Menedżerowie pakietów innych niż root

Z moich badań wynika, że ​​wszyscy menedżerowie pakietów nalegają na to, aby być wykorzystywanym jako użytkownik uprzywilejowany i muszą być instalowani /.

Zwykle to, co lubię robić, to utworzyć konto typu out-out, skompilować oprogramowanie i zainstalować $HOMEdla tego konta. Mogę wypróbować różne konfiguracje, a kiedy skończę, po prostu zniszcz konto.

Jednak kompilowanie oprogramowania staje się nużące.

Moje doświadczenie jest tak naprawdę ograniczone yum, ale nie rozumiem, dlaczego nie byłbym w stanie upuścić pliku repo ~/etc/yum.repos.di kazać zainstalować wszystko na koncie domowym.

Czy jest jakiś powód, dla którego menedżerowie pakietów muszą być używani jako uprzywilejowani użytkownicy do instalowania oprogramowania?

Pakiety binarne są kompilowane przy założeniu, że zostaną zainstalowane w określonych lokalizacjach w /. Nie zawsze można to łatwo zmienić i wymagałoby to dodatkowego wysiłku zapewnienia jakości (co jest wystarczająco trudne!), Aby ustalić, czy określone pliki binarne można przenosić czy nie.

Do pewnego stopnia możesz użyć rzeczy takich jak fakechroot do stworzenia całego systemu w podkatalogu jako użytkownik inny niż root, ale jest to uciążliwe i delikatne.

Będziesz miał więcej szczęścia z pakietami źródłowymi. Zarówno Gentoo Prefix, jak i Rootless GoboLinux są menedżerami pakietów, które mogą instalować się w innych /lokalizacjach i mogą być używane przez nie- rootużytkowników.

Istnieje projekt menedżera pakietów - Nix - z ciekawym fundamentalnym pomysłem („ funkcjonalny ” menedżer pkg), który obsługuje również operacje dla poszczególnych użytkowników:

Wsparcie dla wielu użytkowników

Począwszy od wersji 0.11, Nix obsługuje wielu użytkowników. Oznacza to, że użytkownicy nieuprzywilejowani mogą bezpiecznie instalować oprogramowanie. Każdy użytkownik może mieć inny profil, zestaw pakietów w sklepie Nix, które pojawiają się w ŚCIEŻCE użytkownika. Jeśli użytkownik zainstaluje pakiet, który inny użytkownik już wcześniej zainstalował, pakiet nie zostanie zbudowany ani pobrany ponownie. Jednocześnie jeden użytkownik nie może wstrzyknąć konia trojańskiego do pakietu, z którego mógłby skorzystać inny użytkownik.

UWAGA, którą chcę Nix dodać : powinna być użyteczna w wybranym systemie uniksowym (np. Dystrybucja Linuksa).

Istnieje również powiązana duża kolekcja pakietów, które można zainstalować za pomocą menedżera pakietów Nix - Nixpkgs - wbudowanego na wiele platform :

• GNU / Linux na 32-bitowym i 64-bitowym x86 (i686-linux i x86_64-linux)
• Mac OS X (i686-darwin i x86_64-darwin)
• FreeBSD (i686-freebsd i x86_64-freebsd)
• OpenBSD (i686-openbsd)
• Windows / Cygwin (i686-cygwin),

i powiązana dystrybucja - NixOS :

NixOS to dystrybucja Linuksa oparta na Nix. Używa Nix nie tylko do zarządzania pakietami, ale także do zarządzania konfiguracją systemu (np. Do tworzenia plików konfiguracyjnych w / etc). Oznacza to między innymi, że można łatwo przywrócić całą konfigurację systemu do wcześniejszego stanu. Użytkownicy mogą także instalować oprogramowanie bez uprawnień administratora. Czytaj więcej…

i związany z nim „ciągły” system budowy - Hydra .

Przede wszystkim wynika to z zależności. Niektóre pakiety mogą nie zostać zainstalowane przez użytkownika - jak PolicyKit. W związku z tym wymagałoby to dodatkowego obciążenia dla osoby pakującej, która poświęca swój wolny czas, a zwykle instalacja programu jest tak prosta, jak pisanie sudo(stacja dla jednego użytkownika) lub dokuczliwy administrator.

Istnieją opcje instalacji w $ HOME

• Prymitywni językowi „menedżerowie pakietów” zwykle obsługują go po wyjęciu z pudełka (jak klejnot dla Ruby lub cabal dla Haskell) lub z drobnymi poprawkami (zapomniałem nazwy dla python)
• Dobre stare ./configure --prefix=$HOME/sandbox --enable-cool-feature && make all install(lub odmiany takie jak jhbuild).
• Tam był program zainstalować w $ HOME kilka lat temu. Jednak nie mogę go znaleźć - wydaje mi się, że prawie nikt go nie użył, ponieważ albo sami je zainstalowali, albo nękali administratorów.

Używam JuJu, który zasadniczo pozwala mieć naprawdę małą dystrybucję linuksa (zawierającą tylko menedżera pakietów) w twoim katalogu $ HOME / .juju.

Pozwala mieć dostęp do twojego niestandardowego systemu w katalogu domowym przez proot, a zatem możesz instalować dowolne pakiety bez uprawnień roota. Będzie działał poprawnie dla wszystkich głównych dystrybucji Linuksa, jedynym ograniczeniem jest to, że JuJu może działać na jądrze Linuksa z minimalną zalecaną wersją 2.6.32.

Kolejny z raczej innym modelem to 0install . Opiera się na pomyśle, że tak naprawdę nie instalujesz pakietów, ale po prostu je uruchamiasz z globalnej przestrzeni nazw, która pobiera, kompiluje w razie potrzeby i buforuje oprogramowanie, którego chcesz użyć.

Jeśli nie masz nic przeciwko kompilacji ze źródła i samodzielnemu rozwiązywaniu zależności, a przede wszystkim chcesz, aby menedżer pakietów obsługiwał operacje wdrażania / cofania / aktualizacji, możesz rzucić okiem na GNU Stow lub nieco ulepszony XStow . Za ich pomocą instalujesz scenę instalacji w oddzielnym katalogu (zwykle poniżej $PREFIX/stow), a następnie stow tworzy dowiązania symboliczne do oprogramowania z Twojego prawdziwego prefiksu. Ułatwia to całkowite usunięcie oprogramowania. Z powodzeniem używam go do zarządzania niestandardowo zainstalowanym oprogramowaniem na mojej uczelni.

Moje doświadczenie jest naprawdę ograniczone tylko do yum, ale nie rozumiem, dlaczego nie mógłbym upuścić pliku repo do ~ / etc / yum.repos.d i kazać yum zainstalować wszystko na koncie domowym.

Główni menedżerowie pakietów Linuksa postrzegają świat jako sysadmin ... gdzie maszyna jest pojedynczą jednostką. Pozwala to uzyskać odpowiedzi na pytania takie jak „jakie wybitne błędy dotyczą systemu X” i „czym różnią się system X i system Y”. Dzięki temu yum może mieć „historię”, która jest użyteczna, mieć wersje rpmdb i robić rzeczy takie jak „mniam - aktualizacja bezpieczeństwa” itp.

Istnieje kilka menedżerów pakietów, takich jak zero-install, którzy próbują postrzegać świat tak, jak użytkownik ... jakie aplikacje zrobić ja mam dostęp.

Możesz pomyśleć, że później jest lepszym modelem, ale IMNSHO istnieje powód, dla którego nie słyszałeś o instalacji zerowej, ale słyszałeś o mniam.

W bloku jest nowy dzieciak: „ JuNest ( Jailed User NEST) - Dystrybucja oparta na Arch Linux, która działa na dowolnej dystrybucji Linuksa bez dostępu roota”. @ https://github.com/fsquillace/junest Zaletą jest to, że nie wprowadza nowego rodzaju formatu pakietu, więc po bardzo łatwej instalacji (minimum: ok. 320 mln), kompletne repozytorium Arch Linux (ponad 13000 pakiety ATM) jest na wyciągnięcie ręki.

W szczególności narzędzia używane przez Slackware installpkg. Ze strony podręcznika:

--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.

Nie znam jednak lepszych nakładek, które mogłyby to zrobić (np slapt-get. O ile wiem, nie mogę tego zrobić). Teoretycznie powinieneś mieć możliwość aliasu installpkgdo installpkg --root ~/Apps- jednak myślę, że większość frontendów wymaga rootowania do uruchomienia, co przeczy temu.

Sugerowałbym http://linuxbrew.sh/

Jest to w zasadzie rozwidlenie naparu dla systemu macOS i ma wstępnie skompilowane pliki binarne do użytku ...

Szczególnie nadaje się do obsługi starszych wersji gcc.

Jeśli naprawdę chcesz zainstalować ręcznie, przydatnym przewodnikiem jest http://www.linuxfromscratch.org/

Yum musi napisać do bazy danych, która jest własnością root. Z tego powodu nie można go używać jako zwykłego użytkownika.

Możesz spróbować zdekompresować pliki rpm (rpm2cpio package.rpm | cpio -idmv) w wybranym katalogu.

Ale kiedy uruchomisz swój program, musisz zadbać o zmodyfikowanie LD_LIBRARY_PATH w celu załadowania zależnych bibliotek. Również to nie rozwiąże żadnych zależności.

Przykład:

# 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)

Powyższe nie ma żadnych zależnych bibliotek, w przeciwnym razie musiałbyś użyć czegoś takiego:

export LD_LIBRARY_PATH=./usr/lib ./usr/bin/program