- openldap-bugs - openldap.org

Re: (ITS#6457) hiding remote attribute with rwm-map in relay context crashes server
by masarati＠aero.polimi.it 18 Jan '10

18 Jan '10

> Full_Name: Guillaume Rousse > Version: 2.4.21 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.55.250.67) > > The following configuration is supposed to map remote 'homePhone' > attribute to > 'telephoneNumber', and hide remote 'telephoneNumber' attribute: > > database relay > suffix ou=telephony,dc=test > overlay rwm > rwm-suffixmassage ou=users,dc=test > > rwm-map attribute telephoneNumber homePhone > rwm-map attribute telephoneNumber > > However, the server crashes as soon as it has to handle an entry with a > telephoneNumber attribute, as demonstrated with the simple ldif below: > > dn: dc=test > dc: test > objectClass: top > objectClass: domain > > dn: ou=users,dc=test > ou: users > objectClass: top > objectClass: organizationalUnit > > dn: cn=user1,ou=users,dc=test > objectClass: inetOrgPerson > cn: user1 > sn: user1 > > dn: cn=user2,ou=users,dc=test > objectClass: inetOrgPerson > cn: user2 > sn: user2 > telephoneNumber: +33123456789 > > Here is the relevant part of server log, with debugLevel set to trace: > Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: <ou=telephony,dc=test> > Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: <ou=telephony,dc=test>, > <ou=telephony,dc=test> > Jan 18 13:29:58 slapd[12035]: ==> limits_get: conn=1001 op=1 > self="[anonymous]" > this="ou=telephony,dc=test" > Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: <ou=users,dc=test> > Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: <ou=users,dc=test>, > <ou=users,dc=test> > Jan 18 13:29:58 slapd[12035]: => bdb_search > Jan 18 13:29:58 slapd[12035]: bdb_dn2entry("ou=users,dc=test") > Jan 18 13:29:58 slapd[12035]: search_candidates: base="ou=users,dc=test" > (0x00000002) scope=2 > Jan 18 13:29:58 slapd[12035]: => bdb_dn2idl("ou=users,dc=test") > Jan 18 13:29:58 slapd[12035]: <= bdb_dn2idl: id=3 first=2 last=4 > Jan 18 13:29:58 slapd[12035]: => bdb_presence_candidates (objectClass) > Jan 18 13:29:58 slapd[12035]: bdb_search_candidates: id=-1 first=2 last=4 > Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: <ou=telephony,dc=test> > Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: <ou=telephony,dc=test>, > <ou=telephony,dc=test> > Jan 18 13:29:58 slapd[12035]: => send_search_entry: conn 1001 > dn="ou=telephony,dc=test" > Jan 18 13:29:58 slapd[12035]: <= send_search_entry: conn 1001 exit. > Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: > <cn=user1,ou=telephony,dc=test> > Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: > <cn=user1,ou=telephony,dc=test>, <cn=user1,ou=telephony,dc=test> > Jan 18 13:29:58 slapd[12035]: => send_search_entry: conn 1001 > dn="cn=user1,ou=telephony,dc=test" > Jan 18 13:29:58 slapd[12035]: <= send_search_entry: conn 1001 exit. > Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: > <cn=user2,ou=telephony,dc=test> > Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: > <cn=user2,ou=telephony,dc=test>, <cn=user2,ou=telephony,dc=test> > Jan 18 13:29:58 slapd[12035]: => send_search_entry: conn 1001 dn="(null)" Could not reproduce. Apparently, it's something else that's creating hassle. Please provide a stack backtrace. p.

1 0

(ITS#6457) hiding remote attribute with rwm-map in relay context crashes server
by Guillaume.Rousse＠inria.fr 18 Jan '10

18 Jan '10

Full_Name: Guillaume Rousse Version: 2.4.21 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.55.250.67) The following configuration is supposed to map remote 'homePhone' attribute to 'telephoneNumber', and hide remote 'telephoneNumber' attribute: database relay suffix ou=telephony,dc=test overlay rwm rwm-suffixmassage ou=users,dc=test rwm-map attribute telephoneNumber homePhone rwm-map attribute telephoneNumber However, the server crashes as soon as it has to handle an entry with a telephoneNumber attribute, as demonstrated with the simple ldif below: dn: dc=test dc: test objectClass: top objectClass: domain dn: ou=users,dc=test ou: users objectClass: top objectClass: organizationalUnit dn: cn=user1,ou=users,dc=test objectClass: inetOrgPerson cn: user1 sn: user1 dn: cn=user2,ou=users,dc=test objectClass: inetOrgPerson cn: user2 sn: user2 telephoneNumber: +33123456789 Here is the relevant part of server log, with debugLevel set to trace: Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: <ou=telephony,dc=test> Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: <ou=telephony,dc=test>, <ou=telephony,dc=test> Jan 18 13:29:58 slapd[12035]: ==> limits_get: conn=1001 op=1 self="[anonymous]" this="ou=telephony,dc=test" Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: <ou=users,dc=test> Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: <ou=users,dc=test>, <ou=users,dc=test> Jan 18 13:29:58 slapd[12035]: => bdb_search Jan 18 13:29:58 slapd[12035]: bdb_dn2entry("ou=users,dc=test") Jan 18 13:29:58 slapd[12035]: search_candidates: base="ou=users,dc=test" (0x00000002) scope=2 Jan 18 13:29:58 slapd[12035]: => bdb_dn2idl("ou=users,dc=test") Jan 18 13:29:58 slapd[12035]: <= bdb_dn2idl: id=3 first=2 last=4 Jan 18 13:29:58 slapd[12035]: => bdb_presence_candidates (objectClass) Jan 18 13:29:58 slapd[12035]: bdb_search_candidates: id=-1 first=2 last=4 Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: <ou=telephony,dc=test> Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: <ou=telephony,dc=test>, <ou=telephony,dc=test> Jan 18 13:29:58 slapd[12035]: => send_search_entry: conn 1001 dn="ou=telephony,dc=test" Jan 18 13:29:58 slapd[12035]: <= send_search_entry: conn 1001 exit. Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: <cn=user1,ou=telephony,dc=test> Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: <cn=user1,ou=telephony,dc=test>, <cn=user1,ou=telephony,dc=test> Jan 18 13:29:58 slapd[12035]: => send_search_entry: conn 1001 dn="cn=user1,ou=telephony,dc=test" Jan 18 13:29:58 slapd[12035]: <= send_search_entry: conn 1001 exit. Jan 18 13:29:58 slapd[12035]: >>> dnPrettyNormal: <cn=user2,ou=telephony,dc=test> Jan 18 13:29:58 slapd[12035]: <<< dnPrettyNormal: <cn=user2,ou=telephony,dc=test>, <cn=user2,ou=telephony,dc=test> Jan 18 13:29:58 slapd[12035]: => send_search_entry: conn 1001 dn="(null)"

1 0

Re: (ITS#6455) Able to crash slapd while using back_ldap
by h.b.furuseth＠usit.uio.no 18 Jan '10

18 Jan '10

quanah(a)zimbra.com writes: > Building unix software with debugging symbols is basic system > administrator knowledge. There is nothing "openldap" specific about > doing so. Yes, there is, since OpenLDAP uses autoconf, libtool & co with defaults that get in the way of debugging: Openldap 'make install' strips debugging symbols, so you must either run slapd from the source tree or install with 'make install STRIP=:' or something, I don't remember at the moment. Also it helps debugging to remove the optimize option which OpenLDAP uses by default if it can compiler-specific, but with gcc that's ./configure CFLAGS="-g" > I would suggest updating <http://www.openldap.org/faq/data/cache/59.html> > with any information you feel specifically is lacking. I'll make a note to update that one a bit. -- Hallvard

1 0

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

18 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 18 Jan '10

18 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 15 Jan '10

15 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 13 Jan '10

13 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 13 Jan '10

13 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 08 Jan '10

08 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 07 Jan '10

07 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 07 Jan '10

07 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

(ITS#6443) test022-ppolicy failure
by richton＠nbcs.rutgers.edu 06 Jan '10

06 Jan '10

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.

1 0

Re: (ITS#6442) slaptools iteration enhancement
by masarati＠aero.polimi.it 06 Jan '10

06 Jan '10

> masarati(a)aero.polimi.it writes: >> Both changes will cause binary incompatibility; the latter will not >> require to modify custom backends (I've already modified all the >> existing backends, exploiting in most cases the new feature; in >> back-bdb there is room for minimal improvement, as DN lookahead is >> relatively straightforward, so if base/scope is defined, but no >> filter, some advantages can be expected). > > Could you put them at the end of the tool_globals variable instead? > Then the binary incompatibility will only be in tool_globals, not in the > backend structure. I suppose this variant makes a bit a mess for glue > if nothing else - I assume it would need to to save/modify/restore such > global parameters. Slap tools could accept these parameters only for > backends which which set a flag to say they handle them. > > Might even put them in a mostly empty Operation in tool_globals. Some > backends may be able to reuse existing Search code that way, and other > search-like parameters could be added later if we want. However that > introduces incompatibility after all, so maybe that's for RE25. > '#define tv_sub_ndn tv_op.o_req_ndn' can handle source code compat. I don't think we'll ever need more than a subtree specification. In any case, I think passing those parameters as args rather than as global variables makes more sense. First of all, if you look at the patches, <ftp://ftp.openldap.org/incoming/slaptools-opt1.patch> <ftp://ftp.openldap.org/incoming/slaptools-opt2.patch> backglue is sort of a nightmare. And it doesn't deal yet with gluing backends that only support one of the methods. Second, I'd prefer backends not to know about tool global variables, for basic data isolation. Take it any way 'round, binary incompatibility arises. Option 2 avoids source incompatibility, that's basically what we need. I find it utopistic to expect binary compatibility within the whole life of a minor release. We never guaranteed that, although we tried to preserve it. p.

1 0

Re: (ITS#6442) slaptools iteration enhancement
by h.b.furuseth＠usit.uio.no 06 Jan '10

06 Jan '10

masarati(a)aero.polimi.it writes: > Both changes will cause binary incompatibility; the latter will not > require to modify custom backends (I've already modified all the > existing backends, exploiting in most cases the new feature; in > back-bdb there is room for minimal improvement, as DN lookahead is > relatively straightforward, so if base/scope is defined, but no > filter, some advantages can be expected). Could you put them at the end of the tool_globals variable instead? Then the binary incompatibility will only be in tool_globals, not in the backend structure. I suppose this variant makes a bit a mess for glue if nothing else - I assume it would need to to save/modify/restore such global parameters. Slap tools could accept these parameters only for backends which which set a flag to say they handle them. Might even put them in a mostly empty Operation in tool_globals. Some backends may be able to reuse existing Search code that way, and other search-like parameters could be added later if we want. However that introduces incompatibility after all, so maybe that's for RE25. '#define tv_sub_ndn tv_op.o_req_ndn' can handle source code compat. -- Hallvard

1 0

(ITS#6442) slaptools iteration enhancement
by masarati＠aero.polimi.it 06 Jan '10

06 Jan '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.149.38.230) Submitted by: ando I've modified bi_tool_entry_first(), the call that initiates an iteration in slaptools, to allow to pass a subtree, a scope and a filter. This allows backends to only return IDs of entries that meet the specification. Currently, slapcat and slapschema can do this check downstream. This makes sense with most backends, significantly with back-bdb/hdb. However, other backends, like back-ndb and back-sql, and custom or private ones, may be able to exploit this information. I have two variants: one adds three arguments to bi_tool_entry_first(), thus breaking existing custom backends. The other adds a new call bi_tool_entry_first_x(), leaving the existing one untouched. Both changes will cause binary incompatibility; the latter will not require to modify custom backends (I've already modified all the existing backends, exploiting in most cases the new feature; in back-bdb there is room for minimal improvement, as DN lookahead is relatively straightforward, so if base/scope is defined, but no filter, some advantages can be expected). I'd be happy to receive further comments before I proceed with the commit. p.

1 0

Re: (ITS#6411) Possible bug in Overlay pPolicy
by jarbas.junior＠gmail.com 06 Jan '10

06 Jan '10

Please close this its. In 2.4.21 Version works fine. Tanks Jarbas 2009/12/3 Jarbas Peixoto J=FAnior <jarbas.junior(a)gmail.com>: > Attached to the configuration file server testing openldap squeeze. > > I made some changes to the file /etc/ldap/slapd.overlay.conf being > included by /etc/ldap/slapd.conf and discovered that the problem is > with the overlay rwm, because when I comment that overlay the problem > does not appear. > > If I keep the following entries rwm overlay the problem happen again: > > moduleload rwm > overlay rwm > > Even with the other settings overlay rwm commented the problem continues. > > Any ideas? > > > 2009/12/2 Howard Chu <hyc(a)symas.com>: >> jarbas.junior(a)gmail.com wrote: >>> >>> Full_Name: Jarbas Peixoto Junior >>> Version: 2.4.11 / 2.4.17 / 2.4.20 >>> OS: Gnu/Linux Debian >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (200.152.34.143) >>> >>> >>> Possible bug in Overlay pPolicy >>> >>> I have OpenLDAP installed via the Debian Lenny package functioning >>> normally. >>> >>> Aiming to test the version of Debian Squeeze in the test machine instal= led >>> package slapd (2.4.17-2.1) with the same set of Debian Lenny (2.4.11). >>> >>> However, when testing the overlay pPolicy noticed that a wrong password >>> authentication, runs all objects in the ldap database, causing a "delay= " >>> that >>> does not exist in version Lenny. >>> >>> Below is some information that may be useful in detecting the problem: >>> >>> File: slapd.conf >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> moduleload =A0 =A0 =A0ppolicy >>> overlay ppolicy >>> ppolicy_default >>> "cn=3Ddefault,ou=3DLdapPassword,ou=3DPoliticas,ou=3DBuiltin,dc=3Dprevid= encia,dc=3Dgov,dc=3Dbr" >>> ppolicy_use_lockout >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> ldapsearch -LLL -x -H ldap://squeeze -b >>> ou=3DLdapPassword,ou=3DPoliticas,ou=3DBuiltin,dc=3Dprevidencia,dc=3Dgov= ,dc=3Dbr >>> '(cn=3Ddefault)' >>> dn: >>> cn=3Ddefault,ou=3DLdapPassword,ou=3DPoliticas,ou=3DBuiltin,dc=3Dprevide= ncia,dc=3Dgov,d >>> =A0c=3Dbr >>> objectClass: top >>> objectClass: device >>> objectClass: pwdPolicy >>> pwdAttribute: userPassword >>> description:: >>> UG9sw610aWNhIGRlIFNlbmhhIERlZmF1bHQgcGFyYSB0b2RvcyB1c3XDoXJpb3M=3D >>> pwdAllowUserChange: TRUE >>> pwdFailureCountInterval: 3600 >>> pwdGraceAuthNLimit: 5 >>> pwdInHistory: 0 >>> pwdLockoutDuration: 60 >>> pwdMaxAge: 7776000 >>> pwdMinAge: 0 >>> pwdMinLength: 6 >>> pwdSafeModify: FALSE >>> pwdCheckQuality: 1 >>> pwdExpireWarning: 600 >>> cn: default >>> pwdMustChange: FALSE >>> pwdMaxFailure: 10 >>> pwdLockout: FALSE >>> >>> date ; ldapsearch -LLL -x -H ldap://squeeze -b >>> ou=3Dusuarios,dc=3Dprevidencia,dc=3Dgov,dc=3Dbr -D >>> uid=3Djarbas.peixoto,ou=3Dpessoas,ou=3Dusuarios,dc=3Dprevidencia,dc=3Dg= ov,dc=3Dbr -w >>> wrong-password '(uid=3Djarbas.peixoto)' cn mail pwdFailureTime >>> pwdAccountLockedTime modifyTimeStamp ; date >>> Qua Dez =A02 16:14:56 AMST 2009 >>> ldap_bind: Invalid credentials (49) >>> Qua Dez =A02 16:15:36 AMST 2009 >>> >>> grep 'access_allowed: search access to' /var/log/debug | wc -l >>> 83714 >>> >>> The question is: why access all entries in LDAP? >> >> Don't know. This would have to be the result of a search operation, but >> there is no search code in ppolicy.c. Since ppolicy cannot be the culpri= t, >> we'll need to see the rest of your config to track down the issue. >> >> -- >> =A0-- Howard Chu >> =A0CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 http://www.symas.com >> =A0Director, Highland Sun =A0 =A0 http://highlandsun.com/hyc/ >> =A0Chief Architect, OpenLDAP =A0http://www.openldap.org/project/ >> >

1 0

(ITS#6441) auxprop_lookup in cyrus-sasl 2.1.24 returns status
by rein＠OpenLDAP.org 06 Jan '10

06 Jan '10

Full_Name: Rein Tollevik Version: CVS HEAD OS: Irrelevant URL: Submission from: (NULL) (2a01:600:0:1:21c:23ff:feab:61cd) Submitted by: rein The upcoming 2.1.24 release of cyrus-sasl have changed the auxprop_lookup plugin from void to returning a status value. A patch that fixes it is coming. Rein Tollevik Basefarm AS

1 0

Re: ITS#6439
by h.b.furuseth＠usit.uio.no 06 Jan '10

06 Jan '10

j(a)gropefruit.com writes: > On Jan 5, 2010, at 12:56 , Hallvard B Furuseth wrote: >> Are they saying it somewhere public? I'm sure there are some OpenLDAP >> things they disagree with (I do too), but on this, RFC 4512 section 5.1 >> is quite clear, not to say loud: >> >> "The root DSE SHALL NOT be included if the client performs a subtree >> search starting from the root." > > I appreciate what you're trying to say, but let me be clear about > something. USERS do not care about RFCs. Yes, that's why I asked where they were saying it, to talk with them directly without you caught in the middle... > Fortunately, I have a solution. I was surgical in whom I was going to > argue with. I chose to argue with SUN and denounce their crappy > software. They too touted RFC this and RFC that. I told them to shove > their RFCs somewhere long and narrow. As a result, they ADMIT that its > wrong and they're going to issue a BACKPORT for my situation. Which > should have been done to begin with. Thank you. -- Hallvard

1 0

Re: (ITS#6439) rootDSE access method question
by j＠gropefruit.com 06 Jan '10

06 Jan '10

ldapclient is also used to initialize system-wide configuration of a = solaris box involving LDAP. You pass it the basic parameters needed to = perform LDAP lookups of users, groups, etc., and it generates the system = configuration. This is the message me and my associates have gathered = after all the reading we have done. (Note: This is also "similar" to the = way RedHat's LDAP configuration tool (system-config-authentication) = works, in that parameters are passed from the command line, into a = parser, which then edits files and then initialized the configuration.) Solaris 10's system, even when explicitly told to BIND WITH A PROXY USER = and NOT ANONYMOUSLY, it insists on binding anonymously. --> Our OpenLDAP system does not permit anonymous binds. This is by = design and I will not budge on this. <-- When we try to initialize ldapclient using the automatic config, it = tries to download a profile (which we have ready and waiting in our DIT) = to configure the local system - unfortunately, since its binding = anonymously, this fails. So our remaining option is to use the ldapclient utility with the MANUAL = config option, where we DON'T use a profile, rather we pass the needed = parameters to it manually, on the command line . When we configure this manually and execute the configuration changes, = we see in our slapd logs an attempt to talk to our system looking for = the supportedControl and supportedSASLMechanisms attributes -- which are = only available in the rootDSE. Unfortunately, this process uses every = scope EXCEPT base, which is the only scope that allows rootDSE to be = queried. Furthermore, I got them to admit that the very act of looking for SASL = entries when doing a SIMPLE BIND config is retarded. They agreed. So we have a few issues on Solaris' side: * Superfluous SASL queries, even in SIMPLE config. * Lack of base scope makes rootDSE query impossible * Client insists on binding anonymously, even when told NOT to They have offered to fix these things, I'm waiting on them now ... The important thing is that our slapd config is not to blame, as = everything else in our infrastructure that uses the DS system I built is = working nicely. J Solaris 10's system implicitly tries to perform=20 On Jan 5, 2010, at 15:05 , Howard Chu wrote: > 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) (68.15.14.98) >>=20 >>=20 >> Certain clients (for example, a Solaris 10 host) need to query the = rootDSE of >> our OpenLDAP server. Unfortunately, due to the way their client = software is >> written, the Solaris 10 client will only be able to attempt to view = the rootDSE >> using a scope of ONELEVEL or SUBTREE - it does not support BASELEVEL = searches of >> the rootDSE. >>=20 >> Solaris 10's 'ldapsearch' allows manual querying of our rootDSE for >> testing-purposes, so I know otherwise things should work (ACL-wise, = etc). It >> just seems to be a problem in the system-config, as the man page = clearly states >> that only the two aforementioned scopes are allowed. >>=20 >> Options? Is there a way I can alias a DN-less object? If so, is this = even >> advisable?=20 >>=20 >> Or, perhaps is there a way to store an alternate copy of the rootDSE = somewhere >> that is more "conventionally" accessible? >>=20 >> At this point, I'll consider any alternative. I reviewed the manpage = for >> slapd.conf, however the rootDSE parameter in slapd.conf seems to be = only used >> for "additions" or supplemental changes to an existing rootDSE. >=20 > Since you quoted the ldapclient docs, I have to ask what exactly = you're trying > to accomplish. Solaris ldapclient is only used to configure NSS, and = there are > no NSS tables that serve anything that could be extracted from an LDAP > server's rootDSE. What are you really trying to do? >=20 > --=20 > -- 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#6439) rootDSE access method question
by hyc＠symas.com 06 Jan '10

06 Jan '10

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) (68.15.14.98) > > > Certain clients (for example, a Solaris 10 host) need to query the rootDSE of > our OpenLDAP server. Unfortunately, due to the way their client software is > written, the Solaris 10 client will only be able to attempt to view the rootDSE > using a scope of ONELEVEL or SUBTREE - it does not support BASELEVEL searches of > the rootDSE. > > Solaris 10's 'ldapsearch' allows manual querying of our rootDSE for > testing-purposes, so I know otherwise things should work (ACL-wise, etc). It > just seems to be a problem in the system-config, as the man page clearly states > that only the two aforementioned scopes are allowed. > > Options? Is there a way I can alias a DN-less object? If so, is this even > advisable? > > Or, perhaps is there a way to store an alternate copy of the rootDSE somewhere > that is more "conventionally" accessible? > > At this point, I'll consider any alternative. I reviewed the manpage for > slapd.conf, however the rootDSE parameter in slapd.conf seems to be only used > for "additions" or supplemental changes to an existing rootDSE. Since you quoted the ldapclient docs, I have to ask what exactly you're trying to accomplish. Solaris ldapclient is only used to configure NSS, and there are no NSS tables that serve anything that could be extracted from an LDAP server's rootDSE. What are you really trying to do? -- -- 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#6322) slapd suddenly stops working, and starts using 100% CPU
by quanah＠zimbra.com 05 Jan '10

05 Jan '10

--On Tuesday, January 05, 2010 1:39 PM -0800 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Wednesday, December 30, 2009 1:09 PM +0000 helge(a)monsternett.no > wrote: > >> On Wed, Dec 30, 2009 at 09:04:12AM +0100, Helge Milde wrote: >>> I just enabled trace loglevel, perhaps that might give us a clue on >>> what's going on. >> >> Slapd just stopped working again. Here's the (annotated) log for viewing >> and/or downloading: http://www.pastie.org/761198.txt >> >> Does this give you any clues? >> >> Tell me if I can do anything else to help. > > A fix for this has been committed to HEAD. You can apply it to the > latest source (2.4.21) if you would like to try it out: > > <http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/daemon.c.diff?hid > eattic=1&r1=text&tr1=1.442&r2=text&tr2=1.443&f=u> Hm, correction, it fixes a minor shutdown issue, not your main issue. :/ --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6322) slapd suddenly stops working, and starts using 100% CPU
by quanah＠zimbra.com 05 Jan '10

05 Jan '10

--On Wednesday, December 30, 2009 1:09 PM +0000 helge(a)monsternett.no wrote: > On Wed, Dec 30, 2009 at 09:04:12AM +0100, Helge Milde wrote: >> I just enabled trace loglevel, perhaps that might give us a clue on >> what's going on. > > Slapd just stopped working again. Here's the (annotated) log for viewing > and/or downloading: http://www.pastie.org/761198.txt > > Does this give you any clues? > > Tell me if I can do anything else to help. A fix for this has been committed to HEAD. You can apply it to the latest source (2.4.21) if you would like to try it out: <http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/daemon.c.diff?hideat…> --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: ITS#6439
by j＠gropefruit.com 05 Jan '10

05 Jan '10

--Apple-Mail-21-951114980 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 5, 2010, at 12:56 , Hallvard B Furuseth wrote: > j(a)telepaths.org writes: >> For compatibility reasons, It may well be in OpenLDAP's best interest = to >> provide options such as the ones I described previously, for "broken" = or >> "substandard" clients such as the ones I am using. >=20 I do not program. > If someone (you?) cares enough, they can write an overlay to > the OpenLDAP slapd frontend which intercepts searches with > (baseObject=3D"", scope=3DwholeSubtree) and changes the scope of > the operation to baseObject. That shouldn't be much code. >=20 Thats an interesting idea nonetheless, thanks. > A server using this overlay must not have a database with suffix "", > since this would break subtree searches in that database. >=20 >> I will point out that Solaris 11 doesn't exhibit these issues ---- = But >> my company wants to use Solaris 10, which leaves me in the middle of = a >> finger pointing party between OPENLDAP and SUN. So you can = understand >> why I might be asking for something as strange as this .... >>=20 >> SUN says OpenLDAP's standard/methods are questionable & strange.=20 >> OpenLDAP says Sun's client is broken and that we should hack it. I = say >> screw Solaris 10. >=20 No this is a commercial support issue I am working on. I doubt its being = publicized anywhere. > Are they saying it somewhere public? I'm sure there are some OpenLDAP > things they disagree with (I do too), but on this, RFC 4512 section = 5.1 > is quite clear, not to say loud: >=20 > "The root DSE SHALL NOT be included if the client performs a subtree > search starting from the root." >=20 I appreciate what you're trying to say, but let me be clear about = something. USERS do not care about RFCs. Even some Administrators, = like me, don't care! We are too busy trying to make stuff work, rather = that having a debate with the makers of software as to what rules they = should be following. Fortunately, I have a solution. I was surgical in whom I was going to = argue with. I chose to argue with SUN and denounce their crappy = software. They too touted RFC this and RFC that. I told them to shove = their RFCs somewhere long and narrow. As a result, they ADMIT that its = wrong and they're going to issue a BACKPORT for my situation. Which = should have been done to begin with. Nevertheless, as I said earlier, OpenLDAP (like many other high and = mighty open source systems) should continue to follow RFCs like always. = But it won't kill anyone to offer alternatives that do NOT involve = reaching deep into the bowels of code we don't understand. Even if the = solutions are bizarre, someone out there is wasting hours and hours = trying to make his own solution work, and would be delighted to find = something native had been implemented. > (Onelevel search is not relevant in this context since it wouldn't > return the baseobject anyway.) >=20 Thanks for your input. > --=20 > Hallvard --Apple-Mail-21-951114980 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; = "><br><div><div>On Jan 5, 2010, at 12:56 , Hallvard B Furuseth = wrote:</div><br class=3D"Apple-interchange-newline"><blockquote = type=3D"cite"><div><a href=3D"mailto:j@telepaths.org">j(a)telepaths.org</a> = writes:<br><blockquote type=3D"cite">For compatibility reasons, It may = well be in OpenLDAP's best interest to<br></blockquote><blockquote = type=3D"cite">provide options such as the ones I described previously, = for "broken" or<br></blockquote><blockquote type=3D"cite">"substandard" = clients such as the ones I am = using.<br></blockquote><br></div></blockquote><div><br></div><div>I do = not program.</div><br><blockquote type=3D"cite"><div>If someone (you?) = cares enough, they can write an overlay to<br>the OpenLDAP slapd = frontend which intercepts searches with<br>(baseObject=3D"", = scope=3DwholeSubtree) and changes the scope of<br>the operation to = baseObject.  That shouldn't be much = code.<br><br></div></blockquote><div><br></div><div>Thats an interesting = idea nonetheless, thanks.</div><br><blockquote type=3D"cite"><div>A = server using this overlay must not have a database with suffix = "",<br>since this would break subtree searches in that = database.<br><br><blockquote type=3D"cite">I will point out that Solaris = 11 doesn't exhibit these issues ---- But<br></blockquote><blockquote = type=3D"cite">my company wants to use Solaris 10, which leaves me in the = middle of a<br></blockquote><blockquote type=3D"cite">finger pointing = party between OPENLDAP and SUN.  So you can = understand<br></blockquote><blockquote type=3D"cite">why I might be = asking for something as strange as this ....<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">SUN says = OpenLDAP's standard/methods are questionable & strange. = <br></blockquote><blockquote type=3D"cite">OpenLDAP says Sun's client is = broken and that we should hack it.   I = say<br></blockquote><blockquote type=3D"cite">screw Solaris = 10.<br></blockquote><br></div></blockquote><div><br></div><div>No this = is a commercial support issue I am working on. I doubt its being = publicized anywhere.</div><br><blockquote type=3D"cite"><div>Are they = saying it somewhere public?  I'm sure there are some = OpenLDAP<br>things they disagree with (I do too), but on this, RFC 4512 = section 5.1<br>is quite clear, not to say = loud:<br><br></div></blockquote><blockquote = type=3D"cite"><div>  "The root DSE SHALL NOT be included if = the client performs a subtree<br>   search starting from the = root."<br><font class=3D"Apple-style-span" color=3D"#000000"><font = class=3D"Apple-style-span" = color=3D"#144FAE"><br></font></font></div></blockquote><div><br></div><div= ><div>I appreciate what you're trying to say, but let me be clear about = something.  USERS do not care about RFCs.  Even some = Administrators, like me, don't care! We are too busy trying to make = stuff work, rather that having a debate with the makers of software as = to what rules they should be = following.</div><div><br></div><div>Fortunately, I have a solution. =  I was surgical in whom I was going to argue with. I chose to argue = with SUN and denounce their crappy software.  They too touted RFC = this and RFC that.  I told them to shove their RFCs somewhere long = and narrow.  As a result, they ADMIT that its wrong and they're = going to issue a BACKPORT for my situation.  Which should have been = done to begin with.</div><div><br></div><div>Nevertheless, as I said = earlier, OpenLDAP (like many other high and mighty open source systems) = should continue to follow RFCs like always.  But it won't kill = anyone to offer alternatives that do NOT involve reaching deep into the = bowels of code we don't understand.  Even if the solutions are = bizarre, someone out there is wasting hours and hours trying to make his = own solution work, and would be delighted to find something native had = been implemented.</div><div><br></div></div><blockquote = type=3D"cite"><div>(Onelevel search is not relevant in this context = since it wouldn't<br>return the baseobject = anyway.)<br><br></div></blockquote><div><br></div><div>Thanks for your = input.</div><br><blockquote type=3D"cite"><div>-- = <br>Hallvard<br></div></blockquote></div><br></body></html>= --Apple-Mail-21-951114980--

1 0

Re: ITS#6439
by h.b.furuseth＠usit.uio.no 05 Jan '10

05 Jan '10

j(a)telepaths.org writes: > For compatibility reasons, It may well be in OpenLDAP's best interest to > provide options such as the ones I described previously, for "broken" or > "substandard" clients such as the ones I am using. If someone (you?) cares enough, they can write an overlay to the OpenLDAP slapd frontend which intercepts searches with (baseObject="", scope=wholeSubtree) and changes the scope of the operation to baseObject. That shouldn't be much code. A server using this overlay must not have a database with suffix "", since this would break subtree searches in that database. > I will point out that Solaris 11 doesn't exhibit these issues ---- But > my company wants to use Solaris 10, which leaves me in the middle of a > finger pointing party between OPENLDAP and SUN. So you can understand > why I might be asking for something as strange as this .... > > SUN says OpenLDAP's standard/methods are questionable & strange. > OpenLDAP says Sun's client is broken and that we should hack it. I say > screw Solaris 10. Are they saying it somewhere public? I'm sure there are some OpenLDAP things they disagree with (I do too), but on this, RFC 4512 section 5.1 is quite clear, not to say loud: "The root DSE SHALL NOT be included if the client performs a subtree search starting from the root." (Onelevel search is not relevant in this context since it wouldn't return the baseobject anyway.) -- Hallvard

1 0

Re: ITS#6439
by masarati＠aero.polimi.it 05 Jan '10

05 Jan '10

> =46rom Solaris 10's 'ldapclient' manpage: > > defaultSearchScope=3Done | sub > > Specify the default search scope for the client's search > operations. This default can be overridden for a given > service by specifying a serviceSearchDescriptor. The > default is one level search. > > The parameter 'defaultSearchScope' only allows ONE or SUB. > > The 'serviceSearchDescriptor' is not an option, since this is designed = > to work with NSS objects like 'passwd', 'shadow', 'hosts', etc. rootDSE = > is not a service in that sense, so it won't work here. > > For compatibility reasons, It may well be in OpenLDAP's best interest to = > provide options such as the ones I described previously, for "broken" or = > "substandard" clients such as the ones I am using. > > I will point out that Solaris 11 doesn't exhibit these issues ---- But = > my company wants to use Solaris 10, which leaves me in the middle of a = > finger pointing party between OPENLDAP and SUN. So you can understand = > why I might be asking for something as strange as this .... > > SUN says OpenLDAP's standard/methods are questionable & strange. = > OpenLDAP says Sun's client is broken and that we should hack it. I say = > screw Solaris 10. OpenLDAP may be questionable & strange, I'm not going to debate it. But I pointed you to a RFC that clearly states what's the correct procedure to perform an operation. You're pointing me to the man page of a client that eventually got fixed across releases. If a client can't perform an operation dictated by an RFC, and pretends to do it another way, I'd call that "questionable & strange". > Thank you for your assistance. You can probably close this ticket. :) p.

1 0

Re: ITS#6439
by j＠telepaths.org 05 Jan '10

05 Jan '10

=46rom Solaris 10's 'ldapclient' manpage: defaultSearchScope=3Done | sub Specify the default search scope for the client's search operations. This default can be overridden for a given service by specifying a serviceSearchDescriptor. The default is one level search. The parameter 'defaultSearchScope' only allows ONE or SUB. The 'serviceSearchDescriptor' is not an option, since this is designed = to work with NSS objects like 'passwd', 'shadow', 'hosts', etc. rootDSE = is not a service in that sense, so it won't work here. For compatibility reasons, It may well be in OpenLDAP's best interest to = provide options such as the ones I described previously, for "broken" or = "substandard" clients such as the ones I am using. I will point out that Solaris 11 doesn't exhibit these issues ---- But = my company wants to use Solaris 10, which leaves me in the middle of a = finger pointing party between OPENLDAP and SUN. So you can understand = why I might be asking for something as strange as this .... SUN says OpenLDAP's standard/methods are questionable & strange. = OpenLDAP says Sun's client is broken and that we should hack it. I say = screw Solaris 10. Thank you for your assistance. You can probably close this ticket. J On Jan 5, 2010, at 10:05 , masarati(a)aero.polimi.it wrote: > The behavior you describe violates RFC 4512 (section 5.1), while = OpenLDAP > complies with it. Please note that the root DSE is accessed using a > plain, perfectly legal LDAP operation. The fact a client cannot be > configured to perform such a simple operation clearly indicates the = client > is broken. A quick answer would be "get the client fixed". >=20 > <advertisement> > I can imagine simple workarounds, consisting in few lines of code that > allow to circumvent the issue. They probably require to hire some = expert > consultant. > </advertisement> >=20 > p. >=20

1 0

ITS#6439
by masarati＠aero.polimi.it 05 Jan '10

05 Jan '10

The behavior you describe violates RFC 4512 (section 5.1), while OpenLDAP complies with it. Please note that the root DSE is accessed using a plain, perfectly legal LDAP operation. The fact a client cannot be configured to perform such a simple operation clearly indicates the client is broken. A quick answer would be "get the client fixed". <advertisement> I can imagine simple workarounds, consisting in few lines of code that allow to circumvent the issue. They probably require to hire some expert consultant. </advertisement> p.

1 0

(ITS#6440) slapcat could write info about how it was run in form of LDIF comments
by masarati＠aero.polimi.it 05 Jan '10

05 Jan '10

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.149.38.230) Submitted by: ando Something like # slapcat run by <who>@<host> on <date> ... LDIF of database # number of entries, execution time, file size, ... For backward compatibility, this would need to be enabled by a specific switch. p.

1 0

(ITS#6439) rootDSE access method question
by j＠gropefruit.com 05 Jan '10

05 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) Certain clients (for example, a Solaris 10 host) need to query the rootDSE of our OpenLDAP server. Unfortunately, due to the way their client software is written, the Solaris 10 client will only be able to attempt to view the rootDSE using a scope of ONELEVEL or SUBTREE - it does not support BASELEVEL searches of the rootDSE. Solaris 10's 'ldapsearch' allows manual querying of our rootDSE for testing-purposes, so I know otherwise things should work (ACL-wise, etc). It just seems to be a problem in the system-config, as the man page clearly states that only the two aforementioned scopes are allowed. Options? Is there a way I can alias a DN-less object? If so, is this even advisable? Or, perhaps is there a way to store an alternate copy of the rootDSE somewhere that is more "conventionally" accessible? At this point, I'll consider any alternative. I reviewed the manpage for slapd.conf, however the rootDSE parameter in slapd.conf seems to be only used for "additions" or supplemental changes to an existing rootDSE. Thanks J

1 0

Re: (ITS#6438) usage of invalid mutexint in syncprov
by hyc＠symas.com 05 Jan '10

05 Jan '10

Aaron Richton wrote: > *so = { > s_next = 0x54f778 > s_base = { > bv_len = 0 > bv_val = (nil) > } > s_eid = 2147483967U > s_op = (nil) > s_rid = -34707408 > s_sid = -32897008 > s_filterstr = { > bv_len = 0 > bv_val = (nil) > } > s_flags = 0 > s_inuse = -1 Looks like syncprov_free_syncop() was getting called twice while in the middle of freeing. A potential fix is in HEAD. -- -- 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#6438) usage of invalid mutexint in syncprov
by richton＠nbcs.rutgers.edu 05 Jan '10

05 Jan '10

*so = { s_next = 0x54f778 s_base = { bv_len = 0 bv_val = (nil) } s_eid = 2147483967U s_op = (nil) s_rid = -34707408 s_sid = -32897008 s_filterstr = { bv_len = 0 bv_val = (nil) } s_flags = 0 s_inuse = -1 s_res = 0x523120 s_restail = (nil) s_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 0 __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 82U __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 5392720U } __pthread_mutex_owner64 = 5392720ULL } __pthread_mutex_data = 0 } }

1 0

Re: (ITS#6438) usage of invalid mutexint in syncprov
by hyc＠symas.com 05 Jan '10

05 Jan '10

richton(a)nbcs.rutgers.edu wrote: > Backtrace: https://www.nbcs.rutgers.edu/~richton/openldap-6438-bt.txt So we passed a NULL pointer in here, odd. Thread 5 is the one that crashed; in frame 4 can you print *so ? -- -- 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#6438) usage of invalid mutexint in syncprov
by richton＠nbcs.rutgers.edu 04 Jan '10

04 Jan '10

Backtrace: https://www.nbcs.rutgers.edu/~richton/openldap-6438-bt.txt

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs