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!
Nun ja, an genau dieser Stelle beginnt für mich Softwaremanagement. Natürlich könnte man nun alle Systeme an das Internet anbinden und direkt die Pakete aus den Repositories der jeweiligen Distribution beziehen. Ok, dies ist vielleicht nicht der gängigste Weg! Aber das alles über einen Proxy gebündelt, weil man zum einen die Systeme nicht direkt an das böse Internet anbinden möchte und zum anderen ja auch etwas Bandbreite sparen möchte, kommt oft vor. Auch dass dann manche Pakete nicht verfügbar sind, weil diese einfach nicht durch den Proxy und seine Filtermechanismen durchkommen. Hier schonmal ein erster Rat: Softwarepakete und die Metadaten sind bei Linux signiert! Wenn man also Open Source im allgemeinen und seinem Distributor im speziellen vertraut, benötigt man hier also keinen Contentfilter oder Virenscanner. Und Vertrauen ist hierbei ja angebracht, schließlich verlässt man sich beim Betrieb seiner IT-Landschaft darauf.
Alle Systeme an die Online-Quellen angebunden, ist zwar besser als nichts, denn es erlaubt problemloses Updaten und Nachinstallieren von Software. Aber als nächstes muss man mitbekommen, dass Systeme nicht aktuell und Updates einzuspielen sind. Hier kann ein Monitoring-System helfen (beispielsweise Icinga mit check_apt/check_yum/check_zypper) oder eine dedizierte Lösung (beispielsweise Apt-Dater für Debian). Letzteres hat den Vorteil auch gleich noch den Update-Vorgang zu unterstützen.
Naja, und nun kommt der Punkt, an dem das oben ausgesprochene Vertrauen endet und Updates erst getestet werden sollen bevor sie in Produktion eingespielt werden. Meist ist der Grund für diese Anforderung, dass kommerzielle Software oder Eigenentwicklungen irgendwann mal nach einem Update nicht mehr liefen. Hierfür ist zwar meist nicht die Schuld auf Seite der Linux-Distribution zu suchen, aber am Ende hilft dies keinem wenn die Produktion still steht. Um nun ein Staging für die Updates zu ermöglichen braucht es zwei Dinge.
Als erstes muss die Verfügbarkeit von Updates geregelt werden können, also die Repositories lokal gespiegelt und versioniert werden. Hierfür können Eigenbau-Lösungen aus den Mirror-Tools der Distribution und eigenentwickelten Skripts zum Einsatz kommen oder genau dafür geschaffene Werkzeuge wie Spacewalk und Katello. Als zweites muss eine Möglichkeit geschaffen werden zwischen Produktionssystemen und den vorausgehenden Stages zu differenzieren. Wer hier feststellt er hat nur Produktionssysteme oder seine Testsysteme haben weniger Funktionalität als Produktion, hat entsprechenden Nachholbedarf, der sich hoffentlich dank Automatisierung aber in Grenzen hält.
Außerdem immer dran denken das Staging nicht so zu machen, dass es keine Möglichkeit gibt es zu beschleunigen. Denn irgendwann kommt der nächste Heartbleed oder Shellshock und ein Update muss auch in kürzester Zeit in Produktion eingespielt sein.
Und nun komme ich zu dem Punkt, wo für mich “Things done wrong” wirklich anfängt. Denn hat man nun so eine Lösung, die ich gebe es zu eine gewisse Komplexität besitzt, sollte diese auch optimal genutzt werden. Darum kann es für mich nur den Grundsatz geben alle Software kommt aus dieser Quelle. Trotzdem höre ich oft solche Sätze wie “Über den Satellite stellen wir nur Red Hat Pakete zur Verfügung”, “Die Pakete für Icinga laden wir runter, legen sie auf das System und installieren sie dann” oder “Perl-Module installieren wir mit CPAN”. Aber auch in die andere Richtung schlägt es manchmal aus “Also dieses Repository können wir aber nicht gleichzeitig mit jenem anbieten”. Beides ist nicht zielführend in meinen Augen!
Wenn ich also so ein Konzept erstelle oder implementiere, kläre ich als erstes ab was für Betriebssysteme und Quellen erlaubt sind. Beispielsweise setze ich mich bei Red Hat immer ein auch EPEL (Extra Packages for Enterprise Linux) mit anzubieten, da hiermit mehrere Tausend Pakete zur Verfügung stehen, für die zwar “nur” Community-Support verfügbar ist, die aber nach gleichen Standards wie bei Red Hat erstellt und gepflegt und auch keine supporteten Pakete von Red Hat ersetzen. Letzeres ist für mich dabei auch ein sehr wichtiges Kriterium. Deshalb setzen auch viele Repositories mit Zusatzsoftware darauf auf unter anderem RPMFusion oder Icinga. Auch diese Repositories gehören dann eingebunden, wenn solche Software verwendet wird.
Auch sehe ich immer einen Channel für selbst paketierte Software vor. Hier landet alles was an eigenen Paketen entsteht, aber dies heißt auch dass hierfür ein Maintainer vorzusehen ist, der sich auch um Updates kümmert. Denn ein einmaliges Erstellen und Verfügbar machen ist noch kein Softwaremanagement. Davon Software-Pakete neu zu bauen oder auch neu zu signieren halte ich wenig. Diesbezüglich schlimmste Aussage war “Wir bauen die Pakete aus EPEL selber nach, die wir brauchen, weil dort kennen wir den Maintainer ja nicht”. Wenn man dies aber für Software machen will, die in Paketform vorliegt aber kein Repository anbietet trotzdem machen will, sehe ich hierfür einen separaten Channel vor. Und natürlich unter der gleichen Maßgabe, dass die Pakete gepflegt werden.
Natürlich ist die richtige Pflege und das Paketieren im ersten Moment mehr Aufwand, aber nur so lässt sich im Endeffekt sicherstellen, dass Sicherheitslücken überall geschlossen sind, gleiche Versionen in Test und Produktion liegen und im Endeffekt ein reibungsloserer Betrieb möglich ist. Auch Konfigurationsmanagement und Automatisierung profitieren hiervon nicht unerheblich. Und mit Hilfsmitteln wie rpmdevtools, cpanspec, R2spec, Tools wie mock zum Bauen für verschieden Architekturen und Version und den Paketrichtlinen der Distributionen hält sich der Aufwand auch in Grenzen.
0 Comments