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