Re: Cyrus IMAPd 2.3.10 Released
On Sun, Nov 04, 2007 at 07:19:26PM -0800, Rich Wales wrote: What is the current status of 2.3.10? Right after it was announced a couple of weeks ago, I saw some people reporting problems. Are there any patches? Or is 2.3.10 still believed to be OK as is? I'm running 2.3.9 on a FreeBSD 6.2 master and an Ubuntu 7.10 replica server setup, and I want to upgrade to 2.3.10 in hopes of getting rid of some problems with the sync code intermittently crashing, but this is a production system, and I don't feel comfortable upgrading to 2.3.10 as long as there are unresolved serious bug reports. FastMail is running 2.3.10 on all our production systems now, and there are no regressions that I'm aware of. There are still some bugs that also existed in 2.3.9, but we aren't patching against any bugs rather than things that don't work how we would prefer. The two big new bugs that we found in the 2.3.10pre3 codebase when we rolled that out into production had their fixes accepted back upstream before the final 2.3.10 was cut. That said, we're seeing slightly more skiplist corruption than previously and have not yet determined the cause. We're backing up a text-dump of our mailboxes.db files once per hour just in case - but it's highly probable that the issues are due to something odd we're doing with long running cyr_dbtool processes. Bron. 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: Deleting top-level mailbox with 'delete_mode: delayed'
On Fri, Nov 02, 2007 at 01:15:37PM -0400, Brian Wong wrote: On Nov 2, 2007 12:39 PM, Rudy Gevaert [EMAIL PROTECTED] wrote: Brian Wong wrote: I was testing out Cyrus 2.3.10 and realized that when I set the option delete_mode: delayed I can not delete top-level mailboxes. localhost.localdomain lm localhost.localdomain cm user.bwong localhost.localdomain sam user.bwong admin_account c localhost.localdomain dm user.bwong deletemailbox: Operation is not supported on mailbox localhost.localdomain lm user.bwong (\HasNoChildren) Disabling the delayed delete gives expected results. The mailbox is deleted as normal. Anyone else confirm this? I'm just back from holiday (and only catching up on mail). I always set the 'x' permission. Could you try that? If that doesn't work, I'll try to delete a top level mailbox on Monday (I'm running 2.3.10 in test). Rudy localhost.localdomain lam user.bwong bwong lrswipkxtecda admin kxc localhost.localdomain dm user.bwong deletemailbox: Operation is not supported on mailbox I think if I did not have the right to delete the mailbox, I would get a Permission Denied instead of the error I am receiving. Let me know what you find when you try it. I feel that if this is really a bug it would have been caught before release, but then again I can't think of anything atypical with my setup that would cause this problem. It's almost certainly caused by the code that checks if you're renaming a top level mailbox for a user and special cases it in all sorts of ways. I never liked that code much! My solution was to make DELETED.user.bwong.46A12345 (or similar) also be considered to be an INBOX so it was treated as a user rename. This seems not to be working in your environment, and I'm really not sure why. I don't see anything specially different in our config. fast_rename: yes, but that won't work for you anyway because it's using a not-yet-perfect patch at our end. All our mailbox deletes are done as the admin user. It won't work if you're not a bona-fide admin (not just a user called admin who happens to have an ACL). Check the 'admins:' parameter in your imapd.conf. Regards, Bron. (P.S. your username is scarily similar to mine!) 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: Replication: sync_client -r dies
On Sun, Nov 04, 2007 at 08:42:21PM -0800, Rich Wales wrote: Wesley Craig wrote: But most sync_server errors that will cause sync_client to bail out ought to cause sync_server to give a reasonably unique log message for the failure. As I explained earlier this evening, I didn't see ANYTHING AT ALL in the replica server's logs that resembled any sort of error indication at the times when sync_client bailed out. Is it possible that something I should be seeing is being filtered out by syslog.conf? What syslog facility name is used by sync_server? -- Rich Wales === Palo Alto, CA, USA === [EMAIL PROTECTED] http://www.richw.org === http://en.wikipedia.org/wiki/User:Richwales The difference between theory and practice is that, in theory, theory and practice are identical -- whereas in practice, they aren't. 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 Rich and Wesley, We are seeing similar behavior here where everything looks fine but we are not replicating messages in folders and the process bails out with no errors. Just another data point. Any help would be appreciated. Ken Marshall -- Mgr./Middleware, Infrastructure Development [EMAIL PROTECTED] / 713-348-5294 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: Deleting top-level mailbox with 'delete_mode: delayed'
On Nov 5, 2007 6:15 AM, Bron Gondwana [EMAIL PROTECTED] wrote: On Fri, Nov 02, 2007 at 01:15:37PM -0400, Brian Wong wrote: On Nov 2, 2007 12:39 PM, Rudy Gevaert [EMAIL PROTECTED] wrote: Brian Wong wrote: I was testing out Cyrus 2.3.10 and realized that when I set the option delete_mode: delayed I can not delete top-level mailboxes. localhost.localdomain lm localhost.localdomain cm user.bwong localhost.localdomain sam user.bwong admin_account c localhost.localdomain dm user.bwong deletemailbox: Operation is not supported on mailbox localhost.localdomain lm user.bwong (\HasNoChildren) Disabling the delayed delete gives expected results. The mailbox is deleted as normal. Anyone else confirm this? I'm just back from holiday (and only catching up on mail). I always set the 'x' permission. Could you try that? If that doesn't work, I'll try to delete a top level mailbox on Monday (I'm running 2.3.10 in test). Rudy localhost.localdomain lam user.bwong bwong lrswipkxtecda admin kxc localhost.localdomain dm user.bwong deletemailbox: Operation is not supported on mailbox I think if I did not have the right to delete the mailbox, I would get a Permission Denied instead of the error I am receiving. Let me know what you find when you try it. I feel that if this is really a bug it would have been caught before release, but then again I can't think of anything atypical with my setup that would cause this problem. It's almost certainly caused by the code that checks if you're renaming a top level mailbox for a user and special cases it in all sorts of ways. I never liked that code much! My solution was to make DELETED.user.bwong.46A12345 (or similar) also be considered to be an INBOX so it was treated as a user rename. This seems not to be working in your environment, and I'm really not sure why. I don't see anything specially different in our config. fast_rename: yes, but that won't work for you anyway because it's using a not-yet-perfect patch at our end. All our mailbox deletes are done as the admin user. It won't work if you're not a bona-fide admin (not just a user called admin who happens to have an ACL). Check the 'admins:' parameter in your imapd.conf. Regards, Bron. (P.S. your username is scarily similar to mine!) admins: cyradm localhost.localdomain sam user.bwong cyradm c localhost.localdomain lam user.bwong bwong lrswipkxtecda cyradm kxc localhost.localdomain dm user.bwong deletemailbox: Operation is not supported on mailbox The 'admins' parameter seems to be fine. I just didnt want to get specific with the configuration and showing that the admin was 'cyradm' because I didnt want to confuse anyone with having an admin user with the same name as the command. I really do not know what to do. This is a test box where I removed and recreated all the relevant cyrus directories just to make sure I was starting from scratch. Configuration: imapidresponse: 0 allowallsubscribe: 1 allowplaintext: 1 configdirectory: /var/imap defaultpartition: ms1 metapartition_files: header index cache expunge partition-default: /var/spool/imap partition-ms1: /var/spool/imap/data1 metapartition-ms1: /var/spool/imap/meta1 partition-ms2: /var/spool/imap/data2 metapartition-ms2: /var/spool/imap/meta2 auth_mech: pts pts_module: ldap admins: cyradm sasl_pwcheck_method: saslauthd sasl_mech_list: plain LDAP OPTIONS snipped username_tolower: 1 lmtp_downcase_rcpt: 1 singleinstancestore: 1 munge8bit: 0 reject8bit: 0 duplicate_db: skiplist annotation_db: skiplist mboxkey_db: skiplist mboxlist_db: skiplist ptscache_db: skiplist seenstate_db: skiplist subscription_db: flat tlscache_db: skiplist expunge_mode: delayed delete_mode: delayed 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
Purging Inbox Only
What is the best way to purge the inbox? I currently use ipurge for other folders but was told that if you run ipurge on the inbox it will be recursive and purge all boxes. But, the man page says different. Can you guys give me an example of how you did this in the past. 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
