GENESIS: Documentation

Related Documentation:

Automated Tester

The neurospaces_cron Script

This script is part of the DeveloperPackage, its function is to perform sanity checks for communicating with a repository, system installation, and runs tests to check that software packages are properly working. Here we introduce how to use the script, set up a cron job, and how to avoid some common pitfalls.

Running neurospaces_cron

The neurospaces_cron script can be run by entering “neurospaces_cron” from the command line after installing the DeveloperPackage. There are command line arguments available to customize aspects of a cron job, e.g.

• --outputdir <absolute path to target directory>: Set the output directory for cron job output logs.
• --config <file name>: Read a YAML configuration file for setting cron job parameters.

However, it is preferable to create a YAML configuration file to set cron job parameters.

The neurospaces_cron Configuration File

The neurospaces_cron configuration file is a YAML formatted file containing values that can be set for the following optional parameters:

• MAILTO: Email address for recipient of email notifying cron job completion.
• MAILFROM: Email address from which cron job completion email is sent.
• MAILBCC: Email addresses to send a courtesy copy of the cron jobs report to.
• OUTPUTDIR: Target directory for writing cron job output log data.
• URL: http link to serve test harness output.
• DOXYGENOUTPUT: The local directory that holds doxygen html output.
• DOXYGENURL: http link to serve doxygen output.
• REGTESTOUTPUT: The local directory containing output of regression test html.
• REGTESTURL: http link to serve regression test html output.
• LOGROTATE: The number of output logs to rotate on successive runs.
• NOCHECK: If set to True, the cronjob will not run tests to check the source code. Proceeds as normal when set to False. This option case insensetive.
• NOPULL: If set to True the cronjob will not perform a pull from the developer repository.
• NOINSTALL: If set to True the cronjob will not install the packages on the machine.
• NOUNINSTALL: If set to True the cronjob will not perform a final uninstall of the system before exiting.
• PKGDEB: Directory to place built Debian packages.
• PKGDEBURL: The URL to serve Debian packages from.
• RPMDIR: Directory to place build RPM packages.
• RPMURL: The URL to serve RPM packages from.
• SRCDIST: Directory to place built source tarballs.
• SRCDISTURL: The URL to serve source tarballs from.

Example configuration file:

The Cron Job

Setting up a cron job typically requires administrator rights. There are several ways to run a cron job. We now give some of the easiest ways to do this on a Linux based machine.

To automate the running of a cron job create the directory /etc/cron.d. A cron job formatted text file placed in this directory will be picked up by the cron daemon. A typical invocation for neurospaces_cron would be with a line like this:

This job is set to run at exactly one minute after midnight. To run the job more frequently you could do this:

which would make the cron job run every eight hours.

Note: The g3tester is a user set up for permissions to perform a sudo make install, and sudo make uninstall. To set up a regular user to use sudo, add them to the /etc/sudoers file (see next section).

Testing the cron daemon

Bad syntax in your crontab file can prevent any of the jobs from executing. If you want to test if your cronjobs are going off you can use the wall command. The wall command sends a message to the terminal of all users logged in. Check your system for the proper way to call it via:

Some systems have it invoked as:

While some call it with a file containing your broadcast message as an argument:

Simply enter a line in your crontab like this:

This will send the broadcast message every minute, so if you don’t see any output on your screen you know something is wrong.

Alternatively you can also have a command that just outputs the date to a file every minute:

Then you can just check the output file for a date message for every minute. This is probably better to use if the machine has many users that you don’t wish to disturb with a terminal message.

The Sudoers File

The sudoers file grants a particular user the privileges to run a command or set of commands in superuser mode. The file is located at /etc/sudoers. There are variables in the file which must be set to allow a regular user to perform the neurospaces_cron tests as they require GENESIS components to be installed and uninstalled to the system.

To allow the g3tester user to perform any command anywhere on the system in superuser mode the following line can be placed into the sudoer’s file:

This configuration line still results in the system asking for a password, which will stop the cron job. To prevent this, the “NOPASSWD” option can be inserted:

Since it is desirable to restrict a regular user to commands they absolutely need to run, their privileges can be limited to a particular list of command, e.g.

This limits the user g3tester to executing only the commands neurospaces_cron and make, without requiring a password. More commands can be added as needed simply by appending them to the list with a space delimiter.

Logging

By default, the cron daemon will usually not log anything. To turn on logging you need to add a line to the system log configuration. In debian the file you need to edit is /etc/rsyslog.conf. Before proceeding, it’s a good idea to make a backup copy of your system log configuration. Open the file with your favorite text editor and add this line:

You can change /var/log/cron.log to the file of your choice. Once your change is in place restart the system log daemon.

Not that on a Red Hat system the file you need to edit is /etc/syslog.conf and you restart the daemon via the command: