sys 관리자는 서버에 소프트웨어 응용 프로그램 (Maven)을 설치하고 모든 사람에게 /usr/local/maven/bin/폴더를 경로에 추가하도록 지시했습니다.
다음과 같이 /bin폴더 (또는 모든 사람이 경로에있는 다른 폴더) 에서 해당 폴더의 몇 가지 프로그램을 연결하는 것이 더 편리 할 수 있다고 생각합니다 .
ln -s /usr/local/maven/bin/* /bin
이 올바른지? 내 제안에 숨겨진 부작용이 있습니까?
답변:
일반적으로 /usr/local/*와 (과 /bin) 연결 하지는 않지만 이는 역사적 관행에 가깝습니다. 일반적으로 제안하는 것을 수행 할 수없는 몇 가지 "기술적 인"이유가 있습니다.
실행 파일에 링크를 만들면 /bin문제가 발생할 수 있습니다.
시스템이 RPM, dpkg, APT, YUM, pacman, pkg_add 등과 같은 일종의 패키지 관리자에 의해 패키지를 관리하고 있다면 아마도 가장 큰 경고는 아마도 패키지를 허용하고 싶을 것입니다. 관리자는 일을하고 같은 디렉토리 관리 /sbin, /bin, /lib,와 /usr. 한 가지 예외는 /usr/local패키지 관리자가 파일을 방해하지 않아도 걱정할 필요없이 일반적으로 상자에 딱 맞는 안전한 장소입니다.
종종 빌드 된 실행 파일 /usr/local은이 PATH를 실행 파일에 하드 코딩합니다. /usr/local이러한 응용 프로그램 설치의 일부로 포함 된 구성 파일이있을 수도 있습니다 . 따라서 실행 파일에만 연결하면 .cfg나중에 해당 앱에서 파일을 찾는 데 문제가 발생할 수 있습니다 . 이러한 경우의 예는 다음과 같습니다.
$ strings /usr/local/bin/wit | grep '/usr/local'
/usr/local/share/wit
/usr/local/share/wit/
.cfg파일 찾기에 적용되는 동일한 문제가 기본 앱을 실행해야하는 "도우미"실행 파일에서도 발생할 수 있습니다. 이것 또한 /usr/bin문제가있을 수 있으며 실제로 연결된 앱을 실행하려고했을 때만 나타납니다.
참고 : 일반적으로의 오프 앱 하나에 연결하려는 유혹을 피하는 것이 가장 좋습니다 /usr/bin.
대신 모든 사용자가이 관리 기능을 제공하게되면 관리자 $PATH는 /etc/profile.d디렉토리에 해당 파일을 추가 하여 모든 사람에게 쉽게 추가 할 수 있습니다 .
다음과 같은 파일 /etc/profile.d/maven.sh:
PATH=$PATH:/usr/local/maven/bin
일반적으로이 설정으로 모든 사용자 설정을 오염시키는 대신 관리자로이 작업을 수행합니다.
대부분의 배포판은 이제 alternatives(Fedora / CentOS) 또는 update-alternatives(Debian / Ubuntu) 라는 다른 도구를 제공 $PATH합니다 /bin. 이 도구는 외부에있을 수 있는 도구 로 반복하는 데 사용할 수도 있습니다 . 이와 같은 도구를 사용하는 것이 바람직합니다. 대부분의 관리자가 "표준 관행"으로 간주하는 것에 더 많은 영향을 미치므로 시스템을 한 관리자에서 다른 관리자로 쉽게 전달할 수 있습니다.
이 도구는 링크를 만들 때 비슷한 작업을 수행합니다 /bin. 그러나 이러한 링크의 생성 및 제거를 관리하므로 도구를 통해 수행 할 때와 제안한대로 직접 수행 할 때 시스템의 의도 된 설정을 이해하기가 더 쉽습니다.
여기서는 해당 시스템을 사용하여 상자에서 Oracle의 Java를 관리하고 있습니다.
$ 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
이것의 효과를 볼 수 있습니다 :
$ 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
/bin대부분의 시스템 관리자가 링크를 만드는 것은 그럴듯하지만 권장하지 않습니다.
/bin디렉토리를 소유하고 있지 않다고 확신하지 않습니다 . 다음은 예입니다. RPM에 파일이 이미 존재하는 경우 RPM을 사용하는 Red Hat 배포판 /bin에서는 --replacefiles스위치를 사용하여 연결하지 않으면 위에서 설명한대로 위에 설치되지 않습니다 . 이것이 실제로 기술적 인 이유는 아닙니다. 다른 디렉토리와 동일합니다. 나는 당신이 OS "소유"에 대해 말하는 것을 이해 /bin하지만 그것은 당신이 말하는 것만 큼 똑 바르지는 않습니다.
질문에 대한 답변 :
이 올바른지?
아니 , 그것은 나쁜 습관입니다.
내 제안에 숨겨진 부작용이 있습니까?
예 , 몇 가지 부작용이 있습니다. 귀하의 제안은 응용 프로그램에 따라 작동하거나 작동하지 않을 수 있으며 장기적으로 회귀되거나 깨질 수 있습니다.
이러한 기호 링크를 작성 하지 않는 합리적인 이유 가 있습니다.
/bin이 디렉토리는 운영 체제 / 배포 개발자에 속하므로 관리자는 "소유"하지 않습니다 (주 1 참조). 반면에 /usr/local로컬 관리자가 구축 한 /opt/<packagename>소프트웨어는 번들로 제공되지 않는 소프트웨어 의 전형적인 위치입니다 . 에서 파일 또는 링크를 만드는 경우 /bin패키지 설치, 파일 maven이 OS에서 제공 한 가상 패키지 로 덮어 쓰여질 수 있습니다. 로컬에서 작성된 패키지가 최신 버전에서 작성된 경우 회귀로 이어질 수 있습니다. 소스 코드는 OS 버전입니다. 예를 들어, SVR4 pkgadd, debian dpkg, red-hat rpm및 slackware tarball은 모두 맹목적으로 심볼릭 링크를 덮어 씁니다.
일부 응용 프로그램은 구성 파일, 플러그인 및 유사한 리소스를 검색하기 위해 호출되는 위치를 찾습니다. 심볼릭 링크로 응용 프로그램을 호출하면 해당 코드가 해당 코드를 따르지 않고 해당 리소스 파일 /usr/bin이없는 위치 를 찾습니다 .
다른 바이너리가있을 수 있으며이 모든 잠재적 명령을 연결하여 명령과 함께 이미 고려했을 때 제거되었습니다./usr/local/maven/bin디렉토리를 PATH에 추가하지 않으면 사용할 수 없게됩니다.
maven2 페이지가 PATH에이 디렉토리를 추가하는 지시 (정확하게 : 경로에 M2 환경 변수를 추가, 예를 들어 수출 PATH = $ M2 : $ PATH .), 당신은 그래서 단계를 깨고, 다른 접근 방법을 사용하여 지원되지 않는가는 방법. 물론, 대부분의 시스템 maven사용자 가 잠재적 인 사용자라면 PATH각각 대신 에 전역으로 설정하는 것이 더 합리적 .profile입니다.
참고 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.
/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.
옵션을 사용 dpkg하지 않더라도 데비안을 보여주는 간단한 테스트 는 기존 링크를 유지하지 않습니다 --force-overwrite.
# 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
/bin또는에 직접 설치했다 /usr/bin. 숨겨 지거나 파괴 된 시스템 바이너리 (가장 유명한 것 test) 의 문제점을 발견하면, 다른 곳에 비 시스템 바이너리를 설치하는 모범 사례가 점차 채택되었습니다.
심볼릭 링크를하려면 심볼릭 링크를 사용하는 것이 좋습니다 /usr/local/bin. 서버에서 로컬 소프트웨어를 설치 /opt/NAME하고 바이너리를에 심볼릭 링크했습니다 /usr/local/bin.
제안 된 두 가지 방법에 대한 대안은 /usr/local/bin실행시 스크립트에 지정한 바이너리를 실행 하는 쉘 스크립트를 작성하는 것 입니다. 예를 들어, 예를 들어 Maven을 사용하여, 나는에 쉘 스크립트를 만들 것 /usr/local/bin이라고 maven이있는 받는다는 바이너리를 실행하고 여기에 인수를 전달하는 작은 스크립트 내부를 가지 :
#!/bin/sh
exec /usr/local/maven/bin/maven "$@"
"링크"하려는 모든 바이너리에 대해이 작업을 수행해야하는 단점이 있지만 $PATH환경 변수 를 정리할 필요없이 명령 행에서 해당 바이너리를 호출 할 수 있습니다 .
/opt.