On Thu, 7 Sep 2000, Félix C.Courtemanche wrote:
> Hi,
>
> I have been looking around for some time already about this and here are the
> 2 solutions I came up with... I would like some comments, especially if you
> think it would be safe / fast to use.
Uhm, did you read the proposed solutions at
http://perl.apache.org/guide/multiuser.html
> Solution #1 (apache solution)
> ¯¯¯¯¯¯¯¯¯
> - Use a centralized apache server for all html request, graphics, etc.
> mod_php and mod_perl disabled on this server
> - Redirect a certain directory or sub domains to a personalized apache
> server (on an unprivileged port), running under the client's uid.
> - That personalized server would be compiled with mod_perl and mod_php, and
> running with the following apache directives:
> - RLimitMEM (http_core.c) :: Soft/hard limits for max memory usage per
> process
> - RLimitNPROC (http_core.c) :: Soft/hard limits for max number of
> processes per uid
> - It would also have the Apache-Watchdog-RunAway perl module installed to
> kill zombies.
>
> That solution would allow the fastest setup (as far as I am concerned) but I
> am afraid that redirecting the directory to a personalized apache server
> could generate some problems... I thought of redirect using the [P] flag
> (proxy) so that the url viewed in the browser stay the same... however, for
> each queries, 2 httpd process will have to handle it. This may hurt the
> performances for a web site using a lot of scripts.
Nauh, it won't hurt the performance. Almost everybody uses this
scenario. See http://perl.apache.org/guide/strategy.html
> Solution #2 (perl module solution)
> ¯¯¯¯¯¯¯¯¯
> - Only use 1 apache server for everyone
> - Use Apache:SizeLimit (included with mod_perl) (memory watchdog)
> - Use Apache-watchdog-runaway (same as above)
> - Use apache:resources for other control
> - Use Apache:safe and apache:safe:hole to restrict the use of mod_perl...
> however I may have to fight with it a bit to allow DBI and other similar
> modules to be used as well
>
> That solution appears to be faster for me, but a lot harder to set up and
> configure. It may involve some programmation, etc.
>
>
> What is your opinion on these... and do you have a better solution? Wich one
> is the best?
> I am open for any comments and help... I plan to set up some package or at
> least a web page to explain to others how to do it once it is working
> perfectly for me. I noticed that perl security (along with shell security)
> is one of the worst seucirty/privacy treat in almost all web hosting
> companies... and I intend to solve this. :)
I don't see any security-wise differences between #1 and #2. These are
performance issues, where #1 wins in most cases, while #2 is Ok for
specific content delivery setups. See the Strategy chapter link above.
You still run mod_perl in both setups, so this is the only thing that you
have to solve.
I've an overdue article in the queue of things that I've to do, that talks
about this, mainly based on the multiuser.html chapter and the information
I've collected from ISPs a month ago. (Not much though, so if you have
some information to share with public and plug the name of your mod_perl
ISP service in make sure to contact me.).
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perlmonth.com perl.org apache.org
