Re: Cyrus 2.2.x vs 2.3

2005-08-17 Thread Patrick H Radtke

On Tue, 16 Aug 2005, Scott Russell wrote:


Ken Murchison wrote:


Changes to the Cyrus IMAP Server since 2.2.x


snip

I'm more curious about what led sites to deploy 2.3.x over 2.2.x and how the 
stability has been along with maintenance issues, if any, of staying up to 
date on the development branch.




We are using the 2.3 branch because we needed replication and unexpunge in 
our deployment.


We have no experience with anything but 2.3, so when we run into problems 
it is hard to know if we made a mistake, if its a bug in 2.3 or a change 
from the current documentation.


Bugs we have found are listed in bugzilla, but nothing has been to major.

Staying up to date is not to bad. Most development is on the newer 
features and we can take our time updating our servers.


-Patrick

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


Re: Cyrus 2.2.x vs 2.3

2005-08-16 Thread Ken Murchison

Scott Russell wrote:


Greets -

I'm going to be rebuilding our cyrus imap 2.1.x server in the next month 
and trying to figure out which version of cyrus I should use next. I 
understand that 2.2.x is stable and that 2.3.x in CVS is the development 
however it appears that some sites have jumped to 2.3 anyway. (What 
really got me thinking about it was when I noticed fastmail.fm has 
deployed 2.3)


In general, what are the advantages of 2.3 over 2.2.x for a basic site? 
We don't use murder but we do use SQL auth, sieve, postfix, and dspam on 
our IMAP server.


I guess I'm just curious what the driving factor is that pushes people 
to use 2.3.x instead of the stable 2.2.x release. :)


Changes to the Cyrus IMAP Server since 2.2.x

* Added support for unified and replicated Murders. A Murder no 
longer has to have discrete frontend and backend servers; any one 
unified server can both proxy and serve local mailboxes (proxy 
functionality in proxyd and lmtpproxyd has been merged with imapd and 
lmtpd respectively), or all replicated servers can serve the same 
mailboxes from a shared filesystem. The new mupdate_config option in 
imapd.conf is used to determine whether a Murder is using a 
traditional, unified or replicated configuration.
* Ported/rewrote/integrated David Carter's mailspool replication 
code. Development sponsored by Columbia University.
* Added support for delayed expunge, in which messages are 
removed from the mailbox index at the time of the EXPUNGE (hiding them 
from the client), but the message files and cache entries are left 
behind, to be purged at a later time by cyr_expire. This reduces the 
amount of I/O that takes place at the time of EXPUNGE and should result 
in greater responsiveness for the client, especially when expunging a 
large number of messages. The new expunge_mode option in imapd.conf 
controls whether expunges are immediate or delayed. Development 
sponsored by FastMail.
* Added support to place some/all mailbox metadata files (cyrus.* 
files) on a separate (probably high-speed) partition. See the new 
metapartition and metapartition_files options for details. Development 
sponsored by FastMail.
* Added support for accessing subfolders of INBOX via POP3. See the 
new popsubfolders option for details. Development sponsored by FastMail.
* Added support to lmtpd to do fuzzy mailbox matching on 
user+detail addresses. See the new lmtp_fuzzy_mailbox_match option for 
details. Development sponsored by FastMail.
* Added new sieve_extensions option to allow individual Sieve 
extensions to be enabled/disabled.
* The Sieve include extension is now supported. This also allows 
for global sieve scripts. See the new sieve_extensions options to enable it.
* The Sieve body extension is now supported. See the new 
sieve_extensions option to enable it. Development sponsored by FastMail.
* The $text$ variable for Sieve notify messages is now supported. 
Development sponsored by FastMail.
* The MIME structure of a new message destined for multiple 
recipients is now only parsed once rather than once per delivery, 
resulting in better performance. Development sponsored by FastMail.
* Support 64-bit quota usage (both per mailbox and for the entire 
quotaroot), based on a patch from Jeremy Rumpf. Development sponsored by 
FastMail.
* Added new flushseenstate option which causes imapd to immediately 
flush changes in \Seen state to disk rather than caching them until the 
mailbox is closed. Enabling this option may fix \Seen state weirdness 
with MS Outlook, at the expense of performance/scalability. Based on a 
patch by John A. Tamplin ([EMAIL PROTECTED]).

* The Sieve copy extension is now supported.
* The IMAP CATENATE extension is now supported.




--
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 2495 Main St. - Suite 401
716-604-0088 x26  Buffalo, NY 14214
--PGP Public Key--http://www.oceana.com/~ken/ksm.pgp

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


Re: Cyrus 2.2.x vs 2.3

2005-08-16 Thread Ken Murchison

Etienne Goyer wrote:


Ken Murchison wrote:

* Added support for unified and replicated Murders. A Murder 
no longer has to have discrete frontend and backend servers; any one 
unified server can both proxy and serve local mailboxes (proxy 
functionality in proxyd and lmtpproxyd has been merged with imapd and 
lmtpd respectively), or all replicated servers can serve the same 
mailboxes from a shared filesystem. The new mupdate_config option in 
imapd.conf is used to determine whether a Murder is using a 
traditional, unified or replicated configuration.
* Ported/rewrote/integrated David Carter's mailspool replication 
code. Development sponsored by Columbia University.



These two really got me excited.  2.3 will really be an important 
release for HA/scalability.


Could somebody expand a little about 'all replicated servers can serve 
the same mailboxes from a shared filesystem' ?  Assuming a number of 
servers serve mailboxes from a shared filesystem, there is no point in 
Murder anymore as any server in the pool have directly access to any 
mailbox in the shared filesystem, right ?


I would consider the replicated Murder code experimental at best.  I 
began writing it for a local university to use with a SAN filesystem , 
but I don't think it was ever deployed.  With David Carter's replication 
code, use a replicated Murder is already obsolete.


--
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 2495 Main St. - Suite 401
716-604-0088 x26  Buffalo, NY 14214
--PGP Public Key--http://www.oceana.com/~ken/ksm.pgp

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


Re: Cyrus 2.2.x vs 2.3

2005-08-16 Thread Scott Russell

Ken Murchison wrote:


Changes to the Cyrus IMAP Server since 2.2.x


snip

I'm more curious about what led sites to deploy 2.3.x over 2.2.x and how 
the stability has been along with maintenance issues, if any, of staying 
up to date on the development branch.


I'm excited about the feature list too. For me, the reason to consider 
2.3.x over 2.2.x is the added sieve support and potentially replicated 
mailbox code.


--
Scott Russell [EMAIL PROTECTED]
IBM Linux Technology Center System Admin


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