Byla vydána nová verze 14.3 svobodného unixového operačního systému FreeBSD. Podrobný přehled novinek v poznámkách k vydání.
CSIRT.CZ upozorňuje, že na základě rozhodnutí federálního soudu ve Spojených státech budou veškeré konverzace uživatelů s ChatGPT uchovávány. Včetně těch smazaných.
Ač semestr ve škole právě končí, bastlíři ze studentského klubu Silicon Hill neodpočívají a opět se jako každý měsíc hlásí s pravidelným bastlířským setkáním Virtuální Bastlírna, kde si můžete s ostatními techniky popovídat jako u piva o novinkách, o elektronice, softwaru, vědě, technice obecně, ale také o bizarních tématech, která se za poslední měsíc na internetu vyskytla.
Z novinek za zmínku stojí Maker Faire, kde Pájeníčko předvedlo … více »Na WWDC25 byl představen balíček Containerization a nástroj container pro spouštění linuxových kontejnerů na macOS. Jedná se o open source software pod licencí Apache 2.0 napsaný v programovacím jazyce Swift.
Do 16. června do 19:00 běží na Steamu přehlídka nadcházejících her Festival Steam Next | červen 2025 doplněná demoverzemi, přenosy a dalšími aktivitami. Demoverze lze hrát zdarma.
Apple na své vývojářské konferenci WWDC25 (Worldwide Developers Conference, keynote) představil řadu novinek: designový materiál Liquid Glass, iOS 26, iPadOS 26, macOS Tahoe 26, watchOS 26, visionOS 26, tvOS 26, nové funkce Apple Intelligence, …
Organizátoři konference LinuxDays 2025, jež proběhne o víkendu 4. a 5. října 2025 v Praze na FIT ČVUT, spustili přihlašování přednášek (do 31. srpna) a sběr námětů na zlepšení.
Po roce byla vydána nová stabilní verze 25.6.0 svobodného multiplatformního multimediálního přehrávače SMPlayer (Wikipedie).
DNS4EU, tj. evropská infrastruktura služeb DNS založená na vysoce federovaném a distribuovaném ochranném ekosystému, byla spuštěna v testovacím režimu [𝕏]. Na výběr je 5 možností filtrování DNS.
Skriptovací programovací jazyk PHP (PHP: Hypertext Preprocessor, původně Personal Home Page) dnes slaví 30 let. Přesně před třiceti lety, 8. června 1995, oznámil Rasmus Lerdorf vydání PHP Tools (Personal Home Page Tools) verze 1.0.
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.