hi torsten, much of what you're trying to do touches a similar vein to a project i'm currently working on[1]. while unfortunately i haven't built in any support for ldap (only mysql/pgsql), the topics, concepts, and practices are directly relevant to your situation and i'd recommend reading through it. i'd also welcome any comments you have.
On Tue, Mar 15, 2005 at 01:36:17AM +0100, Torsten Landschoff wrote:
> a) the preinst checks if the database format has changed between the old
> version and the version that we are upgrading to
is this an underlying database format change, or simply stricter schema checks?
if it is a change to the db format, will the new server work with the
old format (even if less optimally)? if so it might make a better
quality package to leave the data in the old format and provide
instructions to the admin (who will know more than you about the
directory server) for how to get the new optimised format.
> b) if it has each LDAP directory is dumped to <suffix>.ldif using slapcat
might want pipe that through gzip/bzip2 :)
> c) the postinst checks if an ldif file is available from the old version
if this is an upgrade that will always need to happen in between 2.0/2.1
and 2.2, you should rely on the version numbers provided by dpkg instead.
set the preinst to fail if it can't successfully dump the file, which
will keep the admin in as sane of a state as possible (with a working
old install)
> 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
does this mean you will have to drop the contents of the ldap server
before re-adding them with the correct format/syntax?
> e) next old data in the directory of the database is moved away so the
> new DB can be created
that's really scary sounding. remember that some people have some
Important Data in these servers. at the *very* least you'll want to
give them a big scary debconf warning and the ability to quit the install.
> f) the corrected ldif file is piped into the new directory using slapadd
instead of dumping to an ldif, moving the database out of the way, and
reading back in from a corrected ldif, could you do the following?
- dump the data in ldif format through a pipe
- pipe it through your syntax/schema checker, outputting all the
violations, perhaps even as ldap modify commands
- if there are no violations, continue with the upgrade
- otherwise leave this in a file somewhere, and try to perform the
commands
- if this fails, tell the admin where the file is and let them perform
the modifications before they upgrade (assuming this will not break
a 2.0 server), and fail the install gracefully.
> This sounds simple. There are a lot of problems so:
no it doesn't :)
> 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.
somewhere under /var/cache would be appropriate, though you might want
to give the admin the option via debconf to put it somewhere else.
> 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?
like i said earlier, you'll want the upgrade to fail as early as possible,
ideally in the preinst before you've unpacked the latest version.
this way every call to dpkg --configure will provide the same values
for the current and old version, and failure won't leave the admin with
a totally b0rken system.
> ad e) where to move the directory? Should be on the same disk so that
> the mv command is most effective.
if you really have to move the databases, i'd recommend against hard
coding where you put it. give the admin the option of where to put it.
he/she will know much more about where there's free space to put it.
hth,
sean
[1] http://people.debian.org/~seanius/policy/dbapp-policy.html
--
signature.asc
Description: Digital signature
