Projet

Général

Profil

AbulÉdu Client Lourd 19.08.1

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

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) : 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 : Les tickets et bugs suivants :
Redmine Appliance - Powered by TurnKey Linux