On Tue, 2003-12-23 at 13:23, Anthony DeRobertis wrote:
> On Dec 22, 2003, at 19:10, Greg Folkert wrote:
> >
> > The best part *IS* the split out. I can add or remove "pieces".
>
> You can add and remove pieces from a single file, too.
But adding them in a relevant file name. Simply I use in routers (of
which I have a few dozen)
350_spamcheck, 999_catchall_doaminname, 999_catchall_username_variant,
in each of the 999s have expansions, gotten from postgresql. It is all a
matter of using scalable techniques.
> > I am running Hundreds of changes in my config for Debian Exim4. I
> > believe that the Config is a Brilliant use.
>
> I hope the exim4 maintainer never decides to rename one of the .d
> files, or add or new one, or combine two, or...
The point is that breakout simplifies. The way things are broken out
right now are very simply done according to the respective usage.
I would think that 700_exim4-config_procmail would have things
pertaining to the default set of procmail rules with requires involved
in the conditional. And guess what.. it is. If procmail ain;t installed
it doesn;t work. It the user doesn't have .procmail in the home dir...
not gonna happen.
Now for the Virtual stuff, most user will never even log into the
machine. There for no need to worry the router will get executed.
Now... my 350_exim4-config_spamcheck router runs on any piece of mail
in-or out of my machine once. No wonder... it has to tagged with, look
at the conditional:
> # SpamAssassin
> spamcheck_router:
> no_verify
> check_local_user
> # When to scan a message :
> # - it isn't already flagged as spam
> # - it isn't already scanned
> condition = "${if and { {!def:h_X-Spam-Flag:} {!eq {$received_protocol}{spam-scanned}}} {1}{0}}"
> driver = accept
> transport = spamcheck
Yes that is stock dman13 pieces. But it works.
> > Think about xinetd, a
> > similar directory work exceptionally well for it. Additionally I use a
> > very similar setup for managing my virtual apache hosting.
>
> Those work great because they are largely independent. Your FTP server
> and your POP3 server don't really have anything to do with each other,
> other than running from xinetd.
Yes, they are separate services... but so is every single virtual host
you have. Largely independent of each other. Yet exim4 is still dealing
with them all. Same with Apache.
Heck I am even doing ETRN using exim4, for a few domains as well. It is
nice to be able to modify the files NAMED:
972_exim4-config_ETRN_domain_expansion
and the transports NAMED:
597_exim4-config_ETRN_honkytonk.bomb
and know they are related... except one uses expansion to use the other.
Now, the "big file" you want with comments looks like:
/var/lib/exim4/config.autogenerated
And, if you use: update-exim4.conf --keepcomments
It will look just like you want.
> Your virtual hosts in apache don't have much to do with each other,
> either, I'd guess. And I imagine you are the only person that will ever
> put files in your virtual host directory, so you don't have to worry
> about it breaking.
Yes, mainly because I cater to a higher degree of user/customer. One
that is a typically self service individual, one that has sudo rights on
the machine that is shared by everyone... If they break it, the machine
will automagically check for diffs against the previous config and
comment out the offending piece that was changed. Then e-mail the
changer and myself... and they fix it... and I'll re-enable it. I have
only had it happen once. It worked they way I wrote it...
> > Exim4 suits simple prospects with the update-exim4.conf.conf.
>
> The point is, both methods work fine for the debconf-only setup, so its
> not an advantage.
Never said it was an advantage, you said it *WAS* a disadvantage.
> >
> >> For more complicated configurations, those changes --- possibly even
> >> including new or removed files --- happening without ANY prompting and
> >> any chance to merge your changes --- is very worrying.
> >
> > That is all part of making you config properly. For add-ins I use I
> > numbers that are not the same as what the packages deem. Think large
> > scale... changes are made in pieces not wholesale.
>
> It depends on what you're doing. I'm doing email virtual hosting.
> Different domains are different. They have different policies,
> different users, etc. That means several of the routers have to be
> fixed.
I too am doing virtual hosting, I have different policies, different
SpamAssassin configs, some default "copy to" to a salesmanager, some
users are real, MOST are DB Driven :), some of the mail is even stored
in the DB vs in Maildir. I use a combo of Maildrop, Procmail and other
MDAs to get the job done. I also do the same with Apache Configs and
other services I offer. Webmail, Webmail-SSL, IMAP, IMAP-SSL, POP3,
POP3-SSL, SSH Logins for those that pay for it, SUDO access for those
that pay for it, Many other pieces... everything it modular. I can
remove a whole domain(or customer) from Logins, Apache, E-Mail, etc...
all by removing the control file.
> The virtual users don't all have their own UID/GID (most don't). Mail
> is delivered to Maildirs, not mboxs. Users, domains, quotas, UIDs,
> GIDs, etc. come out of mysql. That takes some fairly major changes to
> the transports.
Yeap... some of my transports are *GASP* 35 lines (not 25 like I
thought) long...
> Mail to postmaster@ and abuse@ is handled specially. That's a few more
> routers. I still need to get ip literals for postmaster@ and abuse@
> working; that'll probably be another router.
Okay, you obviously are talk RFC compliance... been there done that...
plus I can let the owner change that themselves.
> I plan to get he blocklists for senders and hosts to also come from
> mysql. Same with virus and spam filtering settings.
Am there, am doing it. I have Blacklists, Whitelists, seperate configs
for SpamAssassin for some domains, ClamAV setup per domain if the domain
file exists, others all(mostly) use the default I provide.
> >
> > My transports directory has a few hundred files in it. I have a few
> > dozen routers... that use expansions. I have ~200 ACL sets, all
> > separate
> > files. It allows me to tailor my domain or user specific configs for
> > and
> > label them usefully without having to go through a 3MB ASCII File (with
> > comments).
>
> It sounds like you'd be in trouble if, for example, an exim4-config
> upgrade created a new file that assumed all domains are the same and
> are delivered to the users with accounts on the system (the default)
> and it happened to come before all your routers.
They won't (shouldn't) because they numbering scheme has already been
established.
> That's the kind of thing that worries me.
As it should. Backup your configs... that is why you do it.
> > Not likely, I have gone from exim v4.20 -> 4.22 -> 4.24 -> 4.30
>
> Glad to hear it's still working. I'd be less worried if, for example,
> there was a clear policy statement on when files in conf.d will be
> changed (especially renamed or new ones created).
Oh, come on now you are talking about blather now. Clear Policy has
already been quoted by you... and you don't even really understand the
issue at hand.
> > Personally, I find it more able to transfer a setup similar to this to
> > another machine.
>
> scp /etc/exim4/exim4.conf root@new-machine:/etc/exim4/exim4.conf
> doesn't seem to hard to me, but to each his own, I suppose.
If that was meant as an insult, it failed. Also, allowing straight root
login is a bad thing, goes against Debian Policy on Default Security.
I guess I have transferred this idea behind the breakout of configs,
mainly because it is more useful to large scale implementations. I have
used this setup now, with AIX, HP-UX, Tru64, Linux, FreeBSD and OSX. It
is extremely friendly, variables are setup easily, functions work well.
Exactly how many message are you handling a day?
> >
> > I'd much prefer working with several hundred smaller 5-25 line files,
> > meaningfully named vs. grepping through a HUGE ASCII file and possibly
> > losing track of where I am.
>
> Gak. Why do you have several hundred routers, anyway?
I don't have several hundred routers, I have a few dozen. I several
hundred transports that are called using expansion in exim4. ACL number
in the hundreds as well. BTW, good planning and judicious use of exim4
capabilities make the breakout and excellent Idea.
When Philip Hazel gets back from Australia in February/March, I will be
doing a wishlist for the Exim4 default config to be a modified version
of this. Maybe once it gets documented properly (not that Marc or
Andreas don;t do a good enough job) you be less opposed to it.
Also, I get the feeling, you haven't been supporting large scale
implementations of mail infrastructure long.
--
greg@gregfolkert.net
REMEMBER ED CURRY! http://www.iwethey.org/ed_curry
Attachment:
signature.asc
Description: This is a digitally signed message part