Frage Best Practices für die Aktualisierung eines zuvor nicht gepflegten Servers RHEL5.7


Ein neuer RedHat EL5.6 Server wurde kürzlich in meine Obhut genommen. Es ist sofort offensichtlich, dass in den letzten 12 Monaten wenig oder gar keine Aufmerksamkeit auf Aktualisierungen der Pakete gerichtet wurde.

Normalerweise bin ich der Meinung, wenn es nicht kaputt ist - repariere es nicht. Nach der Registrierung des Servers mit RHN und der Verwendung des yum-security-Plugins zur Überprüfung von Sicherheitsupdates stehen jedoch nur über 1100 "Sicherheitsupdates" zur Verfügung.

Hat jemand eine ähnliche Situation gehabt? Ich zögere, alles nur zu aktualisieren, da ich gerne weiß, was aktualisiert wird und ob es Auswirkungen auf alles hat, was auf der Box läuft (dies ist ein Produktionsserver). Es sieht jedoch auch so aus, als würde ich mich an diese Praxis halten und müsste 1100 Paket-Errata Zeile für Zeile durchgehen. Gibt es eine effizientere Lösung?


21
2018-03-04 14:02


Ursprung




Antworten:


Im Allgemeinen werden Sicherheitsupdates als etwas sicher angesehen, insbesondere für eine Distribution mit Zielen wie RedHat. Ihr Hauptaugenmerk liegt auf der Schaffung einer konsistenten Betriebsumgebung. Als solche neigen die Betreuer dazu, Versionen von Paketen zu wählen und bleiben ihnen auf lange Sicht treu. Um zu sehen, was ich meine, schauen Sie sich die Versionen solcher Pakete an kernel, python, perl, und httpd. Was sie auch tun, ist Backport-Sicherheits-Patches von den Upstream-Entwicklern. Wenn also eine Sicherheitslücke für alle Versionen von Apache httpd 2.2.x gefunden wird, kann die Apache Foundation die Version 2.2.40 mit dem Fix veröffentlichen, aber RedHat wird den Patch lokal auslösen und freigeben httpd-2.2.3-80 mit der Lösung.

Bedenken Sie auch, dass Sie derzeit über ein RHEL5.7-System sprechen, die aktuelle Version ist 5.9. Einige Softwareanbieter unterstützen nur bestimmte Unterfreigaben. Ich bin vor kurzem auf eine Software gestoßen, zum Beispiel, dass der Hersteller sagt, dass er nur mit 5.4 arbeitet. Das heißt es nicht Gewohnheit laufen auf 5.9, aber es kann bedeuten, dass sie keine Unterstützung bieten, wenn nicht Arbeit.

Es gibt auch Bedenken, Massenaktualisierungen eines Systems durchzuführen, das so lange nicht gepatcht wurde. Die größte, auf die ich gestoßen bin, ist eher ein Problem des Konfigurationsmanagements, das durch große Updates noch verschlimmert werden kann. Manchmal wird eine Konfigurationsdatei geändert, aber der Administrator startet den Dienst nie neu. Dies bedeutet, dass die Konfiguration auf der Festplatte noch nie getestet wurde und die laufende Konfiguration möglicherweise nicht mehr existiert. Wenn der Dienst neu gestartet wird, was nach der Installation der Kernel-Updates der Fall ist, wird er möglicherweise nicht neu gestartet. Oder es kann sich anders verhalten Einmal es startet neu.

Mein Rat wäre, die Updates zu machen, aber sei schlau.

  • Planen Sie es während eines Wartungsfensters aus. Wenn nichts anderes der Server neu gestartet werden muss, gab es eine Reihe von Kernel-Updates und Sie müssen neu starten, um sie anzuwenden.
  • Stellen Sie sicher, dass Sie eine vollständige Sicherung durchführen, bevor Sie etwas unternehmen. Dies kann Snapshotting sein, wenn es sich um eine VM handelt, die eine vollständige Sicherung für das, was auch immer Ihr Werkzeug ist, auslöst /(zu einem anderen System), wobei a dd Bild der Laufwerke, was auch immer. Nur solange es etwas ist, von dem man wiederherstellen kann.
  • Planen Sie aus Wie Sie wenden die Updates an. Du willst nicht einfach einen werfen yum update -y daran und geh weg. Für all die guten Dinge, die Yum tut, tut es das nicht Reihenfolge, wenn Updates entsprechend den Abhängigkeiten angewendet werden. Dies hat in der Vergangenheit zu Problemen geführt. Ich renne immer yum clean all && yum update -y yum && yum update -y glibc && yum update. Das neigt dazu, sich um die meisten möglichen Bestellprobleme zu kümmern.

Dies kann auch eine gute Zeit sein, um neu zu formatieren. Wir haben RHEL6 schon eine ganze Weile. Abhängig von dem, was dieser Server tut, kann es sinnvoll sein, diesen Vorgang so auszuführen, wie er ist, während Sie eine neue Instanz parallel aufrufen. Nach der Installation können Sie alle Daten kopieren, die Dienste testen und den Schnitt durchführen. Dies gibt Ihnen auch die Möglichkeit, von Grund auf zu wissen, dass das System standardisiert, sauber, gut dokumentiert und all dieser Jazz ist.

Egal, was Sie tun, ich finde es ziemlich wichtig, dass Sie sich auf ein aktuelles System einlassen. Sie müssen nur darauf achten, dass Sie auf Ihre Arbeit und das fertige Produkt vertrauen.


21
2018-03-04 14:46



Danke für die ausführliche Antwort und Einsicht in einige Überlegungen, an die ich nicht gedacht habe. Hoffentlich wird dies das letzte Bulk-Update sein, das ich machen muss. Wie ich in meinem Beitrag erwähnt habe, benutzten sie nicht einmal RHN (was sie kauften), also wird es wahrscheinlich schwieriger sein, die Anwendungsbesitzer an Bord zu bekommen, als die technische Arbeit :) - tdk2fe
@ tdk2fe: ​​Es ist immer so. :) Ehrlich, abhängig davon, was das Ding läuft, sollte es ziemlich stinkstabil sein. Ich würde mich viel weniger mit Anwendungen befassen, die nicht mehr funktionieren, als wenn ich die Dienste tatsächlich starten würde. - Scott Pack
Seien Sie nicht zu sehr besorgt über RHEL 5.7 vs 5.9, RHEL 5.9 ist nur RHEL 5.0 mit allen Updates seit, ausgeliefert fertig zur Installation. Es ist wirklich nicht notwendig, innerhalb der Serie zu "upgraden". Ich würde es empfehlen wenigstens Installieren Sie die Sicherheitsupdates und denken Sie ernsthaft darüber nach, den Rest gegebenenfalls zu installieren. Können Sie nicht eine virtuelle Maschine oder eine Testbox einrichten, in der die Hauptmaschine repliziert wird und nichts herausspringt? - vonbrand
@vonbrand: Richtig, genau. Die Point-Releases sind effektiv nur Tag-Cuts des Repos zu bestimmten Daten. Das heißt nicht dort Gewohnheit Probleme haben. Die gilbc Kerfuffle von 5.3 bis 5.4 ist ein fantastisches Beispiel. - Scott Pack
@ tdk2fe Ganz zu schweigen, wenn das System war nur seit einem Jahr nicht mehr gepflegt, geht es dir ziemlich gut. Die meisten von uns haben gesehen, dass Systeme jahrelang ohne Aufmerksamkeit bleiben ... - Michael Hampton♦


Meiner Erfahrung nach bricht RHEL die Abwärtskompatibilität nicht bei Updates mit identischen Versionen.

das wird sich jedoch nicht auf etwas erstrecken, das extern zu rpm installiert wurde.

Du könntest benutzen rpm -qf Um die Dateien zu finden, von denen Sie vermuten, dass sie extern kompiliert wurden, gibt es möglicherweise Probleme bei der Aktualisierung, wenn sie "nicht im Besitz eines Pakets" zurückgibt.

Ich würde ein Image des Servers machen und das Upgrade machen, ich bin ein wenig mehr Teufelskerl als die meisten.


3
2018-03-04 14:44



Guter Punkt. Überprüfen Sie, ob /etc/yum.repos.d hat einige seltsame Repositories konfiguriert (EPEL sollte sicher sein), installieren yum-utils und überprüfen Sie die Ausgabe von package-cleanup --orphans (Pakete installiert, die sich nicht in einem konfigurierten Repository befinden). - vonbrand