Fails parsing LDIF during upgrade

Bug #14929 reported by Debian Bug Importer
4
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://bugs.debian.org/302629

Revision history for this message
In , Torsten Landschoff (torsten) wrote : Re: 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: 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

Revision history for this message
In , Torsten Landschoff (t-landschoff) wrote : severity of 302629 is serious

severity 302629 serious

Revision history for this message
In , Torsten Landschoff (t-landschoff) wrote : tagging 302629

tags 302629 confirmed

Revision history for this message
In , Torsten Landschoff (t-landschoff) wrote : retitle 302629 to Fails parsing LDIF during upgrade

retitle 302629 Fails parsing LDIF during upgrade

Revision history for this message
In , Torsten Landschoff (torsten) wrote : Re: 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

Revision history for this message
In , Cowboy (cowboy-debian) wrote :

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: 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> ;>

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Automatically imported from Debian bug report #302629 http://bugs.debian.org/302629

Revision history for this message
Debian Bug Importer (debzilla) wrote :
Download full text (3.1 KiB)

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_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: 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=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.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-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
 ...

Read more...

Revision history for this message
Debian Bug Importer (debzilla) wrote :

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-Disposition: inline

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

--jI8keyz6grp/JLjh
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCTgugdQgHtVUb5EcRAvXdAJ9ivMkTOhD3e9MdjhrxK2GRmzxGzwCfQPKC
+YcaVocYmda+qaoN7IfYmm4=
=x28C
-----END PGP SIGNATURE-----

--jI8keyz6grp/JLjh--

Revision history for this message
Debian Bug Importer (debzilla) wrote :

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-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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_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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCTgVAdQgHtVUb5EcRAmU5AJ9VRre0Q64N++gHRE2ZJycEPQ2KqACfZDJz
cZouGxaWnl7BNtjtOmUdbQ8=
=D1WE
-----END PGP SIGNATURE-----

--AhhlLboLdkugWU4S--

Revision history for this message
Debian Bug Importer (debzilla) wrote :

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

Revision history for this message
Debian Bug Importer (debzilla) wrote :

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

Revision history for this message
Debian Bug Importer (debzilla) wrote :

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

Revision history for this message
Debian Bug Importer (debzilla) wrote :

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_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: 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> ;>

Revision history for this message
Matt Zimmerman (mdz) wrote :

I think this may be specific to 2.2.x, but please investigate and confirm

Revision history for this message
Adam Conrad (adconrad) wrote :

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.

Revision history for this message
In , Andreas Tscharner (andy-blackmoon) wrote : 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/slapd.conf in /var/backups/slapd-2.2.23-1... done.
  Moving old database directories to /var/backups:
  Loading from /var/backups/slapd-2.2.23-1:
  -directory dc=tasha,dc=blackmoon,dc=ch... /var/lib/dpkg/info/slapd.postinst: line 103: /var/backups/slapd-2.2.23-1/dc=tasha,dc=blackmoon,dc=ch.ldif: No such file or directory
/var/lib/dpkg/info/slapd.postinst: line 106: [: : integer expression expected
failed.

Loading the dazabase from the LDIF dump failed with the following
error while running slapadd:
    /var/backup/slapd-2.2.23-1/dc=tasha,dc=blackmoon,dc=ch.ldif: No such file or directory
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=ANSI_X3.4-1968)

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-base64-perl] 5.8.4-8 Larry Wall's Practical Extraction
ii psmisc 21.6-1 Utilities that use the proc filesy

-- debconf information excluded

Revision history for this message
In , Torsten Landschoff (torsten) wrote : Re: Bug#302629: slapd: Similar problem with update from 2.2.23-1 to 2.2.23-2

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/*-2.3.23-1.ldapdb /var/lib/ldap/
   # /etc/init.d/slapd start

and you should be fine.

Greetings

 Torsten

Revision history for this message
In , Steve Langasek (vorlon) wrote : Re: 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: 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

Revision history for this message
In , Torsten Landschoff (torsten) wrote :

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

Revision history for this message
In , Greg Matthews (gmatt) wrote :

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,dc=my,dc=base... done.
  Loading from /var/backups/slapd-2.1.30-3:
  - directory dc=lea,dc=my,dc=base... slapadd: could not add entry
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/slapd.conf -l /var/backups/slapd-2.1.30-3/foo.ldif
slapadd: could not parse entry (line=14)

turning on debug info produced:
/usr/sbin/slapadd -d1 -f /etc/ldap/slapd.conf -l /var/backups/slapd-2.1.30-3/foo.ldif
<snip>
backend_startup: starting "dc=lea,dc=my,dc=base"
bdb_db_open: dbenv_open(/var/lib/ldap)
=> str2entry: "dn: dc=my,dc=base
dc: my
objectClass: top
objectClass: domain
objectClass: nisDomainObject
structuralObjectClass: domain
entryUUID: 142d2f8e-52f5-1027-8b41-c022ab19fc70
creatorsName: cn=manager,dc=my,dc=base
createTimestamp: 20030725140732Z
nisDomain: foobar
entryCSN: 2003092908:57:14Z#0x0001#0#0000
modifiersName: cn=manager,dc=my,dc=base
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.4.1.1466.115.121.1.38)
slapadd: could not parse entry (line=14)
slapadd shutdown: initiated
====> bdb_cache_release_all
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/slapd.conf. ***This has led to complete
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/slapd-2.1.30-3 is a backup of the wrong data and my
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/slapd.conf -l /var/backups/slapd...
/usr/bin/slapadd -f /etc/ldap/slapd.conf -l /var/backups/sla....

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

Revision history for this message
In , Steve Langasek (vorlon) wrote :

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.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

Revision history for this message
Debian Bug Importer (debzilla) wrote :

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/slapd.conf in /var/backups/slapd-2.2.23-1... done.
  Moving old database directories to /var/backups:
  Loading from /var/backups/slapd-2.2.23-1:
  -directory dc=tasha,dc=blackmoon,dc=ch... /var/lib/dpkg/info/slapd.postinst: line 103: /var/backups/slapd-2.2.23-1/dc=tasha,dc=blackmoon,dc=ch.ldif: No such file or directory
/var/lib/dpkg/info/slapd.postinst: line 106: [: : integer expression expected
failed.

Loading the dazabase from the LDIF dump failed with the following
error while running slapadd:
    /var/backup/slapd-2.2.23-1/dc=tasha,dc=blackmoon,dc=ch.ldif: No such file or directory
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=ANSI_X3.4-1968)

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-base64-perl] 5.8.4-8 Larry Wall's Practical Extraction
ii psmisc 21.6-1 Utilities that use the proc filesy

-- debconf information excluded

Revision history for this message
Debian Bug Importer (debzilla) wrote :

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-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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/*-2.3.23-1.ldapdb /var/lib/ldap/
   # /etc/init.d/slapd start
=20
and you should be fine.

Greetings

 Torsten

--gBBFr7Ir9EOA20Yy
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCYC/udQgHtVUb5EcRAnJLAJ9CAC73XINBPKx1IfcW217SEA9OAwCffhv0
22i3TZRgj79ICU0CjbHKBxU=
=L+js
-----END PGP SIGNATURE-----

--gBBFr7Ir9EOA20Yy--

Revision history for this message
Debian Bug Importer (debzilla) wrote :
Download full text (3.8 KiB)

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="z6Eq5LdranGa6ru8"
Content-Disposition: inline

--z6Eq5LdranGa6ru8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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:=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.

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-Disposition: attachment; filename="openldap2.2-302629.patch"
Content-Transfer-Encoding: quoted-printable

Index: debian/fix_ldif
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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.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...

Read more...

Revision history for this message
Debian Bug Importer (debzilla) wrote :

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-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCY4DcdQgHtVUb5EcRAm+/AJ44t28EgeECeRb5bS8P+SoAsHpLfwCeMuat
3dr4kIr1d2nnlWCyF6UOwg0=
=GXzm
-----END PGP SIGNATURE-----

--6TrnltStXW4iwmi0--

Revision history for this message
Debian Bug Importer (debzilla) wrote :

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,dc=my,dc=base... done.
  Loading from /var/backups/slapd-2.1.30-3:
  - directory dc=lea,dc=my,dc=base... slapadd: could not add entry
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/slapd.conf -l /var/backups/slapd-2.1.30-3/foo.ldif
slapadd: could not parse entry (line=14)

turning on debug info produced:
/usr/sbin/slapadd -d1 -f /etc/ldap/slapd.conf -l /var/backups/slapd-2.1.30-3/foo.ldif
<snip>
backend_startup: starting "dc=lea,dc=my,dc=base"
bdb_db_open: dbenv_open(/var/lib/ldap)
=> str2entry: "dn: dc=my,dc=base
dc: my
objectClass: top
objectClass: domain
objectClass: nisDomainObject
structuralObjectClass: domain
entryUUID: 142d2f8e-52f5-1027-8b41-c022ab19fc70
creatorsName: cn=manager,dc=my,dc=base
createTimestamp: 20030725140732Z
nisDomain: foobar
entryCSN: 2003092908:57:14Z#0x0001#0#0000
modifiersName: cn=manager,dc=my,dc=base
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.4.1.1466.115.121.1.38)
slapadd: could not parse entry (line=14)
slapadd shutdown: initiated
====> bdb_cache_release_all
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/slapd.conf. ***This has led to complete
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/slapd-2.1.30-3 is a backup of the wrong data and my
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/slapd.conf -l /var/backups/slapd...
/usr/bin/slapadd -f /etc/ldap/slapd.conf -l /var/backups/sla....

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

Revision history for this message
Debian Bug Importer (debzilla) wrote :

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-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.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.

--=20
Steve Langasek
postmodern programmer

--lEGEL1/lMxI0MVQ2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCZL+1KN6ufymYLloRAt2UAKClPj9jJ9Qlkoi//zoniupUy/XoMACfYwCf
u+HevDYW9tsFrZK8KJONZQk=
=b6KO
-----END PGP SIGNATURE-----

--lEGEL1/lMxI0MVQ2--

Revision history for this message
In , Steve Langasek (vorlon) wrote : Bug#302629: fixed in openldap2.2 2.2.23-4
Download full text (3.6 KiB)

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_2.2.23-4_i386.deb
  to pool/main/o/openldap2.2/ldap-utils_2.2.23-4_i386.deb
libldap-2.2-7_2.2.23-4_i386.deb
  to pool/main/o/openldap2.2/libldap-2.2-7_2.2.23-4_i386.deb
openldap2.2_2.2.23-4.diff.gz
  to pool/main/o/openldap2.2/openldap2.2_2.2.23-4.diff.gz
openldap2.2_2.2.23-4.dsc
  to pool/main/o/openldap2.2/openldap2.2_2.2.23-4.dsc
slapd_2.2.23-4_i386.deb
  to pool/main/o/openldap2.2/slapd_2.2.23-4_i386.deb

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/slapd.preinst: Always use debconf (don't check for availability).
   * debian/slapd.scripts-common: Remove the alert_user function which
     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_LIBRARY_PATH, so the package builds on systems that don't already
     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/slapd.scripts-common: Make sure - ends up at the end of the
     bracket expression given to grep so it's not treated as a range
     (closes: #302743).
Files:
 9528bce88602c86516b383cc4697b7df 1035 net optional openldap2.2_2.2.23-4.dsc
 e...

Read more...

Revision history for this message
In , Adrian Bunk (bunk) wrote : still present in sarge

reopen 302629
tags 302629 +sarge
thanks

Revision history for this message
In , Steve Langasek (vorlon) wrote : closing 302629, tagging 302629

# Automatically generated email from bts, devscripts version 2.8.14
close 302629
 # fixed package accepted in sarge
tags 302629 - sarge

Revision history for this message
Adam Conrad (adconrad) wrote :

This seems to be fixed in the latest versions of 2.2...

Changed in openldap2.2:
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.