API 4TW

Ok, here’s a real blog post to make up for that last one. You may have heard that one of the major features of Splunk 4.0 is a brand new REST API. This is the interface that both the CLI and the web UI use to manage Splunk inputs, retrieve splunkd status, perform searches, etc. You, too, can use this API for doing all sorts of good or evil - read on.

Explore a bit…

Exploring it is easy - point Firefox at your your local Splunk instance’s management port. For example, https://localhost:8089/services is the default. Adjust https vs http as necessary, as well as the port. Note that this is the management port, not the web interface port (which is 8000 by default).

In a decent browser (my favorite, Konqueror, doesn’t seem to cut it :( ), you’ll see a list of links, with smaller links beneath each. This is just a user-friendly rendering of our Atom XML feed. View the raw XML by right clicking and choosing View Source, if you wish.

Reload 4 Auth

This will be a very brief post, to fulfill my obligations. I’ll share something a little more informative, perhaps even more interesting, in an upcoming post (soon… I promise (kinda) this time).

As of Splunk 4.0, our old somewhat-of-an-API has been replaced with an entirely new REST API, invalidating my old post on reloading authentication from the command line.

Sooo….. in 4.x, you can restart the authentication system with the following command:

$ splunk _internal call /authentication/providers/services/_reload -auth admin:changeme

Any errors should be obvious in the resulting XML. As of 4.0.3, you’ll also get a non-zero return code upon receiving errors from the API. And I’ve filed a bug (just now) to expose this as a real CLI command, so soon this post will no longer be very important. :)


Happy now, Simeon?

Reloading the auth system via CLI

Note: Tina pointed out that this does not apply to the authorize.conf file. This will be fixed in an upcoming version of splunk.

This comes up every once in a while on the support channel (EFnet/#splunk), so I guess that means I should do a blog post on it.

If you’re making changes to the authentication.conf file and want to reload Splunk’s auth system without going through the web UI, you can use one of our internal functions to do it at the command line:

$ splunk _internal rpc-auth ‘<call name=”syncAuth”><params/></call>’

This fires off the same call that the UI would use to reload the auth system, so it functions identically. Note that this is an authenticated call, so you’ll need to use one of the standard authentication methods (-auth, splunk login, or the SPLUNK_USERNAME/SPLUNK_PASSWORD env vars…).

Saving the environment, one beer pong game at a time.

Recycling is universally considered to be a good thing, right?

Good. Then that means that we at Splunk are obligated to play play beer pong every Friday! I figure that with all the bottles and cans that subsequently go into the recycling bin, we’re probably offsetting a small percentage of the many computers we use here… amirite?

Al Gore would be proud

If you disagree, you can voice your opinions in person. See you here Friday at 5PM. ;)

Things you don’t want to hear at work

Lots of things are said here that are… hmm, what’s the word… inappropriate? disgusting? TMI? omgwtfbbq?

My boss just told me, “Amrit, I have a camera on my computer. And when I’m at home, anytime you want, I can turn on the camera and you can watch.”

There was more, but I think my ears reflexively closed in on themselves.

do not want

:/

Administering remote Splunk servers via the CLI

It’s a little known (mainly because it’s undocumented) fact that it is possible to use the Splunk CLI to manage remote Splunk servers. This capability has been built into the product since version 2.1, and allows one to do things such as remotely manage data inputs, run searches, manage users, etc. For fairly obvious reasons, this cannot be done with commands that require Splunkd to be stopped.

The syntax is simple:

/opt/splunk/bin/splunk <command> [<subcommand>] <params> -uri https://my2ndSplunkBox:8089

The key here is the -uri parameter, which instructs the PCL to send all SOAP requests to the specified server. There are 3 pieces to the parameter: protocol, host, and port.

The protocol must be one of http or https, depending on whether or not SSL is enabled on the Splunkd port. Most users will want the latter, as recent versions of Splunk enable SSL on this port by default.

The second part is the hostname or IP address of the host that the remote Splunk server is running on. This should need no real explanation - in this case, the remote server has the hostname my2ndSplunkBox.

HI@WEB2.0

Well, I guess I had to start “blogging” eventually…

Hi, I’m Amrit, the main CLI (Command Line Interface) and PCL (Python Control Layer) guy here at Splunk. This means that I maintain our more common bash scripts (bin/splunk & friends), and our Python support scripts (site-packages/splunk/clilib/), which do the heavy lifting for a number of CLI & Web UI features.

These aren’t the only things I work on, but they are the parts of the Splunk codebase that have consumed most of my time since starting here in December 2005. I should also mention that Ivan Tam (no blog.. yet..?), who now works on the SplunkWeb UI, helped write the first implementation of the PCL during mid-2006.

Every now and then I’ll post some tips & tricks related to the things I’m working on, which you’ll hopefully find useful.

KTHXBAI