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@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/