On Friday 08 Apr 2005 15:14, John Peacock wrote:
> This is, indeed, probably the easiest and best way to handle it (it
> requires the fewest changes). �Using qpsmtpd-forkserver is actually
> fairly efficient in terms of CPU (if not of RAM), so the age of your
> hardware shouldn't be a big deal. �Don't tell anyone, but my inbound
> servers are running on Cobalt RaQ3's upgraded to 450MHz AMD K6 CPU's
> (which is comparable to a Pentium II 500MHz) and I'm running two(!) AV
> scanners on most messages. �If you aren't using forkserver (or pperl if
> desired), you are probably better off to stop using tcpserver than
> editing any code at all.
I'm using an old 233 Pentium laptop - it's quiet, it's compact (same size and
weight as "Programming Perl"), it draws very little power (~8 Watts) and it
has it's own UPS ! Mostly it gets by, and like you say this is the simplest
approach to just "get the job done", but I thought I'd float the idea to see
if there was any interest in "yeah, I could then use that for some other
problem" (e.g. combining scores from multiple plugins or the like).
I could look at ditching tcpserver, but I think it's spamassassin and the like
(even in daemonised form) that's taking the time (tho I do seem to end up
with a load of sockets strangely hung in CLOSING state every now and then,
maybe this is tcpserver mis-behaving somehow).
> > �- a single qpsmtpd setup, but use tcprules with tcpserver to set an
> > environment variable which could point at a different config folder in
> > Qpsmtpd::get_qmail_config()
>
> Interesting idea but I don't know how well that will work (since the
> config code is mostly interested in "get the qmail config files and if
> nothing there, use the local config files"). �You could also look at the
> http_config plugin to see how you can leverage the config hook.
I think it would work OK if in that one routine, where it uses "/config/" I
could change that part of the path lookup based on an env var or similar...
� my $cfgdir = ENV{QPSMTPD_CONFIG} || "config";
and then I could easily override to point at "config.localnet/" and the like.
> These are probably out of the scope for what you want to do. �The
> plugins are so varied in function that trying to create a general state
> management system would be very difficult.
Yeah, just pointing out the range beyond "quick hack" to see if anyone got
excited about it.
> Hardware is usually pretty cheap, compared to the time involved in
> revamping the codebase. �You should check out this great service called
> eBay, where people sell just about anything for sometimes very
> reasonable prices... ;-);-)
True, but new hardware gets old over time, whereas features last forever, and
features get shared without us all having to buy new kit �;^)
If there's not any interest then I'll simply drop the idea, but I thought I'd
float it by a few people.
Cheers
--
Tim
