Balík nástrojů Rust Coreutils / uutils coreutils, tj. nástrojů z GNU Coreutils napsaných v programovacím jazyce Rust, byl vydán ve verzi 0.3.0. Z 634 testů kompatibility Rust Coreutils s GNU Coreutils bylo úspěšných 532, tj. 83,91 %. V Ubuntu 25.10 se již používá Rust Coreutils místo GNU Coreutils, což může přinášet problémy, viz například nefunkční automatická aktualizace.
Od 3. listopadu 2025 budou muset nová rozšíření Firefoxu specifikovat, zda shromažďují nebo sdílejí osobní údaje. Po všech rozšířeních to bude vyžadováno někdy v první polovině roku 2026. Tyto informace se zobrazí uživateli, když začne instalovat rozšíření, spolu s veškerými oprávněními, která rozšíření požaduje.
Jste nuceni pracovat s Linuxem? Chybí vám pohodlí, které vám poskytoval Microsoft, když vás špehoval a sledoval všechno, co děláte? Nebojte se. Recall for Linux vám vrátí všechny skvělé funkce Windows Recall, které vám chyběly.
Společnost Fre(i)e Software oznámila, že má budget na práci na Debianu pro tablety s cílem jeho vyžívání pro vzdělávací účely. Jako uživatelské prostředí bude použito Lomiri.
Proběhla hackerská soutěž Pwn2Own Ireland 2025. Celkově bylo vyplaceno 1 024 750 dolarů za 73 unikátních zranitelností nultého dne (0-day). Vítězný Summoning Team si odnesl 187 500 dolarů. Shrnutí po jednotlivých dnech na blogu Zero Day Initiative (1. den, 2. den a 3. den) a na YouTube.
Byl publikován říjnový přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Pracuje se na podpoře M3. Zanedlouho vyjde Fedora Asahi Remix 43. Vývojáře lze podpořit na Open Collective a GitHub Sponsors.
Iniciativa Open Device Partnership (ODP) nedávno představila projekt Patina. Jedná se o implementaci UEFI firmwaru v Rustu. Vývoj probíhá na GitHubu. Zdrojové kódy jsou k dispozici pod licencí Apache 2.0. Nejnovější verze Patiny je 13.0.0.
Obrovská poptávka po plynových turbínách zapříčinila, že datová centra začala používat v generátorech dodávajících energii pro provoz AI staré dobré proudové letecké motory, konvertované na plyn. Jejich výhodou je, že jsou menší, lehčí a lépe udržovatelné než jejich průmyslové protějšky. Proto jsou ideální pro dočasné nebo mobilní použití.
Typst byl vydán ve verzi 0.14. Jedná se o rozšiřitelný značkovací jazyk a překladač pro vytváření dokumentů včetně odborných textů s matematickými vzorci, diagramy či bibliografií.
Specialisté společnosti ESET zaznamenali útočnou kampaň, která cílí na uživatele a uživatelky v Česku a na Slovensku. Útočníci po telefonu zmanipulují oběť ke stažení falešné aplikace údajně od České národní banky (ČNB) nebo Národní banky Slovenska (NBS), přiložení platební karty k telefonu a zadání PINu. Malware poté v reálném čase přenese data z karty útočníkovi, který je bezkontaktně zneužije u bankomatu nebo na platebním terminálu.
Jen bych upozornil, že výpis směrovací tabulky není to, co ukazuje příkaz route, ale to, co ukazuje 'ip route show' nebo ještě lépe 'ip route show table all' a 'ip rule show'.
Jinak konfigurace FreeS/WAN byla vždycky trochu mystická a po přechodu na ipsec-tools (setkey a racoon) jsem zjistil, že je všechno najednou mnohem průhlednější, když se nemlží vlastními matoucími pojmy a používají se ty standardní. Celkově v používání OpenSWAN na dnešních jádrech nevidím moc smysl.
Jen bych upozornil, že výpis směrovací tabulky není to, co ukazuje příkaz routeTakže mě někdo mystifikuje?
man route route - show / manipulate the IP routing table
route --help Usage: route [-nNvee] [-FC] [<AF>] List kernel routing tables
route je v Linuxu obsolete od jádra 2.2 (vyšlo v lednu 1999). Takže vám sice v dobré víře ukáže, co si myslí, že je směrovací tabulka, ale ani zdaleka nemůžete spoléhat na to, že vám ukáže všechno, co potřebujete vědět.
1. Já to třeba v ifconfig(8) mám (a ne, nenapsal jsem si to tam sám). Jinak třeba tady a na spoustě dalších míst. Stačí nezavírat oči.
2. To už jsem udělal mnohokrát, ale pokud si úmyslně zadefinujete "běžné" situace jako ty, kdy ifconfig a route jakž takž stačí, pak to samozřejmě už z principu nepůjde. Pro zajímavost si zkuste porovnat i na zcela "běžném" systému výstup 'route -n' a 'ip route show table all'. Myslíte si, že to, co ukazuje druhý příkaz navíc, je nějaká fikce? Nebo si snad myslíte, že tyto položky nemají vliv na směrování paketů?
ifconfig a route naprosto postačuje. Navíc má o mnoho příjemnější syntaxi.
ifc<TAB>eth0 IP/maska upvs
ip addr add IP/maska dev eth0
ifconfig eth0:n IP/maska
ifconfig eth0:n IP/maska
To je alias, ne dve adresy. ja mam napriklad na jednom(!) rozhrani DHCP a zaroven dalsich par
ip a s eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:13:d3:d2:bb:ef brd ff:ff:ff:ff:ff:ff
inet 192.168.26.1/32 scope global eth0
inet 192.168.2.175/24 brd 192.168.2.255 scope global eth0
inet 192.168.0.175/24 brd 192.168.0.255 scope global eth0
inet 172.16.34.175/16 brd 172.16.255.255 scope global eth0
inet6 fe80::213:d3ff:fed2:bbef/64 scope link
valid_lft forever preferred_lft forever
A co mi ukaze ifconfig?
ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:13:d3:d2:bb:ef
inet addr:192.168.26.1 Bcast:0.0.0.0 Mask:255.255.255.255
inet6 addr: fe80::213:d3ff:fed2:bbef/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:254104359 errors:0 dropped:5146 overruns:0 frame:0
TX packets:130721632 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3197090190 (2.9 GiB) TX bytes:3644918187 (3.3 GiB)
Interrupt:17
No a kde je ten zbytek adres? Navic, primarni by mela byt 172.16.34.175 (DHCP) - kde je? To se pak nediv, ze ti pak chodi nejaky packety neznamo odkud a neznamo kam, kdyz vidis jenom pulku nastaveni (resp. mozna jenom 10%).
To je alias, ne dve adresy.
On to právě není alias, jen se to tak tváří. IP aliasing jako takový fungoval naposledy v řadě 2.0 (IIRC pouze v řädě 2.0). Problém (jeden z problémů) je právě v tom, že se ifconfig dodnes tváří, jako by tam skutečně existovalo virtuální rozhraní, což dávno není pravda. Navíc další adresy vidí a zobrazuje jen v případě, že mají přiřazený label (což demonstruje váš příklad).
Jestli jsem to dobře pochopil, výrazem příjemnější rozumíte kratší. V tom případě se můžete vykašlat na srozumitelnost a psát 'ip a a addr/prefixlen dev eth0' (IIRC spíš musíte, protože ip IIRC zápis s maskou ani nepodporuje).
Z filosofického hlediska má navíc ip jednu zcela zásadní výhodu: odpovídá tomu, co skutečně děláte - přidáváte na rozhraní adresu. Syntaxe ifconfig pořád vychází z toho, co už přes dvanáct let neplatí: že má rozhraní jednu adresu, která se nastavuje. Příznačné je, že pro IPv6 tentýž příkaz najednou realitu bere na vědomí a používá add a remove.
Příznačné je, že pro IPv6 tentýž příkaz najednou realitu bere na vědomí a používá add a remove.Neni to primarne proto, ze u IPv4 se vseobecne pocitalo s tim, ze rozhrani ma jen jednu adresu (a vic adres je tedy rozsireni nekterych implementaci), tak u IPv6 se standardne pocita s vice adresama? Treba u toho IPv4 mnoho navazujicich standardu ma s vice adresama problem (treba OSPFv2).
1. U IPv6 je skutečně pro plnou funkcionalitu nutné mít možnost přiřadit rozhraní více adres. Ale co se IPv4 týká, nejsem si vědom toho, že by standard nějak přikazoval nebo aspoň doporučoval mít jen jednu.
2. Skutečně je to problém OSPF jako takového? Není to spíš problém konkrétních implementací?
U OSPFv2 standard predpoklada 'jedna linka - jeden prefix'.Tedy s vyjimkou ptp (a ptmp) linek, ktere prefix mit nemusi.
Z filosofického hlediska má navíc ip jednu zcela zásadní výhodu: odpovídá tomu, co skutečně děláte - přidáváte na rozhraní adresu. Syntaxe ifconfig pořád vychází z toho, co už přes dvanáct let neplatí: že má rozhraní jednu adresu, která se nastavuje.Mě jedna adresa na rozhraní zatím skoro vždy stačila (OK, IPv6 je výjimka).
'ip route show table all'No, to je trochu zavadejici, nebot to vypise i obsah tabulky 'local', ktera ma specifickou funkci a rozhodne se nejedna o beznou routovaci tabulku. Pokud clovek srovna 'route -n' a 'ip route show', tak to na beznych konfiguracich vypise vicemene to same.
tabulky 'local', ktera ma specifickou funkci a rozhodne se nejedna o beznou routovaci tabulku
S takovou formulací bych určitě nesouhlasil. Tabulka local (255) je normální tabulka, která se zpracovává úplně stejně jako všechny ostatní. Zvláštní jsou na ní jen dvě věci: za prvé je defaultní tabulkou pro přidávání položek typu local a broadcast (a možná i některých dalších), ale stejně tak je main (254) defaultní pro typ unicast a některé další. Za druhé: automaticky vytvářené pravidlo s prioritou 0 zajišťuje, že se tato tabulka prohledává pro všechny pakety jako první. Jinak ale tato tabulka funguje stejně jako všechny ostatní.
Pokud clovek srovna 'route -n' a 'ip route show', tak to na beznych konfiguracich vypise vicemene to same.
Ne úplně, první příkaz vám IIRC neukáže třeba MTU, metriku nebo preferovanou zdrojovou adresu. Ale především vám ani jeden neukáže dostatek informací na to, abyste mohl určit, jak se bude konkrétní paket směrovat.
S takovou formulací bych určitě nesouhlasil. Tabulka local (255) je normální tabulka, která se zpracovává úplně stejně jako všechny ostatní.Hlavni rozdil bych videl v tom, ze tabulka 'local' je asi dost linuxove specifikum - pokud si predstavim jakysi genericky koncept IPv4 routovani a pak jeho jednotlive implementace, pak tabulka 'local' (resp. ty polozky typu 'local' a 'broadcast') resi to, co v ostatnich implementacich (ci v tom generickem modelu) je reseno mimo routovaci tabulku jinymi strukturami. Ze v Linuxove implementaci to chytre sloucili do stejnych struktur je sice pekne, ale tezko to potom porovnavat.
Imho je tam skutecne neposle. 10.0.0.0/8 neni globalne smerovatelna, takze na takovem rozhrani nema co delat. NAT/Maskarada funguje proto, ze se paketu na vstupu veme, zmenej se mu adresy, a pak uz je korektni paket vlozen, tusim primo do vystupni fronty pozadovaneho rozhrani. (Coz by znamenalo, ze se o jeho smeru vubec nerozhoduje routovaci tabulka. Ale nejsem si zcela jist, je to uz delsi dobu co sem to studoval.)
NAT/Maskarada funguje proto, ze se paketu na vstupu veme, zmenej se mu adresy, a pak uz je korektni paket vlozen, tusim primo do vystupni fronty pozadovaneho rozhrani.
To určitě ne, jak by se pak poznalo, které rozhraní to má být (a kdo má být další hop)? Překlad zdrojové adresy (tj. i maškaráda) se provádí až na konci, kdy už je o směrování rozhodnuto. Překlad zdrojové adresy naopak probíhá - aspoň u průchozích paketů - ještě před směrováním, ale paket je pak směrován podle standardních pravidel a tabulek. Trochu složitější je to jen při přepisu cílové adresy (případně značky) u lokálně generovaných paketů, ale i tam v zásadě platí, že bez ohledu na NAT o směrování rozhodují standardní mechanismy.
Na druhou stranu, pokud se používá IPsec (a zvláště v tunelovacím modu), je potřeba dávat pozor ještě na to, kdy se na paket aplikuje SP, která také může zamíchat kartami.
Mate pravdu, staci zadat do Googlu iptables a mrknout se co to naslo za obrazky.
Překlad zdrojové adresy naopak probíhá - aspoň u průchozích paketů - ještě před směrováním
Tady samozřejmě mělo být cílové, omlouvám se za nepozornost.
Bohužel není možné, abych zveřejnil topologii firemní sítě. Jak vidím, všeobecný názor je, že jádro neví nic o veřejných a privátních rozsazích. My teď opravíme konfiguraci, aby všechny routy byly definované. Tím ty záhady přestanou být vidět a budeme moci na ně zapomenout.
Prošlo to tam na úrovni Ethernetu VLANou, která vede radiospojem mimo routování a málokdo ze správy sítě o tom věděl. Na jedné straně je mi líto, že máme v síti nepořádek. Na druhé straně jsem rád, že jádro linuxu se nestydí a ten plyšovej talisman zatím ještě není tak úplně nezbytný.
Tiskni
Sdílej: