The default configuration that is installed in /etc/backupninja.conf is to log errors of informational, warnings, errors and fatal errors:
# how verbose to make the logs # 5 -- Debugging messages (and below) # 4 -- Informational messages (and below) # 3 -- Warnings (and below) # 2 -- Errors (and below) # 1 -- Fatal errors (only) loglevel = 4 Additionally, a report is sent (again by default), to root: # send a summary of the backup status to # this email address: reportemail = root If you are familiar with how backupninja works with this default configuration, you would *expect* an email every day, and if you didn't get one, then you'd realize that there was something wrong. However, I agree that this is a valid point and most people are going to want to know when something is misconfigured. You do *not* want to remove the exit call in the fatal function, because you dont want things to continue in this situation, and backupninja would act in ways that are unexpected. The solution is to make it so that if there is a fatal problem in backupninja itself (not one of the handlers), that an echo is done of the fatal message right before the fatal message is added to the message stack. This would mean that CRON would report the erorr, because something would be echoed, and it will report it every hour. This is annoying, but if you screwed something up, you probably want to know, and you are going to notice the problem if you keep getting this reminder. The upstream author has suggested this fix, and it is going into the upstream code, however he said that a better fix would be to re-do things at a more fundamental level so that things could pop out of the stack into a master script that would then report the errors, however this change is more significant, so this is what will happen for now. Expect a new version shortly. micah daniel schrieb am Wednesday, den 04. May 2005: > Package: backupninja > Version: 0.5-2 > Severity: important > > > When a fatal error is found (for instance, wrong permissions in > /etc/backup.d), the main script just exits, which means no email is sent > to report the problem. This is an important bug, since that means the > user can remain unaware of a problem that prevents his backups from > happening normally. > > This happens because the 'fatal' function does an 'exit 2' line 113 of > /usr/sbin/backupninja. Since all work happens in the same process > (scripts are sourced), this mean backupninja just exits in that case, > preventing any further action like sending the report email. Just > commenting out the exit seems to be a fine solution, at least > temporarily. Probably discussion with upstream is needed to decide what > is the proper behaviour in all cases. That is, is it ever important that > part of the script is skipped when a fatal error is found? In any case, > it should definitely not just finish the whole script. > > > -- System Information: > Debian Release: 3.1 > APT prefers testing > APT policy: (700, 'testing'), (600, 'unstable') > Architecture: i386 (i686) > Kernel: Linux 2.6.6-2-686 > Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) > > Versions of packages backupninja depends on: > ii gawk 1:3.1.4-2 GNU awk, a pattern scanning and > pr > ii mawk 1.3.3-11 a pattern scanning and text > proces > > -- no debconf information > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
