Điểm vào: mọi tệp thực thi mà sản phẩm này cài đặt

Quy ước CLI là trục còn lại của cùng câu hỏi này: một lệnh bên trong hitechcloudcli nên trông như thế nào. Trang này nói về chính các tệp thực thi - những gì nằm trên PATH (hoặc tại một đường dẫn cố định mà một cơ chế bên ngoài chỉ định), cái gì cài nó, cái gì gọi nó, và liệu con người có bao giờ cần gõ nó hay không.

Từ 4.0.1, tất cả đều là tệp nhị phân Rust, được phát hành theo từng kiến trúc bên cạnh mỗi bản phát hành (<name>-linux-amd64, <name>-linux-arm64) và được liệt kê trong SHA256SUMS của bản phát hành. Không có gì được biên dịch trên máy chủ và không có script shell nào được cài làm lệnh.

Danh mục​

Tìm được bằng cách đọc INSTALL.sh, trình cài đặt (hitechcloudcli server-install, server/install.rs trong kho CLI), trình cập nhật (hitechcloudcli update, update/full.rs), các mẫu unit systemd trong hitechcloudpanel/configuration-native/systemd/, các unit mà CLI ghi lúc chạy (dbgovernor, limits, user-backupset, ipmanager), và tệp sudoers drop-in mà native/jail.rs ghi.

Hai tên điểm vào chính là tệp nhị phân CLI: khi chạy dưới tên hitechcloud-jail hoặc -hitechcloud-shell, nó chính là lệnh đó, như thể được gọi bằng hitechcloudcli --direct jail / restricted-shell.

systemd chạy hitechcloudcli trực tiếp. native/dbgovernor.rs, native/limits.rs và user/backupset.rs mỗi tệp ghi một unit oneshot có ExecStart= là /usr/local/bin/hitechcloudcli <command> ..., nên các lần chạy đó đi qua tính cách dispatcher (lịch sử, hook) giống như con người.

Một tệp nhị phân, hai tính cách​

hitechcloudcli quyết định một lần, trong main(), xem nó được gọi như thế nào:

• dưới tên hitechcloudcli (con người, hook, cron, systemd): dispatcher - kiểm tra root, hitechcloudcli.log, hook trước/sau từ /etc/hitechcloud/hitechcloud/hooks, --help, trường hợp đặc biệt error - chạy lệnh bằng cách tự thực thi lại chính nó (/proc/self/exe) với --direct ở phía trước;
• với --direct (hoặc dưới bất kỳ tên nào khác): trình chạy lệnh, không có kiểm tra root, lịch sử hay hook. Các panel gọi nó theo cách này để đọc JSON.

Cây thư mục CLI​

/usr/local/hitechcloudcli chỉ chứa những gì CLI đọc lúc chạy: các tệp mà .github/scripts/cli_runtime_files.txt liệt kê (danh sách lệnh aliases.txt, error.py, csf-ui.pl của trang quản trị, và bash dispatcher bên dưới). runtime.tar.gz của bản phát hành mang đúng những tệp đó - mã nguồn của CLI không được phát hành - và release.yml từ chối gói có bất kỳ .rs, .go hay manifest crate nào. Trình cài đặt và trình cập nhật sao chép cây thư mục từ gói, giữ lại aliases.txt và imunify/ vì máy chủ tự ghi chúng.

hitechcloudpanel/hitechcloudcli-scripts trong kho này là bản sao của kho CLI (mọi thứ trừ cli/). hitechcloud-devtools sync-cli-copy --check làm CI thất bại khi hai bên khác nhau.

Bash dispatcher, và các bản cập nhật từ trước 4.0.1​

Kho CLI vẫn còn một tệp shell, hitechcloudcli, và gói vẫn phát hành nó, vì một lý do: trình cập nhật từ 3.0.0-3.7.x (một tệp bash update.sh) sao chép cây thư mục của bản phát hành, cài tệp đó làm /usr/local/bin/hitechcloudcli, và chỉ tải CLI đã biên dịch dưới tên hitechcloud-rustcli. Hai điều giúp máy chủ như vậy cuối cùng có CLI hoạt động:

• version/<v>/UPDATE.sh của bản phát hành, được tạo bởi .github/scripts/legacy_update_sh.py, cài CLI đã biên dịch đè lên dispatcher trước khi chạy hitechcloudcli --direct update --migrate <v>;
• bản thân dispatcher chuyển mọi lệnh cho CLI đã biên dịch mà nó tìm thấy (hitechcloud-rustcli, hoặc hitechcloudcli), cài CLI đó đè lên chính nó trước, để cron, các panel và bộ hẹn giờ cập nhật không còn gọi tới script.

Một ứng viên chỉ được tính khi tệp mà nó trỏ tới bắt đầu bằng magic ELF: trên máy chủ mới hơn, hitechcloud-rustcli là symlink tới hitechcloudcli, và chạy một liên kết trỏ ngược về script sẽ chuyển lệnh cho chính nó, mỗi lần sâu thêm một tầng bash.

INSTALL.sh (tệp shell còn lại, một bootstrap POSIX sh) không bao giờ cài dispatcher: nó tải hitechcloudcli-linux-<arch>, kiểm tra với SHA256SUMS của bản phát hành, và chuyển giao cho server-install của nó.

Quy tắc: những gì được phép trở thành tệp nhị phân mới​

Không gì cả, trừ khi một cơ chế bên ngoài đòi hỏi một đường dẫn nhị phân và không thể được đáp ứng theo cách khác - trường login shell, đích của sudoers, ExecStart của systemd, exec ở cấp kernel. Mọi thứ khác là lệnh con, và một điểm vào mà cơ chế bên ngoài cần là symlink tới CLI, không phải một chương trình mới. Việc gỡ hitechcli là tiền lệ cho việc khai tử một tên: thêm tên thay thế, để nó phát hành qua một bản, rồi xoá tên cũ khỏi mọi đường cài đặt.

Kiểm thử​

• cargo test --release của kho CLI (cli/tests/shell_dispatcher.rs bao phủ việc chuyển giao của dispatcher và trình tự cập nhật 3.x).
• hitechcloudpanel/engine/tests/repo_guards.rs: UPDATE.sh cũ, nội dung của gói runtime, bản triển khai demo cài CLI đã biên dịch.
• .github/scripts/no_shell_check.py (do workflow native-stack chạy): tìm shell theo dòng đầu tiên, trong kho này và các submodule; chỉ INSTALL.sh và dispatcher được phép giữ lại.