openldap-technical

openldap-technical@openldap.org

17 participants
9799 discussions

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

access control with pbind overlay
by Ferenc Wagner 29 Sep '14

29 Sep '14

Hi, I've got a partial syncrepl replica, which (among others) misses the userPassword attributes of the provider database. I added a pbind overlay to the replica, which forwards binds to the provider, thus it became possible to do simple binds against the replica. But access control on the replica does not honor these binds properly: "by users" works, but "by self" does not. Before I waste too much time debugging: is it supposed to work at all? I tested this under 2.4.31 with: dn: olcDatabase={1}mdb,cn=config olcAccess: to * by dn.exact=gidNumber=119+uidNumber=116,cn=peercred,cn=external,cn=auth read by self read by * none olcSyncrepl: rid=1 [...] The external auth part works, and if I replace self with users, that works as well (but is not what I want). Do I expect too much? -- Thanks, Feri.

2 5

can a automountMap be associated with a nisNetgroup
by Dal tee 26 Sep '14

26 Sep '14

Hi, I'm trying to see if I can control which mounts get mounted based on a servers netgroup membership. I suppose the first question is... Can it be done. I'm using an openldap client on RHEL 6.2 accessing AD. Has anyone got a working example they can walk through ?

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical