Keeping the server current
From version 8.4.0 Syncplify Server! keeps itself current. Each node checks Syncplify's signed release channel once a day, tells you what it found, and can install a new version on its own: on request from the SuperAdmin console or the command line, or automatically when the node is idle, according to an update policy. The setup program is still the way to install the software for the first time, to upgrade from a v6 installation, and to install 8.4.0 itself; from then on it is one of two equivalent ways to update, and both run the very same sequence on the node.
This page explains what happens, in what order, and what the rules are. The console is described on the Updates page.
Trust
Every release is published on a channel that Syncplify signs with an offline key. A node verifies four things before it installs anything: the channel index signature, that the index is not older than one it already saw (so a stale index cannot be replayed at it), the signature of the release package, and the checksum and size of every file inside it. A node that cannot verify a release does not stage it. From 8.4.0 the setup program is signed with the same key, so there is one trust root for the software however it arrives.
The channel is served over HTTPS from https://ss-release.us-ord-10.linodeobjects.com. A node knows the address on its own and nothing has to be configured; it is listed here for the one case where it matters, a firewall that must allow the node outbound HTTPS to it. The address carries no trust: every byte fetched from it is verified as above, so a wrong or hijacked address can only cause a refusal, never a bad update.
Private release repositories
Large customers may be granted the right to run a private release repository of their own, a paid option; contact Syncplify if interested. The update policy's Private release repository field points the server at it, and nothing else changes: the repository is a mirror of the signed channel, so the same signatures are verified and the trust still never comes from the address. Leave the field blank otherwise.
Eligibility
Updates and upgrades require an active maintenance plan on the license. A node checks its standing before it downloads anything: a trial license is eligible while the trial is valid; a full license is eligible while its maintenance plan is active and the license covers the published version. When the installation is not eligible, the node still learns that a newer version exists and says so prominently, with the license code and the steps to extend the maintenance plan in the Syncplify Customer Portal. Software that is not up to date may be vulnerable, because it is not running the latest security patches.
When the licensing service cannot be reached from the node, neither the standing nor the revocation status of the license can be verified. Automatic updates then never apply; an operator can still apply by hand after accepting full responsibility, exactly as the setup program asks on a machine without outbound access.
What happens on a node
An update is applied by the product's own updater, which runs as the new version's Web/REST binary from the staged release, never inside the service it is replacing. The steps, in order:
- Preflight. The updater refuses to run in a container, without administrative rights, or while another updater runs on the node. It checks that the staged files are what was verified, that the license covers the new version, and that the new SyngoDB server can open this node's data (see below). It records which worker services are running, so exactly those are started again.
- Backup. A backup of the configuration database is taken while the database is still running, using the same automatic backup as the scheduled one.
- Stop. The running worker services, then the Web/REST service, then the SyngoDB service.
- Swap. The three binaries (Web/REST, worker, SyngoDB) are replaced at their installed paths, each previous binary being kept beside it as the rollback slot. Service definitions and firewall rules keep pointing at the same paths.
- Reconcile and prepare. The service definitions are brought in line with the new version, SyngoDB is started, the node's own database credential is rotated if the installation still used the built in one, and the per node database tasks run (schema updates included). This is the same work the setup program used to do.
- Start. The Web/REST service, then the worker services that were running before.
- Health gate. The updater waits for the new Web/REST service to report a healthy node: database open, inter process channel up, web interface answering, every remembered worker running and reporting the new version.
An update that passes the gate is done. One that fails after the swap is rolled back as a set: the three previous binaries are restored, the service definitions are reconciled again, and the node runs the previous version. One that fails before the swap (a service that would not stop, a refused preflight) leaves the node exactly as it was.
The one exception to the rollback is the SyngoDB data layout. When the new SyngoDB server writes a newer data layout than the installed one, its first start may migrate the store, and restoring the previous server afterwards would be unsafe. In that case a failed health check leaves the node on the new version, reports it as needing manual attention, and points at the pre update backup. Contact Syncplify support before doing anything else. A new SyngoDB server that cannot open the installed data at all is refused before anything is touched; such a release is installed with the setup program.
The rollback slot stays after a successful update, so ss-webrest update rollback can restore the previous version by hand later, with the services stopped. Exactly one previous version is kept.
Sessions during an update
A node updates only when it is drained. Draining stops new connections while existing sessions finish. Two modes exist:
- When idle (automatic updates, and the recommended manual action): the node is drained, and the update starts once the node has had no open transfers, no sessions and no R2FS! open files for a full minute, inside the daily time window if the policy has one. No transfer is ever cut, and there is no deadline. Canceling undrains the node.
- Now: the node is drained, open transfers get up to the grace period (600 seconds by default) to finish, then every session still open is terminated and the update starts.
The update itself takes a few minutes, during which the node's virtual sites are down. In a cluster the other nodes keep serving; on a standalone server clients see the node unavailable until it is back. R2FS! nodes attached to the server reconnect on their own.
Clusters: one node at a time
In a high availability cluster, nodes are never updated at the same time. That is the rule that keeps the cluster up through an update: while one node is down for its few minutes, the others carry the load. The rule is enforced by an update lease: a node claims it from every other member before it starts, holds it until its health check passed, and every member refuses a second claim while it is held. The lease is granted to the lower node ID when two nodes ask at once.
Beyond the lease, a cluster update follows a few rules:
- No update while a member is offline. An offline node cannot follow, and a cluster with members on different versions is not what anyone wants. Automatic updates wait; a cluster pass refuses to start; updating one node by hand requires an explicit acknowledgement of the offline members. The remedy for a node that is gone for good is to remove it from the cluster first.
- No update while a member is mid update or failed. A node whose last update failed or rolled back halts everything until an operator clears it.
- A failed node halts the pass. The remaining nodes are not touched.
- Every member must run 8.4.0 or newer. Older members are updated with the setup program first; the cluster tells you so.
There are three ways to update a cluster:
- Automatic (the policy set to apply when idle): every node stages the release, and any node that is idle inside its window claims the lease and updates; the next one waits a settle period after the previous one finished. The cluster converges on its own, one node at a time, with no one watching.
- Update cluster from the console or
ss-webrest update cluster: a rolling pass in a fixed order, peers by node ID first and the initiating node last, each node updating when idle or now as chosen. - Per node, from the console or the command line, whenever you want to control the order yourself. The lease still prevents two nodes from updating together.
Releases that change the cluster protocol are never published to the channel; they are installed with the setup program on every node.
Updating with the setup program
Running the setup program of a newer version on an existing installation updates it. From 8.4.0 the setup program no longer stops, swaps and restarts the services itself: after the license and maintenance checks it stages the binaries it carries exactly as a downloaded release would be staged and hands over to the product's own updater, so the update follows the sequence above, backup, rollback slot and health gate included, and the outcome is reported the same way. In a cluster, run it on one node at a time and wait for the node's health check to pass before starting the next.
The setup program refuses to replace a newer version the server installed on its own. A setup older than what is installed says so and stops; --allow-downgrade on the install command installs the older version deliberately.
Command line
The Web/REST binary has an update command that mirrors the console: status, check, apply (when idle by default, --now to drain and terminate after the grace period), cancel, cluster (a rolling pass) and rollback. When the service is running, apply hands the request to it, so the node drains and the lease is claimed exactly as from the console; when the service is stopped, apply runs the updater directly. See the Command line reference.
Containers
A node that runs in a container never updates itself: the image is the unit of update. The console and the command line report what the channel offers and nothing else; deploy a newer image to update.
Files the updater keeps
Everything lives in the data directory (/opt/Syncplify/Server/data on Linux, C:\ProgramData\Syncplify\Server on Windows) except the rollback slots, which sit beside the installed binaries:
| Location | Holds |
|---|---|
bin/ss-<version>/ | A staged release: the three binaries and set.json, which says what they are. The current one and the previous one are kept. |
bin/update-state.json | The state of the last update on this node: phase, step, versions, reason, warnings, backup file. |
bin/update.lock | Held by the updater while it runs. |
bin/ss-release-floor.json | The newest channel index this node has seen; an older one is refused. |
health.json | The health snapshot the Web/REST service writes every half minute, which the health gate reads. |
update.log | The output of the last updater run. |
ss-webrest.prev, ss-wrk.prev, syngod.prev (beside the installed binaries) | The rollback slots: the previous version, restored as a set on a failed health check or by update rollback. |
None of these needs backing up. The pre update backup archive goes where the automatic backups go.