Fails parsing LDIF during upgrade
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
openldap2.2 (Debian) |
Fix Released
|
Unknown
|
|||
openldap2.2 (Ubuntu) |
Fix Released
|
Medium
|
Adam Conrad |
Bug Description
Automatically imported from Debian bug report #302629 http://
In Debian Bug tracker #302629, Torsten Landschoff (torsten) wrote : Re: Bug#302629: slapd: Unstable upgrade (2.1 -> 2.2) failures | #1 |
In Debian Bug tracker #302629, Torsten Landschoff (t-landschoff) wrote : severity of 302629 is serious | #2 |
severity 302629 serious
In Debian Bug tracker #302629, Torsten Landschoff (t-landschoff) wrote : tagging 302629 | #3 |
tags 302629 confirmed
In Debian Bug tracker #302629, Torsten Landschoff (t-landschoff) wrote : retitle 302629 to Fails parsing LDIF during upgrade | #4 |
retitle 302629 Fails parsing LDIF during upgrade
In Debian Bug tracker #302629, Torsten Landschoff (torsten) wrote : Re: Bug#302629: slapd: Unstable upgrade (2.1 -> 2.2) failures | #5 |
On Fri, Apr 01, 2005 at 04:24:53PM -0800, Richard A Nelson wrote:
> 1) use of ldapi:/// fails:
> ldap_url_
> daemon: bind(10) failed errno=2 (No such file or directory)
> slap_open_listener: failed on ldapi:/
Should be fixed in subversion.
Greetings
Torsten
In Debian Bug tracker #302629, Cowboy (cowboy-debian) wrote : | #6 |
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_
> > daemon: bind(10) failed errno=2 (No such file or directory)
> > slap_open_listener: failed on ldapi:/
> >
> > 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/
> > - 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: 0000
> > gidNumber: 0000
> >
> > but slapadd barfs on that, saying it is an invalid number! Changing
> > the 0000 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
<xtifr> direct brain implants :)
<knghtbrd> xtifr - yah, then using computers would actually require some
of these idiots to think!
<knghtbrd> ;>
Debian Bug Importer (debzilla) wrote : | #7 |
Automatically imported from Debian bug report #302629 http://
Debian Bug Importer (debzilla) wrote : | #8 |
Message-Id: <email address hidden>
Date: Fri, 01 Apr 2005 16:24:53 -0800
From: Richard A Nelson <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: 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_
daemon: bind(10) failed errno=2 (No such file or directory)
slap_open_
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/
- 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: 0000
gidNumber: 0000
but slapadd barfs on that, saying it is an invalid number! Changing
the 0000 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=
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.2 4.2.52-18 Berkeley 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 libltdl3 1.5.6-6 A system independent dlopen wrappe
ii libperl5.8 5.8.4-8 Shared Perl library
ii libsasl2 2.1.19-1.5 Authentication abstraction library
ii libslp1 1.0.11a-2 OpenSLP libraries
ii libssl0.9.7 0.9.7e-3 SSL shared libraries
ii libwrap0 7.6.dbs-8 Wietse Venema's TCP wrappers libra
ii perl [libmime-
ii psmisc 21.6-1 Utilities that use the proc filesy
-- debconf information:
slapd/
* shared/
slapd/
slapd/backend: BDB
* slapd/allow_
slapd/
slapd/
slapd/
slapd/
* slapd/dump_
slapd/
* slapd/domain: cavein.org
slapd/
* slapd/invalid_
slapd/
* slapd/dump_
slapd/
...
Debian Bug Importer (debzilla) wrote : | #9 |
Message-ID: <email address hidden>
Date: Sat, 2 Apr 2005 05:04:01 +0200
From: Torsten Landschoff <email address hidden>
To: Richard A Nelson <email address hidden>, <email address hidden>
Subject: Re: Bug#302629: slapd: Unstable upgrade (2.1 -> 2.2) failures
--jI8keyz6grp/JLjh
Content-Type: text/plain; charset=us-ascii
Content-
On Fri, Apr 01, 2005 at 04:24:53PM -0800, Richard A Nelson wrote:
> 1) use of ldapi:/// fails:
> ldap_url_
> daemon: bind(10) failed errno=2 (No such file or directory)
> slap_open_listener: failed on ldapi:/
Should be fixed in subversion.
Greetings
Torsten
--jI8keyz6grp/JLjh
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFCTgugdQg
+YcaVocYmda+
=x28C
-----END PGP SIGNATURE-----
--jI8keyz6grp/
Debian Bug Importer (debzilla) wrote : | #10 |
Message-ID: <email address hidden>
Date: Sat, 2 Apr 2005 04:36:49 +0200
From: Torsten Landschoff <email address hidden>
To: Richard A Nelson <email address hidden>, <email address hidden>
Subject: Re: Bug#302629: slapd: Unstable upgrade (2.1 -> 2.2) failures
--AhhlLboLdkugWU4S
Content-Type: text/plain; charset=us-ascii
Content-
Content-
Hi Richard,=20
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_
> daemon: bind(10) failed errno=3D2 (No such file or directory)
> slap_open_listener: failed on ldapi:/
>=20
> 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/
> - directory dc=3Dcavein,
> (line=3D316) 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: 0000
> gidNumber: 0000
>=20
> but slapadd barfs on that, saying it is an invalid number! Changing
> the 0000 to 0 for the user and group settings worked fine
=2E.. and another incompatibility.
Greetings
Torsten
--AhhlLboLdkugWU4S
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFCTgVAdQg
cZouGxaWnl7BNtj
=D1WE
-----END PGP SIGNATURE-----
--AhhlLboLdkugW
Debian Bug Importer (debzilla) wrote : | #11 |
Message-Id: <email address hidden>
Date: Sat, 2 Apr 2005 05:02:27 +0200 (CEST)
From: <email address hidden> (Torsten Landschoff)
To: <email address hidden>
Subject: tagging 302629
tags 302629 confirmed
Debian Bug Importer (debzilla) wrote : | #12 |
Message-Id: <email address hidden>
Date: Sat, 2 Apr 2005 05:03:30 +0200 (CEST)
From: <email address hidden> (Torsten Landschoff)
To: <email address hidden>
Subject: retitle 302629 to Fails parsing LDIF during upgrade
retitle 302629 Fails parsing LDIF during upgrade
Debian Bug Importer (debzilla) wrote : | #13 |
Message-Id: <email address hidden>
Date: Sat, 2 Apr 2005 04:37:14 +0200 (CEST)
From: <email address hidden> (Torsten Landschoff)
To: <email address hidden>
Subject: severity of 302629 is serious
severity 302629 serious
Debian Bug Importer (debzilla) wrote : | #14 |
Message-ID: <email address hidden>
Date: Fri, 1 Apr 2005 21:35:13 -0800 (PST)
From: Richard A Nelson <email address hidden>
To: Torsten Landschoff <email address hidden>
cc: <email address hidden>
Subject: Re: 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_
> > daemon: bind(10) failed errno=2 (No such file or directory)
> > slap_open_listener: failed on ldapi:/
> >
> > 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/
> > - 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: 0000
> > gidNumber: 0000
> >
> > but slapadd barfs on that, saying it is an invalid number! Changing
> > the 0000 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
<xtifr> direct brain implants :)
<knghtbrd> xtifr - yah, then using computers would actually require some
of these idiots to think!
<knghtbrd> ;>
Matt Zimmerman (mdz) wrote : | #15 |
I think this may be specific to 2.2.x, but please investigate and confirm
Adam Conrad (adconrad) wrote : | #16 |
This is definitely a 2.1->2.2 upgrade issue. I'm going to tag it for 5.10,
since I assume we'll sync 2.2 packages sometime before then, and watch to
see how it's resolved in Debian, perhaps helping with some simple slapcat
output mungers to fix easily-solved issues (like the root uid one), rather
than just rely entirely on a README file.
Also, dropping severity to normal, as it will at least be an issue with a
documented workaround by the time we get to caring about it.
In Debian Bug tracker #302629, Andreas Tscharner (andy-blackmoon) wrote : slapd: Similar problem with update from 2.2.23-1 to 2.2.23-2 | #17 |
Package: slapd
Version: 2.2.23-2
Followup-For: Bug #302629
I have a similar problem when updaeting from 2.2.23-1 to 2.2.23-2. The
output
Setting up slapd (2.2.23-2) ...
Backing up /etc/ldap/
Moving old database directories to /var/backups:
Loading from /var/backups/
-directory dc=tasha,
/var/lib/
failed.
Loading the dazabase from the LDIF dump failed with the following
error while running slapadd:
/var/
dpkg: error processing slapd (--configure):
dubprocess post-installation script returned error exist status 1
Errors were encountered while processing
slapd
(Hand typed from screen)
Best regards
Andreas
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i586)
Kernel: Linux 2.4.27
Locale: LANG=C, LC_CTYPE=C (charmap=
Versions of packages slapd depends on:
ii coreutils [fileutils] 5.2.1-2 The GNU core utilities
ii debconf 1.4.48 Debian configuration management sy
ii fileutils 5.2.1-2 The GNU file management utilities
ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an
ii libdb4.2 4.2.52-18 Berkeley v4.2 Database Libraries [
ii libiodbc2 3.52.2-3 iODBC Driver Manager
ii libldap-2.2-7 2.2.23-2 OpenLDAP libraries
ii libltdl3 1.5.6-6 A system independent dlopen wrappe
ii libperl5.8 5.8.4-8 Shared Perl library
ii libsasl2 2.1.19-1.5 Authentication abstraction library
ii libslp1 1.0.11a-2 OpenSLP libraries
ii libssl0.9.7 0.9.7e-3 SSL shared libraries
ii libwrap0 7.6.dbs-8 Wietse Venema's TCP wrappers libra
ii perl [libmime-
ii psmisc 21.6-1 Utilities that use the proc filesy
-- debconf information excluded
In Debian Bug tracker #302629, Torsten Landschoff (torsten) wrote : Re: Bug#302629: slapd: Similar problem with update from 2.2.23-1 to 2.2.23-2 | #18 |
Hi Andreas,
On Fri, Apr 15, 2005 at 11:04:24AM +0200, Andreas Tscharner wrote:
> (Hand typed from screen)
Uargh, that's a lot of work for this. Thanks! Bug is known, please move
the ldabdb directory from /var/backups back to /var/lib/ldap:
# /etc/init.d/slapd stop
# rm /var/lib/ldap/*
# cp -a /var/backups/
# /etc/init.d/slapd start
and you should be fine.
Greetings
Torsten
In Debian Bug tracker #302629, Steve Langasek (vorlon) wrote : Re: Bug#302629: slapd: Unstable upgrade (2.1 -> 2.2) failures | #19 |
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/
> > - 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: 0000
> > gidNumber: 0000
> > but slapadd barfs on that, saying it is an invalid number! Changing
> > the 0000 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
In Debian Bug tracker #302629, Torsten Landschoff (torsten) wrote : | #20 |
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: 0000
> > > gidNumber: 0000
>
> > > but slapadd barfs on that, saying it is an invalid number! Changing
> > > the 0000 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 "0000" values are
coming from. Or wtf "0000" 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
In Debian Bug tracker #302629, Greg Matthews (gmatt) wrote : | #21 |
This appears to be an LDIF parsing problem (which is why I have
submitted it to this bug number). In fact it is more subtle than that.
Feel free to move this to a different bug number if necessary.
The error during a dist-upgrade was:
Installing new version of config file /etc/init.d/slapd ...
Updating config access directives... done.
Moving old database directories to /var/backups:
- directory dc=lea,
Loading from /var/backups/
- directory dc=lea,
dn="dc=my,dc=base" (line=14): txn_aborted! DB_KEYEXIST: Key/data pair
already exists (-30996)
failed.
dpkg: error processing slapd (--configure):
subprocess post-installation script returned error exit status 1
attempting to manually slapadd the LDIF file produced:
/usr/sbin/slapadd -f /etc/ldap/
slapadd: could not parse entry (line=14)
turning on debug info produced:
/usr/sbin/slapadd -d1 -f /etc/ldap/
<snip>
backend_startup: starting "dc=lea,
bdb_db_open: dbenv_open(
=> str2entry: "dn: dc=my,dc=base
dc: my
objectClass: top
objectClass: domain
objectClass: nisDomainObject
structuralObjec
entryUUID: 142d2f8e-
creatorsName: cn=manager,
createTimestamp: 20030725140732Z
nisDomain: foobar
entryCSN: 2003092908:
modifiersName: cn=manager,
modifyTimestamp: 20030929085714Z
"
>>> dnPrettyNormal: <dc=my,dc=base>
<<< dnPrettyNormal: <dc=my,dc=base>, <dc=my,dc=base>
str2entry: invalid value for attributeType objectClass #2 (syntax
1.3.6.1.
slapadd: could not parse entry (line=14)
slapadd shutdown: initiated
====> bdb_cache_
slapadd shutdown: freeing system resources.
openldap is known for obscure error messages but I believe this is
caused by trying to add data that is not within the DIT defined by the
suffix. The reasons for this are outlined below.
path names are not absolute for the binaries slapadd/slapcat nor for the
configuration file /etc/ldap/
loss of data in my directory***
I have another openldap installed in /usr/local and binaries for this
installation appear first in PATH. this meant that slapcat and slapadd
were working on the wrong directory and so the backup kept
in /var/backups/
directory data is LOST!
I suggest that binaries are defined explicitly as well as paths to
config files eg:
/usr/bin/slapcat -f /etc/ldap/
/usr/bin/slapadd -f /etc/ldap/
to prevent this happening in future.
GREG
hardware: Dell optiplex desktop
distro: sarge
kernel: 2.6.8-2-686
slapd: upgrade from 2.1.30-3 to 2.2.23 (dist-upgrade)
--
Greg Matthews
iTSS Wallingford 01491 692445
In Debian Bug tracker #302629, Steve Langasek (vorlon) wrote : | #22 |
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: 0000
> > > > gidNumber: 0000
> > > > but slapadd barfs on that, saying it is an invalid number! Changing
> > > > the 0000 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 "0000" values are
> coming from. Or wtf "0000" 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.
mailPreferenceO
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
Debian Bug Importer (debzilla) wrote : | #23 |
Message-Id: <email address hidden>
Date: Fri, 15 Apr 2005 11:04:24 +0200
From: Andreas Tscharner <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: slapd: Similar problem with update from 2.2.23-1 to 2.2.23-2
Package: slapd
Version: 2.2.23-2
Followup-For: Bug #302629
I have a similar problem when updaeting from 2.2.23-1 to 2.2.23-2. The
output
Setting up slapd (2.2.23-2) ...
Backing up /etc/ldap/
Moving old database directories to /var/backups:
Loading from /var/backups/
-directory dc=tasha,
/var/lib/
failed.
Loading the dazabase from the LDIF dump failed with the following
error while running slapadd:
/var/
dpkg: error processing slapd (--configure):
dubprocess post-installation script returned error exist status 1
Errors were encountered while processing
slapd
(Hand typed from screen)
Best regards
Andreas
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i586)
Kernel: Linux 2.4.27
Locale: LANG=C, LC_CTYPE=C (charmap=
Versions of packages slapd depends on:
ii coreutils [fileutils] 5.2.1-2 The GNU core utilities
ii debconf 1.4.48 Debian configuration management sy
ii fileutils 5.2.1-2 The GNU file management utilities
ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an
ii libdb4.2 4.2.52-18 Berkeley v4.2 Database Libraries [
ii libiodbc2 3.52.2-3 iODBC Driver Manager
ii libldap-2.2-7 2.2.23-2 OpenLDAP libraries
ii libltdl3 1.5.6-6 A system independent dlopen wrappe
ii libperl5.8 5.8.4-8 Shared Perl library
ii libsasl2 2.1.19-1.5 Authentication abstraction library
ii libslp1 1.0.11a-2 OpenSLP libraries
ii libssl0.9.7 0.9.7e-3 SSL shared libraries
ii libwrap0 7.6.dbs-8 Wietse Venema's TCP wrappers libra
ii perl [libmime-
ii psmisc 21.6-1 Utilities that use the proc filesy
-- debconf information excluded
Debian Bug Importer (debzilla) wrote : | #24 |
Message-ID: <email address hidden>
Date: Fri, 15 Apr 2005 23:19:42 +0200
From: Torsten Landschoff <email address hidden>
To: Andreas Tscharner <email address hidden>, <email address hidden>
Subject: Re: Bug#302629: slapd: Similar problem with update from 2.2.23-1 to 2.2.23-2
--gBBFr7Ir9EOA20Yy
Content-Type: text/plain; charset=us-ascii
Content-
Content-
Hi Andreas,=20
On Fri, Apr 15, 2005 at 11:04:24AM +0200, Andreas Tscharner wrote:
=20
> (Hand typed from screen)
Uargh, that's a lot of work for this. Thanks! Bug is known, please move
the ldabdb directory from /var/backups back to /var/lib/ldap:
# /etc/init.d/slapd stop
# rm /var/lib/ldap/*
# cp -a /var/backups/
# /etc/init.d/slapd start
=20
and you should be fine.
Greetings
Torsten
--gBBFr7Ir9EOA20Yy
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFCYC/
22i3TZRgj79ICU0
=L+js
-----END PGP SIGNATURE-----
--gBBFr7Ir9EOA2
Debian Bug Importer (debzilla) wrote : | #25 |
Message-ID: <email address hidden>
Date: Mon, 18 Apr 2005 01:56:17 -0700
From: Steve Langasek <email address hidden>
To: Torsten Landschoff <email address hidden>, <email address hidden>
Cc: Richard A Nelson <email address hidden>
Subject: Re: Bug#302629: slapd: Unstable upgrade (2.1 -> 2.2) failures
--L6iaP+gRLNZHKoI4
Content-Type: multipart/mixed; boundary=
Content-
--z6Eq5LdranGa6ru8
Content-Type: text/plain; charset=us-ascii
Content-
Content-
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/
> > - directory dc=3Dcavein,
> > (line=3D316) 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: 0000
> > gidNumber: 0000
> > but slapadd barfs on that, saying it is an invalid number! Changing
> > the 0000 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? =20
A naive patch for this might look like the one attached.
Cheers,
--=20
Steve Langasek
postmodern programmer
--z6Eq5LdranGa6ru8
Content-Type: text/plain; charset=us-ascii
Content-
Content-
Index: debian/fix_ldif
=3D=3D=
=3D=3D=
=3D=3D=
--- debian/fix_ldif (revision 516)
+++ debian/fix_ldif (working copy)
@@ -361,7 +361,13 @@
}
=20
#
-# 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.
+# we only check the most commonly affected attributes, which we also
+# happen to know are SINGLE-VALUE.
#
sub checkattrs...
Debian Bug Importer (debzilla) wrote : | #26 |
Message-ID: <email address hidden>
Date: Mon, 18 Apr 2005 11:41:48 +0200
From: Torsten Landschoff <email address hidden>
To: Steve Langasek <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: Bug#302629: slapd: Unstable upgrade (2.1 -> 2.2) failures
--6TrnltStXW4iwmi0
Content-Type: text/plain; charset=us-ascii
Content-
Content-
Hi Steve,=20
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: 0000
> > > gidNumber: 0000
>=20
> > > but slapadd barfs on that, saying it is an invalid number! Changing
> > > the 0000 to 0 for the user and group settings worked fine
>=20
> > ... and another incompatibility.
>=20
> 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? =20
I think we could. OTOH I'd rather find out where those "0000" values are
coming from. Or wtf "0000" 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
--6TrnltStXW4iwmi0
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFCY4DcdQg
3dr4kIr1d2nnlWC
=GXzm
-----END PGP SIGNATURE-----
--6TrnltStXW4iw
Debian Bug Importer (debzilla) wrote : | #27 |
Message-Id: <email address hidden>
Date: Mon, 18 Apr 2005 10:56:35 +0100
From: Greg Matthews <email address hidden>
To: <email address hidden>
Subject: Fails parsing LDIF during upgrade
This appears to be an LDIF parsing problem (which is why I have
submitted it to this bug number). In fact it is more subtle than that.
Feel free to move this to a different bug number if necessary.
The error during a dist-upgrade was:
Installing new version of config file /etc/init.d/slapd ...
Updating config access directives... done.
Moving old database directories to /var/backups:
- directory dc=lea,
Loading from /var/backups/
- directory dc=lea,
dn="dc=my,dc=base" (line=14): txn_aborted! DB_KEYEXIST: Key/data pair
already exists (-30996)
failed.
dpkg: error processing slapd (--configure):
subprocess post-installation script returned error exit status 1
attempting to manually slapadd the LDIF file produced:
/usr/sbin/slapadd -f /etc/ldap/
slapadd: could not parse entry (line=14)
turning on debug info produced:
/usr/sbin/slapadd -d1 -f /etc/ldap/
<snip>
backend_startup: starting "dc=lea,
bdb_db_open: dbenv_open(
=> str2entry: "dn: dc=my,dc=base
dc: my
objectClass: top
objectClass: domain
objectClass: nisDomainObject
structuralObjec
entryUUID: 142d2f8e-
creatorsName: cn=manager,
createTimestamp: 20030725140732Z
nisDomain: foobar
entryCSN: 2003092908:
modifiersName: cn=manager,
modifyTimestamp: 20030929085714Z
"
>>> dnPrettyNormal: <dc=my,dc=base>
<<< dnPrettyNormal: <dc=my,dc=base>, <dc=my,dc=base>
str2entry: invalid value for attributeType objectClass #2 (syntax
1.3.6.1.
slapadd: could not parse entry (line=14)
slapadd shutdown: initiated
====> bdb_cache_
slapadd shutdown: freeing system resources.
openldap is known for obscure error messages but I believe this is
caused by trying to add data that is not within the DIT defined by the
suffix. The reasons for this are outlined below.
path names are not absolute for the binaries slapadd/slapcat nor for the
configuration file /etc/ldap/
loss of data in my directory***
I have another openldap installed in /usr/local and binaries for this
installation appear first in PATH. this meant that slapcat and slapadd
were working on the wrong directory and so the backup kept
in /var/backups/
directory data is LOST!
I suggest that binaries are defined explicitly as well as paths to
config files eg:
/usr/bin/slapcat -f /etc/ldap/
/usr/bin/slapadd -f /etc/ldap/
to prevent this happening in future.
GREG
hardware: Dell optiplex desktop
distro: sarge
kernel: 2.6.8-2-686
slapd: upgrade from 2.1.30-3 to 2.2.23 (dist-upgrade)
--
Greg Matthews
iTSS Wallingford 01491 692445
Debian Bug Importer (debzilla) wrote : | #28 |
Message-ID: <email address hidden>
Date: Tue, 19 Apr 2005 01:22:13 -0700
From: Steve Langasek <email address hidden>
To: Torsten Landschoff <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#302629: slapd: Unstable upgrade (2.1 -> 2.2) failures
--lEGEL1/lMxI0MVQ2
Content-Type: text/plain; charset=us-ascii
Content-
Content-
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 thi=
s:
> > > > uidNumber: 0000
> > > > gidNumber: 0000
> > > > but slapadd barfs on that, saying it is an invalid number! Changi=
ng
> > > > the 0000 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 k=
now
> > 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? =20
> I think we could. OTOH I'd rather find out where those "0000" values are
> coming from. Or wtf "0000" 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.
mailPreferenceO
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.
--=20
Steve Langasek
postmodern programmer
--lEGEL1/lMxI0MVQ2
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFCZL+
u+HevDYW9tsFrZK
=b6KO
-----END PGP SIGNATURE-----
--lEGEL1/
In Debian Bug tracker #302629, Steve Langasek (vorlon) wrote : Bug#302629: fixed in openldap2.2 2.2.23-4 | #29 |
Source: openldap2.2
Source-Version: 2.2.23-4
We believe that the bug you reported is fixed in the latest version of
openldap2.2, which is due to be installed in the Debian FTP archive:
ldap-utils_
to pool/main/
libldap-
to pool/main/
openldap2.
to pool/main/
openldap2.
to pool/main/
slapd_2.
to pool/main/
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Steve Langasek <email address hidden> (supplier of updated openldap2.2 package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.7
Date: Sat, 23 Apr 2005 22:01:20 -0700
Source: openldap2.2
Binary: slapd ldap-utils libldap-2.2-7
Architecture: source i386
Version: 2.2.23-4
Distribution: unstable
Urgency: low
Maintainer: Torsten Landschoff <email address hidden>
Changed-By: Steve Langasek <email address hidden>
Description:
ldap-utils - OpenLDAP utilities
libldap-2.2-7 - OpenLDAP libraries
slapd - OpenLDAP server (slapd)
Closes: 302629 302743 305785
Changes:
openldap2.2 (2.2.23-4) unstable; urgency=low
.
Torsten Landschoff <email address hidden>:
* debian/control: Make the requirement for debconf a pre-dependency as
we are using it from the maintainer scripts.
* debian/
* debian/
was there to output an error message in case debconf is not available.
.
Steve Langasek <email address hidden>:
* debian/fix_ldif: Add code to fix up oddly formatted integer attribs;
limited use because it only fixes those attributes that we have
prior knowledge of (i.e., those in the default schemas we ship), but
it's something at least. Closes: #302629.
* debian/fix_ldif: Also change fix_ldif to not chew up everything that
has a # in the line: treat lines beginning with # as comments, but #
is a valid character in an attribute value.
* debian/rules: Fix the check for missing lib symbols to use
LD_
have libldap-2.2-7 installed. Closes: #305785.
* debian/po/ja.po: Use the partial translation provided by Kenshi Muto.
.
Stephen Frost <email address hidden>:
* debian/
bracket expression given to grep so it's not treated as a range
(closes: #302743).
Files:
9528bce88602c8
e...
In Debian Bug tracker #302629, Adrian Bunk (bunk) wrote : still present in sarge | #30 |
reopen 302629
tags 302629 +sarge
thanks
In Debian Bug tracker #302629, Steve Langasek (vorlon) wrote : closing 302629, tagging 302629 | #31 |
# Automatically generated email from bts, devscripts version 2.8.14
close 302629
# fixed package accepted in sarge
tags 302629 - sarge
Adam Conrad (adconrad) wrote : | #32 |
This seems to be fixed in the latest versions of 2.2...
Changed in openldap2.2: | |
status: | Unknown → Fix Released |
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: parse_ext( ldapi:/ //????x- mod=0777) //????x- mod=0777
> ldap_url_
> daemon: bind(10) failed errno=2 (No such file or directory)
> slap_open_listener: failed on ldapi:/
>
> 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: slapd-2. 1.30-3:
> 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/
> - 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: 0000
> gidNumber: 0000
>
> but slapadd barfs on that, saying it is an invalid number! Changing
> the 0000 to 0 for the user and group settings worked fine
... and another incompatibility.
Greetings
Torsten