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