Skip to main content
Enterprise Annual License: pay for 10 months, get 12.Claim the free months
HiTechCloudPanelDocumentation
Version: 4.1

Update

hitechcloudcli update checks whether a new release exists and installs it.

hitechcloudcli update            # update if autoupdate or autopatch is on
hitechcloudcli update --check    # only report what is available
hitechcloudcli update --force    # update regardless of those settings
hitechcloudcli update --admin    # HiTechAdmin only
hitechcloudcli update --panel    # the hosting panel only
hitechcloudcli update --cli      # HiTechCloudCLI only
hitechcloudcli update --repair   # converge from the release on disk, no download
hitechcloudcli update --translations   # refresh the installed panel translations only

Refresh one area's service files and templates, and nothing else (any number of these together; they cannot be combined with the options above):

hitechcloudcli update --wp          # wp-cli and composer
hitechcloudcli update --ols         # the OpenLiteSpeed WebEngine's configuration
hitechcloudcli update --apache      # the Apache WebEngine's configuration
hitechcloudcli update --clamav      # ClamAV's configuration, limits and signatures
hitechcloudcli update --phpmyadmin  # phpMyAdmin's configuration
hitechcloudcli update --postgres    # PostgreSQL's configuration and access rules
hitechcloudcli update --skeleton    # files new accounts start with (adds missing ones only)
hitechcloudcli update --ssh         # the jailed and restricted login shells, the jail rules
hitechcloudcli update --varnish     # Varnish's service and every account's VCL
hitechcloudcli update --cron        # the scheduled jobs

Where a release comes from​

The mirror, and only the mirror. https://mirrors.hitechcloud.org/version is the version this server compares itself against, and https://mirrors.hitechcloud.org/releases/<version>/ is where the runtime bundle and the binaries are fetched from. Set HITECHCLOUD_MIRROR to read from a different one.

There is no GitHub or Docker Hub fallback. The repositories are private, so mirrors.hitechcloud.org/api answers 404 for a server with no token — which every customer server is — and asking could only ever cost a timeout and then fail. A version the mirror does not carry is a version this server cannot install anyway, so the mirror is the only place worth asking. A mirror that cannot be reached is reported as a real failure rather than papered over.

Versions are compared as versions, not as strings, so 2.1.9 is correctly older than 2.1.30.

What an update does​

An update runs from start to finish in one go. There are no version-specific scripts to run and nothing is left for a later update to finish.

  1. Install. The release is fetched from the mirror and checked against its signed SHA256SUMS (or, on a server installed from a checkout, the checkout is updated). The release's own hitechcloudcli goes in first. If it differs from the program already running, the rest of the update is handed to it, so the new release's steps run now, not on the next update. The new program does not download the release a second time. After that come the CLI tree, the service and web server templates, the feature sets, the webmail, every panel binary and both engines. Each binary is checksummed and keeps a .prev copy of the build it replaced. If nothing could be installed, the update stops here: nothing else is changed and the version file is left alone.
  2. Converge. One ordered list of steps brings the server in line with the release, whatever release it came from. Each step checks whether there is anything to do, so the whole list runs on every update:
    • the update timer's own unit;
    • /etc/hitechcloud stays closed to hosting accounts and stays readable by the services that need it;
    • the central user-backup schedule line;
    • the templates are copied into place and every installed WebEngine's main configuration is rendered from them, with the default engine kept as the default;
    • FTP: pure-ftpd is switched to its virtual-user database, and remaining FTP logins are converted to virtual users;
    • mail, where it is configured: Postfix's main.cf settings and master.cf listeners, and Dovecot's settings in the configuration language of the Dovecot installed (2.3 or 2.4), are rendered from the release's templates (hitechcloudcli mail apply-config), then the mail tables are rebuilt (mail sync). Dovecot is asked to check its new settings before it loads them; settings of the panel's that it refuses are put back as they were, and an error in a file the panel does not write is named;
    • every website's configuration (vhost rebuild --all);
    • phpMyAdmin's PHP pool and front end, where phpMyAdmin is served;
    • the mail client autoconfiguration responder and its pool, where it is set up;
    • settings a release added to waf.conf, appended at their defaults. A setting you already have is never changed;
    • the jail's sudoers rules and sysctls, then the Resource Engine and every account's limits;
    • the Services page catalogue, the installed locales, the module and feature lists, and the scheduled jobs.
  3. Record the new version in /usr/local/hitechcloud/version and /etc/hitechcloud/version.
  4. Restart the panel, then HiTechAdmin, then the web application firewall (only if its binary or its settings changed). The restarts come after the version is recorded, so the Updates page shows the new version as soon as it is back. If the panel does not start on the new binaries, the builds it replaced are restored from their .prev copies and the previous version is written back.
  5. Runs the custom post-update hook (/root/hitechcloud_run_after_update), if there is one.

If any convergence step could not finish, or a panel does not answer after the restart, the update writes /var/lib/hitechcloud/update-incomplete. The version is still recorded, but the next run of the update timer runs the update again, even at the same version, until nothing is left undone. The log says which step failed and which command to run by hand. hitechcloudcli update --repair runs the same convergence from the release already on disk, without downloading anything, and restarts the services. When it finishes cleanly, it clears the marker.

Each run is logged to /var/log/hitechcloud/updates/<version>.log, a lock file keeps two updates from running at once, and an update that is still running after 85 minutes is stopped (HITECHCLOUD_UPDATE_MAX_SECONDS). The automatic update timer allows it 90 minutes.

Which servers can update​

An update starts from 4.0.1 or later. A server that records an older version is refused before anything changes. Install the release on a fresh server and move the accounts across with hitechcloudcli migrate accounts plan --from <old server>. A server whose version file cannot be read is updated: none of the steps above depend on the version it is coming from.

What an update does not do​

  • It does not update the operating system's packages or the kernel.
  • It does not touch a server that has neither autoupdate nor autopatch enabled unless you pass --force.
  • It does not install a version listed in /etc/hitechcloud/upgrade/skip_versions.
  • It does not overwrite settings you have tuned in waf.conf or in the scheduled jobs. It only adds what a release introduced.

Running it from the panel's terminal​

An update restarts the panel and the admin panel. Started from a panel Terminal page, the update would be a process inside one of those services, and restarting the service would kill it half-finished. So when it detects that, the update re-runs itself in a systemd unit of its own and keeps your output and exit status — the restart takes your terminal session with it, and the update runs to the end regardless.

Previous
Toolkit
Next
Users
Was this helpful?