3.1 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.2 The Source Directory

All references to the “Source Directory” below are to the CLS directory ~idallen/cst8177/14w/assignment07/ and that name starts with a tilde character followed by a userid with no intervening slash.

4.1 Set Up – The Base Directory

1. Do a Remote Login to the Course Linux Server (CLS) from any existing computer, using the name appropriate for whether you are on-campus or off-campus. All work in this assignment must be done on the CLS.

2. Make the directory ~/CST8177-14W/Assignments/assignment07, in which you will create the files and scripts resulting from the following tasks.

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

Run the Checking Program to verify your work so far.

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.

1. Using the directions in this section, write a script that shows processes that are owned by a particular user and have a particular process name. The userid and the name to search for in the process list will be given on the command line as two arguments to the script. The script will use the ps command and a pipeline of one or more commands to select only those ps output lines that match the userid and the name.
   1. Name the script process_id.sh
   2. The script takes two arguments, the first is the username of the process owner, and the second is the name of the process:
      • ./process_id.sh username process
      • The active part of the script will be one line long (a pipeline). A perfect solution needs only two commands separated by one pipe.
      • That one line will be preceded by code to check the number of arguments (two 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 must print one or more lines containing the process ID of every command with the given process name owned by the given username.
   4. 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.
   5. The process ID does not have to be the only thing on the output line. The output lines may contain other information, or you can optionally process the lines to only show the process ID field.
   6. The script should only show lines for processes owned by the given userid.
   7. The script should not show any lines for partial userids such as roo or oot. (Test this!)
   8. Avoid printing lines from ps that look like process names. Often, the script will incorrectly print the grep command that is being used to select the right ps output line inside the script; don’t do that. Show only the required output.
   9. Hints: Refer to your work on process listings from Assignment #02 Task 4.6
   10. Hints: Do not use any options to ps that show all processes! Use only the two options described next:
   11. Hints: The ps command has a useful option to display only processes with a particular command name. Using this option to select only lines that contain that command name makes the script much simpler, since otherwise it is tricky to use grep to match a process name in the middle of a line of ps output. If you don’t use this option to ps (use the option!), you must select the process name carefully by choosing some surrounding context from the output lines using grep.
   12. Hints: In addition to the option that selects command name, you will need an option to make ps generate a userid at the start of every output line. See the man page for either the full-format or user-oriented output format. Once you have selected lines that have the right command name, selecting lines containing the correct userid is easy since the userid field can always be matched anchored at the start of every line.
   13. Hints: Make sure that when you search for a userid in the output of ps that you use a pattern that ensures that the entire userid is matched and not just a prefix or a suffix. The script should not show any lines for partial userids such as roo or oot. (Test this!)
   14. Test your script. Can the script find the process number of itself when it runs? ./process_id.sh "$USER" process_id.sh
2. Let’s use the above script to find a process to kill. First, we need to run a test process to kill:
   1. Run the script signaltrap.sh which is located in the Source Directory. You’ll notice this script doesn’t print anything – 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 or stopped.
   2. Type ^C to try to interrupt this script process (send it an INT signal).
      • Notice that the process did not do the normal thing (die) upon receiving the INT signal. It “caught” the signal and refused to die.
      • The script creates a log file in the current directory named signaltrap_output.
   3. Type ^Z to send a STOP signal to the script process.
      • You will get your bash prompt back and see a message about the script process being Stopped by the signal.
   4. Use bg to resume the script process running in the background.
   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).
   7. Finally, send the signaltrap.sh process a KILL signal.
      • KILL signals can’t be ignored, so it should be gone – verify this.
   8. Find a PID of any process owned by root or by another user, and try sending it a KILL signal (or any signal).
      • Notice that regular users cannot kill other users’ processes.

Run the Checking Program to verify your work so far.

4.3 The Temperature Script

Before you write any scripts, re-read the above section with the title Review of How To Write and Test Scripts.

1. Create a simple Ottawa Temperature script that pulls the temperature from the appropriate Environment Canada XML RSS page.
   • Refer to work with pipes and web pages shown in CST8207 Examples of Pipes. Scroll down to the Ottawa weather temperature example that fetches the temperature using the XML RSS feed.
   1. As shown in the above example, use the text browser elinks with the given options (reproduced below) to retrieve the current Ottawa temperature from the given XML RSS feed URL:
      • elinks -dump -no-numbering -no-references URL
      • Note: If a URL contains shell meta-characters, such as ?, you must quote the URL to prevent expansion by the shell. Hide all special characters in the URL from the shell.
      • elinks defaults to fetching pages using the UTF8 character set, which may not display well on your screen. You can change the character set using the elinks -dump-charset option followed by the name of a new character set. (Try the names ascii, latin1 or the default utf8.)
   2. Following the example given in the CST8207 page above, pipe the elinks output into fgrep to extract the line containing the word Temperature: from the XML RSS page. The pipeline will print one line of current temperature from the XML RSS page.
      • If the degree special character between the temperature number and the letter “C” doesn’t display correctly (e.g. “10°C”), you may need to reconfigure PuTTY for the UTF8 character set. (Remember to save your PuTTY settings.)
   3. Put the above pipeline into a script named temperature.sh that prints out the current temperature for Ottawa.
      • The active part of the script will be one line long (a pipeline). A perfect solution needs only two commands separated by one pipe.
      • 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!
      • Do not create or use an alias in your script; use the full elinks command line with the correct URL. (Scripts never use aliases, since aliases are meant to save typing by humans, not by scripts.)
      • You should see only the one line of temperature output on your screen when you run the script correctly.
   4. Test your script. Did your script validate the (lack of) arguments and produce a Good Error Message if there are any?
2. Create a hard link to the temperature.sh script in your own bin/ directory and name the link otemp
   • 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.4 of Assignment #02?)

Run the Checking Program to verify your work so far.

4.4 Sending information using a mail command

System administrators often have systems send them automated email. 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. Optional: If you are interested in trying a power-user text-mode mail client for everyday interactive use, try mutt (man mutt).

1. Read the man page for the mail command and try sending yourself email from the CLS to your own email account:
   1. echo "Testing mail command." | mail -s "Test" abcd0001@algonquinlive.com
      • Replace the abcd0001 with your own Algonquin email address.
      • You can pipe any text standard output into the mail program.
      • Do not send binary data this way; it won’t work. Text Only
      • You can use a similar command to send to any of your email accounts.
   2. Following the above model, 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. “10°C”), you can try adding either -dump-charset latin1 or -dump-charset ascii to the elinks command line in your temperature.sh script.
   3. Optional: You can try using an SMS Gateway List to find the email address of your SMS enabled phone, and email any text message 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 on your phone (e.g. “10°C”), you can try adding either -dump-charset latin1 or -dump-charset ascii to the elinks command line in your temperature.sh script.
2. Create a script called mail_temperature.sh that will use your temperature.sh script and email the current Ottawa temperature to your Algonquin email address (or to your phone). (You already know what command line will do this, from above.)
   • The active part of the script will be one line long (a pipeline). A perfect solution needs only two commands separated by one pipe.
   • 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!
   • 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.
   • Use pipes; do not use any output or input temporary files.
   • 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).
   • 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.)
   • Did you use an absolute pathname to temperature.sh in your script?
3. Create a hard link to the mail_temperature.sh script in your own bin/ directory and name the link mail_temperature
   • Verify that you can now type simply mail_temperature at a shell prompt to have the temperature sent to you by email. (If this command isn’t found, perhaps you haven’t set your PATH in your .bashrc as required in Section 4.4 of Assignment #02?)
4. Optional: Since sysadmin are generally lazy, and mail_temperature is a very long name to type, find a way to create another name for this script that is shorter and faster to type. (You choose the name; nobody is looking.) (Hint: Perhaps another hard link in your bin/ directory, or perhaps create a shorter shell alias?)

Run the Checking Program to verify your work so far.

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

1. Read the course notes and 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. In this 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 that runs the date command every minute.
   • Save the file and exit the editor to enable the new crontab file.
   • If you don’t redirect the output of your crontab command lines into a file, the output will be sent to you by email. You will need to use the mail program to see the emailed output generated by your cron jobs.
   • Use the crontab command to edit and experiment with other valid crontab lines that run in the near future.
   • Use the crontab command to remove the test crontab when you know enough about how to create working cron jobs.
4. Now, create a crontab designed to run your mail_temperature program at 10:14am on the first day of every month.
   • Use this basename as part of a relative pathname to this program (in your bin/ directory) and use this time/date.
   • First, 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, change the time to be exactly the 10:14am time and first month day for marking.
   • You can create this crontab file correctly even if you have not got a working mail_temperature script. (Of course you won’t receive the correct output without a working mail_temperature 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:14 on the first day of every month.

6. Repeat the above command and redirect the contents of your current live crontab file into a mail_weather.crontab text file in the base directory. (It should be one valid crontab line.)

In your cron job, did you use a relative path to the mail_temperature script name (the name 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 mail_temperature program in your bin/ directory.

Run the Checking Program to verify your work so far.

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

1. Read the course notes and the man page for the at command and note the syntax used to schedule an at job in the future. Experiment with some at command lines that run in the near future to make sure you know how it works. (If you don’t redirect the output of your tests, the 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.)
2. Use the at command to schedule a run of your mail_temperature program at 09:00am, December 25, 2014. Use this basename as part of the absolute program pathname and use this exact time/date to schedule your at job. You will need to experiment with times in the near future while you are testing the at command to make sure it works, but make sure you leave one correctly dated at job queued for marking.
   • You can create this at job correctly even if you have not got a working mail_temperature script. (Of course you won’t receive the correct output without a working mail_temperature 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 mail_temperature script name (the name is located in your own bin/ directory)?

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