http://dovecot.org/releases/2.0/dovecot-2.0.0.tar.gz http://dovecot.org/releases/2.0/dovecot-2.0.0.tar.gz.sig
As promised last Friday, here's the v2.0.0 release finally. I'm cautiously optimistic that v2.0.1 won't (have to) be released for a few weeks, since there was quite a lot of testing and fixing going on in the RC stage.
Remember to read http://wiki2.dovecot.org/Upgrading/2.0 before upgrading from v1.x. Although there is automatic config conversion, it can't handle everything, so reserve some extra time for upgrading. If you find an upgrade problem that isn't listed on the wiki page, please add it there or email Dovecot mailing list about it.
Pigeonhole Sieve and ManageSieve support can now be installed without patching Dovecot. Unfortunately there isn't a Pigeonhole release yet for v2.0, but its Mercurial code tree should be quite stable. See http://wiki2.dovecot.org/Pigeonhole
There are no changes since v2.0.rc6. The largest changes since v1.2 are:
* Dovecot uses two system users for internal purposes now by default:
dovenull and dovecot. You need to create the dovenull user or change
default_login_user setting.
* Global ACLs are now looked up using namespace prefixes. For example
if you previously had INBOX. namespace prefix and a global ACL for
"INBOX.Sent", it's now looked up from "INBOX.Sent" file instead of
"Sent" as before.
* Maildir: File permissions are no longer based on dovecot-shared file,
but the mailbox directory.
+ Redesigned master process. It's now more modular and there is less
code running as root.
+ Configuration supports now per-local/remote ip/network settings.
+ dsync utility does a two-way mailbox synchronization.
+ LMTP server and proxying.
+ Added mdbox (multi-dbox) mail storage backend.
+ doveadm utility can be used to do all kinds of administration
functions. Old dovecotpw and *view utilities now exist in its
subcommands.
+ imap and pop3 processes can now handle multiple connections.
+ IMAP: COMPRESS=DEFLATE is supported by imap_zlib plugin
+ director service helps NFS installations to redirect users always
to same server to avoid corruptionOn Mon, 2010-08-16 at 15:49 +0100, Timo Sirainen wrote:
http://dovecot.org/releases/2.0/dovecot-2.0.0.tar.gz http://dovecot.org/releases/2.0/dovecot-2.0.0.tar.gz.sig
Well, it didn't take long for someone to find the first "bug": http://hg.dovecot.org/dovecot-2.0/rev/2156583b00e2 configure: v2.0.0 is no longer UNSTABLE development branch. --- a/configure.in Mon Aug 16 15:35:16 2010 +0100 +++ b/configure.in Mon Aug 16 16:07:01 2010 +0100 @@ -2739,6 +2739,3 @@ if test "$not_sql_drivers" != ""; then echo " :$not_sql_drivers" fi - -echo -echo "NOTE: This is the UNSTABLE development branch of Dovecot v2.0."
On Mon, Aug 16, 2010 at 5:49 PM, Timo Sirainen <tss@iki.fi> wrote:
http://dovecot.org/releases/2.0/dovecot-2.0.0.tar.gz http://dovecot.org/releases/2.0/dovecot-2.0.0.tar.gz.sig
As promised last Friday, here's the v2.0.0 release finally. I'm cautiously optimistic that v2.0.1 won't (have to) be released for a few weeks, since there was quite a lot of testing and fixing going on in the RC stage.
Remember to read http://wiki2.dovecot.org/Upgrading/2.0 before upgrading from v1.x. Although there is automatic config conversion, it can't handle everything, so reserve some extra time for upgrading. If you find an upgrade problem that isn't listed on the wiki page, please add it there or email Dovecot mailing list about it.
Pigeonhole Sieve and ManageSieve support can now be installed without patching Dovecot. Unfortunately there isn't a Pigeonhole release yet for v2.0, but its Mercurial code tree should be quite stable. See http://wiki2.dovecot.org/Pigeonhole
There are no changes since v2.0.rc6. The largest changes since v1.2 are:
* Dovecot uses two system users for internal purposes now bydefault: dovenull and dovecot. You need to create the dovenull user or change default_login_user setting. * Global ACLs are now looked up using namespace prefixes. For example if you previously had INBOX. namespace prefix and a global ACL for "INBOX.Sent", it's now looked up from "INBOX.Sent" file instead of "Sent" as before. * Maildir: File permissions are no longer based on dovecot-shared file, but the mailbox directory.
+ Redesigned master process. It's now more modular and there is less code running as root. + Configuration supports now per-local/remote ip/network settings. + dsync utility does a two-way mailbox synchronization. + LMTP server and proxying. + Added mdbox (multi-dbox) mail storage backend. + doveadm utility can be used to do all kinds of administration functions. Old dovecotpw and *view utilities now exist in its subcommands. + imap and pop3 processes can now handle multiple connections. + IMAP: COMPRESS=DEFLATE is supported by imap_zlib plugin + director service helps NFS installations to redirect users always to same server to avoid corruption
It is yet another major milestone for Dovecot!
Congratulations Timo.
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223
"If you have nothing good to say about someone, just shut up!." -- Lucky Dube
Congratulations Timo!:)
SUSE packages are already building and can be found at [1] in a few minutes.
though the package doesnt try to migrate the config yet. so users have to do that on their own. :)
darix[1] http://download.opensuse.org/repositories/server:/mail/ dovecot20 dovecot20-backend-mysql dovecot20-backend-pgsql dovecot20-backend-sqlite dovecot20-fts-solr dovecot20-devel
-- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Timo Sirainen said the following on 16/08/10 16:49:
As promised last Friday, here's the v2.0.0 release finally. I'm cautiously optimistic that v2.0.1 won't (have to) be released for a few weeks, since there was quite a lot of testing and fixing going on in the RC stage.
Congratulations Timo and thank you!!!
Ciao, luigi
/ +--[Luigi Rosa]-- \
Biggest Black Hole ever Found in Nearby Galaxy. EVERYBODY PAN..I....................C --fark.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxpX2YACgkQ3kWu7Tfl6ZSHBACfYqBFlpHe0Cc4pRMx+b2OZZL9 P0QAoIwCuMkwS6w4SQpusyWwJWUQY+SN =k0GJ -----END PGP SIGNATURE-----
On Aug 16, 2010, at 7:49 AM, Timo Sirainen wrote:
http://dovecot.org/releases/2.0/dovecot-2.0.0.tar.gz http://dovecot.org/releases/2.0/dovecot-2.0.0.tar.gz.sig
A new dovecot2 port Mac and/or MacPorts users here.
http://trac.macports.org/ticket/26111
Regards, Bradley Giesbrecht
Le 16 août 2010 à 16:49:00, Timo Sirainen a écrit :
[...]
- imap and pop3 processes can now handle multiple connections. [...]
Hello,
Could someone point to some more info about the above? I remember Mike's message (November 2009, 11th) as well as Timo's plans (January 2010, 23rd), but couldn't find details about the current status of that feature.
TIA, Axel
On Tue, 2010-09-07 at 15:56 +0200, Axel Luttgens wrote:
- imap and pop3 processes can now handle multiple connections.
Could someone point to some more info about the above?
Well, I don't necessarily recommend actually using it, but it's possible:
service imap { client_limit = <maybe a few> service_count = 0 } service pop3 { client_limit = <maybe a few more than imap> service_count = 0 }
The main problem is that some disk I/O, and especially lock waits, can hang all other connections running in the same process.
Le 7 sept. 2010 à 16:16:26, Timo Sirainen a écrit :
On Tue, 2010-09-07 at 15:56 +0200, Axel Luttgens wrote:
- imap and pop3 processes can now handle multiple connections.
Could someone point to some more info about the above?
Well, I don't necessarily recommend actually using it, but it's possible:
service imap { client_limit = <maybe a few> service_count = 0 } service pop3 { client_limit = <maybe a few more than imap> service_count = 0 }
The main problem is that some disk I/O, and especially lock waits, can hang all other connections running in the same process.
Hello Timo,
Many thanks for your reply.
Here, with dovecot 2.0.2, client_limit seems to default to 1 for services imap and pop3. Trying client_limit=10 for imap, I get:
dovecot[46911]: imap(testuser): Error: user testuser: Initialization failed: Initializing mail storage from mail_location setting failed: mbox: mbox requires client_limit=1 for service(yes, still experimenting with mbox format...) Same kind of error message when client_limit is set to a non-default value for pop3.
On the other hand, client_limit seems to default to 0 for service lmtp. Leaving that default yields:
dovecot[46286]: lmtp(46334, testuser): Error: user testuser: Initialization failed: Initializing mail storage from mail_location setting failed: mbox: mbox requires client_limit=1 for serviceand one needs to define client_limit=1 for lmtp as well.
This behavior seems to have been enforced in mbox-storage.c with http://hg.dovecot.org/dovecot-2.0/rev/28c3486864f6, and comes with following comment: "/* we can't handle locking related problems. */".
This is thus rather new. But I couldn't find any information on the list related to those "locking problems". Is it really needed to be so stringent with mbox format? Or was it jut intended to be a temporary workaround?
TIA, Axel
On Wed, 2010-09-15 at 10:12 +0200, Axel Luttgens wrote:
Here, with dovecot 2.0.2, client_limit seems to default to 1 for services imap and pop3. Trying client_limit=10 for imap, I get:
dovecot[46911]: imap(testuser): Error: user testuser: Initialization failed: Initializing mail storage from mail_location setting failed: mbox: mbox requires client_limit=1 for service
Yes.
dovecot[46286]: lmtp(46334, testuser): Error: user testuser: Initialization failed: Initializing mail storage from mail_location setting failed: mbox: mbox requires client_limit=1 for service
and one needs to define client_limit=1 for lmtp as well.
Yes, this is intentional. client_limit=1 default is good for pop3/imap, but for lmtp and non-mbox format a larger client_limit is better because latency doesn't matter that much.
This behavior seems to have been enforced in mbox-storage.c with http://hg.dovecot.org/dovecot-2.0/rev/28c3486864f6, and comes with following comment: "/* we can't handle locking related problems. */".
This is thus rather new. But I couldn't find any information on the list related to those "locking problems". Is it really needed to be so stringent with mbox format? Or was it jut intended to be a temporary workaround?
The problem is that with mbox format the mbox file can be locked for a long time. So for example two clients handled by the same process may attempt to write to the same mbox:
- Client 1 write-locks mbox file and goes back to ioloop waiting for the message data to arrive.
- Ioloop starts handling client 2 connection, which also tries to save message to same mailbox and tries to write-lock the same mbox file.
Now the second client keeps blocking on the write-lock and waiting for client 1 to release the lock, but since 1 is handled by the same process, this won't happen.
This problem doesn't happen with any other mailbox format.
Maybe some day in future there's a way to avoid this by having the code notice early that the mailbox is locked and go back to ioloop instead of block.
participants (8)
-
Axel Luttgens
-
Bradley Giesbrecht
-
Dave McGuire
-
Luigi Rosa
-
Marcus Rueckert
-
Odhiambo Washington
-
Timo Sirainen
-
William Blunn