Administrator’s E-Mail Address - ApacheLearn the basic steps necessary to download, install, and configure a basic Apache server. This article is from chapter two of Pro Apache by Peter Wainwright. (Apress, 2004, ISBN: 1590593006).
print this article SEARCH DEV SHED |
Usually when running a Web site, you’ll want an e-mail contact address so that people can report problems to you. In fact, Apache uses the administrator’s e-mail address in its default error messages when problems are encountered. The e-mail address is set with the ServerAdmin directive and can be any valid e-mail address; it isn’t restricted to the same domain name as the Web server, for example:
However, for this site, you’ll use the same domain as the Web site:
Note that you don’t specify the hostname www in the e-mail address—remember, www.alpha-complex.com refers to the machine running Apache, not necessarily the machine running your mail server. Even if both are on the same machine, you may decide to separate them later, so it’s best to use a generic address from the start. Having said this, it’s true that a mail exchanger can be set up in the DNS to direct e-mail to the www address to a different server, if that’s what you want to do. Server Root The server root is where Apache keeps all its essential files and is the default root for Apache’s other directives to append to if they’re defined with a relative path—see the following error log and document root sections for two good examples. You’ll stick with the default for now:
Default Error Log Apache can support many different kinds of logs, of which the most common are an access log (also called a transfer log), referrer log, and error log. You might not want to bother with access and referrer logs because they take up space and processing time, but you certainly want an error log. Apache sets the error log name with the ErrorLog directive, which defaults to logs/error_log under Unix and logs/error.log for Windows and OS/2. The name of the error log is either an explicit pathname starting with / or a name relative to the server root. To put the error log explicitly in the default place under the server root, you could specify this:
However, more simply, and with the same effect, you can use this:
Because you’ll probably want a transfer log (also called an access log) at some point, you can take care of it at the same time and worry about customizing it to your own requirements later:
If you want to allow for virtual hosts, you might also place per-host versions of these files in a directory related to the domain name of the Web site, alongside a document root, which is the last location you need to set. Document Root Last, but not least, you need to decide where the actual Web pages will reside. This can be any valid directory accessible to the server, even on another computer over NT File System (NFS) or Server Message Block (SMB), though this would be very inefficient unless you’re using a dedicated NFS system such as a NetApp filer (see http://www.netapp.com/products/filer/). As Chapter 8 discusses, there are additional considerations if the document root isn’t local, so you’ll assume it is for now. By default, Apache looks for a directory called htdocs under the server root. If you want to change it, you can specify either a relative path, which Apache will look for under the server root, or an absolute path, which can be outside it. It’s quite usual for the document root to be moved somewhere else to distance the publicly accessible Web site or Web sites from any sensitive Apache configuration files. This also makes upgrading or replacing the Apache installation simpler. So to specify the default document root, either of the following will do:
For your server, you’re going to place your Web site in its own directory inside a directory called www well outside the server root in /home:
This naming scheme will serve you well if you decide to host multiple Web sites, as you can then add more directories under /home/www. As suggested previously, you can also use this directory to store log files, CGI scripts, and other files related to the Web site that don’t go into the document root itself, as these alternative log directives illustrate: Introducing the Master Configuration File Now that you’ve decided on your basic configuration choices, you need to make the necessary changes to Apache’s configuration. Originally, Apache came with three configuration files:
Since Apache 1.3.4 was released, only httpd.conf is now necessary, and the other two have been merged into it. Apache 2 removes support for them entirely, so you’ll make all your changes in httpd.conf. Taking all the decisions you’ve made, you arrive at the basic configuration for your example server, and the httpd.conf file now will look like this:
The lines prefixed with a hash are commented out—they’re the defaults anyway, so they’re here only to remind you of what they are. Windows Apache doesn’t understand the User and Group directives, but it’s smart enough to just ignore them rather stopping with an error. As it happens, all these directives are documented in httpd.conf, even in a three-file configuration, so setting these directives (uncommenting the ones you want to change if they’re commented) is a one-step operation—you simply need to uncomment if they’re commented. Once httpd.conf has been changed and saved back to the disk, you’re ready to go. NOTE I’m listing only the configuration directives you’re actually changing because the Apache configuration file is long and contains a great deal of information. You want to keep all of it for the moment, so you’ll see only the things you need to for now. Other Basic Configuration DirectivesAlthough not usually part of a basic Apache installation, Apache does support a few other directives that control the location of certain files created by Apache during its execution. Because most of them are both somewhat technical and rarely need to be changed from the default setting, I mention them here for completeness. However, if you’re going to use them at all, this is the time and place to do it. Note that all of these directives are specific to Unix. The PidFile directive determines the name and location of the file in which Apache stores the process ID of the parent Apache process. This is the process ID that can be sent signals to stop or restart the server, for example, to send a termination signal:
TERM is the default signal for the kill command, so you don’t need to state it explicitly. Use kill -l to see a list of the available signal names, though Apache would recognize TERM, HUP, and USR1 only. I’ll discuss the subject of starting and stopping Apache in more detail in a moment. The default value of PidFile is logs/httpd.pid, which places the file in the logs directory under the server root. Like all Apache’s Location directives, an absolute pathname can also be used to specify a location outside of the server root. For example, Apache packages often move the PidFile to /var/run with this:
The LockFile directive determines the name and location of the file that Apache uses for synchronizing the allocation of new network requests. In Apache 1.3, this is a compile-time setting. In Apache 2, the AcceptMutex directive determines how Apache handles synchronization, and the lock file is used only if it’s set to the values fcntl or flock. For platforms that don’t support any kind of in-memory lock, this directive can be used to move the lock file from the default of logs/accept.lock. This is necessary if the logs directory is on another server and is mounted via NFS or SMB because the lock file must be on a local file system. You’ll also need to do this if you want to run more than one Apache server, for example:
NOTE See Chapter 8 for a full discussion of Apache’s locking mechanism and how the different lock types affect performance. The ScoreBoardFile directive determines the location of a file required on some platforms for the parent Apache process to communicate with child processes. Like the access lock, Apache will usually create the scoreboard in memory (technically, a shared memory segment), but not all platforms can support this. To find out if a given Apache binary needs a scoreboard file, simply run Apache and see if the file named by the ScoreBoardFile directive appears. The default value is logs/apache_status, which places the file in the logs directory under the server root. Administrators concerned about speed might want to move the scoreboard to a Random Access Memory (RAM) disk, which will improve Apache’s performance, for example:
This assumes that a RAM disk is present and mounted on /mnt/ramdisk, of course. Keep in mind that if you want to run more than one Apache server, the servers need to use different scoreboard files. A more ideal solution would be to migrate to a platform that allows Apache to store the scoreboard in memory in the first place. In modern versions of Apache (1.3.28 onward), the server creates the in-memory scoreboard owned by the user and group ID of the parent Apache process, which is more secure. In the rare case that the old behavior of creating the scoreboard with the user and group defined by the User and Group directives (which is technically wrong) specify the directive ScmemUIDisUser on; the default is off. In other words, unless you know you need to use this directive, you almost certainly don’t. The CoreDumpDirectory directive determines where Apache will attempt to dump core in the—I hope rare—event of a crash. By default, Apache uses the server root, but because under normal circumstances Apache should be running as a user that doesn’t have the privilege to write to the server root, no file will be created. To get a core file for debugging purposes, the CoreDumpDirectory can be used to stipulate a different, writable directory, for example:
Note that this is genuinely useful because Apache comes with source code, so debugging is actually possible. Building Apache from source makes this much more useful because the debugger will have something to get its teeth into. It’s important to note, however, that leaving this option set in a production server can lead to certain security risks associated with Denial of Service attacks if a flaw is found in the Apache server that can remotely crash the Apache server. This option should be left off in production environments.
blog comments powered by Disqus |
|
|
|
|
|
|
|
/ 19 
