Yesterday I saw the following within
[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?
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.
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.
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.