Script

Description

The Script Update Module allows to execute any general purpose script or binary on the target device. A Mender Artifact containing one or more executables (usually scripts) is sent to the device, where the Update Module will execute these during the ArtifactInstall state.

If multiple scripts are provided, they will be executed in alphabetical order on the device.

Example use-cases:

  • Restart application into diagnostic mode
  • Run diagnostics script
  • Execute any other generic command

Specification

Module name script
Supports rollback no
Requires restart no
Artifact generation script no
Full operating system updater no
Source code Update Module
Maintainer Community

Please be aware that Mender Update modules are meant to update parts of the operating system and if not configured properly they could potentially delete parts or the complete operating system. Always inspect the code carefully and only test modules on a device that you can recover easily.

It is not recommended to install a Mender Artifact on your workstation

Prepare the device

This section describes how to setup your target device, i.e. the device to be updated. This will also be referred to as the device environment.

All commands outlined in this section should be run in the device environment.

Prerequisites

This update module has the following prerequisites for the device environment:

  • Install the Mender client, version 2.0 or later
  • Ensure the device has a Bash Unix shell
    • How to install this depends on which OS you are running

Install the Update Module

Download the latest version of this Update Module by running:

mkdir -p /usr/share/mender/modules/v3 && wget -P /usr/share/mender/modules/v3 https://raw.githubusercontent.com/mendersoftware/mender/master/support/modules/script

Prepare the development environment on your workstation

This section describes how to set up your development environment on your workstation.

All commands outlined in this section should be run in the development environment.

Prerequisites

This Update Modules has the following prerequisites for the development environment:

Create Mender Artifacts

The Artifact can be generated using mender-artifact tool.

Create example content to deploy:

cat > my-script-1.sh << EOF
#!/bin/bash
echo "$(basename "$0") was executed on device!" > /tmp/my-script-1.txt
EOF

cat > my-script-2.sh << EOF
#!/bin/bash
echo "$(basename "$0") was executed on device!" > /tmp/my-script-2.txt
EOF

Now generate a Mender Artifact using the following command:

ARTIFACT_NAME="my-update-1.0"
DEVICE_TYPE="my-device-type"
OUTPUT_PATH="my-update-1.0.mender"
SHELL_SCRIPTS="my-script-1.sh my-script-2.sh"
mender-artifact write module-image -T script -n ${ARTIFACT_NAME} -t ${DEVICE_TYPE} -o ${OUTPUT_PATH} -f $(echo "$SHELL_SCRIPTS" | sed -e 's/ / -f /g')
  • ARTIFACT_NAME - The name of the Mender Artifact
  • DEVICE_TYPE - The compatible device type of this Mender Artifact
  • OUTPUT_PATH - The path where to place the output Mender Artifact. This should always have a .mender suffix
  • SHELL_SCRIPTS - The path to the script that you wish to deploy and execute on your device. NOTE that the extension does not matter.

You can either deploy this Artifact in managed mode with the Mender server (upload it under Releases in the server UI) or by using the Mender client only in Standalone deployments.

Artifact technical details

The Mender Artifact used by this Update Module has a payload with as many files as scripts are contained in the Artifact.

The Mender Artifact contents will look like:

Updates:
    0:
    Type: script
    Provides: Nothing
    Depends: Nothing
    Metadata: Nothing
    Files:
        name: my-script-1.sh
        size: 140
        modified: 2019-03-05 18:34:43 +0100 CET
        checksum: 065714b581785a2d7c83b684f0d5348031c5512f21863fed38197078cb3ef6e5
    Files:
        name: my-script-2.sh
        size: 139
        modified: 2019-03-05 18:34:54 +0100 CET
        checksum: 9fca4ec0f65f960d1ac2dfd311e32070b62c26f35968c8002c16d39ccdb1330a
2 Likes

Hello and good work.
I have been working on the mender for a while and have integrated my device (Variscite i.MX-6ul) into the mender. I am currently using mender-client-2.0.0 and I can see my device in demo server:


That seems like that.

I tried to use the script update module to create and distribute Artifact and follow this document. I recently created an artifact named my-update-1.0 and uploaded it to my demo server. My device doesn’t see this artifact when I try to distribute it. What could this be about? As an example, let me show you:

How do I fix this? Why Artifact and my device don’t match?

You need to change the following,

DEVICE_TYPE="my-device-type"

to

DEVICE_TYPE="imx6ul-var-dart"

Because that is what your device is called.

Thank you @mirzak . After correcting the device type variable, the update was performed and I found that it was successful through the demo server. But when I go into my device, I see that nothing has changed and my device still work with previous update information. We were expecting to see an executable script file running on our device with this update module (script), but we couldn’t. Also the artifact name is still the same. How do I observe this?

Where is the this script files in my device ?

The scripts are not saved in your device. The script Update Module executes these scripts while updating (i.e. they are executed only once).

That is not expected. If the Artifact was successfully installed (in this case, that will mean that the Update Module executed the two scripts) then the Artifact name should have been updated to the name of your last Artifact (my-update-1.0 in your case).

My guess here is that an error ocurred during the execution of these scripts. You should be able to find the logs in the finished deployments tab in the ui.

That is not expected. If the Artifact was successfully installed (in this case, that will mean that the Update Module executed the two scripts) then the Artifact name should have been updated to the name of your last Artifact ( my-update-1.0 in your case).

I mean, I can’t see this artifact name on my device. It still appears as first-artifact-emre in / etc / mender / artifact_info :

And this is my demo-server dashboard information:

Is this normal? The version information on the device and the version information on the server look different.
On device artifact_info: first-artifact-emre
On server artifact_info: my-update-01

I understand now :slight_smile:

The /etc/mender/artifact_info file is deprecated from Mender 2.0.x. To locally check the current artifact name, use mender -show-artifact

The server reports the correct version: my-update-01

Thank you so much for speedy reply. You really helped me. See you next question :slight_smile:

Hi,

I’m looking into this functionality because we need to wipe data from our devices before handing them over to new clients. This must be done separately from any firmware update.

Is it possible to use this mechanism in order to wipe data from a separate data partition (call it partition 5 in the boot/rootfsA/rootfsB/data setup) without having to switch to a new rootfs partition?

Firmware updates can happen while clients are using the device, so we don’t want to tie the data wipe to a firmware update. We really need it as a separate, remote startable action.

Could this mechanism be used for that?

The documentation isn’t quite clear on this topic, that’s why I’m asking.

So to recap:

Can a script be readied for the device to perform a remote data wipe (for instance a format of a separate client data partition) without triggering a complete firmware update involving a rootfs partition switch?

Yes. The script Update Module will not trigger a switch of the rootfs and only implements the ArtifactInstall state.

Hi mirzak,

Thanks for the quick response. That really helps me enormously.

Hi,

I would like to use this module to reboot my RPi , I tried including “sudo reboot”, it reboot just fine, but deployment is failing in the mid way, because the mender artifact isn’t able to recognize the poweroff maybe, So whats the right way to reboot the device, Thats it, Only a reboot device command.,

Hi @nishad1092 ,

Recently I realized that the this Update Module is not the best for the reboot device kind of use case. (I did update the description yesterday). The problem is that Mender must have full control on when to reboot or not the device; and doing it from an script is a bad practice. I am sorry for the confusion.

You can achieve this writing your own simple Update Module which returns “Yes” to “NeedsArtifactReboot”, and then use dummy Artifacts with no payload. Read more about this in the spec documentation.

1 Like

Sure @lluiscampos, Ill look into it, But I also heard from other member that if I use NeedsArtifactReboot Update Module, then it changes the Artifact name, Is it true? Becuase that can lead to unlikely situations in the future.

@nishad1092 Yes. After you successfully “install” anything with Mender the current Artifact in the device will be updated.

Keep in mind that this remote control is a use case for what Mender is not intended for; hence the oddities with the Artifact name for example. Mender is intended for OTA updates in a robust and secure manner.

Hi @lluiscampos,

Im using this module to execute python scripts.
So, the issue is, When a deployment fails, the current release becomes “Inconsistent”, I understand that, but after it fails, the device doesnt sync up to Mender, I had to reboot the device manually, and further I cant deploy any releases before the previous release became Inconsistent.

I think, to resolve this, this module should have rollback feature ? is it?

Im using the default script module :—
#!/bin/sh

set -e

STATE="$1"
FILES="$2"

case “$STATE” in
ArtifactInstall)
for file in “$FILES”/files/*; do
chmod u+x “$file”
“$file”
done
;;
esac
exit 0

How can I include rollback feature, so that if any update thru script fails, I need to rollback and also restart, Please could you give an example. I think ArtifactRollback or ArtifactRollbackReboot will help, Isn’t it? plz give an example, a simple rollback state and restart,

To add rollback to a given update module:

[...]
case "$STATE" in

    SupportsRollback)
        echo "Yes"
    ;;

    ArtifactRollback)
        # Here your rollback logic
    ;;
esac

exit 0

If you can share more details on what your Python script is doing I could give some advise on what “rolling back” could mean in your context.

LluĂ­s

Hi @lluiscampos,
Thank you for your response, I wish I can give more details but the script is confidential, But I can say that the script includes Installation of Python, docker, and creating files, folders, moving folders etc. So, I just want to know what does rollback offer?

Scenario: Say I have a folder /home/scripts/script1.py ( only 1 file is there currently) and I’m executing this .py which generates many other files (xxx.txt, abc.py, def.py) inside /home/scripts/ when I execute script1.py ,
But if something goes wrong or deployment fails, I would like to rollback to the situation where I have only /home/scripts/script1.py (No files or folder, No .xxx.txt, or .py generated)…

@lluiscampos, The script has only command to execute the python file (just pythoin3 /home/.script/script1.py) , I’m using the directory module to deploy that script1.py into /home/scripts/)

That is the key: the rollback mechanism for Update Modules, where applicable, has to be implemented by the Update Moudule itself. Mender does not “offer” it as Mender has no idea on what the module could be doing in its install state.

For example, if your module installs xxx.txt, abc.py, def.py, the rollback state could remove xxx.txt, abc.py, def.py.