Il est temps de noter les objectifs essentiels de la version 9.x d'AbulÉdu, de nombreux liens seront faits entre cette page et le forum pour chaque point important.

• Base de travail: Ubuntu 8.04 LTS (pas encore définitif, à cause de la version de xorg impossible à passer en 1.6 …)
  Finalement c'est la version 9.04 qui sert de base à cette nouvelle version.
• Support multilingue http://forum.abuledu.org/topic/international-amp-multilingue
• Gestion des terminaux LTSP 4.4 http://forum.abuledu.org/topic/module-gestion-tx-recents-2009
• Gestion de Windows Vista http://forum.abuledu.org/topic/prise-en-charge-des-postes-windows-vista
  Suite au “cadeau” de Microsoft on reste sur XP Pro.
• Améliorations diverses du système (applications plus récentes, etc.)
• Annuaire LDAP
• Compatibilité améliorée pour les Macintosh sous réserve de fournir un Mac-intel et un Mac-ppc (de préférence portables) à RyXéo pour les tests et validations.

Le développement et les tests doivent suivre le document de validation suivant: (tests de régression) ou l'outil de validation proposé par François: → http://www.ryxeo.com/testlink/.

Du temps des postes Windows 98, nous avions mis en place un partage réseau “profs2eleves” qui permettait aux enseignants de mettre des ressources à disposition des élèves.

Ce nom étant maladroit et les outils d'administration d'AbulÉdu actuels permettant de créer très facilement des partages ayant les mêmes caractéristiques il est actuellement demandé sur la liste dev@abuledu.org si personne n'est contre la mort pure et simple de ce partage.

L'interface Web d'administration évolue quelque peu pour fournir des outils adaptés à certaines contraintes “nouvelles” souvent liées au plan des ENR.

Pour faciliter le déploiement des centaines de postes clients, RyXéo a finalisé le système de gestion des maquettes des postes clients.

En amont, RyXéo crée une image disque d'un poste “type”, par exemple pour les Lenovo S10e, et fournit cette image à l'ensemble de ses partenaires et revendeurs qui peuvent ainsi suivre une procédure de déploiement massif des postes clients.

Ce service est strictement réservé à nos partenaires et revendeurs officiels.

Il en va de même pour la gestion de la clé wifi centralisée dans webadmin : si vous êtes dans une situation de déploiement massif, cette fonctionnalité vous permet de configurer les paramètres de connexion wifi pour tous les postes Windows et Linux en une seule passe.

C'est une bricole mais c'est arrivé avec cette nouvelle version : les ordinateurs portables n'auront plus le pavé numérique forcé à chaque ouverture de session. Il suffit de ne pas cocher la case “pavé numérique” lorsque vous fixez la configuration du poste.

Les performances de webadmin ne sont pas terribles du fait de l'implémentation historique du moteur de cache et du passage sur LDAP. LDAP n'est pas en cause mais notre moteur de cache oui :) ça sera donc amélioré très rapidement.

Mis à part le déploiement initial d'une maquette sur tous les postes Windows, cette nouvelle version d'AbulÉdu apporte un certain nombre de changements majeurs pour cet environnement.

Il n'est plus nécessaire de demander un mot de passe “root” temporaire pour rejoindre le domaine AbulÉdu: l'utilisateur abuladmin a tous les droits pour réaliser cela.

Après avoir rejoint le domaine, abuladmin doit double-cliquer sur le script installation.bat et rebooter le poste, tout est ensuite automatique.

Le serveur AbulÉdu déploie automatiquement sur tous les postes du domaine Windows les logiciels qui ont été sélectionnés.

Selon la maintenance, choisie ces applications peuvent varier. Par exemple si une académie décide de déployer un antivirus à grande échelle, nous pouvons totalement l'automatiser sur l'ensemble du parc des postes clients Windows de tous les réseaux AbulÉdu de l'académie.

Concernant les Macintosh, j'ai eu la chance d'en avoir un entre les mains pendant deux jours et c'est absolument sensationnel, le seul hic c'est qu'il faut intégrer les bases minimales le plus rapidement possible.

OSX est intégralement Zéroconf Bonjour ce qui implique qu'en étant un peu rusé on peut faire beaucoup de choses géniales côté serveur pour faire en sorte qu'un Mac connecté au réseau s'autoconfigure quasi totalement.

J'ai pu rapidement faire un 'lanceur' pour que tout Mac puisse avoir une icone sympa pour lancer une session X distante : http://docs.abuledu.org/abuledu/administrateur/configbasemacos
Il suffit de télécharger le fichier DMG (tout utilisateur de Mac sait comment ça se passe) et glisser/déposer l'icone du lanceur dans Applications. C'est simple comme … bonjour :)

Le système d'impression des Macs étant cups, il n'y a rien à faire à ce niveau-là.

Et pour ce qui est de l'authentification centralisée et du déport du compte utilisateur sur le serveur, c'est possible moyennant l'intégration du schéma LDAP d'Apple… ce qu'il faut faire au plus vite.

Dans tous les cas nous devons trouver une solution pour que les TX minimums soient des Pentiums 2 avec 64 Mo de RAM … ça me semble être la situation acceptable.

Le problème de LTSP est compliqué : les développeurs officiels de LTSP ont pris la décision avec LTSP 5 de pousser de plus en plus les applications en exécution locale (en particulier Firefox pour les problèmes liés à Flash et de charge réseau).

LTSP5 nécessite des performances importantes du côté des postes clients (par exemple un P4 avec 512 Mo de RAM minimum) … ce qui est loin d'être l'état du parc dans nos écoles (tentative de collecte d'informations sur http://forum.abuledu.org/topic/votre-parc-informatique).

Il y a un autre gros problème : Xorg évolue vite et les nouvelles versions utilisent XCB à la place de Xlibs … Si on a un Xorg local au terminal léger (compilé donc avec xlibs) et des applications côté serveur (avec XCB donc) ça provoque un certain nombre de problèmes dont des lenteurs horribles (menu déroulant dans Firefox par exemple).

Nous avons donc un gros chantier autour de LTSP 4.4 qui est une création purement RyXéo/AbulÉdu … créer un LTSP récent avec une lib XCB et garder la philosophie “LTSP 4” avec toutes les applications lancées sur le serveur et affichées sur le TX.

Ça marche mais … le Xorg récent occupe environ 128 Mo de RAM à l'heure actuelle. La compilation de tout LTSP 4.4 avec uclibc n'a pas amélioré sensiblement les choses et surtout pulse audio ne compile pas à l'heure actuelle avec uclibc.

La gestion des clés USB évolue également et il faut juste prendre soin d'avoir la même version de ltspfs(d) côté serveur et client.

Le son passe maintenant sur pulseaudio en lieu et place de esd (esound) … Même remarque que pour l'USB : il faut juste faire attention d'avoir des versions compatibles sur le client et le serveur.

Le passage sur l'annuaire est validé, il reste à faire très rapidement le nécessaire pour le support natif des ordinateurs OSX (Macintosh) dont le schéma ldap “apple.schema” doit être migré ou adapté pour OpenLDAP 2.4 … Ce point est bloquant pour toute la suite.

Quelques problèmes sont encore en cours : certains privilèges sont liés aux fichiers /etc/group par exemple lpadmin et les utilisateurs qui sont dans l'annuaire ne peuvent pas vraiment faire partie de groupes qui ne sont pas dans l'annuaire (inconsistance lorsqu'on sera sur un client lourd Linux par exemple).

Ce problème est en cours de résolution.

L'intranet évolue un tout petit peu au niveau des “pages perso” : si un utilisateur dépose un fichier index.png dans son répertoire public_html cette image sera mise en en-tête du “listing” du répertoire.

De même le listing du contenu d'un répertoire utilisateur est un peu plus “sympa” qu'avant :)

iTalc se déploie tout seul et est préinstallé sur le serveur.

Il reste à déployer la clé maître/élève en fonction de l'ouverture de la session (postes Windows, sous Linux c'est déjà ok) et à vérifier que ça n'écroule pas trop les performances des terminaux légers.

À terme on aura peut-être / probablement une case à cocher dans webadmin “activer italc sur ce poste” si ça prend trop de ressources comme je l'imagine.

Le moyen le plus simple de savoir si vous êtes sur le serveur ou le client lourd c'est de faire un test sur le fichier /etc/abuledu/clientlourd, ce fichier sert de “flag” et sera peut-être inclus dans le fichier configuration dans le futur.