Re: [PATCH] Updated master.c process counting patch
I am still waiting to hear from Ken and Lawrence on what they think about these patches? Will any or all of them be implented in the next release? Scott --On Wednesday, May 15, 2002 12:41 PM +1000 Jeremy Howard [EMAIL PROTECTED] wrote: Thanks to Jaska Kivela, some patch formatting problems that caused the master.c process counting patch to not apply cleanly have been resolved. The patch set has been updated, and now also incorporates the master.c race condition patch: http://jhoward.fastmail.fm/patches/cyrus/imap-diff.tgz The only file changed in the patch set is master-avail.diff . master-avail.diff solves the problem that master fails to correctly keep count of child processes if processes do not exit cleanly. This manifests itself as Cyrus failing to accept new connections on one or more ports after a while, when using preforking in imapd.conf. -- +-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-+ Scott W. Adkinshttp://www.cns.ohiou.edu/~sadkins/ UNIX Systems Engineer mailto:[EMAIL PROTECTED] ICQ 7626282 Work (740)593-9478 Fax (740)593-1944 +-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-+ PGP Public Key available at http://www.cns.ohiou.edu/~sadkins/pgp/ msg07755/pgp0.pgp Description: PGP signature
Re: [PATCH] Updated master.c process counting patch
On Wed, 15 May 2002, Scott Adkins wrote: I am still waiting to hear from Ken and Lawrence on what they think about these patches? Will any or all of them be implented in the next release? I don't know what Ken and Lawrence think of these patches, but I just finished porting the child pid tracking of master-avail.diff to 2.1.4CVS, and will post that to this list soon. I will also include it in Debian, which will give some field-testing to the patch. I don't know about all the other patches, though. I have included the safe_flock patches, and I *may* include the alarm and locking stuff in master-avail.diff later, but I must study and understand it first. -- 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
IN-USE, unable to lock maildrop
I have users trying to check mail, they seem to authenticate fine, judging by the logs, but they get the error (at least in mozilla) [IN-USE] Unable to lock maildrop and then they get prompted for username/password again. Nothing obvious appears in my logs, and I haven't made any changes that would cause this! This mail server has been running without a hitch for several months now. Any help is greatly appreciated, Regards, -Jev my ver info is as follows; name : Cyrus version: v2.0.16 vendor : Project Cyrus support-url: http://asg.web.cmu.edu/cyrus os : FreeBSD os-version : 4.5-STABLE environment: Cyrus SASL 1.5.24 Sleepycat Software: Berkeley DB 3.2.9: (January 24, 2001) OpenSSL 0.9.6a 5 Apr 2001 TCP Wrappers -- http://www.ecad.org/~jev/jev.gpg Key fingerprint = 748B 2346 1683 6384 5E8D 4EE3 0807 EADB 999E AB95
Re: [PATCH] Updated master.c process counting patch
On Wed, 15 May 2002, Scott Russell wrote: On Wed, May 15, 2002 at 10:35:04AM -0300, Henrique de Moraes Holschuh wrote: I don't know about all the other patches, though. I have included the safe_flock patches, and I *may* include the alarm and locking stuff in master-avail.diff later, but I must study and understand it first. Are the patches TLS sane / tested? At one point I remember reading The ones I am including in Debian are. No TLS is _not_ an option IMHO. -- 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] Updated master.c process counting patch
On Wed, May 15, 2002 at 10:35:04AM -0300, Henrique de Moraes Holschuh wrote: On Wed, 15 May 2002, Scott Adkins wrote: I am still waiting to hear from Ken and Lawrence on what they think about these patches? Will any or all of them be implented in the next release? I don't know what Ken and Lawrence think of these patches, but I just finished porting the child pid tracking of master-avail.diff to 2.1.4CVS, and will post that to this list soon. I will also include it in Debian, which will give some field-testing to the patch. I don't know about all the other patches, though. I have included the safe_flock patches, and I *may* include the alarm and locking stuff in master-avail.diff later, but I must study and understand it first. Are the patches TLS sane / tested? At one point I remember reading that they wouldn't work with TLS connections. That was some time ago and I might have lost track of the status. -- Regards, Scott Russell ([EMAIL PROTECTED]) Linux Technology Center, System Admin, RHCE. T/L 441-9289 / External 919-543-9289 http://bzimage.raleigh.ibm.com/webcam
[PATCH] 2.1.4 master process counting
Here is the 2.1.4 port of the master process counting patch. It will be in
Debian's Cyrus IMAPd package 2.1.4-9, to be uploaded today or tomorrow.
None of the unrelated changes in the fastmail.fm patchset were included,
just the improvements to the tracking of the number of available workers.
Original patch credits goes to the fastmail.fm crew. Thanks, guys.
Please consider applying this path to 2.1.4 CVS. I will file a bugreport in
bugzilla with 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
Index: master/master.c
===
RCS file: /home/cvs/debian/cyrus21-imapd/master/master.c,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- master/master.c 12 Apr 2002 00:38:19 - 1.13
+++ master/master.c 15 May 2002 13:57:00 - 1.14
-124,6 +124,7
struct centry {
pid_t pid;
+int is_available;
struct service *s;
struct centry *next;
};
-658,6 +659,7
/* add to child table */
c = get_centry();
c-pid = p;
+ c-is_available = 1;
c-s = s;
c-next = ctable[p % child_table_size];
ctable[p % child_table_size] = c;
-792,7 +794,12
/* first thing in the linked list */
/* decrement active count for service */
- if (c-s) c-s-nactive--;
+ if (c-s) {
+ c-s-nactive--;
+ if (c-is_available) c-s-ready_workers--;
+ } else {
+ syslog(LOG_ERR, no service found, child %d, pid);
+ }
ctable[pid % child_table_size] = c-next;
c-next = cfreelist;
-809,7 +816,12
t = c-next;
/* decrement active count for service */
- if (t-s) t-s-nactive--;
+ if (t-s) {
+ t-s-nactive--;
+ if (c-is_available) t-s-ready_workers--;
+ } else {
+ syslog(LOG_ERR, no service found, child %d, pid);
+ }
c-next = t-next; /* remove node */
t-next = cfreelist; /* add to freelist */
-899,24 +911,39
}
}
-void process_msg(struct service *s, int msg)
+void process_msg(struct service *s, struct notify_message *msg)
{
-switch (msg) {
+struct centry * c;
+
+/* Search hash table with linked list for pid */
+c = ctable[msg-service_pid % child_table_size];
+while (c c-pid != msg-service_pid) c = c-next;
+
+/* Did we find it? */
+if (!c || c-pid != msg-service_pid) {
+ syslog(LOG_ERR, can't find pid %d to process message %d,
+ msg-service_pid, msg-message);
+ return;
+}
+
+switch (msg-message) {
case MASTER_SERVICE_AVAILABLE:
+ c-is_available = 1;
s-ready_workers++;
break;
case MASTER_SERVICE_UNAVAILABLE:
+ c-is_available = 0;
s-ready_workers--;
break;
case MASTER_SERVICE_CONNECTION:
s-nconnections++;
break;
-
+
default:
syslog(LOG_ERR, unrecognized message for service '%s': %x,
- s-name, msg);
+ s-name, msg-message);
break;
}
-1340,7 +1367,7
syslog(LOG_NOTICE, ready for work);
for (;;) {
- int r, i, msg, maxfd;
+ int r, i, maxfd;
struct timeval tv, *tvptr;
time_t now = time(NULL);
#if HAVE_UCDSNMP
-1448,13 +1475,15
int j;
if (FD_ISSET(x, rfds)) {
- r = read(x, msg, sizeof(int));
- if (r != sizeof(int)) {
+ struct notify_message message;
+
+ r = read(x, message, sizeof(message));
+ if (r != sizeof(message)) {
syslog(LOG_ERR, got weird response from child: %x, i);
continue;
}
-
- process_msg(Services[i], msg);
+
+ process_msg(Services[i], message);
}
if (Services[i].nactive Services[i].max_workers) {
Index: master/service.c
===
RCS file: /home/cvs/debian/cyrus21-imapd/master/service.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- master/service.c14 May 2002 13:18:25 - 1.2
+++ master/service.c15 May 2002 13:57:00 - 1.3
-79,8 +79,11
void notify_master(int fd, int msg)
{
-if (verbose) syslog(LOG_DEBUG, telling master %d, msg);
-if (write(fd, msg, sizeof(msg)) != sizeof(msg)) {
+struct notify_message notifymsg;
+if (verbose) syslog(LOG_DEBUG, telling master %x, msg);
+notifymsg.message = msg;
+notifymsg.service_pid = getpid();
+if (write(fd, notifymsg, sizeof(notifymsg)) !=
Re: [PATCH] Updated master.c process counting patch
On Wed, May 15, 2002 at 10:52:39AM -0300, Henrique de Moraes Holschuh wrote: On Wed, 15 May 2002, Scott Russell wrote: On Wed, May 15, 2002 at 10:35:04AM -0300, Henrique de Moraes Holschuh wrote: I don't know about all the other patches, though. I have included the safe_flock patches, and I *may* include the alarm and locking stuff in master-avail.diff later, but I must study and understand it first. Are the patches TLS sane / tested? At one point I remember reading The ones I am including in Debian are. No TLS is _not_ an option IMHO. Agreed. I'm thankful to the people who took the time to track this down and write the patch. I'm also thankful to those who added TLS support to the patch :) -- Regards, Scott Russell ([EMAIL PROTECTED]) Linux Technology Center, System Admin, RHCE. T/L 441-9289 / External 919-543-9289 http://bzimage.raleigh.ibm.com/webcam
lmtpd and forwarding MTA error messages
We have recently noticed strange behaviour with our cyrus-imapd-1.0.14
installation. Lmtpd does not seem to forward auto-generated error messages
properly. When a cyrus-imap user sends a mail to a non-existent address, the other
MTA will typically respond with an error message with a null envelope sender
address: ''. Suppose now that this cyrus-imap user also has a sieve forward rule
which will forward this error message to another address. In our case, when lmtpd
forwards the mail by calling sendmail, it seems to be trying to set the sender
address (with the -f option) to the empty return-path: value, generating something
like:
sendmail -f -- rcpt to ...
Consequently, the mail is sent with --@ourimap as the envelope sender. A local
MTA rejects this mail, sending another error message back to --@ourimap, which
of course does not exist. I imaging it should be forwarded with sendmail -f --
rcpt to.
I think there may be two bugs here. Firstly, in send_forward() in lmtpd.c we have:
smbuf[0] = sendmail;
if (return_path != NULL) {
smbuf[1] = -f;
smbuf[2] = return_path;
} else {
smbuf[1] = -f;
smbuf[2] = ;
}
smbuf[3] = --;
smbuf[4] = forwardto;
Should the second line not be if (return_path != '') ? I think I'm right in
saying that if the original message had an envelope sender, then return_path
will be empty here, and hence the problem.
Secondly, in savemsg() in lmtpengine.c we have:
if (!strchr(rpath, '@')) {
hostname = config_servername;
}
fprintf(f, Return-Path: %s%s%s\r\n,
rpath, hostname ? @ : , hostname ? hostname : );
which explains why messages generated by a sieve vacation rule (where the envelope
sender will be ) have:
Return-Path: @imapdomain
I think this might be fixed in the cvs, but I'm not sure.
Thanks.
--
Stephen Grier [EMAIL PROTECTED]
Systems Developer
Computing Services
Queen Mary, University of London
Re: archive.info-cyrus - 13519
On Wed, 15 May 2002, prune wrote: I still have the same probleme as described. maybe the change was not commited in 2.1.4 ?? It was, but it caused another bug that looks exactly the same in particular configurations. The fix is to change line 5226 of configure from: LDFLAGS=$LIB_SASL to LDFLAGS=$LIB_SASL $LDFLAGS -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 235 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: sasl2 + imsp / acap ???
Hi, --On Tuesday, May 14, 2002 10:46 PM -0500 Alon [EMAIL PROTECTED] wrote: | I have imapd running using sasl2 for authentication, but I'd like to add | remote preferences support. Unfortunately, neither smlacapd nor imspd | seem to support sasl2 in their current form. Is there any way to get | either one to authenticate against sasl2, maybe a patch somewhere, or am | I stuck using sasl1 ? Thanks, aLoN We have been working on some updates to imsp that will include sasl2 support and integrated TLS support. We're planning on some other major changes too, including improving the backend database support to improve performance of address books etc, plus some other changes that will tie in directly with some major new functionality that will be appearing in Mulberry hopefully later this year. I'm going to try and get the IMSP stuff available off our site soon. -- Cyrus Daboo
Re: archive.info-cyrus - 13519
Rob Siemborski wrote: [EMAIL PROTECTED]"> On Wed, 15 May 2002, prune wrote: I still have the same probleme as described. maybe the change was notcommited in 2.1.4 ?? It was, but it caused another bug that looks exactly the same inparticular configurations. The fix is to change line 5226 of configurefrom:LDFLAGS=$LIB_SASLtoLDFLAGS=$LIB_SASL $LDFLAGS-Rob-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-Rob Siemborski * Andrew Systems Group * Cyert Hall 235 * 412-268-7456Research Systems Programmer * /usr/contributed Gatekeeper ;) exactly what I did then, another problem when compiling (after configure, during the make) : ### Making all in /opt/src/mail/cyrus-imapd-2.1.4/lib gcc -c -I.. -I/opt/db/BerkeleyDB/include -I/opt/dns/bind/bind-8.3.1/include -I/opt/db/db3/include -I/usr/local/ssl/include/openssl -I/opt/db/mysql/include/mysql -I/opt/ldap/openldap/include -I/opt/mail/cyrus_sasl2/include -I/opt/mail/cyrus2/include -I/usr/local/include -I/usr/local/ssl/include -I/opt/mail/cyrus_sasl2/include -DHAVE_CONFIG_H -I. -I. -Wall -I/opt/dns/bind/bind-8.3.1/include -I/opt/db/db3/include -I/usr/local/ssl/include/openssl -I/opt/db/mysql/include/mysql -I/opt/ldap/openldap/include -I/opt/mail/cyrus_sasl2/include -I/opt/mail/cyrus2/include cyrusdb_skiplist.c cyrusdb_skiplist.c: In function `getsyncfd': cyrusdb_skiplist.c:190: `O_DSYNC' undeclared (first use in this function) cyrusdb_skiplist.c:190: (Each undeclared identifier is reported only once cyrusdb_skiplist.c:190: for each function it appears in.) cyrusdb_skiplist.c: In function `dump': cyrusdb_skiplist.c:1678: warning: int format, long int arg (arg 2) cyrusdb_skiplist.c:1678: warning: int format, long int arg (arg 3) cyrusdb_skiplist.c:1681: warning: unsigned int format, u_long arg (arg 2) cyrusdb_skiplist.c:1687: warning: unsigned int format, u_long arg (arg 2) *** Error code 1 Stop in /opt/src/mail/cyrus-imapd-2.1.4/lib. *** Error code 1 still on freebsd 4.5, gcc 2.95.3 ... Cheers, Prune
Re: archive.info-cyrus - 13519
On Wed, 15 May 2002, prune wrote: exactly what I did then, another problem when compiling (after configure, during the make) : Sorry, I misunderstood you, try this at the top of cyrusdb_skiplist.c: #ifndef O_DSYNC # ifdef O_SYNC #define O_DSYNC O_SYNC /* POSIX */ # else #define O_DSYNC O_FSYNC /* BSD */ # endif #endif -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 235 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: IN-USE, unable to lock maildrop
Jev wrote: I have users trying to check mail, they seem to authenticate fine, judging by the logs, but they get the error (at least in mozilla) [IN-USE] Unable to lock maildrop and then they get prompted for username/password again. Nothing obvious appears in my logs, and I haven't made any changes that would cause this! This mail server has been running without a hitch for several months now. Any help is greatly appreciated, These users are using POP3 to access their mail, and already have an existing connection, which is prohibited by the spec (RFC 1939). If they want to have multiple clients/connections open at the same time, then they will have to use IMAP. 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
Berkeley DB 3.3 and 4.0 on Mac OS X
I you are trying to use Berkeley DB 4.0 (and likely 3.3) on Mac OS X,
you will need the following patch or the mutexes will not work and you
will eventually encounter database corruption.
-kevin
I believe the appended patch
will make Berkeley DB run correctly on your Mac OS X system.
Please let us know if you have any further problems.
Regards,
--keith
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Keith Bostic
Sleepycat Software Inc. [EMAIL PROTECTED]
118 Tower Rd. +1-781-259-3139
Lincoln, MA 01773 http://www.sleepycat.com
*** dbinc/mutex.h.orig Wed Apr 10 14:50:05 2002
--- dbinc/mutex.h Wed Dec 31 19:00:00 1969
***
*** 510,532
* 'set' mutexes have the value 1, like on Intel; the returned value
from
* MUTEX_SET() is 1 if the mutex previously had its low bit clear, 0
otherwise.
*/
! #define MUTEX_SET(tsl) ({ \
! int __one = 1; \
! int __r;\
! tsl_t *__l = (tsl); \
! asm volatile ( \
! 0:\
! lwarx %0,0,%1; \
! cmpwi %0,0; \
! bne 1f; \
! stwcx. %2,0,%1; \
! bne- 0b;\
! 1: \
! : =r (__r) \
! : r (__l), r (__one)); \
! !(__r 1); \
! })
!
#define MUTEX_UNSET(tsl)(*(tsl) = 0)
#define MUTEX_INIT(tsl) MUTEX_UNSET(tsl)
#endif
--- 510,536
* 'set' mutexes have the value 1, like on Intel; the returned value
from
* MUTEX_SET() is 1 if the mutex previously had its low bit clear, 0
otherwise.
*/
! extern int __db_mutex_set __P((volatile tsl_t *));
! static void
! __db_mutex_tas_dummy()
! {
! __asm__ __volatile__( \n\
! .globl ___db_mutex_set \n\
! ___db_mutex_set: \n\
! lwarx r5,0,r3 \n\
! cmpwi r5,0\n\
! bne fail\n\
! addir5,r5,1 \n\
! stwcx. r5,0,r3 \n\
! beq success \n\
! fail: \n\
! li r3,0\n\
! blr \n\
! success: \n\
! li r3,1\n\
! blr);
! }
! #define MUTEX_SET(tsl) __db_mutex_set(tsl)
#define MUTEX_UNSET(tsl)(*(tsl) = 0)
#define MUTEX_INIT(tsl) MUTEX_UNSET(tsl)
#endif
PAM Authentication
Greetings,
I am currently attempting to make Cyrus authenticate via a PAM library
(like our Courier-IMAP system did), but have yet been able to accomplish
this. The following is my imapd.conf file and cyrus.conf file. The MTA I am
using is Postfix, but that seems to be functional.
Cheers,
David
Imapd
configdirectory: /var/imap
partition-default: /home/mail
admins: root cyrus
#srvtab: /var/imap/srvtab
allowanonymouslogin: no
sasl_pwcheck_method: pwcheck
Cyrus
# standard standalone server implementation
START {
# do not delete this entry!
recover cmd=ctl_cyrusdb -r
# this is only necessary if using idled for IMAP IDLE
# idledcmd=idled
}
# UNIX sockets start with a slash and are put into /var/imap/socket
SERVICES {
# add or remove based on preferences
imap cmd=imapd listen=imap prefork=0
imaps cmd=imapd -s listen=imaps prefork=0
# pop3 cmd=pop3d listen=pop3 prefork=0
# pop3scmd=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
# this is only necessary if using notifications
# notify cmd=notifyd listen=/var/imap/socket/notify proto=udp
prefork=1
}
EVENTS {
# this is required
checkpointcmd=ctl_cyrusdb -c period=30
# this is only necessary if using duplicate delivery suppression
delprune cmd=ctl_deliver -E 3 period=1440
# this is only necessary if caching TLS sessions
tlsprune cmd=tls_prune period=1440
}
Re: PAM Authentication
What version of Cyrus? Assuming that you are using v2.1.x, set
sasl_pwcheck_method: saslauthd
and start saslauthd with the '-a pam' option.
David Chait wrote:
Greetings,
I am currently attempting to make Cyrus authenticate via a PAM library
(like our Courier-IMAP system did), but have yet been able to accomplish
this. The following is my imapd.conf file and cyrus.conf file. The MTA I am
using is Postfix, but that seems to be functional.
Cheers,
David
Imapd
configdirectory: /var/imap
partition-default: /home/mail
admins: root cyrus
#srvtab: /var/imap/srvtab
allowanonymouslogin: no
sasl_pwcheck_method: pwcheck
Cyrus
# standard standalone server implementation
START {
# do not delete this entry!
recover cmd=ctl_cyrusdb -r
# this is only necessary if using idled for IMAP IDLE
# idledcmd=idled
}
# UNIX sockets start with a slash and are put into /var/imap/socket
SERVICES {
# add or remove based on preferences
imap cmd=imapd listen=imap prefork=0
imaps cmd=imapd -s listen=imaps prefork=0
# pop3 cmd=pop3d listen=pop3 prefork=0
# pop3scmd=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
# this is only necessary if using notifications
# notify cmd=notifyd listen=/var/imap/socket/notify proto=udp
prefork=1
}
EVENTS {
# this is required
checkpointcmd=ctl_cyrusdb -c period=30
# this is only necessary if using duplicate delivery suppression
delprune cmd=ctl_deliver -E 3 period=1440
# this is only necessary if caching TLS sessions
tlsprune cmd=tls_prune period=1440
}
--
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: [PATCH] Updated master.c process counting patch
Date: Wed, 15 May 2002 08:34:29 -0400 From: Scott Adkins [EMAIL PROTECTED] [...] I am still waiting to hear from Ken and Lawrence on what they think about these patches? Will any or all of them be implented in the next release? I'm still wondering what causes these problems. Some reports say that service processes aren't crashing; if they're not crashing, how is the count getting off? I think in general this stuff is a good idea but I'd like to understand a little better how this is happening. We don't have this problem on any of our servers. Larry
Re: [PATCH] Updated master.c process counting patch
On Wed, 15 May 2002, Lawrence Greenfield wrote: Date: Wed, 15 May 2002 08:34:29 -0400 From: Scott Adkins [EMAIL PROTECTED] [...] I am still waiting to hear from Ken and Lawrence on what they think about these patches? Will any or all of them be implented in the next release? I'm still wondering what causes these problems. Some reports say that service processes aren't crashing; if they're not crashing, how is the count getting off? Good question, isn't it? I am trying to track a segfault in the auth_unix callbacks with SASL 2.1.2 [1], but after that I will try to do a once-over the entire master flow, with and without the child pid tracking patches. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=nobug=145766 We don't have this problem on any of our servers. Do you have preforking enabled? If you do (and if I did undertand the issue correctly), start kill -9'ing service processes, and it should be possible to duplicate the bug. I will try that just now, in fact. -- 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] Updated master.c process counting patch
Date: Wed, 15 May 2002 15:37:50 -0300 From: Henrique de Moraes Holschuh [EMAIL PROTECTED] [...] I'm still wondering what causes these problems. Some reports say that service processes aren't crashing; if they're not crashing, how is the count getting off? Good question, isn't it? I am trying to track a segfault in the auth_unix callbacks with SASL 2.1.2 [1], but after that I will try to do a once-over the entire master flow, with and without the child pid tracking patches. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=nobug=145766 auth_unix is part of the authorization, not part of libsasl. Regardless, this code happens after the service has told the master it's unavailable, so a crash here wouldn't cause the master's count to get off. We don't have this problem on any of our servers. Do you have preforking enabled? If you do (and if I did undertand the issue correctly), start kill -9'ing service processes, and it should be possible to duplicate the bug. I will try that just now, in fact. Sure, if you intentionally kill processes that are waiting for connections this happens. I understand this. But if I did that, master would log messages that the processes were dying incorrectly (signaled to death by 9). Larry
Re: [PATCH] Updated master.c process counting patch
On Wed, 15 May 2002, Lawrence Greenfield wrote: Good question, isn't it? I am trying to track a segfault in the auth_unix callbacks with SASL 2.1.2 [1], but after that I will try to do a once-over the entire master flow, with and without the child pid tracking patches. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=nobug=145766 auth_unix is part of the authorization, not part of libsasl. It registers callbacks with sasl. Sasl calls auth_newstate via the callback interface, and glibc dies in the middle of a getgrent from auth_newstate. The problem could be anywhere. Do you have preforking enabled? If you do (and if I did undertand the issue correctly), start kill -9'ing service processes, and it should be possible to duplicate the bug. I will try that just now, in fact. Sure, if you intentionally kill processes that are waiting for connections this happens. I understand this. But if I did that, master would log messages that the processes were dying incorrectly (signaled to death by 9). The point is, if that indeed happens, log or no log, master loses track of the number of children that can service requests. That would be a bug, and the patch supposedly fixes this bug. It really doesn't matter (for accepting or not the patch) why the child died. I _do_ agree that we have to track down why the children are dying, too. But that is another separate issue. -- 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
quickie patch to reconstruct
Here's a quick patch for reconstruct.c as of 2.0.16 to use the message
sent time instead of sbuf.mtime for previously-unseen mailboxes. This
fixes a problem (as the comment describes) with outlook using INTERNALDATE
for displaying / sorting messages.
(I might have sent this in once before around the 2.0.5-era. I am upgrading
my server to 2.0.16 and found I had to reimplement it, for what its worth)
[cyrus@marvin ~/src/cyrus-imapd-2.0.16/imap] diff reconstruct.c.orig reconstruct.c
450,451c450,451
/* Message file write time is good estimate of internaldate */
message_index.internaldate = sbuf.st_mtime;
---
/* Flag this to set it after the message is parsed */
message_index.internaldate = -1;
462a463,471
/* Some broken IMAP clients (notably Outlook) use INTERNALDATE as
a sort/display key for Date. Using sbuf.mtime makes it appear
to the user as if all the messages in a newly-imported mailbox
were sent at the same time (when the message files were written */
if (message_index.internaldate == -1) {
message_index.internaldate = message_index.sentdate;
}
Eric Sorenson - Systems / Network Administrator - Transmeta Corporation
Re: I Had attempted to do LMTP with Postfix ...
So then i can assume it would be more proper to do LMTP over Unix Socket?
I can do either, i just am trying to find the best method to do this.
Thanks
--On Wednesday, May 15, 2002 8:10 AM -0500 Amos Gouaux
[EMAIL PROTECTED] wrote:
On Tue, 14 May 2002 12:09:14 -0600,
Scott M Likens [EMAIL PROTECTED] (sml) writes:
sml May 13 15:52:32 shell postfix/lmtp[21546]: [ID 197553 mail.info]
sml 614D48A84E: to=[EMAIL PROTECTED],
sml relay=shell.bourg.net[207.229.76.2], delay=1, status=deferred (host
sml shell.bourg.net[207.229.76.2] said: 430 Authentication required)
Ugh, README_FILES/LMTP_README really does need updating. I should
try to do that during our inter-session. Anyway, if you're doing
LMTP over a TCP connection, you'll either need to use LMTP-AUTH
(like SMTP-AUTH), or use the -a flag as in:
SERVICES {
...
lmtp cmd=lmtpd -a listen=[127.0.0.1]:lmtp prefork=0
...
}
Though, if you use the -a flag, be sure to restrict access to
this LMTP server. This can be done by either binding to a specific
IP address as done above and/or by using tcp_wrappers.
sml Also has anyone seen this with the new postfix 1.1.9-Experimental?
sml May 13 15:39:38 shell postfix/lmtp[17534]: [ID 947731 mail.warning]
sml warning: spurious attribute sender in input from lmtp socket
Not yet. I was waiting for the dust to settle a bit before trying
latest Postfix snapshot/release.
--
Amos
Re: [PATCH] Updated master.c process counting patch
Date: Wed, 15 May 2002 16:02:42 -0300 From: Henrique de Moraes Holschuh [EMAIL PROTECTED] [...] The point is, if that indeed happens, log or no log, master loses track of the number of children that can service requests. That would be a bug, and the patch supposedly fixes this bug. It really doesn't matter (for accepting or not the patch) why the child died. Yes, I understand that. However, if the master (in real life situations) is actually losing track of the number of available service processes without one of those service processes crashing (either by the sysadmin or otherwise) then there's some other problem in the child accounting. I'd like to know if there is before doing something that may mask the problem completely. Larry
Re: [PATCH] Updated master.c process counting patch
On Wed, 15 May 2002, Lawrence Greenfield wrote: service processes without one of those service processes crashing (either by the sysadmin or otherwise) then there's some other problem in the child accounting. Well, anything that could cause the messages to be lost will cause trouble for the accounting without the patch. I can't see any other races in there right now, though. I did duplicate the problem caused by children deaths, and I did verify that the patch fixes the problem, so at least that side of things it seems to handle well. Children forking is behaving erratically, though. Before the first connect() to any of the master-controlled services, a random number of children are created (up to the prefork setting). After a connect(), all the missing children (maybe subject to maxforkrate, I didn't test) are created. This might be the way the code is supposed to work, though. I'd like to know if there is before doing something that may mask the problem completely. Timing and logging warnings if the children take too much time to tell us that it is available for work, or die without telling us it was going to exit cleanly would give out the same information, while avoiding the worst of the problems the bug creates (no children left to service incoming requests). This would complicate the code in master/ a bit, though. -- 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
Moving mailbox to a new partition
Hello, Which is the most appropriate way to move specific mailboxes to a new partition? The way i tried it was by using the rename command following the syntax: . rename oldmailbox newmailbox newpartition ( where oldmailbox is the same with newmailbox ... if this makes any difference ) The result was that the mailbox was indeed copied to the new partition but not removed from the previous location. This implies a second login to the system to remove it, not a very efficient solution. So is there any imap way to both copy and remove the mailbox ? Thank you in advance.
quota -f confusion
Hello, I had the impression that the removed tag after issuing the command quota -f indicates that the user mailbox had been removed whereas the corresponding quota file had not. In that case the following output : admin:~/opt/Cyrus/bin/quota -f . . user.nvoutsin: removed . . followed by : . OK User logged in . getquota user.nvoutsin * QUOTA user.nvoutsin (STORAGE 5997 40960) . OK Completed is completely confusing for me since from the response of the imap daemon it seems that the user still exists (which is actually true). So what is the conclusion of the quota -f output? Btw a question related to the above is if quota -f command actually removes the stale quota files ? Thank you in advance
Re: I Had attempted to do LMTP with Postfix ...
On Thu, 03 Jan 2002 13:23:55 -0700, Scott M Likens [EMAIL PROTECTED] (sml) writes: sml So then i can assume it would be more proper to do LMTP over Unix sml Socket? I can do either, i just am trying to find the best method to sml do this. The properness depends on your environment. TCP is handy if using separate boxes for Cyrus and MTA. Using TCP also makes it easier to take advantage of single instance delivery. (The local delivery agent in Postfix can only deliver one recipient at a time.) -- Amos
Re: I Had attempted to do LMTP with Postfix ...
On Wed, 15 May 2002, Amos Gouaux wrote: to take advantage of single instance delivery. (The local delivery agent in Postfix can only deliver one recipient at a time.) Well, use the lmtp transport, then. It can deliver through an unix socket just fine. -- 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: I Had attempted to do LMTP with Postfix ...
Ahh... Since the LMTP is well quite out of date i'm more or less trying to figure out the password maps and everything i would need to setup. I guess i'll wait for someone to update it and take another crack at it. --On Wednesday, May 15, 2002 5:48 PM -0500 Amos Gouaux [EMAIL PROTECTED] wrote: On Thu, 03 Jan 2002 13:23:55 -0700, Scott M Likens [EMAIL PROTECTED] (sml) writes: sml So then i can assume it would be more proper to do LMTP over Unix sml Socket? I can do either, i just am trying to find the best method to sml do this. The properness depends on your environment. TCP is handy if using separate boxes for Cyrus and MTA. Using TCP also makes it easier to take advantage of single instance delivery. (The local delivery agent in Postfix can only deliver one recipient at a time.) -- Amos
RE: TLS error? cyrus-imapd-2.1.4
If you look in the Archive thru whatever web mailing list you wish, there was someone who had mentioned using openssl how to create the CA, the key, and cert. Look it up, it'd be worth your time. No thanks, I wasn't asking for a HOWTO but for others' experiences. I had already read the cyrus-imapd documentation and it only recommends using: tls_cert_file: /var/imap/cyrus-imapd.pem tls_key_file: /var/imap/cyrus-imapd.pem but I have found that if I add: tls_ca_file: /var/imap/cyrus-imapd.pem with the way I created the cert it works flawlessly. Jeff --On Tuesday, May 14, 2002 7:33 PM -0700 jeff bert [EMAIL PROTECTED] wrote: I've gotten cyrus-imapd-2.1.4 working with the unencrypted ports and have now moved to getting the secure ports working. I created a self-signed certificate using: [root@jabba imap]# openssl req -new -x509 -days 365 -nodes -config /usr/lib/ssl/openssl.cnf -out cyrus-imapd.pem -keyout cyrus-imapd.pem and entering the information. My imapd.conf file has: tls_cert_file: /var/imap/cyrus-imapd.pem tls_key_file: /var/imap/cyrus-imapd.pem And it seems to work but there is a delay of about 30 seconds when I connect for the first time in an email clients session in my imapd log file: May 14 19:20:33 jabba imap3d[2648]: TLS engine: cannot load CA data after that it works... Is this an error I need to be concerned about or is this just the result of self-siging the certificate? Thanks, Jeff Bert
Re: I Had attempted to do LMTP with Postfix ...
Please change your system time (date !) ... On Thu, Jan 03, 2002 at 05:27:10PM -0700, Scott M Likens wrote: Thanks Luc
RE: TLS error? cyrus-imapd-2.1.4
Actually the proper way is this, Quite good url on how to be your Own CA http://www.aet.tu-cottbus.de/personen/jaenicke/postfix_tls/doc/myownca.html Look it up, modify it so you dont use des based pem's... See mine is like this (imapd.conf) tls_cert_file: /var/imap/cert.pem tls_key_file: /var/imap/key.pem tls_ca_file: /var/imap/CAcert.pem Works flawlessly. Of course it's self signed, but i haven't had a problem with a client complaining about that yet. --On Wednesday, May 15, 2002 4:35 PM -0700 Jeff Bert [EMAIL PROTECTED] wrote: If you look in the Archive thru whatever web mailing list you wish, there was someone who had mentioned using openssl how to create the CA, the key, and cert. Look it up, it'd be worth your time. No thanks, I wasn't asking for a HOWTO but for others' experiences. I had already read the cyrus-imapd documentation and it only recommends using: tls_cert_file: /var/imap/cyrus-imapd.pem tls_key_file: /var/imap/cyrus-imapd.pem but I have found that if I add: tls_ca_file: /var/imap/cyrus-imapd.pem with the way I created the cert it works flawlessly. Jeff --On Tuesday, May 14, 2002 7:33 PM -0700 jeff bert [EMAIL PROTECTED] wrote: I've gotten cyrus-imapd-2.1.4 working with the unencrypted ports and have now moved to getting the secure ports working. I created a self-signed certificate using: [root@jabba imap]# openssl req -new -x509 -days 365 -nodes -config /usr/lib/ssl/openssl.cnf -out cyrus-imapd.pem -keyout cyrus-imapd.pem and entering the information. My imapd.conf file has: tls_cert_file: /var/imap/cyrus-imapd.pem tls_key_file: /var/imap/cyrus-imapd.pem And it seems to work but there is a delay of about 30 seconds when I connect for the first time in an email clients session in my imapd log file: May 14 19:20:33 jabba imap3d[2648]: TLS engine: cannot load CA data after that it works... Is this an error I need to be concerned about or is this just the result of self-siging the certificate? Thanks, Jeff Bert
Re: I Had attempted to do LMTP with Postfix ...
lol sorry.. Clock seems to be resetting for some reason on my computer and i'm not sure why. Battery is fine and all... just every time i reboot it looses it. --On Thursday, May 16, 2002 1:49 AM +0200 Luc Brouard [EMAIL PROTECTED] wrote: Please change your system time (date !) ... On Thu, Jan 03, 2002 at 05:27:10PM -0700, Scott M Likens wrote: Thanks Luc
Re: PAM Authentication
Or, if you're in 2.0,
sasl_pwcheck_method: pam
should work fine.
Michael
--On Wednesday, May 15, 2002 1:50 PM -0400 Ken Murchison [EMAIL PROTECTED]
wrote:
What version of Cyrus? Assuming that you are using v2.1.x, set
sasl_pwcheck_method: saslauthd
and start saslauthd with the '-a pam' option.
David Chait wrote:
Greetings,
I am currently attempting to make Cyrus authenticate via a PAM
library (like our Courier-IMAP system did), but have yet been
able to accomplish this. The following is my imapd.conf file and
cyrus.conf file. The MTA I am using is Postfix, but that seems to be
functional.
Cheers,
David
Imapd
configdirectory: /var/imap
partition-default: /home/mail
admins: root cyrus
# srvtab: /var/imap/srvtab
allowanonymouslogin: no
sasl_pwcheck_method: pwcheck
Cyrus
# standard standalone server implementation
START {
# do not delete this entry!
recover cmd=ctl_cyrusdb -r
# this is only necessary if using idled for IMAP IDLE
# idledcmd=idled
}
# UNIX sockets start with a slash and are put into /var/imap/socket
SERVICES {
# add or remove based on preferences
imap cmd=imapd listen=imap prefork=0
imaps cmd=imapd -s listen=imaps prefork=0
# pop3 cmd=pop3d listen=pop3 prefork=0
# pop3scmd=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
# this is only necessary if using notifications
# notify cmd=notifyd listen=/var/imap/socket/notify
# proto=udp
prefork=1
}
EVENTS {
# this is required
checkpointcmd=ctl_cyrusdb -c period=30
# this is only necessary if using duplicate delivery suppression
delprune cmd=ctl_deliver -E 3 period=1440
# this is only necessary if caching TLS sessions
tlsprune cmd=tls_prune period=1440
}
--
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: [PATCH] Updated master.c process counting patch
--On Wednesday, May 15, 2002 4:29 PM -0400 Lawrence Greenfield [EMAIL PROTECTED] wrote: Date: Wed, 15 May 2002 16:02:42 -0300 From: Henrique de Moraes Holschuh [EMAIL PROTECTED] [...] The point is, if that indeed happens, log or no log, master loses track ofthe number of children that can service requests. That would be a bug, andthe patch supposedly fixes this bug. It really doesn't matter (foraccepting or not the patch) why the child died. Yes, I understand that. However, if the master (in real life situations) is actually losing track of the number of available service processes without one of those service processes crashing (either by the sysadmin or otherwise) then there's some other problem in the child accounting. I'd like to know if there is before doing something that may mask the problem completely. Larry Would it be sufficient if the patch were altered slightly to send a LOG_DEBUG message to syslog every time the master decremented one of the worker counters, specifying what it did? Right now, it seems like the indicator of the problem is a service unavailability. If key step in the process that we're covering is the report of the dead child to the master, and you'd be just as happy with a log message as a blatantly obvious failure, well heck, let's do it! I'm happy to send you any bit of logging information you want, just so long as my servers stay available! :) Michael Bacon OIT Systems Administration
Move Mail
Anyone has any experience moving mail from exchange to cyrus-imapd? I have tried fetchmail. Its not a great tool to move folders of all my users. thx, zod
Bogus mailbox problem
Hi All, I have the latest cyrus-imapd and sasl. I have moved my mailbox from exchange to this server. During which something went wrong and I have ghost mailboxes. When I list with lm in cyradm i see a bunch stuff which in reality don't exist. I tried to do dm but they don't exist. They show up in my eMail client though and I cannot delete them. Any idea? thx, zod
Re: [PATCH] Updated master.c process counting patch
--On Wednesday, May 15, 2002 2:50 PM -0400 Lawrence Greenfield [EMAIL PROTECTED] wrote: Date: Wed, 15 May 2002 15:37:50 -0300 From: Henrique de Moraes Holschuh [EMAIL PROTECTED] [...] We don't have this problem on any of our servers. Do you have preforking enabled? If you do (and if I did undertand the issuecorrectly), start kill -9'ing service processes, and it should be possibleto duplicate the bug. I will try that just now, in fact. Sure, if you intentionally kill processes that are waiting for connections this happens. I understand this. But if I did that, master would log messages that the processes were dying incorrectly (signaled to death by 9). Just to follow up a bit more -- I'm not sure if this will be terribly helpful, but it may be illustrative of the one situation which might cause such a problem. Here's a snippet of log that occured shortly before we ran into a service problem: May 2 15:35:14 delrey.acpub.duke.edu master[16360]: can't fork process to run c heckpoint May 2 15:35:14 delrey.acpub.duke.edu last message repeated 45 times May 2 15:35:15 delrey.acpub.duke.edu master[16360]: process 7494 exited, signal ed to death by 9 Preceeding this is a couple hundred more messages generally complaining about inability to fork, lack of resources, inability to load a shared library, and all of the other things one would expect to see when swap runs out. However, I don't see any other mention of process 7494. (This is logging at the user6.info level, so we don't get all of the debug messages, unfortunately.) Now, the core problem here is very simple: This is a poor, beleagured SparcStation 20 with 17k mailboxes on it, and at a peak block of time, it just ran out of available memory. The solution is also simple: we need to upgrade our hardware. However, since we're currently under budget cuts as our Executive VP scrounges up money to go around building big buildings, that's not exactly a viable option. Tracking down the whys and wherefores of a process dying under a resource crunch is not likely to be terribly productive -- one can't very well expect a service to keep functioning normally under those circumstances. However, it would be nice if the master process paid attention to the SIGCHLD and the information from the wait() call and take note of the fact that the ex-process has shook off this mortal coil, so that 15 minutes later, the process miscount didn't cause the master to start blithely ignoring incoming requests. I hope this is helpful, Michael Bacon OIT Systems Administration Duke University
info-cyrus-digest: any progress?
Is there any progress on providing info-cyrus (and cyrus-sasl) in digested form? thanks -- Mathias Körber |2385 Bay Road |Tel:+1-650-381.6044|Fax:+1-650-381.6055 Sr. Consult. Engr. |Redwood City |Direct Fax/Voicemail:+1-240-368.1170 Nominum, Inc. |CA 94063, USA |Private: Mobile:+65-9815.7807 [EMAIL PROTECTED]|www.nominum.com|E:[EMAIL PROTECTED]|Fax/Vmail:+1-801-6 50.9591
Re: Moving mailbox to a new partition
On Thu, 16 May 2002, Voutsinas Nikos wrote: Which is the most appropriate way to move specific mailboxes to a new partition? The way i tried it was by using the rename command following the syntax: . rename oldmailbox newmailbox newpartition That's how you do it. Were any error messages logged? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 235 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: [PATCH] Updated master.c process counting patch
Henrique de Moraes Holschuh wrote: I don't know what Ken and Lawrence think of these patches, but I just finished porting the child pid tracking of master-avail.diff to 2.1.4CVS, and will post that to this list soon. I will also include it in Debian, which will give some field-testing to the patch. I *strongly* recommend also including shutdown.diff. This is important in Linux to avoid sockets handing around in CLOSE_WAIT state. Remove the ' !imapd_in-tls_conn' bit everywhere for general distribution--this is a workaround for a memory corruption problem that is unrelated to this patch.
Re: [PATCH] Updated master.c process counting patch
Lawrence Greenfield wrote: Date: Wed, 15 May 2002 16:02:42 -0300 From: Henrique de Moraes Holschuh [EMAIL PROTECTED] [...] The point is, if that indeed happens, log or no log, master loses track of the number of children that can service requests. That would be a bug, and the patch supposedly fixes this bug. It really doesn't matter (for accepting or not the patch) why the child died. Yes, I understand that. However, if the master (in real life situations) is actually losing track of the number of available service processes without one of those service processes crashing (either by the sysadmin or otherwise) then there's some other problem in the child accounting. The child accounting is fine. The problem in our case was always caused by child segfaults, or failure to properly close TCP connections. We still see segfaults (about one per fifty thousand connections I'd guess), and occassional TCP closing problems, but they're much reduced with the other patches. However with the master.c patch these intermittent problems have no practical impact on our users, since the server handles them gracefully. The master.c patch is important because without it, any little problem in any daemon that causes a child to crash, will eventually bring down the whole server. With the patch, processes are still counted correctly and therefore a child segfaulting will not stop the server from accepting connections. Child segfaults still cause the problem to be logged as per usual--the only difference with the patch is that child processes are correctly counted in this event.
Re: [PATCH] 2.1.4 master process counting
Henrique de Moraes Holschuh wrote: Here is the 2.1.4 port of the master process counting patch. It will be in Debian's Cyrus IMAPd package 2.1.4-9, to be uploaded today or tomorrow. I'm not 100% sure, but I think the change you've made to return if the centry isn't found may mean the nconnections doesn't get updated correctly in some cases. You probably want to update nconnections in the case of the SERVICE_CONNECTION message regardless of whether you find the centry.
Re: [PATCH] Updated master.c process counting patch
Henrique de Moraes Holschuh wrote: On Wed, 15 May 2002, Scott Russell wrote: On Wed, May 15, 2002 at 10:35:04AM -0300, Henrique de Moraes Holschuh wrote: I don't know about all the other patches, though. I have included the safe_flock patches, and I *may* include the alarm and locking stuff in master-avail.diff later, but I must study and understand it first. Are the patches TLS sane / tested? At one point I remember reading The ones I am including in Debian are. No TLS is _not_ an option IMHO. The TLS issue was simply required to work around a memory corruption bug. The patches all work correctly with TLS, as long as you remove the ' !imapd_in-tls_conn' bits in imapd.c and pop3d.c. These extra tests are nothing to do with the other patches. The problem is that imapd_in et al sometimes get overwritten, causing prot_flush and prot_fill to result in a segfault when they are call during shut_down() or imapd_reset(). Therefore we wanted some way of checking whether imapd_in was still sane, and we happened to pick to check that -tls_conn==0. A better approach would be to make the first element of the record a known constant and check for that. An even better approach would be to work out why the structure is getting corrupted in the first place! To clarify--the memory corruption problem occurs regardless of whether the other patches are present (in our environment at least), and needs to be worked around regardless of whether the other patches are present. The issues are completely independent. The memory corruption bug is something we see every few thousand connections under Linux 2.4.18 with Cyrus 2.1.3 in a mixed client high load environment.
Re: I Had attempted to do LMTP with Postfix ...
On Wed, 15 May 2002 20:04:27 -0300, Henrique de Moraes Holschuh [EMAIL PROTECTED] (hdmh) writes: hdmh On Wed, 15 May 2002, Amos Gouaux wrote: to take advantage of single instance delivery. (The local delivery agent in Postfix can only deliver one recipient at a time.) hdmh Well, use the lmtp transport, then. It can deliver through an unix socket hdmh just fine. If you use mailbox_transport, you'll still only get one recipient at a time. I don't recall if that's also true with local_transport. I think it is. However, if there's not a high probability that you'll see lots of mail addressed to many recipients on the same Cyrus partition, then it's a mute point. -- Amos
Re: I Had attempted to do LMTP with Postfix ...
On Thu, 03 Jan 2002 17:27:10 -0700, Scott M Likens [EMAIL PROTECTED] (sml) writes: sml Ahh... sml Since the LMTP is well quite out of date i'm more or less trying to sml figure out the password maps and everything i would need to setup. sml I guess i'll wait for someone to update it and take another crack at sml it. As far as the LMTP_README goes, it's not *that* out of date. I think the biggest one was the lmtp -a as a possibility. The lmtp_sasl_* stuff is the LMTP-AUTH I was referring to. If you compile Postfix with SMTP-AUTH then you get LMTP-AUTH as well. Though, the LMTP-AUTH in Postfix isn't quite as useful as that in Sendmail. (Because any auth specified via SMTP-AUTH is not conveyed over to the LMTP-AUTH sequence, but I digress.) To be honest, there hasn't been that much change in the Postfix LMTP client and Cyrus LMTP server since that readme was slapped together, so it is still valid. -- Amos
Re: I Had attempted to do LMTP with Postfix ...
Yeah i noticed. But I find it a little nicer. Just used lmtp:unix:/var/imap/socket/lmtp Seems to work just dandy actually, much easier then TCP. Althought to be honest TCP isnt a bad idea, having postfix on 1 server accepting the mail and sending it to another server for storage. Of Course having postfix as the backup transport. You learn something new every day, can almost put this on my resume by now. Thanks btw. --On Wednesday, May 15, 2002 10:40 PM -0500 Amos Gouaux [EMAIL PROTECTED] wrote: On Wed, 15 May 2002 20:04:27 -0300, Henrique de Moraes Holschuh [EMAIL PROTECTED] (hdmh) writes: hdmh On Wed, 15 May 2002, Amos Gouaux wrote: to take advantage of single instance delivery. (The local delivery agent in Postfix can only deliver one recipient at a time.) hdmh Well, use the lmtp transport, then. It can deliver through an unix socket hdmh just fine. If you use mailbox_transport, you'll still only get one recipient at a time. I don't recall if that's also true with local_transport. I think it is. However, if there's not a high probability that you'll see lots of mail addressed to many recipients on the same Cyrus partition, then it's a mute point. -- Amos
RE: PAM Authentication
May 15 20:41:43 bonmaildev saslauthd[19131]: AUTHFAIL: user=dchait
service=imap realm= [PAM auth error]
This is what I received using the saslauthd -a pam option (pam didn't
work at all). Any ideas? I can't seem to find a reference for this error
anywhere.
-Original Message-
From: Michael Bacon [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 15, 2002 6:08 PM
To: Ken Murchison; David Chait
Cc: [EMAIL PROTECTED]
Subject: Re: PAM Authentication
Or, if you're in 2.0,
sasl_pwcheck_method: pam
should work fine.
Michael
--On Wednesday, May 15, 2002 1:50 PM -0400 Ken Murchison
[EMAIL PROTECTED]
wrote:
What version of Cyrus? Assuming that you are using v2.1.x, set
sasl_pwcheck_method: saslauthd
and start saslauthd with the '-a pam' option.
David Chait wrote:
Greetings,
I am currently attempting to make Cyrus authenticate via a
PAM
library (like our Courier-IMAP system did), but have yet been
able to accomplish this. The following is my imapd.conf file and
cyrus.conf file. The MTA I am using is Postfix, but that seems to be
functional.
Cheers,
David
Imapd
configdirectory: /var/imap
partition-default: /home/mail
admins: root cyrus
# srvtab: /var/imap/srvtab
allowanonymouslogin: no
sasl_pwcheck_method: pwcheck
Cyrus
# standard standalone server implementation
START {
# do not delete this entry!
recover cmd=ctl_cyrusdb -r
# this is only necessary if using idled for IMAP IDLE
# idledcmd=idled
}
# UNIX sockets start with a slash and are put into /var/imap/socket
SERVICES {
# add or remove based on preferences
imap cmd=imapd listen=imap prefork=0
imaps cmd=imapd -s listen=imaps prefork=0
# pop3 cmd=pop3d listen=pop3 prefork=0
# pop3scmd=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
# this is only necessary if using notifications
# notify cmd=notifyd listen=/var/imap/socket/notify
# proto=udp
prefork=1
}
EVENTS {
# this is required
checkpointcmd=ctl_cyrusdb -c period=30
# this is only necessary if using duplicate delivery suppression
delprune cmd=ctl_deliver -E 3 period=1440
# this is only necessary if caching TLS sessions
tlsprune cmd=tls_prune period=1440
}
--
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: PAM Authentication
what's your /etc/imapd.conf set to for sasl_pwcheck_method?
what's your /etc/pam.d/imap set to?
we need to know those to help trouble shoot... but...
if in /etc/imapd.conf reads...
...
sasl_pwcheck_method: saslauthd
and your /etc/pam.d/imap is:
# begin
authrequired /lib/security/pam_stack.so service=system-auth
account required /lib/secruity/pam_stack.so service=system-auth
# end
then you can try this:
1) make dchait a valid user on your system via useradd and give
that user a password.
2) make sure saslauthd is running...
3) run:
[root] # imtest -m login -a dchait -u dchait -r hostname hostname
and that will test the shadow password checking...
4) run:
[root] # saslpasswd2 -c dchait
Password: password
Again (for verification): password
[root] # imtest -a dchait -u dchait -r hostname hostname
and you should be able to authenticate in both circumstances.
if you read the docs, the '-m login' bypasses the auth mechanism
and goes straight for the shadow passes (AFAICS)
Jeff
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of David Chait
Sent: Wednesday, May 15, 2002 9:37 PM
To: 'Michael Bacon'; 'Ken Murchison'
Cc: [EMAIL PROTECTED]
Subject: RE: PAM Authentication
May 15 20:41:43 bonmaildev saslauthd[19131]: AUTHFAIL: user=dchait
service=imap realm= [PAM auth error]
This is what I received using the saslauthd -a pam option (pam didn't
work at all). Any ideas? I can't seem to find a reference for this error
anywhere.
-Original Message-
From: Michael Bacon [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 15, 2002 6:08 PM
To: Ken Murchison; David Chait
Cc: [EMAIL PROTECTED]
Subject: Re: PAM Authentication
Or, if you're in 2.0,
sasl_pwcheck_method: pam
should work fine.
Michael
--On Wednesday, May 15, 2002 1:50 PM -0400 Ken Murchison
[EMAIL PROTECTED]
wrote:
What version of Cyrus? Assuming that you are using v2.1.x, set
sasl_pwcheck_method: saslauthd
and start saslauthd with the '-a pam' option.
David Chait wrote:
Greetings,
I am currently attempting to make Cyrus authenticate via a
PAM
library (like our Courier-IMAP system did), but have yet been
able to accomplish this. The following is my imapd.conf file and
cyrus.conf file. The MTA I am using is Postfix, but that seems to be
functional.
Cheers,
David
Imapd
configdirectory: /var/imap
partition-default: /home/mail
admins: root cyrus
# srvtab: /var/imap/srvtab
allowanonymouslogin: no
sasl_pwcheck_method: pwcheck
Cyrus
# standard standalone server implementation
START {
# do not delete this entry!
recover cmd=ctl_cyrusdb -r
# this is only necessary if using idled for IMAP IDLE
# idledcmd=idled
}
# UNIX sockets start with a slash and are put into /var/imap/socket
SERVICES {
# add or remove based on preferences
imap cmd=imapd listen=imap prefork=0
imaps cmd=imapd -s listen=imaps prefork=0
# pop3 cmd=pop3d listen=pop3 prefork=0
# pop3scmd=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
# this is only necessary if using notifications
# notify cmd=notifyd listen=/var/imap/socket/notify
# proto=udp
prefork=1
}
EVENTS {
# this is required
checkpointcmd=ctl_cyrusdb -c period=30
# this is only necessary if using duplicate delivery suppression
delprune cmd=ctl_deliver -E 3 period=1440
# this is only necessary if caching TLS sessions
tlsprune cmd=tls_prune period=1440
}
--
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
