Re: How to make sync_client invoke STARTTLS for replication
On 06/01/2010 03:53 PM, Wesley Craig wrote: On 01 Jun 2010, at 05:09, Rudy Gevaert wrote: Can you tell me how to further troubleshoot, please? sync_client ought to syslog any error that backend_connect() gets. Helo Wesley, Sorry, I forgot about reporting it: replica side: Jun 3 10:40:12 cyrdev2 maild1r/syncserver[9595]: accepted connection Jun 3 10:40:12 cyrdev2 maild1r/syncserver[9595]: cmdloop(): startup Jun 3 10:40:12 cyrdev2 maild1r/syncserver[9595]: SSL_accept() incomplete - wait Jun 3 10:40:12 cyrdev2 maild1r/syncserver[9595]: SSL_accept() succeeded - done master side: Jun 3 10:39:12 cyrdev1 maild1/sync_client[3519]: starttls: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits new client) no authentication Jun 3 10:40:12 cyrdev1 maild1/sync_client[3519]: Doing a peer verify Jun 3 10:40:12 cyrdev1 maild1/sync_client[3519]: Doing a peer verify Jun 3 10:40:12 cyrdev1 maild1/sync_client[3519]: Doing a peer verify Jun 3 10:40:12 cyrdev1 maild1/sync_client[3519]: Doing a peer verify Jun 3 10:40:12 cyrdev1 maild1/sync_client[3519]: received server certificate Jun 3 10:40:12 cyrdev1 maild1/sync_client[3519]: starttls: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits new client) no authentication How can I further debug? Thanks! 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
intermittent problems with kick_mupdate
Hi there, We are busy migrating lots of users to new backends in our cyrus murder using xfer. The existing backends (and the rest of the murder) are cyrus 2.2 where as the new backend machines are cyrus 2.3.15. Mostly everything works just fine. However every now and them our new backends fail to connect to our mupdate server at the start of an xfer. We see the new backend log into the mupdate server, but then a subsequent call to kick_mupdate fails and consequently so does the xfer:- The error on the originating backend for the failed xfer is: The remote Server(s) denied the operation The error on the new backend receiving the error is: kick_mupdate: can't connect to target: No such file or directory the underlying OS of the new backend is openSolaris any thoughts? -- 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. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. 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: intermittent problems with kick_mupdate
Forgot to mention the more specific errors we have seen on the backends we're moving users from: imap[29289]: [ID 886451 local6.error] Could not trigger remote push to mupdate serverduring move of user... and imap[22505]: [ID 772019 local6.error] Could not set remote acl on user Quoting Gavin Gray gavin.g...@ed.ac.uk: Hi there, We are busy migrating lots of users to new backends in our cyrus murder using xfer. The existing backends (and the rest of the murder) are cyrus 2.2 where as the new backend machines are cyrus 2.3.15. Mostly everything works just fine. However every now and them our new backends fail to connect to our mupdate server at the start of an xfer. We see the new backend log into the mupdate server, but then a subsequent call to kick_mupdate fails and consequently so does the xfer:- The error on the originating backend for the failed xfer is: The remote Server(s) denied the operation The error on the new backend receiving the error is: kick_mupdate: can't connect to target: No such file or directory the underlying OS of the new backend is openSolaris any thoughts? -- 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. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. 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 -- 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. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. 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: intermittent problems with kick_mupdate
On 03 Jun 2010, at 09:24, Gavin Gray wrote: imap[29289]: [ID 886451 local6.error] Could not trigger remote push to mupdate serverduring move of user... During the xfer, the local backend sets some information in the mupdate master WRT the new mailbox location. However, this information may be a bit of a guess. The MUPDATEPUSH instructs the remote backend to set whatever the correct information is in the mupdate master. Stupidly, the above log doesn't report what the problem was, and neither does the remote backend. That should be fixed (can you open a bug report?). However, the error is not fatal. imap[22505]: [ID 772019 local6.error] Could not set remote acl on user This error is fatal. In fact, you ought to not execute the following MUPDATEPUSH, because not being able to set the ACL is not permissible. Perhaps you're seeing this problem: https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=3218 Of course, the logging again fails to tell us *why* we aren't able to set the remote ACL (another good opportunity to report a bug). The error on the new backend receiving the error is: kick_mupdate: can't connect to target: No such file or directory Is this a unified murder? Skimming imapd.c, I see a mix of calls to kick_mupdate(), some protected by checks for the type of murder, some not. Perhaps that's the problem. In any case, kick_mupdate() is void, so errors relating to it are probably cascades from some other failed step in the process. :wes 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
