Vývojáři C-Kermit oznámili několik dlouhodobě přítomných zranitelností. Patří mezi ně buffer overflow v Telnet/FTP klientovi a command injection v Kermit serveru. Dotčené verze: C-Kermit 11.0.514 a starší. Fix: 11.1.515 [oss-security].
Byla vydána nová verze 3.2.8 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání a v souboru NEWS na GitLabu. Nový GIMP je již k dispozici také na Flathubu.
Projekt openSUSE dnes, 3. listopadu 2026, oficiálně vydal openSUSE Leap 16.1, novou verzi své stabilní linuxové distribuce. Novinkou je také Immutable Mode, který nahrazuje dosavadní samostatnou distribuci openSUSE Leap Micro. Podrobnosti o novém vydání najdete v oficiálním oznámení nebo v českém překladu oznámení. Instalační obrazy jsou již dostupné na get.opensuse.org. Vydání společně oslavíme v pátek ve virtuálním baru a na … více »
Bylo oznámeno vydání Fedora Linuxu 45. Ve finální verzi vychází šest oficiálních edic: Fedora Workstation a Fedora KDE Plasma Desktop pro desktopové, Fedora Server pro serverové, Fedora Cloud pro cloudové nasazení, Fedora CoreOS pro ty, kteří preferují neměnné systémy a Fedora IoT pro internet věcí. Vedle nich jsou k dispozici také další atomické desktopy, spiny a laby. Podrobný přehled novinek v samostatných článcích na stránkách
… více »Vědci z MIT CSAIL představili koncept 'weight-space programming' a názorně předvedli, že pokročilé jazykové modely SI dokážou přímo číst a upravovat váhy neuronových sítí. Studie ukazuje, že modely nejen dokážou identifikovat účel sítí z pouhého nahlédnutí do jejich číselných vah, ale mohou i cíleně opravovat chyby a nedostatky, například GPT-6 Astra se změnou pouhých 0,016% vah open-weight modelu Qwen3.5-0.8B podařilo odstranit
… více »Organizátoři komunitního setkání nejen českých a slovenských správců sítí CSNOG 2027, které se uskuteční 20. a 21. ledna na půdě zlínské univerzity Tomáše Bati, oznámili prodloužení termínu pro zasílání abstraktů do programu akce. Zájemci se mohou hlásit prostřednictvím webu setkání do úterý 10. listopadu. Programová komise uvítá příspěvky věnované nejen správě sítí, ale také legislativě a regulaci nebo síťařským aktivitám studentů a pedagogů.
Bylo spuštěno předobjednávání zařízení Flipper One s Linuxem. Za 20 dolarů si lze koupit kupón a zajistit si tím speciální cenu 379 dolarů po spuštění kampaně na Kickstarteru.
Tor Browser, tj. fork webového prohlížeče Mozilla Firefox s integrovaným klientem sítě Tor přednastavený tak, aby přes tuto síť bezpečně komunikoval, byl vydán ve verzi 16.0. Postaven je na Firefoxu ESR 153. Vydána byla také nová verze 7.16 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. S Tor Browserem 16.0.
FreeTube, desktopový klient pro YouTube využívající lokální API, byl vydán ve verzi 0.26.0. Toto velké opravné vydání mj. vrací částečnou podporu živých přenosů nebo přepracovává zobrazování titulků a obecně nastavení videa v přehrávači – FreeTube umožňuje např. přehrávat video s větším zrychlením.
Další vlna kyberútoků zasáhla chladicí zařízení supermarketů v sedmi evropských zemích, Belgii, Lucembursku, Švédsku, Nizozemsku, Irsku, Estonsku a Finsku. Mrazáky se v některých prodejnách opět 'proměnily v trouby' a zahřály až na 50°C, což pochopitelně vedlo ke znehodnocení uskladněných potravin. Útoky navazují na podobný incident ve Francii z první poloviny října letošního roku, pachatel stále není znám.
V podniku máme dvě pracoviště spojená internetem. Na každém pracovišti je pár strojů s "veřejnými" t.j. routovatelnými adresami a hodně strojů s "privátními" t.j. neroutovatelnými adresami. Linuxové hraniční routery dělají současně NAT pro přístup privátních strojů do internetu. Hraniční routery dále dělají IPsec tunel mezi oběma lokalitami, takže vzájemná konektivita v rámci podniku je každý s každým.
Stroje s veřejnou adresou chodí na router nativním Ethernetem. Stroje s privátní adresou chodí na router pomocí VLAN na stejném fyzickém rozhraní, a router si to přebere. Na routerech je řada filtrovacích pravidel iptables sloužících jako firewall. Spojení do internetu máme na optice. Všechno funguje a stroje s veřejnou adresou si posílají data s průchodností tisíců Mbps.
Problém: Stroje s privátní adresou se dostanou na druhou stranu jen s malou průchodností pod 10Mbps. Často se stane, že přenos z privátní sítě jedné lokality začne slušnou rychlostí 100Mbps, ale rychlost během několika minut klesne na desetinu a méně, při čemž některý z routerů začne být zahlcený. Ve stavu zahlcení je jeho celková datová průchodnost velmi malá, ale nevypadá to, že by se pakety ztrácely. Ale odezva pingu vyběhne z původních jednotek ms na stovky ms. Při tom top na linuxovém routeru ukazuje load asi tak 4, procesor přes 95% idle. Současně vmstat ukazuje jen malý provoz, odpovídající té malé průchodnosti. Top vůbec neukáže, že by démon pluto (t.j. IPsec) spotřebovával zdroje.
Otázky: Kam se poděl výkon? Mohlo by to brzdit VLAN dekódování v jádře? Může to brzdit IPsec? Zažil někdo podobný jev?
Děkuji.
Vypadá že zahlcený je přímo ten router. Všecko co jde přes něj nebo přímo z něj má pomalou odezvu. Všechno co jde mimo něj má dobrou. Problém je ale v tom, že nevidíme nebo se neumíme podívat, co konkrétně se na routeru tak náročnýho děje.
Pozorované případy zahlcení jsou
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
25.7.2011 14:45
lokalita A <-> IPsec <-> lokalita B
Při tom je NAT vyloučen, je tam jen tunel. Jestli je moc pravidel nevím, ale stejná pravidla se uplatní i při spojení
veřejná síť A <-> veřejná síť B
a propustnost je velmi dobrá.
Statistiky před přenosem a po přenosu, když se přenos udělá různýma cestama - že mě to nenapadlo?? Dík já to zkusím. (Ale teď jdu domů.)
Prozkoumal jsem statistiky s velkou parádou, snímkoval jsem po sekundě, dělal jsem z toho grafy a hnidopišsky jsem sečítal a odčítal čísílka v souborech vzorků. Nakonec vidím že nic nevidím, pakety běhají jak mají, žádné chyby, co jeden pošle druhý přijme. Když mám nějaký provoz na eth0.204 tak ho vidím ve statistice jak téhle vlany, tak ve statistice eth0. To je doufám správně.
Teď asi budu muset nějak hledat, který program je ten, který to zatížení způsobuje. Problém je že top nic neukázal. Já myslím že top ukazuje čas strávený v kontextu procesu, ale routování včetně netfilteru je přece v jádře. Jak spolehlivě zjistit, kolik zdrojů spotřebovává jádro, to tedy vážně nevím.
3.8.2011 19:51
vencour | skóre: 57
| blog: Tady je Vencourovo
| Praha+západní Čechy
A conntrack-tools jste už zkusil, jestli se nějak mění počet spojení? Ohledně "provozu" zkuste sledovat stav skrze latencytop a atop.
Děkuji za rady. Normálně je tam kolem 2000 interuptů za sekundu podle vmstat, atop ukazuje IRQ na úrovni 3%. Když pustím intezívní přenos, který jde do veřejné sítě a tedy neprochází tunelem IPsec, interupty vylezou na 8000 / s a atop ukazuje IRQ hodnotu mezi 30 - 40% . Myslím že to znamená, že 40% výkonu CPU jde na zpracování přerušení. Když pustím stejně inteznívní přenos do privátní sítě, jde to skrz IPsec tunel. V tom případě je přes 13000 přerušení/s a atop mi píše 100% IRQ a při tom se červená.
Mimochodem ten router je IBM blade LS21, 4GBN RAM, jeden Dual-Core AMD Opterony 2218 @2.6 GHz. Chipset jsem vyguglil SERVERWORKS HT1000 / HT2000 . Tož tak. Problém trvá, protože kdokoliv z uživatelů může začít tlačit data z jedné lokality do druhé a tím to zahltí. Řešení mě nenapadá.
nrouter2 root# cat /proc/interrupts
CPU0 CPU1
0: 42 0 IO-APIC-edge timer
1: 0 2 IO-APIC-edge i8042
5: 0 1043 IO-APIC-fasteoi ehci_hcd:usb1, ohci_hcd:usb2, ohci_hcd:usb3
7: 1 0 IO-APIC-edge
8: 0 0 IO-APIC-edge rtc0
9: 0 0 IO-APIC-fasteoi acpi
12: 0 4 IO-APIC-edge i8042
48: 15930 3074685 PCI-MSI-edge qla2xxx
49: 1624 333074 PCI-MSI-edge qla2xxx
50: 26215268 3136520483 PCI-MSI-edge eth0
51: 30172892 3172682677 PCI-MSI-edge eth1
52: 40 2693 PCI-MSI-edge eth2
53: 136 11704 PCI-MSI-edge eth3
NMI: 0 0 Non-maskable interrupts
LOC: 259980490 661828332 Local timer interrupts
SPU: 0 0 Spurious interrupts
PMI: 0 0 Performance monitoring interrupts
IWI: 0 0 IRQ work interrupts
RES: 55276625 7716555 Rescheduling interrupts
CAL: 6435 2238 Function call interrupts
TLB: 338364 157931 TLB shootdowns
TRM: 0 0 Thermal event interrupts
THR: 0 0 Threshold APIC interrupts
MCE: 0 0 Machine check exceptions
MCP: 11148 11148 Machine check polls
ERR: 1
MIS: 0
Nějak neumím zarovnat sloupečky. Naprostá většina přerušení je na CPU 1.
Vychází to moc draho - na dva routery šifrující 300 Mbps milionová investice. Já nevím jestli by ten OpenSwan šel nějak poladit nebo použít něco jiného.
Podle /proc/stat máme 3 miliardy HW přerušení a 4 miliardy SW přerušení. Běžně tam je 2000 přerušení/s, Při testovacím SSH přenosu rychlostí 11 MB/s podle tvrzení SCP do veřejné sítě máme 7500 intr/s . Řekněme že těch 5500 navíc jsou HW intr. odpovídající přijetí paketu a odeslání paketu. Při testovacím přenosu do privátní sítě skrz IPsec (stejnou rychlostí podle tvrzení SCP) máme 13000 intr/s . Řekněme že z toho je 2000 běžný provoz, 5500 HW přijmutí a odeslání a dalších 5500 přečtení programem a zápis programem do soketu. Když dedikujeme další celý stroj pro IPsec, bude tam tedy místo 13000 intr/s jen 11000, to se mi nezdá až takový rozdíl. Podle mě není jisté, že toto rozdělení funkcí něco rapidně zlepší.
Tiskni
Sdílej:
