How to install an app or add-on which is not Deployment Server compatible but should be present in the end client?

[koshyk]

hi
We have a deployment server configured to push apps to heavy forwarders. the heavy forwarder apps are managed by "deployment-server". It seems some of the Splunk Official apps and add-ons don't support Deployment-server (eg Splunk Add-on for ServiceNow). So in this case, how would we deploy the add-on to the end clients (Heavy forwarders?)?

• if I install it manually, will it be wiped out by Deployment Server on the next iteration? Because the rest of the apps are managed by deployment server, we cannot detach deployment server for whole of the heavy forwarders.
• How you guys do this? How is Splunk is expecting to do these type of non-supported apps?

[woodcock]

The main reason that these are "Not DS compatible" is because they require you to run though a configuration step ( setup.xml ). So what I do is deploy to the DS, run the configuration/setup there, being sure to TEST ALL FEATURES. Then move it from the $SPLUNK_HOME/etc/apps/<NEW APP>/ directory to the $SPLUNK_HOME/etc/deployment-apps/<NEW APP>/ directory and deploy it where it should go.

[koshyk]

@woodcock, We have done the same and it works. But the only problem remaining is the "password" is cannot be encrypted in "deployment-apps".

[woodcock]

If you ensure that all of you Splunk infrastructure nodes share a common $SPLUNK_HOME/etc/auth/splunk.secret file, this should not be a problem.

[muebel · Accepted solution]

Hi koshyk, I expect you'll have some issues deploying apps from the DS that end up being customized on the client system. The Deployment Server and Deployment Client each maintain hashes of the apps. If there is a disagreement, the DS is the authority, and the DC is reloaded.

So, for apps that your options are to do all configuration within the app on the deployment server, and then reload to deploy the changes as needed. This isn't possible if the Servicenow App contains data or state information within the app ( I know the DB Connect app does this, for instance).

Alternatively, you can utilize another configuration management system to manage the state of the default and static components of the app, and ignore the rest. This will let you deploy updates to the app, while leaving all the local config intact.

Finally, depending on how many HFs you are dealing with, you could maintain them manually. Not always the best option, but suitable if you are only dealing with a small amount of systems.

Please let me know if this answers your question! 😄

[koshyk]

hi mate, thanks for reply. When you say manually ; you mean copying and configuring directly into HF? This means the serverclass entry won't be in DS. Will this be wiped out?

[muebel]

Correct, the manual step would be to disengage the DS entirely. Remove the app from the DS and do not associate it with any server class.