Kök Paketi Olmayan Yöneticiler

Araştırmamdan itibaren, tüm paket yöneticilerinin ayrıcalıklı bir kullanıcı olarak kullanılmakta ısrar ettikleri ve yüklenmeleri gerektiğine dikkat çekiyor görünmektedir /.

Genelde, yapmaktan hoşlandığım şey, basit bir hesap oluşturmak, bazı yazılımları derlemek ve $HOMEbu hesaba yüklemek . Çeşitli ayarları deneyebilirim ve sonra işim bittiğinde, hesabı yok et.

Ancak, derleme yazılımı sıkıcı hale gelir.

Tecrübelerim gerçekten sadece bunlarla sınırlı yum, ama neden bir repo dosyasını bırakıp ~/etc/yum.repos.dher şeyi bir ev hesabına yükleyemedim anlamıyorum .

Paket yöneticilerinin yazılım yüklemek için ayrıcalıklı bir kullanıcı olarak kullanılmaları için herhangi bir neden var mı?

İkili paketler, içindeki belirli konumlara yüklenecekleri varsayımı ile derlenir /. Bu her zaman kolayca değiştirilemez ve belirli ikili dosyaların yer değiştirip değiştirilemeyeceğini belirlemek için ek QA çabası gerekir (ilk başta yeterince zor!).

Bir dereceye kadar, bir alt dizinde kök dışı bir kullanıcı olarak tüm bir sistemi oluşturmak için fakechroot gibi şeyleri kullanabilirsiniz , ancak bu çok sıkıcı ve kırılgandır.

Kaynak paketlerde daha iyi şanslar olacaktır. Gentoo Öneki ve Rootless GoboLinux , /konum dışı kurulum yapabilen paket rootkullanıcılarıdır ve kullanıcılar tarafından kullanılamazlar .

Bir paket yöneticisi projesi var - Nix - aynı zamanda kullanıcı başına bir işlemi de destekleyen ilginç bir temel fikirle (" işlevsel " pkg yöneticisi):

Çok kullanıcılı destek

0.11 sürümünden başlayarak, Nix çoklu kullanıcı desteği vardır. Bu, ayrıcalıklı olmayan kullanıcıların yazılımı güvenle yükleyebilecekleri anlamına gelir. Her kullanıcı farklı bir profile, Nix'in mağazasında kullanıcının PATH'inde görünen bir paket grubuna sahip olabilir. Bir kullanıcı daha önce başka bir kullanıcının daha önce yüklediği bir paketi yüklerse, paket ikinci kez oluşturulmaz veya indirilmez. Aynı zamanda, bir kullanıcının bir Truva atını başka bir kullanıcı tarafından kullanılabilecek bir pakete enjekte etmesi mümkün değildir.

Eklemek İstiyorum Bir Not: Nix Seçtiğiniz bir Unix benzeri sistemde (örneğin, bir Linux dağıtımı) kullanılabilir olması gerekir.

De vardır Nix paketiyle manager-- ile kurulabilir paketlerin ilişkili büyük koleksiyon Nixpkgs platformların bir dizi için --built :

• 32 bit ve 64 bit x86'da GNU / Linux (i686-linux ve x86_64-linux)
• Mac OS X (i686-darwin ve x86_64-darwin)
• FreeBSD (i686-freebsd ve x86_64-freebsd)
• OpenBSD (i686-openbsd)
• Windows / Cygwin (i686-cygwin),

ve ilişkili bir dağıtım-- NixOS :

NixOS, Nix'i temel alan bir Linux dağıtımıdır. Nix yalnızca paket yönetimi için değil, sistem yapılandırmasını yönetmek için de kullanır (örn. / Etc içinde yapılandırma dosyaları oluşturmak için). Bu, diğer şeylerin yanı sıra, sistemin tüm yapılandırmasını daha önceki bir duruma kolayca geri döndürmenin mümkün olduğu anlamına gelir. Ayrıca, kullanıcılar root haklarına sahip olmadan yazılım yükleyebilirler. Daha fazla oku…

ve ilişkili bir "sürekli" yapı sistemi - Hydra .

Her şeyden önce bağımlılıklar kaynaklanmaktadır. Bazı paketler, kullanıcı benzeri PolicyKit tarafından yüklenmemiş olabilir. Bu nedenle, boş zamanlarını bağışlayan paketleyicilere ek bir yük getirilmesi gerekir ve genellikle programın yüklenmesi, yazmak sudo(tek kullanıcılı istasyon) veya nagging yöneticisi kadar kolaydır .

$ HOME içine yükleme seçenekleri var

• Dil ilkel 'paket yöneticileri' genellikle kutudan çıkarır (Ruby için Gem veya Ruby için kabal gibi) ya da küçük ayarlamalar (python için adı unuttum)
• İyi yaşlı ./configure --prefix=$HOME/sandbox --enable-cool-feature && make all install(veya jhbuild gibi değişkenler).
• Orada oldu birkaç yıl önce $ HOME de yüklemek için bir program. Ancak bulamıyorum - sanırım neredeyse hiç kimse onları kendileri kurarken ya da yöneticileri yok ederken kullandı.

Kullandığım Juju temelde $ HOME / .juju dizinde içinde gerçekten küçük linux dağıtımı (içeren sadece paket yöneticisi) sahip olmasını sağlar.

Özel sisteminizin ana dizinde proot üzerinden erişilebilir olmasını sağlar ve bu nedenle herhangi bir paketi kök ayrıcalıkları olmadan yükleyebilirsiniz. Tüm büyük linux dağıtımlarına uygun şekilde çalışacaktır, tek sınırlama JuJu'nun linux çekirdeğinde önerilen minimum 2.6.32 sürümüyle çalışabilmesidir.

Oldukça farklı bir modele sahip olan bir tane daha 0install . Gerçekten paketleri kurmamanız fikrine dayanır, ancak bunları yalnızca indiren, gerekirse derleyen ve kullanmak istediğiniz yazılımı önbelleğe alan küresel bir ad alanından çalıştırın.

Kaynaktan derleme ve bağımlılıkları çözme konusunda kendiniz iyiyseniz , öncelikle paket yöneticisinin konuşlandırma / yayılma / yükseltme işlemlerini yönetmesini istiyorsanız, GNU Stow veya biraz geliştirilmiş XStow'a bakmak isteyebilirsiniz . Onlarla, yüklemeyi ayrı bir dizine (genellikle altında $PREFIX/stow) geçirirsiniz ve ardından stow, yazılımın üzerine gerçek önekinizden linkler oluşturur. Bu, yazılımı tamamen kaldırmayı kolaylaştırır. Özel olarak yüklenen yazılımımı üniversitemde başarıyla yönetmek için kullanıyorum.

Tecrübelerim gerçekten yum ile sınırlı, ama neden bir repo dosyasını ~ / etc / yum.repos.d içine bırakamayacağımı ve yum'u her şeyi ev hesabına yükleyemediğimi anlamıyorum.

Yaygın Linux paket yöneticileri dünyayı makinenin tek bir varlık olduğu bir sysadmin olarak görüyorlar. Bu, "sisteme X için hangi olağanüstü hataların uygulandığı" ve "sistem X ile sistem Y'nin nasıl farklı olduğu" gibi soruların yanıtlarını almanızı sağlar. Bu aynı zamanda yum'un kullanılabilir, rpmdb sürümleri olan ve "yum --security update" gibi şeyleri yapmasını sağlayan bir "geçmişe" sahip olmasını sağlar.

Dünyayı bir kullanıcı gibi görmeye çalışan sıfır kurulum gibi bazı paket yöneticileri var ... yani. Ne uygulamaları yapmak ı erişebilir.

Daha sonradan daha iyi bir model olduğunu düşünebilirsiniz, ancak IMNSHO sıfır kurulumunu duymamanızın ama yum'ı duymanızın bir nedeni var.

Blokta yeni bir çocuk var: " JuNest ( Jailed User NEST) - Kök erişimi olmayan herhangi bir Linux dağıtımıyla çalışan Arch Linux tabanlı dağıtım." @ https://github.com/fsquillace/junest Advantage, yeni bir paket formatı sunmamasıdır, bu yüzden çok kolay bir kurulumdan sonra (minimum: yaklaşık 320M), tam Arch Linux deposu (13000'den fazla) paketleri ATM) parmaklarınızın ucunda.

Özellikle Slackware tarafından kullanılan aletler installpkgolabilir. Man sayfasından:

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

Bununla birlikte, bunu yapabilen daha iyi sınırların hiçbirini tanımıyorum (örneğin slapt-getbildiğim kadarıyla bunu yapamaz). Teorik olarak, takma adlar installpkgyapabilmelisiniz installpkg --root ~/Apps- bununla birlikte, çoğu cenazenin koşmak için kök gerektirdiğini düşünüyorum, bu da noktayı yener.

Ben öneririm http://linuxbrew.sh/

Temelde macOS için bir demlemek çatal ve kullanım için önceden derlenmiş bir ...

Özellikle eski gcc versiyonlarını kullanmak için idealdir.

Gerçekten elle yüklemek istiyorsanız, yararlı bir rehber http://www.linuxfromscratch.org/

Yum'un root tarafından kendisine ait olan veritabanına yazması gerekir. Bu nedenle normal bir kullanıcı olarak kullanamazsınız.

Seçtiğiniz bir dizinin içindeki rpm dosyalarını (rpm2cpio package.rpm | cpio -idmv) sıkıştırmayı deneyebilirsiniz.

Ancak, programınızı çalıştıracağınız zaman bağımlı kütüphaneleri yüklemek için LD_LIBRARY_PATH ayarını değiştirmeye özen göstermelisiniz. Ayrıca, bu herhangi bir bağımlılıkla ilgilenmeyecektir.

Örnek:

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

Yukarıdakilerin bağımlı kütüphaneleri yok, aksi halde benzeri bir şeyi kullanmanız gerekir:

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