abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 01:11 | Nová verze

Byla vydána nová major verze 3.0 svobodného multiplatformního geografického informačního systému QGIS (Wikipedie). Její kódové jméno je Girona, dle názvu města, ve kterém proběhlo 15. setkání vývojářů QGISu. Přehled novinek i s náhledy a animacemi v poznámkách k vydání.

Ladislav Hagara | Komentářů: 0
včera 20:33 | Zajímavý článek

Nadace Raspberry Pi vydala sedmašedesáté číslo (pdf) anglicky psaného časopisu MagPi věnovanému Raspberry Pi a projektům postaveným na tomto jednodeskovém počítači a čtvrté číslo (pdf) časopisu pro kutily HackSpace věnovanému navíc 3D tisku, pájení, řezání nebo i elektronice a IoT.

Ladislav Hagara | Komentářů: 0
včera 18:33 | Komunita

Morevna Project, který stojí za řadou svobodného softwaru pro animátory (např. Synfig Studio, RenderChan nebo Papagayo-NG) a svobodnými (CC-BY-SA) animovanými filmy/komiksy Morevna (3. díl) a Pepper&Carrot: The Potion Contest (6. díl), sbírá do 1. března příspěvky na 4. díl svého animovaného filmu Morevna. Mezi odměnami přispěvatelům lze najít např. i videokurzy animace v Synfigu či Blenderu.

xHire | Komentářů: 0
včera 12:22 | Bezpečnostní upozornění

Ve středu vydaná "npm@next" verze 5.7.0 správce balíčků pro JavaScript npm (Wikipedie, Node Package Manager) přinesla řadě uživatelů Linuxu nečekanou nepříjemnost. V závislosti na způsobu instalace a ve spojení s příkazem sudo mohlo dojít ke změně vlastníka u systémových souborů, také například /. Chyba je opravena v před několika hodinami vydané verzi npm 5.7.1 [reddit].

Ladislav Hagara | Komentářů: 8
včera 10:00 | Nová verze

Byla vydána verze 10.5 open source alternativy GitHubu, tj. softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech, GitLab (Wikipedie). Představení nových vlastností v příspěvku na blogu. Zdůraznit lze integrovanou podporu Let's Encrypt.

Ladislav Hagara | Komentářů: 0
22.2. 12:33 | Komunita

Příspěvek na blogu Signalu (Wikipedie) informuje o založení neziskové nadace Signal Foundation, jež bude zastřešovat další vývoj tohoto svobodného bezpečného komunikátoru běžícího také na Linuxu (Signal Desktop). Brian Acton, spoluzakladatel WhatsAppu, věnoval nadaci 50 milionů dolarů [Hacker News].

Ladislav Hagara | Komentářů: 1
22.2. 05:55 | Zajímavý článek

Článek na Fedora Magazine krátce představuje programovací jazyk Rust a několik zajímavých v Rustu naprogramovaných terminálových aplikací. Jedná se o alternativu k příkazu grep ripgrep, moderní barevnou alternativu k příkazu ls exa, příkazem cloc inspirovaný tokei a zvířátko v terminálu ternimal.

Ladislav Hagara | Komentářů: 0
21.2. 23:55 | Zajímavý projekt

Byl spuštěn Humble Classics Return Bundle. Za vlastní cenu lze koupit hry Broken Sword 5 - The Serpent's Curse, Shadowrun Returns a Shadowrun: Dragonfall - Director's Cut. Při nadprůměrné platbě (aktuálně 8,48 $) také Shadowrun: Hong Kong - Extended Edition, Wasteland 2: Director's Cut - Standard Edition, Age of Wonders III a Xenonauts. Při platbě 15 $ a více lze získat navíc Torment: Tides of Numenera a Dreamfall Chapters: The Final Cut Edition.

Ladislav Hagara | Komentářů: 0
21.2. 00:11 | Bezpečnostní upozornění

Vývojáři linuxové distribuce Mageia na svém blogu upozorňují na narušení bezpečnosti Mageia Identity. Narušitel získal přístup k LDAP databázi a zveřejnil jména uživatelů, jejich emailové adresy a haše hesel. Hesla uživatelů byla resetována.

Ladislav Hagara | Komentářů: 3
20.2. 21:55 | Nová verze

Byla vydána verze 2.0.0 nástroje pro záznam a sdílení terminálových sezení asciinema (GitHub). Z novinek je nutno upozornit na nový zpětně nekompatibilní formát záznamu asciicast v2. S novým formátem si poradí nové verze asciinema-playeru a asciinema-serveru [Hacker News].

Ladislav Hagara | Komentářů: 0
Který webový vyhledávač používáte nejčastěji?
 (2%)
 (28%)
 (62%)
 (3%)
 (3%)
 (0%)
 (1%)
 (1%)
Celkem 439 hlasů
 Komentářů: 35, poslední 21.2. 19:51
    Rozcestník

    Dotaz: Ronja + wifi - jak na to nejlépe?

    1.9.2005 15:16 JirkaK | skóre: 15 | blog:
    Ronja + wifi - jak na to nejlépe?
    Přečteno: 175×
    Dobrý den, spravuji část sítě, v níž se nám nedávno podařilo úspěšně nasadit optický spoj (Ronju) ke stávajícímu wifi spojení. Chtěl bych se zeptat, jak ji nejlépe zaintegrovat do stávajícího systému tak, aby byla využita kapacita obou linek (ronja i wifi současně) a v případě nedostupnosti ronji (ranní mlhy, hustý déšť, sněžení apod.) aby spoj jel pouze přes wifi. Nejdříve jsem to chtěl řešit bondingem, ale dle sdělení kamaráda je lepší použít dynamické routování, což jsem také udělal. Ale jak se ukázalo, není to přesně řešení, jak na to, nebo to dělám špatně. A tak bych rád zkusil již zmíněný bonding. Chci propojit dva routery - v každém jsou mimo jiné dvě rozhraní - v jednom vedou obě ke druhému routeru, v druhém je jedno vyčleněno pro ronju a druhé pro spoj na první router, ovšem visí na něm i klienti sítě. Je možné pro tuto situaci bonding použít? Máte s ním dobré zkušenosti? Případně neřešil již někdo takovouto či podobnou situaci?

    Za odpovědi předem děkuji a přeji hezký den.
    ** Počítač bez window$, to je jako ryba bez bicyklu... ** echo 'Kdo neskáče, není Čech!'|sed s/Čech/cvičená\ opice/

    Odpovědi

    1.9.2005 15:52 Jiří Veselský | skóre: 30 | blog: Jirkovo | Ostrava
    Rozbalit Rozbalit vše Re: Ronja + wifi - jak na to nejlépe?

    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ě.

    1.9.2005 16:03 JirkaK | skóre: 15 | blog:
    Rozbalit Rozbalit vše Re: Ronja + wifi - jak na to nejlépe?
    Děkuji za tak obsáhlou odpověď :). Ta topologie je trošku jiná, než se domníváte - je tu spoj (ronja)-(ronja) a (wifi)-(wifi+klienti), tj. jedno rozhraní na jednom z routerů potřebuji využít jak pro spoj na wifi na druhý router, tak i pro připojení dalších PC. Co se týče bondingu - už před nějakým časem jsem jen tak letmo pročítal dokumentaci ve zdrojácích kernelu - a dočetl jsem se, že bonding (nebo přesněji moduly pro bonding) mají několik módů, ve kterých mohou fungovat... Například využití obou spojů současně, využití jednoho ze spojů a v případě pádu přepnutí na druhý a ještě nějaké další možnosti - takže touto cestou by to snad mělo jít řešit. Nebo se mýlím/s něčím si to pletu? Děkuji.
    ** Počítač bez window$, to je jako ryba bez bicyklu... ** echo 'Kdo neskáče, není Čech!'|sed s/Čech/cvičená\ opice/
    1.9.2005 16:13 Jiří Veselský | skóre: 30 | blog: Jirkovo | Ostrava
    Rozbalit Rozbalit vše Re: Ronja + wifi - jak na to nejlépe?

    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?

    1.9.2005 16:28 JirkaK | skóre: 15 | blog:
    Rozbalit Rozbalit vše Re: Ronja + wifi - jak na to nejlépe?
    Ano, ta topologie je taková, jak jste napsal. Z Vaší odpovědi tedy vyplývá, že to v této situaci nelze udělat...? Ovladač pro bonding by (teoreticky) měl komunikaci pro daná PC posílat pouze na rozhraní, na kterém by viděl ta PC (jejich MAC)... Ale nejspíš budete mít pravdu. Jen je mi divné, že to nelze nějakými rozumnými dostupnými prostředky řešit - zajímalo by mne, jak se tohle řeší například v CZFree a podobných sítích. Nerad bych skončil u nějakého skriptu, který bude linky přepínat dle aktuálního packetlossu :(
    ** Počítač bez window$, to je jako ryba bez bicyklu... ** echo 'Kdo neskáče, není Čech!'|sed s/Čech/cvičená\ opice/
    1.9.2005 16:42 Jiří Veselský | skóre: 30 | blog: Jirkovo | Ostrava
    Rozbalit Rozbalit vše Re: Ronja + wifi - jak na to nejlépe?

    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 :-)

    1.9.2005 17:01 JirkaK | skóre: 15 | blog:
    Rozbalit Rozbalit vše Re: Ronja + wifi - jak na to nejlépe?
    Když myslíte, že by ten skript byl použitelný... :) budu Vám věřit :) Škoda, že nejsem programátor, myslím, že napsáním ovladače "sedícího" na takovéto situace (především ztrátové linky) bych udělal docela zajímavou věc. Každopádně děkuji za Vaše odborné odpovědi a Váš čas.
    ** Počítač bez window$, to je jako ryba bez bicyklu... ** echo 'Kdo neskáče, není Čech!'|sed s/Čech/cvičená\ opice/
    1.9.2005 20:26 Jiří Veselský | skóre: 30 | blog: Jirkovo | Ostrava
    Rozbalit Rozbalit vše Re: Ronja + wifi - jak na to nejlépe?

    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í.

    1.9.2005 21:49 JirkaK | skóre: 15 | blog:
    Rozbalit Rozbalit vše Re: Ronja + wifi - jak na to nejlépe?
    Uvidím, nejspíš vyzkouším ten skript. To, že to je třeba řešit na obou stranách je mi naprostou jasné - co mě napadlo jako první, je (jistě, neprofesionální, ale zcela jistě funkční :) předávat informace např. prostřednictvím apache na jedné straně a wget na druhé nebo si s tím víc pohrát a udělat to přes netcat. Ale s tím zatím bohužel nemám zkušenosti. Když to nepůjde, tak tedy zkusím ten bridge. Každopádně nebojím se psaní skriptů, jen jsem myslel, že to půjde vyřešit tak, jak jsem si představoval, a to na bázi nějakého elegantního řešení :) Snad možná za nějaký ten čas se na to najdou prostředky - vývoj jde stále kupředu, takže třeba budu mít štěstí :)
    ** Počítač bez window$, to je jako ryba bez bicyklu... ** echo 'Kdo neskáče, není Čech!'|sed s/Čech/cvičená\ opice/
    1.9.2005 17:08 Ctirad Feřtr | skóre: 43 | Praha
    Rozbalit Rozbalit vše Re: Ronja + wifi - jak na to nejlépe?
    Bonding v žádném případě nedělat. Nic se tím nezíská, jenom přibudou samé problémy. Ronja je tak o dva řády kvalitnější pojítko než wifi (rychlost, full duplex, latence, PL), takže spojovat to paralelně je nošení dříví do lesa.

    Co se týče výpadků za mlhy, hustého sněžení apod., pokud je ta ronja dostatečně dimenzovaná (nejede to na kilometr a půl nebo i víc), tak ty budou minimální a řešil bych to akorát přepnutím na wifi spoj pomocí ospf nebo nějakýho skriptíku.
    1.9.2005 22:14 vampi | skóre: 16 | blog: JenTakBlog
    Rozbalit Rozbalit vše Re: Ronja + wifi - jak na to nejlépe?
    právě stojíme před stejným rozhodnutím - problém s ronjou a spojením je, že nemusí spadnout úplně - nejdříve začne mít pouze "packet loose" a ten ji při mlze může vydržet :) otázkou tedy je, jak se na podobnou kvalitu linky bude dívat bond - ten mám pocit pozná pouze případ, kdy linka k síťovce je úplně down :)
    určitým řešením je otestovat, při jakém napětí naměřeném na přijímacím modulu ronji je spoj už nepoužitelný a danou linku odpojit od síťovky - pak se totiž bond sám asi po 1-5 vypadlých paketech přepne na druhou linku :) přečti si pořádně dokumentaci k bondutils, jestli ji nemáš, napiš :)
    cesta k dokonalosti je nekonečná - proto hledám jen jednoduchá funkční řešení :)

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.