Re: [BackupPC-users] Issues with a restore

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