Re: Shared folder filtering (probably a thousand times asked)
[I should have gone to bed way before] Am Sonntag, 4. November 2007 schrieben Sie: > > It's not a ACL problem, afaics: No wonder, if beaten with blindness: > lam shared.text* > shared.test: > test lrswipkxtecd > cyrus lrswipkxtecda > anyone p > shared.test.Gesendet: > test lrswipkxtecd > cyrus lrswipkxtecda > anyone lrs ^^^ I simply missed the "p". Please excuse my stupidity and the noise. Thanks, Pete 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'
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 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. I tested it here and it works. [EMAIL PROTECTED]:~$ cyradm -t '' kavula verify error:num=19:self signed certificate in certificate chain Password: kavula.ugent.be> cm user/[EMAIL PROTECTED] kavula.ugent.be> lm ... user/[EMAIL PROTECTED] (\HasNoChildren) ... kavula.ugent.be> sam user/[EMAIL PROTECTED] cyrus x kavula.ugent.be> dm user/[EMAIL PROTECTED] kavula.ugent.be> lm DELETED/user/rgevaert/[EMAIL PROTECTED] (\HasNoChildren) ... kavula.ugent.be> dm DELETED/user/rgevaert/[EMAIL PROTECTED] kavula.ugent.be> lm and that doesn't show the deleted mailbox. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Rudy Gevaert [EMAIL PROTECTED] tel:+32 9 264 4734 Directie ICT, afd. Infrastructuur Direction ICT, Infrastructure dept. Groep Systemen Systems group Universiteit Gent Ghent University Krijgslaan 281, gebouw S9, 9000 Gent, Belgie www.UGent.be -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 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 03 Nov 2007, at 23:20, Rich Wales wrote: > Wesley Craig wrote: >> It usually dies for a reason, i.e., some discrepancy that either >> sync_client or sync_server couldn't handle. The typical way to >> handle it is to contact someone. > > What sort of debugging output am I going to need to generate in order > for anyone to have a chance of tracking the problem down? > I added the -l and -v flags to sync_client, but right now, the only > clue I have is that /var/log/messages includes a couple of errors > saying "Error in do_sync(): bailing out!". Both sync_client and sync_server typically log problems. Those logs are probably immediately helpful. Further information would depends on the reason for the bail out. > No core dump files anywhere in sight. Personally, I see more cases of unresolvable discrepancies than core buts, but both exist. :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
Re: Replication: sync_client -r dies
Wesley Craig wrote: > Both sync_client and sync_server typically log problems. Those > logs are probably immediately helpful. Further information would > depend on the reason for the bail out. Where would I find this log info? As I said earlier, the only info I've found so far are the "Error in do_sync(): bailing out!" notices in the /var/log/messages file. Are there some other log files saved somewhere else? I do have "-l" and "-v" specified for the sync_client command. Should I add any additional options in order to get debugging info? -- 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
Re: Replication: sync_client -r dies
On 04 Nov 2007, at 13:11, Rich Wales wrote: > Where would I find this log info? As I said earlier, the only info > I've > found so far are the "Error in do_sync(): bailing out!" notices in the > /var/log/messages file. Are there some other log files saved > somewhere > else? I do have "-l" and "-v" specified for the sync_client command. > Should I add any additional options in order to get debugging info? The replica sync_server will also log to syslog. :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
Re: Replication: sync_client -r dies
Wesley Craig wrote: > The replica sync_server will also log to syslog. No, sorry, as best I can tell, there isn't anything non-routine in any of the log files on my replica server. Do I need to specify any command-line flags to 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
Re: Replication: sync_client -r dies
On 04 Nov 2007, at 14:27, Rich Wales wrote: > No, sorry, as best I can tell, there isn't anything non-routine in any > of the log files on my replica server. > Do I need to specify any command-line flags to sync_server? No, sync_server doesn't take much in the way of command line options. If the problem appears to be reproducible, you can enable telemetry logging or examine the mailboxes that are causing problem. :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
Re: Replication: sync_client -r dies
Wesley Craig wrote: > No, sync_server doesn't take much in the way of command line options. Hmmm. OK, thanks. > If the problem appears to be reproducible, you can enable telemetry > logging or examine the mailboxes that are causing problem. I currently have absolutely no idea as to what is causing sync_client to bail out, or which mailbox(es) or other factors may be causing it. The only other possible piece of evidence I'm aware of might be the log files left over in my /cyrus/config/sync directory. If I were to post these or send them to you, is there a chance this might reveal anything? -- 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
Re: Replication: sync_client -r dies
Wesley Craig wrote: > The log files are pretty obvious in what they say, e.g., they just > list mailboxes or users to check. So I suspect they would reveal > to you which mailboxes are problematic. I sort of assume that > you're running sync_client with -l, otherwise it doesn't log much. > If it's run with -l, it should mention the action that preceded > the problem. Here's one of the leftover log files, time-stamped right at the time of one of these bailout crashed. APPEND user.marie SEEN marie user.marie MAILBOX user.marie MAILBOX user.marie.Junk SEEN marie user.marie.Junk SEEN marie user.marie MAILBOX user.marie Other messages have been delivered since that time to both user.marie and user.marie.Junk without crashing sync_client. So if this log is telling me there's a problem with either of these mailboxes, I don't understand what the log is telling me. Yes, I am using the "-l" flag (sync_client -r -l -v), but I'll have to say once again that neither /var/log/messages nor any other log file on my master server shows any other sync-related error message of any sort whatsoever, except for the "Error in do_sync(): bailing out!" message I mentioned previously. In /var/log/debug.log, I see things such as these: Nov 3 18:55:44 whodunit sync_client[6875]: seen_db: user richw opened /var/imap/user/r/richw.seen Nov 3 19:03:29 whodunit sync_client[7008]: DIGEST-MD5 client step 1 Nov 3 19:03:29 whodunit sync_client[7008]: DIGEST-MD5 client step 2 Nov 3 19:03:29 whodunit sync_client[7008]: DIGEST-MD5 client step 3 Nov 3 19:13:44 whodunit sync_client[7127]: DIGEST-MD5 client step 1 Nov 3 19:13:44 whodunit sync_client[7127]: DIGEST-MD5 client step 2 Nov 3 19:13:44 whodunit sync_client[7127]: DIGEST-MD5 client step 3 (the bailout message itself occurred at 19:14:37) and on the replica server, I see the following: Nov 3 19:03:29 flipflop syncserver[15942]: accepted connection Nov 3 19:03:29 flipflop syncserver[15942]: cmdloop(): startup Nov 3 19:13:45 flipflop master[16110]: about to exec /usr/cyrus/bin/sync_server Nov 3 19:13:45 flipflop syncserver[15942]: accepted connection Nov 3 19:13:45 flipflop syncserver[15942]: cmdloop(): startup Nov 3 19:13:45 flipflop syncserver[16110]: executed but that's all. Should I be seeing additional debugging output? If so, where should I be looking for it? I'm very sorry, but at the moment, all I can see is that the sync software mysteriously dies every so often, with no intelligible clue as to why. I understand you're saying that there should be additional info, but either it's NOT there or I don't know where to look for it. If anyone can help me figure out what I'm doing wrong here, I'll be grateful. -- 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
Re: Cyrus IMAPd 2.3.10 Released
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. -- 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
Re: Replication: sync_client -r dies
If you're running with -r -l (-v is for interactive use -- it causes printf output), you should be getting messages like: APPEND user.marie in syslog at level INFO. If you're not seeing those, then you have syslog configured to filter them. See the man page for syslog.conf. :wes On 04 Nov 2007, at 22:13, Rich Wales wrote: > Should I be seeing additional debugging output? 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
The log files are pretty obvious in what they say, e.g., they just list mailboxes or users to check. So I suspect they would reveal to you which mailboxes are problematic. I sort of assume that you're running sync_client with -l, otherwise it doesn't log much. If it's run with -l, it should mention the action that preceded the problem. :wes On 04 Nov 2007, at 20:36, Rich Wales wrote: > I currently have absolutely no idea as to what is causing sync_client > to bail out, or which mailbox(es) or other factors may be causing it. > > The only other possible piece of evidence I'm aware of might be the > log files left over in my /cyrus/config/sync directory. If I were to > post these or send them to you, is there a chance this might reveal > anything? 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
Wesley Craig wrote: > If you're running with -r -l . . . , you should be getting messages > like:APPEND user.mariein syslog at level INFO. If you're > not seeing those, then you have syslog configured to filter them. Thanks. It looks like that's what was happening. I modified my syslog.conf and kicked syslogd, and now I'm seeing those entries in /var/log/messages. I'll let the list know if I experience any more sync_client crashes. Should I be looking for similar syslog messages on my replica server too (and checking syslog.conf on that system if necessary)? -- 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
Re: Replication: sync_client -r dies
On 04 Nov 2007, at 22:57, Rich Wales wrote: > Should I be looking for similar syslog messages on my replica server > too (and checking syslog.conf on that system if necessary)? No, not similar. 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. :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
Re: Replication: sync_client -r dies
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
