|
|
A summary hint of rsync-related information
***LONG POST WARNING ***
I thought I'd just relate the results of my successful experimentation with RsyncX and the RsyncxCD - and this seems like the right place to do it... I've had a lot of success with spot synchronisations with a module/mount point on a server and, more recently, installing entire system images with RsynxCD (latest version 2 I think). With the CD I have been able to boot up all "New World" machines (well back to a Grey G4 single 450) and install the same system image and it works perfectly. At 100Mbps it takes about 8 minutes to download the image, bless and reboot. Unfortunately it takes about 5 minutes to boot up from the CD on a Grey G4 450! I've installed the rsyncX (version 2.6.0) executable in place of the standard /usr/bin/rsync on a standard client system and on a server machine configured to run as a daemon. For the server daemon (simply invoked with the --daemon switch) I used the RsyncX utility/wizard that steps you through the creation of the required rsyncd.conf and rsyncd.secrets file, but basically they are like: /etc/rsyncd.conf (chown'd by root:wheel and readable by others): secrets file = /etc/rsyncd.secrets read inly= yes list = yes uid = root gid = wheel [TestMod] auth users = rsyncx_usera, rsyncx_userb path = /Applications /etc/rsyncd.secrets (chown'd by root:wheel and NOT readable by others): #rsyncd secrets file rsyncx_usera:usera_password rsyncx_userb:userb_password Now if the client has a password file (root readable only or rsync complains) you can run the following script on a client without any user intervention: /usr/bin/rsync -a -c -z "rsyncx_usera@server_address::TestMod/" \ /Volumes/Work/NewTestApps --eahfs --showtogo --password-file /Library/Management/rsync_password This syncs the clients "/Volumes/Work/NewTestApps" folder with the server's "Module"/share point (in the above case the Applications folder). Pretty useful and pretty quick - it took a couple of minutes to take an inventory, and about 40 seconds to upload a large adobe application . However I have occasionally hit file number limits (previously mentioned) - only on v large transfers, and it is solved by a second run. I haven't found any file limit problems with the technique of pushing/pulling loadsets. I did have to enable root user on the server though. Without root, the copying was imperfect. Here I used scripts from the University of Michigan's macosxlabs pages. To push a loadset: rsync --eahfs -qe ssh root@server_address:'`mkdir -p "/loadsets/1/Network" \ "/loadsets/1/private" "/Homes/loadsets/1/private/tmp" "/Homes/loadsets/1/dev" \ "/loadsets/1/private/var" "/loadsets/1/private/var/run" "/loadsets/1/Volumes"`' time sudo rsync -a --eahfs --exclude "/private/var/automount*" --exclude "/dev*" \ --exclude "/private/tmp*" --exclude "/Network*" --exclude "/Volumes*" \ --exclude "/private/var/run*" -e ssh /. "root@server_address:/loadsets/1" --showtogo Pretty much all I added to the scripts at the link above is the crucial --eahfs switch, which adds the all important hfs+ support. (I also added the automount exclusion - don't know if I needed that). Now booting from the RsyncXCD you can initialise the hard disk and pull down the loadset with: time rsync --eahfs -a -z -e ssh "root@server_address:/loadsets/1/" \ "/Volumes/OS X" --delete --showtogo bless -folder "/Volumes/OS X/System/Library/CoreServices" -bootinfo "/Volumes/OS X/usr/standalone/ppc/bootx.bootinfo set the System Disk in System Preferences and restart the machine. Done. Like I say, about 8 minutes at 100Mbps |
SearchFrom our Sponsor...Latest Mountain Lion HintsWhat's New:HintsNo new hintsComments last 2 daysLinks last 2 weeksNo recent new linksWhat's New in the Forums?
Hints by TopicNews from Macworld
From Our Sponsors |
|
Copyright © 2014 IDG Consumer & SMB (Privacy Policy) Contact Us All trademarks and copyrights on this page are owned by their respective owners. |
Visit other IDG sites: |
|
|
|
Created this page in 0.09 seconds |
|