MMR - Add and delete entry on on server, CSN too old on the other and the entry is not deleted
by Meunier, Antonin
Hello,
I'm with openldap-2.4.39.
I've 2 openldap server on MMR, the config is down to the mail.
On the 1st server, il made
- ADD an entry
- Little after (1h) DELETE the same entry
On the second server, I have :
- The entry is created by replication
- BUT the entry is not delete by the replication with a CSN too old error.
How can i resolv this ?
Thanks by advance
Extract of the logs is :
On 1st server (where entry is add and delete) :
2014-09-16T01:59:09.161478+02:00 ldapp01 slapd[19641]: conn=6131651 op=5367 ADD dn="cn=1952991,ou=groupe..."
2014-09-16T02:57:46.499274+02:00 ldapp01 slapd[19641]: conn=6153444 op=24 DEL dn="cn=1952991,ou=groupe_..."
...
2014-09-16T04:44:01.713257+02:00 ldapp01 slapd[19641]: syncprov_search_response: cookie=rid=000,sid=001,csn=20140916024243.636498Z#000000#001#000000;20140830211826.755872Z#000000#002#000000;20131010140905.564563Z#000000#065#000000;20130913220003.060576Z#000000#12b#000000;20131206221310.808393Z#000000#12d#000000
2014-09-16T04:44:01.713299+02:00 ldapp01 slapd[19641]: syncprov_sendresp: cookie=rid=000,sid=001,csn=20140916024342.267736Z#000000#001#000000
2014-09-16T04:44:01.906746+02:00 ldapp01 slapd[19641]: conn=6183327 op=1 UNBIND
On the Second server (where entry persist without delete) :
2014-09-16T04:29:28.462968+02:00 ldapp02 slapd[12536]: syncrepl_message_to_op: rid=102 be_add cn=1952991,ou=groupe... (0)
2014-09-16T04:29:28.462968+02:00 ldapp02 slapd[12536]: syncrepl_message_to_op: rid=102 be_add cn=1952991,ou=groupe... (0)
2014-09-16T04:29:28.462978+02:00 ldapp02 slapd[12536]: slap_queue_csn: queing 0x7f0f505698d0 20140915235909.161585Z#000000#001#000000
2014-09-16T04:29:28.463051+02:00 ldapp02 slapd[12536]: slap_graduate_commit_csn: removing 0x7f0f50568740 20140915235909.161585Z#000000#001#000000
2014-09-16T04:29:28.463076+02:00 ldapp02 slapd[12536]: do_syncrep2: rid=102 cookie=rid=000,sid=001,csn=20140915235909.166279Z#000000#001#000000
2014-09-16T04:29:28.463113+02:00 ldapp02 slapd[12536]: slap_queue_csn: queing 0x7f0f5056e6ee 20140915235909.166279Z#000000#001#000000
2014-09-16T04:29:28.464678+02:00 ldapp02 slapd[12536]: slap_queue_csn: queing 0x7f0f5055f710 20140915235909.166279Z#000000#001#000000
2014-09-16T04:29:28.464860+02:00 ldapp02 slapd[12536]: syncprov_matchops: skipping original sid 001
2014-09-16T04:29:28.464870+02:00 ldapp02 slapd[12536]: slap_graduate_commit_csn: removing 0x7f0f50556380 20140915235909.166279Z#000000#001#000000
2014-09-16T04:29:28.464880+02:00 ldapp02 slapd[12536]: slap_graduate_commit_csn: removing 0x7f0f50563df0 20140915235909.166279Z#000000#001#000000
...
2014-09-16T04:44:01.653713+02:00 ldapp02 slapd[12536]: do_syncrep2: rid=102 cookie=rid=000,sid=001,csn=20140915235909.166279Z#000000#001#000000
2014-09-16T04:44:01.653740+02:00 ldapp02 slapd[12536]: do_syncrep2: rid=102 CSN too old, ignoring 20140915235909.166279Z#000000#001#000000 (reqStart=20140915235909.000007Z,cn=de
lta-sync)
..
2014-09-16T04:44:01.653619+02:00 ldapp02 slapd[12536]: do_syncrep2: rid=102 cookie=rid=000,sid=001,csn=20140915235909.161585Z#000000#001#000000
2014-09-16T04:44:01.653646+02:00 ldapp02 slapd[12536]: do_syncrep2: rid=102 CSN too old, ignoring 20140915235909.161585Z#000000#001#000000 (reqStart=20140915235909.000005Z,cn=de
lta-sync)
Configuration is :
On the 1st server :
.
ServerID 001
.
maxderefdepth 15
readonly FALSE
sync_use_subentry FALSE
.
dbnosync TRUE
# ecriture tous les 15 minutes
checkpoint 0 15
.
syncrepl rid=201
provider=ldap://ldapp02:389
type=refreshAndPersist
retry="5 5 300 +"
searchbase="dc=ent,dc=fr"
attrs="*,+"
bindmethod=simple
binddn="cn=admin,ou=system,dc=ent,dc=fr"
credentials=XXXXXXX
logbase="cn=delta-sync"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
syncdata=accesslog
mirrormode on
# Overlay configuration should be added after the database configuration
# Définition de l'overlay lié à la réplication maitre
overlay syncprov
syncprov-checkpoint 100 10
On the second server :
ServerID 002
.
maxderefdepth 15
readonly FALSE
sync_use_subentry FALSE
.
dbnosync TRUE
# ecriture tous les 15 minutes
checkpoint 0 15
.
syncrepl rid=102
provider=ldap://ldapp01:389
type=refreshAndPersist
retry="5 5 300 +"
searchbase="dc=ent,dc=fr"
attrs="*,+"
bindmethod=simple
binddn="cn=admin,ou=system,dc=ent,dc=fr"
credentials=XXXXXXX
logbase="cn=delta-sync"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
syncdata=accesslog
mirrormode on
# Overlay configuration should be added after the database configuration
# Définition de l'overlay lié à la réplication maitre
overlay syncprov
syncprov-checkpoint 100 10
Antonin Meunier
8 years, 11 months
OpenLDAP manual sync (on-demand replication)
by Peter Boguszewski
I would like to setup a Master / Consumer relationship that only does
one way replication on demand. We have complex scripts that update one
server (the master) and needs to be verified / approved before
replicating to the consumer. I understand how to setup replication in
general and have a multi-master setup for other services so I am not
asking how to do initial setup. My first thought is to set the
replication interval to 30 days and forcing a manual sync - but this is
the part I am not sure how to do. Is there a command to force a manual
sync before the normal replication interval? Thanks in advance and sorry
if there is a simple answer I am missing.
Thanks for any help!
--
Peter Boguszewski
Manager of Library Systems
UW Madison - Library Technology Group
pboguszewski(a)library.wisc.edu
608.262.4768
8 years, 11 months
access control with pbind overlay
by Ferenc Wagner
Hi,
I've got a partial syncrepl replica, which (among others) misses the
userPassword attributes of the provider database. I added a pbind
overlay to the replica, which forwards binds to the provider, thus it
became possible to do simple binds against the replica. But access
control on the replica does not honor these binds properly: "by users"
works, but "by self" does not. Before I waste too much time debugging:
is it supposed to work at all? I tested this under 2.4.31 with:
dn: olcDatabase={1}mdb,cn=config
olcAccess: to * by dn.exact=gidNumber=119+uidNumber=116,cn=peercred,cn=external,cn=auth read by self read by * none
olcSyncrepl: rid=1 [...]
The external auth part works, and if I replace self with users, that
works as well (but is not what I want). Do I expect too much?
--
Thanks,
Feri.
8 years, 11 months
can a automountMap be associated with a nisNetgroup
by Dal tee
Hi,
I'm trying to see if I can control which mounts get mounted based on a
servers netgroup membership.
I suppose the first question is... Can it be done.
I'm using an openldap client on RHEL 6.2 accessing AD.
Has anyone got a working example they can walk through ?
8 years, 12 months
Help: Query unmodified non SSHA userPasswords
by Ulrich Windl
Hi!
I'd like to query userPassword attributes that don't start with "{SSHA", but it seems substring match doesn't work there.
An addition I'd like to find those users that didn't change their password since the user was created, i.e. modifyTimestamp=createTimestamp, but I think that's not possible in a search filter as the right of '=' is interpreted literally, right?
Any ideas?
Regards,
Ulrich
8 years, 12 months
Sync Repl - mirror mode - rid=001 LDAP_RES_INTERMEDIATE - REFRESH_DELETE
by Sterling Sahaydak
I've upgraded my 2 ldap servers to 2.4.39 and have been trying to get
mirror mode to work with no luck.
I've removed out for now TLS and using ldap:///
The issue I've had since 2.4.23 version and now is
"LDAP_RES_INTERMEDIATE - REFRESH_DELETE"
Everything else works but have run into this issue that can't resolve.
I've looked up in the forum for other references to this, but not seeing
a clear resolution.
Others, keep getting additional messages beyond this, but mine stops at
this.
I've tried running also with slapd -h "ldapi:/// ldap:///" -d 7 but
getting stuck as well
Your help is greatly appreciated!
[root@ldap-east ~]# slapd -d sync
54243242 @(#) $OpenLDAP: slapd 2.4.39 (Sep 17 2014 15:14:19) $
root@admin.xxxxx.net:/root/rpmbuild/BUILD/openldap-2.4.39/openldap-2.4.39/servers/slapd
54243242 /etc/openldap/slapd.conf: line 226: rootdn is always granted
unlimited privileges.
54243242 slapd starting
54243242 do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - REFRESH_DELETE
Provider/Master side - slapd.conf (ldap-east)
-------------------------------------------
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/sudo.schema
allow bind_v2
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
modulepath /usr/lib/openldap
modulepath /usr/lib64/openldap
moduleload accesslog.la
moduleload rwm.la
moduleload syncprov.la
disallow bind_anon
moduleload back_bdb
moduleload back_ldap
backend bdb
database monitor
access to *
by dn.exact="cn=Manager,dc=xxxxx,dc=net" read
by * none
database bdb
suffix "dc=xxxxx,dc=net"
checkpoint 1024 15
rootdn "cn=Manager,dc=xxxxx,dc=net"
rootpw xxxxx
directory /var/lib/ldap
access to *
by dn.base="cn=TestSync,ou=Roles,dc=xxxxx,dc=net" write
by * break
access to attrs=userPassword,shadowLastChange
by dn="cn=Manager,dc=xxxxx,dc=net" write
by anonymous auth
by self write
by * none
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
index entryCSN,entryUUID eq
serverID 1
overlay syncprov
syncprov-checkpoint 100 1
syncprov-sessionlog 100
#LDAP Sync - Slave
syncrepl rid=001
provider=ldap://ldap-west.xxxxx.net
bindmethod=simple
binddn="cn=TestSync,ou=Roles,dc=xxxxx,dc=net"
credentials="xxxxxx"
searchbase="dc=xxxxx,dc=net"
schemachecking=off
type=refreshAndPersist
retry="60 +"
filter="(objectclass=*)"
attrs="*,+"
mirrormode on
loglevel -1
Consumer/Slave side - slapd.conf (ldap-west) - only difference is the
replication section
-------------------------------------------
....
serverID 2
overlay syncprov
syncprov-checkpoint 100 1
syncprov-sessionlog 100
#LDAP Sync - Master
syncrepl rid=001
provider=ldap://ldap-east.xxxxx.net
bindmethod=simple
binddn="cn=TestSync,ou=Roles,dc=xxxxx,dc=net"
credentials="xxxxxx"
searchbase="dc=xxxxx,dc=net"
schemachecking=off
type=refreshAndPersist
retry="60 +"
filter="(objectclass=*)"
attrs="*,+"
mirrormode on
8 years, 12 months
(ITS#7274) delta-syncrepl MMR infinite loop - like issue?
by Francesco Malvezzi
During the setup of a mirror mode cluster, I enabled the syncprov after
building the mirror.
So maybe I run into ITS#7274:
http://www.openldap.org/its/index.cgi/Documentation?id=7274;selectid=7274...
delta-syncrepl fails with:
1) ABANDON log messages on provider;
2) matching "delta-sync lost" log messages on consumer.
Do I understand correctly: provider needs contextCSN value for SID=0 in
order to have delta-syncrepl working?
Does the following query confirm the lack of the contextCSN value for SID=0?
ldapsearch -ZZ -h ldap.example.org -LLL -x -s base -b dc=example,dc=org
contextCSN
dn: dc=example,dc=org
contextCSN: 20140925113354.230424Z#000000#001#000000
contextCSN: 20140925113307.523494Z#000000#002#000000
If the mirror mode cluster is in production, do I have any hope to setup
delta-syncrepl?
Thank you,
Francesco
8 years, 12 months
slapo-refint not working on consumer.
by Mike Hulsman
Hi,
When testing slapo-refint functionality in a configuration with mirror
node masters, and a Delta-syncrepl consumer.
I see that refint is working between the 2 providers, but not on the consumer.
Using Openldap 2.4.39 on all instances.
Database is hdb
After renaming a uid the ContextCSN on all instances are the same, so
changes are propagated successful.
Every change if replicated properly, except for refint on a consumer.
The refint configuration:
overlay refint
refint_attributes uniqueMember
refint_nothing cn=Manager,o=test
The logfile on the consumer:
Sep 23 17:05:12 sldapa01 slapd[1727]: do_syncrep2: rid=101
cookie=rid=101,sid=001,csn=20140923150512.298991Z#000000#001#000000
Sep 23 17:05:12 sldapa01 slapd[1727]: syncrepl_message_to_entry:
rid=101 DN: uid=108284.22593,ou=users,o=test, UUID:
7d4fb488-a789-1033-9f1d-cd9d692f2885
Sep 23 17:05:12 sldapa01 slapd[1727]: syncrepl_entry: rid=101
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY)
Sep 23 17:05:12 sldapa01 slapd[1727]: => bdb_filter_candidates
Sep 23 17:05:12 sldapa01 slapd[1727]: #011AND
Sep 23 17:05:12 sldapa01 slapd[1727]: => bdb_list_candidates 0xa0
Sep 23 17:05:12 sldapa01 slapd[1727]: => bdb_filter_candidates
Sep 23 17:05:12 sldapa01 slapd[1727]: #011EQUALITY
Sep 23 17:05:12 sldapa01 slapd[1727]: <= bdb_filter_candidates: id=1
first=102822 last=102822
Sep 23 17:05:12 sldapa01 slapd[1727]: <= bdb_list_candidates: id=1
first=102822 last=102822
Sep 23 17:05:12 sldapa01 slapd[1727]: <= bdb_filter_candidates: id=1
first=102822 last=102822
Sep 23 17:05:12 sldapa01 slapd[1727]: => test_filter
Sep 23 17:05:12 sldapa01 slapd[1727]: EQUALITY
Sep 23 17:05:12 sldapa01 slapd[1727]: <= test_filter 6
Sep 23 17:05:12 sldapa01 slapd[1727]: syncrepl_entry: rid=101 be_search (0)
Sep 23 17:05:12 sldapa01 slapd[1727]: syncrepl_entry: rid=101
uid=108284.22593,ou=users,o=test
Sep 23 17:05:12 sldapa01 slapd[1727]: slap_queue_csn: queing
0x7ff278108d90 20140923150512.298991Z#000000#001#000000
Sep 23 17:05:12 sldapa01 slapd[1727]: slap_graduate_commit_csn:
removing 0x7ff27b1f5150 20140923150512.298991Z#000000#001#000000
Sep 23 17:05:12 sldapa01 slapd[1727]: syncrepl_entry: rid=101
be_modrdn uid=118284.22593,ou=users,o=test
Sep 23 17:05:12 sldapa01 slapd[1727]: slap_queue_csn: queing
0x7ff278108d90 20140923150512.298991Z#000000#001#000000
Sep 23 17:05:12 sldapa01 slapd[1727]: slap_graduate_commit_csn:
removing 0x7ff27b1f3260 20140923150512.298991Z#000000#001#000000
Logfile on mirror mode master:
Sep 23 17:05:11 mldapa01 slapd[2237]: do_syncrep2: rid=100
cookie=rid=100,sid=001,csn=20140923150512.298991Z#000000#001#000000
Sep 23 17:05:11 mldapa01 slapd[2237]: syncrepl_message_to_entry:
rid=100 DN: uid=108284.22593,ou=users,o=test, UUID:
7d4fb488-a789-1033-9f1d-cd9d692f2885
Sep 23 17:05:11 mldapa01 slapd[2237]: syncrepl_entry: rid=100
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY)
Sep 23 17:05:11 mldapa01 slapd[2237]: => bdb_filter_candidates
Sep 23 17:05:11 mldapa01 slapd[2237]: #011AND
Sep 23 17:05:11 mldapa01 slapd[2237]: => bdb_list_candidates 0xa0
Sep 23 17:05:11 mldapa01 slapd[2237]: => bdb_filter_candidates
Sep 23 17:05:11 mldapa01 slapd[2237]: #011EQUALITY
Sep 23 17:05:11 mldapa01 slapd[2237]: <= bdb_filter_candidates: id=1
first=102822 last=102822
Sep 23 17:05:11 mldapa01 slapd[2237]: <= bdb_list_candidates: id=1
first=102822 last=102822
Sep 23 17:05:11 mldapa01 slapd[2237]: <= bdb_filter_candidates: id=1
first=102822 last=102822
Sep 23 17:05:11 mldapa01 slapd[2237]: => test_filter
Sep 23 17:05:11 mldapa01 slapd[2237]: EQUALITY
Sep 23 17:05:11 mldapa01 slapd[2237]: <= test_filter 6
Sep 23 17:05:11 mldapa01 slapd[2237]: syncrepl_entry: rid=100 be_search (0)
Sep 23 17:05:11 mldapa01 slapd[2237]: syncrepl_entry: rid=100
uid=108284.22593,ou=users,o=test
Sep 23 17:05:11 mldapa01 slapd[2237]: slap_queue_csn: queing
0x7f270b394ad0 20140923150512.298991Z#000000#001#000000
Sep 23 17:05:11 mldapa01 slapd[2237]: syncprov_matchops: skipping
original sid 001
Sep 23 17:05:11 mldapa01 slapd[2237]: slap_graduate_commit_csn:
removing 0x7f27120a2200 20140923150512.298991Z#000000#001#000000
Sep 23 17:05:11 mldapa01 slapd[2237]: syncprov_matchops: skipping
original sid 001
Sep 23 17:05:11 mldapa01 slapd[2237]: => bdb_filter_candidates
Sep 23 17:05:11 mldapa01 slapd[2237]: #011AND
Sep 23 17:05:11 mldapa01 slapd[2237]: => bdb_list_candidates 0xa0
Sep 23 17:05:11 mldapa01 slapd[2237]: => bdb_filter_candidates
Sep 23 17:05:11 mldapa01 slapd[2237]: #011OR
Sep 23 17:05:11 mldapa01 slapd[2237]: => bdb_list_candidates 0xa1
Sep 23 17:05:11 mldapa01 slapd[2237]: => bdb_filter_candidates
Sep 23 17:05:11 mldapa01 slapd[2237]: #011EQUALITY
Sep 23 17:05:11 mldapa01 slapd[2237]: syncrepl_entry: rid=100
be_modrdn uid=118284.22593,ou=users,o=test
Sep 23 17:05:11 mldapa01 slapd[2237]: <= bdb_filter_candidates: id=0
first=0 last=0
Sep 23 17:05:11 mldapa01 slapd[2237]: => bdb_filter_candidates
Sep 23 17:05:11 mldapa01 slapd[2237]: #011OR
Sep 23 17:05:11 mldapa01 slapd[2237]: => bdb_list_candidates 0xa1
Sep 23 17:05:11 mldapa01 slapd[2237]: => bdb_filter_candidates
Sep 23 17:05:11 mldapa01 slapd[2237]: #011EXT
Sep 23 17:05:11 mldapa01 slapd[2237]: <= bdb_filter_candidates: id=-1
first=1 last=102893
Sep 23 17:05:11 mldapa01 slapd[2237]: <= bdb_list_candidates: id=-1
first=1 last=102893
Sep 23 17:05:11 mldapa01 slapd[2237]: <= bdb_filter_candidates: id=-1
first=1 last=102893
Sep 23 17:05:11 mldapa01 slapd[2237]: <= bdb_list_candidates: id=-1
first=1 last=102893
Sep 23 17:05:11 mldapa01 slapd[2237]: <= bdb_filter_candidates: id=-1
first=1 last=102893
Sep 23 17:05:11 mldapa01 slapd[2237]: <= bdb_list_candidates: id=-1
first=1 last=102893
Sep 23 17:05:11 mldapa01 slapd[2237]: <= bdb_filter_candidates: id=-1
first=1 last=102893
Sep 23 17:05:11 mldapa01 slapd[2237]: => test_filter
Sep 23 17:05:11 mldapa01 slapd[2237]: OR
Sep 23 17:05:11 mldapa01 slapd[2237]: => test_filter_or
Sep 23 17:05:11 mldapa01 slapd[2237]: => test_filter
Sep 23 17:05:11 mldapa01 slapd[2237]: EXT
Sep 23 17:05:11 mldapa01 slapd[2237]: <= test_filter 5
Sep 23 17:05:11 mldapa01 slapd[2237]: <= test_filter_or 5
Sep 23 17:05:11 mldapa01 slapd[2237]: <= test_filter 5
Sep 23 17:05:11 mldapa01 slapd[2237]: => test_filter
8 years, 12 months
way to validate server certificate
by Bin Lu
Hi,
Does openldap provide APIs to do server certificate validation? Can I retrieve the server cert from LDAP connection and do the validation myself or by passing the trusted CA list openldap will do it (in this case, how the hostname matching with the subject DN is performed)?
Thanks a lot in advance,
-blu
8 years, 12 months
Delta-syncrepl Consumer refresh entry
by unimore
Hi all,
once in a while, a modification entry in cn=accesslog on provider is
lost by consumer (both openldap-2.4.39). Later modifies on the same
entry are cought up, but entry is now inconsistent.
If I am right, eventually a "janitor process" recognizes messed up
entries and fixes them, but in my limited scenario it could take hours.
Is there a way to force consumer to refresh a given entry?
Thank you for your patience,
Francesco
8 years, 12 months
