Deployment Architecture

Updating the 'deploymentclient.conf' on Forwarders to Point to New Deployment Server

rgcurry
Contributor

I am migrating to a new architecture with my Splunk implementation. In this change I will be creating a new Deployment Server. I want to get this change rolled out to all of my Forwarders but from what I've read in the doc, I cannot update the $SPLUNK_HOME/etc/system/local/deploymentclient.conf via the Deployment Server. I have an app called 'deployment_client' that was setup to send config changes to the Forwarder but the etc/system/local copy of deploymentclient.conf trumps any duplicated keyword=value pair so I cannot use that to make this change.

Rolling this around in my head I thought -- maybe -- I can create an app in the Deployment Server on the old platform that will send and execute a script that will also carry with it a new version of the deploymentclient.conf with the correct settings and copy that over the existing version of the file then issue a restart command. This app will not exist on the new Deployment Server so this [script: ...] app will be removed from the Forwarders after they restart, connect to the new Deployment Server and "phone home" and get their updates.

Does anyone see something I do not or something that I have missed with this idea?

Rick

1 Solution

rgcurry
Contributor

It seems that I misread the doc and that I can update my deployment_client app with the new settings, deploy that to the Forwarders and the change will take place as needed and wanted.

Is this a great product or what?! Clearly the designers and developers think thru some pretty impressive use cases as they built and continue to improve Splunk. The more I work with it the more I not only love the product but see the many possibilities for which we can use it.

View solution in original post

rgcurry
Contributor

It seems that I misread the doc and that I can update my deployment_client app with the new settings, deploy that to the Forwarders and the change will take place as needed and wanted.

Is this a great product or what?! Clearly the designers and developers think thru some pretty impressive use cases as they built and continue to improve Splunk. The more I work with it the more I not only love the product but see the many possibilities for which we can use it.

sowings
Splunk Employee
Splunk Employee

The system always prefers the system/local version. The configs in system/default provide a base. Next, the default configs from apps (in etc/apps/<app>/default) are layered on, then the local configs from apps, then finally system/local.

For this reason, when using the deployment server, it's preferred not to write application settings to system/local, as they will never be overridden by any application you deploy.

0 Karma

twinspop
Influencer

I'm not seeing that behavior. Can you point me to the docs that explain it? I have an 'outputs' app that includes a deploymentclient.conf file. However, it is ignored. The system prefers the system/local version.

0 Karma
Get Updates on the Splunk Community!

Earn a $35 Gift Card for Answering our Splunk Admins & App Developer Survey

Survey for Splunk Admins and App Developers is open now! | Earn a $35 gift card!      Hello there,  Splunk ...

Continuing Innovation & New Integrations Unlock Full Stack Observability For Your ...

You’ve probably heard the latest about AppDynamics joining the Splunk Observability portfolio, deepening our ...

Monitoring Amazon Elastic Kubernetes Service (EKS)

As we’ve seen, integrating Kubernetes environments with Splunk Observability Cloud is a quick and easy way to ...