Splunk® Enterprise

Updating Splunk Enterprise Instances

Acrobat logo Download manual as PDF


Acrobat logo Download topic as PDF

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.
Last modified on 19 December, 2015
PREVIOUS
Use serverclass.conf to define server classes
  NEXT
Extended example: Deploy configurations to several forwarders

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


Was this documentation topic helpful?


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