4.1.3

4.1.3 là bản vá nóng cho 4.1.2. Bản này chỉ gồm bốn bản sửa lỗi về thư và đăng nhập dưới đây cùng phần gia cố bộ nhớ đệm đi kèm.

Ghi chú nâng cấp và thay đổi hành vi​

• Không cần thao tác thủ công. Bản cập nhật lên 4.1.3 tự sửa máy chủ bị ảnh hưởng: nó ghi lại thông tin đăng nhập bộ nhớ đệm của panel và trao cho webmail chứng chỉ thư của chính máy chủ này. Không cần chạy lệnh nào bằng tay, cả trước lẫn sau khi cập nhật.
• Lỗi chứng chỉ không còn bị báo là sai mật khẩu. Khi webmail không xác minh được chứng chỉ của máy chủ thư, trang đăng nhập của nó nói rõ điều đó, và POST /api/auth/login trả về 502 kèm code: mail_tls_untrusted thay vì 401 "Invalid credentials". Sai mật khẩu vẫn là "Invalid credentials". Các script coi mọi lần đăng nhập webmail thất bại là 401 cần xử lý thêm mã 502. (hitechcloudmail#89)
• Một số tên tài khoản nay bị từ chối (thay đổi hành vi). Tài khoản hosting không còn được đặt tên trùng với tiền tố khoá của bộ nhớ đệm dùng chung: sess, rl, oidc_bcl_jti, panel_sso_nonce, totp_used, send_idem, bimi, sender-favicon, session, tokens_valid_after, email_import, lockout, mailticket, mcp, ticket, hitechcloud-webmail, hitechcloud_cache_* và op_*. Tài khoản hiện có mang một trong các tên này mất thông tin đăng nhập bộ nhớ đệm khi cập nhật và bị đánh dấu là đáng ngờ; tài khoản không bị đổi tên. Hãy coi tài khoản như vậy là đáng ngờ và kiểm tra nó. (hitechcloudcli#459)

Đã sửa​

• Đăng nhập 2083 thất bại trên bản cài mới khi người dùng default của Redis không có mật khẩu. Gặp trên Ubuntu 22.04 với Redis 6, kết nối qua unix socket. Mọi lần đăng nhập đều dừng ở thông báo "Không thể lưu phiên đăng nhập" (tiếng Anh: "Your session could not be saved"), nên không làm được gì trong 2083: không tạo được hộp thư và đăng nhập một lần vào webmail không hoạt động. Redis 6 từ chối AUTH <password> khi default không có mật khẩu, nhưng bước kiểm tra thông tin đăng nhập bộ nhớ đệm của panel trong CLI dùng redis-cli, vốn in ra lời từ chối đó rồi vẫn trả lời PONG. Vì vậy hitechcloudcli objectcache status báo đăng nhập hoạt động, và bản cài giữ lại một mật khẩu mà panel không dùng được. Bước kiểm tra nay đăng nhập đúng như panel (không gửi AUTH khi không có mật khẩu, AUTH <password> cho người dùng default, AUTH <user> <password> cho người dùng khác, rồi PING) và lấy lỗi đầu tiên làm câu trả lời. Mỗi lần cập nhật đều ghi lại thông tin đăng nhập bộ nhớ đệm bằng bước kiểm tra này, nên máy chủ bị ảnh hưởng tự hết lỗi khi cập nhật lên 4.1.3. (hitechcloudcli#448)
• Đăng nhập webmail và đăng nhập một lần vào webmail thất bại khi chứng chỉ thư là tự ký hoặc do CA nội bộ cấp. Đây là điều trình cài đặt để lại khi tên máy không có DNS công khai. IMAP vẫn hoạt động, nhưng webmail chỉ kiểm tra máy chủ thư theo các tổ chức cấp chứng chỉ công khai, nên mọi lần đăng nhập đều hiện "Invalid credentials" và việc chuyển từ 2083 và 2087 sang webmail quay về trang đăng nhập của webmail. webmail.log ghi self-signed certificate. CLI nay trao cho webmail đúng chứng chỉ mà Dovecot và Postfix của máy chủ này trình ra (mail_tls_cert, chỉ chứng chỉ công khai, không bao giờ có khoá), và ghi lại sau mỗi lần cấp và gia hạn chứng chỉ. Webmail tin chứng chỉ đó, đối chiếu theo dấu vân tay SHA-256, chỉ cho máy chủ thư của chính máy này, khi đăng nhập, khi panel chuyển sang, khi đồng bộ IMAP và khi gửi thư. Mọi máy chủ thư khác vẫn được xác minh đầy đủ, và việc xác minh không bao giờ bị tắt. Chứng chỉ vẫn không xác minh được thì được báo là lỗi chứng chỉ, và nhật ký nêu lệnh làm mới nó, hitechcloudcli webmail mail-login. (hitechcloudcli#449, hitechcloudmail#89)
• Đăng nhập webmail và đăng nhập một lần vào webmail thất bại trên Debian 12 và AlmaLinux 9. Trình cài đặt đặt mật khẩu cho bộ nhớ đệm của panel (Redis hoặc Valkey) trước khi webmail được cài, rồi webmail được thiết lập với REDIS_URL không kèm thông tin đăng nhập. Bộ nhớ đệm từ chối webmail với NOAUTH: mọi lần đăng nhập webmail kết thúc bằng "Login failed" và mọi lần chuyển từ 2083 và 2087 sang webmail quay về trang đăng nhập của webmail, trên bản cài mới và sau mỗi lần cập nhật. Webmail nay đăng nhập vào bộ nhớ đệm bằng thông tin đăng nhập riêng của nó (xem phần Bảo mật), và webmail update, lệnh mà mọi lần cập nhật đều chạy, ghi lại REDIS_URL nào bị bộ nhớ đệm từ chối. Máy chủ bị ảnh hưởng tự hết lỗi khi cập nhật lên 4.1.3. (hitechcloudcli#459)
• Mở webmail từ 2083 thất bại với thông báo "Create it first" cho hộp thư tạo bên ngoài panel. Hộp thư tạo bằng CLI (hoặc trong 2087, hoặc do khôi phục) sau khi 2083 đã lưu đệm danh sách hộp thư của tài khoản bị từ chối trong tối đa một giờ. 2083 nay gắn danh sách đó với danh sách tài khoản của chính máy chủ thư, /etc/hitechcloud/mail/postfix-accounts.cf, tệp mà mọi cách tạo hoặc xóa hộp thư đều ghi, nên hộp thư mới được nhận ra ngay. Địa chỉ không phải hộp thư vẫn bị từ chối từ bộ nhớ đệm, không nhập lại danh sách ở mỗi yêu cầu. (HiTechCloud-Panel#1748)

Bảo mật​

• Webmail có người dùng bộ nhớ đệm riêng với quyền tối thiểu, hitechcloud-webmail, và không bao giờ được trao thông tin đăng nhập quản trị của bộ nhớ đệm. Người dùng này không chạy được SCAN, KEYS hay các lệnh publish/subscribe và không có quyền quản trị. Bản cập nhật thay thế thông tin đăng nhập quản trị nếu tìm thấy trong webmail.env của webmail. (hitechcloudcli#459)
• Tên tài khoản trùng với tiền tố khoá của bộ nhớ đệm dùng chung bị từ chối, để thông tin đăng nhập bộ nhớ đệm của một tài khoản hosting không bao giờ chạm tới khoá của panel hay của webmail. Tài khoản hiện có mang tên như vậy mất thông tin đăng nhập bộ nhớ đệm khi cập nhật và bị đánh dấu là đáng ngờ (xem Ghi chú nâng cấp). (hitechcloudcli#459)

Đã kiểm chứng​

• Các bản sửa được thử trong một lần chạy CI trên 10 máy ảo kiểm thử, không phải máy chủ của khách hàng: Debian 12 (ba máy), AlmaLinux 9 (ba máy) và Ubuntu 22.04 và 24.04, gồm bản cài mới và máy chủ nâng cấp từ 4.1.1 lên 4.1.2, với cả chứng chỉ thư được tin cậy công khai lẫn chứng chỉ tự ký. Các máy chạy đúng mã nguồn của bản phát hành này.
• Trên mọi máy, trình cập nhật áp dụng các bản sửa lên 4.1.2 mà không cần thao tác thủ công, và mọi mục sau đều đạt trên cả mười máy: đăng nhập 2083; tạo hộp thư trong 2083 và bằng CLI; đăng nhập webmail bằng mật khẩu, đăng nhập webmail hai lớp và đăng nhập một lần vào webmail từ 2083; người dùng bộ nhớ đệm của webmail bị từ chối mọi thứ ngoài các khoá của chính nó, kể cả publish/subscribe trên Redis 6.0; và các tên tài khoản dành riêng.
• Có hai điều không kiểm chứng được trong các container thử nghiệm. Gửi thư từ webmail: tên máy chủ thư của container phân giải ra địa chỉ riêng, mà bộ chặn kết nối ra ngoài của webmail từ chối, giống hệt 4.1.2 (xem Hạn chế đã biết). Đăng nhập IMAP trên AlmaLinux 9: curl của container không hỗ trợ IMAPS, nên bước kiểm tra thất bại cả trước lẫn sau khi cập nhật. Đăng nhập IMAP đạt trên các máy Debian và Ubuntu.

Hạn chế đã biết​

• Một lần cập nhật bị gián đoạn có thể được ghi nhận là hoàn tất trước khi các dịch vụ được khởi động lại. Bản sửa có trong 4.1.4.
• Trên máy chủ đã bảo mật bộ nhớ đệm, việc đăng xuất các phiên webmail khác của hộp thư sau khi đổi hoặc đặt lại mật khẩu, và đăng xuất back-channel OpenID Connect, chưa có hiệu lực ở 4.1.3: các phiên đang mở tồn tại đến khi hết hạn (tối đa bằng thời hạn phiên). 4.1.4 khôi phục cả hai.
• Hộp thư được tạo trong 2083 khi việc đăng nhập hoặc tạo hộp thư đang lỗi trên 4.1.2 có thể chưa bao giờ được tạo đầy đủ: mật khẩu của nó bị từ chối qua IMAP và việc mở webmail từ 2083 quay về danh sách hộp thư. Bản cập nhật không sửa hộp thư như vậy. Hãy đặt lại mật khẩu của nó trong 2083, hoặc xoá rồi tạo lại. Hộp thư tạo sau khi cập nhật hoạt động bình thường.
• Trên máy chủ có tên máy phân giải ra địa chỉ riêng (ví dụ sau NAT), việc gửi thư từ webmail bị bộ chặn kết nối ra ngoài từ chối, như ở 4.1.2. 4.1.4 miễn trừ máy chủ thư của chính máy này (hitechcloudmail#91).
• Các thao tác WordPress trong 2083 (ví dụ bật hoặc tắt bộ nhớ đệm đối tượng Redis) thất bại với lỗi 500 Could not open input file: /etc/hitechcloud/wordpress/wp-cli.phar sau khi máy chủ đã chạy cập nhật hoặc sửa chữa. Lỗi này có từ 4.0.4, khi các bản cập nhật bắt đầu giới hạn quyền truy cập /etc/hitechcloud; bản thân các website vẫn hoạt động bình thường. Cách khắc phục tạm thời, với quyền root, nếu /usr/local/bin/wp tồn tại: mv /etc/hitechcloud/wordpress/wp-cli.phar /etc/hitechcloud/wordpress/wp-cli.phar.stock-disabled. Đã sửa trong 4.1.4 (hitechcloudcli#470, HiTechCloud-Panel#1772).