1. Verzeichnisstruktur
Dies sollte im Filesystem Hierarchy Standard (2.3 PDF) behandelt werden
/bin/ Essential command binaries that need to be available in single user mode;
for all users, e.g., cat, ls, cp
/sbin/ Essential system binaries, e.g., init, ip, mount.
/usr/bin/ Non-essential command binaries (not needed in single user mode);
for all users
/usr/sbin/ Non-essential system binaries, e.g. daemons for various network-services.
/usr/local/ Tertiary hierarchy for local data, specific to this host.
Typically has further subdirectories, e.g., bin/, lib/, share/
2. Installation
Wo immer möglich verwende ich einen Paketmanager (zB 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 einige Leute bevorzugen dies)
Einige Paketmanager können von RPMs installieren (z. B. yum install oddity.rpm )
Wenn Sie aus dem Quellcode kompilieren, ist es wahrscheinlich kein großer Schritt, Ihr eigenes Paket zu erstellen, damit der Systeminstaller weiß, was Sie getan haben.
Dann reduziert sich Ihr Problem auf z.B. yum remove packagename
Die Alternative besteht darin, eine gute Dokumentation über alle durchgeführten Sysadmin-Aktivitäten zu führen (ich führe sowieso ein Tagebuch in einer Textdatei)
Dinge in allen */sbin-Verzeichnissen sind in der Regel nur für Systemadministratoren nützlich. Sie können sie aus Ihrem PATH heraushalten, 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 gemacht wurden, als die Systeme etwas anders waren.
/sbin tendenziell sehr klein. Dies sind Utilities, die Sie brauchen, wenn Sie wirklich abgespritzt sind. Sie würden dies auf einer minimalen Root-Partition mit /root und /lib ablegen. Die Dinge in /sbin waren früher alle statisch verknüpft, denn wenn Ihre /usr-Partition abgespritzt wird, sind alle dynamisch verknüpften Apps nutzlos. fsck ist hier und statisch verlinkt. Wenn Sie eine Abhängigkeit von /usr haben, können Sie /usr/ offensichtlich nicht fsck. Wenn die Root-Partition abgespritzt wird, sind Sie natürlich sehr am Arsch. Aus diesem Grund ist dies eine so kleine Partition - verringern Sie die Wahrscheinlichkeit eines fehlerhaften Festplattenblocks, indem Sie hier nur sehr wenige Blöcke verwenden.
/usr/sbin Binärdateien sind allgemeine Sysadmin-Tools, mit denen Sie zumindest in den Einzelbenutzermodus wechseln und alle Ihre Volumes mounten können. Sie dürfen dynamisch verlinkt werden.
Die getrennten Partitionen für /sbin (naja, /sbin auf / partition) und /usr machen auch mehr Sinn, wenn man bedenkt, dass Backups sowohl Zeit als auch Band sehr teuer waren. Wenn sie sich auf separaten Partitionen befänden, könnten Sie sie anders planen.
/usr/local kann ein Netzwerkdateisystem sein. Daher gehen lokal geschriebene Sysadmin-Tools, die von vielen Rechnern gemeinsam genutzt werden können, manchmal in /usr/local/sbin. Offensichtlich können keine Netzwerk-Reparatur-Dienstprogramme dorthin gehen.
Auch hier machten viele Dinge mehr Sinn auf großen Rechnern in einer vernetzten Umgebung auf verwalteten Rechnern mit mehreren Volumes, weniger bei einem Linux-Rechner auf einer einzelnen Root-Partition.
Ihre zweite Frage sollte wirklich eine separate Frage hier auf Superuser sein. Es hat nichts mit dem ersten zu tun.
Ja, es ist scheiße, überall Dateien zu haben. Deshalb gibt es viele Verpackungslösungen. RedHat hat RPM entwickelt, das überall verwendet wird. Solaris hatte sein Paketformat. HP/UX hatte ihre, und es gibt apt und viele andere Paketformate. Bewahren Sie die Dinge an den richtigen Stellen (/usr/bin, /usr/lib) auf, aber erlauben Sie einfaches Hinzufügen und Entfernen.
Für Source 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/bin für Sie handhabten. Seit der weiten Verbreitung von Paket-Tools ist dies weniger notwendig, und ich habe ihre Namen vergessen.
Einige Leute installieren gerne in /opt/Paketname und dort alles zusammenhalten. Das gute:alles ist in einem Verzeichnis und eine Deinstallation ist rm -rf /opt/packagename . Die Nachteile davon sind, dass /opt/packagename/bin zu jedem PATH hinzugefügt werden muss, und die Tatsache, dass Leute normalerweise /opt nicht auf einer separaten Partition ablegen und Sie die Root-Partition füllen.