1. Not likely, but not impossible... To Quote a source The /dev/random device hands out "high-quality" random bits, up to the limit of the "random" information it has been seeded with. The /dev/urandom device does not have this limitation. It continues to hand out bits of decreasing quality as long as it is polled. 2. mknod /dev/random c 1 8 (you may need to chmod it to ensure it can be read of course) 3. You can use aptitude to get the SASL source, then using the Debian Modified/patched Sources, you can run configure and then install it into a temporary directory and then create a .deb out of that, however you will want to freeze that afterwards so you don't download an updated version that sets you back. Alternatively, you can report the bug to the debian people, and have them re-compile it to use /dev/urandom instead of /dev/random and save you the effort. However that may take a few days. If you wish to make your own package, you can read this http://linuxdevices.com/articles/AT8047723203.html Additionally Google will be your friend on how to build Debian Packages, as I haven't done so in quite some time thankfully. Scott Rick Kunkel wrote: > Hm! I did some additional reading after receiving this, and it seems > that pursuing the random number generator path is the way to go... > > A coupla quick questions (that I think are likely going to be answered > with "it depends" answers): > > 1. Is nuking /dev/random in the way described going to have adverse > affects on other elements/services? > > 2. If, andter going this, I want to restore /dev/random to what it > was beforehand, how would I go about doing that? > > 3. We used aptitude (in all its inflexibility) to install sasl. Does > anyone know if there is an easy way to change this compile-time flag, > but still use aptitude to install SASL? (Probably off-topic for this > list, I admit.) > > Thanks! > > Rick Kunkel > > On Tue, 11 Sep 2007, Scott M. Likens wrote: > >> Rick, >> >> This problem is related to Debian using /dev/random instead of >> /dev/urandom. >> >> Short term solution would be to rm /dev/random >> >> mknod /dev/random c 1 9 >> >> The other solution for you would be to recompile the sources and change >> the configure to use urandom instead of random... You can search the >> archives and search for urandom on how to do that. >> >> Scott >> >> Rick Kunkel wrote: >>> Hello all, >>> >>> I'm new to Cyrus. Historically, I've used Qpopper, Sendmail, and UW >>> IMAP. >>> We recently switched to Cyrus for IMAP. It came highly recommended... >>> >>> We've got this on a darned burly machine, running some very recent >>> version >>> of Debian, with a fast CPU, 4GB RAM, and fast SAS drives. When testing >>> the thing, before it went into production, everything worked awesomely. >>> However, having loaded it with 2300 users, it's suddenly acting >>> erratically. (Incidentally, of the 2300 users, almost all are POP >>> users, >>> which seems to be working fine. A few hundred -- at most -- are >>> IMAP, and >>> they are split between squirrelmail users and a handful that use >>> standard >>> MUAs.) >>> >>> The server acts as if it's low on resources or something, or has hit >>> some >>> kind of connection limit. It's speedy as heck WHEN it does it >>> what's it's >>> supposed to, but that initial connection is sketchy. For the first 30 >>> seconds after you restart it, it's generally good, but it goes downhill >>> from there. >>> >>> Testing with telnet exhibits this behavior. Here's a sample session... >>> >>> # telnet mail 143 >>> Trying xxx.xxx.xxx.xxx... >>> Connected to mail. >>> Escape character is '^]'. >>> >>> >>> And then it just kinda sits. Sometimes, after 30 seconds or so >>> >>> * OK mail Cyrus IMAP4 v2.2.13-Debian-2.2.13-10 server ready >>> >>> >>> We're currently using the following line in cyrus.conf for imapd: >>> >>> imap cmd="imapd" listen="imap" prefork=1 >>> >>> >>> We've messed with tons of different settings here, to little avail. >>> >>> There don't seem to be any salient log entries. >>> >>> Anyone have any ideas? >>> >>> Thanks, >>> >>> Rick Kunkel >>> ---- >>> 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 >>> >>> >>> >>> >>> >>> >> >> > > > !DSPAM:46e7181084202125116682! > > ---- 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
