Xymon Bacula Check Script


The instructions and script that follow are intended to be used to monitor a Bacula Backup Server's Director status output and report back to a Xymon monitoring server for logging and alerting on failed backup jobs and/or jobs that require operator intervention.

Here you will find the most current versions of our:

  • Instructions on integrating, monitoring, and alerting on the output from the xymon_bacula_check.sh script with a Xymon server
  • xymon_bacula_check.sh - Xymon Bacula Check Script

Related Scripts

We have also written several other scripts that you may find useful. You may find them HERE


Configure your server to allow Xymon to run bconsole

The xymon_bacula_check.sh script uses bconsole, the primary interface to the Bacula Director to query the list of recent jobs and the current status of the Bacula director.

bconsole is installed by default with the following (reasonably secure) permissions:

# ls -la `which bconsole`
-rwxr-x--- 1 root root 41488 May 19 16:24 /usr/sbin/bconsole

With those permissions, the xymon user can not run bconsole without some extra work.

There are two methods you can use to allow the xymon user on your Bacula server to run bconsole. Depending on your environment, and your level of paranoia, either of these methods may be acceptable.

  • Method 1 - Enable the setuid bit on the /usr/sbin/bconsole binary to allow normal users to run it as the root user
  • Method 2 - Configure sudo so that the normal xymon user can call "sudo bconsole" to run the program

  • Method 1 - Enabling the setuid bit on the bconsole binary

    This first method is quick and easy, but just consider the security ramifications before taking this route.

    This method will allow ANY user logged into your Bacula backup server to run bconsole. The program will be run with the permissions of the root user, so if you have untrusted users that log into your backup server this method is not recommended - But then again if you have untrusted users logging into a mission-critical server in the first place you already have bigger problems. ;)

    Also, remember that on subsequent upgrades of the Bacula software, you will need to re-enable the setuid bit since bconsole will be re-installed with it disabled.

    To enable the setuid bit, as root, do the following:

    chmod u+s `which bconsole`

    Then, check to see that the setuid bit is set by doing the following:

    ls -la `which bconsole`
    -rwsr-x--- 1 root root 41488 May 19 16:24 /usr/sbin/bconsole

    Notice that the user execute bit has been changed from an x to an s. This means that non-root users on your system can now run bconsole and it will be run as if the root user had started it.

  • Method 2 - Configuring sudo for bconsole access

    This method (using sudo) is the more responsible and recommended way to do this. With sudo you can allow specific users the ability to run bconsole on your system without having to modify the permissions on the bconsole binary.

    The /etc/sudoers is the configuration file for sudo. This file should only be edited by using the visudo program since it will verify proper syntax before allowing you to save the file. A broken /etc/sudoers file can cause unexpected results so you would be wise to heed this warning.

    Edit your /etc/sudoers file by running visudo and add the following lines to it, then save it.

    # Set up a User Alias called "BACULA" 
    # which will be used later to allow
    # specific users to run bconsole
    # -----------------------------------
    User_Alias      BACULA = xymon
    # Set up a Command Alias called "BCONSOLE"
    # defining the one command allowed. More 
    # commands may be added later if needed
    # ----------------------------------------
    Cmnd_Alias      BCONSOLE = /usr/sbin/bconsole
    # Allow users in the "BACULA" User Alias 
    # list to run the commands in the "BCONSOLE"
    # Command Alias via sudo with no password
    # ------------------------------------------

    When added to the /etc/sudoers file, the above lines will allow the user xymon to use sudo to run /usr/sbin/bconsole without being asked for their password.

    As root, we can test this like so:

    First become the xymon user.

    root@servername # su - xymon
    xymon@servername $ 

    Now test bconsole access with sudo as the xymon user:

    xymon@servername $ sudo bconsole
    Connecting to Director servername:9101
    1000 OK: servername-dir Version: 5.0.2 (28 April 2010)
    Enter a period to cancel a command

    OK, the asterisk (*) character is bconsole's command line prompt. THis means we are able to run bconsole via sudo as the xymon user.

    - Now type quit to exit back to your xymon user's shell prompt, then type quit again to exit back to the root user's shell prompt and then continue with the rest of these instructions.

Install the custom external client-side Xymon script

- Copy the bash shell script below to ~xymon/client/ext/xymon_bacula_check.sh on your Bacula server
- Set the ownership and execution permissions on the script

chown xymon:xymon ~xymon/client/ext/xymon_bacula_check.sh
chmod +x ~xymon/client/ext/xymon_bacula_check.sh

Edit the script to match your environment

- The script is pretty well documented, but you may need to modify just a couple of the pre-configured variables to suit your environment:

  • Local system binaries: (SUDO, GREP, SED, AWK, & TAIL)
  • BCONSOLE: Path to the bconsole program
  • BCONFIG: Path to the bconsole configuration file
  • NUMJOBS: Number of recently run jobs for the script to consider when reporting the Bacula status to your Xymon server
  • CHK_MEDIA: Set this to "1" if you would like the script to report back a yellow status to Xymon if it detects media with a status of "Error"
  • POOLS: A space separated list of Bacula Media Pools to check for media with a status of "Error". The special case "ALL" may be used to test all pools
  • ADMINMSG: Custom text (not required) that you want to be pre-pended to the Xymon report. This text will always appear at the top of the Bacula status page on your Xymon server

Tell Xymon (hobbitlaunch) to start running the new script

- Tell Xymon to start running the new external script by adding these lines to the ~xymon/client/etc/clientlaunch.cfg file on your Bacula backup server:

        ENVFILE $HOBBITCLIENTHOME/etc/hobbitclient.cfg
        CMD $HOBBITCLIENTHOME/ext/xymon_bacula_check.sh
        LOGFILE $HOBBITCLIENTHOME/logs/xymon_bacula_check.log
        INTERVAL 5m

- Wait a few minutes and you should see a new column called Bacula on your Xymon page
- Click on the Bacula icon and you should see the current status of your Bacula server similar to the image below:

- Of course, this yellow status page is just an example. You will always want your Bacula status page and the rest of your Xymon status pages to be green!

The xymon_bacula_check.sh script:

xymon_bacula_check.sh10.77 KB

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

bacula script

I saw the script, and at the very end there is the line

$BB $BBDISP .....

These variables are undefined. Is this intentional or an oversight? I don't be believe they are predefined shell variables.

Environment Variables

These are defined in the environment that is loaded as the script is run.

$BB points to the bb (now xymon) binary

$BBDISP points to the IP address or FQDN of the display server

Bill Arlofski

Post new comment

  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <b> <i> <u> <strong> <cite> <code> <pre> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options

This question is for testing whether you are a human visitor and to prevent automated spam submissions.
Enter the code without spaces and pay attention to upper/lower case.