[vorlon@debian.org: [Pkg-openldap-devel] Problems with current slapd postinst]

[Torsten Landschoff]

--a8Wt8u1KmwUX3Y2C
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Steve,=20

Thanks for your ongoing work on slapd! FYI: I just uploaded 2.2.23-3
with your patches, I think they really warrant an upload.

On Wed, Apr 20, 2005 at 03:21:11AM -0700, Steve Langasek wrote:
> Well, I definitely don't think the package should be asking *more*
> questions than it already does.  Given that the existing question is asked
> at medium priority, I suppose it doesn't matter much if it stays.

:) Basically I'd like the upgrade to just ask if an automatic upgrade
should be tried if debconf priority is at least high.=20

> Personally, I still don't understand why anyone would not want to use the
> automatic upgrade; except for Stephen Frost, but that's just because he
> apparently doesn't trust his own packages. ;)  Seriously, the worst case
> scenario on an automatic upgrade is ENOSPC and the admin has to deal with
> the problem by hand:  which is what he has to do anyway without an automa=
tic
> upgrade, and slapadd -q is cheap and has a high rate of success.  I can't
> imagine a sane server config where there's not enough local storage for an
> LDIF copy, anyway.

I know some people though who will kill me if I create a backup of their
LDAP DB without asking ;)

> > The question was not about keeping redundant binary copies. It's just to
> > have the state of the old directory available in LDIF format before the
> > server was upgraded. Just in case the new version breaks the database
> > miserably.
>=20
> Right, the fact that it was trying to create redundant binary copies was
> just a bug :)

:) Yep.=20

> > In fact the idea is to even move the databases away when there is no
> > ldif and the format has changed (which it will do now) as the old
> > database will probably get severly broken (tried that... :() with the
> > new slapd. I still wonder if the postinst should complete successfully
> > in that case.
>=20
> I personally don't think it's worth trying to have the postinst complete
> successfully in this case; which is another reason why allowing the admin=
 to
> say "never dump" doesn't seem useful to me.

But we don't currently have a route for the admin to fix it manually. If
he slapadds his data again, how does he get the slapd package to
installed state again? Currently there is no such way short of hacking
the dpkg infrastructure. We need to implement a fallback path of some
sort - like

	- Automatic upgrading has failed. Abort upgrade/fix it manually

or something. Another thing: What is the postinst supposed to do in case
the LDIF file is not there? I'd say it should expect that the data was
already added. Other ideas?

> Hmm.  In that case, perhaps something like this in the postinst:
>=20
>   if database_format_changed; then
>   	move_incompatible_databases_away
>   	db_get slapd/dump_database || true
>   	if [ "$RET" !=3D "never" ]; then
>   		load_databases
>   	fi
>   fi

Looks good.

> ?  But, the postinst will *still* fail, because slapd will not start
> correctly without a database, and slapadd && dpkg --configure --pending w=
ill
> fail because it will again try to move the database aside...  Again, I do=
n't
> think it's worthwhile to try to solve this.

Do you have another solution to the problem mentioned above?

> A Pre-Depend is the only way to ensure that debconf is in an *installed*
> state at the time the preinst is called; without making this requirement
> explicit, the package manager is free to leave debconf in a broken state
> while calling the preinst for slapd, which has a decent chance of happeni=
ng
> on a major upgrade.

Making the Pre-Dependency now. No gain in spending time on this. If
people don't like that I think we can classify it as wish list for the
time being ;)

> > The other debconf data that is queried is the location of the LDIFs
> > which is not fixed that easily. I really wonder why we can't make
> > debconf required anyway.
>=20
> Yes, the easiest (and IMHO best) way to fix that if not Pre-Depending on
> debconf would be to hard-code a default location into the scripts.

I was asked for override for debconf answers from /etc/default/slapd. Do
you think we should implement something like that?

> > The DB_CONFIG contains only comment lines currently. So it's not such a
> > big deal currently anyway.
>=20
> Well, 303057 seems like a good reason to ship it with more than just comm=
ent
> lines.  Do you agree with the submitter on that point?  It's unfortunate
> that BDB tuning can't be done more automatically, but if the defaults are
> not sensible I think it's worth making an effort to providing defaults th=
at
> are *more* sensible even if they aren't perfect.

Yes, I agree that we should install a reasonable DB_CONFIG. What do you
think would be good default values given the range of machines Debian
may be running on?

> > Erm, I was thinking about the debconf not installed possibility at that
> > point - this /was/ called from preinst. I am not sure if it still is,
> > the only point would be the slapcat of the old directories.
>=20
> It seems that currently, it's not used from anywhere...

Removed that function.

> > more information can be bad. And I yet have to see an admin watching the
> > dpkg --configure -a output - that's what screen with logging is for. If
> > something goes wrong I have the last few lines and go hunting for the
> > cause from there.
>=20
> Ok.  I admit, it does look rather elegant when upgrading slapd; not nearly
> as bad as I thought it would based on the number of echo's present.

:) Thanks. After all the visual appearance of software plays a great
role in user perception. And, libc is just as verbose in generating
locales etc. My choice would be to keep it as it is until somebody has a
problem with it.

> > The point is that in case anything goes wrong during the upgrade, I'd
> > like to be able to just reinstall the old package and have everything
> > still available. The new slapd.conf will not work with old slapd so I
> > think it should be backed up. And, truth to be told, I guess without the
> > message nobody will ever seek in /var/backups for that.
>=20
> Yes, things can go wrong in the upgrade, but my point was that there's no
> reason to back up the config unless we know we'll be changing it.  Since
> every single function that will edit slapd.conf also calls
> backup_config_once, there's no need to call it here as well, is there?  F=
or
> that matter, the "echo" command could be moved into the
> if [ -z "$FLAG_CONFIG_BACKED_UP" ] part of backup_config_once.

There normally something like

	doing foo... _  <<-- cursor

is on the screen. OTOH I agree that the situation is not perfect - just
installed 2.2.23-3 and it looks weird that it is backing up the config
without changing anything ;)

Greetings

	Torsten

--a8Wt8u1KmwUX3Y2C
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCZuyodQgHtVUb5EcRAo0nAJ9HacNMorCgrivjg01SACSFmLRhswCeOCsO
TJeqwUdwJf5aP6Unq6lU+c8=
=00UJ
-----END PGP SIGNATURE-----

--a8Wt8u1KmwUX3Y2C--