NFS (Network File System) allows hosts to mount partitions on a remote system and use them as though they are local file systems. This allows the system administrator to store resources in a central location on the network, providing authorized users continuous access to them.
Two versions of NFS are currently in use. NFS version 2 (NFSv2), which has been around for several years, is widely supported by various operating systems. NFS version 3 (NFSv3) has several more features, including a variable file handle size and better error reporting. Red Hat Linux supports both NFSv2 and NFSv3, and uses NFSv3 by default when connecting with a server that supports it.
This chapter will focus on NFS version 2, though many of the concepts discussed also apply to version 3. Additionally, only fundamental NFS concepts and supplemental information will be provided. For specific instructions regarding the configuration and operation of NFS on client or server machines, see the chapter titled Network File System (NFS) in the Red Hat Linux Customization Guide.
9.1. Methodology
Linux uses a combination of kernel-level support and continuously running daemon processes to provide NFS file sharing, however, NFS support must be enabled in the Linux kernel in order to function. NFS uses Remote Procedure Calls (RPC) to route requests between clients and servers, meaning that the portmap service must be enabled and active at the proper runlevels for NFS communication to occur. Working with portmap, the following processes ensure that a given NFS connection is allowed and may proceed without error:
*
rpc.mountd — The running process that receives the mount request from an NFS client and checks to see if it matches with a currently exported file system.
*
rpc.nfsd — The process that implements the user-space components of the NFS service. It works with the Linux kernel to meet the dynamic demands of NFS clients, such as providing additional server threads for NFS clients to use.
*
rpc.lockd — A daemon that is not necessary with modern kernels. NFS file locking is now done by the kernel. It is included with the nfs-utils package for users of older kernels that do not include this functionality by default.
*
rpc.statd — Implements the Network Status Monitor (NSM) RPC protocol. This provides reboot notification when an NFS server is restarted without being gracefully brought down.
*
rpc.rquotad — An RPC server that provides user quota information for remote users.
Not all of these programs are required for NFS service. The only services that must be enabled are rpc.mountd, rpc.nfsd, and portmap. The other daemons provide additional functionality and should only be used if the server environment requires them.
NFS version 2 uses the User Datagram Protocol (UDP) to provide a stateless network connection between the client and server. NFS version 3 can use UDP or TCP running over an IP. The stateless UDP connection minimizes network traffic, as the NFS server sends the client a cookie after the client is authorized to access the shared volume. This cookie is a random value stored on the server's side and is passed along with RPC requests from the client. The NFS server can be restarted without affecting the clients and the cookie will remain intact.
NFS only performs authentication when a client system attempts to mount a remote file system. To limit access, the NFS server first employs TCP wrappers. TCP wrappers reads the /etc/hosts.allow and /etc/hosts.deny files to determine if a particular client should be permitted or prevented access to the NFS server. For more information on configuring access controls with TCP wrappers, see Chapter 15 TCP Wrappers and xinetd.
After the client is granted access by TCP wrappers, the NFS server refers to its configuration file, /etc/exports, to determine whether the client can mount any of the exported file systems. After granting access, any file and directory operations are sent to the server using remote procedure calls.
Warning Warning
NFS mount privileges are granted specifically to a client, not a user. Exported file systems can be a accessed by any users on the remote machine.
When configuring the /etc/exports file, be very careful when granting read-write permissions (rw) for an exported file system.
9.1.1. NFS and portmap
NFS relies upon remote procedure calls (RPC) to function. The portmap service is required to map RPC requests to the correct services. RPC processes notify portmap when they start, revealing the port number they are monitoring and the RPC program numbers they expect to serve. The client system then contacts portmap on the server with a particular RPC program number. portmap then redirects the client to the proper port number to communicate with its intended service.
Because RPC-based services rely on portmap to make all connections with incoming client requests, portmap must be available before any of these services start. If, for some reason, the portmap service unexpectedly quits, restart portmap and any services running when it was started.
The portmap service can be used with TCP wrappers' hosts access files (/etc/hosts.allow and /etc/hosts.deny) to control which remote systems are permitted to use RPC-based services on the server. See Chapter 15 TCP Wrappers and xinetd for more information. Access control rules for portmap will affect all RPC-based services. Alternatively, it is possible to specify each of the NFS RPC daemons to be affected by a particular access control rule. The man pages for rpc.mountd and rpc.statd contain information regarding the precise syntax for these rules.
9.1.1.1. Trouble shooting NFS with portmap
As portmap provides the coordination between RPC services and the port numbers used to communicate with them, it is useful to be able to view the status of current RPC services using portmap when troubleshooting. The rpcinfo command shows each RPC-based service with its port number, RPC program number, version, and IP protocol type (TCP or UDP).
To make sure the proper NFS RPC-based services are enabled for portmap, use the rpcinfo -p command:
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 1024 status
100024 1 tcp 1024 status
100011 1 udp 819 rquotad
100011 2 udp 819 rquotad
100005 1 udp 1027 mountd
100005 1 tcp 1106 mountd
100005 2 udp 1027 mountd
100005 2 tcp 1106 mountd
100005 3 udp 1027 mountd
100005 3 tcp 1106 mountd
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100021 1 udp 1028 nlockmgr
100021 3 udp 1028 nlockmgr
100021 4 udp 1028 nlockmgr
The -p option probes the portmapper on the specified host or defaults to localhost if no specific host is listed. Other options are available from the rpcinfo man page.
From this output, it is apparent that various NFS services are running. If one of the NFS services does not start up correctly, portmap will be unable to map RPC requests from clients for that service to the correct port. In many cases, restarting NFS as root (/sbin/service nfs restart) will cause those service to correctly register with portmap and begin working.
9.2. NFS Server Configuration Files
Configuring a system to share files and directories using NFS is a simple process. Every file system being exported to remote users via NFS, as well as the access rights relating to those file systems, is located in the /etc/exports file. This file is read by the exportfs command to give rpc.mountd and rpc.nfsd the information necessary to allow the remote mounting of a file system by an authorized host.
The exportfs command allows the root user to selectively export or unexport directories without restarting the NFS service. When exportfs is passed the proper options, the file systems to be exported are written to /var/lib/nfs/xtab. Since rpc.mountd refers to the xtab file when deciding access privileges to a file system, changes to the list of exported file systems take effect immediately.
Various options are available when using exportfs:
*
-r — Causes all directories listed in /etc/exports to be exported by constructing a new export list in /etc/lib/nfs/xtab. This option effectively refreshes the export list with any changes that have been made to /etc/exports.
*
-a — Causes all directories to be exported or unexported, depending on the other options passed to exportfs.
*
-o options — Allows the user to specify directories to be exported that are not listed in /etc/exports. These additional file system shares must be written in the same way they are specified in /etc/exports. This option is used to test an exported file system before adding it permanently to the list of file systems to be exported.
*
-i — Ignore /etc/exports; only options given from the command line are used to define exported file systems.
*
-u — Unexports directories from being mounted by remote users. The command exportfs -ua effectively suspends NFS file sharing while keeping the various NFS daemons up. To allow NFS sharing to continue, type exportfs -r.
*
-v — Verbose operation, where the file systems being exported or unexported are displayed in greater detail when the exportfs command is executed.
If no options are passed to the exportfs command, it displays a list of currently exported file systems.
Changes to /etc/exports can also be read by reloading the NFS service with the service nfs reload command. This keeps the NFS daemons running while re-exporting the /etc/exports file.
9.2.1. /etc/exports
The /etc/exports file controls which file systems are exported to remote hosts and specifies options. Blank lines are ignored, comments can be made by starting a line with the hash mark (#), and long lines can be wrapped with a backslash (\). Each exported file system should be on its own individual line. Lists of authorized hosts placed after an exported file system must be separated by space characters. Options for each of the hosts must be placed in parentheses directly after the host identifier, without any spaces separating the host and the first parenthesis.
In its simplest form, /etc/exports only needs to know the directory to be exported and the hosts permitted to use it:
/some/directory bob.example.com
/another/exported/directory 192.168.0.3
After re-exporting /etc/exports with the /sbin/service nfs reload command, the bob.example.com host will be able to mount /some/directory and 192.168.0.3 can mount /another/exported/directory. Because no options are specified in this example, several default NFS preferences take effect:
*
ro — Read-only. Hosts mounting this file system will not be able to change it. To allow hosts to make changes to the file system, the rw (read-write) option must be specified.
*
async — Allows the server to write data to the disk when it sees fit. While this is not important if the host is accessing data as read-only, if a host is making changes to a read-write file system and the server crashes, data could be lost. By specifying the sync option, all file writes must be committed to the disk before the write request by the client is actually completed. This may lower performance.
*
wdelay — Causes the NFS server to delay writing to the disk if it suspects another write request is imminent. This can improve performance by reducing the number of times the disk must be accessed by separate write commands, reducing write overhead. The no_wdelay option turns off this feature, but is only available when using the sync option.
*
root_squash — Strips root users connected remotely from having root privileges by assigning them the nobody userid. This effectively "squashes" the power of the remote root user to the lowest local user, preventing remote root users from acting as though they were the root user on the local system. Alternatively, the no_root_squash option turns off root squashing. To squash every remote user, including root, use the all_squash option. To specify the user and group IDs to use with remote users from a particular host, use the anonuid and anongid options, respectively. In this case, a special user account can be created for remote NFS users to share and specify (anonuid=
In order to override these defaults, you must specify an option that takes its place. For example, if you do not specify rw, then that export will only be shared read-only. Each default for every exported file system must be explicitly overridden. Additionally, other options are available where no default value is in place. These include the ability to disable sub-tree checking, allow access from insecure ports, and allow insecure file locks (necessary for certain early NFS client implementations). See the exports man page for details on these lesser used options.
When specifying hostnames, use the following methods:
*
single host — Where one particular host is specified with a fully qualified domain name, hostname, or IP address.
*
wildcards — Where a * or ? character is used to take into account a grouping of fully qualified domain names that match a particular string of letters. Wildcards are not to be used with IP addresses; however, they may accidently work if reverse DNS lookups fail.
However, be careful when using wildcards with fully qualified domain names, as they tend to be more exact than you would expect. For example, the use of *.example.com as wildcard will allow sales.example.com to access an exported file system, but not bob.sales.example.com. To match both possibilities, as well as sam.corp.example.com, you would have to provide *.example.com *.*.example.com.
*
IP networks — Allows the matching of hosts based on their IP addresses within a larger network. For example, 192.168.0.0/28 will allow the first 16 IP addresses, from 192.168.0.0 to 192.168.0.15, to access the exported file system but not 192.168.0.16 and higher.
*
netgroups — Permits an NIS netgroup name, written as @
Warning Warning
The format of the /etc/exports file is very precise, particularly in regards to use of the space character. Remember to always separate exported file systems from hosts and hosts from one another with a space character. However, there should be no other space characters in the file except on comment lines.
For example, the following two lines do not mean the same thing:
/home bob.example.com(rw)
/home bob.example.com (rw)
The first line allows only users from bob.example.com read-write access to the /home directory. The second line allows users from bob.example.com to mount the directory read-only (the default), but the rest of the world can mount it read-write.
9.3. NFS Client Configuration Files
Any NFS share made available by a server can be mounted using various methods. The share can be manually mounted, using the mount command. However, this requires that the root user type the mount command every time the system restarts. Two methods of configuring NFS shares to be mounted automatically at boot time include modifying the /etc/fstab or using the autofs service.
9.3.1. /etc/fstab
Placing a properly formatted line in the /etc/fstab file has the same effect as manually mounting the exported file system. The /etc/fstab file is read by the /etc/rc.d/init.d/netfs script at system startup and any NFS shares listed there will be mounted.
A sample /etc/fstab line to mount an NFS export looks like the following:
The
The is the path to the exported directory.
The specifies where on the local file system to mount the exported directory. This mount point must exist before /etc/fstab is read or the mount will fail.
The nfs option specifies the type of file system being mounted.
The
9.3.2. autofs
One drawback to using /etc/fstab is that, regardless of how infrequently a user may access the NFS mounted file system, the system must dedicate resources to keep that mount in place. This is not a problem with one or two mounts, but when the system is maintaining mounts to a dozen systems at one time, overall system performance can suffer. An alternative to /etc/fstab is to use the kernel-based automount utility, which will mount and unmount NFS file systems automatically, saving resources.
The autofs script, located in the /etc/rc.d/init.d/ directory, is used to control automount through the /etc/auto.master primary configuration file. While automount can be specified on the command line, it is more convenient to specify the mount points, hostname, exported directory, and options in a set of files rather than typing them all by hand. By running autofs as a service that starts and stops in designated runlevels, the mount configurations in the various files can be automatically implemented.
The autofs configuration files are arranged in a parent-child relationship. A main configuration file (/etc/auto.master) refers mount points on your system that are linked to a particular map type, which take the form of other configuration files, programs, NIS maps, and other less common mount methods. The auto.master file contains lines referring to each of these mount points, organized like this:
The
The
While autofs configuration files can be used for a variety of mounts to many types of devices and file systems, they are particularly useful in creating NFS mounts. For example, some organizations store a user's /home/ directory on a central server via an NFS share. Then, they configure the auto.master file on each of the workstations to point to an auto.home file containing the specifics for how to mount the /home/ directory via NFS. This allows the user to access personal data and configuration files in their /home/ directory by logging in anywhere on the internal network. The auto.master file in this situation would look similar to this:
/home /etc/auto.home
This sets up the /home/ mount point on the local system to be configured by the /etc/auto.home file, which may look similar to this:
* -fstype=nfs,soft,intr,rsize=8192,wsize=8192,nosuid server.example.com:/home
This line states that any directory a user tries to access under the local /home/ directory (due to the asterisk character) should result in an NFS mount on the server.example.com system within its exported /home/ file system. The mount options specify that each /home/ directory NFS mounts should use a particular collection of settings. For more information on mount options, including the ones used in this example, see Section 9.3.3 Common NFS Mount Options.
9.3.3. Common NFS Mount Options
Beyond mounting a file system via NFS on a remote host, a number of different options may be specified at the time of the mount that can make it easier to use. These options can be used with manual mount commands, /etc/fstab settings, and autofs, and other mounting methods.
The following options are the most popular for NFS mounts:
*
hard or soft — specifies whether the program using a file via an NFS connection should stop and wait (hard) for the server to come back online if the host serving the exported file system is unavailable, or if it should report an error (soft).
If hard is specified, the user cannot terminate the process waiting for the NFS communication to resume unless intr option is also specified.
If soft, is specified, the user can set an additional timeo=
*
intr — allows NFS requests to be interrupted if the server goes down or cannot be reached.
*
nolock — is occasionally required when connecting to older NFS server. To require locking, use the lock option.
*
noexec — does not permit the execution of binaries on the mounted file system. This is useful if the system is mounting a non-Linux file system via NFS that contains incompatible binaries.
*
nosuid — does not allow set-user-identifier or set-group-identifier bits to take effect.
*
rsize=8192 and wsize=8192 — may speed up NFS communication for reads (rsize) and writes (wsize) by setting a larger data block size, in bytes, to be transferred at one time. Be careful when changing these values; some older Linux kernels and network cards may not work well with larger block sizes.
*
nfsvers=2 or nfsvers=3 — specify which version of the NFS protocol to use.
Many more options are listed on the mount man page, including options for mounting non-NFS file systems.
9.4. Securing NFS
NFS works well for sharing entire file systems with a large number of known hosts in a largely transparent manner. Many users accessing files over an NFS mount may not be aware that the file system they are using is not local to their system. However, with ease of use comes a variety of potential security problems.
The following points should be considered when exporting NFS file systems on a server or mounting them on a client. Doing so will minimize NFS security risks and better protect data on the server.
9.4.1. Host Access
NFS controls who can mount an exported file system based on the host making the mount request, not the user that will actually use the file system. Hosts must be given explicit rights to mount the exported file system. Access control is not possible for users, other than file and directory permissions. In other words, once a file system is exported via NFS, any user on any remote host connected to the NFS server can access the shared data. To limit the potential risks, administrators can only allow read-only access or squashing users to a common user and groupid. But these solutions may prevent the NFS share from being used in the way it was originally intended.
Additionally, if an attacker gains control of the DNS server used by the system exporting the NFS file system, the system associated with a particular hostname or fully qualified domain name can be pointed to an unauthorized machine. At this point, the unauthorized machine is the system permitted to mount the NFS share, since no username or password information is exchanged to provide additional security for the NFS mount. The same risks hold true to compromised NIS servers, if NIS netgroups are used to allow certain hosts to mount an NFS share. By using IP addresses in /etc/exports, this kind of attack is more difficult.
Wildcards should be used sparingly when granting exporting NFS shares as the scope of the wildcard may encompass more systems than intended.
For more information on securing NFS, refer to the chapter titled Server Security in the Red Hat Linux Security Guide.
9.4.2. File Permissions
Once the NFS file system is mounted read-write by a remote host, the only protection each shared file has is its permissions. If two users that share the same userid value mount the same NFS file system, they will be able to modify each others files. Additionally, anyone logged in as root on the client system can use the su - command to become a user who could access particular files via the NFS share. For more on NFS and userid conflicts, refer to the chapter titled Managing Accounts and Groups in the Red Hat Linux System Administration Primer.
The default behavior when exporting a file system via NFS is to use root squashing. This sets the userid of anyone accessing the NFS share as the root user on their local machine to a value of the server's nobody account. Never turn off root squashing.
If exporting an NFS share read-only, consider using the all_squash option, which makes every user accessing the exported file system take the userid of the nobody user.
Chapter 10. Apache HTTP Server
The Apache HTTP Server is a robust, commercial-grade open source Web server developed by the Apache Software Foundation (http://www.apache.org). Red Hat Linux includes the Apache HTTP Server version 2.0 as well as a number of server modules designed to enhance its functionality.
The default configuration file installed with the Apache HTTP Server works without alteration for most situations. This chapter outlines many of the Apache HTTP Server configuration file (/etc/httpd/conf/httpd.conf) to aid those who require a custom configuration or need to convert a configuration file from the older Apache HTTP Server 1.3 format.
Warning Warning
If using the graphical HTTP Configuration Tool (redhat-config-httpd), do not hand edit the Apache HTTP Server's configuration file as the HTTP Configuration Tool regenerates this file whenever it is used.
For more information about the HTTP Configuration Tool, please refer to the chapter titled Apache HTTP Server Configuration in the Red Hat Linux Customization Guide.
10.1. Apache HTTP Server 2.0
There are important differences between the Apache HTTP Server version 2.0 and version 1.3 (version 1.3 shipped with Red Hat Linux 7.3 and earlier). This section reviews some of the features of Apache HTTP Server 2.0 and outlines important changes. For instructions on migrating a version 1.3 configuration file to the 2.0 format, refer to Section 10.2 Migrating Apache HTTP Server 1.3 Configuration Files.
10.1.1. Features of Apache HTTP Server 2.0
The arrival of Apache HTTP Server 2.0 brings with it a number of new features. Among them are the following:
*
New Apache API — Modules utilize a new, more powerful set of Application Programming Interfaces (APIs).
Important Important
Modules built for Apache HTTP Server 1.3 will not work without being ported to the new API. If unsure whether or not a particular module has been ported, consult the developer before upgrading.
*
Filtering — Modules can act as content filters. Refer to Section 10.2.4 Modules and Apache HTTP Server 2.0 for more on how filtering works.
*
IPv6 Support — The next generation IP addressing format is supported.
*
Simplified Directives — A number of confusing directives have been removed while others have been simplified. See Section 10.5 Configuration Directives in httpd.conf for more information about specific directives.
*
Multilingual Error Responses — When using Server Side Include (SSI) documents, customizable error response pages can be delivered in multiple languages.
*
Multiprotocol Support — Multiple protocols are supported.
A more complete list complete list of changes can be found online at http://httpd.apache.org/docs-2.0/.
10.1.2. Packaging Changes in Apache HTTP Server 2.0
Starting with Red Hat Linux 8.0, the Apache HTTP Server packages were renamed. Also, some related packages were renamed, deprecated, or incorporated into other packages.
Below is a list of the packaging changes:
*
The apache, apache-devel and apache-manual packages were renamed httpd, httpd-devel and httpd-manual respectively.
*
The mod_dav package were incorporated into the httpd package.
*
The mod_put and mod_roaming packages were removed, since their functionality is a subset of that provided by mod_dav.
*
The mod_auth_any and mod_bandwidth packages were removed.
*
The version number for the mod_ssl package is now synchronized with the httpd package. This means that the mod_ssl package for Apache HTTP Server 2.0 has a lower version number than mod_ssl package for Apache HTTP Server 1.3.
10.1.3. File System Changes in Apache HTTP Server 2.0
The following changes to the file system layout occur when upgrading to Apache HTTP Server 2.0:
*
A new configuration directory, /etc/httpd/conf.d/, has been added. — This new directory is used to store configuration files for individually packaged modules, such as mod_ssl, mod_perl, and php. The server is instructed to load configuration files from this location by the directive Include conf.d/*.conf within the Apache HTTP Server configuration file, /etc/httpd/conf/httpd.conf.
Important Important
It is vital that this line be inserted when migrating an existing configuration.
*
The ab and logresolve programs have been moved. — These utility programs have been moved from the /usr/sbin/ directory and into the /usr/bin/ directory. This causes scripts with absolute paths for these binaries to fail.
*
The dbmmanage command has been replaced. — The dbmmanage command has been replaced with htdbm. See Section 10.2.4.4 The mod_auth_dbm and mod_auth_db Modules for more information.
*
The logrotate configuration file has been renamed. — The logrotate configuration file has been renamed from /etc/logrotate.d/apache to /etc/logrotate.d/httpd.
The next section outlines how to migrate an Apache HTTP Server 1.3 configuration to the new 2.0 format.
10.2. Migrating Apache HTTP Server 1.3 Configuration Files
If upgrading from Red Hat Linux 7.3 or earlier upon which the Apache HTTP Server was already installed, then the new stock configuration file for the Apache HTTP Server 2.0 package is installed as /etc/httpd/conf/httpd.conf.rpmnew and the original version 1.3 httpd.conf is not touched. It is, of course, entirely up to you whether you use the new configuration file and migrate the old settings to it or use the existing file as a base and modify it to suit; however, some parts of the file have changed more than others and a mixed approach is generally the best. The stock configuration files for both version 1.3 and version 2.0 are divided into three sections. The goal of this guide is to suggest what is hopefully the easiest route.
If the /etc/httpd/conf/httpd.conf is a modified version of the default Red Hat Linux version and a saved a copy of the original is available, it may be easiest to invoke the diff command, as in the following example:
diff -u httpd.conf.orig httpd.conf | less
This command highlights any modifications made. If a copy of the original file is not available, extract it from an RPM package using the rpm2cpio and cpio commands, as in the following example:
rpm2cpio apache-
In the above command, replace
Finally, it is useful to know that the Apache HTTP Server has a testing mode to check for configuration errors. To use access it, type the following command:
apachectl configtest
10.2.1. Global Environment Configuration
The global environment section of the configuration file contains directives which affect the overall operation of the Apache HTTP Server, such as the number of concurrent requests it can handle and the locations of the various files. This section requires a large number of changes compared with the others and it is therefore recommended to base this section on the Apache HTTP Server 2.0 configuration file and migrate the old settings into it.
10.2.1.1. Selecting Which Interfaces and Ports To Bind To
The BindAddress and Port directives no longer exist; their functionality is now provided by a more flexible Listen directive.
If Port 80 was set in the 1.3 version configuration file, change it to Listen 80 in the 2.0 configuration file. If Port was set to some value other than 80, then append the port number to the contents of the ServerName directive.
For example, the following is a sample Apache HTTP Server 1.3 directive:
Port 123
ServerName www.example.com
To migrate this setting to Apache HTTP Server 2.0, use the following structure:
Listen 123
ServerName www.example.com:123
For more on this topic, refer to the following documentation on the Apache Software Foundation's website:
*
http://httpd.apache.org/docs-2.0/mod/mpm_common.html#listen
*
http://httpd.apache.org/docs-2.0/mod/core.html#servername
10.2.1.2. Server-pool Size Regulation
In Apache HTTP Server 2.0, the responsibility for accepting requests and dispatching child-processes to handle them has been abstracted into a group of modules called Multi-Processing Modules (MPMs). Unlike other modules, only one module from the MPM group can be loaded by the Apache HTTP Server. There are three MPM modules that ship with version 2.0: prefork, worker, and perchild.
The original Apache HTTP Server 1.3 behavior has been moved into the prefork MPM. Currently only the prefork MPM is available on Red Hat Linux, although the other MPMs may be made available at a later date.
The prefork MPM accepts the same directives as Apache HTTP Server 1.3, so the following directives may be migrated directly:
*
StartServers
*
MinSpareServers
*
MaxSpareServers
*
MaxClients
*
MaxRequestsPerChild
For more on this topic, refer to the following documentation on the Apache Software Foundation's website:
*
http://httpd.apache.org/docs-2.0/mpm.html
10.2.1.3. Dynamic Shared Object (DSO) Support
There are many changes required here, and it is highly recommended that anyone trying to modify an Apache HTTP Server 1.3 configuration to suit version 2.0 (as opposed to migrating the changes into the version 2.0 configuration) copy this section from the stock Red Hat Linux Apache HTTP Server 2.0 configuration file.
Those who do not want to copy the section from the stock Apache HTTP Server 2.0 configuration should note the following:
*
The AddModule and ClearModuleList directives no longer exist. These directives where used to ensure that modules could be enabled in the correct order. The Apache HTTP Server 2.0 API allows modules to specify their ordering, eliminating the need for these two directives.
*
The order of the LoadModule lines is no longer relevant.
*
Many modules have been added, removed, renamed, split up, or incorporated with each other.
*
LoadModule lines for modules packaged in their own RPMs (mod_ssl, php, mod_perl, and the like) are no longer necessary as they can be found in the relevant file in the /etc/httpd/conf.d/ directory.
*
The various HAVE_XXX definitions are no longer defined.
Important Important
If modifying the original file, please note that it is of paramount importance that the httpd.conf contains the following directive:
Include conf.d/*.conf
Omission of this directive will result in the failure of all modules packaged in their own RPMs (such as mod_perl, php, and mod_ssl).
10.2.1.4. Other Global Environment Changes
The following directives have been removed from Apache HTTP Server 2.0's configuration:
*
ServerType — The Apache HTTP Server can only be run as ServerType standalone making this directive irrelevant.
*
AccessConfig and ResourceConfig — These directives have been removed since they mirror the functionality of the Include directive. If the AccessConfig and ResourceConfig directives are set then replace them with Include directives.
To ensure that the files are read in the order implied by the older directives the Include directives should be placed at the end of httpd.conf, with the one corresponding to ResourceConfig preceding the one corresponding to AccessConfig. If using the default values, include them explicitly as conf/srm.conf and conf/access.conf files.
10.2.2. Main Server Configuration
The main server configuration section of the configuration file sets up the main server, which responds to any requests that are not handled by a
The directives used in this section have changed little between Apache HTTP Server 1.3 and version 2.0. If the main server configuration is heavily customized it may be easier to modify the existing configuration file to suit Apache HTTP Server 2.0. Users with only lightly customized main server sections should migrate their changes into the default 2.0 configuration.
10.2.2.1. UserDir Mapping
The UserDir directive is used to enable URLs such as http://example.com/~bob/ to map to a subdirectory within the home directory of the user bob, such as /home/bob/public_html. A side-effect of this feature allows a potential attacker to determine whether a given username is present on the system. For this reason, the default configuration for Apache HTTP Server 2.0 disables this directive.
To enable UserDir mapping, change the directive in httpd.conf from:
UserDir disable
to the following:
UserDir public_html
For more on this topic, refer to the following documentation on the Apache Software Foundation's website, http://httpd.apache.org/docs-2.0/mod/mod_userdir.html#userdir.
10.2.2.2. Logging
The following logging directives have been removed:
*
AgentLog
*
RefererLog
*
RefererIgnore
However, agent and referrer logs are still available using the CustomLog and LogFormat directives.
For more on this topic, refer to the following documentation on the Apache Software Foundation's website:
*
http://httpd.apache.org/docs-2.0/mod/mod_log_config.html#customlog
*
http://httpd.apache.org/docs-2.0/mod/mod_log_config.html#logformat
10.2.2.3. Directory Indexing
The deprecated FancyIndexing directive has now been removed. The same functionality is available through the FancyIndexing option within the IndexOptions directive.
The new VersionSort option to the IndexOptions directive causes files containing version numbers to be sorted in a more natural way. For example, httpd-2.0.6.tar appears before httpd-2.0.36.tar in a directory index page.
The defaults for the ReadmeName and HeaderName directives have changed from README and HEADER to README.html and HEADER.html.
For more on this topic, refer to the following documentation on the Apache Software Foundation's website:
*
http://httpd.apache.org/docs-2.0/mod/mod_autoindex.html#indexoptions
*
http://httpd.apache.org/docs-2.0/mod/mod_autoindex.html#readmename
*
http://httpd.apache.org/docs-2.0/mod/mod_autoindex.html#headername
10.2.2.4. Content Negotiation
The CacheNegotiatedDocs directive now takes the argument on or off. Existing instances of CacheNegotiatedDocs should be replaced with CacheNegotiatedDocs on.
For more on this topic, refer to the following documentation on the Apache Software Foundation's website:
*
http://httpd.apache.org/docs-2.0/mod/mod_negotiation.html#cachenegotiateddocs
10.2.2.5. Error Documents
To use a hard-coded message with the ErrorDocument directive, the message should be enclosed in a pair of double quotation marks ["], rather than just preceded by a double quotation mark as required in Apache HTTP Server 1.3.
To migrate an ErrorDocument setting to Apache HTTP Server 2.0, use the following structure:
ErrorDocument 404 "The document was not found"
Note the trailing double quote in the previous example ErrorDocument directive.
For more on this topic, refer to the following documentation on the Apache Software Foundation's website:
*
http://httpd.apache.org/docs-2.0/mod/core.html#errordocument
10.2.3. Virtual Hosts Configuration
The contents of all
Important Important
Note that SSL/TLS virtual host configuration has been moved out of the main server configuration file and into /etc/httpd/conf.d/ssl.conf.
For more on this topic, refer to the chapter titled Apache HTTP Secure Server Configuration in the Red Hat Linux Customization Guide and the documentation online at the following URL:
*
http://httpd.apache.org/docs-2.0/vhosts/
10.2.4. Modules and Apache HTTP Server 2.0
In Apache HTTP Server 2.0, the module system has been changed to allow modules to be chained together or combined in new and interesting ways. Common Gateway Interface (CGI) scripts, for example, can generate server-parsed HTML documents which can then be processed by mod_include. This opens up a tremendous number of possibilities with regards to how modules can be combined to achieve a specific goal.
The way this works is that each request is served by exactly one handler module followed by zero or more filter modules.
Under Apache HTTP Server 1.3, for example, a PHP script would be handled in its entirety by the PHP module. Under Apache HTTP Server 2.0, the request is initially handled by the core module — which serves static files — and is then filtered by the PHP module.
Exactly how to use this, and all the other new features of Apache HTTP Server 2.0 for that matter, is beyond the scope of this document; however, the change has ramifications if the PATH_INFO directive is used for a document which is handled by a module that is now implemented as a filter, as each contains trailing path information after the true file name. The core module, which initially handles the request, does not by default understand PATH_INFO and will return 404 Not Found errors for requests that contain such information. As an alternative, use the AcceptPathInfo directive to coerce the core module into accepting requests with PATH_INFO.
The following is an example of this directive:
AcceptPathInfo on
For more on this topic, refer to the following documentation on the Apache Software Foundation's website:
*
http://httpd.apache.org/docs-2.0/mod/core.html#acceptpathinfo
*
http://httpd.apache.org/docs-2.0/handler.html
*
http://httpd.apache.org/docs-2.0/filter.html
10.2.4.1. The mod_ssl Module
The configuration for mod_ssl has been moved from httpd.conf into the file /etc/httpd/conf.d/ssl.conf. For this file to be loaded, and hence for mod_ssl to work, the statement Include conf.d/*.conf must be in the httpd.conf as described in Section 10.2.1.3 Dynamic Shared Object (DSO) Support.
ServerName directives in SSL virtual hosts must explicitly specify the port number.
For example, the following is a sample Apache HTTP Server 1.3 directive:
# General setup for the virtual host
ServerName ssl.example.name
...
To migrate this setting to Apache HTTP Server 2.0, use the following structure:
# General setup for the virtual host
ServerName ssl.host.name:443
...
For more on this topic, refer to the following documentation on the Apache Software Foundation's website:
*
http://httpd.apache.org/docs-2.0/mod/mod_ssl.html
*
http://httpd.apache.org/docs-2.0/vhosts/
10.2.4.2. The mod_proxy Module
Proxy access control statements are now placed inside a
The caching functionality of the old mod_proxy has been split out into the following three modules:
*
mod_cache
*
mod_disk_cache
*
mod_file_cache
These generally use the same or similar directives as the older versions of the mod_proxy module.
For more on this topic, refer to the following documentation on the Apache Software Foundation's website:
*
http://httpd.apache.org/docs-2.0/mod/mod_proxy.html
10.2.4.3. The mod_include Module
The mod_include module is now implemented as a filter and is therefore enabled differently. Refer to Section 10.2.4 Modules and Apache HTTP Server 2.0 for more about filters.
For example, the following is a sample Apache HTTP Server 1.3 directive:
AddType text/html .shtml
AddHandler server-parsed .shtml
To migrate this setting to Apache HTTP Server 2.0, use the following structure:
AddType text/html .shtml
AddOutputFilter INCLUDES .shtml
Note that just as before, the Options +Includes directive is still required for the
For more on this topic, refer to the following documentation on the Apache Software Foundation's website:
*
http://httpd.apache.org/docs-2.0/mod/mod_include.html
10.2.4.4. The mod_auth_dbm and mod_auth_db Modules
Apache HTTP Server 1.3 supported two authentication modules, mod_auth_db and mod_auth_dbm, which used Berkeley Databases and DBM databases respectively. These modules have been combined into a single module named mod_auth_dbm in Apache HTTP Server 2.0, which can access several different database formats. To migrate from mod_auth_db, configuration files should be adjusted by replacing AuthDBUserFile and AuthDBGroupFile with the mod_auth_dbm equivalents: AuthDBMUserFile and AuthDBMGroupFile. Also, the directive AuthDBMType DB must be added to indicate the type of database file in use.
The following example shows a sample mod_auth_db configuration for Apache HTTP Server 1.3:
AuthType Basic
AuthName "My Private Files"
AuthDBUserFile /var/www/authdb
require valid-user
To migrate this setting to version 2.0 of Apache HTTP Server, use the following structure:
AuthType Basic
AuthName "My Private Files"
AuthDBMUserFile /var/www/authdb
AuthDBMType DB
require valid-user
Note that the AuthDBMUserFile directive can also be used in .htaccess files.
The dbmmanage Perl script, used to manipulate user name and password databases, has been replaced by htdbm in Apache HTTP Server 2.0. The htdbm program offers equivalent functionality and like mod_auth_dbm can operate a variety of database formats; the -T option can be used on the command line to specify the format to use.
Table 10-1 shows how to migrate from a DBM-format database to htdbm format using dbmmanage.
Action dbmmanage command (1.3) Equivalent htdbm command (2.0)
Add user to database (using given password) dbmmanage authdb add username password htdbm -b -TDB authdb username password
Add user to database (prompts for password) dbmmanage authdb adduser username htdbm -TDB authdb username
Remove user from database dbmmanage authdb delete username htdbm -x -TDB authdb username
List users in database dbmmanage authdb view htdbm -l -TDB authdb
Verify a password dbmmanage authdb check username htdbm -v -TDB authdb username
Table 10-1. Migrating from dbmmanage to htdbm
The -m and -s options work with both dbmmanage and htdbm, enabling the use of the MD5 or SHA1 algorithms for hashing passwords, respectively.
When creating a new database with htdbm, the -c option must be used.
For more on this topic, refer to the following documentation on the Apache Software Foundation's website:
*
http://httpd.apache.org/docs-2.0/mod/mod_auth_dbm.html
10.2.4.5. The mod_perl Module
The configuration for mod_perl has been moved from httpd.conf into the file /etc/httpd/conf.d/perl.conf. For this file to be loaded, and hence for mod_perlto work, the statement Include conf.d/*.conf must be included in the httpd.conf as described in Section 10.2.1.3 Dynamic Shared Object (DSO) Support.
Occurences of Apache:: in the httpd.conf must be replaced with ModPerl::. Additionally, the manner in which handlers are registered has been changed.
This is a sample Apache HTTP Server 1.3 mod_perl configuration:
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
This is the equivalent mod_perl for Apache HTTP Server 2.0:
SetHandler perl-script
PerlModule ModPerl::Registry
PerlHandler ModPerl::Registry::handler
Options +ExecCGI
Most modules for mod_perl 1.x should work without modification with mod_perl 2.x. XS modules require recompilation and may possibly require minor Makefile modifications.
10.2.4.6. The mod_python Module
The configuration for mod_python has been moved from httpd.conf into the file /etc/httpd/conf.d/python.conf. For this file to be loaded, and hence for mod_python to work, the statement Include conf.d/*.conf must be in the httpd.conf as described in Section 10.2.1.3 Dynamic Shared Object (DSO) Support.
10.2.4.7. PHP
The configuration for PHP has been moved from httpd.conf into the file /etc/httpd/conf.d/php.conf. For this file to be loaded, the statement Include conf.d/*.conf must be in the httpd.conf as described in Section 10.2.1.3 Dynamic Shared Object (DSO) Support.
The PHP is now implemented as a filter and must therefore be enabled in a different manor. See Section 10.2.4 Modules and Apache HTTP Server 2.0 for more about filters.
Under Apache HTTP Server 1.3, PHP was implemented using the following directives:
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps
Under Apache HTTP Server 2.0, use the following directives instead:
SetOutputFilter PHP
SetInputFilter PHP
In PHP 4.2.0 and later the default set of predefined variables which are available in the global scope has changed. Individual input and server variables are, by default, no longer placed directly into the global scope. This change may cause scripts to break. Revert to the old behavior by setting register_globals to On in the file /etc/php.ini.
For more on this topic, refer to the following URL for details concerning the global scope changes:
*
http://www.php.net/release_4_1_0.php
10.3. After Installation
After installing the httpd package, the Apache HTTP Server's documentation is available by installing the httpd-manual package and pointing a Web browser to http://localhost/manual/ or browse the Apache documentation available online at http://httpd.apache.org/docs-2.0/.
The Apache HTTP Server's documentation contains a full list and complete descriptions of all configuration options. For the convenience, this chapter provides short descriptions of the configuration directives used by Apache HTTP Server 2.0.
The version of the Apache HTTP Server included with Red Hat Linux includes the ability to set up secure Web servers using the strong SSL encryption provided by the mod_ssl and openssl packages. When looking through the configuration files, be aware that it includes both a non-secure and a secure Web server. The secure Web server runs as a virtual host, which is configured in the /etc/httpd/conf.d/ssl.conf file. For more information about virtual hosts, see Section 10.8 Virtual Hosts. For information on configuring a secure server virtual host, Section 10.8.1 Setting Up Virtual Hosts. For information on setting up an Apache HTTP Secure Server see the chapter titled Apache HTTP Secure Server Configuration in the Red Hat Linux Customization Guide.
Note Note
Red Hat, Inc. does not ship FrontPage extensions as the Microsoft™ license prohibits the inclusion of these extensions in a third party product. More information about FrontPage extensions and the Apache HTTP Server can be found online at the following URL: http://www.rtr.com/fpsupport/.
10.4. Starting and Stopping httpd
The httpd RPM installs the /etc/rc.d/init.d/httpd script, which can be accessed using the /sbin/service command.
To start the server, as root type:
/sbin/service httpd start
To stop the server, as root type:
/sbin/service httpd stop
The restart option is a shorthand way of stopping and then starting the Apache HTTP Server.
To restart the server, as root type:
/sbin/service httpd restart
Note Note
If running the Apache HTTP Server as a secure server, it is necessary to type the server password whenever using the start or restart options.
After editing the httpd.conf file, however, it is not necessary to explicitly stop and start the server. Instead, use the reload option.
To reload the server configuration file, as root type:
/sbin/service httpd reload
Note Note
If running the Apache HTTP Server as a secure server, the server password is not required when using the reload option.
By default, the httpd service will not start automatically at boot time. To configure the httpd service to start up at boot time using an initscript utility, such as /sbin/chkconfig, /sbin/ntsysv, or the Services Configuration Tool program. Refer to the chapter titled Controlling Access to Services in Red Hat Linux Customization Guide for more information regarding these tools.
Note Note
If running the Apache HTTP Server as a secure server, the secure server's password is required after the machine boots, unless a specific type of server key file is present.
For information about setting up an Apache HTTP Secure Server see the chapter titled Apache HTTP Secure Server Configuration in the Red Hat Linux Customization Guide.
10.5. Configuration Directives in httpd.conf
The Apache HTTP Server configuration file is /etc/httpd/conf/httpd.conf. The httpd.conf file is well-commented and mostly self-explanatory. Its default configuration works for most situations; however, it is a good idea to become familiar some of the more important configuration options.
Warning Warning
With the release of Apache HTTP Server 2.0, many configuration options have changed. If migrating a version 1.3 configuration file to the 2.0 format, refer to Section 10.2 Migrating Apache HTTP Server 1.3 Configuration Files.
10.5.1. General Configuration Tips
If configuring the Apache HTTP Server, edit /etc/httpd/conf/httpd.conf and then either reload, restart, or stop and start the httpd process as outlined in Section 10.4 Starting and Stopping httpd.
Before editing httpd.conf, first make a copy the original file. Creating a backup makes it easier to recover from mistakes made while editing the configuration file.
If a mistake is made and the Web server does not work correctly, first review recently edited passages in httpd.conf to verify there are no typos.
Next look in the Web server's error log, /var/log/httpd/error_log. The error log may not be easy to interpret, depending on the level of experience. If experiencing problems, however, the last entries in the error log should provide useful information about what happened.
Next are a list of short descriptions for many of the directives included in httpd.conf. These descriptions are not exhaustive. For more information, refer to the Apache documentation provided in HTML format at http://localhost/manual/ or online at the following URL: http://httpd.apache.org/docs-2.0/.
For more information about mod_ssl directives, refer to the documentation included in HTML format at http://localhost/mod/mod_ssl.html or online at the following URL: http://httpd.apache.org/docs-2.0/mod/mod_ssl.html.
10.5.2. ServerRoot
The ServerRoot is the top-level directory which contains the server's files. Both the secure server and the non-secure server set the ServerRoot directive is set to "/etc/httpd".
10.5.3. ScoreBoardFile
The ScoreBoardFile stores internal server process information, which is used for communication between the parent server process and its child processes. Red Hat Linux uses shared memory to store the ScoreBoardFile, the default of /etc/httpd/logs/apache_runtime_status is only used as a fall back.
10.5.4. PidFile
PidFile names the file where the server records its process ID (PID). By default the PID is set in /var/run/httpd.pid.
10.5.5. Timeout
Timeout defines, in seconds, the amount of time that the server will wait for receipts and transmissions during communications. Specifically, Timeout defines how long the server will wait to receive a GET request, how long it will wait to receive TCP packets on a POST or PUT request, and how long it will wait between ACKs responding to TCP packets. Timeout is set to 300 seconds by default, which is appropriate for most situations.
10.5.6. KeepAlive
KeepAlive sets whether the server will allow more than one request per connection and can be used to prevent any one client from consuming too much of the server's resources.
By default Keepalive is set to off. If Keepalive is set to on and the server becomes very busy, the server can quickly spawn the maximum number of child processes. In this situation, the server will slow down significantly. If Keepalive is enabled, it is a good idea to set the the KeepAliveTimeout low (refer to Section 10.5.8 KeepAliveTimeout for more information about the KeepAliveTimeout directive) and monitor the /var/log/httpd/error_log log file on the server. This log reports when the server is running out of child processes.
10.5.7. MaxKeepAliveRequests
This directive sets the maximum number of requests allowed per persistent connection. The Apache Project recommends a high setting, which improves the server's performance. MaxKeepAliveRequests is set to 100 by default, which should be appropriate for most situations.
10.5.8. KeepAliveTimeout
KeepAliveTimeout sets the number of seconds the server will wait after a request has been served before it closes the connection. Once the server receives a request, the Timeout directive applies instead. KeepAliveTimeout is set to 15 seconds by default.
10.5.9. MinSpareServers and MaxSpareServers
The Apache HTTP Server dynamically adapts to the perceived load by maintaining an appropriate number of spare server processes based on the traffic. The server checks the number of servers waiting for a request and kills some if there are more than MaxSpareServers or creates some if the number of servers is less than MinSpareServers.
The default MinSpareServers value is 5; the default MaxSpareServers value is 20. These default settings should be appropriate in most situations. Be careful not to increase the MinSpareServers to a large number as doing so will create a heavy processing load on the server even when traffic is light.
10.5.10. StartServers
StartServers sets how many server processes are created upon startup. Since the Web server dynamically kills and creates server processes based on traffic load, it is not necessary to change this parameter. The Web server is set to start eight server processes at startup.
10.5.11. MaxClients
MaxClients sets a limit on the total number of server processes, or simultaneously connected clients, that can run at one time. The main purpose of this directive is to keep a runaway Apache HTTP Server from crashing the operating system. For busy servers this value should be set to a high value. The server's default is set to 150. It is not recommended this the value for the MaxClients exceed 256.
10.5.12. MaxRequestsPerChild
MaxRequestsPerChild sets the total number of requests each child server process serves before the child dies. The main reason for setting MaxRequestsPerChild is to avoid long-lived process induced memory leaks. The default MaxRequestsPerChild for the server is 1000.
10.5.13. Listen
The Listen command identifies the ports on which the Web server will accept incoming requests. By default, the Apache HTTP Server is set to listen to port 80 for non-secure Web communications and (in the /etc/httpd/conf.d/ssl.conf which defines any secure servers) to port 443 for secure Web communications.
If the Apache HTTP Server is configured to listen to a port under 1024, the root user to start it. For port 1024 and above, httpd can be started as a regular user.
The Listen directive can also be used to specify particular IP addresses over which the server will accept connections.
10.5.14. Include
Include allows other configuration files to be included at runtime.
The path to these configuration files can be absolute or relative to the ServerRoot.
Important Important
For the server to use individually packaged modules, such as mod_ssl, mod_perl, and php, the following directive must be in Section 1: Global Environment of httpd.conf:
Include conf.d/*.conf
10.5.15. LoadModule
LoadModule is used to load in Dynamic Shared Object (DSO) modules. More information on the Apache HTTP Server's DSO support, including exactly how to use the LoadModule directive, can be found in Section 10.7 Adding Modules. Note, the load order of the modules is no longer important with Apache HTTP Server 2.0. See Section 10.2.1.3 Dynamic Shared Object (DSO) Support for more information about Apache HTTP Server 2.0 DSO support.
10.5.16. ExtendedStatus
The ExtendedStatus directive controls whether Apache generates basic (off) or detailed server status information (on), when the server-status handler is called. The Server-status handler is called using Location tags. More information on calling server-status is included in Section 10.5.63 Location.
10.5.17. IfDefine
The
The test in the
By default,
10.5.18. User
The User directive sets the user name of the server process and determines what files the server is allowed to access. Any files inaccessible to this user are also inaccessible to clients connecting to the Apache HTTP Server.
By default User is set to apache.
Note Note
For security reasons, the Apache HTTP Server will refuse to run as the root user.
10.5.19. Group
Specifies the group name of the Apache HTTP Server processes.
By default Group is set to apache.
10.5.20. ServerAdmin
Set the ServerAdmin directive to the email address of the Web server administrator. This email address will show up in error messages on server-generated Web pages, so users can report a problem by sending email to the server administrator.
By default, ServerAdmin is set to root@localhost.
A common way to set up ServerAdmin is to set it to webmaster@example.com. Then alias webmaster to the person responsible for the Web server in /etc/aliases and run /usr/bin/newaliases.
10.5.21. ServerName
Use ServerName to set a hostname and port number (matching the Listen directive) for the server. The ServerName does not need to match the machine's actual hostname. For example, the Web server may be www.example.com but the server's hostname is actually foo.example.com. The value specified in ServerName must be a valid Domain Name Service (DNS) name that can be resolved by the system — do not make something up.
The following is a sample ServerName directive:
ServerName www.example.com:80
When specifying a ServerName, be sure the IP address and server name pair are included in the /etc/hosts file.
10.5.22. UseCanonicalName
When set to on, this directive configures the Apache HTTP Server to references itself using the value specified in the ServerName and Port directives. When UseCanonicalName is set to off, the server will instead use the value used by the requesting client when referring to itself.
UseCanonicalName is set to off by default.
10.5.23. DocumentRoot
The DocumentRoot is the directory which contains most of the HTML files which is served in response to requests. The default DocumentRoot for both the non-secure and secure Web servers is the /var/www/html directory. For example, the server might receive a request for the following document:
http://example.com/foo.html
The server looks for the following file in the default directory:
/var/www/html/foo.html
To change the DocumentRoot so that it is not shared by the secure and the non-secure Web servers, see Section 10.8 Virtual Hosts.
10.5.24. Directory
By default, very restrictive parameters are applied to the root directory (/), using the Options (see Section 10.5.25 Options) and AllowOverride (see Section 10.5.26 AllowOverride) directives. Under this configuration, any directory on the system which needs more permissive settings has to be explicitly given those settings.
In the default configuration, another Directory container is configured for the DocumentRoot which assigns less rigid parameters to the directory tree so that the Apache HTTP Server can access the files residing there.
The Directory container can be also be used to configure additional cgi-bin directories for server-side applications outside of the directory specified in the ScriptAlias directive (refer to Section 10.5.44 ScriptAlias for more information about the ScriptAlias directive).
To accomplish this, the Directory container must set the ExecCGI option for that directory.
For example, if CGI scripts are located in /home/my_cgi_directory, add the following Directory container to the httpd.conf file:
Options +ExecCGI
Next, the AddHandler directive must be uncommented to identify files with the .cgi extension as CGI scripts. See Section 10.5.59 AddHandler for instructions on setting AddHandler.
For this to work, permissions for CGI scripts, and the entire path to the scripts, must be set to 0755.
10.5.25. Options
The Options directive controls which server features are available in a particular directory. For example, under the restrictive parameters specified for the root directory, Options is set to only FollowSymLinks. No features are enabled, except that the server is allowed to follow symbolic links in the root directory.
By default, in the DocumentRoot directory, Options is set to include Indexes and FollowSymLinks. Indexes permits the server to generate a directory listing for a directory if no DirectoryIndex (for example, index.html) is specified. FollowSymLinks allows the server to follow symbolic links in that directory.
Note Note
Options statements from the main server configuration section needs to be replicated to each VirtualHost containers individually. Refer to Section 10.5.69 VirtualHost for more information about VirtualHost containers.
10.5.26. AllowOverride
The AllowOverride directive sets whether or not any Options can be overridden by the declarations in an .htaccess file. By default, both the root directory and the DocumentRoot are set to allow no .htaccess overrides.
10.5.27. Order
The Order directive controls the order in which allow and deny directives are evaluated. The server is configured to evaluate the Allow directives before the Deny directives for the DocumentRoot directory.
10.5.28. Allow
Allow specifies which requester can access a given directory. The requester can be all, a domain name, an IP address, a partial IP address, a network/netmask pair, and so on. The DocumentRoot directory is configured to Allow requests from all, meaning everyone has access.
10.5.29. Deny
Deny works just like Allow, except it specifies who is denied access. The DocumentRoot is not configured to Deny requests from anyone by default.
10.5.30. UserDir
UserDir is the name of the subdirectory within each user's home directory where they should place personal HTML files which are served by the Web server. This directive is set to disable by default.
The name for the subdirectory is set to public_html in the default configuration. For example, the server might receive the following request:
http://example.com/~username/foo.html
The server would look for the file:
/home/username/public_html/foo.html
In the above example, /home/username/ is the user's home directory (note that the default path to users' home directories may vary).
Make sure that the permissions on the users' home directories are set correctly. Users' home directories must be set to 0711. The read (r) and execute (x) bits must be set on the users' public_html directories (0755 will also work). Files that will be served in users' public_html directories must be set to at least 0644.
10.5.31. DirectoryIndex
The DirectoryIndex is the default page served by the server when a user requests an index of a directory by specifying a forward slash (/) at the end of the directory name.
When a user requests the page http://example/this_directory/, they get either the DirectoryIndex page if it exists or a server-generated directory list. The default for DirectoryIndex is index.html and the index.html.var type map. The server tries to find any one of these files, and returns the first one it finds. If it does not find any of these files and Options Indexes is set for that directory, the server generates and returns a listing, in HTML format, of the subdirectories and files within the directory, unless the directory listing feature is turned off.
10.5.32. AccessFileName
AccessFileName names the file which the server should use for access control information in each directory. The default is .htaccess.
Immediately after the AccessFileName directive, a set of Files tags apply access control to any file beginning with a .ht. These directives deny Web access to any .htaccess files (or other files which begin with .ht) for security reasons.
10.5.33. CacheNegotiatedDocs
By default, the Web server asks proxy servers not to cache any documents which were negotiated on the basis of content (that is, they may change over time or because of the input from the requester). If CacheNegotiatedDocs is set to on, disables the function and allowing proxy servers to cache documents.
10.5.34. TypesConfig
TypesConfig names the file which sets the default list of MIME type mappings (file name extensions to content types). The default TypesConfig file is /etc/mime.types. Instead of editing /etc/mime.types, the recommended way to add MIME type mappings is to use the AddType directive.
For more information about AddType, refer to Section 10.5.58 AddType.
10.5.35. DefaultType
DefaultType sets a default content type for the Web server to use for documents whose MIME types cannot be determined. The default is text/plain.
10.5.36. IfModule
For more information about Apache HTTP Server modules, refer to Section 10.7 Adding Modules.
10.5.37. HostnameLookups
HostnameLookups can be set to on, off or double. If HostnameLookups set to on, the server automatically resolves the IP address for each connection. Resolving the IP address means that the server makes one or more connections to a DNS server, adding processing overhead. If HostnameLookups is set to double, the server performs a double-reverse DNS look up adding even more processing overhead.
To conserve resources on the server, HostnameLookups set to off by default.
If hostnames are required in server log files, consider running one of the many log analyzer tools that perform the DNS lookups more efficiently and in bulk when rotating the Web server log files.
10.5.38. ErrorLog
ErrorLog specifies the file where server errors are logged. By default, this directive is set to /var/log/httpd/error_log.
10.5.39. LogLevel
LogLevel sets how verbose the error messages in the error logs are. LogLevel can be set (from least verbose to most verbose) to emerg, alert, crit, error, warn, notice, info or debug. The default LogLevel is warn.
10.5.40. LogFormat
The LogFormat directive configures the format of the various Web server log files. The actual LogFormat used depends on the settings given in the CustomLog directive (see Section 10.5.41 CustomLog).
The following are the format options if the CustomLog directive is set to combined:
%h (remote host's IP address or hostname)
Lists the remote IP address of the requesting client. If HostnameLookups is set to on, the client hostname is recorded unless it is not available from DNS.
%l (rfc931)
Not used. A hyphen [-] appears in the log file for this field.
%u (authenticated user)
If authentication was required, lists the user name of the user is recorded. Usually, this is not used, so a hyphen [-] appears in the log file for this field.
%t (date)
Lists the date and time of the request.
%r (request string)
Lists the request string exactly as it came from the browser or client.
%s (status)
Lists the HTTP status code which was returned to the client host.
%b (bytes)
Lists the size of the document.
%\"%{Referer}i\" (referrer)
Lists the URL of the webpage which referred the client host to Web server.
%\"%{User-Agent}i\" (user-agent)
Lists the type of Web browser making the request.
10.5.41. CustomLog
CustomLog identifies the log file and the log file format. By default, the log is recorded to the /var/log/httpd/access_log file.
The default CustomLog format is combined. The following illustrates the combined log file format:
remotehost rfc931 user date "request" status bytes referrer user-agent
10.5.42. ServerSignature
The ServerSignature directive adds a line containing the Apache HTTP Server server version and the ServerName to any server-generated documents, such as error messages sent back to clients. ServerSignature is set to on by default.
It to also be set to off or to EMail. EMail, adds a mailto:ServerAdmin HTML tag to the signature line of auto-generated responses.
10.5.43. Alias
The Alias setting allows directories outside the DocumentRoot directory to be accessible. Any URL ending in the alias automatically resolves to the alias' path. By default, one alias for an icons directory is already set up. An icons directory can be accessed by the Web server, but the directory is not in the DocumentRoot.
10.5.44. ScriptAlias
The ScriptAlias directive defines where CGI scripts are located. Generally, it is not good practice to leave CGI scripts within the DocumentRoot, where they can potentially be viewed as text documents. For this reason, a special directory outside of the DocumentRoot directory containing server-side executables and scripts is designated by the ScriptAlias directive. This directory is known as a cgi-bin and set to /var/www/cgi-bin/ by default.
It is possible to establish directories for storing executables outside of the cgi-bin directory. For instructions on doing so, refer to Section 10.5.59 AddHandler and Section 10.5.24 Directory.
10.5.45. Redirect
When a webpage is moved, Redirect can be used to map the file location to a new URL. The format is as follows:
Redirect /
In this example, replace
In this example, any requests for
For more advanced redirection techniques, use the mod_rewrite module included with the Apache HTTP Server. For more information about configuring the mod_rewrite module, refer to the Apache Software Foundation documentation online at http://httpd.apache.org/docs-2.0/mod/mod_rewrite.html.
10.5.46. IndexOptions
IndexOptions controls the appearance of server generated directing listings, by adding icons, file descriptions, and so on. If Options Indexes is set (see Section 10.5.25 Options), the Web server generates a directory listing when the Web server receives an HTTP request for a directory without an index.
First, the Web server looks in the requested directory for a file matching the names listed in the DirectoryIndex directive (usually, index.html). If an index.html file is not found, Apache HTTP Server creates an HTML directory listing of the requested directory. The appearance of this directory listing is controlled, in part, by the IndexOptions directive.
The default configuration turns on FancyIndexing. This means that a user can re-sort a directory listing by clicking on column headers. Another click on the same header will switch from ascending to descending order. FancyIndexing also shows different icons for different files, based upon file extensions.
The AddDescription option, when used in conjunction with FancyIndexing, presents a short description for the file in server generated directory listings.
IndexOptions has a number of other parameters which can be set to control the appearance of server generated directories. Parameters include IconHeight and IconWidth, to make the server include HTML HEIGHT and WIDTH tags for the icons in server generated webpages; IconsAreLinks, for making the icons act as part of the HTML link anchor along with the filename and others.
10.5.47. AddIconByEncoding
This directive names icons which are displayed by files with MIME encoding in server generated directory listings. For example, by default, the Web server shows the compressed.gif icon next to MIME encoded x-compress and x-gzip files in server generated directory listings.
10.5.48. AddIconByType
This directive names icons which are displayed next to files with MIME types in server generated directory listings. For example, the server shows the icon text.gif next to files with a mime-type of text, in server generated directory listings.
10.5.49. AddIcon
AddIcon specifies which icon to show in server generated directory listings for files with certain extensions. For example, the Web server is set to show the icon binary.gif for files with .bin or .exe extensions.
10.5.50. DefaultIcon
DefaultIcon specifies the icon displayed in server generated directory listings for files which have no other icon specified. The unknown.gif image file is the default.
10.5.51. AddDescription
When using FancyIndexing as an IndexOptions parameter, the AddDescription directive can be used to display user-specified descriptions for certain files or file types in a server generated directory listings. The AddDescription directive supports listing specific files, wildcard expressions, or file extensions.
10.5.52. ReadmeName
ReadmeName names the file which, if it exists in the directory, is appended to the end of server generated directory listings. The Web server first tries to include the file as an HTML document and then try to include it as plain text. By default, ReadmeName is set to README.html.
10.5.53. HeaderName
HeaderName names the file which, if it exists in the directory, is prepended to the start of server generated directory listings. Like ReadmeName, the server tries to include it as an HTML document if possible or in plain text if not.
10.5.54. IndexIgnore
IndexIgnore lists file extensions, partial file names, wildcard expressions or full filenames. The Web server will not include any files which match any of those parameters in server generated directory listings.
10.5.55. AddEncoding
AddEncoding names filename extensions which should specify a particular encoding type. AddEncoding can also be used to instruct some browsers to uncompress certain files as they are downloaded.
10.5.56. AddLanguage
AddLanguage associates file name extensions with specific languages. This directive is useful for Apache HTTP Servers which serve content in multiple languages based on the client Web browser's language settings.
10.5.57. LanguagePriority
LanguagePriority sets precedence for different languages in case the client Web browser has no language preference set.
10.5.58. AddType
Use the AddType directive to define MIME type and file extension pairs. For example, using PHP4, use the AddType directive to make the Web server recognize with PHP file extensions (.php4, .php3 .phtml .php) as PHP MIME types. The following directive tells the Apache HTTP Server to recognize the .shtml file extension:
AddType text/html .shtml
AddHandler server-parsed .shtml
10.5.59. AddHandler
AddHandler maps file extensions to specific handlers. For example, the cgi-script handler can be matched with the extension .cgi to automatically treat a file ending with .cgi as a CGI script. The following is a sample AddHandler directive for the .cgi extension.
AddHandler cgi-script .cgi
This directive enables CGIs outside of the cgi-bin to function in any directory on the server which has the ExecCGI option within the directories container. Refer to Section 10.5.24 Directory for more information about setting the ExecCGI option for a directory.
In addition to CGI scripts, the AddHandler directive is used to process server-parsed HTML and image-map files.
10.5.60. Action
Action specifies a MIME content type and CGI script pair, so that whenever a file of that media type is requested, a particular CGI script is executed.
10.5.61. ErrorDocument
The ErrorDocument directive associates an HTTP response code with a message or a URL to be sent back to the client. By default, the Web server outputs a simple and usually cryptic error message when an error occurs. The ErrorDocument directive forces the Web server to instead output a customized message or redirects the client to a local or external URL.
Important Important
In order to be valid, the message must be enclosed in a pair of double quotes ["].
10.5.62. BrowserMatch
The BrowserMatch directive allows the server to define environment variables and take appropriate actions based on the User-Agent HTTP header field — which identifies the client's Web browser type. By default, the Web server uses BrowserMatch to deny connections to specific browsers with known problems and also to disable keepalives and HTTP header flushes for browsers that are known to have problems with those actions.
10.5.63. Location
The
For instance, to allow people connecting from within the server's domain to see status reports, use the following directives:
SetHandler server-status
Order deny,allow Deny from all
Allow from <.example.com>
Replace <.example.com> with the second-level domain name for the Web server.
To provide server configuration reports (including installed modules and configuration directives) to requests from inside the domain, use the following directives:
SetHandler server-info
Order deny,allow
Deny from all
Allow from <.example.com>
Again, replace <.example.com> with the second-level domain name for the Web server.
10.5.64. ProxyRequests
To configure the Apache HTTP Server to function as a proxy server, remove the hash marks from the beginning of the
10.5.65. Proxy
10.5.66. ProxyVia
The ProxyVia command controls whether or not an HTTP Via: header line is sent along with requests or replies which go through the Apache proxy server. The Via: header shows the hostname if ProxyVia is set to On, shows the hostname and the Apache HTTP Server version for Full, passes along any Via: lines unchanged for Off, and Via: lines are removed for Block.
10.5.67. Cache Directives
A number of commented cache directives are supplied by the default Apache HTTP Server configuration file. In most cases, uncommenting these lines by removing the hash mark [#] from the beginning of the line is sufficient. The following, however, is a list of some of the more important cache-related directives.
*
CacheRoot — Specifies the name of the directory containing cached files. The default CacheRoot is the /var/httpd/proxy/ directory.
*
CacheSize — Specifies how much space the cache can use in kilobytes. The default CacheSize is 5 KB.
*
CacheGcInterval — Specifies the number of hours which must pass before files in the cache are deleted. The default for CacheGcInterval is 4 hours.
*
CacheMaxExpire — Specifies how long HTML documents are retained (without a reload from the originating Web server) in the cache. The default is 24 hours.
*
CacheLastModifiedFactor — Specifies the creation of an expiry (expiration) date for a document which did not come from its originating server with its own expiry set. The default CacheLastModifiedFactor is set to 0.1, meaning that the expiry date for such documents equals one-tenth of the amount of time since the document was last modified.
*
CacheDefaultExpire — Specifies the expiry time in hours for a document that was received using a protocol that does not support expiry times. The default is set to 1 hour.
*
NoCache — Specifies a list of hosts whose content is not cached.
10.5.68. NameVirtualHost
The NameVirtualHost directive associates an IP address and port number, if necessary, for any name-based virtual hosts. Name-based virtual hosting allows one Apache HTTP Server to serve different domains without using multiple IP addresses.
Note Note
Name-based virtual hosts only work with non-secure HTTP connections. If using virtual hosts with a secure server, use IP address-based virtual hosts instead.
To enable name-based virtual hosting, uncomment the NameVirtualHost configuration directive and add the correct IP address. Then add more VirtualHost containers for each virtual host.
10.5.69. VirtualHost
A set of commented VirtualHost container is provided in httpd.conf, which illustrates the minimum set of configuration directives necessary for each virtual host. Refer to Section 10.8 Virtual Hosts for more information about virtual hosts.
Note Note
All SSL virtual host containers have been moved into the file /etc/httpd/conf.d/ssl.conf.
10.5.70. SSL Configuration Directives
The SSL directives in /etc/httpd/conf.d/ssl.conf file can be configured to enable secure Web communications using SSL and TLS.
10.5.70.1. SetEnvIf
SetEnvIf sets environment variables based on the headers of incoming secure connections. In the supplied /etc/httpd/conf.d/ssl.conf file, it is used to disable HTTP keepalive and to allow SSL to close the connection without a close notify alert from the client browser. This setting is necessary for certain browsers that do not reliably shut down the SSL connection.
For more information on SSL directives, direct a Web browser to either of the following addresses:
*
http://localhost/manual/mod/mod_ssl.html
*
http://httpd.apache.org/docs-2.0/mod/mod_ssl.html
For information about setting up an Apache HTTP Secure Server see the chapter titled Apache HTTP Secure Server Configuration in the Red Hat Linux Customization Guide.
Note Note
10.7. Adding Modules
The Apache HTTP Server supports Dynamically Shared Objects (DSOs) or modules, which can easily be loaded at runtime as necessary.
The Apache Project provides complete DSO Documentation at online http://httpd.apache.org/docs-2.0/dso.html. Or if the http-manual package is installed, documentation about DSOs can be found at http://localhost/manual/mod/.
For the Apache HTTP Server to use a DSO, it must be specified in a LoadModule directive within in /etc/httpd/conf/httpd.conf; if the module is provided by a separate package, the line must appear within the modules configuration file in the /etc/httpd/conf.d/ directory. Refer to Section 10.5.15 LoadModule for more about the LoadModule directive.
If adding or deleting modules from http.conf, Apache HTTP Server must be reloaded or restarted, as covered in Section 10.4 Starting and Stopping httpd.
If creating a new module, first install the httpd-devel package as it contains the include files, the header files, as well as the APache eXtenSion (/usr/sbin/apxs) application, which uses the include files and the header files to compile DSOs.
After writing a module, use /usr/sbin/apxs to compile the module sources outside the Apache source tree. For more information about using the /usr/sbin/apxs command, refer to the the Apache documentation online at http://httpd.apache.org/docs-2.0/dso.html and the apxs, man page.
Once compiled, put the module in the /usr/lib/httpd/ directory. Then add a LoadModule line to the httpd.conf, using the following structure:
LoadModule
In the above example, change
10.8. Virtual Hosts
The Apache HTTP Server's built in virtual hosting allows the server to serve different information based on which IP address, hostname, or port is being requested. A complete guide to using virtual hosts is available online at http://httpd.apache.org/docs-2.0/vhosts/.
10.8.1. Setting Up Virtual Hosts
To create a name-based virtual host, it is best use the virtual host container provided in httpd.conf as an example.
The virtual host example read as follows:
#NameVirtualHost *
#
#
# ServerAdmin webmaster@dummy-host.example.com
# DocumentRoot /www/docs/dummy-host.example.com
# ServerName dummy-host.example.com
# ErrorLog logs/dummy-host.example.com-error_log
# CustomLog logs/dummy-host.example.com-access_log common
#
To activate name-based virtual hosting, uncomment the NameVirtualHost line by removing the hash mark (#) and replace the asterisk (*) with the IP address assigned to the machine.
Next, configure a virtual host, by uncommenting and customizing the
On the
The
Tip Tip
If configuring a virtual host to listen on a non-default port, that port must be added to the Listen directive in the global settings section of the /etc/httpd/conf/http.conf file.
To activate a newly created virtual host the Apache HTTP Server must be reloaded or restarted. Refer to Section 10.4 Starting and Stopping httpd for instructions on doing this.
Comprehensive information about creating and configuring both name-based and IP address-based virtual hosts is provided online at http://httpd.apache.org/docs-2.0/vhosts/.
10.8.2. The Secure Web Server Virtual Host
By default, the Apache HTTP Server is configured as both a non-secure and a secure server. Both the non-secure and secure servers use the same IP address and host name, but listen on different ports: 80 and 443 respectively. This enables both non-secure and secure communications to take place simultaneously.
One aspect of SSL enhanced HTTP transmissions are that they are more resource intensive than the standard HTTP protocol, so a secure server cannot serve as many pages per second. For this reason it is often a good idea to minimize the information available from the secure server, especially on a high traffic Web site.
Important Important
Do not use name-based virtual hosts in conjunction with a secure Web server as the SSL handshake occurs before the HTTP request identifies the appropriate name-based virtual host. Name-based virtual hosts only work with the non-secure Web server.
The configuration directives for the secure server are contained within virtual host tags in the /etc/httpd/conf.d/ssl.conf file.
By default, both the secure and the non-secure Web servers share the same DocumentRoot. It is recommended that the DocumentRoot be different for the secure Web server.
To stop the non-secure Web server from accepting connection comment the line in httpd.conf which reads Listen 80 by placing a hash mark at the beginning of the line. When finished it will look like the following example:
#Listen 80
For more information on configuring an SSL enhanced Web server, refer to the chapter titled Apache HTTP Secure Server Configuration in the Red Hat Linux Customization Guide. For advanced configuration tips, refer to the Apache Software Foundation documentation available online at the following URLs:
*
http://httpd.apache.org/docs-2.0/ssl/.
*
http://httpd.apache.org/docs-2.0/vhosts/
No comments:
Post a Comment