Bug#618885: sasl2-bin: unowned files after purge (policy 6.8, 10.8)
On Sat, 30 Apr 2011, Russ Allbery wrote: Steve Langasek vor...@debian.org writes: I don't think that /etc/shadow qualifies as a configuration file, either; I would call it variable state information (→ /var/lib), but it lives in /etc because a) it has to be on the root filesystem, b) that's where it's always been so moving it somewhere else would be more trouble than it's worth. For other packages like sasl (or, say, samba, which stores all its authentication databases in /var/lib/samba in Debian), neither of these arguments holds AFAICS. Actually, now that I look at the sasldb2 file, I think you're right. I was under the mistaken impression that it was a file that administrators were expected to edit with a text editor, but it's actually a binary file format that's manipulated only via utilities. You're right; this probably doesn't belong in /etc at all and should instead be somewhere in /var. It has the same semanthics as /etc/shadow. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618885: Bug#624586: Bug#618885: sasl2-bin: unowned files after purge (policy 6.8, 10.8)
On Sun, 01 May 2011, Henrique de Moraes Holschuh wrote: On Sat, 30 Apr 2011, Russ Allbery wrote: Steve Langasek vor...@debian.org writes: I don't think that /etc/shadow qualifies as a configuration file, either; I would call it variable state information (→ /var/lib), but it lives in /etc because a) it has to be on the root filesystem, b) that's where it's always been so moving it somewhere else would be more trouble than it's worth. For other packages like sasl (or, say, samba, which stores all its authentication databases in /var/lib/samba in Debian), neither of these arguments holds AFAICS. Actually, now that I look at the sasldb2 file, I think you're right. I was under the mistaken impression that it was a file that administrators were expected to edit with a text editor, but it's actually a binary file format that's manipulated only via utilities. You're right; this probably doesn't belong in /etc at all and should instead be somewhere in /var. It has the same semanthics as /etc/shadow. Bah, just noticed the semanthics are broken because we have the libs outside of / anyway, so if anyone tried to use it for important stuff, it is already broken. We could purge it, yes, provided it is optional and we ask about it. It needs also to default to NO. It has to be fool-proof on every possible fucked up scenario, and in some of them an admin saying no! is the only thing that will save him from losing the authentication information (passwords) for his users. That said, relocating it to outside of /etc is a Major Bad Idea, and I very strongly recommend against it. Local configuration to move it somewhere else is already provided, but you just have extreme amount of application documentation and even certification tests that want it in /etc/sasldb2. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618885: Bug#624586: Bug#618885: sasl2-bin: unowned files after purge (policy 6.8, 10.8)
Henrique de Moraes Holschuh h...@debian.org writes: That said, relocating it to outside of /etc is a Major Bad Idea, and I very strongly recommend against it. Local configuration to move it somewhere else is already provided, but you just have extreme amount of application documentation and even certification tests that want it in /etc/sasldb2. Yes, there is that problem. I think it's a bug that it's in /etc, but it may be a wontfix bug due to other issues. -- 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#624586: Bug#618885: sasl2-bin: unowned files after purge (policy 6.8, 10.8)
On Fri, Apr 29, 2011 at 05:15:09PM +0200, Holger Levsen wrote:
On Freitag, 29. April 2011, Roberto C. Sánchez wrote:
Regardless, policy states the following in section 6.8:
5. The conffiles and any backup files (~-files, #*# files, %-files,
.dpkg-{old,new,tmp}, etc.) are removed.
Please note that /etc/sasldb2 is not a conffile. So, not removing it
should not be considered a policy violation.
Hm, right, at least on a quick search for config files I cannot find anything
in policy how config files should be treated, I can merely guess from the ucf
description that they exist...
10.7.3: If the existence of a [configuration] file is required for the
package to be sensibly configured it is the responsibility of the package
maintainer to provide maintainer scripts which correctly create, update and
maintain the file and remove it on purge.
So I don't think anything is actually missing in Policy?
(If one wishes to argue that /etc/sasldb2 is not a configuration file, then
it's also a policy violation for it to be under /etc.)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624586: Bug#618885: sasl2-bin: unowned files after purge (policy 6.8, 10.8)
Hi Steve, On Samstag, 30. April 2011, Steve Langasek wrote: 10.7.3: If the existence of a [configuration] file is required for the package to be sensibly configured it is the responsibility of the package maintainer to provide maintainer scripts which correctly create, update and maintain the file and remove it on purge. Thanks for this pointer! So I don't think anything is actually missing in Policy? Hm, there is no link from 6.8 to 10(.7) - maybe that would be useful. 6.8 misses files described in 10.6-10.8. If you don't think such a link would be useful, I guess this bug can be closed. cheers, Holger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624586: Bug#618885: sasl2-bin: unowned files after purge (policy 6.8, 10.8)
On Sat, Apr 30, 2011 at 12:02:46PM +0200, Holger Levsen wrote: On Samstag, 30. April 2011, Steve Langasek wrote: 10.7.3: If the existence of a [configuration] file is required for the package to be sensibly configured it is the responsibility of the package maintainer to provide maintainer scripts which correctly create, update and maintain the file and remove it on purge. Thanks for this pointer! So I don't think anything is actually missing in Policy? Hm, there is no link from 6.8 to 10(.7) - maybe that would be useful. 6.8 misses files described in 10.6-10.8. If you don't think such a link would be useful, I guess this bug can be closed. I don't think it's the right place for such a link; 6.8 describes the order in which actions are taken to remove and purge packages. It says nothing one way or the other about what actions the maintainer scripts are supposed to take, it's obvious to me that you need to look elsewhere in policy for this. But I'm not closing the bug, I'll leave it for a policy maintainer to decide on. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624586: Bug#618885: sasl2-bin: unowned files after purge (policy 6.8, 10.8)
Steve Langasek vor...@debian.org writes: (If one wishes to argue that /etc/sasldb2 is not a configuration file, then it's also a policy violation for it to be under /etc.) It's basically similar to /etc/shadow. -- 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#624586: Bug#618885: sasl2-bin: unowned files after purge (policy 6.8, 10.8)
On Sat, Apr 30, 2011 at 03:49:26PM -0700, Russ Allbery wrote: Steve Langasek vor...@debian.org writes: (If one wishes to argue that /etc/sasldb2 is not a configuration file, then it's also a policy violation for it to be under /etc.) It's basically similar to /etc/shadow. I don't think that /etc/shadow qualifies as a configuration file, either; I would call it variable state information (→ /var/lib), but it lives in /etc because a) it has to be on the root filesystem, b) that's where it's always been so moving it somewhere else would be more trouble than it's worth. For other packages like sasl (or, say, samba, which stores all its authentication databases in /var/lib/samba in Debian), neither of these arguments holds AFAICS. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618885: sasl2-bin: unowned files after purge (policy 6.8, 10.8)
Steve Langasek vor...@debian.org writes: I don't think that /etc/shadow qualifies as a configuration file, either; I would call it variable state information (→ /var/lib), but it lives in /etc because a) it has to be on the root filesystem, b) that's where it's always been so moving it somewhere else would be more trouble than it's worth. For other packages like sasl (or, say, samba, which stores all its authentication databases in /var/lib/samba in Debian), neither of these arguments holds AFAICS. Actually, now that I look at the sasldb2 file, I think you're right. I was under the mistaken impression that it was a file that administrators were expected to edit with a text editor, but it's actually a binary file format that's manipulated only via utilities. You're right; this probably doesn't belong in /etc at all and should instead be somewhere in /var. -- 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#618885: sasl2-bin: unowned files after purge (policy 6.8, 10.8)
Hi, On Sonntag, 24. April 2011, Roberto C. Sánchez wrote: On Sun, Apr 24, 2011 at 09:51:17AM +0200, Holger Levsen wrote: On Samstag, 23. April 2011, Roberto C. Sánchez wrote: This is not a bug. Yeah, right. It's not a bug because you dont care about policy which says you must purge the package on purge. Yes well, I'm sure you would appreciate it if, for example, purging postgresql also removed /var/lib/postgesql. I would not appreciate it, that much is for certain. That is, unless I specifically told the package that it was OK to do so. But then again, I guess you decided not to read the rest of my email where I point out that the adminitrator is *asked just such a question* in the case of /etc/sasldb2. I read it. And think its wrong. I'm glad most of the 18000 source packages respect policy. And this one does respect policy. It is only when it cannot obtain an answer from the admin on the disposition of /etc/sasldb2 that it errs on the side of caution and leaves the file untouched. I think every package should err on the side of policy. If you think policy should be different, go and try to change policy. The admin can always trivially remove it later. Restoring the file may not be so straightforward. not purging in the first place is very simple. and, the trivial way to remove it later is, doh, to purge, not to remove. bingo. cheers, Holger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618885: sasl2-bin: unowned files after purge (policy 6.8, 10.8)
Hi Holger,
On Fri, Apr 29, 2011 at 02:25:35PM +0200, Holger Levsen wrote:
Hi,
On Sonntag, 24. April 2011, Roberto C. Sánchez wrote:
And this one does respect policy. It is only when it cannot obtain an
answer from the admin on the disposition of /etc/sasldb2 that it errs on
the side of caution and leaves the file untouched.
I think every package should err on the side of policy. If you think policy
should be different, go and try to change policy.
The admin can always
trivially remove it later. Restoring the file may not be so
straightforward.
not purging in the first place is very simple. and, the trivial way to
remove
it later is, doh, to purge, not to remove. bingo.
Regardless, policy states the following in section 6.8:
5. The conffiles and any backup files (~-files, #*# files, %-files,
.dpkg-{old,new,tmp}, etc.) are removed.
Please note that /etc/sasldb2 is not a conffile. So, not removing it
should not be considered a policy violation.
I think that both of us feels strongly about our particular positions.
We may need to seek an alternate means of resolving this. Do you have
any ideas/suggestions on this?
Regards,
-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
signature.asc
Description: Digital signature
Bug#618885: sasl2-bin: unowned files after purge (policy 6.8, 10.8)
reassign 618885 debian-policy
thanks
Hi Roberto, hi policy maintainers!
On Freitag, 29. April 2011, Roberto C. Sánchez wrote:
Regardless, policy states the following in section 6.8:
5. The conffiles and any backup files (~-files, #*# files, %-files,
.dpkg-{old,new,tmp}, etc.) are removed.
Please note that /etc/sasldb2 is not a conffile. So, not removing it
should not be considered a policy violation.
Hm, right, at least on a quick search for config files I cannot find anything
in policy how config files should be treated, I can merely guess from the ucf
description that they exist...
I think that both of us feels strongly about our particular positions.
We may need to seek an alternate means of resolving this. Do you have
any ideas/suggestions on this?
yes, as you've seen by now :) I've now reassigned to policy as I've been
suggested to do on irc.
(And thank you very much indeed for looking for constructive ways out! Much
appreciated!)
cheers,
Holger
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618885: sasl2-bin: unowned files after purge (policy 6.8, 10.8)
On Samstag, 23. April 2011, Roberto C. Sánchez wrote: This is not a bug. Yeah, right. It's not a bug because you dont care about policy which says you must purge the package on purge. I'm glad most of the 18000 source packages respect policy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618885: sasl2-bin: unowned files after purge (policy 6.8, 10.8)
On Sun, Apr 24, 2011 at 09:51:17AM +0200, Holger Levsen wrote: On Samstag, 23. April 2011, Roberto C. Sánchez wrote: This is not a bug. Yeah, right. It's not a bug because you dont care about policy which says you must purge the package on purge. Yes well, I'm sure you would appreciate it if, for example, purging postgresql also removed /var/lib/postgesql. I would not appreciate it, that much is for certain. That is, unless I specifically told the package that it was OK to do so. But then again, I guess you decided not to read the rest of my email where I point out that the adminitrator is *asked just such a question* in the case of /etc/sasldb2. I'm glad most of the 18000 source packages respect policy. And this one does respect policy. It is only when it cannot obtain an answer from the admin on the disposition of /etc/sasldb2 that it errs on the side of caution and leaves the file untouched. The admin can always trivially remove it later. Restoring the file may not be so straightforward. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#618885: sasl2-bin: unowned files after purge (policy 6.8, 10.8)
Package: sasl2-bin Version: 2.1.23.dfsg1-8 Severity: important User: debian...@lists.debian.org Usertags: piuparts piuparts.d.o Hi, during a test with piuparts I noticed your package left unowned files on the system after purge, which is a violation of policy 6.8 (or 10.8): http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails Filing this as important as having a piuparts clean archive is a release goal since lenny. From the attached log (scroll to the bottom...): 0m20.7s ERROR: FAIL: Package purging left files on system: /etc/sasldb2 not owned cheers, Holger Start: 2011-03-17 09:30:41 UTC Package: sasl2-bin Priority: optional Section: utils Installed-Size: 508 Maintainer: Debian Cyrus SASL Team pkg-cyrus-sasl2-debian-de...@lists.alioth.debian.org Architecture: amd64 Source: cyrus-sasl2 Version: 2.1.23.dfsg1-8 Depends: libsasl2-2 (= 2.1.23.dfsg1-8), libc6 (= 2.4), libcomerr2 (= 1.01), libdb4.8, libgssapi-krb5-2 (= 1.6.dfsg.2), libk5crypto3 (= 1.6.dfsg.2), libkrb5-3 (= 1.7dfsg), libldap-2.4-2 (= 2.4.7), libpam0g (= 0.99.7.1), libssl0.9.8 (= 0.9.8m-1), debconf (= 0.5) | debconf-2.0, lsb-base (= 3.0-6), db4.8-util, debconf (= 1.4.69) | cdebconf (= 0.39) Filename: pool/main/c/cyrus-sasl2/sasl2-bin_2.1.23.dfsg1-8_amd64.deb Size: 179922 MD5sum: c45fb950ae4fb646dd12f36bde14e541 SHA1: 961391da4f409e44e6e941cb13130cd26c3bb6d8 SHA256: 3df4be5dc4f89e9077b1bb39e937a5b620ffe1743466c32104bddffcb0a1a63c Description: Cyrus SASL - administration programs for SASL users database This is the Cyrus SASL API implementation, version 2.1. See package libsasl2-2 and RFC for more information. . This package contains administration programs for the SASL users database and common binary files for plugin modules. Homepage: http://cyrusimap.web.cmu.edu/ Tag: admin::user-management, interface::commandline, role::program, scope::utility, security::authentication Executing: sudo /org/piuparts.debian.org/sbin/piuparts --warn-symlinks --warn-on-others --skip-logrotatefiles-test --scriptsdir /etc/piuparts/scripts/ --tmpdir /org/piuparts.debian.org/tmp -ad sid -b sid.tar.gz --mirror http://piatti.debian.org/debian/ sasl2-bin Guessed: debian 0m0.0s INFO: -- 0m0.0s INFO: To quickly glance what went wrong, scroll down to the bottom of this logfile. 0m0.0s INFO: FAQ available at http://wiki.debian.org/piuparts/FAQ 0m0.0s INFO: -- 0m0.0s INFO: piuparts version 0.40~201102250909 starting up. 0m0.0s INFO: Command line arguments: /org/piuparts.debian.org/sbin/piuparts --warn-symlinks --warn-on-others --skip-logrotatefiles-test --scriptsdir /etc/piuparts/scripts/ --tmpdir /org/piuparts.debian.org/tmp -ad sid -b sid.tar.gz --mirror http://piatti.debian.org/debian/ sasl2-bin 0m0.0s INFO: Running on: Linux piatti 2.6.32-5-amd64 #1 SMP Wed Jan 12 03:40:32 UTC 2011 x86_64 0m0.0s DEBUG: Created temporary directory /org/piuparts.debian.org/tmp/tmpCXgHo2 0m0.0s DEBUG: Unpacking sid.tar.gz into /org/piuparts.debian.org/tmp/tmpCXgHo2 0m0.0s DEBUG: Starting command: ['tar', '-C', '/org/piuparts.debian.org/tmp/tmpCXgHo2', '-zxf', 'sid.tar.gz'] 0m2.0s DEBUG: Command ok: ['tar', '-C', '/org/piuparts.debian.org/tmp/tmpCXgHo2', '-zxf', 'sid.tar.gz'] 0m2.0s DEBUG: Created policy-rc.d and chmodded it. 0m2.0s DEBUG: Starting command: ['chroot', '/org/piuparts.debian.org/tmp/tmpCXgHo2', 'apt-get', 'update'] 0m10.5s DUMP: Get:1 http://piatti.debian.org sid InRelease [147 kB] Ign http://piatti.debian.org sid/main amd64 Packages/DiffIndex Ign http://piatti.debian.org sid/contrib amd64 Packages/DiffIndex Ign http://piatti.debian.org sid/non-free amd64 Packages/DiffIndex Ign http://piatti.debian.org sid/contrib TranslationIndex Ign http://piatti.debian.org sid/main TranslationIndex Ign http://piatti.debian.org sid/non-free TranslationIndex Get:2 http://piatti.debian.org sid/main amd64 Packages [9195 kB] Get:3 http://piatti.debian.org sid/contrib amd64 Packages [72.7 kB] Get:4 http://piatti.debian.org sid/non-free amd64 Packages [142 kB] Ign http://piatti.debian.org sid/contrib Translation-en Ign http://piatti.debian.org sid/main Translation-en Ign http://piatti.debian.org sid/non-free Translation-en Fetched 9556 kB in 1s (7324 kB/s) Reading package lists... 0m10.5s DEBUG: Command ok: ['chroot', '/org/piuparts.debian.org/tmp/tmpCXgHo2', 'apt-get', 'update'] 0m10.5s DEBUG: Starting command: ['chroot', '/org/piuparts.debian.org/tmp/tmpCXgHo2', 'mount', '-t', 'proc', 'proc', '/proc'] 0m10.5s DEBUG: Command ok: ['chroot', '/org/piuparts.debian.org/tmp/tmpCXgHo2', 'mount', '-t', 'proc', 'proc', '/proc'] 0m10.5s DEBUG: Starting command: ['chroot', '/org/piuparts.debian.org/tmp/tmpCXgHo2', 'apt-get', '-yf', 'upgrade'] 0m12.9s DUMP: Reading package lists... Building dependency tree... The following packages will be upgraded: apt
