rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rdiff-backup-users] Backing up the backup server


From: Keith Edmunds
Subject: Re: [rdiff-backup-users] Backing up the backup server
Date: Thu, 19 Jan 2006 21:16:48 +0000
User-agent: Debian Thunderbird 1.0.2 (X11/20051002)

Question 1: For a purely local backup such as this, is there any reason (security concerns, for instance) to prefer that it not run as root, and instead to have it run as the backup user?

The requirement is only that the backup user has read access to all data files, and execute access to all directories. In many cases this does mandate the use of root, but you may judge that not to be the case here.

Question 2: Why does rdiff-backup keep asking me for a password, instead of working without interaction as it does when it backs up dns-server? What are the things I should check?

rdiff-backup uses ssh, and if ssh requires a password then so will rdiff-backup. The solution is passphraseless keys, which it sounds as if you have setup. In my (reasonably extensive) experience, the problem is 95% certain to be on the system which is receiving the login rather than the system which is doing the logging in (hope that makes sense). As you're backing up on the same system, you could just specify a local directory on the rdiff-backup command line rather than a network connection (a network connection has a double colon in the command). Things to check if an ssh connection seems to insist on a password despite setting up keys (check these things on the server which you are try to log into):

- is the account enabled? 'passwd -S username' should _not_ show a "L" in the status field

- make sure that the ~/.ssh directory is owned by the account concerned and that is it not group or world writable. For choice, chmod 600.

- make sure ~/.ssh/authorized_keys is owned by the account concerned and is not group or world writable

- if all else fails, set 'LogLevel' to 'DEBUG' in /etc/ssh/sshd_config, restart the sshd daemon and post the results of a failed login from /var/log/auth (or maybe 'syslog', depending on your setup).

HTH,
Keith

--
Keith Edmunds

+---------------------------------------------------------------------+
|  Tiger Computing Ltd  |  Helping businesses make the most of Linux  |
|  "The Linux Company"  |       http://www.tiger-computing.co.uk      |
+---------------------------------------------------------------------+




reply via email to

[Prev in Thread] Current Thread [Next in Thread]