Deprecated machineTypes -v- machineTypesFilter

[eckdale]

The Splunk v4.3 spec for serverClass.conf indicates that attribute 'machineTypes' has been deprecated and the preferred attribute is 'machineTypesFilter'. However it seems that with my configuration the deprecated attribute works and the new attribute does not. I.E. Deployment app gets deployed when using the deprecated attribute versus preferred attribute.

It should be noted that I am a Splunk novice. Here is a copy of my test serverClass.conf:

# -----------------------------------------------------------------------------
# File name: serverclass.conf
# Author: Slunk newbie
# Date: 02/22/2012 16:21:55
# Keywords: configuration
# Comments: 
#           $SPLUNK_HOME/etc/system/local/serverclass.conf
# -----------------------------------------------------------------------------
[global]
repositoryLocation = $SPLUNK_HOME/etc/deployment-apps
targetRepositoryLocation = $SPLUNK_HOME/etc/apps

# Server classes --------------------------------------------------------------
[serverClass:all-searchheads]
whitelist.0 = myhost.skunkworks.root.local

[serverClass:all-indexers]
whitelist.0 = myhost.skunkworks.root.local

[serverClass:all-forwarders]
blacklist.0 = vlab-mgmt-02.skunkworks.root.local
whitelist.0 = *

[serverClass:all-machinetypes]
whitelist.0 = *

[serverClass:all-adds]
whitelist.0 = addc-01.root.local
whitelist.1 = addc-03.skunkworks.root.local

# Applications ----------------------------------------------------------------
[serverClass:all-forwarders:app:universalfwd]
stateOnClient = enabled
restartSplunkd = true

[serverClass:all-forwarders:app:std-winevt-logs]
stateOnClient = enabled
restartSplunkd = true
machineTypesFilter = windows-x64, windows-x86, windows-intel

[serverClass:all-adds:app:ad-monitor]
stateOnClient = enabled
restartSplunkd = true
machineTypesFilter = windows-x64, windows-x86, windows-intel

[gekoner]

I was able to finally get this to work with some help from the Splunk support team.
My deployment server is Splunk 4.3.3 (build 128297)

Here is my working stanza;

[serverClass:namehere]
machineTypesFilter = linux-x86_64, linux-x86
whitelist.0 = *
blacklist.0 = hostnamevaluehere
blacklist.1 = hostnamevaluehere
blacklist.2 = hostnamevaluehere
stateOnClient=enabled
restartSplunkd=true
[serverClass:namehere:app:namehere

For me I was missing the whitelist.0= * entry. Without this it would not work.
Hope this helps.

[dkuk]

I already had a whitelist at the serverclass level (under [serverClass:namehere] stanza in the example above). It was at the app level ([serverClass:namehere:app:namehere] in e.g. above), where I needed to add a whitelist entry. Once both of these were done, the expected behaviour resumed. This seems to be slightly different than the old machineTypes way of doing things where the serverClass whitelist would have been inherited I think. Your comment led me to realise this so thanks gekoner.

[jbsplunk · Accepted solution]

This is a bug, being tracked as SPL-52201, and scheduled to be fixed in 4.3.4.

http://docs.splunk.com/Documentation/Splunk/4.3.3/ReleaseNotes/Knownissues

[msarro]

Same issue exists in 5.0.3. It's a huge PITA for us because we use a global blacklist and adding whitelist.0=* deploys apps to everywhere, and we can't list out 1000+ individual blacklist lines just so splunk can see a whitelist.0 entry.

[dkuk]

I've noticed that when using v5.0.1 this issue still seems to exist. Only by using machineTypes (rather than machineTypesFilter) do apps successfully deploy in my environment.

[gekoner]

Having the same issue on a Splunk Deployment server that is version 4.3.3.
Deprecated attribute 'machineTypes' works and preferred attribute 'machineTypesFilter' does not.

[eckdale]

Yes. sorry I should have noted that.

[MarioM]

are you using Splunk version 4.3?