Two serverclass.conf files - now what?

[a212830]

Hi,

Because of the ridiculous nature in which Splunk handles serverclass.conf via the gui (really? I can create multiple serverclass.conf files, based upon where I was in the gui?)... I know have two serverclass.conf files and need to reconcile them. Is it as simple as appending one on to the other? Looking for suggestions...

[hettervik]

The documentation clearly states that "[...] forwarder management creates the serverclass.conf file under $SPLUNK_HOME/etc/system/local on the deployment server." I have the same problem as you in 7.0.2, so apparently this bug hasn't been fixed yet, or if it isn't a bug, the documentation isn't clear on this matter.

[sloshburch]

I often accidentally generate serverclass definitions outside of system scope. I'll build upon my answer in here: https://answers.splunk.com/answers/438982/why-is-my-serverclass-not-in-my-serverclassconf.html

If you run btool serverclass list --debug | grep -v system you should be able to see what's not in your $SPLUNK_HOME/etc/system/local/serverclass.conf.

If you want to merge everything together, you could do it by hand or slam it all with something like this:
btool serverclass list > $SPLUNK_HOME/etc/system/local/serverclass.new
Which will throw the config being used into a new file (instead of replacing immediately).

Then edit the file to remove the items from $SPLUNK_HOME/etc/system/default/serverclass.conf

Then you can remove all the undesired serverclass.conf files with something like:
find /opt/splunk/etc/ -not -path "*system*" -type f -name "serverclass.conf" -ls -exec rm {} \;
Use the above at your own risk since it deletes files. You should start by backing up the $SPLUNK_HOME/etc directory or generating a diag.

You can then use btool with --debug to validate those other files are gone. Then replace the system/local with the new one you created and reload the deployment server. You should be clean from then on.

[a212830]

Yes, I get it. That's how it's designed. Which is my issue. Terrible design (at least for this paticular piece).

I love Splunk. Doesn't mean everything they do is correct.

That said, thanks again for the help. I do appreciate it.

[ddrillic · Accepted solution]

-- Because of the ridiculous nature in which Splunk handles serverclass.conf via the gui (really? ..

The following Configuration file precedence

says -

-- As mentioned, Splunk decides how to evaluate a configuration file based on the context that the file operates within, global or app/user. Generally speaking, files that affect data input, indexing, or deployment activities are global; files that affect search activities usually have a app/user context.

serverclass.conf is defined there as a global configuration file similar to indexes.conf. It means that their "natural" location is at etc/system/local which the admin class emphasizes.

If the GUI is app context sensitive and doesn't have a global context, I would say that this is a bug.

Looking at Use serverclass.conf to define server classes

It says -

It means that etc/system/local is its location.

[jkat54]

Yes it is that simple. Append and maybe look for duplicates just to play it safe. It's also not ridiculous given the file precedence design that this follows. Also maybe you could have a strategy for setting up and deploying apps to minimize your risk of doing this in the future.

[jkat54]

Not to mention the ui is just making calls to the api based on what app context you're in so that your changes only apply to that app. If they "fixed" this for one .conf it would cause trouble with the rest of the design.

[a212830]

Thanks. That said, I couldn't disagree more. It's a terrible design. They should be able to easily create a config setting that is global that is applied to serverclass.conf file. I understand it's making calls to the API - I've been living that horror separately. (No append for serverclass clients?!! )

I'll say it again - the deployment server and it's API isn't made for large enterprises, or anyone who wants to be agile...

[jkat54]

If you need a global variable, you're doing it wrong ;-P. That's all I learned from CS class.

Have you seen the btool command? You could get an output of all the server classes really quick with it:

./splunk cmd btool serverclass list
or

./splunk cmd btool serverclass list --debug

Both should be great for this problem you face.

[a212830]

I can figure it out. Thanks for the help.. I just think it's a terrible design. My opinion, that's all.

[jkat54]

oh ok. Best wishes @a212830