Accéder à distance à un vieux HP ProLiant MicroServer en 2022 : quelle galère !

Présentation de la bestiole

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).

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.

Connexion à l'interface d'accès à 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 :

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 »... 🙃️

Ça y est, on a les droits !

Vous prendrez bien un peu de thé glacé ?

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.

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

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... 😜️

Accès KVM

Je retélécharge donc le fichier JNLP, et je tente de le lancer :

javaws ~/Téléchargements/viewer.jnlp*

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).

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 ! 😑️

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 :

• /etc/java-11-openjdk/security/java.security

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 !

Passons maintenant au lecteur CD virtuel

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.

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 :

1. installer une version Intel 32 bits de Java lorsque cela est possible,
2. installer un Linux 32 bits dans une machine virtuelle et y installer un Java 32 bits,
3. demander à quelqu'un de brancher une clef USB bootable sur le serveur,
4. manger une choucroute en espérant que ça marchera mieux aprè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 ! 😁️

Lancer l'installation de Debian 11

À 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 :

• cliquer sur le bouton « Add Image... »,
• sélectionner l'image ISO de Debian 11 (ou de tout autre système à installer),
• puis cliquer sur la case à cocher « Mapped » à côté de l'image ISO pour que celle-ci soit montée.

Il ne reste plus qu'à redémarrer la machine pour démarrer sur notre image d'installation. Pour se faire,

• on se rend dans « Server Information → Power → Control »,
• on coche la case « Power Cycle System »,
• puis on clique sur le bouton « Apply Changes ».

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'à » ! 😄️

Conclusion

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. 😉️