| poslední úprava: 30.7.2019 09:24
Portál AbcLinuxu, 20. dubna 2024 04:59
22.7.2019 00:47
| Přečteno: 3872×
|
| 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.
Ž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.
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.
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.
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... :) (*)
#! /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...
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.
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.
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é.
Tohle jsem nakonec zavrhl s tím, že se to ve vhodné momenty prostě odzálohuje ručně. (Tak určitě, že jo...)
Done, viz aktualizovaný skript.
Nakonec na povrch vyplulo ještě pár nedostatků, jež bylo nutné vyřešit a sice:
-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.
-no-quit.
-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
Tiskni
Sdílej:
24.7.2019 10:23
Max | skóre: 72
| blog: Max_Devaine
24.7.2019 21:51
Max | skóre: 72
| blog: Max_Devaine
24.7.2019 21:54
Max | skóre: 72
| blog: Max_Devaine
26.7.2019 18:11
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
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í :)
22.7.2019 13:04
Salamek | skóre: 22
| blog: salamovo
22.7.2019 13:50
Max | skóre: 72
| blog: Max_Devaine
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í.
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.
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ý chromatografSchvá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.
24.7.2019 09:54
xkucf03 | skóre: 49
| blog: 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.
24.7.2019 10:29
Max | skóre: 72
| blog: Max_Devaine
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 :)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?
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.htmlPrototyp 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.
28.7.2019 19:15
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
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.
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 ^~~~~~~~~~~~
Mně zcela upřímně taky... :)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.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...
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 sChci 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 ^~~~~~~~~~~~
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.)
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
Při sestavení by mělo stačit použítDí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 .
-DLIBHPCS_DIR=/opt/echmet/<adresář s include a lib>...
EDII je samostatná binárka, která běží jako služba. CEval se při prvním startu zeptá, kde má hledatTak 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 .
EDIICore a v případě potřeby si ho sám spustí. S CEvalem komunikuje buď D-Busem nebo local socketem.
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...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é.
23.7.2019 18:15
Salamek | skóre: 22
| blog: salamovo
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ý...
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)
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 ACCEPTKdyž 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éž...
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
3.8.2019 11:47
Dreit | skóre: 15
| blog: Dreit a jeho dračí postřehy
| Královehradecký kraj
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.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.