V sobotu 1. června lze navštívit Maker Faire Ostrava, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Webový server Caddy (Wikipedie) s celou řadou zajímavých vlastností byl vydán ve verzi 2.8 (𝕏). Přehled novinek na GitHubu.
Byla vydána verze 3.0 (@, 𝕏) svobodného softwaru HAProxy (The Reliable, High Performance TCP/HTTP Load Balancer; Wikipedie) řešícího vysokou dostupnost, vyvažování zátěže a reverzní proxy. Detailní přehled novinek v příspěvku na blogu společnosti HAProxy Technologies.
Společnost Framework Computer představila novou vylepšenou verzi svého modulárního notebooku Framework Laptop 13 s Intel Core Ultra Series 1, displej s lepším rozlišením a novou webovou kameru. Přímo do Česka jej zatím koupit nelze.
Byla vydána nová verze 2.16 svobodného video editoru Flowblade (GitHub, Wikipedie). Přehled novinek v poznámkách k vydání. Videoukázky funkcí Flowblade na Vimeu. Instalovat lze také z Flathubu.
TerminalTextEffects (TTE) je engine pro vizuální efekty v terminálu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Od čtvrtka 30. 5. do soboty 1. 6. lze v Praze navštívit Veletrh vědy, tj. největší populárně naučnou akci v České republice, kterou každoročně od roku 2015 pořádá Akademie věd ČR. Vstup zdarma.
Canonical představil Ubuntu optimalizované pro jednodeskový počítač s RISC-V procesorem Milk-V Mars.
Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu optimalizovaná pro jednodeskové počítače na platformě ARM a RISC-V, ke stažení ale také pro Intel a AMD, byl vydán ve verzi 24.5.1 Havier. Přehled novinek v Changelogu.
Společnost xAI založena Elonem Muskem a stojící za AI LLM modelem Grok získala investici 6 miliard dolarů.
Po včerejším díle je dnes na pořadu následující: KVM s LVM, btrfs a 9pfs – KVM hosté s X11 a systemd-user – slepé uličky s grafikou v KVM. Zakončení zítra.
Ústup začal zkouknutím řady Star Treků, aby se mi uvolnilo místo na desktopu. Pak jsem si prakticky ověřil, že btrfs jde zmenšit, zkopíroval ho na Hikari a na Maboroshi vytvořil LVM. Škatulata hejbejte se zase zpátky a útok pokračuje.
Když máme konečně blokové zařízení (LVM), které můžeme KVM hostovi předat, je třeba zajistit správná práva. Zde nastupuje UDEV (a ještě speciálně pro LVM):
# zjištění identifikátoru DM_UUID logického svazku LVM udevadm info -q all /dev/maboroshi_ssd_lvm/kanashimi # /etc/udev/rules.d/10-lvm-kvm.rules ENV{DM_UUID}=="LVM-coy5HiEulYOchdjcqNqICAL2eRkx1UARaUWmyqlSAQcphdxa3ZLBU5ZMlfiJQCUw", OWNER="qemu-kanashimi" ENV{DM_UUID}=="LVM-coy5HiEulYOchdjcqNqICAL2eRkx1UARCSidTziWvNwadexP3pJ2YjfLYHL40L7o", OWNER="qemu-makoto" # pro ověření, zda je pravidlo napsané správně udevadm trigger
Příslušné zařízení se pak KVM hostovi předá takto:
-drive file=/dev/maboroshi_ssd_lvm/makoto,index=0,media=disk,if=virtio
Pro /boot
pak jde použít
přes 9pfs nasdílený btrfs pododdíl.
V tomto případě jsem na problémy nenarazil, nižší výkon na /boot
nevadí a
v případě těch tří souborů od jádra, co tam jsou, se zřejmě nepoužívají takové záludnosti jako jinde
na /
.
Nejprve příprava na Maboroshi:
mount /dev/maboroshi_ssd_lvm/btrfs /mnt/maboroshi/ cd /mnt/maboroshi btrfs subvol create makoto_boot # /etc/fstab LABEL=maboroshi_ssd_btrfs /home/qemu-makoto/boot btrfs rw,noatime,ssd,space_cache,subvol=makoto_boot0 0
Nasdílení přes 9pfs KVM hostovi (opět finální stav na Makoto):
-virtfs local,id=p9fs1,path=/home/qemu-makoto/boot,security_model=mapped,mount_tag=makoto_9p_boot
A připojení nasdíleného svazku na KVM hostovi:
# z ruky mount -t 9p -o trans=virtio makoto_9p_boot /boot -oversion=9p2000.L # /etc/fstab makoto_9p_boot /boot 9p rw,noatime,sync,dirsync,trans=virtio,version=9p2000.L 0 0
KVM hosta pak lze bootovat přímo. Předání příslušných parametrů (finální stav na Makoto):
-kernel "/home/qemu-makoto/boot/vmlinuz-linux" -initrd "/home/qemu-makoto/boot/initramfs-linux.img" -append "root=/dev/disk/by-label/makoto_ssd_btrfs rootflags=subvol=makoto_root rw quiet systemd.unit=multi-user.target"
Jak vyřešit spouštění KVM hostů při startu systému? Máme přece ten systemd… A když chceme, aby běžely pod běžným uživatelem? Máme přece ten systemd --user… No ale my jim potřebujeme pustit i X11… Máme přece tu aktivaci služeb na vyžádání… i X11 budou.
Aby fungoval systemd
--user
, musí být buď uživatel přihlášen, nebo se musí povolit automatické spouštění
uživatelské instance systemd (což je to, co chceme):
loginctl enable-linger qemu-kanashimi loginctl enable-linger qemu-makoto
Dále je potřeba nějaká ta konfigurace. Grafické aplikace mohou chtít D-Bus (nejsem si ale teď už jistý, zda je to i případ KVM):
# /etc/systemd/user/dbus.service [Unit] Description=D-Bus Message Bus Requires=dbus.socket [Service] ExecStart=/usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation ExecReload=/usr/bin/dbus-send --print-reply --session --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig # /etc/systemd/user/dbus.socket [Unit] Description=D-Bus Message Bus Socket Before=sockets.target [Socket] ListenStream=%t/dbus/user_bus_socket [Install] WantedBy=default.target # Aktivace jako root systemctl --global enable dbus.socket # Nastavení proměnné prostředí # /etc/systemd/system/user@.service.d/dbus.conf [Service] Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/dbus/user_bus_socket
Grafické aplikace ale určitě budou chtít X11. Od verze 1.16 lze sice X11 pouštět s uživatelským oprávněním, má to ale háček: musí to být v rámci sezení, tedy po přihlášení uživatele. Jako by tedy X11 tuto fíčurku neměl:
# Povolení spouštění X11 pod rootem jako dřív # /etc/X11/Xwrapper.config allowed_users=anybody needs_root_rights=yes # /home/qemu-kanashimi/.config/systemd/user/xorg@.service [Unit] Description=Xorg server at display %i Requires=xorg@%i.socket After=xorg@%i.socket [Service] Type=simple SuccessExitStatus=0 1 ExecStart=/usr/bin/Xorg :%i -nolisten tcp -noreset -verbose 2 "vt7" # /home/qemu-kanashimi/.config/systemd/user/xorg@.socket [Unit] Description=Socket for xorg at display %i [Socket] ListenStream=/tmp/.X11-unix/X%i # Ještě jedna proměnná prostředí #/etc/systemd/system/user@.service.d/display.conf [Service] Environment=DISPLAY=:0 # Povolení aktivace X11 přes systemd --user socket systemctl --user enable xorg@0.socket
Spuštění grafické aplikace pod daným uživatelem teď pustí X11 na terminálu 7 a tam pustí danou aplikaci.
Když už se pouští X11 pro uživatele qemu-kanashimi
na vyžádání, zbývá vytvořit
unit
soubor pro virtuál (jeden ze stavů, kam jsem se dopracoval):
# /home/qemu-kanashimi/.config/systemd/user/qemu-kanashimi.service [Unit] Description=QEMU virtual kanashimi After=xorg@0.socket Requires=xorg@0.socket [Service] Environment="QEMU_AUDIO_DRV=alsa" ExecStart=/usr/bin/env qemu-system-x86_64 -name kanashimi \ -enable-kvm -m 2048 -cpu host -smp 2 -soundhw ac97 -vga vmware \ -device virtio-net-pci,netdev=net2,mac=52:54:00:12:34:00 \ -netdev type=tap,id=net2,ifname=tap1,script=no,downscript=no \ -drive file=/dev/maboroshi_ssd_lvm/kanashimi,index=0,media=disk,if=virtio \ -virtfs local,id=p9fs1,path=%h/boot,security_model=mapped,mount_tag=kanashimi_9p_boot \ -monitor unix:%h/kvm-kanashimi.sock,server,nowait \ -kernel "%h/boot/vmlinuz-linux" -initrd "%h/boot/initramfs-linux.img" \ -append "root=/dev/disk/by-label/kanashimi_ssd_btrfs rootflags=subvol=kanashimi_root rw quiet systemd.unit=graphical.target" #-drive media=cdrom,file=%h/archlinux-2014.09.03-dual.iso,readonly,index=1 ExecStop=/bin/sh -c "echo 'system_powerdown' | unixterm %h/kvm-kanashimi.sock" TimeoutStopSec=30 KillMode=none [Install] WantedBy=default.target # A službu povolit systemctl --user enable qemu-kanashimi.service
Tato kapitola obsahuje asi nejvíc nahromaděné frustrace… Máme tedy nainstalovaný a
nakonfigurovaný lehký virtuální Arch s Xfce (Shin-Kanashimi), který se spouští pod svým
neprivilegovaným uživatelem pomocí systemd --user
, dokonce si pustí X11 na VT7…
až potud sluníčkové. Jenže… Ukázalo se, že to má několik mušek a masařek:
QEMU_AUDIO_DRV
a
přepínač -soundhw ac97
.Tragický výkon s přepínačem -vga=std
jsem očekával, tedy jen pro úplnost ve výčtu:
hýbání s okýnky je slide-show.
Zde jsem měl ještě nějaké naděje. Přepínač -vga=vmware
potřebuje mít na
straně hosta nainstalované a použité správné ovladače: xf86-video-vmware
a
xf86-input-vmmouse
z [extra]
. Hýbávní s okýnky už není slide-show,
jupí!
Jde se testovat! Dokonce to zvládá plynule přehrát mp3 v mplayeru, ovšem nesmí se při tom hejbat s okýnkama. Tak ještě nějaké video… Potíže začaly už na youtube, ale říkal jsem si, že to bude těmi blbými flashi, které by se měly zakázat. Staré čb nahrávky Peter, Paul and Mary se ještě držely, ale něco novějšího, barevného s Dylanem už to nevydýchalo. Star Trek TNG v avíčku bylo hodně pomalé slide-show a z Naruta v 720px emkávéčku byl vidět jen první snímek…
TO JE MARNÝ!
Zde už jsem si naděje nedělal. Pro
zprovoznění SPICE je potřeba na straně hosta
ovladač xf86-video-qxl
a agent spice-vdagent
z AURu. Na hostiteli
pak musí být klient (balíček spice
) a pro spouštění při startu se pak upraví
systemd unity. Povoluje se pak uživatelská služba spice-client.service
, která
závisí na vlastní službě pro virtuálního hosta:
#/home/qemu-kanashimi/.config/systemd/user/spice-client.service [Unit] Description=Spice client for virtual kanashimi Wants=qemu-kanashimi.service After=qemu-kanashimi.service After=xorg@0.socket Requires=xorg@0.socket [Service] ExecStart=/usr/bin/env spicec -h 127.0.0.1 -p 5930 [Install] WantedBy=default.target #/home/qemu-kanashimi/.config/systemd/user/qemu-kanashimi-spice.service [Unit] Description=QEMU virtual kanashimi [Service] Environment="QEMU_AUDIO_DRV=alsa" ExecStart=/usr/bin/env qemu-system-x86_64 -name kanashimi \ -enable-kvm -m 2048 -cpu host -smp 2 -soundhw ac97 \ -vga qxl -spice port=5930,disable-ticketing \ -device virtio-serial-pci -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 -chardev spicevmc,id=spicechannel0,name=vdagent \ -device virtio-net-pci,netdev=net2,mac=52:54:00:12:34:00 \ -netdev type=tap,id=net2,ifname=tap1,script=no,downscript=no \ -drive file=/dev/maboroshi_ssd_lvm/kanashimi,index=0,media=disk,if=virtio \ -virtfs local,id=p9fs1,path=%h/boot,security_model=mapped,mount_tag=kanashimi_9p_boot \ -monitor unix:%h/kvm-kanashimi.sock,server,nowait \ -kernel "%h/boot/vmlinuz-linux" -initrd "%h/boot/initramfs-linux.img" \ -append "root=/dev/disk/by-label/kanashimi_ssd_btrfs rootflags=subvol=kanashimi_root rw quiet systemd.unit=graphical.target" #-drive media=cdrom,file=%h/archlinux-2014.09.03-dual.iso,readonly,index=1 ExecStop=/bin/sh -c "echo 'system_powerdown' | unixterm %h/kvm-kanashimi.sock" TimeoutStopSec=30 KillMode=none [Install] WantedBy=default.target
Tato konfigurace fungovala v tom smyslu, že se povedlo spustit Shin-Kanashimi, ovšem
co se týče grafiky, bylo to ještě tragičtější, než s -vga=vmware
.
TO JE VÁŽNĚ MARNÝ!
Přes KVM hosty s grafickým prostředím tedy zřejmě cesta nepovede. Nastal čas pro další taktický ústup.
Tiskni Sdílej:
Tady je krátký záznam na gigabit síti přes ssh tunel na testovací CentOS mašinu, client je spuštěn takto:
xtightvncviewer -compresslevel 9 -quality 9 -encodings Tight -owncmap …
Ale je to jen 1024×768…
A co starý dobrý X protokol tunelovaný přes SSH? Vím, v rámci localhostu to zní hrozně, ale kupodivu to funguje. Používám to hlavně na různé experimenty a blbnutí – teď jsem si třeba zkusil zahrát Nexuiz a šlo to v pohodě.
v tom pripade mas neco spatne v lokalni siti
hraval jsem Freeciv na 5 kompech z jednocho a Xservery na win95 na 10 mbit siti a bez problemu ,
stejne jako pres 10mbit instaluji gfx instalatorem pres ssh servery v DE z prahy a no problem, nepoznas to od lolkalni app