3.1 Save your work

You will create file system structure in your HOME directory on the CLS, with various directories, files, and links. When you are finished the tasks, leave these files, directories, and links in place as part of your deliverables on the CLS. 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.

3.2 The Source Directory

All references to the “Source Directory” below are to the CLS directory ~idallen/cst8177/14f/assignment07/ and that name starts with a tilde character ~ followed by a user name 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 Searching the course notes

The previous term’s course notes are available on the Internet here: CST8207 GNU/Linux Operating Systems I. All the notes files are also 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.

3.4 Review of How To Write and Test Scripts

Some of the tasks below ask you to write a small executable shell script, based on the lecture notes and slides. All scripts should begin with the Script Header you used for your previous assignments. When you have completed each script, ensure that it is executable, so that it can be run in the current directory as ./scriptname.sh.

Some scripts contain simple one-line pipelines. You can first create these pipelines on the command line, get them working correctly, then copy the working pipeline into the script file when it works. It is much faster to test and fix the pipeline on the command line instead of editing and saving the script file over and over.

When you have completed each script, ensure that it is executable, so that it can be run as ./scriptname.sh.

Scripts must validate their arguments, even if they take no arguments. (A script that takes no arguments must not run if you give it arguments, since clearly you don’t know how to use it.) Error messages must be written in the style of Good Error Message, as you did in the previous assignment. Always follow the Good Error Message with a Usage message that says how the script should be run.

Scripts that have usage errors should exit with a non-zero exit code, indicating something went wrong.

Run the given tests on your scripts to make sure they work. Sample output for each of the scripts is given, so that you may check your work as you proceed. Make sure your script handles all of the sample inputs given, especially the inputs containing shell metacharacters. (System crackers often attack your system using special characters as input.)

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. All work in this assignment must be done on the CLS.

2. Make an assignment07 directory in the same directory as you made assignment02 in a previous assignment.

This assignment07 directory is the Base Directory for most pathnames in this assignment. Store your files and answers in this Base Directory.

3. Follow the instructions in the first two steps at the start of Checking Program below to create a working symbolic link to the executable Checking Program.

Check your work so far using the checking program symlink.

4.2 The Processes Script

• Before you write any scripts, re-read the above section with the title Review of How To Write and Test Scripts.
• The material from last term on Processes may be useful.

Using the specifications below, write an executable script named process_id.sh that shows information about processes that are owned by a given user name and have a given command name. Use the Hints below to help you.

1. The process_id.sh script must start with the correct Script Header lines.

2. The script takes exactly two arguments. The first is the user name of the process owner, and the second is the command name of the processes to show:
   • ./process_id.sh user_name command_name

3. The script must print zero or more lines containing process information about every process with the given command_name owned by the given user_name (if any).

4. The script should show only lines for processes owned by the given user_name and with the given process_name.

5. The script must not show any lines for partial user names such as roo or oot or partial process names such as bas or ash. Both names given by the user must match fully in the output of ps.

6. The script must print a Good Error Message and Usage message if it doesn’t receive exactly two command line arguments, and exit with an exit status of 2.

7. The script does not have to validate the user name or produce any error message if no lines of output are generated. Failing to match any processes is not an error.

$ ./process_id.sh "$USER" process_id.sh
abcd0001 9170 0.0 0.0 4400 612 pts/2 S+ 10:25 0:00 /bin/sh -u ./process_id.sh abcd0001 process_id.sh
$ ./process_id.sh "$USER" bash
abcd0001 1647 0.0 0.0 26344 2740 pts/2 Ss Oct22 0:00 -bash
$ ./process_id.sh "$USER" sshd
abcd0001 1643 0.0 0.0 90508 1308 ? S Oct22 0:02 sshd: abcd0001@pts/2
$ ./process_id.sh root cron
root 3574 0.0 0.0 19112 860 ? Ss Oct22 0:03 cron
$ ./process_id.sh root sshd | wc -l
10                                          # should find at least two
$ ./process_id.sh oot sshd | wc -l
0                                           # no such user name
$ ./process_id.sh roo sshd | wc -l
0                                           # no such user name
$ ./process_id.sh sshd sshd | wc -l
0                                           # no such user name
$ ./process_id.sh root s | wc -l
0                                           # no such process name
$ ./process_id.sh sshd root | wc -l
0                                           # no such user or process
$ ./process_id.sh one
./process_id.sh: Expecting two arguments, found 1 (one)
Usage:  ./process_id.sh user_name command_name
$ ./process_id.sh one two three
./process_id.sh: Expecting two arguments, found 3 (one two three)
Usage:  ./process_id.sh user_name command_name

4.3 A Signal Trap Test

Let’s use the above script to find a process and then send it some signals.

We are going to be running a shell background process for this test. Normally, the shell won’t tell you anything about your background processes until you push the Enter key and get a shell prompt. To get immediate notification, set the notify shell option as described in last term’s Login and Shell Startup Files.

1. First, we need to run a test process to receive the signals: Run the script signaltrap.sh which is located in the Source Directory. You’ll notice this script starts and doesn’t finish – it just sits there doing nothing, and you don’t get your bash prompt back because the script isn’t finished yet. The bash prompt won’t appear until the script process is finished, killed, or stopped.
   • The script creates a log file in the current directory named signaltrap_output. Do not delete this log file.
2. Type ^C to try to interrupt this script process.
   • Recall that typing ^C at a keyboard sends the foreground process an INT (interrupt) signal. Most processes die when they receive an interrupt signal.
   • Notice that the signaltrap.sh process did not do the normal thing (die) upon receiving the INT signal. It “caught” the signal, printed and logged a message, and refused to die.
3. Type ^Z at the keyboard to send a STOP signal to the signaltrap.sh process.
   • You will get your bash prompt back and see a message about the process being Stopped by the signal.
   • The shell built-in jobs command will list this as a Stopped process.
4. Use bg to resume the script process running in the background.
   • The process will resume, but the shell will not wait for it to finish. You get your shell prompt back and can enter other commands while the background process runs.
5. Use your process_id.sh script from above to find the process id of this background script process.
   • Be sure your script finds your process, not any other process!
   • If your process_id.sh script can’t find signaltrap.sh you may need to adjust it to find commands that are shell scripts. (This may be tricky if you aren’t using the ps option described in the Hints for the ./process_id.sh script.)
6. At your command prompt, send the signaltrap.sh script process a TERM signal (terminate) and notice that this too didn’t make the process do the expected terminate action (clean up and die).
   • The script traps and does not die on many signals. You can read the script to see which ones are handled with trap.
   • Read the messages that the script writes into its log file.
7. Finally, send the signaltrap.sh process a KILL signal.
   • KILL signals can’t be ignored, so it should be gone – verify this.
   • The shell built-in jobs command will show that the process is gone.
   • Do you know why the script didn’t write a log message when it received the KILL signal?
8. Find a PID of any process owned by root or by another user, and try sending it a KILL signal (or any other signal).
   • You will see an Operation not permitted error message.
   • Regular users cannot kill (send signals to) other users’ processes.
   • Re-run the command and append the error message to the signaltrap.sh log file, below all the other log messages. Do not accidentally erase the messages in the log file!
   • Verify that the log file contains several log messages and ends with the above error message as the last line.

Run the Checking Program to verify your work so far.

4.4 The Temperature Script

• Before you write any scripts, re-read the above section with the title Review of How To Write and Test Scripts.
• The material from last term on Examples of Pipes may be useful.

Using the specifications below, write an executable script named temperature.sh that extracts the current Ottawa Temperature from the appropriate Environment Canada XML RSS page. Use the Hints below to help you.

1. The temperature.sh script must start with the correct Script Header lines.

2. The script will accept no arguments.

3. The script will print one line containing the current Ottawa Temperature, e.g. Temperature: 6.4°C

4. The script must print a Good Error Message and Usage message if it receives any command line arguments, and exit with an exit status of 2.

5. Create a hard link to the temperature.sh script in your own bin/ directory and name the link otemp

6. Verify that you can now type simply otemp at a shell prompt to have the one line of current temperature display.
   • If this command isn’t found, perhaps you haven’t set your PATH in your .bashrc as required in Section 4.3 of Assignment #02?

$ ./temperature.sh
   Temperature: 6.4°C
$ otemp
   Temperature: 6.4°C
$ ./temperature.sh one two three
./temperature.sh: Not expecting any arguments, found 3 (one two three)
Usage:  ./temperature.sh
$ otemp one two
/home/abcd0001/bin/otemp: Not expecting any arguments, found 2 (one two)
Usage:  /home/abcd0001/bin/otemp

4.5 Sending information using a mail command

System administrators often have systems send them automated EMail. You will build a script that uses EMail to send you the Ottawa temperature. (You can optionally send the temperature to your mobile phone.)

• There are many text-mode EMail clients (“Mail User Agents”) for Linux. This assignment uses the one named mail, which is fairly standard and fairly small, which makes it ideal for use in sending EMail inside scripts. Learn about EMail on the CLS.
• Optional: If you are interested in trying a power-user text-mode mail client for everyday interactive use, try mutt and read man mutt on the CLS.

1. Learn about EMail on the CLS, skim over the man page for the mail command, and try sending yourself EMail from the CLS to your own EMail account using this pipeline:
   • $ echo "Testing mail" | mail -s "Test" abcd0001@algonquinlive.com
   • $ who | mail -s 'See who list' abcd0001@algonquinlive.com
   • Replace the abcd0001 with your own Algonquin Live EMail address, or use your own personal EMail address instead.
   • You can pipe any text standard output into the mail program; try replacing the command on the left of the pipe with ls or date or any command that generates standard output that you can redirect.
   • Do not send binary data this way; it won’t work. Text Only
   • You can use a similar command to send EMail to any of your other EMail accounts.
2. Following the above syntax, EMail the one line of standard output of your above temperature.sh weather script to your Algonquin EMail address with the subject: Current Ottawa Temperature
   • If the degree special character between the temperature number and the letter C doesn’t display correctly in your EMail (e.g. 6.4°C), read the Hints above about option -dump-charset.
3. Create a script called mail_temperature.sh that will use your temperature.sh script and the above EMail syntax to send the current Ottawa temperature to your Algonquin EMail address. (Use the working command line from above.)
   1. The active part of the script will be one line long (a pipeline). A perfect solution needs only two commands separated by one pipe. Use pipes; do not use any output or input temporary files.
   2. That one line will be preceded by code to check the number of arguments (no arguments), plus some lines for the Script Header. As with many one-line scripts, the code needed to check the arguments greatly exceeds the code that does useful work!
   3. The script will use an absolute pathname to your existing temperature.sh script to generate the one line of temperature data for the script pipeline.
   4. Do not duplicate the elinks line inside this new mail script; your new script must EMail the output created by running your temperature.sh script (that contains the elinks line).
   5. You can create this script correctly even if you have not got a working temperature.sh script. (Of course, you won’t be able to fully test it without a working temperature.sh script.)
4. Create a hard link to the mail_temperature.sh script in your own bin/ directory and name the link omt (Ottawa Mail Temperature).
   • Verify that you can now type simply omt at a shell prompt to have the temperature sent to you by EMail. (If this command isn’t found, re-read the note about PATH above in the temperature script section.)

Run the Checking Program to verify your work so far.

• Optional: You can try finding and using an SMS Gateway List to find the EMail address of your SMS enabled phone, and EMail any text message from the CLS directly to your phone. (May be subject to length restrictions and incur an arbitrary delay.)
• If the degree special character between the temperature number and the letter C doesn’t display correctly in your EMail (e.g. 6.4°C), read the Hints above about option -dump-charset.

4.6 Scheduling repeated tasks with crontab

The crontab command is used to create tasks that are run repeatedly by the system cron daemon program. These are commonly called cron jobs. You can create personal cron jobs. There is also a system file containing system cron jobs that only the super-user can edit.

If you don’t redirect all the output of command lines used in a cron job, any output will be sent to you by EMail. You will need to use the mail program to read the EMailed output generated by your cron jobs. Learn about EMail on the CLS.

1. Read the course notes and the skim the man page for the crontab command.

2. Run the CLS command select-editor to choose a text editor for use by the crontab command. (Isn’t it time you learned some vim?)

3. Run crontab -e to start the selected text editor to edit your personal crontab file.
   • Your personal crontab file opens in the text editor with a list of helpful comments, but no actual commands are scheduled.
   • Use the text editor to add valid crontab commands to the bottom of the file, below the comments. The commands you add will not take effect until after you save the file and exit the text editor.
   • Experiment by creating a crontab line that runs in the near future to make sure you know how cron jobs work: e.g. create a crontab line that runs the date command every minute, save, and exit. Wait a minute for the command to execute.
   • See the note above about where the date output will be sent. Learn about EMail on the CLS.
   • Use the crontab command again to edit and experiment with other valid crontab lines that run in the near future, e.g. two minutes from now, etc.
   • Use the crontab command to remove the test commands from your personal crontab when you know enough about how to create working cron jobs.
4. Now, create a crontab line designed to run your omt program (located in your bin/ directory) at 10:41am on the first day of every month.
   • Use a relative pathname to run your omt program in your bin/ directory.
   • Testing: Create and save your crontab using times in the near future while you are testing your cron job to make sure it works.
   • When you know your job works in the near future, change the time to be exactly the time required for marking.
   • You can create this crontab file correctly even if you have not got a working omt script. (Of course you won’t receive the correct output without a working omt script.)

5. Use the crontab command with option that lists the contents of your current live crontab file. Make sure your displayed cron job is scheduled for 10:41 on the first day of every month.

   Repeat the above command and redirect the contents of your current live crontab file into an omt.crontab text file in the Base Directory. (It should contain one valid crontab line at the bottom of all the comments.)

In your cron job, did you use a relative path to the omt script name (the name that is located in your own bin/ directory)? You need to know in which directory the cron job runs, to create the correct relative path to the program in your bin/ directory.

Run the Checking Program to verify your work so far.

4.7 Scheduling a command once with at

The at command is used to create a task that runs only once at some future date and time. These are commonly called at jobs. There is no system file of at jobs, since these jobs only run once.

If you don’t redirect all the output of command lines used in an at job, any output will be sent to you by EMail. You will need to use the mail program to see the EMailed output generated by your at jobs. Learn about EMail on the CLS.

1. Read the course notes and skim the man page for the at command and note the syntax used to schedule an at job at a time and date in the future. Experiment with some at command lines that run in the near future to make sure you know how it works.
2. Use the at command to schedule a run of your omt program (located in your bin/ directory) at 08:00am, December 25, 2014.
   • Use an absolute pathname to your omt program in your bin/ directory.
   • Testing: Experiment with times in the near future while you are testing the at command to make sure it works.
   • When you know your job works, change the time to be exactly the time required for marking.
   • You can create this at job correctly even if you have not got a working omt script. (Of course you won’t receive the correct output without a working omt script.)
3. Learn the command that displays a list of your scheduled at job numbers and display the list to make sure your December 25 job is there.

In your at job, did you use an absolute path to the omt script name (the name is located in your own bin/ directory)?

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