1-click update feature allows updating all system components (Servers and Client) from Desktop Client without the need to manually update each component.

However, by default this functionality allows updating Servers running on supported operating systems only.

The following scenarios are not covered by the standard 1-click update mechanism:

It is possible to customize Linux Servers to run on different operating systems or ARM devices (see “Creating Update Packages for Custom Linux/ARM Servers”)
The Desktop Client source code is available for the public which allows creating a custom Desktop Client (see “Open Source Desktop Client”).

In both cases, such update packages cannot be rolled out through the standard update mechanism. In order to make 1-click update work in such an environment, it is necessary to set up a custom Update Server and place custom update packages there.

This article describes how to create your own update server to serve updates to Open Source Desktop Clients or custom Servers on ARM/Linux OSs that are not officially supported.

How Does 1-Click Update Work?

In a multi-Server environment, the Desktop Client is the central part of the update mechanism which initiates the update process for the whole system.

In a diagram below, the system contains Servers running on different platforms and devices including the ones that are not officially supported and the Desktop Client is a custom one built from Open Source. This is an uncommon but the most comprehensive use case.

All Servers communicate to each other in P2P mode (aka hive), and the Desktop Client may be connected to any of them.

In this situation, the 1-click update process does the following:

During the update process, the user enters the version and build number to update to.
The Desktop Client connects to all servers and determines the operation systems and devices the servers are running on.
After the data is collected, the Desktop Client connects to the Update Server via the default (https://updates.vmsproxy.com/metavms/releases.json) or specific URL (see "Redirecting the Update Server URL") and requests the following update packages with the specified brand (i.e. Nx Witness, Nx Meta or any of the OEMs), version and build number:

- Desktop Client custom update package for the corresponding operating system (Mac OS)
- Server update packages for all the operation systems and devices ( Windows, Ubuntu Linux, Raspberry Pi, custom Linux - Kubuntu and custom Edge device)

Server looks for the appropriate update packages (details are explained below) and provides their URLs to the Desktop Client. If any of the packages is not found, the update is not possible unless the corresponding Server is offline.
Client uses the URLs to download all the packages and sends them to Servers.
Servers update themselves in the background mode.
Client updates itself and restarts.

Actually, the update mechanism is slightly more complicated, as Servers can connect to the Update Server themselves if the Desktop Client is not connected to the Internet. However, in case of creating a custom Update Server this scenario will not work properly so it is not covered in this article.

Update Server File Structure

The update server is an HTTP file server containing the following:

root/
├─ <brand1>/
│  ├─ <version>/
│  │  ├─ client_update1.zip
│  │  ├─ client_update2.zip
│  │  ├─ .....
│  │  ├─ server_update1.zip
│  │  ├─ server_update2.zip
│  │  ├─ .....
│  │  └─ packages.json
│  └─ releases.json
├─ <brand2>/
...

brand - OEM name (nxwitness for Nx Witness, metavms for Nx Meta or another OEM name)
version - version and build number (X.Y.Z.ABCDE)
update files in zip archives
releases.json - contains information about all the versions and builds available for the particular brand on the Update Server
packages.json - contains detailed information about the specific build (platforms, components, etc.) and the links to download them.

Here is a real-life example which illustrates the beta version of Nx Meta (5.1.0.36161) and the official release of Nx Witness (5.0.0.35745) with all officially supported platforms:

root/
├─ metavms/
│  ├─ 5.1.0.36161/
│  │  ├─ metavms-client_update-5.1.0.36161-windows_x64-beta.zip
│  │  ├─ metavms-client_update-5.1.0.36161-linux_x64-beta.zip
│  │  ├─ metavms-client_update-5.1.0.36161-linux_arm64-beta.zip
│  │  ├─ metavms-client_update-5.1.0.36161-macos_x64-beta.zip
│  │  ├─ metavms-client_update-5.1.0.36161-macos_arm64-beta.zip
│  │  ├─ metavms-server_update-5.1.0.36161-windows_x64-beta.zip
│  │  ├─ metavms-server_update-5.1.0.36161-linux_x64-beta.zip
│  │  ├─ metavms-server_update-5.1.0.36161-linux_arm32-beta.zip
│  │  ├─ metavms-server_update-5.1.0.36161-linux_arm64-beta.zip
│  │  └─ packages.json
│  └─ releases.json
└─ nxwitness/
   ├─ 5.0.0.35745/
   │  ├─ nxwitness-client_update-5.0.0.35745-windows_x64.zip
   │  ├─ nxwitness-client_update-5.0.0.35745-linux_x64.zip
   │  ├─ nxwitness-client_update-5.0.0.35745-linux_arm64.zip
   │  ├─ nxwitness-client_update-5.0.0.35745-macos_x64.zip
   │  ├─ nxwitness-client_update-5.0.0.35745-macos_arm64.zip
   │  ├─ nxwitness-server_update-5.0.0.35745-windows_x64.zip
   │  ├─ nxwitness-server_update-5.0.0.35745-linux_x64.zip
   │  ├─ nxwitness-server_update-5.0.0.35745-linux_arm32.zip
   │  ├─ nxwitness-server_update-5.0.0.35745-linux_arm64.zip
   │  └─ packages.json
   └─ releases.json

The file naming structure is:

<brand-<component>_update-<version>-<platform>-<beta>.zip

where:

brand - the name of the OEM
component - client or server
version - version and build number (X.Y.Z.ABCDE)
platform:
- windows
- linux_x64 - for Ubuntu Linux
- linux_arm32 - for Raspberry Pi and other compatible boards/OS
- linux_arm64 - for nVidia® Tegra®
- macos_x64 - for Intel-based Mac computers
- macos_arm64 - for M1/M2 Mac computers
beta - optional flag for beta versions.

What’s Needed

In order to perform 1-click update from the Desktop Client using a custom Update Server, it is necessary to have the following:

HTTP Server (we will use the one available on Python so Python 3 should be installed)
(optional) Custom ARM/Linux Server package built from the original Linux package (see “Creating Update Packages for Custom Linux/ARM Servers”)
All other update packages (9 total) in zip with the same build number:
- Client - windows, linux_x64, linux_arm64, macos_x64, macos_arm64
- Server - windows, linux_x64, linux_arm32, linux_arm64
(optional) Custom Desktop Client built from open source (if planning to roll out custom Desktop Client updates). Such Desktop Client should:
- Be built from a tag that is compatible with those servers
- Have a custom Update Server URL (see “Redirecting the Update Server URL”)
- Have the same build number
Root Update Server Descriptor (releases.json) - see below.

Configuring Custom Update Server

Create the primary folder for the update server (e.g. C:/update_server)
Open this folder.
Run the update server:
```
python3 -m http.server 7002
```
Create a subfolder with your desired brand name (e.g. C:\update_server\custom)
Now we can use the URL scheme

http://<ip>:<port>/<brand>/<subfolder>

to locally access folders and files in our web server, for instance:

http://172.16.1.102:7002/custom

Creating the Root Update Descriptor

The Root Update Descriptor is a JSON file which specifies the builds that will be served as updates.

Every release should be added to this file and then the Custom Desktop Client is pointed to this file via custom Update Server URL to read the information about available updates.

The descriptor should be created in the root directory for each brand. For the brand "custom", the path would be C:\update_server\custom\releases.json:

{
  "packages_urls": [
    "http://172.16.1.102:7002/custom/"
  ],
  "releases": [
    {
      "product": "vms",
      "version": "5.1.0.36011",
      "protocol_version": 5106,
      "publication_type": "beta",
      "release_date": null,
      "release_delivery_days": null
    },
    {
      "product": "vms",
      "version": "5.0.0.35744",
      "protocol_version": 0,
      "publication_type": "release",
      "release_date": "1620851150559",
      "release_delivery_days": 30
    }
  ]
}

The following parameters (in bold) should be specified:

package_urls: Link to where download packages can be found.
product: VMS, Mobile, or Cloud
version: Version and build number of the update package.
protocol_version:
publication_type: Type of update package, such as release, patch, etc.
release_date: The first date this update was made available to download.
release_date_delivery: The number of days this update will be pushed for.

Processing the Update Packages

The packages should be pre-processed in a certain way before hosting them on the update server. The following actions are necessary:

Creating a directory structure
Creating the update descriptor

Both operations can be done by the script that we offer as a part of out tools repository:

https://github.com/networkoptix/tools/blob/master/prepare_vms_update/prepare_vms_update.py

You need to do the following:

Put all the packages described in "What’s Needed" in the brand root folder (for the brand "custom", the path would be C:\update_server\custom\ and the example build would be 5.1.0.36011)
Make sure the update descriptor is there (C:\update_server\custom\releases.json)
Download and run the pre-processor script from this directory:

python prepare_vms_update.py

After the script is done, the subfolder with the build number (5.1.0.36011) will be created and the packages will be placed there. Also the update descriptor (c:\update_server\custom\5.1.0.36011\packages.json) will be created.

Using the URL of the Custom Update Server

URL of the Update Server will look like http://<ip>:<port>/<brand>/releases.json

I.e. http://172.16.1.102:7002/custom/releases.json

This URL should be used as the Custom Update Server URL for the Open Source Desktop Client to be able to update to custom builds.

After this is done, the custom Desktop Clients built with this URL will be able to update from custom Update Server.

Articles in this section

Distributing Custom System Components through 1-Click Updates

How Does 1-Click Update Work?

Update Server File Structure

What’s Needed

Configuring Custom Update Server

Creating the Root Update Descriptor

Processing the Update Packages

Using the URL of the Custom Update Server

Comments

Articles in this section

How Does 1-Click Update Work?

Update Server File Structure

What’s Needed

Configuring Custom Update Server

Creating the Root Update Descriptor

Processing the Update Packages

Using the URL of the Custom Update Server

Related articles