Se connecter par KVM à son serveur OVH via l'applet Java

J'ai actuellement 2 serveurs chez OVH : Chalice et Shaddam (Shaddam II pour être précis, la version 1 était chez feu Gandi que j'ai quitté sans regret suite à leur rachat par TWS).

Lors de la montée en version vers Debian 13 "Trixie", j'ai eu la mauvaise surprise de ne pas voir Chalice revenir en ligne après le reboot final de rigueur. Bon, pas super enchanté par la nouvelle mais pas non plus alarmé, ça m'arrive régulièrement sur mes home-servers. La différence majeure ici est que je ne peux pas juste "connecter une clé USB pour booter une Debian de rescue" pour corriger le bousin. La seule solution c'est de passer par la console KVM fournie.

Et là j'ai pu observer une petite différence qui a son importance entre Chalice et Shaddam, qui ne doivent pas être exactement de la même génération :

• Shaddam offre la possibilité de se connecter via une applet Java (bof) ou "via le navigateur" (moderne, rapide et efficace)

• Chalice de son côté n'a que l'applet Java 😕

Allez, tant pis, va pour l'applet Java. Je clique sur le bouton qui télécharge alors un fichier .jnlp. OK, je connais pas, mais ça doit pas être sorcier.

Je tente alors un bête java <monfichier>.jnlp. Hum non, ça ne marche pas. Je cherche un peu et apparemment il faut passer par javaws.

$ javaws <monfichier>.jnlp
selected jre: /usr/lib/jvm/default-runtime
Warning!, Fall back in resolve_jar to hardcoded paths: 
/usr/share/java/js.jar
WARNING: Unknown module: jdk.jsobject specified to --patch-module
WARNING: package sun.applet not in java.desktop
WARNING: package com.sun.net.ssl.internal.ssl not in java.base
WARNING: package sun.security.action not in java.base
WARNING: package jdk.internal.util.jar not in java.base
WARNING: package javax.jnlp not in java.desktop
java.security.NoSuchAlgorithmException: JavaPolicy Policy not available
    at java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:189)
    at java.base/java.security.Policy.getInstance(Policy.java:162)
    at net.sourceforge.jnlp.runtime.JNLPPolicy.getPolicyFromUrl(JNLPPolicy.java:200)
    at net.sourceforge.jnlp.runtime.JNLPPolicy.<init>(JNLPPolicy.java:64)
    at net.sourceforge.jnlp.runtime.JNLPRuntime.initialize(JNLPRuntime.java:261)
    at net.sourceforge.jnlp.runtime.Boot.init(Boot.java:353)
    at net.sourceforge.jnlp.runtime.JnlpBoot.run(JnlpBoot.java:58)
    at net.sourceforge.jnlp.runtime.Boot.run(Boot.java:274)
    at net.sourceforge.jnlp.runtime.Boot.run(Boot.java:63)
    at java.base/java.security.AccessController.doPrivileged(AccessController.java:74)
    at net.sourceforge.jnlp.runtime.Boot.main(Boot.java:214)

Mouais OK, c'est pas mieux mieux.

Il m'a fallu un peu plus de recherche pour apprendre qu'il faut absolument passer par le JRE 8 (qu'on installera au passage avec pacman -S jre8-openjdk sur Arch).

On précise ensuite le JRE à utiliser pour lancer la console comme ceci :

$ JAVA_HOME=/usr/lib/jvm/java-8-openjdk/ javaws <monfichier>.jnlp

Et là de suite, ça va mieux et l'interface de contrôle s'affiche. On peut voir l'écran et dépanner la bête comme si on était devant la machine (presque).

☝️ Deux informations complémentaires avant de finir :

1. le problème que j'avais était lié à GRUB qui s'était mal mis à jour. Il m'a donc fallu booter sur l'image rescue fournie (en Debian 12 mais pas grave), faire le petit chroot qui va bien puis update-grub && grub-install /dev/sda && grub-install /dev/sdb (je résume hein).
2. Le process de boot de ces machines peut être très lent, entre l'"appui sur le bouton power" (virtuel) et la disponibilité de SSH il faut parfois compter plusieurs minutes. Rien que pour arriver à GRUB j'ai compté presque 2 minutes parfois. Aucune idée si c'est normal ou non.