While I understand that it might be an "advantage" to allow the customer's
their own mix of modules, it can also be a bit of a support headache as
different customers will be loading different DSOs presumably even in
different orders. There may be subtle bugs with module interaction that
providing a standard set of one or two Apache binaries would solve for the ISP.
However, I do agree that you should not compile in mod_perl and other
modules like it by default for the front-end servers.... The reason is
security. Core Apache is complicated enough without adding to the potential
for buffer overflows. The more lines of code you add, the greater the
likelihood of bugs, some of those bugs have a likelihood of being security
bugs.
By only having a subset of users using a DSO, or making a back-end server
use this stuff, you could limit the possibility that the main web server
itself is subject to the overflow (although this is still a risky scenario,
it is less risky than compiling everything in one monolithic apache) since
the front-end could be designed to have very little in it except for an
Intrusion Detection system (which I am under the impression that someone is
writing?).
Anyway, I guess it all boils down to balance and the risks (either support
or security) you are willing to take as an ISP. Adding mod_perl certainly
is a risk in itself! But one that I think many of us definatley would not
mind paying extra for as a dedicated server solution is extremely expensive
as it is.
Later,
Gunther
At 04:26 PM 4/12/00 +0000, Jesse Wolfe wrote:
>At 02:54 PM 4/12/00 -0700, Tom Brown wrote:
> >On Wed, 12 Apr 2000, Jesse Wolfe wrote:
> >
> >> I am working with www.superb.net to get their mod_perl up and working
> >> again. They have great infrastrucure, lots of great tools, and an amazing
> >> price.
> >> They had apache/mod_perl for awhile, and upgrades broke it. I expect they
> >> will have it in a week or two, if we can use all these dynamic/shared
> >> modules as planned.
> >
> >strikes me (as an owner of a web hosting service) that DSO is the wrong
> >answer. What does DSO buy you? NOTHING except a complete waste of
> >memory...
>
>well, it would let each customer add their own combo of modules to their
>apache server without requiring either two installs (one with, one without
>mod_perl) or making everyone's server run mod_perl even if they aren't
>using it.
>
>But it is a good question... I found it kind of unusual to request that
>EVERY Apache module be dso, including mod_perl, mod_ssl, PHP3, and libdav.
>I'm not even sure that it's possible that it will run well. Any advise
>anyone has here would be most appreciated.
>
>I'm actually kind of surprised I got mod_perl DSO 'make test' to pass at all.
>
> >
> >I'm reading between the lines here, but it sounds like you are trying to
> >have _one_ parent apache daemon that services _everything_ on the machine
> >(likely _more_ than one website), which would imply that you are going to
> >have an _extremely_ low hit ratio on your mod_perl scripts.
>
>nahh, that's not where we were going with it. I am pretty sure it's just a
>"maximum flexibility" feature they want to have on hand to minimize tech
>support, etc. Why does DSO waste so much memory? I thought DSO would mean
>all processes share the resident copy of the perl library?
>
> >
> >it strikes me that you _want_ a frontend proxy to feed your requests to
> >the smallest number of backend daemons which are most likely to already
> >have compiled your scripts. This saves memory and CPU, while simplifying
> >the configuration, and of course, for a dedicated backend daemon, DSO buys
> >nothing... even if that daemon uses access handlers, it still always needs
> >mod_perl
>
>remember we're talking an entire ISP, not just a website. I think it might
>be a mighty pain to have everyone running or sharing some backend mod_perl
>server. Logs and all that.
>
> >
> >That said, we bought modperl-space.com back when domains suddenly got
> >cheap, but haven't put together a mod_perl package because we really don't
> >know what folks want/are using it for.
>
>seems like most folks with enough ?? to be using mod_perl are either
>working corporate or have their own hosts and don't have to deal with ISP's
>on the mod_perl issue. With all this talk about mod_perl programmers being
>needed, I'm surprised to find so few ISP's offering it. Bottom line it
>seems you need to be able to keep a mod_perl guru on hand just to keep it
>going... the compilation, etc. of it is so complex. I actually need to
>leave my original mod_perl isp because they just don't have the staff to
>make the right mods to their system, even if I figure it out for them.
>Their mod_perl person got up and left and they can't seem to hire a
>replacement. Anyone in Boston area would like to work with a pretty decent
>ISP?
>
>Regards,
>
>Jesse
>
>
