Issues with Ppolicy Overlay and chaining (master/slave)
by Raul Hernandez
Hello!
I've been experiencing some issues with ppolicy overlay and chaining. I've
implemented a simple openldap master and consumer architecture.This
implementation works fine. I have data from the master, replicated into the
slave, and all writes sent to the slave (add/edit ous and users), are
forwarded to the master.
I've now added to this architecture ppolicy overlay (with
olcPPolicyForwardUpdates set to TRUE). When the slave receives a logon
failure, it should forward this to the master, so ppolicy overlay can set
pwdFailuretime and pwdAccountLockedTime.
This is not happening. Neither master nor slave, are setting
pwdFailuretime or pwdAccountLockedTime.
When debugging the slave, I get the following messages:
541875a7 conn=1010 op=0 BIND dn="cn=Lisa
Hayes,ou=Quality,dc=example,dc=com" method=128
541875a7 conn=1010 op=0 ldap_back_retry: retrying URI="ldap://ldapmaster.com"
DN="cn=syncrepluser,ou=security,dc=example,dc=com"
541875a7 conn=1010 op=0 RESULT tag=97 err=49 text=
541875a7 conn=1010 op=1 UNBIND
541875a7 conn=1010 fd=21 closed
I've been searching the Internet how to solve this issue without any luck.
can someone point me to the right direction? Here is my conf for
replication and chain in both master and slave:
#-----
# Master
#-----
dn: cn=module,cn=config
changetype: add
objectClass: olcModuleList
cn: module
olcModulePath: /usr/lib/ldap
olcModuleLoad: syncprov
dn: olcOverlay=syncprov,olcDatabase={1}hdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
#-----
# Slave
#-----
dn: cn=module,cn=config
changetype: add
objectClass: olcModuleList
cn: module
olcModulePath: /usr/lib/ldap
olcModuleLoad: syncprov
olcModuleLoad: back_ldap
dn: olcOverlay=syncprov,olcDatabase={1}hdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcSyncRepl
olcSyncRepl: rid=001 provider=ldap://ldapmaster.com
binddn="cn=syncReplUser,ou=Security,dc=example,dc=com" bindmethod=simple
credentials=secret searchbase="dc=example,dc=com" type=refreshAndPersist
scope=sub retry="5 10 10 +" timeout=1 sizelimit=unlimited schemachecking=on
-
add: olcUpdateRef
olcUpdateRef: ldap://ldapmaster.com
dn: olcOverlay=chain,olcDatabase={-1}frontend,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcChainConfig
olcOverlay: chain
olcChainReturnError: TRUE
dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
changetype: add
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: ldap
olcDbURI: ldap://ldapmaster.com
olcDbRebindAsUser: TRUE
olcDbIDAssertBind: bindmethod=simple
binddn="cn=syncReplUser,ou=Security,dc=example,dc=com" credentials=secret
mode=self flags=prescriptive,proxy-authz-non-critical
Thanks in advanced
9 years, 2 months
Re: Consumer replication 0 entries fetched - CSN problem?
by Josh Nielsen
Okay. Thank you for the information Quanah.
Regards,
Josh
On Tue, Sep 16, 2014 at 11:27 AM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote:
> --On Tuesday, September 16, 2014 11:38 AM -0500 Josh Nielsen
> <jnielsen(a)hudsonalpha.org> wrote:
>
>> Yes, I used distro packages for Centos 6; and yes, I understand your
>> point. I may have the luxury of building openldap from scratch for
>> LDAP02, though I don't have the redundancy (the point of this whole
>> exercise) that I need to reinstall LDAP01 by building it from scratch.
>> That was an unfortunate mistake in hindsight that I stuck with the
>> distro package there. I suppose to start over I would have to make a
>> new server and slapcat the LDAP01 config? How would I carry over the
>> existing DB entries without using replication? I'm still a novice when
>> it comes to OLC.
>>
>> As for the ACL, that was a result of my sloppy email editing. I
>> changed the name of the DNs. They actually match in my config. Once I
>> proof-of-concept the replication I will create replication-only user
>> DNs.
>>
>> But nothing looks overtly amiss with my CSNs or UUIDs?
>
>
> Hi Josh,
>
> 2.4.23 is known to have numerous bugs in sync replication. So even once you
> have your system configured correctly, there is no guarantee that your data
> will be correctly pushed out. I strongly advise you to read over the
> CHANGES file for everything fixed since 2.4.23 to the 2.4.40 release:
>
> <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob_plain;f=CH...>
>
> In addition, there's no requirement that you build OpenLDAP yourself. You
> can obtain current OpenLDAP builds from Symas (<https://symas.com/>) or the
> LTB project (<http://ltb-project.org/wiki/download#openldap>) for
> deployment.
>
> Regards,
> Quanah
>
>
>
> --
>
> Quanah Gibson-Mount
> Server Architect
> Zimbra, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
9 years, 2 months
Consumer replication 0 entries fetched - CSN problem?
by Josh Nielsen
Hello all,
Last year I switched from the slapd.conf to the OLC style config for
OpenLDAP and transitionally tested it by making the OLC server a
replication slave to the older LDAP server configured with slapd.conf.
Now I've disabled replication from that old server and am making the
OLC server (LDAP01 - version 2.4.23) the new master and threw up a new
VM called LDAP02 (2.4.23) to become the new sync replication
slave/consumer. Though I'm using multiple guides of varying detail the
simplest setup steps basically followed this article:
http://gagravarr.livejournal.com/145679.html.
I followed the same steps I thought I did for LDAP01, but despite the
fact that I see LDAP02 bind and try to fetch entries for replication
nothing is being fetched. The problem description is almost identical
to this person's issue:
http://www.openldap.org/lists/openldap-software/200911/msg00017.html
(with "nentries=0" in the replication log messages, but plenty of
entries found with an ldapsearch manually).
Though I think my setup situation is different than that person's, and
they were exporting using slapcat/slapadd (which I did for converting
my existing slapd.conf config to LDAP01 last year, but this time I
merely setup LDAP02 from scratch as a cn=config OLC server to begin
with), one of the follow-up responses to that email thread said this:
"The only correct usage of -w is when you have an LDIF produced by slapcat
on a database that was not being used with replication before, and so is missing
the contextCSN. But all the other operational attributes (entryUUID and
entryCSN in particular) are present and valid."
This made me wonder if the problem I'm seeing is because LDAP02 (or
LDAP01?) is somehow missing a contextCSN. I am seeing no "cookie"
messages associated with replication in my log.
Some of my config is below as well as the log messages I am seeing on
LDAP01 (edited domain & password). I did notice off-the-bat though
that I am missing an "olcDbIndex: entryUUID pres,eq" entry on LDAP02
where I have it on LDAP01. Is that a crucial setting for replication?
Lastly, I deleted the database files in /var/lib/ldap/ on LDAP02 and
restarted slapd once I had configured "olcSyncRepl" on LDAP02 to
ensure that I was starting from scratch.
-------
LDAP01's log entry for LDAP02's attempted connection looks like this:
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 fd=359 ACCEPT from
IP=192.168.21.60:46198 (IP=0.0.0.0:389)
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=0 STARTTLS
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=0 RESULT oid= err=0 text=
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 fd=359 TLS established
tls_ssf=256 ssf=256
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=1 BIND
dn="cn=root,dc=myerslab,dc=haib,dc=org" method=128
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=1 BIND
dn="cn=root,dc=myerslab,dc=haib,dc=org" mech=SIMPLE ssf=0
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=1 RESULT tag=97 err=0 text=
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=2 SRCH
base="dc=myerslab,dc=haib,dc=org" scope=2 deref=0
filter="(objectClass=*)"
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=2 SRCH attr=* +
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=2 SEARCH RESULT
tag=101 err=0 nentries=0 text=
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 op=3 UNBIND
Sep 15 16:29:07 ldap01 slapd[18869]: conn=1472 fd=359 closed
-------
LDAP02's /etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif:
dn: olcDatabase={1}bdb
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {1}bdb
olcSuffix: dc=mydomain,dc=org
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=admin,dc=mydomain,dc=org
olcRootPW::
olcSyncUseSubentry: FALSE
olcMonitoring: TRUE
olcDbDirectory: /var/lib/ldap
olcDbCacheSize: 50000
olcDbCheckpoint: 10240 720
olcSyncrepl: {0}rid=001 provider=ldap://ldap01.mydomain.org bindmethod=si
mple timeout=1 network-timeout=0 binddn="cn=root,dc=mydomain,dc=org"
credentials="ld4p3650" keepalive=0:0:0 starttls=yes filter="(objectclass=*)" s
earchbase="dc=mydomain,dc=org" scope=sub schemachecking=off type=refr
eshOnly interval=00:00:00:10 retry="5 5 300 5"
tls_cacert=/etc/openldap/certs/rootCA.cert
olcUpdateRef: ldap://ldap01.mydomain.org
olcMirrorMode: TRUE
olcDbNoSync: FALSE
olcDbDirtyRead: FALSE
olcDbIDLcacheSize: 0
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: loginShell pres,eq
olcDbIndex: sn pres,eq,sub
olcDbIndex: givenName pres,eq,sub
olcDbIndex: memberUid pres,eq,sub
olcDbIndex: nisMapName pres,eq,sub
olcDbIndex: nisMapEntry pres,eq,sub
olcDbLinearIndex: FALSE
olcDbMode: 0600
olcDbSearchStack: 16
olcDbShmKey: 0
olcDbCacheFree: 1
olcDbDNcacheSize: 0
structuralObjectClass: olcBdbConfig
entryUUID: 31e2c8b0-c0ec-1033-8c20-43a6f59853d5
creatorsName: cn=config
createTimestamp: 20140825214036Z
entryCSN: 20140912164223.814325Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20140912164223Z
-------
LDAP01's /etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif:
dn: olcDatabase={1}bdb
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {1}bdb
olcSuffix: dc=mydomain,dc=org
olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * no
ne
olcAccess: {1}to * by anonymous read
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=admin,dc=mydomain,dc=org
olcRootPW::
olcSyncUseSubentry: FALSE
olcMirrorMode: TRUE
olcMonitoring: TRUE
olcDbDirectory: /var/lib/ldap
olcDbCacheSize: 50000
olcDbCheckpoint: 10240 720
olcDbConfig: {0}# $OpenLDAP: pkg/ldap/servers/slapd/DB_CONFIG,v 1.3.2.4 2007/1
2/18 11:53:27 ghenry Exp $
olcDbConfig: {1}# Example DB_CONFIG file for use with slapd(8) BDB/HDB databas
es.
olcDbConfig: {2}#
olcDbConfig: {3}# See the Oracle Berkeley DB documentation
olcDbConfig: {4}# <http://www.oracle.com/technology/documentation/berkeley-d
b/db/ref/env/db_config.html>
olcDbConfig: {5}# for detail description of DB_CONFIG syntax and semantics.
olcDbConfig: {6}#
olcDbConfig: {7}# Hints can also be found in the OpenLDAP Software FAQ
olcDbConfig:: ezh9Iwk8aHR0cDovL3d3dy5vcGVubGRhcC5vcmcvZmFxL2luZGV4LmNnaT9maWxl
PTI+
olcDbConfig: {9}# in particular:
olcDbConfig: {10}# <http://www.openldap.org/faq/index.cgi?file=1075>
olcDbConfig: {11}
olcDbConfig: {12}# Note: most DB_CONFIG settings will take effect only upon re
building
olcDbConfig: {13}# the DB environment.
olcDbConfig: {14}
olcDbConfig: {15}# one 0.25 GB cache
olcDbConfig: {16}set_cachesize 0 268435456 1
olcDbConfig: {17}
olcDbConfig: {18}# Data Directory
olcDbConfig: {19}#set_data_dir db
olcDbConfig: {20}
olcDbConfig: {21}# Transaction Log settings
olcDbConfig: {22}set_lg_regionmax 262144
olcDbConfig: {23}set_lg_bsize 2097152
olcDbConfig: {24}#set_lg_dir logs
olcDbConfig: {25}
olcDbConfig: {26}# Note: special DB_CONFIG flags are no longer needed for "qui
ck"
olcDbConfig:: ezI3fSMgc2xhcGFkZCg4KSBvciBzbGFwaW5kZXgoOCkgYWNjZXNzIChzZWUgdGhl
aXIgLXEgb3B0aW9uKS4g
olcDbNoSync: FALSE
olcDbDirtyRead: FALSE
olcDbIDLcacheSize: 0
olcDbIndex: objectClass pres,eq
olcDbIndex: entryUUID pres,eq
olcDbIndex: entryCSN pres,eq
olcDbIndex: cn pres,eq,sub
olcDbIndex: uid pres,eq,sub
olcDbIndex: uidNumber pres,eq
olcDbIndex: gidNumber pres,eq
olcDbIndex: ou pres,eq,sub
olcDbIndex: mail pres,eq,sub
olcDbIndex: memberUid pres,eq,sub
olcDbIndex: sn pres,eq,sub
olcDbIndex: loginShell pres,eq
olcDbIndex: givenName pres,eq,sub
olcDbIndex: nisMapName pres,eq,sub
olcDbIndex: nisMapEntry pres,eq,sub
olcDbLinearIndex: FALSE
olcDbMode: 0600
olcDbSearchStack: 16
olcDbShmKey: 0
olcDbCacheFree: 1
olcDbDNcacheSize: 0
structuralObjectClass: olcBdbConfig
entryUUID: 727d260c-cc5c-1032-89cf-2fc7acd5ca31
creatorsName: cn=config
createTimestamp: 20131018161654Z
entryCSN: 20140915195740.431843Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20140915195740Z
------
Thanks,
Josh Nielsen
9 years, 2 months
ldappasswd usage problems
by Bruce Carleton
I'm having problems setting passwords with ldappasswd. It keeps
failing with a usage message. I've tried a bunch of different
arrangements of the command line arguments, but it keeps giving me a
usage message. Here's an example:
ldappasswd -s some_password \
-x -H ldapi:/// \
-D cn=admin,dc=example,dc=com -y secret.txt \
uid=some.user,ou=people,dc=example,dc=com
During one of my attempts I followed the order specified in the man
page. That didn't work either. I'm using the packaged (ldap-utils /
2.4.28-1.1ubuntu4.4) ldappasswd on Ubuntu 12.04.4 LTS. The specific
ldappasswd version follows:
$ ldappasswd -VV
ldappasswd: @(#) $OpenLDAP: ldappasswd (Sep 19 2013 22:39:03) $
buildd@panlong:/build/buildd/openldap-2.4.28/debian/build/clients/tools
(LDAP library: OpenLDAP 20428)
I'm feeling kind of stuck on this. I'm probably missing something
silly. Any suggestions?
Thanks,
--Bruce
9 years, 2 months
Returned mail: Data format error
by richm＠stanfordalumni.org
This message was undeliverable due to the following reason(s):
Your message was not delivered because the destination server was
unreachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.
Most likely there is a network problem that prevented delivery, but
it is also possible that the computer is turned off, or does not
have a mail system running right now.
Your message was not delivered within 5 days:
Mail server 46.146.14.227 is not responding.
The following recipients did not receive this message:
<openldap-technical(a)openldap.org>
Please reply to postmaster(a)openldap.org
if you feel this message to be in error.
9 years, 2 months
OpenLDAP crash when defining multiple olcDbURI for chaining
by Khosrow Ebrahimpour
Hello list,
I am trying to setup referral chaining in a multi-master setup. I can
setup chaining to one of the masters without any problems. And I can
perform a MOD operation that is then referral chased and performed on
the master.
However, when I define both masters the replica crashes when I do a MOD
operation.
Snippet of cn=config from the working example:
dn:
olcDatabase={1}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {1}ldap
olcDbStartTLS: start starttls=yes
olcDbIDAssertAuthzFrom: {0}*
olcDbRebindAsUser: FALSE
olcDbChaseReferrals: TRUE
olcDbTFSupport: no
olcDbProxyWhoAmI: FALSE
olcDbProtocolVersion: 3
olcDbSingleConn: FALSE
olcDbCancel: abandon
olcDbUseTemporaryConn: FALSE
olcDbConnectionPoolMax: 16
olcDbNoRefs: FALSE
olcDbNoUndefFilter: FALSE
olcDbURI: ldap://ldap-m1.example.com
olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical
bindmethod=simple timeout=0 network-timeout=0
binddn="cn=admin,dc=example,dc=com" credentials="secret" keepalive=0:0:0
starttls=yes tls_reqcert=allow
If I change olcDbURI to either of the entries below, the replica server
crashes
* olcDbURI: "ldap://ldap-m1.example.com,ldap://ldap-m2.example.com"
* olcDbURI: "ldap://ldap-m1.example.com ldap://ldap-m2.example.com"
According to slapd-ldap(5), the URI list can be comma or space separated.
I've turned on "args" and "trace" debugging to troubleshoot, but never
get any errors in the logs. I only see an attempt to chase the referral
followed by an immediate crash (see log snippet at the end of email).
Finally, I'm running OpenLDAP 2.4.31 on Ubuntu Trusty, but was also able
to replicate this same error on OpenLDAP 2.4.28 on Ubuntu Precise.
Any help is much appreciated.
--
Khosrow Ebrahimpour
Crash Log:
Sep 8 21:07:23 ldap-rep1 slapd[20947]: conn=1000 op=1 modifications:
Sep 8 21:07:23 ldap-rep1 slapd[20947]: replace: givenName
Sep 8 21:07:23 ldap-rep1 slapd[20947]: one value, length 1
Sep 8 21:07:23 ldap-rep1 slapd[20947]: conn=1000 op=1 MOD
dn="uid=user1,ou=people,dc=example,dc=com"
Sep 8 21:07:23 ldap-rep1 slapd[20947]: conn=1000 op=1 MOD attr=givenName
Sep 8 21:07:23 ldap-rep1 slapd[20947]:
bdb_dn2entry("uid=user1,ou=people,dc=example,dc=com")
Sep 8 21:07:23 ldap-rep1 slapd[20947]: =>
hdb_dn2id("ou=people,dc=example,dc=com")
Sep 8 21:07:23 ldap-rep1 slapd[20947]: <= hdb_dn2id: got id=0x6
Sep 8 21:07:23 ldap-rep1 slapd[20947]: =>
hdb_dn2id("uid=user1,ou=people,dc=example,dc=com")
Sep 8 21:07:23 ldap-rep1 slapd[20947]: <= hdb_dn2id: got id=0xe
Sep 8 21:07:23 ldap-rep1 slapd[20947]: entry_decode: ""
Sep 8 21:07:23 ldap-rep1 slapd[20947]: <= entry_decode()
Sep 8 21:07:23 ldap-rep1 slapd[20947]: send_ldap_result: conn=1000 op=1 p=3
Sep 8 21:07:23 ldap-rep1 slapd[20947]: send_ldap_result: err=10
matched="" text=""
Sep 8 21:07:23 ldap-rep1 slapd[20947]: send_ldap_result:
referral="ldap://ldap-m1.example.com/uid=user1,ou=people,dc=example,dc=com"
Sep 8 21:07:23 ldap-rep1 slapd[20947]: >>> dnPrettyNormal:
<uid=user1,ou=people,dc=example,dc=com>
Sep 8 21:07:23 ldap-rep1 slapd[20947]: <<< dnPrettyNormal:
<uid=user1,ou=people,dc=example,dc=com>,
<uid=user1,ou=people,dc=example,dc=com>
Sep 8 21:07:23 ldap-rep1 slapd[20947]: conn=1000 op=1 ldap_chain_op:
ref="ldap://ldap-m1.example.com/uid=user1,ou=people,dc=example,dc=com"
-> "ldap://ldap-m1.example.com"
Sep 8 21:09:02 ldap-rep1 slapd[21057]: @(#) $OpenLDAP: slapd (Ubuntu)
(Mar 17 2014 21:20:08) $
buildd@aatxe:/build/buildd/openldap-2.4.31/debian/build/servers/slapd
9 years, 2 months
LDAP_OPT_DESC historic
by Michael Ströder
HI!
What does it mean that there's the comment "historic" at constant
LDAP_OPT_DESC in ldap.h?
Is there another option value one should use to get the file descriptor of a
connection?
Ciao, Michael.
9 years, 2 months
difference between configuration file
by Gremaud Cyrill
Hello List,
I don’t understand the difference between /etc/ldap/ldap.conf and /etc/default/slapd
For exemple, what is the difference between URI and SLAPD_SERVICES ?
I want to authorise LDAP protocol only from localhost and only LDAPS for the external… How can I do this ?
thanks
9 years, 2 months
Multiple threads and mdb_dbi_open
by Harry B
Hello,
As per the documentation here
http://symas.com/mdb/doc/group__mdb.html#gac08cad5b096925642ca359a6d6f0562a
I see the following,
"This function must not be called from multiple concurrent transactions. A
transaction that uses this function must finish (either commit or abort)
before any other transaction may use this function."
This seems to imply that after one txn has begun on an environment, I
cannot create another txn or dbi until the first one has finished - that
doesn't seem to be right.
If I have multi-threaded app, what is the expected sequence for creation of
Environment, Transaction, and DBI handles?
Any help is appreciated.
--
Harry
9 years, 2 months
Re: Replication breaks and needs restart - version 2.4.30
by Raja T Nair
Hello Quanah,
Thanks for your suggestion. I will seriously consider upgrading my
installations.
For now, the issue seems resolved by setting TCP keepalive values in my
servers.
Regards,
Raja.
On 9 September 2014 22:44, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote:
> --On Tuesday, September 09, 2014 1:42 PM +0530 Raja T Nair <
> rtnair(a)gmail.com> wrote:
>
>
>>
>>
>>
>> Hello All,
>>
>>
>> I am running openldap-2.4.30 in multiple locations, and all are
>> replicating from a single Provider.
>>
>
> Upgrade to a current release, to start with. 2.4.30 is ancient, and
> numerous replication related bugs have been fixed since that release.
> Second, you may want to configure TCP keepalive settings in the syncrepl
> setup, as it seems like you have a device between the replicas and master
> that is timing out the connections. Hard to really know for sure, however.
>
> --Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Server Architect
> Zimbra, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
>
--
:^)
9 years, 2 months
