When editing server classes in the Splunk GUI, it cannot handle a comma in a regex. EG:
\w{3}\d{1,3}\w
Ends up being broken up into two different whitelists in the serverclass.conf file.
Is this a bug?
The documentation says:
These patterns are PCRE regular
expressions
Apart from the caveat it then follows this statement with, where does it say anything about other limitation?
The specific syntax work perfectly in the conf file. The question I asked was about the behaviour of Splunk GUI config page wrongly interpreting the commas inside the regex as a delimiter. So you haven't really answered the question.
The documentation says:
These patterns are PCRE regular
expressions
Apart from the caveat it then follows this statement with, where does it say anything about other limitation?
The specific syntax work perfectly in the conf file. The question I asked was about the behaviour of Splunk GUI config page wrongly interpreting the commas inside the regex as a delimiter. So you haven't really answered the question.
I had a case open with Splunk support on this, and was told it was a potential defect in the UI. I worked around it; you could use \w{3}\d\d?\d?\w instead of \w{3}\d{1,3}\w
Clunky, but it works...
Yeah I did the same as I realised I should have been using ? instead of {0,1}.
It would be great if you posted any fix they provide to you. Thanks for the reply
Refer to the spec file for serverclass.conf, you cannot use full PCRE regex expressions in the whitelist / blacklists..
http://docs.splunk.com/Documentation/Splunk/latest/Admin/Serverclassconf
whitelist. = | |
blacklist. = | |
* 'n' is a number starting at 0, and increasing by 1. Splunk stops evaluating a filter at the first break in sequence of 'n' values.
* 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
* All of these can be used with wildcards. * will match any sequence of characters. For example:
* Match a network range: 10.1.1.*
* Match a domain: *.splunk.com
* Can be overridden at the serverClass level, and the serverClass:app level.
* There are no whitelist or blacklist entries by default.
* These patterns are PCRE regular expressions, with the following aids for easier entry:
* You can specify simply '.' to mean '\.'
* You can specify simply '*' to mean '.*'
* Matches are always case-insensitive; you do not need to specify the '(?i)' prefix.
# Note: Overriding one type of filter (whitelist/blacklist) causes the other to
# be overridden (and hence not inherited from parent) too.
# Example with filterType=whitelist:
# whitelist.0=*.splunk.com
# blacklist.0=printer.splunk.com
# blacklist.1=scanner.splunk.com
# This will cause all hosts in splunk.com, except 'printer' and 'scanner', to match this server class.
# Example with filterType=blacklist:
# blacklist.0=*
# whitelist.0=*.web.splunk.com
# whitelist.1=*.linux.splunk.com
# This will cause only the 'web' and 'linux' hosts to match the server class. No other hosts will match.