openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

(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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs