Splunk Enterprise

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

andrewtrobec
Motivator

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
Motivator

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

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

Introducing Splunk Enterprise 9.2

WATCH HERE! Watch this Tech Talk to learn about the latest features and enhancements shipped in the new Splunk ...

Adoption of RUM and APM at Splunk

    Unleash the power of Splunk Observability   Watch Now In this can't miss Tech Talk! The Splunk Growth ...

Routing logs with Splunk OTel Collector for Kubernetes

The Splunk Distribution of the OpenTelemetry (OTel) Collector is a product that provides a way to ingest ...