Re: How to migrate away from BDB
On Tuesday 28 September 2010 19:03:20 Mark Nipper wrote: On 28 Sep 2010, Simon Matter wrote: Are these Debian specific? Or is there something missing from my installation? Or do these only exist when Cyrus is not running? (Which I would find strange) I don't know the Debian packages but I'm quite sure it's Debian specific. Looks like their way to remember the current state of backends somehow. Definitely Debian specific. I was referring you to those instructions as a general guideline. You'll need to substitute the appropriate information as needed. But basically, since you're probably not switching between versions, your cvt_cyrusdb will work without having to divine the version of your BDB files or worrying about converting them between versions. So I think, unless I'm horribly mistaken, all you need to do is dump the BDB versions of your files into skiplist format and you're golden! I was thinking along the same lines :) I will set up a test environment on a VM first to try this on. I can not risk any downtime on the mailserver without knowing exactly what I need to do. I won't be able to do this in the next few weeks due to other engagements though :( -- Joost Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: competition
Adam Tauno Williams wrote: On Wed, 2010-09-22 at 18:18 +0200, Jeroen van Meeuwen (Kolab Systems) wrote: The scenario is integration, not extension of Cyrus -which in and of itself works perfecly fine and reliable for us. We're not seeking to improve Cyrus' performance with *SQL db backends. But, this assumes the data that Cyrus stores in that DB would be useful outside the context of the Cyrus' processes. I've lightly played with the idea, and not gone any further - the data available isn't really very useful. Well, for one, our ActiveSync implementation wants the following information; - List of (subscribed) IMAP folders, - Annotations, per IMAP folder, - Current status of the contents of such IMAP folder, such as new messages or deleted messages, in comparison to what the client currently holds, - Message contents. While connecting through the IMAP server and have Cyrus hand over the answers, and correlate such information on the side of the 3rd party application is perfectly feasible, I think it may be more efficient to correlate the requested information from a database directly, as opposed to attempting to cache the results handed over by Cyrus by each 3rd party application. Imagine the following scenario; a client polls 3rd party application for a list of mailboxes and the content's status very regularly -basically what it's interested in knowing is whether anything changed. Doesn't condstore solve this issue inexpensively? [maybe I misunderstand condstore]. I thought it was equivalent to WebDAV/CalDAV ctags (which are mightily nice). I'm not sure whether the IMAP server's capabilities with regards to modification sequences has anything to do with this thread, but maybe I'm misunderstanding the IMAP CONDSTORE extension. Each 3rd party app will seek to cache the results somehow, for improved performance interacting with its clients and as to not continuously put load on the Cyrus server. Which is what WebDAV/CalDAV ctags are for. The WebDAV/CalDAV scenario doesn't really fly with mailboxes. For one, mailboxes tend to have plenty more folders and plenty more messages. The question is not how the 3rd party app *can* get the needed information, the question is how many 3rd party apps can be integrated *most efficiently* (both in terms of performance/lower overhead, as well as architecture and 3rd party app's design -DYI cache for each 3rd party app?). Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: high-availability Cyrus (i.e. glusterfs)?
On Wed, 29 Sep 2010, Tomasz Chmielewski wrote:
Hmm - I added this to imapd.conf:
annotation_db: skiplist
duplicate_db: skiplist
mboxlist_db: skiplist
ptscache_db: skiplist
quota_db: skiplist
seenstate_db: skiplist
tlscache_db: skiplist
When starting cyrus, I have this:
Sep 29 02:53:48 omega cyrus/master[1089]: process started
Sep 29 02:53:48 omega cyrus/ctl_cyrusdb[1090]: recovering cyrus databases
Sep 29 02:53:48 omega cyrus/ctl_cyrusdb[1090]: done recovering cyrus databases
Sep 29 02:53:49 omega cyrus/cyr_expire[1091]: DBERROR db4: Program version
4.2 doesn't match environment version
Sep 29 02:53:49 omega cyrus/cyr_expire[1091]: DBERROR: dbenv-open
'/shared/var/lib/cyrus/db' failed: Invalid argument
Sep 29 02:53:49 omega cyrus/cyr_expire[1091]: DBERROR: init() on berkeley
Sep 29 02:53:49 omega cyrus/cyr_expire[1091]: duplicate_prune: pruning back 3
days
Sep 29 02:53:49 omega cyrus/cyr_expire[1091]: duplicate_prune: purged 0 out
of 0 entries
Sep 29 02:53:49 omega cyrus/cyr_expire[1091]: expunged 0 out of 0 messages
from 0 mailboxes
Sep 29 02:53:49 omega cyrus/tls_prune[1092]: tls_prune: purged 0 out of 0
entries
Sep 29 02:53:49 omega cyrus/master[1089]: ready for work
Sep 29 02:53:49 omega cyrus/ctl_cyrusdb[1093]: checkpointing cyrus databases
Sep 29 02:53:49 omega cyrus/ctl_cyrusdb[1093]: done checkpointing cyrus
databases
# file /shared/var/lib/cyrus/db/*
/shared/var/lib/cyrus/db/__db.001: data
/shared/var/lib/cyrus/db/__db.002: data
/shared/var/lib/cyrus/db/__db.003: data
/shared/var/lib/cyrus/db/__db.004: data
/shared/var/lib/cyrus/db/__db.005: data
/shared/var/lib/cyrus/db/log.01: Berkeley DB (Log, version 8, native
byte-order)
/shared/var/lib/cyrus/db/skipstamp: data
The error and Berkeley DB log file is there even if I empty this
directory, and start Cyrus.
Did I miss some value in imapd.conf?
Cyrus is always linked with Berkeley DB, so it always tries to init the
Berkeley DB environment. Even with all your backends set to skiplist,
you'll still see the Berkeley DB log files in {configdir}/db/. You can
safely ignore them.
I'm not sure why you still get Berkeley DB errors when starting Cyrus. I
have converted everything to skiplist, and I do not get those errors.
Andy
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Incoming e-mail during mailbox relocation from one partition or backed to another
On Wed, 29 Sep 2010, Dmitry Ivanov wrote: Hello! Is it safe to relocate mailboxes from one partition or backend (in case of murder) to another while listening to lmtp or lmtp proxy? Is there a chance that relocation can fail or e-mail messages can be lost? Yes, you can move mailboxes live. Anyone currently connected to the mailbox via IMAP will see the mailbox contents disappear until they reconnect. Andy Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
