Byla vydána (𝕏) listopadová aktualizace aneb nová verze 1.96 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.96 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
OpenMandriva ROME, tj. průběžně aktualizovaná (rolling) edice linuxové distribuce OpenMandriva, byla vydána ve verzi 24.12.
U příležitosti oslav sedmi let prací na debianím balíčku vyšlo GPXSee 13.33. Nová verze přináší rychlejší vykreslování vektorových map a vylepšení/doladění nového stylu pro OpenAndroMaps/Mapsforge mapy. Kdo by rád OSM mapy v "prémiovém" barevném schématu a nechce čekat až nová verze dorazí do jeho distribuce, nalezne zdrojové kódy na GitHubu.
Tým Google Quantum AI představil kvantový čip Willow se 105 qubity.
Byla vydána nová verze 257 správce systému a služeb systemd (GitHub).
RPCS3 (Wikipedie), tj. open source emulátor Sony PlayStation 3, nově oficiálně běží také na architektuře arm64. Podporován je Apple Silicon (YouTube) je i Raspberry Pi 5 (YouTube).
Jaký byl rok 2024 ve vyhledávání Googlu? Mistrovství světa v hokeji, triumf Davida Pastrňáka, Robert Fico nebo loučení s herečkou Simonou Postlerovou. To jsou některá z témat, která letos nejvíce rezonovala ve vyhledávání na Googlu. Češi s velkým zájmem zjišťovali, proč je přestupný rok, a s podobnou intenzitou hledali důvod absence Zdeňka Chlopčíka ve StarDance. Kompletní žebříčky včetně globálních a další zajímavosti.
Chatbot Grok AI je nově pro uživatele sítě 𝕏 zdarma (návod). S omezením 10 zpráv za dvě hodiny a tři obrázky za den.
GNU Shepherd (Wikipedie) dospěl do verze 1.0.0. Po 21 letech. Jedná se o init systém a správce služeb napsaný v Guile Scheme. Původně se jmenoval GNU dmd (Daemon managing Daemons). Používá se v systému GNU Guix.
GNUnet (Wikipedie) byl vydán v nové major verzi 0.23.0. Jedná se o framework pro decentralizované peer-to-peer síťování, na kterém je postavena řada aplikací.
Zdravim,
bezi mi samba na debianu, a tvari se jako dva sitove disky, pro jednoduchost rekneme A a B.
Mam tam dve sitovky a potreboval bych kvuli rychlosti aby se na disk A pristupovalo pres ip eth3
a na disk B pres ip eth4. V etc/network/interfaces mam tohle:
iface eth3 inet static
network 192.168.11.0
netmask 255.255.255.0
address 192.168.11.220
gateway 192.168.11.1
broadcast 192.168.11.255
iface eth4 inet static
network 192.168.11.0
netmask 255.255.255.0
address 192.168.11.221
#gateway 192.168.11.1
broadcast 192.168.11.255
problem je ze porad jedou oba A i B pres eth3 (bez ohledu na # pred gateway). Tzn kdyz si pripojim
sitovy disk s ip 11.221 (coz by melo byt eth4) tak to funguje jen kdyz je pripojeny kabel k eth3 a jede to pres nej.
Pres eth4 nejspis nic nejede, kdyz ho odpojim nema to na nic vliv. Firewall tam neni, policy na ACCEPT.
Je nejaka finta jak to udelat funkcni, tzn. aby sitovy disk na .11.220 sel pres eth3 a .11.221 pres eth4?
Nebude problem ze u obou je stejna network? ip 192.168.11.1 je router v te siti.
Vsem dik za napady..
Co skusit spustit 2 instance(konfigurace)samby, kazdou na jinem rozhrani pres:
[global] interfaces = eth3
A v kazde instanci odkazovat na jiny disk?
NN
to zni dobre, nicmene tohle je problem spis systemu nez samby, to co jsem psal plati i pro ping - tzn kdyz jede ping na ip .11.221 (eth4)
a vytahnu kabel z eth3 tak uz si nepingnu ani tu 11.221. Uprimne receno bych cekal ze se ten system bude chovat naopak
tzn ze pres obe sitovky si pingnu libovolnou adresu (a pak by tohle bylo reseni), ale bohuzel to tak neni.
net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.eth3.arp_ignore=1
net.ipv4.conf.eth4.arp_ignore=1
net.ipv4.conf.all.arp_announce=2
net.ipv4.conf.eth3.arp_announce=2
net.ipv4.conf.eth4.arp_announce=2
>Route
vypise tohle:Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.20.8 * 255.255.255.252 U 0 0 0 eth0
192.168.21.8 * 255.255.255.252 U 0 0 0 eth1
192.168.11.0 * 255.255.255.0 U 0 0 0 eth4
192.168.11.0 * 255.255.255.0 U 0 0 0 eth3
default my.router 0.0.0.0 UG 0 0 0 eth3
default my.router 0.0.0.0 UG 0 0 0 eth4
a >ip route show table local scope host
local 192.168.20.10 dev eth0 proto kernel src 192.168.20.10
local 192.168.11.221 dev eth4 proto kernel src 192.168.11.221
local 192.168.11.220 dev eth3 proto kernel src 192.168.11.220
local 192.168.21.10 dev eth1 proto kernel src 192.168.21.10
local 127.0.0.1 dev lo proto kernel src 127.0.0.1
local 127.0.0.0/8 dev lo proto kernel src 127.0.0.1
a >ip route show table local
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
broadcast 192.168.11.0 dev eth4 proto kernel scope link src 192.168.11.221
broadcast 192.168.11.0 dev eth3 proto kernel scope link src 192.168.11.220
broadcast 192.168.20.8 dev eth0 proto kernel scope link src 192.168.20.10
local 192.168.20.10 dev eth0 proto kernel scope host src 192.168.20.10
broadcast 192.168.20.11 dev eth0 proto kernel scope link src 192.168.20.10
local 192.168.11.221 dev eth4 proto kernel scope host src 192.168.11.221
local 192.168.11.220 dev eth3 proto kernel scope host src 192.168.11.220
broadcast 192.168.11.255 dev eth4 proto kernel scope link src 192.168.11.221
broadcast 192.168.11.255 dev eth3 proto kernel scope link src 192.168.11.220
broadcast 192.168.21.8 dev eth1 proto kernel scope link src 192.168.21.10
local 192.168.21.10 dev eth1 proto kernel scope host src 192.168.21.10
broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1
broadcast 192.168.21.11 dev eth1 proto kernel scope link src 192.168.21.10
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
x.
ok, jeden default smazu, ale mel jsem za to ze routovaci pravidla v local s konkretni ip (tedy .11.220 a .11.221) by to mely odfiltrovat drive nez default. Princip myslim ze matne ale chapu, ale je tam nekde nejaky hacek ktery nemuzu najit. Uprimne receno me trochu prekvapuje proc to nejde, myslel jsem si ze proste budou 2 rozhrani s 2 ip, kazda prijme to co ji je urceny a taky sama odpovi.. jde o to ze to budou 2 sitovy disky, na ktery se budou pripojovat ruzny klienti z toho rozsahu a tak nemuzu natvrdo urcit odchozi ip.. chtelo by to nejaky pravidlo ze to co na sitovku prijde po ni taky odejde a ne po jiny.. co sem tak cet o nastavovani ARP tak to vypadalo nadejne ze to je ono ale furt no neni funkcni.. a takovy masakry jako arp flux jsem radsi preskocil a doufam ze to pujde nejak jednoduseji :)
Pro tuto situaci je podle mého nejvhodnější ty dvě síťovky hodit do etherchannelu (Cisco terminologie), respektive bondingu (Linux terminologie). To je technologicky nejlepší způsob, jak řešit vámi požadované výkonnostní zlepšení.
Toto chování podporuje snad každý (managovatelný nebo smart) switch, se kterým jsem se kdy potkal, včetně modelů za pár stovek. Třeba tomu říkají "port group" nebo ještě nějak jinak, ale určitě to půjde nastavit.
Řešit to na L3, tak jak se o to snažíte, bude asi docela opruz a hlavně to prostě není "ta správná cesta".
Kdybys chtěl si hrát s vrrp, tak vidim v linuxu možná dvě implementace ... http://www.ucarp.org a http://www.keepalived.org/. Takže by šlo udělat dvě vrrp skupiny, každou s primárem na jedný síťovce. Jinak jan na L3 jednoduše nevim. No, možná udělat dva subnety, na každé síťovce jeden.
Tiskni Sdílej: