3.5. Task Scheduling

Quite often, a certain operation has to be run at a certain time. In this respect, I used to rely on my memory and would launch the necessary application at the required time myself . But after failing a few times to do this due to simply being too busy to pay attention to the clock I placed this task on the computer's silicon shoulders. Come to think about it, why clutter my head space with what the computer can do much better?

If this reason is not good enough, what if some simple but lengthy tasks need to be performed after work hours? What should the administrator do in this case? Stay at work all night? Of course not. The computer can do everything by itself; you just have to tell it what and when has to be done.

3.5.1. Scheduling One-Time Tasks

The simplest, most reliable, and most beloved hacker tool for launching a program at a certain time is the at command. Its simplest format looks like the following:

 at hh:mm dd.mm. yy

The date can be omitted; in this case, the closest date is used. For example, if the time specified is later than the current time, the current date is used; if it is before the current time, then the following date is used, because the command can no longer be executed during the current day.

Consider the usage of the at command on a real-life example. Suppose that you added a new user at the start of a workday who will work only today and only until 12:00. If after this time you forget to delete the user's account, it will present a large hole in your system's security.

So as not to forget to delete the user, you should schedule the deletion at the same time as you create the account for him or her. You start with executing the at command specifying the time as 12:30. Just in case the user does not manage to complete the job assigned by this time, give him or her an extra 20 minutes. Thus, the final command will be the following:

 at 12:50

After you press the <Enter> key, the prompt to enter the command will be displayed:

at>

Enter the commands to be executed at the time scheduled. The user is deleted by the userdel command; also, his or her directory is deleted by the rm command. The necessary command sequence is the following:

 userdel tempuser rm -fr /home/tempuser

The user management subject will be considered in detail in Chapter 4 ; for now, just use these commands. Unless there actually is a tempuser user in your system, the command will not execute, but this is not important because at this point you will be more interested in learning how to run it at the specified time than in actual execution.

Type the preceding commands, pressing the <Enter> key after each one. Press the <Ctrl>+<D> key combination to quit the at command. The system will respond with a text message showing the task identifier and the date and time, at which the commands will be executed. It will look similar to the following:

 Job 1 at 2005-03-03 12:30

The queue of scheduled at tasks can be viewed using the atq command. The results of its execution will look similar to the following:

 1       2005-01-28 12:40 a root 2       2005-01-28 01:00 a root 3       2005-01-30 12:55 a root

In the first column, the task's number is displayed. The task can be manipulated using this number. The second column holds the date for the task's execution; the name of the user who created the task is in the last column.

Now suppose that some urgent processor- intensive job has to be done at the time that the system backup is scheduled to be performed. The backup process will put quite a brake on the other work, and it would be logical to postpone the backup until the job has been finished.

This problem is solved by using the batch command instead of at to schedule the backup. In this case, the execution of the scheduled task will start when the system load drops below the specified value, which is 0.8% by default.

3.5.2. Scheduling Recurrent Tasks

The at command is quite simple and easy to use, but it can be used to schedule only a one-time task. Many administrator tasks (backup, for example) must be run on a recurrent basis. Suppose that your system has to be backed up every day at 10:00 p.m. Preparing the at command every day is not much fun; most likely, you will tire of doing this after a week at the most and will be looking for a way to optimize the task. A script file is not convenient either, because you will have to remember to run it.

The answer to this problem is using the cron program. Using this program requires you to have the crond daemon installed and running. It is also advisable to include it in the start-up.

The crond daemon is controlled with the help of the crontab program. A new entry is added to the schedule by executing the program without any parameters. The program will respond with a blank line, into which the date template and the necessary command can be entered. The format of the filled line is as follows :

 minutes hours day month day_of_week command

The day of the week is specified by a number from 0 to 7, where both 0 and 7 denote Sunday. This is because in different countries the week starts on different days of week: in some it starts on Monday, and in others the week begins on Sunday. In the former, weekdays are denoted by numbers from 1 to 7, and in the latter they are numbered 0 to 6.

Parameters that are not used are filled with an asterisk.

Consider a few examples. Here is the first one:

 00 5 * * * /home/flenov/backup1_script

Here, only the hours and minutes are specified. Because the other parameters are not specified, the command will execute daily at 05:00. The second example:

 00 20 * * 1 /home/flenov/backup2_script

This command executes the same script file every Monday (the weekday parameter is 1) at 20:00. The third example:

 00 * * * * /home/flenov/backup3_script

This command will execute every hour at 00 minutes.

Important

Pressing the <Ctrl>+<D> key combination without entering any commands will delete all previously scheduled tasks. To exit the program without saving the changes, use only the <Ctrl>+<C> key combination.

The cron service also uses several supplementary directories to simplify the scheduling process. Executable scripts are grouped in the following directories:

/etc/cron.hourly
/etc/cron.daily
/etc/cron.weekly
/etc/cron.monthly

It seems simple, but on which day of the week and at what time does a weekly script execute? The answer becomes obvious by examining the /etc/crontab/ configuration file of the cron service. It contains the following entries:

 01 * * * * root run-parts /etc/cron.hourly 02 4 * * * root run-parts /etc/cron.daily 22 4 * * 0 root run-parts /etc/cron.weekly 42 4 1 * * root run-parts /etc/cron.monthly

The appropriate execution time is specified at the start of each entry in the following format: minute hour day month dayofweek .

The execution time can be specified in such a way that scripts from the /etc/cron.monthly directory will execute hourly. So the default names of the execution time directories are purely symbolic and can be easily changed.

Note that there are already scripts in these directories; you should remove all of them that are not necessary to avoid overloading the system, or you should schedule their execution for a different time.

The list of existing tasks (stored in the crontab configuration file) can be viewed by executing the crontab -1 command. The crontab configuration file can be edited by executing the crontab -e command. This will open the file in a text editor, in which you can edit its entries. If you have never worked with this particular text editor, you may have some problems because it is rather specific. If you have any problems, press <F1> to display the help information. Changes become effective immediately upon quitting the editor. To quit the editor without saving changes, type : q! and press <Enter>.

All cron task information is stored as test . For each user, an individual /var/spool/ cron/file crontab file is created. The name of the file is the same as the user's name.

The following is an example of the contents of a crontab file:

 #DO NOT EDIT THIS FILE - edit the master and reinstall. #(- installed on Thu Jan 27 13:55:49 2005) #(Cron version$Id:crontab.c,v2.13 1994/01/17 03:20:37 vixie Exp $) 10 * * * * ls

You can edit this file directly, without using the crontab -e command.

3.5.3. Task Scheduling Security

In conclusion, I want to give some security advice on working with the at command. Hackers like to use this instruction a lot. For example, a hacker may manage to obtain an account with maximum rights. He or she can then use the at command to delete the account and clean up all the traces of entering the system.

There are two files in the /etc directory that you should configure properly:

at.allow Only those users listed in this file have the right to execute the at command.
at.deny Users listed in this file are explicitly denied the right to use the at command.

Similar files exist for the cron service:

cron.allow Users listed in this file have the right to use the cron service. The file may not be created by default.
cron.deny Users listed in this file are denied the right to use the cron service.

I have said it many times and will repeat it again: You should maintain a restrictive configuration policy. This means that you start with disabling all services and denying all users all rights; then you enable the services that are necessary and give the necessary rights to those users that require them. But don't try to list all users in the at.deny file. Instead, create the at.allow file and list in it only your account, which preferably is not the root one. If some users complain that they need to use the at command, make sure that they need it before entering their accounts into the at.allow file.

No stray visitors should be allowed to use the at command. Sometimes, it is better to put up with some griping from an unsatisfied customer than to lose control over the system.

If you do not use the at and cron scheduling commands, I recommend deleting the crond service from the start-up, or, even better, deleting it from the system altogether. You cannot control something that you do not use.

The /etc/crontab file is the configuration file for the cron command. I recommend entering the following entry at the beginning of the file:

 CRONLOG  =  YES

This will enable logging of the commands executed by cron in the /var/cron/log log file.