Jaka jest konwencjonalna lokalizacja instalacji aplikacji w systemie Linux?


72

Obecnie instaluję NetBeans, a domyślnym katalogiem instalacyjnym jest /home/thomasowens/netbeans-6.8. Nie jestem fanem tej lokalizacji, tak patrzę /etc, /bin, /usr/bin, i /sbin. Czy Linux ma miejsce, które zgodnie z umową jest takie samo jak C:\Program Fileskatalog Windows ?

Odpowiedzi:


98

Zgodnie ze standardem hierarchii systemu plików istnieje kilka miejsc, które są dopuszczalne, w zależności od aplikacji. Cytuję tutaj obszernie.

  • bin jest oczywiście skrótem od „binarny”
  • sbin jest skrótem od „binarny serwer”, inaczej zdefiniowany jako:

    Narzędzia używane do administrowania systemem (i inne polecenia tylko do rootowania)

  • /usr służy do udostępniania danych tylko do odczytu i powinien być udostępniany między różnymi hostami zgodnymi z FHS (jeśli masz wiele komputerów w sieci i wszystkie mają tę samą architekturę, powinieneś mieć możliwość współużytkowania jednego folderu / usr z każdą maszyną w sieci)

  • /usr/local służy do użytku administratora systemu podczas instalacji oprogramowania lokalnie (tj. dla aplikacji zainstalowanych tylko na tym komputerze, a nie na każdym komputerze w sieci).

Łącząc je razem:

  • /usr/bin jest podstawowym katalogiem komend wykonywalnych w systemie.
  • /usr/sbin jest dla wszelkich nieistotnych plików binarnych używanych wyłącznie przez administratora systemu.
  • /sbinZamiast tego należy umieścić programy administracyjne systemu wymagane do naprawy systemu, przywracania systemu, montowania / usr lub innych podstawowych funkcji (tj. Rzeczy, do których należy uzyskać dostęp w celu zamontowania /usr/sbingo /sbin)
  • Podobnie niezbędne polecenia użytkownika, które mogą być potrzebne przed /usrzamontowaniem/bin
  • Wszystko zainstalowane tylko na komputerze lokalnym powinno być w /usr/local/binlub/usr/local/sbin

Jest jeszcze jedno zastosowanie dla / usr / local. Większość rzeczy, które instalujesz za pomocą menedżera pakietów twojej dystrybucji, będzie umieszczona w / usr; wiele osób umieszcza rzeczy, które skompilowały ręcznie w / usr / local. To chroni je przed systemem zarządzania pakietami i pozwala dostrzec to, co zainstalowałeś z dystrybucji (i nie musisz tworzyć kopii zapasowej, ponieważ możesz go ponownie pobrać) i to, co skompilowałeś ręcznie; pozwala także na uruchamianie różnych wersji jednocześnie (np. / usr / bin / firefox vs / usr / local / bin / firefox).


Właśnie wtedy, gdy myślałeś, że wszystko zostało załatwione, jest jeszcze jedno miejsce, które prawdopodobnie jest najbliższym odpowiednikiem c:\Program Files- /opt:

/opt jest zarezerwowany do instalacji dodatkowych pakietów aplikacji. ”

/optJest to prawdopodobnie najbliższy odpowiednik c:\program files, ponieważ jest to jedyne miejsce, gdzie można się spodziewać, aby znaleźć aplikację ze wszystkich swoich plików w jednym folderze, a nie rozproszone /usr/bin, /vari /etc. Zwykle jest używany tylko przez bardzo duże pakiety, ale w tym przypadku, biorąc pod uwagę, że Netbeans chce mieć własny folder, prawdopodobnie najbardziej sensowne jest umieszczenie go w / opt / netbeans


3
ciekawy. gdybym zaprojektował Linuksa, umieściłbym sieciowe aplikacje współdzielone w / usr / shared, a następnie umieściłem prywatne aplikacje hosta w / usr. w ten sposób mógłbym udostępnić / usr / shared bez również, poprzez dziedziczenie, sharing / usr.
djangofan

1
Naprawdę miła odpowiedź. Podoba mi się również komentarz na temat trzymania systemu z dala od systemu zarządzania pakietami.
DaveParillo

1
Zdecydowanie / wybierz „pełne pakiety innych firm”. Większość instalacji dzieli różne pliki binarne, biblioteki, pliki itp. Na różne katalogi, ale gdy masz katalog „wszystko w jednym”, / opt ułatwia obsługę.
Avery Payne,

Kilka szybkich pytań: 1) Jeśli / usr ma być współużytkowany przez wszystkie komputery w sieci, czy nie oznacza to, że wszystkie katalogi potomne również mogłyby być współużytkowane, dzięki czemu / usr / local będzie widoczny dla innych komputerów w sieci? 2) Co to jest FHS 3) Kiedy mówisz o poleceniach niezbędnych do zamontowania / usr, czy mówisz o tym, jak system operacyjny uruchamia się, powiedzmy, po wyłączeniu? Przepraszam za bombardowanie pytań 7 lat później, ale jestem nowy w Linuksie i miałem to samo pytanie po zobaczeniu, jak przewodniki instalacyjne mówią, gdzie umieścić rzeczy, ale nie DLACZEGO je tam umieszczać. +1 btw
Ungeheuer

5

Naprawdę sprowadza się to do osobistych preferencji. Wyjaśnię moje za to, co jest warte.

/ usr, / usr / bin to zazwyczaj miejsca na oprogramowanie zainstalowane przez system do zainstalowania. Kiedy instaluję rzeczy sam, instaluję je w jednym z kilku miejsc:

  1. Jeśli będę używać tylko skryptu lub małego programu, instaluję go w ~ / bin - tam kończy się większość moich rzeczy.
  2. Jeśli jest to coś, co opisałeś (NetBeans) z własnym pełnym drzewem plików, instaluję go w / opt
  3. Jeśli jest to pojedynczy plik wykonywalny, instaluję go w / usr / local / bin

Dlaczego rozróżniam # 2 i # 3? Nie mam pojęcia, to po prostu nawyk, który rozwinąłem z czasem. Okazuje się, że / opt zwykle staje się głębokim drzewem plików, ale ma tylko 2 lub 3 rzeczywiste „rzeczy” zainstalowane. W tej chwili mam zainstalowane lampp i lotosowe notatki w opt, 2 katalogi, z których każdy ma dość duże drzewa pod nimi. W katalogu / usr / local / bin mam 20 lub 30 pozycji, ale nie mam podkatalogu.

Nie instaluję rzeczy w / usr / bin ani / usr / sbin, ponieważ lubię trzymać osobno rzeczy, które dodaję ręcznie (nie jest to po prostu instalacja ze standardowego repozytorium).


1

Chociaż Standard hierarchii systemu plików zawiera pewne wskazówki. Przekonałem się, że większość dystrybucji lubi instalować pakiety /usr/share.

Z tego powodu podjąłem praktykę instalowania dowolnej aplikacji niezainstalowanej za pomocą menedżera pakietów (rpm / apt-get / emerge) w /usr/local. To pozwala mi trzymać aplikacje i biblioteki, które nie są zarządzane przez zarządzanie pakietami, oddzielnie od tych, które są.

Jest to technika, która pomogła mi zarządzać systemem w Fedorze Core i Gentoo.


0

Myślałem, że domyślna lokalizacja to miejsce /bin, w którym prawie wszystko instaluje się domyślnie, jeśli używasz apt-get lub podobnego ...

... Jednak jeśli chodzi o bardziej nowoczesne programy (lub te bez instalatora), które mają wiele dodatkowych plików, lubię umieszczać je w ich własnym katalogu /bin.


3
Jaka jest różnica między / bin, / usr / bin i / sbin? / bin ma sens, ponieważ dotyczy plików BINary.
Thomas Owens,

0

Zwykle instalują się w wielu folderach, głównie / usr, / local, / bin itp. Możesz dowiedzieć się, gdzie program instaluje się z GDebi Installer (w zakładce plików). Jeśli zamierzasz przenieść Netbeans, sugeruję przeniesienie go do / opt, ponieważ tam wydaje się, że Google instaluje swoje rzeczy.


0

Zgadzam się z odpowiedzią Jamesa Polleya, ale tak naprawdę domyślny katalog ma sens, chyba że musisz udostępnić aplikację wielu kontom. Musiałem na przykład zainstalować Eclipse 3.0 (przestarzałe), aby wykonać Flex w Linuksie, i umieściłem go w $ HOME / eclipse3.


0

Lubię używać / apps do większości aplikacji dodatkowych instalowanych na wielu serwerach. Trzymam kopię folderu w / installs / apps na moim serwerze NFS. Kiedy tworzę nowy serwer Linux, montuję folder instalacyjny i kopiuję / aplikacje i mam wiele różnych wspólnych aplikacji na nowym serwerze. Usuwam wpisy, których nie potrzebuję dla tego nowego serwera i gotowe. Cóż, może muszę uruchomić skrypt lub trzy, aby ustawić zmienne środowiskowe lub instrukcje ścieżki, ale to w zasadzie tyle, ile potrzeba, aby skonfigurować wiele nowych serwerów.

Pochodzę z systemu Windows i tła .net. Jedną z obietnic .net było to, że większość aplikacji można zainstalować przy użyciu Windows xcopy. Tego samego szukam w systemie Linux. Tam, gdzie jest to możliwe, wybieram tarball zamiast RPM lub yum itp., Więc mogę wdrożyć do / apps za pomocą cp -r i dodać aplikację do mojego serwera NFS do przyszłych wdrożeń.


2
Pytanie dotyczy konwencji. Sam opisałeś, co robisz. Czy możesz przynajmniej powiązać to z konwencją?
fixer1234
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.