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

 

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

Description:

In this project you will configure web services using first Apache and then Nginx.  You will also configure the web server to serve your yum repository, created in an earlier project.

Background:

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.

Apache web server configuration depends on your operating system.  For Fedora, the current configuration is a main config file /etc/httpd/conf/httpd.conf and all other files ending with the .conf extension in the directory /etc/httpd/conf.d/.  On top of that, you can enable/disable various modules (plug-ins) by commenting or uncommenting lines in the files in the directory /etc/httpd/conf.modules.d/.

(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.)

Requirements:

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 always 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. Identify your firewall type.  Which (if any) firewall are is installed, and is it enabled?  How did you determine that?
  3. 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), or which commands did you use?
  4. Check if your web server was written to use TCP Wrappers.  How do you do that?  If so, what changes will you make to allow access to your web server from localhost?
  5. 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.)
  6. Now make some additional configuration changes to your web server.  (Remember to 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 web 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.)
  7. 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.  Also show the complete contents of any new files created.
  8. 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?
  9. 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?
  10. 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?
  11. 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 rootMake 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">
      <head>
        <meta charset="utf-8">
        <title>your-name website</title>
      </head>
      <body>
        <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>
      </body>
    </html>
    

    (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 directory: 

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

    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?

  12. 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
      </Location>
      

      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
  13. (Optional step)  Install and configure “awstats” package.  Be sure to record all your steps in your journal.

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 and its man page are no longer found.
  2. Edit the /etc/yum.repos.d/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 (stop it) 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!

    Next, install NginX.

  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 can go in that block; in our project we need the alias directive) web server documentation.  The location block you use should have a location of “/myrepo/” and the alias should refer to the directory of your repo.  What is the name, permissions, and content of your myrepo.conf file?
  5. While not required by dnf, 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), and possibly a link to browse or search the RPMs in 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">
      <head>
        <meta charset="utf-8">
        <title>myrepo - yum repo</title>
      </head>
      <body>
        <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>
      </body>
    </html>
    

    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?

    Web Servers and SELinux

    Normally, SELinux prevents web servers from accessing files that aren't labeled as web content files (“httpd_sys_content” or “httpd_user_content”).  Only files under a web server's document root are correctly labeled by default.  This means that no web server will be able to access any web content in /var/myrepo!  The error log will say permission denied for such attempts.

    While you should be able to fix that by relabeling your files or by updating the policy, for this project we will opt for the simpler method: Turn off SELinux.  To do so, as root run the command “setenforce 0”.  That will put SELinux into permissive mode until you either turn it back to enforcing mode or until you reboot.

  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, start the Nginx web server to activate your new configuration.  Examine that web server's error log file.  What is the pathname of the Nginx 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.  Make sure to enable only one web server to start at boot time.)

Hints:

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.  (It may not matter however, as many web browsers attempt to correct such URL errors for you.)

If you try to view a page in a web browser but see an error message with the number “403”, it means permission denied.  Check the permissions of the files and containing directories; files should be readable and directories searchable by everyone.  In addition, this error will be shown for SELinux violations.  Be sure to set SELinux in permissive mode.

If you try to view a page in a web browser but see an error message with the number “404”, it means file not found.  Check your URL for a typo!

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 allowed 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.  Use Canvas and submit to the project's drop-box. 

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.