Installing the apache web server on a Debian server is as simple using the "aptitude" package manager.
The workhorse of the Internet
Ah, the apache web server. Used to host more web sites than any other web server out there, apache's popularity stems from its flexibility and stable performance. It also doesn't hurt that there's a lot of documentation for it that's just a web search away.
In this article series we'll cover how to install apache and how to dive into its configuration to tailor the web server to your needs. We'll also throw in some instructions for installing PHP, given its widespread use on web servers these days.
Note that we'll usually refer to the apache web server as just "apache", even though technically apache puts out other projects too. Honestly, we do it for the same reason most of the Internet does it: It's easier to just say "apache".
We start at the beginning.
The first step is really a precautionary one before installing the web server. We'll want to make sure that once the web server is running, browsers will actually be able to reach it.
You may be running a firewall on your server, and it might be blocking traffic to the standard web server ports, port 80 (for regular connections) and port 443 (for secure connections). We'll talk about how to check iptables, since it's the firewall method used most often (and because it's what we use in our server setup articles), but the same general principle will apply to any other firewall solution.
Check the current firewall rules, to start off:
sudo /sbin/iptables -L
You'll want to look those rules over to make sure ports 80 and 443 are open for business. If it turns out you don't have a firewall running no changes are necessary. If you're using the default rules from our slice setup articles, you should already find ports 80 and 443 are open. Otherwise you'll want to apply rules to open those ports.
Rules like these should suffice for even the strictest iptables configuration:
-I INPUT -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT -I OUTPUT -p tcp --sport 80 -m state --state ESTABLISHED -j ACCEPT -I INPUT -p tcp --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT -I OUTPUT -p tcp --sport 443 -m state --state ESTABLISHED -j ACCEPT
Installing a basic apache web server is straightforward:
sudo aptitude update sudo aptitude install apache2
That should install apache along with a couple other packages to support some commonly-used options (like SSL support).
Towards the end of the install, when it starts the apache process, you might see this warning:
apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1 for ServerName
The warning comes from "apache2" because that's the name of the apache process when it's running (and thus what you'd look for in a ps list or top).
We'll take a closer look at apache configuration later in this article series, but for now let's attend to that complaint.
Create a config file to store your server name:
sudo nano /etc/apache2/conf.d/servername.conf
Put the following line into that file:
Change "demo" to the name of your slice or another handy identifier. Don't use the domain names of any of your sites for this value. We'll want to use those when we set up virtual hosts later in this series.
Once you're done, save servername.conf.
Now that you've explicitly told apache what your server name should be, let's gracefully restart Apache:
sudo /usr/sbin/apache2ctl graceful
You shouldn't see the warning this time. If you do, you may want to double-check your change to the servername.conf file.
We used "apache2ctl" to restart apache just now. That command can be used to start or stop apache in a manner similar to using the init script (/etc/init.d/apache2). If you just run apache2ctl by itself you get a list of the arguments you can send it:
$ /usr/sbin/apache2ctl Usage: /usr/sbin/apache2ctl start|stop|restart|graceful|graceful-stop|configtest|status|fullstatus /usr/sbin/apache2ctl <apache2 args>
The start, stop, and restart commands are pretty self-explanatory, and often they're all you will need. But let's take a moment to briefly explain the other arguments.
The "graceful" argument to apache2ctl asks apache to restart, but to do it in a way that won't interfere with existing connections. The "graceful-stop" argument is similar to "stop", but apache will let existing connections finish their business before cutting them off. The common thread there is that while the core of the web server is restarted or stopped, processes are left in place to continue handling old connections using the old configuration.
So on paper, "graceful" looks pretty good. When it works, you can restart the web server without actually cutting any users off or interrupting their sessions. In practice, graceful doesn't always execute perfectly. Some modules don't work well with graceful restarts, and sometimes you can end up with several hung connections that won't go away. There are also some configuration changes that only take effect after a full restart.
If you want to use "graceful" to restart apache after most configuration changes, just be aware of the possibility that it won't always work like you'd want it to. Make a test connection to the web server immediately after a graceful restart to make sure it accepts new connections using the new configuration. If graceful restarts don't consistently work, you may be better off just using a regular "restart" command instead (it may not be graceful, but it's more reliable).
Should you run the apache init script with the "reload" argument, behind the scenes it runs "apache2ctl graceful" to handle the configuration reload.
The "configtest" argument to apache2ctl doesn't interfere with a running web server. It simply asks apache to skim its configuration files to check for syntax errors. It's good to use this one after any change.
The configtest won't guarantee that a configuration change will actually work, mind you, but it does let you catch the more obvious configuration problems like a missing bracket or misspelled keyword.
The status command can present you with a snapshot of what the web server is doing at a given moment, but it usually takes some preparation to get it to work. Since the output is a bit more complex than just whether or not the web server is running, you may not want to go to the effort.
To get a response from the status or fullstatus commands, you would need to enable mod_status on the web server, configure it, and have a text-based web browser like "lynx" or "links" installed on your slice. If you just try to run "apache2ctl status", apache will let you know what needs to be done.
For details on how to enable apache's mod_status module and read the output, check this article on the subject after you have your basic apache installation in place.
By default, the apache logs are stored in the directory:
You will need to use sudo to look around in that directory since it's restricted to root access. The two main log files you'll find in there are "access.log" and "error.log".
The "access.log" will store all access attempts apache receives. This can be useful for traffic analysis, but it's also handy for troubleshooting if you need to figure out if a connection attempt got through to the web server (or if it's been blocked by something like iptables).
The "error.log" stores the errors apache reports. This can include both errors reported by the binary or by modules (like PHP complaining about not finding an SQL library) and errors the web server has sent to users (like a "file not found" error).
Test the server
If you navigate to your server's IP address in a web browser:
You should see a default page telling you apache is working. Hooray for working!
If not then, well, it doesn't work. If you didn't see the "It works!" page and your browser took a minute to tell you it couldn't get to it (like a "Server unavailable" error), then iptables may be blocking access to port 80.
If your browser gives you an error response right away, like a "connection refused" error, then apache may not be running. Try starting it up to be sure:
If that doesn't work, and you didn't get a useful explanation from apache2ctl, check the error log in apache's log directory. Common problems include a mistake in the /etc/apache/apache2.conf file, or another web server already running and keeping apache from attaching itself to port 80.
You should now have a functioning, but very basic, apache installation running on your server. There's more work to be done to properly configure apache and get your site on there, but you've completed the first step.
The next article in this series describes how to install PHP. If you don't want to install PHP for your web server, you can skip that step and go straight to the article discussing the apache configuration layout.
- -- Jered