prerm での VPN パッケージ削除に失敗した場合に最初に確認すること

アンインストールは、メンテナンススクリプトを名指しするエラーで途中停止し、VPN が半分削除されたまま残ることがあり、設定ファイルは残り、サービスがまだ動作している可能性があり、パッケージマネージャーは続行を拒否します。古いフォーラムの投稿にある魅力的な修正は、スクリプトを削除して削除を強制することです。それは症状を扱うだけで、失敗したクリーンアップ手順を捨ててしまいます。まず段階とパッケージの状態を読み取ってください。

実際に失敗したのはライフサイクルのどの段階か

Debian パッケージはインストール時に preinst と postinst を、削除や完全消去時に prerm と postrm を実行し、各スクリプトの終了ステータスが次の動作を決めます。prerm のエラーは、パッケージのファイルが削除される前に削除が止まったことを意味し、postrm のエラーは削除がすでに済んでクリーンアップが失敗したことを意味します。どちらも異なる復旧を伴う別の状況です。ディストリビューションのポリシーは、失敗した段階を避けるのではなく再実行すべきものとして、スクリプトが繰り返し実行に耐えることも求めています。

最初のエラーを、パッケージ名、バージョン、ディストリビューションのリリースとともにそのまま記録します。後続のエラーは通常は結果です。

変更する前にパッケージの状態を読む

別のコマンドを出す前に、パッケージマネージャーに何が起きたと思うか尋ねます。

dpkg -l vpn-package
dpkg --audit
apt-get -s remove vpn-package

一覧はパッケージの状態フラグを示し、監査は壊れたまま、または半分設定されたまま残ったパッケージを見つけ、シミュレートされた削除は何にも触れずに apt が何をするかを出力します。同じスクリプトで失敗するシミュレーションは、ネットワークではなく段階を裏付けます。エラーで示されたスクリプトに注目し、どのスクリプトが存在するかを見る必要があればパッケージの情報ファイルを一覧します。これらのどれも、まだそのファイルを編集する根拠にはなりません。

修復の前に管理経路を守る

VPN がこのホストへの唯一の SSH セッションを運んでいるなら、それを削除すると修復の途中でアクセスが切れます。先にコンソール、帯域外の管理インターフェース、または第二の経路を用意し、開始前に機能することを確認してください。後で必要になるプロファイルと再登録の手順は、完全消去が生成された設定を削除する可能性があるため保存してください。チケットに貼るメモから認証情報を外し、秘密鍵は診断から完全に切り離してください。

文書化された手動による上書きは、パッケージ所有者の指示のもとで、省略した手順を明示しつつ最後の手段として扱ってください。パッケージ自身のクリーンアップ一覧がまだ必要な作業の記録であるため、ワイルドカードでスクリプトを削除しないでください。

パッケージ、ネットワーク、認証情報の結果を分ける

サポートされた手順が終わったら、三つの結果を個別に確認する必要があります。パッケージのトランザクションは、監査に半分設定された項目を残さず、きれいな状態を示すべきです。ネットワークは、正しいサービスが停止し、古いルートや DNS 設定がなく、交換または直接アクセスのための経路が機能しているという、意図したとおりの状態でなければなりません。遠端側が三つ目の結果であり、クライアントをアンインストールしても何も取り消されないため、不要になった認証情報はそのアカウントの所有者を通じて失効させるべきです。

その後に再接続し、許可された宛先を一つテストします。トンネルがまだ動いているきれいなパッケージ状態は、きれいなネットワークとは別の結果であり、削除が実際に効いたことを教えてくれるのは後者だけです。