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?
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'.
thanks for the input. i had already checked the spec but was hoping someone was aware of a creative workaround.
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'.