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 lon
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 hav
Cyrus could lag at this stage if there is a problem reversing its own
IP. With the 'listen' argument specified as is, I would think it would
be reversing 127.0.0.1 (or possibly the main IP on the box?). Make sure
that you have both of these IPs specified in the hosts file. Also make
sure that your
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
On note #3, I imagine changing to a 2.6 kernel has to do with the
entropy pool in /dev/random as it differs in 2.4 from 2.6
Scott
Andy Fiddaman wrote:
> On Tue, 11 Sep 2007, Rick Kunkel wrote:
>
> ; # telnet mail 143
> ; Trying xxx.xxx.xxx.xxx...
> ; Connected to mail.
> ; Escape character is '^]
On Tue, 11 Sep 2007, Rick Kunkel wrote:
; # 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
Generally this kind of delay
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
I had the same problems. if you google for this you'll find a discussion
regarding how SASL context expires should be handled. Heimdal allows
expired contexts to be used after expiration. MIT does not.
1) indefinitely long means the default lifetime of your KDC or the
individual keys involved.
My frontends authenticate to the backends using GSSAPI. Every 5
hours the frontends do a kinit to get a TGT to talk to the backend
and all is good.
However, if the frontend imap (proxyd) is proxying a session for more
than 10 hours I get:
imaps[3207]: GSSAPI Error: The context has expi
Hello all,
I have 2 servers and try to make replication between them.
I have FreeBSD 6.2 and Cyrus IMAPd 2.3.9 compiled from sources.
Configuration of master server.
imapd.conf :
...
sync_machineid: 1
sync_host: xx.xx.xx.xx
sync_authname: x
sync_password: x
sync_log: 1
cyrus.conf:
STA
See also https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2805
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:info-cyrus-
> [EMAIL PROTECTED] On Behalf Of Wesley Craig
> Sent: Friday, September 07, 2007 10:12 PM
> To: David Newman
> Cc: info-cyrus@lists.andrew.cmu.edu
> Subject: Re
Am Montag, den 10.09.2007, 22:11 +0200 schrieb Ulrich Spoerlein:
> On Mon, 10.09.2007 at 16:01:12 +0200, Johannes Rußek wrote:
> > beloved list,
> >
> > i'm so free to ask this question probably for the 1000st time: how can i
> > manage sieve script for shared folders?
> > i have a few shared fold
On Sep 10, 2007, at 11:59 AM, Gary Mills wrote:
> We have a Cyrus murder configuration with one proxy front-end and
> one storage back-end. I'm very pleased with it. However, users who
> happen to look at the full headers of their e-mail are often alarmed
> by the word `murder' that appears in t
13 matches
Mail list logo
