Pro mě je noční můra mít funční ale děravou síť, to raději ať nefunguje a není zneužitelná.
Teď vážně, automatické aktualizace jsou výchozí stav, můžeš je vypnout. Cílovka jsou domácnosti, malé firmy, kde to dává smysl. Šikovnější správci je mohou vypnout a spravovat sami.
Mimochodem Turris notifikuje před tím než aktualizace naistaluje pár hodin dopředu.
co je to: "pár hodin"? V 10 večer pošle informaci o tom, že v 5 ráno se aktualizuje? Nebo je tato notifikace a čas instalace volitelný? Protože právě zmíněné malé firmy a domácnosti většinou kolem nějaké 17-18:00 hodí za hlavu nějaké maily, i kdyby sebedůležitější a prostě si řeknou: uvidíme ráno. No a ráno mohou taky přijít k nefunkčnímu zařízení, nefunkční síti, prostě ke katastrofě ...
Můžete si vybrat ze tří voleb – automatická aktualizace, odložená aktualizace (kde si zvolíte počet dní, o kolik se má aktualizace odložit), nebo ruční aktualizace.
Problém těchto voleb - nejen u Turrisu, ale obecně v IT systémech je, že dává do ruky lehce ovladatelný prvek, který s sebou přináší těžko předpokladatelné důsledky. Zkratky v lidském mozku nám napovídají, že pokud něco lehce přepnu, tak případný problém napravím zase lehce - např. přepnutím zpět. Dál nepředpokládáte, že se systém dostane do nepoužitelného a nesnadno opravitelného stavu. Počítáte s tím, že aktualizace např. neprojde, ale nezasekne úplně vše.
Takže ano, máte pravdu, uživatel si může zvolit, ale volí mezi volbami, kde se nemůže kvalifikovaně rozhodnout a všechny tři mohou vést ke stejně špatnému výsledku.
To je chyba v koncepci. Napravit ji asi nebude možné, takže jedinou cestou je leda tak maximální edukace uživatele.
Miroslav Šilhavý: Mám jednu připomínku pro autory tohohle robota. Máte připravené texty na několik témat, které se váš robot snaží protlačit, kde to jen jde. OK. Váš robot reaguje na klíčová slova – vidí „aktualizace“, tak přidá komentář o aktualizacích. No, tady už to začíná trochu drhnout, protože řeč byla o tom, kdy se spustí aktualizace, a váš robot do toho vpadl s tématem, zda se aktualizace podaří či nepodaří. Pokud někdo jen prolétne témata komentářů, asi vašeho robota neodhalí – ale pokud si někdo přečte můj komentář i „reakci“ vašeho robota, vidí na první pohled, že ta reakce je mimo.
No a největší problém je v tom, že ten váš robot odkazuje na části z předchozího komentáře (které se týkají jednoho tématu) a na ně přímo ve stejné větě navazuje svým odlišným tématem. Takže pak v jedné větě pomotá dohromady přepínač času instalace (v podstatě kalendář) a to, zda se aktualizace dokončí nebo nedokončí. No a tady už každému dojde, že je to robot, kterému chybí některé základní informace o reálném světě – třeba to, že snadnost, s jakou se přepíná, zda se má aktualizace instalovat dnes nebo zítra, nijak nesouvisí s tím, jak aktualizace dopadne.
Ale jako generátor vtipů je ten váš robot dobrý. Napadají mne další témata, která může váš robot spojit: vypínač stropního světla a provoz atomové elektrárny (obojí souvisí s elektřinou), nebo pojídání koláčů a řízení automobilu (v obou případech se bere do ruky něco kulatého).
To je chyba v koncepci.
Ne, to je chyba mezi židlí a klávesnicí. Nepochopil jste, k čemu ta volba slouží.
Velmi nás mrzí, že k tomuto problému došlo i přes veškeré intenzivní testování se nám tuto chybu nepodařilo zachytit dříve a během testování s komunitou nám tento problém nebyl nahlášen a dokonce tato verze byla dlouhou dobu v RC, ale to je možné si vše zjistit na komunitním fóru Turris.
Rád bych Vás požádal, abyste nám napsal na technickou podporu a postupoval podle článku Getting help, kde to společně s Vámi dořešíme.
Dakujem, ale kedze som bol v situacii, kde som to musel vyriesit rychlo a necakat X dni kym podpora na nieco pride, tak nasledoval `schnapps rollback`, reboot a zakaz updatov. Zatial neviem, ako budem riesit updaty v buducnosti.
Ide o kus z indiegogo kampane, Classic + RAM upgrade, ak to niecomu pomoze.
To mas jeste dobry, mne se, pravda mnou vynucenym, upgradem nejprve nainstalovala verze curlu, ktera zavisela na knihovnach ktere jeste stahle nebyly(?) a na jejich stazeni je potreba mit funkcni curl. Mozna nebyly nainstalovane, ale curl (a sshd a cokoliv co zaviselo na libssl a libcrypto, proste na balicku libopenssl) v tu chvili funkcni nebyl a bez nej to nepokracovalo. Nastal zasek kvuli knot-host(resp. knot-libs) a dal uz to rozebehnout neslo, protoze nebyl curl.
Proste si to podrezalo vetev.
Ted to mam snad ve stavu spravnem, ale buhvi jestli je to pravda. Mam chut to cely prejet medkitem (proste instalace od cista), ale kdyz si vzpomenu jaky porod byla obnova ze zalohy (zaloha sice drzi konfiguraci, ale uz ne co je a co neni nainstalovane - proste nahrani medkitu + obnova ze zalohy se nerovna funkcni router), tak se do toho moc nehrnu.
7. 6. 2020, 13:45 editováno autorem komentáře
Ale vy jste použil migraci z verze Turris OS 3.x na Turris OS 5.x, která byla určená pouze pro pokročilé uživatele a u které se počítalo s některými případnými problémy. Ve vlákně s migrací si, prosím, všimněte: "Please be aware that this is still experimental and problems might be present. You
should read the documentation in its fullest before you attempt migration."
7. 6. 2020, 15:58 editováno autorem komentáře
Vsak jo, proto rikam ze aktualizace byla vynucena mnou.
Tohle byl jen postreh ze se to umi zazdit uprostred aktualizace na veci, ktere by to melo odchytit uz u “prerequsities”.
Ja muzu na druhou stranu argumentovat tim ze kdyz uvedete changelog prakticky odprostredka (no, spis ke konci), tak “problems might be present” by se melo vylozit spis jako ruska ruleta s peti kulkami :-)
7. 6. 2020, 23:33 editováno autorem komentáře
Himl hergot uz ani neumim psat - "prerequisites" (nechci to brat jako preanglictenost, spis jako terminus technicus toho co se pred hlavnim upgradem obvykle deje).
Jako cekal jsem toho dost, ale spis neco na urovni toho ze se treba nezaktualizovaly (nezmodernizovaly) konfigurace u LXC kontejneru. Ale tohle bylo fakt doslovny podrezani vetve. Jeste ze to ma ty snapshoty (na ktery jsem si vlastni vinou ani nevzpomnel, to mne nekdo nakopnul na foru)
Uz jsem to nejak rozdejchal, ale dneska fakt byly chvile kdy jsem penil a plival jedovaty sliny (napr u zjisteni ze nastavovani interniho switche muzu udelat papa a ze ted muzu bejt rad, ze eth1 jsou lan0-3 a eth0 je lan4 natvrdo).
Ale at nejsem jen negativista, prohozeni puvodne WANkovyho eth1 za LANkovy eth2 proslo tak hladce ze jsem si toho nejprve ani nevsiml.
Váš první příspěvek neříká bohužel nic o experimentální migraci, ale pouze o vynuceném upgradu. Vynucený upgrade může také znamenat ruční spuštění Updateru z příkazové řádky. Takže je poměrně zavádějící a proto jsem uvedl věci na pravou míru. Slovíčkařit, případně řešit různé postřehy pod zprávičkou není vhodný nápad a řešit ho tady ani nebudeme. Od toho je zaslání e-mailu na technickou podporu, případně založení issue do repozitáře na Gitlabu jestli jste vývojář nebo fórum Turrisu, kde můžete diskutovat s komunitou.
Vsak jo, proto rikam ze aktualizace byla vynucena mnou.
Tohle byl jen postreh ze se to umi zazdit uprostred aktualizace na veci, ktere by to melo odchytit uz u “prerequsities”.
To by bylo moc hezké, ale bohužel to není tak snadné. Verze updateru jsou rozdílné a je nutné prvně aktualizovat updater a s ním i všechny závislosti. Teprve nová verze updateru je schopná plně číst skripty z Turris OS 5.0 a tedy zkontrolovat závislosti. Updater je při migraci nastaven tak aby ignoroval požadavky na balíčky které nejsou k dispozici, jenže toto je balíček který je k dispozici a chybí jeho závislost. To je něco s čím migrace nepočítala. Přesně proto je řečeno zde https://forum.turris.cz/t/optional-migration-from-turris-os-3-x-for-advanced-users, že migrace je experimentální a že mohou nastat problémy.
Apropo, byla by nekde dokumentace ktera se zminuje treba o knot-libs nebo swconfig?
Ja jen ze nedusledna, roztristena nebo dokonce kolizni dokumentace neni uzitecna nikomu. Berte to jako pripominku (kterou teda bohuzel osobne znam az moc dobre, clovek je vyvojem tak napred, ze zapomina ze nektere veci pro ostatni samozrejme nejsou a je treba je do dokumentace doplnit).
8. 6. 2020, 00:00 editováno autorem komentáře
Turris Mox s 0,5 GB RAM je bohuzel nefunkcni kram, do 2-3 dnu zkolabuje na problemu s nedostatkem RAMky. Az po upgradu na 1 GB RAM se da mluvit o jakemsi funkcnim reseni. Bohuzel, ma spoustu dalsich potizi, kterymi starsi turrisy (modraky) netrpely a takovy modrak umi dodnes spoustu veci, na ktere MOX nemuze ani pomyslet....
Treba stale nefunguji pri zaplych wifinach rebooty z prikazoveho radku.... kdyz se ale obe wifi karty vypnou, reboot to umi... dodnes to nikdo neumi z turris teamu vyresit.
Nebo treba si domaci a pro hosty pro modraka neni problem a MOX to dodnes neumi...
OpenVPN totez. Na modrakovi funguje krasne, na MOXovi ani tuk...
Je s podivem, ze se tato nefunkcni verze "Classic" jeste stale s 0,5 GB RAM prodava (treba CZC, AMAZON) - pritom je jasne, ze to fungovat nebude... asi hosi z turris teamu testuji s 1GB RAM a na tohle vec jeste neprisli, nebo si to nedokazu vysvetlit, jak to muze nastat....
Skoda, myslenka dobra, provedeni bohuzel naprosto pokulhava....
Ano, pokud jsem měl Mox čistě v módu router a bez wifiny , tam mu 0,5 GB RAM stačilo, dokonce i rebootoval.... jak jsem zapnul wifi (obě), tak tentýž Mox přestal rebootovat a vždy mi nejpozději do 3 dnů zkolaboval.... dle logu na out of memory právě ve chvíli, kdy se pokusil kontatovat repozitář, zdali nejsou nějaké aktualizace.... verze OS 4.x nebo 5.x, totožné chování.
Jak mám 1 GB RAM na desce A, je to OK a běží stabilně. Tedy soudím, že 0,5 GB RAM je prostě málo, někdo ušetřil na nepravém místě. Původní modrák měl 2 GB RAM, Omnie tuším 1-2 GB RAM, tak nevím, koho tam napadlo (asi ty úsporné důvody) tam dát 512 MB RAM ?
Je to samozřejmě Váš názor, ale divil byste se. Viděl jsem i to, že Turris MOX s 512 MB RAM běžel 2 měsíce v kuse pak došlo ze strany uživatele k restartu zařízení. Pokud-li by zkolaboval do 2-3 dnů jak píšete, tak na fóru Turris by byly vytvořené příspěvky o tom, že ano? Někteří uživatelé jsou názoru, že přece 512 MB RAM je dostačující, aby na tom běžela Suricata a LXC kontejnery zároveň a v jiném případě nainstalují Home Assistant, který vyžaduje minimálně 1 GB RAM dle jejich požadavků v dokumentaci. V tom případě se ale není divit, že systém zavolá OOM killera.
Co se týče problémů ohledně guestovské Wi-Fi sítě, tak když se podíváte na odkaz, který je ve zprávičce a hned na první příspěvek ve vlákně, kde jsou napsané known bugs. Tak zjistíte, že vývojáři Turrisu na tom usilovně pracují ať už v hostapd a také v ovladači mwifiex v kernelu. V některých případech se Turris MOX správně nerestartuje i tohle se řeší s výrobcem SoC.
Dobrý den, chtěl jsem od MOXe jen stejnou funkcionalitu, jakou mám na modrákovi - už jen z důvodu novějšího OS 5.x, který je pro modráka zatím experimentální.
Nemám tu nic exotického, ale i těchto pár věcí - které léta na modrákovi fungují, jsou pro MOX bohužel problém :
- OpenVPN - na modrákovi léta funguje, totožná konfigurace na MOXovi bohužel nechodí (ani žádná jiná)
- po aktualizaci OS není možné provést u MOXe restart "reboot" - vytuhne a je nutné přijít k zásuvce, fyzicky vytáhnout ze zásuvky napětí a zase zapnout... modrák to nedělá
- wifi pro hosty - modrák funguje, MOX dodnes bohužel neumí
- past na roboty HAAS - na MOXovi naběhne, po pár hodinách spadne a už nejde bez restartu nahodit (restart ale nechodí, dle podpory se služba "sama po čase nehodí" - nenahodí, bez restartu to nechodí, ale restart nejde bez mé fyzické přítomnosti provést - viz bod výše)
Není bez zajímavosti, že když se vypnou obě WIFI karty, najednou mu stačí i těch 0,5 GB RAMky a dokonce funguje i reboot.... ale jak se wifi karty zase zapnou, bohužel 0,5 GB RAM je málo a paradoxně to kolabuje, když se to pokusí stáhnout aktualizace z repozitářů na "out of memory". Soudím tedy, že navrhnout takovýto router s 0,5 GB RAM je málo a divím se, že se třeba tohle prodává. Asi chtěl někdo ušetřit na nesprávném místě a kdo si to koupí a bude očekávat fukcionalitu jako já, bude zklamán.
Neprovozuji žádné další home řešení, NAS, LXC apod. Přesto je evidentně 0,5 GB RAM málo.
Dle mého místo toho, aby jste už min. půl roku řešili nefunkční restarty nebo nefunkční síť pro hosty, programujete ReForis (který není úplně nutný, starý Foris funguje OK).
Škoda, mám turris rád, ale ... někdo bohužel ušetřil na nesprávném místě a na trhu je bohužel kvůli problematické 0,5 GB RAM nedodělek.
Já bych to zase tolik nekritizoval. Skutečně je mnoho možností, jak update provádět - to, že má někdo nastavený automatický update, to je jeho vlastní blbost (já jsem na toto přišel velmi brzy a možnost schvalování jsem velice uvítal - tuším od nějaké verze 3.x) - pokud to máte na důležitém místě a máte nastavené automatické aktualizace, tak nekritizujte Turris tým, ale zamyslete se sami nad sebou (to je slušně řečené) ... První verze btw. nikdy u nikoho není 100% OK ...
Já osobně jsem s Omnií (u mě doma) a 1.0 u rodičů prodělal pár "infarktů" v minulosti, kdy najednou po x dnech něco přestalo fungovat, vždy se to podařilo nějak vyřešit. Momentálně Omnii používám jen jako NAS (vlastně jsem povolil jen NTP komunikaci a update zkusím po povolení komunikace cca 1x týdně, byl jsem v HBT, takže updaty chodily) a síťové věci jsem si začal řešit na Checkpointu a DNS přes pihole a jsem spokojený jako nikdy.
Nicméně si myslím, že verze 5.0 je jeden z největších posunů za celou tu dobu, co je venku nejen Omnia. Jasně x věcí přestala fungovat - různé statistiky v luci, na několik bodů z Indiegogo kampaně se stále u Omnie čeká, ale 5.0 je konečně dobrý výchozí bod, na kterém snad bude možné stavět do budoucna. Dost mi to připomíná problémy Androidu, kde si každý výrobce bastlí to svoje a bitý je tím jenom zákazník, který má třeba na telefon za 30k podporu jen 2 roky, což je otřesné! U Turrisu to bylo dost podobné (jen podpora je mnohem delší, ale zase to řešili jen oni v omezené kapacitě) - "bastlili" si svoje openwrt, a to se nyní nekoná, došlo k redesignu toho systému a vlastně je to čisté openwrt s "nadstavbou" pro jejich HW, a to je dost zásadní změna. Takže bude v budoucnu možné mít rychleji aktuálnější verzi openwrt se všemi jeho vlastnostmi - balíčky atd. Taky se tím "spojením" může více zapojit komunita openwrt. Vznikne snad tak i prostor pro nové vychytávky, ale to jsem asi naivní.
Na závěr jen doufejme, že je komunita openwrt natolik soudržná a silná, v minulosti tam byly nějaké hádky.
Hotovo, vyreseno - router jsem nastavil do tovarniho nastaveni podle navodu - sice peklo (sledovat diodu a zaroven spendlikem mackat tlacitko na opacne strane routeru), ale nakonec se zadarilo :) Jedu na TurrisOS 4.0-beta1 :)
Navod: https://doc.turris.cz/doc/cs/howto/mox_rescue_modes
O vikendu jsem aktualizoval Turris MOX, vzhledem k tomu, ze jsem mel upozorneni na nove aktualizace ve Foris. No... Dopadlo to, jak to dopadlo. Router jsem stejne menil za pfSense, takze me nevadilo, ze po aktualizaci router nenabehl do funkcniho stavu (dal jsem na to nemel cas se v tom vrtat). Ovsem budu s nim mit ted praci, abych ho zase rozchodil.
Ac Turris celkove mam rad (mel jsem i Omnii), tak podobne veci me dost mrzi. Protoze to dost snizuje pouzitelnost routeru v mistech, kde bych chtel minimum starosti. Jen bych dodal, ze na Mox nebezelo nic extra, jen Wifi a routovani - vse nastavene na zacatku wizardem. I tak se to rozbilo, skoda...