Aktualizace SW

Od Michal Vaner (>>)

Dne 2014-04-16 08:58

Dobrý den

Jednak se to objeví po přihlášení do administračního rozhraní. Ta hláška ale zmizí buď odkliknutím, nebo restartem. Navíc, tyto hlášky se objeví až s nejbližším velkým updatem, který plánujeme na nejbližší hodiny až dny.

Trvalejší záznam je v /usr/share/updater/updater-log

Aktualizace se dějí automaticky, bez zásahu uživatele. Každou celou hodinu to kontroluje, jestli jsme nějaké updaty vystavili, a pokud to nějaké najde, tak je bez čekání nainstaluje. Dá se vynutit puštění té kontroly ručně, z konzole:

updater.sh -n

Navíc, v /etc/config/updater lze nastavit, které skupiny dodatečných balíků to má instalovat. Ale protože pro to zatím nemáme žádné rozumné rozhraní, tak jsou ve výchozím stavu povolené skoro všechny skupiny, co jsme zatím vytvořili. Jediná tam nezmíněná je shell-utils, pro pokročilé uživatele, co se chtějí vrtat v příkazové řádce a mají rádi plnohodnotný bash a vim a podobně.

Od Ondřej Caletka (>>>)

Dne 2014-04-17 08:33

Zajímalo by mě, jak se automatické aktualizace vypořádávají se změněnými konfiguračními soubory. Co když nová verze balíku zavede zpětně nekompatibilní změnu syntaxe konfigurace? Znamená to, že služba přestane fungovat do ručního zásahu?

A restartují se služby po provedení update?

Od Michal Vaner (>>)

Dne 2014-04-17 10:29

Dobrý den

Jak je možné, že někteří uživatelé tak spolehlivě odhalí, kde se nacházejí výzvy O:-).

Balíčky v OpenWRT umí označit některé soubory jako konfigurační. Pokud je soubor v původním stavu tak, jak byl nainstalován, tak se přepíše novou verzí z balíčku. Pokud se liší, ponechá se starý a nová verze se uloží jako soubor.opkg. To nepřepíše uživateli jeho konfiguraci, kterou pracně vypotil, ale problém s nekompatibilní verzí existuje.

Většina konfigurace je snad v UCI. Tam se nebude měnit syntaxe, mohou ale přibývat a ubývat volby. U běžných věcí, které používáme, budeme mít otestované, že se upgradem nic nerozbije (případně vyřešíme nějakou migraci), u méně obvyklých věcí se to asi rozbít může :-|. Tedy, pokročilejší uživatel, který na routeru pouští kdeco, může potkat nějaké problémy, běžný uživatel, který se přes to jen připojuje k internetu by neměl.

Služby ‒ ty, které se nám dostaly nějak více do rukou, tak ty se restartují při upgradu. Ale celý repozitář OpenWRT jsme neprolézali, abychom to dopsali všude.

Od horada

Dne 2014-04-25 06:56

Do /etc/config/updater jsem si přidal sekci shell-utils kvůli shellu, vimu a podobně, po včerejších updatech mi ale přišel email o odstranění balíků: smap, uhttpd, uhttpd-mod-ubus, psmisc, libncurses, htop, terminfo, vim-full, bash.
Po chvíli zkoumání jsem zjistil, že mi ze souboru /etc/config/updater zmizela skupina shell-utils, bylo to ale trochu hloupé, protože po odstranění Bahse jsem se nemohl přes ssh vůbec přihlásit (měl jsem jej nastavený jako login shell - řešení nainstalovat bash přes LuCI, naštěstí prošlo bez problému).
Trochu mě zmátl htop, který jsem myslím instaloval ručně, dříve než jsem přidal tuhle skupinu.

Tak jako tak by mě ale spíš zajímalo jestli se nějak nechá zajistit aby mi to tu další updaty nerozbili?

Trochu související.. v emailu o provedených updatech by mohlo být info zda vše proběhlo ok, nebo zda se vyskytl nějaký warning (třeba že se nepřepsala konfigurace a je vyžadován ruční zásah)... ale nevím jestli to vůbec opkg nějak rozumě hlásí...

Od CIJOML

Dne 2014-04-25 07:15

nastav si bash do start profilu a mas po problemu:)

Od horada

Dne 2014-04-25 07:21

Myslíte nechat ash jako login shell a po nalogování pustit bash? (nějak automaticky... nevím přesně jak se to v ash dělá - jestli přes soubor ~/.profile?).

Od CIJOML

Dne 2014-04-25 07:22

presne tak

Od stibi

Dne 2014-05-22 22:53

Jaký je ideální způsob, jak ten /bin/bash po přihlášení spustit z ~/.profile ?
Zarazilo mě, že stačí SHELL=/bin/bash.

Původně jsem vygoolil toto:

SHELL=/bin/bash
exec /bin/bash --login

Ale to se chovalo divně…nejdřív se pořád dokola spouštěl nejspíš bash, takže na terminálu pořád dokolečka lítal ASCII Turris welcome baner…při dalších pokusech se občas zobrazil jen 2x a bylo to ok…podivné.
Jak to funguje?

Od Michal Vaner (>>)

Dne 2014-04-25 08:30

Dobrý den

Chyba je na mé straně, /etc/config/updater nebyl označený jako konfigurační soubor, takže nebyl chráněn proti přepsání. Jdu to opravit, ale nevím, jestli opkg tu ochranu dělá podle nově instalovaného balíčku, nebo starého, který se nahrazuje :-|.

S těmi warningy, tam je to horší. Opkg sice něco vypisuje na svůj chybový výstup, ale je to určené spíš pro lidi. Ne, že by to nešlo naparsovat, ale asi to nemá nejvyšší prioritu. Každopádně určitě chci někdy brzy implementovat hlášení o tom, když updater opakovaně padá (není to jen třeba krátkodobý výpadek internetu, ze kterého se sám vzpamatuje).

Od horada

Dne 2014-04-25 11:01

A co vložit do emailu celý log z updatu (asi nejlépe volitelně nastavitelné)?
(člověk by to sice musel projet očima... ale nemusel by se přihlašovat na router a prohledávat logy...)

Od Michal Vaner (>>)

Dne 2014-04-28 16:10

Dobrý den

Abych si to ujasnil, který log máte na mysli? To, co se objeví ve /var/log/messages? Nebo to, co vypadne z updater.sh, když ho pustíte ručně? A posílat každou hodinu, i když se nic neupdatuje?

Totiž, ta věc neumí příliš uživatelsky přívětivého výstupu a asi ani brzy nebude. Bylo to plánované jako zcela automatická a bezobslužná věc, původně se nepočítalo ani s tímhle posíláním.

Od horada

Dne 2014-04-28 18:02

Myslel jsem tak jak by měly chodit emaily že se něco aktualizovalo, tak tak že by s tím přišel i log z aktualizace... ale jestli to není uživatelsky moc vypovídající... tak to asi nemá cenu.