On-Box-Befehle

Zwei separate Befehlssätze erreichen einen Customer Edge, und keiner enthält den anderen.

• Auf dem Gerät verfügt die Site CLI über 6 übergeordnete Befehle und 82 execcli-Unterbefehle.
• Über das Netzwerk besitzt die Debug-API einen eigenen Katalog mit 34 Befehlen.

Der größte Teil der On-Box-Oberfläche hat kein API-Äquivalent: Die gesamte Vega-Steuerungsebene, die Envoy-Wrapper, die Paketerfassung, der kubelet-Parametersatz, die edit-*-Dateien und das ergänzende Root-Zugriffspaar sind nur vom Gerät aus erreichbar.

Der Zugang erfordert SSH oder die serielle Konsole, sowie eine Sache, die nirgendwo dokumentiert ist:

execcli ist ein versteckter Befehl

execcli erscheint nicht im interaktiven Menü der Site CLI. Es nimmt einen Befehlsnamen als Argument entgegen, und das Eingeben von execcli gefolgt von Tab listet alle 82 mit der eigenen einzeiligen Beschreibung des Geräts für jeden auf. Dieses Vervollständigungsmenü ist der maßgebliche Katalog für einen Build, und es ist das, was sitecli/exec-catalog.json aufzeichnet.

Wie dies gemessen wurde und wie sich die Sätze überschneiden

Der nachfolgende Satz wurde nicht aus einem Herstellerdokument übertragen. Er wurde von Live-Knoten mit scripts/sitecli_ssh_harvest.py ausgelesen und mit seiner Herkunft in sitecli/exec-catalog.json übernommen. Drei Durchläufe in drei Registrierungszuständen:

Gemessen bei	Oberste Ebene	execcli
site_state: PROVISIONING	6	82
site_state: PROVISIONED	6	82
site_state: ONLINE	6	82

Alle drei lieferten identische Sätze zurück – dieselben Namen, nicht nur dieselben Gesamtzahlen, und der letzte war eine andere Bereitstellung mit anderen Site- und Ressourcennamen. Der Befehlsumfang ändert sich daher nicht mit dem Registrierungszustand, und ein fehlender Befehl ist tatsächlich nicht vorhanden, anstatt nur noch nicht angeboten zu werden.

Gegenüber den 34 Befehlen der Debug-API ergibt das zwei Zahlen, die es auseinanderzuhalten gilt:

• 51 execcli-Unterbefehle haben kein API-Äquivalent.
• 55 ist dieselbe Zahl, über die gesamte On-Box-Oberfläche gezählt, da sie auch die vier configure*-Befehle umfasst, die auf der obersten Ebene statt unter execcli angesiedelt sind.

Beide sind korrekt; ein Leser, der den einen neu berechnet und den anderen findet, hat keinen Fehler gemacht. Jede Zahl hier leitet sich aus sitecli/catalog.json und sitecli/exec-catalog.json ab.

Fünf Befehle, die nicht existieren

factory-reset, upgrade, reboot, show und clear sind nicht in diesem Build vorhanden. Es sind die Art von Befehlen, die eine Site CLI plausiblerweise hat, sie wurden in diesem Repository eine Zeit lang auf dieser Annahme basierend klassifiziert, und keine Aufzählung fand sie. Die oberste Ebene hat genau sechs Einträge: configure, configure-generic-hardware, configure-network, configure-http-proxy, diagnosis und health.

Drei API-Befehle sind keine execcli-Unterbefehle

Die Suche nach diesen unter execcli ergibt nichts, was als „der Befehl fehlt” gelesen wird:

• health und diagnosis sind übergeordnete Site-CLI-Befehle. Geben Sie diese direkt an der >>>-Eingabeaufforderung ein, ohne execcli-Präfix.
• dig ist über die Debug-API erreichbar und erscheint in keinem der On-Box-Menüs, weshalb es in der nachfolgenden Passthrough-Auflistung fehlt. Es ist ausschließlich über die API verfügbar.

Was dokumentiert ist und was nur aufgeführt wird

Ein Customer Edge betreibt Linux und eine Reihe von Drittanbieter-Daemons. Deren Befehle zu dokumentieren würde ihre eigenen Referenzen duplizieren und implizieren, dass F5 sie besitzt. Daher gilt folgende Regel: F5-Software dokumentieren, und für alles andere nur das dokumentieren, was für einen CE spezifisch ist.

Drei Stufen, da „unsere” und „ihre” keine saubere Trennung ist. Die Aufteilung ist in sitecli/command-classification.json erfasst.

Stufe	Behandlung
F5-Software	Vollständige Dokumentation – Zweck, Syntax, Argumente, erfasste Ausgabe, worauf zu achten ist. Argo, Vega, vpm, vifdump, configure*, der edit-*-Satz, kubelet-Parameter, Root-Zugriff.
CE-spezifische Interpretation	Ein Drittanbieter-Werkzeug, dessen Ausgabe auf einem CE eine besondere Bedeutung hat. Die CE-spezifische Lesart wird dokumentiert, die eigene Semantik des Werkzeugs bleibt beim Upstream.
Passthrough	Reines Linux oder Drittanbieter ohne CE-spezifische Aussage. Als verfügbar aufgeführt, mit einem Verweis zum Upstream. Kein Fließtext.

Diese Unterscheidung entscheidet darüber, ob eine Seite überhaupt existiert, und sie verhindert, dass diese Dokumentation zu einer schlechteren Kopie der Man-Pages verkommt.

F5-Software

Vega control planeSix vegactl commands: configuration objects, introspection tables, trace buffers, and which node holds the primary role.

EnvoyFour wrappers around Envoy's admin interface — listeners, clusters, and two config dumps.

Packet captureThe five vifdump commands. Documented, never run here: they write capture files onto the node.

Kubelet parametersRead, add and remove custom kubelet parameters. Support-directed.

vpm serviceThe agent that registers the node and runs the platform containers.

Configuration filesThe four edit-* commands that open F5-owned files on the node.

Auxiliary root accessCreating and removing the xuser root account. Support-directed, and it leaves the node modified.

Node configurationThe four configure* commands at the Site CLI top level.

Passthrough

Auf dem Gerät verfügbar und hier nicht dokumentiert – dies sind das Betriebssystem und Drittanbieter-Daemons, nicht F5-Software, und ihre eigenen Referenzen sind besser als alles, was diese Seite wiederholen könnte.

Befehle	Upstream
ping, netstat, lsof, ip, ip-link-show, nmcli, tracepath	iproute2, NetworkManager
top, check-mem, sysctl, load-sysctl-conf, journalctl, files, rpm-ostree, chronyc-sources	coreutils, procps, systemd, rpm-ostree, chrony
edit-etc-hosts, edit-sysctl-conf	Die Dateien gehören zum Betriebssystem
systemctl-status-crio, systemctl-status-docker, systemctl-status-kubelet, systemctl-status-iscsid, systemctl-status-multipathd	systemd
systemctl-restart-crio, systemctl-restart-docker, systemctl-restart-kubelet, systemctl-restart-iscsid, systemctl-restart-multipathd	systemd – jeder dieser Befehle unterbricht Workloads auf dem Knoten

Zwei davon sind es wert, bekannt zu sein, auch wenn sie keine eigene Seite erhalten. files führt Dateioperationen durch und schreibt ausschließlich unterhalb von /tmp. Und jeder systemctl-restart-*-Befehl ist per Definition störend – ein Neustart von crio oder kubelet unterbricht die Workloads auf diesem Knoten.

Sieben Befehle existieren in neueren Builds und nicht in diesem

collect-database-stats, iptables-lv, die drei marker-exists-*-Befehle, systemctl-restart-NetworkManager und systemctl-start-crio-prune fehlen hier und sind im Build 20260703-e2c462a vorhanden, was dort 89 execcli-Befehle gegenüber 82 hier ergibt. Befehle in neueren Builds dokumentiert diese. Sie sind unter not_on_this_build.newer_build in der Klassifizierung erfasst, damit nichts hier mit etwas verwechselt wird, das auf crt-20250613-3382 ausgeführt werden kann.

collect-debug-info ist ein Sonderfall: Es erscheint in keinem Menü und keinem Katalog. Der Willkommenstext der Site CLI besagt, dass die CLI „erlaubt, … Debug-Informationen für den Support zu sammeln”, sodass der Name höchstwahrscheinlich aus diesem Text abgeleitet wurde und nicht beobachtet wurde. Er ist als unverifiziert markiert und wird absichtlich nicht sondiert – das spekulative Ausführen eines unbekannten Befehls auf einem Live-Knoten ist der Grund, warum eine vifdump-Paketerfassung auf einem CE gestartet wurde, das sich noch in der Registrierung befand.