Return to teamxx. Edit the current crontab file by adding to the existing crontab data a line that executes the sizechk script on the hour, every hour of every day except

Sunday. Once you are done, remove this particular entry so it does not drive you crazy the rest of the week. Verify that it was removed.

__ 22. Switch to root. Examine the file /etc/inittab and notice how the cron daemon actually gets started. cron will respawn if it is not running. Why is this important?

_______ Log off.

END OF LAB

EXempty

Exercise Instructions with Hints

Using at

__ 1. Log in as teamxx. Submit a single at job that will immediately echo the message Running an at command and then echo another message This is it! Check your mail. Notice the shell script name assigned to your job.

• $ at now

echo Running an "at" command echo This is it!

<ctrl-d>

• $ mail

• Hint! Wait for a minute or so for the mail daemon to respond and keep checking for new mail.

__ 2. Repeat the above instruction, but this time force your output to your screen. (Hint:

Use the tty command to get your device name.) • $ at now

echo Running an "at" command > /dev/xxxx (xxxx is replaced by your device name)

echo This is it! >/dev/xxxx

<ctrl-d>

• Hint! Enter tty at the command line to find out what your /dev/xxxx device name is.

__ 3. Experiment with the time specifications of next week and next month.

• $ at now next week

__ 4. Let's take a look at the environment when an at job executes. Change directory to /etc. Submit an at job that will return the current directory to your screen and have it execute in one minute. Now change directory to /var/adm and repeat the at request.

Change directory to the /(root) directory list the queued jobs then wait for the execution of your two jobs. What can you deduce?__________

• $ cd /etc

• $ at now +1 min

echo $PWD >/dev/xxxx (xxxx is device you are using)

<ctrl-d>

• $ cd /var/adm • $ at now +1 min

echo $PWD >/dev/xxxx (xxxx is device you are using)

<ctrl-d>

• $ cd / • $ at -l

(Wait for your jobs to run)

__ 5. You should now have several at jobs scheduled. su to root to give yourself proper permission for viewing these jobs. Change to the directory /var/spool/cron/atjobs.

Examine some of the files in this directory and notice the additional statements that are created for the at job besides the ones that the user entered.

Note: pg won't work very well because lines get truncated. For one thing, you should see that the directory for the at job does indeed get set specifically within the at job itself. If the contents of the file looks disjointed, it is because nulls are used as field delimiters within the file. When you have finished, return to your teamxx ID.

• $ su root

• # cd /var/spool/cron/atjobs • # ls -l

• # cat <filename>

• # <ctrl-d>

__ 6. As teamxx, list your at jobs. Use the appropriate option to cancel several of them.

Note: You need to specify the whole name.

• $ at -l

• $ at -r <jobname>

__ 7. Switch to root to gain proper permission to view the security files. Page the

/var/adm/cron/at.deny file. Notice there are no entries. What security implications does this have? For this exercise we won't modify this file, but if we were to, we would put one userid on each line for whom we wanted to deny access. Notice, also, that there is no at.allow file. Kill the subshell and return to teamxx.

• $ su

root's Password: (enter password) • # cd /var/adm/cron

• # pg at.deny

• # ls -l /var/adm/cron

(Notice there is no at.allow file.) • # exit

EXempty Using batch

__ 8. As teamxx, submit two jobs to batch that will output the result of the date command to your screen after waiting 60 seconds (Hint: sleep 60). If you are a slow typist, you may want to wait 90 seconds. Remember, it is submitted exactly like an at job but without a date and time because the submittal time is determined by the queue definitions in the /var/adm/cron/queuedefs file. Since this file, by default, says to take a job every 60 seconds, you should still see one job in the batch queue. List the jobs in the queue.

• $ batch sleep 60

date > /dev/xxxx

<ctrl-d>

• Repeat the batch again • $ at -l

Using crontab Files

__ 9. Switch to root. Make sure you are still in the /var/adm/cron directory. Display the contents of the cron.deny file. Also, look in the directory to see if a cron.allow file exists.

• $ su

root's Password: (enter password) • # cd /var/adm/cron (if necessary) • # pg cron.deny

• # ls -l

__ 10. Create a shell script in /usr/local/bin called ledclock to:

__ a. Call the program /usr/lib/methods/showled to write on the led.

__ b. Display the hour (24-hour clock) as a decimal number by using the date command.

__ c. Display the minutes as decimal number (00-59) by using the date command.

__ d. This value is shown on LEDs in hexadecimal format, therefore transfer it back to decimal.

__ e. Make the script executable.

• $ mkdir -p /usr/local/bin • $ cd /usr/local/bin

• $ vi ledclock

#!/bin/ksh

/usr/lib/methods/showled 0x‘date +%H%M‘

• $ chmod 750 ledclock __ 11. Test your script.

• $ /usr/local/bin/ledclock

__ 12. Create a file called cron00 that will cause ledclock to be invoked every minute for now on. Remember to use full path names for commands used in cron. Remember, there can be NO blank lines in the file including pressing Enter after the last entry.

• $ vi cron00

* * * * * /usr/local/bin/ledclock > /dev/null 2>&1

__ 13. Place your crontab file in the crontabs directory via the crontab command. Wait for