Evropská komise (EK) předběžně shledala čínskou sociální síť pro sdílení krátkých videí TikTok návykovým designem v rozporu s unijním nařízením o digitálních službách (DSA). Komise, která je exekutivním orgánem Evropské unie a má rozsáhlé pravomoci, o tom informovala v tiskovém sdělení. TikTok v reakci uvedl, že EK o platformě vykreslila podle něj zcela nepravdivý obraz, a proto se bude bránit.… více »
Offpunk byl vydán ve verzi 3.0. Jedná se o webový prohlížeč běžící v terminálu a podporující také protokoly Gemini, Gopher a RSS. Přibyl nástroj xkcdpunk pro zobrazení XKCD v terminálu.
Promethee je projekt, který implementuje UEFI (Unified Extensible Firmware Interface) bindingy pro JavaScript. Z bootovacího média načítá a spouští soubor 'script.js', který může používat UEFI služby. Cílem je vytvořit zavaděč, který lze přizpůsobit pomocí HTML/CSS/JS. Repozitář se zdrojovými kódy je na Codebergu.
Zpráva Justičního výboru Sněmovny reprezentantů upozorňuje na cenzurní kampaň Evropské komise, mířenou proti svobodě projevu na sociálních sítích. V dokumentu se uvádí, že se Evropská komise během posledních šesti let účastnila více než 100 uzavřených jednání, během nichž po platformách požadovala úpravy pravidel moderování obsahu, přičemž toto úsilí Komise zahrnovalo i cenzuru politických názorů a pravdivých informací. Výbor zdůrazňuje, že tento přístup Bruselu ohrožuje ústavou zaručená práva Američanů na svobodu projevu.
Linus Torvalds vydal jádro Linux 6.19. Podrobný výčet změn je ke zhlédnutí na stránce Kernel Newbies, stručné výběry v LWN (část první, druhá).
Do prodeje jde tichá bezdrátová herní myš Logitech PRO X2 SUPERSTRIKE s analogovými spínači s haptickou odezvou (HITS, Haptic Inductive Trigger System). Cena je 4 459 Kč.
Microsoft na GitHubu zveřejnil zdrojový kód projektu LiteBox, jedná se o 'knihovní operační systém' (library OS) zaměřený na bezpečnost, využívající systémovou architekturu LVBS k ochraně jádra před útoky z uživatelského prostoru. LiteBox je napsán v Rustu a uvolněný pod licencí MIT. Projekt je teprve v rané fázi vývoje.
BreezyBox je open-source shell a virtuální terminál pro populární jednočip ESP32. Nabízí základní unixové příkazy, sledování aktuálního pracovního adresáře (CWD), jednoduchý instalátor a spouštěč aplikací v podobě ELF binárních souborů, zabudovaný HTTP server nebo třeba ovládání WiFi - ukázka použití coby 'malého osobního počítače'. Ačkoliv je BreezyBox inspirovaný BusyBoxem, oproti němu má tento projekt několik externích závislostí, zejména na ESP-IDF SDK. BreezyBox je dostupný pod licencí MIT.
Byl představen cross-assembler xa.sh, napsaný čistě v Bourne shell skriptu. Tento nástroj umožňuje zpracovávat assemblerový kód pro Intel 8080, přičemž je možné snadno přidat podporu i pro další architektury, například 6502 a 6809. Skript využívá pouze různé běžné unixové příkazy jako jsou awk, sed nebo printf. Skript si lze stáhnout z GitHubového repozitáře projektu.
Byla představena nová verze modelu Claude Opus 4.6 od společnosti Anthropic. Jako demonstraci možností Anthropic využil 16 agentů Claude Opus 4.6 k vytvoření kompilátoru jazyka C, napsaného v programovacím jazyce Rust. Claude pracoval téměř autonomně, projekt trval zhruba dva týdny a náklady činily přibližně 20 000 dolarů. Výsledkem je fungující kompilátor o 100 000 řádcích kódu, jehož zdrojový kód je volně dostupný na GitHubu pod licencí Creative Commons.
Prosím o vaše názory na následující problém:
Mám domácí IPv6 síť se serverem, který routuje ven přes 6to4. Chtěl jsem do té sítě zavolat zvenku přes SIP. S IPv6 by to mělo jít teoreticky bez problémů. Nicméně výsledek byl velmi neslavný.
Napřed jsem zkusil prostě zavolat. Nefungovalo to, což bylo zcela správné, protože tam je nastavený jednoduchý firewall (viz řetězec FORWARD). Zvenku tedy spojení skutečně navázat nešlo. Tím ovšem korektní chování končí...
[root@charon ~]# ip6tables-save # Generated by ip6tables-save v1.4.0 on Sat Oct 18 01:15:01 2008 *mangle :PREROUTING ACCEPT [92:18894] :INPUT ACCEPT [10:952] :FORWARD ACCEPT [82:17942] :OUTPUT ACCEPT [11:1500] :POSTROUTING ACCEPT [94:19602] -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu COMMIT # Completed on Sat Oct 18 01:15:01 2008 # Generated by ip6tables-save v1.4.0 on Sat Oct 18 01:15:01 2008 *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [13:1804] -A INPUT -i lo -j ACCEPT -A INPUT -i ath0 -j ACCEPT -A INPUT -i eth1 -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 25 -j ACCEPT -A INPUT -p tcp -m tcp --dport 53 -j ACCEPT -A INPUT -p udp -m udp --dport 53 -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -p tcp -m tcp --dport 143 -j ACCEPT -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT -A INPUT -p tcp -m tcp --dport 5190 -j ACCEPT -A INPUT -p tcp -m tcp --dport 5222 -j ACCEPT -A INPUT -p tcp -m tcp --dport 5223 -j ACCEPT -A INPUT -p tcp -m tcp --dport 5269 -j ACCEPT -A INPUT -p tcp -m tcp --dport 7777 -j ACCEPT -A INPUT -p udp -m udp --dport 7777 -j ACCEPT -A INPUT -p ipv6-icmp -j ACCEPT -A FORWARD -i lo -j ACCEPT -A FORWARD -i ath0 -j ACCEPT -A FORWARD -i eth1 -j ACCEPT -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT COMMIT # Completed on Sat Oct 18 01:15:01 2008
Pak jsem prostě (jen tak na zkoušku) povolil forwardování všech paketů, tj. vypnul firewall.
ip6tables -t filter -P FORWARD ACCEPT
Nyní by správně měly všechny hovory bez problémů fungovat. Opak byl pravdou, což je vážná chyba. Zvukové spojení (RTP) se buď nenavázalo vůbec, nebo se (nejčastěji) navázalo pouze jedním směrem, nebo bylo po cca dvou sekundách v jednom směru přerušeno.
Už výše zmíněný problém by možná stačil na obsáhlé chybové hlášení, ale zkusil jsem jen tak pro zajímavost ještě jeden špinavý trik:
ip6tables -t filter -P INPUT ACCEPT
Pak už bylo zcela jisté, že je něco špatně. Hovory totiž začaly fungovat bez problémů. Abych vyloučil dočasnou nefunkčnost sítě, obě situace jsem prověřil ještě jednou se stejným výsledkem. (Zdůrazňuji, že volaný počítač nebyl samotný server. Šlo o stroj ve „vnitřní“ síti.)
Pokud jsem něco podstatného nepřehlédl, je tohle závažný bug v kernelu. Forwardování nemá absolutně nic společného s řetězcem INPUT. Jak je vůbec možné, že se zahazují nějaké pakety, přestože je forwardování povoleno, a že teprve úplné vyřazení řetězce INPUT dá tento problém do pořádku?
Hlavní otázka je: Co s tím? Hlásit? Nebo to může mít ještě jiné příčiny?
To je pravda
.[root@charon ~]# iptables-save # Generated by iptables-save v1.4.0 on Sat Oct 18 19:33:43 2008 *nat :PREROUTING ACCEPT [25046:7728446] :POSTROUTING ACCEPT [180:29094] :OUTPUT ACCEPT [833:79743] -A POSTROUTING -o ppp0 -j SNAT --to-source 217.112.173.73 COMMIT # Completed on Sat Oct 18 19:33:43 2008 # Generated by iptables-save v1.4.0 on Sat Oct 18 19:33:43 2008 *filter :INPUT DROP [13487:4322121] :FORWARD ACCEPT [104645:87372133] :OUTPUT ACCEPT [240465:50638141] -A INPUT -i lo -j ACCEPT -A INPUT -i ath0 -j ACCEPT -A INPUT -i eth1 -j ACCEPT -A INPUT -p ipv6 -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 25 -j ACCEPT -A INPUT -p tcp -m tcp --dport 53 -j ACCEPT -A INPUT -p udp -m udp --dport 53 -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -p tcp -m tcp --dport 143 -j ACCEPT -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT -A INPUT -p udp -m udp --dport 5004:5013 -j ACCEPT -A INPUT -p udp -m udp --dport 5060:5061 -j ACCEPT -A INPUT -p tcp -m tcp --dport 5190 -j ACCEPT -A INPUT -p tcp -m tcp --dport 5222 -j ACCEPT -A INPUT -p tcp -m tcp --dport 5223 -j ACCEPT -A INPUT -p tcp -m tcp --dport 5269 -j ACCEPT -A INPUT -p tcp -m tcp --dport 5432 -j ACCEPT -A INPUT -p tcp -m tcp --dport 7777 -j ACCEPT -A INPUT -p udp -m udp --dport 7777 -j ACCEPT -A INPUT -p icmp -j ACCEPT COMMIT # Completed on Sat Oct 18 19:33:43 2008 # Generated by iptables-save v1.4.0 on Sat Oct 18 19:33:43 2008 *mangle :PREROUTING ACCEPT [405575:174786346] :INPUT ACCEPT [287589:82843409] :FORWARD ACCEPT [104645:87372133] :OUTPUT ACCEPT [240465:50638141] :POSTROUTING ACCEPT [345693:138110445] -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu COMMIT # Completed on Sat Oct 18 19:33:43 2008
Samozřejmě. Jinak by totiž přes IPv6 nefungovalo vůbec nic. Nešel by ani ping6 zvenčí, natož abych se připojoval k mailu, webu nebo Jabberu přes IPv6. Můj server je ovšem přes IPv6 naprosto normálně dostupný. (Výše popsané potíže se týkaly počítače v LAN, do které server routuje.)
a ten ping zvenci jede taky pres ten tunel?
To přece záleží na tom, který ping. ping charon.podzimek.org půjde přes normální IPv4 síť, zatímco ping6 charon.podzimek.org půjde pochopitelně přes tunel. Nebo se ptáte, zda ping zvenčí funguje? Ano, funguje přes IPv4 i přes IPv6.
a kdyz ten radek z iptables (ipv4) oddelate, tak ping zvenci nepojede?
Přesně tak. Když jsem IPv6 poprvé nastavoval, právě na tento řádek jsem zapomněl. Dlouho jsem se divil, proč to nefunguje. 
Je to ovšem zcela logické. Paket jde z vnějšího rozhraní a navíc není typu TCP ani UDP. Tedy nesplní žádnou podmínku a propadne se až na konec řetězce, který má ovšem policy DROP.
Hmmm. No, asi mi nic jiného nezbude, pokud se to v dohledné době nepodaří nějak racionálně vysvětlit... Ale žádné pakety z vnitřní sítě určitě blokovány nejsou.
Vnější rozhraní jsou eth0, ppp0 a tun6to4. (Prakticky se používá pouze ppp0 (IPv4) a tun6to4 (IPv6).)
Vnitřní rozhraní jsou ath0 a eth1. Jak je vidět na výpisech, pakety z vnitřních rozhraní se ihned přijmou.
Ne, to není v pořádku. Protokol 6to4 není TCP ani UDP. Je to prostě jiný protokol rodiny IP a na routeru (iptables pro IPv4) se všechny takové pakety propouští, aby se následně filtrovaly přes ip6tables. Nemá se kde co předem zahazovat. (A pokud se to děje, je to bug v kernelu.)
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz