Splunk® Enterprise

Updating Splunk Enterprise Instances

Download manual as PDF

Download topic as PDF

Use serverclass.conf to define server classes

You can optionally define server classes by directly editing the serverclass.conf configuration file, rather than using the forwarder management interface. More advanced configurations might require you to edit serverclass.conf, because the forwarder management interface only handles a subset of possible configurations. You can also start the configuration process through forwarder management and then switch to directly editing the configuration file to deal with advanced configuration issues.

Important: If you edit serverclass.conf directly, you will likely not be able to return later to configuring via the forwarder management interface. This is because the forwarder management interface can handle only a subset of the configurations possible through serverclass.conf. For details on what changes are compatible with forwarder management, see the topic "Compatibility and forwarder management".

Location for serverclass.conf

Create a serverclass.conf file in $SPLUNK_HOME/etc/system/local on the deployment server. If you have previously defined one or more server classes by means of the forwarder management interface, this file will already exist and you just need to edit or append to it. For information on serverclass.conf, see "The serverclass.conf file".

What you can configure for a server class

The most important settings define the set of deployment clients and the set of apps for each server class. You can set most attributes at any of three stanza levels.

Stanza levels

You can specify settings at the global level, as well as for individual server classes or apps within server classes. There are three levels of stanzas to enable this:

Stanza Meaning Scope
[global] The global level. Attributes defined here pertain to all server classes.
[serverClass:<serverClassName>] An individual server class.

There can be multiple serverClass stanzas - one for each server class.

Attributes defined here pertain to just the server class <serverClassName>.

Note: <serverClassName> cannot contain spaces. In addition, <serverClassName> must be unique across all serverclass.conf files.

[serverClass:<serverClassName>:app:<appName>] App within the named server class. You use this to specify the apps that the server class applies to.

There can be multiple stanzas of this type - one for each app in the server class.

<appname> can be either the name of a single app (usually, its directory name in repositoryLocation) or the wildcard character "*" to specify all apps in repositoryLocation.

Attributes defined here pertain to just the specified deployment app <appName> within <serverClassName> (or to all apps, if "*" is specified).

Attributes are definable at each stanza level, unless otherwise indicated in the serverclass.conf spec file. Attributes in more specific stanzas override less specific stanzas. Therefore, an attribute defined in a [serverClass:<serverClassName>] stanza will override the same attribute defined in [global].

Client filtering attributes

The most common attributes are the ones that configure client filtering. See the topic "Set up client filters" for detailed information on those attributes.

Non-filtering attributes

Most of the non-filtering attributes are rarely changed from their defaults. These ones are of particular interest:

Attribute What it's for Default
repositoryLocation The location on the deployment server where the content to be deployed for this server class is stored. $SPLUNK_HOME/etc /deployment-apps
stateOnClient Set to "enabled", "disabled", or "noop". This setting specifies whether the deployment client receiving an app should enable or disable the app once it is installed. The "noop" value is for apps that do not require enablement; for example, apps containing only event and source types. enabled
restartSplunkWeb Set to "true" or "false". Determines whether the client's Splunk Web restarts after receiving an update. false
restartSplunkd Set to "true" or "false". Determines whether the client's splunkd restarts after receiving an update. false
issueReload Set to "true" or "false". Determines whether the client's splunkd reloads after receiving an update. false

Note: The most accurate and complete list of settings available for a given configuration file is in the .spec file for that configuration file. You can find the latest version of the .spec and .example files for serverclass.conf in serverclass.conf in the Configuration file reference in the Admin manual, or in $SPLUNK_HOME/etc/system/README.

Interaction of restartSplunkd and issueReload

The behavior of the client varies depending on the settings of restartSplunkd and issueReload. These are the options:

issueReload restartSplunkd Behavior
true false Reload only. No restart. It might be necessary to issue a manual restart to fully activate the downloaded apps.
true true Client reloads. If some app components require a restart to activate, the client restarts.
false false The downloaded apps are not activated.
false true The client always restarts after app updates.

These settings are customizable on a server class basis.


For some simple examples of serverclass.conf configurations, see "Set up client filters". In addition, there are several longer and more complete examples presented later in this manual.

Reload the deployment server

In order for changes to take effect, you must reload the deployment server after you add a server class or change its configuration. For example, if you add an app to a server class, the deployment server only deploys the new app to the server class clients after you reload. Similarly, if you change the client filters for a server class, the change in the set of clients (and any subsequent app deployment) only takes effect after you reload.

To reload the deployment server, invoke the CLI reload deploy-server command:

 splunk reload deploy-server

For more information on reloading the deployment server, see the topic "Deploy apps to clients".

Use forwarder management to manage clients
Compatibility and forwarder management

This documentation applies to the following versions of Splunk® Enterprise: 6.3.0, 6.3.1, 6.3.2, 6.3.3, 6.3.4, 6.3.5, 6.3.6, 6.3.7, 6.3.8, 6.3.9, 6.3.10, 6.3.11, 6.3.12, 6.3.13, 6.3.14, 6.4.0, 6.4.1, 6.4.2, 6.4.3, 6.4.4, 6.4.5, 6.4.6, 6.4.7, 6.4.8, 6.4.9, 6.4.10, 6.4.11, 6.5.0, 6.5.1, 6.5.1612 (Splunk Cloud only), 6.5.2, 6.5.3, 6.5.4, 6.5.5, 6.5.6, 6.5.7, 6.5.8, 6.5.9, 6.5.10, 6.6.0, 6.6.1, 6.6.2, 6.6.3, 6.6.4, 6.6.5, 6.6.6, 6.6.7, 6.6.8, 6.6.9, 6.6.10, 6.6.11, 6.6.12, 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.0.5, 7.0.6, 7.0.7, 7.0.8, 7.0.9, 7.1.0, 7.1.1, 7.1.2, 7.1.3, 7.1.4, 7.1.5, 7.1.6, 7.1.7, 7.2.0, 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.5, 7.2.6


It's 2017, we're using Splunk 6.5.2 Enterprise, and I encountered the same problem as Lauraokkanen.
Some server classes and app bindings end up in apps/search/local/serverclass.conf, most are in system/local...
I'm not perfectly sure, but the only difference may be that some of those are Serverclasses that I renamed using the GUI - maybe only the GUI rename function uses the wrong config location?

July 18, 2017

Laurarokkanen -

According to the developer, there hasn't been any code change that would cause forwarder management to stop writing to /etc/system/local and switch to the search app. Also, they tested on 6.3, and it appears that forwarder management is still writing to /etc/system/local.

Probably the best next step would be for you to open a Support case, so that they can examine the details of your particular deployment.

Sgoodman, Splunker
October 15, 2015

hi, it seems the location of serverclass.conf has changed (?) when I edit my configs with forwarder managment the serverclass.conf under etc/system/local is empty, it seems my configs DO appear in a file under etc/apps/search/serverclass.conf

is this intended behavior now? it's pretty confusing

October 9, 2015

Was this documentation topic helpful?

Enter your email address, and someone from the documentation team will respond to you:

Please provide your comments here. Ask a question or make a suggestion.

You must be logged into splunk.com in order to post comments. Log in now.

Please try to keep this discussion focused on the content covered in this documentation topic. If you have a more general question about Splunk functionality or are experiencing a difficulty with Splunk, consider posting a question to Splunkbase Answers.

0 out of 1000 Characters