Re: MUPDATE master server
No kidding. I'm looking forward to the donation that makes developing that possible. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper Any idea what it would take to make this happen... ballpark? Jared - -BEGIN GEEK CODE BLOCK- Version: 3.12 GIT/S/B d- s-:+ a- C$ UL$ P--- L+++$ E--- W+++ N++ o+ K- w O- M-- !V PS+ PE Y++ PGP++ t+ 5- X+ R* tv+ b++ DI+ D G e++>+++ h+ r>+++ z* --END GEEK CODE BLOCK--
Re: MUPDATE master server
On Fri, 7 Mar 2003 [EMAIL PROTECTED] wrote: > >Its possible. Make sure you understand that you're doing this for the > >shared namespace though, otherwise you almost certainly want a more > >traditional IMAP proxy like perdition. > > The main advantage that we are interested in is that we would have two IMAP > connection points for clients located in two different geographical > locations. The user which would connect wouldn't care at which locations he > connects to the front end server because the frontend server would know on > which back end server his mailbox is. This is possible with perdition. > >I think you should be sure Murder is what you want before you jump into > >it. It solves a very special problem that most people don't have. > > I think I will wait until Murder gets some kind of replication integrated > as that would really give a big plus to the whole concept. You would then > also have high availability. No kidding. I'm looking forward to the donation that makes developing that possible. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: MUPDATE master server
>Its possible. Make sure you understand that you're doing this for the >shared namespace though, otherwise you almost certainly want a more >traditional IMAP proxy like perdition. The main advantage that we are interested in is that we would have two IMAP connection points for clients located in two different geographical locations. The user which would connect wouldn't care at which locations he connects to the front end server because the frontend server would know on which back end server his mailbox is. >I think you should be sure Murder is what you want before you jump into >it. It solves a very special problem that most people don't have. I think I will wait until Murder gets some kind of replication integrated as that would really give a big plus to the whole concept. You would then also have high availability. Thanks again for your comments Regards Marc
Re: MUPDATE master server
On Fri, 7 Mar 2003 [EMAIL PROTECTED] wrote: > >So, there's a partial failure, but the majority of the system survives. > > That sounds fine for me. Now I have the current configuration: > > 1 server at a colocation place and a few other servers at a hosting center, > that would be two different geographical regions. Now with such a > configuration is it possible to implement an interested Cyrus Murder > environement ? Its possible. Make sure you understand that you're doing this for the shared namespace though, otherwise you almost certainly want a more traditional IMAP proxy like perdition. Note that the murder was never intended to work in a geographicly distributed fashion. There may be lurking bugs/performance issues (though based on how it actually works, I don't expect this). > I see the current problem where the single server located at the colocation > place will somehow need to act as front end and back end server at the same > time, is that somehow possible ? Yes. Ken debugs complete murder configurations on a single laptop. Of course, I don't recommend it (now you're costing yourself 2 IMAP processes per connection on that machine instead of 1) > Or shouldn't I even think about such a setting up a Cyrus murder > environement with so less servers. What do you think about this setup ? I think you should be sure Murder is what you want before you jump into it. It solves a very special problem that most people don't have. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * [EMAIL PROTECTED] * 412.268.7456 -BEGIN GEEK CODE BLOCK Version: 3.12 GCS/IT/CM/PA d- s+: a-- C$ ULS$ P+++$ L+++() E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? --END GEEK CODE BLOCK-
Re: MUPDATE master server
On Fri, 7 Mar 2003 [EMAIL PROTECTED] wrote: > What would then happen to mails when the MUPDATE master server goes down ? > Will mail be undelivered and be bounced back ? I would like to avoid the > MUPDATE master server to become the single point of failure. In the event of a mupdate server failure lmtpproxyd will start returning temporary failures to the MTA, so provided your MTA queues properly, nothing should bounce. In terms of IMAP functionality, users can no longer do folder operations (create, delete, setacl, etc), but they can still read mail (of any mailboxes with metadata that had been replicated across the frontends at the time of the failure). So, there's a partial failure, but the majority of the system survives. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: MUPDATE master server
Thanks for the answer. I was reading the IMAP Aggregoatr: A Murder of IMAP Servers (ag.html) that's why I didn't find my answer in that document. So if I can only have one single MUPDATE master server the others would be slaves right ? What would then happen to mails when the MUPDATE master server goes down ? Will mail be undelivered and be bounced back ? I would like to avoid the MUPDATE master server to become the single point of failure. Regards Marc Rob Siemborski To: [EMAIL PROTECTED] <[EMAIL PROTECTED] cc: [EMAIL PROTECTED] mu.edu> Subject: Re: MUPDATE master server 03/07/03 05:04 PM On Fri, 7 Mar 2003 [EMAIL PROTECTED] wrote: > I am a bit confused on where should be ran the MUPDATE master server, > should it be running on a Front End server, Back End Server or maybe a > seperate server ? The documentation is not very explicit about this I > think. >From the documentation (install-murder.html): * One machine to become the MUPDATE master server. This can be the same as one of your frontend servers. Presumably you could also run it on a backend with a separate imapd.conf file. > Also is it possible to have two MUPDATE master servers for > redundancy ? No. > I am looking to the best way to get a maximum of redundancy and high > availabilty between two different geographical sites where we would be > running Cyrus v2.2. Are there maybe any examples around ? The murder won't increase your redundancy. It will only reduce the impact of a failure. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: MUPDATE master server
On Fri, 7 Mar 2003 [EMAIL PROTECTED] wrote: > I am a bit confused on where should be ran the MUPDATE master server, > should it be running on a Front End server, Back End Server or maybe a > seperate server ? The documentation is not very explicit about this I > think. >From the documentation (install-murder.html): * One machine to become the MUPDATE master server. This can be the same as one of your frontend servers. Presumably you could also run it on a backend with a separate imapd.conf file. > Also is it possible to have two MUPDATE master servers for > redundancy ? No. > I am looking to the best way to get a maximum of redundancy and high > availabilty between two different geographical sites where we would be > running Cyrus v2.2. Are there maybe any examples around ? The murder won't increase your redundancy. It will only reduce the impact of a failure. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
MUPDATE master server
Hello, I am a bit confused on where should be ran the MUPDATE master server, should it be running on a Front End server, Back End Server or maybe a seperate server ? The documentation is not very explicit about this I think. Also is it possible to have two MUPDATE master servers for redundancy ? I am looking to the best way to get a maximum of redundancy and high availabilty between two different geographical sites where we would be running Cyrus v2.2. Are there maybe any examples around ? Many thanks Regards