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!

Announcing Scheduled Export GA for Dashboard Studio

We're excited to announce the general availability of Scheduled Export for Dashboard Studio. Starting in ...

Extending Observability Content to Splunk Cloud

Watch Now!   In this Extending Observability Content to Splunk Cloud Tech Talk, you'll see how to leverage ...

More Control Over Your Monitoring Costs with Archived Metrics GA in US-AWS!

What if there was a way you could keep all the metrics data you need while saving on storage costs?This is now ...