Hi Christian, thanks for looking into this.
What we have here is a conffile shared between two packages that Conflicts+Replaces each other. That's even more weird than placing conffiles in multi-arch:same packages ... at least they don't ship different versions (but they did in lenny ...) I think the conffiles part should be factored out to a separate package (e.g. "sudoers"). But probably not for jessie :-) If I see this correctly, in wheezy /etc/sudoers finally became a conffile. So the preinst scripts are wrong - they should not touch (or move around) the unmodified wheezy conffile. And while switching sudo->sudo-ldap the following happens: sudo gets removed, conffile remains sudo-ldap.preinst gets called with no previous version, so the conffile handling is activated - the md5sum matches that one from wheezy and therefore /etc/sudoers is moved aside sudo-ldap replaces sudo and takes over a deleted conffile this is not reinstated - per policy sudo-ldap.postinst explodes on the deleted conffile. could you try how switching between sudo and sudo-ldap works if the wheezy md5sum is removed from teh preinst? Andreas On 2015-01-28 23:56, Christian Kastner wrote: > Control: tags -1 + patch > > On Sat, 24 Jan 2015 12:05:52 +0100 Andreas Beckmann <a...@debian.org> wrote: >> The upgrade to jessie with sudo-ldap/jessie went smooth, and thereafter >> I wanted to switch to sudo/jessie, which failed due to missing >> /etc/sudoers, the problem is reproducible in plain jessie, too: >> >> # apt-get install sudo > <snip> >> WARNING: /etc/sudoers not present! >> chown: cannot access '/etc/sudoers': No such file or directory >> dpkg: error processing package sudo (--configure): >> subprocess installed post-installation script returned error exit status 1 >> Errors were encountered while processing: >> sudo >> E: Sub-process /usr/bin/dpkg returned an error code (1) > > The problem stems from the solution used to avoid an unnecessary action > prompt for a conffile change when in fact there was no change. See bugs > #636049, #612532, #660594. > > 1. Each respective preinst checks, via md5sum, if /etc/sudoers has > changed. Iff not, it is moved to a temporary location at > /etc/sudoers.pre-conffile. > > 2. Each respective postinst checks whether /etc/sudoers is present, > and warns if it isn't (see WARNING quoted above). > > 3. Then follows an unconditional chown of /etc/sudoers, and when this > fails, postinst aborts because of set -e. > > This is the first problem. It is of course possible for this file to be > generally absent (it's a conffile, and the user might have forcefully > removed it), so this chown should be guarded by a test for existence. Is sudo useful at all if /etc/sudoers is missing? > 3. Later on, there is an attempted to remove the temporarily > renamed /etc/sudoers.pre-conffile mentioned above: > >> # if we've gotten this far .. remove the saved, unchanged old sudoers file >> rm -f /etc/sudoers.pre-conffile that is an *old* pristine sudoer that was not a conffile > This I don't understand. Why remove it? This file can only exist because > of step 1. above, and if it exists, the purpose was to just temporarily > move it out of the way to avoid a conffile-change question. Why is it > being removed now? Shouldn't it just be moved back in step 2.? dpkg should have installed a new sudoers (that is now a conffile) the .pre-conffile is a backup that should be restored in failed-upgrade or removed in postinst, so the intention is right, just the preinst should not have touch a conffile > Please find attached a debdiff against the version in t-p-u that > > A. Makes the chmod/chown conditional on the existence of /etc/sudoers maybe its better to explode here if sudoers does not exist - I assume sudo will be nonfunctional without it > B. When /etc/sudoers.pre-conffile exists, moves it back to > /etc/sudoers. This is done unconditionally since the very > existence of /etc/sudoers.pre-conffile implies that it is the > pristine package version (recall the md5sum check above). So > the user did not delete or change /etc/sudoers, and we want it > back. there was never the intention to restore this in a pre-conffile to conffile upgrade case ... > I'm confident that change A. is correct and necessary, but change B. > depends on whether I understood the problem the code is trying to solve > correctly! > > I tested this with various combinations (pristine, changed, deleted > /etc/sudoers), and TTBOMYK the result is policy-conform. Additional > testing would be highly appreciated, though. > > Regards, > Christian > -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
