I have a Linux host that is both a deployment server and deployment client in a tiered deployment server configuration. For all of the apps that I am installing into the
$SPLUNK_HOME/etc/deployment-apps directory (received from the primary deployment server using the
targetRepositoryLocation parameter) I constantly receive messages in my splunkd log like the following:
06-11-2012 20:49:11.832 -0400 WARN DeployedApplication - Installing app: uf_win_dev to location: /opt/splunk/etc/deployment-apps/uf_win_dev 06-11-2012 20:49:11.882 -0400 ERROR DeployedApplication - Failed to install app : /opt/splunk/etc/deployment-apps/uf_win_dev. Application does not exist: uf_win_dev 06-11-2012 20:49:11.882 -0400 WARN DeployedServerClass - There was a problem installing app: uf_win_dev for server class: t2-ds
uf_win_dev app folder gets written to
$SPLUNK_HOME/etc/deployment-apps as expected, but constantly gets overwritten every time this host phones home to the primary deployment server and Splunk tries to reinstall the app because it thinks its failing each time. Any ideas what might be happening here? I tried changing some of the log output to DEBUG but didn't see any additional messages relating to it not being able to locate the application.
All Splunk instances in my environment are 4.3.1.
Answering my own question, found the solution in a different thread (finally!)
The implementation of targetRepositoryLocation is buggy (I've since upgraded from 4.3.1 to 5.0.1, problem still exists), so the apps never properly deploy to the second tier deployment server, causing the tier 2 deployment clients to constantly download and install an app with a different checksum, even though the deployment app hasn't changed. I implemented the workaround in the thread above and it seems to work fine now.
I'd like to see this "bug" fixed. Its annoying that you need to put it in etc/apps dir and not somewhere else as dictated by the targetrepositorylocation option. It's makes the tiered deployment servers "messy" as to what is a local app and what is deployed elsewhere. For all intents targetrepositorylocation is broken.
What we've actually done is to make a deployment "bundle" dir inside the app itself that we then refer to as the repository location.
ie. ~/etc/apps/deployment-apps/someotherapptodeploy and have "stateOnClient = disabled".