Bug#302629: slapd: Unstable upgrade (2.1 -> 2.2) failures
On Mon, Apr 18, 2005 at 11:41:48AM +0200, Torsten Landschoff wrote: > > this particular LDIF incompatibility be dealt with in fix_ldif? > In theory fix_ldif could be improved to handle all incompatibilities. If > we know them... > > > > The issue seems to be that slapcat created the root entry like > > > > this: > > > > uidNumber: > > > > gidNumber: > > > > but slapadd barfs on that, saying it is an invalid number! > > > > Changing > > > > the to 0 for the user and group settings worked fine > > > ... and another incompatibility. > > It would be better if fix_ldif knew about schemas and could therefore know > > which entries to automatically change; but even without that, we could > > safely edit the LDIF for this when it's a known attrib like uidNumber or > > gidNumber, couldn't we? > I think we could. OTOH I'd rather find out where those "" values are > coming from. Or wtf "" is an invalid number. Crazy stuff! Well, I understood that they were coming from his existing directory because that's how they had been input? > > A naive patch for this might look like the one attached. > Yep, naive but might work. Not to mention that there might be other > integer fields which will go mad like this. I wonder if there is a perl > module with full schema parsing support which would make writing > something like this much easier. Would be nice, but I don't think there is such a thing in Debian yet. In the meantime, here are the attributeTypes in the Debian-provided schemas that use syntax 1.3.6.1.4.1.1466.115.121.1.27: mailPreferenceOption uidNumber gidNumber shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag ipServicePort ipServiceProtocol ipProtocolNumber oncRpcNumber There are of course plenty of other schemas that will use this common syntax; it's used by both krb5-kdc and samba schemas that I have on hand. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Bug#302629: slapd: Unstable upgrade (2.1 -> 2.2) failures
Hi Steve, On Mon, Apr 18, 2005 at 01:56:17AM -0700, Steve Langasek wrote: > I think it's worth a lot to provide as smooth of an upgrade path as > possible, and leave the README for cases we can't reasonably handle. Can Yeah. > this particular LDIF incompatibility be dealt with in fix_ldif? In theory fix_ldif could be improved to handle all incompatibilities. If we know them... > > > The issue seems to be that slapcat created the root entry like this: > > > uidNumber: > > > gidNumber: > > > > but slapadd barfs on that, saying it is an invalid number! Changing > > > the to 0 for the user and group settings worked fine > > > ... and another incompatibility. > > It would be better if fix_ldif knew about schemas and could therefore know > which entries to automatically change; but even without that, we could > safely edit the LDIF for this when it's a known attrib like uidNumber or > gidNumber, couldn't we? I think we could. OTOH I'd rather find out where those "" values are coming from. Or wtf "" is an invalid number. Crazy stuff! > A naive patch for this might look like the one attached. Yep, naive but might work. Not to mention that there might be other integer fields which will go mad like this. I wonder if there is a perl module with full schema parsing support which would make writing something like this much easier. Greetings Torsten signature.asc Description: Digital signature
Bug#302629: slapd: Unstable upgrade (2.1 -> 2.2) failures
On Sat, Apr 02, 2005 at 04:36:49AM +0200, Torsten Landschoff wrote:
> > 2) error in parsing the saved ldif file:
> > Setting up slapd (2.2.23-1) ...
> > Enabling LDAPv2 support... already enabled.
> > Updating config access directives... done.
> > Moving old database directories to /var/backups:
> > Loading from /var/backups/slapd-2.1.30-3:
> > - directory dc=cavein,dc=org... slapadd: could not parse entry
> > (line=316) failed.
> That's quite known an issue. If you consider this grave, we can't put
> slapd 2.2 in Debian as 2.2 fails on a lot of 2.1 and even more of 2.0
> directories. I am working on a README type upgrade document which tells
> the user.
I think it's worth a lot to provide as smooth of an upgrade path as
possible, and leave the README for cases we can't reasonably handle. Can
this particular LDIF incompatibility be dealt with in fix_ldif?
> > Well, that was a helpful message (I know, not your fault) :)
> I think it is - at least you got the line number...
> > The issue seems to be that slapcat created the root entry like this:
> > uidNumber:
> > gidNumber:
> > but slapadd barfs on that, saying it is an invalid number! Changing
> > the to 0 for the user and group settings worked fine
> ... and another incompatibility.
It would be better if fix_ldif knew about schemas and could therefore know
which entries to automatically change; but even without that, we could
safely edit the LDIF for this when it's a known attrib like uidNumber or
gidNumber, couldn't we?
A naive patch for this might look like the one attached.
Cheers,
--
Steve Langasek
postmodern programmer
Index: debian/fix_ldif
===
--- debian/fix_ldif (revision 516)
+++ debian/fix_ldif (working copy)
@@ -361,7 +361,13 @@
}
#
-# Check required attributes.
+# Check required attributes, and fix up known attributes for which the
+# syntax has changed
+# Bad hack: the "fix up" should be replaced by something which knows
+# about schemas and can fix all instances for all attributes of the
+# relevant attribute syntax (1.3.6.1.4.1.1466.115.121.1.27). For now,
+# we only check the most commonly affected attributes, which we also
+# happen to know are SINGLE-VALUE.
#
sub checkattrs
{
@@ -386,6 +392,10 @@
print STDERR "\n\n";
}
}
+${$entries{$dn}{'uidnumber'}}[0] = 0)
+ if (${$entries{$dn}{'uidnumber'}}[0] eq '');
+${$entries{$dn}{'gidnumber'}}[0] = 0)
+ if (${$entries{$dn}{'gidnumber'}}[0] eq '');
}
#
signature.asc
Description: Digital signature
Bug#302629: slapd: Unstable upgrade (2.1 -> 2.2) failures
On Sat, 2 Apr 2005, Torsten Landschoff wrote: > > Justification: renders package unusable > > Come on... well, since I did manage to get it going, I'll grant that the package isn't unusable... but it was upon 1st install ! > > 1) use of ldapi:/// fails: > > ldap_url_parse_ext(ldapi:///x-mod=0777) > > daemon: bind(10) failed errno=2 (No such file or directory) > > slap_open_listener: failed on ldapi:///x-mod=0777 > > > > The cause seems to be that the ./configure script had bad settings - > > the binary expects /var/run/run/ldapi instead of the proper > > /var/run/ldapi > > Very interesting. I got reports by a tester that this is the case and > some workaround but forgot about it. I've not heard of many people using ldapi: - always wondered why... seems like a much lower overhead (if your server happens to be on the same box) > > 2) error in parsing the saved ldif file: > > Setting up slapd (2.2.23-1) ... > > Enabling LDAPv2 support... already enabled. > > Updating config access directives... done. > > Moving old database directories to /var/backups: > > Loading from /var/backups/slapd-2.1.30-3: > > - directory dc=cavein,dc=org... slapadd: could not parse entry > > (line=316) failed. > > That's quite known an issue. If you consider this grave, we can't put > slapd 2.2 in Debian as 2.2 fails on a lot of 2.1 and even more of 2.0 > directories. I am working on a README type upgrade document which tells > the user. Ah... 'twasn't known by me - and took a bit of digging to find it, but as long as it is documented, I'm fine with setting this to whatever priority you are happy with. > > Well, that was a helpful message (I know, not your fault) :) > > I think it is - at least you got the line number... ah, but the line number is the last line of the stanza... it gave me relatively little clue upon what the real issue was (some several lines above the reported line) > > uidNumber: > > gidNumber: > > > > but slapadd barfs on that, saying it is an invalid number! Changing > > the to 0 for the user and group settings worked fine > > ... and another incompatibility. Cool - I'm not trying to be a prick about this - I just wanted to make sure that we wind up with something that wont break people out of the box. If we can tell people they might have to edit the ldif file and rerun the install, then I'm happy... Oh, and by the way - editing the ldif file and re-running the install did work just fine... thanks :) -- Rick Nelson direct brain implants :) xtifr - yah, then using computers would actually require some of these idiots to think! ;> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#302629: slapd: Unstable upgrade (2.1 -> 2.2) failures
On Fri, Apr 01, 2005 at 04:24:53PM -0800, Richard A Nelson wrote: > 1) use of ldapi:/// fails: > ldap_url_parse_ext(ldapi:///x-mod=0777) > daemon: bind(10) failed errno=2 (No such file or directory) > slap_open_listener: failed on ldapi:///x-mod=0777 Should be fixed in subversion. Greetings Torsten signature.asc Description: Digital signature
Bug#302629: slapd: Unstable upgrade (2.1 -> 2.2) failures
Hi Richard, On Fri, Apr 01, 2005 at 04:24:53PM -0800, Richard A Nelson wrote: > Package: slapd > Version: 2.2.23-1 > Severity: grave > Justification: renders package unusable Come on... > 1) use of ldapi:/// fails: > ldap_url_parse_ext(ldapi:///x-mod=0777) > daemon: bind(10) failed errno=2 (No such file or directory) > slap_open_listener: failed on ldapi:///x-mod=0777 > > The cause seems to be that the ./configure script had bad settings - > the binary expects /var/run/run/ldapi instead of the proper > /var/run/ldapi Very interesting. I got reports by a tester that this is the case and some workaround but forgot about it. > 2) error in parsing the saved ldif file: > Setting up slapd (2.2.23-1) ... > Enabling LDAPv2 support... already enabled. > Updating config access directives... done. > Moving old database directories to /var/backups: > Loading from /var/backups/slapd-2.1.30-3: > - directory dc=cavein,dc=org... slapadd: could not parse entry > (line=316) failed. That's quite known an issue. If you consider this grave, we can't put slapd 2.2 in Debian as 2.2 fails on a lot of 2.1 and even more of 2.0 directories. I am working on a README type upgrade document which tells the user. > Well, that was a helpful message (I know, not your fault) :) I think it is - at least you got the line number... > The issue seems to be that slapcat created the root entry like this: > uidNumber: > gidNumber: > > but slapadd barfs on that, saying it is an invalid number! Changing > the to 0 for the user and group settings worked fine ... and another incompatibility. Greetings Torsten signature.asc Description: Digital signature
Bug#302629: slapd: Unstable upgrade (2.1 -> 2.2) failures
Package: slapd Version: 2.2.23-1 Severity: grave Justification: renders package unusable 1) use of ldapi:/// fails: ldap_url_parse_ext(ldapi:///x-mod=0777) daemon: bind(10) failed errno=2 (No such file or directory) slap_open_listener: failed on ldapi:///x-mod=0777 The cause seems to be that the ./configure script had bad settings - the binary expects /var/run/run/ldapi instead of the proper /var/run/ldapi 2) error in parsing the saved ldif file: Setting up slapd (2.2.23-1) ... Enabling LDAPv2 support... already enabled. Updating config access directives... done. Moving old database directories to /var/backups: Loading from /var/backups/slapd-2.1.30-3: - directory dc=cavein,dc=org... slapadd: could not parse entry (line=316) failed. Well, that was a helpful message (I know, not your fault) :) The issue seems to be that slapcat created the root entry like this: uidNumber: gidNumber: but slapadd barfs on that, saying it is an invalid number! Changing the to 0 for the user and group settings worked fine -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.11 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages slapd depends on: ii coreutils [fileutils] 5.2.1-2 The GNU core utilities ii debconf 1.4.47 Debian configuration management sy ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libdb4.24.2.52-18Berkeley v4.2 Database Libraries [ ii libiodbc2 3.52.2-3 iODBC Driver Manager ii libldap-2.2-7 2.2.23-1 OpenLDAP libraries ii libltdl31.5.6-6 A system independent dlopen wrappe ii libperl5.8 5.8.4-8 Shared Perl library ii libsasl22.1.19-1.5 Authentication abstraction library ii libslp1 1.0.11a-2OpenSLP libraries ii libssl0.9.7 0.9.7e-3 SSL shared libraries ii libwrap07.6.dbs-8Wietse Venema's TCP wrappers libra ii perl [libmime-base64-perl] 5.8.4-8 Larry Wall's Practical Extraction ii psmisc 21.6-1 Utilities that use the proc filesy -- debconf information: slapd/fix_directory: true * shared/organization: dc=cavein, dc=org slapd/upgrade_slapcat_failure: slapd/backend: BDB * slapd/allow_ldap_v2: true slapd/no_configuration: false slapd/move_old_database: true slapd/suffix_change: false slapd/slave_databases_require_updateref: * slapd/dump_database_destdir: /var/backups/slapd-VERSION slapd/autoconf_modules: true * slapd/domain: cavein.org slapd/password_mismatch: * slapd/invalid_config: true slapd/upgrade_slapadd_failure: * slapd/dump_database: when needed slapd/purge_database: false slapd/admin: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
