openldap-technical

openldap-technical@openldap.org

21 participants
9802 discussions

Issue with delta-sync multimaster
by Al 26 Apr '13

26 Apr '13

Hi All, I just recently migrated to a new OpenLDAP environment, and am experiencing an occasional issue. I am using 2.4.35 and Redhat 6 - x64 with OpenLDAP compiled and packaged locally. I have setup multimaster using delta-sync with MDB being utilized for both the user data as well as the access log. This environment is fronted by a load balancer, so traffic is directed to a single server. A couple of times an hour, I get the following error in the log on the second server: -------------------- Apr 25 13:52:19 server2 slapd[15648]: null_callback : error code 0x10 Apr 25 13:52:19 server2 slapd[15648]: syncrepl_message_to_op: rid=011 be_modify cn=USER123,cn=users,cn=domain,cn=com (16) -------------------- After this error, the second server goes into refresh mode and gets a fresh copy. It would appear that this error relates to the ppolicy overlay as the entries in the access log at the time of error shows the pwdFailureTime being removed during a password reset. I do see the pwdFailureTime being set in the access log earlier too, so the data should be there (even though the error code indicates no such attribute). I was luckily able to catch a bunch of debug logging while the issue occured. I have attempted to strip out some useful information, but I have a very large file with more data in it if neccessary. -------------------- 517967bc mdb_modify_internal: 0x000197ed: cn=USER123,cn=users,cn=domain,cn=com 517967bc <= acl_access_allowed: granted to database root 517967bc mdb_modify_internal: replace userPassword 517967bc mdb_modify_internal: replace pwdChangedTime 517967bc mdb_modify_internal: softdel pwdFailureTime 517967bc mdb_modify_internal: replace entryCSN 517967bc mdb_modify_internal: replace modifiersName 517967bc mdb_modify_internal: replace modifyTimestamp 517967bc mdb_modify_internal: delete pwdFailureTime 517967bc mdb_modify_internal: 16 modify/delete: pwdFailureTime: no such attribute 517967bc mdb_modify: modify failed (16) 517967bc send_ldap_result: conn=-1 op=0 p=3 517967bc send_ldap_result: err=16 matched="" text="modify/delete: pwdFailureTime: no such attribute" 517967bc null_callback : error code 0x10 517967bc slap_graduate_commit_csn: removing 0x7fc7ec1bc300 20130425172817.060117Z#000000#001#000000 517967bc syncrepl_message_to_op: rid=011 be_modify cn=USER123,cn=users,cn=domain,cn=com (16) ... 517967bc do_syncrep2: rid=011 delta-sync lost sync on (reqStart=20130425172817.000023Z,cn=accesslog), switching to REFRESH -------------------- Here is the important parts of my config - the configs are mirrored - so its the same on all: -------------------- dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /u01/openldap/live2/var/openldap-data olcSuffix: cn=domain,cn=com olcAddContentAcl: FALSE olcLastMod: TRUE olcLimits: {0}dn.base="cn=ldapreplicator,cn=systems,cn=domain,cn=com " size.soft=unlimited size.hard=unlimited time.soft=unlimited time.hard=un limited olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=Manager,cn=domain,cn=com olcRootPW:: NONONO olcSyncUseSubentry: FALSE olcMirrorMode: TRUE olcMonitoring: TRUE olcDbCheckpoint: 512 5 olcDbNoSync: TRUE olcDbIndex: objectClass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcDbIndex: cn pres,eq,sub olcDbIndex: uid eq olcDbIndex: uidNumber eq olcDbIndex: gidNumber eq olcDbIndex: uniqueMember eq olcDbIndex: nisNetgroupTriple eq olcDbIndex: sudoUser eq,sub olcDbMaxSize: 25000000000 olcDbMode: 0600 structuralObjectClass: olcMdbConfig entryUUID: a12ed549-25c6-4424-8c4f-fe63eed54ba2 creatorsName: cn=config createTimestamp: 20111014131247Z olcSyncrepl: {0}rid=011 provider=ldap://server1.company.com:21389/ bind method=simple timeout=1 network-timeout=1 binddn="cn=ldapreplicator,cn=system s,cn=domain,cn=com" credentials="NONONONO" keepalive=0:0:0 startt ls=critical filter="(objectclass=*)" searchbase="cn=domain,cn=com" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" logbase="cn=access log" scope=sub schemachecking=off type=refreshAndPersist interval=00:00:00:05 retry="30 +" syncdata=accesslog olcSyncrepl: {1}rid=012 provider=ldap://server2.company.com:21389/ bind method=simple timeout=1 network-timeout=1 binddn="cn=ldapreplicator,cn=system s,cn=domain,cn=com" credentials="NONONO" keepalive=0:0:0 startt ls=critical filter="(objectclass=*)" searchbase="cn=domain,cn=com" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" logbase="cn=access log" scope=sub schemachecking=off type=refreshAndPersist interval=00:00:00:05 retry="30 +" syncdata=accesslog entryCSN: 20130425161500.179131Z#000000#001#000000 modifiersName: cn=Manager,cn=config modifyTimestamp: 20130425161500Z dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov structuralObjectClass: olcSyncProvConfig entryUUID: 9a4fbba8-fbe8-4f89-a64f-f20d66023a8a creatorsName: cn=config createTimestamp: 20111014131247Z entryCSN: 20130425004117.389246Z#000000#001#000000 modifiersName: cn=Manager,cn=config modifyTimestamp: 20130425004117Z dn: olcOverlay={1}accesslog,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: {1}accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogPurge: 7+00:00 1+00:00 olcAccessLogSuccess: TRUE structuralObjectClass: olcAccessLogConfig entryUUID: 7e12de76-e7fd-4fb2-83f5-46bb58363dd9 creatorsName: cn=config createTimestamp: 20111014131247Z entryCSN: 20111019170537.715510Z#000000#000#000000 modifiersName: cn=Manager,cn=config modifyTimestamp: 20111019170537Z dn: olcOverlay={2}ppolicy,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: {2}ppolicy olcPPolicyHashCleartext: TRUE olcPPolicyUseLockout: FALSE olcPPolicyForwardUpdates: FALSE structuralObjectClass: olcPPolicyConfig entryUUID: c9b15bd3-ae80-42f7-b355-31acebcc941f creatorsName: cn=config createTimestamp: 20111014131247Z entryCSN: 20111014131247.731074Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20111014131247Z dn: olcOverlay={3}memberof,olcDatabase={1}mdb,cn=config objectClass: olcMemberOf objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top olcOverlay: {3}memberof olcMemberOfRefInt: FALSE olcMemberOfGroupOC: groupOfUniqueNames olcMemberOfMemberAD: uniquemember structuralObjectClass: olcMemberOf entryUUID: 370bc13f-ae2a-4082-945d-7e6778967400 creatorsName: cn=Manager,cn=config createTimestamp: 20121001170641Z entryCSN: 20121001170641.572227Z#000000#000#000000 modifiersName: cn=Manager,cn=config modifyTimestamp: 20121001170641Z dn: olcDatabase={2}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {2}mdb olcDbDirectory: /u01/openldap/live2/var/accesslog-data olcSuffix: cn=accesslog olcAccess: {0}to dn.subtree="cn=accesslog" by dn.base="cn=manager,cn=company, cn=com" read by dn.base="cn=ldapreplicator,cn=systems,cn=company,cn=com" read by group/groupOfUniqueNames/uniqueMember.exact="cn=ldap_ admins,cn=ldap,cn=groups,cn=domain,cn=com" read by * none olcAddContentAcl: FALSE olcLastMod: TRUE olcLimits: {0}dn.base="cn=ldapreplicator,cn=systems,cn=domain,cn=com " size.soft=unlimited size.hard=unlimited time.soft=unlimited time.hard=un limited olcMaxDerefDepth: 15 olcReadOnly: FALSE olcSyncUseSubentry: FALSE olcMonitoring: TRUE olcDbNoSync: TRUE olcDbIndex: default eq olcDbIndex: objectClass eq olcDbIndex: entryCSN eq olcDbIndex: reqStart eq olcDbIndex: reqEnd eq olcDbIndex: reqResult eq olcDbIndex: reqDN eq olcDbMaxSize: 25000000000 olcDbMode: 0600 structuralObjectClass: olcMdbConfig entryUUID: 76907acf-5c8e-4650-9b36-023da1655a81 creatorsName: cn=config createTimestamp: 20111014131247Z entryCSN: 20130424144439.664389Z#000000#001#000000 modifiersName: cn=Manager,cn=config modifyTimestamp: 20130424144439Z dn: olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE structuralObjectClass: olcSyncProvConfig entryUUID: d6cadc16-c4f7-4daf-9a6b-9a37db55ca91 creatorsName: cn=config createTimestamp: 20111014131247Z entryCSN: 20111014131247.731074Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20111014131247Z -------------------- Thank you in advance for any help you might be able to offer. AL

2 3

Reduce the influence of ldap server trouble
by Yuki Takase 26 Apr '13

26 Apr '13

Hi all I'm a beginner of openldap. When I can't use a ldap server because of hardware or network trouble, I want to reduce the influence of ldap client. I changed the following configration of ldap.conf. bind_policy soft bind_timelimit 10 nss_initgroups_ignoreusers [local users...] Are there other solutions to reduce the influence? I use WebSphereMQ on Linux server. I added MQ's startup user 'mqm' to nss_initgroups_ignoreusers. But WebSphereMQ's startup command 'strmqm' always tries to connect to a ldap server. (I think that's a specification.) I use a ldap server to authentification of server maintenance members. But in some case such as above is it better not to use ldap?

2 1

hdb and mdb dereferencing aliases differently
by Juergen.Sprenger＠swisscom.com 26 Apr '13

26 Apr '13

Hi Michael, NSS results must not be dependent on the backend database a directory service uses. I activated connection logging and here's the proof that NSS is not the culprit. Searches initiated by NSS are identical and exactly this behavior can also be seen when using ldapsearch from command line with parameters from the log: # running 'getent passwd' with hdb backend: Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=0 BIND dn="cn=itsAgent,ou=customerAgent,dc=scom" method=128 Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=0 BIND dn="cn=itsAgent,ou=customerAgent,dc=scom" mech=SIMPLE ssf=0 Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=0 RESULT tag=97 err=0 text= Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=1 SRCH base="ou=account,dc=its,dc=scom" scope=1 deref=3 filter="(objectClass=posixAccount)" Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory x-LinuxLoginShell gecos description objectClass Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=656 text= Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 fd=13 closed (connection lost) # running 'getent passwd' with mdb backend: Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=0 BIND dn="cn=itsAgent,ou=customerAgent,dc=scom" method=128 Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=0 BIND dn="cn=itsAgent,ou=customerAgent,dc=scom" mech=SIMPLE ssf=0 Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=0 RESULT tag=97 err=0 text= Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=1 SRCH base="ou=account,dc=its,dc=scom" scope=1 deref=3 filter="(objectClass=posixAccount)" Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory x-LinuxLoginShell gecos description objectClass Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=1 SEARCH RESULT tag=101 err=0 text= Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 fd=13 closed (connection lost) I suspect that aliases are not handled the same way in hdb and mdb as I am using aliases here and deref=3 in both searches, example: dn: uid=joe,ou=Account,dc=its,dc=scom objectClass: alias objectClass: extensibleObject uid: joe aliasedObjectName: uid=joe,ou=Person,dc=its,dc=scom structuralObjectClass: alias When using hdb, the alias is dereferenced correctly (nentries=656), when using mdb it seems not to be dereferenced at all (nentries=0). Maybe there's a parameter around for mdb which I couldn't find in the docs to prevent this, but if not I consider this as a bug. Regards Juergen michael(a)stroeder.com wrote: >It would certainly help if you could examine the issue with pure LDAP search >operations preferably with OpenLDAP's ldapsearch command-line tool. > >When looking at NSS results too many things can go wrong with other >components' configuration. > >Ciao, Michael. > >Juergen.Sprenger(a)swisscom.com wrote: >> Hi, >> >> I have running OpenDLAP 2.4.35 on Gentoo Linux and wanted to make some tests with mdb. >> >> Slapd was running fine with hdb, no problems so far. >> Then I exported contents via slapcat and switched config to mdb. >> When slapd started using mdb no users from directory were shown by 'getent passwd': >> >> ### hdb part #### >> # using hdb parameters >> database hdb >> dirtyread >> cachesize 150000 >> cachefree 100 >> idlcachesize 450000 >> dncachesize 100000 >> >> # slapadd from backup and run slapd with hdb backend >> /etc/init.d/unscd stop >> /etc/init.d/slapd stop >> rm /var/lib/openldap-data/* >> rm -rf /etc/openldap/slapd.d/* >> cp -p /etc/openldap/DB_CONFIG /var/lib/openldap-data/ >> cp -p /etc/openldap/slapd.conf.hdb /etc/openldap/slapd.conf >> su ldap -c '/usr/sbin/slapadd -f /etc/openldap/slapd.conf -l odsldap-dev.ldif' >> /etc/init.d/slapd start >> /etc/init.d/unscd start >> slapcat -f /etc/openldap/slapd.conf -b dc=scom | md5sum >> # 73850f9a3f7ff9d3d1ddb7663cd046a6 - >> >> getent passwd >> # all users shown, everything ok >> >> ### mdb part #### >> # using mdb paramters >> database mdb >> dbnosync >> maxsize 2094967296 >> searchstack 64 >> >> # slapadd from backup and run slapd with mdb backend >> /etc/init.d/unscd stop >> /etc/init.d/slapd stop >> rm /var/lib/openldap-data/* >> rm -rf /etc/openldap/slapd.d/* >> cp -p /etc/openldap/slapd.conf.mdb /etc/openldap/slapd.conf >> su ldap -c '/usr/sbin/slapadd -f /etc/openldap/slapd.conf -l odsldap-dev.ldif' >> /etc/init.d/slapd start >> /etc/init.d/unscd start >> slapcat -f /etc/openldap/slapd.conf -b dc=scom | md5sum >> # 73850f9a3f7ff9d3d1ddb7663cd046a6 - <> >> getent passwd >> # no users from ldap shown >> >> Am I missing something when setting up and using mdb? >> Both backends have exactly the same content, and so the results for searches should also be identical. >> >> Regards >> >> Jürgen Sprenger

3 3

odd multi-master inconsistency
by Brian Gold 25 Apr '13

25 Apr '13

Hi all. Kind of an odd issue that I was hoping to get your advice with. I'm currently running a pair of rhel6 servers (hostnames: ldap1 & ldap2) w/ openldap-2.4.23 in multi-master. I also have a pair of rhel6 servers running keepalived & haproxy to act as loadbalancers (floating ip resolves to hostname: ldap) to direct ldap queries from some of our less documented/older services from the days before we had 2 ldap servers or from services that can't natively handle failover ldap providers. This setup has been working without issue (from what I could tell) for over 2 years. I noticed today that we have an issue with 2x of our users ldap entries. They went from being students to being staff, which necessitated a uid change (username09 for student to username for staff). We have a script that was written years ago for handling these uid changes. Apparently, when this script was run on these two users, the uid change happened only on one of the ldap servers. The other still contains the old uid information. Here is a sanitized version of the script: http://pastebin.com/UiDJgWKA Would love some advice on why this might not have replicated and what I might be able to do to prevent this in the future.

3 2

retrieve local operational attributes with translucent overlay?
by Steve Eckmann 25 Apr '13

25 Apr '13

Is it possible to retrieve operational attributes associated with local entries in the context of translucent overlay queries? For example, to retrieve the local entryUUID, I try something like this: ldapsearch -x -H ldaps://localhost -LLL -b ou=people,dc=issinc,dc=com \ -D "cn=admin,ou=people,dc=issinc,dc=com" -W \ '(mail=steve.eckmann(a)issinc.com)' dn entryUUID where the 'mail' attribute is remote. I get back the DN but not an entryUUID. If I specify + instead of entryUUID I get back three operational attributes: entryDN, subschemaSubentry, and hasSubordinates. If I query a purely local backend with + I get several operational attributes, including the three I want: entryUUID, createTimestamp, and modifyTimestamp. Is there something I can put in my slapd.conf or in the search to get specific local operational attributes? Thanks. Steve

1 0

slapd terminates with error "read_config: no serverID / URL match found. Check slapd -h arguments"
by Joe Phan 24 Apr '13

24 Apr '13

Hi, When I configure N-Way Multi-Master configuration with cn=config, slapd terminates with the error: "module syncprov.la: null module registered" and "read_config: no serverID / URL match found. Check slapd -h arguments". olcServerID IDs are already added and configured properly, but when slapd starts with -h option, it always fails. Please help if someone has gone through a similar issue. Thanks, Joe Reference, Step 3-4: http://niranjanmr.wordpress.com/2012/03/29/n-waymmr/ Is there an equivalent /etc/sysconfig/ldap file in Solaris 10? Platform: Sun Solaris10 OpenLDAP: openldap-2.4.32 Configuring for N-Way Multi-Master: adding olcServerID, olcOverlay: syncprov, and olcSyncRepl: apggd04dev# more config_repl.ldif #Specify ServerID for both the masters dn: cn=config changetype: modify add: olcServerID olcServerID: 101 ldap://apggd06dev.pg.dtveng.net olcServerID: 201 ldap://apggd04dev.pg.dtveng.net #Enable Syncprov Overlay for config database dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectclass: olcOverlayConfig objectclass: olcSyncProvConfig olcOverlay: syncprov #Configure SyncRepl for config database dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=ldap://apggd06dev.pg.dtveng.net binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=002 provider=ldap://apggd04dev.pg.dtveng.net binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 - add: olcMirrorMode olcMirrorMode: TRUE apggd04dev# ldapmodify -x -D "cn=config" -w secret -f config_repl.ldif -h apggd04dev.pg.dtveng.net <== olcServerID IDs are already added successfully to dn: cn=config. modifying entry "cn=config" adding new entry "olcOverlay=syncprov,olcDatabase={0}config,cn=config" modifying entry "olcDatabase={0}config,cn=config" Restart slapd with -h option: ==================== apggd04dev# /usr/local/libexec/slapd -d -1 -h ldap://apggd04dev.pg.dtveng.net:389 entryUUID: 05897b3c-3bd8-1032-8598-57af23b0cca0 creatorsName: cn=config createTimestamp: 20130417182610Z olcServerID: 101 ldap://apggd06dev.pg.dtveng.net <=== olcServerID IDs are successfully loaded olcServerID: 201 ldap://apggd04dev.pg.dtveng.net <=== olcServerID IDs are successfully loaded entryCSN: 20130418183118.510871Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20130418183118Z contextCSN: 20130418183118.573577Z#000000#000#000000 ... olcModuleLoad: {0}syncprov.la 51705faf loaded module syncprov.la 51705faf module syncprov.la: null module registered <=== ERROR for syncprov.la module ... olcSyncrepl: {0}rid=001 provider=ldap://apggd06dev.pg.dtveng.net binddn="cn=co <=== olcSyncrepl is successfully loaded nfig" bindmethod=simple credentials=secret searchbase="cn=config" type=refres hAndPersist retry="5 5 300 5" timeout=1 olcSyncrepl: {1}rid=002 provider=ldap://apggd04dev.pg.dtveng.net binddn="cn=co nfig" bindmethod=simple credentials=secret searchbase="cn=config" type=refres hAndPersist retry="5 5 300 5" timeout=1 olcMirrorMode: TRUE ... 5170847e index objectClass 0x0004 5170847e index entryUUID 0x0006 5170847e index entryCSN 0x0006 5170847e send_ldap_result: conn=-1 op=0 p=0 5170847e send_ldap_result: err=0 matched="" text="" 5170655f read_config: no serverID / URL match found. Check slapd -h arguments. <=== ERROR for serverID 5170655f slapd destroy: freeing system resources. 5170655f syncinfo_free: rid=001 5170655f slapd stopped. <=== slapd terminates 5170655f connections_destroy: nothing to destroy.

3 4

Documentation for memberof overlay
by Philip Colmer 24 Apr '13

24 Apr '13

I'm trying to find documentation for the various values that can be specified for the MemberOf overlay, particularly olcMemberOfMemberAD and olcMemberOfMemberOfAD. There are other values where I'm curious as to why they have their particular value (e.g. olcMemberOfDangling: ignore). Where is this stuff documented, please? I've tried searching openldap.orgweb site but cannot find anything definitive. Thanks. Philip

2 1

pbkdf2_sha256
by Alessandro Dentella 24 Apr '13

24 Apr '13

Hi, is it possible to use password stored as pbkdf2_sha256 in slapd? A first trial on ubuntu 12.04 seems to fail... My trial was: userPassword: {PBKDF2-SHA256}12000$1Pqf0/pfyxmDsPaeEwIghA$ory6WKYGfDASDNwhsWoOiVHwqmBnHginfu.FD2YuXIs Thnaks in advance sandro *:-) -- Sandro Dentella *:-) http://www.reteisi.org Soluzioni libere per le scuole http://sqlkit.argolinux.org SQLkit home page - PyGTK/python/sqlalchemy

2 2

RE: slapd-meta as a proxy for a monolithic namespace
by Hummel, Wolfgang 24 Apr '13

24 Apr '13

Hello, thanks a lot for your support on this topic. Both inputs from Howard and Pierangelo were really helpful. With the additional config tweak it works properly. So far I tested search and delete operations successfully. Other tests to follow ... Regards Wolfgang Hummel -----Original Message----- From: Hummel, Wolfgang Sent: Dienstag, 23. April 2013 18:10 To: 'openldap-technical(a)openldap.org' Subject: slapd-meta as a proxy for a monolithic namespace Hello OpenLDAP community, we are currently planning for a largescale directory with > 1 Bio. entries in a single namespace. The idea is to divide the DB in 10 equal sized DBs and let them access by slapd-meta proxies. Example: dn: ou=rsp1,c=de,o=mno entries with uid=79101234567890, 79101234567891 etc. 791 is always fix In our scenario each server would have 100 Mio. entries using the last digit of uid as a naturally even balanced distribution mechanism. Here are the questions: - is slapd-meta a feasible approach for this scenario ? - how could the slapd.conf for the proxy look like ? Here is a (non working) example with 2 backend servers. What is wrong about it ? ... moduleload back_meta moduleload back_ldap ... ####################################################################### # Meta database ####################################################################### database meta suffix " ou=rsp1,c=de,o=mno" dncache-ttl forever lastmod off rootdn "cn=admin,ou=rsp1,c=de,o=mno" rootpw secret network-timeout 1 uri "ldap://10.11.12.170/ ou=rsp1,c=de,o=mno" rewriteEngine on #rewriteContext searchFilterAttrDN rewriteContext searchFilter rewriteRule '^uid=[0-9]{11}1,.*' 'ldap://10.11.12.170/%0' ':@' uri "ldap://10.11.12.180/ ou=rsp1,c=de,o=mno" rewriteEngine on #rewriteContext searchFilterAttrDN rewriteContext searchFilter rewriteRule '^uid=[0-9]{11}2,.*' 'ldap://10.11.12.180/%0' ':@' ...

1 0

slapd-meta as a proxy for a monolithic namespace
by Hummel, Wolfgang 24 Apr '13

24 Apr '13

Hello OpenLDAP community, we are currently planning for a largescale directory with > 1 Bio. entries in a single namespace. The idea is to divide the DB in 10 equal sized DBs and let them access by slapd-meta proxies. Example: dn: ou=rsp1,c=de,o=mno entries with uid=79101234567890, 79101234567891 etc. 791 is always fix In our scenario each server would have 100 Mio. entries using the last digit of uid as a naturally even balanced distribution mechanism. Here are the questions: - is slapd-meta a feasible approach for this scenario ? - how could the slapd.conf for the proxy look like ? Here is a (non working) example with 2 backend servers. What is wrong about it ? ... moduleload back_meta moduleload back_ldap ... ####################################################################### # Meta database ####################################################################### database meta suffix " ou=rsp1,c=de,o=mno" dncache-ttl forever lastmod off rootdn "cn=admin,ou=rsp1,c=de,o=mno" rootpw secret network-timeout 1 uri "ldap://10.11.12.170/ ou=rsp1,c=de,o=mno" rewriteEngine on #rewriteContext searchFilterAttrDN rewriteContext searchFilter rewriteRule '^uid=[0-9]{11}1,.*' 'ldap://10.11.12.170/%0' ':@' uri "ldap://10.11.12.180/ ou=rsp1,c=de,o=mno" rewriteEngine on #rewriteContext searchFilterAttrDN rewriteContext searchFilter rewriteRule '^uid=[0-9]{11}2,.*' 'ldap://10.11.12.180/%0' ':@' ... logfile snippet for # ldapsearch -LLL -xD uid=admin,ou=rsp1,c=de,o=mno -w secret -b ou=rsp1,c=de,o=mno uid=791720001981 ldap_bind: Invalid credentials (49) Apr 23 08:44:13 slapd[26200]: >>> dnPrettyNormal: <uid=admin,ou=rsp1,c=de,o=mno> Apr 23 08:44:13 slapd[26200]: <<< dnPrettyNormal: <uid=admin,ou=rsp1,c=de,o=mno>, <uid=admin,ou=rsp1,c=de,o=mno> Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 BIND dn="uid=admin,ou=rsp1,c=de,o=mno" method=128 Apr 23 08:44:13 slapd[26200]: do_bind: version=3 dn="uid=admin,ou=rsp1,c=de,o=mno" method=128 Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 meta_back_bind: dn="uid=admin,ou=rsp1,c=de,o=mno". Apr 23 08:44:13 slapd[26200]: conn=1015 op=0: meta_back_getconn[0] Apr 23 08:44:13 slapd[26200]: conn=1015 op=0: meta_back_getconn[1] Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 meta_back_getconn: candidates=2 conn=ANON fetched Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 >>> meta_back_search_start[0] Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 >>> meta_search_dobind_init[0] Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 <<< meta_search_dobind_init[0]=1 Apr 23 08:44:13 slapd[26200]: ==> rewrite_context_apply [depth=1] string='uid=admin,ou=rsp1,c=de,o=mno' Apr 23 08:44:13 slapd[26200]: ==> rewrite_context_apply [depth=1] res={0,'NULL'} Apr 23 08:44:13 slapd[26200]: [rw] searchBase: "uid=admin,ou=rsp1,c=de,o=mno" -> "uid=admin,ou=rsp1,c=de,o=mno" Apr 23 08:44:13 slapd[26200]: ==> rewrite_context_apply [depth=1] string='(objectClass=*)' Apr 23 08:44:13 slapd[26200]: ==> rewrite_rule_apply rule=''^uid=[0-9]{11}1,.*'' string='(objectClass=*)' [1 pass(es)] Apr 23 08:44:13 slapd[26200]: ==> rewrite_context_apply [depth=1] res={0,'(objectClass=*)'} Apr 23 08:44:13 slapd[26200]: [rw] searchFilter: "(objectClass=*)" -> "(objectClass=*)" Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 <<< meta_back_search_start[0]=1 Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 >>> meta_back_search_start[1] Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 >>> meta_search_dobind_init[1] Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 <<< meta_search_dobind_init[1]=1 Apr 23 08:44:13 slapd[26200]: ==> rewrite_context_apply [depth=1] string='uid=admin,ou=rsp1,c=de,o=mno' Apr 23 08:44:13 slapd[26200]: ==> rewrite_context_apply [depth=1] res={0,'NULL'} Apr 23 08:44:13 slapd[26200]: [rw] searchBase: "uid=admin,ou=rsp1,c=de,o=mno" -> "uid=admin,ou=rsp1,c=de,o=mno" Apr 23 08:44:13 slapd[26200]: ==> rewrite_context_apply [depth=1] string='(objectClass=*)' Apr 23 08:44:13 slapd[26200]: ==> rewrite_rule_apply rule=''^uid=[0-9]{11}2,.*'' string='(objectClass=*)' [1 pass(es)] Apr 23 08:44:13 slapd[26200]: ==> rewrite_context_apply [depth=1] res={0,'(objectClass=*)'} Apr 23 08:44:13 slapd[26200]: [rw] searchFilter: "(objectClass=*)" -> "(objectClass=*)" Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 <<< meta_back_search_start[1]=1 Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 meta_back_search: ncandidates=2 cnd="**" Apr 23 08:44:13 slapd[26200]: daemon: activity on 1 descriptor Apr 23 08:44:13 slapd[26200]: daemon: activity on: Apr 23 08:44:13 slapd[26200]: Apr 23 08:44:13 slapd[26200]: daemon: epoll: listen=8 active_threads=0 tvp=zero Apr 23 08:44:13 slapd[26200]: daemon: epoll: listen=9 active_threads=0 tvp=zero Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 meta_back_search[0] match="" err=32 (No such object). Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 meta_back_search[1] match="" err=32 (No such object). Apr 23 08:44:13 slapd[26200]: send_ldap_result: conn=1015 op=0 p=3 Apr 23 08:44:13 slapd[26200]: send_ldap_result: err=32 matched="ou=rsp1,c=de,o=mno" text="" Apr 23 08:44:13 slapd[26200]: conn=1015 op=0 meta_back_bind: no target for dn "uid=admin,ou=rsp1,c=de,o=mno" (32).

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical