Tumbleweed: Update-Schmerzen

[Alexander Goetzenstein]

Hallo,
bislang habe ich einmal wöchentlich ein Update gemacht:
yast → Software → Alle Pakete → aktualisieren, wenn neuere Version verfügbar

Wenn dann Konflikte auftraten, habe ich mich meist für
(o) nicht installieren
entschieden. Oft weiß ich ja sowieso nicht so genau, was hinter den
Paketnamen steckt und vor allem nicht, was genau warum geändert wurde.
Schon gar nicht so auf die Schnelle, und wenn ich mich zu jedem Paket in
jeder Änderung schlaugoogeln und einlesen wollte, käme ich nicht mehr
hinterher. Bislang ging das Verfahren auch meist ganz gut.

Nicht so jedoch vergangene Woche: da kam die Oberfläche nicht mehr hoch,
und ich habe die Datensicherung zurückgespielt. Dummerweise dauert so
etwas einige Zeit, während der ich den Rechner nicht benutzen kann, und
die übrigen Aktualisierungen (aktuell gibt es da ja wichtiges) sind auch
nicht vollzogen.

Heute nun wollte ich etwas mehr Aufmerksamkeit darauf verwenden, doch
bei den insgesamt 3.177 zu installierenden Paketen werden mir 23
Konflikte angezeigt mit jeweils bis zu sechs Optionen, die jeweils bis
über 20 Pakete betreffen. Dabei sind dann mehrfach Deinstallation von
Plasma-Paketen, Networkmanager, ghc-* und Teilen von Anwendungen wie
digikam-Plugins, die man doch eigentlich braucht (→?) bzw. behalten möchte.

Wie gehe ich da nun am besten vor? Welche Strategie ist empfehlenswert?

[Matthias Gerds]

Am Tue, 2 Apr 2024 09:17:56 +0200

Post by Alexander Goetzenstein
Hallo,
yast → Software → Alle Pakete → aktualisieren, wenn neuere Version verfügbar
Wenn dann Konflikte auftraten, habe ich mich meist für
(o) nicht installieren
entschieden. Oft weiß ich ja sowieso nicht so genau, was hinter den
Paketnamen steckt und vor allem nicht, was genau warum geändert wurde.
Schon gar nicht so auf die Schnelle, und wenn ich mich zu jedem Paket
in jeder Änderung schlaugoogeln und einlesen wollte, käme ich nicht
mehr hinterher. Bislang ging das Verfahren auch meist ganz gut.
Nicht so jedoch vergangene Woche: da kam die Oberfläche nicht mehr
hoch, und ich habe die Datensicherung zurückgespielt. Dummerweise
dauert so etwas einige Zeit, während der ich den Rechner nicht
benutzen kann, und die übrigen Aktualisierungen (aktuell gibt es da
ja wichtiges) sind auch nicht vollzogen.
Heute nun wollte ich etwas mehr Aufmerksamkeit darauf verwenden, doch
bei den insgesamt 3.177 zu installierenden Paketen werden mir 23
Konflikte angezeigt mit jeweils bis zu sechs Optionen, die jeweils bis
über 20 Pakete betreffen. Dabei sind dann mehrfach Deinstallation von
Plasma-Paketen, Networkmanager, ghc-* und Teilen von Anwendungen wie
digikam-Plugins, die man doch eigentlich braucht (→?) bzw. behalten möchte.

Also bei mir waren es über 5000 Pakete durch Kernel-Update auf 6.8.x und
Wechsel von KDE-Plasma v5 auf v6. Das hat auch erst nach mehreren
Anläufen geklappt. Manchmal hilft auch ein wenig zu warten, bis
wirklich alle Pakete im Repo aktualisiert sind. Es kann auch helfen,
nicht gleich alle Pakete zu aktualisieren, sondern nur einen Teil, dann
wieder neu starten, kontrollieren, usw.

Post by Alexander Goetzenstein
Wie gehe ich da nun am besten vor? Welche Strategie ist
empfehlenswert?

K.A. Mich nervt's ehrlich gesagt auch auf die Dauer und überlege, doch
auf eine pflegeleichtere Distro zu wechseln. Meine anderen Rechner haben
alle Debian 12 drauf. Da sind natürlich nicht alle Pakete wirklich
aktuell, aber wenn man wirklich ein sehr aktuelles Paket einer
bestimmten Anwendung braucht, kann man das oft per Flatpak beziehen,
ohne das Gesamtsystem in Mitleidenschaft zu ziehen, weil das dann alle
benötigten Bibliotheken etc. schon mitbringt. Beispiel: Audacity.

M:

[Alexander Goetzenstein]

Hallo,

Post by Matthias Gerds
Am Tue, 2 Apr 2024 09:17:56 +0200

Post by Alexander Goetzenstein
Hallo,
yast → Software → Alle Pakete → aktualisieren, wenn neuere Version verfügbar
Wenn dann Konflikte auftraten, habe ich mich meist für
(o) nicht installieren
entschieden. Oft weiß ich ja sowieso nicht so genau, was hinter den
Paketnamen steckt und vor allem nicht, was genau warum geändert wurde.
Schon gar nicht so auf die Schnelle, und wenn ich mich zu jedem Paket
in jeder Änderung schlaugoogeln und einlesen wollte, käme ich nicht
mehr hinterher. Bislang ging das Verfahren auch meist ganz gut.
Nicht so jedoch vergangene Woche: da kam die Oberfläche nicht mehr
hoch, und ich habe die Datensicherung zurückgespielt. Dummerweise
dauert so etwas einige Zeit, während der ich den Rechner nicht
benutzen kann, und die übrigen Aktualisierungen (aktuell gibt es da
ja wichtiges) sind auch nicht vollzogen.
Heute nun wollte ich etwas mehr Aufmerksamkeit darauf verwenden, doch
bei den insgesamt 3.177 zu installierenden Paketen werden mir 23
Konflikte angezeigt mit jeweils bis zu sechs Optionen, die jeweils bis
über 20 Pakete betreffen. Dabei sind dann mehrfach Deinstallation von
Plasma-Paketen, Networkmanager, ghc-* und Teilen von Anwendungen wie
digikam-Plugins, die man doch eigentlich braucht (→?) bzw. behalten möchte.

Also bei mir waren es über 5000 Pakete durch Kernel-Update auf 6.8.x und
Wechsel von KDE-Plasma v5 auf v6. Das hat auch erst nach mehreren
Anläufen geklappt. Manchmal hilft auch ein wenig zu warten, bis
wirklich alle Pakete im Repo aktualisiert sind. Es kann auch helfen,
nicht gleich alle Pakete zu aktualisieren, sondern nur einen Teil, dann
wieder neu starten, kontrollieren, usw.

Post by Alexander Goetzenstein
Wie gehe ich da nun am besten vor? Welche Strategie ist
empfehlenswert?

K.A. Mich nervt's ehrlich gesagt auch auf die Dauer und überlege, doch
auf eine pflegeleichtere Distro zu wechseln. Meine anderen Rechner haben
alle Debian 12 drauf. Da sind natürlich nicht alle Pakete wirklich
aktuell, aber wenn man wirklich ein sehr aktuelles Paket einer
bestimmten Anwendung braucht, kann man das oft per Flatpak beziehen,
ohne das Gesamtsystem in Mitleidenschaft zu ziehen, weil das dann alle
benötigten Bibliotheken etc. schon mitbringt. Beispiel: Audacity.

inzwischen habe ich es über zypper dup gemacht, da kamen praktisch keine
Nachfragen. Das System startete auch wieder, auf den ersten Blick läuft
auch alles.

Aber ich habe ein neues -kleineres- Problem: die Oberfläche verhält sich
anders. Die fehlende Eindeutschung wird mit der Zeit sicher noch
nachgeholt, aber was mich wirklich nervt, ist der nun nötige Doppelklick
für Vieles von Programmstart bis Auswahl von Dateien. Dummerweise habe
ich keine Möglichkeit gefunden, das wieder auf Einfachklick umzustellen.
Wo versteckt es sich?

(cp 2 de.comp.os.unix.apps.kde)
(wenn ich nur wüsste, wie ich ein fup hinbekomme...)

[Matthias Gerds]

Am Tue, 2 Apr 2024 13:14:32 +0200

Post by Alexander Goetzenstein
Hallo,

Post by Matthias Gerds
Am Tue, 2 Apr 2024 09:17:56 +0200

Post by Alexander Goetzenstein
Hallo,
yast → Software → Alle Pakete → aktualisieren, wenn neuere Version verfügbar
Wenn dann Konflikte auftraten, habe ich mich meist für
(o) nicht installieren
entschieden. Oft weiß ich ja sowieso nicht so genau, was hinter den
Paketnamen steckt und vor allem nicht, was genau warum geändert
wurde. Schon gar nicht so auf die Schnelle, und wenn ich mich zu
jedem Paket in jeder Änderung schlaugoogeln und einlesen wollte,
käme ich nicht mehr hinterher. Bislang ging das Verfahren auch
meist ganz gut.
Nicht so jedoch vergangene Woche: da kam die Oberfläche nicht mehr
hoch, und ich habe die Datensicherung zurückgespielt. Dummerweise
dauert so etwas einige Zeit, während der ich den Rechner nicht
benutzen kann, und die übrigen Aktualisierungen (aktuell gibt es da
ja wichtiges) sind auch nicht vollzogen.
Heute nun wollte ich etwas mehr Aufmerksamkeit darauf verwenden,
doch bei den insgesamt 3.177 zu installierenden Paketen werden mir
23 Konflikte angezeigt mit jeweils bis zu sechs Optionen, die
jeweils bis über 20 Pakete betreffen. Dabei sind dann mehrfach
Deinstallation von Plasma-Paketen, Networkmanager, ghc-* und
Teilen von Anwendungen wie digikam-Plugins, die man doch
eigentlich braucht (→?) bzw. behalten möchte.

Also bei mir waren es über 5000 Pakete durch Kernel-Update auf
6.8.x und Wechsel von KDE-Plasma v5 auf v6. Das hat auch erst nach
mehreren Anläufen geklappt. Manchmal hilft auch ein wenig zu
warten, bis wirklich alle Pakete im Repo aktualisiert sind. Es kann
auch helfen, nicht gleich alle Pakete zu aktualisieren, sondern nur
einen Teil, dann wieder neu starten, kontrollieren, usw.

Post by Alexander Goetzenstein
Wie gehe ich da nun am besten vor? Welche Strategie ist
empfehlenswert?

K.A. Mich nervt's ehrlich gesagt auch auf die Dauer und überlege,
doch auf eine pflegeleichtere Distro zu wechseln. Meine anderen
Rechner haben alle Debian 12 drauf. Da sind natürlich nicht alle
Pakete wirklich aktuell, aber wenn man wirklich ein sehr aktuelles
Paket einer bestimmten Anwendung braucht, kann man das oft per
Flatpak beziehen, ohne das Gesamtsystem in Mitleidenschaft zu
ziehen, weil das dann alle benötigten Bibliotheken etc. schon
mitbringt. Beispiel: Audacity.

inzwischen habe ich es über zypper dup gemacht, da kamen praktisch
keine Nachfragen. Das System startete auch wieder, auf den ersten
Blick läuft auch alles.
Aber ich habe ein neues -kleineres- Problem: die Oberfläche verhält
sich anders. Die fehlende Eindeutschung wird mit der Zeit sicher noch
nachgeholt, aber was mich wirklich nervt, ist der nun nötige
Doppelklick für Vieles von Programmstart bis Auswahl von Dateien.
Dummerweise habe ich keine Möglichkeit gefunden, das wieder auf
Einfachklick umzustellen. Wo versteckt es sich?

Bin auch ein absoluter Doppelklick-Hasser. Warum muss man nun unbedingt
alles wie in diesem dämlichen Windows machen? Verstehe ich nicht.
Doppelklick ist jetzt Standard.

KDE-Systemeinstellungen (systemsettings)
Arbeitsbereich
Allgemeines Verhalten
Klicken auf Dateien und Ordner

Viel Spaß am Gerät -

M:

[Martin Schnitkemper]

Post by Matthias Gerds
Bin auch ein absoluter Doppelklick-Hasser. Warum muss man nun unbedingt
alles wie in diesem dämlichen Windows machen? Verstehe ich nicht.

Das wurde unter den KDE-Entwicklern auch lange diskutiert
https://invent.kde.org/plasma/plasma-desktop/-/issues/72

mit dem Ergebnis, dass man sich für den Doppelklick als Standard
entschieden hat, vor allem auch um es Windows-Umsteigern einfacher zu
machen.

Unter bestimmten Umständen macht der Doppelklick auch Sinn, denn der
einfache Klick dient zur Dateiauswahl oder der Erweiterung einer Auswahl,
und es kann durchaus vorkommen, dass wenn man in der Verzeichnisansicht an
der falschen Stelle klickt unbeabsichtigt eine Datei geöffnet statt eine
Auswahl getroffen oder erweitert wird.

Die Änderung betrifft auch nur neue Installationen oder neu angelegte
Benutzer. Die Wahlmöglichkeit bestand immer schon, und wenn jemand für sich
den Einfachklick konfiguriert hatte, müsste er bei einem Update auch
übernommen werden.

[Matthias Gerds]

Am Wed, 3 Apr 2024 10:00:59 +0200

Post by Martin Schnitkemper

Post by Matthias Gerds
Bin auch ein absoluter Doppelklick-Hasser. Warum muss man nun
unbedingt alles wie in diesem dämlichen Windows machen? Verstehe
ich nicht.

Das wurde unter den KDE-Entwicklern auch lange diskutiert
https://invent.kde.org/plasma/plasma-desktop/-/issues/72
mit dem Ergebnis, dass man sich für den Doppelklick als Standard
entschieden hat, vor allem auch um es Windows-Umsteigern einfacher zu
machen.
Unter bestimmten Umständen macht der Doppelklick auch Sinn, denn der
einfache Klick dient zur Dateiauswahl oder der Erweiterung einer
Auswahl, und es kann durchaus vorkommen, dass wenn man in der
Verzeichnisansicht an der falschen Stelle klickt unbeabsichtigt eine
Datei geöffnet statt eine Auswahl getroffen oder erweitert wird.
Die Änderung betrifft auch nur neue Installationen oder neu angelegte
Benutzer. Die Wahlmöglichkeit bestand immer schon, und wenn jemand
für sich den Einfachklick konfiguriert hatte, müsste er bei einem
Update auch übernommen werden.

Unter TW hat das zumindest im Dateimanager Dolphin eine Weile nicht
funktioniert (nur Doppelklick). Da habe ich HB-Männchen gespielt. Jetzt
geht der Einfachklick wieder. Schont die Sehnenscheiden.

M:

[Martin Schnitkemper]

Post by Matthias Gerds
Also bei mir waren es über 5000 Pakete durch Kernel-Update auf 6.8.x und
Wechsel von KDE-Plasma v5 auf v6. Das hat auch erst nach mehreren

Das ist vor allem dem Umstand geschuldet, das SUSE wegen des
xz-Backdoor-Vorfalls ein Rollback auf die letzte als sicher geltende
Version 5.4 durchgeführt und somit alle Pakete neu gepackt hat:
https://www.reddit.com/r/openSUSE/comments/1brt6pr/2000_package_update_for_tumbleweed_an_explanation/?rdt=48437

[Matthias Gerds]

Am Tue, 2 Apr 2024 19:03:35 +0200

Post by Martin Schnitkemper

Post by Matthias Gerds
Also bei mir waren es über 5000 Pakete durch Kernel-Update auf
6.8.x und Wechsel von KDE-Plasma v5 auf v6. Das hat auch erst nach
mehreren

Das ist vor allem dem Umstand geschuldet, das SUSE wegen des
xz-Backdoor-Vorfalls ein Rollback auf die letzte als sicher geltende
https://www.reddit.com/r/openSUSE/comments/1brt6pr/2000_package_update_for_tumbleweed_an_explanation/?rdt=48437

Hoffentlich haben sie alles erwischt. Zum Glück hatte ich kein
openssh-server laufen, aber vielleicht gibt's ja auch noch andere
Einfallstore. Die richtige Entspannung will sich bei mir also dennoch
nicht einstellen, denn wenn der Wurm einmal im Heimnetz ist ...

M:

[Martin Schnitkemper]

Post by Matthias Gerds
Einfallstore. Die richtige Entspannung will sich bei mir also dennoch
nicht einstellen, denn wenn der Wurm einmal im Heimnetz ist ...

Wenn, dann ist das Kind doch eh schon in den Brunnen gefallen.

Die problematische Version wurde ab 24.02. verteilt und die
Sicherheitslücke erst am 29.03. entdeckt und publiziert; im ungünstigsten
Fall könnte das Hintertürchen also schon gut vier Wochen aktiv gewesen.

Nach derzeitigem Stand sind ist nur der sshd betroffen, und auch nur, wenn
er gegen die liblzma gelinkt wurde; bei Arch ist das beispielsweise nicht
der Fall, entsprechend entspannt ging man auch an das Problem heran. Ob das
bei openSUSE auch so ist, kannst du mit einem einfachen ldd "$(command -v
sshd)" herausfinden.

Damit die Hintertür ausgeführt wird, müssen neben einer gültigen Signatur
auch noch weitere Vorbedingungen erfüllt sein:
https://www.heise.de/news/xz-Attacke-Hintertuer-entraetselt-weitere-Details-zu-betroffenen-Distros-9671588.html

[Matthias Gerds]

Am Wed, 3 Apr 2024 10:07:41 +0200

Post by Martin Schnitkemper

Post by Matthias Gerds
Einfallstore. Die richtige Entspannung will sich bei mir also
dennoch nicht einstellen, denn wenn der Wurm einmal im Heimnetz ist
...

Wenn, dann ist das Kind doch eh schon in den Brunnen gefallen.
Die problematische Version wurde ab 24.02. verteilt und die
Sicherheitslücke erst am 29.03. entdeckt und publiziert; im
ungünstigsten Fall könnte das Hintertürchen also schon gut vier
Wochen aktiv gewesen.
Nach derzeitigem Stand sind ist nur der sshd betroffen, und auch nur,
wenn er gegen die liblzma gelinkt wurde; bei Arch ist das
beispielsweise nicht der Fall, entsprechend entspannt ging man auch
an das Problem heran. Ob das bei openSUSE auch so ist, kannst du mit
einem einfachen ldd "$(command -v sshd)" herausfinden.

Hatte ich bei meinen Debian12-Systemen schon gemacht. Da kam immer nur

------------------------------------
ldd "$(command -v sshd)" | grep xz
ldd: ./: Keine reguläre Datei
------------------------------------
Auch bei Tumbleweed ist das (jetzt nach Updates?) so.

Post by Martin Schnitkemper
Damit die Hintertür ausgeführt wird, müssen neben einer gültigen
https://www.heise.de/news/xz-Attacke-Hintertuer-entraetselt-weitere-Details-zu-betroffenen-Distros-9671588.html

Weitere Infos, gut. Das meiste war mir bereits durch entsprechende
Videos bekannt.


M:

[R Daneel Olivaw]

Post by Matthias Gerds
Am Wed, 3 Apr 2024 10:07:41 +0200

Post by Martin Schnitkemper

Post by Matthias Gerds
Einfallstore. Die richtige Entspannung will sich bei mir also
dennoch nicht einstellen, denn wenn der Wurm einmal im Heimnetz ist
...

Wenn, dann ist das Kind doch eh schon in den Brunnen gefallen.
Die problematische Version wurde ab 24.02. verteilt und die
Sicherheitslücke erst am 29.03. entdeckt und publiziert; im
ungünstigsten Fall könnte das Hintertürchen also schon gut vier
Wochen aktiv gewesen.
Nach derzeitigem Stand sind ist nur der sshd betroffen, und auch nur,
wenn er gegen die liblzma gelinkt wurde; bei Arch ist das
beispielsweise nicht der Fall, entsprechend entspannt ging man auch
an das Problem heran. Ob das bei openSUSE auch so ist, kannst du mit
einem einfachen ldd "$(command -v sshd)" herausfinden.

Hatte ich bei meinen Debian12-Systemen schon gemacht. Da kam immer nur
------------------------------------
ldd "$(command -v sshd)" | grep xz
ldd: ./: Keine reguläre Datei
------------------------------------
Auch bei Tumbleweed ist das (jetzt nach Updates?) so.

Post by Martin Schnitkemper
Damit die Hintertür ausgeführt wird, müssen neben einer gültigen
https://www.heise.de/news/xz-Attacke-Hintertuer-entraetselt-weitere-Details-zu-betroffenen-Distros-9671588.html

Weitere Infos, gut. Das meiste war mir bereits durch entsprechende
Videos bekannt.

Tumbleweed ist ein Rolling Release wobei immer die neueste Packages
eingespielt werden, da ist man praktisch Beta Tester. Mit solchen
Problemen muss man ab und zu mal rechnen.
Ja, ich benutze Leap.

[Matthias Gerds]

Am Wed, 3 Apr 2024 15:14:33 +0200

Post by R Daneel Olivaw

Post by Matthias Gerds
Am Wed, 3 Apr 2024 10:07:41 +0200

Post by Martin Schnitkemper

Post by Matthias Gerds
Einfallstore. Die richtige Entspannung will sich bei mir also
dennoch nicht einstellen, denn wenn der Wurm einmal im Heimnetz
ist ...

Wenn, dann ist das Kind doch eh schon in den Brunnen gefallen.
Die problematische Version wurde ab 24.02. verteilt und die
Sicherheitslücke erst am 29.03. entdeckt und publiziert; im
ungünstigsten Fall könnte das Hintertürchen also schon gut vier
Wochen aktiv gewesen.
Nach derzeitigem Stand sind ist nur der sshd betroffen, und auch
nur, wenn er gegen die liblzma gelinkt wurde; bei Arch ist das
beispielsweise nicht der Fall, entsprechend entspannt ging man auch
an das Problem heran. Ob das bei openSUSE auch so ist, kannst du
mit einem einfachen ldd "$(command -v sshd)" herausfinden.

Hatte ich bei meinen Debian12-Systemen schon gemacht. Da kam immer nur
------------------------------------
ldd "$(command -v sshd)" | grep xz
ldd: ./: Keine reguläre Datei
------------------------------------
Auch bei Tumbleweed ist das (jetzt nach Updates?) so.

Post by Martin Schnitkemper
Damit die Hintertür ausgeführt wird, müssen neben einer gültigen
https://www.heise.de/news/xz-Attacke-Hintertuer-entraetselt-weitere-Details-zu-betroffenen-Distros-9671588.html

Weitere Infos, gut. Das meiste war mir bereits durch entsprechende
Videos bekannt.

Tumbleweed ist ein Rolling Release wobei immer die neueste Packages
eingespielt werden, da ist man praktisch Beta Tester. Mit solchen
Problemen muss man ab und zu mal rechnen.
Ja, ich benutze Leap.

Nach Jahr(zehnt)en openSUSE benutze ich über Tumbleweed (abgeraucht),
LMDE (Linux Mint Debian Edition) jetzt auch meist Debian 12 stable. Nur
der Hauptrechner hat noch LMDE, ein anderer TW. Aber den werde ich wohl
zur Schonung meiner Nerven über kurz oder lang umstellen auf was
Pflegeleichteres.

Weißt Du, was das mit diesem openSUSE Micro OS auf sich hat?

M:

[R Daneel Olivaw]

Post by Matthias Gerds
Am Wed, 3 Apr 2024 15:14:33 +0200

Post by R Daneel Olivaw

Post by Matthias Gerds
Am Wed, 3 Apr 2024 10:07:41 +0200

Post by Martin Schnitkemper

Post by Matthias Gerds
Einfallstore. Die richtige Entspannung will sich bei mir also
dennoch nicht einstellen, denn wenn der Wurm einmal im Heimnetz
ist ...

Wenn, dann ist das Kind doch eh schon in den Brunnen gefallen.
Die problematische Version wurde ab 24.02. verteilt und die
Sicherheitslücke erst am 29.03. entdeckt und publiziert; im
ungünstigsten Fall könnte das Hintertürchen also schon gut vier
Wochen aktiv gewesen.
Nach derzeitigem Stand sind ist nur der sshd betroffen, und auch
nur, wenn er gegen die liblzma gelinkt wurde; bei Arch ist das
beispielsweise nicht der Fall, entsprechend entspannt ging man auch
an das Problem heran. Ob das bei openSUSE auch so ist, kannst du
mit einem einfachen ldd "$(command -v sshd)" herausfinden.

Hatte ich bei meinen Debian12-Systemen schon gemacht. Da kam immer nur
------------------------------------
ldd "$(command -v sshd)" | grep xz
ldd: ./: Keine reguläre Datei
------------------------------------
Auch bei Tumbleweed ist das (jetzt nach Updates?) so.

Post by Martin Schnitkemper
Damit die Hintertür ausgeführt wird, müssen neben einer gültigen
https://www.heise.de/news/xz-Attacke-Hintertuer-entraetselt-weitere-Details-zu-betroffenen-Distros-9671588.html

Weitere Infos, gut. Das meiste war mir bereits durch entsprechende
Videos bekannt.

Tumbleweed ist ein Rolling Release wobei immer die neueste Packages
eingespielt werden, da ist man praktisch Beta Tester. Mit solchen
Problemen muss man ab und zu mal rechnen.
Ja, ich benutze Leap.

Nach Jahr(zehnt)en openSUSE benutze ich über Tumbleweed (abgeraucht),
LMDE (Linux Mint Debian Edition) jetzt auch meist Debian 12 stable. Nur
der Hauptrechner hat noch LMDE, ein anderer TW. Aber den werde ich wohl
zur Schonung meiner Nerven über kurz oder lang umstellen auf was
Pflegeleichteres.
Weißt Du, was das mit diesem openSUSE Micro OS auf sich hat?

https://get.opensuse.org/de/leapmicro/5.5/ (überwiegend Englisch), und
mehr weiß ich auch nicht.

[Martin Schnitkemper]

Post by R Daneel Olivaw
Tumbleweed ist ein Rolling Release wobei immer die neueste Packages
eingespielt werden, da ist man praktisch Beta Tester. Mit solchen
Problemen muss man ab und zu mal rechnen.

Das hätte bei einer Distribution mit festen Releasezyklen genau so
passieren können, wenn die Hintertür zum Zeitpunkt des Release schon
bestanden aber noch unentdeckt geblieben wäre.

Selbst später hätte es noch passieren können, wenn im Rahmen der
allgemeinen Paketupdates ein aktualisiertes xz-Paket ausgeliefert worden
wäre, vor allem weil der böswillige Maintainer auch noch die Distributoren
zu einer schnellen Übernahme der angeblich fehlerkorrigierten Version
gedrängt hatte.

Es ist doch eher dem Zufall und der Hartnäckigkeit eines Andres Freund zu
verdanken, der sich auf die Suche nach einer halben Sekunde Verzögerung
machte, dass die Hintertür relativ schnell aufgeflogen ist und keine
weitere Verbreitung gefunden hat.

[Martin Schnitkemper]

Post by Matthias Gerds
Hatte ich bei meinen Debian12-Systemen schon gemacht. Da kam immer nur
------------------------------------
ldd "$(command -v sshd)" | grep xz
ldd: ./: Keine reguläre Datei

Gibt es denn den sshd auf deinem System? Was sagt denn "whereis sshd"?

Außerdem darf nicht auf "xz" gefiltert werden, weil du ja nach der liblzma
suchst.

Hier liefert
| command -v sshd

ein
| /usr/bin/sshd

womit schon mal eine der bekannten Vorbedingungen nicht erfüllt wäre, und "ldd"

| linux-vdso.so.1 (0x00007ffc0d3e2000)
| libcrypt.so.2 => /usr/lib/libcrypt.so.2 (0x000078fff26f4000)
| libpam.so.0 => /usr/lib/libpam.so.0 (0x000078fff26e3000)
| libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x000078fff268f000)
| libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x000078fff25b7000)
| libcrypto.so.3 => /usr/lib/libcrypto.so.3 (0x000078fff2000000)
| libz.so.1 => /usr/lib/libz.so.1 (0x000078fff259d000)
| libc.so.6 => /usr/lib/libc.so.6 (0x000078fff1e1e000)
| libaudit.so.1 => /usr/lib/libaudit.so.1 (0x000078fff2570000)
| libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x000078fff2542000)
| libcom_err.so.2 => /usr/lib/libcom_err.so.2 (0x000078fff253c000)
| libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x000078fff1e10000)
| libkeyutils.so.1 => /usr/lib/libkeyutils.so.1 (0x000078fff2535000)
| libresolv.so.2 => /usr/lib/libresolv.so.2 (0x000078fff1dff000)
| /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x000078fff2846000)
| libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0x000078fff1df7000)

und damit ist dann klar, dass auch die liblzma nicht verwendet wird.

[Matthias Gerds]

Am Wed, 3 Apr 2024 15:36:15 +0200

Post by Martin Schnitkemper

Post by Matthias Gerds
Hatte ich bei meinen Debian12-Systemen schon gemacht. Da kam immer nur
------------------------------------
ldd "$(command -v sshd)" | grep xz
ldd: ./: Keine reguläre Datei

Gibt es denn den sshd auf deinem System? Was sagt denn "whereis sshd"?
Außerdem darf nicht auf "xz" gefiltert werden, weil du ja nach der
liblzma suchst.

Auch ohne '| grep xz'
kommt bei mir da dasselbe:
------------------------------
ldd "$(command -v sshd)"
ldd: ./: Keine reguläre Datei
------------------------------

Post by Martin Schnitkemper
Hier liefert
| command -v sshd
ein
| /usr/bin/sshd

Da kann bei mir ja auch nichts kommen, weil ich das Paket openssh-server
nicht installiert hatte/habe.

Post by Martin Schnitkemper
womit schon mal eine der bekannten Vorbedingungen nicht erfüllt wäre, und "ldd"
| linux-vdso.so.1 (0x00007ffc0d3e2000)
| libcrypt.so.2 => /usr/lib/libcrypt.so.2 (0x000078fff26f4000)
| libpam.so.0 => /usr/lib/libpam.so.0 (0x000078fff26e3000)
| libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2
(0x000078fff268f000) | libkrb5.so.3 => /usr/lib/libkrb5.so.3
(0x000078fff25b7000) | libcrypto.so.3 => /usr/lib/libcrypto.so.3
(0x000078fff2000000) | libz.so.1 => /usr/lib/libz.so.1
(0x000078fff259d000) | libc.so.6 => /usr/lib/libc.so.6
(0x000078fff1e1e000) | libaudit.so.1 => /usr/lib/libaudit.so.1
(0x000078fff2570000) | libk5crypto.so.3 => /usr/lib/libk5crypto.so.3
(0x000078fff2542000) | libcom_err.so.2 => /usr/lib/libcom_err.so.2
(0x000078fff253c000) | libkrb5support.so.0 =>
/usr/lib/libkrb5support.so.0 (0x000078fff1e10000) | libkeyutils.so.1
=> /usr/lib/libkeyutils.so.1 (0x000078fff2535000) | libresolv.so.2 =>
/usr/lib/libresolv.so.2 (0x000078fff1dff000) |
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2
(0x000078fff2846000) | libcap-ng.so.0 => /usr/lib/libcap-ng.so.0
(0x000078fff1df7000)
und damit ist dann klar, dass auch die liblzma nicht verwendet wird.

/var/lib/sshd als auch
/usr/lib/liblzma.so.5
sind vorhanden.

Aber /var/lib/sshd/bin/
ist leer.

Will jetzt aber auch nicht nur zum Testen den sshd (opensshd-server)
installieren.

M:

[Martin Schnitkemper]

Post by Matthias Gerds
Da kann bei mir ja auch nichts kommen, weil ich das Paket openssh-server
nicht installiert hatte/habe.

Dann ist doch alles gut.

Post by Matthias Gerds
/usr/lib/liblzma.so.5
sind vorhanden.

Die wird vom xz-Paket bereitgestellt, weil es darauf etliche Abhängigkeiten
gibt, unter anderem von SystemD.

Post by Matthias Gerds
Will jetzt aber auch nicht nur zum Testen den sshd (opensshd-server)
installieren.

Ich habe den sshd installiert aber den Service seit jeher de-aktiviert und
starte ihn nur fallweise, wenn ich ihn mal benötige, und das auch nur für
das interne Netz, von außen ist der Rechner nicht erreichbar.

[Matthias Gerds]

Am Thu, 4 Apr 2024 12:27:28 +0200

Post by Martin Schnitkemper

Post by Matthias Gerds
Da kann bei mir ja auch nichts kommen, weil ich das Paket
openssh-server nicht installiert hatte/habe.

Dann ist doch alles gut.

Post by Matthias Gerds
/usr/lib/liblzma.so.5
sind vorhanden.

Die wird vom xz-Paket bereitgestellt, weil es darauf etliche
Abhängigkeiten gibt, unter anderem von SystemD.

Post by Matthias Gerds
Will jetzt aber auch nicht nur zum Testen den sshd (opensshd-server)
installieren.

Ich habe den sshd installiert aber den Service seit jeher
de-aktiviert und starte ihn nur fallweise, wenn ich ihn mal benötige,
und das auch nur für das interne Netz, von außen ist der Rechner
nicht erreichbar.

Leider ist ja die Erreichbarkeit von außen heutzutage eine riskante
Angelegenheit, wenn man kein IT-Studium hat. Früher habe ich auch
DynDNS benutzt, aber heute traue ich mich das nicht mehr. Vor allem,
weil ich mich auch nicht dauernd um die Absicherung und Kontrolle
desselben kümmern müssen will.
Für die Synchronisierung benutze ich jetzt Syncthing im Heimnetz.
Habe allerdings auch ein NextCloud-Konto. Meine Passwortdatei da
reinzupacken habe ich mich jedoch noch nicht getraut. Aber kann ja mal
wichtig werden.

M:

[Alexander Goetzenstein]

Hallo,

Post by Martin Schnitkemper

Post by Matthias Gerds
Da kann bei mir ja auch nichts kommen, weil ich das Paket openssh-server
nicht installiert hatte/habe.

Dann ist doch alles gut.

Post by Matthias Gerds
/usr/lib/liblzma.so.5
sind vorhanden.

Die wird vom xz-Paket bereitgestellt, weil es darauf etliche Abhängigkeiten
gibt, unter anderem von SystemD.
xz-lang-5.6.1.revertto5.4-3.2.noarch
xz-5.6.1.revertto5.4-3.2.x86_64
liblzma5-x86-64-v3-5.6.1.revertto5.4-3.2.x86_64
liblzma5-5.6.1.revertto5.4-3.2.x86_64

Ist das dann doppelt vorhanden?