Deployment Architecture

Serverclass.conf - server gets app under two stanzas, but not another

msarro
Builder

Hello!
I am trying to figure this one out. I have a server which is actively communicating with the deployment server. There are several stanzas which refer to the server 10.253.163.32 (a RHEL 5.x x64 box):

[global]
blacklist.0 = *
restartSplunkd = true

#All clients
[serverClass:all_clients]
whitelist.0 = *

[serverClass:all_clients:app:Base_DeploymentClient]
restartSplunkd = true
stateOnClient = true

#All Forwarders
[serverClass:all_forwarders]
whitelist.0 = *
blacklist.0 = 10.253.163.243
blacklist.1 = 10.255.157.85
blacklist.2 = 10.253.135.172
blacklist.3 = 10.253.135.173
blacklist.4 = 10.253.135.174

[serverClass:all_forwarders:app:bcs_fwd_limits]
restartSplunkd = true
stateOnClient = enabled

#All *nix PE forwarders
[serverClass:all_pe_nix_forwarders]
machineTypesFilter=linux-i686, linux-x86_64, sunos-sun4u
whitelist.0 = 10.253.163.*
whitelist.1 = 10.253.172.*
blacklist.0 = 10.253.163.243

[serverClass:all_pe_nix_forwarders:app:pe_bcs_fwd_nix_ssl]
restartSplunkd = true
stateOnClient = enabled

The server receives Base_DeploymentClient and bcs_fwd_limits apps with no issue, however it does NOT receive the pe_bcs_fwd_nix_ssl app. The app exists, and I can see the server phoning home. Am I making a logic error here that I am missing?

0 Karma
1 Solution

msarro
Builder

After finding this post:
http://answers.splunk.com/answers/41355/deprecated-machinetypes-v-machinetypesfilter

It turns out that machineTypesFilter doesn't work properly if you don't begin the stanza with whitelist.0 = * at both the serverClass and App level. I made the changes as described, and it appears to now be working. Kind of annoying to have the redundancy but it is working!

View solution in original post

0 Karma

msarro
Builder

After finding this post:
http://answers.splunk.com/answers/41355/deprecated-machinetypes-v-machinetypesfilter

It turns out that machineTypesFilter doesn't work properly if you don't begin the stanza with whitelist.0 = * at both the serverClass and App level. I made the changes as described, and it appears to now be working. Kind of annoying to have the redundancy but it is working!

0 Karma

sowings
Splunk Employee
Splunk Employee

If you have _internal logs from 10.253.163.32, try looking for messages from the deployment client (in splunkd.log).

0 Karma

sowings
Splunk Employee
Splunk Employee

Is the app OK? The forwarder might be attempting to install it but not finding a critical piece of infrastructure. Does it have a metadata subdir with a local.meta and/or an an app.conf in either default/ or local/ ?

0 Karma

gkanapathy
Splunk Employee
Splunk Employee

I don't have a Splunk Linux install handy right now, but I believe that the machineTypeFilter entry should be linux-x86_64, not linux-x86-64 that you have, i.e., underscore instead of dash.

msarro
Builder

Good observation, and I have edited the example. We did make that change, but it appears to have not resolved the issue. We were really hopeful it would 😞

0 Karma
Get Updates on the Splunk Community!

Stay Connected: Your Guide to May Tech Talks, Office Hours, and Webinars!

Take a look below to explore our upcoming Community Office Hours, Tech Talks, and Webinars this month. This ...

They're back! Join the SplunkTrust and MVP at .conf24

With our highly anticipated annual conference, .conf, comes the fez-wearers you can trust! The SplunkTrust, as ...

Enterprise Security Content Update (ESCU) | New Releases

Last month, the Splunk Threat Research Team had two releases of new security content via the Enterprise ...