Bộ nhớ đệm đối tượng (Redis và Valkey)
hitechcloudcli objectcache quản lý thông tin đăng nhập theo từng tài khoản cho
các instance Redis và Valkey dùng chung: bộ nhớ đệm mà WordPress và các ứng dụng
khác dùng, và cũng là nơi panel lưu phiên đăng nhập của chính nó. Tên cũ của
lệnh là hitechcloudcli native-cache.
hitechcloudcli objectcache status
Mỗi engine bộ nhớ đệm đang làm gì trên máy chủ này: có đang chạy không, chỉ lắng nghe trên loopback hay rộng hơn, và các tài khoản có được cách ly với nhau không.
Từ bản 4.1.2 status có thêm dòng panel cho biết thông tin đăng nhập bộ nhớ
đệm của chính panel có dùng được không.
Thông tin đăng nhập bộ nhớ đệm của panel
Panel lưu phiên đăng nhập trong bộ nhớ đệm. Nếu bộ nhớ đệm từ chối thông tin đăng nhập của panel, không ai đăng nhập được vào 2083, các cổng khách hàng hay qua liên kết đăng nhập một lần: trình duyệt bị đưa về trang đăng nhập.
hitechcloudcli objectcache panel-login [--no-restart]
hitechcloudcli objectcache reset-admin <redis|valkey> --yes
panel-logingiữ nguyên thông tin đăng nhập đang dùng được. Nếu không, nó ghi, trong một bước, thông tin đăng nhập đầu tiên trong hồ sơ mà bộ nhớ đệm của panel chấp nhận, rồi khởi động lại panel một lần (--no-restartđể bạn tự khởi động lại). Trình cài đặt và mỗi lần cập nhật chạy lệnh này với--no-restart.reset-admindùng khi không có thông tin đăng nhập nào trong hồ sơ mở được instance. Nó đặt mật khẩu quản trị mới trong tệp ACL của instance, giữ thông tin đăng nhập của mọi tài khoản và khởi động lại instance một lần. Thông tin đăng nhập của panel được cập nhật theo khi đó là bộ nhớ đệm của panel.
Hai lệnh này có từ bản 4.1.2. Chúng được kiểm tra trong mã nguồn và unit test, chưa trên máy chủ thật, cho trang này.
Cách ly theo từng tài khoản
Khi bật cách ly, mỗi tài khoản hosting có thông tin đăng nhập bộ nhớ đệm và
không gian khoá riêng, được ghi vào ~/cache.cnf, và instance từ chối các máy
khách không xác thực.
hitechcloudcli objectcache secure [redis|valkey|all] [--yes]
hitechcloudcli objectcache adduser <username> [--engine <name>]
hitechcloudcli objectcache deluser <username>
hitechcloudcli objectcache password <username>
hitechcloudcli objectcache show <username>
securecấp thông tin đăng nhập cho mọi tài khoản hiện có trước, rồi đóng instance với các máy khách không xác thực.secure ... --if-freshchỉ tác động lên máy chủ chưa có tài khoản hosting nào. Trình cài đặt chạy lệnh này, nên máy chủ mới được cách ly ngay từ đầu và máy chủ đang dùng không bao giờ bị cắt mà quản trị viên không biết.addusercấp cho một tài khoản thông tin đăng nhập bộ nhớ đệm và~/cache.cnf;deluserxoá thông tin đăng nhập và các khoá đã lưu của tài khoản;passwordđặt lại mật khẩu và ghi lại~/cache.cnf;showin thông tin kết nối.
Trong 4.1.x, cách ly chỉ được bật tự động trên máy chủ chưa có tài khoản. Bật
nó về sau sẽ chặn mọi máy khách kết nối không có mật khẩu. Thiết lập Redis cho
WordPress của panel không ghi mật khẩu, và cấu hình greylisting của rspamd cũng
không có, nên hãy kiểm tra những chỗ đó trước khi chạy secure trên máy chủ
đang dùng. Cho đến lúc đó objectcache status báo instance là dùng chung: nó
chỉ lắng nghe trên loopback, nên chính các tài khoản trên máy, chứ không phải
mạng bên ngoài, có thể đọc dữ liệu đệm của nhau.
hitechcloudcli objectcache unsecure <engine> --yes
Mở lại instance cho các máy khách không xác thực. Đây là lối thoát khẩn cấp, không phải thiết lập để bật mãi.
Chỉ loopback
hitechcloudcli objectcache loopback
Instance nào lắng nghe ra ngoài máy này và nhận máy khách không cần mật khẩu sẽ
được gắn vào 127.0.0.1 và ::1, trong cấu hình và trên máy chủ đang chạy, không
cần khởi động lại. Instance có yêu cầu mật khẩu chỉ được báo cáo và để nguyên.
Mỗi lần cập nhật đều chạy lệnh này.
Bộ nhớ đệm hình ảnh
hitechcloudcli objectcache image help
Bộ nhớ đệm chuyển đổi hình ảnh: bản WebP và AVIF được phục vụ cho trình duyệt hỗ trợ chúng, bản gốc cho mọi trình duyệt khác.
Khách hàng bật tính năng này cho từng website trong 2083 tại Websites > Image
Cache. Các bản chuyển đổi nằm ở /var/cache/hitechcloud/native/images/<domain>,
bên ngoài tệp của tài khoản; ảnh gốc không bao giờ bị thay đổi, và
objectcache image purge <domain> (Xoá các tệp đã tạo trong 2083) xoá các bản
chuyển đổi.
Ảnh không bao giờ được giải mã bằng quyền root. Mỗi lần chạy, bộ chuyển đổi được
khởi động với chính người dùng của website trong một unit systemd thuộc
user-<uid>.slice của tài khoản, giới hạn nửa nhân CPU với mức ưu tiên CPU và
đĩa thấp nhất, không có mạng và hệ thống chỉ đọc. Nó chỉ ghi vào
~/.cache/hitechcloud-images/ trong thư mục home của tài khoản, không bao giờ đi
theo liên kết tượng trưng trong thư mục gốc của website, và chuyển đổi tối đa 2000
ảnh mỗi lần. Sau đó root chỉ chép một kết qu ả vào bộ nhớ đệm nếu nó khớp với một
ảnh thật trong thư mục gốc, là tệp thường do tài khoản sở hữu, không lớn hơn ảnh
gốc, và đúng là tệp WebP hoặc AVIF.
Bộ mã hoá là cwebp và avifenc của bản phân phối
(objectcache image encoders --install):
| Hệ điều hành | WebP | AVIF |
|---|---|---|
| Ubuntu 22.04, 24.04, 26.04; Debian 12, 13 | webp | libavif-bin |
| AlmaLinux 9, 10 | libwebp-tools (kho CRB) | libavif-tools (chỉ có ở EPEL) |
Không có avifenc thì chỉ có WebP. ImageMagick không được dùng.
Nơi lưu thông tin đăng nhập
Thông tin đăng nhập quản trị của mỗi engine nằm trong
/etc/hitechcloud/hitechcloud/cache.cnf (ADMIN_REDIS_*, ADMIN_VALKEY_*).
Thông tin đăng nhập bộ nhớ đệm của panel là REDIS_PASSWORD trong môi trường
của panel. Khi panel không dùng được thông tin đăng nhập này, không ai đăng
nhập được vào 2083: xem
Xử lý sự cố.