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------
I too have similar problem.
where i have deployment server, which is a unix system and deployment client as windows.
File permission on unix system for 'rename_app' is drwxrwxrwx .
When i deploy the 'renameapp' from unix system, i am getting 'access issue' for 'renameapp' folder.
interval = 30
disabled = false
If the issue is file permission in window, how to set the permission of window folder/file from unix server. Please advise.
I just run in to the same issue.
Deployment host is on Linux, client is on Solaris. While it seems to work on systems using ZFS, it does not seem to work on UFS.
Untaring the bundle (with Solaris' tar) from /opt/splunk/var/run/ime/solaris-1305840239.bundle does in fact preserve the permissions on UFS.
Maybe Splunk uses another tar for this...
did you check the umask on the deployment clients? this can result in very strange file permission when untaring files - read more here http://www.sun.com/bigadmin/content/submitted/umask_permissions.jsp
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.
I can't be sure with a Solaris setup but I think that if you tar a file on the same system you want to deploy to and keep permissions then it should keep the permissions intact when extracting to the same type of system as long as that tar file had not been repackaged on another system. It would be great to find out how that works on Solaris though 🙂
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.
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
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.
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?