This is a discussion on Re: sendmail wrapper to find spammer-magnet scripts - Networking ; >> started small scale with self-contained servers with each >> one dealing with its own pop3/ftp/apache/smtp/mysql/dns... >> then grown very quickly by replication of live servers. > > Oh dear, and none had ever heard about virtual hosting...;( Guess > ...
>> started small scale with self-contained servers with each
>> one dealing with its own pop3/ftp/apache/smtp/mysql/dns...
>> then grown very quickly by replication of live servers.
> Oh dear, and none had ever heard about virtual hosting...;( Guess
> most systems are just idling along, wasting rack space and
> power. This would be a great challenge for you, combining all
> those on a very few systems.
Oops, I really ought to say "self-contained servers with
each one dealing with its own pop3/ftp/apache/smtp/mysql/dns
for well over 1000 domains". Yep, we certainly have virtual
As for Menno's comments.. I think I'm going to have to read
that through very slowly.
> You'll probably want to look at suPHP for .php scripts
> (especially if you'll be moving from mod_php to a
> 'per user' configuration). As suEXEC expects to handle
> "normal" CGI scripts (with a shebang line) and SSI.
> If this all hapens to cause performance problems, have
> a look at FastCGI with like mod_fcgid too.
I hadn't realised that suEXEC is purely for tradistional CGI
scripts. Ah.. I'll carry on reading... slowly.
> Rather then wrap the (send)mail commands you could then
> just run an ident service (like pidentd or authd) in
> order to log any offending users.
I'll have to find out about these two services. I'm finding
that this wrapper idea is more hassle than I thought.
There is the
/usr/sbin/sendmail -> /var/qmail/bin/sendmail (binary)
Each method of injecting mail into the queue needs its own
wrapper since since I need the calling process info.
cat /proc/$PPID/cmdline | tr '\0' '\n'
ls -l /proc/$PPID/cwd
and maybe even
proc/$PPID/environ | tr '\0' '\n' (since some qmail methods
pick up environment variables too)
> Since lusers aren't going to be happy should you disable
> their scripts (however buggy they may be);
It seems that this has become company policy as a quick fix
to stop one cause of spam.
> something you might want to consider aswell is to write
> some filter rules for mod_security, or something similar.
mod_security?.. blank stare...
Again.. some more very slow reading involved since there is
nobody at the company I could ask, it would be up to me to
learn, convince, implement then educate. I may as well get
> BTW: Cfengine or Puppet can automate rolling this stuff
I shall google for these.
> (Better still, however even more effort on your part,
> would indeed be to redesign the whole thing dedicating
> machines to specific tasks, as Michael pointed out).
Oh, I'd love to, and that was a top priority for about 2
weeks, then it looks like it's being shelved so that we can
do an IP migration. (Hence my push for squashing the spam
generated by scripts on our servers.) Ireally don't want to
end up on SpamBlackLists withing days of the migration.
Oh well.. off to do some Googling:-
Never criticize a man 'til you've walked a mile in his shoes.
After that, you can say what you like..
'cos you're a mile away and you've got his shoes.