I'm having the same issue documented here http://www.splunk.com/support/forum:SplunkGeneral/3130
"An example is the Unix app. When this app is pushed to a Splunk instance using the deployment server the scripts under unix/bin lose their execute permissions."
The permissions on the deployment server are -r-xr-xr-x but on the client they become -rw------
Are you having issues with scripts not being runnable after deployed by the Deployment Server? Or are you having issues with the Deploy Server not updating the apps on the client properly?
Deploy server updates the apps just fine, but they aren't runnable after being deployed by the deployment server.
I heard this was some type of feature, so that a malicious person cod not make a new app with a malicious script inside it that could be deployed onto a deployment client and run to do malicious tasks on your server.
Seems like chaff, since the purpose of deployment server would be to do exactly this, and it would presumably be controlled at least as well as the clients themselves. If it happens, it's a bug.
We stepped through this exercise with Support's help and it seems to be an issue when deploying form Windows.
We were only interested in deploying the unix app to machines that would act as forwarders, thus the way we solved it was to deploy a "unix-enable" app, which just switched on the inputs on the forwarders.
This wasn't a problem as the unix app was deployed by default as part of the Splunk install and the permissions for the scripts were set correctly.
[script://./bin/cpu.sh] disabled = 0 [script://./bin/df.sh] disabled = 0 [script://./bin/hardware.sh] disabled = 0 [script://./bin/interfaces.sh] disabled = 0 [script://./bin/iostat.sh] disabled = 0 [script://./bin/lastlog.sh] disabled = 0 [script://./bin/lsof.sh] disabled = 0 [script://./bin/netstat.sh] disabled = 0 [script://./bin/openPorts.sh] disabled = 0 [script://./bin/package.sh] disabled = 0 [script://./bin/protocol.sh] disabled = 0 [script://./bin/ps.sh] disabled = 0 [script://./bin/rlog.sh] disabled = 0 [script://./bin/time.sh] disabled = 0 [script://./bin/top.sh] disabled = 0 [script://./bin/usersWithLoginPrivs.sh] disabled = 0 [script://./bin/vmstat.sh] disabled = 0 [script://./bin/who.sh] disabled = 0 [fschange:/etc] disabled = 0 [monitor://~/Library/Logs] disabled = 0 [monitor:///Library/Logs] disabled = 0 [monitor:///var/log] disabled = 0 [monitor:///etc] disabled = 0
Enabling the apps isn't this issue we are seeing, it's granting execute permissions on the scripts.
Just a side note, our deployment server(s) are Solaris servers.
The problem with file permissions and ownership is based on the interpreting file system. This means that if you transfer files from one file system to another that the receiving file system will usually not be able to read the "properties" of the file such ownership and permissions.
To break it down further, if a file has specific permissions and ownership properties on a machine with FAT or NTFS files system and it is transferred to a machine with ext/reiser/hfs/(other *nix variants), then the file properties are typically lost. This same rule applies for a file transfer in the opposite direction (e.g. *nix to Windows) as well.
This file system interpretation issue can sometimes be worked around using tar to keep permissions of files within a tar package intact. However, this would only allow for the files to keep the permissions intact if both the endpoints use a file system that can interpret the same file permission properties. This means that a tar package containing files with permissions from a *nix system will be maintained as long as the files are un-packaged on a *nix system. It doesn't matter if the tar file had been transferred from another file system. Here is an excerpt from the tar man page:
(x mode only) Preserve file permissions. Attempt to restore the full permissions, including owner, file modes, fileflags and ACLs, if available, for each item extracted from the archive. By default, newly-created files are owned by the user running tar, the file mode is restored for newly-created regular files, and all other types of entries receive default permissions. If tar is being run by root, the default is to restore the owner unless the -o option is also specified.
Theoretically, if you were to create a deployment package on Windows using tar to preserve the file permissions, then you could then possibly deploy that package from a *NIX machine as long as the files had not been extracted from the package and re-packaged. The same could be said for a *NIX package created on a *NIX machine but stored on a Windows deployment server.
Then it would simply be a matter of deploying the correct package based on the target OS.
In our case we see the issue when we go from one Solaris (running a ZFS filesystem) to another Solaris box (running a ZFS filesystem). It is mostly a x86 Solaris (deployment server) to SPARC Solaris (deployment clients), but I don't think that would matter.