Re: 2.4.2 on Solaris - Crashes in mailbox_unlock_index
On Mon, 1 Nov 2010, Bron Gondwana wrote: ; ; Here's your patch :) Works perfectly, thanks :) Andy Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: 2.4.2 on Solaris - Crashes in mailbox_unlock_index
On Mon, Nov 01, 2010 at 09:43:46AM +, Andy Fiddaman wrote: On Mon, 1 Nov 2010, Bron Gondwana wrote: ; ; Here's your patch :) Works perfectly, thanks :) Excellent. Like I said, it WILL be in the next release. I just have to fix some other stuff first! (and I suspect Max and Greg will have stuff to fix too - we're all bug fixing or rounding out incomplete stuff which I will call a bug fix even if it's somewhat new featurish... things like tidying up the multi-channel replication stuff that nobody better be using yet because it's only half done!) Bron. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Odd problem: IMAP/S suddenly not working, but no errors, and IMAP still works
On Sun, 31 Oct 2010, Chris Pepper wrote: But my /dev/random does seem quite low. Still surfing and looking for a good way to fill it on a mostly headless server -- I haven't found a good solution yet. http://www.entropykey.co.uk/ Very good hardware, first-class Linux support, and will fit on the internal USB ports of most 1U/2U servers and workstations (where it will be safe from physical accidents during server maintenance, and far more protected against tampering). I'm one of their happy customers (and not otherwise affiliated with them in any way). Just like I am a happy customer of fastmail.fm :-) That said, you should always use /dev/urandom unless you're generating long-term keys, even if you add one or more entropy keys. Otherwise, it gets easier to DoS the service. -- 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: Odd problem: IMAP/S suddenly not working, but no errors, and IMAP still works
On 31/10/10 20:51 -0400, Chris Pepper wrote: Alternatively, is there a way to make sure Cyrus requires STARTTLS on 143? I was blocking external access to it to make sure users always use encryption to connect, but port 143 with STARTTLS required would be an acceptable alternative. You can set 'allowplaintext: 0' to disallow plaintext logins over port 143. That would require clients to perform a STARTTLS, or negotiate a SASL security layer which meets your 'sasl_minimum_layer:' setting. -- Dan White Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Odd problem: IMAP/S suddenly not working, but no errors, and IMAP still works
Bron, My Cyrus is from RPM, and I am just nursing it along until my users finish migrating off and FastMail manages to complete my own migration, so I don't want to build from source. Why would IMAP/S block on empty /dev/random, while IMAP+STARTTLS works? FWIW, SASL2 seems to use urandom. If this is really stock CentOS 5 then I think everything Cyrus related should use /dev/urandom and not /dev/random. But, could it be that other software you installed uses /dev/random and makes it empty? Simon [r...@inspector random]# strings /usr/lib/libsasl* |grep random /dev/urandom /dev/urandom But my /dev/random does seem quite low. Still surfing and looking for a good way to fill it on a mostly headless server -- I haven't found a good solution yet. Chris [r...@inspector ~]# ls -l /dev/*random crw-rw-rw- 1 root root 1, 8 Oct 31 02:05 /dev/random cr--r--r-- 1 root root 1, 9 Oct 31 02:05 /dev/urandom [r...@inspector ~]# cd /proc/sys/kernel/random [r...@inspector random]# more *|cat :: boot_id :: d3724e19-7462-4224-960b-49d5d3a18d7a :: entropy_avail :: 17 :: poolsize :: 4096 :: read_wakeup_threshold :: 64 :: uuid :: a3ed2323-e04d-4034-a72a-76b5d4b697f7 :: write_wakeup_threshold :: 128 On 10/31/10 9:26 PM, Bron Gondwana wrote: Sounds like your /dev/random is empty. You can compile with /dev/urandom or add a source of entropy... Chris Pepperpep...@cbio.mskcc.org wrote: mail.reppep.com (CentOS 5) is running cyrus-imapd-2.3.7-7.el5_4.3, along with SquirrelMail, postfix, etc. Last night, I noticed that when I sent mail from Thunderbird, it was not able to file copies in the Sent mailbox, although they did reach the recipients, so postfix was accepting mail on 587/tcp. I restarted Cyrus IMAPd but don't see any error messages in /var/log/maillog, and the cert key look fine. SquirrelMail is fine using plain IMAP. I opened 143/tcp in the firewall, and am able to fetch mail via IMAP with STARTTLS, so it looks like the cert and key are fine. But telnet mail.reppep.com 993 and openssl fail to get any response. Port 993 is open to the Internet, FWIW. Does anyone have any suggestions for what went wrong and/or how to fix? I'll try tcpdump next to see if it's responding at all. Alternatively, is there a way to make sure Cyrus requires STARTTLS on 143? I was blocking external access to it to make sure users always use encryption to connect, but port 143 with STARTTLS required would be an acceptable alternative. Thanks, Chris Pepper pep...@imp:~$ !openssl openssl s_client -connect www.reppep.com:993 CONNECTED(0003) 4284:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/SourceCache/OpenSSL098/OpenSSL098-32/src/ssl/s23_lib.c:188: [r...@inspector ~]# cat /etc/imapd.conf admins: cyrus altnamespace: yes configdirectory: /var/lib/imap duplicatesuppression: yes hashimapspool: no partition-default: /var/spool/imap servername: mail.reppep.com singleinstancestore: yes #syslog_prefix: cyrus unixhierarchysep: yes lmtp_downcase_rcpt: yes maxmessagesize: 20971520 sendmail: /usr/sbin/sendmail #quotawarn: 80 #allowplaintext: yes #allowplainwithouttls: yes sasl_pwcheck_method: saslauthd #imap_auth_login: yes #imap_auth_cram_md5: yes #imap_auth_plain: yes autocreateinboxfolders: Junk autocreatequota: -1 #autocreate_sieve_script: /etc/junk.sieve autocreate_sieve_compiledscript: /etc/sieve.bc autosievefolders: Junk autosubscribeinboxfolders: Junk createonpost: yes #sievedir: /var/lib/imap/sieve sieveusehomedir: true tls_ca_file: /etc/pki/tls/certs/mail.reppep.com.20100115.crt tls_cert_file: /etc/pki/tls/certs/mail.reppep.com.20100115.crt tls_key_file: /etc/pki/tls/private/mail.reppep.com.20080219.key tls_cipher_list: SSLv3:TLSv1:!NULL:!EXPORT:!DES:!LOW:@STRENGTH [r...@inspector ~]# ls -l /etc/pki/tls/certs/mail.reppep.com.20100115.crt /etc/pki/tls/private/mail.reppep.com.20080219.key -rw-r--r-- 1 root root 6466 Oct 1 17:13 /etc/pki/tls/certs/mail.reppep.com.20100115.crt -rw-r- 1 root mail 497 Feb 19 2008 /etc/pki/tls/private/mail.reppep.com.20080219.key [r...@inspector ~]# netstat -an|grep LIST|grep tcp|sort -n tcp0 0 0.0.0.0:110 0.0.0.0:* LISTEN tcp0 0 0.0.0.0:111 0.0.0.0:* LISTEN tcp0 0 0.0.0.0:139 0.0.0.0:* LISTEN tcp0 0 0.0.0.0:143 0.0.0.0:* LISTEN tcp0 0 0.0.0.0:20000.0.0.0:* LISTEN tcp0 0 0.0.0.0:25 0.0.0.0:* LISTEN tcp0 0 0.0.0.0:33060.0.0.0:* LISTEN tcp0 0 0.0.0.0:445 0.0.0.0:* LISTEN tcp0 0 0.0.0.0:587
Re: Odd problem: IMAP/S suddenly not working, but no errors, and IMAP still works
On 11/1/10 10:46 AM, Simon Matter wrote: Bron, My Cyrus is from RPM, and I am just nursing it along until my users finish migrating off and FastMail manages to complete my own migration, so I don't want to build from source. Why would IMAP/S block on empty /dev/random, while IMAP+STARTTLS works? FWIW, SASL2 seems to use urandom. If this is really stock CentOS 5 then I think everything Cyrus related should use /dev/urandom and not /dev/random. But, could it be that other software you installed uses /dev/random and makes it empty? Most things are CentOS RPMs (thanks for those! ;), with a few from RPMforge. [r...@inspector ~]# rpm -q cyrus-imapd amavisd-new clamav spamassassin postfix httpd mod_ssl cyrus-imapd-2.3.7-7.el5_4.3 amavisd-new-2.6.4-3.el5.rf clamav-0.96.4-1.el5.rf spamassassin-3.3.1-3.el5.rf postfix-2.3.3-2.1.el5_2 httpd-2.2.3-43.el5.centos.3 mod_ssl-2.2.3-43.el5.centos.3 Which still leaves me thinking my port 993 problem isn't entropy, because STARTTLS works fine. Chris [r...@inspector random]# strings /usr/lib/libsasl* |grep random /dev/urandom /dev/urandom But my /dev/random does seem quite low. Still surfing and looking for a good way to fill it on a mostly headless server -- I haven't found a good solution yet. Chris [r...@inspector ~]# ls -l /dev/*random crw-rw-rw- 1 root root 1, 8 Oct 31 02:05 /dev/random cr--r--r-- 1 root root 1, 9 Oct 31 02:05 /dev/urandom [r...@inspector ~]# cd /proc/sys/kernel/random [r...@inspector random]# more *|cat :: boot_id :: d3724e19-7462-4224-960b-49d5d3a18d7a :: entropy_avail :: 17 :: poolsize :: 4096 :: read_wakeup_threshold :: 64 :: uuid :: a3ed2323-e04d-4034-a72a-76b5d4b697f7 :: write_wakeup_threshold :: 128 On 10/31/10 9:26 PM, Bron Gondwana wrote: Sounds like your /dev/random is empty. You can compile with /dev/urandom or add a source of entropy... Chris Pepperpep...@cbio.mskcc.org wrote: mail.reppep.com (CentOS 5) is running cyrus-imapd-2.3.7-7.el5_4.3, along with SquirrelMail, postfix, etc. Last night, I noticed that when I sent mail from Thunderbird, it was not able to file copies in the Sent mailbox, although they did reach the recipients, so postfix was accepting mail on 587/tcp. I restarted Cyrus IMAPd but don't see any error messages in /var/log/maillog, and the cert key look fine. SquirrelMail is fine using plain IMAP. I opened 143/tcp in the firewall, and am able to fetch mail via IMAP with STARTTLS, so it looks like the cert and key are fine. But telnet mail.reppep.com 993 and openssl fail to get any response. Port 993 is open to the Internet, FWIW. Does anyone have any suggestions for what went wrong and/or how to fix? I'll try tcpdump next to see if it's responding at all. Alternatively, is there a way to make sure Cyrus requires STARTTLS on 143? I was blocking external access to it to make sure users always use encryption to connect, but port 143 with STARTTLS required would be an acceptable alternative. Thanks, Chris Pepper pep...@imp:~$ !openssl openssl s_client -connect www.reppep.com:993 CONNECTED(0003) 4284:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/SourceCache/OpenSSL098/OpenSSL098-32/src/ssl/s23_lib.c:188: [r...@inspector ~]# cat /etc/imapd.conf admins: cyrus altnamespace: yes configdirectory: /var/lib/imap duplicatesuppression: yes hashimapspool: no partition-default: /var/spool/imap servername: mail.reppep.com singleinstancestore: yes #syslog_prefix: cyrus unixhierarchysep: yes lmtp_downcase_rcpt: yes maxmessagesize: 20971520 sendmail: /usr/sbin/sendmail #quotawarn: 80 #allowplaintext: yes #allowplainwithouttls: yes sasl_pwcheck_method: saslauthd #imap_auth_login: yes #imap_auth_cram_md5: yes #imap_auth_plain: yes autocreateinboxfolders: Junk autocreatequota: -1 #autocreate_sieve_script: /etc/junk.sieve autocreate_sieve_compiledscript: /etc/sieve.bc autosievefolders: Junk autosubscribeinboxfolders: Junk createonpost: yes #sievedir: /var/lib/imap/sieve sieveusehomedir: true tls_ca_file: /etc/pki/tls/certs/mail.reppep.com.20100115.crt tls_cert_file: /etc/pki/tls/certs/mail.reppep.com.20100115.crt tls_key_file: /etc/pki/tls/private/mail.reppep.com.20080219.key tls_cipher_list: SSLv3:TLSv1:!NULL:!EXPORT:!DES:!LOW:@STRENGTH [r...@inspector ~]# ls -l /etc/pki/tls/certs/mail.reppep.com.20100115.crt /etc/pki/tls/private/mail.reppep.com.20080219.key -rw-r--r-- 1 root root 6466 Oct 1 17:13 /etc/pki/tls/certs/mail.reppep.com.20100115.crt -rw-r- 1 root mail 497 Feb 19 2008 /etc/pki/tls/private/mail.reppep.com.20080219.key [r...@inspector ~]# netstat -an|grep LIST|grep tcp|sort -n tcp0 0 0.0.0.0:110 0.0.0.0:* LISTEN tcp0
Re: Odd problem: IMAP/S suddenly not working, but no errors, and IMAP still works
On Monday, November 01, 2010 03:46:38 pm Simon Matter wrote: Bron, My Cyrus is from RPM, and I am just nursing it along until my users finish migrating off and FastMail manages to complete my own migration, so I don't want to build from source. Why would IMAP/S block on empty /dev/random, while IMAP+STARTTLS works? FWIW, SASL2 seems to use urandom. If this is really stock CentOS 5 then I think everything Cyrus related should use /dev/urandom and not /dev/random. But, could it be that other software you installed uses /dev/random and makes it empty? I think the stock CentOS packages do in fact use /dev/urandom. Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Odd problem: IMAP/S suddenly not working, but no errors, and IMAP still works
On 11/1/10 10:46 AM, Simon Matter wrote: Bron, My Cyrus is from RPM, and I am just nursing it along until my users finish migrating off and FastMail manages to complete my own migration, so I don't want to build from source. Why would IMAP/S block on empty /dev/random, while IMAP+STARTTLS works? FWIW, SASL2 seems to use urandom. If this is really stock CentOS 5 then I think everything Cyrus related should use /dev/urandom and not /dev/random. But, could it be that other software you installed uses /dev/random and makes it empty? Most things are CentOS RPMs (thanks for those! ;), with a few from RPMforge. [r...@inspector ~]# rpm -q cyrus-imapd amavisd-new clamav spamassassin postfix httpd mod_ssl cyrus-imapd-2.3.7-7.el5_4.3 amavisd-new-2.6.4-3.el5.rf clamav-0.96.4-1.el5.rf spamassassin-3.3.1-3.el5.rf postfix-2.3.3-2.1.el5_2 httpd-2.2.3-43.el5.centos.3 mod_ssl-2.2.3-43.el5.centos.3 Which still leaves me thinking my port 993 problem isn't entropy, because STARTTLS works fine. That's my impression from the beginning, because lack of entropy has not been a known problem on the RHEL/CentOS configs. That's not much help of course. If you already restarted master and you know it's not stuck somehow, then the only thing I could think to check is your /var/lib/imap/tls_sessions.db database. I don't know if a broken TLS db could result in what you see but better check it out. Simon Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Odd problem: IMAP/S suddenly not working, but no errors, and IMAP still works
On 11/1/10 10:41 AM, Dan White wrote: On 31/10/10 20:51 -0400, Chris Pepper wrote: Alternatively, is there a way to make sure Cyrus requires STARTTLS on 143? I was blocking external access to it to make sure users always use encryption to connect, but port 143 with STARTTLS required would be an acceptable alternative. You can set 'allowplaintext: 0' to disallow plaintext logins over port 143. That would require clients to perform a STARTTLS, or negotiate a SASL security layer which meets your 'sasl_minimum_layer:' setting. Excellent, thanks! allowplaintext: 0 I am leaving sasl_minimum_layer at default for now. LOGINDISABLED before STARTTLS is encouraging, but I don't know why Authentication failed. generic failure *after* STARTTLS. On the other hand, with allowplaintext: 0 and after restarting cyrus-imapd, I can still get mail, so I suspect this is exactly what I wanted. Thanks, Chris [r...@inspector ~]# imtest -u pepper -t localhost S: * OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS LOGINDISABLED AUTH=DIGEST-MD5 AUTH=CRAM-MD5 SASL-IR] mail.reppep.com Cyrus IMAP4 v2.3.7-Invoca-RPM-2.3.7-7.el5_4.3 server ready C: C01 CAPABILITY S: * CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS LOGINDISABLED AUTH=DIGEST-MD5 AUTH=CRAM-MD5 SASL-IR ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE CATENATE CONDSTORE IDLE LISTEXT LIST-SUBSCRIBED X-NETSCAPE URLAUTH S: C01 OK Completed C: S01 STARTTLS S: S01 OK Begin TLS negotiation now verify error:num=19:self signed certificate in certificate chain TLS connection established: TLSv1 with cipher AES256-SHA (256/256 bits) C: C01 CAPABILITY S: * CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID AUTH=PLAIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5 AUTH=LOGIN SASL-IR ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE CATENATE CONDSTORE IDLE LISTEXT LIST-SUBSCRIBED X-NETSCAPE URLAUTH S: C01 OK Completed Please enter your password: C: A01 AUTHENTICATE PLAIN S: A01 NO authentication failure Authentication failed. generic failure Security strength factor: 256 -- Chris Pepper:http://cbio.mskcc.org/ http://www.extrapepperoni.com/ Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Odd problem: IMAP/S suddenly not working, but no errors, and IMAP still works
On 11/1/10 11:21 AM, Simon Matter wrote: On 11/1/10 10:46 AM, Simon Matter wrote: Bron, My Cyrus is from RPM, and I am just nursing it along until my users finish migrating off and FastMail manages to complete my own migration, so I don't want to build from source. Why would IMAP/S block on empty /dev/random, while IMAP+STARTTLS works? FWIW, SASL2 seems to use urandom. If this is really stock CentOS 5 then I think everything Cyrus related should use /dev/urandom and not /dev/random. But, could it be that other software you installed uses /dev/random and makes it empty? Most things are CentOS RPMs (thanks for those! ;), with a few from RPMforge. [r...@inspector ~]# rpm -q cyrus-imapd amavisd-new clamav spamassassin postfix httpd mod_ssl cyrus-imapd-2.3.7-7.el5_4.3 amavisd-new-2.6.4-3.el5.rf clamav-0.96.4-1.el5.rf spamassassin-3.3.1-3.el5.rf postfix-2.3.3-2.1.el5_2 httpd-2.2.3-43.el5.centos.3 mod_ssl-2.2.3-43.el5.centos.3 Which still leaves me thinking my port 993 problem isn't entropy, because STARTTLS works fine. That's my impression from the beginning, because lack of entropy has not been a known problem on the RHEL/CentOS configs. That's not much help of course. If you already restarted master and you know it's not stuck somehow, then the only thing I could think to check is your /var/lib/imap/tls_sessions.db database. I don't know if a broken TLS db could result in what you see but better check it out. Interesting. I moved tls_sessions.db aside restarted IMAPd, and it's apparently in a new format -- perhaps the default format has changed since it was first created. But 993 is still open but not responsive. I am going to try disabling Cyrus' IMAP/SSL and swapping in stunnel, as Rob @ FastMail has suggested as a workaround. Thanks, Chris [r...@inspector imap]# ls -l tls* -rw--- 1 cyrus mail 8192 Nov 1 11:27 tls_sessions.db -rw--- 1 cyrus mail 1976 Nov 1 11:27 tls_sessions.db.BAD [r...@inspector imap]# file tls* tls_sessions.db: Berkeley DB (Btree, version 9, native byte-order) tls_sessions.db.BAD: Cyrus skiplist DB -- Chris Pepper:http://cbio.mskcc.org/ http://www.extrapepperoni.com/ Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Odd problem: IMAP/S suddenly not working, but no errors, and IMAP still works
On 01/11/10 11:27 -0400, Chris Pepper wrote: On 11/1/10 10:41 AM, Dan White wrote: On 31/10/10 20:51 -0400, Chris Pepper wrote: Alternatively, is there a way to make sure Cyrus requires STARTTLS on 143? I was blocking external access to it to make sure users always use encryption to connect, but port 143 with STARTTLS required would be an acceptable alternative. You can set 'allowplaintext: 0' to disallow plaintext logins over port 143. That would require clients to perform a STARTTLS, or negotiate a SASL security layer which meets your 'sasl_minimum_layer:' setting. Excellent, thanks! allowplaintext: 0 I am leaving sasl_minimum_layer at default for now. LOGINDISABLED before STARTTLS is encouraging, but I don't know why Authentication failed. generic failure *after* STARTTLS. On the other hand, with allowplaintext: 0 and after restarting cyrus-imapd, I can still get mail, so I suspect this is exactly what I wanted. After sending the first email, I noticed that you have a sasl_pwcheck_method of saslauthd in your config. You probably also want a 'sasl_mech_list: plain login'. If you're depending on saslauthd to perform your authentication, digest-md5 and cram-md5 should always fail. -- Dan White Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
duplicatedeliver annotation
All, We've never had cause to try it out until now, but I can't seem to get the annotation set to suppress duplicate delivery for a single mailbox. We're running 2.3.16 on RHEL5, and I'm using cyradmin. But whenever I try to do mboxconfig mailbox duplicatedeliver true on a mailbox, I keep getting permission denied. I'm connecting as an admin user. I've also tried using on and 1 as the value, but nothing takes. Is there additional configuration that needs to be set up to allow this? Regards, -paul -- Paul D. Engle | Rice University Sr. Systems Administrator | Information Technology - MS119 (713)348-4702 | PO Box 1892 pen...@rice.edu| Houston, TX 77252-1892 pgpuCP5PHDLYP.pgp Description: PGP signature Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Odd problem: IMAP/S suddenly not working, but no errors, and IMAP still works
On Sun, Oct 31, 2010 at 10:40:13PM -0400, Chris Pepper wrote: Bron, My Cyrus is from RPM, and I am just nursing it along until my users finish migrating off and FastMail manages to complete my own migration, so I don't want to build from source. Why would IMAP/S block on empty /dev/random, while IMAP+STARTTLS works? FWIW, SASL2 seems to use urandom. I really don't know to be honest - we don't run any ssl enabled imapds, we do all the ssl in nginx on the frontend. It sounds like Rob's workaround might be all you need though :) Bron. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Odd problem: IMAP/S suddenly not working, but no errors, and IMAP still works
On 11/1/10 7:26 PM, Bron Gondwana wrote: On Sun, Oct 31, 2010 at 10:40:13PM -0400, Chris Pepper wrote: Bron, My Cyrus is from RPM, and I am just nursing it along until my users finish migrating off and FastMail manages to complete my own migration, so I don't want to build from source. Why would IMAP/S block on empty /dev/random, while IMAP+STARTTLS works? FWIW, SASL2 seems to use urandom. I really don't know to be honest - we don't run any ssl enabled imapds, we do all the ssl in nginx on the frontend. It sounds like Rob's workaround might be all you need though :) Neither do I. I decided to re-enable pop3 (which I don't use or allow, and had recently commented out) in cyrus.conf and restarted cyrus-imapd, and IMAP/SSL is working again! I commented it out and restarted Cyrus, and port 993 is still working. I'd say I just needed to restart the daemon, except I rebooted Saturday night after port 993 stopped working, so I don't know what's up. One interesting odd data point: after service cyrus-imapd stop, I still had a couple active connections to an imap daemon which was listening on port 993. I killed the process, but again that couldn't have persisted across the reboot I performed 1d19h ago. Bizarre! Thanks for everyone's suggestions. Chris Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
