☰

Was bedeuten /usr/sbin, /usr/local/sbin und /usr/local/bin?

tag-icon • tag-icon linux
Was bedeuten /usr/sbin, /usr/local/sbin und /usr/local/bin?

Lassen Sie uns alle Bin- und Sbin-Ordner (aus dem Dateisystemhierarchiestandard) klären:

  • /binist für Binärdateien auf Systemebene
  • /sbinist für andere Binärdateien auf Systemebene, hauptsächlich für den Bootloader und Systemadministratoren
  • /usr/binist für nicht essentielle Binärdateien
  • /usr/sbin- hier beginnt das Chaos - keine wesentlichen Tools für Systemadministratoren? Was bedeutet das? Für Experimente?
  • /usr/local/bin- kein Wort über diesen Ordner
  • /usr/local/sbin- lokal installierte Systemadministrationsprogramme. Nochmal? Wie wäre es mit /usr/sbin?

Die Frage ist also: Warum gibt es so viele Verzeichnisse und was bedeuten die Symbole /usr/sbin, /usr/local/sbinund /usr/local/bin?

Viele Programme werden über Archive verteilt und wir müssen sie aus dem Quellcode erstellen. Normalerweise haben sie Makefiles, also ist das ziemlich einfach. Dieser Prozess beinhaltet das Erstellen von Dateien in usr/local/lib, usr/local/bin... usr/local/was auch immer, ohne dass für ein bestimmtes Programm spezielle Ordner erstellt werden.

Wieso ist es so?

Ich denke, das ist nicht richtig, denn wenn wir das Programm entfernen müssen, müssen wir alle seine Dateien manuell löschen, wenn der Ersteller des Programms sich nicht darum gekümmert hat.

Antwort1

1. Verzeichnisstruktur

Dies sollte abgedeckt werden in derDateisystemhierarchiestandard (2.3 PDF)

/bin/ Wichtige Befehlsbinärdateien, die im Einzelbenutzermodus verfügbar sein müssen;
            für alle Benutzer, zB cat, ls, cp

/sbin/ Wichtige Systembinärdateien, z. B. init, ip, mount.

/usr/bin/ Nicht unbedingt erforderliche Befehlsbinärdateien (im Einzelbenutzermodus nicht erforderlich);
            für alle Benutzer

/usr/sbin/ Nicht unbedingt erforderliche Systembinärdateien, z. B. Daemons für verschiedene Netzwerkdienste.

/usr/local/ Tertiäre Hierarchie für lokale Daten, spezifisch für diesen Host.
            Hat typischerweise weitere Unterverzeichnisse, z.B. bin/, lib/, share/

2. Installation

Ich verwende, wo immer möglich, einen Paketmanager (z. B. yum oder apt-get). Dies ist für eine sehr große Anzahl von Anwendungen möglich, in einigen Fällen müssen Sie möglicherweise ein Repository hinzufügen. Meine zweite Wahl wären Pakete auf niedrigerer Ebene wie RPMs, und das Kompilieren aus dem Quellcode wäre mein letzter Ausweg (aber manche Leute bevorzugen dies).

Einige Paketmanager können von RPMs installieren (zB yum install oddity.rpm)

Wenn Sie aus dem Quellcode kompilieren, ist es wahrscheinlich kein großer Schritt, ein eigenes Paket zu erstellen, damit das Systeminstallationsprogramm weiß, was Sie getan haben.

Dann reduziert sich Ihr Problem auf zByum remove packagename

Die Alternative besteht darin, alle durchgeführten Sysadmin-Aktivitäten gut zu dokumentieren (ich führe sowieso ein Tagebuch in einer Textdatei).

Antwort2

Inhalte in allen */sbin-Verzeichnissen sind normalerweise nur für Systemadministratoren nützlich. Sie können sie aus Ihrem PATH fernhalten, wenn Sie ein normaler Benutzer sind.

Die verschiedenen Verzeichnisse machen nicht viel Sinn, wenn Sie eine einzelne Unix-Maschine auf einer einzelnen Festplatte haben, aber sie machen mehr Sinn, wenn Sie ein großes System und verschiedene Partitionen haben. Denken Sie daran, dass viele dieser Gewohnheiten in den 80er und 90er Jahren entstanden sind, als die Systeme noch etwas anders waren.

/sbinneigt dazu,sehrklein. Dies sind Dienstprogramme, die Sie brauchen, wenn Sie wirklich aufgeschmissen sind. Sie würden dies auf einer minimalen Root-Partition mit /root und /lib ablegen. Dinge in /sbin waren früher alle statisch verknüpft, denn wenn Ihre /usr-Partition aufgeschmissen ist, sind alle dynamisch verknüpften Apps nutzlos. fsck ist hier und statisch verknüpft. Wenn Sie eine Abhängigkeit von /usr haben, können Sie /usr/ natürlich nicht fsck. Wenn die Root-Partition aufgeschmissen ist, sind Sie natürlich aufgeschmissen. Aus diesem Grund ist dies eine so kleine Partition – verringern Sie die Wahrscheinlichkeit eines fehlerhaften Festplattenblocks, indem Sie hier sehr wenige Blöcke verwenden.

/usr/sbinBinärdateien sind allgemeine Sysadmin-Tools, mit denen Sie zumindest in den Einzelbenutzermodus gelangen und alle Ihre Volumes mounten können. Sie dürfen dynamisch verknüpft werden.

Die separaten Partitionen für /sbin (also /sbin auf der /-Partition) und /usr sind auch sinnvoller, wenn man bedenkt, dass Backups sowohl zeitaufwändig als auch sehr teuer waren. Wenn sie sich auf separaten Partitionen befänden, könnten Sie sie anders planen.

/usr/localkann ein Netzwerkdateisystem sein. Daher landen lokal geschriebene Sysadmin-Tools, die von mehreren Rechnern gemeinsam genutzt werden können, manchmal in /usr/local/sbin. Natürlich können keine Dienstprogramme zur Netzwerkreparatur dorthin gelangen.

Auch hier war vieles auf großen Maschinen in einer Netzwerkumgebung auf verwalteten Maschinen mit mehreren Volumes sinnvoller, auf einer einzelnen Linux-Maschine auf einer einzelnen Root-Partition jedoch weniger sinnvoll.

Antwort3

Ihre zweite Frage sollte wirklich eine separate Frage hier auf Superuser sein. Sie hat nichts mit der ersten zu tun.

Ja, es ist nervig, wenn überall Dateien herumliegen. Deshalb gibt es viele Verpackungslösungen. RedHat hat RPM entwickelt, das überall verwendet wird. Solaris hatte sein eigenes Paketformat. HP/UX hatte seines, und es gibt apt und viele andere Paketformate. Bewahren Sie die Dinge je nach Bedarf an den richtigen Stellen auf (/usr/bin, /usr/lib), aber ermöglichen Sie einfaches Hinzufügen und Entfernen.

Für den Quellcode gab es früher Tools, mit denen Sie in einem Unterverzeichnis von /usr/local konfigurieren und installieren konnten und die symbolische Links zu /usr/local für Sie verwalteten. Seit der großen Verbreitung von Pakettools ist dies weniger notwendig und ich habe ihre Namen vergessen.

Manche Leute installieren gerne in /opt/Paketnamenund halten Sie dort alles zusammen. Das Gute: Alles ist in einem Verzeichnis und eine Deinstallation ist rm -rf /opt/packagename. Die Nachteile dabei sind, dass /opt/packagename/bin zu jedem PATH hinzugefügt werden muss und die Tatsache, dass die Leute /opt normalerweise nicht auf einer separaten Partition ablegen und Sie die Root-Partition füllen.

Antwort4

Um Ihre zweite Frage zu beantworten:
Normalerweise werden Programme mit einem sogenanntenPaket-Manager. Ein Paketmanager holt normalerweise Binärpakete (Software, die für eine bestimmte Plattform kompiliert wurde) und verteilt sie in Verzeichnissen (einige laden den Quellcode herunter, kompilieren ihn auf Ihrem Computer und installieren ihn). So weiß der Paketmanager, wo sich die Dateien befinden, die zu einem bestimmten „Programm“ (Paket) gehören, und wenn Sie das Paket entfernen möchten, kümmert sich der Paketmanager darum, alles aufzuräumen.
Selbst wenn Sie den Quellcode selbst kompilieren mit

make

und installieren Sie es mit

make install

Sie können in der Regel tun

make uninstall

wodurch die Dateien aus dem Dateisystem gelöscht werden.

verwandte Informationen