Clean slate: Rather than modify the existing default configuration file, we are going to delete it and start from scratch. We will start by removing the existing configuration script. This may seem dramatic but this course seeks to explain every single line of the configuration file that will finally be written. After we delete the file we will note that the web server won't start.
Simplest configuration: The aim of this section is to give us enough configuration so that the server will at least start, even if it won't do anything useful.
One more line. We will add one more line to the most basic configuration file we can have to turn off many defaults so we can see them explicitly when we need them.
Deleting the configuration file is easy. Go on, you know you've always wanted to do it! What's the worst that could happen?
The web server will not start now. First it will complain about not having a configuration file. Perhaps we should have kept a backup...
# /etc/init.d/apache2 start /apache2/httpd.conf: No such file or directory The command line was: /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf failed
Next, we will create an empty configuration file and see that that just changes the error message.
# touch /etc/apache2/httpd.conf # /etc/init.d/apache2 start Starting httpd2 (prefork) no listening sockets available, shutting down Unable to open logs startproc: exit status of parent of /usr/sbin/httpd2-prefork: 1 failed
It must be admitted that as error messages go, "no listening sockets available, shutting down" is a fairly obscure way of saying "you've not told me what to do". Actually it means, "you've not told me to listen for any incoming requests so I might as well quit now".
We will start by detailing an absolutely minimal configuration file that gets the server launched but nothing else.
The command to tell the server to listen for connections is Listen. This takes one argument, specifying which interface and port to listen on. The default port assigned to web services by the Internet authorities is port 80. Quoting just a port number means to listen on that port number on every IP-enabled interface. Simply to launch the web server this should be all we need!
Unfortunately, the launched web server then immediately shuts down. By default, the web server logs error messages in an error long file. In SLES, as in many Linux distributions, this will be /var/log/apache2/error_log. We can look in there for clues as to what we need next.
[Wed Feb 21 15:54:58 2007] [alert] (2)No such file or directory: getpwuid: couldn't determine user name from uid 4294967295, you probably need to modify the User directive
What does this error message mean? It means that the web server needs to know who to run as. A standard SLES install comes pre-configured with a user wwwrun and a group www for the web server. We need to tell it to use them. This is done with the User and Group commands in the configuration file.
While we are at it, we add one "unnecessary" line which has the effect of turning off various settings which default to being on. We do this for two reasons. The first is didactic; we want to meet these options explicitly when they become relevant rather than relying on defaults. The second is our decision to provide what was specified and no more. This line will turn off everything and we must explicitly turn on what we want.
And if we start the web server now, with this four line configuration file, it launches just fine and stays running.
# /etc/init.d/apache2 start Starting httpd2 (prefork) done # tail -1 /var/log/apache2/error_log [Wed Feb 21 16:31:46 2007] [notice] Apache/2.2.3 (Linux/SUSE) configured -- resuming normal operations # ps -ef | grep apache2 root 6377 1 0 16:31 ? 00:00:00 /usr/sbin/httpd2-prefork ... wwwrun 6378 6377 0 16:31 ? 00:00:00 /usr/sbin/httpd2-prefork ... wwwrun 6379 6377 0 16:31 ? 00:00:00 /usr/sbin/httpd2-prefork ... wwwrun 6380 6377 0 16:31 ? 00:00:00 /usr/sbin/httpd2-prefork ... wwwrun 6381 6377 0 16:31 ? 00:00:00 /usr/sbin/httpd2-prefork ... wwwrun 6382 6377 0 16:31 ? 00:00:00 /usr/sbin/httpd2-prefork ... root 6392 3260 0 16:34 pts/0 00:00:00 grep apache2
But, as the figure shows, it's not a single daemon that gets launched. There are six of them. The first column of the ps output gives the owner of the process and the second gives the process ID or PID. One of the server processes is owned by user root and the others by user wwwrun. That root-owned process is the parent process of all the other processes. What happens is that the startup script that we manually invoked launched the parent, root-owned process (PID 6377). It in turn launched five child processes owned by wwwrun (PIDs 6378 - 6392).
Why? Well, the idea is that the parent process does not service any request at all. Its sole purpose is to keep an eye on the child processes. If one of them dies for any reason the parent decides whether or not to replace it. (If they have all been idle for the past 48 hours it may decide that four processes are plenty.) If they are all kept too busy the parent may choose to start up some more processes to share the load. The set of child processes is called the server pool and is the traditional mechanism that Apache has always used to provide rapid responses. This way of working is called the pre-forked model.
There are other models, or MPMs (Multi-Processing Modules) as the Apache documentation calls them, other than pre-forked but SLES has this enabled by default and it is what we will use throughout the course.
At the moment, the server has nothing to serve. Every attempt to request a page from it results in a 404, not found error. If we look in the error log file, /var/log/apache2/error_log we will see the error message:
[Wed Feb 21 16:39:34 2007] [error] [client 131.111.10.33] File does not exist: /srv/www/htdocs/index.html
which at least looks promising.
Syntax summary: Getting launched
This specifies the network interface the server should listen on. If only a port is specified then it will listen on every active network address. (Typically the system's own network address and the loopback address.)
This specifies the system user ID that the server process should run as. This user was created by the SLES system install.
This specifies the system group ID that the server process should run as. This group was created by the SLES system install.
This command sets various parameters in the configuration. We will meet these through the course as we turn them on.