Prázdniny jsou v plném proudu a jeden by si skoro řekl, že už těch výletů a sluníčka je až příliš mnoho. Nezoufejte však, i proto je tu po měsíci opět Virtuální Batlírna. S projektem MacGyver studentského klubu SiliconHill si můžete v příjemném virtuálním prostředí videokonference Zoom popovídat o aktualitách v elektronice nebo o rozličných technických problémech. A to všechno bez rizika spálení na slunci či poštípání dotěrným hmyzem.
… více »Po třinácti měsících od vydání verze R1/beta2 byla vydána verze R1/beta3 operačního systému Haiku (Wikipedie). Přehled novinek v poznámkách k vydání. Přispělo 87 vývojářů s 1 248 commity. Vyřešeno bylo více než 251 chyb a žádostí o vylepšení.
Rakudo (Wikipedie), tj. překladač programovacího jazyka Raku (Wikipedie), byl vydán ve verzi 2021.07. Programovací jazyk Raku byl ještě nedávno znám pod názvem Perl 6.
V únoru byl představen modulární notebook Framework Laptop, který je možné "libovolně" konfigurovat, upgradovat a opravovat. V květnu byl spuštěn jeho předprodej. První várka notebooků byla již odeslána. Publikovány jsou první nezávislé recenze. Viz například rozborka z sborka na YouTube kanálu iFixit.
Projekt BLAKE3, tj. oficiální implementace kryptografické hašovací funkce BLAKE3 v programovacích jazycích Rust a C, dospěl do verze 1.0.0.
Populární open-source e-mailový klient pro Android K-9 Mail dostal po bezmála třech letech nové stabilní vydání 5.800 s přepracovaným uživatelským rozhraním.
Vydání Debianu 11 s kódovým jménem Bullseye je naplánováno na sobotu 14. srpna.
Google Chrome 92, konkrétně verze 92.0.4515.107, byl v úterý prohlášen za stabilní. Opraveno bylo 35 bezpečnostních chyb. Pete LePage doteď nepublikoval oficiální přehled novinek (New in Chrome, YouTube). Publikován byl jenom seznam novinek v nástrojích pro vývojáře (YouTube). Sundar Pichai dnes na Twitteru oznámil vylepšení integrované hry chrome://dino/.
Firewall firewalld (Wikipedie, GitHub) dospěl do verze 1.0.0. Upozornit je nutno na nekompatibilní změny. Zrušena byla podpora Pythonu 2.
Milí priatelia Mozilly, tím Mozilla.sk hľadá pomoc v radoch dobrovoľníkov, ktorí sú ochotní pomáhať nám s týmto projektom. Vítaná je akákoľvek pomoc, no aktuálne hľadáme hlavne ľudí, ktorí by sa starali o aktuálnosť lokalizovaných článkov na stránkach podpory SUMO. Projekt je doteraz veľmi sviežo udržiavaný, no naše kapacity prekročili všetky limity a už nestíhame. Ak sa nám v najbližšej dobe nepodarí rozšíriť tím, bude nutné zo stránok
… více »Trochu jsem se ztratil v tom, jak máte ty routery a rozhraní. Takže by to mělo být takto: máte dvě lokality, A a B. Mezi těmito lokalitami máte vybudovány dva spoje - jeden na Ronji a druhý na wifi. Na každé z těch lokalit musíte mít router se dvěmi vyčleněnými síťovkami. Do jedné z nich bude zapnuta Ronja, do druhé z nich wifina. A teď, co se vám nabízí:
Bonding - na každé straně ona dvě rozhraní "sbondujete" do jednoho virtuálního (na něm nastavujete IP a takové ty věci), bonding vám zajistí distribuci zatížení přes obě fyzická rozhraní. (Část tedy poteče přes Ronju, část přes wifi.)
Vlastnosti: Provoz se vám bude rozdělovat na oba spoje, ale neumí se v případě výpadku jednoho spoje překlopit plně na ten druhý. Ronja a wifi mají navíc jiné přenosové rychlosti, takže při (ideální) distribuci zátěže 1:1 ty spoje nebudou využity stejně z hlediska percentuálního naplnění své kapacity. Zatížení se navíc nerozloží 1:1, ale rozloží se podle dvojic SRC/DST MAC adres (každá dvojice si jednou provždy zvolí "svou" trasu) - může se vám tedy stát, že jeden spoj bude zatěžován hodně, druhý málo.
STP - Spanning Tree Protocol - na každé straně spojíte ona dvě rozhraní do bridge, zapnete na něm STP (a nastavíte IP). Protokol se "rozhodne" (samozřejmě ho můžete ovlivnit) a jeden ze spojů použije jako hlavní, druhý jako záložní v případě, že první zdechne.
Vlastnosti: Nebude docházet k distribuci zátěže, provoz pojede vždy jen jednou ze dvou možných tras. Jde o velmi robustní a rychlé řešení, v případě výpadku se vám provoz překlopí v řádu jednotek vteřin.
Dynamický routing - Každé z obou rozhraní bude mít své IP adresy a provoz půjde tím nebo oním na základě rozhodnutí routovacího protokolu.
Vlastnosti: Jde nastavit částečný load-balancing mezi obě trasy s možností fail-over překlopení na jedinou živou trasu, řešení je tedy nejuniverzálnější. Nastavení ovšem vůbec není triviální (na rozdíl od předchozích dvou možností), musíte o tom poměrně dost vědět. Navíc to může (podle topologie sítě) vyžadovat i nastavení na jiných routerech. Jako jediné řešení z uvedených tří navíc striktně nevyžaduje "plnou paralelnost" obou tras.
Vybrat si musíte sám, já osobně bych (podle možností) preferoval STP. (Dynamický routing mi v tomto případě přijde příliš komplikovaná věc, bonding se principiálně nehodí, protože neumí fail-over.
PS: Vzhledem k tomu, že Ronja i wifi jsou "pseudospoje", mohou vznikat poměrně tristní problémy. Jak STP tak dynamické routovací protokoly se obecně rozhodují podle toho, zda linka "jede nebo nejede". Situaci, kdy linka "jede blbě" (ve smyslu velké procento ztrát) prostě neumějí řešit a mohou se rozhodovat poměrně zmateně, může vám to celé začít flapovat (provoz se bude neustále překlápět mezi dvěma blbě jedoucíma trasama) a podobně.
Je pravda, že je to dost dávno, co jsem něco ohledně bondingu potřeboval, takže nevylučuju, že tam existuje možnost jak distribuovat zátěž, tak i automatické přepnutí při výpadku jedné linky.
Každopádně ale, bonding je mechanismus druhé síťové vrstvy, nad kterým vzniká virtuální rozhraní, na němž teprve nastavujete vyšší vrstvy. Pořád ještě nechápu tu vaši topologii (obrázek?), ale principiálně nejspíš nebude možné, aby "jedno ze dvou rozhraní" (mezi nimiž se ten bonding nějak rozhoduje) plnilo "něco navíc" než to druhé.
Řeknu to takto: předpokládám, že na té "složitější" straně onoho dvouspojí máte do jedné síťovky ronju, do druhé switch a v něm wifi plus nějaká ta PC. Když budete chtít bondovaným rozhraním něco odeslat, bonding sám se rozhodne, zda to pošle tou či onou síťovkou. Jak ho donutíte, aby provoz pro ona PC posílal vždy jen tou jednou?
Příliš bych nedůvěřoval tomu, že bonding "něco vidí". To je jenom tupý přehazovač paketů: Máte (řekněme) eth0 a eth1 sbondované do bond0. Jakmile odesíláte přes bond0 paket, bonding to nějakým svým vnitřním mechanismem rozhodí buď na eth0 nebo eth1. Typicky ten mechanismus funguje tak, že se zahashuje zdrojová a cílová MAC adresa a podle výsledku (sudý/lichý, řekněme) se to pošle tudy či jinudy. Tím se zajistí, že mezi dvěma fyzickými stanicemi jde provoz vždy stejnou linkou (a rámce tak nemění pořadí). Může do toho vstoupit nějaká váha těch rozhraní, může do toho vstoupit to, že jedno rozhraní je "down", ale nemyslím, že byste dokázal natvrdo bonding přimět, aby provoz pro danou množinu MAC adres posílal vždy jen jedním určitým rozhraním. Netvrdím, že je to nemožné (minimálně byste si to tam mohl doprogramovat), ale myslím si, že to (ve stávající podobě) spíš nejde.
CZFree, pokud vím, používá OSPF (tedy dynamický routing). Předpokládám, že vhodným vyladěním časovacích parametrů jde routovací protokol donutit k nějakému stabilnímu chování i na ztrátujících linkách, ale to už jenom spekuluju.
Mimochodem, ten skript, o kterém mluvíte, by vám možná prokázal úplně nejlepší službu 
No, upřímně řečeno, k vytváření takového skriptu vás nenavádím. Ono to sice vypadá jednoduše, ale jenom na první pohled. Samozřejmě není problém nějak detekovat, že linka č. 1 blbne a - co teď. Překlopit provoz na linku č. 2, že? Ale jak? Shodit první rozhraní, přehodit IPčko na druhé? Přeroutovat to přes (jiné IP) druhého rozhraní? Problém je v tom, že stejně by měla reagovat i druhá strana spoje! Pokud to totiž neudělá, tak (v prvním případě) vám to přestane jet úplně, ve druhém se vám to začne routovat asymetricky, což může a nemusí působit další problémy. A jak donutit obě strany spoje, aby reagovaly synchronně, to je docela ořech... A vracet to pak zpátky na první spoj, no... Prostě, žádná sranda.
Proto existují takové věci, jako je dynamický routing nebo STP, které to řeší poměrně sofistikovaně.
Každopádně, ve vašem případě bych se vzdal distribuce zátěže přes obě trasy (jak už tady padlo, kvalita Ronji a wifi je přeci jen trochu jinde, takže wifi bych použil skutečně jako zálohu pro případ nouze). A pak bych nasadil STP - to je triviální. Dynamický routing je v této situaci kanón na vrabce. A dokonce, STP můžete použít i ve vaší situaci, tj. máte-li v jednom rozhraní jak wifi, tak další PC. Akorát ten switch, v němž je to zapojeno, musí taky podporovat STP. Anebo překopejte topologii, to je varianta B. Pořád je to nejspolehlivější řešení.
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz