Security Updates autom. einspielen lassen (Ubuntu Server) Erfahrungen?

Hallo zusammen (und noch mal ein verspätetes frohes Neues),

bei der Installation von Ubuntu Server gibt es die Möglichkeit, die Auswahl zu treffen, dass man Sicherheitsupdates auf einem System automatisch einspielen lassen möchte.

Meine Frage wäre, ob jemand Erfahrungswerte dazu hat wie sich soetwas in einem Produktivbetrieb verhält.

Momentan ist es so, dass ich tatsächlich meine Server nur über apt upgrade aktualisiere. Das hat natürlich zur Folge, dass meine Applikationen generell angehoben sofern ich sie nicht explizit ausschließe. Den Aktualisierungsprozess habe ich zwischenzeitlich im Griff, so dass ich nicht mehr ganz so viele Schweißperlen auf der Stirn habe wenn ich ein Upgrade durchführe ;) ... trotzdem hätte es schon Charme wenn sich Sicherheitsupdates automatisch einspielen würden und ich die Zyklen für Software Upgrades dadurch deutlich vergrößern könnte. Ich brauch ja nicht immer die neusten Funktionen die gerade frisch aus dem Compiler gepurzelt kommen.

Ich gehe mal davon aus, dass die Sicherheitsupdates tatsächlich nur das Betriebssystem betreffen und nicht die Applikationen, die ich ggf. noch hinzufüge. Trotzdem würde ich gerne wissen, ob ich beim automatischen einspielen befürchten muss, dass sich Server Applikationen dann zerschießen. Wenn ich bei einem Upgrade nicht alle Dienste etc. sauber beende und die Configs nicht überprüfe/ggf. anpasse, geht in der Regel erstmal gar nichts mehr. Und das würde ich im Produktivbetrieb gerne vermeiden.

Wie handhabt ihr das?

Vielen Dank für eure Erfahrungen :) !

Viele Grüße

Ark
 
Die Sicherheitsupdates betreffen üblicherweise alle über den Paketmanager installierten Programme sowie den Kernel. Aber selbst wenn dafür nur 'unattended-upgrades' ausgeführt wird, sind auch Libs wie die libc sowie der Kernel betroffen. Von daher würde ich von einem Auto-Update bei Servern abraten, denn einige der Updates (libc, Kernel etc.) machen einen Reboot notwendig. Der wird zwar durch Auto-Updates üblicherweise nicht ausgelöst, kann aber bei der Verwendung von Programmen, die bestimmte Libs nur zu bestimmten Zeiten laden, ggf. direkt nach dem Update zwingend notwendig sein, da sie sonst ggf. crashen. Manuell geänderte Configs werden üblicherweise durch Sicherheitsupdates nicht überschrieben.

Wenn du mal eine Weile beobachten willst welche Programme und Libs durch Security-Updates betroffen sind, kannst du einfach mal vor deinem Update ein 'apt-get install unattended-upgrades' ausführen. Dann siehst du, was durch ein Auto-Update eingespielt werden würde.

Wenn dir das Einspielen von Updates zu viel Aufwand darstellt, solltest du ggf. überlegen ein Rollout-System wie R(?)ex - (R)?ex - A simple framework to simplify system administration and datacenter automation - o.ä. zu verwenden, mit denen du Updates auf allen Systemen gleichzeitig anstossen kannst. So sparst du dir schon eine Menge Zeit und das Updaten deiner Server-Flotte beschränkt sich auf 1-2 Befehle auf deiner Admin-Station. Mit den richtigen Task-Definitionen vermeidest du damit auch ungewollte Updates. Kannst ja die Tasks jedes zu installierende Paket manuell bestätigen lassen.
 
Guten Morgen Bitmuchner,

vielen Dank mal wieder für die vielen Informationen.
Ich werde es dann wohl erstmal nicht aktivieren, aber aus Interesse mir mal die Veränderungen durch unattended-upgrades anschauen.

(R)?ex schaue ich mir mal an :) ...

Viele Grüße

Ark
 
R(?)ex kann ich jedenfalls total empfehlen. Vereinfacht meinen Job derzeit enorm. Da man damit alles machen kann, was Perl kann (neben den Rex-spezifischen Features), kann man damit auch so lustige Dinge tun wie dynamische Hostlisten für Cloud-Umgebungen generieren, Paketlisten aus Outputs abfangen und sie dann einzeln bestätigen und installieren uvm.. Ich nutze es daher mittlerweile als "Erweiterung" für diverse CLI-Tools, die ich auf mehreren Hosts ausführen muss.
 
Hi Bitmuncher,

ich habe mir gerade eine Präsentation zu (R)?ex auf Youtube angeschaut. Ehrlich gesagt erinnert mich diese deklarative Schreibweise schon sehr an Puppet, allerdings scheint das Konzept ja dennoch ein anderes zu sein. Kannst du das vll. in einem Satz abgrenzen wo da im Doing der Unterschied liegt?

Ich werde mir (R)?ex aufjedenfall nach der Klausurphase mal in meiner Testumgebung Zuhause in ruhe zu Gemüte führen. Da ich zufällig gerade im Abendstudium Perl gelernt habe und darüber Samstag eine Klausur schreibe, bietet es sich ja an die Kentnisse ein bisschen praktisch zu festigen und damit mal was zu machen :) ...

Vielen Dank.
 
Zuletzt bearbeitet:
Die deklarativen Elemente sind mit Absicht an andere Rollout-Systeme wie Puppet und Chef angelehnt. Der Unterschied besteht aber darin, dass du sämtlichen Perl-Code darin auch verwenden kannst, so dass dir die Weiten des Perl-Universums uneingeschränkt zur Verfügung stehen. Du bist also nicht auf die Deklarationen angewiesen und musst nicht für jeden Furz eigene Erweiterungen schreiben sondern kannst auf existierende Perl/CPAN-Module zugreifen. Bei Chef mit seinen vielen Einschränkungen bei Ruby ist sowas drastisch umständlicher.

So kannst du z.B. Prozesse von Datensätzen in Datenbanken abhängig machen oder die Hostlisten anhand von Netzwerk-Scans automatisch generieren lassen. Ein Beispiel dafür habe ich vor einiger Zeit mal in http://bitmuncher.subnetworx.de/2014/09/30/dynamische-host-liste-fuer-rex-deployment/ beschrieben. Ein Beispiel aus meiner Praxis: Ich habe mit meinen Kunden Zeitfenster für Systemupdates ausgemacht. Führe ich nun eine Task für ein Systemupdate aus, schaut diese in der DB nach ob sie sich im richtigen Zeitfenster befindet. Wenn nicht, bekomme ich eine Meldung, dass ich mich nicht im vereinbarten Zeitfenster befinde und der Prozess wird abgebrochen.

Ein paar der Vorteile von Rex gegenüber Systemen wie Puppet habe ich auch in http://bitmuncher.subnetworx.de/2014/06/18/einfuehrung-die-automatisierung-mit-rex/ im letzten Absatz mal aufgeführt. Kurz zusammengefasst: Man kann es auch nutzen um mal schnell Befehle auf einer Reihe von Servern auszuführen oder Entwicklern die Möglichkeit zu geben die Deployments selbst zu steuern, indem sie in ihren Projektordnern einfach ein Rexfile bereitstellen (ähnlich wie die Jenkinsfiles von Jenkins).
 
Ehrlich gesagt rennst du da bei mir wirklich offene Türen ein, denn das ist etwas, dass ich an Puppet wirklich schon oft vermisst habe. Um die Prozesse in unserer Firma in Puppet nachzubilden musste ich schon diverse Ressource-Types bis hin zu ganzen Providern in Ruby selbst schreiben und einige davon nur, weil man in den .pp files nur deklarieren und ansonsten so gut wie keine Sprachfeatures der Ruby API nutzen kann sondern nur die Puppet DSL. Allein schon den Update-Prozess unserer Software in verteilten Umgebungen geregelt ablaufen zu lassen, ist in Puppet gefühlt ein riesiger Workaround da man sich dem Puppet Paradigma halt vollständig "unterwerfen" und alles aus der Clientperspektive sehen muss ... Das hatten wir an anderer Stelle mit selbstgestrickter Software die "von außen" einwirkt schon mal deutlich eleganter und vor allem transparenter für den Administrator.

Ein "leichtgewichtiges" Automationsframwork mit ähnlichen Ansätzen aber mehr Freiheiten hört sich sehr gut an um auch kleinere Prozesse (ohne Code Massen durch Provider und Types) sinnvoll weg zu automatisieren und vielleicht kriege ich damit eine sinnvolle Update Automatik für meine Linux Server auf die Reihe.

Vielen Dank! :)
 
Zuletzt bearbeitet:
Zurück
Oben