- openldap-bugs - openldap.org

Re: FW: (ITS#5941) Problem when stacking rwm and translucent overlays together
by masarati＠aero.polimi.it 06 Oct '10

06 Oct '10

> I installed the latest version currently available 2.4.23 > The same bug still exists in this version. > > So I can for sure say this is not related to ITS#6070 > > Since this is a major loss of functionality I would kindly ask someone to > h= > ave a deeper look at this. I confirm it is related to ITS#6070; only, that ITS could be fixed (read: worked around) differently. I don't think this qualifies as a "major loss of functionality" for the vast majority of the users of OpenLDAP. Solving this issue the right way (and few others) would require to advance OpenLDAP at least to 2.5 or 3.0, because a significant portion of the ABI would need to change, so do not expect to see it solved any soon. In the meanwhile, you can try to use an instance of back-ldap as the translucent local storage, and place slapo-rwm on the database of the remote server that acts as local. I haven't tested it, so there might be minor issues, but I don't expect anything like this one. p.

1 0

FW: (ITS#5941) Problem when stacking rwm and translucent overlays together
by wdh＠vasco.com 05 Oct '10

05 Oct '10

I installed the latest version currently available 2.4.23 The same bug still exists in this version. So I can for sure say this is not related to ITS#6070 Since this is a major loss of functionality I would kindly ask someone to h= ave a deeper look at this. Thanks Wouter=

1 0

Re: (ITS#5941) Problem when stacking rwm and translucent overlays together
by wdh＠vasco.com 05 Oct '10

05 Oct '10

--=-pjbfbkt+SDCV4FzF9Ohv Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit I'm hitting this bug also in Debian Lenny. Is this bug already fixed? It prevents me from implementing our OpenLDAP server. Thanks Wouter --=-pjbfbkt+SDCV4FzF9Ohv Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.28.3"> </HEAD> <BODY> I'm hitting this bug also in Debian Lenny. Is this bug already fixed? It prevents me from implementing our OpenLDAP server. Thanks Wouter </BODY> </HTML> --=-pjbfbkt+SDCV4FzF9Ohv--

1 0

(ITS#6665) back_ldap and back_meta chasing referrals authentication
by jsceballos＠gmail.com 05 Oct '10

05 Oct '10

Full_Name: Javier Sanz Version: 2.4.17 OS: Debian Linux 5.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.38.203.12) back_ldap and back_meta should be able to do a non-anonymous bind to the referrals returned by the external LDAP servers. This is a regression since 2.3, because the old directives "pseudorootdn" and "pseudorootpw" allowed specifying the binddn and password that would be used to chase the referrals, but their 2.4 replacements "idassert-bind" and "idassert-authzFrom" do not allow that, so these binds are always done anonymously.

1 0

(ITS#6664) Server control forwarding in back_meta and back_ldap
by jsceballos＠gmail.com 05 Oct '10

05 Oct '10

Full_Name: Javier Sanz Version: 2.4.17 OS: Debian Linux 5.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.38.203.12) back_meta and back_ldap should forward server controls that clients use in their queries to the corresponding external LDAP servers. For example, the inhability to send controls to external servers currently causes that RFC2696 paged results control cannot be used, so it is impossible to retrieve more results for a query than the page size configured in the external server, which often is not a big number.

1 0

Re: (ITS#6647) Overlay sssvlv is always loaded
by clem.oudot＠gmail.com 05 Oct '10

05 Oct '10

--=-sj86jeXTHEFBrrKIl07g Content-Type: text/plain; charset=utf-8 Content-ID: <1286271588.1952.3.camel@Nokia-N900-51-1> Content-Transfer-Encoding: 8bit ----- Message d'origine ----- > > > Please try this (nearly blind) patch > > > > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-14-sssvlv.1.pat…> > > > > and report through the ITS. Thanks, p. > > I note that I have messed things up a bit in cleanup; however, this > should not affect the testing of the functionality, except if you delete > the overlay from the configuration using back-config. If the patch works > fine, I'll fix that part. > Hi, sorry for this late reply. I tried the patch on 2.4.23 source code, the second hunk was not working, so I deleted it to apply the patch. I am not using cn=config anyway. After recompiling with your patch and --enable-overlays, all works fine: a search with sss extention returns success (and fails if the control is critical). So I think you can commit the code! Thanks, Clément. --=-sj86jeXTHEFBrrKIl07g Content-Type: text/html; charset=utf-8 Content-ID: <1286271588.1952.5.camel@Nokia-N900-51-1> Content-Transfer-Encoding: 8bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html><head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="generator" content="Osso Notes"> <title></title></head> <body> ----- Message d'origine ----- > > > Please try this (nearly blind) patch > > > > <<a href="ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-14-sssvlv.1.pat…">ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-14-sssvlv.1.pat…</a>; > > > > and report through the ITS.  Thanks, p. > > I note that I have messed things up a bit in cleanup; however, this > should not affect the testing of the functionality, except if you delete > the overlay from the configuration using back-config.  If the patch works > fine, I'll fix that part. > Hi, sorry for this late reply. I tried the patch on 2.4.23 source code, the second hunk was not working, so I deleted it to apply the patch. I am not using cn=config anyway. After recompiling with your patch and --enable-overlays, all works fine: a search with sss extention returns success (and fails if the control is critical). So I think you can commit the code! Thanks, Clément. </body> </html> --=-sj86jeXTHEFBrrKIl07g--

1 0

(ITS#6663) refint not altering last attribute on delete
by knewell＠math.arizona.edu 04 Oct '10

04 Oct '10

Full_Name: Karl Newell Version: 2.4.21 OS: Ubuntu 10.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.196.224.235) refint does not alter the value of an attribute to refint_nothing when the last "member" of a group is deleted. refint is working when the dn of a member is modified. slapd.conf: loglevel 16383 ... moduleload refint ... overlay refint refint_attributes member uniqueMember seeAlso refint_nothing cn=Manager,dc=math,dc=arizona,dc=edu ... ldap.log (what I believe to be the relevant entries): ... Oct 4 14:12:03 vm-ldap slapd[8744]: refint_search_cb <cn=LDAP Admins,ou=Groups,dc=math,dc=arizona,dc=edu> Oct 4 14:12:03 vm-ldap slapd[8744]: refint_search_cb: uniqueMember: uid=atb,ou=Users,dc=math,dc=arizona,dc=edu (#1) Oct 4 14:12:03 vm-ldap slapd[8744]: send_ldap_result: conn=-1 op=0 p=0 Oct 4 14:12:03 vm-ldap slapd[8744]: send_ldap_result: err=0 matched="" text="" Oct 4 14:12:03 vm-ldap slapd[8744]: refint_search_cb <NOTHING> Oct 4 14:12:03 vm-ldap slapd[8744]: hdb_modify: cn=LDAP Admins,ou=Groups,dc=math,dc=arizona,dc=edu Oct 4 14:12:03 vm-ldap slapd[8744]: bdb_dn2entry("cn=ldap admins,ou=groups,dc=math,dc=arizona,dc=edu") Oct 4 14:12:03 vm-ldap slapd[8744]: bdb_modify_internal: 0x00000008: cn=LDAP Admins,ou=Groups,dc=math,dc=arizona,dc=edu Oct 4 14:12:03 vm-ldap slapd[8744]: <= acl_access_allowed: granted to database root Oct 4 14:12:03 vm-ldap slapd[8744]: bdb_modify_internal: delete uniqueMember Oct 4 14:12:03 vm-ldap slapd[8744]: dnMatch 0#012#011"uid=atb,ou=users,dc=math,dc=arizona,dc=edu"#012#011"uid=atb,ou=users,dc=math,dc=arizona,dc=edu" Oct 4 14:12:03 vm-ldap slapd[8744]: bdb_modify_internal: replace modifiersName Oct 4 14:12:03 vm-ldap slapd[8744]: bdb_modify_internal: delete uniqueMember Oct 4 14:12:03 vm-ldap slapd[8744]: bdb_modify_internal: 16 modify/delete: uniqueMember: no such attribute Oct 4 14:12:03 vm-ldap slapd[8744]: hdb_modify: modify failed (16) Oct 4 14:12:03 vm-ldap slapd[8744]: send_ldap_result: conn=-1 op=0 p=0 Oct 4 14:12:03 vm-ldap slapd[8744]: send_ldap_result: err=16 matched="" text="modify/delete: uniqueMember: no such attribute" Oct 4 14:12:03 vm-ldap slapd[8744]: refint_repair: dependent modify failed: 16 ...

1 0

Re: (ITS#6660) paged result searches fail to deallocate memory until slapd shutdown
by quanah＠zimbra.com 30 Sep '10

30 Sep '10

--On Thursday, September 30, 2010 11:14 AM +0000 masarati(a)aero.polimi.it wrote: > There's no mention of overlays; I was wondering whether or not it could be > related to some adverse interaction, e.g. with sssvlv, which has some > paged-results specific code. Can you also post on overlays either global > or specific to "olcDatabase={2}hdb"? There are no overlays being used. ;) As I said, a very vanilla config. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

RE: ITS#6661 (Was: FW: (6661))
by masarati＠aero.polimi.it 30 Sep '10

30 Sep '10

Should be fine now. The whole thing originated from the fact that be_rootdn_bind() was passed a NULL SlapReply* without handling results accordingly. Thanks, p. > Yes it is fixed, > > But in your fix, only the rootpw password works. If we have the rootdn > also as a dn stored inside the ldap tree then openldap does not tries to > bind to the dn of the tree if the rootpw is incorrect > > if we use the same code segment of bind.cpp written for back-bdb which is: > > /* allow noauth binds */ > switch ( be_rootdn_bind( op, NULL ) ) { > case LDAP_SUCCESS: > /* frontend will send result */ > return rs->sr_err; > default: > break; > } > And the rootpw is not matched, then slapd will continue to search the ldap > tree and if it finds a dn and its userPassword matches, then it > authenticates. If an appropriate dn / password is not found in the tree, > then it throughs the invalid credentials error. > > Maybe the bind-dbd way is more correct? > >

1 0

RE: ITS#6661 (Was: FW: (6661))
by gtzanetis＠pylones.gr 30 Sep '10

30 Sep '10

Yes it is fixed, But in your fix, only the rootpw password works. If we have the rootdn also= as a dn stored inside the ldap tree then openldap does not tries to bind t= o the dn of the tree if the rootpw is incorrect if we use the same code segment of bind.cpp written for back-bdb which is: /* allow noauth binds */ switch ( be_rootdn_bind( op, NULL ) ) { case LDAP_SUCCESS: /* frontend will send result */ return rs->sr_err; default: break; } And the rootpw is not matched, then slapd will continue to search the ldap = tree and if it finds a dn and its userPassword matches, then it authenticat= es. If an appropriate dn / password is not found in the tree, then it throu= ghs the invalid credentials error. Maybe the bind-dbd way is more correct?

1 0

Re: (ITS#6660) paged result searches fail to deallocate memory until slapd shutdown
by hyc＠symas.com 30 Sep '10

30 Sep '10

masarati(a)aero.polimi.it wrote: >> --On Wednesday, September 29, 2010 8:34 PM +0200 masarati(a)aero.polimi.it >> wrote: >> >>>> --On Wednesday, September 29, 2010 12:38 AM +0000 quanah(a)zimbra.com >>>> wrote: >>>> >>>>> It appears to be a problem with the entry cache, which is set to >>>>> 25,000: >>>> >>>> Running with a fix from Howard, the entry cache behaves correctly. >>>> However, slapd still grows at the same rate. >>>> >>>> If I limit to only 10 paged results searches, slapd grows at a rate of >>>> 300MB Virtual and 300MB Resident for every set of 10 paged results >>>> searches >>>> I do concurrently, up until I run slapd out of memory. There's >>>> something >>>> very wrong with paged results searches. >>> >>> Could it be configuration-specific? I tested with a plain configuration >>> resulting from test003; maybe some player in the middle, say, is causing >>> entries to be duplicated and leaked, or read-locks on originals are not >>> released correctly? Can you post a configuration that shows the issue? >> >> Hi Pierangelo, >> >> My testing shows the issue is only really visible with large databases >> that >> return giant result sets. I don't expect you to see it with a small >> database and test003, because the amount of "lost" memory will be a few >> bytes at best. > > If it's something related to bdb's cache size I agree; if it's related to > paged results I'd expect to notice it anyway using valgrind or so. > There's no actual leak, so valgrind won't point anything out. It's simply an issue with the entry cache not running its purge in some cases where it needs to. cn=monitor shows that the entry cache grows far beyond its configured size. Still looking into a proper fix. -- -- 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#6660) paged result searches fail to deallocate memory until slapd shutdown
by masarati＠aero.polimi.it 30 Sep '10

30 Sep '10

> --On Wednesday, September 29, 2010 8:34 PM +0200 masarati(a)aero.polimi.it > wrote: > >>> --On Wednesday, September 29, 2010 12:38 AM +0000 quanah(a)zimbra.com >>> wrote: >>> >>>> It appears to be a problem with the entry cache, which is set to >>>> 25,000: >>> >>> Running with a fix from Howard, the entry cache behaves correctly. >>> However, slapd still grows at the same rate. >>> >>> If I limit to only 10 paged results searches, slapd grows at a rate of >>> 300MB Virtual and 300MB Resident for every set of 10 paged results >>> searches >>> I do concurrently, up until I run slapd out of memory. There's >>> something >>> very wrong with paged results searches. >> >> Could it be configuration-specific? I tested with a plain configuration >> resulting from test003; maybe some player in the middle, say, is causing >> entries to be duplicated and leaked, or read-locks on originals are not >> released correctly? Can you post a configuration that shows the issue? > > Hi Pierangelo, > > My testing shows the issue is only really visible with large databases > that > return giant result sets. I don't expect you to see it with a small > database and test003, because the amount of "lost" memory will be a few > bytes at best. If it's something related to bdb's cache size I agree; if it's related to paged results I'd expect to notice it anyway using valgrind or so. > My configuration itself is very minimal, but it is in cn=config format. ;) > > dn: olcDatabase={2}hdb > objectClass: olcDatabaseConfig > objectClass: olcHdbConfig > olcDatabase: {2}hdb > olcSuffix: > olcAccess: {0}to attrs=userPassword by anonymous auth by > dn.children="cn=adm > ins,cn=zimbra" write > olcAccess: {1}to dn.subtree="cn=zimbra" by > dn.children="cn=admins,cn=zimbra" > write > olcAccess: {2}to > attrs=zimbraZimletUserProperties,zimbraGalLdapBindPassword,zi > mbraGalLdapBindDn,zimbraAuthTokenKey,zimbraPreAuthKey,zimbraPasswordHistory, > z > imbraIsAdminAccount,zimbraAuthLdapSearchBindPassword by > dn.children="cn=admi > ns,cn=zimbra" write by * none > olcAccess: {3}to attrs=objectclass by dn.children="cn=admins,cn=zimbra" > write > by dn.base="uid=zmpostfix,cn=appaccts,cn=zimbra" read by > dn.base="uid=zmam > avis,cn=appaccts,cn=zimbra" read by users read by * none > olcAccess: {4}to attrs=@amavisAccount by > dn.children="cn=admins,cn=zimbra" > wr > ite by dn.base="uid=zmamavis,cn=appaccts,cn=zimbra" read by * +0 break > olcAccess: {5}to attrs=mail by dn.children="cn=admins,cn=zimbra" write > by > dn > .base="uid=zmamavis,cn=appaccts,cn=zimbra" read by * +0 break > olcAccess: {6}to attrs=zimbraAllowFromAddress by > dn.children="cn=admins,cn=zi > mbra" write by dn.base="uid=zmpostfix,cn=appaccts,cn=zimbra" read by * > none > olcAccess: {7}to filter="(!(zimbraHideInGal=TRUE))" > attrs=cn,co,company,dc,di > splayName,givenName,gn,initials,l,mail,o,ou,physicalDeliveryOfficeName,posta > l > Code,sn,st,street,streetAddress,telephoneNumber,title,uid,homePhone,mobile,p > a > ger by dn.children="cn=admins,cn=zimbra" write by > dn.base="uid=zmpostfix,cn > =appaccts,cn=zimbra" read by users read by * none > olcAccess: {8}to > attrs=zimbraId,zimbraMailAddress,zimbraMailAlias,zimbraMailCa > nonicalAddress,zimbraMailCatchAllAddress,zimbraMailCatchAllCanonicalAddress, > z > imbraMailCatchAllForwardingAddress,zimbraMailDeliveryAddress,zimbraMailForwa > r > dingAddress,zimbraPrefMailForwardingAddress,zimbraMailHost,zimbraMailStatus, > z > imbraMailTransport,zimbraDomainName,zimbraDomainType,zimbraPrefMailLocalDeli > v > eryDisabled by dn.children="cn=admins,cn=zimbra" write by > dn.base="uid=zmpo > stfix,cn=appaccts,cn=zimbra" read by * none > olcAccess: {9}to attrs=entry by dn.children="cn=admins,cn=zimbra" write > by * > read > olcLastMod: TRUE > olcMaxDerefDepth: 15 > olcReadOnly: FALSE > olcRootDN: cn=config > olcSizeLimit: unlimited > olcTimeLimit: unlimited > olcMonitoring: TRUE > olcDbDirectory: /opt/zimbra/data/ldap/hdb/db > olcDbCacheSize: 25000 > olcDbCheckpoint: 64 5 > olcDbConfig: {0}# > olcDbConfig: {1}# Set the database in memory cache size. > olcDbConfig: {2}# > olcDbConfig: {3}set_cachesize 0 52428800 0 > olcDbConfig: {4} > olcDbConfig: {5}# > olcDbConfig: {6}# Set database flags. > olcDbConfig: {7}# Automatically remove log files that are no longer > needed. > olcDbConfig: {8}set_log_config DB_LOG_AUTO_REMOVE > olcDbConfig: {9} > olcDbConfig: {10}# > olcDbConfig: {11}# Set log values. > olcDbConfig: {12}# > olcDbConfig: {13}set_lg_regionmax 262144 > olcDbConfig: {14}set_lg_max 10485760 > olcDbConfig: {15}set_lg_bsize 2097152 > olcDbConfig: {16}set_lg_dir /opt/zimbra/data/ldap/hdb/logs > olcDbConfig: {17}# Increase locks > olcDbConfig:: ezE4fXNldF9sa19tYXhfbG9ja3MJMzAwMA== > olcDbConfig:: ezE5fXNldF9sa19tYXhfb2JqZWN0cwkxNTAw > olcDbConfig:: ezIwfXNldF9sa19tYXhfbG9ja2VycwkxNTAw > olcDbNoSync: FALSE > olcDbDirtyRead: FALSE > olcDbIDLcacheSize: 25000 > olcDbIndex: objectClass eq > olcDbIndex: entryUUID eq > olcDbIndex: entryCSN eq > olcDbIndex: cn pres,eq,sub > olcDbIndex: uid pres,eq > olcDbIndex: zimbraForeignPrincipal eq > olcDbIndex: zimbraYahooId eq > olcDbIndex: zimbraId eq > olcDbIndex: zimbraVirtualHostname eq > olcDbIndex: zimbraVirtualIPAddress eq > olcDbIndex: zimbraMailDeliveryAddress eq,sub > olcDbIndex: zimbraAuthKerberos5Realm eq > olcDbIndex: zimbraMailForwardingAddress eq > olcDbIndex: zimbraMailCatchAllAddress eq,sub > olcDbIndex: zimbraShareInfo sub > olcDbIndex: zimbraMailTransport eq > olcDbIndex: zimbraMailAlias eq,sub > olcDbIndex: zimbraACE sub > olcDbIndex: zimbraDomainName eq,sub > olcDbIndex: mail pres,eq,sub > olcDbIndex: zimbraCalResSite eq,sub > olcDbIndex: givenName pres,eq,sub > olcDbIndex: displayName pres,eq,sub > olcDbIndex: sn pres,eq,sub > olcDbIndex: zimbraCalResRoom eq,sub > olcDbIndex: zimbraCalResCapacity eq > olcDbIndex: zimbraCalResBuilding eq,sub > olcDbIndex: zimbraCalResFloor eq,sub > olcDbLinearIndex: FALSE > olcDbMode: 0600 > olcDbSearchStack: 16 > olcDbShmKey: 0 > olcDbCacheFree: 1000 > olcDbDNcacheSize: 0 > structuralObjectClass: olcHdbConfig > entryUUID: 152ab0a8-333e-102d-8700-d562901af228 > creatorsName: cn=config > createTimestamp: 20081020215916Z > entryCSN: 20081020215916.275992Z#000000#000#000000 > modifiersName: cn=config > modifyTimestamp: 20081020215916Z There's no mention of overlays; I was wondering whether or not it could be related to some adverse interaction, e.g. with sssvlv, which has some paged-results specific code. Can you also post on overlays either global or specific to "olcDatabase={2}hdb"? p.

1 0

ITS#6661 (Was: FW: (6661))
by masarati＠aero.polimi.it 30 Sep '10

30 Sep '10

> Hi Pierangelo, > > I replied to the ticket's list but I forgot to include your address. > > Here is my reply if you care to read it, > > Regards, > > George > > > > -----Original Message----- > From: George Tzanetis > Sent: Thursday, September 30, 2010 10:37 AM > To: 'openldap-its(a)openldap.org' > Subject: (ITS#6661) > > Hi, > > I built openldap using the new code. The rootpw now works, but if a wrong > password in an ldap query, then the ldap query process locks. > > e.g.: > with rootdn: 'cn=root,dc=example,dc=gr' > and rootpw: secret > > -when rootdn and rootpw are correct: > ldapwhoami -h 192.168.6.10 -D 'cn=root,dc=example,dc=gr' -w 'secret' >>dn:cn=root,dc=example,dc=gr > > -when rootdn is wrong: > Ldapwhoami -h 192.168.6.10 -D 'cn=root,dc=example,dc=com' -w 'secret' >>ldap_bind: Invalid credentials (49) > > -when rootdn is correct and rootpw is wrong > Ldapwhoami -h 192.168.6.10 -D 'cn=root,dc=example,dc=com' -w 'secret1' > "NO RESULT, the ldapwhoami locks" > > > Here are the logs of the slapd process: > > > ################################### > #with correct rootdn & rootpw # > ################################### > daemon: activity on 1 descriptor > daemon: activity on: > slap_listener_activate(8): > daemon: epoll: listen=7 active_threads=0 tvp=NULL > daemon: epoll: listen=8 busy >>>> slap_listener(ldap:///) > daemon: activity on 1 descriptor > daemon: activity on: > daemon: epoll: listen=7 active_threads=0 tvp=NULL > daemon: epoll: listen=8 active_threads=0 tvp=NULL > daemon: listen=8, new connection on 23 > daemon: activity on 1 descriptor > daemon: activity on: 23r > daemon: read active on 23 > daemon: added 23r (active) listener=(nil) > daemon: epoll: listen=7 active_threads=0 tvp=NULL > daemon: epoll: listen=8 active_threads=0 tvp=NULL > daemon: activity on 1 descriptor > daemon: activity on: > daemon: epoll: listen=7 active_threads=0 tvp=NULL > daemon: epoll: listen=8 active_threads=0 tvp=NULL > conn=1000 fd=23 ACCEPT from IP=192.168.6.10:47722 (IP=0.0.0.0:389) > connection_get(23) > connection_get(23): got connid=1000 > connection_read(23): checking for input on id=1000 > ber_get_next > ldap_read: want=8, got=8 > ldap_read: want=36, got=36 > ber_get_next: tag 0x30 len 42 contents: > ber_dump: buf=0x1d047ee0 ptr=0x1d047ee0 end=0x1d047f0a len=42 > op tag 0x60, time 1285831215 > ber_get_next > ldap_read: want=8 error=Resource temporarily unavailable > daemon: activity on 1 descriptor > daemon: activity on: > daemon: epoll: listen=7 active_threads=0 tvp=NULL > daemon: epoll: listen=8 active_threads=0 tvp=NULL > conn=1000 op=0 do_bind > ber_scanf fmt ({imt) ber: > ber_dump: buf=0x1d047ee0 ptr=0x1d047ee3 end=0x1d047f0a len=39 > ber_scanf fmt (m}) ber: > ber_dump: buf=0x1d047ee0 ptr=0x1d047f01 end=0x1d047f0a len=9 >>>> dnPrettyNormal: <cn=root,dc=example,dc=gr> > => ldap_bv2dn(cn=root,dc=example,dc=gr,0) > <= ldap_bv2dn(cn=root,dc=example,dc=gr)=0 > => ldap_dn2bv(272) > <= ldap_dn2bv(cn=root,dc=example,dc=gr)=0 > => ldap_dn2bv(272) > <= ldap_dn2bv(cn=root,dc=example,dc=gr)=0 > <<< dnPrettyNormal: <cn=root,dc=example,dc=gr>, <cn=root,dc=example,dc=gr> > conn=1000 op=0 BIND dn="cn=root,dc=example,dc=gr" method=128 > do_bind: version=3 dn="cn=root,dc=example,dc=gr" method=128 > ==> ndb_back_bind: dn: cn=root,dc=example,dc=gr > conn=1000 op=0 BIND dn="cn=root,dc=example,dc=gr" mech=SIMPLE ssf=0 > do_bind: v3 bind: "cn=root,dc=example,dc=gr" to "cn=root,dc=example,dc=gr" > send_ldap_result: conn=1000 op=0 p=3 > send_ldap_result: err=0 matched="" text="" > send_ldap_response: msgid=1 tag=97 err=0 > ber_flush2: 14 bytes to sd 23 > ldap_write: want=14, written=14 > conn=1000 op=0 RESULT tag=97 err=0 text= > daemon: activity on 1 descriptor > daemon: activity on: 23r > daemon: read active on 23 > daemon: epoll: listen=7 active_threads=0 tvp=NULL > daemon: epoll: listen=8 active_threads=0 tvp=NULL > connection_get(23) > connection_get(23): got connid=1000 > connection_read(23): checking for input on id=1000 > ber_get_next > ldap_read: want=8, got=8 > ldap_read: want=24, got=24 > ber_get_next: tag 0x30 len 30 contents: > ber_dump: buf=0x1d045c10 ptr=0x1d045c10 end=0x1d045c2e len=30 > op tag 0x77, time 1285831215 > ber_get_next > ldap_read: want=8 error=Resource temporarily unavailable > daemon: activity on 1 descriptor > daemon: activity on: > daemon: epoll: listen=7 active_threads=0 tvp=NULL > daemon: epoll: listen=8 active_threads=0 tvp=NULL > conn=1000 op=1 do_extended > ber_scanf fmt ({m) ber: > ber_dump: buf=0x1d045c10 ptr=0x1d045c13 end=0x1d045c2e len=27 > conn=1000 op=1 EXT oid=1.3.6.1.4.1.4203.1.11.3 > do_extended: oid=1.3.6.1.4.1.4203.1.11.3 > conn=1000 op=1 WHOAMI > send_ldap_extended: err=0 oid= len=26 > send_ldap_response: msgid=2 tag=120 err=0 > ber_flush2: 42 bytes to sd 23 > ldap_write: want=42, written=42 > conn=1000 op=1 RESULT oid= err=0 text= > daemon: activity on 1 descriptor > daemon: activity on: 23r > daemon: read active on 23 > daemon: epoll: listen=7 active_threads=0 tvp=NULL > daemon: epoll: listen=8 active_threads=0 tvp=NULL > connection_get(23) > connection_get(23): got connid=1000 > connection_read(23): checking for input on id=1000 > ber_get_next > ldap_read: want=8, got=7 > ber_get_next: tag 0x30 len 5 contents: > ber_dump: buf=0x1d045c10 ptr=0x1d045c10 end=0x1d045c15 len=5 > op tag 0x42, time 1285831215 > ber_get_next > ldap_read: want=8, got=0 > > ber_get_next on fd 23 failed errno=0 (Success) > connection_read(23): input error=-2 id=1000, closing. > connection_closing: readying conn=1000 sd=23 for close > daemon: activity on 1 descriptor > daemon: activity on: > daemon: epoll: listen=7 active_threads=0 tvp=NULL > daemon: epoll: listen=8 active_threads=0 tvp=NULL > connection_close: deferring conn=1000 sd=23 > conn=1000 op=2 do_unbind > conn=1000 op=2 UNBIND > connection_resched: attempting closing conn=1000 sd=23 > connection_close: conn=1000 sd=23 > daemon: removing 23 > conn=1000 fd=23 closed > > > ########################################## > #with correct rootdn & incorrect rootpw # > ########################################## > daemon: activity on 1 descriptor > daemon: activity on: > slap_listener_activate(8): > daemon: epoll: listen=7 active_threads=0 tvp=NULL > daemon: epoll: listen=8 busy >>>> slap_listener(ldap:///) > daemon: listen=8, new connection on 23 > daemon: added 23r (active) listener=(nil) > conn=1001 fd=23 ACCEPT from IP=192.168.6.10:47723 (IP=0.0.0.0:389) > daemon: activity on 2 descriptors > daemon: activity on: 23r > daemon: read active on 23 > daemon: epoll: listen=7 active_threads=0 tvp=NULL > daemon: epoll: listen=8 active_threads=0 tvp=NULL > connection_get(23) > connection_get(23): got connid=1001 > connection_read(23): checking for input on id=1001 > ber_get_next > ldap_read: want=8, got=8 > ldap_read: want=37, got=37 > ber_get_next: tag 0x30 len 43 contents: > ber_dump: buf=0x1d0460b0 ptr=0x1d0460b0 end=0x1d0460db len=43 > op tag 0x60, time 1285831240 > ber_get_next > ldap_read: want=8 error=Resource temporarily unavailable > conn=1001 op=0 do_bind > ber_scanf fmt ({imt) ber: > ber_dump: buf=0x1d0460b0 ptr=0x1d0460b3 end=0x1d0460db len=40 > ber_scanf fmt (m}) ber: > ber_dump: buf=0x1d0460b0 ptr=0x1d0460d1 end=0x1d0460db len=10 >>>> dnPrettyNormal: <cn=root,dc=example,dc=gr> > => ldap_bv2dn(cn=root,dc=example,dc=gr,0) > <= ldap_bv2dn(cn=root,dc=example,dc=gr)=0 > => ldap_dn2bv(272) > <= ldap_dn2bv(cn=root,dc=example,dc=gr)=0 > => ldap_dn2bv(272) > <= ldap_dn2bv(cn=root,dc=example,dc=gr)=0 > <<< dnPrettyNormal: <cn=root,dc=example,dc=gr>, <cn=root,dc=example,dc=gr> > conn=1001 op=0 BIND dn="cn=root,dc=example,dc=gr" method=128 > do_bind: version=3 dn="cn=root,dc=example,dc=gr" method=128 > ==> ndb_back_bind: dn: cn=root,dc=example,dc=gr > daemon: activity on 1 descriptor > daemon: activity on: > daemon: epoll: listen=7 active_threads=0 tvp=NULL > daemon: epoll: listen=8 active_threads=0 tvp=NULL Should be re-fixed now, sorry. Thanks for the report. p.

1 0

(ITS#6662) ldapsearch with slapd-ndb only works when filter is a substring
by gtzanetis＠pylones.gr 30 Sep '10

30 Sep '10

Full_Name: George Tzanetis Version: 2.4.23 stable OS: Red Hat Enterprise 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.169.213.126) It seems that when using slapd-ndb the filters in ldapsearches only work if they are substrings. i.e *text or text* or te*xt for attributes that are not defined as indices. If the attribute is defined as an index then the substring filter does not work, as indicate in the manual. The slapd.conf is as follows: pidfile /usr/local/openldap/var/run/slapd.pid argsfile /usr/local/openldap/var/run/slapd.args ####################################################################### # NDB database definitions ####################################################################### #NDB database defintions database ndb suffix "dc=example,dc=gr" rootdn "cn=root,dc=example,dc=gr" rootpw secret dbconnect 192.168.6.11 dbhost 192.168.6.12 dbport 3306 dbname openldap dbuser ldapUser dbpass "1234" dbconnections 3 dbsocket /tmp/mysql.sock attrblob description index uid ####################################################################### # Monitor Database definitions ####################################################################### database monitor loglevel 5 The ldif of an ou: version: 1 dn: ou=test,dc=example,dc=gr objectClass: top objectClass: organizationalUnit ou: test dn: uid=user1,ou=test,dc=example,dc=gr objectClass: top objectClass: inetOrgPerson objectClass: posixAccount cn: user1 gidNumber: -1 givenName: user1 homeDirectory: * sn: user1 uid: user1 uidNumber: -1 userPassword:: 1234 dn: uid=user2,ou=test,dc=example,dc=gr objectClass: top objectClass: inetOrgPerson objectClass: posixAccount cn: user2 gidNumber: -1 givenName: user2 homeDirectory: * sn: user2 uid: user2 uidNumber: -1 userPassword:: 1234 dn: uid=user3,ou=test,dc=example,dc=gr objectClass: top objectClass: inetOrgPerson objectClass: posixAccount cn: user3 gidNumber: -1 givenName: user3 homeDirectory: * sn: user3 uid: user3 uidNumber: -1 userPassword:: 1234 dn: uid=user4,ou=test,dc=example,dc=gr objectClass: top objectClass: inetOrgPerson objectClass: posixAccount cn: user4 gidNumber: -1 givenName: user4 homeDirectory: * sn: user4 uid: user4 uidNumber: -1 userPassword:: 1234 the ldapsearch queries: -search with specific cn inside the ou: --------------------------------------------------------------------- ldapsearch -h 192.168.132.177 -b 'ou=test,dc=example,dc=gr' -D "cn=root,dc=example,dc=gr" -L -w 'secret' "cn=user1" version: 1 # # LDAPv3 # base <ou=test,dc=example,dc=gr> with scope subtree # filter: cn=user1 # requesting: ALL # # search result # numResponses: 1 --------------------------------------------------------------------- No result but if we search the cn as a substring: --------------------------------------------------------------------- ldapsearch -h 192.168.132.177 -b 'ou=test,dc=example,dc=gr' -D "cn=root,dc=example,dc=gr" -L -w 'secret1' "cn=user1*" version: 1 # # LDAPv3 # base <ou=test,dc=example,dc=gr> with scope subtree # filter: cn=user1* # requesting: ALL # # user1@test, test, example.gr dn: uid=user1@test,ou=test,dc=example,dc=gr objectClass: top objectClass: inetOrgPerson objectClass: posixAccount userPassword:: 1234 sn: user1 cn: user1 uid: user1@test givenName: user1 uidNumber: -1 gidNumber: -1 homeDirectory: * # search result # numResponses: 2 # numEntries: 1 --------------------------------------------------------------------- any substring will give a result i.e. cn=*user1, cn=user1*, cn=us*er1 etc. if we search for cn=user* it will display all entries of the ou as expected. The same behavior exists if we filter using any other attribute with the exception of the objectClass attribute, or with the uid attribute which is indexed. Is this normal? Thank you, George

1 0

(ITS#6626)
by gtzanetis＠pylones.gr 30 Sep '10

30 Sep '10

I wanted to add that I do not find the contextCSN attribute anywhere inside= the database schema that the slapd-ndb backend creates. Maybe that is the reason I get the segmentation fault every time the slapd = process tries to update this attribute?

1 0

(ITS#6661)
by gtzanetis＠pylones.gr 30 Sep '10

30 Sep '10

Hi, I built openldap using the new code. The rootpw now works, but if a wrong p= assword in an ldap query, then the ldap query process locks. e.g.: with rootdn: 'cn=3Droot,dc=3Dexample,dc=3Dgr' and rootpw: secret -when rootdn and rootpw are correct: ldapwhoami -h 192.168.6.10 -D 'cn=3Droot,dc=3Dexample,dc=3Dgr' -w 'secret' >dn:cn=3Droot,dc=3Dexample,dc=3Dgr -when rootdn is wrong: Ldapwhoami -h 192.168.6.10 -D 'cn=3Droot,dc=3Dexample,dc=3Dcom' -w 'secret' >ldap_bind: Invalid credentials (49) -when rootdn is correct and rootpw is wrong Ldapwhoami -h 192.168.6.10 -D 'cn=3Droot,dc=3Dexample,dc=3Dcom' -w 'secret1= ' "NO RESULT, the ldapwhoami locks" Here are the logs of the slapd process: ################################### #with correct rootdn & rootpw # ################################### daemon: activity on 1 descriptor daemon: activity on: slap_listener_activate(8): daemon: epoll: listen=3D7 active_threads=3D0 tvp=3DNULL daemon: epoll: listen=3D8 busy >>> slap_listener(ldap:///) daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=3D7 active_threads=3D0 tvp=3DNULL daemon: epoll: listen=3D8 active_threads=3D0 tvp=3DNULL daemon: listen=3D8, new connection on 23 daemon: activity on 1 descriptor daemon: activity on: 23r daemon: read active on 23 daemon: added 23r (active) listener=3D(nil) daemon: epoll: listen=3D7 active_threads=3D0 tvp=3DNULL daemon: epoll: listen=3D8 active_threads=3D0 tvp=3DNULL daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=3D7 active_threads=3D0 tvp=3DNULL daemon: epoll: listen=3D8 active_threads=3D0 tvp=3DNULL conn=3D1000 fd=3D23 ACCEPT from IP=3D192.168.6.10:47722 (IP=3D0.0.0.0:389) connection_get(23) connection_get(23): got connid=3D1000 connection_read(23): checking for input on id=3D1000 ber_get_next ldap_read: want=3D8, got=3D8 ldap_read: want=3D36, got=3D36 ber_get_next: tag 0x30 len 42 contents: ber_dump: buf=3D0x1d047ee0 ptr=3D0x1d047ee0 end=3D0x1d047f0a len=3D42 op tag 0x60, time 1285831215 ber_get_next ldap_read: want=3D8 error=3DResource temporarily unavailable daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=3D7 active_threads=3D0 tvp=3DNULL daemon: epoll: listen=3D8 active_threads=3D0 tvp=3DNULL conn=3D1000 op=3D0 do_bind ber_scanf fmt ({imt) ber: ber_dump: buf=3D0x1d047ee0 ptr=3D0x1d047ee3 end=3D0x1d047f0a len=3D39 ber_scanf fmt (m}) ber: ber_dump: buf=3D0x1d047ee0 ptr=3D0x1d047f01 end=3D0x1d047f0a len=3D9 >>> dnPrettyNormal: <cn=3Droot,dc=3Dexample,dc=3Dgr> =3D> ldap_bv2dn(cn=3Droot,dc=3Dexample,dc=3Dgr,0) <=3D ldap_bv2dn(cn=3Droot,dc=3Dexample,dc=3Dgr)=3D0 =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(cn=3Droot,dc=3Dexample,dc=3Dgr)=3D0 =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(cn=3Droot,dc=3Dexample,dc=3Dgr)=3D0 <<< dnPrettyNormal: <cn=3Droot,dc=3Dexample,dc=3Dgr>, <cn=3Droot,dc=3Dexamp= le,dc=3Dgr> conn=3D1000 op=3D0 BIND dn=3D"cn=3Droot,dc=3Dexample,dc=3Dgr" method=3D128 do_bind: version=3D3 dn=3D"cn=3Droot,dc=3Dexample,dc=3Dgr" method=3D128 =3D=3D> ndb_back_bind: dn: cn=3Droot,dc=3Dexample,dc=3Dgr conn=3D1000 op=3D0 BIND dn=3D"cn=3Droot,dc=3Dexample,dc=3Dgr" mech=3DSIMPLE= ssf=3D0 do_bind: v3 bind: "cn=3Droot,dc=3Dexample,dc=3Dgr" to "cn=3Droot,dc=3Dexamp= le,dc=3Dgr" send_ldap_result: conn=3D1000 op=3D0 p=3D3 send_ldap_result: err=3D0 matched=3D"" text=3D"" send_ldap_response: msgid=3D1 tag=3D97 err=3D0 ber_flush2: 14 bytes to sd 23 ldap_write: want=3D14, written=3D14 conn=3D1000 op=3D0 RESULT tag=3D97 err=3D0 text=3D daemon: activity on 1 descriptor daemon: activity on: 23r daemon: read active on 23 daemon: epoll: listen=3D7 active_threads=3D0 tvp=3DNULL daemon: epoll: listen=3D8 active_threads=3D0 tvp=3DNULL connection_get(23) connection_get(23): got connid=3D1000 connection_read(23): checking for input on id=3D1000 ber_get_next ldap_read: want=3D8, got=3D8 ldap_read: want=3D24, got=3D24 ber_get_next: tag 0x30 len 30 contents: ber_dump: buf=3D0x1d045c10 ptr=3D0x1d045c10 end=3D0x1d045c2e len=3D30 op tag 0x77, time 1285831215 ber_get_next ldap_read: want=3D8 error=3DResource temporarily unavailable daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=3D7 active_threads=3D0 tvp=3DNULL daemon: epoll: listen=3D8 active_threads=3D0 tvp=3DNULL conn=3D1000 op=3D1 do_extended ber_scanf fmt ({m) ber: ber_dump: buf=3D0x1d045c10 ptr=3D0x1d045c13 end=3D0x1d045c2e len=3D27 conn=3D1000 op=3D1 EXT oid=3D1.3.6.1.4.1.4203.1.11.3 do_extended: oid=3D1.3.6.1.4.1.4203.1.11.3 conn=3D1000 op=3D1 WHOAMI send_ldap_extended: err=3D0 oid=3D len=3D26 send_ldap_response: msgid=3D2 tag=3D120 err=3D0 ber_flush2: 42 bytes to sd 23 ldap_write: want=3D42, written=3D42 conn=3D1000 op=3D1 RESULT oid=3D err=3D0 text=3D daemon: activity on 1 descriptor daemon: activity on: 23r daemon: read active on 23 daemon: epoll: listen=3D7 active_threads=3D0 tvp=3DNULL daemon: epoll: listen=3D8 active_threads=3D0 tvp=3DNULL connection_get(23) connection_get(23): got connid=3D1000 connection_read(23): checking for input on id=3D1000 ber_get_next ldap_read: want=3D8, got=3D7 ber_get_next: tag 0x30 len 5 contents: ber_dump: buf=3D0x1d045c10 ptr=3D0x1d045c10 end=3D0x1d045c15 len=3D5 op tag 0x42, time 1285831215 ber_get_next ldap_read: want=3D8, got=3D0 ber_get_next on fd 23 failed errno=3D0 (Success) connection_read(23): input error=3D-2 id=3D1000, closing. connection_closing: readying conn=3D1000 sd=3D23 for close daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=3D7 active_threads=3D0 tvp=3DNULL daemon: epoll: listen=3D8 active_threads=3D0 tvp=3DNULL connection_close: deferring conn=3D1000 sd=3D23 conn=3D1000 op=3D2 do_unbind conn=3D1000 op=3D2 UNBIND connection_resched: attempting closing conn=3D1000 sd=3D23 connection_close: conn=3D1000 sd=3D23 daemon: removing 23 conn=3D1000 fd=3D23 closed ########################################## #with correct rootdn & incorrect rootpw # ########################################## daemon: activity on 1 descriptor daemon: activity on: slap_listener_activate(8): daemon: epoll: listen=3D7 active_threads=3D0 tvp=3DNULL daemon: epoll: listen=3D8 busy >>> slap_listener(ldap:///) daemon: listen=3D8, new connection on 23 daemon: added 23r (active) listener=3D(nil) conn=3D1001 fd=3D23 ACCEPT from IP=3D192.168.6.10:47723 (IP=3D0.0.0.0:389) daemon: activity on 2 descriptors daemon: activity on: 23r daemon: read active on 23 daemon: epoll: listen=3D7 active_threads=3D0 tvp=3DNULL daemon: epoll: listen=3D8 active_threads=3D0 tvp=3DNULL connection_get(23) connection_get(23): got connid=3D1001 connection_read(23): checking for input on id=3D1001 ber_get_next ldap_read: want=3D8, got=3D8 ldap_read: want=3D37, got=3D37 ber_get_next: tag 0x30 len 43 contents: ber_dump: buf=3D0x1d0460b0 ptr=3D0x1d0460b0 end=3D0x1d0460db len=3D43 op tag 0x60, time 1285831240 ber_get_next ldap_read: want=3D8 error=3DResource temporarily unavailable conn=3D1001 op=3D0 do_bind ber_scanf fmt ({imt) ber: ber_dump: buf=3D0x1d0460b0 ptr=3D0x1d0460b3 end=3D0x1d0460db len=3D40 ber_scanf fmt (m}) ber: ber_dump: buf=3D0x1d0460b0 ptr=3D0x1d0460d1 end=3D0x1d0460db len=3D10 >>> dnPrettyNormal: <cn=3Droot,dc=3Dexample,dc=3Dgr> =3D> ldap_bv2dn(cn=3Droot,dc=3Dexample,dc=3Dgr,0) <=3D ldap_bv2dn(cn=3Droot,dc=3Dexample,dc=3Dgr)=3D0 =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(cn=3Droot,dc=3Dexample,dc=3Dgr)=3D0 =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(cn=3Droot,dc=3Dexample,dc=3Dgr)=3D0 <<< dnPrettyNormal: <cn=3Droot,dc=3Dexample,dc=3Dgr>, <cn=3Droot,dc=3Dexamp= le,dc=3Dgr> conn=3D1001 op=3D0 BIND dn=3D"cn=3Droot,dc=3Dexample,dc=3Dgr" method=3D128 do_bind: version=3D3 dn=3D"cn=3Droot,dc=3Dexample,dc=3Dgr" method=3D128 =3D=3D> ndb_back_bind: dn: cn=3Droot,dc=3Dexample,dc=3Dgr daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=3D7 active_threads=3D0 tvp=3DNULL daemon: epoll: listen=3D8 active_threads=3D0 tvp=3DNULL thanks, George

1 0

Re: (ITS#6660) paged result searches fail to deallocate memory until slapd shutdown
by quanah＠zimbra.com 29 Sep '10

29 Sep '10

--On Wednesday, September 29, 2010 8:34 PM +0200 masarati(a)aero.polimi.it wrote: >> --On Wednesday, September 29, 2010 12:38 AM +0000 quanah(a)zimbra.com >> wrote: >> >>> It appears to be a problem with the entry cache, which is set to 25,000: >> >> Running with a fix from Howard, the entry cache behaves correctly. >> However, slapd still grows at the same rate. >> >> If I limit to only 10 paged results searches, slapd grows at a rate of >> 300MB Virtual and 300MB Resident for every set of 10 paged results >> searches >> I do concurrently, up until I run slapd out of memory. There's something >> very wrong with paged results searches. > > Could it be configuration-specific? I tested with a plain configuration > resulting from test003; maybe some player in the middle, say, is causing > entries to be duplicated and leaked, or read-locks on originals are not > released correctly? Can you post a configuration that shows the issue? Hi Pierangelo, My testing shows the issue is only really visible with large databases that return giant result sets. I don't expect you to see it with a small database and test003, because the amount of "lost" memory will be a few bytes at best. My configuration itself is very minimal, but it is in cn=config format. ;) dn: olcDatabase={2}hdb objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}hdb olcSuffix: olcAccess: {0}to attrs=userPassword by anonymous auth by dn.children="cn=adm ins,cn=zimbra" write olcAccess: {1}to dn.subtree="cn=zimbra" by dn.children="cn=admins,cn=zimbra" write olcAccess: {2}to attrs=zimbraZimletUserProperties,zimbraGalLdapBindPassword,zi mbraGalLdapBindDn,zimbraAuthTokenKey,zimbraPreAuthKey,zimbraPasswordHistory, z imbraIsAdminAccount,zimbraAuthLdapSearchBindPassword by dn.children="cn=admi ns,cn=zimbra" write by * none olcAccess: {3}to attrs=objectclass by dn.children="cn=admins,cn=zimbra" write by dn.base="uid=zmpostfix,cn=appaccts,cn=zimbra" read by dn.base="uid=zmam avis,cn=appaccts,cn=zimbra" read by users read by * none olcAccess: {4}to attrs=@amavisAccount by dn.children="cn=admins,cn=zimbra" wr ite by dn.base="uid=zmamavis,cn=appaccts,cn=zimbra" read by * +0 break olcAccess: {5}to attrs=mail by dn.children="cn=admins,cn=zimbra" write by dn .base="uid=zmamavis,cn=appaccts,cn=zimbra" read by * +0 break olcAccess: {6}to attrs=zimbraAllowFromAddress by dn.children="cn=admins,cn=zi mbra" write by dn.base="uid=zmpostfix,cn=appaccts,cn=zimbra" read by * none olcAccess: {7}to filter="(!(zimbraHideInGal=TRUE))" attrs=cn,co,company,dc,di splayName,givenName,gn,initials,l,mail,o,ou,physicalDeliveryOfficeName,posta l Code,sn,st,street,streetAddress,telephoneNumber,title,uid,homePhone,mobile,p a ger by dn.children="cn=admins,cn=zimbra" write by dn.base="uid=zmpostfix,cn =appaccts,cn=zimbra" read by users read by * none olcAccess: {8}to attrs=zimbraId,zimbraMailAddress,zimbraMailAlias,zimbraMailCa nonicalAddress,zimbraMailCatchAllAddress,zimbraMailCatchAllCanonicalAddress, z imbraMailCatchAllForwardingAddress,zimbraMailDeliveryAddress,zimbraMailForwa r dingAddress,zimbraPrefMailForwardingAddress,zimbraMailHost,zimbraMailStatus, z imbraMailTransport,zimbraDomainName,zimbraDomainType,zimbraPrefMailLocalDeli v eryDisabled by dn.children="cn=admins,cn=zimbra" write by dn.base="uid=zmpo stfix,cn=appaccts,cn=zimbra" read by * none olcAccess: {9}to attrs=entry by dn.children="cn=admins,cn=zimbra" write by * read olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=config olcSizeLimit: unlimited olcTimeLimit: unlimited olcMonitoring: TRUE olcDbDirectory: /opt/zimbra/data/ldap/hdb/db olcDbCacheSize: 25000 olcDbCheckpoint: 64 5 olcDbConfig: {0}# olcDbConfig: {1}# Set the database in memory cache size. olcDbConfig: {2}# olcDbConfig: {3}set_cachesize 0 52428800 0 olcDbConfig: {4} olcDbConfig: {5}# olcDbConfig: {6}# Set database flags. olcDbConfig: {7}# Automatically remove log files that are no longer needed. olcDbConfig: {8}set_log_config DB_LOG_AUTO_REMOVE olcDbConfig: {9} olcDbConfig: {10}# olcDbConfig: {11}# Set log values. olcDbConfig: {12}# olcDbConfig: {13}set_lg_regionmax 262144 olcDbConfig: {14}set_lg_max 10485760 olcDbConfig: {15}set_lg_bsize 2097152 olcDbConfig: {16}set_lg_dir /opt/zimbra/data/ldap/hdb/logs olcDbConfig: {17}# Increase locks olcDbConfig:: ezE4fXNldF9sa19tYXhfbG9ja3MJMzAwMA== olcDbConfig:: ezE5fXNldF9sa19tYXhfb2JqZWN0cwkxNTAw olcDbConfig:: ezIwfXNldF9sa19tYXhfbG9ja2VycwkxNTAw olcDbNoSync: FALSE olcDbDirtyRead: FALSE olcDbIDLcacheSize: 25000 olcDbIndex: objectClass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq olcDbIndex: zimbraForeignPrincipal eq olcDbIndex: zimbraYahooId eq olcDbIndex: zimbraId eq olcDbIndex: zimbraVirtualHostname eq olcDbIndex: zimbraVirtualIPAddress eq olcDbIndex: zimbraMailDeliveryAddress eq,sub olcDbIndex: zimbraAuthKerberos5Realm eq olcDbIndex: zimbraMailForwardingAddress eq olcDbIndex: zimbraMailCatchAllAddress eq,sub olcDbIndex: zimbraShareInfo sub olcDbIndex: zimbraMailTransport eq olcDbIndex: zimbraMailAlias eq,sub olcDbIndex: zimbraACE sub olcDbIndex: zimbraDomainName eq,sub olcDbIndex: mail pres,eq,sub olcDbIndex: zimbraCalResSite eq,sub olcDbIndex: givenName pres,eq,sub olcDbIndex: displayName pres,eq,sub olcDbIndex: sn pres,eq,sub olcDbIndex: zimbraCalResRoom eq,sub olcDbIndex: zimbraCalResCapacity eq olcDbIndex: zimbraCalResBuilding eq,sub olcDbIndex: zimbraCalResFloor eq,sub olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbSearchStack: 16 olcDbShmKey: 0 olcDbCacheFree: 1000 olcDbDNcacheSize: 0 structuralObjectClass: olcHdbConfig entryUUID: 152ab0a8-333e-102d-8700-d562901af228 creatorsName: cn=config createTimestamp: 20081020215916Z entryCSN: 20081020215916.275992Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20081020215916Z The actual DB_CONFIG is: zimbra@zre-ldap001:~/data/ldap/hdb/db$ cat DB_CONFIG # # Set the database in memory cache size. # set_cachesize 10 0 0 # # Set database flags. # Automatically remove log files that are no longer needed. set_log_config DB_LOG_AUTO_REMOVE # # Set log values. # set_lg_regionmax 262144 set_lg_max 10485760 set_lg_bsize 2097152 set_lg_dir /opt/zimbra/data/ldap/hdb/logs # Increase locks set_lk_max_locks 3000 set_lk_max_objects 1500 set_lk_max_lockers 1500 -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6660) paged result searches fail to deallocate memory until slapd shutdown
by masarati＠aero.polimi.it 29 Sep '10

29 Sep '10

> --On Wednesday, September 29, 2010 12:38 AM +0000 quanah(a)zimbra.com wrote: > >> It appears to be a problem with the entry cache, which is set to 25,000: > > Running with a fix from Howard, the entry cache behaves correctly. > However, slapd still grows at the same rate. > > If I limit to only 10 paged results searches, slapd grows at a rate of > 300MB Virtual and 300MB Resident for every set of 10 paged results > searches > I do concurrently, up until I run slapd out of memory. There's something > very wrong with paged results searches. Could it be configuration-specific? I tested with a plain configuration resulting from test003; maybe some player in the middle, say, is causing entries to be duplicated and leaked, or read-locks on originals are not released correctly? Can you post a configuration that shows the issue? p.

1 0

Re: (ITS#6660) paged result searches fail to deallocate memory until slapd shutdown
by quanah＠zimbra.com 29 Sep '10

29 Sep '10

--On Wednesday, September 29, 2010 12:38 AM +0000 quanah(a)zimbra.com wrote: > It appears to be a problem with the entry cache, which is set to 25,000: Running with a fix from Howard, the entry cache behaves correctly. However, slapd still grows at the same rate. If I limit to only 10 paged results searches, slapd grows at a rate of 300MB Virtual and 300MB Resident for every set of 10 paged results searches I do concurrently, up until I run slapd out of memory. There's something very wrong with paged results searches. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

ITS#6661
by masarati＠aero.polimi.it 29 Sep '10

29 Sep '10

Please try back-ndb/bind.cpp 1.5->1.6 from HEAD's CVS. Thanks for the report. p.

1 0

(ITS#6661) rootpw is not verified with slapd.conf
by gtzanetis＠pylones.gr 29 Sep '10

29 Sep '10

Full_Name: George Tzanetis Version: 2.4.23 stable OS: Red Hat Enterprise 5.5 URL: Submission from: (NULL) (62.169.213.126) I have built openldap 2.4.23 with the back-ndb in 4 machines. I created the slapd.conf as follows: pidfile /usr/local/openldap/var/run/slapd.pid argsfile /usr/local/openldap/var/run/slapd.args ####################################################################### # NDB database definitions ####################################################################### #NDB database defintions database ndb suffix "dc=example,dc=gr" rootdn "cn=root,dc=example,dc=gr" rootpw secret dbconnect 192.168.6.11 dbhost 192.168.6.12 dbport 3306 dbname openldap dbuser ldapUser dbpass "1234" dbconnections 3 dbsocket /tmp/mysql.sock attrblob description index uid ####################################################################### # Monitor Database definitions ####################################################################### database monitor loglevel 5 My problem is that I can authenticate to the ldap with any password for the cn=root,dc=example,dc=gr (rootdn) user, as long as I specify a password. To make it clearer, all the following ldapsearches work: ldapsearch -h 192.168.6.10 -b 'dc=example,dc=gr' -w secret1 -D "cn=root,dc=example,dc=gr" ldapsearch -h 192.168.6.10 -b 'dc=example,dc=gr' -w secret -D "cn=root,dc=example,dc=gr" ldapsearch -h 192.168.6.10 -b 'dc=example,dc=gr' -w sec -D "cn=root,dc=example,dc=gr" ldapsearch -h 192.168.6.10 -b 'dc=example,dc=gr' -w " " -D "cn=root,dc=example,dc=gr" If I do not specify a password, (i.e. -w flag is omitted) I get the message: ldap_bind: Server is unwilling to perform (53) additional info: unauthenticated bind (DN with no password) disallowed In addition if I don input the correct rootdn user, I get the message: ldap_bind: Invalid credentials (49). This behavior exists in all instances of openldap with ndb as back-end. I did some more testing, and I built openldap with the bdb and ndb backends. The issue appears only to the suffix that is stored in the ndb back-end and not to the bdb back-end, so there must be something wrong with the bind operation of the slapd-ndb. Finally, I would like to state that with the slapd-ndb, all the ldapsearches / modifications / deletions are performed correctly, even if the rootpw password is wrong.

1 0

Re: (ITS#6659) logfile directive not logging any log
by masarati＠aero.polimi.it 29 Sep '10

29 Sep '10

hayashis(a)indiana.edu wrote: > --001636d34cf42a20380491547f9e > Content-Type: text/plain; charset=ISO-8859-1 > > Hi. I will use the correct mailing list. > > The place that I found the *wrong* information for logfile directive > (according to Google) was this doc >> http://www.zytrax.com/books/ldap/ch6/#logfile > > Here, it states, > > OpenLDAP logs via syslogd (using LOCAL4) in all cases (see loglevel for > configuration information on streaming syslogd LDAP messages to a separate > file). In addition the logfile directive may be used to create a separate > file containing just LDAP log information. > > Based on this information, I have *perceived* the behavior of slapd as a > BUG.. my apologies. Your opinion is valuable, just like that of anyone. The code is perfectible. However, to discuss opinions and improvements of code, a technical discussion forum is more appropriate that a bug tracking system. I believe that slapd already has provisions to address your needs, and pointed you to what I think are the appropriate sources of information. Changing the way software works (and has been working for decades) requires a real need and consensus. Fixing bugs is a completely different business. p.

1 0

Re: (ITS#6660) paged result searches fail to deallocate memory until slapd shutdown
by quanah＠zimbra.com 28 Sep '10

28 Sep '10

--On Tuesday, September 28, 2010 11:10 PM +0000 quanah(a)zimbra.com wrote: > --On Tuesday, September 28, 2010 8:04 PM +0200 masarati(a)aero.polimi.it > wrote: > >> Each paged results control request mallocs a small amount of memory on >> the slab which is not explicitly freed. It should not be an issue, >> since it occurs so early in the life of an operation that the slab >> should never be exhausted. In any case, I've committed a fix. Can you >> test and report, please? Thanks, p. > > Hi Pierangelo, > > I'm testing a build with your patch now. In the meantime, you can see a > callgraph generated from tcmalloc's heap profiling tool at > <http://www.stanford.edu/~quanah/pprof.pdf>. I baselined the graph to > start after the first initial searches have been to load the cache, etc. > So you can see that slapd grew by 14.3GB once I started doing the paged > results searches. It appears to be a problem with the entry cache, which is set to 25,000: olcDatabase={2}hdb.ldif:olcDbCacheSize: 25000 yet: olmBDBEntryCache: 209759 from cn=monitor. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6660) paged result searches fail to deallocate memory until slapd shutdown
by quanah＠zimbra.com 28 Sep '10

28 Sep '10

--On Tuesday, September 28, 2010 8:04 PM +0200 masarati(a)aero.polimi.it wrote: > Each paged results control request mallocs a small amount of memory on the > slab which is not explicitly freed. It should not be an issue, since it > occurs so early in the life of an operation that the slab should never be > exhausted. In any case, I've committed a fix. Can you test and report, > please? Thanks, p. Hi Pierangelo, I'm testing a build with your patch now. In the meantime, you can see a callgraph generated from tcmalloc's heap profiling tool at <http://www.stanford.edu/~quanah/pprof.pdf>. I baselined the graph to start after the first initial searches have been to load the cache, etc. So you can see that slapd grew by 14.3GB once I started doing the paged results searches. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6660) paged result searches fail to deallocate memory until slapd shutdown
by masarati＠aero.polimi.it 28 Sep '10

28 Sep '10

Each paged results control request mallocs a small amount of memory on the slab which is not explicitly freed. It should not be an issue, since it occurs so early in the life of an operation that the slab should never be exhausted. In any case, I've committed a fix. Can you test and report, please? Thanks, p.

1 0

(ITS#6660) paged result searches fail to deallocate memory until slapd shutdown
by quanah＠zimbra.com 28 Sep '10

28 Sep '10

Full_Name: Quanah Gibson-Mount Version: 2.4.23 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) When using paged result searches with large databases, it quickly becomes apparent that slapd is failing to deallocate memory allocated during those searches once they complete. The example database I am using has 6,326,513 entries, and is some 8.5GB on disk (id2entry.bdb + dn2id.bdb). What has been found is that over time when using multiple paged results searches, slapd's memory continually grows until it eventually consumes all memory on the system. Once slapd is stopped, the allocated memory is freed. This behavior can be seen in a more pronounced fashion by running multiple paged results searches and searches of the full database simultaneously. For example, I start slapd, and preload all the caches by doing 4 full searches of the database. At this point, top reports (V/R/S): 12.2G/10G/8.4G I then start 10 ldap searches dumping the full database (using root dn), and 10 paged result searches that only return some 2.6 million entries. After these all complete, I run this sequence again. Instead of slapd's memory remaining stable (i.e., re-using all the memory it had previously allocated), it instead continues to grow. At the end of just 2 of these runs, we end up at: 22.5G/20G/8.4G Or a 10.3GB growth in virtual memory and 10GB growth in resident memory. As soon as slapd is halted, all of this memory is freed (Making it impossible to track this via valgrind). I'm currently using the heap profiler shipped with tcmalloc to gather further information and will follow up when that is complete. --Quanah

1 0

Re: (ITS#6659) logfile directive not logging any log
by quanah＠zimbra.com 28 Sep '10

28 Sep '10

--On Tuesday, September 28, 2010 12:40 PM -0400 Soichi Hayashi <hayashis(a)indiana.edu> wrote: > Hi. I will use the correct mailing list. > > The place that I found the *wrong* information for logfile directive > (according to Google) was this doc >> http://www.zytrax.com/books/ldap/ch6/#logfile This is why we always suggest you read the project supplied documentation. Zytrax is known to have numerous issues with what they have written. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6659) logfile directive not logging any log
by hayashis＠indiana.edu 28 Sep '10

28 Sep '10

--001636d34cf42a20380491547f9e Content-Type: text/plain; charset=ISO-8859-1 Hi. I will use the correct mailing list. The place that I found the *wrong* information for logfile directive (according to Google) was this doc > http://www.zytrax.com/books/ldap/ch6/#logfile Here, it states, OpenLDAP logs via syslogd (using LOCAL4) in all cases (see loglevel for configuration information on streaming syslogd LDAP messages to a separate file). In addition the logfile directive may be used to create a separate file containing just LDAP log information. Based on this information, I have *perceived* the behavior of slapd as a BUG.. my apologies. On Tue, Sep 28, 2010 at 12:16 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Tuesday, September 28, 2010 2:07 PM +0000 hayashis(a)indiana.edu wrote: > >> Thanks. >> >>> Please direct further sofware usage questions to the most appropriate >>> mai= >> >> ling lists >> >> Sorry to keep bugging, but I believe this *is* the most appropriate >> mailing list. > > You are wrong. This list is about bugs in the software. It has already > been noted there is no bug here. Please use the > openldap-technical(a)openldap.org if you have further questions. > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > --001636d34cf42a20380491547f9e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi. I will use the correct mailing list. The place that I found the = *wrong* information for logfile directive (according to Google) was this do= c > <a href=3D"http://www.zytrax.com/books/ldap/ch6/#logfile">http://= www.zytrax.com/books/ldap/ch6/#logfile</a> Here, it states, OpenLDAP logs via syslogd (using LOCAL4) in al= l cases (see loglevel for configuration information on streaming syslogd LD= AP messages to a separate file). In addition the logfile directive may be u= sed to create a separate file containing just LDAP log information. <div>Based on this information, I have *perceived* the behavior of slap= d as a BUG.. my apologies.</div><div>=A0</div><div>On Tue, Sep 28, 2010 at = 12:16 PM, Quanah Gibson-Mount <<a href=3D"mailto:quanah@zimbra.com">quan= ah(a)zimbra.com</a>> wrote: > --On Tuesday, September 28, 2010 2:07 PM +0000 <a href=3D"mailto:hayas= his(a)indiana.edu">hayashis(a)indiana.edu</a> wrote: > >> Thanks= . >> >>> Please direct further sofware usage questions= to the most appropriate >>> mai=3D >> >> ling lists >> >&= gt; Sorry to keep bugging, but I believe this *is* the most appropriate = >> mailing list. > > You are wrong. =A0This list is about= bugs in the software. =A0It has already > been noted there is no bug here. =A0Please use the > <a href=3D"= mailto:openldap-technical@openldap.org">openldap-technical(a)openldap.org</a>= if you have further questions. > > --Quanah > > --= > > Quanah Gibson-Mount > Principal Software Engineer &gt= ; Zimbra, Inc > -------------------- > Zimbra :: =A0the leader = in open source messaging and collaboration > </div> --001636d34cf42a20380491547f9e--

1 0

Re: (ITS#6659) logfile directive not logging any log
by quanah＠zimbra.com 28 Sep '10

28 Sep '10

--On Tuesday, September 28, 2010 2:07 PM +0000 hayashis(a)indiana.edu wrote: > Thanks. > >> Please direct further sofware usage questions to the most appropriate >> mai= > ling lists > > Sorry to keep bugging, but I believe this *is* the most appropriate > mailing list. You are wrong. This list is about bugs in the software. It has already been noted there is no bug here. Please use the openldap-technical(a)openldap.org if you have further questions. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6659) logfile directive not logging any log
by masarati＠aero.polimi.it 28 Sep '10

28 Sep '10

> Thanks. > >> Please direct further sofware usage questions to the most appropriate >> mailing lists > > Sorry to keep bugging, but I believe this *is* the most appropriate > mailing list. > > Having to create a different user just so that I can log to a > different files doesn't seem like an optimal solution. Clearly, this > is a lack of necessary feature for slapd where user can not override > the location of the log file. Also, I've re-read the documentation > many times but it seems to suggest that I am supposed to be able to > forward the content of the log (sent to syslog) to a separate file. > Perhaps the documentation needs to be updated? "user" here means "facility" in syslog's nomenclature (don't know why it was called like that originally in slapd). So you don't need to create different users, you need to run slapd with "-l LOCAL0", "-l LOCAL1" etc. to be able to discriminate logs as "local0", "local1" and so in syslog.conf. The documentation of "logfile" I'm reading says logfile <filename> Specify a file for recording debug log messages. By default these messages only go to stderr and are not recorded anywhere else. Specifying a logfile copies messages to both stderr and the logfile. so it explicitly mentions "stderr" and never mentions "syslog". So it clearly refers to logging that goes to "stderr", which is controlled by the "-d" switch, which has nothing to do with syslog as well. I don't think it needs any amendment or clarification, but feel free to suggest any improvement (possibly in the form of a specific ITS with a patch to current documentation sources). p.

1 0

Re: (ITS#6659) logfile directive not logging any log
by hayashis＠indiana.edu 28 Sep '10

28 Sep '10

Thanks. > Please direct further sofware usage questions to the most appropriate mai= ling lists Sorry to keep bugging, but I believe this *is* the most appropriate mailing list. Having to create a different user just so that I can log to a different files doesn't seem like an optimal solution. Clearly, this is a lack of necessary feature for slapd where user can not override the location of the log file. Also, I've re-read the documentation many times but it seems to suggest that I am supposed to be able to forward the content of the log (sent to syslog) to a separate file. Perhaps the documentation needs to be updated? Thanks, Soichi On Tue, Sep 28, 2010 at 9:33 AM, <masarati(a)aero.polimi.it> wrote: > >> I am running multiple BDII servers (listening on different port), and >> I need them to log to different location. If I understand correctly, >> "logfile" directive only works to capture stderr messages (not stats, >> or other logs currently sent to syslog). Since I can't tell syslog to >> log to a different file based on which instance of LDAP server, logs >> from both server goes to a single file in /var/log. >> >> Is there anyway that I can redirect logs from each LDAP server to a >> different locations? > > You can use '-l' to have different instances of slapd log as different > syslog users. =A0See slapd(8) and syslog(8) for further details. > > Please direct further sofware usage questions to the most appropriate > mailing lists (openldap-technical for OpenLDAP software; Syslog-specific > lists for syslog(8) detaild usage). =A0This ITS will be closed. > > p. > >

1 0

Re: (ITS#6659) logfile directive not logging any log
by masarati＠aero.polimi.it 28 Sep '10

28 Sep '10

> I am running multiple BDII servers (listening on different port), and > I need them to log to different location. If I understand correctly, > "logfile" directive only works to capture stderr messages (not stats, > or other logs currently sent to syslog). Since I can't tell syslog to > log to a different file based on which instance of LDAP server, logs > from both server goes to a single file in /var/log. > > Is there anyway that I can redirect logs from each LDAP server to a > different locations? You can use '-l' to have different instances of slapd log as different syslog users. See slapd(8) and syslog(8) for further details. Please direct further sofware usage questions to the most appropriate mailing lists (openldap-technical for OpenLDAP software; Syslog-specific lists for syslog(8) detaild usage). This ITS will be closed. p.

1 0

Re: (ITS#6659) logfile directive not logging any log
by hayashis＠indiana.edu 28 Sep '10

28 Sep '10

Hi. Thank you for your reply! I am running multiple BDII servers (listening on different port), and I need them to log to different location. If I understand correctly, "logfile" directive only works to capture stderr messages (not stats, or other logs currently sent to syslog). Since I can't tell syslog to log to a different file based on which instance of LDAP server, logs from both server goes to a single file in /var/log. Is there anyway that I can redirect logs from each LDAP server to a different locations? On Tue, Sep 28, 2010 at 8:26 AM, <masarati(a)aero.polimi.it> wrote: >> Full_Name: Soichi Hayashi >> Version: 2.3.43-12.el5_5.2 >> OS: RHEL5 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (99.50.225.74) >> >> >> I have following in my slapd.conf >> >> logfile /var/log/ldap.log >> >> When I start slapd, it creates the file specified but the filesize remai= ns >> 0 >> although I see a lot of log sent to syslog. >> >> It looks like the logging through "logfile" directive is not working. > > According to the documentation, this directive collects messages that are > sent to stderr when "-d" is used, so it is not related to syslog. =A0It i= s > equivalent to > > $ slapd -d <level> >>/var/log/ldap.log 2>&1 > > I've checked recent code and it works as expected. =A0Unless this is what > you're expecting, and it does not happen, this ITS will be closed. > > p. > >

1 0

Re: (ITS#6659) logfile directive not logging any log
by masarati＠aero.polimi.it 28 Sep '10

28 Sep '10

> Full_Name: Soichi Hayashi > Version: 2.3.43-12.el5_5.2 > OS: RHEL5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (99.50.225.74) > > > I have following in my slapd.conf > > logfile /var/log/ldap.log > > When I start slapd, it creates the file specified but the filesize remains > 0 > although I see a lot of log sent to syslog. > > It looks like the logging through "logfile" directive is not working. According to the documentation, this directive collects messages that are sent to stderr when "-d" is used, so it is not related to syslog. It is equivalent to $ slapd -d <level> >>/var/log/ldap.log 2>&1 I've checked recent code and it works as expected. Unless this is what you're expecting, and it does not happen, this ITS will be closed. p.

1 0

modifyTimestamp does not always update
by Jani Salonen 27 Sep '10

27 Sep '10

Seems that modifyTimestamp of groupOfUniqueNames does not always update as it should. We have one application that updates uniqueMembers of groupOfUniqueNames groups (we have about 30000 groups, from 5 to 1000 members each). Another application syncs its sql database based on groupOfUniqueNames member's once an hour, and for speeding things up, that another application first looks from modifyTimeStamp if group has changed within last hour, and if so, it will be synced. But here is the problem: another application's database does not always sync because modifyTimestamp does not always update for some group. Unfortunately this happens quite rarely and I cannot provide exact instructions how to reproduce this, I was not able to find any pattern either. If anyone has any ideas/experiments what is wrong/how to fix this, they are most welcome. Thanks, Jani Salonen

2 1

(ITS#6659) logfile directive not logging any log
by hayashis＠indiana.edu 24 Sep '10

24 Sep '10

Full_Name: Soichi Hayashi Version: 2.3.43-12.el5_5.2 OS: RHEL5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (99.50.225.74) I have following in my slapd.conf logfile /var/log/ldap.log When I start slapd, it creates the file specified but the filesize remains 0 although I see a lot of log sent to syslog. It looks like the logging through "logfile" directive is not working.

1 0

ITS#6657
by masarati＠aero.polimi.it 23 Sep '10

23 Sep '10

Please - rebuild with -DSLAP_NO_SL_MALLOC=1 (you only need to recompile sl_malloc.c) - run slapd under valgrind --tool=memcheck --leak-check=full and minimal loglevel (e.g. -d stats) - send valgrind's output (if anything surfaces) Thanks, p.

1 0

Re: (ITS#6657) back-sql segfault in backsql_search
by david＠dasz.at 22 Sep '10

22 Sep '10

I've tried the same configuration with 2.4.11-1+lenny2 from lenny and it didn't segfault on my test-queries. Regards, David

1 0

(ITS#6657) back-sql segfault in backsql_search
by david＠dasz.at 22 Sep '10

22 Sep '10

Full_Name: David Schmitt Version: 2.4.23-5 OS: Debian squeeze URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.170.188.2) I'm seeing reproducible but inconsistent segfaults from within back-sql: #0 slap_sl_free (ptr=0x9cc440, ctx=0x98e270) at /home/devel/openldap/trunk/servers/slapd/sl_malloc.c:490 p = 0xffffffee009bc130 tmpp = <value optimized out> #1 0x00007ffff35f7877 in backsql_free_entryID (id=0x7ffff139d678, freeit=0, ctx=0x98e270) at /home/devel/openldap/trunk/servers/slapd/back-sql/entry-id.c:84 next = 0x0 __PRETTY_FUNCTION__ = "backsql_free_entryID" #2 0x00007ffff35f0ad8 in backsql_search (op=0x98b500, rs=0x7ffff139ea40) at /home/devel/openldap/trunk/servers/slapd/back-sql/search.c:2552 dbh = 0x965590 sres = <value optimized out> user_entry = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x0}, e_nname = {bv_len = 0, bv_val = 0x0}, e_attrs = 0x0, e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0} base_entry = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x0}, e_nname = {bv_len = 0, bv_val = 0x0}, e_attrs = 0x0, e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0} manageDSAit = 0 stoptime = 1285164120 bsi = {bsi_op = 0x98b500, bsi_rs = 0x7ffff139ea40, bsi_flags = 1, bsi_base_ndn = 0x98b538, bsi_use_subtree_shortcut = 0, bsi_base_id = {eid_id = 1, eid_keyval = 1, eid_oc_id = 1, eid_oc = 0x98bb50, eid_dn = {bv_len = 0, bv_val = 0x0}, eid_ndn = {bv_len = 18, bv_val = 0x9cc440 "ou=samba,ou=uni-ak"}, eid_next = 0x0}, bsi_scope = 2, bsi_filter = 0x9bbf98, bsi_stoptime = 1285164120, bsi_id_list = 0x0, bsi_id_listtail = 0x7ffff139d6d8, bsi_c_eid = 0x7ffff139d678, bsi_n_candidates = -2, bsi_status = 0, bsi_oc = 0x98b3f0, bsi_sel = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_from = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_join_where = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_flt_where = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_filter_oc = 0x0, bsi_dbh = 0x965590, bsi_attrs = 0x0, bsi_e = 0x0} eid = <value optimized out> lastid = 0 #3 0x00000000004355c9 in fe_op_search (op=0x98b500, rs=0x7ffff139ea40) at /home/devel/openldap/trunk/servers/slapd/search.c:366 bd = 0x7347e0 #4 0x0000000000435ddc in do_search (op=0x98b500, rs=0x7ffff139ea40) at /home/devel/openldap/trunk/servers/slapd/search.c:217 base = {bv_len = 18, bv_val = 0x9ac727 "ou=samba,ou=uni-ak"} siz = 0 i = 140737240492960 #5 0x0000000000433479 in connection_operation (ctx=0x7ffff139eba0, arg_v=<value optimized out>) at /home/devel/openldap/trunk/servers/slapd/connection.c:1109 rc = <value optimized out> cancel = <value optimized out> op = 0x98b500 rs = {sr_type = REP_RESULT, sr_tag = 101, sr_msgid = 2, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = { r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = { r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 99 opidx = SLAP_OP_SEARCH conn = 0x7ffff7f3b690 memctx = 0x98e270 memctx_null = 0x0 __PRETTY_FUNCTION__ = "connection_operation" #6 0x0000000000433c65 in connection_read_thread (ctx=<value optimized out>, argv=<value optimized out>) at /home/devel/openldap/trunk/servers/slapd/connection.c:1245 s = 14 I've configured back-sql with suffix 'ou=uni-ak' and am searching for '(&(cn=p0002001)(objectclass=sambasamaccount))' (which doesn't return results) within 'ou=samba,ou=uni-ak', which exists and has ~10k items in the whole tree. The segfault happens on the second such ldapsearch in the slapd's lifetime. Using a filter that returns multiple entries '(&(cn=x0004291)(objectclass=sambasamaccount))', back-sql segfaults already within the first query: #0 slap_sl_free (ptr=0x9dd7f8, ctx=0x98e270) at /home/devel/openldap/trunk/servers/slapd/sl_malloc.c:490 p = 0xffffffc9009cc582 tmpp = <value optimized out> #1 0x00007ffff35f7896 in backsql_free_entryID (id=0x9dd7f8, freeit=1, ctx=0x98e270) at /home/devel/openldap/trunk/servers/slapd/back-sql/entry-id.c:101 next = 0x0 __PRETTY_FUNCTION__ = "backsql_free_entryID" #2 0x00007ffff35f0ee7 in backsql_search (op=0x98b500, rs=0x7ffff139ea40) at /home/devel/openldap/trunk/servers/slapd/back-sql/search.c:2223 dbh = 0x965590 sres = <value optimized out> user_entry = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x0}, e_nname = {bv_len = 0, bv_val = 0x0}, e_attrs = 0x0, e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0} base_entry = {e_id = 1, e_name = {bv_len = 18, bv_val = 0x9cc468 "ou=samba,ou=uni-ak"}, e_nname = {bv_len = 18, bv_val = 0x9cc490 "ou=samba,ou=uni-ak"}, e_attrs = 0x82e7b8, e_ocflags = 256, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0} manageDSAit = 0 stoptime = 1285164373 bsi = {bsi_op = 0x98b500, bsi_rs = 0x7ffff139ea40, bsi_flags = 1, bsi_base_ndn = 0x98b538, bsi_use_subtree_shortcut = 0, bsi_base_id = {eid_id = 1, eid_keyval = 1, eid_oc_id = 1, eid_oc = 0x98bb50, eid_dn = {bv_len = 18, bv_val = 0x9cc3d8 "ou=samba,ou=uni-ak"}, eid_ndn = {bv_len = 18, bv_val = 0x9cc440 "ou=samba,ou=uni-ak"}, eid_next = 0x0}, bsi_scope = 2, bsi_filter = 0x9bbf98, bsi_stoptime = 1285164373, bsi_id_list = 0x9dcc18, bsi_id_listtail = 0x9dd838, bsi_c_eid = 0x9dd7f8, bsi_n_candidates = -5, bsi_status = 0, bsi_oc = 0x993690, bsi_sel = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_from = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_join_where = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_flt_where = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_filter_oc = 0x0, bsi_dbh = 0x965590, bsi_attrs = 0x0, bsi_e = 0x7ffff139d890} eid = 0x9dd7f8 lastid = 0 #3 0x00000000004355c9 in fe_op_search (op=0x98b500, rs=0x7ffff139ea40) at /home/devel/openldap/trunk/servers/slapd/search.c:366 bd = 0x7347e0 #4 0x0000000000435ddc in do_search (op=0x98b500, rs=0x7ffff139ea40) at /home/devel/openldap/trunk/servers/slapd/search.c:217 base = {bv_len = 18, bv_val = 0x9ac727 "ou=samba,ou=uni-ak"} siz = 0 i = 140737240492960 #5 0x0000000000433479 in connection_operation (ctx=0x7ffff139eba0, arg_v=<value optimized out>) at /home/devel/openldap/trunk/servers/slapd/connection.c:1109 rc = <value optimized out> cancel = <value optimized out> op = 0x98b500 rs = {sr_type = REP_SEARCH, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 3, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 1} tag = 99 opidx = SLAP_OP_SEARCH conn = 0x7ffff7f3b690 memctx = 0x98e270 memctx_null = 0x0 __PRETTY_FUNCTION__ = "connection_operation" #6 0x0000000000433c65 in connection_read_thread (ctx=<value optimized out>, argv=<value optimized out>) at /home/devel/openldap/trunk/servers/slapd/connection.c:1245 s = 14 A third query for a different mapped object class doesn't lead to a segfault at all (within the 15 tries I tested). I would not exclude an error in the schema mapping, but I'd prefer an error message instead of a segfault ;-) Thanks for your time and work, David

1 0

(ITS#6656) logging "reqEntryUUID" in accesslog
by michael＠stroeder.com 22 Sep '10

22 Sep '10

Full_Name: Michael Ströder Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.92.147.99) Feature request: In accesslog the value of entryUUID of the entry affected by a write operation should be logged in a separate attribute 'reqEntryUUID' so that this write operations are also searchable in case an entry was renamed afterwards. Searching in reqOld is not an option because for performance reasons one would not index this multi-valued attribute which can contain lots of values.

1 0

Re: (ITS#6655) Error on delete for jpegPhoto attribute
by masarati＠aero.polimi.it 21 Sep '10

21 Sep '10

This is not a bug, but a legitimate error. The definition of the attribute jpegPhoto contains no matching rule, so deleting a specific value is not possible. This ITS will be closed. p. > Full_Name: Philippe EYCHART > Version: 2.4.15 > OS: slackware > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (123.50.121.95) > > > Hi, > It seems that the delete of a jpegPhoto attribute (specifing its value) > produce > the error 18 (Inappropriate matching). > With other attribute ("title", for exemple), this error doesn't appear ... > > source (C++): > m_errNo = ldap_modify_ext_s ( m_desc, > (*m_entryIn)->getIdentifier().c_str(), > tmpMods, NULL, NULL ); > > Trace Debug (code::blocks 8.02): > **tmpMods > mod_op=129 > mod_type = 0xcc9950 "jpegPhoto" > mod_vals > modv_strvals = 0xc3dad0 > modv_bvals = 0xc3dad0 > *tmpMods->mod_vals->modv_bvals[0] > bv_len = 816 > bv_val = 0xec9480 "iVBORwOKGgoAAAANSUh... // (*) > tmpMods->mod_vals->modv_bvals[1] = (berval *) 0x0,, > this->m_errNo = 18 > > (*): here, the value seems correct: (std::string(..."a search jpegPhoto > attribute result in > Base"...getAttribute()->getStrValue()))->compare(bv_val)==0... > > but: > **tmpMods > mod_op=129 > mod_type = 0xd76130 "title" > mod_vals > modv_strvals = 0xcc7e90 > modv_bvals = 0xcc7e90 > *tmpMods->mod_vals->modv_bvals[0] > bv_len = 4 > bv_val = 0xdd3b40 "test" > tmpMods->mod_vals->modv_bvals[1] = (berval *) 0x0,, > this->m_errNo = 0 > > > Please, tell me if you need some more samples of code or trace debug ... > Regards. > PE > <http://homepage.gna.org/ldapcppei/Frontends/Howto-7.fr.html> > > >

1 0

Re: (ITS#6655) Error on delete for jpegPhoto attribute
by philippe.eychart＠mail.pf 20 Sep '10

20 Sep '10

Le lundi 20 septembre 2010 à 23:36 +0000, openldap-its(a)OpenLDAP.org a écrit : > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#6655. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#6655) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#6655) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=6655 > > Please remember to retain your issue tracking number (ITS#6655) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > More context here : http://homepage.gna.org/ldapcppei/archives/ldapEasyAdminFrontends/personFro… line # 707...

1 0

(ITS#6655) Error on delete for jpegPhoto attribute
by philippe.eychart＠mail.pf 20 Sep '10

20 Sep '10

Full_Name: Philippe EYCHART Version: 2.4.15 OS: slackware URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.50.121.95) Hi, It seems that the delete of a jpegPhoto attribute (specifing its value) produce the error 18 (Inappropriate matching). With other attribute ("title", for exemple), this error doesn't appear ... source (C++): m_errNo = ldap_modify_ext_s ( m_desc, (*m_entryIn)->getIdentifier().c_str(), tmpMods, NULL, NULL ); Trace Debug (code::blocks 8.02): **tmpMods mod_op=129 mod_type = 0xcc9950 "jpegPhoto" mod_vals modv_strvals = 0xc3dad0 modv_bvals = 0xc3dad0 *tmpMods->mod_vals->modv_bvals[0] bv_len = 816 bv_val = 0xec9480 "iVBORwOKGgoAAAANSUh... // (*) tmpMods->mod_vals->modv_bvals[1] = (berval *) 0x0,, this->m_errNo = 18 (*): here, the value seems correct: (std::string(..."a search jpegPhoto attribute result in Base"...getAttribute()->getStrValue()))->compare(bv_val)==0... but: **tmpMods mod_op=129 mod_type = 0xd76130 "title" mod_vals modv_strvals = 0xcc7e90 modv_bvals = 0xcc7e90 *tmpMods->mod_vals->modv_bvals[0] bv_len = 4 bv_val = 0xdd3b40 "test" tmpMods->mod_vals->modv_bvals[1] = (berval *) 0x0,, this->m_errNo = 0 Please, tell me if you need some more samples of code or trace debug ... Regards. PE <http://homepage.gna.org/ldapcppei/Frontends/Howto-7.fr.html>

1 0

Re: ITS#6653
by jargon＠molb.org 20 Sep '10

20 Sep '10

Hello, On Tue, Sep 21, 2010 at 12:12:54AM +0200, masarati(a)aero.polimi.it wrote: > Fixed (differently) in HEAD; please test. Thanks for the report. p. It works as expected! Thanks! --=20 Johannes Wei=C3=9Fl

1 0

ITS#6653
by masarati＠aero.polimi.it 20 Sep '10

20 Sep '10

Fixed (differently) in HEAD; please test. Thanks for the report. p.

1 0

(ITS#6654) ldifutil.c introduced a dependence of libldap on liblutil that is not strictly necessary
by masarati＠aero.polimi.it 20 Sep '10

20 Sep '10

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (188.153.50.138) Submitted by: ando lutil_atoix() is used to parse the version; since we only explicitly allow LDIFv1, a string comparison suffices right now. p.

1 0

(ITS#6653) Segfault when getting LDAP_OPT_HOST_NAME and URI = ldapi://
by jargon＠molb.org 20 Sep '10

20 Sep '10

Full_Name: Johannes Weißl Version: HEAD OS: Debian GNU/Linux AMD64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.104.127.153) This is only a minor issue: When URI is e.g. ldapi:// in ldap.conf and ldap_get_option() for LDAP_OPT_HOST_NAME is called, ldap_url_list2hosts() [url.c:1416] segfaults because the lud_host field in LDAPURLDesc is NULL. Adding an additional test in the loop header fixes this bug: diff -Naur openldap/libraries/libldap/url.c openldap.new/libraries/libldap/url.c --- openldap/libraries/libldap/url.c 2010-04-13 22:17:57.000000000 +0200 +++ openldap.new/libraries/libldap/url.c 2010-09-20 22:44:58.325892001 +0200 @@ -1424,7 +1424,7 @@ /* figure out how big the string is */ size = 1; /* nul-term */ - for (ludp = ludlist; ludp != NULL; ludp = ludp->lud_next) { + for (ludp = ludlist; ludp != NULL && ludp->lud_host != NULL; ludp = ludp->lud_next) { size += strlen(ludp->lud_host) + 1; /* host and space */ if (strchr(ludp->lud_host, ':')) /* will add [ ] below */ size += 2; @@ -1436,7 +1436,7 @@ return NULL; p = s; - for (ludp = ludlist; ludp != NULL; ludp = ludp->lud_next) { + for (ludp = ludlist; ludp != NULL && ludp->lud_host != NULL; ludp = ludp->lud_next) { if (strchr(ludp->lud_host, ':')) { p += sprintf(p, "[%s]", ludp->lud_host); } else {

1 0

(ITS#6652) accesslog anomaly in db drop/re-import
by marco.pizzoli＠gmail.com 20 Sep '10

20 Sep '10

Full_Name: Marco Pizzoli Version: 2.4.23 OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.41.84.11) Hi, I had a problem with my Accesslog database. I was investigating an anomaly that I had and, in doing this, I tried to: - backup (slapcat) my accesslog db - drop the entire db (rm -f alock, *.bdb, log.*, __db*) - slapadd the db In slapadd I obtained this error: --- BEGIN /usr/sbin/slapadd -b "cn=log,dc=mycorp.it" -l /srv/bck/dump_db_log.ldif.20100916 . 0.00% eta 08h35m elapsed spd 90.2 k/s str2entry: invalid value for attributeType reqControls #0 (syntax 1.3.6.1.4.1.4203.666.11.5.3.1) slapadd2.4: could not parse entry (line=4907) - 0.01% eta 05h58m elapsed spd 205.7 k/s Closing DB... --- END I went to that line and found this entry: --- BEGIN dn: reqStart=20100913065628.000008Z,cn=log,dc=mycorp.it objectClass: auditSearch structuralObjectClass: auditSearch reqStart: 20100913065628.000008Z reqEnd: 20100913065628.000009Z reqType: search reqSession: 1129 reqAuthzID: cn=syncrepl-ldap04,ou=utenze_tecniche_openldap,ou=Gestori,dc=mycorp.it reqControls: {0}{1.3.6.1.4.1.4203.1.9.1.1 controlValue "30440K0103043M7269643N 3030332M7369643N3030342M63736O3N32303130303931333036353130362O3932343735355K2 330303030303023303033233030303030300001PP"} reqControls: {1}{2.16.840.1.113730.3.4.2 criticality TRUE} reqDN: dc=mycorp.it reqResult: 0 reqScope: base reqDerefAliases: never reqAttrsOnly: TRUE reqFilter: (objectclass=*) reqAttr: 1.1 reqEntries: 0 reqTimeLimit: -1 reqSizeLimit: 1 entryUUID: 2beb0bd0-ba32-4a00-93da-748ef2177cc7 creatorsName: cn=Manager,cn=log,dc=mycorp.it createTimestamp: 20100913065628Z entryCSN: 20100913065628.167225Z#000000#003#000000 modifiersName: cn=Manager,cn=log,dc=mycorp.it modifyTimestamp: 20100913065628Z --- END Having produced this ldif using slapcat and not having "touched" the environment in between could I assume this to be a bug? The entry showed is related to an access made by another OL server of my deployment, which is in mirrormode(=true). This OL is 2.4.23 with BDB4.8.30. Other OLs are 2.4.22 with BDB4.8.26 I deleted this entry and retried the import. Now I have the following error: --- BEGIN /usr/sbin/slapadd2.4 -b "cn=log,dc=mycorp.it" -l /tmp/dump_db_log.ldif.20100916_Corrected " 4.69% eta 01h07m elapsed 03m19s spd 542.3 k/s str2entry: invalid value for attributeType reqRespControls #0 (syntax 1.3.6.1.4.1.4203.666.11.5.3.1) slapadd2.4: could not parse entry (line=3099715) * 4.70% eta 01h07m elapsed 03m20s spd 979.8 k/s Closing DB... --- END The "corrupted" entry is this one: --- BEGIN dn: reqStart=20100913093021.000000Z,cn=log,dc=mycorp.it objectClass: auditBind structuralObjectClass: auditBind reqStart: 20100913093021.000000Z reqEnd: 20100913093021.000001Z reqType: bind reqSession: 2746 reqAuthzID: reqControls: {0}{1.3.6.1.4.1.42.2.27.8.5.1} reqRespControls: {0}{1.3.6.1.4.1.42.2.27.8.5.1 controlValue "3000"} reqDN: uid=pe1597,ou=People,dc=mycorp.it reqResult: 0 reqVersion: 3 reqMethod: SIMPLE entryUUID: 192cbddf-4b5c-431d-a92e-c2f84fa4b7be creatorsName: cn=Manager,cn=log,dc=mycorp.it createTimestamp: 20100913093021Z entryCSN: 20100913093021.411398Z#000000#003#000000 modifiersName: cn=Manager,cn=log,dc=mycorp.it modifyTimestamp: 20100913093021Z --- END Is this a software bug? If yes, do I need to produce other infos related to my environment? Regards Marco Pizzoli

1 0

Re: (ITS#6650) The synchronization between two Mirror Servers is not stable
by changhong_sun＠yahoo.cn 19 Sep '10

19 Sep '10

I've updated the openLdap version from 2.4.12 to 2.4.23, and it works corre= ctly. =0A=0APreviously, I installed the OpenLdap 2.4.12 directly by YaST So= ftware Management of SUSE Linux Enterprise Server 11, and the Linux was ins= talled in VMWare 7.0. =0A=0AI don't know if the unstable synchronization is= a common issue of the openLdap 2.4.12? =0A=0AThanks and Best Regards,=0ACh= angHong=0A=0A=0A=0A=0A

1 0

Re: (ITS#6642) back-meta idassert with SASL EXTERNAL ignoring parameters
by masarati＠aero.polimi.it 18 Sep '10

18 Sep '10

>> Just to make sure, can you pull the entire HEAD? Thanks for checking, >> in >> any case. p. > I finally had the time to reproduce the issue using the cvs source > code from HEAD. > The following command was used to build OpenLDAP: > -------------------------------- > CPPFLAGS="-I/home/openldap/software/include -D_AVL_H" \ > LDFLAGS="-L/home/openldap/software/lib > -Wl,-rpath=/home/openldap/software/lib" \ > ./configure --prefix=/home/openldap/software --enable-rewrite > --enable-dnssrv \ > --enable-ldap --enable-meta --enable-auditlog --enable-rwm > --enable-sssvlv \ > --with-cyrus-sasl --with-tls=openssl --enable-bdb > make depend; make; make install > -------------------------------- > > The necessary SSL certificates are selfsigned: > -------------------------------- > openssl genrsa -out server1.key 2048 > openssl req -new -key server1.key -x509 -days 365 -out server1.crt > openssl genrsa -out server2.key 2048 > openssl req -new -key server2.key -x509 -days 365 -out server2.crt > -------------------------------- > > "server2" was started with the command: > slapd -f /home/openldap/config/slapd.conf.server2 -h > "ldaps://server2:6361" > At this point I could already authenticate via SASL EXTERNAL using the > ldapsearch command: > LDAPTLS_CACERT=server2.crt LDAPTLS_CERT=server1.crt > LDAPTLS_KEY=server1.key \ > ldapsearch -H "ldaps://server2:6361" -b "" -s base -Y EXTERNAL > 'objectclass=*' > > Now I started "server1": > slapd -f /home/openldap/config/slapd.conf.server1 -h "ldap://server1:3891" > > Searching with > ldapsearch -H ldap://server1:3891 -b "dc=server2,dc=example,dc=com" -x > gives me no result, but the following output on server1's debug log (level > 1): > -------------------------------- > ldap_connect_to_host: Trying 127.0.0.1:6361 > ldap_pvt_connect: fd: 9 tm: -1 async: 0 > TLS trace: SSL_connect:before/connect initialization > TLS trace: SSL_connect:SSLv2/v3 write client hello A > TLS trace: SSL_connect:SSLv3 read server hello A > TLS certificate verification: depth: 0, err: 18, subject: > /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server2, issuer: > /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server2 > TLS certificate verification: Error, self signed certificate > TLS trace: SSL3 alert write:fatal:unknown CA I think the real error is that you're using self-signed certificates; this has nothing to do with the way OpenLDAP is using them. Using certificates signed by a CA known to the servers I obtain the expected behavior. p. > TLS trace: SSL_connect:error in SSLv3 read server certificate B > TLS trace: SSL_connect:error in SSLv3 read server certificate B > TLS: can't connect: error:14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (self > signed certificate). > conn=1000 op=1 meta_search_dobind_init[0]: retrying > URI="ldaps://server2:6361" DN="". > -------------------------------- > > And again: > Starting "server1" with the environment variables and everything works > fine: > LDAPTLS_CACERT=server2.crt LDAPTLS_CERT=server1.crt > LDAPTLS_KEY=server1.key \ > slapd -f /home/openldap/config/slapd.conf.server1 -h > "ldap://server1:3891" > > I hope you can reproduce this issue using the information I provided. > The configurations of both servers are attached below. > > Best Regards, > Manuel > > > slapd.conf.server1 > -------------------------------- > include /home/openldap/software/etc/openldap/schema/core.schema > include /home/openldap/software/etc/openldap/schema/cosine.schema > include > /home/openldap/software/etc/openldap/schema/inetorgperson.schema > database meta > suffix "dc=example,dc=com" > uri "ldaps://server2:6361/dc=server2,dc=example,dc=com" > idassert-authzFrom "*" > idassert-bind bindmethod=sasl > saslmech=EXTERNAL > tls_cert=/home/openldap/config/server1.crt > tls_key=/home/openldap/config/server1.key > tls_cacert=/home/openldap/config/server2.crt > mode=none > -------------------------------- > > > slapd.conf.server2 > -------------------------------- > include /home/openldap/software/etc/openldap/schema/core.schema > include /home/openldap/software/etc/openldap/schema/cosine.schema > include > /home/openldap/software/etc/openldap/schema/inetorgperson.schema > TLSCertificateFile /home/openldap/config/server2.crt > TLSCertificateKeyFile /home/openldap/config/server2.key > TLSCACertificateFile /home/openldap/config/server1.crt > TLSVerifyClient demand > database bdb > suffix "dc=server2,dc=example,dc=com" > rootdn "cn=manager,dc=server2,dc=example,dc=com" > directory /home/openldap/db.server2 > -------------------------------- > >

1 0

ITS#6650
by masarati＠aero.polimi.it 18 Sep '10

18 Sep '10

There exists no 4.2.12 version of OpenLDAP. The latest stable is 2.4.23; please check and report. Unless you are actually using 2.4.23, this ITS will be closed. p.

1 0

(ITS#6651) Parsing of multiple generic controls (-E <oid>) broken
by masarati＠aero.polimi.it 18 Sep '10

18 Sep '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (188.153.50.138) Submitted by: ando A fix has been committed to HEAD. p.

1 0

ITS#6649
by masarati＠aero.polimi.it 18 Sep '10

18 Sep '10

I assume you are not talking about ldapsearch(1) the command-line tool. In any case, please try HEAD's overlays/sssvlv.c commit of few minutes ago and report through the ITS. Thanks, p.

1 0

(ITS#6650) The synchronization between two Mirror Servers is not stable
by changhong_sun＠yahoo.cn 18 Sep '10

18 Sep '10

Full_Name: Chang Hong Sun Version: 4.2.12 OS: SUSE Linux Enterprise Server 11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (124.15.219.84) Hi, I'm using OpenLdap 4.2.12 Mirror Mode to make protection between two LDAP servers. Sometimes it works prettey good, but sometimes the synchronization between two servers doesn't work, I don't know if the Mirror Mode is not stable in 4.2.12, should I update to a higher version? Thanks and Best Regards, Changhong

1 0

(ITS#6649) Possible bug in ldapsearch
by kacoroski＠gmail.com 17 Sep '10

17 Sep '10

Full_Name: Ski Kacoroski Version: 2.4.23 OS: debian 64 bit linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (152.157.64.243) When I run a search with the following parameters: 0 'base' 1 'dc=nsd,dc=org' 2 'attr' 3 ARRAY(0x23f0cf0) 0 'nsduidnumber' 4 'filter' 5 '(&(objectClass=nsdAcct)(nsdUIDNumber<=80000)(nsdUIDNumber>=70000))' 6 'control' 7 ARRAY(0x23f0fa8) 0 Net::LDAP::Control::Sort=HASH(0x2374e60) 'order' => ARRAY(0x23f05b8) 0 'nsduidnumber' 'type' => '1.2.840.113556.1.4.473' 'value' => "0\cP0\cN\cD\cLnsduidnumber" 1 Net::LDAP::Control::Paged=HASH(0x23f0b88) 'asn' => HASH(0x23f0d80) 'cookie' => '' 'size' => 10 'size' => 10 'type' => '1.2.840.113556.1.4.319' 'value' => "0\cE\cB\cA\cJ\cD\c@" I can reliably crash the slapd server. Logs are in Ski-Kacoroski-100917.ext If I only use one or the other control it works fine. It only crashed when both controls are used together. Let me know if you need anything else.

1 0

Re: (ITS#6642) back-meta idassert with SASL EXTERNAL ignoring parameters
by mgaupp＠googlemail.com 17 Sep '10

17 Sep '10

> Just to make sure, can you pull the entire HEAD? =A0Thanks for checking, = in > any case. =A0p. I finally had the time to reproduce the issue using the cvs source code from HEAD. The following command was used to build OpenLDAP: -------------------------------- CPPFLAGS=3D"-I/home/openldap/software/include -D_AVL_H" \ LDFLAGS=3D"-L/home/openldap/software/lib -Wl,-rpath=3D/home/openldap/softwa= re/lib" \ ./configure --prefix=3D/home/openldap/software --enable-rewrite --enable-dn= ssrv \ --enable-ldap --enable-meta --enable-auditlog --enable-rwm --enable-sssvl= v \ --with-cyrus-sasl --with-tls=3Dopenssl --enable-bdb make depend; make; make install -------------------------------- The necessary SSL certificates are selfsigned: -------------------------------- openssl genrsa -out server1.key 2048 openssl req -new -key server1.key -x509 -days 365 -out server1.crt openssl genrsa -out server2.key 2048 openssl req -new -key server2.key -x509 -days 365 -out server2.crt -------------------------------- "server2" was started with the command: slapd -f /home/openldap/config/slapd.conf.server2 -h "ldaps://server2:6361" At this point I could already authenticate via SASL EXTERNAL using the ldapsearch command: LDAPTLS_CACERT=3Dserver2.crt LDAPTLS_CERT=3Dserver1.crt LDAPTLS_KEY=3Dserve= r1.key \ ldapsearch -H "ldaps://server2:6361" -b "" -s base -Y EXTERNAL 'objectcla= ss=3D*' Now I started "server1": slapd -f /home/openldap/config/slapd.conf.server1 -h "ldap://server1:3891" Searching with ldapsearch -H ldap://server1:3891 -b "dc=3Dserver2,dc=3Dexample,dc=3Dcom" -= x gives me no result, but the following output on server1's debug log (level = 1): -------------------------------- ldap_connect_to_host: Trying 127.0.0.1:6361 ldap_pvt_connect: fd: 9 tm: -1 async: 0 TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 0, err: 18, subject: /C=3DAU/ST=3DSome-State/O=3DInternet Widgits Pty Ltd/CN=3Dserver2, issuer: /C=3DAU/ST=3DSome-State/O=3DInternet Widgits Pty Ltd/CN=3Dserver2 TLS certificate verification: Error, self signed certificate TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (self signed certificate). conn=3D1000 op=3D1 meta_search_dobind_init[0]: retrying URI=3D"ldaps://server2:6361" DN=3D"". -------------------------------- And again: Starting "server1" with the environment variables and everything works fine= : LDAPTLS_CACERT=3Dserver2.crt LDAPTLS_CERT=3Dserver1.crt LDAPTLS_KEY=3Dserve= r1.key \ slapd -f /home/openldap/config/slapd.conf.server1 -h "ldap://server1:3891= " I hope you can reproduce this issue using the information I provided. The configurations of both servers are attached below. Best Regards, Manuel slapd.conf.server1 -------------------------------- include /home/openldap/software/etc/openldap/schema/core.schema include /home/openldap/software/etc/openldap/schema/cosine.schema include /home/openldap/software/etc/openldap/schema/inetorgperson.s= chema database meta suffix "dc=3Dexample,dc=3Dcom" uri "ldaps://server2:6361/dc=3Dserver2,dc=3Dexample,dc=3Dcom" idassert-authzFrom "*" idassert-bind bindmethod=3Dsasl saslmech=3DEXTERNAL tls_cert=3D/home/openldap/config/server1.crt tls_key=3D/home/openldap/config/server1.key tls_cacert=3D/home/openldap/config/server2.crt mode=3Dnone -------------------------------- slapd.conf.server2 -------------------------------- include /home/openldap/software/etc/openldap/schema/core.schema include /home/openldap/software/etc/openldap/schema/cosine.schema include /home/openldap/software/etc/openldap/schema/inetorgperson.s= chema TLSCertificateFile /home/openldap/config/server2.crt TLSCertificateKeyFile /home/openldap/config/server2.key TLSCACertificateFile /home/openldap/config/server1.crt TLSVerifyClient demand database bdb suffix "dc=3Dserver2,dc=3Dexample,dc=3Dcom" rootdn "cn=3Dmanager,dc=3Dserver2,dc=3Dexample,dc=3Dcom" directory /home/openldap/db.server2 --------------------------------

1 0

(ITS#6648) Syncrepl cold refresh fails with mirrormode supplier
by andrew.findlay＠skills-1st.co.uk 15 Sep '10

15 Sep '10

Full_Name: Andrew Findlay Version: 2.4.23 OS: OpenSuSE 11.1 URL: ftp://ftp.openldap.org/incoming/ajf-syncrepl-config-20100915a.tgz Submission from: (NULL) (88.97.25.132) When a read-only consumer server uses one peer of a mirrormode pair as its supplier, there is a case where the initial refresh phase of the synchronisation loses deletions. This is very similar to the case where a single master server has its serverID changed between taking a slapcat backup to LDIF and bringing up a consumer server fom that LDIF file. See this thread for some background: http://www.openldap.org/lists/openldap-technical/201009/msg00193.html The problem occurs when a deletion was originated on a server whose serverID does not match the serverID of the supplier when a new consumer is brought up. It is masked by the volatile syncprov-sessionlog if the deletion is still in the provider's log, which is why the instructions below stop and start the servers so much. I have uploaded the configs and data files for this to ftp.openldap.org. Case 1: serverID of supplier server changes during the creation of a consumer: people.ldif contains entries #1, #2, #3, #4 under dc=people,dc=example,dc=org 1) Load people.ldif into empty master server 2) Start master 3) Stop master 4) Dump master DB using slapcat > m1.ldif 5) Start master 6) Delete entry#1 7) Stop master 8) change master serverID 9) Start master 10) Dump master DB using slapcat > m2.ldif 11) Delete entry#2 11a) Stop master 11b) Start master 12) Load m1.ldif into empty consumer server 13) Start consumer 14) Check ContextCSN matches on each server 15) Check for Entry#1 Entry#2 Entry#3 If 11a/b are run: Entry#1 and Entry#2 are still found on the consumer If 11a/b are not run: Entry#1 is still found on the consumer Entry#2 is deleted - presumably because it was in the volatile sessionlog Case 2: mirrormode pair supplying read-only consumer: 1) Load people.ldif into empty peer server with serverID 1 2) Start peer 1 3) Start peer 2 and allow it to sync up 4) Stop peer 1 4) Dump peer 1 DB using slapcat > p1.ldif 5) Start peer 1 6) Delete entry#1 on peer 1 7) Delete entry#2 on peer 2 8) Verify that both entries have gone on both servers 9) Stop both peer servers (this clears the volatile syncrepl-sessionlog) 10) Start peer 1 and peer 2 11) Load p1.ldif into empty consumer server (which is configured to sync from peer 1) 12) Start consumer 13) Check ContextCSN matches on each server 14) Check for Entry#1 Entry#2 Entry#3 on all servers Entries #1 and #2 have gone on both mirrormode peers Entries #1 and #2 are still present on the consumer The consumer only has a ContextCSN value from peer 1 15) Restart the consumer server The consumer now has both ContextCSN values but it still has entries #1 and #2 16) Delete Entry #3 on peer 1 17) Check for entry #3 on all servers Correctly deleted 18) Delete Entry #4 on peer 2 19) Check for entry #3 on all servers Correctly deleted Entries #1 and #2 are still present on the consumer Andrew

1 0

Re: (ITS#6647) Overlay sssvlv is always loaded
by masarati＠aero.polimi.it 14 Sep '10

14 Sep '10

> Please try this (nearly blind) patch > > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-14-sssvlv.1.pat…> > > and report through the ITS. Thanks, p. I note that I have messed things up a bit in cleanup; however, this should not affect the testing of the functionality, except if you delete the overlay from the configuration using back-config. If the patch works fine, I'll fix that part. p.

1 0

Re: (ITS#6647) Overlay sssvlv is always loaded
by masarati＠aero.polimi.it 14 Sep '10

14 Sep '10

> 2010/9/14 <masarati(a)aero.polimi.it>: >>> On 14/09/2010 11:33, clem.oudot(a)gmail.com wrote: >>>> Full_Name: Clement OUDOT >>>> Version: 2.4.23 >>>> OS: GNU/Linux >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (83.145.72.122) >>>> >>>> >>>> Hi, >>>> >>>> I am using OpenLDAP 2.4.23 compiled with --enable-overlays (RPMs from >>>> http://www.ltb-project.org). Overlays are not compiled as modules. >>>> >>>> Overlay sssvlv is compiled, but not activated in configuration >>>> >>>> But: >>>> * SSS and VLV controls are displayed in RootDSE >>>> * SSS control is taken into account if present in an LDAP search >>>> operation >>>> >>>> For example, a search with SSS control on cn (which has no ordering >>>> rule) >>>> gives: >>>> result: 18 Inappropriate matching >>>> text: serverSort control: No ordering rule >>>> >>>> >>>> The error would be normal if overlay has been activated, but I think >>>> control >>>> should be ignored if overlay is not active. >>> >>> I hit this exact same issue just last week - it seems that when the >>> overlay is compiled in, the SSS control is displayed in the rootDSE. >>> >>> In my case, this caused a client to attempt to use the control, then >>> fail with a similar message as above. Without the overlay compiled in, >>> the client just doesn't use the control, and the client's operation >>> suceeded. >>> >>> My point is that I agree this probably shouldn't be activated by >>> default, or at the very least a clear warning added in the >>> documentation= > . >> >> This behavior is common to all overlays that register a general feature, >> like controls, extended ops or even just a bit of custom schema: the >> registration is done when the module is loaded (or at startup, if the >> module is statically built into slapd). =A0As a consequence, the feature >> = > is >> advertised because slapd knows about it, but since it is not explicitly >> configured, does not know how to handle it. >> >> In the end, slapd's behavior is correct: it recognizes the feature, it >> recognizes requests for the feature, but does not know how to handle >> them= > , >> thus returns an appropriate error. =A0This looks pretty consistent with >> RFC4511 and specifications of each feature, although I understand it >> coul= > d >> be disappointing. >> >> Perhaps we could modify this behavior so that the module initialization >> does nothing or so, and only the first instantiation of the feature >> cause= > s >> the real initialization. =A0This was discussed in the past, and I recall >> = > it >> created trouble when part of the initialization was needed earlier (e.g. >> registering schema items that need to be used later in the configuration >> or so; a clear case was back-monitor, which registers schema items that >> are needed by other backends when registering custom monitoring; if >> back-monitor startup didn't occur early enough, one had to instantiate >> it >> before any database that wanted to register custom monitoring). >> >> In conclusion: the current behavior is consistent; on a case by case >> basis, feature instantiation could perhaps be deferred as much as >> possible, unless this conflicts with other features. >> > > I understand your point of view. Indeed, recompiling OpenLDAP without > sssvlv overlay works. > > The fact is that for people compiling OpenLDAP with --enable-overlays, > we have a 'regression' with overlay sssvlv, because LDAP clients are > now using the control and get errors. > > Maybe the issue can be retargeted to sssvlv overlay: if an LDAP client > is using the SSS control in a non-critical mode, OpenLDAP should > return search results (unsorted) even if the control fails (because of > missing ordering rule for requested attribute). If the control is > critical, then the error must be returned. Please try this (nearly blind) patch <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-14-sssvlv.1.pat…> and report through the ITS. Thanks, p.

1 0

Re: (ITS#6647) Overlay sssvlv is always loaded
by clem.oudot＠gmail.com 14 Sep '10

14 Sep '10

2010/9/14 <masarati(a)aero.polimi.it>: >> On 14/09/2010 11:33, clem.oudot(a)gmail.com wrote: >>> Full_Name: Clement OUDOT >>> Version: 2.4.23 >>> OS: GNU/Linux >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (83.145.72.122) >>> >>> >>> Hi, >>> >>> I am using OpenLDAP 2.4.23 compiled with --enable-overlays (RPMs from >>> http://www.ltb-project.org). Overlays are not compiled as modules. >>> >>> Overlay sssvlv is compiled, but not activated in configuration >>> >>> But: >>> * SSS and VLV controls are displayed in RootDSE >>> * SSS control is taken into account if present in an LDAP search >>> operation >>> >>> For example, a search with SSS control on cn (which has no ordering >>> rule) >>> gives: >>> result: 18 Inappropriate matching >>> text: serverSort control: No ordering rule >>> >>> >>> The error would be normal if overlay has been activated, but I think >>> control >>> should be ignored if overlay is not active. >> >> I hit this exact same issue just last week - it seems that when the >> overlay is compiled in, the SSS control is displayed in the rootDSE. >> >> In my case, this caused a client to attempt to use the control, then >> fail with a similar message as above. Without the overlay compiled in, >> the client just doesn't use the control, and the client's operation >> suceeded. >> >> My point is that I agree this probably shouldn't be activated by >> default, or at the very least a clear warning added in the documentation= . > > This behavior is common to all overlays that register a general feature, > like controls, extended ops or even just a bit of custom schema: the > registration is done when the module is loaded (or at startup, if the > module is statically built into slapd). =A0As a consequence, the feature = is > advertised because slapd knows about it, but since it is not explicitly > configured, does not know how to handle it. > > In the end, slapd's behavior is correct: it recognizes the feature, it > recognizes requests for the feature, but does not know how to handle them= , > thus returns an appropriate error. =A0This looks pretty consistent with > RFC4511 and specifications of each feature, although I understand it coul= d > be disappointing. > > Perhaps we could modify this behavior so that the module initialization > does nothing or so, and only the first instantiation of the feature cause= s > the real initialization. =A0This was discussed in the past, and I recall = it > created trouble when part of the initialization was needed earlier (e.g. > registering schema items that need to be used later in the configuration > or so; a clear case was back-monitor, which registers schema items that > are needed by other backends when registering custom monitoring; if > back-monitor startup didn't occur early enough, one had to instantiate it > before any database that wanted to register custom monitoring). > > In conclusion: the current behavior is consistent; on a case by case > basis, feature instantiation could perhaps be deferred as much as > possible, unless this conflicts with other features. > I understand your point of view. Indeed, recompiling OpenLDAP without sssvlv overlay works. The fact is that for people compiling OpenLDAP with --enable-overlays, we have a 'regression' with overlay sssvlv, because LDAP clients are now using the control and get errors. Maybe the issue can be retargeted to sssvlv overlay: if an LDAP client is using the SSS control in a non-critical mode, OpenLDAP should return search results (unsorted) even if the control fails (because of missing ordering rule for requested attribute). If the control is critical, then the error must be returned. What is your opinion? Cl=E9ment.

1 0

Re: (ITS#6647) Overlay sssvlv is always loaded
by masarati＠aero.polimi.it 14 Sep '10

14 Sep '10

> On 14/09/2010 11:33, clem.oudot(a)gmail.com wrote: >> Full_Name: Clement OUDOT >> Version: 2.4.23 >> OS: GNU/Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (83.145.72.122) >> >> >> Hi, >> >> I am using OpenLDAP 2.4.23 compiled with --enable-overlays (RPMs from >> http://www.ltb-project.org). Overlays are not compiled as modules. >> >> Overlay sssvlv is compiled, but not activated in configuration >> >> But: >> * SSS and VLV controls are displayed in RootDSE >> * SSS control is taken into account if present in an LDAP search >> operation >> >> For example, a search with SSS control on cn (which has no ordering >> rule) >> gives: >> result: 18 Inappropriate matching >> text: serverSort control: No ordering rule >> >> >> The error would be normal if overlay has been activated, but I think >> control >> should be ignored if overlay is not active. > > I hit this exact same issue just last week - it seems that when the > overlay is compiled in, the SSS control is displayed in the rootDSE. > > In my case, this caused a client to attempt to use the control, then > fail with a similar message as above. Without the overlay compiled in, > the client just doesn't use the control, and the client's operation > suceeded. > > My point is that I agree this probably shouldn't be activated by > default, or at the very least a clear warning added in the documentation. This behavior is common to all overlays that register a general feature, like controls, extended ops or even just a bit of custom schema: the registration is done when the module is loaded (or at startup, if the module is statically built into slapd). As a consequence, the feature is advertised because slapd knows about it, but since it is not explicitly configured, does not know how to handle it. In the end, slapd's behavior is correct: it recognizes the feature, it recognizes requests for the feature, but does not know how to handle them, thus returns an appropriate error. This looks pretty consistent with RFC4511 and specifications of each feature, although I understand it could be disappointing. Perhaps we could modify this behavior so that the module initialization does nothing or so, and only the first instantiation of the feature causes the real initialization. This was discussed in the past, and I recall it created trouble when part of the initialization was needed earlier (e.g. registering schema items that need to be used later in the configuration or so; a clear case was back-monitor, which registers schema items that are needed by other backends when registering custom monitoring; if back-monitor startup didn't occur early enough, one had to instantiate it before any database that wanted to register custom monitoring). In conclusion: the current behavior is consistent; on a case by case basis, feature instantiation could perhaps be deferred as much as possible, unless this conflicts with other features. p.

1 0

Re: (ITS#6647) Overlay sssvlv is always loaded
by jonathan.clarke＠normation.com 14 Sep '10

14 Sep '10

On 14/09/2010 11:33, clem.oudot(a)gmail.com wrote: > Full_Name: Clement OUDOT > Version: 2.4.23 > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.145.72.122) > > > Hi, > > I am using OpenLDAP 2.4.23 compiled with --enable-overlays (RPMs from > http://www.ltb-project.org). Overlays are not compiled as modules. > > Overlay sssvlv is compiled, but not activated in configuration > > But: > * SSS and VLV controls are displayed in RootDSE > * SSS control is taken into account if present in an LDAP search operation > > For example, a search with SSS control on cn (which has no ordering rule) > gives: > result: 18 Inappropriate matching > text: serverSort control: No ordering rule > > > The error would be normal if overlay has been activated, but I think control > should be ignored if overlay is not active. I hit this exact same issue just last week - it seems that when the overlay is compiled in, the SSS control is displayed in the rootDSE. In my case, this caused a client to attempt to use the control, then fail with a similar message as above. Without the overlay compiled in, the client just doesn't use the control, and the client's operation suceeded. My point is that I agree this probably shouldn't be activated by default, or at the very least a clear warning added in the documentation. Jonathan -- ========================================== Jonathan CLARKE ------------------------------------------ Normation 44 rue Cauchy, 94110 Arcueil, France ------------------------------------------ Telephone: +33 (0)1 83 62 26 96 ------------------------------------------ Web: http://www.normation.com/ ==========================================

1 0

(ITS#6647) Overlay sssvlv is always loaded
by clem.oudot＠gmail.com 14 Sep '10

14 Sep '10

Full_Name: Clement OUDOT Version: 2.4.23 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.145.72.122) Hi, I am using OpenLDAP 2.4.23 compiled with --enable-overlays (RPMs from http://www.ltb-project.org). Overlays are not compiled as modules. Overlay sssvlv is compiled, but not activated in configuration But: * SSS and VLV controls are displayed in RootDSE * SSS control is taken into account if present in an LDAP search operation For example, a search with SSS control on cn (which has no ordering rule) gives: result: 18 Inappropriate matching text: serverSort control: No ordering rule The error would be normal if overlay has been activated, but I think control should be ignored if overlay is not active.

1 0

(ITS#6489) replication problem - new valuable information, nearly solved
by frank.offermanns＠caseris.de 14 Sep '10

14 Sep '10

Hello, after digging very deep to find out, what the problem could be, I found interesting facts: 1) With our new client-DLL the master/slave replication problem seems to be solved. (our old DLL wrote each attribute separately, our new writes all in a row), but 2) So I switched back to Master/Master in hope that this works also, but I found out the following. - my client-DLL first create a new user entry and then it does a add with all attributes. - at the second master server I activated replication log and saw the following short message (the important part is surounded with ________): "do_syncrep2: rid=001 cookie=rid=001,sid=001,csn=20100914081312.596142Z#000000#00 1#000000 syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=001 be_search (0) syncrepl_entry: rid=001 cn=10008,o=BAD_CLIENT3,ou=users,o=caesar slap_queue_csn: queing 09369668 20100914081312.596142Z#000000#001#000000 syncprov_matchops: skipping original sid 001 slap_graduate_commit_csn: removing 09377b10 20100914081312.596142Z#000000#001#00 0000 syncrepl_entry: rid=001 be_add cn=10008,o=BAD_CLIENT3,ou=users,o=caesar (0) slap_queue_csn: queing 09369668 20100914081312.596142Z#000000#001#000000 syncprov_matchops: skipping original sid 001 slap_graduate_commit_csn: removing 09377b10 20100914081312.596142Z#000000#001#00 0000 do_syncrep2: rid=001 cookie= syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) __________________________________________________________________ dn_callback : new entry is older than ours cn=10008,o=BAD_CLIENT3,ou=users,o=cae sar ours 20100914081312.596142Z#000000#001#000000, new 20100914081312.100780Z#00 0000#001#000000 ___________________________________________________________________ syncrepl_entry: rid=001 be_search (0) syncrepl_entry: rid=001 cn=10008,o=BAD_CLIENT3,ou=users,o=caesar syncrepl_entry: rid=001 entry unchanged, ignored (cn=10008,o=BAD_CLIENT3,ou=user s,o=caesar)" Is it a bug, or a result of a bad time synchronization (I only have windows standard time synchronization) But if it would be a time synchronization problem, in recent posts I asked when the time synchronization is important. I got the answer (if understood correctly) that the time synchronization only matters if concurrent write operations are made. So it should'nt be an issue here, since I made my write operations only at one master. Best regards, Frank

1 0

Re: (ITS#6639) syncrepl failing using SASL/GSSAPI
by hyc＠symas.com 12 Sep '10

12 Sep '10

Bill MacAllister wrote: > Howard, > > The patched packages where installed last night on the production OpenLDAP > master with two of the replicas in the failing state. Once the patched > slapd was started the two problem replicas quickly caught up and everything > looks good now. Thanks for the confirmation. I'll commit a final fix to HEAD shortly. > > Thanks again for your help. > > Bill > -- -- 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#6639) syncrepl failing using SASL/GSSAPI
by whm＠stanford.edu 11 Sep '10

11 Sep '10

--On Thursday, September 09, 2010 10:43:06 PM -0700 Howard Chu <hyc(a)symas.com> wrote: > whm(a)stanford.edu wrote: >> --On Friday, September 03, 2010 01:23:17 AM -0700 Bill MacAllister<whm(a)stanford.edu> wrote: >> >> The problem with the database was only coincidental. Restoring the database >> got the failing replica past the problem replication event. >> >> In the replica pool of 6 servers we have seen the problem on there of the >> servers. In thinking about this more it is unlikely that it is a slave >> problem since the slaves have been in use for about 6 weeks and we did >> not see the problem. Only when we changed the master to 2.4.23 did we >> see the problem. I have captured a master debug log of the problem >> event. It is at http://www.stanford.edu/~whm/files/master-debug.txt. >> >> Bill >> > Please try with this patch: > > Index: sasl.c > =================================================================== > RCS file: /repo/OpenLDAP/pkg/ldap/libraries/libldap/sasl.c,v > retrieving revision 1.79 > diff -u -r1.79 sasl.c > --- sasl.c 13 Apr 2010 20:17:56 -0000 1.79 > +++ sasl.c 10 Sep 2010 05:42:22 -0000 > @@ -733,8 +733,9 @@ > return ret; > } else if ( p->buf_out.buf_ptr != p->buf_out.buf_end ) { > /* partial write? pretend nothing got written */ > - len2 = 0; > p->flags |= LDAP_PVT_SASL_PARTIAL_WRITE; > + sock_errset(EAGAIN); > + len2 = -1; > } > > /* return number of bytes encoded, not written, to ensure Howard, The patched packages where installed last night on the production OpenLDAP master with two of the replicas in the failing state. Once the patched slapd was started the two problem replicas quickly caught up and everything looks good now. Thanks again for your help. Bill -- Bill MacAllister Infrastructure Delivery Group, Stanford University

1 0

Re: (ITS#6565) DNSSRV referrals: chaining without search base
by masarati＠aero.polimi.it 10 Sep '10

10 Sep '10

> I've checked a simple configuration (global instance of chain overlay; > request for non existing entry, resulting in slapd returning the default > referral), and nothing strange appeared (the offending instruction is > executed). The issue might be specific to your configuration. You'll > probably need to post more details. I've checked a "real" case: DNSSRV-located DSAs, one responding and one not. Things seem to work as expected, no cores and valgrind shows no issue. In any case, I have committed a few modifications to HEAD code (plugs a potential leak). Please test and either provide more details about the core or more details about the configuration. p.

1 0

Re: (ITS#6645) Yet Another LDIF Wrap Patch
by masarati＠aero.polimi.it 10 Sep '10

10 Sep '10

> hyc(a)symas.com writes: >> Not thrilled with the magic constant 2^31-1. Seems like you should have >> just >> used "if ( wrap && len > wrap )" instead of a word-size-dependent magic. > > The code just needs to be a little less clever:-) Pass -1 to a > 'ber_len_t wrap'. The constant (ber_len_t)-1 will prevent wrapping: > "if (len > (ber_len_t)-1)" always fails. <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-09-ldif-wrap.3.…> Includes documentation. Thanks for checking this. p.

1 0

Re: (ITS#6645) Yet Another LDIF Wrap Patch
by masarati＠aero.polimi.it 10 Sep '10

10 Sep '10

> hyc(a)symas.com writes: >> Not thrilled with the magic constant 2^31-1. Seems like you should have >> just >> used "if ( wrap && len > wrap )" instead of a word-size-dependent magic. > > The code just needs to be a little less clever:-) Pass -1 to a > 'ber_len_t wrap'. The constant (ber_len_t)-1 will prevent wrapping: > "if (len > (ber_len_t)-1)" always fails. Thanks. > But if we are going to have smarter LDIF output, I'm more interested in > an option to avoid base64 encoding of valid UTF-8 strings. Also one > to force base64-encoding for caller-specified attributes. Or just > a bitflag to ldif_sput() after the caller checks the attribute type. See ldif_must_b64_encode_register() :) We already use it to force encoding of olcRootPW and other password-like attrs in proxy backends. p.

1 0

Re: (ITS#6645) Yet Another LDIF Wrap Patch
by h.b.furuseth＠usit.uio.no 10 Sep '10

10 Sep '10

hyc(a)symas.com writes: > Not thrilled with the magic constant 2^31-1. Seems like you should have just > used "if ( wrap && len > wrap )" instead of a word-size-dependent magic. The code just needs to be a little less clever:-) Pass -1 to a 'ber_len_t wrap'. The constant (ber_len_t)-1 will prevent wrapping: "if (len > (ber_len_t)-1)" always fails. But if we are going to have smarter LDIF output, I'm more interested in an option to avoid base64 encoding of valid UTF-8 strings. Also one to force base64-encoding for caller-specified attributes. Or just a bitflag to ldif_sput() after the caller checks the attribute type. -- Hallvard

1 0

Re: (ITS#6646) back-hdb dncache disregarded in some searches
by ondrej.kuznik＠acision.com 10 Sep '10

10 Sep '10

On 09/10/2010 11:19 AM, hyc(a)symas.com wrote: > This fact is already documented in the manpage. This ITS will be closed. I disagree. The manpage states: "It should be noted that the DN cache is allowed to temporarily grow beyond the configured size. It does this if many entries are locked when it tries to do a purge, because that means they're legitimately in use. Also, the DN cache never purges entries that have cached children, so depending on the shape of the DIT, it could have lots of cached DNs over the defined limit." However, in the last case with the sizelimit, the DN cache grows over its configured size permanently. They do not seem to be legitimately in use and if they are, it is because the code that used them told noone it stopped doing so as the sizelimit has been reached or connection severed. All those entries are leafs, so no children either. From all this I deduced that either the code or documentation are missing something. And I will repeat myself, but two searches that differ only in their search bases behave _very_ differently. If one search iterates though the database and uses and frees the entries it processes emitting and the other one gets all entries first and parses and releases them afterwards, and if something interrupts it, does not release some. But yet again, I am only slowly gaining familiarity with OpenLDAP's immerse codebase and thus have no authority to speak about code I am nowhere near familiar with. Still, I am eager to learn as much as I can, so I'll be glad for some pointers. Thanks, Ondra This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

Re: (ITS#6639) syncrepl failing using SASL/GSSAPI
by hyc＠symas.com 10 Sep '10

10 Sep '10

whm(a)stanford.edu wrote: > --On Thursday, September 09, 2010 10:43:06 PM -0700 Howard Chu<hyc(a)symas.com> wrote: > >> whm(a)stanford.edu wrote: >>> --On Friday, September 03, 2010 01:23:17 AM -0700 Bill MacAllister<whm(a)stanford.edu> wrote: >>> >>> The problem with the database was only coincidental. Restoring the database >>> got the failing replica past the problem replication event. >>> >>> In the replica pool of 6 servers we have seen the problem on there of the >>> servers. In thinking about this more it is unlikely that it is a slave >>> problem since the slaves have been in use for about 6 weeks and we did >>> not see the problem. Only when we changed the master to 2.4.23 did we >>> see the problem. I have captured a master debug log of the problem >>> event. It is at http://www.stanford.edu/~whm/files/master-debug.txt. >>> >>> Bill >>> >> Please try with this patch: >> >> Index: sasl.c >> =================================================================== >> RCS file: /repo/OpenLDAP/pkg/ldap/libraries/libldap/sasl.c,v >> retrieving revision 1.79 >> diff -u -r1.79 sasl.c >> --- sasl.c 13 Apr 2010 20:17:56 -0000 1.79 >> +++ sasl.c 10 Sep 2010 05:42:22 -0000 >> @@ -733,8 +733,9 @@ >> return ret; >> } else if ( p->buf_out.buf_ptr != p->buf_out.buf_end ) { >> /* partial write? pretend nothing got written */ >> - len2 = 0; >> p->flags |= LDAP_PVT_SASL_PARTIAL_WRITE; >> + sock_errset(EAGAIN); >> + len2 = -1; >> } >> >> /* return number of bytes encoded, not written, to ensure > > I have applied the patch and the debian packages built fine. I have > installed the new packages on the master servers in our dev and test > environments. Initial tests show that basic replication is working. > Of course, this problem did not exhibit itself in our test > environments. I will install it in our production environment Friday > evening and let you know what happens. > > Am I correct in assuming that the root of the problem is on the providers? Yes. Really, the problem will occur when either a client or server writes a large buffer thru a SASL encrypted connection, but this is more likely to happen when a server is sending responses. > I am asking because I was not planning installing the new version on the > consumers right away since 'emergency' changes to production software > require special approval. I would like to upgrade the providers in our > next maintenance window which is next Thursday. If you think I should > do it with the update of the master let me know. It's probably not urgent for the consumers, just bear in mind that any clients querying them thru SASL could also run into similar issues. -- -- 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#6639) syncrepl failing using SASL/GSSAPI
by whm＠stanford.edu 10 Sep '10

10 Sep '10

--On Thursday, September 09, 2010 10:43:06 PM -0700 Howard Chu <hyc(a)symas.com> wrote: > whm(a)stanford.edu wrote: >> --On Friday, September 03, 2010 01:23:17 AM -0700 Bill MacAllister<whm(a)stanford.edu> wrote: >> >> The problem with the database was only coincidental. Restoring the database >> got the failing replica past the problem replication event. >> >> In the replica pool of 6 servers we have seen the problem on there of the >> servers. In thinking about this more it is unlikely that it is a slave >> problem since the slaves have been in use for about 6 weeks and we did >> not see the problem. Only when we changed the master to 2.4.23 did we >> see the problem. I have captured a master debug log of the problem >> event. It is at http://www.stanford.edu/~whm/files/master-debug.txt. >> >> Bill >> > Please try with this patch: > > Index: sasl.c > =================================================================== > RCS file: /repo/OpenLDAP/pkg/ldap/libraries/libldap/sasl.c,v > retrieving revision 1.79 > diff -u -r1.79 sasl.c > --- sasl.c 13 Apr 2010 20:17:56 -0000 1.79 > +++ sasl.c 10 Sep 2010 05:42:22 -0000 > @@ -733,8 +733,9 @@ > return ret; > } else if ( p->buf_out.buf_ptr != p->buf_out.buf_end ) { > /* partial write? pretend nothing got written */ > - len2 = 0; > p->flags |= LDAP_PVT_SASL_PARTIAL_WRITE; > + sock_errset(EAGAIN); > + len2 = -1; > } > > /* return number of bytes encoded, not written, to ensure I have applied the patch and the debian packages built fine. I have installed the new packages on the master servers in our dev and test environments. Initial tests show that basic replication is working. Of course, this problem did not exhibit itself in our test environments. I will install it in our production environment Friday evening and let you know what happens. Am I correct in assuming that the root of the problem is on the providers? I am asking because I was not planning installing the new version on the consumers right away since 'emergency' changes to production software require special approval. I would like to upgrade the providers in our next maintenance window which is next Thursday. If you think I should do it with the update of the master let me know. Bill -- Bill MacAllister Infrastructure Delivery Group, Stanford University

1 0

Re: (ITS#6646) back-hdb dncache disregarded in some searches
by hyc＠symas.com 10 Sep '10

10 Sep '10

ondrej.kuznik(a)acision.com wrote: > Full_Name: Ondrej Kuznik > Version: 2.4.23 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (62.168.56.1) This fact is already documented in the manpage. This ITS will be closed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6646) back-hdb dncache disregarded in some searches
by ondrej.kuznik＠acision.com 10 Sep '10

10 Sep '10

Full_Name: Ondrej Kuznik Version: 2.4.23 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.168.56.1) Example: database hdb suffix o=test dncache 1000 is a database that has most of its 1M entries as uid=%d,o=one,o=test. perform an unindexed search: ldapsearch -b o=test uid=1 the entry is first in the db, so is spit out immediately. Watching dn cn=Database 2,cn=Databases,cn=Monitor shows: olmBDBDNCache: 1002 This is OK, but: perform an unindexed search with base o=one,o=test: ldapsearch -b o=one,o=test uid=1 watching dn cn=Database 2,cn=Databases,cn=Monitor shows that all 1M dns are loaded into the cache and only after that the entry uid=1,o=one,o=test is spit out. Then the dncache starts decreasing as the database filters out the remaining entries: olmBDBDNCache: 1000002 Another twist: perform an unindexed search with base o=one,o=test but either kill ldapsearch while hdb is still crunching or add a sizelimit greater than the number of entries that should be returned: ldapsearch -z2 -b o=one,o=test "uid=1*" olmBDBDNCache contains most of the database and never decreases. olmBDBDNCache: 1000002 A dn is later freed from the cache only in case it is referenced, should there be another similar arc e.g. o=another,o=test, its dns are added inside the cache too if we use the same technique. This makes hdb unusable for a large database (whose set of dns alone can eat the entire memory if loaded into dncache) unless one can guarantee that every search is either indexed or with search base == suffix of the db. In the example scenario, the value of cachefree affects almost nothing.

1 0

Re: (ITS#6639) syncrepl failing using SASL/GSSAPI
by hyc＠symas.com 09 Sep '10

09 Sep '10

whm(a)stanford.edu wrote: > --On Friday, September 03, 2010 01:23:17 AM -0700 Bill MacAllister<whm(a)stanford.edu> wrote: > > The problem with the database was only coincidental. Restoring the database > got the failing replica past the problem replication event. > > In the replica pool of 6 servers we have seen the problem on there of the > servers. In thinking about this more it is unlikely that it is a slave > problem since the slaves have been in use for about 6 weeks and we did > not see the problem. Only when we changed the master to 2.4.23 did we > see the problem. I have captured a master debug log of the problem > event. It is at http://www.stanford.edu/~whm/files/master-debug.txt. > > Bill > Please try with this patch: Index: sasl.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/libraries/libldap/sasl.c,v retrieving revision 1.79 diff -u -r1.79 sasl.c --- sasl.c 13 Apr 2010 20:17:56 -0000 1.79 +++ sasl.c 10 Sep 2010 05:42:22 -0000 @@ -733,8 +733,9 @@ return ret; } else if ( p->buf_out.buf_ptr != p->buf_out.buf_end ) { /* partial write? pretend nothing got written */ - len2 = 0; p->flags |= LDAP_PVT_SASL_PARTIAL_WRITE; + sock_errset(EAGAIN); + len2 = -1; } /* return number of bytes encoded, not written, to ensure -- -- 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#6645) Yet Another LDIF Wrap Patch
by masarati＠aero.polimi.it 09 Sep '10

09 Sep '10

<ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-09-ldif-wrap.2.…> :)

1 0

Re: (ITS#6645) Yet Another LDIF Wrap Patch
by hyc＠symas.com 09 Sep '10

09 Sep '10

masarati(a)aero.polimi.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-09-ldif-wrap.1.… > Submission from: (NULL) (129.72.165.135) > Submitted by: ando > > > The subject should be self-explanatory. It is only exploited by slapcat, via > the -o ldif-wrap=<n> option (<n> < 0: default;<n> == 0: no wrap;<n> > 0: wrap > value); extending ldapsearch is trivial. > > I'm *NOT* going to commit this unless there is unanimous consensus ;) Not thrilled with the magic constant 2^31-1. Seems like you should have just used "if ( wrap && len > wrap )" instead of a word-size-dependent magic. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

ITS#6598
by masarati＠aero.polimi.it 09 Sep '10

09 Sep '10

Committed to HEAD; please test. Thanks, p.

1 0

ITS#6600
by masarati＠aero.polimi.it 09 Sep '10

09 Sep '10

Applied (with changes) to HEAD; please test. Thanks, p.

1 0

Re: (ITS#6565) DNSSRV referrals: chaining without search base
by masarati＠aero.polimi.it 09 Sep '10

09 Sep '10

>> Hello, >> we tested this (HEAD code): >> >> 1. ITS 6565 seems to be fixed: Chaining works now with correct search >> base. >> >> 2. If the target server of the chaining is not reachable we get "no such >> object", followed by a SIGSEV (core dump). Stack Trace: >> >> #0 0x0000000400040004 in ?? () >> #1 0x000000000042eb60 in slap_cleanup_play (op=0x7fffe40028c0, >> rs=0x7ffff1f70940) at result.c:436 >> #2 0x000000000043145a in send_ldap_response (op=0x7fffe40028c0, >> rs=0x7ffff1f70940) at result.c:621 >> #3 0x00000000004320cd in slap_send_ldap_result (op=0x7fffe40028c0, >> rs=0x7ffff1f70940) at result.c:750 >> #4 0x00000000004e2154 in ldap_chain_response (op=0x7fffe40028c0, >> rs=0x7ffff1f70940) at chain.c:1132 >> #5 0x00000000004833f8 in over_back_response (op=0x7fffe40028c0, >> rs=0x7ffff1f70940) at backover.c:237 >> #6 0x000000000042eace in slap_response_play (op=0x7fffe40028c0, >> rs=0x7ffff1f70940) at result.c:402 >> #7 0x0000000000431437 in send_ldap_response (op=0x7fffe40028c0, >> rs=0x7ffff1f70940) at result.c:476 >> #8 0x00000000004320cd in slap_send_ldap_result (op=0x7fffe40028c0, >> rs=0x7ffff1f70940) at result.c:750 >> #9 0x0000000000497adc in dnssrv_back_referrals (op=0x7fffe40028c0, >> rs=0x7ffff1f70940) at referral.c:118 >> >> 0x0000000400040004 is the address referenced in >> op->o_callback->sc_cleanup(op,rs) . > > Thanks for the report. It would be useful to know how that memory became > stale or dangling. Could you run slapd under valgrind and report any > error message related to accessing that memory? Thanks, p. I've checked a simple configuration (global instance of chain overlay; request for non existing entry, resulting in slapd returning the default referral), and nothing strange appeared (the offending instruction is executed). The issue might be specific to your configuration. You'll probably need to post more details. p.

1 0

(ITS#6645) Yet Another LDIF Wrap Patch
by masarati＠aero.polimi.it 09 Sep '10

09 Sep '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-09-ldif-wrap.1.… Submission from: (NULL) (129.72.165.135) Submitted by: ando The subject should be self-explanatory. It is only exploited by slapcat, via the -o ldif-wrap=<n> option (<n> < 0: default; <n> == 0: no wrap; <n> > 0: wrap value); extending ldapsearch is trivial. I'm *NOT* going to commit this unless there is unanimous consensus ;) Enjoy. p.

1 0

Re: (ITS#6565) DNSSRV referrals: chaining without search base
by masarati＠aero.polimi.it 09 Sep '10

09 Sep '10

> Hello, > we tested this (HEAD code): > > 1. ITS 6565 seems to be fixed: Chaining works now with correct search > base. > > 2. If the target server of the chaining is not reachable we get "no such > object", followed by a SIGSEV (core dump). Stack Trace: > > #0 0x0000000400040004 in ?? () > #1 0x000000000042eb60 in slap_cleanup_play (op=0x7fffe40028c0, > rs=0x7ffff1f70940) at result.c:436 > #2 0x000000000043145a in send_ldap_response (op=0x7fffe40028c0, > rs=0x7ffff1f70940) at result.c:621 > #3 0x00000000004320cd in slap_send_ldap_result (op=0x7fffe40028c0, > rs=0x7ffff1f70940) at result.c:750 > #4 0x00000000004e2154 in ldap_chain_response (op=0x7fffe40028c0, > rs=0x7ffff1f70940) at chain.c:1132 > #5 0x00000000004833f8 in over_back_response (op=0x7fffe40028c0, > rs=0x7ffff1f70940) at backover.c:237 > #6 0x000000000042eace in slap_response_play (op=0x7fffe40028c0, > rs=0x7ffff1f70940) at result.c:402 > #7 0x0000000000431437 in send_ldap_response (op=0x7fffe40028c0, > rs=0x7ffff1f70940) at result.c:476 > #8 0x00000000004320cd in slap_send_ldap_result (op=0x7fffe40028c0, > rs=0x7ffff1f70940) at result.c:750 > #9 0x0000000000497adc in dnssrv_back_referrals (op=0x7fffe40028c0, > rs=0x7ffff1f70940) at referral.c:118 > > 0x0000000400040004 is the address referenced in > op->o_callback->sc_cleanup(op,rs) . Thanks for the report. It would be useful to know how that memory became stale or dangling. Could you run slapd under valgrind and report any error message related to accessing that memory? Thanks, p.

1 0

Re: (ITS#6565) DNSSRV referrals: chaining without search base
by mlists＠keutel.de 09 Sep '10

09 Sep '10

Hello, we tested this (HEAD code): 1. ITS 6565 seems to be fixed: Chaining works now with correct search base. 2. If the target server of the chaining is not reachable we get "no such object", followed by a SIGSEV (core dump). Stack Trace: #0 0x0000000400040004 in ?? () #1 0x000000000042eb60 in slap_cleanup_play (op=0x7fffe40028c0, rs=0x7ffff1f70940) at result.c:436 #2 0x000000000043145a in send_ldap_response (op=0x7fffe40028c0, rs=0x7ffff1f70940) at result.c:621 #3 0x00000000004320cd in slap_send_ldap_result (op=0x7fffe40028c0, rs=0x7ffff1f70940) at result.c:750 #4 0x00000000004e2154 in ldap_chain_response (op=0x7fffe40028c0, rs=0x7ffff1f70940) at chain.c:1132 #5 0x00000000004833f8 in over_back_response (op=0x7fffe40028c0, rs=0x7ffff1f70940) at backover.c:237 #6 0x000000000042eace in slap_response_play (op=0x7fffe40028c0, rs=0x7ffff1f70940) at result.c:402 #7 0x0000000000431437 in send_ldap_response (op=0x7fffe40028c0, rs=0x7ffff1f70940) at result.c:476 #8 0x00000000004320cd in slap_send_ldap_result (op=0x7fffe40028c0, rs=0x7ffff1f70940) at result.c:750 #9 0x0000000000497adc in dnssrv_back_referrals (op=0x7fffe40028c0, rs=0x7ffff1f70940) at referral.c:118 0x0000000400040004 is the address referenced in op->o_callback->sc_cleanup(op,rs) . Regards, Jochen. Am 05.09.2010 18:01, schrieb masarati(a)aero.polimi.it: >> Hello, >> >>> Hi. I don't have time to work at this right now, but I think the >>> solution >>> would be to modify slapo-chain(5) so that when a referral's DN is "" and >>> the DN in the original request is not "", to use that DN instead. The >>> original request DN can be found in op->o_req_dn. >> >> we tested the following - with success: >> >> Just replace in servers/slapd/back-ldap/chain.c, function >> ldap_chain_op(), line 485-486: >> >> op->o_req_dn = pdn; >> op->o_req_ndn = ndn; >> >> With: >> >> if (pdn.bv_len> 0) { >> op->o_req_dn = pdn; >> } >> if (ndn.bv_len> 0) { >> op->o_req_ndn = ndn; >> } >> >> It would be great if this came into the official code. > > This issue was fixed consistently in HEAD code more than a month ago, > please test it and report, so in case it works the ITS can be closed and > the fix released. > > Thanks, p. >

1 0

Re: (ITS#6644) wrong conversion specifier for "port" in "ldap_domain2hostlist"
by masarati＠aero.polimi.it 09 Sep '10

09 Sep '10

Fixed in HEAD. Thanks, p.

1 0

Re: (ITS#6642) back-meta idassert with SASL EXTERNAL ignoring parameters
by masarati＠aero.polimi.it 09 Sep '10

09 Sep '10

> I've just tested this scenario using the back-meta sources (and > slap.h,sl_malloc.c) from HEAD. I also tried to add "tls start" to the > back-meta configuration. Not sure why you need those... > Unfortunately, the problem still persists. (But the workaround, > setting LDAPTLS_..., still works) > > When I look at the debug outputs (at debug level 1), the first > difference is in the SSL_connect messages. Only my workaround method > is sending the "write certificate verify" to authenticate with the > certificate, whereas it doesn't send this message without the > workaround. Can I see the entire configuration of both sides? (minus passwords and so, of course). Is the client using TLS? I'll re-check later, but I could use TLS-based EXTERNAL auth with both back-ldap and back-meta with and without setting "tls start". Just to make sure, can you pull the entire HEAD? Thanks for checking, in any case. p. > The Output from the "good" request (with workaround) is > ----------------------------------------------------------------------------------------- > TLS trace: SSL_connect:SSLv3 read server certificate A > TLS trace: SSL_connect:SSLv3 read server key exchange A > TLS trace: SSL_connect:SSLv3 read server certificate request A > TLS trace: SSL_connect:SSLv3 read server done A > TLS trace: SSL_connect:SSLv3 write client certificate A > TLS trace: SSL_connect:SSLv3 write client key exchange A > TLS trace: SSL_connect:SSLv3 write certificate verify A > TLS trace: SSL_connect:SSLv3 write change cipher spec A > TLS trace: SSL_connect:SSLv3 write finished A > TLS trace: SSL_connect:SSLv3 flush data > TLS trace: SSL_connect:SSLv3 read finished A > ldap_int_sasl_open: host=localhost > ldap_sasl_bind_s > ldap_sasl_bind > ldap_send_initial_request > ldap_send_server_request > ----------------------------------------------------------------------------------------- > > The output from the request without the workaround: > ----------------------------------------------------------------------------------------- > TLS trace: SSL_connect:SSLv3 read server certificate A > TLS trace: SSL_connect:SSLv3 read server key exchange A > TLS trace: SSL_connect:SSLv3 read server certificate request A > TLS trace: SSL_connect:SSLv3 read server done A > TLS trace: SSL_connect:SSLv3 write client certificate A > TLS trace: SSL_connect:SSLv3 write client key exchange A > TLS trace: SSL_connect:SSLv3 write change cipher spec A > TLS trace: SSL_connect:SSLv3 write finished A > TLS trace: SSL_connect:SSLv3 flush data > TLS trace: SSL_connect:SSLv3 read finished A > ldap_int_sasl_open: host=localhost > ldap_free_connection 1 1 > ldap_send_unbind > ber_flush2: 7 bytes to sd 15 > TLS trace: SSL3 alert write:warning:close notify > ldap_free_connection: actually freed > ----------------------------------------------------------------------------------------- > > Regards, > Manuel > > >

1 0

(ITS#6644) wrong conversion specifier for "port" in "ldap_domain2hostlist"
by mgaupp＠googlemail.com 09 Sep '10

09 Sep '10

Full_Name: Manuel Gaupp Version: 2.4.23 OS: Linux 2.6/x86 URL: Submission from: (NULL) (93.222.138.193) Hi, when using ldap_domain2hostlist to get informations from DNS SRV RRs, there is an issue for ports > 32767. For example, when a DNS SRV RR _ldap._tcp is referenced to port 63677 on a specific host, the returned hostlist contains port -1859. The error is caused by a wrong conversion in libldap/dnssrv.c, line 292. In this sprintf line, the unsigned short "port" is converted using "%hd" instead of "%hu". The attached patch should fix this issue (it did in my case). Regards, Manuel --- openldap-2.4.23-orig/libraries/libldap/dnssrv.c 2010-04-13 22:22:56.000000000 +0200 +++ openldap-2.4.23/libraries/libldap/dnssrv.c 2010-09-09 13:41:27.000000000 +0200 @@ -289,7 +289,7 @@ int ldap_domain2hostlist( /* not first time around */ hostlist[cur++] = ' '; } - cur += sprintf(&hostlist[cur], "%s:%hd", host, port); + cur += sprintf(&hostlist[cur], "%s:%hu", host, port); } add_size:; p += size;

1 0

Re: (ITS#6642) back-meta idassert with SASL EXTERNAL ignoring parameters
by mgaupp＠googlemail.com 09 Sep '10

09 Sep '10

I've just tested this scenario using the back-meta sources (and slap.h,sl_malloc.c) from HEAD. I also tried to add "tls start" to the back-meta configuration. Unfortunately, the problem still persists. (But the workaround, setting LDAPTLS_..., still works) When I look at the debug outputs (at debug level 1), the first difference is in the SSL_connect messages. Only my workaround method is sending the "write certificate verify" to authenticate with the certificate, whereas it doesn't send this message without the workaround. The Output from the "good" request (with workaround) is ----------------------------------------------------------------------------------------- TLS trace: SSL_connect:SSLv3 read server certificate A TLS trace: SSL_connect:SSLv3 read server key exchange A TLS trace: SSL_connect:SSLv3 read server certificate request A TLS trace: SSL_connect:SSLv3 read server done A TLS trace: SSL_connect:SSLv3 write client certificate A TLS trace: SSL_connect:SSLv3 write client key exchange A TLS trace: SSL_connect:SSLv3 write certificate verify A TLS trace: SSL_connect:SSLv3 write change cipher spec A TLS trace: SSL_connect:SSLv3 write finished A TLS trace: SSL_connect:SSLv3 flush data TLS trace: SSL_connect:SSLv3 read finished A ldap_int_sasl_open: host=localhost ldap_sasl_bind_s ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ----------------------------------------------------------------------------------------- The output from the request without the workaround: ----------------------------------------------------------------------------------------- TLS trace: SSL_connect:SSLv3 read server certificate A TLS trace: SSL_connect:SSLv3 read server key exchange A TLS trace: SSL_connect:SSLv3 read server certificate request A TLS trace: SSL_connect:SSLv3 read server done A TLS trace: SSL_connect:SSLv3 write client certificate A TLS trace: SSL_connect:SSLv3 write client key exchange A TLS trace: SSL_connect:SSLv3 write change cipher spec A TLS trace: SSL_connect:SSLv3 write finished A TLS trace: SSL_connect:SSLv3 flush data TLS trace: SSL_connect:SSLv3 read finished A ldap_int_sasl_open: host=localhost ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 15 TLS trace: SSL3 alert write:warning:close notify ldap_free_connection: actually freed ----------------------------------------------------------------------------------------- Regards, Manuel

1 0

Re: (ITS#6642) back-meta idassert with SASL EXTERNAL ignoring parameters
by masarati＠aero.polimi.it 08 Sep '10

08 Sep '10

The issue should be fixed in HEAD both for back-meta and back-ldap; now if TLS is required by idassert it will be started. Moreover, back-meta now allows to specify tls options per-target. The man page has not been updated yet. Please test and report through the ITS. Thanks, p.

1 0

Re: (ITS#6638) ldapseach segfault on OSX
by quanah＠zimbra.com 08 Sep '10

08 Sep '10

--On Monday, September 06, 2010 3:11 AM +0200 masarati(a)aero.polimi.it wrote: > Should now be fixed in HEAD; platform independent, on Linux was not > failing but memory was being used incorrectly. ldapsearch-specific, no > issue in client library. Please test. Thanks, p. > I can confirm the issue no longer occurs with this patch in place. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

ITS#6642
by masarati＠aero.polimi.it 08 Sep '10

08 Sep '10

The problem is slightly different: the tls_* parameters of idassert are ignored unless TLS is started for other reasons. I believe back-meta needs to automatically start TLS for those connections created by idassert when idassert requires TLS for authentication. You can work this around by setting tls start this forces TLS to be started on all connections (tls try-start will fall back to non-TLS if it cannot be started). I note that there is an asymmetry between back-ldap and back-meta: the former allows to configure specific tls_* parameters for the "tls" statement. However, also back-ldap seems to require the "tls" statement to honor EXTERNAL TLS-based idassert. p.

1 0

(ITS#6643) back-meta silently retries anonymously in case of idassert with auth method not supported
by masarati＠aero.polimi.it 08 Sep '10

08 Sep '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.165.240) Submitted by: ando A fix is coming. p.

1 0

(ITS#6642) back-meta idassert with SASL EXTERNAL ignoring parameters
by mgaupp＠googlemail.com 08 Sep '10

08 Sep '10

Full_Name: Manuel Gaupp Version: 2.4.23 OS: Linux 2.6/x86 URL: Submission from: (NULL) (93.222.169.203) Hi, as described in http://www.openldap.org/lists/openldap-technical/201009/msg00073.html using SASL EXTERNAL authentication within back-meta is not possible without the workaround to set some LDAPTLS_... environment variables. In http://www.openldap.org/lists/openldap-technical/201009/msg00085.html it is mentioned, that back-meta ignores the tls_... parameters for SASL EXTERNAL auth. I used the following configuration ------------------------------------------------- database meta suffix "dc=example" uri "ldaps://server2:636/cn=server2,dc=example" idassert-authzFrom "dn:*" idassert-bind bindmethod=sasl saslmech=EXTERNAL tls_cert=mycert.crt tls_key=mycert.key tls_cacert=trusted-ca.pem mode=none ------------------------------------------------- At least, the options tls_cert,tls_key and tls_cacert should work properly to authenticate with TLS certificates. Thanks in advance Manuel Gaupp

1 0

Re: (ITS#6548) Many "connection_read(): no connection!" warnings when using ldapi:/// and a bind DN (no external authentication)
by gturner＠unzane.com 07 Sep '10

07 Sep '10

Hello folks, I've never used a jitterbug, so I hope this email goes to the right place and doesn't spam up the system. I've been experiencing the same problem as Mark. I use OpenLDAP 2.4.23 packaged in Debian. I have a few processes that connect to ldapi:/// socket and do anonymous binds, there are one or two "no connection!" log messages each time these processes run. None of my remote connections produce these messages. This happens at very low volume, when slapd is idle. When slapd gets more utilization, maybe one or two requests per second, the noise stops. I've spent a few hours looking at the source of OpenLDAP slapd and libldap, also Perl Net::LDAP (the client most often generating these log entries on my system). The source code for OpenLDAP looks very clean, but I'm no C expert, and I'm lost in the asynchronous nature of the connection.c. FYI, Net::LDAP doesn't use libldap - it's all Perl, no native libraries. After hundreds of tests and various olcLogLevel settings I've finally stumbled upon something that solves the problem... usleep(1); I know this has to be the lamest bug report ever, but it works, please bear with me. The first thing that tipped me to try 'usleep' was that with olcLogLevel set to "trace packets args conns stats", I get the following output: connection_get(14) connection_get(14): got connid=1007 connection_read(14): checking for input on id=1007 * op tag 0x42, time 1283917507 * ber_get_next on fd 14 failed errno=0 (Success) connection_read(14): input error=-2 id=1007, closing. connection_closing: readying conn=1007 sd=14 for close connection_close: deferring conn=1007 sd=14 conn=1007 op=2 do_unbind conn=1007 op=2 UNBIND connection_resched: attempting closing conn=1007 sd=14 connection_close: conn=1007 sd=14 daemon: removing 14 conn=1007 fd=14 closed daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=8 active_threads=0 tvp=zero daemon: epoll: listen=9 active_threads=0 tvp=zero connection_get(14) connection_get(14): connection not used connection_get(14) connection_get(14): connection not used connection_read(14): no connection! connection_read(14) error connection_read(14): no connection! The two lines I marked with asterisks are the output from the connection_input function, "op tag 0x42..." should be printed after "ber_get_next on fd 14 failed...", but it's not - so evidently this function is reentrant, the input loop is processing both the UNBIND request and the client closing the socket at the same time, and unfortunately the socket close processing came first so that connection_input thread tears down the connection. Now with the perl scripts I tried adding a microsecond sleep just after they unbind and before they exit, it worked - haven't seen any "no connection!" logs from them for hours. As for the libldap-client and ldapsearch commands, everytime I executed a simple 'ldapsearch -x -H ldapi:///' I'd get two "no connection!" log messages. I tried the same braindead usleep(1) solution and it worked. The following is the diff of what I changed to libldap, ldap_free_connection function in request.c: if ( unbind ) { ldap_send_unbind( ld, lc->lconn_sb, NULL, NULL ); + Debug( LDAP_DEBUG_TRACE, + "ldap_free_connection: sleeping after unbind\n", + 0, 0, 0 ); + usleep(1); } Here's the last bits of output from ldapsearch with -d3 after applying this brutal "fix" to libldap: ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 3 ldap_write: want=7, written=7 0000: 30 05 02 01 03 42 00 0....B. ldap_free_connection: sleeping after unbind ldap_free_connection: actually freed Notice the bytes getting flushed between unbind, my dumb sleep, and "actually freed". Without the sleep it seems slapd may process the close before the unbind. -- Gerald Turner Email: gturner(a)unzane.com JID: gturner(a)jabber.unzane.com GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5

1 0

Re: (ITS#5796) back-sql intermittently failing
by frederik.bosch＠gmail.com 07 Sep '10

07 Sep '10

http://www.openldap.org/lists/openldap-technical/201009/msg00070.html While googling for reconnect in the ODBC API I found this: http://dev.mysql.com/doc/refman/5.0/en/connector-odbc-configuration-connect… option 4194304: Enables auto-reconnection functionality. It seems like it fixes my problem.

1 0

Re: (ITS#6641) Syncrepl failure with 'overlay unique'
by andrew.findlay＠skills-1st.co.uk 07 Sep '10

07 Sep '10

On Tue, Sep 07, 2010 at 05:09:07AM -0700, Howard Chu wrote: >> We've talked about doing this isolation in the first refresh upon slapd >> startup. That might still be a good idea. It would certainly help to keep the apparent promises made by things like the uniqueness overlay. Alternatively you could take the view that the data will converge eventually and that is all that the LDAP standards promise. > But that reminds me of the joys of being a Sun sysadmin back in the 1980s, > when Sun's boot scripts always started their NFS client before starting > their NFS server. If two machines cross-mounted each other's filesystems > and both were booting at the same time they would hang, each waiting for > the other's NFS server to respond to their mount request. I remember that - one of the many reasons for switching to automounters (along with their own set of problems)... The alternative was 'soft' mounts, which may be a better model for solving the mirrormode problem. > Mirrormode and multimaster bootstrapping becomes a lot harder if you > implement this type of isolation during startup refresh. I was originally going to suggest that servers should not listen for connections until the first refresh completes, but that would indeed cause the deadlock you describe. How about having master servers listen on an extra port which is used purely for replication and *is* available immediately? The main LDAP port would thus remain closed until the server is synced-up, making it much easier for load-balancers to do the right thing. [This should really be a separate discussion as it is not directly related to the bug.] >> Doing it on every refresh seems far more problematic, because without some >> type of multi-version concurrency control, that means making the server >> non-responsive until the refresh completes. That may not be a problem with refresh-and-persist, as in normal circumstances I would expect updates to arrive at the consumer in the same order they hit the supplier (so this bug could not trigger). More difficult for scheduled refresh mode though. Could the consumer server simply write-lock every entry involved in the refresh while it processes the list, and then commit the whole lot in one DB transaction? Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#6641) Syncrepl failure with 'overlay unique'
by hyc＠symas.com 07 Sep '10

07 Sep '10

Howard Chu wrote: > andrew.findlay(a)skills-1st.co.uk wrote: >> Full_Name: Andrew Findlay >> Version: 2.4.23 >> OS: SLES 10.3 x86_64 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (88.97.25.132) >> >> >> The attribute uniqueness overlay can cause syncrepl to jam up. >> Consider this case: > >> The obvious answer is for syncrepl to bypass all data checks, as the supplier >> server should have already enforced them. The problem with that is that clients >> could see data that breaks the rules if they query while syncrepl is running >> (unless the refresh phase is handled as a single transaction and thus isolated >> from clients until it is complete). > > We've talked about doing this isolation in the first refresh upon slapd > startup. That might still be a good idea. But that reminds me of the joys of being a Sun sysadmin back in the 1980s, when Sun's boot scripts always started their NFS client before starting their NFS server. If two machines cross-mounted each other's filesystems and both were booting at the same time they would hang, each waiting for the other's NFS server to respond to their mount request. Mirrormode and multimaster bootstrapping becomes a lot harder if you implement this type of isolation during startup refresh. > Doing it on every refresh seems far more problematic, because without some > type of multi-version concurrency control, that means making the server > non-responsive until the refresh completes. -- -- 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#6641) Syncrepl failure with 'overlay unique'
by hyc＠symas.com 07 Sep '10

07 Sep '10

andrew.findlay(a)skills-1st.co.uk wrote: > Full_Name: Andrew Findlay > Version: 2.4.23 > OS: SLES 10.3 x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.97.25.132) > > > The attribute uniqueness overlay can cause syncrepl to jam up. > Consider this case: > The obvious answer is for syncrepl to bypass all data checks, as the supplier > server should have already enforced them. The problem with that is that clients > could see data that breaks the rules if they query while syncrepl is running > (unless the refresh phase is handled as a single transaction and thus isolated > from clients until it is complete). We've talked about doing this isolation in the first refresh upon slapd startup. That might still be a good idea. Doing it on every refresh seems far more problematic, because without some type of multi-version concurrency control, that means making the server non-responsive until the refresh completes. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6641) Syncrepl failure with 'overlay unique'
by andrew.findlay＠skills-1st.co.uk 07 Sep '10

07 Sep '10

Full_Name: Andrew Findlay Version: 2.4.23 OS: SLES 10.3 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.97.25.132) The attribute uniqueness overlay can cause syncrepl to jam up. Consider this case: 1) Configure a mirrormode pair with identical configs, including 'unique_attributes uid' 2) Start one server and add some data, including an entry containing a UID value. 3) Start the second server, let it synchronise, then stop it again. 4) On the first server, delete the entry and add a new one with a different DN that has the same UID value. 5) Start the second server. Look in the logs, and you will see something like this: Sep 7 11:33:03 jupiter slapd[19407]: @(#) $OpenLDAP: slapd 2.4.23 (Sep 6 2010 19:55:47) $ andrew@jupiter:/usr/local/src/openldap-2.4.23/servers/slapd Sep 7 11:33:03 jupiter slapd[19408]: slapd starting Sep 7 11:33:04 jupiter slapd[19408]: conn=1000 fd=23 ACCEPT from IP=127.0.0.1:33611 (IP=0.0.0.0:389) Sep 7 11:33:04 jupiter slapd[19408]: conn=1000 op=0 BIND dn="" method=128 Sep 7 11:33:04 jupiter slapd[19408]: conn=1000 op=0 RESULT tag=97 err=0 text= Sep 7 11:33:04 jupiter slapd[19408]: conn=1000 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Sep 7 11:33:04 jupiter slapd[19408]: conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Sep 7 11:33:04 jupiter slapd[19408]: conn=1000 op=2 UNBIND Sep 7 11:33:04 jupiter slapd[19408]: conn=1000 fd=23 closed Sep 7 11:33:04 jupiter slapd[19408]: null_callback : error code 0x13 Sep 7 11:33:04 jupiter slapd[19408]: syncrepl_entry: rid=001 be_add uniqueIdentifier=list.6b9432f9,dc=routing,dc=mail,dc=apps,dc=nis,dc=brunel,dc=ac,dc=uk failed (19) Sep 7 11:33:04 jupiter slapd[19408]: do_syncrepl: rid=001 rc 19 retrying (9 retries left) Sep 7 11:34:04 jupiter slapd[19408]: null_callback : error code 0x13 Sep 7 11:34:04 jupiter slapd[19408]: syncrepl_entry: rid=001 be_add uniqueIdentifier=list.6b9432f9,dc=routing,dc=mail,dc=apps,dc=nis,dc=brunel,dc=ac,dc=uk failed (19) Sep 7 11:34:04 jupiter slapd[19408]: do_syncrepl: rid=001 rc 19 retrying (9 retries left) Sep 7 11:35:05 jupiter slapd[19408]: null_callback : error code 0x13 Sep 7 11:35:05 jupiter slapd[19408]: syncrepl_entry: rid=001 be_add uniqueIdentifier=list.6b9432f9,dc=routing,dc=mail,dc=apps,dc=nis,dc=brunel,dc=ac,dc=uk failed (19) Sep 7 11:35:05 jupiter slapd[19408]: do_syncrepl: rid=001 rc 19 retrying (9 retries left) The problem is that syncrepl is trying to add the new entry before deleting the old one, and the uniqueness constraint on UID is preventing it from doing so. It is likely that other constraints on data will have the same effect. See for example this thread: http://www.openldap.org/lists/openldap-software/201001/msg00038.html The obvious answer is for syncrepl to bypass all data checks, as the supplier server should have already enforced them. The problem with that is that clients could see data that breaks the rules if they query while syncrepl is running (unless the refresh phase is handled as a single transaction and thus isolated from clients until it is complete). Andrew

1 0

(ITS#6640) pcache must always free callback
by masarati＠aero.polimi.it 06 Sep '10

06 Sep '10

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.165.221) Submitted by: ando pcache_op_cleanup should always free callback malloc'ed by pcache_op_search when done; caught with valgrind (need -DSLAP_NO_SL_MALLOC); see ITS#6629

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs