Bug#419560: [Pkg-openldap-devel] Bug#419560: Upgrade problems.

[Steve Langasek]

On Wed, Apr 18, 2007 at 01:48:40PM +0200, Ola Lundqvist wrote:

> > Sorry, I don't see how this is possible at all, and no one else has reported
> > seeing this problem on upgrade.  The slapd package depends on adduser, and
> > the current slapd postinst unconditionally calls:

> Can it be so that the old postinst script was used for some strange reason?

Only if there were a bug in dpkg; the "point of no return" in an upgrade is
immediately after the new version is unpacked and the old version's postrm
is called with "upgrade <new-version>" as arguments, so if that failed the
conffile should have been rolled back by dpkg and if it succeeded the old
maintainer scripts should have been completely removed from the system.

> It is the best thing I can consider. Or maybe prerm or preinst?

Again, this shouldn't have gone anywhere near a failure to start slapd,
because that doesn't happen until the postinst.

> > There are no invocations of invoke-rc.d slapd prior to this anywhere in the
> > upgrade process, the daemon restart is the last thing done in the postinst;
> > and nothing but the init script uses the openldap user/group, which is
> > referenced only from /etc/default/slapd.  So without a log of the *earliest*
> > stages of this upgrade, I don't see that there's any hope of figuring out
> > what happened to cause this problem for you.

> I see. Too bad that I do not think I have that left.

Ok, then I guess this failure is doomed to go unexplained.

> > > 3) The upgrade continue, and now the user is created it chowns
> > >    a number of files and do convert from old data to the new.
> > > 4) But the start of slapd do not work well and the upgrade
> > >    of the package terminates.

> > Well, again here we would need to know what didn't "work well".

> In this case I have figured out that I needed the -4 option as I do
> not have IPv6 support in this virtual server. That is probably the
> reason for it.

Hmm, ok.  That means the kernel doesn't allow an IPv6-style bind in the
virtual server, right?  I don't see any good way to handle that specifically
on upgrade.

> > No, I disagree.  The slapd maintainer scripts are deliberately very
> > conservative with what they do with all user data.  Inconveniencing users
> > with a requirement to manually fix up the data directory is better (not
> > good, but better) than trashing the user's directory by mistake.

> Ok. In this case I suggest to improve the log message with an suggestion
> on how to proceed.

Yah, no disagreement there; no time on my part to look into it currently
though.

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon at debian.org                                   http://www.debian.org/