Chuyển tới nội dung chính
Version: 4.1

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-login giữ 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-admin dù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.
NOTE

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>
  • secure cấ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-fresh chỉ 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.
  • adduser cấp cho một tài khoản thông tin đăng nhập bộ nhớ đệm và ~/cache.cnf; deluser xoá 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; show in thông tin kết nối.
Máy chủ đã có tài khoản

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ànhWebPAVIF
Ubuntu 22.04, 24.04, 26.04; Debian 12, 13webplibavif-bin
AlmaLinux 9, 10libwebp-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ố.

Trang này có hữu ích không?