はじめに：LinuxサーバーやMacのパッチ適用、放置していませんか？
LAN内PC端末管理というとWindows Updateばかりが注目されますが、実際のLAN内インフラを見渡すとどうでしょうか？
- 開発チームがLAN内に置いている Ubuntu / Debian サーバー
- デザイナーやiOSエンジニアが使っている MacBook / Mac mini
- ファイルサーバーやバックアップ用の NAS（Linuxベース）
これらにも日々重大なセキュリティ脆弱性（OpenSSHのregreSSHion、sudoの特権昇格、macOSのゼロデイ等）が公表されています。
しかし、「1台ずつSSHで入って apt-get upgrade や softwareupdate を叩くのは面倒」「再起動が必要なのかどうか判断がつかない」という理由で、半年以上放置されているケースが後を絶ちません。
本記事では、Ansibleのような重たい構成管理ツールを導入することなく、PythonとSSH（Paramiko）だけで、LinuxとmacOSの未適用パッチをリモート診断し、サイレント適用して結果ログを中央に回収する自動化スクリプト を紹介します。
1. Ubuntu / Debian：非対話モードでの apt パッチ適用
SSH経由で apt-get upgrade を実行する際、最大の罠は 「途中で確認ダイアログ（設定ファイルの維持確認やサービス再起動確認）が表示されてコマンドが永久にブロック（ハング）すること」 です。
以下の環境変数をセットして、完全非対話（サイレント）モードで実行します。
💻 コア実装・設定スニペット（抜粋）
# (要点抜粋)
import paramiko
def patch_ubuntu_host(ssh: paramiko.SSHClient) -> dict:
# 対話プロンプトを完全無効化する環境変数
cmd = (
"sudo DEBIAN_FRONTEND=noninteractive "
"apt-get update && "
"sudo DEBIAN_FRONTEND=noninteractive "
"apt-get upgrade -y -o Dpkg::Options::='--force-confdef' -o Dpkg::Options::='--force-confold'"
)
stdin, stdout, stderr = ssh.exec_command(cmd, timeout=600)
exit_status = stdout.channel.recv_exit_status()
log = stdout.read().decode('utf-8')
# 再起動が必要かどうかの判定（Ubuntu公式のフラグファイル）
stdin, stdout, stderr = ssh.exec_command("test -f /var/run/reboot-required && echo 'YES' || echo 'NO'")
needs_reboot = (stdout.read().decode('utf-8').strip() == "YES")
return {
"status": "SUCCESS" if exit_status == 0 else "FAILED",
"needs_reboot": needs_reboot,
"log_summary": log[-300:] # ログ末尾
}
Ubuntuでは、再起動が必要なカーネル更新や重要ライブラリが当たると、OSが自動的に /var/run/reboot-required という空ファイルを作成します。このファイルの有無をチェックするだけで、業務時間外に再起動をかけるべきかどうかが機械的に判定できます。
2. macOS：CLI標準の softwareupdate コマンド制御
macOS端末に対しても、エージェントソフトを入れずに標準の softwareupdate CLI を叩くだけでセキュリティアップデートを適用できます。
3. 安全運用のための「事前チェック（Pre-flight Check）」
一斉パッチ適用で最も危険なのは、「ディスク容量が不足していてパッチ適用途中でOSが起動不能になる」トラブルです。
必ずコマンド実行前にディスク空き容量（最低5GB以上）をチェックします。
まとめ：異機種混在環境こそ「エージェントレス」が輝く
Windows、Ubuntu、macOSが混在するLAN内環境で、OSごとに別々の商用パッチ管理ソフトを契約するのはライセンスコストの無駄です。
- Ubuntuには
aptと/var/run/reboot-required - macOSには
softwareupdate - 共通のSSHプロトコルで接続し、Pythonで例外処理とログ回収を一元化する
この仕組みを整えるだけで、LAN内のLinuxサーバーやMac端末を「脆弱性の吹き溜まり」にすることなく、ボタン1つで最新の安全な状態に保ち続けることができます！
📚 さらに詳しいアーキテクチャ設計・パラメータ表・トラブルシューティング
最後までお読みいただきありがとうございます！
本記事が少しでも「役に立った」「あとで試したい」と感じていただけましたら、ぜひQiitaの 「いいね（♡）」 と 「ストック」、および アカウントのフォロー をいただけると今後の検証・執筆の大きな励みになります！
また、本記事のさらに踏み込んだ 「深層アーキテクチャ解説」「主要パラメータの技術的根拠」「現場アンチパターン・トラブルシューティング対応表」 は、以下のGitHub技術リファレンスにて公開しています。
👉 【第26弾 詳細技術リファレンス (QIITA_ARTICLE_DETAIL_26.md)】
⭐ 全14層・200パターンの自立型インフラ＆オンプレAIリファレンス集（おじさんの武器庫）を順次公開中です。ぜひGitHubリポジトリへの Star (★) と X (@OjisanTechnical) のフォローもお願いいたします！
👉 GitHub リポジトリ: ojisantech/ojisan-arsenal
💡 【検証環境・個人研究（PoC）に関する注記】
本記事は、筆者個人の自宅検証環境（ホームラボ／仮想環境）において、公開情報およびOSS（オープンソースソフトウェア）を用いて独自に構築・検証した個人研究（PoC）の記録です。特定の企業・団体の実環境や業務上の非公開情報とは一切関係ありません。