% CST8207 Assignment 14 - BONUS - Part 2 of 2 - GRUB, Run Levels, services % Ian! D. Allen - - [www.idallen.com] % Fall 2013 - September to December 2013 - Updated Tue Dec 3 10:59:17 EST 2013 Due Date and Deliverables ========================= > You must have your own CentOS virtual machine (with root permissions) > running to do this lab. You cannot do the lab on the Course Linux Server > because you do not have root permissions on that machine. - **Due Date**: `23h59 (11:59pm) Friday December 6, 2013 (end of Week 14)` - The original Assignment 13 has been split into two smaller pieces – 13 and 14 – to make the checking script simpler. This Assignment 14 is the second half of Assignment 13. - College policy does not allow assignments to be due after the term ends on December 6. - Late assignments or wrong file names may not be marked. Be accurate. - This is a **Bonus** assignment worth extra marks. - **Available online** - Version 1 – 07:00am Thursday November 28, 2013 - Version 2 – 12:00 Thursday November 28, 2013 - fixed file name spelling - Version 3 – 14:00 Thursday November 28, 2013 - added geometry command - **Prerequisites** - All [Class Notes] since the beginning of term. - All your previous [Assignments]. - Completed [CentOS Virtual Machine] installation. - Completed [CentOS VMware Tools] installation. - An ability to **READ ALL THE WORDS** to work effectively! - **Deliverables** 1. One text file uploaded to Blackboard according to the steps in the [Checking Program] section below. 2. Directory structure created and left for marking on the [Course Linux Server] (**CLS**).\ **Do not delete any assignment work from the CLS until after the term is over!** 3. Accounts and directory structure created and left for marking on your own [CentOS Virtual Machine].\ **Do not delete any assignment work from your CentOS VM until after the term is over!** **WARNING:** Some inattentive students upload Assignment #14 into the Assignment #13 upload area. Don’t make that mistake! Be exact. Purpose of this Assignment ========================== 1. Practice managing [Booting and GRUB] in your own virtual machine. - This is a **BONUS** assignment for extra credit. 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. You also don’t get any of the later updates to the > assignment. Do not print this assignment on paper. 1. Complete the readings in your weekly [Class Notes]. 2. Do the **Tasks** listed below, in order. - **READ ALL THE WORDS** to work effectively and not waste time. 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. > 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 > mistakes detected by the [Checking Program]. When you are finished the tasks, leave the files and directories in place 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; you must have your term work available right until term end. The CLS Source Directory ------------------------ All references to the “Source Directory” below are to the CLS directory `~idallen/cst8207/13f/assignment14/` 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). Commands, topics, and features covered -------------------------------------- Review course notes [Booting and GRUB]. Use the on-line help (`man` command) for the commands listed below for more information. - `chkconfig` – display or change Run Level information and services - `grub` – **GRand Unified Bootloader** (legacy version 0.9x - **not** the Version 2 GRUB numbered 1.9x). The man page is useless. See this instead: [GRUB manual] - `runlevel` – display previous and current Run Level - `telinit` – change Run Levels - `uname` – print system information: display system name, kernel **release** and **version** number, machine, processor, and O/S type - `/etc/inittab` – documentation on Run Levels; contains the default Run Level - `/boot/grub/grub.conf` – the GRUB Legacy (version 1) configuration file Correct user, command lines, and command output ----------------------------------------------- - Most of the commands in this assignment require `root` privilege. Use the `sudo` command to run individual commands as `root` – don’t use a `root` subshell. - If you start a `root` subshell (not recommended – use `sudo` instead), your prompt will tell you if you are the `root` user by changing to include a `#` character instead of a `$` character. You can also use the commands `id` or `whoami` to show your current userid. - Some answers require you to record **command lines**. Do **not** include the shell **prompt** with your command lines. Give only the part of the command line that you would type yourself. - Make sure you know the difference between a command **line** (which is what you type into the shell) and command **output** (which is what the command displays on your screen). Pay attention to whether the question asks you to record the command line or the command output. Backup and Recovery ------------------- 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. 2. *Are you keeping an external backup copy of all your coursework (including your virtual machines) somewhere? You should be!* 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. The Answer File `answer.txt` ---------------------------- Where you are required to record or save a command line or its output into [The Answer File], **do** the command and then copy and **record** the command line or its output as a separate line into an `answer.txt` file in your CentOS `assignment14` directory. You will be told how many lines to save in the file. If you can’t answer a question, leave a blank line in this answer file. (The `vim` option `:set number` may be useful to you as you edit.) You can use either `nl` or `cat -n` to show the contents of a file with line numbers, to make sure each answer is on its correct line number. Tasks ===== - Do the following tasks in order, from top to bottom. - **READ ALL THE WORDS!** and do not skip steps. - Pay attention as to which tasks must be done in your own [CentOS Virtual Machine] and which must be done in your account on the [Course Linux Server]. - Your instructor will mark on the due date the work you have in your account on the CLS. Leave all your work on the CLS and do not modify it. - **Do not delete any assignment work from the CLS or your CentOS VM until after the course is over.** Set Up ------ 1. Create your `assignment14` directory on the CLS in the usual place. 2. Create your sysadmin account `assignment14` directory on your CentOS VM in the usual place (not in the `root` account!). **This CentOS directory is the base directory for all pathnames in this assignment. Store your files and answers here on CentOS.** 3. Before you begin this assignment, create a snapshot of your [CentOS Virtual Machine], as mentioned above. - Enter a comment explaining where and when you took this snapshot. - You can restore back to this snapshot if anything goes wrong. 4. Run the [Checking Program] to verify your work so far. Booting into single-user mode (changing forgotten root password) ---------------------------------------------------------------- Review [Booting and GRUB]. This section depends on a successful [CentOS Virtual Machine] installation, including a working GRUB menu. To change a forgotten `root` password or do maintenance on the system that requires it to be quiescent, you can boot your system in a restricted **single-user** mode that does not start many system daemons and goes directly into a `root` shell prompt on the system console without requiring a password. The system should not be left in single-user mode; many things are not started. You may not even be able to log-in remotely in single-user mode. 1. View your CentOS GRUB configuration file and look at the `kernel` line in that file. Note all the options used on the `kernel` line; you will see them again soon. - Record on Line 1 in [The Answer File] the Linux absolute pathname of this GRUB configuration file. 2. Record on Line 2 in [The Answer File] the kernel option keyword used in booting a machine single-user (maintenance mode). (one word) 3. Safely reboot your CentOS VM into the GRUB menu. 4. When the boot process begins, if you correctly disabled the `hiddenmenu` command in GRUB, you will boot directly to the GNU GRUB menu where you should see a one-line list of CentOS systems to boot and at the bottom a 30 second countdown in progress. - Interrupt the countdown by pressing an arrow key. (If you didn’t disable `hiddenmenu`, when the countdown is interrupted your system should display the one-entry GRUB menu.) ![CentOS 6 GRUB Menu] 5. Now, just as the GRUB menu instructions tell you, to modify the kernel arguments you press just the single letter `a` – just the letter key, no `[Enter]` key! - After pressing `a` you will see your cursor on a line that ends with the same `kernel` arguments you viewed earlier in the configuration file. - You can use the `[Home]` key to zoom to the left end of the kernel options line, and the `[End]` key to zoom to the right. ![CentOS 6 Kernel Options] 6. Modify this kernel options line so that the system will boot single-user. (Add the correct kernel option keyword to the end of the line.) - As the instructions say, push **[Enter]** to accept your changes and directly boot the system using these new kernel options. - These changes to the kernel options are **not** saved back into the configuration file – they are only in effect for this boot menu. - (If you wanted to abandon your changes and leave the menu entry unmodified, you would have used the **Escape** key, as it says.) 7. The system should come up in single-user (maintenance) mode with a `root` shell prompt. (If you get a `login` prompt, you didn’t use the right kernel option keyword. Reboot and try again.) - You can perform any `root` function at this prompt, including changing passwords (even the `root` password). - Often single-user mode has no networking enabled and only a minimal number of file systems mounted. 8. From the single-user shell, place a full list of all processes for all users, **BSD** format, text user name (not numeric UID), full wide listing (not truncated at all), into a `psbsd-single.txt` file. (All assignment answer files must be saved in your sysadmin CentOS `assignment14` directory.) The output should be approximately 52 lines and 4KB. All the processes will be owned by `root`. The first two lines will look similar to this: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 2.5 0.5 2900 1368 ? Ss 16:35 0:01 /sbin/init 9. Use the command that displays the previous and current Run Level (two words on one line) and record this line of output as Line 3 in [The Answer File]. 10. Leave single-user mode and let the system finish booting into full multi-user mode. The `login` prompt should appear on the console. - Leaving single-user mode does *not* mean rebooting the machine. Do not reboot or shut down the machine. 11. Log in as your sysadmin account (optionally use an SSH login, not the terrible console window) and repeat the command that displays the previous and current Run Level and save the output as Line 4 in [The Answer File] (two more words on one line). 12. Check your work using the [Checking Program]. Using a different GRUB configuration file ----------------------------------------- Review [Booting and GRUB]. You can select a different GRUB configuration file at boot time. 1. Record the number of lines in a standard Linux **boot menu entry** as Line 5 in [The Answer File] (one number). 2. In your running CentOS VM, copy the current GRUB configuration file to a new file named `myconfig` in its same `grub` directory. - Record the Linux absolute pathname of the new file as Line 6 in [The Answer File]. 3. Edit the `myconfig` file: a) On the `title` line of the only **boot menu entry** in the file, change the word `CentOS` to `MY OWN CentOS` b) Save the `myconfig` file. 4. Compare the current GRUB configuration file with the new `myconfig` GRUB configuration file. The new file should have two more words. A file difference using the `diff` command should show the one line change: $ diff grub.conf myconfig 14c14 < title CentOS (2.6.32-358.el6.i686) --- > title MY OWN CentOS (2.6.32-358.el6.i686) ### Previewing a new GRUB configuration file You can preview much of a GRUB configuration file from multi-user mode without having to reboot the system to test it, but you can’t actually select a new kernel until you reboot. 5. Record as Line 7 in [The Answer File] a GRUB pathname (using GRUB syntax) that refers to your new `myconfig` GRUB configuration file in its correct partition. - Recall that GRUB pathnames start with a device (partition). - You need to turn the Linux partition name into a GRUB name. - The resulting path name will be in the GRUB form: *(xxx,x)/xxxxx* - You will need this GRUB pathname shortly. 6. GRUB can be run as a shell-like utility that has many built-in commands. Start the command-line GRUB utility by running the command named `grub` as `root` from your shell without rebooting the machine. When you run this `grub` command you will see a `grub>` prompt: $ sudo grub Probing devices to guess BIOS drives. This may take a long time. GNU GRUB version 0.97 (640K lower / 3072K upper memory) [ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename.] grub> The comments about TAB completion don’t apply to this command-line version of GRUB. (Sorry – this is a bug!) TAB only works when GRUB is run at boot time as the boot loader. 7. Type `help` at the`grub>` prompt to see a partial list of GRUB utility commands. You can also type `help commandname` to get a bit more help on *commandname* - Note which GRUB command will quit GRUB and return you to your BASH shell prompt. (`^C` will also terminate this GRUB utility.) - Note which GRUB command will load a new configuration file. (You will need this command name shortly.) - Note (and try) which GRUB command will display partitions on a disk: grub> geometry (hd0) drive 0x80: C/H/S = 261/255/63, The number of sectors = 4194304, /dev/sda Partition num: 0, Filesystem type is ext2fs, partition type 0x83 Partition num: 1, Filesystem type unknown, partition type 0x82 grub> geometry (hd1) drive 0x81: C/H/S = 130/255/63, The number of sectors = 2097152, /dev/sdb Partition num: 0, Filesystem type is ext2fs, partition type 0x83 Partition num: 1, Filesystem type is ext2fs, partition type 0x83 Partition num: 3, Filesystem type is fat, partition type 0xc Partition num: 4, Filesystem type unknown, partition type 0x82 Partition num: 5, Filesystem type unknown, partition type 0x7 GRUB is not very intelligent about the file systems inside partitions. Above, it mistakes both `ext3` and `ext4` file systems as type `ext2fs`. (You can actually mount both `ext3` and `ext4` file systems as type `ext2` and the journalling feature will be disabled. Don’t do it!) - Note (and try) which GRUB command displays (and sets) the current partition/device prefix, and which command displays a text file: grub> cat /etc/hosts Error 1: Invalid device requested grub> root (fd0): Filesystem type unknown, partition type 0x0 grub> root (hd0,0) Filesystem type is ext2fs, partition type 0x83 grub> root (hd0,0): Filesystem type is ext2fs, partition type 0x83 grub> cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 127.0.0.2 cst8207b ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 8. Choose the GRUB utility command that loads a configuration file and run that command now with an argument that is your new `myconfig` file name: - The configuration file name must be given in full GRUB pathname form, including the partition name, just as you recorded earlier. - As a file name argument to the `configfile` command you will need to specify both the partition and the pathname to the new GRUB configuration file you edited above. - The errors *Invalid device requested* and/or *Cannot mount selected partition* mean you didn’t get the GRUB partition part of the pathname correct. - The error *File not found* means you didn’t get the pathname inside the partition correct. - The error *Selected disk does not exist* might mean you don’t have enough permissions – what user is supposed to be running this GRUB utility? - Keep trying until you get it right and you see the output below: 9. When you get the `configfile` command and GRUB pathname to your `myconfig` file right, you will see output similar to this: GNU GRUB version 0.97 (640K lower / 3072K upper memory) ------------------------------------------------------------------- 0: MY OWN CentOS (2.6.32-358.el6.i686) ------------------------------------------------------------------- Use the ^ and v keys to select which entry is highlighted. Press enter to boot the selected OS, 'e' to edit the commands before booting, 'a' to modify the kernel arguments before booting, or 'c' for a command-line. Ignore the information about which keys work – none of these keys work in this command-line version of GRUB. The keys only work after a reboot in the boot loader version of GRUB. We are only using GRUB in command-line mode to preview our GRUB menu to make sure it works. 10. When you see the expected `MY OWN CentOS` menu, break out of (interrupt) the GRUB utility and return to the BASH shell prompt. - You have confirmed that your new GRUB configuration file works. - You cannot actually select and run any **boot menu entries** in the command-line version of GRUB. To actually select a kernel, you would have to reboot into the real GRUB boot loader, but don’t do that yet. - If you don’t see the `MY OWN CentOS` menu, edit and fix the `myconfig` file until you do. ### Run the new GRUB configuration file 11. When you have successfully previewed your new GRUB configuration file above and you see your `MY OWN CentOS` menu entry, as shown above, you are ready to try your new file in the real GRUB boot process: a) Safely reboot your CentOS VM into the standard GRUB menu (the one that doesn’t have your changes). b) As you did before, interrupt the GRUB countdown timer. c) Follow the GRUB directions on your screen and type the correct letter key to start up a GRUB command line. GRUB will then prompt with the usual `grub>` prompt. d) At the `grub>` prompt, use the exact same `configfile` line you used earlier to select your new `myconfig` GRUB configuration file. (In this boot loader version of GRUB, TAB completion now works for both GRUB command names, disk names, partition names, and file names. Use TAB to help you type the correct GRUB command line.) e) When you load your new configuration file inside the boot loader version of GRUB, you should see your `MY OWN CentOS` menu entry, like this: ![CentOS 6 myconfig configuration file] 12. Let the time out expire to boot your system, or use the **[Enter]** key. 13. Check your work using the [Checking Program]. Configure a second GRUB boot menu --------------------------------- Your current CentOS GRUB configuration file contains only a single **boot menu entry** for one Linux kernel. We will now create a new GRUB configuration file with a second **boot menu entry**. 1. In your running CentOS VM, copy your `myconfig` configuration file to a new file named `newconfig` in its same `grub` directory. - Record the Linux absolute pathname of the new file as Line 8 in [The Answer File]. 2. Edit the `newconfig` file to create a second **boot menu entry** that will boot the machine single-user as follows: a) Copy the existing four-line **boot menu entry** in the file and create a new four-line **boot menu entry** below it. (Copy and paste four lines in the file. In `vim` put your cursor on the first line to copy and type `4yyP`.) - The new four-line **boot menu entry** must start out as an exact copy of the original four-line **boot menu entry**. - Do not make any changes to the first four-line **boot menu entry**. b) On the `title` line of the second **boot menu entry** change the word `CentOS` to `single user CentOS` c) In the second **boot menu entry** add the kernel option to boot in single-user mode, just as you did earlier when booting single-user from the live GRUB menu. d) Save your changes. Your new `newconfig` configuration file will now be four lines longer than the `myconfig` file: $ wc -l myconfig newconfig 17 myconfig 21 newconfig 3. To make sure your `newconfig` file works before you reboot, preview your configuration file changes using the `grub` utility run from the shell as you did before. You should see this two-line menu as preview output when you load your `newconfig` configuration file into GRUB: GNU GRUB version 0.97 (640K lower / 3072K upper memory) ------------------------------------------------------------------- 0: MY OWN CentOS (2.6.32-358.el6.i686) 1: MY OWN single user CentOS (2.6.32-358.el6.i686) ------------------------------------------------------------------- 4. When you have the preview working, safely reboot and run your new GRUB `newconfig` configuration file using the same method as you did earlier to run tye `myconfig` file. - Make sure you see two choices in your GRUB menu now: ![CentOS 6 newconfig configuration file] 5. Select the single-user choice. It must boot the machine into the single-user `root` shell with no password required. 6. Leave single-user mode and continue the boot process into standard multi-user mode (with a `login` prompt). 7. In multi-user mode, log in as your sysadmin account (optionally use an SSH login, not the terrible console window) and check your work so far using the [Checking Program]. Changing System V Run Levels and Services ----------------------------------------- See the section on Legacy Run Levels and Services in the [Booting and GRUB][1] page. As with most system maintenance activities, you will need to use the `sudo` command to run the privileged commands in this section. 1. If not already logged in, log in to the CentOS VM console (not via SSH) as your ordinary (non-`root`) sysadmin account. - You will see console messages if you are logged in to the console, which you will not see using an SSH terminal connection. 2. Use a command to list all services and all run level information into file `chkconfig-before.txt` in your CentOS `assignment14` directory. It should be approximately 22 lines. Two of the lines should look like this: ntpdate 0:off 1:off 2:off 3:off 4:off 5:off 6:off postfix 0:off 1:off 2:on 3:on 4:on 5:on 6:off 3. Use the same command name to enable (turn on) the **NTP Date** service only in Run Level 4 (a normally unused Run Level in CentOS). 4. Use the same command name to disable (turn off) the above **Postfix Mail Service** service in Run Level 4. 5. Save a second listing of all services and all run levels into file `chkconfig-after.txt` in your CentOS `assignment14` directory. It should still be approximately 22 lines. Two of the lines should now look like this: ntpdate 0:off 1:off 2:off 3:off 4:on 5:off 6:off postfix 0:off 1:off 2:on 3:on 4:off 5:on 6:off 6. Use the `diff` command to compare the *before* listing file with the *after* listing file. Only two lines should have changed. 7. Run a command to show a full list of all processes for all users, **BSD** format, text user name (not numeric UID), full wide listing (not truncated at all) and search for any lines containing the string `postfix`. - You will see about three or four lines. - Save those three or four lines into a `postfix.txt` file. 8. Record as Line 9 in [The Answer File] the Linux absolute pathname of the system configuration file that gives the default Run Level for your CentOS system. 9. Record as Line 10 in [The Answer File] the one line from the above system configuration file that sets the default Run Level for your CentOS system. (Hint: It’s the only non-comment line in the file!) 10. Use a command to confirm that your current Run Level is the same as the CentOS default Run Level. (This should be true unless you are running in single-user mode, which you should not be.) 11. On the system console, use a command to change from the current Run Level (which should be the default) to Run Level 4. You will see (only if logged in on the console) various status messages about services that stop and start: - The Postfix service will announce that it is shutting down. - The `lvm2-monitor` service will complain that it is too dangerous to shut down. - The `udev` event manager will retrigger some events. - The `ntpdate` service will try to synchronize the time, and fail. 12. Use the command that displays the previous and current Run Level (two words on one line) and record this line of output as Line 11 in [The Answer File]. 13. In a system log file, find the reason that the `ntpdate` service did not work: - How do you know which [System Log Files] were modified most recently? Those log files are the files you should look in for the log message. - The message from `ntpdate` talks about a socket being in use. - When you find the right log file name, record the Linux absolute pathname of the correct log file as Line 12 in [The Answer File]. - Record this last `ntpdate` log message as Line 13 in [The Answer File]. 14. Run a command to show a full list of all processes for all users, **BSD** format, text user name (not numeric UID), full wide listing (not truncated at all) and again search for any processes running as the `postfix` userid. - No processes running as the `postfix` userid will be found. (You might see a process run by you, searching for `postfix`.) 15. On the system console, use a command to change from the current Run Level 4 back to the CentOS system default Run Level. You will again see (only if logged in on the console) various status messages about services that stop and start: - The `udev` event manager will retrigger some events. - The Postfix service will announce that it is starting. 16. Use the command that displays the previous and current Run Level (two words on one line) and record this line of output as Line 14 in [The Answer File]. 17. Confirm that the `postfix` processes are again running. 18. Check your work using the [Checking Program]. Manually Starting/Stopping Services ----------------------------------- See the section on Starting and Stopping Services in the [Booting and GRUB][2] page. As with most system maintenance activities, you will need to use the `sudo` command to run the privileged commands in this section. 1. Make sure your system is running as the default CentOS Run Level. 2. Use a command to ask for the service status of the `postfix` service: - The output of the command will include the `pid` of the service and say that it is running. - Record the one line of output (with the `pid`) as Line 15 in [The Answer File]. 3. Use a command to stop the `postfix` service: - You will see one line of logging information saying: `Shutting down postfix: [ OK ]` 4. Use a command to ask for the service status of the `postfix` service: - The output of the command will say that the service is **stopped**. - Record the one line of output from the command as Line 16 in [The Answer File]. (Record the **stopped** output line from the status command, not the **Shutting down** logging information.) 5. Use a command to start the `postfix` service: - You will see one line of logging information saying: `Starting postfix: [ OK ]` 6. Use a command to try to start the `ntpdate` service: - You will see one line of logging information saying: `[FAILED]` - The system log file will tell you why it failed. 7. Check your work using the [Checking Program]. Kernel Version Number (release number) -------------------------------------- Your Linux kernel has a **version** number, as in “What **version** of the kernel are you running? I’m running **version** `2.6.32`”. Unfortunately, the command that prints system information, including the kernel **version** number, calls the number a kernel **release** number, because it uses the option name **version** to stand for the kernel **compile date**. When using this system information command to display the kernel **version** number, you must use the option for **release**. 1. Display **only** the version (release) of the Linux kernel that is running on CentOS (about 17-20 characters): - Record the command line you must use as Line 17 in [The Answer File]. - Record the one line of output for CentOS as Line 18 in [The Answer File]. (The output starts with the digit `2` on CentOS.) - Log in to the CLS find out what kernel it is running. Record the one line of output for the CLS as Line 19 in [The Answer File]. (The output starts with the digit `3` on the CLS – the CLS runs a newer kernel than CentOS.) 2. Check your work using the [Checking Program]. When you are done ----------------- That is all the tasks you need to do. Check your work a final time using the [Checking Program] and save the output as described below. Submit your mark following the directions below. 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. The checking program resides on the [Course Linux Server], but your work is on your [CentOS Virtual Machine]. There is a new **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 below on your CentOS VM when you make changes on your [CentOS Virtual Machine]. 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. 1. Log in to CentOS using your system administrator (non-root) account. 2. Change to your existing CentOS `assignment14` directory containing all your answer files for this assignment. 3. 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 end up with a file named `do.sh` in your `assignment14` directory. - Make sure the downloaded file is not a file of HTML and errors. It should start with `#!/bin/sh` and contain a few shell comments and commands, including another `curl` command. - You only need to download this **Fetch** program once per assignment. 4. As shown below, use `sudo` to run the `do.sh` script you just downloaded to CentOS, with the `USER` environment variable set to your own College/Blackboard/CLS account userid (do not use *abcd0001*). - You can run the `do.sh` script over and over to check your work. 5. This **Fetch** program will connect from CentOS to the CLS using your account name. It will copy files from CentOS to your `assignment14` 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. It will look something like this (use your userid, not *abcd0001*): CentOS$ hostname abcd0001 CentOS$ pwd /home/abcd0001/CST8207-13F/Assignments/assignment14 CentOS$ echo "$USER" abcd0001 CentOS$ curl -A mozilla http://teaching.idallen.com/cst8207/13f/notes/data/assignment14do.sh >do.sh [... various download statistics print here ...] CentOS$ sudo USER=$USER sh do.sh --------------------------------------------------------------------------- abcd0001: FETCH version 2. Connecting to CLS as USER='abcd0001' using ssh --------------------------------------------------------------------------- abcd0001: Use local Algonquin IP cst8207-alg.idallen.ca [y/N]? n abcd0001: Please wait; using ssh to connect to user 'abcd0001' on cst8207.idallen.ca ... *** COURSE LINUX SERVER *** abcd0001@cst8207.idallen.ca's password: # enter your CLS password --------------------------------------------------------------------------- idallen-ubuntu assignment14fetch_server.sh version 4 run by abcd0001. Please wait; collecting info from abcd0001 Virtual Machine --------------------------------------------------------------------------- VM files collected into CST8207-13F/Assignments/assignment14/abcd0001.tar.bz on CLS. Now running checking program for abcd0001 on CLS: [... checking program output appears here ...] - You can use `sudo` to run the `do.sh` script over and over to check your work. - You only need to run the `curl` line once, to get the `do.sh` script. ### Notes on the Fetch program - This **Fetch** program updates your saved files 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 exiting files saved under `assignment14` 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. 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 and submit the output file, as follows: Do all this one last time on the [Course Linux Server] (not on CentOS): 1. There is a [Checking Program] named `assignment14check` in the [Source Directory] on the CLS. Create a [Symbolic Link] to this program named `check` under your new `assignment14` 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 tasks 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 `assignment14.txt` under your `assignment14` directory on the CLS. Use the *exact* name `assignment14.txt` in your `assignment14` 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! 4. Transfer the above `assignment14.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. 5. Submit the `assignment14.txt` file under the correct Assignment area on Blackboard (with the exact name) before the due date. Upload the file via the **assignment14** “Upload Assignment” facility in Blackboard: click on the underlined **assignment14** 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 want to send me comments about your assignment, use email.) 6. Your instructor may also mark the `assignment14` 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!** 7. Your instructor may also mark the files on your CentOS VM after the due date. Leave everything there on your CentOS VM. **Do not delete any assignment work from the CentOS VM until after the term is over!** Use the *exact* file name given above. Upload only one single file of plain text, not HTML, not MSWord. No fonts, no word-processing. Plain text only. Did I mention that the format is plain text (suitable for VIM/Nano/Pico/Gedit or Notepad)? **NO EMAIL, WORD PROCESSOR, PDF, RTF, or HTML DOCUMENTS ACCEPTED.** No marks are awarded for submitting under the wrong assignment number or for using the wrong file name. Use the exact name given above. WARNING: Some inattentive students don’t read all these words. Don’t make that mistake! Be exact. **READ ALL THE WORDS. OH PLEASE, PLEASE, PLEASE READ ALL THE WORDS!** -- | 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 [www.idallen.com]: http://www.idallen.com/ [Class Notes]: indexcgi.cgi#XImportant_Notes__alphabetical_order_ [Assignments]: indexcgi.cgi#XAssignments [CentOS Virtual Machine]: 000_centos_install.html [CentOS VMware Tools]: 000_centos_vmware_tools.html [Checking Program]: #checking-marking-and-submitting-your-work [Course Linux Server]: 070_course_linux_server.html [Booting and GRUB]: 750_booting_and_grub.html [GRUB manual]: http://www.dedoimedo.com/computers/grub.html [The Answer File]: #the-answer-file-answer.txt [CentOS 6 GRUB Menu]: data/centos64_grub_menu.jpg "CentOS 6 GRUB Menu" [CentOS 6 Kernel Options]: data/centos64_kernel.png "CentOS 6 Kernel Options" [CentOS 6 myconfig configuration file]: data/centos64_myconfig1.png "CentOS 6 myconfig configuration file" [CentOS 6 newconfig configuration file]: data/centos64_newconfig1.png "CentOS 6 myconfig configuration file" [1]: 750_booting_and_grub.html#legacy-run-levels-and-services [System Log Files]: 580_system_log_files.html [2]: 750_booting_and_grub.html#starting-and-stopping-services-using-service [Source Directory]: #the-cls-source-directory [Symbolic Link]: 460_symbolic_links.html [Search Path]: 400_search_path.html [File Transfer]: 015_file_transfer.html [Plain Text]: assignment14.txt [Pandoc Markdown]: http://johnmacfarlane.net/pandoc/