Bug#1041524: logcheck: badly handles "rsyslog + journalctl" checking
Le jeudi 27 juillet 2023 à 18:44, d'après Richard Lewis : > The possibility of setting JOURNALCTL_OPTS would be great! I think the > pre/post-processing customisation is a good idea too, to move all that > logic from the code to the configuration. > > cool. this does seem the way to go (there are other priorities, but consider > it on the todo list!) Great! Thanks. -- Thomas Parmelan
Bug#1041524: logcheck: badly handles "rsyslog + journalctl" checking
Le vendredi 21 juillet 2023 à 23:32, d'après Richard Lewis : > I suppose the timestamp difference is because the journal 'gets' the > message, and then forwards it to rsyslog which then creates its own > timestamp, so even if systemd and rsyslog would agree a common format, > this will always be an issue. Yes, that's what I thought too. > Personally, i would just tell rsyslog to use the less precise format, The more precise format has been the default in rsyslog for quite some time. > (or stop using rsyslog entirely). I quite like my old habits wrt to /var/log/* :p But I now understand that all that is logged via rsyslog comes from systemd-journald anyway, so there's actually no point for logcheck to check both rsyslog files and the journal! I instructed logcheck to only look at the journal, and I therefore no longer have my "duplicates" problem. Maybe that should be the new default for the logcheck package, or at least having some explicit documentation about it? > This might be overkill, but we could make the pre-processing of log > files be more customisable, so the user could choose whatever mangling > of timestamps, whitespace and/or sorting they want. [...] The possibility of setting JOURNALCTL_OPTS would be great! I think the pre/post-processing customisation is a good idea too, to move all that logic from the code to the configuration. -- Thomas Parmelan
Bug#1041524: logcheck: badly handles "rsyslog + journalctl" checking
nths ago) to use SORTUNIQ=1 (it it set to 0 by default), I don't recall exactly, but you are right, this is not correct. The logic was initially to use 'sort -u' or only 'sort' and I wrongly transformed it to 'sort -u' or 'sort | uniq' which I agree is total nonsense. Sorry about that. The sort key selection probably still needs to be adjusted though. When using ISO_TIMESTAMPS, the whole timestamp is in the first field so '-k 1' should be used. If not using ISO_TIMESTAMPS, the original behaviour of "-k 1,3" is used (I don't understand it though: that would be the month and then the hh:mm::ss parts?). Regards, Tom -- Thomas Parmelan
Bug#1041524: logcheck: badly handles "rsyslog + journalctl" checking
Package: logcheck
Version: 1.4.3
Severity: normal
Tags: patch
X-Debbugs-Cc: tom+deb...@ankh.fr.eu.org
Dear maintainers,
The systemd journal is checked by default, in addition to rsyslog files,
starting with logcheck version 1.4.1. But the format of timestamps are
different by default for journal (uses the old-school format: "Jul 20
11:51:03") and rsyslog >= 8.2210.0-3 (uses an RFC3339-compatible format:
"2023-07-20T11:51:03.046581+0200"). So logcheck cannot compare them
correctly.
Also, journalctl can emit multi-line logs, whereas rsyslog cannot.
The attached patch adds a new ISO_TIMESTAMPS config variable to the logcheck
script, allowing logcheck to:
- call journalctl with "-o short-iso-precise" in order to get a
nearly-RFC3339-compatible timestamp
- add the missing ':' between the timezone hours and minutes to convert the
journalctl shot-iso-precise timestamp to the exact RFC3339 timestamp
format used by rsyslog
- join continuous lines (lines starting with whitespace) from
journalctl output, as rsyslog only logs them as one line
- handle SORTUNIQ correctly even when using ISO_TIMESTAMPS
I have been using this locally since early March.
(NB in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032197 I also
suggested to make journalctl use the "correct" timestamp format; if/when
this actually gets done, the "second sed action" in my logcheck patch
can be dropped)
Regards,
Tom
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.3.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages logcheck depends on:
ii adduser 3.137
ii cron [cron-daemon] 3.0pl1-162
ii lockfile-progs 0.1.19
ii logtail 1.4.3
ii mime-construct 1.12+really1.11-1
ii postfix [mail-transport-agent] 3.8.1-2
Versions of packages logcheck recommends:
ii logcheck-database 1.4.3
Versions of packages logcheck suggests:
ii rsyslog [system-log-daemon] 8.2306.0-2
--
Thomas Parmelan
--- logcheck.1.4.3 2023-07-20 11:03:01.945539427 +0200
+++ logcheck 2023-07-20 11:02:09.184636208 +0200
@@ -90,6 +90,7 @@
REBOOT=0
FQDN=0
SORTUNIQ=0
+ISO_TIMESTAMPS=1
SUPPORT_CRACKING_IGNORE=0
SYSLOGSUMMARY=0
LOCKDIR=/run/lock/logcheck
@@ -480,6 +481,10 @@
local JOURNALCTL_OPTS=() OPTS=()
local offsetfile offsettime
+ if [ "$ISO_TIMESTAMPS" -eq 1 ]; then
+ JOURNALCTL_OPTS+=("-o" "short-iso-precise")
+ fi
+
# There are some problems with this section.
debug "logoutput called with file: $file"
if [ -f "$file" ]; then
@@ -508,7 +513,13 @@
offsettime="--since=-5h"
fi
debug "Running $JOURNALCTL ${JOURNALCTL_OPTS[*]} -q $offsettime"
+ # first sed action: join lines starting with whitespace
+ # (source: https://www.gnu.org/software/sed/manual/html_node/Joining-lines.html)
+ # second sed action: convert ISO8601 timestamps (as generated by journalctl -o short-iso-precise)
+ # to RFC3339 timestamps (as generated by rsyslog)
"$JOURNALCTL" "${JOURNALCTL_OPTS[@]}" --quiet "$offsettime" \
+ | sed -E ':a ; $!N ; s/\n\s+/ / ; ta ; P ; D' \
+ | sed -E 's/^([0-9T:.+-]{29})/\1:/' \
>> "$TMPDIR/logoutput/$file" 2>&1 \
|| error "Could not run journalctl or save output"
touch "$offsetfile"
@@ -602,13 +613,6 @@
INTRO=1
fi
-# Use sort -u or -k 1,3 -s
-if [ "$SORTUNIQ" -eq 1 ];then
- SORT="sort -u"
-else
- SORT="sort -k 1,3 -s"
-fi
-
# Set the mime encoding if required (blank means auto-detected)
if [ -n "$MIMEENCODING" ]; then
ENCODING=(--encoding "$MIMEENCODING")
@@ -780,8 +784,20 @@
# First sort the logs to remove duplicate lines (including from different logfiles with
# the same lines) to reduce CPU and memory usage.
debug "Sorting logs"
-$SORT "$TMPDIR/logoutput"/* | sed -e 's/[[:space:]]\+$//' > "$TMPDIR/logoutput-sorted" \
+# Use "sort -u" or "sort ... | uniq"
+if [ "$SORTUNIQ" -eq 1 ];then
+ SORT_OPTS="-u"
+ sort $SORT_OPTS "$TMPDIR/logoutput"/* | sed -e 's/[[:space:]]\+$//' > "$TMPDIR/logoutput-sorted" \
+ || error "Could not save sorted log content to $TMPDIR/logoutput-sorted"
+else
+ if [ "$ISO_TIMESTAMPS" -eq 1 ]; then
+ SORT_OPTS="-k 1 -s"
+ else
+ SORT_OPTS="-k 1,3 -s"
+ fi
+ sort $SORT_OPTS "$TMPDIR/logoutput"/* | sed -e 's/[[:space:]]\+$//' | uniq > "$TMPDIR/logoutput-sorted" \
|| error "Could not save sorted log content to $TMPDIR/logoutput-sorted"
+fi
debug "After sorting, we have the following log entries to check" "$TMPDIR/logoutput-sorted"
# See if the logoutput-sorted file actually has data to check,
Bug#1032197: systemd: journalctl -o short-iso-precise not compatible with RFC 3339
Hi Michael, Le mercredi 01 mars 2023 à 18:10, d'après Michael Biebl : > I think this could be a useful addition. That said, this should be > discussed/implemented upstream and not via a downstream patch. > > Can you thus please file an issue upstream at > https://github.com/systemd/systemd/ Thanks for your answer. I opened the following issue: https://github.com/systemd/systemd/issues/26639 Regards, Tom -- Thomas Parmelan
Bug#1032197: systemd: journalctl -o short-iso-precise not compatible with RFC 3339
Package: systemd Version: 252.5-2 Severity: wishlist X-Debbugs-Cc: tom+deb...@ankh.fr.eu.org Dear Maintainer, Recent versions of rsyslog (as used in sid) are now using by default timestamps based on RFC 3339 (Date and Time on the Internet: Timestamps). The "-o short-iso-precise" journalctl option uses an ISO 8601 profile that is not compatible with RFC 3339 (it misses a ':' between the hours and minutes in the timezone offset). Making journalct's ISO 8601 format compatible with RFC 3339 would make things easier for people comparing journalctl output with rsyslog output, for instance those like me using the 'logcheck' package (which, in sid, recently started checking by default the systemd journal too). Would it be possible to change the short-iso-precise in this way, or if you prefer not changing it, maybe adding a new short-rfc3339-precise option ? (and probably doing the same thing for short-iso / short-rfc339 too) ? Best regards, Tom -- Thomas Parmelan
Bug#895901: backup-manager: fails to purge old remote archives via ftp and ssh
Hi Maximiliano, Le vendredi 01 février 2019 à 10:44, d'après Maximiliano Curia : > It seems that the upstream issue report is stale, could you please create a > pull request to fix the issue upstream? Done: https://github.com/sukria/Backup-Manager/pull/120 I will follow-up here if I get news from upstream. Regards, Tom -- Thomas Parmelan
Bug#895901: backup-manager: fails to purge old remote archives via ftp and ssh
Package: backup-manager
Version: 0.7.14-1
Severity: normal
Tags: patch
Hi there,
I recently noticed that my remote archives were not purged anymore (I am
using FTP but the problem would be the same for SSH). This seems to have
started when I upgraded from 0.7.12-4 to 0.7.14-1.
After investigating, I found the problem lies in the fact that
/usr/sbin/backup-manager exports
BM_BMP_PATH=/usr/bin/backup-manager-purge, whereas backup-manager-upload
tries to run $ENV{BM_BMP_PATH}/backup-manager-purge, thus trying to run
/usr/bin/backup-manager-purge/backup-manager-purge, which does not
exist.
My fix was to simply delete the line "export BM_BMP_PATH=$bmp" (line 37)
in /usr/sbin/backup-manager.
For what it's worth, this line was introduced in a commit related to
upstream issue #91 and I reported it there too:
https://github.com/sukria/Backup-Manager/issues/91#issuecomment-381925277
Thanks
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.15.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages backup-manager depends on:
ii debconf [debconf-2.0] 1.5.66
ii perl 5.26.1-5
ii ucf3.0038
backup-manager recommends no packages.
Versions of packages backup-manager suggests:
pn anacron
pn backup-manager-doc
ii dar2.5.14+bis-2
ii dvd+rw-tools 7.1-12
ii genisoimage9:1.1.11-3+b2
ii gettext-base 0.19.8.1-6
pn libnet-amazon-s3-perl
ii openssh-client 1:7.7p1-2
ii wodim 9:1.1.11-3+b2
ii zip3.0-11+b1
-- debconf-show failed
--
Thomas PARMELAN
Ingénierie Vidéo - Unicast / CDN
SFR / Altice Labs France
Campus SFR Saint-Denis
Bug#882225: inn2: wrong hardcoded gzip path breaks scanlogs and UUCP feed
Package: inn2 Version: 2.6.1-2 Severity: important Dear Maintainer, I recently upgraded from jessie to stretch and my inn2 setup stopped working: - the articles from my incoming feed (via UUCP) are SILENTLY dropped; - the daily usenet report contains the following error: /usr/lib/news/bin/scanlogs: line 206: /usr/bin/gzip: No such file or directory After a few investigations I found out that while in jessie /bin/gzip is used (in innshellvars.* and in include/inn/paths.h.in), /usr/bin/gzip is used in those files in stretch. But only /bin/gzip actually exists on a Debian system. I manually added /usr/bin/gzip (as a symlink to /bin/gzip) and my feed started to work again. I think there are two issues to be addressed here: - correct the package to actually use /bin/gzip again; - make rnews and/or gunbatch fail with an error insted of silently dropping the incoming batch. Feel free to ask if more information is needed. Tom -- System Information: Debian Release: 9.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.9.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages inn2 depends on: ii cron3.0pl1-128+b1 ii inn2-inews 2.6.1-2 ii libc6 2.24-11+deb9u1 ii libdb5.35.3.28-12+deb9u1 ii libmime-tools-perl 5.508-1 ii libpam0g1.1.8-3.6 ii libperl5.24 5.24.1-3+deb9u2 ii libsasl2-2 2.1.27~101-g0780600+dfsg-3 ii libssl1.1 1.1.0f-3+deb9u1 ii lsb-base9.20161125 ii perl5.24.1-3+deb9u2 ii perl-base [perlapi-5.24.1] 5.24.1-3+deb9u2 ii postfix [mail-transport-agent] 3.1.6-0+deb9u1 ii procps 2:3.3.12-3 ii time1.7-25.1+b1 ii zlib1g 1:1.2.8.dfsg-5 inn2 recommends no packages. Versions of packages inn2 suggests: ii gnupg 2.1.18-8~deb9u1 ii libcomerr2 1.43.4-2 ii libgd-perl 2.53-3 ii libkrb5-3 1.15-1+deb9u1 ii wget1.18-5+deb9u1 -- Configuration Files: /etc/logcheck/ignore.d.server/inn2 [Errno 13] Permission non accordée: '/etc/logcheck/ignore.d.server/inn2' /etc/logcheck/violations.ignore.d/inn2 [Errno 13] Permission non accordée: '/etc/logcheck/violations.ignore.d/inn2' /etc/news/expire.ctl changed [not included] /etc/news/incoming.conf changed [not included] /etc/news/newsfeeds changed [not included] /etc/news/send-uucp.cf changed [not included] -- debconf information excluded -- Thomas Parmelan
Bug#610012: apt-listchanges: fallback to a non-interactive frontend when needed
Hi, Le dimanche 14 juin 2015 à 09:35, d'après Alexandre Detiste : > This patch seems to break my setup (frontend=mail). > unattended-upgrade's email got messed-up with apt-listchanges output; Another bug (#788059) has been opened for this problem. A patch has been proposed, if you want to try it. Regards, Tom -- Thomas Parmelan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#788059: apt-listchanges: patch for #610012 breaks mail mode
Le lundi 08 juin 2015 à 09:26, d'après Thorsten Glaser : > So please don't override my mail frontend, thank you very much. Sorry for the side effect. Can you try this patch? --- /usr/bin/apt-listchanges2015-06-17 15:49:00.118359447 +0200 +++ /tmp/apt-listchanges.new2015-06-17 15:48:55.718281577 +0200 @@ -66,7 +66,8 @@ sys.exit(0) # Force quiet (loggable) mode if not running interactively -if not sys.stdout.isatty() and not config.quiet: +if not sys.stdout.isatty() and not config.quiet and \ +config.frontend != 'mail': config.quiet = 1 # If apt is in quiet (loggable) mode, we should make our output -- Thomas Parmelan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#610012: apt-listchanges: fallback to a non-interactive frontend when needed
severity 610012 minor tags 610012 + patch thanks Le vendredi 14 janvier 2011 à 21:58, d'après Micah Anderson : > It would be nice, especially for things like puppet, to make apt-listchanges > fallback to a non-interactive frontend when needed I totally agree! I raise the severity from whishlist to minor, because this actually breaks some real usecases. Here is a proposal for a patch to force the 'text' frontend when stdout is not a terminal. This patch was made against version 2.85.13+nmu1, as found in sid. --- apt-listchanges.orig2014-10-13 01:35:58.0 +0200 +++ apt-listchanges 2014-11-26 15:50:21.186460996 +0100 @@ -65,6 +65,10 @@ if config.frontend == 'none': sys.exit(0) +# Force quiet (loggable) mode if not running interactively +if not sys.stdout.isatty() and not config.quiet: +config.quiet = 1 + # If apt is in quiet (loggable) mode, we should make our output # loggable too if config.quiet == 1: -- Thomas Parmelan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#714610: pmailq: Would be nice to allow selection with the envelope from address
Package: pmailq Version: 0.5-1 Severity: wishlist Dear Maintainer, pmailq --email appears to select entries based on the envelope recipient. It would be nice to do the same thing based on the envelope sender, for instance: "pmailq --from sen...@example.org". If you implement this, it would probably be interesting to rename the --email option to "--to" (for instance), otherwise it might be too confusing. (or, at least, explicitly mention in the man page that --email only looks at the recipient adress). Thanks for considering this improvement. -- System Information: Debian Release: 7.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages pmailq depends on: ii postfix 2.9.6-2 ii python 2.7.3-4 pmailq recommends no packages. pmailq suggests no packages. -- no debconf information -- Thomas Parmelan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#714607: pmailq: Reports wrong version umber
Package: pmailq Version: 0.5-1 Severity: minor Dear Maintainer, $ dpkg-query -W pmailq pmailq 0.5-1 $ pmailq --version pmailq 0.3 This is only cosmetic, but very confusing. -- System Information: Debian Release: 7.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages pmailq depends on: ii postfix 2.9.6-2 ii python 2.7.3-4 pmailq recommends no packages. pmailq suggests no packages. -- no debconf information -- Thomas Parmelan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#706223: Mutt delivers wrong %{charset} to .mailcap
Hi,
Le vendredi 26 avril 2013 à 18:18, d'après
"erc...@tiscali.it" :
> I have the following entry in the .
> mailcap file used by Mutt :
>
> text/html; /usr/bin/w3m -I %{charset} -dump -T text/html '%s';
> copiousoutput; description=HTML Text; nametemplate=%s.html
>
> which is incorrectly interpreted as
>
> /usr/bin/w3m -I 'iso-8859-1' -dump -T text/html ''/tmp/mutt.html''
>
> (as I can read from Mutt headers) instead of
>
> /usr/bin/w3m -I 'utf-8' - dump -T text/html ''/tmp/mutt.html''
>
> as it should be, according to the
>
> charset="utf-8"
>
> entry in my .muttrc. This of course causes some characters to be unreadable.
>
> Testing the charset variable in Mutt returns the correct value (utf-8).
This seems like perfectly expected behaviour if the mail you were viewing is
encoded in iso-8859-1. The charset="utf-8" is related to your locale, whereas
the %{charset} is related to the charset of the mail or attachment you are
viewing.
See "Command Expansion" in manual.txt:
[...]
%{}
Mutt will expand this to the value of the specified parameter from the
Content-Type: line of the mail message. For instance, if your mail message
contains:
Content-Type: text/plain; charset=iso-8859-1
then Mutt will expand %{charset} to iso-8859-1. The default metamail
mailcap file uses this feature to test the charset to spawn an xterm using
the right charset to view the message.
[...]
Regards,
Tom
--
Thomas Parmelan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#644876: initramfs-tools: Boot failure from software RAID1 + LVM2 by timing of mdadm + lvm initiation
reassign 644876 mdadm tags 644876 + patch thanks Le mercredi 14 mars 2012 à 01:29, d'après Dave Whitla : > The condition will never be true because udevsettle was a symlink to > /sbin/udevadm which has been absent from Debian since Lenny. > > Try editing this file to replace the above with: > > if [ -x "$(command -v udevadm)" ]; then > verbose && log_begin_msg "Waiting for udev to process events" > udevadm settle --timeout=10 > verbose && log_end_msg > fi Good catch! And even better, there is a function to do that (defined in scripts/functions and already used by scripts/nfs and scripts/local). Also, this script is shipped by the mdadm package. --- /usr/share/initramfs-tools/scripts/local-top/mdadm.orig 2013-01-24 14:09:11.0 +0100 +++ /usr/share/initramfs-tools/scripts/local-top/mdadm 2013-03-02 18:03:59.0 +0100 @@ -97,11 +97,7 @@ done fi -if [ -x "$(command -v udevsettle)" ]; then - verbose && log_begin_msg "Waiting for udev to process events" - udevsettle 10 - verbose && log_end_msg -fi +wait_for_udev 10 maybe_break post-mdadm -- Thomas Parmelan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#563918: devscripts: [debcommit] limits commit to the debian directory when using cvs
-buildpackage 5.23 A set of Debian package scripts fo pn devscripts-el (no description available) pn gnuplot(no description available) pn libfile-desktopentry-perl (no description available) ii libnet-smtp-ssl-perl 1.01-2 SSL support for Net::SMTP ii mutt 1.5.20-5 text-based mailreader supporting M ii svn-buildpackage 0.7.1 helper programs to maintain Debian ii w3m 0.5.2-2.1 WWW browsable pager with excellent -- no debconf information -- debsums errors found: debsums: changed file /usr/bin/debcommit (from devscripts package) -- Thomas Parmelan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#548307: fpdns: "-c" option ignored
Package: fpdns
Version: 0.9.3-2
Severity: normal
Tags: patch
This is just a small typo, but it makes "-c" ignored.
Here's the patch :
--- fpdns.orig 2009-09-25 14:04:04.0 +0200
+++ fpdns 2009-09-25 14:04:10.0 +0200
@@ -79,7 +79,7 @@
timeout => $opt{t},
retry=> $opt{r},
forcetcp => $opt{T},
- qversion => $opt{v},
+ qversion => $opt{c},
qchaos => $opt{f},
separator=> $opt{S},
);
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Versions of packages fpdns depends on:
ii libio-socket-inet6-perl 2.54-1.1 Object interface for AF_INET6 doma
ii libnet-dns-fingerprint-perl 0.9.3-2library to determine DNS server ve
fpdns recommends no packages.
fpdns suggests no packages.
-- no debconf information
--
Thomas Parmelan -+- t...@ankh.fr.eu.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#491088: p3scan: Unable to free memory not previously allocated
tag 491088 + patch
thanks
Hi,
I think the following patch fixes all these problems (I explained what
was going on in #484676, but didn't submit a patch at that time).
Basically it's always the same thing: memory used after being freed (by
calling context_uninit(p) before using p->foo). The fix is to strdup()
the needed strings before calling context_uninit(p), and later using the
copy instead of p->foo. There's no need to free() the copy because all
these cases are LOG_EMERG cases, and do_log(LOG_EMERG, ...) ends the
program by exit(1).
Regards,
Tom
--
Thomas Parmelan
diff -ubBr p3scan-2.3.2-7/p3scan.c p3scan-2.3.2-7+tom1/p3scan.c
--- p3scan-2.3.2-7/p3scan.c 2009-05-01 11:11:28.0 +0200
+++ p3scan-2.3.2-7+tom1/p3scan.c2009-05-01 12:53:54.0 +0200
@@ -475,24 +475,26 @@
char *vi;
int vipos = 0;
+ char *maildir_name = strdup(p->maildir);
+
/* scan directory */
maildirlen=strlen(p->maildir);
if (stat (p->maildir, &s) == -1){
context_uninit(p);
- config->emergency=make_message("%s does not exist", p->maildir);
- do_log(LOG_EMERG, "ERR: %s does not exist", p->maildir);
+ config->emergency=make_message("%s does not exist", maildir_name);
+ do_log(LOG_EMERG, "ERR: %s does not exist", maildir_name);
return SCANNER_RET_ERR;
}
if (!S_ISDIR(s.st_mode)){
context_uninit(p);
- config->emergency=make_message("%s is not a directory", p->maildir);
- do_log(LOG_EMERG, "ERR: %s is not a directory", p->maildir);
+ config->emergency=make_message("%s is not a directory", maildir_name);
+ do_log(LOG_EMERG, "ERR: %s is not a directory", maildir_name);
return SCANNER_RET_ERR;
}
if ((dp = opendir (p->maildir)) == NULL){
context_uninit(p);
- config->emergency=make_message("Can't open directory %s", p->maildir);
- do_log(LOG_EMERG, "ERR: Can't open directory %s", p->maildir);
+ config->emergency=make_message("Can't open directory %s", maildir_name);
+ do_log(LOG_EMERG, "ERR: Can't open directory %s", maildir_name);
return SCANNER_RET_ERR;
}
vi=w_malloc(VISIZE);
@@ -831,10 +833,11 @@
do_log(LOG_DEBUG, "Unlinking deMIMEd files", p->maildir);
maildirlen=strlen(p->maildir);
if ((dp = opendir (p->maildir)) == NULL){
+ char *maildir_name = strdup(p->maildir);
p->errmsg=1;
context_uninit(p);
- config->emergency=make_message("Can't open directory %s to erase
files", p->maildir);
- do_log(LOG_EMERG, "ERR: Can't open directory %s to erase files",
p->maildir);
+ config->emergency=make_message("Can't open directory %s to erase
files", maildir_name);
+ do_log(LOG_EMERG, "ERR: Can't open directory %s to erase files",
maildir_name);
} else {
while ((de = readdir (dp)) != NULL){
if (strcmp (de->d_name, ".") == 0) continue;
@@ -1199,7 +1202,7 @@
}
pclose(scanner);
if (vlen < 512) virdef[vlen-1]='\0';
- else virdef[512]='\0';
+ else virdef[511]='\0';
paramlist_set(p->params, "%VDINFO%", virdef);
}
} else paramlist_set(p->params, "%VDINFO%", NULL);
@@ -1284,6 +1287,8 @@
unsigned long len;
int readerr=0, bufferr=0, subjfd=-1, extrafd=-1;
int ret;
+ char *vnmsg = strdup(p->vnmsg);
+ char *mailfile_name = strdup(p->mailfile);
#define CHMODCMD "/bin/chmod 0600"
if (p->cksmtp){
@@ -1373,8 +1378,8 @@
w_free(mail,"mail0");
if (p->extra) w_free(mailx,"mailx0");
context_uninit(p);
- config->emergency=make_message("Critical error opening file '%s',
Program aborted.", p->vnmsg);
- do_log(LOG_EMERG,"ERR: Critical error opening file '%s', Program
aborted.", p->vnmsg);
+ config->emergency=make_message("Critical error opening file '%s',
Program aborted.", vnmsg);
+ do_log(LOG_EMERG,"ERR: Critical error opening file '%s', Program
aborted.", vnmsg);
/* should not reach here as we are dead */
}
readerr=read(subjfd,comm,4096);
@@ -1395,8 +1400,8 @@
config->emergency=make_message("Can't open extra mail notification
template %s", EXTRA);
do_log(LOG_EMERG, "ERR: Can't open extra mail notification
template %s",EXTRA);
} else {
-config->emergency=make_message("Can't creade extra virus warning
Bug#484676: p3scan: Silently replaces config file then dies
Package: p3scan
Version: 2:2.3.2-5
Severity: important
Hi,
When upgrading p3scan, the /etc/p3scan/p3scan.mail link is silently
replaced with this :
# ls -l /etc/p3scan/p3scan.mail
lrwxrwxrwx 1 root root 79 May 27 00:23 /etc/p3scan/p3scan.mail ->
/home/rynge2/debian/p3scan/p3scan-2.3.2/debian/p3scan/etc/p3scan/p3scan-en.mail
wich, on my machine, is a danglink symlink... ;)
I believe the upstream Makefile is the culprit, but I don't know the
proper/Debian way of fixing this part of the bug.
I however tag this bug important because it breaks the configuration so that
next time a virus is detected, the template cannot be found, and in this very
case p3scan dies badly with the following error messages :
Jun 5 15:02:28 pern p3scan[8378]: ERR: Critical error opening file '', Program
aborted.
Jun 5 15:02:28 pern p3scan[8378]: ERR: Exiting now...
Jun 5 15:02:28 pern p3scan[8378]: ERR: Unable to free memory not previously
allocated: ø<84>Ò·ø<84>Ò·Ðå^K^HÐå^K^HÀ¨^A^P
Jun 5 15:02:28 pern p3scan[3906]: ERR: Attention: child with pid 8378 died
with abnormal termsignal (11)! This is probably a bug. Please report to the
author. numprocs is now 0
Jun 5 15:02:28 pern kernel: p3scan[8378]: segfault at 0004 eip 0804dd92
esp bfdf59f0 error 4
Jun 5 15:05:27 pern p3scan[3906]: P3Scan terminates now
After some investigation, I believe the problem lies somewhere in the following
horrible construct (which seems to be used all over the code!) :
subjfd = open(config->virustemplate, O_RDONLY);
if (subjfd<0){
w_free(mail,"mail0");
if (p->extra) w_free(mailx,"mailx0");
context_uninit(p);
config->emergency=make_message("Critical error opening file '%s',
Program aborted.", p->vnmsg);
do_log(LOG_EMERG,"ERR: Critical error opening file '%s', Program
aborted.", p->vnmsg);
/* should not reach here as we are dead */
}
p->vnmsg is used after calling context_uninit(p), which in turns does a
w_free(p).
So, something like this should fix it :
subjfd = open(config->virustemplate, O_RDONLY);
if (subjfd<0){
char *filename = strndup(p->vnmsg, strlen(p->vnmsg)+1);
w_free(mail,"mail0");
if (p->extra) w_free(mailx,"mailx0");
context_uninit(p);
config->emergency=make_message("Critical error opening file '%s',
Program aborted.", filename);
do_log(LOG_EMERG,"ERR: Critical error opening file '%s', Program
aborted.", filename);
/* should not reach here as we are dead */
}
Regards,
Tom
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.23.11-pern (PREEMPT)
Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Versions of packages p3scan depends on:
ii adduser 3.107add and remove users and groups
ii libc6 2.7-10 GNU C Library: Shared libraries
ii libpcre37.4-1+lenny1 Perl 5 Compatible Regular Expressi
ii libssl0.9.8 0.9.8g-10+lenny1 SSL shared libraries
p3scan recommends no packages.
-- no debconf information
--
Thomas Parmelan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397941: libnet-ip-perl: error in 'ipcount' example script
Package: libnet-ip-perl
Version: 1.25-1
Severity: normal
Tags: patch
Hi,
The 'ipcount' script (/usr/share/doc/libnet-ip-perl/examples/ipcount) is
really useful, but the -d option results in a fatal error :
$ ipcount -d 24 192.68.0.0/23
Invalid chars in IP 192.68.0.0+255 at /home/tom/bin/ipcount line 83.
The attached (very simple) patch fixes it :
$ ipcount2 -d 24 192.68.0.0/23
192.68.0/24
192.68.1/24
Found 2 /24s in 192.68.0/23
Regards,
Tom
--
Thomas Parmelan
--- ipcount 2006-08-05 02:03:14.0 +0200
+++ ipcount22006-11-10 15:06:08.0 +0100
@@ -80,7 +80,7 @@
while ($current->bincomp ('lt', $last))
{
- $new_ip->set($current->last_ip.'+'.$size) or die (Error());
+ $new_ip->set($current->last_ip.' + '.$size) or die (Error());
print $new_ip->print,"\n";
if ($opts{r})
@@ -88,7 +88,7 @@
print $new_ip->reverse_ip,"\n";
}
- $current->set($new_ip->last_ip .'+ 1') or die (Error());
+ $current->set($new_ip->last_ip .' + 1') or die (Error());
$count++;
}
Bug#387272: logcheck-database: new rule needed for send-uucp in inn2 2.4.3-1
Package: logcheck-database
Version: 1.2.47
Severity: minor
Tags: patch
Hi,
Starting with inn2 2.4.3-1 the send-uucp program logs a new message
which is not yet ignored. Here's a patch to ignore it.
Regards,
Tom
--- /etc/logcheck/ignore.d.server/innd.orig 2005-08-22 21:34:29.0
+0200
+++ /etc/logcheck/ignore.d.server/innd 2006-09-13 11:54:09.0 +0200
@@ -45,6 +45,7 @@
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ cnfsstat\[[0-9]+\]: Class (ARCHIV|SPOOL)
for groups matching \"[^[:space:]]+\" Buffer (ARCH|SPOOL)[0-9]+, len: [0-9]+
Mbytes, used: [0-9]+\.[0-9]+ Mbytes \([0-9 ]+\.[0-9]%\) [ 0-9]+ cycles$
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ send-uucp\[[0-9]+\]: checking site
[^[:space:]]+$
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ send-uucp\[[0-9]+\]: no articles for
[^[:space:]]+$
+^\w{3} [ :0-9]{11} [._[:alnum:]-]+ send-uucp\[[0-9]+\]: Flushing [^[:space:]]+
for site [^[:space:]]+$
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ send-uucp\[[0-9]+\]: batched articles for
[^[:space:]]+$
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ innfeed\[[0-9]+\]: ME time [0-9]+ idle
[0-9]+\([0-9]+\) blstats [0-9]+\([0-9]+\) stsfile [0-9]+\([0-9]+\) newart
[0-9]+\([0-9]+\) readart [0-9]+\([0-9]+\) prepart [0-9]+\([0-9]+\) read
[0-9]+\([0-9]+\) write [0-9]+\([0-9]+\) cb [0-9]+\([0-9]+\)$
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ innfeed\[[0-9]+\]: [._[:alnum:]-]+ spooling
no active connections$
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16.20-pern
Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
Versions of packages logcheck-database depends on:
ii debconf [debconf-2.0] 1.5.3 Debian configuration management sy
logcheck-database recommends no packages.
-- debconf information:
* logcheck-database/rules-directories-note:
* logcheck-database/standard-rename-note:
* logcheck-database/conffile-cleanup: true
* logcheck-database/security_level: paranoid
--
Thomas Parmelan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#385269: backup-manager: Outputs useless error message on first purge
Alexis Sukrieh <[EMAIL PROTECTED]> : > Indeed, that bug appeared in last development versions of BM, it's > reported upstream: Sorry, should have checked there. > Indeed, but as you can see in the upstream bug report, that bug > triggered a question: does the purging system needs to be recursive or > not (as archives are stored in the top-level directory)? In my setup, I have a subdirectory (where another host running backup-manager uploads its backups) that should be purged. Maybe it could be made conditional, defaulting to non-recursive (most setups would probably be OK with the default) ? -- Thomas Parmelan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#385269: backup-manager: updated patch for #385269
Hi,
Forget the explanation i gave in my previous mail, it was wrong. The
real problem lies in shell variables and function recursivity: in
clean_directory() $list is not declared as local, so when you have a
subdirectory and call clean_directory() on it, $list is modified.
The following patch fixes this for me but is probably specific to bash.
--- files.sh.orig^I2006-08-04 14:04:19.0 +0200
+++ files.sh.local^I2006-08-31 09:34:41.0 +0200
@@ -326,7 +326,7 @@
fi
# First list all the files to process
-list=$(mktemp /tmp/bm-list.XX)
+local list=$(mktemp /tmp/bm-list.XX)
for file in $directory/*
do
if [ ! -e $file ]; then
On the other hand, is there a good reason to implement clean_directory()
as recursive instead of just using find ? backup-manager-purge seems to
accept full paths so something like this might be better (untested):
clean_directory()
{
directory="$1"
purge_date=$(date +%Y%m%d --date "$BM_ARCHIVE_TTL days ago")
#__debug "Purging archives older than $purge_date"
if [ ! -d $directory ]; then
error "Directory given is not found."
fi
# First list all the files to process
list=$(mktemp /tmp/bm-list.XX)
find -H $directory -type f -print > $list
# Then ask bakup-manager-purge what to remove
for archive in `/usr/bin/backup-manager-purge --ttl=$BM_ARCHIVE_TTL < $list`
do
info "Removing archive \"\$archive\"."
rm -f $archive
done
rm -f $list
}
Or even:
clean_directory()
{
directory="$1"
purge_date=$(date +%Y%m%d --date "$BM_ARCHIVE_TTL days ago")
#__debug "Purging archives older than $purge_date"
if [ ! -d $directory ]; then
error "Directory given is not found."
fi
# First list all the files to process
# and ask bakup-manager-purge what to remove
list=$(mktemp /tmp/bm-list.XX)
find -H $directory -type f -print \
| /usr/bin/backup-manager-purge --ttl=$BM_ARCHIVE_TTL > $list
for archive in `cat $list`
do
info "Removing archive \"\$archive\"."
rm -f $archive
done
rm -f $list
}
Or even:
clean_directory()
{
directory="$1"
purge_date=$(date +%Y%m%d --date "$BM_ARCHIVE_TTL days ago")
#__debug "Purging archives older than $purge_date"
if [ ! -d $directory ]; then
error "Directory given is not found."
fi
for archive in ` find -H $directory -type f -print \
| /usr/bin/backup-manager-purge --ttl=$BM_ARCHIVE_TTL \
| xargs rm -v -- `
do
info "\$archive"
done
}
Of course all this might be perfectly wrong, because I didn't have my coffee
yet ;)
--
Thomas Parmelan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#385269: backup-manager: Outputs useless error message on first purge
Package: backup-manager Version: 0.7.4-1 Severity: minor Tags: patch Hi, On the first cron.daily run after installing backup-manager I received the following error : /etc/cron.daily/backup-manager: /usr/share/backup-manager/files.sh: line 318: /tmp/bm-list.I29365: No such file or directory I think the problem lies in the clean_directory() function in /usr/share/backup-manager/files.sh: the temporary file ($list) is never created if no file is found. Touching it should fix the problem, as in the following patch (untested) : --- files.sh2006-08-04 14:04:19.0 +0200 +++ /tmp/files.sh 2006-08-30 10:38:21.0 +0200 @@ -327,6 +327,7 @@ # First list all the files to process list=$(mktemp /tmp/bm-list.XX) +touch $list for file in $directory/* do if [ ! -e $file ]; then -- Thomas Parmelan -+- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#381820: backup-manager: More info: problem in postinst
Package: backup-manager Version: 0.7.4-1 Followup-For: Bug #381820 Hi Alexis ;) I think I came across a similar problem when installing backup-manager for the first time yesterday. The real problem is that the postinst script updates BM_TARBALL_DIRECTORIES, which is commented out in the default Debian configuration, so in fine only the default directories specified in BM_TARBALL_TARGETS (/etc and /boot) are considered for backup. Either the postinst script should be updated to work on the BM_TARBALL_TARGETS array, or the default configuration should use the deprecated BM_TARBALL_DIRECTORIES variable instead of the BM_TARBALL_TARGETS array. Best regards, Tom -- Thomas Parmelan -+- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
