Advanced Deployments - Implementing Splunk: Big Data Reporting and Development for Operational Intelligence - page 355

The startup command must still be run as root, but the startup script will be
modified to run as the user provided.
If you do not run Splunk as root, and you shouldn't if you can
avoid it, be sure that the Splunk installation and data directories
are owned by the user specified in the enable boot-start
command. You can ensure this by using chmod , such as in
chmod -R splunkuser $SPLUNK_HOME
On Linux, you could then start the command using service splunk start .
Using apps to organize configuration
When working with a distributed configuration, there are a number of ways to
organize these configurations. The most obvious approach might be to organize
configurations by machine type. For instance, put all configurations needed by web
servers into one app and all configurations needed by database servers in another
app. The problem with this approach is that any changes that affect both types of
machines must be made in both apps, and mistakes will most likely be made.
The less fragile but more complicated approach is to normalize your configurations,
ensuring that there is only one copy of each configuration spread into multiple apps.
Separate configurations by purpose
Stepping through a typical installation, you would have configuration apps named
like the following:
• inputs-sometype
For some logical set of inputs, you would create an app. You could use
machine purpose, source type, location, operating system, or whatever
makes sense in your situation. Normally, I would expect machine purpose
or source type.
• props-sometype
This grouping should correspond to the grouping of the inputs, more or
less. You may end up with props apps for more than one type, for instance
machine type and location.
• outputs-datacenter
When deploying across data centers, it is common to place Splunk indexers
in each data center. In this case, you would need an app per data center.