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

Antw: RE: Syncrepl and mmr

To: "John - 0442 - MITLL Borresen" <John.Borresen@ll.mit.edu>, "openldap-technical@openldap.org" <openldap-technical@openldap.org>, "Quanah Gibson-Mount" <quanah@zimbra.com>
Subject: Antw: RE: Syncrepl and mmr
From: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
Date: Thu, 20 Feb 2014 08:01:08 +0100
Content-disposition: inline
In-reply-to: <201402191921.s1JJL9q9079356@boole.openldap.org>
References: <201402131554.s1DFsndc032876@boole.openldap.org> <88E13387E9F3EF88B800D17C@[192.168.1.2]> <201402141352.s1EDpx2n028673@boole.openldap.org> <201402141834.s1EIYbWS047940@boole.openldap.org> <201402142128.s1ELSNl7058088@boole.openldap.org> <20140218151031.3EAEFA6272@edge02.zimbra.com> <85A8918962FA0AAA487481E0@[192.168.1.2]> <201402191921.s1JJL9q9079356@boole.openldap.org>

>>> "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: 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

Follow-Ups:
- Re: Antw: RE: Syncrepl and mmr
  - From: Quanah Gibson-Mount <quanah@zimbra.com>

References:
- Syncrepl and mmr
  - From: "Borresen, John - 0442 - MITLL" <John.Borresen@ll.mit.edu>
- Re: Syncrepl and mmr
  - From: Quanah Gibson-Mount <quanah@zimbra.com>
- RE: Syncrepl and mmr
  - From: "Borresen, John - 0442 - MITLL" <John.Borresen@ll.mit.edu>
- RE: Syncrepl and mmr
  - From: "Borresen, John - 0442 - MITLL" <John.Borresen@ll.mit.edu>
- RE: Syncrepl and mmr
  - From: "Borresen, John - 0442 - MITLL" <John.Borresen@ll.mit.edu>
- RE: Syncrepl and mmr
  - From: Quanah Gibson-Mount <quanah@zimbra.com>
- RE: Syncrepl and mmr
  - From: "Borresen, John - 0442 - MITLL" <John.Borresen@ll.mit.edu>

Prev by Date: openldap 2.4.33 configure problem - could not locate TLS/ssl package.
Next by Date: Re: openldap 2.4.33 configure problem - could not locate TLS/ssl package.
Index(es):
- Chronological
- Thread