Zentrales Update-Management für Linux

Firewire2002

Firewire2002

Registered User
Hallo,

ich bin (privat) auf der Suche nach einem zentralen Update-Management mit Webinterface für Linux Systeme.
Von Red Hat kennt man bereits das Satellite-System und Canonical hat für Ubuntu Landscape entwickelt. Allerdings sind mir beide Lösung etwas zu komplex und ich möchte nicht von der Distribution abhängig sein.

Eingesetzt wird vorzugsweise Debian und CentOS. openSUSE oder Fedora könnten aber ebenso dabei sein. Es wäre daher praktisch, wenn die Lösung direkt yum, apt, zypper oder deren API nutzen würde.
Größtes Hinderniss an der Geschichte: Es darf kein SSH zwischen "Update-Client" und "Management-Server" erforderlich sein. Die "Clients" könnten hinter einem NAT hängen. So dass die Lösung hier mit Agents oder Cronjobs auf den Clients arbeiten müsste, um nach Updates zu suchen, zu installieren, usw.

Die großen Lösungen von IBM und HP (die ebenfalls wieder weitaus mehr können, als nur Updates verwalten) sind mir ein bisschen zu teuer. :)
Ich such daher eher bevorzugt etwas kleineres freies/kostenloses.

Gewünschte Features nochmal zusammen gefasst:
- zwischen Update-Client und Management-Server kein SSH
- Webinterface
- tauglich für die gängigen Linux Distributionen
- Updates auflisten
- Updates installieren (einzelne Updates / alle Updates für einen Host / alle Updates für alle Hosts)

Optional:
- Hostgruppen
- Benutzerverwaltung
- Bereichtigungsvergabe für einzelne Hostgruppen
- Installation weiterer Packages aus den Repos der Distribution

Ich hab schon überlegt sowas selbst zu bauen. Allerdings ist die Zeit im Moment etwas knapp und meine Programmierkenntnisse sind auch nicht unbedingt auf dem Niveau, einen derart sicherheitskritischen Task sauber zu implementieren.
Sollte ja nicht jeder einfach Updates freigeben dürfen. :p

Ist euch in dieser Richtung irgendeine Software bekannt?

Gruß
Firewire2002
 
Naja, die ganzen Configuration Management Lösungen lassen sich auch für Updatepflege missbrauchen. Sind aber (wenn man es allein für die Updates verwendet) ziemlich komplex und umständlich.

Mittlerweile sind die ersten 500 Code Zeilen für die Selbstbau Lösung schon getippt. Ich denke es wird wohl nun letztendlich auch darauf hinaus laufen, wenn ich mir die überwältigende Anzahl an Antworten hier anschaue. :(
 
Sorry für die Leichenfledderei, aber das Thema ist bei mir gerade aktuell...
Hast Du damals was gefunden?

Grüße
Basti
 
Leider nein. Obwohl meine Eigenbaulösung zwar technisch funktionsfähig war. Habe ich die Entwicklung mangels Zeit eingestellt. Die Lösung ist leider nicht produktiv einsetzbar. Dafür fehlt noch zuviel.

Mittlerweile sind wir auf SaltStack ausgewichen. Schön ist anders. Aber damit lassen sich zumindest recht schnell die Updatestände abfragen und die Packages einspielen. Auch wenn SaltStack an dem Punkt nichts weiter macht, als man mit einer for i Schleife und dem ssh Client ebenfalls könnte. ;)
 
Die Anforderungen klingen eigentlich fasst 100% nach Puppet. Was sprach denn gegen dieses und für SaltStack?
 
Puppet scheint mir für reines Patch-Management genauso ungeeignet wie SaltStack, nur dass letzteres warscheinlich besser für Orchestration geeignet zu sein scheint. Ich kann mich da aber auch täuschen :D

Ich hab mir heute beim Recherchieren auch mal SaltStack genauer angesehen, und mein aktueller Plan sieht auch eine Bastel-Lösung vor:

- Salt Master fragt die Minions regelmässig nach ausstehenden Patches ab
- Diese werden auf dem Master in eine Datenbank geschrieben
- In einem Webinterface kann ich mir die aggregierten Daten ansehen, und Patch-Aufträge zusammenklicken (nach Gruppen oder einzelne Server)
- Ein Batch-Job prüft im Hintergrund die Datenbank nach Jobs, und patcht die Server via Salt
- Die Ausgaben der Jobs werden wiederrum in die Datenbank geschrieben, damit sie im Webinterface sichtbar sind

Das schreit leider alles nach sehr viel Handarbeit...
 
Da muss ich traced zustimmen. Puppet ist dafür genauso ungeeignet. Bzw. endet es im gleichen "Gefrickel" wie mit SaltStack.

Die Variante mit Datenbank und Webinterface haben ein paar Kollegen auch laufen. Machbar ist das. Aber es gibt eben nichts fertiges, was man einfach einsetzen kann.
Alle großen Player bauen sich was eigenes. Aber keiner wirft es mal mit einem aktzeptablen Preis auf den Markt. :(
 
wieso sollte Puppet für Patchmanagement ungeeignet sein? Gerade das ist doch eigentlich neben dem Konfigurationsmanagement einer der Punkte, die sich damit recht einfach abfrühstücken lassen?
 
Für einzelne, von Hand definierte Pakete mag das bei Puppet richtig sein, aber wie würdest Du es bei ~800 möglichen Paketen auf einem Debian/Ubuntu Server damit handhaben?

Versteh mich nicht falsch, ich bin kein SaltStack vertreter... ich bin einfach auf der Suche nach einer geeigneten Lösung um mittlerweile ~50 Linux Server aktuell zu halten.
 
Die Anforderungen sind ja grundlegend überall andere - aber "wir" halten es so, daß die Grundpackete vom System über dieses aktualisert werden.

Puppet würden wir (wir sind gerade selber am überlegen, was man so für div. Tasks einsetzen können und bisher sieht Puppet als die passende Lösung aus) im Paketmanagement-Part dann dafür verwenden, sich um die ded. "Sonderpakete" der jeweiligen Server kümmern, also das, was über die reine Grundinstallation hinaus geht.
 
Liest du eigentlich die ganzen Beiträge oder nur das, was dir nicht passt? ;)

Natürlich ist es mit Puppet möglich. Genauso wie mit SaltStack. Mit eben den beschriebenen Selbstbauten drumherum.
Patchmanagement heißt nicht "ich prügel einfach mal Updates drauf". Patchmanagement heißt, ich brauche Reports, welche einzelnen Updates, in welcher Version (alt/neu), auf welchem System zur Verfügung stehen.
Ebenso gehören Funktionen dazu, bestimmte Packages in bestimmter Version auf einem gezielten System oder einer Teilmenge oder alle Server zu installieren.

Dafür wird eben auch ein gewisses Frontend benötigt. Das bietet Puppet schlicht nicht. Das ist eben ein Konfigurationsmanagement was man für sowas als Backend missbrauchen kann. Aber die nützlichen Funktionen die Puppet für das Patchmanagement brauchbar machen, muss man selbst bauen.

Wenn du da was fertiges kennst, was öffentlich verfügbar bzw. vertrieben wird, dann sag an. Aber hör bitte auf mit Einzeilern zu argumentieren ohne eine fertige Lösung anzubieten.

Hier geht es nicht darum, etwas selbst zu frickeln. Das machen die Leute die es betrifft, schon und können das fachlich auch. Wir wollen hier eine fertige Lösung die man einfach einsetzen kann. Siehe ersten Beitrag.
 
Firewire2002 said:
Gewünschte Features nochmal zusammen gefasst:
- zwischen Update-Client und Management-Server kein SSH
- Webinterface
- tauglich für die gängigen Linux Distributionen
- Updates auflisten
- Updates installieren (einzelne Updates / alle Updates für einen Host / alle Updates für alle Hosts)
Click to expand...

Ich bin gerade dabei, diese Features mit SaltStack, Python und einem kleinen PHP Frontend umzusetzen.
Sollte das alles zufriedenstellend laufen, kann ich Dir gerne mal eine kleine Preview schicken, das wird aber noch ein paar Tage dauern.
 
Jo sobald es etwas vorzeigbares gibt, mit dem ich mich nicht total als Programmier Noob oute dann gerne :D

Aktuell sind es drei Komponenten:
- 1 Python Modul fragt über SaltStack alle Server nach OS-Typ und offene Updates ab (aktuell per Cronjob)
- 1 PHP Webinterface für Übersicht aller Updates/Server, und Zusammenstellung von Update-Jobs
- 1 Python Modul fragt die SQLite Datenbank nach fälligen Jobs ab, und führt die Updates über SaltStack aus (auch per Cronjob)

SQLite sollte restmal dicke reichen, es passieren ja nicht viele gleichzeitige Zugriffe.

Mal gespannt ob das dann auch so funktioniert, wie ich mir das vorstelle ;)
 
traced said:
Ich bin gerade dabei, diese Features mit SaltStack, Python und einem kleinen PHP Frontend umzusetzen.
Click to expand...

storvi said:
Überlege auch, das umzusetzen - allerdings mit SaltStack, Python und Flask (oder Django)
Click to expand...

Macht doch ein Gemeinschaftsprojekt draus...Bedarf scheint ja vorhanden zu sein.
Vllt. finden sich ja noch mehr Unterstützer hier... ;)
 
Bezahlen lassen will ich mich nicht dafür, dann müsste ich das auch supporten oder maintainen. Wenn es was wird, dann landets auf GitHub.
Wem es dann was wert ist, der kann ja immer noch was in meine Bitcoin Wallet schmeissen :D
 
Also falls du Interesse an meinem alten Code hast, gib Bescheid. Der basiert auch auf Python (im Backend) + PHP (im Frontend).
Nur das ich einen eigenen Agent gebaut habe. Gerade die Anbindung der Paketverwaltung (apt/dpkg ist da ziemlich fies) dürfte sich aber recht einfach klauen lassen. ;)

Code ist komplett objektorientiert geschrieben.
 
You must log in or register to reply here.
Back
Top