Inventar in Datenbank

Der Satellite Server unterhält ein Inventar der Software auf jedem Client, das in einer Oracle Datenbank gespeichert ist, die sich entweder auf dem Satellite Server oder einem extra Datenbankserver befinden kann. Sobald alle Patches heruntergeladen wurden, berechnet der Satellite Server, wer welchen Patch braucht. Danach erstellt er für jeden Client einen Zeitplan. Die eigentliche Installation des Patches plant dann der Admin des Clients. Damit bietet der Satellite Server eine Lösung für Anwender, die eine absolute Kontrolle benötigen, über die auf ihren Servern eingespielten Sicherheits-packages und alle Informationen darüber. Er erlaubt Red-Hat-Kunden die größte Flexibilität und zugleich Sicherheit beim Updaten ihrer Server.

Der Satellite Server braucht wie bereits erwähnt eine Datenbank, die auf einem separaten Server oder auf dem Satellite Server selbst laufen kann. Beide Optionen sind weitgehend identisch, aber nicht ganz. Unterschiede ergeben sich insbesondere bei den Hardwareanforderungen, bei den Installationsschritten und bei der Wartung.

Für die Einbindung des Satellite Servers in ein Netzwerk bieten sich drei verschiedenen Topologien an: einzelner Satellite Server, mehrere Satellite Server, horizontal abgestuft und vertikal abgestufter Satellite-Proxy.

Die Single-Server-Topologie mit einem einzigen Satellite Server für das gesamte Netzwerk zeigt Abbildung 2 . Diese Konstellation ist ideal für Laborumgebungen, eignet sich aber nicht besonders gut, wenn das Netz in Subnetze aufgeteilt ist, wo einzelne Abteilungen ihre eigenen Server warten. Die Single-Server-Konfiguration ist vergleichsweise billig und leicht zu administrieren, ist aber auf eine nicht-hierarchische Netzwerkstruktur ausgelegt und skaliert in größeren Umgebungen schlecht.

Abbildung 2: Single-Server-Konfiguration: Ein einziger Satellite Server bedient das gesamte interne Netz.

Bei der Topologie mit mehreren Satellite Servern und horizontaler Gliederung, sind verschiedene Satellite Server mit dem Internet verbunden ( Abbildung 3 ). Jeder Server wird mit allen anderen synchronisiert. Bei dieser Variante hat jedes Subnetz oder Projekt seinen eigenen Satellite Server. Zusätzlich ist ein Failover möglich, falls einer der Server ausfällt. Allerdings erhöht diese Variante mit vielen Servern die Kosten erheblich, denn jeder Server braucht eine eigene Lizenz, und das gesamte System ist auch wesentlich aufwendiger zu konfigurieren und zu warten.

Abbildung 3: Mehrere Satellite Server mit horizontaler Gliederung der Topologie: Eine Anzahl Server bedient jeweils ein Subnetz.

Mit Proxy

Die Version Satellite Proxy mit vertikaler Gliederung zeigt Abbildung 4 . Einem einzelnen Satellite Server steht hier eine Anzahl von Satellite Proxies in den verschiedenen Subnetzen gegenüber. Der Proxy-Server fungiert als Pakete-Cache, der die erforderliche Bandbreite der Verbindung zum RHN-Server reduziert. Dabei hat nur der Satellite Server eine direkte Internetverbindung. Die Proxy-Server reden nur mit den Clients, die sie managen, und mit dem Satellite Server.

Abbildung 4: Topologie mit einem zentralen Satellite Server und Proxies bei vertikaler Gliederung.

Zwar liegen die Pakete nun auf den Proxy-Servern, aber die Profile und User-Informationen der Clients speichert weiterhin der Satellite Server. Der Proxy-Server agiert als Vermittler zwischen Client und Satellite Server. Sobald Red Hat einen Patch freigibt, lädt ihn der Satellite Server herunter und prüft, für welches Clientsystem er infrage kommt. Dann verschiebt er den Patch auf den jeweils zuständigen Proxy-Server [3] .

Auf den Proxies werden nur Paket-Dateien gespeichert. Jede Transaktion wird weiter durch den Satellite Server authentisiert.Der Red Hat Update Agent überprüft die GPG-Signatur jedes Pakets, das er vom lokalen RHN Proxy Server oder dem Satellite Server erhält. Die Signaturen werden bei der Installation erzeugt und jedes System hat zur Identifikation, eine Kopie der Signaturen von Satellite und Proxy-Server. Der Proxy Server kann auch so konfiguriert werden, dass er neben den offiziellen Red-Hat-Paketen zusätzlich solche aus privaten Kanälen verwendet. Beispielsweise könnte eine Firma ihre eigene Software entwickeln, paketieren und mit ihrer eigenen GPG-Signatur signieren. Die lokalen RHN-Proxies könnten dann alle individuellen Systeme mit der neuesten Version dieser Software versorgen. (Tatsächlich wäre ein vergleichbares Szenario auch mit den anderen beiden Topologien realisierbar.)