Cyrus eats mails when delivering to user.subfolder
Hi, I'm using Cyrus 2.0.9/Linux/LMTP delivery. Mails addressed to be.usenet@... get dropped by Cyrus. No delivery to any file. No bounce is returned. Discovered while testing subfolder delivery to be+usenet@... (works if you grant p to anyone on that subfolder). I straced -f the master process to what files it opens and closes. 2002-09-28 10:10:48 17vCgZ-0006A1-00 => be.usenet <[EMAIL PROTECTED]> D=cyrususer T=local_delivery_cyrus_lmtp be.usenet@...: files accessed are (without regard to libraries) /var/imap/deliverdb/db/__db.00? /var/imap/db/log.02 /var/imap/mailboxes.db see complete strace's output at http://berdmann.dyndns.org/debug/cyrus/user.subfolder/master.strace.be.usenet 2002-09-28 10:31:07 17vD0E-0006CJ-00 => be+usenet <[EMAIL PROTECTED]> D=cyrususer T=local_delivery_cyrus_lmtp be+usenet@...: files accessed are /var/imap/deliverdb/db/__db.00? /var/imap/db/__db.00? /var/imap/db/log.02 /var/imap/mailboxes.db /var/yp/binding/berdmann.de.2 /var/imap/deliverdb/deliver-b.db /var/spool/imap/user/be/usenet/cyrus.* /var/spool/imap/stage./23831-1033201867 /var/spool/imap/user/be/usenet/5. see complete strace's output at http://berdmann.dyndns.org/debug/cyrus/user.subfolder/master.strace.be+usenet
RE: Time has come to stop with /usr/local path pollution!
Quoting Andrew Diederich <[EMAIL PROTECTED]>: > I'd just ask that if a known bug isn't going to be fixed, it needs to be > documented and put upfront, big and large, where folks will see it. > Shutting off compiler warnings with gcc 3.2 is an example. It broke > compile, but folks were talking about it on the list. > > Many of the developers, and people on this list, know about the problem, > but > people who just download the software, read the docs, and try to install it > will get burned otherwise. Then they'll curse the crappy software, and > they'll be right. > > There are three things to do when a bug is found. 1) fix it, 2) document > the bug and the workaround, or 3) hope people don't find it again. #3 is > terribly expensive in support costs, like this string of emails. Its seems that people are missing a very important point here. Cyrus was developed for internal use at CMU. CMU has been kind enough to allow the source code to be distributed for use by anybody, commercial or otherwise. Some may argue that CMU has a responsibility to fix all bugs, write good documentation, hand-hold ignorant/illiterate admins, make coffee, and clean windows. In most cases, they do all of the above, and more. I wish people would keep this in mind, when they claim that the build process is broken. It is broken for _you_, because I can assure you that it built for the intended user (CMU). The developers first responsibilty is to their employers, not to a small, whiny part of the user community with an edge-case problem. If people spend the same amount of time trying to fix the problem instead of bitching about it, this would've been a dead issue a long time ago. It don't think that the "squeaky wheel gets the grease" principal is necessarily going to work. The next time somebody is frustrated by the software and wants to rant about how much of their time the developers wasted, take a step back and remember how much time and money they actually _saved_ you. Another $.02 > -Original Message- > From: Rob Siemborski [mailto:[EMAIL PROTECTED]] > > On Fri, 27 Sep 2002, Michael Newlyn Blake wrote: > > > However it does seem that when explicit paths are called for certain > > componants they should be placed in line before the assumed system paths. > > That is to say, if you want to build and link against a libfoo in > > /snert/myjunk/foo-8.3.4 then this should be placed in the relevant paths > > before the include and lib dirs in /usr or /usr/local that are added > > automatically. > > I agree 100% that the paths should be honored. However, since it works > for most people, and testing is pretty annoying (as ken stated), I'm not > terribly eager to spend my time doing it, when I could be working on > performance or feature improvements elsewhere in the code. > > If there was a patch provided that I could look at, approve, and apply, > I'd be willing to do so. This is much less the case if I'm going to have > to read a bug report hidden inside of a rant that seems to assume that the > developers of Cyrus are part of a consipracy against all system > administrators everywhere. > > -Rob > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 > Research Systems Programmer * /usr/contributed Gatekeeper > > > -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
Re: Cyrus eats mails when delivering to user.subfolder
On Sat, 28 Sep 2002, Bernhard Erdmann wrote: > I'm using Cyrus 2.0.9/Linux/LMTP delivery. Mails addressed to > be.usenet@... get dropped by Cyrus. No delivery to any file. No bounce > is returned. Please upgrade to something more recent (*atleast* 2.0.16, preferably 2.1.5 or 2.1.9) and let us know if the problem is still there. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Bug in 2.1.9 rename across partitions
I've bugzilla'd this and I'll look into it early next week. On Sat, 28 Sep 2002, JP Howard wrote: > I've been using "RENAME user.name user.name newpartition" to move a > bunch of users to a different partition. I am using 2.1.9 under Linux > 2.4.18. > > After the RENAME completes, the user's quota file shows them using > twice the quota that they are actually using. Running the 'quota' > command fixes the problem. > > Looks like there might be a bug in the quota tracking in RENAME?... > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Death by Sieve
Hi, The following story happened to me on Friday - it's posted here for amusement and edification, and also because I have a nagging feeling that the software ought to be able to do something to prevent this sort of thing, though I'll admit I'm not entirely sure what. Some background - I run a cyrus server (2.0.16) for about 50 users. Postmaster mail goes to two admins. One of our users left on Friday evening, and it was necessary to bounce email to that user. As we wanted people mailing her to redirect their messages to a colleague, we chose to accomplish the bouncing with a sieve script, which rejected all mail, with an explanatory note. Some time later, my admin colleague, who was having a slow day, decided to add a reject to her own sieve script, for messages above a certain size. These would be rejected with a note to not send her large attachments. However, a mistake was made in this script, and it ended up bouncing all mail not caught by a preceding filter. At this stage, one of the two participant (I'm not yet sure which) managed to send a mail to the other. With Sieve deflector shields operating to make Scotty proud, the resultant message ping-ponged between them, each trip adding some more text to the message, and eventually died as the MTA (sendmail) generated an error. At this point, sendmail politely sent the problem message to postmaster (by way of MAILER-DAEMON alias expansion). Unfortunately, the mail for postmaster was delivered to me, and also to my colleague with the problematic sieve script. And so another infinetly bouncing message was born - this time both ends of the bounce being different aliases for the same email address. The net result of this was that every time sendmail ran the queue, I (as the unlucky sod with no shields up :-)) would receive about 3000 messages, each about 1.7Megs in size. My cyrus.cache file grew to over 2 gigs, and cyrus started refusing to talk to me any more. After a couple or three queue runs, I'd figured what was going on, and managed to remove the messages, reconstruct my mailbox, and delete the unprocessed mails from sendmail's queue to prevent it restarting, so it's all OK now. However, should there not be some way for cyrus's sieve implementation to avoid this. Perhaps it would be enough for sieve to refuse to process a message that contained a header indicating that another sieve instance had already processed it? Perhaps the reject action should add a special "rejected" header, and not reject mail that contained that header? On this occasion I fixed the problem, but at the rate it was going, if I had not noticed the problem before leaving, it would have filled the mail partition within about 6-8 hours. Clearly, any user who receives postmaster/MAILER-DAEMON mail should under no circumstances be able to reject this mail with sieve, so maybe the answer would be that the sieve implmentation should refuse to send mail to MAILER-DAEMON. There are still holes in that (other accounts that alias out to the same person), but it would perhaps get rid of some of the possibilities for mayhem Anyway, hopefully I've provided something to mull over, (and laugh at over beer). Mike.
RE: Time has come to stop with /usr/local path pollution!
I'm going to throw out my opinion too.. Please no flames. This isn't directed at anyone -- just my observations after using/maintaining Cyrus for 4 years (v1.5.19 still in production) First, CMU places a nice disclaimer in the docs. Cyrus is on the same order of NetNews to install -- historically compiling/installing/maintaining news server software has been a daunting task at best. When we started w/ Cyrus (1998) it was a big departure from the traditional mbox mail system. Even today if you want a simple to install mailsystem use mbox+/var/mail. Cyrus is a much more robust system and as a result requires more time and experience to install. Additionally, if you are trying to build a big mail system you better have more experience than "I've installed Linux a few times." Building large, scalable, and secure mail systems requires experience, patience and usually lots of caffeine and little sleep. (subscribing to this list helps too) Second, opensource does NOT work unless people contribute. CMU developed and maintains this software for their own use -- the rest of us get a free ride. I really appreciate the contributions Ken and others have made to the project. If you find something you don't like/think needs changing do what the rest of us do - change it and contrib it back to CMU. The current group of Cyrus developers have been great w/ working with outside patches etc. (users since v1 will remember those days when CMU was just trying to make it work ;-) ) Cyrus has been instrumental in our organizations conversion to opensource. Without Cyrus, we'd be running Groupwise or M$ Exchange ick! If Cyrus is too complicated / difficult for you to install/maintain go hire someone who can or purchase one of the above mentioned packages. Some important points: 1) Many thanks to CMU for releasing and trying to support this great software. 2) You get what you pay for (in this case remember the code is free) 3) If it breaks -- you get to keep both pieces -- but ask nicely many of us have broken Cyrus too. 4) Participate -- subscribe to the list, submit docs fixes etc if you can, discuss issues on the list, don't post "bitching" about this or that unless you are willing to do something about it. 5) If you don't like #4 quit wasting our time.. Paul Satisfied Cyrus user & contributor since v1.5.14 On Sat, 28 Sep 2002, Ken Murchison wrote: > Quoting Andrew Diederich <[EMAIL PROTECTED]>: > > > I'd just ask that if a known bug isn't going to be fixed, it needs to be > > documented and put upfront, big and large, where folks will see it. > > Shutting off compiler warnings with gcc 3.2 is an example. It broke > > compile, but folks were talking about it on the list. > > > > Many of the developers, and people on this list, know about the problem, > > but > > people who just download the software, read the docs, and try to install it > > will get burned otherwise. Then they'll curse the crappy software, and > > they'll be right. > > > > There are three things to do when a bug is found. 1) fix it, 2) document > > the bug and the workaround, or 3) hope people don't find it again. #3 is > > terribly expensive in support costs, like this string of emails. > > Its seems that people are missing a very important point here. Cyrus was > developed for internal use at CMU. CMU has been kind enough to allow the > source code to be distributed for use by anybody, commercial or otherwise. > > Some may argue that CMU has a responsibility to fix all bugs, write good > documentation, hand-hold ignorant/illiterate admins, make coffee, and clean > windows. In most cases, they do all of the above, and more. > > I wish people would keep this in mind, when they claim that the build process > is broken. It is broken for _you_, because I can assure you that it built for > the intended user (CMU). The developers first responsibilty is to their > employers, not to a small, whiny part of the user community with an edge-case > problem. > > If people spend the same amount of time trying to fix the problem instead of > bitching about it, this would've been a dead issue a long time ago. It don't > think that the "squeaky wheel gets the grease" principal is necessarily going > to work. > > The next time somebody is frustrated by the software and wants to rant about > how much of their time the developers wasted, take a step back and remember how > much time and money they actually _saved_ you. > > Another $.02 > > > > -Original Message- > > From: Rob Siemborski [mailto:[EMAIL PROTECTED]] > > > > On Fri, 27 Sep 2002, Michael Newlyn Blake wrote: > > > > > However it does seem that when explicit paths are called for certain > > > componants they should be placed in line before the assumed system paths. > > > That is to say, if you want to build and link against a libfoo in > > > /snert/myjunk/foo-8.3.4 then this should be placed in the relevant paths > > > before the include and li
[no subject]
I have a Cyrus IMAP installed and I need just realized that users could access their account through POP3. My question is, Is it possible to disable POP3 access to some accounts and leave it enabled to others? If not how could I disable POP3 access to the IMAP accounts? Any help would be appreciated!!
RE: Time has come to stop with /usr/local path pollution!
I am new to cyrus and the info-cyrus mailing list, but am a long time unix administrator and developer. Sendmail offers a similar product to cyrus, but lacking in some of the new features, for a large price tag. I prefer to deal with a few compilation gliches, provided the software works reliably once installed. If I can contribute in any way, I will. Thank you for making this software publicly available. I suspect it is far more popular than the developers originally anticipated. -- Tom Andrews Team Leader / Server Manager Campus Computing University of Nevada, Reno Quoting Paul Fleming <[EMAIL PROTECTED]>: > I'm going to throw out my opinion too.. > > Please no flames. This isn't directed at anyone -- just my observations > after using/maintaining Cyrus for 4 years (v1.5.19 still in production) > > First, CMU places a nice disclaimer in the docs. Cyrus is on the same order > of NetNews to install -- historically compiling/installing/maintaining news > server software has been a daunting task at best. When we started w/ Cyrus > (1998) it was a big departure from the traditional mbox mail system. Even > today if you want a simple to install mailsystem use mbox+/var/mail. Cyrus > > is a much more robust system and as a result requires more time and > experience > to install. Additionally, if you are trying to build a big mail system you > better have more experience than "I've installed Linux a few times." Building > > large, scalable, and secure mail systems requires experience, patience and > usually lots of caffeine and little sleep. (subscribing to this list helps > too) > > Second, opensource does NOT work unless people contribute. CMU developed > and > maintains this software for their own use -- the rest of us get a free > ride. > I really appreciate the contributions Ken and others have made to the > project. > If you find something you don't like/think needs changing do what the rest of > > us do - change it and contrib it back to CMU. The current group of Cyrus > developers have been great w/ working with outside patches etc. (users > since > v1 will remember those days when CMU was just trying to make it work ;-) ) > > Cyrus has been instrumental in our organizations conversion to opensource. > Without Cyrus, we'd be running Groupwise or M$ Exchange ick! If Cyrus is > too > complicated / difficult for you to install/maintain go hire someone who can > or purchase one of the above mentioned packages. > > Some important points: > > 1) Many thanks to CMU for releasing and trying to support this great > software. > > 2) You get what you pay for (in this case remember the code is free) > > 3) If it breaks -- you get to keep both pieces -- but ask nicely many of us > have > broken Cyrus too. > > 4) Participate -- subscribe to the list, submit docs fixes etc if you can, > discuss > issues on the list, don't post "bitching" about this or that unless you are > > willing to do something about it. > > 5) If you don't like #4 quit wasting our time.. > > Paul > Satisfied Cyrus user & contributor since v1.5.14 > > > On Sat, 28 Sep 2002, Ken Murchison wrote: > > > Quoting Andrew Diederich <[EMAIL PROTECTED]>: > > > > > I'd just ask that if a known bug isn't going to be fixed, it needs to > be > > > documented and put upfront, big and large, where folks will see it. > > > Shutting off compiler warnings with gcc 3.2 is an example. It broke > > > compile, but folks were talking about it on the list. > > > > > > Many of the developers, and people on this list, know about the > problem, > > > but > > > people who just download the software, read the docs, and try to install > it > > > will get burned otherwise. Then they'll curse the crappy software, and > > > they'll be right. > > > > > > There are three things to do when a bug is found. 1) fix it, 2) > document > > > the bug and the workaround, or 3) hope people don't find it again. #3 > is > > > terribly expensive in support costs, like this string of emails. > > > > Its seems that people are missing a very important point here. Cyrus was > > > developed for internal use at CMU. CMU has been kind enough to allow the > > > source code to be distributed for use by anybody, commercial or > otherwise. > > > > Some may argue that CMU has a responsibility to fix all bugs, write good > > documentation, hand-hold ignorant/illiterate admins, make coffee, and clean > > > windows. In most cases, they do all of the above, and more. > > > > I wish people would keep this in mind, when they claim that the build > process > > is broken. It is broken for _you_, because I can assure you that it built > for > > the intended user (CMU). The developers first responsibilty is to their > > employers, not to a small, whiny part of the user community with an > edge-case > > problem. > > > > If people spend the same amount of time trying to fix the problem instead > of > > bitching about it, this would've been a dead
Re: Cyrus eats mails when delivering to user.subfolder
> Please upgrade to something more recent (*atleast* 2.0.16, preferably > 2.1.5 or 2.1.9) and let us know if the problem is still there. Is is still there using 2.1.9. A mail to user.subfolder disappears.
RE: Time has come to stop with /usr/local path pollution!
Thanks for the help, Rob. -- Andrew From: Rob Siemborski [mailto:[EMAIL PROTECTED]] On Fri, 27 Sep 2002, Andrew Diederich wrote: > There are three things to do when a bug is found. 1) fix it, 2) document > the bug and the workaround, or 3) hope people don't find it again. #3 is > terribly expensive in support costs, like this string of emails. I have committed these two bugs to bugzilla as #1423 and #1424. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Time has come to stop with /usr/local path pollution!
On Sat, Sep 28, 2002 at 08:44:52AM -0400, Ken Murchison wrote: > Quoting Andrew Diederich <[EMAIL PROTECTED]>: > > > There are three things to do when a bug is found. 1) fix it, 2) document > > the bug and the workaround, or 3) hope people don't find it again. #3 is > > terribly expensive in support costs, like this string of emails. > > Its seems that people are missing a very important point here. Cyrus was > developed for internal use at CMU. CMU has been kind enough to allow the > source code to be distributed for use by anybody, commercial or otherwise. CMU scratched its itch, and released to code. No complaint here. > Some may argue that CMU has a responsibility to fix all bugs, write good > documentation, hand-hold ignorant/illiterate admins, make coffee, and clean > windows. In most cases, they do all of the above, and more. Since there is no contract between CMU, Cyrus developers, and folks who download Cyrus, it's absolutely not CMU's responsibility to do anything. > I wish people would keep this in mind, when they claim that the build process > is broken. It is broken for _you_, because I can assure you that it built for > the intended user (CMU). The developers first responsibilty is to their > employers, not to a small, whiny part of the user community with an edge-case > problem. Sure, Cyrus is there to scratch your itch. It happens to work for some others, too. I'd have to argue that installing the Berkeley DB in its default location is a little far from an "edge-case problem," though. > If people spend the same amount of time trying to fix the problem instead of > bitching about it, this would've been a dead issue a long time ago. It don't > think that the "squeaky wheel gets the grease" principal is necessarily going > to work. Yup. And some of that is taking what feedback you get from users, and deciding what to do with it. There really are only the three things you can do with a bug. Remember that its really hard to get user feedback. Even if a bug report doesn't include a patch, its usually better than not getting it at all. For every one guy that says "it surprised me when this happened" there are nine that were surprised and didn't say anything. And there are even fewer that tell you _why_ they were surprised, and what really happened. > The next time somebody is frustrated by the software and wants to rant about > how much of their time the developers wasted, take a step back and remember how > much time and money they actually _saved_ you. > > Another $.02 Open source software does tend to save money. And a good, helpful user community like this one, and sunmanagers, all adds to the value of a product. Thanks for the time to read this. -- Andrew Diederich
Murder
Hi, I have a few questions about murder. 1. Is it possible to run a mupdate master on the same host as a backend? 2. Is it possible to run a backend on the same host as a frontend? I'm trying running everything on 1 host now; all the backend daemons are listening to the ethernet device and all the frontend proxy-daemons to the loopbackdevice (just for testing purposes), but when i try creating a mailbox, it gives me this message: NO unable to reserve mailbox on mupdate server Even without frontend proxies it gives me this message. But the mupdate master is still on the same machine offcourse. Might that be the problem? here are the relevant mail.log entries: Sep 28 22:58:35 jef cyrus/imapd[19626]: login: kerberos.jef.ahk.nl[193.67.24.49] cyrus plaintext Sep 28 22:58:38 jef cyrus/imapd[19626]: myfetch: starting txn 2147483666 Sep 28 22:58:38 jef cyrus/imapd[19626]: mystore: reusing txn 2147483666 Sep 28 22:58:38 jef cyrus/imapd[19626]: mycommit: committing txn 2147483666 Sep 28 22:58:38 jef cyrus/mupdate[19612]: accepted connection Sep 28 22:58:38 jef cyrus/mupdate[19612]: telling master 3 Sep 28 22:58:38 jef cyrus/mupdate[19628]: starting cmdloop() on fd 13 Sep 28 22:58:38 jef cyrus/master[19604]: got weird response from child: 9 Sep 28 22:58:38 jef cyrus/mupdate[19628]: login: mupdate from kerberos.jef.ahk.nl[193.67.24.49] Sep 28 22:58:38 jef cyrus/mupdate[19628]: cmd_set(fd:13, qwerqwer) Sep 28 22:58:38 jef cyrus/imapd[19626]: mupdate NO response: mailbox already exists Sep 28 22:58:38 jef cyrus/imapd[19626]: MUPDATE: can't reserve mailbox entry for 'qwerqwer' Sep 28 22:58:38 jef cyrus/imapd[19626]: mydelete: starting txn 2147483667 Sep 28 22:58:38 jef cyrus/imapd[19626]: mydelete: committing txn 2147483667 Sep 28 22:58:38 jef cyrus/mupdate[19628]: ending cmdloop() on fd 13 I also have a question about authenticating to a mupdate server. To use a kerberos 5 ticket for authenticating to the mupdate server (and to the backend servers) i su to cyrus and do a: kinit -k mupdate I noticed that i also had to add the mupdate/kerberos.jef.ahk.nl service ticket to the keytab. This isn't ideal because the tickets it uses expire. Isn't it possible for clients of mupdate to read their tickets from the krb5.keytab? I allready tried DIGEST-MD5 and other shared secret methods, but i kept getting messages like: Sep 28 21:13:56 jef cyrus/imapd[18882]: badlogin: kerberos.jef.ahk.nl[193.67.24.49] DIGEST-MD5 [SASL(-13): user not found: no secret in database] I wasn't able to add MD5 tickets with: saslpasswd2 -c -n mupdate. That doesn't seem to do anything (allthough it doesn't complain about anything either). Only userPasswords seem to have effect. That's why i decided to try GSSAPI in the first place. Then i have a minor problem with the pop proxy. When i try loggin in with the user and pass command, it exits saying: -ERR [SYS/PERM] Fatal error: gethostbyname failed Below is what the mail.log says: Sep 28 23:40:59 jef cyrus/master[19765]: about to exec /usr/lib/cyrus/bin/pop3proxyd Sep 28 23:40:59 jef cyrus/pop3proxy[19765]: executed Sep 28 23:40:59 jef cyrus/pop3d[19765]: telling master 2 Sep 28 23:40:59 jef cyrus/master[19753]: service pop3proxy now has 0 workers Sep 28 23:40:59 jef cyrus/pop3d[19765]: accepted connection Sep 28 23:40:59 jef cyrus/pop3d[19765]: telling master 3 Sep 28 23:40:59 jef cyrus/master[19753]: service pop3proxy now has 0 workers Sep 28 23:41:04 jef cyrus/pop3d[19765]: login: localhost[127.0.0.1] willem plaintext Sep 28 23:41:04 jef cyrus/master[19753]: process 19765 exited, status 75 So it looks to me that i authenticated to the backend pop3 successfully? I have no clue about why it exists with that strange messsage. I'm sorry if these questions seem silly. It's my first try with the cyrus imap server & sasl library. Thanks, Willem van den Oord
Re: Time has come to stop with /usr/local path pollution!
--On Friday, September 27, 2002 10:34 AM -0400 Ken Murchison <[EMAIL PROTECTED]> wrote: > A lot of bitching, and no proposed fixes. It works for me, and I'm sure I have submitted patches in the past to fix this dain-bramaged configure behaviour. They have been ignored. Lots of the --with-foo options are implemented badly in configure.in. I'd like to fix them, but can't until the maintainers stop insisting on supporting autoconf-2.13. At this point, I've basically given up, and just manually hack configure to be non-idiotic before I configure a new release. -- Carson
Re: Murder
On 28 Sep 2002, Willem van den Oord wrote:
> 1. Is it possible to run a mupdate master on the same host as a backend?
With some creativity, yes it is. You just need to be sure that the
mupdate instance is using a different configdirectory from the backend
instance.
It is definately possible to put a mupdate master on a frontend.
> 2. Is it possible to run a backend on the same host as a frontend?
Again, yes, but the frontend can't be answering on the IMAP port (since
the backend is answering there). I doubt this is what you want.
> I'm trying running everything on 1 host now; all the backend daemons are
> listening to the ethernet device and all the frontend proxy-daemons to
> the loopbackdevice (just for testing purposes), but when i try creating
> a mailbox, it gives me this message:
Ken had a "murder-in-a-box" running for some testing purposes on his
laptop and was fine (the frontend was sharing its mailbox database with
the mupdate master, and was answering on a nonstandard port). The
backend was setup as normal.
> NO unable to reserve mailbox on mupdate server
>
> Even without frontend proxies it gives me this message. But the mupdate
> master is still on the same machine offcourse. Might that be the
> problem?
>
> here are the relevant mail.log entries:
>
> Sep 28 22:58:38 jef cyrus/mupdate[19628]: login: mupdate from
> kerberos.jef.ahk.nl[193.67.24.49]
> Sep 28 22:58:38 jef cyrus/mupdate[19628]: cmd_set(fd:13, qwerqwer)
> Sep 28 22:58:38 jef cyrus/imapd[19626]: mupdate NO response: mailbox
> already exists
> Sep 28 22:58:38 jef cyrus/imapd[19626]: MUPDATE: can't reserve mailbox
> entry for 'qwerqwer'
You do appear to be authenticating properly, though it seems that the
mailbox already exists.
I'm betting you have your master mupdate server sharing the same
configdirectory as your backend, and since the backend does:
1. create local entry
2. reserve remote entry
the mupdate server sees that the entry already exists, and denys the
operation.
> I also have a question about authenticating to a mupdate server.
> To use a kerberos 5 ticket for authenticating to the mupdate server (and
> to the backend servers) i su to cyrus and do a: kinit -k mupdate
>
> I noticed that i also had to add the mupdate/kerberos.jef.ahk.nl service
> ticket to the keytab. This isn't ideal because the tickets it uses
> expire. Isn't it possible for clients of mupdate to read their tickets
> from the krb5.keytab?
We do this at CMU (with krb4, but krb5 shouldn't be much different) with
entrys in cyrus.conf like:
START {
auth cmd="/usr/local/bin/ksrvtgt -l 3600 imap mail1 ANDREW.CMU.EDU
/imap/conf/srvtab"
}
EVENTS {
reauthcmd="/usr/local/bin/ksrvtgt -l 3600 imap mail1 ANDREW.CMU.EDU
/imap/conf/srvtab"
}
> I allready tried DIGEST-MD5 and other shared secret methods, but i kept
> getting messages like:
>
> Sep 28 21:13:56 jef cyrus/imapd[18882]: badlogin:
> kerberos.jef.ahk.nl[193.67.24.49] DIGEST-MD5 [SASL(-13): user not found:
> no secret in database]
>
> I wasn't able to add MD5 tickets with: saslpasswd2 -c -n mupdate. That
> doesn't seem to do anything (allthough it doesn't complain about
> anything either). Only userPasswords seem to have effect. That's why i
> decided to try GSSAPI in the first place.
-n isn't doing what you expect. This could probably be clarified in the
documentation. You don't want to specify it.
> Then i have a minor problem with the pop proxy. When i try loggin in
> with the user and pass command, it exits saying:
>
> -ERR [SYS/PERM] Fatal error: gethostbyname failed
[snip]
> So it looks to me that i authenticated to the backend pop3 successfully?
> I have no clue about why it exists with that strange messsage.
Me either. I'd need to do some more detailed debugging.
> I'm sorry if these questions seem silly. It's my first try with the
> cyrus imap server & sasl library.
They don't seem silly. We haven't gotten much feedback (other than our
own experiences) on the Murder setup.
In any case, to get a murder this close to working on your first try is
pretty impressive ;)
Let me know how it works out.
-Rob
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper
Re: your mail
On Sat, Sep 28, 2002 at 01:20:34PM -0400, Issac Simchayof wrote: > Is it possible to disable POP3 access to some accounts and leave it > enabled to others? If not how could I disable POP3 access to the IMAP > accounts? > Check your /etc/cyrus.conf file and disable any services you do not want to run. -- Scott Russell ([EMAIL PROTECTED]) Linux Technology Center, System Admin, RHCE. Dial 877-735-8200 then ask for 919-543-9289 (TTY)
Re: Murder
Hi, Could you post your imapd.conf file for me to look at? Thanks. -- << Eugene Chow >> ==--==--== -=ecentrenet dot kom=- http://www.ecentrenet.com ** Willem van den Oord wrote: >here are the relevant mail.log entries: > >Sep 28 22:58:35 jef cyrus/imapd[19626]: login: >kerberos.jef.ahk.nl[193.67.24.49] cyrus plaintext >Sep 28 22:58:38 jef cyrus/imapd[19626]: myfetch: starting txn 2147483666 >Sep 28 22:58:38 jef cyrus/imapd[19626]: mystore: reusing txn 2147483666 >Sep 28 22:58:38 jef cyrus/imapd[19626]: mycommit: committing txn >2147483666 >Sep 28 22:58:38 jef cyrus/mupdate[19612]: accepted connection >Sep 28 22:58:38 jef cyrus/mupdate[19612]: telling master 3 >Sep 28 22:58:38 jef cyrus/mupdate[19628]: starting cmdloop() on fd 13 >Sep 28 22:58:38 jef cyrus/master[19604]: got weird response from child: >9 >Sep 28 22:58:38 jef cyrus/mupdate[19628]: login: mupdate from >kerberos.jef.ahk.nl[193.67.24.49] >Sep 28 22:58:38 jef cyrus/mupdate[19628]: cmd_set(fd:13, qwerqwer) >Sep 28 22:58:38 jef cyrus/imapd[19626]: mupdate NO response: mailbox >already exists >Sep 28 22:58:38 jef cyrus/imapd[19626]: MUPDATE: can't reserve mailbox >entry for 'qwerqwer' >Sep 28 22:58:38 jef cyrus/imapd[19626]: mydelete: starting txn >2147483667 >Sep 28 22:58:38 jef cyrus/imapd[19626]: mydelete: committing txn >2147483667 >Sep 28 22:58:38 jef cyrus/mupdate[19628]: ending cmdloop() on fd 13 > > >I also have a question about authenticating to a mupdate server. >To use a kerberos 5 ticket for authenticating to the mupdate server (and >to the backend servers) i su to cyrus and do a: kinit -k mupdate > >I noticed that i also had to add the mupdate/kerberos.jef.ahk.nl service >ticket to the keytab. This isn't ideal because the tickets it uses >expire. Isn't it possible for clients of mupdate to read their tickets >from the krb5.keytab? > >I allready tried DIGEST-MD5 and other shared secret methods, but i kept >getting messages like: > >Sep 28 21:13:56 jef cyrus/imapd[18882]: badlogin: >kerberos.jef.ahk.nl[193.67.24.49] DIGEST-MD5 [SASL(-13): user not found: >no secret in database] > >I wasn't able to add MD5 tickets with: saslpasswd2 -c -n mupdate. That >doesn't seem to do anything (allthough it doesn't complain about >anything either). Only userPasswords seem to have effect. That's why i >decided to try GSSAPI in the first place. > > >Thanks, > >Willem van den Oord >
Re:
That's weird... Why would you want to do that? Anyway, you might like to try this. Since the daemons pop3d and imapd can accept parameters to use different config files, you could create two config files in /etc for imapd and pop3d (ie. pop3d.conf and imapd.conf). Then in each config file, specify a different path for the sasldb2 user database using this parameter: sasl_sasldb_path: /etc/sasldb2 You could have one db file called pop3db and another imapdb if you like. Then in cyrus.conf, change the following line from this: pop3 cmd="/usr/local/cyrus/pop3d" listen="pop3" prefork=0 to: pop3 cmd="/usr/local/cyrus/pop3d -C /etc/pop3d.conf" listen="pop3" prefork=0 The command used in the second line tells pop3d to read pop3d.conf instead of the default imapd.conf. Tell me if it works 'coz I never tested it out before. Hope it helped! Cheers, Eugene Issac Simchayof wrote: >I have a Cyrus IMAP installed and I need just realized that users could >access their account through POP3. > >My question is, > >Is it possible to disable POP3 access to some accounts and leave it >enabled to others? If not how could I disable POP3 access to the IMAP >accounts? > >Any help would be appreciated!! >
Telnet commands.
Greetings all. I've been reading some of the archive, but did not find exactly what I wanted, so here it is ... My main goal is to be able to telnet on port 143, and administer Cyrus remotelly, and be able to use the same tools taht cyradm provides. Thus far, I was able to login using user cyrus, and even create a user. [Question #1] Why do I have a permission denied error message when trying to delete the bogus account I've just created ? [root@isham root]# telnet localhost 143Trying 127.0.0.1...Connected to localhost.Escape character is '^]'.* OK xxx.xx.com Cyrus IMAP4 v2.0.16 server readyA001 LOGIN cyrus xxxA001 OK User logged in0 CREATE foobar0 OK Completed0 DELETE foobar0 NO Permission denied ??? I read the doc located on http://sunsite.doc.ic.ac.uk/rfc/rfc2060.txt. This provided me with a couple of commands I can issue via Telnet, as stated above. Great. But cyradm premits to set quota, set permissions on account, list mailboxes and others usefull commands. Those commands are not shown in the documentation. [Question #2] Can we issue the same set of commands via telnet ? I appreciate you help.
Re: Telnet commands.
On Sat, 28 Sep 2002, Frederic Trudeau wrote: > [Question #1] Why do I have a permission denied error message when > trying to delete the bogus account I've just created ? You need to give yourself 'c' in the ACL for the mailbox, since by default you don't have it. > I read the doc located on http://sunsite.doc.ic.ac.uk/rfc/rfc2060.txt. This provided >me with a couple of commands I can issue via Telnet, as stated above. > Great. But cyradm premits to set quota, set permissions on account, list mailboxes >and others usefull commands. Those commands are not shown in > the documentation. Read doc/specs.html in the distribution. This will give links to all the applicable RFCs and IDs. > [Question #2] Can we issue the same set of commands via telnet ? I don't understand this question. OOC, why aren't you just using cyradm (or a perl script based off of the Cyrus::Admin module). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Telnet commands.
Thanks, and could you be more specific on how to give myself 'c' in the ACL ? You are asking why I am not simply using cyradm. One main reason : My client wants a web-based tool that will enable him to have control over the mail system, and I dont know Perl. One easy way to do this via Telnet is to use PHP and create a socket on port 143. Then, I will be able to control input/output easilly. Ok ok ... maybe I *should* learn Perl after all =) - Original Message - From: "Rob Siemborski" <[EMAIL PROTECTED]> To: "Frederic Trudeau" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Saturday, September 28, 2002 11:20 PM Subject: Re: Telnet commands. > On Sat, 28 Sep 2002, Frederic Trudeau wrote: > > > [Question #1] Why do I have a permission denied error message when > > trying to delete the bogus account I've just created ? > > You need to give yourself 'c' in the ACL for the mailbox, since by default > you don't have it. > > > I read the doc located on http://sunsite.doc.ic.ac.uk/rfc/rfc2060.txt. This provided me with a couple of commands I can issue via Telnet, as stated above. > > Great. But cyradm premits to set quota, set permissions on account, list mailboxes and others usefull commands. Those commands are not shown in > > the documentation. > > Read doc/specs.html in the distribution. This will give links to all the > applicable RFCs and IDs. > > > [Question #2] Can we issue the same set of commands via telnet ? > > I don't understand this question. > > OOC, why aren't you just using cyradm (or a perl script based off of the > Cyrus::Admin module). > > -Rob > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 > Research Systems Programmer * /usr/contributed Gatekeeper > > > >
Re: Telnet commands.
On Sat, 2002-09-28 at 23:32, Frederic Trudeau wrote: > > Thanks, and could you be more specific on how to give myself 'c' in the ACL > ? > > You are asking why I am not simply using cyradm. One main reason : My client > wants a web-based tool that will enable him to have control over the mail > system, and I dont know Perl. One easy way to do this via Telnet is to use > PHP and create a socket on port 143. Then, I will be able to control > input/output easilly. > > Ok ok ... maybe I *should* learn Perl after all =) > Perl and PHP aren't that different. Not surprising since PHP was developed as a more Web friendly replacement for Perl. You might want to look around for php-cyradm. I've used it successfully for some Cyrus admin tasks via a Web interface. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= The instructions said to use Windows 98 or better, so I installed RedHat Jim Levie email: [EMAIL PROTECTED]
