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 | Attributes defined here pertain to just the server class <serverClassName>.Note: |
[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 |
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".
Last modified on 09 July, 2015
| Use forwarder management to manage clients | Compatibility and forwarder management |
This documentation applies to the following versions of Splunk® Enterprise: 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.0.10, 7.0.11, 7.0.13, 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.1.8, 7.1.9, 7.1.10, 7.2.0, 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.5, 7.2.6, 7.2.7, 7.2.8, 7.2.9, 7.2.10, 7.3.0, 7.3.1, 7.3.2, 7.3.3, 7.3.4, 7.3.5, 7.3.6, 7.3.7, 7.3.8, 7.3.9, 8.0.0, 8.0.1, 8.0.2, 8.0.3, 8.0.4, 8.0.5, 8.0.6, 8.0.7, 8.0.8, 8.0.9, 8.0.10, 8.1.0, 8.1.1, 8.1.2, 8.1.3, 8.1.4, 8.1.5, 8.1.6, 8.1.7, 8.1.8, 8.1.9, 8.1.10, 8.1.11, 8.1.12, 8.1.13, 8.1.14, 8.2.0, 8.2.1, 8.2.2, 8.2.3, 8.2.4, 8.2.5, 8.2.6, 8.2.7, 8.2.8, 8.2.9, 8.2.10, 8.2.11, 8.2.12, 9.0.0, 9.0.1, 9.0.2, 9.0.3, 9.0.4, 9.0.5, 9.0.6, 9.0.7, 9.0.8, 9.0.9, 9.1.0, 9.1.1, 9.1.2, 9.1.3, 9.1.4, 9.2.0, 9.2.1
