root/claude_settings
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Rolling Documentation: Opportunistisches Host-Scanning hinzugefügt

Browse Source
This commit is contained in:
root
2026-01-28 16:26:29 +01:00
parent 3660683a73
commit 6826e36386
5 changed files with 524 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

155
CLAUDE.md
View File

@@ -466,6 +466,161 @@ Nach Abschluss der Dokumentationsarbeit, erstelle eine Vergleichstabelle:
**Dieser Prozess ist nicht optional.** Dokumentationsverlust durch unvollständige Arbeit ist inakzeptabel. **Dieser Prozess ist nicht optional.** Dokumentationsverlust durch unvollständige Arbeit ist inakzeptabel.
### Rolling Documentation: Opportunistisches Host-Scanning
**Prinzip:** Wenn du während deiner Arbeit Zugriff auf einen Host bekommst, führe einen VOLLSTÄNDIGEN Scan durch - nicht nur für die aktuelle Aufgabe.
#### Auslöser
- SSH-Zugriff auf einen Host
- Web-UI Zugriff (pfsense, NPM, etc.)
- API-Zugriff
#### Workflow bei Host-Zugriff
1. **Prüfe:** Existiert `infrastructure/hosts/[hostname].md`?
2. **Falls nein oder unvollständig:** Vollständigen Scan durchführen
3. **Dann erst:** Ursprüngliche Aufgabe erledigen
#### Scan-Checkliste nach Host-Typ
**Netzwerk-Geräte (pfsense, Router):**
- [ ] Interfaces (Name, IP, Netz)
- [ ] ALLE Firewall-Regeln (nicht nur relevante!)
- [ ] ALLE Aliases
- [ ] NAT-Regeln (Port-Forwards, Outbound)
- [ ] DHCP/DNS-Konfiguration
- [ ] System-Version
- [ ] **ABHÄNGIGKEITEN:** Welche Hosts/Dienste hängen von diesem Gerät ab?
**Linux-Server:**
- [ ] OS/Version
- [ ] Interfaces und IPs
- [ ] Laufende Dienste
- [ ] Docker-Container
- [ ] Offene Ports
- [ ] Wichtige Configs
- [ ] **ABHÄNGIGKEITEN:** Welche anderen Hosts braucht dieser Server? Wer braucht ihn?
**Windows-Server:**
- [ ] OS/Version
- [ ] Interfaces und IPs
- [ ] Dienste und geplante Tasks
- [ ] Installierte Rollen
- [ ] **ABHÄNGIGKEITEN:** Verbindungen zu anderen Systemen
#### PFLICHT: Abhängigkeiten dokumentieren
**Bei JEDEM Host-Scan müssen die Abhängigkeiten erfasst werden:**
| Frage | Dokumentieren in |
|-------|------------------|
| Welche Hosts/Dienste braucht dieser Host? | `hosts/[host].md` → Abschnitt "Abhängigkeiten" |
| Welche Hosts/Dienste hängen von diesem Host ab? | `hosts/[host].md` → Abschnitt "Abhängig von diesem Host" |
| Gibt es Abhängigkeitsketten? | `dependencies.md` → Mermaid-Diagramm |
**Ziel:** Anhand der Dokumentation muss erkennbar sein:
- Was passiert wenn Host X ausfällt?
- Welche Dienste sind von Änderungen an Host X betroffen?
- Welche Hosts müssen vor Host X gestartet werden?
**Beispiel Abhängigkeits-Dokumentation:**
```markdown
## Abhängigkeiten
Dieser Host benötigt:
- **srv-docker02** (10.10.10.81) - n8n Backend
- **srv-nu-dc01** (10.10.10.111) - DNS-Auflösung
## Abhängig von diesem Host
Folgende Dienste/Hosts sind von diesem Host abhängig:
- **flow.wvits.de** - Webhook-Zugang fällt aus wenn dieser Host down ist
- **n8n.vinos.de** - Interner Zugang über diesen NPM
## Impact bei Ausfall
| Ausfall-Szenario | Betroffene Dienste |
|------------------|-------------------|
| Komplett-Ausfall | flow.wvits.de, n8n.vinos.de, ... |
| Nur Port 443 | HTTPS-Zugriff auf alle proxied Dienste |
```
**dependencies.md aktualisieren:**
Nach jedem Host-Scan prüfen ob `infrastructure/dependencies.md` aktualisiert werden muss:
- Neue Abhängigkeitskette entdeckt? → Mermaid-Diagramm ergänzen
- Impact-Analyse hinzufügen
- Repo-Links aktualisieren
#### Beispiel
**Aufgabe:** Firewall-Regel für srv-revproxy01 prüfen
| Falsch | Richtig |
|--------|---------|
| Nur die eine Regel prüfen | Erst: Existiert hosts/gw-nu-dmz02.md? |
| Session beenden | Nein → Vollständigen Scan aller Regeln, Aliases, Interfaces |
| | Host-Datei erstellen |
| | Dann: Ursprüngliche Aufgabe |
#### Rekursive Host-Entdeckung (WICHTIG!)
**Wenn du bei einem Scan Referenzen zu anderen Hosts siehst, gehe AUTOMATISCH weiter:**
Entdeckungsquellen:
- Firewall-Regeln (Ziel-IPs, Aliases)
- NAT-Regeln (Forward-Ziele)
- DNS-Einträge
- Docker-Compose (externe Hosts)
- Konfigurationsdateien
- Log-Einträge
- Netzwerk-Verbindungen
**Workflow:**
```
Host A scannen
↓
Entdecke Referenz zu Host B (z.B. in Firewall-Regel)
↓
Kann ich Host B erreichen?
├─ JA → Host B scannen (rekursiv)
└─ NEIN → Host B in Entdeckungsliste aufnehmen
```
**Entdeckungsliste führen:**
Wenn ein Host nicht gescannt werden kann (kein Zugriff, keine Credentials, etc.):
```markdown
## Entdeckte aber nicht gescannte Hosts
| Host | IP | Entdeckt in | Grund für fehlenden Scan |
|------|----|-------------|-------------------------|
| srv-xyz01 | 10.10.10.99 | gw-nu-dmz02 Firewall-Regel | Kein SSH-Zugriff |
| db-server | 10.10.20.5 | docker-compose.yml | Credentials unbekannt |
```
**Der User muss dich NICHT auf jeden Host einzeln hinweisen!**
Du sollst selbstständig:
1. Referenzen zu anderen Hosts erkennen
2. Versuchen diese zu scannen
3. Falls nicht möglich: Dokumentieren was du entdeckt hast
4. Beim nächsten Mal nachfragen ob Zugriff jetzt möglich ist
#### Effizienz
Nutze parallele Agenten für umfangreiche Scans und rekursive Entdeckung.
#### Ausnahmen
- Zeitkritische Notfälle (erst fixen, dann dokumentieren)
- Explizite User-Anweisung nur aktuelle Aufgabe zu erledigen
- User sagt explizit "nicht weiter scannen"
### Skills-Referenz ### Skills-Referenz
| Skill | Zweck | | Skill | Zweck |

69
plans/eager-cooking-knuth.md Normal file
View File

@@ -0,0 +1,69 @@
# Plan: RDP Client Monitor-Auswahl verbessern
## Problem
Bei "2 Monitors" werden falsche Monitore ausgewählt (Links + Laptop statt Links + Mitte).
**Ursache**: Die Funktion `_get_best_monitor_selection()` sortiert Monitore nur nach X-Position. Bei gleicher X-Position (Laptop und Mittlerer Monitor sind beide bei X=1920) gewinnt die niedrigere Monitor-ID.
**Aktuelles Layout**:
```
Monitor [3]: X=0, Y=0 <- Links
Monitor [2]: X=1920, Y=0 <- Mitte oben
Monitor [0]: X=1920, Y=1080 <- Laptop (Primary, unten)
Monitor [1]: X=3840, Y=0 <- Rechts
```
## Loesung
Sortierung verbessern: Bei gleicher X-Position den Monitor mit niedrigerer Y-Position bevorzugen (Monitore oben vor Monitoren unten).
## Aenderungen
**Datei**: `rdp_client.py`
### 1. Y-Position parsen (Zeile ~410)
```python
# Aktuell:
x_pos = int(pos_part.split('+')[1])
monitor_info = (monitor_id, x_pos, is_primary)
# Neu:
pos_coords = pos_part.split('+')[1:] # ['1920', '1080']
x_pos = int(pos_coords[0])
y_pos = int(pos_coords[1]) if len(pos_coords) > 1 else 0
monitor_info = (monitor_id, x_pos, y_pos, is_primary)
```
### 2. Sortierung anpassen (Zeile ~417)
```python
# Aktuell:
monitors.sort(key=lambda x: x[1])
# Neu: Primaer nach X, sekundaer nach Y
monitors.sort(key=lambda m: (m[1], m[2]))
```
### 3. Log-Ausgabe anpassen (Zeile ~421)
```python
# Aktuell:
self.logger.info(f"Monitor layout detected: {[(m[0], m[1], 'primary' if m[2] else 'secondary') for m in monitors]}")
# Neu:
self.logger.info(f"Monitor layout detected: {[(m[0], m[1], m[2], 'primary' if m[3] else 'secondary') for m in monitors]}")
```
## Erwartetes Ergebnis
Nach der Aenderung bei "2 Monitors":
- Sortierung: [3](X=0), [2](X=1920,Y=0), [0](X=1920,Y=1080), [1](X=3840)
- Auswahl: "3,2" = Linker + Mittlerer Monitor
## Verifikation
1. `xfreerdp /monitor-list` ausfuehren, um Monitor-Layout zu pruefen
2. RDP-Verbindung mit "2 Monitors" testen
3. Log-Datei pruefen (`~/.config/rdp-client/rdp_client.log`)

33
plans/effervescent-meandering-pony.md Normal file
View File

@@ -0,0 +1,33 @@
# Plan: C:\Tasks ins Repo + Task erstellen + Commits
## Status
- Task `Webshop-Tracking\Remove-OldFiles.ps1` wurde gelöscht
- v4 XML liegt unter `C:\Temp\Remove-OldFiles-v4.ps1.xml`
- 43 Dateien (configs + task XMLs) gestaged
- User hat Passwort bereitgestellt
## Schritte
### 1. v4 Skript auf Server in richtigen Ordner verschieben
- Remove-OldFiles-v4.ps1 nach C:\skripte\ verschieben (wo auch Remove-OldFiles.ps1 liegt)
### 2. C:\Tasks vom Server ins Repo kopieren
- Kompletten Tasks-Ordner (PowerShell-Scripts) herunterladen
- In srv-job01 Repo unter `C_Tasks/` ablegen
### 3. Task mit v4 XML neu erstellen
- XML anpassen falls nötig (Pfad zum Skript)
- Task auf Server erstellen mit scheduler.bi Credentials
### 3. Task testen
- Manuell ausführen
- Log prüfen auf v4 Format
### 4. Git Commits
- Alle Änderungen committen
- Nach Gitea pushen
## Verifikation
- Task läuft mit v4 Script
- C:\Tasks im Repo dokumentiert
- Alles gepusht

78
plans/encapsulated-crunching-jellyfish.md Normal file
View File

@@ -0,0 +1,78 @@
# Plan: Home Assistant Repo Konsolidierung (via Remote Agent)
## Ziel
Zwei HA-Repos zusammenführen via Claude Remote Agent auf srvclawdbot01. Test des Remote Agent Systems.
## Ausgangslage
| Repo | URL | Status |
|------|-----|--------|
| `home_assistant` (neu) | `git@gitea.egonetix.de:Egonetix/home_assistant.git` | Ziel-Repo |
| `home-assistant` (alt) | `git@gitea.egonetix.de:Egonetix/home-assistant.git` | Zu migrieren & löschen |
## Ausführung via Remote Agent
**Agent-Server:** srvclawdbot01.egonetix.lan (10.0.0.61)
Der Task wird an den Remote Agent delegiert. Agent klont beide Repos von Gitea, vergleicht, merged und pusht.
## Task-Prompt für Remote Agent
```
Führe folgende Aufgaben aus:
1. Klone beide Repos in /tmp:
- git clone ssh://git@gitea.egonetix.de:222/Egonetix/home-assistant.git /tmp/ha-old
- git clone ssh://git@gitea.egonetix.de:222/Egonetix/home_assistant.git /tmp/ha-new
2. Vergleiche die Inhalte:
- Liste alle Dateien in beiden Repos
- Identifiziere Dateien die nur im alten Repo existieren
- Vergleiche gemeinsame Dateien auf Unterschiede
3. Erstelle einen Bericht:
- Welche Dateien sind unique im alten Repo?
- Welche Inhalte fehlen im neuen Repo?
- Git-Historie des alten Repos (Commits)
4. Räume auf:
- rm -rf /tmp/ha-old /tmp/ha-new
Gib einen strukturierten Report zurück.
```
## Voraussetzungen auf Remote Agent
- [ ] SSH-Key für Gitea muss auf srvclawdbot01 konfiguriert sein
- [ ] Git muss installiert sein
- [ ] known_hosts Eintrag für gitea.egonetix.de
**Prüfen vor Start:**
```bash
ssh root@10.0.0.61 "ssh -T git@gitea.egonetix.de -p 222"
```
## Schritte
### 1. Task an Remote Agent senden
- Prompt wie oben an srvclawdbot01 senden
- Warten auf Ergebnis
### 2. Ergebnis auswerten
- Report analysieren
- Entscheiden welche Inhalte migriert werden
### 3. Migration (lokal oder via Agent)
- Falls Inhalte zu migrieren: ins neue Repo übernehmen
- Commit & Push
### 4. Altes Repo löschen
- Via Gitea API oder Web-UI
## Verifikation
1. Remote Agent Task erfolgreich abgeschlossen
2. Report zeigt Unterschiede
3. Relevante Inhalte migriert
4. Altes Repo gelöscht

189
plans/partitioned-enchanting-mango.md Normal file
View File

@@ -0,0 +1,189 @@
# Plan: CLAUDE.md erweitern - Opportunistisches Host-Scanning
## Ziel
Neue Anweisung in `~/dotfiles/claude_settings/CLAUDE.md` aufnehmen: **Rolling Documentation durch opportunistisches Host-Scanning**
## Kontext
Bei der Arbeit an n8n/flow.wvits.de hatte ich SSH-Zugriff auf gw-nu-dmz02, habe aber nur die für die aktuelle Aufgabe relevanten Firewall-Regeln dokumentiert. Der User möchte, dass bei jedem Host-Zugriff ein vollständiger Scan erfolgt.
---
## Änderung
### Datei
`~/dotfiles/claude_settings/CLAUDE.md`
### Platzierung
Nach Zeile 467 (nach "Dokumentations-Verifikation (PFLICHT)" und vor "Skills-Referenz")
### Neuer Abschnitt
```markdown
### Rolling Documentation: Opportunistisches Host-Scanning
**Prinzip:** Wenn du während deiner Arbeit Zugriff auf einen Host bekommst, führe einen VOLLSTÄNDIGEN Scan durch - nicht nur für die aktuelle Aufgabe.
#### Auslöser
- SSH-Zugriff auf einen Host
- Web-UI Zugriff (pfsense, NPM, etc.)
- API-Zugriff
#### Workflow bei Host-Zugriff
1. **Prüfe:** Existiert `infrastructure/hosts/[hostname].md`?
2. **Falls nein oder unvollständig:** Vollständigen Scan durchführen
3. **Dann erst:** Ursprüngliche Aufgabe erledigen
#### Scan-Checkliste nach Host-Typ
**Netzwerk-Geräte (pfsense, Router):**
- [ ] Interfaces (Name, IP, Netz)
- [ ] ALLE Firewall-Regeln (nicht nur relevante!)
- [ ] ALLE Aliases
- [ ] NAT-Regeln (Port-Forwards, Outbound)
- [ ] DHCP/DNS-Konfiguration
- [ ] System-Version
- [ ] **ABHÄNGIGKEITEN:** Welche Hosts/Dienste hängen von diesem Gerät ab?
**Linux-Server:**
- [ ] OS/Version
- [ ] Interfaces und IPs
- [ ] Laufende Dienste
- [ ] Docker-Container
- [ ] Offene Ports
- [ ] Wichtige Configs
- [ ] **ABHÄNGIGKEITEN:** Welche anderen Hosts braucht dieser Server? Wer braucht ihn?
**Windows-Server:**
- [ ] OS/Version
- [ ] Interfaces und IPs
- [ ] Dienste und geplante Tasks
- [ ] Installierte Rollen
- [ ] **ABHÄNGIGKEITEN:** Verbindungen zu anderen Systemen
#### PFLICHT: Abhängigkeiten dokumentieren
**Bei JEDEM Host-Scan müssen die Abhängigkeiten erfasst werden:**
| Frage | Dokumentieren in |
|-------|------------------|
| Welche Hosts/Dienste braucht dieser Host? | `hosts/[host].md` → Abschnitt "Abhängigkeiten" |
| Welche Hosts/Dienste hängen von diesem Host ab? | `hosts/[host].md` → Abschnitt "Abhängig von diesem Host" |
| Gibt es Abhängigkeitsketten? | `dependencies.md` → Mermaid-Diagramm |
**Ziel:** Anhand der Dokumentation muss erkennbar sein:
- Was passiert wenn Host X ausfällt?
- Welche Dienste sind von Änderungen an Host X betroffen?
- Welche Hosts müssen vor Host X gestartet werden?
**Beispiel Abhängigkeits-Dokumentation:**
```markdown
## Abhängigkeiten
Dieser Host benötigt:
- **srv-docker02** (10.10.10.81) - n8n Backend
- **srv-nu-dc01** (10.10.10.111) - DNS-Auflösung
## Abhängig von diesem Host
Folgende Dienste/Hosts sind von diesem Host abhängig:
- **flow.wvits.de** - Webhook-Zugang fällt aus wenn dieser Host down ist
- **n8n.vinos.de** - Interner Zugang über diesen NPM
## Impact bei Ausfall
| Ausfall-Szenario | Betroffene Dienste |
|------------------|-------------------|
| Komplett-Ausfall | flow.wvits.de, n8n.vinos.de, ... |
| Nur Port 443 | HTTPS-Zugriff auf alle proxied Dienste |
```
**dependencies.md aktualisieren:**
Nach jedem Host-Scan prüfen ob `infrastructure/dependencies.md` aktualisiert werden muss:
- Neue Abhängigkeitskette entdeckt? → Mermaid-Diagramm ergänzen
- Impact-Analyse hinzufügen
- Repo-Links aktualisieren
#### Beispiel
**Aufgabe:** Firewall-Regel für srv-revproxy01 prüfen
| Falsch | Richtig |
|--------|---------|
| Nur die eine Regel prüfen | Erst: Existiert hosts/gw-nu-dmz02.md? |
| Session beenden | Nein → Vollständigen Scan aller Regeln, Aliases, Interfaces |
| | Host-Datei erstellen |
| | Dann: Ursprüngliche Aufgabe |
#### Rekursive Host-Entdeckung (WICHTIG!)
**Wenn du bei einem Scan Referenzen zu anderen Hosts siehst, gehe AUTOMATISCH weiter:**
Entdeckungsquellen:
- Firewall-Regeln (Ziel-IPs, Aliases)
- NAT-Regeln (Forward-Ziele)
- DNS-Einträge
- Docker-Compose (externe Hosts)
- Konfigurationsdateien
- Log-Einträge
- Netzwerk-Verbindungen
**Workflow:**
```
Host A scannen
↓
Entdecke Referenz zu Host B (z.B. in Firewall-Regel)
↓
Kann ich Host B erreichen?
├─ JA → Host B scannen (rekursiv)
└─ NEIN → Host B in Entdeckungsliste aufnehmen
```
**Entdeckungsliste führen:**
Wenn ein Host nicht gescannt werden kann (kein Zugriff, keine Credentials, etc.):
```markdown
## Entdeckte aber nicht gescannte Hosts
| Host | IP | Entdeckt in | Grund für fehlenden Scan |
|------|----|-------------|-------------------------|
| srv-xyz01 | 10.10.10.99 | gw-nu-dmz02 Firewall-Regel | Kein SSH-Zugriff |
| db-server | 10.10.20.5 | docker-compose.yml | Credentials unbekannt |
```
**Der User muss dich NICHT auf jeden Host einzeln hinweisen!**
Du sollst selbstständig:
1. Referenzen zu anderen Hosts erkennen
2. Versuchen diese zu scannen
3. Falls nicht möglich: Dokumentieren was du entdeckt hast
4. Beim nächsten Mal nachfragen ob Zugriff jetzt möglich ist
#### Effizienz
Nutze parallele Agenten für umfangreiche Scans und rekursive Entdeckung.
#### Ausnahmen
- Zeitkritische Notfälle (erst fixen, dann dokumentieren)
- Explizite User-Anweisung nur aktuelle Aufgabe zu erledigen
- User sagt explizit "nicht weiter scannen"
```
---
## Verifikation
1. CLAUDE.md editieren
2. Abschnitt an korrekter Stelle eingefügt prüfen
3. `cd ~/dotfiles/claude_settings && git add -A && git commit -m "Rolling Documentation: Opportunistisches Host-Scanning hinzugefügt" && git push origin main`
4. `git status` zeigt clean