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.
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.)
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
httpd
).
Do not forget to record all changes made in your journal!
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?
localhost
?
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.)
localhost
”. /var/www/html
, change the options
from “FollowSymLinks
”
to “SymLinksifOwnerMatch
”. 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
. localhost
,
from the URL
“http://localhost/server-status
”.
(Hint: see
mod_status in the Apache documentation.) 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.) -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.
http://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?
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"> <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?
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.
/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
/var/www/foo-passwords
.
Make sure the file has the correct permissions. 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.
Test your setup by starting a web browser and attempt to use the
URL of http://localhost/
, then click on the
link for foo
.
Describe 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:
http://localhost/BAR/
http://localhost/bar
http://localhost/server-status/
http://localhost/nosuchpage
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
”).
myhello
”
package.
Verify the command hello
and its man page are no longer found.
/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.)
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.
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?
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 — 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?
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.
-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.
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.)
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.
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.