openldap-technical

openldap-technical@openldap.org

3 participants
9990 discussions

Re: Syncrepl and mmr
by Michael Ströder 31 Jan '14

31 Jan '14

Borresen, John - 0442 - MITLL wrote: > I'm not trying to implement partial replication. Missed the smiley? Your *first* ACL should give read access to the whole tree to the group of replicas and then pass on all other access checking to the subsequent ACLs (by * break). Something like: limits group="cn=replicas,dc=example,dc=com" time=unlimited size=unlimited access to dn.subtree="ou=ampua" by group="cn=replicas,dc=example,dc=com" read by * break Ciao, Michael. > -----Original Message----- > From: Michael Ströder [mailto:michael@stroeder.com] > Sent: Friday, January 31, 2014 2:15 PM > To: Quanah Gibson-Mount; Borresen, John - 0442 - MITLL; openldap-technical(a)openldap.org > Subject: Re: Syncrepl and mmr > > Quanah Gibson-Mount wrote: >> --On Friday, January 31, 2014 1:20 PM -0500 "Borresen, John - 0442 - MITLL" >> <John.Borresen(a)ll.mit.edu> wrote: >> >>> Thanks, Quanah >>> >>> Not sure what you meant by " Well, it may not have been this issue, but >>> it definite would become an issue then." >>> >>> Was what I did a good thing or not? Curious minds want to know. <lol> >> >> The lack of read permissions for the replication user would absolutely be an >> issue at some point. ;) > > To put it the other way round: > It's very hard to implement partial replication correctly. ;-} > > Ciao, Michael.

2 1

RE: Syncrepl and mmr
by Quanah Gibson-Mount 31 Jan '14

31 Jan '14

--On Friday, January 31, 2014 2:25 PM -0500 "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu> wrote: > I'm not trying to implement partial replication. Throwing darts from 100 > miles away and trying to hit a penny nailed to the opposite side of > tree...yes that is what I feel like I'm doing. : At this point, I've no idea what you've done to break your servers in relation to TLS. I would ask what SSL implementation you are linked to (Openssl, GnuTLS, or MozNSS). --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

2 1

RE: Syncrepl and mmr
by Quanah Gibson-Mount 31 Jan '14

31 Jan '14

--On Friday, January 31, 2014 1:20 PM -0500 "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu> wrote: > Thanks, Quanah > > Not sure what you meant by " Well, it may not have been this issue, but > it definite would become an issue then." > > Was what I did a good thing or not? Curious minds want to know. <lol> The lack of read permissions for the replication user would absolutely be an issue at some point. ;) > MM Server1: ># ldapsearch -H ldap://mm-server1.example.ldap -d 256 -x -D ># cn=admin,cn=config -W -ZZ -b olcDatabase=\{1\}bdb,cn=config olcSyncrepl What CA cert is your ldapsearch command using? --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

3 4

RE: Syncrepl and mmr
by Quanah Gibson-Mount 31 Jan '14

31 Jan '14

--On Friday, January 31, 2014 8:54 AM -0500 "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu> wrote: > Thanks Quanah > > I'm sure it isn't 100% correct, but I added the following ACL to my > accesslog DB on both MM servers: > > olcAccess: to * by dn="cn=ldapadmin,dc=group42,dc=ldap" read by * none Well, it may not have been this issue, but it definite would become an issue then. ;) > I'm still seeing > gp42-admin3 (MM server1) > Jan 31 08:25:17 gp42-admin3 slapd[3599]: conn=5551 op=2 SRCH > base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)" Jan 31 > 08:25:17 gp42-admin3 slapd[3599]: conn=5551 op=2 SRCH attr=reqDN reqType > reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jan 31 08:25:17 > gp42-admin3 slapd[3599]: do_syncrep2: rid=001 got empty syncUUID with > LDAP_SYNC_ADD (cn=accesslog) Jan 31 08:25:17 gp42-admin3 slapd[3599]: > do_syncrepl: rid=001 rc -1 retrying Jan 31 08:25:17 gp42-admin3 > slapd[3599]: send_search_entry: conn 5551 ber write failed. Jan 31 > 08:25:17 gp42-admin3 slapd[3599]: conn=5551 fd=32 closed (connection lost > on write) Jan 31 08:25:17 gp42-admin3 slapd[3599]: do_syncrep2: rid=002 > got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 31 08:25:17 > gp42-admin3 slapd[3599]: do_syncrepl: rid=002 rc -1 retrying Your masters are unable to talk to each other. You need to determine why. This will take debugging on your part, as I've never seen anything like this before. > gp42-admin4 (MM server2) > Jan 31 08:25:19 gp42-admin4 slapd[26000]: conn=8050 fd=101 ACCEPT from > IP=155.34.133.73:10446 (IP=0.0.0.0:389) Jan 31 08:25:19 gp42-admin4 > slapd[26000]: conn=8050 op=0 BIND dn="dc=group42,dc=ldap" method=163 Jan > 31 08:25:19 gp42-admin4 slapd[26000]: conn=8050 op=0 RESULT tag=97 err=13 > text=TLS confidentiality required Jan 31 08:25:19 gp42-admin4 > slapd[26000]: conn=8050 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" > method=128 Jan 31 08:25:19 gp42-admin4 slapd[26000]: conn=8050 op=1 > RESULT tag=97 err=13 text=TLS confidentiality required Jan 31 08:25:19 > gp42-admin4 slapd[26000]: conn=8050 op=2 UNBIND > Jan 31 08:25:19 gp42-admin4 slapd[26000]: conn=8050 fd=101 closed > Jan 31 08:25:51 gp42-admin4 slapd[26000]: do_syncrep2: rid=001 got empty > syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 31 08:25:51 gp42-admin4 > slapd[26000]: do_syncrepl: rid=001 rc -1 retrying This says that your consumer is connecting without sending a startTLS, while you've configured the master to require startTLS. Clearly you need to either enable startTLS in the syncrepl statement, or not require starttls on your master. --Quanah > -----Original Message----- > From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] > Sent: Thursday, January 30, 2014 5:10 PM > To: Borresen, John - 0442 - MITLL; openldap-technical(a)openldap.org > Subject: RE: Syncrepl and mmr > > --On Thursday, January 30, 2014 4:51 PM -0500 "Borresen, John - 0442 - > MITLL" <John.Borresen(a)ll.mit.edu> wrote: > >> Well, that was helpful -- lol > > > Looking at your previously supplied configuration, it is clearly apparent > that you provided your replication user no ACLs to read the accesslog DB, > so the error you see makes sense. It can't read the data out of > accesslog, so it throws an error stating that fact. > > --Quanah > > -- > > Quanah Gibson-Mount > Architect - Server > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

2 1

RE: Syncrepl and mmr
by Quanah Gibson-Mount 31 Jan '14

31 Jan '14

--On Thursday, January 30, 2014 4:51 PM -0500 "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu> wrote: > Well, that was helpful -- lol Looking at your previously supplied configuration, it is clearly apparent that you provided your replication user no ACLs to read the accesslog DB, so the error you see makes sense. It can't read the data out of accesslog, so it throws an error stating that fact. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

2 1

Re: Overlay ppolicy not found
by Dieter Klünter 31 Jan '14

31 Jan '14

Am Thu, 30 Jan 2014 12:13:04 +0000 schrieb Rodrigo Coutinho <Rodrigo.Coutinho(a)ifap.pt>: > Hi again, > > Th result was: > > Included static overlays: > syncprov > Included static backends: > config > ldif > monitor > bdb > hdb > mdb > relay > > What now? Check with your OS Distribution whether there are additional dynamic loadable modules. -Dieter -- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E

2 1

RE: Syncrepl and mmr
by Quanah Gibson-Mount 31 Jan '14

31 Jan '14

--On Thursday, January 30, 2014 4:25 PM -0500 "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu> wrote: > Thanks Quanah... > > Question, about the "manage" Access Level when would that be used? > > It is not talked about at all other than Table 5.4 in section 8.3.3. The man pages are the definitive source for all information. I would suggest you read the slapd.access(5) man page. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

4 3

RE: Syncrepl and mmr
by Quanah Gibson-Mount 30 Jan '14

30 Jan '14

--On Thursday, January 30, 2014 4:51 PM -0500 "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu> wrote: > All Masters in the chain have the olcServerID's and olcSynRepl for itself > and its partner? I can understand having each knowing about the others > but why itself? It's replicating to itself? It knows about itself so it knows what to ignore. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

RE: Syncrepl and mmr
by Quanah Gibson-Mount 30 Jan '14

30 Jan '14

--On Thursday, January 30, 2014 4:35 PM -0500 "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu> wrote: > Seeing the following in the logs: > > Jan 30 16:28:41 gp42-admin4 slapd[26000]: do_syncrep2: rid=001 got empty > syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 30 16:28:41 gp42-admin4 > slapd[26000]: do_syncrepl: rid=001 rc -1 retrying > > Jan 30 16:33:02 gp42-admin3 slapd[3599]: do_syncrep2: rid=002 got empty > syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 30 16:33:02 gp42-admin3 > slapd[3599]: do_syncrepl: rid=002 rc -1 retrying Sounds like you managed to break your system somehow. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

2 1

RE: Syncrepl and mmr
by Quanah Gibson-Mount 30 Jan '14

30 Jan '14

--On Thursday, January 30, 2014 3:28 PM -0500 "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu> wrote: > Thanks Quanah... > > Now, I'm going to ask this... > > My current ACL is: > > olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by > anonymous auth by * none olcAccess: {1}to * by * read > > Supposed this allows the user to modify their userPassword and (in so > doing) modifying the shadowLastChange, allows anonymous to authenticate > against these entries and allows others to read these entries > > Am I reading that correctly...or at least close? > > To give my syncrepl user (ldapadmin) access, my new ACL would another > olcAccess: > > olcAccess:{2}to * by cn=ldapdmin manage > > Is that correct? I would suggest you re-read the documentation on ACLs. As noted in the ACL documentation, ACL processing STOPS on the first matching ACL by default. So NO ACL is evaluated for userPassword and ShadowLastChange if they do not match the self write, anonymous auth bits. What you would want is something like: olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by replicauser read by * none olcAccess: {1}to * by * read I.e, specifically grant read access to those 2 attrs to whatever the DN is for your replication user. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical