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).

[splunkreal]

Hello @somesoni2 @andrewtrobec @edoardo_vicendo  we saw same issue and it can wipe your changes on client's local folder.

So is that normal that even if we don't have local folder in deployment-apps/app, reloading deployment server creates deployment-apps/app/local + deployment-apps/app/local/app.conf ?

We had to leave it, resync correctly then at the end add our specific conf files on the heavyforwarder etc/apps/app/local

Thanks.

[edoardo_vicendo]

@splunkreal ideally if you create the app you should put the configs in the default folder. You should see you as the author.

About your question, yes when you deploy an app the entire app folder on the client is replaced by the new one.

Therefore if you first manually created an app on a client (for test), and later you want to move the management of that app on the deployment server because you have several client, then is the deployment server that will drive. Since then any change need to be made on the DS.

Best Regards,

Edoardo

[splunkreal]

Hi @edoardo_vicendo the weird thing is the local folder with app.conf inside have been created on the deployment-apps folder when restarting/reloading deploy-server.

[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.