Define server classes

Define server classes

A server class defines a set of content that you want the deployment server to deploy to one or more deployment clients. This content can be made up of applications, system configurations, and other related content, such as scripts, images, and supporting material.

(A deployment client has its own configuration, defined in deploymentclient.conf. The information in deploymentclient.conf tells that deployment client where to go to get the content that the server class it belongs to says it should have.)

You can define different server classes to reflect the different requirements, OSes, and purposes of your deployment clients.

You define server classes in serverclass.conf on your deployment server. There isn't a serverclass.conf file by default, so you will create one in $SPLUNK_HOME/etc/system/local and define your server classes in it.

Important: Once you've created a serverclass.conf, you must restart Splunk for the configurations you've defined to take effect.

If you have multiple server classes, you might want to define a global, or general server class instance that applies to all deployment clients by default, and then override various aspects of it as needed in individual, more specific server classes. For example, you might want to specify that in general, all your deployment clients pick up their content from one location, but that one subset of them picks up from a different location.

Important: All configuration information is evaluated numerically and then alphabetically (0-9, then a-z) in the configuration file, so nomenclature matters.

What you can define for a server class

You can specify the settings described here for the global server class as well as for individual server classes. To define a global server class, create a stanza called [global]. To define a more specific server class, create a stanza named for that server class: [serverClass:<serverClassName>], where serverClassName is the name you want to give your server class.

Note: The most accurate and up-to-date list of settings available for a given configuration file is in the .spec file for that configuration file. You can find the latest version of the .spec and .example files in the Configuration file reference in this manual, or in $SPLUNK_HOME/etc/system/README.

repositoryLocation

This is both the location on the deployment server where the content to be deployed for this server class is stored, and by default is also where it will end up when it is deployed to the client. You can override this in deploymentclient.conf. By default, this is $SPLUNK_HOME/etc/deployment-apps.

continueMatching

If you set this to false, the deployment server will look through the list of server classes in this configuration file and stop when it matches the first one. If you set this to true, it will keep looking and matching. This option is available because you can define multiple, layered sets of server classes. The default value is true.

endpoint

This is the HTTP location from which the deployment server will tell the deployment client to retrieve content. The deployment server fills in the variable substitutions itself. You can provide any URI here as long as it uses the same variables. The default value is $deploymentServerUri$/services/streams/deployment?name=$serverClassName$:$appName$

filterType

This is how you tell the deployment server how to filter the layers of configuration information in the global server class definition as opposed to the information in the individually-defined server classes. You can choose to have the items evaluated as whitelist or blacklist entries--if you choose blacklist, for instance, the deployment server will match things that you do not explicitly specify in the blacklist entry filter.

If you don't specify a filter type, it defaults to whitelist.

It's important to remember that you can override this value at the server class level, so if you say at the global level that you're using whitelist, but then for an individual server class, you say you're using blacklist, it overrides the setting completely. You have to provide another filter in that server class definition to replace the one you overrode.

Important: All configuration information is evaluated from top to bottom in the configuration file, so order matters.

Here are some examples: When filterType is whitelist:

whitelist.0=*.fflanda.com
blacklist.0=printer.fflanda.com
blacklist.1=scanner.fflanda.com

This will cause all hosts in fflanda.com, except 'printer' and 'scanner' to match this server class.

When filterType is blacklist:

blacklist.0=*
whitelist.0=*.web.fflanda.com
whitelist.1=*.linux.fflanda.com

This will cause only the 'web' and 'linux' hosts to match the server class. No other hosts will match.

The default value is whitelist.

startBuild and endBuild

This setting allows you to specify a range of Splunk build numbers so that you can either restrict a given server class to only allow or not allow builds in the range. This setting is primarily intended for internal Splunk use at the moment.

stateOnClient

This setting lets you specify whether the deployment client receiving an App should enable or disable that App once it is installed. Options are enabled, disabled, and noop (for Apps that do not require enablement, such as Apps containing only Splunk knowledge such as event or source types).

machineTypes

This setting lets you use the hardware type of the deployment client as a filter. This filter will be used only if a client could not be matched using the whitelist/blacklist filter.

The value here is a specific string that is designated by the hardware platform itself. The method for finding this string on the client itself will vary by platform, but if the deployment client is already connected to the deployment server, you can determine what this string is by using this Splunk CLI command on the deployment server: ./splunk list deploy-clients

This will return a value for utsname that you can use to specify machineTypes.

This setting will match any of the machine types in a comma-delimited list. Commonly used machine types are linux-x86_64, windows-intel, linux-i686, freebsd-i386, darwin-i386, sunos-sun4u, linux-x86_64, sunos-i86pc, freebsd-amd64.

Note: Be sure to include the 's' at the end of "machineTypes"

restartSplunkWeb

<True or False>

restartSplunkd

<True or False>

• Was this topic useful?
• Post a comment