Comandos no dispositivo

Dois conjuntos de comandos distintos alcançam um Customer Edge, e nenhum contém o outro.

• No dispositivo, a CLI do Site tem 6 comandos de nível superior e 82 subcomandos execcli.
• Pela rede, a API de depuração possui seu próprio catálogo de 34.

A maior parte da superfície no dispositivo não possui equivalente na API: todo o plano de controle Vega, os wrappers do Envoy, a captura de pacotes, o conjunto de parâmetros do kubelet, os arquivos edit-* e o par auxiliar de acesso root são acessíveis apenas pelo dispositivo.

Para acessá-los, é necessário SSH ou o console serial, além de algo que não está documentado em nenhum lugar:

execcli é um comando oculto

execcli não aparece no menu interativo da CLI do Site. Ele recebe o nome de um comando como argumento, e digitar execcli seguido de Tab lista todos os 82 com a descrição de uma linha do próprio appliance para cada um. Esse menu de conclusão é o catálogo definitivo para uma build, e é o que sitecli/exec-catalog.json registra.

Como isso foi medido e como os conjuntos se sobrepõem

O conjunto abaixo não foi transcrito de um documento do fornecedor. Ele foi lido de nós ativos com scripts/sitecli_ssh_harvest.py e registrado em sitecli/exec-catalog.json com sua procedência. Três execuções, em três estados de registro:

Medido em	Nível superior	execcli
site_state: PROVISIONING	6	82
site_state: PROVISIONED	6	82
site_state: ONLINE	6	82

As três retornaram conjuntos idênticos — os mesmos nomes, não apenas os mesmos totais, e a última foi uma implantação diferente com nomes de site e recursos distintos. Portanto, a superfície de comandos não muda com o estado de registro, e um comando ausente está genuinamente ausente, não apenas ainda não disponível.

Em comparação com os 34 da API de depuração, isso gera dois números que vale manter claros:

• 51 subcomandos execcli não possuem equivalente na API.
• 55 é o mesmo número contado em toda a superfície no dispositivo, pois também inclui os quatro comandos configure*, que residem no nível superior em vez de sob execcli.

Ambos estão corretos; um leitor que recalcule um e encontre o outro não cometeu um erro. Todos os números aqui derivam de sitecli/catalog.json e sitecli/exec-catalog.json.

Cinco comandos que não existem

factory-reset, upgrade, reboot, show e clear não estão nesta build. São o tipo de coisa que uma CLI do Site plausivelmente teria, foram incluídos na classificação deste repositório por um tempo com base nessa suposição, e nenhuma enumeração os encontrou. O nível superior tem exatamente seis entradas: configure, configure-generic-hardware, configure-network, configure-http-proxy, diagnosis e health.

Três comandos da API não são subcomandos do execcli

Procurar por estes sob execcli não encontra nada, o que é interpretado como “o comando está ausente”:

• health e diagnosis são comandos de nível superior da CLI do Site. Digite-os no prompt >>> diretamente, sem o prefixo execcli.
• dig é acessível pela API de depuração e não aparece em nenhum menu no dispositivo, portanto está ausente da listagem de passthrough abaixo. É exclusivo da API.

O que está documentado e o que está apenas listado

Um Customer Edge executa Linux e diversos daemons de terceiros. Documentar seus comandos duplicaria suas próprias referências e implicaria que a F5 os possui, portanto a regra é: documentar o software da F5 e, para todo o restante, documentar apenas o que é específico de um CE.

Três categorias, porque “nosso” e “deles” não é uma divisão clara. A divisão está registrada em sitecli/command-classification.json.

Categoria	Tratamento
Software F5	Documentação completa — propósito, sintaxe, argumentos, saída capturada, o que observar. Argo, Vega, vpm, vifdump, configure*, o conjunto edit-*, parâmetros do kubelet, acesso root.
Interpretação específica do CE	Uma ferramenta de terceiros cuja saída tem um significado particular em um CE. A leitura específica do CE é documentada e a semântica própria da ferramenta é deixada para o upstream.
Passthrough	Linux simples ou terceiros sem nada específico do CE a dizer. Listado como disponível, com indicação para o upstream. Sem prosa.

Essa distinção decide se uma página existe ou não, e é o que evita que esta documentação se deteriore em uma cópia pior das páginas de manual.

Software F5

Plano de controle VegaSeis comandos vegactl: objetos de configuração, tabelas de introspecção, buffers de rastreamento e qual nó detém o papel primário.

EnvoyQuatro wrappers em torno da interface de administração do Envoy — listeners, clusters e dois dumps de configuração.

Captura de pacotesOs cinco comandos vifdump. Documentados, mas nunca executados aqui: eles escrevem arquivos de captura no nó.

Parâmetros do kubeletLer, adicionar e remover parâmetros personalizados do kubelet. Direcionado pelo suporte.

Serviço vpmO agente que registra o nó e executa os contêineres da plataforma.

Arquivos de configuraçãoOs quatro comandos edit-* que abrem arquivos de propriedade da F5 no nó.

Acesso root auxiliarCriação e remoção da conta root xuser. Direcionado pelo suporte e deixa o nó modificado.

Configuração do nóOs quatro comandos configure* no nível superior da CLI do Site.

Passthrough

Disponíveis no dispositivo e não documentados aqui — são o sistema operacional e os daemons de terceiros, não o software da F5, e suas próprias referências são melhores do que qualquer coisa que esta página pudesse reproduzir.

Comandos	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	Os arquivos são do sistema operacional
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 — cada um desses interrompe as cargas de trabalho no nó

Dois destes valem ser conhecidos mesmo sem receberem uma página própria. files realiza operações de arquivo e só escreve em /tmp. E todo systemctl-restart-* é disruptivo por definição — reiniciar crio ou kubelet interrompe as cargas de trabalho naquele nó.

Sete comandos existem em builds mais recentes e não nesta

collect-database-stats, iptables-lv, os três comandos marker-exists-*, systemctl-restart-NetworkManager e systemctl-start-crio-prune estão ausentes aqui e presentes na build 20260703-e2c462a, resultando em 89 comandos execcli lá contra 82 aqui. Comandos em builds mais recentes os documenta. Eles estão registrados em not_on_this_build.newer_build na classificação para que nada aqui seja confundido com algo que você pode executar em crt-20250613-3382.

collect-debug-info é um caso à parte: não aparece em nenhum menu nem catálogo. O texto de boas-vindas da CLI do Site diz que a CLI “permite… coletar informações de depuração para o suporte”, portanto o nome provavelmente foi derivado dessa prosa em vez de observado. Está marcado como não verificado e deliberadamente não testado — executar especulativamente um comando desconhecido em um nó ativo é como uma captura de pacotes vifdump foi iniciada em um CE que ainda estava em processo de registro.