Re^6: Time to write a "serious" http server in Perl?

[autarch]

Wow, I've never compiled my own Apache, nor has anybody I've worked with ever suggested we do so. I suppose I can imagine going to the trouble to do so in some situations, but there are a _lot_ of advantages to using the vendor packages.

That said, configuring two apache instances (one backend and one frontend) using stock Ubuntu apache is not terribly hard. I use the vendor-supplied config dir for the frontend, and set up a parallel directory structure for the backend (/etc/apache2-backend, /var/log/apache2-backend, etc). Works great.

[mr_mischief]

If you've never compiled your own Apache, you either haven't been using Apache as long as many of us or you were missing out on a good deal of its better functionality. IMO the vendor binaries from any vendor were not ready for high-volume web hosting just a handful of years ago. In recent years with advances within Apache and in the package management teams for the distributions, prebuilt Apache and addons for it have become a viable option.

There used to be something called Apache Toolkit, which was a menu-driven configurator for Apache, the DSOs, the basic configuration, and more. It was, IME, the most robust way to deploy a strong Apache configuration in a short amount of time. It would apply all the necessary patches, configure the build environment, compile everything, and install it for you. I'm not sure if it's still around, because RedHat/CentOS, Suse, Mandriva, and Debian all seem to have solid enough Apache packages now.

[perrin]

DSO is better than it used to be in apache 1, so there's less reason to do it now, but I still prefer it because I want control over what modules are loading and specific control over how some things (SSL, mod_perl) are compiled. The default one on distros I've seen includes junk you won't use and forces you to use DSO.

The other big problem is that switching versions of apache will usually break mod_perl, so I can't have the OS swapping it out under my feet. I have to be in control of when apache gets upgraded and to what version, much like controlling your CPAN module versions.

[autarch]

Back when Debian had Apache 1 as the default, it offered a separate apache-perl package that had mod_perl statically compiled. You could install the apache and apache-perl packages together side by side. Very nice.

Nowadays, with Apache 2, mod_perl is only a DSO, AFAICT, and I needed to set up my own parallel set of dirs, as I mentioned earlier, but it worked fine.

Since I'm not compiling my own mod_perl2, switching the Apache 2 version isn't an issue, since the packages all get upgraded together.