Výzkumníci ukazují, jak mohou otevřené tunely a IPv6 Extension Headers synchronizovat pakety do krátkých provozních špiček. V kontrolovaném experimentu naměřili přes 180násobnou koncentraci paketového toku vůči průměrné rychlosti odesílání — nikoli 180násobné zvětšení objemu dat. Článek obsahuje metodiku, limity měření i mitigace pro GRE, IPIP a další tunely.
Po velkém úspěchu prvního MobileLinux Hackdaye se vracíme do Českých Budějovic s druhým ročníkem. V pátek 30. října 2026 od 10:00 se v prostorách Jihočeské univerzity uskuteční Embedded & MobileLinux Hackday #2. Těšit se můžete na témata jako Immutable Linux na telefonech (BengalOS), U-Boot a upstream vývoj, AI optimalizace pro embedded systémy nebo otevřený hardware. Nebude chybět praktické hackování, sdílení zkušeností a možnost … více »
Dne 21. října 2026 vydal projekt Node.js bezpečnostní aktualizace opravující deset zranitelností, včetně jedné umožňující potenciální vzdálené spuštění kódu (RCE). Nejzajímavější je CVE-2026-111497, chyba dekodéru Brotli, kterou objevili výzkumníci využívající OpenAI Codex Security. Chyba je v nativním dekodéru Brotli, nikoli v samotném JavaScriptu. Speciálně vytvořený komprimovaný vstup způsobí, že dekodér zamění
… více »Francouzský výrobce kabelů Nexans upozornil na napjaté dodávky elektrických kabelů. Výstavba nové výrobní linky pro některé typy kabelů může trvat přibližně tři roky. Datacentra potřebují rozsáhlé nízkonapěťové a středněnapěťové rozvody. Poptávka roste současně s modernizací elektrických sítí. Někteří odběratelé proto uzavírají výrazně delší dodavatelské smlouvy [Reuters].
Představena byla (𝕏) virtuální platforma FLYBENCH FPV, která nováčky provede zapojením a konstrukcí dronů.
Google Chrome 156 byl prohlášen za stabilní. Přehled novinek v poznámkách k vydání. Opraveno bylo 353 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Indická společnost eMudhra po bezpečnostním incidentu, tj. kompromitaci soukromých klíčů osmi mezilehlých certifikátů své certifikační autority, opouští globální byznys s SSL/TLS certifikáty.
Dle Phoronixu zveřejnila společnost Trend Micro prostřednictvím programu Zero Day Initiative (ZDI) několik hlášení bezpečnostních zranitelností přímo na veřejném mailing listu LKML, přestože některé chyby dosud nemají opravu začleněnou do hlavní větve jádra. Mezi hlášenými problémy jsou dvě zranitelnosti s hodnocením CVSS 9.0, týkající se SMB Direct a KSMBD, které mohou umožnit vzdálené spuštění kódu. Další hlášení se týkají … více »
Správce hesel KeePassXC byl vydán ve verzi 2.8.0. Přechází na Qt 6, podporuje vkládání hesel s Waylandem, rychlé odemykání pomocí Polkitu nebo možnost nastavení klávesových zkratek (seznam změn).
Databáze DuckDB (Wikipedie) byla vydána ve verzi 2.0.0 LTS. S kódovým názvem Cinnamon Teal (čírka skořicová). S vyladěným protokolem Quack.
Zdravim,
mam server - eth0 wan, eth1 lan, bezi na nem firewall, samba atd., ale nejdou odesilat maily.
puvodne jsem mel vsechno forwardovany na smtp od ISP, takhle v iptables:
-A PREROUTING -i eth1 -p tcp -m tcp --dport 25 -j DNAT --to-destination xxx.xxx.xxx.xxx:25
normalne to fungovalo, pak sem to zrusil a fungovalo posilani pres libovolnej smtp. Ted by tam mel jet postfix,
ale nic neodejde, na cokoliv mi to pise: Connection timed out: port 25
Port 25 blokovanej neni, na jakykoliv smtp ven se telnetem pripojim, dokonce i kdyz se pripojim
zevnitr na server dostanu se na smtp postfixu, a kdyz tam rucne dam neco odeslat je to to samy.
Proto tipuju na blbe nastavenej firewall, v iptables uz nic o portu 25 neni, internet atd funguje normalne.
Tusite nekdo v cem je zakopanej pes?
a vlogach postfixu neco je?
no tam prave je ten timeout, pise to tohle:
Dec 17 09:44:56 server postfix/qmgr[7791]: CDE96400B537: from=<neco@domena.cz>, size=5345, nrcpt=1 (queue active)
Dec 17 09:45:26 server postfix/smtp[7793]: connect to mx50.seznam.cz[77.75.73.47]: Connection timed out (port 25)
Dec 17 09:45:56 filmserver postfix/smtp[7793]: connect to mx60.seznam.cz[77.75.73.47]: Connection timed out (port 25)
Dec 17 09:45:56 server postfix/smtp[7793]: CDE96400B537: to=<xtas--at--email.cz>, relay=none, delay=147012, delays=146951/0.01/60/0, dsn=4.4.1, status=deferred (connect to mx60.seznam.cz[77.75.73.48]: Connection timed out)
Podivejte se do firewallu, zdali opravdu nekde nemate blokovany port 25 a pak v main.cf zkontrolujte parametr mynetworks, zdali nemate povolenou komunikaci jen z localhostu, zkuste take odeslat mail z localhostu, zdali projde. Pokud ani to nezabere, tak sem vlozte vypis z logu mail.info, mail.error a mail.warn
v mynetworks je 127.0.0.0/8, 192.168.1.0/24 - ale to by snad melo byt spravne, potrebuju jen posilani mailu z vnitrni site. Mail neprojde ani kdyz se telnetem pripojim na localhost a zkusim to rucne. mail.info viz trochu vyse, mail.error a mail.warn jsou prazdne. Asi znovu zkouknu ten firewall ale asi jsem slepej :-/
je spravne v main.cf: mydestination = localhost.localdomain, localhost ? to je defaultni ne?
Tak jste me navedli spravne, bylo to fakt v tom firewallu, akorat byla nastavena stara adresa v iptables
-A OUTPUT -s xxx.xxx.xxx.xxx -j ACCEPT
ja sem si rikal ze to pravidlo je nastaveny spravne, ale neznam tu adresu zpameti a nenapadlo me ze bude spatna, momentalne na serveru nic nebezelo, traffic sel pres FORWARD takze se vse zdalo v pohode :)
Kazdopadne teda jeste jeden dotaz: to co mam v main.cf jako MYHOSTNAME - muzu to pouzit uz jako smtp server nebo musim jeste neco nekde nastavit? tzn. aby lidi ve svych klientech meli v nastaveni odchoziho serveru to co je v MYHOSTNAME a ne 192.168.1.1?
priste by melo stacit z dane masiny telnet nejaky.smtp.server 25 a hned by bylo videt, ze se se vzdalenym serverem vubec nespojite...
Tiskni
Sdílej: