wiki:initscripts
Last modified 3 years ago Last modified on 10/10/11 07:34:06

THIS PAGE IS OBSOLETE, INITSCRIPTS TEST HAS BEEN REMOVED FROM AUTOQA


What are initscript tests

The goal of these tests is to check LSB compliance of initscripts - i.e. if the scripts contain all required actions and if the exit codes for status and non-status actions are correct (another source of information).

How can you help?

Help with testing of the tests :)

At the moment, we have some of these tests already in AutoQA , but there are more waiting to be revised and pushed to the master branch.

We have already roughly pre-checked these tests, but they still need some deeper testing - i.e. someone needs to go through the source code, see if all the tests are correct, if the script does not leave the system in 'another' or even 'broken' state, and possibly fix the issues & provide patches so the tests can be pushed to the master branch.

How to test the tests

These tests are written in BASH using Beakerlib library, which is used for writing bash-based tests in Red Hat. But don't be scared, this library is pretty self-explanatory and you can review all the tests using your BASH knowledge and this Beakerlib quick reference sheet.

So lets look at the workflow of the review.

Selecting the script

Go through the Initscript review milestone, and choose the script you would like to review. Once you have done that, take the ticket and follow the next steps.

Setting up the environment

  1. Prepare a system -- You'll need a Fedora system to test with. While, the tests should be non-destructive, they do require installing packages that provide the respective services. Depending on your setup, you may wish to test on another system. To test with a virtual machine, you can find more information at Getting_started_with_virtualization.
  2. Install initscript -- Depending on which test you choose, you must install the package that provides the initscript. For example, if you are testing mysql, you might type: yum install /etc/rc.d/init.d/mysqld
  3. Install beakerlib -- Once you have your test machine, be it a virtual or bare metal, you need to install the beakerlib package. Type: yum install beakerlib

Getting the script

The best way to do this is using git:

yum install git
git clone git://git.fedorahosted.org/autoqa.git autoqa
cd autoqa
git checkout -b initscripts origin/initscripts

The scripts are then in the tests/initscripts/tests/ directory.

Or you can just download the content of the respective directory (e.g. httpd from the git repo using your web browser).

You really need only the runtest.sh file, which contains the test's source code.

Pre-check

Each test should have a Setup/Cleanup? phase, test the presence and function of the mandatory actions, and test the Lock/PID file behaviour. The tests should be a variation on this template.

Stuff to do:

  1. Check if there's #!/bin/bash shebang at the beginning of the script.
  2. Check if the package name and service name are correct.
  3. Check if the script tests all of the required actions.
  4. Check if the tests for action exit codes are correct (see status and non-status expected results).
  5. Check if there is a rlServiceStop in Setup and rlServiceRestore in Cleaup phase.
  6. If temporary user accounts are created somewhere in the script, check if they are disposed in the Cleanup phase (possibly move the user creation to Setup phase).
  7. Check if the Lock/PID file names are correct (some services may store the Lock/PID file in non-standard way - investigate in the init file itself (/etc/init.d/$SERVICE)
  8. If the tests creates/changes config files for the service, make sure that these get backed up and restored if present before the testrun (rlFileBackup rlFileRestore).
  9. If the script needs to delete a file, make sure it gets backed up and restored.
  10. Check for any other signs of destructive behavior (changed/deleted files, stopped/started services, ...).

Detailed description of some of these points to be found here

Run the script

Once you've finished the pre-check, install the $PACKAGE and run the runtest.sh as root (unprivileged user usually can not start/stop services and delete/create Lock/PID files).

su root
chmod a+x runtest.sh
./runtest.sh

Check if the script runs correctly, examine the results and make sure there are no errors.

Share the result

Once you've finished testing, report your findings to the appropriate TRAC ticket.

If everything went correctly, congratulations! You can close the ticket.

If problems were encountered, please add details of the failure. Bonus points for providing a patch! Patches can be attached to the relevant TRAC ticket, or send it to the autoqa-devel mailing list with the subject [PATCH][INITSCRIPTS] - #TracTicketNumber TracTicketDescription.

Detailed pre-check

Check if the script tests all of the required actions

Check if the tests for action exit codes are correct (see status and non-status expected results)

Each initscript should provide some certain 'actions' (e.g. start, stop, restart...), the list of required actions is here <https://fedoraproject.org/wiki/Packaging/SysVInitScript#Required_Actions> and these actions need to return certain exit codes according to <https://fedoraproject.org/wiki/Packaging/SysVInitScript#Exit_Codes_for_non-Status_Actions> and <https://fedoraproject.org/wiki/Packaging/SysVInitScript#Exit_Codes_for_the_Status_Action> based on the type of action.

Example: Command service $servicename start should return 0 if everything | went ok, and it should return 4 or 1 if you try to run the command | with non-privileged account.

So you should check, if the test is trying to use all these actions (i.e. if there is a line like rlRun "service $SERVICE $ACTION" "$REQUIRED EXIT CODE") and if these tests (the rlRuns) expect the exit code stated by the documentation.

If temporary user accounts are created somewhere in the script, check if they are disposed in the Cleanup phase (possibly move the user creation to Setup phase)

Some tests (in fact, after the review all the tests should) have a part which tests initscript behaviour while runned as unprivileged user. These scripts create a temporary user account, but sometimes, they do it somewhere else than in the 'Setup' phase, and destroy the accound elsewhere than in Cleanup phase (see e.g. auditd test to see how it should look like in the correct state).

So your task here is to go through the code and find the possible user creation/destruction and move it to appropriate phase.

Check if the Lock/PID file names are correct (some services may store the Lock/PID file in non-standard way - investigate in the init file itself (/etc/init.d/$SERVICE)

Since the tests are taken from the RHEL crew, lock/pid files do not necessary need to be in the same file on Fedora. Your task here is to check, if the path to the Lock/PID file in the test is correct for the appropriate initscript. The correct path is to be found inside the initscript itself.

If the tests creates/changes config files for the service, make sure that these get backed up and restored if present before the testrun (rlFileBackup rlFileRestore)

Check for any other signs of destructive behavior (changed/deleted files, stopped/started services, ...)

Some of the tests may create/change/delete files during their execution. Since we want these test to be non-destructive you should go through the tests source code and find all (if any) occurences of this behaviour. Once found you should use rlFileBackup on the respective file _before_ it's changed/deleted and add a rlFileRestore to the cleaup phase. You should also delete any file which is created by the test in other directory than /tmp, also in the cleanup phase.

Attachments