Zwei Stunden mit Univention Corporate Server

Univention Corporate Server (UCS) ist eine Linux-Distribution die als „Serversoftware für unkomplizierten IT-Betrieb“ dienen soll. Insbesondere wird ein einfaches Identity- und Infrastrukturmanagement ermöglicht, UCS ist damit eine zentrale Komponente in einem Unternehmen zur Verwaltung von Benutzern und Administration von Anwendungen. Durch die Active-Directory-Funktionen, die von Samba zur Verfügung gestellt werden, kann UCS als Ersatz für ein Windows-Server-System dienen.

Univention bietet mit UCS Core Edition eine kostenfreie Lösung an, Voraussetzung ist allerdings eine Registrierung mit einer gültigen E-Mail-Adresse, an die einem der Lizenzschlüssel gesendet wird. Inwiefern das System damit noch „Open Source“ genannt werden kann, bleibt fraglich, jedoch vermeidet Univention eine solche Bezeichnung auch auf ihrem Web-Auftritt, immerhin ist die Core Edition kostenlos, während die Enterprise-Varianten bei Preisen von wenigen Hundert Euro pro Jahr beginnen. Ich habe also ein weiteres Mal meine Daten eingegeben und konnte die neueste UCS-Version 4.3 als ISO-Image herunterladen.

Vom Newsletter zum Anleitungs-Video

So weit, so gut. Warum habe ich nun – wie der Titel hier nahe legt – erneut zwei Stunden mit UCS verbracht? Und warum nur zwei Stunden? Es begann mit einem Newsletter. Da ich früher UCS bereits getestet hatte und Univention somit im Besitz meiner Mailadresse ist, senden sie einem von Zeit zu Zeit Newsletter.

Das ist auch völlig in Ordnung, schließlich könnte ich mich jederzeit abmelden. In diesem Newsletter wurde auf ein Video auf YouTube hingewiesen, in dem die Installation und Einrichtung eines Heimservers mit Linux, basierend auf UCS beschrieben wird. Zwar handelte es sich um eine von Univention bezahlte Promotion, aber immerhin enthält es einige Informationen, im Gegensatz zu manchen Instagrammerinnen-Produktplatzierungen, bei denen dann ganz zufällig Ketchupflaschen im Bad herum stehen – oder ähnliches. Insofern war mein Interesse geweckt, das Video versprach ein Tutorial durch die Installation von UCS und der darauf folgenden Einrichtung von Nextcloud in Verbindung mit OnlyOffice und darüber hinaus als Mailserver- und Groupware-Lösung Kopano. Diese Komponenten steht im Univention App Center zur Verfügung – einer Art App-Store für Server-Software, vorkonfiguriert und fertig zum Einsatz auf einem UCS-System.

Nun hatte ich vor einiger Zeit zwar bereits UCS getestet, aber letztlich wieder verworfen. Doch auch das Nutzungsverhalten kann sich ändern, zwar nicht je nach Tageszeit, aber je nach Gewohnheiten mit den Jahren. So verwende ich beispielsweise inzwischen verstärkt Thunderbird mit Lightning-Extension für meine Mails bzw. Kalender. Die Mails kommen von einem IMAP-Server, jedoch nicht von einem eigenen oder Gmail. Der Kalender hingegen synchronisiert die Einträge mit dem Google-Kalender, so dass auch mobil alle Daten zur Verfügung stehen. Die Mail-Konfiguration insgesamt ist um einiges komplexer, grundsätzlich werden Mails zwar von einem (virtuellen) Server empfangen, dann aber weiter geleitet an Gmail, das ich seit mehr als zehn Jahren nutze. Im Laufe der Zeit haben sich dort insofern einige Mails angesammelt, das funktioniert auch angesichts der hohen Zahl von Mails nach wie vor prima – Google hat einfach ausreichend Kapazitäten dafür. Die Mails sind auch nicht wie einst in irgend welchen Ordnern sortiert, sondern einfach in der Inbox belassen – schließlich lässt sich darin ja „googlen“. Nichtsdestotrotz könnte es eigentlich nicht schaden, den kompletten Mailbestand auch mal ins heimische Netz bzw. auf die heimischen Server zu holen, so zumindest mein Gedanke. Und wenn damit noch ein Cloud-Storage einher geht, sich der Kalender ebenfalls synchronisieren lässt, Thunderbird mit dem Server im Keller redet anstatt mit dem entfernten IMAP-Dienst, ist man vielleicht nicht mehr ganz so abhängig von anderen Diensten. Quasi zurück zur autarken Lösung, zwar nicht mehr in der „Cloud“, aber bei der aktuellen Wetterlage gibt es davon sowieso zu wenige.

Vom Video zur Installation von UCS

Nachdem ich mit einige Minuten des Videos angesehen hatte, war meine Neugier aufs Ausprobieren geweckt. Nebenbei richtete ich also eine neue VM ein, auf der UCS Platz nehmen sollte, 8 GB RAM, 4 CPU und 400 GB Plattenplatz sollten dafür eigentlich ausreichen. Währenddessen habe ich das Video weiter bzw. bis zum Ende angesehen. Das Video soll hier auch nicht Thema sein – nur soviel – es ist durchaus gelungen. „Linux Guides“ erklärt kurz die Grundlagen, bevor er zur Installation über geht, länger dauernde Schritte werden sinnvoll gekürzt, danach werden die drei Komponenten installiert und kurz eingerichtet. Dafür ist das Video zwar recht lang geraten, aber die gute halbe Stunde sorgt so dafür, dass auch ein Einsteiger keine Schwierigkeiten haben dürfte, dem Vorgehen zu folgen. Der Autor betont auch, dass er trotz Produkt-Promotion von dem System, ergo UCS überzeugt sei, und dass es möglicherweise auch weitere Videos dazu geben wird. Ich habe die Installation also durchgeführt, die Einrichtung der Maschine war schnell geschehen, danach folgten die im Video besprochenen Schritte.

Wer sich mit der Installation von Debian oder Ubuntu auskennt, für den dürfte die Installation von UCS auch kein Problem darstellen. Ich gehe im Folgenden auch nicht auf jeden Schritt ein, dazu empfehle ich z.B. einen Blick in das genannte Video, aber ich möchte doch ein paar Auffälligkeiten beschreiben. Spoiler-Warnung: Letztlich führten diese dazu, dass ich zwar zwei Stunden mit UCS verbracht habe, aber leicht bis mittel genervt die gesamte VM am Ende wieder rigoros gelöscht habe.

Erste Schritte – Partitionierung und ein paar Fragen

Eine erste Merkwürdigkeit begegnete mir bei der Partitionierung. Dass ich zunächst die automatische Partitionierung gewählt, dann auf die manuelle Partitionierung umgeschwenkt habe, war allein meine Schuld, aber letztlich hat es doch funktioniert. Die Partitionsgrößen bei der automatischen Einstellung verlangen meiner Ansicht nach hingegen einer Erklärung. Warum wurde für /home/ die größte Partition eingerichtet, /var/ hingegen nur 35 GB? Warum ext2 als Filesystem für /boot/? Wo landen die Daten der Nutzer, etwa Mails bei Verwendung von Kopano? Wo werden die App-Daten gespeichert? Da ich das nicht hellsehe bei einem vorkonfigurierten System wie UCS, müsste ich der Einstellung entweder vertrauen oder sie zumindest überprüfen können. Letztlich habe ich mich dann für die manuelle Partitionierung entschieden, wie üblich wollte ich Btrfs als Filesystem für die größte Partition nutzen. UCS warnte mich allerdings davor, dass die verwendete Container-Technologie (warum nennen sie das Kind nicht beim Namen – Docker?) Btrfs nicht unterstützen würde und man besser XFS nutzen sollte. Merkwürdig, denn meine VMs mit Ubuntu besitzen mittlerweile fast alle Btrfs – und der Betrieb von Docker war damit bisher kein Problem. Aber vielleicht ist dies auch den verwendeten Versionen von Debian und Docker geschuldet, ergo XFS angewählt und weiter. Der Rest der Installation war eher unspektakulär, zumindest bis zur Domänenauswahl.

Erste Hürden – die Domänenauswahl

Die Angabe der Domäne ist quasi die Grundlage für allen weiteren Betrieb von UCS. Denn UCS kann einen Domänencontroller für Windows-Clients darstellen, alle Benutzer sind Teil der verwalteten Domäne, letztlich ist UCS zuständig für alle Dienste, die unter der Domäne erreichbar sind. Man kann wählen, ob der UCS-Server eine Domäne erhalten soll, einer bestehenden beitreten o.ä., im Tutorial wird vorgeschlagen, dass UCS als Server für die angegebene Domäne fungieren soll, daran wollte ich mich halten. Doch welche Domäne – im Folgenden nenne ich dies wieder wie üblich „Domain“ wollte ich einsetzen?

Meine bisherige Konfiguration sieht so aus, dass IP-Adressen per DHCP-Server vergeben werden, jener wird von einem EdgeRouter X verwaltet. Die DNS-Server hingegen laufen auf zwei internen VMs, die jeweiligen IP-Adressen sind im EdgeRouter eingetragen, so dass die IP-Adressen inkl. DNS-Server, Default-Route etc. korrekt vergeben werden. Dabei wird die tatsächlich existierende Domain „geschke.net“ von den internen DNS-Servern für die internen Zwecke verwaltet, somit können beispielsweise intern Server-Namen vergeben werden, die im Internet nicht zu finden sind. Alle im Netz befindlichen Clients nutzen diese DNS-Server, die alle anderen Anfragen an die DNS-Server des Providers weitergeben. An der Konfiguration sollte nichts geändert werden. Im DHCP-Server habe ich insofern die MAC-Adresse der neuen VM statisch auf eine IP-Adresse gemappt, so dass bei Nutzung von DHCP der USC-Server immer dieselbe IP-Adresse erhält. Im DNS kann zu jener IP-Adresse jeder beliebige Name eingetragen werden, der Einfachheit halber nenne ich ihn im Folgenden „ucs.geschke.net“.

Meinem Plan zufolge sollte der UCS-Server jedoch für eine weitere Domain zuständig sein. Erstens wäre damit eine gewisse Unabhängigkeit vorhanden, so könnte UCS als DNS-Server für diese zweite Domain dienen, alle Dienste wären einheitlich auf dieser Domain vereint usw.. Nicht zuletzt hätte ich später Clients entsprechend konfigurieren können, dass sie sich an dieser Domain anmelden. Somit wählte ich „geschke.cloud“ als Domain für UCS, bei der Installation wurden diese Daten auch korrekt übernommen.

Installation und Gedanken zu Domänen, Domains, FQDN und DNS

A propos Installation – gefühlt dauerte die Installation von UCS insgesamt sehr lange. Damit meine ich weniger die Benutzerdialoge als die Installation des Grundsystems. Verglichen mit einer aktuellen Ubuntu-Variante, die sogar auf weniger leistungsfähigen Systemen eingerichtet wurde, genehmigte sich UCS weitaus mehr Zeit. Ein nicht geringer Teil wurde dabei auch von der Installation der aktualisierten Pakete beansprucht, die ich nach Empfehlung in einem der UI-Dialoge ausgewählt hatte.

Irgendwann konnte ich noch den FQDN, d.h. den Namen des Hosts wählen, auf dem UCS laufen sollte. Dabei soll der Domainbestandteil die zuvor gewählte Domäne sein, ergänzt durch einen Hostnamen. Insofern gab ich „ucs.geschke.cloud“ an. Dabei habe ich mich absichtlich nicht an die Empfehlung des Tutorials gehalten. Einerseits mag ich diese Domainnamen à la „name.intern“, „name.local“ o.ä. nicht. Es widerstrebt mir, derartige Namen zu verwenden, es ist mir auch nicht klar, wo der Vorteil dabei liegen sollte. Immerhin laufen DNS-Server, DHCP-Server etc. bereits im Netz, alles lässt sich mit dem Hostnamen ansprechen, ggf. sogar von außen, falls eine entsprechende Freigabe durch Router, Firewall etc. existiert. In dem Fall hätten dann interne Domain und von außen ansprechbarer Host unterschiedliche Namen, was nur zu Problemen führt. Letztlich sind diese Fantasie-Domains für mich keine Option, zumindest mit der aktuellen Konfiguration. Der User, der nur per iPad ins Netz geht, für den Domains, FQDN etc. irrelevant sind, der sich insofern gar nicht mit derartigen Details beschäftigen will – oder muss, kann natürlich auf die Standard-Konfiguration seines Routers zurück greifen. Daran ist auch nichts falsch, doch war meine Absicht eine andere, und zwar die Integration des UCS-Servers in eine bestehende Infrastruktur, die vielleicht eher einem kleinen Unternehmen als einem Home-Server entspricht. Letztlich hätte UCS auch als DNS-Server fungieren können, um sich für die Verwaltung der Domain „geschke.cloud“ zuständig zu zeigen, für alle weiteren Domains hätte UCS auf die bestehenden DNS-Server weiterleiten können. Nachdem die Installation erfolgreich abgeschlossen war, begrüßte mich UCS wie im Tutorial beschrieben mit einem Startbildschirm und der Nennung der IP-Adresse, unter der die Admin-Oberfläche erreichbar war.

Andererseits hatte ich ja bereits einen Namen für UCS vergeben, insofern rief ich ihn einfach per „ucs.geschke.net“ auf. Auch das funktionierte, jedoch verschlüsselt per https nur mit den üblichen Warnungen, von wegen ungültiges Zertifikat usw.. Ein weiteres Argument für real existierende Domainnamen. Im Video wurde nur mittels eines nachträglich hinzugefügten Kommentars darauf eingegangen. Und zwar lässt sich per Let’s Encrypt auch kostenfrei ein SSL-Zertifikat hinzufügen. Möglicherweise besitzt UCS sogar dazu ein entsprechendes Modul, was das Zertifikat automatisch erstellt. Doch da Let’s Encrypt während des Ausstellens des Zertifikats eine Validierung der Domain durchführt, muss der jeweilige Server vom Internet aus erreichbar sein. Genau das ist jedoch nur möglich, wenn UCS einen echten FQDN hat, d.h. eine Domain und einen Hostnamen besitzt, der im Internet bekannt ist. Gesetzt den Fall, dass UCS nur einen internen Namen besitzt, könnte auch kein SSL-Zertifikat für diesen internen Namen ausgestellt werden, denn er wäre nicht von außen erreichbar. Wenn UCS aber von außen erreichbar sein müsste, kann man auch direkt eine reale Domain verwenden. Oder sollte man sich eines Proxies bedienen, der für die Erreichbarkeit von außen zuständig wäre, und über den die Zertifikatsverwaltung liefe? Aber auch dann wäre das Zertifikat letztlich für den extern verfügbaren Namen, nicht für die interne Domain. Ergo – wie man es dreht und wendet, diese internen Domainnamen bleiben eine eher schlechte Idee.

Doch so weit war ich noch gar nicht – zunächst wollte ich UCS per Web-UI erreichen. Das funktionierte entweder unter der angegebenen IP-Adresse oder unter dem Hostnamen der bereits vorhandenen Domain, also ucs.geschke.net.

Erster Login und Einrichten eines Users

Das Login funktionierte mit dem Usernamen „Administrator“ und dem vormals gewählten Passwort. Während der Installation hatte ich übrigens per Mail den Lizenzschlüssel erhalten, der im Begrüßungsdialog hochgeladen werden konnte. Damit war die Installation des Grundsystems abgeschlossen, bis hierhin entsprach dies auch der Beschreibung im Video.

Als nächstes habe ich einen User eingerichtet – schließlich will man nicht als User „Administrator“ arbeiten, der vermutlich nichts anderes als der root-User ist. Bis dahin hatte ich noch keine weiteren Module aus dem Univention App Center installiert, aber die Einrichtung von Benutzern dürfte vielfach der erste Schritt sein. Zunächst wurden nur die wichtigsten Daten abgefragt, also Username, Vorname, Nachname, Passwort. Alle weiteren konnte man in einem umfassenderen Dialog eintragen. Ich hielt es für eine gute Idee, dem Nutzer bereits eine Mailadresse zu geben. Doch dies quittierte UCS mit einer LDAP-Fehlermeldung – die Angabe einer Mailadresse sei (noch?) nicht möglich aufgrund fehlender Module. Natürlich hatte ich noch keinen Mailserver eingerichtet, das sollte ja erst später erfolgen. Aber warum man in der User-Datenbank noch keine Mailadresse hinterlegen konnte, hat sich mir dennoch nicht erschlossen. Vielleicht wäre es auch möglich gewesen, wenn ich den Active-Directory-Server eingerichtet hätte, aber zunächst wollte ich mich mit den Bausteinen aus dem Tutorial beschäftigen.

Des Weiteren hätte ich gerne meinem neuen User Admin-Rechte gegeben, damit ich mich nicht bei Admin-Tätigkeiten extra als Administrator einloggen muss. Eine derartige Möglichkeit habe ich jedoch nicht gefunden, jedenfalls nicht in den User-Einstellungen. Ob es überhaupt möglich ist, kann ich insofern nicht sagen, ich hätte mir hier ein Prinzip vergleichbar mit sudo oder ähnlichen Hilfsmitteln vorgestellt, eben der Möglichkeit, zwar als User mit normalen User-Rechten zu arbeiten, aber auch die Rechte zu Admin-Tätigkeiten zu besitzen. In der Gruppenauswahl habe ich ebenfalls keine eindeutig als Admin-Gruppe zu interpretierende Gruppe gefunden. Sicherlich muss man Univention zugute halten, dass umfassende Dokumentation für UCS zur Verfügung steht, und das sogar in deutscher Sprache. Hier hätte ich mich insofern erstmal einlesen müssen. Andererseits soll UCS ja das Management möglichst einfach machen – meine Erwartungshaltung war somit eine andere.

Next Step – Nextcloud

Der nächste Schritt bestand aus der Installation von Nextcloud. Hier kommt bereits die „Container-Technologie“ zum Einsatz, denn UCS gab an, dass die dafür benötigten Pakete erstmal installiert werden müssten, weshalb dies einmalig einen gewissen Mehraufwand darstellen würde. Also im Klartext – zunächst bedurfte des einer Installation von Docker, dann konnten die Docker-Images für Nextcloud heruntergeladen und gestartet werden. Das dauerte tatsächlich relativ lange, ich würde schätzen zwischen zehn und 15 Minuten, trotz 100 MBit-Leitung, auch hier bin ich mit manueller Einrichtung des Docker-apt-Repositorys und Eingabe der apt-Installationskommandos schneller. Aber sei’s drum, nach besagten Minuten meldete UCS, dass die Installation erfolgreich abgeschlossen wäre. Praktischerweise werden einem die installierten Anwendungen in einer entsprechenden Liste im oberen Bereich angezeigt, hier kann man mit einem Klick die Anwendung aufrufen.

Oder vielmehr – könnte. Denn hierbei tragen Probleme mit der Domain auf. Ich hatte UCS unter „ucs.geschke.net“ aufgerufen, das war schließlich die bekannte, interne Adresse der bestehenden Domain. Im Video wurde hingegen bereits der DNS-Server des Client-Systems getauscht, d.h. die IP-Adresse des UCS-Servers eingetragen.  Dafür war es mir aber noch ein wenig zu früh, ich wollte ja zunächst ein paar Funktionen ausprobieren, ganz zu schweigen davon, dass ich dann zunächst den DNS-Server von UCS hätte konfigurieren müssen, so dass er zumindest die DNS-Servers des Providers nutzt. Darüber hinaus wurde als URL auch der aktuelle UCS-Server-Name angegeben, es sprach also nichts dagegen, dass das funktionierte. Tatsächlich meldete sich Nextcloud nach dem Klick auf den Anwendungslink, jedoch nicht wie erwartet. Man habe Nextcloud unter einer nicht vertrauenswürdigen Adresse aufgerufen, man könnte die aktuelle Adresse mit Änderung in config/config.php zu den vertrauenswürdigen Adressen hinzufügen. Dafür wurde auch ein Button angeboten, möglicherweise hätte man diese Änderung auch gleich durchführen können, doch der Button zeigte auf die – noch – nicht bekannte URL ucs.geschke.cloud. Also probierte ich die IP-Adresse, unter der UCS erreichbar war, womit auch Nextcloud letztlich angesprochen werden konnte. Immerhin ließ sich Nextcloud somit ein wenig testen bzw. zumindest weiter einrichten.

OnlyOffice – oder auch nicht

Die nächste Anwendung aus dem Video war OnlyOffice, ein laut Wikipedia Open-Source-Online-Office-Programm, das sich in OwnCloud und Nextcloud integrieren lässt, so dass ein Editieren der Dokumente, Tabellen und Präsentationen im Browser bzw. in der Oberfläche von Nextcloud möglich wird – vergleichbar mit Google Docs oder Microsoft Office Online.

Die Installation dauerte wiederum einige Minuten, trotzdem nun Docker vorhanden war, danach sollte sich OnlyOffice in Nextcloud einrichten lassen. Dazu musste eine Verbindung geschaffen, d.h eine URL für OnlyOffice in Nextcloud eingetragen werden. Doch welche URL bzw. welcher Hostname sollte eingetragen werden? Auch hier haderte ich wieder mit den Einstellungen. Denn nach der Installation wurde auf der Informationsseite zwar der Pfad-Anteil der Adresse von OnlyOffice angegeben, über den Host schwieg man sich hingegen aus. Zunächst führte der Weg somit wieder zu Nextoffice, dort war ich noch als Administrator eingeloggt. Da ich inzwischen trotz der Zertifikatswarnungen per https auf UCS und somit auch Nextcloud zugegriffen habe, was nur über die IP-Adresse funktionierte, probierte ich es damit aus – https://<ip-adresse->/<pfad>. Zwar quittierte Nextcloud den Erfolg der Einrichtung, jedoch führte der Weg, ein neues Dokument anzulegen, in eine Sackgasse. Einen Dateinamen konnte ich noch wählen, aber danach war Schluss, OnlyOffice meldete sich nicht bzw. gab einen Verbindungsfehler aus. Also schön, dann vielleicht den Hostnamen, unter dem ich alternativ UCS erreicht hatte, d.h. der intern gültige Hostname, doch damit fand Nextcloud OnlyOffice überhaupt nicht. Das konnte ich auch nur zur Hälfte nachvollziehen, denn einerseits hatte ich die bisherigen internen Nameserver nicht eingetragen, andererseits waren diese per DHCP an UCS übergeben worden – genau wie bei allen anderen VMs. Insofern hätte UCS sie bereits verwenden müssen. Warum die Verbindung dennoch nicht funktionieren wollte, blieb mir insofern ein Rätsel. Die dritte Möglichkeit – die Nutzung der Domain, für die sich UCS zuständig zeigte, also „geschke.cloud“ schlug ebenfalls fehl, was wiederum erklärbar war, falls UCS nicht als Nameserver fungierte, jedoch befand sich UCS mitsamt Nextcloud und OnlyOffice doch auf gerade auf ein- und demselben Host, und wenn UCS einen eigenen DNS-Dienst besitzt, der von allen Komponenten genutzt wird, dann müsste die Namensauflösung doch funktionieren… Da an dieser Stelle meine Geduld schon ein wenig in Mitleidenschaft gezogen war, beschloss ich, das Problem erstmal nach hinten zu verlagern und mich der dritten Komponente des Videos zuzuwenden – Kopano.

Die Groupware Kopano und ein Killerargument

Kopano ist eine Groupware-Anwendung und bringt die Kernfunktionen E-Mail, Kalender, Kontaktverwaltung, Aufgabenliste  und Notizen usw. mit sich, inzwischen gibt es auch die Möglichkeit von Chats oder Dokumentenaustausch. Insofern werden viele Funktionalitäten versprochen, die teilweise jedoch auch kostenpflichtig sind. Die Community-Version steht kostenfrei zur Verfügung und sollte für den Betrieb im Home-Office auch absolut ausreichen. Letztlich wollte ich meine Mails und den Kalender darüber verwalten. Falls einem der Name unbekannt erscheint, vielleicht ist Zarafa eher ein Begriff, denn bei Kopano handelt es sich um einen Fork von Zarafa, der nun unter eigenem Namen weiterentwickelt wird. Über die Community-Version schweigt sich die Website von Kopano leider aus, eine Übersicht der Unterschiede findet sich jedoch beispielsweise bei einem der Kopano-Partnerunternehmen.

Die Installation von Kopano bestand einerseits aus dem üblichen Vorgehen, d.h. Auswahl des Moduls bei UCS im Univention App Center, andererseits ist Kopano selbst in mehrere Module aufgeteilt. Zunächst hieß es, Kopano Core auszuwählen und zu installieren, danach die Web-UI namens Kopano WebApp, die sich in einem weiteren Modul befindet. Nach dem Klick auf den „Installieren“-Button erschien zunächst der Hinweis, dass „Softwaretests auf den beteiligten Systemen“ durchgeführt würden. Was es damit auf sich hatte, wurde nicht weiter erklärt, vielmehr erstaunte mich jedoch die lange Zeit, die diese Aktion bei den Kopano-Anwendungen benötigt hat. Docker war doch bereits auf UCS installiert, benötigter Speicherplatz sollte sich schneller prüfen lassen, also warum genehmigte sich UCS erst wieder eine gewisse Zeitspanne, um irgend welche Tests durchzuführen? Ich habe die Zeit zwar nicht gestoppt, gefühlt waren es aber schon zwei bis drei Minuten, bis UCS den eigentlichen Installieren-Dialog anzeigte, in dem dann noch einmal „Installieren“ geklickt werden musste. Die Benutzerführung – zunächst auf der Modul-Detailseite auf „Installieren“ drücken, dann auf einer weiteren Seite nochmal „Installieren“ klicken, könnte meines Erachtens ebenfalls verbessert werden. Im Video wird an diesen Stellen geschickt geschnitten, so dass diese Kuriosität weniger auffällig ist. Den Hinweis, offizielle Paketquellen verwenden zu können, habe ich ebenso ignoriert, wie im Video vorgeschlagen wurde. Tatsächlich – und das nur am Rande erwähnt, meine ich, während der weiteren Tests gelesen zu haben, dass für die offiziellen Paketquellen eine Registrierung und damit kostenpflichtige Version von Kopano Voraussetzung sein würde. Auf das Modul „Z-Push for Kopano“ habe ich zunächst verzichtet, da ich kein Outlook einsetze, und für mobile Devices hätte ich diese Synchronisierungslösung auch jederzeit nachinstallieren können.

Nach der Installation wird im Video die Eingabe der E-Mail-Adresse in der UCS-Benutzerverwaltung gezeigt. Damit hatte ich im Vorfeld wie beschrieben bereits Probleme, aber tatsächlich funktionierte die Zuweisung einer Mailadresse für meinen angelegten Benutzer nun problemlos. Dennoch empfinde ich diesen Prozess als hakelig – um eine Mailadresse in der UCS-Benutzerverwaltung einzutragen, muss anscheinend ein Mailserver oder etwas Ähnliches auf dem UCS-System enthalten sein. Laut Fehlermeldung von meinen ersten Versuchten wird jedoch ein LDAP-Server für die Benutzerverwaltung eingesetzt. Warum in dieser Datenbank die entsprechenden Felder nicht von Anfang an enthalten sind, mag einen Grund haben, besonders logisch oder benutzerfreundlich empfinde ich diesen Prozess jedoch nicht. Schließlich werden im Benutzerkonto-Dialog auch ohne vorherige Einrichtung eines Mailservers alle Felder angezeigt, darunter das besagte Input-Feld für die „Primäre E-Mail-Adresse“. Die Eingabe dann mit einer Fehlermeldung zu quittieren, die sich nur auf den LDAP-Server bezieht, nicht jedoch die genaue Ursache oder gar einen Hinweis angibt, wie das Problem zu beheben ist (z.B. „Installieren Sie im App Center eine Mailserver-Komponente“), ist leider suboptimal.

Davon abgesehen hatte die Eingabe der Mailadresse nun funktioniert, also sollte das Einloggen bei Kopano möglich sein. Der Weg zur Kopano-Loginseite war hier übrigens kein Problem, von der UCS-Startseite ließ sich die Kopano WebApp wie erwartet öffnen.

Danach sollte das Einloggen mit meinem Usernamen möglich sein. Doch weit gefehlt – der Login funktionierte nicht, die Login-Daten wurden trotz mehrfacher und zweifellos richtiger Eingabe nicht akzeptiert. Ich erinnerte mich an das Video, in dem der Autor erwähnte, einmal das Passwort „offscreen“ geändert zu haben. Zwar handelte es sich dabei um den Login bei Nextcloud, aber vielleicht – so mein Gedanke – war dies auch eine Lösung für das Login-Problem bei Kopano. Also wieder zurück zu UCS in die Benutzerverwaltung und das Passwort erneut setzen. Wobei das genaugenommen falsch ist, denn ich konnte nicht dasselbe Passwort einfach nur ein weiteres Mal nutzen, dies wurde von UCS abgelehnt. Einerseits bei einer Passwort-Policy verständlich, bei der nur Passwörter eingesetzt werden können, die vorher noch nicht in Benutzung gewesen waren, in diesem Fall jedoch eine weitere Hürde für den Home-Server-Betrieb. Als ich das Passwort geändert hatte, konnte ich mich auch bei Kopano einloggen – hurra! Aber mal ehrlich – was soll das? Wenn dieser Weg nicht im Video genannt worden wäre, hätte ich sicherlich noch länger nach einer Lösung gesucht. Doch war es wirklich eine Lösung? Meines Erachtens handelte es sich eher um einen schlechten Workaround, der noch dazu keinen Einzelfall darstellte. Im Video war der Schritt notwendig, leider geht der Autor auch nicht näher darauf ein, ob und wenn ja, welche Lösung es tatsächlich für dieses Problem geben könnte. Denn eine solche ist es bei weitem nicht. Man stelle sich vor, UCS läuft bereits mit einer gewissen Anzahl von Usern, beispielsweise in einem kleinen Unternehmen. Irgendwann möchte man eine weitere Komponente nutzen, die aus dem App Center nachinstalliert wird. Durch den Einsatz von UCS erhofft man sich letztlich eine einfache Administration, eine Abstimmung der Komponenten bzw. Server-Software untereinander, eine leichte Administrierbarkeit usw.. Wenn dann für alle User die Passwörter neu gesetzt werden müssen, ist das ein absolutes Killerargument gegen UCS.

Danach habe ich mir Kopano eigentlich nur noch halbherzig angesehen. Der erste Eindruck – es ist nicht schön. Die Web-App ist einfach nur hässlich, wenn man den Vergleich mit Gmail oder ähnlichen Mail-Anwendungen ziehen möchte. Vielleicht lag es auch am viel zu roten Theme, mit dem die Univention-Fassung ausgestattet war, denn die Screenshots auf den offiziellen Kopano-Webseiten sehen von der Farbgestaltung ein wenig anders aus, in meinen Augen geringfügig ansprechender. Nichtsdestotrotz – „schön“ ist anders. Gmail & Co. machen es doch vor, dass und wie es möglich ist, ein ansprechendes Design mit effizienter Benutzbarkeit zu vereinen.

Kein Spaß, kein System

Nach diesen zwei Stunden mit Univention Corporate Server hatte ich genug. Die Hakeligkeiten waren inzwischen zu echten Ärgernissen geworden, weiter wollte ich mich damit auch nicht beschäftigen. Insofern habe ich die komplette VM mit UCS und dessen Apps wieder gelöscht. Denn so machte es irgendwie keinen Spaß.

Zielgruppen und Szenarien

Nehmen wir an, die Zielgruppe besteht aus „Nebenbei-Admins“, z.B. möchte man einfach und schnell einen Home-Server betreiben oder aber die IT besteht in kleinerem Unternehmen aus einer Person, die bereits zu 150% ausgelastet ist. In einer solchen Situation würde ich einfach schnell zum Ziel kommen wollen, das System müsste wie aus einem Guss sein oder zumindest so wirken, alle Komponenten müssten ineinander greifen, die Benutzeroberfläche müsste es einem möglichst leicht machen, alle notwendigen Services einzurichten. Insbesondere müssten alle Dienste aufeinander abgestimmt sein, die geschilderten Probleme mit der erneuten Passwortvergabe oder der fragwürdigen Möglichkeit, erst nach Installation eines Mailservers eine Mailadresse eines Users eingeben zu können, sprechen eindeutig gegen UCS. Die Idee, die Server-Komponenten als Container mit Hilfe von Docker zu betreiben, finde ich ja grundsätzlich gut. Aber die Integration in das Kernsystem müsste um einiges besser funktionieren.

Als zweites Szenario könnte UCS in größeren Unternehmen zum Einsatz kommen, die nicht nur eine eigene Abteilung für den IT-Betrieb besitzt, sondern auch ausreichend Kapital, um auf die Subskriptionsmodelle zurück zu greifen. Dazu gäbe es jedoch Alternativen, vom kompletten SaaS-Modell von Google und Microsoft über den Einsatz eigener Exchange-Server, falls das bereits obligatorische Microsoft Office inkl. Outlook standardmäßig verwendet wird. Oder die IT-Abteilung setzt angesichts der vorhandenen Kompetenz und Leistungsstärke auf eine eigene Lösung aus Standard-Open-Source-Komponenten, die mit jeder Linux-Distribution einher gehen. Zwar ist die Installation eines solchen Systems initial mit einem höheren Aufwand verbunden, dafür kennt die IT-Abteilung hinterher auch alle Details. Darauf aufbauend lassen sich letztlich ebenfalls Lösungen wie Zarafa/Kopano und ähnliches betreiben. Oder aber man nutzt die Dienste von Systemhäusern, die eine schlüsselfertige und für das jeweilige Unternehmen maßgeschneiderte Lösung aufbauen.

Mein drittes Szenario besteht aus dem User, der tatsächlich einen Home-Server aufsetzen möchte, also letztlich meinem exemplarischen Anspruch aus den zwei Stunden mit UCS. Wenn ich nun wenig Vorkenntnisse hätte, würde ich erwarten, dass alles auf Anhieb funktioniert. Vielleicht hätte ich nicht die Probleme mit den Domänen, weil ich „*.intranet“ oder ähnliches akzeptieren würde. Aber auch die Nutzerverwaltung und Integration der Komponenten müsste perfekt funktionieren. Wenn ich noch keinen Server hätte und einen „Cloud-Speicher“ bräuchte, würde ich vielleicht sogar auf ein NAS von Synology zurück greifen. Denn neben der eigentlichen Speicher-Funktionalität bieten diese Systeme ebenfalls eine Vielzahl von Server-Komponenten und sogar Docker an, so dass sich ein Home-Server sehr gut aufbauen lässt. Aus meinen letzten Erfahrungen mit Synology kann ich jedenfalls erwähnen, dass die Admin-UI konsistent und gut bedienbar ist, an derartige Probleme wie oben geschildert kann ich mich nicht erinnern. Andererseits könnte der Home-User auch gerade den umgekehrten Weg nehmen wollen, d.h. sein System von der Basis her aufbauen. Dafür gibt es nicht nur Myriaden gute Anleitungen, als Beispiel sei der ISPmail guide for Debian Stretch genannt, sondern man lernt dabei einiges über sein System, weiß letztlich, welche Dienste laufen, wie sie ineinander greifen, wo bei Fehlern evtl. einzugreifen wäre usw.. Darüber hinaus ist man frei in der Wahl der Komponenten, anstatt das Aufwärmen eines Fertiggerichts wird somit selbst gekocht. Und falls man weniger Zeit, aber dafür Vertrauen in Container-Systeme hat, kann man immer noch Docker-Images für die einzelnen Dienste nutzen – oder im Zweifelsfall auch selbst erstellen. Univention wird diese Zielgruppe auch nicht vermissen, denn kaum jemand aus von ihnen hätte jemals eine Subskription gezahlt.

Fazit

So einfach die Installation und Einrichtung im Video gezeigt wird, so sehr sollte man auf die Untertöne und geschnittenen Szenen achten. Denn diese verraten fast mehr als der eigentliche Inhalt. Um es erneut zu erwähnen – das Video an sich ist völlig in Ordnung, der Autor führt den User langsam an UCS heran und beschreibt die ersten Schritte. Wenn sie denn in der Praxis so einfach wären wie dort dargestellt, wäre ich völlig zufrieden! Mein Ziel bestand tatsächlich darin, UCS zu testen und nicht darüber einen Bericht zu schreiben, ansonsten hätte ich währenddessen Screenshots als Beweis für die angesprochenen Probleme angefertigt. Angesichts dieser Unzulänglichkeiten ist UCS für meinen Zweck einfach nicht geeignet, oder anders ausgedrückt, ich gehöre wohl nicht zur Zielgruppe.