Upgrade na Turris OS 3.9

Zdravím,
a asi bych měl předem upozornit, že se jedná spíš a vybrečení se z frustrace z nového OS pro Turris Omnia, který by mělo sloužit jako feedback.
Celý nadšený z nových funkcionalit, jsem se rozhodl v sobotu pro instalaci nového Turris OS 3.9. Po předchozích zkušenostech jsem se rozhodl uvést router do továrního nastavení a udělat všechno od začátku a správně, protože jsem měl celou sobotu volno.
Od 12:00 do 22:00 jsem věnoval nastavováním různých služeb a potřeb mojí domácí sítě (VPN, statické IP adresy dle MAC, Wi-Fi pro hosty, Honeypot, Netmetr…)
Když pominu problémy, které tu popisovali již jiní uživatelé (stejné heslo pro statistiky a honeypot službám, které nefungovalo, nemožnost ověřit e-mail pro sběr statistik, nefunkční honeypot), tak ve chvíli kdy jsem končil a měl vše za funkční a router mě přestal přidělovat IP adresy dle MAC (i když před hodinou vše fungovalo), jsem ztratil veškeré naděje.
Jako dlouholetý podporovatel OSS a vývojář vím, jak je těžké vyvíjet bez chyb (natož OS), ale při používání Turris si připadám spíš jako tester, než jako koncový uživatel. Nedovedu si představit, že bych si router koupil a používal jako běžný uživatel (často svůj problém vyřeším v konzoli, po grepování logu nebo prohledáváním fóra).
Nemohlo by se cz.nic zaměřit na vyladění funkcionality starých služeb, než neustále přidávat nové a způsobovat (soudím dle reakcí na fóru) uživatelům neustále opravování a hledání na fóru?
Omlouvám se za delší příspěvek, ale opravdu už jsem ze stavu softwaru pro Turris zklamaný a muselo to ven. Jakkoliv negativně to může vyznít, věřím, že se cz.nic podaří vše vyřešit a do budoucna zlepšit nasazování nových verzí.
Ještě dodám, že jsem radši skončil ve fázi, kdy jsem oříznul router na minimum služeb a používám minimum funkcionality routeru (bohužel), než řešit neustále zásahy do nastavení.

10 Likes

Mluvíte mi z duše! :slight_smile:
Turris teď žere poměrně dost času, než bylo obvyklé … speciálně po větších updatech.

Navíc mi s instalací TurrisOS 3.9 přestala fungovat tunelovaná IPv6 adresa přes Hurricane Electric.

Router sice na WAN6 rozhraní validní IPv6 adresu dostane, ale již ji nedistribuuje dál.
A teď marně hledám, kdo nebo co za to může.

Pakon … resp. Surricata? Mám podezření na ně, protože do doby instalace balíčku pakon žiju v domnění, že vše fungovalo, jak má.
Vím, že v rámci PaKon, resp. Surricaty, se přidává nějaké pravidlo do FW, které přesměrovává provoz v LAN Surricatě, ale není to moc zdokumentované, tak netuším, kde mám hledat a lovit.

1 Like

Nevím, zda-li je to způsobené pavouky … co si dobře vzpomínám, nové verze TurrisOS od původního vývojového teamu nebyly poznamenané žádnými většími chybami, které by pronikly až do deploy verzí, nebo … nedej bože, způsobily úplnou nefunkčnost routeru.

Chápu, že v raných fázích TurrisOS byla menší míra složitosti a provázanosti, ale to pro mne není omluvou pro to, stávat se nedobrovolně testerem na deploy verzích.

P.S.: “Update approval needed” mám zapnuto od začátku, co to bylo do TurrisOS přidáno (fakticky to začalo fungovat teprve nedávno) právě z důvodu, že nechci dostávat nové verze TurrisOS příliš brzo po vydání.

Teď mne napadá, zda-li to vlastně není trošku protismyslné … pořizoval jsem si router Turris právě proto, že budu mít pravidelně a včas aktualizovaný jeho firmware a donedávna to bylo vyzdvyhováno jako jedna z jeho největších předností a výhod před konkurenčními výrobky :slight_smile:

Bohužel, je to tak. Omnii jsem kupoval s tím, že budu mít bezpečný a spolehlivý stále aktualizovaný router/firewall. A že toto řešení nabídnu dál - rodině, známým příp. zákazníkům. Já osobně jsem s Omnií celkem spokojený. Když se něco rozbije, spravím to. S linuxem si tykáme. :sunglasses:
ALE. Bohužel. Všem, kterým jsem o Omnii říkal, musím stále opakovat, že to pro ně stále ještě není - není to stabilní prostředí. Situace, kdy po nějakém updatu přestane třeba wifi fungovat všem, kterým jsem to doporučil a budu muset rekonfigurovat třeba 10 Omnií mě zcela děsí.
Prosím, udělejte stabilní řadu, kde budou jen bezpečnostní patche. Pak klidně nějakou jinou, kde bude probíhat vývoj a s tím spojené věci. Ale za boha nedopusťte aby se produkční systém po updatu kvůli nějaké testing věci rozbil.
Vím, že je to spousta práce, ale pokud chcete Omnii rozšířit i mimo nadšence, tak se to asi jediná možnost.
I tak díky za Vaši práci - je to skvělá věc.

5 Likes

Já mám modráka, takže zadara a mám tím pádem zcela minimální právo do toho kecat, ale sám sebe se dost často ptám, zda-li bych byl ochoten do komerční verze routeru investovat své finanční prostředky.
Již několikrát jsem o koupi Omnie uvažoval, ale přesně tento červíček mne dosud od nákupu zviklal a odradil.

P.S.: Zdá se mi, že tahle diskuze v podobném tónu zde probíhá po nasazení každého většího update TurrisOS

Naprosto souhlasim s komentari vyse. Tyto nestabilni patche, ktere neco na routru rozbiji nebo jej uvedou do stavu neprovozuschopnosti me treba stoji hodne casu a penez (router mam v jinem state a pro kazdou opravu takto zbabranych updatu si musim vzit v praci dovolenou a letet to opravit :frowning: )

1 Like

Já myslím, že se opět vracíme k té staré, dosud neuzavřené diskuzi … vypsat někde, jak má vypadat vzorová konfigurace každého HW modelu routeru, která bude teamem před vypuštěním deploy verze TurrisOS otestována a garantována tak její plná funkčnost.

Já osobně bych se klidně vzdal všech dalších featurek navíc a zkonfiguroval si svůj router tak, aby byl v souladu s touto vzorovou doporučenou konfigurací a po každém update mi chodil na první dobrou tak, jak má.

I když si stále myslím (jak uže jsem někde výše psal), že můj router se příliš od základní konfigurace po továrním resetu neliší, jen pár drobnostmi, které jsou v souladu s doporučenám nastavením popsaným v oficiální dokumentaci projektu.
Ale ono ani to není samospásné … v oficiální dokumentaci je popsán i přechod routeru Turris 1.x na BTRFS, pak jsem se někde na fóru dočetl, že to není podporovaná konfigurace, a po přechodu se stane, že přestane fungovat oficiální funkcionalita (např. mountování přes LuCi) … je to sice nahlášeno, ale dosud neřešeno. A další a další kostlivci ve skříni.

Konec roku je ve znamení bilancování, tak by bylo dobré bilancovat …

1 Like

moje TO se taky prilis nelisi od zakladni konfigurace a je opravdu smutne ze i kdyz si clovek toto zarizeni koupi (vcetne propagovanych sluzeb jako automaticke updaty apod) tak se setkava s tim ze musi mesic co mesic neco opravovat a hledat kde je chyba diky nepovedemu updatu.

1 Like

Díky pánové. Na jednu stranu mě těší, že to nevidím takhle jen já, na druhou mě to mrzí, protože pořád věřím v to, že je to výjimečný produkt. Omnii jsem sponzoroval vývoj na Indiegogo a i přes všechny nedostatky, ho doporučuji dál (bohužel jen technicky zdatným jedincům).

V průběhu roku jsem se zaradoval, když jsem zaznamenal vstup Patrika Zandla do projektu a těšil se na změny. Chápu, že to není věc jednoduchá a doufám, že se v budoucnu změní.

Taky bych byl pro stable větev, která bude testovat základní nastavení routeru (třeba jen nastavení přes Foris a vždy bude funkční).

Naopak vývojová větev může přidávat Honeypoty, Nextcloud (na který také čekám), Netmeter a další věci, které běžný uživatel stejně nevyužije (předpokládám).

Což mě přivádí k myšlence, že záleží především na tvůrcích a jejich směru, kam chtějí router dostat. Pokud by měl být hračkou pro pár linuxových nadšenců, asi to nebude problém a plní to dobře. Pokud by se měl stát mainstreamem a zasáhnout větší část trhu, tak si troufám říct, že i přes veškeré kvality nemá šanci obstát.

Doufám, že tohle vlákno poslouží tvůrcům jako konstruktivní zpětná vazba od uživatelů.

4 Likes

Já mám taky modráka v té základní konfiguraci a i přesto mám z každé nové verze strach - co mi zase nepůjde či co bude jinak. A opět jsem se nezklamal. Musím udělat tovární nastavení a vše znovu nastavit ( naštěstí ze zálohy) - do BTFRS jsem zatím nešel. Pokud bychom zákazníkovi odevzdávali software v takovémto stavu při každé nové verzi, tak už si neškrtneme už po první verzi. Takže bych preferoval dořešit VŠECHNY stávající problémy a další nové produkty přidávat DÚKLADNĚ OTESTOVANÉ.

2 Likes

Malé vyjádření z mé strany. My si uvědomujeme, že v testování máme stále mezery a jedná se o věc na kterou se silně zaměřujeme. Aktivně sháníme testery, přesněji implementátory testů a na příští rok máme naplánovány projekty které by ke stabilitě měli přispět. Jen jako ochutnávku, již dlouho slibovaný přechod nad lede, dobrovolné zapojení do package survey a v neposlední řadě i nástroj pro kontrolu rozumného nastavení routeru.

Ale objevuje se tu přání, že by jste rádi měli něco jako stabilní build a vývojový kde by přibývali nové featury. Ale něco takového máme, jmenuje se to deploy a nightly. Prosím uvědomte si, že deploy je naše stabilní větev a pokud si přejete aby někdo testoval nové věci i mimo cz.nic (což chceme i my) tak to někdo musí dělat. Z rc 3.9 se ukázalo, že v něm jsou sotva jednotky lidí a kdokoliv kdo má trochu pokročilejší nastavení tam prostě není (nebo problém nenahlásil), protože se nám do deploye dostaly tak velké chyby které mají ale strašně jednoduché opravy. Jen kdyby někdo s tím složitějším setupem byl v tom rc. Takže vy tu možnost máte, ale mám pocit, že k tomu všichni přistupujete jako že on tam dá ten router někdo jiný, já to pak budu mít otestované a bude to super. Je zde na fóru docela dost velká komunita. Vím, že někteří z Vás mají více než jen jeden Turris. Prosím vzchopte se a pokud jste alespoň trochu technicky zdatní tak zkuste rc, pokud máte hlubší zkušenosti tak se nebojte ani nightly, dostanete nové vlastnosti dříve (někdy i o měsíce) a pomůžete nám je otestovat. Shodli jsme se na tom, že nám to prostě moc se stabilitou nejde, tak nám s tím jako komunita pomožte. Je to router nás všech.

2 Likes

ipv6 mi přesně stejným způsoben na předchozí verzi rozbila instalace “Device detection”, což mě vyléčilo ze snahy zkoušet experimentální věci na routeru, který potřebuju aby fungoval :-). Každopádně to vypadalo, že za to může suricata, ale neměl jsem zatím čas to zkoumat podrobněji.

2 Likes

Pokud můžu napsat za sebe, už párkrát jsem RC verzi měl, chyby většinou už objevil někdo přede mnou,
není problém to vyzkoušel, problém je že to zkouším na jediném domácím uzlu a když to zrovna nechodí, je problém.
Mám na to hlavně víkend, jako člověk s normální pracovní dobou víc nestíhám.
Teď je to díky BTRFS jednodušší, ale už mě nebaví poslouchat nářky že u toho furt sedím a stejně to nejde. :slight_smile:
Většina z vás mi asi rozumí.
Proto jsem se ptal už jinde, nejde třeba něco testovat v LXC kontejneru?
Mám Turris 1.0, už mě napadlo mít dvě karty a prohazovat je, jedna s RC verzí jedna stabilní. Ale byl by to asi opruz.
Něslo by mít obě větve na jedné kartě a udělat vždy rollback toho co potřebuji?
Třeba sudé číslo stabilní, liché číslo RC verze?
Jak třeba nahráváte nové verze na router vy všichni v teamu? Musí přece být nějaký rychlý a snadný postup.

Testoval bych fakt rád, protože mě to pořád ještě baví a zajímá.

3 Likes

OK, mám Turris 1.1 pod smlouvou, teď mám 2 týdny dovolené. Budu testovat. Kde najdu rc a nightly, jak ji dostanu do stroje?

To je přesně to co @cynerd asi nechce slyšet… :slight_smile:

https://doc.turris.cz/doc/cs/howto/release_candidate

2 Likes

Každý nahrává trochu jinak, což je dobře, protože se otestuje více cest. Otázka je co chceme testovat. Já většinou testuji nejnovější medkit a update z deploy. Standardně mám router v testovací větvi jen si vytvořím snapshot s medkitem, je jedno jestli z deploy nebo ten který budeme releasovat. To není zase až tak složité. Následně stačí udělat reboot a mám nejnovější systém v čisté podobě. To samozřejmě asi moc nechcete, protože v takovém případě musíte router nastavovat od znova.

Pro otestování včetně konfigurace je vhodnější podle mě udělat jen toto:

schnapps create "pretest"
switch-branch rc

Pokud narazíte na problém tak schnapps list; schnapps rollback $NUM; reboot (NUM samozřejmě podle toho kde uvidíte snapshot pretest). A samozřejmě problém nahlásit. Když nemáte čas na debug tak i to, že se nám ozve několik lidí se stejným problémem stačí na to aby jsme věděli že existuje.

Trochu problém je pokud se nedostanete na ssh, na omnii je možnost udělat rollback tlačítkem, na Turris 1.x ne. Tam se asi vyplatí počítat s tím, že je nutná sériová konzole. Ale mě se osobně nikdy nestalo, že by se router updatem od ssh odstřihl. Ale je pravda, že tu byla situace kdy některé naše skripty kolidovali s uživatelským nastavením dhcp a tak neběžel dhcp server což je trochu nepříjemné (ne neřešitelné, statická ip). No a na Turris 1.x bez btrfs je to už vůbec obtíž. Ale můžete se snad spolehnout na to, že se vrátíte pomocí switch-branch deploy.

2 Likes

Jsem ve stejné situaci. Router stále pod smlouvou a jediná brána do internetu. Když nejede net (=youtube :wink: ), tak si děti docela stěžují :smiley:

Už teď jsem musel dělat instalaci wifi upgrade v noci :sunglasses:

1 Like

V tom vidím největší problém.
U vás se testuje hlavně v čistém systému, což u nás nehrozí a tam je největší zdroj problémů.

To není zcela pravda. Pro nás je nutné aby čistá podoba systému byla funkční, ale nejedná se o jedinou formu, spíše tu co pracovně aktivně dělám já. Dost chyb odhalíme jen tím, že router máme doma. Já například mám Turris Omnia u rodičů s jen vzdáleným přístupem který je v nightly a až na asi dva zádrhely (výpadek dns a nestabilita nas) v něm mám konfiguraci už déle než rok s nulovou údržbou. Spíše jde o to, že nemáme vaše nastavení a tedy vaše nastavení neotestujeme, odhalíme chyby jen vzhledem k tom co máme nastavené my.

Tak nám prosím specifikujte, jakou poiužíváte testovací konfiguraci. Několikrát jsme o specifikaci (včetně mě) žádali a nikdy jsme se žádného dokumentu nedočkali. Na svém routeru budu rád provozovat vaši konfiguraci, protože preferuji stabilitu a bezpečnost. Na “pokročilé” multimediální a ukládácí funkce používám Synology, které provozuji již 4 rok bez jediného problému…

1 Like