How can I avoid overwriting the local folder when reloading from my deployment server?

[andrewtrobec]

Hello!

I am deploying a custom input to a cluster of Heavy Forwarders from a Deployment Server.  Since I only want the input to be active on one HF I have set disabled=1 on the DS.  After deploying I SSH into the HF I want to enable the input on and create local/inputs.conf and set disabled=0 and restart.

I thought this was the way forward since I didn't think reloading the DS would cause the local folder to be overwritten, but after making a change and redeploying I notice that this does in fact happen.

My question: how can I stop the DS from overwriting the local folder so it's easier to manage my HFs?

Thanks!

Andrew

[somesoni2]

Does the app have a local folder on DS?

[andrewtrobec]

@somesoni2 Thanks for replying.  I don't have a local folder for the app on DS, no, but when I reload deploy-server from backend it automatically creates one with app.conf containing the text "autogenerated" and then overwrites the local folder on the HF.

You've given me something to work with, but it seems as though we're trying to "trick" the DS 🙂

[somesoni2]

I've not played with it yet, but this seems like the setting you need. On serverclass.conf, you've following attribute (available as global, for each serverclass and for each app, set this on your particular app only.)

excludeFromUpdate=$app_root$/local

This should prevent local directory on clients from being overwritten (I believe).

Another option to achieve what you want to do (this I have used) is to use client Name.

https://docs.splunk.com/Documentation/Splunk/8.2.5/Updating/Configuredeploymentclients#Set_a_client_...

You'll basically add the serverclass-whitelist to a clientName and then just  set the clientName on the HF you want to be active. When the HF fails, you can just set the clientName to other available HF. The caveat is that if originally active HF comes back, it'll have that clientName setup and will receive the monitoring. So you'll have to find a way to turn that off (or switch the clientName dynamically between HFs).

[edoardo_vicendo]

Hi Andrew,

Hope you are fine!

About your Use Case I think the best solution is to define on your severclass where the app have to be deployed, so basically on one HF only.

In serverclass.conf:

[serverClass:YOUR_SERVER_CLASS:app:your_app_name]
restartSplunkd = 1
stateOnClient = enabled

[serverClass:YOUR_SERVER_CLASS]
disabled = false
whitelist.0 = <clientName> | <IP address> | <hostname> | <instanceId>

see:

https://docs.splunk.com/Documentation/Splunk/latest/Admin/Serverclassconf

Best Regards,

Edoardo

[andrewtrobec]

@edoardo_vicendo Ciao Edoardo ❤️

Are you saying that I have to create a new server class for one app and for one HF?

[edoardo_vicendo]

@andrewtrobec : exactly, you only need a serverclass that allows to deploy the app on 1 HF only.

In this way you don't need to deploy it on all the HF and then SSH into your single target HF to modify the local folder.

You basically define the correct configs (see for example your_app_name/local/inputs.conf) in the deployment server and then you deploy it just on 1 HF.