Hi all;
I have to decomission our current deployment server (forwarder configs) and was hoping to get an extra set of eyes on the work that I plan on doing:
My expectation here is that the reload will re-push the updated deploymentclient.conf file out to all the servers, which will in turn restart the forwarders and make them connect to the new server.
Wanted to update everyone on what I ended up doing :).
So the first thing i did, was on the original Deployment Server, I created a new deployment app called 'enterprise_deploymentclient' that had a deploymentconfig.conf file that pointed to the new server
I then copied the deployment-apps folder to the new server exactly.
After that, I copied over the serverclasses.conf to the new server.
New server was then recycled.
Next, i worked through each server class, removed the original deploymentclient 'app', and replaced it with the new one
Saved the class, and then verified that the servers soon connected to the new server
Rinsed and repeated for each class, and went page by page
In my opinion, this was the "safest" way of doing it vs just updating the original deploymentclient.conf file and pushing it out in one fell swoop.
So migrating a DS can be a bit tricky sometimes, but ill give you some steps I've used in the past.
on the old DS
1. make a full backup of /opt/splunk/etc/*
on the old DS
2. tar up the following things independantly
a. deployment apps > deployment_apps.tgz
b. system / local > local.tgz
c. apps (I use sym links from /deployment-apps to /apps on the DS to maintain up-to-date apps in a single repo. If not, you won't
need apps)
This 'should' give you the base config of your old DS. Should being operative due to editing default directories anywhere.
/deployment apps
from new server/system/local
from new serverdeployment_apps.tgz
to /opt/splunk/etc
local.tgz
to /opt/splunk/etc/system
before doing this make sure you have that full backup, because if there's ever anything you need for config, it's going to be in /opt/splunk/etc
Thanks @tmarlette! I think one catch that we would need to worry about is making sure that the app on the DS that has deploymentconfig.conf is updated with the new DS right? Else when we now go and update the existing forwarders to point to the new DS, it will keep bouncing back and forth
FYI: we deploy the deploymentconfig.conf as an app vs configuring it during forwarder install
do you mean, deploymentclient.conf? I'm not familiar with the other file.
assuming you mean deploymentlcient.conf here:
so... if you are using an IP address in your deploymentclient.conf, the app your using will be useless, because as soon as you change the IP address on your DS, your forwarders lose connection. UNLESS you're going to use the same IP address, which can sometimes prove tricky.
The workaround:
use a DNS address like 'splunkds.mydoman.com' and stick that in the /etc/system/local folder of all of your forwarders. That way you can change the DNS mapping to a different IP it's basically a hot cut.
I have some doubts about -
-- My expectation here is that the reload will re-push the updated deploymentclient.conf
file out to all the servers
when you say: "copy server classes" i assume you mean that you will copy serverclass.conf
Thats correct 🙂 thanks for the clarification @adonio