Spacewalk 2.4 veröffentlicht

Diese Woche wurde Spacewalk nach 6 Monaten Entwicklungszeit in der Version 2.4 veröffentlicht. Insgesamt wurden knapp 60 Bugs behoben und einige neue Features implementiert.

Die verwendete Web-Oberfläche wird jetzt als Patternfly-Framework auch anderen Projekten zur Verfügung gestellt. Das maßgeblich durch Red Hat unterstützte Projekt hat es sich zur Aufgabe gemacht, besonders ansprechende Designs mit Twitter Bootstrap zu kombinieren, um leicht Enterprise-Administrationsoberflächen zu generieren. Selbstverständlich lassen sich Ansichten auch auf mobilen Endgeräten, wie beispielsweise Smartphones oder Tablets, komfortabel bedienen.

Pro Spacewalk-Organisation können nun einige Einstellungen abweichend vom Standard konfiguriert werden, darunter:

• Content Staging aktivieren/deaktivieren
• Softwareabsturz-Meldungen aktivieren/deaktivieren, Größe limitieren
• Verwendung von SCAP-Tests aktivieren/deaktivieren

Ebenfalls neu ist die Unterstützung von Fedora 22 als Client-System. In diesem Zuge wurde ein entsprechendes Plugin für die neue DNF-Paketverwaltung entwickelt - es muss also nicht mehr zwingend YUM verwendet werden. Für Enterprise Linux 7-Systeme (CentOS, ScientificLinux, Oracle Linux) wurden einige Cobbler-Bugs behoben. Eingebundene Software-Kanäle müssen nun zwingend eine Prüfsumme verwenden (sha1, sha256, sha384 oder sha512). Bisher gab es für Legacy-Systeme (vor EL5) noch die Möglichkeit dies zu deaktivieren. Abgeschlossene Software-Kanal Synchronisationen werden nun detaillierter in der Web-Oberfläche aufgelistet. Für mich ist das ein echter Mehrwert - diese Funktion ist insbesondere bei der Fehlersuche unabdingbar. Da sie bisher fehlte, habe ich Software-Kanäle nicht über die in Spacewalk integrierte Task-Engine, sondern über konventionelle Cronjobs synchronisiert.

Vergessene Benutzerpasswörter werden nun nicht mehr im Klartext zurückgesetzt, stattdessen wird ein verschleierter Zurücksetzungs-Link per Mail versendet.

Sofern SCAP-Audits verwendet werden, wird pro System ein Compliance-Graph angezeigt, der die Einhaltung des definierten Sicherheitsstandard anzeigt.

Darüber hinaus wurden einige neue API-Aufrufe hinzugefügt - darunter:

• org.isErrataEmailNotifsForOrg - definiert, ob E-Mail-Benachrichtigungen über neue Errata für eine Organisation aktiviert sind
• org.isOrgConfigManagedByOrgAdmin - definiert, ob sämtliche Organisationseinstellungen vom aktuellen Benutzer verändert werden können
• org.setErrataEmailNotifsForOrg - aktiviert/deaktiviert E-Mail-Benachrichtigungen über neue Errata für eine Organisation
• org.setOrgConfigManagedByOrgAdmin - legt fest, ob der aktuelle Benutzer sämtliche Organisationseinstellungen verändern darf
• system.getOsaPing - gibt Informationen zur Erreichbarkeit eines Systems über OSAD (Open System Architecture Daemon) aus
• system.sendOsaPing - überprüft ein registriertes System über OSAD auf Erreichbarkeit

Insbesondere die OSAD-Ping-Funktionalität erachte ich als Mehrwert. Ich selbst habe viele administrative Aufgaben innerhalb Spacewalk über Python-Skripte automatisiert und könnte die Funktion aufgreifen, um nicht reagierende Systeme von bestimmten Aufgaben auszuschließen. Insbesondere satprep könnte hiervon profitieren.

Die vollständige API-Dokumentation befindet sich in der Hilfe-Sektion von Spacewalk oder alternativ im Internet auf der Spacewalk-Webseite.

Eine vollzählige Liste aller Änderungen in Spacewalk 2.4 sind in den Release Notes des Spacewalk-Projekts dokumentiert.

Die Arbeiten an Spacewalk 2.5 haben bereits begonnen, im nightly-Repository befinden sich die nächtlich generierten Pakete aktueller Entwicklungen.

Kürzlich hat SUSE ein Video bezüglich der für nächstes Jahr erwarteten Version 3 von SUSE Manager veröffentlicht. Eine der angekündigten Erneuerungen war die Bereistellung einer Appliance, die auch Icinga zu Monitoring-Zwecken integriert. Die eher beschränkte integrierte Monitoring-Funktionalität wurde in Spacewalk 2.3 entfernt. Im Zusammenhang mit Configuration Management war auch Saltstack die Rede. Ich selbst erachte den derzeit von Spacewalk (und somit auch SUSE Manager und Red Hat Satellite 5) verwendeten Mechanismus zur Konfiguration von Systemen als statisch und relativ unflexibel - Saltstack wäre hier deutlich flexibler. Ich hatte bereits im Januar auf den SUSE Linux Expert Day 2015 einen groben Einblick in die geplanten Erneuerungen bekommen und bin sehr gespannt, welche Entwicklungen sich hier noch ergeben werden. Es ist schön zu sehen, dass SUSE sich sehr aktiv am Spacewalk-Projekt beteiligt, 27% der Änderungen in Spacewalk 2.4 stammen vom ursprünglich aus Nürnberg stammenden Unternehmen.