Terminal Ops
Diagnose-Lage von SERVER: Kali-VM, Lab-Tools und Systemkennwerte — beim Laden dieser Seite gemessen
Was diese Seite kann — und was nicht
Diese Seite führt keinen Befehl aus. Es gibt auf HYPDB.ONE keinen HTTP-Endpunkt, der eine Shell öffnet, und es gab nie einen. Der frühere Text dieser Seite versprach „SSH, lokale Shell, sichere Diagnosebefehle und Dry-Run-Ausführung" — das war eine Behauptung ohne Codepfad dahinter.
Was hier tatsächlich passiert: Diese Seite fragt beim Laden sechs Endpunkte ab und zeigt den Status dieses Aufrufs. Alles andere auf der Seite — Kali-Werkzeugliste, Systemkennwerte, Netz-Knoten — wird aus derselben Messung gefüllt, nicht aus fest eingetragenen Zahlen.
Diagnose-Workflow
VM-Status, Werkzeugbestand und Systemkennwerte werden abgefragt, nicht angenommen.
Ein gestoppter VM liefert leere Felder. Leere ist ein Befund, kein Fehler der Abfrage.
kvm:false heisst: das BIOS lässt die Hardware-Virtualisierung nicht zu. Am Webroot nicht behebbar.
0 installierte Werkzeuge ist die Folge des gestoppten VM, kein Fehler im Katalog.
Was diese Seite nicht kann, steht oben. Das ist Teil der Diagnose.
Jede Zeile unten trägt ihren gemessenen HTTP-Status und die Messzeit.
Kali-Lab: gemessener Werkzeugbestand
Werkzeugliste wird geladen …
| Werkzeug | Kategorie | Paket | Installiert |
|---|---|---|---|
| wird geladen … | |||
Quelle: GET /kali-api/kali/tools — der Dienst liest die Liste live per dpkg-query aus der VM. Bei gestoppter VM ist das Ergebnis 0 von 48.
Live-Messung
Sechs Abrufe, ausgeführt beim Laden dieser Seite:
| Endpunkt | Status | Bedeutung |
|---|---|---|
| Messung läuft … | ||
Messzeit: –
Telefonie- und Agentenlage (live)
Zwei zusätzliche gemessene Quellen, die diese Seite bisher nicht zeigte. Beide werden beim Laden abgefragt; fällt eine aus, bleibt der Platzhalter mit dem Grund stehen.
| Agent | Zustand | Queue |
|---|---|---|
| wird geladen … | ||
Quellen: GET /twilio/api/status (Telefonie-Server, Port 8767) und GET /assets/data/agenten_status.json (statisch, alle 30 s vom Agenten-Worker geschrieben). Zugangsdaten werden nie ausgegeben — die Statusdatei führt nur Variablennamen.
Systemkennwerte
| Kennwert | Gemessener Wert |
|---|---|
| wird geladen … | |
Quelle: GET /api/status. Die uptime dort ist die Laufzeit des API-Prozesses, nicht die des Rechners.
Netz-Knoten
Netz-Knoten werden geladen …
Quelle: GET /api/topology. Namen und IP-Adressen liefert erst /api/tailscale — und das erst nach Anmeldung (HTTP 401).
Warum die Kali-VM gestoppt ist
kvm: false heisst: /dev/kvm fehlt. Die Hardware-Virtualisierung ist im BIOS nicht aktiviert (VT-x / VT-d). Solange das so ist, startet die VM nicht — unabhängig davon, was diese Seite anzeigt.
Das liegt ausserhalb des Webroots und ist daher nicht von hier aus behebbar. Nötig ist: VT-x im BIOS aktivieren, neu starten. Danach liefert /kali-api/kali/tools den echten Bestand statt 0.
Diagnose-Grenzen — Endpunkte, die nicht existieren
Diese Seite fragt nur ab, was der API-Dienst wirklich beantwortet. Endpunkte, die angefragt wurden und mit 404 geantwortet haben, sind hier bewusst nicht eingebaut — es gibt keinen Codepfad dahinter:
- POST /api/exec — Shell-Ausführung über HTTP: existiert nicht
- GET /api/logs — Log-Abruf über die API: existiert nicht (nur per journalctl auf dem Host)
- GET /api/cron — Cron-Job-Liste über die API: existiert nicht
- GET /api/agents — ohne gültiges Token: 401
Kein Endpunkt auf dieser Seite ist aus einem Kommentar, einem Gerätenamen oder einer Vermutung übernommen — jeder ist hier per HTTP gemessen.
Systembindung
Interne Seiten zur Lage: API-Server · Logs & Audit · Cron-Healthcheck · Automation-Workflows · Security & Auth
Status
Diese Seite ist im Paket enthalten und intern verlinkt.
Verbinde mit dem Backend …