Wyjaśnijmy wszystkie foldery bin i sbin (ze standardowej hierarchii systemu plików):

• /bin jest dla plików binarnych na poziomie systemu
• /sbin jest przeznaczony dla innych plików binarnych na poziomie systemu, głównie dla programu ładującego i administratorów systemu
• /usr/bin jest dla nieistotnych plików binarnych
• /usr/sbin- tu zaczyna się bałagan - nie jest to niezbędne narzędzie dla administratorów systemu? Co to znaczy? Do eksperymentów?
• /usr/local/bin - brak słowa o tym folderze
• /usr/local/sbin- lokalnie zainstalowane programy administracyjne systemu. Jeszcze raz? Jak o /usr/sbin?

Więc pytanie brzmi: Dlaczego istnieje tak wiele katalogów i jakie są znaczenia /usr/sbin, /usr/local/sbini /usr/local/bin?

Wiele programów jest dystrybuowanych poprzez archiwa i musimy je budować z kodu źródłowego. Zwykle mają plik makefile, więc jest to dość łatwe. Ten proces obejmuje tworzenie plików w usr / local / lib, usr / local / bin ... usr / local / cokolwiek bez tworzenia określonych folderów dla danego programu.

Dlaczego tak jest

Myślę, że to nie w porządku, ponieważ jeśli musimy usunąć program, musimy ręcznie usunąć wszystkie jego pliki, jeśli twórca programu nie zajął się tym.

1. Struktura katalogów

Powinno to zostać objęte Standardem hierarchii systemu plików ( 2.3 PDF )

/ bin / Niezbędne pliki binarne poleceń, które muszą być dostępne w trybie pojedynczego użytkownika;
            dla wszystkich użytkowników, np. cat, ls, cp

/ sbin / Essential binaria systemowe, np. init, ip, mount.

/ usr / bin / Nieistotne pliki binarne poleceń (niepotrzebne w trybie pojedynczego użytkownika); 
            dla wszystkich użytkowników

/ usr / sbin / Nieistotne pliki binarne systemu, np. demony dla różnych usług sieciowych.

/ usr / local / trzeciorzędna hierarchia danych lokalnych, specyficzna dla tego hosta. 
            Zazwyczaj ma dalsze podkatalogi, np. Bin /, lib /, share /

2. Instalacja

Używam menedżera pakietów tam, gdzie to możliwe (np. Yum lub apt-get). Jest to możliwe w przypadku bardzo dużej liczby aplikacji, w niektórych przypadkach może być konieczne dodanie repozytorium. Moim drugim wyborem byłyby pakiety niższego poziomu, takie jak RPM, a kompilowanie ze źródła byłoby moją ostatnią deską ratunku (ale niektórzy wolą to)

Niektórzy menedżerowie pakietów mogą instalować z RPM (np. yum install oddity.rpm)

Jeśli kompilujesz ze źródła, prawdopodobnie nie jest to duży krok do stworzenia własnego pakietu, aby instalator systemu wiedział, co zrobiłeś.

Wtedy twój problem sprowadza się do np yum remove packagename

Alternatywą jest prowadzenie dobrej dokumentacji na temat wszystkich podejmowanych działań sysadmin (i tak mam dziennik w pliku tekstowym)

Rzeczy we wszystkich katalogach * / sbin są zwykle przydatne tylko dla administratorów systemu. Możesz trzymać je poza swoją ŚCIEŻKĄ, jeśli jesteś zwykłym użytkownikiem.

Różne katalogi nie mają większego sensu, jeśli masz jedną maszynę uniksową na jednym dysku, ale mają większy sens, jeśli masz duży system i różne partycje. Pamiętaj, że wiele z tych nawyków powstało w latach 80. i 90., kiedy systemy były nieco inne.

/sbinbywa bardzo mały. Są to narzędzia, których potrzebujesz, gdy naprawdę jesteś węża. Umieściłbyś to na minimalnej partycji root z / root i / lib. Rzeczy w / sbin były wszystkie połączone statycznie, ponieważ jeśli twoja partycja / usr jest ukryta, wszelkie dynamicznie połączone aplikacje są bezużyteczne. fsck jest tutaj i jest statycznie powiązany. Jeśli masz zależność od / usr, oczywiście nie możesz fsck / usr /. Oczywiście, jeśli partycja root jest ukryta, jesteś bardzo przykręcony. Właśnie dlatego jest to tak mała partycja - zmniejsz prawdopodobieństwo uszkodzenia bloku dysku, używając tutaj bardzo niewielu bloków.

/usr/sbinpliki binarne to ogólne narzędzia sysadmin, w których można przynajmniej przejść do trybu pojedynczego użytkownika i zamontować wszystkie woluminy. Mogą być dynamicznie powiązane.

Oddzielne partycje dla / sbin (cóż, / sbin on / partition) i / usr mają również większy sens, gdy pamiętasz, że tworzenie kopii zapasowych było bardzo drogie zarówno pod względem czasu, jak i taśmy. Jeśli były na osobnych partycjach, można je zaplanować inaczej.

/usr/localmoże być sieciowym systemem plików. Tak więc lokalnie napisane narzędzia sysadmin, które mogą być współużytkowane na wielu komputerach, czasami przechodzą do / usr / local / sbin. Oczywiście żadne narzędzia do naprawy sieci nie mogą się tam znaleźć.

Ponownie wiele rzeczy miało większy sens na dużych komputerach w środowisku sieciowym na zarządzanych komputerach z wieloma woluminami, a mniej na jednym komputerze z Linuksem na jednej partycji root.

Naprawdę powinieneś mieć swoje drugie pytanie jako osobne pytanie tutaj na Superuser. To nie ma związku z pierwszym.

Tak, posiadanie plików w całym miejscu jest do bani. Dlatego istnieje wiele rozwiązań opakowaniowych. RedHat stworzył RPM, który jest używany wszędzie. Solaris miał swój format pakietu. HP / UX miał swoje, i jest apt i wiele innych formatów pakietów. Trzymaj rzeczy we właściwych miejscach (/ usr / bin, / usr / lib) odpowiednio, ale umożliwiają łatwe dodawanie i usuwanie.

Dla źródła istniały narzędzia, które pozwoliłyby ci skonfigurować i zainstalować w podkatalogu / usr / local i obsługiwałyby dowiązania symboliczne do / usr / local / bin. Ponieważ szerokie rozpowszechnianie narzędzi do tworzenia pakietów jest mniej konieczne, zapomniałem ich nazw.

Niektórzy ludzie lubią instalować w / opt / packagename i trzymać wszystko razem. Dobrze: wszystko jest w jednym katalogu, a odinstalowanie rm -rf /opt/packagename. Wadami tego jest konieczność dodania / opt / nazwa_pakietu / bin do ŚCIEŻKI każdego, a także fakt, że ludzie zwykle nie umieszczają / opt na osobnej partycji, a Ty wypełniasz partycję root.

Moje zdanie na temat znaczeń katalogów (z doświadczenia z Debian GNU Linux) jest następujące:

Pierwsze rozróżnienie: sdotyczy administratora

sprzed binkatalog wskazuje, że zawiera narzędzia, które zwykle są przydatne tylko dla administratorów. Zauważ, że np. ifconfigRównież należy do tej kategorii i lubię przywoływać ifconfigjako zwykły użytkownik (aby sprawdzić, czy mam adres IP / połączenie sieciowe), co sprawia, że ​​to rozróżnienie nie jest tak trudne, jak mogłoby się wydawać.

Drugie rozróżnienie localdotyczy „danych lokalnych”

W praktyce najważniejsze jest tutaj to, że menedżerowie pakietów systemu operacyjnego (np. APT) instalują pakiety do normalnej /usrstruktury i pozostawiają to /usr/localbez zmian. Dzięki temu lokalnie skompilowane pakiety lub wewnętrzne skrypty firmy dostarczone przez administratora systemu mogą zostać umieszczone w miejscu, w /usr/localktórym nigdy nie będą zakłócały poprawnie spakowanych plików.

Można dyskutować, czy /usr/localzastąpić istniejące pliki z normalnej /usrstruktury, zobacz Czy niebezpieczne jest posiadanie / usr / local / bin przed / usr / bin w PATH? po kilka szczegółów na ten temat.

Trzecie wyróżnienie: najwyższy poziom /bini /sbinkatalogi.

Na Debianie istnieje tak zwany UsrMerge . Kiedyś różnicą, że /bini /sbinbyły dostępne w proces uruchamiania wcześniej (pomyśleć /usr, że na urządzeniu sieciowym lub RAID innej partycji, itp), ale dzisiejszych czasach niewiele systemów Linux uruchomić bez dobrze /usr, dlatego uważam rozróżnienie między grzałka górna poziom i /usrkatalogi będą w dużej mierze historycznie interesujące dla Linuksa.

Wreszcie: zalety i problemy związane z „rozpraszaniem” plików.

Naprawdę nie ma na to „jednej prawdziwej” odpowiedzi. Zalety rozproszonego systemu plików Linux to:

• Wszystkie pliki binarne znajdują się w kilku katalogach. Oznacza to, że możesz wywoływać każdy program z powłoki. Porównaj system Windows, w którym zawsze trzeba edytować %PATH%zmienną środowiskową, aby dodać dowolny program będący przedmiotem zainteresowania. Widziałem bardzo długie ścieżki środowisk w systemie Windows.

• Wszystkie biblioteki znajdują się w centralnym miejscu. Oznacza to, że nie muszą być instalowane dwukrotnie, gdy są używane przez wiele aplikacji.

• Ponieważ Linux jest zaprojektowany i większość plików systemowych jest śledzona przez menedżera pakietów , nie ma potrzeby prowadzenia przeglądu plików z punktu widzenia użytkownika.

• Ze względu na FHS standaryzacji dokumentacji tkwi również w centralnych miejscach systemy pozwalające podobają man, infoi wspierających plikach README do pracy zgodnie z oczekiwaniami.

• Łatwiej jest polegać na programie instalowanym w ustalonym miejscu. Każdy pisze #!/bin/sh -elub podobnie na początku skryptów i to po prostu działa . Zastanówmy się nad systemem, w którym powłoka trafiałaby do innego katalogu: Skąd wiadomo, jaką będzie miała nazwę? W razie zainteresowania sprawdź różne sposoby instalacji Perla lub LaTeXa w systemie Windows, aby zobaczyć, jak skomplikowane może być ...

Wady, które do tej pory znalazłem, to:

• Zwykle trudniej jest uruchomić aplikacje „przenośnie” w znaczeniu „aplikacji przenośnych dla systemu Windows”. W Linuksie nie jest tak łatwo skopiować program na inny komputer ... trzeba mieć pakiet (który wymaga uprawnień roota) lub poradzić sobie z LD_LIBRARY_PATHkierowaniem aplikacji do różnych ścieżek wyszukiwania wymaganych bibliotek.

• Instalowanie wielu wersji tego samego programu musi być obsługiwane jawnie, podczas gdy w systemach z „jednym katalogiem na program” często stanowi to mniejszy problem.

• Zarządzanie plikami bez menedżera pakietów jest podatne na błędy (jak już wspomniano).

Aby odpowiedzieć na drugie pytanie:
Zazwyczaj programy są dystrybuowane za pomocą tak zwanego menedżera pakietów . Menedżer pakietów zwykle pobiera pakiety binarne (oprogramowanie skompilowane dla konkretnej platformy) i rzuca je wokół katalogów (są tacy, którzy pobierają kod źródłowy, kompilują go na komputerze i instalują). Zatem menedżer pakietów wie, gdzie znajdują się pliki należące do określonego „programu” (pakietu), a kiedy chcesz usunąć pakiet, menedżer pakietów zajmuje się czyszczeniem wszystkiego.
Nawet przy samodzielnym kompilowaniu kodu źródłowego

make

i zainstaluj za pomocą

make install

zwykle możesz to zrobić

make uninstall

który usuwa pliki z systemu plików.