openldap-technical

openldap-technical@openldap.org

21 participants
9787 discussions

Why didn't rfc2307bis supersede rfc2307?
by John Lewis 27 Jun '17

27 Jun '17

https://tools.ietf.org/html/draft-howard-rfc2307bis-02 They only thing that jumps at me is the name. It doesn't follow rfc norms. Normally a new standard would be rfc and then the next number available. This one deviated, It used the same number as the old one and appended text. The standard itself is good enough to be used by Active Directory and FreeIPA by default. I am having a really hard time finding anyone who says that the standard is bad. I am willing to bet that if Luke Howard puts out this latest proposal out under the name of the next available rfc number today, which according to ftp://ftp.rfc-editor.org/in-notes/rfc-ref.txt would be rfc8203 it will be approved before the end of the year. According to Ludo here https://ludopoitou.com/2011/04/20/linux-and-unix-ldap-clients-and-rfc2307-s… , I can campaign for the standard myself if I had permission from the authors. I would do it to streamline documentation and, get the new standard into OpenLDAP 2.5 so it will be in OpenLDAP 2.6 by default.

3 5

mmr pair stops replicating: "consumer state is newer than provider"
by btb 27 Jun '17

27 Jun '17

hi. i have two servers, in an mmr arrangement, using delta-syncrepl. on a couple of occasions, the servers have stopped replicating, and the following is logged: dsa1: Jun 27 06:13:29 ldap0 slapd[8699]: do_syncrep2: rid=000 LDAP_RES_SEARCH_RESULT Jun 27 06:13:29 ldap0 slapd[8699]: do_syncrep2: rid=000 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform Jun 27 06:13:29 ldap0 slapd[8699]: do_syncrep2: rid=000 (53) Server is unwilling to perform Jun 27 06:13:29 ldap0 slapd[8699]: do_syncrepl: rid=000 rc -2 retrying dsa2: Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 fd=9 ACCEPT from IP=10.200.41.20:49141 (IP=0.0.0.0:389) Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=0 STARTTLS Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=0 RESULT oid= err=0 text= Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 fd=9 TLS established tls_ssf=256 ssf=256 Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=1 BIND dn="uid=dsa1_slapd-repl-content,ou=dsa1.example.org,ou=services,ou=accounts,dc=example,dc=org" method=128 Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=1 BIND dn="uid=dsa1_slapd-repl-content,ou=dsa1.example.org,ou=services,ou=accounts,dc=example,dc=org" mech=SIMPLE ssf=0 Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=1 RESULT tag=97 err=0 text= Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=2 SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is newer than provider! Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=3 UNBIND Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 fd=9 closed if i reload data and restart replication, things work again, for a period of time, but then this happens again. what determines "consumer state is newer than provider"? i'm also a little bit confused about this message in the context of mmr. if one has newer data than the other, i had sort of expected that the newer data would replace the old [obviously it's not that simple, so i'd like to understand what i'm missing]. lastly, how can i further troubleshoot why this happened in the first place? i'm using 2.4.44 on freebsd, built from ports. i can provide any config details etc - i just didn't want to inundate the post with guesses on detail that might not be relevant. thanks -ben

1 0

LDAP Issue: Logging region out of memory; you may need to increase its size
by Gurjot Kaur 27 Jun '17

27 Jun '17

Hello, On an already running setup of OpenLDAP 2.4 on Linux (Linux GURKES015 2.6.18-128.el5 #1 SMP Wed Dec 17 11:41:38 EST 2008 x86_64 x86_64 x86_64 GNU/Linux) platform, one day I start getting following error when I execute the slapcat command: bdb_db_open: warning - no DB_CONFIG file found in directory /opt/proxy/HostedDirectoryLDAPMultiMaster/instances/LdapServers_1/var/openldap-data: (2). Expect poor performance for suffix "dc=ORG,dc=COM".bdb(dc=ORG,dc=COM): Logging region out of memory; you may need to increase its size bdb_db_open: database "dc=ORG,dc=COM": db_open(/opt/proxy/HostedDirectoryLDAPMultiMaster/instances/LdapServers_1/var/openldap-data/id2entry.bdb) failed: Cannot allocate memory (12). backend_startup_one: bi_db_open failed! (12) slap_startup failed Following are the system RAM and disk space usage. Tasks: 192 total, 2 running, 190 sleeping, 0 stopped, 0 zombie Cpu(s): 0.1%us, 0.3%sy, 0.0%ni, 98.9%id, 0.7%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 8178840k total, 8145460k used, 33380k free, 329840k buffers Swap: 2031608k total, 220k used, 2031388k free, 6623032k cached Filesystem Size Used Avail Use% Mounted on /dev/mapper/rootvg-lv_root 1.9G 688M 1.2G 38% / tmpfs 3.9G 0 3.9G 0% /dev/shm /dev/sda1 289M 17M 258M 7% /boot /dev/mapper/rootvg-lv_users 1.9G 1.6G 218M 89% /users /dev/mapper/rootvg-lv_exec 124M 5.6M 113M 5% /exec /dev/mapper/rootvg-lv_images 1.9G 73M 1.8G 4% /images /dev/mapper/rootvg-lv_var 1.9G 140M 1.7G 8% /var /dev/mapper/rootvg-lv_tmp 961M 22M 890M 3% /tmp /dev/mapper/rootvg-lv_system 186M 7.9M 169M 5% /system /dev/mapper/rootvg-lv_usr 1.9G 663M 1.2G 37% /usr /dev/mapper/rootvg-lv_cft251 496M 430M 41M 92% /exec/products/cft /dev/mapper/rootvg-lv_bases 79G 19G 57G 25% /bases /dev/mapper/rootvg-lv_nbu 1008M 361M 597M 38% /exec/products/netbackup /dev/mapper/rootvg-lv_pat 1008M 194M 764M 21% /exec/products/patrol /dev/mapper/rootvg-lv_bladelogic 992M 187M 755M 20% /exec/products/bladelogic I have removed some log.xxxxx files from /opt/proxy/HostedDirectoryLDAPMultiMaster/instances/LdapServers_1/var/openldap-data which are not in use. But still the same error persist while executing slapcat command. Then I restarted the slapd process. After that I start facing ldaperror 80 with additional info "index generation failed" error while adding, deleting or modifying any entry along in ldap DB. Could somebody help us to understand: 1. Why there was "Logging region out of memory; you may need to increase its size" error. How to resolve it? 2. Why after slapd restart, I got "index generation failed" error. How to resolve it? PS: DB_CONFIG was not present in /var/openldap-data directory and slapcat was used to work properly before this issue. "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

2 2

RE: Using TLS
by Quanah Gibson-Mount 26 Jun '17

26 Jun '17

--On Friday, June 23, 2017 10:31 PM +0000 Daniel Le <daniel.le(a)exfo.com> wrote: > Thanks Quanah. > > Using OpenLDAP API, is it correct to set client TLS option to -not- > validate server certificates as follows? > > int opt; > opt = LDAP_OPT_X_TLS_NEVER; > rc = ldap_set_option(NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, &opt); You still have to reinitialize the global context, as in my commit, for the filehandle. So you'd want these two lines to be following: int new_ctx = 0; rc = ldap_set_option(ld, LDAP_OPT_X_TLS_NEWCTX, &new_ctx) etc. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

RE: syncrepl fails after upgrade to openldap 2.4.45
by Quanah Gibson-Mount 25 Jun '17

25 Jun '17

--On Friday, June 23, 2017 8:30 AM +0000 Juergen.Sprenger(a)swisscom.com wrote: > Have also added these entries to syncrepl now, but without any success: > > tls_cert=/etc/ssl/openldap/dannatu.ch.pem > tls_key=/etc/ssl/openldap/dannatu.ch.key > tls_cacert=/etc/ssl/certs/dannatuCA-cacert.pem This would indicate you want to do client cert authentication with the syncrepl client, which as far as I know, you are not using (based on your earlier configuration). You need to remove the tls_cert and tls_key lines. I've tested with OpenLDAP 2.4.45 and TLS works as expected with replication. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: ldapsearch on accesslog hangs in OpenLDAP 2.4.40 on RHEL 6.9 ( works ok w/ slapcat -b "cn=accesslog")
by Quanah Gibson-Mount 24 Jun '17

24 Jun '17

--On Thursday, June 22, 2017 9:19 PM +0000 Ron Lamarche <Ron.Lamarche(a)innovapost.com> wrote: > I've installed the RHEL 6.9 OpenLDAP bundled product and have a working > suffix based on cn=config vs. slapd.conf model but cannot get the > accesslog overlays/DB's to work properly (ldapsearch returns accesslog > records but never completes and instead hangs showing > "ldap_int_select" . Need to ctl –c to exit ) Hi Ron, The OpenLDAP build distributed by RedHat is known to have severe issues. It is strongly recommended to avoid their OpenLDAP builds because of this and their advanced age. If you are not able to build OpenLDAP yourself, the LTB project provides standard OpenLDAP builds for free: <http://ltb-project.org/wiki/download#openldap> If you require support, Symas (my employer) has such an offering. Our OpenLDAP builds also include features not yet available from the OpenLDAP project. You may be well facing any of a number of bugs that have been fixed in the 2.5 years since 2.4.40 was released, in particular: Fixed slapd cn=config when updating olcAttributeTypes (ITS#8199) Fixed slapo-accesslog to honor pauses during purge for cn=config update (ITS#8423) Finally, I would also note that the back-bdb backend has been deprecated since OpenLDAP 2.3, and as of OpenLDAP 2.4, back-hdb is also deprecated. The recommended backend is back-mdb, which is built on top of LMDB (<http://www.symas.com/lmdb/>, <https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database>) In general, issues with RedHat's build will not be explored unless you can reproduce the same problem with a current build of OpenLDAP. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

RE: Using TLS
by Quanah Gibson-Mount 23 Jun '17

23 Jun '17

--On Friday, June 23, 2017 10:08 PM +0000 Daniel Le <daniel.le(a)exfo.com> wrote: > Hi Quanah, > > No, I'm fairly new to OpenLDAP and wasn't aware of such global context > requirement. > > Does that only apply to client TLS options? > > Is global option set by passing a NULL LDAP handle? > > I found ITS#8573 wrt your TLS patch, but the URL: > <http://www.openldap.org/lists/openldap-devel/attachments/20170608/2ae39d > 03/attachment.bin> is not found. Can you point me to where to download or > see the patch? Has it been integrated into 2.4.45? Hi Daniel, You can view it here: <https://github.com/quanah/openldap-scratch/commit/cff66313706c607d4df6f0742…> and no, it would be part of 2.5 once submitted, although it applies just fine for me to 2.4 --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

RE: Using TLS
by Quanah Gibson-Mount 23 Jun '17

23 Jun '17

Hi Daniel, You are aware that you must use the global context when changing the TLS options for a client, correct? It does not work on the specific filehandle. See my TLS patch for the command line client tools for an example (that is posted to the openldap-devel list). --Quanah --On Friday, June 23, 2017 9:20 PM +0000 Daniel Le <daniel.le(a)exfo.com> wrote: > Hello, > > Is there a unit tester where the client LDAP_OPT_X_TLS_REQUIRE_CERT > option is set to LDAP_OPT_X_TLS_NEVER that I can try? I was looking at > openldap-2.4.44/clients/tools/ldapsearch but it doesn't configure this > option. > > My application program sets LDAP_OPT_X_TLS_NEVER. Why does LDAP client > still check for server certificate which fails in the case of bad > certificate? > > int opt; > opt = LDAP_OPT_X_TLS_NEVER; > ldap_retcode = ldap_set_option(m_tLDAP, LDAP_OPT_X_TLS_REQUIRE_CERT, > &opt); ... > > Daniel > > -----Original Message----- > From: Daniel Le > Sent: Monday, June 19, 2017 3:58 PM > To: 'Paulm' <paulm(a)tetrardus.net> > Cc: openldap-technical(a)openldap.org > Subject: RE: Using TLS > > I rebuilt with libssl (an OpenSSL library which supports SSL and TLS) and > that worked. Thanks. > > However, I got into the connect error "14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (self > signed certificate)", even though the LDAP_OPT_X_TLS_REQUIRE_CERT option > is set to LDAP_OPT_X_TLS_NEVER. Isn't LDAP client supposed to bypass > server certificate validation when LDAP_OPT_X_TLS_NEVER is configured? > > Daniel > > -----Original Message----- > From: Paulm [mailto:paulm@tetrardus.net] > Sent: Sunday, June 18, 2017 10:13 PM > > On Fri, Jun 16, 2017 at 03:26:20PM +0000, Daniel Le wrote: >> Hi, >> >> >> I'm seeing some critical error which causes the application program to >> exit/terminate when ldap_start_tls_s(LDAP-handle, NULL, NULL) is >> called. Tracing the code execution, ldap_start_tls_s => >> ldap_int_tls_start => tls_init, it appears the crash is at the >> statement "return impl->ti_tls_init()" in the tls_init function. >> >> >> Can someone give a pointer to help debugging this? And does OpenLDAP >> need to be linked to OpenSSL library for TLS to work? > > If your ldap libs are linked to gnutls, then it might be worthwhile to > rebuild and link to the openssl library; then test your code again. > > I don't use gnutls because it has given me problems. > >> I use LDAPv3, port 389 and the default LDAP_OPT_X_TLS_NEVER option. >> HAVE_TLS is defined but not LDAP_R_COMPILE. >> >> >> Thanks, >> >> Daniel > -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Using TLS
by Daniel Le 23 Jun '17

23 Jun '17

Hi, I'm seeing some critical error which causes the application program to exit/terminate when ldap_start_tls_s(LDAP-handle, NULL, NULL) is called. Tracing the code execution, ldap_start_tls_s => ldap_int_tls_start => tls_init, it appears the crash is at the statement "return impl->ti_tls_init()" in the tls_init function. Can someone give a pointer to help debugging this? And does OpenLDAP need to be linked to OpenSSL library for TLS to work? I use LDAPv3, port 389 and the default LDAP_OPT_X_TLS_NEVER option. HAVE_TLS is defined but not LDAP_R_COMPILE. Thanks, Daniel

2 3

Re: syncrepl fails after upgrade to openldap 2.4.45
by Quanah Gibson-Mount 23 Jun '17

23 Jun '17

--On Thursday, June 22, 2017 10:25 AM +0000 Juergen.Sprenger(a)swisscom.com wrote: > 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 don't see anything here configuring for syncrepl to find the CA for your server cert. I.e., something like tls_cacertdir=<path> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical