Entry points: every executable this product installs

CLI conventions is the other axis of this same question: what a command inside hitechcloudcli should look like. This page is about the executables themselves - what ends up on PATH (or at a fixed path an outside mechanism names), what installs it, what invokes it, and whether a human is ever meant to type it.

Since 4.0.1 every one of them is a Rust binary, published per architecture beside each release (<name>-linux-amd64, <name>-linux-arm64) and listed in the release's SHA256SUMS. Nothing is compiled on a server and no shell script is installed as a command.

The inventory​

Found by reading INSTALL.sh, the installer (hitechcloudcli server-install, server/install.rs in the CLI repository), the updater (hitechcloudcli update, update/full.rs), the systemd unit templates under hitechcloudpanel/configuration-native/systemd/, the units the CLI writes at run time (dbgovernor, limits, user-backupset, ipmanager), and the sudoers drop-in native/jail.rs writes.

The two entry-point names are the CLI binary itself: run as hitechcloud-jail or -hitechcloud-shell, it is that command, as if called with hitechcloudcli --direct jail / restricted-shell.

systemd runs hitechcloudcli directly. native/dbgovernor.rs, native/limits.rs and user/backupset.rs each write a oneshot unit whose ExecStart= is /usr/local/bin/hitechcloudcli <command> ..., so those runs go through the dispatcher personality (history, hooks) like a human's.

One binary, two personalities​

hitechcloudcli decides once, in main(), how it was asked:

• as hitechcloudcli (humans, hooks, cron, systemd): the dispatcher - root check, hitechcloudcli.log, pre/post hooks from /etc/hitechcloud/hitechcloud/hooks, --help, the error special case - which runs the command by re-executing itself (/proc/self/exe) with --direct in front;
• with --direct (or under any other name): the command runner, with no root check, history or hooks. The panels call it this way to read JSON.

The CLI tree​

/usr/local/hitechcloudcli holds only what the CLI reads at run time: the files .github/scripts/cli_runtime_files.txt lists (the command list aliases.txt, error.py, the admin's csf-ui.pl, and the bash dispatcher below). The release's runtime.tar.gz carries exactly those - the CLI's source is not shipped - and release.yml refuses a bundle with any .rs, .go or crate manifest in it. The installer and the updater mirror the tree from the bundle, keeping aliases.txt and imunify/, which the server writes itself.

hitechcloudpanel/hitechcloudcli-scripts in this repository is a copy of the CLI repository (everything but cli/). hitechcloud-devtools sync-cli-copy --check fails CI when the two differ.

The bash dispatcher, and updates from before 4.0.1​

The CLI repository still has one shell file, hitechcloudcli, and the bundle still ships it, for one reason: an updater from 3.0.0-3.7.x (a bash update.sh) copies the release's tree, installs that file as /usr/local/bin/hitechcloudcli, and fetches the compiled CLI only as hitechcloud-rustcli. Two things make such a server end up with a working CLI:

• the release's version/<v>/UPDATE.sh, generated by .github/scripts/legacy_update_sh.py, installs the compiled CLI over the dispatcher before it runs hitechcloudcli --direct update --migrate <v>;
• the dispatcher itself hands every command to a compiled CLI it finds (hitechcloud-rustcli, or hitechcloudcli), installing it over itself first, so cron, the panels and the update timer stop reaching the script.

A candidate counts only when the file it resolves to starts with the ELF magic: on newer servers hitechcloud-rustcli is a symlink to hitechcloudcli, and running a link back to the script would hand the command to itself, one bash deeper each time.

INSTALL.sh (the one other shell file, a POSIX sh bootstrap) never installs the dispatcher: it downloads hitechcloudcli-linux-<arch>, checks it against the release's SHA256SUMS, and hands over to its server-install.

The rule: what may ever become a new binary​

Nothing, unless an outside mechanism demands a binary path and cannot be satisfied any other way - a login shell field, a sudoers target, a systemd ExecStart, a kernel-level exec. Everything else is a subcommand, and an entry point an outside mechanism needs is a symlink to the CLI, not a new program. The hitechcli removal is the precedent for retiring a name: add the replacement, let it ship for a release, then delete the old name from every install path.

Testing​

• The CLI repository's cargo test --release (cli/tests/shell_dispatcher.rs covers the dispatcher's hand-over and the 3.x update sequence).
• hitechcloudpanel/engine/tests/repo_guards.rs: the legacy UPDATE.sh, the runtime bundle's contents, the demo deploy installing the compiled CLI.
• .github/scripts/no_shell_check.py (run by the native-stack workflow): shell found by its first line, in this repository and its submodules; only INSTALL.sh and the dispatcher may stay.