Re: Syncrepl losing connection
by Quanah Gibson-Mount
--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>
6 years, 1 month
Re: RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20)
by Quanah Gibson-Mount
--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>
6 years, 1 month
Re: 2.4.44 + ITS 8432 patch segfault in modify_add_values
by Quanah Gibson-Mount
--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>
6 years, 1 month
Re: RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20)
by Quanah Gibson-Mount
--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>
6 years, 1 month
Syncrepl losing connection
by Nick Milas
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
6 years, 1 month