Bewährte Methoden zum Aktualisieren eines zuvor nicht verwalteten Servers RHEL5.7

Ein neuer RedHat EL5.6 Server wurde kürzlich unter meine Obhut genommen. Es ist sofort ersichtlich, dass in den letzten 12 Monaten keinerlei Aufmerksamkeit auf Paketaktualisierungen gelegt wurde.

Normalerweise bin ich der Meinung, wenn es nicht kaputt ist - repariere es nicht. Nach der Registrierung des Servers bei RHN und der Verwendung des yum-security-Plugins zum Überprüfen von Sicherheitsupdates sind jedoch nur mehr als 1100 Sicherheitsupdates verfügbar.

Hat jemand eine ähnliche Situation gehabt? Ich möchte nur ungern alles aktualisieren, da ich gerne wissen möchte, was aktualisiert wird und ob es die Möglichkeit hat, dass etwas auf der Box ausgeführt wird (dies ist ein Produktionsserver). Es sieht jedoch auch so aus, als müsste ich bei Einhaltung dieser Praxis zeilenweise die Errata von 1100 Paketen durchgehen. Gibt es eine effizientere Lösung?

Im Allgemeinen werden Sicherheitsupdates als etwas sicher angesehen, insbesondere für eine Distribution mit Zielen wie RedHat. Ihr Hauptaugenmerk liegt auf der Schaffung einer einheitlichen Betriebsumgebung. Als solche neigen die Betreuer dazu, Versionen von Paketen auszuwählen und für die Langstrecke bei ihnen zu bleiben. Um zu sehen , was ich Blick auf den Versionen solcher Pakete wie bedeuten kernel, python, perl, und httpd. Was sie auch tun, ist das Backportieren von Sicherheitspatches von den vorgelagerten Entwicklern. Wenn also eine Sicherheitslücke für alle Versionen von Apache httpd 2.2.x gefunden wird, veröffentlicht die Apache Foundation möglicherweise Version 2.2.40 mit dem Fix, aber RedHat wird den Patch lokal rollen und httpd-2.2.3-80mit dem Fix veröffentlichen.

Denken Sie auch daran, dass Sie derzeit über ein RHEL5.7-System sprechen. Die aktuelle Version ist 5.9. Einige Softwareanbieter unterstützen nur bestimmte Unterversionen. Ich bin kürzlich auf eine Software gestoßen, von der der Hersteller sagt, dass sie nur mit 5.4 funktioniert. Das bedeutet nicht, dass es nicht auf 5.9 läuft, aber es kann bedeuten, dass sie keine Unterstützung bieten, wenn es nicht funktioniert.

Es gibt auch Bedenken, Massenaktualisierungen eines Systems durchzuführen, das seit so langer Zeit nicht mehr gepatcht wurde. Das größte Problem, auf das ich gestoßen bin, ist eher ein Konfigurationsverwaltungsproblem, das nur durch große Aktualisierungen 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 aktuelle Konfiguration möglicherweise nicht mehr vorhanden ist. Wenn der Dienst also neu gestartet wird, was nach dem Anwenden der Kernel-Updates der Fall ist, wird er möglicherweise nicht neu gestartet. Oder es kann anders handeln , wenn es neu gestartet wird .

Mein Rat wäre, die Updates zu machen, aber schlau darüber zu sein.

• Planen Sie es während eines Wartungsfensters. Wenn für den Server kein Neustart erforderlich ist, wurden einige Kernel-Updates durchgeführt, und Sie müssen einen Neustart durchführen, um sie anzuwenden.
• Stellen Sie sicher, dass Sie eine vollständige Sicherung erstellen, bevor Sie etwas unternehmen. Dies kann ein Schnappschuss sein, wenn es sich um eine VM handelt, der eine vollständige Sicherung auf einem beliebigen Tool auslöst, einen Teer /(auf einem anderen System) erstellt, ein ddImage der Laufwerke erstellt, was auch immer. Nur solange es etwas ist, von dem Sie wiederherstellen können.
• Planen Sie, wie Sie die Updates anwenden. Du willst nicht einfach einen yum update -ydrauf werfen und weggehen. Für all die guten Dinge, die yum tut, ist es nicht in der richtigen Reihenfolge, wenn es Aktualisierungen gemäß den Abhängigkeiten anwendet. Dies hat in der Vergangenheit zu Problemen geführt. Ich laufe immer yum clean all && yum update -y yum && yum update -y glibc && yum update. Das kümmert sich in der Regel um die meisten potenziellen Bestellprobleme.

Dies ist möglicherweise auch eine gute Zeit, um die Plattform zu aktualisieren. Wir haben RHEL6 jetzt schon eine ganze Weile. Je nachdem, was dieser Server tut, kann es sinnvoll sein, diesen Server so laufen zu lassen, wie er ist, während Sie parallel eine neue Instanz aufrufen. Sobald es installiert ist, können Sie alle Daten kopieren, die Dienste testen und das Cut-Over durchführen. Dies gibt Ihnen auch die Möglichkeit, von Grund auf zu wissen, dass das System standardisiert, sauber, gut dokumentiert und der ganze Jazz ist.

Egal was Sie tun, ich finde es ziemlich wichtig, dass Sie sich mit einem aktuellen System vertraut machen. Sie müssen nur sicherstellen, dass dies so erfolgt, dass Sie Ihrer Arbeit und dem fertigen Produkt vertrauen können.

Meiner Erfahrung nach unterbricht RHEL die Abwärtskompatibilität in Updates derselben Version nicht.

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

Sie könnten rpm -qfdie Dateien finden, von denen Sie vermuten, dass sie extern kompiliert wurden. Wenn die Meldung "Nicht im Besitz eines Pakets" lautet, treten möglicherweise Probleme bei Ihrem Upgrade auf.

Ich würde ein Image des Servers machen und das Upgrade durchführen, aber ich bin ein bisschen teuflischer als die meisten anderen.