소스 코드(예: 타사 GitHub 저장소)의 소프트웨어를 내 컴퓨터에 설치하고 싶습니다. 일반적으로 /usr/local/bin 및 /usr/local/src는 배포판에 특화되지 않은 소프트웨어에 사용됩니다. 그렇죠?
/usr/local의 소유권을 갖는 것은 위험해 보입니다. 내 권한으로 실행되는 모든 것은 /usr/local/bin의 실행 파일이나 /usr/local/src의 소스 코드를 악의적으로 변경할 수 있습니다.
그러나 다른 옵션인 루트( )로 sudo빌드하고 설치하는 것은 나에게는 이해가 되지 않습니다.gitGitHub는 루트로 실행하지 말라고 경고합니다 .make다른 곳의 로컬 저장소에서 소스 코드를 복사하더라도 and make installas를 실행해야 합니다 sudo. 이는 내가 설치하는 소프트웨어가 내 컴퓨터의 나머지 부분을 가로챌 수 있음을 의미합니다.
모든 것을 /home에 넣을 수 있지만 그것은 경찰 아웃처럼 보입니다. 이것은 /usr/local이 아닌가요?~을 위한?
답변1
다음 용도로 사용하지 마세요 ./usr/localsudo설치하다소프트웨어. 하지만 본인 계정을 사용하세요.세워그것.
git clone … # or tar -x or …
cd …
./configure
make
sudo make install
왜 소유권을 가지지 않습니까 /usr/local? 네가 해냈어. 이렇게 하면 귀하의 계정에서 실행 중인 모든 프로그램이 거기에 쓸 수 있습니다. 맬웨어에 대해서는 어쨌든 패합니다. 로컬 계정을 감염시키는 것은 중요한 단계이며 루트로 업그레이드하는 것은 어렵지 않습니다(예: 다음 실행 시 피기백 sudo). 그러나 잘못 구성된 프로그램의 경우 시스템 전체 디렉터리에 쓰기 가능한 비트를 포함하지 않는 것이 가장 좋습니다.
홈 디렉토리 중에서 선택하는 경우 /usr/local: 계정에만 사용하려는 항목의 홈 디렉토리와 /usr/local시스템 전체에 설치된 항목의 홈 디렉토리입니다.
답변2
방법
이 솔루션에는 두 가지 접근 방식이 있습니다.
/usr/local/{src,bin}시스템 관리자가 설치한 맞춤형 소프트웨어의 경우, 즉root이 경우 항상 사용해야 하므로sudo이 질문은 논쟁의 여지가 있습니다.su -- 미리 컴파일된 바이너리 업데이트(예: 배포판의 패키지 관리 메커니즘에 있는 업데이트)를 설치하지만
/opt이 경우에도 시스템 관리자가 수행합니다.
추리
두 경우 모두 이러한 위치에 설치된 소프트웨어는 배포판에서 업스트림을 지원하지 않으므로 잠재적으로 위험한 작업을 무시하려면 루트 액세스가 필요합니다. 또한 /usr/local/src소스코드를 컴파일하는 곳도 아닙니다. 여기에 소스가 저장됩니다. 이 두 가지 항목을 염두에두면 다음과 같은 일이 보장됩니다.CentOS 7에서 Awesome Window Manager 사용하기일어나지 마세요.
혼동하지 마세요
설치된 소프트웨어만 업데이트하려면 배포판에 테스트 소프트웨어를 추가하는 기본 방법을 통해 업데이트해야 합니다. 몇 가지 주요 방법:
답변3
대부분의 빌드 시스템은 기본값을 따릅니다 --prefix=$path./usr/local
따라서 일반적으로 빌드 + 테스트 + 설치를 수행합니다. 여기서 빌드 + 테스트 단계는 쓰기 액세스 권한이 있는 어느 곳에서나 발생할 수 있으며 설치 단계는 일반적으로...
sudo make install (에 설치 --prefix)
빌드 환경을 설정하는 한 가지 방법은 work + attic 하위 디렉터리를 포함하는 빌드 디렉터리를 만드는 것입니다.
내 빌드 환경은...
/smartbuild/work - 패키지의 빌드 위치(tarball 또는 git/svn/etc에서)
/smartbuild/attic- tarball 캐시의 위치(따라서 재구축 시 tarball 다운로드를 건너뜁니다)