Gestern haben die openSUSE-Entwickler die neueste Version von openSUSE 13.2 freigegeben. Soviel vorweg: openSUSE macht mit dieser Version einen riesigen Sprung nach vorne. In manchen Bereichen hat openSUSE jetzt aber Ähnlichkeiten zu Fedora: openSUSE 13.2 zeichnet sich nicht nur durch (überwiegend) ganz aktuelle Software-Versionen aus, sondern auch durch einige Neuerungen, die an den experimentellen Charakter von Fedora erinnern. Die Verwendung von btrfs als Standarddateisystem ist dabei nur ein Beispiel.

Software-Versionsnummern

Die wichtigsten Versionsnummern in openSUSE 13.2 sehen so aus:

Basis           Desktop            Programmierung     Server
--------------  ------------------ ---------------    --------------
Kernel    3.16  Gnome        3.14  bash      4.2      Apache    2.4
glibc     2.19  KDE          4.14  gcc       4.8      CUPS      1.5
X-Server  1.16  Firefox      33    Java      8        MariaDB   10
GRUB      2.02  Gimp         2.8   PHP       5.6      OpenSSH   6.6
Systemd   210   LibreOffice  4.3   Python    2.7/3.4  qemu/KVM  2.1
                Thunderbird  31                       Postfix   2.11
                                                      Samba     4.1

Einige Anmerkungen:

• Gnome- und KDE-Freunde werden gleichermaßen zufrieden sind. openSUSE verwendet die jeweils aktuellsten Desktop-Versionen. Wer einen Vorgeschmack auf KDE 5 bekommen möchte, kann das in den Standardpaketquellen enthaltene Paket plasma5-desktop mit Plasma 5.1 installieren.

• Etwas überraschend steht bash nur in Version 4.2 zur Verfügung, obwohl 4.3 aktuell ist.

• Bei Python sind die Versionen 2.7 und 3.4 beide standardmäßig installiert (Kommando python und python3).

• Merkwürdigerweise ist CUPS bei Version 1.5 aus dem Jahr 2012 stehen geblieben. Aktuell ist seit ein paar Wochen 2.0, davor gab es auch noch die Versionen 1.6 und 1.7 (wird z.B. von Ubuntu 14.10 verwendet).

• Ganz aktuell ist hingegen der weitgehend MySQL-kompatible Datenbank-Server MariaDB in der Version 10.0. Diese Version kommt auch in SUSE Enterprise Linux 12 zum Einsatz. RHEL 7 und CentOS 7 sind hier vorsichtiger und setzen auf MariaDB 5.5, Ubuntu ist bisher bei MySQL geblieben. Für openSUSE-Nutzer, die nicht auf MariaDB umsteigen möchten, enthalten die Paketquellen auch alle erforderlichen MySQL-5.6-Pakete.

Installation

Stark überarbeitet, farblich angepasst und deutlich aufgeräumter ist das Installationsprogramm. Standardmäßig verwendet openSUSE das Dateisystem btrfs für die Root-Partition und XFS für die Home-Partition. Gerade Linux-Einsteiger sind gut beraten, mit Änderung der Vorschlagseinstellungen beide Dateisysteme auf ext4 umzustellen. (Mehr Details zu den Dateisystemen folgen weiter unten.)

Nach der Auswahl des Desktop-Systems, der Einstellung der Zeitzone und der Angabe von Benutzernamen und Passworts erscheint die aus früheren Versionen bekannte Zusammenfassung der Installationseinstellungen. Dort können Sie noch Detailveränderungen vornehmen. Empfehlenswert ist oft die Aktivierung von SSH und das Öffnen des SSH-Ports in der Firewall.

Erfreulicherweise kann openSUSE nach Abschluss der Installation sofort genutzt werden. In der Vergangenheit war die Installation zweigeteilt, einige Einstellungen konnten erst nach dem ersten Bootprozess durchgeführt werden.

Für alle, die openSUSE 13.2 virtuell ausprobieren möchten, ist die Integration der VirtualBox-Erweiterungen ein Segen: Die automatische Anpassung der Bildschimauflösung an die Fenstergröße funktioniert auf Anhieb und ohne umständliche Installation von Zusatzpaketen.

YaST

YaST ist nun vollständig in der Programmiersprache Ruby implementiert. Einzelne Module wurden überarbeitet oder neu entwickelt. Der Großteil der YaST-Module wurde allerdings nur durch ein automatisiertes Portierungswerkzeug erstellt. Diese Module funktionieren exakt gleich wie in früheren YaST-Versionen.

Damit hinterlässt YaST wie schon in den vergangenen Versionen zwiespältige Gefühle: Einerseits ist YaST in seiner Vielfalt von Konfigurationsmöglichkeiten in der Linux-Welt einzigartig. Andererseits ist die Bedienung vieler Module total unübersichtlich; es gibt jede Menge Redundanzen — sowohl innerhalb YaSt als auch mit den Konfigurationswerkzeugen von KDE oder Gnome. Besonders irritierend sind aus meiner Sicht die vielen Module zur Paketverwaltung, zu denen sich je nach Desktop noch KDE- oder Gnome-spezifische Update-Programme gesellen. Hier warte ich seit Jahren auf das große und wirklich überfällige Aufräumen.

Dateisystem

Die größten Veränderungen im Vergleich zu openSUSE 13.1 betreffen zweifelsohne das Dateisystem. Standardmäßig verwendet openSUSE nun btrfs für die Systempartition und xfs für die Home-Partition. Wenn bei kleinen Installationen, z.B. in virtuellen Maschinen, nur wenig Speicherplatz zur Verfügung steht, wird das home-Verzeichnis in die Systempartition integriert.

openSUSE macht intensiven Gebrauch der btrfs-Subvolumes. Derartige Subvolumes sind gewissermaßen virtuelle Dateisysteme innerhalb eines btrfs-Dateisystems. openSUSE verwendet solche Subvolumes unter anderem für die Verzeichnisse /tmp, /var/lib/xxx, /var/log, /var/spool etc. Das führt dazu, dass /etc/fstab und gleichermaßen die Ergebnisse der Kommandos df und mount recht unübersichtlich aussehen. (lsblk kennt hingegen keine btrfs-Subvolumes und zeigt nur das Dateisystem als Ganzes an.)

Eine Liste aller Subvolumes finden Sie übrigens auch im YaST-Modul Partitionierer (tolle Übersetzung!): Dort wählen Sie in der Seitenleiste den Punkt btrfs an und wählen dann die gewünschte Partition aus. Bearbeiten führt dann in einen Dialog, der die Eigenschaften der Partition anzeigt. Dort gibt es wiederum den Button Subvolumenverarbeitung, der einen weiteren Dialog öffnet. Dort sind alle Subvolumes aufgelistet. Sie können in diesem Dialog Subvolumes löschen bzw. hinzufügen.

openSUSE nutzt die Snapshot-Funktion von btrfs und legt bei Paket-Installationen, Updates sowie bei vielen Konfigurationsarbeiten automatisch Snapshots an. Zur Verwaltung dieser Snapshots dient das YaST-Modul Snapper.

Die neuen Funktionen sind durchaus faszinierend, werden aber viele Anwender überfordern. Die YaST-Dialoge verraten weder, wie viel Speicherplatz die Subvolumes bzw. Snapshots erfordern, noch geben sie Tipps, welche Snapshots gefahrlos gelöscht werden können. Auf den meisten openSUSE-Installationen werden sich daher im Laufe der Zeit immer Snapshots ansammeln und immer mehr Speicherplatz konsumieren.

Hinweis: btrfs enthält Quota-Funktionen, mit denen sich der Speicherplatz pro Subvolume errechnen lässt. Diese Funktionen gelten aber noch nicht als ganz ausgereift. Weitere Informationen können Sie hier nachlesen: Btrfs Subvolume Quota Groups (PDF), btrfs Wiki, GitHub issues.

Kommentar: Ich betrachte die Abkehr von ext4 als Standarddateisystem mit gemischten Gefühlen. RHEL und CentOS verwenden ja seit Version 7 standardmäßig XFS. openSUSE und SUSE Enterprise setzen seit Version 13.2 bzw. 12 wiederum auf btrfs für die System- und XFS für die Home-Partition. Klar, btrfs bietet eine Fülle neuer Funktionen, und XFS brilliert bei Dateisystemen, die über viele TByte reichen.

Andererseits ist ext4 seit vielen Jahren durch seine hohe Stabilität und Geschwindigkeit bekannt. btrfs kann in dieser Hinsicht definitiv (noch) nicht mithalten, und die Vorteile von XFS kommen nur bei riesigen Dateisystemen zum Tragen. Gleichzeitig vergrößert btrfs die Komplexität der Dateisystemverwaltung erheblich und wird viele Anwender überfordern. df liefert wenig aufschlussreiche Daten, und mit dem Datenfriedhof von btrfs fi df fast niemand etwas anfangen. btrfs erfordert außerdem erheblich Platz für Metadaten; gerade auf kleinen Datenträgern steht dann spürbar weniger freier Speicherplatz zur Verfügung als unter ext4.

Da openSUSE primär von Privatanwendern genutzt wird, erscheint mir für diesen Nutzerkreis ext4 definitiv die bessere Wahl. Wenn Sie kein btrfs-Versuchskaninchen sein wollen, sollten Sie sich bei der Installation für diese Option entscheiden!

Update 6.11.2014: Die irrwitzige Anzahl der btrfs-Subvolumes hat anscheinend damit zu tun, dass Snapper die entsprechenden Verzeichnisse dann leichter von den automatisch erzeugten Snapshots ausnehmen kann. Eine vernünftige Dokumentation zur in openSUSE gewählten btrfs-Konfiguration habe ich bislang leider nicht gefunden. Sehr aufschlussreich ist aber immerhin das Snapper-Kapitel im Administrations-Handbuch zu SUSE Enterprise Linux 12:

https://www.suse.com/documentation/sles-12/pdfdoc/book_sle_admin/book_sle_admin.pdf

Spannend ist dieses Zitat (S. 38):

As a result, partitions containing snapshots need to be larger than “normal” partitions. The exact amount strongly depends on the number of snapshots you keep and the amount of data modifications. As a rule of thumb you should consider using twice the size than you normally would.

Mit anderen Worten: Das SLE-Handbuch empfiehlt, die root-Partition doppelt so groß wie bisher einzurichten, um den zusätzlichen Speicheraufwand von Snapper (+ btrfs) zu kompensieren!

Offensichtlich mache nicht nur ich mir Gedanken zur btrfs-Komplexität. Werfen Sie auch einen Blick auf die folgende Seite:

https://www.marshut.net/krptku/btrfs-in-opensuse-13-2.html

Update 13.11.2014: Durch das Script /etc/cron.daily/suse*-snapper wird die Anzahl der gespeicherten Snapshots auf maximal 10 reduziert. Die Parameter für das Aufräum-Script befinden sich in /etc/snapper/configs/root. Ihre Bedeutung ist in man snapper-configs dokumentiert. Der Platzbedarf durch die Snapshots sollte insofern überschaubar bleiben.

Vorsicht: Das Verzeichnis /var/lib/mysql ist nicht wie /var/log oder /home standardmäßig von den Snapshots ausgenommen. Das bedeutet, dass bei einem vollständigen Rollback auf einen älteren Snapshot alle seither durchgeführten Änderungen in einer MariaDB- oder MySQL-Datenbank verloren gehen. Ist das nun ein Bug oder ein Feature? Tatsache ist, dass das entsprechende PostreSQL-Verzeichnis /var/lib/pgsql sehr wohl von den Snapshots ausgenommen ist. Ich empfehle allen MySQL/MariaDB-Administratoren, vor dem ersten Start des DB-Servers ein btrfs-Subvolume für /var/lib/mysql einzurichten, also:

btrfs sub create /var/lib/mysql

Die Empfehlung im Bug-Bericht ist ähnlich, allerdings soll das Subvolume erst nach der Inbetriebnahme eingerichtet werden. Anscheinend gibt es technische Gründe, warum das Subvolume nicht von vorne herein angelegt wird.

(Übrigens habe ich auch mit dem YaST-Modul Partitionierung versucht, ein derartiges Subvolume zu erzeugen, habe aber nur eine merkwürdige Fehlermeldung -15001 oder so ähnlich erhalten.)

Ende der Updates

Netzwerkkonfiguration

Die Verwaltung der Netzwerkschnittstellen übernehmen wahlweise der Network Manager (bei Notebook-Installationen) oder das Programm Wicked. Wicked kommt standardmäßig bei Desktop-Installationen und in virtuellen Maschinen zum Einsatz. Wenn Sie mit KDE arbeiten, weist ein Icon im Panel darauf hin, dass der Network Manager nicht läuft. Das rote x-Symbol sieht wie ein Hinweis auf einen Fehler aus. Das ist einigermaßen verwirrend, weil das Icon keinerlei Aussage gibt, ob nun tatsächlich eine durch Wicked hergestellte Netzwerkverbindung besteht oder nicht.

Zur Wicked-Konfiguration verwenden Sie das YaST-Modul Netzwerkeinstellungen, dessen Aufbau sich nicht verändert hat. Im Dialogblatt Globale Optionen können Sie bei Bedarf zwischen dem Network Manager oder Wicked umschalten.

Wicked ist eine SUSE-Eigenentwicklung. Brauchbare Dokumentation ist im Netz kaum zu finden. Die Wicked-Seite im openSUSE-Portal ist nur mäßig hilfreich. Einen guten Überblick über die Intentionen von Wicked gibt diese Präsentation (PDF). Implementierungsdetails sind dort aber nicht enthalten. Die finden Sie momentan in den für Entwickler gedachten Dokumentationsdateien auf github.

Links

• Release Announcement
• openSUSE 13.2 im openSUSE-Portal
• Features
• Release Notes
• heise-Testbericht

openSUSE-eBook

Wie in den vergangenen Jahren habe ich Anfang Dezember 2014 auch zu openSUSE 13.2 ein eBook veröffentlicht.