Deployment Architecture

Simplifying serverclass.conf?

sowings
Splunk Employee
Splunk Employee

Let's say that I have a class in my serverclass.conf that contains a pretty substantial
white/blacklist. This is in an effort to narrow down the hosts receiving a particular set
of apps. Further, let's assume that there are, say, two distinct subsets of the larger
class, that get data center specific apps (e.g. one containing outputs.conf). The docs
for serverclass.conf say that I can include whitelist.N or blacklist.N at the app level
in addition to the class level.

When I provide a filtering statement at the app level, am I overriding the existing one
from the class level, and therefore renumbering the entries, or clearing them, such as
blacklist.4 = ? Or instead is this a completely separate filter and my
numbering would start again at 0?

Tags (1)
1 Solution

hexx
Splunk Employee
Splunk Employee

According to serverclass.conf.spec:

# Property inheritance
# Stanzas in serverclass.conf go from general to more specific, in the following order:
# [serverClass] -> [serverClass:<name>] -> [serverClass:<scname>:app:<appname>]
#
# Some properties defined at a general level (say [serverClass]) can be
# overridden by the more specific stanzas as it applies to them. All inheritable
# properties are marked as such.
(...)

filterType = whitelist | blacklist
(...)  
* Can be overridden at the serverClass level, and the serverClass:app level.

It seems that a filtering statement at the app level (most specific) will override a colliding statement at the class-level (least specific).

View solution in original post

hexx
Splunk Employee
Splunk Employee

According to serverclass.conf.spec:

# Property inheritance
# Stanzas in serverclass.conf go from general to more specific, in the following order:
# [serverClass] -> [serverClass:<name>] -> [serverClass:<scname>:app:<appname>]
#
# Some properties defined at a general level (say [serverClass]) can be
# overridden by the more specific stanzas as it applies to them. All inheritable
# properties are marked as such.
(...)

filterType = whitelist | blacklist
(...)  
* Can be overridden at the serverClass level, and the serverClass:app level.

It seems that a filtering statement at the app level (most specific) will override a colliding statement at the class-level (least specific).

sowings
Splunk Employee
Splunk Employee

Thanks, I finally worked it out. There was one more key piece of documentation that I had missed before:

# Note: Overriding one type of filter (whitelist/blacklist) causes the other to
# the overridden too. It is important to note that if you are overriding the
# whitelist, the blacklist will not be inherited from the parent - you must
# provide one in the stanza.

My instance used filterType = blacklist but initially failed to carry forward the blacklist entries. When I added that in at app level, that worked.

Get Updates on the Splunk Community!

.conf24 | Registration Open!

Hello, hello! I come bearing good news: Registration for .conf24 is now open!   conf is Splunk’s rad annual ...

Splunk is officially part of Cisco

Revolutionizing how our customers build resilience across their entire digital footprint.   Splunk ...

Splunk APM & RUM | Planned Maintenance March 26 - March 28, 2024

There will be planned maintenance for Splunk APM and RUM between March 26, 2024 and March 28, 2024 as ...