TurtleBot

Autorem obsahu této stránky, který je stále průběžně aktualizován, je Aleš Kapica, administrátor laboratorní disklessové infrastruktury na DCE a DC.
Veškerá fakta ohledně vývoje, uvedená v textu, jsou podložena dokumentací v rámci této wiki, jeho e-mailovou korespondencí a veřejně dohledatelnými internetovými zdroji, na které odkazuje v textu.

Výrobcem těchto zařízení, je Open Source Robotics Foundation, Inc.. První kusy které se ocitly na Karlově náměstí v roce 2018, byly zakoupeny jako stavebnice a poprvé použity při výuce 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 a z počátku se na nich používala předinstalovaná linuxová distribuce Ubuntu, pro kterou se softwarový balík utilit pro práci se senzory, distribuovaný pod názvem ROS vyvíjí. Šlo tedy o Non-Diskless instalaci, se všemi neduhy a problémy spojenými s administrací instalovaného systému, proto jsem byl již v říjnu 2018 osloven, je-li technicky možné, aby na TurtleBotech běžel stejný operační systém, jako na ostatních laboratorních strojích, tedy 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. Ten sice má ethernetový port, přes který by mohl Intel NIC komunikovat po síti, ale TurtleBot je v prvé řadě autonomní zařízení, které se využívá coby nosič nejrůznějších senzorů s nimiž se studenti učí pracovat, a na základě zpracovaných nasnímaných dat řídí jeho pohyb v prostoru.

Pokud by se měl TurtleBot pohybovat prostorem napojený do sítě ethernetovým kabelem, 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. Proto komunikují TurtleBoty 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 nepodporuje. Takže mým úkolem bylo najít co nejlepší řešení.

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

TurtleBot se neliší liší od normálního laboratorního PC jen tím, že komunikuje jen přes Wi-FI, ale také tím, že nemá připojenou myš s klávesnicí. Intel NUC má k dispozici jen omezený počet USB portů a ty jsou – až na jeden – obsazeny připojenými senzory. A na ten jeden port, co je k dispozici je připojen dotykový diplej, takže ten, kdo pracuje s TurtleBotem má dvě možnosti jak s ním pracovat:

1. Vzdáleně přes SSH
2. Nebo přes připojený dotykový displej – jenže ten nemusí vždy fungovat, proto by měl každý student vědět, jak s TurtleBotem pracovat přes SSH (viz níže)

Zde je potřeba zmínit, že naše TurtleBoty, přestože jsou všechny z řady verze 2, nejsou hardwarově identické jelikož první várku stavebnic z roku 2018 následovala další, která dorazila počátkem roku 2019. Stroje, které měly mít Intel NUC s výkonnějším procesorem, větším množstvím RAM a rychlejším NVME diskem měly rozšířit naší „flotilu” TurtleBotů, jenže dodávka nedošla kompletní – chyběly mechanické díly, nezbytné k instalaci platformy pro senzory. A tak Petr Novák, který měl za úkol stroje sestavit, nic dalšího nerozbaloval a sháněl chybějící díly.

To se vleklo až do září 2019 a tak až těsně před začátkem semestru – při finální kompletaci – zjistil, že je poškozená i většina dodaných dotykových displejů, takže sestavené stroje stále nebylo možné použít. Pokračovalo se tedy ve výuce na strojích z první várky a Petr Novák měl za úkol do dalšího semestru (který měl začít od poloviny února 2020) displeje vyreklamovat. Jenže z toho nebylo z toho nic, protože koncem roku Petr Novák odešel na CIIRC aniž by tu záležitost dořešil.

A tak až jeho nástupce, Bedřich Himmel, vyřešil tuhle situaci po vzájemné dohodě všech zainteresovaných, tím že použil displeje ze starších, výkonostně slabších TurtleBotů (číslo 3 až 7), které byly odstaveny. Vše co se dalo použít, se použilo, takže byste neměli být překvapeni, až u některého TurtleBota zjistíte, že nereaguje na dotyk (TurtleXX), nebo že během zavádění nevypisuje na displeji žádný výpis (Turtle13).

Podpora zavádění přes PXE

Řešení veškerých problémů Non-Diskless systému na stroji, co nemá k dispozici klávesnici, a je bez funkčního síťového připojení, je komplikované. Proto bylo nutné v prvé řadě každého TurtleBota přenastavit tak, aby přednostně zaváděl disklessový operační systém přes PXE a teprve pak zavaděč, jehož menu se zobrazuje na dotykovém displeji. Ke každému stroji tedy bylo nutné připojit dočasně klávesnici a přenastavit UEFI.

1. Každý Intel NUC 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.
2. 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!

Diskless přes Wi-Fi

A pak přišel na řadu další krok, který měl zajistit, aby bylo možné TurtleBota nastartovat jako Diskless i bez připojené klávesnice a ethernetové konektivity.

Výhodné v tuto chvíli bylo, že v rámci disklessové infrastruktry DC již od roku 2016 jelo několik virtuálních strojů v režimu Half-Diskless, takže bylo nutné dořešit pouze to, jak zajistit, nahození Wi-Fi sítě v prostředí ramdisku. 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. Takže se o nahození sítě místo PXE postará samo jádro po úspěšném nahození Wi-Fi a systém dál pokračuje v zavádění systému expertovaného přes NFS server. A zavedený systém, podobně jako Full-Diskless už dál s lokálním blokovým zařízením pracovat nemusí.

V takovém stavu byly TurtleBoty během zimního semestru roku 2018. První testy zcela jasně ukázaly, že propustnost připojení přes Wi-Fi nestačí a je potřeba najít technologické řešení, které srazí potřebu síťové komunikace ze strany operačního systému spuštěného TurtleBota na minimum.

Bylo nutné vyčkat na období mezi semestry, kdy neprobíhá výuka. Během výuky totiž nelze měnit systém pod rukama. V minulosti bylo tohle období zárukou, že se dá v laboratořích nerušeně pracovat na údržbě laboratorního systému, aniž by tam někdo přišel něco dělat. Byl to čas vyhrazený na údržbu, který je už dnes (2024) minulostí, protože se v rámci tohoto období propůjčují katederní laboratoře pro jiné akce, co bezprostředně nesouvisejí s výukou, ale zvyšují renomé katedry.

Omezující faktory u TurtleBotů

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

U 2,7GHz Wi-Fi je teoretická maximální propustnost kolem 56Mbit/s, tedy ještě horší než u 100 Mb sítě. Data se tahají rychlostí cca 2MB/s, o kteráou se ale 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 tahají přes tu samou Wi-Fi, jsou-li přihlášeni svým uživatelským jménem, může úroveň použitelnosti TurtleBotů velice rychle spadnout na nulu. Studenti s musí být vědomi faktu, že TurtleBoty žádnou jinou alternativu pro síťové připojení nemají, proto by se měli pokud možno vyvarovat chyb, které k takovému stavu vedou.

Nejhorší jsou zdánlivě banální operace, jako např. automatické doplňování příkazů na příkazové řádce, kdy se zdánlivě žádná data nepřenáší. Je to dáno tím, že mezi NFS serverem a klientem probíhá komunikace kterou tvoří mraky malých paketů. Ty sice neobsahují žádná data, ale mají svou režii. A jak se říká: „Tisíckrát nic by umlátilo slona.” Operace, která u stroje připojeného etherenetovým kabelem proběhne prakticky ihned, dokáže konektivitu TurtleBota dokonale zasekat i na několik desítek sekund. Záleží jen na tom, kolik zbytečného „smetí” má uživatel ve svém profilu, sdíleném přes NFS. I tak bylo nutné najít řešení, jak minimalizovat objem dat přenášených po síti během práce s TurtleBotem.

Řešení, která pomohla situaci vylepšit...

1. V prvé řadě to bylo přemění Wi-Fi AP na protilehlou stěnu, kde byla zásuvka připojená ke switchi kratším drátem, což zlepšilo propustnost ethernetového připojené Wi-Fi AP.
2. A TurtleBoty byly přepracovány na kešovaný Half-Diskless, který si na lokálním blokovém zařízení průběžně ukládal použité soubory pro budoucí opakované použití.

Řešení na bázi mcachefs

Bylo první, elegantní, ale mělo dost podstatnou vadu. Bylo závislé na aplikaci mcachefs. Ta sice dělala přesně to, co jsme po ní chtěli – ukládala do lokální keše vše, nač uživatel sáhnul – ale má zásadní nedostatky, které se projevily časem:

1. To, že mcachefs jel přes FUSE, bylo to nejmenší. Pomalejší natahování souborů se dá přežít. Bohatě se to vyvážilo při opakované spouštění stejných aplikací po restartu.
2. Mnohem vážnější bylo to, že mcachefs nepodporoval automické změny. Aby se promítla změna na straně NFS serveru, bylo nutné udělat nový restart.
3. Velice vážným problémem bylo to, že neuměl aktualizovat nakešované symlinky, protože systemd, na který jsme přešli od verze Bookworm, je na symlincích založen.

Nicméně během zimního semestru roku 2019 se zdálo, že jde o uspokojivé řešení a v únoru 2020, během přípravy na další semestr nikdo netušil, že o pouhý měsíc později bude prezenční výuka na rok a půl přerušena.

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

Krátce na to, v březnu 2020, vypukla koronavirová panika. Využil jsem nucené přestávky k tomu, abych přizpůsobil disklessový systém pro vzdálený přístup. Ale na TurtleBoty padal více než rok a půl prach, přestože byly připraveny k provozu. Jenže to by vyžadovalo pracovní sílu, trvale 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 sledovaného on-line kamerou, přes kterou by mohli vzdáleně pracující studenti sledovat co TurtleBot dělá.

Při aktualizaci kešovaných souborů na TurtleBotech se v plné nahotě projevily nedostatky mcachefs. Měl jsem představu, jak to udělat jinak a lépe. Jenže jsme naskořili do prezenční výuky tak rychle, že na to nebyl žádný čas a jednodušší bylo kešování opět vypnout, takže se TurtleBoty opět provozovaly jako Full-Diskless přes Wi-Fi – se všemi již zmíněnými nedostatky.

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

Dříve také nebylo běžné, že by si studenti nosili sebou do výuky vlastní notebooky, s nimiž by se připojovali na laboratorní Wi-Fi, určenou pro TurtleBoty.

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.

A implementace zabrala období od prosince 2023 až do poloviny února 2024, protože bylo nutné vytvořit nástroje pro přípravu squshovaných vrstev a implementovat podporu kryptování do dynamického ramdisku.

Hardware

V současné době provozujeme tyto TurtleBoty:

	CPU (počet jader a typ)	RAM (v GB)	swap (v GB)	Disk (kapacita + typ)	Astra	RealSense	Převodník USB na UART CP2102	Dotyková vrstva	Převodník USB na UART TTL	Typ	Poznámka
turtle01	4 Intel(R) Core(TM) i5-6260U CPU @ 1.80GHz	7,65	0	120 GB Intel 540 Series SSDs INTEL SSDSCKKW120H6 CVLY617600BH120H LSBG100	Y	N	N	Y	Y	NUC6i5SYB Intel(R) Client Systems verze ?	Někdy se Wi-Fi nechytne na poprvé
turtle02	4 Intel(R) Core(TM) i5-6260U CPU @ 1.80GHz	7,65	7,81	120 GB Intel 540 Series SSDs INTEL SSDSCKKW120H6 CVLY61760044120H LSBG100	Y	N	Y	Y	Y	NUC6i5SYB Intel(R) Client Systems verze ?	Někdy se Wi-Fi nechytne na poprvé
turtle08	8 Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz	7,63	7,88	240 GB KINGSTON SA1000M8240G 50026B7682756FAC E8FK11.R	N	Y	Y	Y	Y	NUC7i7DNKE Intel(R) Client Systems verze J85069-205
turtle09	8 Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz	7,63	7,88	240 GB KINGSTON SA1000M8240G 50026B7682884D07 E8FK11.R	N	Y	Y	Y	Y	NUC7i7DNKE Intel(R) Client Systems verze J85069-205
turtle10	8 Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz	7,63	7,88	240 GB KINGSTON SA1000M8240G 50026B7682756D7D E8FK11.R	N	Y	Y	Y	Y	NUC7i7DNKE Intel(R) Client Systems verze J85069-205
turtle11	8 Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz	7,66	7,88	240 GB KINGSTON SA1000M8240G 50026B76827572DB E8FK11.R	N	Y	Y	Y	Y	NUC7i7DNKE Intel(R) Client Systems verze J85069-205
turtle12	8 Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz	7,63	7,88	240 GB KINGSTON SA1000M8240G 50026B7682756D38 E8FK11.R	N	Y	Y	Y	Y	NUC7i7DNKE Intel(R) Client Systems verze J85069-205	Někdy se Wi-Fi nechytne na poprvé a při zavolání systemctl poweroff stroj nevypne a udělá reboot.
turtle13	2 Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz	7,63	7,88	240 GB KINGSTON SA1000M8240G 50026B7682756D8D E8FK11.R	N	Y	Y	Y	Y	NUC7i7DNKE Intel(R) Client Systems verze J85069-205	Displej má pravděpodobně HW problém, protože nefunguje dotyková vrstva a zavaděč se s ním při startu rovněž nedomluví, takže zavádí jádro v blind módu (není vidět žádný výstup).

Editace původního grub.cfg

Jelikož se pro zavádění jádra měl využívat zavaděč z předinstalovaného Ubuntu, byla nutná následující úprava souboru /mnt/grub/grub.cfg:

...

Úprava instalace disklessu

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

1. Nahození aplikace wpa_supplicant
2. Získání adresy přes aplikaci dhclient
3. 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. 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í	Kolik přidá na objemu ramdisku
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"

• https://www.cyberpunk.rs/termshark-terminal-ui-for-tshark termshark
• https://github.com/gcla/termshark/blob/master/docs/UserGuide.md termshark
• https://github.com/gcla/termshark/blob/master/docs/FAQ.md tshark

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

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í.