Programatically Copying - Zip file from Mac to Dropbox type Folder on OS X Server...

dgreening
Valued Contributor II

I have written a script to gather a bunch of fairly generic information from System Profiler and various log files, write it to a text file, and then zip up the text file in preparation for uploading to a drop box (write only) folder on an OS X file server.

I need to figure out how to programatically authenticate to the file server and copy the zip file over. I can't seem to get scp to work, as it would require a public/private key pair, and wont simply let me pass username and password into the command. This command needs to be totally hands-off for the user, as we are running this in the background. There is nothing sensitive or of security concern in the zipped up text, so I don't mind it being passed unencrypted to the file server. The user to be used for the copy would be write-only.

Ideas?

1 ACCEPTED SOLUTION

ShaunRMiller83
Contributor III

You should have a look at the script in this JamfNation post.

You could easily modify the script to fit your needs but the overall function and syntax will do exactly what you're looking for.

View solution in original post

11 REPLIES 11

ShaunRMiller83
Contributor III

You should have a look at the script in this JamfNation post.

You could easily modify the script to fit your needs but the overall function and syntax will do exactly what you're looking for.

dgreening
Valued Contributor II

Excellent. I have this mostly working but am getting an error from rsync. The files DO transfer, I'd like to do away with this error though:

Copying Data for Hostname: BOSDGREEN47366-2015-08-24
BOSDGREEN47366-2015-08-24.zip 7935233 100% 39.46MB/s 0:00:00 (xfer#1, to-check=0/1)
rsync: chgrp "/Volumes/Files/.BOSDGREEN47366-2015-08-24.zip.YI1yxi" failed: Operation not permitted (1)

sent 7938028 bytes received 42 bytes 5292046.67 bytes/sec
total size is 7935233 speedup is 1.00
rsync error: some files could not be transferred (code 23) at /SourceCache/rsync/rsync-45/rsync/main.c(992) [sender=2.6.9]
bash-3.2#

ShaunRMiller83
Contributor III

Are you manually running the script or thru running it thru Casper? I'm betting manually because I've seen that before when running manually. The issue went away when it ran thru the JSS since scripts are run as root.

Shaun

dgreening
Valued Contributor II

Aha! Yes, I am running it locally for now. I'll upload it to the JSS and see what happens. Thanks for the help! Much appreciated!

ShaunRMiller83
Contributor III

Happy to help... Let me know how the testing goes!!

Just for awareness the error you're seeing is an rsync perms error and depending on the switches you are using in the rsync command will display or suppress the error. I never looked into it more since it worked as far as I could tell from the JSS.

dgreening
Valued Contributor II

Hmmm I am seeing the same error when run via the JSS:

Copying Data for Hostname: BOSDGREEN47366-C02M7AB3FD57-2015-08-24
BOSDGREEN47366-C02M7AB3FD57-2015-08-24.zip
32768 0% 0.00kB/s 0:00:00
7968490 100% 42.28MB/s 0:00:00 (xfer#1, to-check=0/1)
rsync: chgrp "/Volumes/Files/.BOSDGREEN47366-C02M7AB3FD57-2015-08-24.zip.r3I3rD" failed: Operation not permitted (1)

sent 7971309 bytes received 42 bytes 15942702.00 bytes/sec
total size is 7968490 speedup is 1.00
rsync error: some files could not be transferred (code 23) at /SourceCache/rsync/rsync-45/rsync/main.c(992) [sender=2.6.9]
Finished Copying Data for Hostname: BOSDGREEN47366-C02M7AB3FD57-2015-08-24

dgreening
Valued Contributor II

I did find that if I used

rsync --ignore-errors --force --progress /"$DESTDIR"/"$CNAME"-"$serial"-"$DATE".zip /Volumes/Files

that worked with a successful policy log in the JSS.

If I used rsync -vzog --ignore-errors --force --progress /"$DESTDIR"/"$CNAME"-"$DATE".zip /Volumes/Files

that results in a failed policy log, though it does complete.

ShaunRMiller83
Contributor III

Ahhh those details help a bit more to see what's going on... using the RSYNC switch -vzog means:

V - Verbose Z - Compress
O - Preserve Owner
G - Preserve Group

Without using those switches the file would get stripped of those settings and sounds like that is working without issue and inheriting whatever permissions are on the target drive. If retaining those parameters isn't important than the top command would work just fine.

If those are important you will need to find out why keeping those parameters is throwing up log errors.

dgreening
Valued Contributor II

The permissions really don't matter to me as I am going to chmod -r 777 the destination directory before supply the collected data to anyone.

ShaunRMiller83
Contributor III

So it sounds like using the top command works and should get you what you need then unless I'm missing something.

dgreening
Valued Contributor II

Yes it sure does! I am testing the complete script out on my local support guys as we speak! Thanks again for the help!