SASLAUTHD problem and some others!
Hello! I need help!!! We are migrating our users from an old cyrus server to 2.1.9 cyrus server and I get this errors... What's that?? thanks! Felix Nov 13 10:03:46 sinclair pop3d[22138]: TLS engine: cannot load CA data Nov 13 10:03:46 sinclair pop3d[22138]: starttls: TLSv1 with cipher RC4-MD5 (128/128 bits reused) no authentication Nov 13 10:03:46 sinclair saslauthd[21761]: AUTHFAIL: user=grusko service=pop realm= Nov 13 10:04:11 sinclair pop3d[22164]: TLS engine: cannot load CA data Nov 13 10:04:11 sinclair pop3d[22164]: starttls: TLSv1 with cipher EXP1024-RC4-SHA (56/128 bits reused) no authentication Nov 13 10:04:29 sinclair imapd[20602]: DBERROR: error fetching user.vluis: DB_RUNRECOVERY: Fatal error, run database recovery Nov 13 10:04:29 sinclair imapd[20602]: DBERROR: error fetching user.vluis: cyrusdb error Nov 13 10:04:39 sinclair saslauthd[21762]: AUTHFAIL: user=mocchi service=pop realm= Nov 13 10:04:41 sinclair saslauthd[21759]: AUTHFAIL: user=pcasaj service=pop realm= -- Felix Cuello [EMAIL PROTECTED] Qodiga/its Av.Santa Fe 882 P.13 Of. E C.P. ABP1059C Tel.: (54) 011 - 4312-1698 Buenos Aires - Argentina
Cyrus DBERROR
I'm really nervous with that... ? what can I do? thanks a lot Felix Nov 13 10:14:32 sinclair lmtpd[22676]: DBERROR: error closing deliverdb: cyrusdb error Nov 13 10:14:32 sinclair lmtpd[22676]: DBERROR: error closing: DB_RUNRECOVERY: Fatal error, run database recovery Nov 13 10:14:32 sinclair lmtpd[22676]: DBERROR: error closing mailboxes: cyrusdb error Nov 13 10:14:32 sinclair lmtpd[22676]: DBERROR: error exiting application: DB_RUNRECOVERY: Fatal error, run database recovery Nov 13 10:14:32 sinclair lmtpd[22676]: DBERROR: error exiting application: cyrusdb error Nov 13 10:14:32 sinclair lmtpd[22667]: unable to tell master 2: Broken pipe Nov 13 10:14:32 sinclair lmtpd[22667]: DBERROR: error closing: DB_RUNRECOVERY: Fatal error, run dat -- Felix Cuello [EMAIL PROTECTED] Qodiga/its Av.Santa Fe 882 P.13 Of. E C.P. ABP1059C Tel.: (54) 011 - 4312-1698 Buenos Aires - Argentina
Re: to live or to fight
On Wed, 13 Nov 2002, Andrei Loukinykh wrote: Well, now I have Cyrus installed (yet not completely tested though) The only 2 things left, which are bothering me now , 2 king of messages in syslog: 1: lmtpd[10260]: DBERROR db4: 9 lockers These are usually harmless, unless they go up in a sudden spike or are accompanied by other problems, its ok. 2: master: setrlimit: Unable to set file descriptors limit to -1: Operation not permitted This is also mostly harmless, it indicates that cyrus was unable to unlimit its max # of file descriptors, which is generally ok. But, may be there's something I can do to fix those bugs , to live with clean logs...? change the code? turn off logging? Since the setrlimit one only occurs at startup, it shouldn't be that big a deal. I can see the DBERROR one being more annoying I guess, but it would require a change to the code. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Cyrus case issues
To complete this thread... I modified the lib/auth_unix.c file with the code below, added a -DENEABLE_EDUNET in the Makefile in the lib dir, did a make clean, make, and make install, and now all of the id's are translated to lowercase, and Cyrus is happy. Thanks Voutsinas! A possible addition for future versions of Cyrus: maybe add a config option in the cyrus.conf file to allow this translation without re-compiling. Voutsinas Nikos wrote: . /* Map of which characters are allowed by auth_canonifyid. * Key: 0 - not allowed (special, ctrl, or would confuse Unix or imapd) * 1 - allowed, but requires an alpha somewhere else in the string * 2 - allowed, and is an alpha * * At least one character must be an alpha. * * This may not be restrictive enough. * Here are the reasons for the restrictions: * * forbidden because of MUTF-7. (This could be fixed.) * :forbidden because it's special in /etc/passwd * /forbidden because it can't be used in a mailbox name * * % forbidden because they're IMAP magic in the LIST/LSUB commands * ?it just scares me * ctrl chars, DEL * can't send them as IMAP characters in plain folder names, I think * 80-FF forbidden because you can't send them in IMAP anyway * (and they're forbidden as folder names). (This could be fixed.) * * + and - are *allowed* although '+' is probably used for userid+detail * subaddressing and qmail users use '-' for subaddressing. * * Identifiers don't require a digit, really, so that should probably be * relaxed, too. */ static char allowedchars[256] = { /* 0 1 2 3 4 5 6 7 8 9 A B C D E F */ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, /* 00-0F */ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, /* 10-1F */ #ifdef ENABLE_EDUNET 0, 1, 1, 1, 1, 0, 0, 1, 1, 1, 0, 1, 1, 1, 1, 0, /* 20-2F */ 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 1, 1, 1, 1, 0, /* 30-3F */ 1, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, /* 40-4F */ 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 1, 1, 1, 1, 1, /* 50-5F */ #else 1, 1, 1, 1, 1, 0, 0, 1, 1, 1, 0, 1, 1, 1, 1, 0, /* 20-2F */ 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 1, 1, 1, 1, 0, /* 30-3F */ 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, /* 40-4F */ 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 1, 1, 1, 1, 1, /* 50-5F */ #endif 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, /* 60-6F */ 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 1, 1, 1, 1, 0, /* 70-7F */ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }; /* * Convert 'identifier' into canonical form. * Returns a pointer to a static buffer containing the canonical form * or NULL if 'identifier' is invalid. * * XXX If any of the characters marked with 0 are valid and are cropping up, * the right thing to do is probably to canonicalize the identifier to two * representations: one for getpwent calls and one for folder names. The * latter canonicalizes to a MUTF7 representation. */ char *auth_canonifyid(identifier, len) const char *identifier; size_t len; { static char retbuf[81]; #ifndef ENABLE_EDUNET struct group *grp; #endif char sawalpha; char *p; if(!len) len = strlen(identifier); if(len = sizeof(retbuf)) return NULL; if (strcasecmp(identifier, anonymous) == 0) { return anonymous; } if (strcasecmp(identifier, anybody) == 0 || strcasecmp(identifier, anyone) == 0) { return anyone; } memcpy(retbuf, identifier, len); retbuf[len] = '\0'; /* This used to be far more restrictive, but many sites seem to ignore the * ye olde Unix conventions of username. Specifically, we used to * - drop case on the buffer * - disallow lots of non-alpha characters ('-', '_', others) * Now we do neither of these, but impose a very different policy based on * the character map above. */ if (!strncmp(retbuf, group:, 6)) { #ifndef ENABLE_EDUNET grp = getgrnam(retbuf+6); if (!grp) return 0; strcpy(retbuf+6, grp-gr_name); #endif return retbuf; } /* Copy the string and look up values in the allowedchars array above. * If we see any we don't like, reject the string. */ sawalpha = 0; for(p = retbuf; *p; p++) { switch (allowedchars[*(unsigned char*) p]) { case 0: return NULL; case 2: sawalpha = 1;
Re: to live or to fight
From personal experience I would suggest using skiplist for deliver.db Ever since I have switched from db3_nosync to skiplist my lmtpd's have stopped hanging and the box appears to be performing better. It has only been two weeks since I changed but I haven't had lmtpd hang yet and it used to hang on a daily basis. Andrei Loukinykh wrote: Well, now I have Cyrus installed (yet not completely tested though) The only 2 things left, which are bothering me now , 2 king of messages in syslog: 1: lmtpd[10260]: DBERROR db4: 9 lockers 2: master: setrlimit: Unable to set file descriptors limit to -1: Operation not permitted As I explored this list, the first is related to Berkeley DB (4.0.14) bug, since its counters got incremented ... I've read on sleepycat, that it had been fixed in 4.1. , but this version of DB is not supported by Cyrus.. The second seemes to be kernel , or cyrus-kernel problem ( or not? ), and as I found in list I shouldn't pay much attention to it too.. But, may be there's something I can do to fix those bugs , to live with clean logs...? Best regards, Andrei V. Loukinykh , Evpatoria Ukrtelecom ISP, +380 6569 29376 ~~~ UNIX is like a vigvam - no Windows, no Gates and an Apache inside
how to unsubscribe from this list ?
Does Cyrus preserve flags when it does a COPY?
Hi, RFC 2060 prefers, but does not require, that IMAP servers preserve flags during copy operations. My experience (using the Mail::IMAPClient module) is that it does not. Does it? Thanks, Ian -- 6.4.7. COPY Command Arguments: message set mailbox name Responses: no specific responses for this command Result: OK - copy completed NO - copy error: can't copy those messages or to that name BAD - command unknown or arguments invalid The COPY command copies the specified message(s) to the end of the specified destination mailbox. The flags and internal date of the message(s) SHOULD be preserved in the copy.
Re: Does Cyrus preserve flags when it does a COPY?
Yes, it does, is the answer. - Original Message - From: Ian McDonald [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 13, 2002 4:40 PM Subject: Does Cyrus preserve flags when it does a COPY? Hi, RFC 2060 prefers, but does not require, that IMAP servers preserve flags during copy operations. My experience (using the Mail::IMAPClient module) is that it does not. Does it? Thanks, Ian -- 6.4.7. COPY Command Arguments: message set mailbox name Responses: no specific responses for this command Result: OK - copy completed NO - copy error: can't copy those messages or to that name BAD - command unknown or arguments invalid The COPY command copies the specified message(s) to the end of the specified destination mailbox. The flags and internal date of the message(s) SHOULD be preserved in the copy.
Re: Cyrus case issues
On Wed, 13 Nov 2002, Gardiner Leverett wrote: A possible addition for future versions of Cyrus: maybe add a config option in the cyrus.conf file to allow this translation without re-compiling. I would happly code such a thing, if the CMU crew point me to what must absolutely NOT be folded into lowercase... It has been in my TODO list for a while. -- 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
Cyrus IMAPd 2.1.10 Released
I'm pleased to announce the release of Cyrus IMAPd 2.1.10. This is mostly a bug-fix and cleanup release, with the notable new feature of Berkeley DB 4.1 support. Full details are available in doc/changes.html file that is included in the distribution. As always, the distribution is available at: ftp://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.1.10.tar.gz or http://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.1.10.tar.gz -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Sieve isn't sieving for me - things to check
I went through the same thing.. There were 4 basic things to check 1) Check the location of the sasl2 libs The default location is /usr/lib/sasl2 but apparently sometimes you need to link that dir to /usr/lib/local/sasl2. Get and use strace to check this. 2) Incorrect permissions on the sasl2 dir 3) sasl_minimumlayer should be set low Apparently you should set this var to 0 4) Make sure the plain lib is THERE (This is the one that got me) In the sasl2 dir there should be libplain.so. I'm no expert but these were the main points that every one mentioned. Also if your using pam with plain make sure that pam has a sieve entry. Nick -Original Message- From: David C. Tuttle [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Wed, 13 Nov 2002 12:22:08 -0800 (PST) Subject: Sieve isn't sieving for me I'm sure I'm missing something, but I can't find it in the docs, FAQs or info-cyrus archive... I've got a user who wants to run sieve. So I upgraded Cyrus IMAP to 2.1.9, and I enabled sieve by leaving out --disable-sieve in the configure step and kept all the other options I used for 2.1.5: # ./configure --with-sasl=/usr/local/lib --with-openssl=/usr/local/ssl --disable-otp --without-gssapi --without-krb --with-auth=unix I manually placed a sieve script for a test account sstest in /usr/sieve/s/sstest/myscript.script: -rw-r--r-- 1 cyrus mail 105 Nov 13 12:10 myscript.script require fileinto; if header :contains From [EMAIL PROTECTED] { fileinto INBOX.FROM-DAVID; } I stopped and restarted cyrus, to no effect. I had no luck getting sieveshell to run (it SegFaults), so I thought I could I could just place the sieve script manually. Is this wrong? timsieved runs OK, I can telnet localhost sieve and get a response, but no AUTHENTICATE commands will work, and no mechanisms are listed: # telnet localhost sieve Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. IMPLEMENTATION Cyrus timsieved v1.1.0 SIEVE fileinto reject envelope vacation imapflags notify subaddress relational regex OK /etc/imapd.conf says: sasl_pwcheck_method:saslauthd sasl_mech_list: PLAIN lmtpsocket: /home/cyrus/socket/lmtp tls_sieve_cert_file:disabled tls_sieve_key_file: disabled sievedir: /usr/sieve /etc/cyrus.conf says in its SERVICES section: SERVICES { # add or remove based on preferences # imap cmd=imapd listen=imap prefork=0 imaps cmd=imapd -s listen=imaps prefork=0 maxchild=8 # pop3 cmd=pop3d listen=pop3 prefork=0 pop3s cmd=pop3d -s listen=pop3s prefork=0 sieve cmd=timsieved listen=sieve prefork=0 # at least one LMTP is required for delivery # lmtp cmd=lmtpd listen=lmtp prefork=0 lmtpunix cmd=lmtpd listen=/var/imap/socket/lmtp prefork=0 } Any and all advice would be greatly appreciated. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- David C. Tuttle [EMAIL PROTECTED] Product Engineer/System Administrator (707) 445-4355 x21 Silicon Defense 513 2nd St, Eureka, CA 95501 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
RE: Sieve isn't sieving for me
This may or may not be your problem, but when I had the exact same problem, I fixed it like this. (Everything else worked fine, but sieve showed no available mechs, and I couldn't login using sieveshell.) When I first built Cyrus, I symlinked to the /usr/lib/sasl2 directory like this: # ln -s /usr/local/lib/sasl2/ /usr/lib/sasl2 When I used this, sieve finally showed avalable mechs: #ln -s /usr/local/lib/sasl2/* /usr/lib/sasl2 The first example symlinks the whole /usr/local/lib/sasl2 directory. The second symlinks all the files *in* the directory. The first worked fine with cyrus-imapd and auxprop, but didn't work with sieve. Paul Schmehl ([EMAIL PROTECTED]) TCS Department Coordinator The University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/~pauls/ -Original Message- From: David C. Tuttle [mailto:david;silicondefense.com] Sent: Wednesday, November 13, 2002 2:22 PM To: [EMAIL PROTECTED] Subject: Sieve isn't sieving for me I'm sure I'm missing something, but I can't find it in the docs, FAQs or info-cyrus archive... I've got a user who wants to run sieve. So I upgraded Cyrus IMAP to 2.1.9, and I enabled sieve by leaving out --disable-sieve in the configure step and kept all the other options I used for 2.1.5: # ./configure --with-sasl=/usr/local/lib --with-openssl=/usr/local/ssl --disable-otp --without-gssapi --without-krb --with-auth=unix I manually placed a sieve script for a test account sstest in /usr/sieve/s/sstest/myscript.script: -rw-r--r-- 1 cyrus mail 105 Nov 13 12:10 myscript.script require fileinto; if header :contains From [EMAIL PROTECTED] { fileinto INBOX.FROM-DAVID; } I stopped and restarted cyrus, to no effect. I had no luck getting sieveshell to run (it SegFaults), so I thought I could I could just place the sieve script manually. Is this wrong? timsieved runs OK, I can telnet localhost sieve and get a response, but no AUTHENTICATE commands will work, and no mechanisms are listed: # telnet localhost sieve Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. IMPLEMENTATION Cyrus timsieved v1.1.0 SIEVE fileinto reject envelope vacation imapflags notify subaddress relational regex OK /etc/imapd.conf says: sasl_pwcheck_method:saslauthd sasl_mech_list: PLAIN lmtpsocket: /home/cyrus/socket/lmtp tls_sieve_cert_file:disabled tls_sieve_key_file: disabled sievedir: /usr/sieve /etc/cyrus.conf says in its SERVICES section: SERVICES { # add or remove based on preferences # imap cmd=imapd listen=imap prefork=0 imaps cmd=imapd -s listen=imaps prefork=0 maxchild=8 # pop3 cmd=pop3d listen=pop3 prefork=0 pop3s cmd=pop3d -s listen=pop3s prefork=0 sieve cmd=timsieved listen=sieve prefork=0 # at least one LMTP is required for delivery # lmtp cmd=lmtpd listen=lmtp prefork=0 lmtpunix cmd=lmtpd listen=/var/imap/socket/lmtp prefork=0 } Any and all advice would be greatly appreciated. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- David C. Tuttle [EMAIL PROTECTED] Product Engineer/System Administrator (707) 445-4355 x21 Silicon Defense 513 2nd St, Eureka, CA 95501 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Re: sasl_pwcheck_method: alwaystrue
It's not removed, its just not compiled in by default. You need to compile sasl with --enable-alwaystrue -Rob On Wed, 13 Nov 2002 [EMAIL PROTECTED] wrote: Hello, I can't remember who but someone told me that there was an option for sasl_pwcheck_method called alwaystrue which would bypass the user's password, now I have tryed that but it looks like this doesn't exist as I can't see anything mentioning that and when I try it I see the the Cyrus log file: Nov 13 22:08:31 mail pop3d[331]: [ID 702911 auth.error] unknown password verifier So did someone lie to me maybe ? Or was it maybe removed ? Regards Marc -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Updating /seen from concurrent sessions
Outlook Express users are complaining that their message \Seen status is lost. Snooping traffic, I see that OE is opening a second connection. In duplicating OE's behaviour by hand, I'm finding that I'm more confused than ever about Cyrus's behaviour. We're using Cyrus 2.1.9 on NetApp mounted disk. First up, a description of what OE is doing (in all it's stupidity) - when you read a message, it uses BODY.PEEK so as not to update the \Seen flag. It then apparently closes that connection, opens another, and sets the \Seen status with xxx UID STORE 49 +FLAGS.SILENT (\Seen). It then forgets that connection, and opens a new connection and starts using that for accessing the mailbox. At the Cyrus end, this is useless - the Cyrus that accepts the \Seen update, but holds off updating the .seen file (presumably as a performance optimisation). So the second session doesn't see it until OE eventually closes the first connection. Even sending a NOOP on the \Seen-updating thread would have been enough to trigger Cyrus into updating the .seen file. Cyrus probably needs to update the .seen file if no other activity occurs for a second or two. But - there appears to be a second problem: even if OE had sent a NOOP (or Cyrus decided to write the file), the second session doesn't see the update - it's still holding open an old .seen file, now unlinked (by the rename() that the \Seen-updating thread did). Cyrus needs to periodically stat() the .seen file and compare it's inode number to that of the file it holds open - if the differ, it needs to reopen the file). The RFC isn't entirely helpful on who's at fault here - section 5.5 talks about multiple commands being allowed, provided ambiguity doesn't result. In this case, provided OE waits for the STORE command to complete, I guess it's within it's rights to check the message status from another session. It's largely irrelevant anyway - OE is out there, and getting it fixed would be a hiding to nothing. I realise this is an old known problem, but I've spent some time searching list archives, and other sources looking for an answer. Any help anyone can provide will be gratefully received. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/