Run Automated System Tasks with ANACRON

started at system boot up and exits when there are no more jobs to run. Upon start-up, Anacron reads the list of configured jobs from the Anacron table. For each job, it checks whether the current job has been executed in the last ‘n' days. If not, Anacron waits for the number of minutes specified as the delay parameter in the Anacron table, and starts executing the job. After this is done, it records the job execution date in a special timestamps file. At the next system boot up cycle, this timestamps file is checked to decide whether there is a need for a particular job to be executed or not. Anacron makes sure that only one instance of a job runs at a time by using a locking mechanism. After executing all jobs, Anacron exits.

Understanding the Anacron table

Now that we have understood the need for Anacron and its lifecycle, let us explore the format of the Anacron table. In the Anacron table, each field is separated by a space or a tab character. Shown below is the format of the Anacron table:

{period} {delay} {job-identifier} {command(s)}

OR

{@period_name} {delay} {job-identifier} {command(s)}

Table 1 describes each field of the Anacron table.

Table 1

Field Description

period This is a numeric value, which can be specified in days only. delay This can be specified in minutes. After starting, Anacron waits for the ‘n' number of minutes specified as the delay parameter, before actual job execution. job-identifier This is the name of the timestamps file and should be unique for each job. Before job execution, Anacron examines the timestamps file to decide whether job execution is needed or not. command This field, which is self-explanatory, can be a shell command or script.

Anacron provides a special string value that can be used in place of the period field. The currently supported value for this field is @monthly. This ensures that jobs will be executed once a month, regardless of the number of days in the current or previous month.

Anacron also allows the assignment of values to environment variables in the Anacron table. Please note that Anacron tables are parsed from top to bottom; hence, any environment settings are applicable only to those commands that are specified after setting environment variables. By default ‘SHELL' is set to /bin/ sh. ‘HOME' is the home directory of the user. ‘LOGNAME' is the name of the user executing the Anacron job. The default value of ‘PATH' is /usr/bin:/bin.

By default, after successful command execution, the output is mailed to the owner of the Anacron table (usually the root user). This default behavior can be overridden by setting up a ‘MAILTO' environment variable. If ‘MAILTO' is set up and is not empty, then the output of the command is mailed to the user so named. In ‘MAILTO', multiple recipients can be specified by a comma separated list. If the empty value is assigned to ‘MAILTO' (e.g., MAILTO="" ), then no mail is sent. In the Anacron table, we can assign values to environment variables in the same manner as shell assignment. The simple example given below will give you a clearer idea about the usage of environment variables.

[root]# cat /etc/anacrontab # Set environment variables. SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/ usr/bin HOME=/root LOGNAME=root MAILTO="jerry@acme.com"

# These replace Cron's entries 1 5 cron.daily run-parts --report /etc/cron.daily 7 10 cron.weekly run-parts --report /etc/cron.weekly @monthly 15 cron.monthly run-parts --report /etc/cron. monthly

Additionally, Anacron provides two more variables (given below) that control the scheduled time of the configured jobs. 1) RANDOM_DELAY: This is the maximum number of minutes that will be added to the delay field of each job.

The minimum possible value for this variable is 6 minutes.

Here is an example. Let us suppose the value of

RANDOM_DELAY is 20 minutes and the value in the delay field is 10 minutes. Then, before job execution,

Anacron will wait for 10 minutes (from the delay field) + a random number of minutes between 6-20 (because of

RANDOM_DELAY). 2) START_HOURS_RANGE: Anacron overcomes one of the major drawbacks of Cron. If an Anacron job is scheduled for a particular time interval and the system is not running at that time, Anacron guarantees that the job will be executed when the system comes up. But here is a catch.

What if the system does not go offline? When should the job be executed? The solution is to specify this range by defining the START_HOURS_RANGE variable.

For example, if the value of START_HOURS_RANGE is ‘1218', then Anacron jobs can be run between 12 a.m. and 6 p.m.

If START_HOURS_RANGE is defined and that time interval is missed, for example, because of a power outage,

then the job will not run for that particular day.

Playing with Anacron tables

The two files below play an important role in the Anacron lifecycle. ƒ /etc/anacrontab: This is a configuration file, which stores the Anacron table and describes the jobs controlled by it. ƒ /var/spool/anacron: This is the default spool area used by

Anacron to store timestamps files.

Anacron stores its table in the /etc/anacrontab file. To create or edit an Anacron table, edit the /etc/anacrontab file directly using your favourite text editor. Please note that the user must be privileged to edit the Anacron table. An Anacron table file might look like the example listing below:

[root]# cat /etc/anacrontab # Set environment variables. SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/ usr/bin

1 5 cron.daily run-parts --report /etc/cron.daily 7 10 cron.weekly run-parts --report /etc/cron.weekly @monthly 15 cron.monthly run-parts --report /etc/cron. monthly

Additionally, we can instruct Anacron to use a specified Anacron table rather than the default one. Anacron's ‘-t' option will do the needful. Let us check it out with an example.

Jerry has written his Anacron table in the jerry.anacrontab file and it has the following contents:

[jerry]$ cat /home/jerry/jerry.anacrontab # Set environment variables. SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/ usr/bin LOGNAME="jerry" HOME="/home/jerry" MAILTO="jerry@acme.com"

1 5 jerrcron.daily /home/jerry/daily_maintenance.sh 7 10 jerrycron.weekly /home/jerry/weekly_maintenance.sh

To use the above file as an Anacron table instead of the default one, execute the following command:

[jerry]$ anacrontab -t /home/jerry/jerry.anacrontab

This method is useful for a non-root user to run Anacron. To execute a job successfully, Anacron needs its table in a particular format. It is good practice to check the Anacron table for syntax errors. One of the lengthy ways to test it is to copy the Anacron table to the test machine and verify it by executing jobs. It's better to identify those syntax errors by static analysis, i.e., without running an actual job. Anacron provides the ‘-T' option. Using it, we can validate the Anacron tables. It validates the syntax of the Anacron table and if errors are found, it reports them on the standard error stream and sets the command exit status to 1. Let us check this out with an example.

We know that Anacron does not support the ‘@hourly' string. Let us deliberately insert it into the Anacron table. Given below is an example of an Anacron table with a syntax error:

[jerry]$ cat /home/jerry/jerry.anacrontab # Set environment variables. SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/ usr/bin LOGNAME="jerry" HOME="/home/jerry" MAILTO="jerry@acme.com"

1 5 jerrcron.daily /home/jerry/daily_maintenance.sh 7 10 jerrycron.weekly /home/jerry/weekly_maintenance.sh

@hourly 10 jerrycron.hourly /home/jerry/check_disk_space.sh # Here is error.

Now, validate the Anacron table for syntax errors.

[jerry]$ anacron -t /home/jerry/jerry.anacrontab -T Anacron: /home/jerry/jerry.anacrontab: Unknown named period on line 10, skipping

Also verify the exit status of command.

[jerry]$ echo $? 1

Running Anacron

We have completed our discussion on Anacron tables. Let us now look at different ways of running Anacron.

Running Anacron at system start-up: If your system’s start-up and shut-down cycles are very frequent, then launching Anacron at the time of system boot-up is a good choice. Upon system start-up, Anacron can check the list of configured jobs and execute them, if necessary.

For the Ubuntu GNU/Linux distribution /etc/init/Anacron. conf is Anacron's start-up script which runs all the jobs from / etc/anacrontab. The contents of the /etc/init/Anacron.conf file might vary from version to version. If you are running any other GNU/Linux distribution, then go through your distribution’s documentation to find out or write the Anacron start-up script.

Running Anacron via Cron: Another popular way to launch Anacron is to run it via Cron. If your computer shuts

down or starts up less frequently, then this is a good choice. To launch Anacron via Cron, create a Cron table entry in the / etc/crontab file:

@hourly * * * * root anacron

For the job above, Cron executes Anacron once every hour, and Anacron executes jobs only if necessary.

Running Anacron via a non-root user: In our earlier discussion, we have seen how the root user can run Anacron. But it is a very common requirement to execute Anacron via an ordinary or non-root user. We can achieve this by simply creating a private Anacron table and by specifying a different spool area. To run Anacron via an ordinary user add the following entry into the user's Cron table or execute Anacron via login scripts:

crontab -t /home/jerry/jerry.anacrontab -S /home/jerry/ crontab_spool

…where the ‘-t' option is used to specify a private Anacron table and the ‘-S' option is used to specify the spool area that stores the timestamps file.

Insights about Crontab

Anacron is sensitive to signals. The signal ‘SIGUSR1' can be used to stop Anacron gracefully. After receiving the

For any queries, please contact our team at efyenq@efy.in OR +91-11-26810601 ‘SIGUSR1' signal, if there are any running jobs, Anacron waits to finish them and exits gracefully. To know more about signals, refer to the manual page of the ‘kill' command from your distribution.

By default, Anacron forks out and creates child processes. The parent process exits immediately and child processes start their execution in the background. By providing the ‘-d' option, we can instruct Anacron not to fork out in the background. In this mode, Anacron will print all messages to the standard error stream as well as send them to the ‘syslog' daemon. Additionally, it will also e-mail the output according to the MAILTO setting.

Before job execution, Anacron does some pre-checks. Reading the timestamps file is one of them. Anacron then decides whether job execution is needed or not. We can override this default behaviour by using the ‘-f' option, which forces Anacron to execute the job by ignoring timestamps.

We can also perform dry runs of jobs for testing purposes. The ‘-u' option of Anacron just updates the timestamps to the current date, but in reality does not run any job.

We can instruct Anacron to start job execution in serial order. The ‘-s' option of Anacron takes care of that. In serial job execution, the next job will be started only when the previous job completes its execution.

Anacron uses the /var/spool/anacron directory as a spool area to store the timestamps file. We can also use other directories as the spool area by specifying an argument to the ‘-S' option. This is needed when a non-root user wants to execute a job through Anacron.

Caveats

Although Anacron is a great utility and works intelligently by taking care of missed jobs, it also has some shortcomings. Let us discuss a few of them. ƒ For Anacron, the smallest possible granularity is days. It does not deal with hours or minutes. ƒ Anacron creates the timestamps file per job in the spool area, and those files never get removed automatically. If the user removes a particular job entry from an Anacron table, then he has to remove the timestamps file manually. ƒ For each job execution, Anacron uses up to two file descriptors; so we can easily run out of descriptors if we run a large number of jobs. Please note that this limit varies from one version of GNU/Linux to another.

We have seen that, by combining Anacron with other utilities, we can manage a GNU/Linux system more efficiently. These simple but powerful command-line utilities make GNU/ Linux more interesting and reliable.

By: Narendra Kangralkar

The author is a FOSS enthusiast and loves exploring anything related to open source. He can be reached at narendrakangralkar@gmail.com

Managing Your IT Infrastructure with Zentyal

Zentyal (formerly eBox Platform) is a program for servers used in small and medium enterprises (SMBs). It plays multiple roles—as a gateway, network infrastructure manager, unified threat manager, office server, unified communications server or a combination of all of the above. This is the second article in our series on Zentyal.

In the previous article, we discussed the installation of Zentyal in two scenarios. In this article, let’s consider DHCP, DNS and a captive portal set-up.

Zentyal installation creates default settings that are not suitable for a production environment. Here, we will look at how to overrun those settings and create custom settings. I will start with DNS, then discuss the steps to be taken for DHCP, followed by a captive portal.

The DNS set-up

In my previous article, we had set up a domain name, which we will now use for setting up our DNS. The steps for configuration are as follows: 1. Open the Zentyal dashboard by using the IP address configured. 2. The URL will be https://your-ip-address. 3. Enter the user ID and password. 4. In the dashboard, you will see different categories like

Core, Infrastructure, Office, etc. Click ‘DNS’ under

‘Infrastructure’. 5. Select ‘Enable transparent DNS cache’. With this setting,

DNS will cache all the DNS requests, which will be routed through an internal DNS server. The clients have to use Zentyal as their gateway. Also enable the ‘Firewall’ module by traversing to ‘Module Status’ under the Core section. Click the ‘Save changes’ button on the top left of the screen to save the settings and enable the service. 6. The next option is ‘DNS forwarder’. With this option, all the DNS requests that come to the server will first be searched in local cache. If not found, they will be forwarded to external forwarders. Select ‘Add New’ and give your router address, and ISP-supplied gateway.

VirtualBox users need to enter their DHCP gateway address. Click the ‘Save changes’ button on the top left of

the screen to save the settings and enable the service. 7. The next sub-category is ‘Domains’. This will list all the local domains. Click on the button under ‘Domain IP addresses’ and remove your public IP from this using the

‘Delete’ button under ‘Action’. Click the ‘Save changes’ button on the top left of the screen to save the settings and enable the service. 8. Click on the back button of your browser and click on the button under ‘Hostname’. Then click on the button under

‘IP address’ and delete your public IP from here too. This removal will prevent your public IPs from serving DNS requests from the Web. Click ‘Save changes’ at the top left of the screen to save the settings and enable the service.

DHCP set-up

The DNS has almost been setup. We will now set up the DHCP server. Follow the steps below: 1. Click DHCP under ‘Infrastructure’. 2. Uncheck ‘Enabled’ to stop DHCP requests on the external interface. Click ‘Save changes’ at the top left of the screen to save the settings and enable the service. 3. Click ‘Configuration’ of eth1 to set up DHCP. 4. Click ‘Custom IP address’ and add 172.22.22.1 for the default gateway. 5. For the search domain, select ‘Zentyal domain’. 6. For the primary nameserver, select ‘Custom’ and add 8.8.8.8. 7. For the secondary nameserver, add 8.8.4.4. 8. For NTP server, set ‘Local Zentyal NTP’. 9. Click the ‘Change’ button to temporarily save changes. 10. Under DHCP ranges, you can see the interface IP address set as 172.22.22.1, the subnet as 172.22.22.0/24 and the available range as 172.22.22.1 – 172.22.22.254. To provide the IP address to clients, you need to set up the DHCP range. Click the ‘Add new’ button under ‘Ranges’. Under ‘Name’ enter

‘lan’; under ‘From’ enter 172.22.22.2, and under ‘To’ enter 172.22.22.254. Click ‘Add’, and then click the ‘Save changes’ button at the top left of the screen to save the settings. 11. Then click ‘Dynamic DNS options’. 12. Select ‘Enabled’ under the ‘Dynamic DNS options’ and click the ‘Change’ button. Click the ‘Save changes’ button at the top left of the screen to save the settings. 13. In the end, click on ‘Modules status’ under ‘Core’. 14. Select DHCP and click on the‘ Save changes’ button at the top left of the screen to save the settings and enable the service.

Captive portal set-up

With these settings, clients will get IP addresses automatically. The next part involves setting up the captive portal. As discussed earlier, it is used to limit access to the network. Follow the steps below: 1. Click ‘Captive portal’ under ‘Gateway’. 2. Select ‘Limit Bandwidth usage’. 3. Define the bandwidth quota. Enter the size in MBs. 4. Select the period for that quota—from Day, Week and

Month. Hit ‘Change’ to save. 5. Click ‘Checkbox enabled’ under captive interfaces and then click the ‘Save changes’ button at the top left of the screen to save settings and enable the service.

With all the steps mentioned earlier, you will be able to configure and set up DNS, DHCP and captive portal on your server.

Test the configuration

To test the configuration on a client, which could be Windows or Linux, remove any IPs from the interface of the client. Connect it to the network. Wait for a few seconds. Your client will receive an IP address from the server. To check the IP address received on the client, type the following command:

ipconfig /all

…on your Windows clients.

And for Linux clients, type…

$ ifconfig eth0

Things you might miss

Here’s a list of some of the commonly missed settings during set-up. If you missed them, you can configure them from the dashboard. 1. If you missed the IP set-up, then follow the steps below: • Click ‘Network’ under ‘Core’, then click ‘Interfaces’. • You can now set the external interface (eth0) from here. You can also set the internal interface (eth1). • Click ‘Save Changes’. 2. If you missed the gateway, follow the steps below: • Click on ‘Network’ under ‘Core’, then click ‘Gateway’. • Click ‘Add new’. • Provide the name to the gateway. • Provide the IP address of the gateway. • Select ‘Default checkbox’. • Click ‘Save Changes’. 3. If you missed some of the components from the installation, follow the steps below: • Click ‘Software Management’ under ‘Core’. • Click ‘Zentyal components’. • Then select any component that you have missed during installation. • In the end, click ‘Install’ to install the component.

In my next tutorial I will discuss the HTTP proxy, traffic shaping, firewalls and users, and computers.

By: Gaurav Parashar

The author is a FOSS enthusiast, and loves to work with open source technologies like Moodle and Ubuntu. He works as assistant dean (for IT students) at Inmantec Institutions, Ghaziabad, UP. He can be reached at gauravparashar24@gmail.com