Tvorba kyberzombies s PCI passthrough (update 30. 7. 2019)

22.7.2019 00:47 | Přečteno: 3944× | | poslední úprava: 30.7.2019 09:24

Aneb proč dělat věci jednoduše, když nad nimi můžeme strávit půl soboty, že jo?

Co je PCI passthrough asi není třeba příliš vysvětlovat. Jde o technologii, která pomocí vhodného přemapování paměťových adres umožňuje předat virtuálnímu stroji přístup k fyzickému hardwaru hostitele. Nejvíce to asi používají hráči, kteří virtualizují Widle s plným přístupem k výkonné grafické kartě. Těm zároveň vděčím za to, že je k tématu k dispozici spousta studijního materiálu. PCI passthrough lze však použít k ledasčemu.

O co se to vlastně snažím?

Životnost různých chemických analyzátorů bývá o dost delší, než by si jejich výrobci asi představovali. Zařízení musí být postavená tak, aby bez mrknutí oka zvládaly provoz v komerčních laboratořích, kde se dlouhé dny a noci prakticky nezastaví. Každá sekunda, kdy přístroj v hodnotě pár mega nečinně stojí představuje vyhozené peníze. V prostředí univerzitní laboratoře nedostávají přístroje zdaleka tolik za uši a mohou vydržet doopravdy dlouho. Faktorem, který může nějakým způsobem omezit jejich životnost je paradoxně ta nejlevnější část celé sestavy, tedy ovládací počítač.

Podobných veteránů máme v laboratoři více. Část z nich je ovládána počítačem s Windows XP a tomu odpovídajícími verzemi softwaru. Kolik života asi zbývá ve starém HPčku s Core2 Duo a mechanickým diskem si radši nechci představovat. Tím, že jsme výzkumná skupina působící na univerzitě si můžeme dovolit kašlat na různá bezpečnostní pravidla a obslužná PC slouží nejen k ovládání přístrojů ale i jako pracovní stanice k vyhodnocování dat, psaní reportů apod. Připojovat historické exponáty s XPčky k síti je vůbec dost o držku, pouštět na nich starý Firefox je pomalu smrtelný hřích. Další problém vzniká třeba v případě, kdy je nutné nahrát nějaká data na sdílený file server. Pro přístup k serveru je vyžadována podpora protokolu SMB2, který XPčka neznají. No a protože je občas potřeba něco zkontrolovat nebo se dostat k výsledkům měření na dálku, je všude nainstalován TeamViewer nebo povolena vzdálená plocha. Psycho.

Cílem bylo nahradit z našich relikvií tu nejrelikvovatější - staré IBM ThinkCentre s Pentiem 4, Windows XP SP2(!) a pomalu odumírajícím mechanickým diskem. Počítač slouží k řízení skoro dvacet let starého kapalinového chromatografu. Problém má několik dalších zábavných omezení souvisejících s tím, jak se k nám ten kapaliňák kdysi dostal. K ničemu nejsou instalační média, jakýkoliv problém se musí vyřešit bez nutnosti cokoliv reinstalovat. Ovládací software používá dost husté protipirátské techniky a někam ho prostě zkopírovat není jen tak. K přístroji už není absolutně žádná technická podpora, cokoliv se kde rozbije, musíme vyřešit sami. Upgrade na novější verzi ovládacího softwaru by sice měl být možný ale cena licence se pohybuje ve stovkách tisících CZK. Poslední zádrhel vězí v tom, že kapaliňák není k PC připojen ethernetem ale rozhraním IEEE-488, též známým jako GPIB. GPIB port PC běžně nemá a proto je třeba přídavná karta do PCI.

Preludium

Porcuji kartonovou krabici zalepenou červenobílou páskou s logem CZC. Vymámit z CZC objednané zboží bylo opět ne úplně přímočaré, leč po oworkaroundění všech formalit objednávku vyřídili dost svižně. V tunách bublinkové fólie leží zachumlaný Ryzen 2200G, deska ASUS PRIME X370-A, 256 GB M.2 Patriot Scorch a nějaký ten další balast okolo. Nezapomenu se vyplísnit za to, že tubu s pastou Arctic Silver MX-4 jsem nechal doma a na chladiči bude muset zůstat tovární bláto a rychle nasypu celou tu přehlídku levného hardwaru do skříně. Regnum RG1 od SilentiumPC je docela fajn kastle se zdrojem na dně. Zajímalo by mě jen, který borec vymýšlel otvory, kterými je třeba vést napájecí kabely od zdroje ke komponentám. Kdyby byly o dva, tři milimetry širší, ušetřil bych si pár expletiv. K další vychytávce patří, že ke zdroji namontovanému v šachtě se dost blbě může, takže zapojování drátů do patic na zdroji je pěkná patlanina. Než zmáčknu power, chvíli se schýzuji tím, že na desce určitě nebude pro podporu Ryzenu 2 dostatečně aktuální BIOS a já budu někde jako šílenec shánět jedničkový Ryzen. Byl bych vzal čtyřstovkový chipset ale nepodařilo se mi najít vhodnou desku s PCI sloty. Ryzen se naštěstí probouzí...

Plán je následující: Na železo nainstalovat nějaké linuxové distro s dlouhodobou podporou a do něj QEMU. Z původního PC předdčkuji celý disk, ten podstrčím QEMU a přes PCI passthrough mu předám IEEE-488 komunikační kartu. Zdánlivě přímočarý plán se začal komplikovat daleko dříve, než jsem čekal.

Na stroj jsem pragmaticky nainstaloval Debian 10 „Buster“. CentOS 8 ještě nevyšel a navíc má Buster o jednu řadu novější jádro; v Busteru je 4.19, v RHEL 8 jen 4.18. LTSková podpora Busteru je plánována do roku 2024, což musí stačit. Instalace základního systému z netinstu, XFCE a QEMU je otázka jestli patnácti minut.

First shots fired

O první překážku zakopávám už při pokusu o spuštění překlonovaných XPček. Zasekávají se hned při bootu, v normálním režimu se nedostanu ani na startovní splash screen, v nouzovém režimu vykysnou hned po zavedení základních ovladačů. QEMU spouštím vždy ručně z terminálu nějakou variací na následující příkaz:

    qemu-system-x86_64 \
    -enable-kvm -cpu host -smp sockets=1,cores=4,threads=2 \
    -machine type=q35,accel=kvm -m 4096M \
    -drive file="disk.img" \
    -net user,smb="/some/where" -net nic,model=virtio \
    -vga qxl \
    -usb -device usb-tablet -show-cursor

Jako první mě napadá, že si XP neporadí s emulací novějšího chipsetu Q35 (*). Změna chipsetu na -machine pc-i440fx-2.8 nicméně nic neřeší, stejně tak nepomáhá snížení množství RAM na 2 GB. XP se probírají až po vypnutí KVM akcelerace. To považuji za podivné, vím totiž určitě, že XPčka v QEMU mi s volbou -enable-kvm na jiné mašině normálně chodí. Technické vysvětlení je prý to, že modul hardwarové abstrakce HAL.dll je na instalačním médiu Windows XP k dispozici v několika variantách a instalátor nainstaluje vždy jen ten vhodný pro hardware, na nějž je instalováno. Fyzický stroj se zřejmě od virtuálního s povoleným KVM liší natolik, že je třeba použít jinou variantu HAL.dll. Tu lze vykopírovat z funkční instalace Windows XP s podobným stupněm opatchování. Protože nic takového nemám po ruce, vypínám KVM a pokračuji dále. XPčka se konečně spustí a očuchají si nový hardware, nezapomínajíc požádat o novou aktivaci.

(*) Ony si s ní taky jen tak neporadí, ale zapnuté KVM je sundá dříve.

Předáváme komunikační kartu

Kdyby byl tohle jediný problém, asi bych si říkal, že to bylo celé až podezřele jednoduché. Skutečná legrace nastává až při pokusu předat komunikační kartu virtuálnímu stroji. IEEE-488 komunikační karta se v lspci ukazuje takto:

    06:01.0 Unassigned class [ff00]: Applied Micro Circuits Corp. Device [10e8:8130]

Linuxové jádro pro ni nemá žádný ovladač, což se hodí. V perfektním světě by stačilo zavést jaderný modul vfio-pci

    modprobe vfio-pci ids=10e8:8130

a přidat do konfigurace QEMU řádek.

    -device vfio-pci,host=06:01.0

Tak triviální to ale není kvůli tzv. IOMMU groups. Detailnější vysvětlení celého problému je třeba zde; ve zkratce jde o toto. Zařízení na PCI-Express sběrnici mohou komunikovat mezi sebou ve stylu peer-to-peer. Taková komunikace nemusí projít skrz IOMMU a tudíž se správně nepřemapuje. V případě zařízení, která dělají DMA to může být katastrofické. Jádro proto seskupuje zařízení, mezi kterými je tato „skrytá“ komunikace možná do skupin. Chceme-li pomocí PCI passthrough předat nějaké zařízení virtuálnímu stroji, musíme zajistit, že všechna zařízení ve skupině jsou pod kontrolou ovladače vfio-pci či pci-stub. Tyto dva ovladače na hardware téměř nesahají a nedělají žádné DMA. Na ArchWiki lze nalézt šikovný miniskript pro výpis zařízení v jednotlivých IOMMU skupinách, skript samotný vypadá takto:

    #!/bin/bash
    shopt -s nullglob
    for g in /sys/kernel/iommu_groups/*; do
        echo "IOMMU Group ${g##*/}:"
        for d in $g/devices/*; do
            echo -e "\t$(lspci -nns ${d##*/})"
        done;
    done;

Jak vypadá skupina s naší komunikační kartou? Takhle:

    IOMMU Group 7:
        01:00.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] X370 Series Chipset USB 3.1 xHCI Controller [1022:43b9] (rev 02)
        01:00.1 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] X370 Series Chipset SATA Controller [1022:43b5] (rev 02)
        01:00.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] X370 Series Chipset PCIe Upstream Port [1022:43b0] (rev 02)
        02:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port [1022:43b4] (rev 02)
        02:04.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port [1022:43b4] (rev 02)
        02:05.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port [1022:43b4] (rev 02)
        02:06.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port [1022:43b4] (rev 02)
        02:07.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port [1022:43b4] (rev 02)
        05:00.0 PCI bridge [0604]: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge [1b21:1080] (rev 04)
        06:01.0 Unassigned class [ff00]: Applied Micro Circuits Corp. Device [10e8:8130]
        07:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 15)

No... scheiꞵe, pravilo by se po německu.

Částečným řešením může být ACS override patch. ACS zde znamená Access Control Services a jde o mechanismus poskytovaný PCIe sběrnicí, který umožňuje přenosy neviditelné pro IOMMU zakázat. Problém je, že tento mechanismus musí být správně implementován chipsetem. Napadá mě, že kdybych nebyl pitomec, mohl jsem se podívat, jak IOMMU skupiny vypadají na chipsetu B450 a aspoň tušit, že nastane problém. ACS override patch falešně hlásí podporu ACS navzdory tomu, co tvrdí hardware, což může pomoci. Jádra s ACS override patchem pro Ubuntu a Debian se dají stáhnout třeba odsud. Problém je, že i po instalaci jádra s ACS overridem a nabootováním s jaderným parametrem pcie_acs_override=downstream zůstane skupina s komunikační kartou úplně stejná. Scheiꞵe indeed...

Fajn, která z těch ostatních zařízení skutečně potřebuji? PCI bridge uvolňovat není třeba a bez síťovky se obejdu, se SATA řadičem a USB je to horší. Na SATA řadiči je připojený mechanický disk s obrazem virtuálky, do USB je připojená myš. SSD disk, který jsem chtěl původně - a měl kapacitu jen 128 GB - byl naštěstí vyprodaný, takže jsem musel pořídit jiný v 256 GB verzi. Celý obraz disku virtuálky má 150 GB, takže se na SSDčko v pohodě vejde. NVMe řadič je v samostatné IOMMU skupině, čímž máme aspoň jedno zařízení z krku. USB řadič je rozdělen na několik zařízení, budu-li mít štěstí, umrtvím jen nějaké USB porty. Jak tedy na to? Nejdříve musíme upravit initramfs tak, aby obsahoval vfio-pci ovladač. To na Debianu provedeme tak, že do souboru /etc/initramfs-tools/modules přidáme následující řádky

    vfio
    vfio-vifqfd
    vfio-iommu-type1
    vfio-pci

a spustíme /sbin/update-initramfs -u

V dalším kroku upravíme jadernou příkazovou řádku tak, aby se vfio-pci zaváděl co nejdříve při bootu. Do souboru /etc/default/grub přidáme do řádky GRUB_CMDLINE_LINUX následující:

    iommu=on amd_iommu=on rd.driver.pre=vfio-pci vfio-pci.ids=1022:43b9,1022:43b0,1022:43b4,1b21:1080,10e8:8130,10ec:8168

Tím jednak nahodíme IOMMU a za druhé řekneme jádru, že má při startu zavést ovladač vfio-pci. Seznam uvedený za vfio-pci.ids je seznam hardwarových ID zařízení, pro která chceme vfio-pci použít. Ten získáme třeba z výpisu lspci -nn. Nakonec spustíme /sbin/update-grub a restartujeme stroj.

Zde je jádro bohužel trochu hloupé a někdy si bezostyšně nahradí vfio-pci „správným“ ovladačem pro dané zařízení. Zda se tak stalo můžeme zjistit třeba výpisem lspci -k. Ukázkový výstup může vypadat následovně:

    03:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 3e)
            Subsystem: Intel Corporation Centrino Ultimate-N 6300 3x3 AGN
            Kernel driver in use: iwlwifi
            Kernel modules: iwlwifi

Pokud je v řádku Kernel driver in use něco jiného než vfio-pci, jádro se rozhodlo nás vyfakovat a zavést si ovladače po svém. To vyřešíme tak, že nežádoucí zařízení ovladači ručně sebereme. Pro unbind USB řadiče (viz seznam o trochu výše) bychom postupovali takto:

    echo -n 0000:01:00.0 > /sys/bus/pci/drivers/xhci_hcd/unbind
    echo 1022 43b9 > /sys/bus/pci/drivers/vfio-pci/new_id

Výpis lspci -k by měl nyní ukázat Kernel driver in use: vfio-pci. Podobný trik provedeme pro případná další zařízení v dané IOMMU skupině. PCI bridge můžeme ignorovat, ty QEMU nevadí, protože samy nemohou provádět žádné DMA.

Pokusíme-li se teď předat QEMU přístup ke komunikační kartě, zmizí chybová hláška Group not viable a QEMU s XPčky nastartuje. Ač dokumentace QEMU nedoporučuje používat PCI passthrough spolu s emulací chipsetu i440FX, karta se objevuje ve Správci zařízení a XP chvíli dumají nad instalací ovladače. Ten se nainstaluje a Windows si řeknou o restart. Poté se karta tváří jako plně funkční.

Na hodinách už je zle po osmé večerní, když třesoucím se prstem zapínám chromatograf a PDA detektor. Inicializace obou zařízení chvíli trvá... konečně. Spouštím ovládací software a v konfigurátoru instrumentace skenuji dostupná zařízení. U separačního modulu i PDA detektoru se zobrazuje OK: Yes. I údaje o teplotě autosampleru, kolony a hodnotě zpětného tlaku vypadají živé a smysluplné. Ty krávo, ono to snad fakt funguje... :) (*)

Pro úplnost, celý skript, kterým virtuálku spouštím vypadá následovně. Skript se spouští automaticky se startem XFCE - aktualizován 23. 7. 2019

#! /bin/bash

RUN_VM=1
IP_ADDR=10.8.2.152

destroy_tap() {
	ip l set dev tap0 down
	brctl delif vmbr0 tap0
	ip tuntap del tap0 mode tap
}

destroy_iptables() {
	iptables -D FORWARD -s $IP_ADDR -p udp --dport 67:68 -j ACCEPT
	iptables -D FORWARD -d $IP_ADDR -p udp --sport 67:68 -j ACCEPT
	iptables -D FORWARD -s $IP_ADDR -p udp --dport 53 -j ACCEPT
	iptables -D FORWARD -d $IP_ADDR -p tcp --dport 3389 -j ACCEPT
	iptables -D FORWARD -p udp --dport 137 -s $IP_ADDR -j ACCEPT
	iptables -D FORWARD -p udp --dport 138 -s $IP_ADDR -j ACCEPT
	iptables -D FORWARD -p udp --sport 137 -d $IP_ADDR -j ACCEPT
	iptables -D FORWARD -p udp --sport 138 -d $IP_ADDR -j ACCEPT
	iptables -D FORWARD -p tcp --dport 139 -s $IP_ADDR -j ACCEPT
	iptables -D FORWARD -p tcp --dport 445 -s $IP_ADDR -j ACCEPT
	iptables -D FORWARD -d $IP_ADDR -p icmp -j ACCEPT
	iptables -D FORWARD -s $IP_ADDR -p icmp -j ACCEPT
	iptables -D FORWARD -s $IP_ADDR -j DROP
	iptables -D FORWARD -d $IP_ADDR -j DROP
}

cleanup() {
	destroy_iptables
	destroy_tap
}

fail() {
	echo "$1"
	read -p "Press Enter to terminate..."

	cleanup

	exit 1
}

fail_early() {
	echo "$1"
	read -p "Press Enter to terminate..."

	exit 1
}

init_iptables() {
	# Allow DHCP
	iptables -A FORWARD -s $IP_ADDR -p udp --dport 67:68 -j ACCEPT
	iptables -A FORWARD -d $IP_ADDR -p udp --sport 67:68 -j ACCEPT

	# Allow DNS
	iptables -A FORWARD -s $IP_ADDR -p udp --dport 53 -j ACCEPT

	# Allow RDP
	iptables -A FORWARD -d $IP_ADDR -p tcp --dport 3389 -j ACCEPT

	# Allow SMB shares
	iptables -A FORWARD -p udp --dport 137 -s $IP_ADDR -j ACCEPT
	iptables -A FORWARD -p udp --dport 138 -s $IP_ADDR -j ACCEPT
	iptables -A FORWARD -p udp --sport 137 -d $IP_ADDR -j ACCEPT
	iptables -A FORWARD -p udp --sport 138 -d $IP_ADDR -j ACCEPT
	iptables -A FORWARD -p tcp --dport 139 -s $IP_ADDR -j ACCEPT
	iptables -A FORWARD -p tcp --dport 445 -s $IP_ADDR -j ACCEPT

	# Allow ICMP (ping and stuff)
	iptables -A FORWARD -d $IP_ADDR -p icmp -j ACCEPT
	iptables -A FORWARD -s $IP_ADDR -p icmp -j ACCEPT

	# Block anything else
	iptables -A FORWARD -s $IP_ADDR -j DROP
	iptables -A FORWARD -d $IP_ADDR -j DROP
}

init_tap() {
	if grep -qs "tap0" ip l show; then
		echo "Tap device already exists"
	else
		ip tuntap add tap0 mode tap || fail_early "Cannot create tap device"
		brctl addif vmbr0 tap0 || fail "Cannot add tap interface to bridge"
	fi
}

warn() {
	echo "WARNING: $1"
}

unmount_data_part() {
	if grep -qs "/media/data" cat /proc/mounts; then
		umount /media/data || fail "Cannot unmount data partition"
	fi
}

unbind_all() {
	echo "Freaky stuff happening..."

	#Unbind interferring USB controller
	echo -n 0000:01:00.0 > /sys/bus/pci/drivers/xhci_hcd/unbind || warn "Failed to unbind USB controller"
	echo 1022 43b9 > /sys/bus/pci/drivers/vfio-pci/new_id || warn "Failed to vfio-ize USB controller"

	#Unbind interferring network controller
	echo -n 0000:07:00.0 > /sys/bus/pci/drivers/r8169/unbind || warn "Failed to unbind network controller"
	echo 10ec 8168 > /sys/bus/pci/drivers/vfio-pci/new_id || warn "Failed to vfio-ize network controller"

	#Unmount HDD and unbind interferring SATA controller
	unmount_data_part
	echo -n 0000:01:00.1 > /sys/bus/pci/drivers/ahci/unbind || warn "Failed to unbind SATA controller"
	echo 1022 43b5 > /sys/bus/pci/drivers/vfio-pci/new_id || warn "Failed to vfio-ize SATA controller"

	echo "Freaky stuff happened successfully..."
}

rebind_partial() {
	#Remount data partition
	echo -n 0000:01:00.1 > /sys/bus/pci/drivers/vfio-pci/unbind || fail "Failed to devfio-ize SATA controller"
	echo 1022 43b5 > /sys/bus/pci/drivers/ahci/new_id || fail "Failed to rebind SATA controller"
	echo "Please wait for the SATA disk to remount..."
	sleep 2
	mount /dev/disk/by-uuid/087f61b0-177d-4bb6-8b49-cac445c14d61 /media/data || warn "Failed to remount data partition"
}

launch_qemu() {
	qemu-system-x86_64 \
		-cpu coreduo,-vme \
		-smp 1,cores=1,threads=1 \
		-machine pc-i440fx-2.8 -m 2048M \
		-device vfio-pci,host=06:01.0 \
		-drive file=/home/echmet/VM/WinXP_Empower.img,format=raw \
		-net nic,model=e1000,macaddr=00:09:6b:47:c0:e9 \
		-net tap,ifname=tap0 \
		-rtc base=localtime \
		-vga qxl -usb -device usb-tablet -show-cursor \
	        -no-quit || fail "QEMU failed to launch or crashed..."
}

upgrade_packages() {
	apt-get -y update || fail "Failed to refresh package list"
	apt-get -y upgrade || fail "Failed to upgrade packages"
}

ask_restart() {
	zenity --question \
		--title "What do I do?" \
		--text "Do you want to restart the virtual machine?" \
		--width 300

	if [ $? -ne 0 ]; then
		RUN_VM=0
	fi
}

ask_main() {
	zenity --question \
		--title "What do I do?" \
		--text "Virtual machine has shut down. Do you want to update system packages and shut the computer down?" \
		--width 500

	if [ $? -eq 0 ]; then
		upgrade_packages
		systemctl poweroff
	fi

	ask_restart
}

	init_tap
	init_iptables

if [ ! -z "$1" ]; then
	if [ "$1" == "rebind_partial" ]; then
		rebind_partial
		exit 0
	elif [ "$1" != "nounbind" ]; then
		unbind_all
	fi
else
	unbind_all
fi

while [ $RUN_VM -eq 1 ]; do
	launch_qemu
	ask_main
done

cleanup

rebind_partial

(*) To nebudu vědět jistě, dokud na tom někdo nezkusí něco měřit...

Resumé

Takhle sesumírované to zní děsně jednoduše. Když jsem to dával dohromady, ke konci jsem se u toho moc nesmál. Reálná cena za umrtvení několika zařízení na desce je nefunkční síť, čtyři inhibované USB porty (z celkových osmi) a nemožnost zapisovat na sekundární HDD. První problém jsem vyřešil zapojením USB síťovky. AXAGON ADE-SR se na Alze povaluje za cca 340 Kč a na Linuxu funguje ihned po zapojení. Verze, co jsem obdržel já se identifikuje takto:

    Bus 002 Device 006: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter

Problém s USB porty vlastně není třeba řešit. Dokud fungují aspoň nějaké porty, vždycky se dá zapojit rozbočovač. Nutnost shodit i SATA řadič mi vadí asi nejvíce. SSD diskům pořád úplně nevěřím; třeba Crucial MX200, co jsem donedávna měl v notebooku zhruba před čtrnácti dny odešel doslova zničehonic (co myslíte, měl jsem zazálohováno?). Protože SATA řadič je nutné shodit až tehdy, když se spouští virtuálka, uvažuji o pravidelném zálohování obrazu z SSDčka na mechanický disk. Jasně, žádná pořádná záloha to není ale aspoň proti nečekanému selhání SSD disku by to stačilo.

TODO - Update 23. 7. 2019

Vzhledem to tomu, že zápisek vzbudil až nečekaný zájem - původně jsem to napsal spíš pro sebe jako takovou zajímavou blbůstku - přikládám aktualizovaný TODO list s finálním startovacím skriptem.

Rozjet na virtuálce KVM akceleraci. Sice to není až tak pomalé ale znát to je.

Tohle se mi prostě nepodařilo. Buď je to důsledek bugu ve VME 1,2, který QEMU neumí zamaskovat, nebo jde o ještě něco jiného. Každopádne se mi ani po hodině zběsilého přehazování typu CPU a povolených rozšíření nepovedlo rozjet ani instalátor XPček. Bez -enable-kvm to funguje.

Omezit virtuálce přístup k síti tak, aby mohla jen k SMB sharu hosta a možná vzdálené ploše.

Done. Při pohledu na ty pravidla pro iptables ihned rozpoznáte, že nejsem žádný síťař ale svůj účel to plní. Bacha na to, že Debian 10 používá jako výchozí nftables a pokud chcete filtrovat TCP/IP na bridgi, je lepší se vrátit k iptables a zavést modul br_netfilter. Virtuálka může jen k SMB sharu hosta, DNS, DHCP a RDP, všechno ostatní je zatnuté.

Nastavit automatické zálohování obrazu virtuálky.

Tohle jsem nakonec zavrhl s tím, že se to ve vhodné momenty prostě odzálohuje ručně. (Tak určitě, že jo...)

Upravit spouštěcí skript tak, aby po zastavení virtuálky znovu připojil druhý disk.

Done, viz aktualizovaný skript.

Update 30. 7. 2019

Nakonec na povrch vyplulo ještě pár nedostatků, jež bylo nutné vyřešit a sice:

• QEMU s VM občas náhodně crashnul, velmi dobře reprodukovatelné to bylo při pokusu restartovat virtualizovaná XP. Vyřešeno změnou -cpu na

  -cpu coreduo,-vme \
  -smp 1,cores=1,threads=1 \
  

  S povolenými více jádry by to asi fungovalo také ale už se mi nechtělo s tím dál laborovat.
• QEMU je možné nechtěně zavřít kliknutím na zavírací křížek okna nebo zmáčknutím Alt+F4. Vyřešeno přidáním parametru -no-quit.
• Ovladač virtio síťovky pro XP (verze 0.1.141-1) je zřejmě nějak zabugovaný a občas po startu XPček nechodí žádné příchozí packety. Pokud se síťovka ve správci zařízení ručně zakáže a opět povolí, chytne to ale moc user-friendly to není. Vyřešeno nastavením -net nic,model=e1000 a doinstalováním ovladače pro kartu IntelPRO 1000 - XPčka ho ještě nemají.

A proč jsem to vlastně psal? Počítačů, které bude potřeba podobným způsobem zombifikovat máme víc, tak ať se má případný budoucí snaživec kde inspirovat. Už teď je mi ho líto...

A na závěr ten obligátní It Works! obrázek

       

Komentáře

[hydrandt]

Yeeeeah, gratulace! Diky za detektivku!

[KOLEGA]

a mel jste zazalohovano?

[MadCatX]

Jasně že ne, naštěstí asi nejhodnotnější věcí na tom disku byla virtuálka, kterou používám pro buildování a testování pár appek na Windows a tu odzálohovanou mám. Spíš mě zaskočilo, jak to zdechlo z vteřiny na vteřinu.

[marbu]

Díky za zápisek. Zvažoval jsi že to nahodíš přes libvirt místo spouštení qemu napřímo? Jak se řeší XP posmrtně žádají o aktivaci? Jinak každopádně gratuluju.

[MadCatX]

Uvažoval a nakonec jsem to zavrhl. Jednak se mi z XML konfiguráků libvirt dělá nevolno a druhak mám na proces spuštění a zastavení virtuálky trochu specifické požadavky, které si radši vyřeším „na dřevorubce“ skriptem. Nepochybuji, že by to šlo i přes libvirt ale nechtělo se mi s tím bojovat.

[MadCatX]

Ad aktivace XP: Kupodivu jsem nemusel řešit nic. V průvodci aktivací či jak se to jmenuje jsem prostě zvolil „Aktivovat přes internet“ a bylo vyřešeno. Taky jsem to čekal trnitější.

[/dev/random]

sa to crackne, tak ci tak aktivacia po nasadeni vo virtuale nieje legalna...

[j]

Ale neblabol, to si vzal kde? ....

[Max]

WinXP můžeš v klidu zvirtualizovat a je to licenčně ok. Taktéž můžeš OEM licenci zmigrovat na jiný hw. MS oficiálně udává, že v případě zničení původního to možné je.
Zdar Max
PS:reálně to nikdo kontrolovat nebude a kdyby, bude to ok

[debian+]

Nejaky doveryhodny zdroj podporujuci Tvoje tvrdenie?

[Max]

Si přečti EULU, já jí četl. Ze začátku o virtualizaci v EULE nebylo ani slovo, protože virtualizace byla v plenách, poté to myslím doplnili. Samozřejmě když jsi měl jednu licenci na WinXP, nemohl jsi mít pod WinXP virtualbox a v něm další WinXP. Ale Linux+WinXP bylo ok. Má jednu licenci pro jeden PC a je jedno, zda instalaci provozuješ na fyzickém železe, nebo formou virtuálu. To samé pak pro Win7, platí dodnes.
U Win serverů je to tak, že můžeš třeba se standard edicí mít spuštěné dvě instance Windows serveru s tím, že pokud virtualizuješ na Windows, tak můžeš mít instance tři. Jedna jako hypervisor, kde nesmí nic běžet, jen služby hypervisoru (žádná app) a k tomu dvě VM, kde už může běžet cokoli. Nevím, zda něco podobného už nepřevzaly Win10, EULU jsem u nich nečetl.
Každopádně tento druh virtualizace platí pro desktop použití. Nejde takto mít 20x OEM v ESXi clusteru a připojovat se na ty stanice přes rdesktop, to už je v rozporu s licencí, na VDI je potřeba ještě dokoupit další licence.
Spíš by mně zajímalo, kde lidi berou, že virtualizace WinXP OEM je v rozporu s licencí. Tahle fáma se vytvořila nevím kde a pořád jí někdo opakuje.
Zdar Max

[Max]

A to jsem ještě zapomněl na to, že s Win7 Pro/Ulti je automaticky i licence na WinXP (= XPmod).
Zdar Max

[j]

Tyhle blaboly od lidi ktery tu licenci nikdy necetli (pripadne vzivote neprecetli jedinej §AZ) se na netu objevujou leta letouci. Je to stejnej blabol jako ze s OEM je to na konkretni pocitac, jenze kdyby si ti mamlasove precetli, co to je OEM, tak zjisti, ze to je ujednani, ktery se vubec nevztahuje na uzivatele, ale na distributora - OEM totiz rika jen to, ze tu licenci smi distributor prodat pouze z HW, ale nikoli samostatne (a protoze i tohle ujednani je dost gumovy, prodavalo se trebas s mysi). Vubec nic to nerika o tom, ze se to smi provozovat jen na konkretnim HW, a navic i kdyby rikalo, tak to je v rozporu s AZ.

Tyhle vyklady jsou samo vyhodny predevsim pro vsemozny preprodejce "fakt legalnich" licenci.

[Bedňa]

Tahle fáma se vytvořila nevím kde a pořád jí někdo opakuje.

Pretože ani ty si nepovedal úplnú pravdu o Win a licencie na počet procesorov. O tom že niektoré verzie Win pri zmene HW sa zablokovali atď.

Každý proste len vytrhne časť a tú niekde zavesí :)

[/dev/random]

a pritom stacilo pouzit VirtualBox + Guest Additions

[GeorgeWH]

VB v produkcii?

[MadCatX]

Zrovna s VBoxem nemám úplně nejlepší zkušenosti a postupně jsem ho skoro všude nahradil právě QEMU. Nepotřebuje to žádné addony ani out-of-tree jaderné moduly a je k němu spousta dokumentace a návodů. A to PCI passthrough ve VBoxu bych fakt chtěl viděl, resp. spíš nechtěl.

[Salamek]

Tak a ted tu app jeste "zreverse engineeringovat" a napsat znovu v QT

[Max]

Čekal bych, že práce s IOMMU bude o něco přívětivější.
Každopádně díky za pěkné počtení.
Zdar Max

[henk]

Gratulace, jinak já žil v přesvědčení, že XPéčka nepřežijí výměnu základní desky - viděl jsem to alespoň několikrát na reálném HW. Takže si možná měl velkou kliku? :)

[Jana J.]

Obvykle se jim s trochou snahy nechalo domluvit.

[OldFrog {Ondra Nemecek}]

Gratuluji. Zdá se, že jste univerzitě ušetřil pár set tisíc za cenu nové licence potažmo pár mega za nový chromatograf Je to lumpárna, že jeho výrobce neposkytuje ovladače pod opensource licencí. Takhle na to tom ale očividně víc vydělá. Každopádně pokud jste to zvládnul rozchodit za den tak to mi přijde jako super rychlé řešení.

[ewew]

Pravdepodobne ten ovladač obsahuje nejaký kód alebo tajomstvo, ktoré si chcú uchovať. Možno je to zlý kód a nechcu pustiť do sveta informáciu ako zle to majú.

Skutočný dôvod uzavretia poznajú len autori.

[trekker.dk]

Gratuluji. Zdá se, že jste univerzitě ušetřil pár set tisíc za cenu nové licence potažmo pár mega za nový chromatograf

Schválně, jestli to někdo ocení něčím hmotnějším než je poděkování. Minimálně prémie by byly na místě.

A to, že výrobce neposkytuje k zařízení za pár mega s takto dlouhou životností zdarma ovladače pro novější operační systémy, je skutečně lumpárna. Bohužel ale nic překvapivého.

[MadCatX]

Ten ovladač - resp. popis komunikace mezi obsluhou a přístrojem - bude dost pravděpodobně někde zdokumentovaný a dostupný. Linuxový ovladač k té GPIB kartě by se asi nechal sehnat také. Ke starým plynových chromatografům apod. ještě od Hewlett-Packard se dodávala docela obsáhlá dokumentace popisu komunikace včetně headerů a ukázkového kódu. Není tak vzácné, že software poskytovaný firmou A umí ovládat instrumenty od firmy B. Problém je hlavně v tom obslužném softwaru, který umí spoustu netriviálních věcí co člověk prostě nenaimplementuje za víkend.

[xkucf03]

Problém je hlavně v tom obslužném softwaru, který umí spoustu netriviálních věcí co člověk prostě nenaimplementuje za víkend.

To už by ale zase mohlo jít rozchodit pod Wine, ne?

Jinak tyhle problémy znám taky – např. software vyžadující HW klíč do LPT portu (ochrana proti kopírování). Na nových deskách jednak moc paralelní porty už nejsou a jednak i když jsou, tak se to nedá moc virtualizovat. Nejlepší řešení by byl crack, ale ten jsem bohužel na tu legálně koupenou verzi/lokalizaci nenašel. Jinak by tohle ve Wine ale chodilo.

[Max]

Pokud jde o tak obstarožní věci jako klíče do LPT apod., tak věřím, že zkušený cracker by to zlomil během dne.
Problém je spíš někoho takového sehnat. Osobně vím asi jen o jednom člověku, ale těžko říci, zda se tomu ještě věnuje (už vyrostl a času na hraní je čím dál tím méně :-/ ).
Zdar Max

[MadCatX]

Problém je hlavně v tom obslužném softwaru, který umí spoustu netriviálních věcí co člověk prostě nenaimplementuje za víkend.

To už by ale zase mohlo jít rozchodit pod Wine, ne?

Ani náhodou. Ten SW je dost komplexní záležitost s Oralce WAP5 backendem, několika permanentně běžícími službami a tak podobně. Rozhýbat tohle dostatečně spolehlivě WINEm bych se asi ani nepokoušel, navíc od té věci stejně nemám instalačky :)

[Pavel Píša]

Zavést/promapovat specifický driver do Wine nemusí být triviální a to ani v případě, že jsou k dispozici zdrojové kódy driveru pro Linux i Windows, jako to bylo v našem případě.

Pokud má driver nabídnout i read/write API, tak tato funkcionalita nebyla ve Wine podporovaná, pouze drivery s IOCTL only jsou implementované.

Dotazy a hlubší rozbor viz má komunikace na Wine hq

https://www.winehq.org/pipermail/wine-devel/2013-July/100409.html https://www.winehq.org/pipermail/wine-devel/2013-July/100445.html

Prototyp takového driveru zde:

http://cmp.felk.cvut.cz/~pisa/ulan/wine/

Jinak bych mohl napsat a možná někdy napíši celkem dlouhou litanii na téma open-source, spolupráce v oblasti Laboratorních přístrojů, robotiky a software v České republice. Je nutné si dobře vybírat partnery a kolegy, protože jinak si ostatní ukradnou co mohou, vyberou granty, do kterých ani původní autory nepřizvou a dobře odvedené práce mnoho nebude.

Je v krátkosti k našim open-source projektům v oblasti HPLC

Když jsme někdy v roce 1990 navrhovali novou generaci HPLC přístrojů, tak jsme zvažovali, jak zařídit jejich komunikaci a řízení. Použili jsme základ 8051 multidrop komunikace pro RS-485 navržený Intelem a rozšířili ho o plnou podporu multi-master s deterministickou distribuovanou arbitrací přístupu k médiu, projekt uLAN.

Z soukromého prostředí firmy jsme ho poskytli univerzitě, kde byl náš návrh použitý pro parametrizaci jednotek zapalování. Zároveň byl protokol prvně plně dokumentovaný v rámci mé DP. Prvně existovaly drivery pro 8051, DOS, PMD85, poté pro Linux a port z Linux driveru do Windows. Projekt byl brzy plně otevřený včetně všech variant driverů i infrastruktury firmware pro návrh vlastních řídicích modulů na bázi 8051 a ARM LPC. Myšlenka byla vytvořit kompletní systém ne jen pro analytické použití, ale i pro automatizované řízení preparací, purifikací, výroby čistých látek, léčiv atd. Kromě analytických pum máme vyvinuté i pumpu do 20 MPa 400 ml/min.

Z počátku jsme pro přístroje používali na míru upravený komerční produkt DataApex pro DOS. Když jsme dodali přístroje na přírodovědeckou fakultu UK, tak doktor Jindřich Jindřich projevil zájem o novější software pro Windows a na základě dokumentace ho začal implementovat. Poté jsme spojili síly, roky v rámci možností vývoj platili. Výsledkem je projekt CHROMuLAN. Jeden z prvních kompletně open-source systémů pro vyhodnocování HPLC analýz včetně řízení sestav chromatografických přístrojů a analyzátorů aminokyselin. A to přímo podporovaný a vyvýjený ve spolupráci s týmem, který přístroje konstruoval. Na software se odkazují stovky článků, kdy je použitý i pro vyhodnocování záznamů z jiných přístrojů. Náš zájem byl, aby si ho lidé vyzkoušeli a případně až budou sestavy inovovat, tak zvážili nákup přístrojů od parterů, kteří v naší licenci přístroje vyráběli.

Jenže české univerzity raději platili mnohem více za zavedené značky.

Přitom naše přístroje slouží v několika generacích desítky let a i nejstarší dodaný někdy v roce 1992 do Ústavu organické chemie a biochemie AV ČR dostal někdy okolo roku 1996 bezplatný upgrade firmware, který umožňuje přístroj zapojit i k aktuálním verzím sofware. Základní vrstva komunikačního protokolu včetně plné introspekce datových typů má linkovou vrstvu stabilizovanou někdy od roku 1992, takže shodný zdrojový kód driveru pracuje s PCI kartami a později i USB převodníky od verze Linuxu někdy okolo 1.3.38 (1995), Windows Nt 3.5 s tím že se při překladu umí přizpůsobit i PnP modelu Windows 2000 až 10 32 i 64-bit verzi.

Vlastní řídicí a vyhodnocovací software je poplatný době vzniku, je psaný pro Delphi, přesto jsem investoval značné množství času a i nějaké firemní peníze do portu pod Linux. Varianta pro Linux zatím není plnohodnotná, protože FPC/Lazarus nepodporuje MDI tak, jak byl program napsaný. Ale SW nativně na Linuxu v 32 i 64-bit buildu běží, s přístroji komunikuje a základní vyhodnocování umožňuje. Nechodí overlay režim porovnávání několika analýz a tisk.

Byli jsme otevření i spolupráci s dalšími, kteří by měli zájem software rozšířit o podporu sběru dat a řízení dalších přístrojů. Pro připojení starších detektorů s analogovým výstupem dodáváme AD převodník ULAD32, který lze zapojit do USB a zároveň vytváří bránu pro připojení dalších přístrojů přes naší komunikaci uLAN. Vzhledem k otevřenému protokolu a zdrojovým kódům infrastruktury pro tvorbu firmware není problém zapojit i vlastní zařízení na bázi MCU.

[Bedňa]

Jinak bych mohl napsat a možná někdy napíši celkem dlouhou litanii na téma open-source, spolupráce v oblasti Laboratorních přístrojů, robotiky a software v České republice.

Tak na to sa trasiem ako drahý pes v zime.

Mám rád osobné skúsenosti a asi nebudem sám.

[MadCatX]

Projekt CHROMuLANu mě dříve docela zaujal. Z mého pohledu je škoda, že je to postavené okolo Delphi, jinak bych si s tím asi chvíli vyhrál. Myšlenka otevřené infrastruktury pro řízení a vyhodnocování dat z různých chemických analyzátorů je super.. Škoda, že zejména průmyslová praxe je zabetonovaná ve striktně komerčních řešeních a univerzity a výzkumné ústavy se tomu musí aspoň zčásti přizpůsobit. Pro nás se zatím zdá nejschůdnější zreverzovat datové formáty záznamů, které plivou komerční softwary (kde to rozumně jde) a případně se uchylovat k hackům popsaným v tomto blogu...

[Pavel Píša]

Souhlasím, že Delphi/Lazarus již z dnešního pohledu nejsou ideální. Jak pro počítače tak pro embedded HW, analyzátory, demonstrátor nového GUI a HW infúzních pump a další jsme použili a používáme Qt.

Na druhou stranu je Lazarus/FPC zajímavý tím, že binární build z Jessie běží i na Busteru a v podstatě libovolném Linuxovém distru, stejně jako dříve Acrobat reader, bez nutnosti si s sebou táhnout knihovny. Důvod je celkem prostý, objektová obálka, která se s verzí Lazarusu/FPC mění je zalinkovaná staticky a vlastní grafické knihovny Gtk, Glib a spol mají čistě C-čkové API, které je po celou major verzi udržované striktně binárně kompatibilní. Pak vlastně ekvivalent flatpak like runtime je jen seznam major verzí knihoven, které si distribuce normálně dotáhne (pustit libovolný SW tak, aby viděl jen /lib a /usr v kontejneru je na Linuxu téměř zadarmo). Tak to bylo dříve v Unixovém světě se závislostmi vymyšlené. Bohužel požadavek na rychlý vývoj, featury a C++ tohle neumožňují. Vymýšlel jsem mechanizmus, jak definovat objektové ABI tak, aby bylo možné v předcích přidat virtuální metody a dokonce i fieldy, aniž by bylo nutné rekompilovat veškeré objekty, které z daného objektu dědí. Vycházelo mi řešení, které by sice mělo určitý overhead a více symbolů s runtime nastavenými ofsety, ale nebylo by to tak hrozné. V Qt to dříve řešili tím, že pro zachování binární kompatibility v major verzích přidali metodu, co měla být virtuální jako statickou a navázali na ní signál/slot, kterým v potomcích mohli vlastní tělo přesměrovat. V major verzi Qt 5 to ale již neplatí, všechny projekty jsem musel po instalaci Busteru rekompilovat.

Co se týče chromatografického SW, tak když se mám nepodařilo získat komunitu pro CHROMuLAN, tak jsem alespoň podnítil a zasponzoroval vývoj modulů pro OpenChrom, které umí data z CHROMuLANu číst a i lze přes ně připojit naše zařízení. Podporovaný je ale jen základní sběr dat.

Co se týče CHROMuLANu, tak si myslím, že pro vyhodnocování analýz s jednou nebo několika málo liniemi je stále i po desítce let již jen velmi sporadických updatů lepší než datový model OpenChromu a a možná i Clarity. I když její poslední verze neznám. Každá analýza si nese veškerá data nastavení přístrojů a vyhodnocování přímo v sobě. Tím je možné nejen podmínky dokumentovat, ale i po letech použít jako šablonu nové analýzy. Šablonu lze i exportovat a případně z ní oddělit zvlášť metodu vyhodnocování, nastavení přístrojů a časové programy. Všechno jsou to jen větve jednoho datového modelu, které se serializují do shodného, celkem úsporného a rychle načítaného binárního formátu. Přitom v aplikaci jednotný datový model zahrnuje všechny otevřené soubory (analýzy, sekvence, kalibrace) a živými větvemi datového modelu je i stav připojených přístrojů, které lze zápisem položek ovládat, data číst a nastavit pro každou položku periodu obnovování. Datový model přístrojů je pak načítaný přímo z nich. To znamená že i libovolný nový přístroj lze řídit verzí SW, která o něm neměla tušení a propojení používá skripty v Pascalu, takže přizpůsobení bez nutnosti rekompilace je možné i na straně uživatelů.

Vlastní binární formát byl založený tak, že umožnil dopřednou i zpětnou kompatibilitu od založení projektu před téměř 20 lety do dnes. Ano, není to zcela ideální, natažením nových dat do staré verze se přijde o ty položky v objektech záznamu, které stará verze nezná. Vymýšlel jsem i formát, který by i toto zvládal, ale zvítězil pragmatický přístup. Přiznávám, že i s tou zpětnou kompatibilitou to není 100%, protože jednou jsme objevili zanesenou chybu a tu opravili s tím, že z novějších verzí data do té před chybou nahrát nebude možné. Dopředná kompatibilita dat byla zachovaná po 20 let vždy.

Stále si myslím, že by verze pro Linux mohla být užitečná. Spíš již pro pomoc druhým, než pro nás, protože naše projekty dostaly takové rány, že se spíš nevzpamatujeme. Pokud by byl zájem, tak nějakou lehkou pomoc, dokud ještě dýchám a nejsem zcela pod prášky na vymazání mysli, mohu nabídnout. Plán jak technicky rozumně dál mám, ale je mi spíš k ničemu. Systém CHMRuLANího IDLu, který z validních struktur v Pascalu s komentáři generuje kompletní objektový datový model, by bylo možné rozšířit tak, aby vygeneroval buď přímo kód v C++ nebo nějaký jiný formát popisu datového modelu a z něho pak vygenerovat Qt property nebo nějaký jiný objektový model pro C++. Vlastní výpočetní funkce převést z Pascalu do C již není až tak moc práce. Grafy by se v Qt našly možná i lepší a pro výměnu dat mezi GUI aplikacemi a RT daemony pro řízení přístrojů bych nyní volil Silicon Heaven protokol, který navrhl můj kolega pro řízení tramvají https://github.com/silicon-heaven/libshv nebo RTPS protokol.

Pro vyhodnocení jsem měl připravený i koncept, jak implementovat PeakFitting s analyticky spočítanými modely včetně derivací pro mnoho typů peků https://sourceforge.net/p/chromulan/pfit-experiments/ a dizertace https://support.dce.felk.cvut.cz/mediawiki/images/a/a3/Diz_2010_pisa_pavel.pdf.

Pokud by pak někdo měl opravdu o HPLC zájem a chuť spolupracovat a pustit se do seriózního projektu, tak bych byl třeba i pro open-source/hardware řešení. Když by se sehnal crowdfunding na takových 20 přístrojů od jednoho typu, tak máme připravený velmi pěkný projekt analytické HPLC pumpy do 5 ml/min, který náš partner zmrzačil v rámci grantu za 5 mega a tvrdí, že v jím "vyvinutém" přístroji již naše komponenty nejsou a neplatí licence (licence na veškerý náš předchozí vývoj dostali bez počáteční investice do vývoje s tím, že se naše investice zaplatí procenty z prodaných kusů). Ozkoušené máme bloky pro separace do těch 20 MPa 400 ml/min. Dále pumpy do 20 a 100 ml/min, které vykazují výrazně menší rychlost opotřebení ucpávek než konkurence. Naše UV-VIS detektory také při testech vyhazovaly shodné parametry jako nejlepší zahraniční. I po naší likvidaci za peníze z grantu v oblasti analyzátorů aminokyselin, jsme připravovali třeba i pro původního partnera PDA, ale ochota zaplatit výrobu prototypu byla nulová. Vzhledem k tomu, že oficiálně deklarovali, že naše analyzátory již nevyrábí a k tomu, že v oblasti HPLC odmítli navrhované přístroje nebo náš vývoj po výrobě prototypu přímo zmrzačili a ukradli, tak se necítím vázaný smluvním ustanovením, že nejdříve máme nové přístroje v oblasti HPLC nabízet tomu jistému partnerovi. Takže projekt kompletního HPLC je volný. Naděje sehnat partnery je ale mizivá a rád bych viděl alespoň finanční zajištění, které by umožnilo projektům pokračovat, když na mě za posledních nejméně 16 let i při mém značném nasazení nezbyla po zaplacení nákladů ani koruna a šéfové partnerů se ještě tvářili, že jsme drazí a jak je odíráme. Na svých platech spotřebovali víc než byl celý hospodářský výsledek naší firmy za téměř 25 let existence.

Co se týče ECHMET, tak by mě zajímalo, jaké jsou s projektem plány. Zkusil jsme a úspěšně zkompiloval PeakMasterNG, ale pro nějaké otestování mi chybí databáze a nějaký příklad. Chci se i podívat co umí CEval, ale tam zatím s novější verzí GCC narážím na problém s kompilací HVL_MT

/home/pi/repo/echmet/src/HVL_MT/src/hvl.cpp: In function ‘HVL_RetCode LaunchWorkersAndWait(HVL_Range**, const HVL_Context*, double, double, double, double, double, double, double, fpcalcfun)’:
/home/pi/repo/echmet/src/HVL_MT/src/hvl.cpp:763:2: error: ‘MPFR_TRY_BEG’ was not declared in this scope
  MPFR_TRY_BEG
  ^~~~~~~~~~~~

[MadCatX]

Co se týče ECHMET, tak by mě zajímalo, jaké jsou s projektem plány.

Mně zcela upřímně taky... :)

Zkusil jsme a úspěšně zkompiloval PeakMasterNG, ale pro nějaké otestování mi chybí databáze a nějaký příklad.

Hustý... dost dlouho jsem byl přesvědčen, že to podle toho postupu v README nikdo jiný nezkompiluje. Databáze je bohužel dílem někoho jiného, takže švihnout ji jen tak na GitHub pod GPL licencí není dost dobře možné. Řešením je stáhnout oficiální binárku PMNG pro Windows a databázi odtamtud vykopírovat. Návod s nějakými příklady tam je taky - link. Předem se omlouvám za nutnost registrace, z mé hlavy to není a nemohu s tím mnoho udělat...

Chci se i podívat co umí CEval, ale tam zatím s novější verzí GCC narážím na problém s kompilací HVL_MT

/home/pi/repo/echmet/src/HVL_MT/src/hvl.cpp: In function ‘HVL_RetCode LaunchWorkersAndWait(HVL_Range**, const HVL_Context*, double, double, double, double, double, double, double, fpcalcfun)’:
/home/pi/repo/echmet/src/HVL_MT/src/hvl.cpp:763:2: error: ‘MPFR_TRY_BEG’ was not declared in this scope
  MPFR_TRY_BEG
  ^~~~~~~~~~~~

Díky, mělo by to být opravené. Za tenhle megahack jsem si asi nic jiného nezasloužil. Jinak HVL_MT silně doporučuji kompilovat s podporou MPFR, jinak bude pro praktická data téměř nepoužitelná. (Celá šaškárna s MPFR_[TRY|CATCH]_* je odporný workaround chování libmpfr, která v určitých případech při překročení určitého počtu platných číslic bez milosti zavolá abort() a sundá celý program. Doporučuji tuhle hrůzu vyřadit volbou -DCATCH_MPFR_ASSERTS=OFF, měl by to být default.)

[Pavel Píša]

Dík, na to použít -DUSE_MPFR=ON jsem přišel. Nepodařilo se mi dostat do EDII, aby libHPCS hledal v /opt/emchet/lib . Tak jsem to zatím na jeden běh ohackoval přidáním příslušného L do generovaných link.txt. Tím jsem vybuildoval CEval, ale opět, nevím kam namířit na EDII, tak aby to chodilo. Mám pouze /opt/echmet/bin/EDIICore .

Skript na vybuildování jsem sestavoval spíš z CMakeLists.txt a pro a pri než podle README. Obecně by se hodilo vytvořit git, který by ty ostatní natáhl jako submoduly a přidal toplevel projekt, který by do ostatních předával cesty. Natvrdo zakódované cesty do home v pri nejsou moc pěkné. Ale plně to chápu a minimálně stylem řešení (Qt5, D-bus, MPFR a i to cmake, které sice nemám nejraději, ale je dnes asi nejpoužitelnější/nejpoužívanější) se mi projekt jako celek líbí a rád bych viděl, k čemu vlastně je. Jestli se v něm dá nějaký záznam zobrazit .

#!/bin/sh

EMCHET_INST_DIR=/opt/echmet

(cd src/ECHMETCoreLibs && git pull ) || exit 1
(cd build/ECHMETCoreLibs && cmake -DCMAKE_CXX_FLAGS="-I/usr/include/eigen3" -DCMAKE_C_FLAGS="-I/usr/include/eigen3" -DCMAKE_INSTALL_PREFIX:PATH=$EMCHET_INST_DIR ../../src/ECHMETCoreLibs && make) || exit 1
(cd build/ECHMETCoreLibs && make install ) || exit 1

(cd src/HVL_MT && git pull ) || exit 1
(cd build/HVL_MT && cmake -DUSE_MPFR=ON -DCMAKE_CXX_FLAGS="-I/usr/include/eigen3" -DCMAKE_C_FLAGS="-I/usr/include/eigen3" -DCMAKE_INSTALL_PREFIX:PATH=$EMCHET_INST_DIR ../../src/HVL_MT && make) || exit 1
(cd build/HVL_MT && make install ) || exit 1

(cd src/libHPCS && git pull ) || exit 1
(cd build/libHPCS && cmake -DUSE_MPFR=ON -DCMAKE_CXX_FLAGS="-I/usr/include/eigen3" -DCMAKE_C_FLAGS="-I/usr/include/eigen3" -DCMAKE_INSTALL_PREFIX:PATH=$EMCHET_INST_DIR ../../src/libHPCS && make) || exit 1
(cd build/libHPCS && make install ) || exit 1

(cd src/EDII && git pull ) || exit 1
(cd build/EDII && CONFIGURE_ENV="LDFLAGS=-L$EMCHET_INST_DIR/lib" cmake -DUSE_MPFR=ON -DCMAKE_CXX_FLAGS="-I/usr/include/eigen3 -I$EMCHET_INST_DIR/include" -DCMAKE_C_FLAGS="-I/usr/include/eigen3 -I$EMCHET_INST_DIR/include" -D"CMAKE_INSTALL_PREFIX:PATH=$EMCHET_INST_DIR" ../../src/EDII && make) || exit 1
(cd build/EDII && make install ) || exit 1

(cd src/ECHMETUpdateCheck && git pull ) || exit 1
(cd build/ECHMETUpdateCheck && cmake -DCMAKE_INSTALL_PREFIX:PATH=$EMCHET_INST_DIR ../../src/ECHMETUpdateCheck && make) || exit 1
(cd build/ECHMETUpdateCheck && make install ) || exit 1

(cd src/LEMNG && git pull ) || exit 1
(cd build/LEMNG && cmake  -DCMAKE_CXX_FLAGS="-I$EMCHET_INST_DIR/include/ECHMET/CoreLibs -I/usr/include/eigen3" -DECHMET_CORE_LIBS_DIR=$EMCHET_INST_DIR  -DCMAKE_INSTALL_PREFIX:PATH=$EMCHET_INST_DIR ../../src/LEMNG && make) || exit 1
(cd build/LEMNG && make install ) || exit 1

(cd src/PeakMasterNG && git pull ) || exit 1
(cd build/PeakMasterNG && /usr/lib/x86_64-linux-gnu/qt5/bin/qmake ../../src/PeakMasterNG/PeakMasterNG.pro PREFIX=$EMCHET_INST_DIR && make) || exit 1
(cd build/PeakMasterNG && make install ) || exit 1

(cd src/CEval && git pull ) || exit 1
(cd build/CEval && /usr/lib/x86_64-linux-gnu/qt5/bin/qmake ../../src/CEval/CEval.pro PREFIX=$EMCHET_INST_DIR && make) || exit 1
(cd build/CEval && make install ) || exit 1

[MadCatX]

Dík, na to použít -DUSE_MPFR=ON jsem přišel. Nepodařilo se mi dostat do EDII, aby libHPCS hledal v /opt/emchet/lib .

Při sestavení by mělo stačit použít -DLIBHPCS_DIR=/opt/echmet/<adresář s include a lib>...

Tak jsem to zatím na jeden běh ohackoval přidáním příslušného L do generovaných link.txt. Tím jsem vybuildoval CEval, ale opět, nevím kam namířit na EDII, tak aby to chodilo. Mám pouze /opt/echmet/bin/EDIICore .

EDII je samostatná binárka, která běží jako služba. CEval se při prvním startu zeptá, kde má hledat EDIICore a v případě potřeby si ho sám spustí. S CEvalem komunikuje buď D-Busem nebo local socketem.

Skript na vybuildování jsem sestavoval spíš z CMakeLists.txt a pro a pri než podle README. Obecně by se hodilo vytvořit git, který by ty ostatní natáhl jako submoduly a přidal toplevel projekt, který by do ostatních předával cesty. Natvrdo zakódované cesty do home v pri nejsou moc pěkné.

Zrovna QMake je na nějakou uživatelem definovanou konfiguraci docela nešikovný; nacpat parametry buildu aspoň do .pri je zdá se jediné jakž takž schůdné řešení. Řešit to submoduly apod. jsem zvažoval, problém je, že CEval byl původně o hodně jednodušší a spousta věcí se tam doslova a do písmene doprasila jako brutální "afterthought", i ta komunikace s EDII přes D-Bus je tak trochu hack :) To už by se spíš vyplatilo napsat to celé znovu s nějakou modulární a trochu promyšlenou architekturou...

[Pavel Píša]

Tak jen pro informaci, podařilo se mi vše zkompilovat i pustit. Spiš se na to dívám, jako na zajímavost, protože můj obor jsou víc ty přístroje a elektronika. Pro PeakMasterNG by bylo zajímavé mít rovnou nějaký pěkný příklad s nějakým složitějším složením látek. Pro CEval jsem ty dostupné zkusil. Zajímavá je podpora NetCDF, ale asi je to jen načítání z jednoho konkrétního typu souborů. Podpora standardizovaného výměnného formátu nám v CHROMuLANu chyběla. Bohužel i ASCII alternativa k binárnímu formátu vznikla dříve, než se rozšířil JSON a XML bylo na začátek pro nás asi příliš složité.

[MadCatX]

Díky! Konečně vím, že množina osob schopných zkompilovat můj kód je větší než jedna :) Jen tak pro zajímavost, když jste na to narazil: Podpora pro NetCDF se do CEvalu dostala úplnou náhodou na žádost jednoho člověka odkudsi z Německa; dalo se to napsat za ani ne dvě hodiny. Ta "specializace" NetCDF souborů obsahujících chromatografický záznam by prý měla být jakž takž standardní a podporovaná různými softwary. Prakticky jsem to ovšem nezkoušel...

[r233]

Ale nejaky sikovny student by je mohl naimplementovat v ramdi diplomove prace...

[MadCatX]

To by asi mohl ale lopotit se s grafickým frontendem v rámci DP bych žádnému studentovi fakt nepřál. Jednak mi přijde, že se na tom student mnoho nenaučí, protože jde vesměs o lepení tlačítek, sosání dat z nějaké DB a ošetřování všemožných corner-casů (=predpokládej, že user může být úplný dement), druhak se obávám, že čas, který na nakódění diplomky běžně je asi nestačí na to, aby vzniklo něco doopravdy použitelného. Zajímavé projekty pro studenty technických VŠ bysme nepochybně vymysleli ale zrovna code-monkeying nad UI bych k tomu nezařazoval.

[biolog]

Jak píše MadCatX, linuxový ovladač pro tu GPIB kartu určitě existuje. Ale výrobce nedodává popis komunikačního protokolu pro ty přístroje. BTW Ty přístroje jsou Waters 2996 PDA Detector (nahoře) a Waters 2695 HPLC (dole).

[Ivan]

Pokud jde o ten HAL. Pokud se dobre pamatuju tak je to ocekavane chovani.

Pokud ches natahnout jiny hal.dll tak bys' mel spustit sysprep. Ten pripravi Windows na klonovani na to ze pri pristim boot-u mohou nabehnout na jinem HW. Alespon takhle nejak se to resilo kdyz se woknam zmenil radic disku.

[PetebLazar]

Článek mi připomíná, že budu muset oživit své dřívější pokusy s využitím PCI=>PCIe redukce (v PCI passthrough). PCI sloty z moderních MB za nedlouho zmizí nadobro a rád bych měl ověřené/vyloučené řešení do budoucna (cena i levnějších USB=GPIB je docela značná).

A jak již bylo výše zmíněno i když výrobce u staršího přístroje nabízí vyšší verzi SW podporující novější OS, takový upgrade může znamenat stovky tisíc Kč. Investovat je do staršího přístroje, který může přestat fungovat klidně zítra se nemusí vyplatit.

Ad IOMMU group: Wendell z Level1techs zmiňoval, že u jím testovaného MB (X570?) měly i PCI 1x (4.0) sloty samostatnou IOMMU group což je pokrok proti X370/X470 kde byly samostatné IOMMU group typicky pro sloty PCIe 16x a M.2 slot. Rozšíří se tak možnosti PCI passthough bez ACS patche.

[Faceless man]

Identický starší HW nájdeš stále, či už na skládke alebo za pivo na bazosi ...

Vlastná skúsenosť - príklad z praxe - priemyselná váha na nákladné autá napojená na staručké HP s Windows 2000 a zviazaná s ISA kartou a HW kľúčom na LPT porte. Zo skládky elektronického odpadu boli v roku 2010 dotiahnuté 3 identické funkčné HPčka (za 5 eur kus len kôli ekonómke) - jedno sa odvtedy použilo a 2 čakajú na sklade na ich chvíľu + pravidelné zálohy 8GB IDE 44 PIN SSD disku na server :) Váha beží takmer nepretržite od januára 2000 a za celí čas boli 3 x menené disky a 1 x menené celé HPčko (kôli odídenej doske žiadna výmena, zobralo sa zo skladu iné HP). Čiže sa správam ekonomicky a ekologicky.

Takže do žiadnej virtualizácie či hraniu sa s IOMMU sa nehrniem - je to časovo a hlavne finančne náročné (nový HW, nový soft a hodiny nastavovania a to nevravím o neexistencii ISA slotu a LPT portu).

[kralyk z abclinuxu]

No to už by dost možná bylo jednodušší reverznout protokol tý váhy než tohle emulovat...

[Salamek]

Presne tak, driv nebo pozdeji to budou muset stejne udelat, a veci jako vaha jsou casto dost easy

[j]

Jasne, nekdo stravi 100+ (a to jako nejmin, 100 hodin je smesne malo) clovekohodin na reverzovani cehosi, misto toho aby za pivo poridil stary zelezo a vymenil ho.

[R]

V pripade vahy to moze byt nejaky jednoduchy protokol cez RS232 - to je za jeden den analyzovane a za druhy den implementovane. Bonusom su potom nove moznosti spracovania dat, ktore povodny system neumoznoval.

[j]

Jiste a dalsich 5 dnu to budes testovat abys ve finale jeste dalsi 3 mesice zjistoval, ze tam sou veci ktery se ti nepovedlo odchytit behem toho prvniho dne.

Nic jako "jednoduchy" v IT neexistuje. Xkrat sem resil implementace naprosto primitivnich veci ... klidne to bylo na 10 minut "analyza + implementace" a pak jeste mesice narazis na to, co vsechno to vlastne ovlivnuje.

Je to tak 2 mesice, co sem narazil u jednoho takovyho primitivismu po 10 letech pouzivani na situaci, ktera sice ridce, ale pravidelne, nastavala uz drive. Tentokrat se ji povedlo podchytit vcetne logu a popisu toho co se deje a proc.

Pokud mas letitej SW, kterej "proste funguje", je dost pravdepodobny, ze ty mesice do jeho odladeni nekdo investoval pred temi lety. A/nebo se uzivatele smirili s nejakymi neduhy, a uz je ani nevnimaji. Ani jedno nebude platit pro novou implementaci.

[/dev/random]

nevraviac o tom ze priemyselne vahy podliehaju pravidelnym reviziam a preskusaniam a ten povodny primitivny soft na to ma uz procesy, a nove vytvarat bude trosku oriesok...

[kralyk z abclinuxu]

Pokud mas letitej SW, kterej "proste funguje", je dost pravdepodobny, ze ty mesice do jeho odladeni nekdo investoval pred temi lety. A/nebo se uzivatele smirili s nejakymi neduhy, a uz je ani nevnimaji. Ani jedno nebude platit pro novou implementaci.

To je jasný, nicméně být majitelem/provozovatelem takového HW tak si minimálně nějakej ten dump komunikace udělám, možná i nějakou předběžnou krátkou analýzu. SW může být sebeodladěnější, ale až ho nebude na čem spustit, nebude to nic platný...

[j]

Otazka zni, jesli by nebylo jednodussi, ty XPcka pustit na tom HW primo. Je totiz vysoce pravdepodobny, ze ten system jako takovej by to rozdejchal. Uvedom si, ze support mu skoncil teprve letos. Jina vec je pochopitelne ten soft samotnej, IMO mas velkou kliku v tom, ze si nekontroluje zmenu HW, jinak bys byl v loji i takhle.

Znam osobne lidi, kteri maji HW nasyslino do zasoby, protoze u podobnych(a mozna i mnohem drazsich) masin, maji ovladaci PC na dosu. A presne jak pises, vymenit by to mozna slo, ale za stovky tisic nejmin. Nejak soudruzi totiz nepocitaj s tim, ze kdyz si nekdo koupi stroj za 50+M, ze ho bude pouzivat klidne taky 50+ let.

[MadCatX]

XPčka určitě nebudou mít ovladače pro USB3, NVMe a SATA řadič atp. na X370 chipsetu, navíc Ryzen má bug ve VME, kvůli kterému je problém na něm pustit XPčka i v paravirtualizaci. Support XPček skončil letos jen POS verzi, která běžela na nějakých embedded systémech. Vzhledem k tomu, že XPčka mají problém se vzpamatovat i ze změny řadiče disků na podporovaném HW, byla by to ještě větší kovbojka, než tohle.

[Odin1918]

Ja uz se lekl, ze se tento post tyka pana Jilka.

[trekker.dk]

Bacha na to, že Debian 10 používá jako výchozí nftables a pokud chcete filtrovat TCP/IP na bridgi, je lepší se vrátit k iptables...

Můžete napsat proč? Já zatím narazil na to, že chybí modul recent (i když možná funguje s tím zpětně kompatibilním iptables, ale nepřišel jsem na to, jak ho pomocí nft nastavit)

[alkoholik]

Misto recent zkus obycejny set s timeoutem. Asi takhle

[trekker.dk]

To není totéž. Set obsahuje jenom informaci o tom, jestli v něm daná (v mým případě) IP je nebo není. Recent umožňuje filtrovat podle toho, kolikrát za posledních pár sekund je daná IP zachycena. To potřebuju.

[alkoholik]

Nevim, co presne potrebujes udelat, ale mozna by to slo pres meters. Ale ty jeste nemam osahane.

[trekker.dk]

No, používám tohle:

iptables -A INPUT -p tcp -i eth0 --dport 80 -m recent --name flood --hitcount 20 --seconds 2 --rcheck -j DROP
iptables -A INPUT -p tcp -i eth0 --dport 80 --syn -m recent --name flood --set -j ACCEPT

Když přijde SYN paket na port 80, do tabulky "flood" se vytvoří záznam pro zdrojou IP adresu a uloží se do něj nějaký timestamp. Když jich přijde víc, timestampů se uloží víc:

src=92.63.194.15 ttl: 121 last_seen: 4297053550 oldest_pkt: 3 4297037105, 4297053550, 4297053550

To první pravidlo je splněné v případě, že pro zdrojovu adresu paketu je v tabulce 20 záznamů, které nejsou starší než 2 sekundy. Cílem je zablokovat roboty, co považují za dobrý nápad prolézat weby tak, že se na server naváže třicet spojení naráz. Několik spojení se jim povolí, ostatní syn pakety se dropnou a spojení se naváže až poté, co se ten syn paket pošle opakovaně.

Dneska už to není takový problém, takže bych se bez toho pravidla asi i obešel, ale na druhou stranu si říkám, že když je nějaký udělátor, co vezme syntaxi iptables a nastaví NF pravidla, tak by syntaxe pro nft mohla umět totéž...

[Jindřich Makovička]

Mělo by fungovat něco jako

ct state established,related accept

...

tcp dport http ct state new meter http size 65535 { tcp dport . ip saddr limit rate 10/second burst 20 packets } accept

[trekker.dk]

Díky, zkusím, až se k tomu dostanu.

[MadCatX]

Pochopil jsem, že podpora pro filtrování TCP/IP provozu v nftables ještě není taková jako v iptables. Tím, že se na bridgi standardně filtruje jen L2 provoz, musí se udělat "přeskok" z L2 do L3 a filtrovat to až tam, což s iptables jde. Jak říkám, nejsem žádný síťař, takže to možná jde i s nftables a byl jsem akorát líný na to to vymýšlet.

[trekker.dk]

No jo, tak mě holt čeká překvapení, až to budu zkoušet

[j]

K tomu asi toliko, ze na testovacim stroji nft mam a pravidelne chcipnou (nenactou se pravidla, a to ani rucne, je treba vyhodit modul z pameti a nacist ho znova ...), coz se s iptables nedeje. Tudiz to podle me na jakykoli ostry nasazeni jeste ani zdaleka neni.

[alkoholik]

Jasne, proto je nftables default v novem Debianu i RHELu.

[trekker.dk]

Pamatujte si: "j" ví všechno nejlíp. Nedávno tady dokonce tvrdil, že zjistit, jestli se na úvodní stránce ábíčka něco změnilo - za účelem zjištění, jestli je potřeba ji generovat nebo vrátit z cache - je pro něj záležitost na jeden SQL dotaz. Ve znalostech, zkušenostech a dovednostech se s ním nemůžete měřit, takže to nezkoušejte a budete mít hned lepší den

[alkoholik]

Ja uz ho mam davno v blokovanych.
Jenom obcas mam potrebu jeho blaboly vyvratit, protoze tu muze zblbnout omladinu.

[j]

Pise negramotnej idiot, odkaz kde sem neco takovyho tvrdil ...

Ostatne, systemd je taky ve spouste distrech default, coz nic nemeni na tom, ze to je zcela nepouzitelnej kram. Coz se dnes a denne potvrzuje ...

[NN]

Parada.

[r233]

Rozhodne zajimave. Resim neco podobneho - stary osc, ktery ma pc interne, ale je tam normalni uATX deska s P4. Nicmene nejsem prvni, kdo to bude upgradovat. Dokonce nekdo napsal ovladec pro tu kartu do W7, ale to toho se mi asi poustet nechce. Rozhodl jsem se tam nechat WXP. ma to nekolik problemu - muse to bezet na uniprocesor HAL (jinak si stim ten origo driver neporadi). Optimalni platforma je Intel Ivy bridge, kde je ofic. podpora pro WXP. Jeste jde i o to, ze ten SW realtime pocita nejake analyzy, ktere vyuzivat a i nektere dalsi cinosti, ktere znacne praci s oscikem zpomaluji - da se tedy tezit z vysokeho vykonu. Postupne tedy shanim desky. Skutecny orisek to ma jen jeden, a to je pripojeni vnitrniho LCD, pro ktery budu muset vyrobit mustek (ale da se, umim takove veci).

[Dreit]

Před pár dny se GPIB načalo na EEVblog, ale hádám že ovládací software bude i něco počítat a ne jen zobrazovat čísla.

[MadCatX]

Parádní! Pro pouhé vyčítání dat z přístrojů to určitě stačí, pro naše potřeby bohužel vyžadujeme o dost sofistikovanější řešení. Škoda, klidně bych to i na něco použil...