I am running OpenLDAP 2.4.44 locally built on RHEL7 using mdb as the database backend. I am attempting to replicate just the inetLocalMailRecipient objectclass and the DSA attributes to a new set of replicas that will be in charge of delivering mail. I would like the DSA attributes (creator, modifier, contextCSN, entryCSN, entryUUID - etc) to be included, so I can more easily tell if the partial replica is actually staying sync'd to the master.
My reading of the man pages for slapd.conf and slapd.access have me part way there, but setting up a replication DN and using acls to limit its access to the inetLocalMailRecipient objectclass. What I'm not finding is a way to specify all of (what I'm calling) the DSA attributes (without naming them all individually) - have I missed something in the man pages or is the source code (or the benevolence of one of you good folks) my only hope?
--On Thursday, May 19, 2016 10:11 AM -0400 Frank Swasey Frank.Swasey@uvm.edu wrote:
I am running OpenLDAP 2.4.44 locally built on RHEL7 using mdb as the database backend. I am attempting to replicate just the inetLocalMailRecipient objectclass and the DSA attributes to a new set of replicas that will be in charge of delivering mail. I would like the DSA attributes (creator, modifier, contextCSN, entryCSN, entryUUID - etc) to be included, so I can more easily tell if the partial replica is actually staying sync'd to the master.
My reading of the man pages for slapd.conf and slapd.access have me part way there, but setting up a replication DN and using acls to limit its access to the inetLocalMailRecipient objectclass. What I'm not finding is a way to specify all of (what I'm calling) the DSA attributes (without naming them all individually) - have I missed something in the man pages or is the source code (or the benevolence of one of you good folks) my only hope?
+
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc
Today at 10:37am, Quanah Gibson-Mount wrote:
--On Thursday, May 19, 2016 10:11 AM -0400 Frank Swasey Frank.Swasey@uvm.edu wrote:
I am running OpenLDAP 2.4.44 locally built on RHEL7 using mdb as the database backend. I am attempting to replicate just the inetLocalMailRecipient objectclass and the DSA attributes to a new set of replicas that will be in charge of delivering mail. I would like the DSA attributes (creator, modifier, contextCSN, entryCSN, entryUUID - etc) to be included, so I can more easily tell if the partial replica is actually staying sync'd to the master.
My reading of the man pages for slapd.conf and slapd.access have me part way there, but setting up a replication DN and using acls to limit its access to the inetLocalMailRecipient objectclass. What I'm not finding is a way to specify all of (what I'm calling) the DSA attributes (without naming them all individually) - have I missed something in the man pages or is the source code (or the benevolence of one of you good folks) my only hope?
Sadly, slapd will not start with the following acl:
access to attrs=@inetLocalMailRecipient,+ by dn.exact="cn=MailReplicator,dc=example,dc=com" read by * break
It does not like the + in the attrs.
--On Thursday, May 19, 2016 12:18 PM -0400 Frank Swasey Frank.Swasey@uvm.edu wrote:
Today at 10:37am, Quanah Gibson-Mount wrote:
--On Thursday, May 19, 2016 10:11 AM -0400 Frank Swasey Frank.Swasey@uvm.edu wrote:
I am running OpenLDAP 2.4.44 locally built on RHEL7 using mdb as the database backend. I am attempting to replicate just the inetLocalMailRecipient objectclass and the DSA attributes to a new set of replicas that will be in charge of delivering mail. I would like the DSA attributes (creator, modifier, contextCSN, entryCSN, entryUUID
- etc) to be included, so I can more easily tell if the partial replica
is actually staying sync'd to the master.
My reading of the man pages for slapd.conf and slapd.access have me part way there, but setting up a replication DN and using acls to limit its access to the inetLocalMailRecipient objectclass. What I'm not finding is a way to specify all of (what I'm calling) the DSA attributes (without naming them all individually) - have I missed something in the man pages or is the source code (or the benevolence of one of you good folks) my only hope?
Sadly, slapd will not start with the following acl:
access to attrs=@inetLocalMailRecipient,+ by dn.exact="cn=MailReplicator,dc=example,dc=com" read by * break
It does not like the + in the attrs.
I would put it in the syncrepl attr list.
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc
Today at 11:36am, Quanah Gibson-Mount wrote:
--On Thursday, May 19, 2016 12:18 PM -0400 Frank Swasey Frank.Swasey@uvm.edu wrote:
Today at 10:37am, Quanah Gibson-Mount wrote:
--On Thursday, May 19, 2016 10:11 AM -0400 Frank Swasey Frank.Swasey@uvm.edu wrote:
I am running OpenLDAP 2.4.44 locally built on RHEL7 using mdb as the database backend. I am attempting to replicate just the inetLocalMailRecipient objectclass and the DSA attributes to a new set of replicas that will be in charge of delivering mail. I would like the DSA attributes (creator, modifier, contextCSN, entryCSN, entryUUID
- etc) to be included, so I can more easily tell if the partial replica
is actually staying sync'd to the master.
My reading of the man pages for slapd.conf and slapd.access have me part way there, but setting up a replication DN and using acls to limit its access to the inetLocalMailRecipient objectclass. What I'm not finding is a way to specify all of (what I'm calling) the DSA attributes (without naming them all individually) - have I missed something in the man pages or is the source code (or the benevolence of one of you good folks) my only hope?
Sadly, slapd will not start with the following acl:
access to attrs=@inetLocalMailRecipient,+ by dn.exact="cn=MailReplicator,dc=example,dc=com" read by * break
It does not like the + in the attrs.
I would put it in the syncrepl attr list.
Having not specified an attr list on the syncrepl, it was already defaulting to "*,+" - what I have discovered is I have to allow the MailReplicator dn to see the contextCSN attribute, but the syncrepl attrs of "*,+" gets the rest of the DSA attributes. I guess contextCSN is not a DSA attribute.
Frank Swasey wrote:
Today at 11:36am, Quanah Gibson-Mount wrote:
--On Thursday, May 19, 2016 12:18 PM -0400 Frank Swasey Frank.Swasey@uvm.edu wrote:
Today at 10:37am, Quanah Gibson-Mount wrote:
--On Thursday, May 19, 2016 10:11 AM -0400 Frank Swasey Frank.Swasey@uvm.edu wrote:
I am running OpenLDAP 2.4.44 locally built on RHEL7 using mdb as the database backend. I am attempting to replicate just the inetLocalMailRecipient objectclass and the DSA attributes to a new set of replicas that will be in charge of delivering mail. I would like the DSA attributes (creator, modifier, contextCSN, entryCSN, entryUUID
- etc) to be included, so I can more easily tell if the partial replica
is actually staying sync'd to the master.
My reading of the man pages for slapd.conf and slapd.access have me part way there, but setting up a replication DN and using acls to limit its access to the inetLocalMailRecipient objectclass. What I'm not finding is a way to specify all of (what I'm calling) the DSA attributes (without naming them all individually) - have I missed something in the man pages or is the source code (or the benevolence of one of you good folks) my only hope?
Sadly, slapd will not start with the following acl:
access to attrs=@inetLocalMailRecipient,+ by dn.exact="cn=MailReplicator,dc=example,dc=com" read by * break
It does not like the + in the attrs.
I would put it in the syncrepl attr list.
Having not specified an attr list on the syncrepl, it was already defaulting to "*,+" - what I have discovered is I have to allow the MailReplicator dn to see the contextCSN attribute, but the syncrepl attrs of "*,+" gets the rest of the DSA attributes. I guess contextCSN is not a DSA attribute.
The contextCSN is used in replication, but it does not get replicated itself. Each replica maintains its own.
On Thu, 19 May 2016 at 3:10pm, Howard Chu wrote:
The contextCSN is used in replication, but it does not get replicated itself. Each replica maintains its own.
I was testing my partial replication against my test MMR setup. I have discovered that the database suffix in the two MMR's have two contextCSN values. The code I was using to test was checking the first contextCSN value returned from the "master" server - which is not the "current" CSN against the value generated by the replica. I have not (yet) figured out what that first of the two values is indicating.
Frank Swasey Frank.Swasey@uvm.edu schrieb am 24.05.2016 um 14:10 in Nachricht
alpine.OSX.2.20.1605240743160.16039@vc0ns51415.vag.hiz.rqh:
On Thu, 19 May 2016 at 3:10pm, Howard Chu wrote:
The contextCSN is used in replication, but it does not get replicated
itself.
Each replica maintains its own.
I was testing my partial replication against my test MMR setup. I have discovered that the database suffix in the two MMR's have two contextCSN values. The code I was using to test was checking the first contextCSN value returned from the "master" server - which is not the "current" CSN against the value generated by the replica. I have not (yet) figured out what that first of the two values is indicating.
I think there is one CSN per ServerID, like this: contextCSN: 20130722065709.189194Z#000000#000#000000 contextCSN: 20160222141054.581517Z#000000#001#000000 (or another context) contextCSN: 20130719093756.074776Z#000000#000#000000 contextCSN: 20160517103616.692516Z#000000#001#000000 contextCSN: 20151007103227.123574Z#000000#002#000000
-- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900)
On Tue, 24 May 2016 at 10:07am, Ulrich Windl wrote:
Frank Swasey Frank.Swasey@uvm.edu schrieb am 24.05.2016 um 14:10 in Nachricht
alpine.OSX.2.20.1605240743160.16039@vc0ns51415.vag.hiz.rqh:
On Thu, 19 May 2016 at 3:10pm, Howard Chu wrote:
The contextCSN is used in replication, but it does not get replicated
itself.
Each replica maintains its own.
I was testing my partial replication against my test MMR setup. I have discovered that the database suffix in the two MMR's have two contextCSN values. The code I was using to test was checking the first contextCSN value returned from the "master" server - which is not the "current" CSN against the value generated by the replica. I have not (yet) figured out what that first of the two values is indicating.
I think there is one CSN per ServerID, like this: contextCSN: 20130722065709.189194Z#000000#000#000000 contextCSN: 20160222141054.581517Z#000000#001#000000 (or another context) contextCSN: 20130719093756.074776Z#000000#000#000000 contextCSN: 20160517103616.692516Z#000000#001#000000 contextCSN: 20151007103227.123574Z#000000#002#000000
It appears that each master (I have two, ServerID 1 and 2 respectively) sets its own contextCSN (the 00[012] segments are the serverid numbers) and I guess updates based on entryCSN values for the other servers. My own two servers have the following contextCSN values right now:
(ServerID 1) contextCSN: 20160525000023.928191Z#000000#000#000000 contextCSN: 20160525135840.176813Z#000000#001#000000 contextCSN: 20160525102003.058340Z#000000#002#000000
(ServerID 2) contextCSN: 20160525000023.928191Z#000000#000#000000 contextCSN: 20160525135840.176813Z#000000#001#000000 contextCSN: 20160525135906.347736Z#000000#002#000000
(Replica) contextCSN: 20160525102935.619902Z#000000#000#000000 contextCSN: 20160525135840.176813Z#000000#001#000000 contextCSN: 20160525135906.347736Z#000000#002#000000
So, it appears they have gone split brain on me - since they have not gotten to a place where they agree on what ServerID2's contextCSN should be.
The ServerID 0 records are the result of performing the initial slapadd from the non-MMR production system.
openldap-technical@openldap.org
-
Frank Swasey -
Howard Chu -
Quanah Gibson-Mount -
Ulrich Windl