PROJET EN COURS mais FONCTIONNEL !
|
Primtux en utilisation avec des clients lourds n'est pas envisageable tel quel. En effet, il y a un problème avec les comptes utilisateurs. J'ai donc choisi de me baser sur l'interface de l'administrateur car qui peut le plus, peut le moins. Par contre, les utilisateur⋅rice⋅s se connecteront avec leur propres identifiants et disposeront de leur propre dossier /home. Bref, on reprend le principe des clients Éclair. |
ATTENTION : Depuis 2019, LTSP a été ré-écrit afin de prendre en compte les évolutions comme Systemd, Wayland et autres. C'est la version que l'on trouve à partir d'Ubuntu 20.04. De fait, l'ancienne version est dénommée LTSP 5 et on la trouve dans Ubuntu 16.04 et 18.04. Du coup, pour des question de pérennité, il faut faire évoluer la version LTSP5 vers la nouvelle qui au moment de la rédaction de cette page est la LTSP 20. Plus d'info, sur cette page : https://ltsp.org/docs/ppa/
AVERTISSEMENT : La nouvelle version de LTSP ne supporte plus les clients légers dans le sens où les applications ne fonctionnent plus de façon déportée sur le serveur. Ce fonctionnement qu'on trouve dans la version LTSP 5 n'est plus adapté et il est très contraignant en terme de développement ce qui engendre des problèmes non résolus faute de suivi (voir les infos en anglais ici : https://github.com/ltsp/ltsp/discussions/243#discussioncomment-101460). On parlera donc maintenant de clients lourds (ou riches ou fat clients en anglais) dans le sens où les applications fonctionnent localement et que le lien avec le serveur ne sert que pour l'échange de données.
AVERTISSEMENT 2 : Je me suis cassé les dents sur la configuration du réseau pour l'accès à Internet des clients lourds. Faut dire aussi, que j'étais initialement sur un réseau avec proxy, sans serveur DHCP... ce qui a compliqué grandement les choses. En passant sur un réseau simple, sans proxy, avec une box pour la liaison directe avec Internet, les problèmes se sont arrangés. ÉVITER UN RÉSEAU AVEC PROXY ET SANS SERVEUR DHCP !
Sources officielles :
- https://ltsp.org
- https://github.com/ltsp
- https://github.com/ltsp/ltsp/wiki
- Forum de discussion où on peut avoir des infos : https://github.com/ltsp/ltsp/discussions
- Fil de discussion ouvert sur le forum Primtux : https://forum.primtux.fr/viewtopic.php?id=2284
1- Avantages d'un serveur de clients Lourds basé sur le projet LTSP
Remarque : suite à l'évolution de LTSP (voir avertissement ci-dessus), je commencerai par faire mes expérimentations sur un serveur Ubuntu 20.04 et non sur l'AmonÉcoleÉclair. La version AmonEcole qui proposerait ce nouveau mode de fonctionnement serait la 2.8.1 actuellement en travaux avec LTSP intégré dans le Scribe (et donc disparition du module Éclair).
Dans notre école, nous utilisons un serveur AmonecoleEclair 2.6.2 (basé sur Ubuntu 16.04) qui combine à la fois des serveurs Scribe, Amon et Éclair. Ces solutions sont proposées par le pôle EOLE.
Le serveur Éclair (basé sur LTSP) permet de faire fonctionner des ordinateurs poussifs (qui auraient fini au mieux en déchetterie) en les soulageant en exécutant le plus gros du travail de traitement.
En dehors du fait de pouvoir réutiliser de vieilles machines, dès qu'on a une dizaine de postes en réseau, il s'agit là d'une solution "idéale". Elle est très économique et écologique (récupération de machines, les nôtres ont une dizaine d'années), facilite la maintenance (on n'agit que sur le serveur, aucune installation sur les postes, pas de disque dur,...). Malheureusement, elle ne bénéficie pas d'un éclairage/intérêt à la hauteur de tous ses avantages... Quel dommage et quel gâchis...
2- Intérêt du Raspberry Pi 4 comme client LOURD
Au lieu d'utiliser de vieux ordinateurs de récup, il est possible désormais d'envisager d'utiliser des nano-ordinateurs comme le RaspBerry Pi 4 (avec 4 Go de Ram). Hors écran, on peut s'équiper pour 100-110 € : RaspBerry Pi 4 modèle B avec 4 Go (60€ ) , boîtier (6 € ) , carte microSD 32Go de qualité (10 € ) , transformateur (9 € ) , clavier/souris USB (15 € ) , câble micro-Hdmi -> Hdmi (6 € ). Bref, on peut compter 200€ par poste complet, moniteur compris.
Edit du 23/11/2020 : avec la sortie du Raspberry Pi 400 qui est un clavier intégrant un Raspberry Pi 4, c'est une solution pour un usage en classe plutôt pertinente.
Attention, le boîtier officiel n'est pas pratique car il ne permet pas une fixation par vis au dos de l'écran. Il faudra envisager une fixation par colle thermofusible, le scotch double-face ne tenant pas dans la durée. La fixation devra se faire côté couvercle blanc afin d'avoir un accès facile à la carte micro-SD.
Avec la version 4 et les dernières mises à jour, contrairement à ses prédécesseurs, le Raspberry Pi peut désormais démarrer directement sur le réseau (boot PXE).
L'idée est donc d'essayer de mettre en place un serveur de clients légers ou plutôt de clients lourds (fat-clients) pour distribuer une image Primtux basée sur la version destinée aux Raspberry Pi.
3- Mettre à jour l'EEPROM de son Raspberry Pi 4
Source : https://www.raspberrypi.org/documentation/hardware/raspberrypi/booteeprom.md
Cela nécessite de mettre à jour le Raspi via Raspberry Pi OS qu'on aura sur une carte micro-SD et de taper ces 3 lignes de commandes :
sudo apt update sudo apt full-upgrade sudo reboot
Pour vérifier s'il y a une mise à jour de l'eeprom, taper :
sudo rpi-eeprom-update
Si c'est le cas pour mettre à jour, taper :
sudo rpi-eeprom-update -a sudo reboot
4- Configuration de l'EEPROM pour choisir l'ordre de démarrage
Source : https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711_bootloader_config.md
On tape la commande suivante pour éditer le fichier de configuration :
sudo -E rpi-eeprom-config --edit
Et on met sur la ligne BOOT_ORDER=0fx12 pour démarrer d'abord via le réseau puis sur la carte SD. Le démarrage se fait en premier sur le dernier chiffre (2 = réseau), puis 1 (1=carte micro SD).
Voici le contenu de ce fichier de configuration du démarrage :
[all]
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
TFTP_IP=
TFTP_PREFIX=0
BOOT_ORDER=0xf12
[none]
FREEZE_VERSION=0
5- Installation du serveur Ubuntu 20.04
Source : https://github.com/ltsp/ltsp/wiki/Installing-LTSP-on-Ubuntu-Server
Mon serveur a 2 cartes réseaux 1 gigabit (5 en vérité sur un serveur récupéré dans un collège, un Proliant ML350 G5 avec 2 Go de Ram au départ puis augmentée à 16 Go) : la 1ère carte servira à l'accès Internet et la 2nde servira pour les clients lourds. Cette 2e carte reliée aux clients légers, aura comme IP fixe, l'adresse 192.168.67.1 (on la retrouvera dans certains paramétrages par la suite).
Remarque : au début, pensant pouvoir gérer l'image chroot des clients lourds avec Virtualbox (solution abandonnée par la suite, cf ci-dessous), j'ai eu besoin d'activer dans le BIOS du serveur la virtualisation afin de pouvoir virtualiser des OS en 64 bits.
A) Paramétrages :
IMPORTANT : On se met en utilisateur root en tapant la commande de sorte à ne plus avoir à faire précéder les commandes de sudo :
sudo -i
Une fois l'installation faite, commandes à taper :
systemctl disable systemd-networkd-wait-online.service
systemctl mask systemd-networkd-wait-online.service
apt remove bcache-tools btrfs-progs cloud-guest-utils cloud-initramfs-copymods cloud-initramfs-dyn-netconf xfsprogs lxd-agent-loader open-iscsi open-vm-tools
Suppression de Snap (source : https://github.com/ltsp/ltsp/wiki/Client-Choices-and-Performance) en listant les paquets snap avec la commande :
snap list
Puis on procède aux suppressions en terminant par core18 puis snapd :
snap remove lxd
snap remove core18
snap remove snapd
apt purge snapd
reboot
sudo -i
apt-get autoremove
apt-mark hold snap snapd
B) Configuration du réseau :
Depuis Ubuntu 18.04, c'est Netplan qui permet de configurer le réseau.
Sources pour configurer adresses IP sur un serveur 20.04 :
Pour connaître les adresses des cartes réseau, taper la commande :
ip a
Pour connaître les caractéristiques des ses cartes réseaux, utiliser la commande :
ethtool nom_interface # le nom de l'interface est obtenu avec la commande précédente
Pour éditer le fichier de configuration et notamment fixer l'adresse IP de la 2e carte réseau à 192.168.67.1, taper la commande :
nano /etc/netplan/00-installer-config.yaml
Pour vérifier qu'il n'y a pas d'erreur de syntaxe, taper :
netplan try
Pour enregistrer définitivement, taper :
netplan apply
Il faudra éventuellement rebooter.
C) Mise à jour et installations supplémentaires :
Une fois l'installation faite, commandes à taper :
apt install nvidia-driver-440 #(pas forcément utile dans mon cas)
apt install xubuntu-desktop
apt purge --yes --auto-remove indicator-application
apt install --yes synaptic
Installation de LTSP (source : https://ltsp.org/docs/installation/)
add-apt-repository ppa:ltsp
apt update
apt install --install-recommends ltsp ltsp-binaries dnsmasq nfs-kernel-server openssh-server squashfs-tools ethtool net-tools epoptes
gpasswd -a login_admin epoptes #(login_admin est l'identifiant de l'administateur du serveur)
Après avoir fixé l'adresse de la 2e carte réseau à 192.168.67.1 avec Netplan (voir plus haut), on tape :
ltsp dnsmasq --proxy-dhcp=0
6- Construction de l'image Primtux à mettre sur le serveur
Sources :
A- Choix du type d'image : chrootless, images VM ou chroot
Source : https://ltsp.org/man/ltsp-image/
- Comme les Raspberry Pi 4, à base d'ARM n'ont pas la même architecture que le serveur à base d'un processeur AMD64, une utilisation "chrootless" n'est pas possible même si ça semblait la plus simple à mettre en œuvre. C'est la solution la plus intéressante si on a un O.S. identique entre le serveur et les clients. Nous ne sommes pas dans ce cas.
- Du coup, j'ai vu qu'il était possible d'utiliser des images de machines virtuelles au format .vmdk comme images de boot. Ça me semblait la solution la plus intéressante car ça aurait permis de configurer l'image sur le serveur (comme pour la solution "chrootless") et de la proposer au démarrage. Vu qu'on va travailler sur des versions desktop, a priori Virtualbox aurait été la solution la plus pratique, KVM (que je ne connais pas) étant semble-t-il plus adapté à des images serveur. SOLUTION ABANDONNÉE CAR IL N'EST PAS POSSIBLE DE VIRTUALISER UN O.S. D'ARCHITECTURE DIFFÉRENTE DE CELLE DE L'HÔTE (ici ARM à partir d'AMD64).
- Il ne reste donc plus que la solution classique à base d'un chroot "normal". Par contre avec cette nouvelle version de LTSP la commande ltsp-built-client a disparu et cela demande donc de construire l'image avec debootstrap, ce qui semble plus délicat. Info pour savoir comment gérer les chroots ici : https://artisan.karma-lab.net/magie-chroot. Mais autant se baser sur une image fonctionnelle au départ sur un Raspberry Pi 4.
B- Construction de l'image chroot sur le serveur
Sources :
- https://ltsp.org/docs/installation/raspbian/
- Pour avoir des infos sur les périphériques loop, comment modifier des fichiers sur des images montées avec la commande losetup : http://casteyde.christian.free.fr/system/linux/guide/online/x5706.html
Avertissement : Lors de ma première tentative, l'image Primtux4 récupérée à partir du site officiel, n'a pas permis de démarrer correctement les clients lourds à la fin. J'ai donc reconstruit une image de "zéro" à partir du script de construction de Philippe Dpt35 en supprimant le contrôle parental CTparental, wicd et le logiciel "log2ram".
- Sur le Raspberry Pi 4 : Sur la nouvelle image obtenue de Primtux4 (sans le contrôle parental, Wicd et log2ram), il est nécessaire de faire des modifications pour activer le réseau.
On édite le fichier /etc/network/interfaces et on rajoute les 2 lignes suivantes pour obtenir l'adresse IP par Dhcp (à partir du serveur) :
allow-hotplug eth0 iface eth0 inet dhcp
On enlève la "protection en écriture" du fichier /etc/resolv.conf avec la commande :
chattr -i /etc/resolv.conf
Et on modifie /etc/resolv.conf afin de lui indiquer l'adresse du serveur DNS (qui est le serveur Ltsp) avec la ligne :
nameserver 192.168.67.1
- Sur le serveur Ltsp :
IMPORTANT : On se met en utilisateur root en tapant la commande de sorte à ne plus avoir à faire précéder les commandes de sudo :
sudo -i
- On récupère l'installation Primtux pour Raspberry Pi 4 (basée sur Raspbian) existante et optimisée sous forme d'image .img à l'aide de la commande dd (source : https://www.arsouyes.org/blog/2019/48_copie_DD/) où sdX correspond au périphérique ayant Primtux (en général la carte microSD) :
time dd if=/dev/sdX of=primtux4-rpi4.img conv=notrunc,noerror status=progress
- Ensuite on tape les commandes suivantes pour créer l'image chroot dans le dossier du serveur /srv/ltsp (attention, veillez à avoir assez de place sur le disque où vous montez l'image sinon vous aurez des erreurs à la commande mount) :
losetup -rP /dev/loop8 primtux4-rpi4.img # attendre un peu que les 2 volumes rootfs et boot se montent ou pas assez de place sur le disque dur ! mount -o ro /dev/loop8p2 /mnt time cp -a /mnt/. /srv/ltsp/primtux4-rpi4 umount /mnt mount -o ro /dev/loop8p1 /mnt cp -a /mnt/. /srv/ltsp/primtux4-rpi4/boot/ umount /mnt losetup -d /dev/loop8
VARIANTE si on utilise directement la carte micro-SD de primtux4-rpi4 montée sur son ordinateur à l'emplacement /media/thierry/boot et /media/thierry/rootfs (en tant que device /sdb par exemple) :
time cp -a /media/thierry/rootfs/. /srv/ltsp/primtux4-rpi4 time cp -a /media/thierry/boot/. /srv/ltsp/primtux4-rpi4/boot
- Il faut maintenant préparer l'image chroot avec ces commandes :
# On se place dans le dossier de l'image chroot cd /srv/ltsp/primtux4-rpi4 # On masque les services qu'on ne veut pas au démarrage réseau systemctl mask --root=. dhcpcd dphys-swapfile raspi-config resize2fs_once # On supprime les informations relatives à la carte SD de fstab echo 'proc /proc proc defaults 0 0' >./etc/fstab # On adapte le fichier cmdline pour NFS_RW netbooting echo 'ip=dhcp root=/dev/nfs rw nfsroot=192.168.67.1:/srv/ltsp/primtux4-rpi4,vers=3,tcp,nolock console=serial0,115200 console=tty1 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles modprobe.blacklist=bcm2835_v4l2' >./boot/cmdline.txt
- Le paramétrage du serveur et des clients lourds se fait dans le fichier /etc/ltsp/ltsp.conf (https://ltsp.org/man/ltsp.conf/).
Pour créer le fichier initial, taper :install -m 0660 -g sudo /usr/share/ltsp/common/ltsp/ltsp.conf /etc/ltsp/ltsp.conf
Remarque : il ne faut pas d'espace autour du signe "=" et on peut commenter avec le signe "#".
- On accède au fichier ltsp.conf avec la commande :
nano /etc/ltsp/ltsp.conf
- Dans le fichier ltsp.conf (https://ltsp.org/man/ltsp.conf/), on tape :
[server] NAT=1 RPI_IMAGE="primtux4-rpi4"
- Puis on lance les 3 commandes :
ltsp kernel primtux4-rpi4 ltsp initrd ltsp nfs
- À ce stade, il est désormais possible de démarrer un client lourd en mode NFS_RW (pas en mode graphique, voir constatation précédente) mais toutes les modifications que l'on fera sur un client connecté se répercuteront sur l'image /srv/ltsp/primtux4-rpi4. Ça peut être intéressant pour personnaliser l'image mais pas pratique en production. On va donc copier l'image de base en tapant :
echo '/srv/ltsp/primtux4-rpi4 *(rw,async,crossmnt,no_subtree_check,no_root_squash,insecure)' >/etc/exports.d/ltsp-primtux4-rpi4.exports
Remarque : pour des questions de sécurité, on peut remplacer l'étoile * par l'adresse IP d'un Raspberry Pi ou une fois les manipulations faites, supprimer le fichier /etc/exports.d/ltsp-primtux4-rpi4.exports.
Et on exporte cette copie avec la commande :exportfs -ra
- À ce stade, tout fonctionne (la connexion Internet, le son, Scratch 3, LibreOffice ...), voir la vidéo du démarrage réussi !
Sur le Raspberry Pi 4 : On démarre un client lourd Raspberry Pi 4 et on y installe dessus le dépôt PPA de LTSP (c'est exceptionnellement possible car ce dépôt ne contient que des scripts shell et python) en tapant :
sudo wget https://ltsp.org/misc/ltsp-ubuntu-ppa-focal.list -O /etc/apt/sources.list.d/ltsp-ubuntu-ppa-focal.list sudo wget https://ltsp.org/misc/ltsp_ubuntu_ppa.gpg -O /etc/apt/trusted.gpg.d/ltsp_ubuntu_ppa.gpg sudo apt update
- Toujours sur le client Raspberry Pi 4 on installe les paquets suivants :
apt install --install-recommends ltsp epoptes-client
- À ce stade sur le serveur, le chroot contient tout le code LTSP et est prêt pour le démarrage réseau. On peut faire les modifications nécessaires pour avoir notre image chroot "modèle".
Fil de discussion du problème ici : https://github.com/ltsp/ltsp/discussions/329
Sur le serveur Ltsp :
Mais il faut un fichier cmdline avec un kernel différent que le mode NFS_RW. On va donc maintenant modifier le mode NFS_RW dans le fichier cmdline.txt :
echo 'ip=dhcp root=/dev/nfs nfsroot=192.168.67.1:/srv/ltsp/primtux4-rpi4,vers=3,tcp,nolock init=/usr/share/ltsp/client/init/init ltsp.image=images/primtux4-rpi4.img console=serial0,115200 console=tty1 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles modprobe.blacklist=bcm2835_v4l2' >/srv/ltsp/primtux4-rpi4/boot/cmdline.txt
- Pour créer l'image squashfs (image de fichiers compressés en lecture seule), on termine avec la commande qui prend du temps (environ 18 minutes) :
ltsp image primtux4-rpi4 --mksquashfs-params='-comp lzo'
À ce stade, il est possible de démarrer tous les autres raspberry pi 4 en mode client lourd. On arrive bien sur la fenêtre de connexion de Primtux mais avec uniquement l'administrateur du serveur. Aucun des 3 niveaux, ni celui de l'administrateur. Voi la vidéo de démarrage ici : https://tube-montpellier.beta.education.fr/videos/watch/0a0b1d5c-3d25-41a6-aa75-09127412ae20.
J'ai pourtant créé un nouvel utilisateur "administrateur" mais ça n'a pas suffit... Un problème de squelette skel...
8- Créer un modèle à partir du /home/administrateur de Primtux
J'ai trouvé la solution grâce à cette discussion : https://github.com/ltsp/ltsp/discussions/345
En fait, avec un serveur Ltsp, les utilisateur⋅rice⋅s sont créé⋅e⋅s sur le serveur avec leur propre répertoire /home.
- Si l'on veut que les nouveaux⋅elles utilisateur⋅rice⋅s aient le même environnement de bureau, la même interface il faut mettre tout le contenu du dossier /home/administrateur dans le dossier /etc/skel. On tape donc la commande :
rsync -a /srv/ltsp/primtux4-rpi4/home/administrateur/ /etc/skel
- Ensuite on se place dans le répertoire /etc/skel avec la commande :
cd /etc/skel
- Ensuite on peut y faire le ménage en supprimant des dossiers cachés comme .mozilla, .kde, ... Cela nécessite quelques recherches.
Il faut aussi rechercher dans tous les fichiers, les chemins codés en dur avec la chaîne "/home/administrateur" avec la commande (sans oublier le "." à la fin) :
grep -r home/administrateur .
- Ensuite on remplace toutes les chaînes trouvées "/home/administrateur" par la variable $HOME.
- On ajoute un⋅e nouvel⋅le utilisateur⋅rice sur le serveur et pour qu'il⋅elle soit pris⋅e en compte par ltsp, on tape la commande :
ltsp initrd
9- Adaptation de la fenêtre de connexion
Le mode de fonctionnement du serveur LTSP, impose que les utilisateur⋅rice⋅s saisissent leur login et mot de passe pour se connecter. Il faut donc modifier l'écran de connexion habituel de Primtux reposant sur le choix d'icones et basé sur Lightdm.
Sources :
En construction ...
| CONCLUSION : On se rapproche du fonctionnement d'un serveur Éclair avec des utilisateur⋅rice⋅s ayant leur propre compte et en perdant la sélection de l'interface de Primtux mais cela fonctionne. |
10- Obtenir des info sur ses raspberry Pi
- Il est nécessaire de connaître le numéro de série de son Raspberry Pi 4 (les 8 derniers caractères) pour démarrer via le réseau. Pour obtenir les caractéristiques de son Raspberry Pi, taper la commande :
cat /proc/cpuinfo
- Pour connaitre l'adresse MAC, taper :
ip a
- Pour fixer une IP fixe, il faut éditer le fichier /etc/dhcpcd.conf (source : https://soltveit.org/raspbian-buster-static-ip-how-to-set-it/). Une fois la configuration faite, si l'on ne veut pas redémarrer, on tape les commandes suivantes :
systemctl daemon-reload systemctl restart dhcpcd
11- Commandes utiles sur le serveur ltsp
- Pour connaître les volumes montés sous forme d'arborescence :
lsklb
- Pour connaître la version LTSP utilisée :
ltsp info
-
Le paramétrage du serveur et des clients lourds se fait dans le fichier /etc/ltsp/ltsp.conf (https://ltsp.org/man/ltsp.conf/).
Pour créer le fichier initial, taper :install -m 0660 -g sudo /usr/share/ltsp/common/ltsp/ltsp.conf /etc/ltsp/ltsp.conf
Remarque : il ne faut pas d'espace autour du signe "=" et on peut commenter avec le signe "#".
- À chaque ajout de nouveaux⋅elles utilisateur⋅rice⋅s ou modification du fichier ltsp.conf, afin d'appliquer les changements, il faudra taper :
ltsp initrd
et redémarrer les clients lourds.
12- Pour aller plus loin
Pour voir comment se passe le boot du Raspberry Pi : https://www.raspberrypi.org/documentation/configuration/boot_folder.md
https://www.ferdinand-keil.com/network-booting-rpi4-from-centos7.html
https://hackaday.com/2019/11/11/network-booting-the-pi-4/
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ABANDONNÉ CAR IMPOSSIBLE À FAIRE SUR UN SERVEUR ET DES CLIENTS D'ARCHITECTURES DIFFÉRENTES (trace conservée pour ne pas perdre les recherches).
Utilisation d'une installation Primtux existante pour la convertir en image virtuelle .vmdk
Du coup, voici la démarche choisie :
- Installer VirtualBox sur le serveur avec la commande :
sudo apt install virtualbox virtualbox-ext-pack
- Récupérer l'installation Primtux pour Raspberry Pi 4 (basée sur Raspbian) existante et optimisée sous forme d'image iso à l'aide de la commande dd (source : https://www.arsouyes.org/blog/2019/48_copie_DD/) où sdX correspond au périphérique ayant Primtux (en général la carte microSD) :
time sudo dd if=/dev/sdX of=primtux4-rpi4.iso conv=notrunc,noerror status=progress
- Convertir l'image iso de Primtux en une image de machine virtuelle .vmdk (source : https://www.how2shout.com/how-to/how-to-convert-iso-to-vdmk-or-vdi-using-virtualbox.html) avec VBoxManage avec la commande :
VboxManage convertfromraw primtux4-rpi4.raw primtux4-rpi4.vmdk --format VMDK
- On se crée une nouvelle machine virtuelle dans Virtualbox à partir de l'image primtux4-rpi4.vmdk obtenue précédemment en choisissant le type .VMDK et une taille fixe (important). Source : https://www.arsouyes.org/blog/2020/24_Raw_to_VDI/
- On personnalise, adapte sa machine virtuelle si c'est encore nécessaire et on ferme Virtualbox.
- On se crée un lien symbolique de l'image primtux4-rpi4.vmdk dans le dossier des images Ltsp avec la commande :
ln -rs ~/dossier-images-Virtualbox/primtux4-rpi4.vmdk /srv/ltsp/primtux4-rpi4.img
- On met à disposition l'image vers les clients lourds (manip à refaire lorsqu'on fera une modification dans Virtualbox) avec la commande :
ltsp image primtux4-rpi4