2022-04-18
Depuis quelques semaines je travaille à la migration et à la mise à jour de mes serveurs. L'un d'entre eux était un vieux HP ProLiant MicroServer qui tournait toujours sous Debian 7 depuis presque 10 ans. Le pauvre avait été un peu oublié dans un coin chez mes parents et ne faisait plus tourner que mon lecteur de flux RSS, que j'ai migré sur un autre serveur il y a quelques jours.
Étant donné qu'il dispose tout de même de 6 To de d'espace disque, j'ai décidé de le reconvertir en serveur de stockage pour mes sauvegardes. J'ai donc entrepris de lui réinstaller un petit Debian 11 tout beau tout neuf... et c'est là que les ennuis ont commencé ! 😓️
Photo du serveur HP ProLiant MicroServer gen 7
Ce serveur est donc un petit HP Proliant MicroServeur de 7ème génération. Il est équipé de 2 Go de RAM ECC, d'un « vaillant » AMD Turion II Neo N40L dual core à 1,5 GHz, d'un disque de 240 Go pour le système et donc de 6 To de stockage pour les données (un RAID 5 composé de 3 disques de 3 To).
Comme je l'ai dit en introduction, cette machine ne se trouve pas chez moi ; il va donc falloir effectuer toutes les opérations à distance. Heureusement j'ai été prévoyant, et j'ai équipé le serveur d'une carte d'accès à distance (on parle de RAC pour Remote Access Card).
Photo de la carte d'accès à distance
Carte d'accès à distance du HP ProLiant MicroServer
Cette carte fournit une interface Web permettant d'afficher l'état du serveur (température, vitesse du ventilateur,...) de l'allumer, de l'éteindre, d'accéder à son écran, clavier et souris comme si on se trouvait sur place (vKVM), et même de lui monter des images ISO dans un lecteur CD virtuel (vMedia). Bref, tout ce qu'il faut pour effectuer une réinstallation du système à distance.
Pour accéder à l'interface de la carte RAC, on a besoin de connaitre son adresse IP, un nom d'utilisateur et le mot de passe qui va avec. Je dispose bien sûr de toutes ces informations que je conserve bien au chaud dans mon gestionnaire de mot de passe, je peux donc me lancer !
J'ouvre mon navigateur, et entreprends de me rendre à l'adresse https://<IP_DE_LA_CARTE_RAC>/ pour accéder à interface Web de la carte. Et... raté. J'obtiens pour seule réponse une erreur de sécurité de la part de Firefox :
Échec de la connexion sécurisée
Une erreur est survenue pendant une connexion à <IP_DE_LA_CARTE_RAC>. Le pair utilise une version non gérée du protocole de sécurité.
Code d’erreur : SSL_ERROR_UNSUPPORTED_VERSION
La version de TLS utilisée par la carte est totalement obsolète, et Firefox, ainsi que l'ensemble des autres navigateurs, ne la supporte plus du tout... Ça commence bien ! 😑️
« Heureusement », la carte ne force pas l'utilisation du HTTPS, je peux donc accéder à l'interface en HTTP, et j'arrive enfin devant la page de connexion :
Capture d'écran de la page de connexion de la carte d'accès à distance
Je m'empresse donc d'y rentrer mes identifiants puis je clique sur le bouton « Sign In »... Et... nouvel échec ! Je me retrouve à nouveau devant la page de connexion, sans aucune erreur ni aucune autre information supplémentaire... 🤨️
Après avoir essayé des tas de trucs pendant une bonne dizaine de minutes, j'ai fini par me rendre compte que si je validais le formulaire en cliquant sur le bouton prévu à cet effet, et bah ça ne marchait pas ; mais que si je me plaçais dans le champ de mot de passe (et seulement celui-ci !) et que j'appuyais sur « Entrée », là ça marchait ! 🤷
Pour paraphraser un grand philosophe contemporain : « encore un truc codé avec le postérieur posé sur une commode Louis XV » (ou un truc dans ce genre-là, je n'ai jamais été très doué en citation). En tout cas, si même l'étape de connexion est à ce point mal foutue, la suite risque d'être... « intéressante »... 🙃️
Capture d'écran après une connexion réussie
Ça y est, on a les droits !
Sans plus attendre, je me rends sur la page « vKVM & vMedia » pour accéder à l'écran et au clavier de la machine et enfin pouvoir procéder à sa réinstallation.
Capture d'écran de la page vKVM & vMedia
Page vKVM & vMedia
Je clique donc sur le gros bouton « Launch KVM Viewer » et... Quoi ?! Il me télécharge un fichier ?!! « viewer.jnlp » ? Ah oui c'est vrai, j'avais oublié... le serveur est sorti il y a plus d'une dizaine d'années, et à cette époque-là, on ne faisait pas encore de console Web... Il va falloir composer avec des applications Java Web... Youpi ! 👍️
Pour lancer ces applications Java Web, il nous faudra utiliser la technologie Java Web Start, présente dans le JRE (Java Runtime Environment) officiel d'Oracle jusqu'à sa version 11. Il existe également une implémentation open source nommé Iced Tea, qui se base sur OpenJDK, la version open source de Java. Je vais bien évidemment partir sur cette dernière, qui a en plus le bon goût d'être disponible dans les dépôts de ma distribution.
Sous Debian / Ubuntu, on peut installer Iced Tea à l'aide de la commande suivante :
sudo apt install icedtea-netx
--------------------------------------------------------------------------------
📝️ Note:
--------------------------------------------------------------------------------
NOTE : Si vous êtes sous Fedora ou Archlinux, le paquet à installer se nomme icedtea-web.
--------------------------------------------------------------------------------
Une fois le paquet installé, il suffit, théoriquement, de télécharger le fichier JNLP et de le lancer à l'aide de la commande suivante :
javaws fichier.jnlp
Mais les choses ne se passent pas toujours aussi bien, sinon vous seriez déjà à la fin de cet article... 😜️
Je retélécharge donc le fichier JNLP, et je tente de le lancer :
javaws ~/Téléchargements/viewer.jnlp*
--------------------------------------------------------------------------------
📝️ Note:
--------------------------------------------------------------------------------
NOTE : L'étoile à la fin du nom du fichier n'est pas une faute de frappe, elle est là pour simplifier la commande : le nom du fichier téléchargé est en réalité "viewer.jnlp(<IP_DE_LA_CARTE_RAC>@<ID_SESSION>@<TIMESTAMP>)", et change à chaque téléchargement.
--------------------------------------------------------------------------------
Une fois démarré, Iced Tea commence par m'afficher moulte avertissements de sécurité (bon ok, « seulement » deux), que je m'empresse d'accepter (par ce que de toute façon pas le choix).
Capture d'écran des alertes de sécurité
Une fois toutes les permissions accordées, l'application se lance... pour m'afficher un message d'erreur des plus informatif : « Connection failed. ». Pas un mot de plus ! Et bien évidemment, aucune information supplémentaire n'est disponible dans la console, ça serait trop simple sinon ! 😑️
Capture d'écran du message d'erreur.
Après avoir fait pas mal de recherches, je tombe sur la page d'un wiki qui explique que le problème vient de la politique de sécurité de Java : les algorithmes utilisés par l'application sont obsolètes et sont donc blacklistés. Pour contourner ce problème, il faut aller trifouiller les paramètres de sécurité de Java pour réautoriser ces vieux algorithmes...
On va donc aller modifier le fichier "security/java.security" situé dans le dossier de configuration de la version de Java que l'on utilise. Pour ma part j'utilise OpenJDK 11, et le fichier se trouve à l'emplacement suivant :
Dans ce fichier il faudra trouver la configuration "jdk.tls.disabledAlgorithms" et la commenter pour qu'elle ne soit plus effective. Dans mon cas, j'ai donc remplacé les lignes suivantes :
jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \
DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
include jdk.disabled.namedCurves
Par :
# jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \ # DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \ # include jdk.disabled.namedCurves
Une fois ceci fait, je retélécharge le fichier JNLP (il faut le retélécharger à chaque tentative car il contient un couple identifiant / mot de passe à usage unique) puis je le lance :
javaws ~/Téléchargements/viewer.jnlp*
Et là, victoire ! J'accède enfin au serveur !
Capture d'écran de la fenêtre d'accès à distance
Il ne reste plus qu'à charger l'image ISO de Debian pour réinstaller le système. Je clique donc sur le gros bouton « Launch VM Viewer ». Il me télécharge cette fois encore un fichier JNLP appelé « data » (ils n'ont vraiment pas fait le moindre effort sur le nom des fichiers), et je tente de l'exécuter :
javaws ~/Téléchargements/data
Et après m'avoir affiché les habituelles alertes de sécurité, je me retrouve, cette fois encore, devant un message d'erreur : « The Virtual Media native library cannot be loaded. ». Bon, au moins on a un message un minimum informatif cette fois-ci.
Capture d'écran du message d'erreur
En jetant un coup d'œil dans la console, on se retrouve avec l'avertissement suivant :
OpenJDK 64-Bit Server VM warning: You have loaded library /tmp/netx-native-62718/libavmlinux.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
Au moins ça nous confirme qu'on a un problème avec une bibliothèque native (libavmlinux.so), mais il faut toutefois se méfier de la solution proposée qui est une fausse piste. 🙃️
En résumé, l'un des .jar de l'application contient une bibliothèque native (un fichier .so pour Linux, un .dll pour Windows, et si vous utilisez macOS, vous pouvez vous gratter, rien n'est fourni pour ce système). Étant donné que cette bibliothèque est compilée pour l'architecture Intel 32 bits, il nous faut une version 32 Bits de Java pour qu'elle puisse être chargée...
On se retrouve donc face à 3 possibilités :
Dans mon cas, je vais opter pour la première solution, car par chance, Debian (et donc Ubuntu) permettent de faire cohabiter des versions 32 et 64 bits des bibliothèques et applications.
Je vais donc installer OpenJDK 8 32 bit pour essayer de faire marcher tout ça. Pourquoi cette version précisément ? Aucune raison particulière, je l'ai choisie au hasard.
Pour installer la version de Java choisie, compilée pour une architecture Intel 32 bit sous Debian et Ubuntu, la commande est la suivante :
sudo apt install openjdk-8-jdk:i386
Il ne reste plus qu'à trouver comment indiquer à Iced Tea qu'il doit utiliser cette version de Java. J'ai essayé plein de trucs, y comprit update-alternatives mais rien n'y fait... Au final, la solution la plus simple que j'ai trouvée a été de modifier le script /usr/bin/javaws pour qu'il aille chercher la bonne version.
On va donc commencer par copier le script en question afin de conserver l'original intact :
sudo cp /usr/bin/javaws /usr/bin/javaws32
Puis on l'édite avec les droits root (dans mon cas je vais utiliser Vim mais vous pouvez utiliser l'éditeur de votre choix hein) :
sudo vim /usr/bin/javaws32
Il ne reste plus qu'à modifier la ligne qui définit l'emplacement du JRE à utiliser. Par défaut elle se présente ainsi :
JRE=/usr/lib/jvm/default-java
Il faudra donc l'adapter pour la faire pointer sur notre version de Java 32 bits, ce qui donne pour moi :
JRE=/usr/lib/jvm/java-8-openjdk-i386/
Je peux à présent retélécharger mon fichier JNLP et essayer de le lancer avec cette version :
javaws32 ~/Téléchargements/data
Et cette fois, miracle, ça fonctionne ! 😁️
Capture d'écran de l'outil vMedia
À présent que tout fonctionne, on peut monter notre image ISO de Debian 11 pour, enfin, pouvoir procéder à son installation ! Pour se faire, il faut :
Capture d'écran de l'applet avec une ISO montée
Il ne reste plus qu'à redémarrer la machine pour démarrer sur notre image d'installation. Pour se faire,
Capture d'écran de la page « Power Control » de la carte RAC
Et voilà ! On se reconnecte au KVM si on l'avait fermé, et on se retrouve sur le menu du média d'installation de Debian, « ya plus qu'à » ! 😄️
Capture d'écran de la fenêtre du KVM sur le menu d'installation de Debian 11
Accéder au KVM et au lecteur CD virtuel d'un HP ProLiant MicroServer gen 7 est toujours possible en 2022, mais c'est quand même une sacrée galère.
Au final le plus gros problème, c'est le manque total d'information utile dans les messages d'erreur des applications. Avec des erreurs un peu plus détaillées, j'aurais clairement perdu moins de temps. J'espère du coup que cet article pourra être utile à d'autres, pour qu'ils ne passent pas autant de temps que moi à chercher pourquoi ça marche pas. 😉️
--------------------------------------------------------------------------------
