[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: suEXEC witch mod_userdir

Michael Loftis wrote:
> --On March 12, 2009 1:31:55 PM -0700 Seth Mattinen <sethm@rollernet.us>
> wrote:
>> Thomas Goirand wrote:
>>> Marc Aymerich wrote:
>>>> Hi Thomas!
>>>> Thanks for your recommendation. We have considered using DTC control
>>>> panel in our servers, but the structure of DTC is not compatible with
>>>> our system. We have 3 virtualized servers, for web, mail and mysql,
>>>> each of this servers mounts a different disk partition from a SAN
>>>> server, and DTC stores web and mail in the user home directory, so we
>>>> have no idea how to adapt this to our needs.
>>> I see absolutely no reasons why you would separate in 3 servers if they
>>> are all visualized. If you do that, that is because you don't have
>>> enough resources on ONE server, there is no reason otherwise.
>> There are plenty of reasons for ensuring, for example, something doesn't
>> walk all over MySQL or a mail flood doesn't eat up all the resources and
>> take the website down. Especially if user shell account are permitted on
>> the web server.
> And virtualization doesn't really solve this.  There's no virtualization
> system that allows you to set QoS on Disk I/O and most of the time, when
> a server starts to pop, it's Disk I/O nowadays.  That's not to say that
> it ALWAYS is, but a LOT of the time it is.  Now Virtualization in
> concert with dedicated disk pools can, assumign your virtualization
> allows you to keep the virtualized machines from interfering with
> eachother in other ways (Network, CPU, and Memory resources for example)

It also means you don't have to to screwy things to separate services
running on the same machine. Sure you can do run on-server firewalls,
run multiple instances of daemons out of different roots, views, or
similar things. Or you can simplify and split them out to their own VM.
When the next remote root exploit for something comes along, who cares?
It's in it's own little world. You can rest easily knowing there's no
way for anything to get outside the VM. Fix it, of course, but the scope
of damage is restricted to a known environment. Even worse, you get
rooted. Do you really know the extent? Most people will recommend you
wipe it and restore. Much less painful if it's just one tiny VM.

Some audit processes require such separation - some even require NAT in
absurd cases. Sure, argue it, but the auditors will still put you down.
I'm sure you'll find reasons to argue against every little thing I said
and claim I'm wrong, but to state there is absolutely never any reason
to run virtual servers for services that could be combined is ignorant
and absurd.


Reply to: