On 12/03 03:05 , Les Mikesell wrote:
> I thought it was on the wiki but I can't find it now and don't have an
> example myself.
Here's the doc I wrote.
Should get this up on the new wiki.
-=Introduction=-
Here's a quick & dirty explanation of how to set up a client machine to be
backed up with rsync, using sudo and restricted command rights to give some
protection against unauthorized writes. If you are logging in as root on the
hosts to be backed up, then someone cracking the backup server could easily get
access to modify files on the machines being backed up. If you set your clients
up this way, it provides a couple of layers of restriction which prevent the
backup process from being able to modify files.
For purposes of this explanation, I'm going to use 'rsyncbackup' as the user.
It actually doesn't matter what the remote user's name is, so long as it's
unique. (It shouldn't collide with any other username).
--==Setup==--
If you do not have a DSA key pair for passwordless authentication with ssh, you
will need to create one. Otherwise backups would require someone manually
typing in the password every time the backup is run. This is done with the
ssh-keygen command, and you should use the 'dsa' type (instead of the obsolete
rsa type). If you need to create a key, become root and type the following
command:
ssh-keygen -t dsa
If it asks you for a passphrase, just hit <enter>, to avoid putting one in.
Otherwise we're back at the original problem of having to put a password in
whenever a backup should be run.
This will create a pair of files in ~root/.ssh/ called id_dsa and id_dsa.pub.
The id_dsa file is the private side of the keypair, and should be kept secret.
The id_dsa.pub file is the public side of the keypair, and shoud be put on any
remote machine you wish to log into without a password.
-=On the Client Machine to be Backed Up=-
First, create the 'rsyncbackup' user on the intended client machine. Make the
home directory /var/lib/rsyncbackup. This will be the user that we log in as,
and then use sudo to run the actual rsync commands. The actual command to run
is likely to be something resembling:
useradd -r -m -d /var/lib/rsyncbackup -c "Backuppc User" rsyncbackup
Note that the '-r' option is a RedHat-ism (though I believe it applies to SuSE
as well). It creates a 'system' (low-UID) account. On other distributions (like
Debian), just manually assign an unallocated low UID number.
Once the rsyncbackup user has been created, you will need to create a .ssh
directory to hold the public side of the keypair that the backup user will log
in with.
- First, change to the backup user's home directory.
cd ~rsyncbackup
- Next, make a .ssh directory
mkdir .ssh
- Transfer the public side of the keypair to the client machine by some
mechanism (scp is a good one). You can upload it to /var/tmp/, temporarily.
(You should not be transferring files in as root, so you wouldn't be able to
upload directly to ~rsyncbackup/.ssh). We then transfer it from there to the
~rsyncbackup/.ssh/authorized_keys file. Note that it is possible to have
multiple keys in the authorized_keys file; but since this is a brand-new
account, we will just move the file into place.
mv /var/tmp/id_dsa.pub ~rsyncbackup/.ssh/authorized_keys
- Next we need to make sure the ownership and permissions on the key file and
directory is correct; otherwise it will not authorize correctly.
chown -R rsyncbackup:users ~rsyncbackup/.ssh
chmod 700 ~rsyncbackup/.ssh
Now edit /etc/sudoers with the 'visudo' command and add some lines to allow the
rsyncbackup user to run the rsync command as root, thereby giving them access
to the whole filesystem. (Without allowing other commands to be run with access
to the whole filesystem).
# allow backup user to run rsync as root
rsyncbackup ALL= NOPASSWD: /usr/bin/rsync
(One should run the 'which rsync' command to verify that rsync is indeed
installed, and what its actual path is. /usr/bin/rsync is just a common place
to find it).
On the backuppc server, su to backuppc ( su - backuppc -s /bin/bash); then try
to ssh to rsyncbackup@client. Make sure that works without a password being
entered. if not, check that the permissions and ownership on the
~rsyncbackup/.ssh directory are correct.
Doing this also adds the host to backuppc's list of known_hosts; so it won't
hang waiting for confirmation that the host's key is acceptable.
Make sure when you ssh to the client, that you refer to it by the name you call
it in the backuppc configuration files (so if you will list the machine in
/etc/backuppc/hosts as foo.example.tld, ssh to it as rsyncbackup AT foo.example
DOT tld instead of rsyncbackup@foo). Otherwise the key caching will not work,
and backups will fail because ssh prompts for acceptance of the host key.
Now add the rsync/sudo restrictions to the authorized_keys file. Here is a
starting example of what a key might look like (of course, the ...AAA.. section
should be replaced with your actual DSA public key). The 'ssh-dss' is where the
automatically-generated part of the key begins. Everything before that is
additional restrictions on what can be done after logging in with this key.
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="sudo
/usr/bin/rsync --server --sender -logDtpr --exclude='/proc/*'
--exclude='/sys/*' --exclude='/tmp/*' --exclude='/mnt/*' --exclude='/staff/*'
--delete --numeric-ids --block-size=2048 . /" ssh-dss
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
root AT backupserver.example DOT tld
-=On the Server=-
Become root on the server again; then go to /etc/backuppc.
Copy one of the other per-host configuration files and edit the options
therein, if necessary.
Add the host to the /etc/backuppc/hosts file, and specify which users should
have authority over it.
You will likely need to restart/rehup the backuppc process, before it will
resolve the hostname of the new box. So run:
/etc/init.d/backuppc reload
Go to the web interface, choose your new host to be backed up from the Host
Summary page by clicking on its link, and click on the 'start full backup'
button for that host.
Check the running processes on the client and server; see if there is an rsync
running on both of them. (Use the 'ps ax' command).
if not, go to the debugging section.
--==Removing Clients==--
If you wish to stop backups of a client; don't remove them from the list of
hosts.
just add the following lines to their config file:
#Going to disable backups for the near-term. Setting FullPeriod=-2 means
#it will never be backed up, and EMailNotifyMinDays=365 means it won't notify
#about the lack of backups for a year.
$Conf{FullPeriod} = -2;
$Conf{EMailNotifyMinDays} = 365;
--==Debugging==--
In some cases, it may be necessary to put a password on the 'rsyncbackup'
account before DSA logins will be accepted.
you'll see an error in syslog like:
"User rsyncbackup not allowed because account is locked"
Just generate a long string up characters with md5sum against some file, or the
like, and use that as a password. (you'll never need to know it).
If DSA-keyed logins still don't work; make sure the authorized_keys file hasn't
become corrupt. (often happens when you copy-and-paste the key, you'll miss the
first character, or put an extraneous line break in).
On older SSH implementations:
- it's authorized_keys2 instead of authorized_keys
- the authorized_keys2 file must be chmod'ed 600 or 400; even if the directory
is already.
To get more debugging information out of the rsync transfers, in the per-host
configuration file, add the line:
$Conf{RsyncLogLevel} = 6;
Better yet, become backuppc, and try running the BackupPC_dump command by hand,
and look at the output. 99% of the time, this will tell you what's wrong.
# su - backuppc -s /bin/bash
$ /usr/share/backuppc/bin/BackupPC_dump -v -f berzerker
Note that rsync-2.5.5 is supposedly needed for backuppc-2.0.2 and later. (tho
it looks like rsync-2.4.6 [protocol v24] works anyway).
Rsync protocols >26 should work (maybe lower, don't know); I think protocol v28
is the current one. the protocol version is apparent when you run backuppc_dump
by hand. if there is a protocol mismatch; the connections will open, and the
rsync process start; but nothing will be transferred.
--
Carl Soderstrom
Systems Administrator
Real-Time Enterprises
www.real-time.com
------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
|
