Re: [RFC] OpenLDAP automatic upgrade
Hello Torsten
although I have just a small LDAP directory running for authentication
purposes, and am a comparatively new Debian user on top, I'd still like
to make some comments ...
> a) the preinst checks if the database format has changed between the old
> version and the version that we are upgrading to
OK.
> b) if it has each LDAP directory is dumped to <suffix>.ldif using slapcat
> ad b) where is that .ldif file to be saved? For small directories not an
> issue (take /var/backups or something). For big directories it should be
> on a different disk than /var/lib/ldap with enough space to get sensible
> performance.
Several of your trouble spots are concerned with how to best support large
directories. This is one.
> c) the postinst checks if an ldif file is available from the old version
> ad c) what happens if the upgrade fails for incompatibilities in
> slapadd? will the next dpkg --configure slapd give the right value for
> previous version to the postinst?
Don't know, but shouldn't this be a common upgrade issue all packages
resp. packagers who run upgrade scripts have to deal with? I'm under
the impression that this is an expert deb maintainer question, and
either it can or cannot be solved with what the package managment has
to offer.
> d) if it is, the fix_ldif script is run to adapt the contents of the
> directory to the more strict checking of the new OpenLDAP server
> ad d) fix_ldif is a script that tries to fix some errors in the LDAP
> data that are not noticed by OpenLDAP 2.0 but get detected by newer
> OpenLDAP breaking the slapadd. Problem is: It reads the LDIF into
> memory. Try that with 1GB of data...
Large directory issue.
> e) next old data in the directory of the database is moved away so the
> new DB can be created
> ad e) where to move the directory? Should be on the same disk so that
> the mv command is most effective.
Sure. Basically a large directory issue too, isn't it?
> f) the corrected ldif file is piped into the new directory using slapadd
Altogether, with the exception of c), you seem to be mainly concerned
with how to deal with big directories. Of these points, two are
concerned with paths where to copy stuff, and where you can let the user
make a choice during setup, and only one is a real technical obstacle,
i.e. d). Regarding that one, what does upstream say? I mean, the
OpenLDAP guys should offer a migration path for all their users,
included those with large directories, and the question is wether it
can be automated.
So as I see it, only c) and d) are real trouble spots, and only for
large directories. Regarding b) and e), you could just choose sensible
defaults for the paths and give users the possibility to enter own ones
during setup. For example I myself don't really care because of the size
of my directory.
So c) I guess should be discussed with veteran maintainers. And d) I
guess is a problem e.g. database projects might face resp. have faced
as well. I think upstream should have a word on this. And maybe the
mysql, postgre and whatever maintainers could give a hint too. If all
fails, you might have to consider dropping large directory support
because of d) and warn the user about that.
Just my thoughts. Hopefully, more comments come in especially regarding
d)
Regards, Bruno.
Reply to: