Difference between revisions of "OPS235 Lab 2 - Fedora17"

From CDOT Wiki
Jump to: navigation, search
Line 81: Line 81:
 
==Instructions==
 
==Instructions==
  
# Insert and secure your SATA hard disk to the removable disk slot.
+
=== Preparation ===
# Power up the computer.
 
# Insert the Fedora 13 x86_64 Installation DVD into the DVD drive.
 
# Reboot the system.
 
  
===Investigation 1: How do you install Fedora?===
+
{{Admon/tip|Update your Fedora Installation|It's a good idea to ensure that your Fedora installation is fully updated before proceeding. You can update your system with the graphical tool located on the menu at >System>Administration>Software Update (or type the command <code>gpk-update-view</code>), or by typing either of these commands: <code>pkcon update</code> or <code>yum update</code>}}
{{Admon/important | Logical Volume Management | Fedora uses a type of storage management called Logical Volume Management (LVM). In LVM, disk partitions are called Physical Volumes (PVs) and provide storage to a Volume Group (VG). This storage is then split into various Logical Volumes (LVs). The advantage to this scheme is that you can change LV size and you can add and remove PVs after installation. For example, you can add a new disk to your system and then increase the size of your existing filesystems using that extra disk space. ''Please be careful to enter all LVM information accurately, including the VG and LV names.'' We will investigate and manipulate LVM in future labs.}}
 
  
{{Admon/note | Installation Time | The installation process will take about 15 minutes to complete when using DVD. Click the Reboot button on the screen to reboot the system after the installation is complete. There is a post installation setup after boot.}}
+
# Install the Fedora virtualization software: <code>yum groupinstall "Virtualization"</code> or <code>pkcon install @virtualization</code>  The virtualization software installed is in three parts:
 +
## A system service named ''libvirtd'' that manages the VMs.
 +
## Tools to manage virtualization, including the <code>virt-manager</code> graphical tool and the <code>virsh</code> command-line tool.
 +
## The actual virtual machines themselves.
 +
# Start the virtualization service: <code>service libvirtd start</code>
 +
# The firewall configuration is altered by the addition of the virtualization software. Restart the firewall so that these changes become active: <code>service iptables restart</code>
 +
# Start the graphical tool by selecting the menu option Applications>System Tools>Virtual Machine Manager or by typing the command <code>virt-manager</code>
  
 +
{{Admon/important|Run virt-manager as a regular user|Running virt-manager as root may not work due to configuration issues.}}
  
# After booting from the Installation DVD, at the Welcome Screen choose "Install or upgrade an existing system" to launch the Graphical installation program and select the following options (you can use the media test to verify that your DVD burned correctly -- It will take some time -- otherwise, skip it):
+
{{Admon/caution|Reboot your fedora host|There appears to be an issue with supplying your VM's with a dynamic IP unless the host is restarted after installing "Virtualization". '''Reboot now to avoid this problem.'''}}
#* Language - English
 
#* Keyboard Configuration - U.S. English
 
#* Type of devices: Basic Storage Devices
 
#* There should only be one storage drive listed - select it
 
#* If you get a warning that the drive may need to be initialized, it is because your drive is new and contains no partitition table. Select "Re-Initialize"
 
#* Set your hostname to - f13host (one word, no space, all lowercase)
 
#* Root Password: enter a password of your own choosing. Pick one that is really, really hard to guess to protect your system. (Recommendation: use the first letter and all the punctuation from a favorite phrase or song verse. For example, "To be or not to be, that is the question!" could become the password "Tbontb,titq!").
 
#* Disk Partition Setup - Specify a Custom Layout, and then set up the installation with this configuration:
 
#** Find your existing 300MB partition (/dev/sda1). Edit this entry so that the mountpoint is /boot and is formatted as an ext3 filesystem.
 
#** Don't touch the other existing 300M partition (/dev/sda5).
 
#** Create 4 new LVM Physical Volumes that are 25000 MB in size. Set the File System Type to Physical Volume (LVM). Should be /dev/sda6 to /dev/sda9.
 
#** Create an LVM Volume Group. Set the Volume Group Name to '''vg_main''' and set the Physical Extent size to '''4MB'''.
 
#** Click on the Add button (within the "Make LVM Volume Group" window) to create a logical volume within that volume group:
 
#*** Mount point / (root), filesystem type ext4, logical volume name '''root''', size 90000MB.
 
#* Say yes to continue without a swap partition.
 
#* Say yes to format /dev/sda1.
 
#* Accept Boot Loader defaults.
 
#* Accept Graphical Desktop and repository defaults.
 
# Proceed with the installation. '''Note how long it takes to perform the installation.'''
 
# Reboot using the controls on the screen. When the system starts, it will ask you some final configuration questions.
 
#* Check the License Agreement. What license is used for the Fedora distribution? What activities do have restrictions and obligations?
 
#* Create a user account for yourself using the same name as your learn account.
 
#* Set date and time. Normally, you would want to enable Network Time Protocol, but since we will be experimenting with the networking turned off in later labs, leave it disabled.
 
#* Click on Do Not Send Hardware Profile.
 
#* Finish the post-installation customization, wait for the login screen to appear, and then login to your Learn account.
 
  
Answer the Investigation 1 question in your lab log book.
+
=== Investigation 1: Installing from a Live Disc ===
  
{{Admon/tip|Forcing the Resolution on the Projector|The podium computers in the lab rooms are connected to a video splitter. This splitter then connects to both the LCD screen on the podium and the projector at the front of the room. However, the splitter prevents the computer from successfully querying the LCD or screen to find the supported resolutions, and Fedora therefore selects a very low (safe) resolution. If you are using a podium system, you can force the native 1680x1050 resolution of the LCD display using [http://matrix.senecac.on.ca/~chris.tyler/fedora-scripts/1680x1050 this script].}}
+
{{Admon/tip|Using an Image instead of a Live Disc|If you do not have a Live Disc available, you can download the .iso image file from http://belmont.senecac.on.ca/fedora/releases/13/Live/x86_64/Fedora-13-x86_64-Live.iso and then use the iso image file in place of the physical disk.}}
  
===Investigation 2: How many files packages and files are installed on the system?===
+
==== Introduction ====
  
For the rest of the tasks in this lab, you must login to your system using your Learn account and execute all commands under your learn account. If you get a Permission Denied message when trying to execute a command, then switch to the superuser account by running the command su -  and type in the password for "root". Once the intended command is executed, type "exit" to exit from the superuser account and return to your regular Learn account.
+
In this investigation, you will install Fedora from your live disc, and observe the differences between this type of installation and the DVD installation previously performed.
  
Record the commands used and the output generated in each of the following steps:
+
==== VM Details ====
  
# To find all the mount points, enter the command: <code>mount</code>
+
* Name: fedora1
#* Study the output and record all the mount points in your log book.
+
* Boot media: Fedora Live CD
# The name of the installation log file is <code>/root/install.log</code> -- It is an ASCII file (how can you be sure?) and can be viewed with the <code>less</code> command.
+
* Installation source: Fedora Live CD
# You can make use of this file to determine how many packages have been installed: complete the following command to count the number of packages listed in the installation log file:
+
* Memory: 512MB
#* <code>grep ________________ /root/install.log | wc -l</code>
+
* Disk space: 10GB
# Using the <code>rpm</code> command: you can also use the following commands to list all the installed packages, and the total number of packages installed:
+
* CPUs: 1
#* <code>rpm -q -a</code>
 
#* <code>rpm -q -a | wc -l</code>
 
#* <code>rpm -qa  | wc -l</code>
 
# The <code>-q</code> option means query, and the <code>-a</code> option means all (in other words, query all installed software packages). Did you get the same number of packages from the above two methods?
 
# Some of the files on your system were installed with the software packages, and some were created by system activity (for example, by creating your Learn account and by logging in). If you know the package name (from the <code>install.log</code>), you can list all the files that were installed from the package by using the following command:
 
#* <code>rpm -q -l package_name</code>
 
# This combines the <code>-q</code> (query) option with the <code>-l</code> (list filenames) option.
 
# You can pipe the outupt through <code>wc -l</code> to count the number of lines:
 
#* <code>rpm -ql package_name| wc -l</code>
 
# Using what you learned in steps 3, 4, and 8, get a count of the total number of files installed by all of the software packages on your system.
 
# To find out the name that you have assigned to your Linux system, enter the command: <code>hostname</code>
 
# To find out the kernel version of your GNU/Linux workstation and the date it was created, enter the command:  <code>uname -r</code>
 
# To find out all the system processes running on your GNU/Linux workstation, enter the command: <code>ps -ef</code>
 
# To capture the list of all the system processes to a file called <code>ps.lst</code>, enter the command: <code>ps -ef > ps.lst''</code>
 
# Copy the installation log file <code>/root/install.log</code> and the file ps.lst to a USB memory key, or scp to your matrix account as a backup.
 
  
{{Admon/tip |Updating Fedora|The Fedora 13 software is updated frequently to add features, fix bugs, and upgrade security. Perform a system update to get the latest versions of the packages installed in Fedora: Start the Firefox web browser, turn off popup window blocking (select ''Edit>Preferences'', then select the Content tab and uncheck the box to Block Popups), then login to SeneNET. Open a terminal and type <code>su</code> to start a shell as root. Enter the command <code>yum update</code> This will download and install all of the packages that have been updated since the installation DVD image was created.  If you complete this command at Seneca it should run quite fast as Seneca College hosts a Fedora Repository mirror (a copy of all of the current fedora packages, on a local web server).}}
+
==== Steps ====
  
=== Investigation 3: What is a runlevel? ===
+
{{Admon/note|Fedora 12 Screen Shots|The following screen shots are from Fedora 12. The Fedora 13 version of virt-manager varies slightly -- there are a few extra controls on some dialogs which may be ignored.}}
  
After the kernel boots, it starts a single program, called <code>init</code>. A running instance of a program is called a '''process''' -- the init process always has a process ID (PID) of 1. All other processes on the system are started by init, or they are started by processes started by init.
+
# In the Virtual Machine Manger, click on the icon to ''Create a Virtual Machine'' in the upper-left corner: <br />[[Image:Virt-manager1.png]]
 +
# A window will appear with the title ''New VM''. There are five steps to be completed; click Forward after each step:
 +
# Step 1 of 5: Enter the virtual machine name and select ''Local install media''.<br />[[Image:Virt-manager2.png]]
 +
# Step 2 of 5: Insert the CDROM or DVD containing the Fedora Live Disc image. Wait a moment for the disc to be recognized, then select it as the install media. Set the ''OS type'' to Linux and the ''Version'' to Fedora 13.<br />[[Image:Virt-manager3.png]]
 +
<!-- {{Admon/tip|Using an ISO image|Instead of using a physical CD or DVD, you can use an ISO image of a CD or DVD. The virtualization software will make this ISO image appear like an actual CD within the virtual machine. Because hard disks are faster then optical discs, this will work faster than an actual CD/DVD.}}{{Admon/note|Choosing the operating system type and version|The purpose of the ''OS type'' and ''Version'' fields is to fine-tune some of the virtual machine settings for best performance. The VM will work even if these are set incorrectly.}} -->
 +
# Step 3 of 5: Set the memory to 512 MB and the number of CPUs to 1.<br />[[Image:Virt-manager4.png]]
 +
# Step 4 of 5: This next step creates a disk file that will be used to simulate the virtual machine's disk drive. Select a size of 10 GB and checkmark the box labeled ''Allocate entire disk now''.<br />[[Image:Virt-manager5.png]]
 +
# Step 5 of 5: Review the options that you have selected. '''Make a note of the storage location.''' If anything needs to be changed, use the ''Back'' button to go back and edit it; otherwise, click ''Finish''.<br />[[Image:Virt-manager6.png]]
 +
# The virtual machine will now start. You will see a window which displays the virtual video card from the VM. It's important to note that the VM can (and often will) run even when this display is not present. The virtual machine is running from the live disc at this point, and no software has been installed on the ''hard drive'' of the virtual machine.
 +
# Login to the VM and double-click on the ''Install to Hard Drive'' icon. The installation program, similar to the one used when installing Fedora in Lab 2, will appear. You will get a warning at one point during the installation process that the disk "may need to be re-initialized" -- this is simply a warning that the virtual disk is completely blank, and it is safe to select ''Re-initialize drive''.
 +
# During the installation process, when prompted for the drive, select "Virtio Block Device", when prompted for the hostname, enter "fedora1", when prompted for the timezone, select ''America/Toronto'', and when asked about storage, select ''Use All Space''. '''Use the default values for all other fields.''' Notice that the installer does not ask you what software should be installed; compare the installation time to the amount of time it took to do your Lab 2 installation.
 +
# When the installation is complete, select the menu option System>Shutdown to stop the Live Disc.
 +
# Start the VM from its disk image by selecting Virtual Machine>Run from the virtual machine menu. You will get the ''Firstboot'' configuration questions during the boot process (asking you to create a user, set the date and time, and optionally send the hardware profile to the Fedora Project). Create a user with the same name as your Matrix account.
 +
# Login using the new user account.
 +
# Enable SSH access to your virtual machine with these commands: <code>service sshd start; chkconfig sshd on</code>
 +
# Find out the IP address of your virtual machine: <code>ifconfig eth0</code>
 +
# Enter the following command on your virtual machine to create a firewall exception to allow ssh traffic into the machine:  <code>iptables -I INPUT -p tcp -s0/0 -d0/0 --dport 22 -j ACCEPT</code>
 +
# Confirm that you can ssh to your virtual machine from the host (your main Fedora installation): <code>ssh ''IPaddress''</code>
  
Most current Linux systems use some variation of the init system originally developed for Unix System V (called "sysvinit") or a newer version called "upstart".
+
=== Investigation 2: Installing from the Network ===
  
These systems employ the concept of "runlevels" -- groups of software that can be selected, so that the system can be run in various modes. In Fedora systems, these runlevels are used:
+
{{Admon/tip|Authenticate to the network|The rest of this lab uses network access. Be sure to authenticate to the network using your browser before proceeding.}}
  
{|class="mediawiki" border="1"
+
==== Introduction ====
!Runlevel
+
 
!Description
+
It is possible to install Fedora entirely from the network. In this investigation, you will install Fedora from a webserver on Seneca's LAN.
 +
 
 +
==== VM details ====
 +
 
 +
* Name: fedora2
 +
* Boot media: Network installation
 +
* Installation source: http://belmont.senecac.on.ca/fedora/releases/13/Fedora/x86_64/os/
 +
* Memory: 512MB
 +
* Disk space: 15GB
 +
* CPUs: 1
 +
 
 +
==== Steps ====
 +
# Create the VM as you did with the ''fedora1'' virtual machine, except:
 +
#* In step 1 of 5, set the installation type to "Network Install (HTTP, FTP, or NFS)"
 +
#* In step 2 of 5, provide the URL http://belmont.senecac.on.ca/fedora/releases/13/Fedora/x86_64/os/
 +
#* In step 2 of 5, set the ''OS Type'' to "Linux" and ''Version'' to "Fedora 13"
 +
# Observe the boot process. How is it different from booting from an optical disc (CD/DVD)?
 +
# Start the installation process. When you get to the disk partitioning step, enable the checkbox labelled ''Review and modify partition layout''. On the next screen, change the logical volumes as follows:
 +
#* Reduce the size of the root LV to 8000 MB.
 +
#* Add a logical volume with a size of 2000 MB and a mountpoint of /home (you can name it whatever you want, and use ext3 or ext4 as the filesystem type).
 +
# On the software selection screen, select ''Graphical Desktop''.
 +
# On the same screen, select the "Fedora 13 - x86_64" and the "Fedora 13 - x86_64 - Updates". Leave "Installation Repo" selected. ''DO NOT'' enable the "Test Updates" repository.
 +
# Complete the installation. Record the time taken to install, and compare this to the time taken by the previous installations.
 +
 
 +
=== Investigation 3: Installing from the Network using Kickstart ===
 +
 
 +
==== Introduction ====
 +
 
 +
When Fedora is installed using the techniques you have used so far, the user is asked a number of questions. In some situations, it is better to provide the answers to these questions in a file rather than answer them individually. This type of file is called a ''kickstart'' file.
 +
 
 +
In this investigation, a kickstart file is provided for you. You can also create or modify a kickstart file using a regular text editor or a graphical tool.
 +
 
 +
==== VM details ====
 +
 
 +
* Name: fedora3
 +
* Boot media: Network installation
 +
* Installation source: http://belmont.senecac.on.ca/fedora/releases/13/Fedora/x86_64/os/
 +
* Kickstart location: http://zenit.senecac.on.ca/~chris.tyler/fedora13-vda-ks.cfg
 +
* Memory: 512MB
 +
* Disk space: 10GB
 +
* CPUs: 1
 +
 
 +
==== Steps ====
 +
# Create the VM as you did with the ''fedora2'' virtual machine, specifying a network install as before, except:
 +
#* In step 2 of 5, after entering the URL for the installation source, click on the ''URL Options'' control.
 +
#* Enter the Kickstart URL: http://zenit.senecac.on.ca/~chris.tyler/fedora13-vda-ks.cfg
 +
# Observe the installation. How is it different from booting from an optical disc (CD/DVD)?
 +
# Complete the installation. Record the time taken to install, and compare this to the time taken by the previous installations.
 +
# What happens when the installation is finished?
 +
# Take a look at the kickstart file (using the URL you entered) to determine the root password as well as the name and password for the first user account.
 +
# Boot the virtual machine and log in (use the user ID and password information from the previous step). Compare the experience to the first time you booted the other virtual machines.
 +
 
 +
=== Investigation 4: Updating and Comparing the VMs ===
 +
 
 +
# In each VM, run this command: <code>yum update</code>
 +
# Record the answers to these questions in your log book:
 +
#* How long did it take to run on each VM? How many packages were updated?
 +
#* Why does it take longer in some VMs than others?
 +
 
 +
Complete the following table:
 +
 
 +
{|border="1" width="100%"
 +
|-
 +
! ||f13host||fedora1||fedora2||fedora3
 +
|-
 +
|'''Installation Method'''||Installation Disc||Live Disc||Network Installation||Network Installation + Kickstart
 +
|-
 +
|'''Packages Installed'''|| || || ||
 +
|-
 +
|'''Updates Installed immediately after installation'''|| || || ||
 +
|-
 +
|'''Software could be selected during installation'''|| || || ||
 +
|-
 +
|'''Disk layout could be selected during installation'''|| || || ||
 
|-
 
|-
|0
+
|'''No questions asked during installation'''|| || || ||
|Halt (powers off the system)
 
 
|-
 
|-
|1
+
|'''Total installation time''' (after installation questions)|| || || ||
|Single-user maintenance mode, network not running, character-mode display
 
 
|-
 
|-
|2
+
|'''Amount of disk space used'''|| || || ||
|''Not normally used - originally meant: Multi-user mode, network not running, character-mode display''
 
 
|-
 
|-
|3
+
|'''Questions asked during first boot'''|| || || ||
|Multi-user mode, network running, character-mode display
 
 
|-
 
|-
|4
+
|'''Advantages of this type of installation'''|| || || ||
|''Not normally used''
 
 
|-
 
|-
|5
+
|'''Disadvantages of this type of installation'''|| || || ||
|Multi-user mode, network running, graphical user interface
 
 
|-
 
|-
|6
+
|'''This type of installation is recommended for...'''|| || || ||
|Reboot
 
 
|}
 
|}
  
{{Admon/note|Different runlevel systems|Various Linux distributions may use the runlevel numbers differently. For example, on some Debian/Ubuntu systems, the default (standard) runlevel is 2.}}
+
=== Investigation 5: Managing Virtual Machines from the Command Line ===
 
 
In order to implement runlevels, init uses a configuration file and a number of script files:
 
  
* <code>/etc/inittab</code> is the configuration file, which sets the default runlevel.
+
{{Admon/note|Manage virtual machines from the host|The commands used to manage virtual machines must be executed on the host (your disk pack) and not inside a virtual machine.}}
* <code>/etc/rc.d/init.d</code> is a directory of scripts.
 
  
In order to determine which of the startup scripts should be executed in each runlevel, the one directory per runlevel is created (<code>/etc/rc.d/rc'''X'''.d</code>, where '''X''' is the runlevel). This directory is filled with symbolic links to the startup scripts in <code>/etc/rc.d/init.d</code>
+
# Start the ''fedora1'' virtual machine, and stop the ''fedora2'' and ''fedora3'' virtual machines.
 +
# Enter these commands and note the result:
 +
#* <code>virsh list</code>
 +
#* <code>virsh list --all</code>
 +
#* <code>virsh list --inactive</code>
 +
# Start the ''fedora3'' virtual machine from the command line: <code>virsh start fedora3</code>
 +
# Repeat the commands from step 2 and notice any changes.
 +
# Stop the ''fedora3'' virtual machine: <code>virsh shutdown fedora3</code>
 +
# Confirm that ''fedora3'' has been shut down.
 +
# Execute this command: <code>virsh dumpxml fedora3 >fedora3.xml</code>
 +
# Examine the file <code>fedora3.xml</code>. What does it contain? What format is it in?
 +
# Edit the file fedora3.xml, making the following changes:
 +
#* Change the name to <code>fedora3a</code>
 +
#* Change at least one of the hexadecimal characters in the UUID. Do not change the length of the UUID. Valid hexadecimal characters are 0-9 and a-f.
 +
# Issue this command: <code>virsh define fedora3a.xml</code>
 +
# Issue the command <code>virsh list --all</code> and record any changes.
 +
# Issue the command: <code>virsh undefine fedora3a</code>
 +
# List all of the virtual machines again, and note any changes.
  
# To find out the value of the runlevel your GNU/Linux system goes into after boot, enter the command: <code>grep initdefault /etc/inittab</code>
+
=== Investigation 6: How do I backup a virtual machine? ===
# You should get a single line containing ":" as the field delimiter. The second field stores the value of the runlevel the init process will use after a reboot. Record the output in your log book.
 
# A list of processes that should be running at a given runlevel can be found in the directory <code>/etc/rc.d/rc'''X'''.d</code> where '''X''' is the runlevel. Do a directory listing of that directory and study what files are in there. Pay attention to the first three characters of each file name. They have special meaning to the system. Record your observation in your log book.
 
# Make a backup of the file /etc/inittab with the command:  <code>cp /etc/inittab /etc/inittab.original</code>
 
# Edit the file <code>/etc/inittab</code> and change the default runlevel to 3. Save the change and reboot your system.
 
# After the reboot, you should get a "Text Login Screen". Login with your Learn account and type startx at the command prompt. Describe what happens in your log book.
 
# Enter the command: <code>runlevel</code> -- this shows the previous and current runlevel. Record the values in your book.
 
  
 +
# Shut down all of the virtual machines.
 +
# Change to the directory <code>/var/lib/libvirt/images/</code>. Note the size of the files in this directory. What do these files contain?
 +
# Make a compressed backup of the <code>fedora3.img</code> file with this command: <code>gzip <fedora3.img >fedora3.img.backup.gz</code>
 +
{{Admon/caution|Make sure the backup is successful!|If there are any error messages, '''DO NOT''' proceed past this point. You're going to destroy your fedora3 virtual machine and restore it using the backup you have created -- if there are any problems with the backup, you will not have a working virtual machine, and will have to re-install it.}}
 +
# Compare the size of the compressed and original files.
 +
# Start the ''fedora3'' VM.
 +
# '''Make certain that you are in your fedora VM, and <u>not</u> in your Fedora main system.'''
 +
# Wreck <u>only</u> your fedora 3 system! Try this command inside the fedora3 virtual machine ('''DO NOT''' do this on your main Fedora system, or you will have to repeat your '''lab2''' and portions of your '''lab3'''!): <code>rm -rf /*</code>
 +
# Shut down the VM.
 +
# Restore the original image from backup (type this command carefully): <code>gunzip <fedora3.img.backup.gz >fedora3.img</code>
 +
# Restart the VM. Is it working normally?
 +
# Create compressed backups of your other virtual machines.
 +
# Answer this question in your log book:
 +
#* In order to fully back up a virtual machine, what information should be saved in addition to the virtual machine image?
 +
# Write the answer to the Investigation 6 question in your lab book.
  
Answer the Investigation 3 question.
+
{{Admon/important|Backing up VMs|It's a good idea to back up your VMs at the end of each lab, so you can easily restore them if something goes wrong in the next lab.}}
  
=== Investigation 4: What is the network configuration? ===
+
{{Admon/tip|Shutting Down the Host while Virtual Machines are Running|If you shut down your host system while virtual machines are running, they will be suspended, and will resume the next time you boot your host system.}}
  
# To check the network configuration settings obtained from the DHCP server, run the following commands, describing the output in your log book:
+
=== Investigation 7: Kickstart Files ===
#* ifconfig
 
#* route
 
#* netstat -rn
 
#* nslookup (at the > prompt, enter the word "server" (do not type the quotes) and record the output. Type exit to leave nslookup).
 
# Find the following information in the output of the above commands:
 
#* MAC address (physical or hardware address) of the ethernet network interface
 
#* The IP address (logical address) assigned by the DHCP server
 
#* The default route (gateway)
 
#* The DNS nameserver
 
  
Answer the Investigation 4 question.
+
{{Admon/tip|SSHD and Firewall|If you have restarted your virtual machine ''fedora1'', the sshd server you started in section 1-16 will no longer be running. In addition, the firewall will have reverted to its original state. In order to use ''scp'', below, you will need to restart ssh and adjust the firewall again.}}
  
=== Investigation 5: How do You Secure the Grub Boot Loader? ===
+
When you perform a non-Kickstart installation, the installation program creates a Kickstart file in the <code>/root</code> directory for reference.
  
{{Admon/caution|Duplicate UUIDs|Before proceeding, use the <code>mount</code> command to check to see which filesystem is mounted on the mount point <code>/boot</code>. If it is <code>/dev/sda5</code>, it is the wrong filesystem. This may be caused by a duplication of serial numbers which is the result of Lab 1; you can fix this problem with this series of commands:
+
# Obtain the kickstart files for all four of your installations (your disk pack ''f13host'', plus the ''fedora1'', ''fedora2'', and ''fedora3'' virtual machines). Copy them all to your f13host system (tip: use <code>scp</code>).
mkdir /media/sda5 /tmp/sda5-files
+
# Compare these files. What are the differences? Similarities? (Tip: you may want to use tools such as <code>sdiff</code> to help with the comparison).
umount /dev/sda5
+
# How could you use the kickstart file produced by the installation program to perform additional, identical installations?
mount /dev/sda5 /media/sda5
 
cp -v -R /media/sda5/* /tmp/sda5-files
 
umount /dev/sda5
 
mkfs -t ext3 /dev/sda5
 
mount /dev/sda5 /media/sda5
 
cp -v -R /tmp/sda5-files/* /media/sda5
 
rm -rf /tmp/sda5-files
 
mount -a
 
}}
 
 
 
By default, the Grub boot loader allows anyone with access to the computer at boot time to set the runlevel, or change the boot parameters, which can allow them to influence the init process and which kernel image is loaded. Anyone with access to the boot prompt can therefore bypass security controls and control which software is loaded. For example, rebooting to runlevel 1, known as single user mode, gives the user root priveleges without the need for a password! Obviously, giving a non-administrator this much control can be dangerous, and it is wise to protect the boot loader with a secure password.
 
 
 
We will need to choose a password, encrypt with the grub programs hash utility (called md5crypt), and add the encrypted hash of your password to the grub configuration file, /etc/grub.conf
 
 
 
{{Admon/important|Do not lose the GRUB password|If you lose the GRUB password you will not be able to change boot parameters when you boot the system. If you need to write it down, put it in a safe place, where no one will be able to tell what it is for.}}
 
 
 
# Choose a suitable password.
 
# Open the grub program by typing the command: <code>grub</code>
 
# At the grub prompt, type in the command: <code>md5crypt</code>
 
# When prompted for a password, carefully type in your password. The program will display the encrypted hash of your password. Carefully write down that encrypted hash generated by the program.
 
# Type the command: <code>quit</code> to exit the grub program.
 
# Open the grub configuration file, <code>/etc/grub.conf</code> for editing. (This file is actually linked to /boot/grub/grub.conf).
 
# Carefully add the line: <code>password --md5 ''password-hash''</code> (note: ''password-hash'' is the hash you generated with md5crypt) Place this line between the splashimage line and the title line. If there are other lines there, there is no need to remove them. Just insert your password line as a new line.
 
# Make sure you have not made a mistake. What you type in must match exactly the output from the md5crypt command.
 
# While you are editing the file you should also increase the timeout for grub to automatically boot the default OS. Edit the line <code>timeout=0</code> to <code>timeout=5</code> to give us more time to interrupt the process.
 
# You should also ensure that the grub boot menu is not hidden. Add a hash sign (<code>#</code>) to the start of the line which reads: <code>hiddenmenu</code>
 
# Save the file and exit. Your Grub boot loader is now password protected.
 
# Find the section of [http://fedorasolved.org/post-install-solutions/runlevel this article] that explains how to change the runlevel at boot time, and read it. Reboot your system, trying to change to runlevel 1 from the boot prompt, and see if the password protection worked.
 
# From now on, when you want to change boot parameters when you boot, you must type lowercase <code>p</code> at the boot prompt and enter the required password.
 
  
 
== Completing the Lab ==
 
== Completing the Lab ==
  
Check off the following items before asking your instructor to check your lab:
+
{{Admon/important | Important! | Arrange evidence of each of the following items on the screen, and then ask your professor or lab monitor to check them:}}
  
* Task 1 - Install GNU/Linux Workstation using Fedora
+
# Three working virtual machines created.
* Task 2 - Collect system information after installation.
+
# Four kickstart files.
* Task 3 - Customize and configure boot time environment
+
# All virtual machines fully updated.
* Task 4 - Collect network information
+
# All virtual machines backed up.
* Task 5 - Password protect Grub Bootloader
+
# Installation comparison table filled in.
 
 
Arrange evidence for each of these items on your screen, then ask your instructor to review them and sign off on the lab's completion:
 
 
 
* Grub is password protected.
 
* Can login with your "learn" account name
 
* Has all the mount points
 
* Has the package count
 
* Has edited the default runlevel
 
* Has the correct IP address and MAC address
 
* Find out the default route (gateway)
 
* IP of the DNS name server
 
* '''Name and contact information on your disk pack'''
 
 
 
{{Admon/tip|Runlevel|Feel free to change your default runlevel to 3 or 5 according to your own personal preference. Note that later labs may assume a particular runlevel.}}
 
  
 
== Preparing for the Quizzes ==
 
== Preparing for the Quizzes ==
  
# How many packages were installed?
+
# What is the name of the Fedora installation program?
# How many files (correct to the nearest hundred) were installed?
+
# Which factors recorded in your table (above) were due to the type of installation performed, and which factors were due to the amount of software installed?
# How many mount points were used?
+
# Which type of installation works best for confirming compatibility with hardware before installation? Why?
# How many users were created automatically on your system (do not count your learn account)?
+
# Which type of installation works best for installing large numbers of computers? Why?
# What is your learn account's UID and GID?
+
# What factors affect installation time?
# What is your learn account's home directory?
+
# How can you reduce the number of software updates required immediately after installation?
# What is the home directory for the user "root"?
+
# Why would you enable additional repositories during installation?
# How do you determine the host name of your GNU/Linux workstation?
+
# What does the file <code>/root/anaconda-ks.cfg</code> contain, and how is it created?
# What command can display the NIC's MAC address?
+
# How do you start and stop virtual machines?
# Which file contains the default "runlevel" value for your GNU/Linux workstation?
+
# How do you SSH into your virtual machines?
 
+
# What is the purpose of and relationship between these pieces of software?
{{Admon/important|Unbind your MAC address|Before moving your disk pack to another system, [[Unbinding MAC Addresses on Fedora|unbind your MAC address]].}}
+
#* libvirt
 +
#* libvirtd
 +
#* virsh
 +
#* virt-manager
 +
#* virt-install
 +
#* vncviewer
 +
#* kvm

Revision as of 11:51, 13 January 2012

Important.png
This is a draft only!
It is still under construction and content may change. Do not rely on this information.
Important.png
The course schedule, labs, and links are subject to change.
Check with your professor for details and changes specific to your section.

OPS235 Lab 2: Fedora 16 Installation Methods (on Virtual Machines)

Introduction

A virtual machine is a software simulation of a computer which can be used as though it were actual hardware. It's possible to run multiple virtual machines on one computer, reducing hardware requirements and introducing flexibility. Some common uses of virtualization include:

  • Software testing -- Using multiple operating systems simultaneously on a single computer for testing and experimentation.
  • Network simulation -- Testing network services, protocols, and security scenarios with a small number of computers.
  • Isolation -- Protecting multiple sets of data by storing them on multiple virtual machines. If one of the virtual machines is compromised, the data on other virtual machines is still protected.
  • Server consolidation -- Reducing the number of physical servers in a network by moving physical machines to virtual machines. This saves hardware, administration, cooling, and electricity costs, and it can increase the utilization of hardware (by ensuring that the hardware is not under-loaded).
  • Load-balancing and disaster recovery -- It is possible to migrate virtual machines between different physical machines, to ensure that a workload is balanced across multiple computers, to allow routine hardware maintenance and upgrading, and to compensate for hardware failure or other disasters.

In this lab, you will create three virtual machines. This also gives you an opportunity to experiment with different ways of installing Fedora. Later in this course you will install another operating system distribution in a virtual machines.

You should already have both a Fedora installation DVD and a Fedora LIVE CD. In both cases, the boot media (which you used to load the installation software) and the installation source (where the software that got installed came from) were the same: your CD/DVD provides both. However, the Fedora (and most other Linux distributions) permits you to use any combination of boot media and installation media:

  • Boot Media:
    • CD or DVD
    • Hard disk
    • USB flash drive
    • Network boot
  • Installation Source:
    • CD or DVD
    • Hard disk
    • USB flash drive
    • Network HTTP or NFS software repository

Objectives

  • Understand Virtualization
  • Use KVM virtualization on Fedora
  • Use a variety of installation methods:
    • Live Image Installation
    • Network Installation
    • Kickstart Installation

Required Materials (Bring to All Labs)

  • Fedora 16 LIVE CD - You can burn this onto a CD-R in the Open Lab
  • Fedora 16 x_64 Installation DVD - You can burn this onto a DVD-R in the Open Lab (or burn image onto a DVD+R if you are using the Freedom Toaster).
  • SATA Hard Disk (in removable disk tray)
  • USB Memory Stick (minimum 64M)
  • Lab Logbook (Lab1 Reference Sheet) (to make notes and observations).

Prerequisite

  • Completion and Instructor "Sign-off" of Lab 1: OPS235 Lab 1

Linux Command Online Reference

Each Link below displays online manpages for each command (via http://linuxmanpages.com):

  • virsh (Refer to Fedora Virtualization Guide below)
  • gzip / gunzip

Reesources on the Web

Virtualization:

Installation Methods:


Idea.png
Performing this Lab off the Seneca network (eg. at home)
This lab uses servers which are on the Seneca network and which are not available from other locations (such as your home). If you attempt this lab from another location, adjust the belmont.senecac.on.ca URLs to point to another Fedora mirror server -- note that you may need to change the directory name as well as the server name. The installation of the fedora3 virtual machine must be done at Seneca.


Instructions

Preparation

Idea.png
Update your Fedora Installation
It's a good idea to ensure that your Fedora installation is fully updated before proceeding. You can update your system with the graphical tool located on the menu at >System>Administration>Software Update (or type the command gpk-update-view), or by typing either of these commands: pkcon update or yum update
  1. Install the Fedora virtualization software: yum groupinstall "Virtualization" or pkcon install @virtualization The virtualization software installed is in three parts:
    1. A system service named libvirtd that manages the VMs.
    2. Tools to manage virtualization, including the virt-manager graphical tool and the virsh command-line tool.
    3. The actual virtual machines themselves.
  2. Start the virtualization service: service libvirtd start
  3. The firewall configuration is altered by the addition of the virtualization software. Restart the firewall so that these changes become active: service iptables restart
  4. Start the graphical tool by selecting the menu option Applications>System Tools>Virtual Machine Manager or by typing the command virt-manager
Important.png
Run virt-manager as a regular user
Running virt-manager as root may not work due to configuration issues.
Stop (medium size).png
Reboot your fedora host
There appears to be an issue with supplying your VM's with a dynamic IP unless the host is restarted after installing "Virtualization". Reboot now to avoid this problem.

Investigation 1: Installing from a Live Disc

Idea.png
Using an Image instead of a Live Disc
If you do not have a Live Disc available, you can download the .iso image file from http://belmont.senecac.on.ca/fedora/releases/13/Live/x86_64/Fedora-13-x86_64-Live.iso and then use the iso image file in place of the physical disk.

Introduction

In this investigation, you will install Fedora from your live disc, and observe the differences between this type of installation and the DVD installation previously performed.

VM Details

  • Name: fedora1
  • Boot media: Fedora Live CD
  • Installation source: Fedora Live CD
  • Memory: 512MB
  • Disk space: 10GB
  • CPUs: 1

Steps

Note.png
Fedora 12 Screen Shots
The following screen shots are from Fedora 12. The Fedora 13 version of virt-manager varies slightly -- there are a few extra controls on some dialogs which may be ignored.
  1. In the Virtual Machine Manger, click on the icon to Create a Virtual Machine in the upper-left corner:
    Virt-manager1.png
  2. A window will appear with the title New VM. There are five steps to be completed; click Forward after each step:
  3. Step 1 of 5: Enter the virtual machine name and select Local install media.
    Virt-manager2.png
  4. Step 2 of 5: Insert the CDROM or DVD containing the Fedora Live Disc image. Wait a moment for the disc to be recognized, then select it as the install media. Set the OS type to Linux and the Version to Fedora 13.
    Virt-manager3.png
  5. Step 3 of 5: Set the memory to 512 MB and the number of CPUs to 1.
    Virt-manager4.png
  6. Step 4 of 5: This next step creates a disk file that will be used to simulate the virtual machine's disk drive. Select a size of 10 GB and checkmark the box labeled Allocate entire disk now.
    Virt-manager5.png
  7. Step 5 of 5: Review the options that you have selected. Make a note of the storage location. If anything needs to be changed, use the Back button to go back and edit it; otherwise, click Finish.
    Virt-manager6.png
  8. The virtual machine will now start. You will see a window which displays the virtual video card from the VM. It's important to note that the VM can (and often will) run even when this display is not present. The virtual machine is running from the live disc at this point, and no software has been installed on the hard drive of the virtual machine.
  9. Login to the VM and double-click on the Install to Hard Drive icon. The installation program, similar to the one used when installing Fedora in Lab 2, will appear. You will get a warning at one point during the installation process that the disk "may need to be re-initialized" -- this is simply a warning that the virtual disk is completely blank, and it is safe to select Re-initialize drive.
  10. During the installation process, when prompted for the drive, select "Virtio Block Device", when prompted for the hostname, enter "fedora1", when prompted for the timezone, select America/Toronto, and when asked about storage, select Use All Space. Use the default values for all other fields. Notice that the installer does not ask you what software should be installed; compare the installation time to the amount of time it took to do your Lab 2 installation.
  11. When the installation is complete, select the menu option System>Shutdown to stop the Live Disc.
  12. Start the VM from its disk image by selecting Virtual Machine>Run from the virtual machine menu. You will get the Firstboot configuration questions during the boot process (asking you to create a user, set the date and time, and optionally send the hardware profile to the Fedora Project). Create a user with the same name as your Matrix account.
  13. Login using the new user account.
  14. Enable SSH access to your virtual machine with these commands: service sshd start; chkconfig sshd on
  15. Find out the IP address of your virtual machine: ifconfig eth0
  16. Enter the following command on your virtual machine to create a firewall exception to allow ssh traffic into the machine: iptables -I INPUT -p tcp -s0/0 -d0/0 --dport 22 -j ACCEPT
  17. Confirm that you can ssh to your virtual machine from the host (your main Fedora installation): ssh IPaddress

Investigation 2: Installing from the Network

Idea.png
Authenticate to the network
The rest of this lab uses network access. Be sure to authenticate to the network using your browser before proceeding.

Introduction

It is possible to install Fedora entirely from the network. In this investigation, you will install Fedora from a webserver on Seneca's LAN.

VM details

Steps

  1. Create the VM as you did with the fedora1 virtual machine, except:
  2. Observe the boot process. How is it different from booting from an optical disc (CD/DVD)?
  3. Start the installation process. When you get to the disk partitioning step, enable the checkbox labelled Review and modify partition layout. On the next screen, change the logical volumes as follows:
    • Reduce the size of the root LV to 8000 MB.
    • Add a logical volume with a size of 2000 MB and a mountpoint of /home (you can name it whatever you want, and use ext3 or ext4 as the filesystem type).
  4. On the software selection screen, select Graphical Desktop.
  5. On the same screen, select the "Fedora 13 - x86_64" and the "Fedora 13 - x86_64 - Updates". Leave "Installation Repo" selected. DO NOT enable the "Test Updates" repository.
  6. Complete the installation. Record the time taken to install, and compare this to the time taken by the previous installations.

Investigation 3: Installing from the Network using Kickstart

Introduction

When Fedora is installed using the techniques you have used so far, the user is asked a number of questions. In some situations, it is better to provide the answers to these questions in a file rather than answer them individually. This type of file is called a kickstart file.

In this investigation, a kickstart file is provided for you. You can also create or modify a kickstart file using a regular text editor or a graphical tool.

VM details

Steps

  1. Create the VM as you did with the fedora2 virtual machine, specifying a network install as before, except:
  2. Observe the installation. How is it different from booting from an optical disc (CD/DVD)?
  3. Complete the installation. Record the time taken to install, and compare this to the time taken by the previous installations.
  4. What happens when the installation is finished?
  5. Take a look at the kickstart file (using the URL you entered) to determine the root password as well as the name and password for the first user account.
  6. Boot the virtual machine and log in (use the user ID and password information from the previous step). Compare the experience to the first time you booted the other virtual machines.

Investigation 4: Updating and Comparing the VMs

  1. In each VM, run this command: yum update
  2. Record the answers to these questions in your log book:
    • How long did it take to run on each VM? How many packages were updated?
    • Why does it take longer in some VMs than others?

Complete the following table:

f13host fedora1 fedora2 fedora3
Installation Method Installation Disc Live Disc Network Installation Network Installation + Kickstart
Packages Installed
Updates Installed immediately after installation
Software could be selected during installation
Disk layout could be selected during installation
No questions asked during installation
Total installation time (after installation questions)
Amount of disk space used
Questions asked during first boot
Advantages of this type of installation
Disadvantages of this type of installation
This type of installation is recommended for...

Investigation 5: Managing Virtual Machines from the Command Line

Note.png
Manage virtual machines from the host
The commands used to manage virtual machines must be executed on the host (your disk pack) and not inside a virtual machine.
  1. Start the fedora1 virtual machine, and stop the fedora2 and fedora3 virtual machines.
  2. Enter these commands and note the result:
    • virsh list
    • virsh list --all
    • virsh list --inactive
  3. Start the fedora3 virtual machine from the command line: virsh start fedora3
  4. Repeat the commands from step 2 and notice any changes.
  5. Stop the fedora3 virtual machine: virsh shutdown fedora3
  6. Confirm that fedora3 has been shut down.
  7. Execute this command: virsh dumpxml fedora3 >fedora3.xml
  8. Examine the file fedora3.xml. What does it contain? What format is it in?
  9. Edit the file fedora3.xml, making the following changes:
    • Change the name to fedora3a
    • Change at least one of the hexadecimal characters in the UUID. Do not change the length of the UUID. Valid hexadecimal characters are 0-9 and a-f.
  10. Issue this command: virsh define fedora3a.xml
  11. Issue the command virsh list --all and record any changes.
  12. Issue the command: virsh undefine fedora3a
  13. List all of the virtual machines again, and note any changes.

Investigation 6: How do I backup a virtual machine?

  1. Shut down all of the virtual machines.
  2. Change to the directory /var/lib/libvirt/images/. Note the size of the files in this directory. What do these files contain?
  3. Make a compressed backup of the fedora3.img file with this command: gzip <fedora3.img >fedora3.img.backup.gz
Stop (medium size).png
Make sure the backup is successful!
If there are any error messages, DO NOT proceed past this point. You're going to destroy your fedora3 virtual machine and restore it using the backup you have created -- if there are any problems with the backup, you will not have a working virtual machine, and will have to re-install it.
  1. Compare the size of the compressed and original files.
  2. Start the fedora3 VM.
  3. Make certain that you are in your fedora VM, and not in your Fedora main system.
  4. Wreck only your fedora 3 system! Try this command inside the fedora3 virtual machine (DO NOT do this on your main Fedora system, or you will have to repeat your lab2 and portions of your lab3!): rm -rf /*
  5. Shut down the VM.
  6. Restore the original image from backup (type this command carefully): gunzip <fedora3.img.backup.gz >fedora3.img
  7. Restart the VM. Is it working normally?
  8. Create compressed backups of your other virtual machines.
  9. Answer this question in your log book:
    • In order to fully back up a virtual machine, what information should be saved in addition to the virtual machine image?
  10. Write the answer to the Investigation 6 question in your lab book.
Important.png
Backing up VMs
It's a good idea to back up your VMs at the end of each lab, so you can easily restore them if something goes wrong in the next lab.
Idea.png
Shutting Down the Host while Virtual Machines are Running
If you shut down your host system while virtual machines are running, they will be suspended, and will resume the next time you boot your host system.

Investigation 7: Kickstart Files

Idea.png
SSHD and Firewall
If you have restarted your virtual machine fedora1, the sshd server you started in section 1-16 will no longer be running. In addition, the firewall will have reverted to its original state. In order to use scp, below, you will need to restart ssh and adjust the firewall again.

When you perform a non-Kickstart installation, the installation program creates a Kickstart file in the /root directory for reference.

  1. Obtain the kickstart files for all four of your installations (your disk pack f13host, plus the fedora1, fedora2, and fedora3 virtual machines). Copy them all to your f13host system (tip: use scp).
  2. Compare these files. What are the differences? Similarities? (Tip: you may want to use tools such as sdiff to help with the comparison).
  3. How could you use the kickstart file produced by the installation program to perform additional, identical installations?

Completing the Lab

Important.png
Important!
Arrange evidence of each of the following items on the screen, and then ask your professor or lab monitor to check them:
  1. Three working virtual machines created.
  2. Four kickstart files.
  3. All virtual machines fully updated.
  4. All virtual machines backed up.
  5. Installation comparison table filled in.

Preparing for the Quizzes

  1. What is the name of the Fedora installation program?
  2. Which factors recorded in your table (above) were due to the type of installation performed, and which factors were due to the amount of software installed?
  3. Which type of installation works best for confirming compatibility with hardware before installation? Why?
  4. Which type of installation works best for installing large numbers of computers? Why?
  5. What factors affect installation time?
  6. How can you reduce the number of software updates required immediately after installation?
  7. Why would you enable additional repositories during installation?
  8. What does the file /root/anaconda-ks.cfg contain, and how is it created?
  9. How do you start and stop virtual machines?
  10. How do you SSH into your virtual machines?
  11. What is the purpose of and relationship between these pieces of software?
    • libvirt
    • libvirtd
    • virsh
    • virt-manager
    • virt-install
    • vncviewer
    • kvm