saslauthd: /var/state/saslauthd: No such file or directory
After installing cyrus-imapd-2.1.4 and cyrus-sasl-2.1.2 and trying to start up saslauthd I get this error message: saslauthd: /var/state/saslauthd: No such file or directory so I created that directory manuall and don't get the error any longer but I was curious does this show a sympton that something is wrong in my compile? Everything went fine configuring, making and installing. Just curious. Thanks, Jeff
Re: [PATCH] 2.1.3 reliability patches (REPOST)
On Tue, 07 May 2002, Jeremy Howard wrote: > Most MTAs are pretty good about this. However, when using an IMAP client > to move messages between accounts (e.g. drag and drag in Mozilla, > Netscape, Outlook Express, etc) the source account may well store the > "From " in the message even although the MTA did not send it like this. Well, the correct answer to that one would be to remove the "From " header, maybe rewriting it to Delivered-To:, I think. The "From " header is supposed to keep the envelope recipients, and should never be sent to any MUA, only to the MDA. But any rewriting must be done if, and only if "From " is the very first header, otherwise, the entire thing must be junked. It is very strange that users should get that header when downloading the message through the imap server. Was this one of M$ crappy ideas as always, or someone else botched up for a change, I wonder... -- "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: [PATCH] 2.1.3 reliability patches (REPOST)
Henrique de Moraes Holschuh wrote: >They REALLY shouldn't, and the MTA is supposed to trash them when told to >not add them in the first place, and to rewrite them with the true >information when told to add them. > > Most MTAs are pretty good about this. However, when using an IMAP client to move messages between accounts (e.g. drag and drag in Mozilla, Netscape, Outlook Express, etc) the source account may well store the "From " in the message even although the MTA did not send it like this. This is where our users were constantly complaining until we added this patch--they would try to drag messages to their Cyrus mailbox from another mailbox and get the cryptic (to them) "Message contains invalid header" error. While I can certainly understand that accepting non-RFC compliant messages is something that may not be acceptable in a major distribution (at least by default) I can tell you that doing so has substantially reduced our support load in this case. We probably see this problem more often than most sites, because we are a fast-growing public email provider so people are often migrating messages across to us, and also we have a lot of ex-Hotmail users (and Hotmail is one of the providers that store messages with the "From " prepended).
Re: [PATCH] 2.1.3 reliability patches (REPOST)
On Tue, 07 May 2002, Jeremy Howard wrote: > Note that the original patch was actually by jwade, not by me. I > included it for completeness to show all the patches that we are using > to improve reliability, but we did not write or change that particular > patch. Noted. I have fixed the credits in the patch. -- "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: [PATCH] 2.1.3 reliability patches (REPOST)
On Tue, 07 May 2002, Jeremy Howard wrote: > The problem is that a lot of messages have this header. They shouldn't, They REALLY shouldn't, and the MTA is supposed to trash them when told to not add them in the first place, and to rewrite them with the true information when told to add them. -- "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: [PATCH] 2.1.3 reliability patches (REPOST)
Henrique de Moraes Holschuh wrote: >Duh, I should awake first before I reply. This is a From(space)-type header, >which is useless for Cyrus, and should not be stored inside the message >either. I am NOT adding this patch to Debian's Cyrus package. > > The problem is that a lot of messages have this header. They shouldn't, of course, and it's certainly not RFC-compliant... A nice approach would be to strip this header, rather than just failing to deliver the message.
how do I add new members to a very populated shared folders tree
We have a very, very long shared folder try to which I have to add two new users. Is there an easy way to do this or will I have to do it for every single folder? Badiane
Re: [PATCH] 2.1.3 reliability patches (REPOST)
Henrique de Moraes Holschuh wrote: >I have cleaned up the log messages, and written the fcntl patch to get the >same timeout functionality. See attached file. > > Great! >+ * Modified by [EMAIL PROTECTED] 2002-05-06 to work around seen file locking >+ * problem. Added locking timeout parameter to allow processes that are >+ * waiting for a lock to eventually time out, based on patch by Jeremy Howard > > Note that the original patch was actually by jwade, not by me. I included it for completeness to show all the patches that we are using to improve reliability, but we did not write or change that particular patch.
Re: Migrate From 2.0 to 2.1.4
> doc/install-upgrade.html This information assumes you are upgrading on one box. My situation (and I suspect it is the situation of most production systems) is having 2.1 set up clean (i.e. no mail or metadata) on a second machine, and now I want to get all the mail from my 2.0 machine to it, without upgrading the 2.0 machine. This insures that falling back to the old server is trivial, in case the upgrade fails. The documentation doesn't discuss at all how to transfer mailstores between machines. I think this is what Patrick and I both want to know.
quotas in
Upgraded one of our older Solaris machines to cyrus imap 2.0.16 ... everything is working great, *except* that quotes aren't being enforced, or calculated, properly ... For example: relay:/home/centre/c/cyrus> /usr/cyrus/bin/quota user.038073c Quota % UsedUsed Root 5000 1346740 user.038073c relay:/home/centre/c/cyrus> /usr/cyrus/bin/quota -f user.038073c user.038073c: usage was 6902363, now 12342416 Quota % UsedUsed Root 5000 241 12053 user.038073c In fact, I just ran a 'quota -f' to force it to re-calculate everyone's mail quota/usage, and even afterwards: relay:/home/centre/c/cyrus> /usr/cyrus/bin/quota -f user.046959s user.046959s: usage was 7557475, now 11349515 Quota % UsedUsed Root 5000 221 11083 user.046959s Something I don't have setup right? :( Thanks ...
Re: Migrate From 2.0 to 2.1.4
Patrick Lin wrote: > > I actually Run : > > - Cyrus imap 2.0.16 (auth against sasldb) > - Cyrus SASL 1.5.24 > - Sendmail Switch 2.1.0 > > And want to use : > > - Cyrus Imap 2.1.4 (auth against LDAP) > - Cyrus Sasl 2.1.2 > - Sendmail 8.12.3 + SASLv2 Patch (from Ken) > - LDAP (probably open ldap) > - OpensSSL 0.9.6c > > I want to know > * If I have something to aware of ? > * Any tips . > * Comments doc/install-upgrade.html -- 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
db3 -> db4
I think I have the build process down... Can anyone warn me about what I might have to do if I go from 2.1.3 built against db3 (3.1.17) to 2.1.4 built against db4 (4.0.14)? mailboxes is skiplist, everything else is 'normal'. A clean install and a recover of the mailboxes is do-able, but not desired. Thanks, Jason -- Jason Englander [EMAIL PROTECTED]
Migrate From 2.0 to 2.1.4
I actually Run : - Cyrus imap 2.0.16 (auth against sasldb) - Cyrus SASL 1.5.24 - Sendmail Switch 2.1.0 And want to use : - Cyrus Imap 2.1.4 (auth against LDAP) - Cyrus Sasl 2.1.2 - Sendmail 8.12.3 + SASLv2 Patch (from Ken) - LDAP (probably open ldap) - OpensSSL 0.9.6c I want to know * If I have something to aware of ? * Any tips . * Comments Thanks a lot P.
Re: Duplicates triplicates ...
On Mon, May 06, 2002 at 11:37:26AM -0600, Scott M Likens wrote: > Well i just wanted to say quite simply, i haven't gotten one Duplicate yet. > Either Postfix is removing them, or something. Because as i use Mulberry > client and enjoy it very much, i see not one duplicate ever. > > Maybe i did something really good for once. I think it is because you have sieve delivery duplicate removal on. I am using postfix/maildrop (courier) and I have seen a lot of duplicates .. and all from binary.net as told by someone before... Luc > > >
Re: Duplicates triplicates ...
> On Mon, 06 May 2002 11:37:26 -0600, > Scott M Likens <[EMAIL PROTECTED]> (sml) writes: sml> Well i just wanted to say quite simply, i haven't gotten one sml> Duplicate yet. Either Postfix is removing them, or something. sml> Because as i use Mulberry client and enjoy it very much, i see not sml> one duplicate ever. Well, not to take Mulberry down, but I suspect this is a difference between those sites using the duplicate delivery trap in Cyrus, and those that aren't. We have duplicate delivery enabled and as I might expect, I haven't seen these dups either. Anyway, just speculation since I haven't actually looked into this matter myself. -- Amos
Duplicates triplicates ...
Well i just wanted to say quite simply, i haven't gotten one Duplicate yet. Either Postfix is removing them, or something. Because as i use Mulberry client and enjoy it very much, i see not one duplicate ever. Maybe i did something really good for once.
Another example of a locked POP3 session
I had a complaint this morning that a user was unable to read mail with Outlook because the mailbox was locked. I found an old pop3d process with an established connection to his workstation. UID PID PPID CSTIME TTY TIME CMD cyrus 10763 725 0 22:30:41 ?0:01 pop3d It was sleeping in a read() from the network. # truss -p 10763 read(0, 0x001488F0, 4096) (sleeping...) I don't have `poptimeout' set in /etc/imapd.conf. Shouldn't pop3d have timed out after ten minutes of idle time? I'm running cyrus version v2.1.0pre on this system. -- -Gary Mills--Unix Support--U of M Academic Computing and Networking-
RE: New RPMs
> Simon wrote: > > Did you install on RedHat 7.2? If yes, make sure you have current > updates installed, if no, I don't know. > No I use Linux Mandrake 8.1 > This is what I have installed: > > [root@dhcp-141-104 SRPMS]# rpm -qa | grep cyrus > cyrus-imapd-devel-2.1.4-1 > cyrus-sasl-md5-2.1.2-1 > cyrus-imapd-2.1.4-1 > cyrus-imapd-utils-2.1.4-1 > cyrus-sasl-devel-2.1.2-1 > cyrus-sasl-plain-2.1.2-1 > cyrus-sasl-2.1.2-1 > [root@dhcp-141-104 SRPMS]# rpm -qa | grep openssl > openssl-devel-0.9.6b-8 > openssl-0.9.6b-8 > would you please run: # rpm -qa --filesbypkg | grep libssl.so.2 # rpm -qa --filesbypkg | grep libcrypto.so.2 and tell me what is shows? that would tell me what package(s) contain those files. Thanks, Jeff
Re: [PATCH] 2.1.3 reliability patches (REPOST)
On Mon, 06 May 2002, Henrique de Moraes Holschuh wrote: > > In addition, this patch does not reject messages that include "From " at > > the start. We frequently observe these messages, and have seen no > > problems in accepting them. > > Hmm... Cyrus probably won't have any sort of problem storing them either. I > think the From reject is there to help debugging bad installs where the MTA > adds a From line. I will take it for Debian, it enhances functionality for > those that configure Cyrus right. Duh, I should awake first before I reply. This is a From(space)-type header, which is useless for Cyrus, and should not be stored inside the message either. I am NOT adding this patch to Debian's Cyrus package. -- "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: [PATCH] 2.1.3 reliability patches (REPOST)
(bcc'ed to cyrus-bugs+)
On Mon, 06 May 2002, Jeremy Howard wrote:
> safe-flock.diff
>
> This is jwade's safer flock code which resolves problems with waiting
> forever for locks. Although not required on all platforms, we are not
> aware of any downsides to using it and therefore we recommend its use.
I have cleaned up the log messages, and written the fcntl patch to get the
same timeout functionality. See attached file.
--
"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
Index: lib/lock_fcntl.c
===
RCS file: /home/cvs/debian/cyrus21-imapd/lib/lock_fcntl.c,v
retrieving revision 1.1.1.1
retrieving revision 1.3
diff -u -r1.1.1.1 -r1.3
--- lib/lock_fcntl.c2 Oct 2001 21:08:13 - 1.1.1.1
+++ lib/lock_fcntl.c6 May 2002 13:21:46 - 1.3
@@ -49,6 +49,10 @@
#include
#include "lock.h"
+#include
+
+/* Locking timeout parameter */
+#define MAXTIME 99
const char *lock_method_desc = "fcntl";
@@ -67,6 +71,19 @@
* 'failaction' is provided, it is filled in with a pointer to a fixed
* string naming the action that failed.
*
+ * Modified by [EMAIL PROTECTED] 2002-05-06 to work around seen file locking
+ * problem. Added locking timeout parameter to allow processes that are
+ * waiting for a lock to eventually time out, based on patch by Jeremy Howard
+ *
+ * Sets lock in non-blocking fashion and then retries until a
+ * maximum delay is reached or the lock succeeds.
+ *
+ * As written, uses a quadratic backoff on retries with MAXTIME being
+ * the longest interval delay. Total delay time is the sum of the squares
+ * of all integers whose square is less than MAXTIME. In the case of
+ * MAXTIME = 99 this is 0+1+4+9+16+25+36+49+64+81= 285 Seconds
+ * This time is arbitrary and can be adjusted
+ *
*/
int lock_reopen(fd, filename, sbuf, failaction)
int fd;
@@ -78,18 +95,35 @@
struct flock fl;
struct stat sbuffile, sbufspare;
int newfd;
+int delay, i;
if (!sbuf) sbuf = &sbufspare;
-for (;;) {
+for (i=0,delay=0;;) {
fl.l_type= F_WRLCK;
fl.l_whence = SEEK_SET;
fl.l_start = 0;
fl.l_len = 0;
- r = fcntl(fd, F_SETLKW, &fl);
+ r = fcntl(fd, F_SETLK, &fl);
if (r == -1) {
- if (errno == EINTR) continue;
- if (failaction) *failaction = "locking";
+ if (errno == EINTR) {
+ continue;
+ }
+ else if (((errno==EAGAIN) || (errno==EACCES)) && (delay < MAXTIME)) {
+ syslog(LOG_DEBUG, "lock_reopen: blocked, sleeping for %d on interval %d
+(%d, %s)",
+ delay, i, fd, filename);
+ sleep(delay);
+ i++;
+ delay = i*i;
+ continue;
+ }
+ if (failaction) {
+ if (delay >= MAXTIME) {
+ *failaction = "locking_timeout";
+ } else {
+ *failaction = "locking";
+ }
+ }
return -1;
}
Index: lib/lock_flock.c
===
RCS file: /home/cvs/debian/cyrus21-imapd/lib/lock_flock.c,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- lib/lock_flock.c2 Oct 2001 21:08:13 - 1.1.1.1
+++ lib/lock_flock.c6 May 2002 13:12:39 - 1.2
@@ -51,6 +51,10 @@
#endif
#include "lock.h"
+#include
+
+/* Locking timeout parameter */
+#define MAXTIME 99
const char *lock_method_desc = "flock";
@@ -69,6 +73,18 @@
* 'failaction' is provided, it is filled in with a pointer to a fixed
* string naming the action that failed.
*
+ * Modified by jwade 4/16/2002 to work around seen file locking problem
+ * Added locking timeout parameter to allow processes that are
+ * waiting for a lock to eventually time out
+ *
+ * Calls flock() in non-blocking fashion and then retries until a
+ * maximum delay is reached or the lock succeeds.
+ *
+ * As written, uses a quadratic backoff on retries with MAXTIME being
+ * the longest interval delay. Total delay time is the sum of the squares
+ * of all integers whose square is less than MAXTIME. In the case of
+ * MAXTIME = 99 this is 0+1+4+9+16+25+36+49+64+81= 285 Seconds
+ * This time is arbitrary and can be adjusted
*/
int lock_reopen(fd, filename, sbuf, failaction)
int fd;
@@ -79,14 +95,28 @@
int r;
struct stat sbuffile, sbufspare;
int newfd;
+int delay, i;
if (!sbuf) sbuf = &sbufspare;
-for (;;) {
- r = flock(fd, LOCK_EX);
+for(i=0,delay=0;;) {
+ r = flock(fd, LOCK_EX|LOCK_NB);
if (r == -1) {
- if (errno == EINTR) continue;
- if (failaction) *failaction = "locking";
+ if (errno == E
Re: New RPMs
jeff bert schrieb: > > I'm trying to install this and it's saying that to files are required: > > libcrypto.so.2 > libssl.so.2 > > but openssl is only up to verion 0.96d so is this just a linked name to > libssl.so.0 ? Did you install on RedHat 7.2? If yes, make sure you have current updates installed, if no, I don't know. This is what I have installed: [root@dhcp-141-104 SRPMS]# rpm -qa | grep cyrus cyrus-imapd-devel-2.1.4-1 cyrus-sasl-md5-2.1.2-1 cyrus-imapd-2.1.4-1 cyrus-imapd-utils-2.1.4-1 cyrus-sasl-devel-2.1.2-1 cyrus-sasl-plain-2.1.2-1 cyrus-sasl-2.1.2-1 [root@dhcp-141-104 SRPMS]# rpm -qa | grep openssl openssl-devel-0.9.6b-8 openssl-0.9.6b-8 Simon > > Jeff > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Simon Matter > > Sent: Monday, May 06, 2002 12:10 AM > > To: info-cyrus > > Subject: New RPMs > > > > > > I have upgraded my Cyrus RPMs to cyrus-imapd-2.1.4 / cyrus-sasl-2.1.2. > > The binary packages have been compiled on RedHat 7.2. For those > > interested, here are the links: > > > > http://home.teleport.ch/simix/Cyrus-sasl/ > > http://home.teleport.ch/simix/Cyrus-imapd/ > > > > Simon > > > > > > > > > > > >
Re: Mail Loop
On Mon, 6 May 2002, James Spooner wrote: > Is anyone else getting a heap of duplicates from this list? > Yes. The mails seem to be reposted to the ml by ts2.bynari.net for some reason and loop until they are rejected because of the increasing hop count. It started yesterday evening (GMT +2000). > Received: (from postman@localhost) > by lists2.andrew.cmu.edu (8.12.0.Beta16/8.12.2.Beta3) id g45BNiU8012862 > for info-cyrus-list; Sun, 5 May 2002 07:23:44 -0400 (EDT) > Received: from ts2.bynari.net (gw1.bynari.net [216.234.228.98]) ^^ > by lists2.andrew.cmu.edu (8.12.0.Beta16/8.12.2.Beta3) with ESMTP id > g45BNgi5012858 > for <[EMAIL PROTECTED]>; Sun, 5 May 2002 07:23:42 -0400 (EDT) > Received: from ravms by ts2.bynari.net with mail-ok (Exim 3.33 #2) > id 174Kuh-0008RK-00; Sun, 05 May 2002 07:14:51 -0500 > Received: from [216.234.235.143] (helo=raq2.bynari.net) > by ts2.bynari.net with esmtp (Exim 3.33 #2) > id 174Kuf-0008RE-00 > for [EMAIL PROTECTED]; Sun, 05 May 2002 07:14:50 -0500 > Received: from lists2.andrew.cmu.edu (LISTS2.andrew.cmu.edu [128.2.10.216]) > by raq2.bynari.net (8.10.1/8.10.1) with ESMTP id g45BZux15268 > for <[EMAIL PROTECTED]>; Sun, 5 May 2002 06:35:56 -0500 (CDT) > Received: (from postman@localhost) > by lists2.andrew.cmu.edu (8.12.0.Beta16/8.12.2.Beta3) id g45BC5BI012715 > for info-cyrus-list; Sun, 5 May 2002 07:12:05 -0400 (EDT) > Received: from web14103.mail.yahoo.com (web14103.mail.yahoo.com > [216.136.172.133]) > by lists2.andrew.cmu.edu (8.12.0.Beta16/8.12.2.Beta3) with SMTP id > g45BC1i5012711 > for <[EMAIL PROTECTED]>; Sun, 5 May 2002 07:12:01 -0400 (EDT) > -- Best regards / Mit freundlichen Gruessen, Andreas Amann < [EMAIL PROTECTED] > =
Re: [PATCH] 2.1.3 reliability patches (REPOST)
On Mon, 06 May 2002, Jeremy Howard wrote: > The patches described here can be downloaded from: [...] I will probably add some of them to the Debian-packaged version of cyrus, after some testing. > master-avail.diff [...] > Therefore a per-process status is required to track which pids are busy > servicing a request. Then on SIGCHLD ready_workers is decremented, > unless this status shows that the pid had already notified master that > it was unavailable. We have found that this patch successfully tracks > process counts under high load and when killing children with a range of > signals. Sounds good. I will try to use this patch. > shutdown.diff [...] > This is because we found that imapd_out would often be corrupted. > Because we are not using TLS, we could check for corruption by making > sure that tls_conn was false. This will *NOT* work if you are using TLS. > A real fix is to work out why imapd_out is getting corrupted--we have > not as yet succeeded at doing that. Hmm, I will have to wait this to be cleared up first. > linux-limit.c > > Linux does not recognise RLIM_INFINITY. This patch uses 64000 instead. > The patch really should add a configure test instead of just using this > on all systems. Without using this patch imapd will run out of FDs on > moderately loaded systems. This is glibc breakage, not the kernel. I am waiting to see what the glibc guys will do about it. When I get a proper fix, I will send it here. > safe-flock.diff > > This is jwade's safer flock code which resolves problems with waiting > forever for locks. Although not required on all platforms, we are not > aware of any downsides to using it and therefore we recommend its use. I will also look over this patch, looks useful. > rated.diff > > This patch connects to a Unix socket /var/state/rated/rated and sends > the username and message size during a BODY FETCH or an APPEND. This is > important to track per-user bandwidth, which is necessary to avoid DOS > attacks from users sending or receiving too much data. You need to write > a daemon to listen on this socket and keep counters of bandwidth per > user, if you want to use this patch. Interesting. I hope this funcionality gets added to Cyrus. > allow8bit.diff > > This patch removes the code that replaces 8bit headers with 'X'. Most > mail systems still seem to use 8bit headers, and we have not found any > problem in accepting them. I will probably add something like this to Debian's Cyrus sooner or later. I'd rather have it runtime-configurable, though (defaults to disabled, of course). > In addition, this patch does not reject messages that include "From " at > the start. We frequently observe these messages, and have seen no > problems in accepting them. Hmm... Cyrus probably won't have any sort of problem storing them either. I think the From reject is there to help debugging bad installs where the MTA adds a From line. I will take it for Debian, it enhances functionality for those that configure Cyrus right. -- "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: New RPMs
I've got up to 6 copies and this answer of Birger came twice ! Birger Toedtmann schrieb: > > Mike Brady schrieb am Mon, May 06, 2002 at 10:32:11AM +1200: > > No > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of jeff bert > > Sent: Monday, 6 May 2002 10:14 p.m. > > To: Simon Matter; info-cyrus > > Subject: RE: New RPMs > > > > > > I've gotten 5 copies of this same email... am I the only one who got this > > many? > > Me too. Both "bulk"s (5 mails each) came from Simon. Something wrong with > his MUA/MTA? > > Regards, > > Birger -- ,,, /"^"\ ( o o ) ---oOOO--(_)--OOOo Paul HeßTel +49-711/898-1191 Abt. ZS22 Fax +49-711/898-2036 SVI Stgt-Löwentor E-Mail [EMAIL PROTECTED] .oooO ( ) Oooo. -\ (( ) \_) ) / (_/ begin:vcard n:Hess;Paul tel;fax:+49-711-898-2036 tel;work:+49-711-898-1191 x-mozilla-html:FALSE url:http://www.svi.de org:SVI GmbH;ZS22 adr:;;Loewentor Str.65;Stuttgart;Baden-Wuerttemberg;70376;Deutschland version:2.1 email;internet:[EMAIL PROTECTED] fn:Paul Hess end:vcard
Re: New RPMs
Mike Brady schrieb am Mon, May 06, 2002 at 10:32:11AM +1200: > No > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of jeff bert > Sent: Monday, 6 May 2002 10:14 p.m. > To: Simon Matter; info-cyrus > Subject: RE: New RPMs > > > I've gotten 5 copies of this same email... am I the only one who got this > many? Me too. Both "bulk"s (5 mails each) came from Simon. Something wrong with his MUA/MTA? Regards, Birger
RE: New RPMs
I'm trying to install this and it's saying that to files are required: libcrypto.so.2 libssl.so.2 but openssl is only up to verion 0.96d so is this just a linked name to libssl.so.0 ? Jeff > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Simon Matter > Sent: Monday, May 06, 2002 12:10 AM > To: info-cyrus > Subject: New RPMs > > > I have upgraded my Cyrus RPMs to cyrus-imapd-2.1.4 / cyrus-sasl-2.1.2. > The binary packages have been compiled on RedHat 7.2. For those > interested, here are the links: > > http://home.teleport.ch/simix/Cyrus-sasl/ > http://home.teleport.ch/simix/Cyrus-imapd/ > > Simon > > > > > >
Re: New RPMs
I have got several copies of this e-mail..., I didn't count'em before I threw them away... -- Veigar Freyr [EMAIL PROTECTED] - Original Message - From: "jeff bert" <[EMAIL PROTECTED]> To: "Simon Matter" <[EMAIL PROTECTED]>; "info-cyrus" <[EMAIL PROTECTED]> Sent: Monday, May 06, 2002 10:14 AM Subject: RE: New RPMs > I've gotten 5 copies of this same email... am I the only one who got this > many? > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Simon Matter > > Sent: Monday, May 06, 2002 12:10 AM > > To: info-cyrus > > Subject: New RPMs > > > > > > I have upgraded my Cyrus RPMs to cyrus-imapd-2.1.4 / cyrus-sasl-2.1.2. > > The binary packages have been compiled on RedHat 7.2. For those > > interested, here are the links: > > > > http://home.teleport.ch/simix/Cyrus-sasl/ > > http://home.teleport.ch/simix/Cyrus-imapd/ > > > > Simon > > > > > > > > > > > > > > > > >
RE: New RPMs
No -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of jeff bert Sent: Monday, 6 May 2002 10:14 p.m. To: Simon Matter; info-cyrus Subject: RE: New RPMs I've gotten 5 copies of this same email... am I the only one who got this many? > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Simon Matter > Sent: Monday, May 06, 2002 12:10 AM > To: info-cyrus > Subject: New RPMs > > > I have upgraded my Cyrus RPMs to cyrus-imapd-2.1.4 / cyrus-sasl-2.1.2. > The binary packages have been compiled on RedHat 7.2. For those > interested, here are the links: > > http://home.teleport.ch/simix/Cyrus-sasl/ > http://home.teleport.ch/simix/Cyrus-imapd/ > > Simon > > > > > > >
RE: New RPMs
I've gotten 5 copies of this same email... am I the only one who got this many? > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Simon Matter > Sent: Monday, May 06, 2002 12:10 AM > To: info-cyrus > Subject: New RPMs > > > I have upgraded my Cyrus RPMs to cyrus-imapd-2.1.4 / cyrus-sasl-2.1.2. > The binary packages have been compiled on RedHat 7.2. For those > interested, here are the links: > > http://home.teleport.ch/simix/Cyrus-sasl/ > http://home.teleport.ch/simix/Cyrus-imapd/ > > Simon > > > > > > >
Valid user account format in Cyrus 2.0.16
Hello.. I am setting up an enviroment as follows, OS : SuSE Linux 7.3 Cyrus IMAPD : 2.0.16 SASLDB : 1.5.24 Sendmail : 8.11.6 I am using SASLDB/Plaintext as the authentication for both Cyrus and Sendmail, and I found that, if my user name for the Cyrus system is making up of numbers only (e.g. 00010001), I cannot login successfully. But the system works ok if the user name is made up of alphabet (e.g. test). I wouldl ike to ask, if there are any limitation on how the username should be? Thanks and regards, Ronnie mail2web - Check your email from the web at http://mail2web.com/ .
RE: New RPMs
No need to answer this... I d/l the 2.1.4 tarball and read the changes.html doc: Changes to the Cyrus IMAP Server since 2.0.16 ... - altnamespace: it is now possible to display user mailboxes as siblings to the INBOX at the top-level (Ken Murchison) - unixhierarchysep: it is now possible possible to use slash as the hierarchy seperator, instead of a period. (Ken Murchison, inspired by David Fuchs, [EMAIL PROTECTED]) ... Coolio! Jeff > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of jeff bert > Sent: Monday, May 06, 2002 12:50 AM > To: info-cyrus > Subject: RE: New RPMs > > > does this version allow the admin to setup mailboxes in the hiersep manner > like that patch to 2.0.15 so that you can store mailboxes as > [EMAIL PROTECTED] ? > > and thanks for making them into RPM's. I had to do a bunch of > voodoo to get > the tarball cyrus-imap to install with my RPM installs of cyrus-sasl in > cyrus-imap-2.0.15 > > Jeff > > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Simon Matter > > Sent: Monday, May 06, 2002 12:10 AM > > To: info-cyrus > > Subject: New RPMs > > > > > > I have upgraded my Cyrus RPMs to cyrus-imapd-2.1.4 / cyrus-sasl-2.1.2. > > The binary packages have been compiled on RedHat 7.2. For those > > interested, here are the links: > > > > http://home.teleport.ch/simix/Cyrus-sasl/ > > http://home.teleport.ch/simix/Cyrus-imapd/ > > > > Simon > > > > > > > >
Re: New RPMs
jeff bert schrieb: > > does this version allow the admin to setup mailboxes in the hiersep manner > like that patch to 2.0.15 so that you can store mailboxes as > [EMAIL PROTECTED] ? I don't know about this feature. I didn't change anything so if it's not in 2.1.4, it's not there. Simon > > and thanks for making them into RPM's. I had to do a bunch of voodoo to get > the tarball cyrus-imap to install with my RPM installs of cyrus-sasl in > cyrus-imap-2.0.15 > > Jeff > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Simon Matter > > Sent: Monday, May 06, 2002 12:10 AM > > To: info-cyrus > > Subject: New RPMs > > > > > > I have upgraded my Cyrus RPMs to cyrus-imapd-2.1.4 / cyrus-sasl-2.1.2. > > The binary packages have been compiled on RedHat 7.2. For those > > interested, here are the links: > > > > http://home.teleport.ch/simix/Cyrus-sasl/ > > http://home.teleport.ch/simix/Cyrus-imapd/ > > > > Simon > > > > > >
[PATCH] 2.1.3 reliability patches (REPOST)
The patches described here can be downloaded from:
http://jhoward.fastmail.fm/patches/cyrus/imap-diff.tgz
As I mentioned last week, we have now resolved the main reliability
problems with 2.1.3. The problems were:
- Failure to flush buffers and therefore failure to close some connections
- Failure to call shutdown() to safely close some connections
- Corruption of a pointer causing segfault on shutdown of some sessions
- Failure to maintain connection count correctly in master after a child
segfault
Attached is a set of diffs against 2.1.3 that fix these and other
problems, written by Jeremy Howard and Robert Mueller of FastMail.FM
(except for those taken from 2.1.4, of course!). However, these diffs
are not production-ready: they work in our specific environment, but you
should review them carefully before applying in your environment. Having
said that, in our particular environment they have now fixed all of the
problems we were having, and we have now had no problems for four days
(previously we had to restart at least once a day). If you are using
Linux 2.4 and not using TLS most patches will work directly.
In addition to the basic reliability fixes, I'm also attaching most of
the patches that we are using since we added a number of features and
fixes which may be useful for others. I'd be interested in hearing any
comments on how to achieve any of these goals better, or in seeing some
of the patches fleshed out more fully.
The diffs are against 2.1.3 instead of 2.1.4 because 2.1.4 includes some
experimental code and our focus is at this stage on reliability. It
would be great if Project Cyrus could start using a scheme like Linux
and Perl where experimental releases get odd-numbered versions. That way
we could focus on completely stablising a release while adding new
features to a different tree. In the attached I have included some
patches from 2.1.4 where they are for reliability rather than new
features. Here's a complete description of the attached patches, in
order of priority. The first two patches are vital for production
systems IMO.
master-avail.diff
This patch is very important. Without it, any error causing a process to
segfault will eventually cause master to stop accepting connections.
master previously kept track of available processes in "ready_workers"
by listening to notifications from children. If a child died, no
notification would be sent. Therefore there would be less ready_workers
than master actually knew about. Over time, the pool of processes would
shrink until eventually no new processes would be accepted.
To fix this problem master should instead use the CHLD signal to track
ready_workers, as well as being notified when a child is busy servicing
a request. However if a child dies while in the middle of servicing a
request, it would decrement ready_workers twice (once when starting to
service the request, one on SIGCHLD).
Therefore a per-process status is required to track which pids are busy
servicing a request. Then on SIGCHLD ready_workers is decremented,
unless this status shows that the pid had already notified master that
it was unavailable. We have found that this patch successfully tracks
process counts under high load and when killing children with a range of
signals.
master-avail.diff also includes a patch from 2.1.4 that correctly
handles ALRM signals.
shutdown.diff
imapd and popd did not call shutdown() before close(). shutdown() should
always be called first to flush buffers and notify that no further data
is expected. On some OSs this is called automatically, but this should
not be assumed. This patch adds shutdown() calls as appropriate.
A socket will not close correctly if data is waiting to be read. This
patch adds a prot_fill call to ensure that receive buffers are empty.
Without this we frequently saw sockets waiting in a CLOSE_WAIT state.
***IMPORTANT:
In shut_down() you'll notice the following patch (and an equivalent in
pop3d.c):
-if (imapd_out) {
+
+if (imapd_out && !imapd_out->tls_conn) {
This is because we found that imapd_out would often be corrupted.
Because we are not using TLS, we could check for corruption by making
sure that tls_conn was false. This will *NOT* work if you are using TLS.
A real fix is to work out why imapd_out is getting corrupted--we have
not as yet succeeded at doing that.
linux-limit.c
Linux does not recognise RLIM_INFINITY. This patch uses 64000 instead.
The patch really should add a configure test instead of just using this
on all systems. Without using this patch imapd will run out of FDs on
moderately loaded systems.
skiplist.diff
This is the improved skiplist code from 2.1.4. It works well for us.
safe-flock.diff
This is jwade's safer flock code which resolves problems with waiting
forever for locks. Although not required on all platforms, we are not
aware of any downsides to using it and therefore we recommend its use.
---Diffs below this point are not
RE: New RPMs
does this version allow the admin to setup mailboxes in the hiersep manner like that patch to 2.0.15 so that you can store mailboxes as [EMAIL PROTECTED] ? and thanks for making them into RPM's. I had to do a bunch of voodoo to get the tarball cyrus-imap to install with my RPM installs of cyrus-sasl in cyrus-imap-2.0.15 Jeff > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Simon Matter > Sent: Monday, May 06, 2002 12:10 AM > To: info-cyrus > Subject: New RPMs > > > I have upgraded my Cyrus RPMs to cyrus-imapd-2.1.4 / cyrus-sasl-2.1.2. > The binary packages have been compiled on RedHat 7.2. For those > interested, here are the links: > > http://home.teleport.ch/simix/Cyrus-sasl/ > http://home.teleport.ch/simix/Cyrus-imapd/ > > Simon > > >
Re: New RPMs
Simon Matter wrote: > I have upgraded my Cyrus RPMs to cyrus-imapd-2.1.4 / cyrus-sasl-2.1.2. So did I for Mandrake 8.2 http://perso.wanadoo.es/olivetti/cyrus/ Bye -- Luca Olivetti Wetron Automatización S.A. http://www.wetron.es/ Tel. +34 93 5883004 Fax +34 93 5883007
New RPMs
I have upgraded my Cyrus RPMs to cyrus-imapd-2.1.4 / cyrus-sasl-2.1.2. The binary packages have been compiled on RedHat 7.2. For those interested, here are the links: http://home.teleport.ch/simix/Cyrus-sasl/ http://home.teleport.ch/simix/Cyrus-imapd/ Simon
