Im folgenden wird die Kernfunktionalität des von Gruppe Client Delivery bereitgestellten Satellite 6 beschrieben
Staging
Red Hat Satellite 6 setzt verstärkt auf Staging. Dabei wird eine
Sammlung von Komponenten wie Packages, Erratas und Puppet-Module zu
einer eindeutig definierten Version zusammengefasst. Diese Version eines
Installations- und Konfigurationszustands kann entlang eines Lifecycles
propagiert werden. Verwaltete Systeme sind immer einem bestimmten
Schritt eines Lifecycles zugeordnet und können dadurch in einem
definierten Zustand gehalten werden.
GPG Keys
Für die Einbindung externer Paketquellen empfiehlt es sich, zuvor den entsprechenden GPG-Key zu hinterlegen.
Dazu wählt man den Punkt Content / GPG Keys / + New GPG Key. Der Key kann entweder hochgeladen oder per Copy & Paste eingefügt werden.
Products
Bei Products handelt es sich um Sammlungen von Repositories. Dabei kann
es sich um von Red Hat bereitgestellt Repositories oder um andere
Repositories handeln. Unterstützt werden zur Zeit yum und puppet als
Repository-Typ. Als puppet Repository lässt sich sowohl ein eigenes
Repository, aber beispielsweise auch das Repository von puppetlabs
einbinden (https://forge.puppetlabs.com).
Für alle Red Hat Produkte, für die eine Subscription vorliegt, wird standardmässig ein entsprechendes Product erzeugt.
Um ein neues Product zu erstellen, wählt man im Bereich Content / Products den Punkt + New Product
Dem neu erstellten Product, können daraufhin Repositories zugewiesen werden. Dazu wählt man im Reiter Repositories den Punkt Create Repository
Alternativ zur manuellen Erstellung eines Products und der
entsprechenden Zuweisung eines Repositories, kann die Repo Discovery
Funktion genutzt werden. Nach einem Klick auf Repo Discovery gibt man die entsprechende Einstiegsurl ein und löst das Discovery aus. Dieser Vorgang kann einige Zeit in Anspruch nehmen.
Gibt man beispielsweise https://dl.fedoraproject.org/pub/epel/ für das EPEL Repository an, wird nach dem erfolgreichen Discovery eine Liste aller gefundenen Repositories angezeigt.
Wählt man aus dieser Liste 6/x86_64/ und 7/x86_64/ aus und Klickt auf den Punkt Create selected,
hat man die Möglichkeit die ausgewählten Repositories einem
existierenden Product hinzuzufügen oder ein neues Product aus der
Auswahl zu erstellen.
Sync Plan
Grundsätzlich empfiehlt sich die Einrichtung eines Synchronisationsplans, für die zuvor angelegten Products. Hierzu wählt man Content / Sync Plan und erstellt über den Punkt New Sync Plan
einen neuen Synchronisationsplan. Um den Serverbetrieb währen der
regulären Arbeitszeiten nicht zu sehr zu belasten, wird darum gebeten eine tägliche Synchronisation zu Randzeiten oder Nachts einzurichten.
Nach der Erstellung des Sync Plans kann dieser angewählt werden und über
die Reiter Products / Add mit zuvor definierten Products versehen
werden.
Hinweis: Auch für Red Hat Produkte existiert per default kein Sync Plan. Dieser muss manuell erstellt werden.
Sync Status
Den aktuellen Synchronisationsstatus kann man unter Content / Sync Status einsehen. Hier besteht auch die Möglichkeit, eine einmalige Synchronisation manuell auszulösen.
Lifecycle Management
Lifecycle Environments
Unter Content / Lifecycle Environment lassen sich Staging Pfade
definieren. Damit wird die Strategie bestimmt, wie Software-Stände
gestestet und für den Betrieb bereit gemacht werden. Anzahl der Pfade,
Anzahl der Schritte und ihre Benennung sind frei bestimmbar. Lifecycle
Environments sind abstrakte Definitionen, die selber keinen direkten
Bezug zu Produkten oder Systemen haben. Sie können darum für
verschiedenste Clients oder Gruppen von Clients verwendet werden,
solange sie dem gleichen Ablauf folgen.
Der erste Punkt ist für jeden Pfad vorgegeben. Library bezeichnet den aktuellen synchronisierten Upstream Stand der Produkte und Konfigurationen. Über das + Symbol lassen sich neue Stages in diesem Pfad hinzufügen.
Ein Beispiel wäre:
Library > Development > Testing > Production
Content Views
Was genau z.B. Development oder Production für
Products und Konfigurationen bereitstellt, definieren die Content Views.
Sie fassen Products, zugehörige Erratas und Puppet-Module zusammen.
Mittels der Content Views können und müssen diese Zusammenstellungen
durch die definierten Stages publiziert werden, die Schritte sind
versioniert und die Aktionen über eine History nachvollziehbar.
Abgesehen von der Library, was einem rollenden Release
entspricht, legen die Versionen der Content Views auch die Versionen der
Products etc. fest, wie sie zum Zeitpunkt der Publizierung bestanden.
Ein Content View definiert noch nicht, was genau auf einem Client
installiert wird oder welche Puppet-Module aktiviert werden, es stellt
nur einen Pool bereit, aus dem der Client sich bedienen kann.
Die
Zuordnung von Paketen und Puppet-Modules erfolgt pro Host oder über
Host-Gruppen.
Clients
Red Hat Satellite 6 kennt zwei Arten resp. Stufen von Hosts:
Host - Als Host werden Clients
bezeichnet, die über den Satellite installiert werden sollen oder
installiert worden sind. Informationen zu Netzwerk (Subnet, MAC-Adresse,
Domain), zu installierendes OS, zu Standort und Organisation,
vorgesehene Content View, Installationsquelle und mehr sind für die
Installation notwendig. Ein solcher Host ist aber nicht automatisch ein
für Updates registrierter Client des Satellite.
Content Host - Ein am Satellite registrierter
Client wird vom Satellite als Content Host geführt. Damit ist die
Einsicht in die verwendeten Subscriptions, Verwaltung der aktivierten
Channels oder Installation einzelner Pakete oder Errata möglich.
Clients können in Gruppen zusammengefasst werden. Dazu gibt es zwei Arten von Gruppen:
Host Groups - (Menu Configure) bestimmt die Konfiguration von Clients vor der Installation. Damit kann vor einer Installation festgelegt werden, welches OS und welcher Content View genutzt wird, oder welcher Activation Key verknüpft werden soll.
Host Collections - (Menu Hosts) entspricht ungefähr den Gruppen des Satellite 5. Damit können Clients für gemeinsame Aktionen zusammengefasst werden: Paketinstallation und -Update, oder Zuordnung eines Lifecycle Environment oder Content Views.
Client-Netzwerke
Zur installierende Maschinen müssen einem Netzwerk zugeordnet sein. Neben den üblichen Einstellungen für Subnetze wird hier auch definiert, ob nach der Installation ein statisch oder ein DHCP-konfigurierter Netzwerkadapter genutzt wird. Mit IPAM = None und Boot mode = Static wird eine statische Konfiguration erstellt, mit IPAM = DHCP und Boot mode = DHCP eine dynamische.
Diese Netzwerkkonfigurationen dürfen sich auch überlappen, d. h. ein Subnetz kann einmal statisch und einmal dynamisch konfiguriert erfasst werden, die Installation wird je nach Auswahl in der Host-Definition vorgenommen.
Client Installation
Eine Installation ist möglich über
- ein spezifisches ISO-Image für genau einen Client
- ein allgemeines ISO-Image für eine Reihe ähnlicher Clients
- PXE/TFTP
- Original-ISOs von Red Hat
Provisioning Templates
Damit ein Client automatisiert installiert werden kann, müssen einige
Provisioning Templates verfügbar sein, sonst können keine allgemeine
ISOs gebildet werden oder PXE verwendet werden. Die Templates müssen pro
Organisation konfiguriert werden Hauptmenü / Manage Organisations / Organisationsname / Templates.
Die Templates sind als Bausteine anzusehen, die für bestimmte Aspekte
des Installationsprozesses zuständig sind. Folgende Templates (resp.
Ableitungen davon) sind notwendig und sinnvoll:
- Boot disk iPXE - generic host
- Boot disk iPXE - host
- epel
- fix_hosts
- http_proxy
- idm_register
- Kickstart default iPXE
- Kickstart default PXELinux
- puppet.conf
- PXELinux global default
- Satellite Finish Default
- Satellite Kickstart Default
- Satellite User Data Default
- subscription_manager_registration
- UserData default
Booten mit ISOs vom Satellite
In der Detailansicht zu einem Eintrag in Hosts / All Hosts können die
ISO-Images heruntergeladen werden. Für ein spezifisches Image muss in
der Hostdefinition die IP-Adresse eingetragen sein, für ein allgemeines
Image wird für einen Host der DHCP verwendet.
Ein allgemeines Image kann sowohl für statisch als auch für dynamisch (DHCP) konfigurierte Hosts verwendet werden. Zwingend notwendig ist in beiden Fällen die MAC-Adresse, bei statischer Konfiguration auch IP-Adresse, Netmask, Gateway.
Booten mit ISOs von Red Hat
Die Gruppe Client Delivery stellt originalen ISOs von Red Hat hier zur Verfügung.
Es besteht die Möglichkeit einen Client über diese Boot-ISO zu
installieren. Dabei kann man wahlweise das Basis-Repository in der Form
repo=http://<Server>/<Pfad> als Bootparameter angeben oder
die url während des Installationsvorgangs in die entsprechende
Eingabemaske eintragen.
Bei einer Installation mit Hilfe einer Kickstartdatei definiert man das
zum Installationsmedium passende Basis-Repository durch die Angabe von
url --url=http://id-sat-tst.ethz.ch/<Pfad>. Zusätzliche
Repositories werden in der Form repo --name=<Name>
--baseurl=http://<Server>/<Pfad> in einer Kickstartdatei
angegeben. <Name> ist dabei frei wählbar.
Die anzugebenden Repository URLs kann man im Bereich Content / Products nach Auswahl des entsprechenden Products und des Repositories einsehen.
Client Registrierung
Automatische Registrierung
Ist ein Host-Eintrag einer Host-Gruppe zugeordnet, und die Host-Gruppe einem Aktivierungsschlüssel, muss nicht von Hand registriert werden. Am Ende der Installation wird die Registration automatisch vorgenommen und allfällige Updates installiert.
Manuelle Registration
Zur Registrierung eines Clients, muss zunächst das Katello CA RPM installiert werden.
rpm -Uvh http://id-sat-tst.ethz.ch/pub/katello-ca-consumer-latest.noarch.rpm
Daraufhin kann das System mit Hilfe des subscription-manager Kommandos am Satellite Server registriert werden:
subscription-manager register --org="$org_id" --activationkey="$activation_key"
$org_id ersetzt man mit dem Label der Organisationseinheit und
$activation_key durch den Namen des zu verwendenden Activationkeys.
Das Label der Organisationseinheit entspricht dem Org-Namen in
Kleinbuchstaben. Heisst die Organisationseinheit beispielsweise ID-CD
ist das Label id-cd.
Mit Hilfe des Kommandos
subscription-manager list --available
kann man sich die verfügbaren Products anzeigen lassen. Jedes Product
hat eine sogenannte Pool-ID. Durch Angabe dieser Pool ID, kann man das
Product subscriben.
subscription-manager subscribe --pool="$pool_id"
$pool_id ersetzt man dabei durch die zuvor ermittelte Pool-ID.
Auch yum Repositories lassen sich über den subscription-manager anzeigen, aktivieren oder de-aktivieren.
subscription-manager repos --list
zeigt alle verfügbaren Repositories an.
Es empfiehlt sich zunächst alle nicht benötigten Repositories mit
folgendem Befehl zu deaktivieren und daraufhin nur die wirklich
benötigten Repositories selektiv zu aktivieren:
subscription-manager repos --disable "*"
Mit Hilfe von
subscription-manager repos --enable $repo
lässt sich ein Repository aktivieren. $repo muss dabei durch den Namen des Repositories ersetzt werden.
Hinweis: für die Installation und spätere Nutzung des
katello-agents muss das Red Hat Common repository aktiviert werden und
daraufhin das katello-agent Paket installiert werden.
Nach erfolgreicher Registrierung wird ein Host, der nicht über den Satellite gekickstarted wurde, im Bereich Hosts / Content Hosts aufgeführt.
Known Issues
- Monitor / Content View does not work
- Content / Products / Select Product / Removal of Product not possible due to the lack of permissions
- Hosts / All Hosts / <Client> / Bootdisk Download of specific boot image not possible due to the lack of permission
Literaturverzeichnis