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

From CDOT Wiki
Jump to: navigation, search
m (Tweaking the SOA timers)
Line 26: Line 26:
 
#Create a clone virtual machine called '''dining''' from the '''foundation''' cloning-source. Refer to the table below for '''address''' and '''hostname'''.
 
#Create a clone virtual machine called '''dining''' from the '''foundation''' cloning-source. Refer to the table below for '''address''' and '''hostname'''.
 
#Create a '''regular user''' for this virtual machine using '''your Seneca userID'''.
 
#Create a '''regular user''' for this virtual machine using '''your Seneca userID'''.
#Setup a DNS server on your '''dining''' virtual machine noting the following items below:<ol type="a"><li>This virtual machine will be the '''Slave DNS server''' (in case the Master Name Server goes down).</li><li>This virtual machine will obtain its zone files by copying them from the Master Name Server.</li><li>This Slave DNS server will check for updated records from the Master DNS server every day. If the initial attempt fails, then it will attempt every hour until it succeeds.</li><li>This machine will provide '''forward''' and '''reverse''' lookups of ALL virtual machines in the '''house.neighbourhood.ops''' zone, the zone files for which will be obtained from '''kitchen.house.neighbourhood.ops'''.</li><li>Only machines within the '''house.neighbourhood.ops''' domain will be allowed to query this machine.</li><li>This machine will not provide recursive lookup capabilities for any machines.<br><br></li></ol>
+
#Setup a DNS server on your '''dining''' virtual machine noting the following items below:<ol type="a"><li>This virtual machine will be the '''Slave DNS server''' (in case the Master Name Server goes down).</li><li>This virtual machine will obtain its zone files by copying them from the Master Name Server.</li><li>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.</li><li>This machine will provide '''forward''' and '''reverse''' lookups of ALL virtual machines in the '''house.neighbourhood.ops''' zone, the zone files for which will be obtained from '''kitchen.house.neighbourhood.ops'''.</li><li>Only machines within the '''house.neighbourhood.ops''' domain will be allowed to query this machine.</li><li>This machine will not provide recursive lookup capabilities for any machines.<br><br></li></ol>
  
 
=== Network Configuration ===
 
=== Network Configuration ===

Revision as of 12:52, 26 September 2017

Purpose

In this assignment, you will use the 335assign virtual network and the foundation cloning-source that you created in assignment 1 (part 1) to create two name-servers. One of the cloned VMs (hostname: kitchen) will be a master name server, and the other VM (hostname: dining) 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 (kitchen)

Perform the following steps for this section:

  1. Create a clone virtual machine called kitchen from the foundation 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 kitchen virtual machine noting the following items below:
    1. This virtual machine will be the Master DNS server for house.neighbourhood.ops.
    2. Only dining 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 house.neighbourhood.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 bedroom.house.neighbourhood.ops.
    5. Any machine in the house.neighbourhood.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 house.neighbourhood.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 (dining)

Perform the following steps for this section:

  1. Create a clone virtual machine called dining from the foundation 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 dining 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 house.neighbourhood.ops zone, the zone files for which will be obtained from kitchen.house.neighbourhood.ops.
    5. Only machines within the house.neighbourhood.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 Address Purpose
roof.house.neighbourhood.ops (your existing host) | External Facing Address: DHCP assigned
Internal Virtual Bridge (virbr1): 172.30.10.1
Your host machine
foundation.house.neighbourhood.ops 172.30.10.100 Cloning-source used to create other servers for other assignments.
kitchen.house.neighbourhood.ops 172.30.10.3 Master Name Server
dining.house.neighbourhood.ops 172.30.10.4 Slave Name Server
bedroom.house.neighbourhood.ops 172.30.10.7 SMTP mail Server
closet.house.neighbourhood.ops 172.30.10.8 IMAP mail Server
basement.house.neighbourhood.ops 172.30.10.9 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 kitchen
  2. Only the machines in the house.neighbourhood.ops network may query dining.

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. Students need to demonstrate their assignment functionality to their professor during a lab period
      (like you would for any lab for "sign-off").
    2. 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.
    3. Do do 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 (Murray Saul's Sections B & C / Peter Callaghan's Section D):
  • Instructions will be provided through Moodle.


Elizabeth Kopiec's Classes (Section A):
  1. Login as root on your host machine.
  2. Change to the /root/bin directory.
  3. Make certain that both your kitchen and dining virtual machines are running.
  4. Issue the command to download a checking script for your assignment to your host machine:
    wget http://matrix.senecac.on.ca/~elizabeth.kopiec/ops335/check-assn1-p2.bash
  5. Set execute permissions and run the command: /root/bin/check-assn1-p2.bash
    (You 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
    kitchen and dining VMs created
    /1
    kitchen and dining VMs can perform DNS queries of vm1, vm2, vm3
    /1
    kitchen and dining VMs can perform forward DNS lookups for ALL machines within network (listed in the table above)
    /3
    kitchen and dining 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 (kitchen) - Network Configuration
    correct static network configuration
    (one mark for each network config item)
    /5
    Master Name Server (kitchen) - Named Configuration Options / Zone Declarations
    Zone transfer (i.e. to slave DNS server) limited to dining only
    /1
    Allows forward and reverse lookups to house.neighbourhood.ops
    /1
    Recursion limited to house.neighbourhood.ops only
    /1
    kitchen server is the master name-server for house.neighbourhood.ops
    /1
    Master Name Server (kitchen) - 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 (dining) - Network Configuration
    correct static network configuration
    (one mark for each network config item)
    /5
    Slave Name Server (dining) - Named Configuration Options
    Queries are limited to house.neighbourhood.ops
    /1
    Slave server is Non-recursive
    /1
    Allows forward and reverse lookup for house.neighbourhood.ops
    /1
    dining server is slave name-server for house.neighbourhood.ops
    /1
    Firewall policies
    kitchen allows queries from any machine
    /2
    dining limits queries to house.neighbourhood.ops (won't work with vm1, vm2, vm3)
    /2
    Less Deductions (1 mark 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)
    TOTAL /40