I already got a standard deployment configuration to work, the unix app is deployed to all servers with machineType linux-* by linking etc/apps/unix/ to etc/deployment-apps/unix/. That an updated app on the deployment server is automatically pushed to all clients is ok for me at the moment.
Now I thought about adding special inputs for example, to all server with device-mapper multipathing.
My idea is using a second serverClass entry with a different repositoryLocation. In that repository I delete everything apart from a local/inputs.conf that contains just the additional multipath input.
I would hope that first the machineType unix app is deployed and after that the multipathing unix app gets kind of merged.
Any idea if something like that could work or what is the correct way to deploy multiple slighty different configurations of the same app?
I'm not sure what happens if you try to send a forwarder two copies of the same app. One would probably win over the other, and you wouldn't have your desired result.
What you want to do is leverage Splunk's built in configuration-merging functionality. If you need to send a few lines to one server, just make a new app with those few lines on it! Splunk will automatically merge the apps together into its running configuration.
For example, most apps ship with inputs disabled. You can send out the unix app, and it won't collect anything. But to certain servers, you can also send an app that has just a local/inputs.conf of
disabled = 0
As long as your setting is in local/, it will always override the settings in the unix app's default/ - no matter what your app is named.
To check merged settings, run bin/splunk cmd btool <name of config file> list and --debug will list down the list which app the particular setting came from. For example, bin/splunk cmd btool inputs list --debug