4.1.4

4.1.4 follows the 4.1.3 mail hotfix. It fixes what the 4.1.3 known limitations said 4.1.4 would fix, closes the shared-cache findings of the 4.1.3 security audit, and makes the update and install paths fail loudly instead of quietly.

Upgrade notes and behaviour changes​

• WordPress sites installed by the panel between 3.9.6 and 4.1.3 now keep their security keys in wp-config.php rather than in the database. Their logged-in users are signed out once after the update and need to sign in again. The panel's WordPress installer left the comment before the eight keys (AUTH_KEY to NONCE_SALT) unclosed, so the keys it wrote were part of a comment and WordPress generated its own and kept them in its database, where anyone who can read the database (a plugin's SQL injection, a leaked backup) could forge sign-in cookies. The update runs hitechcloudcli websites-wp_install heal-salts --once once: only a wp-config.php that carries exactly the block the panel wrote is rewritten, as the account, with fresh keys, and the keys WordPress kept in the database are deleted. A key block of the customer's own, or WordPress's sample block, is left alone, and a wp-config.php the account cannot write is skipped and reported, never made writable. The update lists each WordPress site it could not heal, by the path of its wp-config.php, and shows its success tick only when every site was healed; a skipped site is tried again by the next update. (hitechcloudcli#471, #472, #473)
• Greylisting starts from empty. rspamd's greylist keys now use the prefix hitechcloud.rspamd:rg, which no account's cache login can reach, and greylisting signs in to the cache as its own user hitechcloud.rspamd. The history kept under rspamd's default rg is no longer read, so a sender that was already known is delayed once more, for the greylist delay, and then passes as before. On Ubuntu 22.04 (rspamd 3.1) and Debian 12 (rspamd 3.4) with a secured cache, greylisting stays off: rspamd before 3.7 cannot sign in with a username, and it is never given the cache administrator's password. The command says so; rspamd 3.7 or later fixes it. (hitechcloudcli#460, #467)
• The webmail's cache keys move under Webmail:. The update moves the webmail's live keys to their new names and files every open session in the new session indexes before the webmail restarts, so nobody is signed out. On a server where a hosting account is named after one of the old key families (for example sess), the old sessions are deleted instead, because that account could have rewritten them, and every webmail user signs in again. The old key families stay granted to the webmail's cache user for this release only; 4.1.5 removes them. (hitechcloudcli#469, hitechcloudmail#90)
• Database restores use the account's own database login only (behaviour change). Every restore path (account restore, backup sets and jobs, site import, Copy a database) refuses a ~/my.cnf or ~/.my.cnf that names root or another account's login, reads the dump with the same rules as Copy a database, and runs the database client as the account. Accounts migrated from the retired container stack carry such a file; the update replaces it with the account's own login (hitechcloudcli account own-db-login --all), which is also how to repair one by hand. (hitechcloudcli#457, #468)
• Server > Databases in 2087 is the Super Admin's (behaviour change). The page lists every database and login on the server and can kill connections and change the database services' limits; it was open to every delegated administrator. A delegated administrator now reaches it only when the Super Admin grants it on the same page as the phpMyAdmin and pgAdmin grants; the grant is off until it is set. (hitechcloudadmin#315)
• An API token made with a token is no broader than that token (behaviour change). A token created through POST /api/account/mcp with an existing token expires no later than it and is limited to the same features and addresses or fewer. A token created by someone who signed in is not affected. (HiTechCloud-Panel#1753)
• Copy a database into another account asks what a switch to that account asks (behaviour change). The target account must be in good standing, not locked out and allowed from the caller's address by its own allowlists, and when it has an authenticator app its current code is entered on the form, exactly as when switching to it. A target whose only second factor is an e-mailed code is refused. Only one copy per customer runs at a time; another is refused until it has finished. (HiTechCloud-Panel#1752, hitechcloudcli#453)
• Servers whose cache is shared without a password are named on every update. A server that already had hosting accounts when it was installed keeps a cache any local account can sign in to as default. Every update now says so for each such instance and gives the way out. hitechcloudcli objectcache clients lists the clients that securing it would cut off, and objectcache secure first moves the panel-managed WordPress object caches onto each account's own cache login, so securing such a server no longer breaks its WordPress sites. (hitechcloudcli#466)

Added​

• hitechcloudcli objectcache clients, objectcache rewire-wordpress [--account NAME] (every update runs it) and objectcache wordpress-enable --account A --dir D, which turns a WordPress site's object cache on without the FLUSHDB that an account's cache login is refused: only that site's own keys are cleared, and the plugin's drop-in is put in place as the account. (hitechcloudcli#466)
• hitechcloudcli account own-db-login [--all|<user>], which gives an account a my.cnf naming its own database login; the update runs it. (hitechcloudcli#457)
• 2087: a REST API for customers (/api/customers: list, create, show, delete, link and unlink accounts), and a Customer column and filter on Users. (hitechcloudadmin#316)

Fixed​

• Every panel restart, and so every update, signed every webmail user out. Since 4.0.8 the panel cleared its Redis cache whenever it started by deleting every key on the shared instance except the panel's own sessions (session:*). That instance also holds the webmail's sessions, rate limits and replay guards, and every hosting account's own keys, such as WordPress object caches. All of them were deleted on each restart. The panel now clears only its own memoized values, under hitechcloud_cache_, with SCAN MATCH on that prefix. Webmail sessions, the 4.1.4 webmail session indexes and accounts' keys survive an update. (HiTechCloud-Panel#1775)
• WordPress actions in 2083 (for example turning the Redis object cache on or off) failed with 500 Could not open input file: /etc/hitechcloud/wordpress/wp-cli.phar after any update or repair. wp-cli runs as the account, and since 4.0.4 updates close /etc/hitechcloud to the accounts. The installer no longer puts the stock wp-cli there; the update renames a stock copy it finds to wp-cli.phar.stock-disabled (never deletes it) once /usr/local/bin/wp is known to work, and leaves an operator's own copy alone with a warning. 2083, the CLI and the site scanner take /usr/local/bin/wp, then wp on the path, then a download cached in /var/cache/hitechcloud/toolkit, never a path under /etc/hitechcloud; Composer is found the same way. The 4.1.3 workaround is no longer needed. (hitechcloudcli#470, HiTechCloud-Panel#1772)
• A WordPress install could fail with a PHP parse error. A generated key containing */ closed the comment around the keys in the middle of the value. Keys are now drawn without * or /. (hitechcloudcli#471)
• An interrupted update could be recorded as complete before the services were restarted (a 4.1.3 known limitation). The previous processes kept serving the new files and every later run said "No update needed". The update is now marked incomplete until its restarts are made, so the next run does it again, together with the restarts it owed. (hitechcloudcli#450)
• An update reported the panel as running when nobody could sign in to it. The check after the panel restarts asked only /healthz and /login, which answer without a usable cache. It now also signs in to the cache exactly as the panel engine does, and a refusal fails the update, naming hitechcloudcli objectcache panel-login. The installer ends with a "NOBODY CAN SIGN IN TO THE HOSTING PANEL YET" banner and the fix in the same case, and multiweb status keeps saying so. (hitechcloudcli#451, #465)
• Sending from the webmail failed on a server whose own hostname resolves to a private address (behind NAT, in a container, or mapped in /etc/hosts; a 4.1.3 known limitation). The webmail's outgoing-connection guard now exempts exactly this server's own mail host, on the standard mail ports, in panel mode; every other host is checked as before. (hitechcloudmail#91)
• webmail update keeps the webmail's REDIS_URL only when the webmail's own client can sign in with it, checked the way that client signs in, and writes a new one otherwise. (hitechcloudcli#454)
• Greylisting turned on before the cache was secured stopped without a word; rspamd's cache login is now written and checked the way rspamd signs in, and greylist show tells a refused login apart from an unreachable cache. webmail doctor signs in to the cache instead of only opening a connection, and ending a user's sessions (password change, delete, suspend) reads the panel's cache login the way the engine does. (hitechcloudcli#460)
• mail tls, which every certificate issue and renewal runs, said Postfix and Dovecot were presenting the new certificate even when one of them did not come back; it now checks Dovecot's configuration before reloading, names a service that is not running afterwards, and exits 1. (hitechcloudcli#455)
• An update no longer unpacks the new release over the running one: it unpacks beside it and swaps it in once everything is there, so a full disk or an interrupted extraction leaves the live files as they were. Every binary it installs is written to disk before it is renamed into place. (hitechcloudcli#463, #464)
• A renamed account's backups made before the rename were deleted after the GDPR erasure period as if the account had been terminated. Erasure now follows the rename. (hitechcloudcli#456)
• Sentinel missed out-of-memory kills: it read only a syslog file, only per-group kills and only one date format. It now reads the kernel journal and reports every kill, including the server-wide one, once. (hitechcloudcli#452)
• 2083: the sign-in, forgot-password and team-member pages list each language by its own name (日本語, Tiếng Việt, العربية) instead of its code. (HiTechCloud-Panel#1759)
• 2083: the input patterns of the new domain, document root, mailing list, anonymous FTP and git deploy forms did not compile in browsers and were ignored; they now apply. (HiTechCloud-Panel#1762)
• 2083: domain alias messages are translated, the activity page's sort links are named, and the accessibility findings on the pages added in 4.1.2 are fixed. (HiTechCloud-Panel#1756, #1757)
• 2087: every locale's flag shows on Settings > Locales; menu, form pattern and contrast fixes on the pages added in 4.1.2; the Services page checks the cache socket the panel engine actually uses. (hitechcloudadmin#317, #320, #321)
• Translations: Polish is complete with no orphaned entries, and the Copy a database second-factor messages are in all eight machine-translated languages. 2087's machine-translated catalogues are now held to the Vietnamese one in CI. (translations#67, hitechcloudadmin#319)

Security​

• On servers with a secured cache, signing out a mailbox's other webmail sessions after a password reset or change, and OpenID Connect back-channel logout, work again (a 4.1.3 known limitation). The webmail now finds a user's sessions through an index it keeps beside them instead of SCAN, which its cache login is refused. (hitechcloudmail#90, hitechcloudcli#469)
• Every webmail key is under Webmail:. No account name starts with a capital letter, so no hosting account's cache login can reach the webmail's sessions, rate limits or replay guards, and the webmail's own cache user is limited to Webmail:*. In 4.1.3 an account named, for example, sess could have rewritten webmail sessions; 4.1.3 refused such names as a stopgap. (hitechcloudmail#90, hitechcloudcli#469)
• The panel's startup cache clear deleted state that must outlive a restart: token revocation ("sign out everywhere", password changes), sign-in lockout counters, TOTP replay markers, password-reset tokens and the portal API's spent refresh tokens and revoked token families. A panel restart reopened all of them. They are now kept. (HiTechCloud-Panel#1775)
• The panel, 2087 and the CLI send the panel's cache login over a unix socket only when the socket is owned by root or a system user. The default socket sits in a world-writable directory, where a hosting account could have listened in its place and been sent the cache administrator's password. The panel's last two key families outside its prefix (tokens_valid_after, email_import) moved under it, so an account named after them can no longer bring back revoked tokens. (HiTechCloud-Panel#1758, hitechcloudadmin#318, #320)
• A hosting account's cache login is never created without its denies: SCAN, KEYS, RANDOMKEY, DBSIZE, PUBSUB and SCRIPT are always refused, and an engine that refuses every safe rule set leaves the account without a cache login and says so, instead of falling back to a login that could list every key on the instance. On Redis 6.0, which has no channel permissions, account logins and greylisting's login get no publish/subscribe at all. (hitechcloudcli#461, #467)
• Database restores never run as root and never with another account's login. (hitechcloudcli#457)
• The webmail's root sudo rule, unused since 4.0.8, is removed on update. (hitechcloudcli#458)
• A session of one account could copy a database into another account of the same customer and so run SQL as that account without its second factor or allowlists; the copy now asks what a switch asks. (HiTechCloud-Panel#1752)

Known limitations​

• A mailbox that was created in 2083 while sign-in or mailbox creation was broken on 4.1.2 may never have been fully created: its password is refused over IMAP and opening the webmail from 2083 returns to the mailbox list. The update does not repair such a mailbox. Reset its password in 2083, or delete it and create it again.
• 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 Upgrade notes).