openldap-technical June 2017

openldap-technical@openldap.org

34 participants
69 discussions

Re: mmr pair stops replicating: "consumer state is newer than provider"
by Quanah Gibson-Mount 29 Jun '17

29 Jun '17

--On Thursday, June 29, 2017 2:12 AM -0400 btb <btb(a)bitrate.net> wrote: > i see, thanks. i tested this, and did a modify on each, but didn't see > replication resume. emulating the syncrepl connection with a manual > search against each master, there do seem to be accesslog entries now, on > both masters: You may have to restart the consumers (I did when I ran into this). Also, there are 2 sets of CSNs per master that you need to examine -- The CSNs in your database root (i.e., dc=example,dc=org) and your accesslog root. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: syncrepl fails after upgrade to openldap 2.4.45
by Quanah Gibson-Mount 29 Jun '17

29 Jun '17

--On Thursday, June 29, 2017 5:07 PM +0100 Andrew Findlay <andrew.findlay(a)skills-1st.co.uk> wrote: > It seems that the CA cert was never referenced in the syncrepl clause, so > it would have dropped back to whatever TLS config was in the LDAP *client* > config file (probably /etc/ldap/ldap.conf). I seem to remember a change in > behaviour of OpenSSL libs a while ago where I was bitten by something > similar. Maybe Juergen's earlier setup used ldap.conf and the new one > is ignoring it? Could be. My specific suggestion to him was to add a line for the CA. Instead, he added a line for the CA and the two additional lines for a cert & key (which would imply certificate authentication). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

RE: syncrepl fails after upgrade to openldap 2.4.45
by Quanah Gibson-Mount 29 Jun '17

29 Jun '17

--On Monday, June 26, 2017 7:11 AM +0000 Juergen.Sprenger(a)swisscom.com wrote: > Cert authentication works on 2.4.44-r1 without any problem. Now you're switching topics. Your original mail did not include cert authentication, it used simple binds: syncrepl rid=000 provider=ldaps://ldap.dannatu.ch:636 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=dannatu,dc=ch" attrs="*,+" scope=sub bindmethod=simple binddn="cn=Manager,dc=dannatu,dc=ch" credentials=************** Either way, cert authentication AND TLS encrypted syncrepl both work for me with OpenSSL 1.0.2l and OpenLDAP 2.4.45 just fine, so I would have to again guess issues with proper TLS configuration. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: mmr pair stops replicating: "consumer state is newer than provider"
by Quanah Gibson-Mount 28 Jun '17

28 Jun '17

--On Tuesday, June 27, 2017 5:35 PM -0400 btb <btb(a)bitrate.net> wrote: > On 6/27/17 10:27 AM, Quanah Gibson-Mount wrote: >> --On Tuesday, June 27, 2017 10:37 AM -0400 btb <btb(a)bitrate.net> wrote: >>> i'm using 2.4.44 on freebsd, built from ports. i can provide any config >>> details etc - i just didn't want to inundate the post with guesses on >>> detail that might not be relevant. >> >> What is your accesslog purge setting? Do you have long periods of time >> with no write activity? > > there are some extended periods of time with no write activity, yes. That's one form of a known issue then with using accesslog (ITS#8100). I've made a suggestion on how it could be fixed, and Howard agreed that would be the correct solution. Just need the fix. :) In the meantime, you can set up a cronjob that does a modify once a day on some object that doesn't really do anything, like if you had: dn: cn=someobject,dc... objectClass: ... cn: someobject description: blah you could have a job that does: dn: cn=someobject,dc... changetype: modify replace: description description: blah So it in effect does nothing, but it keeps an active change in the accesslog alive. Basically what happens with the accesslog empty is that it'll end up generating its own new contextCSN that differs for that server than the one stored in the rootDB, and will be /newer/ than it as well, which is why you get that message. You can also fix the problem simply by doing a modify on each master, and it'll reset the contextCSNs and things will flow (i.e., no need to do a dump/reload, etc). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: N-Way multi-master configuration
by Quanah Gibson-Mount 28 Jun '17

28 Jun '17

--On Wednesday, June 28, 2017 11:25 PM +0100 Dave Lambley <dave.lambley(a)gmail.com> wrote: > What is the reason the documentation suggests "type=refreshOnly" for > data, but not for config? Should I expect any problems using > "type=refreshAndPersist" for data? The admin guide is simply giving information on how things can be done. It is not making recommendations on how things should be done. It is generally thought that people read through the pros and cons of different replication strategies and develop an understanding of what is likely best for them. I would note that running MMR with 2.4.31 is generally suicidal. I strongly advise upgrading to a current release. Please read the list of fixes in the 5 years since 2.4.31 was released: <http://www.openldap.org/software/release/changes.html> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

N-Way multi-master configuration
by Dave Lambley 28 Jun '17

28 Jun '17

We are using OpenLDAP 2.4.31 under Ubuntu 14.04, doing four way multi master replication. When I initially configured it, I set the data (as opposed to config) replication to be "type=refreshOnly", as described here, http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master That didn't work well, we lost insertions and and memory usage of some servers steadily over the two weeks I left it. Switching the replication to "type=refreshAndPersist" resolved both problems. What is the reason the documentation suggests "type=refreshOnly" for data, but not for config? Should I expect any problems using "type=refreshAndPersist" for data? Best regards, Dave Lambley

1 0

redMod with single colon
by Michael Ströder 28 Jun '17

28 Jun '17

HI! I have several accesslog entries with 'reqMod' containing a single colon. :-/ Example (excerpt): [..] reqMod: aeTicketId:- IAM-31 reqMod:: Og== reqMod: aeTicketId:+ IAM-201 reqMod: member:- uid=foo1,cn=ae,ou=ae-dir reqMod: member:- uid=foo2,cn=ae,ou=ae-dir reqMod:: Og== reqMod: member:+ uid=foo1,cn=ae,ou=ae-dir reqMod: member:+ uid=foo2,cn=ae,ou=ae-dir reqMod: member:+ uid=foo3,cn=ae,ou=ae-dir reqMod: memberUid:- foo1 reqMod: memberUid:- foo2 reqMod:: Og== reqMod: memberUid:+ foo1 reqMod: memberUid:+ foo2 reqMod: memberUid:+ foo3 [..] (before you ask: An account foo3 added to Æ-DIR user group with hybrid group schema compatible to RFC2307 and RFC2307bis.) Under which circumstances is slapo-accesslog writing a single colon? Currently I cannot easily reproduce it and I don't know what was so special about this particular modify operation (sent by web2ldap). Ciao, Michael.

2 1

Re: mmr pair stops replicating: "consumer state is newer than provider"
by Quanah Gibson-Mount 27 Jun '17

27 Jun '17

--On Tuesday, June 27, 2017 10:37 AM -0400 btb <btb(a)bitrate.net> wrote: > i'm using 2.4.44 on freebsd, built from ports. i can provide any config > details etc - i just didn't want to inundate the post with guesses on > detail that might not be relevant. What is your accesslog purge setting? Do you have long periods of time with no write activity? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Why didn't rfc2307bis supersede rfc2307?
by John Lewis 27 Jun '17

27 Jun '17

https://tools.ietf.org/html/draft-howard-rfc2307bis-02 They only thing that jumps at me is the name. It doesn't follow rfc norms. Normally a new standard would be rfc and then the next number available. This one deviated, It used the same number as the old one and appended text. The standard itself is good enough to be used by Active Directory and FreeIPA by default. I am having a really hard time finding anyone who says that the standard is bad. I am willing to bet that if Luke Howard puts out this latest proposal out under the name of the next available rfc number today, which according to ftp://ftp.rfc-editor.org/in-notes/rfc-ref.txt would be rfc8203 it will be approved before the end of the year. According to Ludo here https://ludopoitou.com/2011/04/20/linux-and-unix-ldap-clients-and-rfc2307-s… , I can campaign for the standard myself if I had permission from the authors. I would do it to streamline documentation and, get the new standard into OpenLDAP 2.5 so it will be in OpenLDAP 2.6 by default.

3 5

mmr pair stops replicating: "consumer state is newer than provider"
by btb 27 Jun '17

27 Jun '17

hi. i have two servers, in an mmr arrangement, using delta-syncrepl. on a couple of occasions, the servers have stopped replicating, and the following is logged: dsa1: Jun 27 06:13:29 ldap0 slapd[8699]: do_syncrep2: rid=000 LDAP_RES_SEARCH_RESULT Jun 27 06:13:29 ldap0 slapd[8699]: do_syncrep2: rid=000 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform Jun 27 06:13:29 ldap0 slapd[8699]: do_syncrep2: rid=000 (53) Server is unwilling to perform Jun 27 06:13:29 ldap0 slapd[8699]: do_syncrepl: rid=000 rc -2 retrying dsa2: Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 fd=9 ACCEPT from IP=10.200.41.20:49141 (IP=0.0.0.0:389) Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=0 STARTTLS Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=0 RESULT oid= err=0 text= Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 fd=9 TLS established tls_ssf=256 ssf=256 Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=1 BIND dn="uid=dsa1_slapd-repl-content,ou=dsa1.example.org,ou=services,ou=accounts,dc=example,dc=org" method=128 Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=1 BIND dn="uid=dsa1_slapd-repl-content,ou=dsa1.example.org,ou=services,ou=accounts,dc=example,dc=org" mech=SIMPLE ssf=0 Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=1 RESULT tag=97 err=0 text= Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=2 SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is newer than provider! Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=3 UNBIND Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 fd=9 closed if i reload data and restart replication, things work again, for a period of time, but then this happens again. what determines "consumer state is newer than provider"? i'm also a little bit confused about this message in the context of mmr. if one has newer data than the other, i had sort of expected that the newer data would replace the old [obviously it's not that simple, so i'd like to understand what i'm missing]. lastly, how can i further troubleshoot why this happened in the first place? i'm using 2.4.44 on freebsd, built from ports. i can provide any config details etc - i just didn't want to inundate the post with guesses on detail that might not be relevant. thanks -ben

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical June 2017