Les jours en mission se suivent, mais ne se ressemblent pas toujours. Nous avons l’occasion de nous connecter à des serveurs toujours plus nombreux, à livrer nos applications dessus, voire même à les hacker (au sens noble du terme) quand on a le droit, mais les occasions sont rares d’aller plus loin. C’est pourquoi j’aimerais vous faire partager l’expérience que je viens d’avoir du décomissionnement d’un serveur d’appliance Google, que j’ai recommissionné pour en faire un serveur dédié à recevoir nos outils de développements.

A l’origine, il y a l’indexation

Pour commencer, je vais vous expliquer le contexte de ma mission. Les équipes avec lesquelles je suis en relation, dont la mienne, sont là pour réaliser des applications Web et mobile dédiées aux clients particuliers, mais aussi aux entreprises, pour une banque.

Le site Internet est le moyen privilégié pour les clients, ou futurs clients, de rentrer en contact avec la banque. Dans le cas présent, c’est la boîte “Rechercher” qui permet d’effectuer une recherche sur tout le site qui nous intéresse. Derrière cette boîte se cache le moteur d’indexation du site, dont la fonctionnalité est déléguée à un serveur spécialisé : le Google Search Appliance (ou GSA). Le GSA va indexer le site de l’intérieur, c’est-à-dire depuis le réseau de l’entreprise.

Certaines machines de notre environnement de développement sont installées dans des racks dans une salle réseau où certains membres des équipes sont habilités à pénétrer. Le GSA est donc voisin d’autres serveurs, et lorsqu’il faut le remplacer, ce sont des architectes qui sont chargés de réaliser ce travail pour préparer les procédures qui serviront en homologation et en production. J’ai accompagné l’architecte responsable cette fois-ci de cette opération, et pendant qu’il s’occupait du nouveau GSA, j’ai eu l’ancien à ma charge.

Merci Google pour le serveur

Quand un contrat de GSA arrive à son terme, il n’est pas rare que sur une simple demande Google renonce à récupérer la machine. En réalité il est quasiment toujours possible de la recommissionner, et il faut dire que derrière la jolie structure jaune, il s’agit d’un serveur assez classique et qu’il serait bien dommage de le jeter ! Puisque le nouveau GSA est arrivé, et installé dans le rack voisin, il n’y a pas de raison de ne pas faire quelque chose de ces processeurs, de ces presque 40Go de RAM et des 2To de disque en RAID 10 qui nous tendent les bras.

Alors évidemment, le recommissionnement du serveur annule la garantie. Mais on dit quand même “Merci Google !” avant de s’attaquer à le rendre à nouveau utile.

Recommissionner le serveur

Prérequis : une clé USB, un ISO Linux, et Rufus

Après avoir téléchargé un ISO de CentOS minimal, j’ai fabriqué une clé USB bootable. Pour ce faire, sous Windows, j’ai utilisé le logiciel Rufus. La procédure se fait en quelques clics de souris, pour ma part j’ai choisi les options par défaut.

Un petit rappel :

• RedHat Enterprise Linux (ou RHEL) est la distribution préparée et supportée par la société RedHat : si vous avez des serveurs Linux en production, c’est assez probablement celle-ci qui est installée ;
• CentOS est la distribution préparée à l’identique de RHEL, mais sans contrat et sans support : elle remplace efficacement RHEL pour une utilisation ponctuelle et sans budget (accessoirement c’est elle que Google utilise pour ses GSA) ;
• Fedora est la distribution sponsorisée par RedHat, communautaire, sur laquelle des projets sont menés et où les développements sont fournis en avance de phase par rapport à RHEL (bugs compris).

Première étape : on remet tout à zéro

Une fois le serveur proprement déplacé, rebranché, lors de la séquence de boot il faut attendre de voir arriver l’option de configuration des disques, qui se déclenche par un appui sur Ctrl + R.

Dans cet écran, j’ai choisi le périphérique virtuel et appuyé sur F2 pour obtenir un menu qui propose de faire une réinitialisation rapide. Une fois rendu là, le système CentOS installé par Google a été effacé.

Quelques appuis sur Echap, et un redémarrage plus tard, tout s’étant bien passé j’ai arrêté le serveur et je l’ai débranché électriquement.

Seconde étape : reconfigurer le BIOS

Il est possible de remplacer intégralement le BIOS fourni par Google par un BIOS plus classique (récupéré chez DELL). Afin d’aller au plus simple j’ai choisi de ne réinstaller que le système.

Si vous vous demandez encore comment ouvrir la serrure d’un GSA…

Avant de pouvoir commencer à installer son propre système, il faut pouvoir donner le droit à la machine de booter sur une clé USB. Pour cela, j’ai ouvert le boitier et cherché sur la carte mère un cavalier nommé “PWRD_EN”. Celui-ci enlevé, il suffit de refermer le boitier, de rebrancher électriquement et de démarrer le serveur. Le retrait de ce cavalier permet en effet de pénétrer dans le BIOS une fois arrivé en fin de boot, lorsque le serveur indique qu’il ne trouve aucun système bootable. Par défaut Google met un mot de passe au BIOS, c’est pourquoi cette partie de la procédure est indispensable.

J’ai alors reconfiguré le BIOS pour qu’il soit en mode “UEFI”, à l’image de ce qui a été fait sur la clé USB (UEFI + MBR, l’option par défaut dans Rufus).

Une fois la machine redémarrée, le système de la clé USB est chargé et l’installation peut commencer.

Troisième étape : installer le système

Autant dire que l’installation du système CentOS est d’une simplicité totale. Je ne détaillerai même pas la procédure, j’ai même été surpris de trouver que l’installeur est en mode graphique. Pour l’anecdote, comme il n’y a que deux prises USB à l’arrière du GSA, et que la clé USB branchée en utilisait un, je n’ai pu brancher qu’un clavier. Tant pis pour la souris, de toute manière la navigation avec Tab, les flèches et la barre espace fonctionne très bien.

Le serveur configuré, j’ai créé un premier utilisateur, ajouté au groupe wheel et changé son mot de passe.

useradd -m -G wheel <utilisateur>
passwd <utilisateur>

Puis j’ai donné le droit aux utilisateurs du groupe wheel d’être sudoers (dans le fichier /etc/sudoers) :

## Allows people in group wheel to run all commands
%wheel ALL=(ALL) ALL

J’ai aussi configuré l’interface réseau :

ifcfg eth0 add <IP>/<masque CIDR>
ifup eth0

Et ajouté la passerelle par défaut :

route add default gw <IP>

Ensuite j’ai déclaré les serveurs DNS dans /etc/resolv.conf :

search sous.domaine.tld
nameserver <IP du serveur DNS>

Et enfin j’ai bien sûr demandé à l’administrateur du serveur DNS d’inscrire le nom de notre nouveau serveur afin que la résolution se fasse correctement depuis les autres machines du réseau. Ces quelques opérations effectuées, le serveur est pleinement opérationnel !

Deux GSA ça va, trois c’est encore mieux

C’est le troisième GSA qui est recommissionné de cette manière dans la salle. Les deux premiers l’ont été par d’anciens consultants, depuis partis vers d’autres horizons. Il n’y a jamais eu de documentation écrite, mais il restait l’idée. Je suis content d’avoir réussi comme eux à donner une seconde vie à un serveur comme celui-ci, d’une part parce que c’est quelque chose qui sort assez largement du cadre habituel d’une mission de développeur, et surtout d’autre part parce que ce serveur sera bientôt très utile à toutes les équipes.

Maintenant, la porte de la salle serveur s’est refermée. Mais le serveur est là, fidèle au poste et joignable par SSH, prêt à accueillir JVM et JDK, Git, Jenkins, Artifactory et tous leurs amis.