Menedżerowie pakietów innych niż root


51

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?

Odpowiedzi:


35

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.


3
Dodam, że istnieją 2 rodzaje relokowalności. Pakiet może zakładać, że zawsze znajduje się w określonym miejscu lub inne rzeczy są w niektórych miejscach (jak /bin) lub może zakładać, że jest zainstalowany w miejscu określonym przez --prefix. Podczas gdy te drugie mogą być omijane przez te projekty, te pierwsze wymagają poprawek do kodu źródłowego.
Maciej Piechotka

Inną opcją a la Gentoo Prefix, Rootless i Nix jest pkgsrc . Pochodzi z NetBSD, ale działa na różnych platformach.
Michael Ekstrand

2
Pakiety binarne są kompilowane przy założeniu, że zostaną zainstalowane w określonych lokalizacjach w./ Brzmi to jak wymóg, który może być uzasadniony może 30 lat temu, ale nie teraz. Czy na przykład envprogram nie ma na celu rozwiązania tego rodzaju problemów? Jeśli nie, łatwo jest wyjść ze schematem konfiguracji dowolnego pliku binarnego w celu wyszukiwania innych plików binarnych w określonych lokalizacjach.
Piotr Dobrogost

1
@PiotrDobrogost do pewnego stopnia tak, do pewnego stopnia nie. Na przykład nie ma zmiennej środowiskowej dla /etclub (zgodnie z moją wiedzą) /usr/lib/<packagename>/lub /usr/libexec/<packagename>/. /usr/sharemogą być zmienione przez zmienne XDG, które zostały wydane w tym stuleciu i niekoniecznie są przystosowane do starszych programów.
Maciej Piechotka,

28

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 .


4
Ładne podsumowanie. Niedawno ogłoszono GNU Guix. Menedżer pakietów GNU oparty na nix. savannah.gnu.org/forum/forum.php?forum_id=7436
Davorak

2
@Davorak Jakie są różnice między nixi guix. Ponieważ teraz naprawdę używam nixdo swojej pracy, chcę wiedzieć, czy mogę rozważyć guixinną implementację narzędzia, którego potrzebuję. Czy mogę gdzieś przeczytać podsumowanie różnic? Być może mógłbyś nawet napisać odpowiedź z takim streszczeniem tutaj, ogłaszając jeszcze jedno alternatywne rozwiązanie?
imz - Ivan Zachharyaschev

6

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.

1
Naprawdę nie rozumiem, jak to przekonujący argument. To, że pakiet nie działa, ponieważ nie jest wywoływany jako root, nie oznacza, że ​​pomysł nie jest wykonalny. Oczekuje się, że PolicyKit nie będzie działać w tego typu sytuacjach. Istnieje wiele innych pakietów, które można zainstalować bez uprawnień administratora. Znam menedżerów pakietów oprogramowania (Python's EasyInstall), ale nie są one globalnie stosowane tak jak yum lub apt-get. Czy ktoś zna nazwę programu, do którego odnosi się Maciej?
elmt

1
@elmt: Możliwie stow , które mogą Cię zainteresować mimo to (ale jest to narzędzie, a nie źródło pakietu).
Gilles „SO- przestań być zły”

@Gilles: Nie - miał GUI i miał być „prosty”. Myślę, że obecny kierunek to raczej synaptic / packagekit.
Maciej Piechotka

6

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.


4

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


4

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.


3

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.


2

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.


1

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.



0

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
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.