Dotaz: Linuxove balicky

[Honza]

Ahoj,

linux pouzivam uz nejaky rok ale jedna vec mi neni stale jasna. Kdyz chci nainstalovat nejaky balicek ktery neni v repozitari tak si nekde stahnu zdrojak (treba z gitu) - nainstaluju podle instrukci.

1. Jak je to se zavislostmi? Stahnou se automaticky nebo musim nejak rucne?

2. Co bezpecnost, kdyz se bude chtit nainstalovat do /bin nebo /sbin a ne jen do lokalu?

3. Jak pak na odinstalaci nebo pripadne na upgrade?

Diky, H.

---

---

Odpovědi

[wamba]

1. Ručně.

2. Smůla, musíš tomu věřit.

3. Typicky k make install existuje i make uninstall. Další možnost je instalovat do samostatného adresáře například v /opt a ten pak smazat (ale pak když z toho chceš používat třeba knihovny, tak je to opruz) nebo použít checkinstall, který vytvoří takybalíček a ten můžeš později pomocí správce balíčků odstranit a smaže to i soubory.

[goro]

Aneb jak je to s flatpakem..

[Andrej]

2. Smůla, musíš tomu věřit.

Tohle je naprostý nesmysl. Rád bych parafrázoval jednu reklamu: Nemusíš a nemusíš a nemusíš. Prostě nemusíš!

Od toho má například Arch už asi tak od třetihor fakeroot. Balíčky se samozřejmě instalují pod normálním uživatelem (nebo dokonce pod ještě omezenějším účtem) a knihovna fakeroot předstírá, že se daří nastavovat vlastníka a oprávnění na roota. Všechna příslušná metadata se ukládají a nakonec se zapíšou do výsledného .tar archivu, takže při pozdější instalaci balíčku pacmanem (už pod rootem, pochopitelně) se správně nastaví. K vytvoření toho .tar archivu ale není nikdy potřeba root, dokonce ani při make install.

Tohle^^^ ale není nic nového; je to postup, který je už přinejmenším celé jedno desetiletí standardem. Často a rád lidem říkám, že pokud jejich distribuce ve 2. dekádě 21. století pořád ještě vytváří balíčky pod rootem, ať tu distribuci vyhodí do digitální popelnice a přejdou na rozumnější distribuci.

Vytvoření balíčku v Archu je triviální; stačí si stáhnout PKGBUILD šablonu, vyplnit tam podle dokumentace pár detailů (například adresu Git/Mercurial/SVN/KdesiCosi repository, adresu tarballu ke stažení, checksumy atd.) a pak pomocí makepkg vyrobit balíček. Tohle celé se obejde bez roota a nemusíš tedy ničemu věřit. Balíček si pak můžeš před instalací zkontrolovat (tar -tJf ...), co přesně v něm je.

3. Typicky k make install existuje i make uninstall. Další možnost je instalovat do samostatného adresáře například v /opt a ten pak smazat (ale pak když z toho chceš používat třeba knihovny, tak je to opruz) nebo použít checkinstall, který vytvoří takybalíček a ten můžeš později pomocí správce balíčků odstranit a smaže to i soubory.

Když si člověk zvykne i pro velice jednoduché buildy dělat zásadně vždycky balíček (protože třeba v Archu je vytvoření balíčku skoro stejně jednoduché jako manuální build), má z toho jenom samé výhody:

1. Obsah balíčku lze zkontrolovat předem.
2. Není možné, aby nevychovaný instalační skript sáhl na existující soubory z jiných balíčků; prostě k tomu nemá oprávnění.
3. Není žádný problém s odinstalací — standardní balíčkovací systém.
4. Při správném nastavení závislostí se nestane, že by zkompilovanému balíčku najednou zmizely závislosti (dynamické knihovny atd.).
5. Při aktualizaci na novější verzi člověk ušetří čas, když má PKGBUILD se vším potřebným. Stačí změnit verzi / download link, jde-li o tarball, v případě repository se makepkg automaticky podívá, co je nového.

Všechny ostatní (rozumné) distribuce mají podobné mechanismy. Sečteno a podtrženo: Doporučuju všechno instalovat jako balíček. Má to samé výhody a stačí jen obětovat 10 minut práce navíc, když člověk daný kus softwaru instaluje a kompiluje poprvé.

[Jendа]

Chápu správně, že jsi právě řekl, že balíček zkompiluješ a nainstaluješ pomocí sandboxu a pak zkompilovaný program spouštíš mimo sandbox?

[Josef Kufner]

Přesně tak. Sandbox ale není kvůli omezení běžícího programu, ale kvůli tomu, aby jeho instalátor nenadělal bordel v systému.

[Andrej]

No, v podstatě tam ten "sandbox" je kvůli omezení (nebo spíš oklamání) běžícího programu, v tomto případě instalátoru (třeba make install). Fakeroot zajistí, aby instalátor mohl běžet pod normálním omezeným účtem, ale aby se mu zdály sny o tom, že je root.

Samozřejmě se to nesnaží řešít adresáře; není to chroot. Falešným rootem se tady myslí falešný uživatel 0, nikoliv falešný adresář /. Instalátor tedy musí umět instalovat do zvoleného podadresáře. Podstatné ale je, že jakmile se pokusí sáhnout mimo vyhrazený podadresář, nepodaří se to, protože neběží pod rootem a nemá potřebná oprávnění.

[Aleš Kapica]

Fakeroot zajistí, aby instalátor mohl běžet pod normálním omezeným účtem, ale aby se mu zdály sny o tom, že je root.

To je moc hezky napsané.

[Andrej]

Jestli poukazuješ na přílišnou obšírnost mého popisu, myslím si, že je lepší k popisu přidat pár odkazů a vysvětlení, než pouze zmínit nějaký blíže neurčený sandbox, u kterého není jasné, jak se jmenuje, kde se používá a jak funguje.

Především jsem reagoval na nesmyslý výrok musíš tomu věřit. Nemusíš. Ale to je příliš málo informací pro někoho, kdo si chce nainstalovat software, že ano.

Instalace pomocí fakeroot prostředí je normální (a jediný) způsob přípravy balíčků v Archu; není to věc (mojí) volby nebo způsobu, jakým kompiluju balíčky. Je to standardní způsob fungování makepkg.

[Josef Kufner]

Existuje nástroj checkinstall, který kouká, co instalace dělá a podle toho vyrobí a nainstaluje balíček. Takže když pak tento balíček odstraníš, mělo by všechno hezky zmizet, jak se sluší a patří.

[k3dAR]

i kdyz to mozna neni nejcistejsi reseni, pridam priklad jak pomoci checkinstall balim rdiff-backup-fs

cd source

autoreconf -i -f -v

./configure

echo "Fuse filesystem for accessing rdiff-backup archives \n \
    rdiff-backup-fs is a filesystem in userspace that reads rdiff-backup \n \
    archives and provides convenient access for different revisions of the copied \n \
    files and directories." >description-pak

checkinstall --nodoc --install=no --fstrans=yes --pkgname=rdiff-backup-fs --pkgversion=1.0.0+hg20110607+samba --pkgrelease=4 \
        --pkgarch=amd64 --pkggroup=utils --pkgsource="https://github.com/rbrito/rdiff-backup-fs.git" --conflicts="archfs" --provides="archfs" --replaces="archfs" \
        --pakdir=".."

btw: kdyz uz zminuju rdiff-backup-fs, tak konkrente teda aplikuju rdiff-backup-fs samba patche, aby sel primontovana zaloha exportovat pres sambu (zameni z nazvu nevhodne : za -)
a nedavno me uz stvalo ze v primontovanem adresare representuji cas zalohy maji UTC nikoliv Lokalni, coz pro prohrabani v zdojaku sem nakonec zjistil ze je trivialni a jen se zmeni pripravena volba, viz:

--- rdiff-backup-fs.c.orig      2017-10-08 18:33:14.569144179 +0200
+++ rdiff-backup-fs.c   2017-10-08 18:33:39.221144471 +0200
@@ -23,7 +23,7 @@
     int options_count = 0;
     
     file_system_info = single(struct file_system_info);
-    file_system_info->rev_dir_time = REV_GMT_TIME;
+    file_system_info->rev_dir_time = REV_LOCAL_TIME;
 
     parse(file_system_info, argc, argv);
     initialize(file_system_info);

[Josef Kufner]

Nějaký rdiff-backup přes Fuse jsem kdysi zkoušel a bylo to ukrutně pomalé. rsync a hardlinky nebo btrfs snapshoty jsou mnohem lepší volba.

[k3dAR]

ale rsync a hardlinky narozdil od rdiff-backup nedelaji jen diff u zmenenejch souboru... u btrfs nevim...

[Josef Kufner]

V případě rsync se nedělá diff, dělají kopie celých změněných souborů na disku, ale po síti se přenáší jen rozdíly. Záleží na povaze záloh, zda to vadí. U btrfs bych čekal stejný přístup, ale na úrovni bloků.

Výhodou hardlinků a snapshotů je, že pro obnovu není potřeba žádný specializovaný nástroj. Prostě se to zkopíruje.

rdiff-backup bude výrazně efektivnější například na logy, kde se jen připisuje na konec. Nebo na malé změny velkých souborů obecně. Pro běžné zálohování však jsou zrovna logy cíleně vynechávány.

Z vlastní zkušenosti můžu říct, že rdiff-backup a rsync --linkdest se nijak zásadně ve spotřebě zálohovacího prostoru neliší. Výhodou rdiff-backup a snapshotů oproti rsync je schopnost říct, jak velký ten snapshot/diff je.

[k3dAR]

ze rsync po siti prenasi jen rozdily samozrejme vim, poukazoval sem ale prave na to ukladani, nikoliv prenos po siti :) rdiff-backup pouzivam lokalne na zalohu dat co se casto meni a kde je potreba historie, rsync pouzivam na zalohu celeho pole na zalozni server...