--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@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@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%22%3Ehttp://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%22%3Eopenldap.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--