Byla vydána nová verze 260 správce systému a služeb systemd (Wikipedie, GitHub). Odstraněna byla podpora skriptů System V. Aktualizovány byly závislosti. Minimální verze Linuxu z 5.4 na 5.10, OpenSSL z 1.1.0 na 3.0.0, Pythonu z 3.7.0 na 3.9.0…
Byla vydána nová verze 5.1 svobodného 3D softwaru Blender. Přehled novinek i s náhledy a videi v poznámkách k vydání. Videopředstavení na YouTube.
Bylo oznámeno vydání nové verze 8.1 "Hoare" kolekce svobodného softwaru umožňujícího nahrávání, konverzi a streamovaní digitálního zvuku a obrazu FFmpeg (Wikipedie). Doprovodný příspěvek na blogu Khronosu rozebírá kódování a dekódování videa pomocí Vulkan Compute Shaders v FFmpeg.
Byl představen open-source a open-hardware prototyp nízkonákladového raketometu kategorie MANPADS, který byl sestaven z běžně dostupné elektroniky a komponent vytištěných na 3D tiskárně. Raketa využívá skládací stabilizační křidélka a canardovou stabilizaci aktivně řízenou palubním letovým počítačem ESP32, vybaveným inerciální měřicí jednotkou MPU6050 (gyroskop a akcelerometr). Přenosné odpalovací zařízení obsahuje GPS,
… více »Vědci z univerzity La Sapienza v Římě vyvinuli systém, který dokáže identifikovat jednotlivce pouze na základě toho, jak narušují signály Wi-Fi. Autoři tuto novou technologii nazvali WhoFi. Na rozdíl od tradičních biometrických systémů, jako jsou skenery otisků prstů a rozpoznávání obličeje, nevyžaduje tato metoda přímý fyzický kontakt ani vizuální vstupy. WhoFi může také sledovat jednotlivce na větší ploše než kamera s pevnou polohou; stačí, je-li k dispozici Wi-Fi síť.
SuperTux (Wikipedie), tj. klasická 2D plošinovka inspirovaná sérií Super Mario, byl vydán v nové verzi 0.7.0. Videoukázka na YouTube. Hrát lze i ve webovém prohlížeči.
Ageless Linux je linuxová distribuce vytvořená jako politický protest proti kalifornskému zákonu o věkovém ověřování uživatelů na úrovni OS (AB 1043). Kromě běžného instalačního obrazu je k dispozici i konverzní skript, který kompatibilní systém označí za Ageless Linux a levné jednodeskové počítače v ceně 12$ s předinstalovaným Ageless Linuxem, které se chystají autoři projektu dávat dětem. Ageless Linux je registrován jako operační
… více »PimpMyGRC upravuje vzhled toolkitu GNU Radio a přidává alternativní barevná témata. Primárním cílem autora bylo pouze vytvořit tmavé prostředí vhodné pro noční práci, nicméně k dispozici je nakonec celá škála barevných schémat včetně možností různých animací a vizuálních efektů (plameny, matrix, bubliny...), které nepochybně posunou uživatelský zážitek na zcela jinou úroveň. Témata jsou skripty v jazyce Python, které nahrazují
… více »GIMP 3.2 byl oficiálně vydán (Mastodon, 𝕏). Přehled novinek v poznámkách k vydání.
FRANK OS je open-source operační systém pro mikrokontrolér RP2350 (s FRANK M2 board) postavený na FreeRTOS, který přetváří tento levný čip na plně funkční počítač s desktopovým uživatelským rozhraním ve stylu Windows 95 se správcem oken, terminálem, prohlížečem souborů a knihovnou aplikací, ovládaný PS/2 myší a klávesnicí, s DVI video výstupem. Otázkou zůstává, zda by 520 KB SRAM stačilo každému 😅.
Dobry vecer,
prosim, poradte, jestli to, co se snazim udelat, je vubec mozne.
PC s Ubuntu 22 LTS ma nekolik sitovek, vsechny jsou pres PCI passthrough vecpane do virtualky s pfSense. Vedle pfSense na stejne masine bezi jeste dalsi VM.
pfSense (VM1)
WAN (em1, PCI passthrough)
LAN0,1,2,3 (em2-5, PCI passthrough), sdruzene do bridge
OPT (vmnet0, virtio sitovka z hypervisoru, vnet1 na strane hosta.. ale kam ji pichnout?)
^ pfSense je nastaven dobre, u fyzickych rozhrani vse funguje, routuje, vsechno slunickove.
CentOS (VM2)
eth0 na strane VM, vnet2 na strane hosta
Ubuntu (host)
Predstava spravneho nastaveni je, ze udelam bridge, do nej vecpu vnet1, vnet2 a nejaky virtualni interface (rikejme mu treba tun0) a vsechno bude standardne fungovat jako u rozhrani fyzickych. Jenze tomu tak neni.
Co jsem zkousel: pripojit obe VM v ruznem rezimu k hostu pres virtual networks pres virt-manager GUI, postupne vsechny 4 rezimy. Nejblize uspechu jsem byl, kdy fungovalo aspon spojeni pfSense VM > host, fungovalo dokonce i host > pfSense. Nefungovalo vsak: LAN (preroutovano na pfSense) > host (prestoze wireshark pusteny na Ubuntu ukazoval prichozi ICMP, odpoved nikdy neprisla, vypnuti FW zadnej rozdil... )
No a definitivne to rozbil zasah do pripojeni vytvoreneho libvirtem ze strany NetworkManageru, kdy jsem se z nej snazil udelat default gateway... Takze pres defaultne nabizene virtual networks zrejme cesta nevede, nakolik to neumoznuje nastavit defaultni vibr jako vychozi branu. OK, chapu, neni to uplne bezny use case.
Zkousim ted laborovat s bridgem na hostu vytvorenym pres NetworkManager, ale taky bez uspechu. Vytvorim bridge, dam do nej vmnet1 a vmnet2 jako slaves, overim, ze vNIC u obou VM je nastaveny na pripojeni do tohoto bridge a.... Host unreachable, ARP prazdny, nic, nada. A to porad jeste nejsem v bode, kdy bych do toho bridge chtel pridat i nejaky (tun?) adapter z hosta...
Tak si rikam, jestli to, ceho chci docilit, je vubec mozne? Nebo muze cesta vest pres OpenVSwitch?
Diky za napady.
Tak si rikam, jestli to, ceho chci docilit, je vubec mozne?Ceho chces docilit? Z textu jsem pochopil, ze mas dva virtualy na Ubuntu.
Tak jsem to mozna napsal nesrozumitelne, pardon.
Snazim se docilit toho, aby VM1, host i VM2 mohly komunikovat bez omezeni.
Pokud by se melo jednat o fyzicke sitovky, vytvorim nad nimi bridge a vse by fungovalo dle ocekavani.
Jenze u virtualnich sitovek mi to pri stejnem postupu, ale vlastne jen s jinymi nazvy interfacu, nefunguje.
Pro jednodussi ladeni uvedu jako priklad spojeni mezi CentOS VM a hostem (Ubuntu).
Na Ubuntu vytvorim bridge pres nmcli, dam mu nejakou ipv4 a pojmenuju treba virt_br.
ve vlastnostech VM CentOS dam vNIC nastaveni tak, at pouzije virt_br jako bridge
Startuju CentOS, nastavim ipv4 ze stejneho rozsahu, cajk.
Na Ubuntu spusteny prikaz pro overeni, ze je vse ok:
brctl show
ukaze vnet1 jako slave pod virt_br, v poradku a melo by to fungovat, zejo?
Jenze. Pustim ping z CentOS na adresu bridge, vse timeout.
Wireshark pusteny na interface bridge vidi prichozi ICMP a upozornuje, ze neni reply. Nicmene... ty pakety prisly.
ARP zaznam na strane CentOS VM se objevi.
Pustim ping opacnym smerem, z Ubuntu na adresu CentOS VM. Vse konci na host unreachable, Wireshark bezici na hostu ukazuje ARP dotazy, avsak bez odpovedi.
Cili pakety mezi hostem a CentOS VM prolezou jen jednim smerem, a jeste k tomu nejak divne polovicate, jako kdyby je mel pozrat firewall. Opacnym smerem pak neprojde vubec nic a ARP ani nezjisti, kam to ma vlastne poslat.
Diky za tip.
Defaultne ve vypisu sysctl -a tyto polozky vubec nevidim:
net.bridge.bridge-nf-call-ip6tables
net.bridge.bridge-nf-call-iptables
net.bridge.bridge-nf-call-arptables
Po spusteni:
modprobe br_netfilter
mi sysctl tyto hodnoty zobrazil, prenastavil jsem je na 0, avsak zmenu to neprineslo.
Dobry den
Takhle se to muze chovat, kdyz jsou nastavene nekonzistentne masky siti(jeden stroj si mysli, ze jsou na stejne siti, druhy je jineho nazoru).
marekUznavam, ze jsem s tim otravny, ale nespustil byste prosim na hostu prikaz:
ip route get ADRESA_QUESTA
A na questu prikaz:
ip route get ADRESA_HOSTA
a odpoved ukazal?
dekuji
marekDobry vecer,
v pohode, vazim si kazde snahy pomoci!
Masky podsite jsou uvedeny spravne, vsude /24, preklep jsem tam neudelal.
Adresy pro virt_br (na strane Ubuntu) i na strane VM (CentOS) jsou nastaveny rucne:
virt_br na hostu ma 192.168.122.254/24
eth0 (viditelny na hostu jako vnet0) ma 192.168.122.97/24, opet, rucni konfigurace.
Na ubuntu spusteno:
ip route get 192.168.122.97
192.168.122.97 dev virt_br src 192.168.122.254 uid 0
cache
Na centOS:
ip route get 192.168.122.254
192.168.122.254 dev eth0 src 192.168.122.97
cache
To dle meho vypada taky spravne.
Jdu jeste prubnout pridani fyzickeho rozhrani do tohoto bridge...
Kdysi jsem zazil, ze bridge byl up, ale jeden z portu byl down, pak se to chovalo divne...ale to bylo nekdy v pocatcich nm.
Doporucil bych spustit tcpdump na bridge, portu a questu a navzajem porovnat.
Dale bych zkusil bridge fdb show, jestli se alespon nauci forwardovat.
Provozuji vpodstate stejny setup a vse mi funguje bez fyzickeho rozhrani.
Vse jsem nastavoval pomoci nmtui a virt-manager, nikde jsem nenastavoval zadny spek...
Po restartu hosta se nastavi bridge a startujici quest se do nej pripoji.
Pote je mozne mezi hostem a questem po siti komunikovat.
marekNo, tak s pridanim fyzickeho rozhrani do bridge jsem si nepomohl, tak jsem z toho jelen.
Pravda, srovnat tcpdump primo na bridgi a na vnetx mne nenapadlo... Budu tedka par dni mimo, pristi tyden to omrknu, diky!
Nicmene videl bych to jeste na rozjeti druhe fyzicke masiny s cistym Ubuntu, novym pokusem a srovnavanim configu, to prece neni mozny totok... tuplem, kdz vam to jede.
Skús pozrieť tento blog. Potom je tu dokumentácia priamo na QEMU, kde si môžeš pozrieť príklad konfigurácie. Najdi si časť kde sa píše o bridge. Tam máš stručný popis ako dosiahneš sieťový most.
Myslím, že tento scenár asi nebude možné naklikať a môže do toho zasahovať networkmanager.
Vsechno sedi, vytvoreni bridge, poveseni VM na bridge, kontrola XMLka pro danou VM, overeni pres brctl show.
Jedine, co mne zarazi, je zminka:
Limitations
The libvirt server must be connected to the LAN via Ethernet. If it is connected wirelessly, a Routed network or NAT-based network are the only options.
Coz je ale dale vysvetleno tak, ze se to tyka spise Wi-Fi a toho, jak se zpracovavaji framy...
Bridging with a wireless NIC
Just like you can bridge two wired ethernet interfaces, you can bridge between an ethernet interface and a wireless interface. However, most Access Points (APs) will reject frames that have a source address that didn’t authenticate with the AP. Since Linux does ethernet bridging transparently (doesn’t modify outgoing or incoming frames), we have to set up some rules to do this with a program called ebtables.
Schvalne teda zitra prubnu, jestli to nahodou kouzelne nezacne fungovat pote, co do bridge pridam jednu fyzickou sitovku.
OK, tak uz jsem trosku moudrejsi, akorat stale ne dostatecne 
Wireshark na vnetx nebo primo na bridgi nedelal zadny rozdil, ale rikam si fajn, vsechno to rozbiju a pojedu znovu.
A dostal jsem se do celkem vtipne situace, opet, pres nmtui vytvoreny bridge br0 a VM povesene na dany bridge.
Tedka mi pro zmenu virtualky v bridgi pri startu pfSense, kdy pfSense zacne konfigurovat rozhrani, proste zmizi...
Z dmesg | grep br0 hypervisoru:
Spoustim CentOS VM:
br0: port 1(vnet0) entered blocking state
br0: port 1(vnet0) entered disabled state
br0: port 1(vnet0) entered blocking state
br0: port 1(vnet0) entered forwarding state
vsechno cajk dle ocekavani.
Spoustim pfSense VM:
br0: port 2(vnet1) entered blocking state
br0: port 2(vnet1) entered disabled state
br0: port 2(vnet1) entered blocking state
br0: port 2(vnet1) entered forwarding state
pfSense startuje a zacina nastavovat interfacy, mezitim v dmesg:
br0: port 1(vnet0) entered disabled state (mi to sestrelilo i sit z te CentOS VM?!)
br0: port 2(vnet1) entered disabled state (a tady to odstrihne i sebe; fyzicka rozhrani se na pfSense vsak bezi v poradku)
... a proste schluss.
Tak pro zmenu mudruju, proc se deje tady todle.
Loop tam nikde neni a chtelo by to fakt hodne kreativity jej dokazat vytvorit, takze STP je na tom bridgi neaktivni, nicmene jeho zapnuti na zkousku nemelo zadny vliv.
Ted uz ale mam aspon funkcni workaround. Po startu pfSense staci pustit
brctl addif br0 vnet0 vnet1
a najednou je vsechno azuro...
Tak prinejhorsim si holt udelam nejakej skript na autostart virtualek s pevnym cekanim dvou minut, nez porty do bridge rucne prida a bude, ale ... prece to musi mit nejakej duvod, ze se todle deje...?
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
