OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
sudo-rs, tj. sudo a su přepsáné do programovacího jazyka Rust, nahradí v Ubuntu 25.10 klasické sudo. V plánu je také přechod od klasických coreutils k uutils coreutils napsaných v Rustu.
Fedora se stala oficiální distribucí WSL (Windows Subsystem for Linux).
Společnost IBM představila server IBM LinuxONE Emperor 5 poháněný procesorem IBM Telum II.
Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
kernel: [22221.120869] ADDRCONF(NETDEV_CHANGE): tap0: link becomes ready kernel: [22221.120930] br0: port 2(tap0) entering forwarding state kernel: [22221.120940] br0: port 2(tap0) entering forwarding state kernel: [22221.123169] br0: port 2(tap0) entering forwarding state kernel: [22221.123405] br0: port 2(tap0) entering disabled state
br0 bridge id 8000.60eb692c7e94 designated root 8000.60eb692c7e94 root port 0 path cost 0 max age 20.00 bridge max age 20.00 hello time 2.00 bridge hello time 2.00 forward delay 0.00 bridge forward delay 0.00 ageing time 300.01 hello timer 0.96 tcn timer 0.00 topology change timer 0.00 gc timer 30.00 flags eth0 (1) port id 8001 state forwarding designated root 8000.60eb692c7e94 path cost 4 designated bridge 8000.60eb692c7e94 message age timer 0.00 designated port 8001 forward delay timer 0.00 designated cost 0 hold timer 0.00 flags tap0 (2) port id 8002 state disabled designated root 8000.60eb692c7e94 path cost 100 designated bridge 8000.60eb692c7e94 message age timer 0.00 designated port 8002 forward delay timer 0.00 designated cost 0 hold timer 0.00 flags tap1 (3) port id 8003 state disabled designated root 8000.60eb692c7e94 path cost 100 designated bridge 8000.60eb692c7e94 message age timer 0.00 designated port 8003 forward delay timer 0.00 designated cost 0 hold timer 0.00 flags
bridge name bridge id STP enabled interfaces br0 8000.60eb692c7e94 no eth0 tap0 tap1cely most by mel byt smerovan do internetu pomoci eth0, neni dulezite jake dalsi virtualni rozhrani budou uvnitr, prozatim jde o funkcnost. jedina ma domenka prozatim je, ze na konci tap0 a tap1 chybi nejake "pripojene zarizeni", kdyz jsem odpojil kabel od eth0, port eth0 v bridgi se taktez dostal do stavu disabled. budu vdecny za jakekoliv rady, ikdyby se melo jednat o programovani nejake c aplikace, ktera by mela simulovat zarizeni na konci.
Jestli to správně chápu, mají spolu komunikovat virtuální stroje na různých fyzických strojích, jako by byly na jednom ethernetovém switchi. To znamená, že je potřeba umět tunelovat vrstvu 2 skrz vrstvu 3. To znamená, že se dá použít gretap
.
Otázka je, jestli je opravdu nutné mít pro všechny virtuální stroje jeden virtuální switch a jestli by se komunikace nedala zajistit například běžným IP routingem. Řešení s gretap
je výhodné pro případ, že mají fyzické stroje tvořit cloud a tedy podporovat migraci virtuálních strojů za provozu, která zachová konfiguraci sítě a dokonce i TCP spojení, protože migrovaný virtuální stroj je v podstatě stále připojený k témuž ethernetovému switchi. Pokud ale prostředí live migraci nepodporuje nebo nepotřebuje, routing je skoro vždy lepší nápad.
Pak může být řešení celkem triviální.
První (a podle mě lepší možnost) je routování. Virtuální síť bude mít nějaký prefix adres a fyzický stroj musí být v okolní síti (v celé síti, tedy včetně nějakého modemu či přístupového bodu) známý jako router do tohoto prefixu. (Prefix by neměl být podmnožinou adres normálně používaných v domácí síti; měl by se zkrátka lišit, aby bylo jasné, kudy se routuje.)
Druhá možnost je mít adresy ve virtuální síti se stejným prefixem jako ve zbytku domácí sítě. Pak se musí do bridge, který propojuje všechna virtuální rozhraní, přidat ještě i fyzické rozhraní. Fyzickým strojům na síti se pak virtuální stroje budou jevit jako na lokálním switchi, tj. komunikace s nimi bude založená na 2. vrstvě, ne na 3. vrstvě, narozdíl od routování.
Třetí možnost je podobná té první, ale v lecčem trochu horší a odpovídá nastavení, které vytvářejí automaticky virtualizační frameworky typu virt-manager + libvirt. Zaprvé většinou podporují jenom IPv4, což je samo o sobě hodně hloupé, ale zadruhé nastavují virtuální podsíť jako NAT. Pak fyzický stroj slouží jako NAT router. To znamená, že virtuální stroje se mohou připojovat do Internetu téměř neomezeně (až na to, že prostě nebudou moct používat protokoly, které nejsou založené na TCP ani UDP), zatímco přímé spojení zvenku (tedy mimo fyzický server) do virtuálních strojů není možné. (Je to zkrátka NAT — co víc k tomu dodat.)
Klíčové je nezapomenout nastavit některé detaily v sysctl — například nezapomenout povolit routování (packet forwarding), v případě bridge zkusit na něm pro jistotu povolit STP a tak podobně. No a pak je taky třeba přidělovat IP adresy správným rozhraním, tj. například pokud fyzický stroj funguje jako bridge, jeho IP adresy se nastavují na bridge rozhraní, nikoliv na některých „členech“ toho bridge.
Mimochodem, stačí si přece nainstalovat libvirt a virt-manager. Tam je automaticky nastavená a zprovozněná síť a virtuální stroje se můžou připojovat k Internetu, má-li fyzický stroj správně nastavený přístup a povolený packet forwarding. Taková možnost se pak dá snadno rozšířit drobnou úpravou iptables pravidel tak, aby (například) požadavky do Internetu mimo domácí sít šly přes NAT, zatímco požadavky směrované do domácí sítě a zpátky z domácí sítě by se naprosto normálně routovaly. Stačí jen příslušné příslušné pravidlo typu SNAT trochu tweaknout, aby fungovalo jen pro některé odesilatele a příjemce.
U všech tří řešení se občas stávají nějaké velmi dobře známé chyby, které je třeba prověřit — zakázaný packet forwarding, špatně nastavené prefixy (takže stroje nevědí, že je třeba routovat, a hledají protějšky na lokálním switchi), špatně nastavený bridge (zakázaný STP a několik mostů v dosahu, IP adresy nastavené na rozhraních v bridgi, ale ne na bridgi samotném), špatně použitý IPv4 NAT (buď v kombinaci s nekompatibilními dalšími pravidly firewallu, která všechno zablokují, nebo se zkrátka NATuje úplně všechno, včetně komunikace, která má směřovat do lokální sítě) a konečně všechny možné typy softwarových firewallů, které vyrobí tak složité nastavení iptables, že se v tom nedá vyznat a půlka sítě pak nefunguje. Posledně jmenovaný problém zpočátku není vůbec poznat, protože pro běžné služby typu web, Jabber nebo SSH se zdá být vše v pořádku.
Základem asi bude spustit si na fyzickém stroji tcpdump
a podívat se, jaké pakety tam chodí a proč se asi ztrácejí. Třeba bude jenom někde špatně nastavený default gateway a tak podobně.
Když narazím na problémy tohoto typu, ještě rychlejším řešením než experimenty s tcpdump
leckdy bývá IPv6 — ten velmi rychle odhalí, zda se jedná o problém s NATem (který u něj zatím naštěstí nikdo a nic implicitně nezapíná) nebo s nesprávně nastavenými délkami prefixů (proti čemuž je IPv6 mnohem odolnější, protože nemá žádnou „broadcast“ adresu a NDP funguje i mezi stroji s různými nastaveními délek prefixů, pokud se prefixy shodují až do konce toho delšího) a tak dále. Pokud ani IPv6 nefunguje, dojde na tcpdump
.
Takže tolik tipy pro diagnostiku.
Maximální zatížení CPU může znamenat, že je tam cyklus, ať už mezi routery, mezi mosty, nebo nějakou záhadnou kombinací obojího. Má bridge zapnutý STP? Jsou interfacy v bridge spojené ještě jinou cestou? Problém se záplavou paketů může nastat při vypnutém STP, pokud existuje cyklus mezi mosty.
Tiskni
Sdílej: