Cyrus Caldav Murder integration
Hi, After successfully tested Cyrus IMAPD v2.4.17-caldav on a stand-alone Cyrus IMAP server, I wonder how to integrate CalDAV features in our running Imap systems. We're currently using 2 murder hosts and 4 backend servers, running in a cluster (Solaris) environment. Users mailboxes are distributed on 4 backends and I plan to offer caldendars to those users. I understand that the CalDAV module will automatically create the required calendars for a user the first time that the user authenticates to the CalDAV server; but what's happen if mailboxes are located on different backends ? - Do I have to configure CalDAV server only on the murder agreggator hosts ? - Is there (or in the future) such a proxy mode for http services (or referrals like sieve) ? - Or shall I consider using a separate Cyrus Caldav server acting as stand-alone calendar server with LOCAL mailboxes containing ONLY CAL information? Of course I'd like to published only one calendar url for all. Thanks. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Cyrus Caldav Murder integration
On 06/05/2014 05:33 AM, Jean-Christophe Delaye wrote: Hi, After successfully tested Cyrus IMAPD v2.4.17-caldav on a stand-alone Cyrus IMAP server, I wonder how to integrate CalDAV features in our running Imap systems. We're currently using 2 murder hosts and 4 backend servers, running in a cluster (Solaris) environment. Users mailboxes are distributed on 4 backends and I plan to offer caldendars to those users. I understand that the CalDAV module will automatically create the required calendars for a user the first time that the user authenticates to the CalDAV server; but what's happen if mailboxes are located on different backends ? - Do I have to configure CalDAV server only on the murder agreggator hosts ? - Is there (or in the future) such a proxy mode for http services (or referrals like sieve) ? - Or shall I consider using a separate Cyrus Caldav server acting as stand-alone calendar server with LOCAL mailboxes containing ONLY CAL information? The setup for CalDAV Murder is the same as for IMAP. Run httpd processes on both the frontend and backend servers. httpd will proxy the requests to the proper backend. CMU is currently doing this for RSS access to shared mailboxes on our production Murder and I have been using CalDAV on our test Murder for well over a year. That being said, I can't guarantee that CalDAV auto-scheduling will work between users on different backends. Best-case, the backend server will send an email, worst-case it will fail to store the scheduling object. I haven't done a lot of scheduling testing in a Murder environment yet. I might have to rework the scheduling code so that the frontend machine directs the traffic to various backends. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
xfer problems between 2.3.15 and 2.4.17
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 small number of accounts on our older backends that had corrupt cyrus.index files. However we are now having trouble configuring frontends that will work with this mixed murder environment while we xfer our users accross. If we use our existing 2.3.15 frontends then users have who have been migrated lose the ability to see other accounts in the Other Users name space. On the other hand if we introduce 2.4.17 frontends then we see strange behaviour around folder creation. Clients can create the folders but autosubscription fails with the client being told the new folder doesn't exist. If one waits a minute or two one can manually subscribe to the folder. So far we have not upgraded the mupdate master. Is this a mistake? In terms of the frontend config we have added suppress_capabilities: ESEARCH QRESYNC WITHIN XLIST LIST-EXTENDED to the 2.4.17 frontends, otherwise the config is identical to our 2.3.15 frontends. Is there any other config changes we should be aware of? any ideas greatly appreciated... Gavin Gray Edinburgh University Information Services Rm 2013 JCMB Kings Buildings Edinburgh EH9 3JZ UK tel +44 (0)131 650 5987 email gavin.g...@ed.ac.uk -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: xfer problems between 2.3.15 and 2.4.17
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 between these backends. The problems we had appear to have been with a very small number of accounts on our older backends that had corrupt cyrus.index files. However we are now having trouble configuring frontends that will work with this mixed murder environment while we xfer our users accross. If we use our existing 2.3.15 frontends then users have who have been migrated lose the ability to see other accounts in the Other Users name space. On the other hand if we introduce 2.4.17 frontends then we see strange behaviour around folder creation. Clients can create the folders but autosubscription fails with the client being told the new folder doesn't exist. If one waits a minute or two one can manually subscribe to the folder. So far we have not upgraded the mupdate master. Is this a mistake? In terms of the frontend config we have added suppress_capabilities: ESEARCH QRESYNC WITHIN XLIST LIST-EXTENDED to the 2.4.17 frontends, otherwise the config is identical to our 2.3.15 frontends. Is there any other config changes we should be aware of? any ideas greatly appreciated... What you're doing should work just fine. It's exactly what we did to migrate our murder environment from 2.3.x to 2.4.x. I think I posted to the info-cyrus list about how we upgraded, but maybe I didn't. I got all the 2.4 backend servers built and ready to go, then I upgraded all the frontends to 2.4, then I used XFER to move all the mail from 2.3 to 2.4 servers. I don't recall exactly when I upgraded our mupdate server, but I don't think it matters. I don't believe anything changed in mupdate protocol or in the mailbox.db format between 2.3 and 2.4. Have you tried grabbing telemetry on the 2.4 server when the subscription fails? Is there anything being logged? Thanks! Dave Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: xfer problems between 2.3.15 and 2.4.17
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 backends. The problems we had appear to have been with a very small number of accounts on our older backends that had corrupt cyrus.index files. However we are now having trouble configuring frontends that will work with this mixed murder environment while we xfer our users accross. If we use our existing 2.3.15 frontends then users have who have been migrated lose the ability to see other accounts in the Other Users name space. On the other hand if we introduce 2.4.17 frontends then we see strange behaviour around folder creation. Clients can create the folders but autosubscription fails with the client being told the new folder doesn't exist. If one waits a minute or two one can manually subscribe to the folder. This is tickling my memory, but I can't recall exactly what it was. I remember running into a problem like this as well. Something about the frontend's mailbox database not being updated in a timely fashion... So far we have not upgraded the mupdate master. Is this a mistake? In terms of the frontend config we have added suppress_capabilities: ESEARCH QRESYNC WITHIN XLIST LIST-EXTENDED to the 2.4.17 frontends, otherwise the config is identical to our 2.3.15 frontends. Is there any other config changes we should be aware of? I used the following when I upgraded from 2.3 to 2.4: suppress_capabilities: ESEARCH LIST-EXTENDED QRESYNC WITHIN XLIST ENABLE SORT=DISPLAY There was a thread I started back in October 2011 with the subject 2.3 to 2.4 Murder upgrade where I ran through the upgrade and the workarounds I had to make. Andy Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
