openldap-technical October 2014

openldap-technical@openldap.org

69 participants
76 discussions

Re: LMDB internals questions
by Howard Chu 04 Oct '14

04 Oct '14

Valerii Hiora wrote: > Hi Howard, > > I have a couple of questions regarding LMDB. In the future, please send questions to the openldap-technical mailing list. > 1. MDB_INTEGERKEY > >> Setting this option requires all keys to be the same size, typically >> sizeof(int) or sizeof(size_t) > > It is unclear from this description if size of the key depends on arch > or the only requirement is to have all keys to have same size. Is it > possible use i64 keys independent of arch? The documentation is precise - if the actual word size mattered, we would say so. You can use 64 bit integers on any arch. You could use 16 bit or 128 bit as well, it makes no difference. > 2. MDB_DUPSORT - how is it organized internally, i.e. which are > penalties of having big number of items for one key. And how > cheap/expensive is cursor count operation for a key? This is already documented - the values of a dupsort key are their own sub-database. Cursor count just returns md_entries of the subDB. > 3. Multiple databases > >> Currently a moderate number of slots are cheap but a huge number >> gets expensive: 7-120 words per transaction, and every mdb_dbi_open() >> does a linear search of the opened slots. > > So if the space isn't a problem and mdb_dbi_open() is called only once > and returned handle is kept - are there any other penalties for multiple > dbs? Can you also specify "moderate number of slots" to have a better > understanding? You should understand "moderate" as it applies to your own situation. We state quite clearly it does a linear search - you can see how the cost adds up. There are no costs other than those we have documented. -- -- 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

N-Way Multi-Master authentication problem
by Pocci Francesco 03 Oct '14

03 Oct '14

Hello everyone. I have a big problem releated to 2 OpenLdap configured in N-Way Multi-Master Configuration. My problem isn't on replication, that works, but on authenticating users on DIT !!! Infact when an user tries to simply authenticate himself on DIT with ldapsearch -x -D 'uid=example(a)gmail.com,ou=people,dc=example,dc=com' -w 'password' he receives an ldap_bind: Invalid credentials (49) error. Disabling configurations for multi master replication the same user is able to search on DIT. Following there is one slapd.conf of server 1... allow bind_anon_dn # Schema and objectClass definitions include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/inetorgperson.schema # Additional schemas pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args # Read slapd.conf(5) for possible values loglevel 0 modulepath /usr/lib64/openldap moduleload syncprov.la serverID 001 backend bdb # FIXME: puppet database bdb suffix "dc=example,dc=com" directory /var/lib/ldap rootdn "cn=admin,dc=example,dc=com" rootpw password checkpoint 512 30 dbconfig set_cachesize 0 2097152 0 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 #allows read access from all consumers access to * by dn.base="cn=admin,dc=example,dc=com" read by * break syncrepl rid=000 provider=ldap://ldap-be2 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=example,dc=com" attrs="*,+" bindmethod=simple binddn="cn=admin,dc=example,dc=com" credentials=password ########################################################### index objectclass eq index entryCSN eq index entryUUID eq index uidNumber eq index gidNumber eq index cn pres,sub,eq index sn pres,sub,eq index uid pres,sub,eq index displayName pres,sub,eq # mirror mode essential to allow writes #and must appear after all syncrepl directives mirrormode TRUE # define the provider to use the syncprov overlay # (last directives in database section) overlay syncprov # # contextCSN saved to database every 100 updates or ten minutes syncprov-checkpoint 100 10 Slap.conf of 2th server is a copy of this with different serverID and provider. Every hint will be a bless. Best regards. F. Francesco Pocci Open Reply Viale Regina Margherita, 8 00198 - Roma - ITALY phone: +39 06 844341 f.pocci(a)reply.it<mailto:f.pocci@reply.it> www.reply.it [Open Reply] ________________________________ -- The information transmitted is intended for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

1 0

Ldap performance : help needed
by Jonas Kellens 03 Oct '14

03 Oct '14

Hello list, I have the following rules in /etc/openldap/slapd.conf for about 250 users (cust1 -> cust250). This is an extract for user 'cust22' and user 'cust23' : access to dn.regex="ou=tbook[12345],ou=contacten,ou=cust22,dc=mydomain" attrs=children by group.exact="cn=admins,ou=cust22,dc=mydomain" write by * none break access to dn.one="ou=tbook1,ou=contacten,ou=cust22,dc=mydomain" by group.exact="cn=admins,ou=cust22,dc=mydomain" write by group.exact="cn=tbook1,ou=gebruikers,ou=cust22,dc=mydomain" read access to dn.one="ou=tbook2,ou=contacten,ou=cust22,dc=mydomain" by group.exact="cn=admins,ou=cust22,dc=mydomain" write by group.exact="cn=tbook2,ou=gebruikers,ou=cust22,dc=mydomain" read access to dn.one="ou=tbook3,ou=contacten,ou=cust22,dc=mydomain" by group.exact="cn=admins,ou=cust22,dc=mydomain" write by group.exact="cn=tbook3,ou=gebruikers,ou=cust22,dc=mydomain" read access to dn.one="ou=tbook4,ou=contacten,ou=cust22,dc=mydomain" by group.exact="cn=admins,ou=cust22,dc=mydomain" write by group.exact="cn=tbook4,ou=gebruikers,ou=cust22,dc=mydomain" read access to dn.one="ou=tbook5,ou=contacten,ou=cust22,dc=mydomain" by group.exact="cn=admins,ou=cust22,dc=mydomain" write by group.exact="cn=tbook5,ou=gebruikers,ou=cust22,dc=mydomain" read access to dn.regex="ou=tbook[12345],ou=contacten,ou=cust23,dc=mydomain" attrs=children by group.exact="cn=admins,ou=cust23,dc=mydomain" write by * none break access to dn.one="ou=tbook1,ou=contacten,ou=cust23,dc=mydomain" by group.exact="cn=admins,ou=cust23,dc=mydomain" write by group.exact="cn=tbook1,ou=gebruikers,ou=cust23,dc=mydomain" read access to dn.one="ou=tbook2,ou=contacten,ou=cust23,dc=mydomain" by group.exact="cn=admins,ou=cust23,dc=mydomain" write by group.exact="cn=tbook2,ou=gebruikers,ou=cust23,dc=mydomain" read access to dn.one="ou=tbook3,ou=contacten,ou=cust23,dc=mydomain" by group.exact="cn=admins,ou=cust23,dc=mydomain" write by group.exact="cn=tbook3,ou=gebruikers,ou=cust23,dc=mydomain" read access to dn.one="ou=tbook4,ou=contacten,ou=cust23,dc=mydomain" by group.exact="cn=admins,ou=cust23,dc=mydomain" write by group.exact="cn=tbook4,ou=gebruikers,ou=cust23,dc=mydomain" read access to dn.one="ou=tbook5,ou=contacten,ou=cust23,dc=mydomain" by group.exact="cn=admins,ou=cust23,dc=mydomain" write by group.exact="cn=tbook5,ou=gebruikers,ou=cust23,dc=mydomain" read I notice that there is a huge lack of performance (slow response times) when over about 100 users. There are quite some access rules in slapd.conf at that time. There is about 8 seconds between query and response : Sep 3 14:57:05 slap01 slapd[12908]: conn=1001 fd=13 ACCEPT from IP=xx.xx.xx.xx:1046 (IP=0.0.0.0:389) Sep 3 14:57:05 slap01 slapd[12908]: conn=1001 op=0 BIND dn="cn=Ucust23,ou=cust23,dc=mydomain" method=128 Sep 3 14:57:05 slap01 slapd[12908]: conn=1001 op=0 BIND dn="cn=Ucust23,ou=cust23,dc=mydomain" mech=SIMPLE ssf=0 Sep 3 14:57:05 slap01 slapd[12908]: conn=1001 op=0 RESULT tag=97 err=0 text= Sep 3 14:57:05 slap01 slapd[12908]: conn=1001 op=1 SRCH base="dc=mydomain" scope=2 deref=0 filter="(&(telephoneNumber=*)(sn=t*))" Sep 3 14:57:05 slap01 slapd[12908]: conn=1001 op=1 SRCH attr=cn sn telephoneNumber Sep 3 14:57:13 slap01 slapd[12908]: conn=1001 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Sep 3 14:57:13 slap01 slapd[12908]: conn=1001 op=2 ABANDON msg=2 Sep 3 14:57:13 slap01 slapd[12908]: conn=1001 op=3 UNBIND Sep 3 14:57:13 slap01 slapd[12908]: conn=1001 fd=13 closed Question : how can I get a better performance ? How can I adapt my access rules for better performance ? Thanks ! Kind Regards, Jonas.

4 10

Re: (ITS#7274) delta-syncrepl MMR infinite loop - like issue?
by Quanah Gibson-Mount 02 Oct '14

02 Oct '14

--On Thursday, September 25, 2014 2:46 PM +0200 Francesco Malvezzi <francesco.malvezzi(a)unimore.it> wrote: > During the setup of a mirror mode cluster, I enabled the syncprov after > building the mirror. > > So maybe I run into ITS#7274: > http://www.openldap.org/its/index.cgi/Documentation?id=7274;selectid=7274 > ;statetype=-1 > > delta-syncrepl fails with: > 1) ABANDON log messages on provider; > 2) matching "delta-sync lost" log messages on consumer. > > Do I understand correctly: provider needs contextCSN value for SID=0 in > order to have delta-syncrepl working? No, that is not correct. ITS#7274 was invalid, and had to do very specifically with the way in which I wrote a script to promote a stand-alone master to MMR mode. It does not apply to your situation. More likely, you would be hitting <http://www.openldap.org/its/index.cgi/?findid=7849>. --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

2 1

Returned mail: see transcript for details
by richm＠stanfordalumni.org 01 Oct '14

01 Oct '14

Your message was not delivered due to the following reason: Your message could not be delivered because the destination computer was not reachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. Most likely there is a network problem that prevented delivery, but it is also possible that the computer is turned off, or does not have a mail system running right now. Your message was not delivered within 2 days: Host 41.121.38.8 is not responding. The following recipients did not receive this message: <openldap-technical(a)openldap.org> Please reply to postmaster(a)openldap.org if you feel this message to be in error.

1 0

RE: MMR with MirrorMode problem..
by Bill Brigden 01 Oct '14

01 Oct '14

Just as a followup from having the issue now - I force killed and restarted the process as it wouldn't shutdown normally - it came up with: slapd[12047]: @(#) $OpenLDAP: slapd (Feb 27 2014 09:38:39) $#012#011root@debian: slapd[12048]: hdb_db_open: database "dc=test,dc=com": unclean shutdown detected; attempting recovery. slapd[12048]: slapd starting slapd[12048]: => bdb_idl_delete_key: c_get failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30994) slapd[12048]: conn=-1 op=0: attribute "entryCSN" index delete failure Cheers > -----Original Message----- > From: Bill Brigden [mailto:bill@dotbill.co.uk] > Sent: 01 October 2014 09:09 > To: 'openldap-technical(a)openldap.org' > Subject: MMR with MirrorMode problem.. > > Hi all, > > I'm running 2.4.39 with Mirrormode replication. I've noticed that > occasionally when making schema changes, a change will hang indefinitely > without reason. Though (possibly as a cause), also I've found that if I > try and restart one of the three servers in this replica set, it will > occasionally get the following with causes it to hang indefinitely: > > Oct 1 08:55:37 ldap-03 slapd[19608]: daemon: shutdown requested and > initiated. > Oct 1 08:55:37 ldap-03 slapd[19608]: slapd shutdown: waiting for 2 > operations/tasks to finish > > The other hosts show the disconnection and try and reconnect - the only > way to fix it seems to be either force killing this server or restarting > all the other hosts. > > Any ideas? It's a fairly standard setup with mirrormode as per the > doc's. > > I've seen there is 2.4.40 released however haven't scheduled in an > upgrade yet as there wasn't anything on the changelog that appeared to > be linked. > > Cheers

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical October 2014