this fix, detailed below, has indeed solved our problem with folder
creation on our new 2.4.17 frontends.
many thanks
On Tue, 10 Jun 2014, Andrew Morgan wrote:
> On Tue, 10 Jun 2014, gavin.g...@ed.ac.uk wrote:
>
>> Hi Wes,
>>
>> It looks like the whole mupdate thing is working perfectly well.
On Tue, 10 Jun 2014, gavin.g...@ed.ac.uk wrote:
> Hi Wes,
>
> It looks like the whole mupdate thing is working perfectly well.
> If I create a folder while connected to my 2.4.17 frontend then the logs show
> the backend issuing the cmd_set and then a bunch of cmd_find going out
> including to t
Hi Wes,
It looks like the whole mupdate thing is working perfectly well.
If I create a folder while connected to my 2.4.17 frontend then the logs
show the backend issuing the cmd_set and then a bunch of cmd_find going
out including to the frontend in question. Furthermore the new folder
really
I've switched to debug logging now on our mupdate master,
thanks
On Mon, 9 Jun 2014, Wesley Craig wrote:
> On 09 Jun 2014, at 07:14, gavin.g...@ed.ac.uk wrote:
>> Actually we get very little logged on our mupdate master, just logins,
>> checkpointing notices etc, nothing about the work done t
sorry I should've been more explicit, we also have the same thing in our
backend's imapd.conf
On Tue, 10 Jun 2014, Michael Menge wrote:
Hi,
Quoting gavin.g...@ed.ac.uk:
yes we have
allowallsubscribe: yes
in our frontend imapd.conf
the man page mentions backend servers
thanks
On Tue,
Hi,
Quoting gavin.g...@ed.ac.uk:
yes we have
allowallsubscribe: yes
in our frontend imapd.conf
the man page mentions backend servers
thanks
On Tue, 10 Jun 2014, Michael Menge wrote:
Hi,
did you use allowallsubscribe in your imapd.conf?
copied from imapd.conf manpage
allowallsubscri
yes we have
allowallsubscribe: yes
in our frontend imapd.conf
thanks
On Tue, 10 Jun 2014, Michael Menge wrote:
Hi,
did you use allowallsubscribe in your imapd.conf?
copied from imapd.conf manpage
allowallsubscribe: 0
Allow subscription to nonexistent mailboxes. This option is typic
Hi,
did you use allowallsubscribe in your imapd.conf?
copied from imapd.conf manpage
allowallsubscribe: 0
Allow subscription to nonexistent mailboxes. This option is typically
used on backend servers in a Murder so that users can subscribe to
mailboxes that don't reside on
Actually we get very little logged on our mupdate master, just logins,
checkpointing notices etc, nothing about the work done to maintain
folder state. It's one of the reasons we feel so in the dark with this
issue.
On Sat, 7 Jun 2014, Wesley Craig wrote:
> On 07 Jun 2014, at 14:49, Gavin Gray
yes it looks like for some reason the mupdate procedure that happens within the
murder upon folder creation is getting held up for some reason with regard to
the 2.4 frontend. but we don't know why or how to correct it.
thanks for getting back to us,
Quoting Andrew Morgan on Thu, 5 Jun 2014 11
All we see is the request from the client to subscrobe to the newly created
folder failing for the reason that, the mailbox does not exist. we get this
from logging the client's imap session.
thanks,
Gavin
Quoting Dave McMurtrie on Thu, 5 Jun 2014 16:18:16
+:
> On Thu, 2014-06-05 at 16:
On Thu, 5 Jun 2014, gavin.g...@ed.ac.uk wrote:
> As you may be aware we are attempting this and have run into various
> problems.
>
> Currently we have a mixed murder of 2.3.15 backends and 2.4.17 backends.
> We are now fairly confident that we can xfer accounts succesfully between
> these backend
On Thu, 2014-06-05 at 16:15 +0100, gavin.g...@ed.ac.uk wrote:
> As you may be aware we are attempting this and have run into various
> problems.
>
> Currently we have a mixed murder of 2.3.15 backends and 2.4.17 backends.
> We are now fairly confident that we can xfer accounts succesfully betwee
As you may be aware we are attempting this and have run into various
problems.
Currently we have a mixed murder of 2.3.15 backends and 2.4.17 backends.
We are now fairly confident that we can xfer accounts succesfully between
these backends. The problems we had appear to have been with a very s
So I'm going to attach the cyrus metadata files for a folder that behaved
the way I am describing having been xfer'd between 2.3.15 and 2.4.17.
these are the files from the source server ie the 2.3.15 backend.
If anyone with far deeper knowledge of cyrus than we do, could have a look
to see if
Thanks Ken,
We have tried the -G and -R options to no avail. I've begun to experiment
with your seen database idea. It would be nice to discover the reason for
the corruption. We still don't even know whether the problem was there
before the xfer or if it's a result of the xfer process. Obvious
Hi Gavin,
Have you tried running reconstruct with the -G and/or -R options to see
if they fix the corruption without having to remove cyrus.index?
Another option is to place a copy of the user's .seen file from
the 2.3 machine on the 2.4 machine prior to removing cyrus.index and
reconstructing
Any help with this would be much appreciated.
We keep coming across folders that once they have been migrated seem to
have corrupt cyrus.index files. The only way to fix them is to remove the
files and do a reconstruct. This is not a workable solution from our users
point of view as is sets all
I have been testing xfer of accounts within a cyrus murder from 2.3.15
backends to new 2.4.17. backends.
all the email and folders seem to migrate perfectly and the xfer'd
accounts can send and receive email. However when reading email with an
IMAP client I am having strange issues setting flag
19 matches
Mail list logo
