CTS 2322 (Unix/Linux Administration II) Project
Web Services, Yum Setup


Due: by the start of class on the date shown on the syllabus


In this project you will configure a web service using both Apache and Nginx.  You will also configure the web server to enable your yum repository, created in an earlier project.


A web server accepts requests from clients (known as web browsers) for specific documents.  Usually these are text documents with HTML formatting, but may be any type of document.  In addition to serving up such documents, known as static content, a web server can generate documents dynamically, as the result of running separate (external) programs or performing database lookups.

The requests include a URL which uniquely identifies a document on the Internet.  A URL has several parts, including a protocol (such as http://, https://, ftp://, etc.), a web server (either an IP address or a DNS name, such as www.example.com, mail.example.com, etc.) and an optional port number (by default “:80”), a pathname, and optional other data.  A typical example might be http://www.example.com/some-document.html.

A URL can also point to a directory rather than a document, indicated by a trailing slash.  In this case it is up to the web server to determine what document to return to the client.  Some possibilities include a (nicely formatted) directory listing, an error message, or some default document.  For Apache the default document is called “index.html” (or some variation such as “index.htm” or “index.php”).  A default web page for the top directory of the web server is called the server's home page.  This is the page you get with a URL similar to “http://servername/”.)  By default Apache ships with a default “test” homepage.  You will need to change that.

The requests and responses are sent via TCP using HTTP.  A request packet may include form data that the user entered on some web page that allows user input (a form), and includes a submit button.

In many cases, the user needs both privacy (so no one can eavesdrop) and assurance that they are talking to your website and not some impostor.  Both of these goals are met if you use HTTPS connections.  (This will be done in a project for the Unix/Linux Security course.)

The most popular web server is Apache's httpd (commonly called just Apache).  Knowing how to configure and manage Apache is an important skill.  But there are other web servers used, such as Nginx (pronounced “Engine X”).  In this project, you will practice managing and configuring both web servers, for non-trivial (but still simple) web sites.

(There are whole courses and books to teach one how to manage and configure web servers such as Apache.  In this project, we just scratch the surface of what is possible.  Since managing web services is usually a major part of a system administrator's job, you are encouraged to explore the on-line docs and tutorials, as you have the time.)


You may work individually or in groups on this project.  Each student in a group must submit an identical copy of the assignment, which must include the names of all student in your group.  Unlike some previous projects, the steps will not include specific commands to run.  At this point, you are expected to be able to locate relevant commands and documentation using the skills you have learned.  (However, see the hints section, below.)

Perform the following tasks and answer the following questions

Part I — Apache Web Server Setup

  1. Install the Apache web server package (httpd).  Do not forget to record all changes made in your journal!
  2. Make sure you have configured your firewall to allow access to your web server from localhost, port TCP/80 (and possibly TCP/443 for HTTPS).  What changed (if any) did you need to make, and to which file(s)?
  3. Check if your web server uses TCP Wrappers.  How do you do that?  If so, what changes will you make to allow access to your webmail from localhost?
  4. Make a copy of any files you will change, for example httpd.conf as httpd.conf-original.  Make any changes needed to the Apache web server configuration.  While Apache will work “out of the box”, you may need to make some changes to turn on or off various features to suit your use.  For example there is no need to support fancy indexing, UserDirs, etc.  What changes did you make (if any), and to which files?  (You should use diff to record the changes made.)
  5. Now make some additional configuration changes to your web server.  (Remember, first make a copy of any files you will change, if you haven't done so already.)  Make the following changes to the Apache configuration:
    1. Set the server's name to “localhost”.
    2. For the directory /var/www/html, change the options from “FollowSymLinks” to “SymLinksifOwnerMatch”.
    3. Change the “DirectoryIndex” file (the file served if a URL is for a directory), from just index.html to the three files: index.html, index.htm, and index.php.
    4. Enable server status information, only from localhost, from the URLhttp://localhost/server-status”.  (Hint: see mod_status in the Apache documentation.)
    5. Enable the optional module “mod_speling”.  Then add the proper directive to httpd.conf to have the module only check the case of URLs.  (Doing this makes your server use case-insensitive URLs.)
  6. You can test your web server's new configuration using the server's “-t” option.  If any errors are reported, go back and change the incorrect statements.  Repeat until no errors are detected.  What changes did you make?  Show the changes of any files using the diff command.
  7. Start the web server.  Now examine the error log.  If any errors are reported you may need to change the configuration and then restart the server.  What log messages resulted from starting the web server?
  8. Try using the server by running any web browser with the URLhttp://your-server-name/”.  Use “localhost” for your server-name.  If you don't see a test page, examine the error and access logs to determine the problem(s).  Once working, make sure your web server will start automatically at boot time.  What changes did you make and/or commands did you issue, to have the web server start at boot time?
  9. Make sure your web service log files are properly rotated.  What log file(s) are used for your web server?  What changes (if any) did you make to ensure they are rotated regularly?
  10. Let's add some content to our web site.  Start with the site's home page, the file “index.html” placed in your site's document root.  Make sure the file is readable by everyone.  Use the following as a guide for this file (feel free to customize it, but make sure your page contains the two links):
    <!DOCTYPE html>
    <html lang="en">
        <meta charset="utf-8">
        <title>your-name website</title>
        <h1> Welcome to your-name's website!</h1>
        <p> <a href="foo/">view foo files</a> </p>
        <p> <a href="bar/">view bar files</a> </p>

    (Of course, change “your-name” to your actual name.)  Next, create two directories within your document root, named foo and bar.  Make sure these two directories have the correct permissions, so everyone can read and search them.

    Finally, put an index.html file into each directory, with the correct permissions.  The contents of these files can be anything you wish.  Here's a sample page you can use; just change “foo” to “bar” in the file you put into the bar subdirectory: 

    <!DOCTYPE html>
    <html lang="en">
        <meta charset="utf-8">
        <title>Foo Files</title>
        <h1> Foo Files</h1>

    Verify all your web pages can be viewed, and that the links work.

    What is the output of the command “ls -lR” when run from your document root?

  11. Lastly, we will password protect the files in the foo subdirectory.  To do so, you will need to create a file of authorized users and their passwords, then configure the web server to authenticate users when they attempt to view and files under the foo directory.
    1. Create the password file.  The web server doesn't use the system accounts (that is, it doesn't use the accounts found in /etc/passwd); you can make up any user name you want.  In this example, I use “hymie” for the username, and “foo-passwords” for the password file:
      htpasswd -cB foo-passwords hymie
    2. Put the file where the web server can find it, for example /var/www/foo-passwords.  Make sure the file has the correct permissions.
    3. To restrict access to the files under foo, add the following foo.conf file to your Apache configuration directory:
      <Location "/foo">
         AuthType Basic
         AuthName "Foo"
         AuthUserFile /var/www/foo-passwords
         Require valid-user

      This says that for URLs of /foo, use basic authentication (a user name and password).  The security realm is named Foo.  Finally, any valid user from the foo-passwords file is acceptable.

    4. Check the configuration of the web server after adding this file.  Fix any errors found.  Then restart the web server.

    Test your setup by starting a web browser and attempt to use the URL of http://localhost/, then click on the link for fooDescribe the result: did the foo file display immediately, or did you need to do something first (and if so, what)?

    Test your web server by visiting the following URLs, and describe the results you see:

    1. http://localhost/BAR/
    2. http://localhost/bar
    3. http://localhost/server-status/
    4. http://localhost/nosuchpage

Part II — Using Nginx to Serve a Yum Repository

In a previous project, you created a yum repository that was accessible with a “file:///URL.  If necessary, rebuild that repo now, including the myhello package.  For this part of the project, you will configure your web server to serve up this repo, using a “http://localhost/myrepo/URL (instead of the one used previously, “file:///var/myrepo”).

  1. If it is still installed, uninstall the “myhello” package.  Verify the command hello no longer is found.
  2. Edit the myrepo.repo file, and change the URL to the repo from “file:///var/myrepo” to “http://localhost/myrepo/”.  What is the output of diff from the previous version to the new version?  (You are encouraged, but not required, to use RCS or some other versioning control system such as git, and check in the original version, then check in the modified version.  You can then use “rcsdiff” or “git diff” to show the changes made.)
  3. Next you need to configure Nginx to recognize this URL.

    If currently running Apache, be sure to turn that off and turn on Nginx before proceeding.  (And do not forget to update your system journal.)  Note if you reboot, whichever web server is enabled will start; make sure you only start one!

  4. Create a new file named “myrepo.conf” in the Nginx configuration directory, /etc/nginx/default.d/.  This file needs one location block, to map the URL of http://localhost/myrepo/ to the directory containing your yum repository (should be /var/myrepo/ if you followed the directions in the Building and Installing Software project).  You can look up the Nginx location block (see the alias and root directives that go in that block) web server documentation.  What is the name, permissions, and content of your myrepo.conf file?
  5. While not required by yum, it is customary to place a web page at your repo's URL, so those who type it in will not get an error message.  Often this page will contain instructions for using the repo (or even a link for an RPM you can use to create the repo).  Create a web page named index.html in the root of your repo.  In the document root, replace the file “index.html” that you created earlier, with something that looks like this (for the name “myrepo”):
    <!DOCTYPE html>
    <html lang="en">
        <meta charset="utf-8">
        <title>myrepo - yum repo</title>
        <h1> myrepo &mdash; Private yum package repository for example.com </h1>
        <p> This repo is for ... legal notice goes here ... </p>
        <p> To enable myrepo on your machine, you need to ... </p>
        <p> You can download the myrepo package signing key from ... </p>

    You can take a look at other repo's web sites, such as rpmfusion.org, for inspiration.  You can also install the repoview package, which generates the HTML web pages needed (in a directory named repoview by default).  Making a link to that directory in your index.html page allows your visitors to browse the repo's packages. 

    What is the content of your web page?  What permissions does that file need?

  6. Test your web server configuration, by using the command line option “-t”.  What errors (if any) did this report?  You should fix any errors and try again until all errors are fixed.  Note what you did in your journal.  Make sure you have the permissions correct, so the web server (which does not run as root can search directories and read files.
  7. Once there are no web server errors, restart the web server to activate your new configuration.  Examine the web server error log file.  What is the pathname of the web server error log?  What messages resulted when you restarted the web server?  You should test the configuration by pointing your web browser to the repo's URL; you should see the web page you created earlier.  If not, trouble-shoot the problem, record the steps needed to fix the problem in your journal.
  8. Finally, you should install the myhello package from your repo.  What is the exact command you used?  Verify the command hello is now working.

(When done with this project, you should consider which web server you want to run automatically at boot time.  (If any.)  Whichever one you chose, you should add the configuration steps you did for the other one.  For example, If you decide to run Apache, you should configure it to serve up your yum repo.)


The Apache web server on-line documentation is an excellent resource, and well-organized.  You should consult it whenever you are working on configuring Apache.

The Nginx web server on-line documentation is also excellent.

URLs that point to directories are supposed to end in a slash.  A common problem is forgetting that slash.  With extra configuration, a web server can make the trailing slash optional, but that wasn't done in this project.

The messages in a daemon's error log can be very, very helpful when trying to figure out what is wrong.  Don't forget to look there if the server misbehaves!

Creating simple web pages is an easy skill to learn.  An excellent source of tutorials for all web-related technology is found at w3schools.com.  For this project, you are allow to ask your instructor for help in creating the required web page.

To be turned in:

A copy of your journal pages showing the changed made for this project, and the answers to the questions asked above.  You can send as email to (preferred).  If email is a problem for some reason, you may turn in a hard-copy.  In this case the pages should be readable, dated, and stapled together.  Your name should appear on the first page. 

Don't turn in your whole journal, you will need to add to it every day in class!  It is common in fact to keep the journal as a text file on the system (with a paper backup of course).

Please see your syllabus for more information about submitting projects.