Return-Path: Delivered-To: apmail-perl-modperl-archive@www.apache.org Received: (qmail 65284 invoked from network); 24 Jun 2008 00:47:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 24 Jun 2008 00:47:23 -0000 Received: (qmail 63543 invoked by uid 500); 24 Jun 2008 00:47:19 -0000 Delivered-To: apmail-perl-modperl-archive@perl.apache.org Received: (qmail 63523 invoked by uid 500); 24 Jun 2008 00:47:19 -0000 Mailing-List: contact modperl-help@perl.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list modperl@perl.apache.org Received: (qmail 63512 invoked by uid 99); 24 Jun 2008 00:47:19 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 23 Jun 2008 17:47:19 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of zx_viper_xz@hotmail.com designates 65.54.246.213 as permitted sender) Received: from [65.54.246.213] (HELO bay0-omc3-s13.bay0.hotmail.com) (65.54.246.213) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Jun 2008 00:46:26 +0000 Received: from BAY113-W34 ([65.54.168.134]) by bay0-omc3-s13.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 17:46:45 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_57ca86fe-6555-420e-80ee-bbad536bc9dd_" X-Originating-IP: [59.167.116.199] From: James Austin To: Subject: Apache (httpd) + Persistant Perl (ModPerl/SpeedyCGI) + User Based Processes (SuExec) + Chroot Date: Tue, 24 Jun 2008 10:46:45 +1000 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 24 Jun 2008 00:46:45.0201 (UTC) FILETIME=[C6C8B410:01C8D593] X-Virus-Checked: Checked by ClamAV on apache.org --_57ca86fe-6555-420e-80ee-bbad536bc9dd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I was referred to this mailing list from the following thread on perlmonks = (http://www.perlmonks.org/index.pl?node_id=3D693487) =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 For years I have been using modperl and have been quite fond of it, the ide= a of persistant perl interpereter is excellent.The problem however lies wit= h using modperl securely for multiple sites. Ideally, the desired solution = is to have each site run in a chroot jail for security, have each site exec= ute under it's own user/group and have a modperl instance for each site.Up = until now the best solution I have been able to come up with is as follows:= Implementation 1:=20 Top Level Apache Server, Port 80, ModProxy=20 This serves requests via ModProxy to the respective apache servers with mod= _perl.Site 1 Apache Server, Port 8081, ModPerl=20 This server runs an instance of ModPerl and all scripts required for Site 1= .Apache User: site1Site 2 Apache Server, Port 8082, ModPerl=20 This server runs an instance of ModPerl and all scripts required for Site 2= .Apache User: site2This allowed me to have seperate modperl instances, this= is done for three reasons:=20 1) ModPerl does not support user based processes2) This prevents pollution = between instances & secures one mod_perl instance from another.3) Each inst= ance can be chrooted for additional security.The problem with this configur= ation is:=20 1) Requires a new http server for each additional site/modperl application2= ) Apache creates a set of workers for each instance (ususally about 7). Wit= h 7 required for the Top level proxy, and 7 for each site, this soon adds u= p.=20 e.g. 5 sites =3D 7 + (5 * 7) =3D 49 child workers--------------------------= -------Implementation 2:A new solution I have been working on is to have a = single Apache server with chrooting suexec and speedycgi.The setup is as fo= llows:=20 1. Create a Chroot Jail for Apache (Extra Security Measure). 2. Modify suEx= ec to allow chrooting before suid and process execution.3. Install Apache i= nto Chroot Jail4. For each site: a. Create a Jail for each site that includes perl + speedycgib. Create a vi= rtualhost which specifies SuExecUserGroup and the ENV variable used for the= chroot.How it works:=20 Apache first resides in a jail, it then serves non-perl requests to static = objects as per normal. When a request for a perl script is made:=20 Apache chroots into the site's jail using suexec. Suexec changes to the cor= rect site's user.SpeedyCGI then either: Loads a script into speedy-backend orExecutes a script cached in speedy-bac= kendAdvantages:=20 1) Provides persistant perl WITH suexec for per-virtualhost user execution2= ) SpeedyCGI handles dynamic data, Apache handles static, hence you don't re= quire a covering proxy as described in http://perl.apache.org/docs/1.0/guid= e/strategy.html3) The timeout property in speedycgi means that a script wit= h low or no load will drop out of memory, this means high use scripts will = run in persistant perl and low use scripts will load into memory then remov= e themself when they are no longer being activly used. Disadvantages:=20 1) Speedycgi seems to be no longer in development, whereas modperl is still= in active development.2) I have read somewhere that speedycgi is not as fa= st as modperl (will have to benchmark the two later).3) Since speedycgi wit= h timeout enabled fades out with inactivity, the first request to an inacti= ve script requires all the modules to be reloaded, whereas modperl exists i= n memory indefinitly and can load a script on server start, rather than fir= st request. ---------------------------------I was wondering if I could get= some feedback on both these designs. I have been researching and testing t= he second solution over the last few days and would like to get some input.= a) Is there a better way to achive this goal?b) Is there a way to make modp= erl scale and attain the desired results without creating a new server for = each instance (Implementation 1)?c) Have I missed anything (security etc. (= Implementation 2))?d) Is there a better solution (fastcgi/pperl etc.)?e) Wh= at are there any downsides (other than those listed above) to either of the= se implementations?Finally, are there any suggestions/ideas?James Austin=20 _________________________________________________________________ Never miss another e-mail with Hotmail on your mobile. http://www.livelife.ninemsn.com.au/article.aspx?id=3D343869= --_57ca86fe-6555-420e-80ee-bbad536bc9dd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I was referred to this mailing list from the foll= owing thread on perlmonks (http://www.perlmonks.org/index.pl?node_id=3D693487)

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

For years I have been using modperl and have been quite fond of it, the = idea of persistant perl interpereter is excellent.

The problem howev= er lies with using modperl securely for multiple sites. Ideally, the desire= d solution is to have each site run in a chroot jail for security, have eac= h site execute under it's own user/group and have a modperl instance for ea= ch site.

Up until now the best solution I have been able to come up = with is as follows:

Implementation 1:=20

Top Level Apache Server, Port 80, ModProxy=20
This serves requests via ModProxy to the respective apache serv= ers with mod_perl.
Site 1 Apache Server, Port 8081, ModPerl=20
This server runs an instance of ModPerl and all scripts require= d for Site 1.
Apache User: site1
Site 2 Apache Server, Port = 8082, ModPerl=20
This server runs an instance of ModPerl and all scripts require= d for Site 2.
Apache User: site2
This allowed m= e to have seperate modperl instances, this is done for three reasons:=20
1) ModPerl does not support user based processes
2) This pre= vents pollution between instances & secures one mod_perl instance from = another.
3) Each instance can be chrooted for additional security.
The problem with this configuration is:=20
1) Requires a new http server for each additional site/modperl = application
2) Apache creates a set of workers for each instance (ususal= ly about 7). With 7 required for the Top level proxy, and 7 for each site, = this soon adds up.=20
e.g. 5 sites =3D 7 + (5 * 7) =3D 49 child workers
<= /BLOCKQUOTE>---------------------------------

Implementation 2:
A new solution I have been working on is to have a single Apache serv= er with chrooting suexec and speedycgi.

The setup is as follows:=20
1. Create a Chroot Jail for Apache (Extra Security Measure). 2.= Modify suExec to allow chrooting before suid and process execution.
3. = Install Apache into Chroot Jail
4. For each site:
a. Create a Jail for each site that includes perl + speedycgib. Create a virtualhost which specifies SuExecUserGroup and the ENV varia= ble used for the chroot.
How it works:=20
Apache first resides in a jail, it then serves non-perl request= s to static objects as per normal. When a request for a perl script is made= :=20
Apache chroots into the site's jail using suexec. Suexec change= s to the correct site's user.
SpeedyCGI then either:
Loads a script into speedy-backend or
Executes a script cach= ed in speedy-backend
Advantages:=20
1) Provides persistant perl WITH suexec for per-virtualhost use= r execution
2) SpeedyCGI handles dynamic data, Apache handles static, he= nce you don't require a covering proxy as described in http://perl.apache.o= rg/docs/1.0/guide/strategy.html
3) The timeout property in speedycgi mea= ns that a script with low or no load will drop out of memory, this means hi= gh use scripts will run in persistant perl and low use scripts will load in= to memory then remove themself when they are no longer being activly used. =
Disadvantages:=20
1) Speedycgi seems to be no longer in development, whereas modp= erl is still in active development.
2) I have read somewhere that speedy= cgi is not as fast as modperl (will have to benchmark the two later).
3)= Since speedycgi with timeout enabled fades out with inactivity, the first = request to an inactive script requires all the modules to be reloaded, wher= eas modperl exists in memory indefinitly and can load a script on server st= art, rather than first request.
------------------------------= ---

I was wondering if I could get some feedback on both these desig= ns. I have been researching and testing the second solution over the last f= ew days and would like to get some input.

a) Is there a better way t= o achive this goal?
b) Is there a way to make modperl scale and attain t= he desired results without creating a new server for each instance (Impleme= ntation 1)?
c) Have I missed anything (security etc. (Implementation 2))= ?
d) Is there a better solution (fastcgi/pperl etc.)?
e) What are the= re any downsides (other than those listed above) to either of these impleme= ntations?

Finally, are there any suggestions/ideas?

Jame= s Austin
Hotmail on your mobile. Never miss anothe= r e-mail with = --_57ca86fe-6555-420e-80ee-bbad536bc9dd_--