- openldap-bugs - openldap.org

Re: (ITS#6151) Update cosine.schema to RFC 4524
by masarati＠aero.polimi.it 22 Apr '10

22 Apr '10

> Kurt Zeilenga wrote: >> obsoletes != OBSOLETE, so no. That is, the meaning of the term >> 'obsolete' is quite different in these two contexts. >> >> The latter context the term is defined as follows: The OBSOLETE field, >> if >> present, indicates the element is not active. > > I agree that OBSOLETE should not be set in this case. > >> For user application attribute types, whether the type is active or not >> is, >> I think, best left to the schema administrator. > > Who is the schema administrator? I'm nitpicking here because on the > OpenLDAP > lists we all keep telling OpenLDAP admins not to mess with the standard > schema > at all. IMO this includes setting OBSOLETE. I Think there's a misunderstanding. My understanding (and intention) is 1) You said you pulled in revisited cosine.schema also elements that were dropped in RFC4524. 2) I was asking whether the fact they were dropped implied they were OBSOLETE (i.e. had to be marked as OBSOLETE in their schema definition) 3) Kurt replied that they MUST NOT be marked as OBSOLETE. Whether they are loaded or not in a DSA's schema is at the DSA schema administrator's choice 4) This, IMHO, implies that we need to provide two separate files, to allow DSA admins to either load strict RFC4524 schema (no obsolete items) or loose RFC4524 (entire RFC1274 schema). Now, we have different options to arrange the resulting schema files (names used below are only an example, the final name can be discussed when there's consensus on the approach): a) cosine.schema (== RFC1274) cosine4524.schema (== RFC4524) mutually exclusive (Kurt does not like this) b) cosine4524.schema (== RFC4524) cosine.schema (== RFC1274 - RFC4524) the latter includes the former c) cosine4524.schema (== RFC4524) cosine1274.schema (== RFC1274 - RFC4524) (there might be more) Cases (a) and (b) have advantages: loading cosine.schema loads all RFC1274 schema, thus existing configurations surely do not break. I concur case (a) would cause a lot of complaints from people loading all available schema files and having conflicts. Case (c) needs to modify configuration, but avoids file nesting, if that's a problem at all. p.

1 0

(ITS#6517) undefined references to ldif_*
by abartlet＠samba.org 22 Apr '10

22 Apr '10

--=-hLLTpGMzur3nD+xeX+/o Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Using these instructions, the issue remains with current CVS: I have had it sometimes build from an old tree, but this from scratch does not: =3D=3DGetting OpenLDAP=3D=3D This guide presumes you are running OpenLDAP CVS HEAD from after 22 April 2010 (or a release after that date) You need the 'deref' and 'rdnval' overlay. This may be in your packaged version, but if not your must rebuild. To get OpenLDAP from CVS run: CVSROOT=3D:pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP export CVSROOT cvs login You will need to enter at the prompt: Password: (enter OpenLDAP) Then check out the tree cvs -z3 checkout -P openldap Then change to the newly created 'openldap' directory: cd openldap To update your OpenLDAP checkout (discarding local conflicts) from CVS run: cvs -z9 update -dP 2>&1 | grep ^C | cut -b3-| xargs rm cvs -z9 update -dP To build it run: CFLAGS=3D"-fno-omit-frame-pointer" `dirname $0`/configure --enable-overlays=3Dmod --enable-modules --enable-dynamic || exit 1 make clean all AC_CFLAGS=3D-g --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. --=-hLLTpGMzur3nD+xeX+/o Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iD8DBQBL0BYkz4A8Wyi0NrsRAuntAKCf7rc4Q9IQrpMwcTeY6cOQIaSgnQCeOGh2 FxErm+tMjQUnb0y7Hmgs9n8= =zuyi -----END PGP SIGNATURE----- --=-hLLTpGMzur3nD+xeX+/o--

1 0

Re: (ITS#6151) Update cosine.schema to RFC 4524
by michael＠stroeder.com 22 Apr '10

22 Apr '10

Kurt Zeilenga wrote: > obsoletes != OBSOLETE, so no. That is, the meaning of the term > 'obsolete' is quite different in these two contexts. > > The latter context the term is defined as follows: The OBSOLETE field, if > present, indicates the element is not active. I agree that OBSOLETE should not be set in this case. > For user application attribute types, whether the type is active or not is, > I think, best left to the schema administrator. Who is the schema administrator? I'm nitpicking here because on the OpenLDAP lists we all keep telling OpenLDAP admins not to mess with the standard schema at all. IMO this includes setting OBSOLETE. Ciao, Michael.

1 0

Re: (ITS#6151) Update cosine.schema to RFC 4524
by kurt＠OpenLDAP.org 22 Apr '10

22 Apr '10

On Apr 21, 2010, at 6:03 PM, masarati(a)aero.polimi.it wrote: >> Kurt Zeilenga wrote: >>>=20 >>> On Jun 1, 2009, at 4:30 AM, michael(a)stroeder.com wrote: >>>> Updated schema file cosine-update.schema attached. >>>=20 >>> I note that differs are generally preferred, even where the file is >>> mostly changed. This helps ensure changes that others might make to = the >>> file you started with are not lost. >>=20 >> I thought about sending a diff but the file in this form is more >> readable for easy review. Could someone please look at it whether = that's >> ok? >=20 >> Another approach would be to have two schema files, one which only >> contains the schema descriptions from RFC 4524 and one with the = missing >> schema descriptions from RFC 1274 with the latter obviously being >> dependent on the former. >=20 > I have one preliminary question for Kurt: since rfc4524 obsoletes = rfc1274, > should those schema items that were not brought forward be marked as > OBSOLETE? obsoletes !=3D OBSOLETE, so no. That is, the meaning of the term = 'obsolete' is quite different in these two contexts. The latter context the term is defined as follows: The OBSOLETE field, if present, indicates the element is not active. For user application attribute types, whether the type is active or not = is, I think, best left to the schema administrator. (Update operations = upon an inactive element is limited to removal of the element.) > If yes, then all schema could fit in one file. I'd like a > clear way to separate valid from obsolete schema. The obsolete items > should be available for backwards compatibility. As an alternative, = I'd > like to have a "slim" (without obsolete) and a complete version of the > file. I rather no element be specified in multiple files. > Could you please upload the file? Through the ITS attachments > don't work too well. >=20 >>>> IPR notice: >>>> This patch file is derived from OpenLDAP Software and RFC 4524 and = RFC >>>> 1274. All of the modifications to OpenLDAP Software represented in = the >>>> attached file were developed by Michael Str=F6der = <michael(a)stroeder.com>. >>>> I have not assigned rights and/or interest in this work to any = party. >>>=20 >>> While this notice of origin is fine, you did not include a rights >>> statement. >>=20 >> I, Michael Str=F6der, hereby place the modified schema file = cosine.schema >> attached to ITS#6151 (and only these modifications) into the public >> domain. Hence, these modifications may be freely used and/or >> redistributed for any purpose with or without attribution and/or = other >> notice. >=20 > Am I right in assuming this IPR is fine? Thanks, p. Yes. - Kurt

1 0

ITS#6250
by masarati＠aero.polimi.it 22 Apr '10

22 Apr '10

Why is this ITS in software development, and open? Anyone intends to develop that feature, despite the discussion? p.

1 0

Re: (ITS#6151) Update cosine.schema to RFC 4524
by masarati＠aero.polimi.it 22 Apr '10

22 Apr '10

> Kurt Zeilenga wrote: >> >> On Jun 1, 2009, at 4:30 AM, michael(a)stroeder.com wrote: >>> Updated schema file cosine-update.schema attached. >> >> I note that differs are generally preferred, even where the file is >> mostly changed. This helps ensure changes that others might make to the >> file you started with are not lost. > > I thought about sending a diff but the file in this form is more > readable for easy review. Could someone please look at it whether that's > ok? > Another approach would be to have two schema files, one which only > contains the schema descriptions from RFC 4524 and one with the missing > schema descriptions from RFC 1274 with the latter obviously being > dependent on the former. I have one preliminary question for Kurt: since rfc4524 obsoletes rfc1274, should those schema items that were not brought forward be marked as OBSOLETE? If yes, then all schema could fit in one file. I'd like a clear way to separate valid from obsolete schema. The obsolete items should be available for backwards compatibility. As an alternative, I'd like to have a "slim" (without obsolete) and a complete version of the file. Could you please upload the file? Through the ITS attachments don't work too well. >>> IPR notice: >>> This patch file is derived from OpenLDAP Software and RFC 4524 and RFC >>> 1274. All of the modifications to OpenLDAP Software represented in the >>> attached file were developed by Michael Ströder <michael(a)stroeder.com>. >>> I have not assigned rights and/or interest in this work to any party. >> >> While this notice of origin is fine, you did not include a rights >> statement. > > I, Michael Ströder, hereby place the modified schema file cosine.schema > attached to ITS#6151 (and only these modifications) into the public > domain. Hence, these modifications may be freely used and/or > redistributed for any purpose with or without attribution and/or other > notice. Am I right in assuming this IPR is fine? Thanks, p.

1 0

Re: (ITS#6529) slapcat: bad configuration file!
by masarati＠aero.polimi.it 22 Apr '10

22 Apr '10

> Full_Name: SLava > Version: 2.4.21 > OS: Gentoo Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (77.120.255.22) > > > My aim is to regularly backup openldap database, so I created a special > backup-user to do that. But while doing this command: "slapcat -f > /etc/openldap/slapd.conf -b "dc=my,dc=domain,dc=com" -l backup.ldif - I > get this > error: "/etc/openldap/slapd.conf: line 77: invalid path: Permission denied > slapcat: bad configuration file!". I watched my conf file and there is > "directory /var/lib/openldap-data/my-domain-com" string in line 77. I > looked for > permission rights and all seems to be properly. Don't know what to do... > > By the way, the same command under "root" works perfectly. Your file permissions are obviously inappropriate for the operation you're trying to perform. There is no evidence of an OpenLDAP bug; there is not even an evidence of an LDAP-related issue. This ITS will be closed. p.

1 0

Re: (ITS#6472) Syncrepl : loop problem with moddn on a new node
by masarati＠aero.polimi.it 21 Apr '10

21 Apr '10

This is a known issue. That patch is now obsoleted by the code that has been committed to HEAD and ported to re24 for release. Please test re24 out of the CVS, or apply the corresponding modifications to slapd/syncrepl.c to 2.4.21, and test. Please note that test018 has been modified to reproduce and test the problem you highlighted. If you run the new test18 with 2.4.21 it should consistently fail, while it passes with the new code. p. > Hello, > > Le 17/04/2010 22:00, > masarati(a)aero.polimi.it (par Internet) a écrit : >> A fix is in HEAD, please test > > I have tried the compilaltion of the source 2.4.21 with your patch, > "make test" failed on "test020-proxycache for bdb" with this error : > > >>>>> Starting test020-proxycache for bdb... > Starting master slapd on TCP/IP port 9011... > Using ldapsearch to check that master slapd is running... > Using ldapadd to populate the master directory... > Starting proxy cache on TCP/IP port 9012... > Using ldapsearch to check that proxy slapd is running... > Making queries on the proxy cache... > Query 1: filter:(sn=Jon) attrs:all (expect nothing) > Query 2: filter:(|(cn=*Jon*)(sn=Jon*)) attrs:cn sn title uid > Query 3: filter:(sn=Smith*) attrs:cn sn uid > ./scripts/test020-proxycache: line 173: 16714 Erreur de segmentation > $SLAPD -f $CONF2 -h $URI2 -d $LVL -d pcache > $LOG2 2>&1 > ldapsearch failed (255)! > ./scripts/test020-proxycache: line 177: kill: (16714) - Aucun processus > de ce type > >>>>> ./scripts/test020-proxycache failed for bdb (exit 255) > make[2]: *** [bdb-mod] Erreur 255 > make[2]: quittant le répertoire « > /root/openldap/2.4.21-its6472/compil-upstream/openldap-2.4.21/tests » > make[1]: *** [test] Erreur 2 > make[1]: quittant le répertoire « > /root/openldap/2.4.21-its6472/compil-upstream/openldap-2.4.21/tests » > make: *** [test] Erreur 2 > > I have used this compilation steps : > tar -zxvf openldap-2.4.21.tgz > > cd openldap-2.4.21 > > patch -p0 < ../pierangelo-masarati-2010-04-17-sync-rename.1.patch > patching file servers/slapd/syncrepl.c > Hunk #2 succeeded at 2554 (offset -10 lines). > Hunk #3 succeeded at 2891 (offset -10 lines). > Hunk #4 succeeded at 3026 (offset -10 lines). > > ./configure --enable-debug --enable-dynamic --enable-syslog > --enable-proctitle --enable-ipv6 --enable-local --enable-slapd > --enable-aci --enable-cleartext --enable-crypt --disable-lmpasswd > --enable-spasswd --enable-modules --enable-rewrite --enable-rlookups > --enable-slapi --enable-slp --enable-wrappers --enable-backends=mod > --enable-ldbm=no --disable-ndb --enable-overlays=mod --with-subdir=ldap > --with-cyrus-sasl --with-threads --with-tls=openssl --with-odbc=unixodbc > > make depend > > make > > make test > > regards, > Julien > >

1 0

(ITS#6529) slapcat: bad configuration file!
by slava.kargaltsev＠gmail.com 21 Apr '10

21 Apr '10

Full_Name: SLava Version: 2.4.21 OS: Gentoo Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (77.120.255.22) My aim is to regularly backup openldap database, so I created a special backup-user to do that. But while doing this command: "slapcat -f /etc/openldap/slapd.conf -b "dc=my,dc=domain,dc=com" -l backup.ldif - I get this error: "/etc/openldap/slapd.conf: line 77: invalid path: Permission denied slapcat: bad configuration file!". I watched my conf file and there is "directory /var/lib/openldap-data/my-domain-com" string in line 77. I looked for permission rights and all seems to be properly. Don't know what to do... By the way, the same command under "root" works perfectly.

1 0

Re: ITS#6055
by masarati＠aero.polimi.it 21 Apr '10

21 Apr '10

> Can you give me the exact commands I need to put into the wiki, for a > user to go from a checkout of OpenLDAP, to a build with this module > installed just like all the others? Assuming one builds in the tree, - follow instructions for anonymous CVS checkout of HEAD branch <http://www.openldap.org/software/repo.html#AnonCVS> - cd contrib/slapd-modules/samba4 - edit Makefile if needed; as it is, it assumes you build in tree, and installs in /usr/local/libexec/openldap - make; make install - in slapd.conf: modulepath /usr/local/libexec/openldap moduleload rdnval.la # ... database hdb # ... overlay rdnval That's it. p.

1 0

Re: ITS#6055
by abartlet＠samba.org 21 Apr '10

21 Apr '10

--=-GJES2Ff4FHn/Nl+ftOBF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2010-04-21 at 05:42 +0200, masarati(a)aero.polimi.it wrote: > > My eventual goal is that folks using a Ubuntu or Fedora system would > > have Samba4 'just work' with the packaged OpenLDAP. I can of course > > lobby them to get their packages updated to build from contrib, but it'= s > > easier if it's just in there.=3D20 > > > > Similarly, when I ask folks to configure with 'OpenLDAP HEAD' in the > > short term, it is of course easier for me if everything is already in > > place.=3D20 > > > > But this is your project, not mine, and I am happy with whatever we can > > make work.=3D20 >=20 > Right now, along the lines illustrated by Howard, I've committed > everything to contrib/slapd-modules/samba4. You may need to tweak the > Makefile if you are not building in the source tree (as I usually do; the= n > adjust LDAP_BUILD to your build tree), and if you wish to install modules > in some specific place (prefix, exec_prefix, ldap_subdir). >=20 > My medium term objective would be to have: >=20 > - generally useful modules built-in (e.g. slapo-deref) >=20 > - Samba4-specific modules all in one contrib directory, possibly > harmonized and consolidated when possible in a single module, to ease > configuration and maintenance >=20 > The latter could then have a specific configure, if needed, so that > packagers could make and install them as easily as possible. In the > meanwhile, we should live with this interim solution. Time permitting, I > see no issue in maintaining that code, much like we already do with the > other modules. Can you give me the exact commands I need to put into the wiki, for a user to go from a checkout of OpenLDAP, to a build with this module installed just like all the others? Thanks, --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. --=-GJES2Ff4FHn/Nl+ftOBF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQBLznxIz4A8Wyi0NrsRAl6mAJ4+rykBiTBAhn3ANiDgEfc8dG1OAgCghGeg ycx5bF3Vlb1Yx3OMwa3p13k= =XUh6 -----END PGP SIGNATURE----- --=-GJES2Ff4FHn/Nl+ftOBF--

1 0

Re: ITS#6055
by masarati＠aero.polimi.it 21 Apr '10

21 Apr '10

> My eventual goal is that folks using a Ubuntu or Fedora system would > have Samba4 'just work' with the packaged OpenLDAP. I can of course > lobby them to get their packages updated to build from contrib, but it's > easier if it's just in there.=20 > > Similarly, when I ask folks to configure with 'OpenLDAP HEAD' in the > short term, it is of course easier for me if everything is already in > place.=20 > > But this is your project, not mine, and I am happy with whatever we can > make work.=20 Right now, along the lines illustrated by Howard, I've committed everything to contrib/slapd-modules/samba4. You may need to tweak the Makefile if you are not building in the source tree (as I usually do; then adjust LDAP_BUILD to your build tree), and if you wish to install modules in some specific place (prefix, exec_prefix, ldap_subdir). My medium term objective would be to have: - generally useful modules built-in (e.g. slapo-deref) - Samba4-specific modules all in one contrib directory, possibly harmonized and consolidated when possible in a single module, to ease configuration and maintenance The latter could then have a specific configure, if needed, so that packagers could make and install them as easily as possible. In the meanwhile, we should live with this interim solution. Time permitting, I see no issue in maintaining that code, much like we already do with the other modules. p.

1 0

Re: ITS#6055
by abartlet＠samba.org 21 Apr '10

21 Apr '10

--=-dnOZfedjaeI8f/8PVlNm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2010-04-21 at 04:32 +0200, masarati(a)aero.polimi.it wrote: > > My only concern is that it be maintained, so that the OpenLDAP backend > > can be a supported part of Samba4 into the long term. (I know it's not > > been in good shape for the past while, but there is hope we can get it > > back on track). > > > > Do contrib modules come with this level of maintenance? >=20 > Inherently no, because they would not be configured/built along with the > rest of the package. Of course, as soon as users (possibly including > myself) notice issues, they would be maintained (see for example nssov). >=20 > The most straightforward way of having it routinely built is to place it > in slapd/overlays/; I guess this needs consensus from the rest of the > team. I'd vote in favor; please holler. My eventual goal is that folks using a Ubuntu or Fedora system would have Samba4 'just work' with the packaged OpenLDAP. I can of course lobby them to get their packages updated to build from contrib, but it's easier if it's just in there.=20 Similarly, when I ask folks to configure with 'OpenLDAP HEAD' in the short term, it is of course easier for me if everything is already in place.=20 But this is your project, not mine, and I am happy with whatever we can make work.=20 Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. --=-dnOZfedjaeI8f/8PVlNm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQBLzmzwz4A8Wyi0NrsRAomfAJ9J4b76Ujcu5fC3Yig3lgIBJ712ywCeOw3U fDuSKTOqEEfK1JEriBOcJ8g= =FSwh -----END PGP SIGNATURE----- --=-dnOZfedjaeI8f/8PVlNm--

1 0

Re: ITS#6055
by masarati＠aero.polimi.it 21 Apr '10

21 Apr '10

> masarati(a)aero.polimi.it wrote: >>> My only concern is that it be maintained, so that the OpenLDAP backend >>> can be a supported part of Samba4 into the long term. (I know it's not >>> been in good shape for the past while, but there is hope we can get it >>> back on track). >>> >>> Do contrib modules come with this level of maintenance? >> >> Inherently no, because they would not be configured/built along with the >> rest of the package. Of course, as soon as users (possibly including >> myself) notice issues, they would be maintained (see for example nssov). >> >> The most straightforward way of having it routinely built is to place it >> in slapd/overlays/; I guess this needs consensus from the rest of the >> team. I'd vote in favor; please holler. > > I think contrib is the right place for now. It seems to me that the > requirements here are still a moving target, so it's better in contrib. > (Contrib items are free to add new features independent of the rest of the > release cycle. Items in the main slapd/overlays are more constrained to > bugfixes-only within a release cycle.) Fair enough. I've started committing stuff to contrib/slapd-modules/samba4 p.

1 0

Re: ITS#6055
by hyc＠symas.com 21 Apr '10

21 Apr '10

masarati(a)aero.polimi.it wrote: >> My only concern is that it be maintained, so that the OpenLDAP backend >> can be a supported part of Samba4 into the long term. (I know it's not >> been in good shape for the past while, but there is hope we can get it >> back on track). >> >> Do contrib modules come with this level of maintenance? > > Inherently no, because they would not be configured/built along with the > rest of the package. Of course, as soon as users (possibly including > myself) notice issues, they would be maintained (see for example nssov). > > The most straightforward way of having it routinely built is to place it > in slapd/overlays/; I guess this needs consensus from the rest of the > team. I'd vote in favor; please holler. I think contrib is the right place for now. It seems to me that the requirements here are still a moving target, so it's better in contrib. (Contrib items are free to add new features independent of the rest of the release cycle. Items in the main slapd/overlays are more constrained to bugfixes-only within a release cycle.) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: ITS#6055
by masarati＠aero.polimi.it 21 Apr '10

21 Apr '10

> My only concern is that it be maintained, so that the OpenLDAP backend > can be a supported part of Samba4 into the long term. (I know it's not > been in good shape for the past while, but there is hope we can get it > back on track). > > Do contrib modules come with this level of maintenance? Inherently no, because they would not be configured/built along with the rest of the package. Of course, as soon as users (possibly including myself) notice issues, they would be maintained (see for example nssov). The most straightforward way of having it routinely built is to place it in slapd/overlays/; I guess this needs consensus from the rest of the team. I'd vote in favor; please holler. p.

1 0

Re: ITS#6055
by abartlet＠samba.org 21 Apr '10

21 Apr '10

--=-plI2z6xrAOfHgQ7f8NT2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2010-04-21 at 03:44 +0200, masarati(a)aero.polimi.it wrote: > > On Tue, 2010-04-20 at 15:37 +0200, masarati(a)aero.polimi.it wrote: > >> > That's no problem at all. > >> > >> Good. This version explicitly check for instantiation as global, and > >> also > >> does some further sanity checks prior to startup. > >> > >> <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-20-rdnval= .2.c> > >> > >> > It now just fails in the same was as without > >> > the patch. I'll mention it on openldap-technical if I can't get > >> > assistance on #ldap. > >> > >> Not quite clear what patch and what failure you refer to. Anyway, I'v= e > >> tested this version of the overlay as global (refuses to start) and on= a > >> database, either empty or populated, and it works as intended. Please > >> test and report. Thanks, p. > > > > It seems to be working well. When can I expect it to be in the tree? > > > > (I'll then require folks to use the current OpenLDAP CVS if they want t= o > > use the LDAP backend). >=20 > I can commit it in a minute. It's not 100% clear to me what's the most > appropriate location: slapd/overlays/ may not, as this looks like > something definitely specific to Samba4; probably, contrib/slapd-modules/ > is more appropriate. Perhaps, a contrib/slapd-modules/samba4/ would be > the most appropriate, along with future specific (i.e. not of general > usefulness) modules, as we did for the nssov module. >=20 > Comments? I mean, from others, not only from you :) My only concern is that it be maintained, so that the OpenLDAP backend can be a supported part of Samba4 into the long term. (I know it's not been in good shape for the past while, but there is hope we can get it back on track).=20 Do contrib modules come with this level of maintenance? Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. --=-plI2z6xrAOfHgQ7f8NT2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iD8DBQBLzmHxz4A8Wyi0NrsRAlF3AKCXBqb/jzSgemy/GREWapoan6QkVwCgj1of Dmourk1xQiMAlvWFJocYuSQ= =rE8J -----END PGP SIGNATURE----- --=-plI2z6xrAOfHgQ7f8NT2--

1 0

Re: ITS#6055
by masarati＠aero.polimi.it 21 Apr '10

21 Apr '10

> On Tue, 2010-04-20 at 15:37 +0200, masarati(a)aero.polimi.it wrote: >> > That's no problem at all. >> >> Good. This version explicitly check for instantiation as global, and >> also >> does some further sanity checks prior to startup. >> >> <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-20-rdnval.2.c> >> >> > It now just fails in the same was as without >> > the patch. I'll mention it on openldap-technical if I can't get >> > assistance on #ldap. >> >> Not quite clear what patch and what failure you refer to. Anyway, I've >> tested this version of the overlay as global (refuses to start) and on a >> database, either empty or populated, and it works as intended. Please >> test and report. Thanks, p. > > It seems to be working well. When can I expect it to be in the tree? > > (I'll then require folks to use the current OpenLDAP CVS if they want to > use the LDAP backend). I can commit it in a minute. It's not 100% clear to me what's the most appropriate location: slapd/overlays/ may not, as this looks like something definitely specific to Samba4; probably, contrib/slapd-modules/ is more appropriate. Perhaps, a contrib/slapd-modules/samba4/ would be the most appropriate, along with future specific (i.e. not of general usefulness) modules, as we did for the nssov module. Comments? I mean, from others, not only from you :) p.

1 0

Re: ITS#6055
by abartlet＠samba.org 21 Apr '10

21 Apr '10

--=-u2bdcYXWzM+LH/qgpb9q Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2010-04-20 at 15:37 +0200, masarati(a)aero.polimi.it wrote: > > That's no problem at all. >=20 > Good. This version explicitly check for instantiation as global, and als= o > does some further sanity checks prior to startup. >=20 > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-20-rdnval.2.= c> >=20 > > It now just fails in the same was as without > > the patch. I'll mention it on openldap-technical if I can't get > > assistance on #ldap. >=20 > Not quite clear what patch and what failure you refer to. Anyway, I've > tested this version of the overlay as global (refuses to start) and on a > database, either empty or populated, and it works as intended. Please > test and report. Thanks, p. It seems to be working well. When can I expect it to be in the tree? (I'll then require folks to use the current OpenLDAP CVS if they want to use the LDAP backend). Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. --=-u2bdcYXWzM+LH/qgpb9q Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iD8DBQBLzldRz4A8Wyi0NrsRAgzTAJ4lv6P1wia2JLA7L2jPNkpgEvX3FwCgqyY0 jrguLg5MsW14D6wPlNThuko= =F1ZZ -----END PGP SIGNATURE----- --=-u2bdcYXWzM+LH/qgpb9q--

1 0

Re: (ITS#6165) Support offline modify (slapmodify) for cn=config
by quanah＠zimbra.com 21 Apr '10

21 Apr '10

--On Tuesday, April 20, 2010 4:03 AM +0000 masarati(a)aero.polimi.it wrote: > >> Very cute, but it fails the second portion of the requirement, which is >> command validation. ;) > > Here's a poor man's implementation. It *should* work for add & modify; > don't quite know how to delete entries; this also implies renaming. > probably, this would need be_tool_rename & be_tool_delete hooks. Cannot > compete in efficiency with slapadd; uses newly added ldifutil stuff > (ITS#6194). Please test. Cool, thanks! I'll give it a spin :) I believe delete support was added to back-ldif in HEAD, but I'm not sure how it works either. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: ITS#6055
by masarati＠aero.polimi.it 20 Apr '10

20 Apr '10

> That's no problem at all. Good. This version explicitly check for instantiation as global, and also does some further sanity checks prior to startup. <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-20-rdnval.2.c> > It now just fails in the same was as without > the patch. I'll mention it on openldap-technical if I can't get > assistance on #ldap. Not quite clear what patch and what failure you refer to. Anyway, I've tested this version of the overlay as global (refuses to start) and on a database, either empty or populated, and it works as intended. Please test and report. Thanks, p.

1 0

Re: ITS#6055
by abartlet＠samba.org 20 Apr '10

20 Apr '10

--=-8VSfpSadYnNS78ACEBD7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2010-04-20 at 07:11 +0200, masarati(a)aero.polimi.it wrote: > > On Mon, 2010-04-19 at 02:15 +0200, masarati(a)aero.polimi.it wrote: > >> Refactored rdnval.c available at > >> > >> <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-18-rdnval= .c> > >> > >> attempts to repair the database at startup; useful when the overlay is > >> configured for an existing database. Please test. > > > > Sadly it segfaults on startup (we don't have the DB at startup - we > > expect the first operations to create them). >=20 > It's not that sad: this overlay is not intended to be used as global. Yo= u > should use it within any database you want the rdnvalue stored. I haven'= t > considered yet how hard it would be to allow it to be global, and if it's > worth. Since it needs to write operational attributes to the directory, > it may run into issues in case non-local storage databases are used, and > it'd definitely risk to suffer from authentication issues. Does it make > sense for you to add an instance in each database you need rndvalue for? That's no problem at all. It now just fails in the same was as without the patch. I'll mention it on openldap-technical if I can't get assistance on #ldap. Then, when I get past that, I'll get back to this! Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. --=-8VSfpSadYnNS78ACEBD7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iD8DBQBLzU0sz4A8Wyi0NrsRAu1jAKCZMe8/cj55Qm+nFk1lZ0nRDnvQWACfXKCh jbVrJNvjzyeb5W6fOR49u58= =UMuS -----END PGP SIGNATURE----- --=-8VSfpSadYnNS78ACEBD7--

1 0

Re: ITS#6055
by masarati＠aero.polimi.it 20 Apr '10

20 Apr '10

> On Mon, 2010-04-19 at 02:15 +0200, masarati(a)aero.polimi.it wrote: >> Refactored rdnval.c available at >> >> <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-18-rdnval.c> >> >> attempts to repair the database at startup; useful when the overlay is >> configured for an existing database. Please test. > > Sadly it segfaults on startup (we don't have the DB at startup - we > expect the first operations to create them). It's not that sad: this overlay is not intended to be used as global. You should use it within any database you want the rdnvalue stored. I haven't considered yet how hard it would be to allow it to be global, and if it's worth. Since it needs to write operational attributes to the directory, it may run into issues in case non-local storage databases are used, and it'd definitely risk to suffer from authentication issues. Does it make sense for you to add an instance in each database you need rndvalue for? p. > I produced the environment with Samba4 from master > (538a07a80aae72b57e5c23133158c7f214d0c27a) with the attached additional > patch > > TEST_LDAP=yes OPENLDAP_SLAPD=/usr/local/libexec/slapd make quicktest > > This ran: > '/usr/local/libexec/slapd' > '-F/scratch/samba-2/source4/st/dc/private/ldap/slapd.d' '-h' 'ldapi://% > 2Fscratch%2Fsamba-2%2Fsource4%2Fst%2Fdc%2Fprivate%2Fldap%2Fldapi' '-d0' > > and running that under gdb produced > > Program received signal SIGSEGV, Segmentation fault. > 0x000000000057ba54 in rdnval_repair (be=0x7fffffffdbe0) at rdnval.c:466 > 466 op->o_req_dn = op->o_bd->be_suffix[ 0 ]; > Missing separate debuginfos, use: debuginfo-install > glibc-2.11.90-17.x86_64 libgcc-4.4.3-12.fc13.x86_64 > libicu-4.2.1-7.fc12.x86_64 libicu-4.2.1-8.fc13.x86_64 libstdc > ++-4.4.3-12.fc13.x86_64 libtool-ltdl-2.2.6-18.fc12.x86_64 > libtool-ltdl-2.2.6-18.fc13.x86_64 libuuid-2.17.2-1.fc13.x86_64 > mysql-libs-5.1.45-2.fc13.x86_64 postgresql-libs-8.4.3-1.fc13.x86_64 > (gdb) p op > $1 = (Operation *) 0x7fffffffd4d0 > (gdb) p op->o_bd > $2 = (BackendDB *) 0x0 > (gdb) p *op > $3 = {o_hdr = 0x7fffffffd640, o_tag = 99, o_time = 1271737105, o_tincr = > 1, o_bd = 0x0, o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = > {bv_len = 0, bv_val = 0x0}, o_request = {oq_add = {rs_modlist = 0x0, > rs_e = 0x0}, oq_bind = { > rb_method = 0, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = > {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 0, bv_val = > 0x0}}, oq_compare = {rs_ava = 0x0}, oq_modify = {rs_mods = {rs_modlist = > 0x0, > rs_no_opattrs = 0 '\000'}, rs_increment = 0}, oq_modrdn = > {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\000'}, rs_deleteoldrdn > = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, > bv_val = 0x0}, > rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = {rs_scope = 0, > rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly > = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val > = 0x0}}, > oq_abandon = {rs_msgid = 0}, oq_cancel = {rs_msgid = 0}, oq_extended > = {rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = > 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 0, bv_val = > 0x0}, rs_flags = 0, > rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = > {bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon > = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', > o_is_auth_check = 0 '\000', > o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 > '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 0 '\000', > o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 31 > times>, > o_controls = 0x7fffffffd788, o_authz = {sai_method = 0, sai_mech = > {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn > = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, > sai_tls_ssf = 0, > sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x0, > o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, > o_extra = {slh_first = 0x0}, o_next = {stqe_next = 0x0}} > (gdb) > > > -- > Andrew Bartlett http://samba.org/~abartlet/ > Authentication Developer, Samba Team http://samba.org > Samba Developer, Cisco Inc. > >

1 0

Re: ITS#6055
by abartlet＠samba.org 20 Apr '10

20 Apr '10

--=-JaZE3OeFLXsBmyVf+gjk Content-Type: multipart/mixed; boundary="=-5geAzHYesMuCPweb8j5I" --=-5geAzHYesMuCPweb8j5I Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2010-04-19 at 02:15 +0200, masarati(a)aero.polimi.it wrote: > Refactored rdnval.c available at >=20 > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-18-rdnval.c> >=20 > attempts to repair the database at startup; useful when the overlay is > configured for an existing database. Please test. Sadly it segfaults on startup (we don't have the DB at startup - we expect the first operations to create them).=20 I produced the environment with Samba4 from master (538a07a80aae72b57e5c23133158c7f214d0c27a) with the attached additional patch TEST_LDAP=3Dyes OPENLDAP_SLAPD=3D/usr/local/libexec/slapd make quicktest This ran:=20 '/usr/local/libexec/slapd' '-F/scratch/samba-2/source4/st/dc/private/ldap/slapd.d' '-h' 'ldapi://% 2Fscratch%2Fsamba-2%2Fsource4%2Fst%2Fdc%2Fprivate%2Fldap%2Fldapi' '-d0' and running that under gdb produced Program received signal SIGSEGV, Segmentation fault. 0x000000000057ba54 in rdnval_repair (be=3D0x7fffffffdbe0) at rdnval.c:466 466 op->o_req_dn =3D op->o_bd->be_suffix[ 0 ]; Missing separate debuginfos, use: debuginfo-install glibc-2.11.90-17.x86_64 libgcc-4.4.3-12.fc13.x86_64 libicu-4.2.1-7.fc12.x86_64 libicu-4.2.1-8.fc13.x86_64 libstdc ++-4.4.3-12.fc13.x86_64 libtool-ltdl-2.2.6-18.fc12.x86_64 libtool-ltdl-2.2.6-18.fc13.x86_64 libuuid-2.17.2-1.fc13.x86_64 mysql-libs-5.1.45-2.fc13.x86_64 postgresql-libs-8.4.3-1.fc13.x86_64 (gdb) p op $1 =3D (Operation *) 0x7fffffffd4d0 (gdb) p op->o_bd $2 =3D (BackendDB *) 0x0 (gdb) p *op $3 =3D {o_hdr =3D 0x7fffffffd640, o_tag =3D 99, o_time =3D 1271737105, o_ti= ncr =3D 1, o_bd =3D 0x0, o_req_dn =3D {bv_len =3D 0, bv_val =3D 0x0}, o_req_ndn =3D {bv_len =3D 0, bv_val =3D 0x0}, o_request =3D {oq_add =3D {rs_modlist =3D 0= x0, rs_e =3D 0x0}, oq_bind =3D { rb_method =3D 0, rb_cred =3D {bv_len =3D 0, bv_val =3D 0x0}, rb_edn = =3D {bv_len =3D 0, bv_val =3D 0x0}, rb_ssf =3D 0, rb_mech =3D {bv_len =3D 0, bv= _val =3D 0x0}}, oq_compare =3D {rs_ava =3D 0x0}, oq_modify =3D {rs_mods =3D {rs_modl= ist =3D 0x0,=20 rs_no_opattrs =3D 0 '\000'}, rs_increment =3D 0}, oq_modrdn =3D {rs_mods =3D {rs_modlist =3D 0x0, rs_no_opattrs =3D 0 '\000'}, rs_deleteold= rdn =3D 0, rs_newrdn =3D {bv_len =3D 0, bv_val =3D 0x0}, rs_nnewrdn =3D {bv_len= =3D 0, bv_val =3D 0x0},=20 rs_newSup =3D 0x0, rs_nnewSup =3D 0x0}, oq_search =3D {rs_scope =3D 0= , rs_deref =3D 0, rs_slimit =3D 0, rs_tlimit =3D 0, rs_limit =3D 0x0, rs_attr= sonly =3D 0, rs_attrs =3D 0x0, rs_filter =3D 0x0, rs_filterstr =3D {bv_len =3D 0,= bv_val =3D 0x0}},=20 oq_abandon =3D {rs_msgid =3D 0}, oq_cancel =3D {rs_msgid =3D 0}, oq_ext= ended =3D {rs_reqoid =3D {bv_len =3D 0, bv_val =3D 0x0}, rs_flags =3D 0, rs_reqda= ta =3D 0x0}, oq_pwdexop =3D {rs_extended =3D {rs_reqoid =3D {bv_len =3D 0, bv_val = =3D 0x0}, rs_flags =3D 0,=20 rs_reqdata =3D 0x0}, rs_old =3D {bv_len =3D 0, bv_val =3D 0x0}, rs_= new =3D {bv_len =3D 0, bv_val =3D 0x0}, rs_mods =3D 0x0, rs_modtail =3D 0x0}}, o_ab= andon =3D 0, o_cancel =3D 0, o_groups =3D 0x0, o_do_not_cache =3D 0 '\000', o_is_auth_check =3D 0 '\000',=20 o_dont_replicate =3D 0 '\000', o_acl_priv =3D ACL_NONE, o_nocaching =3D 0 '\000', o_delete_glue_parent =3D 0 '\000', o_no_schema_check =3D 0 '\000', o_no_subordinate_glue =3D 0 '\000', o_ctrlflag =3D '\000' <repeats 31 times>,=20 o_controls =3D 0x7fffffffd788, o_authz =3D {sai_method =3D 0, sai_mech = =3D {bv_len =3D 0, bv_val =3D 0x0}, sai_dn =3D {bv_len =3D 0, bv_val =3D 0x0}, = sai_ndn =3D {bv_len =3D 0, bv_val =3D 0x0}, sai_ssf =3D 0, sai_transport_ssf =3D 0, sai_tls_ssf =3D 0,=20 sai_sasl_ssf =3D 0}, o_ber =3D 0x0, o_res_ber =3D 0x0, o_callback =3D 0= x0, o_ctrls =3D 0x0, o_csn =3D {bv_len =3D 0, bv_val =3D 0x0}, o_private =3D 0x= 0, o_extra =3D {slh_first =3D 0x0}, o_next =3D {stqe_next =3D 0x0}} (gdb)=20 --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. --=-5geAzHYesMuCPweb8j5I Content-Disposition: attachment; filename="add-rdnval.patch" Content-Transfer-Encoding: base64 Content-Type: text/x-patch; name="add-rdnval.patch"; charset="UTF-8" ZGlmZiAtLWdpdCBhL3NvdXJjZTQvc2V0dXAvc2xhcGQuY29uZiBiL3NvdXJjZTQvc2V0dXAvc2xh cGQuY29uZg0KaW5kZXggMDA3N2EyMi4uZTVmY2QwNiAxMDA2NDQNCi0tLSBhL3NvdXJjZTQvc2V0 dXAvc2xhcGQuY29uZg0KKysrIGIvc291cmNlNC9zZXR1cC9zbGFwZC5jb25mDQpAQCAtNDksNiAr NDksNyBAQCBkZWZhdWx0c2VhcmNoYmFzZSAke0RPTUFJTkROfQ0KIHJvb3RkbiBjbj1NYW5hZ2Vy DQogDQogb3ZlcmxheSBkZXJlZg0KK292ZXJsYXkgcmRudmFsDQogDQogJHtSRUZJTlRfQ09ORklH fQ0KIA0K --=-5geAzHYesMuCPweb8j5I-- --=-JaZE3OeFLXsBmyVf+gjk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iD8DBQBLzS/Pz4A8Wyi0NrsRApX6AJ0cG3n8qHNNN8TgvyQDIQD9wWTkXQCfbGgW rlvjjg0JC8ufGPwfp5709c8= =LCEs -----END PGP SIGNATURE----- --=-JaZE3OeFLXsBmyVf+gjk--

1 0

Re: (ITS#6165) Support offline modify (slapmodify) for cn=config
by masarati＠aero.polimi.it 20 Apr '10

20 Apr '10

> Very cute, but it fails the second portion of the requirement, which is > command validation. ;) Here's a poor man's implementation. It *should* work for add & modify; don't quite know how to delete entries; this also implies renaming. probably, this would need be_tool_rename & be_tool_delete hooks. Cannot compete in efficiency with slapadd; uses newly added ldifutil stuff (ITS#6194). Please test. p.

1 0

Re: (ITS#6165) Support offline modify (slapmodify) for cn=config
by quanah＠zimbra.com 20 Apr '10

20 Apr '10

--On Sunday, April 18, 2010 10:17 PM +0200 masarati(a)aero.polimi.it wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.16 >> OS: NA >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.29.239) >> >> >> The slapmodify function already exists, but we've never built a tool >> around it. >> It would be useful to be able to have a utility that validates commands >> that >> users can use to modify cn=config while slapd is offline, rather than >> resorting >> to text editors that don't do validation of the changes being made. > > What about this? > > <ftp://ftp.openldap.org/incoming/slapmodify> Very cute, but it fails the second portion of the requirement, which is command validation. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

ITS#5804
by masarati＠aero.polimi.it 20 Apr '10

20 Apr '10

The syntax added by ITS#5804 has never been documented. A patch to slapd.access(5) is about to be committed. p.

1 0

Re: (ITS#6482) slapcat doesn't continue with -c after the first corrupted database entry
by sysadmin＠htl-leonding.ac.at 19 Apr '10

19 Apr '10

I had restarted the server many times and it still worked, so I don't think the data was cached. Maybe the different method of access caused the difference, because the non-corrupted entries were still accessible via their id, so direct access worked. Could it be that slapcat doesn't correctly handle the case of invalid entries (entries with decoding errors)? Before this generic patch, I checked if the current entry had the id of the first invalid entry and in this case I incremented the ID by three, got the resulting entry and continued the export --> slapcat "skipped" the entries which it couldn't decode and then continued processing normally. Sorry that I can't test catastrophic recovery any more, because I have deleted the corrupted database, but I think that the main problem was that slapcat (and also other ldap-tools) wasn't able to decode the few damaged entries and didn't try to work around that problem.

1 0

ITS#6055
by masarati＠aero.polimi.it 19 Apr '10

19 Apr '10

Refactored rdnval.c available at <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-18-rdnval.c> attempts to repair the database at startup; useful when the overlay is configured for an existing database. Please test. p.

1 0

Re: ITS#6017
by masarati＠aero.polimi.it 19 Apr '10

19 Apr '10

> > --=-Ga69RST1xu0P4I4ibWcD > Content-Type: text/plain; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > On Sun, 2010-04-18 at 22:59 +0200, masarati(a)aero.polimi.it wrote: >> Still needed? Would the entryUUID of the parent stored in a >> "parentUUID" >> attribute fit? > > While we may change our minds again, Samba4 currently does not require > parentUUID to be stored. We now calculate it dynamically at runtime.=20 OK, thanks. In any case, while refactoring the rdnval.c (ITS#6055), I also implemented this <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-18-pguid.c>. It keeps the parentUUID in sync, and repairs the database at startup (useful when the overlay is added on existing databases). p.

1 0

Re: ITS#6017
by abartlet＠samba.org 19 Apr '10

19 Apr '10

--=-Ga69RST1xu0P4I4ibWcD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 2010-04-18 at 22:59 +0200, masarati(a)aero.polimi.it wrote: > Still needed? Would the entryUUID of the parent stored in a "parentUUID" > attribute fit? While we may change our minds again, Samba4 currently does not require parentUUID to be stored. We now calculate it dynamically at runtime.=20 Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. --=-Ga69RST1xu0P4I4ibWcD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iD8DBQBLy49wz4A8Wyi0NrsRAgxwAJ96NWo95lkdiVV2WSpz9F/EdKaDfwCeO6Y3 +zF9u9EWpDvziGGAsOAyB8Q= =a/rb -----END PGP SIGNATURE----- --=-Ga69RST1xu0P4I4ibWcD--

1 0

ITS#6017
by masarati＠aero.polimi.it 18 Apr '10

18 Apr '10

Still needed? Would the entryUUID of the parent stored in a "parentUUID" attribute fit? p.

1 0

Re: (ITS#6165) Support offline modify (slapmodify) for cn=config
by masarati＠aero.polimi.it 18 Apr '10

18 Apr '10

> Full_Name: Quanah Gibson-Mount > Version: 2.4.16 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > The slapmodify function already exists, but we've never built a tool > around it. > It would be useful to be able to have a utility that validates commands > that > users can use to modify cn=config while slapd is offline, rather than > resorting > to text editors that don't do validation of the changes being made. What about this? <ftp://ftp.openldap.org/incoming/slapmodify> ;) p.

1 0

Re: (ITS#6482) slapcat doesn't continue with -c after the first corrupted database entry
by masarati＠aero.polimi.it 18 Apr '10

18 Apr '10

> The main point wasn't to tell you how important the data was, but that > tools like ldapsearch or other tools connecting to slapd using port 389 > still saw the good data. Because it was cached? Was this true after restarting the server? > And slapd never complained about a corrupted > database. As a result of that the data corruption was hidden (all other > programs worked, only three non-important entries were not accessible) > until I tried to use slapcat to export the data for an upgrade. > > Regarding "If the underlying database fails, there's little slapcat can > do.": As long as slapd sees the data, because it sends it in responses > to ldap-queries, the database hasn't failed so much, that slapcat > couldn't retrieve those data. Well, as I said in my previous message, slapcat is asking the underlying database to provide entries. If the underlying database fails, there's little slapcat can do. When the underlying database is back-bdb/hdb, slapd accesses data using indexes (dn/filter indexes mapped to IDs; the entry is then accessed using BDB in DB_SET mode), while slapcat accesses it using BDB cursors in DB_NEXT mode. Your approach of guessing IDs in the hope it works sounds a bit naive; I think in your case it worked by chance. Perhaps, a more "robust" approach would be to have back-bdb/hdb bi_tool_entry_next() to try to use itself the DB_SET approach instead of the DB_NEXT when the latter fails, with slapcat only knowing about the failure (so it can abort if -c is not passed). > Regarding "any garbage coming out of a corrupted database": slapd never > complained about the database being corrupted, it started without any > problems (except that three entries were unreadable), the entries after > those damaged entries made sense and weren't garbage. Berkeley's > db_tools claimed that there were some errors in the db, but slapd worked > without problems, only slapcat (and ldapdelete when trying to delete > those entries) complained that it couldn't decode them (which seems to > be rather a problem of the application layer than of the database layer, > but might have been caused by some little db corruption). When things go wrong, and specifically when this happens outside the code of our pertinence (in this case BDB), usually the best we can do is to rely on what any diagnostics/recovery capability they provide. Again, what worked for you may not work for another kind of corruption. Actually, going on might provide inconsistent data, something as bad as data loss. > I tried tools like "db_recover", but they didn't help, What about catastrophic recovery, using archived log files? > so I wanted to > extract the good ldap entries (using slapcat ...) to drop the database > and recreate it with the exported ldif, which failed because slapcat > stopped after the first failure (even with -c). Using the submitted > patch I was able to export all readable data into a ldif-file and to > recreate the database. > > summary: > * slapd never complained, ldapsearch listed the data, only few entries > were missing (because for them following was true: > > <= entry_decode: slap_str2undef_ad(object�..!p): > AttributeDescription > contains inappropriate characters) > > --> it seems that some attribute-values were damaged, but not the dn? > > * if ldapsearch is able to retrieve the data, slapcat should also do In general, I concur. However, slapd and tools access data in a slightly different manner, so this may not be trivial, and might require a redesign. > * I don't know how you want to recover an corrupted database. I tried to > recover all good entries and then to recreate it. And for that I wanted > to use slapcat (or is there any other tool for exporting data from the > ldap database than slapcat with option -c)? None I know about. > * maybe the way -c works shouldn't be changed, but there should be an > option for trying data recovery harder without having to patch openldap > (which is complicated for users of other distros not working directly > with the sources, but with precompiled packages) I'd take this as a feature request for redesigning the tools iteration procedure in order to try to overcome minor db corruptions. p.

1 0

Re: (ITS#6528) test020 with hdb: Query 15: ldapsearch failed (4)
by michael＠stroeder.com 18 Apr '10

18 Apr '10

Seems to work now with recent checkout. Ciao, Michael.

1 0

Re: (ITS#6225) GSSAPI support for client library (fixes)
by mimir＠samba.org 18 Apr '10

18 Apr '10

--LZvS9be/3tNcYl/X Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Howard, On Fri, Jul 24, 2009 at 09:20:46PM -0700, Howard Chu wrote: > mimir(a)samba.org wrote: > >Full_Name: Rafal Szczesniak > >Version: Stable (2.4.16) > >OS: GNU/Linux > >URL: http://www.samba.org/~mimir/gssapi-bugfix.diff > >Submission from: (NULL) (67.51.54.234) > > > > > >This is a bugfix patch for OpenLDAP's gssapi support. > > > One of these patches appears to duplicate ITS#6092. As the original > author of this code, could you also take a look at #6091 and #6093? I'm really sorry but after I looked at current code in HEAD and I thought I= liked it (the actual issue was fixed), following with this thread completely went of= f my radar. I've found it while looking through my mailbox. The last chunk of this its' patch still applies though. It's a minor thing = but fixes potential memory leak. I can open a separate ITS for it if you like. As for the other patches - #6091 is (was) convenient but not absolutely nec= essary and #6093 is interesting but I'm not sure if it isn's a bit too much. If yo= u're connecting invalid (from kerberos point of view) hostname then, well, find out what's = the correct=20 hostname first. This its # can be closed of course. cheers, --=20 Rafal Szczesniak Samba Team member http://www.samba.org Likewise Software http://www.likewise.com --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFLy1e3Hvdfyv3qiKkRAk7ZAJ0VPkzc89VAxXh/AF4EZVCJTvS/fgCfeZK7 TULoTjp8aXQkK0oGZNShxsY= =zucU -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X--

1 0

Re: (ITS#6482) slapcat doesn't continue with -c after the first corrupted database entry
by sysadmin＠htl-leonding.ac.at 18 Apr '10

18 Apr '10

This is a multi-part message in MIME format. --------------020204070007000004050507 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit The main point wasn't to tell you how important the data was, but that tools like ldapsearch or other tools connecting to slapd using port 389 still saw the good data. And slapd never complained about a corrupted database. As a result of that the data corruption was hidden (all other programs worked, only three non-important entries were not accessible) until I tried to use slapcat to export the data for an upgrade. Regarding "If the underlying database fails, there's little slapcat can do.": As long as slapd sees the data, because it sends it in responses to ldap-queries, the database hasn't failed so much, that slapcat couldn't retrieve those data. Regarding "any garbage coming out of a corrupted database": slapd never complained about the database being corrupted, it started without any problems (except that three entries were unreadable), the entries after those damaged entries made sense and weren't garbage. Berkeley's db_tools claimed that there were some errors in the db, but slapd worked without problems, only slapcat (and ldapdelete when trying to delete those entries) complained that it couldn't decode them (which seems to be rather a problem of the application layer than of the database layer, but might have been caused by some little db corruption). I tried tools like "db_recover", but they didn't help, so I wanted to extract the good ldap entries (using slapcat ...) to drop the database and recreate it with the exported ldif, which failed because slapcat stopped after the first failure (even with -c). Using the submitted patch I was able to export all readable data into a ldif-file and to recreate the database. summary: * slapd never complained, ldapsearch listed the data, only few entries were missing (because for them following was true: <= entry_decode: slap_str2undef_ad(object�..!p): AttributeDescription contains inappropriate characters) --> it seems that some attribute-values were damaged, but not the dn? * if ldapsearch is able to retrieve the data, slapcat should also do * I don't know how you want to recover an corrupted database. I tried to recover all good entries and then to recreate it. And for that I wanted to use slapcat (or is there any other tool for exporting data from the ldap database than slapcat with option -c)? * maybe the way -c works shouldn't be changed, but there should be an option for trying data recovery harder without having to patch openldap (which is complicated for users of other distros not working directly with the sources, but with precompiled packages) --------------020204070007000004050507 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-15"> </head> <body bgcolor="#ffffff" text="#000000"> The main point wasn't to tell you how important the data was, but that tools like ldapsearch or other tools connecting to slapd using port 389 still saw the good data. And slapd never complained about a corrupted database. As a result of that the data corruption was hidden (all other programs worked, only three non-important entries were not accessible) until I tried to use slapcat to export the data for an upgrade. Regarding "If the underlying database fails, there's little slapcat can do.": As long as slapd sees the data, because it sends it in responses to ldap-queries, the database hasn't failed so much, that slapcat couldn't retrieve those data. Regarding "any garbage coming out of a corrupted database": slapd never complained about the database being corrupted, it started without any problems (except that three entries were unreadable), the entries after those damaged entries made sense and weren't garbage. Berkeley's db_tools claimed that there were some errors in the db, but slapd worked without problems, only slapcat (and ldapdelete when trying to delete those entries) complained that it couldn't decode them (which seems to be rather a problem of the application layer than of the database layer, but might have been caused by some little db corruption). I tried tools like "db_recover", but they didn't help, so I wanted to extract the good ldap entries (using slapcat ...) to drop the database and recreate it with the exported ldif, which failed because slapcat stopped after the first failure (even with -c). Using the submitted patch I was able to export all readable data into a ldif-file and to recreate the database. summary: * slapd never complained, ldapsearch listed the data, only few entries were missing (because for them following was true: <pre><= entry_decode: slap_str2undef_ad(object&#65533;..!p): AttributeDescription contains inappropriate characters) --> it seems that some attribute-values were damaged, but not the dn? </pre> * if ldapsearch is able to retrieve the data, slapcat should also do * I don't know how you want to recover an corrupted database. I tried to recover all good entries and then to recreate it. And for that I wanted to use slapcat (or is there any other tool for exporting data from the ldap database than slapcat with option -c)? * maybe the way -c works shouldn't be changed, but there should be an option for trying data recovery harder without having to patch openldap (which is complicated for users of other distros not working directly with the sources, but with precompiled packages) </body> </html> --------------020204070007000004050507--

1 0

Re: (ITS#6482) slapcat doesn't continue with -c after the first corrupted database entry
by masarati＠aero.polimi.it 18 Apr '10

18 Apr '10

> Maybe I haven't described the situation correctly: > The database was used for managing user accounts (via nss_ldap). The > database seems to had three corrupted entries in the middle (good > entries were following after that). The command "getent passwd" i.e. > still listed all users except those three with corrupted entries, but > export via slapcat and reimport of the data would have led to loss of > many more accounts. Lossing half your data is not the expected behaviour > for a tool, which should list all the existing (or at least somehow > readable) database entries. I'm not questioning the importance of the data slapcat couldn't export. > The important point is that slapcat cancelled the export at the first > corrupted database entry and didn't even try to get to the non-corrupted > database entries (which were seen by the other LDAP-tools). This is not correct. Slapcat tries. It asks the underlying backend to provide the subsequent entries. If the underlying database fails, there's little slapcat can do. > It didn't > even try in "continuation" mode, so there was no way to rescue all the > readable data via slapcat. I've tested slapcat in continuation mode by forcibly having be_entry_get() return NULL, and it works as expected: it continues to the next one, as soon as be_entry_next() is able to return a valid ID. if it can't, then anything you'd get from be_entry_next() with an arbitrary ID is unreliable. > For slapcat all entries occuring after the > first corrupt entry were lost. As the remaining good entries were still > accessible and visible via the other tools communicating with slapd via > the port 389, the expected behaviour for slapcat would have been to try > harder to ignore the damaged entries and to recover the remaining > readable entries after them. Maybe slapcat really failed to extract the > next entries id, but in "continuation"-mode it should try hard to > workaround any errors caused by non-readable entries. In case of an > non-readable entry my patch continues stupidly incrementing the id by 1 > and trying to read that entry. As soon as it can extract an entry, it > continues processing. If by "try hard" you mean that any garbage coming out of a corrupted database would be fine for you, then you can fix your patch by having it stop when id == NOID. To me, it sounds a bit too hard. What about recovering the database first, did you try? p.

1 0

Re: (ITS#6528) test020 with hdb: Query 15: ldapsearch failed (4)
by masarati＠aero.polimi.it 18 Apr '10

18 Apr '10

Thanks, I'm working at this. p. > Full_Name: Michael Ströder > Version: HEAD > OS: > URL: > Submission from: (NULL) (84.163.121.239) > > > Note: It seems to work with back-bdb > > $ ./run -b hdb test020 > Cleaning up test run directory leftover from previous run. > Running ./scripts/test020-proxycache for hdb... > Starting master slapd on TCP/IP port 9011... > Using ldapsearch to check that master slapd is running... > Using ldapadd to populate the master directory... > Starting proxy cache on TCP/IP port 9012... > Using ldapsearch to check that proxy slapd is running... > Making queries on the proxy cache... > Query 1: filter:(sn=Jon) attrs:all (expect nothing) > Query 2: filter:(|(cn=*Jon*)(sn=Jon*)) attrs:cn sn title uid > Query 3: filter:(sn=Smith*) attrs:cn sn uid > Query 4: filter:(sn=Doe*) attrs:cn sn title uid > Query 5: filter:(uid=johnd) attrs:mail postaladdress telephonenumber cn > uid > Query 6: filter:(mail=*@mail.alumni.example.com) attrs:cn sn title uid > Query 7: filter:(mail=*) attrs:cn sn title uid > Query 8: filter:(mail=*example.com) attrs:cn sn title uid > ldapsearch failed (4) > Query 9: filter:(uid=b*) attrs:mail > ldapsearch failed (4) > Query 1 not cacheable > Query 2 cacheable > Query 3 cacheable > Query 4 cacheable > Query 5 cacheable > Query 6 cacheable > Query 7 not cacheable > Query 8 cacheable > Query 9 cacheable > Successfully verified cacheability > Query 10: filter:(|(cn=*Jones)(sn=Jones)) attrs:cn sn title uid > Query 11: filter:(sn=Smith) attrs:cn sn title uid > Query 12: filter:(uid=bjorn) attrs:mail postaladdress telephonenumber cn > uid > Query 13: filter:(mail=jaj@mail.alumni.example.com) attrs:cn sn title uid > Query 14: filter:(mail=*example.com) attrs:cn sn title uid > ldapsearch failed (4) > Query 15: filter:(uid=b*) attrs:mail > ldapsearch failed (4) > Query 10 answerable > Query 11 answerable > Query 12 answerable > Query 13 not answerable > Query 14 not answerable > Query 15 answerable > Successfully verified answerability > Filtering ldapsearch results... > Filtering original ldif... > Comparing filter output... > Comparison failed > > >

1 0

Re: (ITS#6527) Build errors in function � slap_cf_aux_table_unparse�
by masarati＠aero.polimi.it 18 Apr '10

18 Apr '10

Thanks, Quanah is working at this. p. > Full_Name: Michael Ströder > Version: RE24 > OS: openSUSE 11.2 Linux > URL: > Submission from: (NULL) (84.163.121.239) > > > HEAD builds and make test works. > > RE24 fails to build since recent check-ins (anon CVS) yesterday: > > make[3]: Leaving directory > `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers/slapd/overlays' > ../../build/mkversion -v "2.4.X" -s -n Versionstr slapd > version.c > cc -g -O2 -DSLAP_SCHEMA_EXPOSE -I../../include -I. -I./slapi -I. > -I../../include > -c -o main.o main.c > cc -g -O2 -DSLAP_SCHEMA_EXPOSE -I../../include -I. -I./slapi -I. > -I../../include > -c -o globals.o globals.c > cc -g -O2 -DSLAP_SCHEMA_EXPOSE -I../../include -I. -I./slapi -I. > -I../../include > -c -o bconfig.o bconfig.c > cc -g -O2 -DSLAP_SCHEMA_EXPOSE -I../../include -I. -I./slapi -I. > -I../../include > -c -o config.o config.c > config.c: In function �slap_cf_aux_table_unparse�: > config.c:1575: error: duplicate case value > config.c:1547: error: previously used here > make[2]: *** [config.o] Error 1 > make[2]: Leaving directory > `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers/slapd' > make[1]: *** [all-common] Error 1 > make[1]: Leaving directory > `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers' > make: *** [all-common] Error 1 > > >

1 0

(ITS#6528) test020 with hdb: Query 15: ldapsearch failed (4)
by michael＠stroeder.com 18 Apr '10

18 Apr '10

Full_Name: Michael Ströder Version: HEAD OS: URL: Submission from: (NULL) (84.163.121.239) Note: It seems to work with back-bdb $ ./run -b hdb test020 Cleaning up test run directory leftover from previous run. Running ./scripts/test020-proxycache for hdb... Starting master slapd on TCP/IP port 9011... Using ldapsearch to check that master slapd is running... Using ldapadd to populate the master directory... Starting proxy cache on TCP/IP port 9012... Using ldapsearch to check that proxy slapd is running... Making queries on the proxy cache... Query 1: filter:(sn=Jon) attrs:all (expect nothing) Query 2: filter:(|(cn=*Jon*)(sn=Jon*)) attrs:cn sn title uid Query 3: filter:(sn=Smith*) attrs:cn sn uid Query 4: filter:(sn=Doe*) attrs:cn sn title uid Query 5: filter:(uid=johnd) attrs:mail postaladdress telephonenumber cn uid Query 6: filter:(mail=*@mail.alumni.example.com) attrs:cn sn title uid Query 7: filter:(mail=*) attrs:cn sn title uid Query 8: filter:(mail=*example.com) attrs:cn sn title uid ldapsearch failed (4) Query 9: filter:(uid=b*) attrs:mail ldapsearch failed (4) Query 1 not cacheable Query 2 cacheable Query 3 cacheable Query 4 cacheable Query 5 cacheable Query 6 cacheable Query 7 not cacheable Query 8 cacheable Query 9 cacheable Successfully verified cacheability Query 10: filter:(|(cn=*Jones)(sn=Jones)) attrs:cn sn title uid Query 11: filter:(sn=Smith) attrs:cn sn title uid Query 12: filter:(uid=bjorn) attrs:mail postaladdress telephonenumber cn uid Query 13: filter:(mail=jaj@mail.alumni.example.com) attrs:cn sn title uid Query 14: filter:(mail=*example.com) attrs:cn sn title uid ldapsearch failed (4) Query 15: filter:(uid=b*) attrs:mail ldapsearch failed (4) Query 10 answerable Query 11 answerable Query 12 answerable Query 13 not answerable Query 14 not answerable Query 15 answerable Successfully verified answerability Filtering ldapsearch results... Filtering original ldif... Comparing filter output... Comparison failed

1 0

Re: (ITS#6482) slapcat doesn't continue with -c after the first corrupted database entry
by sysadmin＠htl-leonding.ac.at 18 Apr '10

18 Apr '10

Maybe I haven't described the situation correctly: The database was used for managing user accounts (via nss_ldap). The database seems to had three corrupted entries in the middle (good entries were following after that). The command "getent passwd" i.e. still listed all users except those three with corrupted entries, but export via slapcat and reimport of the data would have led to loss of many more accounts. Lossing half your data is not the expected behaviour for a tool, which should list all the existing (or at least somehow readable) database entries. The important point is that slapcat cancelled the export at the first corrupted database entry and didn't even try to get to the non-corrupted database entries (which were seen by the other LDAP-tools). It didn't even try in "continuation" mode, so there was no way to rescue all the readable data via slapcat. For slapcat all entries occuring after the first corrupt entry were lost. As the remaining good entries were still accessible and visible via the other tools communicating with slapd via the port 389, the expected behaviour for slapcat would have been to try harder to ignore the damaged entries and to recover the remaining readable entries after them. Maybe slapcat really failed to extract the next entries id, but in "continuation"-mode it should try hard to workaround any errors caused by non-readable entries. In case of an non-readable entry my patch continues stupidly incrementing the id by 1 and trying to read that entry. As soon as it can extract an entry, it continues processing.

1 0

(ITS#6527) Build errors in function �slap_cf_aux_table_unparse�
by michael＠stroeder.com 18 Apr '10

18 Apr '10

Full_Name: Michael Ströder Version: RE24 OS: openSUSE 11.2 Linux URL: Submission from: (NULL) (84.163.121.239) HEAD builds and make test works. RE24 fails to build since recent check-ins (anon CVS) yesterday: make[3]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers/slapd/overlays' ../../build/mkversion -v "2.4.X" -s -n Versionstr slapd > version.c cc -g -O2 -DSLAP_SCHEMA_EXPOSE -I../../include -I. -I./slapi -I. -I../../include -c -o main.o main.c cc -g -O2 -DSLAP_SCHEMA_EXPOSE -I../../include -I. -I./slapi -I. -I../../include -c -o globals.o globals.c cc -g -O2 -DSLAP_SCHEMA_EXPOSE -I../../include -I. -I./slapi -I. -I../../include -c -o bconfig.o bconfig.c cc -g -O2 -DSLAP_SCHEMA_EXPOSE -I../../include -I. -I./slapi -I. -I../../include -c -o config.o config.c config.c: In function slap_cf_aux_table_unparse: config.c:1575: error: duplicate case value config.c:1547: error: previously used here make[2]: *** [config.o] Error 1 make[2]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers' make: *** [all-common] Error 1

1 0

Re: (ITS#6458) syncrepl fails if attribute has no equalty maching rule
by masarati＠aero.polimi.it 18 Apr '10

18 Apr '10

Should now be fixed in HEAD; please test. Thanks, p.

1 0

Re: (ITS#6458) syncrepl fails if attribute has no equalty maching rule
by masarati＠aero.polimi.it 18 Apr '10

18 Apr '10

> I see the issue, and I've isolated it to the case where you're removing a > value. In that case, in attr_cmp(), nn == 0 and no < o; the original test > for modifying an attribute without matching rule fails. I've fixed it > according to this patch, not sure whether it's appropriate for other cases > > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-17-syncrepl-no-…> > > Please test and review. Thanks, p. Please disregard, this patch is breaking other things (basically, producer's and consumer's entries are equivalent, but attrs are listed in a different order; this conforms to the LDAP model but breaks the original, preferable behavior). Working at a better fix. p.

1 0

Re: (ITS#6458) syncrepl fails if attribute has no equalty maching rule
by masarati＠aero.polimi.it 18 Apr '10

18 Apr '10

> Full_Name: Patrick Cernko > Version: 2.4.21 > OS: Linux > URL: > http://www.mpi-inf.mpg.de/~pcernko/syncrepl_fails_if_attribute_has_no_equal… > Submission from: (NULL) (139.19.3.67) > > > Hi OpenLDAP-Programmers, > > although some related bug reports were posted in the past years, this > issue > still seems not to be fixed: > > OpenLDAP's syncrepl replication fails if it comes to removing one of a > multi-value attribes of an object if this attribute does not have a > equality > matching rule defined in the schema. Modification works on the master > server but > fails to replicate to the slave(s) leaving them with the dit version just > before > and not replicating any other changes any more. > > I compiled a small example how to reproduce the problem with the (maybe > "well-known") nisNetgroupTriple attribute from nis.schema as shipped with > openldap-2.4.21: > > - extract the files from > http://www.mpi-inf.mpg.de/~pcernko/syncrepl_fails_if_attribute_has_no_equal… > into an empty working directory > - download the tarball to that working dir and configure similar to the > just > extracted configure.sh > - build and install it to get an install subdir in the working dir > - start the master using sh master.sh in the working dir > This will create the "master" database in your working dir, slapadd the > dit.ldif and start a master slapd with a unix socket /tmp/master. > - start the slave using sh slave.sh > This will create "slave" database in your working dir and start the > slave > slapd with a unix socket /tmp/slave which will immediately start syncing > from > the running master > - if you want you can search the 2 servers with > install/bin/ldapsearch -H ldapi://%2ftmp%2fmaster/ -b ou=openldap -LLL > resp. > install/bin/ldapsearch -H ldapi://%2ftmp%2fslave/ -b ou=openldap -LLL > - use "python mod.py" to remove one of the nisNetgroupTriple attributes > from the > netgroup object > - you will see a debug message from the slave server like this: > > bdb_modify_internal: delete nisNetgroupTriple > bdb_modify_internal: 18 modify/delete: nisNetgroupTriple: no equality > matching > rule > send_ldap_result: err=18 matched="" text="modify/delete: > nisNetgroupTriple: no > equality matching rule" > null_callback : error code 0x12 > slap_graduate_commit_csn: removing 0x29931c0 > 20100120124712.028626Z#000000#000#000000 > syncrepl_entry: rid=001 be_modify cn=netgroup,ou=openldap (18) > syncrepl_entry: rid=001 be_modify failed (18) > > if not, use "python mod.py add" to re-add the removed nisNetgroupTriple > and > try again. Sometimes, it seems to work (race condition?). > - you can also verify the difference with: > install/bin/ldapsearch -H ldapi://%2ftmp%2fmaster/ -b ou=openldap -LLL > cn=netgroup > install/bin/ldapsearch -H ldapi://%2ftmp%2fslave/ -b ou=openldap -LLL > cn=netgroup > - from now on, the slave will fail to sync any succeeding changes, as it > continuously tries to sync the modification above first. :-( > > Now, obviously having an attribute without equality matching rule is not a > good > idea in the first place. However, the (official?) nis.schema comes with > such an > attribute which we must use like this (e.g. we would have to patch the > Solaris > kernel to change it for the Solaris NFS server). > > It is possible to modify a nisNetgroup object like this: according to the > debugging output, I guess the master removes simply ALL nisNetgroupTriple > attributes and adds only the attributes that should remain. When the > corresponding syncrepl_entry is handled by the slave, it seems the it in > contrast tries to really only remove the 2-be-removed attribute which does > not > work as it cannot identify the right one due to a missing eq-match > operator. > > I suggest the best way to solve this issue is to try to get syncrepl do > exactly > the same actions (not resulting changes) as the server does. I see the issue, and I've isolated it to the case where you're removing a value. In that case, in attr_cmp(), nn == 0 and no < o; the original test for modifying an attribute without matching rule fails. I've fixed it according to this patch, not sure whether it's appropriate for other cases <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-17-syncrepl-no-…> Please test and review. Thanks, p.

1 0

Re: (ITS#6463) dnssrv_back_referrals: ldaps not handled, search base gone
by masarati＠aero.polimi.it 18 Apr '10

18 Apr '10

> Full_Name: Jochen Keutel > Version: 2.4.21 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (87.159.206.14) > > > dnssrv_back_referrals() always returns ldap URLs - even when the original > request was a ldaps query. This is a (logical) duplicate of ITS#6462; see related answers. > Additionally only protocol and hostname are put into the URL - the search > base > doesn't appear any more. > > Problematic code: > > url.bv_len = STRLENOF( "ldap://" ) + strlen( hosts[i] ); > url.bv_val = ch_malloc( url.bv_len + 1 ); > > strcpy( url.bv_val, "ldap://" ); > strcpy( &url.bv_val[STRLENOF( "ldap://" )], hosts[i] ); > > I'm not sure whether you want me to deliver a complete patch or not ... This behavior conforms to RFC4511, section 4.1.10: - If the <dn> part is present, the client uses this name in its next request to progress the operation, and if it is not present the client uses the same name as in the original request. I note that few lines above the same RFC states: - It is RECOMMENDED that the <dn> part be present to avoid ambiguity. However, slapd-dnssrv(5) computes the referral from DNS SRV records, rather than returning data it knows about. So returning the <dn> part here would be incorrect, in my opinion, as the client could legitimately rely on the fact that the returned DN is appropriate, while it may not. p.

1 0

Re: (ITS#6462) DNS SRV records: ldaps ???
by masarati＠aero.polimi.it 18 Apr '10

18 Apr '10

> --On Wednesday, January 27, 2010 1:28 AM +0000 jochen(a)keutel.de wrote: > >> Full_Name: Jochen Keutel >> Version: 2.4.21 >> OS: Solaris 10 >> URL: ftp://ftp.openldap.org/incoming/ > >> protocol is either "ldap" oder "ldaps". > > LDAPS is not a defined protocol. I would suggest using LDAP with > startTLS, > which is RFC Defined. One could argue that OpenLDAP supports ldaps in many places. I agree in general with your reply, but I'd treat this ITS as a feature request, although I'm not going to give it any special priority. p.

1 0

Re: (ITS#6491) LDAP Error code 80 - Dn index delete failed
by masarati＠aero.polimi.it 18 Apr '10

18 Apr '10

> Full_Name: Robert Hanson > Version: 2.4.21 > OS: RedHat 4.7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.203.208.250) > > > 1) start with an empty database; use slapadd to add a large (3 MB) > database. 2) > Use ldapbrowser to delete nearly all the nodes. After this process, I get > to a > point where a subnode can't be deleted; I see the message "12:00:27 PM: > Failed > to delete entry ou=Agents, lcc=Call Center 1, ou=Company, o=Spanlink > Communications > Reason: [LDAP: error code 80 - DN index delete failed] > 12:15:19 PM: Failed to delete entry ou=Agents, lcc=Call Center 1, > ou=Company, > o=Spanlink Communications > Reason: [LDAP: error code 80 - DN index delete failed]" in the ldapbrowser > window. > > Steps to reproduce: (on redhat linux; I think any linux will do) > 1) build bdb 4.8.26 from the distro; build openldap 2.4.21 from the > distro. > 2) copy built slapd to an appropriate place. link it to slapadd. > 3) FTP: ftp.calabrio.com, user openldap, pass *a68pcJH (Account is > scheduled to > close 3/23/2010; let me know if you need the file uploaded again). unzip > the > file, it contains the slapcat.out; a blank database (in a subfolder), and > a > slapd.conf file. > 4) Edit the slapd.conf file as needed to point to the directory where you > put > the database. > > That was the setup, now here are the steps to reproduce the problem: > > 5) use slapadd -c -f slapd.conf -l slapcat.out to create the database. > 6) start slapd (using slapd -d 1 -f slapd.conf) > 7) use ldapbrowser to delete the "lcc=call center 1" node. > > It takes a long time, but eventually you'll see it fail while trying to > delete > the "agents" node. Can you reproduce with -dtrace? It'll generate a large log file, please only post the part related to the failure. p.

1 0

Re: (ITS#6472) Syncrepl : loop problem with moddn on a new node
by masarati＠aero.polimi.it 17 Apr '10

17 Apr '10

A fix is in HEAD, please test slapd/syncrepl.c 1.502 -> 1.503 Thanks for reporting, p.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs