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!

Index This | I am a number, but when you add ‘G’ to me, I go away. What number am I?

March 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with another ...

What’s New in Splunk App for PCI Compliance 5.3.1?

The Splunk App for PCI Compliance allows customers to extend the power of their existing Splunk solution with ...

Extending Observability Content to Splunk Cloud

Register to join us !   In this Extending Observability Content to Splunk Cloud Tech Talk, you'll see how to ...