Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Nakonec jsem zápisek rozdělil, dnes tedy: Popis výchozí situace – Hardware – UEFI – Odemykání LUKS přes SSH – KVM síťování – KVM s btrfs a 9pfs. Pokračování zítra a pozítří.
Začalo to koncem září. To jsem se konečně dostal k prvnímu kroku dlouho zamýšlené akce – postavit si domácí servřík. Skončilo to koncem prosince (téhož roku). To jsem mohl první krok prohlásit za dokončený…
Běžel tu starý Kanashimi, který vedle své „hot-spot“ funkce de facto funkci jednoduchého serveru (torrent, CUPS, SSH, Squid pro balíčky) plnil. Jenže hardware byl zneužitý z téměř deset let starého desktopu, včetně tehdy skoro herní grafiky. Bylo to hlučné, žravé a vzniklo to postupnou evolucí a flikováním systému z 32bitového notebooku. Zejména po loňské koupi zrcadlovky se začaly objevovat úkoly, které by se na Kanashimi řešily blbě. Prostě by to chtělo vytvořit archiv fotek, nějak elegantně a řízeně ho nasdílet do zbytku domácí sítě a možná částečně i ven. Časem na to nabalit další služby.
Co tedy s tím?
Nakonec jsem se rozhodl pro variantu 3). Díky virtualizaci by se měl hardware využít efektivněji (výkon, spotřeba, prostor). Z nového hardwaru budou těžit i domácí uživatelé Kanashimi. A člověk si vyzkouší něco zajímavějšího než v ostatních variantách. Umístěním serveru na místo Kanashimi však bude tento na očích chronických vypínačů všeho blikajícího a běžícího (čti ostatních členů domácnosti). No snad se to podaří překonat domluvou…
Aby se to celé udělalo ještě zajímavější, rozhodl jsem se to celé rozdělit do několika fází:
Mělo by to být úsporné, rozumně výkonné, rozumně levné, prostě takové klasické protichůdné požadavky Virtualizace potřebuje alespoň základní podporu v procesoru. Protože používám diskové šifrování a SSH, hodila by hardwarová akcelerace AES. Poučen z minula politikou Intelu k procesorovým fíčurkám, koukal jsem rovnou po AMD. Jak tak teď koukám, tak se možná i u Intelu blýská na lepší časy.
Co jsem tedy vybral:
Nějakou dobu jsem hardware nekupoval, takže mě zejména ceny RAM nepříjemně zaskočily, jinak bych šel do 16 GB, ať je dost místa na kešky.
Zatímco složit skládačku a přendat ji do bedny od Kanashimi bylo „piece of cake“, při instalaci systémů a jejich nastavení jsem (oprávněně) očekával řadu výzev. Tyto se navíc ukázaly náročnější, než má pesimistická očekávání (ano, tento kognitivní bias nádherně funguje). Samozřejmě, všude bude Arch Linux.
Výchozí idea: Nabootuje to přes UEFI, půjde tomu odemknout LUKS přes síť, bude to používat btrfs (pododdíly a snapshoty), každý KVM host bude pod vlastním běžným uživatelem, KVM hosty budou moct na síť a budou dostupné ze sítě.
Deska má UEFI, UEFI znamená GPT, nebo legacy mód s MBR. Úkolem nebylo pouze to zprovoznit, ale také se něco naučit… Vzhledem k tomu, že konfigurace GRUB2 s GPT je poněkud specifičtější, rozhodl jsem se vyzkoušet EFIStub – když máte štěstí a přidáte správnou položku do UEFI menu, nabootujete systém bez klasického zavaděče.
Nejprve je potřeba vytvořit EFI oddíl (cca 512 MB FAT32) připojený jako /boot
:
# gdisk /dev/sda a typ oddílu EF00 # mkfs.fat -n UEFI-mab -F32 /dev/sda1 # /etc/fstab, genfstab se činí: LABEL=UEFI-mab /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 2
Z EFI CDčka (v mém případě flashky) Archu (při bootu je potřeba vybrat UEFI režim instalačního média) lze pak přidat příslušnou položku do EFI menu (zde již v podobě po všech peripetiích):
efibootmgr -d /dev/sdb -p 1 -c -L "Arch Linux GUI" -l /vmlinuz-linux -u "cryptdevice=/dev/disk/by-uuid/789f95ae-f182-4cab-a5c9-c11bb8c18455:maboroshi_ssd_luks root=/dev/maboroshi_ssd_lvm/btrfs rootflags=subvol=maboroshi_root rw initrd=/initramfs-linux.img ip=192.168.1.20::192.168.1.254:255.255.255.0::eth0:none net.ifnames=0 quiet init=/usr/lib/systemd/systemd systemd.unit=graphical.target"
Zádrhel v mém případě ovšem je, že se mi nedaří přidat do EFI více jak jednu vlastní položku.
Protože používám diskové šifrování (LUKS), hodilo by se, kdyby bylo možné odemknout
oddíly vzdáleně. Že to lze,
vím díky Bystroushaakovi.
V Archu (AURu) je to hezky pořešené,
takže není třeba provádět žádné velké harakiri. Stačí nainstalovat dropbear_initrd_encrypt
z AURu,
nahrát veřejný klíč do dropbearu, přidat ip
parametr do konfigurace
zavaděče (viz výše) a povolit háčky net
, dropbear
a encryptssh
v /etc/mkinitcpio.conf
(opět finální verze):
HOOKS="base udev autodetect modconf net block keymap consolefont keyboard dropbear encryptssh lvm2 btrfs filesystems fsck"
Pro odemčení oddílů pak stačí ssh root@maboroshi
– používají se systémové
klíče z OpenSSH, takže je i jistota, kam se člověk připojuje.
Instalace QEMU/KVM je pokrytá na Arch-WIKI.
Pro každého KVM hosta jsem založil vlastního uživatele qemu-kanashimi
a
qemu-makoto
a přidal je do skupiny kvm
. Tato skupina se už sice nepoužívá,
ale systemd dá odpovídající oprávnění jen přihlášeným uživatelům – tehdy jsem se ještě
nechtěl hrabat v UDEV pravidlech.
Protože nepůjde jen o virtuály na hraní, je potřeba vystavit je do sítě přes bridge. V Archu
používám na nastavení sítě netctl
, který staví na systemd. Pomocí něj lze spustit
jak samotný bridge, tak i virtuální síťovky pro KVM hosty (QEMU si sice umí nahodit virtuální
síťovky samo, ale to není čisté, navíc pak chce „nemístná“ oprávnění)
:
#/etc/netctl/bridge-maboroshi Description="Bridge connection for maboroshi and VMs" Interface=br0 Connection=bridge BindsToInterfaces=(eth0 tap0 tap1) IP=static Address=('192.168.1.20/24') Gateway='192.168.1.254' DNS=('192.168.1.254') #/etc/netctl/tap-makoto Description='Tap device for makoto' Interface=tap0 Connection=tuntap Mode='tap' User='qemu-makoto' #/etc/netctl/tap-kanashimi Description='Tap device for kanashimi' Interface=tap1 Connection=tuntap Mode='tap' User='qemu-kanashimi'
Příslušné zařízení se pak KVM hostovi předá takto (ještě že má Arch dobrá fóra):
-device virtio-net-pci,netdev=net2,mac=52:54:00:12:34:01 \ -netdev type=tap,id=net2,ifname=tap0,script=no,downscript=no
Zde jsem se poprvé spálil. KVM potřebuje dostat blokové zařízení, ale já měl pouze pododdíl na btrfs. Dát tomu práva na celý btrfs svazek hostitele není dobrý nápad. Existuje však jakýsi 9pfs, který se používá na obousměrné sdílení adresářů mezi hostitelem a hostem.
To by vypadalo nadějně, jenže… Existuje několik módů, jak se v takové situaci vyrovnat s právy:
security_model=passthrough
– jaká práva na hostu, taková na hostiteli
(jenže obyčejný uživatel na hostiteli samozřejmě nemůže vytvářet soubory s právem roota
z hosta, a pouštět kvůli tomu KVM pod rootem nechceme).security_model=mapped
– práva z hosta se na hostiteli uloží do rozšířených
atributů nebo do skrytých souborů (jenže to bylo jednak šíleně pomalé a aby toho nebylo málo,
tak navíc locale-gen
na hostu sice bezchybně proběhl, ale žádné lokály nevygeneroval.
A co se systémem bez lokálu…).security_model=none
– stejné jako 1) jen to nehlásí chyby.Nějaké to googlení neodhalilo nic moc povzbudivého, tak jsem se rozhodl takticky ustoupit.
Tiskni Sdílej:
křemík umí AES, HT, turbo a AVX a Intel vám ho uměle vypnulA virtualizace zůstala zapnutá?
Je to jeden z důvodů, proč se Intelu vyhýbám, kde to jde.To bych i chápal, ale ve prospěch jakého výrobce? Zatím mám dojem, že je Intel bezkonkurenční v oblasti kompatibility s Linuxem.
Můžeš být trochu konkrétnější? Zrovna tenhle problém řeším. Můžeš mi poslat třeba e-mail přes zdejší profil. Ale myslím, že taková firma by zasloužila publicitu, takže není třeba to držet v tajnosti.
Bohužel nabídka notebooku s AMD chipsety a bez OS je obecně dost tristní.
Ale u těch s Intelem je to snad ještě horší…
Před nějakou dobou jsem narazil na stránku, kde někdo testoval VirtualBox na CPU od Intelu. Nejvíc mě fascinovalo, že se zapnutým VT-x to bylo pomalejší než bez něj.