On Tue, 2006-03-28 at 17:24 +0200, listrcv wrote:
> Drake Mobius wrote:
> > Virtual domains are a big concern to me..I may be brand new at this but I'm
> > stuck with the task and I need an enterprise-size mail server.
> > cpanel: http://www.cpanel.net/ is used for site config and mgmt
> > plesk: server mgmt for web hosting. think webmin, but bigger.
>
> Hm, that seems like tools needed by/suited to ISPs. That's totally
> different from what I need.
Yes, think large multi-domain
e-mail/webserving/PHP-Perl-Python-CGI/postgresql-mysql setups. Each of
the ones I am hosting each get what they want, when they want it. All
through a web-interface that I have made so that they can request a
feature not currently available. Their config is also manually editable,
but verified when they commit it. If it fails, they get an error back
telling them what failed. And suggesting they use the check boxes.
Here is just a few options I am supporting currently available:
* Full POP3, POP3S, IMAP, IMAPS service, (all, any or none)
* Inline Spam-Assassin, with Pyzor, Razor, RulesDuJour and others,
optional. Can be either receive(incoming) and/or
sending(outgoing) or both or not at all.
* ACLs per Virtual Domain, Aliases, Mailforwarding, server side
mail sorting (procmail or maildrop)
* Inline ClamAV Virus Scanning, with rejection based on either
defaults or customized rules, or allowing the files through but
being flagged as infected.
* Full Apache2 configs, (with tons of available modules) with
manual editing available and syntax checking on commit with
feedback as to which one is bad. (so as to not blow-up apache)
* PHP, Perl, Python capability with or with out a DB connection,
with manual editing and syntax checking on commit (so as to not
blow-up apache)
* Tomcat 5.5, JBOSS and other a application serving.
* Three different blog systems (all, any or none)
* Database usage, BSDdb, MySQL and PostgresQL. Other DBs are
allowed, but additional charges are required (much additional in
some cases)
* DNS with Bind using a templating system. Supporting any record
types. Of course linted before commit, serials automagically
updated.
* Virtual Machines, varying size using products available.
* Build Environments (chroot'd or not) for those that would rather
pay for CPU used rather than always having it available on site.
I don't do Windows, unless my Lively-hood depends on it, which it
doesn't anymore.
> > I think my greatest hate of exim-config thus far has actually been my lack
> > of experience with DEBCONF, and thus all the debconf replacements in the
> > otherwise easy to read config.
>
> yeah
Its just a fact of understand the way Marc, Andreas and others have used
what is available from Debconf. They have "followed the rules." If you
see the beauty of the seperate files for what it is intended to do, its
like magically everything comes into view.
I use it so I don't have to worry about multiple access to hyarge config
file. I can manipulate each file (based on a naming scheme and service
level) without worry if those changes would get on multiple simultaneous
commits, where last one to write wins.
> > It should also be noted that the multi-file config is more like "The Debian
> > Way" tm
> > As you can see with apache, includes of directories of files is easier for
> > dropping in a new section and version managing an existing config. I do this
> > also!
>
> Yes, such a way to configure things has great advantages when you want
> to do things automatically.
Not really, I use it so that all changes are captured and not
over-written by multiple accesses and writes can occur.
> The problem is that automatical things tend
> not to be suited that much for human intervention, so it becomes
> difficult to find a way allowing for both, manual configuration and
> automated. The automated configuration introduces additional learning
> overhead when humans want to interfere --- and be it just to get what
> they want --- and exim-config is a nice example of the problems arising
> from that.
Well, I guess you have a point, but if you make an attempt understand
why Debian really chooses to do this like this it makes a ton of sense,
when you look at thing from an "Easily adding and removing components,
without screwing everything else up" point of view. IOW, I can add and
delete domains just by dropping files in or removing them in the the
router and transport directories, Changing (adding or removing or
editing) ACLs for those domains by dropping files or removing files in
the acl directory makes it possible to allow config for every single
Virtual Domain seperately.
Also, allows me to find and fix individual domain problems (should they
arise) and fix them plus add in the syntax for checking that problem for
the system. Sort of like what Jalopy does for CVS.
> But still, when questions come up like 'How do I configure a mail
> server/my mail to have virus scanning and SPAM checking?', they are
> probably not being asked by ISPs who need flexibility but by
> users/admins who just want what they ask for and who will (want to) end
> up with a static and reliable setup for their mail system. The
> autoconfig is imho not suited for that. Maybe it will include options to
> set these things up at a later stage, but that will still leave users
> alone in case something fails. That is what Windoze does, except that it
> leaves them alone long before ... If they know what they do, they are
> able to help themselfes :)
Yes, it comes down to someone understanding what needs to be done and
how to do it. If I were you, there is a big lesson to be learned.
Learning to do things in Multiple ways (sometimes 50 different ways) is
a good thing. Locking yourself into a Straight and Narrow is a sure path
to being obsoleted.
--
greg, greg@gregfolkert.net
The technology that is
Stronger, Better, Faster: Linux
Use Debian GNU/Linux, its a bazaar thing
NOTICE: Due to Presidential Executive Orders, the
National Security Agency may have read this email
without warning, warrant, or notice, and certainly
without probable cause. They may do this without
any judicial or legislative oversight. You have no
recourse nor protection.
Attachment:
signature.asc
Description: This is a digitally signed message part