hey, On Tue, Mar 15, 2005 at 10:02:23PM +0100, Torsten Landschoff wrote: > 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... this is true, though more precisely it's packages needing to manage databases, which i think applies to this case. > 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. that sucks. > > 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 > > No way. double sucks. > > 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... yeah, i'm wondering whether or not that actually makes sense to do, now that i'm thinking about it. you make a valid point though... i would hope there aren't any directory services running on 386's, heh. > > > 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. i think i misread your statement that "if postinst finds a dump file to act on it", as opposed to "if the version changes suggest it should check for a dump file". > > 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. if you warn them and give the ability to opt-out in the config, you'll get all the folks who use apt (which preconfigures the packages before unpacking them). if your maintscripts automatically stop slapd during the upgrade, even failing based on their response after unpacking would be okay, as they could back up to an old version before slapd started and mangled their data. > > 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. okay, just a thought. > > - 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. d'oh. > > > 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. that's definitely reassuring. > > 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: i think /var/cache is the a sensible default location. the only other location that fits within the fhs is /var/tmp or /tmp, which has even more liberal (the admin should be able to delete anything) requirements. plus, the data can arguably be reconstituted by dumping the ldap database again, assuming nothing goes wrong :) > > 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 :(( you could do something like - use low priority to prompt for the location (so most folks won't see it) - dump the database - if failure dumping, display a debconf note saying why the dump failed (full disk), and that setting debconf priority to low and reinstalling the package will give the option of where to dump. sean --
Attachment:
signature.asc
Description: Digital signature