- openldap-bugs - openldap.org

(ITS#6456) Feature Request
by j＠gropefruit.com 17 Jan '10

17 Jan '10

Full_Name: J Version: 2.4.20 OS: Debian-Lenny/amd64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (68.15.14.98) Greetings, Having found out this doesn't already exist as another parameter or configuration method, I am hereby submitting a request for a particular feature. When performing idassert-bind operations, such as with back_ldap, it would be great if an option could be added which would allow specific matched client DNs to be matched and asserted as usual (e.g: the anonymous user asserting to a backend "proxyauthenticator" account) .... while other clients (flagged somehow) would pass-through as themselves. Example (as I might do it for my purposes): idassert-bind bindmethod="simple" binddn="uid=proxyauthenticator,ou=users,dc=example,dc=com" credentials="password_string" starttls="yes" tls_reqcert="never" mode="none" # anonymous clients will assert as "proxyauthenticator", since the backend may not allow anonymous binds. idassert-authzFrom "dn.exact:" # this guy will pass through as himself to the backend, as-is. idassert-passThrough "dn.exact:uid=admin,ou=users,dc=example,dc=com" This would be really helpful, not sure if its difficult to implement ...

1 0

Re: (ITS#6455) Able to crash slapd while using back_ldap
by quanah＠zimbra.com 17 Jan '10

17 Jan '10

--On Sunday, January 17, 2010 10:28 PM +0000 j(a)gropefruit.com wrote: > In general, a page should exist on openldap.org that details, in full, = > the debugging/core dump process and best practices.=20 Building unix software with debugging symbols is basic system administrator knowledge. There is nothing "openldap" specific about doing so. Same with debugging the core files that are generated. Here's a page on basic C compilation: <http://www.cs.rutgers.edu/LCSR-Computing/programming.html> Most specifically, note the "-g" option to CFLAGS, which instructs gcc, in this case, to include debugging symbols in the resulting compiled code. Ensure that when you install, you set STRIP="" so that the "make" program does not strip out the debugging symbols on installation. Run the new slapd that has the debugging information and get a core file. Use GDB to get a backtrace from it. Again, nothing here is specific to OpenLDAP, which is why there is no "OpenLDAP" page on how to do this. I will note the FAQ is fully interactive, allowing anyone to create an entry, if you feel so inclined. I would suggest updating <http://www.openldap.org/faq/data/cache/59.html> with any information you feel specifically is lacking. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6455) Able to crash slapd while using back_ldap
by j＠gropefruit.com 17 Jan '10

17 Jan '10

--Apple-Mail-1--155291042 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii See my inline changes: On Jan 17, 2010, at 14:13 , masarati(a)aero.polimi.it wrote: > Apart from some changes, I can't reproduce. See comments below. >=20 >> Full_Name: J >> Version: 2.4.20 >> OS: Debian-Lenny/amd64 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (68.15.14.98) >>=20 >>=20 >> Host running Debian Lenny amd64 is experiencing a strange issue. = slapd is >> segfaulting for no obvious reason. Syslog output: >>=20 >> Jan 15 19:29:59 ldapc1 kernel: [10702.262741] slapd[3218]: segfault = at 40 >> ip >> 7fb2b4829875 sp 44d90940 error 4 in >> back_ldap-2.4.so.2.5.3[7fb2b4819000+1f000] >=20 Is there a recommended debugging "practice" you guys recommend? And what = control do I have over the details of our DIT being produced in the core = dump? Security concerns on part of my organization may prevent such a = backtrace ... =3D( > This is not a useful bug report. You should rather follow = instructions > here <http://www.openldap.org/faq/data/cache/56.html> and provide = useful > information. A stack backtrace is essentially mandatory. Also, = details > about the DIT and the exact offending operations would be of help. >=20 >> We are running slapd 2.4.20, via this config: >>=20 >> include /etc/ldap/schema/core.schema >> include /etc/ldap/schema/cosine.schema >> include /etc/ldap/schema/nis.schema >> include /etc/ldap/schema/inetorgperson.schema >>=20 >> pidfile /var/run/slapd/slapd.pid >> argsfile /var/run/slapd/slapd.args >>=20 >> disallow bind_anon >>=20 >> loglevel 0 >> sizelimit 999999 >> idletimeout 10 >>=20 >> modulepath /usr/lib/ldap >> moduleload back_ldap >> moduleload back_hdb >> moduleload pcache >>=20 >> TLSCertificateFile /etc/ldap/ssl/wildcard.crt >> TLSCertificateKeyFile /etc/ldap/ssl/wildcard.key >> TLSCACertificateFile /etc/ldap/ssl/wildcard.pem >>=20 >> database ldap >> uri ldaps://192.168.1.1:636/ >> suffix "ou=3Dsvcs,cn=3Dauth" >> rootdn "uid=3Dslapd,ou=3Dsvcs,cn=3Dauth" >=20 I lied. Our syntax is not cn=3Dauth, I had to sanitize it from what it = really was (security concerns for my company). But thanks for the note. > I note that "cn=3Dauth" should not be used, as this naming context is = used > internally for SASL identities. >=20 >> idassert-bind >> bindmethod=3Dsimple >> binddn=3D"uid=3Dauth,ou=3Dsvcs,cn=3Dauth" >> credentials=3D"password" >> mode=3Dnone >> idassert-authz=46rom "dn.subtree:ou=3Dsvcs,cn=3Dauth" >>=20 >> ### For some reason, we can no longer use indexes like we could in = slapd >> 2.3 >> ### while using back_ldap (uncommenting these will present slapd from >> starting). >>=20 >> #index objectClass eq >> #index uid,mail,cn eq,sub >> #index queryid eq >=20 Thanks. This is useful to know. > 2.4 is pickier about syntax. "index" has no meaning within back-ldap. = In > 2.3 unrecognized keywords were plainly ignored. >=20 >> overlay pcache >> proxycache hdb 1000 1 50 1200 >> directory "/var/lib/ldap" >> proxycachequeries 100 >> proxyattrset 0 uid mail cn >> proxytemplate (uid=3D) 0 600 >>=20 >> include /etc/ldap/acls.slapd >>=20 >> ########## >>=20 >>=20 >> My hunch, given ITS #6452 (which I remarked was "solved"), is that id >> assertion >> may cause slapd to crash when an identity tries to assert as itself? >>=20 >> e.g: uid=3Dauth,ou=3Dsvcs,cn=3Dauth >--idassert--> = uid=3Dauth,ou=3Dsvcs,cn=3Dauth by >> means >> of the idassert-authz=46rom parameter, which authorizes the entire = subtree >> in >> which this account resides. Again, just a hunch ... >=20 > I had it working auth'ing both as idassert's "binddn" and as another = user > within the allowed subtree. >=20 In general, a page should exist on openldap.org that details, in full, = the debugging/core dump process and best practices.=20 > Please improve the report and feed back. >=20 > p. >=20 --Apple-Mail-1--155291042 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">See = my inline changes:<div><br></div><div><div><div>On Jan 17, 2010, at = 14:13 , <a = href=3D"mailto:masarati@aero.polimi.it">masarati(a)aero.polimi.it</a> = wrote:</div><br class=3D"Apple-interchange-newline"><blockquote = type=3D"cite"><div>Apart from some changes, I can't reproduce.  See = comments below.<br><br><blockquote type=3D"cite">Full_Name: = J<br></blockquote><blockquote type=3D"cite">Version: = 2.4.20<br></blockquote><blockquote type=3D"cite">OS: = Debian-Lenny/amd64<br></blockquote><blockquote type=3D"cite">URL: <a = href=3D"ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/= </a><br></blockquote><blockquote type=3D"cite">Submission from: (NULL) = (68.15.14.98)<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">Host running = Debian Lenny amd64 is experiencing a strange issue.  slapd = is<br></blockquote><blockquote type=3D"cite">segfaulting for no obvious = reason. Syslog output:<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">Jan 15 19:29:59 = ldapc1 kernel: [10702.262741] slapd[3218]: segfault at = 40<br></blockquote><blockquote = type=3D"cite">ip<br></blockquote><blockquote type=3D"cite">7fb2b4829875 = sp 44d90940 error 4 in<br></blockquote><blockquote = type=3D"cite">back_ldap-2.4.so.2.5.3[7fb2b4819000+1f000]<br></blockquote><= br></div></blockquote><div>Is there a recommended debugging "practice" = you guys recommend? And what control do I have over the details of our = DIT being produced in the core dump?  Security concerns on part of = my organization may prevent such a backtrace ... =3D(</div><br><blockquote= type=3D"cite"><div>This is not a useful bug report.  You should = rather follow instructions<br>here <<a = href=3D"http://www.openldap.org/faq/data/cache/56.html">http://www.openlda= p.org/faq/data/cache/56.html</a>> and provide useful<br>information. =  A stack backtrace is essentially mandatory.  Also, = details<br>about the DIT and the exact offending operations would be of = help.<br><br><blockquote type=3D"cite">We are running slapd 2.4.20, via = this config:<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">include =         /etc/ldap/schema/core.sche= ma<br></blockquote><blockquote type=3D"cite">include =         /etc/ldap/schema/cosine.sc= hema<br></blockquote><blockquote type=3D"cite">include =         /etc/ldap/schema/nis.schem= a<br></blockquote><blockquote type=3D"cite">include =         /etc/ldap/schema/inetorgpe= rson.schema<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">pidfile =         /var/run/slapd/slapd.pid<b= r></blockquote><blockquote type=3D"cite">argsfile =        /var/run/slapd/slapd.args<br></b= lockquote><blockquote type=3D"cite"><br></blockquote><blockquote = type=3D"cite">disallow =        bind_anon<br></blockquote><block= quote type=3D"cite"><br></blockquote><blockquote type=3D"cite">loglevel =        0<br></blockquote><blockquote = type=3D"cite">sizelimit =       999999<br></blockquote><blockquote = type=3D"cite">idletimeout =     10<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">modulepath =      /usr/lib/ldap<br></blockquote><blockquote = type=3D"cite">moduleload =      back_ldap<br></blockquote><blockquote = type=3D"cite">moduleload =      back_hdb<br></blockquote><blockquote = type=3D"cite">moduleload =      pcache<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote = type=3D"cite">TLSCertificateFile =      /etc/ldap/ssl/wildcard.crt<br></blockquote><= blockquote type=3D"cite">TLSCertificateKeyFile =   /etc/ldap/ssl/wildcard.key<br></blockquote><blockquote = type=3D"cite">TLSCACertificateFile =    /etc/ldap/ssl/wildcard.pem<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">database =        ldap<br></blockquote><blockquote= type=3D"cite">uri =             <a= = href=3D"ldaps://192.168.1.1:636/">ldaps://192.168.1.1:636/</a><br></blockq= uote><blockquote type=3D"cite">suffix =          "ou=3Dsvcs,cn=3Dauth= "<br></blockquote><blockquote type=3D"cite">rootdn =          "uid=3Dslapd,ou=3Dsv= cs,cn=3Dauth"<br></blockquote><br></div></blockquote><div><br></div><div>I= lied. Our syntax is not cn=3Dauth, I had to sanitize it from what it = really was (security concerns for my company).  But thanks for the = note.</div><br><blockquote type=3D"cite"><div>I note that "cn=3Dauth" = should not be used, as this naming context is used<br>internally for = SASL identities.<br><br><blockquote = type=3D"cite">idassert-bind<br></blockquote><blockquote type=3D"cite"> =   bindmethod=3Dsimple<br></blockquote><blockquote type=3D"cite">= =   binddn=3D"uid=3Dauth,ou=3Dsvcs,cn=3Dauth"<br></blockquote><blo= ckquote type=3D"cite"> =   credentials=3D"password"<br></blockquote><blockquote = type=3D"cite">   mode=3Dnone<br></blockquote><blockquote = type=3D"cite">idassert-authz=46rom = "dn.subtree:ou=3Dsvcs,cn=3Dauth"<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">### For some = reason, we can no longer use indexes like we could in = slapd<br></blockquote><blockquote = type=3D"cite">2.3<br></blockquote><blockquote type=3D"cite">### while = using back_ldap (uncommenting these will present slapd = from<br></blockquote><blockquote = type=3D"cite">starting).<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">#index =           objectClass =    eq<br></blockquote><blockquote type=3D"cite">#index =          uid,mail,cn =     eq,sub<br></blockquote><blockquote = type=3D"cite">#index =          queryid =         eq<br></blockquote><br></d= iv></blockquote><div><br></div><div>Thanks.  This is useful to = know.</div><br><blockquote type=3D"cite"><div>2.4 is pickier about = syntax.  "index" has no meaning within back-ldap.  In<br>2.3 = unrecognized keywords were plainly ignored.<br><br><blockquote = type=3D"cite">overlay =             &n= bsp;   pcache<br></blockquote><blockquote = type=3D"cite">proxycache =             &n= bsp;hdb 1000 1 50 1200<br></blockquote><blockquote type=3D"cite">directory= =             &n= bsp; "/var/lib/ldap"<br></blockquote><blockquote = type=3D"cite">proxycachequeries =       100<br></blockquote><blockquote = type=3D"cite">proxyattrset =            0 uid = mail cn<br></blockquote><blockquote type=3D"cite">proxytemplate =           (uid=3D) =  0 600<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">include =             &n= bsp;   /etc/ldap/acls.slapd<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote = type=3D"cite">##########<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">My hunch, given = ITS #6452 (which I remarked was "solved"), is that = id<br></blockquote><blockquote = type=3D"cite">assertion<br></blockquote><blockquote type=3D"cite">may = cause slapd to crash when an identity tries to assert as = itself?<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">e.g: = uid=3Dauth,ou=3Dsvcs,cn=3Dauth >--idassert--> = uid=3Dauth,ou=3Dsvcs,cn=3Dauth by<br></blockquote><blockquote = type=3D"cite">means<br></blockquote><blockquote type=3D"cite">of the = idassert-authz=46rom parameter, which authorizes the entire = subtree<br></blockquote><blockquote = type=3D"cite">in<br></blockquote><blockquote type=3D"cite">which this = account resides.  Again, just a hunch = ...<br></blockquote><br></div></blockquote><blockquote = type=3D"cite"><div>I had it working auth'ing both as idassert's "binddn" = and as another user<br>within the allowed = subtree.<br><br></div></blockquote><div><br></div><div>In general, a = page should exist on <a href=3D"http://openldap.org">openldap.org</a> = that details, in full, the debugging/core dump process and best = practices. </div><div><br></div><blockquote type=3D"cite"><div>Please= improve the report and feed back.<br><font class=3D"Apple-style-span" = color=3D"#000000"><font class=3D"Apple-style-span" = color=3D"#144FAE"><br></font></font></div></blockquote><blockquote = type=3D"cite"><div>p.<br><br></div></blockquote></div><br></div></body></h= tml>= --Apple-Mail-1--155291042--

1 0

Re: (ITS#6455) Able to crash slapd while using back_ldap
by masarati＠aero.polimi.it 17 Jan '10

17 Jan '10

Apart from some changes, I can't reproduce. See comments below. > Full_Name: J > Version: 2.4.20 > OS: Debian-Lenny/amd64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (68.15.14.98) > > > Host running Debian Lenny amd64 is experiencing a strange issue. slapd is > segfaulting for no obvious reason. Syslog output: > > Jan 15 19:29:59 ldapc1 kernel: [10702.262741] slapd[3218]: segfault at 40 > ip > 7fb2b4829875 sp 44d90940 error 4 in > back_ldap-2.4.so.2.5.3[7fb2b4819000+1f000] This is not a useful bug report. You should rather follow instructions here <http://www.openldap.org/faq/data/cache/56.html> and provide useful information. A stack backtrace is essentially mandatory. Also, details about the DIT and the exact offending operations would be of help. > We are running slapd 2.4.20, via this config: > > include /etc/ldap/schema/core.schema > include /etc/ldap/schema/cosine.schema > include /etc/ldap/schema/nis.schema > include /etc/ldap/schema/inetorgperson.schema > > pidfile /var/run/slapd/slapd.pid > argsfile /var/run/slapd/slapd.args > > disallow bind_anon > > loglevel 0 > sizelimit 999999 > idletimeout 10 > > modulepath /usr/lib/ldap > moduleload back_ldap > moduleload back_hdb > moduleload pcache > > TLSCertificateFile /etc/ldap/ssl/wildcard.crt > TLSCertificateKeyFile /etc/ldap/ssl/wildcard.key > TLSCACertificateFile /etc/ldap/ssl/wildcard.pem > > database ldap > uri ldaps://192.168.1.1:636/ > suffix "ou=svcs,cn=auth" > rootdn "uid=slapd,ou=svcs,cn=auth" I note that "cn=auth" should not be used, as this naming context is used internally for SASL identities. > idassert-bind > bindmethod=simple > binddn="uid=auth,ou=svcs,cn=auth" > credentials="password" > mode=none > idassert-authzFrom "dn.subtree:ou=svcs,cn=auth" > > ### For some reason, we can no longer use indexes like we could in slapd > 2.3 > ### while using back_ldap (uncommenting these will present slapd from > starting). > > #index objectClass eq > #index uid,mail,cn eq,sub > #index queryid eq 2.4 is pickier about syntax. "index" has no meaning within back-ldap. In 2.3 unrecognized keywords were plainly ignored. > overlay pcache > proxycache hdb 1000 1 50 1200 > directory "/var/lib/ldap" > proxycachequeries 100 > proxyattrset 0 uid mail cn > proxytemplate (uid=) 0 600 > > include /etc/ldap/acls.slapd > > ########## > > > My hunch, given ITS #6452 (which I remarked was "solved"), is that id > assertion > may cause slapd to crash when an identity tries to assert as itself? > > e.g: uid=auth,ou=svcs,cn=auth >--idassert--> uid=auth,ou=svcs,cn=auth by > means > of the idassert-authzFrom parameter, which authorizes the entire subtree > in > which this account resides. Again, just a hunch ... I had it working auth'ing both as idassert's "binddn" and as another user within the allowed subtree. Please improve the report and feed back. p.

1 0

Re: (ITS#6455) Able to crash slapd while using back_ldap
by j＠gropefruit.com 16 Jan '10

16 Jan '10

And just for the record, this exact config (the only difference being = the index params were uncommented) was working fine on Debian Etch / = slapd 2.3.x, which we have been using for a very long time, with no ill = effects (certainly nothing like this). We only rebuilt this same box = today with 2.4.20 on Lenny/Amd64. J=

1 0

(ITS#6455) Able to crash slapd while using back_ldap
by j＠gropefruit.com 16 Jan '10

16 Jan '10

Full_Name: J Version: 2.4.20 OS: Debian-Lenny/amd64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (68.15.14.98) Host running Debian Lenny amd64 is experiencing a strange issue. slapd is segfaulting for no obvious reason. Syslog output: Jan 15 19:29:59 ldapc1 kernel: [10702.262741] slapd[3218]: segfault at 40 ip 7fb2b4829875 sp 44d90940 error 4 in back_ldap-2.4.so.2.5.3[7fb2b4819000+1f000] We are running slapd 2.4.20, via this config: include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args disallow bind_anon loglevel 0 sizelimit 999999 idletimeout 10 modulepath /usr/lib/ldap moduleload back_ldap moduleload back_hdb moduleload pcache TLSCertificateFile /etc/ldap/ssl/wildcard.crt TLSCertificateKeyFile /etc/ldap/ssl/wildcard.key TLSCACertificateFile /etc/ldap/ssl/wildcard.pem database ldap uri ldaps://192.168.1.1:636/ suffix "ou=svcs,cn=auth" rootdn "uid=slapd,ou=svcs,cn=auth" idassert-bind bindmethod=simple binddn="uid=auth,ou=svcs,cn=auth" credentials="password" mode=none idassert-authzFrom "dn.subtree:ou=svcs,cn=auth" ### For some reason, we can no longer use indexes like we could in slapd 2.3 ### while using back_ldap (uncommenting these will present slapd from starting). #index objectClass eq #index uid,mail,cn eq,sub #index queryid eq overlay pcache proxycache hdb 1000 1 50 1200 directory "/var/lib/ldap" proxycachequeries 100 proxyattrset 0 uid mail cn proxytemplate (uid=) 0 600 include /etc/ldap/acls.slapd ########## My hunch, given ITS #6452 (which I remarked was "solved"), is that id assertion may cause slapd to crash when an identity tries to assert as itself? e.g: uid=auth,ou=svcs,cn=auth >--idassert--> uid=auth,ou=svcs,cn=auth by means of the idassert-authzFrom parameter, which authorizes the entire subtree in which this account resides. Again, just a hunch ... Thanks J

1 0

Re: (ITS#6454) idassert-bind, etc., assistance
by quanah＠zimbra.com 14 Jan '10

14 Jan '10

--On Thursday, January 14, 2010 8:49 PM +0000 j(a)gropefruit.com wrote: > Full_Name: J > Version: 2.4.20 > OS: Debian/Lenny > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (68.15.14.98) The ITS system is for bug reports, not help with usage. I don't see any evidence here you are reporting a bug. Please use the openldap-software(a)openldap.org list if you have questions on how to set up and configure OpenLDAP. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6454) idassert-bind, etc., assistance
by j＠gropefruit.com 14 Jan '10

14 Jan '10

Full_Name: J Version: 2.4.20 OS: Debian/Lenny URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (68.15.14.98) Is there any way to use the idassert feature ONLY for anonymous connections, while allowing all other binddns to be directly proxied as themselves? I ask because we have root LDAP servers that have ACL configurations that work for our purposes, and we don't want to change them. We also do not allow anonymous binds to our root servers. To be clear, we do not want to change anything whatsoever on our root servers. however, some clients do need to be able to bind anonymously. We're ok with this, as long as anonymous is allowed against LDAP proxies only, and not on our root LDAP servers. This way, we can control what anonymous user sees. I am trying to make the proxy behave in the following ways: * authenticated non-admin Users may bind as themselves, they can see groups, etc., (anything non-confidential) but can only see their own account (we have this one working, but is an essential element of the larger picture) * anonymous users see all of the same non-sensitive material, but no user accounts whatsoever * there are proxybind users in our DIT, one for read-ops and one for write-ops. The writer-proxybind user typically is needed for changing a users' password, etc. The read user is the one that performs lookups for strictly read-only operations. He can see all users. If I set the idassert-bind to the read-only user, then no one can do writes. If i set it to the write-user, then everyone (even those who shouldn't) can do writes (except anonymous, which is good). The understanding I have is that we should be setting the proxy user in slapd's proxy config to be the highest-privileged user that we're ok with being "asserted". For example, we're not asserting to the rootdn or anything, rather we assert to a bind user that is designed to read the very information that the proxy is designed to lookup. Here is our running config, though its been hacked up so much you should understand its probably not perfect around the edges. Also ignore the comments as they haven't been updated with the rest of the real parameters. PS - I tried to upload as anonymous to your ftp and got this: local: j-gropefruit-100114.txt remote: j-gropefruit-100114.txt 229 Entering Extended Passive Mode (|||60518|) 553 j-gropefruit-100114.txt: Permission denied. So you'll just have to read it here: include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/misc.schema include /etc/ldap/schema/openldap.schema include /etc/ldap/schema/duaconf.schema include /etc/ldap/schema/dyngroup.schema include /etc/ldap/schema/ppolicy.schema include /etc/ldap/schema/sudo.schema include /etc/ldap/schema/dhcp.schema include /etc/ldap/schema/samba.schema include /usr/share/doc/libpam-ldap/ldapns.schema include /etc/ldap/schema/hdb.schema include /etc/ldap/schema/uber.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel stats stats2 conns parse idletimeout 0 sizelimit unlimited timelimit unlimited defaultsearchbase dc=fake,dc=example,dc=com limits dn.regex="^uid=([^,]+).,cn=plain,*" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited access to dn.base="" by * read access to dn.base="cn=Subschema" by * read ## Load modules here modulepath /usr/lib/ldap moduleload back_relay moduleload back_ldap moduleload back_hdb moduleload pcache moduleload rwm.la ## SSL/TLS TLSCertificateFile /etc/ldap/ssl/wildcard.fake.example.com.crt TLSCertificateKeyFile /etc/ldap/ssl/wildcard.fake.example.com.key TLSCACertificateFile /etc/ldap/ssl/wildcard.fake.example.com.pem ## This is for SASL/GSSAPI authentication sasl-realm FAKE.EXAMPLE.COM sasl-host ds-fake-int.fake.example.com authz-regexp "uid=$.*$,cn=FAKE.EXAMPLE.COM,cn=gssapi,cn=auth" "uid=$1,cn=plain,cn=auth,dc=real,dc=example,dc=com" authz-regexp "uid=$.*$,cn=DEV.EXAMPLE.COM,cn=gssapi,cn=auth" "uid=$1,cn=plain,cn=auth,cn=dev,dc=real,dc=example,dc=com" ## Define the actual 'database', as referenced by the suffix. database ldap uri ldaps://10.9.8.7:636/ suffix "dc=real,dc=example,dc=com" rootdn "uid=rootdn,cn=plain,cn=auth,dc=real,dc=example,dc=com" overlay rwm rwm-rewriteEngine on # all dataflow from server to client rwm-rewriteContext searchEntryDN rwm-rewriteRule "(.+,)?dc=real,dc=example,dc=com$" "$1dc=fake,dc=example,dc=com" ## When proxying information, configure what identity to assert. #acl-bind # bindmethod="simple" # binddn="uid=plainproxy,cn=plain,cn=auth,dc=real,dc=example,dc=com" # credentials="pass" # starttls="no" # tls_reqcert="never" idassert-bind bindmethod="simple" binddn="uid=plainchange,cn=plain,cn=auth,dc=real,dc=example,dc=com" credentials="pass" starttls="no" tls_reqcert="never" mode="legacy" flags="override,non-prescriptive" idassert-authzFrom "dn.subtree:cn=plain,cn=auth,dc=real,dc=example,dc=com" idassert-authzFrom "dn.subtree:cn=plain,cn=auth,dc=real,dc=example,dc=com" idassert-authzFrom "dn.exact:" chase-referrals NO rebind-as-user NO ## Cache data for PERFORMANCE - this only works when the upstream proxy ## is online. There's no way to cache data in its entirety if the provider ## goes down (that's what actual replication is for). overlay pcache proxycache hdb 2000 5 100 1800 directory "/var/lib/ldap/cache" dbconfig set_cachesize 0 4097152 0 dbconfig set_lg_regionmax 1048576 dbconfig set_lg_max 1048576 dbconfig set_lg_dir /var/lib/ldap/cache dbconfig set_tmp_dir /tmp index uid,cn,sn,givenName eq,sub index uidNumber,gidNumber eq index homeDirectory,loginShell,gecos,objectClass eq proxycachequeries 10000 proxyattrset 0 uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass proxytemplate (&(objectclass=)(uidNumber=)) 0 1200 proxytemplate (&(objectclass=)(uid=)) 0 1200 proxyattrset 1 objectclass proxytemplate (objectclass=) 1 1200 proxyattrset 2 uid proxytemplate (uid=) 2 1200 proxyattrset 3 cn nisNetgroupTriple memberNisNetgroup proxytemplate (&(objectClass=)(cn=)) 3 1200 proxyattrset 4 gidNumber proxytemplate (&(objectClass=)(memberUid=)) 4 1200 ## Set a global rule to allow everything to our service/proxy users, then forbid ## all others access, but BREAK the rule so it keeps processing the rest of the rules, ## which are all much less-permissive ... access to dn.subtree="dc=real,dc=example,dc=com" by group/groupOfUniqueNames/uniqueMember="cn=ldapadmin,cn=ldap,cn=groups,dc=real,dc=example,dc=com" write by dn.regex="^uid=plain$modify|change$,cn=plain,cn=auth,dc=real,dc=example,dc=com" write by dn.regex="^uid=plain$proxy|agent$,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by * none break access to attrs=userPassword by self =w by * =x ## OMFGZZZZ the Solipsism rule - if you touch this I will kill you. ## This fixes the MUST-BIND-AS-SELF logic problem with Sun VDI access to dn.regex="^uid=([^,]+),cn=plain,cn=auth,dc=real,dc=example,dc=com" by dn.base,expand="uid=$1,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by * none break ########## Relay Instance for the "fake" zone database relay suffix dc=fake,dc=example,dc=com relay dc=real,dc=example,dc=com overlay rwm rwm-suffixmassage dc=real,dc=example,dc=com rwm-rewriteEngine on rwm-normalize-mapped-attrs yes rwm-rewriteContext searchAttrDN rwm-rewriteRule "(.+,)?dc=real,dc=example,dc=com$" "$1dc=fake,dc=example,dc=com" access to dn.subtree="dc=fake,dc=example,dc=com" by group/groupOfUniqueNames/uniqueMember="cn=ldapadmin,cn=ldap,cn=groups,dc=real,dc=example,dc=com" write by dn.exact="uid=plainchange,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainmodify,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainproxy,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainagent,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by * none break access to dn.children="cn=plain,cn=auth,dc=fake,dc=example,dc=com" attrs=userPassword filter=(&(uid=*)(|(objectClass=posixAccount)(objectClass=simpleSecurityObject)(objectClass=shadowAccount)(objectClass=inetOrgPerson)(objectClass=account))) by self write by dn.exact="uid=plainchange,cn=plain,cn=auth,dc=real,dc=example,dc=com" write by dn.exact="uid=plainmodify,cn=plain,cn=auth,dc=real,dc=example,dc=com" write by anonymous auth by * none break access to dn.children="cn=plain,cn=auth,dc=fake,dc=example,dc=com" filter=(&(uid=*)(|(objectClass=posixAccount)(objectClass=simpleSecurityObject)(objectClass=shadowAccount)(objectClass=inetOrgPerson)(objectClass=account))) by self read by dn.exact="uid=plainchange,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainmodify,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainproxy,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainagent,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by * none break access to dn.subtree="cn=groups,dc=fake,dc=example,dc=com" filter=(|(objectClass=posixGroup)(objectClass=nisNetgroup)(objectClass=groupOfUniqueNames)(objectClass=groupOfNames)(objectClass=organizationalRole)) by dn.exact="uid=plainmodify,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainchange,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainagent,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainproxy,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by anonymous read by * none break access to dn.onelevel="cn=gssapi,cn=auth,dc=fake,dc=example,dc=com" by dn="uidNumber=0+gidNumber=0,cn=peercred,cn=external,cn=auth" read by * none break access to dn.onelevel="cn=FAKE.EXAMPLE.COM,cn=gssapi,cn=auth,dc=fake,dc=example,dc=com" by dn="uidNumber=0+gidNumber=0,cn=peercred,cn=external,cn=auth" write by * none break access to dn.subtree="cn=sys,dc=fake,dc=example,dc=com" by * read access to dn.subtree="cn=tester,dc=fake,dc=example,dc=com" by * read access to dn.subtree="cn=dev,dc=fake,dc=example,dc=com" by * none access to dn.subtree="cn=elements,dc=fake,dc=example,dc=com" by * none The man pages and examples on OL.org have helped tremendously, but I need some living & breathing opinions. Thanks J

1 0

Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by rein＠OpenLDAP.org 14 Jan '10

14 Jan '10

On 13.01.2010 14:30, alinachegalati(a)yahoo.com wrote: > Spam detection software, running on the system "boole.openldap.org", has > identified this incoming email as possible spam. The original message > has been attached to this so you can view it (if it isn't spam) or label > similar future email. If you have any questions, see > The administrator of that system for details. > > Content analysis details: (5.2 points, 5.0 required) > > pts rule name description > ---- ---------------------- -------------------------------------------------- > 3.4 FH_DATE_PAST_20XX The date is grossly in the future. This is a broken spamassassin rule, it believes that the year 2010 is in the future. Run sa-update (if it works), or add to spamassassins local.cf: score FH_DATE_PAST_20XX 0 Rein

2 1

Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by alinachegalati＠yahoo.com 13 Jan '10

13 Jan '10

--0-1551663707-1263389393=:13367 Content-Type: text/plain; charset=us-ascii Workaround : count the number of timeouts per ldap connection and unbind it when it reaches a certain threshold (1000 for example). --0-1551663707-1263389393=:13367 Content-Type: text/html; charset=us-ascii <table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Workaround : count the number of timeouts per ldap connection and unbind it when it reaches a certain threshold (1000 for example).<br></td></tr></table><br> --0-1551663707-1263389393=:13367--

1 0

Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by alinachegalati＠yahoo.com 13 Jan '10

13 Jan '10

--0-1599667706-1263381171=:58734 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Aditional Information : Note that the ldap connection is not un-binded, it = is simply returned to a connection pool. --- On Wed, 1/13/10, openldap-its(a)OpenLDAP.org <openldap-its(a)OpenLDAP.org> = wrote: From: openldap-its(a)OpenLDAP.org <openldap-its(a)OpenLDAP.org> Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT To: alinachegalati(a)yahoo.com Date: Wednesday, January 13, 2010, 3:05 AM *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System.=A0 Your report has been assigned the tracking number ITS#6453. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers.=A0 They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message.=A0 Note that any mail sent to openldap-its(a)openldap.org with (ITS#6453) in the subject will automatically be attached to the issue report. =A0=A0=A0 mailto:openldap-its@openldap.org?subject=3D(ITS#6453) You may follow the progress of this report by loading the following URL in a web browser: =A0 =A0 http://www.OpenLDAP.org/its/index.cgi?findid=3D6453 Please remember to retain your issue tracking number (ITS#6453) on any further messages you send to us regarding this report.=A0 If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. =A0=A0=A0 http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. =0A=0A=0A --0-1599667706-1263381171=:58734 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"= top" style=3D"font: inherit;">Aditional Information : Note that the ldap co= nnection is not un-binded, it is simply returned to a connection pool.<br><= br>--- On <b>Wed, 1/13/10, openldap-its(a)OpenLDAP.org <i><openldap-its@Op= enLDAP.org></i></b> wrote:<br><blockquote style=3D"border-left: 2px soli= d rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: openlda= p-its(a)OpenLDAP.org <openldap-its(a)OpenLDAP.org><br>Subject: Re: (ITS#6= 453) OpenLDAP memory leak on LDAP_TIMEOUT<br>To: alinachegalati(a)yahoo.com<b= r>Date: Wednesday, January 13, 2010, 3:05 AM<br><br><div class=3D"plainMail= "><br>*** THIS IS AN AUTOMATICALLY GENERATED REPLY ***<br><br>Thanks for yo= ur report to the OpenLDAP Issue Tracking System.  Your<br>report has b= een assigned the tracking number ITS#6453.<br><br>One of our support engine= ers will look at your report in due course.<br>Note that this may take some= time because our support engineers<br>are volunteers.  They only work on O= penLDAP when they have spare<br>time.<br><br>If you need to provide additio= nal information in regards to your<br>issue report, you may do so by replyi= ng to this message.  Note that<br>any mail sent to <a ymailto=3D"mailt= o:openldap-its@openldap.org" href=3D"/mc/compose?to=3Dopenldap-its@openldap= .org">openldap-its(a)openldap.org</a> with (ITS#6453)<br>in the subject will = automatically be attached to the issue report.<br><br>    ma= ilto:<a ymailto=3D"mailto:openldap-its@openldap.org" href=3D"/mc/compose?to= =3Dopenldap-its(a)openldap.org">openldap-its(a)openldap.org</a>?subject=3D(ITS#= 6453)<br><br>You may follow the progress of this report by loading the foll= owing<br>URL in a web browser:<br>    <a href=3D"http://www.OpenL= DAP.org/its/index.cgi?findid=3D6453" target=3D"_blank">http://www.OpenLDAP.= org/its/index.cgi?findid=3D6453</a><br><br>Please remember to retain your i= ssue tracking number (ITS#6453)<br>on any further messages you send to us regarding this= report.  If<br>you don't then you'll just waste our time and yours be= cause we<br>won't be able to properly track the report.<br><br>Please note = that the Issue Tracking System is not intended to<br>be used to seek help i= n the proper use of OpenLDAP Software.<br>Such requests will be closed.<br>= <br>OpenLDAP Software is user supported.<br>    <a href=3D"h= ttp://www.OpenLDAP.org/support/" target=3D"_blank">http://www.OpenLDAP.org/= support/</a><br><br>--------------<br>Copyright 1998-2007 The OpenLDAP Foun= dation, All Rights Reserved.<br><br></div></blockquote></td></tr></table><b= r>=0A=0A --0-1599667706-1263381171=:58734--

1 0

(ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by alinachegalati＠yahoo.com 13 Jan '10

13 Jan '10

Full_Name: Alin Vasile Version: 2.4.19 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.7) Hi, We have a memory leak LDAP_TIMEOUT is encountered on ldap_search_ext_invocation and we are unable to determine if it is related to OpenLdap or not. The following summarizes our code in case the LDAP_TIMEOUT response is returned : LDAPMessage *res ; // acquire connection // perform search if(rc == LDAP_TIMEOUT) { ldap_msgfree(res); // return connection } Is ldap_msgfree(res) enough in this case ? We tested our program by enabling a low timeout and hence all ldap calls resulting in timeout. The memory leak is about 9 Megs in several minutes, at a load of 5 req/ sec. dmalloc sees the following not allocated pointers 6642692 bytes : Line 640 of "io.c" starts at address 0xff2659c4 <ber_get_next+468> and ends at 0xff2659cc <ber_get_next+476>. 2019876 bytes : Line 277 of "memory.c" starts at address 0xff26676c <ber_memcalloc_x+132> and ends at 0xff266774 <ber_memcalloc_x+140>.

1 0

Re: (ITS#6452) Able to crash slapd when using identity assertion
by j＠gropefruit.com 12 Jan '10

12 Jan '10

Nevermind, commented out the following in my relay database config area: rwm-rewriteEngine on rwm-normalize-mapped-attrs yes rwm-rewriteContext searchAttrDN rwm-rewriteRule "(.+,)?dc=example,dc=com$" "$1,dc=public,dc=com" No longer crashes. You may close. J On Jan 12, 2010, at 21:39 , openldap-its(a)OpenLDAP.org wrote: > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#6452. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#6452) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#6452) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=6452 > > Please remember to retain your issue tracking number (ITS#6452) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. >

1 0

(ITS#6452) Able to crash slapd when using identity assertion
by j＠gropefruit.com 12 Jan '10

12 Jan '10

Full_Name: J Version: 2.4.20 OS: Debian-Lenny/amd64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (68.15.14.98) Able to do all necessary identity assertion when using command-line tools (ldapsearch, ldapmodify, etc) against my server. Server is running back_ldap, back_relay, pcache and back_hdb. But when I point one of my test hosts (Debian Lenny) against this seemingly healthy server and I try to login, I get this while running slapd -d -1: [rw] searchEntryDN: "uid=jay,cn=plain,cn=auth,dc=example,dc=com" -> "uid=jay,cn=plain,cn=auth,dc=example,dc=com" slapd: /usr/src/openldap-src-2.4.20/openldap-2.4.20/servers/slapd/entry.c:483: entry_clean: Assertion `e->e_private == ((void *)0)' failed. Aborted Why?

1 0

(ITS#6449) roadmap update
by quanah＠OpenLDAP.org 12 Jan '10

12 Jan '10

Full_Name: Quanah Gibson-Mount Version: NA OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) http://www.openldap.org/software/roadmap.html needs to be updated to note that OpenLDAP 2.3 is no longer maintained, same as 2.2 and prior.

1 0

(ITS#6448) BUS Error on Multi Master Mode
by acirulli＠gmail.com 12 Jan '10

12 Jan '10

Full_Name: Andrea Cirulli Version: 2.4.21 OS: Solaris 9 SPARC URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.77.56.181) Hi, I have setted up two multimasters in mirror mode. After launching in debug mode with -d 16384 once I stop the slapd ( by CTRL+c ) I obtain a bus error. below the analysis of the core: [New Thread 1 (LWP 1)] Loaded symbols for /usr/lib/64//libthread.so.1 warning: Can't read pathname for load map: I/O error. warning: Can't read pathname for load map: I/O error. Core was generated by `libexec/slapd -f etc/openldap/slapd.conf -h ldap://:379 -d 16384'. Program terminated with signal 10, Bus error. #0 0x00000001001fb8f4 in avl_free () (gdb) thread apply all bt full Thread 2 (Thread 1 (LWP 1)): #0 0x00000001001fb8f4 in avl_free () No symbol table info available. #1 0x0000000100185ef0 in ?? () No symbol table info available. #2 0x0000000100185ef0 in ?? () No symbol table info available. Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 1 (LWP 1 ): #0 0x00000001001fb8f4 in avl_free () No symbol table info available. #1 0x0000000100185ef0 in ?? () No symbol table info available. #2 0x0000000100185ef0 in ?? () No symbol table info available. Backtrace stopped: previous frame identical to this frame (corrupt stack?)

1 0

RE: (ITS#6447) Can't compile openldap with --enable-dynamic on solari sparc 10
by Biren.Patel＠directbrands.com 11 Jan '10

11 Jan '10

Please close this issue, it has been resolved. Thanks -----Original Message----- From: openldap-its(a)OpenLDAP.org [mailto:openldap-its@OpenLDAP.org]=20 Sent: Monday, January 11, 2010 10:31 AM To: Patel, Biren - Direct Brands Subject: Re: (ITS#6447) Can't compile openldap with --enable-dynamic on so= lari sparc 10 *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#6447. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. Note that any mail sent to openldap-its(a)openldap.org with (ITS#6447) in the subject will automatically be attached to the issue report. =09mailto:openldap-its@openldap.org?subject=3D(ITS#6447) You may follow the progress of this report by loading the following URL in a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=3D6447 Please remember to retain your issue tracking number (ITS#6447) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. =09http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email=20 ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email=20 ______________________________________________________________________

1 0

Re: (ITS#6444) OpenLDAP 2.5 RoadMap Question
by michael＠stroeder.com 11 Jan '10

11 Jan '10

j(a)gropefruit.com wrote: > Please clarify this statement in your 2.5 roadmap: Any reason why you didn't simply post this to the openldap-software mailing list? > LDAPv3 extensions: > *LDAP Transaction support AFAIK this means implementing draft-zeilenga-ldap-txn http://tools.ietf.org/draft/draft-zeilenga-ldap-txn/ Ciao, Michael.

1 0

Re: (ITS#6444) OpenLDAP 2.5 RoadMap Question
by quanah＠zimbra.com 11 Jan '10

11 Jan '10

--On Wednesday, January 06, 2010 11:49 PM +0000 j(a)gropefruit.com wrote: > Full_Name: J > Version: 2.4.20 > OS: Debian/Lenny-AMD64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (207.67.92.30) > > > Please clarify this statement in your 2.5 roadmap: This is not a bug report. If you have development questions, please send them to openldap-devel(a)openldap.org for discussion. Thanks! This ITS will be closed. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6447) Can't compile openldap with --enable-dynamic on solari sparc 10
by biren.patel＠directbrands.com 11 Jan '10

11 Jan '10

Full_Name: Biren Patel Version: openldap-2.4.19 OS: SPARC Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.223.34.13) I can't compile openldap with option --enable-dynamic on SPARC Solaris 10. Receiving the error provided below. It complies fine without the --enable-dynamic but when complie PHP 5 with ldap, PHP gives me the same error. I have norrowed down to Openldap not able to compile all the libs as dynamic loadable. Please help Using gcc. Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.10/3.4.6/specs Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --enable-shared --enable-languages=c,c++,f77 Thread model: posix gcc version 3.4.6 /bin/sh ../../libtool --mode=link gcc -D_AVL_H -L/usr/local/openssl/lib/ -L/usr/local/BerkeleyDB/lib -L/usr/local/lib/ -R/usr/local/BerkeleyDB/lib -R/usr/local/lib -o apitest apitest.o libldap.la ../../libraries/liblber/liblber.la ../../libraries/liblutil/liblutil.a -lsasl -lssl -lcrypto -lresolv -lgen -lnsl -lsocket gcc -D_AVL_H -o .libs/apitest apitest.o -L/usr/local/openssl/lib/ -L/usr/local/BerkeleyDB/lib -L/usr/local/lib/ ./.libs/libldap.so /u/bpatel/openldap-2.4.21/libraries/liblber/.libs/liblber.so ../../libraries/liblber/.libs/liblber.so ../../libraries/liblutil/liblutil.a -lsasl -lssl -lcrypto -lresolv -lgen -lnsl -lsocket -Wl,--rpath -Wl,/usr/local/openldap/lib -Wl,--rpath -Wl,/usr/local/BerkeleyDB/lib -Wl,--rpath -Wl,/usr/local/lib /usr/ccs/bin/ld: ./.libs/libldap.so: dlclose: invalid version 13 (max 0) ./.libs/libldap.so: could not read symbols: Bad value collect2: ld returned 1 exit status make[2]: *** [apitest] Error 1 make[2]: Leaving directory `/u/bpatel/openldap-2.4.21/libraries/libldap' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/u/bpatel/openldap-2.4.21/libraries' make: *** [all-common] Error 1

1 0

Re: (ITS#6446) Quickstart guide only uses slapd.conf
by gavin.henry＠gmail.com 07 Jan '10

07 Jan '10

Will update. Thanks! On 07/01/2010, quanah(a)openldap.org <quanah(a)openldap.org> wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > The quickstart guide on the OpenLDAP home page only references using > slapd.conf. > It has no references to the new config backend. Since slapd.conf is > deprecated, it would be good to have a quickstart guide that reflected this. > -- Sent from my mobile device http://www.suretecsystems.com/services/openldap/ http://www.suretectelecom.com

1 0

(ITS#6446) Quickstart guide only uses slapd.conf
by quanah＠OpenLDAP.org 07 Jan '10

07 Jan '10

Full_Name: Quanah Gibson-Mount Version: RE24 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) The quickstart guide on the OpenLDAP home page only references using slapd.conf. It has no references to the new config backend. Since slapd.conf is deprecated, it would be good to have a quickstart guide that reflected this.

1 0

(ITS#6445) Duplicate free with back-relay + passwd op
by h.b.furuseth＠usit.uio.no 07 Jan '10

07 Jan '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard HEAD configured with CPPFLAGS=-DSLAP_NO_SL_MALLOC ./run test030-relay with slapd under valgrind Bad frees of op->o_req_ndn.bv_val and op->o_req_dn.bv_val: Invalid slap_sl_free() by 0x4864F1: do_extended (extended.c:187) Address 0xd8853a0 is 0 bytes inside a block of size 62 free'd by 0x487DAC: passwd_extop (passwd.c:321) by 0x486712: fe_extended (extended.c:225) by 0x486491: do_extended (extended.c:180) Invalid slap_sl_free() by 0x486515: do_extended (extended.c:189) Address 0xd8855d0 is 0 bytes inside a block of size 62 free'd by 0x487DFF: passwd_extop (passwd.c:325) by 0x486712: fe_extended (extended.c:225) by 0x486491: do_extended (extended.c:180) The four backtraces are surrounded by: at 0x4A05A31: free (vg_replace_malloc.c:325) by 0x4E707E5: ber_memfree_x (memory.c:152) by 0x4B7157: slap_sl_free (sl_malloc.c:481) <...backtrace above...> by 0x4444F8: connection_operation (connection.c:1109) by 0x444A7D: connection_read_thread (connection.c:1245) by 0x4C1AFE2: ldap_int_thread_pool_wrapper (tpool.c:685)

1 0

(ITS#6444) OpenLDAP 2.5 RoadMap Question
by j＠gropefruit.com 06 Jan '10

06 Jan '10

Full_Name: J Version: 2.4.20 OS: Debian/Lenny-AMD64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (207.67.92.30) Please clarify this statement in your 2.5 roadmap: LDAPv3 extensions: *LDAP Transaction support Do you mean that SyncRepl will actually become legitimately enterprise-class, in that replication will work 100% of the time? Or does this mean transaction support for some other element unrelated to content synchronization? Why I ask: I've opened a few tickets on OpenLDAP in the past, related to replication issues involving multiple multimaster servers with a frontend employed (a hardware load balancer) to control writes. From time to time, it seems as though SyncRepl just "decides" to fail, and gives no indication ANYWHERE as to why. We log all sync activity, and we see no indication that the host is unreachable or down, and we see no performance delays when querying the DSAs manually. * All slapd servers' clocks are perfectly synchronized and are in a common time zone * Of all six multimasters, only two of them actually receive WRITES * All are 2.4.20 on amd64 kernel (Debian Lenny) * We see no discernible improvement when switching from refreshOnly to refreshAndPersist. Replication will work fine for awhile (in the most recent case, it worked for 16 days, having written test records ranging from 1000 to 50000 *repeatedly* without issues) and then just "fail" .... We have ruled out the following: * Bad hardware * slapd Configuration error (have posted our config before) * Firewall timeout issues for cross-site replication (a timeout wouldn't wait 16 days) * Firewall policies between sites (wouldn't cause it to work and then not work). * slapd segfaulting or crashing in some way This behavior is quite lackluster for a business environment and is ultimately insufficient for any legitimate application. As far as I am concerned, the results are so unbelievably inconsistent that this is an affront to the way SyncRepl is represented/advertised. If it NEVER worked at all, at least THAT would be consistent. SyncRepl rarely makes any valid attempt to "sync up" when differences are detected between DSAs - SOMETIMES it feels like it, most of the time it does not. I hate to say it, but SyncRepl is a huge pile of misrepresentation and broken promises. So: Is transaction support intended to SOLVE these issues? If not, maybe you should invent something to replace SyncRepl altogether. J

1 0

Re: (ITS#6443) test022-ppolicy failure
by hyc＠symas.com 06 Jan '10

06 Jan '10

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.4.21 > OS: CentOS 5.4 > URL: https://www.nbcs.rutgers.edu/~richton/openldap-testfail-20100106.tar.bz2 > Submission from: (NULL) (128.6.31.135) > > > During CentOS 5 x86_64 RPM build using the Buchan specfile: > >>>>>> Starting test022-ppolicy for bdb... > running defines.sh > Starting slapd on TCP/IP port 9065... > Using ldapsearch to check that slapd is running... > Using ldapadd to populate the database... > Testing account lockout... > Waiting 20 seconds for lockout to reset... > Testing password expiration > Waiting 20 seconds for password to expire... > Password expiration test failed >>>>>> ./scripts/test022-ppolicy failed for bdb (exit 1) > > and then everything exited clean. testrun directory attached. > > This is not reproducible; a subsequent rebuild from the same specfile on the > same hardware finished clean. Given that these expiration tests are timing dependent, not sure there's anything real to track down here. -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs