2006 - 2007

Ingenieur informatique — UCAD - Union centrale des arts decoratifs (musee)

Paris



---  ---

Institution museale, +300 salaries. Parc mixte : postes de travail Windows et postes Linux ; serveurs Linux (production Debian, etc.) et stack Windows/Novell. Pas encore d'Active Directory : l'institution reposait sur Novell, dont l'annuaire (NDS / eDirectory) centralisait utilisateurs et ressources - l'equivalent fonctionnel anterieur a l'ecosysteme AD dans ce type d'infrastructure. MCO serveurs Windows et Novell, Solaris ; support bureautique niveau 1 et production niveau 2.



--- Contexte - recyclage Windows → Linux ---

Pour revenir en arriere a l'epoque ou j'etais a l' UCAD , l'un des points les plus remarquables etait le recyclage des anciennes machines abandonnees ou jugees obsoletes sous Windows : les nouvelles generations de Windows exigent toujours plus de puissance, alors que des installations sous Linux permettaient de reutiliser le materiel existant et de prolonger le service a moindre frais . Experience marquante dans l'ensemble du mandat : remettre a niveau un parc longtemps delaisse avec tres peu de moyens ; les alternatives open source ont aussi permis de remplacer des logiciels proprietaires a cout de licence quasi nul, tout en evitant de mettre au rebut du materiel encore exploitable.



--- Site distant & portables recycles ---

Avec des budgets serres, il fallait optimiser tout le parc et recycler au maximum. Les portables etaient encore tres chers ; peu de collaborateurs en avaient un - le standard restait la tour sous le bureau. Pour equiper un site distant et permettre aux equipes de realiser des inventaires dans les reserves du musee, nous avons recupere d'anciens ordinateurs portables, a peine assez puissants pour faire tourner Linux avec une stack graphique legere (X11), puis le client Citrix pour acceder aux applications metier en mode bureau distant. L'association Linux + Citrix permettait de donner au personnel une experience de poste de travail exploitable avec tres peu de ressources locales.



--- Debian, noyau & pilotes (materiel recycle) ---

Pour arriver a ce resultat (fait tourner des machines " bout de course " sous Linux), il a fallu maitriser l'ensemble des composantes du systeme Linux et, au premier chef, la compilation du noyau : iterations successives - compiler encore et encore jusqu'a obtenir une installation suffisante (stable et utilisable) sur le materiel cible. Un effort considerable est aussi alle a la compatibilite materielle : le support n'etait pas encore homogene comme aujourd'hui, peu de pilotes vraiment generiques dans les noyaux standards ; traque de pilotes adaptes, recompilation pour du materiel tres specifique, et recompilation pour alleger le noyau (RAM, CPU, disque) en retirant les modules inutiles. Base essentiellement Debian . A l'epoque, je m'etais beaucoup appuye sur la documentation et la formation qu' Alexis Delattre mettait librement a disposition sur Internet : Formation Linux (PDF) - linux.bouzzi.com .



--- Affichage graphique - interfaces et configurations optimisees ---

A l' UCAD , j'ai aussi du etudier les interfaces graphiques - ou du moins toute la chaine de composants necessaire a l' affichage graphique sous Linux - puis choisir et configurer les combinaisons les plus optimisees possibles pour qu'elles restent tenables sur du materiel peu puissant (parc recycle), tout en restant compatibles avec l'usage bureautique.



--- Controle et bureau a distance (VNC, RDP, NX Server) ---

J'ai aussi du etudier les solutions de controle a distance et de bureau a distance : VNC , RDP (Remote Desktop Protocol) et NX Server / NoMachine (NX) - pour l'assistance, l'acces aux postes distants et l'exploitation d'un parc Windows / Linux heterogene.



--- Compilation depuis les sources (Apache, SSL, modules) ---

Il n'etait pas rare de devoir compiler nous-memes des logiciels plutot que de nous limiter aux paquets fournis : pour plusieurs briques, le packaging n'etait pas encore assez abouti. C'etait souvent le cas pour les serveurs Apache, les bibliotheques SSL/TLS et les differents modules Apache associes (mod_ssl, etc.).



--- Proxy Squid et miroir local de paquets (Apache) ---

A l' UCAD , j'avais installe un serveur proxy Squid : Squid - pour securiser et fluidifier les acces Internet lors des installations de logiciels . Nous utilisions en parallele un miroir local des paquets d'installation, expose sous Apache ( HTTP Server ), afin de limiter la bande passante sortante et d'accelerer les deploiements sur le parc.



--- Sauvegardes ---

La sauvegarde sur bande etait assuree par Bacula (pools, jobs, lecteurs…). La sauvegarde sur disque reposait sur BackupPC - solution libre de sauvegardes incrementelles vers stockage disque, complementaire a la partie magnetique.



--- Messagerie ---

Le socle messagerie : Postfix (MTA) avec acces IMAP pour les clients lourds, et webmail via SquirrelMail pour l'acces dans le navigateur.



--- Perimetre reseau (Linux & iptables) ---

Il n'y avait pas encore d'appliance pare-feu dediee : une machine Linux tenait lieu de pare-feu ; la configuration passait par iptables pour filtrer et piloter l'ensemble du trafic reseau du musee.



--- DNS (BIND) ---

Le service DNS etait assure par BIND ( Berkeley Internet Name Domain ), tel que maintenu par l'ISC.



--- Wi-Fi : Linksys WRT54G & DD-WRT ---

Pour l'acces sans fil, utilisation de routeurs Linksys WRT54G . Pour maximiser la capacite d'exploitation et simplifier la maintenance, le firmware constructeur a ete remplace par le projet libre DD-WRT .



--- Securite, recyclage : LTSP, PXE & postes diskless ---

Pour les postes legers , je m'etais notamment appuye sur LTSP - Linux Terminal Server Project - qui permet de faire demarrer les clients sur le LAN depuis une installation modele sur le serveur (image/chroot), avec iPXE, DHCP/TFTP et root en squashfs/NFS : entretenir des dizaines de stations diskless comme un seul poste. J'ai aussi etudie et mis en place le boot a distance via PXE et des deploiements diskless (sans disque dur local) : on manquait souvent de disques sur le materiel recupere, et ce modele permettait de n'avoir cote poste que de simples terminaux - systeme et donnees servis depuis l'infrastructure centrale. Chaine PXE operationnelle (menu de boot, profils par adresse MAC , redeploiement a distance) pour securiser la remise en service du parc et prolonger le recyclage ; montages d'arborescences via NFS pour les postes diskless.



--- Materiel, video et kiosques ---

Le parc n'etait pas tres puissant : les machines les plus recentes etaient des Intel Pentium 4 , a peine suffisantes pour la lecture video. On travaillait surtout en MPEG-1 et MPEG-2 ; le H.264 / MP4 n'etait pas encore la norme sur ce type de poste. VideoLAN existait deja, mais n'etait pas le plus leger sur ce materiel. Le lecteur le plus frugal et optimise pour nos usages etait MPlayer . Dans les salles du musee, kiosques sur mesure : postes Linux lancant un navigateur (affichage plein ecran), avec verrouillage des touches de fonction et des raccourcis pour empecher l'utilisateur de sortir du parcours prevu. Postes dedies a la lecture video et autres dedies a l'affichage de sites intranet .



--- Gestion des collections (Mobidoc) ---

Pour la gestion des oeuvres et du fonds museal, le logiciel metier etait Micro Musee, edite par la societe Mobidoc ; a l'epoque, aucun equivalent open source ne permettait de couvrir le besoin de facon satisfaisante.



--- Deploiement & migrations ---

Les deploiements couvraient le poste Windows (reinstallation massive sous delais serres) et la partie Linux du parc (postes et serveurs). Pour Windows, l'habitude etait l'image disque avec Symantec Ghost et des masters sur l'infrastructure Novell - peu souple. Nous avons experimente Unattended pour des installations automatisees et parametrables, en complement des methodes rigides par clone. Premiere experience marquante en automatisation : les chaines Unattended reposaient sur de nombreux scripts melangeant shell , Perl et AutoIt - langage dedie au pilotage de l'interface Windows (fenetres, frappes clavier, mouvements de souris) pour fiabiliser les installations, en parallele de la preparation de paquets MSI et de deploiements silencieux. Cote bureautique et fichiers : migration vers Samba pour le partage (Windows XP / NT4 / 2000), cohabitant avec l'annuaire Novell ; rationalisation des lecteurs CD. Les debuts de GLPI et de l' OCS Inventory (serveur) sur le site : realisation d'un plugin pour alimenter GLPI a partir des remontees OCS, ce qui a permis d'obtenir un inventaire complet et exploitable de tout le parc. A l'epoque, peu d'institutions avaient encore generalise un systeme de tickets pour les incidents ; il a ete decide d'adopter Request Tracker (RT) , logiciel libre de gestion d'incidents et de suivi d'actions.



--- Documentation ---

La documentation technique et procedurale a ete redigee en LaTeX ( LaTeX Project ), pour des livrables structures, revisables et export PDF.

