[Dovecot] v2.1.rc1 released
http://dovecot.org/releases/2.1/rc/dovecot-2.1.rc1.tar.gz http://dovecot.org/releases/2.1/rc/dovecot-2.1.rc1.tar.gz.sig
I'll probably release v2.1.0 pretty soon, unless people report some new bugs. I know v2.1 is already being used to serve mails to tens (or hundreds?) of thousands of users, so it should be pretty stable.
Most of the changes since v2.1.beta1 have been for rather small issues. Many of the fixed bugs exist also in v2.0, but since they are so minor I didn't bother backporting the fixes.
As new features since v2.1.beta1 there are the things I did also for v2.0.16, and:
- ssl_client_cert/key: Proxying can now send SSL certificate to backend server
- ssl_crypto_device for enabling hardware encryption
- SCRAM-SHA-1 authentication mechanism support by Florian Zeitz
- passdb/userdb checkpassword: Export all auth %variables to AUTH_* environment.
- maildir_broken_filename_sizes setting for people upgrading from other maildir servers that wrote tons of broken S=<size> values
And as a reminder, here are the biggest new things since v2.0:
* Plugins now use UTF-8 mailbox names rather than mUTF-7:
acl, autocreate, expire, trash, virtual
* auth_username_format default changed to %Lu. If you really want
case sensitive usernames, set it back to empty.
* Solr full text search backend changed to use mailbox GUIDs instead of
mailbox names, requiring reindexing everything. solr_old backend can
be used with old indexes to avoid reindexing, but it doesn't support
some newer features.
+ imapc (= IMAP client) storage allows using a remote IMAP server to
be used as storage. This allows using Dovecot as a smart (caching)
proxy or using dsync to do migration from remote IMAP server.
+ Mailbox indexing via queuing indexer service (required for Lucene)
+ Lucene full text search (FTS) backend rewritten with support for
different languages
+ FTS finally supports "OR" search operation
+ FTS supports indexing attachments via external programs
+ IMAP FUZZY extension, supported by Lucene and Solr FTS backends
+ Mailbox list indexes
+ Statistics tracking via stats service. Exported via doveadm stats.
+ Autocreate plugin creates/subscribes mailboxes physically only when
the mailbox is opened for the first time. Mailbox listing shows the
autocreated mailboxes even if they don't physically exist.
+ Password and user databases now support default_fields and
override_fields settings to specify template defaults/overrides.
- listescape plugin works perfectly now-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Timo Sirainen said the following on 24/11/11 01:46:
Works as advertised.
I noticed this warining:
Warning: fd limit (ulimit -n) is lower than required under max. load (1024 < 4096), because of service auth { client_limit }
What does exactly means?
The server we are talking about is my home server, a CentOS/64 with a dozen of mailboxes.
Ciao, luigi
/ +--[Luigi Rosa]-- \
Computers make excellent and efficient servants, but I have no wish to serve under them. Captain, a starship also runs on loyalty to one man. And nothing can replace it or him. --Spock, "The Ultimate Computer" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7OhxwACgkQ3kWu7Tfl6ZSJ0gCeIaS5ksyVHY3O9qOSCEyWUH2V By8AoMbUNSHBBc4102vScrozTOOkOeo+ =AZaL -----END PGP SIGNATURE-----
El Jueves, 24 de Noviembre de 2011 19:04:12 Luigi Rosa escribió:
Timo Sirainen said the following on 24/11/11 01:46:
Works as advertised.
I noticed this warining:
Warning: fd limit (ulimit -n) is lower than required under max. load (1024 < 4096), because of service auth { client_limit }
What does exactly means?
The server we are talking about is my home server, a CentOS/64 with a dozen of mailboxes.
The fd limit is the maximum number of concurrently open file descriptors per process. It can be configured on a per-user basis. You can check the actual value running 'ulimit -n'. It can be increased up to the value set in /proc/sys/fs/file-max. You can set it editing /etc/security/limits.conf. What the above comment means is that under max load the auth service could need up to 4096 file descriptors open, that's more than the default in most linux systems (1024).
However, in your case with just a dozen of mailboxes I don't think you'll need to change it.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Miguel Tormo said the following on 24/11/11 19:23:
The fd limit is the maximum number of concurrently open file descriptors per process. It can be configured on a per-user basis. You can check the actual value running 'ulimit -n'. It can be increased up to the value set in /proc/sys/fs/file-max. You can set it editing /etc/security/limits.conf. What the above comment means is that under max load the auth service could need up to 4096 file descriptors open, that's more than the default in most linux systems (1024).
However, in your case with just a dozen of mailboxes I don't think you'll need to change it.
Thank you for the explaination.
Ciao, luigi
/ +--[Luigi Rosa]-- \
A woman was in love with fourteen soldiers. It was clearly platoonic. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7OjRUACgkQ3kWu7Tfl6ZQXAwCgyD6LAUYQX7/x1PIFda5CoFjx IYsAniqFYvdk6y982XjvWsWc4G5t9zEC =70Em -----END PGP SIGNATURE-----
On Thu, 2011-11-24 at 19:23 +0100, Miguel Tormo wrote:
The fd limit is the maximum number of concurrently open file descriptors per process. It can be configured on a per-user basis. You can check the actual value running 'ulimit -n'. It can be increased up to the value set in /proc/sys/fs/file-max. You can set it editing /etc/security/limits.conf.
I'm not sure if changing /etc/security/limits.conf helps. It's probably only used by PAM when user logs in, so if Dovecot is started in system bootup it's unlikely to have been even read yet. Also I think some OSes override the limits in /etc/init.d/ scripts. Of course, I could be completely wrong in all of the above, I haven't really tested any of it :)
What the above comment means is that under max load the auth service could need up to 4096 file descriptors open, that's more than the default in most linux systems (1024).
I wonder if there's a good reason for why auth default should be that high. Probably in earlier times imap/pop3 processes just weren't disconnecting early enough from auth. So I guess I'll just drop it back to default and this warning would go away in most systems. I had started to get a little bit annoyed at that warning myself also.
El Jueves, 24 de Noviembre de 2011 20:25:47 Timo Sirainen escribió:
I'm not sure if changing /etc/security/limits.conf helps. It's probably only used by PAM when user logs in, so if Dovecot is started in system bootup it's unlikely to have been even read yet. Also I think some OSes override the limits in /etc/init.d/ scripts. Of course, I could be completely wrong in all of the above, I haven't really tested any of it
Well actually this is tricky, I'm not sure if it would work after a system boot, but I'm sure it works after a reboot of the service. It is also true what you say that some OSes override the limits in the /etc/init.d/ scripts, for example issuing an 'ulimit -n 4096' (if using bash) before dropping privileges (that should be inherited, but if privileges are dropped using "su" or something that uses PAM, then the /etc/security/limits.conf file comes into play again).
Another permanent way between reboots that I just googled is changing this line of includes/linux/fs.h: #define INR_OPEN 1024 /* Initial setting for nfile rlimits */
and recompile the kernel :P.
On Thu, 2011-11-24 at 21:35 +0100, Miguel Tormo wrote:
El Jueves, 24 de Noviembre de 2011 20:25:47 Timo Sirainen escribió:
I'm not sure if changing /etc/security/limits.conf helps. It's probably only used by PAM when user logs in, so if Dovecot is started in system bootup it's unlikely to have been even read yet. Also I think some OSes override the limits in /etc/init.d/ scripts. Of course, I could be completely wrong in all of the above, I haven't really tested any of it
Well actually this is tricky, I'm not sure if it would work after a system boot, but I'm sure it works after a reboot of the service. It is also true what you say that some OSes override the limits in the /etc/init.d/ scripts, for example issuing an 'ulimit -n 4096' (if using bash) before dropping privileges (that should be inherited, but if privileges are dropped using "su" or something that uses PAM, then the /etc/security/limits.conf file comes into play again).
much simpler way without rebuilding is as Timo suggested, just pick your value #!/bin/sh # Start/stop dovecot. ulimit -n 16384
...
Be careful, building in kernel based higher limits means /every/ service and can lead to DoS, this way limits dovecot to 16384, but keeps other stuff like mysql at 4096, and everything else at 1024, bit safer.
El 24/11/11 21:35, Miguel Tormo escribió:
El Jueves, 24 de Noviembre de 2011 20:25:47 Timo Sirainen escribió:
I'm not sure if changing /etc/security/limits.conf helps. It's probably only used by PAM when user logs in, so if Dovecot is started in system bootup it's unlikely to have been even read yet. Also I think some OSes override the limits in /etc/init.d/ scripts. Of course, I could be completely wrong in all of the above, I haven't really tested any of it
Well actually this is tricky, I'm not sure if it would work after a system boot, but I'm sure it works after a reboot of the service. It is also true what you say that some OSes override the limits in the /etc/init.d/ scripts, for example issuing an 'ulimit -n 4096' (if using bash) before dropping privileges (that should be inherited, but if privileges are dropped using "su" or something that uses PAM, then the /etc/security/limits.conf file comes into play again).
I tested this "intensively" some time ago, and Timo is right -as usual :) -: modifications in limits.conf are only relevant after a login. This means that they are not enforced at system boot, but they are if you reboot the service by hand (because you have already logged in).
The permanent solution is, as Noel Butler has pointed, modifying the startup script and using ulimit before actually starting dovecot.
HTH
On Thu, Nov 24, 2011 at 09:25:47PM +0200, Timo Sirainen wrote:
I'm not sure if changing /etc/security/limits.conf helps. It's probably only used by PAM when user logs in, so if Dovecot is started in system bootup it's unlikely to have been even read yet. Also I think some OSes override the limits in /etc/init.d/ scripts. Of course, I could be completely wrong in all of the above, I haven't really tested any of it :)
The OP was running Centos, and the Red Hat way of increasing nofile for services is to add the ulimit setting to /etc/sysconfig/dovecot:
ulimit -n 32768This is what we use, and it survives dovecot upgrades (since this is tagged as a configfile in RPM, not as script that will be overwritten on upgrades).
-jf
participants (6)
-
Jan-Frode Myklebust
-
Joseba Torre
-
Luigi Rosa
-
Miguel Tormo
-
Noel Butler
-
Timo Sirainen