AbulÉdu Client Lourd 19.08.1¶

Publiée durant l'été 2020 cette version apporte les améliorations suivantes:

correction d'un bug assez "aléatoire" concernant la résolution DNS des postes clients (le /etc/resolv.conf est incomplet parfois)
grosse amélioration du système de synchronisation des profils (publication d’un nouveau paquet deb « horizon-meta » et « horizon-lightdm-default-settings »)
correction d'un bug gnome lorsqu'il essaye de télécharger les mises à jours (référence du bug chez redhat: https://bugzilla.redhat.com/show_bug.cgi?id=1787512) → publication d'un nouveau paquet horizon-meta
LightDM : Modification des scripts d’ouverture / fermeture de session → publication d’un nouveau paquet deb « horizon-lightdm-default-settings » et voir toutes les modifications dans le dépot git(http://redmine.abuledu.org/projects/horizon-default-settings/repository?rev=version-19.08)
Lors du démarrage le message « mise à jour du poste » n’est pas toujours affiché. → bug corrigé dans la nouvelle maquette
Erreur de réinstallation de grub (Suite à la mise à jour sécurité récente de Grub2 (voir https://ubuntu.com/blog/mitigating-boothole-theres-
a-hole-in-the-boot-cve-2020-10713-and-related-vulnerabilities
et https://www.zdnet.fr/actualites/l-attaque-boothole-affecte-les-systemes-windows-et-linux-utilisant-grub2-et-secure-boot-39907469.htm pour un article en français) un bug inattendu a été rencontré : comme la maquette de déploiement a été générée via une VM Virtuelle la référence au disque dur était préconfigurée pour faire référence à ce disque ! ... Bug corrigé → https://redmine.abuledu.org/issues/5113)
Gel du bureau gnome avec messages d’erreurs javascript dans la console ... Bug corrigé → https://redmine.abuledu.org/issues/5112 *

Nouveaux paquets "officiels"¶

La maquette 19.08beta3 ayant été proposée en janvier 2020 la liste des paquets de mise à jour à appliquer est longue (346 paquets et 585Mo) ... une nouvelle maquette de déploiement est donc justifiée aussi par ces 346 paquets qui ne seront donc pas à mettre à jour après le déploiement !

Synchronisation des profils¶

Problème à résoudre¶

Rappel du problème :

les profils itinérants permettent de répondre au problème des délais de réponses de la couche réseau (les applications n’aiment pas avoir leur .config et .local sur le réseau) ainsi qu’à l’impossibilité de faire de pipe et sockets sur des montages réseau ;
la synchronisation se fait à l’ouverture de session dans le sens serveur → poste et à la fermeture de session dans le sens inverse ;
quelques problèmes connus sont liés à ce système : * si l’utilisateur ouvre sa session sur un 2° poste il récupère son profil « serveur » alors qu’il a probablement été modifié sur le 1er poste (mais pas encore synchronisé car sa session y est encore ouverte) * son profil serveur sera écrasé par le contenu du profil du dernier poste sur lequel il fermera sa session … * si le poste est brutalement éteint (panne de courant), ou débranché du réseau (coupure, câble, autre) ou qu’il plante son profil local ne sera jamais « remonté » sur le serveur ;

La piste envisagée est la suivante : une synchronisation périodique des fichiers composant le profil itinérant, de fait si l’utilisateur ferme sa session brutalement ou si son poste « plante » les données auront été sauvegardées sur le serveur (avec 2 minutes de « perte » au pire).

Le problème à gérer est de faire une synchronisation bidirectionnelle, car le profil peut-être modifié des deux côtés si on anticipe l’ouverture possible d’une session utilisateur sur plusieurs postes (cette situation est à éviter mais se produit forcément de temps en temps).

Solution adoptée¶

Après avoir testé bon nombre de solutions notre choix s’est arrêté sur deux outils répondants à nos contraintes (pas de modèle client/serveur, pas de démon à installer, pas de protocole spécifique) :

bsync (script python) - https://github.com/dooblem/bsync
osync (script shell) - https://github.com/deajan/osync

Notre choix s’est finalement arrêté sur osync essentiellement pour les raisons suivantes :

projet dynamique
version 1.3 en cours de release
communauté plus importante que bsync
shell script (bash)

Le code de osync est disponible via la commande horizon-osync. Cette commande est appelée par horizon-osync_runner elle même lancée par horizon-pam (via pam.d donc) à l’ouverture de la session utilisateur.

Explication des options passées à osync :

PRESERVE_OWNER=false : rsync sur le client ne doit pas vérifier les uid des fichiers qu’il synchronise car le montage sshfs ↔ serveur modifie ça tout seul (ACL côté serveur) ;
PRESERVE_GROUP=false : même remarque ;
PRESERVE_ACL=no : idem ;
PRESERVE_XATTR=no : idem ;
RSYNC_EXCLUDE_FROM="horizon-osync.exclude" : le fichier horizon-osync.exclude contient la liste des fichiers à ne pas synchroniser (par exemple les fichier lock, les flags et autres Cache, Temp et Trash) ;

Gestion de la mémoire SWAP¶

Le dernier développement apporté sur l’image du poste client 19.08 est de créer automatiquement une partition swap après le déploiement de l’image si la taille du disque dur est suffisante.

Cette fonctionnalité s’appuie sur la possibilité de lancer automatiquement un script shell à la fin du déploiement d’une image. Ce script porte le nom de horizon-postrestaure

Liens et références¶

En complément de cette synthèse vous trouverez des informations en ligne en suivant les liens ci-dessous :

https://docs.abuledu.org/2019/abuledu_client_19.08/accueil : la section 19.08 du wiki officiel de documentation du projet ;
http://redmine.abuledu.org/projects/horizon/wiki/Gestion_des_profils_itin%C3%A9rants_sous_linux et en particulier la section « Actualisation-2020-Client-Version-1908 » ;
https://redmine.abuledu.org/projects/abuledu-dvd-client/wiki/Page_des_profils_1908;
http://redmine.abuledu.org/projects/abuledu-dvd-client/wiki/Sp%C3%A9cificit%C3%A9s_d'un_client_Abul%C3%89du;

Les tickets et bugs suivants :

Projet

Général

Profil

AbulÉdu » abuledu-dvd-client et client lourd

Wiki