Upozornění pro uživatele Asahi Linuxu: Neaktualizujte macOS na verzi 27 Golden Gate! Apple změnil detekci spouštěcích oddílů. Po aktualizaci oddíl s Asahi Linuxem nevidí. Snad je to jenom chyba.
Na webu konference Den IPv6, která se konala 4. června v Národní technické knihovně v pražských Dejvicích, jsou nyní k dispozici všechny prezentace (v PDF) a jejich videozáznamy. Organizátory konference byly i letos sdružení CESNET, CZ.NIC a NIX.CZ.
Byla vydána nová verze 9.1.0 správce sbírky fotografií digiKam (Wikipedie). Přehled novinek i s náhledy v oficiálním oznámení (NEWS). Vypíchnout lze vylepšené vyhledávání nebo podporu Pixel Motion Photos. Nejnovější digiKam je ke stažení také jako balíček ve formátu AppImage. Stačí jej stáhnout, nastavit právo ke spuštění a spustit.
Přihlaste svou přednášku na další ročník konference LinuxDays, který proběhne 3. a 4. října na FIT ČVUT v pražských Dejvicích. Příjem témat poběží do konce prázdnin, pak proběhne veřejné hlasování a následně sestavení programu.
Byla vydána nová verze 2.4.68 svobodného multiplatformního webového serveru Apache (httpd). Řešeno je mimo jiné 13 zranitelností.
Apple na své vývojářské konferenci WWDC26 (Worldwide Developers Conference, keynote) představil řadu novinek. Vypíchnout lze novou generaci Apple Intelligence a zbrusu novou Siri, která dostala název Siri AI. Kvůli Aktu o digitálních trzích (DMA) však funkce Siri AI nebudou v systémech iOS 27 a iPadOS 27 k dispozici uživatelům v Evropské unii.
Byla vydána nová verze 1.18.0 distribučního frameworku Flatpak (Wikipedie), tj. technologie umožňující distribuovat aplikace v podobě jednoho instalačního souboru na různé linuxové distribuce a jejich různá vydání. Přehled novinek na GitHubu. Vypíchnout lze podporu rozhraní /dev/kfd pro výpočty na kartách AMD (AMDKFD).
aMule (Wikipedie), tj. multiplatformní klient pro peer-to-peer sdílení souborů pro sítě eD2k and Kademlia, byl po více než pěti letech od vydání poslední verze 2.3.3, vydán v nové major verzi 3.0.0 (GitHub). S novou webovou stránkou a dokumentací.
Byly vyhlášeni vítězové a zveřejněny vítězné zdrojové kódy (YouTube, GitHub) již 29. ročníku soutěže International Obfuscated C Code Contest (IOCCC), tj. soutěže o nejnepřehlednější (nejobfuskovanější) zdrojový kód v jazyce C.
Evropská komise předložila evropský balíček pro technologickou suverenitu, tedy soubor opatření, která mají posílit kapacity EU v oblasti polovodičů, umělé inteligence, cloudu a open source. To Evropě pomůže stát se lídrem v oblasti umělé inteligence, posílit její digitální autonomii a vytvářet podmínky pro udržitelnější digitální budoucnost.
Řešení dotazu:
172.16.X.0/24, což pak nekoliduje s firemními sítěmi 10.0.0.0/8, s switchovanými přípojkami do stejně adresovaných ISP sítí, ani běžnými 192.168.0.0/24 nebo 192.168.1.0/24. Když to nešlo jinak, tak jsem se z toho většinou vylhal samostatným routerem s NAT, co jsem měl po ruce.
Na virtuál bych se vykašlal, to je kanón na vrabce. Tohle by měl zvládnout jeden jediný patřičně nakonfigurovaný network namespace s veth spojem, což pak člověk rozběhne skriptem o pár příkazech.
Řešením je (jako obvykle) IPv6. Rozsah nemusí nutně být routovatelný směrem ven — koneckonců, u IPv4 může mít člověk taky na každém zařízení tolik adres a rozsahů, kolik jen chce, a nemusí je routovat mimo lokální síť. Zásadní rozdíl je v tom, že u IPv6 se dá zajistit, aby ten rozsah byl unikátní, tedy aby nebyl v konfliktu s žádným jiným rozsahem ve veřejném Internetu.
wlan0, wlan1, eth0.1, eth0.2, eth0.3, eth0.4.
Přes wlan zařízení mám vytvořený bridgě br-wlan a přes eth zařízení mám br-lan.
Teď má jeden bridge rozsah 10.0.1.0/24 a druhý 10.0.2.0/24. Routovní mezi těmito sítěmi (už) funguje. Broadcasty se z daných sítí níkdy nedoatnou ven, to chápu.
Chtěl jsem do jednoho subnetu(bridge) všechny zažízení, tj: wlan0, wlan1, eth0.1, eth0.2, eth0.3, eth0.4. Pak by byl rozsah ip adres třeba 10.0.0.0/22 a klienti na wlan* interfacech by dostávali od dhcp adresy 10.0.2.x a na eth.* interfacech by dostávali 10.0.2.x. Jen nevím, jestli jde dhcp serveru říci, kde má jaké adresy rozdávat.
Nevím jak tohodo dosáhnout, myslel jsem, že problém bude jen v konfiguraci dhcp serveru...
Dhcp server je dnsmasq.
Ne, to je z bláta do louže. Vždycky bude s nějakým IPv4 rozsahem v konfliktu. IPv6 rozsah bude světově unikátní, bez ohledu na to, do jakých dalších sítí a VPN bude routovat a bez ohledu na to, co si v budoucnu usmyslí poskytovatel. V tom byla celá pointa.
#!/bin/bash
# enable ipv4 forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward
# create a new network namespace
ip netns add ns1-modem
# move usb0 device to ns1-modem namespace
ip link set usb0 netns ns1-modem
# veth link
ip link add v-eth1 type veth peer name v-peer1
ip link set v-peer1 netns ns1-modem
# set ip address of v-eth1 in root namespace
ip addr add 172.20.172.2/24 dev v-eth1
# set ip address of v-peer1 in ns1-modem namespace
ip netns exec ns1-modem ip addr add 172.20.172.1/24 dev v-peer1
# set ip address of usb0 modem interface in ns1-modem namespace
ip netns exec ns1-modem ip addr add 192.168.1.2/24 dev usb0
# activate interfaces
ip link set v-eth1 up
ip netns exec ns1-modem ip link set lo up
ip netns exec ns1-modem ip link set usb0 up
ip netns exec ns1-modem ip link set v-peer1 up
# in namespace ns1-modem set default route via modem device and set NAT
ip netns exec ns1-modem ip route add default via 192.168.1.1 dev usb0
ip netns exec ns1-modem iptables -t nat -A POSTROUTING -s 172.20.172.0/24 -o usb0 -j MASQUERADE
# set default route of root ns
#ip route add default via 172.20.172.1 dev v-eth1 metric 210
Tiskni
Sdílej: