Index: [Article Count Order] [Thread]

Date:  Fri, 09 May 2008 10:57:49 +1000
From:  Greg Kuhnert <greg.kuhnert (at mark)>
Subject:  [coba-e:12775] Re: dovecot udpate
To:  Hisao SHIBUYA <shibuya (at mark)>
Cc:  coba-e (at mark)
Message-Id:  <4823A18D.3030906 (at mark)>
In-Reply-To:  <4823789C.3060301 (at mark)>
References:  <327DE0A0-4C10-47A0-B6F7-71D79103911B (at mark)> <5fa041b20805060033t6b2551e6l46f710fc664f9943 (at mark)> <1d4c951a0805060646t2f5824eal999403f55697c73b (at mark)> <7A304A11-98EE-49B3-AB64-2D64109BF7F1 (at mark)> <033501c8b041$da2c2c70$6400a8c0 (at mark) HPPAVILION> <450AA6B0-4436-492D-BDEF-4D35ACE43CD5 (at mark)> <7853B509BA765D40B8DACAEA2F64B2A4023890F9 (at mark)> <8FBC9FEF-EAAA-4F46-84A9-A19A62D82298 (at mark)> <4823789C.3060301 (at mark)>
X-Mail-Count: 12775

I spoke too soon. Its all back to normal now. It was weird. I looked at 
the box, and there were no CPU load problems, no network load issues, no 
brute-force attacks in progress. It was just slow. Restarted it, and its 
all fixed.


Greg Kuhnert wrote:
> I notice the new dovecot has been pushed. It might be helping on the 
> pwdb related matters, but my mail performance has gone down the drain. 
> For me to login to my own inbox is taking 30 seconds to change from 
> one imap folder to another.....
> Anyone else having problems after the update?
> Regards,
> Greg.
> Hisao SHIBUYA wrote:
>> Hi Rusty and all,
>>>>> First, let me say thank you for all you do.
>>>>> Second, let me ask a question: is converting BQ from PAM to flat
>>> files
>>>>> going backwards? It doesn't appear to be a step forward, but a step
>>>>> backward.
>>>>> Shudder the word, but has anyone looked at Zeffie's recommendation to
>>>>> see if it had any value before moving backwards?
>>>> Changing flat file from pwdb will be performance down.
>>>> On some point, changing flat file means to be a step back.
>>>> I read Zeffie's post as coba-e:12183 again.
>>>> If it is true, and the pwdb isn't the cause of the issue with dovecot.
>>>> That issue is cause of dovecot pwdb implementation, we don't need to
>>> change back to flat file.
>>> <...>
>>>> Any comment?
>>>> Regards,
>>>> Hisao
>>> I've been playing around with the "login_max_processes_count" option in
>>> dovecot.conf, and while it seems to work great preventing issues when
>>> there is a dictionary-attack against POP3, it obviously had no 
>>> affect on
>>> a recent FTP dictionary-attack... pwdb still flaked out, and you would
>>> have to login with root (since root is in shadow vs pwdb) to manually
>>> fix or wait for sometime after the attack has stopped (time enough for
>>> db_recover to do its thing).
>>> I see shadow vs pwdb as a step back also, but would be a step towards
>>> stability and reliability.
>> Yes, pwdb has hung up issue with dictionary attack.
>> And one more reason, that is compatibility.
>> I checked pam and pwdb package of CentOS5, it has pam 0.99.
>> It doesn't have pwdb library.
>> Does anyone know why pwdb library was removed?
>> On performance point, we can use db file for nsswitch as same as
>> current database.
>> So, if somebody would like to use db file for pam, they can
>> install nss_db and make on /var/db directory, it makes db file
>> from flat file.
>>> I know BQ made the change from vsftpd to proftpd, so does proftpd 
>>> have a
>>> similar config setting as dovecot that may reduce issues with pwdb
>>> during dictionary attacks? But, is this a bad direction to head; tuning
>>> the individual services instead of replacing the underlying
>>> authentication mechanism?
>> There is no specific reason to use proftpd, I just ported the original
>> code to RH based linux, and original code supported proftpd.
>> That is why I use proftd.
>> I understood somebody said that vsftpd configuration file is almost
>> same as proftpd one.
>> If it is true, it isn't difficult to migrate to vsftpd.
>> It means, we don't release update package for proftpd.
>> It is very good point for us.
>> Anyway, I will fix the pwdb and dovecot issue in a couple of weeks.
>> Thanks,
>> Hisao