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!

Webinar Recap | Revolutionizing IT Operations: The Transformative Power of AI and ML ...

The Transformative Power of AI and ML in Enhancing Observability   In the realm of IT operations, the ...

.conf24 | Registration Open!

Hello, hello! I come bearing good news: Registration for .conf24 is now open!   conf is Splunk’s rad annual ...

ICYMI - Check out the latest releases of Splunk Edge Processor

Splunk is pleased to announce the latest enhancements to Splunk Edge Processor.  HEC Receiver authorization ...