SUSE-Repositories
Vorbemerkung
Das Leibniz-Rechenzentrum (LRZ) bezieht – Stand 05/2023 – die Software für SUSE Linux Enterprise (SLE) und openSUSE aus den offiziellen Quellen des Distributors – https://www.suse.com/ – und des openSUSE-Projekts – https://www.opensuse.org/. Um die Zahl der Zugriffe auf die offiziellen Quellen auf ein Mindestmaß zu senken, wird die SUSE-Software in Form sog. Repositories regelmäßig auf LRZ-Server kopiert bzw. dort aktualisiert. Letztere werden auch als LRZ-Software-Verteiler bezeichnet; die jeweiligen Repositories dienen als Installationsquelle der im LRZ aktivierten SUSE-Hosts, nachfolgend auch als SUSE-Clients bezeichnet.
LRZ-SUSE-Mirror mit HTTPS-Installationsquellen
Der Zugriff auf die LRZ-Software-Verteiler vermeidet zudem die Notwendigkeit, jeden einzelnen SUSE-Host beim Distributor zu registrieren. Dies bedeutet, dass das LRZ die Nutzung lizenzpflichtiger SUSE-Software verwalten und überwachen muss. Aus diesem Grund ist der direkte Zugang auf den sog. LRZ-SUSE-Mirror – https://suse.mirror.lrz.de/ – mit seinen HTTPS-Installationsquellen auf bestimmte IP-Adressen und -Subnetze beschränkt. Weitere Details sind auf der Seite zum SUSE-Softwarebezug beschrieben.
LRZ-openSUSE-Mirror mit HTTPS-Installationsquellen
Es gibt zwar den LRZ-openSUSE-Mirror https://opensuse.mirror.lrz.de/, nachdem die grundsätzlich uneingeschränkte Nutzung der offiziellen Paketquelle https://download.opensuse.org/ möglich ist und von dort aktuell – Stand 05/2023 – wesentlich mehr Software beziehbar ist, wird Ersterer nicht auf dem notwendigen Stand gehalten; bei der Verwendung von openSUSE-Repositories empfiehlt sich demnach die Einbindung der offiziellen Quellen.
LRZ-SUSE-Management mit NFS-Installationsquellen
Der o.g. LRZ-SUSE-Mirror dient als Bezugsquelle weiterer LRZ-Software-Verteiler, wie z.B. 'lxins01.srv.lrz.de', deren Repositories als NFS-Installationsquellen der SUSE-Hosts eingebunden werden können. Historisch bedingt gibt es dabei zwei Unterscheidungsmerkmale:
1. SUSE-Repositories
Hierbei handelt es sich in erster Linie um lizenzpflichtige Software für SUSE Linux Enterprise Server (SLES) ab einschl. Version 15, die im NFS-Unterverzeichnis '/repo/ISO/' und '/repo/SUSE/', also z.B. durch die Einbindung von Repositories im Unterverzeichnis 'nfs://lxins01.srv.lrz.de/repo/ISO/' und 'nfs://lxins01.srv.lrz.de/repo/SUSE/', abrufbar ist. Die hier bereitgestellten Repositories sind eine unveränderte Kopie der SUSE-Originalquellen.
2. LRZ-Repositories
Hierbei handelt es sich um die lizenzpflichtige Software für SUSE Linux Enterprise Server (SLES) bis einschl. Version 12 und um die grundsätzlich frei nutzbare Software für openSUSE bis einschl. Version 42, die im NFS-Unterverzeichnis '/nfs/', also z.B. durch die Einbindung von Repositories im Unterverzeichnis 'nfs://lxins01.srv.lrz.de/nfs/', abrufbar ist.
Im Gegensatz zu den vorgenannten SUSE-Reporsitories werden die LRZ-Repositories aus historischen Gründen verschlankt. Zur Einsparung von Speicherplatz, vielmehr jedoch zur Beschleunigung von Neuinstallationen und Update-Zyklen, enthalten die LRZ-Repositories neben der "Erstausgabe" grundsätzlich nur die jeweils aktuell(st)en Softwarepakete. Genauer gesagt werden "Erstausgabe" plus Update-Quelle zusammengefasst; die von SUSE vorgesehene Aufsplittung entfällt.
Zur Technik: Die "Erstausgabe" einer Softwarequelle, bestehend meist aus SUSE-Installations-CDs, -DVDs oder einer, per HTTP/S bzw. S/FTP abrufbaren "Erstquelle", wird zunächst auf den NFS-Server in ein Unterverzeichnis '/nfs/<Repo-Name>/<Repo-Source>/' übertragen und dort per Hardlinks nach '/nfs/<Repo-Name>/' kopiert¹; somit sind zunächst zwei gleiche Repositories abrufbar.
¹) Die abrufbaren Repositories '<Repo-Name>' sind in der Spalte 'LRZ OS-Channel' der "grünen" Tabellen auf der Seite SUSE-OS-Upgrade aufgelistet; je nach Quellmedium besitzt '<Repo-Source>' die Bezeichnung 'CDS', 'DVD', 'FTPoss', 'FTPnon-oss' etc..
Beim sog. LRZ-Repository in '/nfs/<Repo-Name>/' werden die Hardlinks im Lauf der Zeit regelmäßig durch verfügbare Paketupdates ersetzt. Ältere, bereits ersetzte Paketupdates werden gelöscht mit dem, in der Praxis tolerierbaren Nachteil, dass ein Zurücksetzen auf den gelöschten Softwarestand nur nach Paketrestauration aus o.g. Bezugsquelle oder aus einem Backup durch den NFS-Administrator möglich ist.
Die "Erstausgabe" wird für seltene Einsätze aufbewahrt, wenn beispielsweise Neuinstallationen auf Basis der stetig aktualisierten Installationssoftware fehlschlagen. Das Warten bis zum meist zeitnahen Eintreffen von Bugfixes kann somit vermieden werden.
Sowohl eigens erstellte LRZ-Update-Tools, als auch die von SUSE bereitgestellten Installations-Tools, wie YaST oder Zypper, kommen mit den verschlankten Quellen gut und schnell zurecht. In der Vergangenheit war v.a. der deutliche Zeitgewinn beim Aufruf der vorgenannten SUSE-Tools bemerkbar. Hierzu zählte auch der Zeitvorteil, wenn bei Neuinstallationen älterer OS-Versionen noch das Installieren der "Erstausgabe" und im Nachgang die Aktualisierung mit allen Updatepaketen notwendig war. Im Lauf der Zeit sammeln sich bekanntlich mehr und mehr Updatepakete einer OS-Version an; umso mehr wurde der Zeitvorteil bei Neuinstallationen gegenüber der "SUSE-Methode" sichtbar.
Inzwischen sind die SUSE-Tools wesentlich performanter programmiert, kommen mit der Einbindung zahlreicher Repositories wesentlich schneller zurecht und können nun Neuinstallationen aus den aktuell(st)en Softwarepaketen orchestrieren. Insofern ist das Generieren schlankerer LRZ-Repositories nicht mehr notwendig. Der oben beschriebene Nachteil, dass ein "spontanes" Zurücksetzen auf bestimmte Paket-Versionen nicht möglich ist, muss mit Verwendung der SUSE-Repositories nicht mehr toleriert werden. Software-Downgrades sind inzwischen grundsätzlich ohne Mehraufwand möglich.
Signieren von LRZ-Repositories
Zum Signieren von SUSE-Repositories ist der Besitz eines PGP-Schlüsselpaares notwendig. Für o.g. LRZ-Repositories wird deshalb ein eigens generiertes Schlüsselpaar verwendet; der öffentliche Teil ist u.a. in der Datei namens 'gpg-pubkey-c6994baf-60018565.asc' gespeichert; bei älteren, inzwischen nicht mehr unterstützten LRZ-Repositories, wurde 'gpg-pubkey-c18362ae-447b3f94.asc' verwendet. Je nach Aktualität, ist eine der vorgenannten Dateien im jeweiligen LRZ-Repository hinterlegt; die dortigen Dateien './content' sowie './media.1/products' werden mit dem privaten Teil signiert.
In der Regel ist der aktuelle LRZ-Schlüssel bereits auf dem SUSE-Client registriert; falls dies nicht der Fall ist, ist das temporäre oder dauerhafte Vertrauen/Akzeptieren z.B. beim folgenden Zypper-Aufruf notwendig:
Beispiel: Paket-Update mit Zypper
Bei einem `zypper update` kann Folgendes passieren:
> zypper update Retrieving repository 'LRZ-Repo-SLEMweb12x64' metadata New repository or package signing key received: Repository: LRZ-Repo-SLEMweb12x64 Key Name: Leibniz-Rechenzentrum (LRZ) <root@localhost> Key Fingerprint: 538707DA EC1A916A 02399723 B65B03D7 C6994BAF Key Created: Fri Jan 15 13:07:01 2021 Key Expires: Thu Dec 31 13:07:01 2026 Subkey: 012288010AC64A89 2021-01-15 [expires: 2026-12-31] Rpm Name: gpg-pubkey-c6994baf-60018565 Do you want to reject the key, trust temporarily, or trust always? [r/t/a/? shows all options] (r): ^C
Dann muss bitte der Fingerprint des Schlüssels gegen eine starke Referenz geprüft werden; diese Confluence Seite ist keine starke Referenz! Sonst kann es dazu kommen, dass manipulierte Software eingespielt wird.
So wird's beispielsweise gemacht: Starke Referenz selbst prüfen:
# Ursprung des Repo finden > zypper repos --uri Repository priorities are without effect. All enabled repositories share the same priority. # | Alias | Name | Enabled | GPG Check | Refresh | URI --+------------------------+------------------------+---------+-----------+---------+--------------------------------------------------------------------- 1 | LRZ-Repo-SLEMweb12x64 | LRZ-Repo-SLEMweb12x64 | Yes | (r ) Yes | Yes | nfs://lxinst/nfs/SLEMweb12x64 2 | LRZ-Repo-SLES12.5x64 | LRZ-Repo-SLES12.5x64 | Yes | (r ) Yes | Yes | nfs://lxinst/nfs/SLES12.5x64 3 | LRZ-Repo-SLESDK12.5x64 | LRZ-Repo-SLESDK12.5x64 | Yes | (r ) Yes | Yes | nfs://lxinst/nfs/SLESDK12.5x64 4 | edirectory-9.2.1 | edirectory-9.2.1 | No | ---- | ---- | dir:///simbackup/downloads/edir921/eDirectory_921_Linux_x86_64/setup # Repository "LRZ-Repo-SLEMweb12x64" kommt von "nfs://lxinst/nfs/SLEMweb12x64" # Entsprechenden NFS-Mount finden > mount | grep SLEMweb12x64 lxinst:/nfs/SLEMweb12x64 on /var/adm/mount/AP_0xOHtTIa type nfs4 (ro,relatime,vers=4.0,rsize=524288,wsize=524288,namlen=255,soft,proto=tcp,timeo=300,retrans=2,sec=sys,clientaddr=10.156.86.14,local_lock=none,addr=10.156.10.105) # Schlüssel am temporären Mountpoint auslesen > gpg2 /var/adm/mount/AP_0xOHtTIa/gpg-pubkey-c6994baf-60018565.asc Version: GnuPG v2 pub 2048R/1BB5A57D 2021-01-15 [expires: 2026-12-31] uid Leibniz-Rechenzentrum (LRZ) <root@localhost> sig 1BB5A57D 2021-01-15 [selfsig] sub 2048R/2992151E 2021-01-15 [expires: 2026-12-31] sig 1BB5A57D 2021-01-15 [keybind] pub 2048R/C6994BAF 2021-01-15 [expires: 2026-12-31] uid Leibniz-Rechenzentrum (LRZ) <root@localhost> sig C6994BAF 2021-01-15 [selfsig] sub 2048R/0AC64A89 2021-01-15 [expires: 2026-12-31] sig C6994BAF 2021-01-15 [keybind] # gpg-Signatur "C6994BAF" mit Ausgabe von `zypper update` vergleichen
Wenn, wie im o.g. Beispiel keine Unstimmigkeiten erkennbar sind, kann der Schlüssel dauerhaft akzeptiert werden.