"Borresen, John - 0442 - MITLL" John.Borresen@ll.mit.edu schrieb am
19.02.2014 um 20:20 in Nachricht 201402191921.s1JJL9q9079356@boole.openldap.org:
Thanks Quanah for your reply. It answered a lot of questions.
I took a back step, and slapcat'd all my cn=configs and main_dbase from all three servers, then ran slapadd to put each into place. Taking one of the cn=configs (using mm-server2's) I modified it for each server pretty much based on your suggestions below to set up Syncreplication with mm-server1 as the master (right now). When I brought them up, they were replicating (I was so happy!) --> any change I made on mm-server1 was immediately replicated over to mm-server2 and 3.
I did learn a great deal over the last week or so. Patience being one of them. I will forward to you in a separate email my cn=configs.
When running slapadd, I did run into this error (which I resolved -- but am curious about) on mm-server1:
First had this (mm-server1): 5304e1ff olcMirrorMode: value #0: <olcMirrorMode> database is not a shadow slapadd: could not add entry dn=olcDatabase={1}bdb,cn=config (line=2260)
Shouldn't it be like: dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config
Resolution: set olcMirrorMode to FALSE (made this change on the other servers' ldifs)
This caused an error when, later, running ldapmodify on the main dbase when all servers were running slapd.
ldap_modify: server unwilling to perform (53) additional info: shadow context: no update referral
Resolution: Removed olcMirrorMode from all ldifs.
Why, even with it set to FALSE, would MirrorMode cause this issue?
Thanks,
John
-----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: Wednesday, February 19, 2014 2:02 PM To: Borresen, John - 0442 - MITLL; openldap-technical@openldap.org Subject: RE: Syncrepl and mmr
Hi John,
SIDs (server IDs) must be unique across servers.
RIDs (replication IDs) must be unique inside a single server.
So the answer to your question is essentially "no".
If you email me your full cn=config db bits from both servers (minus passwords), there's some cleanup on them I can send back.
The serverID: 1 <URI> bit is only necessary if you are doing cn=config replication, which you are not doing. If you are going to use the <#> <URI> form, then the <URI> must EXACTLY MATCH the arguments slapd is being started with.
Personally, since I do not do cn=config replication, and the URIs are customizable by customers, I go with the much simpler:
olcServerID: <#>
form. Then each server only has a single value for olcServerID, which is its specific serverID. This way I never have to worry that MMR replication is going to get mesed up because of URI changes.
--Quanah
--On Tuesday, February 18, 2014 10:09 AM -0500 "Borresen, John - 0442 - MITLL" John.Borresen@ll.mit.edu wrote:
All,
The long weekend didn't help...still at a loss. Question...
If the olcServerIDs look like, on all three servers:
olcServerID: 1 ldap://mm-server1.example.ldap olcServerID: 2 ldap://mm-server2.example.ldap olcServerID: 3 ldap://mm-server3.example.ldap
Should the Replica IDs (rid) in the olcSycnrepl directive be:
olcSyncrepl: {0} rid=001 provider=mm-server1.example.ldap bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> interval=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +"
filter="(objectClass=*)" attrs=*,+"
syncdata=accesslog starttls=no olcSyncrepl: {1} rid=002 provider=mm-server2.example.ldap bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> interval=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no olcSyncrepl: {0} rid=003 provider=mm-server3.example.ldap bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> interval=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +"
filter="(objectClass=*)" attrs=*,+"
syncdata=accesslog starttls=no
OR
olcSyncrepl: {0} rid=1 provider=mm-server1.example.ldap bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> interval=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no olcSyncrepl: {1} rid=2 provider=mm-server2.example.ldap bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> interval=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no olcSyncrepl: {0} rid=3 provider=mm-server3.example.ldap bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> interval=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no
OR
Does it matter?
Also, should the all three olcSycrepl directives be loaded on all three servers so they look identical. What I mean by that is should each Server "replicate" to itself? There is confusion on this matter. I asked Quanah that back in late January, and he stated that the system knows about itself so it knows what to ignore. Then last week, he asked why I had the master replicating to itself.
Also, since I have refreshAndPersist configured do I need an interval as well?
Thanks in advance,
John
-----Original Message----- From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Borresen, John - 0442 - MITLL Sent: Friday, February 14, 2014 4:28 PM To: Quanah Gibson-Mount; openldap-technical@openldap.org Subject: RE: Syncrepl and mmr
All,
I just created an mm-server3, using the config_dbase and main_dbase from mm-server2 -- copied the ldif's I created from mm-server2 then ran slapadd.
On mm-server3: olcServerID: 1 ldap://mm-server1.example.ldap olcServerID: 2 ldap://mm-server2.example.ldap olcServerID: 3 ldap://mm-server3.example.ldap
olcSyncrepl: {0} rid=001 provider=mm-server1.example.ldap bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> interval=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +"
filter="(objectClass=*)" attrs=*,+"
syncdata=accesslog starttls=no olcSyncrepl: {1} rid=002 provider=mm-server2.example.ldap bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> interval=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no olcSyncrepl: {0} rid=003 provider=mm-server3.example.ldap bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> interval=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +"
filter="(objectClass=*)" attrs=*,+"
syncdata=accesslog starttls=no
Started slapd, no errors. It immediately sync'd up with mm-server1! Changes that I made on mm-server1 days ago which have never replicated over to mm-server2...replicated to mm-server3 immediately on startup.
I had not even got around to adding mm-server3 to mm-server1 (or mm-server2) yet.
The olcServerIDs and olcSyncrepl on both mm-server1 and 2 show: olcServerID: 1 ldap://mm-server1.example.ldap olcServerID: 2 ldap://mm-server2.example.ldap
olcSyncrepl: {0} rid=001 provider=mm-server1.example.ldap bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> interval=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +"
filter="(objectClass=*)" attrs=*,+"
syncdata=accesslog starttls=no olcSyncrepl: {1} rid=002 provider=mm-server2.example.ldap bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> interval=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no
So...now, I am at even more of a loss. Why would mm-server1 be replicating to mm-server3 and not 2? When the configs are the same between mm-server2 and 3???
Thanks in advance... John
-----Original Message----- From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Borresen, John - 0442 - MITLL Sent: Friday, February 14, 2014 1:34 PM To: Quanah Gibson-Mount; openldap-technical@openldap.org Subject: RE: Syncrepl and mmr
All,
If I went off the beaten' path...where did I go wrong? (my config and error messages are in a previous posting)
Thanks in advance, John
-----Original Message----- From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Borresen, John - 0442 - MITLL Sent: Friday, February 14, 2014 8:40 AM To: Quanah Gibson-Mount; openldap-technical@openldap.org Subject: RE: Syncrepl and mmr
Thanks Quanah,
A few weeks back I asked that question (on 1/30):
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?
-You replied -It knows about itself so it knows what to ignore.
Even in the Admin Guide is specifies setting it up that way...each server has all the others and itself listed. I was following the procedures delineated in the Admin Guide and in the man-pages (including how I understood what was put out on the board): From the Admin
Guide:
8.3.3. N-Way Multi-Master
For the following example we will be using 3 Master nodes. Keeping in line with test050-syncrepl-multimaster of the OpenLDAP test suite, we will be configuring slapd(8) via cn=config
This sets up the config database:
dn: cn=config objectClass: olcGlobal cn: config olcServerID: 1 dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW: secretsecond and third servers will have a different olcServerID obviously:
dn: cn=config objectClass: olcGlobal cn: config olcServerID: 2 dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW: secretThis sets up syncrepl as a provider (since these are all masters):
dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulePath: /usr/local/libexec/openldap olcModuleLoad: syncprov.laNow we setup the first Master Node (replace $URI1, $URI2 and $URI3 etc. with your actual ldap urls):
dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 $URI1 olcServerID: 2 $URI2 olcServerID: 3 $URI3 dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=$URI1 binddn="cn=config"bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=002 provider=$URI2 binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=003 provider=$URI3 binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 - add: olcMirrorMode olcMirrorMode: TRUE
I followed what is put in the Admin Guide, etc...
Thanks
-----Original Message----- From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Quanah Gibson-Mount Sent: Thursday, February 13, 2014 1:57 PM To: Borresen, John - 0442 - MITLL; openldap-technical@openldap.org Subject: Re: Syncrepl and mmr
--On Thursday, February 13, 2014 10:54 AM -0500 "Borresen, John - 0442
- MITLL" John.Borresen@ll.mit.edu wrote:
All,
Your configuration is very confused. Why do you have the master replicate to itself, for example?
--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