Hi,
After a long bout of unrelated issues I have had a chance to revisit my
cyrus issues. I managed to reduce startup times by increasing the
frequency of checkpoints in cyrus.conf. I have installed pam_mysql 0.5
and recompiled sasl with a few options random being one and removed
unwanted mech
Lainaus Matthew baker <[EMAIL PROTECTED]>:
> pam_mysql 0.4.7 which has been patched to allow for crypt passwords
> and
> md5 hashes.
> My previous server had both types stored. I suppose one
> would be to move to a more stable (newer) version of pam_mysql.
> However,
> my patch only seems to wo
On Tue, 2004-02-10 at 02:05, Andrew Morgan wrote:
> So let me
> say that pam_mysql is not the only pam module that seems to leak memory.
> Perhaps it is a problem with libpam itself?
My RH8 system doesn't set a limit on saslauthd process reuse, and I
authenticate via '-a pam' to libpam_ldap. I ha
On Mon, 9 Feb 2004, Matthew baker wrote:
> Hi,
> Thanks for the reply.
>
> Rob Siemborski wrote:
> > On Sat, 7 Feb 2004, Matthew Baker wrote:
> >
> > If you are using PAM with saslauthd, you need to be very sure that
> > whatever PAM module you are using doesn't have any memory leaks, other
Hi,
--On Montag, 9. Februar 2004 15:48 Uhr + Matthew baker <[EMAIL PROTECTED]>
wrote:
Long login times are often caused by
insufficient entropy in the system.
Sorry, I'm not familiar with that phrase. Do you mean I need to define
somewhere in the configuration or compile time /dev/random or
--On Montag, 9. Februar 2004 10:16 Uhr -0500 Rob Siemborski
<[EMAIL PROTECTED]> wrote:
On Mon, 9 Feb 2004, Sebastian Hagedorn wrote:
>> I'm still fuzzy on how to find out if that's the cause. as I wrote in
>> an ealrier message, "cat /dev/random" doesn't seem to block ...
[snip]
Any ideas regard
Hi,
Thanks for the reply.
Rob Siemborski wrote:
On Sat, 7 Feb 2004, Matthew Baker wrote:
If you are using PAM with saslauthd, you need to be very sure that
whatever PAM module you are using doesn't have any memory leaks, otherwise
you'll become very sad very quickly.
pam_mysql 0.4.7 which
Hi,
--On Montag, 9. Februar 2004 9:52 Uhr -0500 Rob Siemborski
<[EMAIL PROTECTED]> wrote:
It takes between 7 and 15 seconds to login into any mailbox even if it's
empty. Regardless of client or OS. Also it takes about 5 minutes after a
restart before the deliver.db is ready and logins start. M
--On Montag, 9. Februar 2004 10:07 Uhr -0500 Rob Siemborski
<[EMAIL PROTECTED]> wrote:
On Mon, 9 Feb 2004, Sebastian Hagedorn wrote:
I'm still fuzzy on how to find out if that's the cause. as I wrote in an
ealrier message, "cat /dev/random" doesn't seem to block ...
If it *is* demonstrably the c
On Mon, 9 Feb 2004, Sebastian Hagedorn wrote:
> >> I'm still fuzzy on how to find out if that's the cause. as I wrote in an
> >> ealrier message, "cat /dev/random" doesn't seem to block ...
[snip]
> Any ideas regarding my first question?
strace/truss an imapd during the connection process and see
On Mon, 9 Feb 2004, Sebastian Hagedorn wrote:
>
> I'm still fuzzy on how to find out if that's the cause. as I wrote in an
> ealrier message, "cat /dev/random" doesn't seem to block ...
>
> If it *is* demonstrably the cause in many instances, why isn't the default
> for SASL to use /dev/urandom?
On Sat, 7 Feb 2004, Matthew Baker wrote:
> Problem 1.
> Saslauthd gradually grows in memory size until the login process grinds
> to a halt. I have set it to restart once an hour to clear it. I have
> tried setting the option -n0 to force a child for each auth request but
> that seem to create num
Hi all,
I recently started using Cyrus Imap 2.1.15 on a system with 5000 mail
accounts (500 actively used on a daily basis). I have setup Mysql for
virtual alias lookups for a Postfix mta and also for authentication via
saslauthd. I initially had major issues with DB errors and general
instab
13 matches
Mail list logo
