Re: Lmtp time-out for one user
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Warren Flemmer [EMAIL PROTECTED] writes: I have been having problems with one users mailbox. This occurs about weekly. I see the following in the mailq: (conversation with /var/imap/socket/lmtp[/var/imap/socket/lmtp] timed out while sending end of data -- message may be sent more than once) This looks like the locking issue of the seen database discussed on the mailing list. Perhaps you should try to apply the patch proposed by John Wade. - -Hein -BEGIN PGP SIGNATURE- Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE86hwgX1+b5sUfCrQRAoHvAKCMtxXy1CjWmoiMz3eS2+U4baWLjwCggiXP vX8Amj8c3lt9s3R0YttkIzw= =6TlH -END PGP SIGNATURE-
Cannot run Cyrus Master process : SIGSEGV (cont.)
In /var/log/imapd.log I have something like this : May 21 14:27:38 pegase master[14544]: process started May 21 14:27:38 pegase master[14544]: process 14545 exited, signaled to death by 5 And the first time I have 2 lines more : May 21 14:24:47 pegase ctl_cyrusdb[14538]: recovering cyrus databases May 21 14:24:48 pegase ctl_cyrusdb[14538]: done recovering cyrus databases Any idea ?
Cannot run Cyrus Master process : SIGSEGV (cont.) (cont.)
Replacing Berkeley db-4.0.14 with db-3.3.11 ... problem is the same : it segfaults ... And in log file I have only this : May 21 15:20:06 pegase master[7379]: process started May 21 15:20:06 pegase master[7380]: about to exec /usr/cyrus/bin/ctl_cyrusdb May 21 15:20:06 pegase ctl_cyrusdb[7380]: recovering cyrus databases May 21 15:20:07 pegase ctl_cyrusdb[7380]: done recovering cyrus databases
Re: Cannot run Cyrus Master process : SIGSEGV
Ema Nymton wrote: Hi, Having just compiled cyrus-sasl and cyrus-imapd from CVS (with Berkeley DB 4.0.14), I have a segfault when trying to run the master process. I followed instructions in help files (creation of right user/group, and directory structure with correct rights attributes). Using GDB I have the following results : pegase:~# gdb /usr/cyrus/bin/master GNU gdb 19990928 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i686-pc-linux-gnu...(no debugging symbols found)... (gdb) r Starting program: /usr/cyrus/bin/master (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x0 in ?? () (gdb) where #0 0x0 in ?? () #1 0x401abb32 in __db_err () from /lib/libdb.so.3 #2 0x401a527d in db_open () from /lib/libdb.so.3 Off the top of my head, this _migbt_ be your problem. I'm guessing you are having a BDB version conflict. What version of Linux is this that is using BDB for the naming service(s)? BTW, please stop sending messages like these to cyrus-cvs. That list is for CVS commit announcements only. Ken -- 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: Mail status
Actually I found the hash incorrect for both sieve and cyrus in the user/quota directory's. What i did is patch'd the mkimap and dohash scripts. Attached you'll find what i did, i implemented a FULL hash and found that the directory's created by the scripts were in-adequite for my needs, and cyrus couldnt handle it. It was basically looking for directory's in uppercase, when they were lowercase, so what i did is modified the scripts to create both upper and lowercase on both sieve and quota and user directory's. Which is the problem usually when messages suddenly become new. If you have *.debug /var/log/debug.log enabled in syslogd which i suggest You would have found something like this May 2 04:16:00 shell imapd[12087]: [ID 136705 local6.error] IOERROR: opening /var/imap/user/S/darius.seen: No such file or directory May 2 04:16:00 shell imapd[12087]: [ID 729713 local6.error] DBERROR: opening /var/imap/user/S/darius.seen: cyrusdb error May 2 04:16:00 shell imapd[12087]: [ID 844790 local6.error] Could not open seen state for darius (System I/O error) If you notice the path is /var/imap/user/S not /var/imap/user/s you will take note that by default S is not created, we need to create it. Once we create it, darius.seen can be written and suddenly your messages will be sent to you proplery Maybe it's something that Rob needs to take a look at why it's requesting these directory's. But anyhow here's my little patch's i hope this helps. --On Tuesday, May 21, 2002 2:10 PM +0200 Luca Olivetti [EMAIL PROTECTED] wrote: Russell Packer wrote: Hi, I get strange behaviour using Microsoft Outlook - the status for various e-mail messages seems to change rather randomly. I will mark messages as being read, then 5/10 minutes later they will suddenly be marked as 'unread' (IMAP). Others in the company have remarked upon it as well. Has anyone else experienced this behaviour? What can I look at to tell what cyrus is doing? I have experienced the same problem with mozilla, see http://asg.web.cmu.edu/archive/message.php?mailbox=archive.info-cyrusmsg =13859 Alec H. Peterson suggested a solution here http://asg.web.cmu.edu/archive/message.php?mailbox=archive.info-cyrusmsg =13890 so I made a patch with a new runtime option to implement what he said. At first it seemed to work but then the problem resurfaced after a week of use. Now I switched to using skiplist instead of flat for the seen database and so far it works, but who knows, maybe in a couple of days it'll break again. -- Luca Olivetti Wetron Automatización S.A. http://www.wetron.es/ Tel. +34 93 5883004 Fax +34 93 5883007 --- If Thyne Eyes Deceivee Thee, Pluck Them Out. dohash.diff Description: Binary data mkimap.diff Description: Binary data
Re: Mail status
Thanks. I'll make sure that I update the correct docs. Ken Gary Mills wrote: On Tue, May 21, 2002 at 02:35:45PM -0400, Ken Murchison wrote: Its been so long since I committed your patches, I don't remember how this stuff works (or is documented). Is the improved hash stuff only available as an 'upgrade' via rehash, or can it be used right out of the box on a fresh installation? The rehash script replaces and supercedes the dohash, mkimap, and undohash scripts. It can be used on a fresh installation to create either type of hashing, or can be used to convert an existing installation to another type. Essentially, it reviews the existing directory structure, adding what is missing, and converting what needs to be converted. If it is only an upgrade, we should work on making it available on a fresh installation. In either case, we should make sure that we have all of this documented correctly. Yes, it would be good to document it. Here's a piece of what I submitted originally: The `rehash' perl script converts the Cyrus directory structure between three hash schemes: none, basic, and full. `none' means no directory hashing at all. `basic' is the current scheme, based on the first letter. `full' is the new hashing scheme. This perl script replaces several of the other perl scripts in the tools directory: dohash, mkimap, and undohash, but not upgradesieve. The name of the new hash scheme must be specified as one of its command-line arguments. -- -Gary Mills--Unix Support--U of M Academic Computing and Networking- -- 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: Mail status
On Tue, May 21, 2002 at 02:35:45PM -0400, Ken Murchison wrote: Its been so long since I committed your patches, I don't remember how this stuff works (or is documented). Is the improved hash stuff only available as an 'upgrade' via rehash, or can it be used right out of the box on a fresh installation? The rehash script replaces and supercedes the dohash, mkimap, and undohash scripts. It can be used on a fresh installation to create either type of hashing, or can be used to convert an existing installation to another type. Essentially, it reviews the existing directory structure, adding what is missing, and converting what needs to be converted. If it is only an upgrade, we should work on making it available on a fresh installation. In either case, we should make sure that we have all of this documented correctly. Yes, it would be good to document it. Here's a piece of what I submitted originally: The `rehash' perl script converts the Cyrus directory structure between three hash schemes: none, basic, and full. `none' means no directory hashing at all. `basic' is the current scheme, based on the first letter. `full' is the new hashing scheme. This perl script replaces several of the other perl scripts in the tools directory: dohash, mkimap, and undohash, but not upgradesieve. The name of the new hash scheme must be specified as one of its command-line arguments. -- -Gary Mills--Unix Support--U of M Academic Computing and Networking-
Re: Secure Imap Problems
Ken Murchison wrote: You need to tell Cyrus where your cert, key, and CA file are located. See the tls_* options in imapd.conf(5). So I figured maybe they did something stupid when building the RPMS I downloaded the Cyrus Imapd source: $ cd cyrus-imapd-2.0.16 $ cd man $ grep tls * $ grep tls imapd.conf.5 $ grep tls * grep: CVS: Is a directory $ Perhaps this is something only in the 2.1.x branch? Phil -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, 1759
Re: Secure Imap Problems
Phil Dibowitz wrote: Ken Murchison wrote: You need to tell Cyrus where your cert, key, and CA file are located. See the tls_* options in imapd.conf(5). So I figured maybe they did something stupid when building the RPMS I downloaded the Cyrus Imapd source: $ cd cyrus-imapd-2.0.16 $ cd man $ grep tls * $ grep tls imapd.conf.5 $ grep tls * grep: CVS: Is a directory $ Perhaps this is something only in the 2.1.x branch? Yeah, these entries might be missing from the 2.0.x manpages. tls_cert_file: none File containing the global certificate used for ALL services (imap, pop3, lmtp). tls_key_file: none File containing the private key belonging to the global server certificate. tls_ca_file: none File containing one or more Certificate Authority (CA) certificates. tls_ca_path: none Path to directory with certificates of CAs. -- 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: Secure Imap Problems
On Tue, 21 May 2002, Phil Dibowitz wrote: Either I wasn't clear, or you didn't read my post carefully. I created the certs. What's not there is THE TLS OPTIONS IN THE MAN PAGE. I can only speak for the cyrus-imapd-2.0.16 distribution, but the file doc/install-configure.html discuss the tls_cert_file and tls_key_file options for imapd.conf. Perhaps it would be a good job for a community member to contribute an update to the man pages. Thaddeus Parkinson
Re: Secure Imap Problems
Ken Murchison wrote: Yeah, these entries might be missing from the 2.0.x manpages. tls_cert_file: none File containing the global certificate used for ALL services (imap, pop3, lmtp). tls_key_file: none File containing the private key belonging to the global server certificate. tls_ca_file: none File containing one or more Certificate Authority (CA) certificates. tls_ca_path: none Path to directory with certificates of CAs. But again, I don't think it's just that they're missing from the man pages because 'imapd -s' gives invalid option -s It seems that the imapd from 2.0.x doesn't support secure imap. If I can't run 'imapd -s' then 'master' can't run 'imapd -s' and if 'master' can't run 'imapd -s' then there will be nothing to answer once a secure connection is made to port 993. Phil -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, 1759
Re: Secure Imap Problems
Phil Dibowitz wrote: Ken Murchison wrote: Yeah, these entries might be missing from the 2.0.x manpages. tls_cert_file: none File containing the global certificate used for ALL services (imap, pop3, lmtp). tls_key_file: none File containing the private key belonging to the global server certificate. tls_ca_file: none File containing one or more Certificate Authority (CA) certificates. tls_ca_path: none Path to directory with certificates of CAs. But again, I don't think it's just that they're missing from the man pages because 'imapd -s' gives invalid option -s You can't run imapd from the command line, so any option errors are bogus. Check the imapd(8) manpage, it CAN do imaps. It seems that the imapd from 2.0.x doesn't support secure imap. If I can't run 'imapd -s' then 'master' can't run 'imapd -s' and if 'master' can't run 'imapd -s' then there will be nothing to answer once a secure connection is made to port 993. Try connecting to your imaps port using: openssl s_client -connect localhost:imaps and I bet you'll see errors in imapd.log complaining about missing tls_* options. FYI, I added imaps/pop3s support to imtest/pop3test in CVS. Ken -- 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
unixhierarchy/altnamespace IMAP folders, bug?
When I use the unixhierarchy/altnamespace options in imapd.conf I can't create sub-folders in the main inbox but I can create folders outside the main inbox and then create subfolders in those. When I turn unixhierarchy/altnamespace off then I can create subfolders in the main inbox but not outside of it. I'm pretty new to imap... is this correct behaviour? Jeff
Re: unixhierarchy/altnamespace IMAP folders, bug?
When I use the unixhierarchy/altnamespace options in imapd.conf I can't create sub-folders in the main inbox but I can create folders outside the main inbox and then create subfolders in those. When I turn unixhierarchy/altnamespace off then I can create subfolders in the main inbox but not outside of it. I'm pretty new to imap... is this correct behaviour? Yes. Under normal circumstances (altnamespace off), only the INBOX (and its subfolders) belong to the user, so he cannot create any folders outside it. Trouble is, this differes from the UW IMAP server, which allows personal folders outside the INBOX hierarchy, and many people had got used to that behaviour. Altnamespace placates these people by making subfolders of the INBOX look like seperate top-level folders. Of couse, as a side-effect, INBOX becomes something special which cannot have subfolders. I prefert to train my users in the Cyrus way of thinking and leave the altnamespace off.
Re: unixhierarchy/altnamespace IMAP folders, bug?
Jeff Bert wrote: When I use the unixhierarchy/altnamespace options in imapd.conf I can't create sub-folders in the main inbox but I can create folders outside the main inbox and then create subfolders in those. When I turn unixhierarchy/altnamespace off then I can create subfolders in the main inbox but not outside of it. I'm pretty new to imap... is this correct behaviour? Yup. This was mainly done for forward/backward compatibility. Cyrus uses one internal representation of the folder hierarchy internally, and allowing both subfolders of INBOX and toplevel personal folders would have made the code a big mess (speaking as the person who wrote the altnamespace/unixhiersep code). Keep in mind that these options are mutually exclusive (ie, you can use one without the other). Ken -- 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
imapd timeout
Using 2.0.16 on Linux 2.2.19. I am having trouble with imapd daemons hanging around for a long time. I currently (21 May) have some imapd daemons that have been hanging around for over two weeks (4 May). It is just possible that a couple users have been sending keep-alives that long, but I have a lot more than a couple. I don't set any timeout parameter in imapd.conf, so according to man imapd.conf, it should default to 30 minutes. Is this not true? Does cyrus perhaps recycle imapd processes rather than killing them and starting new ones? If so, what is the logic behind this? (Unix forking is remarkably fast, and starting fresh each time seems much safer/cleaner.) Do I perhaps need to set some /proc/sys/net/ TCP timeout parameter? All help is appreciated.
Compiling (was secure imap)
Ken, Thanks for the clarification on the command-line info. Good to know. In between waiting for responses I removed the 2.0.16 RPM's that were on my system in order to build 2.1.x but decided to stick with 2.0.16. Unfortunately I have no idea where my coworker got those RPMS (which are no longer there), and the most recent ones RedHat has are 2.0.9. So I've resovled to compile Cyrus-imapd myself. I feel better using software I compiled anyway. But of course, I've run into a problem... ./configure ran fine make depend ran fine make all CFLAGS=-O however, gives: ### Making all in /home/phil/cyrus-imapd-2.0.16/sieve make[1]: Entering directory `/home/phil/cyrus-imapd-2.0.16/sieve' gcc -c -I. -I.. -I. -I./../lib -I/usr/include/db3 -I/usr/local/include -DHAVE_CONFIG_H -I. -I. -O \ sieve_err.c make[1]: *** No rule to make target `/usr/local/share/bison.simple', needed by `sieve.o'. Stop. make[1]: Leaving directory `/home/phil/cyrus-imapd-2.0.16/sieve' make: *** [all] Error 1 Phil -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, 1759
Re: unixhierarchy/altnamespace IMAP folders, bug?
On Tue, 2002-05-21 at 13:46, David Wright wrote: SNIP I prefert to train my users in the Cyrus way of thinking and leave the altnamespace off. Yeah, I would too if there weren't so many screwy mail clients out there that depend on this behavior. -Jules
Re: Compiling (was secure imap)
Phil Dibowitz wrote: ./configure ran fine make depend ran fine make all CFLAGS=-O however, gives: I was able to get around this by replacing /usr/local/share/bison.simple with /usr/lib/bison.simple in the sieve/Makefile. Then I got com_err.h not found from imapd.c - I replaced #include com_err.h with #include et/com_err.h Isn't that what automake is for? Stupid autoconf Gr. now index.c needs com_err.h I'm gonna link the damn thing. Phil -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, 1759
Re: Secure Imap Problems
Out of Curiosity do you have OpenSSL installed by any chance, and if so what Version and did you build Cyrus 2.x.x whatever with SSL Compatability in it? Thanks --On Tuesday, May 21, 2002 12:17 PM -0700 Phil Dibowitz [EMAIL PROTECTED] wrote: Galen Johnson wrote: you have to create them yourself...check out: http://www.ncsu.edu/imap/admin/sslcyrus.html Either I wasn't clear, or you didn't read my post carefully. I created the certs. What's not there is THE TLS OPTIONS IN THE MAN PAGE. Phil -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, 1759 --- If Thyne Eyes Deceivee Thee, Pluck Them Out.
RE: Compiling (was secure imap)
We feel... felt your pain... btw here's a pretty good HOWTO I used back when I compiled 2.0.15... note it has some differences since it includes the HIERSEP patch. http://dudle.linuxroot.org/docs/postfix_cyrus/ Jeff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Phil Dibowitz Sent: Tuesday, May 21, 2002 2:28 PM To: [EMAIL PROTECTED] Subject: Re: Compiling (was secure imap) Phil Dibowitz wrote: ./configure ran fine make depend ran fine make all CFLAGS=-O however, gives: I was able to get around this by replacing /usr/local/share/bison.simple with /usr/lib/bison.simple in the sieve/Makefile. Then I got com_err.h not found from imapd.c - I replaced #include com_err.h with #include et/com_err.h Isn't that what automake is for? Stupid autoconf Gr. now index.c needs com_err.h I'm gonna link the damn thing. Phil -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, 1759
Re: Secure Imap Problems
Scott M Likens wrote: Out of Curiosity do you have OpenSSL installed by any chance, and if so what Version and did you build Cyrus 2.x.x whatever with SSL Compatability in it? 0.9.6 (according to RH, 0.9.6-9) I've built Cyrus 2.0.16. A few incorrectly placed includes aside, it wasn't such a chore... Onto configuring again. Phil -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, 1759
seen flag not preserved
Hi, I'm using kmail (1.4.1) together with a cyrus 2.0.16 server. I've a problem that doesn't occur permanently but too often. A message is marked as \seen and \answered and then copied to the trash-folder. After that copy-action it has only the \answered flag set and not the \seen flag, with the result that it appears as unread. I've read that the seen-flag is cached and therefore not written immediately. But kmail operates on the same connection, so I don't see the problem. I've an ethereal log if you need it. Regards, Carsten -- Carsten Burghardt email: [EMAIL PROTECTED] WWW: http://www.magic-shop.de PGP: http://www.magic-shop.de/Carsten_Burghardt.asc
Re: Secure Imap Problems
Alright, brand-spankin' new Cyrus-imap 2.0.16 installed from source.
I want to get regular imap working before secure imap. I got my imapd.conf
file set, and my cyrus.conf file set. I have two users (cyrus and test) who
both have real accounts, and sasldb accounts.
I can't authenticate.
I've tried
sasl_passwd_check: sasldb
sasl_passwd_check: passwd
sasl_passwd_check: shadow
And I've restarted 'master' each time and onery attempt to login gives me:
C: L01 LOGIN test {13}
+ go ahead
C: omitted
L01 NO Login failed: authentication failure
Authentication failed. generic failure
Security strength factor: 0
That's from imtest. (imtest -m login -p imap localhost)
Maybe this is more helpful - when I try to use cyradm localhost I get:
Login failed: authentication failure at
/usr/lib/perl5/site_perl/5.6.0/i386-linux/Cyrus/IMAP/Admin.pm line 78
cyradm: cannot authenticate to server with as test
The users I'm trying are 'cyrus' and 'test.' Cyrus is an 'admin' in
imapd.conf, while test is not.
GAH!
Phil
--
They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety.
-Benjamin Franklin, 1759
Re: Secure Imap Problems
On Tue, 21 May 2002, Thaddeus Parkinson wrote: I can only speak for the cyrus-imapd-2.0.16 distribution, but the file 2.1.4 and 2.1.4 CVS have all these well documented. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
RE: Secure Imap Problems
when you use '-m login' imtest bypasses the sasldb and goes straight
for your shadow file. did you try that with a valid linux user?
also, you might try starting saslauthd:
# saslauthd -a pam
in imapd.conf
sasl_passwd_check: sasldb
# saslpasswd -c cyrususer
# sasldblistusers
*** NOTE WHAT REALM THE PASSWORDS ARE IN ***
# imtest -a cyrususer -u cyrususer -r REALM REALM
Jeff
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Phil Dibowitz
Sent: Tuesday, May 21, 2002 3:18 PM
To: [EMAIL PROTECTED]
Subject: Re: Secure Imap Problems
Alright, brand-spankin' new Cyrus-imap 2.0.16 installed from source.
I want to get regular imap working before secure imap. I got my
imapd.conf
file set, and my cyrus.conf file set. I have two users (cyrus and
test) who
both have real accounts, and sasldb accounts.
I can't authenticate.
I've tried
sasl_passwd_check: sasldb
sasl_passwd_check: passwd
sasl_passwd_check: shadow
And I've restarted 'master' each time and onery attempt to
login gives me:
C: L01 LOGIN test {13}
+ go ahead
C: omitted
L01 NO Login failed: authentication failure
Authentication failed. generic failure
Security strength factor: 0
That's from imtest. (imtest -m login -p imap localhost)
Maybe this is more helpful - when I try to use cyradm localhost I get:
Login failed: authentication failure at
/usr/lib/perl5/site_perl/5.6.0/i386-linux/Cyrus/IMAP/Admin.pm line 78
cyradm: cannot authenticate to server with as test
The users I'm trying are 'cyrus' and 'test.' Cyrus is an 'admin' in
imapd.conf, while test is not.
GAH!
Phil
--
They that can give up essential liberty to obtain a little
temporary safety
deserve neither liberty nor safety.
-Benjamin Franklin, 1759
Re: Secure Imap Problems
try sasl_pwcheck_method: sasldb
- Original Message -
From: Phil Dibowitz [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, May 21, 2002 4:18 PM
Subject: Re: Secure Imap Problems
Alright, brand-spankin' new Cyrus-imap 2.0.16 installed from source.
I want to get regular imap working before secure imap. I got my imapd.conf
file set, and my cyrus.conf file set. I have two users (cyrus and test)
who
both have real accounts, and sasldb accounts.
I can't authenticate.
I've tried
sasl_passwd_check: sasldb
sasl_passwd_check: passwd
sasl_passwd_check: shadow
And I've restarted 'master' each time and onery attempt to login gives
me:
C: L01 LOGIN test {13}
+ go ahead
C: omitted
L01 NO Login failed: authentication failure
Authentication failed. generic failure
Security strength factor: 0
That's from imtest. (imtest -m login -p imap localhost)
Maybe this is more helpful - when I try to use cyradm localhost I get:
Login failed: authentication failure at
/usr/lib/perl5/site_perl/5.6.0/i386-linux/Cyrus/IMAP/Admin.pm line 78
cyradm: cannot authenticate to server with as test
The users I'm trying are 'cyrus' and 'test.' Cyrus is an 'admin' in
imapd.conf, while test is not.
GAH!
Phil
--
They that can give up essential liberty to obtain a little temporary
safety
deserve neither liberty nor safety.
-Benjamin Franklin, 1759
Re: Secure Imap Problems
NOTE: I'm replying to both Tim and Jeff here
Tim Pushor wrote:
try sasl_pwcheck_method: sasldb
I noticed that the HowTO says sasl_passwd_check while the man page and
official docs say sasl_pwcheck_method - I tried both with the same result...
NOTE: Authentication does seem to work (atleast the Howto says that's what the
following means):
C: L01 LOGIN test {13}
+ go ahead
C: omitted
but then fails a few seconds later with:
L01 NO Login failed: authentication failure
Authentication failed. generic failure
Security strength factor: 0
Jeff Bert wrote:
when you use '-m login' imtest bypasses the sasldb and goes straight
for your shadow file. did you try that with a valid linux user?
Yup, both users are valid linux and sasl users.
also, you might try starting saslauthd:
# saslauthd -a pam
Don't seem to have that...
in imapd.conf
sasl_passwd_check: sasldb
GRRR. The docs say it's sasl_pwcheck_method which one's correct?
# saslpasswd -c cyrususer
I did this for 'test'... but adding the -c flag didn't change anything.
# sasldblistusers
*** NOTE WHAT REALM THE PASSWORDS ARE IN ***
They're all in 'bonanza' which is the name of the host. there's 3 of each one,
one for each authentication mechanism.
# imtest -a cyrususer -u cyrususer -r REALM REALM
imtest -a test -u test -r bonanza bonanza
imtest -a test -u test -r bonanza localhost
neither fully work. They both give the same as above... they seem to work,
then a few seconds later I get an error.
Phil Dibowitz
--
They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety.
-Benjamin Franklin, 1759
Re: imapd timeout
Date: Tue, 21 May 2002 14:08:15 -0700 (PDT) From: David Wright [EMAIL PROTECTED] [...] Does cyrus perhaps recycle imapd processes rather than killing them and starting new ones? If so, what is the logic behind this? (Unix forking is remarkably fast, and starting fresh each time seems much safer/cleaner.) Cyrus does recycle processes. Unix forking is amazingly slow compared to not forking and on servers that receive many connections a second this performance tweak is vital. Larry
HORRIBLE SASL Auth Probs!!
Gah! I'm pulling my hair out trying to get this sasl stuff to work!! I've removed /etc/sasldb and recreated it using saslpasswd... I've tried explicitly giving all information (i.e. saslpasswd -u 'localhost' -c test saslpasswd -u 'bonanza' -c test) (I'd remove the localhost one before trying bonanza). I've tried providing as littls as possible: saslpasswd test Coresponding with the attempts above I've tried: imtest -a test -u test -r localhost localhost imtest -a test -u test -r bonanza bonanza imtest -a test -u test -r bonanza localhost imtest -a test -u test -r localhost bonanza and each of those above with '-p imap' then each one of those above with '-m login' then each one of those above with '-m login -p imap' then # su test $ imtest localhost imtest -m login locahost imtest -p login localhost imtest -m login -p imap localhost The saslauthd that Jeff suggested seems to be a part of the 2.1.2 branch of sasl... which I'm not using. Any help would be MUCH appreciated. Here is some last bit of info for you: Cyrus 2.0.16 compiled from Source # rpm -qa | grep -i sasl cyrus-sasl-1.5.24-17 cyrus-sasl-devel-1.5.24-17 # rpm -qa | grep -i cyrus cyrus-sasl-1.5.24-17 cyrus-sasl-devel-1.5.24-17 perl-Cyrus-2.0.16-3rm My only thought now is that that perl-Cyrus rpm may be messing with things (it's from before when I had installed Cyrus imap from RPM) - but I'm worried to uninstall it for fear if needing it... Phil -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, 1759
RE: imapd timeout
I wonder how many IMAP processes are short lived enough to make a difference? I know at least on my servers they are fairly long running. POP servers are another story.. Tim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Lawrence Greenfield Sent: Tuesday, May 21, 2002 5:48 PM To: Cyrus-Info; David Wright Subject: Re: imapd timeout Date: Tue, 21 May 2002 14:08:15 -0700 (PDT) From: David Wright [EMAIL PROTECTED] [...] Does cyrus perhaps recycle imapd processes rather than killing them and starting new ones? If so, what is the logic behind this? (Unix forking is remarkably fast, and starting fresh each time seems much safer/cleaner.) Cyrus does recycle processes. Unix forking is amazingly slow compared to not forking and on servers that receive many connections a second this performance tweak is vital. Larry
iPAQ Outlook accessing Cyrus
I just got a Compaq (HP?) iPAQ 3835 which uses the Pocket PC 2002 operating system. I can't seem to get the built-in Outlook client to work fully with our Cyrus (2.0.16) server. I can get my email (via IMAP4), but I can't send. One would think this is not related to Cyrus, but it seems that it fails because it tries to create a Sent Items folder on the server. It tries to do this on the same level as INBOX instead of under it. I never see any SMTP traffic come from the unit before getting the failed-to-send message. I know other mail clients allow you to specify a folder prefix (like inbox. ), but the options are very limited on this client. Any thoughts? -Shawn
Re: Cannot run Cyrus Master process : SIGSEGV
On Tue, 21 May 2002, Ema Nymton wrote: Sorry for posting in the CVS list. Server is running on a Debian 2.2r6, that's the matter doc ? Remove the db entries from /etc/nsswitch.conf. Leave the files entries (or whatever else is there) alone. -Chris
RE: HORRIBLE SASL Auth Probs!!
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Phil Dibowitz Sent: Tuesday, May 21, 2002 5:10 PM To: [EMAIL PROTECTED] Subject: HORRIBLE SASL Auth Probs!! Gah! I'm pulling my hair out trying to get this sasl stuff to work!! I've removed /etc/sasldb and recreated it using saslpasswd... I've tried explicitly giving all information (i.e. saslpasswd -u 'localhost' -c test saslpasswd -u 'bonanza' -c test) (I'd remove the localhost one before trying bonanza). I've tried providing as littls as possible: saslpasswd test Coresponding with the attempts above I've tried: imtest -a test -u test -r localhost localhost imtest -a test -u test -r bonanza bonanza imtest -a test -u test -r bonanza localhost imtest -a test -u test -r localhost bonanza and each of those above with '-p imap' then each one of those above with '-m login' then each one of those above with '-m login -p imap' then # su test $ imtest localhost imtest -m login locahost imtest -p login localhost imtest -m login -p imap localhost The saslauthd that Jeff suggested seems to be a part of the 2.1.2 branch of sasl... which I'm not using. Not fully, the way I used to startup saslauthd in cyrus-sasl-1.5.24 was: # saslauthd -a pam also, I never forced the hostname (realm) i just used: # saslpasswd -c cyrususer enter pass then checked what the hostname (realm) was by: # sasldblistusers and i only ever used my FQDN so I don't know if the aliases for the host work or not. Did you compile cyrus-imapd-2.0.16 with the '--with-auth=unix' option... if not that will explain it all. Jeff Any help would be MUCH appreciated. Here is some last bit of info for you: Cyrus 2.0.16 compiled from Source # rpm -qa | grep -i sasl cyrus-sasl-1.5.24-17 cyrus-sasl-devel-1.5.24-17 # rpm -qa | grep -i cyrus cyrus-sasl-1.5.24-17 cyrus-sasl-devel-1.5.24-17 perl-Cyrus-2.0.16-3rm My only thought now is that that perl-Cyrus rpm may be messing with things (it's from before when I had installed Cyrus imap from RPM) - but I'm worried to uninstall it for fear if needing it... Phil -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, 1759
RE: HORRIBLE SASL Auth Probs!!
bummer, i know I'm repeating myself somewhat but here we go: 0) add debug logs to syslog: local6.debug-/var/log/imapd.log auth.debugy -/var/log/saslauthd.log # /etc/init.d/syslog restart 1) start saslauthd # saslauthd -a pam 2) edit /etc/imapd.conf sasl_pwcheck_method: sasldb allowplaintext: yes 3) start cyrus-imapd 4) create a user # saslpasswd -c test 5) check their domain # sasldblistusers 6) chown the sasldb file # chown cyrus.mail /etc/sasldb (or your path to it) 7) try cyradm # cyradm --user test --server realm from sasldblistusers 8) IF THAT FAILS... crap. # tail /var/log/imapd.log # tail /var/log/saslauthd.log post the output... also, what version of berkeley db are you using? Jeff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Phil Dibowitz Sent: Tuesday, May 21, 2002 6:06 PM To: [EMAIL PROTECTED] Subject: Re: HORRIBLE SASL Auth Probs!! Jeff Bert wrote: Did you compile cyrus-imapd-2.0.16 with the '--with-auth=unix' option... if not that will explain it all. I just recompiled and reinstalled with the '--with-auth=unix' option - same exact deal. Any ideas? Phil -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, 1759
Re: imapd timeout
Date: Tue, 21 May 2002 19:32:44 -0700 From: David Wright [EMAIL PROTECTED] Cc: Cyrus-Info [EMAIL PROTECTED] Cyrus does recycle processes. Unix forking is amazingly slow compared to not forking and on servers that receive many connections a second this performance tweak is vital. That explains it; thanks for the explanation. (Still, even 10 forks/second seems entirely do-able. While I don't dispute the principle, I'd think you'd need to get closer to 100 forks/second before forking bottlenecks would become as important as disk I/O bottlenecks.) Unfortunately, experience doesn't agree with your estimate. Larry
