Nicht-Root-Paketmanager

Aus meinen Nachforschungen geht hervor, dass alle Paketmanager darauf bestehen, als privilegierter Benutzer verwendet zu werden, und dass sie in installiert werden müssen /.

Normalerweise erstelle ich gerne ein Wegwerfkonto, kompiliere Software und installiere sie $HOMEfür dieses Konto. Ich kann verschiedene Setups ausprobieren und wenn ich fertig bin, zerstöre ich einfach das Konto.

Das Kompilieren von Software wird jedoch mühsam.

Meine Erfahrung ist eigentlich nur auf beschränkt yum, aber ich verstehe nicht, warum ich eine Repo-Datei nicht ablegen ~/etc/yum.repos.dund alles auf einem Home-Account installieren kann.

Gibt es einen Grund, warum Paketmanager als berechtigter Benutzer zum Installieren von Software verwendet werden müssen?

Binärpakete werden unter der Annahme kompiliert, dass sie an bestimmten Speicherorten in installiert werden /. Dies ist nicht immer leicht zu ändern und es würde zusätzlichen Qualitätssicherungsaufwand erfordern (der in erster Linie schwierig genug ist!), Um festzustellen, ob bestimmte Binärdateien verlagerbar sind oder nicht.

Bis zu einem gewissen Grad können Sie beispielsweise fakechroot verwenden , um als Nicht-Root-Benutzer ein gesamtes System in einem Unterverzeichnis zu erstellen. Dies ist jedoch mühsam und anfällig.

Mit Quellpaketen haben Sie mehr Glück. Gentoo Prefix und Rootless GoboLinux sind beide Paketmanager, die an einem anderen /Ort installiert werden können und möglicherweise von Nichtbenutzern verwendet werden rootkönnen.

Es gibt ein Paketmanager-Projekt - Nix - mit einer interessanten Grundidee (ein " funktionaler " Paketmanager), der auch eine benutzerspezifische Operation unterstützt:

Unterstützung für mehrere Benutzer

Ab Version 0.11 bietet Nix Unterstützung für mehrere Benutzer. Dies bedeutet, dass nicht privilegierte Benutzer Software sicher installieren können. Jeder Benutzer kann ein anderes Profil haben, eine Reihe von Paketen im Nix-Store, die im PATH des Benutzers angezeigt werden. Wenn ein Benutzer ein Paket installiert, das bereits von einem anderen Benutzer installiert wurde, wird das Paket nicht ein zweites Mal erstellt oder heruntergeladen. Gleichzeitig ist es nicht möglich, dass ein Benutzer ein Trojanisches Pferd in ein Paket injiziert, das möglicherweise von einem anderen Benutzer verwendet wird.

HINWEIS, DEN ICH HINZUFÜGEN MÖCHTE: Nix Sollte in einem Unix-ähnlichen System Ihrer Wahl (z. B. einer Linux-Distribution) verwendbar sein.

Es gibt auch eine große Sammlung von Paketen, die mit dem Nix-Paketmanager installiert werden können - Nixpkgs -, der für eine Reihe von Plattformen erstellt wurde :

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

und eine zugehörige Distribution - NixOS :

NixOS ist eine Linux-Distribution, die auf Nix basiert. Es verwendet Nix nicht nur zur Paketverwaltung, sondern auch zur Verwaltung der Systemkonfiguration (z. B. zum Erstellen von Konfigurationsdateien in / etc). Dies bedeutet unter anderem, dass die gesamte Konfiguration des Systems problemlos auf einen früheren Zustand zurückgesetzt werden kann. Außerdem können Benutzer Software ohne Root-Rechte installieren. Weiterlesen…

und ein zugehöriges "kontinuierliches" Build-System - Hydra .

Erstens liegt es an Abhängigkeiten. Einige Pakete können möglicherweise nicht von einem Benutzer installiert werden, z. B. PolicyKit. Daher würde es eine zusätzliche Belastung für den Packager bedeuten, der seine Freizeit spendet und das Installieren des Programms normalerweise so einfach ist wie das Eingeben sudo(Einzelplatz) oder das Nörgeln des Administrators.

Es gibt Optionen für die Installation in $ HOME

• Sprachprimitive 'Paketmanager' unterstützen es normalerweise direkt (wie gem für Ruby oder cabal für Haskell) oder mit kleinen Anpassungen (ich habe den Namen für Python vergessen)
• Gut alt ./configure --prefix=$HOME/sandbox --enable-cool-feature && make all install(oder Variationen wie jhbuild).
• Vor einigen Jahren gab es ein Programm, das bei $ HOME installiert werden sollte. Ich kann es jedoch nicht finden - ich denke, fast niemand hat es benutzt, da sie es entweder selbst installiert haben oder Administratoren.

Ich verwende JuJu, das im Grunde genommen erlaubt, eine wirklich winzige Linux-Distribution (die nur den Paketmanager enthält) in Ihrem $ HOME / .juju-Verzeichnis zu haben.

Es ermöglicht Ihnen, Ihr benutzerdefiniertes System innerhalb des Home-Verzeichnisses über Proot zugänglich zu machen. Daher können Sie alle Pakete ohne Root-Rechte installieren. Es wird ordnungsgemäß auf allen wichtigen Linux-Distributionen ausgeführt. Die einzige Einschränkung besteht darin, dass JuJu auf einem Linux-Kernel mit der empfohlenen Mindestversion 2.6.32 ausgeführt werden kann.

Ein anderes mit einem etwas anderen Modell ist 0install . Es basiert auf der Idee, dass Sie Pakete nicht wirklich installieren, sondern sie lediglich in einem globalen Namespace ausführen, der die gewünschte Software herunterlädt, bei Bedarf kompiliert und im Cache speichert.

Wenn Sie in der Lage sind, aus dem Quellcode zu kompilieren und Abhängigkeiten selbst aufzulösen, und hauptsächlich möchten, dass der Paketmanager die Bereitstellungs- / Aufhebungs- / Aktualisierungsvorgänge ausführt, sollten Sie sich GNU Stow oder das etwas verbesserte XStow ansehen . Mit ihnen inszenieren Sie die Installation in einem separaten Verzeichnis (normalerweise unter $PREFIX/stow) und stellen dann von Ihrem tatsächlichen Präfix aus Symlinks zur Software her. Dies macht es einfach, die Software dann vollständig zu entfernen. Ich verwalte damit erfolgreich meine individuell installierte Software an meiner Universität.

Meine Erfahrung ist eigentlich nur auf yum beschränkt, aber ich verstehe nicht, warum ich eine Repo-Datei nicht in ~ / etc / yum.repos.d ablegen und yum alles auf einem Home-Account installieren lassen könnte.

Die Mainstream-Linux-Paketmanager betrachten die Welt als einen Systemadministrator, bei dem die Maschine eine Einheit ist. Auf diese Weise erhalten Sie Antworten auf Fragen wie "Welche ausstehenden Errata gelten für System X?" Und "Wie unterscheiden sich System X und System Y?". Dies ermöglicht es yum auch, "einen Verlauf" zu haben, der verwendbar ist, rpmdb-Versionen hat und Dinge wie "yum --security update" usw. ausführt.

Es gibt einige Paketmanager wie Zero-Install, die versuchen, die Welt so darzustellen, wie ein Benutzer es tun würde. welche Anwendungen tun ich Zugriff haben.

Sie mögen denken, dass das spätere Modell ein besseres ist, aber IMNSHO gibt es einen Grund, warum Sie nicht von Zero-Install gehört haben, sondern von Yum.

Es gibt ein neues Kind auf dem Block: " JuNest (Jailed User NEST) - Die Arch Linux-basierte Distribution, die auf jeder Linux-Distribution ohne Root-Zugriff läuft." @ https://github.com/fsquillace/junest Der Vorteil ist, dass keine neue Art von Paketformat eingeführt wird. Nach einer sehr einfachen Installation (Minimum: ca. 320M) wird das komplette Arch Linux-Repository (mehr als 13000) erstellt Pakete ATM) ist an Ihren Fingerspitzen.

Die von Slackware speziell verwendeten Tools installpkgkönnen. Von der Manpage:

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

Ich kenne jedoch keines der besseren Frontends, die dazu in der Lage sind (z slapt-get. B. kann ich das meines Wissens nicht). Theoretisch sollten Sie in der Lage sein, einen Alias installpkgzu erstellen installpkg --root ~/Apps- ich denke jedoch, dass die meisten Frontends root erfordern, um ausgeführt zu werden, was den Punkt zunichte macht.

Ich würde vorschlagen, http://linuxbrew.sh/

Es ist im Grunde genommen eine Fork of Brew für MacOS und hat vorkompilierte Binärdateien für die Verwendung ...

Besonders geeignet für ältere gcc-Versionen.

Wenn Sie wirklich von Hand installieren möchten, finden Sie unter http://www.linuxfromscratch.org/ eine nützliche Anleitung.

Yum muss in die Datenbank schreiben, deren Eigentümer root ist. Aus diesem Grund können Sie es nicht als normaler Benutzer verwenden.

Sie können versuchen, RPM-Dateien (rpm2cpio package.rpm | cpio -idmv) in einem Verzeichnis Ihrer Wahl zu dekomprimieren.

Wenn Sie Ihr Programm ausführen, müssen Sie jedoch darauf achten, LD_LIBRARY_PATH zu ändern, um die abhängigen Bibliotheken zu laden. Auch dies wird keine Abhängigkeiten berücksichtigen.

Beispiel:

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

Die oben genannten haben keine abhängigen Bibliotheken, sonst müssten Sie so etwas wie verwenden:

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