Die Qualitätsuniversität setzt den orcharhino inzwischen (siehe „Wie kommt orcharhino zu Kund:innen?“) für den gesamten Campus ein. Was ursprünglich ein reines Projekt zur Verwaltung zentraler Dienste war, involviert mittlerweile fast alle Institute. Somit hat sich ein Sammelsurium von Tools und Ansätzen in einem Werkzeug konzentriert. Im Zuge dieses Prozesses hat sich gezeigt, dass es den einzelnen beteiligten Einrichtungen (Lehrstühle, Verwaltungseinheiten) wichtig ist, die ursprüngliche Trennung nach Instituten und Lehrstühlen weiterhin abbilden zu können.
Mechanismen, diese Trennung im orcharhino abzubilden, sind in erster Linie die sogenannten Organizations und Locations. Als Organisationen beispielweise existieren Uni für die zentralen Dienste und die Lehrstuhlinfrastruktur sowie Verwaltung und Klinikum. Eine Ebene darunter sind die Locations angesiedelt. Die Verwaltung unterscheidet hier nicht weiter, das Klinikum hat sich für eine Untergliederung in Infrastruktur und Lehrbetrieb entschieden. Für die Organisation Uni gibt es Locations mit den Namen der einzelnen Lehrstühle, RZ, Cluster und Media. Alle Objekte im orcharhino erhalten eine Organization und eine Location zugewiesen. Das ermöglicht das Filtern von Listen und die Vergabe von Rechten.
Zur Authentifizierung von Nutzer:innen hängt der orcharhino am zentralen LDAP Server der Universität und auch an dem des Klinikums. Meldet sich ein Nutzer/eine Nutzerin am Web Frontend an, weist das System der Person einer Nutzungsgruppe zu. Die Zuordnung erfolgt anhand der Gruppenzuordnung im LDAP. Lehrstuhl-Admins beispielsweise sehen nur ihre eigenen Rechner und können auch nur diese verwalten.
Die verwalteten Objekte sind in erster Linie die Hosts, denn damit arbeiten die Admins am meisten, aber beispielsweise auch Subnetze lassen sich in ihren Zugriffserlaubnissen einschränken. Somit können die Admins neu angelegte Hosts nur in bestimmten IP-Bereichen registrieren.
Jeder Administrationseinheit steht ein Klasse-C-Netz zur Verfügung. Fast alle Rechner erhalten öffentliche IPs, nur der Rechencluster befindet sich in einem privaten Netz und für bestimmte Server existiert eine separate DMZ. Das Clusternetz ist relativ stark abgeschottet, ähnlich einer DMZ. Lediglich zwei Nodes sind aus dem Universitätsnetz erreichbar und können Verbindungen nach außen aufbauen: ein Login-Knoten für die Nutzer:innen und der orcharhino Proxy. Letzterer ist eine separate Instanz und gehört zur orcharhino Infrastruktur. Er besitzt keine eigene Web GUI, sondern dient lediglich als Bindeglied für Netzwerke, auf die der orcharhino keinen direkten Zugriff hat, oder spiegelt Repositories, wenn sich das zur Minimierung der genutzten Bandbreite empfiehlt. Er empfängt auch Puppet Reports und dient als Proxy für Ansible Calls. Auf dem orcharhino Proxy laufen ähnliche Dienste wie auf dem orcharhino, allerdings in einer untergeordneten Rolle. Pulp synchronisiert ausgewählte Repositories vom orcharhino – in diesem Fall Debian – und versorgt die Nodes mit Paketen, er ist DHCP Server und Nameserver und liefert per PXE und TFTP die nötigen Daten zum Installieren neuer Nodes.
Neben dem Cluster gibt es derzeit acht Subnetze, die am orcharhino hängen. Dazu gehören ein zentrales Netz, in dem die Serverdienste der Universität liegen (Intranet, Mailserver & Co) und mehrere Institutsnetze, wenn diese eigene zentrale Dienste oder kleine lokale Rechencluster, wie in der Physik oder der Chemie, betreiben.
In allen Netzen läuft ein orcharhino Proxy als Bindeglied zwischen den Hosts und dem orcharhino. Da die Netzwerklast bisher überschaubar ist, verwenden fast alle Hosts den orcharhino direkt als Paketquelle, sie müssen aber ihren jeweiligen orcharhino Proxy als HTTP Proxy verwenden, denn es gibt keine direkte Route – orcharhino selbst hängt in einem internen Netz. Arbeitsplatzrechner sind bisher von der zentralen Verwaltung durch den orcharhino ausgenommen, obwohl zumindest für die Linux Pools darüber nachgedacht wird.
Value and Vision betreibt eine vergleichbare Infrastruktur, hat jedoch vorwiegend private Netze, auf die die Kund:innen per VPN zugreifen. Für jeden Kunden/jede Kundin legen die Admins automatisiert eine eigene Organisation an. Hosts authentifizieren sich gegenüber dem orcharhino per SSL-Zertifikaten und sehen somit nur erlaubte Repositories. Einige Kund:innen hinterlegen selbstentwickelte Software und können so sichergehen, dass keine etwaigen Mitbewerber:innen darauf einfach Zugriff hat.
Die Finesse Bank hat ein zentrales Netz in der Hauptfiliale und Subnetze an den Remote-Standorten. Die orcharhino Proxies dort spiegeln die Repositories vom orcharhino. Die Bedienung des orcharhino obliegt vollständig dem Infrastrukturteam, sodass kein feingranulares Rechtemanagement auf Nutzungsebene nötig ist. Dafür sind strengere Richtlinien für das Netzwerk notwendig. Das liegt eigentlich außerhalb des Bereichs, den orcharhino verwaltet. Die Hardware lässt sich jedoch per Ansible steuern, was sich wiederum über den orcharhino verwalten lässt.
