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…).

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.