Die Vielfalt der existierenden Open-Source-Projekte macht es einfach, neue Funktionen zu einem modularen Produkt wie UCS hinzuzufügen – für sehr viele Dinge sind die Grundlagen da und es gibt positive Erfahrungen mit den Software-Projekten. Bei Univention verfolgen wir das Ziel, diese Funktionen bei unseren Anwender*innen zum Einsatz zu bringen. Darüber hinaus soll die Integration mit unseren Kernkomponenten gepflegt werden. Diese Pflege ist dabei der deutlich größere Teil der Arbeit, was sich besonders bei Upgrades bemerkbar macht. Ein Ziel von UCS 5.0 ist es daher, auf die Funktionen zu fokussieren, die den Kernnutzen von UCS stärken – und zu verhindern, dass UCS durch „Featuritis“ nicht mehr wartbar ist. Das bedeutet leider, von Funktionen und Projekten Abschied zu nehmen, die uns ans Herz gewachsen sind. Bevor wir uns also in zukünftigen Blogartikeln zusammen über die Neuerungen freuen können, gilt es zunächst, ein paar Kapitel zu schließen – mal wehmütig und mal freudig.
Arbeiten an der Basis – Aktualisierung der Debian-Plattform und Abschalten von runsv
Mit UCS 5.0 werden wir UCS auf die aktuelle stabile Debian-Plattform aktualisieren. Damit werden einige Veränderungen und Entscheidungen, die im Debian-Team getroffen wurden, auch UCS betreffen. Diese werde ich hier nicht im Einzelnen aufführen (für Interessierte sei an dieser Stelle auf die Debian Release Notes verwiesen), aber auch wir wollen an der Basis modernisieren.
Einen Bereich, den wir in UCS 5.0 nicht mehr weiter unterstützen werden, ist das Aktualisieren von Systemen mit der i386-Architektur, also der Betrieb von UCS als 32 Bit-Betriebssystem. Installationsmedien für diese Architektur gibt es schon länger nicht mehr; auf UCS 5.0 wird man bestehende 32 Bit-Systeme auch nicht mehr aktualisieren können.
Zu unseren Aktualisierungen an der Basis gehört auch das Entfernen des „runsv“-Dienstes und dem zugehörigen Paket „univention-runit“. Dieser Dienst wurde eingeführt, um andere Services zu überwachen und bei Problemen neu zu starten. Mit „systemd“ lässt sich diese Aufgabe einfacher realisieren und Services wie der Univention Notifier, Univention Listener oder der DHCP Daemon werden entsprechend umgestellt.
Abschied von der Vergangenheit: Windows NT-kompatibler Domänencontroller
Als eine der wichtigsten Komponenten von UCS übernimmt Samba 4 heute die Emulation eines Windows Active Directory inklusive kompatibler File und Print Services. Vor UCS 3.0 war der Betrieb als Windows NT-Domänencontroller Standard – und im Falle von Upgrades unterstützen auch die Releases von UCS 4.0 und folgende in eingeschränkter Form diesen Betriebsmodus. Mit UCS 5.0 werden wir uns davon verabschieden. Eine Neuinstallation im „alten“ Modus einer Windows NT-Domäne ist auch schon länger nicht mehr möglich – wer aber noch nicht migriert hat, wird dies vor dem Update auf UCS 5.0 tun müssen.
Mit dem Abschied von Windows NT-Domänen entfernen wir auch Elemente, die damit nicht mehr gebraucht werden. Dazu gehören kleine Helfer wie das „samba4wins“, mit dem es möglich war, redundante WINS Server neben NT-kompatiblen Domänencontrollern unter UCS zu betreiben. Das wird für Samba als AD-kompatibler Domänencontroller nicht mehr benötigt.
Das war nicht einfach: Univention Virtual Machine Manager
Die Entscheidung, mit der wir uns am längsten und intensivsten intern und auch im Austausch mit Kunden auseinandergesetzt haben, war der Umgang mit dem Univention Virtual Machine Manager (UVMM).
UVMM haben wir auf den Virtualisierungs-Bedarf in kleineren und mittleren Umgebungen ausgerichtet. Es bietet ein einfach zu bedienendes grafisches Frontend für die tägliche Arbeit, kann aber mit entsprechender Expertise durch seine Basis aus KVM, QEMU und libvirt zum Aufbau großer Virtualisierungsumgebungen genutzt werden. Zum Einsatz kommt er fast ausschließlich in einfachen Szenarien, beispielsweise um auf Standortservern noch ergänzende Services als virtuelle Maschine bereitzustellen.
Als UVMM vor über 10 Jahren mit UCS 2.4 eingeführt wurde, fehlte es an Tools, Virtualisierung auf Linux-Servern mit einer einfachen, remote bedienbaren Oberfläche zu administrieren. Diese Lücke hat UVMM erfolgreich in vielen Projekten geschlossen. Der Fokus von Univention war es dabei, Maschinen mit unterschiedlichen Betriebssystemen betreiben zu können. Dazu haben u. a. zur Verfügbarkeit von Beschleunigungstreibern für Windows-Betriebssysteme unter KVM beigetragen. Durch die intensive und engagierte Arbeit auch mit schwierigen Details des Netzwerk-Stacks oder der Live-Migrationen haben wir inzwischen zu dieser Komponente auch fast schon eine emotionale Bindung – und Änderungen fallen um so schwerer.
Abschied nehmen: den Univention Virtual Machine Manager wird es in UCS 5.0 nicht mehr geben.
Die Möglichkeiten und die verfügbaren Tools zur Virtualisierung unter Linux haben sich in den letzten Jahren vervielfältigt, so dass es inzwischen zahlreiche Alternativen zu UVMM gibt. Gleichzeitig ist Virtualisierung nicht der Grund, warum UCS eingesetzt wird. Vielmehr wird es oft mitgenutzt, weil es eben da ist. Die Aufgaben von UVMM können aber auch der durch Debian in UCS enthaltene Standard-KVM-Stack sowie ergänzende Tools übernehmen.
Wir haben uns daher bei der Entwicklung von UCS 5.0 dazu entschieden, UVMM zur Steuerung von Virtualisierung nicht mehr weiter zu pflegen. Die Basiskomponenten wie KVM, QEMU und libvirt wird es auch für UCS weiter geben; auch sind sie weiterhin Bestandteil des Produktsupports. Der Betrieb von virtuellen Maschinen unter UCS wird damit auch in Zukunft möglich sein und auch vorhandene virtuelle Maschinen werden weiter funktionieren. Die grafische Administration werden wir aber nicht mehr selber pflegen, sondern Open Source Tools empfehlen. Details dazu werden wir mit dem Release kommunizieren.
Komponenten mit wenig Nutzung
Es gibt viele andere Komponenten oder Apps, die es seit langer Zeit in UCS gibt, und die wir ebenfalls auf den tatsächlichen Nutzen bei unseren Anwender*innen geprüft haben. Bei einigen haben wir uns dazu entschieden, sie für UCS 5.0 nicht länger anzubieten:
- Der lokale Desktop wurde in UCS für den einfachen Zugriff vor allem bei Hardware-Installationen eingeführt und unterstützt insbesondere Anwender*innen ohne Erfahrung mit der Kommandozeile. Diese können aber für die tägliche Arbeit inzwischen sehr gut unsere Webinterfaces nutzen. Wer weiterhin einen Desktop auf einem UCS nutzen möchte, kann dies auch in Zukunft über die von Debian übernommenen Standards tun.
- Ein anderer Anwendungsfall war die Bereitstellung von Linux-Terminalservices, für die der Desktop auch um die XRDP App für Remote-Zugriffe über RDP ergänzt wurde. Da wir schon in der Vergangenheit den Support für diese Anwendungsfälle eingestellt haben, ist es nur konsequent, auch diese Integrationen nicht mehr zu pflegen.
- Zwei weitere Beispiele für inzwischen nicht mehr oft genutzte Erweiterungen von UCS sind so selten im Einsatz, dass die meisten Leser sie wahrscheinlich gar nicht kennen: Über das Paket „univention-ftp“ konnte ein FTP Server mit dem UCS Identity Management verbunden werden. Die Integration „univention-snmp“ ermöglicht den vereinfachten Zugriff auf Eigenschaften einer UCS-Instanz über SNMP. Beide Integrationen sind selten im Einsatz und insbesondere FTP hat aufgrund seiner Unsicherheit allgemein keine Verbreitung mehr.
In Würde gealtert
Für eine Reihe von Apps und Bestandteilen von UCS finden sich inzwischen würdige Nachfolger in unserem App Center und sie sind nicht mehr „state of the art“ – oft begleitet von einer fehlenden Pflege der ursprünglichen Software. Hier haben wir folgende Ablösungen geplant:
- Der Webmailer Horde ist ursprünglich als Referenz für den Zugriff auf unseren Mailstack gestartet. Er wird inzwischen aber von zahlreichen anderen Webmail- und Groupwarelösungen in unserem App Center begleitet, die ihn in Funktionalität und Usability übertreffen.
- Monitoring wird in UCS schon lange über Nagios umgesetzt – wie bei Horde gab es auch hier wenig Entwicklung in dem von uns verwendeten Release-Zweig. Der Fokus unserer Integration liegt dabei auf dem Prüfen von Parametern der UCS-Instanzen und überschneidet sich dabei mit dem UCS Dashboard – dem nur die Möglichkeit fehlt, über erkannte Probleme als Alert per E-Mail zu berichten. Der Dienst Prometheus hinter dem Dashboard kann solche Alerts ausliefern, so dass wir uns dazu entschieden haben, die Funktionen von Nagios im UCS Dashboard aufgehen zu lassen.
- Ebenfalls eine Überschneidung mit dem UCS Dashboard weist die Integration von MRTG in die Univention Management Console auf, mit der einfache Systemstatistiken generiert werden können. Auch diese Integration werden wir zu Gunsten des UCS Dashboards entfernen.
- Mit „Pykota“ realisierten wir bisher die Printquota-Funktionalität, um Volumen von Druckaufträgen nachvollziehbar zu machen. Die Software wird nicht mehr aktiv gepflegt und büßt durch Inkompatibilität stark an Funktion ein. Gleichzeitig steht aus unserem Partnerumfeld z. B. mit Papercut eine gute Alternative bereit.
- Weitere Pakete, die wir zur Vereinfachung bei der Integration von Open Source in UCS gepflegt haben, sind „univention-bacula“ und „univention-remote-backup“. Diese werden wir zugunsten besserer Backup-Lösungen , die im App Center oder über Partner bereitstehen, mit UCS 5.0 einstellen.
Nachbereitung
Wie schon im Blogartikel zu den Änderungen der Systemrollen geschrieben, haben wir einige Rechnerobjekttypen aus dem Univention Directory Manager entfernt, die aus den schon länger abgekündigten Produkten UCC und TCS übriggeblieben waren. Ebenfalls aus diesen Produkten stammen einige Pakete, die die Arbeit mit UCS als Linux Terminalserver oder Desktop-System vereinfachen sollten – und nicht mehr gebraucht werden: „univention-passwd-cache“ übernahm die Übergabe von Passwörtern innerhalb einer Desktop Session, während „univention-check-printers“ USB-Drucker auf Erreichbarkeit überwachte.
Aus Kompatibilitätsgründen gab es mit „univention-java“ ein Paket, das den Zugriff auf die Univention Configuration Registry per Java ermöglichte. Auch dieses Paket wird nicht mehr benötigt. Mit früheren Versionen des Proxy in UCS wurde über konfigurierbare Regeln in „Dansguardian“ der Zugriff auf Internetseiten gezielt gesteuert; inzwischen übernehmen andere Squid-Plugins diese Aufgabe.
Blick in die Zukunft
Ein Abschied ist gleichzeitig ein direkter Schritt in die Zukunft: Wie angekündigt, stellen wir unsere Implementierungen von Python 2 auf Python 3 um. Bereits in der Vorab-Veröffentlichung werden wir den Univention Directory Manager und Univention Configuration Registry auf Python 3 migriert haben, ebenso weitere, darauf aufbauende Implementierungen wie der Samba4-Connector.
Nicht jede der angekündigten Änderungen kann unbemerkt im Hintergrund erfolgen; bei einigen wird es auch Eingriffe durch die Administratoren von UCS und Veränderungen für die Anwender*innen geben. Für alle hier angekündigten Änderungen gilt dabei: Wir arbeiten daran, diese Übergänge möglichst einfach zu gestalten und zu automatisieren, wo es sinnvoll möglich ist oder dokumentieren es, wo es nötig ist.
Nach diesen vielen Abschieden freue ich mich darauf, in den nächsten Blogbeiträgen den Blick auf die Verbesserungen und Neuerungen in den Fokus-Bereichen von UCS werfen zu können. Mehr dazu schon in Kürze begleitend zum Vorab-Release.
