Backup Central

Hi,

I have a backup server running OpenSUSE, call it 'backup-server' and a
dns server running Debian, call it 'dns-server'. They are on the same
subnet. Last night I got rdiff-backup 1.0.4 installed on both so that
backup-server backs up dns-server via a cron job, basically following
the instructions at http://www.howtoforge.com/linux_rdiff_backup.

However, I cannot similarly get backup-server to backup itself via the
backup user's cron job. Instead I have to let root run the cron job.
Every time the backup user runs rdiff-backup it requests a password
rather than running without requiring interaction.

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?

If the answer to question 1 is yes, then:

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?

I already looked at /home/backup/.ssh/config and
/root/.ssh/authorized_keys and /etc/ssh/sshd_config and everything looks
just as good as it did for the server that works.

I also tried the sudoers method described here:
http://www.arctic.org/~dean/rdiff-backup/unattended.html

and I also get asked for a password by sudo! Aack!?!

Thanks for any help.

Brian

Brian C wrote:
Hi,

I have a backup server running OpenSUSE, call it 'backup-server' and a
dns server running Debian, call it 'dns-server'. They are on the same
subnet. Last night I got rdiff-backup 1.0.4 installed on both so that
backup-server backs up dns-server via a cron job, basically following
the instructions at http://www.howtoforge.com/linux_rdiff_backup.

However, I cannot similarly get backup-server to backup itself via the
backup user's cron job. Instead I have to let root run the cron job.
Every time the backup user runs rdiff-backup it requests a password
rather than running without requiring interaction.

What is the command-line you are using ?

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?

If the answer to question 1 is yes, then:

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?

I guess we need to see you command line.

when using localhost for backup, you dont need to specify a
hostname-part of the destination


I already looked at /home/backup/.ssh/config and
/root/.ssh/authorized_keys and /etc/ssh/sshd_config and everything looks
just as good as it did for the server that works.

No need to use keys to authenticate for a localhost, as ssh should not
be used ( but it should work)

I also tried the sudoers method described here:
http://www.arctic.org/~dean/rdiff-backup/unattended.html

and I also get asked for a password by sudo! Aack!?!

That depends on the sudo-rights.

--
Finn-Arne Johansen
faj < at > bzz.no http://bzz.no/
Debian-edu developer and Solution provider
EE2A71C6403A3D191FCDC043006F1215062E6642 062E6642

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 |
+---------------------------------------------------------------------+

Hi,

If you need the backup to have correct ownership of the files,
rdiff-backup needs to run as root at the backup side. For most
installations I know, this is not the case.
At the backed-up side however, rdiff-backup usually needs to run as root
to have access to all files in the backed-up tree.

For local backup, you could also use the TCP/IP loopback to split backup
and backup-up userid's.

Regarding your second question:
- Does it work when you run `ssh root < at > backup-server' when logged in as the
backup user? If not, maybe /root/.ssh has wrong permissions?
- Do you use the same rsa/dsa key for both backup-server and
dns-server? If not, maybe the private or public keys are mixed up?


Regards,
Maarten


On Thu, 19 Jan 2006, Brian C wrote:

Hi,

I have a backup server running OpenSUSE, call it 'backup-server' and a
dns server running Debian, call it 'dns-server'. They are on the same
subnet. Last night I got rdiff-backup 1.0.4 installed on both so that
backup-server backs up dns-server via a cron job, basically following
the instructions at http://www.howtoforge.com/linux_rdiff_backup.

However, I cannot similarly get backup-server to backup itself via the
backup user's cron job. Instead I have to let root run the cron job.
Every time the backup user runs rdiff-backup it requests a password
rather than running without requiring interaction.

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?

If the answer to question 1 is yes, then:

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?

I already looked at /home/backup/.ssh/config and
/root/.ssh/authorized_keys and /etc/ssh/sshd_config and everything looks
just as good as it did for the server that works.

I also tried the sudoers method described here:
http://www.arctic.org/~dean/rdiff-backup/unattended.html

and I also get asked for a password by sudo! Aack!?!

Thanks for any help.

Brian


_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki