Linuxパッチの設定

Linuxサーバーの更新を管理します。ディストリビューションのパッケージ管理の仕組みに依存するため、Windowsとは考え方が異なります。

対応ディストリビューションとパッケージ管理

Linuxの更新は、各ディストリビューションのパッケージ管理システムを通じて行われます。NinjaOneはその実行と結果の収集を担います。

系統	パッケージ管理
RPM系	yum、dnf
DEB系	apt

対応するディストリビューションとバージョンは公式ドキュメントで確認してください。サポート期間が終了したものは対象外になることがあります。

Windowsとの考え方の違い

最も大きな違いは、更新の粒度です。

Windowsでは個々の更新プログラムを承認・却下できますが、Linuxではパッケージ単位の管理になります。「この更新だけを除外する」という制御の仕方が異なります。

また、Linuxの更新は必ずしも再起動を必要としません。カーネルの更新など一部を除けば、サービスの再起動で済む場合が多くなります。

適用の設定

Policyの中で、スキャンと適用のスケジュールを設定します。

サーバーが対象になるため、次の点を考慮してください。

1. 業務処理が動いていない時間帯を選ぶ
2. 複数台を同時に更新しない（Staggerを使う）
3. 事前スクリプトで安全確認を入れる

2番目は冗長構成のサーバーで特に重要です。同じ役割のサーバーが同時に再起動すると、冗長性が失われます。

除外するパッケージの指定

更新の対象から外すパッケージを指定できます。

除外を検討するのは次のような場合です。

対象	理由
業務アプリケーションが依存するライブラリー	バージョンを固定する必要がある
データベース製品	計画的に更新する必要がある
カーネル	再起動を伴うため個別に管理する
独自にビルドしたパッケージ	標準の更新で上書きされると動作しなくなる

【注意】 除外したパッケージは更新されません。脆弱性が公表されても対象外のままです。除外する場合は、そのパッケージを別途どう管理するかを決め、記録に残してください。

再起動の要否の判定

Linuxでは、更新の内容によって再起動の要否が変わります。

更新内容	再起動
カーネル	必要
glibcなど基盤ライブラリー	必要または推奨
個別のアプリケーション	該当サービスの再起動で足りる場合が多い

再起動が必要な状態は検知できます。長期間再起動されていないサーバーは、カーネルの更新が有効になっていない可能性があります。

【運用のポイント】 「再起動が必要」と検知されたサーバーの一覧を、保存した条件として用意しておいてください。計画停止の際にまとめて対応できます。方法は検索・フィルター・保存ビューを参照してください。

事前・事後スクリプトの活用

Linuxサーバーでは、事前・事後のスクリプトが特に有効です。

タイミング	処理の例
事前	サービスの停止、設定ファイルのバックアップ、負荷状況の確認
事後	サービスの起動確認、動作確認、ログの収集

事前スクリプトで失敗を返せば適用を中止できるため、安全装置として機能します。設定方法はWindows OSパッチの設定と同様です。

適用結果の確認

適用の結果はデバイス詳細画面とダッシュボードで確認します。

Linuxで確認すべき固有の項目があります。

確認項目	見るべき点
適用の成否	依存関係のエラーが出ていないか
再起動の要否	カーネル更新後に再起動されているか
サービスの状態	更新後にサービスが起動しているか
ディスク容量	古いカーネルが蓄積して逼迫していないか

最後の項目は運用が長期化すると問題になります。古いカーネルが削除されずに/bootが満杯になり、次の更新が失敗するという事象が起きます。定期的な削除をScheduled Automationsで自動化しておくと予防できます。