Hi Sean, On Mon, Mar 14, 2005 at 08:14:39PM -0500, sean finney wrote: > 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
As far as I can see your are mostly targetting packages /using/ a
database? Good work so far looking at your text. The few database using
packages I tried to install did not work as good as I'd have expected...
> 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.
I'll try to find some time.
> 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?
The first. Basically upstream changes the database format quite often.
I am even not entirely sure if the database format stays compatible in
the 2.1 or 2.2 line but I'd expect it to. The 2.2.23 Debian packages
uses libdb4.3 instead of libdb4.2 as used in 2.1.x so the reload has to
be done in any case.
> 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.
No way.
> > b) if it has each LDAP directory is dumped to <suffix>.ldif using slapcat
>
> might want pipe that through gzip/bzip2 :)
Hmm, good question. On a slow system this will hit really hard for big
databases. On the other hand who will run a big LDAP server on a slow
machine...
> > 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.
Instead of what? I am using the version numbers from dpkg currently.
> 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)
That's what I am doing in any case.
> > 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?
Installing a new version will automatically drop the old contents.
Either by the script moving it away or by the server messing with the
database.
> > 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.
That kind of contradicts seamless upgrades. And at install time (in
postinst) it is already too late in the game. They'd need to reinstall
the old package anyway.
> > 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
Way to complicated. In fact I don't even know the exact list of
incompatibilities.
> - if there are no violations, continue with the upgrade
The old Debian configuration created a directory that does not pass the
schemacheck of the new packages so it is almost guaranteed there are
violations.
> > This sounds simple. There are a lot of problems so:
>
> no it doesn't :)
It is mostly working already at least for simple setups. And I did not
get that many reports about upgrade problems.
> > 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.
/var/cache? I'd rather not put it there. Quoting the FHS:
Files located under /var/cache may be expired in an application
specific manner, by the system administrator, or both. The
application should always be able to recover from manual deletion of
these files (generally because of a disk space shortage). No other
requirements are made on the data format of the cache directories.
> > 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.
That's what I wanted to know. I'll check it anyway just in case.
> > 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.
Yes, another debconf question :((
Greetings
Torsten
signature.asc
Description: Digital signature
