Splunk Enterprise

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

andrewtrobec
Builder

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

Labels (3)
0 Karma

somesoni2
Revered Legend

Does the app have a local folder on DS?

andrewtrobec
Builder

@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 🙂

Tags (1)
0 Karma

somesoni2
Revered Legend

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

0 Karma

edoardo_vicendo
Contributor

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
Builder

@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
Contributor

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

0 Karma
Get Updates on the Splunk Community!

Observability Highlights | January 2023 Newsletter

 January 2023New Product Releases Splunk Network Explorer for Infrastructure MonitoringSplunk unveils Network ...

Security Highlights | January 2023 Newsletter

January 2023 Splunk Security Essentials (SSE) 3.7.0 ReleaseThe free Splunk Security Essentials (SSE) 3.7.0 app ...

Platform Highlights | January 2023 Newsletter

 January 2023Peace on Earth and Peace of Mind With Business ResilienceAll organizations can start the new year ...