Re: Setting up Apache2 with mod_perl and Apache2::AuthCookieLDAP

[Warren Young <warren at etr-usa dot com>]

On 5/6/2014 11:42, Andrew DeFaria wrote:
> I could just switch to a Linux server but I figured I'd try my
> Windows laptop first.

Don't neglect the option of running a minimal Linux VM on the laptop. 
You can shove a headless Linux VMs into a pretty small slice of RAM.

> Goal: Set up Apache2 on my Windows laptop with mod_perl

mod_perl has been slowly dying for years.  It's not dead yet (*thwack*) 
but it pretty much only works with Apache 2.2 and older.  RHEL7 won't 
include it at all, because it will ship with Apache 2.4.6.  There are 
third-party patches floating around the net that restore compatibility, 
but this isn't the sort of thing you want to be building programs 
against that have to live for many years to come.

Cygwin still ships Apache 2.2, but you'd be betting that either Cygwin 
Apache will never be updated to 2.4, or that mod_perl will get dragged 
into the modern world before that happens.

mod_perl is being allowed to die because all the modern web frameworks 
have moved to PSGI/Plack instead: http://plackperl.org/

PSGI abstracts away the operating environment.  You can run PSGI apps 
standalone as their own web server, or behind a fast reverse proxy, or 
in a FastCGI environment (e.g. Apache's mod_fcgid).  From the software 
development perspective, it's all the same.  (Devops is a different 
story, of course.)

A common pattern is to run the PSGI app with an internal web server on 
localhost:3000 or whatever, then put nginx or similar in front of it to 
carry the static content load and proxy dynamic page requests to the web 
app.

Since the native Windows nginx port doesn't yet run as a Windows 
service, it isn't suited for systems that need long uptimes, or which 
can't be left logged in to an interactive desktop.  The native Windows 
version of Apache is only a smidge slower than nginx for many workloads, 
it ships with mod_proxy to make it act as a reverse proxy, and it 
naturally runs as a Windows service: http://goo.gl/woQjYZ

It is common to use HTTP::Server::PSGI (http://goo.gl/o7wmIm) for 
development, and only switch to something more complicated when it comes 
time to deploy to production.  If your web app won't have a high load, 
you may not have to switch at all.  Or, if most of the load is static 
content, you can push that load off onto the reverse proxy. 
Single-threaded dynamic page generation is fine for many web apps.

If you really need concurrent dymamic page generation, a lot of people 
use Starman (http://goo.gl/J97Ac1) rather than a traditional web server. 
 It is a pure Perl pre-forking web server, compatible with PSGI, and 
fast enough that a lot of its users don't use a reverse proxy in front 
of it at all.

If you go Perl-native, your web app can run as a single-instance 
program, which can have tremendous benefits.  A lot of old web 
frameworks persist session data to disk purely because it assumes it 
will run under pre-forking Apache, where there are many short-lived 
children that may contend for access to the session store.  When all I/O 
comes into a single long-lived process, you might not have to persist 
some things to disk at all, greatly reducing that area of I/O overhead. 
 Single-instance web apps also don't have to pay other penalties 
associated with periodically killing off an restarting child forks.

You don't have to use PSGI/Plack directly.  All of the modern Perl web 
frameworks -- Catalyst, Mojolicious, Mason/Poet -- will run under it, 
providing a much nicer usage environment.  I've been using Dancer 
(http://perldancer.org/) for months now, and love it.  I just tested, 
and it does build and run under Cygwin.  Install App::cpanminus with 
cpan, then just say "cpanm Dancer".  Done, easy.

(I chose Dancer because it doesn't impose MVC or ORM policies like a lot 
of other web frameworks do.  (Catalyst, Rails, Zope, etc.)  You're free 
to design your web app however it makes sense to you.)

If you do go with Dancer or something like it, you don't need to use 
Cygwin Apache.  The native Windows version of Apache will perform much 
better, and when used as a reverse proxy, you probably won't need any of 
the benefits you get from using Cygwin Apache which native Apache 
wouldn't have, such as the ability to compile and load some of the more 
esoteric modules that only build on POSIXy systems.

> First problem (minor): I can't figure out how to install Apache2 as a
> Windows service.

Another reason to native Windows Apache instead.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple