Easiest Way to Upgrade Splunk to a New Version

In short, you just install it over the top of the existing install. As a precaution, you could copy everything in /opt/splunk/ before you do the upgrade.

This is a verbatim copy-paste of the easiest way I’ve found to install Splunk. Yeah, you’re literally just overwriting the existing files with the new install. All your configs, index references, searches, apps, etc. will not be touched (provided you don’t have anything particularly custom of course).

I’m using CentOS 6.6, but any Linux variant should work fine.

You want the .tgz file from here (use wget to downoad the file to the /tmp directory on your server):

http://ift.tt/18rHcT7. Mine looked like this:



wget -O splunk-6.2.2-255606-Linux-x86_64.tgz 'http://ift.tt/1FAMGVO'

--2015-02-26 01:30:13-- http://ift.tt/1FAMGVO


Extract splunk and put it in the /opt directory:



tar xvzf splunk-*.tgz -C /opt


Run Splunk for the first time:



/opt/splunk/bin/splunk start --accept-license


Set Splunk to start at boot (just to make sure):



/opt/splunk/bin/splunk enable boot-start


What about changes to props.conf in Splunk Cloud?

I can’t really find anything definitive in the docs (I’m sure there’s something, but my searches were coming up dry… maybe that says something about me though

Anyways, I think you have to submit a support ticket that includes the props.conf additions you want.

Forwarding Logs from Splunk Universal Forwarder to 2 indexers – one Splunk Enterprise and one Splunk Cloud

ejabberd hard crash and caps_features.DAT showing as not a valid file

We had a hard, nasty crash of the VM running Ejabber.

So, we ended up copying all the files in /var/lib/ejabberd to an earlier cloned image of this same machine.

But ejabberd wouldn’t start with ejabberdctl start. It threw this initially:



{error_logger,{{2015,3,5},{21,25,9}},"Error when reading /var/lib/ejabberd/.erlang.cookie: eacces",[]}


Ultimately, the solution to that problem was found in restoring ownership of the /var/lib/ejabberd/.erlang.cookie to ejabber_user:ejabber_user.

Then, another problem came up, and the only way we found what it was was by running ejabberctl live and watching the output. Here was the output:



** FATAL ** {error,{"Cannot open dets table",caps_features,

[{file,"/var/lib/ejabberd/caps_features.DAT"},


Well, after opening up this file and comparing with another file from an instance that was running, we tried simply renaming it to caps_features.DAT.bak and starting up ejabberd. And it worked.

caps_features.DAT seems to not be critical data – it appears to just be info on clients; and it can be rebuilt over time.

How to Call a Stored Procedure from a View in SQL Server