Nasz administrator sys zainstalował aplikację (Maven) na serwerze i kazał wszystkim dodać /usr/local/maven/bin/folder do swojej ścieżki.
Myślę, że wygodniej byłoby po prostu połączyć kilka programów w tym folderze z /binfolderu (lub innego folderu, który każdy ma na swojej ścieżce) w następujący sposób:
ln -s /usr/local/maven/bin/* /bin
Czy to jest poprawne? Czy są jakieś ukryte skutki uboczne mojej sugestii?
Odpowiedzi:
Ogólnie nie łączysz /usr/local/* z /bin, ale jest to raczej praktyka historyczna. Ogólnie istnieje kilka „technicznych” powodów, dla których nie możesz zrobić tego, co sugerujesz.
Tworzenie linków do plików wykonywalnych w /bin może powodować problemy:
Prawdopodobnie największym zastrzeżeniem byłoby, jeśli system ma pakiety zarządzane przez jakiegoś menedżera pakietów, takiego jak RPM, dpkg, APT, YUM, pacman, pkg_add itp. W takich przypadkach zazwyczaj będziesz chciał pozwolić pakietowi menedżer wykonywać swoje zadania i zarządzać katalogi takie jak /sbin, /bin, /lib, i/usr . Jedynym wyjątkiem może być /usr/localbezpieczne miejsce, które uważasz za stosowne, bez obawy, że menedżer pakietów zakłóci twoje pliki.
Często skonstruowane pliki wykonywalne /usr/localbędą miały na stałe zapisaną PATH w swoich plikach wykonywalnych. Mogą również istnieć pliki konfiguracyjne, które są /usr/localczęścią instalacji tych aplikacji. Zatem połączenie tylko z plikiem wykonywalnym może powodować problemy z wyszukiwaniem .cfgplików przez aplikacje później. Oto przykład takiego przypadku:
$ strings /usr/local/bin/wit | grep '/usr/local'
/usr/local/share/wit
/usr/local/share/wit/
Ten sam problem, który dotyczy wyszukiwania .cfgplików, może również wystąpić w przypadku plików wykonywalnych „pomocniczych”, które musi uruchomić główna aplikacja. Te również będą musiały być połączone /usr/bin, wiedząc, że może to być problematyczne i pojawiają się tylko wtedy, gdy faktycznie próbujesz uruchomić połączoną aplikację.
UWAGA: ogólnie najlepiej jest unikać pokusy łączenia się z jednorazowymi aplikacjami /usr/bin.
Zamiast tego wszyscy użytkownicy zapewniają to zarządzanie, administrator może bardzo łatwo dodać to do wszystkich w $PATHpolu, dodając odpowiedni plik w /etc/profile.dkatalogu.
Plik taki jak ten /etc/profile.d/maven.sh:
PATH=$PATH:/usr/local/maven/bin
Generalnie robisz to jako administrator, zamiast zanieczyszczać tym konfiguracje wszystkich użytkowników.
Większość dystrybucji zawiera teraz inne narzędzie o nazwie alternatives(Fedora / CentOS) lub update-alternatives(Debian / Ubuntu), którego można również użyć do zapętlenia $PATHnarzędzi, które mogą znajdować się poza /bin. Preferowane jest korzystanie z takich narzędzi, ponieważ są one bardziej zgodne z tym, co większość administratorów uważa za „standardową praktykę”, a tym samym ułatwia przekazywanie systemów od jednego administratora do drugiego.
To narzędzie działa podobnie do tworzenia linków /bin ; ale zarządza tworzeniem i niszczeniem tych łączy, więc łatwiej jest zrozumieć zamierzoną konfigurację systemu, gdy jest wykonywana za pomocą narzędzia, a nie bezpośrednio, jak sugerujesz.
Tutaj używam tego systemu do zarządzania Javą Oracle na pudełku:
$ ls -l /etc/alternatives/ | grep " java"
lrwxrwxrwx. 1 root root 73 Feb 5 13:15 java -> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64/jre/bin/java
lrwxrwxrwx. 1 root root 77 Feb 5 13:15 java.1.gz -> /usr/share/man/man1/java-java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64.1.gz
lrwxrwxrwx. 1 root root 70 Feb 5 13:19 javac -> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64/bin/javac
lrwxrwxrwx. 1 root root 78 Feb 5 13:19 javac.1.gz -> /usr/share/man/man1/javac-java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64.1.gz
lrwxrwxrwx. 1 root root 72 Feb 5 13:19 javadoc -> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64/bin/javadoc
lrwxrwxrwx. 1 root root 80 Feb 5 13:19 javadoc.1.gz -> /usr/share/man/man1/javadoc-java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64.1.gz
Możesz zobaczyć efekty tego:
$ type java
java is /usr/bin/java
$ readlink -f /usr/bin/java
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64/jre/bin/java
Udostępnianie linków /bin, choć prawdopodobne, byłoby wysoce zniechęcone przez większość sysadminów:
/binkatalogu. Oto przykład. W dystrybucjach Red Hat, które wykorzystują RPM, jeśli plik już istnieje w /binRPM, nie zostanie zainstalowany tak, jak opisano powyżej, chyba że zostanie to zrobione przy użyciu --replacefilesprzełącznika. To nie jest tak naprawdę powód techniczny. To samo z innymi katalogami. Rozumiem, co mówisz o „posiadaniu” systemu operacyjnego, /binale nie jest to tak proste, jak twierdzisz.
Odpowiedzi na zadane pytania:
Czy to jest poprawne?
Nie , to zła praktyka.
Czy moja sugestia ma jakieś ukryte skutki uboczne?
Tak, istnieje kilka efektów ubocznych. Twoja sugestia może działać lub nie w zależności od aplikacji i może się cofnąć lub zostać zerwana w dłuższej perspektywie.
Istnieją uzasadnione powody, aby nie tworzyć takiego dowiązania symbolicznego:
Administratorzy nie są „właścicielami” /bin(patrz uwaga 1), ponieważ katalog ten należy do twórców systemów operacyjnych / dystrybucji. Z drugiej strony /usr/localjest to tradycyjna lokalizacja dla oprogramowania zbudowana przez lokalnego administratora, /opt/<packagename>która jest dla oprogramowania wydzielonego. Jeśli utworzysz plik lub łącze /bin, istnieje ryzyko zastąpienia go instalacją pakietu, w twoim przypadku hipotetycznym mavenpakietem dostarczonym przez system operacyjny, co może prowadzić do regresji, jeśli lokalnie zbudowany jest nowszy kod źródłowy w wersji systemu operacyjnego. Na przykład, pliki tar SVR4 pkgadd, debian dpkg, red-hat rpmi slackware w oślepiający sposób zastąpią twój symboliczny link.
Niektóre aplikacje szukają miejsca, w którym są wywoływane, w celu pobrania plików konfiguracyjnych, wtyczek i podobnych zasobów. Jeśli wywołasz aplikację za pomocą dowiązania symbolicznego, jej kod może nie podążać za nią, a następnie poszukać tych plików zasobów, /usr/binktórych nie ma.
Mogą istnieć inne pliki binarne, Usunięto, ponieważ uwzględniono to już w poleceniu, łącząc wszystkie potencjalne polecenia./usr/local/maven/bina brak dodania tego katalogu do ŚCIEŻKI spowoduje, że będą one niedostępne.
Strona maven2 mówi, aby dodać ten katalog do ŚCIEŻKI (dokładnie: dodaj zmienną środowiskową M2 do swojej ścieżki, np. Eksport ŚCIEŻKA = $ M2: $ ŚCIEŻKA .), Stosując inne podejście, przełamujesz ten krok, więc przejdziesz nieobsługiwany droga. Oczywiście, jeśli większość użytkowników systemu jest potencjalnymi mavenużytkownikami, sensowniejsze byłoby ustawienie PATHglobalne zamiast dla każdego z nich .profile.
Notatka 1:
The /bin directory usually doesn't receive modification
after installation. If it does, it's usually in the form
of package upgrades that we provide.
Debian / Fileystem Hierarchy Standard
/bin/
Essential command executable (binaries) for all users (e.g., cat, ls, cp)
(especially files required to boot or rescue the system)
...
/opt/
Add-on application software packages
Pre-compiled, non ".deb" binary distribution (tar'ed..) goes here.
/opt/bin/
Same as for top-level hierarchy
/usr/bin
Platform-dependent, user-invoked executables. These are
commands users expect to be run as part of their normal
$PATH. For executables that are different on a 64-bit
system than on a 32-bit system, a wrapper that selects
the appropriate executable is placed here. See
isaexec(3C). An approved installation location for bun-
dled Solaris software. The analogous location for add-on
system software or for applications is
/opt/packagename/bin.
Prosty test pokazujący, że Debian dpkgnie zachowuje istniejącego linku, nawet jeśli --force-overwriteopcja nie jest używana:
# ls -l /usr/bin/banner
lrwxrwxrwx 1 root root 11 Feb 25 21:37 /usr/bin/banner -> /tmp/banner
# dpkg -i sysvbanner_1.0.15_amd64.deb
Selecting previously unselected package sysvbanner.
(Reading database ... 236250 files and directories currently installed.)
Unpacking sysvbanner (from sysvbanner_1.0.15_amd64.deb) ...
Setting up sysvbanner (1.0.15) ...
Processing triggers for man-db ...
# ls -l /usr/bin/banner
-rwxr-xr-x 1 root root 11352 May 7 2009 /usr/bin/banner
/binlub /usr/bin. Po odkryciu problemów związanych z ukrytymi lub rozproszonymi plikami binarnymi systemu (najbardziej znana była test), stopniowo wprowadzano najlepsze praktyki instalowania plików binarnych niesystemowych w innym miejscu.
Jeśli chcesz utworzyć dowiązanie symboliczne, lepiej byłoby dowiązanie symboliczne /usr/local/bin. Na moim serwerze instalowałem lokalne oprogramowanie /opt/NAMEi łączyłem pliki binarne z nimi /usr/local/bin.
Alternatywą dla dwóch sugerowanych metod jest utworzenie skryptu powłoki, w /usr/local/binktórym po uruchomieniu wykonuje dowolny plik binarny określony w skrypcie. Na przykład, używając maven jako przykładu, stworzyłbym skrypt powłoki w /usr/local/binwywołanym, mavenktóry ma mały skrypt wewnątrz, aby wykonać plik binarny maven, w którym się znajduje, i przekazać do niego wszelkie argumenty:
#!/bin/sh
exec /usr/local/maven/bin/maven "$@"
Ma to tę wadę, że musi to robić dla każdego pliku binarnego, który chcesz „połączyć”, ale pozwala na wywoływanie tych plików binarnych z wiersza poleceń bez konieczności usuwania $PATHzmiennej środowiskowej.
/opt.