연구 결과, 모든 패키지 관리자는 권한있는 사용자로 사용해야한다고 주장하고에 설치해야합니다 /.
일반적으로 내가하고 싶은 일은 버리기 계정을 만들고 소프트웨어를 컴파일 $HOME한 다음 해당 계정에 설치하는 것 입니다. 다양한 설정을 시도한 다음 완료되면 계정을 삭제하십시오.
그러나 소프트웨어 컴파일이 지루해집니다.
내 경험은 실제로로만 제한되어 yum있지만 왜 repo 파일을 놓을 수없고 ~/etc/yum.repos.dyum이 모든 것을 홈 계정에 설치할 수 없는지 이해할 수 없습니다 .
소프트웨어를 설치하기 위해 패키지 관리자를 권한있는 사용자로 사용해야하는 이유가 있습니까?
답변:
이진 패키지는의 특정 위치에 설치 될 것이라는 가정하에 컴파일됩니다 /. 이것은 항상 쉽게 변경되는 것은 아니며 특정 바이너리가 재배치 가능한지 아닌지를 결정하기 위해 추가 QA 노력이 필요합니다 (처음에는 충분히 어렵습니다!).
어느 정도까지, 루트 디렉토리가 아닌 사용자로서 fakechroot 와 같은 것을 사용 하여 서브 디렉토리에 전체 시스템을 작성할 수 있지만, 이는 지루하고 취약합니다.
소스 패키지로 더 나은 행운을 얻게 될 것입니다. 젠투 접두사 와 루트가없는 GoboLinux 는 모두 비 /위치에 설치할 수 있고 비 root사용자 가 사용할 수있는 패키지 관리자입니다 .
/ . 예를 들어 env프로그램이 이런 종류의 문제를 해결하기위한 것이 아닙니까? 그렇지 않은 경우 특정 위치에서 다른 바이너리를 찾도록 바이너리를 구성하는 구성표를 쉽게 만들 수 있습니다.
/etc또는 (내 지식에 따르면) /usr/lib/<packagename>/또는 에 대한 환경 변수가 없습니다 /usr/libexec/<packagename>/. /usr/shareXDG 변수에 의해 변경 될 수 있습니다. XDG 변수는 금세기에 출시되었으며 반드시 구형 프로그램에는 적용되지 않습니다.
패키지 관리자 프로젝트 인 Nix 는 흥미로운 기본 아이디어 ( " 기능적 "pkg 관리자)를 가지고 있으며 사용자 별 작업도 지원합니다.
다중 사용자 지원
버전 0.11부터 Nix는 다중 사용자를 지원합니다. 이는 권한이없는 사용자가 소프트웨어를 안전하게 설치할 수 있음을 의미합니다. 각 사용자는 사용자의 PATH에 나타나는 다른 프로파일 인 Nix 저장소의 패키지 세트를 가질 수 있습니다. 사용자가 다른 사용자가 이전에 이미 설치 한 패키지를 설치하면 패키지가 다시 빌드되거나 다운로드되지 않습니다. 동시에 한 사용자가 다른 사용자가 사용할 수있는 패키지에 트로이 목마를 삽입 할 수 없습니다.
추가하고 싶은 참고 사항 : Nix 선택한 유닉스 계열 시스템 (예 : Linux 배포판)에서 사용할 수 있어야합니다.
여러 플랫폼을 위해 구축 된 Nix 패키지 관리자 인 Nixpkgs 와 함께 설치할 수있는 대규모 패키지 모음 도 있습니다 .
- 32 비트 및 64 비트 x86의 GNU / Linux (i686-linux 및 x86_64-linux)
- Mac OS X (i686-darwin 및 x86_64-darwin)
- FreeBSD (i686-freebsd 및 x86_64-freebsd)
- OpenBSD (i686-openbsd)
- Windows / Cygwin (i686-cygwin),
그리고 관련 배포판 인 NixOS :
NixOS는 Nix 기반 Linux 배포판입니다. 패키지 관리뿐만 아니라 시스템 구성 관리 (예 : / etc에 구성 파일 작성)에도 Nix를 사용합니다. 이는 무엇보다도 시스템의 전체 구성을 이전 상태로 쉽게 롤백 할 수 있음을 의미합니다. 또한 사용자는 루트 권한없이 소프트웨어를 설치할 수 있습니다. 더 읽기…
및 관련 "연속은"외 시스템 구축 히드라 .
nix하고 guix. 지금은 실제로 nix작업에 사용 하고 있으므로 guix필요한 도구의 다른 구현으로 고려할 수 있는지 알고 싶습니다 . 차이점에 대한 요약을 어딘가에서 읽을 수 있습니까? 아마도, 당신은 여기에 하나의 대안 솔루션을 발표하면서 그러한 요약으로 답을 쓸 수 있습니까?
우선 그것은 의존성 때문입니다. PolicyKit과 같은 일부 패키지는 사용자가 설치할 수 없습니다. 따라서 자유 시간을 기증하고 일반적으로 프로그램 설치는 입력 sudo(단일 사용자 스테이션)이나 잔소리 관리자 만큼 쉬운 패키저에 대한 추가 부담이 필요합니다 .
$ HOME에 설치하기위한 옵션이 있습니다
./configure --prefix=$HOME/sandbox --enable-cool-feature && make all install(또는 jhbuild와 같은 변형).모델이 다른 또 다른 모델은 0install 입니다. 실제로 패키지를 설치하는 것이 아니라 필요한 경우 다운로드하고 컴파일하고 사용하려는 소프트웨어를 캐시하는 전역 네임 스페이스에서 패키지를 실행한다는 아이디어를 기반으로합니다.
소스에서 컴파일하고 종속성을 직접 해결하고 패키지 관리자가 주로 배포 / 배포 / 업그레이드 작업을 처리하도록하려는 경우 GNU Stow 또는 다소 개선 된 XStow를 살펴볼 수 있습니다. 그것들을 사용하여 설치를 별도의 디렉토리 (일반적으로) 아래로 스테이징 $PREFIX/stow한 다음 실제 접두사에서 소프트웨어로 심볼릭 링크를 만듭니다. 그러면 소프트웨어를 쉽게 완전히 제거 할 수 있습니다. 대학에서 맞춤형 설치 소프트웨어를 관리하는 데 성공적으로 사용합니다.
내 경험은 실제로 yum으로 제한되어 있지만 왜 repo 파일을 ~ / etc / yum.repos.d에 놓을 수없고 yum이 모든 것을 홈 계정에 설치하도록 할 수 없는지 이해할 수 없습니다.
주류 Linux 패키지 관리자는 시스템을 단일 엔티티로하는 sysadmin으로 세상을 본다. 이를 통해 "시스템 X에 뛰어난 정오표 적용"및 "시스템 X와 시스템 Y의 차이점"과 같은 질문에 대한 답변을 얻을 수 있습니다. 또한 yum은 "히스토리"를 사용할 수 있고 rpmdb 버전을 가지며 "yum --security update"등과 같은 작업을 수행 할 수 있습니다.
제로 설치와 같은 일부 패키지 관리자가 있습니다.이 관리자는 세상을 사용자처럼 볼 수 있습니다. 어떤 응용 프로그램을 어떻게 내가 에 액세스 할 수 있습니다.
후자가 더 나은 모델이라고 생각할 수도 있지만 IMNSHO는 설치가 전혀 없지만 얌에 대해 들어 본 이유가 있습니다.
" Juneest ( Jailed User NEST)-루트 액세스없이 Linux 배포판에서 실행되는 아치 Linux 기반 배포판입니다." @ https://github.com/fsquillace/junest 이점은 새로운 종류의 패키지 형식을 도입하지 않으므로 매우 쉬운 설치 (최소 : 약 320M) 후 완전한 Arch Linux 저장소 (13000 이상) 패키지 ATM)이 여러분의 손끝에 있습니다.
슬랙웨어가 사용하는 도구, 특히 installpkg. 매뉴얼 페이지에서 :
--root /otherroot
Install using a location other than / (the default) as the root of the
filesystem to install on. In the example given, use /otherroot instead.
Setting the ROOT environment variable does the same thing.
그러나 나는 이것을 할 수있는 더 나은 프론트 엔드를 slapt-get알지 못합니다 (예를 들어 , 내가 아는 한, 이것을 할 수 없습니다). 이론적으로, 당신은 별명 할 수 있어야 installpkg에 installpkg --root ~/Apps- 그러나, 나는 대부분의 프론트 엔드는 점을 패배하는, 실행하는 루트가 필요하다고 생각합니다.
http://linuxbrew.sh/를 제안합니다
그것은 기본적으로 macOS를위한 양조장이며 사용을 위해 바이너리를 미리 컴파일했습니다 ...
이전 gcc 버전을 처리 할 때 특히 좋습니다.
실제로 직접 설치하려는 경우 유용한 안내서는 http://www.linuxfromscratch.org/ 입니다 .
Yum은 루트가 소유 한 데이터베이스에 기록해야합니다. 이로 인해 일반 사용자로 사용할 수 없습니다.
선택한 디렉토리 내에서 rpm 파일 (rpm2cpio package.rpm | cpio -idmv)을 압축 해제 할 수 있습니다.
그러나 프로그램을 실행할 때는 종속 라이브러리를로드하기 위해 LD_LIBRARY_PATH를 수정해야합니다. 또한 이것은 종속성을 처리하지 않습니다.
예:
# mkdir new_root
# cd new_root
# wget ftp://mirror.switch.ch/pool/4/mirror/centos/6.7/os/x86_64/Packages/vim-enhanced-7.4.629-5.el6.x86_64.rpm
# rpm2cpio vim-enhanced-7.4.629-5.el6.x86_64.rpm | cpio -idmv
# ./usr/bin/vim -version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Jul 24 2015 02:23:23)
위의 라이브러리에는 종속 라이브러리가 없으므로 그렇지 않으면 다음과 같은 것을 사용해야합니다.
export LD_LIBRARY_PATH=./usr/lib ./usr/bin/program
/bin있다고 가정하거나 --prefix로 지정된 곳에 설치되었다고 가정 할 수 있습니다. 후자는 해당 프로젝트로 해결할 수 있지만 전자는 소스 코드에 대한 패치가 필요합니다.