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
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
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
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
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 should
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
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
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).
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, 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 example
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).
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
-- 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
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
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 (xfs, ext3, Reiser), in a 2.4.20pre
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
--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
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 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,
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
.
-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
am asking
has been covered before
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
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 help your
23 matches
Mail list logo
