Ich frag mich die ganze Zeit, was der Mist soll.
Irgendwie habe ich das Gefühl dass da was im Busch ist.

Für mich bahnt sich da eine unheilige Dreieinigkeit an, und zwar mit Microsoft, Red Hat und Ubuntu.

von Red hat kommt die Idee, den Bootmanager Grub abzulösen und durch einen in den Kernel integrierten Bootmanager zu ersetzen.
https://linuxnews.de/nmbl-no-more-boot-loader/
https://fizuxchyk.wordpress.com/2024/06/13/nmbl-we-dont-need-a-bootloader/
Als Begründung für diese Idee wird gesagt, Grub sei "behäbig, überladen und fehleranfällig. Das macht die Software schwer zu pflegen."
Über das "schwer zu pflegen" kann ich nicht urteilen, mag sein. Aber dass ein komplexes Projekt nicht dadurch einfacher wird, dass man es in ein noch komplexeres Projekt einbaut, scheint mir auf der Hand zu liegen. Auch die Fehleranfälligkeit von Grub kann ich so nicht sehen, aber vielleicht habe ich bisher nur Glück gehabt.
Mir stellt sich aber auch die Frage, was ist mit Rechnern, die mehrere Distris installiert haben? Kann ich dann beim Kernel auswählen, dass nur der Kernel von Distri foo den Boot-Teil enthält und die anderen ohne diesen installiert werden? Ganz abgesehen davon, wird der Kernel-Booter auch Windows booten können? Betrifft mich zwar nicht, aber solche Windows/Linux-Rechner sollen ja durchaus vorkommen...
Oder anders gefragt, wenn denn Grub so fett und unwartbar gworden ist, warum ihn nicht forken und verschlanken oder - vielleicht noch besser - andere, durchaus schon vorhandene Bootmanager benutzen und weiterentwickeln?
Ein paar Kandidaten wie z.B. burg, GAG, Plop Boot Manager bzw. PlopKexec, refind, SYSLINUX und SyMon Bootmanager würden sich da eventuell schon anbieten. Ob sich der ehrwürdige LiLO auch für moderne Rechner aufbohren lässt kann ich nicht sagen. In dem Zusammenhang fällt mir auch mein Lieblingsbootmanager aus alten Zeiten, XOSL, ein, der es wirklich wert wäre, wieder aufgenommen zu werden.
Aber leider geht der Trend doch offenbar in die Richtung, "packen wir alles denkbare in ein einziges Paket", a la eierlegende Wollmilchsau. Allerdings stimmen mich die vielen kritischen Kommentare auf der Webseite von Linux News doch wieder etwas optimistisch.

viele Grüsse gosia

Hallo gosia,

herzlichen Dank für deine Ausführungen und ja, es scheint wie bei so vielem, eine Wissenschaft zu sein

Wenn seit Kernel 2.6.30 relatime default ist, dann lasse ich alles so wie es ist.
Ich betreibe weder einen Server, noch habe ich ein 24/7 NAS laufen. Ich habe lediglich SSDs in Notebooks.
Den trim Befehl wende ich von Zeit zur Zeit an und den Einsatz von zswap werde ich mir mal etwas genauer anschauen.

Viele Grüße
Roberto

Hallo Roberto,
das ist so ein Thema bei dem zwei Leute drei Meinungen haben
Inzwischen haben SSDs eine durchschnittliche garantierte Lebenszeit zwischen drei und fünf Jahren und dass bei ziemlich hohem Datenverkehr, der bei normalen Rechnern eigentlich nicht erreicht wird - es sei denn Du betreibst einen Server.
Aber gut, was relatime betrifft, so aktualisiert es das Zugriffsdatum nur unter bestimmten Bedingungen, schreibt also weniger. Ganz genau sagt es meine man-Page zu mount (Option relatime):

"Update inode access times relative to modify or change time. Access time is only updated if the previous access time was earlier than the current modify or change time. (Similar to noatime, but it doesn't break mutt or other applications that need to know if a file has been read since the last time it was modified.)"
"Aktualisierung der Inode-Zugriffszeiten relativ zum Modifikations- oder Änderungszeitpunkt. Die Zugriffszeit wird nur dann aktualisiert, wenn die vorherige Zugriffszeit vor der aktuellen Modifikations- oder Änderungszeit lag. (Ähnlich wie noatime, aber es stört nicht mutt oder andere Anwendungen, die wissen müssen, ob eine Datei seit der letzten Änderung gelesen wurde)."

relatime ist übrigens seit Kernel 2.6.30 default, sofern nicht andere Optionen angefordert werden. Es erfüllt also schon mal deine Wünsche.

Noch weniger Schreiboperationen hast Du mit der Option "lazytime". Die benutzt für den Zeitstempel RAM und schreibt erst auf die SSD, wenn entweder der Datei-Inode aufgrund einer Änderung aktualisiert werden muss, oder eine Synchronisation vom RAM mit der SSD erfolgt oder mehr als 24 Stunden seit dem letzten Schreiben der In-Memory-Kopie auf die Festplatte vergangen sind.
Wird nur die Option lazytime angegeben, so wirkt sie im Hintergrund zusammen mit der Default-Option relatime. Kann aber auch mit strictatime kombiniert werden, was nach allgemeinen Angaben dann sehr schreibarm wäre. lazytime hat aber den Nachteil, dass bei einem Systemabsturz der Datei-Zeitstempel maximal 24 Stunden zu alt sein kann. Aber auch hier, wenn Du keinen Server betreibst, der 7-Tage-24-Stunden läuft, dann wäre in diesem Worst-Case die Abweichung natürlich geringer.
zu dem ganzen *atime-Gewussel siehe u.a. hier:
https://smarttech101.com/relatime-atime-noatime-strictatime-lazytime/

Aber abseits von diesen fstab-Optionen gibt es noch mehr Faktoren zur Gesunderhaltung von SSDs:
trim (wie oft und ob überhaupt), Einsatz von zswap statt swap, Reduzierung des Cache-Vorgangs von Browsern und Vermeidung von Hibernation.

viele Grüsse gosia

Hallo zusammen,

ich habe nach einiger Zeit mal wieder eine grundsätzliche Frage, zu der ich im Netz keine befriedigende Antwort gefunden habe.

Ich möchte gerne wissen, ob man die fstab für die Nutzung einer SSD (die heuzutage sicher jeder nutzt), nachträglich anpassen muss.
Es geht mit speziell um die möglichen Ergänzungen "relatime" bzw. "noatime", um die Schreibzugriffe zu reduzieren und somit evtl. die Lebensdauer der SSD zu verlängern.

Ich habe zwei verschiedene Distributionen auf 2 verschiedenen Notebooks mit SSD im Einsatz.
Einmal ein HP Elitebook 640 G9 mit Artix Linux und dann ein Dell Latitude 7490 mit Void Linux.
Beide Original fstab haben bei den Partitionen weder noatime noch relatime eingetragen.

HP Elitebook 640 G9 mit Artix Linux:

# /etc/fstab: static file system information.
# 
# Use 'blkid' to print the universally unique identifier for a device; this may 
# be used with UUID= as a more robust way to name devices that works even if 
# disks are added and removed. See fstab(5). 
# 
# <file system>             <mount point>  <type>  <options>  <dump>  <pass> 
UUID=B77E-C666                            /boot/efi      vfat    defaults,umask=0077 0 2 
UUID=df37c9ad-9d71-4671-84a8-30e17c294643 swap           swap    defaults   0 0 
UUID=9546b426-adb7-4ead-9d5d-d412c09be47a /              ext4    defaults   0 1 
UUID=f7345c09-260c-42c9-bb15-bb11643c2065 /home          ext4    defaults   0 2 
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0

Dell Latitude 7490 mit Void Linux:

UUID=8b3450e6-c22f-491b-956d-b73bb06f8dbe / ext4 defaults 0 1
UUID=a7e6a13c-139e-488a-a1c2-c5eb9f82b3b8 none swap defaults 0 0
UUID=8F48-124C /boot/efi vfat defaults 0 2
UUID=44a58ab8-23e4-4947-96e9-69debef95d69 /home ext4 defaults 0 2
tmpfs /tmp tmpfs defaults,nosuid,nodev 0 0

Im Netz wird von "noatime" zwar mittlerweile abgeraten, aber zu "relatime" habe ich nichts wirklich konkretes gefunden.
Vor allem sind die Beiträge schon relativ alt und ich frage mich, wie man das Ganze heute sieht.

Ich freu mich über jeden Gedanken, jede Idee und jeden Tipp

Viele Grüße
Roberto

"Eins, zwei, drei! Im Sauseschritt
Läuft die Zeit; wir laufen mit." (Wilhelm Busch)
schon wieder ein halbes Jahr fast rum, Zeit für die Veranstaltungstermine im 2. Halbjahr 2024 in Deutschland:

• 09.-13.07. Hacken Open Air (Gifhorn)
• 17.-18.08. FrOSCon 19 (St. Augustin)
• 07.-12.09. Akademy 2024 (Würzburg)
•       12.09. Bitkom Forum Open Source 2024 (Erfurt)
• 19.-21.09. 22. Kieler Open Source und Linux Tage (kilux) (Kiel)
• 20.-22.09. Datenspuren 2024 (Dresden)
• 03.-06.10. MRMCD 2024 (Darmstadt)
• 19.-21.11. Open Source Monitoring Conference (Nürnberg)
• 27.-30.12. Chaos Communication Congress (Hamburg)

auch hier, wer es internationaler haben möchte, kann hier https://foss.events/ nachsehen. Von da stammen alle Termine.

viele Grüsse gosia

Ein entfernter anonymer Angreifer kann eine Schwachstelle in OpenSSL ausnutzen, um beliebigen Code auszuführen, einen Denial-of-Service-Zustand zu verursachen, vertrauliche Informationen offenzulegen und Daten zu manipulieren.
Betroffen sind die OpenSSL-Versionen 3.3, 3.2, 3.1 und 3.0
Gefixt in den Versionen 3.3.1, 3.2.2, 3.1.6, 3.0.14
Wer nicht weiss welche Version installiert ist

openssl version

gibt Auskunft.
Sicherheitswarnung vor neuer Schwachstelle bei OpenSSL
OpenSSL Security Advisory [28th May 2024]

viele Grüsse gosia

Das Alpine Linux-Team hat als großes Update die erste Version der stabilen v3.20-Serie veröffentlicht. Wie üblich steht Alpine Linux in verschiedenen Geschmacksrichtungen zum Download bereit:
Standard, Extended, Netboot, Raspberry Pi, Generic ARM und Mini Root Filesystem für 64-Bit (x86-64), AArch64 (ARM64), ARMv7, 32-Bit (x86), PowerPC 64-Bit Little Endian (ppc64le) und IBM System z (s390x)

Unter der Haube läuft der 6.6 LTS Kernel. Wichtige Neuerungen sind die Unterstützung für die 64-Bit-RISC-V-Architektur und Gnome 64 bzw. KDE Plasma 6-Desktop-Umgebung mit Wayland.
Für die Programmierer gibt es u.a. Python 3.12, Ruby 3.3, Rust 1.78, Crystal 1.12 und Go 1.22.

Alpine Linux ist eine sicherheitsorientierte und leichte Linux-basierte Distribution, die auf der mol C-Standardbibliothek und der BusyBox-Software-Suite basiert, die mehrere Unix-Dienstprogramme in einer einzigen ausführbaren Datei bereitstellt. Es hat standardmäßig keine spezifische grafische Umgebung, so dass Benutzer ihre Installationen vollständig anpassen können.
Als Standard-Init-System wird OpenRC benutzt.
https://alpinelinux.org/posts/Alpine-3.20.0-released.html
https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.20.0

Normalerweise sollte man in unsicheren Netzen, z.B. Hotels, VPN benutzen, damit Unbefugte den Datenverkehr nicht mitlesen können und auch keine Infos zu den Aktivitäten im Internet gesammelt werden. Dies gilt auch für den privaten Netzverkehr am heimischen Computer.
Jetzt haben aber Sicherheitsforscher eine Möglichkeit gefunden, mit der den Usern vorgetäuscht wird, dass sie noch über ein sicheres VPN kommunizieren, in Wirklichkeit wird der Datenverkehr jedoch am VPN vorbei geleitet und kann so unter Umständen vom Angreifer mitgelesen oder zumindest der Zielpunkt, also die gewünschte Webseite erkannt werden.
Für solch einen Angriff (von den Entdeckern "TunnelVision" genannt) wird eine Funktion von DHCP benutzt, die es ermöglicht, statt der im Router vorgesehenen Standard-Route eine andere Daten-Route zu nehmen, also einen Umweg ohne Verschlüsselung.
Zum Glück ist dies jedoch nur möglich, wenn sich der Angreifer im gleichen lokalen Netz befindet, was allerdings leider ausgerechnet in den am Anfang genannten Einsatzgebieten, z.B. ein Hotel-WLAN schnell vorkommt.
Details s. Angreifer können VPNs aushebeln und Daten umleiten

viele Grüsse gosia

Kürzlich wurde in Flatpak eine Sicherheitslücke entdeckt, die es bösartigen oder kompromitierten Flatpak-Anwendungen erlaubt, beliebigen Code ausserhalb der Sandbox auszuführen
https://security-tracker.debian.org/tracker/CVE-2024-32462
https://www.openwall.com/lists/oss-security/2024/04/18/5
Anwender von Flatpak sollten mindestens auf Version 1.14.6 updaten, für ältere Zweige sind die Versionen 1.12.9 und 1.10.9 gepatcht worden.
https://github.com/flatpak/flatpak/security/advisories/GHSA-phv6-cpc2-2fgj

viele Grüsse gosia