[[Category:OPS335]][[Category:OPS335 Labs]]=Basic network configuration =Configuring a Linux Gateway==This lab will 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 configure a service. You will also use systemd to manage when a service runs. This will occur in the simple intranet you 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 must be completed before you can begin this lab.}}

==Instructions=====Managing services using systemd===Before Remember how you start, if you are more familiar with set up the chkconfig or service commands, you may wish network interfaces in your virtual machines in OPS235? You're expected to review know that inside out by now. All the [http://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet SysVinit to Systemd Cheatsheet].Boot up your Centos host system, login with your learn id and use Firefox to authenticate yourself on SENEnet services we're configuring in this course require a working network connection so it will be hard for 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 get anything done if you don't know how to date yum update*Now boot up set a static IP address or change your VMs, log in, and update them tooDNS server or default gateway.

*You will want to be able to communicate with your machines using ssh.**Check the ip address This lab is a crash course of the virtual machine by running the following command on each one. ip address show*Start the ssh service on the virtual machine. material from Also set the service to start automatically when the machine boots. service sshd start*Notice that your command was redirected to <code>'systemctl'</code>, the command executed was <code>'systemctl start sshd.service'</code>. Record this in your lab book.*Enable sshd to start at boot chkconfig sshd on*Again notice your command was redirected to <code>'systemctl'<labs 6 and 7 from [http:/code>, the command executed was <code>'systemctl enable sshd.service'</code>.**Use ssh to connect from your host to the virtual machine.***If you have not used ssh to connect to this machine in the past, you will now be prompted to store the virtual machine's identification. Choose yeszenit. This allows your machine to store a 'fingerprint' of the machine you are connecting tosenecac. From now on, when you connect to that machine, it will compare the fingerprint you have stored to the one available on that machine. If you connect to a machine and that fingerprint has changed, it is often an indication that something has gone wrong.**Reboot the virtual machine and check the status of your ssh 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 example.service example.service is not a native service, redirecting to ca/sbinwiki/chkconfigindex. Executing /sbinphp/chkconfig example on Warning: unit files do not carry install information. No operation executed.OPS235_Weekly_Schedule_-_CentOS7 OPS235]

==Check current settings = Testing Connectivity ===*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.*Restart each VM and run the following command to ensure they have the IP address you set. Do not continue until they keep the address you set. ip address show*Test connectivity by pinging each of your VM's.*Try to ssh from the guest to the host machine, then from the host to the guest. *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 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 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 enter this data instead. nameserver 142.204.33.53 nameserver 142.204.33.54*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 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 VMs).*Try to ssh from your Matrix account back to your host.

===User management===*Find a partner for this step In OPS235 you've used the ifconfig and create a user on your host machine that matches the user on their hostroute commands.*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 rsa*when you enter In this command just hit ENTER for all the questions. Herecourse we's what I got when I ran it on my host Generating public/private rsa key pair. Enter file in which to save ll use 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 + | | . . | +-----------------+*When you run that ip 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 instead (in this case id_rsa), and you give the public key (id_rsa.pub) 're welcome to use the machine old commands but you want to log in to.*Have your partner email you their public key.**Copy the contents into /home/<partner's user>/.ssh/authorized_keys on your host machine.***You may have to create that file if it does not already exist.*Have your partner attempt to ssh from their host re expected to yours.**If they are prompted for a password, you have done something wrong. Make sure know 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 filenew ones too).*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.

===Configuring a Service===*A common, if somewhat blatant, way to try to hack into a machine is to try to ssh as root To get the IP address and brute-force subnet mask for all the password.interfaces:**The root user always exists, meaning the attacker doesnOld: '''ifconfig'''t need to try guessing what user names are on your system.**And if they can get access to root, they can do anything.New: '''ip address'''*To prevent this, we'll edit the configuration file for the ssh service to prevent root from ssh'ing into get your host machine.default gateway:*Use cat to display /etc/ssh/sshd_config on your host.*This file contains the configuration parameters for the ssh service.Old: '''route -n'''*Lines that begin with # are comments. Either simple explanations of parameters, or parameters that have not been set.*Open the man page for sshd_configNew: '''ip route'''**This lists all the possible parameters in alphabetical order along with a brief explanation of To check what each one does.DNS server you're using:**The parameter we are looking for is PermitRootLogin, read its description.*Use an editor (e.g. vi) to open /etc/ssh/sshd_config, Old and find the line that has PermitRootLoginnew: '''resolv.conf'''**By default it is set to yes, allowing the root user to ssh in to the machine.To check your hostname:**Uncomment it, Old and change it to no.*Now try to use ssh from one of your VMs to log into your host as root.**Younew: '''uname -n'''ll still be able to. This is because (for most services) the changes you make to the configuration file do not take effect until the service restarts.**Restart the sshd service on your host and try to ssh in again. Now it should prevent you.*The configuration files for most services follow a very similar format. Some use an = between the parameter and its value, some require you to group certain parameters together, and most use # to be a comment. You will get lots of experience working with the configuration files for services in this course.

== Completing the Lab Make persistent changes ==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.

Each of your VMs should now boot to a command prompt (no graphical interface)For the IP address, subnet mask, default gateway, and should be using DNS server you edit a static IP address.file in '''/etc/sysconfig/network-scripts/'''

Exploration questionsYou'll need a file that describes the settings for a network interface. The association between a specific network interface and the configuration file is made using (from least to most important):#How can you tell if a service is native or non* The name of the file ('''ifcfg-native to 'systemd'?'interfacename)#How are ping and ssh affected (on both machines) when you run * The "NAME" setting inside the following command on file* The "DEVICE" setting inside the host machine?file#*echo 0 > /proc/sys/net/ipv4/ip_forward#The systemctl set-default command runs two commands for you. What option could be used to reduce this to a single command?#What parameters can be used to change the address that "HWADDR" setting inside the ssh service listens on? (hint: there are three).file

{{Admon== Set static IP addresses on vm1, vm2, and vm3 == Except for the host all the machines in this course will have static network configuration. That means you need to be able to perform said configuration and debug problems quickly. If the following steps aren't 100% clear - make sure to practice them. # 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.# Don't forget to set the default gateway and DNS server. You can use your host's IP address as a DNS server (libvirt will proxy the requests to the real DNS server).# Make note of the files used and entries required.# Restart each VM and run the following command to ensure they still have the network configuration you set.# Test connectivity by pinging each of your VMs.# Try to ssh from the guest to the host machine, then from the host to the guest. # 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. 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: # '''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.# '''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.# '''Do you have an IP address?''' Run '''ip address''' to check.# '''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.# '''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.# '''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 is a number of other problems that could prevent your network connection from functioning but the above are the most common ones. You should be able to go through the 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. = 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 [http://sebastien.saunier.me/blog/2015/05/10/importantgithub-public-key-authentication.html 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): [[Image:ssh_connection_explained.png|Time 800px]] 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): <source lang="bash">ssh-keygen -t rsa</source> 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: <source lang=bash>mkdir -p /backup/vm1rsync -avz 192.168.x.2:/etc /backup/vm1/</source> 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 successfully completed to insert a line like this: <pre>10 * * * * echo "Cron ran this job at: "`date` > /tmp/cron.log</pre> 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. = Completing the lab= * Each of your VMs should now boot to a command prompt (no graphical interface), make 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 new backup password.* Backups of the three VMs' /etc/ directories are made automatically in the host.* You have notes in your virtual machineslabbook about what you've learned in this lab.}}