openldap-technical September 2014

openldap-technical@openldap.org

48 participants
64 discussions

MMR - Add and delete entry on on server, CSN too old on the other and the entry is not deleted
by Meunier, Antonin 30 Sep '14

30 Sep '14

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

2 3

OpenLDAP manual sync (on-demand replication)
by Peter Boguszewski 30 Sep '14

30 Sep '14

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

3 3

access control with pbind overlay
by Ferenc Wagner 29 Sep '14

29 Sep '14

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.

2 5

can a automountMap be associated with a nisNetgroup
by Dal tee 26 Sep '14

26 Sep '14

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 ?

1 0

Help: Query unmodified non SSHA userPasswords
by Ulrich Windl 25 Sep '14

25 Sep '14

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

4 5

Sync Repl - mirror mode - rid=001 LDAP_RES_INTERMEDIATE - REFRESH_DELETE
by Sterling Sahaydak 25 Sep '14

25 Sep '14

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

1 0

(ITS#7274) delta-syncrepl MMR infinite loop - like issue?
by Francesco Malvezzi 25 Sep '14

25 Sep '14

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;s… 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

1 0

slapo-refint not working on consumer.
by Mike Hulsman 25 Sep '14

25 Sep '14

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

2 3

way to validate server certificate
by Bin Lu 24 Sep '14

24 Sep '14

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

6 11

Delta-syncrepl Consumer refresh entry
by unimore 24 Sep '14

24 Sep '14

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

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical September 2014