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
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.conffile and start fresh with the forwarder management interface, using it to recreate your server classes and other settings.
- Edit your existing
serverclass.conffile 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
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.
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.
|filterType||whitelist (forwarder management implicitly uses this default value)||Unsupported||Unsupported||Unsupported|
|stateOnClient||enabled||Unsupported||Single per-app setting across all server classes|
|restartSplunkd||False||Unsupported||Single per-app setting across all server classes|
Notes regarding entries in the table:
- n/a: This means that the attribute cannot be set at that level in
- Single per-app setting across all server classes: The
restartSplunkdattributes are configured under the app-level stanzas. App-level stanzas include both an
serverClassNamecomponent, 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:Y:app:A]must both configure
stateOnClientidentically. The same condition applies to
Use serverclass.conf to define server classes
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.1.0, 9.1.1, 9.1.2