I'm a bit worried and I hope you can help me over that. I'm afraid that our server might run into entropy trouble when it gets hit by real world use. Here's the story:
We don't allow plaintext without a layer, so most connections will use TLS. Right now there are only about 50 users, but come Sunday there are going to be about 30,000 live accounts. Not all of them are actually in use, but of course it's going to be much more than now. We've made sure the server can handle the mail load, but I've noticed that there are sometimes substantial delays between accepting a connection and login, e.g.:
Jan 27 12:18:00 lvr1 master[6255]: about to exec /usr/lib/cyrus-imapd/imapd
Jan 27 12:18:00 lvr1 imap[6255]: executed
Jan 27 12:22:16 lvr1 imapd[6255]: accepted connection
Jan 27 12:22:16 lvr1 imapd[6255]: mystore: starting txn 2147739162
Jan 27 12:22:16 lvr1 imapd[6255]: mystore: committing txn 2147739162
Jan 27 12:22:16 lvr1 imapd[6255]: starttls: TLSv1 with cipher DES-CBC3-SHA (168/168 bits new) no authentication
Jan 27 12:23:44 lvr1 imapd[6255]: login: campfire.rrz.uni-koeln.de[134.95.19.27] xxx CRAM-MD5+TLS User logged in
Jan 27 12:23:44 lvr1 imapd[6255]: seen_db: user xxx opened /var/lib/imap/user/K/xxx.seen
Jan 27 12:23:44 lvr1 imapd[6255]: open: user xxx opened INBOX
That's one of the worst cases I've seen (and this specific instance might include waiting for the user to enter their password), but delays of 15 seconds are quite common, also with DIGEST-MD5 without TLS.
Our config is: name : Cyrus IMAPD version : v2.1.16-Invoca-RPM-2.1.16-4 2003/11/19 16:45:28 vendor : Project Cyrus support-url: http://asg.web.cmu.edu/cyrus os : Linux os-version : 2.4.9-e.35enterprise environment: Cyrus SASL 2.1.15 Sleepycat Software: Berkeley DB 4.0.14: (November 18, 2001) Built w/OpenSSL 0.9.6b [engine] 9 Jul 2001 Running w/OpenSSL 0.9.6b [engine] 9 Jul 2001 CMU Sieve 2.2 TCP Wrappers mmap = shared lock = fcntl nonblock = fcntl auth = unix idle = poll dirhash = full mailboxes.db = skiplist seen.db = skiplist subs.db = flat deliver.db = db3-nosync tls_sessions.db = db3-nosync
I know about /dev/random and /dev/urandom, but I'm not sure how to tell if that's really the issue. Whenever I've noticed delays myself and I've tried a "cat /dev/random" there seemed to be enough entropy. Any ideas what else might cause these delays?
Cheers, Sebastian Hagedorn -- Sebastian Hagedorn M.A. - RZKR-R1 (Gebäude 52), Zimmer 18 Zentrum für angewandte Informatik - Universitätsweiter Service RRZK Universität zu Köln / Cologne University - Tel. +49-221-478-5587
pgp00000.pgp
Description: PGP signature
