Die Qualitätsuniversität setzt den orcharhino inzwischen (siehe ‘Wie kommt der orcharhino eigentlich zum Kunden?’) für den gesamten Campus ein. Ursprünglich ein reines Projekt zur Verwaltung zentraler Dienste sind mittlerweile fast alle Institute involviert. 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 erlaubt einerseits, Listen zu filtern, und andererseits, Rechte zu vergeben.
Zur Nutzerauthentifizierung hängt der orcharhino am zentralen LDAP-Server der Universität und auch an dem des Klinikum. Meldet sich ein Nutzer am Web-Frontend an, weist das System ihm einer Nutzergruppe 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 Administratoren 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 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 8 Subnetze, die am orcharhino hängen. Dazu gehört 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 – der 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 Kunden per VPN zugreifen. Für jeden Kunden legen die Administratoren automatisiert eine eigene Organisation an. Hosts authentifizieren sich gegenüber dem orcharhino per SSL-Zertifikaten und sehen somit nur erlaubte Repositories. Einige Kunden hinterlegen selbstentwickelte Software und können somit sichergehen, dass kein etwaiger Mitbewerber 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 Infrastruktur-Team, sodass kein feingranulares Rechtemanagement auf Nutzerebene nötig ist. Dafür sind strengere Richtlinien für das Netzwerk nötig. Das liegt eigentlich außerhalb des Bereichs, den der orcharhino verwaltet. Die Hardware lässt sich jedoch per Ansible steuern, was sich wiederum über den orcharhino verwalten lässt.
