Installing the apache web server on an Ubuntu 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.
Checking iptables
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 -LYou’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 ACCEPTApache Install
Installing a basic apache web server is straightforward:
sudo aptitude update
sudo aptitude install apache2That should install apache along with a couple other packages to support some commonly-used options (like SSL support).
ServerName
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 ServerNameThe 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.confPut the following line into that file:
ServerName demoChange “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.
Graceful restart
Now that you’ve explicitly told apache what your server name should be, let’s gracefully restart Apache:
sudo /usr/sbin/apache2ctl gracefulYou shouldn’t see the warning this time. If you do, you may want to double-check your change to the servername.conf file.
Using apache2ctl
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.
Graceful
graceful|graceful-stopThe “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.
Configtest
configtestThe “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.
Status
status|fullstatusThe 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 articleon the subject after you have your basic apache installation in place.
Apache logs
By default, the apache logs are stored in the directory:
/var/log/apache2/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:
http://123.45.67.890You 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:
/usr/sbin/apache2ctl startIf 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.
Summary
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.
