Re: rsync approach
On Wed, 27 May 2009 15:03:30 -0700, prad p...@towardsfreedom.com said: P We are thinking of rsync to duplicate 1st [box] 2nd [box] (with the P exception of rc.conf and a few other files of course because we don't P want them to be absolutely identical). P we plan to allow root login and have disabled all password access so P that rsync can preserve permissions. is this a good way to accomplish P the bkp job? If you're going to use root login, I'd suggest access control for ssh via either daemontools or tcpwrappers, and add some extra security by putting 'from=hostname' in root's entry in the authorized_keys2 file: from=1st.box.com ssh-dss B3NzaC1MtH[...]WDXDrq03pE= r...@1st.box.com It's not strictly necessary to allow root connections if you want to keep permissions intact. I use an unprivileged account (bkup) to copy gzipped cpio archives between systems. On the 1st box, root can use pax or cpio to create the archive, and then run something as user bkup to do the copy to the 2nd box: root# cd /some/where root# find . -print | pax -x cpio -wd | gzip -1c /tmp/arch.pax.gz root# su bkup -c scp -c arcfour -i /bkup/.ssh/backuphost_dsa \ /tmp/arch.pax.gz 2nd.box.com:/someplace/bkup/can/write The arcfour cipher will probably give you better throughput. To unpack the files on 2nd.box.com: root# cd /some/where/else root# gunzip -c /someplace/bkup/can/write/arch.pax.gz | pax -rd -pe root# rm /someplace/bkup/can/write/arch.pax.gz If the files you're syncing are huge, you're better off using root login plus rsync. -- Karl Vogel I don't speak for the USAF or my company SUVs are gross because they're the solution to a gross problem: how to make minivans look more masculine. --Paul Graham ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: rsync approach
we have 2 static ip addresses with a machine running 7.2 connected to each. one is the primary server, while the other does only dns and receives bkp dumps from the first. we want to set things up so the 2nd can be brought on line at a moment's notice. therefore, we are thinking of rsync to duplicate 1st 2nd (with the exception of rc.conf and a few other files of course because we don't want them to be absolutely identical). we plan to allow root login and have disabled all password access so that rsync can preserve permissions. i don't catch why disabling password access will allow rsync to preserve permission. It will preserve just when you give proper option is this a good way to accomplish the bkp job? yes it is. There is another way too - having both adventage and disadventage. 1) make an option in FreeBSD loader menu to run ramdisk-freebsd (ramdisk from file). Put on that cutdown ramdisk system only startup of ggated with a disk 2) on main machine run ggatec and gmirror. you will get network mirrored hard disk. make this procedure conditional so it runs only on first machine (for eg check MAC address of your network interface) in case of machine 1 fail, you just run second with normal, instead of ramdisk mode. It has adventage of full realtime replication, but it's disadventage in the same time. For example if you run rsync once per 2 hours, and you by accident delete a lots of things, you can recover. with gmirror way it is instantly replicated so you can't recover ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: rsync approach
On 27 May 2009, at 15:03, prad wrote: we have 2 static ip addresses with a machine running 7.2 connected to each. one is the primary server, while the other does only dns and receives bkp dumps from the first. we want to set things up so the 2nd can be brought on line at a moment's notice. therefore, we are thinking of rsync to duplicate 1st 2nd (with the exception of rc.conf and a few other files of course because we don't want them to be absolutely identical). we plan to allow root login and have disabled all password access so that rsync can preserve permissions. is this a good way to accomplish the bkp job? It might be, but its difficult to say without knowing a lot more about what going on in the system. For example, rsync of large files that change real often can be an issue. You may get an inconsistent copy of the file if it is changing during the update of that file. Rsync does one file at a time. Hence if you have multiple files that need to be consistent between them it might not happen. If transactions changing a file occur between the rsync of the first file and the rsync of the second file, they will not be consistent. I use rsync for basically the same thing you are considering. However, in my situation, the real dynamic files are database files. I don't rsync them. Those are exported every evening and those files are rsync'd. During the day, every application that updates a database file also adds a copy of the new record to the end of a log file. That log file is also rsync'd about every 5 minutes. In this way I can recover to within 5 minutes quite easily. The last 5 minutes might be a bit more work, but the information would be available from the original sources at that point. Allowing root login is generally not a great approach. Rsync will retain permissions (use -p) if the user id's and group ids are the same on both systems. You may have to modify some of the pam files to permit rsync to function easily. The easy test is to rsh other host date If that works and you get the date, then rsync will function properly. If not you need to track down why in the various log files. I had to make the following change: pam.d/rsh: -auth requiredpam_rhosts.so no_warn +auth required pam_rhosts.so no_warnallow_root This was first done quite a few years ago and has been propagated to the current systems so I don't know if its still required or not. Our systems only have 3 users (the administrators) so we have passwords working fine. It has not interfered with rsync. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
