Hi all,
We just have done a migration from a very old Cyrus stand alone
installation to a new one with murder.
During the migration everything went ok and no user complaint, so we
destroy our old mailbox.
Shortly after that one of our user notice a huge problem with outlook
that we don't
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
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
Joseph Brennan wrote:
--On Tuesday, October 9, 2007 14:19 +0100 Ian G Batten
[EMAIL PROTECTED] wrote:
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 have
What's your authentication authorization infrastructure look like?
Every mailbox has an associated ACL, which must be canonicalized to
determine whether the user in question gets to see it. ctl_mboxlist
just lists whatever it finds. I've seen Kerberos cause LIST * to
take a long time
I'm trying to setup a murder with 3 machines for testing.
(mupdated, fe, and be all separate machines)
The mupdate master works fine, the backend can do the initial dump/import to
the master (and mupdatetest works on the backend and frontend)
The front end however doesn't seem to be able to
On 09 Oct 07, at 1550, Wesley Craig wrote:
What's your authentication authorization infrastructure look like?
sasl into yellow pages.
Every mailbox has an associated ACL, which must be canonicalized to
determine whether the user in question gets to see it.
ctl_mboxlist just lists
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
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
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
Ian G Batten [EMAIL PROTECTED] 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.
On Tue, 9 Oct 2007, Guillaume Postaire wrote:
Hi all,
We just have done a migration from a very old Cyrus stand alone
installation to a new one with murder.
During the migration everything went ok and no user complaint, so we
destroy our old mailbox.
Shortly after that one of our user
I'll put in my 10cents as it's not really on topic for this mailing list.
When converting from a qmail+courier IMAP solution to Zimbra *ugh* I had
a similar problem in this case Zimbra had a solution.
imapsync --ssl1 --ssl2 --host1 #HOST1# --host2 #HOST2# \
--authuser1 cyrus --password1
So I want to do LMTP between an MX pool and Cyrus backends.
The common way I read about doing this, is with a shared LMTP
account from MX pool to backends. So it becomes a postman sort
of account with the password in plaintext in various places and of
course transiting the network that way.
Is
On Sat, 6 Oct 2007, Rob Mueller wrote:
As it turns out, the memory leaks weren't critical, because the the pages do
seem to be reclaimed when needed, though it was annoying not knowing exactly
how much memory was really free/used. The biggest problem was that with
cyrus you have millions of
On Tue, 9 Oct 2007, Andrew Morgan wrote:
On Sat, 6 Oct 2007, Rob Mueller wrote:
As it turns out, the memory leaks weren't critical, because the the pages do
seem to be reclaimed when needed, though it was annoying not knowing exactly
how much memory was really free/used. The biggest problem
Yesterday I checked my own Cyrus servers to see if I was running out of
lowmem, and it sure looked like it. Lowmem had only a couple MB free, and
I had 2GB of free memory that was not being used for cache.
I checked again today and everything seems to be fine - 150MB of lowmem
free and
On Tue, 09 Oct 2007 15:04:32 -0700, Vincent Fox [EMAIL PROTECTED] wrote:
So I want to do LMTP between an MX pool and Cyrus backends.
The common way I read about doing this, is with a shared LMTP
account from MX pool to backends. So it becomes a postman sort
of account with the password in
On Sep 28, 2007, at 5:29 AM, Nikos Gatsis wrote:
It's the first time that I've install the cyrus-imap on a fedora 7
server.
So, I'm very new with cyrus.
I'd like to set a vacation message for each user and I don't find a
way.
Can you help me?
No, and please nobody do. Vacation messages
You can also use
vm.lower_zone_protection=size_in_mb
to protect portions of low memory. This doesn't help with caching issues but
can help prevent the kernel from getting cornered and resorting to oom-killer.
We haven't tested everything in our enviroment at 64bit so we've used lower
zone
There's no really easy way, but this patch might help. Basically it parses
the last Received: header to set the internal date.
http://cyrus.brong.fastmail.fm/#cyrus-receivedtime-2.3.8.diff
The problem is if you apply it, you then have to reconstruct all your
mailboxes to rebuild the
21 matches
Mail list logo
