Server · Container · Tunnel
Diese Seite beschreibt den Rechner, auf dem hypdb.one ausgeliefert wird. Alle Zahlen in der Live-Messung stammen aus dem Aufruf, den diese Seite selbst gerade ausgeführt hat. Feste Angaben sind als Festmessung mit Datum gekennzeichnet.
Live-Messung dieser Seite
Sieben Endpunkte, alle eben jetzt von diesem Browser aus abgefragt. Die dritte Spalte zeigt die Antwort, nicht das, was die Seite behauptet.
| ENDSPUNKT | HTTP | ANTWORT | BEWERTUNG |
|---|---|---|---|
| /health | … | … | … |
| /api/status | … | … | … |
| /api/stats | … | … | … |
| /api/tts/status | … | … | … |
| /api/topology | … | … | … |
| /api/tiers | … | … | … |
| /api/skills | … | … | … |
Messung läuft …
Docker läuft, ist aber über den Standardsocket nicht erreichbar
Festmessung vom 04.10.2026 auf dem Host. Diese Werte kann die Seite nicht selbst per HTTP nachmessen — sie stammen aus einer Shell-Messung und sind deshalb als Festmessung gekennzeichnet.
| PRÜFUNG | ERGEBNIS |
|---|---|
| Unit docker.service | active (running), seit 17:10:47, dockerd PID 2555 |
| Socket-Pfad laut daemon | /run/docker.sock — vorhanden, srw-rw---- root:docker |
| Socket, den die CLI sucht | /var/run/docker.sock — nicht vorhanden |
| Ursache | /var/run ist auf diesem System ein echtes Verzeichnis (Inode 1725533), kein symbolischer Link auf /run |
| Folge für docker ps | Fehlermeldung „Cannot connect to the Docker daemon" — obwohl der Daemon läuft |
| Umweg, der funktioniert | DOCKER_HOST=unix:///run/docker.sock docker ps |
| Container über diesen Umweg | 0 Container, 0 Images (gemessen) |
Damit ist auch die Aussage der Vorgängerversion dieser Seite — „Docker auf SERVER" als ruhiger Dauerzustand — irreführend. Richtig ist: der Daemon läuft, es läuft kein einziger Container, und die Standard-CLI findet ihn nicht. Compose liegt als Plugin vor (docker-compose → CLI-Plugin v2.26.1), eine Compose-Datei existiert im Webroot aber nicht.
CasaOS ist auf diesem Host nicht installiert
Der Name dieser Seite nennt CasaOS. Diese Festmessung vom 04.10.2026 stellt fest: es gibt auf SERVER keine CasaOS-Installation.
| Pfad / Befehl | Ergebnis |
|---|---|
| /opt/casaos | existiert nicht |
| /var/lib/casaos | existiert nicht |
| /DATA | existiert nicht |
| casaos / casaos-cli | nicht im Pfad |
| Container mit „casa" im Namen | 0 (auch mit DOCKER_HOST-Umweg) |
Was auf dem Host läuft, sind systemd-Dienste ohne Container: nginx, hypdb-auth, hypdb-restore, hypdb-cloudflared, ollama, hermes und jarvis-server. Die Bezeichnung „Server-jd / CasaOS" beschreibt also einen historischen Namen, nicht eine installierte Software.
nginx: die Unit und die Wirklichkeit widersprechen sich
Am 04.10.2026 ist die Website einmal komplett ausgefallen, weil drei nginx-Verzeichnisse fehlten (/var/lib/nginx mit dem Unterverzeichnis body, /var/cache/nginx, /var/log/nginx). Sie wurden neu angelegt, der Daemon gestartet — über sudo /usr/sbin/nginx statt über die Unit.
| Ebene | Zustand am 04.10.2026 |
|---|---|
| Port 7777 | LISTEN — die Website ist erreichbar |
| systemctl status nginx | failed — die Unit weiss nichts von der laufenden Instanz |
| Ursache der Abweichung | ein Start im unbeaufsichtigten Cron-Lauf umgeht die Unit |
Praktische Folge: nach einem Neustart des Rechners ist hypdb.one so lange offline, bis nginx von Hand gestartet wurde. Ein Neustart der Unit behebt beides.
Server · Live-Werte
| Host (aus API) | – |
| Version (aus API) | – |
| Modus | – |
| Sicherheitsstufe | – |
| API-Laufzeit | – |
| System-Skills | – |
| Produkt-Skills (nach Tarif) | – |
| Dienste aus /api/stats | – |
| Root-Partition | – |
| Last (1/5/15) | – |
| Agenten online | – |
| Sprachausgabe | – |
Tailnet-Knoten (Festmessung 04.10.2026)
Namen und Adressen sind hier fest eingetragen. Die API liefert diese Namen absichtlich nicht: /api/tailscale antwortet ohne Anmeldung mit 401, und /api/topology anonymisiert die Knoten. Ein Detailabgleich ist deshalb nur mit Anmeldung möglich.
| KNOTEN | ADRESSE | ART | ZUSTAND |
|---|---|---|---|
| word-jd-1 | 100.90.251.58 | linux | online — das ist SERVER selbst |
| ai | 100.94.227.72 | linux | online |
| iphone-15 | 100.91.165.70 | iOS | online |
| big-bear-tailscale-1 | 100.115.49.82 | linux | offline, zuletzt vor 73 Tagen |
| big-bear-tailscale | 100.113.254.34 | linux | offline, zuletzt vor 109 Tagen |
| mi-11 | 100.83.230.60 | android | offline, zuletzt vor 68 Tagen |
| server-jd-1 | 100.68.219.9 | linux | offline, zuletzt vor 72 Tagen |
| server-jd | 100.96.120.117 | linux | offline, zuletzt vor 39 Tagen |
| word-jd | 100.96.156.61 | linux | offline, zuletzt vor 58 Tagen |
| a36f4cb2000b | 100.98.146.124 | linux | offline, zuletzt vor 86 Tagen |
Vier Knoten sind online, sieben offline. server-jd ist nicht verschwunden, sondern offline — der Eintrag besteht weiter, es antwortet nur keiner mehr. Das ist ein Unterschied, der in Betriebsnotizen gern untergeht.
Lauschende Ports (Festmessung 04.10.2026)
| 22 | SSH |
| 7777 | nginx — hypdb.one und die gesamte API |
| 7788 / 7799 | hypdb-auth: Anmeldung und API-Zustand |
| 7801 | hypdb-restore |
| 8642 | Hermes api_server |
| 8767 | jarvis-server |
| 11434 | Ollama, nur lokal |
| 7920 | Auto-Content-System, nur lokal |
| 633 / 53 | nur lokal bzw. VLAN |
Die öffentliche Erreichbarkeit läuft über genau einen Weg: Cloudflare verbindet sich zu nginx auf 7777. Alles andere auf dieser Liste ist lokal.
Was auf SERVER nicht läuft
Damit die Lücken nicht wieder verschwinden, hier ausdrücklich:
| CasaOS | nicht installiert, kein Verzeichnis, kein Container |
| Docker-Container | 0 laufende, 0 Images |
| Compose-Stapel | keine Compose-Datei im Webroot |
| hypdb-one-scheduler | inactive (dead), Unit disabled, kein Logeintrag |
| Kali-VM | startet nicht, weil /dev/kvm fehlt (VT-x im BIOS) |