Re: much information from cyrus log
We need the information about which ip is connecting to which mailbox, and what is this user doing: opening, deleting, authenticating, ... Thanks in advance - ANNA - Quoting Andreas Winkelmann m...@awinkelmann.de: I'm trying to get as much information as possible from the cyrus log. I've tried several modification of the syslog configuration filewithout success. I also create a folder at /var/log/.. per user getting as much information I want but... it's in different files and folders, and is per user based solution, which is difficult to administrate. Any clue on how to configure cyrus and syslog to retrieve all this info? Maybe you should go the other way around. Tell what information you need. Cyrus sends alot of information with LOG_DEBUG to syslog, check if you catch these Messages. The directories you mentioned are telemetry Logs, these Dirs are in $configdirectory, which is normally not in /var/log/... -- Andreas 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 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
[no subject]
Greets! I am researching lemonade compliance and what email servers may be able to support key extensions, especially RFC 5465 - IMAP NOTIFY. As it stands, no support appears to be available from any vendor. Cyrus 2.4 looks like it will support much of the new lemonade functionality, but little information has been made available. Can anyone shed light on when we might expect a 2.4 or lemonade-oriented release and what might be included? Thanks! Colin Jaccino 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
Using the quota command question
Hello all. Quick (hopefully) question - the man page for quota says it isn't recommended to do a -f when specifying a user. Due to some issues that would take a while to explain, we will need to fix quite a few quotas on users as we xfer them to a new system. Is this an outdated statement in the man page? If not, what is the risk? I'd hate to have to run quota -f across a server of many thousand users just to fix one. Thanks for any help! Tim Champ UMBC DoIT Unix Infrastructure Team 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: Using the quota command question
Tim Champ wrote: Hello all. Quick (hopefully) question - the man page for quota says it isn't recommended to do a -f when specifying a user. Due to some issues that would take a while to explain, we will need to fix quite a few quotas on users as we xfer them to a new system. Is this an outdated statement in the man page? If not, what is the risk? I'd hate to have to run quota -f across a server of many thousand users just to fix one. Thanks for any help! Tim Champ UMBC DoIT Unix Infrastructure Team Sigh -- I forgot to add our version - 2.3.8. Sorry about that, and the resulting double mail. The version of software is the same on the to/from machines. If you have any questions, I'm happy to answer them. Thanks! Tim 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: Using the quota command question
On Thu, 23 Apr 2009, Tim Champ wrote: Hello all. Quick (hopefully) question - the man page for quota says it isn't recommended to do a -f when specifying a user. Due to some issues that would take a while to explain, we will need to fix quite a few quotas on users as we xfer them to a new system. Is this an outdated statement in the man page? If not, what is the risk? I'd hate to have to run quota -f across a server of many thousand users just to fix one. I use quota -f user.foo all the time to fix quotes on mailboxes restored from backups. I've never had any errors or problems, so I don't know why the manpage gives that recommendation. Andy 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
Cyrus Imap plaintext authentication with saslauth PAM
Hello everyone! I'm new to this mailing list, actually, this is the first mailing list I've ever subscribed. :) So greetings to all from Hungary! (And excuse my really bad english, please) I'm not sure if I can ask for help here, but I didn't find any answer elsewhere, so trying this out. I have a postfix relay server and a (local) cyrus imap server on the same machine. Everything was fine until I thought, I change the imap authentication from sasldb to saslauth, to have global authentication on postfix and cyrus. Postfix uses saslauthd, which is configured for PAM. It works perfectly, with plain/login/cram/digest mechanisms, with or without tls/ssl, absolutely no problems with it. Saslauth tests are all fine obviously. So I decided to use this with cyrus imap too. Set it to use the same saslauth daemon, and plain, login, cram-md5 and digest-md5 mechs. Since then, I can not login with plain or login mechs, because they aren't being offered at all by cyrus imapd. I can login with cram or digest fine. I understand that plain login isn't offered by default, only after a successfull tls session setup, but if I understand correctly, the "allowplaintext: yes" option should still force imapd to offer plain logins. But it doesn't. I tried it with different sasl_min|max_levels, to no avail. This is the first thing I don't understand. The second is: after establishing a tls or ssl connection, plain and login are offered, but I can not login with these mechs. (I'm using imtest to test it all.) However, with "testsaslauth", I am able to authenticate fine. I'm quite new to cyrus and linux systems, but I read all kinds of manuals and FAQs nd documentation, and googled a lot, but I was unable to find the culprit. So you are my last hope. If nothing else works, I leave it as is, with digest and cram it works and it's more secure. Or I go back to sasldb, which is less comfortable for me... Any help is greatly appreciated! Thanks! Regards, Janos 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
Multiple IMAP connections from new IMAP clients
We've had a problem recently with the number of imapd processes on our Cyrus front-end increasing steadily until it filled the process table. It seems that some recent IMAP clients will normally open a number of IMAP connections to their server, and will open more based on user activity. Each of these causes a new imapd process to be spawned on the front-end. As far as I know, the server treats each connection independantly, even though the client may consider one to be permanent and the others to be transient. What are people doing to protect their Cyrus servers from this increasing number of connections, each of which consumes resources on the server? This problem is going to get worse as more sophisticated clients become popular. Is many small front-ends the solution? -- -Gary Mills--Unix Support--U of M Academic Computing and Networking- 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 Imap plaintext authentication with saslauth PAM
Kővári János wrote: I have a postfix relay server and a (local) cyrus imap server on the same machine. Everything was fine until I thought, I change the imap authentication from sasldb to saslauth, to have global authentication on postfix and cyrus. Postfix uses saslauthd, which is configured for PAM. It works perfectly, with plain/login/cram/digest mechanisms, with or without tls/ssl, absolutely no problems with it. Saslauth tests are all fine obviously. So I decided to use this with cyrus imap too. Set it to use the same saslauth daemon, and plain, login, cram-md5 and digest-md5 mechs. Since then, I can not login with plain or login mechs, because they aren't being offered at all by cyrus imapd. I can login with cram or digest fine. I understand that plain login isn't offered by default, only after a successfull tls session setup, but if I understand correctly, the allowplaintext: yes option should still force imapd to offer plain logins. But it doesn't. I tried it with different sasl_min|max_levels, to no avail. This is the first thing I don't understand. The second is: after establishing a tls or ssl connection, plain and login are offered, but I can not login with these mechs. (I'm using imtest to test it all.) However, with testsaslauth, I am able to authenticate fine. I'm quite new to cyrus and linux systems, but I read all kinds of manuals and FAQs nd documentation, and googled a lot, but I was unable to find the culprit. So you are my last hope. If nothing else works, I leave it as is, with digest and cram it works and it's more secure. Or I go back to sasldb, which is less comfortable for me... Please include the following information, so we can get a better idea of your setup: Postfix and Cyrus IMAP version Postfix SASL config: grep sasl main.cf cat /etc/postfix/sasl/smtpd.conf (or wherever smtpd.conf it located on your system) Your cyrus imap.conf config saslauthd does not support cram-md5 or digest-md5, so you may be (also) using the sasldb auxprop in Postfix. - Dan 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: Multiple IMAP connections from new IMAP clients
On 04/23/2009 01:57 PM, Gary Mills wrote: We've had a problem recently with the number of imapd processes on our Cyrus front-end increasing steadily until it filled the process table. It seems that some recent IMAP clients will normally open a number of IMAP connections to their server, and will open more based on user activity. Each of these causes a new imapd process to be spawned on the front-end. As far as I know, the server treats each connection independantly, even though the client may consider one to be permanent and the others to be transient. What are people doing to protect their Cyrus servers from this increasing number of connections, each of which consumes resources on the server? This problem is going to get worse as more sophisticated clients become popular. Is many small front-ends the solution? We've been using imapproxyd to help solve just this kind of problem. Haven't used it with a murder, but expect it could still be useful. Cheers, -nic -- Nic Bernstein n...@onlight.com Onlight llc. www.onlight.com 2266 North Prospect Avenue #610 v. 414.272.4477 Milwaukee, Wisconsin 53202-6306 f. 414.290.0335 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: Multiple IMAP connections from new IMAP clients
On Thu, Apr 23, 2009 at 02:23:10PM -0500, Nic Bernstein wrote: On 04/23/2009 01:57 PM, Gary Mills wrote: We've had a problem recently with the number of imapd processes on our Cyrus front-end increasing steadily until it filled the process table. It seems that some recent IMAP clients will normally open a number of IMAP connections to their server, and will open more based on user activity. Each of these causes a new imapd process to be spawned on the front-end. As far as I know, the server treats each connection independantly, even though the client may consider one to be permanent and the others to be transient. What are people doing to protect their Cyrus servers from this increasing number of connections, each of which consumes resources on the server? This problem is going to get worse as more sophisticated clients become popular. Is many small front-ends the solution? We've been using imapproxyd to help solve just this kind of problem. Haven't used it with a murder, but expect it could still be useful. Does it actually combine separate connections from a single client into one connection to the server? I don't know how it could do that without violating the protocol. -- -Gary Mills--Unix Support--U of M Academic Computing and Networking- 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
