自動化されたカーネルアップグレード
最新のカーネルイメージを自動的に構成、ビルド、インストールするBASHスクリプトを作成しています。生成されたカーネルには、 grsecurity パッチセットが含まれている必要があります。マシンで最初のカスタムカーネルをコンパイルするときに手動で作成した/proc/config.gzの以前の構成を使用します。
プロセスを完全に自動化しても安全ですか？次のようになります。
grsecurityが利用可能な最新のカーネルを確認してくださいgrsecurityパッチセットと対応するカーネルソースツリーをダウンロードします- カーネルにパッチを適用する
- 以前のカーネル構成ファイルをカーネルソースディレクトリにコピーします
make olddefconfigを実行して、以前の構成に基づいてカーネルを構成します- カーネルを
fakeroot make deb-pkgでコンパイルします - 結果のパッケージをインストールし、ブートローダーの優先度を変更します
- 再起動が必要であることを示すメールを送ってください
主な質問：olddefconfigでコンパイルされたカーネルには、以前の構成が正しく機能している場合にシステムの起動を妨げるエラーが含まれる可能性がありますか？ SSH経由でアクセスされるリモートサーバーであり、手動によるレスキューには多大な労力がかかるため、これは非常に重要です。
失敗する余裕がない場合は、テストしてください。
失敗する余裕があったとしても、テストは良いことです。可能であれば、専用のテスト環境でビルドを実行します。多くの場合、仮想ゲストは適切なテストシステムを作成します。更新されたカーネルを再起動し、その後のテストも正常に完了したら、新しいパッケージをコピーしてリモートシステムにデプロイします。
今あなたの主な質問に：あなたの計画とmake olddefconfig起動失敗につながるエラーが含まれていますか？
システムが完全に絶対確実だと信じるのはばかだけです。あなたが述べたように、最新カーネルを実行したいとき、あなたはEdgeを出血させ、それに関連するすべての利点とリスクを持っています。リスクを軽減することは、機能セットが凍結されている長期リリースを選択することであり、バグ/セキュリティ修正のみが導入されます。
関係なく、再起動すると失敗するリスクがわずかにあります。
補足：私は過去にデータセンターでサーバーの問題/構成の誤りを修復するのに非常に多くの時間を費やしたため、常に適切なリモート管理オプション（HP ILO、DellのDRAC、OracleのILOMなど）を追加することをお勧めします。 KVM over IPゲートウェイ）リモートサーバーへ。これにより、ほとんどの問題をデスクの快適さで修正できます。