OPS335 Lab 1

INVESTIGATION 1: BASIC NETWORK CONFIGURATION (REVISITED)

Remember how you set up the network interfaces in your virtual machines in OPS235? You're expected to know that "inside-out" by now.

In OPS235, you learned how to configure a virtual private network via graphical applications for the centos1 and centos2 machines. In the previous lab, you have created and cloned VMs that are text-based only (like centos3). All of the services that we are configuring in this course require a working network connection; therefore, it is very important that you know how to set (preferable configure) a static IP address, default gateway, as well as your DNS server.

This lab is a review of the material from labs 6 ( CLI Network Configuration ), but will also show newer (more efficient) commands in the process.

Checking Your Current Network Settings

In OPS235 you've used the ifconfig and route commands. In this course we'll use the ip command instead (you're welcome to use the old commands but you're expected to know the new ones too).

1. View the table below comparing older vs newer methods of obtaining network setting information for a Linux machine.

Comparison of Older and Newer Methods of Obtaining Network Settings

Purpose	Older Method (command)	Newer Method (command)
Obtain IP ADDRESS and Subnet Mask	ifconfig	ip address
Obtain Default Gateway	route -n	ip route
Obtain DNS Server	nslookup	more resolv.conf
Obtain Hostname	uname -n	Same

2. Run the ifconfig and ip address commands separately. Do you notice any differences between their respective outputs?
3. Repeat the same steps for other two sets of commands listed in the table.
4. Which commands do you prefer to use?
5. Use the man pages to see how to issue the above commands to create a temporary connection to your existing network.

Making Persistent (Permanent) Network Setting Changes

If you change your network settings using the commands in the previous section, those changes will be lost if you restart your Linux machine. In order to have your network settings become permanent, you need to edit and save the settings changes in a file. For the IP address, subnet mask, default gateway, and DNS server you edit that file is contained in a directory called: network-scripts.

1. From your OPS335/OPS235/ULI101 notes, issue a command to provide the full path-name of the directory: network-scripts
2. Why do you think that previously issued command can be useful when you want to edit your exiting network settings?
3. The name of the file that contains your persistent network settings has the following name format: ifcfg-{interfacename}
4. Which filename in your network-scripts directory do you think contains your current network settings?
5. View the contents of the file to see if it contains the IP ADDRESS, subnet mask, and default gateway?
6. What is the MAC address if your current machine?
7. Does this file contain the hostname of your machine? If not, what command can allow you to change your machine's hostname?

Set static IP addresses on vm1, vm2, and vm3

Except for your host machine, all the Virtual Machines in this course will have static network configuration (as opposed to Automatic or DHCP). Sometimes, you will be required to debug networking problems quickly by changing the network configuration of your VMs.

If the following steps aren't 100% clear - make sure to practice them.

1. Edit each of your VMs to use a static IP address: vm1 should use the first available address in the subnet, vm2 the second, and vm3 the third.
2. Don't forget to set the default gateway and DNS server for your VMs. You can use your host's IP address as a DNS server (libvirt will proxy the requests to the real DNS server).
3. Make note of the files used and entries required and note them in your lab log-book.
4. Restart each VM and run the following command to ensure they still have the network configuration you set:

ping (what is the purpose of this command?). Try to ping matrix and google from your host machine. Try to ping matrix and google from each of your VM's to ensure you can reach the outside world.

ssh (into another server, like Matrix)

If everything works - great. If not, move on to the next section.

Linux network connection configuration troubleshooting

If the network works in your host but not in the VM, the following are the usual steps you go through to troubleshoot the problem, starting with the first two rules of troubleshooting:

1. Is it plugged in? On a physical network you would check whether the cable is plugged in and the link light is on on your network card. In a virtual network environment you don't have that - you'll need to check the NIC settings in the virtual machine details. In there it will tell you which virtual network your virtual network card is connected to.
2. Is it turned on? This is a problem more common with virtual networks than physical networks. Check in your VirtManager->ConnectionDetails->VirtualNetworks that your network is active.
3. Do you have an IP address? Run ip address to check.
4. Can you ping the host by IP? (by its internal IP address). If not - check all of the above, check if you have an IP address conflict, check that your subnet mask is correct.
5. Can you ping 8.8.8.8? If all of the above work - check that your default gateway is set correctly with ip route and that you can ping the default gateway.
6. Can you resolve google.ca? Run host google.ca. If it doesn't come back with an IP address, and all of the above worked - check that your DNS server is configured correctly and that you can ping it.

There are a number of other problems that could prevent your network connection from functioning but the above are the most common problems.

7. Move to your vm1 in order to perform the following trouble-shooting task:
   1. Use the wget command to download and run the following shell script:
      [ link shell script here ]
      
      
   2. after you have run that shell script, restart your vm1 machine.
   3. Use the commands taught in this lab to confirm if your network connection is broken.
   4. Carefully check your configuration to see if there is a change to your settings
   5. Try to temporarily connect to the Internet
   6. Edit your network settings file to make the changes permanent
   7. Test your connectivity (including after a reboot of your vm1.

You should be able to go through that troubleshooting process pretty quickly. Setting up the network in this course is never a primary task, but it's almost always a prerequisite for anything else we're going to do. You can't have a working web server (or any other kind of server) if you don't have a working network connection.

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

SSH Server

The default (and often the only) way to administer a linux server is via SSH. Even in your case where you have a direct console to all your VM screens you may find it helpful to connect to your virtual machines using SSH (if nothing else - you can resize the terminal window).

The SSH server should be installed and running in your VMs. If it's not installed - you can install openssh-server using yum. Whether it is running or not - you should practice the following commands to make sure you know how to use them, you'll need them for nearly every topic this semester:

• systemctl start/stop
• systemctl enable/disable
• systemctl status

SSH Keys

Using the magic of public key cryptography you can SSH to a linux machine without using a password. This topic is crucial - not only for this course but in the industry, SSH keys are used everywhere that linux servers are used.

Here's a modified diagram from Sébastien Saunier's blog that's a simple illustration of how SSH key authentication works (the one in the blog post had a significant error in it which I fixed in the version here):

It's not a complete diagram but it helps see all the parts of ssh key authentication in one place.

Public/Private key pair

This needs to be generated on and used on your client (the user/machine you're connecting from). The private key is the equivalent of a password, that's why it's private. And a private key is used by one user, that's why it's stored in a user's ~/.ssh/ directory.

You generate a new keypair with this command (press enter for all the questions):

ssh-keygen -t rsa

You'll end up with ~/.ssh/id_rsa and ~/.ss/id_rsa.pub - now you have a key pair you can use for authentication.

Public key on the server

If you have the private key - you can prove to someone who has your public key that you're really the owner of that public key. That's how ssh key authentication works, so the server needs to have you user's public key. You can copy it over manually and append the contents of your ~/.ssh/id_rsa.pub from the client to ~/.ssh/authorized_keys on the server, or you can issue this command on the client to do all that for you:

ssh-copy-id -i ~/.ssh/id_rsa.pub username@server

After that you can login without a password. But remember - keys are per user, not per machine. So this will only work with one user on the client and one user on the server (the two users involved in running the command above).

Your task ===: For this lab you have to set up password-less login for the root user on the host to the root user on each of the VMs.

Rsync

Rsync is a very versatile backup tool. As the name suggests it's used for synchronising files typically across a network. It works over the SSH protocol so if you have ssh working - you can use rsync as well.

You're going to use your host machine to backup files from the virtual machines. To make it simpler we won't have any incremental backups and the backups will be automated so don't rely on these too much, but they may save you some time over the many weeks in this course.

On your host run the following commands:

mkdir -p /backup/vm1
rsync -avz 192.168.x.2:/etc /backup/vm1/

If rsync asked for a password - make sure you completed the SSH keys part of the lab, and that you're using the correct user. If you get a different error - perhaps rsync is not installed. What you should see is all the files from vm1 being copied over.

Rerun the command. Notice that the second time nothing is copied over - that's because there would be no point, none of the files have changed on vm1.

Create a new file in vm1's /etc/ directory, and rerun rsync. Notice that only that file gets copied over.

Cron

Cron is a daemon - a program that runs in the background. It's role is to run tasks periodically. It can run tasks for the system or for a user (any user). We'll get cron to run some backup scripts for us, but first let's see how it works.

Every user has a crontab - a list of tasks they want to run periodically. You edit this table using the command crontab -e. Once you run the command you'll get an empty file where you have to insert a line like this:

10 * * * * echo "Cron ran this job at: "`date` > /tmp/cron.log

This tells cron to run the command echo "Cron ran this job at: "`date` > /tmp/cron.log at the 10th minute of every hour of every day of every month. Modify the setting so it will run in a couple of minutes from now and insert that into your crontab.

Wait for the minute to pass, and check that /tmp/cron.log was created with the expected contents. You can also check /var/log/cron to see what jobs were run.

Your task: set up cron to make automatic backups of the /etc directory from vm1, vm2, and vm3 into /backup/vm1, /backup/vm2, and /backup/vm3. These should run every hour and overwrite the previous backup. Which makes them lousy backups but they're better than nothing.

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

Completing the lab

• Each of your VMs should now boot to a command prompt (no graphical interface), and should be using a static IP address.
• Each of your VMs should have a working network connection and a static IP address.
• Each of your VMs should have an SSH server running.
• You should be able to ssh from your host to each VM as the root user without a password.
• Backups of the three VMs' /etc/ directories are made automatically in the host.
• You have notes in your labbook about what you've learned in this lab.