openldap-bugs

openldap-bugs@openldap.org

1 participants
20966 discussions

(ITS#5079) Sourious warnings in slapd-bdb/hdb about missing objectClass at add
by ando＠sys-net.it 08 Aug '07

08 Aug '07

Full_Name: Pierangelo Masarati Version: 2.3 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando When adding an entry rooted at "" to a back-bdb/hdb configured for the empty suffix, warnings about the objectClass attribute being missing are issued because a dummy root entry is checked for being an alias, a referral and so. This has already been fixed in HEAD long ago, but apparently, since no ITS was opened, the fix was not backported to 2.3. It is not a showstopper, but it causes annoying spurious warnings to be logged. p.

1 0

Re: (ITS#5073) Syncrepl spinlock
by ando＠sys-net.it 08 Aug '07

08 Aug '07

> Okay, I figured it out -- This is definitely a misconfiguration type > scenario... > > The database is something like: > > database bdb > base "dc=example,dc=com" > > ... > > Then the syncrepl config has: > searchbase="" > > I'm not sure this is something that should be allowed -- where the search > base is broader than the database. I'm not sure either, but in any case this is triggering a bug: an internal search is performed with base "" and scope "sub"; even though the database is configured to serve "dc=example,dc=com", it answers "success" with no data, since it erroneously treats itself as if handling the empty suffix. I think the bug here is that an internal search should never be invoked without making sure whether the base is within the naming context of the database. If the above configuration does not make sense, the check can be done at configuration; otherwise, it needs to be dealt with from within syncrepl_entry(). I vote for the first. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5078) slapd high cpu usage
by marg＠rz.tu-clausthal.de 08 Aug '07

08 Aug '07

Hello, Babu.Suresh(a)pacificlife.com wrote: > bdb_db_open: Warning - No DB_CONFIG file found in directory=20 > Expect poor performance for suffix o=3Dpacificlife.com. Well, slapd even gives you hints for better performance... > <=3D bdb_equality_candidates: (uid) index_param failed (18) > <=3D bdb_equality_candidates: (cn) index_param failed (18) > <=3D bdb_equality_candidates: (uniqueMember) index_param failed (18) Obviously there are some indices missing in the Database. First add configuration for indices cn, uniquemember then re-index/rebuild database. bye Christian -- Christian Marg mail : mailto:marg@rz.tu-clausthal.de Dezernat 2 TU Clausthal web : http://www.tu-clausthal.de D-38678 Clausthal-Zellerfeld fon : 05323/72-2107 Germany jabber: ifcma(a)jabber.tu-clausthal.de

1 0

Re: (ITS#5078) slapd high cpu usage
by ando＠sys-net.it 07 Aug '07

07 Aug '07

Please do not post in HTML. p. Babu.Suresh(a)pacificlife.com wrote: > This is a multi-part message in MIME format. <snip> Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

RE: Re: (ITS#5078) slapd high cpu usage
by Babu.Suresh＠pacificlife.com 07 Aug '07

07 Aug '07

This is a multi-part message in MIME format. ------_=_NextPart_001_01C7D93E.7410BF9A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable OpenLDAP version we are using is - 2.3.32=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DHere is the debug log of one = login=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D bdb_db_open: Warning - No DB_CONFIG file found in directory=20 Expect poor performance for suffix o=3Dpacificlife.com. slapd starting conn=3D0 fd=3D10 ACCEPT from IP=3Dxxxxxxxxx) conn=3D0 op=3D0 BIND dn=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" = method=3D128 conn=3D0 op=3D0 BIND dn=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" = mech=3DSIMPLE ssf=3D0 conn=3D0 op=3D0 RESULT tag=3D97 err=3D0 text=3D conn=3D0 op=3D1 SRCH base=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxxm= "= scope=3D1 deref=3D0 filter=3D"(&(uid=3Dxxxxxxx)(objectClass=3Dperson))" conn=3D0 op=3D1 SRCH attr=3D1.1 <=3D bdb_equality_candidates: (uid) index_param failed (18) conn=3D0 op=3D2 BIND anonymous mech=3Dimplicit ssf=3D0 conn=3D0 op=3D2 BIND dn=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" = method=3D128 conn=3D0 op=3D2 BIND dn=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" = mech=3DSIMPLE ssf=3D0 conn=3D0 op=3D2 RESULT tag=3D97 err=3D0 text=3D conn=3D0 op=3D3 BIND anonymous mech=3Dimplicit ssf=3D0 conn=3D0 op=3D3 BIND dn=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" = method=3D128 conn=3D0 op=3D3 BIND dn=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" = mech=3DSIMPLE ssf=3D0 conn=3D0 op=3D3 RESULT tag=3D97 err=3D0 text=3D conn=3D1 fd=3D12 ACCEPT from IP=3D12.12.1.11:40660 = (IP=3D10.141.1.217:121212) conn=3D1 op=3D0 BIND dn=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" = method=3D128 conn=3D1 op=3D0 BIND dn=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" = mech=3DSIMPLE ssf=3D0 conn=3D1 op=3D0 RESULT tag=3D97 err=3D0 text=3D conn=3D1 op=3D1 SRCH base=3D"ou=3DPeople,ou=3DInternet,o=3Dpacificlife.com"= = scope=3D1 deref=3D0 filter=3D"(&(uid=3Dplevone)(objectClass=3Dperson))" conn=3D1 op=3D1 SRCH attr=3D1.1 <=3D bdb_equality_candidates: (uid) index_param failed (18) conn=3D1 op=3D2 SRCH base=3D"ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" scope=3D1 = deref=3D0 =66ilter=3D"(&(uniqueMember=3Duid=3Dplevone,ou=3Dpeople,ou=3Dinternet,o=3Dp= acificlife. com)(objectClass=3DgroupOfUniqueNames))" conn=3D1 op=3D2 SRCH attr=3Dcn <=3D bdb_equality_candidates: (uniqueMember) index_param failed (18) conn=3D0 op=3D4 SRCH base=3D"ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" scope=3D1 = deref=3D0 =66ilter=3D"(|(&(cn=3Dpresenters)(objectClass=3DgroupOfUniqueNames))(&(cn= =3Dpresen ters)(objectClass=3DgroupOfURLs)))" conn=3D0 op=3D4 SRCH attr=3D1.1 <=3D bdb_equality_candidates: (cn) index_param failed (18) <=3D bdb_equality_candidates: (cn) index_param failed (18) conn=3D0 op=3D5 SRCH base=3D"ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" scope=3D1 = deref=3D0 =66ilter=3D"(&(uniqueMember=3Dcn=3Dpresenters,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxx= xxx)(object Class=3DgroupOfUniqueNames))" conn=3D0 op=3D5 SRCH attr=3Dcn <=3D bdb_equality_candidates: (uniqueMember) index_param failed (18) conn=3D1 op=3D2 SEARCH RESULT tag=3D101 err=3D0 nentries=3D1 text=3D conn=3D0 op=3D4 SEARCH RESULT tag=3D101 err=3D0 nentries=3D1 text=3D conn=3D0 op=3D5 SEARCH RESULT tag=3D101 err=3D0 nentries=3D0 text=3D conn=3D1 op=3D3 SRCH base=3D"ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" scope=3D1 = deref=3D0 =66ilter=3D"(objectClass=3DgroupOfURLs)" conn=3D1 op=3D3 SRCH attr=3Dcn memberURL conn=3D1 op=3D3 SEARCH RESULT tag=3D101 err=3D0 nentries=3D0 text=3D conn=3D1 op=3D1 SEARCH RESULT tag=3D101 err=3D0 nentries=3D1 text=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ---------------------------------------------------------------------------= --- The information in this e-mail and any attachments are for the sole use of = the intended recipient and may contain privileged and confidential = information. If you are not the intended recipient, any use, disclosure, = copying or distribution of this message or attachment is strictly = prohibited. If you believe that you have received this e-mail in error, = please contact the sender immediately and delete the e-mail and all of its = attachments. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D ------_=_NextPart_001_01C7D93E.7410BF9A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 6.5.7651.59"> <TITLE>RE: Re: (ITS#5078) slapd high cpu usage</TITLE> </HEAD> <BODY>  OpenLDAP version we are = using is - 2.3.32 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DHere is the debug log of = one login=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D bdb_db_open: Warning - = No DB_CONFIG file found in directory Expect poor performance= = =66or suffix o=3Dpacificlife.com. slapd starting conn=3D0 fd=3D10 ACCEPT= = =66rom IP=3Dxxxxxxxxx) conn=3D0 op=3D0 BIND = dn=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" = method=3D128 conn=3D0 op=3D0 BIND = dn=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" mech=3DSIMPL= E= ssf=3D0 conn=3D0 op=3D0 RESULT = tag=3D97 err=3D0 text=3D conn=3D0 op=3D1 SRCH = base=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxxm" scope=3D1= = deref=3D0 = =66ilter=3D"(&(uid=3Dxxxxxxx)(objectClass=3Dperson))"<= /P> conn=3D0 op=3D1 SRCH = attr=3D1.1 <=3D = bdb_equality_candidates: (uid) index_param failed (18) conn=3D0 op=3D2 BIND = anonymous mech=3Dimplicit ssf=3D0 conn=3D0 op=3D2 BIND = dn=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" = method=3D128 conn=3D0 op=3D2 BIND = dn=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" mech=3DSIMPL= E= ssf=3D0 conn=3D0 op=3D2 RESULT = tag=3D97 err=3D0 text=3D conn=3D0 op=3D3 BIND = anonymous mech=3Dimplicit ssf=3D0 conn=3D0 op=3D3 BIND = dn=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" = method=3D128 conn=3D0 op=3D3 BIND = dn=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" mech=3DSIMPL= E= ssf=3D0 conn=3D0 op=3D3 RESULT = tag=3D97 err=3D0 text=3D conn=3D1 fd=3D12 ACCEPT= = =66rom IP=3D12.12.1.11:40660 (IP=3D10.141.1.217:121212) conn=3D1 op=3D0 BIND = dn=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" = method=3D128 conn=3D1 op=3D0 BIND = dn=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" mech=3DSIMPL= E= ssf=3D0 conn=3D1 op=3D0 RESULT = tag=3D97 err=3D0 text=3D conn=3D1 op=3D1 SRCH = base=3D"ou=3DPeople,ou=3DInternet,o=3Dpacificlife.com" scope=3D1 = deref=3D0 = =66ilter=3D"(&(uid=3Dplevone)(objectClass=3Dperson))"<= /P> conn=3D1 op=3D1 SRCH = attr=3D1.1 <=3D = bdb_equality_candidates: (uid) index_param failed (18) conn=3D1 op=3D2 SRCH = base=3D"ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" scope=3D1 deref=3D0 = =66ilter=3D"(&(uniqueMember=3Duid=3Dplevone,ou=3Dpeople,ou=3Dinter= net,o=3Dpacificlife.com)(objectClass=3DgroupOfUniqueNames))" conn=3D1 op=3D2 SRCH = attr=3Dcn <=3D = bdb_equality_candidates: (uniqueMember) index_param failed (18) conn=3D0 op=3D4 SRCH = base=3D"ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" scope=3D1 deref=3D0 = =66ilter=3D"(|(&(cn=3Dpresenters)(objectClass=3DgroupOfUniqueNames= ))(&(cn=3Dpresenters)(objectClass=3DgroupOfURLs)))" conn=3D0 op=3D4 SRCH = attr=3D1.1 <=3D = bdb_equality_candidates: (cn) index_param failed (18) <=3D = bdb_equality_candidates: (cn) index_param failed (18) conn=3D0 op=3D5 SRCH = base=3D"ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" scope=3D1 deref=3D0 = =66ilter=3D"(&(uniqueMember=3Dcn=3Dpresenters,ou=3Dxxxxxxx,ou=3Dxx= xx,o=3Dxxxxx)(objectClass=3DgroupOfUniqueNames))" conn=3D0 op=3D5 SRCH = attr=3Dcn <=3D = bdb_equality_candidates: (uniqueMember) index_param failed (18) conn=3D1 op=3D2 SEARCH = RESULT tag=3D101 err=3D0 nentries=3D1 text=3D conn=3D0 op=3D4 SEARCH = RESULT tag=3D101 err=3D0 nentries=3D1 text=3D conn=3D0 op=3D5 SEARCH = RESULT tag=3D101 err=3D0 nentries=3D0 text=3D conn=3D1 op=3D3 SRCH = base=3D"ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" scope=3D1 deref=3D0 = =66ilter=3D"(objectClass=3DgroupOfURLs)" conn=3D1 op=3D3 SRCH = attr=3Dcn memberURL conn=3D1 op=3D3 SEARCH = RESULT tag=3D101 err=3D0 nentries=3D0 text=3D conn=3D1 op=3D1 SEARCH = RESULT tag=3D101 err=3D0 nentries=3D1 text=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D <pre = wrap>----------------------------------------------------------------------= -------- The information in this e-mail and any attachments are for the sole use of = the intended recipient and may contain privileged and confidential = information. If you are not the intended recipient, any use, disclosure, = copying or distribution of this message or attachment is strictly = prohibited. If you believe that you have received this e-mail in error, = please contact the sender immediately and delete the e-mail and all of its = attachments. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D </pre></BODY> </HTML> ------_=_NextPart_001_01C7D93E.7410BF9A--

1 0

Re: (ITS#5078) slapd high cpu usage
by Babu.Suresh＠pacificlife.com 07 Aug '07

07 Aug '07

This is a multi-part message in MIME format. ------_=_NextPart_001_01C7D93C.273C1782 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable thank you Quanah for your quick response. see bellow.. What version of OpenLDAP 2.3=3F -->V2.3.4 Have you configured the DB_CONFIG file=3F -->NO You can still use cachesize whether or not it is restarted nightly. -->will do Have you examined the logs at loglevel 256 to see what kind of searches are being performed, so you can optimize your indices=3F -->yes, we did but I didn't put much attention to this. I will perform again and post the output. thank you ---------------------------------------------------------------------------= --- The information in this e-mail and any attachments are for the sole use of = the intended recipient and may contain privileged and confidential = information. If you are not the intended recipient, any use, disclosure, = copying or distribution of this message or attachment is strictly = prohibited. If you believe that you have received this e-mail in error, = please contact the sender immediately and delete the e-mail and all of its = attachments. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D ------_=_NextPart_001_01C7D93C.273C1782 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 6.5.7651.59"> <TITLE>Re: (ITS#5078) slapd high cpu usage</TITLE> </HEAD> <BODY>  thank you Quanah for your quick = response. see bellow.. What version of OpenLDAP = 2.3=3F -->V2.3.4 Have you configured the DB_CONFIG = =66ile=3F -->NO You can still use cachesize whether= = or not it is restarted nightly. -->will do Have you examined the logs at = loglevel 256 to see what kind of searches are being performed, so you can = optimize your indices=3F -->yes, we did but I didn't put = much attention to this. I will perform again and post the output. thank you <pre = wrap>----------------------------------------------------------------------= -------- The information in this e-mail and any attachments are for the sole use of = the intended recipient and may contain privileged and confidential = information. If you are not the intended recipient, any use, disclosure, = copying or distribution of this message or attachment is strictly = prohibited. If you believe that you have received this e-mail in error, = please contact the sender immediately and delete the e-mail and all of its = attachments. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D </pre></BODY> </HTML> ------_=_NextPart_001_01C7D93C.273C1782--

1 0

Re: (ITS#5078) slapd high cpu usage
by quanah＠zimbra.com 07 Aug '07

07 Aug '07

--On Tuesday, August 07, 2007 6:25 PM +0000 babu.suresh(a)pacificlife.com wrote: > Full_Name: Babu > Version: 2.3 > OS: RedHAT3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.181.11.27) > > > Hello, > > > We are using openldap2.3, BDB 4.5.20 and Rehat3..seeing having high cpu > usage of the slapd process. What version of OpenLDAP 2.3? Have you configured the DB_CONFIG file? You can still use cachesize whether or not it is restarted nightly. Have you examined the logs at loglevel 256 to see what kind of searches are being performed, so you can optimize your indices? In any case, I see no bug here. Please redirect further questions and response to openldap-software(a)openldap.org --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5078) slapd high cpu usage
by babu.suresh＠pacificlife.com 07 Aug '07

07 Aug '07

Full_Name: Babu Version: 2.3 OS: RedHAT3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (198.181.11.27) Hello, We are using openldap2.3, BDB 4.5.20 and Rehat3..seeing having high cpu usage of the slapd process. Tried with bellow indexes, we can't use "cachesize" as we have nightly restart of the process and cache go away (let me know there is way to save cache and it will be available even after restart of slapd); also we have yearly onetime users in our system. Please let me know what are can be done to solve slapd high cpu utilization problem. ====indexes in slapd.conf==== index objectClass eq index uid pres, eq ========= =========CPU usage with 3/4 users concurrent login========= 321 processes: 319 sleeping, 2 running, 0 zombie, 0 stopped CPU states: cpu user nice system irq softirq iowait idle total 28.0% 0.0% 7.8% 0.0% 0.0% 7.9% 56.0% cpu00 47.6% 0.0% 8.9% 0.0% 0.3% 2.3% 40.6% cpu01 32.8% 0.0% 7.7% 0.0% 0.0% 0.7% 58.6% cpu02 19.4% 0.0% 8.1% 0.0% 0.0% 14.1% 58.2% cpu03 12.1% 0.0% 6.5% 0.0% 0.0% 14.5% 66.7% PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND 30973 xxxxx 19 0 148M 148M 2224 R 15.4 3.1 4:44 0 slapd 30975 xxxxx 18 0 148M 148M 2224 S 9.5 3.1 3:51 3 slapd 32030 xxxxxx 19 0 148M 148M 2224 S 7.9 3.1 3:59 1 slapd

1 0

Coredump on ACLs for nonexistent Attributes. Is it a bug?
by Christian Marg 07 Aug '07

07 Aug '07

Hello, I didn't find an ITS concerning what I encountered yesterday: I had ACLs defined for undefined attributes (e.g. a schema file was missing some entries) and slaptest etc. crashed with dumped core. The message I got was: slaptest in free(): error: junk pointer, too high to make sense Abort (core dumped) I'm using v 2.3.34 on FreeBSD 6.2-RELEASE-p3. bye Christian -- Christian Marg mail : mailto:marg@rz.tu-clausthal.de Dezernat 2 TU Clausthal web : http://www.tu-clausthal.de D-38678 Clausthal-Zellerfeld fon : 05323/72-2107 Germany jabber: ifcma(a)jabber.tu-clausthal.de

2 2

Re: Contribution: Active Directory Password Cache (ITS#5042)
by ando＠sys-net.it 07 Aug '07

07 Aug '07

ando(a)sys-net.it wrote: > At this point, it sounds like that your contribution could be > __entirely__ reworked into simply adding caching capabilities into the > current {SASL} password scheme (implemented in servers/slapd/sasl.c), > preserving the logics you're using right now. You'd probably need to > define your own "cachedUserPassword" attribute to temporarily store the > cached credentials, unless something like this: > > userPassword: {SASL}user > userPassword: {<hash>}<hashed password> > > allows the {SASL} module to fetch the next value of the userPassowrd and > treat it as the cached value. The rest would be adding some TTL mech, > configurable via back-config, and that should be it. > > Yet another option would be to allow per-entry caching, by defining a > new {CACHED-SASL} scheme. This way, one could fine-grain decide whose > credentials can be cached and whose can't, letting the two cases share > most of the code. I'd allow {SASL} to be cached as well, in case the > administrator just wants to allow all {SASL} auths to be cached. For this purpose, it might be necessary to change the API of password scheme handling, so that it gets passed a pointer to the entire entry, read-only locked, so that attributes like the "cachedPwd" and the "cachedPwdTimestamp" can be fetched and used. With respect to updating them, we might need to add some means to schedule internal modifications to be performed as soon as the entry lock is released. Thoughts? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs