設定ファイル

4 つのコマンドが F5 所有ファイルのエディターを開きます。これらはデバッグ API には含まれておらず、そのうち 2 つは説明文の中に「F5 XC サポートから要請がない限り使用しないでください」と明記されています。

`edit-app-env-file`

ノードのローカルアプリケーション環境である /etc/vpm/app_env.yaml を開きます。

execcli edit-app-env-file

アプライアンスの説明には「F5 XC サポートから要請がない限り使用しないでください」と記されています。文字通りに受け取ってください。このファイルは起動時に vpm によって読み込まれ、不正な値はノード上のすべてのプラットフォームコンテナに影響します。

`edit-certified-hardware`

認定ハードウェアの設定を開きます。

execcli edit-certified-hardware

アプライアンスによってサポート専用とマークされています。これは vpm が F5 認定のハードウェア上で動作しているかどうかを判断する設定です — 誤った設定は理論上の問題ではありません。有効な CertifiedHardwareEndpoint がない場合、 vpmd は「certified hardware の一致に失敗」として終了し、ノードは登録されません。これが、このリポジトリの cloud-init がデフォルト値に依存するのではなくエンドポイントを明示的に設定している理由です。 terraform/cloud-init/ce-node.yaml を参照してください。

`edit-azure-client-id-secret`

資格情報が期限切れになった場合に、この CE が使用する Azure クライアント ID とシークレットを更新します。

execcli edit-azure-client-id-secret

このコマンドが有効なケース。 動作していた CE が Azure 操作に失敗し始め、設定変更による原因が見当たらない場合 — 何かが壊れたのではなく、資格情報が期限切れになったケースがこのコマンドの対象です。

`edit-udev-10-nic-name`

NIC の命名方法を決定する /etc/udev/rules.d/10-nic-names.rules を開きます。

execcli edit-udev-10-nic-name

変更前にインターフェースページを確認してください。 CE 上の NIC 命名はすでに意外な仕様です。 eth0 は a-i-eth0 にリネームされてホストアドレスを持たず、SLO アドレスは vhost0 に存在し、 eth1/eth2 のどちらが内部アドレスを保持するかはこのデプロイメントの 3 つのノード間で一貫していません。 ip を参照してください。整然とした構成を前提とした udev ルールは状況を悪化させます。