Wie oft sollte ich unseren Linux-Server aktualisieren?


56

Ich bin sowohl für die Verwaltung unseres Produktionsservers (Mail, Web, Datenbank sind alle auf einem Server) als auch unseres Testservers verantwortlich. Beide basieren auf Debian. Da ich in der Systemadministration noch sehr jung bin, habe ich nur Aktualisierungen installiert, wenn ich auf Dinge gestoßen bin, die aktualisiert werden müssen, damit ich neuere Funktionen und Fehlerbehebungen erhalten kann. Es ist gerade ein hübscher Ad-hoc-Prozess, und ich würde es gerne weniger machen.

Ich frage mich also, wie Leute, die wissen, was sie tun, damit umgehen? Wie oft führen Sie Upgrades auf Ihren Servern durch? Unterscheidet sich der Upgrade-Prozess zwischen Test und Produktion? Aktualisieren Sie immer zuerst Testserver? Und führen Sie ein vollständiges Update der gesamten Software durch oder installieren Sie nur ausgewählte Updates?

Antworten:


34

Ich führe apt-get update -qq aus; Apt-Get Upgrade -duyq täglich. Dadurch wird nach Updates gesucht, diese jedoch nicht automatisch durchgeführt.

Dann kann ich die Aktualisierungen manuell ausführen, während ich sie ansehe, und alles korrigieren, was schief gehen könnte.

Abgesehen von den Sicherheitsbedenken bei der Wartung eines gepatchten Systems stelle ich fest, dass zwischen den einzelnen Patches eine ganze Reihe von Paketen auftauchen , die aktualisiert werden sollen zwei jede Woche oder so. Daher neige ich dazu, meine Upgrades wöchentlich oder, wenn sie hohe Priorität haben, täglich durchzuführen. Dies hat den zusätzlichen Vorteil, dass Sie wissen, welches Paket Ihr System beschädigt hat (dh, wenn Sie nur ein paar auf einmal aktualisieren).

Ich aktualisiere immer zuerst weniger kritische Systeme. Ich habe auch einen "Rollback-Plan", falls ich das System nicht reparieren kann. (Da die meisten unserer Server virtuell sind, besteht dieser Rollback-Plan normalerweise darin, vor dem Upgrade einen Snapshot zu erstellen , auf den ich bei Bedarf zurückgreifen kann.)

Abgesehen davon denke ich, dass ein Upgrade in den letzten 4 Jahren nur ein oder zwei Mal etwas kaputt gemacht hat und dass es sich um ein hochgradig angepasstes System handelte - man muss also nicht ZU paranoid sein :)


4
Ich arbeite sehr hart, um jeden Server alle 30 Tage zu berühren. Ich habe zu diesem Zeitpunkt über 80 Server. Ich mache sie in Stapeln nach Funktionsgruppe oder nach Betriebssystem.
Thomas Denton

2
Wir haben ein Cron-Skript, das jede Nacht das Äquivalent für unsere SLES / OpenSuSE-Boxen ausführt. Wenn es feststellt, dass es Pakete benötigt, sendet es ein Ticket an die Systemverwaltungswarteschlange in unserem Trouble-Ticket-System. (Es verfolgt, welche es zuvor in einer Datei in / tmp übermittelt hat, damit es die Warteschlange nicht
spammt

4
Debian hat zwei Pakete, apticron und cron-apt, die eine ähnliche Funktion haben und Sie per E-Mail benachrichtigen, wenn Updates verfügbar sind. IME, apticron hat den Vorteil, dass Sie das Changelog per E-Mail erhalten, damit Sie sehen können, was sich geändert hat.
David Pashley


6

Vorausgesetzt, Sie führen die stabile Version von Debian aus, sind die meisten Patches sicherheits- oder fehlerbezogen, was bedeuten sollte, dass es zwischen den Versionen eines bestimmten Pakets nicht zu viele größere Änderungen gibt. Laut Debian-Patch-Policy sollten Patches auch einige Zeit im Test gewesen sein, bevor sie vom Betreuer in den Stable-Zweig verschoben wurden. Offensichtlich stoppt dies keine Brüche beim Patchen, sollte sie aber in den meisten Fällen verhindern.

Es ist ratsam, sicherzustellen, dass Ihr Testserver auf dem neuesten Stand ist und dass alle Pakete, bei denen Fehler auf Sie und Ihre Server zurückzuführen sind, auf dem neuesten Stand sind. Alle Pakete mit Sicherheitshinweisen sollten aktualisiert werden, sobald Sie wissen, dass der Patch stabil ist.

Debian ist normalerweise ein sehr stabiles Betriebssystem, und Sie sollten sich nicht übermäßig um Brüche kümmern, sondern immer lesen, was aktualisiert werden soll, bevor es aktualisiert wird, und nach etwas Ausschau halten, das seltsam erscheint. Ich verwende VCS auch in meiner Datei / etc / dir, um sicherzustellen, dass alle Änderungen an der Konfigurationsdatei mit dem Befehl 'git diff' angezeigt werden.


3

Ich mache einen Probelauf (zuerst), um zu sehen, was aktualisiert wird. Manchmal ändern Bibliotheken (nennen wir es in diesem Beispiel libfoo) ihre API, wodurch selbst geschriebene / installierte Programme beschädigt werden. Wenn eine wichtige Bibliothek aktualisiert wird, greife ich nach dem Quellcode und versuche, unsere Daten vor der Aktualisierung erneut zu erstellen.

Ich überprüfe auch, ob wir nicht zu einer Zwischenversion eines öffentlichen Dienstes (z. B. Apache) wechseln. Ich möchte lieber ein Jahr zurückbleiben und keine zufälligen Fehler feststellen, es sei denn, das Update ist kritisch.

Wenn Sie ein Systemadministrator sind, sollten Sie RSS-Feeds von Websites wie Secunia abrufen , um rechtzeitig zu erfahren, ob Ihre Distribution Patches bereitstellt .

Nie, nie nur blind upgraden / updaten. Leider liegt die Aufgabe, zu wissen, was defekt ist, bei Ihnen und nicht bei Ihrem Distributionspaket-Manager, insbesondere wenn Ihre Systeme Programmierer unterstützen.


2

Wo ich arbeite, haben wir einen ziemlich umfangreichen Prozess, bei dem PatchLink verwendet wird, um uns über die wichtigsten sicherheitsrelevanten Updates zu informieren, und wir wenden sie nach dem Testen Paket für Paket an. Wir haben jedoch Tausende von Servern.

Wenn Sie nur zwei Server haben, sollte der Vorgang viel einfacher sein. Obwohl ich nicht der Meinung bin, dass ein "passendes Update / Upgrade" die beste Wahl ist.

Ich würde Patches für die Software überwachen, die Sie ausführen, und Entscheidungen basierend auf den Fixes in diesen Releases treffen, wenn ein Upgrade durchgeführt werden soll.

Da Sie einen Testserver haben, testen Sie das Update natürlich immer, bevor Sie es anwenden.


2

Manuelle Updates sind am besten, wie hier erwähnt, in dem Sinne, dass Sie sehen können, was passiert. Bei sehr vielen Servern kann dies jedoch unpraktisch werden. Trockenlauf ist eine Standardpraxis. Tatsächlich werden Sie von den meisten Paketmanagern gefragt, bevor Sie fortfahren.

Regelmäßige Aktualisierungen sind in der Regel am besten, obwohl dies ein Balanceakt sein kann. Häufige Updates bedeuten weniger in einem Zug und weniger Fehler auf einmal. Wenn etwas schief geht, gibt es weniger Kandidaten, die überprüft werden müssen. Pakete können auch etwas besser in kleineren Schritten aktualisiert werden, da im Allgemeinen, wenn der Programmierer nach Updates sucht, die von der letzten Version zur nächsten wechseln, die Frage, ob er über die letzte Version hinaus Aufmerksamkeit schenkt, variieren kann, obwohl dies in der Regel eine Rolle spielt Hauptsächlich für Software, die sich schnell entwickelt.

Nicht alle Updates sind unterbrechungsfrei. Sie werden darauf achten wollen. Einige starten die Dienste neu, was zu Ausfallzeiten führt.

In einem idealen Setup könnten Sie Folgendes haben:

  • Ein Mittel, um scheinbar zwischen Servern zu wechseln (A / B oder Tick Token). Das heißt, Sie aktualisieren eine, während sie auf der Bank ist, und tauschen dann einfach den Verkehr von der aktuellen auf die neue. Dies kann für Dienste wie Datenbanken komplizierter sein.
  • Die Möglichkeit, Updates zu testen. Sie sollten Testserver haben, die praktisch Klone der Produktion sind (aber keine Verbindung zu Produktionsdiensten herstellen). Auf diese Weise können Sie zuerst Aktualisierungen testen.
  • Eine gute Backup-Strategie, inkrementell ist ideal. Man weiß nie. Es ist immer besser als Nachsicht.
  • Achten Sie darauf, welche Zeiten am aktivsten sind und welche Ausfallzeiten tolerierbar sind.
  • Wissen, wie ein Update oder ein bestimmtes Paket zurückgesetzt werden kann.
  • Verwenden Sie Ihre eigenen Paketspiegel, damit Updates auf allen Servern konsistent und vorhersehbar sind. Dies ist der erste Schritt in Richtung eines anständigen unbeaufsichtigten Systems, dem Sie vertrauen können. Dies bedeutet, dass Sie den Spiegel aktualisieren und das Update auf einem oder mehreren Testcomputern ausführen können. Ist dies der Fall, wird es automatisch gelöscht. Ich hatte eine großartige Zeit mit der treffenden Verwaltung von rund 800 EPOS-Maschinen.
  • Ein gutes Maß an Konsistenz, damit Sie wissen, dass, wenn hier etwas funktioniert, es dort funktioniert.

Einige davon können bei kleinen Aufbauten in unterschiedlichem Maße überfordert sein, sollten jedoch beachtet werden.

Im Allgemeinen sind Updates für Server-Distributionen in der Regel relativ problemlos. Dies liegt daran, dass sie sich fast immer nur an Fehlerbehebungen und Sicherheitsupdates halten. Möglicherweise haben Sie jedoch Probleme, wenn andere Benutzer ungewöhnliche Dinge am System vorgenommen haben oder Sie zusätzliche Paketquellen hinzufügen.

Obwohl es mäßig selten ist, machen sie gelegentlich Fehler und brechen die Kompatibilität zwischen kleineren Paketversionen.


1

Ich mag es, wenn cron-apt diesen Prozess automatisiert, aber wie @dinomite auf eine andere Frage in Bezug auf Aktualisierungen hingewiesen hat, ist es eine sehr clevere Idee , es speziell für die Automatisierung sicherheitsrelevanter Aktualisierungen zu konfigurieren - Sie können dann manuell aktualisieren, was Sie benötigen. Ich hatte cron-apt für alle Aktualisierungen verwendet, dies jedoch basierend auf seiner Antwort geändert. Wenn du es magst, solltest du seine Antwort wahrscheinlich besser abstimmen als diese.


1

Unter Debian installiere ich cron-apt und bearbeite seine Konfigurationsdatei, um mich zu benachrichtigen, wenn sich etwas ändert. auf diese weise werde ich benachrichtigt, wenn es updates für meine systeme gibt und mache die updates von hand


1

In Anlehnung an cron-apt sollten Sie sich das Paket für unbeaufsichtigte Upgrades anschauen: http://packages.debian.org/lenny/unattended-upgrades .

Es ist sehr einfach zu konfigurieren und ermöglicht es Ihnen, Sicherheitsupdates automatisch herunterzuladen und anzuwenden, aber andere Updates für die manuelle Aktualisierung zu belassen (oder alles nach Ihrem Ermessen zu aktualisieren!).

Das Offizielle Ubuntu-Serverhandbuch enthält einen recht detaillierten Abschnitt über die Verwendung des Pakets für unbeaufsichtigte Upgrades ( https://help.ubuntu.com/9.04/serverguide/C/automatic-updates.html)

Hinweis: Abhängig von Ihrer Vorsicht / Paranoia können Sie zuerst ein laufendes Upgrade auf einer Gruppe von Testservern durchführen. Wenn keine Probleme auftreten, lassen Sie die Aktualisierung Ihrer Produktionsboxen zu, obwohl ich persönlich keine Probleme mit Sicherheitsupdates festgestellt habe Bisheriges Chaos (auf Holz klopfen) ...

Es gibt auch eine Konfigurationsoption, mit der Sie die Ergebnisse jedes Sicherheitsupdates per E-Mail erhalten, sobald es angewendet wurde. Wenn während des Updates Dialogfelder oder interaktive Eingabeaufforderungen angezeigt wurden, die von einem Systemadministrator manuell angepasst werden müssen, werden diese ebenfalls erwähnt.


1

Ich persönlich deaktiviere automatische Updates und aktualisiere Pakete auf Servern in meinen Umgebungen nicht regelmäßig, es sei denn: (a) es gibt eine wichtige CERT-Empfehlung für eines der Pakete auf meinem System; (b) Ich muss einzelne Pakete aus bestimmten Gründen aktualisieren. (c) Betriebssystem oder Pakete haben das Ende des Zyklus erreicht, sie werden nicht mehr unterstützt und wir müssen weiterhin Unterstützung erhalten. Mein Grund dafür ist, dass ein Upgrade durchgeführt wird, ohne zu wissen, was geändert wird oder warum zu viel Platz bleibt, damit etwas kaputt geht. Ich mache seit 14 Jahren so etwas und es funktioniert gut.


0

Neben den genannten Dingen sollten Sie eine Art Überwachungstool (Nagios oder was auch immer auf Ihrem Boot schwimmt) verwenden, um Sie über Aktualisierungen zu informieren.

So oft es geht: Sobald ein Update verfügbar ist!

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.