UCS 5.0 Beta Release

Im Dezember werden wir das Beta Release von UCS 5.0 herausgeben. Für Nutzer*innen, die UCS bereits länger einsetzen, wird vor allem die Umbenennung der Systemrollen eine deutliche Veränderung bringen, die im Beta Release bereits sichtbar werden wird. Neben der elementaren Trennung von diskriminierenden Begriffen („Master“ und „Slave“) möchten wir durch neue Namensgebungen die zentrale Funktionalität der jeweiligen Systemrolle in den Fokus des (neuen) Namens rücken. Im Folgenden stelle ich Ihnen die neue Namensgebung für die Systemrollen vor und erläutere die Ziele, die wir damit verfolgen.



Neue Portalansicht: Apps können nach Präferenz sortiert werden in UCS 5

Neuer Look und neue Basis: UCS 5.0 ist da

Das fünfte Major Release von Univention Corporate Server ist fertig und steht ab sofort zum Download bereit. UCS 5.0 enthält neue Funktionen, einen neuen Look, Detailverbesserungen und Fehlerkorrekturen. Auch unter der Haube hat sich viel getan: Die neue Version setzt jetzt auf Debian 10 („Buster“) und Python 3. …mehr lesen »


Ursprung der bisherigen Namen

Die Systemrollen in UCS können in Umgebungen mit vielen Instanzen genutzt werden, um Komponenten des UCS Managementsystems, wie zum Beispiel den Verzeichnisdienst, sinnvoll zu verteilen: Abhängig von der jeweiligen Systemrolle wird ein vollständiges Managementsystem, nur ein Replikat des Verzeichnisdienstes oder auch gar kein Verzeichnisdienst installiert.
Die bis UCS 4.4 verwendeten Beschreibungen der Systemrollen wie „Domaincontroller Master“ sind von Begriffen abgeleitet, die ihren Ursprung in der in den 90er Jahren des letzten Jahrhunderts von Microsoft eingeführten NT-Domänen haben. Wir haben uns vor ca. 15 Jahren bewusst für diese Begriffe entschieden, da sie geläufig waren – und da das Ziel von UCS damals noch die Bereitstellung von Diensten war, die kompatibel zu NT-Domänen waren.

Gründe für die Änderungen

Bei Univention geht die Diskussion um die Namen der Systemrollen mindestens auf das Jahr 2016 zurück – eine so grundlegende Änderung wollten wir aber erst in einem Major Release wie jetzt UCS 5.0 durchführen. Die Gründe für die Diskussion kommen aus mindestens zwei Bereichen:

1. Selbsterklärende Beschreibungen
Spätestens mit der Umstellung auf Active Directory-kompatible Domänendienste für Clients sind die aus der NT-Welt abgeleiteten Begriffe „Master“ und „Backup“ irreführend: jedes System, auf dem ein Samba 4 DC als App ausgerollt wird, ist eine beschreibbare Kopie des Samba 4-Verzeichnisdienstes (ein „Master“). Dabei muss gar keine Installation auf der Systemrolle „UCS Domaincontroaller Master“ erfolgen, denn dort ist im Zweifel nur OpenLDAP installiert – er ist also gar kein „Domaincontroller“ im Sinne einer Active Directory kompatiblen Domäne. Wir wollen hier die Begriffe aus der „Microsoft-Welt“ abstreifen, um Missverständnisse zu vermeiden bzw. deutlicher zu machen, welches Ziel die Systemrollen verfolgen.

2. Nicht diskriminierende Begriffe
Die Begriffe „Master“ und „Slave“, die die bisherigen Namen der Systemrollen verwenden, sind untrennbar mit dem Leid unzähliger Menschen durch Unrecht wie Versklavung und Rassentrennung verbunden – und stehen damit in klarem Konflikt mit den Wertvorstellungen, die wir bei Univention vertreten.

Screenshot des Installationsbildschirms der Systemrollen in UCS 5.0

Übersicht der neu benannten Systemrollen und ihrer Funktionen im Installationsprozess

Herangehensweise an die neuen Begriffe

Die Namen der Systemrollen sollen für die Kernfunktionalität der Rolle stehen. Dabei wollen wir bereits berücksichtigen, dass wir die Bindung von Diensten an eine Systemrolle zukünftig – nicht alle mit UCS 5.0, aber später – lösen wollen, indem weitere Dienste in Apps aus dem UCS App Center auslagert werden. Erstes Beispiel ist das UCS-Portal, das als Preview bereits für UCS 4.4 als App bereitgestellt wurde, aber auch Dienste wie DNS oder die in UCS integrierte PKI.
Primäre Aufgabe einer UCS-Instanz ist es, als zentral verwaltetes Enterprise-Betriebssystem eine Plattform für diverse Services zu sein. Wir finden, dass dies mit dem Begriff „Node“, also eines Knotens in einer Infrastruktur, optimal repräsentiert wird.

Die wichtigste Trennung zwischen den Systemrollen ist im nächsten Schritt, ob auf dem System ein OpenLDAP als Verzeichnisdienst ausgerollt wird oder nicht; diese Entscheidung wird auch langfristig über die Systemrolle definiert. Systeme mit Verzeichnisdienst haben dann den Namen „Directory Node“, solche ohne sind ein „Managed Node“.

Zuletzt gibt es noch eine Unterscheidung bei den Aufgaben des Verzeichnisdienstes: „Primary Directory Node“ ist eine beschreibbare, führende Instanz, „Backup Directory Node“ stellt eine Instanz dar, die als Fallback für den „Primary Directory Node“ deren beschreibbare Rolle übernehmen kann, und „Replica Directory Node“ bezeichnet eine dauerhafte, nur lesbare Kopie.

Bisheriger Name Neuer Name Kernfunktion
Domaincontroller Master Primary Directory Node Beschreibbare, führende Instanz des Verzeichnisdienstes
Domaincontroller Backup Backup Directory Node Kopie des Verzeichnisdienstes und aller Informationen, um die Rolle des Primary Directory Node als Fallback übernehmen zu können
Domaincontroller Slave Replica Directory Node „Read-Only“ Replikat des Verzeichnisdienstes, für Lastverteilung und Standorte sowie Hosting von Services mit hoher Auslastung des Verzeichnisdienstes
Memberserver Managed Node Zentral verwaltetes System für Hosting von Services
Basissystem Die Rolle entfällt, da der Mehrwert gegenüber einem reinen Debian zu gering ist.

 

Angleichen anderer Rechnerobjekte im Managementsystem

In UCS 4 wurde der „IP Managed Client“ eingeführt, der als Objekt für das Verwalten von IP-Informationen (Adresse, DHCP, DNS) dient. Wir sahen hier eine Verwechslungsgefahr mit der neuen Rolle des „Managed Node“ – und gleichzeitig ist der Begriff „Managed Client“ irreführend, da der Client selber nicht von UCS verwaltet wird, sondern lediglich seine Informationen in den UCS Services DNS und DHCP. Der Client wird daher zukünftig „IP Client“ heißen.
Einige ältere Objekte im Managementsystem, die auf bereits länger abgekündigte Produkte zurückgehen, wurden aus UCS 5 entfernt. Dazu gehören Objekte wie der „Univention Thin Client“ und „Univention Corporate Client“.

Ansicht der systemrollen in der UMC

Die neu benannten Systemrollen in der Univention Management Console (UMC)

Ausblick

Mit der Umbenennung der Systemrollen gehen wir einen wichtigen Schritt für mehr Klarheit bei der Verwendung von UCS und legen die Grundlage für höhere Flexibilität mit zukünftigen Releases.
Diese Änderungen sind natürlich nicht die einzigen, die wir mit UCS 5.0 veröffentlichen werden. In kommenden Artikeln werde ich begleitend zur weiteren Entwicklung auf Änderungen an der Installation, Updates des Basissystems, Überarbeitung des Look & Feel sowie weitere Neuerungen eingehen.

Mit jedem Artikel freuen wir uns auch über Rückmeldungen zu den Änderungen hier im Blog!

UCS Core Edition jetzt kostenfrei einsetzen!

Zum Downloadbereich
Ingo Steuwer

Ingo Steuwer beschäftigt sich seit 1999 mit Linux und ist seit 2004 bei Univention. Als Head of Product Management liegt sein Fokus auf der Weiterentwicklung von UCS.

Was ist Ihre Meinung? Hinterlassen Sie einen Kommentar!

Kommentare

  1. Rassismus bekämpft wir können alle aufatmen…

    Ganz im ernst, eine neue sinvollere Bezeichnung ist gut und wenn Sie besser beschreibt was die Funktion tut alles Super. Da jetzt aber auf den „wir sind ja so Snowflakefriendly“ Marketingzug aufspringen finde ich unnötig.
    Die Änderung war notwendig, weil es das ganze Prinzip besser beschreibt hätte vollkommen gereicht.

    Aber man soll ja das Positive hervorheben und nicht imer rumschietern. Ich freue mich auf die weiteren Veränderungen und auch die neuen Bezeichnungen finde ich einleuchtend und sinnvoll.

    Antworten
  2. Anstatt sich mit begriffen abzugeben und dem Mainstream zu folgen, Begriffe, welche angeblich diskriminierend sind (wie soll man Software diskriminieren?), wäre es besser sich für Funktionen einzusetzen. Ich kann Euch daher nicht mehr für voll nehmen und werde den newsletter abbestellen.
    BTW: Was ist den mit dem akademischen Master. Da war Diplom dann doch wohl allemal besser.

    Antworten
  3. Ich glaube dass es eine zielführende und sinnstiftende Entscheidung ist, die Umbenennung ab Version 5 umzusetzen. Die Begründung und Argumentation sind absolut schlüssig. Mich würde in diesem Kontext interessieren was die Samba Community bzw. deren Entwickler wie z.B. die Sernet GmbH und andere Linux-Distributoren wie Canonical, Debian, Redhat und SuSe beurteilen diese Entscheidung beurteilen bzw. bewerten.

    Beste Grüße aus Zossen. Albrecht Barthel

    Antworten
  4. Ein absolut richtiger und wichtiger Schritt!

    Antworten
  5. Hallo Herr Steuwer,
    die Wortwahl finde ich sehr gelungen, wird doch der Kern des Ganzen, das Directory klar in den Fokus gestellt.
    Allerdings, und das ist nicht Thema des Artikels, bleibt mein Auge beim Lesen wie in unerwartet auftauchendem Stacheldraht hängen am Sternchen von „Nutzer*innen“ aber das ist wohl das Ergebnis anderer Diskussionen.

    Antworten
  6. Die Bezeichnungen sind klar und verständlich.
    Ich denke jedoch auch, dass es wichtigere Dinge gibt, als einen Mohrenkopf in Schaumküsse umzubenennen. Die POC in unserem Bekanntenkreis jedenfalls sind da wenig interessiert.

    Antworten
  7. Meinen Glückwunsch für einen m.E. längst überfälligen Schritt.
    Auch die in der IT Beschäftigten dürfen ruhig mal über gesellschaftspolitische Fragen nachdenken.
    Hoffentlich macht dieses Beispiel Schule.
    „Master“ mag ja noch auf die Funktion des PDC passen, „Slave“ dagegen hat noch nie die Funktion eines Replica-Directory sprachlich korrekt (und verständlich) wiedergegeben.

    Antworten

Schreibe einen Kommentar zu Patrick Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert