Update to Murder docs (D69) and question on style.

Nic Bernstein nic at onlight.com
Fri Aug 21 09:56:15 EDT 2015


On 08/21/2015 02:58 AM, Michael Menge wrote:
> Hi,
>
>
> Quoting Nic Bernstein <nic at onlight.com>:
> <snip>
>> I can write this up, I just wasn't sure if it was still needed.  I 
>> put a big ol' Note: in the replication page saying:
>>
>>    Important
>>
>>    Within a Cyrus /Murder/
>> <https://docs.cyrus.foundation/imap/developer/architecture.html#architecture-murder>
>>    environment, replicas must *not* be configured to invoke
>>    ctl_mboxlist(8)
>> <http://docs.cyrus.foundation/imap/admin/commands/ctl_mboxlist.html>
>>    on startup (pushing the local mailbox list to the *Mupdate Master*).
>>    This may only be done on the Master instance.
>>
>> That's the only real gotcha I know of, but, having said that, I did 
>> write up a brief set of instructions about this very topic not that 
>> long ago (IIRC) for user mailing list.  I figured I could start with 
>> that.
>>
>
>
> For the initial configuration I second this. But there are IHMO things
> to consider on failover.
>
>
> 1. ctl_mboxlist must be used with -m and -a Option on failover
> 2. on big installations updating all entries in mailbox.db on the
>    mupdate server can take some time, on our setup we switch the IP 
> address
>    of master and replic on failover

And on 21 August at 06:12AM CDT, Ken Murchison wrote:
> Right.  We don't even have our replicas as part of our Murder.  They 
> replicate their backend as if it were a standalone server.


Yes indeed.  We use the following in /etc/imapd.conf on our servers:

    ##
    # Only one of these should be uncommented
    @include: /etc/imapd-master.conf
    #@include: /etc/imapd-replica.conf

And then comment/uncomment as needed.  The difference between these 
being the following (sanitized for your protection):

    root at mailbox:~# diff -uwb /etc/imapd-master.conf /etc/imapd-replica.conf
    --- /etc/imapd-master.conf	2014-11-24 23:06:49.830675999 +0000
    +++ /etc/imapd-replica.conf	2014-11-24 23:06:49.834675999 +0000
    -servername: mailbox.example.com
    +servername: mailbox.wi.example.com
      
    -##
    -# Auth credentials
    -mupdate_server: postman.example.com
    -mupdate_username: postman
    -mupdate_authname: postman
    -mupdate_password: <secret>
    -
    -##
    -# Replication support
    -# This is how the BACKEND for this host is defined
    -sync_host: mailbox.ia.example.com
    -sync_authname: mailproxy
    -sync_password: <secret>
    -sync_compress: true
    -sync_log: true
    -sync_repeat_interval: 5
    -sync_shutdown_file: /var/run/cyrus/sync_stop
    +## Auth credentials
    +# The credentials below must match the account listed in lmtp_admins
    +# on the backend servers.
    +proxy_authname: mailproxy
    +proxy_password: <secret>
    +serverlist: mailbox mailbox.wi

So the replica has no clue about the Murder.  We switch DNS between the 
two hosts during failover, so no IP address change [the servers are in 
different data centers, so that wouldn't be practical in any event].  I 
doubt we actually need that last blob of stuff on the replica, but it 
doesn't seem to have hurt.

As for /etc/cyrus.conf, we do something similar, in regards to 
commenting/uncommenting START entries for ctl_mboxlist and sync_client, 
versus an SERVICES entry for sync_server.

It's not the cleanest process in failover, but a damn sight better than 
nothing.

Cheers,
     -nic

-- 
Nic Bernstein                             nic at onlight.com
Onlight, Inc.                             www.onlight.com
6525 W Bluemound Road, Suite 24           v. 414.272.4477
Milwaukee, Wisconsin  53213-4073

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20150821/3a6cc66f/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nic.vcf
Type: text/x-vcard
Size: 278 bytes
Desc: not available
Url : http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20150821/3a6cc66f/attachment.vcf 


More information about the Cyrus-devel mailing list