Things done wrong: Softwaremanagement

Homer Simpson
Ich widme mich diesmal in meiner Reihe zu Konzepten mit fundamentalen Fehlern dem Thema Softwaremanagement. Wenn ich von Softwaremanagement rede, meine ich damit üblicherweise den Roll-Out von Software und auch das Update und da ich mich meist auf Linux beziehe auch Paketierung. Ich werde mich diesmal bei Software-Empfehlungen und Vorgehen ausschließlich auf Linux beziehen, aber ich hoffe meine Aussagen lassen sich auch auf andere Betriebssysteme anwenden.
Meist sehe ich, dass dem Thema Softwaremanagement kaum Gedanken gewidmet wurden, wenn ich mich in IT-Landschaften bewege. Dies ist auch verständlich, denn irgendwann startete das Thema Linux als kleine Alternative zu Unix und Windows oder die Umgebung war eh nicht groß. Nun ja, mit Virtualisierung hat sich dann meist ein Wachstum ergeben und man war mit diesem beschäftigt. Im Anschluss kam dann (hoffentlich) die Automatisierung um die Systeme wieder besser handhabbar zu machen. Und nun steht man mit einer Vielzahl von Systemen da, die alle laufen, produktiv sind und die man am liebsten gar nicht mehr anfassen möchte. Aber nun kommt plötzlich die böse IT-Sicherheit ums Eck und erwartet dass alle Systeme sicher sind, was erstmal heißt auf aktuellem Software-Stand! Ich denke dies können die meisten nachvollziehen!
(mehr …)

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Softwaremanagement – Spacewalk – Raketentechnik?

Nachdem ich immer wieder gern im Zusammenhang mit Puppet erwähne, dass man sich zusätzlich zum Konfigurationsmanagement auch eine Lösung zum Softwaremanagement überlegen sollte, war es nur eine Frage der Zeit bis ich den Worten auch Taten folgen lassen durfte.
Aber zuerst möchte ich meine Aussage begründen. Für viele ist die Einführung eines Konfigurationsmanagement ein Moment sich nochmal gründlich mit seinen Systemen zu befassen. Dadurch dass Puppet eine Quelle benötigt um Software zu installieren und auch die Möglichkeit bietet diese aktuell zu halten, kommt oftmals die Frage auf woher die Software kommt. Bei den wenigsten Umgebungen haben alle Systeme direkten Internetzugriff, also muss eine lokale Quelle geschaffen werden. Dies ist mit ein bisschen Skripting leicht bewerkstelligt und der eigene Mirror steht.
Wie so oft stellt sich dann die Frage “Darf es etwas mehr sein?” Unter Softwaremanagment verstehe ich ähnlich wie bei Konfigurationsmanagement eine zentrale Lösung, die es mir erlaubt zu sehen welche Pakete installiert sind, Pakete zu verteilen und Updates einzuspielen. Letzteres möchte ich gegebenenfalls allerdings mit getesteten Ständen in Produktion machen und nicht mit tagesaktuellen Paketen. Wer sich nun denkt “Das ist immer noch leicht geskriptet”, bekommt dann noch die Aufgabenstellung hinzu dies für verschiedene Versionen einer Distribution und schlussendlich für gänzlich unterschiedliche Distributionen zu machen. Spätestens ab da möchte man eine fertige Lösung.
Eine dieser Lösungen heißt Spacewalk und ist das Upstream-Projekt zu den wohl bekannteren Lösungen Red Hat Network Satellite und Suse Manager. Die Aufgabenstellung beim Kunden war recht einfach die Lösung muss SLES verwalten und optional wäre Debian noch gut. Spacewalk kann dies für Fedora, CentOS, OpenSuse, SLES und mit Einschränkungen auch Debian und Ubuntu, leider offiziell kein RHEL.
Nun werden sich viele wundern warum kein RHEL, wenn es die Basis des Red Hat Network Satellite ist. Ich würde es einfach mal auf politische Gründe schieben, da man nur mit einer Satellite-Subskription ein Zertifikat bekommt, dass für die Anbindung nötig ist. Natürlich hätte ich Ideen wie man dies umgeht, aber dann wären wir wieder bei Skripting statt einer fertigen Lösung.
Die zweite Frage wäre nun welche Einschränkungen habe ich mit Debian und Ubuntu. Nun ja, speichern kann Spacewalk die Pakete problemlos, aber zum einen muss man um diese dorthin zu bekommen erst mal ein zusätzliches Skript installieren. Zum anderen klappt es mit der Metadaten-Erstellung nicht ohne einen Bugfix. Und zu guter Letzt benötigt auch der Client einen Bugfix, der aber schon in die nächste Version eingeflossen ist. Alles verständlich wenn man überlegt wie neu der Teil für Debian ist im Vergleich zum Rest des Codes.
SLES stellt auch noch eine kleine Hürde dar, da man hier die Zugangsdaten auf dem Novell Center benötigt. Diese lassen sich dann aber einfach in die URL integrieren. Frei zugängliche Repositories wie für Fedora, CentOS und OpenSuse stellen gar kein Problem dar.
Aber genug von den Einschränkungen wenn man sehen möchte was die Lösung kann, einfach der Anleitung folgend auf einem CentOS 6 ein paar zusätzliche Repositories eingebunden, die Setup-Pakete installiert, dem Setup ein paar Fragen beantwortet und einen administrativen Account erstellt.
Nun lassen sich Repositories erstellen, diese können in Softwarekanäle synchronisiert und Clients registriert werden, damit diese die Pakete sehen. Und zentral sieht der Admin welches System nicht auf aktuellem Stand ist und welche Pakete es betrifft.
Spacewalk Startseite
Übrigens ist die Registrierung mit einem Puppet-Modul relativ schnell geschehen, um den Kreis zum Einstiegspunkt Konfigurationsmanagement zu schließen.

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.