I'm happy for file copy to be via a BSA App server (which is apparently slow) rather than direct source-to-target copy.
Below Discussions seem to suggest 'cp -M' as a possible solution.
Copy files from one server to another using SSO
Question: In Bladelogic how to copy file/folder from server to server
BladeLogic NSH Script to Copy files from server to NAS
direct copy between bladelogic agent with NSH
But how do you run it?
cp -M //source_target/path/to/filename //destination_target/path/to/destination/folder
...via an NSH SCript Job I get "Error 23/10/2015 3:42:28 PM cp: invalid option -- M"
So 'cp' command doesn't recognise -M switch. How are people getting this to work?
I also tried copying a file from one BSA server to another on the same network (in case of name resolution issues from remote machines) but 'cp' command via NSHScript Job still fails. Same fail result when trying "Set Execution Override" with a BLAdmin account.
Also a "File Deploy Job copies files and directories from a managed server to multiple locations."
Can it do the reverse? i.e. Copy files and directories from multiple locations to a managed server?
what error did you get when you tried to do the cp via a nsh job? this is how you should do the copy.
the cp would not work as a blpackage as the nsh cp is not going to be installed on your targets. a file deploy job will not work because that's a one to many copy, not many to one.
cp -M is to do a remote-to-remote copy, get target to target. that's not your problem here either.
As per OP, the error message returned when running an NSH Script Job is "No such file or directory"
Error 23/10/2015 1:05:50 PM cp: cannot create //bsa_server/filestore/storage/files/myfile/myfile.conf/remotehost_myfile.conf_2015-10-23: No such file or directory
Similarly 'ls' and 'cat' commands fail whenever command //someotherserver is invoked via NSH Script Job. It seems the job cannot run a command from one target to another. These jobs do work on all servers if I limit commands to run locally on the target host. e.g. cp /etc/somefile /tmp/someotherfile
I agree NSH Script Job is what I want to run. The question is why does this job fail for anything that is running a command from one host to another...yet they work perfectly if I run the same commands on a remote host via NSH Here?
Any help would be appreciated as we need to run these commands via a single job rather than some manual process like NSH Here to each host.
can you share the script ? you are running cp directly in the script not nexec'ing it on the target ?
I am running cp directly in the script. The script in NSH Script Job is simply...
cp /etc/myfile/myfile.conf //bsa_server/filestore/storage/files/myfile/myfile.conf/`hostname`_myfile.conf_`date '+%Y-%m-%d'`
Also tried prepending nexec and nexec -e but it made no difference; the job still fails in the same way.
Even making it simple such as cp /etc/somefile //someserver/somefile it always fails. It also fails if you use 'ls //someserver/etc' command or 'cat /etc/somefile > //someserver/somefile'.
Run those same commands via NSH Here and they work every time. I need to know how to make them work via NSH Script Job.
This is a ‘type 1’ nsh job (runscript) ?
the other thing would be to put a 'which cp' in your script and see which cp it's using.
All tests have been using NSH Script set to Type 3.
From BSA 8.6 SP1 doco
Execute the script separately against each host (Type 1)
Execute the script once, passing the host list as a parameter to the script (Type 2)
Copy and execute the script against each host separately (Type 3)
Execute the script using the PERL interpreter, passing the host list as a parameter (Type 4)
"From a performance perspective, Type 3 NSH Script Jobs differ from the other types in that they execute the script on the target instead of the Application Server. However, even for scripts executed on the Application Server, nexec commands are executed on the target."
So is solution simply a matter of setting job to Type 1? If yes, then do I have to modify the script lines at all? i.e. add nexec command or something else?
Also, how do you turn the process spawner ON and OFF for an NSH Script Job? It would be good to test turning it off to confirm this separately-running process is not root cause for the (authentication?) issue I'm experiencing.
right - so type 3 doesn't use nsh, so it's trying to use the native cp command on the target which doesn't work w/ nsh paths. you should use a type 1 job (runscript)
you shouldn't need to change the script. the type 1 will cd to the target so any paths you give are relative to the target.
also - i would not copy stuff into the 'files' directory on the file server, that's reserved to store snapshot contents and if you run db and file server cleanup it's likely that your files will get flagged as orphans and deleted.
Doh - my newbyness has just been exposed big time. Changed NSH Script to Type 1, ran it on a bunch of hosts with a variety of commands...and it worked perfectly on every target! Thank you so much.
Now I have to be very certain of what you said about 'files' location. If I have all BSA servers connecting to central filer storage then is this the files folder you say to put nothing in? If I can't use this location then I wonder which of these folders is safest to store files in long term (maybe Content or depotfiles)? Or conversely, which other folders should I avoid?
make a new directory. or make a new directory outside of the 'storage' folder for what you are doing.
Thanks for the heads-up not to 'manually' put stuff into the 'storage' subfolders. I've made a new directory that's still on the filer but outside of the 'storage' folder for what I am doing. Works fine.
Interestingly, a single host failed on one occasion when testing just now...
Info 24/10/2015 1:42:26 AM Exit Code 1
Info 24/10/2015 1:42:25 AM /opt/bmc/bladelogic/NSH/bin/nsh: Unable to set working directory as "//<hostname><fqdn>".
However repeated testing against that same host is working perfectly. It would be handy to know root cause why above glitch may intermittently occur during an NSH Scripting Job.
i haven't seen that error before. it looks like there is some issue w/ nsh setting the cwd - was there an error or message in the rscd log on that system when this occured ?