Managing Apache

Why Apache rather than other webservers? There are lots of reasons, but I suppose, in the end, it has to do with working on the platform that w3c works on. The same reason that I prefer to use Firefox as my default browser. -- HilaryHolz - 23 May 2008

Designing an Apache install - Danger, Will Robinson!

The key to a happy and healthy Apache installation is a good design - that's a hard learned lesson. What's more, for pocket labs, that design will change steadily over time, as Apache continues to develop. What we throw out here is what works quite well for us, but we're very open to collaboration.

Folks, this is a really key area for us right now due to the current thrust towards virtual labs. Now, virtual labs are really useful, but our lab has learned from experience is that anyone working seriously in our areas of Digital Arts and Sciences is going to run into trouble quite quickly trying to use virtual labs for our work. Our work is simply too close to the OS for VMWare to support. Given that we're not an OS research group, that's rather revealing. The Digital Arts and Sciences folks need to work as a community to collaborate with IT and university administration to help them sort out what sorts of uses virtual labs are good for and what sorts of uses they aren't - not fight the whole trend, or work in isolation, duplicating effort and wasting time that could be put towards our research and teaching

Some major recommendations:

• install Apache from source (not yum, and not an rpm, not even a source rpm)
  • you can use apxs (usually in /usr/sbin/apxs, run 'which apxs' to find it) once you've installed apache to install related systems from tarballs with real ease, so this first installation is, in a sense, what drives the rest of the process
• only install Apache 2, not Apache 1 unless you have an absolutely mission critical reason to do so.
  • if you absolutely must have Apache 1 on a system, install only Apache 1 on that system and do everything you can to convert asap.
  • Apache 2 is very deeply embedded in how the larger computing community thinks about programming itself. As a result it takes more and more work to keep it viable on a system. It isn't intentional, it just is.
• keep that Apache installation up to date. I realize that it's harder to do when doing the install by hand, but that's what mailing lists are for.
• don't use threading. threading is a super idea, and it's great that the developer community is working away at it, and we're all looking forward to the day it works, but it's a snake pit. What's more, you'll need to keep your eyes out yourself to be sure you are aware of all the places threading pokes its nasty head up, because so much focus in the Apache 2 world is on threading. Select 'prefork' packages whenever there's an option.
• use mod_security, get a stable configuration, then make sure you have a lot of time to sort out the upgrade in rule set each time you upgrade the rule set. mod_sec is a wonder, but each rule_set upgrade is a lot of work to get stable, even if you are pretty fluent in apache and perl and pcre.
• make sure you get both the httpd package and the libapreq2 packages and install them. You can use apxs to install libapreq2.
• if you are going to be using mod_perl, then you use mod_perl to configure and install apache, and use apxs to install everything else.

Step by step (although look at the mod_perl info if going that route):

1. If you have apache installed from a rpm, remove that version first. Version 1 is listed as apache, you would use 'rpm -qa | grep apache' to check for it. Version 2 is listed as httpd, you would use, well, you get the idea, ...
2. You get apache2 and libapreq2 source from the Apache HTTP Server Project. Unpack the most recent stable source release into a directory in /usr/src.
3. It's still best to install apache 2 according to the fedora default layout. We ended up creating a new entry in config.layout which we called Fedora (duh). (FedoraHttpLayout) We did this before we understood much about the automake, etc., system, so no doubt could do a better job now...
4. in a production environment, the current recommendation is against using threads, so you also need to turn those off. So the final configuration command to use the Fedora layout, no threads, and our default module set is

   ./configure --enable-layout=Fedora --with-mpm=prefork --enable-mods-shared="all ssl cache proxy authn_alias mem_cache file_cache disk_cache"

5. Don't forget to add httpd* to the excludes list in YumDotConf (see PackageManagers)

Follow the default configuration files given in the linked TWiki pages, documenting as noted above any needed changes. Make sure that you come update the default config files when new releases of packages necessitate updating our default config. We may not have the time (or the need) to update all the machines all the time, but it's very important to keep these guidelines up to date!

Once you have stabilized your configuration, add the server to the services system so that it will be restarted at boot time. To do so, you'll need administrator privileges, but here are the steps (for Fedora, it varies a bit from distribution to distribution):

1. customize this HttpdService script as necessary, then copy it to /etc/init.d. Make sure you make the script executable!
2. add your new service. If you named your file httpd, you would use 'chkconfig --add httpd'
3. test your file, by running 'sudo service httpd start' (or whatever you decided to call your server) and then visiting the server in a browser
4. once it works, set it to start automatically: 'chkconfig httpd on'

back to top

Configuring Apache

Config file are generally in /etc/httpd/conf and /etc/httpd/conf.d, however some 3rd party modules have additional configuration files (e.g., modsecurity has a whole set it adds to /etc/modsecurity.d)

Our design is agile, i.e., the only configuration information that should go in the main configuration file, /etc/httpd/conf/httpd.conf, is that which applies to the base configuration of apache. Configuration information for dynamically loaded modules ('dso's) should go in separate configuration files in /etc/httpd/conf.d. The main configuration file automatically loads all the rest of the configuration files. Make sure that all configuration information needed for a particular module or application is self-contained in a config file in /etc/httpd/conf.d so that only that config file need be changed if/when the module changes.

• HttpdConf - the main server config file. This is a composite, with extra info to help you configure a server. It won't work alone - it works with the related files also listed here! In general, there's a lot of stuff turned off that you are probably used to seeing turned on. Leave it off - Apache is the dominant server and thus the high profile target. You'd be amazed at the resources lost simply repelling attacks. (Remember? Denial of Service attacks?) To sort out exactly what modules you need for your particular server:
  1. customize the template, adding the various configuration information you need
  2. try to start the server, it will die
  3. check the error log for directives that Apache could not find
  4. look those directives up in the Directive Quick Reference. The linked documentation will tell you which module a directive belongs to. Turn on the module.
  5. consider reading up a bit about the module in question. You will only truly understand what a module does when you need its functionality, so now is the time to read about what it does, and the Server Project pages are the primary sources.
• conf.d / ModInfoConf - config file for mod_info
• conf.d / ModStatusConf - config file for mod_status
• conf.d / ModSecurityConf - config file for mod_security, and modsecurity.d / ModSecurityLocalrulesConf - all local changes (except those in ModSecurityConf) go in this file
• conf.d / TWikiConf - config file for TWiki installation
• conf.d / SubversionConf - config file for subversion repository (acc only)
• conf.d / MailmanConf - config file for mailman (mailing list server, acc only)

back to top

PHP

No PHP. Ever. Turn it off. Making and keeping php secure takes more resources than we have. You must get explicit permission from Hilary to turn it on, even for a microsecond, and it will be really tough to talk her into it, as she has better things to do with her time than deal with the resulting continual barrage of attacks.

back to top

mod_ssl

Comes as part of the source install, although you do have to enable it explicitly. We use openssl as our ssl package. (Get info about how to get certificates signed...)

back to top

mod_security

Install and use mod_security (keep up to date). Mod_security is a third-party module (not part of the apache project, so you get it from the modsecurity homepage. You'll need to sign up for an account at the breach security network to actually download the source.

installing mod_security on fedora

• Documentation for mod_security is generally pretty good.
• Note that the fedora yum rpms are generally a release behind on the libxml2 rpms, and you usually do need the latest release, so check the link to xmlsoft.
• There's no need to stop your apache install when you unpack the mod_security archive (at least on linux, who knows what goes on with windows...)
• in the apache2 directory, run ./configure, make, and make install
• check your ruleset against our sample configuration files in ConfiguringApache

back to top

mod_evasive

Jonathan Zdziarski's mod_evasive module is also a fundamental protection module to install on your Apache server. Download it from his site and follow the ridiculously clear and easy directions in the README file Thanks, fella!

back to top

mod_perl

You'll also be best off installing mod_perl from source (and it is easier than trying to use a package install of mod_perl.) The source comes from the mod_perl homepage If you use the configure command listed above, you can configure mod_perl using 'perl Makefile.PL MP_APXS=/usr/sbin/apxs' and then follow the standard install process. If, for some reason, you decide you need more complex configuration options, you should store those options in an options file and add the argument MP_OPTIONS_FILE to the configure step. The first time one of us finds a need to do this, think through a good name and location for a file and come back here and document it.

back to top

gdbm

As of April 1st, 2008, the rpm install of gdbm had a bug that affected mod_perl, so you'll need to install gdbm from source. You can download it from any GNU mirror, you want version 1.8.3 (which dates from 2002!)

back to top . . .

[see also ServerAdminGuidelines]