Tato dokumentace je jen pro Turris OS 3.x, který se už nenachází na nově prodávaných routerech. Novou dokumentaci najdete na https://docs.turris.cz/.
Updater je část firmware, která instaluje a udržuje aktuální balíčky. Oproti obvyklým správcům balíčků přináší jisté výhody. Zavádí zcela nový způsob správy balíčků a nové možnosti nastavení. Napřed se tedy podívejme na teoretické rozdíly ve správě balíčků.
Také si přečtěte o Odložení aktualizací.
Tento článek hovoří pouze o novém updateru (updater-ng). Omnia ho používá již od začátku, pro Turrisu 1.x je přechod proveden ve verzi Turris OS 3.7.
Správci balíčků, kteří pocházejí z osobních počítačů a serverů, jsou programy, které umí instalovat balíčky. Dělají tak na příkaz uživatele. V důsledku toho fungují interaktivně. V případě, že je třeba vyřešit problém, nabídnou uživateli možnosti a nechají rozhodnutí na něm. Navíc, fungují na úrovni jednotlivých balíčků. Pokud je funkcionalita jednoho balíčku rozštěpena v další verzi mezi více balíčků, nijak danou situaci neošetřují.
Do této kategorie patří i opkg
. To však, vzhledem k úspornosti implementace, neumí update celého systému (resp. umí se o něj pokusit, ale v mnoha případech dostane systém do zcela nepoužitelného stavu).
Kombinuje některé vlastnosti klasických správců (například to, že lze spravovat libovolné balíčky) a doplňuje je o vlastnosti nutné pro updater v routeru ‒ schopnost pracovat zcela autonomně. V průběhu svého běhu tedy pouze informuje uživatele, ale nikdy se aktivně nedotazuje.
Aby toto mohl splnit tak veškeré požadavky a preference na software musí být předem popsány v konfiguraci updateru. Základní konfigurace obvykle obsahuje jen seznam repozitářů a seznam požadovaných balíčků, ale je možné popsat i preference řešení konfliktů či výběr z více možných kandidátů.
Toto je základní a trochu zjednodušený princip, jak updater funguje:
Toto má několik důležitých důsledků. Jednak, software nainstalovaný updateru „za zády“ bude při nejbližším updatu odstraněn. Jednak, každý kus nainstalovaného softwaru musí mít nějaký zdroj, odkud pochází (repozitář).
Toto je metoda, při které je největší přímá kontrola nad tím, co se děje. Je možné oeditovat konfigurační soubory v /etc/updater/conf.d
(jakýkoliv soubor v tomto adresáři je načten jako konfigurace). Jsou v jazyce Lua a specifické příkazy pro updater jsou popsané zde (některé části ještě nejsou zcela podporované). Pro základní nastavení ale obvykle stačí níže uvedené příkazy.
Po změně konfigurace pusťte příkaz updater.sh
, aby byly změny hned aplikovány (a případné chyby nahlášeny).
Je následován jedním či více jmény balíčků. Jedná se o požadavek o nainstalování těchto balíčků:
Install("vim-full") Install("strace")
Lze ještě doplnit o upravující parametry instalace, ty jsou popsány ve výše zmíněné dokumentaci.
Přidává nový repozitář. Například:
Repository("turris", "https://repo.turris.cz/omnia/packages/turrispackages", { ocsp = false, pubkey = "file:///etc/updater/keys/release.pub" })
Tento již přidávat nemusíte, ekvivalentní již je v základním nastavení přítomný. Ale můžete si přidat vlastní.
Příkaz opkg
při instalaci a smazání balíčku upravuje soubor /etc/updater/conf.d/opkg-auto.lua
. Tento soubor je upravován programově a proto není doporučené do něj zasahovat ručně.
Tento postup je jednodušší a funguje i přes webové rozhraní LuCI. Na druhou stranu jde o nedokonalou abstrakci, neboť fungování opkg
a updateru je z principu rozdílné. Při složitějších zásazích tedy může dojít k neočekávaným výsledkům.
Userilisty, nebo též seznamy balíčků, je možné zapínat v rozhraní Foris
. Ty zapínají většinou více balíčků zároveň, s tématicky podobnou funkcionalitou. Taktéž, balíčky z těchto seznamů dostávají trochu lepší péči, než zbytek a jsou testovány pohromadě.
Smazání balíčku pomocí opkg
zapříčiní dvě věci. Jednak jej smaže ze systému a jednak jej odstraní z /etc/updater/conf.d/opkg-auto.lua
, pokud se tam nacházel. Ale pokud updater dojde k názoru, že je balíček potřeba z jiného důvodu, nainstaluje jej zpět do systému.
Důvody mohou být následující:
NAS
obsahuje mnoho balíčků, které můžete a nemusíte využívat). V takovém případě lze buď odinstalovat userlist a nainstalovat jednotlivé balíčky, které potřebujete, nebo vynutit absenci balíčku (popsáno níže)./etc/updater/conf.d
. Řešením je balíček smazat z takového konfiguračního souboru, pokud se jedná o Vámi vytvořený soubor.
V některých případech lze vynutit absenci balíčku následujícím příkazem v /etc/updater/user.lua
:
Uninstall("jmeno-balicku", { priority = 60 })
Podobně jako příkaz Install
požaduje, aby balíček byl nainstalovaný, příkaz Uninstall
požaduje aby nainstalovaný nebyl. Dojde ke konfliktu požadavků, ale protože jsme nastavili vyšší prioritu (výchozí je 50), tento převáží. Pozor, toto může zapříčinit odstranění i dalších balíčků, pokud na tomto balíčku závisí.
Tento problém většinou nastává kvůli příkazu Uninstall
, který jste
pravděpodobně přidali jako řešení předchozího problému. Balíček který závisí na
balíčku který vynucujete jako nenainstalovaný nemůže mít splněné závislosti a je
tak odstraněn. Řešením je zjistit si na kterém Vámi blokovaném je problematický
balíček závislý. Pokud daný balíček jste ochotní mít na systému tak pro něho
Uninstall
příkaz odstraňte. Pokud trváte na tom, že daný balíček na systému
nechcete, pak je jediné řešení nemít ani nainstalované balíčky které na něm
závisí.