openldap-technical

openldap-technical@openldap.org

9 participants
9989 discussions

Re: Upgrade to 2.4.35 Causes Instability, Errors
by Tim Gustafson 18 Jul '13

18 Jul '13

> So you didn't answer anything about the old version of OpenLDAP versus the > current one. I would note that according to the db_stat output, you've > experienced zero deadlocks. That seems somewhat in conflict with your > earlier report. Did you run db_recover (resetting the stats)? Sorry; I missed that one. We were running 2.4.33 before the upgrade. I have not run db_recover in between the original report and now. It is worth noting that the deadlock errors have ceased in the log file, but I can't speak to whether or not we're more stable than we were before; as I mentioned earlier, it seemed kinda random when it would crash. I was thinking that doing a slapcat and then cleaning out the database files and then slapadd'ing everything back might be helpful. Do you agree? -- Tim Gustafson tjg(a)ucsc.edu 831-459-5354 Baskin Engineering, Room 313A

2 1

Re: Upgrade to 2.4.35 Causes Instability, Errors
by Tim Gustafson 18 Jul '13

18 Jul '13

> When you say you upgraded, what all did you do? Did you only upgrade the > openldap binaries? From what openldap release to what release? Did your > upgrade also change the version of BDB? What version of BDB were you on? > What one are you on now? What does your DB_CONFIG file look like? What > does your db_stat -c usage show for locks/lockers/lock objects etc? We're running FreeBSD. I did a minor OS update from 8.2 to 8.4, and then rebuilt all my ports using "portmaster". We're using db46-4.6.21.4 both before and after the upgrade. DB_CONFIG is as follows: set_cachesize 0 67108864 1 set_flags DB_LOG_AUTOREMOVE The output of "db_stat-4.6 -c" is: 116 Last allocated locker ID 0x7fffffff Current maximum unused locker ID 9 Number of lock modes 1000 Maximum number of locks possible 1000 Maximum number of lockers possible 1000 Maximum number of lock objects possible 16 Number of current locks 24 Maximum number of locks at any one time 105 Number of current lockers 111 Maximum number of lockers at any one time 16 Number of current lock objects 22 Maximum number of lock objects at any one time 4144507 Total number of locks requested 4144491 Total number of locks released 0 Total number of locks upgraded 36 Total number of locks downgraded 38 Lock requests not available due to conflicts, for which we waited 0 Lock requests not available due to conflicts, for which we did not wait 0 Number of deadlocks 0 Lock timeout value 0 Number of locks that have timed out 0 Transaction timeout value 0 Number of transactions that have timed out 712KB The size of the lock region 13666 The number of region locks that required waiting (0%) -- Tim Gustafson tjg(a)ucsc.edu 831-459-5354 Baskin Engineering, Room 313A

2 1

Upgrade to 2.4.35 Causes Instability, Errors
by Tim Gustafson 18 Jul '13

18 Jul '13

I recently upgraded OpenLDAP to 2.4.35 and I'm now experiencing some instability issues, and also seeing a bazillion of the following error in my log file: bdb_dn2id_delete 0x108c68: delete failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock -30995 I'm using the BDB backend at the moment. One Google search hit I found suggested I switch to MDB instead. Would this help? -- Tim Gustafson tjg(a)ucsc.edu 831-459-5354 Baskin Engineering, Room 313A

3 3

delete members in big groups with back_mdb
by Marco Schirrmeister 18 Jul '13

18 Jul '13

Hi, I have a problem with mdb and modify operations on very large groups. Specifically deleting members from those groups. Removing 10 members from a group with 25000 members takes 23 seconds. Which also means, all other clients that want to do something hang. Deleting a user from multiple big groups takes minutes before it finishes. Adding members to a large group is quick though. When this delete is running, the cpu goes also up to 100%. It looks like it has to do with the index that I have on uniqueMember. If I remove the index on uniqueMember, the delete of members in big groups is fast. System details are CentOS 6 64bit OpenLDAP 2.4.35 slapd.conf below Is this something normal/exptected or is it maybe a bug? Steps to reproduce - Install OpenLDAP 2.4.35 - Import a base ldif - Add a group with 25000 users - Remove 10 members from the group via ldapmodify Example group dn: cn=x3zolgnanlmpzj1nfk21,ou=groups,dc=example,dc=com objectClass: top objectClass: groupOfUniqueNames ou: groups cn: x3zolgnanlmpzj1nfk21 description: aw88bob79vvqffv1fhii uniqueMember: uid=faefxus4e83ywhh7bbgw(a)ough6unnwjdx0zzqiy0i.e3j,ou=people,dc=example,dc=com ... Below is the slapd.conf from a test system where I reproduced it. I used a very minimal config on the test system. ---- slapd.conf ---- include /usr/share/openldap2.4/schema/core.schema include /usr/share/openldap2.4/schema/cosine.schema include /usr/share/openldap2.4/schema/corba.schema include /usr/share/openldap2.4/schema/inetorgperson.schema include /usr/share/openldap2.4/schema/openldap.schema pidfile /var/run/ldap2.4/slapd.pid argsfile /var/run/ldap2.4/slapd.args modulepath /usr/lib64/oldap24/openldap2.4 moduleload back_monitor.la loglevel stats sync serverID 21 ldap://ldap.example.com database mdb suffix "dc=example,dc=com" rootdn "cn=manager,dc=example,dc=com" rootpw secret directory /var/lib/ldap2.4/example.com dbnosync maxsize 107374182400 conn_max_pending_auth 2000 index objectClass eq index uniqueMember eq index entryCSN,entryUUID eq monitoring on database config rootdn "cn=admin,cn=config" rootpw secret database monitor rootdn cn=monitor rootpw secret ---- slapd.conf ---- Thanks Marco

4 6

Q: TLS support
by Ulrich Windl 18 Jul '13

18 Jul '13

Hi! I have some questions on TLS support in OpenLDAP: 1) How can I find out which cipher suite had been configured (when using the distribution-supplied version)? From ldd I guess my slapd is using libopenssl0_9_8. 2) Is the restriction ("This directive is not supported when using GnuTLS.") on TLSCACertificatePath and GunTLS still effective? I'd like to use it, but I'm unsure what the cipher suite is. 3) Do the CA certificates for TLSCACertificateFile have to have a specific ordering? Regards, Ulrich

3 3

OpenLDAP syncrepl using SASL - GSSAPI
by Quentin PETEL 18 Jul '13

18 Jul '13

Hi! I'm trying to implement a Kerberos server using an OpenLdap backend on a server called *ldap1.vm* and replicate those on an other called *ldap2.vm*. My first server is working fine. Each kerberos principal is stored in his own ldap entry (with the krbPrincipalName attribut). For exemple : user1(a)EXEMPLE.COM --> uid=user1,ou=people,dc=exemple,dc=com ldap/ldap2.vm.exemple.com(a)EXEMPLE.COM --> cn=ldap2.vm,ou=ldap,dc=exemple,dc=com I wish to replicate either the cn=config DIT and the dc=exemple,dc=com DIT to my second server. So in my *cn=config* DIT on *ldap1.vm* I have the following configuration : ========================================================== dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcAuthzRegexp: {0}uid=admin,cn=exemple.com,cn=gssapi,cn=auth cn=admin,dc=exemple,dc=com olcAuthzRegexp: {1}uid=ldap\/(.*).exemple.com,cn=exemple.com,cn=gssapi,cn=auth cn=$1,ou=ldap,dc=exemple,dc=com olcAuthzRegexp: {2}uid=host\/(.*).exemple.com,cn=exemple.com,cn=gssapi,cn=auth cn=$1,ou=hosts,dc=exemple,dc=com olcAuthzRegexp: {3}uid=(.*),cn=exemple.com,cn=gssapi,cn=auth uid=$1,ou=people,dc=exemple,dc=com olcSaslRealm: EXEMPLE.COM olcServerID: 1 ldap://ldap1.vm.exemple.com/ olcServerID: 2 ldap://ldap2.vm.exemple.com/ olcLogLevel: stats olcPidFile: /var/run/slapd/slapd.pid olcToolThreads: 1 dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_hdb olcModuleLoad: {1}syncprov dn: olcBackend={0}hdb,cn=config objectClass: olcBackendConfig olcBackend: {0}hdb dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=Subschema" by * read olcSizeLimit: 500 dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by * break olcRootDN: *cn=admin,cn=config* dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 100 dn: olcDatabase={1}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=exemple,dc=com olcAccess: {0}to attrs=userPassword,shadowLastChange by dn="cn=admin,dc=exemple,dc=com" write by dn.one="ou=ldap,dc=exemple,dc=com" read by anonymous auth by * none olcAccess: {1}to dn.subtree="dc=exemple,dc=com" by dn="cn=adm-srv,ou=krb5,dc=exemple,dc=com" write by dn="cn=kdc-srv,ou=krb5,dc=exemple,dc=com" read by dn="cn=admin,dc=exemple,dc=com" write by dn.one="ou=ldap,dc=exemple,dc=com" read olcAccess: {2}to attrs=loginShell by self write by users read by * none olcAccess: {3}to dn.base="" by * read olcAccess: {4}to * by users read by * none olcAccess: {5}to dn="cn=config" by dn.one="ou=ldap,dc=exemple,dc=com" write olcLastMod: TRUE olcRootDN: cn=admin,dc=exemple,dc=com olcRootPW: {SSHA}7JR5Gh0ZUbw9U4cVytBrChBjXuPAdLKh olcDbCheckpoint: 512 30 olcDbConfig: {0}set_cachesize 0 2097152 0 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbIndex: objectClass eq olcDbIndex: uid eq olcDbIndex: cn eq olcDbIndex: ou eq olcDbIndex: dc eq olcDbIndex: uidNumber eq olcDbIndex: gidNumber eq olcDbIndex: memberUid eq olcDbIndex: uniqueMember eq olcDbIndex: krbPrincipalName eq,pres,sub olcDbIndex: krbPwdPolicyReference eq dn: olcOverlay={0}syncprov,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 100 ========================================================== And on the ldap2.vm i wanna replicate the cn=config DIT first: ========================================================== dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break olcRootDN: cn=admin,cn=config olcSyncrepl: {0}rid=001 provider="ldap://ldap1.vm.exemple.com/" type=refreshAndPersist retry="10 30 30 +" searchbase="cn=config" bindmethod=sasl saslmech=gssapi ========================================================== There is no olcMirrorMode attributes because I wanna add other provider directives later. Every 10 secondes, i see those logs: ========================================================== conn=1001 fd=13 ACCEPT from IP=192.168.x.x:57695 (IP=0.0.0.0:389) conn=1001 op=0 BIND dn="" method=163 conn=1001 op=0 RESULT tag=97 err=14 text=SASL(0): successful result: conn=1001 op=1 BIND dn="" method=163 conn=1001 op=1 RESULT tag=97 err=14 text=SASL(0): successful result: conn=1001 op=2 BIND dn="" method=163 conn=1001 op=2 BIND authcid="ldap/ldap2.vm.exemple.com(a)EXEMPLE.COM" authzid="ldap/ldap2.vm.exemple.com(a)EXEMPLE.COM" conn=1001 op=2 BIND dn="cn=ldap2.vm,ou=ldap,dc=exemple,dc=com" mech=GSSAPI sasl_ssf=56 ssf=56 conn=1001 op=2 RESULT tag=97 err=0 text= conn=1001 op=3 SRCH base="cn=config" scope=2 deref=0 filter="(objectClass=*)" conn=1001 op=3 SRCH attr=* + findbase failed! 32 conn=1001 op=3 SEARCH RESULT tag=101 err=32 nentries=0 text= conn=1001 op=4 UNBIND conn=1001 fd=13 closed ========================================================== We see that the olcAuthzRegexp do is job, indeed, the authcid="ldap/ldap2.vm.exemple.com(a)EXEMPLE.COM" from the ticket (I use Kstart to obtain it) become dn="cn=ldap2.vm,ou=ldap,dc=exemple,dc=com". But it fail to find the cn=config DIT. Here is the entry on my ldap database: ========================================================== dn: cn=ldap2.vm,ou=ldap,dc=exemple,dc=com objectClass: ipHost objectClass: device objectClass: top objectClass: krbPrincipalAux objectClass: krbTicketPolicyAux cn: ldap2.vm ipHostNumber: 192.168.x.x structuralObjectClass: device entryUUID: afe9a32a-81a3-1032-85b7-7976b72b0c24 creatorsName: cn=admin,dc=exemple,dc=com createTimestamp: 20130715140754Z krbPrincipalName: ldap/ldap2.vm.exemple.com(a)EXEMPLE.COM krbLoginFailedCount: 0 krbPrincipalKey:: [...] krbPasswordExpiration: 19700101000000Z krbLastPwdChange: 20130715140838Z krbExtraData:: AAJmAuRRYWRtaW5ASU5URVJORS5PQlNFUlZBVE9JUkVERVNNQVJRVUVTLkZSAA= = krbExtraData:: AAgBAA== authzTo: {0}dn.regex:*cn=admin,cn=config* entryCSN: 20130716154135.008692Z#000000#001#000000 modifiersName: cn=admin,dc=exemple,dc=com modifyTimestamp: 20130716154135Z ========================================================== The authzTo directive allow, i think, this entry to act as cn=admin,cn=config and to see the cn=config DIT, am I wrong? How can I do what I want? This configuration works well when I try to synchronise the dc=exemple,dc=com DIT. Regards, Quentin

1 1

Problems with ACLs
by Leonardo Bacha Abrantes 17 Jul '13

17 Jul '13

Hi guys, I configured ACL (below) and am trying to log on the console with a ldap's user I receive the error "ldap_search_s No such object' on /var/log/secure. If I comment acls the user is able to logon. Here my configuration: ==>> olcDatabase={2}bdb.ldif olcRootDN: cn=Manager,dc=foo,dc=local olcRootPW: {MD5}xxxxxxxxxxxxxxxxx olcAccess: to attrs=userPassword by self write olcAccess: to attrs=cn,sn,displayName,mail,description by users read olcaccess: to * by self read I used slapacl to check the permissions and appeared ok. What I'm doing worng ? Can you help me please ?

2 2

Q: Multi-Master setup
by Ulrich Windl 16 Jul '13

16 Jul '13

Hi! I have a few questions for multi-master mode: 1) olcServerID (two arguments): if a node's salpd binds to some interface alias address, do I need an olcServerID for that interface alias, do I need an olcServerID for the physical host, or do I need both? 2) What is the correct syntax for the second argument (URI): Do you need a final slash, do you need the port? Currently I'm using a syntax like "olcServerID: 1 ldap://ldap.domain.org" 3) For the syncrepl privider, how is the syntax of the provider URI: With trailing slash, or with port, or with none of those? Currently I'm using a syntax like "olcServerID: 1 ldap://ldap.domain.org/" 4) Do I need olcUpdateRef? If so, for every server in the multi-master group? My guess is that without olcUpdateRef each server will accept local changes and sync those out. 5) How does "mirrormode=on" affect a multi-master setup? I'm dealing with a configuration tool (SLES11 SP2 YaST) tha tseems to have trouble with some configuration settings, so I wonder how the correct configuration will look like. 6) On "split brain": If one server is separated from the rest, and that server receives updates, and the rest receives updates also: The latest update of an entry will overwrite older entries once the servers join again, right? Once delta-syncrepl will work for multi-master, will the latest attribute change (as opposed to the latest entry change) be propagated to the rest? I read the documentation, but could not find answers to all of the questions above. Maybe someone can help. Regards, Ulrich

1 0

Regarding Queries for Ldap authentication
by Ashutosh Tiwari 16 Jul '13

16 Jul '13

Hello, I am calling ldap_init and ldap_bind_s from our code in which while calling the ldap_init, we are passing the multiple host in it, so I want to know what is the retry count for connection to a down server and time to wait for a connection etc. Is these parameters are configured ? where I can look into details for it. Thanks & Regards, Ashutosh Tiwari

1 0

Q: "stable" slapcat / slapadd?
by Ulrich Windl 13 Jul '13

13 Jul '13

Hi! I used to dump the OpenLDAP databases using slapcat (as suggested for backup). As an optimization I avoid storing identical databases. However I had seen changes that actually were not made, so my question: Is slapcat expected to be stable, i.e. report entries and attributes in a specific ordering? Is slapadd expected to be stable, i.e. add entries and attributes the same way when they come from the same LDIF file? I had just removed the entryCSN on cn=config, and I see differences after removing and rebuilding the config database that were not made in the LDIF file: --- /tmp/1 2013-07-12 14:49:35.000000000 +0200 +++ /tmp/2 2013-07-12 14:49:35.000000000 +0200 @@ -4,6 +4,10 @@ olcArgsFile: /var/run/slapd/slapd.args olcAuthzRegexp: {0}gidNumber=0\+uidNumber=0,cn=peercred,cn=external,cn=auth dn :cn=config +olcLogLevel: config +olcLogLevel: stats +olcLogLevel: sync +olcLogLevel: none olcPidFile: /var/run/slapd/slapd.pid olcServerID: 1 ldap://rksapds1.site olcServerID: 2 ldap://rksapds2.site @@ -19,10 +23,6 @@ entryUUID: db3f4d44-7c0e-1032-81c4-d54356bd918f creatorsName: cn=config createTimestamp: 20130708113956Z -olcLogLevel: config -olcLogLevel: stats -olcLogLevel: sync -olcLogLevel: none entryCSN: 20130712095650.995134Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20130712095650Z @@ -2152,12 +2152,12 @@ dn: olcDatabase={2}monitor,cn=config objectClass: olcDatabaseConfig olcDatabase: {2}monitor +olcAccess: {0}to dn.subtree="cn=monitor" by dn.base="cn=Admin,dc=censored + ,dc=uni-regensburg,dc=de" write by users read by * none structuralObjectClass: olcDatabaseConfig entryUUID: 20f4a254-7f1a-1032-9c35-67ae7acd0417 creatorsName: cn=config createTimestamp: 20130712083810Z -olcAccess: {0}to dn.subtree="cn=monitor" by dn.base="cn=Admin,dc=censored - ,dc=uni-regensburg,dc=de" write by users read by * none entryCSN: 20130712085712.643156Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20130712085712Z Regards, Ulrich

3 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical