We are using the Splunk Add-on for Unix on all of our Unix and Linux servers. But lots of the scripts are quit old and fail on new operating releases like Solaris 11 whit ldoms and Zones, Redhat 7, Oracle Linux. We have adopted some of the scripts, but is quit a tedious work. Has Splunk some plans to update this app, or are there other people around which face the same issue and are interested in some form of collaboration in updating this scripts? Fritz ... View more

It is not official supported, but we have to try to change secret.conf on a few thousand universal forwarders. A complete deinstallation and a new installation is not an option as this would reread all the log files we are indexing. We must do this as we are no longer allowed to have the clear text passwords of certificates in our apps we are deploying. The Steps would be: upgrade the universal forwarder from 5.x and 6.x to 6.4.3 (replaces all the binaries) change deploymentclient.conf to point to a new deployment server. This new deployment server will provide the same apps as the old one, but has hashes matching the newly installed splunk.secret instead of the clear text passwords. replyce the splunk.secret (and the password file) restart the universal forwarder. The follwoing command seem to work: export SPLUNK_HOME=/opt/splunkforwarder cp <file with defined secret> $SPLUNK_HOME/etc/auth/splunk.secret rm ${SPLUNK_HOME}/etc/auth/ca.pem rm ${SPLUNK_HOME}/etc/auth/ca.srl rm ${SPLUNK_HOME}/etc/auth/cacert.pem rm ${SPLUNK_HOME}/etc/auth/server.pem rm ${SPLUNK_HOME}/etc/system/local/server.conf touch ${SPLUNK_HOME}/ftr <update deploymentcleint.conf> /opt/splunkforwarder/bin/splunk start --accept-license --answer-yes --auto-ports This removes anything with hashed passwords except the ones in our apps which we replace afterwards, and forces the universal forwarder to recreate them on the start as it behaves like a first start. Its ugly, but seems to work in a test environment, do we have to expect any gotchas from this? ... View more

in case I have an event which does not describe a relation between two systems, e.g. the size of an Oracle table space or a filesystem size, should I use src_host or dest_host (or the other src/dest fields) for the host field in this events? I never did find a clear statement in the documentation regarding these fields. ... View more

I'm trying to extract data from events which contain a table: RAW Data Table # | INST_ID | STATISTIC | VALUE 1 | 1 | DDL Initiated | 3786 2 | 1 | DDL Initiated (IPQ) | 0 3 | 1 | DFO Trees | 24036 4 | 1 | DML Initiated | 0 5 | 1 | DML Initiated (IPQ) | 0 6 | 1 | Distr Msgs Recv'd | 0 multikv.conf [ops_db_ora_mkv] header.linecount = 1 header.start_offset = 1 header.tokens = _tokenize_, -1,"|" body.start_offset=2 body.tokens = _tokenize_, 0,"|" Search String .... | multikv conf=ops_db_ora_mkv fields STATISTIC | eval s=if(isnull(STATISTIC),"isnull",STATISTIC) Result Field Value VALUE 3786 INST_ID 1 # 1 STATISTIC DDL Initiated linecount 1 s isnull The field STATISTIC, like the other fields, contains a value, but if I use it somewhere it is NULL, do I need another syntax to access this fields? ... View more

I have a script which runs on the deployment server and maintains the contents of ../deployment-apps/... out of a git repository. After any change, it should reload the deployment server and thus needs some credentials. I can of course create a local user inside of Splunk just for this purpose, but it seems I have to grant this user admin privileges. I would have to store this user and its password in the script. If someone gets hold of this script, this person has the credentials with grant admin privileges to the deployment server, not really desired. Preferred behavior would be to have a user in Splunk which allows access only from the local host via CLI, and only if executed from the same OS user under which splunkd is running. This would eliminate the risks as only one local user is able to use it, and this OS user is able to restart splunkd anyway. Another solution would be to have a user which is limited to just the local CLI. Not as secure as above, but at least remote access would be excluded. ... View more