Apache (httpd) + Persistant Perl (ModPerl/SpeedyCGI) + User BasedProcesses (SuExec) + Chroot - modperl

This is a discussion on Apache (httpd) + Persistant Perl (ModPerl/SpeedyCGI) + User BasedProcesses (SuExec) + Chroot - modperl ; I was referred to this mailing list from the following thread on perlmonks ( http://www.perlmonks.org/index.pl?node_id=693487 ) =================================== For years I have been using modperl and have been quite fond of it, the idea of persistant perl interpereter is excellent.The problem ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Apache (httpd) + Persistant Perl (ModPerl/SpeedyCGI) + User BasedProcesses (SuExec) + Chroot

  1. Apache (httpd) + Persistant Perl (ModPerl/SpeedyCGI) + User BasedProcesses (SuExec) + Chroot

    I was referred to this mailing list from the following thread on perlmonks (http://www.perlmonks.org/index.pl?node_id=693487)

    ===================================

    For years I have been using modperl and have been quite fond of it, the idea of persistant perl interpereter is excellent.The problem however lies with 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 execute 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:
    Top Level Apache Server, Port 80, ModProxy
    This serves requests via ModProxy to the respective apache servers with mod_perl.Site 1 Apache Server, Port 8081, ModPerl
    This server runs an instance of ModPerl and all scripts required for Site 1..Apache User: site1Site 2 Apache Server, Port 8082, ModPerl
    This server runs an instance of ModPerl and all scripts required for Site 2..Apache User: site2This allowed me to have seperate modperl instances, thisis done for three reasons:
    1) ModPerl does not support user based processes2) This prevents 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:
    1) Requires a new http server for each additional site/modperl application2) Apache creates a set of workers for each instance (ususally about 7). With 7 required for the Top level proxy, and 7 for each site, this soon adds up.
    e.g. 5 sites = 7 + (5 * 7) = 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 follows:
    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 Jail4. For each site:
    a. Create a Jail for each site that includes perl + speedycgib. Create a virtualhost which specifies SuExecUserGroup and the ENV variable used for thechroot.How it works:
    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:
    Apache chroots into the site's jail using suexec. Suexec changes to the correct site's user.SpeedyCGI then either:
    Loads a script into speedy-backend orExecutes a script cached in speedy-backendAdvantages:
    1) Provides persistant perl WITH suexec for per-virtualhost user execution2) SpeedyCGI handles dynamic data, Apache handles static, hence you don't require a covering proxy as described in http://perl.apache.org/docs/1.0/guide/strategy.html3) The timeout property in speedycgi means that a script with 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 remove themself when they are no longer being activly used. Disadvantages:
    1) Speedycgi seems to be no longer in development, whereas modperl is stillin active development.2) I have read somewhere that speedycgi 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, whereas modperl exists in memory indefinitly and can load a script on server start, rather than first request. ---------------------------------I was wondering if I could getsome feedback on both these designs. I have been researching and testing the 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 modperl 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) What are there any downsides (other than those listed above) to either of these implementations?Finally, are there any suggestions/ideas?James Austin
    __________________________________________________ _______________
    Never miss another e-mail with Hotmail on your mobile.
    http://www.livelife.ninemsn.com.au/a...aspx?id=343869

  2. Re: Apache (httpd) + Persistant Perl (ModPerl/SpeedyCGI) + User Based Processes (SuExec) + Chroot

    On Mon, Jun 23, 2008 at 8:46 PM, James Austin wrote:
    > 1) Requires a new http server for each additional site/modperl application
    > 2) Apache creates a set of workers for each instance (ususally about 7).
    > With 7 required for the Top level proxy, and 7 for each site, this soon adds
    > up.


    That's entirely under your control. You can start as few or as many
    as you like, and vary the settings by site if you choose to. You
    would want about 20 times as many front-end server processes as
    backend ones to start with.

    > A new solution I have been working on is to have a single Apache server with
    > chrooting suexec and speedycgi.


    SpeedyCGI's only advantage over FastCGI was that it could be installed
    and used by a non-privileged user on a shared host without any direct
    support from the hosting provider. At this point, it's been a dormant
    project for ages. I think you'd better try FastCGI instead.

    However, I don't really see any advantage to FastCGI over the mod_perl
    setup you suggested.

    - Perrin


  3. Re: Apache (httpd) + Persistant Perl (ModPerl/SpeedyCGI) + User BasedProcesses (SuExec) + Chroot


    James Austin wrote:

    >
    > Advantages:
    >
    > 1) Provides persistant perl WITH suexec for per-virtualhost user
    > execution
    > 2) SpeedyCGI handles dynamic data, Apache handles static, hence you
    > don't require a covering proxy as described in
    > http://perl.apache.org/docs/1.0/guide/strategy.html


    You can configure the Apache proxy server to server static content in
    the mod_perl configuration as well, either directly or via caching. You
    can have the back server serve static content on an initial request,
    then have the proxy cache it for some time period. We do this because it
    allows you to run a single back server when doing development as it
    knows how to serve everything.

    > 3) The timeout property in speedycgi means that a script with 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 remove themself when they are no longer being activly used.


    You can configure Apache to do this with your mod_perl servers too. You
    can configure the number of servers (as Perrin mentioned) and Apache
    will expand to based on load. Apache will clean up as load goes away.
    You can also set the children to exit after a number of requests. Check
    out these Apache directives: MaxClients, MaxRequestsPerChild,
    MaxSpareServers, MinSpareServers, StartServers.

    >
    > a) Is there a better way to achive this goal?
    > b) Is there a way to make modperl scale and attain the desired results
    > without creating a new server for each instance (Implementation 1)?


    You mention security, but you didn't say if you had a requirement for
    the different processes to not share memory. If this isn't required, you
    can put your app-specific code in separate modules and handlers. This
    would avoid multiple servers and allow you to share memory with shared
    modules (CGI, DBI, etc.).

    > c) Have I missed anything (security etc. (Implementation 2))?
    > d) Is there a better solution (fastcgi/pperl etc.)?
    > e) What are there any downsides (other than those listed above) to
    > either of these implementations?


    The main problem with the one server per app implementation is likely to
    be scaling. While you have as many ports as you need, at some point the
    server will run out of memory if you get above some number of
    applications. If you don't think you'll have than many, it should work fine.

    Jim


    --
    Jim Brandt
    Administrative Computing Services
    University at Buffalo


+ Reply to Thread