La solution de l'usage des terminaux légers nous a permis d'atteindre le but fixé : s'approcher du zéro absolu au niveau de la maintenance du poste client. Soit le TX marche, soit il ne marche pas. Lorsqu'un TX meurt on le remplace, “tout simplement”.

Il n'y a plus besoin de passer sur chaque ordinateur pour mettre à jour l'antivirus, vérifier que les logiciels marchent bien, etc.

De plus cette solution est bien adaptée au reconditionnement d'ordinateurs anciens, on peut réutiliser un Pentium à 200 Mhz comme poste client sans aucun problème.

Mais… avec l'évolution des ordinateurs nous voyons arriver des Pentium 4 (ou plus) dans les réseaux scolaires … et dans ce cas de figure on n'utilise pas au mieux les équipements. En effet le Pentium 4 à 2,8 Ghz (par exemple) serait tout à fait en mesure de lancer OpenOffice.org (et les autres logiciels) lui-même, le serveur ne ferait alors plus que serveur de stockage de fichiers, partage de connexion internet, serveur d'impression, etc.

On pourrait aussi améliorer grandement la gestion des périphériques locaux si les ordinateurs sont des “postes clients lourds” (carte vidéo 3D, carte son, scanner, périphériques en tout genre).

Car dans les principales difficultés liées aux terminaux légers (TX) se trouve la gestion des périphériques locaux du TX alors que les logiciels sont lancés sur le serveur …

Voici donc en quelques lignes un résumé de ce travail lancé sur les “postes lourds”. Lourds pourquoi ? Tout simplement parce qu'on utilise leur processeur, leur disque dur, et les périphériques locaux.

Les postes lourds ne doivent pas nous causer plus de problèmes que les terminaux légers. Ils doivent également avoir un niveau de maintenance proche du zéro absolu et ne doivent en aucun cas compliquer la vie des utilisateurs.

Lorsqu'un poste lourd démarre, il lance une requête réseau (de type PXE) comme tout terminal léger. Cela nous permettra de transformer un poste lourd en TX en quelques secondes ou de réinstaller son système si nécessaire.

Ensuite il amorce un système identique à celui du serveur. Pourquoi ? Tout simplement pour éviter ceci :

Imaginez que vous avez une distribution plus récente sur votre client lourd que sur le serveur. Lorsque vous vous authentifiez, votre KDE super récent “migre” vos fichiers de configuration de “.kde” vers la nouvelle version. Ensuite vous retournez sur un terminal léger avec un KDE plus ancien et là … explosion de problèmes : votre profil kde ayant été mis à jour avec une version plus récente vous ne pourrez plus vraiment travailler.

Durant la procédure d'amorçage il devra demander des instructions au serveur, nous sommes donc en train de travailler sur une interface de gestion des postes lourds pour éventuellement déclencher automatiquement une mise à jour du poste, réinstaller un logiciel, déployer un “truc” ou tout ce qui pourrait nous passer par la tête.

Et enfin, lorsqu'il lancera l'interface graphique permettant aux usagers de travailler, il “passera le jeton” d'authentification au serveur qui vérifiera si cet utilisateur est connu. Si tel est le cas, la session sera ouverte et les fichiers personnels de cet utilisateur accessibles depuis le poste lourd.

La solution industrielle retenue est la suivante : Vous utilisez le DVD d'installation AbulEdu 8.08.2 et choisissez “installer automatiquement un client lourd”.

À la fin de l'installation vous devrez alors faire une mise à jour du client lourd:

• connectez le poste sur le réseau abuledu (physiquement, branchez sa prise réseau)
• basculez sur la console n°1 du poste lourd avec la combinaison des touches “Ctrl + Alt +F1”
• authentifiez-vous en root (mot de passe par defaut “ryxeo”)
• changez tout de suite le mot de passe root avec la commande “passwd”
• lancez la commande “apt-get update”
• lancez la commande “apt-get dist-upgrade”
• attendez la fin de la mise à jour
• redémarrez votre poste

Lors du premier démarrage (après la mise à jour) si votre poste n'est pas fixé sur le serveur abuledu il vous demandera de le faire. Ensuite il vous proposera de rejoindre le domaine abuledu. Et enfin si tout ceci est fait vous pourrez vous authentifier avec un compte valide sur le réseau abuledu !

À peu près tout :) Les bugs sont à remonter sur la Forge de Ryxéo

— Éric Seigne (OpenID) 2009/03/04 09:40