[toaster] RH 7.3 / courier-imap-2.2.2.20040207.tar.bz2 compile fail
hi all, I'm trying this in 2 different stock RH 7.3 boxes, following Bill's steps with the latest snapshot of courier-imap: tar -xjf tar/courier-imap-2.2.2.20040207.tar.bz2 cd courier-imap-2.2.2.20040207 # build as vpopmail chown -R vpopmail:vchkpw ../courier-imap-2.2.2.20040207 su vpopmail # configure may take some time... ./configure # note: redhat 9 users need to add "--with-redhat" comment 1: it seems to be necessary add "--with-redhat" even in RH7.3 comment 2: make fails exiting with: " make[2]: Entering directory `/var/src/courier-imap-2.2.2.20040207/unicode' Compiling big5.c big5.c: In function `c2u_doconv': big5.c:311: parse error before `ucv' big5.c:318: `ucv' undeclared (first use in this function) big5.c:318: (Each undeclared identifier is reported only once big5.c:318: for each function it appears in.) make[2]: *** [big5.o] Error 1 make[2]: Leaving directory `/var/src/courier-imap-2.2.2.20040207/unicode' make[1]: *** [all] Error 2 make[1]: Leaving directory `/var/src/courier-imap-2.2.2.20040207/unicode' make: *** [all-recursive] Error 1 " When I switched back to courier-imap-2.2.1.tar.bz2 and re-try, it compiles smoothly as usual. I don't tried in another OS's yet so I cannot say if this a general problem regards Abel Lucano [EMAIL PROTECTED]
Re: [toaster] RH 7.3 / courier-imap-2.2.2.20040207.tar.bz2 compile fail
Abel Lucano wrote: hi all, I'm trying this in 2 different stock RH 7.3 boxes, following Bill's steps with the latest snapshot of courier-imap: tar -xjf tar/courier-imap-2.2.2.20040207.tar.bz2 cd courier-imap-2.2.2.20040207 # build as vpopmail chown -R vpopmail:vchkpw ../courier-imap-2.2.2.20040207 su vpopmail # configure may take some time... ./configure # note: redhat 9 users need to add "--with-redhat" comment 1: it seems to be necessary add "--with-redhat" even in RH7.3 I have removed the "9" from the comment. comment 2: make fails exiting with: " make[2]: Entering directory `/var/src/courier-imap-2.2.2.20040207/unicode' Compiling big5.c big5.c: In function `c2u_doconv': big5.c:311: parse error before `ucv' big5.c:318: `ucv' undeclared (first use in this function) big5.c:318: (Each undeclared identifier is reported only once big5.c:318: for each function it appears in.) make[2]: *** [big5.o] Error 1 make[2]: Leaving directory `/var/src/courier-imap-2.2.2.20040207/unicode' make[1]: *** [all] Error 2 make[1]: Leaving directory `/var/src/courier-imap-2.2.2.20040207/unicode' make: *** [all-recursive] Error 1 " When I switched back to courier-imap-2.2.1.tar.bz2 and re-try, it compiles smoothly as usual. The only thing 2.2.1 is missing is vlimits support. That's why I used the pre-release. Hopefull this will be fixed by the final release. It does work fine on RH 9, fwiw. Thanks, Bill Shupp
RE: [toaster] RH 7.3 / courier-imap-2.2.2.20040207.tar.bz2 compile fail
>The only thing 2.2.1 is missing is vlimits support. That's why I used >the pre-release. Hopefull this will be fixed by the final >release. It >does work fine on RH 9, fwiw. > I have compiled courier-imap-2.2.2.20040118 on RH7.3 and its running fine. I used the following to compile. ./configure --without-authpwd --without-authshadow --without-authpam --without-authuserdb --without-authcram --without-authldap --without-authmysql --without-authpgsql --without-authcustom --without-authdaemon --disable-root-check --with-redhat Its been working fine for me. I just recompiled a few nights ago to take the trash included in quota out as it was causing more support calls than it was worth. Shane
Re: [toaster] RH 7.3 / courier-imap-2.2.2.20040207.tar.bz2 compile fail
I agree - we needed to use --with-redhat on an RH8.0 installation. At 01:12 PM 2/27/2004, you wrote: hi all, I'm trying this in 2 different stock RH 7.3 boxes, following Bill's steps with the latest snapshot of courier-imap: tar -xjf tar/courier-imap-2.2.2.20040207.tar.bz2 cd courier-imap-2.2.2.20040207 # build as vpopmail chown -R vpopmail:vchkpw ../courier-imap-2.2.2.20040207 su vpopmail # configure may take some time... ./configure # note: redhat 9 users need to add "--with-redhat" comment 1: it seems to be necessary add "--with-redhat" even in RH7.3 comment 2: make fails exiting with: " make[2]: Entering directory `/var/src/courier-imap-2.2.2.20040207/unicode' Compiling big5.c big5.c: In function `c2u_doconv': big5.c:311: parse error before `ucv' big5.c:318: `ucv' undeclared (first use in this function) big5.c:318: (Each undeclared identifier is reported only once big5.c:318: for each function it appears in.) make[2]: *** [big5.o] Error 1 make[2]: Leaving directory `/var/src/courier-imap-2.2.2.20040207/unicode' make[1]: *** [all] Error 2 make[1]: Leaving directory `/var/src/courier-imap-2.2.2.20040207/unicode' make: *** [all-recursive] Error 1 " When I switched back to courier-imap-2.2.1.tar.bz2 and re-try, it compiles smoothly as usual. I don't tried in another OS's yet so I cannot say if this a general problem regards Abel Lucano [EMAIL PROTECTED] Best Regards, Jeff Koch, Intersessions
Re: [toaster] Suggestions for improving performance
Jeff Koch wrote: Does anybody have any suggestion for improving the performance of a mailserver runnning qmail/vpopmail/qmailadmin/qmail-scanner/spamassassin? We're using a 2.4Ghz P4 with 1GB RAM and a 40GB SCSI drive. The operating system is a basic RH8.0 install with the ext3 journalling file system. We're handling about 50K messages/day and seem to exhausting the capabilities of the server. During peak periods CPU idle time reaches 0% and load averages will exceed 10.0 We've seen some recommendations ( http://people.redhat.com/alikins/system_tuning.html , for example) for changing hard disk and file system parameters mostly having to do with read/write caching and cache sizes and minumum delays before writing to disk but we have been afraid to try any of these for fear of making things worse. We would welcome any suggestions or URL's that you could point to - particularly with respect to performance tuning that will work with qmail. Thanks Jeff, In my experience, the first bottleneck is usually disk i/o. Some steps you can take to alleviate this are: 1. Put /var/qmail/queue on its own disk, preferably not a raid. 2. If you use qmail-scanner, put /var/spool/qmailscan on its own disk 3. You can also try putting /var/log/qmail on its own disk if you can. But at least try and keep it on a different disk than /var/qmail/queue Next, qmail-scanner/clamd/spamd tend to be the bottleneck. You can try qscanq/qmail-spamc to get rid of qmail-scanner's perl overhead. I have had success with qscanq on Linux, but had unexplained qq read errors on FreeBSD that I have not been able to explain yet. So I'd try this only with caution. You also might try moving some components off of this machine, like clamd, spamd, or even MySQL if you use it. Hope this helps, Bill Shupp
Re: [toaster] Suggestions for improving performance
Hi Bill: Thanks for the reply. I know how to run mysql from another server but how would one move spamd and clamd to another server? Your other suggestions are good but we're using a 1U rack server that unfortunately has room for one drive (big mistake!). At 02:44 PM 2/27/2004, you wrote: Jeff Koch wrote: Does anybody have any suggestion for improving the performance of a mailserver runnning qmail/vpopmail/qmailadmin/qmail-scanner/spamassassin? We're using a 2.4Ghz P4 with 1GB RAM and a 40GB SCSI drive. The operating system is a basic RH8.0 install with the ext3 journalling file system. We're handling about 50K messages/day and seem to exhausting the capabilities of the server. During peak periods CPU idle time reaches 0% and load averages will exceed 10.0 We've seen some recommendations ( http://people.redhat.com/alikins/system_tuning.html , for example) for changing hard disk and file system parameters mostly having to do with read/write caching and cache sizes and minumum delays before writing to disk but we have been afraid to try any of these for fear of making things worse. We would welcome any suggestions or URL's that you could point to - particularly with respect to performance tuning that will work with qmail. Thanks Jeff, In my experience, the first bottleneck is usually disk i/o. Some steps you can take to alleviate this are: 1. Put /var/qmail/queue on its own disk, preferably not a raid. 2. If you use qmail-scanner, put /var/spool/qmailscan on its own disk 3. You can also try putting /var/log/qmail on its own disk if you can. But at least try and keep it on a different disk than /var/qmail/queue Next, qmail-scanner/clamd/spamd tend to be the bottleneck. You can try qscanq/qmail-spamc to get rid of qmail-scanner's perl overhead. I have had success with qscanq on Linux, but had unexplained qq read errors on FreeBSD that I have not been able to explain yet. So I'd try this only with caution. You also might try moving some components off of this machine, like clamd, spamd, or even MySQL if you use it. Hope this helps, Bill Shupp Best Regards, Jeff Koch
Re: [toaster] Suggestions for improving performance
Jeff, We had a similar problem, and our bottleneck was SpamAssassin and Clam Scanner. We ended up putting SpamAssassin and Clamd on a seperate machine that simply scanned the incoming messages and passed them onto the primary mail machine that housed the vpopmail accounts, etc. All you need to do is install Bill's toaster on a second machine with Qmailscanner, SpamAssassin, etc, etc. and then setup that machine to forward all mail to your primary box in /var/qmail/control/smtproutes Works like a charm, just make sure DNS points to the scanning server in the MX route. Peter Jeff Koch wrote: Hi Bill: Thanks for the reply. I know how to run mysql from another server but how would one move spamd and clamd to another server? Your other suggestions are good but we're using a 1U rack server that unfortunately has room for one drive (big mistake!). At 02:44 PM 2/27/2004, you wrote: Jeff Koch wrote: Does anybody have any suggestion for improving the performance of a mailserver runnning qmail/vpopmail/qmailadmin/qmail-scanner/spamassassin? We're using a 2.4Ghz P4 with 1GB RAM and a 40GB SCSI drive. The operating system is a basic RH8.0 install with the ext3 journalling file system. We're handling about 50K messages/day and seem to exhausting the capabilities of the server. During peak periods CPU idle time reaches 0% and load averages will exceed 10.0 We've seen some recommendations ( http://people.redhat.com/alikins/system_tuning.html , for example) for changing hard disk and file system parameters mostly having to do with read/write caching and cache sizes and minumum delays before writing to disk but we have been afraid to try any of these for fear of making things worse. We would welcome any suggestions or URL's that you could point to - particularly with respect to performance tuning that will work with qmail. Thanks Jeff, In my experience, the first bottleneck is usually disk i/o. Some steps you can take to alleviate this are: 1. Put /var/qmail/queue on its own disk, preferably not a raid. 2. If you use qmail-scanner, put /var/spool/qmailscan on its own disk 3. You can also try putting /var/log/qmail on its own disk if you can. But at least try and keep it on a different disk than /var/qmail/queue Next, qmail-scanner/clamd/spamd tend to be the bottleneck. You can try qscanq/qmail-spamc to get rid of qmail-scanner's perl overhead. I have had success with qscanq on Linux, but had unexplained qq read errors on FreeBSD that I have not been able to explain yet. So I'd try this only with caution. You also might try moving some components off of this machine, like clamd, spamd, or even MySQL if you use it. Hope this helps, Bill Shupp Best Regards, Jeff Koch
Re: [toaster] Suggestions for improving performance
Peter Maag wrote: Jeff, We had a similar problem, and our bottleneck was SpamAssassin and Clam Scanner. We ended up putting SpamAssassin and Clamd on a seperate machine that simply scanned the incoming messages and passed them onto the primary mail machine that housed the vpopmail accounts, etc. All you need to do is install Bill's toaster on a second machine with Qmailscanner, SpamAssassin, etc, etc. and then setup that machine to forward all mail to your primary box in /var/qmail/control/smtproutes Works like a charm, just make sure DNS points to the scanning server in the MX route. Peter The one thing that you can lose by doing this is chkuser support. Two workarounds are to use MySQL w/ valias support, or perhaps share the mail spool via NFS. Regards, Bill
Re: [toaster] Suggestions for improving performance
On Feb 27, 2004, at 3:08 PM, Bill Shupp wrote: The one thing that you can lose by doing this is chkuser support. Two workarounds are to use MySQL w/ valias support, or perhaps share the mail spool via NFS. Mailing lists aren't stored in MySQL, even with valias support turned on. I have ideas on how to do it, but I can't spare the time to work on it unless someone sponsors the work. -- Tom Collins - [EMAIL PROTECTED] QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/ Info on the Sniffter hand-held Network Tester: http://sniffter.com/
Re: [toaster] Suggestions for improving performance
Hi Peter: I was thinking of that also. But didn't you lose the benefit of 'checkuser' patch. We have one domain that used to have a catch-all and now gets 40,000 spams a day addressed to every possible name. We shut down the catch-all and the checkuser patch rejects them all saving us all kind of CPU cycles. At 03:29 PM 2/27/2004, you wrote: Jeff, We had a similar problem, and our bottleneck was SpamAssassin and Clam Scanner. We ended up putting SpamAssassin and Clamd on a seperate machine that simply scanned the incoming messages and passed them onto the primary mail machine that housed the vpopmail accounts, etc. All you need to do is install Bill's toaster on a second machine with Qmailscanner, SpamAssassin, etc, etc. and then setup that machine to forward all mail to your primary box in /var/qmail/control/smtproutes Works like a charm, just make sure DNS points to the scanning server in the MX route. Peter Jeff Koch wrote: Hi Bill: Thanks for the reply. I know how to run mysql from another server but how would one move spamd and clamd to another server? Your other suggestions are good but we're using a 1U rack server that unfortunately has room for one drive (big mistake!). At 02:44 PM 2/27/2004, you wrote: Jeff Koch wrote: Does anybody have any suggestion for improving the performance of a mailserver runnning qmail/vpopmail/qmailadmin/qmail-scanner/spamassassin? We're using a 2.4Ghz P4 with 1GB RAM and a 40GB SCSI drive. The operating system is a basic RH8.0 install with the ext3 journalling file system. We're handling about 50K messages/day and seem to exhausting the capabilities of the server. During peak periods CPU idle time reaches 0% and load averages will exceed 10.0 We've seen some recommendations ( http://people.redhat.com/alikins/system_tuning.html , for example) for changing hard disk and file system parameters mostly having to do with read/write caching and cache sizes and minumum delays before writing to disk but we have been afraid to try any of these for fear of making things worse. We would welcome any suggestions or URL's that you could point to - particularly with respect to performance tuning that will work with qmail. Thanks Jeff, In my experience, the first bottleneck is usually disk i/o. Some steps you can take to alleviate this are: 1. Put /var/qmail/queue on its own disk, preferably not a raid. 2. If you use qmail-scanner, put /var/spool/qmailscan on its own disk 3. You can also try putting /var/log/qmail on its own disk if you can. But at least try and keep it on a different disk than /var/qmail/queue Next, qmail-scanner/clamd/spamd tend to be the bottleneck. You can try qscanq/qmail-spamc to get rid of qmail-scanner's perl overhead. I have had success with qscanq on Linux, but had unexplained qq read errors on FreeBSD that I have not been able to explain yet. So I'd try this only with caution. You also might try moving some components off of this machine, like clamd, spamd, or even MySQL if you use it. Hope this helps, Bill Shupp Best Regards, Jeff Koch Best Regards, Jeff Koch, Intersessions
Re: [toaster] Suggestions for improving performance
Jeff, Yes, as Bill pointed out we do loose the benefit of the checkuser patch, but many of our users use catch-all accounts. So, in that respect there really was no downside in not going with the chkuser patch(unless I am mistaken, and it works with catchalls). Peter Jeff Koch wrote: Hi Peter: I was thinking of that also. But didn't you lose the benefit of 'checkuser' patch. We have one domain that used to have a catch-all and now gets 40,000 spams a day addressed to every possible name. We shut down the catch-all and the checkuser patch rejects them all saving us all kind of CPU cycles. At 03:29 PM 2/27/2004, you wrote: Jeff, We had a similar problem, and our bottleneck was SpamAssassin and Clam Scanner. We ended up putting SpamAssassin and Clamd on a seperate machine that simply scanned the incoming messages and passed them onto the primary mail machine that housed the vpopmail accounts, etc. All you need to do is install Bill's toaster on a second machine with Qmailscanner, SpamAssassin, etc, etc. and then setup that machine to forward all mail to your primary box in /var/qmail/control/smtproutes Works like a charm, just make sure DNS points to the scanning server in the MX route. Peter Jeff Koch wrote: Hi Bill: Thanks for the reply. I know how to run mysql from another server but how would one move spamd and clamd to another server? Your other suggestions are good but we're using a 1U rack server that unfortunately has room for one drive (big mistake!). At 02:44 PM 2/27/2004, you wrote: Jeff Koch wrote: Does anybody have any suggestion for improving the performance of a mailserver runnning qmail/vpopmail/qmailadmin/qmail-scanner/spamassassin? We're using a 2.4Ghz P4 with 1GB RAM and a 40GB SCSI drive. The operating system is a basic RH8.0 install with the ext3 journalling file system. We're handling about 50K messages/day and seem to exhausting the capabilities of the server. During peak periods CPU idle time reaches 0% and load averages will exceed 10.0 We've seen some recommendations ( http://people.redhat.com/alikins/system_tuning.html , for example) for changing hard disk and file system parameters mostly having to do with read/write caching and cache sizes and minumum delays before writing to disk but we have been afraid to try any of these for fear of making things worse. We would welcome any suggestions or URL's that you could point to - particularly with respect to performance tuning that will work with qmail. Thanks Jeff, In my experience, the first bottleneck is usually disk i/o. Some steps you can take to alleviate this are: 1. Put /var/qmail/queue on its own disk, preferably not a raid. 2. If you use qmail-scanner, put /var/spool/qmailscan on its own disk 3. You can also try putting /var/log/qmail on its own disk if you can. But at least try and keep it on a different disk than /var/qmail/queue Next, qmail-scanner/clamd/spamd tend to be the bottleneck. You can try qscanq/qmail-spamc to get rid of qmail-scanner's perl overhead. I have had success with qscanq on Linux, but had unexplained qq read errors on FreeBSD that I have not been able to explain yet. So I'd try this only with caution. You also might try moving some components off of this machine, like clamd, spamd, or even MySQL if you use it. Hope this helps, Bill Shupp Best Regards, Jeff Koch Best Regards, Jeff Koch, Intersessions
Re: [toaster] Suggestions for improving performance
Tom Collins wrote: On Feb 27, 2004, at 3:08 PM, Bill Shupp wrote: The one thing that you can lose by doing this is chkuser support. Two workarounds are to use MySQL w/ valias support, or perhaps share the mail spool via NFS. Mailing lists aren't stored in MySQL, even with valias support turned on. I have ideas on how to do it, but I can't spare the time to work on it unless someone sponsors the work. True. So perhaps the best setup, if you need mailing list support and chkuser, is to use NFS with MySQL. Regards, Bill
[toaster] controlling size of attachments
Does anyone know of a patch that would allow the mailserver to reject emails/attachments over a certain size? Best Regards, Jeff Koch
Re: [toaster] controlling size of attachments
Jeff, That functionality is built into QMail. Edit/Create the file: /var/qmail/control/databytes Enter a value in there in bytes(i.e. my max is 5MB so it reads: 500) Thats it! Peter Jeff Koch wrote: Does anyone know of a patch that would allow the mailserver to reject emails/attachments over a certain size? Best Regards, Jeff Koch
Re: [toaster] Suggestions for improving performance
We thought about using valias support but even with that mailinglists and autoresponders addresses would be missed. NFS mounting of /home/vpopmail always seems a little risky to us. We're going to try mirroring via rsync just the top couple of levels of the /home/vpopmail/domains directories so the chkuser patch has something to check against. At 05:08 PM 2/27/2004, you wrote: Peter Maag wrote: Jeff, We had a similar problem, and our bottleneck was SpamAssassin and Clam Scanner. We ended up putting SpamAssassin and Clamd on a seperate machine that simply scanned the incoming messages and passed them onto the primary mail machine that housed the vpopmail accounts, etc. All you need to do is install Bill's toaster on a second machine with Qmailscanner, SpamAssassin, etc, etc. and then setup that machine to forward all mail to your primary box in /var/qmail/control/smtproutes Works like a charm, just make sure DNS points to the scanning server in the MX route. Peter The one thing that you can lose by doing this is chkuser support. Two workarounds are to use MySQL w/ valias support, or perhaps share the mail spool via NFS. Regards, Bill Best Regards, Jeff Koch, Intersessions
Re: [toaster] Suggestions for improving performance
Has anyone ever tried this - is it a reliable solution? do the servers bog down waiting for NFS repsonses? At 06:04 PM 2/27/2004, you wrote: Tom Collins wrote: On Feb 27, 2004, at 3:08 PM, Bill Shupp wrote: The one thing that you can lose by doing this is chkuser support. Two workarounds are to use MySQL w/ valias support, or perhaps share the mail spool via NFS. Mailing lists aren't stored in MySQL, even with valias support turned on. I have ideas on how to do it, but I can't spare the time to work on it unless someone sponsors the work. True. So perhaps the best setup, if you need mailing list support and chkuser, is to use NFS with MySQL. Regards, Bill Best Regards, Jeff Koch, Intersessions
[toaster] Suggestions for improving performance
Does anybody have any suggestion for improving the performance of a mailserver runnning qmail/vpopmail/qmailadmin/qmail-scanner/spamassassin? We're using a 2.4Ghz P4 with 1GB RAM and a 40GB SCSI drive. The operating system is a basic RH8.0 install with the ext3 journalling file system. We're handling about 50K messages/day and seem to exhausting the capabilities of the server. During peak periods CPU idle time reaches 0% and load averages will exceed 10.0 We've seen some recommendations ( http://people.redhat.com/alikins/system_tuning.html , for example) for changing hard disk and file system parameters mostly having to do with read/write caching and cache sizes and minumum delays before writing to disk but we have been afraid to try any of these for fear of making things worse. We would welcome any suggestions or URL's that you could point to - particularly with respect to performance tuning that will work with qmail. Thanks Best Regards, Jeff Koch
