Syncrepl only partially working
by Joshua Schaeffer
Greetings all,
I'm trying to figure out why Syncrepl is only syncing part of my provider's database when I use GSSAPI to connect. Both my provider and consumer are on 2.4.40. Here are all the steps I'm taking:
My provider is working fine, I've been using it for months now without any issues. I added this to the provider:
dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpCheckpoint: 100 10
structuralObjectClass: olcSyncProvConfig
entryUUID: b32ac160-29e6-1036-8d0a-07ef98fd592e
creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
createTimestamp: 20161019012544Z
olcSpSessionlog: 100
entryCSN: 20161024233803.817199Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20161024233803Z
I also indexed entryCSN and entryUUID on the provider. I have olcAuthzRegexp setup on the provider as well.
olcAuthzRegexp: {0}"uid=admin,cn=harmonywave.com,cn=GSSAPI,cn=auth" "cn=admin,dc=harmonywave,dc=com"
olcAuthzRegexp: {1}"uid=ldap/admin,cn=harmonywave.com,cn=GSSAPI,cn=auth" "dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth"
olcAuthzRegexp: {2}"uid=syncprov,cn=harmonywave.com,cn=GSSAPI,cn=auth" "cn=syncprov,dc=harmonywave,dc=com" #not using this.
olcAuthzRegexp: {3}"uid=.*\/admin,cn=harmonywave.com,cn=GSSAPI,cn=auth" "cn=admin,dc=harmonywave,dc=com"
olcAuthzRegexp: {4}"uid=host\/([^.]*).harmonywave.com,cn=harmonywave.com,cn=GSSAPI,cn=auth" "cn=$1+ipHostNumber=.*,ou=Hosts,dc=harmonywave,dc=com"
olcAuthzRegexp: {5}"uid=([^/]*),cn=harmonywave.com,cn=GSSAPI,cn=auth" "uid=$1,ou=End Users,ou=People,dc=harmonywave,dc=com"
On the consumer I have slapd installed. The first thing I did was change the olcSuffix on my database. I'm not sure if this is required or not.
dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcSuffix
olcSuffix: dc=harmonywave,dc=com
-
replace: olcRootDN
olcRootDN: cn=admin,dc=harmonywave,dc=com
Then I'm adding my ldap keytab for the consumer.
kadmin: ktadd -k /etc/ldap/ldap.keytab ldap/consumer.harmonywave.com
consumer: ~# chown openldap:openldap /etc/ldap/ldap.keytab
consumer: ~# chmod 0640 /etc/ldap/ldap.keytab
I edited my /etc/default/slapd file and pointed the KRB5_KTNAME environment variable to the new keytab then restarted slapd. Next I installed kstart and created a ticket cache.
consumer: ~# k5start -U -f /etc/ldap/ldap.keytab -K 10 -l 24h -k /tmp/krb5cc_108 -o openldap -b
I can see the ldap service's keytab with klist.
consumer: ~# klist /tmp/krb5cc_108
Ticket cache: FILE:/tmp/krb5cc_108
Default principal: ldap/koprulu.harmonywave.com(a)HARMONYWAVE.COM
Valid starting Expires Service principal
10/28/2016 21:18:14 10/29/2016 07:18:14 krbtgt/HARMONYWAVE.COM(a)HARMONYWAVE.COM
renew until 10/29/2016 21:18:14
Then I add my olcSaslRealm
dn: cn=config
changetype: modify
add: olcSaslRealm
olcSaslRealm: HARMONYWAVE.COM
Here is what my database looks like right before I add olcSyncrepl:
dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /var/lib/ldap
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonym
ous auth by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by * read
olcLastMod: TRUE
olcRootPW:: ...
olcDbCheckpoint: 512 30
olcDbMaxSize: 1073741824
structuralObjectClass: olcMdbConfig
entryUUID: 9a091324-2e84-1036-8b7a-73db8891632a
creatorsName: cn=admin,cn=config
createTimestamp: 20161024222607Z
olcSuffix: dc=harmonywave,dc=com
olcRootDN: cn=admin,dc=harmonywave,dc=com
olcDbIndex: cn,uid eq
olcDbIndex: entryCSN eq
olcDbIndex: entryUUID eq
olcDbIndex: member,memberUid eq
olcDbIndex: objectClass eq
olcDbIndex: uidNumber,gidNumber eq
entryCSN: 20161029033105.691204Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20161029033105Z
then I add olcSyncrepl to the consumer.
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcSyncrepl
olcSyncrepl: {0}rid=000
provider=ldap://provider.harmonywave.com
type=RefreshAndPersist
retry="30 10 1800 +"
searchbase="dc=harmonywave,dc=com"
bindmethod=sasl
saslmech=GSSAPI
starttls=critical
tls_cacert=/etc/ssl/certs/ca.harmonywave.com.pem
tls_reqcert=demand
After that I slapcat on the consumer and I only see about 1/3 of my data from the provider. When I watch the log on the provider this is what I get:
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 fd=36 ACCEPT from IP=10.1.30.19:55992 (IP=0.0.0.0:389)
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=0 STARTTLS
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=0 RESULT oid= err=0 text=
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 fd=36 TLS established tls_ssf=128 ssf=128
Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43768 SRCH base="dc=harmonywave,dc=com" scope=2 deref=0 filter="(&(|(objectClass=krbPrincipalAux)(objectClass=krbPrincipal))(krbPrincipalName=krbtgt/HARMONYWAVE.COM(a)HARMONYWAVE.COM))"
Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43768 SRCH attr=krbprincipalname krbcanonicalname objectclass krbprincipalkey krbmaxrenewableage krbmaxticketlife krbticketflags krbprincipalexpiration krbticketpolicyreference krbUpEnabled krbpwdpolicyreference krbpasswordexpiration krbLastFailedAuth krbLoginFailedCount krbLastSuccessfulAuth krbLastPwdChange krbLastAdminUnlock krbExtraData krbObjectReferences krbAllowedToDelegateTo
Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43768 SEARCH RESULT tag=101 err=0 nentries=1 text=
Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43769 SRCH base="dc=harmonywave,dc=com" scope=2 deref=0 filter="(&(|(objectClass=krbPrincipalAux)(objectClass=krbPrincipal))(krbPrincipalName=ldap/baneling.harmonywave.com(a)HARMONYWAVE.COM))"
Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43769 SRCH attr=krbprincipalname krbcanonicalname objectclass krbprincipalkey krbmaxrenewableage krbmaxticketlife krbticketflags krbprincipalexpiration krbticketpolicyreference krbUpEnabled krbpwdpolicyreference krbpasswordexpiration krbLastFailedAuth krbLoginFailedCount krbLastSuccessfulAuth krbLastPwdChange krbLastAdminUnlock krbExtraData krbObjectReferences krbAllowedToDelegateTo
Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43769 SEARCH RESULT tag=101 err=0 nentries=1 text=
Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43770 SRCH base="dc=harmonywave,dc=com" scope=2 deref=0 filter="(&(|(objectClass=krbPrincipalAux)(objectClass=krbPrincipal))(krbPrincipalName=ldap/koprulu.harmonywave.com(a)HARMONYWAVE.COM))"
Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43770 SRCH attr=krbprincipalname krbcanonicalname objectclass krbprincipalkey krbmaxrenewableage krbmaxticketlife krbticketflags krbprincipalexpiration krbticketpolicyreference krbUpEnabled krbpwdpolicyreference krbpasswordexpiration krbLastFailedAuth krbLoginFailedCount krbLastSuccessfulAuth krbLastPwdChange krbLastAdminUnlock krbExtraData krbObjectReferences krbAllowedToDelegateTo
Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43770 SEARCH RESULT tag=101 err=0 nentries=1 text=
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=1 BIND dn="" method=163
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=1 RESULT tag=97 err=14 text=SASL(0): successful result:
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=2 BIND dn="" method=163
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=2 RESULT tag=97 err=14 text=SASL(0): successful result:
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=3 BIND dn="" method=163
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=3 BIND authcid="ldap/koprulu.harmonywave.com(a)HARMONYWAVE.COM" authzid="ldap/koprulu.harmonywave.com(a)HARMONYWAVE.COM"
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=3 BIND dn="uid=ldap/koprulu.harmonywave.com,cn=harmonywave.com,cn=gssapi,cn=auth" mech=GSSAPI sasl_ssf=56 ssf=128
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=3 RESULT tag=97 err=0 text=
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=4 SRCH base="dc=harmonywave,dc=com" scope=2 deref=0 filter="(objectClass=*)"
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=4 SRCH attr=* +
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=5 UNBIND
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 fd=36 closed
The only thing I really notice from this is near the end of the file. It when it searches the base with attributes "*+", but then immediately unbinds. I've seen people stating that authzid is required, but when I don't provide it I still get a partial sync, so I'm not sure about this. I've restored my consumer to a clean install of slapd and repeated the above steps with minor variations several times but the consumer always syncs the exact same amount of data and then seems to stop.
Any help to point me in the right direction would be appreciated.
Thanks,
Joshua Schaeffer
**
8 years, 8 months
RE: Multi Master OpenLdap.
by arun.sasi1＠wipro.com
Thank you very much Eli for concidering my issue. Here is my scenario...
I couldn’t find any abnormality in log files and also I never seen any deletion logs in the server. Slapd will go for hang and some ID`s will get disappear same will be replicate to slaves too. Mainly Groups and Computer accounts
I can see some UNBIND and connection lost logs from one server and another multimaster server from
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138411 op=24 SEARCH RESULT tag=101 err=32 nentries=0 text=
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138424 op=12 SRCH base="ou=Groups,dc=emb,dc=slb,dc=com" scope=2 deref=0 filter="(&(objectClass=sambaGroupMapping)(gidNumber=65534))"
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138424 op=12 SRCH attr=gidNumber sambaSID sambaGroupType sambaSIDList description displayName cn objectClass
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138424 op=12 SEARCH RESULT tag=101 err=0 nentries=0 text=
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138415 op=21 SRCH base="sambaDomainName=EMB,sambaDomainName=emb,dc=emb,dc=slb,dc=com" scope=2 deref=0 filter="(&(objectClass=sambaTrustedDomainPassword)(sambaDomainName=emb))"
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138415 op=21 SEARCH RESULT tag=101 err=32 nentries=0 text=
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138385 op=46 SRCH base="ou=Groups,dc=emb,dc=slb,dc=com" scope=2 deref=0 filter="(&(objectClass=sambaGroupMapping)(|(displayName=test)(cn=test)))"
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138385 op=46 SRCH attr=gidNumber sambaSID sambaGroupType sambaSIDList description displayName cn objectClass
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: <= bdb_equality_candidates: (displayName) not indexed
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: <= bdb_equality_candidates: (cn) not indexed
Jul 11 04:07:53 gb0135embldap01 slapd[21335]: @(#) $OpenLDAP: slapd 2.4.15 (Mar 19 2009 10:07:59) $ ^Ibuildd@yellow:/build/buildd/openldap-2.4.15/debian/build/servers/slapd
Jul 11 04:07:54 gb0135embldap01 slapd[21337]: slapd starting
Jul 11 04:07:54 gb0135embldap01 slapd[21337]: conn=0 fd=23 ACCEPT from IP=[::1]:57016 (IP=[::]:389)
Jul 11 04:07:54 gb0135embldap01 slapd[21337]: conn=1 fd=24 ACCEPT from IP=134.32.44.37:40763 (IP=0.0.0.0:389)
OLCDATABSE
dn: olcDatabase={1}hdb
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=emb,dc=slb,dc=com
olcAccess: {0}to attrs=userPassword,shadowLastChange,sambaLMPassword,sambaNTPassword
by dn="cn=admin,dc=emb,dc=slb,dc=com" write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=136.250.9.48 write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=163.185.18.238 write
by anonymous auth by self write
by * none
olcAccess: {1}to dn.base="" by * read
#Enable Local Admin to add users in the Group and also SunOne to add users to country groups
olcAccess: {2}to dn.subtree="ou=groups,dc=emb,dc=slb,dc=com"
by set="user/uid & [cn=group-admin,ou=SuperGroups,dc=emb,dc=slb,dc=com]/memberuid" write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=136.250.9.48 write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=163.185.18.238 write
by * read
#Enable Local Admin to add computers
olcAccess: {3}to dn.subtree="ou=Computers,dc=emb,dc=slb,dc=com"
by set="user/uid & [cn=group-admin,ou=SuperGroups,dc=emb,dc=slb,dc=com]/memberuid" write
by * read
#Enable shell-admin to set up local user access
olcAccess: {4}to attrs=loginShell,homeDirectory
by set="user/uid & [cn=shell-admin,ou=SuperGroups,dc=emb,dc=slb,dc=com]/memberuid" write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=136.250.9.48 write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=163.185.18.238 write
by * read
#Enable write access to account sun-one-replication for sun ldap replication.
olcAccess: {5}to *
by dn="cn=admin,dc=emb,dc=slb,dc=com" write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=136.250.9.48 write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=163.185.18.238 write
by * read
olcLastMod: TRUE
olcDbCheckpoint: 512 30
olcDbConfig: {0}set_cachesize 0 2097152 0
olcDbConfig: {1}set_lk_max_objects 1500
olcDbConfig: {2}set_lk_max_locks 1500
olcDbConfig: {3}set_lk_max_lockers 1500
olcDbIndex: objectClass eq
olcDbIndex: entryUUID eq
olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: loginShell eq
olcDbIndex: uid eq,pres,sub
olcDbIndex: memberUid eq,pres,sub
olcDbIndex: uniqueMember eq,pres
olcDbIndex: sambaSID eq
olcDbIndex: sambaPrimaryGroupSID eq
olcDbIndex: sambaGroupType eq
olcDbIndex: sambaSIDList eq
olcDbIndex: sambaDomainName eq
olcDbIndex: default sub
structuralObjectClass: olcHdbConfig
entryUUID: f479600a-5f34-102f-8ddd-3ff046e70702
creatorsName: cn=admin,cn=config
createTimestamp: 20100928101442Z
olcRootDN: cn=admin,dc=emb,dc=slb,dc=com
olcSyncrepl: {0}rid=003 provider=ldap://gb0135embldap01.emb.slb.com binddn="cn
=admin,dc=emb,dc=slb,dc=com" bindmethod=simple credentials=Bsl@121z searchbas
e="dc=emb,dc=slb,dc=com" type=refreshOnly interval=00:00:00:10 retry="5 5 300
5" timeout=1 starttls=yes
olcSyncrepl: {1}rid=004 provider=ldap://ae0042embldap01.emb.slb.com binddn="cn
=admin,dc=emb,dc=slb,dc=com" bindmethod=simple credentials=Bsl@121z searchbas
e="dc=emb,dc=slb,dc=com" type=refreshOnly interval=00:00:00:10 retry="5 5 300
5" timeout=1 starttls=yes
olcMirrorMode: TRUE
entryCSN: 20100928191927.932499Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20100928191927Z
Ldap Version
@(#) $OpenLDAP: slapd 2.4.15 (Mar 19 2009 10:07:59) $
Operating system
Distributor ID: Ubuntu
Description: Ubuntu 9.04
Release: 9.04
Codename: jaunty
Thanks,
-Arun
-----Original Message-----
From: E.S. Rosenberg [mailto:esr@g.jct.ac.il]
Sent: Monday, July 11, 2011 12:58 PM
To: Arun Sasi V (WI01 - Manage IT)
Cc: openldap-technical(a)openldap.org
Subject: Re: Multi Master OpenLdap.
Have you tried raising the loglevel?
Are the schemas the same between the servers?
Is time in sync between the servers?
What versions are you dealing with?
You don't provide a lot of info and most of us are not clairvoyant....
Regards,
Eli
2011/7/11 <arun.sasi1(a)wipro.com>:
>
>
>
>
> Thanks,
>
> -Arun
>
>
>
> From: Arun Sasi V (WI01 - Manage IT)
> Sent: Wednesday, July 06, 2011 5:46 PM
> To: 'openldap-technical(a)openldap.org'
> Subject: Multi Master OpenLdap.
>
>
>
> Hello Team,
>
>
>
> I have configured Multi-master Mirror mode replica setup in our environment.
> We have 3 regions slave Ldap server which is read only and two location we
> have configured as mirror mode replica Ldap. My problem here is…
>
>
>
> Master Ldap is going hang some times and some ID`s are disappearing from the
> master server. I couldn’t find any logs over there for why ID`s are
> disappearing and also why Ldap is going hung state.
>
>
>
> Thanks & Regards,
>
> Arun Sasi V
>
> Please do not print this email unless it is absolutely necessary.
>
> The information contained in this electronic message and any attachments to
> this message are intended for the exclusive use of the addressee(s) and may
> contain proprietary, confidential or privileged information. If you are not
> the intended recipient, you should not disseminate, distribute or copy this
> e-mail. Please notify the sender immediately and destroy all copies of this
> message and any attachments.
>
> WARNING: Computer viruses can be transmitted via email. The recipient should
> check this email and any attachments for the presence of viruses. The
> company accepts no liability for any damage caused by any virus transmitted
> by this email.
>
> www.wipro.com
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com
13 years, 11 months
TLS negotiation failure
by aRaviNd
Hi All,
I am trying to debug an issue related to Chef-manage WebUI trying to
authenticate users using LDAP. Authentication was working fine but after
upgrading the LDAP server to the latest version of the OS we are getting
authentication failures below are the errors showing in the log
Jul 13 20:26:52 ldap.local slapd[18572]: connection_get(14)
Jul 13 20:26:52 ldap.local slapd[18572]: connection_get(14): got connid=1003
Jul 13 20:26:52 ldap.local slapd[18572]: connection_read(14): checking for
input on id=1003
Jul 13 20:26:52 ldap.local slapd[18572]: op tag 0x77, time 1657744012
Jul 13 20:26:52 ldap.local slapd[18572]: conn=1003 op=0 do_extended
Jul 13 20:26:52 ldap.local slapd[18572]: conn=1003 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Jul 13 20:26:52 ldap.local slapd[18572]: do_extended:
oid=1.3.6.1.4.1.1466.20037
Jul 13 20:26:52 ldap.local slapd[18572]: conn=1003 op=0 STARTTLS
Jul 13 20:26:52 ldap.local slapd[18572]: send_ldap_extended: err=0 oid=
len=0
Jul 13 20:26:52 ldap.local slapd[18572]: send_ldap_response: msgid=0
tag=120 err=0
Jul 13 20:26:52 ldap.local slapd[18572]: conn=1003 op=0 RESULT oid= err=0
text=
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: activity on 1 descriptor
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: activity on:
Jul 13 20:26:52 ldap.local slapd[18572]:
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: epoll: listen=7
active_threads=0 tvp=NULL
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: epoll: listen=8
active_threads=0 tvp=NULL
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: epoll: listen=9
active_threads=0 tvp=NULL
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: epoll: listen=10
active_threads=0 tvp=NULL
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: epoll: listen=11
active_threads=0 tvp=NULL
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: activity on 1 descriptor
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: activity on:
Jul 13 20:26:52 ldap.local slapd[18572]: 14r
Jul 13 20:26:52 ldap.local slapd[18572]:
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: read active on 14
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: epoll: listen=7
active_threads=0 tvp=NULL
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: epoll: listen=8
active_threads=0 tvp=NULL
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: epoll: listen=9
active_threads=0 tvp=NULL
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: epoll: listen=10
active_threads=0 tvp=NULL
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: epoll: listen=11
active_threads=0 tvp=NULL
Jul 13 20:26:52 ldap.local slapd[18572]: connection_get(14)
Jul 13 20:26:52 ldap.local slapd[18572]: connection_get(14): got connid=1003
Jul 13 20:26:52 ldap.local slapd[18572]: connection_read(14): checking for
input on id=1003
Jul 13 20:26:52 ldap.local slapd[18572]: connection_read(14): TLS accept
failure error=-1 id=1003, closing
Jul 13 20:26:52 ldap.local slapd[18572]: connection_closing: readying
conn=1003 sd=14 for close
Jul 13 20:26:52 ldap.local slapd[18572]: connection_close: conn=1003 sd=14
Jul 13 20:26:52 ldap.local slapd[18572]: =>ldap_back_conn_destroy: fetching
conn 1003
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: removing 14
Jul 13 20:26:52 ldap.local slapd[18572]: conn=1003 fd=14 closed (TLS
negotiation failure)
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: activity on 1 descriptor
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: activity on::
We are not seeing the error while connecting to OpenLDAP servers using
OpenSSL or LDAP client tools. How can we debug further to see why the
server was not able to complete TLS negotiation?
Package versions are
openldap-2.4.44-25.el7_9.x86_64
openssl-1.0.2k-25.el7_9.x86_64
kernel-3.10.0-1160.66.1.el7.x86_64
Regards,
Aravind M D
2 years, 11 months
2.5.7 - bind err=49 after a userPassword and pwdChangedTime update
by Dave Macias
Hello,
Happy Friday!
I have a script that defaults the password to the user's username and then
it sets the pwdChangedTime so far back that pwdMaxAge: 62208000 triggers.
In 2.5.7 before I change the pwdChangedTime i MUST do a simple bind with
dn/password before I can apply the new pwdChangedTime. I say in 2.5.7 bc in
2.4.59 i dont see this behavior.
So my flow goes as follows:
ldappasswd <newpass>
ldapmodify <newPwdChangedTime> (pwdChangedTime: 20191008133434Z)
ssh with new <newpass>
Oct 8 09:17:06 localhost slapd[1380194]: conn=1199 op=2 BIND
dn="uid=davetest,ou=People,dc=domain,dc=net" method=128
Oct 8 09:17:06 localhost slapd[1380194]: conn=1199 op=2 RESULT tag=97
err=49 qtime=0.000026 etime=0.000262 text=
Flow i have to do so that bind works:
ldappasswd <newpass>
ldapsearch -D userdn -w <newpass> &/dev/null
ldapmodify <newPwdChangedTime> (pwdChangedTime: 20191008133434Z)
ssh with new <newpass>
Oct 8 09:29:11 localhost slapd[1380194]: conn=1264 op=2 BIND
dn="uid=davetest,ou=People,dc=domain,dc=net" mech=SIMPLE bind_ssf=0 ssf=256
Oct 8 09:29:11 localhost slapd[1380194]: fe_op_lastbind: old
pwdLastSuccess value=20211008132909Z 2s ago
Oct 8 09:29:11 localhost slapd[1380194]: ppolicy_bind: Entry
uid=davetest,ou=People,dc=domain,dc=net has an expired password: 0 grace
logins
Oct 8 09:29:11 localhost slapd[1380194]: conn=1264 op=2 RESULT tag=97
err=49 qtime=0.000016 etime=0.002915 text=
Oct 8 09:29:11 localhost slapd[1380194]: conn=1264 op=3 UNBIND
Oct 8 09:29:11 localhost slapd[1380194]: conn=1264 fd=15 closed
Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 fd=15 ACCEPT from IP=
127.0.0.1:34044 (IP=0.0.0.0:389)
Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=0 STARTTLS
Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=0 RESULT oid= err=0
qtime=0.000029 etime=0.000113 text=
Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 fd=15 TLS established
tls_ssf=256 ssf=256 tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384
Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=1 SRCH base=""
scope=0 deref=0 filter="(objectClass=*)"
Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=1 SRCH attr=*
altServer namingContexts supportedControl supportedExtension
supportedFeatures supportedLDAPVersion supportedSASLMechanisms
domainControllerFunctionality defaultNamingContext lastUSN
highestCommittedUSN
Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=1 SEARCH RESULT
tag=101 err=0 qtime=0.000016 etime=0.000228 nentries=1 text=
Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=2 BIND
dn="uid=davetest,ou=People,dc=domain,dc=net" method=128
Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=2 BIND
dn="uid=davetest,ou=People,dc=domain,dc=net" mech=SIMPLE bind_ssf=0 ssf=256
Oct 8 09:29:14 localhost slapd[1380194]: fe_op_lastbind: old
pwdLastSuccess value=20211008132911Z 3s ago
Oct 8 09:29:14 localhost slapd[1380194]: ppolicy_bind: Entry
uid=davetest,ou=People,dc=domain,dc=net has an expired password: 0 grace
logins
Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=2 RESULT tag=97
err=49 qtime=0.000016 etime=0.002904 text=
Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=3 EXT
oid=1.3.6.1.4.1.4203.1.11.1
Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=3 PASSMOD
id="uid=davetest,ou=People,dc=domain,dc=net" old new
Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=3 RESULT oid= err=0
qtime=0.000016 etime=0.002618 text=
Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=4 UNBIND
Is this expected behavior?
Thank you,
Dave
3 years, 8 months
Re: Dovecot can't connect to openldap over starttls
by info＠gwarband.de
Am 2017-03-20 14:29, schrieb Dan White:
> On 03/19/17 09:07 +0100, info(a)gwarband.de wrote:
>> Am 2017-03-19 01:09, schrieb Dan White:
>>>>>>>> On 03/17/2017 04:27 PM, info(a)gwarband.de wrote:
>>>>>>>>> https://gwarband.de/openldap/dovecot.log
>>>
>>> Mar 11 11:18:26 s1 dovecot: auth: Debug: Read auth token secret from
>>> /var/run/dovecot/auth-token-secret.dat
>>> Mar 11 11:18:26 s1 dovecot: auth: Error: LDAP: ldap_start_tls_s()
>>> failed: Connect error
>>> Mar 11 11:18:26 s1 dovecot: auth: Error: LDAP: ldap_start_tls_s()
>>> failed: Connect error
>>> Mar 11 11:18:26 s1 dovecot: auth: Debug: auth client connected
>>> (pid=27177)
>>> Mar 11 11:18:33 s1 dovecot: imap-login: Disconnected (no auth
>>> attempts in 7 secs): user=<>, rip=149.172.171.148, lip=188.68.37.50,
>>> session=<gcDtzHFKbwCVrKuU>
>>>
>>>>>>>>> https://gwarband.de/openldap/dovecot-ldap.conf
>>>
>>> uris = ldap://ldap.gwarband.de
>>> dn = cn=T000000002,ou=tech,dc=gwarband,dc=de
>>> dnpass = secret
>>> tls = yes
>>> tls_ca_cert_file = /etc/ssl/certs/LetsEncrypt.pem
>>> auth_bind = yes
>>> ldap_version = 3
>>> base = dc=gwarband,dc=de
>>> scope = subtree
>>> user_attrs =
>>> mail=maildir:/var/vmail/%{ldap:mailbox},uid=vmail,gid=vmail
>>> user_filter =
>>> (&(email=%u)(memberOf=cn=mailbox,ou=application,ou=groups,dc=gwarband,dc=de))
>>> pass_attrs = email=user
>>> pass_filter =
>>> (&(email=%u)(memberOf=cn=mailbox,ou=application,ou=groups,dc=gwarband,dc=de))
>>>
>>>>>>> https://gwarband.de/openldap/openldap.conf
>>>
>>> # Certificate
>>> TLSCACertificateFile /etc/ssl/certs/LetsEncrypt.pem
>>> TLSCertificateFile /etc/ssl/certs/gwarbandDE_LDAP.pem
>>> TLSCertificateKeyFile /etc/ssl/certs/gwarbandDE_LDAP.key
>>> TLSCipherSuite
>>> SECURE128:-ARCFOUR-128:-CAMELLIA-128-CBC:-3DES-CBC:-CAMELLIA-128-GCM
>>> TLSProtocolMin 3.1
>>> TLSVerifyClient never
>
> # Read slapd.conf(5) for possible values
> loglevel 256
>
> There are more verbose options.
>
> # Include ACLs
> include /etc/ldap/acl.conf
>
>>> What are the contents of /etc/ldap/ldap.conf?
>>
>> The ldap.conf has no difference to the dovecot-ldap.conf.
>> See: https://gwarband.de/openldap/ldap.conf
>> The point "TLS_REQCERT" is in both confs "demand". I've changed it
>> after that.
>>
>> The ldapsearch command works also under the user "dovecot"
>> See: https://gwarband.de/openldap/ldapsearch-dovecot.log
>>
>> ~$ ldapsearch -x -ZZ -D "cn=admin,dc=gwarband,dc=de" -W "cn=mailbox"
>
> There is a difference in your binding DN.
>
> Debug Dovecot's implementation of ldap_start_tls_s().
The loglevel was manually edited to -1 ("any") and the log shows the
output of this loglevel.
Yes the binding DN is diffrent, but I have also tried the
"cn=T000000002,ou=tech,dc=gwarband,dc=de" with no success.
I don't have any idea how to set a higher debug level to dovecot. In my
opinion I have the highest. So I can't deliver a greater log.
8 years, 3 months
Re: Slapd Security based on port
by harry.jede＠arcor.de
Chris Jackson wrote:
> On Feb 11, 2011, at 09:50 AM, Chris Jackson wrote:
>
> Is it possible to prevent anonymous and unauthenticated binds to
> ldaps:// 636 but allow them on ldap:// 389?
>
> I want to allow staff to query my ldaps:// outside of my network
> while requiring them to login to do so but allow anyone to bind
> (anonymous, unauthenticated, or authenticated) internally on ldaps//:
> 389.
>
> I know:
> Anonymous bind can be disabled by "disallow bind_anon" and
> Unauthenticated bind mechanism is disabled by default. But if I use
> "disallow bind_anon it stops in on both ports.
Sure, this are global directives.
> I want to stop it just on ldaps://.
You don't need ldaps:// in your local network? May be.
I think a easier solution is to identify your Internet Gateway by IP.
> Chris Jackson
>
>
> On Feb 14, 2011, at 11:28 AM, Aaron Richton wrote:
>
> Stopping users that are "unauthenticated" makes no sense;
> everything's unauthenticated at time=0. You might as well stop slapd
> if you want a 100% inability to serve data.
>
> You can deny anonymous users that aren't plaintext, including any
> ldaps:/// connections, with something like:
>
> access to *
> by anonymous ssf=0 transport_ssf=0 tls_ssf=0 sasl_ssf=0 none break
> by anonymous none
>
> early on in your ACL stanzas. I'm pretty sure this'll deny anonymous
> StartTLS users on 389, though; not sure if that's what you want. I
> can't think of any way to use the slapd access language to
> differentiate based on listeners, which would probably be the most
> elegant way to handle what you asked. To be fair, this entire
> exercise seems really odd from where I sit -- are you positive that
> this will have the desired effect? (If somebody out in Peru is
> permitted to connect in unencrypted and make anonymous queries, why
> not allow them to make those same queries encrypted? What's the
> difference?)
>
> here is a scenario:
>
> Site has a ldap server on ldap://389. Firewall blocks access to 389
> from internet. Everyone queries the ldap via anonymous binds. Site
> would like to allow staff the ability to query the ldap from outside
> the firewall. This would be done via ldaps:// 636 to users who have
> authenticated via username/password. They do not want to allow
> anonymous queries outside the firewall.
>
> Using the "disallow bind_anon" would prevent anon binds on both
> ldap:// and ldaps://. This would break the inside machines ability
> to query. If we dont use "disallow bind_anon" then machines outside
> of the firewall could query the ldap.
>
> ---Is the only option for them to setup two separate ldap servers?
No. You should use ACLs to solve this problem. Read man slapd.access
an/or search the openldap archives.
Assuming you have a NAT gatway as Firewall machine.
Replace all "by anonymous" statements with these 6 statements:
by anonymous auth continue
by peername.ip="127.0.0.1" read continue
by peername.ip="10.0.0.0%255.0.0.0" read continue
by peername.ip="172.16.0.0%255.240.0.0" read continue
by peername.ip="192.168.0.0%255.255.0.0" read continue
by peername.ip="gateway-ip" auth
One may write these statements more effective, but in general they will
do.
Replace "gateway-ip" with yours.
Put the above statements also in every ACL just before the
by *
when this ACL do NOT have an "by anonymous" statement.
Maybe the last line could/should be:
by ssf=56 peername.ip="gateway-ip" auth
Caveats:
Your gateway can no longer access your LDAP Server with
the "gateway-ip". But this is a Firewall Design Question.
I've tested this only with unencrypted sessions; anoymous and
authenticated. But TLS or SSL will not grant more rights, if you do not
tell the ACLs to do so.
Here the output from the two searches:
# ldapsearch -x -LLL -H ldap://192.168.231.90/ dn
Insufficient access (50)
# ldapsearch -x -LLL -H ldap://192.168.231.90/ dn -D
cn=admin,dc=kronprinz,dc=xx -W
dn: dc=kronprinz,dc=xx
dn: cn=admin,dc=kronprinz,dc=xx
> One with "disallow bind_anon" and one without. Then only open the
> firewall for port 636 to the ldap server which has "disallow
> bind_anon".
>
> Chris Jackson
--
Harry Jede
14 years, 4 months
Antw: Problem with N-Way multimaster replication after an node fail and restore
by Ulrich Windl
>>> David Tello <david.tello.wbsgo(a)gmail.com> schrieb am 09.05.2019 um 10:21
in
Nachricht
<CADC8=Wxww4kTHyRS3_j+93VXRzc45fDrVLJxFwFTRjcH8QD_gQ(a)mail.gmail.com>:
> I have a problem with the N-Way replication multimaster. My enviroiment is
> debian Stretch and slapd (2.4.47+dfsg-3~bpo9+1) from Stretch backports.
>
> I have configured a cluster with 3 nodes. I have configured to replicate
> the config database and a normal data mdb database. I followed the
> documentation and the cluster sync work correctly when all nodes are
> started.
>
> If i made a change in any node, this change is replicated to the others. My
> problem appears when i make a change whe one node is down. In this case,
> the other two nodes repli correctly, and when the downed node start this
> get all pending changes correctly. And in this point occurs the problem.
> After the start of downed node, the changes mades in this node are not send
> to the other two nodes. For other way, the changes mades in the other two
> nodes (no shutdowned) are sended to all nodes correctly.
>
> I tried this config with a two nodes cluster and the behavior was the same,
> after reboot slapd do not send more updates.
>
>
> I have checked the olcServerId because i know that a mistake here can
> produce similar problems. I really think that it is correct.
>
> The cmdlines of the proccess are:
>
> /usr/sbin/slapd -h ldapi:/// ldap://wbsvisionNode1/ ldap://127.0.0.1/
> ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d
> /usr/sbin/slapd -h ldapi:/// ldap://wbsvisionNode2/ ldap://127.0.0.1/
> ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d
> /usr/sbin/slapd -h ldapi:/// ldap://wbsvisionNode3/ ldap://127.0.0.1/
> ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d
>
>
> The config database configuración is below:
>
> *DN: cn=config*
> .....
> olcServerID: 1 ldap://wbsvisionNode1/
> olcServerID: 2 ldap://wbsvisionNode2/
> olcServerID: 3 ldap://wbsvisionNode3/
Are you sure your server IDs are assigned as intended? It is logged like
"slapd[1493]: olcServerID: value " on start.
>
> *dn: olcDatabase={0}config,cn=config*
> .......
> olcMirrorMode: TRUE
>
> olcSyncUseSubentry: FALSE
>
> olcSyncrepl:
>
> {0}rid=001
> provider=ldap://wbsvisionNode1
> bindmethod=simple
> binddn="cn=admin,cn=config"
> credentials="TuoDqAG7UbCJx8H8gfMO"
> starttls=no
> tls_cert=/etc/pki/certs/wbsagnitio.local.es.pem
> tls_key=/etc/pki/private/wbsagnitio.local.es.key
> tls_cacert=/etc/pki/certs/wbsagnitio-ca.pem
> tls_reqcert=never
> searchbase="cn=config"
> scope=sub
> type=refreshAndPersist
> retry="5 5 300 +"
> {1}rid=002
> provider=ldap://wbsvisionNode2
> bindmethod=simple
> binddn="cn=admin,cn=config"
> credentials="TuoDqAG7UbCJx8H8gfMO"
> starttls=no
> tls_cert=/etc/pki/certs/wbsagnitio.local.es.pem
> tls_key=/etc/pki/private/wbsagnitio.local.es.key
> tls_cacert=/etc/pki/certs/wbsagnitio-ca.pem
> tls_reqcert=never
> searchbase="cn=config"
> scope=sub
> type=refreshAndPersist
> retry="5 5 300 +"
> {2}rid=003
> provider=ldap://wbsvisionNode3
> bindmethod=simple
> binddn="cn=admin,cn=config"
> credentials="TuoDqAG7UbCJx8H8gfMO"
> starttls=no
> tls_cert=/etc/pki/certs/wbsagnitio.local.es.pem
> tls_key=/etc/pki/private/wbsagnitio.local.es.key
> tls_cacert=/etc/pki/certs/wbsagnitio-ca.pem
> tls_reqcert=never
> searchbase="cn=config"
> scope=sub
> type=refreshAndPersist
> retry="5 5 300 +"
> FALSE
>
> ------
>
> *dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config*
> objectClass: olcSyncProvConfig
> objectClass: olcOverlayConfig
> olcOverlay: {0}syncprov
> olcSpCheckpoint: 1000 1
>
>
> The data database configuración is below:
>
>
>
> *dn: olcDatabase={1}mdb,cn=config*
> objectClass: olcMdbConfig
> objectClass: olcDatabaseConfig
> olcDatabase: {1}mdb
> ...
> olcDbIndex: objectClass eq
> olcDbIndex: entryCSN eq
> ...
> olcLastMod: TRUE
>
> olcSuffix: dc=local,dc=es
> .........
> olcMirrorMode: TRUE
>
> olcSyncrepl: {0}rid=004
> provider=ldap://wbsvisionNode1
> bindmethod=simple
> binddn="cn=manager,dc=local,dc=es"
> credentials="test"
> starttls=no
> searchbase="dc=local,dc=es"
> scope=sub
> type=refreshAndPersist
> retry="5 5 300 +"
>
> olcSyncrepl: {1}rid=005
> provider=ldap://wbsvisionNode2
> bindmethod=simple
> binddn="cn=manager,dc=local,dc=es"
> credentials="test"
> starttls=no
> searchbase="dc=local,dc=es"
> scope=sub
> type=refreshAndPersist
> retry="5 5 300 +"
>
> olcSyncrepl: {2}rid=006
> provider=ldap://wbsvisionNode3
> bindmethod=simple
> binddn="cn=manager,dc=local,dc=es"
> credentials="test"
> starttls=no
> searchbase="dc=local,dc=es"
> scope=sub
> type=refreshAndPersist
> retry="5 5 300 +"
>
> olcSyncUseSubentry: FALSE
>
> dn: olcOverlay={0}dynlist,olcDatabase={1}mdb,cn=config
> objectClass: olcDynamicList
> objectClass: olcOverlayConfig
> olcOverlay: {0}dynlist
> olcDlAttrSet: {0}virtualGroup memberDnURL uniqueMember
> olcDlAttrSet: {1}virtualGroup memberUidURL memberUid:uid
> olcDlAttrSet: {2}virtualGroup memberSidURL sambaSIDList:sambaSID
>
> dn: olcOverlay={1}lastbind,olcDatabase={1}mdb,cn=config
> objectClass: olcLastBindConfig
> objectClass: olcOverlayConfig
> olcOverlay: {1}lastbind
> olcLastBindPrecision: 30
>
> dn: olcOverlay={2}unique,olcDatabase={1}mdb,cn=config
> objectClass: olcUniqueConfig
> objectClass: olcOverlayConfig
> olcOverlay: {2}unique
> olcUniqueAttribute: uid
> olcUniqueAttribute: uidNumber
> olcUniqueAttribute: employeeNumber
> olcUniqueBase: dc=local,dc=es
>
> dn: olcOverlay={3}memberof,olcDatabase={1}mdb,cn=config
> objectClass: olcMemberOf
> objectClass: olcOverlayConfig
> olcOverlay: {3}memberof
> olcMemberOfDangling: ignore
> olcMemberOfGroupOC: groupOfUniqueNames
> olcMemberOfMemberAD: uniqueMember
> olcMemberOfMemberOfAD: memberOf
> olcMemberOfRefInt: TRUE
>
> dn: olcOverlay={4}accesslog,olcDatabase={1}mdb,cn=config
> objectClass: olcAccessLogConfig
> objectClass: olcOverlayConfig
> olcAccessLogDB: cn=accesslog
> olcOverlay: {4}accesslog
> olcAccessLogOld:
(|(objectClass=wbsagnitioGroup)(objectClass=wbsagnitioAccou
> nt))
> olcAccessLogOldAttr: roles
> olcAccessLogOldAttr: objectClass
> olcAccessLogOps: writes
> olcAccessLogOps: bind
> olcAccessLogPurge: 7+00:00 1+00:00
>
> dn: olcOverlay={5}ppolicy,olcDatabase={1}mdb,cn=config
> objectClass: olcPPolicyConfig
> objectClass: olcOverlayConfig
> olcOverlay: {5}ppolicy
> olcPPolicyDefault:
cn=0-default,ou=passwordpolicies,ou=configuration,dc=loca
> l,dc=es
> olcPPolicyForwardUpdates: FALSE
> olcPPolicyHashCleartext: FALSE
> olcPPolicyUseLockout: FALSE
>
> dn: olcOverlay={6}syncprov,olcDatabase={1}mdb,cn=config
> objectClass: olcSyncProvConfig
> objectClass: olcOverlayConfig
> olcOverlay: {6}syncprov
> olcSpCheckpoint: 1000 1
>
> Below i show the sync log of some operations to show the behavior of my
> cluster:
> TEST 1: 3 Nodes up. Update in node 1 (correct):Log Node1:
>
> May 7 17:03:22 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
> 0x7fc7e0100a90 20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
> 0x7fc7e0108b40 20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
> removing 0x7fc7e0108b40 20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode1 slapd[14058]: syncprov_sendresp: to=002,
> cookie=rid=004,sid=001,csn=20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode1 slapd[14058]: syncprov_sendresp: to=003,
> cookie=rid=004,sid=001,csn=20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
> removing 0x7fc7e0100a90 20190507150322.383471Z#000000#001#000000
> Log Node2:
>
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: do_syncrep2: rid=004
> cookie=rid=004,sid=001,csn=20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncrepl_message_to_entry:
> rid=004 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
> d6c282a0-00ff-1039-89ae-b1c1eec8fb13
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncrepl_entry: rid=004
> LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) tid 23fff700
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncrepl_entry: rid=004
> be_search (0)
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncrepl_entry: rid=004
> cn=Usuarios,ou=grupos,dc=local,dc=es
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_queue_csn: queueing
> 0x7f80081057c0 20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncprov_matchops: skipping
> original sid 001
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_queue_csn: queueing
> 0x7f8008107700 20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_graduate_commit_csn:
> removing 0x7f8008107700 20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncprov_matchops: skipping
> original sid 001
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncprov_sendresp: to=003,
> cookie=rid=005,sid=002,csn=20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_graduate_commit_csn:
> removing 0x7f80081057c0 20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncrepl_entry: rid=004
> be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0)
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_queue_csn: queueing
> 0x7f8008105ea0 20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_graduate_commit_csn:
> removing 0x7f8008105ea0 20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: do_syncrep2: rid=006
> cookie=rid=006,sid=003,csn=20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode2 slapd[1263]: do_syncrep2: rid=006 CSN too
> old, ignoring 20190507150322.383471Z#000000#001#000000
> (cn=Usuarios,ou=grupos,dc=local,dc=es)
> Log Node3:
>
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=004
> cookie=rid=004,sid=001,csn=20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncrepl_message_to_entry:
> rid=004 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
> d6c282a0-00ff-1039-89ae-b1c1eec8fb13
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
> LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) tid adbb2700
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
> be_search (0)
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
> cn=Usuarios,ou=grupos,dc=local,dc=es
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> 0x7f428c1045c0 20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping
> original sid 001
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> 0x7f428c1069e0 20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> removing 0x7f428c1069e0 20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping
> original sid 001
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> removing 0x7f428c1045c0 20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncprov_sendresp: to=002,
> cookie=rid=006,sid=003,csn=20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
> be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0)
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> 0x7f428c104c90 20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> removing 0x7f428c104c90 20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=005
> cookie=rid=005,sid=002,csn=20190507150322.383471Z#000000#001#000000
> May 7 17:03:22 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=005 CSN too
> old, ignoring 20190507150322.383471Z#000000#001#000000
> (cn=Usuarios,ou=grupos,dc=local,dc=es)
>
>
> TEST 2: 3 Nodes up. Update in node 2 (correct) (later this will be the down
> node):Log Node1:
>
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: do_syncrep2: rid=005
> cookie=rid=005,sid=002,csn=20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncrepl_message_to_entry:
> rid=005 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
> d6c282a0-00ff-1039-89ae-b1c1eec8fb13
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncrepl_entry: rid=005
> LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) tid eaffd700
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncrepl_entry: rid=005
> be_search (0)
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncrepl_entry: rid=005
> cn=Usuarios,ou=grupos,dc=local,dc=es
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
> 0x7fc7d411fdd0 20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncprov_matchops: skipping
> original sid 002
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
> 0x7fc7d4105fa0 20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
> removing 0x7fc7d4105fa0 20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncprov_matchops: skipping
> original sid 002
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
> removing 0x7fc7d411fdd0 20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncrepl_entry: rid=005
> be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0)
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
> 0x7fc7d4121830 20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncprov_sendresp: to=003,
> cookie=rid=004,sid=001,csn=20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
> removing 0x7fc7d4121830 20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: do_syncrep2: rid=006
> cookie=rid=006,sid=003,csn=20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode1 slapd[14058]: do_syncrep2: rid=006 CSN too
> old, ignoring 20190507150531.748816Z#000000#002#000000
> (cn=Usuarios,ou=grupos,dc=local,dc=es)
>
> Log Node2:
>
> May 7 17:05:31 wbsvisionNode2 slapd[1263]: slap_queue_csn: queueing
> 0x7f8008106ed0 20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode2 slapd[1263]: slap_queue_csn: queueing
> 0x7f80081050e0 20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode2 slapd[1263]: slap_graduate_commit_csn:
> removing 0x7f80081050e0 20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode2 slapd[1263]: syncprov_sendresp: to=003,
> cookie=rid=005,sid=002,csn=20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode2 slapd[1263]: slap_graduate_commit_csn:
> removing 0x7f8008106ed0 20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode2 slapd[1263]: syncprov_sendresp: to=001,
> cookie=rid=005,sid=002,csn=20190507150531.748816Z#000000#002#000000
>
> Log Node3:
>
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=005
> cookie=rid=005,sid=002,csn=20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncrepl_message_to_entry:
> rid=005 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
> d6c282a0-00ff-1039-89ae-b1c1eec8fb13
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=005
> LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) tid acbb0700
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=005
> be_search (0)
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=005
> cn=Usuarios,ou=grupos,dc=local,dc=es
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> 0x7f4288107310 20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping
> original sid 002
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> 0x7f4288109c60 20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> removing 0x7f4288109c60 20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping
> original sid 002
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> removing 0x7f4288107310 20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncprov_sendresp: to=001,
> cookie=rid=006,sid=003,csn=20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=005
> be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0)
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> 0x7f42881079f0 20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> removing 0x7f42881079f0 20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=004
> cookie=rid=004,sid=001,csn=20190507150531.748816Z#000000#002#000000
> May 7 17:05:31 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=004 CSN too
> old, ignoring 20190507150531.748816Z#000000#002#000000
> (cn=Usuarios,ou=grupos,dc=local,dc=es)
>
>
> TEST 3: 2 Nodes up. The node 2 is down. Update in node 1:Log Node1:
>
> May 7 17:10:16 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
> 0x7fc7dc125e50 20190507151016.178467Z#000000#001#000000
> May 7 17:10:16 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
> 0x7fc7dc126f40 20190507151016.178467Z#000000#001#000000
> May 7 17:10:16 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
> removing 0x7fc7dc126f40 20190507151016.178467Z#000000#001#000000
> May 7 17:10:16 wbsvisionNode1 slapd[14058]: syncprov_sendresp: to=002,
> cookie=rid=004,sid=001,csn=20190507151016.178467Z#000000#001#000000
> May 7 17:10:16 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
> removing 0x7fc7dc125e50 20190507151016.178467Z#000000#001#000000
> May 7 17:10:16 wbsvisionNode1 slapd[14058]: syncprov_sendresp: to=003,
> cookie=rid=004,sid=001,csn=20190507151016.178467Z#000000#001#000000
> Log Node3:
>
> May 7 17:10:15 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=004
> cookie=rid=004,sid=001,csn=20190507151016.178467Z#000000#001#000000
> May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncrepl_message_to_entry:
> rid=004 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
> d6c282a0-00ff-1039-89ae-b1c1eec8fb13
> May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
> LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) tid a6ffd700
> May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
> be_search (0)
> May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
> cn=Usuarios,ou=grupos,dc=local,dc=es
> May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> 0x7f42a0124640 20190507151016.178467Z#000000#001#000000
> May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping
> original sid 001
> May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> 0x7f42a01261a0 20190507151016.178467Z#000000#001#000000
> May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> removing 0x7f42a01261a0 20190507151016.178467Z#000000#001#000000
> May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping
> original sid 001
> May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> removing 0x7f42a0124640 20190507151016.178467Z#000000#001#000000
> May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncprov_sendresp: to=002,
> cookie=rid=006,sid=003,csn=20190507151016.178467Z#000000#001#000000
> May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
> be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0)
> May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> 0x7f42a0124810 20190507151016.178467Z#000000#001#000000
> May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> removing 0x7f42a0124810 20190507151016.178467Z#000000#001#000000
>
>
> TEST 4: 3 Nodes up. Logs of the sync produced by the Node2 start. The node2
> resync correctly the change made in TEST3 (when this node was down).
> Log Node1:
>
> May 7 17:13:52 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
> 0x7fc7dc122780 20190507151352.582436Z#000000#001#000000
> May 7 17:13:52 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
> removing 0x7fc7dc122780 20190507151352.582436Z#000000#001#000000
> May 7 17:13:52 wbsvisionNode1 slapd[14058]: syncprov_search_response:
>
cookie=rid=004,sid=001,csn=20190507151016.178467Z#000000#001#000000;20190507
> 150531.748816Z#000000#002#000000;20190507150013.014798Z#000000#003#000000
> Log Node2:
>
> May 7 17:13:52 wbsvisionNode2 slapd[591]: slapd starting
> May 7 17:13:52 wbsvisionNode2 slapd[435]: Starting OpenLDAP: slapd.
> May 7 17:13:52 wbsvisionNode2 systemd[1]: Started LSB: OpenLDAP standalone
> server (Lightweight Directory Access Protocol).
> May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=001
> LDAP_RES_INTERMEDIATE - REFRESH_DELETE
> May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=003
> LDAP_RES_INTERMEDIATE - REFRESH_DELETE
> May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=004
> LDAP_RES_INTERMEDIATE - SYNC_ID_SET
> May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=006
> LDAP_RES_INTERMEDIATE - SYNC_ID_SET
> May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_message_to_entry:
> rid=004 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
> d6c282a0-00ff-1039-89ae-b1c1eec8fb13
> May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=004
> LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) tid f6021700
> May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=004
> be_search (0)
> May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=004
> cn=Usuarios,ou=grupos,dc=local,dc=es
> May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_message_to_entry:
> rid=006 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
> d6c282a0-00ff-1039-89ae-b1c1eec8fb13
> May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=006
> LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) tid f501f700
> May 7 17:13:52 wbsvisionNode2 slapd[591]: dn_callback : entries have
> identical CSN cn=Usuarios,ou=grupos,dc=local,dc=es
> 20190507151016.178467Z#000000#001#000000
> May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=006
> be_search (0)
> May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=006
> cn=Usuarios,ou=grupos,dc=local,dc=es
> May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=006 entry
> unchanged, ignored (cn=Usuarios,ou=grupos,dc=local,dc=es)
> May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=006
> LDAP_RES_INTERMEDIATE - REFRESH_PRESENT
> May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=006
>
cookie=rid=006,sid=003,csn=20190507151016.178467Z#000000#001#000000;20190507
> 150531.748816Z#000000#002#000000;20190507150013.014798Z#000000#003#000000
> May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
> present UUID d6b883e0-00ff-1039-898f-b1c1eec8fb13, dn dc=local,dc=es
> May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
> present UUID d6b88520-00ff-1039-8990-b1c1eec8fb13, dn
> ou=personas,dc=local,dc=es
> May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
> present UUID d6b8e51a-00ff-1039-8991-b1c1eec8fb13, dn
> ou=grupos,dc=local,dc=es
> May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
> present UUID d6b9494c-00ff-1039-8992-b1c1eec8fb13, dn
> ou=dominios,dc=local,dc=es
> May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
> present UUID d6b9b18e-00ff-1039-8993-b1c1eec8fb13, dn ou=dns,dc=local,dc=es
> May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
> present UUID d6b9eaaa-00ff-1039-8994-b1c1eec8fb13, dn
> ou=forward,ou=dns,dc=local,dc=es
> .................................
>
> Similar lines with other entries.
>
> May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
> present UUID d6c282a0-00ff-1039-89ae-b1c1eec8fb13, dn
> cn=Usuarios,ou=grupos,dc=local,dc=es
> ...............................
> May 7 17:13:52 wbsvisionNode2 slapd[591]: slap_queue_csn: queueing
> 0x7f63d0123740 20190507151016.178467Z#000000#001#000000
> May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=004
> be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0)
> May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=004
> LDAP_RES_INTERMEDIATE - REFRESH_PRESENT
> May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=004
>
cookie=rid=004,sid=001,csn=20190507151016.178467Z#000000#001#000000;20190507
> 150531.748816Z#000000#002#000000;20190507150013.014798Z#000000#003#000000
> May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004
> present UUID d6b883e0-00ff-1039-898f-b1c1eec8fb13, dn dc=local,dc=es
> May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004
> present UUID d6b88520-00ff-1039-8990-b1c1eec8fb13, dn
> ou=personas,dc=local,dc=es
> May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004
> present UUID d6b8e51a-00ff-1039-8991-b1c1eec8fb13, dn
> ou=grupos,dc=local,dc=es
> May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004
> present UUID d6b9494c-00ff-1039-8992-b1c1eec8fb13, dn
> ou=dominios,dc=local,dc=es
> May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004
> present UUID d6b9b18e-00ff-1039-8993-b1c1eec8fb13, dn ou=dns,dc=local,dc=es
>
> May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004
> present UUID d6c282a0-00ff-1039-89ae-b1c1eec8fb13, dn
> cn=Usuarios,ou=grupos,dc=local,dc=es
> .............................
>
> Similar lines with other entries.
>
> May 7 17:13:52 wbsvisionNode2 slapd[591]: slap_queue_csn: queueing
> 0x7f63d0121400 20190507151016.178467Z#000000#001#000000
> May 7 17:13:52 wbsvisionNode2 slapd[591]: slap_graduate_commit_csn:
> removing 0x7f63d0121400 20190507151016.178467Z#000000#001#000000
> May 7 17:13:52 wbsvisionNode2 slapd[591]: slap_graduate_commit_csn:
> removing 0x7f63d0123740 20190507151016.178467Z#000000#001#000000
>
> Log Node3:
>
> May 7 17:13:52 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> 0x7f428c103b00 20190507151352.329505Z#000000#003#000000
> May 7 17:13:52 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> removing 0x7f428c103b00 20190507151352.329505Z#000000#003#000000
> May 7 17:13:52 wbsvisionNode3 slapd[1100]: syncprov_search_response:
>
cookie=rid=006,sid=003,csn=20190507151016.178467Z#000000#001#000000;20190507
> 150531.748816Z#000000#002#000000;20190507150013.014798Z#000000#003#000000
>
>
> TEST 5: 3 Nodes up. Change is made in Node2 after resync and this is not
> sended to the other nodes in the cluster.Log Node1:
>
> Empty.
> Log Node2:
>
> May 7 17:28:35 wbsvisionNode2 slapd[591]: slap_queue_csn: queueing
> 0x7f63cc121370 20190507152835.873382Z#000000#002#000000
> May 7 17:28:35 wbsvisionNode2 slapd[591]: slap_queue_csn: queueing
> 0x7f63cc125120 20190507152835.873382Z#000000#002#000000
> May 7 17:28:35 wbsvisionNode2 slapd[591]: slap_graduate_commit_csn:
> removing 0x7f63cc125120 20190507152835.873382Z#000000#002#000000
> May 7 17:28:35 wbsvisionNode2 slapd[591]: slap_graduate_commit_csn:
> removing 0x7f63cc121370 20190507152835.873382Z#000000#002#000000
> Log Node3:
>
> Empty.
6 years, 1 month
Replication Failing with TLS ... Sneaky Little Config Error
by Daniel Howard
I have set up OpenLDAP per the nice tutorial at
https://help.ubuntu.com/lts/serverguide/openldap-server.html and on my
previous run-throughs, I succeeded at setting up replication via TLS. But
now that I'm implementing on the dedicated hardware, I am not able to
replicate via TLS.
SOLUTION: It turns out the solution was to add a space to an LDIF file ...
On PROVIDER I will see, for example:
Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 fd=49 ACCEPT from IP=
10.10.3.117:60277 (IP=0.0.0.0:389)
Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 op=0 BIND dn="" method=128
Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 op=0 RESULT tag=97 err=0 text=
Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 op=1 SRCH
base="dc=qxxxxxxxxd,dc=com" scope=2 deref=0
filter="(&(objectClass=posixAccount)(uidNumber=2043))"
Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 op=1 SRCH attr=uid
userPassword uidNumber gidNumber cn homeDirectory loginShell gecos
description objectClass
Mar 14 16:13:15 ldap0 slapd[1536]: <= bdb_equality_candidates: (uidNumber)
not indexed
Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 op=1 SEARCH RESULT tag=101
err=0 nentries=1 text=
Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 op=2 SRCH
base="dc=qxxxxxxxxd,dc=com"
scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=djh))"
Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 op=2 SRCH attr=uid
userPassword uidNumber gidNumber cn homeDirectory loginShell gecos
description objectClass
Mar 14 16:13:15 ldap0 slapd[1536]: conn=1392 op=2 SEARCH RESULT tag=101
err=0 nentries=1 text=
Mar 14 16:13:16 ldap0 slapd[1536]: conn=1392 op=3 UNBIND
While on CONSUMER:
Mar 14 16:13:15 ldap1 slapd[3672]: @(#) $OpenLDAP: slapd (Ubuntu) (Sep 15
2015 18:19:13) $#012#011buildd@lgw01-53
:/build/openldap-2QUgtL/openldap-2.4.31/debian/build/servers/slapd
Mar 14 16:13:16 ldap1 slapd[3673]: slapd starting
Mar 14 16:13:16 ldap1 slapd[3673]: do_syncrepl: rid=317 rc -1 retrying
Mar 14 16:13:16 ldap1 sudo: pam_unix(sudo:session): session closed for user
root
Mar 14 16:13:23 ldap1 slapd[3673]: conn=1000 fd=13 ACCEPT from IP=
10.10.5.3:15197 (IP=0.0.0.0:389)
Mar 14 16:13:23 ldap1 slapd[3673]: conn=1000 fd=13 closed (connection lost)
I *CAN* to TLS from consumer to master:
0-16:18 djh@ldap1 ~$ *ldapsearch -LLL -x -ZZ -H
ldap://ldap0.mtv.**qxxxxxxxxd.com
uid=djh cn*
dn: uid=djh,ou=People,dc=qxxxxxxxxd,dc=com
cn: djh
So, I increase olcLogLevel to add sync:
Mar 14 16:22:09 ldap1 slapd[4133]: @(#) $OpenLDAP: slapd (Ubuntu) (Sep 15
2015 18:19:13) $#012#011buildd@lgw01-53
:/build/openldap-2QUgtL/openldap-2.4.31/debian/build/servers/slapd
Mar 14 16:22:10 ldap1 slapd[4134]: slapd starting
Mar 14 16:22:10 ldap1 sudo: pam_unix(sudo:session): session closed for user
root
Mar 14 16:22:10 ldap1 slapd[4134]: do_syncrep2: rid=317
cookie=rid=317,csn=20160314224255.836334Z#000000#000#000000
Mar 14 16:22:10 ldap1 slapd[4134]: slap_queue_csn: queing 0x7f0c5c114995
20160314224255.836334Z#000000#000#000000
Mar 14 16:22:10 ldap1 slapd[4134]: slap_graduate_commit_csn: removing
0x7f0c5c114d10 20160314224255.836334Z#000000#000#000000
Mar 14 16:22:10 ldap1 slapd[4134]: do_syncrepl: rid=317 rc -1 retrying
THAT is the contextCSN on the provider!
0-16:24 djh@ldap0 ~$ *ldapsearch -z1 -LLLQY EXTERNAL -H ldapi:/// -s base
-b dc=qxxxxxxxxd,dc=com contextCSN # provider*
dn: dc=qxxxxxxxxd,dc=com
contextCSN: 20160314224255.836334Z#000000#000#000000
0-16:22 djh@ldap1 ~$ *ldapsearch -z1 -LLLQY EXTERNAL -H ldapi:/// -s base
-b dc=qxxxxxxxxd,dc=com contextCSN # consumer*
dn: dc=qxxxxxxxxd,dc=com
contextCSN: 20160314224152.708568Z#000000#000#000000
As best I can tell, the connection works, the replication works, but the
consumer is not asking for TLS.
0-16:29 djh@ldap1 ~$
*sudo ldapsearch -Q -Y EXTERNAL -H ldapi:/// -LLL -b cn=config
olcDatabase={1}hdb olcSyncRepldn: olcDatabase={1}hdb,cn=config*
olcSyncrepl: {0}rid=317 provider=ldap://ldap0.mtv.qxxxxxxxxd.com
bindmethod=si
mple binddn="cn=admin,dc=qxxxxxxxxd,dc=com" credentials=secret searchbase
="dc=qxxxxxxxxd,dc=com" logbase="cn=accesslog"
logfilter="(&(objectClass=audi
tWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist
retry="
60 +" syncdata=accesslogstarttls=critical tls_reqcert=demand
If I rip out starttls=critical tls_reqcert=demand then sync works no
problem.
If I enable logging on the PROVIDER I see:
Mar 14 16:35:46 ldap0 slapd[6838]: @(#) $OpenLDAP: slapd (Ubuntu) (Sep 15
2015 18:19:13) $#012#011buildd@lgw01-53
:/build/openldap-2QUgtL/openldap-2.4.31/debian/build/servers/slapd
Mar 14 16:35:46 ldap0 slapd[6839]: slapd starting
Mar 14 16:35:46 ldap0 sudo: pam_unix(sudo:session): session closed for user
root
Mar 14 16:35:49 ldap0 slapd[6839]: conn=1000 fd=27 ACCEPT from IP=
10.10.5.3:17876 (IP=0.0.0.0:389)
Mar 14 16:35:49 ldap0 slapd[6839]: conn=1000 fd=27 closed (connection lost)
Mar 14 16:35:55 ldap0 slapd[6839]: conn=1001 fd=27 ACCEPT from IP=
10.10.3.117:60312 (IP=0.0.0.0:389)
Mar 14 16:35:55 ldap0 slapd[6839]: conn=1001 op=0 BIND dn="cn=admin,dc=
*qxxxxxxxxd*,dc=com" method=128
Mar 14 16:35:55 ldap0 slapd[6839]: conn=1001 op=0 BIND dn="cn=admin,dc=
*qxxxxxxxxd*,dc=com" mech=SIMPLE ssf=0
Mar 14 16:35:55 ldap0 slapd[6839]: conn=1001 op=0 RESULT tag=97 err=0 text=
Mar 14 16:35:55 ldap0 slapd[6839]: conn=1001 op=1 SRCH base="cn=accesslog"
scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))"
Mar 14 16:35:55 ldap0 slapd[6839]: conn=1001 op=1 SRCH attr=targetDN
changeType changes newRDN deleteOldRDN newSuperior entryCSN
Mar 14 16:35:55 ldap0 slapd[6839]: Entry
reqStart=20160314224152.000005Z,cn=accesslog CSN
20160314224152.708568Z#000000#000#000000 older or equal to ctx
20160314224152.708568Z#000000#000#000000
Mar 14 16:35:55 ldap0 slapd[6839]: syncprov_search_response:
cookie=rid=317,csn=20160314224255.836334Z#000000#000#000000
Mar 14 16:35:55 ldap0 slapd[6839]: conn=1001 op=2 UNBIND
Mar 14 16:35:55 ldap0 slapd[6839]: conn=1001 fd=27 closed
So .......... it looks like ... sync works until it doesn't because ...
we're not binding consumer to provider TLS because .. ?
WAIT A GOSH DARN SECOND HERE ....
0-16:41 djh@ldap1 ~$
*sudo ldapsearch -Q -Y EXTERNAL -H ldapi:/// -LLL -b cn=config
olcDatabase={1}hdb olcSyncRepldn: olcDatabase={1}hdb,cn=config*
olcSyncrepl: {0}rid=317 provider=ldap://ldap0.mtv.qxxxxxxxxd.com
bindmethod=si
mple binddn="cn=admin,dc=qxxxxxxxxd,dc=com" credentials=secret searchbase
="dc=qxxxxxxxxd,dc=com" logbase="cn=accesslog"
logfilter="(&(objectClass=audi
tWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist
retry="
60 +" *syncdata=accesslogstarttls=critical* tls_reqcert=demand
Yeah ...
0-16:43 djh@ldap1 ~$ *cat consumer_sync_tls.ldif*
dn: olcDatabase={1}hdb,cn=config
replace: olcSyncRepl
olcSyncRepl: rid=317 provider=ldap://ldap0.mtv.qxxxxxxxxd.com
bindmethod=simple binddn="cn=admin,dc=qxxxxxxxxd,dc=com"
credentials=secret searchbase="dc=qxxxxxxxxd,dc=com"
logbase="cn=accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
schemachecking=on
type=refreshAndPersist retry="60 +" syncdata=accesslog
starttls=critical tls_reqcert=demand
0-16:43 djh@ldap1 ~$
*sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f
consumer_sync_tls.ldifSASL/EXTERNAL authentication started*
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "olcDatabase={1}hdb,cn=config"
No errors ...
**edit consumer_sync_tls.ldif, add a space to the end of the line ending in
syncdata=accesslog**
0-16:45 djh@ldap1 ~$
*sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f
consumer_sync_tls.ldifSASL/EXTERNAL authentication started*
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "olcDatabase={1}hdb,cn=config"
Same result, no errors, aaand:
0-16:46 djh@ldap1 ~$ *ldapsearch -z1 -LLLQY EXTERNAL -H ldapi:/// -s base
-b dc=**qxxxxxxxxd,dc=com contextCSN # consumer*
dn: dc=qxxxxxxxxd,dc=com
contextCSN: 20160314224255.836334Z#000000#000#000000
Well, I just paid some dues.
I want to add olcLogLevel config perhaps? Would that have helped me here?
Thanks ...
-danny
--
http://dannyman.toldme.com
9 years, 3 months
RE: Multi Master OpenLdap.
by arun.sasi1＠wipro.com
And also I could see below message
nonpresent_callback: rid=003 present UUI
Thanks,
-Arun
From: Arun Sasi V (WI01 - Manage IT)
Sent: Monday, July 11, 2011 1:36 PM
To: 'E.S. Rosenberg'
Cc: openldap-technical(a)openldap.org
Subject: RE: Multi Master OpenLdap.
Thank you very much Eli for concidering my issue. Here is my scenario...
I couldn’t find any abnormality in log files and also I never seen any deletion logs in the server. Slapd will go for hang and some ID`s will get disappear same will be replicate to slaves too. Mainly Groups and Computer accounts
I can see some UNBIND and connection lost logs from one server and another multimaster server from
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138411 op=24 SEARCH RESULT tag=101 err=32 nentries=0 text=
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138424 op=12 SRCH base="ou=Groups,dc=emb,dc=slb,dc=com" scope=2 deref=0 filter="(&(objectClass=sambaGroupMapping)(gidNumber=65534))"
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138424 op=12 SRCH attr=gidNumber sambaSID sambaGroupType sambaSIDList description displayName cn objectClass
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138424 op=12 SEARCH RESULT tag=101 err=0 nentries=0 text=
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138415 op=21 SRCH base="sambaDomainName=EMB,sambaDomainName=emb,dc=emb,dc=slb,dc=com" scope=2 deref=0 filter="(&(objectClass=sambaTrustedDomainPassword)(sambaDomainName=emb))"
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138415 op=21 SEARCH RESULT tag=101 err=32 nentries=0 text=
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138385 op=46 SRCH base="ou=Groups,dc=emb,dc=slb,dc=com" scope=2 deref=0 filter="(&(objectClass=sambaGroupMapping)(|(displayName=test)(cn=test)))"
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138385 op=46 SRCH attr=gidNumber sambaSID sambaGroupType sambaSIDList description displayName cn objectClass
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: <= bdb_equality_candidates: (displayName) not indexed
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: <= bdb_equality_candidates: (cn) not indexed
Jul 11 04:07:53 gb0135embldap01 slapd[21335]: @(#) $OpenLDAP: slapd 2.4.15 (Mar 19 2009 10:07:59) $ ^Ibuildd@yellow:/build/buildd/openldap-2.4.15/debian/build/servers/slapd
Jul 11 04:07:54 gb0135embldap01 slapd[21337]: slapd starting
Jul 11 04:07:54 gb0135embldap01 slapd[21337]: conn=0 fd=23 ACCEPT from IP=[::1]:57016 (IP=[::]:389)
Jul 11 04:07:54 gb0135embldap01 slapd[21337]: conn=1 fd=24 ACCEPT from IP=134.32.44.37:40763 (IP=0.0.0.0:389)
OLCDATABSE
dn: olcDatabase={1}hdb
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=emb,dc=slb,dc=com
olcAccess: {0}to attrs=userPassword,shadowLastChange,sambaLMPassword,sambaNTPassword
by dn="cn=admin,dc=emb,dc=slb,dc=com" write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=136.250.9.48 write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=163.185.18.238 write
by anonymous auth by self write
by * none
olcAccess: {1}to dn.base="" by * read
#Enable Local Admin to add users in the Group and also SunOne to add users to country groups
olcAccess: {2}to dn.subtree="ou=groups,dc=emb,dc=slb,dc=com"
by set="user/uid & [cn=group-admin,ou=SuperGroups,dc=emb,dc=slb,dc=com]/memberuid" write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=136.250.9.48 write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=163.185.18.238 write
by * read
#Enable Local Admin to add computers
olcAccess: {3}to dn.subtree="ou=Computers,dc=emb,dc=slb,dc=com"
by set="user/uid & [cn=group-admin,ou=SuperGroups,dc=emb,dc=slb,dc=com]/memberuid" write
by * read
#Enable shell-admin to set up local user access
olcAccess: {4}to attrs=loginShell,homeDirectory
by set="user/uid & [cn=shell-admin,ou=SuperGroups,dc=emb,dc=slb,dc=com]/memberuid" write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=136.250.9.48 write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=163.185.18.238 write
by * read
#Enable write access to account sun-one-replication for sun ldap replication.
olcAccess: {5}to *
by dn="cn=admin,dc=emb,dc=slb,dc=com" write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=136.250.9.48 write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=163.185.18.238 write
by * read
olcLastMod: TRUE
olcDbCheckpoint: 512 30
olcDbConfig: {0}set_cachesize 0 2097152 0
olcDbConfig: {1}set_lk_max_objects 1500
olcDbConfig: {2}set_lk_max_locks 1500
olcDbConfig: {3}set_lk_max_lockers 1500
olcDbIndex: objectClass eq
olcDbIndex: entryUUID eq
olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: loginShell eq
olcDbIndex: uid eq,pres,sub
olcDbIndex: memberUid eq,pres,sub
olcDbIndex: uniqueMember eq,pres
olcDbIndex: sambaSID eq
olcDbIndex: sambaPrimaryGroupSID eq
olcDbIndex: sambaGroupType eq
olcDbIndex: sambaSIDList eq
olcDbIndex: sambaDomainName eq
olcDbIndex: default sub
structuralObjectClass: olcHdbConfig
entryUUID: f479600a-5f34-102f-8ddd-3ff046e70702
creatorsName: cn=admin,cn=config
createTimestamp: 20100928101442Z
olcRootDN: cn=admin,dc=emb,dc=slb,dc=com
olcSyncrepl: {0}rid=003 provider=ldap://gb0135embldap01.emb.slb.com binddn="cn
=admin,dc=emb,dc=slb,dc=com" bindmethod=simple credentials=Bsl@121z searchbas
e="dc=emb,dc=slb,dc=com" type=refreshOnly interval=00:00:00:10 retry="5 5 300
5" timeout=1 starttls=yes
olcSyncrepl: {1}rid=004 provider=ldap://ae0042embldap01.emb.slb.com binddn="cn
=admin,dc=emb,dc=slb,dc=com" bindmethod=simple credentials=Bsl@121z searchbas
e="dc=emb,dc=slb,dc=com" type=refreshOnly interval=00:00:00:10 retry="5 5 300
5" timeout=1 starttls=yes
olcMirrorMode: TRUE
entryCSN: 20100928191927.932499Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20100928191927Z
Ldap Version
@(#) $OpenLDAP: slapd 2.4.15 (Mar 19 2009 10:07:59) $
Operating system
Distributor ID: Ubuntu
Description: Ubuntu 9.04
Release: 9.04
Codename: jaunty
Thanks,
-Arun
-----Original Message-----
From: E.S. Rosenberg [mailto:esr@g.jct.ac.il]
Sent: Monday, July 11, 2011 12:58 PM
To: Arun Sasi V (WI01 - Manage IT)
Cc: openldap-technical(a)openldap.org
Subject: Re: Multi Master OpenLdap.
Have you tried raising the loglevel?
Are the schemas the same between the servers?
Is time in sync between the servers?
What versions are you dealing with?
You don't provide a lot of info and most of us are not clairvoyant....
Regards,
Eli
2011/7/11 <arun.sasi1(a)wipro.com>:
>
>
>
>
> Thanks,
>
> -Arun
>
>
>
> From: Arun Sasi V (WI01 - Manage IT)
> Sent: Wednesday, July 06, 2011 5:46 PM
> To: 'openldap-technical(a)openldap.org'
> Subject: Multi Master OpenLdap.
>
>
>
> Hello Team,
>
>
>
> I have configured Multi-master Mirror mode replica setup in our environment.
> We have 3 regions slave Ldap server which is read only and two location we
> have configured as mirror mode replica Ldap. My problem here is…
>
>
>
> Master Ldap is going hang some times and some ID`s are disappearing from the
> master server. I couldn’t find any logs over there for why ID`s are
> disappearing and also why Ldap is going hung state.
>
>
>
> Thanks & Regards,
>
> Arun Sasi V
>
> Please do not print this email unless it is absolutely necessary.
>
> The information contained in this electronic message and any attachments to
> this message are intended for the exclusive use of the addressee(s) and may
> contain proprietary, confidential or privileged information. If you are not
> the intended recipient, you should not disseminate, distribute or copy this
> e-mail. Please notify the sender immediately and destroy all copies of this
> message and any attachments.
>
> WARNING: Computer viruses can be transmitted via email. The recipient should
> check this email and any attachments for the presence of viruses. The
> company accepts no liability for any damage caused by any virus transmitted
> by this email.
>
> www.wipro.com
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com
13 years, 11 months
Re: Multi-master replication (ldap_sasl_bind_s failed)
by Artur Nike
I run slap2 for:
/usr/sbin/slapd -h ldap://slap2:389 -d 16383 -u openldap -g openldap
52aef96c =>do_syncrepl rid=004
ldap_create
ldap_url_parse_ext(ldap://ldap1:389)
ldap_sasl_bind_s
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP ldap1:389
52aef96c =>do_syncrepl rid=005
ldap_create
ldap_url_parse_ext(ldap://ldap2:389)
ldap_sasl_bind_s
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP ldap2:389
52aef971 daemon: epoll: listen=7 active_threads=0 tvp=zero
52aef971 daemon: epoll: listen=8 active_threads=0 tvp=zero
*ldap_connect_to_host: getaddrinfo failed: Name or service not known*
52aef976 slap_client_connect: *URI=ldap://ldap1:389
*DN="cn=admin,dc=example,dc=com"
ldap_sasl_bind_s failed (-1)
52aef976 do_syncrepl: rid=004 rc -1 retrying (4 retries left)
52aef976 daemon: activity on 1 descriptor
52aef976 daemon: activity on:52aef976
52aef976 daemon: epoll: listen=7 active_threads=0 tvp=zero
52aef976 daemon: epoll: listen=8 active_threads=0 tvp=zero
*ldap_connect_to_host: getaddrinfo failed: Name or service not known*
52aef976 slap_client_connect: *URI=ldap://ldap2:389
*DN="cn=admin,dc=example,dc=com"
ldap_sasl_bind_s failed (-1)
52aef976 do_syncrepl: rid=005 rc -1 retrying (4 retries left)
52aef976 daemon: activity on 1 descriptor
52aef976 daemon: activity on:52aef976
52aef976 daemon: epoll: listen=7 active_threads=0 tvp=zero
52aef976 daemon: epoll: listen=8 active_threads=0 tvp=zero
ldap1 --> slap1
ldap2 --> slap2
...and every working.
I'm blind and so the topic !!!
Thread is closed
2013/12/16 Artur Nike <opalsie(a)gmail.com>
> Hi all,
>
> My adventure with LDAP lasts a few months, and I came to the topic of
> replication,
> namely multiple-master replication.
> cn = config is replicated perfectly, but the schema, say, dc = example, dc
> = com does not want to: (.
>
> I have two servers slap1 and slap2
>
> I have a standard installation
> ##Server slap1
> whezzy debian 64bit
> apt-get install-y slapd ldap-utils
> added my scheme
> ldapadd-Y EXTERNAL-H ldapi :///-f $ CURRENT / memberof.ldif
> ldapadd-Y EXTERNAL-H ldapi :///-f $ CURRENT / refint.ldif
> # Add "ldap :/ / ldap1 / in /etc/default/slapd
> sed-i "/^
> SLAPD_SERVICES/s/=[^]*/=\"ldap:\/\/slap1\//'/etc/default/slapd
> ldapmodify-Y EXTERNAL-H ldapi :/ / /-f replica1.ldif
>
> where replica1.ldif (replication configuration)::
> dn: cn=config
> changetype: modify
> add: olcServerID
> olcServerID: 1
>
> dn: cn=module{0},cn=config
> changetype: modify
> add: olcModuleLoad
> olcModuleLoad: {1}syncprov.la
>
> dn: olcDatabase={0}config,cn=config
> changetype: modify
> add: olcRootPW
> #only for tests
> olcRootPW: 123
>
> dn: cn=config
> changetype: modify
> replace: olcServerID
> olcServerID: 1 ldap://slap1/
> olcServerID: 2 ldap://slap2/
>
> dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
> changetype: add
> objectClass: olcOverlayConfig
> objectClass: olcSyncProvConfig
> olcOverlay: syncprov
>
> dn: olcDatabase={0}config,cn=config
> changetype: modify
> add: olcSyncRepl
> olcSyncRepl: rid=001 provider=ldap://slap1/
> binddn="cn=admin,cn=config"
> bindmethod=simple credentials=123
> searchbase="cn=config" type=refreshAndPersist
> retry="5 5 300 5" timeout=1
> olcSyncRepl: rid=002 provider=ldap://slap2/
> binddn="cn=admin,cn=config"
> bindmethod=simple credentials=123
> searchbase="cn=config" type=refreshAndPersist
> retry="5 5 300 5" timeout=1
> -
> add: olcMirrorMode
> olcMirrorMode: TRUE
>
> This same scenario takes on a server slap2 (the name change slap1 -> slap2)
>
> where replica2.ldif (replication configuration only servers slap2) :
> dn: cn=config
> changetype: modify
> add: olcServerID
> olcServerID: 2
>
> dn: cn=module{0},cn=config
> changetype: modify
> add: olcModuleLoad
> olcModuleLoad: {1}syncprov.la
>
> dn: olcDatabase={0}config,cn=config
> changetype: modify
> #only for tests
> add: olcRootPW
> olcRootPW: 123
>
> dn: cn=config
> changetype: modify
> replace: olcServerID
> olcServerID: 1 ldap://slap1/
> olcServerID: 2 ldap://slap2/
>
> dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
> changetype: add
> objectClass: olcOverlayConfig
> objectClass: olcSyncProvConfig
> olcOverlay: syncprov
>
> dn: olcDatabase={0}config,cn=config
> changetype: modify
> add: olcSyncRepl
> olcSyncRepl: rid=001 provider=ldap://slap1/
> binddn="cn=admin,cn=config"
> bindmethod=simple credentials=123
> searchbase="cn=config" type=refreshAndPersist
> retry="5 5 300 5" timeout=1
> olcSyncRepl: rid=002 provider=ldap://slap2/
> binddn="cn=admin,cn=config"
> bindmethod=simple credentials=123
> searchbase="cn=config" type=refreshAndPersist
> retry="5 5 300 5" timeout=1
> -
> add: olcMirrorMode
> olcMirrorMode: TRUE
>
>
> and it works , the whole configuration is replicated .
>
> Now I want ( I'm trying to add a replication scheme . )
> Adds only one server , eg slap2 :
> ldapmodify - Y EXTERNAL -H ldapi :/ / / -f rep_schema.ldif
>
> where rep_schema.ldif :
>
> # add replica schema
> dn: olcDatabase={1}hdb,cn=config
> changetype: modify
> replace: olcRootPW
> olcRootPW: 123
> -
> replace: olcRootDN
> olcRootDN: cn=admin,dc=example,dc=com
>
> dn: olcDatabase={1}hdb,cn=config
> changetype: modify
> add: olcLimits
> olcLimits: dn.exact="cn=admin,dc=example,dc=com"
> time.soft=unlimited
> time.hard=unlimited size.soft=unlimited size.hard=unlimited
> -
> add: olcSyncRepl
> olcSyncRepl: rid=004 provider=ldap://ldap1/
> binddn="cn=admin,dc=example,dc=com"
> bindmethod=simple credentials="123"
> searchbase="dc=example,dc=com"
> starttls=no
> filter="(objectclass=*)"
> attrs="*,+" scope=sub
> schemachecking=of
> type=refreshAndPersist interval=00:00:00:10 retry="5 5 10 5"
> timeout=1
> olcSyncRepl: rid=005 provider=ldap://ldap2/
> binddn="cn=admin,dc=example,dc=com"
> bindmethod=simple credentials="123"
> searchbase="dc=example,dc=com"
> starttls=no
> filter="(objectclass=*)"
> attrs="*,+" scope=sub
> schemachecking=off
> type=refreshAndPersist interval=00:00:00:10 retry="5 5 10 5"
> timeout=1
> -
> add: olcDbIndex
> olcDbIndex: entryUUID eq
> -
> add: olcDbIndex
> olcDbIndex: entryCSN eq
> -
> add: olcMirrorMode
> olcMirrorMode: TRUE
>
> dn: olcOverlay=syncprov,olcDatabase={1}hdb,cn=config
> changetype: add
> objectClass: olcOverlayConfig
> objectClass: olcSyncProvConfig
> olcOverlay: syncprov
>
> Configuration replicates and the end, schema does not replicate.
> If you try to replicate one of the servers are in the logs I see:
>
>
> Dec 15 23:44:48 slap1 slapd[4496]: do_syncrepl: rid=004 rc -1 quitting
> Dec 15 23:44:48 slap1 slapd[4496]: slap_client_connect: URI=ldap://ldap2/
> DN="cn=admin,dc=example,dc=com" ldap_sasl_bind_s failed (-1)
> Dec 15 23:44:48 slap1 slapd[4496]: do_syncrepl: rid=005 rc -1 retrying
> Dec 15 23:44:58 slap1 slapd[4496]: =>do_syncrepl rid=005
> Dec 15 23:44:58 slap1 slapd[4496]: slap_client_connect: URI=ldap://ldap2/
> DN="cn=admin,dc=example,dc=com" ldap_sasl_bind_s failed (-1)
>
> Dec 15 23:44:50 slap2 slapd[4456]: do_syncrepl: rid=004 rc -1 retrying
> Dec 15 23:44:54 slap2 slapd[4456]: =>do_syncrepl rid=005
> Dec 15 23:44:54 slap2 slapd[4456]: slap_client_connect: URI=ldap://ldap2/
> DN="cn=admin,dc=example,dc=com" ldap_sasl_bind_s failed (-1)
> Dec 15 23:44:54 slap2 slapd[4456]: do_syncrepl: rid=005 rc -1 quitting
> Dec 15 23:45:00 slap2 slapd[4456]: =>do_syncrepl rid=004
> Dec 15 23:45:00 slap2 slapd[4456]: slap_client_connect: URI=ldap://ldap1/
> DN="cn=admin,dc=example,dc=com" ldap_sasl_bind_s failed (-1)
>
>
> from server slap2 to search slap1:
> ldapsearch -x -D cn=admin,dc=example,dc=com-H ldap://slap1/ -b
> dc=example,dc=com -w 123 (working)
>
> from server slap1 to search slap2:
> ldapsearch -x -D cn=admin,dc=example,dc=com-H ldap://slap2/ -b
> dc=example,dc=com -w 123 (working)
>
> I'm out of ideas...
> user : DN="cn=admin,dc=example,dc=com" is created automatically when I
> install slapd
>
> Can anyone have any suggestions or experience with this problem.
> For all, thank you in advance.
>
> Muniek
>
11 years, 6 months