Gunther Oracle APEX und Datenbank Wiki

Ziel: Claude Code Projekt von WSL2/Windows auf Oracle Linux 9 VM migrieren

Bisher habe ich das Projekt: IHateWeblogic @ GitHub in Visual Code in einer WSL Umgebung durchgeführt und „git pull“ in die produktive Umgebung überführt, in der die Lib schon im Einsatz ist.

Nun soll aber auch das Installationsthema mit per Skript gelöst werden, dazu erstellen ich umfangreiche Dokumentation aus meinen bestehenden Unterlagen und den Blog Einträgen.

Auf Basis dieser Dokument und der exakten Aufgabenbeschreibung der Skripte im Prompt erstellt Claude Code die Skripte, ich testen diese dann wieder gegen über einer produktiven Umgebung.

Um hier das nun noch viel feingranularer zu entwickeln und um natürlich Fehler in produktiven Umgebungen zu vermeiden, ziehen wir jetzt alles auf ein Live System um, das aber über Snapshot Technik sich einfach sicher läßt und wir können immer wieder neu testen.

Das Entwickeln und Testen von Shell-Skripten unter WSL2 hat einen entscheidenden Nachteil: Das Zielsystem ist Oracle Linux 9.7 mit einer installierten Oracle Produkt Basis.

Skripte die im WSL2 laufen, können auf dem echten Zielsystem scheitern - Paketmanager, Pfade, SELinux-Policies und systemd-Verhalten unterscheiden sich zum Teil erheblich.

Daher lohnt es sich, das Projekt direkt auf einer Oracle Linux 9 VM weiterzuentwickeln. Diese Anleitung beschreibt den vollständigen Umzug:

1. Projekt von GitLab/GitHub auf die VM clonen
2. SSH-Keys korrekt einrichten (root vs. Oracle-Entwicklungsuser)
3. Claude Code Memory übertragen
4. Claude Code auf der VM installieren und aktivieren
5. VS Code Remote-SSH anbinden

Auf einem Oracle Linux Produktivsystem arbeitet man nicht dauerhaft als root.

Wir legen einen dedizierten Entwicklungsuser an - in diesem Beispiel oracle (passend zum Kontext der Oracle-Entwicklung).

Auf der VM als root einloggen:

ssh root@orafusion01.pipperr.local

Git

dnf install git

User anlegen und Sudo-Berechtigung vergeben:

# User anlegen
useradd -m -s /bin/bash oracle
 
# Passwort setzen
passwd oracle
 
# Sudo-Gruppe hinzufügen (wheel ist die sudo-Gruppe unter Oracle Linux / RHEL)
usermod -aG wheel oracle
 
# Prüfen
id oracle

Development Verzeichnis anlegen:

mkdir development
chown -R oracle:oinstall development/

Git-Konfiguration auf der VM einrichten wie git config –global user.name; user.email etc..

Globale Konfiguration erfolgt mit „git –system“, hier zum Beispiel um den Editor zu setzen und Farben zu verwenden: User root:

git config --system core.editor vi
git config --system color.ui true

User Konfiguration: User Oracle:

git config --global user.name "Gunther Pippèrr"
git config --global user.email "info @ pipperr.de"
 
#kein CRLF wandlung!
 
git config --global core.autocrlf false

Konfiguration (ließt über alle Konfigurationsdateien, letzter gefundener Wert wird verwendet) anzeigen:

#All
git config --list
 
#One Parameter 
git config core.editor

Das SSH-Key-Thema beim Umzug hat zwei Ebenen:

Für den Zugang zur VM (authorized_keys) reicht der öffentliche Schlüssel.
Für den Zugang zu GitLab/GitHub von der VM aus wird aber auch der private Schlüssel benötigt — der muss also mit auf die VM.

Da die VM eine persönliche Entwicklungsmaschine ist und derselbe Key bereits in GitLab hinterlegt ist, ist der einfachste und sauberste Weg: das komplette ~/.ssh-Verzeichnis aus WSL2 auf die VM kopieren.

1. Komplettes .ssh von WSL2 auf die VM kopieren

Zunächst per Passwort-Login (root) die initiale Verbindung herstellen, dann als oracle das .ssh übertragen:

# Im WSL2 Terminal — .ssh komplett auf die VM kopieren
scp -r ~/.ssh/ oracle@orafusion01.pipperr.local:~/

2. Rechte auf der VM korrigieren (zwingend — SSH verweigert Keys bei falschen Rechten):

ssh oracle@orafusion01.pipperr.local
 
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
chmod 600 ~/.ssh/config          # falls vorhanden
chmod 600 ~/.ssh/authorized_keys # falls vorhanden

3. authorized_keys für VM-Login sicherstellen

Das kopierte ~/.ssh enthält bereits den Public Key. Damit der Login auf die VM selbst funktioniert, muss der eigene Public Key auch in authorized_keys stehen:

# Auf der VM als oracle
cat ~/.ssh/id_ed25519.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Für root-Zugang (initiales Setup) denselben Public Key eintragen — als root auf der VM:

mkdir -p /root/.ssh
chmod 700 /root/.ssh
cat /home/oracle/.ssh/id_ed25519.pub >> /root/.ssh/authorized_keys
chmod 600 /root/.ssh/authorized_keys

4. SELinux-Kontext reparieren (Oracle Linux / RHEL spezifisch):

# Als oracle auf der VM
restorecon -Rv ~/.ssh/

5. ssh-agent einrichten (falls der Key eine Passphrase hat):

# In ~/.bashrc ergänzen
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

# Auf der VM als oracle — GitLab SSH-Verbindung prüfen
ssh -T git@github.com
# Erwartete Antwort: "Welcome to GitLab, @username!"

# Vom Windows/WSL2 aus testen
ssh oracle@orafusion01.pipperr.local

Einen SSH-Config-Eintrag in ~/.ssh/config (WSL2-Seite) anlegen erleichtert den täglichen Umgang:

Host orafusion01.pipperr.local
    HostName orafusion01.pipperr.local
    User oracle
    IdentityFile ~/.ssh/id_ed25519
    ServerAliveInterval 60

Danach reicht: ssh orafusion01.pipperr.local

Als oracle auf der VM einloggen:

ssh oracle@orafusion01.pipperr.local

Arbeitsverzeichnis anlegen und Projekt clonen:

# Entwicklungsverzeichnis bei Bedarf anlegen
mkdir -p ~/development
cd ~/development
 
# Projekt clonen (Public Repo über HTTPS - kein SSH-Key für GitHub nötig)
git clone https://github.com/gpipperr/IHateWeblogic.git
 
cd IHateWeblogic
ls -la

Lokale Einstellung und gitignores in das neue Projektverzeichnis kopieren: Auf der Windows WLS Umgebung

cd /development/IHateWeblogic
scp  -r .claude oracle@10.10.10.124:/development/IHateWeblogic/
scp  CLAUDE.md oracle@10.10.10.124:/development/IHateWeblogic/
 
# + weitere Dateien nicht nicht in das git gehört haben wie Projektdokumente

Claude Code speichert projektbezogenen Kontext in speziellen Dateien - das sogenannte Memory. Diese Dateien enthalten Informationen über das Projekt, Coding-Standards, wiederkehrende Aufgaben und Kontextwissen, das Claude zwischen Sessions beibehält.

Es gibt zwei Arten von Memory-Dateien:

Das Memory ist der „Kontext-Speicher“ von Claude Code. Wenn du auf der neuen VM ohne Memory anfängst, „weiß“ Claude Code nichts über:

• Deine Coding-Standards (PL/SQL Namenskonventionen, Shell-Script-Struktur)
• Die Projektstruktur und wiederkehrende Aufgaben
• Entscheidungen die du getroffen hast („wir nutzen openssl des3 -pbkdf2 für Passwörter“)
• Deine Skill-Dateien

Daher lohnt sich die Übertragung auf die neue VM unbedingt.

Im WSL2 (Windows-Seite) die Claude-Konfiguration sichern:

# Im WSL2 Terminal - Inhalt prüfen
ls -la ~/.claude/
# Tar-Archiv als Backup erstellen
tar czf ~/claude_memory_backup.tar.gz ~/.claude/

# das komplette Verzeichnis
scp -r ~/.claude/ oracle@orafusion01.pipperr.local:~/claude_config_backup/
# oder das tar
scp  ~/claude_memory_backup.tar.gz oracle@orafusion01.pipperr.local:~/
 
# Config
scp  .claude.json oracle@10.10.10.124:~/

Auf der VM als oracle entpacken:

# Backup entpacken — überschreibt ein eventuell bereits von Claude Code
# angelegtes ~/.claude/ — daher vorher prüfen ob schon etwas vorhanden ist
ls -la ~/.claude/ 2>/dev/null && echo "Verzeichnis existiert bereits!"
 
# Entpacken
tar xzf ~/claude_backup.tar.gz -C ~/
 
# Ergebnis prüfen
find ~/.claude/ -type f | sort

# Als oracle mit sudo
 
# Option A: NodeSource Repository (empfohlen für aktuelle Version)
curl -fsSL https://rpm.nodesource.com/setup_20.x | sudo bash -
sudo dnf install -y nodejs
 
# Version prüfen
node --version   # Sollte v20.x.x zeigen
npm --version

Wichtig: Niemals sudo npm install -g verwenden. Stattdessen npm auf ein lokales Verzeichnis konfigurieren:

# npm global prefix in Home-Verzeichnis legen
mkdir -p ~/.npm-global
npm config set prefix '~/.npm-global'
 
# PATH in .bashrc ergänzen
echo 'export PATH=~/.npm-global/bin:$PATH' >> ~/.bashrc
source ~/.bashrc

# npm-Installationsweg (bewährter Weg)
npm install -g @anthropic-ai/claude-code
 
# Installation prüfen
claude --version
 
# Systemcheck
claude doctor
 
─────────────────────────────────────────────────────────────────────
  Diagnostics
  └ Currently running: npm-global (2.1.71)
  └ Path: /usr/bin/node
  └ Invoked: /home/oracle/.npm-global/bin/claude
  └ Config install method: unknown
  └ Search: OK (vendor)
  Updates
  └ Auto-updates: enabled
  └ Update permissions: Yes
  └ Auto-update channel: latest
  └ Stable version: 2.1.58
  └ Latest version: 2.1.71
  Version Locks
  └ No active version locks
  Press Enter to continue…

Alternativ mit dem nativen Installer (kein Node.js nötig):

# Native Installation (neueste Methode)
curl -fsSL https://claude.ai/install.sh | bash

Durch die komplette Übernahmen des Memories war nun bei mir kein neues Login notwendig

Claude Code benötigt eine Authentifizierung gegen Anthropic. Es gibt zwei Wege:

# Claude Code starten - beim ersten Start wird Auth durchgeführt
cd ~/development/IHateWeblogic
claude

Claude Code öffnet einen Browser-Auth-Flow. Da die VM headless ist, funktioniert das direkt so nicht. Stattdessen:

# Authentifizierung mit API-Key (für headless Server)
export ANTHROPIC_API_KEY="sk-ant-..."
 
# Den Key dauerhaft in .bashrc ablegen
echo 'export ANTHROPIC_API_KEY="sk-ant-..."' >> ~/.bashrc
source ~/.bashrc

Ersten Start und Funktionstest:

cd /development/IHateWeblogic
claude
# Claude Code sollte starten und das Projekt-Memory (CLAUDE.md) einlesen

VS Code kann über das Remote-SSH Extension direkt auf der VM arbeiten - alle Dateien, das Terminal und der Debugger laufen dann auf der VM, nur die GUI läuft lokal auf Windows.

• VS Code auf Windows installiert
• Extension Remote - SSH installiert (ms-vscode-remote.remote-ssh)

Vom WSL Ordner \\wsl.localhost\OracleLinux_9_5\home\admin den .ssh nach C:\Users\<User> kopieren.

Hier ist bereits unser Schlüssel hinterlegt den wir zuvor schon ausgetauscht haben.

In der lokalen ~/.ssh/config (Windows: C:\Users\<User>\.ssh\config) den Eintrag ergänzen/prüfen:

Host orafusion01.pipperr.local
    HostName orafusion01.pipperr.local
    User oracle
    IdentityFile ~/.ssh/id_ed25519
    ServerAliveInterval 60

1. VS Code öffnen
2. F1 → Remote-SSH: Connect to Host…
3. orafusion01.pipperr.local auswählen
4. VS Code installiert automatisch den VS Code Server auf der VM
5. Projektverzeichnis öffnen: /home/oracle/development/IHateWeblogic

Wenn Claude Code als VS Code Extension genutzt wird, muss diese in der Remote-Umgebung installiert sein:

1. In VS Code (Remote-SSH Session): Extensions öffnen
2. Nach Claude Code suchen
3. Install in SSH: orafusion01.pipperr.local klicken

Lokal (WSL2 / Windows)          VM (Oracle Linux 9, User: oracle)
──────────────────────────       ──────────────────────────────────
~/.ssh/id_ed25519.pub        →   /home/oracle/.ssh/authorized_keys
~/.ssh/id_ed25519.pub        →   /root/.ssh/authorized_keys
~/.claude/CLAUDE.md          →   /home/oracle/.claude/CLAUDE.md
~/.claude/settings.json      →   /home/oracle/.claude/settings.json
(Projekt)/CLAUDE.md          →   via git clone (im Repo)
(Projekt)/CLAUDE.local.md    →   manuell kopieren (nicht im Git)

# Verbose-Modus für Diagnose
ssh -v oracle@orafusion01.pipperr.local
 
# Häufige Ursachen:
# - SELinux blockiert .ssh (restorecon -Rv ~/.ssh)
# - Falsche Rechte auf .ssh-Verzeichnis oder authorized_keys
# - sshd_config erlaubt keinen Public-Key-Auth
 
# SELinux-Kontext reparieren
restorecon -Rv ~/.ssh/

# Prüfen ob CLAUDE.md gelesen wird
ls -la ~/.claude/
ls -la ~/development/IHateWeblogic/CLAUDE.md
 
# Claude Code Debug-Ausgabe
claude --debug

# PATH-Problem - .bashrc neu laden
source ~/.bashrc
echo $PATH | grep npm
 
# Oder direkt ausführen
~/.npm-global/bin/claude --version

Dokumentation:

• https://docs.claude.com/en/docs/claude-code/overview
• https://code.visualstudio.com/docs/remote/ssh

Gitrepo des Projektes

• https://github.com/gpipperr/IHateWeblogic