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.
V implementaci Broadcom 802.11 byla zjištěna chyba ve zpracování WPS/EAP, týká se to SDK od roku 2010. Broadcom podle výzkumníka Quentina Kaisera odmítl CVE přidělit. Modemy Huawei a Technicolor jsou používány i v ČR, v LTE routerech, běžných domácích routerech a firemních přístupových bodech, jejich současný počet a zranitelnost konkrétních verzí však zatím neznáme. Více detailů a demo. GitHub / Broadcom 802.11 SDK Detection Toolkit.
Byla vydána nová verze 10.8 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Přibyl balíček DietPi WireGuard.
Oslavte vydání openSUSE Leap 16.1 s námi v Praze! Ve středu 4. listopadu 2026 (den po vydání Leapu 16.1) vás zveme na malou oslavu vydání openSUSE Leap 16.1 do pražské kanceláře SUSE. Připravili jsme pro vás dvě krátké přednášky: … více »
Dle plánu bylo PHP vydáno v nových verzích 8.5.12, 8.4.27, 8.3.36 a 8.2.35. Opraveny jsou kritické zranitelnosti CVE-2026-109618 a CVE-2026-109619 aneb PHP2Shell.
UBports, nadace a komunita kolem Ubuntu pro telefony a tablety Ubuntu Touch, vydala Ubuntu Touch 24.04-2.1 a 24.04-1.5. S opravou kritických zranitelností.
Ahoj. Narazil jsem na problem a potreboval bych to pomoci nejak vyresit, nebo alespon vedet proc to nejde. (Debian Etch)
Jako prvni bych vas informoval, ze pppoe ma problemy na Xen serveru v domU (virtualni server). V dom0 (host) neni zadny problem a pppoe najede bez problemu. Stejny xen kernel z binarek u Debianu Etch.
Virtualnimu serveru je udelen vyhradni pristup na sitovou kartu a to tak, ze jsem nastavil boot option pciback.hide=(00.00.0) a pak pci option v configuraku pro virtualni server. Sitovka bez problemu funguje a je to Intel 1G, driver e1000 najel a bezi.
pppoe je nastaveno pres pppoeconf automaticky. Samo si to najde pppoe spojeni na eth2 a vse nakonfiguruje.
Samotny problem je kdyz se snazi o spojeni:
Nov 21 12:39:40 alsfw01 pppd[1316]: Plugin rp-pppoe.so loaded. Nov 21 12:39:40 alsfw01 pppd[1316]: Linux kernel does not support PPPoE -- are you running 2.4.x? Nov 21 12:39:40 alsfw01 pppd[1316]: Exit.
Napada vas neco? Jak muzu zjistit, kde je chyba? Jde nejak zaridit vice verbose log?
Dik za vsechny napady. Uz se s tim morim 4 dny. Zkousel jsem vsemozne kombinace a porad se nemuzu nekam dohrabat.
zgrep PPPOE /proc/config.gz
?
Ak povie
CONFIG_PPPOE=mtak mkôžeš skúsiť ako root urobiť
modprobe pppoeAk povie
# CONFIG_PPPOE is not settak potrebuješ prekompilovať jadro. Hláška samotná napovedá, že ak máš jadro 2.4 tak by si mal prejsť na niečo novšie. Verziu jadra povie uname -r
Prave ze v jadre je
alsfw01:~# zgrep PPPOE /proc/config.gz CONFIG_PPPOE=m
modprobe pppoe naloaduje vsechny moduly.
Ale porad dostavam ty same zpravy.
Jeste se na neco zeptam ohledne toho interface eth2, na kterem mam pppoe nastavene.
Je toto vse ok nebo je na tech vypisech neco podivneho? Hlavne PHYAD: 0 - ma tam byt nula?
alsfw01:~# ifdown eth2
alsfw01:~# ifup eth2
ADDRCONF(NETDEV_UP): eth2: link is not ready
e1000: eth2: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex
ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
alsfw01:~# ethtool eth2
Settings for eth2:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: umbg
Wake-on: g
Current message level: 0x00000007 (7)
Link detected: yes
Tak jsem po nekolika dnech na to konecne prisel.
Ve virtualnim stroji stacilo naistalovat udev a vse se rozbehlo. Uprime receno nevim, jak na to udev muze mit vliv, ale asi ma.
Take jsem si nemyslel, ze udev musi bezet, ale ted mi to dava smysl, protoze kdyz jsem tu kartu fyzicky priradil pro domU, tak tam asi musi byt neco (udev) co ji vlastne ridi. Je to preci fyzicke zarizeni. Ale to me hned nenapadlo, protoze normalne pciback.hide nepouzivam, tedy fyzicka zarizeni jsou jen na dom0.
No, byla to fuska, ale ted jsem happy
jako blecha.
Tiskni
Sdílej: