Open main menu

CDOT Wiki β

Changes

OPS335 Lab 1

419 bytes added, 15:39, 3 January 2014
Updated lab for Winter 2014 semester. Move the installation parts to lab 0, added in some simple content for managing users and services.
[[Category:OPS335]][[Category:OPS335 Labs]]
{{Admon/important|Course Updates| This lab has being modified significantly for the Winter 2014 semester, what you see here is now out of date.}}
==Configuring a Linux Gateway==
This lab will show introduce you to some skills you will be using for the rest of the course (and your career). You will edit files to change how your system works, and to set up configure a simple intranet using one Fedora PC as a gatewayservice. The same Fedora PC You will be also use systemd to manage when a host for a small group of Fedora 17 VM's (Virtual Machine) which service runs. This will act as PC's inside an occur in the simple intranetyou set up in the previous lab. Here is a diagram of your setup.<br /><br /><center>[[Image:lab01.png]]</center>{{Admon/important|Requirement - Lab 0|Lab 0 should must be completed and before you should have a copy of Fedora 17, x86_64 LIVE ISO Imagecan begin this lab.}}
==Instructions==
===Managing services using systemd===
Before you start, if you are more familiar with the chkconfig or service commands, you may wish to review the [http://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet SysVinit to Systemd Cheatsheet].
Boot up your Fedora 17 x86_64 Centos host 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
*Now boot up your VMs, log in, and update them too. *You will want to be able to communicate with your machines using ssh.**Check the ip address of the virtual machine by running the following command on each one. ip address show*Start your the ssh serverservice on the virtual machine. Also set the service to start automatically when the machine boots.
service sshd start
Redirecting to /bin/systemctl start 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 <code>'systemctl'</code>, the command executed was <code>'systemctl enable sshd.service'</code>. A symbolic link was created as well, explain its purpose in your lab book.
*Install *Use ssh to connect from your host to the virtualization software yum groupinstall virtualizationvirtual machine.*Start **You will be prompted to store the libvirt daemon using <code>virtual machine'systemctl'</code> systemctl start libvirtds identification. Choose yes.service*Enable libvirtd This allows your machine to start at boot using <code>store a 'systemctlfingerprint'</code>of the machine you are connecting to. From now on, when you connect to that machine, it will compare the fingerprint you have stored to the one available on that machine. systemctl enable libvirtdIf you connect to a machine and that fingerprint has changed, it is often an indication that something has gone wrong.service*In order for *Reboot the virtual machine and check the installation status of virtualization on your machine to take effect, you will need to restartssh service.
* You may occasionally encounter services that have not yet been moved to Systemd. In those cases Systemd will redirect the command to the appropriate older method. e.g.
systemctl enable serviceNameexample.service serviceNameexample.service is not a native service, redirecting to /sbin/chkconfig. Executing /sbin/chkconfig serviceName example on
Warning: unit files do not carry install information. No operation executed.
===How to change the default runlevel using systemdTesting Connectivity ===Fedora 17 does not use '/etc/inittab*Edit each of your VM' s to set the default run level but rather uses targets as use a more flexible replacementstatic IP address. Note VM01 should use the output of first available address in the subnet, VM02 the second and VM03 the following command:third. ll /etc/systemd/system/*.target lrwxrwxrwx. 1 root root 36 Dec 3 09:35 /etc/systemd/system/default.target -> /lib/systemd/system/runlevel5.targetand ll /lib/systemd/system/*.targetSystemd uses symbolic links to point to This should be done using the default runlevel in use. To change the default runlevel you must first remove the existing symlink. rm /etc/systemd/system/default.targetTo change your system to boot in Graphical mode by default: ln -s /lib/systemd/system/graphicalcommand line on all 3 virtual machines.target /etc/systemd/system/default.targetMake 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 3files used and entries required. === Create your personal network ===Observe *Restart each VM and record the output of run the following command:to ensure they have the IP address you set. iptables -t nat -LStart Virtual Machine Manager through GnomeDo not continue until they keep the address you set.*Click on 'Activities' -> 'Applications' -> System Tools' -> 'Virtual Machine Manager' ip address show*You will need to enter Test connectivity by pinging each of your root passwordVM's.*As you will be using this tool very regularly, you may wish Try to drag ssh from the icon guest to the bar on host machine, then from the left. This will make it easier host to access in the futureguest.Create your own Virtual Network*Right click 'localhost (QEMU)' and select 'Details'. Click on the 'Virtual Networks' tab.*Stop and delete Both should fail with the error message 'defaultNo route to host' network.*Use As root, run the plus sign to add a new virtual network using following command on each machine (which will modify the following options.firewall so it accepts incoming ssh connections):**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 iptables -I INPUT -p tcp --000dport 22 -0<b>90</b>, the network address would be 192.168.<b>90</b>.0/24.j ACCEPT**Ensure Try to ssh from the DHCP range will allow you host to assign at least 3 static IP addressesthe guest machine again. It should work now.**Choose We won'Forwarding to physical network' radio buttont save your firewall rules for now, as we'Destination: Any physical device' and 'Mode: NAT'**Ensure the network is started at bootll be making a permament set of rules next lab.
Once completed open *Try to ping matrix and google from your host machine. Record the ip address of each.*Try to ping matrix and google (using their ip addresses) from each of your VM's to ensure you can reach the outside world (you will need to be authenticated to the network on your host machine).**If your VMs can not ping external machines, use the following command to examine their routing information. ip route show*If you did not give the VMs a default route when you gave them a terminal static IP address, they don't know where to send packets in order to get outside the network.*Add your host's IP address (192.168.x.1) as the default route.*Again try to ping matrix by its ip address.**It should now work.*Try to ping matrix by name, and observe it should fail.**Your virtual machines do not know how to turn the hostname matrix.senecac.on.ca into the ip address.**While they had dhcp addresses your host was telling them where a DNS server was, but now that they have static addresses you need to configure that for them.**Edit /etc/resolv.conf, delete what's there and record enter this data instead. nameserver 142.204.1.2 nameserver 142.204.43.43*Note that this will go away when you reboot. We will cover how to set this permanently in a later lab.*Once you can ping matrix, try to ssh to your Matrix account from the output VMs.**It should work now.*Perform these steps on each of your machines so you can ssh between each VM and the host (and between the following command:VMs).*Try to ssh from your Matrix account back to your host.
iptables ===User management===*Find a partner for this step and create a user on your host machine that matches the user on their host.*Create a password for that user, but do not share it with your partner.*Have your partner run the following command on their host machine: ssh-keygen -t nat rsa*when you enter this command just hit ENTER for all the questions. Here's what I got when I ran it on my host Generating public/private rsa key pair. Enter file in which to save the key (/home/peter/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/peter/.ssh/id_rsa. Your public key has been saved in /home/peter/.ssh/id_rsa.pub. The key fingerprint is: f5:07:8c:aa:b6:08:e0:45:81:ca:d6:88:8c:aa:1a:7b peter@host.pcallagh.org The key's randomart image is: +--[ RSA 2048]----+ | o+++ | | E .ooo.. | | ...o. | | ...o .| | .S+ + o.| | . = . o .| | o + | | o + | | . . | +-----------------L+*When you run that command you generate both halves of a paired-key encryption scheme. In order to be able to log in to another machine without a password, each machine needs one half. You keep the private key (in this case id_rsa), and you give the public key (id_rsa.pub) to the machine you want to log in to.*Have your partner email you their public key.**Copy it into /home/<partner's user>/.ssh/authorized_keys on your host machine.*Have your partner attempt to ssh from their host to yours.**If they are prompted for a password, you have done something wrong. Make sure the path is correct, and that no one other than that user has write permission to their .ssh directory or the authorized_keys file (If anyone does, even that user's group, the ssh service will not consult that file).*Once they have successfully logged in without a password, use the usermod command to change their default shell to /sbin/nologin.**They should no longer be able to log in.*You can use this command to edit many other things about your users, including their home directory, the group they belong to, their user id, etc.
=== Installing the first guest machine Configuring a Service===With *A common, if somewhat blatant, way to try to hack into a machine is to try to ssh as root and brute-force the virtualization software installed and your personal network createdpassword.**The root user always exists, you meaning the attacker doesn't need to try guessing what user names are now ready to create on your first "Virtual Machine"system. Use the Fedora 17 x86 64 bit disk **And if they can get access to installroot, or download an iso from Belmont (these links will only work at schoolthey can do anything.*To prevent this, but installing we'll edit the configuration file for the ssh service to prevent root from an iso saved on disk will be much faster than using a cd)ssh'ing into your host machine. wget http:*Use cat to display /etc/belmont.senecac.ssh/sshd_config onyour host.ca/fedora/releases/17/Live/x86_64/Fedora-17-x86_64-Live-Desktop*This file contains the configuration parameters for the ssh service.iso *Lines that begin with # are comments. Either simple explanations of parameters, orparameters that have not been set. wget http://belmont.senecac.on.ca/fedora/releases/17/Live/x86_64/Fedora-17-x86_64-Live-KDE.iso*Open the man page for sshd_config*Click on *This lists all the icon "Create possible parameters in alphabetical order along with a new virtual machine" to beginbrief explanation of what each one does.*Name your machine "f17-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 *The parameter we are looking for Version select "Fedora 17" then click on the "Forward" buttonis PermitRootLogin, read its description.*Use the default memory and CPU options for use with lab computers an editor (Depending on available hardware these settings can be adjustede.g. vi). Then click on to open /etc/ssh/sshd_config, and find the "Forward" button to proceedline that has PermitRootLogin.*Leave the disk image size *By default it is set at 8GB, ensure "Allocate entire disk now" is checkedto yes, then click on allowing the "Forward" button.*At the "Ready root user to begin installation" window click on 'Advanced options' arrow ssh in to review available optionsthe machine.**Select the Virtual Network named 'ops335'. Make note of any other available optionsUncomment it, and change it to no.*Select 'Install Now try to Hard Drive' to begin use ssh from one of your Fedora installation. Select the appropriate default options (You may wish VMs to review log into your OPS235 notes to remind yourself what these are)host as root.***Set your hostname You'll still be able to "vm01.localdomain".{{Admon/important|Firstboot - First user created|For successful completion of This is because (for most services) the changes you make to the labs, please ensure configuration file do not take effect until the first user created is named using your Learn IDservice restarts.}}During Firstboot create a user with the same name as your learn ID as **Restart the first user created sshd service on your host machine. This is important and try to ensure future labs workssh in again. Now login and open it should prevent you.*The configuration files for most services follow a terminal windowvery similar format. Switch Some use an = between the parameter and its value, some require you to root group certain parameters together, and update your VM guest machine yum updateThis could take most use # to be a long time and you should reboot after it's donecomment. Ensure your VM guest has internet access host cbcYou will get lots of experience working with the configuration files for services in this course.ca
===Minimizing your VM's footprint===
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 graphical or runlevel 5.
Test your VM to make sure that it boots correctly before moving on to the next step.
== Completing the Lab ==
In completing this lab you have started gaining experience with some of the skills you need to be successful in this course, and as a future system administrator. You have started to manage what a service does and how it works. You have worked with a configuration file, and tested to make sure that the changes you wanted took effect.
===Managing a Service===
*Before you start, if you are more familiar with the chkconfig or service commands, you may wish to review the [http://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet SysVinit to Systemd Cheatsheet].
*You will want to be able to communicate with your machines using ssh.
**Check the ip address of the virtual machine
ip address show
**Start the ssh service on the virtual machine. Also set the service to start automatically when the machine boots.
**Use ssh to connect from your host to the virtual machine.
***You will be prompted to store the virtual machine's identification. Choose yes (we will cover this in more detail later).
**Reboot the virtual machine and check the status of your ssh service.
 
== 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, then from the host to the guest.
**Both should fail with the error message 'No route to host'.
*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.
**This should also fail with the error message 'No route to host'.
*First, backup your existing firewall rules
iptables-save > /etc/sysconfig/iptables.backup
*As root, run the following command (which will modify the firewall so it accepts incoming ssh connections):
iptables -I INPUT -p tcp --dport 22 -j ACCEPT
*Try to ssh from the host to the guest machine again. It should work now.
*Now 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 again, to make certain it still works.
*Perform these steps on each of your machines so you can ssh between each VM and the host (and between the VMs)
 
*Edit each of your VM's to use a static IP address. VM01 should use the first available address in the subnet, VM02 the second and VM03 the third.
**This should be done using the command line on all 3 virtual machines. Make note of the files used and entries required.
**Ensure connectivity from all VM's after the change.
== Completing the Lab ==
Answer the following questions in your logbook.
 
#How can you tell if a service is native or non-native to 'systemd'?
#Explain the iptables rules displayed when you ran the command 'iptables -t nat -L'. How did they differ after creating your personal network.
Peter.callaghan
932
edits
Retrieved from "https://wiki.cdot.senecapolytechnic.ca/wiki/Special:MobileDiff/103101"