Managing a growing serverclass.conf

[Ricapar]

We're using Splunk's deployment server to simplify inputs.conf/app configurations on our Universal Forwarders.

We're adding more servers to out environment, and the serverclass.conf file on our Deployment Servers is starting to get pretty large and complicated.

We're using wildcards on some whitelists/blacklists, which work very well since our hostnames follow a given pattern.

But that's not always enough..

We have an entire group's worth of servers (so far about 300ish) that all need the same inputs.conf configuration. Right now we're doing this by listing out all the hostnames by doing:

whitelist.0 = host1
whitelist.1 = host2
...
whitelist.99 = host100
...
whitelist.299 = host300

It's a long and growing list, and it's getting pretty difficult to keep track of.

I've put together a good bit of this list via a script I wrote to automate it's creation, but it feels like this is a bit overkill.

How is everyone else managing their serverclass.conf file when there are many of servers that need to receive a specific configuration?

[nwales]

If your example is really as straightforward as this the whitelist command takes a wildcard so it could look as simple as this:

whitelist.0 = host*

[dstaulcu]

we use microsoft sms in our environment.. with sms, we maintain collections which are basically SQL queries that result in a list of host names to target deployments to.

Building on that construct, a student of ours wrote a executable that updates host whitelist or blacklist entries in serverclasses within a specified serverclass.conf file. For his program to work, we have to define in an xml file connection strings for referenced sql servers, serverclass names, and sql-queries resulting in host names to whitelist or blacklist for each serverclass. With that defined, each time we run the executable against a serverclass.conf, the host names are updated and his program handles all the auto-incrementation of whitelist/blacklist instances numbers. It's nifty.

To achieve the same thing natively within splunk, it would be nice if deployment-servers supported reference to a saved report or lookup table on search head as basis for whitelist or blacklist entries for a given serverclass.

[jtrucks]

I'm considering scripting this or putting cfengine or another configuration management solution in place here. I'd love to create a serverclass.d and shove a code snippet into a file and have it managed like that, but that might be a feature enhancement with a low priority.

I'm thinking of a lookup table of some sort and having a script autogenerate the whitelist.#### entries based on sequential number generation et al.

[tlmayes]

To jtrucks, interested in whether or not you pursued this. II'm working in an environment with ~20k (and growing) UF's and a range of geographies and sub-geographies requiring many white/black lists and apps. Deployment Manager GUI is no longer useful so moving to CLI. The downer is as discussed here is a better way to manage this file and its relationships (Apps & white/blacklists).

The use of lookup table is very interesting, but mostly interested in what you and others may have found as a "best" solution.

[jeremiahc4]

Another thought, you already have a structure within Splunk for handling distributed configurations (i.e. $SPLUNK_HOME/etc/system/default/server.conf, $SPLUNK_HOME/etc/system/local/server.conf, $SPLUNK_HOME/etc/apps/appName/default/server.conf, & $SPLUNK_HOME/etc/apps/appName/local/server.conf) and how to merge those into a single file at runtime with order of precedence. Why not adapt that to the Deployment Server so I can define a local serverclass.conf that has applicability to a specific segment of my environment.