Ich schreibe ein BASH-Skript, das automatisch das neueste Kernel-Image konfiguriert, erstellt und installiert. Der generierte Kernel sollte Folgendes enthalten:grsicherheitPatchset. Es würde die vorherige Konfiguration von verwenden /proc/config.gz
, die ich manuell erstellt habe, als ich den ersten benutzerdefinierten Kernel auf der Maschine kompiliert habe.
Ist es sicher, den Prozess vollständig zu automatisieren? Er würde folgendermaßen aussehen:
- Überprüfen Sie den aktuellsten
grsecurity
verfügbaren Kernel für - Laden Sie das
grsecurity
Patchset und den passenden Kernel-Quellcode herunter - Patchen Sie den Kernel
- Kopieren Sie die vorherige Kernel-Konfigurationsdatei in das Kernel-Quellverzeichnis
- Ausführen
make olddefconfig
, um den Kernel basierend auf der vorherigen Konfiguration zu konfigurieren - Kompilieren Sie den Kernel mit
fakeroot make deb-pkg
- Installieren Sie die resultierenden Pakete und ändern Sie die Bootloaderpriorität
- Senden Sie mir eine E-Mail mit dem Hinweis, dass ein Neustart erforderlich ist
Die Hauptfrage: Ist es wahrscheinlich, dass ein mit kompilierter Kernel olddefconfig
Fehler enthält, die das Booten des Systems verhindern, wenn die vorherige Konfiguration korrekt funktioniert? Dies ist sehr wichtig, da es sich um einen Remote-Server handelt, auf den über SSH zugegriffen wird, und eine manuelle Rettung sehr aufwändig wäre.
Antwort1
Wenn Sie sich keine Fehler leisten können, testen Sie.
Selbst wenn Sie sich Fehler leisten können, ist Testen gut. Führen Sie den Build, wenn möglich, in einer dedizierten Testumgebung aus. In vielen Fällen ist ein virtueller Gast ein geeignetes Testsystem. Wenn Sie Ihren aktualisierten Kernel neu starten und alle nachfolgenden Tests ebenfalls erfolgreich abgeschlossen werden, kopieren und stellen Sie das neue Paket erst dann auf Ihrem Remote-System bereit.
Nun zu Ihrer Hauptfrage: Wird Ihr Plan make olddefconfig
Fehler enthalten, die zu einem Boot-Fehler führen?
Nur ein Idiot würde glauben, dass ein System absolut narrensicher ist. Wenn Sie dasneuesteKernel, wie Sie sagten, sind Sie auf dem neuesten Stand und haben alle damit verbundenen Vorteile und Risiken. Das Risiko lässt sich verringern, indem Sie eine langfristige Version auswählen, bei der ein Funktionsumfang eingefroren ist und nur Fehler-/Sicherheitskorrekturen eingeführt werden.
Unabhängig davon: Bei jedem Neustart besteht ein geringes Risiko, dass er fehlschlägt.
Nebenbemerkung: Ich habe in der Vergangenheit so viele Stunden in Rechenzentren damit verbracht, Probleme/Fehlkonfigurationen von Servern zu beheben, dass ich jedem empfehle, seinen Remote-Servern immer eine geeignete Remote-Verwaltungsoption hinzuzufügen (z. B. HP ILO, Dell DRAC, Oracle ILOM usw. oder ein KVM-over-IP-Gateway), mit der Sie die meisten Probleme bequem von Ihrem Schreibtisch aus beheben können.