- openldap-bugs - openldap.org

Re: (ITS#5382) JLDAP
by rarpit＠novell.com 24 Apr '09

24 Apr '09

--=__PartF5DD40B7.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable hi Jim, We have fixed the issue . We will be checking the same . Thanks for = identifying the issue . =20 regards Arpit=20 =20 --=__PartF5DD40B7.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-15= "> <META content=3D"MSHTML 6.00.2900.3492" name=3DGENERATOR></HEAD> <BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Segoe UI"> <DIV>hi Jim,</DIV> <DIV>    We have fixed the issue . We will be checking the = same . Thanks for identifying the issue .</DIV> <DIV> </DIV> <DIV>regards</DIV> <DIV>Arpit </DIV> <DIV> </DIV></BODY></HTML> --=__PartF5DD40B7.0__=--

1 0

Re: (ITS#5389) Contribution: JLDAP support for password policy response control
by rarpit＠novell.com 24 Apr '09

24 Apr '09

--=__Part133BA653.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable hi Raymond , =20 This is just for my understanding . Is Password Policy response is a = standard ? What is the requirement of this particular feature to be = present in JLDAP? What is this feature and how it can be used ?=20 We can take it in if this is a standard but if this is not a standard = than we cannot take this in as this will make the code bulkier.=20 =20 regards, Arpit=20 --=__Part133BA653.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-15= "> <META content=3D"MSHTML 6.00.2900.3492" name=3DGENERATOR></HEAD> <BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Segoe UI"> <DIV>hi Raymond ,</DIV> <DIV> </DIV> <DIV>   This is just for my understanding . Is Password Policy = response is a standard ? What is the requirement of this particular = feature to be present in JLDAP? What is this feature and how it can be = used ? </DIV> <DIV>   We can take it in if this is a standard but if this is = not a standard than we cannot take this in as this will make the code = bulkier. </DIV> <DIV> </DIV> <DIV>regards, Arpit </DIV></BODY></HTML> --=__Part133BA653.0__=--

1 0

Re: (ITS#6071) LDAP server becomes unresponsive
by carsten.rieck＠trustcenter.de 24 Apr '09

24 Apr '09

Hello, the update to OpenLDAP 2.4.16 has solved my problem with the unresponsive server. Quanah, thank you very much for your help. From my point of view, the ITS can be closed. Best regards, Carsten -- Dr. Carsten T. Rieck Development TC TrustCenter GmbH Sonninstrasse 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40-808026-0, Fax: -126 Geschaeftsfuehrung/Managing Directors: Robert Steinkrauss , Dr. Sabine Kockskaemper , HRB 96168 Email: carsten.rieck(a)trustcenter.de www.trustcenter.de This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies.

1 0

Re: (ITS#6072) slapo-collect: dnLength != dnDepth
by daniel＠pluta.biz 23 Apr '09

23 Apr '09

Michael Ströder schrieb: > daniel(a)pluta.biz wrote: >> I could not find a suitable api-call to determine a DN's depth. > > How about using ldap_bv2dn() and count the DN components? > >> So I've used >> posix regexp and uploaded that quick&dirty hacked patch right here: > > I guess reg ex splitting won't work for arbitrary DN strings. > > Ciao, Michael. I finaly managed to upload the patch under "incoming/collect.c.patch" Instead of using posix regexp I've used the ldap_bv2dn() based methode recommended by you. I would appreciate your revise. This patch does not include slapo-collect's schema-patch that I've filed some minutes ago (see: ITS#6075) Thanks!

1 0

(ITS#6075) slapo-collect: olcCollectInfo: no equality matching rule
by daniel＠pluta.biz 23 Apr '09

23 Apr '09

Full_Name: Daniel Pluta Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/daniel-pluta-090423.patch Submission from: (NULL) (91.12.202.8) It's impossible to delete one value from the multi-valued olcCollectInfo in case there are more than 1 olcCollectInfo values configured... Error: "olcCollectInfo: no equality matching rule" I've uploaded a small patch here: ftp://ftp.openldap.org/incoming/daniel-pluta-090423.patch I'm not sure whether ORDERING and SUBSTRINGMATCH are neccessary, optional or even wrong(?). Perhab's they can (have to?) be omitted - please see below... Index: ldap/servers/slapd/overlays/collect.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays/collect.c,v retrieving revision 1.5.2.8 diff -u -r1.5.2.8 collect.c --- ldap/servers/slapd/overlays/collect.c 22 Jan 2009 00:01:12 -0000 1.5.2.8 +++ ldap/servers/slapd/overlays/collect.c 23 Apr 2009 20:00:02 -0000 @@ -230,6 +230,9 @@ ARG_MAGIC, collect_cf, "( OLcfgOvAt:19.1 NAME 'olcCollectInfo' " "DESC 'DN of entry and attribute to distribute' " + "EQUALITY caseIgnoreMatch " + "ORDERING caseIgnoreOrderingMatch " + "SUBSTR caseIgnoreSubstringsMatch " "SYNTAX OMsDirectoryString )", NULL, NULL }, { NULL, NULL, 0, 0, 0, ARG_IGNORED } };

1 0

Re: (ITS#6073) ftp.openldap.org "no space left on device"?
by daniel＠pluta.biz 23 Apr '09

23 Apr '09

Status update: it has been fixed - proved by me with: ftp> put daniel-pluta-090423.patch local: daniel-pluta-090423.patch remote: daniel-pluta-090423.patch 227 Entering Passive Mode (204,152,186,57,229,234) 150 Opening BINARY mode data connection for 'daniel-pluta-090423.patch'. 226 Transfer complete (unique file name:daniel-pluta-090423.patch). 735 bytes sent in 0.00 secs (413.2 kB/s) Thanks for addressing/solving this issue. Kurt Zeilenga schrieb: > This problem as been addressed. > > -- Kurt > > On Apr 22, 2009, at 7:45 AM, daniel(a)pluta.biz wrote: > >> Full_Name: Daniel Pluta >> Version: HEAD >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2001:4ca0:0:f000:78be:f928:4392:2caf) >> >> >> ~/build/pkg$ ftp -p 204.152.186.57 >> Connected to 204.152.186.57. >> 220- OpenLDAP FTP Service >> 220 boole.openldap.org FTP server (Version 6.00LS) ready. >> Name (204.152.186.57:d): anonymous >> 331 Guest login ok, send your email address as password. >> Password: >> 230- Copyright 1998-2009, The OpenLDAP Foundation, All Rights Reserved. >> 230- COPYING RESTRICTIONS APPLY, see: >> 230- ftp://ftp.openldap.org/COPYRIGHT >> 230- ftp://ftp.openldap.org/LICENSE >> 230 Guest login ok, access restrictions apply. >> Remote system type is UNIX. >> Using binary mode to transfer files. >> ftp> cd incoming >> 250 CWD command successful. >> ftp> put collect.c.patch >> local: collect.c.patch remote: collect.c.patch >> 227 Entering Passive Mode (204,152,186,57,240,13) >> 150 Opening BINARY mode data connection for 'collect.c.patch.3'. >> 452 Error writing to file: No space left on device. >> 1833 bytes sent in 0.00 secs (1361.2 kB/s) >> ftp> >

1 0

Re: (ITS#6074) SEGV in pthread_mutex_lock()
by richton＠nbcs.rutgers.edu 23 Apr '09

23 Apr '09

backtrace: https://www.nbcs.rutgers.edu/~richton/openldap-its6074-bt.txt

1 0

(ITS#6074) SEGV in pthread_mutex_lock()
by richton＠nbcs.rutgers.edu 23 Apr '09

23 Apr '09

Full_Name: Aaron Richton Version: 2.4.16 OS: Solaris 9 URL: Submission from: (NULL) (128.6.31.135) Still going through the logs to see what slapd was doing at the time, but my expectation is "Nothing Particularly Exciting" -- this was under production load, I wasn't poking it with a stick or anything. URI with backtrace to follow...

1 0

Re: (ITS#6072) slapo-collect: dnLength != dnDepth
by daniel＠pluta.biz 23 Apr '09

23 Apr '09

Michael Ströder wrote: >> I could not find a suitable api-call to determine a DN's depth. >> > How about using ldap_bv2dn() and count the DN components? > >> So I've used >> posix regexp and uploaded that quick&dirty hacked patch right here: >> > I guess reg ex splitting won't work for arbitrary DN strings. > Hi Michael, after I've had a quick look into "ldap_bv2dn()" you might be right... ;-) Before I'll try to upload the patch again (see ITS#6073) I'll update my code to include your suggestion. Many thanks for your advice! Cheers Daniel

1 0

Re: (ITS#6072) slapo-collect: dnLength != dnDepth
by daniel＠pluta.biz 23 Apr '09

23 Apr '09

Hallvard B Furuseth wrote: >> DNs should be ordered accoring their in-DIT depth and not accoring their >> bv_len: >> > Does that matter, as long as (child, parent) are ordered correctly? > What is the bug you are fixing? > it's regarding the mentioned "*limited* overlapping feature" within the insert_ordered()-function's comment: cite: "... this means longer dn's (i.e. more specific dn's) will be found first when searching..." But, longer DNs do not neccessarily are more specific: ou=openldap,o=rockz,c=it dc=abcdefghijklmnopqrstuvwxyz,dc=com (even longer but not more specific) BTW: the use of insert_ordered() possibly cause some kind of strange (randomized) deletion of a collect_info config attribute's value in this overlay just in the case: c->type == LDAP_MOD_DELETE combined with c->valx > 1 I've noticed this behaviour during testing of my own (chaotic-)test-overlay but had no time to investigate in deep. In my opinion the effect depends on the order of ldapadds of additional DNs and the effective resulting order produced by insert_ordered in combination with "c->valx"... I would file another ITS in case I'm sure that this impressive effect is not cause by my "chaotic" component. ;-)

1 0

Re: (ITS#6072) slapo-collect: dnLength != dnDepth
by h.b.furuseth＠usit.uio.no 23 Apr '09

23 Apr '09

Daniel Pluta writes: > DNs should be ordered accoring their in-DIT depth and not accoring their > bv_len: Does that matter, as long as (child, parent) are ordered correctly? What is the bug you are fixing? -- Hallvard

1 0

Re: (ITS#6072) slapo-collect: dnLength != dnDepth
by michael＠stroeder.com 23 Apr '09

23 Apr '09

daniel(a)pluta.biz wrote: > I could not find a suitable api-call to determine a DN's depth. How about using ldap_bv2dn() and count the DN components? > So I've used > posix regexp and uploaded that quick&dirty hacked patch right here: I guess reg ex splitting won't work for arbitrary DN strings. Ciao, Michael.

1 0

Re: (ITS#6071) LDAP server becomes unresponsive
by quanah＠zimbra.com 23 Apr '09

23 Apr '09

--On Wednesday, April 22, 2009 7:20 AM +0000 rs1542(a)gmx.com wrote: > Full_Name: Carsten T. Rieck > Version: 2.4.11 > OS: RedHat 5.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.194.157.126) > > > Hello, > > my company runs an anonymously accessible LDAP server on openLDAP 2.4.11 > with Berkeley database 4.6.21 (all recent patches applied) and RedHat 5.1 > as operating system. Please update to OpenLDAP 2.4.16, as the connection code has been significantly reworked, and some issues with using EPOLL have been addressed. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6073) ftp.openldap.org "no space left on device"?
by Kurt＠OpenLDAP.org 23 Apr '09

23 Apr '09

This problem as been addressed. -- Kurt On Apr 22, 2009, at 7:45 AM, daniel(a)pluta.biz wrote: > Full_Name: Daniel Pluta > Version: HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:4ca0:0:f000:78be:f928:4392:2caf) > > > ~/build/pkg$ ftp -p 204.152.186.57 > Connected to 204.152.186.57. > 220- OpenLDAP FTP Service > 220 boole.openldap.org FTP server (Version 6.00LS) ready. > Name (204.152.186.57:d): anonymous > 331 Guest login ok, send your email address as password. > Password: > 230- Copyright 1998-2009, The OpenLDAP Foundation, All Rights > Reserved. > 230- COPYING RESTRICTIONS APPLY, see: > 230- ftp://ftp.openldap.org/COPYRIGHT > 230- ftp://ftp.openldap.org/LICENSE > 230 Guest login ok, access restrictions apply. > Remote system type is UNIX. > Using binary mode to transfer files. > ftp> cd incoming > 250 CWD command successful. > ftp> put collect.c.patch > local: collect.c.patch remote: collect.c.patch > 227 Entering Passive Mode (204,152,186,57,240,13) > 150 Opening BINARY mode data connection for 'collect.c.patch.3'. > 452 Error writing to file: No space left on device. > 1833 bytes sent in 0.00 secs (1361.2 kB/s) > ftp>

1 0

(ITS#6073) ftp.openldap.org "no space left on device"?
by daniel＠pluta.biz 22 Apr '09

22 Apr '09

Full_Name: Daniel Pluta Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:4ca0:0:f000:78be:f928:4392:2caf) ~/build/pkg$ ftp -p 204.152.186.57 Connected to 204.152.186.57. 220- OpenLDAP FTP Service 220 boole.openldap.org FTP server (Version 6.00LS) ready. Name (204.152.186.57:d): anonymous 331 Guest login ok, send your email address as password. Password: 230- Copyright 1998-2009, The OpenLDAP Foundation, All Rights Reserved. 230- COPYING RESTRICTIONS APPLY, see: 230- ftp://ftp.openldap.org/COPYRIGHT 230- ftp://ftp.openldap.org/LICENSE 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> cd incoming 250 CWD command successful. ftp> put collect.c.patch local: collect.c.patch remote: collect.c.patch 227 Entering Passive Mode (204,152,186,57,240,13) 150 Opening BINARY mode data connection for 'collect.c.patch.3'. 452 Error writing to file: No space left on device. 1833 bytes sent in 0.00 secs (1361.2 kB/s) ftp>

1 0

(ITS#6072) slapo-collect: dnLength != dnDepth
by daniel＠pluta.biz 22 Apr '09

22 Apr '09

Full_Name: Daniel Pluta Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/collect.c.patch Submission from: (NULL) (2001:4ca0:0:f000:78be:f928:4392:2caf) DNs should be ordered accoring their in-DIT depth and not accoring their bv_len: 1) "ou=test_ou_long,ou=test,dc=foo,dc=bar" 2) "ou=test,ou=de,ou=test,dc=foo,dc=bar" DN1' bv_len is higher than that of DN2 but DN2 is deeper located within the DIT. I could not find a suitable api-call to determine a DN's depth. So I've used posix regexp and uploaded that quick&dirty hacked patch right here: ftp://ftp.openldap.org/incoming/collect.c.patch Sorry, next time I'll respect the upload naming conventions that I've noticed a bit to late...

1 0

Re: (ITS#6051) JLDAP SASL issue
by rarpit＠novell.com 22 Apr '09

22 Apr '09

--=__Part654DCF55.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable hi Hendrik, From Novell I am the one responsible for Jldap . Our product eDirectory = does not support CRAM authentication. So this functionality is missing . I do not know how to test it ? Can we test it against openldap server ? = =20 You were talking about some test suite in the bug . What is that test = suite ? Please if I can get that test suite I can test it . =20 regards and thanks=20 Arpit=20 >>> <hendrik.saly(a)gmx.de> 4/10/2009 2:19 PM >>> Full_Name: Hendrik Saly Version: JLDAP 4.3 OS: Linux 2.6, Sun JDK 1.5 URL: http://svn.muleforge.org/mule-transport-ldap/trunk/src/main/java/com/n= ovell/ldap/SaslLDAPConnection.java Submission from: (NULL) (78.43.136.21) While trying to use SASL with JLDAP i encounter a potential minor bug in $OpenLDAP: pkg/jldap/com/novell/ldap/LDAPConnection.java,v 1.154 2006/02/09= 08:43:45 sunilk Exp $ Seems the bind method on line 1730 fails to release the bind semaphore = properly under some circumstances. I tried to use more than the wit JLDAP provided = SASL mechanisms DIGESTMD5 and EXTERNAL by wrapping the novell sasl client with = a Java 1.5 sasl client. All works very well but CRAM login for example fails. I = have a workaround http://svn.muleforge.org/mule-transport-ldap/trunk/src/main/ja= va/com/novell/ldap/SaslLDAPConnection.java but i thinks there are some problems with the bind semaphore. The wrapping code is here http://svn.muleforge.org/mule-transport-ldap/trunk/src/main/java/org/mule/t= ransport/ldap/sasl/ClientFactory.java If neccessary i can provide a test suite for this. Thanks Hendrik --=__Part654DCF55.1__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-15= "> <META content=3D"MSHTML 6.00.2900.3492" name=3DGENERATOR></HEAD> <BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Segoe UI"> <DIV>hi Hendrik,</DIV> <DIV>   From Novell I am the one responsible for Jldap . Our = product eDirectory does not support CRAM authentication. So this functional= ity is missing .</DIV> <DIV>   I do not know how to test it ? Can we test it = against openldap server ?  </DIV> <DIV>  You were talking about some test suite in the bug . What is = that test suite ? Please if I can get that test suite I can test it = .</DIV> <DIV> </DIV> <DIV>regards and thanks </DIV> <DIV>Arpit >>> <hendrik.saly(a)gmx.de> 4/10/2009 2:19 = PM >>> Full_Name: Hendrik Saly Version: JLDAP 4.3 OS: = Linux 2.6, Sun JDK 1.5 URL: <A href=3D"http://svn.muleforge.org/mule-tra= nsport-ldap/trunk/src/main/java/com/novell/ldap/SaslLDAPConnection.java">ht= tp://svn.muleforge.org/mule-transport-ldap/trunk/src/main/java/com/novell/l= dap/SaslLDAPConnection.java</A> Submission from: (NULL) (78.43.136.21)<B= R> While trying to use SASL with JLDAP i encounter a potential = minor bug in $OpenLDAP: pkg/jldap/com/novell/ldap/LDAPConnection.java,v = 1.154 2006/02/09 08:43:45 sunilk Exp $ Seems the bind method on = line 1730 fails to release the bind semaphore properly under some = circumstances. I tried to use more than the wit JLDAP provided SASL mech= anisms DIGESTMD5 and EXTERNAL by wrapping the novell sasl client with a = Java 1.5 sasl client. All works very well but CRAM login for example = fails. I have a workaround   <A href=3D"http://svn.muleforge.o= rg/mule-transport-ldap/trunk/src/main/java/com/novell/ldap/SaslLDAPConnecti= on.java">http://svn.muleforge.org/mule-transport-ldap/trunk/src/main/java/c= om/novell/ldap/SaslLDAPConnection.java</A> but i thinks there are some = problems with the bind semaphore. The wrapping code is here <A = href=3D"http://svn.muleforge.org/mule-transport-ldap/trunk/src/main/java/or= g/mule/transport/ldap/sasl/ClientFactory.java">http://svn.muleforge.org/mul= e-transport-ldap/trunk/src/main/java/org/mule/transport/ldap/sasl/ClientFac= tory.java</A> If neccessary i can provide a test suite for = this. Thanks Hendrik </DIV></BODY></HTML> --=__Part654DCF55.1__=--

1 0

(ITS#6071) LDAP server becomes unresponsive
by rs1542＠gmx.com 22 Apr '09

22 Apr '09

Full_Name: Carsten T. Rieck Version: 2.4.11 OS: RedHat 5.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.194.157.126) Hello, my company runs an anonymously accessible LDAP server on openLDAP 2.4.11 with Berkeley database 4.6.21 (all recent patches applied) and RedHat 5.1 as operating system. We encounter the problem that occasionally the LDAP server becomes unresponsive. Investigating the network in such a situation shows a large number of connections in the state CLOSE-WAIT. These connections remain persistent until the LDAP server is restarted. I am able to reproduce the issue in our test environment using a client which accesses the LDAP using libldap. In an infinite loop, the client binds to the LDAP and performs a search, but it does do a proper unbinding. After about thirty loops (depending on the number of threads configured), the LDAP server becomes unresponsive. With netstat, I see the connection still as ESTABLISHED. After killing the client, the connection is marked as CLOSE-WAIT and remains in that state until the server is restarted. Any additional attempts to bind to the server leads to a connections in state CLOSE-WAIT. I do not have a Firewall in my test environment. When the server becomes unresponsive, the log displays the message "Resource temporarily unavailable" as in the following extract: Apr 21 18:31:43 test2 slapd[644]: daemon: epoll: listen=8 active_threads=1 tvp=zero Apr 21 18:31:43 test2 slapd[644]: daemon: epoll: listen=7 busy Apr 21 18:31:43 test2 slapd[644]: => acl_mask: access to entry "cn=ACME Class 2 CA,o=ACME AG,ou=rootcerts,dc=acme,dc=de", attr "certificateRevocationList;binary" requested Apr 21 18:31:43 test2 slapd[644]: => acl_mask: to value by "", (=0) Apr 21 18:31:43 test2 slapd[644]: <= check a_dn_pat: cn=dsa-admin,ou=admin,dc=acme,dc=de Apr 21 18:31:43 test2 slapd[644]: <= check a_dn_pat: cn=dsa-audit,ou=admin,dc=acme,dc=de Apr 21 18:31:43 test2 slapd[644]: <= check a_dn_pat: anonymous Apr 21 18:31:43 test2 slapd[644]: <= acl_mask: [3] applying =rscx (stop) Apr 21 18:31:43 test2 slapd[644]: <= acl_mask: [3] mask: =rscx Apr 21 18:31:43 test2 slapd[644]: => slap_access_allowed: read access granted by =rscx Apr 21 18:31:43 test2 slapd[644]: => access_allowed: read access granted by =rscx Apr 21 18:31:43 test2 slapd[644]: ber_flush2 failed errno=11 reason="Resource temporarily unavailable" Apr 21 18:31:43 test2 slapd[644]: daemon: epoll: listen=8 active_threads=1 tvp=zero Apr 21 18:31:43 test2 slapd[644]: daemon: activity on 2 descriptors Apr 21 18:31:43 test2 slapd[644]: daemon: activity on: Apr 21 18:31:43 test2 slapd[644]: 12w Apr 21 18:31:43 test2 slapd[644]: Apr 21 18:31:43 test2 slapd[644]: daemon: epoll: listen=7 busy Apr 21 18:31:43 test2 slapd[644]: daemon: epoll: listen=8 active_threads=1 tvp=zero In the openLDAP mailing lists I have seen other users having similar although not identical problems. The common advice of reducing the parameter idletimout did not change the behavior. I am most pleased to provide any further information. I appreciate your help. Best regards, Carsten slpad.conf ##================================= ## include /usr/machine/local/admin/openldap/config/ldapdsa/schema/core.schema include /usr/machine/local/admin/openldap/config/ldapdsa/schema/cosine.schema include /usr/machine/local/admin/openldap/config/ldapdsa/schema/inetorgperson.schema password-hash {SSHA} ###################### # generic parameters # ###################### idletimeout 2 sizelimit 1000 timelimit 2 sockbuf_max_incoming 300000 sockbuf_max_incoming_auth 5000000 threads 4 gentlehup on #################### # pid & args files # #################### pidfile /usr/machine/local/work/openldap/slapd.pid argsfile /usr/machine/local/work/openldap/slapd.args ############################################################################### ################## # ssl parameters # ################## ###################### # used cipher suites # ###################### TLSCipherSuite HIGH:MEDIUM:+SSLv3 ################### # key, certs etc. # ################### TLSVerifyClient never ############################################################################### ################################## # macro bdb database definitions # ################################## ########################################## # suffix dc=acme,dc=de # ########################################## database bdb suffix "dc=acme,dc=de" cachesize 8000 checkpoint 5 30 mode 0600 directory /usr/machine/local/persistent/openldap/acme lastmod on rootdn "cn=admin,dc=acme,dc=de" rootpw <Passphrase removed> limits anonymous size.soft=10 ########################################## # ACLs # ########################################## include /usr/machine/local/admin/openldap/config/ldapdsa/acl.conf ############# # set index # ############# index default pres,eq index objectclass index cn,sn pres,eq,sub index mail #eof ##=================================

1 0

Re: (ITS#5941) Problem when stacking rwm and translucent overlays together
by ando＠sys-net.it 21 Apr '09

21 Apr '09

bryan.mesich(a)ndsu.edu wrote: > I pulled the latest HEAD code as of Mon Apr 20 11:38:05 CDT 2009 > and recompiled. Slapd answers one request and then dies with > a segmentation fault: > > connection_get(14): got connid=3D1 > connection_read(14): checking for input on id=3D1 > ber_get_next > Segmentation fault > > I can send you the full debug output if it would be helpful. I'll ask you to send it unless I can easily reproduce the issue myself. Thanks for your time. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5941) Problem when stacking rwm and translucent overlays together
by bryan.mesich＠ndsu.edu 20 Apr '09

20 Apr '09

--17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 20, 2009 at 12:12:48PM +0200, Pierangelo Masarati wrote: >> Full_Name: Bryan Mesich >> Version: 2.4.13 >> OS: RHEL 5.3 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2001:4930:106:0:212:3fff:fefb:2891) >> >> >> When a rwm overlay is used in conjunction with the translucent overlay, = slapd >> dies with the following error and backtrace: > > I've recently (10 minutes ago) fixed an issue in slapo-rwm(5) that could = =20 > also address yours. Can you check? You need to either build HEAD code, = =20 > or apply the difference between servers/slapd/overlays/rwm.c 1.118 -> =20 > 1.119 to 2.4.16. I pulled the latest HEAD code as of Mon Apr 20 11:38:05 CDT 2009 and recompiled. Slapd answers one request and then dies with a segmentation fault: connection_get(14): got connid=3D1 connection_read(14): checking for input on id=3D1 ber_get_next Segmentation fault I can send you the full debug output if it would be helpful. Thanks, Bryan --17pEHd4RhPHOinZp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFJ7N6JlSl3SAlkhEcRAuOwAJ42EyL1dRJAFlZVz7zo5LMTCbgEeACePomd GlMyb+gwM6ZgvTkYl60S7h4= =t8Kh -----END PGP SIGNATURE----- --17pEHd4RhPHOinZp--

1 0

Re: (ITS#6058) slapcat aborts on a double free
by lscamoni＠alice.it 20 Apr '09

20 Apr '09

Tested it and it seems to be fixed

1 0

Re: (ITS#6058) slapcat aborts on a double free
by luca.scamoni＠sys-net.it 20 Apr '09

20 Apr '09

Tested it and it seems to be fixed Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Fax: +39 0382 476497 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6058) slapcat aborts on a double free
by ando＠sys-net.it 20 Apr '09

20 Apr '09

The problem is that slapcat uses be_entry_release_r() as the complement of be->be_entry_get(), namely a run-time function as the complement of a tool function. rwm_entry_release_rw(), on the contrary, assumes that the entry it is passed was dup'ed by rwm_entry_get_rw(). I've applied a fix which **should** always work, based on the assumption that if the entry was retrieved using rwm_entry_get_rw(), and duplicated, both e->e_private and e->e_bv are NULL. p. luca(a)OpenLDAP.org wrote: > Full_Name: Luca Scamoni > Version: 2.4.16 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.63.140.131) > > > Slapcat on a slapd instance using rwm overlay, aborts with: > *** glibc detected *** free(): invalid pointer: 0x09ed06e3 *** > > To simulate it's enough a slapd.conf containing something like > > # Load dynamic backend modules: > modulepath /usr/local/openldap/sbin > moduleload back_hdb.la > moduleload rwm.la > > database hdb > suffix "dc=example,dc=com" > rootdn "cn=Manager,dc=example,dc=com" > rootpw secret > directory /usr/local/openldap/var/data > index objectClass eq > index entryCSN,entryUUID eq > > overlay rwm > > Simple database: > > dn: dc=example,dc=com > objectClass: dcObject > objectClass: organization > dc: example > o: example.com > > 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6034) Assert failure - connection_state_closing
by David Angerer 20 Apr '09

20 Apr '09

Hi there, We upgraded to openldap 2.4.16 about 10 days ago. Since then we are experiencing relatively frequent core dumps (average uptime is around 2-3 days). Investigating the root cause we came across ITS#6034 which reminded us much of problem we are facing, but should be fixed in 2.4.16. Setup: Solaris 10 Openldap 2.4.16 (64bit) Berkeley DB 4.7 1 Master 5 Replicas with deltasyncrepl Cores only happened to the master so far, replicas are running stable so far. I couldn't find a reference to this ITS in the 2.4.16 changelog (probably listed as other ITS or fixed earlier). Also if the fix made it's way into 2.4.16, I am wondering why we still observe this cores. If you need further information or have any suggestions please let me know. Please find some debugging information below. Kind regards, David (dbx) threads t@1 a l@1 ?() LWP suspended in __lwp_wait() t@2 a l@2 slapd_daemon_task() LWP suspended in __pollsys() t@3 a l@3 ldap_int_thread_pool_wrapper() sleep on 0x1004dd428 in __lwp_park() t@4 a l@4 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@5 a l@5 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@6 a l@6 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@7 a l@7 ldap_int_thread_pool_wrapper() sleep on 0x1004dd670 in __lwp_park() t@8 a l@8 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@9 a l@9 ldap_int_thread_pool_wrapper() sleep on 0x1004a9908 in __lwp_park() o t@10 a l@10 ldap_int_thread_pool_wrapper() signal SIGABRT in __lwp_kill() t@11 a l@11 ldap_int_thread_pool_wrapper() sleep on 0x1004a9908 in __lwp_park() t@12 a l@12 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() > t@13 a l@13 ldap_int_thread_pool_wrapper() LWP suspended in slap_access_allowed() t@14 a l@14 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@15 a l@15 ldap_int_thread_pool_wrapper() sleep on 0x1004dd1e0 in __lwp_park() t@16 a l@16 ldap_int_thread_pool_wrapper() LWP suspended in ___lwp_cond_wait() t@17 a l@17 ldap_int_thread_pool_wrapper() sleep on 0x1004a9908 in __lwp_park() t@18 a l@18 ldap_int_thread_pool_wrapper() LWP suspended in __lock_getlocker_int() (dbx) lwp l@10 Current function is connection_state_closing 686 assert( c->c_struct_state == SLAP_C_USED ); t@10 (l@10) stopped in __lwp_kill at 0xffffffff7decea00 0xffffffff7decea00: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xffffffff7decea10 (dbx) where [1] __lwp_kill(0x0, 0x6, 0x10004b128, 0x19d480, 0x0, 0x0), at 0xffffffff7decea00 [2] raise(0x6, 0x0, 0x100445d58, 0xffffffffffffffff, 0xffffffff7dfe6000, 0x0), at 0xffffffff7de6b4f4 [3] abort(0x1, 0x1b8, 0x10004b128, 0x19d480, 0x0, 0x0), at 0xffffffff7de48c8c [4] __assert(0x100271f48, 0x100271f70, 0x2ae, 0x0, 0x19d138, 0x100069f70), at 0xffffffff7de48f30 =>[5] connection_state_closing(c = 0x1004dce30), line 686 in "connection.c" [6] send_ldap_ber(op = 0xffffffff733ff768, ber = 0xffffffff733ff028), line 148 in "result.c" [7] slap_send_search_entry(op = 0xffffffff733ff768, rs = 0xffffffff733ff2d0), line 1247 in "result.c" [8] syncprov_sendresp(op = 0xffffffff733ff768, opc = 0xffffffff733ff4a0, so = 0x113c0a930, e = 0xffffffff733ff500, mode = 3), line 848 in "syncprov.c" [9] syncprov_qplay(op = 0xffffffff733ff768, so = 0x113c0a930), line 913 in "syncprov.c" [10] syncprov_qtask(ctx = 0xffffffff733ffc20, arg = 0x113c0a930), line 971 in "syncprov.c" [11] ldap_int_thread_pool_wrapper(xpool = 0x10046a250), line 663 in "tpool.c" (dbx) list 680,690 680 int connection_state_closing( Connection *c ) 681 { 682 /* c_mutex must be locked by caller */ 683 684 int state; 685 assert( c != NULL ); 686 assert( c->c_struct_state == SLAP_C_USED ); 687 688 state = c->c_conn_state; 689 690 assert( state != SLAP_C_INVALID ); (dbx) print c c = 0x1004dce30 (dbx) print *c *c = { c_struct_state = 1 c_conn_state = 0 c_conn_idx = 26 c_sd = -1 c_close_reason = 0x100271eb0 "?" c_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_sb = 0x118772d90 c_starttime = 0 c_activitytime = 0 c_connid = 18446744073709551615U c_peer_domain = { bv_len = 0 bv_val = (nil) } c_peer_name = { bv_len = 0 bv_val = (nil) } c_listener = (nil) c_sasl_bind_mech = { bv_len = 0 bv_val = (nil) } c_sasl_dn = { bv_len = 0 bv_val = (nil) } c_sasl_authz_dn = { bv_len = 0 bv_val = (nil) } c_authz_backend = (nil) c_authz_cookie = (nil) c_authz = { sai_method = 128U sai_mech = { bv_len = 0 bv_val = (nil) } sai_dn = { bv_len = 0 bv_val = (nil) } sai_ndn = { bv_len = 0 bv_val = (nil) } sai_ssf = 0 sai_transport_ssf = 0 sai_tls_ssf = 0 sai_sasl_ssf = 0 } c_protocol = 0 c_ops = { stqh_first = (nil) stqh_last = 0x1004dcf38 } c_pending_ops = { stqh_first = (nil) stqh_last = 0x1004dcf48 } c_write1_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 4278190080U } __pthread_mutex_owner64 = 4278190080U } __pthread_mutex_data = 18446744071451976704U } c_write1_cv = { __pthread_cond_flags = { __pthread_cond_flag = "" __pthread_cond_type = 0 __pthread_cond_magic = 17238U } __pthread_cond_data = 0 } c_write2_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_write2_cv = { __pthread_cond_flags = { __pthread_cond_flag = "" __pthread_cond_type = 0 __pthread_cond_magic = 17238U } __pthread_cond_data = 0 } c_currentber = (nil) c_writers = 0 c_sasl_bind_in_progress = '\0' c_writewaiter = '\0' c_sasl_layers = '\0' c_sasl_done = '\0' c_sasl_authctx = (nil) c_sasl_sockctx = (nil) c_sasl_extra = (nil) c_sasl_bindop = (nil) c_pagedresults_state = { ps_be = (nil) ps_size = 0 ps_count = 0 ps_cookie = 0 ps_cookieval = { bv_len = 0 bv_val = (nil) } } c_n_ops_received = 3 c_n_ops_executing = 0 c_n_ops_pending = 0 c_n_ops_completed = 3 c_n_get = 4 c_n_read = 3 c_n_write = 1 c_extensions = (nil) c_clientfunc = (nil) c_clientarg = (nil) c_send_ldap_result = 0x10006b900 = &slap_send_ldap_result(Operation *op, SlapReply *rs) c_send_search_entry = 0x10006cda0 = &slap_send_search_entry(Operation *op, SlapReply *rs) c_send_search_reference = 0x10006fa80 = &slap_send_search_reference(Operation *op, SlapReply *rs) c_send_ldap_extended = 0x10006c5f8 = &slap_send_ldap_extended(Operation *op, SlapReply *rs) c_send_ldap_intermediate = 0x10006ca28 = &slap_send_ldap_intermediate(Operation *op, SlapReply *rs) }

1 0

Re: (ITS#5941) Problem when stacking rwm and translucent overlays together
by ando＠sys-net.it 20 Apr '09

20 Apr '09

bryan.mesich(a)ndsu.edu wrote: > Full_Name: Bryan Mesich > Version: 2.4.13 > OS: RHEL 5.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:4930:106:0:212:3fff:fefb:2891) > > > When a rwm overlay is used in conjunction with the translucent overlay, slapd > dies with the following error and backtrace: I've recently (10 minutes ago) fixed an issue in slapo-rwm(5) that could also address yours. Can you check? You need to either build HEAD code, or apply the difference between servers/slapd/overlays/rwm.c 1.118 -> 1.119 to 2.4.16. Thanks, 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#6070) slapo-rwm(5) be_entry_get() incorrect behavior when no DN rewriting occurs
by ando＠sys-net.it 20 Apr '09

20 Apr '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.146) Submitted by: ando To reproduce, stack a slapo-rwm with no specific instructions on top of a provider right before the syncprov overlay. A fix is coming.

1 0

Re: (ITS#6055) Samba4 need 'name' implementation like AD (RDN-Name)
by michael＠stroeder.com 18 Apr '09

18 Apr '09

Pierangelo Masarati wrote: > michael(a)stroeder.com wrote: >> (I've stumbled across ITS#5704. Isn't that already something like this?) > > not exactly, as sets do not allow a placeholder for the naming > attribute; maybe something like "this/entryRDN.ava{0}.value" if it > existed... But given that slapd already enforces the characteristic attribute (e.g. 'cn' for 'user' on Samba4) to be part of the entry IMHO this is not needed. Provided the order of the checks are right. So this would be: constraint_attribute name set "this/cn" restrict="ldap:///dc=example,dc=com??sub?(objectClass=user)" constraint_attribute name set "this/ou" restrict="ldap:///dc=example,dc=com??sub?(objectClass=organizationalUnit)" Since uniqueness of 'cn' or 'ou' for one-level search for the above cases is already enforced wouldn't this be sufficient? Maybe I miss something though. Ciao, Michael.

1 0

Re: (ITS#6055) Samba4 need 'name' implementation like AD (RDN-Name)
by ando＠sys-net.it 18 Apr '09

18 Apr '09

michael(a)stroeder.com wrote: > ando(a)sys-net.it wrote: >> ----- abartlet(a)samba.org wrote: >>> Active Directory always presents an attribute 'name' that is always >>> equal to the relative distinguished name. AD allows only one RDN, >>> but I don't mind if this can be multi-valued for the multi-RDN >>> case. It is equal to the value of the RDN as presented in the RDN. >>> >>> This is not simply the subtype 'CN -> name', but a new attribute >>> unrelated to the existing definition of 'name'. >>> >>> I don't care what name is assigned to 'name', as I can easily remap >>> attributes. >>> >>> It would be great if this could be constructed such that it may be >>> declared to be unique for a particular one-level search (also an AD >>> requirement, but not one Samba4 requires or enforces at this time). >> The only problem I see in defining such an attribute is that its >> syntax should allow the value of any syntax, so it should probably be >> octetString or something like that. > > Why? IMO such an attribute type could be declared like any other > attribute type. If its syntax does not match the syntax of the > characteristic attribute invalidAttributeSyntax should be returned. Since we're dealing with something unspecified, you can: - be "strict": only allow the creation of this attribute when the naming attribute's syntax is 2.5.5.12 (unspecified, I understand, but we live in a wild world) - be "liberal": always allow the creation of this attribute by allowing it to contain any value > I wonder what the exact requirements for the implementation within slapd > are and some very rough ideas as food for thought: > > 1. slapd shall enforce uniqueness on one-level > => I'd vote for an additional feature of slapo-unique to define the > scope of uniqueness in a very flexible way > > 2. Value of 'name' has to match the value of the characteristic > attribute. Does this 1. has to be enforced within slapd or 2. could this > be enforced within smbd? > If 1. maybe the functionality/configuration of slapo-constraint could be > extended to define things like this. > (I've stumbled across ITS#5704. Isn't that already something like this?) not exactly, as sets do not allow a placeholder for the naming attribute; maybe something like "this/entryRDN.ava{0}.value" if it existed... p. > ...more...? > > In web2ldap's plugin classes I have implemented special treatment for > non-compliant notation for the DN part of LDAP URLs to reference a DN > based on an entry's DN: > > . the entry's DN > .. the entry's parent DN > _ the best matching namingContext for the entry's DN > > This strings can be appended to DNs. For example: > > 'ou=Users,_' would always refer to entry ou=Users below an arbitrary > naming context. > > 'ou=My Stuff,.' could refer to a container below a user's entry > > Maybe something like this could be helpful for an extended configuration > of slapo-unique and slapo-constraint. > > Hmm, also > > As said only very rough ideas... > > Ciao, Michael. > > 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6055) Samba4 need 'name' implementation like AD (RDN-Name)
by michael＠stroeder.com 18 Apr '09

18 Apr '09

ando(a)sys-net.it wrote: > ----- abartlet(a)samba.org wrote: >> Active Directory always presents an attribute 'name' that is always >> equal to the relative distinguished name. AD allows only one RDN, >> but I don't mind if this can be multi-valued for the multi-RDN >> case. It is equal to the value of the RDN as presented in the RDN. >> >> This is not simply the subtype 'CN -> name', but a new attribute >> unrelated to the existing definition of 'name'. >> >> I don't care what name is assigned to 'name', as I can easily remap >> attributes. >> >> It would be great if this could be constructed such that it may be >> declared to be unique for a particular one-level search (also an AD >> requirement, but not one Samba4 requires or enforces at this time). > > The only problem I see in defining such an attribute is that its > syntax should allow the value of any syntax, so it should probably be > octetString or something like that. Why? IMO such an attribute type could be declared like any other attribute type. If its syntax does not match the syntax of the characteristic attribute invalidAttributeSyntax should be returned. I wonder what the exact requirements for the implementation within slapd are and some very rough ideas as food for thought: 1. slapd shall enforce uniqueness on one-level => I'd vote for an additional feature of slapo-unique to define the scope of uniqueness in a very flexible way 2. Value of 'name' has to match the value of the characteristic attribute. Does this 1. has to be enforced within slapd or 2. could this be enforced within smbd? If 1. maybe the functionality/configuration of slapo-constraint could be extended to define things like this. (I've stumbled across ITS#5704. Isn't that already something like this?) ...more...? In web2ldap's plugin classes I have implemented special treatment for non-compliant notation for the DN part of LDAP URLs to reference a DN based on an entry's DN: . the entry's DN .. the entry's parent DN _ the best matching namingContext for the entry's DN This strings can be appended to DNs. For example: 'ou=Users,_' would always refer to entry ou=Users below an arbitrary naming context. 'ou=My Stuff,.' could refer to a container below a user's entry Maybe something like this could be helpful for an extended configuration of slapo-unique and slapo-constraint. Hmm, also As said only very rough ideas... Ciao, Michael.

1 0

Re: ITS#5860 slapd in openldap-2.4.16 still doesn't respect memory bounds
by sscdvp＠gmail.com 18 Apr '09

18 Apr '09

2009/4/17, sscdvp(a)gmail.com <sscdvp(a)gmail.com>: > 2009/4/17, sscdvp(a)gmail.com <sscdvp(a)gmail.com>: > > 2009/4/17, Quanah Gibson-Mount <quanah(a)zimbra.com>: > > > --On Friday, April 17, 2009 10:25 PM +0300 sscdvp(a)gmail.com wrote: > > > > Why do you have so many threads configured? How many cpu's do you have?? > > > > > > > > > > > > > > > > > > > > > I have tried openldap-2.4.16 (latest) BDB 4.7.25 with all patches from > > > > > Oracle on Dell AMD64 RAM 4Gb, 8 CPUs, OS Solaris 10. > > > > > > > > > > > > > I have an application which generates heavy load in slapd (many > > > > ldap_search'es and very very many ldap_add, ldap_modify, ldap_delete). > > > > BDB databases are situated on separate disk and BDB logs are on the other > > > > disk. But slapd performance (I mean time to answer) still cuts > > > > down during large disk IO periods 'cause these disks are used by other > > > > applications at the same time. And so I have increased number of threads > > > > from the defaults threads=32 up to 64, just to save some time for my > > > > application which requires not more then 30 ms for one search to > > > > complete. > > > > Just to be sure I have tried the default settings for threads and it's > > > > behaviour didn't changed - slapd heap memory just continuously grows (I > > > > have seen through pmap)... > > > > Also I have tried libtcmalloc which is usually recommended and solaris > > > > built in' libmtmalloc, but it didn't helped. > > > > > > > > > > Please copy replies to the bug tracker if you expect help. > > > > > > I will note that every thread consumes a large chunk of memory. I will also > > > note that the default is 16 threads, not 32. I will also note, that as far > > > as read operations are concerned, usually *fewer* threads is faster, not > > > more. > > >You appear to have quite an excessive amount of threads configured. > > > > > > I have mentioned that using the defaults didn't helped. Probably I was > mistaken about the default number of threads - but if keywords > "threads" is missing in config it simply means the defaults, right? > May be number of threads should be lower then the defaults (e.g. 6 or 8)? > Now I have 8 threads and slapd grows upto 2GB limit in 6 hours.

1 0

Re: ITS#5860 slapd in openldap-2.4.16 still doesn't respect memory bounds
by sscdvp＠gmail.com 17 Apr '09

17 Apr '09

2009/4/17, Quanah Gibson-Mount <quanah(a)zimbra.com>: > --On Friday, April 17, 2009 10:25 PM +0300 sscdvp(a)gmail.com wrote: > > Why do you have so many threads configured? How many cpu's do you have?? > > > > > > > > > > > I have tried openldap-2.4.16 (latest) BDB 4.7.25 with all patches from > > > Oracle on Dell AMD64 RAM 4Gb, 8 CPUs, OS Solaris 10. > > > > > > > I have an application which generates heavy load in slapd (many > > ldap_search'es and very very many ldap_add, ldap_modify, ldap_delete). > > BDB databases are situated on separate disk and BDB logs are on the other > > disk. But slapd performance (I mean time to answer) still cuts > > down during large disk IO periods 'cause these disks are used by other > > applications at the same time. And so I have increased number of threads > > from the defaults threads=32 up to 64, just to save some time for my > > application which requires not more then 30 ms for one search to > > complete. > > Just to be sure I have tried the default settings for threads and it's > > behaviour didn't changed - slapd heap memory just continuously grows (I > > have seen through pmap)... > > Also I have tried libtcmalloc which is usually recommended and solaris > > built in' libmtmalloc, but it didn't helped. > > > > Please copy replies to the bug tracker if you expect help. > > I will note that every thread consumes a large chunk of memory. I will also > note that the default is 16 threads, not 32. I will also note, that as far > as read operations are concerned, usually *fewer* threads is faster, not > more. >You appear to have quite an excessive amount of threads configured. > I have mentioned that using the defaults didn't helped. Probably I was mistaken about the default number of threads - but if keywords "threads" is missing in config it simply means the defaults, right? May be threads should be lower then the defaults (e.g. 6 or 8)?

1 0

Re: ITS#5860 slapd in openldap-2.4.16 still doesn't respect memory bounds
by Quanah Gibson-Mount 17 Apr '09

17 Apr '09

--On Friday, April 17, 2009 10:25 PM +0300 sscdvp(a)gmail.com wrote: > Why do you have so many threads configured? How many cpu's do you have?? > > > >> I have tried openldap-2.4.16 (latest) BDB 4.7.25 with all patches from >> Oracle on Dell AMD64 RAM 4Gb, 8 CPUs, OS Solaris 10. > > I have an application which generates heavy load in slapd (many > ldap_search'es and very very many ldap_add, ldap_modify, ldap_delete). > BDB databases are situated on separate disk and BDB logs are on the other > disk. But slapd performance (I mean time to answer) still cuts > down during large disk IO periods 'cause these disks are used by other > applications at the same time. And so I have increased number of threads > from the defaults threads=32 up to 64, just to save some time for my > application which requires not more then 30 ms for one search to > complete. > Just to be sure I have tried the default settings for threads and it's > behaviour didn't changed - slapd heap memory just continuously grows (I > have seen through pmap)... > Also I have tried libtcmalloc which is usually recommended and solaris > built in' libmtmalloc, but it didn't helped. Please copy replies to the bug tracker if you expect help. I will note that every thread consumes a large chunk of memory. I will also note that the default is 16 threads, not 32. I will also note, that as far as read operations are concerned, usually *fewer* threads is faster, not more. You appear to have quite an excessive amount of threads configured. Others will have to continue the conversation on what you're seeing growth wise. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: ITS#5860 slapd in openldap-2.4.16 still doesn't respect memory bounds
by sscdvp＠gmail.com 17 Apr '09

17 Apr '09

2009/4/17, sscdvp(a)gmail.com <sscdvp(a)gmail.com>: > > > > > > > > > > I have tried openldap-2.4.16 (latest) BDB 4.7.25 with all patches from > > > Oracle on Dell AMD64 RAM 4Gb, 8 CPUs, OS Solaris 10. > > > According to ITS#5860 slapd should not allocate more memory than it was > > > specified. In fact I have the same behaviour as it was with previous > > > > > > version (2.4.11). It correctly allocates 1.2 Gb via shared memory (for > > > set_cachesize 300 MB). But slapd process continuosly grows in memory until > > > 32-bit limit then crashes due to unavalable memory resources. I need to > > > > > > mention bdb database size is less then 1 GB. > > > After restart it rapidly consumes 1.5 GB RSS in few minutes and then it > > > grows beyond the limit during 24 hours. The more queries are processing > > > the more memory it eats. > > > > > > I am using this database for logging which size grows. > > > The question is: is it possible to use 32-bit openldap with relatively > > > large database sizes that override 32-bit per-process memory space? > > > > > > My slapd.conf contains: > > > > > > > > > threads 64 > > > > > > > Why do you have so many threads configured? How many cpu's do you have?? > > > > I have tried openldap-2.4.16 (latest) BDB 4.7.25 with all patches from > > Oracle on Dell AMD64 RAM 4Gb, 8 CPUs, OS Solaris 10. > > I have an application which generates heavy load in slapd (many ldap_search'es and very very many ldap_add, ldap_modify, ldap_delete). BDB databases are situated on separate disk and BDB logs are on the other disk. But slapd performance (I mean time to answer) still cuts down during large disk IO periods 'cause these disks are used by other applications at the same time. And so I have increased number of threads from the defaults threads=32 up to 64, just to save some time for my application which requires not more then 30 ms for one search to complete. > Just to be sure I have tried the default settings for threads and it's behaviour didn't changed - slapd heap memory just continuously grows (I have seen through pmap)... > Also I have tried libtcmalloc which is usually recommended and solaris built in' libmtmalloc, but it didn't helped.

1 0

Re: (ITS#6058) slapcat aborts on a double free
by h.b.furuseth＠usit.uio.no 17 Apr '09

17 Apr '09

luca(a)openldap.org writes: > Slapcat on a slapd instance using rwm overlay, aborts with: > *** glibc detected *** free(): invalid pointer: 0x09ed06e3 *** It's an invalid free() of (static EntryHeader eh).e_bv.bv_val at: ch_free (ch_malloc.c:139) hdb_tool_entry_close (back-hdb/tools.c:164) slapcat (slapcat.c:135) main (main.c:636) already freed (as (Entry *e)->e_bv.bv_val) at: ch_free (ch_malloc.c:139) entry_clean (entry.c:498) entry_free (entry.c:514) rwm_entry_release_rw (overlays/rwm.c:827) overlay_entry_release_ov (backover.c:421) over_entry_release_rw (backover.c:463) be_entry_release_rw (backend.c:867) slapcat (slapcat.c:117) main (main.c:636) I needed to prepend include servers/slapd/schema/core.schema to your config. -- Hallvard

1 0

Re: (ITS#5975) minor issue with slapd.conf manpage
by h.b.furuseth＠usit.uio.no 17 Apr '09

17 Apr '09

eric(a)huss.org wrote: > There appears to be a couple slightly incorrect statements in the slapd.conf > manpage. It says that the argsfile and pidfile values are used "if started > without the debugging command line option". However, it doesn't appear to > make any difference whether or not you use the -d option with slapd. Fixed the doc in HEAD. Also the argsfile did not mention that the program name is written to argsfile as well as the options. -- Hallvard

1 0

Re: (ITS#6059) Abandon syncprov race condition?
by h.b.furuseth＠usit.uio.no 17 Apr '09

17 Apr '09

rein(a)OpenLDAP.org writes: > I've had two cases where a delete operation was performed on the > master without being replicated to its consumers, which so far appear > to be cases of possible connection lost (abandon) race conditions. Not sure if this is the problem, but it is ugly: slapd/cancel.c sets o_abandon with op->o_conn->c_mutex locked, but waits to set o_cancel after it's unlocked. Looks like that can give slapd a chance to react to o_abandon before it "knows" that abandon is actually a cancel. > Do we need some sort of o_committed flag that can be used to prevent > o_abandon from being set or acted upon? Or handle o_abandon more like > o_cancel, i.e with multiple values, including "too late"? o_cancel is a wrapper around o_abandon, turning result code SLAPD_ABANDON into LDAP_TOO_LATE etc. However slap_send_ldap_result() and send_ldap_response() skip "if (op->o_callback) slap_response_play()" if o_abandon is set, and "send" SLAPD_ABANDON instead of the result code. Can that work right? The code looks like SLAPD_ABANDON ought to mean "nothing was done" right up till everything has had a chance to react the same way to an operation. -- Hallvard

1 0

Re: (ITS#6065) slapcat with sql (postgres) backend
by ando＠sys-net.it 17 Apr '09

17 Apr '09

frederic.bouy(a)gmail.com wrote: > Full_Name: Frederic Bouy > Version: 2.4.12 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.255.106.203) > > > When running the following command: > slapcat -l /tmp/lnp.ldif -f /usr/local/openldap/etc/openldap/slapd.conf -d 1 > I get this error message: > <==backsql_load_schema_map() > ==>backsql_free_db_conn() > ==>backsql_close_db_handle(0x8290c18) > <==backsql_close_db_handle(0x8290c18) > <==backsql_free_db_conn() > <==backsql_db_open(): test succeeded, schema map loaded > slapcat: database doesn't support necessary operations. > > ldapsearch is successfull. > > Do you have any clue on how to solve this issue? The message should be pretty self explanatory. A solution consists in implementing the missing support. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#6065) slapcat with sql (postgres) backend
by frederic.bouy＠gmail.com 17 Apr '09

17 Apr '09

Full_Name: Frederic Bouy Version: 2.4.12 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.255.106.203) When running the following command: slapcat -l /tmp/lnp.ldif -f /usr/local/openldap/etc/openldap/slapd.conf -d 1 I get this error message: <==backsql_load_schema_map() ==>backsql_free_db_conn() ==>backsql_close_db_handle(0x8290c18) <==backsql_close_db_handle(0x8290c18) <==backsql_free_db_conn() <==backsql_db_open(): test succeeded, schema map loaded slapcat: database doesn't support necessary operations. ldapsearch is successfull. Do you have any clue on how to solve this issue? Thanks for your help.

1 0

Antwort: Re: (ITS#5837) slapd pthread_kill Core Dump AIX
by howard.allison＠pva.sozvers.at 17 Apr '09

17 Apr '09

--0__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841 Content-type: multipart/alternative; Boundary="1__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841" --1__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable This is a full Backtrace - about 200 MB of Real Memory available(from 2= GB), and 2 GB of swap available. Thanks #0 0xd04a7560 in pthread_kill () from /usr/lib/libpthread.a(shr_xpg5.o= ) No symbol table info available. #1 0xd04a69cc in _p_raise () from /usr/lib/libpthread.a(shr_xpg5.o) No symbol table info available. #2 0xd01367e4 in raise () from /usr/lib/libs.a(shr.o) No symbol table info available. #3 0xd01a9028 in abort () from /usr/lib/libs.a(shr.o) No symbol table info available. #4 0xd0164878 in __assert_c99 () from /usr/lib/libs.a(shr.o) No symbol table info available. #5 0x1000cbe4 in ch_malloc (size=3D8388608) at ch_malloc.c:57 new =3D (void *) 0x0 #6 0x1022a80c in search_stack (op=3D0x243de2d8) at search.c:1013 bdb =3D (struct bdb_info *) 0x20188b98 ret =3D (void *) 0x0 #7 0x1022ac0c in search_candidates (op=3D0x243de2d8, rs=3D0x263ba824, e=3D0x263b9bc4, locker=3D0x51eadec0, ids=3D0x262f9bc4, scopes=3D0x26379= bc4) at search.c:1099 bdb =3D (struct bdb_info *) 0x20188b98 rc =3D 640653952 depth =3D 3 f =3D {f_choice =3D 160, f_un =3D {f_un_result =3D 640653996, f= _un_desc =3D 0x262f9aac, f_un_ava =3D 0x262f9aac, f_un_ssa =3D 0x262f9aac, f_un_mra =3D 0x262f9aac, f_un_complex =3D 0x262f9aac}, f_next =3D 0= x0} rf =3D {f_choice =3D 163, f_un =3D {f_un_result =3D 640654008, = f_un_desc =3D 0x262f9ab8, f_un_ava =3D 0x262f9ab8, f_un_ssa =3D 0x262f9ab8, f_un_mra =3D 0x262f9ab8, f_un_complex =3D 0x262f9ab8}, f_next =3D 0= x286ef7dc} xf =3D {f_choice =3D 161, f_un =3D {f_un_result =3D 640653972, = f_un_desc =3D 0x262f9a94, f_un_ava =3D 0x262f9a94, f_un_ssa =3D 0x262f9a94, f_un_mra =3D 0x262f9a94, f_un_complex =3D 0x262f9a94}, f_next =3D 0= x0} nf =3D {f_choice =3D 0, f_un =3D {f_un_result =3D 0, f_un_desc = =3D 0x0, f_un_ava =3D 0x0, f_un_ssa =3D 0x0, f_un_mra =3D 0x0, f_un_complex =3D = 0x0}, f_next =3D 0x262f9aa0} stack =3D (ID *) 0x1020cc58 aa_ref =3D {aa_desc =3D 0x200c0268, aa_value =3D {bv_len =3D 8,= bv_val =3D 0x102dbf2c "r\ef\erral"}} sf =3D {f_choice =3D 0, f_un =3D {f_un_result =3D 641440756, f_= un_desc =3D 0x263b9bf4, f_un_ava =3D 0x263b9bf4, f_un_ssa =3D 0x263b9bf4, f_un_mra =3D 0x263b9bf4, f_un_complex =3D 0x263b9bf4}, f_next =3D 0= x262f9ad0} aa_subentry =3D {aa_desc =3D 0x0, aa_value =3D {bv_len =3D 0, b= v_val =3D 0x0}} bv_ref =3D {bv_len =3D 8, bv_val =3D 0x102dbf2c "r\ef\erral"} #8 0x10228ee4 in bdb_search (op=3D0x243de2d8, rs=3D0x263ba824) at sear= ch.c:578 bdb =3D (struct bdb_info *) 0x20188b98 id =3D 0 cursor =3D 0 lastid =3D 4294967295 candidates =3D {0 <repeats 131072 times>} scopes =3D {0 <repeats 63759 times>, 641435536, 0, 0, 0, 0, 4030840384, 0 <repeats 11 times>, 641435684, 0 <repeats 206 times>, 641434560, 0 <repeats 11 times>, 641434656, 0, 0, 0, 641434656, 4030840384, 3490904144, 0, 0, 4030840384, 0, 0, 0, 0, 0, 0, 641434672, 0, 0, 0, 32,= 58, 22528, 0, 0, 11, 58, 4030431112, 641434720, 2567258180, 3490905504, 0= , 641434768, 4030840384, 4112, 0, 4030805596, 4030426872, 608034984, 959840256, 110, 608035812, 0, 0, 641434800, 0, 3490902496, 0, 6414348= 00, 4030840384, 58, 22528, 0, 144, 0, 269721729, 269721729, 4030854004, 3490917464, 0, 641434880, 4112, 58, 4030431112, 641434880, 4030840384= , 3490883944, 0, 641434896, 4030840384, 3490889600, 641435752, 641434896,= 4030840384, 3491274292, 0, 0, 641437345, 641437340, 1, 0, 1, 40304311= 12, 4030431112, 641434960, 0, 3490885628, 641435752, 641435008, 4030840384,= 3491268044, 0, 641434976, 4030840384, 0, 0, 641434992, 0, 0, 641435752= , 641435008, 4031927728, 3491274292, 608035800, 641435072, 297, 3490878276, 0, 641435072, 4030840384, 3490889836, 0, 641435072, 4030840384, 3490889600, 641435752, 641435648, 4030840384, 3491266240, 0= , 0, 4030840384, 0, 14, 32, 608035800, 0, 0, 0, 0, 14, 14, 641435168, 0, 3490878896, 0, 0, 4030840384, 0 <repeats 11 times>, 608035800, 1, 0, 641437088...} e =3D (Entry *) 0x0 base =3D {e_id =3D 1, e_name =3D {bv_len =3D 678360812, bv_val = =3D 0x23a301e0 ""}, e_nname =3D {bv_len =3D 23, bv_val =3D 0x243e94e8 "dc=3Dpva,dc=3Dsozv\ers,dc=3Dat"}, e_attrs =3D= 0x3, e_ocflags =3D 641440736, e_bv =3D {bv_len =3D 641440832, bv_val =3D 0xf= 041be40 ""}, e_private =3D 0x203a0f78} e_root =3D (Entry *) 0x2035880c matched =3D (Entry *) 0x0 ei =3D (EntryInfo *) 0x203a0f78 attrs =3D (AttributeName *) 0x0 realbase =3D {bv_len =3D 23, bv_val =3D 0x243e94e8 "dc=3Dpva,dc= =3Dsozv \ers,dc=3Dat"} mask =3D 5119 stoptime =3D 1239955337 manageDSAit =3D 0 tentries =3D 0 nentries =3D 0 idflag =3D 0 locker =3D 0x51eadec0 lock =3D {off =3D 0, ndx =3D 412, gen =3D 77770, mode =3D DB_LO= CK_READ} opinfo =3D (struct bdb_op_info *) 0x0 ltid =3D (DB_TXN *) 0x0 oex =3D (OpExtra *) 0x0 stub =3D {bv_len =3D 4030851424, bv_val =3D 0x0} #9 0x100d66dc in overlay_op_walk (op=3D0x243de2d8, rs=3D0x263ba824, which=3Dop_search, oi=3D0x20189d68, on=3D0x0) at backover.c:646 func =3D (BI_op_bind **) 0x200012b4 rc =3D 32768 sc_next =3D (slap_callback *) 0x0 #10 0x100d691c in over_op_func (op=3D0x243de2d8, rs=3D0x263ba824, which=3Dop_search) at backover.c:698 oi =3D (slap_overinfo *) 0x20189d68 on =3D (slap_overinst *) 0x20189e78 be =3D (BackendDB *) 0x20187f68 db =3D {bd_info =3D 0x20001288, bd_self =3D 0x20187f68, be_ctrls =3D "\000\001\001\001\000\001\000\000\001\000\000\001\001\00= 0 \001", '\0' <repeats 17 times>, "\001", be_flags =3D 2312, be_restricto= ps =3D 0, be_requires =3D 0, be_ssf_set =3D {sss_ssf =3D 0, sss_transport =3D 0= , sss_tls =3D 0, sss_sasl =3D 0, sss_update_ssf =3D 0, sss_update_transport =3D 0, sss_update_tls =3D 0, sss_update_sasl =3D 0, sss_simple_bind =3D 0}= , be_suffix =3D 0x20183b08, be_nsuffix =3D 0x20189a28, be_schemadn =3D {b= v_len =3D 0, bv_val =3D 0x0}, be_schemandn =3D {bv_len =3D 0, bv_val =3D 0x0}, b= e_rootdn =3D {bv_len =3D 34, bv_val =3D 0x20189ce8 "cn=3DManag\er,dc=3Dpva,dc=3Dsozv\ers,dc=3Dat= "}, be_rootndn =3D {bv_len =3D 34, bv_val =3D 0x20189d38 "cn=3Dmanag\er,dc=3Dpva,dc=3Dsozv\ers,dc=3Dat= "}, be_rootpw =3D {bv_len =3D 5, bv_val =3D 0x20187138 "start"}, be_max_deref_depth =3D= 15, be_def_limit =3D {lms_t_soft =3D 3600, lms_t_hard =3D 0, lms_s_soft =3D= -1, lms_s_hard =3D 0, lms_s_unchecked =3D -1, lms_s_pr =3D 0, lms_s_pr_hide= =3D 0, lms_s_pr_total =3D 0}, be_limits =3D 0x0, be_acl =3D 0x2016b768, be_dfltaccess =3D ACL_READ, be_update_ndn =3D {bv_len =3D 0, bv_val =3D= 0x0}, be_update_refs =3D 0x0, be_pending_csn_list =3D 0x20356508, be_pcl_mu= tex =3D {__mt_word =3D {0, 0, 0, 1, 0, 1373, 0, 5, 0, 0, 0, 0, 0}}, be_pcl_mutexp =3D 0x20188034, be_syncinfo =3D 0x0, be_pb =3D 0x0, be_= cf_ocs =3D 0x2001b2a8, be_private =3D 0x20188b98, be_next =3D {stqe_next =3D 0x201= 92308}} cb =3D {sc_next =3D 0x0, sc_response =3D @0x2001e51c: 0x100d553= c <over_back_response>, sc_cleanup =3D @0x0: 0x1, sc_private =3D 0x20189d= 68} rc =3D 32768 #11 0x100d6a84 in over_op_search (op=3D0x243de2d8, rs=3D0x263ba824) at backover.c:720 No locals. #12 0x100b3434 in fe_op_search (op=3D0x243de2d8, rs=3D0x263ba824) at search.c:366 bd =3D (BackendDB *) 0x20046498 entry =3D (Entry *) 0x1021638 #13 0x100b2b2c in do_search (op=3D0x243de2d8, rs=3D0x263ba824) at searc= h.c:217 base =3D {bv_len =3D 23, bv_val =3D 0x243e93ff "dc=3Dpva,dc=3Ds= ozv \ers,dc=3Dat"} siz =3D 0 off =3D 0 i =3D 0 dummy =3D 0x5469746c <Address 0x5469746c out of bounds> #14 0x1006c154 in connection_operation (ctx=3D0x263ba95c, arg_v=3D0x243= de2d8) at connection.c:1084 rc =3D 80 op =3D (Operation *) 0x243de2d8 rs =3D {sr_type =3D REP_RESULT, sr_tag =3D 0, sr_msgid =3D 0, s= r_err =3D 0, sr_matched =3D 0x0, sr_text =3D 0x0, sr_ref =3D 0x0, sr_ctrls =3D 0x0, = sr_un =3D { sru_sasl =3D {r_sasldata =3D 0x0}, sru_extended =3D {r_rspoid =3D 0= x0, r_rspdata =3D 0x0}, sru_search =3D {r_entry =3D 0x0, r_attr_flags =3D 0= , r_operational_attrs =3D 0x0, r_attrs =3D 0x0, r_nentries =3D 0, r= _v2ref =3D 0x0}}, sr_flags =3D 0} tag =3D 99 opidx =3D SLAP_OP_SEARCH conn =3D (Connection *) 0x201bd448 memctx =3D (void *) 0x243de6b8 memctx_null =3D (void *) 0x0 memsiz =3D 1048576 curelm =3D (struct Operation *) 0x1 #15 0x1006c848 in connection_read_thread (ctx=3D0x263ba95c, argv=3D0x20= ) at connection.c:1211 rc =3D 0 cri =3D {op =3D 0x243de2d8, func =3D @0x0: 0x1, arg =3D 0x0, ct= x =3D 0x263ba95c, nullop =3D 0} s =3D 32 #16 0xd26daf88 in ldap_int_thread_pool_wrapper (xpool=3D0x200c9588) at tpool.c:663 pool =3D (struct ldap_int_thread_pool_s *) 0x200c9588 task =3D (ldap_int_thread_task_t *) 0x23e43ae8 work_list =3D (ldap_int_tpool_plist_t *) 0x200c961c ctx =3D {ltu_id =3D 1286, ltu_key =3D {{ltk_key =3D 0x2001e2ac,= ltk_data =3D 0x243de5a8, ltk_free =3D @0x2001e2b8: 0x1006b814 <conn_counter_destroy>= }, {ltk_key =3D 0x2001e048, ltk_data =3D 0x243de6b8, ltk_free =3D @0x2= 001e054: 0x1000a1e4 <slap_sl_mem_destroy>}, {ltk_key =3D 0x20020b20, ltk_data =3D 0x0, ltk_free =3D @0x20020b2c: 0x10009864 <slap_op_q_destroy>}, {ltk_key =3D 0x20356518, ltk_data =3D 0x51eadec0,= ltk_free =3D @0x200201fc: 0x1020f550 <bdb_locker_id_free>}, {ltk_= key =3D 0x0, ltk_data =3D 0x0, ltk_free =3D @0x0: 0x1} <repeats 28 times>}} kctx =3D (ldap_int_thread_userctx_t *) 0x0 i =3D 32 keyslot =3D 171 hash =3D 171 ptr_ =3D (const unsigned char *) 0x263ba95c "" i_ =3D 4 #17 0xd048fc50 in _pthread_body () from /usr/lib/libpthread.a(shr_xpg5.= o) No symbol table info available. Mit freundlichen Gr=FC=DFen Howard ALLISON Pensionsversicherungsanstalt Rechenzentrumsbetrieb A-1021 Wien, Friedrich-Hillegeist-Stra=DFe 1 E-Mail..: howard.allison(a)pva.sozvers.at Internet: www.pensionsversicherung.at -------------------------- VERTRAULICHKEIT: Diese Nachricht ist ausschlie=DFlich f=FCr denjenigen bestimmt, an den sie adressiert ist und kann vertrauliche Informationen enthalten. F= alls Sie nicht der Empf=E4nger dieser Nachricht sind, weisen wir Sie darauf hin, dass = die unberechtigte Weitergabe oder Verwendung sowie das unberechtigte Vertei= len oder Kopieren dieser Nachricht strikt untersagt sind. Falls Sie diese Nachri= cht irrt=FCmlich erhalten haben, vernichten Sie sie bitte sofort. CONFIDENTIALITY: This message is intended only for the use of the individuality or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure. If you are not the intended recipient you are notified that any dissemination, distribution, use or copying of this communication is strictly prohibited. If you received this message in error, please immediately destroy this message. --------------------------= --1__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841 Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable <html><body> This is a full Backtrace - about 200 MB of Real Mem= ory available(from 2 GB), and 2 GB of swap available. Thanks #0 0xd04a7560 in pthread_kill () from /usr/lib/libpth= read.a(shr_xpg5.o) No symbol table info available. #1 0xd04a69cc in _p_raise () from /usr/lib/libpthread= .a(shr_xpg5.o) No symbol table info available. #2 0xd01367e4 in raise () from /usr/lib/libs.a(shr.o)= No symbol table info available. #3 0xd01a9028 in abort () from /usr/lib/libs.a(shr.o)= No symbol table info available. #4 0xd0164878 in __assert_c99 () from /usr/lib/libs.a= (shr.o) No symbol table info available. #5 0x1000cbe4 in ch_malloc (size=3D8388608) at ch_mal= loc.c:57 new =3D (void *) 0x0 #6 0x1022a80c in search_stack (op=3D0x243de2d8) at se= arch.c:1013 bdb =3D (struct bdb_info *) 0x20188b98<= br> ret =3D (void *) 0x0 #7 0x1022ac0c in search_candidates (op=3D0x243de2d8, = rs=3D0x263ba824, e=3D0x263b9bc4, locker=3D0x51eadec0, ids=3D0x262f9bc4,= scopes=3D0x26379bc4) at search.c:1099 bdb =3D (struct bdb_info *) 0x20188b98<= br> rc =3D 640653952 depth =3D 3 f =3D {f_choice =3D 160, f_un =3D {f_un_result= =3D 640653996, f_un_desc =3D 0x262f9aac, f_un_ava =3D 0x262f9aac, f_un= _ssa =3D 0x262f9aac, f_un_mra =3D 0x262f9aac, f_un_complex =3D 0x262f9a= ac}, f_next =3D 0x0} rf =3D {f_choice =3D 163, f_un =3D {f_un_resul= t =3D 640654008, f_un_desc =3D 0x262f9ab8, f_un_ava =3D 0x262f9ab8, f_u= n_ssa =3D 0x262f9ab8, f_un_mra =3D 0x262f9ab8, f_un_complex =3D 0x262f9a= b8}, f_next =3D 0x286ef7dc} xf =3D {f_choice =3D 161, f_un =3D {f_un_resul= t =3D 640653972, f_un_desc =3D 0x262f9a94, f_un_ava =3D 0x262f9a94, f_u= n_ssa =3D 0x262f9a94, f_un_mra =3D 0x262f9a94, f_un_complex =3D 0x262f9a= 94}, f_next =3D 0x0} nf =3D {f_choice =3D 0, f_un =3D {f_un_result = =3D 0, f_un_desc =3D 0x0, f_un_ava =3D 0x0, f_un_ssa =3D 0x0, f_un_mra = =3D 0x0, f_un_complex =3D 0x0}, f_next =3D 0x262f9aa0} stack =3D (ID *) 0x1020cc58 aa_ref =3D {aa_desc =3D 0x200c0268, aa_value =3D= {bv_len =3D 8, bv_val =3D 0x102dbf2c "r\ef\erral"}}<b= r> sf =3D {f_choice =3D 0, f_un =3D {f_un_result = =3D 641440756, f_un_desc =3D 0x263b9bf4, f_un_ava =3D 0x263b9bf4, f_un_= ssa =3D 0x263b9bf4, f_un_mra =3D 0x263b9bf4, f_un_complex =3D 0x263b9b= f4}, f_next =3D 0x262f9ad0} aa_subentry =3D {aa_desc =3D 0x0, aa_value =3D= {bv_len =3D 0, bv_val =3D 0x0}} bv_ref =3D {bv_len =3D 8, bv_val =3D 0x102dbf2= c "r\ef\erral"} #8 0x10228ee4 in bdb_search (op=3D0x243de2d8, rs=3D0x= 263ba824) at search.c:578 bdb =3D (struct bdb_info *) 0x20188b98<= br> id =3D 0 cursor =3D 0 lastid =3D 4294967295 candidates =3D {0 <repeats 131072 times>= } scopes =3D {0 <repeats 63759 times>, 641= 435536, 0, 0, 0, 0, 4030840384, 0 <repeats 11 times>, 641435684, = 0 <repeats 206 times>, 641434560, 0 <repeats 11 times>, 641434656, 0, 0, 0, 6414= 34656, 4030840384, 3490904144, 0, 0, 4030840384, 0, 0, 0, 0, 0, 0, 6414= 34672, 0, 0, 0, 32, 58, 22528, 0, 0, 11, 58, 4030431112, 641434720, 25672581= 80, 3490905504, 0, 641434768, 4030840384, 4112, 0, 4030805596, 40304268= 72, 608034984, 959840256, 110, 608035812, 0, 0, 641434800, 0, 34909= 02496, 0, 641434800, 4030840384, 58, 22528, 0, 144, 0, 269721729, 26972= 1729, 4030854004, 3490917464, 0, 641434880, 4112, 58, 4030431112, 6414= 34880, 4030840384, 3490883944, 0, 641434896, 4030840384, 3490889600, 64= 1435752, 641434896, 4030840384, 3491274292, 0, 0, 641437345, 641437340, = 1, 0, 1, 4030431112, 4030431112, 641434960, 0, 3490885628, 641435752, 6= 41435008, 4030840384, 3491268044, 0, 641434976, 4030840384, 0, 0, 641434992= , 0, 0, 641435752, 641435008, 4031927728, 3491274292, 608035800, 641435= 072, 297, 3490878276, 0, 641435072, 4030840384, 3490889836, 0,= 641435072, 4030840384, 3490889600, 641435752, 641435648, 4030840384, 3= 491266240, 0, 0, 4030840384, 0, 14, 32, 608035800, 0, 0, 0, 0, 14, 14= , 641435168, 0, 3490878896, 0, 0, 4030840384, 0 <repeats 11 times&gt= ;, 608035800, 1, 0, 641437088...} e =3D (Entry *) 0x0 base =3D {e_id =3D 1, e_name =3D {bv_len =3D 6= 78360812, bv_val =3D 0x23a301e0 ""}, e_nname =3D {bv_len =3D = 23, bv_val =3D 0x243e94e8 "dc=3Dpva,dc=3Dsozv\ers= ,dc=3Dat"}, e_attrs =3D 0x3, e_ocflags =3D 641440736, e_bv =3D {bv= _len =3D 641440832, bv_val =3D 0xf041be40 ""}, e_private =3D 0x203a0f78} e_root =3D (Entry *) 0x2035880c matched =3D (Entry *) 0x0 ei =3D (EntryInfo *) 0x203a0f78 attrs =3D (AttributeName *) 0x0 realbase =3D {bv_len =3D 23, bv_val =3D 0x243e= 94e8 "dc=3Dpva,dc=3Dsozv\ers,dc=3Dat"} mask =3D 5119 stoptime =3D 1239955337 manageDSAit =3D 0 tentries =3D 0 nentries =3D 0 idflag =3D 0 locker =3D 0x51eadec0 lock =3D {off =3D 0, ndx =3D 412, gen =3D 7777= 0, mode =3D DB_LOCK_READ} opinfo =3D (struct bdb_op_info *) 0x0<b= r> ltid =3D (DB_TXN *) 0x0 oex =3D (OpExtra *) 0x0 stub =3D {bv_len =3D 4030851424, bv_val =3D 0x= 0} #9 0x100d66dc in overlay_op_walk (op=3D0x243de2d8, rs= =3D0x263ba824, which=3Dop_search, oi=3D0x20189d68, on=3D0x0) at backove= r.c:646 func =3D (BI_op_bind **) 0x200012b4 = rc =3D 32768 sc_next =3D (slap_callback *) 0x0 #10 0x100d691c in over_op_func (op=3D0x243de2d8, rs=3D= 0x263ba824, which=3Dop_search) at backover.c:698 oi =3D (slap_overinfo *) 0x20189d68 = on =3D (slap_overinst *) 0x20189e78 = be =3D (BackendDB *) 0x20187f68 db =3D {bd_info =3D 0x20001288, bd_self =3D 0x= 20187f68, be_ctrls =3D "\000\001\001\001\000\001\000\000\= 001\000\000\001\001\000\001", '\0' <repeats 17 times>, &quot= ;\001", be_flags =3D 2312, be_restrictops =3D 0, be_requires =3D 0, be_ssf_set =3D {sss_ssf =3D 0, ss= s_transport =3D 0, sss_tls =3D 0, sss_sasl =3D 0, sss_update_ssf =3D 0,= sss_update_transport =3D 0, sss_update_tls =3D 0, sss_update_sasl =3D 0, sss_s= imple_bind =3D 0}, be_suffix =3D 0x20183b08, be_nsuffix =3D 0x20189a28,= be_schemadn =3D {bv_len =3D 0, bv_val =3D 0x0}, be_schemandn =3D {bv_len =3D 0, b= v_val =3D 0x0}, be_rootdn =3D {bv_len =3D 34, bv_val =3D 0x20189ce8 "cn=3DManag\er,dc=3Dpva= ,dc=3Dsozv\ers,dc=3Dat"}, be_rootndn =3D {bv_len =3D 34,<br= > bv_val =3D 0x20189d38 "cn=3Dmanag\er,dc=3Dpva= ,dc=3Dsozv\ers,dc=3Dat"}, be_rootpw =3D {bv_len =3D 5, bv_val =3D = 0x20187138 "start"}, be_max_deref_depth =3D 15, be_def_limit =3D {lms_t_soft =3D 3600, lms_t_hard =3D= 0, lms_s_soft =3D -1, lms_s_hard =3D 0, lms_s_unchecked =3D -1, lms_s_= pr =3D 0, lms_s_pr_hide =3D 0, lms_s_pr_total =3D 0}, be_limits =3D 0x0, be_acl =3D= 0x2016b768, be_dfltaccess =3D ACL_READ, be_update_ndn =3D {bv_len =3D = 0, bv_val =3D 0x0}, be_update_refs =3D 0x0, be_pending_csn_list =3D 0x20= 356508, be_pcl_mutex =3D {__mt_word =3D {0, 0, 0, 1, 0, 1373, 0, 5, 0, = 0, 0, 0, 0}}, be_pcl_mutexp =3D 0x20188034, be_syncinfo =3D 0x0, b= e_pb =3D 0x0, be_cf_ocs =3D 0x2001b2a8, be_private =3D 0x20188b98, be_n= ext =3D {stqe_next =3D 0x20192308}} cb =3D {sc_next =3D 0x0, sc_response =3D @0x20= 01e51c: 0x100d553c <over_back_response>, sc_cleanup =3D @0x0: 0x1= , sc_private =3D 0x20189d68} rc =3D 32768 #11 0x100d6a84 in over_op_search (op=3D0x243de2d8, rs=3D= 0x263ba824) at backover.c:720 No locals. #12 0x100b3434 in fe_op_search (op=3D0x243de2d8, rs=3D= 0x263ba824) at search.c:366 bd =3D (BackendDB *) 0x20046498 entry =3D (Entry *) 0x1021638 #13 0x100b2b2c in do_search (op=3D0x243de2d8, rs=3D0x2= 63ba824) at search.c:217 base =3D {bv_len =3D 23, bv_val =3D 0x243e93ff= "dc=3Dpva,dc=3Dsozv\ers,dc=3Dat"} siz =3D 0 off =3D 0 i =3D 0 dummy =3D 0x5469746c <Address 0x5469746c ou= t of bounds> #14 0x1006c154 in connection_operation (ctx=3D0x263ba9= 5c, arg_v=3D0x243de2d8) at connection.c:1084 rc =3D 80 op =3D (Operation *) 0x243de2d8 rs =3D {sr_type =3D REP_RESULT, sr_tag =3D 0, = sr_msgid =3D 0, sr_err =3D 0, sr_matched =3D 0x0, sr_text =3D 0x0, sr_r= ef =3D 0x0, sr_ctrls =3D 0x0, sr_un =3D { sru_sasl =3D {r_sasldata =3D 0x0}, sru_extended =3D= {r_rspoid =3D 0x0, r_rspdata =3D 0x0}, sru_search =3D {r_entry =3D 0x0= , r_attr_flags =3D 0, r_operational_attrs =3D 0x0, r_attrs =3D 0x0, r_= nentries =3D 0, r_v2ref =3D 0x0}}, sr_flags =3D 0} tag =3D 99 opidx =3D SLAP_OP_SEARCH conn =3D (Connection *) 0x201bd448 memctx =3D (void *) 0x243de6b8 memctx_null =3D (void *) 0x0 memsiz =3D 1048576 curelm =3D (struct Operation *) 0x1 = #15 0x1006c848 in connection_read_thread (ctx=3D0x263b= a95c, argv=3D0x20) at connection.c:1211 rc =3D 0 cri =3D {op =3D 0x243de2d8, func =3D @0x0: 0x1= , arg =3D 0x0, ctx =3D 0x263ba95c, nullop =3D 0} s =3D 32 #16 0xd26daf88 in ldap_int_thread_pool_wrapper (xpool=3D= 0x200c9588) at tpool.c:663 pool =3D (struct ldap_int_thread_pool_s *) 0x2= 00c9588 task =3D (ldap_int_thread_task_t *) 0x23e43ae8= work_list =3D (ldap_int_tpool_plist_t *) 0x200= c961c ctx =3D {ltu_id =3D 1286, ltu_key =3D {{ltk_ke= y =3D 0x2001e2ac, ltk_data =3D 0x243de5a8, ltk_free =3D @0x2001e2b8: 0x= 1006b814 <conn_counter_destroy>}, {ltk_key =3D 0x2001e048, ltk_data =3D 0x243de6b8, = ltk_free =3D @0x2001e054: 0x1000a1e4 <slap_sl_mem_destroy>}, {ltk= _key =3D 0x20020b20, ltk_data =3D 0x0, ltk_free =3D @0x20020b2c: 0x10= 009864 <slap_op_q_destroy>}, {ltk_key =3D 0x20356518, ltk_data =3D= 0x51eadec0, ltk_free =3D @0x200201fc: 0x1020f550 <bdb_loc= ker_id_free>}, {ltk_key =3D 0x0, ltk_data =3D 0x0, ltk_free =3D @0x0= : 0x1} <repeats 28 times>}} kctx =3D (ldap_int_thread_userctx_t *) 0x0</fo= nt> i =3D 32 keyslot =3D 171 hash =3D 171 ptr_ =3D (const unsigned char *) 0x263ba95c &q= uot;" i_ =3D 4 #17 0xd048fc50 in _pthread_body () from /usr/lib/libpt= hread.a(shr_xpg5.o) No symbol table info available. Mit freundlichen Gr=FC=DFen<= b> Howard ALLISON <table border=3D"0" cellspacing=3D"0" cellpadding=3D"0"> <tr valign=3D"top"><td width=3D"95"><img src=3D"cid:1__=3D4EBBFF08DFA38= 8418f9e8a93d(a)pva.sozvers.at" width=3D"83" height=3D"52"></td><td width=3D= "237" valign=3D"middle">Pensionsversicherungsanstalt Rechenzentrumsbetrieb A-1021 Wien, Friedrich-Hillegeist-Stra=DFe 1 E-Mail..: <a href=3D"mailto:howard.allison@pva.sozvers.at"><f= ont size=3D"2" color=3D"#0000FF" face=3D"MS Sans Serif">howard.allison@= pva.sozvers.at</a><b= r> Internet: <a href=3D"http://www.pensionsversicherung.at/"><fo= nt size=3D"2" color=3D"#0000FF" face=3D"MS Sans Serif">www.pensionsvers= icherung.at</a></td></tr> </table> -------------------------- VERTRAULICHKEIT: Diese Nachricht ist ausschlie=DFlich f=FCr denjenigen = bestimmt, an den sie adressiert ist und kann vertrauliche Informationen enthalten. F= alls Sie nicht der Empf=E4nger dieser Nachricht sind, weisen wir Sie darauf hin, dass = die unberechtigte Weitergabe oder Verwendung sowie das unberechtigte Vertei= len oder Kopieren dieser Nachricht strikt untersagt sind. Falls Sie diese Nachri= cht irrt=FCmlich erhalten haben, vernichten Sie sie bitte sofort. CONFIDENTIALITY: This message is intended only for the use of the indiv= iduality or entity to which it is addressed and may contain information that is pri= vileged, confidential and exempt from disclosure. If you are not the intended re= cipient you are notified that any dissemination, distribution, use or copying of this c= ommunication is strictly prohibited. If you received this message in error, please imme= diately destroy this message. -------------------------- </body></html>= --1__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841-- --0__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841 Content-type: image/gif; name="18476766.gif" Content-Disposition: inline; filename="18476766.gif" Content-ID: <1__=4EBBFF08DFA388418f9e8a93d(a)pva.sozvers.at> Content-transfer-encoding: base64 R0lGODlhUwA0APcAAA4Rm9DR2jw/qpaYw3Z4sx4hoLy9zldZsIGDtTEzpbGyztbe3lBSr6ipyY+R vDg7p2xursnL1UZJqhgaoSosoEFDpsTF1dLT2hganp+iwIaIwmNmqyEpnGxvtnt8vbe40sHC0aap z1VXsklLpoeJuxwfn46QxZmZzF1fsdHS2WxuuTQ3piAjoSotpL6/09zd3kxPrRQXnVVYpmdptoqN vczMzKutzj0/p7i60nFztVRXrHp7tJqdwKqrxlpdskJFrJKUvn+AumJktdfY3LW2zYKFvZKUxqSl xr3F1khLrSQopM3O1igrpGpstpydxNbW1v4BAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIA AADYLuB3EgMwABIBAACV8AAAOQA8AAAAAACeAgAAAQAAAIhkWAAgwBUAqAZWAAIAAAC88hIA2Vi0 d9UHAYXk8hIAAgAAACj0EgAc8xIAotfhdxIDMAASAQAAlfAAADkAPAABAAAAEgEAAJXwAAASAzAA SLkVANi1FQAgACAAAAAVACAAIAAAABUARgBlAHIAdABpAGcAAAASAAAAAAD8iOd3AAAAAAAAAADV BwGFiGRYADzzEgDxoeF3EgMwAAIDJwASAQAAlfAAADkAPAAAABMAlfAAAKqHRQASAzAAAgMnAAAB AAAkAAAAOQA8AKEAAACIZFgApPYSABgVOwB3wrR3KAM4AGhWEwAgAQAA2LUVAAAAAAAAAAAA0PMS AJUriHcINoh3/////+DzEgAec+d3AAATAAgAFAAYAQAAbJxIAGibSACJOOh3AAAAAAAAAAAAAAAA AAAAAETaRABsnEgA9MIVAHlWEwB5m0gA/////2hWEwB32EQAbJxIACH5BAEAAFAALAAAAABTADQA QAj/AKEIHEiwoMGDCBMqXMiwYcIhAyRgmEixIgYWD1BosAEiwoUhIIc4hBJBAQ0hK2LE0KFgZMIB Fi22ADEywoyJNA42mWARwcENGDqIJBhgKMMHMZPONFjEYgeDFlpMuJHCIA0nBkEwSTqRREEaSiIk tLB14gAoDWIuLTgkgFu3LpygYMGTKxCEBOomDWIQJgAPLgewyNHQQhAdD1hwpaiycYkEhKGAqHrw QsQJE5QUCeCys+fPoEMvHBKXAGIlJVJjXjyxBIUbKIo0sCDaJQm6rHPr5lrAAMMIRIwyHAJDL9e1 nSFgaFkwAgXMP4QLhGmRCc2BATZcT5hgN/KRRBRT/9wwGgbrB0sKQpgQOWGAG5iPEBwCJEEBFwad xNgdk4XvgQ2UUN0O6RVkgASY+XBBbdJBMcQHNORAwABERNDgQhdYoIAJTVRQgkos6ECDCxfWZuKJ KIL2AQFI8TcRC0wkkMADNNLYAgsCVlTACCRslyJBNuWoWwEuUtSCBB04QZtCCnQgAQ2UfTbEDMZR VIAPMwih5ZZc+pBEWRMl0ASXWpqXlHw/EiTDfot955AQMWRg0BAjVITCQU1RNINwRGDFUBBVKuWj QDSUwMKhK/RgkAuHLklQDxgo4ehACghZUQJiYXeDotx5N6iDKYQaZUFO5AhDiUStwFpOBDkBgAkJ of+glw0osFmRmwsFgEJSgMUaKEUrZDrQERgAwBxCH4h3p0BHPIcZrgPYWmQDBgHxawFeNYcgAGc5 dIRi1DYUbZGXZkpEaiVIEMSnJHWQIw2oNgTCBuGmudASRzTRgkqQsWsvQhd8AEQODDzQQgFEWqRS ai3ccEAOAyhgQbz/VmzxxRhn7FAALjQAxA5CyMAADEmUnIQOKHRQxAAcLaixSwE0kMOX5LLWgg4k BPfyQBc4cYB4uSUggRBBsIyDBREsofTSFuBgwwBFzDBCdy/OcOy/R5hpsxAEEDDDAUnc8MAKZD9w gwQ6COEBEDZMrNAFRARRAQVC/HfiESv8WrN3OBf/iJAFJCCAH2hDdKD33kUuazEB0lZEgbAPgVDE A5itwFlzVFd0g8sEEdFtbQYoYbO/CeW1uUE2WGodVC1MhALnUKTQA8UANq4W6WOxAMNBNGAWn0Ep 3GBRtgMNgKZC5+qG6xIf4OC83wSlNcNBVE5QxEEMJNWeQA4IsZAOnhpEgkXTF2TBcz6x9cABP+l9 vEAo6KBQ5qP3ZfYNDn/qgugYfD4QSAbZweGu16oY2CAhrVMe7hIiBIqU4IALoc5i6iUQIMRgewVp 0UWaYCkjLdAgF0iCcZRgt4P0oIMW2QFbbvCqhPSOIgoAgRKqhKuEKEBrFrEcQvbHGh4YRAcxYALk /wxyk4kQUDC3+lQDEoC/G6wATKwZQYOWkIBfxWAH0gHBvlgAPbxgJgF+MwD4MIAr/exNcQIZgkRi UgFOAWkEE4iBUBxChBnKz3wkmJRAzLg3AhBkV0bKQQkH4oQqxmAGsPNWDH6QSIQMAACIwwABWZQD G1zoAkBo0Q8gGBob3ABWDkkBCBQwABJ4QAU+0IEqdXAAtRWBbS5YQrwiQIMfYEYJORgcii5whCGS JIa0GwlpBiCEBCwMBgPw5css4IQmwKACN4CBEHJQBCMcoQHYxKYTjFCEHAghCSsoQGOYAAMCNOCD O6tMBFygABs4wQRAiGcInBfLRqbznvjMZ4oCAgA7 --0__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841--

1 0

ITS#5860 slapd in openldap-2.4.16 still doesn't respect memory bounds
by linamat＠telco.md 17 Apr '09

17 Apr '09

I have tried openldap-2.4.16 (latest) BDB 4.7.25 with all patches from Oracle on Dell AMD64 RAM 4Gb, 8 CPUs, OS Solaris 10. According to ITS#5860 slapd should not allocate more memory than it was specified. In fact I have the same behaviour as it was with previous version (2.4.11). It correctly allocates 1.2 Gb via shared memory (for set_cachesize 300 MB). But slapd process continuosly grows in memory until 32-bit limit then crashes due to unavalable memory resources. I need to mention bdb database size is less then 1 GB. After restart it rapidly consumes 1.5 GB RSS in few minutes and then it grows beyond the limit during 24 hours. The more queries are processing the more memory it eats. I am using this database for logging which size grows. The question is: is it possible to use 32-bit openldap with relatively large database sizes that override 32-bit per-process memory space? My slapd.conf contains: threads 64 concurrency 50 cachesize 200000 dncachesize 400000 idlcachesize 600000 shm_key 10 DB_CONFIG: set_cachesize 0 300097152 1 set_lk_max_locks 1000000 set_lk_max_lockers 1000000 set_lk_max_objects 1000000 set_lg_regionmax 1048576 set_lg_max 10485760 set_lg_bsize 2097152 ls -ls ./openldap-data total 1212876 -rw-r--r-- 1 slapd nobody 640 Apr 17 08:42 DB_CONFIG -rw------- 1 slapd nobody 8 Apr 16 10:50 __db.001 -rw-r--r-- 1 slapd nobody 4096 Apr 16 10:50 alock -rw------- 1 slapd nobody 6053888 Apr 17 09:50 cn.bdb -rw------- 1 slapd nobody 1024000 Apr 17 09:50 dhcpHWAddress.bdb -rw------- 1 slapd nobody 96583680 Apr 17 09:50 dn2id.bdb -rw------- 1 slapd nobody 515637248 Apr 17 09:50 id2entry.bdb -rw------- 1 slapd nobody 1343488 Apr 17 09:50 objectClass.bdb Any help would be much appreciated. Regards, Sergey.

1 0

(ITS#6064) syncrepl.c does not compile ("//" comment)
by h.b.furuseth＠usit.uio.no 16 Apr '09

16 Apr '09

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard C89 chokes on this comment from syncrepl.c 1.445: // add new syncrepl to end of list (same order as when deleting) Fixing.

1 0

Re: (ITS#6063) Syncrepl replication be_modify failed (18)
by michael＠stroeder.com 16 Apr '09

16 Apr '09

wan(a)ccs.neu.edu wrote: > I've been battling some issues with syncrepl for a while now, and I > can't quite figure out what has gone wrong. > [..] > and am still having issues (now at > 2.4.15) Could you please try 2.4.16 released a couple of days ago? There were four syncrepl-related fixes in this release. Not sure whether one of the fixes really solves your particular problem but please give it a try. Maybe it would also help if you try to get more detailed logs by starting slapd with -d on the console. (You might also need to use -u and/or -g option to use the demon user.) Ciao, Michael.

1 0

Re: (ITS#6062) Compile failure in libraries/liblutil/getpeereid.c
by quanah＠zimbra.com 16 Apr '09

16 Apr '09

--On Wednesday, April 15, 2009 5:52 PM +0000 rps2(a)socal.rr.com wrote: > Full_Name: Rick Stevens > Version: 2.4.16 > OS: Fedora 10, x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (12.200.106.34) > > > Compilation fails when compiling the libraries/liblutil/getpeereid.c > file. Under Fedora 10, one must include the line: > > #define _GNU_SOURCE > > somewhere near the top of the file to ensure the system can pick up the > size of the "ucred" structure. This is a duplicate of ITS#5464 and will be closed. The fix will be in the next release. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6063) Syncrepl replication be_modify failed (18)
by wan＠ccs.neu.edu 15 Apr '09

15 Apr '09

Full_Name: Will Nowak Version: 2.4.15 OS: Ubuntu Hardy URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.239.45.4) [Creating an ITS issue of the email thread with the same subject] I've been battling some issues with syncrepl for a while now, and I can't quite figure out what has gone wrong. I initially found http://www.openldap.org/lists/openldap-software/200812/msg00040.html which seemed to describe my issue, and it recommended upgrading to openldap 2.4.13. I tried that, and am still having issues (now at 2.4.15). I built the software for ubuntu hardy on i386, available at https://edge.launchpad.net/~compbrain/+archive/ppa/+sourcepub/566951/+listi… The situation involves a master with 3 slaves using syncrepl. A change comes into the master adding a member to a nisNetgroup/groupOfNames hybrid container: dn: cn=friends,ou=netgroup,dc=example,dc=com objectClass: groupOfNames objectClass: nisNetgroup objectClass: top cn: friends member: uid=bobby,ou=people,dc=example,dc=com nisNetgroupTriple: (,bobby,shadow) An incoming add for user james looks like dn: cn=friends,ou=netgroup,dc=example,dc=com changetype: modify delete: member - add: member member: uid=bobby,ou=people,dc=example,dc=com member: uid=james,ou=people,dc=example,dc=com - delete: nisNetgroupTriple - add: nisNetgroupTriple nisNetgroupTriple: (,bobby,shadow) nisNetgroupTriple: (,james,shadow) Up until this point, everything is fine -- all changes made on the master have replicated ok to the slaves. Now, james is not my friend anymore, so he gets removed from the container: dn: cn=friends,ou=netgroup,dc=example,dc=com changetype: modify delete: member - add: member member: uid=bobby,ou=people,dc=example,dc=com - delete: nisNetgroupTriple - add: nisNetgroupTriple nisNetgroupTriple: (,bobby,shadow) At this point, the most recent change gets applied to the master ok, but it does not get replicated to the slaves. They have a be_modify failed in their logs: Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 be_search (0) Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 cn=friends,ou=netgroup,dc=example,dc=com Apr 13 23:05:43 sl1 slapd[30277]: null_callback : error code 0x12 Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 be_modify (18) Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 be_modify failed

1 0

(ITS#6062) Compile failure in libraries/liblutil/getpeereid.c
by rps2＠socal.rr.com 15 Apr '09

15 Apr '09

Full_Name: Rick Stevens Version: 2.4.16 OS: Fedora 10, x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.200.106.34) Compilation fails when compiling the libraries/liblutil/getpeereid.c file. Under Fedora 10, one must include the line: #define _GNU_SOURCE somewhere near the top of the file to ensure the system can pick up the size of the "ucred" structure.

1 0

(ITS#6061) ./configure messups on NDB and Perl backends
by rps2＠socal.rr.com 15 Apr '09

15 Apr '09

Full_Name: Rick Stevens Version: 2.4.16 OS: Fedora 10, x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.200.106.34) The help text in the configure script for OpenLDAP 2.4.16 states: --enable-ndb enable MySQL NDB Cluster backend no|yes|mod [no] ... --enable-perl enable perl backend no|yes|mod [no] Which indicate that, by default, the MySQL Cluster NDB and Perl back-ends will not be built. This is not the case. The system tries to configure those back-ends. The "make depend" completes normally, but the "make" aborts when trying to compile those back-ends. In the case of the Perl back-end, configure does not find the necessary headers and reports that fact, however it does not set flags to block compilation of that module. On a separate identical machine, I did install the items necessary to build those back-ends. However, the system can't find the necessary headers even though they exist. For NDB, one must install the "mysql-devel" RPM. However, the path for finding the headers isn't correct. On Fedora 10, the include path must include "-I/usr/include/mysql/ndb/ndbapi". For Perl, one must install the "perl-devel" RPM, and the path for finding headers must include "-I/usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/CORE".

1 0

Re: (ITS#6057) "slapo-rwm interferes with content-sensitive ACLs"
by ando＠sys-net.it 15 Apr '09

15 Apr '09

David wrote: > Yup this works, good work, thanks. > > Seems a tad slow though, do filters like these drastically slow down the > search? It applies some overhead: for each value of each attribute of each entry it needs to check whether the memberOf attr is present; if it is, a berval comparison is needed (compare the length first, and the value in case of match). As usual, it depends on the structure of your data. Also, but this is independent of ACL evaluation, slapo-rwm duplicates each entry as soon as it needs to do some manipulation on it (like massaging the DNs and so). If you notice any significant overhead, you might want to profile the execution of your slapd, to point out what's the actual bottleneck. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6057) "slapo-rwm interferes with content-sensitive ACLs"
by ando＠sys-net.it 15 Apr '09

15 Apr '09

David wrote: > Ok, so its probably a deeper rooted problem than 1st thought? Do you reckon > it would be a difficult fix? Please test HEAD (or import the latest fixes to servers/slapd/overlays/rwm.[ch] into 2.4.16, if you prefer). You need to add rwm-drop-unrequested-attrs no to your slapo-rwm configuration. I haven't documented this flag yet; I'd wait until the fix is confirmed. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6057) "slapo-rwm interferes with content-sensitive ACLs"
by hyc＠symas.com 15 Apr '09

15 Apr '09

ando(a)sys-net.it wrote: > David wrote: >> Ok, so its probably a deeper rooted problem than 1st thought? Do you reckon >> it would be a difficult fix? > > On the contrary, it could be relatively simple. I need to further > investigate what's happening, but I could easily reproduce the issue. > I'll be back. Fixing it for back-bdb/hdb is easy enough. For other backends that don't always return whole entries (e.g. back-ldap) there would be more problems. It's an open question whether we care about those at the moment... -- -- 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#6057) "slapo-rwm interferes with content-sensitive ACLs"
by ando＠sys-net.it 15 Apr '09

15 Apr '09

David wrote: > Ok, so its probably a deeper rooted problem than 1st thought? Do you reckon > it would be a difficult fix? On the contrary, it could be relatively simple. I need to further investigate what's happening, but I could easily reproduce the issue. I'll be back. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs