Hi Splunkers, I have a question about a possible issues on UF management via Deploymet Server.
On a customer env, some UFs have been installed on Windows server. They send data to a dedicated HF. Now, we want manage them with a Deployment Server.
The point is this: those UF have been installed with graphical wizard. During this installation, it has been set which data to collect and to send to HF. So, the inputs.conf has been set during this phase, in a GUI manner.
Now, in a Splunk course material (I don't remeber one, it should be the Splunk Enterprise Admin one), I got this warning: if inputs.conf, for Windows UF, are set with graphical wizard like in our case, Deployment Server could get some problems in interact with them, even it could not be able to manage them.
Is this confirmed? Do you know in which section on documentation I can find evidence of this?
It might be true. There are two important things here.
1. You can only distribute _apps_ from the deployment server. So the apps get pulled by the deployment client (in this case your UF) and put into your $SPLUNK_HOME/etc/apps directory
2. Splunk builds the "effective config" by layering all relevant config files according to precedence rules described here https://docs.splunk.com/Documentation/Splunk/latest/Admin/Wheretofindtheconfigurationfiles
So depending on where the install wizard puts those settings, you might or might not be able to overwrite them with an app deployed from DS.
You can check where the settings are stored by running
splunk btool inputs list --debug
This will show you effective config entries along with the file in which it is defined.
If it's in some app/something/... file, it can be overwritten, possibly with some clever app naming in order to put the config file alphabetically before/after another app. But if it's in system/local... you can't overwrite it with an app.
And that's why it's not advisable to put settings in system/local unless you're really really sure you want to do that. If you put settings there you can't overwrite it in any way later unless you manually edit the system/local/whatever.conf file on that particular Splunk component (ok, there is an exception for clustered indexers, but that's for another time).