openldap-technical

openldap-technical@openldap.org

21 participants
9802 discussions

Openldap overloading
by Nick Milas 01 Oct '12

01 Oct '12

Hi, I am running a v2.4.31 consumer on CentOS 5.8 to serve user accounts (and aliases) on a Postfix mail server running locally. It has been running for a long time without problems. Today, after a user sent (on 14:53:39) a mass mail (through a group alias, implemented using ldap dynlist), Postfix stalled and the server (a VM under KVM) became overloaded. I noticed that openldap was using all the cpu: # top top - 15:30:01 up 81 days, 2:11, 1 user, load average: 113.58, 114.36, 104.02 Tasks: 460 total, 3 running, 457 sleeping, 0 stopped, 0 zombie Cpu(s): 98.9%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 1.1%hi, 0.0%si, 0.0%st Mem: 3089988k total, 3074912k used, 15076k free, 12180k buffers Swap: 2064376k total, 92k used, 2064284k free, 1909976k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2209 ldap 18 0 577m 17m 8952 S 93.4 0.6 55:03.67 slapd ... I had to stop and restart openldap manually, and after that I only found in the log (nothing has been logged earlier): Sep 28 15:00:07 mail slapd[2209]: connection_input: conn=14847 deferring operation: too many executing Sep 28 15:00:38 mail slapd[2209]: connection_input: conn=19285 deferring operation: too many executing Sep 28 15:32:46 mail slapd[2209]: connection_input: conn=19419 deferring operation: binding Sep 28 15:32:47 mail slapd[2209]: connection_input: conn=19419 deferring operation: binding Sep 28 15:32:57 mail slapd[4484]: [INFO] Using /etc/default/slapd for configuration Sep 28 15:32:57 mail slapd[4489]: [INFO] Halting OpenLDAP... Sep 28 15:32:57 mail slapd[2209]: daemon: shutdown requested and initiated. Sep 28 15:32:57 mail slapd[2209]: slapd shutdown: waiting for 1 operations/tasks to finish Sep 28 15:33:03 mail slapd[2209]: slapd stopped. Sep 28 15:33:05 mail slapd[4510]: [OK] OpenLDAP stopped after 7 seconds Sep 28 15:33:05 mail slapd[4511]: [INFO] No data backup done Sep 28 15:33:12 mail slapd[4529]: [INFO] Using /etc/default/slapd for configuration Sep 28 15:33:12 mail slapd[4534]: [INFO] Launching OpenLDAP configuration test... Sep 28 15:33:16 mail slapd[4568]: [OK] OpenLDAP configuration test successful Sep 28 15:33:16 mail slapd[4578]: [INFO] No db_recover done Sep 28 15:33:16 mail slapd[4579]: [INFO] Launching OpenLDAP... Sep 28 15:33:16 mail slapd[4580]: [OK] File descriptor limit set to 1024 Sep 28 15:33:17 mail slapd[4581]: @(#) $OpenLDAP: slapd 2.4.31 (Apr 26 2012 19:53:11) $ clement@localhost.localdomain:/home/clement/build/BUILD/openldap-2.4.31/servers/slapd ... Possibly, a number of parallel group alias uses, caused a large number of LDAP queries by Postfix. Can you please advise on what may have caused OpenLDAP overloading, and on how can we avoid it from happening again? Any config changes? My config follows. Thanks in advance for your time and assistance. Regards, Nick # cat /usr/local/openldap/var/openldap-data/DB_CONFIG #==================================================================== # BDB configuration # # Provided by LTB-project (http://www.ltb-project.org) #==================================================================== #==================================================================== # Cache size for DB files #==================================================================== set_cachesize 1 0 1 #==================================================================== # Flags #==================================================================== #set_flags DB_TXN_WRITE_NOSYNC #set_flags DB_TXN_NOSYNC set_flags DB_LOG_AUTOREMOVE #==================================================================== # Logs #==================================================================== # Size set_lg_regionmax 1048576 set_lg_max 10485760 set_lg_bsize 2097152 # Directory set_lg_dir /usr/local/berkeleydb/openldap-logs ************************************************************************ # cat /usr/local/openldap/etc/openldap/slapd.conf # include /usr/local/openldap/etc/openldap/schema/core.schema include /usr/local/openldap/etc/openldap/schema/cosine.schema include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema include /usr/local/openldap/etc/openldap/schema/nis.schema include /usr/local/openldap/etc/openldap/schema/eduperson.schema include /usr/local/openldap/etc/openldap/schema/postfix.schema include /usr/local/openldap/etc/openldap/schema/dyngroup.schema include /usr/local/openldap/etc/openldap/schema/misc.schema include /usr/local/openldap/etc/openldap/schema/ppolicy.schema include /usr/local/openldap/etc/openldap/schema/schac-20090326-1.4.0.schema include /usr/local/openldap/etc/openldap/schema/dnsdomain2.schema include /usr/local/openldap/etc/openldap/schema/proftpd-quota.schema include /usr/local/openldap/etc/openldap/schema/kerberos.schema include /usr/local/openldap/etc/openldap/schema/localemail.schema include /usr/local/openldap/etc/openldap/schema/entryaccess.schema pidfile /usr/local/openldap/var/run/slapd.pid argsfile /usr/local/openldap/var/run/slapd.args modulepath /usr/local/openldap/lib64 loglevel sync sizelimit unlimited timelimit unlimited TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCACertificateFile /usr/local/openldap/etc/openldap/cacerts/chain.pem TLSCertificateFile /usr/local/openldap/etc/openldap/cacerts/cert.pem TLSCertificateKeyFile /usr/local/openldap/etc/openldap/cacerts/key.pem TLSVerifyClient never ####################################################################### # ldbm and/or bdb database definitions ####################################################################### database hdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw secret ######## # ACLs # ######## include /usr/local/openldap/etc/openldap/acl.conf directory /usr/local/openldap/var/openldap-data index objectClass eq,pres index employeeType pres,eq index cn eq,pres,sub index sn,givenname eq,pres,sub index mail eq,pres,sub index uid eq,pres index ou eq,pres index mailacceptinggeneralid eq,pres index owner eq index entryCSN,entryUUID eq index vacationActive eq index associatedDomain pres,eq,sub index dc eq index emailLocalAddress eq,pres,sub overlay dynlist dynlist-attrset nisMailAlias labeledURI dynlist-attrset groupOfURLs labeledURI member syncrepl rid=111 provider=ldaps://ldap.example.com tls_reqcert=never type=refreshAndPersist retry="60 15 180 +" searchbase="dc=example,dc=com" schemachecking=off bindmethod=simple binddn="uid=FullReplAcc1,ou=System,dc=example,dc=com" credentials="mypassword" database monitor access to * by dn.exact="cn=Manager,dc=example,dc=com" read by * none ********************************************************************* # ls -la /usr/local/openldap/var/openldap-data/ total 14120 drwxr-xr-x 2 ldap ldap 4096 Sep 28 15:33 . drwxr-xr-x 4 ldap ldap 4096 Apr 26 20:56 .. -rw-r--r-- 1 ldap ldap 4096 Sep 28 15:33 alock -rw------- 1 ldap ldap 1261568 Sep 28 15:32 associatedDomain.bdb -rw------- 1 ldap ldap 512000 Sep 28 15:32 cn.bdb -rw------- 1 ldap ldap 24576 Sep 28 15:33 __db.001 -rw------- 1 ldap ldap 1294336 Sep 28 16:12 __db.002 -rw------- 1 ldap ldap 32776192 Sep 28 16:12 __db.003 -rw------- 1 ldap ldap 3145728 Sep 28 16:11 __db.004 -rw------- 1 ldap ldap 729088 Sep 28 16:12 __db.005 -rw------- 1 ldap ldap 32768 Sep 28 16:11 __db.006 -rw-r--r-- 1 ldap ldap 924 Apr 26 21:01 DB_CONFIG -rw------- 1 ldap ldap 845 Apr 26 20:56 DB_CONFIG.example -rw------- 1 ldap ldap 61440 Sep 28 15:32 dc.bdb -rw------- 1 ldap ldap 339968 Sep 28 15:33 dn2id.bdb -rw------- 1 ldap ldap 212992 Sep 28 15:33 emailLocalAddress.bdb -rw------- 1 ldap ldap 20480 Sep 28 15:33 employeeType.bdb -rw------- 1 ldap ldap 118784 Sep 28 15:33 entryCSN.bdb -rw------- 1 ldap ldap 81920 Sep 28 15:33 entryUUID.bdb -rw------- 1 ldap ldap 90112 Sep 28 15:32 givenName.bdb -rw------- 1 ldap ldap 2457600 Sep 28 15:33 id2entry.bdb -rw------- 1 ldap ldap 24576 Jul 9 13:13 mailacceptinggeneralid.bdb -rw------- 1 ldap ldap 212992 Sep 28 15:33 mail.bdb -rw------- 1 ldap ldap 266240 Sep 28 15:33 objectClass.bdb -rw------- 1 ldap ldap 40960 Sep 28 15:33 ou.bdb -rw------- 1 ldap ldap 8192 Sep 28 15:32 owner.bdb -rw------- 1 ldap ldap 253952 Sep 28 15:32 sn.bdb -rw------- 1 ldap ldap 28672 Sep 28 15:33 uid.bdb -rw------- 1 ldap ldap 8192 Sep 25 2011 vacationActive.bdb ***************************************************************************

5 11

ldap_add_ext transactions
by Sajid 01 Oct '12

01 Oct '12

hi, i'm trying to do an ldap_add operation using openldap client lib against ActiveDirectory on MAC I want to be able to roll back this add operation so I'm using transactions like this int rc = ldap_add_ext_s(ld, [userDN cStringUsingEncoding: NSUTF8StringEncoding], mods, hcdTC_new, NULL ); hcdTransactionId.ldctl_value.bv_val = (hcdTC_new[0])->ldctl_value.bv_val ; hcdTransactionId.ldctl_value.bv_len = (hcdTC_new[0])->ldctl_value.bv_len ; when I try to rollback rc = ldap_add_ext_s(ld, [userDN cStringUsingEncoding: NSUTF8StringEncoding], mods, hcdTC_rollback, NULL );; it says user already exists which means it created the user without my having to commit the transaction, how can I rollback and ldap add operation here are the definitions of variables static LDAPControl hcdTransactionControl_new = { "1.3.18.0.2.10.3", /* -- hcdTransactionControl -- */ { 3, "\x4E\x45\x57\x00" }, /* -- NEW ------------- */ '\0' /* -- critical --------------- */ } ; static LDAPControl *hcdTC_new[2] = { &hcdTransactionControl_new, NULL }; static LDAPControl hcdTransactionId = { "1.3.18.0.2.10.4", /* -- hcdTransactionId ------ */ { 1, "\x31\x00" }, /* -- TXN Id ---------------- */ '\0' /* -- critical -------------- */ }; static LDAPControl *hcdTC_Id[2] = { &hcdTransactionId, NULL }; static LDAPControl hcdTransactionControl_commit = { "1.3.18.0.2.10.3", /* -- hcdTransactionControl -- */ { 6, "\x43\x4F\x4D\x4D\x49\x54\x00" },/* - COMMIT -- */ '\0' /* -- critical --------------- */ }; static LDAPControl *hcdTC_commit[3] = { &hcdTransactionControl_commit, & hcdTransactionId, NULL }; static LDAPControl hcdTransaction_rollback = { "1.3.18.0.2.10.3", /* -- hcdTransactionControl -- */ { 8, "\x52\x4F\x4C\x4C\x42\x41\x43\x4B\x00" }, /*ROLLBACK*/ '\0' /* -- critical --------------- */ }; static LDAPControl *hcdTC_rollback[3] = { &hcdTransaction_rollback, & hcdTransactionId, NULL };

1 0

Re: slapd ACLs - [SOLVED]
by Mik J 01 Oct '12

01 Oct '12

Olivier, Thank you for your suggestion, it really helped. The problem is now solved. My configuration looks like this now defaultsearchbase dc=mydomain,dc=org sortvals member memberUid roleOccupant access to attrs=userpassword,shadowMax,shadowExpire,sambaLMPassword,sambaNTPassword,sambaPwdLastSet by dn.regex="uid=myadmin,ou=people,dc=mydomain,dc=org" write by self write by anonymous auth by * none access to * by dn.regex="uid=admin,ou=people,dc=mydomain,dc=org" =wrscx by self write by users read by anonymous auth by * none I have made some tests and so far it seems good. Myadmin is able to see everyone's password, a user can see his passwords but not other's people. Non authenticated users cannot do anything. I have noticed that I cannot add a comment line in the middle of an ACL and slapd won't start access to * by dn.regex="uid=admin,ou=people,dc=mydomain,dc=org" =wrscx # by self write by users read But my version 2.4.26 is not the latest so this feature my have been implemented already. ----- Mail original ----- > De : Olivier Guillard <olivier(a)guillard.nom.fr> > À : Mik J <mikydevel(a)yahoo.fr> > Cc : > Envoyé le : Dimanche 30 septembre 2012 22h23 > Objet : Re: slapd ACLs > > Could you activate ACL debug level ? > > since I'm not very familiar with "dn.regex", you might need help > from > someone else anyway. > > --- > Olivier > > 2012/9/30 Mik J <mikydevel(a)yahoo.fr>: >> Thank you for your answer Olivier, I tried to do this but it didn't > work. The logs look like this >> >> conn=1001 op=0 BIND dn="user2,ou=people,dc=mydomain,dc=org" > method=128 >> conn=1001 op=0 BIND dn="user2,ou=people,dc=mydomain,dc=org" > mech=SIMPLE ssf=0 >> conn=1001 op=0 RESULT tag=97 err=0 text= >> conn=1001 op=1 SRCH base="user1,ou=people,dc=mydomain,dc=org" > scope=2 deref=0 filter="(objectClass=*)" >> conn=1001 op=1 SEARCH RESULT tag=101 err=32 nentries=0 text= >> conn=1001 op=2 UNBIND >> >> I triple checked, and when it works, with the dn.subtree permission in the > begining of slapd.conf I have >> conn=1000 op=0 BIND dn="user2,ou=people,dc=mydomain,dc=org" > method=128 >> conn=1000 op=0 BIND dn="user2,ou=people,dc=mydomain,dc=org" > mech=SIMPLE ssf=0 >> conn=1000 op=0 RESULT tag=97 err=0 text= >> conn=1000 op=1 SRCH base="user1,ou=people,dc=mydomain,dc=org" > scope=2 deref=0 filter="(objectClass=*)" >> conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= >> conn=1000 op=2 UNBIND >> >> >> >> >> ----- Mail original ----- >>> De : Olivier <ldap(a)guillard.nom.fr> >>> À : Mik J <mikydevel(a)yahoo.fr> >>> Cc : >>> Envoyé le : Dimanche 30 septembre 2012 20h29 >>> Objet : Re: slapd ACLs >>> >>> T ry to put this rule : >>> >>>> access to dn.subtree="" >>>> by * read >>> >>> after the two others. >>> >>> (ionce a rule matches, then the scan stops : order counts) >>> >>> -- >>> Olivier >>> >>> 2012/9/30 Mik J <mikydevel(a)yahoo.fr>: >>>> Hello, >>>> >>>> I'm a bit confused with the ACLs in my slapd.conf considering > I have >>> this >>>> >>>> access to dn.subtree="" >>>> by * read >>>> >>>> access to >>> > attrs=userPassword,shadowMax,shadowExpire,sambaLMPassword,sambaNTPassword >>>> by > dn.regex="uid=[^/]+/admin\+(realm=MYDOMAIN.ORG)?" >>> write >>>> by dn="uid=admin,ou=people,dc=mydomain,dc=org" > write >>>> by self write >>>> by anonymous auth >>>> by * none >>>> >>>> access to * >>>> by > dn.regex="uid=[^/]+/admin\+(realm=MYDOMAIN.ORG)?" >>> =wrscx >>>> by self write >>>> by users read >>>> by anonymous auth >>>> by * none >>>> >>>> >>>> When I do a ldapsearch without authentication, I can see the > user's >>> details including the unencrypted password >>>> >>>> ldapsearch -x -b > "uid=user1,ou=people,dc=mydomain,dc=org" >>>> I think that it's because the rule access to > dn.subtree="" by >>> * read >>>> With an authenticated user is works as well >>>> >>>> ldapsearch -x -D uid=user2,ou=people,dc=mydomain,dc=org -b >>> "uid=user1,ou=people,dc=mydomain,dc=org" -W >>>> >>>> But if I comment these two lines >>>> #access to dn.subtree="" >>>> # by * read >>>> The search doesn't give me any result >>>> >>>> ldapsearch -x -D uid=user2,ou=people,dc=mydomain,dc=org -b >>> "uid=user1,ou=people,dc=mydomain,dc=org" -W >>>> # search result >>>> search: 2 >>>> result: 32 No such object >>>> # numResponses: 1 >>>> >>>> I would have expected that this command matched >>>> access to * >>>> by users read >>>> >>>> My goal is that only authenticated user would be able to access > the ldap >>> directory and users can change their passwords >>>> >>>> Does anyone has an idea on how to explain this behavior. ? >>>> >>>> Thank you >>>> >>> >> >

1 0

Re: slapd ACLs
by Mik J 30 Sep '12

30 Sep '12

Thank you for your answer Olivier, I tried to do this but it didn't work. The logs look like this conn=1001 op=0 BIND dn="user2,ou=people,dc=mydomain,dc=org" method=128 conn=1001 op=0 BIND dn="user2,ou=people,dc=mydomain,dc=org" mech=SIMPLE ssf=0 conn=1001 op=0 RESULT tag=97 err=0 text= conn=1001 op=1 SRCH base="user1,ou=people,dc=mydomain,dc=org" scope=2 deref=0 filter="(objectClass=*)" conn=1001 op=1 SEARCH RESULT tag=101 err=32 nentries=0 text= conn=1001 op=2 UNBIND I triple checked, and when it works, with the dn.subtree permission in the begining of slapd.conf I have conn=1000 op=0 BIND dn="user2,ou=people,dc=mydomain,dc=org" method=128 conn=1000 op=0 BIND dn="user2,ou=people,dc=mydomain,dc=org" mech=SIMPLE ssf=0 conn=1000 op=0 RESULT tag=97 err=0 text= conn=1000 op=1 SRCH base="user1,ou=people,dc=mydomain,dc=org" scope=2 deref=0 filter="(objectClass=*)" conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=1000 op=2 UNBIND ----- Mail original ----- > De : Olivier <ldap(a)guillard.nom.fr> > À : Mik J <mikydevel(a)yahoo.fr> > Cc : > Envoyé le : Dimanche 30 septembre 2012 20h29 > Objet : Re: slapd ACLs > >T ry to put this rule : > >> access to dn.subtree="" >> by * read > > after the two others. > > (ionce a rule matches, then the scan stops : order counts) > > -- > Olivier > > 2012/9/30 Mik J <mikydevel(a)yahoo.fr>: >> Hello, >> >> I'm a bit confused with the ACLs in my slapd.conf considering I have > this >> >> access to dn.subtree="" >> by * read >> >> access to > attrs=userPassword,shadowMax,shadowExpire,sambaLMPassword,sambaNTPassword >> by dn.regex="uid=[^/]+/admin\+(realm=MYDOMAIN.ORG)?" > write >> by dn="uid=admin,ou=people,dc=mydomain,dc=org" write >> by self write >> by anonymous auth >> by * none >> >> access to * >> by dn.regex="uid=[^/]+/admin\+(realm=MYDOMAIN.ORG)?" > =wrscx >> by self write >> by users read >> by anonymous auth >> by * none >> >> >> When I do a ldapsearch without authentication, I can see the user's > details including the unencrypted password >> >> ldapsearch -x -b "uid=user1,ou=people,dc=mydomain,dc=org" >> I think that it's because the rule access to dn.subtree="" by > * read >> With an authenticated user is works as well >> >> ldapsearch -x -D uid=user2,ou=people,dc=mydomain,dc=org -b > "uid=user1,ou=people,dc=mydomain,dc=org" -W >> >> But if I comment these two lines >> #access to dn.subtree="" >> # by * read >> The search doesn't give me any result >> >> ldapsearch -x -D uid=user2,ou=people,dc=mydomain,dc=org -b > "uid=user1,ou=people,dc=mydomain,dc=org" -W >> # search result >> search: 2 >> result: 32 No such object >> # numResponses: 1 >> >> I would have expected that this command matched >> access to * >> by users read >> >> My goal is that only authenticated user would be able to access the ldap > directory and users can change their passwords >> >> Does anyone has an idea on how to explain this behavior. ? >> >> Thank you >> >

1 0

slapd ACLs
by Mik J 30 Sep '12

30 Sep '12

Hello, I'm a bit confused with the ACLs in my slapd.conf considering I have this access to dn.subtree="" by * read access to attrs=userPassword,shadowMax,shadowExpire,sambaLMPassword,sambaNTPassword by dn.regex="uid=[^/]+/admin\+(realm=MYDOMAIN.ORG)?" write by dn="uid=admin,ou=people,dc=mydomain,dc=org" write by self write by anonymous auth by * none access to * by dn.regex="uid=[^/]+/admin\+(realm=MYDOMAIN.ORG)?" =wrscx by self write by users read by anonymous auth by * none When I do a ldapsearch without authentication, I can see the user's details including the unencrypted password ldapsearch -x -b "uid=user1,ou=people,dc=mydomain,dc=org" I think that it's because the rule access to dn.subtree="" by * read With an authenticated user is works as well ldapsearch -x -D uid=user2,ou=people,dc=mydomain,dc=org -b "uid=user1,ou=people,dc=mydomain,dc=org" -W But if I comment these two lines #access to dn.subtree="" # by * read The search doesn't give me any result ldapsearch -x -D uid=user2,ou=people,dc=mydomain,dc=org -b "uid=user1,ou=people,dc=mydomain,dc=org" -W # search result search: 2 result: 32 No such object # numResponses: 1 I would have expected that this command matched access to * by users read My goal is that only authenticated user would be able to access the ldap directory and users can change their passwords Does anyone has an idea on how to explain this behavior. ? Thank you

1 0

LDAP search filter on superior/parent attribute
by Roman Rybalko 30 Sep '12

30 Sep '12

Have a schema: olcAttributeTypes: ( 2.999.777.1.1.1.3 NAME 'orderingInteger' DESC 'Integer with ordering' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) olcAttributeTypes: ( 2.999.777.1.1.2.16 NAME 'timeInteger' DESC 'Integer time representation' SUP orderingInteger ) olcAttributeTypes: ( 2.999.777.1.1.2.17 NAME 'Mailbox' DESC 'Mailbox name' SUP info ) olcAttributeTypes: ( 2.999.777.1.1.2.16.1 NAME 'timeIntegerYear' DESC 'Integer year representation' SUP timeInteger ) olcAttributeTypes: ( 2.999.777.1.1.2.16.2 NAME 'timeIntegerMonth' DESC 'Integer month representation' SUP timeInteger ) olcAttributeTypes: ( 2.999.777.1.1.2.16.3 NAME 'timeIntegerDay' DESC 'Integer day of the month representation' SUP timeInteger ) olcAttributeTypes: ( 2.999.777.1.1.2.16.4 NAME 'timeIntegerHour' DESC 'Integer hour representation' SUP timeInteger ) olcAttributeTypes: ( 2.999.777.1.1.2.16.5 NAME 'timeIntegerMinute' DESC 'Integer minute representation' SUP timeInteger ) olcObjectClasses: ( 2.999.777.1.2.3 NAME 'entry' SUP top STRUCTURAL MAY ( timeInteger $ timeIntegerYear $ timeIntegerMonth $ timeIntegerDay $ timeIntegerHour $ timeIntegerMinute ) ) Have a search: (&(timeInteger>=1348900000)(timeInteger<=1349000000)) This search may return entries like: timeInteger: 1347014897 timeIntegerYear: 2012 timeIntegerMonth: 9 ... The entry with timeInteger=1347014897 is obviously not in [1348900000,1349000000] range, but it is matched because there are another attributes in the entry with "SUP timeInteger", so timeIntegerYear=2012 is matched the (timeInteger<=1349000000) filter part. I'm looking for RFC that describes such behavior. -- WBR, Roman Rybalko

3 2

Appropriate index for <= >= filter on generalizedTime (Re: reqStart<= slow)
by Roman Rybalko 30 Sep '12

30 Sep '12

Hi, I'm trying to use >= <= filter on eq-indexed generalizedTime attribute. Seems eq-index does not work for <= filter. olcAttributeTypes: ( 2.999.777.1.1.1.5 NAME 'logTime' DESC 'Time' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) olcDbIndex: logTime eq (&(logTime>=201209201440+0400)(logTime<=201209201450+0400)) - 57sec (|(logTime=20120920144001+0400)(logTime=20120920144008+0400)) - 0.03sec ~ 1000000 records in db, target = 100000000 records What should I do to make >= filters work efficiently? I may consider using another data type that work with <=/=> filters for sure. Strings? Integers? Anything that can mimic TIME semantics. Any advice? 14.04.2012 19:44, Michael Ströder пишет: > can I influence the order of index usage by order in the filter or slapd index configuration? The same question from me. Is it possible to select indexes using some sort of filter syntax? -- WBR, Roman Rybalko

2 11

mdb_idl_fetch_key: cursor failed: Invalid argument (22)
by Roman Rybalko 30 Sep '12

30 Sep '12

I have such error in logs: null_callback : error code 0x50 syncrepl_entry: rid=001 be_add logID=502,logID=402,logHost=mail.xxx.xxx.xx,logName=main,cn=test failed (80) do_syncrepl: rid=001 rc 80 retrying (2 retries left) and then every 2-3 minutes: => mdb_idl_fetch_key: cursor failed: Invalid argument (22) MDB is running on replication consumer. I shutted down the replication provider for reindexing. The consumer was not fully synced at that time. Than I changed olcDbMaxSize on the replication consumer. Than I started the provider again. Seems the error happened first time right after olcDbMaxSize was increased from 5G to 8G. I've never changed it before. Sep 30 16:07:01 lintest slapd[518]: conn=1089 op=1 MOD dn="olcDatabase={1}mdb,cn=config" Sep 30 16:07:01 lintest slapd[518]: conn=1089 op=1 MOD attr=olcDbMaxSize Sep 30 16:07:03 lintest slapd[518]: conn=1089 op=1 RESULT tag=103 err=0 text= Sep 30 16:07:03 lintest slapd[518]: conn=1089 op=2 UNBIND Sep 30 16:07:03 lintest slapd[518]: conn=1089 fd=12 closed Sep 30 16:07:03 lintest slapd[518]: => mdb_idl_fetch_key: cursor failed: Invalid argument (22) slapd version git a1c2dc6 db size 3.7Gb What this error is about? Is it serious? Should I recreate the DB on the consumer? Seems replication is stalled. -- WBR, Roman Rybalko

1 0

LDAP and MD5 authentication issues.
by S K 30 Sep '12

30 Sep '12

Hi, I am newbie to LDAP and I am having a issue. I have to work with MD5 authentication as the application we are going to use has to bind to a LDAP server with password generated using MD5. I am not able to authenticate with password generate using the perl script or using the md5 executable. But if I generate the passwords using slappassword and MD5 I am fine. Can somebody please explain what I am doing wrong and how I can authenticate using perl or md5 exe generated password. Any help is greatly appreciated. Passwords generated using this perl script. for example. MD5 for hello perl -e 'use Digest::MD5 qw(md5_hex);print uc(md5_hex("hello"))."\n";' 5D41402ABC4B2A76B9719D911017C592 Using slappasswd ./slappasswd -h \{MD5\} -s hello {MD5}XUFAKrxLKna5cZ2REBfFkg== My LDIF file user MD5A assigned perl or md5 exe generated MD5 password and user MD5B assigned slappasswd generated MD5 password. dn: cn=MD5A, ou=hr, o=test objectClass: top objectClass: person objectClass: organizationalPerson cn: MD5A sn: MD5A userpassword: {MD5}5D41402ABC4B2A76B9719D911017C592 title: admin dn: cn=MD5B, ou=hr, o=test objectClass: top objectClass: person objectClass: organizationalPerson cn: MD5B sn: MD5B userpassword: {MD5}XUFAKrxLKna5cZ2REBfFkg== title: admin Import LDIF: # /usr/local/bin/ldapadd -x -W -D "cn=admin" -f users.ldif Enter LDAP Password: adding new entry "o=test" adding new entry "ou=hr,o=test" adding new entry "cn=MD5A, ou=hr, o=test" adding new entry "cn=MD5B, ou=hr, o=test" ldapsearch fails for MD5A with error 49 and for MD5B it works fine. # /usr/local/bin/ldapsearch -x -w hello -D "cn=MD5A, ou=hr, o=test" ldap_bind: Invalid credentials (49) # /usr/local/bin/ldapsearch -x -w hello -D "cn=MD5B, ou=hr, o=test" # extended LDIF # # LDAPv3 # base <> (default) with scope subtree # filter: (objectclass=*) # requesting: ALL # # test dn: o=test objectClass: top objectClass: organization o: test # hr, test dn: ou=hr,o=test objectClass: top objectClass: organizationalUnit ou: asqmatrix ou: hr # MD5A, hr, test dn: cn=MD5A,ou=hr,o=test objectClass: top objectClass: person objectClass: organizationalPerson cn: MD5A sn: MD5A userPassword:: e01ENX01RDQxNDAyQUJDNEIyQTc2Qjk3MTlEOTExMDE3QzU5Mg== title: admin # MD5B, hr, test dn: cn=MD5B,ou=hr,o=test objectClass: top objectClass: person objectClass: organizationalPerson cn: MD5B sn: MD5B userPassword:: e01ENX1YVUZBS3J4TEtuYTVjWjJSRUJmRmtnPT0= title: admin # search result search: 2 result: 0 Success # numResponses: 5 # numEntries: 4 Thanks, SK

2 1

Re: ldapsearch stalling when performing searches with a large number of results
by Mark Cairney 28 Sep '12

28 Sep '12

My olcDB values are listed below (minus the olcDbConfig entries). I'm not sure if you need the indexes but I've left them in anyway: olcDbDirectory: /usr/local/authz/var/openldap-data/authorise olcAddContentAcl: FALSE olcDbCacheFree: 1 olcDbCacheSize: 400000 olcDbCheckpoint: 10240 10 olcDbDirtyRead: FALSE olcDbDNcacheSize: 0 olcDbIDLcacheSize: 1200000 olcDbIndex: autoMountKey eq olcDbIndex: cn pres,eq,sub olcDbIndex: eduniCategory eq olcDbIndex: eduniCollegeCode eq olcDbIndex: eduniIdmsId pres,eq olcDbIndex: eduniIDStatus eq olcDbIndex: eduniLibraryBarcode pres,eq olcDbIndex: eduniOrganisation pres,eq,sub olcDbIndex: eduniOrgCode eq olcDbIndex: eduniSchoolCode eq olcDbIndex: eduniServiceCode pres,eq olcDbIndex: eduniType eq olcDbIndex: eduniUnitCode eq olcDbIndex: eduPersonAffiliation pres,eq olcDbIndex: eduPersonEntitlement pres,eq olcDbIndex: eduPersonPrimaryAffiliation eq olcDbIndex: eduPersonPrincipalName eq olcDbIndex: eduPersonScopedAffiliation pres,eq olcDbIndex: eduPersonTargetedID eq olcDbIndex: entryCSN eq olcDbIndex: entryUUID eq olcDbIndex: gecos pres,eq,sub olcDbIndex: gidNumber pres,eq olcDbIndex: krbName pres,eq olcDbIndex: mail pres,eq,sub olcDbIndex: memberOf pres,eq olcDbIndex: memberUid eq olcDbIndex: objectClass eq olcDbIndex: sn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbIndex: uidNumber pres,eq olcDbIndex: uniqueMember pres,eq olcDbIndex: userPassword eq olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbNoSync: FALSE olcDbSearchStack: 16 olcDbShmKey: 0 and my DB_CONFIG file contains: set_cachesize 4 0 1 set_flags DB_LOG_AUTOREMOVE set_lk_max_objects 5000 set_lk_max_lockers 5000 set_lg_regionmax 41943040 set_lg_dir /usr/local/authz/slapd/trans-logs set_lk_max_locks 10000 set_lg_bsize 20971520 set_lg_max 83886080 I'm not using an SHM key (should I be?). The search that I spotted this behaviour probably means nothing outside our environment as it's against a value in our local schema but for completeness it was: (&(eduniCategory=201)(objectclass=inetorgperson)) I've seen the same behaviour with similar searches which we would expect to return a large number of results e.g. (&(eduPersonAffiliation=student)(objectclass=inetorgperson)) or indeed against groups with a lot of members. > > You may wish to read over <https://wiki.zimbra.com/wiki/OpenLDAP_Performance_Tuning>. You can easily map the information there to a non-zimbra installation. Thanks- your documentation on the DB tuning and SHM key is excellent. I can see a couple of things which I might change based on it but I'll wait to hear back before I jump in and start playing around with parameters. > > --Quanah > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > /**************************** Mark R Cairney ITI UNIX Section Information Services Tel: 0131 650 6565 Email: Mark.Cairney(a)ed.ac.uk ****************************/ -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

3 7

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical