Troubleshooting an Apache Installation

30 minutes
  • 2 Learning Objectives

About this Hands-on Lab

Understanding a service well enough to troubleshoot it is an important skill as a System Administrator. In this lab, we’ll go over troubleshooting an Apache installation.

Learning Objectives

Successfully complete this lab by achieving the following learning objectives:

Ensure Apache starts correctly.

The first thing to check is why Apache isn’t starting in the first place.


systemctl start httpd

It returns:

Failed to start httpd.service: Unit not found.

It looks like the junior admin didn’t think to install Apache. Let’s install it:

yum install httpd -y
systemctl start httpd

It returns:

Job for httpd.service failed because the control process exited with error code. See "systemctl status httpd.service" and "journalctl -xe" for details.

Looking at systemctl status httpd -l, we see errors like:

Apr 20 16:20:10 server1 httpd[1451]: (98)Address already in use: AH00072: make_sock: could not bind to address [::]:80

So something is already running on port 80.
Running ss -lp shows us that nginx is running and listening on port 80 and port 443. We need to stop nginx and start httpd:

systemctl stop nginx
systemctl start httpd

Finally, Apache is running.

Ensure files are being served correctly.

If everything is configured properly, simply running curl localhost should get our webpage.

It doesn’t, unfortunately. Now we need to configure Apache to use the different DocumentRoot we’re using here. We need to edit /etc/httpd/conf/httpd.conf and replace all instances of /var/www/html and /var/www/ with /opt/website/.
We also need to make sure SSL is enabled.
First, we need to install the mod_ssl package:

yum install mod_ssl -y

Fortunately, there’s a sample configuration file in the /root directory. Copy that to /etc/httpd/conf.d/, and we should be good to go after restarting Apache:

systemctl restart httpd
curl https://localhost -k

(The -k is used to ignore alerts due to a self-signed certificate)

The result doesn’t look like our index.html (you can cat /opt/website/index.html to verify).

Looking at /var/log/httpd/error_log, it looks like a permission issue. Using just ls -l /opt/website, everything looks fine – but maybe it’s SELinux. Check with:

# ls -lZ /opt/website/
-rw-r--r--. root root system_u:object_r:admin_home_t:s0 index.html
drwxr-xr-x. root root system_u:object_r:admin_home_t:s0 storage

That’s it. admin_home_t is for admin home files (like root‘s home directory) Compare that to the default /var/www directory:

# ls -lZ /var/www
drwxr-xr-x. root root system_u:object_r:httpd_sys_script_exec_t:s0 cgi-bin
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 html

So all we need to do is:

chcon -R system_u:object_r:httpd_sys_content_t:s0 /opt/website/*

And our curl should work fine. Good job!

Additional Resources

A junior coworker has come to you with a problem. He was given some files from the development team and told to set them up using Apache to serve them out. Unfortunately, after putting the files in place, he was unable to get Apache to start.

Your task is to start Apache and verify that /opt/website/index.html and /opt/website/storage/pinehead.jpg are served correctly over HTTP and HTTPS. The SSL cert is stored on the server at /etc/ssl/certs/SSLcert, and an SSL configuration file is available in root's home directory.

What are Hands-on Labs

Hands-on Labs are real environments created by industry experts to help you learn. These environments help you gain knowledge and experience, practice without compromising your system, test without risk, destroy without fear, and let you learn from your mistakes. Hands-on Labs: practice your skills before delivering in the real world.

Sign In
Welcome Back!

Psst…this one if you’ve been moved to ACG!

Get Started
Who’s going to be learning?