openldap-technical March 2017

openldap-technical@openldap.org

33 participants
56 discussions

Re: Syncrepl losing connection
by Quanah Gibson-Mount 02 Mar '17

02 Mar '17

--On Thursday, March 02, 2017 7:59 AM -0800 Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Thursday, March 02, 2017 1:08 PM +0200 Nick Milas > <nick(a)eurobjects.com> wrote: > > >> Since "only some systems support the customization of these values; the >> keepalive parameter is ignored otherwise", how can I make sure that this >> parameter has been configured successfully and is enabled on my system >> (CentOS 7)? I enabled "loglevel config stats sync"but I don't see any >> mention of configured syncrepl parameters during OpenLDAP start. > > Hi Nick, > > The keepalive parameter was added after the initial 2.4 release, and > after the current sections on replication in the admin guide were > written. It was created because I kept encountering issues at customer > sites where load balancers & packet shapers were closing the syncrepl > connection. Oh, and to answer your other question -- "keepalive" works on linux, but not necessarily other *nixes or Windows. So CentOS7 would be fine. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Syncrepl losing connection
by Quanah Gibson-Mount 02 Mar '17

02 Mar '17

--On Wednesday, March 01, 2017 8:48 AM +0200 Nick Milas <nick(a)eurobjects.com> wrote: > Hello, > > I have recently installed two syncrepl consumers using 2.4.44 on CentOS 7 > using LTB rpm packages. > > I am almost daily facing issues with consumers losing connection to the > master. I always have to restart the consumer in order to re-establish > connection. > > Note 1: These two consumers have replaced two older ones running 2.4.39 > LTB (and earlier versions) on CentOS 5 without any such issues. > > Note 2: Master is using 2.4.44 version as well (but on CentOS 5). > > Is this a known bug or I need to change/add something in the config when > using this OpenLDAP version so that the problem gets resolved? Have you tried setting the "keepalive" parameter in your syncrepl configs? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20)
by Quanah Gibson-Mount 02 Mar '17

02 Mar '17

--On Tuesday, February 14, 2017 5:04 PM -0800 "Paul B. Henson" <henson(a)acm.org> wrote: > On Tue, Feb 14, 2017 at 04:13:17PM -0800, Quanah Gibson-Mount wrote: > >> I have a test setup from a coworker who managed to trigger this to >> examine and see if I can push it into the test script. :) > > Cool, good to hear; it will be nice to track this down and quash it. I > don't know what it is about my environment that triggers it so often, > perhaps because we add/remove group members frequently. Hi Paul, In the ITS, you didn't provide your configuration -- I'm curious to see the order in which you load the overlays. In the initial report from Mark, he loads them in this order (on the primary data db): dynlist memberof syncprov accesslog So I'd like to know the order in which your overlays are loaded. Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 2

Re: 2.4.44 + ITS 8432 patch segfault in modify_add_values
by Quanah Gibson-Mount 01 Mar '17

01 Mar '17

--On Wednesday, February 22, 2017 7:29 PM -0800 "Paul B. Henson" <henson(a)acm.org> wrote: > On Mon, Feb 20, 2017 at 04:30:00PM -0800, Quanah Gibson-Mount wrote: > >> Ok, I can see if I can reproduce something like this. Do you have a >> link to the schema file in use that adds this attribute? > > https://spaces.internet2.edu/display/macedir/OpenLDAP+eduPerson Great, thanks. I want to look at the attribute rules. :) See if I can reproduce the crash in some way. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20)
by Quanah Gibson-Mount 01 Mar '17

01 Mar '17

--On Wednesday, February 22, 2017 7:21 PM -0800 "Paul B. Henson" <henson(a)acm.org> wrote: > On Tue, Feb 21, 2017 at 01:14:58PM -0800, Quanah Gibson-Mount wrote: > >> So I'd like to know the order in which your overlays are loaded. > > First there's > > database mdb > suffix cn=accesslog > overlay syncprov > > Then > > database mdb > suffix "dc=cpp,dc=edu" > overlay memberof > overlay syncprov > overlay accesslog > > > I don't recall ever seeing a requirement for a specific ordering of the > overlays. Should it matter? no. Can it matter? Maybe. I always load up syncprov first, accesslog second, anything else after that. It would be curious if reordering had any effect. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Syncrepl losing connection
by Nick Milas 01 Mar '17

01 Mar '17

Hello, I have recently installed two syncrepl consumers using 2.4.44 on CentOS 7 using LTB rpm packages. I am almost daily facing issues with consumers losing connection to the master. I always have to restart the consumer in order to re-establish connection. Note 1: These two consumers have replaced two older ones running 2.4.39 LTB (and earlier versions) on CentOS 5 without any such issues. Note 2: Master is using 2.4.44 version as well (but on CentOS 5). Is this a known bug or I need to change/add something in the config when using this OpenLDAP version so that the problem gets resolved? Below follows a log example from one of them (it includes my restart to re-establish connection): OpenLDAP Log excerpt: =========================================================================== Feb 28 16:19:20 vdns slapd[10375]: do_syncrep2: rid=353 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Feb 28 16:19:20 vdns slapd[10375]: do_syncrep2: rid=353 cookie=rid=353,csn=20170228140139.002723Z#000000#000#000000 Feb 28 16:19:20 vdns slapd[10375]: slap_queue_csn: queueing 0x7f9314225d90 20170228140139.002723Z#000000#000#000000 Feb 28 16:19:20 vdns slapd[10375]: slap_graduate_commit_csn: removing 0x7f9314225d90 20170228140139.002723Z#000000#000#000000 Feb 28 16:19:21 vdns slapd[10380]: [OK] OpenLDAP started Feb 28 18:19:23 vdns slapd[10375]: do_syncrep2: rid=353 (-1) Can't contact LDAP server Feb 28 18:19:23 vdns slapd[10375]: do_syncrepl: rid=353 rc -1 retrying (14 retries left) Feb 28 18:20:23 vdns slapd[10375]: do_syncrep2: rid=353 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Feb 28 20:20:37 vdns slapd[10375]: do_syncrep2: rid=353 (-1) Can't contact LDAP server Feb 28 20:20:37 vdns slapd[10375]: do_syncrepl: rid=353 rc -1 retrying (14 retries left) Feb 28 20:21:37 vdns slapd[10375]: do_syncrep2: rid=353 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Feb 28 22:21:52 vdns slapd[10375]: do_syncrep2: rid=353 (-1) Can't contact LDAP server Feb 28 22:21:52 vdns slapd[10375]: do_syncrepl: rid=353 rc -1 retrying (14 retries left) Feb 28 22:22:52 vdns slapd[10375]: do_syncrep2: rid=353 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Mar 1 00:23:06 vdns slapd[10375]: do_syncrep2: rid=353 (-1) Can't contact LDAP server Mar 1 00:23:06 vdns slapd[10375]: do_syncrepl: rid=353 rc -1 retrying (14 retries left) Mar 1 00:24:06 vdns slapd[10375]: do_syncrep2: rid=353 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Mar 1 02:24:21 vdns slapd[10375]: do_syncrep2: rid=353 (-1) Can't contact LDAP server Mar 1 02:24:21 vdns slapd[10375]: do_syncrepl: rid=353 rc -1 retrying (14 retries left) Mar 1 02:25:21 vdns slapd[10375]: do_syncrep2: rid=353 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Mar 1 04:25:35 vdns slapd[10375]: do_syncrep2: rid=353 (-1) Can't contact LDAP server Mar 1 04:25:35 vdns slapd[10375]: do_syncrepl: rid=353 rc -1 retrying (14 retries left) Mar 1 04:26:35 vdns slapd[10375]: do_syncrep2: rid=353 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Mar 1 06:26:50 vdns slapd[10375]: do_syncrep2: rid=353 (-1) Can't contact LDAP server Mar 1 06:26:50 vdns slapd[10375]: do_syncrepl: rid=353 rc -1 retrying (14 retries left) Mar 1 06:27:50 vdns slapd[10375]: do_syncrep2: rid=353 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Mar 1 08:17:54 vdns slapd[18585]: [INFO] Using /etc/default/slapd for configuration Mar 1 08:17:54 vdns slapd[18590]: [INFO] Halting OpenLDAP... Mar 1 08:17:54 vdns slapd[10375]: daemon: shutdown requested and initiated. Mar 1 08:17:54 vdns slapd[10375]: slapd shutdown: waiting for 1 operations/tasks to finish Mar 1 08:17:54 vdns slapd[10375]: slapd stopped. Mar 1 08:17:55 vdns slapd[18594]: [OK] OpenLDAP stopped after 1 seconds Mar 1 08:17:55 vdns slapd[18595]: [INFO] No data backup done Mar 1 08:17:55 vdns slapd[18607]: [INFO] Using /etc/default/slapd for configuration Mar 1 08:17:55 vdns slapd[18612]: [INFO] Launching OpenLDAP configuration test... Mar 1 08:17:56 vdns slapd[18626]: [OK] OpenLDAP configuration test successful Mar 1 08:17:56 vdns slapd[18637]: [INFO] No db_recover done Mar 1 08:17:56 vdns slapd[18638]: [INFO] Launching OpenLDAP... Mar 1 08:17:56 vdns slapd[18639]: [OK] File descriptor limit set to 1024 Mar 1 08:17:56 vdns slapd[18640]: @(#) $OpenLDAP: slapd 2.4.44 (Feb 15 2016 11:14:35) $#012#011clement@centos7.unix.example.com:/home/clement/build/BUILD/openldap-2.4.44/servers/slapd Mar 1 08:17:56 vdns slapd[18641]: slapd starting Mar 1 08:17:56 vdns slapd[18641]: do_syncrep2: rid=353 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Mar 1 08:17:56 vdns slapd[18641]: do_syncrep2: rid=353 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Mar 1 08:17:56 vdns slapd[18641]: do_syncrep2: rid=353 cookie=rid=353,csn=20170301060829.837823Z#000000#000#000000 Mar 1 08:17:56 vdns slapd[18641]: slap_queue_csn: queueing 0x7f33f4225d90 20170301060829.837823Z#000000#000#000000 Mar 1 08:17:56 vdns slapd[18641]: slap_graduate_commit_csn: removing 0x7f33f4225d90 20170301060829.837823Z#000000#000#000000 Mar 1 08:17:57 vdns slapd[18646]: [OK] OpenLDAP started =========================================================================== Configuration on this consumer: =========================================================================== include /usr/local/openldap/etc/openldap/schema/core.schema include /usr/local/openldap/etc/openldap/schema/cosine.schema include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema include /usr/local/openldap/etc/openldap/schema/nis.schema include /usr/local/openldap/etc/openldap/schema/eduperson.schema include /usr/local/openldap/etc/openldap/schema/postfix.schema include /usr/local/openldap/etc/openldap/schema/dyngroup.schema include /usr/local/openldap/etc/openldap/schema/misc.schema include /usr/local/openldap/etc/openldap/schema/ppolicy.schema include /usr/local/openldap/etc/openldap/schema/schac-20090326-1.4.0.schema include /usr/local/openldap/etc/openldap/schema/dnsdomain2.schema include /usr/local/openldap/etc/openldap/schema/proftpd-quota.schema include /usr/local/openldap/etc/openldap/schema/kerberos.schema include /usr/local/openldap/etc/openldap/schema/localemail.schema include /usr/local/openldap/etc/openldap/schema/entryaccess.schema include /usr/local/openldap/etc/openldap/schema/radius.schema pidfile /usr/local/openldap/var/run/slapd.pid argsfile /usr/local/openldap/var/run/slapd.args modulepath /usr/local/openldap/lib64 loglevel sync sizelimit unlimited timelimit unlimited TLSCACertificateFile /usr/local/openldap/etc/openldap/cacerts/DigiCertCA.crt TLSCertificateFile /usr/local/openldap/etc/openldap/cacerts/vdns_noa_gr-1058189.crt TLSCertificateKeyFile /usr/local/openldap/etc/openldap/cacerts/vdns_noa_gr-1058189.key TLSVerifyClient never database mdb suffix "dc=noa,dc=gr" rootdn "cn=Manager,dc=noa,dc=gr" rootpw {SSHA}<SECRET> include /usr/local/openldap/etc/openldap/acl.conf directory /usr/local/openldap/var/mdb maxsize 10737418240 index objectClass eq,pres index cn eq,pres,sub index uid eq,pres index ou eq,pres index owner eq index entryCSN,entryUUID eq index associatedDomain pres,eq,sub index dc eq syncrepl rid=353 provider=ldaps://ldap.noa.gr type=refreshAndPersist tls_reqcert=never retry="60 15 180 +" searchbase="dc=noa,dc=gr" schemachecking=off bindmethod=simple binddn="uid=syncuser,dc=noa,dc=gr" credentials="secret" database monitor access to * by dn.exact="cn=Manager,dc=noa,dc=gr" read by * none =========================================================================== Please let me know of any hint/advice to resolve this issue! Thanks in advance, Nick

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical March 2017