Compatibility and the agent management interface
Agent management UI can handle the configuration needs for most agent managements. 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 (agent management UI or direct editing of serverclass.conf), you can skip the rest of this topic. Compatibility issues can arise, however, if you alternate between agent management UI 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 agent management interface provides a key subset of the configuration capabilities available through serverclass.conf. Most configuration needs can be met by working exclusively in agent management UI.
If you have unusually complex requirements, you can start by configuring in agent management UI 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 agent management interface. This is because the agent management interface supports only a subset of the capabilities available through the configuration file.
If you do return to agent management UI after editing serverclass.conf, agent management UI 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 agent 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.
List of incompatibilities
Some serverclass.conf attributes are incompatible with the agent 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 agent management UI.
If your serverclass.conf file contains incompatible attributes, the agent 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 agent management UI.
| 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 (agent 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
stateOnClientandrestartSplunkdattributes are configured under the app-level stanzas. App-level stanzas include both anappNameand aserverClassNamecomponent, like this:[serverClass::app:]. See Use serverclass.conf to define server classes.If you are not using agent management UI, 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 specifystateOnClient=enabled, while in[serverClass:Y:app:A](same app, different server class), you can specifystateOnClient=disabled. So, depending on the server class, the same app will be either enabled or disabled when it gets downloaded to the agent.However, agent management UI 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 configurestateOnClientidentically. The same condition applies torestartSplunkd.