4.0.9

Added​

• Services diagnostics: hitechcloudcli enterprise ftp troubleshoot|repair, litespeed troubleshoot|repair, varnish troubleshoot and service troubleshoot <ftp|varnish|litespeed> print the unit's state, its Requires= units, the journal and the next step. hitechcloudcli webmail troubleshoot and webmail repair do the same for the webmail (Node, unit, environment keys, database login, Redis or Valkey reachability).

Changed​

• Redis and Valkey are two independent servers that run side by side on different ports on every operating system, including AlmaLinux and RHEL 10, where Redis is a second server built from the Valkey binary with its own unit, configuration and data. A running Valkey is never moved or restarted. objectcache status and the App Store say which one answers on which port, and the webmail, the panel installer and rspamd greylisting ask the running cache for its port instead of assuming 6379.
• App Store: the cards say what is true. Each module card shows why it is not running, with a Start button that runs the repair and reports its real exit code; Varnish and OpenLiteSpeed's stock lshttpd are kept off on purpose (each account runs its own Varnish; OpenLiteSpeed is served by hitechcloud-openlitespeed) and no longer show as broken; the job result label names what ran.

Fixed​

• hitechcloudcli update and update --repair repair what 4.0.8 left behind: an enabled but stopped pure-ftpd is started, ClamAV is prepared (socket settings, runtime directory, reset-failed, start) where it is installed and clamd does not run, and a webmail whose REDIS_URL names a port nothing answers on has its environment regenerated from the running cache and is restarted until /api/health answers.
• pure-ftpd, Varnish and LiteSpeed: the real causes are fixed. Module install and repair no longer unmask and start units this stack keeps masked, fail with a non-zero exit code when a unit does not come up, and limits apply-all reloads systemd once instead of once per account.