<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Simplifying serverclass.conf? in Deployment Architecture</title>
    <link>https://community.splunk.com/t5/Deployment-Architecture/Simplifying-serverclass-conf/m-p/20484#M483</link>
    <description>&lt;P&gt;Let's say that I have a class in my serverclass.conf that contains a pretty substantial &lt;BR /&gt;
white/blacklist. This is in an effort to narrow down the hosts receiving a particular set&lt;BR /&gt;
of apps. Further, let's assume that there are, say, two distinct subsets of the larger&lt;BR /&gt;
class, that get data center specific apps (e.g. one containing outputs.conf). The docs&lt;BR /&gt;
for serverclass.conf say that I can include whitelist.N or blacklist.N at the &lt;EM&gt;app&lt;/EM&gt; level&lt;BR /&gt;
in addition to the class level.&lt;/P&gt;

&lt;P&gt;When I provide a filtering statement at the app level, am I overriding the existing one&lt;BR /&gt;
from the class level, and therefore renumbering the entries, or clearing them, such as&lt;BR /&gt;
&lt;CODE&gt;blacklist.4 = &lt;/CODE&gt; ? Or instead is this a completely separate filter and my&lt;BR /&gt;
numbering would start again at 0?&lt;/P&gt;</description>
    <pubDate>Tue, 05 Feb 2013 17:06:00 GMT</pubDate>
    <dc:creator>sowings</dc:creator>
    <dc:date>2013-02-05T17:06:00Z</dc:date>
    <item>
      <title>Simplifying serverclass.conf?</title>
      <link>https://community.splunk.com/t5/Deployment-Architecture/Simplifying-serverclass-conf/m-p/20484#M483</link>
      <description>&lt;P&gt;Let's say that I have a class in my serverclass.conf that contains a pretty substantial &lt;BR /&gt;
white/blacklist. This is in an effort to narrow down the hosts receiving a particular set&lt;BR /&gt;
of apps. Further, let's assume that there are, say, two distinct subsets of the larger&lt;BR /&gt;
class, that get data center specific apps (e.g. one containing outputs.conf). The docs&lt;BR /&gt;
for serverclass.conf say that I can include whitelist.N or blacklist.N at the &lt;EM&gt;app&lt;/EM&gt; level&lt;BR /&gt;
in addition to the class level.&lt;/P&gt;

&lt;P&gt;When I provide a filtering statement at the app level, am I overriding the existing one&lt;BR /&gt;
from the class level, and therefore renumbering the entries, or clearing them, such as&lt;BR /&gt;
&lt;CODE&gt;blacklist.4 = &lt;/CODE&gt; ? Or instead is this a completely separate filter and my&lt;BR /&gt;
numbering would start again at 0?&lt;/P&gt;</description>
      <pubDate>Tue, 05 Feb 2013 17:06:00 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Deployment-Architecture/Simplifying-serverclass-conf/m-p/20484#M483</guid>
      <dc:creator>sowings</dc:creator>
      <dc:date>2013-02-05T17:06:00Z</dc:date>
    </item>
    <item>
      <title>Re: Simplifying serverclass.conf?</title>
      <link>https://community.splunk.com/t5/Deployment-Architecture/Simplifying-serverclass-conf/m-p/20485#M484</link>
      <description>&lt;P&gt;According to &lt;A href="http://docs.splunk.com/Documentation/Splunk/latest/admin/Serverclassconf"&gt;serverclass.conf.spec&lt;/A&gt;:&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;# Property inheritance
# Stanzas in serverclass.conf go from general to more specific, in the following order:
# [serverClass] -&amp;gt; [serverClass:&amp;lt;name&amp;gt;] -&amp;gt; [serverClass:&amp;lt;scname&amp;gt;:app:&amp;lt;appname&amp;gt;]
#
# 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.
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;It seems that a filtering statement at the app level (most specific) will override a colliding statement at the class-level (least specific).&lt;/P&gt;</description>
      <pubDate>Tue, 05 Feb 2013 22:40:31 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Deployment-Architecture/Simplifying-serverclass-conf/m-p/20485#M484</guid>
      <dc:creator>hexx</dc:creator>
      <dc:date>2013-02-05T22:40:31Z</dc:date>
    </item>
    <item>
      <title>Re: Simplifying serverclass.conf?</title>
      <link>https://community.splunk.com/t5/Deployment-Architecture/Simplifying-serverclass-conf/m-p/20486#M485</link>
      <description>&lt;P&gt;Thanks, I finally worked it out. There was one more key piece of documentation that I had missed before:&lt;/P&gt;

&lt;PRE&gt;
# 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.
&lt;/PRE&gt;

&lt;P&gt;My instance used &lt;CODE&gt;filterType = blacklist&lt;/CODE&gt; but initially failed to carry forward the blacklist entries. When I added that in at app level, that worked.&lt;/P&gt;</description>
      <pubDate>Thu, 14 Feb 2013 18:28:48 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Deployment-Architecture/Simplifying-serverclass-conf/m-p/20486#M485</guid>
      <dc:creator>sowings</dc:creator>
      <dc:date>2013-02-14T18:28:48Z</dc:date>
    </item>
  </channel>
</rss>

