- openldap-bugs - openldap.org

Re: (ITS#6474) test004 (hdb) crashes when slapd is compiled with -D_FORTIFY_SOURCE=2
by hyc＠symas.com 13 Apr '10

13 Apr '10

h.b.furuseth(a)usit.uio.no wrote: >> There is no real buffer overflow here AFAICS but the real problem is, >> that the destination of the strcpy() is defined as char[1] in this >> case (it's the nrdn member of a struct diskNode). The additional >> runtime check when compiling with -D_FORTIFY_SOURCE=2 sees that the >> destination data will not fit in there and aborts. > > This is similar to the struct hack, except nrdn is not the last struct > member. IIRC it actually is invalid to use nrdn as an accessor for the > following struct members (from the compiler's point of view). > > Another case of "not quite the Struct Hack" broke last year: ITS#6303. > If _FORTIFY_SOURCE is warning us that gcc might break this code, the > memcpy patch might merely shut up the warning without fixing the > problem. In that case, the simplest change would be to do away with > struct diskNode - or keep it for reference but not actually use it. > > I'm reopening the ITS for someone else to decide if they care, I have > other things on my mind currently. > Nope, we don't care. The purpose and usage of diskNode is thoroughly documented in the comments and all of the uses are correct. Marking this Test again. -- -- 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#6474) test004 (hdb) crashes when slapd is compiled with -D_FORTIFY_SOURCE=2
by h.b.furuseth＠usit.uio.no 13 Apr '10

13 Apr '10

> There is no real buffer overflow here AFAICS but the real problem is, > that the destination of the strcpy() is defined as char[1] in this > case (it's the nrdn member of a struct diskNode). The additional > runtime check when compiling with -D_FORTIFY_SOURCE=2 sees that the > destination data will not fit in there and aborts. This is similar to the struct hack, except nrdn is not the last struct member. IIRC it actually is invalid to use nrdn as an accessor for the following struct members (from the compiler's point of view). Another case of "not quite the Struct Hack" broke last year: ITS#6303. If _FORTIFY_SOURCE is warning us that gcc might break this code, the memcpy patch might merely shut up the warning without fixing the problem. In that case, the simplest change would be to do away with struct diskNode - or keep it for reference but not actually use it. I'm reopening the ITS for someone else to decide if they care, I have other things on my mind currently. -- Hallvard

1 0

Re: (ITS#6517) undefined references to ldif_*
by michael＠stroeder.com 13 Apr '10

13 Apr '10

masarati(a)aero.polimi.it wrote: >> masarati(a)aero.polimi.it wrote: > >>> Actually it's not that; Michael routinely builds with --enable-dynamic, >>> and libldap now (dynamically) depends on liblutil for the LDIF part. >>> >> I did not want to introduce any new dependencies nor break any existing >> code with the new LDIF library. Ideally, you would only have to link >> with -lldif for external code that wants to use the LDIF API (such as >> ldif_get_entry or ldif_parse_line). Any existing code, or code that >> just wants to use the new higher level api ldap_parse_ldif_record_x >> would only have to link with -lldap. >> >> Is --enable-dynamic the only additional build flag I need to use? > > In fact, you did not introduce any further dependence, as ldif_* functions > (those provided in liblutil/ldif.c) are present in liblutil. I fixed the > issue by reversing the link order of libraries. > > It used to be liblutil, liblber, libldap (I think that was because earlier > there used to be dependencies of liblutil on the others, please correct > me). Now it's libldap, liblber, liblutil, and it builds fine with > --enable-dynamic=yes/no. Please check whether my fix is appropriate. It seems to work for me now. Ciao, Michael.

1 0

Re: (ITS#6517) undefined references to ldif_*
by richm＠stanfordalumni.org 13 Apr '10

13 Apr '10

masarati(a)aero.polimi.it wrote: >> masarati(a)aero.polimi.it wrote: >> > > >>> Actually it's not that; Michael routinely builds with --enable-dynamic, >>> and libldap now (dynamically) depends on liblutil for the LDIF part. >>> >>> >> I did not want to introduce any new dependencies nor break any existing >> code with the new LDIF library. Ideally, you would only have to link >> with -lldif for external code that wants to use the LDIF API (such as >> ldif_get_entry or ldif_parse_line). Any existing code, or code that >> just wants to use the new higher level api ldap_parse_ldif_record_x >> would only have to link with -lldap. >> >> Is --enable-dynamic the only additional build flag I need to use? >> > > In fact, you did not introduce any further dependence, as ldif_* functions > (those provided in liblutil/ldif.c) are present in liblutil. I fixed the > issue by reversing the link order of libraries. > > It used to be liblutil, liblber, libldap (I think that was because earlier > there used to be dependencies of liblutil on the others, please correct > me). Now it's libldap, liblber, liblutil, and it builds fine with > --enable-dynamic=yes/no. Please check whether my fix is appropriate. > I just pulled the latest code from anonymous(a)cvs.openldap.org - started from a clean directory - ran configure with --enable-dynamic --disable-static - make depend and make install - build completed successfully - server works fine, ldapmodify works fine > p. > > > > >

1 0

Re: (ITS#6517) undefined references to ldif_*
by masarati＠aero.polimi.it 13 Apr '10

13 Apr '10

> masarati(a)aero.polimi.it wrote: >> Actually it's not that; Michael routinely builds with --enable-dynamic, >> and libldap now (dynamically) depends on liblutil for the LDIF part. >> > I did not want to introduce any new dependencies nor break any existing > code with the new LDIF library. Ideally, you would only have to link > with -lldif for external code that wants to use the LDIF API (such as > ldif_get_entry or ldif_parse_line). Any existing code, or code that > just wants to use the new higher level api ldap_parse_ldif_record_x > would only have to link with -lldap. > > Is --enable-dynamic the only additional build flag I need to use? In fact, you did not introduce any further dependence, as ldif_* functions (those provided in liblutil/ldif.c) are present in liblutil. I fixed the issue by reversing the link order of libraries. It used to be liblutil, liblber, libldap (I think that was because earlier there used to be dependencies of liblutil on the others, please correct me). Now it's libldap, liblber, liblutil, and it builds fine with --enable-dynamic=yes/no. Please check whether my fix is appropriate. p.

1 0

Re: (ITS#6517) undefined references to ldif_*
by richm＠stanfordalumni.org 13 Apr '10

13 Apr '10

masarati(a)aero.polimi.it wrote: >> Michael Ströder wrote: >> >>> hyc(a)symas.com wrote: >>> >>>> richm(a)stanfordalumni.org wrote: >>>> >>>>> This is most likely related to my recent LDIF changes. But I didn't >>>>> see >>>>> this problem. What platform is this? What build flags are you using? >>>>> >>>> Built fine here too, looks like an inconsistent build tree over there. >>>> >>> The build with the same build flags on the very same system worked right >>> before the recent libldif check-ins. I'm using anon CVS pserver for cvs >>> up. >>> >> The anon CVS server has some lag in receiving updates from the master >> server. >> Don't you have an account on the master? >> > > Actually it's not that; Michael routinely builds with --enable-dynamic, > and libldap now (dynamically) depends on liblutil for the LDIF part. > I did not want to introduce any new dependencies nor break any existing code with the new LDIF library. Ideally, you would only have to link with -lldif for external code that wants to use the LDIF API (such as ldif_get_entry or ldif_parse_line). Any existing code, or code that just wants to use the new higher level api ldap_parse_ldif_record_x would only have to link with -lldap. Is --enable-dynamic the only additional build flag I need to use? > p. > > > > > >

1 0

Re: (ITS#6513) dynacl/aci fails on searches with attributes
by peter＠adpm.de 13 Apr '10

13 Apr '10

--Boundary-00=_glFxL04kLcJl7l6 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Thanks for your quick answer Pierangelo, On Monday, 12. April 2010, masarati(a)aero.polimi.it wrote: > > [...] > > My guess is that you're trying to use ACIs with a non-local storage. In > > that case your analysis is correct. Can you provide your (sanitized) > > configuration? I am using a local hdb backend. In order to generate a minimal test case I found out, that it seems to be=20 related to the rwm overlay. Although I have set rwm-rewriteEngine to off, rwm seems to be partially=20 active. Commenting out the rwm directives completely makes the searches work as=20 expected. Please find attached a testcase with slapd.conf and ldif data. To experience the issue simply perform a search with e.g. attribute 1.1 as = one=20 of the users in the data. Then comment the rwm-... lines in slapd.conf, restart slapd and try again. Voil=E0 the difference. > > [...] >=20 > Automatically detecting what attributes need to be added to requests for > proxying sounds like an overkill. Probably, a reasonable workaround could > be to add a configuration directive that lists what attributes need to be > added to requests. This directive should be honored by proxy backends and > in general by all those backends that do not pass back complete entries to > the frontend. In the case of proxy backends its use would be > straightforward, since requested attrs need to be mapped anyway in the > request. Adding some more would not be a big deal. =20 That would be absolutely sufficient for me. > Things might be a bit > more complicated in case of, say, special configurations like proxycache, > where ACIs would need to be added to all attribute templates, and so. Yet > another reason to avoid ACIs :) As much as I'd like to, but I fear I can't. I am trying to migrate from a non-OpenLDAP directory solution with a comple= x=20 permission structure in in-tree ACLs to OpenLDAP. Unfortunately the permissions are set up in a way that do not let them writ= e=20 as a short list of ACLs. Changing the permission structure is not possible as lots of applications=20 depend on it. =2D-=20 Peter Marschall peter(a)adpm.de --Boundary-00=_glFxL04kLcJl7l6 Content-Type: application/x-compressed-tar; name="testcase.tgz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="testcase.tgz" H4sIAOZWxEsAA+1YbW/jNgzuV/tXCMkBa3duXtz0CqQItq7JDTcc0sOKfjp0gyzJiTZH8iS5Sfbr R8mOm+SSJn1bN8AEAtsUxYekSJqOTnBKG0SK+ODVqAX0odOy1/bZqbsCI8yvrVYHFg/a7ZMP7dZp q3MG/HZ42jo9QK3XM+meMm2wQuhggpUmY5xukwOx+BVj9FZUR01mSDOhOG3qMhfQ8TG6Spn43L/4 giaYC6SZumMK2UU+yhQ2XAoU84T5fh1xQZKMsg2riM0MExoedYAgvmyC4abRaPjFHm8J3i03iVSs kd8/JKS52C0GMkaqUcqUlmIhDQZPx0wxRCUyY4ZUJgyfMGevRiPpp5zae89r3mHVhOU8MkV8YNXH aqSdyEYJu2pREjkacTFChzVIHqNriGsUS4XsE9eGE33kg0zC7ljiORF0cfnZ7lQMU4QJYTrfgcU8 knSOjERKStO/HgCLouvcoVzQM9KjosFmmJhereZ70dz73mnaKEBEL4/HiqTD1kZxYvgdhIaPxmAV wMroD0bMZYLBImxAIMoMQzJGOEmKRb2EY0V0b2mTA1lBv6ATLgLZM4BXgyQTeMScVAa5pnNz7CMW UswnMgPczIy3W2i3fQGkqVR0l2HLsg5EsyRGvensEWau2ZUHEXiuItYDp6FG0OBq2OgPVk9DZ5FR jPVqBcIjDKBzgUnSxISjqeKGrZkQYfInE7QpoW4TPEcTSTOb4Hmo/PwxxWbsNTOtmgmP8tIpVhKJ qWd1/D6m0TJPTSc+6H8ZAjspNjjCGsqRxVxw2zr0i6n3F9o964WrfGyg8G0coPT7P9meZWyDOzQy RZHCAopC2/yx6/ZojnydxTGfeV55RusdpHRh0UJAm2VzBUcvFcQe3jLQCqHoj/ySmzePMu5WtdWM 7XmDJHRRqb7ToAVahRhlXI8ZRQJDp7K1ny7S1zYEKsC69VxxK+nU80pR0P5JUE7yLLB93boO7ZOy mZcnKrHFGjBh1Pzyepjf3Nx86nse+6sQJCLQIhhB9YkhWBOAniSQgcycjKtPl4+oyLwuIKUIyaz3 9bfg9n1hHrImoPzeLyQ9l1zwOy5UDAQ0UObJOF7mXsKRwXvFg4TBWWKWl37NbN+uHTbeB0c/AOKh gzwK1sDf1VDtXRuY78Kysmrd2iYQzbAi4488MUxtXx/YOPWHD5myAX8f5AtoWP0hdDOONdoKttgz wQbyl+6/QbGYKYWTHOYhCViFsx1cffTfemap6OXItq5GQvlrjrb5/N/ZOv93OmeL+T/sdNp2/j9p n1Tz/79Bdei8djzvoja8LOGy6Mj3b4MudOp0lQEzNRb8bzfn+xIE7JbFBwMMJF3UqrtXR30Eb1Rz rgIS6IAGs/Ovjn1bT7Mo4aReYGY9mPrTdvBocJxkMDL4Musip+H5RoTPNiJ8nhE3dvwNXiQkTtW6 NcXEuc2e/HVuB2TClOExJ9iw0sg9dS3mA1HOBwnIyCytw5Byaf0qvfzZsr/1d1+jYcq/PZ8G95wc LUglFGxCJGWBtjtNANPQZJhNIqbqdtrfEvDnHf9/N+DhloCHbxDwLUf+pIjnup5XcVsi8jb2wHmR RYEET2wH+f8dq7yVv0J8IoqGadX7y5/D3fsvC3uyS2I/uug0HL6G/WUd+2XqddEvkq34EW70Y88Y 7+9HuJ8f4TY/wl1+7GxYD3viavEqtt9LejX42p8wWyP7nvxjMmu1Th1MPf/34ZjT+n543xzmQ03k CUEINwZhR9q8eBB24FWfPBVVVFFFFVVUUUUVVVRRRRVVVNH/l/4B1nCcvQAoAAA= --Boundary-00=_glFxL04kLcJl7l6--

1 0

Re: (ITS#6515) A lot of dead links on main page of OpenLDAP man.
by mitroko＠gmail.com 13 Apr '10

13 Apr '10

--000e0ce0457c739d9a04841af395 Content-Type: text/plain; charset=UTF-8 http://www.openldap.org/doc/admin24/schema.html - Contains them, as well On Mon, Apr 12, 2010 at 10:10 PM, Howard Chu <hyc(a)symas.com> wrote: > mitroko(a)gmail.com wrote: > >> Full_Name: Dmitry Stremkouski >> Version: >> OS: GNU/Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (95.84.189.132) >> >> >> Hello guys. The part of OpenLDAP Manual (wich can be found here - >> http://www.openldap.org/doc/admin23/schema.html) contains a lot of broken >> links. >> Please correct. >> > > The 2.3 release is no longer maintained. This doc will not be updated. > > FE: http://www.alvestrand.no/harald/objectid/ - dead >> A: http://www.bsa-global.com/ - dead (doesn't look good enough for global >> OID >> authority) >> A: http://www.iana.org/cgi-bin/enterprise.pl - should be (redirect, but >> futher, >> IMHO, will be dead, try http://pen.iana.org/pen/PenApplication.page) >> >> Thanks. >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > -- <pre> (o_ - Dzmitry Stremkouski. //\ - cel: +7 (916) 090-85-68 V_/_- web: http://mitroko.com </pre> --000e0ce0457c739d9a04841af395 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <a href=3D"http://www.openldap.org/doc/admin24/schema.html">http://www.open= ldap.org/doc/admin24/schema.html</a> - Contains them, as well <div c= lass=3D"gmail_quote">On Mon, Apr 12, 2010 at 10:10 PM, Howard Chu <<a href=3D"mailto:hyc@symas.com">hyc(a)symas.com</a>> = wrote: <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><a href=3D"mailto= :mitroko@gmail.com" target=3D"_blank">mitroko(a)gmail.com</a> wrote: <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Full_Name: Dmitry Stremkouski Version: OS: GNU/Linux URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/incoming/</a> Submission from: (NULL) (95.84.189.132) Hello guys. The part of OpenLDAP Manual (wich can be found here - <a href=3D"http://www.openldap.org/doc/admin23/schema.html" target=3D"_blan= k">http://www.openldap.org/doc/admin23/schema.html</a>) contains a lot of b= roken links. Please correct. </blockquote> The 2.3 release is no longer maintained. This doc will not be updated. <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> FE: <a href=3D"http://www.alvestrand.no/harald/objectid/" target=3D"_blank"= >http://www.alvestrand.no/harald/objectid/</a> - dead A: <a href=3D"http://www.bsa-global.com/" target=3D"_blank">http://www.bsa-= global.com/</a> - dead (doesn't look good enough for global OID authority) A: <a href=3D"http://www.iana.org/cgi-bin/enterprise.pl" target=3D"_blank">= http://www.iana.org/cgi-bin/enterprise.pl</a> - should be (redirect, but fu= ther, IMHO, will be dead, try <a href=3D"http://pen.iana.org/pen/PenApplication.p= age" target=3D"_blank">http://pen.iana.org/pen/PenApplication.page</a>) Thanks. </blockquote> -- =C2=A0-- Howard Chu =C2=A0CTO, Symas Corp. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http:= //www.symas.com" target=3D"_blank">http://www.symas.com</a> =C2=A0Director, Highland Sun =C2=A0 =C2=A0 <a href=3D"http://highlandsun.c= om/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a> =C2=A0Chief Architect, OpenLDAP =C2=A0<a href=3D"http://www.openldap.org/p= roject/" target=3D"_blank">http://www.openldap.org/project/</a> </blockquote></div> -- <pre> (o_ - Dz= mitry Stremkouski. //\ - cel: +7 (916) 090-85-68 V_/_- web: <a href= =3D"http://mitroko.com">http://mitroko.com</a> </pre> --000e0ce0457c739d9a04841af395--

1 0

(ITS#6518) Slapd-ldap proxy between replica and mirror
by udorta＠iac.es 13 Apr '10

13 Apr '10

Full_Name: Ubay Dorta Version: 2.4.21 OS: Suse Linux Enterprise Server 10 SP2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (161.72.9.46) We have problems when we introduce a back-ldap proxy server between a delta-syncrepl server and a mirror configuration of two servers. The modifications through the replica server (with chaining configuration) over the first mirror server are made without problems. The problem appears when we introduce a back-ldap proxy between replica and the two servers in mirror mode. First Scenario: --------------------- A delta syncrepl server replicating from the first server of a mirror. IPs: delta syncrepl (192.168.1.5), mirror server 1 (192.168.1.10), mirror server 2 (192.168.1.20) replica slapd.conf ##################### # Chaining configuration # ##################### overlay chain chain-uri "ldap://mirror1:389" chain-idassert-bind bindmethod="simple" binddn="cn=replicator,dc=example,dc=com" credentials="secret" mode="self" chain-return-error TRUE ########## # Replica # ########## database bdb suffix "dc=example,dc=com" rootdn "cn=Administrator,dc=example,dc=com" rootpw "secret" checkpoint 1024 5 cachesize 10000 index objectClass,uidNumber,gidNumber eq index member,mail eq,pres index cn,displayname,uid,sn,givenname sub,eq,pres overlay ppolicy ppolicy_default "cn=Default Password Policy,dc=example,dc=com" ppolicy_forward_updates ppolicy_hash_cleartext overlay memberof ################## # Syncrepl directives # ################## syncrepl rid=001 provider=ldap://mirror1:389 type=refreshAndPersist retry="60 +" searchbase="dc=example,dc=com" filter="(objectclass=*)" scope=sub attrs="*" schemachecking=on binddn="cn=replicator,dc=example,dc=com" bindmethod=simple credentials=secret sizelimit=unlimited logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog # Refer updates to the master updateref ldap://mirror1:389 ------------------------- ------------------------- slapd.conf of mirror server #1 ------------------------------------------- # Global section serverID 1 moduleload memberof access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to attrs=userPassword,userPKCS12 by self write by dn.base="cn=replicator,dc=example,dc=com" read by * auth access to attrs=shadowLastChange by self write by * read # Give the replica DN unlimited read access. This ACL needs to be # merged with other ACL statements, and/or moved within the scope # of a database. The "by * break" portion causes evaluation of # subsequent rules. See slapd.access(5) for details. access to * by dn.base="cn=replicator,dc=example,dc=com" read by * break access to * by * read # Load the accesslog overlay moduleload accesslog.la #Load the syncprov overlay moduleload syncprov.la # Accesslog database definitions database bdb monitoring off suffix cn=accesslog rootdn cn=accesslog index default eq index entryCSN,objectClass,reqEnd,reqResult,reqStart overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE # Let the replica DN have limitless searches limits dn.exact="cn=replicator,dc=example,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited ####################################################################### # BDB database definitions ####################################################################### database bdb monitoring off suffix "dc=example,dc=com" rootdn "cn=Administrator,dc=example,dc=com" rootpw "secret" checkpoint 1024 5 cachesize 10000 index objectClass,uidNumber,gidNumber eq index member,mail eq,pres index cn,displayname,uid,sn,givenname sub,eq,pres overlay ppolicy ppolicy_default "cn=Default Password Policy,dc=example,dc=com" ppolicy_hash_cleartext overlay memberof # Habilitar authz-policiy authz-policy to index entryCSN eq index entryUUID eq # syncrepl Provider for primary db overlay syncprov syncprov-checkpoint 1000 60 # accesslog overlay definitions for primary db overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE # scan the accesslog DB every day, and purge entries older than 7 days logpurge 07+00:00 01+00:00 # Let the replica DN have limitless searches limits dn.exact="cn=replicator,dc=example,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited #################################################### # MirrorMode - Syncrepl directive syncrepl rid=001 provider=ldap://mirror2:389 bindmethod=simple binddn="cn=Administrator,dc=example,dc=com" credentials=secret searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" mirrormode on --------------- --------------- In the mirror servers we have set the attribute authzTo for the replicator dn: ldapsearch -x -b 'cn=replicator,dc=example,dc=com' -H ldap://mirror1:389 -D 'cn=Administrator,dc=example,dc=com' -w secret authzTo # replicator, example.com dn: cn=replicator,dc=example,dc=com authzTo: ldap:///dc=example,dc=com??sub?(objectClass=person) When we launch the following modification through the replica: ldapmodify -x -H ldap://replica:389 -f pass1_user.ldif -D 'uid=user,ou=people,dc=example,dc=com' -W Enter LDAP Password: modifying entry "uid=user,ou=people,dc=example,dc=com" In the mirror server we get: ldap-mirror1[2649]: conn=1002 op=2 PROXYAUTHZ dn="uid=user,ou=people,dc=example,dc=com" ldap-mirror1[2649]: conn=1002 op=2 MOD dn="uid=user,ou=people,dc=example,dc=com" ldap-mirror1[2649]: conn=1002 op=2 MOD attr=userPassword ldap-mirror1[2649]: conn=1002 op=2 RESULT tag=103 err=0 text= Therefore modifying through the replica server is possible with the chaining configuration. Second sceneario -------------------------- The problem appears when we introduce the back-ldap proxy server to set the high availability feature that provides the mirror mode. IPs: ----- 192.168.1.5 -> delta syncrepl 192.168.1.10 -> Back-ldap proxy 192.168.1.20 -> Mirror mode server 1 192.168.1.30 -> Mirror mode server 2 back-ldap proxy slapd.conf: database ldap suffix "dc=example,dc=com" uri "ldap://mirror1:389 ldap://mirror2:389" rootdn "cn=Administrator,dc=example,dc=com" overlay ppolicy Launching the modification to the proxy, it works: ldapmodify -x -H ldap://proxy:389 -f pass1_user.ldif -D 'uid=user,ou=people,dc=example,dc=com' -W Enter LDAP Password: modifying entry "uid=udg77530,ou=people,dc=example,dc=com" The /var/log/messages of proxy and mirror shows the following: ldap-proxy[4051]: conn=1000 fd=8 ACCEPT from IP=192.168.1.5:42921 (IP=192.168.1.10:389) ldap-proxy[4051]: conn=1000 op=0 BIND dn="uid=user,ou=people,dc=example,dc=com" method=128 ldap-mirror1[3438]: conn=1015 fd=19 ACCEPT from IP=192.168.1.10:18103 (IP=192.168.1.20:1389) ldap-mirror1[3438]: conn=1015 op=0 BIND dn="" method=128 ldap-mirror1[3438]: conn=1015 op=0 RESULT tag=97 err=0 text= ldap-mirror1[3438]: conn=1015 op=1 SRCH base="uid=user,ou=people,dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" ldap-mirror1[3438]: conn=1015 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= ldap-mirror1[3438]: conn=1016 fd=20 ACCEPT from IP=192.168.1.10:18104 (IP=192.168.1.20:1389) ldap-mirror1[3438]: conn=1016 op=0 BIND dn="uid=user,ou=people,dc=example,dc=com" method=128 ldap-mirror1[3438]: conn=1016 op=0 BIND dn="uid=user,ou=people,dc=example,dc=com" mech=SIMPLE ssf=0 ldap-mirror1[3438]: conn=1016 op=0 RESULT tag=97 err=0 text= ldap-proxy[4051]: conn=1000 op=0 BIND dn="uid=user,ou=people,dc=example,dc=com" mech=SIMPLE ssf=0 ldap-mirror1[3438]: conn=1015 op=2 SRCH base="uid=user,ou=people,dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" ldap-mirror1[3438]: conn=1015 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= ldap-proxy[4051]: conn=1000 op=0 RESULT tag=97 err=0 text= ldap-proxy[4051]: conn=1000 op=1 MOD dn="uid=user,ou=people,dc=example,dc=com" ldap-proxy[4051]: conn=1000 op=1 MOD attr=userPassword ldap-mirror1[3438]: conn=1015 op=3 SRCH base="uid=user,ou=people,dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" ldap-mirror1[3438]: conn=1015 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text= ldap-mirror1[3438]: conn=1016 op=1 MOD dn="uid=user,ou=people,dc=example,dc=com" ldap-mirror1[3438]: conn=1016 op=1 MOD attr=userPassword ldap-mirror1[3438]: conn=1016 op=1 RESULT tag=103 err=0 text= ldap-proxy[4051]: conn=1000 op=1 RESULT tag=103 err=0 text= ldap-proxy[4051]: conn=1000 op=2 UNBIND ldap-mirror1[3438]: conn=1016 op=2 UNBIND ldap-mirror1[3438]: conn=1016 fd=20 closed ldap-proxy[4051]: conn=1000 fd=8 closed But when the modification is made through the replica server we get the error: ldapmodify -x -H ldap://replica:389 -f pass1_user.ldif -D 'uid=user,ou=people,dc=example,dc=com' -W Enter LDAP Password: modifying entry "uid=user,ou=people,dc=rexample,dc=com" ldap_modify: unknown result code (123) ldap-proxy[3688]: daemon: activity on 1 descriptor ldap-proxy[3688]: daemon: activity on: ldap-proxy[3688]: 12r ldap-proxy[3688]: ldap-proxy[3688]: daemon: read active on 12 ldap-proxy[3688]: daemon: epoll: listen=7 active_threads=0 tvp=NULL ldap-proxy[3688]: connection_get(12) ldap-proxy[3688]: connection_get(12): got connid=1001 ldap-proxy[3688]: connection_read(12): checking for input on id=1001 ldap-proxy[3688]: op tag 0x66, time 1271064513 ldap-proxy[3688]: conn=1001 op=2 do_modify ldap-proxy[3688]: conn=1001 op=2 do_modify: dn (uid=user,ou=people,dc=example,dc=com) ldap-proxy[3688]: => get_ctrls ldap-proxy[3688]: => get_ctrls: oid="2.16.840.1.113730.3.4.18" (noncritical) ldap-proxy[3688]: parseProxyAuthz: conn 1001 authzid="dn:uid=user,ou=people,dc=example,dc=com" ldap-proxy[3688]: slap_sasl_getdn: conn 1001 id=dn:uid=user,ou=people,dc=example,dc=com [len=38] ldap-proxy[3688]: >>> dnNormalize: <uid=user,ou=people,dc=example,dc=com> ldap-proxy[3688]: <<< dnNormalize: <uid=user,ou=people,dc=example,dc=com> ldap-proxy[3688]: ==>slap_sasl2dn: converting SASL name uid=user,ou=people,dc=example,dc=com to a DN ldap-proxy[3688]: <==slap_sasl2dn: Converted SASL name to <nothing> ldap-proxy[3688]: parseProxyAuthz: conn=1001 "uid=user,ou=people,dc=example,dc=com" ldap-proxy[3688]: ==>slap_sasl_authorized: can cn=replicator,dc=example,dc=com become uid=user,ou=people,dc=example,dc=com? ldap-proxy[3688]: <== slap_sasl_authorized: return 48 ldap-proxy[3688]: <= get_ctrls: n=1 rc=123 err="not authorized to assume identity" ldap-proxy[3688]: send_ldap_result: conn=1001 op=2 p=3 ldap-proxy[3688]: send_ldap_result: err=123 matched="" text="not authorized to assume identity" ldap-proxy[3688]: send_ldap_response: msgid=3 tag=103 err=123 ldap-proxy[3688]: conn=1001 op=2 RESULT tag=103 err=123 text=not authorized to assume identity ldap-proxy[3688]: conn=1001 op=2 do_modify: get_ctrls failed ldap-proxy[3688]: daemon: activity on 1 descriptor ldap-proxy[3688]: daemon: activity on: ldap-proxy[3688]: ldap-proxy[3688]: daemon: epoll: listen=7 active_threads=0 tvp=NULL The file pass1_user.ldif has: dn: uid=user,ou=people,dc=example,dc=com changetype: modify replace: userPassword userPassword: ####CRYPT PASSWORD#### Thanks

1 0

Re: (ITS#6517) undefined references to ldif_*
by masarati＠aero.polimi.it 12 Apr '10

12 Apr '10

> Michael Ströder wrote: >> hyc(a)symas.com wrote: >>> richm(a)stanfordalumni.org wrote: >>>> This is most likely related to my recent LDIF changes. But I didn't >>>> see >>>> this problem. What platform is this? What build flags are you using? >>> >>> Built fine here too, looks like an inconsistent build tree over there. >> >> The build with the same build flags on the very same system worked right >> before the recent libldif check-ins. I'm using anon CVS pserver for cvs >> up. > > The anon CVS server has some lag in receiving updates from the master > server. > Don't you have an account on the master? Actually it's not that; Michael routinely builds with --enable-dynamic, and libldap now (dynamically) depends on liblutil for the LDIF part. p.

1 0

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by richm＠stanfordalumni.org 12 Apr '10

12 Apr '10

masarati(a)aero.polimi.it wrote: >>>> Sorry about that. You can find it here: >>>> http://rmeggins.fedorapeople.org/ldifutil.c >>>> >>> Gotit, thanks. I have one first comment: the public API does not >>> generally expose the memory context. I'm renaming >>> ldap_parse_ldif_record() as ldap_parse_ldif_record_x(), and eliminating >>> the void *ctx arg from ldap_parse_ldif_record(), if you don't mind. >>> >> tested and applied to HEAD; please test. Thanks, p. >> > > More comments: > > 1) perhaps it may be worth providing a function that converts a LDIFRecord > structure into a string, and one that sends it to a stream > For debugging purposes, or something like that? > 2) I note you put > > LDAPMod **lr_mods; /* list of mods for LDAP_REQ_MODIFY, > LDAP_REQ_ADD */ > struct berval lr_newrdn; /* LDAP_REQ_MODDN, LDAP_REQ_MODRDN, > LDAP_REQ_RENAME */ > struct berval lr_newsuperior; /* LDAP_REQ_MODDN, LDAP_REQ_MODRDN, > LDAP_REQ_RENAME */ > int lr_deleteoldrdn; /* LDAP_REQ_MODDN, LDAP_REQ_MODRDN, > LDAP_REQ_RENAME */ > /* the following are for future support */ > struct berval lr_extop_oid; /* LDAP_REQ_EXTENDED */ > struct berval lr_extop_data; /* LDAP_REQ_EXTENDED */ > struct berval lr_cmp_attr; /* LDAP_REQ_COMPARE */ > struct berval lr_cmp_bvalue; /* LDAP_REQ_COMPARE */ > > in the structure; the last four are not used right now. I think it would > make sense to group struct members by op in substructures, and then put > them in a union, to stress the fact that they're mutually exclusive. Much > like Howard did for the corresponding substructures in the Operation > struct in slapd. > Please check out this patch - ftp://ftp.openldap.org/incoming/openldap-2.4.21-ldifrecord-union-20100412.p… > p. > > > > >

1 0

Re: (ITS#6517) undefined references to ldif_*
by hyc＠symas.com 12 Apr '10

12 Apr '10

Michael Ströder wrote: > hyc(a)symas.com wrote: >> richm(a)stanfordalumni.org wrote: >>> This is most likely related to my recent LDIF changes. But I didn't see >>> this problem. What platform is this? What build flags are you using? >> >> Built fine here too, looks like an inconsistent build tree over there. > > The build with the same build flags on the very same system worked right > before the recent libldif check-ins. I'm using anon CVS pserver for cvs up. The anon CVS server has some lag in receiving updates from the master server. Don't you have an account on the master? -- -- 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#6517) undefined references to ldif_*
by michael＠stroeder.com 12 Apr '10

12 Apr '10

hyc(a)symas.com wrote: > richm(a)stanfordalumni.org wrote: >> michael(a)stroeder.com wrote: >>> Full_Name: >>> Version: HEAD >>> OS: Linux >>> URL: >>> Submission from: (NULL) (84.163.96.140) >>> >>> >>> cc -g -O2 -Wl,-R/dummy/lib -Wl,-R/dummy/lib -Wl,-R/dummy/lib -Wl,-R/dummy/lib -o >>> .libs/ldapurl ldapurl.o lduversion.o -L/dummy/lib >>> ../../libraries/liblutil/liblutil.a ../../libraries/libldap/.libs/libldap.so >>> /usr/src/michael/openldap/HEAD/openldap/libraries/liblber/.libs/liblber.so >>> ../../libraries/liblber/.libs/liblber.so -lsasl2 -lssl -lcrypto -lcrypt -lresolv >>> -Wl,--rpath -Wl,/opt/openldap-HEAD/lib >>> ../../libraries/libldap/.libs/libldap.so: undefined reference to `ldif_getline' >>> ../../libraries/libldap/.libs/libldap.so: undefined reference to >>> `ldif_countlines' >>> ../../libraries/libldap/.libs/libldap.so: undefined reference to >>> `ldif_parse_line2' >>> ../../libraries/libldap/.libs/libldap.so: undefined reference to `ldif_debug' >>> collect2: ld returned 1 exit status >>> make[2]: *** [ldapurl] Error 1 >>> make[2]: Leaving directory >>> `/usr/src/michael/openldap/HEAD/openldap/clients/tools' >>> make[1]: *** [all-common] Error 1 >>> make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/clients' >>> make: *** [all-common] Error 1 >>> >>> >> This is most likely related to my recent LDIF changes. But I didn't see >> this problem. What platform is this? What build flags are you using? > > Built fine here too, looks like an inconsistent build tree over there. The build with the same build flags on the very same system worked right before the recent libldif check-ins. I'm using anon CVS pserver for cvs up. Ciao, Michael.

1 0

Re: (ITS#6517) undefined references to ldif_*
by hyc＠symas.com 12 Apr '10

12 Apr '10

richm(a)stanfordalumni.org wrote: > michael(a)stroeder.com wrote: >> Full_Name: >> Version: HEAD >> OS: Linux >> URL: >> Submission from: (NULL) (84.163.96.140) >> >> >> cc -g -O2 -Wl,-R/dummy/lib -Wl,-R/dummy/lib -Wl,-R/dummy/lib -Wl,-R/dummy/lib -o >> .libs/ldapurl ldapurl.o lduversion.o -L/dummy/lib >> ../../libraries/liblutil/liblutil.a ../../libraries/libldap/.libs/libldap.so >> /usr/src/michael/openldap/HEAD/openldap/libraries/liblber/.libs/liblber.so >> ../../libraries/liblber/.libs/liblber.so -lsasl2 -lssl -lcrypto -lcrypt -lresolv >> -Wl,--rpath -Wl,/opt/openldap-HEAD/lib >> ../../libraries/libldap/.libs/libldap.so: undefined reference to `ldif_getline' >> ../../libraries/libldap/.libs/libldap.so: undefined reference to >> `ldif_countlines' >> ../../libraries/libldap/.libs/libldap.so: undefined reference to >> `ldif_parse_line2' >> ../../libraries/libldap/.libs/libldap.so: undefined reference to `ldif_debug' >> collect2: ld returned 1 exit status >> make[2]: *** [ldapurl] Error 1 >> make[2]: Leaving directory >> `/usr/src/michael/openldap/HEAD/openldap/clients/tools' >> make[1]: *** [all-common] Error 1 >> make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/clients' >> make: *** [all-common] Error 1 >> >> > This is most likely related to my recent LDIF changes. But I didn't see > this problem. What platform is this? What build flags are you using? Built fine here too, looks like an inconsistent build tree over there. -- -- 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#6517) undefined references to ldif_*
by richm＠stanfordalumni.org 12 Apr '10

12 Apr '10

michael(a)stroeder.com wrote: > Full_Name: > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (84.163.96.140) > > > cc -g -O2 -Wl,-R/dummy/lib -Wl,-R/dummy/lib -Wl,-R/dummy/lib -Wl,-R/dummy/lib -o > .libs/ldapurl ldapurl.o lduversion.o -L/dummy/lib > ../../libraries/liblutil/liblutil.a ../../libraries/libldap/.libs/libldap.so > /usr/src/michael/openldap/HEAD/openldap/libraries/liblber/.libs/liblber.so > ../../libraries/liblber/.libs/liblber.so -lsasl2 -lssl -lcrypto -lcrypt -lresolv > -Wl,--rpath -Wl,/opt/openldap-HEAD/lib > ../../libraries/libldap/.libs/libldap.so: undefined reference to `ldif_getline' > ../../libraries/libldap/.libs/libldap.so: undefined reference to > `ldif_countlines' > ../../libraries/libldap/.libs/libldap.so: undefined reference to > `ldif_parse_line2' > ../../libraries/libldap/.libs/libldap.so: undefined reference to `ldif_debug' > collect2: ld returned 1 exit status > make[2]: *** [ldapurl] Error 1 > make[2]: Leaving directory > `/usr/src/michael/openldap/HEAD/openldap/clients/tools' > make[1]: *** [all-common] Error 1 > make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/clients' > make: *** [all-common] Error 1 > > This is most likely related to my recent LDIF changes. But I didn't see this problem. What platform is this? What build flags are you using?

1 0

(ITS#6517) undefined references to ldif_*
by michael＠stroeder.com 12 Apr '10

12 Apr '10

Full_Name: Version: HEAD OS: Linux URL: Submission from: (NULL) (84.163.96.140) cc -g -O2 -Wl,-R/dummy/lib -Wl,-R/dummy/lib -Wl,-R/dummy/lib -Wl,-R/dummy/lib -o .libs/ldapurl ldapurl.o lduversion.o -L/dummy/lib ../../libraries/liblutil/liblutil.a ../../libraries/libldap/.libs/libldap.so /usr/src/michael/openldap/HEAD/openldap/libraries/liblber/.libs/liblber.so ../../libraries/liblber/.libs/liblber.so -lsasl2 -lssl -lcrypto -lcrypt -lresolv -Wl,--rpath -Wl,/opt/openldap-HEAD/lib ../../libraries/libldap/.libs/libldap.so: undefined reference to `ldif_getline' ../../libraries/libldap/.libs/libldap.so: undefined reference to `ldif_countlines' ../../libraries/libldap/.libs/libldap.so: undefined reference to `ldif_parse_line2' ../../libraries/libldap/.libs/libldap.so: undefined reference to `ldif_debug' collect2: ld returned 1 exit status make[2]: *** [ldapurl] Error 1 make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/clients/tools' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/clients' make: *** [all-common] Error 1

1 0

Re: (ITS#6515) A lot of dead links on main page of OpenLDAP man.
by hyc＠symas.com 12 Apr '10

12 Apr '10

mitroko(a)gmail.com wrote: > Full_Name: Dmitry Stremkouski > Version: > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (95.84.189.132) > > > Hello guys. The part of OpenLDAP Manual (wich can be found here - > http://www.openldap.org/doc/admin23/schema.html) contains a lot of broken > links. > Please correct. The 2.3 release is no longer maintained. This doc will not be updated. > FE: http://www.alvestrand.no/harald/objectid/ - dead > A: http://www.bsa-global.com/ - dead (doesn't look good enough for global OID > authority) > A: http://www.iana.org/cgi-bin/enterprise.pl - should be (redirect, but futher, > IMHO, will be dead, try http://pen.iana.org/pen/PenApplication.page) > > Thanks. -- -- 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#6516) Proxy backends normalize ordered attrs incorrectly
by masarati＠aero.polimi.it 12 Apr '10

12 Apr '10

> They need to use ordered_value_*() functions instead. Fixed in HEAD. p.

1 0

(ITS#6516) Proxy backends normalize ordered attrs incorrectly
by masarati＠aero.polimi.it 12 Apr '10

12 Apr '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.165.199) Submitted by: ando They need to use ordered_value_*() functions instead. A patch is coming. p.

1 0

Re: (ITS#6513) dynacl/aci fails on searches with attributes
by masarati＠aero.polimi.it 12 Apr '10

12 Apr '10

>> Full_Name: Peter Marschall >> Version: 2.4.21 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/Peter-Marschall-100411.patch >> Submission from: (NULL) (94.217.135.20) >> >> >> Hi, >> >> Playing around with dynacl/aci a bit I cam across the following issue: >> >> Searches that do not contain the attribute OpenLDAPaci in the list of >> attribues >> queried, omit objects. > > dynacl/aci (as the original aci code it's based on) relies on the fact > that the entry is complete. This is the case when the entry is stored > locally, e.g. in back-bdb/hdb. Otherwise, no mechanism is in place to > retrieve operational attributes. Please note that in the latter case, > even ACL rules based on, say, createTimestamp or so would operate > incorrectly. > > My guess is that you're trying to use ACIs with a non-local storage. In > that case your analysis is correct. Can you provide your (sanitized) > configuration? > > The "right" solution is much more general, not only related to dynacl. > Slapd needs to know in advance what (operational) attributes are required > for policy enforcing, and they need to be added to requested attrs when > entries are collected from remote storage. Your patch seems to fix your > specific need, but it is clearly inefficient. Automatically detecting what attributes need to be added to requests for proxying sounds like an overkill. Probably, a reasonable workaround could be to add a configuration directive that lists what attributes need to be added to requests. This directive should be honored by proxy backends and in general by all those backends that do not pass back complete entries to the frontend. In the case of proxy backends its use would be straightforward, since requested attrs need to be mapped anyway in the request. Adding some more would not be a big deal. Things might be a bit more complicated in case of, say, special configurations like proxycache, where ACIs would need to be added to all attribute templates, and so. Yet another reason to avoid ACIs :) p.

1 0

Re: (ITS#6514) bindDN-rewriting with rwm+relay doesn't seem to work
by masarati＠aero.polimi.it 12 Apr '10

12 Apr '10

> Full_Name: Thomas Wunder > Version: 2.4.17 > OS: debian sqeueeze amd64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (141.13.106.69) I don't see a clear evidence of a bug. Software usage questions must be directed to the openldap-software list. Moreover, I just tried your verbatim configuration with the most recent code (while you're using an older release), and it seems to work as expected. This ITS will be closed. p. > I'm currently using the rwm overlay to filter the objects from my > ou=students,dc=uni-bamberg,dc=de directory by their "o"-attribute and > project > the result to ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de > Therefore I use the following section within my slapd.conf (before the > "database > hdb..." section): > > database relay > suffix > "ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de" > overlay rwm > #rwm-rewriteEngine on > rwm-suffixmassage > "ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de" > > "ou=students,dc=uni-bamberg,dc=de" > rwm-rewriteContext bindDN > rwm-rewriteRule ".*" "cn=ldapadmin,dc=uni-bamberg,dc=de" ":@" > rwm-rewriteContext searchFilter > rwm-rewriteRule "(.*)" "(&(o=swt)$1)" ":@I" > > searchFilter rewriting works perfectly but I also need to rewrite the > bindDN as > every operation within ou=students,dc=uni-bamberg,dc=de needs to be > carried out > by a particular user (cn=ldapadmin,dc=uni-bamberg,dc=de) > (the reason is that i don't want any user other than ldapadmin to be able > to > write ou=students,dc=uni-bamberg,dc=de but they should be able to modifiy > entries within ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de) > according to the logs and the error reply messages there seems to be no > binndn > rewriting done... > It looks like the rule never matches. > Is my rule not general enough to match each possible bindDN-String? Is > "cn=ldapadmin,dc=uni-bamberg,dc=de" (replacement string for the bindDN) > not well > formatted (does it expect something else)? Does the overlay "relay" > prevent the > replacement of the bindDN? > > As you can see I don't have any idea what might be causing my problem and > I hope > you can help me. > > >

1 0

Re: (ITS#6507) backglue and paged results issue
by jonathan＠phillipoux.net 12 Apr '10

12 Apr '10

Le 08/04/2010 19:26, masarati(a)aero.polimi.it a écrit : >> Ah yes, just saw this. Sorry, my email seems to be slow today (weird). >> >> Similar to my patch, but I'm unsure about the second part: >> >> } else if ( op->o_bd != gi->gi_n[0].gn_be ) { >> /* if cookie not empty, it's again this database's turn */ >> op->o_conn->c_pagedresults_state.ps_be = op->o_bd; >> } >> >> If the cookie is not empty, then it should again be this database's >> turn, even it this is this last database. >> >> This makes a search that stops in the middle of results from last >> database with a valid cookie fall back to the first database on >> continuation, and thus loop forever. >> >> Would you consider removing the else if? > > Well, it's not that simple. The fact is that paged results state is being > handled in two ways: when the database is back-bdb/hdb, the cookie is an > ID, and it's stored in ps_cookie; otherwise (e.g. back-ldap), it's a > berval, stored in ps_cookieval. I need to handle both cases. I think I > made it. > > Now, ps_cookie in c_pagedresults_state is initialized to NOID; back-bdb > will set it to 0 first, and then to whatever value it needs. Other > backends, that use ps_cookieval, will not touch it. So when ps_cookie == > NOID one needs to look at ps_cookieval (and parse it as needed), otherwise > ps_cookie suffices. You'll need to update backglue.c, controls.c and > back-bdb/search.c. > > Now it passes all cases I checked, both with local glued databases and > with back-null/back-ldap as in your example. Right - I'd missed that, regarding this difference between hdb/bdb databases and others. Thanks for the explanation! Just tested your lasted patch set, and it all works great for me, in various different scenarios. Thanks a lot. Jonathan -- -------------------------------------------------------------- Jonathan Clarke - jonathan(a)phillipoux.net -------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org --------------------------------------------------------------

1 0

Re: (ITS#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by richm＠stanfordalumni.org 12 Apr '10

12 Apr '10

hyc(a)symas.com wrote: > rmeggins(a)redhat.com wrote: > >> Any update on this? >> > > Sorry I must've missed your last reply, I thought we were still waiting on you. > > Why is pem_mod_name needed as an independent variable? Since it's const I > presume it will not be changing in the future? > I guess it doesn't really matter. It may change if the PEM module decides to change its name, but that is not likely. > (Not asking for a change here, just want to understand its purpose.) > > Actually, since it and pem_library are only used once each, I would probably > just #define it instead. But again, just want to know first how constant it > really is. > See above - it doesn't matter to me either, it could be #define'd or even hard coded in the module init string. Just let me know. > I've committed the patch as-is. If any other tweaks are needed let us know. > Thanks for working on this. > Thanks!

1 0

(ITS#6515) A lot of dead links on main page of OpenLDAP man.
by mitroko＠gmail.com 12 Apr '10

12 Apr '10

Full_Name: Dmitry Stremkouski Version: OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (95.84.189.132) Hello guys. The part of OpenLDAP Manual (wich can be found here - http://www.openldap.org/doc/admin23/schema.html) contains a lot of broken links. Please correct. FE: http://www.alvestrand.no/harald/objectid/ - dead A: http://www.bsa-global.com/ - dead (doesn't look good enough for global OID authority) A: http://www.iana.org/cgi-bin/enterprise.pl - should be (redirect, but futher, IMHO, will be dead, try http://pen.iana.org/pen/PenApplication.page) Thanks.

1 0

(ITS#6514) bindDN-rewriting with rwm+relay doesn't seem to work
by thomas.wunder＠swt-bamberg.de 12 Apr '10

12 Apr '10

Full_Name: Thomas Wunder Version: 2.4.17 OS: debian sqeueeze amd64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (141.13.106.69) Hi! I'm currently using the rwm overlay to filter the objects from my ou=students,dc=uni-bamberg,dc=de directory by their "o"-attribute and project the result to ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de Therefore I use the following section within my slapd.conf (before the "database hdb..." section): database relay suffix "ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de" overlay rwm #rwm-rewriteEngine on rwm-suffixmassage "ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de" "ou=students,dc=uni-bamberg,dc=de" rwm-rewriteContext bindDN rwm-rewriteRule ".*" "cn=ldapadmin,dc=uni-bamberg,dc=de" ":@" rwm-rewriteContext searchFilter rwm-rewriteRule "(.*)" "(&(o=swt)$1)" ":@I" searchFilter rewriting works perfectly but I also need to rewrite the bindDN as every operation within ou=students,dc=uni-bamberg,dc=de needs to be carried out by a particular user (cn=ldapadmin,dc=uni-bamberg,dc=de) (the reason is that i don't want any user other than ldapadmin to be able to write ou=students,dc=uni-bamberg,dc=de but they should be able to modifiy entries within ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de) according to the logs and the error reply messages there seems to be no binndn rewriting done... It looks like the rule never matches. Is my rule not general enough to match each possible bindDN-String? Is "cn=ldapadmin,dc=uni-bamberg,dc=de" (replacement string for the bindDN) not well formatted (does it expect something else)? Does the overlay "relay" prevent the replacement of the bindDN? As you can see I don't have any idea what might be causing my problem and I hope you can help me.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs