Evropská komise naléhavě vyzvala členské státy EU, aby kvůli ochraně nezletilých na internetu urychlily zavádění unijní aplikace pro ověřování věku a zajistily její dostupnost do konce roku. Členské státy mohou zavést aplikaci EU pro ověřování věku jako samostatnou aplikaci nebo ji integrovat do takzvané evropské peněženky digitální identity.
Richard Biener oznámil vydání verze 16.1 (16.1.0) kolekce kompilátorů pro různé programovací jazyky GCC (GNU Compiler Collection). Jedná se o první stabilní verzi řady 16. Přehled změn, nových vlastností a oprav a aktualizovaná dokumentace na stránkách projektu. Některé zdrojové kódy, které bylo možné přeložit s předchozími verzemi GCC, bude nutné upravit.
Zulip Server z open source komunikační platformy Zulip (Wikipedie, GitHub) byl vydán ve verzi 12.0. Přehled novinek v příspěvku na blogu.
Před 30 lety, tj. v úterý 30. dubna 1996, byl spuštěn Seznam.cz.
Byly zpracovány a zveřejněny všechny videozáznamy, které stojí za zveřejnění, z konference FOSDEM 2026.
Od úterý 28. dubna musí nově uváděné notebooky v Evropské unii podporovat nabíjení přes USB-C. Jednotná nabíječka byla schválena Evropským parlamentem v říjnu 2022.
Byly publikovány informace o kritické zranitelnosti CVE-2026-31431 pojmenované Copy Fail v Linuxu, konkrétně v kryptografii (AF_ALG). Běžný uživatel může získat práva roota (lokální eskalaci práv). Na všech distribucích Linuxu vydaných od roku 2017. Pomocí 732bajtového skriptu. V upstreamu je již opraveno. Zranitelnost byla nalezena pomocí AI Xint Code.
Textový editor Zed dospěl do verze 1.0. Představení v příspěvku na blogu.
Vývojáři svobodného 3D softwaru Blender představili (𝕏, Mastodon, Bluesky) nejnovějšího firemního sponzora Blenderu. Je ním společnost Anthropic stojící za AI Claude a úroveň sponzoringu je Patron, tj. minimálně 240 tisíc eur ročně. Anthropic oznámil sponzorství v tiskové zprávě Claude for Creative Work.
VNC server wayvnc pro Wayland kompozitory postavené nad wlroots - ne GNOME, KDE nebo Weston - byl vydán ve verzi 0.10.0. Vydána byla také verze 1.0.0 související knihovny neatvnc.
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
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.czroute 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
18.8.2011 14:59
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
ifconfig eth0:n IP/maska
ifconfig eth0:n IP/maska
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.
17.8.2011 22:55
xxx | skóre: 42
| blog: Na Kafíčko
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.
17.8.2011 23:26
xxx | skóre: 42
| blog: Na Kafíčko
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:
