I created an "app" on my old deployment server in
etc/deployment-apps/ called deployserver, and in it, created the local directory, and in that created deploymentclient.conf. Deploymentclient.conf contains
[deployment-client] disabled = false [targer-broker: deploymentServer] targerUri = newdeployserver.domain.com:8089 [license] Master_uri = newlicenseserver.domain.com:8089
And when I reload my legacy deployment server, the deployserver app is dropped onto the client. I'm manually restarting the splunkforwarder on the client (something's weird w/ my serverclasses.conf), and when the client comes back up, the new deployment server doesn't see it. Only after I run
bin/splunk set deploy-poll newdeployserver.domain.com:8089 and restart, the splunkforwarder does start talking to the new deployment server.
Reading about precedence, I see that
etc/system/local/ will take precedence over an app config, but I thought the deployment config app was a possibility.
Has anyone done this, created a deployment server app? How'd you get it to work?
Thanks for any help.
You could use a dirty hack:
Add a scripted input to your app on the old deployment server and miss use the input script to remove the old deploymentserver config from etc/system/local in case it exists.
Deploy this app down to your clients and all clients should now remove the config from etc/system/local and have a new config within your app.
However you then need to restart the clients to get the new config active e.g. by removing the scripted input on the deployment server, setting restartSplunkd = true and deploying the app again.
Additionally you should also place your configuration app (without the scripted input) on the new deployment Server.
Probably not the best way but a way you could potentially go if you have no other chances. But you should first carefully check with a single test client!