Deployment Architecture

Can we administer the serverclass.conf via the UI only?

danielbb
Motivator

Yesterday I saw the following within serverclass.conf -

[serverClass:<name>]
whitelist.0 = <server1>.<domain>.com
whitelist.1 = <server2>.<domain>.com
whitelist.10 = <server3>.<domain>.com
whitelist.11 = <server4>.<domain>.com
whitelist.12 = <server5>.<domain>.com
whitelist.13 = <server6>.<domain>.com
whitelist.14 = <server7>.<domain>.com
whitelist.15 = <server8>.<domain>.com
whitelist.16 = <server9>.<domain>.com
whitelist.17 = <server10>.<domain>.com
whitelist.18 = <server11>.<domain>.com
whitelist.19 = <server12>.<domain>.com
whitelist.2 = <server13>.<domain>.com
whitelist.20 = <server14>.<domain>.com
whitelist.21 = <server15>.*<server15>.*<server16>.*<server15>.*<server16>.*<server17>.*<server18>.*<server19>.*<server20>.*<server21>.*
whitelist.22 = <server22>.<domain>.com
whitelist.23 = <server23>.<domain>.com
whitelist.24 = <server24>.<domain>.com
whitelist.25 = <server25>.<domain>.com
whitelist.26 = <server26>.<domain>.com
whitelist.27 = <server27>.<domain>.com
whitelist.28 = <server28>.<domain>.com
whitelist.29 = <server29>.*
whitelist.3 = <server30>.<domain>.com
whitelist.30 = <server31>.*
whitelist.31 = <server32>.*
whitelist.32 = <server33>.*
whitelist.33 = <server34>.*
whitelist.34 = <server35>.*
whitelist.35 = <server36>.*
whitelist.36 = <server37>.*
whitelist.37 = <server38>.*
whitelist.38 = <server39>.*
whitelist.39 = <server40>.*
whitelist.4 = <server42>.<domain>.com
whitelist.40 = <server43>.*

I voiced my concerns about the quality of the configurations and I was told the following -

-- Using Web UI @ proper deploy server
changes are stored in $SPLUNK_HOME/etc/system/local/serverclass.conf. We should never edit the file manually and avoid options not supported by Web/UI - this prevent UI from not reflecting the actual configuration and will not break it. The file contains critical information for proper deployments of hundreds of apps.

What would you say to that considering the Splunk application is growing very quickly here?

0 Karma

nickhills
Ultra Champion

If you want to tidy up your ./local/serverclass.conf or modify your existing config by hand, there is no issue with doing so.
You will need to issue splunk reload deploy-server to have the DS reflect any logical changes you have made.

There are some parameters which can only be configured by adding them to the serverclass.conf file manually, however IF you use these settings then the DS GUI will tell you that you can no longer make changes via the UI. (unless you remove those settings)

If you have complicated serverclass definitions the DS can make a right old mess of the configuration because if you neatly comment and lay things out in that file, the next time the UI is used it will mess about with your formating and comments - The config will still work 100% fine, its just frustrating.

I have worked on installations where the approach is to manage the file manually only, and tbh, that is what I tend to do, along with a commit to git for change tracking.

If my comment helps, please give it a thumbs up!

13tsavage
Communicator

Short answer is yes, you can manage serverclasses using just the Splunk Web (GUI) from Settings -> Distributed Environment -> Forwarder Management page.

IF you understand how to configure serverclass.conf correctly you can also make changes using the Splunk administrative CLI. Given that some Splunk environments have NO GUI available to work with, using CLI is the only way to manage serverclasses with their apps and clients.

This would require the administrator to reload the deployment server configuration splunk reload deploy-server or restart splunkd on the deployment server. Once the clients phone home they will see the updated serverclasses.

I cannot say that any changes are necessary because I do not know the specifics of your environment, but I do agree the serverclass.conf could use some cleanup.

gcusello
SplunkTrust
SplunkTrust

Hi @danielbb,
I'm not sure to have understood your question.
I agree to not use direct access to serverclass.conf to modify ServerClasses because it's easy to do garbage.
I think that this part of the Deployment Server functions is OK, the part I don't like is that I have to access to the DS using SSH to upload and / or modify apps.

About the growth of your serverclass.conf, it seems that you have many servers in one ServerClass, see if you can simplify the rules of this ServerClass, eventually using also blacklists: e.g. take all the servers with IP = 10.10.. but not the one with IP = 10.10.10.10, it's simpler than listing all the servers.

Ciao.
Giuseppe

Get Updates on the Splunk Community!

Announcing Scheduled Export GA for Dashboard Studio

We're excited to announce the general availability of Scheduled Export for Dashboard Studio. Starting in ...

Extending Observability Content to Splunk Cloud

Watch Now!   In this Extending Observability Content to Splunk Cloud Tech Talk, you'll see how to leverage ...

More Control Over Your Monitoring Costs with Archived Metrics GA in US-AWS!

What if there was a way you could keep all the metrics data you need while saving on storage costs?This is now ...