openSUSE Projekt – Alle binären Dateien nach /usr verschieben

Der Plan: Alle binären Dateien in /bin, /sbin /lib und /lib64 nach /usr verschieben. Aus Gründen der Kompatiblität werden noch symbolische Links zu den binären Dateien angelegt. Angeschoben wurde diese Idee vom Fedora-Projekt. Bei Fedora ist bereits der Umzug voll im Gange. Greg Kroah-Hartman (greg k-h) hat diesen Vorschlag einfach mal in die Mailingliste openSUSE Factory gestellt und wird zur Zeit heiß diskutiert.

Warum macht man das? Die Verzeichnisse /bin, /sbin, /lib und /lib64 waren damals wichtig, wo noch Festplattenspeicher sehr knapp waren. Die Tools und die Bibliotheken standen auf dem System immer zur Verfügung, während man das Verzeichnis /usr aus Platzgründen auf einer anderen Festplatte ausgelagert hatte. Falls das System die Festplatte/Partition für /usr nicht mounten konnte, so hat man noch ein funktionsfähiges System. Außerdem hat man immer noch die Werkzeuge zur Verfügung, um das System zu reparieren.

Würden wir die Trennung weiterhin beibehalten, so muss ich sagen, dass das heutige Linux-System (aus der Sicht von damals) mehr kaputt als ganz ist. Eine Shellanweisung macht es sogar deutlich, wie abhängig wir heute schon vom /usr Verzeichnis sind.

for i in `find /bin /sbin /lib* -type f -executable`; do ldd ${i} 2>/dev/null | grep usr > /dev/null && echo ${i}; done

Auf einem openSUSE 12.1 (64-bit) sieht so aus:

/bin/systemd-notify
/bin/systemctl
/bin/rpm
/sbin/install-info
/lib/systemd/systemd-stdout-syslog-bridge
/lib/systemd/systemd-uaccess
/lib/systemd/systemd-shutdownd
/lib/systemd/systemd-readahead-collect
/lib/systemd/systemd-initctl
/lib/systemd/systemd-readahead-replay
/lib/systemd/systemd-kmsg-syslogd
/lib/udev/iphone-set-info
/lib/udev/udisks-part-id
/lib/udev/ipod-set-info
/lib/udev/mtp-probe
/lib/udev/udisks-probe-sas-expander
/lib/udev/udisks-dm-export
/lib/udev/udev-acl
/lib/udev/udev-configure-printer
/lib/udev/udisks-probe-ata-smart
/lib/libnss_wins.so.2
/lib64/libgudev-1.0.so.0.1.0
/lib64/security/pam_systemd.so
/lib64/security/pam_pwcheck.so
/lib64/security/pam_smbpass.so
/lib64/security/pam_userdb.so
/lib64/security/pam_cracklib.so
/lib64/security/pam_ck_connector.so
/lib64/libnss_wins.so.2

Auch auf einer älteren openSUSE 11.4 (64-bit) sieht es nicht besser aus:

/bin/rpm
/sbin/install-info
/lib/udev/udisks-probe-ata-smart
/lib/udev/mobile-action-modeswitch
/lib/udev/hid2hci
/lib/udev/udisks-part-id
/lib/udev/udev-configure-printer
/lib/libnss_wins.so.2
/lib64/libnss_wins.so.2
/lib64/security/pam_cracklib.so
/lib64/security/pam_ck_connector.so
/lib64/security/pam_pwcheck.so
/lib64/security/pam_userdb.so

Sogar andere Distributionen sind betroffen: I’m interesting in, how much different Linux distributions are broken.

Das würde bedeuten, dass diese Tools bzw. Bibliotheken bei einem fehlenden /usr Verzeichnis nicht mehr funktionieren.

Wie ist es heute? Mittlerweile haben wir mehr als ausreichende Festplattenkapazität und können gleich ein komplettes Linux-System auf die Platte ziehen oder sogar mehrere Linux-Systeme. Sollte das Linux-System einmal ausfallen, haben wir immer noch unsere Rettungs-CDs, Sicherheitskopien oder sogar ein zweites Linux-System auf der Festplatte, um das System wiederherzustellen. Daher wird dieses Argument als Rettungssystem nicht mehr ziehen.

Was sind eigentlich die Vorteile? Theoretisch können mehrere Linux-System das Verzeichnis /usr teilen, so hat man 2 Fliegen mit einer Klappe geschlagen. Man senkt nicht nur den Wartungsaufwand, sondern auch den benötigten Speicherplatz. Man kann so auch viel leichter einen Snapshot vom /usr Verzeichnis erstellen.

Gibt es irgendwelche Nachteile? Bisher sind keine gravierenden Nachteile bekannt. Es gibt aber einige kleinere Nachteile. Beim Bau der Pakete sind noch die alten Installationspfade /bin, /sbin, /lib und /lib64 enthalten und müssen entsprechend gepatcht werden. Sobald die Verzeichnisse /bin, /sbin, /lib und /lib64 in naher Zukunft endgültig entfernt werden, kann es passieren das einige schlampig geschriebenen Skripten oder proprietäre Programme nicht mehr funktionieren. Die andere Seite der Medaille ist, dass es evtl. zu einem Bruch bei der FHS (Filesystem Hierarchy Standard) und bei der LSB (Linux Standard Base) kommt, die den Standard der Dateisystemordnung sowie den Ort für die binären Dateien vorschreibt. Hier müsste die Linux Foundation die FHS/LSB-Spezifikation abändern, sonst ist die Zertifizierung in Gefahr, was für die kommerziellen Linux-Systeme wie z.B. die „SUSE Linux Enterprise“ Produkte und auch „Red Hat Enterprise Linux“ Produkte hart treffen könnte.

Fazit: Meiner Meinung nach ist der Umzug der binären Dateien längst überfällig. Somit schneiden wir endlich alte Zöpfe ab, die in heutiger Zeit mehr störend als nützlich empfunden wird. Man kann sich viel mehr darauf verlassen, dass die binären Dateien genau da sind, wo sie eigentlich hingehören. Auch die einfachere Wartung über mehrere Linux-Systeme hinweg, sollte man berücksichtigen.

Weitere Informationen und Diskussionen zu diesem Thema:
http://en.opensuse.org/UsrMerge
http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
http://0pointer.de/blog/projects/the-usr-merge.html
https://fedoraproject.org/wiki/Features/UsrMove
http://thread.gmane.org/gmane.linux.redhat.fedora.devel/155511/focus=155547
http://thread.gmane.org/gmane.linux.debian.devel.general/165785
http://thread.gmane.org/gmane.linux.gentoo.devel/72128
http://harald.fedorapeople.org/downloads/usrmove/

VN:F [1.9.22_1171]
Rating: 9.5/10 (4 votes cast)
VN:F [1.9.22_1171]
Rating: +1 (from 3 votes)
openSUSE Projekt - Alle binären Dateien nach /usr verschieben, 9.5 out of 10 based on 4 ratings
Dieser Beitrag wurde in openSUSE veröffentlicht und getaggt , . Ein Lesezeichen auf das Permalink. setzen. Trackbacks are closed, but you can post a comment.

4 Kommentare

  1. Lisufa
    Am 01. Februar 2012 um 10:54 Uhr veröffentlicht | Permalink

    Hey Sebastian,

    interessant, sehr gut und verständlich beschrieben!

    Grüße Uwe d. L.

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
  2. Tom
    Am 10. Februar 2012 um 12:04 Uhr veröffentlicht | Permalink

    Solange die Symlinks bleiben (ich denke z.B. an #!/bin/bash), ist es vmtl. völlig egal, wo die Dateien liegen…

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
    • Am 21. Februar 2012 um 12:29 Uhr veröffentlicht | Permalink

      Hallo Tom,

      der Shebang (#!/bin/bash) im Skript zu ändern, dürfte nicht so ein großes Problem darstellen. In Zukunft (wenn /bin weggefallen ist) wird Bash oder andere Shells anhand der Shebang-Zeile automatisch die richtige Shell ermitteln. Unabhängig ob sie /usr/bin/bash oder /bin/bash heißt. Kriminell wird es, wenn man im Skript überall die Pfade zu den binären Dateien hardgecodet hat. Hier hat der Shell-Programmierer Sorge zu tragen, dass er die CLI-Tools inkl. des relativen Pfades mittels which ermitteln soll. Somit schaltet man schon mal eine wichtige Fehlerquelle aus.

      Gruß

      Sebastian

      VN:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
      VN:F [1.9.22_1171]
      Rating: 0 (from 0 votes)
  3. Am 20. März 2012 um 13:13 Uhr veröffentlicht | Permalink

    Ich hätte ja gerne ein Skript, um bestehende Systeme zu migrieren.

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)

Einen Kommentar hinterlassen

Ihre E-Mail wird niemals veröffentlicht oder weitergegeben. Erforderliche Felder sind mit * markiert

Sie können diese HTML-Tags und -Attribute verwenden <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*
*

:wink: :-| :-x :twisted: :) 8-O :( :roll: :-P :oops: :-o :mrgreen: :lol: :idea: :-D :evil: :cry: 8) :arrow: :-? :?: :!: