CSE 265: System and Network Administration

Lab #6

Today we start looking at networking, and in particular focus on DNS, the domain name system that maps hostnames to network IP addresses. We will also configure Apache to handle multiple domains, and install a simple Perl script to support Web chat.

  1. Become familiar with dig.

    Use dig to retrieve SOA information for ibm.com. Notice how subsequent requests show different TTLs. Why? Compare it to the TTLs (in the answer+authority sections) for cse.lehigh.edu.

  2. Configure and run named/bind, the domain name server.

    Bind is likely not installed (type rpm -q bind to see what version is installed; if not installed, install bind and bind-chroot). Use the CentOS/RHEL tool to configure which services are running. Menu item System->Administration->Services is how to start it (or system-config-services from the shell). This tool manages the set of /etc/rc.d/ scripts for you for the current run-level. Make named start at boot, start it now and save changes.

    OK, now named should be running. Use dig to get SOA records for cse.lehigh.edu, specifying localhost as the resolver. This request goes through the server you just started, and you can tell even now that the server is a caching server. (How?)

    Now we will add our own domain as an authoritative zone that this nameserver will manage for us. You should make up any (non-existent) domain name you like (e.g., lehighrules.edu) and then a few hostnames to go within that domain (e.g., www.lehighrules.edu). You'll be creating a zone file that maps those hostnames to IP addresses. You might want to reference a sample domain zone file, supplied as part of an online book about DNS.

    For increased system security, we are running named within a chroot environment. (Make sure to click through on the link on the person who was an early user of the term "jail" for chroot and note where he went to school!) All files for named are found within the /var/named/chroot/ directory. The zone files for named are thus located in /var/named/chroot/var/named/. You should see a number of files there, including one for forward lookups of localhost (named.localhost), one for all root servers (named.ca), etc. We need to add another one for the forward lookups of our new domain.

    Using the named.localhost as an example, create a new file, perhaps called mynet.zone. Edit that file. When complete, your revised file should have (at least) three entries -- two A records, one pointing to your current IP address, and one pointing to 127.0.0.1; the third entry should be a CNAME for www.lehigh.edu. Remember that whenever you make a change to a zone file, you need to increase the serial number -- which is 0 in the default named.localhost file.

    However, there is more to be done before you can test it. You'll need to edit /etc/named.conf to include entries for your new file(s). In addition, in order for the changes to be used by the name server, you'll need to make it re-read the files. I suggest restarting it using the named script in init.d (as you would restart any other service).

    Once you have made all the changes (and updated the serial numbers), restart named and then use dig (or nslookup or host) to verify that you can resolve the new names correctly using your nameserver. If named has a problem with the files you have created, where do you think it'll send warnings and errors? In order for applications on your machine to automatically start using the nameserver, though, you'll need to change /etc/resolv.conf -- put the IP address for localhost as the first nameserver (the system will only use the first, as long as it is a working nameserver).

    You should now be able to use a web browser (you might need to restart it) and visit the hostname you created that points to www.lehigh.edu. To really see everything in action, use wireshark on the lo interface to see the requests that your applications use, and the responses generated by your local nameserver, and the external interface to see the requests made by your nameserver to the rest of the world.

  3. WWW basics.

    • A URL consists of a number of (sometimes optional) parts. For example, http://www.apache.org:80/foundation/faq.html contains the protocol (http), the host (www.apache.org), the port (80), and a path (/foundation/faq.html). If the port is not specified, 80 is assumed. If a path is not specified, the root path (/) is assumed (actually the browser will generate the root path if needed).

      Other protocols are permitted in a URL, such as https (secure HTTP access), ftp (access a file on an FTP server), and others. Not all are recognized by all browsers, but they are still considered valid to the URL specification.

    • A web server is a program that waits for requests that instruct it to serve or generate files. It typically listens on port 80, but can run on other ports as well (which is why a URL can include the port number). A web server accepts requests and sends reponses using HTTP (HyperText Transfer Protocol). Here is a sample request:
        GET /somedir/page.html HTTP/1.1
        Host: www.someschool.edu
        User-agent: Mozilla/4.0
        Connection: close
      And a sample response:
        HTTP/1.1 200 OK
        Date: Thu, 06 Aug 1998 12:00:15 GMT
        Server: Apache/1.3.0 (Unix)
        Last-Modified: Mon, 22 Jun 1998 ...
        Content-Length: 6821
        Content-Type: text/html
      Actually, the above are only considered the headers of the request and response, as they may also carry a body which is the payload. For the response, it would contain the 6821 bytes of the file being served. In a request, the body would contain the contents of a form submission, or a file upload, etc.

      A request of this kind is made for every separate object on a page (often, including the body of the page, every image and advertisement, sometimes for JavaScript, sometimes for CSS, and for AJAX activites).

      You can see all the activity by running wireshark while visiting a web page like Google Maps.

    • Typically, a web server is only able to serve existing files; dynamically generated content usually requires additional programs or services. The Common Gateway Interface (CGI) provides one way to generate content dynamically. Other methods are also possible. It executes a user program to generate output. Note that such programs are often security risks as they usually process some input from a web interface and are not designed to securely handle that input (e.g., student code :-).

    • Apache is the most popular web server technology (Netcraft, February 2016). Apache 2 (included in modern OS releases):
      • Supports multi-process and mult-threaded operation
      • Supports SSL/TLS encryption
      • Supports proxy operation
      • Supports virtual hosting
      • Supports syslog logging, but typically doesn't use it
      See http://httpd.apache.org/ for documentation. Primary configuration files are in /etc/httpd/conf/. Skim through the extensive httpd.conf file as we will be editing it later. Note the use of modules to turn on or off various behaviors. The administrator can also configure the number of processes to use, number of requests to be served by each child process, where the DocumentRoot is, what format to use for generating logs, and much more.

  4. Configuring Apache.

    In our installation, apache has been installed as /usr/sbin/httpd with configuration and logging in /etc/httpd. First, start apache by modifying the services on your machine as we did in last lab (e.g., in System->Administration->Services) to start httpd and make it start at boot. Open a web browser, and visit http://localhost/. You should see a Test page for Apache. Now you know your httpd server is running.

    Now let's create some content. The default home directory for Apache's content is in /var/www/html/. Note that it is empty! The test page you saw was generated on-demand by a module (see the info on the test page for details). If you create an index.html file (which is the default file that is served, even when only the root of a directory is specified as the URL), it will show up instead of the test page.

    Create two subdirectories (choose your own names, such as alpha and beta). Within each subdirectory, create new index.html files (we want to have two different files here). You might visit some website you like and use the browser's Save As menu to make a copy of the HTML.

    Create two hostnames that map to your localhost. You can do this by modifying (if necessary) the zone files you created in last lab, or by just adding two new hosts into your /etc/hosts file and have them both map to 127.0.0.1. To test this, you should be able to use these hostnames in your web browswer, and still get the Apache/Fedora test page.

    Now we can create virtual Web sites for each of these hostnames. Near the end of Apache's long configuration file is a section called VirtualHost. You'll want to enable virtual hosting by uncommenting the NameVirtualHost directive (just above) and specifying the IP address to which it applies (use whatever one you used in your zone files or /etc/hosts file above). Copy the sample twice and modify the copies to match the two hostnames and two directories that you created above. Restart apache, and you should now see the host-specific index.html home pages rather than the test page with your Web browser. However, if you want to have a default host other than your first virtual host, you'll need to create a third entry (to go first). (If no Host: HTTP header is included in a request, or doesn't match an existing VirtualHost entry, the Web server will serve using the first VirtualHost that matches.)

  5. Add a Perl CGI application.

    Fortunately for this exercise, Apache is already configured to support CGI scripts. The default directory for them is /var/www/cgi-bin/. As a demonstration of using a Perl script for CGI, we will use a simple chat application called EveryChat. Check out the local installation at http://wume.cse.lehigh.edu/~brian/chat/chatframes.html so that you know what to expect.

    Download this free (but obsolete) application from http://www.everysoft.com/ and use unzip to uncompress this zip archive and extract its contents. Take a look at the readme.txt file --- it has instructions on how to install EveryChat, and those instructions include needing to edit multiple files. This package was written on a Windows machine, and so all of the files are written with DOS-style end-of-line markers (carriage return -- ASCII 13) rather than UNIX end-of-line markers (newlines -- ASCII 10). For text and HTML this might not matter, but it sometimes matters for scripts. If you have problems running the Perl script, you may need to translate the format. I used the dos2unix utility; there are likely other methods. The package documentation does not mention this (potential) problem.

  6. Wrapping Up

    In order to sign the lab completion sheet, you will need to:
    1. tell me why subsequent requests to a caching nameserver show ever-changing TTLs.
    2. tell me what chroot is.
    3. show me your forward zone and show me what nslookup or host returns for the three names in that zone.
    4. show me the two web pages you created using the virtual hosting.
    5. show me your perl scripting chat site in action.


This page can be reached from http://www.cse.lehigh.edu/~brian/course/2016/sysadmin/labs/
Last revised: 6 March 2016.