4.1.2

Upgrade notes and behaviour changes

Host keys are now pinned (behaviour change). HiTechCloud records the SSH host key of a machine the first time it connects (StrictHostKeyChecking=accept-new) and refuses a different key afterwards. This covers nodes added with user-add, the standby of a clone job, user-transfer and server-migrate, the default-node check, git hosts used by deploys, SFTP backup destinations (including restic's) and the legacy DNS slave. A node, git host, SFTP destination, standby or DNS slave that was reinstalled, or whose key changed on purpose, is refused until its old known_hosts line is removed. The error names the command; for a DNS slave it is ssh-keygen -R '<slave address>' -f /var/lib/hitechcloud/dns-cluster/known_hosts. The files are /var/lib/hitechcloud/node-ssh/known_hosts (nodes), /var/lib/hitechcloud/clone/known_hosts (clone jobs, transfers and migrations), /var/lib/hitechcloud/dns-cluster/known_hosts (DNS slaves) and the account's own ~/.ssh/known_hosts (git deploys). Nothing in the CLI or HiTechAdmin passes StrictHostKeyChecking=no any more. (hitechcloudcli#443, #445, hitechcloudadmin#311, #313)
Server pages that are root-equivalent are the Super Admin's alone (behaviour change). A delegated administrator (role user) no longer reaches Server > Nodes, the default node, naming a remote server or key when creating an account, SSH access, configuration files, cron editing (read-only for others), migrating the server, transferring an account, or database servers; the menu entries, tabs and API routes are gone for that role. Work that relied on these pages is now done by the Super Admin. (hitechcloudadmin#307, #311)
phpMyAdmin and pgAdmin are granted by role (behaviour change). phpMyAdmin with the panel's own database login is now the Super Admin's alone; a delegated administrator could reach it before. Delegated administrators and resellers can be granted phpMyAdmin per account, signed in with that account's own database login (a reseller for its own accounts only), and delegated administrators can be granted pgAdmin. The Super Admin sets this on Server > Databases; every grant is off until it is set. (hitechcloudadmin#313)
POST /api/ asks for the second factor (behaviour change). An administrator whose account has an authenticator on must now send the current six digits as code when it requests an API token (without it, or with a wrong one, the answer is 401 two_factor_required; a code is good once). An account whose only second factor is the e-mailed code is refused and pointed to an API access key. Scripts and apps that signed in with a password alone must send the code or use an access key. (hitechcloudadmin#308)
A clone job's standby may not be this server. A standby that is one of this server's own addresses, the panel's server_ip or server_ipv6, or a name that resolves to one is refused when the job is saved, tested and run. (hitechcloudcli#443)
Features whose software is not installed are hidden. In 2083 and 2087 a feature whose component is not installed is no longer shown, and its address answers not installed instead of a broken page; 2087 says so on the module with the way to install it. (HiTechCloud-Panel#1655, #1721, hitechcloudadmin#253)
Audit logs grow. 2083 now also records the pages an account opens and the files it downloads, and the portals' calls, so the audit chain is larger than in 4.1.1; the logs are kept at least 365 days. (HiTechCloud-Panel#1720)
The eight new languages are machine translations. Japanese, Korean, Italian, Dutch, Indonesian, Thai and Arabic are complete, and Polish is complete for the live set of messages (about 28 legacy entries of the Polish catalogue are still untranslated and show in English if a page asks for them); none of them has been reviewed by native speakers: review them before relying on them with customers. Vietnamese and English remain the reference languages.
Update behaviour carried from the first 4.1.2 builds: the customer portals are on unless switched off, an update restarts each service once, and a server with Redis or Valkey open beyond loopback without a password is closed to loopback by objectcache loopback (see Added and Known limitations).

Fixed

A server update restarted the webmail up to three times and the portal API twice: webmail update, the webmail configure that vhost rebuild --all runs, and the Mail Portal address portals converge writes each restarted the webmail, and portals converge and the update's own final restart each restarted the portal API. The update now keeps a restart ledger (HITECHCLOUD_UPDATE_RESTART_LEDGER): those commands note the unit in it, and the update restarts each noted unit once, after the panels are back and everything the service reads is in place, then checks the webmail answers. update, update --panel and update --repair all do this. Run by hand, outside an update, every command restarts at once as before.
hitechcloudcli objectcache status reported the Redis instance on AlmaLinux and RHEL 10 (a Valkey build) as v? with NO ACL SUPPORT, and Per-account cache logins could not be set up was printed on every install. The panel's cache login (REDIS_PASSWORD) and the Redis instance's administrator login shared one name, so with the panel on Valkey the CLI sent Valkey's password to the Redis instance, which refused it. Every engine has its own administrator entry now (ADMIN_REDIS_*, ADMIN_VALKEY_* in /etc/hitechcloud/hitechcloud/cache.cnf), an instance that refuses the password is asked without it, and a CONFIG SET that the server did not take says why.
ClamAV never started on a fresh install: the installer wrote PrivateMirror https://database.clamav.net into freshclam.conf, which freshclam refuses (The PrivateMirror config option may not include servers under *.clamav.net, exit 9), so no signature database was ever downloaded and clamd@scan stopped with No supported database files found. ClamAV's own server is now a DatabaseMirror, the shipped Example line is commented out, freshclam runs to completion (with retries, and a fallback to ClamAV's own servers when the panel's mirror does not answer) before clamd is started, its error text is shown when it fails, and clamd retries every minute until the database exists. An already broken server is repaired by the next update. The duplicate /run/clamd.scan tmpfiles line is gone.
The post-install Checking that mail works no longer runs, and no longer reports Mail was installed and does not work, on a Community edition or where mail install did not finish.
FTP on AlmaLinux and RHEL 10: pure-ftpd-init.service (which runs sscg) fails there and took pure-ftpd down with it. The default certificate is made with openssl before the start and the init unit is neutralised.
PHP: versions the repository does not offer (PHP 5.6 on AlmaLinux 10) are skipped up front with one warning instead of an error for the package and another for its FPM unit. The ionCube loader is set up for all versions in one pass, each version is restarted once and only if it got the loader (seven versions used to mean seven restarts of each, until systemd's start limit refused them: PHP 7.4..8.6 failed to restart), and a version ionCube publishes no loader for (8.6) is a warning that does not fail the others.
module install of the webmail on a server without Node 22 stopped at Missing: node npm; the webmail component now installs Node 22 first.
Firewall: module install no longer tries to start csf and lfd while the firewall is deliberately off (csf.disable), and no longer reports csf did not start. module list carries a note for units that are off by design (firewall off, the machine-wide Varnish, OpenLiteSpeed's lshttpd), and litespeed-enterprise is listed as installed only when LiteSpeed Enterprise really is.
Search: when OpenSearch cannot be installed (its signing key is rejected by the system crypto policy) Elasticsearch is now tried - its repository was never added before - a repository whose key is rejected is removed so later dnf commands are not poisoned, and when neither engine can be installed the module is reported pending with the reason, not as a failure.
Microsoft SQL Server on AlmaLinux and RHEL 10: the licence is accepted non-interactively (ACCEPT_EULA, mssql-conf -n setup accept-eula), openldap-compat is installed for liblber-2.4.so.2, and the install fails with the service's journal instead of printing success when mssql-server does not run.
WireGuard: the PostUp/PostDown firewall rules end in || true, so one rule the running kernel cannot load (Extension MASQUERADE revision 0 not supported) no longer tears the tunnel down; the netfilter modules are loaded first; and a missing NAT rule is reported with its reason, including a newer kernel is installed: reboot when the running kernel is older than the newest installed one.
On the RHEL family Fail2Ban is installed as fail2ban-server only; the fail2ban bundle requires fail2ban-firewalld and so firewalld, a second firewall beside CSF.
The reason user-add failed for the administrator's own hosting account during a first install is printed.
App Store (administrator panel): a unit the CLI says is off on purpose (the firewall left off, the machine-wide Varnish, OpenLiteSpeed's lshttpd) is shown in grey with the CLI's sentence instead of Not running: ... in red; an item whose units are down and whose last install task failed reads failed, not installed beside failed; PHP versions the PHP repository does not carry (5.6 on AlmaLinux 10) read Not available on this operating system.
Starting a background task whose unit systemd still has loaded (Unit hitechcloud-install-postsrsd.service was already loaded or has a fragment file) now says already running when it is, and clears and restarts a stopped or failed one; turning on SRS (postsrsd) on AlmaLinux and RHEL 10, where it is not packaged, says so instead of starting an install that can only fail.
On a fresh install, hosting accounts could not sign in to the panel (port 2083), the Mail/DNS/S3 portals, or through the administrator's "sign in as" link: the browser went back to the sign-in page with no message. The panel could not send its cache password over the unix socket (HiTechCloud-Panel#1621), and the installer gave it the wrong instance's password (hitechcloudcli#348).
Sign-in error message: if the panel cannot save a session, the sign-in page (password, 2FA, passkey, or the administrator's "sign in as" link) now says "Your session could not be saved: the panel cannot reach its session store. Contact the administrator." instead of silently returning to the sign-in form. The panel's log says why it cannot use its cache (login refused, bad address, unreachable) instead of "no connection", and an unusable cache address is logged once per panel process.
An update that fails after the webmail was rebuilt now restarts the webmail (and the portal API, if asked) before giving up, instead of leaving it running the old process over the new build. If an update rolls the panel back to its previous binaries, it also restores panel.env and cache.cnf as they were before the update.
The App Store's PHP "not available on this OS" check uses the package metadata already on the server, so the page never waits on a repository refresh.
2087 Services shows the session store: whether the hosting panel and the portals can reach their Valkey/Redis and whether it accepts the panel's login. HiTechAdmin finds the panel's cache where the panel does and logs in to it correctly; "Signed in now" and API-token revocation on a plan type change work again on Valkey or password-protected caches. App Store "Off" notes are translated, and Settings > Modules links to the App Store.
Vietnamese: the hosting panel no longer shows English in its menu (38 labels), on the live chat pages, the PHP info page or the RDAP lookup. The menu says "OpenSearch".
Webmail: saving the autoresponder no longer resets the reply interval and extra addresses set in the panel or Mail Portal, and an autoresponder that fails to load is shown as an error instead of a blank form that could switch the reply off.
Webmail: settings forms are accessible (labelled fields, named switches and password buttons, announced errors), status colours meet WCAG AA contrast, the allowed-senders button reads Add, and the Meetings service card is translated into Vietnamese.
Front-end: the default page, the suspended pages and a new 502/504 page now share the HiTechCloud look and translate themselves into the visitor's language (Vietnamese included), with a dark variant and WCAG AA contrast. The 502/504 page speaks all 24 languages of the panel, the eight added in this release included, with Arabic laid out right to left. (HiTechCloud-Panel#1736)
One ClamAV source: the panel's ClamAV mirror is used only while it serves signatures, and is then the only source; otherwise ClamAV's own servers are used. New hitechcloudcli repair clamav (also run by repair all) switches back when the mirror stops answering.
Private secret files: cache.cnf, panel.env and the pure-ftpd certificate with its private key are now written through a private (0600) temporary file in one atomic step, keeping each file's owner and permissions.
A website the administrator (or a reseller) suspended came back live when the customer deleted it and added it again: the suspension lived only in the site record that deleting removes. Deleting a website now keeps that suspension, adding it again restores it (with its reason, message and page), and the customer is told <domain> is suspended: it was suspended when it was deleted, and deleting a website does not lift its suspension. Contact the server administrator. Only the administrator, or the reseller who made it, can lift it, even while the site is not on the server. (hitechcloudcli#354; reported as issue HiTechCloud-Panel#1602, which is still open)
User backups of e-mail contained only a dangling link when a domain's maildir is a symbolic link (moved to another disk and linked back): user-backup and backup chains now archive the mail the link points to. A restore no longer drops a whole domain's mail because one mailbox holds a link (such as the ManageSieve ~/.dovecot.sieve): links are removed from the extracted mail, each one logged, and the mail is restored. (hitechcloudcli#355; reported as issue HiTechCloud-Panel#1601, which is still open)
A server update could sit at "Updating installed locales" for hours when the mirror stopped answering: every download from the mirror (locales, the feature and module lists, components) now gives up after 20 seconds and one retry, and the language or component is skipped with a warning. The installed translation is never cut short. (hitechcloudcli#356; reported as issue HiTechCloud-Panel#1613, which is still open)
The hitechcloudcli dispatcher passes ShellCheck with no warnings (no change in behaviour).
Malware scanner API: POST /api/malware-scanner/scan on a server without ClamAV answered 200 with infected_count: 0, so a scan that never ran looked clean to API clients. It now answers 503 with ClamAV is not installed on this server, as the page already did. (HiTechCloud-Panel#1637)
Vietnamese (2083): 464 strings the panel shows had no Vietnamese and appeared in English (dashboard tiles, FTP quota errors, app-install help, the session-store sign-in error, WordPress and Joomla hardening, the product tour); all are translated now, the same terms read the same way everywhere, and the English and Vietnamese catalogues have the same keys, checked in CI. The messages the panel keeps as constants (FTP quota limits, the DNS scope refusal, the session-store sign-in error and 28 more) are translated too. (translations#24, #27)
Restores brought cron jobs back without scheduling them: user-restore, user-backupset --only cron and 2083's Restore & Download now regenerate the crontab from the restored crons.ini, so the jobs run without the account saving a cron job first. Restore & Download also keeps each file's permission bits (never setuid, setgid or sticky) and modification time instead of restoring everything 0644 and dated now. (hitechcloudcli#365, HiTechCloud-Panel#1638)
2087 DNS zone editor: each row's actions stay on one line and the columns no longer wrap a character at a time. (hitechcloudadmin#251)
Vietnamese HiTechAdmin (2087): flash messages after every action, and 23 template strings (plan form, FTP quota labels, backup and DNS editor placeholders, the HSTS/WAF toggles, the logo and favicon previews), were shown in English. They are translated now, and CI fails on any message the admin asks for without Vietnamese. (hitechcloudadmin#254)
Backups now carry an account's MySQL logins (<account>_..., with their stored hash, host and privileges), so a site that connects with its own database login works again after a restore on another server. user-restore --new-username no longer drops the account's databases. Every field read back from the archive is checked before use. (hitechcloudcli#366)
An account restored on a server where it was never added (another server, or user-restore --new-username) got none of its databases back, and the restore still said SUCCESS: the account's own MySQL login is now created first, so its databases come back. (hitechcloudcli#374)
The sign-in page's language picker in 2083 took the flag from the language code, so Vietnamese showed the flag of the US Virgin Islands, Lao none, Nepali Niger's and Serbian Suriname's; they now show the flags of Vietnam, Laos, Nepal and Serbia. (HiTechCloud-Panel#1715) The account page of 2087 chose its flag from the language code too (vi.svg is the US Virgin Islands, ar.svg Argentina, and ja and ko had no file); it now uses the same table. (hitechcloudadmin#314)
Customer portals: a refused change in the DNS portal no longer loses what was typed, and error messages in the DNS and S3 portals are in the page's language instead of English (see Added). A portal address that does not exist shows a translated not-found page instead of a bare error. (HiTechCloud-Panel#1719, #1723, #1724)
2083: row actions stay inside their cell (the DNS zone Delete button, FTP, cron and MySQL rows), and a feature whose component is not installed is hidden everywhere and refused by its address. (HiTechCloud-Panel#1642, #1655, #1721)
2083 team members: a member never opens the account's Mail, DNS or S3 portal, whatever their role; before this fix a member with only Backups got the account's mailboxes. (HiTechCloud-Panel#1716)
The website: accessibility, performance and accuracy fixes from the 4.1.2 audit. (HiTechCloud-Panel#1624)

Added

Customer accounts and resellers

Customer accounts (A4): one sign-in can own several hosting accounts. hitechcloudcli customers list|show|create|link|unlink|delete|of|available groups accounts of the same owner into a customer, which has no credential of its own; it only says which accounts may be switched between. In 2087, Users > Customers creates, links, unlinks and deletes customers (a reseller sees and makes its own customers only; the administrator makes them for itself or for a reseller), and an account that is linked cannot be moved to another owner. (hitechcloudcli#439, hitechcloudadmin#306)
Account switcher in 2083: when a login has other linked accounts, the header shows a switcher, and choosing an account signs in to it without asking for a password again. The target must belong to the same customer, be in good standing, be allowed by the allowlists and not be locked out; the old session ends first; an account with a second factor still goes through the sign-in's second step; a team member's session and an administrator signed in as the account never switch. Each switch and each refused switch is written to the audit chain and to both accounts' activity logs. (HiTechCloud-Panel#1726, hitechcloud-translations#60)
Database copy and move between a customer's accounts (B5): in 2083, a Copy database page (linked beside the switcher) copies or moves one of the account's databases to another account of the same customer (a move asks for its own confirmation), with its routines, triggers and events and a DEFINER rewritten to the target. The database is dumped with the source account's own database login and loaded with the target account's own login, as that account; the dump is read first and refused, with nothing made, if it holds anything a dump of one database does not (USE, GRANT, CREATE USER, SET GLOBAL, a name in another database, a DEFINER of another login, client commands), so a crafted dump cannot run as root. Both accounts must be linked to the customer and not suspended; the copy runs in the background and the page shows its state. Administrators copy or move between any two accounts from 2087 Server > Copy databases. (hitechcloudcli#446, #447, HiTechCloud-Panel#1732, hitechcloudadmin#301)
Monthly report (R7/T4): hitechcloudcli account monthly-report settings|preview|send|run|cron e-mails the accounts report once a month (day 1 to 28, hour, and who gets it) and on request, through the notification channels, as a summary of the accounts at 90% or more of their disk limit and the largest accounts; the administrator's report covers every account and each reseller's its own. In 2087, Users > Monthly report sets the schedule, previews it and sends it now (a reseller previews and e-mails itself only), and Users > Export CSV downloads the full list with each account's plan, disk and this month's bandwidth. (hitechcloudcli#440, hitechcloudadmin#303, #259)
Plan add-ons on the account page and in the API (A7): an administrator or reseller gives an account extra disk, inodes, domains, subdomains or mailboxes beside its plan; a downgrade that would leave a limit below what the account already uses is refused (409) with the reason; an expiry date can be set on the account page and the account is suspended for billing on it. (hitechcloudadmin#264, #297, #257, hitechcloudcli#433)
Team members (A3): an account owner invites people to a Team page and gives each a role made of modules and, optionally, a list of domains; a member signs in with their own login and sees only what the role allows, and never the Team, Account, two-factor, passkey, session or API pages. Invitations expire after 72 hours and can be used once. (HiTechCloud-Panel#1676, #1679, hitechcloud-translations#35)
Support tickets (A18): 2083 Account > Support sends a ticket to the account's reseller or to the administrators, with files, status and priority; resellers answer, escalate and write their own tickets in 2087 Accounts > Support Tickets, and administrators answer, hand back, set priority and write internal notes that no customer sees. Departments, an outside help desk that replaces tickets, a badge with the number of tickets waiting for the viewer, and staff answers e-mailed to the account's own address are included. (hitechcloudcli#405, #423, hitechcloudadmin#276, #291, HiTechCloud-Panel#1692, #1705)
Reseller tools: permission groups that resellers make themselves from the features they were allowed (R6); suspended pages a reseller sets for its customers' sites (R8); menu links in the customer panel's sidebar and Help and Support links, set by the administrator per plan and by each reseller for its own accounts (L2). (hitechcloudadmin#265, #262, hitechcloudcli#387, HiTechCloud-Panel#1660, #1694)
Editable e-mail templates (A14): 2087 Accounts > E-mail Templates edits, previews and resets the texts of the panel's own e-mails (welcome, suspension, expiry, quota and password reset), per language, for the server and for each reseller's customers; the password reset link in 2083 uses the editable message in the account's language. (hitechcloudcli#399, hitechcloudadmin#273, HiTechCloud-Panel#1687)
Notification channels and the alert center: administrators, resellers and accounts choose where alerts go (e-mail, Telegram, Slack, Discord, Mattermost, signed webhooks or syslog), see them in an alert center with a bell in the top bar, and receive backup and restore alerts through the same router. (hitechcloudcli#372, hitechcloudadmin#263, HiTechCloud-Panel#1675)
Reseller overselling switch: hitechcloudcli admin update <reseller> --oversell=yes|no. With overselling off, account add, account owner and user-change_plan refuse, with the figures, any change that would make the disk promised by the reseller's plans exceed the reseller's disk allowance, and a plan with no disk limit cannot be handed out. Resellers created before this release keep today's behaviour until the administrator turns overselling off. In HiTechAdmin the switch is "May oversell the disk allowance" on Accounts > Resellers > Edit, and each change is written to the reseller's activity log. POST /api/settings/resellers takes it as oversell (hitechcloudadmin#252).
Message All Users (2087, administrators and resellers) can also send the message by email to each account's contact address, in the background, with each send recorded in the account's activity log. (hitechcloudadmin#248)
Account expiry: hitechcloudcli account expiry <account> set YYYY-MM-DD|clear, account expiry list and a daily account expiry check that sends a notice before the date and suspends the account on it. The check runs from hitechcloud-expiry.timer (daily at 04:10, catching up after downtime), installed the first time an account is given a date. (hitechcloudcli#368, HiTechCloud-Panel#1656)
Plan add-ons: hitechcloudcli account addon <account> set disk_gb=5 domains=2 emails=10 adds extra disk, inodes, domains, subdomains or mailboxes to one account on top of its plan, and no plan change or quota run undoes it. (hitechcloudcli#380)
Reseller bandwidth: the month's bandwidth served by a reseller's accounts is recorded every four hours beside an optional monthly allowance (admin update <reseller> --max_bandwidth_gb=<n>). It is shown, not enforced. HiTechAdmin's reseller form has a Monthly bandwidth (GB) field, and the reseller's dashboard a Bandwidth this month card. (hitechcloudcli#378, hitechcloudadmin#258)
hitechcloudcli account db-copy <from-account> <database> <to-account> [--name <suffix>] [--move] copies or moves a MySQL database to another account, with its routines, triggers and events, granted to the target account's login; a DEFINER naming the source account's login is rewritten to the target's, so views and routines keep working. The dump is taken with the source account's own login (its ~/my.cnf, which must name the account itself) and loaded with the target's, never as root; root only creates the empty database and grants it to the target. A dump that holds anything but a database's own statements, or a DEFINER of another login, is refused before anything is made. (hitechcloudcli#382, #447)

Audit log, now with views and downloads: 2087 > Compliance > Audit log records every change an administrator, reseller or API token makes (never a password, key or token), names the account and the reason of refused sign-ins, and the tamper-evident chain can be filtered by action, searched and exported as CSV. 2083 records every change an account makes (including API tokens and an administrator signed in as the account), refused sign-ins, and now also the pages an account opens and the files it downloads, and the calls its portals make. In 2087 Accounts > Activity log a reseller sees the log of its own customers' users, covering what they did in 2083 and the portals. The logs are kept at least 365 days. (hitechcloudadmin#250, #302, HiTechCloud-Panel#1653, #1720)
Single sign-on (S16): customers and administrators sign in to the panels through an identity provider (OpenID Connect with PKCE) or a directory (LDAP and Active Directory, over ldaps or StartTLS), with accounts linked explicitly by an administrator and group or role mapping; nothing is provisioned from an address alone, and an account with a second factor still gives it. 2087 Security > Single sign-on manages providers and links. (hitechcloudcli#412, #429, #425, hitechcloudadmin#280, #294, HiTechCloud-Panel#1702, #1711)
API keys (H3): long-lived keys limited to features and to addresses, shown once, for 2083 (Account > MCP tokens) and 2087, accepted wherever a token is; a read-only key cannot make changes. (hitechcloudadmin#266, HiTechCloud-Panel#1666)
Security advisor (S11): 2087 Security > Security advisor gives a score, what costs points, and fixes that can be undone. Real-time malware scanning with a clean copy put back from backup (S8, S9), a PCI DSS hardening preset for web, mail and FTP transport that can be reversed, with a report (S18), and a scheduled rootkit scan with accepted findings and alerts (S10) have native pages. (hitechcloudcli#404, #391, #398, #421, hitechcloudadmin#277, #271, #295)
Web application firewall: third-party rule sets and the OWASP Core Rule Set translated for the firewall (webfirewall ruleset import|sources|remove), paranoia levels on a rule, on the server and per site, and a per-site anomaly threshold (S2). (hitechcloudcli#409, hitechcloudadmin#287, HiTechCloud-Panel#1689)
hitechcloudcli admin ip-allowlist [on|off|add|remove|clear]: shows and edits the 2087/2083 IP allowlists from a shell, the way back in for an administrator who locked themselves out. (hitechcloudcli#377)
Brute-force monitor: hitechcloudcli bruteforce shows fail2ban and its jails, switches jails on or off and sets their ban time, window and retries (kept across updates), lists and lifts bans (fail2ban and CSF), keeps a trusted list, rescues the operator's own address, groups failed sign-ins by address and by user (2083, 2087, SSH, FTP, mail and WordPress) and sends alerts. Each change must pass fail2ban-client --test or the previous file is put back, and loopback and the caller's own address cannot be removed from the trusted list. (hitechcloudcli#370)
IP allowlists (2087 > Security > IP Allowlist, Super Admin only, and /api/security/ip-allowlist): separate lists of addresses and ranges for administrators, resellers and hosting accounts, checked when a request arrives, before any password, session or token, and again for the signed-in role. A refused sign-in gets the wrong-password answer, every refusal is written to the activity log, and a save that would lock out the administrator making it is refused. The hosting-account list is enforced on 2083 by HiTechCloud-Panel#1659, whose Account > IP Allowlist strings are already translated. (hitechcloudadmin#255, hitechcloud-translations#29)

Commercial SSL certificates (S13)

The panel is neutral about who issues a certificate: nothing in it talks to a certificate authority. The signing request and its key are made on the server (RSA 2048, 3072 or 4096, or ECDSA P-256 or P-384; one name, several, or a wildcard) and the key never leaves it. 2083 SSL and 2087 SSL > Storage show each certificate's state, issuer, end date and days left, the request to paste into an order wherever the certificate is bought, and a Renew button (a new request for the same names with a new key). Installing takes the certificate and the authority's chain, and mail.<domain> is a target beside the account's domains. (hitechcloudcli#442, hitechcloudadmin#305, HiTechCloud-Panel#1727, hitechcloud-translations#61)
Stricter ssl upload: ssl upload, sslstore attach and the install pages share one check before anything is stored or installed. The certificate must match the key, cover every requested name (a wildcard only by a wildcard), be within its dates and have a chain in the right order with valid signatures that ends at a trusted root (a look-alike intermediate with the right name is caught); the key must be RSA of at least 2048 bits or ECDSA, with no SHA-1 or MD5 signature, and the certificate must be valid for TLS servers. A certificate that fails is refused with the reason. (hitechcloudcli#442)
Renewal reminders: a certificate installed by hand is watched, and a reminder goes out through the notification channels 30, 14, 7 and 1 day before it ends and on the day it expires. (hitechcloudcli#442)
Ordering a certificate from inside the panel is coming soon. Nothing for it was built in 4.1.2: no authority is contacted, nothing is ordered or paid for, and the request-and-install flow above is the supported way. (S13)

Kernel live patching (S14)

Status and the distribution's own mechanism: hitechcloudcli server-livepatch status|enable|disable|apply|rollback|watch and 2087 Server > Kernel live patching (Super Admin only) show the running kernel and build, whether it supports live patching, Secure Boot, lockdown and module-signature enforcement, the patch source of this distribution (RHEL's kpatch-patch packages, Ubuntu's Pro client where the owner attached Pro; AlmaLinux, Rocky, Debian and others say plainly that no patch source exists), the loaded patches and the CVEs they name, and a banner when a newer kernel is installed than the one running. Turn on, Apply, Turn off and Roll back ask for confirmation; a rollback of any loaded patch is bounded to 60 seconds; every action is refused while KernelCare or Ksplice is installed. A daily check alerts the administrators when a newer kernel is installed than the one running. (hitechcloudcli#441, hitechcloudadmin#304, HiTechCloud-Panel#1725)
The self-built signed patch pipeline: apply --bundle loads a patch bundle only after checking the ed25519 signature over its manifest against a trusted key, the module's SHA-256, kernel release, build ID and architecture, expiry and serial; it refuses every bundle until a key is trusted. The pipeline also has an offline producer tool, a signed-off review gate that an incomplete or changed review fails, a signed mirror index, and a fetch step that downloads only the entry for exactly this kernel build, checks every file and then runs the whole bundle check again. Patches are ephemeral (nothing reloads them at boot), nothing is fetched or applied on a schedule, and the 2087 page has no field that takes a path, URL or file. (hitechcloudcli#444, hitechcloudadmin#309, HiTechCloud-Panel#1729)
What is still the owner's, stated plainly: the module-signing keys, the build hosts that compile the patches, the per-CVE review and the publishing of the mirror are operational steps for the owner, and none of them exists yet. Until the owner makes and trusts a key, sets a mirror address (mirror set) and publishes patches, there is no HiTechCloud patch to apply, and Secure Boot servers also need the key enrolled. Nothing in S14 was run on a real kernel, build host, mirror or hardware token; see Not verified on live systems. The design and the owner's decisions are in docs-internal/kernel-livepatch-design.md, and the runbook is in the documentation in English and Vietnamese.

Backups, recovery and migration

Backups in 2083: an account makes on-demand backups with its own count, days and encryption choice (an account-held key is shown once and never kept on the server), locks and unlocks its own backups within the server's limits, browses a backup's files and restores or downloads chosen paths through a queue of restores and downloads, accepts the restore conditions before it restores, and restores or downloads by itself only the items the administrator allows (K28, set by default and per account in 2087). The server backup jobs' snapshots can be restored by the account, and FTP, cron, SSL or mail settings can be brought back on their own (user-restore --item). (hitechcloudcli#417, #414, #392, #402, #427, #379, hitechcloudadmin#272, #285, #293, HiTechCloud-Panel#1704, #1696, #1680, #1691, #1712, #1667)
2087 Backups: Backup jobs, Destinations, Runs and Restore points pages over backup-jobs, with destinations on SFTP, FTP(S), WebDAV, S3-compatible storage (AWS, Wasabi, B2, R2, Spaces, MinIO) and cloud storage through rclone (a remote's name only, no login kept), behind an address guard. Settings cover the user lock limits, how many restores and downloads run at once, the download lifetime and per-account limit, the restore conditions text and the log of what accounts accepted. (hitechcloudcli#385, #426, hitechcloudadmin#270, #272, #292)
Panel disaster recovery (K24): every backup run can write an encrypted bundle of the panel's own state, and 2087 Backups > Panel recovery and Recover this server (Super Admin only) turn it on, choose destinations, show the recovery key once, and recover a fresh install from a destination, keeping what it replaces in a panel-dr-before-<stamp>.tgz file. (hitechcloudcli#416, hitechcloudadmin#283, HiTechCloud-Panel#1703)
Clone jobs (K23): clone-jobs copies accounts on a schedule to a standby server, where they stay suspended until a failover; 2087 Backups > Clone jobs manages them. The standby's host key is pinned (see Upgrade notes). (hitechcloudcli#420, hitechcloudadmin#286)
Erasure of terminated accounts' backups (GDPR): backup-jobs gdpr deletes the backups of a terminated account after N days (off by default), and its orphaned archives; it never reaches a live, waiting or locked point, and a suspended account is not a terminated one. (hitechcloudcli#430, #435, hitechcloudadmin#285)
Migration: live migration of whole accounts from cPanel/WHM, Plesk or DirectAdmin, with many backup files at once, a queue with a concurrency limit, per-item status and retry, and post-migration checks of the restored account (site, DNS, mail login, PHP, report page) (G2, G4, G5); and Websites > Import a Site in 2083, which pulls a site from another host over SFTP, SSH, FTPS or FTP as one background job. (hitechcloudcli#390, #400, #407, #389, hitechcloudadmin#279, HiTechCloud-Panel#1673)
Backup jobs: hitechcloudcli backup-jobs runs many backup jobs, each with its own accounts (all, by package, by reseller or by name, with exclusions), type (full, incremental chains or components), schedule, compression, and retention (newest N, last N days, and GFS daily/weekly/monthly, with chains kept or dropped whole). Each job uploads to up to 8 destinations at once, each with its own retries and bandwidth limit, runs accounts in parallel, and can encrypt archives at rest (ChaCha20-Poly1305, root-only keys, key export). Runs leave restore points and send failure and success notifications or a webhook. (hitechcloudcli#376, building on #364)
Backup restore points: backup-jobs points lists the restore points of an account, a reseller or the server, newest first, with what each one holds; backup-jobs fetch writes one point as a single archive (an incremental point folded with its chain), checked against its recorded checksum and decrypted, after checking free space; backup-jobs restore restores a point to its account (or under a new name). backup-jobs lock|unlock keeps a point, and the points it depends on, from retention for N days, until a date or forever. (hitechcloudcli#381, #383)
user-backup options for backup jobs: --compress gzip|zstd (user-restore restores both), --include files,databases,mail,config, --exclude PATTERN, --listed-incremental FILE, --contents FILE (a JSON summary of what the archive holds), and --nice / --ionice-class / --ionice-level. An archive made without them is unchanged. (hitechcloudcli#364)

Websites and applications

Domain aliases (D7), in the panel: 2087 Domains > Domain aliases parks another domain on any account's website, and 2083 Domains > Domain Aliases does the same for the account's own sites; with the mail option, mail to the alias reaches the domain's mailboxes (see the CLI entry in this group). (hitechcloudadmin#300, HiTechCloud-Panel#1647)
Laravel (W5): 2083 PHP > Laravel manages a Laravel application's scheduler, queue worker, .env variables, maintenance mode and deploy; each account's worker has a unit of its own. .NET applications (W4): install and manage pages, the dotnet plan feature and an Autoinstaller card. (hitechcloudcli#432, #434, #438, hitechcloudadmin#299, hitechcloud-configuration#39, HiTechCloud-Panel#1709, #1714)
WordPress Toolkit: selective sync of some tables from staging, Smart Updates and a PHP version check on a hidden copy, one-click password protection of a site, and plugin and theme sets applied at install or to many sites (W13 to W18). (hitechcloudcli#394, #393, #395, #396, HiTechCloud-Panel#1686)
Domains > SEO shows what a crawler finds and writes robots.txt and sitemap.xml (W21); Websites > Folder Listing turns folder listing on or off per website (W25); FTP > Anonymous FTP shares read-only folders with anonymous visitors, and a folder holding a configuration file or key anywhere inside it is never shared (W30); Live Log Tail reads and follows a domain's web server logs, and a monthly statistics archive keeps each domain's report for 36 months (W23, W22). (hitechcloudcli#419, #428, #431, #436, #403, HiTechCloud-Panel#1700, #1707, #1708, #1688)
Event hooks for the panel's own actions (H5, H6, K20): a command can run before or after an action, a pre-hook can veto it (the reason is shown), and mailbox, database, database user, cron and backup download actions raise events; 2087 Settings > Event handlers tests them and keeps a run log. (hitechcloudcli#397, hitechcloudadmin#274, HiTechCloud-Panel#1690)
2083 Cron Jobs > Cron email: the account chooses where its cron jobs' output is mailed (an address, never, or the default mailbox). It becomes the MAILTO line of the panel's block in the crontab, is validated so it cannot add a crontab line, and each change is written to the activity log. (HiTechCloud-Panel#1639)
Domain aliases (parked domains): hitechcloudcli vhost alias add|remove|list makes one website answer for another name, with its www. name, DNS and certificate; with --mail, or hitechcloudcli mail alias-domain add|remove|list, mail to user@alias reaches user@domain, and addresses the domain does not have are still refused at SMTP. In 2083, Domains > Domain Aliases adds and removes them; a name that is already a domain on the panel, or that sits under another account's domain, is refused. (hitechcloudcli#367, #375, HiTechCloud-Panel#1647)

E-mail and DNS

Mailing lists with subscribe and unsubscribe, moderation, an archive and a digest (E2), and a certificate of its own for mail.<domain> on IMAP, POP3 and SMTP, chosen by SNI (E6), in 2083 Emails. (hitechcloudcli#408, #406, HiTechCloud-Panel#1698)
DNS cluster providers (D6): Amazon Route 53, DigitalOcean and PowerDNS beside Cloudflare, with the secret on stdin only. The legacy DNS slave's SSH host key is recorded on first use and a different key is refused (see Upgrade notes). (hitechcloudcli#411, hitechcloudadmin#278, #313)
Webmail: Vietnamese for the Chat, Documents and Files plugins (181 strings). (hitechcloudmail#88)

Server and platform

Nodes (C1 to C4): 2087 Server > Nodes shows the accounts placed on nodes with their usage, can suspend, unsuspend and delete them and collect usage now (joined to the quota report), sets the placement policy for new accounts with automatic placement, and Users lists the whole fleet with each account's node and a filter by server; a username is new to the whole fleet and a domain to the nodes its account is not on. Nodes pages are the Super Admin's. (hitechcloudcli#418, #422, #424, hitechcloudadmin#284, #289, #290, HiTechCloud-Panel#1713)
Remote database servers (B6): register, test and assign database servers per plan or account in 2087 Server > Database servers (Super Admin only), and 2083 reaches databases on a registered server; Server > Database upgrade runs a guided MariaDB major upgrade as one background task with a dump, a data directory copy and an automatic rollback. (hitechcloudcli#413, #384, hitechcloudadmin#282, #268, HiTechCloud-Panel#1693)
Monitoring and operations: uptime monitors probed from this server and from hosting nodes with alerts (T2); GET /metrics with the server's health for Prometheus behind a Bearer token (M10); and Server > Configuration files edits the host services' allow-listed files with their own check and puts the old file back on refusal (Super Admin only). (hitechcloudcli#410, hitechcloudadmin#269, #260, #287)
hitechcloudcli objectcache loopback, run by every update: a Redis or Valkey instance that listens beyond loopback and accepts clients without a password is bound to 127.0.0.1 and ::1 (configuration and running server, no restart, old file kept beside it). An instance that asks for a password is reported and left alone. On the stock packages and this stack's own instances, which already bind loopback, it changes nothing. objectcache status now says, per engine, whether it listens on loopback only or beyond (read by the unit's own process).
Customer portals are on by default: every hosting account can sign in to the Mail, DNS and S3 portals, and every mail-only account to the Mail portal. Install and update start all three and open ports 2091-2093 unless a portal is switched off (<portal>_portal = off), which no update overrides.
New portal layout: a left sidebar with each portal's sections (collapsible to icons, a drawer on phones), breadcrumbs, and the account menu with language, theme and sign out, in Mail, DNS and S3.
Single sign-on into the portals: "Customer portals" buttons on the 2083 dashboard, Mail/DNS/S3 portal buttons beside "Log in as" in 2087 and the reseller panel (also for mail service accounts), and "Sign in with your hosting panel" on each portal's sign-in page. The single-use links never appear in server logs.
New hitechcloudcli objectcache panel-login: checks and repairs the panel's own cache login. The installer and every update run it, and it moves a panel that was put on 127.0.0.1:6380 as a workaround back to the Valkey socket. objectcache status now shows whether the panel's login works.
New hitechcloudcli objectcache reset-admin <redis|valkey> --yes: sets a new administrator password on a Redis or Valkey instance when no recorded password opens it. Each account's own login is kept.
OpenLiteSpeed and LiteSpeed Enterprise WebAdmin console (port 7080): hitechcloudcli litespeed console status|open|close|password. open serves the console over TLS with the panel's certificate, applies LiteSpeed's access list and opens 7080 in the firewall; close binds it back to loopback; password --password-stdin sets the console login. An open console stays open across configuration rewrites and firewall ports.
OS updates: hitechcloudcli server-updates list|apply [--security]|auto on|off|status lists and installs the operating system's package updates (apt or dnf), switches automatic security updates on or off, reports whether a reboot is needed, and logs each run under /var/log/hitechcloud/updates/. (hitechcloudcli#369)

Languages, portals and apps

Eight more languages, complete for the live set of messages (Polish still has about 28 legacy catalogue entries in English): Japanese, Korean, Italian, Dutch, Polish, Indonesian, Thai and Arabic (ja, ko, it, nl, pl, id, th, ar) in 2083 and 2087, with native names and flags in the language pickers and Arabic laid out right to left (X3); the 2087 account page shows each language's own flag and the front-end's 502/504 page is in all of them. They are machine translations: review them before relying on them. (hitechcloud-translations#48, #54, #56, #59, #63, hitechcloudadmin#288, #298, #312, #314, HiTechCloud-Panel#1706, #1715, #1736)
Every 2083 string goes through the catalogue and a live string without Vietnamese fails CI; the Vietnamese documentation now covers the whole site (hundreds of pages, including the AI assistant, API, meetings, webmail, backups and this changelog), and CI fails when an English page has no Vietnamese twin or the pair differs in structure. (HiTechCloud-Panel#1649, #1641, #1643, #1648, #1654, #1658, #1664, #1672, #1677, #1695)
Customer portals: a translated not-found and error page in every app and a loading state in DNS; the DNS portal keeps what was typed after a refused change, asks before deleting managed records, shows errors in the page's language and moves focus to the change; the S3 portal shows errors and form checks in the page's language, offers Try again for lists and is tested at 320 px. (HiTechCloud-Panel#1719, #1723, #1724)
Mobile apps and integrations, for reference only: the mobile apps (HiTechCloud Panel for hosting accounts and administrators, and HiTechCloud Mail) and the WHMCS module are versioned and released from their own repositories (hitechcloud-panel-app, hitechcloud-mail-app, hitechcloud-panel-whmcs-module), not with this release. Their changes on main since the last published app release (access-key sign-in, precise sign-in refusals, a Backups schedule tab, sender addresses and forwarding, the WHMCS reseller product type, plan add-ons and Test Connection) are described there, and this release points at the current WHMCS module.

Security

Sentinel: alert e-mails no longer expose the admin mailer's one-time code or the admin basic-auth login to other local accounts.
Search engine (OpenSearch/Elasticsearch): the superuser login and account passwords are no longer visible to other local accounts while users are created or removed.
Toolkit inventory: the Joomla extension check now connects only to this server's own database, with local-file loading turned off, and no longer puts the database password on the command line.
Front-end: the default server no longer serves a suspended site's page, with its administrator message, to anyone who asks for it by name.
Backup chains: restoring a chain no longer follows a symbolic link carried in the archive's mail directory. The archives sit in the account's web root, so a crafted link could have copied another account's mail into this account's mailboxes.
Critical: restoring from 2083's Backup Schedule (user-backupset --restore) unpacked the account's own, editable archives into its home as root. With GNU tar 1.34 (Ubuntu 22.04, RHEL family) a hosting account could replace a directory with a link and have root write any file on the server. The same restore read archive members and restic files through the account's links (another account's files, dumps and mail) and copied linked metadata as root. Members are now unpacked by a tar running as the account, every member is opened by root without following links, every link in the staged metadata is dropped first, and a zone with $INCLUDE is refused. (hitechcloudcli#359)
Suspended accounts were found with a LIKE pattern that also matched other accounts: user-unsuspend alice could rename a suspended malice or bob_alice to alice (handing over its login and domains), user-delete alice could delete a suspended malice, and user-restore of a suspended account's archive brought it back as a second, unsuspended login. The suspended row is now matched exactly, and user-restore refuses to restore over a suspended account. (hitechcloudcli#361)
user-restore runs as root on an archive the account can edit: a link outside the home in the archive (for example ftp/users.list -> /etc/passwd) had root read and rewrite its target, FTP folders were created by root through the account's links, and with --force the archive chose the account's plan and owner. Links outside the home are dropped right after extraction, FTP folders are made by the account, and an account that is already on the server keeps its plan and owner. (hitechcloudcli#362)
A suspended account could still sign in over FTP and upload or download its site: user-suspend now locks the account's FTP logins and its Linux password, and user-unsuspend unlocks exactly what the suspension locked. (hitechcloudcli#363)
2083 Backups > Restore & Download wrote into the account's home as root after checking each directory for a link, so a link swapped in between was followed as root. Files are now written with the owner's filesystem identity, and a DNS zone with $INCLUDE is refused. (HiTechCloud-Panel#1638)
Sign-in for a name with no row matched suspended rows by suffix: a suspended alice could be checked against a suspended malice's password hash, and any suffix of a suspended account's name could be used to test its password. Only the account's own suspended row is used now. (HiTechCloud-Panel#1640)
Critical: user-restore copied the panel row's context (the system user and home the account's panel session works on) from the archive's user.sql, which sits in the account's web root: an account could name another account there and, once an administrator restored its backup, its panel login worked on the other account's files. The context is now always the one the restore made. (hitechcloudcli#374)
HiTechAdmin (2087) found a suspended account's row with a LIKE pattern that also matched other accounts (bob_alice or malice for alice), so an administrator's action on one account could read or act on another's row, and suspended names were shown cut at the last _. The exact rule from hitechcloudcli#361 is used everywhere now. (hitechcloudadmin#249)
HiTechAdmin (2087) took the client's address from the leftmost X-Forwarded-For entry, which the client writes, or from any CF-Connecting-IP, so a request through the panel's proxy could choose the address that rate limits and session pinning used. The client is now the nearest hop past the trusted proxies, read from the right, and CF-Connecting-IP is believed only from Cloudflare's addresses. (hitechcloudadmin#255)
Migrations reach a remote host only with a host key a person confirmed (a changed key is refused, naming both fingerprints), with credentials that live on tmpfs for the job only and are kept out of logs, and with a tar stream that lets through only regular files and folders, unpacked by the account's own tar. This is the shared core for the 2083 site import and the 2087 live migration. (hitechcloudcli#371)
Security and correctness audit of the features merged after 2026-10-16 (docs-internal/security-audit-4.1.2.md has the 21-row findings table, the paths that were traced and what was reviewed without a finding). 13 findings were fixed, 3 were deferred by the owner (see Known limitations), 4 were accepted with reasons, and 1 (the panel half of the .NET page) was not yet on main when the review ran. The features that landed after that review (the account switcher, database copy, commercial SSL, kernel live patching, the panel half of the .NET page, the 2083 audit views and the portal changes) were not covered by it; the QA read of the switcher handler and the copy planner found one more issue, in database copy (below).
Nodes and root-equivalent pages are the Super Admin's alone: a delegated administrator could enrol a node (which sends the node the panel database's host, user and password), name the machine a new account is created on (POST /user/new took the hidden slave and ssh_key_path fields and ran scp -r /etc/hitechcloud to that address), edit root's SSH keys and sshd_config, the host services' configuration files and root's cron, and migrate the server or transfer an account to a host of its choice. Every one of those pages and its API route is now Super Admin only. (hitechcloudadmin#307, #311)
Host-key pinning with accept-new for nodes, git hosts, SFTP destinations, clone and migration standbys, the default-node probe and the legacy DNS slave: they went to the remote machine with host-key checking off, so a machine that answered as the standby could receive every account's files, database rows and password hashes. A changed key is now refused (behaviour change, see Upgrade notes). (hitechcloudcli#443, #445, hitechcloudadmin#311, #313)
High: POST /api/ (the API token login) never asked an administrator's second factor, so an administrator with 2FA on got a token for every /api/* admin route on the password alone. It now asks for the authenticator's code (see Upgrade notes). Reported by the mobile-apps audit. (hitechcloudadmin#308)
phpMyAdmin and pgAdmin by role: the panel's own database login is refused to every role but the Super Admin (a delegated administrator reached it before), and other roles get phpMyAdmin per account with that account's own login, or pgAdmin under an identity of its own with no saved server, only once the Super Admin grants it on Server > Databases. (hitechcloudadmin#313)
High: erasing the backups of "terminated" accounts also deleted the backups of suspended accounts (a suspended account's row is SUSPENDED_<stamp>_<name>, which looked like an account that was gone), irreversibly, after gdpr_delete_after_days. It is now measured against every account the panel database still holds, and an empty or failed list deletes nothing. (hitechcloudcli#435)
Lower-severity audit fixes: anonymous FTP checks five levels of a shared folder for configuration files and keys, not only the top (hitechcloudcli#436); the key of an on-demand backup does not stay on the server after a run that was killed or never started (#437); two accounts can no longer share one Laravel queue worker unit through look-alike names (#438); a clone job whose standby is this server is refused (#443).
High: database copy (B5): account db-copy and customers db-copy loaded the dump of the source database into the target as root, so an account that controlled object names, comments or DEFINER clauses in its own database could make the dump run statements as root (a GRANT, a client \! command, a trigger run by root). The dump is now taken with the source account's own login, read for anything a dump of one database does not hold (USE, CREATE DATABASE, GRANT, CREATE USER, SET GLOBAL, names in another database, a DEFINER of another login, client commands, settings that make the client and the server read the text differently), and loaded with the target account's own login as that account, without --force; root only creates the empty database and grants it. Found by the QA read of the copy planner, not by the audit. (hitechcloudcli#447)
Dependencies: the zip library is upgraded to version 9 for RUSTSEC-2026-0367 and RUSTSEC-2026-0368 (HiTechCloud-Panel#1697), and Sentinel passes the alert e-mail request to curl on stdin instead of on its command line (sentinel#7).

Documentation

New Customer portals page: the Mail (2091), DNS (2092) and S3 (2093) portals, who can sign in, that they are on by default, single sign-on from 2083, from HiTechAdmin and from each portal's sign-in page, and their hostnames, ports and limits.
New Troubleshooting page: sent back to the sign-in page ("Your session could not be saved", objectcache panel-login and reset-admin), ClamAV signatures, the firewall left off, SQL Server on EL10, background tasks that will not start again, WireGuard NAT, and search on AlmaLinux 10.
System requirements, Install and Manual update rewritten for 4.1.2: AlmaLinux and RHEL 10 notes, ports, and the firewall installed switched off.
CLI reference pages for portals, objectcache, firewall and module, updated license and update pages, the editions page, Securing HiTechCloud and where HiTechCloud stores its logs, all in English and Vietnamese (#1626, #1636). The Vietnamese pages the configuration files page links to are added, and this changelog is in Vietnamese too (#1657).
New and updated pages: Several accounts, one sign-in (customers and the switcher), the kernel live patching runbook (English and Vietnamese), phpMyAdmin and pgAdmin by role and the DNS slave host-key pin, the customer portals page as the portals now are (sidebar layout, single sign-on, open access), and the Vietnamese pages for the whole documentation. (HiTechCloud-Panel#1722, #1729, #1732, #1735)

Known limitations

Redis and Valkey are still shared by every hosting account on a server that has accounts: objectcache status keeps saying SHARED AND UNAUTHENTICATED (loopback only, so it is the accounts on the machine, not the network, that can read each other's cached data). Per-account isolation (objectcache secure <engine> --yes) is applied automatically only on a server with no accounts, because turning it on stops every client that connects without a password: the panel's own WordPress Redis setup writes none, and rspamd greylisting's redis.conf carries none. Wiring those consumers to per-account logins is planned for a later release.
PHP 8.0 shown as installed on an AlmaLinux 10 server whose installer log lists no 8.0 was not root-caused (phpversions list counts any /etc/opt/remi/phpNN/php-fpm.conf). PHP versions asked for from the App Store before the PHP repository is configured cannot be checked against it; the install skips what the repository does not carry.
The libsepol.context_from_record: type l2tpd_var_run_t is not defined message during the base package step (container-selinux) and rpm's group screen/opendkim does not exist - using root are the operating system's own output and are harmless.
Not verified on a live server: the single restart per update, objectcache loopback against an exposed instance, the el10 MSSQL, ClamAV, FTP, WireGuard and search paths. WireGuard's NAT rule needs the netfilter modules of the running kernel: after an update that installed a newer kernel, reboot.
The chain that installed a newer kernel than the running one (fail2ban bundle, firewalld, kernel-modules-extra) could not be confirmed from the code; the bundle is no longer installed.
objectcache loopback, run by every update, closes Redis and Valkey to loopback when they accept clients without a password: operators whose remote application servers reached the cache without a password must re-open it deliberately.
The mail service sign-in-as via the old autologin link is replaced by /login_portal (this removes it from the 4.1.0 limitations list).
Not verified on a live server: portal bring-up on a fresh install or update, the firewall ports 2091-2093, the single sign-on round trip and SameSite=Strict across different site hostnames.
The Databases page of 2087 itself (process list, kill, limits) is still visible to a delegated administrator; only phpMyAdmin, pgAdmin and the panel's own database login are gated by role. (hitechcloudadmin#313)
Three audit findings were deferred by the owner and remain open: the team member's domain scope is a text search on domain-bearing parameters, not a boundary (the member's role is the boundary); an API token can create tokens with no expiry, address list or scope; and user-rename does not move the backup index, so with gdpr_delete_after_days turned on (it is off by default) the backups made under a renamed account's old name count as a terminated account's. The other findings were accepted with reasons, which docs-internal/security-audit-4.1.2.md gives.
Ordering SSL certificates from inside the panel is not available (coming soon); only the request-and-install flow exists. Kernel live patching has no HiTechCloud patch to apply until the owner has made and trusted a signing key, set up build hosts and published a mirror.
Database copy (B5) refuses a database whose dump holds an object defined by another login than the source account's own (for example a routine of <account>_wp), and does not copy MariaDB sequences; both accounts need their own login in ~/my.cnf, as phpMyAdmin's sign-on and the backups already do.
The eight new languages are machine translations that no native speaker has reviewed, and the mobile apps are not released with this version.

Not verified on live systems

Everything in this release was verified by unit tests, by CI, and by browser tests against fixtures. No live server, real kernel, real certificate authority, authenticator app, identity provider, directory server or mobile device was used, and nothing was run on a production system.
Kernel live patching (S14): nothing was run on a real kernel. The status, rollback and distribution-mechanism paths were tested against fixtures of /sys/kernel/livepatch, /proc and the documented output of rpm, dnf, kpatch, pro and canonical-livepatch; the signed-bundle, review-gate and mirror paths were tested with throwaway keys and a fake mirror. The signing keys, the build hosts and the publishing of the mirror are the owner's operational steps and have not been done.
Commercial SSL (S13): checked against fixture certificate chains only, never against a real authority; ordering was not built.
Security fixes: the behaviour of the host-key pins with a real changed key (a standby, node, git host, SFTP destination or DNS slave), the 2087 sidebar, tabs and read-only cron editor as a delegated administrator, the 2FA token login with a real authenticator code, phpMyAdmin's sign-on with an account's own login, the grant form, and pgAdmin under a granted role's identity are unverified on a running machine. The OpenID Connect and directory sign-in were tested against stand-ins, not a real provider or directory.
Backups, clone jobs, nodes, migration and DNS: the S3, SFTP, FTP(S), WebDAV and rclone destinations, clone jobs and nodes with a second server, live migration from cPanel, Plesk and DirectAdmin, and the Route 53, DigitalOcean and PowerDNS providers were exercised with fixtures and fakes, not against the real services or a second machine.
Database copy (B5): the dump, the reader that refuses a crafted dump and the load with the target account's own login were verified by unit tests (a real mariadb-dump 10.11 fixture and hostile dump fixtures), and the reader's output was loaded into a scratch MariaDB 10.11 server with the other account's login. The command itself - system users, runuser, each account's ~/my.cnf, a real panel database - was not run on a server.
Unchanged from the first 4.1.2 notes: the single restart per update, objectcache loopback against an exposed instance, the AlmaLinux 10 MSSQL, ClamAV, FTP, WireGuard and search paths, portal bring-up on a fresh install or update, the single sign-on round trip, and the suspension, backup-restore and LiteSpeed console changes.