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.

Examples

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".