4.0.9

Added​

• Chẩn đoán dịch vụ: hitechcloudcli enterprise ftp troubleshoot|repair, litespeed troubleshoot|repair, varnish troubleshoot và service troubleshoot <ftp|varnish|litespeed> in ra trạng thái của unit, các unit Requires= của nó, journal và bước tiếp theo. hitechcloudcli webmail troubleshoot và webmail repair làm điều tương tự cho webmail (Node, unit, khoá môi trường, đăng nhập cơ sở dữ liệu, khả năng tiếp cận Redis hoặc Valkey).

Changed​

• Redis và Valkey là hai máy chủ độc lập chạy song song trên các cổng khác nhau trên mọi hệ điều hành, kể cả AlmaLinux và RHEL 10, nơi Redis là một máy chủ thứ hai được dựng từ tệp nhị phân Valkey với unit, cấu hình và dữ liệu riêng. Một Valkey đang chạy không bao giờ bị di chuyển hay khởi động lại. objectcache status và App Store nói cái nào trả lời trên cổng nào, và webmail, trình cài đặt panel và greylisting của rspamd hỏi cache đang chạy về cổng của nó thay vì giả định 6379.
• App Store: các thẻ nói điều đúng sự thật. Mỗi thẻ mô-đun hiển thị lý do nó không chạy, với một nút Start chạy bản sửa chữa và báo mã thoát thật của nó; lshttpd mặc định của Varnish và OpenLiteSpeed được cố ý giữ tắt (mỗi tài khoản chạy Varnish riêng; OpenLiteSpeed được phục vụ bởi hitechcloud-openlitespeed) và không còn hiển thị là hỏng; nhãn kết quả tác vụ nêu tên thứ đã chạy.

Fixed​

• hitechcloudcli update và update --repair sửa chữa những gì 4.0.8 để lại: một pure-ftpd đã bật nhưng đang dừng được khởi động, ClamAV được chuẩn bị (cài đặt socket, thư mục runtime, reset-failed, start) nơi nó được cài và clamd không chạy, và một webmail có REDIS_URL nêu một cổng mà không gì trả lời sẽ được tạo lại môi trường từ cache đang chạy và khởi động lại cho đến khi /api/health trả lời.
• pure-ftpd, Varnish và LiteSpeed: các nguyên nhân thực sự đã được sửa. Cài đặt và sửa chữa mô-đun không còn unmask và khởi động các unit mà stack này giữ bị mask, thất bại với mã thoát khác không khi một unit không lên, và limits apply-all nạp lại systemd một lần thay vì một lần mỗi tài khoản.