openldap-technical June 2017

openldap-technical@openldap.org

34 participants
69 discussions

syncrepl fails after upgrade to openldap 2.4.45
by Juergen.Sprenger＠swisscom.com 22 Jun '17

22 Jun '17

Hi, after upgrading from openldap-2.4.44-r1 to openldap-2.4.45 on my Gentoo machine multi-master-replication does not work anymore. Has anything changed in configuration options for syncrepl or are certificates treated differently now? In the logs I found the following message: Jun 22 10:33:13 ids00000 slapd[30734]: [ID 000001 (local4.debug)] slap_client_connect: URI=ldaps://ldap.dannatu.ch:636 DN="cn=manager,dc=dannatu,dc=ch" ldap_sasl_bind_s failed (-1) Running slapd in foreground with -d -1 revealed this message: TLS: can't connect: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (self signed certificate in certificate chain). 594b8120 slap_client_connect: URI=ldaps://ldap.dannatu.ch:636 DN="cn=manager,dc=dannatu,dc=ch" ldap_sasl_bind_s failed (-1) My syncrepl configuriation: syncrepl rid=000 provider=ldaps://ldap.dannatu.ch:636 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=dannatu,dc=ch" attrs="*,+" scope=sub bindmethod=simple binddn="cn=Manager,dc=dannatu,dc=ch" credentials=************** I have verified the certificate and my selfsigned ca-certificate with openssl, and both are ok: # openssl verify /etc/ssl/certs/dannatuCA-cacert.pem /etc/ssl/certs/dannatuCA-cacert.pem: OK # openssl verify /etc/ssl/openldap/dannatu.ch.pem /etc/ssl/openldap/dannatu.ch.pem: OK Also verification with openssl s_client seems ok: # openssl s_client -connect ldap.dannatu.ch:636 -tls1_2 CONNECTED(00000003) depth=1 C = CH, ST = Solothurn, L = Solothurn, O = Dannatu AG, OU = IT, CN = Dannatu AG CA, emailAddress = admin(a)dannatu.ch verify return:1 depth=0 C = CH, ST = Solothurn, L = Solothurn, O = Dannatu AG, OU = IT, CN = dannatu.ch, emailAddress = admin(a)dannatu.ch verify return:1 --- Certificate chain 0 s:/C=CH/ST=Solothurn/L=Solothurn/O=Dannatu AG/OU=IT/CN=dannatu.ch/emailAddress=admin(a)dannatu.ch i:/C=CH/ST=Solothurn/L=Solothurn/O=Dannatu AG/OU=IT/CN=Dannatu AG CA/emailAddress=admin(a)dannatu.ch 1 s:/C=CH/ST=Solothurn/L=Solothurn/O=Dannatu AG/OU=IT/CN=Dannatu AG CA/emailAddress=admin(a)dannatu.ch i:/C=CH/ST=Solothurn/L=Solothurn/O=Dannatu AG/OU=IT/CN=Dannatu AG CA/emailAddress=admin(a)dannatu.ch --- After downgrading to openldap-2.4.44-r1 everything worked fine again. Seems certificate handling has changed. Any hints? Juergen Sprenger

1 0

Delete the root entry of a DIT (mdb as backend)
by Hongfu Huang 21 Jun '17

21 Jun '17

Hi all, I have defined a DIT (LMDB) as follows: > dn: olcDatabase={3}mdb,cn=config > objectClass: olcDatabaseConfig > objectClass: olcMdbConfig > olcDatabase: {3}mdb > olcDbDirectory: /var/lib/ldap/mycompany/o=mycompany > olcSuffix: o=mycompany > olcRootDN: uid=admin,ou=system > olcAccess: {0}to attrs=userPassword,shadowLastChange by > dn="uid=admin,ou=system" write by anonymous auth by self write by * none > olcAccess: {1}to * by dn="uid=admin,ou=system" write by * none > olcAddContentAcl: FALSE > olcLastMod: TRUE > olcMaxDerefDepth: 15 > olcReadOnly: FALSE > olcSyncUseSubentry: FALSE > olcMonitoring: TRUE > olcDbEnvFlags: writemap > olcDbEnvFlags: nometasync > olcDbNoSync: FALSE > olcDbIndex: objectClass pres,eq > olcDbIndex: cn pres,eq,sub > olcDbIndex: uid pres,eq,sub > olcDbIndex: uidNumber pres,eq > olcDbIndex: gidNumber pres,eq > olcDbIndex: mail pres,eq,sub > olcDbIndex: ou pres,eq,sub > olcDbIndex: sn pres,eq,sub > olcDbIndex: givenName pres,eq,sub > olcDbIndex: loginShell pres,eq > olcDbIndex: memberUid pres,eq,sub > olcDbIndex: nisMapName pres,eq,sub > olcDbIndex: nisMapEntry pres,eq,sub > olcDbMaxReaders: 0 > olcDbMaxSize: 4294967296 > olcDbMode: 0600 > olcDbSearchStack: 16 I can add the root entry as: > dn: o=mycompany > objectClass: organization > objectClass: top > o: mycompany And I can also add and delete sub-entries under o=mycompany. But I can not delete the root entry o=mycompany, even there is no sub-entry below it. Please no that the rootdn (uid=admin,ou=system) is not under the subffix (o=mycompany), that is why no rootPW is defined for this DIT. The rootDN and rootPW are defined in the second DIT (in BDB) The weird thing was that I could search and found it: > ldapsearch -x -D uid=admin,ou=system -w XXXXXXXXX -H > ldap://localhost:389 -b o=mycompany > # extended LDIF > # > # LDAPv3 > # base <o=cornerbank> with scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > > # mycompany > dn: o=mycompany > o: mycompany > objectClass: organization > objectClass: top > > # search result > search: 2 > result: 0 Success But it would fail if I tried to delete it: > $ ldapdelete -x -D uid=admin,ou=system -w XXXXXXXXX -H > ldap://localhost:389 o=mycompany > ldap_delete: No such object (32) > 32 In the other words, I could import the whole DIT for o=mycompany, but could not delete the whole DIT (the root entry o=mycompany could not be deleted). Does somebody know how to solve this problem? Thanks! Regards -- Hongfu Huang, Senior System Integrator M.Sc. Computer Science AdNovum Informatik AG Roentgenstrasse 22, 8005 Zurich, Switzerland phone +41 44 272 6111, direct +41 44 270 5266 hongfu.huang(a)adnovum.ch, www.adnovum.ch Locations: Zurich (HQ), Bern, Lausanne, Budapest, Ho Chi Minh City, Singapore

2 1

Error: Can't contact LDAP server
by Jelle de Jong 19 Jun '17

19 Jun '17

Hello everybody, # my /etc/ldap/slapd.conf http://paste.debian.net/plainh/076816e3 I am trying to debug an issue for a while and I can use some help. During midday or in the morning there seems to be something happening that is causing smbd (samba) to not be able to connect to the ldap server. Since the machine is localhost is powerfull enough and has free cpu and memory I am wondering what is going on. Maybe there is some connection maximum but these are the only messages I am getting. Does somebody know how to debug this, or know the options to tweak to get rid of the messages? Kind regards, Jelle de Jong Jun 15 12:39:29 stayce smbd[9632]: [2017/06/15 12:39:29.549569, 0] lib/smbldap.c:1225(smbldap_connect_system) Jun 15 12:39:29 stayce smbd[9632]: failed to bind to server ldap://localhost with dn="cn=admin,dc=companyone,dc=nl" Error: Can't contact LDAP server Jun 15 12:39:29 stayce smbd[9632]: #011(unknown) Jun 15 12:39:59 stayce smbd[5683]: [2017/06/15 12:39:59.076347, 0] lib/smbldap.c:1225(smbldap_connect_system) Jun 15 12:39:59 stayce smbd[5683]: failed to bind to server ldap://localhost with dn="cn=admin,dc=companyone,dc=nl" Error: Can't contact LDAP server Jun 15 12:39:59 stayce smbd[5683]: #011(unknown) Jun 15 12:40:14 stayce smbd[5685]: [2017/06/15 12:40:14.190979, 0] lib/smbldap.c:1225(smbldap_connect_system) Jun 15 12:40:14 stayce smbd[5685]: failed to bind to server ldap://localhost with dn="cn=admin,dc=companyone,dc=nl" Error: Can't contact LDAP server Jun 15 12:40:14 stayce smbd[5685]: #011(unknown) Jun 15 12:40:14 stayce smbd[5686]: [2017/06/15 12:40:14.232185, 0] lib/smbldap.c:1225(smbldap_connect_system) Jun 15 12:40:14 stayce smbd[5686]: failed to bind to server ldap://localhost with dn="cn=admin,dc=companyone,dc=nl" Error: Can't contact LDAP server Jun 15 12:40:14 stayce smbd[5686]: #011(unknown) Jun 15 12:40:17 stayce smbd[5783]: [2017/06/15 12:40:17.852955, 0] lib/smbldap.c:1225(smbldap_connect_system) Jun 15 12:40:17 stayce smbd[5783]: failed to bind to server ldap://localhost with dn="cn=admin,dc=companyone,dc=nl" Error: Can't contact LDAP server Jun 15 12:40:17 stayce smbd[5783]: #011(unknown) Jun 15 12:40:29 stayce smbd[5787]: [2017/06/15 12:40:29.636496, 0] lib/smbldap.c:1225(smbldap_connect_system) Jun 15 12:40:29 stayce smbd[5787]: failed to bind to server ldap://localhost with dn="cn=admin,dc=companyone,dc=nl" Error: Can't contact LDAP server Jun 15 12:40:29 stayce smbd[5787]: #011(unknown)

2 1

Re: SIGSEGV on mdb_txn_begin / __pthread_mutex_lock_full
by Howard Chu 19 Jun '17

19 Jun '17

opensource(a)gmx-topmail.de wrote: >> Are you running multiple Docker instances on the same database? AFAIK that won't work because of Docker's munging with POSIX namespaces. > No, it is a Single Docker instance. Actually, I saw the same thing happening on a Ubuntu box, so it should not be related to Docker. > > I restructured the CI tests and divided one big test suite into two. Funny thing is that the problem did not occur anymore as of now. > > One difference between the now separated tests was that they were using a different version of our lib.so (including the same version of LMDB however). But I hardly see how that might cause problems. If you meant libc.so yeah, you can't do that. LMDB uses process-shared POSIX mutexes in shared memory. glibc has a fundamental (and unfixable) flaw; it doesn't guarantee compatibility for the internal structure of pthread_mutex_t types between library versions. You cannot safely mix glibc versions among multiple programs concurrently accessing the same LMDB environment. Some details on the glibc issue here https://sourceware.org/bugzilla/show_bug.cgi?id=21119 It affects other libraries like BerkeleyDB too https://bugzilla.redhat.com/show_bug.cgi?id=1394862 -- -- 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

Limit which database is reachable on which port (slapd is listening on)?
by Karsten Heymann 19 Jun '17

19 Jun '17

Hi, short question: If I configure slapd to listen to several ports and have several databases configured, is there a way to limit which database is visible on which port? I want to use a single slapd instance to serve multiple databases (slapd-meta instances to be exact) and for each database want to use a dedicated listening port, somehow like port-based virtual hosts in the apache web server. The reason is that I want to define different firewall rules for the different databases. Is this possible with openldap? Best regards Karsten

1 0

RE: SIGSEGV on mdb_txn_begin / __pthread_mutex_lock_full
by opensource＠gmx-topmail.de 18 Jun '17

18 Jun '17

> Are you running multiple Docker instances on the same database? AFAIK that won't work because of Docker's munging with POSIX namespaces. No, it is a Single Docker instance. Actually, I saw the same thing happening on a Ubuntu box, so it should not be related to Docker. I restructured the CI tests and divided one big test suite into two. Funny thing is that the problem did not occur anymore as of now. One difference between the now separated tests was that they were using a different version of our lib.so (including the same version of LMDB however). But I hardly see how that might cause problems. *Shrug.*

1 0

Re: SIGSEGV on mdb_txn_begin / __pthread_mutex_lock_full
by Howard Chu 18 Jun '17

18 Jun '17

opensource(a)gmx-topmail.de wrote: > We are using LMDB and are running a big number of tests on a CI server (Debian via Docker, Xenon CPU). Are you running multiple Docker instances on the same database? AFAIK that won't work because of Docker's munging with POSIX namespaces. > The crash happens during opening the database. This is done a lot in the tests without problems (and on Windows this problem does not exist). However, during the CI process we get the crash quite reproducible (~80% crash rate when running the full CI test suite). > > This is our basic code triggering the SIGSEGV (minus error checking for simplicity): > > mdb_env_create(&dbEnv_); > mdb_env_set_maxdbs(dbEnv_, 8); > mdb_env_set_mapsize(dbEnv_, maxDbSizeInKByte * 1024); > mdb_env_open(dbEnv_, directory, 0, fileMode); > MDB_txn* txn; > mdb_txn_begin(dbEnv_, NULL, 0, &txn); > > It crashes inside mdb_txn_begin with this: > SIGSEGV (0xb) at pc=0x00007fd2607e4b58, pid=23603, tid=0x00007fd228633700 > C [libpthread.so.0+0x5b58] __pthread_mutex_lock_full+0x1a8 > > I digged into it a bit, and could tracd it down to this LOCK_MUTEX call in mdb_txn_renew0: > > /* Not yet touching txn == env->me_txn0, it may be active */ > if (ti) { > if (LOCK_MUTEX(rc, env, env->me_wmutex)) > return rc; > > I also logged some data about the env and the mutex (which looks normal however): > PID: 23603 ENV: 0x7fd1e03e9ab0 > TXN: 0x7fd22811b000 COUNT: 0 KIND: 144 LOCK: 0 OWNER: 0 > > Any idea what could go wrong here? > > Thanks! > Markus > > > Some additional crash info: > > siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x00007fd22801a058 > > Registers: > RAX=0x00007fd22801a060, RBX=0x00007fd22811b040, RCX=0x0000000000000000, RDX=0x0000000000000000 > RSP=0x00007fd22862ff50, RBP=0x0000000000005c4f, RSI=0x0000000000000080, RDI=0x0000000000005c4f > R8 =0x0000000000000080, R9 =0x0000000000000000, R10=0x00007fd22811b060, R11=0x0000000000000000 > R12=0x0000000000000000, R13=0x00007fd22813b0f0, R14=0x00007fd2286309d0, R15=0x00007fd25848b000 > RIP=0x00007fd2607e4b58, EFLAGS=0x0000000000010206, CSGSFS=0x0000000000000033, ERR=0x0000000000000006 > TRAPNO=0x000000000000000e > > Top of Stack: (sp=0x00007fd22862ff50) > 0x00007fd22862ff50: 00007fd22813b0f0 00007fd228630040 > 0x00007fd22862ff60: 0000000000000000 00007fd22813b0f0 > 0x00007fd22862ff70: 00007fd2286309d0 00007fd20c2d05e4 > 0x00007fd22862ff80: 00007fd228630050 00007fd22862ff90 > 0x00007fd22862ff90: 0000000000001020 000000000000003c > 0x00007fd22862ffa0: 0000000a00000023 0000000a00000000 > 0x00007fd22862ffb0: 00007fd228633700 00007fd25fee1c29 > 0x00007fd22862ffc0: 0000000000000000 00007fd25fe7a423 > 0x00007fd22862ffd0: 00007fd2286309d0 0000000900000000 > 0x00007fd22862ffe0: 0000000000000008 00007fd244000000 > 0x00007fd22862fff0: 00007fd22813b0f0 00007fd25fe79ae3 > 0x00007fd228630000: 0000000000000000 00000000286300c0 > 0x00007fd228630010: 0000000000000000 00007fd25fe7b255 > 0x00007fd228630020: 00007fd22811b000 00007fd1e03e9ab0 > 0x00007fd228630030: 00007fd1e08f3260 00007fd25fe6fb22 > 0x00007fd228630040: 00007fd2286300c0 00007fd20c2d0e8a > 0x00007fd228630050: 00007fd2286300c0 00007fd2601ac2a0 > 0x00007fd228630060: 0000000000000020 00007fd244000000 > 0x00007fd228630070: 0000000800000000 00007fd25fe79ae3 > 0x00007fd228630080: 0000000000000020 00007fd228630660 > 0x00007fd228630090: 00007fd1e08f3260 00007fd2286301c8 > 0x00007fd2286300a0: 00000000601ac2a0 0000000000000000 > 0x00007fd2286300b0: 00007fd1e03e9ab0 00007fd25fe6fb22 > 0x00007fd2286300c0: 00007fd228630660 00007fd20c23a768 > 0x00007fd2286300d0: 0000000200f01b00 00007fd20000003b > 0x00007fd2286300e0: 00007fd20c2eb3fd 00007fd24921da4c > 0x00007fd2286300f0: 00000005cac01420 00007fd22814c210 > 0x00007fd228630100: 00007fd228630460 00007fd24921f99f > 0x00007fd228630110: 00007fd2286301c8 0000002000000000 > 0x00007fd228630120: 0000000000000000 0000000000000000 > 0x00007fd228630130: 0000000000000000 0000000000000020 > 0x00007fd228630140: 0000000000000000 0000000000000000 > > Instructions: (pc=0x00007fd2607e4b58) > 0x00007fd2607e4b38: 00 a9 00 00 00 40 0f 85 02 ff ff ff c7 43 04 01 > 0x00007fd2607e4b48: 00 00 00 64 48 8b 04 25 e0 02 00 00 48 83 e0 fe > 0x00007fd2607e4b58: 4c 89 50 f8 64 48 8b 04 25 e0 02 00 00 48 89 43 > 0x00007fd2607e4b68: 20 64 48 8b 04 25 10 00 00 00 48 05 e0 02 00 00 > > Register to memory mapping: > > RAX=0x00007fd22801a060 is an unknown value > RBX=0x00007fd22811b040 is an unknown value > RCX=0x0000000000000000 is an unknown value > RDX=0x0000000000000000 is an unknown value > RSP=0x00007fd22862ff50 is pointing into the stack for thread: 0x00007fd25848b000 > RBP=0x0000000000005c4f is an unknown value > RSI=0x0000000000000080 is an unknown value > RDI=0x0000000000005c4f is an unknown value > R8 =0x0000000000000080 is an unknown value > R9 =0x0000000000000000 is an unknown value > R10=0x00007fd22811b060 is an unknown value > R11=0x0000000000000000 is an unknown value > R12=0x0000000000000000 is an unknown value > R13={method} {0x00007fd22813b0f0} 'nativeCreate' '(Ljava/lang/String;J[B)J' in 'MyDb' > R14=0x00007fd2286309d0 is pointing into the stack for thread: 0x00007fd25848b000 > R15=0x00007fd25848b000 is a thread > > > > -- -- 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

Elliptic Curve support in 2.4 branch
by Abdelkader Chelouah 18 Jun '17

18 Jun '17

Elliptic Curve support for OpenSSL was added in master branch 4 years ago (ITS#7595). Is there any plan to backport EC support for OpenSSL in 2.4 branch ?

1 0

slap_global_control: unrecognized control: 1.3.6.1.4.1.4203.666.5.16
by Jelle de Jong 18 Jun '17

18 Jun '17

Hello everybody, I am getting a lot of these slap_global_control messages in my syslog. I searched online and tried adding the bellow to my /etc/ldap/slapd.conf but it did not help. Does somebody know how to resolve these messages? Kind regards, Jelle de Jong include /etc/ldap/schema/ppolicy.schema Jun 15 13:15:08 cassidy slapd[9071]: slap_global_control: unrecognized control: 1.3.6.1.4.1.4203.666.5.16 cassidy:~# slapd -V @(#) $OpenLDAP: slapd (May 30 2017 07:56:03) $ buildd@x86-ubc-01:/build/openldap-BLqnh8/openldap-2.4.40+dfsg/debian/build/servers/slapd cassidy:~# ldapsearch -x -b "" -s base supportedControl # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: supportedControl # # dn: supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1

2 1

Re: using -c with slapd to force full reload
by Quanah Gibson-Mount 15 Jun '17

15 Jun '17

--On Thursday, June 15, 2017 4:20 PM -0700 Daniel Jung <mimianddaniel(a)gmail.com> wrote: > > > > -c with RID of the consumer and using Syncrepl. > I see the ITSs are opened for the related issue. I am only seeing this > problem on some consumer and not on the master by the way. I will see if > the masters are not in synced in all the datas. Hi Daniel, Your answer still isn't clear to me. From what you wrote, I would interpret that as doing -c 100 (-c with the RID of the consumer). The man page clearly states it takes a value pair, like -c rid=100 Generally, you're always better off doing a slapcat of the master and a slapadd on the consumer as it takes less time to populate the DB, and you don't have to worry about clients getting results from a partial database. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical June 2017