Hallo,
ich habe mir neu Leap 15.2 installiert und wüsste gern was der am besten geeignete Weg ist, jeweils neueste Paketversionen zu bekommen.
Der mitgelieferte Firefox ist mit 78.4 zwar völlig in Ordnung, um Web-Anwendungen zu testen, hätte ich gern auch die neueste Version. Bekomme ich die im Packman Repository oder gibt es einen besseren Weg?
Die openSUSE Philosophie ist, eine einmal ausgelieferte Version einer Software nicht durch eine höhere Version zu erneuern.
Auf gut deutsch:
Die beim Erscheinen der openSUSE Version ausgelieferte Version einer Software bleibt in der Version erhalten, nur bugfixes und Updates dieser Version werden eingepflegt.
Allerdings bestätigen auch Ausnahmen die Regel:
Da z.B. Mozilla eine andere Update-Politik verfolgt, werden hier auch die Versionen, sobald sie nicht mehr unterstützt werden, mit neueren Versionen ersetzt.
Leap benutzt beim Firefox die sogenannten ESR Versionen, da diese längeren Support haben.
Siehe z.B.:
zypper se -s mozillafirefox
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
S | Name | Typ | Version | Arch | Repository
---+------------------------------------+------------+---------------------+--------+-----------
i+ | MozillaFirefox | Paket | 78.4.1-lp152.2.27.1 | x86_64 | OSS-Update
v | MozillaFirefox | Paket | 78.4.0-lp152.2.24.1 | x86_64 | OSS-Update
v | MozillaFirefox | Paket | 78.3.0-lp152.2.21.1 | x86_64 | OSS-Update
v | MozillaFirefox | Paket | 78.2.0-lp152.2.18.1 | x86_64 | OSS-Update
v | MozillaFirefox | Paket | 78.1.0-lp152.2.15.1 | x86_64 | OSS-Update
v | MozillaFirefox | Paket | 78.1.0-lp152.2.12.1 | x86_64 | OSS-Update
v | MozillaFirefox | Paket | 78.0.2-lp152.2.9.1 | x86_64 | OSS-Update
v | MozillaFirefox | Paket | 78.0.1-lp152.2.5.1 | x86_64 | OSS-Update
v | MozillaFirefox | Paket | 68.9.0-lp152.1.1 | x86_64 | OSS
Leap wurde mit Firefox-ESR 68 ausgeliefert, ist nun bei Firefox 78.
Wenn du aktuelle Versionen des Firefox haben möchtest, binde Dir das Mozilla Repo ein:
zypper ar -f https://download.opensuse.org/repositories/mozilla/openSUSE_Leap_15.2/ mozilla
Einbinden allein genügt nicht, die Pakete müssen auch auf das Repo umgestellt werden:
Zunächst mal vielen Dank für die freundliche Hilfe. Der beschriebene Weg hat auch auf Anhieb geklappt. Nach Wechsel des Repositories wurde auf Firefox 83 geupdatet.
Nun bekomme ich beim Aufruf über die GNOME-Toolbar aber das hier:
Diese Meldung habe ich beim upgrade mehrmals erhalten. Wenn ich mich recht erinnere funktioniert das Kommando ‘firefox --ProfileManager’ in einem Konsolenfenster.
Hallo,
das Problem, das mit Firefox bestand konnte ich inzwischen lösen.
Allerdings habe ich das Problem, dass Updates nicht funktionieren, wenn ich (unter GNOME) Software → Aktualisierungen aufrufe und ‘*Herunterladen’ *klicke. (s. Screenshot). https://herrbandow.de/images/screen1220.png
Nach kurzem Abwarten ist der Button wieder anklickbar.
Ich hatte erwartet, dass ich dieselben Updates auch in Yast finden würde. Das ist aber nicht der Fall. Wie kann ich das beheben, ohne alle Updates über das Terminal zu erledigen?
Da OpenSUSE Leap 15.2 auf SLED 15 SP2 basiert (oder umgekehrt) kann ich hier (hoffentlich) kompetent weiterhelfen.
Achtung: Nachfolgende Aussagen sind auf Basis von SLED15SP2, sollten aber auch für OpenSUSE Leap 15.2 gelten!
Der unter einem GNOME-Desktop empfohlene Weg zum Einspielen von Software Updates ist im Starthandbuch von OpenSUSE Leap 15.2 im Kapitel 10.4 und 10.5 beschrieben.
Kapitel 10.4 beschreibt den “alten” Weg zum Einspielen von Softwareupdates via:
gpk-update-viewer
Gpk-update-viewer ist Bestandteil des Softwarepakets (RPM) gnome-packagekit. Gpk-update-viewer wird im Starthandbuch als “GNOME Package Updater” bezeichnet.
Kapitel 10.5 beschreibt den “neuen” Weg zum Einspielen von Softwareupdates via:
gnome-software
Gnome-Software ist Bestandteil des Softwarepakets (RPM) gnome-software. Gnome-Software wird im Starthandbuch als “GNOME Software” bezeichnet.
Gnome-Software wie auch gpk-update-viewer verwenden PackageKit für das Einspielen von Softwareupdates:
PackageKit wiederum verwendet bei OpenSUSE und SUSE Linux Enterprise (SLE) libzypp für das Einspielen von Softwareupdates. https://de.wikipedia.org/wiki/Libzypp
Was wichtig zu wissen ist, aber nicht in der Dokumentation von OpenSUSE oder SUSE Linux Enterprise (SLE) ersichtlich ist:
Die Softwareupdate-Prozedur mit gpk-update-viewer ist im Kapitel 10.4 des Starthandbuchs ausreichend gut beschrieben.
b) gpk-update-viewer führt via PackageKit eine ONLINE-Installation der Softwareupdates durch. Die Softwareupdates werden heruntergeladen und im laufenden System direkt installiert. Solche ONLINE-Installationen können unberechenbare Auswirkungen auf zum Zeitpunkt der Update-Installation laufende Anwendungen haben. Deshalb wird die OFFLINE-Installation empfohlen.
c) GNOME-Software führt via PackageKit eine OFFLINE-Installation der Softwareupdates durch. Ich zitiere Kapitel 10.5 vom OpenSUSE Leap 15.2-Starthandbuch:
While the GNOME Package Updater updates packages within the running system (forcing you to restart the respective applications),
GNOME Software downloads the updates but only applies them at the next reboot of the system.
OFFLINE-Installationen erfolgen durch PackageKit mit Hilfe von Systemd und einem speziellen Aufstartmodus von Systemd, dem “system update mode”. Für mehr Informationen zum “system update mode” von Systemd siehe:
man systemd.offline-updates
Der Aufstartmodus “system update mode” wird verwendet für heikle Updates wie Firmware-Updates (über LVFS/fwupd). Und ist eben auch der ideale Modus zum Einspielen von Softwareupdates (über GNOME Software/PackageKit/libzypp). Nach dem Einspielen des letzten heiklen Updates wird der “system update mode” über einen Rechnerneustart verlassen und danach erfolgt der Rechnerstart im gewohnten Modus (zum Beispiel: GNOME-Desktop Anmeldemaske => gdm).
Im Aufstartmodus “system update mode” hat der Rechner keine Netzwerkverbindung (OFFLINE). Unter SLED15 SP2 benötigt libzypp aber zwingend eine Netzwerkverbindung, somit funktioniert das Einspielen von Softwareupdates per OFFLINE-Installation unter SLED15 SP2 nicht. Ich bezweifle schwer, dass das Einspielen von Softwareupdates per OFFLINE-Installation unter OpenSUSE Leap 15.2 funktionieren soll…
Die Auslösung und die erfolgreiche OFFLINE-Installation kann mit dem PackageKit-Befehl “pkcon” beobachtet respektive kontrolliert werden. Für die Fehlersuche können mit pkcon die Softwareupdates auch händisch im ONLINE- oder OFFLINE-Modus eingespielt werden. Für mehr Informationen zu pkcon siehe:
man pkcon
d) Voraussetzung für einen korrekt funktionierenden “alten” und “neuen” Weg für das Einspielen der Softwareupdates ist ein korrekt konfiguriertes PolKit/PolicyKit. Siehe dazu Kapitel 19 des Sicherheitshandbuch.
Vielen Dank für mich als Einsteiger sind das wertvolle Hinweise. Ich arbeite mich nach und nach in die Konfiguration ein und es macht Spaß. Toll, wenn man mit so ausführlichen Beschreibungen und Erläuterungen ein wenig an die Hand genommen wird.
Verstehe ich das richtig: Die Online-Updates via YaST bleiben von der Konfiguration von Gnome-Software völlig unberührt, oder?
Ich empfehle die Finger von den YAST-Module: Online-Aktualisierung (YOU => Yast Online Update) und “Konfiguration der Online-Aktualisierung” zu lassen. Die Softwareaktualisierung per YAST-Modul “Konfiguration der Online-Aktualisierung” kann man ausschalten und vergessen.
Das automatische Einspielen von Softwareupdates per YAST-Modul “Konfiguration der Online-Aktualisierung” hat den Nachteil, dass der Zeitpunkt des Updates einspielen unpassend sein kann (PackageKit via cron-Job oder systemd). Wenn man genau in diesem Zeitpunkt den Rechner neustartet (reboot) oder herunterfährt (shutdown) könnte dies das System “brechen”, sprich das System ist beim nächsten Rechnerstart in einem nicht lauffähigen Zustand!
Ich verwende jetzt seit 13 Jahren SUSE Linux Enterprise Desktop und habe noch nie die beiden oben genannten YAST-Module eingesetzt!
Heute verwendet man für das Einspielen von Softwareupdates auf einem Desktoprechner mit einer modernen OpenSUSE- oder SUSE Linux Enterprise Desktop-Installation “GNOME Package Updater”.
In naher Zukunft wird man (hoffentlich) für das Einspielen von Softwareupdates das OFFLINE-Update-Verfahren von “GNOME Software” einsetzen (können).
Eine gute Angewohnheit ist es, regelmässig (alle 2/3 Monate) das Einspielen der Softwareupdates mit:
Installation der Softwareupdates optimieren in der Konfigurationsdatei:
/etc/zypp/zypp.conf
=> Zum Beispiel: Ausschalten von Delta-RPM’s, Ausschalten der Installation von “Recommended Packages” und downloadMode = DownloadInAdvance
Beim Wechsel auf eine neuere Version von OpenSUSE Leap nach dem im Starthandbuch, Kapitel 13 “Upgrading the System and System Changes” beschriebenen Verfahren (Einsatz von Zypper empfohlen, siehe Kapitel 13.1.4), sollten alle auf dem System installierten Softwarepakete kontrolliert werden: https://doc.opensuse.org/de/
abriel@localhost:~> sudo zypper up
[sudo] Passwort für root:
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
Die folgenden 12 Paketaktualisierungen werden NICHT installiert:
cups cups-client cups-config cups-filters ghostscript ghostscript-fonts-other
ghostscript-fonts-std ghostscript-fonts-std-converted ghostscript-x11 libcups2
libcupsimage2 parallel-printer-support
Keine auszuführenden Aktionen.
Weil die zwar eine höhere Versionsnummer haben, aber auf ein andere Repositiry ligen als die wovon die jetzitge Version installaliert ist.
zypper nimmt an das wenn du von einen bestimmte Repo installiert hast, das du da bleiben willst.
Also has du möglicherweise die 12 genannte Pakete nicht vom standard Repo, oder du hast ein Repo offen wo neuere Versionen angeboten werden.
Hier meine neuste Eigenentwicklung zum vollautomatischen Einspielen von Sicherheitsupdates auf Desktop-Rechnern unter SLED15SP2. Basierend auf dem bereits vorgestellten “system update mode”. Diese Update-Lösung sollte auch unter openSUSE Leap 15.2 und SLES15SP2 funktionieren. Diese Update-Lösung sollte auch für Server geeignet sein. Zum Beispiel: SLES15SP2 im 24h x 7 Tage-Dauerbetrieb.
**
Achtung: Das regelmässige, händische Einspielen aller nicht-sicherheitsrelevanter Updates ist zu empfehlen! **
Warnung: Die unten vorgestellte Update-Lösung ist noch sehr jung und könnte noch einige “Bugs” enthalten!
/usr/local/sbin/prepareUpdates.sh
#!/bin/bash
########################################################
# /usr/local/sbin/prepareUpdates.sh #
# GrandDixence, 25.05.2021 #
# #
# Sicherheitsupdates herunterladen #
# #
########################################################
# Beginn
echo "**************************************************************************"
echo "Herunterladen der Sicherheitsupdates gestartet.."
/usr/bin/date
echo "--------------------------------------------------------------------------"
# Updates der Software-Update-Werkzeuge herunterladen
echo "Updates der Software-Update-Werkzeuge herunterladen.."
echo " "
/usr/bin/zypper --non-interactive patch --updatestack-only --auto-agree-with-licenses --auto-agree-with-product-licenses --with-interactive --download-only
echo "--------------------------------------------------------------------------"
# Sicherheitsupdates herunterladen
echo "Sicherheitsupdates herunterladen..."
echo " "
/usr/bin/zypper --non-interactive patch --category security --auto-agree-with-licenses --auto-agree-with-product-licenses --with-interactive --download-only
echo "--------------------------------------------------------------------------"
# Müssen Updates der Software-Update-Werkzeuge installiert werden?
echo "Feststellen, ob Updates der Software-Update-Werkzeuge installiert werden müssen..."
EnableInstallUpdates=0
/usr/bin/zypper patch-check --updatestack-only
Rueckgabe=$?
echo " "
if ${Rueckgabe} -eq 100 ];
then
EnableInstallUpdates=1;
echo "Es muss mindestens ein Update der Software-Update-Werkzeuge installiert werden!";
else
echo "Es muss KEIN Update der Software-Update-Werkzeuge installiert werden.";
fi;
echo "--------------------------------------------------------------------------"
# Müssen Sicherheitsupdates installiert werden?
echo "Feststellen, ob Sicherheitsupdates installiert werden müssen..."
/usr/bin/zypper patch-check
Rueckgabe=$?
echo " "
if ${Rueckgabe} -eq 101 ];
then
EnableInstallUpdates=1;
echo "Es muss mindestens ein Sicherheitsupdate installiert werden!";
echo "--------------------------------------------------------------------------";
# Alle zu installierenden Sicherheitsupdates auflisten
echo "Zu installierende Sicherheitsupdates:";
echo " ";
/usr/bin/zypper list-patches --category security;
else
echo "Es muss KEIN Sicherheitsupdate installiert werden.";
fi;
if ${EnableInstallUpdates} -eq 1 ];
then
# System-Update-Modus einschalten
echo "--------------------------------------------------------------------------";
echo "System-Update-Modus einschalten...";
/usr/bin/ln -s /opt/ /security-update;
/usr/bin/ln -s /opt/ /system-update;
# Rechner-Neustart um 03:00 Uhr programmieren
echo " ";
echo "Rechner-Neustart um 03:00 Uhr programmieren...";
/sbin/shutdown -r 03:00 "Rechner-Neustart zum Einspielen von Sicherheitsupdates wird um 03:00 Uhr durchgeführt";
fi;
# Ende
echo "--------------------------------------------------------------------------"
echo "Herunterladen der Sicherheitsupdates beendet."
/usr/bin/date
echo "**************************************************************************"
if ${EnableInstallUpdates} -eq 1 ];
then
echo "Es werden Updates beim nächsten Rechnerstart installiert!";
else
echo "Es werden KEINE Updates beim nächsten Rechnerstart installiert.";
fi;
echo "**************************************************************************"
Linux-Administrator:Innen testen alle Sicherheitsupdates in der Testumgebung ausgiebig, bevor die Produktivumgebung mit diesen neuen Sicherheitsupdates versorgt wird. Siehe dazu:
Beim Einsatz vom oben vorgestellten, vollautomatischen Update-Mechanismus gibt es drei Methoden für den Linux-Administrator, wie von zentraler Stelle aus, die Installation von Sicherheitsupdates in der Produktivumgebung auf mehreren Linux-Rechnern verhindert werden kann.
a) Einsatz des kostenpflichtigen SUSE Manager.
b) Einsatz des kostenlosen Uyuni. Der SUSE Manager basiert auf der kostenlosen Software Uyuni.
Zum Uyuni gibt es vom Benutzer “IT-Gulasch” drei informative Youtube-Videos, welche die Installation und Konfiguration von Uyuni zeigen.
c) Eigenes YUM-Paketdepot erstellen und betreiben. Alle Linuxrechnern in der Produktiv- und Testumgebung so konfigurieren, dass diese Rechnern nur Softwarepakete (RPM) aus dem eigenen YUM-Paketdepot installieren. Die Linuxrechnern der Produktiv- und Testumgebung dürfen keine offiziellen Paketdepots von (Open-)SUSE verwenden!
Nachfolgend wird aufgezeigt, wie man mit Shellskripten ein eigenes YUM-Paketdepot erstellt und betreibt. Die nachfolgenden Informationen basieren auf folgenden Grundlagen:
Auf einem Referenzsystem ist das eigene YUM-Paketdepot wie auch die offiziellen Paketdepots von (Open-)SUSE eingebunden. Das Referenzsystem wird mit den zypper-Befehlen:
Alle verfügbaren Patches anzeigen. # zypper list-patches
Alle nicht installierten Sicherheits-Patches auflisten. # zypper list-patches --category security
Alle verfügbaren Patches auflisten, die vor einem bestimmten Datum veröffentlicht wurden. # zypper list-patches --date 2023-03-28
Informationen zu einem Patch anzeigen. # zypper patch-info SUSE-SLE-Module-Basesystem-15-SP4-2023-1670 # zypper info -t patch SUSE-SLE-Module-Basesystem-15-SP4-2023-1617
Alle nicht installierten Sicherheits-Patches installieren. # zypper patch --category security
Ein einziger Patch installieren. # zypper install -t patch <Name des Patches> # zypper install -t patch SUSE-SLE-SERVER-12-SP2-2017-990
mit den gewünschten Patches versorgt (=> Softwareupdates und Sicherheitsupdates). Siehe dazu auch:
Hinweis: Bei der Installation von Patches werden immer Softwarepakete (RPM) installiert! Bei der Installation eines Patches werden die in den Patchdaten aufgeführten Softwarepakete installiert (RPM). Die Patchdaten findet man im YUM-Paketdepot in einer XML-Datei names updateinfo.xml im Unterverzeichnis repodata. Das Unterverzeichnis repodata enthält alle Metadaten des YUM-Paketdepot.
Mit den nachfolgend vorgestellten Shellskripten werden alle auf dem Referenzsystem installierten Softwarepakete (RPM) lokal auf den Rechner heruntergeladen (downloadUpdates.sh) und dem eigenen YUM-Paketdepot hinzugefügt (addUpdates.sh).
Voraussetzungen für den Einsatz der nachfolgend vorgestellten Shellskripte sind:
Eigener GPG-Schlüssel für das Signieren von eigenen Softwarepakete (RPM) erstellt und auf dem Referenzsystem und allen Linuxrechnern der Produktiv- und Testumgebung installiert.
Der eigene GPG-Schlüssel wird in die RPM-Paketverwaltung mit diesem Befehl importiert:
# rpm --import <Pfad zum eigenen, öffentlichen GPG-Schlüssel>
In das System der RPM-Paketverwaltung darf nur der öffentliche GPG-Schlüssel importiert werden! Keinesfalls den privaten GPG-Schlüssel importieren!
Für mehr Informationen zum Einsatz von GPG-Schlüsseln in der RPM-Paketverwaltung siehe:
# man rpmkeys # man rpmsign
und hier:
Vollautomatische Installation von Sicherheitsupdates mit den vorgängig vorgestellten Systemd-Diensten auf allen Linuxrechnern der Produktiv- und Testumgebung eingerichtet und konfiguriert.
Auf dem Referenzsystem wie auch auf allen Linuxrechnern der Test- und Produktivumgebung ist das eigene YUM-Paketdepot eingebunden:
Mit zypper oder YAST2 das YUM-Paketdepot einhängen.
Im YAST2 die Option “Automatisch aktualisieren” für das YUM-Paketdepot einschalten.
Im YAST2 dem YUM-Paketdepot die Priorität 98 vergeben. Wichtig: Alle offiziellen (Standard-)Update-Paketdepots von (Open-)SUSE erhalten ebenfalls die Priorität 98!
Die Erstellung und Aktualisierung des eigenen YUM-Paketdepots mit den nachfolgenden Shellskripten geht wie folgt auf dem Referenzsystem:
Neue Softwarepakete (RPM) herunterladen: # /usr/local/sbin/downloadUpdates.sh
Neue Softwarepakete (RPM) dem YUM-Paketdepot hinzufügen # /usr/local/sbin/addUpdates.sh
Zur Verteilung und Aktualisierung des eigenen YUM-Paketdepot auf den Linux-Rechnern der Testumgebung gibt es zwei Methoden:
Offline-Methode: Neu erstelltes 7z-Archiv per USB-Memorystick auf die Linuxrechnern der Testumgebung kopieren. Das neu erstellte 7z-Archiv auf den Linuxrechnern der Testumgebung entpacken. Das 7z-Archiv enthält das eigene YUM-Paketdepot.
Online-Methode: Das YUM-Paketdepot mit rsync per SSH vom Referenzsystem auf die Linuxrechnern der Testumgebung synchronisieren. Alternative: Einsatz einer HTTPS-, HTTP-, FTP- oder SMB-Netzwerkablage.
Nach dem erfolgreichen und mangelfreien Testen der neuen Sicherheitsupdates erfolgt die Verteilung und Aktualisierung des eigenen YUM-Paketdepot auf den Linux-Rechnern der Produktivumgebung mit den oben vorgestellten Methoden.
Die nachfolgend vorgestellten Shellskripte wurden für SUSE Linux Enterprise Desktop 15 SP4 geschrieben (SLED15 SP4). Mit Anpassung der offiziellen Paketdepoteinträgen sollten diese Shellskripte auch unter OpenSUSE Leap 15.4 funktionstüchtig sein. Da diese Shellskripte erst einige Tage alt sind, könnten sie noch den einten oder anderen Programmierfehler enthalten!
Diese Behauptung scheint mir übertrieben. Zumindest trifft sie für die von mir installierten und administrierten Leap- und Tumbleweed-Systeme nicht zu. Ich nutze beide Varianten intensiv seit 2014 und bin noch nie in die Verlegenheit gekommen, ein Sicherheitsupdate deinstallieren zu müssen. Falls ich mich täusche waren die Auswirkungen so gering, dass ich die Angelegenheit einfach vergessen habe.