Difference between revisions of "OPS335 Lab 4"

From CDOT Wiki
Jump to: navigation, search
Line 1: Line 1:
= Some DNS Review =
+
[[Category:OPS335]][[Category:OPS335 Labs]]
  
Last week we got an introduction to administering a simple authoritative DNS server. This week we'll review those topics, and learn a few more record types. You'll learn still more about DNS in your first assignment.
+
==MAIL SERVER RESOURCES==
  
Also if you didn't become comfortable using the '''dig''' tool - you'll get more practice with it now.
 
  
== MX Record ==
+
Online References:
  
When someone tries to send email to '''senecacollege.ca''' - they actually want to send email to the Seneca mail server, which is not senecacollege.ca. That is a very typical setup for any business - it simplifies administration and helps a little with load balancing.
+
* [ OPS335 Mail Server Notes ] Course Note providing Concepts and Overview of mail server setup
 +
* [http://www.fredshack.com/docs/postfix.html Postfix for Dummies] Good Basic Guide to setup Postfix MTA
  
Find the MX record for senecacollege.ca using dig:
 
  
<source lang="bash">dig senecacollege.ca MX</source>
+
==OVERVIEW &amp; PREPARATION==
 +
This lab will show you how to set up a '''Postfix''' email server ('''MTA''') on your '''VM2''' and '''VM3''' machines. You will also be setting up on your '''VM2''' and '''VM3''' machines the '''mailx''' package ('''MUA''') to allow users to send and receive text-based mail messages. You should also be able to send email messages to your Seneca College email account.
  
Notice that the email servers aren't even a subdomain of senecacollege.ca but a completely different company (Microsoft in this case). In other cases (for example check the records for google.com) the email servers are within the company's domain.
+
The diagram below shows the layout of the what this lab should be able to accomplish:
  
In still other (rare) cases there is no MX record at all (check littlesvr.ca) - in that case the server that's at the IP for that domain is handling the email.
 
  
Notice that the response for your dig commainds for MX records contains domain names and not IP addresses. That means that when you look for a domain's email server - you may need to do a query for MX and another for A.
+
[[Image:email-setup.png]]
  
You should be comfortable reading and writing an MX record in the Bind configuration file. See [http://www.zytrax.com/books/dns/ch8/mx.html the reference] for the syntax.
 
  
== CNAME record ==
+
==INVESTIGATION 1: INSTALL &amp; SETUP THE MAIL TRANSFER AGENT (MTA)==
  
Sometimes you want multiple domain names to point to the same server. The most common example of this is the www. subdomain. Use dig to find the main web server for Seneca or for CBC.
+
{{Admon/important|Prerequistites|<ol><li>Ensure <u>all</u> machines have been updated and that the '''clocks are set to the correct date and time'''.<br></li><li>Due to the changes made in this lab3, '''you will now need your vm1 running (as the DNS server)''' in order for any of your virtual machines to be able to use the internet.</li></ol>}}
  
See [http://www.zytrax.com/books/dns/ch8/cname.html the reference] for CNAME to get examples of how to configure such records in Bind.
+
=== Confirm Network Connections ===
  
== TXT record ==
+
Before proceeding with this lab, we need to confirm our machines have connectivity to the Internet before we can install and start sending e-mail messages.
  
A TXT record can store pretty much anything, it's typically used for purposes that the desiners of DNS haven't though of themselves. For example a common use of a TXT record is SPF: a record that helps receiving email servers to determine the likelyhood that a message is spam.
+
'''Perform the following steps:'''
  
== Your task ==
+
#Make certain that you can connect to the Internet on your Host Machine via web-browser.  Since your host should be using '''VM1''' as its '''DNS server''', you will need to make certain that the VM1 machine is running as well.
 +
#Start Firefox on your Host Machine, and access your Seneca e-mail account (https://myseneca.ca).
 +
#Confirm that you can access the web from your VM2 machine. You can install the wget or lynx applications in order to test this for your text-based server (NOTE: you should not have to authenticate yourself on the guest machine).
  
Configure at least one of each of the records above for your domain served by the Bind server in your vm1 and verify that your records work.
+
===Install and configure Postfix on a VM===
  
= Test Plans =
+
We will now be installing the postfix application which will act as the Mail Transfer Agent (MTA) that will send and receive e-mail messages between servers (VMs as well as servers that are outside of our virtual network).
  
Every IT company needs to do testing - whether on software they create or systems they set up. Whenever you have a job to do - there has to be a way to show that your job is complete and correct (according to original expectations).
+
'''Perform the following steps:'''
  
How much detail goes into the test plan depends on the resources available for testing, the scale of the changes, and the risk associated with getting things wrong. In your case the worst that's going to happen if you misconfigure a server is you'll lose some marks. In the industry a mistake like that can cost the company you work for a lot of money (perhaps even more than your salary).
+
#Switch to your '''VM2''' machine.
 +
#Check the status of the '''sendmail''' service by using the '''systemctl''' command.  If the sendmail service is running, use the systemctl command to stop and disable that service.
 +
#Issue the following command to install the '''Postfix''' application (MTA):<br><br>'''yum install postfix'''<br><br>
 +
#What is the purpose of installing the postfix application in terms of using e-mail? Record your answer in your lab logbook.<br><br>'''NOTE:''' We need to configure the postfix application (i.e. our MTA) to recognize our recently-created domain name that we setup in lab3.<br><br>
 +
#Edit the Postfix configuration file: '''/etc/postfix/main.cf''' and edit this file to contain only the contents displayed below:<br><br>'''mydomain = senecaID.org'''<br>'''myorigin = $mydomain'''<br>'''mynetworks = 127.0.0.0/8, 192.168.X.0/24'''<br>'''relay_domains ='''<br>'''inet_interfaces=all'''<br><br>'''NOTE:''' Your MTA has the ability to resolve "fake" public address to an actual user account name. For example, if you have a user account called "msaul", you can have the MTA resolve the fake name "murray.saul" to the account name "msaul".<br>In order to do this you need to create an alias which is contained in the MTA's alias file.<br><br>
 +
#Edit the '''/etc/postfix/aliases''' file and add your first name as an alias to be resolved to your VM2's account name:<br><br>'''your-first-name''' &nbsp; &nbsp; &nbsp; '''your-vm2-regular-username'''<br><br>
 +
#In order to update the MTA's database for the newly-create alias, issue the following command:<br>'''postalias hash:/etc/aliases'''<br><br>
 +
#Finally, to start and enable your MTA, issue the following commands:<br><br>'''systemctl start postfix.service'''<br>'''systemctl enable postfix.service'''<br><br>
 +
#Check the '''/var/log/messages''' file to see that your MTA server started without error If there are any errors, correct them before continuing.
  
Whether you have an extremely detailed process or something quick and simple - your test plan must be made with a well organized set of test cases.
 
  
== Test Cases ==
+
'''Record steps, commands, and your observations in INVESTIGATION 1 in your OPS335 lab log-book'''
  
Theoretically you write the test cases before you complete the system. In a way the test suite (all the test cases combined) determine the requirements for your system.
 
  
Generally speaking each test case typically has at least one expected positive and some number of expected negative results. For example if you're setting up a DNS record for www.yoursenecaid.org your test case might look something like this:
+
==INVESTIGATION 2: INSTALL &amp; SETUP THE MAIL USER AGENT (MUA)==
  
[[Image:Sample_test_case.png|800px| ]]
+
We will be using a simple text-based Mail User Agent called mailx to send messages between your running mail servers (MTAs).
  
The test above shows a few things: that the DNS server is running, that it's accessible from the internal network, and it is serving the correct record. It also shows that the needed record does not propagate to the public DNS servers - the server 8.8.8.8 doesn't have the same record that your private server does. That's not a wonderful result but it's what you were expecting so it's still a positive result. In fact if 8.8.8.8 returned an A record for your query - you should be concerned that the rest of your test cases may be incorrect.
 
  
You can spend an infinite amount of time running tests and stil not prove anything definitively, so you have to do your best to make sure the tests you run are representative of the requirements - that after a successful run of all the tests the service is almost certainly working correctly.
+
=== Installing the Mail User Agent (MUA)===
  
=== Failures ===
+
'''Perform the following Steps:'''
  
Test cases (in a test suite, in a system that keeps track of them) are not intended to only show that the system is working. It's equally valuable to see that at some point in the past there was a problem. In that case there may be a bug number or some other means of tracking down what caused the problem in the past and how it was fixed. So recording failed test results is just as important as recording passes.
+
#Issue the following command to install the '''mailx''' application (MUA):<br><br>'''yum install mailx'''<br><br>
 +
#Refer to the chart below to acquaint yourself on how to use the mailx application:
  
== Your task ==
+
--- INSERT REFERENCE CHART ---
  
When I check your lab - I normally ask you to run some commands, and I'll ask you some questions, and that is a sort of made-up-on-the-fly test suite for your lab. Let's formalize that for one section of one lab in a set of test cases.
 
  
Pick any section of any lab you like that would justify having at least three test cases. Write the test cases in a template, save a copy of that for the current test run, and execute the tests, recording the results.
+
===Testing mail with the internet===
  
= Submit =
+
We will now test to see if your MTA for your VM2 machine is correctly running by sending email messages to other servers (both within and outside your virtual network).
  
To submit the lab - show that the new DNS records you created are served correctly and show your completed test plan.
+
 
 +
'''Perform the following steps:'''
 +
 
 +
#Test email from your machine by sending an email to your Seneca account using the following command:<br><br>'''mail -s "PART C3" <Your Seneca email address>'''<br><br>'''NOTE:''' after you type in your letter, enter a period in the first column on the last line and hit the ENTER key.<br><br>
 +
#Check your learn email to see if you got the email (note that it may take a few minutes to arrive, so you may also wish to try an alternate email account if you have one). When you do receive that email make a note of the return address.
 +
#If you did not receive the mail, check the mail logs on your machine to determine what the error is.
 +
#Test email from your Host Machine by sending an email to your Seneca account using the following command:<br><br>'''mail -s "PART C4" -r hacker@evil.com <Your Seneca email address>'''<br><br>
 +
#Check your Seneca email to see if you got the email. If you did make a note of the return address.
 +
#Repeat the steps for INSTALL &amp; '''SETUP THE MAIL TRANSFER AGENT (MTA)''' and '''INSTALL &amp; SETUP THE MAIL USER AGENT (MUA)''' for your '''VM3'''.
 +
 
 +
===Testing email using IP Addresses===
 +
 
 +
If you were able to send e-mail to your Seneca e-mail account from your VM2 and VM3, then we should test to see if we can send email messages within our virtual private network.
 +
First, let's send a message using a static IP ADDRESS for each VM:
 +
 
 +
'''Perform the following Steps:'''
 +
 
 +
#Adjust your firewall (iptables) to allow traffic to port 25 on both VMs.
 +
# Check your '''/var/log/maillog''' file to see the log entries get created when mail is sent and received, or notes when something goes wrong.
 +
#Try sending an email from '''vm2''' to your '''vm3''' by issuing the command:<br><br>'''mail -s "PART E2" yyyyyy@[192.168.X.4]'''<br><br>
 +
#Try sending an email from your '''vm3''' to '''vm2''' by issuing the command:<br><br>'''mail -s "PART E3" root@[192.168.X.3]''' <br><br>
 +
 
 +
===Test email using host names===
 +
 
 +
Let's complete this lab by sending email messages using our recently-created domain name:
 +
 
 +
'''Perform the following Steps:'''
 +
 
 +
#Use the '''host''' and '''hostname''' commands to confirm that each of your machines has the same ''hostname'' and that the DNS service verifies this to be true.
 +
#Restart your MTA (postfix) server if you changed the hostname on either mail server.
 +
#Try sending mail to yourself on both machines. For example, as the username <senecaID> on VM 3, use the command:<br><br>$ mail <senecaID>@vm2.<yourdomain>.org<br><br>'''NOTE:''' the machine will prompt for a subject: enter "testing" without the quotes.<br><br>
 +
#Enter the body of your e-mail message. When you have completed entering your email message, enter a period (.) in column 1 on the last line of your letter. This will send the signal: '''end-of-file''' and your letter will be mailed. You should end up back at the shell prompt. If you make a mistake, use '''CTRL-C''' to cancel the email (DO <u>NOT</u> USE CTRL-Z).
 +
#Use the '''mailq''' command on both machines (you will need to be root) to view the mail queue. Why would this command be useful for an administrator?
 +
#Use the mail command to check to see if you have received any mail.
 +
 
 +
'''Record steps, commands, and your observations in INVESTIGATION 2 in your OPS335 lab log-book'''
 +
 
 +
 
 +
==COMPLETING THE LAB==
 +
Upon completion of this lab you should have postfix mail servers running on two machines, and starting automatically when they do.  These servers must have sent email both ways between each other (from VM 2 to VM 3, and from VM 3 to VM 2), and to your seneca email (or other external mail server).
 +
 
 +
 
 +
==EXPLORATION QUESTIONS==
 +
 
 +
#What did changing the relay_domains parameter do?
 +
#What firewall rule or rules, if any, did you have to enter so that email between your VMs would work?
 +
#What is the meaning of the square brackets surrounding the IP address in the examples?
 +
#What were the results of sending email between the VMs? Show log segments to verify your answers.

Revision as of 14:33, 10 February 2016


MAIL SERVER RESOURCES

Online References:

  • [ OPS335 Mail Server Notes ] Course Note providing Concepts and Overview of mail server setup
  • Postfix for Dummies Good Basic Guide to setup Postfix MTA


OVERVIEW & PREPARATION

This lab will show you how to set up a Postfix email server (MTA) on your VM2 and VM3 machines. You will also be setting up on your VM2 and VM3 machines the mailx package (MUA) to allow users to send and receive text-based mail messages. You should also be able to send email messages to your Seneca College email account.

The diagram below shows the layout of the what this lab should be able to accomplish:


Email-setup.png


INVESTIGATION 1: INSTALL & SETUP THE MAIL TRANSFER AGENT (MTA)

Important.png
Prerequistites
  1. Ensure all machines have been updated and that the clocks are set to the correct date and time.
  2. Due to the changes made in this lab3, you will now need your vm1 running (as the DNS server) in order for any of your virtual machines to be able to use the internet.

Confirm Network Connections

Before proceeding with this lab, we need to confirm our machines have connectivity to the Internet before we can install and start sending e-mail messages.

Perform the following steps:

  1. Make certain that you can connect to the Internet on your Host Machine via web-browser. Since your host should be using VM1 as its DNS server, you will need to make certain that the VM1 machine is running as well.
  2. Start Firefox on your Host Machine, and access your Seneca e-mail account (https://myseneca.ca).
  3. Confirm that you can access the web from your VM2 machine. You can install the wget or lynx applications in order to test this for your text-based server (NOTE: you should not have to authenticate yourself on the guest machine).

Install and configure Postfix on a VM

We will now be installing the postfix application which will act as the Mail Transfer Agent (MTA) that will send and receive e-mail messages between servers (VMs as well as servers that are outside of our virtual network).

Perform the following steps:

  1. Switch to your VM2 machine.
  2. Check the status of the sendmail service by using the systemctl command. If the sendmail service is running, use the systemctl command to stop and disable that service.
  3. Issue the following command to install the Postfix application (MTA):

    yum install postfix

  4. What is the purpose of installing the postfix application in terms of using e-mail? Record your answer in your lab logbook.

    NOTE: We need to configure the postfix application (i.e. our MTA) to recognize our recently-created domain name that we setup in lab3.

  5. Edit the Postfix configuration file: /etc/postfix/main.cf and edit this file to contain only the contents displayed below:

    mydomain = senecaID.org
    myorigin = $mydomain
    mynetworks = 127.0.0.0/8, 192.168.X.0/24
    relay_domains =
    inet_interfaces=all

    NOTE: Your MTA has the ability to resolve "fake" public address to an actual user account name. For example, if you have a user account called "msaul", you can have the MTA resolve the fake name "murray.saul" to the account name "msaul".
    In order to do this you need to create an alias which is contained in the MTA's alias file.

  6. Edit the /etc/postfix/aliases file and add your first name as an alias to be resolved to your VM2's account name:

    your-first-name       your-vm2-regular-username

  7. In order to update the MTA's database for the newly-create alias, issue the following command:
    postalias hash:/etc/aliases

  8. Finally, to start and enable your MTA, issue the following commands:

    systemctl start postfix.service
    systemctl enable postfix.service

  9. Check the /var/log/messages file to see that your MTA server started without error If there are any errors, correct them before continuing.


Record steps, commands, and your observations in INVESTIGATION 1 in your OPS335 lab log-book


INVESTIGATION 2: INSTALL & SETUP THE MAIL USER AGENT (MUA)

We will be using a simple text-based Mail User Agent called mailx to send messages between your running mail servers (MTAs).


Installing the Mail User Agent (MUA)

Perform the following Steps:

  1. Issue the following command to install the mailx application (MUA):

    yum install mailx

  2. Refer to the chart below to acquaint yourself on how to use the mailx application:
--- INSERT REFERENCE CHART ---


Testing mail with the internet

We will now test to see if your MTA for your VM2 machine is correctly running by sending email messages to other servers (both within and outside your virtual network).


Perform the following steps:

  1. Test email from your machine by sending an email to your Seneca account using the following command:

    mail -s "PART C3" <Your Seneca email address>

    NOTE: after you type in your letter, enter a period in the first column on the last line and hit the ENTER key.

  2. Check your learn email to see if you got the email (note that it may take a few minutes to arrive, so you may also wish to try an alternate email account if you have one). When you do receive that email make a note of the return address.
  3. If you did not receive the mail, check the mail logs on your machine to determine what the error is.
  4. Test email from your Host Machine by sending an email to your Seneca account using the following command:

    mail -s "PART C4" -r hacker@evil.com <Your Seneca email address>

  5. Check your Seneca email to see if you got the email. If you did make a note of the return address.
  6. Repeat the steps for INSTALL & SETUP THE MAIL TRANSFER AGENT (MTA) and INSTALL & SETUP THE MAIL USER AGENT (MUA) for your VM3.

Testing email using IP Addresses

If you were able to send e-mail to your Seneca e-mail account from your VM2 and VM3, then we should test to see if we can send email messages within our virtual private network. First, let's send a message using a static IP ADDRESS for each VM:

Perform the following Steps:

  1. Adjust your firewall (iptables) to allow traffic to port 25 on both VMs.
  2. Check your /var/log/maillog file to see the log entries get created when mail is sent and received, or notes when something goes wrong.
  3. Try sending an email from vm2 to your vm3 by issuing the command:

    mail -s "PART E2" yyyyyy@[192.168.X.4]

  4. Try sending an email from your vm3 to vm2 by issuing the command:

    mail -s "PART E3" root@[192.168.X.3]

Test email using host names

Let's complete this lab by sending email messages using our recently-created domain name:

Perform the following Steps:

  1. Use the host and hostname commands to confirm that each of your machines has the same hostname and that the DNS service verifies this to be true.
  2. Restart your MTA (postfix) server if you changed the hostname on either mail server.
  3. Try sending mail to yourself on both machines. For example, as the username <senecaID> on VM 3, use the command:

    $ mail <senecaID>@vm2.<yourdomain>.org

    NOTE: the machine will prompt for a subject: enter "testing" without the quotes.

  4. Enter the body of your e-mail message. When you have completed entering your email message, enter a period (.) in column 1 on the last line of your letter. This will send the signal: end-of-file and your letter will be mailed. You should end up back at the shell prompt. If you make a mistake, use CTRL-C to cancel the email (DO NOT USE CTRL-Z).
  5. Use the mailq command on both machines (you will need to be root) to view the mail queue. Why would this command be useful for an administrator?
  6. Use the mail command to check to see if you have received any mail.

Record steps, commands, and your observations in INVESTIGATION 2 in your OPS335 lab log-book


COMPLETING THE LAB

Upon completion of this lab you should have postfix mail servers running on two machines, and starting automatically when they do. These servers must have sent email both ways between each other (from VM 2 to VM 3, and from VM 3 to VM 2), and to your seneca email (or other external mail server).


EXPLORATION QUESTIONS

  1. What did changing the relay_domains parameter do?
  2. What firewall rule or rules, if any, did you have to enter so that email between your VMs would work?
  3. What is the meaning of the square brackets surrounding the IP address in the examples?
  4. What were the results of sending email between the VMs? Show log segments to verify your answers.