Re: Exec'ing a script from Cyrus when imapd has a client

[Adam Tauno Williams]

> Getting Cyrus to actually trigger something is much more complex - but
> you could easily do something with an inotify on the directory if you
> want smaller than a minute resolution.


-- 
openSUSE 
Linux for human beings who need to get things done.


Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: cyrus replication : master to replica and replica to master

[David Carter]

On Fri, 23 Oct 2009, Bron Gondwana wrote:

> I've seen heartbeat get split brain before.  We gave up on it.  We do 
> all our fencing via humans now!  Check the KVM, kick the box, manually 
> run the failover script.

Some of my colleagues have had a lot of grief with Heartbeat going split 
brain. It seems to really be designed for a pair of machines sitting next 
to each other in a rack with a serial link for the heartbeat, rather 
servers installed in a pair of machine rooms three miles apart.

We do manual failover with our Cyrus mailstores: I would rather 1/8th of 
my users had an outage of a couple of hours (and typically just a few 
minutes) than end up with a split brain.

On the one occasion in five years that we did end up with a Cyrus split 
brain (replication failed because of a memory DIMM error and then the 
entire master failed a few minutes later) it was easy enough to fish 
missing messages out of the dead system the following day and reinject 
them using LMTP. Certainly easier than reengineering the entire Cyrus 
mailstore to allow active/active replication.

On Wed, Oct 21, 2009 at 08:45:11PM +0200, David Touzeau wrote:

> I would like to know if it is possible to SET the replica has the master 
> too in order to replicate new mail saved on the replica to the master 
> and vis versa In this case it should be turn to active/active..

We do this to a limited degree: the set of active users on a pair of 
mailstores can be partitioned and bounced back and forth between the two 
servers in a pair. This is mostly useful for load balancing between our 
two machine rooms, or migrating all the users off a master so that we can 
patch and reboot without any user visible downtime.

However this is using my own replication code rather than the branch which 
was rewritten into Cyrus by Ken. I have additional safeguards to stop 
sync_client from overwriting the master data in a pair (which has only 
ever happened because of stupidity on my part when testing).

I've never used the standard replication code in Cyrus other than to 
backport (sideport?) additional features such as CONDSTORE and GUID 
support. Given the grief Fastmail had with the early Cyrus replication 
code I think that I'm rather glad about this.

Every once in a while I think about moving to standard Cyrus replication. 
Unfortunately there are a lot of warts that I really don't like. It is 
much easier to just drop my own replication code onto new versions of 
Cyrus (typically < 5 minutes work each time). That was one of my original 
design objectives.

-- 
David Carter Email: david.car...@ucs.cam.ac.uk
University Computing Service,Phone: (01223) 334502
New Museums Site, Pembroke Street,   Fax:   (01223) 334679
Cambridge UK. CB2 3QH.

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: Exec'ing a script from Cyrus when imapd has a client

[Greg A. Woods]

At Thu, 22 Oct 2009 18:43:41 -0700 (PDT), David Lang 
 wrote:
Subject: Re: Exec'ing a script from Cyrus when imapd has a client
> 
> there can be cases where you are providing mail services for several people, 
> or 
> have multiple machines you use yourself where having an IMAP server is 
> worthwhile.

Neither of those things make any real sense whatsoever.  They certainly
don't define any clear requirements that make sense in this context.

Every modern and useful IMAP-capable MUA can collect e-mail from any
combination of many IMAP servers anywhere and everywhere all at once.

If "fetchmail" can fetch the mail from an IMAP server, then so can any
MUA.

Just get rid of all the unnecessary complexity in the middle and just
use the MUA for what it's designed to be used for!



> now, it's unusual to use something like this without having a full MTA, but 
> it's 
> not unheard of.

It's not unusual for people to create all kinds of crazy complicated
setups that have no real purpose, in every domain in life.

I'm sure I make my own life more complicated than it needs to be in some ways.

However things do not _need_ to be made more complicated than necessary,

Here the OP's question provides a perfect clue showing that something is
far more complicated than it needs to be because we see that it will
even have to get more complex (and even less robust) before it begins to
work the way it would actually work without any of this unnecessary
complexity in the middle in the first place.

-- 
Greg A. Woods

+1 416 218-0098VE3TCP  RoboHack 
Planix, Inc.   Secrets of the Weird 

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: Exec'ing a script from Cyrus when imapd has a client

[David Lang]

On Fri, 23 Oct 2009, Greg A. Woods wrote:

> At Thu, 22 Oct 2009 18:43:41 -0700 (PDT), David Lang 
>  wrote:
> Subject: Re: Exec'ing a script from Cyrus when imapd has a client
>>
>> there can be cases where you are providing mail services for several people, 
>> or
>> have multiple machines you use yourself where having an IMAP server is
>> worthwhile.
>
> Neither of those things make any real sense whatsoever.  They certainly
> don't define any clear requirements that make sense in this context.
>
> Every modern and useful IMAP-capable MUA can collect e-mail from any
> combination of many IMAP servers anywhere and everywhere all at once.
>
> If "fetchmail" can fetch the mail from an IMAP server, then so can any
> MUA.
>
> Just get rid of all the unnecessary complexity in the middle and just
> use the MUA for what it's designed to be used for!

as long as you are willing to limit yourself to a single MUA on a single 
desktop/laptop.

if you want to be able to access your mail from different devices you need a 
mail server, not just a MUA

David Lang

>
>
>> now, it's unusual to use something like this without having a full MTA, but 
>> it's
>> not unheard of.
>
> It's not unusual for people to create all kinds of crazy complicated
> setups that have no real purpose, in every domain in life.
>
> I'm sure I make my own life more complicated than it needs to be in some ways.
>
> However things do not _need_ to be made more complicated than necessary,
>
> Here the OP's question provides a perfect clue showing that something is
> far more complicated than it needs to be because we see that it will
> even have to get more complex (and even less robust) before it begins to
> work the way it would actually work without any of this unnecessary
> complexity in the middle in the first place.
>
>

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: Exec'ing a script from Cyrus when imapd has a client

[Greg A. Woods]

At Fri, 23 Oct 2009 13:00:34 -0700 (PDT), David Lang 
 wrote:
Subject: Re: Exec'ing a script from Cyrus when imapd has a client
> 
> as long as you are willing to limit yourself to a single MUA on a single 
> desktop/laptop.
> 
> if you want to be able to access your mail from different devices you need a 
> mail server, not just a MUA

Huh?  What in the heck are you talking about?

I run multiple IMAP clients (some on the same computer, some on
different computers) all _simultaneously_, all accessing a half-dozen
different mail accounts on different servers around the Internet.

All my MUAs access the same folders and same messages directly, and
simultaneously.

I certainly don't need yet another IMAP server and a whole bunch of
unnecessary complexity with things like fetchmail just to do this.

What I would really like to learn is why anyone would falsely believe
that they do somehow need their own IMAP server for this reason.  There
must be some false conception or expectation permeating some parts of
the ether out there.

-- 
Greg A. Woods

+1 416 218-0098VE3TCP  RoboHack 
Planix, Inc.   Secrets of the Weird 

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: cyrus replication : master to replica and replica to master

[Carson Gaspar]

On 10/23/09 7:42 AM, David Carter wrote:
> On Fri, 23 Oct 2009, Bron Gondwana wrote:
>
>> I've seen heartbeat get split brain before.  We gave up on it.  We do
>> all our fencing via humans now!  Check the KVM, kick the box, manually
>> run the failover script.
>
> Some of my colleagues have had a lot of grief with Heartbeat going split
> brain. It seems to really be designed for a pair of machines sitting next
> to each other in a rack with a serial link for the heartbeat, rather
> servers installed in a pair of machine rooms three miles apart.

To be fair to heartbeat, if you're getting unexpected split brain, then you 
have 
configured it incorrectly. A 2 node cluster without _extremely_ reliable 
communication and fencing between the nodes requires a tie-breaker service. 
This 
is true of any clustering technology I have ever seen. Heartbeat provides a 
light-weight quorum service for just this purpose.

Of course if you only have 2 sites, and the site with the "extra" vote goes 
down, you lose the service. Anything else requires 3 sites, or a "meatware" 
failover decision.

-- 
Carson

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: Exec'ing a script from Cyrus when imapd has a client

[David Lang]

On Fri, 23 Oct 2009, Greg A. Woods wrote:

> At Fri, 23 Oct 2009 13:00:34 -0700 (PDT), David Lang 
>  wrote:
> Subject: Re: Exec'ing a script from Cyrus when imapd has a client
>>
>> as long as you are willing to limit yourself to a single MUA on a single
>> desktop/laptop.
>>
>> if you want to be able to access your mail from different devices you need a
>> mail server, not just a MUA
>
> Huh?  What in the heck are you talking about?
>
> I run multiple IMAP clients (some on the same computer, some on
> different computers) all _simultaneously_, all accessing a half-dozen
> different mail accounts on different servers around the Internet.
>
> All my MUAs access the same folders and same messages directly, and
> simultaneously.
>
> I certainly don't need yet another IMAP server and a whole bunch of
> unnecessary complexity with things like fetchmail just to do this.

I possibly missed it, but I didn't see anything that said that fetchmail was 
grabbing things via IMAP.

if the remote account is POP then doing something like this has value

if you have intermittent/expensive-per-min internet connectivity doing 
something 
like this has value.

I did something similar to this several years ago where a non-profit only had 
dial-up internet. I ran a local cyrus server and then had a process to bring up 
the internet connection as-needed. In that case I just polled for mail every 
half hour and people were willing to live with that at that time. In this case 
I 
actually used UUCP through a fixed mail server to do the routing instead of 
fetchmail, but the basic concept is the same.

another reason to run your own server is just to be free from quotas. many ISPs 
have small mail quotas.

David Lang

> What I would really like to learn is why anyone would falsely believe
> that they do somehow need their own IMAP server for this reason.  There
> must be some false conception or expectation permeating some parts of
> the ether out there.
>
>

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html