Deployment Architecture
Highlighted

Deprecated machineTypes -v- machineTypesFilter

Path Finder

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
Highlighted

Re: Deprecated machineTypes -v- machineTypesFilter

Motivator

are you using Splunk version 4.3?

Highlighted

Re: Deprecated machineTypes -v- machineTypesFilter

Path Finder

Yes. sorry I should have noted that.

Highlighted

Re: Deprecated machineTypes -v- machineTypesFilter

Splunk Employee
Splunk Employee

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

View solution in original post

Highlighted

Re: Deprecated machineTypes -v- machineTypesFilter

Communicator

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.

0 Karma
Highlighted

Re: Deprecated machineTypes -v- machineTypesFilter

Path Finder

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.

0 Karma
Highlighted

Re: Deprecated machineTypes -v- machineTypesFilter

Builder

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.

0 Karma
Highlighted

Re: Deprecated machineTypes -v- machineTypesFilter

Communicator

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.

Highlighted

Re: Deprecated machineTypes -v- machineTypesFilter

Path Finder

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.