BackupPC-users

Re: [BackupPC-users] Incremental Backup fail

2014-07-15 17:38:23
Subject: Re: [BackupPC-users] Incremental Backup fail
From: Holger Parplies <wbppc AT parplies DOT de>
To: raceface <raceface_the_one AT gmx DOT net>
Date: Tue, 15 Jul 2014 23:37:19 +0200
Hi,

raceface wrote on 2014-07-15 10:40:34 +0200 [Re: [BackupPC-users] Incremental 
Backup fail]:
> thank you for being that kind to non professionals. I have only 3 blank
> lines in my last posting and 21 non blank, don't know, why you get more
> blank 50 times more blank lines.

ok, sorry about that. I should have noticed the multipart/alternative message
and checked the HTML part (source). Or the X-Mailer header. I'd suggest filing
a bug report with your MUA vendor, but that'd probably be quite pointless :-).

As Benjamin Redling has pointed out, such a message, when viewed as text,
creates a strong urge to simply ignore and delete it. In any case, it does not
make debugging the matter easier.

Your current message demonstrates that you - and your MUA - are capable of
sending text-only messages. That is the correct format for a mailing list.
Thank you for that.

> Using this script is a suggestion of the backuppc FAQ and not my personal
> idea.

Ok, then the FAQ needs to be changed. Which part of which FAQ are you
referring to?

> This script helps me getting backuppc running full backups. Using $tarPath
> ends in error " sudo: no tty present and no askpass program specified".

First of all, it evidently does *not* help you getting BackupPC running. So
far, you've had two different problems solely introduced by the script.

Secondly, this is most certainly a misconfiguration of sudo. There is no
reason why 'sudo /tar/tarCreate' should behave differently than
'sudo /bin/tar' when configured correctly. I've used that myself, and it
*does* work without a script. Right now, you've probably got a line similar to

        backuppc        ALL=NOPASSWD:   /tar/tarCreate

in /etc/sudoers. Add a line

        backuppc        ALL=NOPASSWD:   /bin/tar -c -v -f - *

and change your $Conf{TarClientCmd} back to 'sudo $tarPath -c -v -f - ...'.
Please note the following:

1. The path of the tar executable (in sudoers) needs to match your system.
   If you use $tarPath (in $Conf{TarClientCmd}), you should check
   $Conf{TarClientPath}. If things don't work, try using literal '/bin/tar'
   (assuming that is what you need) instead of $tarPath for the moment.
   In /etc/sudoers, you can't use $tarPath in any case.
2. The above line restricts passwordless sudo for the backuppc user to tar
   command lines starting with the options '-c -v -f -'. Any of the following
   example invocations should trigger a password prompt:

        % sudo tar cvf - /home
        % sudo tar -c -v -f /etc/passwd /home
        % sudo tar -x -v -f - -C /home .
        % sudo tar -v -c -f - /home

   This is partly intentional (to disallow someone who manages to gain
   backuppc privileges to damage the system, e.g. by overwriting important
   system files via a tar extract or a tar create to a file), partly because
   sudo has no way of knowing that a certain way of writing options is
   equivalent to another, as far as the tar command is concerned. It simply
   means that you have to track changes you might make to your TarClientCmd.
   My example only includes the first four arguments, because these are
   unlikely to change. You *could* extend that up to (and not including) the
   --newer= parameter, but here you'd need to use a wildcard anyway, and I
   don't see any benefit (there would be if your share was not '/', i.e. you
   had, e.g., a '-C /home' parameter; that would disable a potential attacker
   to create a tar file of secret data outside /home).
3. You *need* the wildcard at the end. Otherwise the line only applies to
   '/bin/tar -c -v -f -' without further parameters, again triggering a
   password prompt if there are any. "Password prompt" translates to your
   "no tty present" error message in the context of BackupPC (on the command
   line, you'd get a password prompt, without a tty, you get an error).
4. You can test on the command line. As the backuppc user (i.e. after
   something like 'su -s /bin/bash backuppc'), run a command and see if you
   are prompted for a password:

        % sudo tar -c -v -f - -C / --totals /bin/sh > /dev/null

   If you are, something is still wrong, and backups will fail with the "no
   tty present" error.
5. If you also want to enable automatic restores (I believe you do), there
   is not much point in restricting tar command line parameters. As your
   setup seems to be (share name "/"), there is nothing a potential attacker
   *can't* do. Consider this: create /tmp/etc/passwd and /tmp/etc/shadow as
   any user with any content you like (your choice of password for root). Run
   'tar cvf /tmp/foo.tar -C /tmp etc/passwd etc/shadow'. Then, as backuppc
   user, run 'sudo tar -x -v -f - -C / etc < /tmp/foo.tar'. Add any --totals
   or --exclude options your sudoers file might require. Chances are, there
   is some way to circumvent the restrictions your sudoers file places - if
   it does place any.
   My recommendation: don't enable automatic restores. If you need to restore
   single files or directories, download them through the web interface. If
   you need to restore the whole machine, either enable automatic restores
   *then* and only for the time the restore takes, or preferably do the
   restore via command line, where you can provide a password if required.

> Root has also no rights to login via ssh, so ssh is no option.

For a local backup, ssh just means more overhead and more complications if you
want to restrict commands than with sudo. Stay with sudo for local backups.

> Giving the user backuppc sudo rights is no option, to prevent having too
> much users with to many rights.

You *are* giving the backuppc user "sudo rights". It's just limited to one
command without password. There is no good reason (and no need) to extend
that to "everything without password".


All of that said, I'd recommend switching the XferMethod from tar to rsync.
Again, you'd need to get the configuration right (sudoers, RsyncClientCmd).
The benefit is not in bandwidth savings, but in backup exactness. rsync
correctly tracks file deletions, renames and anything else that creates
files with old timestamps - even in incrementals. You pay a moderate price
in terms of required processing power, which you likely won't notice on a
computer that doesn't qualify as "ancient". As a rule of thumb, you should
always force a full backup after changing the XferMethod.

Hope that helps.

Regards,
Holger

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
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/