[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Syncrepl and mmr



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)

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: secret
>
> second 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: secret
>
> This 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.la
>
> Now 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