Re: Cyrus IMAPd 2.3.10 Released
>> idled_shutdown_check: 0 > > Are you applying third-party patches? 'idled_shutdown_check' isn't > a valid option in the stock distro. No: the config dates back to the dawn of time, but the installation today is a straight download and compile. ian 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 IMAPd 2.3.10 Released
On 25 Oct 07, at 1248, Ken Murchison wrote:
> What does imapd.conf look like?
See second mail.
>
> Does the output of 'ctl_mboxlist -d' look reasonable?
Yes.
ctl_mboxlist -d > /tmp/foo
ctl_mboxlist -u < /tmp/foo
ctl_mboxlist -d | diff -c - /tmp/foo
comes up clean, too.
>
> Does 'mbexamine user.igb' look reasonable?
I don't know what reasonable looks like, I get this. At first blush
the Index Header info looks the same as running the same command on
the Solaris replica, which seems much healthier.
I can flip between 2.3.7 and 2.3.10 (2.3.7 works, 2.3.10 doesn't) so
I'm fairly certain there's nothing overly toxic about the mailboxes.
ian
[EMAIL PROTECTED] cyrus-imapd-2.3.10]# /usr/cyrus/bin/mbexamine user.igb
Examining user.igb...
Mailbox Header Info:
Path to mailbox: /var/imap/messages/user/igb
Mailbox ACL: igb lrswipcda
Unique ID: 3ab028613d99c597
User Flags: Junk NonJunk $MDNSent $NotJunk $Junk JunkRecorded
$Forwarded $Label1 $Label2 $Label3 $Label4 $Label5
Index Header Info:
Generation Number: -1040070997
Format: NORMAL
Minor Version: 10
Header Size: 96 bytes Record Size: 88 bytes
Number of Messages: 2326 Mailbox Size: 57125014 bytes
Last Append Date: (1193308980) Thu Oct 25 11:43:00 2007
UIDValidity: 1033487767 Last UID: 17662
Deleted: 0 Answered: 464 Flagged: 0
Mailbox Options: POP3_NEW_UIDL
Last POP3 Login: (0) Thu Jan 1 01:00:00 1970
Highest Mod Sequence: 1
Message Info:
01> UID:8642 INT_DATE:1151761881 SENTDATE:1151751600 SIZE:
32648
> HDRSIZE:2855 LASTUPD :1193311454 SYSFLAGS: LINES:
535
> CACHEVER:2 GUID:
MODSEQ:1
> USERFLAGS: 0008
Envel>{314}("Sat, 01 Jul 2006 08:50:25 -0500 (CDT)" "Returned mail:
User unknown" ((NIL NIL "postoffice" "batten.eu.org")) ((NIL NIL
"postoffice" "batten.eu.org")) ((NIL NIL "postoffice"
"batten.eu.org")) (("Mail Delivery Subsystem" NIL "MAILER-DAEMON"
"batten.eu.org")) NIL NIL NIL "<[EMAIL PROTECTED]>")
and then a lot more of the same.
>
>
> Ian G Batten wrote:
>> I've just compiled 2.3.10 on batten.eu.org (my private x86
>> servers) and although it looks OK on the Solaris 10 system, it's
>> in deep trouble on the elderly Linux machine. Both are upgrades
>> from 2.3.7, the Solaris box is a replication target, the Linux box
>> is a replication master that handles deliver and reading. The
>> intent is to swap them over, and that intent might come sooner
>> than I planned.
>> LSUB produces expected output, LIST doesn't (to put it mildly) and
>> examine/select can't select anything. strace on the running imapd
>> shows it's doing roughly sensible things: finding the correct
>> partition and metapartition from the mailbox database, opening the
>> metadata files correctly, but then it says NO. I've reconstructed
>> the mailbox, dumped and reloaded (ctl_mboxlist -d // ctl_mboxlist -
>> u) the mailboxes file and run reconstruct -G ``in case it makes
>> any odds''. No joy. And nothing useful in the logs, either...
>> read(0, ". examine INBOX\r\n", 4096)= 17
>> fcntl64(6, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0,
>> len=0}) = 0
>> fstat64(6, {st_mode=S_IFREG|0600, st_size=3520, ...}) = 0
>> stat64("/var/imap/mailboxes.db", {st_mode=S_IFREG|0600,
>> st_size=3520, ...}) = 0
>> fcntl64(6, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0,
>> len=0}) = 0
>> fcntl64(6, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0,
>> len=0}) = 0
>> fstat64(6, {st_mode=S_IFREG|0600, st_size=3520, ...}) = 0
>> stat64("/var/imap/mailboxes.db", {st_mode=S_IFREG|0600,
>> st_size=3520, ...}) = 0
>> fcntl64(6, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0,
>> len=0}) = 0
>> open("/var/imap/metadata/user/igb/cyrus.header", O_RDWR) = 11
>> fstat64(11, {st_mode=S_IFREG|0600, st_size=250, ...}) = 0
>> mmap2(NULL, 250, PROT_READ, MAP_SHARED, 11, 0) = 0x40ee1000
>> open("/var/imap/metadata/user/igb/cyrus.index", O_RDWR) = 12
>> fstat64(12, {st_mode=S_IFREG|0600, st_size=204784, ...}) = 0
>> mmap2(NULL, 212992, PROT_READ, MAP_SHARED, 12, 0) = 0x40ef3000
>> open("/var/imap/metadata/user/igb/cyrus.cache", O_RDWR) = 13
>> fstat64(13, {st_mode=S_IFREG|0600, st_size=2753804, ...}) = 0
>> mmap2(NULL, 2768896, PROT_READ, MAP_SHARED, 13, 0) = 0x40f27000
>> fstat64(12, {st_mode=S_IFREG|0600, st_s
Re: Cyrus IMAPd 2.3.10 Released
On the Linux box, all fresh compilations aside from the sasl 2.1.15 binaries: imapd 2.3.7 + sasl 2.1.15: works imapd 2.3.7 + sasl 2.1.22: works imapd 2.3.9 + sasl 2.1.15: not tried imapd 2.3.9 + sasl 2.1.22: works imapd 2.3.10 + sasl 2.1.15: fails (cannot examine mailboxes, then coredumps prior to calling accept for second connection) imapd 2.3.10 + sasl 2.1.22: fails (SIGSEGV immediately after authentication) I've compiled 2.3.10 both -O2 and with optimisation turned off, to no effect. This is God's way of telling me to move onto a newer OS platform, I think. I'll stick at 2.3.9 + 2.1.22, since it appears to work and it's obviously a better proposition that the 2.3.7+2.1.15 I was running previously. It seems clear the problem has come in with 2.3.10, and as the platform is horrid I'll stop investigating further. In the mean time, is there any way I can run replication from a master running 2.3.9 into a replica running 2.3.10? Or should I back the replica out to 2.3.9 as well? ian 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 IMAPd 2.3.10 Released
On 25 Oct 07, at 1248, Ken Murchison wrote:
> What does imapd.conf look like?
>
> Does the output of 'ctl_mboxlist -d' look reasonable?
>
> Does 'mbexamine user.igb' look reasonable?
OK, there's a steady stream of imapd processes being forked and then
dying on SIGSEGV. I've caught one in the act. That looks SASL-y:
I'll check the versions and upgrade.
ian
[pid 29202] <... select resumed> ) = 1 (in [0], left {1799,
69})
[pid 29202] time(NULL) = 1193314959
[pid 29202] time(NULL) = 1193314959
[pid 29202] select(1, [0], NULL, NULL, {1800, 0}) = 1 (in [0], left
{1800, 0})
[pid 29202] time(NULL) = 1193314959
[pid 29202] time(NULL) = 1193314959
[pid 29202] read(0, "1 AUTHENTICATE CRAM-MD5\r\n", 4096) = 25
[pid 29202] time(NULL) = 1193314959
[pid 29202] open("/dev/random", O_RDONLY) = 11
[pid 29202] read(11, "\257gK\352F\213", 6) = 6
[pid 29202] close(11) = 0
[pid 29202] gettimeofday({1193314959, 565907}, NULL) = 0
[pid 29202] times({tms_utime=2, tms_stime=2, tms_cutime=0,
tms_cstime=0}) = 1055799906
[pid 29202] write(1, "+ PDU0NjI4NTkyMC4yMTMyNjk0QG9mZn"..., 60) = 60
[pid 29202] time(NULL) = 1193314959
[pid 29202] select(1, [0], NULL, NULL, {1800, 0}) = 1 (in [0], left
{1799, 78})
[pid 29202] time(NULL) = 1193314959
[pid 29202] time(NULL) = 1193314959
[pid 29202] read(0, "aWdiIDVlNjMzNTk2MWY5OWFlZDExYmFh"..., 4096) = 50
[pid 29202] open("/etc/sasldb2", O_RDONLY) = 11
[pid 29202] fcntl64(11, F_SETFD, FD_CLOEXEC) = 0
[pid 29202] fstat64(11, {st_mode=S_IFREG|0660, st_size=12288, ...}) = 0
[pid 29202] lseek(11, 0, SEEK_SET) = 0
[pid 29202] read(11, "\0\0\0\0\0\0\0\0\0\0\0\0a\25\6\0\7\0\0\0\0\20\0
\0\0\10"..., 256) = 256
[pid 29202] close(11) = 0
[pid 29202] stat64("/var/tmp", {st_mode=S_IFDIR|S_ISVTX|0777,
st_size=104, ...}) = 0
[pid 29202] brk(0x817a000) = 0x817a000
[pid 29202] mmap2(NULL, 274432, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_ANONYMOUS, -1, 0) = 0x40ef3000
[pid 29202] open("/etc/sasldb2", O_RDONLY) = 11
[pid 29202] fcntl64(11, F_SETFD, FD_CLOEXEC) = 0
[pid 29202] fstat64(11, {st_mode=S_IFREG|0660, st_size=12288, ...}) = 0
[pid 29202] lseek(11, 0, SEEK_SET) = 0
[pid 29202] read(11, "\0\0\0\0\0\0\0\0\0\0\0\0a\25\6\0\7\0\0\0\0\20\0
\0\0\10"..., 4096) = 4096
[pid 29202] brk(0x817c000) = 0x817c000
[pid 29202] lseek(11, 4096, SEEK_SET) = 4096
[pid 29202] read(11, "\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0.\0\202
\t\0\2\331"..., 4096) = 4096
[pid 29202] close(11) = 0
[pid 29202] munmap(0x40ef3000, 274432) = 0
[pid 29202] open("/etc/sasldb2", O_RDONLY) = 11
[pid 29202] fcntl64(11, F_SETFD, FD_CLOEXEC) = 0
[pid 29202] fstat64(11, {st_mode=S_IFREG|0660, st_size=12288, ...}) = 0
[pid 29202] lseek(11, 0, SEEK_SET) = 0
[pid 29202] read(11, "\0\0\0\0\0\0\0\0\0\0\0\0a\25\6\0\7\0\0\0\0\20\0
\0\0\10"..., 256) = 256
[pid 29202] close(11) = 0
[pid 29202] stat64("/var/tmp", {st_mode=S_IFDIR|S_ISVTX|0777,
st_size=104, ...}) = 0
[pid 29202] mmap2(NULL, 274432, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_ANONYMOUS, -1, 0) = 0x40ef3000
[pid 29202] open("/etc/sasldb2", O_RDONLY) = 11
[pid 29202] fcntl64(11, F_SETFD, FD_CLOEXEC) = 0
[pid 29202] fstat64(11, {st_mode=S_IFREG|0660, st_size=12288, ...}) = 0
[pid 29202] lseek(11, 0, SEEK_SET) = 0
[pid 29202] read(11, "\0\0\0\0\0\0\0\0\0\0\0\0a\25\6\0\7\0\0\0\0\20\0
\0\0\10"..., 4096) = 4096
[pid 29202] lseek(11, 4096, SEEK_SET) = 4096
[pid 29202] read(11, "\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0.\0\202
\t\0\2\331"..., 4096) = 4096
[pid 29202] close(11) = 0
[pid 29202] munmap(0x40ef3000, 274432) = 0
[pid 29202] socket(PF_UNIX, SOCK_STREAM, 0) = 11
[pid 29202] connect(11, {sin_family=AF_UNIX,
path="
/var/run/.nscd_socket"}, 110) = -1 ENOENT (No
such file or directory)
[pid 29202] close(11) = 0
[pid 29202] open("/etc/passwd", O_RDONLY) = 11
[pid 29202] fcntl64(11, F_GETFD)= 0
[pid 29202] fcntl64(11, F_SETFD, FD_CLOEXEC) = 0
[pid 29202] fstat64(11, {st_mode=S_IFREG|0644, st_size=1710, ...}) = 0
[pid 29202] mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_ANONYMOUS, -1, 0) = 0x40ee1000
[pid 29202] read(11, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) =
1710
[pid 29202] close(11) = 0
[pid 29202] munmap(0x40ee1000, 4096)= 0
[pid 29202] open("/etc/group", O_RDONLY) = 11
[pid 29202] fcntl64(11, F_GETFD)= 0
[pid 29202] fcntl64(11, F_SETFD, FD_CLOEXEC) = 0
[pid 29202] fstat64(11, {st_mode=S_IFREG|0644, st_size=725, ...}) = 0
[pid 29202] mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_ANONYMOUS, -1, 0) = 0x40ee1000
[pid 29202] _llseek(11, 0, [0], SEEK_CUR) = 0
[pid 29202] read(11, "root:x:0:root\nbin:x:1:root,bin,d"...
Re: Cyrus IMAPd 2.3.10 Released
On 25 Oct 07, at 1501, Ken Murchison wrote: > Ian G Batten wrote: >> On the Linux box, all fresh compilations aside from the sasl >> 2.1.15 binaries: >> imapd 2.3.7 + sasl 2.1.15: works >> imapd 2.3.7 + sasl 2.1.22: works >> imapd 2.3.9 + sasl 2.1.15: not tried >> imapd 2.3.9 + sasl 2.1.22: works >> imapd 2.3.10 + sasl 2.1.15: fails (cannot examine mailboxes, then >> coredumps prior to calling accept for second connection) >> imapd 2.3.10 + sasl 2.1.22: fails (SIGSEGV immediately after >> authentication) >> I've compiled 2.3.10 both -O2 and with optimisation turned off, to >> no effect. >> This is God's way of telling me to move onto a newer OS platform, >> I think. I'll stick at 2.3.9 + 2.1.22, since it appears to work >> and it's obviously a better proposition that the 2.3.7+2.1.15 I >> was running previously. It seems clear the problem has come in >> with 2.3.10, and as the platform is horrid I'll stop investigating >> further. >> In the mean time, is there any way I can run replication from a >> master running 2.3.9 into a replica running 2.3.10? Or should I >> back the replica out to 2.3.9 as well? > > Back the replica down to 2.3.9. Done, and replication is re-established. I'll try to replicate the problem without users breathing down my neck (ftel.co.uk has 1000 users, batten.eu.org has six, but they're my parents, my wife and my children), but I suspect it's some horrid combination of elderly libraries misbehaving. 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
64-bit Cyrus?
To what extent has Cyrus been tested with 64 bit builds? One of my
users has managed to create a mailbox with a >2.0G cyrus.cache, which
of course can't be mmap'd. The mere act of finding out how many
files there are in there is itself a problem: I've got
perl -e 'use IO::Dir; my $d=new IO::Dir("."); while ($f=$d->read())
{ print $f, "\n"; }' | wc -l
running to read the directory without stat-ing anything, but that's
struggling. It's on NAS storage with hashed directories, so it
didn't slow down as it got bigger: the problem probably didn't arise
until the cache directory got too big!
ian
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
ctl_mboxlist -v not quite doing the right thing
user.markr has, through a sequence of events, ended up with data on both partition8 (/var/imap/partition-8) and default (/var/imap/ partition-1). All his mailboxes have been consolidated into default, but there are still copies in partition-8. So I think ctl_mboxlist -v should report that partition-8 is there but has no DB entry. But it says: 'user.markr' has a directory on partition 'default' but no DB entry Which is bogus, because: mailhost-new# ctl_mboxlist -d | grep user.markr user.markr 0 default markr lrswipcda mailadm lrs 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: ctl_mboxlist -v not quite doing the right thing
On 31 Oct 07, at 1527, Ken Murchison wrote: > Ian G Batten wrote: >> user.markr has, through a sequence of events, ended up with data >> on both partition8 (/var/imap/partition-8) and default (/var/ >> imap/ partition-1). All his mailboxes have been consolidated >> into default, but there are still copies in partition-8. >> So I think ctl_mboxlist -v should report that partition-8 is >> there but has no DB entry. >> But it says: >> 'user.markr' has a directory on partition 'default' but no DB entry >> Which is bogus, because: >> mailhost-new# ctl_mboxlist -d | grep user.markr >> user.markr 0 default markr lrswipcda mailadm lrs > > Have you done any debugging or tracing to see why it gets reported > improperly? Just starting in on it now. I've cleaned up all the obvious inconsistencies (my main job today) but the output is still a bit unclear. I suspect that it's getting confused if the contents of the meta-partitions and the contents of the partitions are differently inconsistent. ctl_mboxlist -v doesn't indicate in its output if the un-referenced directory is meta-data or data. ian 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 IMAPd 2.3.10 Released
>
For confirmation, the problem I had a couple of weeks ago with Cyrus
2.3.10 on a Redhat 8 derived system is fixed by forcing
HAVE_GETGROUPLIST to be undefined (I did it by deleting getgrouplist
from the list of functions checked for in configure --- there's
presumably a cleaner way).
Begin forwarded message:
> From: Ian G Batten <[EMAIL PROTECTED]>
> Date: Thu 25 Oct 07 12:30:57 BDT
> To: Ken Murchison <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], Cyrus Mailing List [EMAIL PROTECTED]>
> Subject: Re: Cyrus IMAPd 2.3.10 Released
>
>
>
> I've just compiled 2.3.10 on batten.eu.org (my private x86 servers)
> and although it looks OK on the Solaris 10 system, it's in deep
> trouble on the elderly Linux machine. Both are upgrades from 2.3.7,
> the Solaris box is a replication target, the Linux box is a
> replication master that handles deliver and reading. The intent is
> to swap them over, and that intent might come sooner than I planned.
>
> LSUB produces expected output, LIST doesn't (to put it mildly) and
> examine/select can't select anything. strace on the running imapd
> shows it's doing roughly sensible things: finding the correct
> partition and metapartition from the mailbox database, opening the
> metadata files correctly, but then it says NO. I've reconstructed
> the mailbox, dumped and reloaded (ctl_mboxlist -d // ctl_mboxlist -u)
> the mailboxes file and run reconstruct -G ``in case it makes any
> odds''. No joy. And nothing useful in the logs, either...
>
> read(0, ". examine INBOX\r\n", 4096)= 17
> fcntl64(6, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0})
> = 0
> fstat64(6, {st_mode=S_IFREG|0600, st_size=3520, ...}) = 0
> stat64("/var/imap/mailboxes.db", {st_mode=S_IFREG|0600,
> st_size=3520, ...}) = 0
> fcntl64(6, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0})
> = 0
> fcntl64(6, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0})
> = 0
> fstat64(6, {st_mode=S_IFREG|0600, st_size=3520, ...}) = 0
> stat64("/var/imap/mailboxes.db", {st_mode=S_IFREG|0600,
> st_size=3520, ...}) = 0
> fcntl64(6, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0})
> = 0
> open("/var/imap/metadata/user/igb/cyrus.header", O_RDWR) = 11
> fstat64(11, {st_mode=S_IFREG|0600, st_size=250, ...}) = 0
> mmap2(NULL, 250, PROT_READ, MAP_SHARED, 11, 0) = 0x40ee1000
> open("/var/imap/metadata/user/igb/cyrus.index", O_RDWR) = 12
> fstat64(12, {st_mode=S_IFREG|0600, st_size=204784, ...}) = 0
> mmap2(NULL, 212992, PROT_READ, MAP_SHARED, 12, 0) = 0x40ef3000
> open("/var/imap/metadata/user/igb/cyrus.cache", O_RDWR) = 13
> fstat64(13, {st_mode=S_IFREG|0600, st_size=2753804, ...}) = 0
> mmap2(NULL, 2768896, PROT_READ, MAP_SHARED, 13, 0) = 0x40f27000
> fstat64(12, {st_mode=S_IFREG|0600, st_size=204784, ...}) = 0
> close(11) = 0
> munmap(0x40ee1000, 250) = 0
> close(12) = 0
> munmap(0x40ef3000, 212992) = 0
> close(13) = 0
> munmap(0x40f27000, 2768896) = 0
> write(1, ". NO Mailbox does not exist\r\n", 29) = 29
>
>
>
>
> * OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS AUTH=CRAM-MD5
> AUTH=DIGEST-MD5 AUTH=LOGIN AUTH=PLAIN AUTH=OTP SASL-IR]
> offsite.batten.eu.org Cyrus IMAP4 v2.3.10 server ready
> . login igb X
> . OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS AUTH=CRAM-MD5
> AUTH=DIGEST-MD5 AUTH=LOGIN AUTH=PLAIN AUTH=OTP SASL-IR ACL
> RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS
> NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT
> SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE
> CATENATE CONDSTORE IDLE URLAUTH] User logged in
> . list "" *
> * LIST (\HasNoChildren) "." "INBOX"
> . OK Completed (0.020 secs 2 calls)
> . lsub "" *
> * LSUB (\HasChildren) "." "INBOX"
> * LSUB () "." "INBOX.2003"
> * LSUB () "." "INBOX.2004"
> * LSUB () "." "INBOX.2005"
> * LSUB () "." "INBOX.2006"
> * LSUB () "." "INBOX.Drafts"
> * LSUB () "." "INBOX.Holidays"
> * LSUB () "." "INBOX.Junk"
> * LSUB () "." "INBOX.Sent"
> * LSUB () "." "INBOX.Trash"
> * LSUB () "." "INBOX.clamav"
> * LSUB () "." "INBOX.macos"
> * LSUB () "." "INBOX.pre-2003"
> * LSUB () "." "INBOX.twonky"
> * LSUB () "." "INBOX.xtension"
> . OK Completed (0.030 secs 16 calls)
> . examine INBOX
> . NO Mailbox does not exist
>
>
>
>
>
>
>
> 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
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
Renaming heirarchies from the bottom
A common scenario when we are moving users between partitions is to
want to move their archived mail first, because there's less risk of
disrupting them, and then their top-level mailbox last.
So we want to do:
rename --partition new-partition user.name.box user.name.box
and then later
rename --partition new-partition user.name user.name
The second step gives the error message ``mailbox already exists'',
but nonetheless performs the move. I presume the error comes after
user.name has been moved, when it then attempts to recurse down into
the subdirs that have already been moved.
Is this safe to do?
ian
mailhost-new# cyradm --user=mailadm localhost
Password:
localhost> cm user.testcase
localhost> cm user.testcase.subdir
localhost> info user.testcase.subdir
{user.testcase.subdir}:
condstore: false
lastpop:
lastupdate: 12-Nov-2007 11:32:19 +
partition: partition9
size: 0
localhost> info user.testcase
{user.testcase}:
condstore: false
lastpop:
lastupdate: 12-Nov-2007 11:32:13 +
partition: partition9
size: 0
localhost> rename --partition partition8 user.testcase.subdir
user.testcase.subdir
localhost> info user.testcase.subdir
{user.testcase.subdir}:
condstore: false
lastpop:
lastupdate: 12-Nov-2007 11:33:14 +
partition: partition8
size: 0
localhost> info user.testcase
{user.testcase}:
condstore: false
lastpop:
lastupdate: 12-Nov-2007 11:32:13 +
partition: partition9
size: 0
localhost> rename --partition partition8 user.testcase user.testcase
renamemailbox: Mailbox already exists
localhost> info user.testcase
{user.testcase}:
condstore: false
lastpop:
lastupdate: 12-Nov-2007 11:34:19 +
partition: partition8
size: 0
localhost>
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
Calendars && Cyrus
On 13 Nov 07, at 0724, Rudy Gevaert wrote: > If we could ever get a decent calendar system that works together with > Cyrus or other software many people would be happy. We run Cyrus for mail, Oracle Collaboration Suite ($$, but not Exchange-$$) for calendaring. The Outlook plugin that allows Outlook to believe it has a genuine Exchange instance under it plays nice with Cyrus (its target is Oracle's IMAP server that's bundled with OCS).The OCS plugin for Exchange is smart enough to use CRAM-MD5 (or is it DIGEST-MD5) authentication if available, and TLS if available. ian 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: OT: Re: How many people to admin a Cyrus system?
On 13 Nov 07, at 0812, Scott M. Likens wrote: > No it's not > as seamless as Exchange, but it works just fine and it's an open > standard. However, people don't want calendaring, they want Outlook. Offer a solution which doesn't allow Outlook to work ``like it should'' and you risk learning more about Exchange than you wanted to. I guess Outlook might start to talk CalDAV, but I personally doubt it: it would undercut Microsoft's Exchange business which is very lucrative for them. OCS has an Outlook plugin I suspect for this very reason: it avoids management refusing to accept a solution which doesn't do what they see as the right thing: the rest of us use the OCS Linux/ Solaris/Windows/OSX native clients or the web front end, all of which work very nicely. Your management won't regard CalDAV as a standard, they think Outlook is a standard. And ``not as seamless'' is a key admission. ian 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
Timed Actions in Sieve
We've been having a chat about how useful it would be to have timed actions in sieve: so that a vacation message could be set up for a duration which would automatically revert, so that a forwarding could be set up for the duration of a short-term project, etc, etc. The naive way is to add support to the sieve interface of choice (the squirrelmail plugin in our case) to handle deferred actions, but I can think of all sorts of security problems with that. Another would be a means to auto-generate regexps to match on Date: headers, but that's really tacky. The full solution would be to have the current time available in sieve scripts, to then match on. Has anyone else thought about this area? ian 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: OT: Re: How many people to admin a Cyrus system?
On 13 Nov 07, at 1335, Adam Tauno Williams wrote: >> 3. Can't handle high load very well, in fact it handles load >> horribly. > > I have a friend who works at a small shop who reports exactly the same > issue with Zimbra, s..ll...ooo..... > >> 3) ClamAV. Do note how much email I said we dealt with a minute. We >> didn't get a great deal of email. Maybe 2000 email a day? Not >> overly >> much. However as the ClamAV database would grow, if you restarted >> ClamAV or Zimbra eventually it would take too long for ClamAV to >> start >> and would not listen on the port assigned and would make mail fail to >> deliver. (Ouch huh?) > > In defense of CLAMAV I can say that we run it on our SMTP server > (not on > the IMAP or groupware server which seems like a bad idea). It works > well and is pretty stable. If your CLAMAV was causing you this > problem > then Zimbra must have boloxed the setup or you just had a bad version. Clamav-milter works very well for sendmail shops, without any amavis involvement at all. The slow startup bug is an artefact of one particular release: it now comes up in about 15 seconds. Once it's running it's perfectly rapid enough to cope with our complete internal load.clamd-milter can do the parsing of archives, breaking up of MIME etc at least as well as amavisd. If you don't have an equivalent to clamav-filter for your MTA of choice, then you need to make sure that you start clamd, and then pass the material to be scanned with clamdscan (note the d). clamd will need to be running as a user that can read the temporary files, because the best way to use clamd is to pass filenames over the AF_UNIX domain socket. We in fact run clamav-milter with its built-in clamd support, for reasons I can't offhand remember. So we fire up clamd, then clamav- milter, then clamav-milter passes temporary files to clamd. If you have to use amavisd, make sure you tell it to use clamdscan rather than clamscan. The latter does indeed take 10 seconds to fire up. clamd likes large pages, Solaris fans. Our milter startup script: there is some local stuff in there. #!/bin/sh case "$1" in start) mv /var/clamav/clamd.log /var/clamav/clamd.log.old LD_PRELOAD=mpss.so.1 MPSSHEAP=4M MPSSSTACK=64K export LD_PRELOAD MPSSHEAP MPSSSTACK newtask -p clam /usr/local/sbin/clamd attempt=1 sleep=5 while [ $attempt -lt 5 ]; do if /usr/local/bin/clamdscan /etc/termcap; then break else attempt=`expr $attempt + 1` sleep=`expr $sleep + 5` echo sleeping for $sleep seconds, attempt $attempt sleep $sleep fi done # [EMAIL PROTECTED] \ # --postmaster-only \ newtask -p milter /usr/local/sbin/clamav-milter \ --dont-blacklist=`/usr/local/bin/fujitsuhosts` \ --noreject \ --dont-wait \ --local \ --outgoing \ --quiet \ --external \ --pidfile=/var/clamav/milter.pid \ --whitelist-file=/etc/mail/clamav-whitelist \ inet:2010 newtask -p spam /usr/perl5/bin/spamd -s local6 -u spamd -x -d --pidfile=/var/run/spamd.pid su spamd << \ZZZ newtask -p milter /usr/local/sbin/spamassassin_milter -p inet: 2002 & ZZZ newtask -p milter /usr/local/sbin/mailarchive -u archive -p inet:4001 newtask -p milter /usr/local/sbin/spamtrap -u spamtrap -p inet: 4000 ;; stop) for i in /var/clamav/milter.pid /var/run/spamd.pid; do test -f $i && kill `cat $i` done pkill -u spamd pkill -u clamav pkill -u archive pkill -u spamtrap ;; esac 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: OT: Re: How many people to admin a Cyrus system?
On 13 Nov 07, at 1505, David Chait wrote: > One key piece of functionality that seems to be missing from every OSS > solution mentioned thus far is mobile device push support > (Activesync), > this is not to be underestimated as it is for us, a key reason why we > are ultimately being forced to adopt Exchange en-mass and abandon our > current Cyrus infrastructure. There's purported to be a solution from Concilliant. http:// www.consilient.com/media/2005/c2-for-cyrus.html ian 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
Setting the location of proc independent of configdir
I was interested to see someone suggesting putting proc into tmpfs. That's slightly painful if /var/imap is in ZFS: the order in which mounts take place means you can't just put /var/imap/proc tmpfs into / etc/vfstab if /var/imap is coming in through ZFS. A glance at the source code says that proc is hardwired to be configdir/proc. Would it be worth considering making procdir: a configuration option, so that it can easily be put somewhere which isn't under configdir:? Indeed, for a lot of people, just shoving it in /tmp/cyrusproc would be a good option. ian 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: Setting the location of proc independent of configdir
On 15 Nov 07, at 1045, Simon Matter wrote: >> I was interested to see someone suggesting putting proc into tmpfs. >> That's slightly painful if /var/imap is in ZFS: the order in which >> mounts take place means you can't just put /var/imap/proc tmpfs >> into / >> etc/vfstab if /var/imap is coming in through ZFS. A glance at the >> source code says that proc is hardwired to be configdir/proc. Would >> it be worth considering making procdir: a configuration option, so >> that it can easily be put somewhere which isn't under configdir:? >> Indeed, for a lot of people, just shoving it in /tmp/cyrusproc would >> be a good option. > > I didn't test but doesn't a symlink work? Yes, it does (just tried it on a development system). ian 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: LARGE single-system Cyrus installs?
On 15 Nov 07, at 1504, Michael Bacon wrote: Interesting thought. We haven't gone to ZFS yet, although I like the idea a lot. My hunch is it's an enormous win for the mailbox partitions, but perhaps it's not a good thing for the meta partition. I'll have to let someone else who knows more about ZFS and write speeds vs. read speeds chime in here. We're finding it a real win for the meta-partition. We're handing ~1000 users on a 2-way stripe by two-way mirror on the internal disks in a T2000 for the meta-data, with the message data coming in over NFS.We do see a few spikes of write operations (this is one instance from zpool isotat -v 1): capacity operationsbandwidth pool used avail read write read write - - - - - - pool1 52.1G 25.9G 4657 3.96K 3.71M mirror 26.0G 13.0G 4354 3.96K 1.42M c0t0d0s4 - - 0135 0 1.42M c0t1d0s4 - - 0126 63.4K 1.42M mirror 26.0G 13.0G 0302 0 2.29M c0t2d0s4 - - 0112 0 2.29M c0t3d0s4 - - 0109 0 2.29M - - - - - - but it's showing no signs at all of being IO bound on the metadata. The spikes are really just spikes for a second: the typical level is about 10 ops / disk / sec. ian 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: LARGE single-system Cyrus installs?
On 17 Nov 07, at 0909, Rob Mueller wrote: This shouldn't really be a problem. Yes the whole file is locked for the duration of the write, however there should be only 1 fsync per "transaction", which is what would introduce any latency. The actual writes to the db file itself should be basically instant as the OS should just cache them. One thing that's worth noting for ZFS-ites is that on ZFS, you can have multiple writer threads in a file simultaneously, which UFS can only do for directio under certain conditions I can't recall. That's a win for overlapping transactions into a file-based database. We're not hitting mailboxes.db remotely rapidly enough for this to be an issue, but I can imagine it being so for big shops. In production releases of ZFS fsync() essentially triggers sync() (fixed in Solaris Next). So if you anticipate a lot of writes (and hence fsync()s) to mailboxes.db then you don't want mailboxes.db in the same ZFS filesystem as things with lots of un-sync'd writes going on.I've broken up /var/imap for ease of taking and rolling back snapshots, but it has the handy side-effect of isolating delivery.db and mailboxes.db from all the metadata partitions. In my darker moments, by the way, I'm tempted to put deliver.db into tmpfs. For planned reboot I could copy it somewhere stable, and I could periodically dump it out to disk. But if I lost it, the consequences aren't serious, and it's most of the write load through that particular filesystem. ian mailhost-new# zfs list -t filesystem | grep imap; df /var/imap/proc pool1/mailhost-space/imap 1.34G 24.6G 346M /var/imap pool1/mailhost-space/imap-seen 105M 24.6G 22.4M /var/imap/ user pool1/mailhost-space/meta-partition-1 2.48G 24.6G 972M /var/imap/ meta-partition-1 pool1/mailhost-space/meta-partition-2 12.4G 24.6G 4.82G /var/imap/ meta-partition-2 pool1/mailhost-space/meta-partition-3 4.86G 24.6G 1.60G /var/imap/ meta-partition-3 pool1/mailhost-space/meta-partition-7 5.60G 24.6G 1.41G /var/imap/ meta-partition-7 pool1/mailhost-space/meta-partition-8 14.0G 24.6G 5.39G /var/imap/ meta-partition-8 pool1/mailhost-space/meta-partition-9 1.08G 24.6G 415M /var/imap/ meta-partition-9 pool1/mailhost-space/sieve 5.26M 24.6G 1.62M /var/imap/ sieve /var/imap/proc (swap ): 514496 blocks 2356285 files mailhost-new# Still, you have a point that mailboxes.db is a global point of contention, and it is access a lot, so blocking all processes on it for a write could be an issue. Which makes me even more glad that we've split up our servers into lots of small cyrus instances, even less points of contention... Rob 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 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: Vacation
On 19 Nov 07, at 2139, Scott Adkins wrote: > This does bring up an important point... we had to disable duplicate > suppression on our server because it was just causing too much > contention. > When every single mail message being delivered has to check against > the > database, it is a problem. The checking's not the problem, as the 99.9% case is an update. In other words, if the rate of duplicates were high, you could lock it for reading, check the message was unique, and then if that gave a positive response lock it for update and perform the update. Yes, there's a race condition, but it's small and benign. However, in the real world this gains you nothing, because the rate of duplicates is vanishingly small. You buy complexity and a race condition for degraded performance (the lock upgrade is expensive). There are other possible solutions. One would be a per-user, or per- user-initial-letter, duplicate database. Another would be to not bother syncing the database (I think this is what berkeley-nosync does, but that doesn't help skiplist users). ian 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
2.3.10 Upgrade Question
In a NON-replicated setup, do the changes to the GUID have an impact? Can I just put 2.3.10 on with a quick restart of the mailsystem, or is there More To It? I have 1.7TB of mail, about 40K mailboxes, about 10 million pieces of mail. So I don't want to do an upgrade which will kick off some huge rebuild-fest without planning. ian 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: 2.3.10 Upgrade Question
On 20 Nov 07, at 1146, Bron Gondwana wrote: > > The index files are pretty small, and they rebuild fast :) They > get streamed > into new copies every single expunge anyway. What's involved in the rebuild? I have users with tens of thousands of messages in a single mailbox, so delaying that open while it reads and indexes a few gigs is bad. Does the rebuild need to open every message? Read headers? Bodies? What? ian > > Also, it will only upgrade each index as it is opened for the first > time, so > the load isn't one giant hit. > > Bron. > -- > Bron Gondwana > [EMAIL PROTECTED] > 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: LARGE single-system Cyrus installs?
On 20 Nov 07, at 1332, Michael R. Gettes wrote: > I am wondering about the use of fsync() on journal'd file systems > as described below. Shouldn't there be much less use of (or very > little use) of fsync() on these types of systems? Let the journal > layer due its job and not force it within cyrus? This would likely > save a lot of system overhead. fsync() forces the data to be queued to the disk. A journaling filesystem won't usually make any difference, because no one wants to keep an intent log of every 1 byte write, or the 100 overwrites of the same block. If you want every write() to go to disk, immediately, the filesystem layout doesn't really matter: it's just a matter of disk bandwidth. Journalling filesystems are more usually concerned with metadata consistency, so that the filesystem isn't actively corrupt if the music stops at the wrong point in a directory create or something. ian 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: LARGE single-system Cyrus installs?
On 20 Nov 07, at 1756, David Lang wrote: however a fsync on a journaled filesystem just means the data needs to be written to the journal, it doesn't mean that the journal needs to be flushed to disk. on ext3 if you have data=journaled then your data is in the journal as well and all that the system needs to do on a fsync is to write things to the journal (a nice sequential write), Assuming the journal is on a distinct device and the distinct device can take the load. It isn't on ZFS, although work is in progress. One of the many benefits of the sadly underrated Solaris Disksuite product was the metatrans devices, which at least permitted metadata updates to go to a distinct device. When the UFS logging code went into core Solaris (the ON integration) that facility was dropped, sadly. My Pillar NFS server does data logging to distinct disk groups, but mostly --- like such boxes tend to do --- relies on 12GB of RAM and a battery. A sequential write is only of benefit if the head is in the right place and the platter is at the right rotational position and the write is well-matched to the transfer rate of the spindle: if the spindle is doing large sequential writes while also servicing reads and writes elsewhere, or can't keep up with writing tracks flat out, the problems increase. for cyrus you should have the same sort of requirements that you would have for a database server, including the fact that without a battery-backed disk cache (or solid state drive) to handle your updates, you end up being throttled by your disk rotation rate (you can only do a single fsync write per rotation, and that good only if you don't have to seek), RAID 5/6 arrays are even worse, as almost all systems will require a read of the entire stripe before writing a single block (and it's parity block) back out, and since the stripe is frequently larger then the OS readahead, the OS throws much of the data away immediatly. if we can identify the files that are the bottlenecks it would be very interesting to see the result of puttng them on a solid-state drive. I've split the meta-data out into separate partitions. The meta data is stored in ZFS filesystems in a pool which is a RAID 0+1 4 disk group with SAS drives, the message data is coming out of the lowest QoS on my Pillar. A ten second fsstat on VM operations shows that by request (this measures filesystem activity, not the implied disk activity) it's the meta partitions taking the pounding (ten second sample): map addmap delmap getpag putpag pagio 0 0 0 45 0 0 /var/imap 11 11 11 17 0 0 /var/imap/meta-partition-1 290290290463 5 0 /var/imap/meta-partition-2 139139139183 3 0 /var/imap/meta-partition-3 66 66 66106 10 0 /var/imap/meta-partition-7 347347342454 16 0 /var/imap/meta-partition-8 57 57 57 65 5 0 /var/imap/meta-partition-9 4 4 8 4 0 0 /var/imap/partition-1 11 11 22 14 0 0 /var/imap/partition-2 1 1 2 1 0 0 /var/imap/partition-3 6 6 12 49 10 0 /var/imap/partition-7 15 15 28457 0 0 /var/imap/partition-8 1 1 2 2 0 0 /var/imap/partition-9 Similarly, by non-VM operation: new name name attr attr lookup rddir read read write write file remov chng get setops ops ops bytes ops bytes 0 0 0 2.26K 0 6.15K 0 0 045 1.22K / var/imap 0 0 0 356 0707 0 0 0 6 3.03K / var/imap/meta-partition-1 3 0 3 596 0902 0 6 135K90 305K / var/imap/meta-partition-2 0 0 0 621 0 1.08K 0 0 0 3 1.51K / var/imap/meta-partition-3 3 0 3 1.04K 0 1.70K 0 6 149K36 650K / var/imap/meta-partition-7 0 0 0 2.28K 0 4.24K 0 0 0 7 1.87K / var/imap/meta-partition-8 0 0 018 0 32 0 0 0 2 176 / var/imap/meta-partition-9 2 2 222 0 30 0 1 2.37K 2 7.13K / var/imap/partition-1 3 41284 0157 0 1 677 3 7.51K / var/imap/partition-2 1 1 1 1.27K 0 2.16K 0 0 0 1 3.75K / var/imap/partition-3 2 2 435 0 56 0 1 3.97K36 279K / var/imap/partition-7 1 2 1 256 0514 0 0 0 1 3.75K / var/imap/partition-8 0 0 0 0 0 0 0 0 0 0 0 / var/imap/partition-9 And looking at the real IO load, ten seconds of zpool (for the meta data and /var/imap_ capacity operationsbandwidth pool used avail read write rea
Re: TMPFS for socket and log directories?
On 30 Nov 07, at 0234, Vincent Fox wrote: > We had sym-linked imap/proc directory to a size-limited > TMPFS a while back. > > Now I'm thinking to do the same for imap/socket and imap/log > > Any reasons against? Other candidates? What's the point? The socket directory only contains a handful of inodes which will sit in the inode cache (if they don't, you've got far deeper problems) and the log directory isn't used other than for weird corner cases. I can imagine if you do a lot of logging there might be some point, but otherwise, why bother? ian 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: folder unreadable
I once had to delete the cyrus.* files prior to a reconstruct: they had become toxic to the point that Cyrus's attempts to make use of the information in them was causing problems. ian 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
Cyrus, Radius, Radiator, Vasco
The Cyrus server I run for my employer is sat on our internal network, and remote users access either the IMAP port or the associated Squirrelmail instance via our VPN. They come in via a Cisco IPSec VPN server, secured with SecureID. My private Cyrus server, which sits in borrowed space in someone else's datacentre, doesn't have such luxuries. The IMAP port is openly available, and there is a Squirrelmail server that will allow anyone to attempt to log in. All the IMAP clients that access it use STARTTLS and/or one of the MD5 authentication styles, the Squirrelmail server only operates over https and the passwords are generated with /dev/random, so I've not got too much to worry about. But the datacentre is a University CS department where I do some lecturing, so all sorts of things could happen. I'm considering using the Radiator product, which directly supports Vasco tags and will run on Solaris (my platform of choice), and a Vasco evaluation kit to upgrade the security. This should only involve having saslauthd talk to Radius via PAM, but my experience of incorporating SecureID into other systems is that there are many little places where things go wrong. Has anyone done anything similar? ian 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, Radius, Radiator, Vasco
On 29 Jan 08, at 2004, Paul Dekkers wrote: > But I don't think it will be very easy to > combine the two: the Vasco tokens provide you with one-time passwords, > and for IMAP access, you'll have more then just one connection. My > Thunderbird client already makes a new connection for each folder I > open, squirrelmail isn't much better. Gawd, I'd not thought of that (and I was looking at the number of IMAP per connections per client only the other day, in another context). Thanks for your other suggestions: I shall go away and have a serious think about it. Nomadic use is my key requirement: my daughter, for example, wants to access my webmail service from school, and that's a case I'm worried about. There are all sorts of semi-legitimate and illegitimate reasons why a computer used by an 11 year old at school might have a keylogger on it. ian 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: Miserable performance of cyrus-imapd 2.3.9 -- seems to be locking issues
On 28 Feb 08, at 2256, Kenneth Marshall wrote: > It may be that the software RAID 5 is your problem. Without the > use of NVRAM for a cache, all of the writes need all 3 disks. > That will cause quite a bottle-neck. In general, RAID5 writes require two reads and two writes, independent of the size of the RAID5 assemblage. To write a given block, you read the previous contents of the block you are updating and the associated parity block. You XOR the previous contents with the parity, thus stripping it out, and then XOR the new contents in. You then write the new contents to the data block and the updated parity to the parity block. New Partity = Old Parity xor Old Contents xor New Contents In the absence of NVRAM this requires precisely four disk operations, two reads followed by two writes. A naive implementation would, as you imply, use all the spindles. It would read contents of the parity stripe from the spindles not directly involved in the update, compute the new parity block, and then write the data block and the new parity. For an N disk RAID5 assemblage that's N-2 reads followed by 2 writes, N operations. Now as it happens, for the pathological case of a 3-disk RAID5 assemblage, the naive implementation is better than the more standard implementation. I don't know if any real-world code is optimised for this corner case. I would doubt it: software RAID5 is a performance disaster area at the best of times unless it can take advantage of intimate knowledge of the intent log in the filesystem (RAID-Z does this), and three-disk RAID5 assemblages are a performance disaster area irrespective of hardware in a failure scenario. The rebuild will involve taking 50% of the IO bandwidth of the two remaining disks in order to saturate the new target; rebuild performance --- contrary to intuition --- improves with larger assemblages as you can saturate the replacement disk with less and less of the bandwidth of the surviving spindles. For a terabyte, 3x500GB SATA drives in a RAID5 group will be blown out of the water by 4x500GB SATA drives in a RAID 0+1 configuration in terms of performance and (especially) latency, especially if it can do the Solaris trick of not faulting an entire RAID 0 sub-group if one spindle fails. Rebuild still isn't pretty, mind you. ian 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: Miserable performance of cyrus-imapd 2.3.9 -- seems to be lockingissues
On 05 Mar 08, at 1549, Simon Matter wrote: >> On Tue, 4 Mar 2008, Ian G Batten wrote: >> >>> software RAID5 is a performance >>> disaster area at the best of times unless it can take advantage of >>> intimate knowledge of the intent log in the filesystem (RAID-Z does >>> this), >> >> actually, unless you have top-notch hardware raid controllers, >> software >> raid 5 >> > I can only second that. I'm still wondering what "top-notch hardware > raid > controllers" are. From my experience the only decent "controllers" > you can > get are those in the heavy priced SAN equipments with gigs of cache > on the > SAN controllers and tens or hundreds of spindles behind it. Sorry, that's what I was comparing it to: my experience of software RAID5 is horrid (5+1 assemblages on various small Suns with disksuite) and I probably live a life of luxury with hardware RAID (100-spindle Pillar with 24G of RAM, assorted 50--100 spindle EMC and DotHill arrays with several GB of RAM). I've rarely used PCI-slot RAID controllers: thinking back, I used PCI-card controllers indirectly once upon a time --- Auspex used commodity RAID controllers in their later, doomed, non-VME machines --- and they were horrid. But I use software RAID 0+1 all the time, both with Solaris Disksuite (or whatever it's called this week) and ZFS. Our Cyrus meta-data partitions, for example, sit in this zpool: NAME STATE READ WRITE CKSUM onboard ONLINE 0 0 0 mirror ONLINE 0 0 0 c0t0d0s4 ONLINE 0 0 0 c1t0d0s4 ONLINE 0 0 0 mirror ONLINE 0 0 0 c0t1d0s4 ONLINE 0 0 0 c1t1d0s4 ONLINE 0 0 0 and are perfectly happy. The message store comes in over NAS from a 20-disk stripe consisting of 4 5+1 RAID5 assemblages spread over four RAID controllers fronted with ~10GB of RAM cache, however... Returning to the topic at hand, though, I can't for the life of me see why anyone would want to use RAID5 in 2008 _without_ tens or hundreds of spindles and gigs of cache. Why not just use RAID 0+1? When I've got ~40TB in my Pillar, the difference between RAID5 and RAID 0+1 is a large chunk of change: it's the difference between 104 500GB spindles (16 5+1 volumes, 8 hot spares) and 160 500GB spindles plus however much hot-sparing is prudent. An extra sixty spindles, plus the space, controllers, power supplies, cabling, metalwork is a non-trivial amount of money and heat. Likewise in the 96-spindle DotHill stack and the ~80-spindle EMC: those would require dozens of extra disks and a lot of electronics. And so long as you can handle burst-writes inside the cache memory, there's little read and no write performance benefit for going from RAID5 to RAID 0+1: in both cases reads are serviced from a large stripe and writes go to a write-back cache. Massively sustained writes may benefit from 0+1 because it is easier to do than 5, but outside video editing and ultra-high-end VTL that's a rare workload. But at the low end? Why piss about with something as complex, messy and error-prone as RAID5 when RAID 0+1 is going to cost you a couple of extra spindles and save you a RAID controller? If you have four SATA ports on your machine, just put four 500GB SATA spindles on and you have 1TB of 0+1. Use ZFS and you can turn on compression if you want, too, which is fast enough to be worth the saving in spindle access relative to the CPU load for a lot of workloads (I have ~10TB under ZFS compression for replication, and another couple of TB for tape staging). RAID5 is worthwhile to reduce 160 disks to 100; it's not worth it to reduce 4 disks to 3. ian 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 and popper
On 11 Mar 08, at 1745, Marco Broglia wrote: > How can I configure Cyrus and Qpopper (or another pop server) on the > same server ? No. The mailbox format is different. > I have sendmail. What about sendmail mailers ? > > I have Qpopper with encrypted password (/etc/passwd) in another server > and I'd like to migrate users transparently on the same mail server > (the > passwords can be moved without knowledge). I'm not clear what you're asking, but Cyrus can authenticate from anything that calls getpwnam() (ie /etc/passwd, /etc/shadow, NIS, etc) using saslauthd. ian 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 and popper
On 12 Mar 08, at 1654, Marco Broglia wrote: > I have problems to enable Cyrus pop because I don't know their > passwords and I don't want to change or ask to users (for several > reasons) for them. saslauthd and auto_transition will cope with this. People with entries in sasldb are authenticated from there; people with just entries in /etc/passwd are authenticated from there. ian 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: patches since 2.3.12-p2?
On 19 Jul 08, at 1313, Bron Gondwana wrote: > > Unfortunately, the cyrus database interface sort of sucks from > a consistency perspective, it's dangerous to call any function > that needs database access if you have a database transaction > open I understand some of the technical, philosophical and historical reasons why this isn't the case, but every now and again I find myself wishing that Cyrus had an SQL backend for the various databases (perhaps not delivery, because losing it isn't the end of the world, but certainly for mailboxes). In our case, we have really big Oracle and Postgres systems that could proably handle the load imposed by out mailsystem metadata as well as our mailsystem copes with it itself via skiplist, but we would could then manage those databases with the same tools we use for the production systems (hot backups, replication, etc). Losing the mailboxes database can spoil your whole day, and the lengths we go to to keep it safe (snapshots of the filesystem, hourly runs of ctl_mboxlist -d, etc, etc should really be necessary if it were in a production SQL database. In my copious spare time, I might take a pass at the cope and see how hard it looks. ian 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: Couple of questions
On 21 Jul 08, at 2135, Steve Webb wrote: > I've got pop users > that can't access IMAP (using phones for checking email when on travel > with "leave messages on server" then suck down the emails when they > arrive > back at a desktop). Have you confirmed that they can't use IMAP, or is that just what they say? I've been a heavy user of mail from mobile phones for long enough that I've done it over raw GSM data calls into modem banks (none of this newfangled GPRS stuff). I've not seen a mobile phone in at least five years, probably more, that doesn't support IMAP. For example, the Ericsson T68 supported IMAP, and that's a _long_ time ago in mobile phone terms. Prior to that I used Palm Pilots with IrDA into various Motorola phones, but let's not go too far in archaeology. But if you are stuck with POP3, it probably means the phone's software is old. Sadly, POP3 has an unhelpful numbering scheme. POP was introduced by RFC918 in October 1984. It was revised to POP2 by RFC937 in Feb 1985. Yes, for younger readers, a protocol really did go through two versions in five months, while only eighteen other RFCs were published... POP3 was defined by RFC1081, and then modified by 1225 (helpfully contains no list of changes, but introduces RPOP), 1460 (again no list of changes, drops RPOP, introduces APOP), 1725 (draft only, removes LAST, adds UIDL, lots of tightening up of language) and 1939 (standard, more tightening up), spanning from November 1988 to May 1996. Throughout this it stayed called `POP3', and there is no equivalent to the IMAP CAPABILITY to find out what it supports. UIDL had been floating around as a proposal and, I think, running code prior to 1994 (RFC1725) and certainly prior to 1996 (RFC1939). Given that POP3 has a chequered history when you push the semantics, I wouldn't trust UIDL any further than I could throw it. It doesn't define an equivalent to UIDVALIDITY (Cyrus fakes it by embedding the mailbox creation time into each UID, so if that changes the messages appear new), the code in a given client is more likely to be server specific than RFC-compliant, and POP3 clients are inherently abandonware anyway. I'd say that your users can almost certainly use IMAP, if but they look at the menus. But if they can't, they are relying on Neolithic client implementations of a Palaeolithic protocol... ian 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
SASL MySQL Backend Considered Beneficial
On 11 Aug 08, at 1648, Martin Schweizer wrote:
> Hello
>
> I have two mail server (FreeBSD 7.0, sendmail/cyrus v2.3.12p2), incl.
> replication with sync_client/-master. Until now they works perfect.
> Now I changed on the sync_server from sasldb (Berkeley db1.85) to
> saslauthd (with saslauthd -a getpwent, the Unix password file). All
> works but not the replication (but the login to cyrus imapd works). So
> I tracked down the problem to the sasldb file. I seems that the sync
> mechanism needs the sync_authname in the sasldb (it not check the
> password file). Is this correct?
In passing, and for what it's worth, one of the best moves I ever made
on my private Cyrus server, which I'm working myself up to do for my
day job Cyrus server, was to switch over to using the mysql backend to
SASL and divorcing it both from the password file and from the /etc/
sasldb mechanism.
I did it because it means I can operate mail accounts disjoint from
real user accounts: I can log in, but my wife, kids, parents etc only
have the ability to send and receive email. But most importantly it
means I have an authentication database which I can secure on a per-
subsystem basis while sharing records. Trying to use /etc/sasldb with
the same authenticators shared between cyrus (running as uid cyrus)
and sendmail (running as uid smmta) is a living hell, whereas with
MySQL I just use imapd.conf settings:
sasl_pwcheck_method: auxprop
sasl_auxprop_plugin: sql
sasl_auto_transition: yes
sasl_sql_engine: mysql
sasl_sql_hostnames: localhost
sasl_sql_user: cyrus
sasl_sql_passwd:
sasl_sql_database: cyrussasl
sasl_sql_select: select %p from users where username = '%u'
sasl_sql_insert: insert into users (username, realm, %p) values ('%u',
'%r', '%v')
sasl_sql_update: update users set %p='%v' where username='%u'
and in Sendmail.conf (in my case in /opt/sasl2/lib/sasl2, but your
mileage will vary):
pwcheck_method: auxprop
auxprop_plugin: sql
sql_engine: mysql
sql_hostnames: localhost
sql_user: sendmail
sql_passwd:
sql_database: cyrussasl
sql_select: SELECT userPassword FROM users WHERE username = '%u'
mech_list: digest-md5 cram-md5
sql_verbose: yes
My database has accreted columns, so when I commission users I have to
put their secret into several of them, which I should fix one day:
CREATE TABLE `users` (
`username` varchar(64) NOT NULL default '',
`realm` varchar(64) default NULL,
`userPassword` varchar(64) default NULL,
`cmusaslsecretPLAIN` varchar(64) default NULL,
`cmusaslsecretDIGEST` varchar(64) default NULL,
`MD5` varchar(64) default NULL,
`cmusaslsecretCRAM` varchar(64) default NULL,
PRIMARY KEY (`username`)
) TYPE=InnoDB
Not the question you asked, I know, but I'm been meaning to mention
just how flexible this setup is.
ian
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
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 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 2.3.13 RC2
On 08 Oct 08, at 0536, Bron Gondwana wrote: > On Mon, Oct 06, 2008 at 11:33:18AM -0400, Ken Murchison wrote: >> I just put together a second release candidate for Cyrus 2.3.13. I'd >> appreciate any independent testing before I release this to the >> masses. > > Sorry about the delay in testing - we've had a few exciting issues > here that had to be fixed first. > >> If there are any outstanding issues that you believe still need to be >> addressed in 2.3.13, please let me know. > > No, it's looking good. I just removed the patches that have gone into > CVS from my build tree and it built fine. Running on our test server > now with no problems. All the patches that have gone upstream have > been running happily on our production machines for a bit too. > > I think now's a good time to release a 2.3.13. What's the testing status of the SQL backend for cyrusdb? I'll switch batten.eu.org over to it, but that only has a dozen or so users; ftel.co.uk's 1000+ users might be a little tenser. I'm keen to switch as the ability to replicate cyrusdb as well as replicating the entire mailsystem is attractive. ian 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 2.3.13 RC2
> > We were only looking at SQL to replace BDB (deliver.db, > tls_sessions.db), because we still think that skiplist is superior > from mailboxes.db and seen.db. If you do some heavy testing with > the BDB code we'd be interested in your results. OK, that's interesting. I'll get 2.3.13 onto batten.eu.org and try some testing. The whole instance is under ZFS so I can roll back if necessary. ian 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 2.3.13 RC2
On 08 Oct 08, at 1119, Bron Gondwana wrote: > > On Wed, 8 Oct 2008 09:24:49 +0100, "Ian G Batten" <[EMAIL PROTECTED] > > said: >> What's the testing status of the SQL backend for cyrusdb? I'll >> switch batten.eu.org over to it, but that only has a dozen or so >> users; ftel.co.uk's 1000+ users might be a little tenser. I'm keen >> to >> switch as the ability to replicate cyrusdb as well as replicating the >> entire mailsystem is attractive. > > You are aware that cyrus replication replicates DB records for all the > important things as well, aren't you? Yes, of course. It's just that having, many years ago, experienced the loss of a cyrusdb, being able to keep up-to-date copies of it which I can use without the nuclear option of failing over to my off- site replica is a good thing. So I will shortly have my whole Cyrus instance (~60K mailboxes, ~1000 users, ~4TB of mail) replicated via GigE to a remote site. But if my local instance went south just because Cyrus DB had gone, being able to simply switch cyrusdb to a MySQL/PostgresQL replica while keeping mail service on the master is preferable to doing a full off-site failover. ian 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 2.3.13 RC3
On 10 Oct 08, at 0128, Bron Gondwana wrote: > On Thu, Oct 09, 2008 at 10:57:33AM -0400, Ken Murchison wrote: >> I just put together a third and hopefully FINAL release candidate for >> Cyrus 2.3.13. I'd appreciate any independent testing before I >> release >> this to the masses. > > Looks good. The syslog deleted change broke the fastrename patch, > so I > had to re-build it, but otherwise applied fine and is working fine on > our testbed. It's running fine on my test system (Solaris 10 on x86) with SQL backends as previously discussed. ian 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
2.1.16->2.2.3 on Linux
On my small personal server, supporting a few family members, I run
Cyrus latest where possible. I was running 2.1.16 with every database
set to skiplist. Upgrading to 2.2.3 with the same ./configure command
./configure --with-openssl --with-sasl --without-cmulocal
--with-cyrus-user= cyrus --with-cyrus-group=cyrus
--with-duplicate-db=skiplist --with-mboxlist-db=s kiplist
--with-seen-db=skiplist --with-subs-db=skiplist --with-tls-db=skiplist -
-with-idle=idled
left lmtpd, cvt_cyrusdb, and possibly other things, hanging.
strace revealed this:
open("/var/imap/db/DB_CONFIG", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/var/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=72, ...}) = 0
open("/var/imap/db/__db.001", O_RDWR) = 3
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
fstat64(3, {st_mode=S_IFREG|0600, st_size=8192, ...}) = 0
close(3)= 0
open("/var/imap/db/__db.001", O_RDWR) = 3
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0x40018000
close(3)= 0
select(0, NULL, NULL, NULL, {0, 1000}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {0, 2000}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {0, 4000}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {0, 8000}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {0, 16000}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {0, 32000}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {0, 64000}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {0, 128000}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {0, 256000}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {0, 512000}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
Reconstructing all the user mailboxes cured the problem.
ian
Re: 2.1.16->2.2.3 on Linux
On Tue, 03 Feb 2004, Rob Siemborski wrote: > On Tue, 3 Feb 2004, Ian G Batten wrote: > > > On my small personal server, supporting a few family members, I run > > Cyrus latest where possible. I was running 2.1.16 with every database > > set to skiplist. Upgrading to 2.2.3 with the same ./configure command > > You should read the 2.2.3 upgrade documentation about how non-default > databases are now handled in imapd.conf. It's in changes.html. It didn't leap out at me when I switched, so perhaps it might be worth making louder noises about. > > Reconstructing all the user mailboxes cured the problem. > > More than likely it only hid this problem (and others which I am sure you > will find later) Correct. deliver.db was still Berkeley. I've corrected everything and all now seems well. ian
Re: 2.1.16->2.2.3 on Linux
On Tue, 03 Feb 2004, Rob Siemborski wrote: > On Tue, 3 Feb 2004, Ian G Batten wrote: > > > It's in changes.html. It didn't leap out at me when I switched, so > > perhaps it might be worth making louder noises about. > > Actually, I was referring to install-upgrade.html. > > I'm not sure where we'd put this sort of stuff that is more obvious than > "the upgrade documentation" OK, here's the thing. I thought that skiplist _was_ the default format. The text is: * The Cyrus database backend configuration is now handled at runtime using imapd.conf options. If you are not using the default backend for any of the databases, make sure that you specify the correct backend(s) in appropriate option(s). and * The default database formats for the mailbox list and the seen state databases has been changed to the skiplist backend. There are two ways of dealing with this if you have been using the defaults. I thought that meant ``no change''. Looking at it more closely, the default format for deliver.db is still Berkeley, hence my problem. I think it would be worth being more specific than ``the default backend''. ian
Re: 2.1.16->2.2.3 on Linux
On Tue, 03 Feb 2004, Rob Siemborski wrote: > On Tue, 3 Feb 2004, Ian G Batten wrote: > > > I thought that meant ``no change''. Looking at it more closely, the > > default format for deliver.db is still Berkeley, hence my problem. I > > think it would be worth being more specific than ``the default > > backend''. > > All of the default values for configuration options are listed in the > imapd.conf man page. > > If you have a specific suggestion for a text change, please send a patch. I'll think about that. The gist of it should be that the entries in imapd.conf should match the entries in the ./configure line. ian
tls_*_cert in 2.2.3
I wiped out access to my Cyrus store for my father and my wife which I
went to 2.2.3. It turned out that the problem was that when they
connected with TLS (I didn't test that, sadly) imapd immediately exited
with ``imaps: required OpenSSL options not present''.
I traced through the source to tls_enabled() in imap/tls.c, which was
returning 0. I was successfully using split certificates for POP, IMAP
and so on under 2.1.16:
tls_imap_cert_file: /var/imap/certs/imap-cert.pem
tls_imap_key_file: /var/imap/certs/imap-private.pem
tls_pop3_cert_file: /var/imap/certs/pop-cert.pem
tls_pop3_key_file: /var/imap/certs/pop-private.pem
tls_lmtp_cert_file: disabled
tls_lmtp_key_file: disabled
In 2.2.3, doc/install-configure.html still says:
Add the following to /etc/imapd.conf to tell the server
where to find the certificate and key file (used for ALL services):
tls_cert_file: /var/imap/server.pem
tls_key_file: /var/imap/server.pem
Optionally, you can use separate certificates and key files for each
service:
tls_imap_cert_file: /var/imap/imap-server.pem
tls_imap_key_file: /var/imap/imap-server.pem
[...]
You in fact can't use tls_*_cert_file. In the 2.1.16 tls.c, tls_enabled()
does:
snprintf(buf, sizeof(buf), "tls_%s_cert_file", ident);
val = config_getstring(buf,
config_getstring("tls_cert_file", NULL));
if (!val || !strcasecmp(val, "disabled")) return 0;
and so on, and tls_init_serverengine() does:
snprintf(buf, sizeof(buf), "tls_%s_cert_file", ident);
s_cert_file = config_getstring(buf,
config_getstring("tls_cert_file", NULL));
snprintf(buf, sizeof(buf), "tls_%s_key_file", ident);
s_key_file = config_getstring(buf,
config_getstring("tls_key_file", NULL));
In 2.2.3, the same functions do:
val = config_getstring(IMAPOPT_TLS_CERT_FILE);
if (!val || !strcasecmp(val, "disabled")) return 0;
and
s_cert_file = config_getstring(IMAPOPT_TLS_CERT_FILE);
s_key_file = config_getstring(IMAPOPT_TLS_KEY_FILE);
lib/imapopts.c has:
{ IMAPOPT_TLS_CERT_FILE, "tls_cert_file", 0, (union config_value)((const char *)
NULL), OPT_STRING, { { NULL, IMAP_ENUM_ZERO } } },
So far as I can make out this breaks the ability to have distinct keys
for distinct services on the same machine. I've worked around it by
using the IMAP key for everything, knowing that only I used the POP3S
service and I can ignore the certificate mis-match. I'm not sure why
the functionality has been removed, but either it should be put back in
or the documentation should be changed and something added to the change
log.
ian
Re: tls_*_cert in 2.2.3
On Wed, 04 Feb 2004, Rob Siemborski wrote: > On Wed, 4 Feb 2004, Ken Murchison wrote: > > > Try _tls_cert_file and _tls_key_file where > > is the name of the service from cyrus.conf (note that this > > is NOT the name of the binary). > > I've fixed install-configure.html (install-upgrade.html had the correct > information). For clarity, if I have this: imap cmd="imapd" listen="imap" prefork=1 imaps cmd="imapd -s" listen="imaps" prefork=0 in /etc/cyrus.conf, do I need to specify both of imap_tls_key_file and imaps_tls_key_file (and likewise for *_cert_file)? My assumption is that I do, but I just want to be sure. I'm assuming that imap_* would be used when someone uses STARTTLS via port 143, the service name being imap, while imaps_* would be used when someone connects to port 993 and expects to be running TLS'd from the outset, the service name being imaps. ian
Re: Problems with Cyrus IMAP 2.2.5 on Solaris 9 on production server
For what it's worth, I'm building a new server to replace my long-standing Solaris 7 + Cyrus 1.6.22 server --- one hour of downtime since 1999. I've used the gcc from the SFW collection, Cyrus 2.2.4 and Solaris 10 build 55 (which is probably the current Solaris Express bits: I'm a Platinum Beta site, so I get my bits via another route). I've transferred my own mailboxes over, and on ``Cortez burning his boats'' grounds I've deleted my mailbox from the production server. So far I've not seen any major problems, although a concerted dose of killing processes at random while under load corrupted my skiplist mailboxes.db file. For safety I've switched that to berkeley (Sun provide db4.1 in SFW). ian --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Problems with Cyrus IMAP 2.2.5 on Solaris 9 on production server
On Thu, 03 Jun 2004, Rob Siemborski wrote: > Why on earth were you killing processes at random? As a test of the stability of the databases. A database should be able to take the explosive failure of any reader or writer with, at worst, a reconstruction. Consider the scenario when the machine loses power, for example, or experiences a panic. ian --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Problems with Cyrus IMAP 2.2.5 on Solaris 9 on production server
On Thu, 03 Jun 2004, Rob Siemborski wrote: > I'll also ask the obvious -- did you subsequently stop the server and run > recovery on the database? Well, master couldn't prefork anything, citing an inability to read mailboxes.db. As reconstruct -m is currently unavailable I used reconstruct -p to rebuild it. I have the corrupt mailboxes.db file available if you're interested. ian --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Problems with Cyrus IMAP 2.2.5 on Solaris 9 on production server
On Fri, 04 Jun 2004, Rob Siemborski wrote: > I ment ctl_cyrusdb -r. I thought that was run automatically when master started? ian --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Moving 1.6.22 cyrus.index to 2.2.latest
As part of my move from 1.6.22 on Solaris 7 to 2.2.4 on Solaris 10, I need to bulk move about six hundred mailboxes totalling about 120GBytes. For the pilot users I've used imapsync, which works correctly (including moving flags) but is quite slow and resource intensive. For service use, I'd ideally just rsync the data over and reconstruct the mailboxes on the receiving side. On current showing, this would be a _lot_ faster. However, it appears to lose flag settings other than seen, which some users will grumble about. I think this is because cyrus.seen is flat, while cyrus.index is a database --- I presume BerkeleyDB, but I'm not entirely sure. I compiled 1.6.22 using BerkeleyDB 3.1. I'm using Berkeley 4.1 and Skiplist in 2.2.4. If I compiled a copy of cvt_cyrusdb using the same set of BerkeleyDB headers and libraries, would it then be capable of converting cyrus.index? Or would the differences between 1.6.22 and 2.2.4 be too great? It worries me that a copy of cvt_cyrusdb which understands Berkeley 4.1 won't look at the files, because I was under the impression that there was back-compatibility there. ian --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Moving 1.6.22 cyrus.index to 2.2.latest
On Thu, 10 Jun 2004, Ian G Batten wrote: > As part of my move from 1.6.22 on Solaris 7 to 2.2.4 on Solaris 10, I > need to bulk move about six hundred mailboxes totalling about 120GBytes. > For the pilot users I've used imapsync, which works correctly (including > moving flags) but is quite slow and resource intensive. > > For service use, I'd ideally just rsync the data over and reconstruct > the mailboxes on the receiving side. On current showing, this would be > a _lot_ faster. However, it appears to lose flag settings other than > seen, which some users will grumble about. I think this is because > cyrus.seen is flat, while cyrus.index is a database --- I presume > BerkeleyDB, but I'm not entirely sure. > > I compiled 1.6.22 using BerkeleyDB 3.1. I'm using Berkeley 4.1 and Correction. It was 2.7.7. And... > Skiplist in 2.2.4. If I compiled a copy of cvt_cyrusdb using the same > set of BerkeleyDB headers and libraries, would it then be capable of > converting cyrus.index? Or would the differences between 1.6.22 and It won't compile, as the API has changed. It looks like imapsync is my kiddy, unless there's a really flashy suggestion... ian --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: script processing messages
On Thu, 10 Jun 2004, Florin Andrei wrote: > What's the most simple method to connect to a Cyrus IMAP server, login > as a user, go to a certain folder (the path is known), delete all > messages in it, then logout - and do all that from a shell script? (a > cron job) There's bound to be an option to fetchmail. Mind you, that's a universal truth for almost any question. ``Peace in the Middle East? There's an option to fetchmail...'' ian --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: New Cyrus Server - what would be ideal?
On Sun, 11 Jul 2004, Elizabeth Schwartz wrote: > I'm planning to build a new, larger, server with Solaris 9, and cyrus, I'm running my new mailserver on Solaris 10, but I'm using ZFS for several of the spool partitions. The performance rocks (even on some mangy old A5000 arrays) and you get multi-layer snapshots to make your backups easier. You can't have those bits right now --- I don't think ZFS is going to go into Solaris Express for a few months yet --- but if you can wait until Solaris 10 ships, or plan for an upgrade then, you won't regret it. ian --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
lists2.andrew.cmu.edu vs Sendmail 8.13 `greet_pause'
I've put in an exception, but it may be worth someone looking at why the Cyrus list trips over the Sendmail greet_pause code. 1090338598.297 Jul 20 16:49:58 i6KFntRU028281: rejecting commands from LISTS2.andrew.cmu.edu [128.2.10.216] due to pre-greeting traffic This implies that LISTS2 is sending traffic to me before it's seen the initial SMTP banner. ian --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
migrate-metadata performance
Looking at the migration script, it's essentially find . -name
cyrus.* -exec mv {} /meta/part/{} \;. That's quite slow, because it
has to stat() all the messages to find the files which are metadata.
I've written an alternative for the migration we're planning for
later this week, which uses ctl_mboxlist -d to find all the mailboxes
and then looks explicitly for the named files, which avoids stat()ing
the messages.It's a bit rough at the moment: for example, it
assumes the old, single-initial-letter hashing scheme, but reducing
the amount of time the mail system has to be down for an upgrade is
always worthwhile!
ian
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
LIST is slow for 35K mailboxes
We have clients which issue LIST "" * when they start up. We think we need them to do this, because we are making quite heavy use of shared mailboxes so a mailbox may arrive in a hierarchy other than INBOX.* to which the user should subscribe. We have ~35K mailboxes (as reported by ctl_mboxlist -d | wc -l), and the LIST takes upwards of 5 minutes. The imapd spins as much CPU as it can get hold of, too. We assumed this was down to our elderly hardware (a 4x650MHz E450, albeit front-ending fast NAS store) but a freshly installed 8-core T2000 with 16GB of RAM and only one imapd executing takes a similar amount of time. The production mailserver is now perfectly usable with a load average of >100 thanks to the wonders of Solaris 10 FSS, but the five minute responses to LIST "" * cause clients some distress. We had hoped the move to the T2000 would solve the problem, but today's testing shows the new machine doesn't make a significant difference. The old machine is running 2.2.8, the new machine is running 2.3.9. The old machine has configdir (/var/imap) striped over four spindles and then mirrored into four spindles, the new machine has /var/imap in ZFS filesystem of four disks, again mirrored in pairs. The imap daemon that is spinning servicing the LIST "" * doesn't appear to do any I/O (other than regularly stating mailboxes.db), so I don't think disk performance is at issue anyway. foolstupidclients: 1 would obviously help the performance, but would break the shared mailboxes. I could modify tghe code to provide a limited form of foolstupidclients, which would turn on the option for users who don't need shared mailboxes but leave it off for those that do. But at root I don't understand why LIST "" * should take any longer than, for example, ctl_mboxlist -d. Before I wade into the code, can anyone make any helpful suggestions? ian 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: LIST is slow for 35K mailboxes
1b1ab8, 0x4,
0x80808080)
/[EMAIL PROTECTED]: -> prot_write(0x1f72e8, 0x1b19fc, 0x2,
0x80808080)
/[EMAIL PROTECTED]: -> prot_printf(0x1f72e8, 0x1b1a78,
0x1aed00,
0x1b1a68)
/[EMAIL PROTECTED]: -> prot_write(0x1f72e8, 0x1b1a78, 0x0,
0x80808080)
/[EMAIL PROTECTED]: -> prot_write(0x1f72e8, 0x1aed00, 0x0,
0x80808080)
/[EMAIL PROTECTED]: -> prot_write(0x1f72e8, 0x1b1a7a, 0x0,
0x80808080)
/[EMAIL PROTECTED]: -> prot_write(0x1f72e8, 0x1b1a68, 0xe,
0x80808080)
/[EMAIL PROTECTED]: -> prot_write(0x1f72e8, 0x1b1a7c, 0x0,
0x80808080)
/[EMAIL PROTECTED]: -> prot_printf(0x1f72e8, 0x1b1a30, 0x2e,
0xffbfc998)
/[EMAIL PROTECTED]: -> prot_write(0x1f72e8, 0x1b1a30, 0x3,
0x80808080)
/[EMAIL PROTECTED]: -> prot_write(0x1f72e8, 0x1b1a35, 0x2,
0x80808080)
/[EMAIL PROTECTED]: -> mboxname_toexternal(0x1efe7c, 0x1dfb40,
0x1f02d0, 0xffbfca38)
/[EMAIL PROTECTED]: -> mboxname_hiersep_toexternal(0x1efe7c,
0xffbfca38, 0x0, 0x7300)
/[EMAIL PROTECTED]: -> printstring(0xffbfca38, 0x1dfb40,
0x1f02d0,
0xffbfca38)
/[EMAIL PROTECTED]: -> prot_printf(0x1f72e8, 0x1af2a0,
0xffbfca38,
0xffbfca38)
/[EMAIL PROTECTED]: -> prot_write(0x1f72e8, 0x1af2a0, 0x1,
0x80808080)
/[EMAIL PROTECTED]: -> prot_write(0x1f72e8, 0xffbfca38, 0x11,
0x80808080)
/[EMAIL PROTECTED]: -> prot_write(0x1f72e8, 0x1af2a3, 0x1,
0x80808080)
/[EMAIL PROTECTED]: -> prot_printf(0x1f72e8, 0x1af918,
0xffbfca38,
0xffbfc998)
/[EMAIL PROTECTED]: -> prot_write(0x1f72e8, 0x1af918, 0x2,
0x80808080)
/[EMAIL PROTECTED]: -> mboxname_tointernal(0x1efe7c, 0x1b0218,
0x1f02d0, 0xffbfca38)
/[EMAIL PROTECTED]: -> mboxname_hiersep_tointernal(0x1efe7c,
0xffbfca40, 0x0, 0x1f02d0)
/[EMAIL PROTECTED]: -> mboxlist_detail(0xffbfca38, 0xffbfca34,
0x0,
0x0)
/[EMAIL PROTECTED]: -> mboxlist_mylookup(0xffbfca38,
0xffbfca34,
0x0, 0x0)
/[EMAIL PROTECTED]: -> fetch(0x1f22f8, 0xffbfca38, 0x1b,
0xffbfc9b4)
/[EMAIL PROTECTED]: -> myfetch(0x1f22f8, 0xffbfca38, 0x1b,
0xffbfc9b4)
/[EMAIL PROTECTED]: -> starttxn_or_refetch(0x1f22f8, 0x0,
0x0,
0x0)
/1: stat("/var/imap/mailboxes.db", 0xFFBFC838) = 0
>
> :wes
>
> On 09 Oct 2007, at 09:19, Ian G Batten wrote:
>> WeBut at root I don't understand why LIST "" * should take any
>> longer than, for example, ctl_mboxlist -d.
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: LIST is slow for 35K mailboxes
On 09 Oct 07, at 1522, Blake Hudson wrote: >> >> Sorry this doesn't help solve your problem but it proves it should >> be a lot faster than that. >> >> Joseph Brennan >> Columbia University Information Technology >> >> > Could database type differences (or contention) be an issue here? What > database format are each of you using? We're using Berkeley. We tried skiplist a few years ago, but we saw occasional problems with it and switched back. I'll try skiplist now... ian 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: LIST is slow for 35K mailboxes
On 09 Oct 07, at 1522, Blake Hudson wrote: >> > Could database type differences (or contention) be an issue here? What > database format are each of you using? Yes. With skiplist (took me several stabs at it to get the conversion to work) it takes 0.19s. Versus ~250s with BDB. A slight difference. Thanks for pointing me at the idea. ian 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: LIST is slow for 35K mailboxes
On 09 Oct 07, at 1748, Ian G Batten wrote: > > On 09 Oct 07, at 1522, Blake Hudson wrote: >>> >> Could database type differences (or contention) be an issue here? >> What >> database format are each of you using? > > Yes. With skiplist (took me several stabs at it to get the > conversion to work) it takes 0.19s. Versus ~250s with BDB. A slight > difference. Thanks for pointing me at the idea. Hmm. We're _not_ using Berkeley (and the give away should have been that the output from ctl_mboxlist -d is the same size as the database itself!). It looks like at some point in the dim and distant we converted to `flat', a la 1.5, for some reason, and then never undid it... At least it's driven us to learn more about FSS than is healthy. Thanks for the help, and I'll slap my forehead Homer style for a while. ian 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
Can I restore from ctl_deliver -d?
I'm performing a migration from 2.2.8 on an E450 running Solaris 10 Beta Build 58 to 2.3.9 on a T2000 running Solaris 10 latest. The former isn't zoned (it wasn't available in that build), isn't smf'd (ditto) and isn't ZFS'd (ditto). The new machine has Cyrus in a zone, rooted on ZFS, with the local storage also on ZFS. The mailboxes themselves (35K mailboxes, a couple of terabytes) are on NFS storage (some on Sun, mostly on a Pillar), so I'm testing the new configuration by performing a metadata migration from read-only mounts. I've written a script to perform the migration in an rsync style, paralleled over the T2000, which is able to sync the metadata between the live storage and the new metadata partition in 35 seconds. Just to ensure the best health and hygiene, I'm rebuilding as many databases as I can. The mailboxes file is the result of ctl_mboxlist -d | ctl_mboxlist -u, the sasldb is the result of db_dump -p and db_load, etc, etc. However, the one that seems resistant to this is deliver.db (skiplist format). cvt_cyrusdb ... skiplist ... flat takes five hours before failing, and although ctl_deliver -d appears to run quickly and correctly, I can't see an immediately obvious way to reload it. Obviously, this isn't a big problem: I can just shut down the old Cyrus instance, copy the file over, and all is well. But having databases de-fragmented, built with the same bits that are in production, is a nice confidence booster if it's possible. ian 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
idled: unrecognized message: 3
I've just brought up our 2.3.9 installation. My logs are filled with `idled: unrecognized message: 3', happening around the time of login. Should I worry? ian 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: idled: unrecognized message: 3
On 12 Oct 07, at 1901, Ian G Batten wrote: > I've just brought up our 2.3.9 installation. My logs are filled with > `idled: unrecognized message: 3', happening around the time of > login. Should I worry? Tracked that one down. In 2.2 you need --with-idle=idled. With 2.3 you need --enable-idled. I compiled 2.3 with the same config deck as 2.2, and then installed it into the same partition. So I had the 2.2 idled. Which worked, astoundingly enough, but logged a lot of problems with things it didn't understand. Anyroadup, ~1000 users on a T2000, load average is below 1.0, zfs'd metadata partitions (compression=on, atime=off) are taking most of the load with the non-metadata partitions over NFS being treated very gently. ian 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: Can I restore from ctl_deliver -d?
On 16 Oct 07, at 1259, Alain Spineux wrote: > Hi > > You are very conscientious. > Because deliver.db only avoid multiple delivery of the same email in > the same mailbox, > most of us should have skipped this. Multiple delivery should be very > rare, happend only once, and without consequences. > > Dou you know you can "expire" oldest entries in deliver.db using > cyr_expire ? > This could reduce the time processing and maybe avoid errors. I considered expiring it down to one day. But that would still have taken a few hours to flatten. Anyway, I just copied it from one machine to the new one, and it all worked fine. ian > > Regards. > > On 10/11/07, Ian G Batten <[EMAIL PROTECTED]> wrote: >> I'm performing a migration from 2.2.8 on an E450 running Solaris 10 >> Beta Build 58 to 2.3.9 on a T2000 running Solaris 10 latest. The >> former isn't zoned (it wasn't available in that build), isn't smf'd >> (ditto) and isn't ZFS'd (ditto). >> >> The new machine has Cyrus in a zone, rooted on ZFS, with the local >> storage also on ZFS. >> >> The mailboxes themselves (35K mailboxes, a couple of terabytes) are >> on NFS storage (some on Sun, mostly on a Pillar), so I'm testing the >> new configuration by performing a metadata migration from read-only >> mounts. I've written a script to perform the migration in an rsync >> style, paralleled over the T2000, which is able to sync the metadata >> between the live storage and the new metadata partition in 35 >> seconds. >> >> Just to ensure the best health and hygiene, I'm rebuilding as many >> databases as I can. The mailboxes file is the result of ctl_mboxlist >> -d | ctl_mboxlist -u, the sasldb is the result of db_dump -p and >> db_load, etc, etc. >> >> However, the one that seems resistant to this is deliver.db (skiplist >> format). cvt_cyrusdb ... skiplist ... flat takes five hours before >> failing, and although ctl_deliver -d appears to run quickly and >> correctly, I can't see an immediately obvious way to reload it. >> Obviously, this isn't a big problem: I can just shut down the old >> Cyrus instance, copy the file over, and all is well. But having >> databases de-fragmented, built with the same bits that are in >> production, is a nice confidence booster if it's possible. >> >> ian >> >> >> 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 >> > > > -- > Alain Spineux > aspineux gmail com > May the sources be with you 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
IOERROR: reading message: unexpected end of file (message_copy_strict)
Since we moved to 2.2.6 on Solaris 10, with storage coming via NFS, we've been seeing ``IOERROR: reading message: unexpected end of file'' intermittently. It doesn't seem to cause any harm. I went through and placed the function name in each occurrence of the message (as a note, non-unique messages in different functions are a bit of a pain) and the error is always arising from message_copy_strict. I've seen the problem with Solaris 10 build 58 with 2.2.6 and 2.2.8 on an E450 and Solaris 10 09/07 with 2.2.8 and 2.3.9 on a T2000, all with NFS storage from other Suns and from a Pillar. I've not seen the problem with Solaris 10 09/07 on Intel with 2.3.9, but that's not using NFS. Before I do the surgery to establish the file in which the error is occurring (which might not help anyway), is the changelog entry for 2.3.10RC3: * Finally fixed (again?) alignment issues on 64-bit SPARC. anything to do with this problem? ian 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: IOERROR: reading message: unexpected end of file (message_copy_strict)
On 23 Oct 07, at 1943, David Carter wrote: > On Tue, 23 Oct 2007, Ken Murchison wrote: > >> Your problem is most likely related to using NFS. NFS has never been >> recommended for Cyrus because is doesn't play nice with mmap() and >> flock(), both of which are critical to the operation of Cyrus. > > While I agree entirely with "don't use Cyrus over NFS", I'm not sure I agree (although my experience is ~1000 users and ~2TB, so rather smaller than a lot of people here). mmap() over NFS arrived in Solaris 8 and we've never had problems with it, and although I accept that locking is a living hell, for the case of an imap message store it's perfectly legitimate to use the llock mount option and handle it all at the client end. I had NFS store on machines that do nothing else (in some cases _can_ do nothing else), and export lumps of storage to the Cyrus server and the Cyrus server alone. > I see these errors > using a local filesystem. A quick grep pins the likely cause down to > message_copy_strict(), which is called by append_fromstream(). It is indeed always from message_copy_strict (I tagged all the messages in the source and recompiled) Oct 24 10:45:11 mailhost-new.ftel.co.uk imap[18187]: [ID 722758 local6.error] IOERROR: reading message: unexpected end of file (message_copy_strict) > > I don't think that this is anything more sinister than TCP connections > dropping out partway through a large IMAP APPEND operation. > Entirely safe. OK, I'll see if I can test that assumption. ian 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 IMAPd 2.3.10 Released
I've just compiled 2.3.10 on batten.eu.org (my private x86 servers)
and although it looks OK on the Solaris 10 system, it's in deep
trouble on the elderly Linux machine. Both are upgrades from 2.3.7,
the Solaris box is a replication target, the Linux box is a
replication master that handles deliver and reading. The intent is
to swap them over, and that intent might come sooner than I planned.
LSUB produces expected output, LIST doesn't (to put it mildly) and
examine/select can't select anything. strace on the running imapd
shows it's doing roughly sensible things: finding the correct
partition and metapartition from the mailbox database, opening the
metadata files correctly, but then it says NO. I've reconstructed
the mailbox, dumped and reloaded (ctl_mboxlist -d // ctl_mboxlist -u)
the mailboxes file and run reconstruct -G ``in case it makes any
odds''. No joy. And nothing useful in the logs, either...
read(0, ". examine INBOX\r\n", 4096)= 17
fcntl64(6, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0})
= 0
fstat64(6, {st_mode=S_IFREG|0600, st_size=3520, ...}) = 0
stat64("/var/imap/mailboxes.db", {st_mode=S_IFREG|0600,
st_size=3520, ...}) = 0
fcntl64(6, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0})
= 0
fcntl64(6, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0})
= 0
fstat64(6, {st_mode=S_IFREG|0600, st_size=3520, ...}) = 0
stat64("/var/imap/mailboxes.db", {st_mode=S_IFREG|0600,
st_size=3520, ...}) = 0
fcntl64(6, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0})
= 0
open("/var/imap/metadata/user/igb/cyrus.header", O_RDWR) = 11
fstat64(11, {st_mode=S_IFREG|0600, st_size=250, ...}) = 0
mmap2(NULL, 250, PROT_READ, MAP_SHARED, 11, 0) = 0x40ee1000
open("/var/imap/metadata/user/igb/cyrus.index", O_RDWR) = 12
fstat64(12, {st_mode=S_IFREG|0600, st_size=204784, ...}) = 0
mmap2(NULL, 212992, PROT_READ, MAP_SHARED, 12, 0) = 0x40ef3000
open("/var/imap/metadata/user/igb/cyrus.cache", O_RDWR) = 13
fstat64(13, {st_mode=S_IFREG|0600, st_size=2753804, ...}) = 0
mmap2(NULL, 2768896, PROT_READ, MAP_SHARED, 13, 0) = 0x40f27000
fstat64(12, {st_mode=S_IFREG|0600, st_size=204784, ...}) = 0
close(11) = 0
munmap(0x40ee1000, 250) = 0
close(12) = 0
munmap(0x40ef3000, 212992) = 0
close(13) = 0
munmap(0x40f27000, 2768896) = 0
write(1, ". NO Mailbox does not exist\r\n", 29) = 29
* OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS AUTH=CRAM-MD5
AUTH=DIGEST-MD5 AUTH=LOGIN AUTH=PLAIN AUTH=OTP SASL-IR]
offsite.batten.eu.org Cyrus IMAP4 v2.3.10 server ready
. login igb X
. OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS AUTH=CRAM-MD5
AUTH=DIGEST-MD5 AUTH=LOGIN AUTH=PLAIN AUTH=OTP SASL-IR ACL
RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS
NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT
SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE
CATENATE CONDSTORE IDLE URLAUTH] User logged in
. list "" *
* LIST (\HasNoChildren) "." "INBOX"
. OK Completed (0.020 secs 2 calls)
. lsub "" *
* LSUB (\HasChildren) "." "INBOX"
* LSUB () "." "INBOX.2003"
* LSUB () "." "INBOX.2004"
* LSUB () "." "INBOX.2005"
* LSUB () "." "INBOX.2006"
* LSUB () "." "INBOX.Drafts"
* LSUB () "." "INBOX.Holidays"
* LSUB () "." "INBOX.Junk"
* LSUB () "." "INBOX.Sent"
* LSUB () "." "INBOX.Trash"
* LSUB () "." "INBOX.clamav"
* LSUB () "." "INBOX.macos"
* LSUB () "." "INBOX.pre-2003"
* LSUB () "." "INBOX.twonky"
* LSUB () "." "INBOX.xtension"
. OK Completed (0.030 secs 16 calls)
. examine INBOX
. NO Mailbox does not exist
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 IMAPd 2.3.10 Released
On 25 Oct 07, at 1230, Ian G Batten wrote: > > > I've just compiled 2.3.10 on batten.eu.org (my private x86 servers) > and although it looks OK on the Solaris 10 system, it's in deep > trouble on the elderly Linux machine. Both are upgrades from > 2.3.7, the Solaris box is a replication target, the Linux box is a > replication master that handles deliver and reading. The intent is > to swap them over, and that intent might come sooner than I planned. > > LSUB produces expected output, LIST doesn't (to put it mildly) and > examine/select can't select anything. strace on the running imapd > shows it's doing roughly sensible things: finding the correct > partition and metapartition from the mailbox database, opening the > metadata files correctly, but then it says NO. I've reconstructed > the mailbox, dumped and reloaded (ctl_mboxlist -d // ctl_mboxlist - > u) the mailboxes file and run reconstruct -G ``in case it makes any > odds''. No joy. And nothing useful in the logs, either... Re-installing 2.3.7 has everything back working again (apart from replication to the now-2.3.10 replication target: I assume 2.3.7 master, 2.3.10 replica isn't supported). The Linux machine is very, very old (2.4.20, but the userland is a massively patched and upgraded Redhat 7.1). Looking at master's logs on 2.3.10 shows a lot of imapd processes getting signal 11: I'm going to hunt for the coredumps and see what's causing the issue. The version of db is very old, but I'm not using any db format databases any more. [EMAIL PROTECTED] igb]$ ldd /usr/cyrus/bin/imapd libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x4002) libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x40032000) libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x40061000) libresolv.so.2 => /lib/libresolv.so.2 (0x40122000) libdb-3.1.so => /lib/libdb-3.1.so (0x40134000) libnsl.so.1 => /lib/libnsl.so.1 (0x401ad000) libc.so.6 => /lib/i686/libc.so.6 (0x401c4000) libdl.so.2 => /lib/libdl.so.2 (0x4030) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) [EMAIL PROTECTED] igb]$ [EMAIL PROTECTED] igb]$ cat /etc/imapd.conf configdirectory: /var/imap partition-default: /var/imap/messages metapartition_files: header index cache expunge squat metapartition-default: /var/imap/metadata sievedir: /var/imap/sieve imap_admins: offsite lmtp_admins: deliver sasl_pwcheck_method: auxprop expunge_mode: delayed imaps_tls_cert_file: /var/imap/certs/imap-cert.pem imaps_tls_key_file: /var/imap/certs/imap-private.pem imap_tls_cert_file: /var/imap/certs/imap-cert.pem imap_tls_key_file: /var/imap/certs/imap-private.pem # there is no STARTTLS for POP3, so this can only happen over port 995 pop3s_tls_cert_file: /var/imap/certs/pop-cert.pem pop3s_tls_key_file: /var/imap/certs/pop-private.pem # there is ONLY STARTTLS for LMTP, so the service name is always lmtp lmtp_tls_cert_file: disabled lmtp_tls_key_file: disabled # same for everyone tls_ca_path: /var/imap/certs/ca sasl_maximum_layer: 0 tls_cipher_list: RC4 idled_shutdown_check: 0 annotation_db: skiplist duplicate_db: skiplist mboxlist_db: skiplist ptscache_db: skiplist seenstate_db: skiplist subscription_db: skiplist tlscache_db: skiplist sync_host: offsite2.batten.eu.org sync_authname: X sync_realm: X sync_password: XX sync_machineid: 1 sync_log: 1 allowplaintext: 1 [EMAIL PROTECTED] igb]$ * OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=OTP SASL-IR] offsite.batten.eu.org Cyrus IMAP4 v2.3.7 server ready . login igb XX . OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID LOGINDISABLED ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE CATENATE CONDSTORE IDLE URLAUTH] User logged in . select INBOX * FLAGS (\Answered \Flagged \Draft \Deleted \Seen Junk NonJunk $MDNSent $NotJunk $Junk JunkRecorded $Forwarded $Label1 $Label2 $Label3 $Label4 $Label5) * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen Junk NonJunk $MDNSent $NotJunk $Junk JunkRecorded $Forwarded $Label1 $Label2 $Label3 $Label4 $Label5 \*)] * 2326 EXISTS * 0 RECENT * OK [UNSEEN 2325] * OK [UIDVALIDITY 1033487767] * OK [UIDNEXT 17663] * OK [NOMODSEQ] Sorry, modsequences have not been enabled on this mailbox . OK [READ-WRITE] Completed 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: [Annoyed] Cyrus-imapd/sasl upgrade and lmtpd behaviour...
On Mon, 30 Dec 2002, Scott Smith wrote: > group and put cyrus and MTA user in it. Or, you can run LMTP over TCP (keep > it on loopback) with SASL. I must confess that as a general rule I've given up on using AF_UNIX sockets now that we're all aware that running all daemons as root is A Bad Idea. By the time you've wrestled with permissions, setuid bits, setgid bits and all the rest, using TCP in loopback with some authentication mechanism is far easier to debug. Indeed, for a classic ``sealed box'' Cyrus setup, I'm not sure that just restricting lmtpd to 127.0.0.1 and using it unauthenticated is any weaker than having a Unix domain socket which sendmail can get at. ian
Re: SSL Update due to Security Advisory
On Mon, 24 Feb 2003, Peter Lawler wrote: > For those who may have missed it, > http://www.openssl.org/news/secadv_20030219.txt As a datapoint, although I could compile Cyrus against OpenSSL 0.9.7a and it appeared to work for imaps, both apache 1.3.27 and sendmail 8.12.7 didn't work correctly (coredump in EWP_update or something). I've backed out to OpenSSL 0.9.6i which fixes the vulnerability and also works with all the packages I need to link against. ian
Re: interesting limitation
On Mon, 31 Mar 2003, Dave O wrote: > > 2 level hashing would work, but I don't know if Cyrus supports that. It > would most likely be trivial to implement. > > eg spool/s/sm/user/smith spool/s/m/user/smith? ian
Re: cyrus server and backup
On Fri, 04 Apr 2003, Phil Chambers wrote: > I am concerned that because Cyrus is a "black box" system which keeps track of its > own internal organisation we may have problems if we restore a disc from our > backups. It will take hours to do a backup and the files within the Cyrus structure > will be changing as we do it. Are there going to be problems with inconsistencies > between files? There are two answers to this. The first is that doing snapshot backups should be possible on most plausible platforms, either by dropping a mirror off (requires mirroring, of course) or using fssnap (Sun) or LVM (Linux) to do a hot backup. The second is that in practice you can recover a mailbox by spinning on the files and then using reconstruct to rebuild the metadata. The worst you're going to do is break the unread flags and suchlike. > There is a secondary, but important use of our current backup service, which is to > dig users out of a hole when they make mistakes: Occasionally a user will > accidentally delete a message or even a whole folder and then come and ask if I can > recover it for them. We do that all the time. We pull the entire mailbox back, then grep for what the punter wants. > With our current backup system it is ussually very easy because I have no problem > identifying the relevant files to be recovered. I seems to that it will be > impossible to recover deleted messages because I will not be able to identify the > files which I need. If I can identify the files, presumably there is no way to get > them back into the Cyrus system? If you can identify them by size or date, you just put them back into the mailbox and reconstruct it. ian
Cyrus over NFS with _one_ instance
It has always been my understanding that Cyrus isn't supported over NFS. Clearly, getting locking working for the scenario of two machines running Cyrus sharing /var/imap is Very Hard. However, what if I only want to use _one_ instance of Cyrus, with failover (essentially, one Sun sat in front of a NetApp|Auspex|OtherNFSBox, with failover to another Sun if the first goes bang). Are there issues with Cyrus over NFS if the running copy of Cyrus has an assurance that it's the only writer? ian
Re: Large cyrus install surver
We've not upgraded for ages, and we must do so. But this should set an interesting lower floor on the amount of hardware you need. On Tue, 02 Dec 2003, [EMAIL PROTECTED] wrote: > The version(s) of Cyrus you are running 1.6.24 > The specs of the servers you have (cpu,mem,disk,os, etc) Sun Ultra 2, Solaris 7, 2x167MHz processors, 1.5GBytes RAM, two Fast/Wide SCSI controllers, 200GBytes of usable disk built from a mess of RAID 0+1 resulting from filesystem growth over the years: d18 -m d28 d38 -g 1 d28 3 2 c1t3d0s3 c1t4d0s3 -i 32b \ 2 c1t5d0s3 c1t6d0s3 -i 32b \ 4 c1t9d0s1 c1t10d0s1 c1t11d0s1 c1t12d0s1 -i 32b d38 3 2 c2t1d0s3 c2t2d0s3 -i 32b \ 2 c2t3d0s3 c2t4d0s3 -i 32b \ 4 c2t9d0s1 c2t10d0s1 c2t11d0s1 c2t12d0s1 -i 32b > How many accounts on each server. ~500 active > The average and peak number of users on each server at a time As of this minute 473 (load average 0.16, 0.25, 0.26), average about 400 during the day. Load average never seen to go even close to 1. > The average and peak number of messages in a folder for your users > (go ahead and estimate here...) Pass. But plenty of people have well in excess of 1000 in a single folder. > Are you using murder? If so, describe your proxies and mupdate server. No. ian
Re: Security of Cyrus IMAPd vs UofW IMAPd ...
On Wed, 14 Mar 2001, Rob Tanner wrote: > privileges. Since all the mailboxes are owned by the Cyrus user, what > would be more secure of a system that just does mail delivery woulkd > be a hack to sendmail so that once it attaches to port 25 it drops root > and runs as the Cyrus user. Show me a hack like that, and Cyrus wins > hands down (or two thumbs up) because you can't do that with UofW. Is there any reason you can't just use ``RunAsUser'' and run as cyrus? I run machine that do no local delivery as arbitrary users, and that works just fine. ian
timeout writing message to cyrus
I'm running 1.6.24 on a machine with RedHat 6.2. I routinely see the problem of messages being deferred because they timeout on their way into users' mailboxes. deliver is running via lmtp to allow vacation to work. Is this a known problem? Is there a cure? ian [igb@new-elo-relay igb]$ /usr/lib/sendmail -bp /var/spool/mqueue (7 requests) Q-ID --Size-- -Q-Time- Sender/Recipient f2TDOtx16640* 253768 Thu Mar 29 14:24 <[EMAIL PROTECTED]> 8BITMIME <[EMAIL PROTECTED]> f2SEH7x09929* 610640 Wed Mar 28 15:17 <[EMAIL PROTECTED]> 8BITMIME <[EMAIL PROTECTED]> f2TFgvx17839* 65736 Thu Mar 29 16:42 <[EMAIL PROTECTED]> (timeout writing message to cyrus) mpires f2TDYa016721* 169814 Thu Mar 29 15:14 MAILER-DAEMON (timeout writing message to cyrus) razenha f2TCYZ016265* 169147 Thu Mar 29 14:09 MAILER-DAEMON (timeout writing message to cyrus) razenha f2TA87x14861* 167497 Thu Mar 29 11:08 <[EMAIL PROTECTED]> 8BITMIME (timeout writing message to cyrus) jfazenda f2T8dZx14102* 166834 Thu Mar 29 09:39 <[EMAIL PROTECTED]> 8BITMIME (timeout writing message to cyrus) jfazenda [igb@new-elo-relay igb]$
Re: Apple Mail.app not playing nicely with Cyrus on large mailboxes
On Wed, 19 Jan 2005, Gregory Harris wrote: > Hi. Last Sunday I migrated all of my users mailboxes from a traditional > [...] > I have had a similar problem with one user that uses Ximian Evolution > 1.4.6. Same error message on the server side, on the client side, says I have only a tiny testcase to comment on, but I recently switched my mother from a Linux laptop using Evolution to an iBook using the Apple Mail app. I presume the latter is the latest version: the machine was delivered running 10.3.5 and I updated it to 10.3.7 immediately. Her mailbox resides on my private server, using Cyrus 2.2.8 on a fairly messy (2.4.20 kernel) Redhat installation. It's accessed via IMAP over a DSL connection. When she switched to the Apple, the first thing I helped her do was resync her mailbox and take offline copies, which meant that about two years of mail, including some large attachments, was downloaded. It appeared to work correctly. ian --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Cyrus on Linksys NSLU2
I've compiled 2.2.12 on a Linksys NSLU2. It appears to work --- I can rsync a mailbox on from a Sun and access it correctly. I've also got Sendmail 8.13.3 built and awaiting a config file, so I can start delivering mail to the slug soonest. I have real work for this, honest, and it's not just geekery: we want low-maintenance mail servers in our branch offices. I did the compilation actually on the slug, as building a cross-compilation environment faithful enough to handle a full-scale configure, especially given my preferred development environment being Solaris 10 on Sparc, seemed too much like hard work. I had to hack a few bits and pieces to get it to build, notably xversion.sh (as perl isn't present, awk appears to be somewhat broken, printf is missing and echo doesn't have \n properly). Obviously I haven't got perl, so I skipped the cyradm build. xversion.sh reads as follows: #!/bin/sh echo "/* Generated automatically by xversion.sh */" > xversion.h echo "#define CYRUS_CVSDATE \"unknown\"" >> xversion.h It loses versioning information, obviously. I'll write a better solution in C when I have a chance. Also, a `make clean' is a bit of a catastrophe, as some things are supplied in the source kit that are scrubbed by a clean and require perl to rebuild (imapopts, notably). I used ipkg to install a whole stack of stuff: diffutils, the compilers, ssl, sasl, db and so on. The slug I'm compiling and testing on has the following packages installed: cpio crosstool-native-arch-bin crosstool-native-arch-inc crosstool-native-arch-lib crosstool-native-bin crosstool-native-inc crosstool-native-lib cyrus-sasl diffutils findutils ipkg less libc6-unslung libdb libgcc libipkg m4 make ncurses nfs-utils nslu2-linksys-libs ntpclient openssh openssl portmap rsync slingbox strace unslung-standard-rootfs wget zlib Not all are required for the build, but I'm not about to start randomly removing packages and seeing if it'll still build! The compilation was done with: # CC=/opt/armeb/bin/armv5b-softfloat-linux-gcc export CC # CFLAGS=-O export CFLAGS # ./configure --build=armv5b-softfloat-linux \ --with-bdb-libdir=/opt/lib --with-bdb-incdir=/opt/include \ --without-perl --with-cyrus-user=mail --with-cyrus-group=mail \ --prefix=/opt/cyrus --with-cyrus-prefix=/opt/cyrus # make I used mail:mail as the uid because it's there, and adding users into /etc/passed is painful on a slug. /opt/cyrus isn't big enough (unless you're using non-standard partitioning) so I made it a symlink into /share/hdd/data/cyrus. ian --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
