OPS335 Lab 1

Configure a Linux Gateway for Linux Hosts inside an Intranet

This lab will show you how to set up a simple intranet using one Fedora PC as a gateway. The same Fedora PC will be a host a small group of Fedora 16 VM's (Virtual Machine) which will act as PC's inside an intranet. Here is a diagram of your setup.

Requirement - Lab 0
Lab 0 should be completed and you should have a copy of Fedora 16, x86_64 LIVE ISO Image.

Instructions

Managing services using systemd

Boot up your Fedora 16 x86_64 system, login with your learn id and use Firefox to authenticate yourself on Senenet so you can download and install new software.

• Open a terminal window and su to root.
• Ensure your system date and time are correct.
• Ensure your system is up to date

yum update

• Start your ssh server

service sshd start
Redirecting to /bin/systemctl start sshd.service

• Notice that your command was redirected to 'systemctl', the command executed was 'systemctl start sshd.service'. Record this in your lab book.
• Enable sshd to start at boot

chkconfig sshd on
Note: Forwarding request to 'systemctl enable sshd.service'.
ln -s '/lib/systemd/system/sshd.service' '/etc/systemd/system/multi-user.target.wants/sshd.service'

• Again notice your command was redirected to 'systemctl', the command executed was 'systemctl enable sshd.service'. A symbolic link was created as well, explain its purpose in your lab book.
• Install the virtualization software

yum groupinstall virtualization

• Start the libvirt daemon using 'systemctl'

 systemctl start libvirtd.service

• Enable libvirtd to start at boot using 'systemctl'

systemctl enable libvirtd.service
libvirtd.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig libvirtd on
Warning: unit files do not carry install information. No operation executed.

• Note the output of the above command - libvirtd.service is not a native service, redirecting to /sbin/chkconfig. How can you tell if a service is native or non-native to 'systemd'?

How to change the default runlevel using systemd

Fedora 16 does not use '/etc/inittab' to set the default run level but rather uses targets as a more flexible replacement. Note the output of the following command:

ll /etc/systemd/system/*.target
lrwxrwxrwx. 1 root root 36 Dec  3 09:35 /etc/systemd/system/default.target -> /lib/systemd/system/runlevel5.target

and

ll /lib/systemd/system/*.target

Systemd uses symbolic links to point to the default runlevel in use. To change the default runlevel you must first remove the existing symlink.

rm /etc/systemd/system/default.target

To change your system to boot in Graphical mode by default:

ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target

Make note of the command that would be needed to change the default 'runlevel' (or 'target' as it is now referred to when using systemd) to multiuser or runlevel 3.

Create your personal network

Observe and record the output of the following command:

iptables -t nat -L

Start Virtual Machine Manager through Gnome or through command line. You will need to enter your root password.

virt-manager

Right click 'localhost (QEMU)' and select 'Details'. Click on the 'Virtual Networks' tab and use the plus sign to add a new virtual network using the following options.

• Name your virtual network 'ops335'
• Use the last two digits of your student number for the third octet of network IP address. Example, if your student number is 000-000-090, the network address would be 192.168.90.0/24.
• Ensure the DHCP range will allow you to assign at least 3 static IP addresses.

• Choose 'Forwarding to physical network' radio button, 'Destination: Any physical device' and 'Mode: NAT'

• Ensure the network is started at boot.

Once completed open a terminal and observe and record the output of the following command:

iptables -t nat -L

Installing the first guest machine

With the virtualization software installed and your personal network created, you are now ready to create your first "Virtual Machine". Use the Fedora 16 x86 64 bit disk to install, or download an iso from Belmont (these links will only work at school).

 wget http://belmont.senecac.on.ca/fedora/releases/16/Live/x86_64/Fedora-16-x86_64-Live-Desktop.iso
 or
 wget http://belmont.senecac.on.ca/fedora/releases/16/Live/x86_64/Fedora-16-x86_64-Live-KDE.iso

• Click on the icon "Create a new virtual machine" to begin.
• Name your machine "f16-vm01" and choose your installation method - "Local install media". Choose the desired option to install from either the CD or iso. For "OS type" select "Linux" and for Version select "Fedora 16" then click on the "Forward" button.
• Use the default memory and CPU options for use with lab computers (Depending available hardware these settings can be adjusted). Then click on the "Forward" button to proceed.
• Leave the disk image size set at 8GB, ensure "Allocate entire disk now" is checked, then click on the "Forward" button.
• At the "Ready to begin installation" window click on 'Advanced options' arrow to review available options.
  • Select the Virtual Network named 'ops335'. Make note of the other available options.

Once your Fedora Live CD boots up you will see a message that Gnome 3 has failed to load and is currently running in fallback mode. This is normal for a VM. Close the dialog window and click on the Applications menu.

• Select Applications -> System Tools -> Install to Hard Disk
  • Click the "Next" button to begin your F13 installation. Select the appropriate default options.
    • Change your hostname to "vm01.localdomain".

Firstboot - First user created
For successful completion of the labs, please ensure the first user created is named using your Learn ID.

During Firstboot create a user with the same name as your learn ID and the first user created on your host machine. This is important to ensure future labs work. Now login and open a terminal window. Switch to root and update your VM guest machine

yum update

This could take a long time and you should reboot after it's done. Ensure your VM guest has internet access

host cbc.ca

Creating additional Clone VM's

To quickly create additional VM's shutdown 'f16-vm01', right click and select 'Clone...'. Use the following options:

• Name: f16-vm02
• Storage:
  • Click the drop down menu below 'f16-vm01.img', choose details and rename the image to the f16-vm02.img

Once successfully created boot the new VM and correct the host name. This can be done using the GUI or command line.

• Record in your notes how each is done.
• After creating f16-vm02 repeat the above steps to create f16-vm03 and correct the host name.

• Check for connectivity.

host cbc.ca

Testing Connectivity

• Test connectivity by pinging each of your VM's.
• Ping matrix and google from each of your VM's to ensure you can reach the outside world. (you will need to be authenticated on your host machine).
• Start the ssh server using 'systemctl'

systemctl start sshd.service

• Enable the ssh server at startup on all machines

systemctl enable sshd.service

• Try to ssh from the guest to the host machine.
• Try to ssh from the host to the guest machine.
• Try to ssh to your Matrix account from both the host and guest machines.
• Try to ssh from your Matrix account back to your host and guest machines.
• Add one iptables rule to the guest firewall that will accept new ssh connections to the guest machine.
• Save your new firewall rules

iptables-save > /etc/sysconfig/iptables

• Restart iptables using systemctl

systemctl restart iptables.service

• Ensure changes are still present

iptables -L

• Try to ssh from the host to the guest machine.

Completing the Lab

Time for a new backup!
If you have successfully completed this lab, make a new backup of your virtual machines.

Answer the following questions in your logbook.

1. How can you tell if a service is native or non-native to 'systemd'?
2. Explain the iptables rules displayed when you ran the command 'iptables -t nat -L'. How did they differ after creating your personal network.
3. Explain the output displayed when you enabled sshd to start at boot by running the command 'chkconfig sshd on'.
4. What file was edited to change the host name on your VM's?
5. What iptables rule was added to allow ssh connections to the guest vm's?
6. How are ping and ssh affected (on both machines) when you run the following command on the host machine?
   • echo 0 > /proc/sys/net/ipv4/ip_forward
7. Change the default target on vm02 and vm03 to multiuser, what command was used?