Elon Musk oznámil (𝕏) spuštění internetové encyklopedie Grokipedia (Wikipedia). Zatím ve verzi 0.1. Verze 1.0 prý bude 10x lepší, ale i ve verzi 0.1 je podle Elona Muska již lepší než Wikipedia.
PSF (Python Software Foundation) po mnoha měsících práce získala grant ve výši 1,5 milionu dolarů od americké vládní NSF (National Science Foundation) v rámci programu "Bezpečnost, ochrana a soukromí open source ekosystémů" na zvýšení bezpečnosti Pythonu a PyPI. PSF ale nesouhlasí s předloženou podmínkou grantu, že během trvání finanční podpory nebude žádným způsobem podporovat diverzitu, rovnost a inkluzi (DEI). PSF má diverzitu přímo ve svém poslání (Mission) a proto grant odmítla.
Balík nástrojů Rust Coreutils / uutils coreutils, tj. nástrojů z GNU Coreutils napsaných v programovacím jazyce Rust, byl vydán ve verzi 0.3.0. Z 634 testů kompatibility Rust Coreutils s GNU Coreutils bylo úspěšných 532, tj. 83,91 %. V Ubuntu 25.10 se již používá Rust Coreutils místo GNU Coreutils, což může přinášet problémy, viz například nefunkční automatická aktualizace.
Od 3. listopadu 2025 budou muset nová rozšíření Firefoxu specifikovat, zda shromažďují nebo sdílejí osobní údaje. Po všech rozšířeních to bude vyžadováno někdy v první polovině roku 2026. Tyto informace se zobrazí uživateli, když začne instalovat rozšíření, spolu s veškerými oprávněními, která rozšíření požaduje.
Jste nuceni pracovat s Linuxem? Chybí vám pohodlí, které vám poskytoval Microsoft, když vás špehoval a sledoval všechno, co děláte? Nebojte se. Recall for Linux vám vrátí všechny skvělé funkce Windows Recall, které vám chyběly.
Společnost Fre(i)e Software oznámila, že má budget na práci na Debianu pro tablety s cílem jeho vyžívání pro vzdělávací účely. Jako uživatelské prostředí bude použito Lomiri.
Proběhla hackerská soutěž Pwn2Own Ireland 2025. Celkově bylo vyplaceno 1 024 750 dolarů za 73 unikátních zranitelností nultého dne (0-day). Vítězný Summoning Team si odnesl 187 500 dolarů. Shrnutí po jednotlivých dnech na blogu Zero Day Initiative (1. den, 2. den a 3. den) a na YouTube.
Byl publikován říjnový přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Pracuje se na podpoře M3. Zanedlouho vyjde Fedora Asahi Remix 43. Vývojáře lze podpořit na Open Collective a GitHub Sponsors.
Iniciativa Open Device Partnership (ODP) nedávno představila projekt Patina. Jedná se o implementaci UEFI firmwaru v Rustu. Vývoj probíhá na GitHubu. Zdrojové kódy jsou k dispozici pod licencí Apache 2.0. Nejnovější verze Patiny je 13.0.0.
Obrovská poptávka po plynových turbínách zapříčinila, že datová centra začala používat v generátorech dodávajících energii pro provoz AI staré dobré proudové letecké motory, konvertované na plyn. Jejich výhodou je, že jsou menší, lehčí a lépe udržovatelné než jejich průmyslové protějšky. Proto jsou ideální pro dočasné nebo mobilní použití.
Mám SUN Blade centrum a v něm dva interní ethernetové switche, které zprostředkují komunikaci do jedné IPv4 sítě. Každá žiletka má tudíž dvě síťová rozhraní připojená do sítě. Chci oživit failover bonding, aby to komunikovalo, i když se rozbije interní switch nebo něco jiného na cestě do sítě. Síť je na linkové úrovni složitě strukturovaná a je rozváděná do různých lokalit.
Žiletky slouží pro KVM virtualizaci, proto mají aktivní virtuální bridge, ten spojuje vnější fyzickou síť s vnitřní virtuální sítí. Všecko běhá přes br0 a stávající konfigurace na testovací žiletce je
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
~ 0> brctl show br0
bridge name bridge id STP enabled interfaces
br0 8000.001b21da8e28 no eth1
~ 0> ip addr
. . .
3: eth1: -BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP qlen 1000
link/ether 00:1b:21:da:8e:28 brd ff:ff:ff:ff:ff:ff
. . .
12: br0: -BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 00:1b:21:da:8e:28 brd ff:ff:ff:ff:ff:ff
inet 10.5.75.142/24 brd 10.5.75.255 scope global br0
inet6 fe80::21b:21ff:feda:8e28/64 scope link
valid_lft forever preferred_lft forever
~ 0>
Z konzoly shodím eth1 a vyndám ho z br0. Potom si udělám bonding:
~ 0> modprobe bonding mode=1 arp_interval=1000 arp_ip_target=10.5.75.140 arp_validate=1 ~ 0> ip link set bond0 up ~ 0> ip link set eth1 up ~ 0> ip link set eth4 up ~ 0> ifenslave bond0 eth1 eth4 ~ 0> brctl addif br0 bond0
Načež mi to nějak komunikuje, ale odezva je mizerná, ve statistice bondingu přibývají výpadky linky střídavě eth1 a eth4. messages ukazují:
Feb 12 15:12:38 blade5 kernel: [ 1565.997923] device eth4 entered promiscuous mode Feb 12 15:12:38 blade5 kernel: [ 1565.998178] bonding: bond0: no path to arp_ip_target 10.5.75.140 via rt.dev br0 Feb 12 15:12:39 blade5 kernel: [ 1566.997126] bonding: bond0: link status definitely up for interface eth1. Feb 12 15:12:39 blade5 kernel: [ 1566.997137] bonding: bond0: no path to arp_ip_target 10.5.75.140 via rt.dev br0 Feb 12 15:12:40 blade5 kernel: [ 1567.996676] bonding: bond0: no path to arp_ip_target 10.5.75.140 via rt.dev br0 Feb 12 15:12:41 blade5 kernel: [ 1568.996217] bonding: bond0: link status definitely down for interface eth4, disabling it Feb 12 15:12:41 blade5 kernel: [ 1568.996224] bonding: bond0: making interface eth1 the new active one. Feb 12 15:12:41 blade5 kernel: [ 1568.996228] device eth4 left promiscuous mode Feb 12 15:12:41 blade5 kernel: [ 1568.996559] device eth1 entered promiscuous mode Feb 12 15:12:41 blade5 kernel: [ 1568.996818] bonding: bond0: no path to arp_ip_target 10.5.75.140 via rt.dev br0 Feb 12 15:12:42 blade5 kernel: [ 1569.995776] bonding: bond0: link status definitely up for interface eth4. Feb 12 15:12:42 blade5 kernel: [ 1569.995786] bonding: bond0: no path to arp_ip_target 10.5.75.140 via rt.dev br0 Feb 12 15:12:43 blade5 kernel: [ 1570.995307] bonding: bond0: no path to arp_ip_target 10.5.75.140 via rt.dev br0 Feb 12 15:12:44 blade5 kernel: [ 1571.994850] bonding: bond0: link status definitely down for interface eth1, disabling it Feb 12 15:12:44 blade5 kernel: [ 1571.994857] bonding: bond0: making interface eth4 the new active one. Feb 12 15:12:44 blade5 kernel: [ 1571.994861] device eth1 left promiscuous mode
Pořád dokola. Na testovacím stroji trvale existuje ARP záznam cílového stroje 10.5.75.140 . Naopak na cílovém stroji vůbec neexistuje ARP záznam testovacího stroje. Na cílovém stroji jsem chytal pakety a od testovacího stroje jsem neviděl nic. Možná jsem se špatně díval, hledal jsem IP komunikaci. Nemá to být něco jiného?
Při aktivním bondingu mi ip link ukazuje, že rozhraní eth1, eth4, bond0 mají všechny stejnou MAC adresu, a to tu, kterou měl původně eth1. Možná že bond0 posílá testovací pakety po aktivním rozhraní, ale pakety nedojdou, protože br0 pakety ukradne. V tom případě by se aktivní cesta považovala za nefunkční a to by byl důvod flapování. Ale nevím, byla by prosím, nějaká rada?
Řešení dotazu:
cat /proc/net/bonding/bond0 ukazuje active/backup. parametr se jmenuje mode. bonding je jmeno modulu. Myslím že tohle mám dobře.
Především byste měl napsat, o jaké jádro se jedná. Tenhle kus kódu byl přepsán tolikrát, že bez této informace nemá smysl naslepo hádat. Pak by také pomohlo, kdybyste ukázal celou konfiguraci, ne jen malý výřez z ní; když se totiž třeba podívám na to, jak vypadala funkce bond_arp_send_all() ve verzi 3.0, tak by se hláška
bonding: bond0: no path to arp_ip_target 10.5.75.140 via rt.dev br0
neměla mít šanci objevit, pokud nad tím bondem nemáte i nějaké vlany. Jinak kdybych si měl tipnout, tak ta vaše konfigurace neměla moc šanci fungovat před commitem 27bc11e63888 (verze 3.12-rc1).
Linux blade5 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux
~ 0> ip link
1: lo: -LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: -BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
link/ether 00:10:e0:3c:0f:cc brd ff:ff:ff:ff:ff:ff
3: eth1: -BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP mode DEFAULT qlen 1000
link/ether 00:1b:21:da:8e:28 brd ff:ff:ff:ff:ff:ff
4: eth2: -BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
link/ether 00:10:e0:3c:0f:cd brd ff:ff:ff:ff:ff:ff
5: eth3: -BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
link/ether 00:c0:dd:26:9a:b4 brd ff:ff:ff:ff:ff:ff
6: eth4: -BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP mode DEFAULT qlen 1000
link/ether 00:1b:21:da:8e:28 brd ff:ff:ff:ff:ff:ff
7: eth5: -BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
link/ether 00:c0:dd:26:9a:b5 brd ff:ff:ff:ff:ff:ff
8: eth6: -BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
link/ether 00:c0:dd:26:9b:0c brd ff:ff:ff:ff:ff:ff
9: eth7: -BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
link/ether 00:c0:dd:26:9b:0d brd ff:ff:ff:ff:ff:ff
10: usb0: -BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
link/ether 02:21:28:57:47:17 brd ff:ff:ff:ff:ff:ff
12: br0: -ROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT
link/ether 00:1b:21:da:8e:28 brd ff:ff:ff:ff:ff:ff
14: bond0:-BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP mode DEFAULT
link/ether 00:1b:21:da:8e:28 brd ff:ff:ff:ff:ff:ff
~ 0>
Potkala mě šílená myšlenka, že ARP monitoring používá nějaký typ komunikace, kterou naše switche v rámci bezpečnosti blokujou. Třeba IPv6. Já tedy nevím co naše switche blokujou, rád bych aspoň věděl, co tam posílá ten ARP monitor. Tuhle informaci jsem nikde nenašel. Co se týká našich switchů, můžu to začít zjišťovat, až budu vědět, co vlastně hledám.
Vyzkoušel jsem obě verze s konstantní MAC adresou a obě fungovaly, ale flapovaly. Ta třetí s přeskakující MAC adresou nefungovala, což jsem přičítal zmatku v ARP tabulkách okolních počítačů. Klidně to ale mohl být i zásah switchů. Řekl bych ale, že s mým problémem tohle nesouvisí. Nachytal jsem pakety na rozhraní eth1, rozumí se bez explicitního přepnutí do promiskuitního režimu, protože bonding si ho zapíná a vypíná jak on chce. Skutečně tam není nic, co by směřovalo na "cílový stroj". Podobně na cílovém stroji nevidím nic, co by pocházelo od testovaného stroje. Takže si pořád musím myslet, že jeden modul jádra ty pakety vytváří a druhý modul je žere.
Tiskni
Sdílej:
