FYI: I use RH8.0 now (basicly had a window for uppgrading the server and
wanted to stay up to date on RH). It worked ok for me. The only problems
were that I'm missing the cyrus-Sasl-ldap plugin and some db3 trouble on
the db.
It worked ok the minute I managed to get tls right, ficed the db hashi
On Mon, 18 Nov 2002, Patrick Boutilier wrote:
> Henrique de Moraes Holschuh wrote:
> >For Linux:
> > 1. Heavily tested and debugged AND patched BerkeleyDB 3.2, stay away from
> > 4.x for now.
>
> I tried those stability patches and they didn't help. The only thing
They are NOT supposed to h
On Mon, 18 Nov 2002, Lawrence Greenfield wrote:
> Some of them (the lock timeout/wait is what I have in mind) will make the
> system perform not as well.
I'd have to profile it to know more, and I am quite short on time to do that
right now. Maybe the fastmail.fm crew has any comments on this is
.
> -Original Message-
> From: Tim Pushor [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 19, 2002 3:08 AM
> To: [EMAIL PROTECTED]
> Subject: Skiplist / best practice for 2.1 branch
>
>
> All,
>
> Hello, and I must first apologize because I know that what I
&
I've just finished doing some benchmarking and general server abusing
using ZD Labs IMAP test tool
(http://www.etestinglabs.com/benchmarks/svrtools/email/t1intro.asp) and
lmtpd performance makes sense. Each inbound message goes through lmtpd
which does duplicate suppression (by default) meaning eac
On Mon, 18 Nov 2002, Patrick Boutilier wrote:
> I tried those stability patches and they didn't help. The only thing
> that stopped lmtp from hanging was switching from db3_nosync to
> skiplist. What are the advantages of using db3_nosync over skiplist?
db3_nosync uses the Berkeley DB backend, wh
Henrique de Moraes Holschuh wrote:
For Linux:
1. Heavily tested and debugged AND patched BerkeleyDB 3.2, stay away from
4.x for now.
(i.e. use the ones from RedHat or Debian, not upstream).
2. Linux stability patches for Cyrus (see the Debian Cyrus package :-)
Cyrus upstream
--On Monday, November 18, 2002 8:57 PM -0200 Henrique de Moraes Holschuh
<[EMAIL PROTECTED]> wrote:
Linux-specific that they have would negative consequences if applied
to a source tree used for a Solaris or *BSD build?? With Linux being
No negative consequences that I know of. But increased
Jonathan Marsden wrote:
On 18 Nov 2002, Jules Agee writes:
I think a lot of people would recommend you stay away from RH 8.0
for production servers. Not that I know of any particular
problems... it's just that there's a lot of bleeding-edge stuff that
hasn't proved itself as far as I'm concerned.
On Tue, 19 Nov 2002, Sebastian Hagedorn wrote:
> -- Henrique de Moraes Holschuh <[EMAIL PROTECTED]> is rumored to have mumbled
> on Montag, 18. November 2002 19:20 Uhr -0200 regarding Re: Skiplist / best
> practice for 2.1 branch:
>
> > 4. Journaling filesystem (
On 18 Nov 2002, Jules Agee writes:
> Jonathan Marsden wrote:
>> Are you recommending that RH 8.0 users running Cyrus should
>> downgrade their BDB libraries to a 3.x RPM set ...
> I think a lot of people would recommend you stay away from RH 8.0
> for production servers. Not that I know of any
-- Henrique de Moraes Holschuh <[EMAIL PROTECTED]> is rumored to have mumbled
on Montag, 18. November 2002 19:20 Uhr -0200 regarding Re: Skiplist / best
practice for 2.1 branch:
4. Journaling filesystem (xfs, ext3, Reiser), in a 2.4.20pre kernel.
Why do you suggest using 2.4.20pre? Is
Jonathan Marsden wrote:
Are you recommending that RH 8.0 users running Cyrus should downgrade
their BDB libraries to a 3.x RPM set for db3 (perhaps as supplied for
RH 7.3)? Wouldn't that tend to have adverse consequences for other
software (Sendmail comes to mind) which expects them and which mig
Henrique de Moraes Holschuh wrote:
On Mon, 18 Nov 2002, Jonathan Marsden wrote:
On 18 Nov 2002, Henrique de Moraes Holschuh writes:
1. Heavily tested and debugged AND patched BerkeleyDB 3.2, stay away
from 4.x for now. (i.e. use the ones from RedHat or Debian, not
upstream).
R
On Mon, 18 Nov 2002, Jonathan Marsden wrote:
> On 18 Nov 2002, Henrique de Moraes Holschuh writes:
> > 1. Heavily tested and debugged AND patched BerkeleyDB 3.2, stay away
> >from 4.x for now. (i.e. use the ones from RedHat or Debian, not
> >upstream).
>
> Red Hat now supplies 4.0.14, for
On 18 Nov 2002, Henrique de Moraes Holschuh writes:
> For Linux:
> 1. Heavily tested and debugged AND patched BerkeleyDB 3.2, stay away
>from 4.x for now. (i.e. use the ones from RedHat or Debian, not
>upstream).
Red Hat now supplies 4.0.14, for example the db4-4.0.14-14.i386.rpm in
Red
On Mon, 18 Nov 2002, Tim Pushor wrote:
> >>duplicate? mboxlist? seen? subs? tls?
> >db3_nosync, skiplist, skiplist, flat, db3_nosync
For Linux:
1. Heavily tested and debugged AND patched BerkeleyDB 3.2, stay away from
4.x for now.
(i.e. use the ones from RedHat or Debian, not upstream)
Tim,
RedHat 7.2 with BDB 4.0.14
Tim Pushor wrote:
Patrick,
What version of Berkeley (Sleepycat) DB were you using? What OS?
Thanks,
Tim
Patrick Boutilier wrote:
duplicate? mboxlist? seen? subs? tls?
db3_nosync, skiplist, skiplist, flat, db3_nosync
I had nothing but trouble using
Patrick,
What version of Berkeley (Sleepycat) DB were you using? What OS?
Thanks,
Tim
Patrick Boutilier wrote:
duplicate? mboxlist? seen? subs? tls?
db3_nosync, skiplist, skiplist, flat, db3_nosync
I had nothing but trouble using db3_nosync for duplicate so I would
suggest using skiplis
On Mon, 18 Nov 2002, Tim Pushor wrote:
> >db3_nosync, skiplist, skiplist, flat, db3_nosync
> >
> If this truly is a 'best practice', should it be added to the
> documentation? or to a FAQ?
Some people have claimed problems with berkeley DB in general, but from a
theoretical standpoint the above s
Rob Siemborski wrote:
On Mon, 18 Nov 2002, Tim Pushor wrote:
I have done some research on the skiplist algorithm, but am wondering
about the cyrus implementation. Is it stable?
I didn't know anyone else was implementing a persistant skiplist. Our
implementation is stable (and I thought
Rob Siemborski wrote:
This is in the mailing list about 8 times, but..
duplicate? mboxlist? seen? subs? tls?
db3_nosync, skiplist, skiplist, flat, db3_nosync
I had nothing but trouble using db3_nosync for duplicate so I would
suggest using skiplist as well for duplicate.
-Rob
On Mon, 18 Nov 2002, Tim Pushor wrote:
> I have done some research on the skiplist algorithm, but am wondering
> about the cyrus implementation. Is it stable?
I didn't know anyone else was implementing a persistant skiplist. Our
implementation is stable (and I thought "proprietary").
> What is
All,
Hello, and I must first apologize because I know that what I am asking
has been covered before, but I am having a difficult time finding
information in the archives.
I am still running the 1.6 branch on all of my production servers, and
want to bring everything up to 2.1. I have resisted
24 matches
Mail list logo
