OPS705 Lab 3 (2211)

LAB PREPARATION

Purpose / Objectives of Lab 3

In this lab, you will practice working with the Linux command line by manipulating the file system in two separate investigations. You will also update your system and create a secondary user.

If you encounter technical issues, please contact your professor via e-mail or in your section's Microsoft Teams group.

Minimum Requirements

Before beginning, you must have:

1. Successfully completed Lab 2
2. Watched the Week 3 video lecture
3. Read through the Week 3 slides, and have them handy as a reference for concepts
4. Your Seneca login credentials

INVESTIGATION 1: Update Linux

This investigation simply has you update your Red Hat Enterprise Linux (RHEL) installation. We'll cover package / software management and security best practices in a later lab.

Updating the OS, by its very nature, changes the system. Any command or utility that performs system-wide changes can only be run by a system administrator. Remember that.

To update the operating system, you'll need to have administrative access. There are two ways to do this: logging in to an admin account, or running a command as your regular user with temporary admin powers. We call this privilege elevation or elevating your privileges. Only regular user accounts that belong to the admin group can do this. The name of the admin group changes depending on the distribution of Linux; for RHEL, it's the wheel group. The ec2-user account you use was automatically added to this group as part of the AWS deployment process.

First, let's login:

1. Start your Linux VM in AWS (this may take a few minutes)
2. Connect to the VM remotely via SSH using your ec2-user account. (Refer to Lab 2)

Now, let's update the system:

• Here's the update command for this distro: yum update

Running this as a regular user will give you an error. To temporarily elevate your privileges for the duration of a command, type sudo before said command.

• For example: sudo yum update

Normally, the shell environment will ask you for your account password as an extra security precaution. However, cloud-based Linux VMs typically have password-less sudo access. The idea is that identity management and security is handled by the cloud infrastructure. We'll explore that in detail next week.

There will likely be further interaction for this update command, mostly asking you to confirm an action. For updates, you can type y and hit Enter safely. That said, do get in the habit of reading warnings and when it asks for your confirmation.

The update command will look for updates, download the install files, and then update the system. Most updates don't require a restart (unlike Windows!), except for kernel updates. The kernel is the very basic building block of the system; sort of the heart. It's responsible for many of the most basic functions a computer performs. If a kernel update is installed, you need to restart the system to use the new kernel. As this is your first update, you'll likely have a kernel update.

• When complete, restart the system with the following command: sudo reboot

You'll be disconnected from your remote session as the SSH server inside your VM shuts down.

It may take a few minutes for the VM to restart. You can track it's progress through the EC2 Instance page. Once back up and running, log back in to confirm everything still works.

INVESTIGATION 2: Adding A New User

In this investigation, we'll create a second user on your Linux VM from the command line, using your Seneca username. This is a required first step before continuing with the lab. Replace yourusername with your Seneca username in each command. (For example: If your e-mail address is cjohnson99@myseneca.ca, your Seneca username is cjohnson99)

To begin:

1. Start your Linux VM in AWS (this may take a few minutes)
2. Connect to the VM remotely via SSH using your ec2-user account. (Refer to Lab 2)
3. To create your second user, run: sudo useradd -G wheel yourusername
4. Assign a password to this account: sudo passwd yourusername (The session will ask you for your new password twice as a security precaution. When you type passwords on a Unix/Linux OS, the cursor remains blank and doesn't move. Just type it out carefully and hit Enter. It may take you a few tries the first time. You'll get used to it.)
5. Login to your new account: su - yourusername (Warning: Do not skip this step!)

Now, let's copy authentication information to your new account so you can log in directly next time.

From your secondary yourusername account:

1. Copy the authorized key file and its folder with this command: sudo cp -r ~ec2-user/.ssh ~/ (It may ask for a password. Use the secondary user account password you just set up.)
2. Change the new file's ownership: sudo chown -R yourusername:yourusername ~/.ssh
3. Now, completely log out back to your local system. Type exit and press Enter to get back to your ec2-user account. Then, type exit and press Enter again to fully log out.
4. From your local machine, use the SSH command to login, but replace ec2-user before the @ symbol with yourusername. It should log you in directly! Use that new account for the rest of this lab.

INVESTIGATION 3: Create the Directory Structure

Figure 1. Square icons are directories, oval icons are empty text files.

In this investigation, you'll create the directory structure and text files you see in the tree diagram below. You will do so entirely on the command line using the utilities and commands provided to you in the Week 3 lecture.

You work will be done entirely in your secondary user's home directory.

WARNING: Only use sudo when instructed by the lab.

To begin:

1. Connect to the VM remotely via SSH using your secondary account.
2. Navigate to your home directory with this command: cd ~
3. In your home directory (/home/yourusername), recreate the directory tree in Figure 1. (yourusername should be your own username home folder that already exists.)

INVESTIGATION 4: Moving Files

In this investigation, you're tasked with moving a set of existing files. You will download and run a script, which will create a set of files in ~/tmp. It is then your job to create the directory structure seen in Figure 2, and move the files from ~/tmp to their proper location according to the file tree diagram. Do not delete and recreate files, and do not delete your work from Investigation 1.

Figure 2. Square icons are directories, oval icons are text files.

1. On your Linux VM, install wget: sudo yum install wget
2. From your user's home directory (/home/yourusername), download script for this lab with the following command: wget https://ict.senecacollege.ca/~chris.johnson/ops705/lab3_script.bash
3. Give the script execute permissions: chmod u+x ~/lab3_script.bash
4. Run the script: ~/lab3_script.bash
5. Check that the files 13-17 have been created in ~/tmp (These must come from the script, do not create them yourself)
6. Using Figure 2 as a model, create the ~/shared directory structure
7. Using Figure 2 as a model, move the files from ~/tmp to their proper location in ~/shared

Voila, you're done!

Lab Submission

Submit to Blackboard's Lab Submission section full-desktop screenshots (PNG/JPG) of the following:

1. From your secondary user's home directory (/home/username), run tree. Your screenshot should contain the entire output. (To install tree, run: sudo yum install tree)
2. Run the following command and screenshot: hostnamectl

Your professor will review your VMs directly; the screenshots are a backup in case of catastrophic issues.

Your professor will not check your lab until the screenshots have been submitted.

Make sure to fully stop your VM when you're done!