sudo・&・-b・--daemon：OpenVPNクライアントをバックグラウンドで動かす方法

「バックグラウンドで動かす」という言葉には二つの問いが隠れている。第一は、このユーザーが特権プロセスを起動できるのかという点、第二は、誰も端末に入力しなくてもセッションを続けられるのかという点だ。シェルのアンパサンドはどちらにも答えず、sudo のパスワードを変数に保存するスクリプトは第一に悪く答え、第二には何も触れていない。両者を切り離せば、選択肢の比較は簡単になる。

三つの候補は利便性ではなく所有権で比較すべきだ。

端末を離れる三つの方法、三つの異なる所有者

コマンドにアンパサンドを付けると、シェルはそれをバックグラウンドジョブとして実行し、ジョブは依然としてそのシェルに属する。sudo はプログラムが始まる前にも問い合わせることがあり、OpenVPNはその後に鍵のパスフレーズやログインを尋ねることがある。入力を待つコマンドをバックグラウンドに置くと、誰も見ていない端末を待つプロセスが生まれる。端末は解放されるが、やり取りは解放されない。

それは最も安価な選択肢であり、最も紛らわしい形で失敗するのは、問い合わせが操作者のすでに離れた場所に現れるからだ。

sudo -b は認証情報のハンドラーではない

sudo -b sudo 自身の視点でコマンドをバックグラウンドで実行するが、それは欠けていた機能のように聞こえてそうではない。sudo のマニュアルによれば、対話型コマンドは一般にそのモードで正しく動作せず、シェルのジョブ制御は生成されたプロセスを管理できない。問いに答える手段を与えずにプロセスを移すだけだ。秘密鍵のパスフレーズやゲートウェイへのログインを提供するものは何もない。

接続に対話が必要なら、解決策はサポートされた非対話的な認証の仕組みであり、同じ問い合わせを起動する別の方法ではない。

--daemon が変えるのはプログラムであり、ログインではない

--daemon 初期化後に切り離すよう OpenVPN 自身に求める。2.6 のマニュアルは、オプションの解析時に syslog のリダイレクトが起こると記しているが、切り離しはその後に起きるため、メッセージは予想より早く端末に出なくなることがある。その時点以降の沈黙はトンネルについて何も証明しない。明示的な --logまたは--log-append を追加して、出力が読める場所に残るようにする。

デーモンモードはコンソールも永久に奪う。保護された秘密鍵はそのモードではaskpassを必要とし、コンソールで入力した認証情報とキャッシュ系オプションの組み合わせは、後続の再認証に尋ねる場所を残さないことがある。バックグラウンド起動が最初の鍵更新を生き延びると仮定する前に、インストール済みのバージョンで認証モデルを確認すること。

sudo の検証が買うもの、買わないもの

sudo -v キャッシュされたローカル資格情報を検証または更新し、ポリシーが要求すれば認証する。OpenVPN を起動せず、ゲートウェイに対して認証せず、スクリプト内の後続コマンドが許可されることも保証しない。sudo -nは逆の意味で、問い合わせず失敗させる。これによりローカルの認可失敗が明示的になり、それは有用だが、OpenVPN が後で何を求めるかについては何も語らない。

どちらの選択肢も、全員にパスワードなしのコマンドを許したり、管理者パスワードをスクリプトに流し込んだりする理由にはならない。

観察できる所有者を選ぶ

マシンが所有するトンネルには、ディストリビューションがサポートするサービスインスタンスを使う。その所有者は起動・停止・状態・ログを提供し、セッションが終わっても存続する。シェルのバックグラウンド実行、デーモン化、再起動ループを互いに組み合わせると、一つのトンネルに三人の所有者が生まれ、どれが動いているのか明確な答えがなくなる。

どれを選ぶにせよ、トンネルが存在する目的のリソースを検証すること。起動要求の成功はプロセスの出来事であり、接続が機能している証拠ではない。