# jviewer – AMI JViewer unter Linux zum Laufen bringen

Startet den alten AMI JViewer (Java-Web-Start-KVM-Client, z.B. für Intel
S2600WTTR mit AMI BMC) unter einem aktuellen Linux, obwohl weder ein
passendes Java 8 noch eine funktionierende `javaws`/IcedTea-Web-Konfiguration
vorinstalliert sind.

Für einen kompletten Neubau ohne Java/IcedTea-Web-Altlasten siehe das parallel
laufende Projekt `jviewer2` (moderner Nachbau des KVM-Protokolls, in Arbeit).

## Ausgangslage / Warum das nötig ist

- BMC liefert eine alte `jviewer.jnlp` mit `<all-permissions/>` und
  `<nativelib>`-Einträgen, die von aktuellem Java-Web-Start/IcedTea-Web so
  nicht mehr akzeptiert werden
- BMC-Zertifikat ist alt und abgelaufen (RSA 1024, SHA1, abgelaufen seit 2016);
  TLS1.2 funktioniert, TLS1.0 nicht
- Auf aktuellen Distributionen gibt es kein passendes OpenJDK-8-Paket mehr
- `JViewer.jar` ist unsigniert, das Manifest deklariert aber
  `Permissions: all-permissions` — moderne IcedTea-Web-Versionen erzwingen
  dafür einen restriktiven Sandbox-Modus, der weder Sockets zum
  KVM-Redirection-Port (7578) noch das Laden der nativen CD/Floppy-Wrapper-
  Bibliotheken erlaubt

## Was das Script macht

`start-jviewer.sh` löst das automatisiert, ohne etwas am System zu verändern
(alles bleibt im Projektordner):

1. Lädt bei Bedarf ein eigenes **Temurin-Java-8-JDK** herunter (nicht nur
   JRE — `jarsigner`/`keytool` werden für Schritt 4 gebraucht) nach
   `java8/`, unabhängig von einer eventuell vorhandenen Systeminstallation
2. Nutzt das im System installierte `javaws` (Paket `icedtea-netx`), erzwingt
   aber über `JAVA_HOME`/`PATH` das eigene Java 8
3. Baut eine komplett isolierte IcedTea-Web-Umgebung unter `runtime-home/`
   (eigenes `XDG_CONFIG_HOME`/`XDG_CACHE_HOME`, eigene
   `deployment.properties`) — die System-IcedTea-Web-Konfiguration bleibt
   unangetastet
4. Patcht die JNLP minimal (`patch_jviewer.py`): nur `<nativelib>` wird zu
   `<jar>` umbenannt (inkompatibel mit angeforderten `all-permissions`,
   unabhängig von Signierung); `<security>`/`<all-permissions>` und
   `<codebase>` bleiben unverändert
5. Lässt `javaws` in einem ersten, absichtlich fehlschlagenden Lauf die
   Original-Jars von der BMC in den eigenen Cache laden
6. **Signiert die gecachten Jars selbst** mit einem einmalig erzeugten,
   selbstsignierten Zertifikat (`signing/jviewer.jks`) und trägt das
   Zertifikat automatisch in IcedTea-Webs Trusted-Certs-Store ein — dadurch
   bekommt die Anwendung reguläre `AllPermission` statt Sandbox, ohne dass
   ein Zertifikats-Dialog manuell bestätigt werden muss
7. Startet `javaws` ein zweites Mal mit `-Xoffline`, damit die gepatchten/
   signierten Cache-Dateien verwendet werden, statt erneut unsignierte
   Originale von der BMC zu laden

## Voraussetzungen

- Linux mit `bash`, `wget`, `unzip`
- Paket `icedtea-netx` installiert (liefert `javaws`):
  ```
  sudo apt install icedtea-netx
  ```
- Netzwerkzugriff zur BMC sowie zu `api.adoptium.net` (für den einmaligen
  Java-8-Download)

## Benutzung

```
./start-jviewer.sh -c jviewer.jnlp
```

Das Script ist pfadunabhängig — es kann aus einem beliebigen Ordner heraus
aufgerufen werden, solange `patch_jviewer.py` im selben Verzeichnis liegt.
Der Pfad zur `.jnlp`-Datei kann relativ (zum Skript-Ordner) oder absolut
angegeben werden.

Alle heruntergeladenen/erzeugten Daten landen im Skript-Ordner:

| Ordner/Datei | Inhalt |
|---|---|
| `java8/` | heruntergeladenes Temurin-JDK-8 |
| `runtime-home/` | isolierte IcedTea-Web-Config und -Cache |
| `signing/` | selbstsigniertes Schlüsselpaar (`jviewer.jks`) für die Jar-Signierung |
| `fixed-<name>.jnlp` | gepatchte JNLP, die tatsächlich gestartet wird |
| `jviewer-debug.log` | vollständiges `javaws`-Log des letzten (zweiten) Laufs |
| `jviewer-debug-pass1.log` | Log des ersten (Cache-Befüll-)Laufs |

`java8/` und `signing/` bleiben zwischen Läufen erhalten (kein erneuter
Download/keine neue Signatur nötig). `runtime-home/.cache` wird bei jedem
Lauf frisch geleert, `runtime-home/.config` bleibt erhalten (falls doch
einmal ein Zertifikats-Dialog manuell bestätigt werden muss, bleibt diese
Entscheidung über Neustarts hinweg erhalten).

## Troubleshooting

- **`javaws wurde nicht gefunden`**: `sudo apt install icedtea-netx`
- **`FEHLER: JNLP wurde NICHT gepatcht (nativelib noch vorhanden)`**: prüfen,
  ob `patch_jviewer.py` im selben Ordner wie `start-jviewer.sh` liegt und ob
  die JNLP-Datei tatsächlich `<nativelib>`-Tags enthält (Struktur kann sich
  je nach BMC-Firmware leicht unterscheiden)
- **`FEHLER: Nach Lauf 1 wurden keine Jars im Cache gefunden`**: BMC nicht
  erreichbar, oder TLS-Handshake schlägt fehl — `jviewer-debug-pass1.log`
  prüfen
- **Immer noch `access denied`/`SocketPermission`-Fehler im 2. Lauf**: prüfen,
  ob im Log `verified as SIGNED_OK` und `App already has trusted publisher:
  true` steht. Falls nicht, kann es sein, dass die verwendete IcedTea-Web-
  Version einen anderen Pfad/Passwort für den Trusted-Certs-Store erwartet
  als `runtime-home/.config/icedtea-web/security/trusted.certs` /
  `changeit` — in diesem Fall erscheint ein GUI-Dialog, in dem einmalig
  "diesem Zertifikat immer vertrauen" bestätigt werden muss; das bleibt dank
  Punkt oben danach dauerhaft erhalten

## Bekannte Einschränkungen

- Virtuelle Medien (CD/Floppy-Redirection über `com.ami.iusb.CDROMRedir`)
  wurden nicht gesondert getestet; der Kern-Anwendungsfall (Bildschirm/
  Tastatur/Maus per KVM) funktioniert
- Der zweite `javaws`-Lauf öffnet ein GUI-Fenster (Swing) — für den Einsatz
  ist also eine grafische Sitzung (lokal oder X11-Forwarding) nötig