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=3D0777)
> daemon: bind(10) failed errno=3D2 (No such file or directory)
> slap_open_listener: failed on ldapi:///????x-mod=3D0777
>=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/slapd-2.1.30-3:=20
> - directory dc=3Dcavein,dc=3Dorg... slapadd: could not parse entry
> (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/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
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 Disposition: inline Transfer- Encoding: quoted-printable
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: parse_ext( ldapi:/ //????x- mod=3D0777) //????x- mod=3D0777
> 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: slapd-2. 1.30-3: =20 dc=3Dorg. .. slapadd: could not parse entry
> 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 pgp-signature; name="signature .asc" Description: Digital signature Disposition: inline
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
HtVUb5EcRAmU5AJ 9VRre0Q64N+ +gHRE2ZJycEPQ2K qACfZDJz tOmUdbQ8=
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFCTgVAdQg
cZouGxaWnl7BNtj
=D1WE
-----END PGP SIGNATURE-----
--AhhlLboLdkugW U4S--