Difference between revisions of "OPS335 - Assignment 1 (Part 2)"

From CDOT Wiki
Jump to: navigation, search
Line 69: Line 69:
 
| style="border: 2px solid black;" |  '''IMAP''' mail Server
 
| style="border: 2px solid black;" |  '''IMAP''' mail Server
 
|-  style="background-color:white;"
 
|-  style="background-color:white;"
| style="border: 2px solid black;" | '''perch.species.lake.ops'''  
+
| style="border: 2px solid black;" | '''milton.species.lake.ops'''  
 
| style="border: 2px solid black;" |  '''172.17.15.8'''   
 
| style="border: 2px solid black;" |  '''172.17.15.8'''   
 
| style=border: 2px solid black;" |  '''Samba''' Server
 
| style=border: 2px solid black;" |  '''Samba''' Server

Revision as of 13:08, 1 October 2018

Purpose

In this assignment, you will use the 335assign virtual network and the cloyne cloning-source that you created in assignment 1 (part 1) to create two name-servers. One of the cloned VMs (hostname: toronto) will be a master name server, and the other VM (hostname: ottawa) will be a slave name server. You will install and setup the master and slave servers in order to provide various domain name resolutions for existing servers, and for servers that will be created and used in assignment #2.

General Requirements

Weight: 7% of the overall grade

Due Date: During Week 9 (in class)

Detailed Requirements

Important.png
It is YOUR responsibility to Backup all of your VMs for this Assignment!
You are required to frequently backup your VMs prior to exiting a work session during this assignment. Your instructor will NOT accept the fact that your hard disk crashed and lost all of your work. If you properly backed up your VM images and xml configuration files to a USB, then you can purchase a new hard-disk or wipe and recreate your hard disk and restore your VMs.

Set-up Master Name Server (toronto)

Perform the following steps for this section:

  1. Create a clone virtual machine called toronto from the cloyne cloning-source. Refer to the table below for address and hostname.
  2. Create a regular user for this virtual machine using your Seneca userID.
  3. Setup a DNS server on your toronto virtual machine noting the following items below:
    1. This virtual machine will be the Master DNS server for species.lake.ops.
    2. Only ottawa will be allowed to obtain zone transfers of this zone.
    3. This machine will provide forward and reverse lookups of ALL virtual machines in the species.lake.ops. zone, including resource records for virtual machines that do not currently exist.
    4. Include an MX record for email sent to the domain to be directed to kingston.species.lake.ops.
    5. Any machine in the species.lake.ops network may use this machine to perform queries of machines outside the network, however it will route all such queries through the DNS server you created in lab #3.
    6. For machines outside the species.lake.ops domain, it will only answer queries about machines inside the network. They may not use it to query other machines.

Set-up Slave Name Server (ottawa)

Perform the following steps for this section:

  1. Create a clone virtual machine called ottawa from the cloyne cloning-source. Refer to the table below for address and hostname.
  2. Create a regular user for this virtual machine using your Seneca userID.
  3. Setup a DNS server on your ottawa virtual machine noting the following items below:
    1. This virtual machine will be the Slave DNS server (in case the Master Name Server goes down).
    2. This virtual machine will obtain its zone files by copying them from the Master Name Server.
    3. This Slave DNS server will check for updated records from the Master DNS server every two days. If the initial attempt fails, then it will attempt every six hours until it succeeds, or one week has passed.
    4. This machine will provide forward and reverse lookups of ALL virtual machines in the species.lake.ops zone, the zone files for which will be obtained from toronto.species.lake.ops.
    5. Only machines within the species.lake.ops domain will be allowed to query this machine.
    6. This machine will not provide recursive lookup capabilities for any machines.

Network Configuration

As you will now have functioning primary and secondary DNS servers, modify your network configuration file on these machines and on the cloning source to specify the correct IPADDR.

Table of Virtual Machines / DNS Records

All the machines in the following table require DNS records. The rows not shaded represent future servers that will be created in Assignment #2.

Hostname / Domain Address Purpose
freshwater.species.lake.ops (your existing host) External Facing Address: DHCP assigned
Internal Virtual Bridge (virbr1): 172.17.15.1
Your host machine
cloyne.species.lake.ops 172.17.15.100 Cloning-source used to create other servers for other assignments.
toronto.species.lake.ops 172.17.15.2 Master Name Server
ottawa.species.lake.ops 172.17.15.3 Slave Name Server
kingston.species.lake.ops 172.17.15.5 SMTP mail Server
coburg.species.lake.ops 172.17.15.6 IMAP mail Server
milton.species.lake.ops 172.17.15.8 Samba Server

Set-up Firewall Policies

In addition to the basic firewall established in assignment 1, ensure the following restrictions are met:

  1. Any machine may query toronto
  2. Only the machines in the species.lake.ops network may query ottawa.

Assignment Submission

The student is required to prove to their professor that their set-up works correctly during the regularly-scheduled lab period.

Assignment Evaluation Details

  • Demonstrate working assignment to your instructor in class:
    1. You need to run their full backup shell script to backup all of your VMs (like you did in Assignment 1 - Part 1.
    2. Students need to demonstrate their assignment functionality to their professor during a lab period
      (like you would for any lab for "sign-off").
    3. Students are required to prepare everything ahead of time so that you can quickly demonstrate to your instructor that all required parts of your assignment are working.
    4. Do not proceed to the next step until you have demonstrated your assignment to your instructor to check for errors that may cause problems when running the checking script.

  • Download and run a shell script to check your work (Depending on your OPS335 Instructor):


Peter Callaghan's Classes (Section D):
  • Refer to instruction on blackboard for instructions on how to submit this assignment.


Colin Yips Classes (Sections A , B & C):
  1. Login as root on your host machine.
  2. Change to the /root/bin directory.
  3. Make certain that your cloning-source, primary DNS and secondary VMs are running.
  4. Make certain that the mailx command has been installed. If not, issue the following command to install e-mail on your host machine:
    yum install mailx
  5. Issue the command to download a checking script for your assignment to your host machine:

    wget https://scs.senecac.on.ca/~colin.yip/2184/check-assn1-p2-colin.bash

    Set execute permissions and run the shell script.
    (Your shell script contents will be mailed to your Seneca email and to your OPS335 instructor's Seneca email.

    If you do NOT receive an e-mail message in your Seneca email account, then there is a problem, and you MUST rerun or contact your OPS335 instructor immediately.


  • Additional Assignment Information:
    1. This assignment is to be completed individually. Group submissions are not allowed.
    2. You are NOT allowed to use local hostname resolution (i.e. no entries in your /etc/hosts file).
    3. Test your machine to make sure it works. If a machine is not accessible (e.g. will not boot, can not be accessed through ssh from your host, etc.), or is otherwise non-functional, you may be told to resubmit.
    4. Late submissions are a subject to a penalty of 10% per day.
    5. SELinux must be set to Enforcing.


    Evaluation Rubric

    Here is an evaluation rubric (in table form) showing you how you will be evaluated for this assignment. Part of the rubric is marked from professor observation from student demonstration of assignment in class, and the other part is based on output from the results of an assignment checking script that the student will download and run.

    Student Demonstration (in class)
    Evaluation Item Mark
    toronto and ottawa VMs created
    /1
    toronto and ottawa VMs can perform DNS queries of vm1, vm2, vm3
    /1
    toronto and ottawa VMs can perform forward DNS lookups for ALL machines within network (listed in the table above)
    /3
    toronto and ottawa VMs can perform reverse DNS lookups for ALL machines within network (listed in the table above)
    /3
    Zone transfer occurs
    /3
    Configuration (Checking Script Output)
    Evaluation Item Mark
    Master Name Server (toronto) - Network Configuration
    correct static network configuration
    (one mark for each network config item)
    /5
    Master Name Server (toronto) - Named Configuration Options / Zone Declarations
    Zone transfer (i.e. to slave DNS server) limited to ottawa only
    /1
    Allows forward and reverse lookups to species.lake.ops
    /1
    Recursion limited to species.lake.ops only
    /1
    toronto server is the master name-server for species.lake.ops
    /1
    Master Name Server (toronto) - Zone Record
    SOA - two common options (determined by instructor at time of marking)
    /2
    Correct NS records in forward zone
    /2
    Correct NS records in reverse zone
    /2
    MX record
    /1
    Slave Name Server (ottawa) - Network Configuration
    correct static network configuration
    (one mark for each network config item)
    /5
    Slave Name Server (ottawa) - Named Configuration Options
    Queries are limited to species.lake.ops
    /1
    Slave server is Non-recursive
    /1
    Allows forward and reverse lookup for species.lake.ops
    /1
    ottawa server is slave name-server for species.lake.ops
    /1
    Firewall policies
    toronto allows queries from any machine (i.e. will work with vm1, vm2, vm3)
    /2
    ottawa limits queries to species.lake.ops (i.e. won't work with vm1, vm2, vm3)
    /2
    Less Deductions (1 mark per issue for EACH VM):
    • VM hostname NOT set
    • firewalld enabled / running
    • iptables disabled / not running
    • No Yum update
    • Named NOT active
    • Local hostname resolution appears in /etc/hosts (1 mark per entry, per vm)
    • Neglecting major safeguards (e.g. no firewall present, firewall allowing all traffic, no active SELinux) (4 marks per issue, per VM)
    • Failing to backup VMs (1 mark deduction for each VM not backed up)
    TOTAL /40