userlist.csv

5. Copy the file userlist.csv from the Source Directory on the CLS to your CentOS Base Directory.
   1. Read about using the scp command in Unix/Linux SCP Command.
   2. Use the “preserves modification times” option to the scp command.
   3. You may find it useful to create an alias in your accounts that always uses the “preserve” option when you type the scp command name.
      • You may already have a similar alias defined for the cp command.
      • Make sure you define and save the alias on both the CLS and CentOS.

Imagine that the userlist.csv file was given to you from the Human Resources department by someone who created it with a spreadsheet.

Examine this file, and notice that it is in Colon-Separated-Value format. It is 98 lines: a header line and a username and a real name for each of 97 new users that need an account on your system.

The file contains five fields, separated by colons (:). Read the header line to know what the five fields are. (A real spreadsheet export would be separated by commas, but we’re making it easier for you.)

We need to create a text file suitable for batch input to the newusers command. Every line in the file we give to newusers must have the correct format: it must have the userid at the start and the seven colon-separated fields described at the top of the newusers man page.

The file given to us only has five fields, and it has a poor password set for all the accounts. We need to fix this file before we can feed it to the newsers command.

Note: If you read all the words in this section before you start working, you will save yourself some file copying by using one command pipeline (no temporary files needed) instead.

userlist.newusers

6. Create a new file called userlist.newusers based on userlist.csv, but make the following changes.

   1. Copy the userlist.csv file into the new file userlist.newusers.

   2. The first line in userlist.csv is a header line, not a user to be created; the first line must be deleted. Use a command to read the file, remove the first (header) line, and write a temporary output file. The temporary output file should be only 97 lines long. (Hints: What command shows the last 97 lines of a file? That same command has a syntax to “print beginning with the Kth item from the start of each file” which allows you to skip the first line without knowing how many lines are in the file. Don’t use the number 97, since it might change in future.)

   3. Move the temporary output file to be the userlist.newusers file.

      • The file should now have only 97 lines in it.
      • Make sure the header line is gone.

   4. Use sed to read the new file and on every line insert the two colon characters that correspond to the location of the missing pw_uid and pw_gid fields needed by newusers, and write a temporary output file. For example, use sed to change this line:

      user066:password:User 066:/home/user066:/bin/bash

      to this line with two more colon characters in the right place:

      user066:password:::User 066:/home/user066:/bin/bash

      on all 97 lines. (This is a one-expression sed substitution.) (Hint: You can’t simply change a colon to three colons. Use some fixed context around your expression, to select the correct colon to change.)

   5. Move the temporary output file to be the userlist.newusers file.

      • Verify that every line now has seven colon-separated fields, with three colons right after the password field.
      • There should still be exactly 97 lines in the file.

   6. All the seven fields in the file are acceptable except the pw_passwd field that currently contains password, which is not a good default password for all these accounts. RTFM to see how the pw_passwd field is used by newusers.

      • Use sed to read the new file and on every line change the pw_passwd field from the dummy value password to a single, common password that all of these new users will get. You choose the new password. (This is not very secure, but it’s the best you can do without writing a more complex script.)
      • Do not choose any obvious password such as password.
      • To make this change, use an invocation of the sed command to read this file and change the word password to the password that you made up, redirecting the output of the sed command to a temporary output file.

   7. Move the temporary output file to be the userlist.newusers file.

   8. Verify that your output file is 97 lines (no header line) and the only field that has changed in each line is the new password field.

      • Every line should contain your new password in the pw_passwd field position.

convert_userlist.sh

7. Realize that the above three edits could be done as one pipeline that reads the original userlist.csv file, and makes each of the above three changes using filters. With a pipeline, no temporary files are needed.

   • Write this command pipeline and when it is working, remove all the file names and put the commands in a script named convert_userlist.sh. With file names removed, the script should act as a “filter” and read standard input and write standard output, so that you can type:

     $ ./convert_userlist.sh <userlist.csv >userlist.newusers

   Hints: The script file will contain two or three commands (which might inclue tail and sed and maybe another sed) separated by pipe characters. If you RTFM, you can combine the two sed commands into one sed command with two expressions, or perhaps even into one single expression that does both edits at the same time. Remove all file names from the script, so that the script reads standard input and writes to standard output, as shown above. Do not put file names in the script.

8. Verify that the userlist.newusers file created by your script contains 97 lines and 194 words, with seven fields per line, with good passwords.

9. Use sudo to run the newusers command with this file to create all of these 97 new users.

10. Make sure all the new users and HOME directories exist:

    • Should have account entries and HOME directories for user001 through user100
    • Use pipelines to select and count the accounts in the password, group, and shadow files. Do they all exist?
    • Use pipelines to select and count the account HOME directories. Do they all exist?
    • Note that these accounts do NOT have hidden files copied from /etc/skel/ in them. Only useradd copies these files.

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

/home/common

3. Create a directory called /home/common owned by your sysadmin user, and group-owned by the new common group.

4. Change the permissions on /home/common so that your sysadmin user can read/write/search, members of the common group can read/write/search, and it is not accessible in any way to other users.

/home/common/README

5. Become User 004 without using a password (using your sysadmin powers)
   • As User 004 create a file /home/common/README containing the text:
     This common directory is for members of the common group.
   • Make the file group-writeable
   • Put the file in the common group you just created.
   • Note the permissions on the file when you create it.
   • Make sure you change only the group and group permissions of this file.
   • Do not remove any existing permissions on the file.
   • Exit from this user004 shell to revert back to your superuser-self.
6. Become User 005, and ensure that as user005 you can edit the file /home/common/README and change the text “for members” to “for all members”.
   • If you can’t edit and save this file, fix the group and group permissions.
   • Exit from this user005 shell to revert back to your superuser-self.
7. Become User 006 and ensure that as user006 you have no access to the /home/common/ directory.
   • Exit from this user006 shell to revert back to your superuser-self.
8. Use a sysadmin command to change the “real name” (GECOS/comment field) of User 005 to: CommonUser 005
   • Do NOT edit the file! Use the correct system admin command.
   • Verify the change by looking in the password file.
9. Lock the password for User 006 and User 007.
   • Do NOT edit the file! Use the correct system admin command.
   • Verify the change by looking in the shadow file.
10. Change the shell for User 008 and User 009 to /bin/sh.
    • Do NOT edit the group file! Use the correct system admin command.
    • Verify the change by looking in the password file.
11. Use the correct command to delete the accounts for User 010 and User 011 without deleting their HOME directories.
    • Verify the change by looking in the password file.
    • Make sure their HOME directories still exist in the file system. (Note what ls tells you about the file owner now!)
    • The group entries for these accounts may also continue to exist.
12. Use the correct command to delete the user010 and user011 groups, if they are still present on your machine.
    • Do not edit the group file! Use the correct system command.
    • You may see an error about removing the shadow group entry, because the newusers command did not create shadow group entries. Ignore the error – the groups don’t exist in the group shadow file.
13. Delete the accounts for User 012 and User 013 using the option that also deletes the HOME directory at the same time.
    • Verify the change by looking in the password file.
    • Make sure their HOME directories are gone from the file system.
    • The group entries for these accounts will also be deleted.

None of the items above require you to text-edit any system files using a text editor. Actions can be performed using the correct account management commands. Most account management commands will require root permissions to run. Do not text-edit the system files!

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

partitions_before.txt

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 be kept under your sysadmin Base Directory on CentOS for marking.

sd_all.txt

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 complex command is needed.
   • The output should show the absolute paths of two disks, and two partitions in the first disk: 4 lines, 40 words.
   • Hint: GLOB Patterns

Advanced Usage: If you need to add a disk to a machine that is powered on (and you can’t afford to reboot the machine), a modern Linux kernel can find the disk if you tell it to re-scan the SCSI host bus containing the new disk, something like this (the exact host number may difer):
echo "- - -" >/sys/class/scsi_host/host2/scan
If the scan is successful, running dmesg will show the new disk being found and you will see the device appear under /dev/. You can use this as an alternative to shutting down and rebooting.

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

partitions_after.txt

6. 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 as devices under the /dev directory.

partitions_diff.txt

7. 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.

8. 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, or perhaps you used MB instead of M when creating the partitions. Delete and start over.

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

fdisk.txt

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

   Put the above output into file fdisk.txt in your sysadmin Base Directory. The file will contain one line.

3. Create an ext4 filesystem on the only primary partition on the new disk.

   • Review the CST8207 Partitions and File Systems notes.
   • This primary partition is the one with size 500MB.

4. After creating the filesystem, again check the type of the device that corresponds to your new primary partition on your new second disk. It should show an ext4 filesystem that is not active:

   Linux rev 1.0 ext4 filesystem data (extents) ...

   Append the above output to file fdisk.txt in your sysadmin Base Directory. The file will contain two lines.

5. Also use file -s to check the type of file system in the first partition of the first disk. This first partition of the first disk has an active (in use) ext4 filesystem. Note the warning “needs journal recovery” indicating this filesystem is open and being modified:

   Linux rev 1.0 ext4 filesystem data (needs journal recovery) ...

   Append the above output to file fdisk.txt in your sysadmin Base Directory. The file will contain three lines.

6. Also check the type of the second partition of the first disk. It will say that it is not an ext4 filesystem.

   Append the above output to file fdisk.txt in your sysadmin Base Directory. The file will contain four lines.

The fdisk.txt file should contain four lines.

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

home.tar.gz

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.

   • A tar index should list over 130 pathnames, including almost 100 directories created by the newusers command in a previous assignment.
   • The compressed tarball will be less than 15K bytes, since most of /home is empty directories or duplicate files.

(You will check the validity of the home.tar.gz file at the end of this task when you move it into your Base Directory.)

home_before.txt

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.

/old_home

3. 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.

/home

4. Re-create a new empty /home directory that will be used as a mount point for the new filesystem you just created, above.

5. 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.)

   • If successful, you will see EXT4-fs (sdb1): mounted filesystem....

6. 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   477M  2.3M   449M    1% /home

7. 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.)

8. 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.

home_after.txt

9. 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.

home_diff.txt

10. 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.)

11. Add a record to the system 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 fstab.
    • Use one (1) for the fifth field (dump or archive flag).
    • Use two (2) for the sixth field (fsck pass number). (RTFM for fstab and note that using pass number 1 is reserved for the ROOT file system.)

12. Use the mount command with the remount option to remount the /home filesystem. The remount will use the new options given in 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 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!

13. Use the mount command to verify that /home is now remounted with the two quota options that you set in fstab:

    /dev/sdb1 on /home type ext4 (rw,usrquota,grpquota)

14. Verify that your sysadmin HOME directory is now valid:

    • Use su with the --login option to log in to your sysadmin account. If this fails (home directory not found), restore from a snapshot and try again.
    • Verify that all the files, dates, and owners in your sysadmin account are exactly the same as they were before moving /home.
    • If your sysadmin HOME directory is missing or has files owned by root, do not continue. Fix it!
    • Exit your sysadmin shell and return to the single-user root shell.

15. In your single-user root shell, unmount /home and then mount it again, relying on the fstab to provide the device name and file system options:

    # umount /home  ;  mount /home  ;  mount

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

/mnt/disk02

3. Make an ext4 file system on the first logical partition of your second disk and create a system fstab entry that mounts it on the new directory /mnt/disk02 (that you will have to create).
   • Use the default options plus noatime in the fstab entry.
   • Turn on backups (field 5) and set the pass number to 3 (field 6).
4. Mount the disk02 file system and then check the mount to make sure it has the noatime option listed: type ext4 (rw,noatime)

/mnt/disk02/backup

5. Create a new system account named backup with these options:
   1. The account should be a system account with a HOME directory
      • Remember the options needed to create a system account with a HOME directory. (Your sysadmin account used the same options when you created it. Check your shell history for the command you used!)
   2. The GECOS (comment) field should be set to be Backup Account
   3. The HOME directory should be set to be /mnt/disk02/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).
6. 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 by typing it multiple times:

     $ 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.

7. 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/disk02/backup
   3. Make sure this works without error: ssh backup@localhost df .
      • Note the “dot” at the end of the line.
      • The output must show that the backup account HOME directory is on the first logical partition of your second disk, which is mounted on /mnt/disk02
      • Under Mounted on you must see /mnt/disk02 and if not, go back a few steps and mount it again.

.ssh/config

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. From your sysadmin account, try out the new SSH Host alias using any ssh command:

   $ ssh backup id
   CentOS release 6.6 (Final)
   CST8177-15W idallen@idallen.ca
   backup@localhost's password: 
   uid=497(backup) gid=497(backup) groups=497(backup)

   You can use the shorter aliases, too. Try any of these:

   $ ssh backup id
   $ ssh back id
   $ ssh bk id
   $ ssh b id

5. 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.

rsync_home_test1.txt

2. Put the exact rsync command line you used above into file rsync_home_test1.txt in your sysadmin Base Directory.

3. 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-15W/Assignments/assignment08/do.sh /tmp/foo
   $ diff /tmp/foo ~/CST8177-15W/Assignments/assignment08/do.sh
   $ ls -l /tmp/foo ~/CST8177-15W/Assignments/assignment08/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 assignment08/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.

4. 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:

   1. You can re-type the command line, or use shell history, or you can simply tell the shell to run the command in the file: sh rsync_home_test1.txt
   2. Always use the relative path on the remote machine.
   3. Almost no file data will transfer, since almost all the files are already there. (Your .bash_history file and the new rsync_home_test1.txt file should be the only files that have changed.)
   4. 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.

5. Change to your sysadmin Base Directory. (Perhaps you are already there?)

6. 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 one or two files are selected for transfer.

rsync_base_test1.txt

7. In your sysadmin Base Directory copy rsync_home_test1.txt to the new file rsync_base_test1.txt

8. Use a new rsync command line 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 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.

     sending incremental file list
     ./
     rsync_base_test1.txt
     
     sent 463 bytes  received 18 bytes  962.00 bytes/sec
     total size is 28770  speedup is 59.81 (DRY RUN)

   • If rsync proposes to transfer all the pathnames in the current directory, then you have the destination directory wrong.

9. When rsync with the dry-run option says only one file will be updated from this sysadmin Base Directory to the remote sysadmin 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.

rsync_base_test1.txt

10. Put the exact rsync command line you used into file rsync_base_test1.txt in your sysadmin Base Directory.

11. 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-15W/Assignments/assignment08/rsync_base_test1.txt

    If you get an error message, you have the pathname wrong or else you didn’t do the previous rsync correctly to back up the file.

12. 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 (12-sshkeys_yum_rsync.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.

ps_auxww.txt

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.

livecd_df.txt

11. Redirect the full output of df (all 10 lines) to the file livecd_df.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.)
12. Run ls -l on all the HOME directories in the HOME partition (which is NOT currently mounted under /home) and note that all the accounts have numeric owners and groups.
    • Even your own sysadmin HOME directory shows a numeric owner and group in the output of ls -l.
    • Exam question: Why are all these HOME directories showing as numbers instead of userids when viewed from the Rescue CD?

livecd_passwd.txt

13. 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.)
    • Since this is the Rescue CD, none of your aliases are defined. Make sure you use the right option to the copy command.
    • The sum of your livecd_passwd.txt file should be 63933 2
14. The owner and group of the livecd files you just copied into your sysadmin directory is currently root.
    • Try (and fail) to change the file to be owned by your CentOS system admin account user name.
    • The command will say your sysadmin userid doesn’t exist: chown: invalid user: 'abcd0001'
    • Exam question: Why did the chown fail when run from the Rescue CD?
    • Why is your sysadmin userid invalid (doesn’t exist) in the Rescue CD environment?
15. Run the command chroot /mnt/sysimage
    • This starts a root shell running with /mnt/sysimage (your hard disk CentOS ROOT) as its ROOT directory, instead of the Rescue CD ROOT.
    • As long as you remain in this chroot shell, the /mnt/sysimage directory will used as be actual ROOT directory named /.
    • 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.
16. Run the df command now and note the familiar list of file systems, with sda1 mounted on the ROOT and sdb1 mounted on /home, etc.
    • The chroot command hides the /mnt/sysimage mount point and makes it look like the real ROOT directory as long as we stay in this chroot shell.

All programs you run from this chroot shell will behave as if they used your CentOS file system as the ROOT. The file name /etc/passwd now refers to your CentOS password file, not the Rescue CD password file.

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.

17. In the chroot shell you are running, pathnames work as if your CentOS machine were running. Everything works as expected.

    • Confirm that you can now see your two livecd_*.txt files in your usual CentOS sysadmin Base Directory using its usual path with respect to the usual CentOS ROOT directory:

      # cd ~abcd0001/CST8177-15W/Assignments/assignment08
      # ls -l livecd_passwd.txt livecd_df.txt

    (Always use your own sysadmin userid in these assignments, never the place-holder userid abcd0001.) Note that the above files in your account are still owned by root.

18. Change the owner and group of the livecd_*.txt files to your system admin account user name. The command will succeed this time.

    • Exam question: Why did the chown succeed in the chroot shell but fail in the Rescue CD shell before using chroot?

19. Exit the chroot shell. You will return back to the Rescue CD shell and prompt.

20. Run the df command again in this Rescue CD shell and note how everything again appears mounted under /mnt/sysimage

21. At the Rescue CD root shell prompt, try to use the usual command to shut down and halt the machine safely. Do not use VMware Power Off!

    1. The command will fail: shutdown: Unable to shutdown system
    2. Exit the Rescue CD root shell and return to the three-itme Rescue CD text menu.
    3. Use the arrow keys to select: reboot Reboot from the menu.
    4. When the machine reboots and you again see the blue Welcome to CentOS 6.6 screen, use the VM -> Power -> Power Off menu to power off the system without starting CentOS.
       • You can safely use VMware to power off a machine before any hard-disk operating system (e.g. CentOS) starts.
       • Never power off a running CentOS machine!

22. 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 to make live snapshots quick and small.
    5. Save the settings.

23. Power on your CentOS VM. You should see a familiar GNU GRUB menu from your hard disk CentOS installation.

    • If you end up booting the CD/DVD again, use the VMware menu to disconnect it. Reboot or choose Boot from local drive.

24. When your CentOS has rebooted, log back in as your system admin account (using SSH if possible, since it’s nicer than the console).

25. Change the ownership and group to you of any remaining root owner or group files anywhere in your CentOS 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.