Obsah

VMware Player v prostředí bezdiskového linuxu »

Výrobcem zařízení, které byly zakoupeny v roce 2018 jako stavebnice, byla Open Source Robotics Foundation, Inc.. A na Karlově náměstí se poprvé použily v zimním semestru univerzitního roku 2018/2019 k praktickému cvičení v rámci předmětu B3M33MKR: Mobile and and Collective Robotics, kde s nimi pracoval Gaël Écorchard s Karlem Košnarem.

Po technické stránce měl tyhle stroje na starosti Petr Novák.

Tehdy se ještě používaly jako Non-Diskless stroje s předinstalovanou linuxovou distribucí Ubuntu, pro kterou se vyvíjí softwarový balík utilit pro práci se senzory, distribovaný pod názvem ROS – viz PDF Karla Košnara https://cw.fel.cvut.cz/b191/_media/courses/b3m33mkr/turtlebot.pdf Ale již v říjnu 2018 se objevil požadavek, zda-li je technicky možné – v rámci sjednocení vývojového prostředí na katedře DC – aby na TurtleBotech běžel stejný operační systém, jako na ostatních laboratorních strojích – Full-Diskless Debian.

Co je TurtleBot?

TurtleBot, je robotické zařízení, jeho „tělem” a zároveň nosičem senzorů je robotický vysavač a „mozkem” mikropočítač, kterým je v případě našich strojů Intel NUC.^[1] Ten sice má ethernetový port, přes který by mohl Intel NIC komunikovat po síti, ale pak by nebyl TurtleBot autonomním zařízením.

TurtleBot, je v prvé řadě autonomní robot. Pokud by se měl pohybovat prostorem upoutaný drátem, byl by to stejný anachronismus jako potápěč 19. století spojený vzduchovou hadicí s pramicí na hladině, v době dýchacích potápěčských přístrojů s uzavřeným okruhem.

TurtleBoti, kteří se se využívají coby nosiče nejrůznějších senzorů, s nimiž se studenti učí pracovat a na základě nasnímaných dat řídit jejcih pohyb v prostoru, musí být nezávislí, proto komunikují primárně přes Wi-Fi. Jenže Full-Diskless si jádro s ramdiskem stahuje přes PXE, a to je čistě ethernetová technologie, kterou Wi-Fi – přes kterou komunikují TurtleBoty – nepodporuje. A mým úkolem bylo tenhle problém vyřešit.

Konverze Non-Diskless systému TurtleBota na Half-Diskless

To byl první krok, který byl učiněn hned na konci zimního semestru roku 2018 – období mezi semestry totiž byla v minulosti jediná doba, kdy se dalo něco v laboratořích řešit, což dnes (2024) již bohužel neplatí. Nebyla to žádná novinka. Už od roku 2016 jelo v rámci disklessové infrastruktry DC v tomhle režimu několik virtuálních strojů. Novinkou bylo pouze to, že tentokrát bylo nutné v ramdisku vyřešit také síťovou konektivitu stroje. Half-Diskless se totiž liší od Full-Disklessu tím, že jádro s ramdiskem nezavádí zavaděč poskytovaný on-line z DHCP serveru, ale lokálně instalovaná verze zavaděče a jádro po nahození Wi-Fi dál pokračuje v zavádění systému expertovaného přes NFS server podobně jako Full-Diskless.

Bohužel, velice záhy se ukázalo, že propustnost připojení přes Wi-Fi nestačí a před reálným nasazením do výuky bude nutné vyřešit další technologické problémy.

Omezující faktory u TurtleBotů

Přetížená Wi-Fi: Na rozdíl od laboratorních strojů a studentských notebooků TurtleBoty žádnou jinou alternativu pro síťové připojení nemají. A již v samém počátku, kdy ještě nebylo běžné, že by si studenti nosili sebou své vlastní notebooky, s nimiž by se připojovali na laboratorní Wi-Fi, určenou pro TurtleBoty, bylo nutné pro vymyslet řešení, jehož cílem bylo v maximální míře minimalizovat objem dat přenášených po síti během práce s TurtleBotem.
Problematická ethernetová kabeláž: Dál vyšlo najevo, že laboratoř E:130, kde se nalézá pracoviště s TurtleBoty, má dlouhodobě ethernetovou kabeláž ve velmi špatném stavu. Bohužel z nejrůznějších důvodů na rekonstrukci ještě nedošlo. Je nutné se o tom zmínit, jelikož jde o výrazně limitující faktor, a každý kdo s TurtleBotem pracuje by měl znát jeho slabiny, aby mohl zvolit optimální řešení a zbytečným problémům se vyhnout.

Internetové připojení si lze představit jako vodovodní trubku, kterou za určitý čas proteče jen omezené množství vody. A celá laboratoř E:130 – včetně Wi-Fi AP, je připojená přes jeden 1 GBitový port. Tedy trubku, přes kterou za 1 sekundu proteče maximálně 128MB. A jeden Full-Diskless, ještě dříve než se na něj vůbec někdo přihlásí, si po sítu z NFS serveru pokaždé stáhne zhruba 300 MB dat.

Jen pro představu. V roce 2018 bylo na tuhle trubku „navěšeno” 8 laboratorních desktopů, tři laboratorní desktopy pro robotické ruky a jedno WiFi AP, přes které se připojovalo 8 TurtleBotů.

Aby to vše najelo ve Full-Diskless módu, muselo přes tuhle trubku projet cca 5,7 GB. Což by za normálních okolností zabralo asi 44 sekund. Jenže kvalita kabeláže v E:130 je tak špatná, že u delších drátů klesala rychlost datového přenosů až na úroveň 100 MBitové sítě, která má propustnost pouhých 11,5MB/s. A to už bylo pod hranicí použitelnosti. A jako naschvál, na jednom takovém drátu „viselo” AP, které mělo zajistit konektivitu pro 8 TurtleBotů.

Propustnost Wi-Fi: Je u 2,7GHz kde je teoretické maximum kolem 56Mbit/s, ještě horší než u 100 Mb sítě, neboť se maximální přenosová rychlost cca 2MB/s dělí mezi všechny stroje připojené k AP – každý studentský notebook, se kterým se musí TurtleBoty dělit o Wi-Fi tak situaci zhoršuje. A pokud s nimi pracují studenti, co NECHÁPOU, že i data jejich uživatelských profilů se honí přes tu samou Wi-Fi, jsou-li přihlášeni svým uživatelským jménem, může úroveň použitelnosti spadnout na nulu.

Co bylo v našich silách

V prvé řadě jsme přemístili Wi-Fi AP na protilehlou stěnu, kde bylo připojeno kratším drátem, abychom dosáhli co možná největší propustnosti ethernetového připojené Wi-Fi AP.
A TurtleBoty byly přepracovány na Half-Diskless, který si na lokální blokové zařízení kešoval použité soubory.

TurtleBot se liší od normálního PC v prvé řadě tím, že nemá připojenou myš, ani klávesnici. Všechny USB porty jsou totiž obsazeny připojenými senzory – tedy až na jeden, kterým je připojený dotykový displej. Jenže ten funguje až po zavedení operačního systému, kdy se načtou potřebné ovladače.

Nejprve tedy bylo nutné každého TurtleBota přenastavit tak, aby zaváděl disklessový operační systém přes PXE, aniž by vyžadoval manuální přepnutí. Ke každému tedy bylo nutné připojit dočasně klávesnici a přenastavit UEFI.

Každý měl z výroby zapnutý legacy boot, který bylo potřeba vypnout – teprve po uložení změny a restartu TurtleBota nabídlo lokální UEFI, možnost zavádění přes UEFI PXE.
Pak teprve bylo možné v konfiguraci povypínat všechny ostatní možnosti zavádění a změnit pořadí zavádění následujícím způsobem:
1. Na první místo dát UEFI PXE Boot…
2. …a teprve za touhle volbou ponechat zavedení lokálního zavaděče GRUB verze 2, který do té doby spouštěl lokálně instalované Ubuntu.

Je velmi důležité bylo v menu Boot Configuration vypnout parametr Unlimited Boot to Network Attempts. Bez toho se totiž Intel NUC neustále pokoušel zavádět systém jenom přes PXE a na lokální boot vůbec nedošlo!

Zde je potřeba zmínit, že naše TurtleBoty přesto že spadají do verze 2 nejsou stejné. V říjnu 2018, kdy přišlo zadání rozběhat stejný operační systém jako je u ostatních laboratorních strojů, se používaly TurtleBoty verze 2, které ještě používaly SSD disky. Další várka strojů, která dorazila počátkem roku 2019, měla také Intel NUCy, ale s výkonnějšími procesory, větším množství RAM a rychlejšími NVME disky. Jenže dodávka nedošla kompletní a díky liknavosti zaměstnance, který měl za úkol stroje sestavit, se přišlo až v září 2019 (tedy zhruba půl roku po dodání), že je většina dodaných dotykových displejů poškozených. Dotyčný sice dostal za úkol displeje vyreklamovat, jenže nevyreklamoval nic a zodpovědnosti se zbavil tím, že koncem roku odešel na CIIRC. Situaci jsme tedy nakonec vyřešili až v únoru 2020 tím, že se přehodily displeje ze starších, výkonostně slabších TurtleBotů, na stroje novější. V současné době tedy máme v provozu:

2 starší stroje

a 6 strojů novějších

První řešení na bázi mcachefs

Vynucená pauza od března 2020 do října 2021

Krátce na to, v březnu 2020, vypukla koronavirová panika a na TurtleBoty padal více než rok prach, přestože byly připraveny k provozu – ovšem to by vyžadovalo pracovní sílu, přítomnou v laboratoři, která by na základě pokynů od studentů zajištovala fyzické přemístění TurtleBota od nabíječky do pracovního pole a instalovanou on-line kameru, přes kterou by mohli vzdáleně pracující studenti sledovat co dělá TurtleBot.

Kritická slabina Full-Diskless řešení přes Wi-Fi

Studentské notebooky připojené na laboratorní Wi-Fi

Roku 2018 ještě nepředstavovaly studentské notebooky pro TurtleBoty závažnější problém – nebylo jich mnoho. Ale během koronavirového šílenství přizpůsobili vyučující svou výuku tomu, že většina studentů pracuje s TurtleBoty z vlastních notebooků, a to sebou přineslo řadu negativních dopadů, s nimiž roku 2018 nikdo nepočítal, které bylo nutné vyřešit. Robotické ruky si naštěstí sebou vzali do CIIRCU. Počet laboratorní PC se o dva snížil, takže následující přehled popisuje je aktuální stav k polovině února 2024.

A vzhledem ke špatnému stavu kabeláže v místnosti je nedostatek ethernetových přípojných bodů. A na těch, co ještě fungují je navěšeno jedno Wi-Fi AP a dva 8 portové switche, do kterých jsou zapíchnutá školní laboratorní PC. A vše, co je v téhle místnosti připojeno do sítě, se dělí o 1GBit!

Pro studentské notebooky je v současné chvíli vyhrazeno celkem 8 ethernetových portů. Do některých by měly být napevno zapojené patch kabely s USB ethernetovými adaptéry, pro notebooky co nedisponují ethernetovým portem.

V laboratoři je nedostatek silových zásuvek – každý TurtleBot vyžaduje svoji nabíjecí stanici (8x), každé laboratorní PC s monitorem vyžaduje 2 silové zásuvky (celkem

Slabiny autonomního Half-Diskless založený na mcachefs nevyhovující se ukázalo již od obnovení prezenční výuky, v zimním semestru 2021. Jenže bylo příliš pozdě na jiné řešení, proto se opět přešlo na Full-Diskless, přes jeho nevýhody a realizaci nového konceptu, založeného na squashfs odložit na neurčito, protože bylo nutné prioritně dořešit jiné, naléhavější úkoly jako:

sjednocení domovských adresářů
a sjednocení operačního systému

Autonomní Half-Diskless

Na realizaci tohoto konceptu došlo až na konci roku 2023. Ale implementace zabrala období od prosince 2023^[2] až do poloviny února 2024, protože bylo nutné paralelně připravit nástroje pro přípravu squshovaných vrstev a jejich kryptování.

Hardware

Parametry NUC6i5SYB Intel(R) Client Systems verze ?

4 jádra CPU Intel(R) Core(TM) i5-6260U CPU @ 1.80GHz

8 GB RAM (2x 4GB modul Kingston)

Ethernet Connection I219-LM (rev 21)

01:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a)

root@turtle04:~# lsblk -o NAME,FSTYPE,LABEL,MOUNTPOINT,SIZE,MODEL
NAME        FSTYPE LABEL  MOUNTPOINT   SIZE MODEL
nvme0n1                              119.2G INTEL SSDPEKKW128G7
|-nvme0n1p1 vfat                       512M 
|-nvme0n1p2 ext4                      39.1G (40000)
|-nvme0n1p3 swap                       7.9G 
`-nvme0n1p4 btrfs  system             58.6G (60000)

Parametry NUC7i7DNKE Intel(R) Client Systems verze J85069-205

8 jader CPU Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz

8 GB RAM (1x 8GB modul Kingston + volný slot)

Ethernet Connection I219-LM

01:00.0 Network controller: Intel Corporation Wireless 8265 / 8275 (rev 78)

root@turtle08:~# lsblk -o NAME,FSTYPE,LABEL,MOUNTPOINT,SIZE,MODEL NAME FSTYPE LABEL MOUNTPOINT SIZE MODEL nvme0n1 223.6G KINGSTON SA1000M8240G |-nvme0n1p1 vfat 512M |-nvme0n1p2 ext4 39.1G (40000) |-nvme0n1p3 swap [SWAP] 7.9G `-nvme0n1p4 btrfs system 58.6G (60000) `-nvme0n1p5 ext3 cache 97.7G

~# lsmod | grep iw
iwlwifi               151552  0
cfg80211              598016  1 iwlwifi

~# cat /proc/partitions 
major minor  #blocks  name

 259        0  234431064 nvme0n1
 259        1     524288 nvme0n1p1 EFI flags boot, esp (zachovat)
 259        2  225643520 nvme0n1p2 ext4 Ubuntu (zmenšit) orig 220355, nově 200000
 259        3    8261632 nvme0n1p3 linux-swap (posunout)

NUC pro TurtleBoty je dodáván s předinstalovaným Ubuntu, proto bylo nutné:

zmenšit diskový odddíl /dev/nvme0np2 na kterém je souborový systém ext4 s Ubuntu
posunout diskový odddíl /dev/nvme0np3 na kterém je swap (ten bude využívat i disklessový OS)
vytvořit nový diskový odddíl /dev/nvme0np4

Tento nově vytvořený diskový oddíl /dev/nvme0np4 byl naformátován na souborový systém Btrfs, aby bylo možné subvolume pro systém nainstalovaný přes debootstrap snapshotovat.

Instalace

Formátování fs, vytvoření subvolume,…

/mnt# debootstrap --verbose --include=firmware-iwlwifi,isc-dhcp-common,openssh-server,wpasupplicant,nfs-common --variant=minbase --components main,contrib,non-free --arch=amd64 unstable ./

…snapshot, bind {/dev,/proc,/sys}, chroot

Editace grub.cfg

Pro zavádění jádra disklessového systému se využívá zavaděč předinstalovaného Ubuntu. K tomu byla nutná následující úprava souboru /mnt/grub/grub.cfg:

...

Automatizace procesu distribuce na ostatní TurtleBoty

Aby vše fungovalo jak má, musí mít všechny TurtleBoty stejnou výchozí konfiguraci, upravený soubor grub.cfg na předinstalovaném Ubuntu a vytvořený diskový oddíl /dev/nvme0np4, s nainstalovaným ramdiskem s podporou wi-fi a jádrem.

Celkově trvá příprava jednoho TurtleBota 50 minut čistého času, a vyžaduje celkem 14 restartů!

Následující body popisují okolnosti a důvody restartu. Nebyly pokažd

1, klávesa F2

vypnutí secure bootu a legacy módu

2, klávesa F2

Nastavení bootování v pořadí:

- IPv4 PXE
- Ubuntu
- IPv6 PXE

Přepnout na Advanced a vypnout všechny ostatní možnosti zavádění
Pak přepnout na Advanced zobrazení Devices, a z Add.In Config vytáhnout MAC adresu pro drátové připojení, která se vloží do nového záznamu v DHCP

Přidat nový záznam do DHCP a restartovat DHCP server!

Uložit změny biosu TurtleBota přes F10 a reboot.

3, Boot na drátě přes PXE - Volba Turtle v menu

Přihlásit se jako root
Vypnout swap:

# swapoff -a

Spustit gparted a upravit rozdělení disku (viz stránka TurtleBot) každou změnu je třeba ihned realizovat!!!
namountovat původní systém na /mnt, přejmenovat původní grug.cfg a nakopírovat z /root/nuc7 nový.
odmountovat /mnt a namountovat místo něj Btrfs oddíl - do kterého se nakopírují symlinky na jádro, které se při použití cache natáhně
Vytáhnout MAC adresu pro Wi-Fi, která se vloží do nového záznamu v DHCP

Přidat nový záznam do DHCP a restartovat DHCP server!

Restartovat příkazem reboot

4, Boot na drátě přes PXE - výchozí volba, ale přidat k ní parametr break=overlay-init

V ramdisku příkazem cat nakopírovat:

jádro z adresáře /root/boot/ souboru /tmp/cache/vmlinuz.backup

(initramfs) cat /root/boot/vmlinuz-… > /tmp/cache/vmlinuz.backup

a ramdisk z adresáře /root/boot/ jako /tmp/cache/initrd.img.backup

(initramfs) cat /root/boot/initrd.img-… > /tmp/cache/initrd.img.backup

a vytáhnout do keše moduly:

(initramfs) find /root/usr/lib/modules -type f -exec cat '{}' > /dev/null \;

Pokračovat příkazem 'exit'

Pokud skončí jádro v Panic => restart čudlem!

Pokud zůstane viset => použít REUSB

5, Boot na drátě přes PXE - výchozí volba

systemd rpcbind.service: Failed at step EXEC spawning /sbin/rpcbind: Transportendpoint is not connected

Pokud skončí jádro v Panic => restart čudlem!

Pokud zůstane viset => použít REUSB

6, Boot na drátě přes PXE - výchozí

Reached target Remote File Systems (Pre)

fb0: switching to inteldrmfb form EFI VGA => REUSB

Reached target Swap

printk-systemd: 23 output lines suppressed due to ratelimiting

systemd rpcbind.service: Failed at step EXEC spawning /sbin/rpcbind: Transportendpoint is not connected

915drmfb framebufer device

systemd [1]: Caught <BUS>, core dump failed (…)

zhavarovaný modul libsystemd-shared

Nyní může následovat 6 až 8 vynucených restartů. Kvůli nakešování základních souborů

Pokud skončí jádro v Panic => restart čudlem!

Pokud zůstane viset => použít REUSB

Po úspěšném otevření obrazovky je třeba NUC vypnoutm vytáhnout drát a vyzkoušet:

13, Boot přes wifi standard

14, Boot přes wifi záložní (vmlinuz.backup a initrd.img.backup)

Export NFS adresáře

Na NFS serveru byl vytvořen nový Btrfs subvolume s názvem bullseye, který byl vyexportován přes NFS s následujícími parametry:

/srv/diskless/version/bullseye (rw,fsid=11,nohide,async,subtree_check,no_root_squash)

Výsledek uvedeného nastavení po exportu:

(rw,async,wdelay,nohide,no_root_squash,fsid=11,sec=sys,rw,secure,no_root_squash,no_all_squash)

Úprava instalace disklessu

Po spuštění lokálního systému:

Nahození aplikace wpa_supplicant
Získání adresy přes aplikaci dhclient
Mount NFS adresáře budoucího disklessu

Přejmenování

# hostnamectl set-hostname bullseye

Vytvoření ramdisku s podporou Wi-Fi

Při vytvoření ramdisku s podporou Wi-Fi jsem postupoval podle webové stránky Marka Fargase. Bohužel se ukázalo, že uvedený postup pro připojení přes WPA2 nestačí.

Aby fungovalo ověřování přes WPA2, musí mít wpa_supplicant k dispozici další dva jaderné moduly: ccm a ctr^[3]. Bez nich funguje pouze anonymní připojení.

busybox

Soubor /etc/initramfs-tools/hooks/enable-wireless, je spustitelný skript, který spustí příkaz update-initramfs -u při sestavení ramdisku. Skript se postará o nakopírování potřebných modulů, utilit, knihoven a konfiguračních souborů pro nahození wi-fi, tak aby byly splněny všechny potřebné závislosti.

#!/bin/sh
set -e
PREREQ=""
prereqs(){
   echo "${PREREQ}"
}
case "${1}" in
   prereqs)
      prereqs
      exit 0
      ;;
esac
. /usr/share/initramfs-tools/hook-functions
manual_add_modules cfg80211 mac80211 iwlwifi iwlmvm ccm ctr
copy_exec /bin/ip
copy_exec /sbin/wpa_supplicant
copy_exec /sbin/wpa_cli
copy_exec /sbin/dhclient
copy_exec /sbin/dhclient-script
copy_file config /etc/initramfs-tools/wpa_supplicant.conf /etc/wpa_supplicant.conf

V tomto ukázkovém skriptu je uvedena pouze je minimální sada nástrojů potřebná k rozběhání připojení přes wifi na turtlebotu. Na většinu ostatních věcí stačí příkazy, které jsou součástí busyboxu. V souvislosti s připojením se ale mohou vyskytnout různé problémy, proto není od věci si do ramdisku přidat i užitečné nástroje, které umožní testování kvality síťového připojení či testování blokového zařízení:

Utilita	Inst. balík	Použití
ip	`iproute2`	Příkaz ip, se kterým pracuje busybox má omezené konfigurační možnosti, proto se k nastavení sítě v našem případě používá plnotučný nástroj ip
iwconfig	`wireless-tools`	Příkaz iwconfig je užitečný v pokud si nejste jisti zda wpa_supplicant navázal spojení. S jeho pomocí totiž můžete zjistit aktuální nastavení vašeho zařízení, nebo zda-li došlo k připojení. Pokud si přidáte i nástroj iwlist, který je ve stejném instalačním balíku, tak si můžete vypsat i parametry sítí, které vaše wifi "vidí".
dhclient	`isc-dhcp-client`	Standardně se pro nastavení sítě v ramdisku používá tzv. mikro klient udhcp. Ovšem v našem případě získanou adresu nebyl schopen nastavit, proto je lepší použít "plnotučného" DHCP klienta.
ping	`iputils-ping`	Nástroj ping vám umožní rychle zjistit zda-li stroj na druhé straně sítě žije. V nouzi místo něj můžete použít telnet, když po otevření portu na druhé straně odklepnete GET
arping	`iputils-arping`	-
tracepath	`iputils-tracepath`	-
termshark	`termshark`	Je GUI rozhraní pro tshark, což terminálová verze utility wireshark, která vám umožní zachytávat síťové pakety na vaší wi-fi. Je to jediné místo, kde můžete zjistit co běhá vzduchem mezi AP a vaším klientem, protože komunikace mezi nimi je jinak šifrovaná.
nc	`iputils-ping`	-
tcpdump	`tcpdump`
netstat	`net-tools`	Umožňuje zjistit jaké jsou aktuálně otevřené porty.

Busybox, který běží v ramdisku by default podporuje řadu příkazů, pro které v "plnotučném" systému může existovat samostatná utilita. Pokud ji do ramdisku přes tento skript nakopírujete, tak se použije přednostně.

Obsah souboru /etc/initramfs-tools/wpa_supplicant.conf

network={
        ssid="jmenowifi"
        #psk="heslowifi"
        psk=989c6426c04864f7f386d12ca3bb776131d5eece0860c6c84f1ce2e1d3bac5ec
}

K vygenerování obsahu tohoto souboru můžete použít utilitu wpa_passphrase, která je součástí instalačního balíku wpasupplicant. Řetězec 'psk' se vygeneruje kombinací 'ssid' a plain hesla 'psk'.

Sledování provozu na Wi-Fi síti

Jak se jmenuje wifi zařízení a případně jakou má adresu lze zjistit přes ip

~# ip addr show

Síla signálu

Jaký je stav signálu na Wi-Fi zjistíme ze souboru /proc/net/wireless. Následující příkaz vypisuje jeho obsah ve vteřinovém intervalu

~$ watch -n 1 cat /proc/net/wireless

Pokud nás z toho zajímá pouze síla signálu, můžeme použít tohle:

~$ watch -n 1 "awk 'NR==3 {print \"WiFi Signal Strength= \" \$3 \"00 %\"}' /proc/net/wireless"

Probíhá vůbec síťová komunikace?

Pro rychlé zjištění jestli na zařízení wlp1s0 nějaká komunikace vůbec probíhá, stačí tcpdump. Pokud nás zajímá jen konkrétní adresa, kupř. to co vrací DHCP server, můžeme si vyfiltrovat pouze pakety s jeho adresou:

~# tcpdump -i wlp1s0 -s 0 host 192.168.210.5

adresa - IPv4 resp. IPv6 adresa

maska - maska

rozsah -

dst net adresa
src net adresa
net adresa
net adresa mask maska
net adresa/rozsah

https://serverfault.com/questions/354102/tcpdump-filter-on-network-and-subnet-mask filtrování výstupu z tcpdump

termshark

Pro sofistikovanější monitoring, kdy potřebujeme nahlédnout do paketů lze použít termshark. Klientská stanice je totiž jediným místem, na kterém se dá sledovat síťová komunikace, která probíhá přes Wi-Fi. Mezi NUCem přes AP až po kontroler, který ho spravuje ji nelze sledovat, protože je šifrovaná.

Pokud jsme na klientskou stanici připojeni přes SSH, tak je vhodné odfiltrovat vlastní komunikaci. To můžeme udělat kupř. tak, že odfiltrujeme svoji MAC sdresu:

~# termshark -i wlp1s0 -f "not ether host 9a:5d:9c:ee:11:a0"

Ale pokud nás SSH provoz nezajímá můžeme odfiltrovat rovnou veškerou komunikaci která probíhá přes port 22:

~# termshark -i wlp1s0 -f "not port 22"

Filtry se dají také řetězit:

… -f "not ip.addr == xxx.x.xx.xxx and not ip.src == xxx.x.xx.xx and not mac == xx-xx-xx-xx-xx-xx and not mac == xx-xx-xx-xx-xx-xx and not ip == xxx.x.x.x and not ip.dst == xxx.x.xx.xxx and not ip.src == xxx.x.xx.xxx"

Overlay nad NFS

Standardní sendwich:

NFS → TMPFS → FS

NFS → FS → TMPFS → FS

Adresáře sdílené přes NFS jsou namountované na adresáře, které jsou přes mcachefs namountované na přípojné body ze kterých se pak skládá sendvič pro overlay, který změny z disklessového systému ukládá na tmpfs, který se po restartu zahodí – tak jako u standardního disklessu

Rozdíl je v tom, že mcachefs při načítání souborů z NFS do RAM paralelně ukládá jejich kopie do kešovacích adresářů na lokálním disku. Jejich obsah se ale (na rozdíl od změn uložených z prostředí disklessu) při restartu nezahodí, takže při opětovném sestavení sendviče nemusí znovu tahat z NFS – catfs pouze zkontroluje zda-li jsou rozšířené atributy souboru stejné.

Na mcachefs jsem se dohmátl přes catfs. Obojí používá FUSE. Rozdíl jsou v tom, že:

mcachefs napsané v C má velikost ~0,5 MB kdežto catfs které je naprogramované v rustu má 2,9 MB
mcachefs, na rozdíl od catfs, pracuje se žurnálem a symlinky interpretuje jako symlinky – na rozdíl od catfs, který je zobrazuje v závislosti a tom nač odkazují.
mcachefs může mít podklad připojený jako readonly – změny se vždy zapisují do cache. U catfs se readonly podklad propaguje jako readonly i do horní vrstvy

Použití mcachefs

# mount … /tmp/backend
# mount -t btrfs -o subvol=cache LABEL=local /tmp/cache
# mcachefs /tmp/backend /target -o cache=/tmp/cache/root,journal=/tmp/cache/journal
…
# systemd-nspawn -D /target
…
## odpojit /target, znovu připojit a pak už to projde
# systemd-nspawn -b -D /target

Spuštění systému z keše

Úpravy v instalaci disklessu

Pro aktualizaci podkladového systému je třeba namountovat základní system na adresář /mnt/background jako rw (pokud je to na onom stroji možné)

Poté se spustí kontejner, ve kterém je možné upravit instalaci:

systemd-nspawn -b -D /mnt/background

Tím se pochopitelně může dostat do nesouladu lokální cache s podkladem. Opravu lze provést tak, že se porušené soubory z keše odstraní

Lokální keš je třeba namountovat na adresář /mnt/cache jako rw a následně zkontrolovat jestli je cksum všech souborů identický s jejic verzemi které nabízí podkladová vrstva z NFS serveru (ta může být namountovaná ro).

Pokud kontrolní součet nesedí, je dobré udělat nejprve truncate na nulovou velikost a potom soubor smazat

https://cromwell-intl.com/open-source/performance-tuning/disks.html Tuning I/O

Několik otázek

Co dělat když NUC UEFI nevidí bootovací disk?

Je nutné reinstalovat grub z prostředí nainstalovaného Ubuntu. Při tom musí být namountovaý EFI oddíl na adresář /boot/efi

Co se stane když přestane komunikovat NFS server?

Pokud pojede systém jako full-diskless (bez lokální keše), budou fungovat aplikace, které již budou mít všechny potřebné soubory načtené do paměti, ale nepůjde spustit nic nového. Pokud NFS server znovu naběhne a začne komunikovat, tak se spojení přes NFS samo obnoví.

Je možné vrstvu, která byla připojená přes NFS do overlaye odpojit a znovu připojit?

Ne. Každou vrstvu ze sendviče lze odpojit, ale znovu se do něj připojit nedá. Sendvič s overlayem se znovu sestaví až po restartu.

Aktualizace

Kvůli špatnému návrhu mcachefs vyžaduje aktualizace následující postup:

1, Před zapnutím turtlebota je třeba do NUC kostky zapíchnout LAN s PXE a USB klávesnici (pokud není k dispozici displej, tak i monitor)

2, po zapnutí je třeba přejít do biosu přes F2, vypnout boost a uložit

3, po natažení menu přes PXE zvolit Debian Turtle - systém najede jako klasický diskless bez toho že by používal cache.

4, V najetém systému se přihlásit jako root, připojit diskový oddíl, který funguje jako cache a ze systémového adresáře pomocí příkazu find odstranit všechny symlinky. Pozor! nespustit na kořen, protože by tím pádem přestal turtlebot funglovat ve wireless módu

5, Odmountovat, restartovat přes reboot a najet plnotučný systém - počkat až se vyžvejká a najede do grafického přihlášení!

6, Opet namountova kešovací oddíl na adresář /mnt a nejprve vylistovat soubor ... a .. a pak místo ls přes cat zapsat aktuální ramdisk do záložního souboru ... v případě aktualizace jádra udělat totéž i pro vmlinuz

7, odmountovat /mnt, spustit reboot a ještě před tím, než se spustí PXE vyškubnout LAN. Systém by měl najet wireless. Opět počkat, dokud vše nenajede do grafiky.

8, Pak stroj vypnout přes poweroff a odpojit klávesnici (případně i displej)

Co se stane když spadne proces mcachefs?

Pokud upadne proces mcachefs který obsluhoval přípojný bod, který je zapíchnutý jako vrstva do sendviče překrytého overlayem, stroj nezhavaruje. Bude to stejné jako když upadne NFS server. Pokud se pokusíte číst adresář, do kterého se z této vrstvy propagovaly nějaké soubory, skončíte následující chybovou zprávou:

root@turtle08:~# ls /usr/local
ls: cannot access '/usr/local': Transport endpoint is not connected

Odpadlou keš není možné znovu nahodit. I když by teoreticky mělo být možné odpadlý proces znovu nahodit a připojit znovu, ale to by nejspíš selhalo, protože overlay pracuje stále s původním sendvičem, který je na nižší vrstvě. Teoreticky by ale mělo být možné provést remount.

Vypínání a restart

U disklessu, který jede přes Wi-Fi je problém s restartem a vypínáním.

Podstata problému je v tom, že systemd před odpojením systémového disku odstřelí mezi jinými i procesy, které zajišťují síťové připojení, resp. přístup na lokální keš. Výsledkem je, že nedojde k restartu či vypnutí protože systemd zůstane "viset" – proto musíme použít vynucený restart.

Pokud není stroj zcela tuhý, lze vynutit korektní restart přes tzv. sysrq klávesy.

Pokud se na stroj nedá přihlást přes SSH a lokální konzole je mrtvá, je nutné použít spínač na NUCu a stroj natvrdo vypnout, a pak spustit znovu.

Aby fungovalo vypínání přímo ze systému, je třeba nahradit symbolický link /usr/sbin/poweroff symbolickým linkem na shellovým souborem s následujícím obsahem

~# for i in r e u s b ; do sleep 3 && echo $i > /proc/sysrq-trigger ; done

Pro reboot se udělá totéž, jenom místo posledního písmene o (vypnout) je nutné umístitb (restartovat). A na výsledný soubor bude odkazovat symlink /usr/sbin/reboot

Původní symlink doporučuji nemazat, ale přejmenovat, např. na poweroff.orig. Bude se to hodit v případě, když si systémový adresář spustíte přes systemd-nspawn v kontejneru – v takovém případě totiž nemůžete do souboru /proc/sysrq-trigger zapisovat a tím pádem vypínání selže. Použijete-li přejmenovaný symlink, proběhne vypnutí kontejneru tak jak má.

Použití

Konfigurace sítě

S TurtleBoty se na Katedře kybernetiky (dále jen DC) komunikuje v rámci VLAN-210. Více ke konfiguraci DHCP a přidělování IPv4 adres naleznete tam. Rychlý sken sítě lze provést pomocí utility nmap:

~# nmap -sn 192.168.210.0/24

Specifikem této VLAN je, že TurtleBoty dostávají přes Wi-Fi stejné IPv4 adresy, jako přes kabelové připojení, aby na ně mohli uživatelé přistupovat pokaždé přes stejnou IPv4 adresu – bez ohledu na to, jestli jsou připojeny přes Wi-Fi, nebo kabelem. Proto se při nahození Wi-Fi v ramdisku kontroluje, zda-li již zařízení nemá jinou konektivitu, aby se tak zabránilo vytvoření smyčky.

Přístup na spodní vrstvy sendviče

Zcela náhodu jsem přišel na to, že procesy spuštěné v ramdisku, jako např. wpa_supplicant nebo mcachefs představují díru, kterou se lze se dostat na vrstvy namountované v ramdisku, překryté za normální situace systémem namountovaným z overlaye. Proto by za všech okolností měly být adresáře sdílené přes NFS exportované:

Jen pro striktně vymezené rozsahy a pouze read-only.
Přístup read-write by měly mít pouze exporty pro vybrané stroje, u kterých je zajištěno, že nedojde k jejich zneužití.

Pokud běží v ramdisku proces, který je vidět ze spuštěného systému, lze se dostat ke připojeným mountpointům přes jeho proces. Pokud jako lokální uživatel 'root' spustíte následující příkaz:

~# ls /proc/*/root/

Vylistuje se vám aktuální kořenový adresář příslušného procesu. Pro většinu z nich je to stávající kořenový adresář, ale u těch co běží v ramdisku, je to kořen ramdisku a v něm je adresář i s připojenými mountpointy, co nebyly přesunuty z ramdisku do systému.

A můžete zjistit i další zajímavé informace, jako kupř. to, odkud jsou tyto adresáře namountované. Stačí k tomu:

~# cat /proc/<číslo procesu>/mounts

Uvedený "problém" se netýká strojů, které běží jako full-diskless přes pevnou linku, protože tam v ramdisku žádný takový proces neběží.
A navíc k tomu potřebuje uživatel nejprve získat práva uživatele root, což ovšem ale u disklessové distribuce, která má povoleno sudo, není problém.

tmux přes ssh připojení

U tmuxu přes SSH mohou nastat problémy spojené s přemapováním kláves. Se základní klávesovou zkratkou (Ctrl+b) nebývá problém, ale znaky pro vytvoření nového okna (uvozovka " a procento % se mouhou psát jinak, než na lokální klávesnici, jakou aktuálně používáte.

Psaní uvozovky: Na české linuxové QWERTY klávesnici se uvozovka píše přes klávesu Shift + ů (na anglické klávesnici je na klávese středník a dvojtečka).; Na US klávesnici je uvozovka o klávesu vedle

Psaní procenta: Na české linuxové QWERTY klávesnici se procento napíše přes klávesu Shift a klávesu, která je hned vedle nuly na horní řadě kláves – bez shiftu píše znak =; Alternativně se dá napsat přes pravý ALT + klávesu s číslem 5; Na US klávesnici by se napsal znak procenta Shift + klávesa s číslem 5

Pokud lezete přes SSH na stroj, kde nejsou nainstalované stejné fonty a lokály a kde není podpora fontu na textové konzoli, posílá se stejný znak jaký píšete na své klávesnici. Pokud ho ten vzdálený systém nezná, nenapíše nic!

Od roku 2018 se na řešení problémů TurtleBotů aktivně podíleli

S Alešem Kapicou, autorem a vývojářem technologie autonomního Half-Disklessu, v průběhu času spolupracovali následující vyučující a kolegové:

Karel Košnar
Gaël Écorchard (optimální postupy pro singularity)
Libor Wágner (příprava ROS image)
Tomáš Petříček (příprava ROS image)
Pavel Krsek
Vojtěch Šalanský
Bedřich Himmel (technická spolupráce)
Martin Pecka (příprava ROS image)
Ondřej Votava (pomoc s konfigurací firewallu a DDNS)

Jejich pomoc, byla jak technického rázu, tak formou hlášení problémů, připomínek a návrhů řešení.

↑ Původní TurtleBoty byly dodávány jako stavebnicové kity, na kterých byl umístěn notebook ASUS. U TurtleBotů verze 2 byl místo nich Intel NUC, původně s procesorem i5, 8GB RAM a 128GB SSD SATA diskem. Novější verze TurtleBotů 3 a 4 se již dodávají s lacinějším, ovšem také výkonostně slabším Raspberry Pi. Šablona:at
↑ První virtuální stroj založený na konceptu squashovaných vrstev se podařilo rozběhnout do konce roku 2023
↑ Trvalo téměř týden, než jsme na to díky Marku Beliškovi přišli.

[1] Původní TurtleBoty byly dodávány jako stavebnicové kity, na kterých byl umístěn notebook ASUS. U TurtleBotů verze 2 byl místo nich Intel NUC, původně s procesorem i5, 8GB RAM a 128GB SSD SATA diskem. Novější verze TurtleBotů 3 a 4 se již dodávají s lacinějším, ovšem také výkonostně slabším Raspberry Pi. Šablona:at

[2] První virtuální stroj založený na konceptu squashovaných vrstev se podařilo rozběhnout do konce roku 2023

[3] Trvalo téměř týden, než jsme na to díky Marku Beliškovi přišli.

[1]

[2]

[3]

TurtleBot

Co je TurtleBot?

Konverze Non-Diskless systému TurtleBota na Half-Diskless

Omezující faktory u TurtleBotů

Co bylo v našich silách

Vynucená pauza od března 2020 do října 2021

Kritická slabina Full-Diskless řešení přes Wi-Fi

Studentské notebooky připojené na laboratorní Wi-Fi

Autonomní Half-Diskless

Hardware

Instalace

Editace grub.cfg

Automatizace procesu distribuce na ostatní TurtleBoty

Export NFS adresáře

Úprava instalace disklessu

Přejmenování

Vytvoření ramdisku s podporou Wi-Fi

busybox

Sledování provozu na Wi-Fi síti

Síla signálu

Probíhá vůbec síťová komunikace?

termshark

Overlay nad NFS

Použití mcachefs

Úpravy v instalaci disklessu

Několik otázek

Co dělat když NUC UEFI nevidí bootovací disk?

Co se stane když přestane komunikovat NFS server?

Je možné vrstvu, která byla připojená přes NFS do overlaye odpojit a znovu připojit?

Aktualizace

Co se stane když spadne proces mcachefs?

Vypínání a restart

Použití

Konfigurace sítě

Přístup na spodní vrstvy sendviče

tmux přes ssh připojení

Od roku 2018 se na řešení problémů TurtleBotů aktivně podíleli

Navigační menu

Hledat