Thanks, that did work and backups are now running :)

Dave Williams

On 10/2/2013 11:15 AM, David Williams wrote:
Actually, it isn't resolved. I just haven't had the time to look into it.  I will try out the sudo option as you mention and maybe that will help :)

David Williams

On 10/2/2013 11:05 AM, Holger Parplies wrote:
Hi,

this matter is probably resolved by now, but for the archives (and
consideration by David):

John Rouillard wrote on 2013-09-09 21:23:35 +0000 [Re: [BackupPC-users] Issues with a restore]:
On Mon, Sep 09, 2013 at 02:21:27PM -0400, David Williams wrote:
On 9/9/2013 1:53 PM, John Rouillard wrote:
On Mon, Sep 09, 2013 at 12:07:03PM -0400, David Williams wrote:
I will want to restore a whole
bunch of files.  Does the backuppc documentation explain how to set
up the ssh key for backuppc to execute as root on the target (which
is in fact one and the same machine)?
             ^^^^^^^^^^^^^^^^^^^^^^^^

Then why bother with ssh at all?

[...]
Ok, so what would go into the restore command then? [...]
basically, you replace the ssh part with a corresponding sudo part. You also
need to remove one level of quoting. And set up sudo.

For example, the default RsyncClientRestoreCmd is (or was at some point)

	$sshPath -q -x -l root $host $rsyncPath $argList+

which would become

	/usr/bin/sudo $rsyncPath $argList

(note the missing "+" behind $argList). Replace RsyncClientCmd accordingly if
you also want to continue doing backups (without ssh).

You need an entry something like

	backuppc	ALL=NOPASSWD: /usr/bin/rsync --server *

in /etc/sudoers (use 'visudo' to edit that).

The same principal is also applicable to tar backups.

[...]

Ah sorry for confusing the issue. I forgot that you can do direct
restores via the web interface. I run with that feature disabled for
security [...]
So do I. For that case, you'd want to additionally enforce the --sender
command line option in the sudoers entry:

	backuppc	ALL=NOPASSWD: /usr/bin/rsync --server --sender *

or even

	backuppc	ALL=NOPASSWD: /usr/bin/rsync --server --sender --numeric-ids --perms --owner --group -D --links --times --block-size=2048 --recursive *

(adapt to the command actually run by BackupPC - possibly consult your
auth.log to see the command actually passed to sudo).

As Les followed up with, my method bypasses the web interface totally.
Yes, but you *can* use sudo instead of ssh for escalating privileges on local
backups, and it does make sense, because you avoid the overhead of encryption.
In fact, for security reasons I use an 'ssh -l backuppc remote_host sudo rsync'
type of setup even for remote backups rather than allowing passwordless root
access with an unencrypted ssh key. Thus sudo is also a *more secure* option
for local backups. Someone should really put that into the wiki if it's not
already there ;-) (yes, I promise to really *try* to remember to do so ...).

Hope that helps someone :-).

Regards,
Holger



------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk


_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/