In this section, youíll configure Apache to operate as a basic Web server, which will run under the name www.alpha-complex.com. First, you make some decisions about what you need the server to do and then set up the configuration file so Apache behaves the way you want. In subsequent chapters, youíll expand this configuration to handle secure connections, virtual domains, and more, but for now youíll concentrate on the minimum configuration that every Apache Web server needs to work.Decisions
Before you even begin to configure Apache, you have to make some decisions about the serverówhat name it will have, what network connections it will respond to, where the serverís configuration and log files will go, and where the Web site documents will reside. Each of these decisions is reflected in a configuration directive in Apacheís main configuration file.
The Server Name
This is the name that the server will use in HTTP responses, and itís usually of the form www.my-domain.com. A common misconception is that the server name is what Apache responds to. This isnít correctóApache will respond to any connection request on any network interface and port number to which itís configured to listen. By default, Apache 1.3 listens to all networks available to the host computer, and Apache 2 requires an explicit configuration. Either way, the server name is the name Apache uses in responses. As an example, the one youíll use for the server is this:
The IP Address and Port to Serve
This is the IP address on which Apache will receive HTTP requests. In fact, this isnít a required part of Apacheís configuration at all; rather, itís the hostís network configuration. You also want to make sure the host and any remote clients that contact it using the server name can associate it with the correct IP address. Youíll use the IP address 192.168.1.1 for the example server. This is a safe address thatís never relayed across the Internet (as discussed in Chapter 1), so you know youíll never accidentally conflict with another computer somewhere else. When you connect the server to an intranet or the Internet, youíll need to give it a proper IP address, but this will do for now.
You can force Apache to listen to explicit addresses using either the now deprecated BindAddress directive of Apache 1.3 or the Listen directive, which is valid for both Apache 1.3 and Apache 2. Accordingly, youíll use Listen here:
This tells Apache to listen to the IP address 192.168.1.1 on ports 80 and 443, which are the ports for HTTP and HTTPS (the secure version of HTTP), respectively. If instead you wanted to allow access from any IP address available to Apache, you can leave out the IP address and just specify a port number:
If you wanted to restrict access to clients running on the host itself with a view to opening it up to external access once youíre finished, you could instead specify this:
NOTE Iíll come back to Listen in Chapter 7 when I discuss virtual hosts.
Using standalone or inetd (Apache 1.3, Unix Only)
On Unix servers only, Apache 1.3 can run in two modes.
The first, and almost universal mode, is the standalone mode. In this mode, Apache handles its own network connections, listening for connections on the port or ports itís configured to serve. This is the default configuration for Apache and can be set explicitly with this:
The second is inetd mode, which applies to Unix systems only. In this mode, Apache is run through inetd when a connection request is received on a configured port and is set with this:
In this case, Apache pays no heed to any of its network configuration directives, and inetd is configured to start Apache. Because a new invocation of Apache is created for each individual connection, this is a very inefficient way to run the server.
Apache 2 drops support for inetd entirely and removes the ServerType directive, which is no longer legal. The best course of action is therefore to simply not specify it; any configurations that do should remove it.
User and Group (Unix Only)
On Unix systems, Apache can be configured to run under a specific user and group. When Apache is started by root (for example, at system start), it spawns one or more child processes to handle clients. If User and Group are set, the children give up their root status and adopt the configured identity instead (the perchild MPM of Apache 2 complicates this statement, but for the sake of simplicity, Iíll let it stand for now). This is a good thing because it makes the server a lot more secure and less vulnerable to attack. If you intend to run Apache as root, you should define these directives.
Most Unix systems define a special user and group nobody for running unprivileged processes, and for the time being, youíll use this for your configuration:
Many administrators prefer to give Apache its own private user and group, typically called web or httpd. The reason for this is that nobody is used by a lot of other programs because itís the generic unprivileged user. As a result, Apache might share its permissions with other programs. To avoid this, a dedicated user and group that only Apache will use is considered more secure. If these donít already exist, you can create them using (on most systems) the groupadd and useradd commands, for example:
This example should create a group called httpd with group ID 999 and then create a user in that group with user ID 999. You gave the user a login shell of /bin/false, so the account canít be used even if you set a password for it, and you include a comment so you know what this user ID is for. Obviously, you should pick a group and user ID that isnít already taken. You donít have to specify them at all, in which case they will be allocated for us, but using a known ID can be useful later when replicating an Apache setup on another server or restoring a previously saved backup.
Once you have the user and group set up, you can then configure Apache with this:
Windows doesnít support the concept of user ownership and privileges in the same way (and on older consumer versions such as 9 x and ME not at all), so these directives cannot work on those platforms. Specifying these directives will not cause an error on Windows, but they will not have any useful effect, either.
blog comments powered by Disqus