Deployment Architecture

Is there an order of precedence in the serverclass.conf?

stcrispan
Communicator

In serverclass.conf...

I'm creating different classes, for deployment. I've inherited this setup, and the previous guy got pretty fancy, so I can't use the GUI to edit any more. I have multiple stanzas within my serverclass.conf, and now I'm trying to split out my tablets into different indexes (and applications).

So, I have a class of devices called tablets, which incorporates every tablet that has been released into the enterprise. Now they are rolling out a sub-class of tablets, which are using a different model tablet with Windows 10. Up until now, tablets have been released with an unpopulated deploymentclient.conf:

[deployment-client]

[target-broker:deploymentServer]
targetUri= 10.10.12.12:8089 

The new tablets are being released with a populated deploymentclient.conf

[deployment-client]
SLATE-$HOSTNAME

[target-broker:deploymentServer]
targetUri= 10.10.12.12:8089 

So I inserted a pair of stanzas into my serverclass.conf, to cover the new tablets using Windows 10:

#########  Original tablets stanza

[serverClass:MYAPP_TABLETS]
whitelist.0 = SLATE*
blacklist.0 = SLATE549G2

[serverClass:MYAPP_TABLETS:app:_server_app_MYAPP_TABLETS]
restartSplunkWeb = 0
restartSplunkd = 1
stateOnClient = enabled

#########  New tablets stanza

[serverClass:MYAPP_TABLETS10]
whitelist.0 = SLATE-*
whitelist.1 = SLATE*-*.stores.roomstogo.rtg
blacklist.0 = SLATE549G2

[serverClass:MYAPP_TABLETS10:app:_server_app_MYAPP_TABLETS10]
restartSplunkWeb = 0
restartSplunkd = 1
stateOnClient = enabled

...and restarted the deployment server (for all apps).

...and got jack. None of the new tablets decided to bite on the new setup.

So my question is, is there an order of precedence in serverclass.conf? Since all my tablets have been using the first stanza, will they simply ignore the second stanza? Or is there a problem with my white/blacklisting? Is it an issue with the deployment client?

Open to suggestions...

ddrillic
Ultra Champion

According to deploymentclient.conf

The syntax is -

[deployment-client]
clientName = deploymentClient
* Defaults to deploymentClient.
* A name that the deployment server can filter on.
* Takes precedence over DNS names.

So, shouldn't it read? -

[deployment-client]
clientName = SLATE-$HOSTNAME

Interestingly, splunk cmd btool check didn't complain about just SLATE-$HOSTNAME...

0 Karma

wyfwa4
Communicator

For the serverclass.conf file, there are no precedence rules. If a host matches a whitelist rule for a server class, then it will automatically deploy any apps assigned to that server class. So in your example, any device called "SLATE-*" will match both server classes and therefore both apps will be deployed.

The only place precedence is involved, is when multiple apps are deployed to the local forwarder and they both have the same stanza's. At that point if you have both apps going to the same hosts and will apply the different settings for the same stanza, you can rename your apps to ensure you know when will take priority. For example if you have two apps that both collect windows system eventlogs, but you want to apply different collection rules for Windows 10 to Windows 8.

From the example above, it looks like the original tablet class (MYAPP_TABLETS) will match both types, while the new Windows 10 tablet class (MYAPP_TABLETS10) will only match the new tablets. Therefore you name your app "_server_app_MYAPP_TABLETS10" to have a lower priority than "_server_app_MYAPP_TABLETS". So where both versions exist (on original tablets) only the original app works. While on the Windows 10 tablets, only the Windows 10 app is deployed and so the priority is irrelevant.

There are just a couple of points to highlight
1) The process above only works if the two apps are applying the same stanza's but with different settings. If they contain different stanza's, then this will not work.
2) The precendence rules are a bit complex based on you app names - Splunk will compare each character as you go through the app name - so when a difference is found in the name (for example your app names are identical apart from an appended "10" ) The following rules apply -

1) hypen
2) number (1 first)
3) upper case letter (A first)
4) blank (no more chars)
5) underscore
6) Lower case letter (a first)

So for your app names - the app "_server_app_MYAPP_TABLETS10" is currently higher precedence, as a number is a higher precedence than "no character" / blank - meaning the end of the name. If you rename your app "_server_app_MYAPP_TABLETS_10", then will then start to have a lower precedence that your original app "_server_app_MYAPP_TABLETS"

FrankVl
Ultra Champion

While you cannot use the forwarder management GUI anymore for editing the serverclass config, you can still use it to check how clients are presenting themselves to the DS and what class(es) they get assigned. I'd start there (if you hadn't already) to see if that gives some clues.

0 Karma

stcrispan
Communicator

Good suggestion, thank you! I went back in to my Fowarder Management, and found that I actually was gathering devices in my new server class...but I'm still gathering them in the old class, too.

I'm thinking that I need to work on my white/black lists.

0 Karma

FrankVl
Ultra Champion

Well, SLATE* of course also matches anything that matches SLATE-*. Adding SLATE-* to the blacklist of the first class might solve your problem?

0 Karma
Did you miss .conf21 Virtual?

Good news! The event's keynotes and many of its breakout sessions are now available online, and still totally FREE!