Bug#453519: [Logcheck-devel] Bug#453519: logcheck-database: amavisd-new file looks like the one shipped by amavisd-new
On Sun, Aug 23, 2009 at 06:47:56PM -0700, Russ Allbery wrote: +[ -e $CONFFILE ] || return 0 It probably doesn't matter, but I'd use -f here. You're right, it would be better. I would tend to not do this and instead just leave the file in place since it does still work. I think it's arguable that moving the file aside such that it is no longer active would constitute discarding user configuration in a way that logcheck shouldn't, Policy-wise, do. Yeah, that conffile meddling is a thorny issue. My concern is that this would introduce a discrepancy between the two cases; why is it OK to move a modified conffile if it's been dropped out of the package today, but not if it's been dropped two years ago? (Not to mention that dpkg will probably confuse the latter for the former.) I also worry a bit about old crappy rules which could match too much; although logcheck probably should not be relied upon for security, it seems wrong to silently leave them behind. In an ideal world, I guess we should ask the user. The wiki can afford to sidestep the issue, because removing a conffile usually means it is obsolete and would no longer be read anyway. However, that's not the case here, and moving the conffiles does have an impact. :( -- Linux: Where Don't We Want To Go Today? -- Submitted by Pancrazio De Mauro, paraphrasing some well-known sales talk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#453519: [Logcheck-devel] Bug#453519: Bug#453519: logcheck-database: amavisd-new file looks like the one shipped by amavisd-new
Frédéric Brière fbri...@fbriere.net writes: My concern is that this would introduce a discrepancy between the two cases; why is it OK to move a modified conffile if it's been dropped out of the package today, but not if it's been dropped two years ago? (Not to mention that dpkg will probably confuse the latter for the former.) If it's been modified, I actually wouldn't do it for that case either. So I guess I'm arguing that even the previous behavior was not what I would have done. I also worry a bit about old crappy rules which could match too much; although logcheck probably should not be relied upon for security, it seems wrong to silently leave them behind. Hm, yes, although that's also somewhat combining two different issues. Generally the best way of fixing bad rules like that is to ship a newer version of the configuration file that cleans out the bad rules. So this would apply to cases where there were both bad rules *and* the configuration file for that application was dropped, which I would expect to be less common. Or are there a lot of existing cases where we know that the dropped configuration files contained bad rules? In an ideal world, I guess we should ask the user. The wiki can afford to sidestep the issue, because removing a conffile usually means it is obsolete and would no longer be read anyway. However, that's not the case here, and moving the conffiles does have an impact. :( Yeah, exactly. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#453519: logcheck-database: amavisd-new file looks like the one shipped by amavisd-new
On Mon, Aug 24, 2009 at 03:39:06PM -0700, Russ Allbery wrote: Or are there a lot of existing cases where we know that the dropped configuration files contained bad rules? Probably not, but I'm too lazy to check. :) A non-empty cracking.d/logcheck might be problematic, though. In an ideal world, I guess we should ask the user. The wiki can afford A somewhat convoluted way to do this would be to bring those files back from the dead, empty aside from comments. dpkg would then prompt the user if those files had been modified (or if the user purged and re-installed logcheck). After one release cycle, we remove them for good, deleting them if they are pristine, and leaving them in place otherwise. It's a somewhat ugly solution, and it doesn't for conflicting files lacking a Replaces (amavisd-new, sendmail-base and thttpd). It might be useful for cracking.d/logcheck, though. (Is it too late to curse the dpkg team? g) -- /* * Buddy system. Hairy. You really aren't expected to understand this * */ -- From /usr/src/linux/mm/page_alloc.cA -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#453519: logcheck-database: amavisd-new file looks like the one shipped by amavisd-new
On Sat, Aug 22, 2009 at 11:21:35AM -0400, Frédéric Brière wrote:
There's no way to tell this manually-added file apart from another one
which was left around as cruft.
Actually, this doesn't bother dpkg at all, which will gladly convert
such a file into a conffile when the occasion comes. If it's good
enough for dpkg, it's good enough for me.
So, here's the commit I made to remove old crufty files. I tested it as
much as possible, but a little peer review certainly wouldn't hurt.
commit 7c0a9db4606434b8366b64f82b31f428228a9237
Author: Frédéric Brière fbri...@fbriere.net
Date: Sun Aug 23 16:24:37 2009 -0400
Support removing even older conffiles in logcheck-database's preinst
Many conffiles have come and gone throughout logcheck's history, and due
to the fact that dpkg did not remove them, these obsolete files are
still left rotting on many installations. (See bug #453519 for an
example.)
This attempts to delete those files on install/upgrade, after making
sure they have not been adopted by another package in the meantime.
If a file is deemed to have been modified, it will be backed up and
subsequently ignored by logcheck.
Since there may no longer be any record of that conffile[*], a list of
past MD5 checksums must be provided in $OLD_CONFFILES. More than one
checksum is allowed per conffile, as the package may have been upgraded
past the last modification, leaving the conffile in an older state.
Unlike with rm_conffile(), we do bother comparing package versions here,
as the call to dpkg-query --search can be costly. One single version
check should be enough, as we don't plan (with any luck) to add any
files to that list.
[*] Actually, dpkg will keep a record of that conffile up until the
package is purged, or another package adopts it.
diff --git a/debian/logcheck-database.preinst b/debian/logcheck-database.preinst
index c2d6589..a7e3eca 100644
--- a/debian/logcheck-database.preinst
+++ b/debian/logcheck-database.preinst
@@ -18,10 +18,22 @@ set -e
# deleted (or backed away) at the next upgrade.
#
# Conffiles must be listed here from the very moment of their removal; adding
-# them later on will not work correctly.
+# them later on will not work correctly. If you ever forget, you'll need to
+# add them to OLD_CONFFILES below, instead.
REMOVED_CONFFILES=
+# List of conffiles which were once part of this package a long time ago, and
+# have never been cleaned up properly. They will be removed if they are still
+# around, unclaimed, and match any specified MD5 checksum.
+#
+# Each line contains one filename, followed by one or many MD5 checksums, all
+# separated by whitespace. When adding files to this list,
+# OLD_CONFFILES_VERSION needs to be bumped up to the current version.
+
+OLD_CONFFILES_VERSION=1.3.4
+OLD_CONFFILES=
+
# Copied from http://wiki.debian.org/DpkgConffileHandling
rm_conffile() {
@@ -46,6 +58,33 @@ rm_conffile() {
fi
}
+# Delete an old forgotten conffile if it's still around and unclaimed, and
+# matches one of any MD5 checksums. If no checksum matches, it will be
+# backed up and move aside.
+rm_old_conffile() {
+local PKGNAME=$1
+local CONFFILE=$2
+shift 2
+
+[ -e $CONFFILE ] || return 0
+
+# Leave that file alone if it now belongs to another package
+dpkg-query --search $CONFFILE /dev/null 21 return 0
+
+local md5sum=$(md5sum $CONFFILE | sed -e 's/ .*//')
+for OLD_MD5SUM in $@; do
+if [ $md5sum = $OLD_MD5SUM ]; then
+echo Removing obsolete conffile $CONFFILE ...
+rm -f $CONFFILE
+return
+fi
+done
+
+echo Obsolete conffile $CONFFILE has been modified by you.
+echo Saving as $CONFFILE.dpkg-bak ...
+mv -f $CONFFILE $CONFFILE.dpkg-bak
+}
+
case $1 in
install|upgrade)
@@ -56,6 +95,21 @@ case $1 in
rm_conffile logcheck-database $CONFFILE
done
fi
+
+# Remove $OLD_CONFFILES on a new install, or when upgrading
+# from an old version.
+if dpkg --compare-versions $2 lt $OLD_CONFFILES_VERSION; then
+echo $OLD_CONFFILES | while read CONFFILE MD5SUMS; do
+if [ $2 ]; then
+ # It's actually quite possible that the file still
+ # belongs to us, and that we can avoid a costly call to
+ # dpkg-query --search.
+rm_conffile logcheck-database $CONFFILE
+fi
+
+rm_old_conffile logcheck-database $CONFFILE $MD5SUMS
+done
+fi
;;
abort-upgrade)
--
I did this 'cause Linux gives me a woody. It doesn't generate revenue.
-- Dave '-ddt-` Taylor, announcing DOOM for Linux
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#453519: [Logcheck-devel] Bug#453519: logcheck-database: amavisd-new file looks like the one shipped by amavisd-new
Frédéric Brière fbri...@fbriere.net writes: +[ -e $CONFFILE ] || return 0 It probably doesn't matter, but I'd use -f here. +echo Obsolete conffile $CONFFILE has been modified by you. +echo Saving as $CONFFILE.dpkg-bak ... +mv -f $CONFFILE $CONFFILE.dpkg-bak I would tend to not do this and instead just leave the file in place since it does still work. I think it's arguable that moving the file aside such that it is no longer active would constitute discarding user configuration in a way that logcheck shouldn't, Policy-wise, do. Otherwise, looks great here. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#453519: logcheck-database: amavisd-new file looks like the one shipped by amavisd-new
On Fri, Aug 21, 2009 at 08:32:40PM -0400, Frédéric Brière wrote: (If we really want to nitpick, if the user copied the file contents from X+1 manually before upgrading to X+2, Policy might possibly require us to leave that file alone.) Here's a similar but less contrieved situation: I install lenny on a brand new server. For some reason, I'm quite unhappy with file $FOO having been withdrawn from logcheck, so I just grab a copy from somewhere else (possibly an older server). There's no way to tell this manually-added file apart from another one which was left around as cruft. -- Whoa...I did a 'zcat /vmlinuz /dev/audio' and I think I heard God... -- mikecd on #Linux -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#453519: logcheck-database: amavisd-new file looks like the one shipped by amavisd-new
On Mon, Mar 17, 2008 at 04:13:03PM -0700, Russ Allbery wrote: Conffiles are not automatically deleted on upgrade. You have to remove It would appear that logcheck has shed many files over the years: $ git log --summary master origin/1.2 -- rulefiles/linux/ | \ grep 'delete mode' What should be done about that? These files are long gone, so we can't rely on dpkg to tell us whether they've been modified. (And some of them have migrated to other packages.) Should we just let them rot in place? -- On the Internet, no one knows you're using Windows NT -- Submitted by Ramiro Estrugo, restr...@fateware.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#453519: [Logcheck-devel] Bug#453519: logcheck-database: amavisd-new file looks like the one shipped by amavisd-new
Frédéric Brière fbri...@fbriere.net writes: On Mon, Mar 17, 2008 at 04:13:03PM -0700, Russ Allbery wrote: Conffiles are not automatically deleted on upgrade. You have to remove It would appear that logcheck has shed many files over the years: $ git log --summary master origin/1.2 -- rulefiles/linux/ | \ grep 'delete mode' What should be done about that? These files are long gone, so we can't rely on dpkg to tell us whether they've been modified. (And some of them have migrated to other packages.) Should we just let them rot in place? Do we have the md5 checksums of the last version that we shipped with the package anywhere? If we did, we could remove them if they matched. Otherwise, I think we have to leave them to rot. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#453519: logcheck-database: amavisd-new file looks like the one shipped by amavisd-new
On Fri, Aug 21, 2009 at 12:03:41PM -0700, Russ Allbery wrote: Do we have the md5 checksums of the last version that we shipped with the package anywhere? Yes, that can be easily extracted. I see two issues with this: First, there's no guarantee that the file will be the last version shipped. If a file was included in version X, modified in X+1, and removed in X+2, it's possible that the user upgraded directly from X to X+2, and therefore doesn't have the last version of that file. Checking for the last version is therefore a best effort, but not foolproof. (If we really want to nitpick, if the user copied the file contents from X+1 manually before upgrading to X+2, Policy might possibly require us to leave that file alone.) Second, it's quite possible that the file now belongs to another package, with the exact same contents as our last version of it. I guess that could be avoided by asking dpkg whether it is currently owned. Anybody eager to write that mess of a script? g -- *** PUBLIC flooding detected from erikyyy lewnie THAT's an erik, pholx ;) -- Seen on #LinuxGER -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#453519: [Logcheck-devel] Bug#453519: logcheck-database: amavisd-new file looks like the one shipped by amavisd-new
Frédéric Brière fbri...@fbriere.net writes: Yes, that can be easily extracted. I see two issues with this: First, there's no guarantee that the file will be the last version shipped. If a file was included in version X, modified in X+1, and removed in X+2, it's possible that the user upgraded directly from X to X+2, and therefore doesn't have the last version of that file. Checking for the last version is therefore a best effort, but not foolproof. (If we really want to nitpick, if the user copied the file contents from X+1 manually before upgrading to X+2, Policy might possibly require us to leave that file alone.) Second, it's quite possible that the file now belongs to another package, with the exact same contents as our last version of it. I guess that could be avoided by asking dpkg whether it is currently owned. Anybody eager to write that mess of a script? g It's not really that much of a mess, but it's kind of annoying and a maintenance hassle. Basically, it's a list of file names and MD5 checksums where if that file name exists and the contents match that MD5 checksum, we remove the file on upgrade. I suspect, though, that we wouldn't want to remove the file if it had moved out of this package into another, which means that it probably wouldn't solve the original problem. And maintaining the list of MD5 checksums is annoying, particularly as you mention if we want to deal with older versions. It would be nice if dpkg provided some clean way of handling this. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#453519: logcheck-database: amavisd-new file looks like the one shipped by amavisd-new
On Mon, Mar 17, 2008 at 11:48:47PM +0100, Marc Bobillier wrote: Yes, with logcheck and logcheck-database 1.2.63: Yeah, I'm quite confused: [EMAIL PROTECTED]:~$ dpkg -S /etc/logcheck/violations.ignore.d/logcheck-amavisd-new logcheck-database: /etc/logcheck/violations.ignore.d/logcheck-amavisd-new [EMAIL PROTECTED]:~$ grep amavis /var/lib/dpkg/info/logcheck-database.list /etc/logcheck/ignore.d.server/amavisd-new /etc/logcheck/violations.ignore.d/logcheck-amavisd-new But: [EMAIL PROTECTED]:~$ grep amavis /var/lib/dpkg/info/logcheck-database.conffiles [EMAIL PROTECTED]:~$ dpkg -c logcheck-database_1.2.63_all.deb | grep amavis [EMAIL PROTECTED]:~$ sudo ls /etc/logcheck/violations.ignore.d/logcheck-amavisd-new ls: cannot access /etc/logcheck/violations.ignore.d/logcheck-amavisd-new: No such file or directory On my machine, both amavisd-new files (as well as thttpd) are in .list, but don't actually exist. Could this be a dpkg bug? -- * SynrG notes that the number of configuration questions to answer in sendmail is NON-TRIVIAL -- Seen on #Debian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453519: logcheck-database: amavisd-new file looks like the one shipped by amavisd-new
* Frédéric Brière [2008-03-16 02:25:50 -0400]: tags 453519 moreinfo In article [EMAIL PROTECTED] you wrote: Version: 1.2.63 The content of the file /etc/logcheck/violations.ignore.d/logcheck-amavisd-new is contained already in /etc/logcheck/violations.ignore.d/amavisd-new (this one shipped with amavisd-new). Both amavisd-new rules files were removed in 1.2.63 for that exact reason. Are you saying that they are still present on your machine? Yes, with logcheck and logcheck-database 1.2.63: $ dpkg -S /etc/logcheck/violations.ignore.d/logcheck-amavisd-new logcheck-database: /etc/logcheck/violations.ignore.d/logcheck-amavisd -new $ dpkg -S /etc/logcheck/violations.ignore.d/amavisd-new amavisd-new: /etc/logcheck/violations.ignore.d/amavisd-new -- marc
Bug#453519: [Logcheck-devel] Bug#453519: logcheck-database: amavisd-new file looks like the one shipped by amavisd-new
Frédéric Brière [EMAIL PROTECTED] writes: In article [EMAIL PROTECTED] you wrote: Version: 1.2.63 The content of the file /etc/logcheck/violations.ignore.d/logcheck-amavisd-new is contained already in /etc/logcheck/violations.ignore.d/amavisd-new (this one shipped with amavisd-new). Both amavisd-new rules files were removed in 1.2.63 for that exact reason. Are you saying that they are still present on your machine? Conffiles are not automatically deleted on upgrade. You have to remove them in the postinst of the package and you have to manually check first if they're unmodified. There's a recipe for how to do this at: http://wiki.debian.org/DpkgConffileHandling -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Bug#453519: logcheck-database: amavisd-new file looks like the one shipped by amavisd-new
tags 453519 moreinfo thanks In article [EMAIL PROTECTED] you wrote: Version: 1.2.63 The content of the file /etc/logcheck/violations.ignore.d/logcheck-amavisd-new is contained already in /etc/logcheck/violations.ignore.d/amavisd-new (this one shipped with amavisd-new). Both amavisd-new rules files were removed in 1.2.63 for that exact reason. Are you saying that they are still present on your machine? -- sangr home is where the highest bandwidth is -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453519: logcheck-database: amavisd-new file looks like the one shipped by amavisd-new
Package: logcheck-database Version: 1.2.63 Severity: minor The content of the file /etc/logcheck/violations.ignore.d/logcheck-amavisd-new is contained already in /etc/logcheck/violations.ignore.d/amavisd-new (this one shipped with amavisd-new). Regards marc -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (50, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-486 Locale: LANG=en_US.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- debconf information: * logcheck-database/rules-directories-note: logcheck-database/standard-rename-note: logcheck-database/conffile-cleanup: false -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
