Re: Cyrus vs Dovecot
On Wed, 13 Aug 2008, Wesley Craig wrote: > On 13 Aug 2008, at 10:31, kbajwa wrote: >> I think you are missing a point which is most important, i.e., what >> type of >> support Cyrus vs Dovecot offers. In my experience: >> >> Cyrus = 0 >> Dovecot= 100 > > As someone who answers many help requests for cyrus (and I'm very far > from the only one), I can honestly say I've never seen a requests > from you. Perhaps you've had a lot of occasion to ask for help with > Dovecot. I'm happy to hear you've gotten that help. Community is a > lot of what open source software is about. As for your experience > with the cyrus imapd community, perhaps your sample size is too small. > > Or perhaps you're thinking of paid support? Because I know very well > that you can get that for cyrus imap. can you provide links to where from? David Lang Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Auto setting an expiration
Via autocreateinboxfolders and autocreatequota a user's mailbox/mailboxes can automatically be created when they authenticate to the server. Is there any way to automatically assign an "expire" value to newly created mailboxes? We automatically create a sent-mail folder when the user logs in and would like to set the expire value of that mailbox to 365. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Web-cyradm and Zimbra maybe?
> > I'm using web-cyradm (mysql frontend for virt. domains+cyrus+postfix > > integration) for years and very happy with it. > > Now we need some implementation for shared calendars (let's say calendar > > solution for all our users). > > What would you recommend? > > Web-cyradm and Zimbra integration? Anyone have any experience with it? How > > would you handle authentication issue? > We use Horde here with LDAP for domains+cyrus+postfix+calendars but it > works equally well with SQL. Got excellent webmail interface as well as > shared calendar support. > http://www.horde.org/ I second the vote for Horde. We've use'd Horde for webmail for a very long time - it is simply the best webmail interface available and does a very good job at dealing with the dorked or thrashed messages produced by some mail clients. In our testing [at the time] it was the only webmail interface that could deal reliably with messages from Lotus Notes/Domino that some of our customers sent. Also the Horde suite can front-end almost any data-store or database, it really is amazingly configurable. While we use OpenGroupware as the backend for our scheduling (calendering) and CRM, etc... we use Horde for providing webmail and interconnect the addressbook to our groupware system. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
RE: Web-cyradm and Zimbra maybe?
> > > I'm using web-cyradm (mysql frontend for virt. domains+cyrus+postfix > > > integration) for years and very happy with it. > > > Now we need some implementation for shared calendars (let's say > > > calendar solution for all our users). > > > > > > What would you recommend? > > > Web-cyradm and Zimbra integration? Anyone have any experience with > > it? > > > How would you handle authentication issue? > > > > > > Any other suggestions? > > > > > > > Bedework[1] seems interesting. > > > > [1] http://www.bedework.org/ > > http://www.kolab.org > > Best Regards > > Joon Thanks guys for all the answers :) I'll check them all. Best Regards, Leon Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Conversion Debian Cyrus 2.1 to 2.2, experiences
Gabor Gombas schreef: > On Thu, Aug 07, 2008 at 10:51:21AM +0200, Paul van der Vlis wrote: > >> make backups: >> cp -a /var/lib/cyrus /var/lib/cyrus-backup >> cp -a /var/spool/sieve /var/spool/sieve-backup >> cp -a /usr/lib/cyrus/ /usr/lib/cyrus-backup >> cp -a /var/spool/cyrus /var/spool/cyrus-backup >> The last one takes long... > > Don't you have regular backups? If you don't, you should better start > doing them... I do have regular backups, but if I do something like this I like a way back to the old situation, without the loss of the mail since the last backup. > Anyway, you can use rsync to make an initial copy while > the old service is still running and a much quicker update when the old > service is stopped. Correct, that's better. >> remove packages: >> apt-get remove cyrus21-common cyrus21-admin cyrus21-clients >> libcyrus-imap-perl21 >> dpkg --get-selections | grep cyrus >> >> backup config-files: >> mv /etc/imapd.conf /etc/imapd.conf.backup >> mv /etc/cyrus.conf /etc/cyrus.conf.backup > > I'd do that _before_ removing the packages... Without --purge, the configfiles are not removed. But maybe your way is better. >> install packages: >> apt-get install cyrus-imapd-2.2 cyrus-admin-2.2 cyrus-clients-2.2 >> libcyrus-imap-perl22 db4.2-util cyrus-pop3d-2.2 >> >> choose to overwrite cyrus.conf and imapd.conf (I wonder why this files >> are still there). > > Because you've used "apt-get remove" instead of "apt-get purge". I did also a "mv /etc/imapd.conf /etc/imapd.conf.backup" etc. > This was my recipe for a 2.1 -> 2.3 (from experimental) migration: > > cd /var/lib/cyrus/db > db3_recover > cd /var/lib/cyrus > db4.X_upgrade deliver.db > rm tls*db > cd db > db4.X_checkpoint -1 > > (replace 'X' with the correct BDB version) Thanks for the information! With regards, Paul van der Vlis. -- http://www.vandervlis.nl/ Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Conversion Debian Cyrus 2.1 to 2.2, experiences
Gabor Gombas schreef: > On Thu, Aug 14, 2008 at 11:49:43AM +0200, Paul van der Vlis wrote: > >>> Just a side note: I am pretty sure your mailboxes.db is a skiplist >>> database which is AFAIK the default for mailboxes.db in Cyrus IMAP 2.1 >>> and 2.2. No conversion is necessary. >> I think that's correct, but I don't know for sure how to check the type. >> The conversed machines are working fine. > > # file mailboxes.db > mailboxes.db: Cyrus skiplist DB > > Gabor > On an old server: elo:/var/lib/cyrus# file mailboxes.db mailboxes.db: Apple QuickTime movie (modified) ??? When I use "strings mailboxes.db" the first line says: skiplist file So I think it's a skiplist file. Thanks for your help! It still gives an correct answer on some other databases. Met vriendelijke groet, Paul van der Vlis. -- http://www.vandervlis.nl/ Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Conversion Debian Cyrus 2.1 to 2.2, experiences
On Thu, Aug 07, 2008 at 10:51:21AM +0200, Paul van der Vlis wrote:
> make backups:
> cp -a /var/lib/cyrus /var/lib/cyrus-backup
> cp -a /var/spool/sieve /var/spool/sieve-backup
> cp -a /usr/lib/cyrus/ /usr/lib/cyrus-backup
> cp -a /var/spool/cyrus /var/spool/cyrus-backup
> The last one takes long...
Don't you have regular backups? If you don't, you should better start
doing them... Anyway, you can use rsync to make an initial copy while
the old service is still running and a much quicker update when the old
service is stopped.
> remove packages:
> apt-get remove cyrus21-common cyrus21-admin cyrus21-clients
> libcyrus-imap-perl21
> dpkg --get-selections | grep cyrus
>
> backup config-files:
> mv /etc/imapd.conf /etc/imapd.conf.backup
> mv /etc/cyrus.conf /etc/cyrus.conf.backup
I'd do that _before_ removing the packages...
> install packages:
> apt-get install cyrus-imapd-2.2 cyrus-admin-2.2 cyrus-clients-2.2
> libcyrus-imap-perl22 db4.2-util cyrus-pop3d-2.2
>
> choose to overwrite cyrus.conf and imapd.conf (I wonder why this files
> are still there).
Because you've used "apt-get remove" instead of "apt-get purge". See the
dpkg manual for the description of the difference between the two
operations. Note: "purge" may also remove the spool directory if you've
choosen to do so, so be careful.
> then convert the databases (on one line):
> find /var/lib/cyrus/ -name \*.db -print -exec /usr/bin/db4.2_upgrade {} \;
>
> this was my output:
> --
> /var/lib/cyrus/mailboxes.db
> db_upgrade: /var/lib/cyrus/mailboxes.db: unrecognized file type
> db_upgrade: DB->upgrade: /var/lib/cyrus/mailboxes.db: Invalid argument
> /var/lib/cyrus/tls_sessions.db
> /var/lib/cyrus/deliver.db
> /var/lib/cyrus/db.backup1/mailboxes.db
> db_upgrade: /var/lib/cyrus/db.backup1/mailboxes.db: unrecognized file type
> db_upgrade: DB->upgrade: /var/lib/cyrus/db.backup1/mailboxes.db: Invalid
> argument
> /var/lib/cyrus/db.backup2/mailboxes.db
> db_upgrade: /var/lib/cyrus/db.backup2/mailboxes.db: unrecognized file type
> db_upgrade: DB->upgrade: /var/lib/cyrus/db.backup2/mailboxes.db: Invalid
> argument
> --
>
> So "mailboxes.db" did not work, but the other databases did.
This was my recipe for a 2.1 -> 2.3 (from experimental) migration:
cd /var/lib/cyrus/db
db3_recover
cd /var/lib/cyrus
db4.X_upgrade deliver.db
rm tls*db
cd db
db4.X_checkpoint -1
(replace 'X' with the correct BDB version)
Gabor
--
-
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
-
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Conversion Debian Cyrus 2.1 to 2.2, experiences
On Thu, Aug 14, 2008 at 11:49:43AM +0200, Paul van der Vlis wrote: > > Just a side note: I am pretty sure your mailboxes.db is a skiplist > > database which is AFAIK the default for mailboxes.db in Cyrus IMAP 2.1 > > and 2.2. No conversion is necessary. > > I think that's correct, but I don't know for sure how to check the type. > The conversed machines are working fine. # file mailboxes.db mailboxes.db: Cyrus skiplist DB Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Conversion Debian Cyrus 2.1 to 2.2, experiences
Pascal Gienger schreef:
> Paul van der Vlis <[EMAIL PROTECTED]> wrote:
>
>> then convert the databases (on one line):
>> find /var/lib/cyrus/ -name \*.db -print -exec /usr/bin/db4.2_upgrade
>> {} \;
>
>> db_upgrade: /var/lib/cyrus/mailboxes.db: unrecognized file type
>
>> So "mailboxes.db" did not work, but the other databases did.
>
> Just a side note: I am pretty sure your mailboxes.db is a skiplist
> database which is AFAIK the default for mailboxes.db in Cyrus IMAP 2.1
> and 2.2. No conversion is necessary.
I think that's correct, but I don't know for sure how to check the type.
The conversed machines are working fine.
The file /usr/lib/cyrus/cyrus-db-types.active of the old systems says:
DBENGINE BerkeleyDB3.2
DUPLICATE db3_nosync
MBOX skiplist
SEEN skiplist
SUBS flat
TLS db3_nosync
The file cyrus-db-types.txt is the same.
The new systems are working fine, and this is the cyrus-db-types.active:
ANNOTATION skiplist
DBENGINE BerkeleyDB4.2
DUPLICATE berkeley-nosync
MBOX skiplist
PTS berkeley
QUOTA quotalegacy
SEEN skiplist
SUBS flat
TLS berkeley-nosync
> Do you have any database type declarations in your imapd.conf?
No, I did nothing special, and I did not found anything like that in my
imapd.conf.
Some of the systems did use Cyrus 1.5 before. The conversion was
difficult I can remember. But the file cyrus-db-types.active is the same
as the other old systems.
And I used everywhere Debian-packages.
With regards,
Paul van der Vlis.
--
http://www.vandervlis.nl/
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus vs Dovecot
Mathieu Kretchner <[EMAIL PROTECTED]> wrote: > Ian G Batten a écrit : >> We have mailboxes.db and the metapartitions on ZFS, along with the zone >> iteself. The pool is drawn from space on four 1rpm SAS drives >> internal to the machine: To give (hopefully) comparable comparison: We have our meta files and spool files also on ZFS, with mirrored pools: # zpool status pool: cyrus state: ONLINE scrub: resilver completed with 0 errors on Sun May 25 12:17:46 2008 config: NAME STATE READ WRITE CKSUM cyrus ONLINE 0 0 0 mirror ONLINE 0 0 0 c6t600D0230006B66680C50AB4F92F61000d0 ONLINE 0 0 0 c6t600D0230006C1C4C0C50BE4DFE511B00d0 ONLINE 0 0 0 errors: No known data errors pool: mail state: ONLINE scrub: resilver completed with 0 errors on Sun May 25 01:05:02 2008 config: NAME STATE READ WRITE CKSUM mail ONLINE 0 0 0 mirror ONLINE 0 0 0 c6t600D0230006B66680C50AB0F36ADF100d0 ONLINE 0 0 0 c6t600D0230006C1C4C0C50BE57396E9F00d0 ONLINE 0 0 0 mirror ONLINE 0 0 0 c6t600D0230006B66680C50AB5675F91300d0 ONLINE 0 0 0 c6t600D0230006C1C4C0C50BE16FF1FE200d0 ONLINE 0 0 0 errors: No known data errors "cyrus" is our log pool, "mail" our imap spool pool. IO ist mostly write: # zpool iostat mail 2 capacity operationsbandwidth pool used avail read write read write -- - - - - - - mail2.08T 6.02T226163 1.36M 1.67M mail2.08T 6.02T358 10 1.35M 94.4K mail2.08T 6.02T234599 1.08M 10.0M mail2.08T 6.02T 77 0 425K 3.98K mail2.08T 6.02T 85306 484K 3.39M mail2.08T 6.02T 95 8 405K 75.6K mail2.08T 6.02T107 6 798K 47.8K mail2.08T 6.02T 73232 281K 2.30M mail2.08T 6.02T 77 2 304K 9.95K mail2.08T 6.02T 66469 254K 5.84M mail2.08T 6.02T 83 4 409K 17.9K As with Ian's setup, most read requests are serviced from ARC. We have BOTH data (meta and spool) on this ZFS pool, however we defined an extra ZFS filesystem for metadata to make distinct snapshots. cyrus.header remains on the imap spool partition. Raw Disk I/O is different as ZFS pulls out up to "recordsize" from disk per request (128k by default). Load is 0.47 at the moment, 1355 imapd processes, 10 lmtpd processes (limited by delivering gateway), 34 pop3d processes. The machine is a two-processor Opteron (dualcore) machine, so 4 cores are available. It has 20 GB ram and ARC (zfs) uses: # kstat zfs:0:arcstats:size module: zfs instance: 0 name: arcstatsclass:misc size9308832256 9 GB zfs file cache. Hope this helps you a little bit. Pascal Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Conversion Debian Cyrus 2.1 to 2.2, experiences
Paul van der Vlis <[EMAIL PROTECTED]> wrote:
> then convert the databases (on one line):
> find /var/lib/cyrus/ -name \*.db -print -exec /usr/bin/db4.2_upgrade {} \;
> db_upgrade: /var/lib/cyrus/mailboxes.db: unrecognized file type
> So "mailboxes.db" did not work, but the other databases did.
Just a side note: I am pretty sure your mailboxes.db is a skiplist database
which is AFAIK the default for mailboxes.db in Cyrus IMAP 2.1 and 2.2. No
conversion is necessary.
Do you have any database type declarations in your imapd.conf?
Pascal
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus vs Dovecot
Ian G Batten a écrit : >> the mail, the indices, and the mailboxes.db. Each can be on >> separate storage with optimal price vs performance characteristics >> for the proposed load. > > > We have 48000 mailboxes on behalf of 2000 users, with typically 1700 > imapd processes during the day and ~1000 overnight. There's about 3.4TB > of mail stored. > > We run Cyrus 2.3.9 (12p1 is due for the next time the machine has a > maintenance window) in a Solaris zone (container) on a Sun T2000 with > 16GB of RAM. The load on the machine is typically low: > > > > > > > > We have mailboxes.db and the metapartitions on ZFS, along with the zone > iteself. The pool is drawn from space on four 1rpm SAS drives > internal to the machine: > > > NAME STATE READ WRITE CKSUM > pool1 ONLINE 0 0 0 > mirror ONLINE 0 0 0 > c0t0d0s4 ONLINE 0 0 0 > c0t1d0s4 ONLINE 0 0 0 > mirror ONLINE 0 0 0 > c0t2d0s4 ONLINE 0 0 0 > c0t3d0s4 ONLINE 0 0 0 > > They're fairly busy, mostly with writes (1 second resolution): > >capacity operationsbandwidth > pool used avail read write read write > -- - - - - - - > pool1 39.4G 38.6G 10 77 472K 509K > pool1 39.4G 38.6G 0 65 0 1.09M > pool1 39.4G 38.6G 2521 1.98K 3.03M > pool1 39.4G 38.6G 2170 255K 951K > pool1 39.4G 38.6G 0 37 0 249K > pool1 39.4G 38.6G 0 35 0 310K > pool1 39.4G 38.6G 2 22 16.3K 430K > pool1 39.4G 38.6G 9660 284K 4.65M > pool1 39.4G 38.6G 0118506 296K > pool1 39.4G 38.6G 0 2 0 27.7K > pool1 39.4G 38.6G 4 39 96.0K 990K > pool1 39.4G 38.6G 1 89 1013 997K > pool1 39.4G 38.6G 3775 56.4K 5.06M > pool1 39.4G 38.6G 0160 0 531K > pool1 39.4G 38.6G 0 20 0 118K > pool1 39.4G 38.6G 0 11 0 83.2K > pool1 39.4G 38.6G 0 41 0 595K > pool1 39.4G 38.6G 0624 1013 3.46M > > This indicates that most client-side reads are being serviced from cache > (as you'd expect with 16GB of RAM). We have 21.4GB of meta data on > disk, which we run with ZFS compression to reduce IO bandwidth (at the > expense of CPU utilisation, of which we have plenty spare). The ZFS > compression ratio is about 1.7x: cyrus.cache, in particular, is very > compressible. > > The message store is out on the `archive' QoS of a Pillar Axiom AX500, > so the data's living in the slow regions of SATA drives, that would > otherwise go to waste. We see ~20ms for all reads, because they are > essentially random and have to come up from the spindle of the NFS > server. Writes go to mirrored RAM on the server at take ~2ms. Because > most clients cache content these days, the load on those partitions is > much lower. Ten seconds' of sar output yields: > > 10:47:34 device%busy avque r+w/s blks/s avwait avserv > [...] >nfs7316 0.2 10 84 0.015.6 >nfs8643 0.4 24 205 0.018.5 >nfs87 1 0.0 3 152 0.0 7.2 >nfs96 2 0.0 6 369 0.0 6.9 >nfs1010 0.0 1 35 0.0 5.0 >nfs1020 0.0 0 0 0.0 0.0 > > ian > Thank you, it gives me a good comparison point with a big configuration I saw on dovecot mailing list. Your architecture seems to be well hacked. It's a good start if we had to choose cyrus. Regards begin:vcard fn:Mathieu Kretchner n:Kretchner;Mathieu org:INRIA;Syslog adr;dom:;;2007 route des lucioles - BP93;Sophia Antipolis;;06902 CEDEX email;internet:[EMAIL PROTECTED] tel;work:04 92 38 76 67 x-mozilla-html:FALSE version:2.1 end:vcard Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: [Dovecot] Cyrus vs Dovecot
Pascal Gienger a écrit : Mathieu Kretchner <[EMAIL PROTECTED]> wrote: kbajwa a écrit : Cyrus = 0 Dovecot= 100 I guess you've right but I can't post this answer at Cyrus mailing list. I'm just trying to have my own opinion of imap server and I already have sarcastic answer on the cyrus mailing list ! Stop. What's this? a) crossposing content to the dovecot mailing list b) talking about "sarcastic" answers when users try to help you saying that migrating from an old cyrus release to a new one is easier then migrating to a new system? c) many users here have described their running configuration to help you. d) starting an advocacy war? What are you trying to do? Sorry but your manners on cyrus list have been disrespectful and hurt me... I do not want an "advocacy war" so I'll stop here this discussion and focus on technical aspect. begin:vcard fn:Mathieu Kretchner n:Kretchner;Mathieu org:INRIA;Syslog adr;dom:;;2007 route des lucioles - BP93;Sophia Antipolis;;06902 CEDEX email;internet:[EMAIL PROTECTED] tel;work:04 92 38 76 67 x-mozilla-html:FALSE version:2.1 end:vcard Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
