Splunk® Enterprise

Distributed Deployment Manual

Download manual as PDF

Splunk version 4.x reached its End of Life on October 1, 2013. Please see the migration information.
This documentation does not apply to the most recent version of Splunk. Click here for the latest version.
Download topic as PDF

Deploy apps and configurations

After configuring the deployment server and clients, you're ready to distribute content to the deployment clients. This involves two steps:

1. Put the new or updated content into deployment directories on the deployment server.

2. Inform the clients that it's time to download new content.

Put the content into directories on the deployment server

You place the deployment apps into individual subdirectories in a special location on the deployment server. From there, the deployment server can push the content to its deployment clients. The default location is $SPLUNK_HOME/etc/deployment-apps, but this is configurable through the repositoryLocation attribute in serverclass.conf. Underneath this location, each app must have its own subdirectory, with the same name as the app itself. The app name is specified in serverclass.conf.

Note: On the deployment clients, the downloaded apps reside in a different location, which defaults to $SPLUNK_HOME/etc/apps. This location is configurable in deploymentclient.conf, but, for most purposes, you should not change it from the default.

This example creates a deployment directory in the default repository location on the deployment server, for an app named "fwd_to_splunk1":

mkdir –p $SPLUNK_HOME/etc/deployment-apps/fwd_to_splunk1/default 

Place the content for each app into the app's subdirectory. To update the app with new or changed content, just add or overwrite the files in the directory.

Inform the clients of new content

When you first configure the deployment server, and whenever you update its configuration by editing serverclass.conf, you'll need to restart or reload it for the changes to take effect. The clients will then pick up any new or changed content. Instead of restarting the server, you can use the CLI reload deploy-server command.

This version of the command checks all server classes for change and notifies the relevant clients:

 splunk reload deploy-server

This version of the command notifies and updates only the server class you specify:

 splunk reload deploy-server -class <server class>

For example:

 splunk reload deploy-server -class www

In this example, the command notifies and updates only the clients that are members of the "www" server class.

Confirm the deployment update

To confirm that all clients received the configuration correctly, run this command from the deployment server:

 splunk list deploy-clients

This lists all the deployment clients that have contacted the deployment server within the last two minutes. It specifies the last time that they successfully synced.

App management issues

Once you start using the deployment server to manage an app, you cannot later stop using the deployment server to manage the app. It is important to understand the implications of this.

If you remove an app from the deployment server's repositoryLocation (defined in serverclass.conf), the deployment client will delete its copy of the app. There is no way instead to tell the deployment client to start managing the app on its own.

For example, say you are using the deployment server to manage updates to "appA". To do this, you have created a directory called "appA" in the repositoryLocation on the deployment server and you have placed the app's contents there. From now on, whenever the deployment clients poll the server to check for updates, they compare their checksum for appA with the server's checksum for appA. If the checksums differ, the clients download the latest version of the app from the server. However, if appA has been deleted from the server's app repository, the client behavior is to delete their own instances of the app.

Therefore, by deleting an app from the deployment server's repositoryLocation, you are not telling the clients to stop using the deployment server to manage the app and to start managing it on their own. Instead, you're actually telling them to delete the app. Once the deployment server manages an app, it always manages that app.

Warning: Because of this behavior, you should be extremely cautious before deciding to use the deployment server to manage the Splunk search app. By managing the search app through the deployment server, you are preventing users from saving any unique searches on their search heads. And since there's no way to tell the deployment server to stop managing an app, you're effectively stuck with that decision.

PREVIOUS
Define server classes
  NEXT
Extended example: deploy configurations to several forwarders

This documentation applies to the following versions of Splunk® Enterprise: 4.3, 4.3.1, 4.3.2, 4.3.3, 4.3.4, 4.3.5, 4.3.6, 4.3.7, 5.0, 5.0.1, 5.0.2, 5.0.3, 5.0.4, 5.0.5, 5.0.6, 5.0.7, 5.0.8, 5.0.9, 5.0.10, 5.0.11, 5.0.12, 5.0.13, 5.0.14, 5.0.15, 5.0.16, 5.0.17, 5.0.18


Was this documentation topic helpful?

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

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

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