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

[Ola Lundqvist]

Hi

On Wed, Apr 18, 2007 at 05:17:57AM -0700, Steve Langasek wrote:
> 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.

Ok.

> > 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.

Ok, then something else must have happend. I know that it was not the
best thing to write a bug report the day after, but during the time
of the upgrade I was in a quite high time pressure. :)

> > > 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.

I understand. I'll check later today if I have the information in the
terminal for the upgrade.

> > > > 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.

One way is to allow startup of the daemon even if this bind fails, and
disable IPv6 support in that case.

> > > 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.

Ok.

My intention with the bug report was to tell that there are potential
problems with upgrade. Just to inform you. You do what you like
with this bug report.

Personally I'm satisfied with the current state as the server is
running just fine now when upgraded. I have to set -4 option though.

Regards,

// Ola

> 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/
> 

-- 
 --- Ola Lundqvist systemkonsult --- M Sc in IT Engineering ----
/  ola at opalsys.net                   Annebergsslingan 37        \
|  opal at debian.org                   654 65 KARLSTAD            |
|  http://opalsys.net/               Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---------------------------------------------------------------