Linux na 4bitovém mikroprocesoru Intel 4004 z roku 1971? Ale jistě: Linux/4004 (YouTube).
Google Chrome 129 byl prohlášen za stabilní. Nejnovější stabilní verze 129.0.6668.58 přináší řadu novinek z hlediska uživatelů i vývojářů (YouTube). Podrobný přehled v poznámkách k vydání. Opraveno bylo 9 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře (YouTube: DevTools Chrome 127-129).
Byly nalezeny a opraveny bezpečnostní chyby CVE-2024-38812 a CVE-2024-38813 s CVSS 9.8 a 7.5 ve VMware vCenter Server. Jedná se o vzdálené spouštění příkazů (RCE) a eskalaci oprávnění.
MojeID rozdává bezpečnostní klíče (tokeny) GoTrust Idem Key pro přístup k online službám veřejné správy (NIA). Ti, kteří již mají, mohou získat tablet ve slosování.
Společnosti Nintendo a Pokémon žalují společnost Pocketpair. Její hra Palworld prý porušuje patenty Nintendo a Pokémon.
RabbitMQ (Wikipedie) byl vydán v nové major verzi 4.0. RabbitMQ je open source messaging a streaming broker napsaný v programovacím jazyce Erlang. Implementuje protokoly AMQP 0-9-1, AMQP 1.0, RabbitMQ Streams, MQTT a STOMP a v HTTP a WebSockets Web STOMP plugin, Web MQTT plugin a management plugin.
Po půl roce vývoje od vydání verze 46 bylo vydáno GNOME 47 s kódovým názvem Denver. Přehled novinek i s náhledy v poznámkách k vydání a v novinkách pro vývojáře. Krátké představení na YouTube.
Svobodná webová platforma pro sdílení a přehrávání videí PeerTube (Wikipedie) byla vydána v nové verzi 6.3. Přehled novinek i s náhledy v oficiálním oznámení a na GitHubu.
Uživatele Windows a Microsoft 365 Business a Enterprise mohou oficiálně používat Python v Excelu. Spolu s knihovnami jako pandas, Matplotlib a NLTK. Jedná se o spolupráci s Anacondou. Microsoft si tento "vynález integrace tabulkových procesorů s externími prostředími" patentoval: US12026560B2. Už před podáním patentu ale mohli uživatelé pro Python v Excelu používat například PyXLL. LibreOffice / OpenOffice.org měl PyUNO.
Provoz Mozilla.social, tj. instance Mastodonu provozované Mozillou, bude 17. prosince 2024 ukončen.
Tento zápisek se snaží ukázat jednoduché řešení nastavení konfigurace PC s Debianem (Wheezy) a s vícero síťovými kartami (integrovanými na desce). Přitom jde o to aby: 1) byla vždy IPv4 konektiva (ať už PC bude zapojeno kteroukoliv ze síťových karet) - IPv6 nechceme; 2) PC musí vždy dostat stejnou lokální IPv4 adresu, ať už je zapojeno přes kterýkoliv port (resp. ať už se eth* rozhraní nadetekují v jakémkoliv pořadí) - přičemž tu adresu dostane přes DHCP; 3) nastavení musí být natvrdo v systému a dostupné všem uživatelům (a nikoliv pomocí NetworkManageru či tak podobně); 3) PC by případně mělo fungovalo jako switch a to se zapnutým STP; 4) nahození rozhraní a získání adresy z DHCP nesmí při bootu zdržovat.
Řešení vypadá asi nějak takto (/etc/network/interfaces
na daném PC):
# --- Loopback auto lo iface lo inet loopback # --- Set up interfaces iface eth1 inet manual ethernet-wol g iface eth0 inet manual ethernet-wol g # --- Ethernet Bridge auto br0 iface br0 inet dhcp bridge_ports eth0 eth1 bridge_waitport 1 bridge_maxwait 1 # !! Not using "bridge_stp on" in order to reduce boot time. Using "post_up" instead !! post-up /sbin/brctl stp br0 yes
Vysvětlení: 1) nejdřív zajistíme, aby na eth[0-1]
nešahal nikdo jiný (např. již zmíněný NetworManager [pun intended]). To se zajistí pomocí dvou sekcí iface eth? inet manual
. Jako bonus pro každé rozhraní nastavíme možnost buzení přes Wake-On-Lan.
2) obě rozhraní (eth0
+ eth1
) dáme do bridge - br0
. To nám pak bude sloužit jako virtualní ethernetové rozhraní, které si získá svoji adresu přes DHCP a přes které se připojíme do sítě.
3) aby nastavení rozhraní netrvalo věčnost, nastavíme waitport (doba, po kterou se čeká na nahození jednotlivých rozhraní, než jsou přidány do bridge) jakož i maxwait (maximální doba, po kterou se čeká, než bude bridge v použitelném stavu) na jednu sekundu. Zvláště MAXWAIT je potvora, anžto je běžně nastavena na 32 sekund, po které se čeká, až bude bridge ve "stabilním stavu".
4) ovšem těchto 32 sekund vypadá jako dlouhá doba, nicméně je potřeba v případě, kdy je bridge v režimu STP (což chceme, protože máme různorodou síť a různé způsoby propojení a je potřeba, aby nám tam nevznikaly smyčky a pododně). Což je ale trochu problém, protože pokud nejprve nahodíme bridge a zapneme STP, pak je docela nutností nejprve dlouho čekat na ustálení STP. Pokud tak neučiníme, tak DHCP nefunguje a trvá nějakou chvíli, než to celé začne fungovat.
Moje řešení je v tuto chvíli takové, že nejdřív nahodím rozhraní, ale nezapnu STP - a doufám, že se síť za tu chviličku nezblázní - nechám PC, ať si získá adresu z DHCP - a teprve potom nahodím STP pomocí post-up
.
Dodatek: To aby PC dostalo vždy stejnou řeším přes ISC-dhcpd asi nějak takto:
host pc1-eth0 { option host-name pc1; hardware ethernet xx:yy:zz:qq:1c:23; fixed-address 192.168.123.123; } host pc1-eth1 { option host-name pc1; hardware ethernet xx:yy:zz:qq:0f:12; fixed-address 192.168.123.123; }
Tiskni Sdílej:
Pravdou je, že jsem to nikdy na linuxu nepotřeboval, jen na switchích a routerech.Jo, když odpadají licenční problémy, tak tohle bude nejspíš důvod, proč v kernelu RSTP není. Bylo by tam hezké, ale nikdo to vlastně nepoužívá, tudíž se nikomu nechce s tím patlat. Používat bridge jako fyzický switch sice jde, ale řekl bych, že drtivá většina použití bude spojení wifi a ethernetu na nějaké domácí routovací krabičce. Na větší nasazení to má málo portů (protože se do počítače nevejde tolik síťovek) a narozdíl od normálního switche se všechno řeší softwarově. S nástupem virtualizace (a virtuálních síťovek jako portů v tom bridge) by se tohle mohlo trochu posunout, ale neřekl bych, že o moc - připojením jednoho virtuálu do stejného bridge přes několik síťovek žádné výhody nemá (resp. žádné mě nenapadají) a jen si to koleduje o průšvih.
spousta mgmt síťových prvků postavených na linuxuNevím, které prvky jsou tím myšleny, ale pokud jde o switche a podobné*, tak i kdyby v nich byl Linux, určitě nebudou pro přepínání paketů používat kernelový bridge. A nemá smysl dávat do jádra implementaci RSTP pro něco, co se nakonec nepoužije. Tipl bych si, že spíš budou mít userspace proces, který od hardwaru dostane info o tom, že přišel RSTP rámec, a případně něco pošle do sítě. *) moc mi toho pod rukama neprošlo, ale jediný výrobce, který se zatím "přiznal", že mu jako OS běží nějaký open source, je Juniper se svým JunOS - který navíc vychází z BSD, ne z Linuxu.