openldap-technical

openldap-technical@openldap.org

7 participants
9901 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

undefined reference to gnutls_certificate_get_x509_cas -HELP
by lux-integ 30 Sep '14

30 Sep '14

Greetings I am trying to compile openldap-2.4.39 on machine with linux (amd64 cpu) and gnutls-3.3.8. I passed --with-tls=gnutls to the configure options. The 'make' ends in failue with the errors:- " undefined reference to gnutls_certificate_get_x509_cas" " undefined reference to gcry_control" It compiles if I remove the --with-tls=gnutls option but I want to use gnutls. I would be grateful for some help. Yours sincerely luxInteg

2 2

Syncrepl authentication via GSSAPI/SASL/Kerberos
by Steven Presser 30 Sep '14

30 Sep '14

Hi, I'm running a pair of OpenLDAP servers on a network which primarily uses kerberos for authentication. The two servers replicate data (via a simple syncrepl master-slave setup). Right now, they're using simple authentication. I'd like to move them to using kerberos authentication. I've successfully gotten them to the point where the kerberos authentication (appears) to succeed. However, replication doesn't happen with the mysterious error "findbase failed! 32". I have found no mention of this error, other than a couple of permissions-related errors. I double-checked my permissions, so it's not that. I've copied relevant portions of my slapd.conf below and would be happy to provide more if required. I also have a syslog excerpt below. Does anyone know what I should be looking at next or have an example of a functional setup similar to what I've described? Thanks, Steve Functioning syncrepl config: syncrepl rid=1 provider=ldap://ldap1.pressers.name/ type=refreshAndPersist retry="60 30 300 +" searchbase="dc=pressers,dc=name"i bindmethod=simple binddn="cn=repl,dc=pressers,dc=name" credentials="SOMEPASSWORD" Config which fails mysteriously: syncrepl rid=1 provider=ldap://ldap1.pressers.name/ type=refreshAndPersist retry="60 30 300 +" searchbase="dc=pressers,dc=name"i bindmethod=sasl saslmech=gssap Finally, an excerpt for syslog on the master when the client attempts to connect: Sep 30 13:11:09 hawking slapd[1620]: conn=1005 fd=18 ACCEPT from IP=10.0.0.3:57149 (IP=0.0.0.0:389) Sep 30 13:11:09 hawking slapd[1620]: conn=1005 op=0 BIND dn="" method=163 Sep 30 13:11:09 hawking slapd[1620]: GSSAPI server step 1 Sep 30 13:11:09 hawking slapd[1620]: conn=1005 op=0 RESULT tag=97 err=14 text=SASL(0): successful result: Sep 30 13:11:09 hawking slapd[1620]: conn=1005 op=1 BIND dn="" method=163 Sep 30 13:11:09 hawking slapd[1620]: GSSAPI server step 2 Sep 30 13:11:09 hawking slapd[1620]: conn=1005 op=1 RESULT tag=97 err=14 text=SASL(0): successful result: Sep 30 13:11:09 hawking slapd[1620]: conn=1005 op=2 BIND dn="" method=163 Sep 30 13:11:09 hawking slapd[1620]: GSSAPI server step 3 Sep 30 13:11:09 hawking slapd[1620]: conn=1005 op=2 BIND authcid="ldap/mordor.pressers.name" authzid="ldap/mordor.pressers.name" Sep 30 13:11:09 hawking slapd[1620]: conn=1005 op=2 BIND dn="uid=ldap/mordor.pressers.name,cn=gssapi,cn=auth" mech=GSSAPI sasl_ssf=56 ssf=56 Sep 30 13:11:09 hawking slapd[1620]: conn=1005 op=2 RESULT tag=97 err=0 text= Sep 30 13:11:09 hawking slapd[1620]: conn=1005 op=3 SRCH base="dc=pressers,dc=name" scope=2 deref=0 filter="(objectClass=*)" Sep 30 13:11:09 hawking slapd[1620]: conn=1005 op=3 SRCH attr=* + Sep 30 13:11:09 hawking slapd[1620]: findbase failed! 32 Sep 30 13:11:09 hawking slapd[1620]: conn=1005 op=3 SEARCH RESULT tag=101 err=32 nentries=0 text= Sep 30 13:11:09 hawking slapd[1620]: conn=1005 op=4 UNBIND Sep 30 13:11:09 hawking slapd[1620]: conn=1005 fd=18 closed

3 6

MMR - Add and delete entry on on server, CSN too old on the other and the entry is not deleted
by Meunier, Antonin 30 Sep '14

30 Sep '14

Hello, I'm with openldap-2.4.39. I've 2 openldap server on MMR, the config is down to the mail. On the 1st server, il made - ADD an entry - Little after (1h) DELETE the same entry On the second server, I have : - The entry is created by replication - BUT the entry is not delete by the replication with a CSN too old error. How can i resolv this ? Thanks by advance Extract of the logs is : On 1st server (where entry is add and delete) : 2014-09-16T01:59:09.161478+02:00 ldapp01 slapd[19641]: conn=6131651 op=5367 ADD dn="cn=1952991,ou=groupe..." 2014-09-16T02:57:46.499274+02:00 ldapp01 slapd[19641]: conn=6153444 op=24 DEL dn="cn=1952991,ou=groupe_..." ... 2014-09-16T04:44:01.713257+02:00 ldapp01 slapd[19641]: syncprov_search_response: cookie=rid=000,sid=001,csn=20140916024243.636498Z#000000#001#000000;20140830211826.755872Z#000000#002#000000;20131010140905.564563Z#000000#065#000000;20130913220003.060576Z#000000#12b#000000;20131206221310.808393Z#000000#12d#000000 2014-09-16T04:44:01.713299+02:00 ldapp01 slapd[19641]: syncprov_sendresp: cookie=rid=000,sid=001,csn=20140916024342.267736Z#000000#001#000000 2014-09-16T04:44:01.906746+02:00 ldapp01 slapd[19641]: conn=6183327 op=1 UNBIND On the Second server (where entry persist without delete) : 2014-09-16T04:29:28.462968+02:00 ldapp02 slapd[12536]: syncrepl_message_to_op: rid=102 be_add cn=1952991,ou=groupe... (0) 2014-09-16T04:29:28.462968+02:00 ldapp02 slapd[12536]: syncrepl_message_to_op: rid=102 be_add cn=1952991,ou=groupe... (0) 2014-09-16T04:29:28.462978+02:00 ldapp02 slapd[12536]: slap_queue_csn: queing 0x7f0f505698d0 20140915235909.161585Z#000000#001#000000 2014-09-16T04:29:28.463051+02:00 ldapp02 slapd[12536]: slap_graduate_commit_csn: removing 0x7f0f50568740 20140915235909.161585Z#000000#001#000000 2014-09-16T04:29:28.463076+02:00 ldapp02 slapd[12536]: do_syncrep2: rid=102 cookie=rid=000,sid=001,csn=20140915235909.166279Z#000000#001#000000 2014-09-16T04:29:28.463113+02:00 ldapp02 slapd[12536]: slap_queue_csn: queing 0x7f0f5056e6ee 20140915235909.166279Z#000000#001#000000 2014-09-16T04:29:28.464678+02:00 ldapp02 slapd[12536]: slap_queue_csn: queing 0x7f0f5055f710 20140915235909.166279Z#000000#001#000000 2014-09-16T04:29:28.464860+02:00 ldapp02 slapd[12536]: syncprov_matchops: skipping original sid 001 2014-09-16T04:29:28.464870+02:00 ldapp02 slapd[12536]: slap_graduate_commit_csn: removing 0x7f0f50556380 20140915235909.166279Z#000000#001#000000 2014-09-16T04:29:28.464880+02:00 ldapp02 slapd[12536]: slap_graduate_commit_csn: removing 0x7f0f50563df0 20140915235909.166279Z#000000#001#000000 ... 2014-09-16T04:44:01.653713+02:00 ldapp02 slapd[12536]: do_syncrep2: rid=102 cookie=rid=000,sid=001,csn=20140915235909.166279Z#000000#001#000000 2014-09-16T04:44:01.653740+02:00 ldapp02 slapd[12536]: do_syncrep2: rid=102 CSN too old, ignoring 20140915235909.166279Z#000000#001#000000 (reqStart=20140915235909.000007Z,cn=de lta-sync) .. 2014-09-16T04:44:01.653619+02:00 ldapp02 slapd[12536]: do_syncrep2: rid=102 cookie=rid=000,sid=001,csn=20140915235909.161585Z#000000#001#000000 2014-09-16T04:44:01.653646+02:00 ldapp02 slapd[12536]: do_syncrep2: rid=102 CSN too old, ignoring 20140915235909.161585Z#000000#001#000000 (reqStart=20140915235909.000005Z,cn=de lta-sync) Configuration is : On the 1st server : . ServerID 001 . maxderefdepth 15 readonly FALSE sync_use_subentry FALSE . dbnosync TRUE # ecriture tous les 15 minutes checkpoint 0 15 . syncrepl rid=201 provider=ldap://ldapp02:389 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=ent,dc=fr" attrs="*,+" bindmethod=simple binddn="cn=admin,ou=system,dc=ent,dc=fr" credentials=XXXXXXX logbase="cn=delta-sync" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog mirrormode on # Overlay configuration should be added after the database configuration # Définition de l'overlay lié à la réplication maitre overlay syncprov syncprov-checkpoint 100 10 On the second server : ServerID 002 . maxderefdepth 15 readonly FALSE sync_use_subentry FALSE . dbnosync TRUE # ecriture tous les 15 minutes checkpoint 0 15 . syncrepl rid=102 provider=ldap://ldapp01:389 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=ent,dc=fr" attrs="*,+" bindmethod=simple binddn="cn=admin,ou=system,dc=ent,dc=fr" credentials=XXXXXXX logbase="cn=delta-sync" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog mirrormode on # Overlay configuration should be added after the database configuration # Définition de l'overlay lié à la réplication maitre overlay syncprov syncprov-checkpoint 100 10 Antonin Meunier

2 3

OpenLDAP manual sync (on-demand replication)
by Peter Boguszewski 30 Sep '14

30 Sep '14

I would like to setup a Master / Consumer relationship that only does one way replication on demand. We have complex scripts that update one server (the master) and needs to be verified / approved before replicating to the consumer. I understand how to setup replication in general and have a multi-master setup for other services so I am not asking how to do initial setup. My first thought is to set the replication interval to 30 days and forcing a manual sync - but this is the part I am not sure how to do. Is there a command to force a manual sync before the normal replication interval? Thanks in advance and sorry if there is a simple answer I am missing. Thanks for any help! -- Peter Boguszewski Manager of Library Systems UW Madison - Library Technology Group pboguszewski(a)library.wisc.edu 608.262.4768

3 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical