sync cpdup with dragonfly current.

Author: laffer1

bin/cpdup/BACKUPS

@@ -1,5 +1,3 @@
-$DragonFly: src/bin/cpdup/BACKUPS,v 1.4 2007/05/17 08:19:00 swildner Exp $
-
 			    INCREMENTAL BACKUP HOWTO
 
     This document describes one of several ways to set up a LAN backup and
@@ -17,7 +15,8 @@ $DragonFly: src/bin/cpdup/BACKUPS,v 1.4 2007/05/17 08:19:00 swildner Exp $
     The easiest way to create a LAN backup box is to NFS mount all your
     backup clients onto the backup box.  It is also possible to use cpdup's
     remote host feature to access your client boxes but that requires root
-    access to the client boxes and is not described here.
+    access to the client boxes and is not described here.  (But see the
+    sections "OFF-SITE BACKUPS" and "SSH SECURITY TIPS" below.)
 
     Create a directory on the backup machine called /nfs, a subdirectory
     foreach remote client, and subdirectories for each partition on each
@@ -34,7 +33,7 @@ $DragonFly: src/bin/cpdup/BACKUPS,v 1.4 2007/05/17 08:19:00 swildner Exp $
     Before you actually do the NFS mount, create a dummy file for each
     mount point that can be used by scripts to detect when an NFS mount
     has not been done.  Scripts can thus avoid a common failure scenario
-    and not accidently cpdup an empty mount point to the backup partition
+    and not accidentally cpdup an empty mount point to the backup partition
     (destroying that day's backup in the process).
 
 	touch /nfs/box1/home/NOT_MOUNTED
@@ -84,7 +83,7 @@ $DragonFly: src/bin/cpdup/BACKUPS,v 1.4 2007/05/17 08:19:00 swildner Exp $
 			PART 3 - DO AN INCREMENTAL BACKUP
 
     An incremental backup is exactly the same as a level 0 backup EXCEPT
-    you use the -H option to specify the location of the most recent 
+    you use the -H option to specify the location of the most recent
     completed backup.  We simply maintain the handy softlink pointing at
     the most recent completed backup and the cpdup required to do this
     becomes trivial.
@@ -115,7 +114,7 @@ $DragonFly: src/bin/cpdup/BACKUPS,v 1.4 2007/05/17 08:19:00 swildner Exp $
     and copy the file instead.  Generally speaking only a few special cases
     will hit the hardlink limit for a filesystem.  For example, the
     CVS/Root file in a checked out cvs repository is often hardlinked, and
-    the sheer number of hardlinked 'Root' files multiplied by the number 
+    the sheer number of hardlinked 'Root' files multiplied by the number
     of backups can often hit the filesystem hardlink limit.
 
 		    PART 4 - DO AN INCREMENTAL VERIFIED BACKUP
@@ -124,7 +123,7 @@ $DragonFly: src/bin/cpdup/BACKUPS,v 1.4 2007/05/17 08:19:00 swildner Exp $
     might exist on the physical /backup disk in only one place even though
     it may be present in dozens of daily mirrors.  To ensure that the
     file being hardlinked does not get corrupted cpdup's -f option can be
-    used in conjunction with -H to force cpdup to validate the contents 
+    used in conjunction with -H to force cpdup to validate the contents
     of the file, even if all the stat info looks identical.
 
 	cpdup -f -H /backup/mirrors/box1 ...
@@ -136,7 +135,7 @@ $DragonFly: src/bin/cpdup/BACKUPS,v 1.4 2007/05/17 08:19:00 swildner Exp $
     will have a distinct copy of all the file data and you will quickly
     run out of space in your /backup partition.
 
-		    MAINTAINANCE OF THE "/backup" DIRECTORY
+		    MAINTENANCE OF THE "/backup" DIRECTORY
 
     Now, clearly you are going to run out of space in /backup if you keep
     doing this, but you may be surprised at just how many daily incrementals
@@ -153,14 +152,14 @@ $DragonFly: src/bin/cpdup/BACKUPS,v 1.4 2007/05/17 08:19:00 swildner Exp $
     Making an off-site backup involves similar methodology, but you use
     cpdup's remote host capability to generate the backup.  To avoid
     complications it is usually best to take a mirror already generated on
-    your LAN backup box and copy that to the remote box. 
+    your LAN backup box and copy that to the remote box.
 
     The remote backup box does not use NFS, so setup is trivial.  Just
     create your super-large /backup partition and mkdir /backup/mirrors.
     Your LAN backup box will need root access via ssh to your remote backup
-    box.
+    box.  See the section "SSH SECURITY TIPS" below.
 
-    You can use the handy softlink to get the latest 'box1.date' mirror 
+    You can use the handy softlink to get the latest 'box1.date' mirror
     directory and since the mirror is all in one partition you can just
     cpdup the entire machine in one command.  Use the same dated directory
     name on the remote box, so:
@@ -231,7 +230,7 @@ $DragonFly: src/bin/cpdup/BACKUPS,v 1.4 2007/05/17 08:19:00 swildner Exp $
 
     Once done you can do incremental backups using './do_mirror 1' to do a
     verified incremental, or './do_mirror 2' to do a stat-optimized
-    incremental.  You can enable the cron jobs that run do_mirror and 
+    incremental.  You can enable the cron jobs that run do_mirror and
     do_cleanup now.
 
     --
@@ -261,3 +260,82 @@ $DragonFly: src/bin/cpdup/BACKUPS,v 1.4 2007/05/17 08:19:00 swildner Exp $
     should do a tower-of-hanoi removal
 
 
+			      SSH SECURITY TIPS
+
+    To allow root access via ssh, add the following line to your sshd
+    configuration on the client boxes (typically /etc/ssh/sshd_config):
+
+	PermitRootLogin forced-commands-only
+
+    If your OpenSSH version is too old to recognize that setting, you
+    should update to a more recent version immediately.
+    Restart sshd for the settings to take effect.
+
+    On the backup machine, create a special backup key for root:
+
+	mkdir /root/.ssh	# if it doesn't already exist
+	cd /root/.ssh
+	ssh-keygen -t dsa -N "" -f backup-key
+
+    You now have a key pair, consisting of a secret key called "backup-key"
+    and a public key called "backup-key.pub".  The secret key must *NEVER*
+    leave the backup machine nor be disclosed in any way!  Note that we
+    haven't procted the secret key with a passphrase (-N "") because it
+    will be used by cron jobs where no passphrase can be entered.
+
+    On the client boxes, create a file /root/.ssh/authorized_keys.
+    It should contain just this line:
+
+	command="/usr/local/bin/cpdup -S",from="<BAKHOST>",no-pty,
+	no-port-forwarding,no-X11-forwarding,no-agent-forwarding <PUBKEY>
+
+    This must be on one long line; it has been broken up here for
+    readability only.  Note that the options must be separated by commas
+    *ONLY* (no spaces).  Replace <BAKHOST> with the IP address or DNS name
+    of the backup machine.  Replace <PUBKEY> with the contents of the
+    file /root/.ssh/backup-key.pub from the backup machine (the public key,
+    not the secret key!).  It typically starts with "ssh-dss" followed by
+    a long character sequence that looks like line noise, followed by a
+    comment that typically indicates who created the key.
+
+    The format of the authorized_keys file is documented in the sshd(8)
+    manual page.  Please refer to it for more details.
+
+    If you have done all of the above correctly, then the root user on the
+    backup machine will be able to log into the client boxes as root and
+    execute "/usr/local/bin/cpdup -S", but nothing else.
+
+    To further improve security, you can place the slave cpdup on the client
+    machine into read-only mode by adding the -R option.  In this case, the
+    line from the authorized_keys file should begin as follows:
+
+	command="/usr/local/bin/cpdup -RS",from="<BAKHOST>",etc...
+
+    If you do that, your backup server can only pull backups from the client
+    machine, but it won't be able to change anything on it.  That is, you
+    cannot use the client machine as a remote target.  So, if an attacker
+    manages to be able to execute commands on your backup machine, he won't
+    be able to do any harm to your clients.  This also protects against
+    human errors, e.g. accidentally swapping source and destination.
+
+    By the way, it doesn't really matter much whether you specify the -R
+    option when running cpdup on the backup machine.  If you do it, then
+    the -R option will be passed to the slave, but the command="..." entry
+    from the authorized_keys file overides it anyway, so the slave always
+    runs with the -R option.
+
+    When using cpdup on the backup machine, make sure that the right key is
+    used by passing the -i option to the ssh command:
+
+	cpdup -F -i/root/.ssh/backup-key ...
+
+    If one or both of the machines involved has a slow processor, it might
+    be worthwhile to use a faster encryption algorithm, for example:
+
+	cpdup -F -cblowfish-cbc ...
+
+    If your OpenSSH version has been patched to support unencrypted transfers
+    *AND* you trust the physical network between the machines involved, you
+    might want to disable encryption altogether:
+
+	cpdup -F -cnone ...

bin/cpdup/Makefile

@@ -1,20 +1,17 @@
-# $DragonFly: src/bin/cpdup/Makefile,v 1.7 2008/04/10 22:09:08 dillon Exp $
-
 PROG=	cpdup
-SRCS=	cpdup.c hcproto.c hclink.c misc.c fsmid.c
-
-.if !defined(NOPTHREADS) && !defined(BOOTSTRAPPING)
-CFLAGS += -DUSE_PTHREADS=1
-LIBADD+=	pthread
-.endif
+SRCS=	cpdup.c hcproto.c hclink.c misc.c
 
+.if defined(BOOTSTRAPPING) || defined(RESCUE)
+# For boostrapping buildworld the md5 functionality is not needed
+CFLAGS+=	-DNOMD5
+.else
 .if !defined(NOMD5)
-SRCS+=	md5.c
+SRCS+=		md5.c
+LIBADD+=	crypto md
+.endif
 .endif
 
-WARNS?= 1
-
-LIBADD+=	md
+WARNS?=	1
 
 .include <bsd.prog.mk>
 

bin/cpdup/PORTING

@@ -15,18 +15,16 @@ $DragonFly: src/bin/cpdup/PORTING,v 1.2 2008/04/11 17:33:11 dillon Exp $
     This script should suffice when compiling under linux.  For some reason
     that I cannot fathom, linux defaults to using a 32 bit off_t.  It makes
     no sense at all to me why they would want to do this, BSDs went to
-    a 64 bit default off_t over 15 years ago.  In anycase, fixing it 
+    a 64 bit default off_t over 15 years ago.  In anycase, fixing it
     requires a few -D options.
 
     #!/bin/csh
     #
     cd cpdup
     rm -f md5.c
     rm -f *.o
-    cc -D__unused= -D_GNU_SOURCE -D__USE_FILE_OFFSET64 -DNOMD5 \
-	-DUSE_PTHREADS -pthread *.c -c
-    cc -D__unused= -D_GNU_SOURCE -D__USE_FILE_OFFSET64 -DNOMD5 \
-	-DUSE_PTHREADS -pthread *.o -o ~/bin/cpdup
+    cc -D__unused= -D_GNU_SOURCE -D__USE_FILE_OFFSET64 -DNOMD5 *.c -c
+    cc -D__unused= -D_GNU_SOURCE -D__USE_FILE_OFFSET64 -DNOMD5 *.o -o ~/bin/cpdup
 
     BACKUP SCRIPT MODIFICATIONS - you will almost certainly have to adjust
     the do_cleanup script to extract the proper field(s) from the df output.