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.

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.

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.

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.

Comments

SloshBurch - The restartSplunkWeb attribute only affects the ability to initiate a SplunkWeb restart after the app gets downloaded to the client. You can still use restartSplunkd and stateOnClient to manipulate the post-download situation. If you absolutely need restartSplunkWeb, you'll have to work outside the forwarder management interface.

Sgoodman

February 4, 2014

Does this mean that restartSplunkWeb is no longer possible from within the new UI? Is there a recommended best practice/approach that splunk prefers we use for loading the remote config?

SloshBurch

February 4, 2014

Bohrasaurabh - 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 http://docs.splunk.com/Documentation/Splunk/latest/Updating/Useserverclass.conf.) <br /><br />If you're not using forwarder management, you can configure those attributes differently depending on the server class. 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 went it gets downloaded to the client.<br /><br />However, forwarder management allows only a single definition for each app, across all server classes that it's used in. So, [serverClass:X:app:A] and [serverClass:Y:app:A] must both configure stateOnClient identically.

Sgoodman

January 21, 2014

What does - "Single per-app setting across all server classes" mean. Can an example of serverclass.conf be provided which has all supported parameters defined, which works with Forwarder Management.

Enter your email address, and someone from the documentation team will respond to you:

Send me a copy of this feedback

Please provide your comments here. Ask a question or make a suggestion.

Feedback submitted, thanks!

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

Your Comment Has Been Posted Above

We use our own and third-party cookies to provide you with a great online experience. We also use these cookies to improve our products and services, support our marketing campaigns, and advertise to you on our website and other websites. Some cookies may continue to collect information after you have left our website.
Learn more (including how to update your settings) here »