Syncplify.me Server v8

Appearance

Updates ​

The Updates area keeps the server current. From version 8.4.0 every node checks Syncplify's signed release channel once a day, shows what it found, and can install a new version on its own: on request, or automatically when the node is idle, according to an update policy that applies to the whole server (and, in a cluster, to every node). Every release is signed by Syncplify and verified on the node before anything is installed. The mechanics of an update, what happens on the node, and the cluster rules are described in Keeping the server current; this page describes the console.

The page is a live status surface: it refreshes every few seconds while an update is in flight, and every half minute otherwise.

Running version ​

The top card shows the version this node runs, with its three components (the Web/REST service, the worker service and the SyngoDB service) and, when a newer version has been published, the version each component would be updated to.

On a node that runs in a container, the page is informational only: a container never updates itself, a newer image is deployed instead.

Maintenance standing ​

Updates and upgrades require an active maintenance plan. The standing card says whether this installation is eligible to install them:

  • Eligible: the maintenance plan is active (its expiry date is shown), or the license is a trial (eligible while the trial is valid).
  • Not eligible: the license is missing, expired, invalid or does not cover the published version, or the maintenance plan has expired or was never attached. The card says which.
  • Could not be verified: the Syncplify licensing service cannot be reached from this server, so neither the maintenance standing nor the revocation status of the license could be checked.

When a newer version has been published and the installation is not eligible, the card makes it prominent, on purpose: software that is not up to date may be vulnerable, because it is not running the latest security patches. It shows the license code and the steps to follow: open the Syncplify Customer Portal at https://syngo.to/cc, sign in, open the license with that code, extend its maintenance plan, then come back and click Check now. As soon as the plan is active again, the installation becomes eligible and the update can be applied from this page.

When the standing could not be verified, automatic updates never apply. An update can still be applied by hand: the apply dialog then shows the same warning the setup program shows, and asks you to accept full responsibility for continuing (if the license has been revoked, or the maintenance plan has expired, updating may deactivate the license and stop the software from running).

Release channel ​

The channel card shows the newest published version and when it was published, whether this server runs it, when the channel was last checked and by whom (the daily check, this console, or the command line), and a link to the release notes. Check now reads the channel immediately. The server checks it once a day on its own; a check that fails reports the reason here, and a channel that could not be read for a long stretch raises a notification. The channel's address is not shown: the server knows it, and it only matters when a firewall must allow outbound HTTPS to it (see Keeping the server current).

Update policy ​

The policy decides what the server does when a new version is published. It is a server wide setting, saved with the Global Configuration and replicated to every node of a cluster, but it is edited here because this is where its effects are seen.

  • Notify only (the default): new versions are shown on this page, on the Dashboard, at sign in and in the notifications. Nothing is installed until you apply it.
  • Apply automatically when idle: the update is downloaded and verified as soon as it is published. The node is then drained (it stops accepting new connections while existing sessions finish) and the update is installed the next time the node has had no open transfers and no sessions for a full minute. Nothing is ever applied while the license standing cannot be verified, and in a cluster nothing is applied while a member is offline, mid update, or failed.
  • Only between: an optional daily time window, in the local time of each node on a 24 hour clock (for example 01:00 and 05:00). A window may cross midnight. Leave both times blank to allow any time of day. Outside the window a node that was drained for an automatic update accepts connections again.
  • Apply now grace period: how long Apply now waits for open transfers to finish before terminating the sessions that remain. The default is 600 seconds (10 minutes).
  • Private release repository: leave it blank to use the Syncplify release channel. Large customers may be granted the right to run a private release repository of their own, a paid option; contact Syncplify if interested. Enter its root URL here only when Syncplify has set one up for you.

The policy can be changed once a valid license is active.

Applying an update ​

Applying restarts the Web/REST, worker and SyngoDB services on the node, so the console on that node is unreachable for a few minutes and asks you to sign in again afterwards. A backup of the configuration database is taken before anything is stopped, the previous version is kept in a rollback slot, and it is restored automatically if the new version fails its health check. Each node has its own card with two actions:

  • Apply when idle (recommended): the node is drained now, and the update is installed once it has had no open transfers and no sessions for a full minute, inside the daily time window if one is set. No transfer is ever cut. There is no deadline: the update waits as long as it takes, and the card shows what the node is doing right now (sessions, uploads, downloads, R2FS! open files) and since when it has been idle. Cancel the waiting update undrains the node and keeps the downloaded release.
  • Apply now: the node is drained, open transfers get up to the grace period to finish, and every session still open after that is terminated. Two confirmations are asked, the second one at the moment of service interruption, and the dialog states how many sessions and transfers are open right now. Apply now instead is also offered while an update is waiting for an idle moment.

While the update runs, the card follows its phases (staged, applying, health check, done, failed or rolled back) and the step in progress. The console on the node being updated becomes unreachable until the health check passes; on a cluster you can watch from another node. The card then shows the last result: the version transition, and the reason when it failed.

Three outcomes are possible:

  • Done: the node runs the new version and passed its health check.
  • Rolled back: the health check failed and the previous version was restored: Web/REST, worker and SyngoDB together. Nothing further is needed; the reason is shown and in the notifications.
  • Failed, manual attention required: the health check failed but the node was left on the new version, because the SyngoDB data layout changed and restoring the previous binaries would be unsafe. A pre update backup is in the data directory. Contact Syncplify support before taking any further action.

An apply request is refused when the installation is not eligible, when the standing could not be verified and the responsibility statement is not accepted, when an update is already in progress, when another node holds the update lease, or when the release could not be downloaded or verified; the page says which.

Cluster ​

In a high availability cluster the page adds a cluster section: which nodes run which version, which node holds the update lease and since when, and whether a cluster update pass is running (which node, and how far along). Nodes are always updated one at a time: the update lease guarantees it, so the cluster stays up throughout an update.

Update cluster starts a rolling pass of every node: peers first, in node ID order, the console's own node last, so you can keep watching from here for as long as possible. You choose whether each node applies when idle or with Apply now. Each node is drained, updates when its turn comes, and must pass its health check before the next one starts. The pass stops at the first failure: the failed node is reported, the remaining nodes are not touched, and per node actions and automatic updates stay off until you clear the halted pass with Clear the halted pass after fixing the node. A running pass can be canceled; a node that is already applying finishes what it started.

A cluster is never updated while a member is offline, because that node could not follow. Bring it back online, or remove the dead node first from the Cluster page. Updating a single node by hand while members are offline is possible: the offline members are listed and you must acknowledge them explicitly. A cluster can update itself only once every member runs 8.4.0 or newer; older members must be updated with the setup program first.

The Cluster page shows the same standing per node and offers the same per node actions.

Where else updates show up ​

  • The Dashboard has a Software updates tile with the current standing and a shortcut to this page.
  • The top bar shows an Update available pill that links here; its colour and tooltip say whether the installation is eligible.
  • The sign in screen carries a notice about available updates, the maintenance standing, and the outcome of the last update on this node.
  • Notifications are raised (once per cluster, not once per node) when a version is published, when an update is staged, started, done, rolled back or failed, and for every step of a cluster pass. The Telegram bot, when configured, receives the same events.
  • The Admin UI shows Admins that a version is available and, when the installation is not eligible, that the SuperAdmin must extend the maintenance plan.