ディレクトリ内の二十個のプロファイルは進歩に見えるし、インポートはコマンド一つで済む。その後に得られるのは、似た名前の二十個の保存済み接続であり、どのファイルがどれを生んだかの記録もなく、どれかが動作する証拠もない。インポートが難しい部分だったことは一度もない。難しいのは棚卸しだ。

フォルダは入力であり、設定ではない

そのディレクトリ内のファイルは、代替の出口、別々の顧客環境、あるいはファイル名では何も区別できない一つのプロファイルの三つの改訂でありうる。それらはプロビジョニングシステムから出てきたもので、プロセスそのものではなくプロセスへの入力になる。すべてをインポートすると保存済みオブジェクトができ、オブジェクトを保存することはそれを使うことに同意するのと同じではない。フォルダを原材料として扱おう。検証済みの出所、選んだ部分集合、記録した結果。欲しい出力は短くレビュー済みの棚卸しであり、より長い接続メニューではない。

何かをインポートする前に、出所フォルダの所有者を決めておこう。誰も所有していないフォルダは、誰も承認できないフォルダだ。

一つのファイルをインポートして検査する

承認済みのファイルを一つインポートし、それが何を作ったかを読む。UUID、エンドポイント、認証方式、ファイル参照、そしてルートやDNSの設定を確認し、共有レポートに秘密を貼り付けずに行う。外部の証明書ファイルを参照するプロファイルはパスを参照し続けるので、補助資料はプロファイルが期待する場所に残さなければならない。インポートは読み取り専用の構文チェックでもない。既定では永続的な接続を書き込み、明示的な一時フラグだけがそれを変える。

次に、その接続を通常の資格情報フローで有効にし、ゲートウェイが受け入れるかを見る。インポートの成功はパーサーがファイルを理解したことを証明するだけで、動作するトンネルよりずっと小さな主張だ。

記憶ではなくマニフェストを保つ

出所ファイル、その目的、結果のUUID、レビューに通ったかどうかを書き留める。一行につき四つの項目を、後から再構成するのではなく作業しながら更新する。その表がなければ、七件の成功したインポートと一件の失敗が、推測に費やす午後になる。

出所のパスが内部構造を明かすなら、共有文書には載せない。マニフェストにはラベルで十分だ。

再実行と重複

部分的なバッチは普通のことだ。二十件に一件は失敗する。何かを再試行する前に、すでに持っているUUIDを突き合わせ、フォルダ全体を新規開始として再試行してはならない。

同じファイルの二回目のインポートは更新ではない。別の保存済みオブジェクトを作り、一覧では同じに見える名前になることが多い。バッチの前後で棚卸しを比較し、意図した追加だけをレビューする。どのUUIDが使われているかを確認したうえで、それを所有するマネージャーから重複を削除する。その間、無関係なWi-FiやEthernetのプロファイルはそのままにしておく。一括整理は、動作中の接続が消える道だからだ。

有効化は別の判断

インポートのループは、無条件の接続で終わってはならない。保存済みプロファイル二十個はライブラリであり、同時に二十個のトンネルはDNS問題を伴うルーティング事故だ。バッチを実行する前に、どれを有効にしてよいか、どの条件でならよいかを決める。

マシンの自動起動ポリシーに注意しよう。誰も頼まないのに新しいプロファイルを有効にすることがある。サポートする選択肢の短い一覧を公開し、将来の差し替えの所有者を明記する。出所のエクスポート、保存済みプロファイル、リモートの資格情報はそれぞれ別のスケジュールで失効するからだ。その対応表が保守されていれば、更新は調査ではなく照会になる。

関連記事