Deployment Architecture

Possible to control which attribute matching is performed on in serverclass?

dstaulcu
Builder

The other day I noticed a subset of workstation based deployment clients had an app installed that was meant only for servers.

It turns out the workstations received the server oriented app because of a whitelist entry match on the InstanceID (guid) attribute.  The whitelist pattern was constructed with matching on clientName or hostname attributes in mind.  I was able to work around the problem by making the whitelist entry regular expression less ambiguous.

This got me wondering whether there is a way to control which attribute matching is conducted on for a given whitelist entry.   I see  for CSV based whitelist entries there are all manner of new features which enable specification of the attribute on which  matching occurs (field name).  Is the same sort of control possible through non CSV based whitelist entries?

 

Labels (1)
0 Karma
1 Solution

scelikok
SplunkTrust
SplunkTrust

Hi @dstaulcu,

Unfortunately, non CSV whitelists are match on following order,

* The value of this attribute is matched against several things in order:
    * Any clientName specified by the client in its deploymentclient.conf file
    * The IP address of the connected client
    * The hostname of the connected client, as provided by reverse DNS lookup
    * The hostname of the client, as provided by the client
    * For Splunk Enterprise version > 6.4, the instanceId of the client. This is
      a GUID string, for example: 'ffe9fe01-a4fb-425e-9f63-56cc274d7f8b'.

 

If this reply helps you an upvote and "Accept as Solution" is appreciated.

View solution in original post

dstaulcu
Builder

thanks for the input.   i had already checked the spec but was hoping someone was aware of a creative workaround.  

0 Karma

scelikok
SplunkTrust
SplunkTrust

Hi @dstaulcu,

Unfortunately, non CSV whitelists are match on following order,

* The value of this attribute is matched against several things in order:
    * Any clientName specified by the client in its deploymentclient.conf file
    * The IP address of the connected client
    * The hostname of the connected client, as provided by reverse DNS lookup
    * The hostname of the client, as provided by the client
    * For Splunk Enterprise version > 6.4, the instanceId of the client. This is
      a GUID string, for example: 'ffe9fe01-a4fb-425e-9f63-56cc274d7f8b'.

 

If this reply helps you an upvote and "Accept as Solution" is appreciated.
Career Survey
First 500 qualified respondents will receive a $20 gift card! Tell us about your professional Splunk journey.

Can’t make it to .conf25? Join us online!

Get Updates on the Splunk Community!

What Is Splunk? Here’s What You Can Do with Splunk

Hey Splunk Community, we know you know Splunk. You likely leverage its unparalleled ability to ingest, index, ...

Level Up Your .conf25: Splunk Arcade Comes to Boston

With .conf25 right around the corner in Boston, there’s a lot to look forward to — inspiring keynotes, ...

Manual Instrumentation with Splunk Observability Cloud: How to Instrument Frontend ...

Although it might seem daunting, as we’ve seen in this series, manual instrumentation can be straightforward ...