Updates

WHost Updates

The Overview tab draws the version card from the agent's last vendor check (the scheduler asks daily and five minutes after every agent start); when that answer is more than an hour old, opening the tab asks the vendor again in the background and the card follows the answer. The version card shows the current version, the version this server is offered (the next release it can install — one release at a time between stable releases, the newest between betas of one line), the channel and, when a newer release exists, the release notes in the Changelog card, grouped by kind (new features, improvements, security, fixes, changes) and written in the panel's language when the vendor published them in it, in English otherwise. "Check for Updates" asks the vendor again. A check that could not be answered — the vendor unreachable, a limiter answer — is shown on the card as "Failed to check for updates" with the reason; the card never reads "You're up to date" for a check that did not run. "Install Update" opens a confirmation naming the versions; the install runs on the server, the card turns into the eight-step progress stepper (backup → downloading → verifying → extracting → migrating → applying → restarting → health_check), and when the agent has restarted on the new version the page reloads itself. A refused install (already on the latest version, no check in this agent process, a limiter answer — six starts per hour, the toast names the seconds left, or a backup, a restore or a scheduled backup running on the server — the install ends in a restart that would cut it, so the toast names that work and when it started; install once it has finished) is shown as an error toast with the agent's reason and the card stays where it was. While an install runs, backups and restores are refused and scheduled backups wait for its end (see Backups — scope and settings). A failed install shows the failure card with the agent's reason (for example a package whose code does not compile, or one that carries another version than the one offered) and, when the agent put the previous version back, the rollback notice; the service keeps running the version it had, nothing is restarted, and the History tab lists the run as rolled back. A release that installs but does not start is put back by the agent's post-update check about two minutes after the restart; the page then reports the failure and the History row reads rolled back. There is no roll-back button: the previous agent tree stays beside the new one on the server. Choosing the beta channel asks for beta releases; it does not admit the licence to the beta programme. A licence that is not admitted is answered from the stable channel: the card lists no beta release, and because the check carries that refusal the version card shows the note "Beta programme: this licence is not admitted, the stable channel was used". To receive beta releases, ask WISECP to admit the licence holder to the programme. The "Update available" banner in the topbar reads the result of the scheduler's last check (daily, and five minutes after every agent start) and never asks the vendor itself; "Check for Updates" refreshes it.

The History tab lists every install attempt — from/to version, date, manual or automatic, status (completed, failed, rolled back) with the error text on hover — ten per page.

The Settings tab saves every change at once, one field per save: the update channel (stable / beta; a server installed from a beta release starts on beta), the automatic-updates master switch with its type (all, security fixes only, patch only, minor), and six preferences — backup before update, notify when available, notify when installed, check OS packages periodically, notify on OS security updates, allow the vendor to push critical updates. Backup before update archives the agent code alone — not the configuration — under /var/whost/backups/update_<time>/, and the newest three archives are kept; undoing a failed update does not need it, because the run and the post-update check put the previous version back themselves. The two notify switches decide whether the scheduler sends the update-available notice and the notice after an automatic install; a failed automatic install is always reported, an install started from the panel sends neither, and the notification settings still choose panel and e-mail. Security mode without the vendor override never installs anything by itself; the page says so under the switch. An automatic install that finds a backup running waits and tries again 30 minutes later, without a failure notification. A save the agent refuses (a limiter answer, an invalid value) returns the control to its stored value and shows the reason.

OS Packages

Lists pending apt / dnf upgrades with the installed and available versions and a category (security, feature, bug fix, other); the tab badge and the topbar banner carry the same counts. The list is the agent's last package scan (daily, and after every upgrade); opening the tab scans again in the background only when that scan is more than an hour old, and the refresh button beside the card title scans at once. "Apply Security Updates" (disabled when no security update is pending) and "Apply All Updates" each open a confirmation; the upgrade runs in the background and the card above the list shows its progress, its result and the number of packages upgraded — the page can be left while it runs. A list that could not be read (a limiter answer, the package manager busy) is shown as an error with a Refresh button, never as "no updates available". When the host asks for a reboot (kernel, libc) a banner offers "Reboot Now" behind its own confirmation. The last 100 upgrade attempts are kept on the server. Package names sent to the API are checked against the pending list — a name that is no longer pending is refused straight away with Unknown package(s) — not in the pending update list, so a stale request cannot occupy the single upgrade slot.

Endpoints used: GET /system/update/check, POST /system/update/install, GET /system/update/status/stream, GET /system/update/history, GET/PUT /system/update/settings, GET /system/packages/summary, GET /system/packages/updates, POST /system/packages/upgrade, GET /system/packages/upgrade/status, POST /system/reboot. The update preferences live in /etc/whost/update_settings.json on the server (configuration.md).