Update with precondition

As indicated in the configure documentation it is possible to use qbee to keep Debian packages updated. The way this works is that the package management configuration function can be configured to update all packages from defined repositories that have updates available or specific packages that have updates. This is a fully automated process and does not need any user involvement. However, the update operation can interfere with the daily operation of the devices. It is unacceptable if a production machine updates in the middle of a production run. Therefore we have introduced the precondition.

Update with precondition on your terms

qbee offers a function which is called "precondition". Only if the script being called by that function exits with zero or TRUE the update process is initiated. Therefore both time and date or any other precondition can be used (for example that an input pin is HIGH).

This offers a few interesting use cases to check if an update should occur. Some ideas are:

  • check for time and/or date

  • check for physical ports/buttons

  • check if certain applications run

  • check if a file or environment variable exists - for example "update-me"

  • check with an external system if update should be performed (for example with curl)

Below the UI is displayed. The precondition script needs to be inserted into the precondition form with full path. Make sure it is executable. An empty form will always execute the package update. The script can be delivered with file distribution.

!qbee-package-management

The first thing that needs to be done is to play out the script. This is done with the file distribution function.

  1. Upload the script to the file manager. Please note the path.

  2. In the qbee app go to "Configure" and select "System->File Distribution".

    On the device tab select the group or device that is in scope. For more information please see the configuration documentation.

  3. Start the actual file distribution definition:

    File Source:

    update-window-check.sh
    

    File Destination:

    /usr/local/bin/update-window-check.sh
    

    This plays out the script to the defined remote devices. If "Command to run" is defined this command will be run.

    When does this file gets played out?

    qbee checks if the file exists in the defined destination. If not it will be transferred. Both the file in the file manager and the file on the machine have a hash. If the file manager file is replaced a new file distribution happens. Likewise, if the file on the target machine is changed this will also trigger a new file download and the changes will be overwritten with the original file from the file manager.

  4. In order to do anything with the script the optional "Command to run" function can be used. Here commands can be chained using "&&" and this opens up for a lot of complex options. In this case we only do one simple operation:

    Make the script user executable and suppress output:

    chmod 755 /usr/local/bin/update-window-check.sh > /dev/null 2>&1 &
    

    !qbee-precondition-update-script-check

  5. Now the script is distributed and can be used. As a last step we need to insert the correct path into the precondition such that the script will be called when package management is run:

    !new-precondition

Previously we discussed different ideas for precondition scripts. Here we want to give you three actual script ideas as a starting point to derive your own precondition.

The following script checks if an environmental variable "update" is set to "1". If true the update starts, otherwise it will not run. This can be used to set this variable from a webserver or C++ application on the device (assuming it has a UI). So users can flag when they see a good window for an update period. For example a machine user knows the machine is turned off.

#!/usr/bin/env bash

CheckNamekEnv="update"
CheckVarEnv="1"

VarEnv=`printenv $CheckNamekEnv`

if [ -n "$VarEnv" ]; then
        echo $CheckNamekEnv exist
        exit 0

        if [ "$VarEnv" == "$CheckVarEnv" ]; then
            echo $CheckNamekEnv = OK
        else
            echo $CheckNamekEnv = FAIL
            exit 2
        fi
else
        echo $CheckNamekEnv not exist
        exit 1
fi

The next script checks for a time period and only kicks off potential updates between that time period:

#!/usr/bin/env bash

currenttime=$(date +%H:%M)
   if [[ "$currenttime" > "23:00" ]] || [[ "$currenttime" < "04:30" ]]; then
     exit 0
   else
     exit 1
   fi

Another example updates once a month on the 28th day:

#!/usr/bin/env bash

DAY=$(date -d "$D" '+%d')
   if [[ "$DAY" == "28" ]]; then
     exit 0
   else
     exit 1
   fi

Why it makes sense to use precondition

The idea is that the precondition gives an infinite amount of flexibility. It is possible to check for time, timezone, specific date periods, sunset, sunrise or whatever makes sense for the application. Please do not hesitate to send us some of the preconditions you use and we can publish them here.

A poor man's update control

This is so obvious that it probably should not be here, but you can disable auto update and only enable it when you want to update. Let's assume your devices have an update rate of 15 minutes. If you enable the "update all" functionality the devices will eventually all pick up this new configuration within the next 15 minutes and start to update. Turning it off again after an hour or two should enable all devices to update. The big drawback with this is obviously that devices that are offline during this operation will not receive the update. So please use with care and rather deploy a precondition.