4.1.6

4.1.6 follows 4.1.5. It fixes the problems that the new weekly live test (real installs and updates on throwaway servers) found in 4.1.4 and 4.1.5: autoresponders and account mail after the update, portal sign-in, phpMyAdmin single sign-on on AlmaLinux, and creating databases on MariaDB 11.8. It also moves the CLI to ureq 3, so the Rust advisory scan ignores nothing, and makes a WordPress site's own cache flush work on a secured cache.

Upgrade notes and behaviour changes​

• A fresh install now closes /etc/hitechcloud to the hosting accounts at once, as an update already did. Before, a fresh server kept the directory open (0755) until its first update, and that first update is where the mail problems below began. Only the services that need it may pass through: the mail delivery user vmail and the postdrop group are now among them. (hitechcloudcli#486)
• WP Helper moves to /usr/local/lib/hitechcloud/wp-helper (root-owned, read-only for everyone). A WordPress installed from the panel copies it from there. The old copy under /etc/hitechcloud/wordpress/plugins is still written. (hitechcloudcli#486)
• New update steps: wp-helper, cache-wp-flush and panel-db. A new socket unit, hitechcloud-cacheflush.socket, serves a WordPress site's own cache flush. The update also creates /etc/hitechcloud/portals/bff.env (root only, 0600), which the portals start using in 4.2. (hitechcloudcli#484, #485, #486, #488)

Fixed​

• Autoresponders sent no replies after the update to 4.1.5, and the server-wide Sieve rules that run before delivery were skipped on every message (Ubuntu and Debian; the before-delivery rules also on AlmaLinux). The update had closed /etc/hitechcloud without letting the mail delivery user through. The next update repairs existing servers. (hitechcloudcli#486)
• Mail sent by the hosting accounts' own websites and cron jobs (PHP mail(), sendmail) failed with "Permission denied" on Ubuntu and Debian servers updated to 4.1.5. (hitechcloudcli#486)
• A WordPress installed from the panel after the update came without WP Helper (the SiteManager auto-login plugin), on every OS. The install still reported "finished". (hitechcloudcli#486)
• The Mail, DNS and S3 portals refused every sign-in on their default address (https://<server hostname>:2091, 2092, 2093) with HTTP 500. This broke both "Open the portal" single sign-on from 2083 and the portal's own sign-in form (4.1.4, 4.1.5). The front-end now forwards the address the browser used, including the port. Requests from another site or another portal are still refused. The update fixes existing servers. (HiTechCloud-Panel#1809)
• phpMyAdmin single sign-on from 2083 opened phpMyAdmin's login form on AlmaLinux and RHEL (4.1.4, 4.1.5). The EPEL package keeps its configuration directory closed to everyone but root and group apache, so phpMyAdmin could not read its configuration. phpMyAdmin's own user now gets an ACL that lets it pass through that directory (execute only), and nobody else does. (hitechcloudcli#487)
• 2083 could not create a MySQL database on Debian 13 and Ubuntu 26.04 (MariaDB 11.8). MariaDB 11.3 added the SHOW CREATE ROUTINE privilege to what "ALL PRIVILEGES" means on a database, and the panel's database login did not have it, so the grant to the account was refused and the database was removed again. The panel's login now gets every database-level privilege the server knows, and nothing more. (hitechcloudcli#488)
• On a secured cache, a WordPress site's own object-cache flush did nothing. The Flush Cache button and wp cache flush failed, and Enable/Disable in wp-admin left stale data. These now clear that site's keys, and only those, through the panel: a root service learns the account from the kernel and clears only that site's own prefix, one flush at a time per account. (hitechcloudcli#485)
• 2087 no longer tries at start-up to keep five files executable that no install ships (the old /etc/hitechcloud/wordpress/wp-cli.phar, csf.pl under /usr/local/admin/modules, and three scripts from the container stack). (hitechcloudadmin#326)

Security​

• TLS roots: no advisory ignored any more (RUSTSEC-2026-0381). The CLI's HTTP client moves from ureq 2 to ureq 3, so webpki-roots 0.26, the wrapper ureq 2 required, is no longer in any lock file, and the Rust advisory scan ignores nothing. Every request behaves as before: the same timeouts, redirects, status handling, certificate pinning and body limits, and no proxy taken from the environment. The webmail calls (end sessions, purge, export, import) were checked on a live server. The floor check now also rejects any webpki-roots 0.x. (hitechcloudcli#483, HiTechCloud-Panel#1807)
• A fresh install closes /etc/hitechcloud to the hosting accounts from the start (see Upgrade notes). (hitechcloudcli#486)

Changed​

• The weekly live test of real installs and updates now also checks 2083 two-step sign-in, the account switcher, delegated-admin refusals, WordPress install, database copy, the file manager and AutoSSL issue (against a local ACME test server). (HiTechCloud-Panel#1803, #1808, #1810)

Known limitations​

• On AlmaLinux with SELinux enforcing (not tested), PHP may be refused the connection to the cache flush socket. A WordPress site's flush then behaves as in 4.1.5.
• Greylisting stays off on Ubuntu 22.04 and Debian 12 when the cache is secured, as their rspamd cannot sign in with a username (see 4.1.4).