Problems / doubts with openwisp-firmware-upgrader

[pni...@gmail.com]

1 - What are the requirements for this to work? I know create category, the build and upload a image, but ... Is mandatory to have SSH access as described in https://openwisp.io/docs/user/configure-push-updates.html

2 - If a upgrade fails, how can I init the update again? Do I have to delete the firmware from the "Firmware" tab on the device change page and add again?

3- The device has been upgraded successfully, but shows as failed

Log says ...

Detected a recoverable failure: Connection failed.

The upgrade operation will be retried soon.

Connection successful, starting upgrade...

Image checksum file not found, proceeding with the upload of the new image...

Sysupgrade test passed successfully, proceeding with the upgrade operation...

Upgrade operation in progress...

SSH connection closed, will wait 120 seconds before attempting to reconnect...

Trying to reconnect to device at XXX.XXX.XXX.XXX (attempt n.1)...

Private key file is encrypted

4 - Is there any way to tell "all devices of this build has to be in build XXX", so if a new device is registered with an old version it will update?

[Federico Capoano]

Hi Pedro,

On Thu, Aug 12, 2021 at 11:57 AM pni...@gmail.com <pni...@gmail.com> wrote:

1 - What are the requirements for this to work? I know create category, the build and upload a image, but ... Is mandatory to have SSH access as described in https://openwisp.io/docs/user/configure-push-updates.html

 

OpenWISP needs to be able to reach the devices, so either OpenWISP is deployed in the same layer2 network or a management tunnel (eg: OpenVPN tun mode) is configured and the "management_interface" option of openwisp-config is specified correctly in /etc/config/openwisp so that OpenWISP knows the management IP to use for push operations.

2 - If a upgrade fails, how can I init the update again? Do I have to delete the firmware from the "Firmware" tab on the device change page and add again?

Yes, this is the easiest thing at the moment.

 

3- The device has been upgraded successfully, but shows as failed

Log says ...

Detected a recoverable failure: Connection failed.

The upgrade operation will be retried soon.

Connection successful, starting upgrade...

Image checksum file not found, proceeding with the upload of the new image...

Sysupgrade test passed successfully, proceeding with the upgrade operation...

Upgrade operation in progress...

SSH connection closed, will wait 120 seconds before attempting to reconnect...

Trying to reconnect to device at XXX.XXX.XXX.XXX (attempt n.1)...

Private key file is encrypted

The upgrade process has a last step in which the worker tries to connect to the device again many times until it either succeeds (and writes a file with the hash of the firmware image installed, to prevent accidental unnecessary double future upgrades) or gives up, in this latter case it considers the upgrade failed even though it may not be a 100% failure.

In this specific case, you'd have to debug where "Private key file is encrypted" is coming from.

 

4 - Is there any way to tell "all devices of this build has to be in build XXX", so if a new device is registered with an old version it will update?

No, there's no such a feature yet. Before implementing something like this I think we should use this module more and improve it further. this module is relatively new. 

However, I've already been moving steps in that direction in the dev branch (anybody using this module I suggest using the dev branch which contains a lot of improvements I did during usage and testing).

Moreover, with the addition of the concept of "Groups" in the near future we can implement a mass group upgrade which would allow us to upgrade all the devices of a group (right now one can only upgrade all the devices of an organization or one by one). 

This idea is interesting though, how would you imagine such a thing?

I imagine 2 possible ways:

- add a checkbox in the firmware build page which would enable this feature for an entire organization, but some logic should be put in place so that this feature can only be enabled on 1 build per org

- add a way to specify the same but for groups, so a specific build can be automatically flashed on all the devices of a specific group

Best regards

Federico