Nachdem wir seit einigen Jahren jeweils im November ein neues Release von UCS mit neuen Features herausgebracht haben, haben wir uns jetzt für die Verschiebung des Releases von UCS 4.2 auf April 2017 entschieden.
Dafür gibt es gute Gründe. Ein wichtiger ist die Migration von Apps aus dem App Center zur Nutzung der Container-Technologie Docker. Das führt zu höherer Sicherheit beim Betrieb und der Möglichkeit, Apps mit unterschiedlichen Systemanforderungen auf dem selben System zu betreiben. Außerdem können wir so die Aktualisierung von UCS selbst und der einzelnen Apps voneinander unabhängiger machen, was die Aufwände für App-Anbieter und Anwender bei neuen Releases signifikant reduziert.
Docker haben wir mit UCS 4.1 eingeführt, seitdem nutzen einige neuere Apps diese Technologie. Nun geht es darum, auch bestehende Apps in Container zu übertragen, ohne dass das mit zusätzlichen Aufwänden für die Hersteller der Apps verbunden ist. In diesem Prozess haben wir gerade die ersten drei Apps freigegeben, weitere werden bald folgen.
Unabhängig davon sehen wir, dass die Anforderungen des Marktes an unser Produkt enorm gestiegen sind. Immer häufiger wird UCS in sehr großen Umgebungen eingesetzt. Beispielsweise nutzen immer mehr Städte unsere Lösung, um Identitäten und Rechte von mehr als 100.000 Nutzern in ihren Schulen zentral zu verwalten. In solcher Skalierung mussten bisher einige Dinge manuell eingerichtet werden, was auch zu Fehlern führte. Wir haben deswegen jetzt viel Energie darauf verwendet, UCS in solchen Szenarien robuster und Funktionen wie die selektive Replikation von Active Directory Domänen stabiler zu machen. Dabei haben wir einiges erreicht und werden diesen Weg im Sinne der kontinuierlichen Verbesserung fortführen.
Zusätzlich bringen wir das App Center voran. App Anbieter werden zukünftig nicht nur via Self Services ihre Anwendungen unabhängig von uns verwalten können, sondern ihre Apps über die Plattform auch Partnern und später Endkunden direkt zum Kauf anbieten können. Die finanziellen Transaktionen können dabei komplett vom App Center übernommen werden.
Wir glauben, dass wir unseren Kunden und Partnern derzeit mit besserer Skalierbarkeit von UCS, mehr Sicherheit beim Betrieb von Apps und insgesamt größerer Robustheit des Produkts besser dienen als mit der Aufrechterhaltung einer Tradition in unseren Releases. Anwender und Partner, mit denen wir das besprochen haben, haben uns diese Einschätzung bestätigt.
Einen Release Candidate von UCS 4.2 wollen wir zur CeBIT 2017 vorstellen. Neben der Erneuerung der Debian-Basis möchten wir mit UCS einen ganz neuen Ansatz für das Bedienkonzept entwickelt: Über eine zentrale Portalseite ermöglichen wir den schnellen Zugriff auf alle Anwendungen der Domäne sowie die Verwaltung der unterschiedlichen UCS-Instanzen. Damit machen wir es für UCS Nutzer gesamter Organisation einfach, auf freigeschaltete Anwendungen zuzugreifen.
Kommentare
Moritz Bunkus
Vielen Dank für das Update. Eine Verschiebung aus den genannten Gründen kann ich als Partner & Anwender eigentlich nur begrüßen.
Zwei Detailnachfragen:
1. Sie schreiben von der »Erneuerung der Debian-Basis«. Bedeutet das den Umstieg auf Debian Jessie als Basis? Wird dann systemd als Init-System zum Einsatz kommen?
2. Docker & Sicherheit. Die Verwendung von Containern bedeutet auch immer, dass innerhalb der Container eigene Versionen von sicherheitsrelevanten Bibliotheken (natürlich OpenSSL aber auch vermeintliche Banalitäten wie die zlib) zum Einsatz kommen. Die Kuratoren der Docker-Images sind daher in einer großen Verantwortung, Updates regelmäßig herauszubringen und darin enthaltene Bibliotheksversionen stets aktuell zu halten. Wie ist hier der Plan von Univention, das sicherzustellen? Und wie soll ein Admin den Überblick behalten, welche Docker-Images aktuelle Bibliotheken verwenden? Davon ist ganz entscheidend abhängig, ob ich mich traue, so eine App auch im Internet zur Verfügung zu stellen.
MfG,
Moritz Bunkus
Peter Ganten
Hallo und danke für das positive Feedback!
Ja, UCS 4.2 wird auf Debian Jessie basieren. Unsere Entwicklung prüft derzeit noch, ob systemd als Init-System eingesetzt werden soll. Würden Sie damit Probleme sehen?
Zu Docker und der Pflege der Container: Standardmäßig verwenden die Docker-Images ein abgespecktes UCS-System. Veröffentlichte Security Updates werden im Docker-Container dann automatisch und direkt eingespielt. Als Administrator hat man die Möglichkeit den Update-Status direkt im App Center zu sehen.
Entscheidet sich der Anbieter einer App dafür, ein anderes Betriebssystem im Docker-Container einzusetzen, so ist die Empfehlung die Update Schnittstellen des App Centers im Container zu implementieren oder immer neue Docker-Images anzubieten, in der die Sicherheitslücken behoben sind. Diese Updates werden dann ebenfalls im App Center anzeigt und können dort entsprechend eingespielt werden.
Ausführlich haben wir die Docker Apps hier beschrieben: https://www.univention.de/2015/11/neu-in-ucs-4-1-docker-apps-fuer-das-univention-app-center/
Viele Grüße, Peter Ganten
Moritz Bunkus
Mit systemd hätte ich kein Problem, eher im Gegenteil. Mir sind sämtliche Kontroversen um das Thema herum deutlich bewusst, aber was für mich Punkte sind, die dafür sprechen:
• Wissenstransfer, da das Gros der Linux-Distributionen heutzutage auf systemd setzen
• Analog: Weiternutzung auf anderern Systemen vorhandener Unit-Files
• Deutlich zuverlässigere Service-Kontrolle (ich hatte schon so oft, dass ein „service XYZ restart“ nicht funktioniert hat, weil das Stoppen nicht zuverlässig funktionierte, noch Prozesse liefen, der Port damit belegt war etc.)
• Deutlich weniger Aufwand, Service-Units für eigene Dienste zu schreiben — kein großes Init-Script-Boilerplate-Rumgefummele
• Direkt in systemd eingebaute Sicherheitsfeatures wie ProtectHome, PrivateTmp, ProtectSystem, Syscall-Filter, die ich als Admin trivial einsetzen kann
Werten Sie das ruhig als deutliche Fürsprache für systemd 🙂
Danke für die Infos zu Docker. Das klingt für mich soweit gut und plausibel.
Gruß,
Moritz Bunkus
Peter Ganten
Alles klar, danke!