Updated: 2014-04-12 22:32 EDT

1 Due Date and Deliverables

Do not print this assignment on paper!

2 Purpose of this Assignment

Do not print this assignment on paper! On paper, you cannot follow any of the hyperlink URLs that lead you to hints and course notes relevant to answering a question.

  1. Review the CST8207 Partitions and File Systems formatting commands from last term.
  2. Add disk space to your CentOS Virtual Machine in two ways:
    1. Add a filesystem
    2. Practice with LVM and grow a filesystem
  3. Practice with the smart rsync file transfer program.
  4. Recover from forgotten admin password of your CentOS Virtual Machine
  5. Recover from corrupted MBR of your CentOS Virtual Machine

3 Introduction and Overview

This is an overview of how you are expected to complete this assignment. Read all the words before you start working.

Do not print this assignment on paper. On paper, you cannot follow any of the hyperlink URLs that lead you to hints and course notes relevant to answering a question.

  1. Complete the readings in your weekly Class Notes.
  2. Complete the Tasks listed below, in order.
  3. Verify your own work before running the Checking Program.
  4. Run the Checking Program to help you find errors.
  5. Submit the output of the Checking Program to Blackboard before the due date.
  6. READ ALL THE WORDS to work effectively and not waste time.

You will create filesystem structure in your CLS home directory containing various directories and files. You will also make changes in your own Linux Virtual Machine running CentOS 6.5. You can use the Checking Program to check your work as you do the tasks. You can check your work with the checking program as often as you like before you submit your final mark. Some task sections below require you to finish the whole section before running the checking program; you may not always be able to run the checking program successfully after every single task step.

When you are finished the tasks, leave the files and directories in place on both the CLS and your own Linux Virtual Machine as part of your deliverables. Do not delete any assignment work until after the term is over! Assignments may be re-marked at any time on the CLS; you must have your term work available on the CLS right until term end.

Since we also do manual marking of student assignments, your final mark may not be the same as the mark submitted using the current version of the Checking Program. We do not guarantee that any version of the Checking Program will find all the errors in your work. Complete your assignments according to the specifications, not according to the incomplete set of mistakes detected by the Checking Program.

3.1 Searching the course notes

The previous term’s course notes are always available on the Internet here: CST8207 GNU/Linux Operating Systems I.

All the current and previous terms notes files are also stored on the CLS. You can learn about how to read and search these files using the command line on the CLS under the heading Copies of the CST8207 course notes near the bottom of the page Course Linux Server. The current CST8177 term notes are searchable there, too!

3.2 The CLS Source Directory

All references to the “Source Directory” below are to the CLS directory ~idallen/cst8177/14w/assignment10/ and that name starts with a tilde character followed by a userid with no intervening slash. The leading tilde indicates to the shell that the pathname starts with the HOME directory of the account idallen (seven letters).

You do not have permission to list the names of all the files in the Source Directory, but you can access any files whose names you already know.

3.3 Review of CST8207 partitioning and filesystems

Review your work from CST8207 GNU/Linux Operating Systems I:

3.4 Backup and Recovery on CentOS

  1. Take a snapshot of your virtual machine before you begin each section of this lab so that you can recover back to the snapshot if needed.
    • You can delete the unused snapshots if everything works well.
    • CentOS snapshots are very small and fast compared to your Windows snapshots; you can save lots of them.
  2. Are you keeping an external backup copy of all your coursework (including your virtual machines) somewhere? You should be!

3.5 Use a remote login, not the VMware console

I recommend that once you have booted your CentOS VM, you connect to it and work using a remote login session (e.g. ssh or PuTTY) where copy-and-paste works and where you can have multiple simultaneous connections into the VM. The VMware console is not friendly.

If you can’t get an SSH (PuTTY or ssh) connection working into your Linux VM, see the Network Diagnostics page.

Note that SSH sessions (and whatever you are doing inside them) do not survive across a VMware suspend. Make sure you save your editor files and exit your SSH session before you pause or suspend your virtual machine. (Editor sessions that run inside the VMware console do survive across suspend and resume, since they don’t depend on a network connection.)

Advanced users may look into the various virtual terminal programs such as tmux and screen that do allow you to suspend and resume your sessions even from a remote login.

4 Tasks

4.1 Set Up – The Base Directory on the CLS

  1. Do a Remote Login to the Course Linux Server (CLS) from any existing computer, using the host name appropriate for whether you are on-campus or off-campus.

  2. Create the CLS directory ~/CST8177-14W/Assignments/assignment10

  3. Create the check symbolic link needed to run the Checking Program, as described in the section Part II - Check and Submit below.

Run Part II - Check and Submit to verify your work so far.

4.2 CentOS: Snapshot

  1. Complete your CentOS Virtual Machine Installation and Verification.
    • Make sure it passes the checks for disk sizes and package counts.
    • Complete these critical system administration tasks required in Assignment #08 and Assignment #09:
      1. Create the sudoers group.
      2. Create your own personal sysadmin account.
      3. Install and configure the NTP package.
  2. Before you begin this assignment, create a snapshot of your CentOS Virtual Machine.
    • Enter a comment explaining where and when you took this snapshot.
    • You can restore back to this snapshot if anything goes wrong.

4.3 CentOS: Set Up – The Base Directory on CentOS

  1. In your own account in your CentOS Virtual Machine, also make the directory ~/CST8177-14W/Assignments/assignment10 (the same hierarchy as you have already made on the CLS).

This CentOS assignment10 directory in your sysadmin account is the base directory for all pathnames in this assignment. Store your CentOS files and answers below in this sysadmin base assignment10 directory.

Run the Fetch and Checking Program to verify your work so far.

4.4 CentOS: Add a second disk to your VM: sdb

You will add a second hard disk to your CentOS Virtual Machine, and partition it. The procedure for adding a hard disk to an actual physical computer is different only in the steps that take place while the machine is powered off. Any step carried out while the machine is running would be the same for physical machines as it is for virtual machines. The console of a physical machine is its actual keyboard and monitor, but in the case of a VM, the console is the VMware window of the machine.

Most of the system admin commands in this assignment access the raw disk and will require you to prefix the actual command name with sudo to gain root permissions (unless you are in single-user mode and therefore running everything as root). If you get “permission denied” errors, you forgot to use sudo.

  1. If your CentOS Virtual Machine is not already powered off, login and use the correct command to power off the virtual machine.
    • Never user the VMware Power Off button to kill power!
    • Never unplug a running Linux machine!
  2. With your CentOS machine still powered off, use the VMware Settings menu for your CentOS VM to add to your VM a virtual 10GB hard disk, accepting defaults for everything except the size. (You did similar work in CST8207 adding a VMware disk; review the notes.)

  3. After adding the new disk, power on your VM, then login as your system administrator user.
    • Recall that you cannot log in as root since the root account password is locked.
  4. Ensure the /proc/partitions file contains the second disk you added.
    • Verify that there is a second disk of the correct size:
      • The size of your second drive should be 10485760.
      • Divide: 10485760/1024/1024 to confirm the number of gigabytes.
    • Verify that no partitions are listed for the second disk.
    • If you have any sdb1 or sdb2 or other sdb partitions, this is not a new disk with no partition table. Get help.
    • Note the three-letter device name of the second disk.
  5. When the second disk is correct, copy /proc/partitions to file partitions_before.txt in your CentOS sysadmin base directory (6 lines, 20 words). Remember: all files should eventually be moved to under your sysadmin base directory on CentOS for marking.

  6. Verify that the three-letter device name for the second disk also exists under the /dev directory. Put a long (ls -l) listing of all names under /dev that start with the first two letters of the new disk name into file sd_all.txt in your base directory.
    • Do not change your current directory.
    • Use the absolute pathnames for the device names.
    • No pipeline or other command is needed.
    • The output should show the absolute paths of two disks, and two partitions in the first disk.
    • Hint

4.5 CentOS: Viewing and Creating Partitions: fdisk

  1. First, you must have added a new 10GB hard drive in VMware and rebooted, as described above. Log in to the machine.

  2. Run (always with root privileges) fdisk -cul /dev/sdb and make sure you see Disk /dev/sdb: 10.7 GB with no errors and no partitions listed under it.

    $ sudo fdisk -cul /dev/sdb
    Disk /dev/sdb: 10.7 GB, 10737418240 bytes

    If you don’t see 10.7 GB, then shut down, delete the disk, recreate the disk, and reboot until your 10GB disk install works.

Make sure you only change things on this new sdb disk in this section! The sda disk is your Linux ROOT disk; if you damage it you will need to recover back to your snapshot. Make sure you have a snapshot to go back to!

  1. In the man page for the fdisk command, locate and make a note of two option letters:
    • The option to “Switch off DOS-compatible mode. (Recommended)”
    • The option to “give sizes in sectors instead of cylinders”
  2. Run the command fdiskdevicename, where devicename is the absolute path of the device corresponding to the new disk under /dev. This will start the fdisk program, just as you did in CST8207 Fdisk Command.
    1. As fdisk starts, read the WARNING about DOS-compatible mode.
    2. This is a serious warning. Quit the fdisk program.
    3. Re-run fdisk command, this time inserting the two option letters you found in the man page. (Keep the same device name.)
    4. The WARNING should be gone when you start fdisk with those two options. Always use these two options on CentOS. (Other versions of fdisk use these options as defaults.)
    5. Display the partition table and verify that the disk you are working on is the 10GiBi disk with no partition table.
  3. Inside fdisk use the command to display the partition table and verify that the disk you are working on is the 10GiBi disk with no partition table. Use fdisk commands to partition the new disk as follows:
    1. First, make sure the new disk has no partitions configured. If you see partitions, you are using fdisk on the wrong disk. Make sure you use fdisk on the new disk device name!
    2. Create a 500MB primary partition as Partition 1 (notice that one of the options for specifying the last cylinder of a partition is +sizeM where size is the number of megabytes).
    3. Create an extended partition as Partition 2, consuming the rest of the disk.
    4. Create a 400 MB logical partition
    5. Create another logical partition consuming the rest of Partition 2.
    6. Save your changes.
    7. Notice whether fdisk tells you as it quits whether you need to reboot for the new partition table to take effect. Do what it says.
  4. Copy the new version of /proc/partitions (showing the new partitions you just created) to partitions_after.txt in your sysadmin base directory.
    • Also note that the new partitions now appear under the /dev directory.
  5. Use the diff command to find the differences between the old and new partitions_{before,after}.txt and redirect the results to partitions_diff.txt in your sysadmin base directory.

  6. Examine the differences file, and verify that your new partitions are the only differences. You should see four additional lines in the new partition file, corresponding to the four partitions you created:

    6a7,10
    >    8       17     512000 sdb1
    >    8       18          1 sdb2
    >    8       21     409600 sdb5
    >    8       22    9561088 sdb6

    If your numbers differ, perhaps you forgot to use the fdisk options that turn off DOS-compatibility mode and switch to using sectors instead of cylinders. Delete and start over.

4.6 CentOS: Migrate the /home directory to its own filesystem

You will create an ext4 filesystem on the primary partition of the new hard disk. Then, in single user mode, you will migrate the contents of the /home directory to that new filesystem. You will configure the /etc/fstab so that the new filesystem will be automatically mounted on /home, with the option for giving the users disk space quotas.

4.6.1 Install software packages

  1. Install the lsof package. RTFM to see what it does.

4.6.2 Make a new file system

  1. Take a snapshot of your CentOS VM.

  2. Run the command file -s /dev/somedevice to check the type of the device special file somedevice that corresponds to your new primary partition on your new disk. Because it has nothing on it, you should see nothing but unknown data:

    /dev/sdb1: data
  3. Create an ext4 filesystem on the only primary partition on the new disk.
  4. Again check the type of the device that corresponds to your new primary partition on your new disk. It should show an ext4 filesystem:

    /dev/sdb1: Linux rev 1.0 ext4 filesystem data (extents) (huge files)
  5. Also check the type of /dev/sda1 that has an active (in use) ext4 filesystem. Note the warning “needs journal recovery” indicating this filesystem is open and being modified:

    /dev/sda1: Linux rev 1.0 ext4 filesystem data (needs journal recovery) (extents) (large files) (huge files)
  6. Also check the type of /dev/sda2, that is not an ext4 filesystem.

4.6.3 Back up /home first

You are about to make a copy of all the files in the /home directory.

  • You will take the system down to single-user mode so that nobody is logged in and using any of the files you are going to copy. Normally you would give the users a few hours notice, but since you know nobody is using your machine you will shut down to maintenance mode now.
  • This is a serious operation, and a simple mistake could wipe out the entire /home directory. On a real system, you would run a full back-up before you attempted this. You don’t have a back-up system running on CentOS, but since the /home is small, you can create a tar archive.
  1. Close down any remote login sessions you are running into your CentOS machine. Exit all PuTTY and SSH connections. These connections will not work when you shut down to single-user, but they could leave processes running that might interfere with moving the /home directory.

  2. From the console (the actual VMware window, not a remote PuTTY or an SSH login that will be disconnected) take the system down to single user mode using shutdown now to do so. (Do not halt the machine!)
    • Review shutting down to single user in CST8207 Booting and GRUB.
    • Verify that you are in single-user mode by running the command that displays the system’s runlevel, which should show 1 S
    • Type whoami and confirm that you are always the root user when running in single-user mode. Be careful!
  3. Create a compressed tar archive of /home and save it under the HOME directory of the root account (which is not the ROOT directory) using the name home.tar.gz and use file to confirm that it is a compressed file:

    home.tar.gz: gzip compressed data, from Unix, last modified: ...
    The archive should contain everything under the /home directory.
    • An index should list over 120 pathnames, including almost 100 directories created by the newusers command in a previous assignment.
    • The compressed tarball will only be about 20K bytes, since most of /home is empty directories or duplicate files.

4.6.4 Copy the files

You will copy the files in /home to the new partition. First record the file names so you can make sure the copy works:

  1. Record a recursive, sorted listing of all of the pathnames of your /home directory using find /home | sort and redirecting the output to a file named home_before.txt in root’s home directory. Your file should contain more than 130 lines, one for each pathname in the /home directory.

  2. Ensure no processes are using the /home directory or any files under it, with lsof +D /home
    • Because /home is not yet a mount point, you need to use the +D option to include every directory under /home.
    • The command should give you no output if no process is using any file or directory under the /home directory.
    • Make sure there is no output! You are going to move /home.
    • If there are any processes using /home, you probably forgot to exit all remote sessions before going into single-user mode. Kill all the processes that are using /home.
    • (If the lsof command isn’t found, you missed an earlier step. Exit single-user to multi-user, install the package, and return to single-user.)

You must finish correctly the remaining steps in this section before you reboot, or your sysadmin account will be missing its HOME directory and you will get an error message about that when you log in. You must completely finish the remaining steps in this section correctly to regain log-in access to your sysadmin files in your HOME directory. Do not shut down or reboot your machine in this section, since the reboot will cause the /home directory to unmount and all your HOME directories, including the one for your sysadmin account, won’t work. You might want to take another snapshot here before you continue.

You can safely use VMware to PAUSE or SUSPEND your CentOS VM in the middle of this work, just don’t shut it down and reboot until you finish this section.

  1. You know from lsof that nothing is using the /home directory. Rename the existing /home directory to /old_home
    • Your sysadmin HOME directory is now invalid, since everything under /home has been renamed and is therefore missing.
    • Do not shut down or reboot your machine until you finish this section! See the warning above.
  2. Re-create a new empty /home directory that will be used as a mount point for the new filesystem you just created, above.

  3. Mount onto the empty /home directory the new 500 MB ext4 filesystem that you created earlier. (Review the mount command in CST8207 Partitions and File Systems.)

  4. Run the mount command and confirm that you can see /dev/sdb1 mounted on the /home directory. Do not proceed until this is true:

    /dev/sdb1 on /home type ext4 (rw)

    The df -h command will also show /dev/sdb1 mounted on /home, with approximately these sizes:

    Filesystem  Size  Used  Avail  Use% Mounted on
    /dev/sdb1   485M   11M   449M    3% /home
  5. Verify that there is a lost+found directory under /home now, because /home is now a file system mount point instead of just a plain directory. Do not accidentally delete this directory, or else the system won’t have a place to put orphan files! (If you delete it, read the man page for the mklost+found(8) command and recreate it.)

  6. Use the copy command with the archive option to copy the contents of the old /old_home directory to the new 500 MB /home filesystem.
    • Make sure that you copy the contents of /old_home into /home and do not copy the name /old_home in to /home!
    • After the copy, look inside /home and confirm that you do not see the old_home directory name there.
    • Make sure you do not delete the lost+found directory inside /home.
  7. Record the list of all pathnames in /home again, in the same way, sorted, except redirect the output into a new file home_after.txt also in root’s home directory.

  8. Record the differences between the two home_{before,after}.txt files, in a file named home_diff.txt also in root’s home directory. (The files should differ by exactly one line; the new HOME directory has one additional directory in it that wasn’t in the original. We’ve already told you what its name is.)

  9. Add a record to the /etc/fstab file so the new /home filesystem is mounted automatically, with default options and added quota options for both users (usrquota) and groups (grpquota).
    • Review CST8207 Partitions and File Systems for the format of /etc/fstab.
    • Use zero (0) for the sixth field (fsck pass number). (RTFM for fstab and note that using pass number 1 is reserved for the ROOT file system.)
  10. Use the mount command with the remount option to remount the /home filesystem according to the new options given in /etc/fstab
    • See man mount and look for the remount section under the -o flag (options).
    • If the mount command doesn’t read the new quota options from /etc/fstab, then you are specifying both the device and the mount point to the mount command, which means it won’t read the file to get the new options. Don’t do it that way.
    • If the mount command has other errors, do not continue. Fix it!
  11. Use the mount command to verify that /home is now remounted with the two quota options that you set in /etc/fstab:

    /dev/sdb1 on /home type ext4 (rw,usrquota,grpquota)
  12. Use su -l to temporarily become your sysadmin account and verify that your sysadmin HOME directory is valid and contains its usual files.i
    • Then exit your shell and return to the single-user shell.
    • If your sysadmin HOME directory is missing, do not continue. Fix it!
  13. Unmount /home and then mount it again, relying on the fstab to provide the device name:

    # umount /home  ;  mount /home  ;  mount

    You should see no errors, and mount should show /home mounted with the quota options again.

4.6.5 Tidy up

At this point you have verified that the new /home directory is working. Your system could be safely shut down and rebooted, but let’s clean up first.

  1. Return from single-user to runlevel 3 by typing exit at the single-user shell. The system will boot multi-user into the default run level.

  2. Log in using your account (you may use SSH again) and verify that you are in runlevel 3 by running the command that displays the system’s runlevel.
    • If your sysadmin HOME directory is missing, you skipped some steps above. Do not continue. Restore from a snapshot and try again.
  3. Normally, you would remove the /old_home directory, and everything beneath it to free up space on the / filesystem, reaping the rewards of moving the /home directory to its own filesystem; however, leave the /old_home directory in place for marking purposes. Do not remove /old_home.

  4. Move into your sysadmin base directory the tarball and all of the *.txt files you created in the home directory for root, and then change the owner and group of those files from root to yourself (your sysadmin user whose name is of the form abcd0001).
    • You may try, and fail, to use a shell GLOB pattern to move these files with sudo. Why? (Hint: Who is running the shell that is doing the GLOB expansion before executing sudo?)

Run the Fetch and Checking Program to verify your work so far.

4.7 CentOS: Add a third disk to your VM and partition it

You will add a third hard disk to your CentOS Virtual Machine, and partition it.

Remember to take snapshots often. You can delete the older snapshots if everything works.

  1. Use VMware to add a 2G hard disk to your virtual machine.
    • Follow the same method as you used when you added the second hard disk earlier in this assignment.
    • This will be its third hard disk.
  2. Ensure the /proc/partitions file contains the third disk you added.
    • Verify that there is a third disk of the correct size:
      • The size of your third drive should be 2097152.
      • Divide: 2097152/1024/1024 to confirm the number of gigabytes.
    • Verify that no partitions are listed for the third disk.
    • Note the three-letter device name of the third disk.
    • If you don’t see any disk, perhaps you aren’t reading all the words of the method you used when adding the second disk. Follow all the steps.
  3. When the third disk is correct, copy /proc/partitions to file partitions_LVM_before.txt in your sysadmin base directory.

  4. Verify that the three-letter device name for the third disk also exists under the /dev directory. Repeat the command you used to create sd_all.txt and redirect the new output into file sd_all2.txt (note the digit 2) in your sysadmin base directory. (See above for how you created sd_all.txt.)

  5. Partition the third disk as follows:
    1. If you see that WARNING message about DOS compatibility, you forgot to use the correct options. Start over.
    2. First, make sure the disk you are partitioning has no partitions configured. If you see partitions, you are using the wrong disk. Make sure you use the third disk device name!
    3. Create a primary partition as Partition 1 to occupy the whole disk.
    4. Save your changes.
    5. Notice whether it tells you as it quits whether you need to reboot for the new partition table to take effect. Do what it says.
  6. Copy the new version of /proc/partitions (showing the new partition you just created) to partitions_LVM_after.txt in your sysadmin base directory.
    • Also note that the new partition now appears under the /dev directory.
  7. Use the diff command to find the differences between the old and new partitions_LVM_{before,after}.txt and redirect the results to partitions_LVM_diff.txt in your sysadmin base directory.

  8. Examine the differences file, and verify that your new partition is the only difference. You should see only one additional line in the new partition file, corresponding to the single partition you created:

    11a12
    >    8       33    2096128 sdc1

    If your numbers differ, perhaps you forgot to use the fdisk options that turn off DOS-compatibility mode and switch to using sectors instead of cylinders. Delete and start over.

4.8 CentOS: Practice with LVM and grow a filesystem

You will use LVM capabilities and disk partitions to create the volume group VolGroup00 and the logical volume LogVol00 with an ext4 filesystem. Then you will extend VolGroup00 using the first logical partition on the first disk you added (the 400MB logical partition). Then you’ll grow the LogVol00 logical volume, and then you’ll grow the filesystem that resides on that volume. Each step of the way, you’ll record the state before, then after, and record the difference.

4.8.1 Create a PV, VG, LV, and file system

  1. Display the list of physical volumes (PV) on your VM with pvdisplay
    • No output should display.
    • If you get an error message about permissions, go back and re-read all the words in the paragraph above that starts with the words “Most of the system admin…”.
  2. Make the only partition on the third hard disk into a physical volume with the command pvcreatedevicename where devicename is the absolute path of the device name of the first (only) partition of the third disk.
    • You will see a warning message: dev_is_mpath: failed to get device for 8:33 which you may safely ignore.
    • You should see: Physical volume "/dev/sdc1" successfully created
  3. Run the command pvdisplay with one argument that is the absolute path of the device name, to show the attributes of this physical volume.
    • You should see: "/dev/sdc1" is a new physical volume of "2.00 GiB"
    • The PV name is /dev/sdc1
    • The VG name is blank
    • There are zero Total, Free, and Allocated PE (physical extents)
  4. Create a new volume group (VG) named VolGroup00, containing the /dev/sdc1 physical volume, with the command vgcreate VolGroup00 /dev/sdc1
    1. You should see: Volume group "VolGroup00" successfully created
    2. You can remove an incorrect volume group name using vgremove followed by the name.
  5. Run the pvdisplay command again with the same device name and verify that that physical volume (PV Name) now belongs to the VolgGroup00 volume group (VG Name).

  6. Run the vgdisplay command and verify that there are 511 Total PE and 511 Free PE (physical extents) totalling 2GiB.

  7. Create a new logical volume (LV) named LogVol00, occupying all the space of VolGroup00 with the command lvcreate -l 100%FREE -n LogVol00 VolGroup00
    1. There are two zero digits and no other digits in those names.
    2. You should see: Logical volume "LogVol00" created
    3. You can remove an incorrect logical volume name using lvremove followed by the name.
  8. Run vgdisplay again and verify that now the volume group has zero free physical extents; all the space is allocated.

  9. Run lvdisplay and find the LV Path of the logical volume you created. This is the name of the device on which you can make a filesystem, and it should be a pathname under /dev that includes your volume group name and your logical volume name.
    • Verify that you can use ls -l on this device name.
    • You will find that the LV Path isn’t actually a device; it’s a symbolic link to an actual device.
  10. Use ls -li on the absolute path of the actual LV device name (not the symbolic link) and redirect the output into file dm-0.txt in your sysadmin base directory. (The inode number must be included, and the type of the device must be b and not l.)

  11. Using the LV Path device name, create an ext4 filesystem on that device.

  12. As you did after creating the ext4 file system on the second disk, check the type of the actual LV device that corresponds to LV Path. It should show an ext4 filesystem:

    /dev/dm-0: Linux rev 1.0 ext4 filesystem data (extents) (large files) (huge files) 

    If you see symbolic link, you forgot to dereference the symlink to find the real device pathname.

  13. Create a mount point (an empty directory) named /mnt/lvm_fs to be used for the new ext4 file system.

  14. Mount the new LV Path ext4 filesystem on the /mnt/lvm_fs mount point.

  15. Run the mount command and confirm that you can see LV Path mounted on the /mnt/lvm_fs directory. Do not proceed until this is true:

    /dev/mapper/VolGroup00-LogVol00 on /mnt/lvm_fs type ext4 (rw)

    The df -h command will also show the same:

    Filesystem                       Size  Used Avail Use% Mounted on
    /dev/mapper/VolGroup00-LogVol00  2.0G   35M  1.9G   2% /mnt/lvm_fs
  16. Verify that there is a lost+found directory under /mnt/lvm_fs because it is a file system mount point.

  17. Record your LVM status by running these commands exactly as shown:
    1. Redirect the output of pvdisplay into a file named pv_before.txt
    2. Redirect the output of vgdisplay into a file named vg_before.txt
    3. Redirect the output of lvdisplay into a file named lv_before.txt
    4. Redirect the output of df -h into a file named df_before.txt

4.8.2 Create another PV, add it, and extend the file system

  1. Create another physical volume (PV), using the same method as you used for the first physical volume you created:
    1. Use the device name of the first logical partition on the second hard disk.
    2. file -s should say the partition is empty (shows data).
    3. When you create the volume, you should see: Physical volume "/dev/sdb5" successfully created
    4. file -s should now say the partition is LVM2 (Linux Logical Volume Manager)
  2. Display the attributes of that physical volume (using its device name), as you did before.
    • You should see: "/dev/sdb5" is a new physical volume of "400.00 MiB"
    • The PV name is /dev/sdb5
    • The VG name is blank
    • There are zero Total, Free, and Allocated PE
  3. Add the new physical volume to the VolGroup00 volume group, with the command vgextend VolGroup00 /dev/sdb5
    • You should see: Volume group "VolGroup00" successfully extended
  4. Display all the volume groups (only one) and redirect the output into vg_after.txt and then use diff to note the key changes with respect to vg_before.txt:
    • The Total PE are 610 up from 511
    • The VG Size is 2.38 GiB up from 2.00 GiB
    • The Free PE are 99 (396.00 MiB) up from zero
    • Take note of the Free PE value of 99
  5. Grow the LogVol00 logical volume to consume all the space you just added to its volume group, with the command lvextend -l+99 /dev/VolGroup00/LogVol00
    • The -l is a “dash el” option letter, not “minus one”
    • The 99 in -l+99 is the number of Free PE from above.
    • You should see: Logical volume LogVol00 successfully resized
  6. Display all the logical volume groups (only one) and redirect the output into lv_after.txt and then use diff to note the key changes with respect to lv_before.txt:
    • The LV Size is 2.38 GiB up from 2.00 GiB
    • The Current LE are 610 up from 511
  7. Display all the volume groups (only one) again and note:
    • The Alloc PE are now 610 (2.38 GiB) up from 511 (2.00 GiB)
    • There is now no free space left – it’s all in use by the logical volume group.
  8. With the /dev/VolGroup00/LogVol00 filesystem sill mounted on /mnt/lvm_fs, grow the ext4 filesystem to use all the free space on the underlying logical volume group by running the command resize2fs /dev/VolGroup00/LogVol00
    • You should see: Performing an on-line resize and The filesystem on /dev/VolGroup00/LogVol00 is now 624640 blocks long.
  9. As you did before, run the command that reports filesystem disk space usage (in “human” readable form) and redirect the output to df_after.txt and then use diff to note the key changes with respect to df_before.txt for the /mnt/lvm_fs file system:

    4c4
    < /dev/mapper/VolGroup00-LogVol00  2.0G   35M  1.9G   2% /mnt/lvm_fs
    ---
    > /dev/mapper/VolGroup00-LogVol00  2.4G   35M  2.2G   2% /mnt/lvm_fs

    There may be small changes in other file system sizes as well.

    You can see the mounted /mnt/lvm_fs file system has about 400 MB more space. The space was added without taking the machine down for maintenance. This is an important feature of LVM and ext4 file systems: They can be resized “live” without any down-time. If the Linux kernel supports disk hot-plug, you can even add disks to the machine without any down-time.

  10. Add a line to /etc/fstab to mount the volume group as shown above.
    • Review CST8207 Partitions and File Systems for the format of /etc/fstab.
    • Use zero (0) for the sixth field (fsck pass number).
    • After you succeed, this test must work without error: umount /mnt/lvm_fs ; mount /mnt/lvm_fs
  11. Record your LVM status by running these commands exactly as shown:
    1. Redirect the output of pvdisplay into a file named pv_after.txt
    2. Redirect the output of vgdisplay into a file named vg_after.txt
    3. Redirect the output of lvdisplay into a file named lv_after.txt
    4. Redirect the output of df -h into a file named df_after.txt

Run the Fetch and Checking Program to verify your work so far.

4.9 CentOS: Practice with rsync

The rsync command is an intelligent form of copy command that only transfers data if the data isn’t already there. You will practice using rsync between your CentOS VM and its loop-back network adapter, which we will call the Backup machine (even though it’s really the same machine). A trivial change to the remote host name lets you transfer files to any machine on the Internet that lets you run rsync.

The modern rsync command uses an underlying SSH protocol to actually transfer the data, so any configuration you have done for SSH (such as private keys, host aliases, or SSH agents) applies to rsync as well.

4.9.1 Create a backup account and directory

  1. Take a snapshot of your CentOS VM. You can never have too many snapshots.

  2. Log in to CentOS as your sysadmin account.

  3. Make sure your 2.4G LVM volume group is mounted on /mnt/lvm_fs
    • If you haven’t created and mounted this LVM volume group, create an empty directory named /mnt/lvm_fs instead.
  4. Create a new account user named backup with these options:
    1. The account should be a system account with a HOME directory
      • Remember the two options needed to create a system account and HOME directory. (Your sysadmin account used the same options when you created it.)
    2. The GECOS (comment) field should be set to be Backup Account
    3. The HOME directory should be set to be /mnt/lvm_fs/backup
      • You need to look up the option to do this; you have not yet used it this term (but did use it last term).
  5. Give the new backup account a really short password (because you will be typing it a lot in this assignment).
    • Tip: The root user can give an account a “too short” password if you persist:

      $ sudo passwd backup
      Changing password for user backup.
      New password: 
      BAD PASSWORD: it is WAY too short
      BAD PASSWORD: is a palindrome
      Retype new password: 
      passwd: all authentication tokens updated successfully.
  6. Verify your new backup account:
    1. Make sure this works without error: ssh backup@localhost id
      • The uid and gid shown should be less than UID_MIN and GID_MIN in /etc/login.defs
    2. Make sure this works without error: ssh backup@localhost pwd
      • The directory printed should be /mnt/lvm_fs/backup

4.9.2 Install the rsync package and test it

  1. Have you taken a snapshot recently?

  2. Install the rsync package.

  3. As a simple test, use rsync to transfer a single file to the Backup machine using the standard three archive, verbose, and hard-links options as follows:

    $ date >foo
    $ rsync -avH foo backup@localhost:
    1. Note the trailing colon (:) character after the host name in the destination pathname! Since nothing follows the colon, the same file name will be used on the remote machine.
    2. The three options -avH are standard sysadmin use for this command and are almost always used, just as sysadmin must always use the -p option to both cp and scp to preserve modes and times.
    3. You should see: sent 121 bytes received 31 bytes
    4. Confirm that the HOME directory of the backup account now contains an exact copy of file foo
      • Recall that the HOME directory of the backup account is not under the usual /home directory. Look in the right place.
    5. Confirm that the foo file in the backup account has exactly the same time and date as the one in your own account:

      $ sudo diff foo /mnt/lvm_fs/backup/foo
      $ sudo ls -l foo /mnt/lvm_fs/backup/foo

    The output of ls must show identical sizes, times, and dates. See your instructor if you can’t get this one-file transfer working.

  4. Repeat the exact same rsync command.
    1. You should see: sent 49 bytes received 12 bytes
    2. No file data will transfer, since the file is already there.
    3. The bytes exchanged are due to the rsync protocol.
  5. Touch foo and repeat the same rsync again.
    1. You should see: sent 92 bytes received 37 bytes
    2. Only the date of the file needed to be changed; the data is the same.
  6. Redirect a new date into foo and repeat the same rsync again.
    1. You should again see: sent 121 bytes received 31 bytes
    2. The whole file had to be sent again because the data changed.
  7. Remove the foo file and reverse the rsync to restore a local copy from the remote Backup machine:

    $ rm foo
    $ rsync -avH backup@localhost:foo .
    1. Note the trailing colon (:) character after the host name in the source pathname, followed by a relative pathname!
    2. Note the use of dot (.) to copy into the current directory as a destination pathname! The same file name will be used.
    3. The three options -avH are standard sysadmin use for this command and are almost always used, just as you must always use the -p option to both cp and scp to preserve modes and times.
    4. You should see: sent 30 bytes received 122 bytes
    5. Confirm that the file foo is restored into the current directory.

The rsync command only does the least amount of work needed to make the remote file or directory the same as the local one (or vice-versa).

4.9.3 Optional: Create an SSH host alias

Typing backup@localhost is too much work. You can shorten that.

  1. If necessary, create directory .ssh in your HOME directory and remove all permissions for group or other.

  2. Put the following four lines into file config in the above .ssh directory:

    Host backup back bk b
        Hostname localhost
        HostKeyAlias localhost
        User backup
  3. Remove all permissions for group or other from the config file.

  4. Now try these; all should work using the above SSH Host aliases:

    $ rsync -avH foo backup:
    $ rsync -avH foo back:
    $ rsync -avH foo bk:
    $ rsync -avH foo b:
    $ rsync -avH b:foo .

    You can now use the short SSH host and user alias b: instead of typing backup@localhost: as either a source or destination host name.

4.9.4 Back up your HOME directory

  1. Use rsync with the standard three sysadmin options to send your entire HOME directory to the Backup machine under remote directory test1.
    1. Always use the relative path on the remote machine.
    2. Use rsync with the added dry-run option so that you can see what pathnames are being copied. When the pathnames look correct (see below), remove the dry-run option.
    3. You may use the optional SSH host alias b: as part of the destination pathname, if you created it above, otherwise you need to use the full backup@localhost: name.
    4. As noted in your rsync course notes PDF, be careful how you specify the source pathname for your HOME directory. You must ensure that every local file /home/abcd0001/foo transfers to the Backup machine HOME directory as test1/foo and not as abcd0001/test1/foo. If rsync displays pathnames that begin with your userid, such as this:

      sending incremental file list
      created directory test1
      abcd0001/
      abcd0001/.bash_history
      [...etc...]

      then your source pathname is NOT correct. If you are not using the dry-run option, you have to remove the abcd0001 directory from the backup account and re-read your rsync course notes PDF. The pathnames transferred should look similar to this:

      sending incremental file list
      created directory test1
      ./
      .bash_history
      [...etc...]
      Only when the pathnames look correct should you remove the rsync dry-run option and actually transfer the files.
    5. Make sure there is no extra abcd0001 directory under the test1 directory in the backup account HOME directory.
    6. Compare a local file and a backed-up file to make sure they are the same, including the time and date:

      $ pwd ; echo ~backup
      /home/abcd0001/CST8177-14W/Assignments/assignment10
      /mnt/lvm_fs/backup
      $ sudo diff do.sh ~backup/test1/CST8177-14W/Assignments/assignment10/do.sh
      $ sudo ls -l do.sh ~backup/test1/CST8177-14W/Assignments/assignment10/do.sh
      Make sure the files are exactly the same. The output of ls must show identical sizes, times, and dates.
    7. Put the exact rsync command line you used into file rsync_home_test1.txt in your sysadmin base directory.

  2. Test that you can restore an existing file from the Backup machine to the /tmp directory on the local machine. Compare the tmp copy to the original file. The two files should be exactly the same, including the time and date:

    $ rsync -avH backup@localhost:test1/CST8177-14W/Assignments/assignment10/do.sh /tmp/foo
    $ diff /tmp/foo ~/CST8177-14W/Assignments/assignment10/do.sh
    $ ls -l /tmp/foo ~/CST8177-14W/Assignments/assignment10/do.sh
    • You may use the optional SSH host alias b: in the source pathname, if you created it above.
    • Pick some other existing file name if you don’t have assignment10/do.sh
    • If rsync says failed: No such file or directory then verify that the file exists where you think it should be under the test1 directory in the backup HOME directory.
    • Make sure the files are exactly the same. The output of ls must show identical sizes, times, and dates.
  3. Repeat the exact same rsync command to the test1 directory that you did in Step 1 above and that you saved in the rsync_home_test1.txt file: sh rsync_home_test1.txt
    1. Always use the relative path on the remote machine.
    2. Almost no file data will transfer, since almost all the files are already there. (Your new rsync_home_test1.txt file should be the only file that has changed.)
    3. Look for a speedup is line at the bottom of the rsync verbose output that tells you how much faster it was to compare files and not have to transfer any of the files that were already there.
  4. Change to your sysadmin base directory. (Perhaps you are already there?)

  5. In your sysadmin base directory, touch your existing rsync_home_test1.txt file and repeat the full HOME directory backup again.
    • Again, note that only that one file is selected for transfer.
  6. In your sysadmin base directory:
    1. Copy rsync_home_test1.txt to rsync_base_test1.txt
    2. Use rsync with the dry-run option to attempt to update just the current sysadmin base directory (not your whole HOME directory) to the corresponding remote sysadmin base directory on the Backup machine.
      • Always use the relative path on the remote machine.
      • The source pathname to rsync must be simply . (the current, sysadmin base directory) not your HOME directory.
      • If you get the command correct, rsync will propose to update only one single file to the remote machine – the new rsync_base_test1.txt file.
      • If rsync proposes to transfer all the pathnames in the current directory, then you have the destination directory wrong.
    3. When rsync with the dry-run option says only one file will be updated from this sysadmin base directory to the remote sysadmin base directory, remove the dry-run option and update the Backup machine with the current directory.
      • Only the one file should transfer between the two base directories.
    4. Put the exact rsync command line you used into file rsync_base_test1.txt in your sysadmin base directory.
  7. Remove just the one file rsync_base_test1.txt from the remote sysadmin base directory as backed up under the test1 directory in the Backup account, like this:

    $ sudo rm ~backup/test1/CST8177-14W/Assignments/assignment10/rsync_base_test1.txt
  8. From your sysadmin base directory repeat the exact same base-directory-only rsync command that you saved in the rsync_base_test1.txt file: sh rsync_base_test1.txt
    • Always use the relative path on the remote machine.
    • Exactly one file should transfer: rsync_base_test1.txt

Since rsync can transfer a lot of files in a very short time, always do a dry-run rsync before doing the real thing, just to make sure that you have the pathnames correct! As it says in the rsync course notes PDF, the source pathname syntaxes foo and foo/. are NOT the same, and it’s usually foo/. that you want to use as a source pathname! Always use the dry-run option first!

Run the Fetch and Checking Program to verify your work so far.

4.9.5 Using rsync to other machines

You can probably see that using rsync to send files to another machine is simply a matter of choosing the remote userid and machine name for the SSH login:

$ date >foo
$ rsync -avH foo backup@localhost:
$ rsync -avH foo abcd0001@cst8177.idallen.ca:

Of course, you need an SSH account on the remote machine, and rsync must be installed there.

Tip: You might choose to back up your CentOS sysadmin account HOME directory to a backup directory in your account on the CLS every now and then.

Warning: An incorrect use of rsync to the CLS can overwrite important files on the CLS. Some rsync options may even delete files. Always use the dry-run option to see what rsync proposes before actually letting rsync do the transfer.

4.10 CentOS: Boot into single user mode

If you find yourself locked out of a Linux machine, and you have access to the console, booting into single user mode will will often not require a password, and in single-user mode you can change passwords or perform various other repair tasks. (Some systems do password-protect single-user mode, in which case you would need to boot a “live” or “rescue” CD to reset your root password.)

  1. Use the correct command to reboot your CentOS VM, and when you see the GNU GRUB menu and the countdown timer, halt the GRUB countdown by pressing the space bar or an arrow key.

  2. Use GRUB to edit your boot options so you boot into single user mode. (Refer to last term’s CST8207 Booting and GRUB.)

  3. Verify that you are in single user mode: when you issue the command runlevel, the output should be either N S or unknown

  4. Note that you are running as root and can change the password of any user in single-user mode, including the root password.

  5. Put the output of the command ps auxww into a file named ps_auxww.txt in your sysadmin base directory, and change the ownership and group of this file to your ordinary sysadmin user. (Don’t leave root-owned files in ordinary user accounts!)

  6. Exit this single-user shell, which will allow the system to boot into the default runlevel.

  7. Log in (using SSH if possible) and verify you’re in the default runlevel by issuing the runlevel command.
    • You should see: S 3

Run the Fetch and Checking Program to verify your work so far.

4.11 CentOS: Boot into rescue mode

If you find a Linux machine is unbootable, and you have console access, you may be able to rescue it by booting the machine from a “Live CD”. You will use the CentOS installation DVD to boot into “rescue” mode, which is a “Live CD” mode.

  1. Shut down or power down your CentOS VM gracefully using the proper command.

  2. Attach the CentOS Installation ISO image file to your VMware virtual DVD drive, connect it, and make sure it will be connected at Power On. (You did exactly this when you first installed CentOS.)

  3. Access the VMware Settings for your Virtual Machine and increase the RAM to at least 1024MB. (The installer and Rescue mode needs more RAM for the graphics than the server-style CentOS machine.)

  4. Boot into the VMware BIOS of your virtual machine, as follows:
    1. On VMware Workstation 7.x and later, to enter the BIOS setup for the guest operating system, click VM > Power > Power On to BIOS
    2. On VMware Fusion, or an earlier version of VMware Workstation:
      • Shut down the virtual machine
      • Take a backup of the *.vmx file
      • Add this line to the end of the *.vmx file to give a longer pause on the VMware BIOS screen: bios.bootDelay = "60000"
      • Reboot your virtual machine and you should have 60 seconds to use the correct key to enter the VMware BIOS menu.
  5. In the VMware BIOS menu, use the keyboard to change the “Boot” settings so that the CD/DVD drive is before the hard disk in the boot order, if it isn’t already.

  6. Save and Exit the VMware BIOS to boot from the virtual CD/DVD drive that contains the CentOS installation ISO image file.
    • If you boot into your regular CentOS, then you didn’t set up either the Boot menu or the CD/DVD device correctly. Wait until the machine has finished booting, log in, shut it down and try again.
  7. If the ISO image boots, you will see the blue CentOS Welcome boot screen below with the large CentOS-6 banner on the screen. The Welcome menu includes the item Rescue installed system. Use the arrow keys to select the Rescue line and boot it by pressing Enter:

CentOS 6 Welcome

CentOS 6 Welcome

  1. Follow the instructions on the screen, choosing the defaults, to finish booting into rescue mode, allowing it to search for and mount your Linux system when it asks you:
    • You do not need to enable networking – choose No
    • Make note of the directory under /mnt that will be used to mount and access your Linux installation.
    • Use Continue and not Read-Only for your Linux installation, since we need to write on the file system.
    • If it fails to find and mount your Linux installation, you will have to find it and do it manually. See your instructor.
  2. At the three-item menu that starts with shell Start shell, choose the first item (start a shell).

  3. When you finally have a bash root prompt, cat the password file to see that this is not your own CentOS system running. It is the Rescue system, with its own Rescue password file.
    • If you see your CentOS password file, you didn’t boot from the Rescue CD. Shut down and try again.
  4. Running df will confirm that your CentOS ROOT partition /dev/sda1 is mounted on directory /mnt/sysimage and your CentOS HOME partition /dev/sdb1 is mounted on directory /mnt/sysimage/home

  5. Run ls -l on all the HOME directories and note that they all have numeric owners and groups.
    • Exam question: Why are all these HOME directories showing as numbers instead of userids when viewed from the Rescue CD?
  6. Save a copy of the LiveCD’s password file, preserving timestamps, permissions, etc., to the file livecd_passwd.txt in your sysadmin base directory in your mounted CentOS system.
    • Use the correct path to your sysadmin base directory on its current mount point. (The correct path to your sysadmin base directory is NOT under /home when mounted on the Rescue CD! Read all the words above.)
    • The sum of your livecd_passwd.txt file should be 63933 2
  7. The owner and group of the livecd_passwd.txt file you just created is currently root. Try (and fail) to change the file to be owned by your CentOS system admin account.
    • It will say your userid doesn’t exist: chown: invalid user: 'abcd0001'
    • Exam question: Why did the chown fail when run from the Rescue CD? Why is your userid invalid (doesn’t exist)?
  8. Run the command chroot /mnt/sysimage to obtain a root shell running with that directory (your CentOS ROOT) as its ROOT directory. As long as you remain in the chroot shell, this directory will be ROOT.

    Now when you cat the password file, you will see the password file relative to the new chroot ROOT directory, which is your CentOS ROOT directory, so you see your CentOS password file, not the LiveCD password file.
    • If you don’t see your own CentOS password file, get help.
    • All programs you run from this chroot shell will behave as if they used your CentOS file system as the ROOT.
    • You could fix a broken MBR with the command grub-install at this point, or do any other repairs to your CentOS Linux file system.
  9. In the chroot shell you are running, confirm that you can now see your livecd_passwd.txt file in your CentOS sysadmin base directory using its usual path with respect to the usual ROOT directory:

    # cd /home/abcd0001/CST8177-14W/Assignments/assignment10
    # ls -l livecd_passwd.txt

    Note that the file is still owned by root.

  10. Change the owner and group of the livecd_passwd.txt file to your system admin account. It will succeed this time.
    • Exam question: Why did the chown succeed in the chroot shell but fail before using chroot?
  11. Exit the chroot shell back to the Rescue CD shell prompt.

  12. At the Rescue CD shell prompt, use a command to shut down the machine.
    • Wait until the machine is powered off.
  13. With the machine powered off:
    1. Go to the VMware VM Settings, Hardware CD/DVD tab, under Device Status, and un-check Connect at power on.
    2. On the same screen, take the ISO file out of the virtual CD/DVD drive by switching the Connection back to Use a physical drive.
    3. Save the settings so that you do NOT boot again from the Rescue ISO image file.
    4. Go to the Hardware Memory settings and reduce the memory back to 256MB.
    5. Save the settings.
  14. Power on your CentOS VM. You should see a familiar GNU GRUB menu.
    • If you end up booting the CD/DVD again, use the VMware menu to disconnect it. Reboot or choose Boot from local drive.
  15. When your CentOS has rebooted, log back in as your system admin account (using SSH if possible, since it’s nicer than the console).

  16. Change the ownership and group (to you) of any remaining root owner or group files anywhere in your system admin account. (If you’ve done your work carefully, there should be nothing owned by root.)
    • System administrators often scan home directories, looking for root-owned files as an indication that someone has broken into the system. Don’t leave root-owned files in your own CentOS sysadmin account.
    • NOTE: The Checking Program does create root files in your CLS assignment directories. This is intentional: don’t delete these!

Run the Fetch and Checking Program to verify your work so far.

4.12 When you are All Done

That is all the tasks you need to do.

Check your work a final time using the Fetch and Checking Program and save the output as described below. Submit your mark following the directions below.

Optional: Keeping your main CentOS Virtual Machine snapshot, remove any intermediate snapshots you no longer require, to free up disk space. - Be careful not to remove your current work!

5 Checking, Marking, and Submitting your Work

Summary: Do some tasks, then run the Fetch and checking program to verify your work as you go. You can run the Fetch and checking program as often as you want. When you have the best mark, upload the marks file to Blackboard.

Since I also do manual marking of student assignments, your final mark may not be the same as the mark submitted using the current version of the Checking Program. I do not guarantee that any version of the Checking Program will find all the errors in your work. Complete your assignments according to the specifications, not according to the incomplete set of the mistakes detected by the Checking Program.

The checking program resides on the Course Linux Server, but your work is on your CentOS Virtual Machine. There is a Fetch program that you must download and use on your CentOS Virtual Machine to copy information from your CentOS Virtual Machine to your account on the CLS so that the checking program can check it on the CLS.

Once the Fetch program has fetched these files from your Virtual Machine to the CLS, you can run the checking program on the CLS to check what is saved in the files. When you make changes on your CentOS Virtual Machine, you need to run the Fetch program again on CentOS to update the saved files on the CLS.

Simply running the checking program on the CLS will not update the saved files on the CLS. You must run the Fetch program on your CentOS VM when you make changes on your CentOS Virtual Machine.

5.1 Part I - Fetch and Check

Do all the following steps on your CentOS Virtual Machine. Read through the whole list before you start typing anything. An example of what to type is given below the descriptions that follow.

Failure to read all the words will lock your account out of the CLS.

  1. Log in to CentOS. Use your sysadmin non-root account (same userid as Blackboard).
  2. Create a directory in your sysadmin account named CST8177-14W/Assignments/assignment10 (use the same directory hierarchy as you already have in your own account on the CLS). This is your base directory for this assignment.
  3. Change to the above sysadmin base directory (on CentOS!).
  4. As shown below, use curl to get a copy of the Fetch program from the given URL into a file named do.sh. Make sure you have a file named do.sh in your sysadmin base directory. You only need to download this once per assignment.
  5. Warning: If you printed this page on paper, you may not be able to scroll right to read the whole web URL that you must pass to the curl program.
$ whoami ; hostname ; pwd
abcd0001                                 # your userid, not abcd0001
abcd0001                                 # your userid, not abcd0001
/home/abcd0001/CST8177-14W/Assignments/assignment10
$ url=http://teaching.idallen.com/cst8177/14w/notes/data/assignment10do.sh
$ curl -A mozilla "$url" >do.sh
[... make sure you scroll right to read the full web URL above ...]
[... various download statistics print here ...]

$ fgrep -i 'error' do.sh                 # make sure no errors (no output)
$ head -n1 do.sh                         # make sure it's a shell script
#!/bin/sh -u
  1. You must run the do.sh script you just downloaded. You must run the script as the root user with the USER environment variable set to your own CLS account userid. (Do not use abcd0001; use your own.) Failure to set the USER= variable as shown below will cause your account to be locked out of the CLS.

    As shown below, use sudo and sh to run the do.sh script you just downloaded to CentOS with the USER environment variable set to your own CLS account userid (as stored in the USER variable).

    $ echo "$USER" ; pwd
    abcd0001                                 # your userid, not abcd0001
    /home/abcd0001/CST8177-14W/Assignments/assignment10
    $ sudo USER=$USER sh do.sh

    This do.sh script runs a Fetch program that will connect from your CentOS machine to the CLS using your account name in the USER variable. It will copy selected files from your CentOS machine to your assignment10 directory on the CLS. It will then run the checking program on the CLS to check your work. You will need to answer one question about your IP address, and then wait and type in your CLS password, as shown below:

    ---------------------------------------------------------------------------
    abcd0001: FETCH version 3.  Connecting to CLS as USER='abcd0001' using ssh
    ---------------------------------------------------------------------------
    abcd0001: Use local Algonquin IP cst8177-alg.idallen.ca [y/N/?]? n
    abcd0001: Please wait; using ssh to connect to user 'abcd0001' on cst8177.idallen.ca ...
    *** COURSE LINUX SERVER ***
    abcd0001@cst8177.idallen.ca's password:         # enter your CLS password
    ---------------------------------------------------------------------------
    idallen-ubuntu assignment10fetch_server.sh version 8 run by abcd0001.
    Please wait; collecting info from abcd0001 Virtual Machine
    ---------------------------------------------------------------------------
    VM files collected into CST8177-14W/Assignments/assignment10/abcd0001.tar.bz on CLS.
    Now running checking program for abcd0001 on CLS:
    [... checking program output appears here ...]

5.1.1 Notes on the Fetch program

  • This Fetch program copies files and information from your CentOS virtual machine into a tar archive in your account under assignment10 on the CLS and then runs the checking program on the CLS. If you only run the checking program on the CLS, it won’t update the files from your CentOS VM and it will just check the existing files saved under assignment10 on the CLS.
  • The checking program is running on the CLS, not on your CentOS VM. At the start, the checking program will issue messages relevant to your account on the CLS (e.g. errors in your CLS .bashrc file or world-writable files on the CLS). These errors are on the CLS, not on your CentOS machine.

5.2 Part II - Check and Submit

When you are done with your assignment, you need to run the checking program one last time on the CLS (not from CentOS) and submit the output file, as follows:

Do all this on the Course Linux Server when you are ready to submit:

  1. There is a Checking Program named assignment10check in the Source Directory on the CLS. Create a Symbolic Link to this program named check under your new assignment10 directory on the CLS so that you can easily run the program to check your work and assign your work a mark on the CLS. Note: You can create a symbolic link to this executable program but you do not have permission to read or copy the program file.

  2. Execute the above “check” program on the CLS using its symbolic link. (Review the Search Path notes if you forget how to run a program by pathname from the command line.) This program will check your fetched CentOS work, assign you a mark, and display the output on your screen. (You may want to paginate the long output so you can read all of it.)

    Remember: The checking program does not fetch new files to the CLS from your CentOS VM. You must run the Fetch program on your CentOS VM to update the fetched files on the CLS so that the checking program can mark them on the CLS.

    You may run the “check” program as many times as you wish, to correct mistakes and get the best mark. Some task sections require you to finish the whole section before running the checking program at the end; you may not always be able to run the checking program successfully after every single task step.

  3. When you are done with checking this assignment, and you like what you see on your screen, redirect the output of the Checking Program into the text file assignment10.txt under your assignment10 directory on the CLS. Use the exact name assignment10.txt in your assignment10 directory. Case (upper/lower case letters) matters. Be absolutely accurate, as if your marks depended on it. Do not edit the file.
    • Make sure the file actually contains the output of the checking program!
    • The last text line of the file should begin with: YOUR MARK for
    • Really! MAKE SURE THE FILE HAS YOUR MARKS IN IT!
  4. Transfer the above assignment10.txt file from the CLS to your local computer and verify that the file still contains all the output from the checking program. Do not edit this file! No empty files, please! Edited or damaged files will not be marked. You may want to refer to your File Transfer notes.
    • Make sure the file actually contains the output of the checking program!
    • The last text line of the file should begin with: YOUR MARK for
    • Really! MAKE SURE THE FILE HAS YOUR MARKS IN IT!
  5. Upload the assignment10.txt file under the correct Assignment area on Blackboard (with the exact correct name) before the due date. Upload the file via the assignment10 “Upload Assignment” facility in Blackboard: click on the underlined assignment10 link in Blackboard. Use “Attach File” and “Submit” to upload your plain text file.

    No word-processor documents. Do not send email. Use only “Attach File”. Do not enter any text into the Submission or Comments boxes on Blackboard; I do not read them. Use only the “Attach File” section followed by the Submit button. If you need to comment on any assignment submission, send me email.

    You can upload the file more than once; I only look at the most recent. You must upload the file with the correct name; you cannot correct the name as you upload it to Blackboard.

  6. Verify that Blackboard has received your submission: After using the Submit button, you will see a page titled Review Submission History that will show all your submissions.
    1. Verify that your latest submission has the correct 16-character, lower-case file name beside the Attached Files heading.
    2. The Submission Field and Student Comments headings must be empty. (I do not read them.)
    3. Save a screen capture showing the uploaded file name. If there is an upload missing, you will need this to prove that you uploaded the file. (Blackboard has never lost a file.)

    You will also see the Review Submission History page any time you already have an assignment attempt uploaded and you click on the underlined assignment10 link.

    You cannot delete an assignment attempt, but you can always upload a new version. I only mark the latest version.

  7. Your instructor may also mark files in your directory in your CLS account after the due date. Leave everything there on the CLS. Do not delete any assignment work from the CLS until after the term is over!

READ ALL THE WORDS. OH PLEASE, PLEASE, PLEASE READ ALL THE WORDS!

Author: 
| Todd Kelley and
| Ian! D. Allen  -  idallen@idallen.ca  -  Ottawa, Ontario, Canada
| Home Page: http://idallen.com/   Contact Improv: http://contactimprov.ca/
| College professor (Free/Libre GNU+Linux) at: http://teaching.idallen.com/
| Defend digital freedom:  http://eff.org/  and have fun:  http://fools.ca/

Plain Text - plain text version of this page in Pandoc Markdown format


Campaign for non-browser-specific HTML   Valid XHTML 1.0 Transitional   Valid CSS!   Creative Commons by nc sa 3.0   Hacker Ideals Emblem   Author Ian! D. Allen