Re: 2.3 to 2.4 Murder upgrade
On Thu, Dec 08, 2011 at 12:20:38PM -0800, Andrew Morgan wrote: Okay. Is there any harm not suppressing URLAUTH=BINARY? :) Maybe issues with Nokia phones... Otherwise you should be OK. You can apply this patch if you need: http://git.cyrusimap.org/cyrus-imapd/commit/?id=6bebf41d13f046ba41a859ab58de45098e76099d Bron. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: 2.3 to 2.4 Murder upgrade
On Tue, 6 Dec 2011, Dave McMurtrie wrote: On 12/06/2011 05:48 PM, Andrew Morgan wrote: On Fri, 14 Oct 2011, Dave McMurtrie wrote: ...snipped... Upgrading from 2.4.5 New config option: suppress_capabilities, which takes a space separated list of capabilities which will NOT be given in any imap capability response. This can be used on frontends to not display capabilities that older backends don't have, so clients don't get confused This leads me to believe that I should upgrade the backends to 2.4 first. Is that true? Has anyone done a Murder upgrade from 2.3 to 2.4 and can tell me what order they upgraded the hosts? Yes, you'll want to upgrade the frontends first and suppress the new capabilities on the frontends that the old backends aren't yet aware of. I should have mentioned the reason why we did the frontends first for the benefit of anyone else who is searching for this information. You need to do the frontends first because as of 2.4, the backends will (correctly) return the NoSelect flag for any remote folders that you're subscribed to in an LSUB response. This is most common with shared folders, where the shared folder may not be on the same backend as the user's Inbox. The 2.4 frontends will know to scrub the NoSelect flag in this case. Hmmm, how do I know which capabilities to suppress? Should I just compare the CAPABILITY response from a 2.3 and a 2.4 server? We used: suppress_capabilities: ESEARCH QRESYNC WITHIN but your idea is perfectly cromulent, also. I compared the CAPABILITY response between 2.3 and 2.4 frontends after TLS was negotiated and found the following differences: ENABLE ESEARCH IMAP4 LIST-EXTENDED QRESYNC SORT=DISPLAY URLAUTH=BINARY WITHIN XLIST So, I tried adding all the new 2.4 capabilities to the suppress_capabilities setting. I found that if I added URLAUTH=BINARY to suppress_capabilities, I was unable to establish an IMAP connection to the frontend. imtest didn't print any output, and proxyd on the frontend was spinning at 100% cpu. If I remove URLAUTH=BINARY from suppress_capabilities, leaving all the other new capabilities suppressed, it works fine. I'm not sure if this is a bug... Let me know if I should file it as a bug. So that leaves the following capabilities suppressed: suppress_capabilities: ESEARCH LIST-EXTENDED QRESYNC WITHIN XLIST ENABLE SORT=DISPLAY The imapd.conf manpage says I only need: suppress_capabilities: ESEARCH QRESYNC WITHIN XLIST LIST-EXTENDED if I have 2.3 murder backends. Is that correct, or should I suppress the new ENABLE and SORT=DISPLAY too? Thanks, Andy Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: 2.3 to 2.4 Murder upgrade
On Thu, Dec 08, 2011 at 10:00:26AM -0800, Andrew Morgan wrote: So, I tried adding all the new 2.4 capabilities to the suppress_capabilities setting. I found that if I added URLAUTH=BINARY to suppress_capabilities, I was unable to establish an IMAP connection to the frontend. imtest didn't print any output, and proxyd on the frontend was spinning at 100% cpu. If I remove URLAUTH=BINARY from suppress_capabilities, leaving all the other new capabilities suppressed, it works fine. I'm not sure if this is a bug... Let me know if I should file it as a bug. Meep - sorry, it's a bug. Fixed on master. I really REALLY need to take some time fixing stable. suppress_capabilities: ESEARCH LIST-EXTENDED QRESYNC WITHIN XLIST ENABLE SORT=DISPLAY The imapd.conf manpage says I only need: suppress_capabilities: ESEARCH QRESYNC WITHIN XLIST LIST-EXTENDED if I have 2.3 murder backends. Is that correct, or should I suppress the new ENABLE and SORT=DISPLAY too? Probably should suppress SORT=DISPLAY. That's even newer than the imapd.conf docs! I think ENABLE is OK, because clients are expected to handle NO responses. Bron. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: 2.3 to 2.4 Murder upgrade
On Thu, 8 Dec 2011, Bron Gondwana wrote: On Thu, Dec 08, 2011 at 10:00:26AM -0800, Andrew Morgan wrote: So, I tried adding all the new 2.4 capabilities to the suppress_capabilities setting. I found that if I added URLAUTH=BINARY to suppress_capabilities, I was unable to establish an IMAP connection to the frontend. imtest didn't print any output, and proxyd on the frontend was spinning at 100% cpu. If I remove URLAUTH=BINARY from suppress_capabilities, leaving all the other new capabilities suppressed, it works fine. I'm not sure if this is a bug... Let me know if I should file it as a bug. Meep - sorry, it's a bug. Fixed on master. I really REALLY need to take some time fixing stable. suppress_capabilities: ESEARCH LIST-EXTENDED QRESYNC WITHIN XLIST ENABLE SORT=DISPLAY The imapd.conf manpage says I only need: suppress_capabilities: ESEARCH QRESYNC WITHIN XLIST LIST-EXTENDED if I have 2.3 murder backends. Is that correct, or should I suppress the new ENABLE and SORT=DISPLAY too? Probably should suppress SORT=DISPLAY. That's even newer than the imapd.conf docs! I think ENABLE is OK, because clients are expected to handle NO responses. Okay. Is there any harm not suppressing URLAUTH=BINARY? :) Andy Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: 2.3 to 2.4 Murder upgrade
On 12/08/2011 03:20 PM, Andrew Morgan wrote: On Thu, 8 Dec 2011, Bron Gondwana wrote: On Thu, Dec 08, 2011 at 10:00:26AM -0800, Andrew Morgan wrote: So, I tried adding all the new 2.4 capabilities to the suppress_capabilities setting. I found that if I added URLAUTH=BINARY to suppress_capabilities, I was unable to establish an IMAP connection to the frontend. imtest didn't print any output, and proxyd on the frontend was spinning at 100% cpu. If I remove URLAUTH=BINARY from suppress_capabilities, leaving all the other new capabilities suppressed, it works fine. I'm not sure if this is a bug... Let me know if I should file it as a bug. Meep - sorry, it's a bug. Fixed on master. I really REALLY need to take some time fixing stable. suppress_capabilities: ESEARCH LIST-EXTENDED QRESYNC WITHIN XLIST ENABLE SORT=DISPLAY The imapd.conf manpage says I only need: suppress_capabilities: ESEARCH QRESYNC WITHIN XLIST LIST-EXTENDED if I have 2.3 murder backends. Is that correct, or should I suppress the new ENABLE and SORT=DISPLAY too? Probably should suppress SORT=DISPLAY. That's even newer than the imapd.conf docs! I think ENABLE is OK, because clients are expected to handle NO responses. Okay. Is there any harm not suppressing URLAUTH=BINARY? :) I'm not aware of any clients that use it, so it probably doesn't matter if it's offered as a capability. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: 2.3 to 2.4 Murder upgrade
On Fri, 14 Oct 2011, Dave McMurtrie wrote: On Oct 14, 2011, at 7:16 PM, Andrew Morgan mor...@orst.edu wrote: I finally have some time to work on upgrading our Cyrus Murder installation from 2.3.16 to 2.4.12. We have 3 backends, 3 frontends, and a mupdate master, all separate systems. When I upgraded from 2.2 to 2.3, I had to upgrade the backends first. Otherwise, the 2.3 frontends would issue commands that the 2.2 backends didn't know yet. I see the following note in the install-upgrade guide: Upgrading from 2.4.5 New config option: suppress_capabilities, which takes a space separated list of capabilities which will NOT be given in any imap capability response. This can be used on frontends to not display capabilities that older backends don't have, so clients don't get confused This leads me to believe that I should upgrade the backends to 2.4 first. Is that true? Has anyone done a Murder upgrade from 2.3 to 2.4 and can tell me what order they upgraded the hosts? Yes, you'll want to upgrade the frontends first and suppress the new capabilities on the frontends that the old backends aren't yet aware of. Hmmm, how do I know which capabilities to suppress? Should I just compare the CAPABILITY response from a 2.3 and a 2.4 server? Thanks, Andy Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: 2.3 to 2.4 Murder upgrade
On 12/06/2011 05:48 PM, Andrew Morgan wrote: On Fri, 14 Oct 2011, Dave McMurtrie wrote: ...snipped... Upgrading from 2.4.5 New config option: suppress_capabilities, which takes a space separated list of capabilities which will NOT be given in any imap capability response. This can be used on frontends to not display capabilities that older backends don't have, so clients don't get confused This leads me to believe that I should upgrade the backends to 2.4 first. Is that true? Has anyone done a Murder upgrade from 2.3 to 2.4 and can tell me what order they upgraded the hosts? Yes, you'll want to upgrade the frontends first and suppress the new capabilities on the frontends that the old backends aren't yet aware of. I should have mentioned the reason why we did the frontends first for the benefit of anyone else who is searching for this information. You need to do the frontends first because as of 2.4, the backends will (correctly) return the NoSelect flag for any remote folders that you're subscribed to in an LSUB response. This is most common with shared folders, where the shared folder may not be on the same backend as the user's Inbox. The 2.4 frontends will know to scrub the NoSelect flag in this case. Hmmm, how do I know which capabilities to suppress? Should I just compare the CAPABILITY response from a 2.3 and a 2.4 server? We used: suppress_capabilities: ESEARCH QRESYNC WITHIN but your idea is perfectly cromulent, also. HTH, Dave Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
2.3 to 2.4 Murder upgrade
I finally have some time to work on upgrading our Cyrus Murder installation from 2.3.16 to 2.4.12. We have 3 backends, 3 frontends, and a mupdate master, all separate systems. When I upgraded from 2.2 to 2.3, I had to upgrade the backends first. Otherwise, the 2.3 frontends would issue commands that the 2.2 backends didn't know yet. I see the following note in the install-upgrade guide: Upgrading from 2.4.5 New config option: suppress_capabilities, which takes a space separated list of capabilities which will NOT be given in any imap capability response. This can be used on frontends to not display capabilities that older backends don't have, so clients don't get confused This leads me to believe that I should upgrade the backends to 2.4 first. Is that true? Has anyone done a Murder upgrade from 2.3 to 2.4 and can tell me what order they upgraded the hosts? Thanks! Andy Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: 2.3 to 2.4 Murder upgrade
On Oct 14, 2011, at 7:16 PM, Andrew Morgan mor...@orst.edu wrote: I finally have some time to work on upgrading our Cyrus Murder installation from 2.3.16 to 2.4.12. We have 3 backends, 3 frontends, and a mupdate master, all separate systems. When I upgraded from 2.2 to 2.3, I had to upgrade the backends first. Otherwise, the 2.3 frontends would issue commands that the 2.2 backends didn't know yet. I see the following note in the install-upgrade guide: Upgrading from 2.4.5 New config option: suppress_capabilities, which takes a space separated list of capabilities which will NOT be given in any imap capability response. This can be used on frontends to not display capabilities that older backends don't have, so clients don't get confused This leads me to believe that I should upgrade the backends to 2.4 first. Is that true? Has anyone done a Murder upgrade from 2.3 to 2.4 and can tell me what order they upgraded the hosts? Yes, you'll want to upgrade the frontends first and suppress the new capabilities on the frontends that the old backends aren't yet aware of. hth, Dave Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
