Re: unified murder and GSSAPI
On Tue, 17 Oct 2006, Huaqing Zheng wrote: From: Huaqing Zheng [EMAIL PROTECTED] To: info-cyrus@lists.andrew.cmu.edu Date: Tue, 17 Oct 2006 18:27:27 -0700 Subject: unified murder and GSSAPI ... Yet when I switch over the cyrus user, set my KRB5CCNAME to the correctly generated service/murder ticket and try to run ctl_mboxlist -mw, I get the following in my syslog: ctl_mboxlist[13748]: couldn't authenticate to backend server: generic failure ctl_mboxlist[13847]: GSSAPI Error: Miscellaneous failure (Server not found in Kerberos database) Any ideas or pointers at better documentation on how to get this working? The Server not found in Kerberos database error usually indicates that it's not asking for the service key you've set up. Your kerberos logs should tell you what service key it's requesting. You need to set up a keytab containing that key. (No, I haven't set something like this up. But the logs on the kerberos server are often useful in diagnosing obscure failures.) -- Dennis Davis, BUCS, University of Bath, Bath, BA2 7AY, UK [EMAIL PROTECTED] Phone: +44 1225 386101 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
Re: idled vs poll
Ken Murchison wrote: Jorey Bump wrote: Cyrus IMAP advertises IDLE, and the docs mention that the default method is poll, but shed little light on the use of idled as an alternative. Which method is preferred, better performing (for users and/or servers), and more robust? idled will provide the client with instant updates, where poll will only give them at the given interval. I don't know if idled has been tested under a heavy load. We deployed idled here over the summer on our main staff IMAP server, a Sunfire v480 running Solaris 8 and cyrus-imap 2.2.12. It typically has about 13,000 concurrent IMAP processes, most of which are not using idle as our main desktop client doesn't support it. Initially, we saw a small rise in the server load, which wasn't particularly worrying, and occasionally slightly more worrying sluggish authentication. Last week was the start of term, and the system collapsed completely. The load average rose from about 1 to between 6 and 9, and socket communication started failing, breaking LMTP delivery, SASL authentication and IDLE, all of which communicate over file system sockets: cannot connect to saslauthd server: Connection refused Failed to connect to socket /var/cyrus/imap/socket/lmtp for local_cyrus_deliver transport: Connection refused error sending to idled: 0 This left the system almost completely unusable. We tried various things to fix it, to no avail. Last night we rebuilt Cyrus with with-idle=poll; the load is immediately much lower (currently 0.7), authentication and IMAP are vastly more responsive and there are no socket errors logged. Incidentally, our main student server, running Solaris 9, showed no such problems. It's unclear if this is due to the different usage patterns (the students, generally speaking, make much less intensive use of the email system, and aren't all back yet) or if it's related to the different OS version. The former seems more likely. cheers, Adam Stephens. -- Adam Stephens Network Specialist - Email DNS [EMAIL PROTECTED] 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
Re: idled vs poll
--On 18. Oktober 2006 11:25:09 +0100 Adam Stephens [EMAIL PROTECTED] wrote: We deployed idled here over the summer on our main staff IMAP server, a Sunfire v480 running Solaris 8 and cyrus-imap 2.2.12. It typically has about 13,000 concurrent IMAP processes Wow, that's a lot of sessions! I'm surprised about that. We have about 35,000 users, yet we rarely have more than 700 concurrent IMAP processes. Partially that's because our Webmail system, which is surprisingly popular, doesn't cache sessions. But the majority of users use POP anyway. Initially, we saw a small rise in the server load, which wasn't particularly worrying, and occasionally slightly more worrying sluggish authentication. Last week was the start of term, and the system collapsed completely. The load average rose from about 1 to between 6 and 9, That's not really such a high load, although that depends on the number of processors your server has. This left the system almost completely unusable. We tried various things to fix it, to no avail. Last night we rebuilt Cyrus with with-idle=poll; the load is immediately much lower (currently 0.7), authentication and IMAP are vastly more responsive and there are no socket errors logged. Surprising, but good to know for future reference. -- .:.Sebastian Hagedorn - RZKR-R1 (Gebäude 52), Zimmer 18.:. Zentrum für angewandte Informatik - Universitätsweiter Service RRZK .:.Universität zu Köln / Cologne University - ✆ +49-221-478-5587.:. .:.:.:.Skype: shagedorn.:.:.:. pgpPse6o33y53.pgp Description: PGP signature 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
Re: idled vs poll
--On Wednesday, October 18, 2006 2:00 PM +0200 Sebastian Hagedorn [EMAIL PROTECTED] wrote: --On 18. Oktober 2006 11:25:09 +0100 Adam Stephens [EMAIL PROTECTED] wrote: We deployed idled here over the summer on our main staff IMAP server, a Sunfire v480 running Solaris 8 and cyrus-imap 2.2.12. It typically has about 13,000 concurrent IMAP processes Wow, that's a lot of sessions! I'm surprised about that. We have about 35,000 users, yet we rarely have more than 700 concurrent IMAP processes. We regularly have between 10,000 and 13,000 concurrent processes each day, depending on the day of the week (heavier on Mon-Wed). cannot connect to saslauthd server: Connection refused Failed to connect to socket /var/cyrus/imap/socket/lmtp for local_cyrus_deliver transport: Connection refused error sending to idled: 0 The first thing I would do here is to use LMTP as a TCP socket instead of a UNIX domain socket. We use Tru64 in our environment, and when I first deployed Cyrus under that architecture, the first thing I noticed what that as load increased, the more connection refused messages I saw with LMTP. Pointing my MTA to a TCP LMTP socket completely eliminated that problem for us. However, you should still keep the UNIX socket, since the deliver program still uses that instead of the TCP socket (the last time I checked). Additionally, when setting up the TCP socket, it would be good to set it to listen only on localhost or a private address (to prevent Internet users from connecting to your LMTP server and bypassing your MTA and spam/virus filtering controls). It is either that, or you configure authentication for the LMTP server (which, admittedly, I have never done). For SASL, I don't know if there can be any changes there. We use UNIX sockets for it as well, and I haven't investigated to see if there is a TCP socket option. That might help if there is one. On our system, when I see load increase, I definitely see SASL authentication take longer as well. We have worked most of our load problems out (Tru64 related), so that has improved considerably. We use the poll method, not idled. Good luck. Scott -- +---+ Scott W. Adkinshttp://www.cns.ohiou.edu/~sadkins/ UNIX Systems Engineer mailto:[EMAIL PROTECTED] ICQ 7626282 Work (740)593-9478 Fax (740)593-1944 +---+ PGP Public Key available at http://www.cns.ohiou.edu/~sadkins/pgp/ pgpTpqBffmAzI.pgp Description: PGP signature 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
Re: different certs for pop3 and imap
On Wed, 18 Oct 2006, Marten Lehmann wrote: Hello, imap_tls_cert_file: /etc/ssl/certs/cyrus-imap.pem imap_tls_key_file: /etc/ssl/private/cyrus-imap.key pop3_tls_cert_file: /etc/ssl/certs/cyrus-pop3.pem pop3_tls_key_file: /etc/ssl/private/cyrus-pop3.key thanks for your help. I just want to add that you have to write pop3s_ and imaps_, otherwise I get errors like this: imaps[12998]: imaps: required OpenSSL options not present imaps[12998]: Fatal error: imaps: required OpenSSL options not present master[12920]: process 12998 exited, status 75 master[12920]: service imaps pid 12998 in READY state: terminated abnormally master[13000]: about to exec /usr/lib/cyrus-imapd/imapd The prefix should be the service name used in cyrus.conf. So the following cyrus.conf entry: imaps cmd=/usr/local/cyrus/bin/proxyd -s listen=imaps prefork=10 would map to imaps_tls_cert_file, etc. Andy 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
Re: Question about using ipurge
I've misunderstood the man page. Thanks On Tue, 17 Oct 2006, Andrew Morgan wrote: On Tue, 17 Oct 2006, AndrXs Tarallo wrote: We need to clean certain mails from a mailbox. Specifically we are trying to clean mails older than 30 days. So we execute (as cyrus) this command: ipurge -d 30 username It returns almost inmediately but nothing happens and the mails remain there. We didn't use -f flag because we were affraid of deleting all mailboxes. Thanks in advance Have you tried using ipurge -d 30 user.username? Whoops, the manpage says: Ipurge by default only deletes mail below shared folders, which means that mails in mailbox(es) below INBOX.* and user.* stay untouched. Use the option -f to also delete mail in mailbox(es) below these folders. So you'll have to use the -f option. Andy A/P Andres Tarallo WDB Consultores Montevideo - Uruguay 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
