Re: TLS failed, service in BUSY state, terminated abnormally
Hello, auto-answering. During the upgrade process the /dev/* permission were broken. It includes /dev/urandom which I think (can someone confirm) is used by SSL. Put permission back and all is working fine. Ethariel 2010/9/5 Ethariel ethar...@gmail.com Hello, I need to upgrade a server to the last Mandriva, so cyrus-imapd as upgraded in the process. imap, pop and sieve are working fine as before. pop3s and imaps are no more working. I try to re-generate some new certificate, same error. From the client : openssl s_client -connect localhost:993 CONNECTED(0003) 3082552968:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:683: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 208 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- From the server side : Sep 5 20:27:45 srv001 imaps[13759]: accepted connection Sep 5 20:27:45 srv001 cyrus-master[13868]: about to exec /usr/lib/cyrus-imapd/imapd Sep 5 20:27:45 srv001 imaps[13868]: SQL backend defaulting to engine 'pgsql' Sep 5 20:27:45 srv001 imaps[13868]: executed Sep 5 20:27:45 srv001 imaps[13759]: imapd:Loading hard-coded DH parameters Sep 5 20:27:45 srv001 imaps[13759]: ssl session id callback failed in SSL_accept() - fail Sep 5 20:27:45 srv001 imaps[13759]: imaps TLS negotiation failed: srv001.domain.tld [127.0.0.1] Sep 5 20:27:45 srv001 cyrus-master[13566]: process 13759 exited, status 75 Sep 5 20:27:45 srv001 cyrus-master[13566]: service imaps pid 13759 in BUSY state: terminated abnormally (domain.tld is just a replace in this log, the name is configurated with a real one). Any idea ? I found some message on this lost or google about some problem with libsasl2, do you think it's related ? libsasl2-2.1.23-8mdv2010.1.i586 cyrus-imapd-2.3.15-7mdv2010.1.i586 Thks for your help BRgds, Ethariel Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: TLS failed, service in BUSY state, terminated abnormally
Le 06/09/2010 11:26, Ethariel a écrit : Hello, auto-answering. During the upgrade process the /dev/* permission were broken. It includes /dev/urandom which I think (can someone confirm) is used by SSL. Actually SSL is supposed to use /dev/random which provide better randomness (because of better entropy gathered via keyboards and disks, or better yet, hardware RNG), less likely to be predictable than /dev/urandom. Cheers, Clément Hermann Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: TLS failed, service in BUSY state, terminated abnormally
On Mon, 06 Sep 2010, Clément Hermann (nodens) wrote: Actually SSL is supposed to use /dev/random which provide better randomness (because of better entropy gathered via keyboards and disks, or better yet, hardware RNG), less likely to be predictable than /dev/urandom. Only if it has a PRNG which it wants to seed. If it will use the values directly, it should use /dev/urandom. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: New Cyrus project site and bugzilla
On Saturday 04 September 2010 03:50:32 Dave McMurtrie wrote: On 9/3/10 8:24 PM, Jeroen van Meeuwen (Kolab Systems) wrote: 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 ^^ You may want to update the list signature as well ;-) Good idea. I *think* I just did, but if the text below this is broken, I'll know I'm wrong. Thanks, Dave Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ I think it works now. :) And congratulations with the new domain. It makes it easier to find when looking for it. -- Joost Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: TLS failed, service in BUSY state, terminated abnormally
On Mon, Sep 06, 2010 at 11:42:38AM +0200, Clément Hermann (nodens) wrote: Le 06/09/2010 11:26, Ethariel a écrit : Hello, auto-answering. During the upgrade process the /dev/* permission were broken. It includes /dev/urandom which I think (can someone confirm) is used by SSL. Actually SSL is supposed to use /dev/random which provide better randomness (because of better entropy gathered via keyboards and disks, or better yet, hardware RNG), less likely to be predictable than /dev/urandom. That's a nice theory. Have you seen how many people have posted to this list about imap freezing and poor throughput that have been caused by using /dev/random and it blocking? On the flip side, can you provide a single example of a successful attack against IMAP connections secured by /dev/urandom? Denial of service is a credible threat too, and unless you actually have a hardware randomness generator, the threats of using /dev/random are generally worse than the threats of using /dev/urandom. Bron ( who doesn't like black and white advice from ivory towers! ) Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: TLS failed, service in BUSY state, terminated abnormally
Le 06/09/2010 23:46, Bron Gondwana a écrit : On Mon, Sep 06, 2010 at 11:42:38AM +0200, Clément Hermann (nodens) wrote: Le 06/09/2010 11:26, Ethariel a écrit : Hello, auto-answering. During the upgrade process the /dev/* permission were broken. It includes /dev/urandom which I think (can someone confirm) is used by SSL. Actually SSL is supposed to use /dev/random which provide better randomness (because of better entropy gathered via keyboards and disks, or better yet, hardware RNG), less likely to be predictable than /dev/urandom. That's a nice theory. Have you seen how many people have posted to this list about imap freezing and poor throughput that have been caused by using /dev/random and it blocking? On the flip side, can you provide a single example of a successful attack against IMAP connections secured by /dev/urandom? Denial of service is a credible threat too, and unless you actually have a hardware randomness generator, the threats of using /dev/random are generally worse than the threats of using /dev/urandom. Bron ( who doesn't like black and white advice from ivory towers! ) Well, I did said 'is supposed to', not 'always should use'. Note also that I mentionned hardware RNG. But you're right, it is far better and perfectly acceptable to provide service with poor entropy than bad service. My main point was that the permission problem was likely on /dev/random rather than on /dev/random. Sorry if it sounded like I was giving a lecture. I guess my not so good english is to blame. I always use /dev/urandom if I don't have hardware RNG on a busy server, because availability is more important than protection against a very unlikely threat, and I did have some problem under heavy load. However, if I can, I prefer to use a hardware RNG, as it is really a breeze to use with rng-tools. It used to be available on any server x86 motherboard, unfortunately it tends to be less frequent onboard nowadays... Actually, if you don't want to recompile cyrus but need to use /dev/urandom, you can use /dev/random with rng-tools using /dev/urandom as a random source instead of the RNG device. -- Clement Hermann (nodens) - L'air pur ? c'est pas en RL, ça ? c'est pas hors charte ? Jean in L'Histoire des Pingouins, http://tnemeth.free.fr/fmbl/linuxsf/ Vous trouverez ma clef publique sur le serveur public pgp.mit.edu. Please find my public key on the public keyserver pgp.mit.edu. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: TLS failed, service in BUSY state, terminated abnormally
On Tue, 07 Sep 2010, Clement Hermann (nodens) wrote: I always use /dev/urandom if I don't have hardware RNG on a busy server, because availability is more important than protection against a very unlikely threat, and I did have some problem under heavy load. If you have a HRNG properly feeding the Linux kernel with entropy, /dev/urandom will operate in the exactly same way as /dev/random anyway. Really, /dev/random is to be used ONLY when generating long-lived very important data, such as long-lived keys. However, if I can, I prefer to use a hardware RNG, as it is really a breeze to use with rng-tools. It used to be available on any server x86 motherboard, unfortunately it tends to be less frequent onboard nowadays... Actually, if you don't want to recompile cyrus but need to use /dev/urandom, you can use /dev/random with rng-tools using /dev/urandom as a random source instead of the RNG device. Well, I can recommend this: http://www.entropykey.co.uk -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Basic question about Cyrus replication
Hi all, Can you please give me some inputs about how Cyrus replication works? I've read the one page that comes with v2.3, and we've been using Cyrus (without replication) for a long time now. When I set up a master and a replica server, does the replica server listen on the IMAP port too, and can it handle IMAP queries while it is receiving sync logs for rolling replication? Basically, my question come from the DBMS background. When we set up a master and slave RDB and do near-real-time replication using log shipping, then the slave operates in recovery mode, not online mode. So, clients can't query the slave during this time. Is it the same with the Cyrus replica server? thanks, Shuvam Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Basic question about Cyrus replication
On Tue, 7 Sep 2010, Shuvam Misra wrote: Can you please give me some inputs about how Cyrus replication works? I've read the one page that comes with v2.3, and we've been using Cyrus (without replication) for a long time now. When I set up a master and a replica server, does the replica server listen on the IMAP port too, and can it handle IMAP queries while it is receiving sync logs for rolling replication? No, the replica only listens on the sync server port. The replica should not listen on the IMAP port and should not accept client queries. Basically, my question come from the DBMS background. When we set up a master and slave RDB and do near-real-time replication using log shipping, then the slave operates in recovery mode, not online mode. So, clients can't query the slave during this time. Is it the same with the Cyrus replica server? Yes, it's the same idea as the recovery mode for DBMS. -- Matt Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Basic question about Cyrus replication
When I set up a master and a replica server, does the replica server listen on the IMAP port too, and can it handle IMAP queries while it is receiving sync logs for rolling replication? No, the replica only listens on the sync server port. The replica should not listen on the IMAP port and should not accept client queries. Thanks. Clarified my most basic question. How do I prevent the replica server from listening on the imap port? Do I do this by not running imapd (from cyrus.conf)? If yes, then I guess the same needs to be done for POP3 and NNTP too, right? Shuvam Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Basic question about Cyrus replication
On Tue, 7 Sep 2010, Shuvam Misra wrote: How do I prevent the replica server from listening on the imap port? Do I do this by not running imapd (from cyrus.conf)? If yes, then I guess the same needs to be done for POP3 and NNTP too, right? Correct. cyrus.conf's services section should contain syncserver, and ptloader, if you need that. The section should not contain any imap/pop/nntp/lmtp services. -- Matt Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
