Compatibility and forwarder management

Forwarder management can handle the configuration needs for most deployment servers. However, if you have complex requirements, you might still need to edit serverclass.conf.

If you do all your configuration in one tool or the other (forwarder management or direct editing of serverclass.conf), you can skip the rest of this topic. Compatibility issues can arise, however, if you alternate between forwarder management and the configuration file, performing configuration through both interfaces.

For information on directly configuring serverclass.conf, read Use serverclass.conf to define server classes.

Compatibility works in one direction only

The forwarder management interface provides a key subset of the configuration capabilities available through serverclass.conf. Most configuration needs can be met by working exclusively in forwarder management.

If you have unusually complex requirements, you can start by configuring in forwarder management and then switch to serverclass.conf for advanced configuration. However, once you start editing the configuration file directly, there is a strong likelihood that you will not be able to later return to configuring via the forwarder management interface. This is because the forwarder management interface supports only a subset of the capabilities available through the configuration file.

If you do return to forwarder management after editing serverclass.conf, forwarder management will detect any incompatibilities and generate error messages in appropriate locations in the interface. As long as the incompatibilities persist, you will not be able to configure via the forwarder management interface.

Even if you can no longer use the interface to edit configurations, you can still use it to monitor the deployment. It will correctly show the mappings between apps, clients, and server classes. It will also correctly report the deployment metrics.

Upgrade from a pre-6.0 deployment server

If you have configured serverclass.conf in a pre-6.0 release of Splunk Enterprise (that is, before the forwarder management interface was introduced), you might have introduced incompatibilities that prevent the forwarder management interface from functioning properly after you upgrade to 6.0. When you first view the forwarder management interface, it will detect any incompatibilities and generate error messages as needed. As long as incompatibilities exist, you will not be able to configure via forwarder management.

If incompatibilities are detected but you want to use the forwarder management interface going forward, you need to do one of two things:

• Remove the existing serverclass.conf file and start fresh with the forwarder management interface, using it to recreate your server classes and other settings.
• Edit your existing serverclass.conf file directly, so that it conforms strictly to the capabilities of the forwarder management interface. This should be possible in most situations. If you want to do this, see the following section for a list of the key incompatibilities that you need to account for.

Important: Whether forwarder management can handle your configuration depends on your specific needs.

List of incompatibilities

Some serverclass.conf attributes are incompatible with the forwarder management interface. In addition, some attributes can be set at multiple levels (global, server class, and app) in the configuration file but are only allowable at a single level with forwarder management.

If your serverclass.conf file contains incompatible attributes, the forwarder management interface goes into lock-down mode. You cannot use it for configuration purposes until the incompatibilities are resolved.

This table correlates the serverclass.conf attributes with their support in forwarder management.

Attribute	Default	Global	Server Class	App
repositoryLocation	$SPLUNK_HOME/etc/deployment-apps	Supported	Unsupported	n/a
targetRepositoryLocation	$SPLUNK_HOME/etc/apps	Unsupported	n/a	n/a
tmpFolder	$SPLUNK_HOME/var/run/tmp	Unsupported	n/a	n/a
continueMatching	True	Unsupported	Unsupported	n/a
endpoint	$deploymentServerUri$/services/streams/deployment?name=$serverClassName$:$appName$	Unsupported	Unsupported	n/a
filterType	whitelist (forwarder management implicitly uses this default value)	Unsupported	Unsupported	Unsupported
whitelist	none	Unsupported	Supported	Unsupported
blacklist	none	Unsupported	Supported	Unsupported
whitelist.from_pathname	none	Unsupported	Supported	Unsupported
blacklist.from_pathname	none	Unsupported	Supported	Unsupported
machineTypesFilter	none	Unsupported	Supported	Unsupported
stateOnClient	enabled	Unsupported	Single per-app setting across all server classes
restartSplunkd	False	Unsupported	Single per-app setting across all server classes
issueReload	False	Unsupported	Unsupported	Unsupported
restartSplunkWeb	False	Unsupported	Unsupported	Unsupported
appFile	none	n/a	n/a	Unsupported

Notes regarding entries in the table:

• n/a: This means that the attribute cannot be set at that level in serverclass.conf.

• Single per-app setting across all server classes: The stateOnClient and restartSplunkd attributes are configured under the app-level stanzas. App-level stanzas include both an appName and a serverClassName component, like this: [serverClass::app:]. See Use serverclass.conf to define server classes.
  
  If you are not using forwarder management, you can configure those attributes differently depending on the server class, even for the same app. For example, in [serverClass:X:app:A], you can specify stateOnClient=enabled, while in [serverClass:Y:app:A] (same app, different server class), you can specify stateOnClient=disabled. So, depending on the server class, the same app will be either enabled or disabled when it gets downloaded to the client.
  
  However, forwarder management allows only a single definition for each app, across all server classes in which it is used. So, [serverClass:X:app:A] and [serverClass:Y:app:A] must both configure stateOnClient identically. The same condition applies to restartSplunkd.