Compare commits
2 Commits
3f95a7adf3
...
07b595c45a
| Author | SHA1 | Date | |
|---|---|---|---|
| 07b595c45a | |||
| 724cfd9a98 |
20
CLAUDE.md
20
CLAUDE.md
@@ -12,15 +12,17 @@ DNS/DHCP-Ablösung, WLAN via **CAPsMAN auf dem Core** (TP28, 2026-08-17 — der
|
|||||||
4. ✅ **TP16.3 §5 durch (2026-09-01):** [`docs/handoff-20260901-tp16.3-paragraph5-flip-durch.md`](docs/handoff-20260901-tp16.3-paragraph5-flip-durch.md)
|
4. ✅ **TP16.3 §5 durch (2026-09-01):** [`docs/handoff-20260901-tp16.3-paragraph5-flip-durch.md`](docs/handoff-20260901-tp16.3-paragraph5-flip-durch.md)
|
||||||
— alle vier oeffentlichen Namen laufen ueber `bf-public`/Caddy; Alttunnel bleiben als Rueckfallebene
|
— alle vier oeffentlichen Namen laufen ueber `bf-public`/Caddy; Alttunnel bleiben als Rueckfallebene
|
||||||
(§6 offen). Enthaelt den 10-Sekunden-DNS-Fund und drei Messfallen.
|
(§6 offen). Enthaelt den 10-Sekunden-DNS-Fund und drei Messfallen.
|
||||||
4. 🔴 **WLAN/Fund E — HEBEL 1 GESCHEITERT + TP27 durchgezogen:**
|
5. 🔴 **WLAN/Fund E — HEBEL 1 WIDERLEGT UND ZURUECKGEBAUT, Messung laeuft:**
|
||||||
[`docs/handoff-20260831-tp27-upgrade-und-hebel1-befund.md`](docs/handoff-20260831-tp27-upgrade-und-hebel1-befund.md)
|
[`docs/handoff-20260901-fund-e-hebel1-zurueckgebaut.md`](docs/handoff-20260901-fund-e-hebel1-zurueckgebaut.md)
|
||||||
— `ft-over-ds=no` hat **nicht** gegriffen (124 `reauthenticating` nach dem Eingriff, zwei erlebte
|
— `ft-over-ds=no` lief 6,4 h **allein** und brachte 124 `reauthenticating` + zwei erlebte
|
||||||
Ausfälle um 13:16 und 14:23). Transaktion `TP25-fund-e-ft-over-ds` **bleibt offen**, **Compliance
|
Ausfaelle; der Einbruch auf 0/h faellt exakt auf das **TP27-Upgrade (7.24.1)** um 14:36.
|
||||||
steht weiter absichtlich auf 134/135**. Nächste Entscheidung: Hebel 2 (`ft=no`) **oder**
|
Hebel 1 ist am **2026-09-01** zurueckgebaut (`ft-over-ds=yes`), Transaktion **geschlossen**,
|
||||||
`wpa2-psk,wpa3-psk` — vorher prüfen, ob 7.24.1 das Verhalten schon verändert hat.
|
**Compliance 140/140**. ⏳ **Offene Aufgabe: eine Messung am 2026-09-02 frueh** — bleibt es
|
||||||
Vorstufen: [Eingriff](docs/handoff-20260831-fund-e-hebel1-gezogen.md) · [Befund](docs/handoff-20260831-wlan-fund-e.md).
|
ruhig, war 7.24.1 die Ursache. Vorstufen:
|
||||||
5. ap3-Bring-up 2026-08-30: [`docs/handoff-20260830-ap3.md`](docs/handoff-20260830-ap3.md) — sechs Funde zu Werks-MikroTiks, CAPsMAN und Golden-Config-Lücken.
|
[Befund](docs/handoff-20260831-tp27-upgrade-und-hebel1-befund.md) ·
|
||||||
6. Inventur-Befund 2026-08-27: [`docs/handoff-20260827-inventur-und-architektur.md`](docs/handoff-20260827-inventur-und-architektur.md) — Master-Struktur, Asymmetrie, Drift.
|
[Eingriff](docs/handoff-20260831-fund-e-hebel1-gezogen.md).
|
||||||
|
6. ap3-Bring-up 2026-08-30: [`docs/handoff-20260830-ap3.md`](docs/handoff-20260830-ap3.md) — sechs Funde zu Werks-MikroTiks, CAPsMAN und Golden-Config-Lücken.
|
||||||
|
7. Inventur-Befund 2026-08-27: [`docs/handoff-20260827-inventur-und-architektur.md`](docs/handoff-20260827-inventur-und-architektur.md) — Master-Struktur, Asymmetrie, Drift.
|
||||||
|
|
||||||
## Was du sofort wissen musst (Inventur 2026-08-27)
|
## Was du sofort wissen musst (Inventur 2026-08-27)
|
||||||
|
|
||||||
|
|||||||
@@ -0,0 +1,85 @@
|
|||||||
|
{
|
||||||
|
"result": [
|
||||||
|
{
|
||||||
|
"created_at": "2026-02-28T21:26:56Z",
|
||||||
|
"decision": "allow",
|
||||||
|
"exclude": [],
|
||||||
|
"id": "8e44f5d1-8257-443e-a797-b3de939952ee",
|
||||||
|
"include": [
|
||||||
|
{
|
||||||
|
"email": {
|
||||||
|
"email": "christoph@emsenhuber.com"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"login_method": {
|
||||||
|
"id": "72c1291b-a38d-4bc7-af97-5dee04a4f84a"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"login_method": {
|
||||||
|
"id": "9024c7a6-2d1f-4432-9f48-51593acd1361"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"name": "christoph",
|
||||||
|
"require": [],
|
||||||
|
"connection_rules": {
|
||||||
|
"rdp": {}
|
||||||
|
},
|
||||||
|
"session_duration": "730h",
|
||||||
|
"uid": "8e44f5d1-8257-443e-a797-b3de939952ee",
|
||||||
|
"updated_at": "2026-07-31T07:27:41Z",
|
||||||
|
"reusable": true,
|
||||||
|
"precedence": 1
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"created_at": "2026-05-09T06:45:22Z",
|
||||||
|
"decision": "non_identity",
|
||||||
|
"exclude": [],
|
||||||
|
"id": "5165d139-8733-4d31-a3a5-f6f1d0fd8643",
|
||||||
|
"include": [
|
||||||
|
{
|
||||||
|
"ip": {
|
||||||
|
"ip": "90.146.33.177/32"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"name": "bf4",
|
||||||
|
"require": [],
|
||||||
|
"uid": "5165d139-8733-4d31-a3a5-f6f1d0fd8643",
|
||||||
|
"updated_at": "2026-08-07T21:36:42Z",
|
||||||
|
"reusable": true,
|
||||||
|
"precedence": 2
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"created_at": "2026-05-15T13:11:36Z",
|
||||||
|
"decision": "non_identity",
|
||||||
|
"exclude": [],
|
||||||
|
"id": "39fe0e9d-6f63-414d-9d6d-440a7a151f5d",
|
||||||
|
"include": [
|
||||||
|
{
|
||||||
|
"service_token": {
|
||||||
|
"token_id": "65f1821a-f134-4e20-aa66-baf31daddbed"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"name": "claude-mcp",
|
||||||
|
"require": [],
|
||||||
|
"uid": "39fe0e9d-6f63-414d-9d6d-440a7a151f5d",
|
||||||
|
"updated_at": "2026-07-31T15:44:48Z",
|
||||||
|
"reusable": true,
|
||||||
|
"precedence": 3
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"success": true,
|
||||||
|
"errors": [],
|
||||||
|
"messages": [],
|
||||||
|
"result_info": {
|
||||||
|
"page": 1,
|
||||||
|
"per_page": 200,
|
||||||
|
"count": 3,
|
||||||
|
"total_count": 3,
|
||||||
|
"total_pages": 1
|
||||||
|
}
|
||||||
|
}
|
||||||
@@ -0,0 +1,116 @@
|
|||||||
|
{
|
||||||
|
"result": {
|
||||||
|
"id": "16aaec78-5951-4cf3-aad5-79f63163b5ea",
|
||||||
|
"uid": "16aaec78-5951-4cf3-aad5-79f63163b5ea",
|
||||||
|
"type": "self_hosted",
|
||||||
|
"name": "*.emsenhuber.net",
|
||||||
|
"aud": "d5bb8c4852895834a0010d6f63882f140cf27faf41f94374532c1f013a15c02d",
|
||||||
|
"created_at": "2026-05-05T11:44:38Z",
|
||||||
|
"updated_at": "2026-05-15T13:30:13Z",
|
||||||
|
"domain": "*.emsenhuber.net",
|
||||||
|
"self_hosted_domains": [
|
||||||
|
"*.emsenhuber.net"
|
||||||
|
],
|
||||||
|
"destinations": [
|
||||||
|
{
|
||||||
|
"type": "public",
|
||||||
|
"uri": "*.emsenhuber.net"
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"app_launcher_visible": true,
|
||||||
|
"allowed_idps": [],
|
||||||
|
"tags": [],
|
||||||
|
"auto_redirect_to_identity": false,
|
||||||
|
"policies": [
|
||||||
|
{
|
||||||
|
"created_at": "2026-02-28T21:26:56Z",
|
||||||
|
"decision": "allow",
|
||||||
|
"exclude": [],
|
||||||
|
"id": "8e44f5d1-8257-443e-a797-b3de939952ee",
|
||||||
|
"include": [
|
||||||
|
{
|
||||||
|
"email": {
|
||||||
|
"email": "christoph@emsenhuber.com"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"login_method": {
|
||||||
|
"id": "72c1291b-a38d-4bc7-af97-5dee04a4f84a"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"login_method": {
|
||||||
|
"id": "9024c7a6-2d1f-4432-9f48-51593acd1361"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"name": "christoph",
|
||||||
|
"require": [],
|
||||||
|
"connection_rules": {
|
||||||
|
"rdp": {}
|
||||||
|
},
|
||||||
|
"session_duration": "730h",
|
||||||
|
"uid": "8e44f5d1-8257-443e-a797-b3de939952ee",
|
||||||
|
"updated_at": "2026-07-31T07:27:41Z",
|
||||||
|
"reusable": true,
|
||||||
|
"precedence": 1
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"created_at": "2026-05-09T06:45:22Z",
|
||||||
|
"decision": "non_identity",
|
||||||
|
"exclude": [],
|
||||||
|
"id": "5165d139-8733-4d31-a3a5-f6f1d0fd8643",
|
||||||
|
"include": [
|
||||||
|
{
|
||||||
|
"ip": {
|
||||||
|
"ip": "90.146.33.177/32"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"name": "bf4",
|
||||||
|
"require": [],
|
||||||
|
"uid": "5165d139-8733-4d31-a3a5-f6f1d0fd8643",
|
||||||
|
"updated_at": "2026-08-07T21:36:42Z",
|
||||||
|
"reusable": true,
|
||||||
|
"precedence": 2
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"created_at": "2026-05-15T13:11:36Z",
|
||||||
|
"decision": "non_identity",
|
||||||
|
"exclude": [],
|
||||||
|
"id": "39fe0e9d-6f63-414d-9d6d-440a7a151f5d",
|
||||||
|
"include": [
|
||||||
|
{
|
||||||
|
"service_token": {
|
||||||
|
"token_id": "65f1821a-f134-4e20-aa66-baf31daddbed"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"name": "claude-mcp",
|
||||||
|
"require": [],
|
||||||
|
"uid": "39fe0e9d-6f63-414d-9d6d-440a7a151f5d",
|
||||||
|
"updated_at": "2026-07-31T15:44:48Z",
|
||||||
|
"reusable": true,
|
||||||
|
"precedence": 3
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"session_duration": "24h",
|
||||||
|
"enable_binding_cookie": false,
|
||||||
|
"http_only_cookie_attribute": false,
|
||||||
|
"options_preflight_bypass": false,
|
||||||
|
"oauth_configuration": {
|
||||||
|
"enabled": false,
|
||||||
|
"dynamic_client_registration": {
|
||||||
|
"enabled": true,
|
||||||
|
"allowed_uris": [
|
||||||
|
"https://ha-mcp.emsenhuber.net"
|
||||||
|
],
|
||||||
|
"allow_any_on_localhost": true,
|
||||||
|
"allow_any_on_loopback": true
|
||||||
|
}
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"success": true,
|
||||||
|
"errors": [],
|
||||||
|
"messages": []
|
||||||
|
}
|
||||||
@@ -0,0 +1,34 @@
|
|||||||
|
{
|
||||||
|
"result": [
|
||||||
|
{
|
||||||
|
"created_at": "2026-06-13T08:34:00Z",
|
||||||
|
"decision": "bypass",
|
||||||
|
"exclude": [],
|
||||||
|
"id": "a8129e37-d3c2-456d-8630-3c6a3449d3f2",
|
||||||
|
"include": [
|
||||||
|
{
|
||||||
|
"everyone": {}
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"name": "bypass",
|
||||||
|
"require": [],
|
||||||
|
"connection_rules": {
|
||||||
|
"rdp": {}
|
||||||
|
},
|
||||||
|
"uid": "a8129e37-d3c2-456d-8630-3c6a3449d3f2",
|
||||||
|
"updated_at": "2026-06-13T08:48:05Z",
|
||||||
|
"reusable": true,
|
||||||
|
"precedence": 1
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"success": true,
|
||||||
|
"errors": [],
|
||||||
|
"messages": [],
|
||||||
|
"result_info": {
|
||||||
|
"page": 1,
|
||||||
|
"per_page": 200,
|
||||||
|
"count": 1,
|
||||||
|
"total_count": 1,
|
||||||
|
"total_pages": 1
|
||||||
|
}
|
||||||
|
}
|
||||||
@@ -0,0 +1,64 @@
|
|||||||
|
{
|
||||||
|
"result": {
|
||||||
|
"id": "1dbc45ca-1376-4a0d-b608-69db58f1875c",
|
||||||
|
"uid": "1dbc45ca-1376-4a0d-b608-69db58f1875c",
|
||||||
|
"type": "self_hosted",
|
||||||
|
"name": "hass, vw, gitea",
|
||||||
|
"aud": "817b2b82d2b1aa9c12de854c7bce9f608b33721f0827cfded68bdc7c5eb92a46",
|
||||||
|
"created_at": "2026-06-13T08:32:39Z",
|
||||||
|
"updated_at": "2026-07-12T12:43:25Z",
|
||||||
|
"domain": "vw.emsenhuber.net",
|
||||||
|
"self_hosted_domains": [
|
||||||
|
"vw.emsenhuber.net",
|
||||||
|
"hass.emsenhuber.net",
|
||||||
|
"gitea.emsenhuber.net"
|
||||||
|
],
|
||||||
|
"destinations": [
|
||||||
|
{
|
||||||
|
"type": "public",
|
||||||
|
"uri": "vw.emsenhuber.net"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"type": "public",
|
||||||
|
"uri": "hass.emsenhuber.net"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"type": "public",
|
||||||
|
"uri": "gitea.emsenhuber.net"
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"app_launcher_visible": true,
|
||||||
|
"allowed_idps": [],
|
||||||
|
"tags": [],
|
||||||
|
"auto_redirect_to_identity": false,
|
||||||
|
"policies": [
|
||||||
|
{
|
||||||
|
"created_at": "2026-06-13T08:34:00Z",
|
||||||
|
"decision": "bypass",
|
||||||
|
"exclude": [],
|
||||||
|
"id": "a8129e37-d3c2-456d-8630-3c6a3449d3f2",
|
||||||
|
"include": [
|
||||||
|
{
|
||||||
|
"everyone": {}
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"name": "bypass",
|
||||||
|
"require": [],
|
||||||
|
"connection_rules": {
|
||||||
|
"rdp": {}
|
||||||
|
},
|
||||||
|
"uid": "a8129e37-d3c2-456d-8630-3c6a3449d3f2",
|
||||||
|
"updated_at": "2026-06-13T08:48:05Z",
|
||||||
|
"reusable": true,
|
||||||
|
"precedence": 1
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"session_duration": "24h",
|
||||||
|
"enable_binding_cookie": false,
|
||||||
|
"http_only_cookie_attribute": true,
|
||||||
|
"options_preflight_bypass": false
|
||||||
|
},
|
||||||
|
"success": true,
|
||||||
|
"errors": [],
|
||||||
|
"messages": []
|
||||||
|
}
|
||||||
@@ -0,0 +1,47 @@
|
|||||||
|
{
|
||||||
|
"result": [
|
||||||
|
{
|
||||||
|
"created_at": "2026-02-28T21:26:56Z",
|
||||||
|
"decision": "allow",
|
||||||
|
"exclude": [],
|
||||||
|
"id": "8e44f5d1-8257-443e-a797-b3de939952ee",
|
||||||
|
"include": [
|
||||||
|
{
|
||||||
|
"email": {
|
||||||
|
"email": "christoph@emsenhuber.com"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"login_method": {
|
||||||
|
"id": "72c1291b-a38d-4bc7-af97-5dee04a4f84a"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"login_method": {
|
||||||
|
"id": "9024c7a6-2d1f-4432-9f48-51593acd1361"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"name": "christoph",
|
||||||
|
"require": [],
|
||||||
|
"connection_rules": {
|
||||||
|
"rdp": {}
|
||||||
|
},
|
||||||
|
"session_duration": "730h",
|
||||||
|
"uid": "8e44f5d1-8257-443e-a797-b3de939952ee",
|
||||||
|
"updated_at": "2026-07-31T07:27:41Z",
|
||||||
|
"reusable": true,
|
||||||
|
"precedence": 1
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"success": true,
|
||||||
|
"errors": [],
|
||||||
|
"messages": [],
|
||||||
|
"result_info": {
|
||||||
|
"page": 1,
|
||||||
|
"per_page": 200,
|
||||||
|
"count": 1,
|
||||||
|
"total_count": 1,
|
||||||
|
"total_pages": 1
|
||||||
|
}
|
||||||
|
}
|
||||||
@@ -0,0 +1,54 @@
|
|||||||
|
{
|
||||||
|
"result": {
|
||||||
|
"id": "6c32fe23-24d8-433f-b00b-0a3d1558bb30",
|
||||||
|
"uid": "6c32fe23-24d8-433f-b00b-0a3d1558bb30",
|
||||||
|
"type": "warp",
|
||||||
|
"name": "Warp Login App",
|
||||||
|
"aud": "fdfaa967d4118469dc994257f65831caa0162d6c45a14b5205af45e1aeca723b",
|
||||||
|
"created_at": "2026-06-04T18:48:59Z",
|
||||||
|
"updated_at": "2026-06-06T16:53:32Z",
|
||||||
|
"domain": "emsenhuber.cloudflareaccess.com/warp",
|
||||||
|
"allowed_idps": [],
|
||||||
|
"session_duration": "24h",
|
||||||
|
"auto_redirect_to_identity": false,
|
||||||
|
"policies": [
|
||||||
|
{
|
||||||
|
"created_at": "2026-02-28T21:26:56Z",
|
||||||
|
"decision": "allow",
|
||||||
|
"exclude": [],
|
||||||
|
"id": "8e44f5d1-8257-443e-a797-b3de939952ee",
|
||||||
|
"include": [
|
||||||
|
{
|
||||||
|
"email": {
|
||||||
|
"email": "christoph@emsenhuber.com"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"login_method": {
|
||||||
|
"id": "72c1291b-a38d-4bc7-af97-5dee04a4f84a"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"login_method": {
|
||||||
|
"id": "9024c7a6-2d1f-4432-9f48-51593acd1361"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"name": "christoph",
|
||||||
|
"require": [],
|
||||||
|
"connection_rules": {
|
||||||
|
"rdp": {}
|
||||||
|
},
|
||||||
|
"session_duration": "730h",
|
||||||
|
"uid": "8e44f5d1-8257-443e-a797-b3de939952ee",
|
||||||
|
"updated_at": "2026-07-31T07:27:41Z",
|
||||||
|
"reusable": true,
|
||||||
|
"precedence": 1
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"tags": []
|
||||||
|
},
|
||||||
|
"success": true,
|
||||||
|
"errors": [],
|
||||||
|
"messages": []
|
||||||
|
}
|
||||||
@@ -0,0 +1,47 @@
|
|||||||
|
{
|
||||||
|
"result": [
|
||||||
|
{
|
||||||
|
"created_at": "2026-02-28T21:26:56Z",
|
||||||
|
"decision": "allow",
|
||||||
|
"exclude": [],
|
||||||
|
"id": "8e44f5d1-8257-443e-a797-b3de939952ee",
|
||||||
|
"include": [
|
||||||
|
{
|
||||||
|
"email": {
|
||||||
|
"email": "christoph@emsenhuber.com"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"login_method": {
|
||||||
|
"id": "72c1291b-a38d-4bc7-af97-5dee04a4f84a"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"login_method": {
|
||||||
|
"id": "9024c7a6-2d1f-4432-9f48-51593acd1361"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"name": "christoph",
|
||||||
|
"require": [],
|
||||||
|
"connection_rules": {
|
||||||
|
"rdp": {}
|
||||||
|
},
|
||||||
|
"session_duration": "730h",
|
||||||
|
"uid": "8e44f5d1-8257-443e-a797-b3de939952ee",
|
||||||
|
"updated_at": "2026-07-31T07:27:41Z",
|
||||||
|
"reusable": true,
|
||||||
|
"precedence": 1
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"success": true,
|
||||||
|
"errors": [],
|
||||||
|
"messages": [],
|
||||||
|
"result_info": {
|
||||||
|
"page": 1,
|
||||||
|
"per_page": 200,
|
||||||
|
"count": 1,
|
||||||
|
"total_count": 1,
|
||||||
|
"total_pages": 1
|
||||||
|
}
|
||||||
|
}
|
||||||
@@ -0,0 +1,55 @@
|
|||||||
|
{
|
||||||
|
"result": {
|
||||||
|
"id": "6df5c431-adcf-4dde-805d-4eb22d7c19b4",
|
||||||
|
"uid": "6df5c431-adcf-4dde-805d-4eb22d7c19b4",
|
||||||
|
"type": "app_launcher",
|
||||||
|
"name": "App Launcher",
|
||||||
|
"aud": "015e805251579e50a49668775c2255facb5bc56007ce49f90885f4114584bae2",
|
||||||
|
"created_at": "2026-03-28T16:20:27Z",
|
||||||
|
"updated_at": "2026-07-08T11:56:56Z",
|
||||||
|
"domain": "emsenhuber.cloudflareaccess.com",
|
||||||
|
"allowed_idps": [],
|
||||||
|
"session_duration": "730h",
|
||||||
|
"auto_redirect_to_identity": false,
|
||||||
|
"policies": [
|
||||||
|
{
|
||||||
|
"created_at": "2026-02-28T21:26:56Z",
|
||||||
|
"decision": "allow",
|
||||||
|
"exclude": [],
|
||||||
|
"id": "8e44f5d1-8257-443e-a797-b3de939952ee",
|
||||||
|
"include": [
|
||||||
|
{
|
||||||
|
"email": {
|
||||||
|
"email": "christoph@emsenhuber.com"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"login_method": {
|
||||||
|
"id": "72c1291b-a38d-4bc7-af97-5dee04a4f84a"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"login_method": {
|
||||||
|
"id": "9024c7a6-2d1f-4432-9f48-51593acd1361"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"name": "christoph",
|
||||||
|
"require": [],
|
||||||
|
"connection_rules": {
|
||||||
|
"rdp": {}
|
||||||
|
},
|
||||||
|
"session_duration": "730h",
|
||||||
|
"uid": "8e44f5d1-8257-443e-a797-b3de939952ee",
|
||||||
|
"updated_at": "2026-07-31T07:27:41Z",
|
||||||
|
"reusable": true,
|
||||||
|
"precedence": 1
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"landing_page_design": {},
|
||||||
|
"skip_app_launcher_login_page": false
|
||||||
|
},
|
||||||
|
"success": true,
|
||||||
|
"errors": [],
|
||||||
|
"messages": []
|
||||||
|
}
|
||||||
449
docs/cf-backup/tp41-20260901/apps-all.json
Normal file
449
docs/cf-backup/tp41-20260901/apps-all.json
Normal file
@@ -0,0 +1,449 @@
|
|||||||
|
{
|
||||||
|
"result": [
|
||||||
|
{
|
||||||
|
"id": "86287661-7b23-4f38-874c-926cab1c0535",
|
||||||
|
"uid": "86287661-7b23-4f38-874c-926cab1c0535",
|
||||||
|
"type": "self_hosted",
|
||||||
|
"name": "Terpenfinder v3 assetlinks",
|
||||||
|
"aud": "353385474c9665c498f2c2477b0236a14a363aff5a700017ee5def5792587c62",
|
||||||
|
"created_at": "2026-07-31T07:50:12Z",
|
||||||
|
"updated_at": "2026-07-31T07:50:12Z",
|
||||||
|
"domain": "420.teilzeitladen.xyz/.well-known/assetlinks.json",
|
||||||
|
"self_hosted_domains": [
|
||||||
|
"420.teilzeitladen.xyz/.well-known/assetlinks.json"
|
||||||
|
],
|
||||||
|
"destinations": [
|
||||||
|
{
|
||||||
|
"type": "public",
|
||||||
|
"uri": "420.teilzeitladen.xyz/.well-known/assetlinks.json"
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"app_launcher_visible": false,
|
||||||
|
"allowed_idps": [],
|
||||||
|
"tags": [],
|
||||||
|
"auto_redirect_to_identity": false,
|
||||||
|
"policies": [
|
||||||
|
{
|
||||||
|
"created_at": "2026-07-31T07:50:12Z",
|
||||||
|
"decision": "bypass",
|
||||||
|
"exclude": [],
|
||||||
|
"id": "8f7c4929-376b-4e8f-b0cf-36fb4c686d69",
|
||||||
|
"include": [
|
||||||
|
{
|
||||||
|
"everyone": {}
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"name": "public-bypass",
|
||||||
|
"require": [],
|
||||||
|
"uid": "8f7c4929-376b-4e8f-b0cf-36fb4c686d69",
|
||||||
|
"updated_at": "2026-07-31T07:50:12Z",
|
||||||
|
"reusable": false,
|
||||||
|
"precedence": 1
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"session_duration": "730h",
|
||||||
|
"enable_binding_cookie": false,
|
||||||
|
"http_only_cookie_attribute": true,
|
||||||
|
"options_preflight_bypass": false,
|
||||||
|
"eager_redirect_cookie_setting": true
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "e6a7991f-466c-4d1d-bac6-4b30fafccce4",
|
||||||
|
"uid": "e6a7991f-466c-4d1d-bac6-4b30fafccce4",
|
||||||
|
"type": "self_hosted",
|
||||||
|
"name": "Terpenfinder v3",
|
||||||
|
"aud": "e4515f7a7740558bf51ff6056e9c52fec25e67d23607209250a92e10cdf574e7",
|
||||||
|
"created_at": "2026-06-22T20:47:31Z",
|
||||||
|
"updated_at": "2026-07-31T07:50:10Z",
|
||||||
|
"domain": "420.teilzeitladen.xyz",
|
||||||
|
"self_hosted_domains": [
|
||||||
|
"420.teilzeitladen.xyz"
|
||||||
|
],
|
||||||
|
"destinations": [
|
||||||
|
{
|
||||||
|
"type": "public",
|
||||||
|
"uri": "420.teilzeitladen.xyz"
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"app_launcher_visible": true,
|
||||||
|
"allowed_idps": [],
|
||||||
|
"tags": [],
|
||||||
|
"auto_redirect_to_identity": false,
|
||||||
|
"policies": [
|
||||||
|
{
|
||||||
|
"created_at": "2026-02-28T21:26:56Z",
|
||||||
|
"decision": "allow",
|
||||||
|
"exclude": [],
|
||||||
|
"id": "8e44f5d1-8257-443e-a797-b3de939952ee",
|
||||||
|
"include": [
|
||||||
|
{
|
||||||
|
"email": {
|
||||||
|
"email": "christoph@emsenhuber.com"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"login_method": {
|
||||||
|
"id": "72c1291b-a38d-4bc7-af97-5dee04a4f84a"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"login_method": {
|
||||||
|
"id": "9024c7a6-2d1f-4432-9f48-51593acd1361"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"name": "christoph",
|
||||||
|
"require": [],
|
||||||
|
"connection_rules": {
|
||||||
|
"rdp": {}
|
||||||
|
},
|
||||||
|
"session_duration": "730h",
|
||||||
|
"uid": "8e44f5d1-8257-443e-a797-b3de939952ee",
|
||||||
|
"updated_at": "2026-07-31T07:27:41Z",
|
||||||
|
"reusable": true,
|
||||||
|
"precedence": 1
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"created_at": "2026-03-06T20:11:40Z",
|
||||||
|
"decision": "allow",
|
||||||
|
"exclude": [],
|
||||||
|
"id": "99839886-4ef1-4bad-8cc6-dc864d4dceeb",
|
||||||
|
"include": [
|
||||||
|
{
|
||||||
|
"email": {
|
||||||
|
"email": "angelikahy@outlook.de"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"login_method": {
|
||||||
|
"id": "9024c7a6-2d1f-4432-9f48-51593acd1361"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"ip": {
|
||||||
|
"ip": "10.95.10.0/24"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"ip": {
|
||||||
|
"ip": "94.154.138.0/24"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"name": "geli",
|
||||||
|
"require": [],
|
||||||
|
"connection_rules": {
|
||||||
|
"rdp": {}
|
||||||
|
},
|
||||||
|
"session_duration": "730h",
|
||||||
|
"uid": "99839886-4ef1-4bad-8cc6-dc864d4dceeb",
|
||||||
|
"updated_at": "2026-07-31T07:27:53Z",
|
||||||
|
"reusable": true,
|
||||||
|
"precedence": 2
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"created_at": "2026-07-27T11:37:45Z",
|
||||||
|
"decision": "non_identity",
|
||||||
|
"exclude": [],
|
||||||
|
"id": "bf7d2e5e-3a53-4af1-a64c-a0f0d00703dc",
|
||||||
|
"include": [
|
||||||
|
{
|
||||||
|
"service_token": {
|
||||||
|
"token_id": "1082bad1-6a25-4188-bf6b-220075679e0f"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"name": "terpene-svc",
|
||||||
|
"require": [],
|
||||||
|
"uid": "bf7d2e5e-3a53-4af1-a64c-a0f0d00703dc",
|
||||||
|
"updated_at": "2026-08-05T18:33:01Z",
|
||||||
|
"reusable": true,
|
||||||
|
"precedence": 3
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"session_duration": "730h",
|
||||||
|
"enable_binding_cookie": false,
|
||||||
|
"http_only_cookie_attribute": true,
|
||||||
|
"options_preflight_bypass": false
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "1dbc45ca-1376-4a0d-b608-69db58f1875c",
|
||||||
|
"uid": "1dbc45ca-1376-4a0d-b608-69db58f1875c",
|
||||||
|
"type": "self_hosted",
|
||||||
|
"name": "hass, vw, gitea",
|
||||||
|
"aud": "817b2b82d2b1aa9c12de854c7bce9f608b33721f0827cfded68bdc7c5eb92a46",
|
||||||
|
"created_at": "2026-06-13T08:32:39Z",
|
||||||
|
"updated_at": "2026-07-12T12:43:25Z",
|
||||||
|
"domain": "vw.emsenhuber.net",
|
||||||
|
"self_hosted_domains": [
|
||||||
|
"vw.emsenhuber.net",
|
||||||
|
"hass.emsenhuber.net",
|
||||||
|
"gitea.emsenhuber.net"
|
||||||
|
],
|
||||||
|
"destinations": [
|
||||||
|
{
|
||||||
|
"type": "public",
|
||||||
|
"uri": "vw.emsenhuber.net"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"type": "public",
|
||||||
|
"uri": "hass.emsenhuber.net"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"type": "public",
|
||||||
|
"uri": "gitea.emsenhuber.net"
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"app_launcher_visible": true,
|
||||||
|
"allowed_idps": [],
|
||||||
|
"tags": [],
|
||||||
|
"auto_redirect_to_identity": false,
|
||||||
|
"policies": [
|
||||||
|
{
|
||||||
|
"created_at": "2026-06-13T08:34:00Z",
|
||||||
|
"decision": "bypass",
|
||||||
|
"exclude": [],
|
||||||
|
"id": "a8129e37-d3c2-456d-8630-3c6a3449d3f2",
|
||||||
|
"include": [
|
||||||
|
{
|
||||||
|
"everyone": {}
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"name": "bypass",
|
||||||
|
"require": [],
|
||||||
|
"connection_rules": {
|
||||||
|
"rdp": {}
|
||||||
|
},
|
||||||
|
"uid": "a8129e37-d3c2-456d-8630-3c6a3449d3f2",
|
||||||
|
"updated_at": "2026-06-13T08:48:05Z",
|
||||||
|
"reusable": true,
|
||||||
|
"precedence": 1
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"session_duration": "24h",
|
||||||
|
"enable_binding_cookie": false,
|
||||||
|
"http_only_cookie_attribute": true,
|
||||||
|
"options_preflight_bypass": false
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "6df5c431-adcf-4dde-805d-4eb22d7c19b4",
|
||||||
|
"uid": "6df5c431-adcf-4dde-805d-4eb22d7c19b4",
|
||||||
|
"type": "app_launcher",
|
||||||
|
"name": "App Launcher",
|
||||||
|
"aud": "015e805251579e50a49668775c2255facb5bc56007ce49f90885f4114584bae2",
|
||||||
|
"created_at": "2026-03-28T16:20:27Z",
|
||||||
|
"updated_at": "2026-07-08T11:56:56Z",
|
||||||
|
"domain": "emsenhuber.cloudflareaccess.com",
|
||||||
|
"allowed_idps": [],
|
||||||
|
"session_duration": "730h",
|
||||||
|
"auto_redirect_to_identity": false,
|
||||||
|
"policies": [
|
||||||
|
{
|
||||||
|
"created_at": "2026-02-28T21:26:56Z",
|
||||||
|
"decision": "allow",
|
||||||
|
"exclude": [],
|
||||||
|
"id": "8e44f5d1-8257-443e-a797-b3de939952ee",
|
||||||
|
"include": [
|
||||||
|
{
|
||||||
|
"email": {
|
||||||
|
"email": "christoph@emsenhuber.com"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"login_method": {
|
||||||
|
"id": "72c1291b-a38d-4bc7-af97-5dee04a4f84a"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"login_method": {
|
||||||
|
"id": "9024c7a6-2d1f-4432-9f48-51593acd1361"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"name": "christoph",
|
||||||
|
"require": [],
|
||||||
|
"connection_rules": {
|
||||||
|
"rdp": {}
|
||||||
|
},
|
||||||
|
"session_duration": "730h",
|
||||||
|
"uid": "8e44f5d1-8257-443e-a797-b3de939952ee",
|
||||||
|
"updated_at": "2026-07-31T07:27:41Z",
|
||||||
|
"reusable": true,
|
||||||
|
"precedence": 1
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"landing_page_design": {},
|
||||||
|
"skip_app_launcher_login_page": false
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "6c32fe23-24d8-433f-b00b-0a3d1558bb30",
|
||||||
|
"uid": "6c32fe23-24d8-433f-b00b-0a3d1558bb30",
|
||||||
|
"type": "warp",
|
||||||
|
"name": "Warp Login App",
|
||||||
|
"aud": "fdfaa967d4118469dc994257f65831caa0162d6c45a14b5205af45e1aeca723b",
|
||||||
|
"created_at": "2026-06-04T18:48:59Z",
|
||||||
|
"updated_at": "2026-06-06T16:53:32Z",
|
||||||
|
"domain": "emsenhuber.cloudflareaccess.com/warp",
|
||||||
|
"allowed_idps": [],
|
||||||
|
"session_duration": "24h",
|
||||||
|
"auto_redirect_to_identity": false,
|
||||||
|
"policies": [
|
||||||
|
{
|
||||||
|
"created_at": "2026-02-28T21:26:56Z",
|
||||||
|
"decision": "allow",
|
||||||
|
"exclude": [],
|
||||||
|
"id": "8e44f5d1-8257-443e-a797-b3de939952ee",
|
||||||
|
"include": [
|
||||||
|
{
|
||||||
|
"email": {
|
||||||
|
"email": "christoph@emsenhuber.com"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"login_method": {
|
||||||
|
"id": "72c1291b-a38d-4bc7-af97-5dee04a4f84a"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"login_method": {
|
||||||
|
"id": "9024c7a6-2d1f-4432-9f48-51593acd1361"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"name": "christoph",
|
||||||
|
"require": [],
|
||||||
|
"connection_rules": {
|
||||||
|
"rdp": {}
|
||||||
|
},
|
||||||
|
"session_duration": "730h",
|
||||||
|
"uid": "8e44f5d1-8257-443e-a797-b3de939952ee",
|
||||||
|
"updated_at": "2026-07-31T07:27:41Z",
|
||||||
|
"reusable": true,
|
||||||
|
"precedence": 1
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"tags": []
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "16aaec78-5951-4cf3-aad5-79f63163b5ea",
|
||||||
|
"uid": "16aaec78-5951-4cf3-aad5-79f63163b5ea",
|
||||||
|
"type": "self_hosted",
|
||||||
|
"name": "*.emsenhuber.net",
|
||||||
|
"aud": "d5bb8c4852895834a0010d6f63882f140cf27faf41f94374532c1f013a15c02d",
|
||||||
|
"created_at": "2026-05-05T11:44:38Z",
|
||||||
|
"updated_at": "2026-05-15T13:30:13Z",
|
||||||
|
"domain": "*.emsenhuber.net",
|
||||||
|
"self_hosted_domains": [
|
||||||
|
"*.emsenhuber.net"
|
||||||
|
],
|
||||||
|
"destinations": [
|
||||||
|
{
|
||||||
|
"type": "public",
|
||||||
|
"uri": "*.emsenhuber.net"
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"app_launcher_visible": true,
|
||||||
|
"allowed_idps": [],
|
||||||
|
"tags": [],
|
||||||
|
"auto_redirect_to_identity": false,
|
||||||
|
"policies": [
|
||||||
|
{
|
||||||
|
"created_at": "2026-02-28T21:26:56Z",
|
||||||
|
"decision": "allow",
|
||||||
|
"exclude": [],
|
||||||
|
"id": "8e44f5d1-8257-443e-a797-b3de939952ee",
|
||||||
|
"include": [
|
||||||
|
{
|
||||||
|
"email": {
|
||||||
|
"email": "christoph@emsenhuber.com"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"login_method": {
|
||||||
|
"id": "72c1291b-a38d-4bc7-af97-5dee04a4f84a"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"login_method": {
|
||||||
|
"id": "9024c7a6-2d1f-4432-9f48-51593acd1361"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"name": "christoph",
|
||||||
|
"require": [],
|
||||||
|
"connection_rules": {
|
||||||
|
"rdp": {}
|
||||||
|
},
|
||||||
|
"session_duration": "730h",
|
||||||
|
"uid": "8e44f5d1-8257-443e-a797-b3de939952ee",
|
||||||
|
"updated_at": "2026-07-31T07:27:41Z",
|
||||||
|
"reusable": true,
|
||||||
|
"precedence": 1
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"created_at": "2026-05-09T06:45:22Z",
|
||||||
|
"decision": "non_identity",
|
||||||
|
"exclude": [],
|
||||||
|
"id": "5165d139-8733-4d31-a3a5-f6f1d0fd8643",
|
||||||
|
"include": [
|
||||||
|
{
|
||||||
|
"ip": {
|
||||||
|
"ip": "90.146.33.177/32"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"name": "bf4",
|
||||||
|
"require": [],
|
||||||
|
"uid": "5165d139-8733-4d31-a3a5-f6f1d0fd8643",
|
||||||
|
"updated_at": "2026-08-07T21:36:42Z",
|
||||||
|
"reusable": true,
|
||||||
|
"precedence": 2
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"created_at": "2026-05-15T13:11:36Z",
|
||||||
|
"decision": "non_identity",
|
||||||
|
"exclude": [],
|
||||||
|
"id": "39fe0e9d-6f63-414d-9d6d-440a7a151f5d",
|
||||||
|
"include": [
|
||||||
|
{
|
||||||
|
"service_token": {
|
||||||
|
"token_id": "65f1821a-f134-4e20-aa66-baf31daddbed"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"name": "claude-mcp",
|
||||||
|
"require": [],
|
||||||
|
"uid": "39fe0e9d-6f63-414d-9d6d-440a7a151f5d",
|
||||||
|
"updated_at": "2026-07-31T15:44:48Z",
|
||||||
|
"reusable": true,
|
||||||
|
"precedence": 3
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"session_duration": "24h",
|
||||||
|
"enable_binding_cookie": false,
|
||||||
|
"http_only_cookie_attribute": false,
|
||||||
|
"options_preflight_bypass": false,
|
||||||
|
"oauth_configuration": {
|
||||||
|
"enabled": false,
|
||||||
|
"dynamic_client_registration": {
|
||||||
|
"enabled": true,
|
||||||
|
"allowed_uris": [
|
||||||
|
"https://ha-mcp.emsenhuber.net"
|
||||||
|
],
|
||||||
|
"allow_any_on_localhost": true,
|
||||||
|
"allow_any_on_loopback": true
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"success": true,
|
||||||
|
"errors": [],
|
||||||
|
"messages": [],
|
||||||
|
"result_info": {
|
||||||
|
"page": 1,
|
||||||
|
"per_page": 1000,
|
||||||
|
"count": 6,
|
||||||
|
"total_count": 6,
|
||||||
|
"total_pages": 1
|
||||||
|
}
|
||||||
|
}
|
||||||
68
docs/cf-backup/tp41-20260901/identity_providers.json
Normal file
68
docs/cf-backup/tp41-20260901/identity_providers.json
Normal file
@@ -0,0 +1,68 @@
|
|||||||
|
{
|
||||||
|
"result": [
|
||||||
|
{
|
||||||
|
"id": "72c1291b-a38d-4bc7-af97-5dee04a4f84a",
|
||||||
|
"type": "github",
|
||||||
|
"uid": "72c1291b-a38d-4bc7-af97-5dee04a4f84a",
|
||||||
|
"name": "github",
|
||||||
|
"version": "2c72ea4133061227e63696fb2559488b",
|
||||||
|
"config": {
|
||||||
|
"client_id": "Ov23li2h96hAkGRPJXYV",
|
||||||
|
"redirect_url": "https://emsenhuber.cloudflareaccess.com/cdn-cgi/access/callback"
|
||||||
|
},
|
||||||
|
"scim_config": {
|
||||||
|
"scim_base_url": "https://emsenhuber.cloudflareaccess.com/scim/72c1291b-a38d-4bc7-af97-5dee04a4f84a",
|
||||||
|
"enabled": false,
|
||||||
|
"user_deprovision": false,
|
||||||
|
"seat_deprovision": false,
|
||||||
|
"group_member_deprovision": false,
|
||||||
|
"identity_update_behavior": "no_action"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "9024c7a6-2d1f-4432-9f48-51593acd1361",
|
||||||
|
"type": "onetimepin",
|
||||||
|
"uid": "9024c7a6-2d1f-4432-9f48-51593acd1361",
|
||||||
|
"name": "",
|
||||||
|
"version": "04b0d281756f552d156faa58ce97f913",
|
||||||
|
"config": {
|
||||||
|
"redirect_url": "https://emsenhuber.cloudflareaccess.com/cdn-cgi/access/callback"
|
||||||
|
},
|
||||||
|
"scim_config": {
|
||||||
|
"enabled": false,
|
||||||
|
"user_deprovision": false,
|
||||||
|
"seat_deprovision": false,
|
||||||
|
"group_member_deprovision": false
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "c7571880-2c63-4b66-a52a-0051802f7444",
|
||||||
|
"type": "google",
|
||||||
|
"uid": "c7571880-2c63-4b66-a52a-0051802f7444",
|
||||||
|
"name": "google",
|
||||||
|
"version": "6c1595b3026ae3196c70977c3924befb",
|
||||||
|
"config": {
|
||||||
|
"client_id": "276709275903-b3q55lsj203v4strbhh5mub76cib867e.apps.googleusercontent.com",
|
||||||
|
"redirect_url": "https://emsenhuber.cloudflareaccess.com/cdn-cgi/access/callback"
|
||||||
|
},
|
||||||
|
"scim_config": {
|
||||||
|
"scim_base_url": "https://emsenhuber.cloudflareaccess.com/scim/c7571880-2c63-4b66-a52a-0051802f7444",
|
||||||
|
"enabled": false,
|
||||||
|
"user_deprovision": false,
|
||||||
|
"seat_deprovision": false,
|
||||||
|
"group_member_deprovision": false,
|
||||||
|
"identity_update_behavior": "no_action"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"success": true,
|
||||||
|
"errors": [],
|
||||||
|
"messages": [],
|
||||||
|
"result_info": {
|
||||||
|
"page": 1,
|
||||||
|
"per_page": 200,
|
||||||
|
"count": 3,
|
||||||
|
"total_count": 3,
|
||||||
|
"total_pages": 1
|
||||||
|
}
|
||||||
|
}
|
||||||
29
docs/cf-backup/tp41-20260901/organizations.json
Normal file
29
docs/cf-backup/tp41-20260901/organizations.json
Normal file
@@ -0,0 +1,29 @@
|
|||||||
|
{
|
||||||
|
"result": {
|
||||||
|
"auth_domain": "emsenhuber.cloudflareaccess.com",
|
||||||
|
"created_at": "2024-02-22T13:41:46Z",
|
||||||
|
"login_design": {
|
||||||
|
"background_color": "#eeeeee"
|
||||||
|
},
|
||||||
|
"name": "bf4.cloudflareaccess.com",
|
||||||
|
"updated_at": "2026-07-09T17:34:55Z",
|
||||||
|
"is_ui_read_only": false,
|
||||||
|
"has_migrated_private_apps": true,
|
||||||
|
"allow_authenticate_via_warp": false,
|
||||||
|
"warp_auth_non_browser_401": false,
|
||||||
|
"cache_device_posture": true,
|
||||||
|
"deny_unmatched_requests": false,
|
||||||
|
"deny_unmatched_requests_exempted_zone_names": [],
|
||||||
|
"mfa_config": {
|
||||||
|
"allowed_authenticators": [
|
||||||
|
"biometrics",
|
||||||
|
"security_key",
|
||||||
|
"totp"
|
||||||
|
],
|
||||||
|
"session_duration": "24h"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"success": true,
|
||||||
|
"errors": [],
|
||||||
|
"messages": []
|
||||||
|
}
|
||||||
51
docs/cf-backup/tp41-20260901/service_tokens.json
Normal file
51
docs/cf-backup/tp41-20260901/service_tokens.json
Normal file
@@ -0,0 +1,51 @@
|
|||||||
|
{
|
||||||
|
"result": [
|
||||||
|
{
|
||||||
|
"client_id": "ad1b47dee8ba9625eebb30247d163dda.access",
|
||||||
|
"created_at": "2026-05-15T13:09:45Z",
|
||||||
|
"expires_at": "2027-05-15T13:19:03Z",
|
||||||
|
"id": "65f1821a-f134-4e20-aa66-baf31daddbed",
|
||||||
|
"name": "claude-mcp",
|
||||||
|
"updated_at": "2026-07-31T14:32:11Z",
|
||||||
|
"duration": "8760h",
|
||||||
|
"client_secret_version": 4,
|
||||||
|
"previous_client_secret_expires_at": "2026-07-31T14:32:11Z",
|
||||||
|
"enabled": true
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"client_id": "e8a56791f7f534f3eaff8629d8fe902c.access",
|
||||||
|
"created_at": "2026-07-27T11:36:26Z",
|
||||||
|
"expires_at": "2027-08-05T18:32:14Z",
|
||||||
|
"id": "a6be7efa-8367-446d-99b8-67f25f173371",
|
||||||
|
"name": "terpene-verify",
|
||||||
|
"updated_at": "2026-08-05T18:32:14Z",
|
||||||
|
"duration": "8760h",
|
||||||
|
"last_seen_at": "2026-08-02T20:49:21Z",
|
||||||
|
"client_secret_version": 3,
|
||||||
|
"previous_client_secret_expires_at": "2026-07-31T10:00:00Z",
|
||||||
|
"enabled": true
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"client_id": "0ec06d3a6dc6d689c13407591b286e5b.access",
|
||||||
|
"created_at": "2026-08-05T18:32:36Z",
|
||||||
|
"expires_at": "2027-08-05T18:32:36Z",
|
||||||
|
"id": "1082bad1-6a25-4188-bf6b-220075679e0f",
|
||||||
|
"name": "terpene-verify-v2",
|
||||||
|
"updated_at": "2026-08-05T18:32:36Z",
|
||||||
|
"duration": "8760h",
|
||||||
|
"last_seen_at": "2026-08-27T12:47:30Z",
|
||||||
|
"client_secret_version": 1,
|
||||||
|
"enabled": true
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"success": true,
|
||||||
|
"errors": [],
|
||||||
|
"messages": [],
|
||||||
|
"result_info": {
|
||||||
|
"page": 1,
|
||||||
|
"per_page": 1000,
|
||||||
|
"count": 3,
|
||||||
|
"total_count": 3,
|
||||||
|
"total_pages": 1
|
||||||
|
}
|
||||||
|
}
|
||||||
186
docs/handoff-20260901-fund-e-hebel1-zurueckgebaut.md
Normal file
186
docs/handoff-20260901-fund-e-hebel1-zurueckgebaut.md
Normal file
@@ -0,0 +1,186 @@
|
|||||||
|
# Handoff 2026-09-01 — Hebel 1 widerlegt und zurückgebaut, 7.24.1 ist der Verdächtige
|
||||||
|
|
||||||
|
> Vorgänger: [`handoff-20260831-tp27-upgrade-und-hebel1-befund.md`](handoff-20260831-tp27-upgrade-und-hebel1-befund.md).
|
||||||
|
> **Dieses Dokument ist der Stand danach.** Offene Aufgabe: **eine Messung am 2026-09-02 früh.**
|
||||||
|
|
||||||
|
## Die Messung, die Hebel 1 widerlegt
|
||||||
|
|
||||||
|
| Fenster | Bedingung | iPhone-`reauthenticating` | pro Stunde |
|
||||||
|
|---|---|---|---|
|
||||||
|
| 31.08. 07:00–08:00 | Baseline | **79** | 79 |
|
||||||
|
| 31.08. 08:09–14:36 | **nur Hebel 1** (ROS 7.24) | **124** | ~19 |
|
||||||
|
| 31.08. 14:37–24:00 | Hebel 1 + **7.24.1** | 17 | ~1,8 |
|
||||||
|
| 01.09. 00:00–07:57 | Hebel 1 + 7.24.1 | **0** | 0 |
|
||||||
|
|
||||||
|
6,4 Stunden Hebel 1 **allein** haben nichts verbessert. Der Einbruch fällt exakt auf den
|
||||||
|
Core-Reboot um 14:36 — also auf das TP27-Upgrade, nicht auf den Hebel.
|
||||||
|
|
||||||
|
**Beide Gegenproben bestanden** — ohne sie wäre die Null wertlos:
|
||||||
|
- **War das Telefon da?** Ja: 27 Zeilen am 01.09., mehrfaches Roaming, live verbunden.
|
||||||
|
- **Lief das Logging?** Ja: keine Lücke > 15 min in der Tagesdatei.
|
||||||
|
|
||||||
|
## 🔴 Widerspruch zu einer Parallelsession — und wie er aufzulösen ist
|
||||||
|
|
||||||
|
Eine zweite Session hat in der Nacht denselben Fall bearbeitet und kam zum **gegenteiligen**
|
||||||
|
Schluss: [`handoff-20260901-tp25-ap2-verdacht.md`](handoff-20260901-tp25-ap2-verdacht.md) wertet
|
||||||
|
Fund E als **geheilt durch Hebel 1** und empfiehlt, ihn zu **committen**.
|
||||||
|
|
||||||
|
**Ihr Beleg war eine Fehlmessung.** Zitiert wird
|
||||||
|
`get_log topics=[wireless] prefix=reauthenticating sinceMinutes=1440` → `total 0`. Das ist der
|
||||||
|
**flüchtige Ringpuffer des Routers**, nicht der Kollektor:
|
||||||
|
|
||||||
|
```
|
||||||
|
/log am Core, live geprüft 2026-09-01 09:1x:
|
||||||
|
1000 Zeilen im Ringpuffer, ältester Eintrag 2026-09-01 00:38:58 ← keine 9 Stunden Tiefe
|
||||||
|
```
|
||||||
|
|
||||||
|
Der Core wurde am 31.08. um **14:36** neu gestartet; der Puffer war danach leer und um 01:18
|
||||||
|
längst überschrieben. Eine 1440-Minuten-Abfrage konnte den 31.08. Vormittag **nicht sehen** —
|
||||||
|
`total 0` heißt „im Puffer nichts", nicht „in 24 h nichts". Genau diese Falle war der Anlass, am
|
||||||
|
30.08. das persistente Logging einzurichten (CLAUDE.md: „ein seit Wochen gemeldetes Client-Problem
|
||||||
|
war rückwirkend nicht diagnostizierbar").
|
||||||
|
|
||||||
|
**Der zweite Einwand — die 124 seien Reboot-Artefakte — trägt ebenfalls nicht.** Die Upgrade-Reboots
|
||||||
|
waren ap2 08:56, core 14:36, ap1 14:50, branch 14:52. Zwischen **09:00 und 14:36 gab es keinen
|
||||||
|
Reboot**, und in diesem Fenster stehen im Kollektor 09h=1, 11h=2, 12h=20, 13h=31, 14h=70 — **alle
|
||||||
|
vom iPhone allein**, also nach dem eigenen Gotcha der Session (viele MACs = Infrastruktur, eine MAC
|
||||||
|
= Client) ein Client-Befund. Dazu Christophs **zwei erlebte Ausfälle** um 13:16 und 14:23.
|
||||||
|
|
||||||
|
⚖️ **Auflösung: der Rückbau IST das Experiment, das den Streit entscheidet.** Steht `ft-over-ds`
|
||||||
|
wieder auf `yes` und bleibt es trotzdem ruhig, war 7.24.1 die Ursache. Kommt das Hämmern zurück,
|
||||||
|
hatte die Parallelsession recht und Hebel 1 wird als neue Transaktion erneut gezogen. **Vor dem
|
||||||
|
2026-09-02 früh sollte niemand committen.**
|
||||||
|
|
||||||
|
✅ **Unabhängig davon wertvoll: ihr `ap2`-Befund.** Am 31.08. um 23:02 meldete Christoph eine
|
||||||
|
Störung am Schreibtisch; die Session maß **−80 dBm bei 2 m Abstand** zu ap2, `not responding` bei
|
||||||
|
−82, und **0 Clients auf ap2** bei 29 auf ap3. Das ist weder Coverage noch FT, sondern ein
|
||||||
|
Hardware-/Störungsverdacht (Kandidat: DTU auf ch11, Transaktion `TP17.1-dtu-pin-ap2`). **Das
|
||||||
|
erklärt den 23:02-Schmerz, den mein Rückbau nicht adressiert** — eigener Strang, braucht eine
|
||||||
|
In-situ-Messung.
|
||||||
|
|
||||||
|
## Was heute getan wurde: Rückbau statt Commit
|
||||||
|
|
||||||
|
**Warum nicht committen:** Solange Hebel 1 steht, sind zwei Änderungen gleichzeitig aktiv. Der
|
||||||
|
Rückbau isoliert das Upgrade — **er ist der Test**, nicht bloß Aufräumen. Und weil das GC-Template
|
||||||
|
in Z. 220 ohnehin `ft-over-ds=yes` führt, kommt die Compliance **ohne Template-Änderung** zurück.
|
||||||
|
|
||||||
|
Weg **symmetrisch zum Hinweg** (Christoph-Entscheid), also am Gerät, nicht über GC:
|
||||||
|
|
||||||
|
```
|
||||||
|
/system backup save name=pre-tp25-funde-rollback # 0
|
||||||
|
/interface wifi security set [find name="sec-main"] ft-over-ds=yes
|
||||||
|
/interface wifi capsman remote-cap provision [find]
|
||||||
|
```
|
||||||
|
|
||||||
|
Der Rückbau-Vorschlag aus dem Snapshot zeigte **genau eine** Abweichung — kein Kollateral-Drift:
|
||||||
|
```
|
||||||
|
JETZT NUR AM GERAET ... ft=yes ft-over-ds=no name=sec-main
|
||||||
|
IM SNAPSHOT, FEHLT ... ft=yes ft-over-ds=yes name=sec-main
|
||||||
|
```
|
||||||
|
|
||||||
|
### Abnahme
|
||||||
|
|
||||||
|
| Prüfung | Ergebnis |
|
||||||
|
|---|---|
|
||||||
|
| `ft-over-ds` am Core | **`ft=yes ft-over-ds=yes`** ✓ |
|
||||||
|
| CAPs | 3 × `Ok`, CAPWAP-Verbindung **ununterbrochen** (17 h) — `provision` trennt sie nicht |
|
||||||
|
| VAPs **am CAP** gelesen | ap2 **9/9** `running`, ap3 **9/9** `running` |
|
||||||
|
| **Frische DHCP-Lease** (die vorgeschriebene Abnahme) | iPhone `10.40.10.196`, `bound`, `expires-after 23h58m56s` bei 24 h Laufzeit ⇒ **~1 min alt** |
|
||||||
|
| Clients | 25 → 28 zurück |
|
||||||
|
| Transaktion | `gc-transaktion.py status` → **`zurueckgebaut`**, kein Drift im Scope |
|
||||||
|
| Compliance | **140/140, 0 Drifts** — ohne jede Template-Änderung, wie vorhergesagt |
|
||||||
|
|
||||||
|
### ⚠️ Zwei Nebenbefunde beim Compliance-Lauf
|
||||||
|
|
||||||
|
**1. `gc-configplan.py --refresh-compliance` scheitert STILL, wenn `NAUTOBOT_TOKEN` fehlt** —
|
||||||
|
Ausgabe „NAUTOBOT_TOKEN nicht gesetzt", danach **Exit-Code 0**. Wer nur den Rückgabewert prüft,
|
||||||
|
hält einen nie gelaufenen Compliance-Check für erfolgreich. Behelf in dieser Session:
|
||||||
|
```bash
|
||||||
|
NAUTOBOT_TOKEN="$(sed -n 's/^[[:space:]]*-[[:space:]]*NAUTOBOT_SUPERUSER_API_TOKEN=//p' \
|
||||||
|
docs/nas-vlan20/stacks/210-nautobot.yml | head -1)" python3 nautobot/gc-configplan.py --refresh-compliance
|
||||||
|
```
|
||||||
|
Dauerhafte Antwort wäre `NAUTOBOT_TOKEN` in `~/.secrets/exports.zsh` (steht schon im Handoff vom
|
||||||
|
31.08. als offener Punkt). ⇒ **Der Exit-Code gehört gefixt**, sonst wiederholt sich das.
|
||||||
|
|
||||||
|
**2. Die Compliance-Zahl ist von 135 auf 140 gestiegen — das ist erklärt, nicht übergangen.**
|
||||||
|
Es gibt jetzt **28 ComplianceRules** statt 27 (5 Geräte × 28 = 140). Neu ist **`interface-veth`**,
|
||||||
|
angelegt **2026-08-31 20:04**, also **nach** der Session vom 31.08. und **nicht** in dieser hier.
|
||||||
|
🔴 **Wer sie angelegt hat, ist offen** — `veth` betrifft Container auf RouterOS. Bitte klären,
|
||||||
|
bevor jemand die Zahl als Basislinie zitiert.
|
||||||
|
|
||||||
|
## 🔴 Die `cap-wifiN`-Karte ist beim Provisionieren SOFORT wieder gewandert
|
||||||
|
|
||||||
|
Innerhalb dieser Session, zwischen zwei Reads im Abstand von Minuten:
|
||||||
|
|
||||||
|
| | vor dem Rückbau (galt 31.08. 14:52 – 01.09. 08:2x) | **ab jetzt** |
|
||||||
|
|---|---|---|
|
||||||
|
| ap3 | `cap-wifi3` / `cap-wifi4` | `cap-wifi3` / **`cap-wifi5`** |
|
||||||
|
| ap2 | `cap-wifi5` / `cap-wifi6` | **`cap-wifi4`** / `cap-wifi6` |
|
||||||
|
| ap1 | `cap-wifi1` / `cap-wifi2` | **getauscht** (`cap-wifi2` / `cap-wifi1`) |
|
||||||
|
|
||||||
|
Belastbar ist nur die **`radio-mac`**, weil sie am Gerät hängt:
|
||||||
|
`ap3 …:9F` = 5 GHz → `cap-wifi3` · `ap3 …:A0` = 2,4 GHz → `cap-wifi5` ·
|
||||||
|
`ap2 …:3E` → `cap-wifi4` · `ap2 …:3F` → `cap-wifi6` · `ap1 …:E5` → `cap-wifi2` · `…:E6` → `cap-wifi1`
|
||||||
|
*(Bandzuordnung für ap2/ap1 in dieser Session **nicht** nachgemessen — nicht raten.)*
|
||||||
|
|
||||||
|
⚠️ **Folge für die Auswertung:** Logzeilen vom 01.09. **vor** ca. 08:25 gehören zur linken Spalte.
|
||||||
|
Sie sind zuschreibbar, weil im ganzen Messfenster **0 `caps`-Ereignisse** standen — das war
|
||||||
|
Glück, kein Verdienst.
|
||||||
|
|
||||||
|
## Die Messung am 2026-09-02
|
||||||
|
|
||||||
|
```bash
|
||||||
|
ssh root@10.40.20.100 "pct exec 400 -- sh -c '
|
||||||
|
D=/opt/tp5-syslog/log/10.40.20.1;
|
||||||
|
echo -n \"caps: \"; grep -c \" caps,\" $D/2026-09-02.log;
|
||||||
|
echo -n \"reauth: \"; grep reauthenticating $D/2026-09-02.log | grep -c E1:AF:09;
|
||||||
|
echo -n \"iPhone da? \"; grep -c E1:AF:09 $D/2026-09-02.log'"
|
||||||
|
```
|
||||||
|
**Reihenfolge einhalten:** erst `caps` (Rejoins erzeugen Bursts, die wie ein Client-Problem
|
||||||
|
aussehen), dann `reauth`, dann die Anwesenheitsprobe. Vergleichszeitraum ist **07:00–08:00** —
|
||||||
|
dort standen am 31.08. 79 Ereignisse, am 01.09. null.
|
||||||
|
|
||||||
|
| Ergebnis | Schluss | Nächster Schritt |
|
||||||
|
|---|---|---|
|
||||||
|
| weiter ~0 | **7.24.1 hat es behoben**, Hebel 1 war wirkungslos | Fund E schließen; offen bleibt das Band-Ping-Pong (s. u.) |
|
||||||
|
| Hämmern kommt zurück | Hebel 1 hat doch beigetragen | neue Transaktion, `ft-over-ds=no` erneut — diesmal auf 7.24.1 **isoliert** |
|
||||||
|
|
||||||
|
## Neues Symptom, das die Reauth-Schleife ablöst: Band-Ping-Pong
|
||||||
|
|
||||||
|
Am 01.09. hämmert nichts mehr, aber das iPhone oszilliert zwischen den **beiden Bändern desselben
|
||||||
|
AP** (alte Karte, also ap3 5 GHz ↔ ap3 2,4 GHz):
|
||||||
|
```
|
||||||
|
01:49:14 ap3-2,4G → ap3-5G (−65)
|
||||||
|
01:49:32 ap3-5G → ap3-2,4G (−55) ← 18 s später zurück
|
||||||
|
01:50:28 ap3-2,4G → ap3-5G (−69)
|
||||||
|
07:45 / 07:46 / 07:47 dasselbe im Minutentakt
|
||||||
|
```
|
||||||
|
Verbindungsalter beim Nachsehen: **1:26 min** bei −72 dBm. Das ist kein Auth-Problem mehr, sondern
|
||||||
|
genau das, wofür **Hebel 3 (`2g-probe-delay=yes`)** gedacht war. **Nicht** in diesem Durchgang.
|
||||||
|
|
||||||
|
## ⚠️ Zwei Anomalien aus dem Gesamtlog — eigener Durchgang, nicht nebenbei
|
||||||
|
|
||||||
|
**1. Das Log besteht zu 98,4 % aus Rauschen.** 5457 von 5548 Zeilen sind Firewall-Drops, davon
|
||||||
|
**3810 MNDP-Broadcasts (udp/5678) der eigenen Netzgeräte** (ap1/ap2/ap3/branch, je ~950/Tag).
|
||||||
|
Nutzsignal 1,6 % — in genau dem Log, das unser Diagnosewerkzeug ist.
|
||||||
|
|
||||||
|
**2. 🔴 IGMP aus VLAN30 wird verworfen** (funktional, nicht kosmetisch):
|
||||||
|
```
|
||||||
|
in:vlan30 proto 2, 10.40.30.211->224.0.0.251
|
||||||
|
in:vlan30 proto 2, 10.40.30.215->224.0.0.251
|
||||||
|
```
|
||||||
|
Membership-Reports für die **mDNS-Gruppe** von zwei IoT-Geräten. Der Core betreibt
|
||||||
|
`mdns-repeat-ifaces` — er verwirft also Anmeldungen für genau den Dienst, den er weiterreichen
|
||||||
|
soll. Kandidat für Matter/HomeKit-Discovery-Probleme (TP12.1).
|
||||||
|
|
||||||
|
**3. Nebenbefund zur Hypothese:** `dirtyvader-iot` (mit `ft=no`) hatte am 31.08. **7
|
||||||
|
`reauthenticating`**, und `association rejected, no cached PMK` tritt dort ebenfalls auf. Die
|
||||||
|
ursprüngliche Trennschärfe „93/93 nur auf der `ft=yes`-SSID" galt für die Nacht-Baseline, **nicht
|
||||||
|
für den vollen Tag**. `no cached PMK` ist PMKSA-Caching und nicht FT-spezifisch.
|
||||||
|
|
||||||
|
## Unverändert offen
|
||||||
|
|
||||||
|
1. TP25-Messrunde mit Rundgang (`bash docs/tp25-runde.sh`) — **Terrasse und Arbeitszimmer**;
|
||||||
|
`ap-map` dabei neu einfrieren (s. o., sie wandert bei jedem Provision).
|
||||||
|
2. Passwort-Rotation TP30 (Admin-PW am 08-30 verbrannt).
|
||||||
|
3. ap1-Umzug ans Sideboard (`core ether3`, `5260/Ce`, Frequenz-**Liste**, `tx-power` vorher messen).
|
||||||
54
docs/handoff-20260901-tp25-ap2-verdacht.md
Normal file
54
docs/handoff-20260901-tp25-ap2-verdacht.md
Normal file
@@ -0,0 +1,54 @@
|
|||||||
|
# Handoff 2026-09-01 — TP25: Fund E geheilt (sauberes Fenster) + neuer Verdacht `ap2`
|
||||||
|
|
||||||
|
**Kontext:** Christoph meldete um **2026-08-31 23:02** eine WLAN-Störung am Schreibtisch (5G, iPhone,
|
||||||
|
kein Telefonat). Diese Session hat den Vorfall am Manager `crs326-core` analysiert (alles read-only)
|
||||||
|
und dabei den Fund-E-Stand korrigiert. Parallel wurde TP39 abgeschlossen (eigener Strang, s. Archiv).
|
||||||
|
|
||||||
|
## Kernbefunde
|
||||||
|
|
||||||
|
### 1. Fund E (`reauthenticating`) ist geheilt — die „GESCHEITERT"-Wertung war kontaminiert
|
||||||
|
- Core-Uptime `10h41m` @ 01:18 ⇒ letzter Reboot **14:36** (TP27-Upgrade). Der `caps`-Log endet um
|
||||||
|
15:57; um 23:02 **kein** caps-Ereignis ⇒ kein Infrastruktur-/Reboot-Burst, echtes Client-Event.
|
||||||
|
- **Tages-Query** `get_log topics=[wireless] prefix=reauthenticating sinceMinutes=1440` → **total 0**.
|
||||||
|
Das erste ungestörte Fenster (14:36 → 01:20, **10,7 h**) zeigt **0× reauthenticating**; Baseline 93×.
|
||||||
|
- Die im Vorgänger-Handoff notierten „124× nach dem Eingriff" fielen in die TP27-Upgrade-Reboots
|
||||||
|
(viele MACs = Infrastruktur, CLAUDE.md-Gotcha). ⇒ **Hebel 1 (`ft-over-ds=no`) hat sein Ziel erreicht.**
|
||||||
|
|
||||||
|
### 2. Neuer Teilbefund: `ap2` unterperformt (das ist der 23:02-Schmerz, NICHT FT)
|
||||||
|
AP-Karte (Manager, stabil seit Rejoin 15:57): `cap-wifi5/6 = ap2`, `cap-wifi3/4 = ap3`,
|
||||||
|
`cap-wifi1/2 = ap1` (funkstill).
|
||||||
|
|
||||||
|
- 23:02: iPhone `F2:62:4C:E1:AF:09` ping-pongt im Sekundentakt `cap-wifi5 ↔ cap-wifi6` =
|
||||||
|
**ap2s 5G (5220) ↔ ap2s 2,4G (ch11/2462)** — Band-Steering-Thrash auf **demselben** AP.
|
||||||
|
`disconnected, not responding` um 22:37:40 (−76) und **23:01:00** (−82). Roam-Feldstärke −75…−88 dBm.
|
||||||
|
- 🔴 **Christophs Fakt:** iPhone ↔ ap2 nur **2 m**, gleicher Raum, ap2 auf 2,3 m. Bei 2 m wären
|
||||||
|
−35…−45 dBm normal. −80 auf 2 m ⇒ **kein Coverage-, kein FT-Problem**.
|
||||||
|
- **0 Clients auf ap2 aktuell**, alle 29 auf ap3 → die Clients meiden ap2.
|
||||||
|
- Verdacht: **ap2s Funk selbst** (RF/Antenne/HW) und/oder **DTU-Störung auf ap2/ch11**
|
||||||
|
(Transaktion `TP17.1-dtu-pin-ap2`, `54:F2:9F:12:51:F0`, −59 dBm auf ap2s 2,4-Radio).
|
||||||
|
|
||||||
|
**In-situ-Diagnose nötig** (nachts nicht messbar, Phone idle auf ap3): Registration-Signal live prüfen,
|
||||||
|
während ein Client auf ap2 hängt. Kandidaten-Eingriffe: DTU-Pin lösen/verlegen; `dirtyvader-main` auf
|
||||||
|
ap2 temporär deaktivieren (ap3 übernimmt Schreibtisch); ap2-Antenne/HW prüfen. **Keine Änderung ohne
|
||||||
|
diese Messung.**
|
||||||
|
|
||||||
|
## Offen / nächster Schritt
|
||||||
|
|
||||||
|
**Hebel 1 committen** (Transaktion `TP25-fund-e-ft-over-ds`, Scope `wifi-security`, Ablauf 2026-09-03).
|
||||||
|
Der Commit ist eine **git-push-Kette** und wartet auf Christophs Go:
|
||||||
|
|
||||||
|
1. `nautobot/mikrotik_routeros.j2` **Z. 220**: `sec-main` `ft-over-ds=yes` → `ft-over-ds=no`.
|
||||||
|
2. Template-Repo nach Nautobot syncen (Golden-Config-Git-Repository).
|
||||||
|
3. `python3 nautobot/gc-configplan.py --refresh-compliance` (Backup → Intended → Compliance).
|
||||||
|
4. `python3 nautobot/gc-transaktion.py commit --change-id TP25-fund-e-ft-over-ds`
|
||||||
|
(verweigert, solange `wifi-security` noch driftet — deshalb Schritt 1–3 zuerst).
|
||||||
|
|
||||||
|
🔴 Schritt 1 ist ein `git push` (Backup-Guard + Christophs Commit-Hinweis-Regel) und Schritt 2–4 sind
|
||||||
|
Live-Nautobot-Jobs — bewusst **nicht autonom** ausgeführt. Geräte-Backup `pre-tp25-funde-ftoverds.backup`
|
||||||
|
liegt auf dem Core. `wifi-security` wird ohnehin **nicht deployt** (Passphrasen `<<REDACTED>>` im
|
||||||
|
Template, Z. 189–196) — der Commit ist reine Soll↔Live-Angleichung, kein Geräte-Write.
|
||||||
|
|
||||||
|
## Werkzeug-Notiz
|
||||||
|
- AP-Zuordnung: `/interface wifi radio print terse proplist=cap,radio-mac,interface` am Manager.
|
||||||
|
- reauth-Zählung: `get_log` mit `prefix=reauthenticating` (nicht `list_wifi_interfaces` — leakt PSKs).
|
||||||
|
- Kanäle: `/interface wifi print detail` je `cap-wifiN` (Frequenz + Band im `channel.`-Block).
|
||||||
@@ -62,6 +62,7 @@ teuerste Eigenschaft der Datei zerstört, um ihr billigstes Problem zu lösen. B
|
|||||||
| [TP27](#tp27) | RouterBOOT-Firmware auf 7.24 nachziehen | ✅ DURCH (2026-08-17/18) |
|
| [TP27](#tp27) | RouterBOOT-Firmware auf 7.24 nachziehen | ✅ DURCH (2026-08-17/18) |
|
||||||
| [TP28](#tp28) | WLAN über CAPsMAN auf `crs326-core` | ↩️ **wieder geöffnet 2026-08-30** (ap3) — Volltext in [teilprojekte.md](teilprojekte.md#tp28) |
|
| [TP28](#tp28) | WLAN über CAPsMAN auf `crs326-core` | ↩️ **wieder geöffnet 2026-08-30** (ap3) — Volltext in [teilprojekte.md](teilprojekte.md#tp28) |
|
||||||
| [TP-R](#tp-r) | Router-Capabilities-Sweep | FERTIG (docs/research/routeros-capabilities.md) |
|
| [TP-R](#tp-r) | Router-Capabilities-Sweep | FERTIG (docs/research/routeros-capabilities.md) |
|
||||||
|
| [TP39](#tp39) | LXC-Hygiene pve: Resolver-Altlasten, `networking.service`, DB-Reverse-Lookup | ✅ ABGESCHLOSSEN (2026-09-01) — pve+NAS-Sweep grün |
|
||||||
|
|
||||||
Dazu am Ende: **[TP25 (Langfassung)](#tp25-lang)** — die Messchronik und die Funde A–E im Volltext.
|
Dazu am Ende: **[TP25 (Langfassung)](#tp25-lang)** — die Messchronik und die Funde A–E im Volltext.
|
||||||
TP25 selbst ist **nicht** abgeschlossen und steht weiter in `teilprojekte.md`; nur seine 394 Zeilen
|
TP25 selbst ist **nicht** abgeschlossen und steht weiter in `teilprojekte.md`; nur seine 394 Zeilen
|
||||||
@@ -1697,3 +1698,82 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
|
|||||||
2026-08-13 gemessen: ap1 25→2, ap2 7→14). **Nicht während eines Calls deployen.** `/system backup` je AP vorher.
|
2026-08-13 gemessen: ap1 25→2, ap2 7→14). **Nicht während eines Calls deployen.** `/system backup` je AP vorher.
|
||||||
- **Abh.:** TP22 ✅ (GC-Deploy-Pipeline). Übernimmt den offenen Rest von **TP3.3**, verwandt **TP3.2** (Coverage-Doku
|
- **Abh.:** TP22 ✅ (GC-Deploy-Pipeline). Übernimmt den offenen Rest von **TP3.3**, verwandt **TP3.2** (Coverage-Doku
|
||||||
`docs/wifi-p750w-coverage-and-map.md`). **Kein Blocker für TP5/TP6** — läuft parallel.
|
`docs/wifi-p750w-coverage-and-map.md`). **Kein Blocker für TP5/TP6** — läuft parallel.
|
||||||
|
|
||||||
|
<a id="tp39"></a>
|
||||||
|
|
||||||
|
### TP39 — LXC-Hygiene auf pve: Resolver-Altlasten, `networking.service`, DB-Reverse-Lookup ▸ ✅ **ABGESCHLOSSEN (2026-09-01)**
|
||||||
|
|
||||||
|
**Auslöser:** ein 10-Sekunden-Hänger auf `gitea`, gefunden am Rand des TP16.3-§5-Flips. Er hatte mit
|
||||||
|
dem Flip nichts zu tun, war aber nur deshalb sichtbar, weil zum ersten Mal jemand systematisch
|
||||||
|
gemessen hat. Beim Beheben kam eine zweite, unabhängige Altlast zum Vorschein. Beide sind
|
||||||
|
**Hygiene an denselben pve-LXCs** und gehören in **ein** Wartungsfenster — deshalb ein TP, nicht zwei.
|
||||||
|
|
||||||
|
#### Was am 2026-09-01 bereits erledigt ist (Ausgangslage, nicht Aufgabe)
|
||||||
|
|
||||||
|
- **Ursache des Hängers:** MariaDB (LXC **302**, `10.40.20.23`) hatte `skip-name-resolve`
|
||||||
|
**auskommentiert** ⇒ Reverse-Lookup bei **jeder neuen Verbindung**; `/etc/resolv.conf` zeigte auf
|
||||||
|
den **toten** `10.40.41.254` (VLAN1-Altschema). **Gemessen: 10.010 ms je Lookup.**
|
||||||
|
Pool-Verbindungen waren schnell ⇒ das Symptom wirkte sporadisch.
|
||||||
|
- **Blast-Radius, per Verbindungstabelle belegt:** an dieser DB hängen **Vaultwarden (`.127`),
|
||||||
|
Home Assistant (`.105`) und gitea (`.157`)**.
|
||||||
|
- **Fix ausgerollt** (`pct set <id> --nameserver 10.40.20.1` + Reboot) für **fünf** LXCs:
|
||||||
|
`302 mariadb`, `102 mqtt5`, `106 influxdb2`, `107 redis`, `150 iob-exposed`.
|
||||||
|
**Nachher: Lookup 21–24 ms, gitea 0 von 25 Proben langsam** (vorher ~10 % bei 10,1 s).
|
||||||
|
|
||||||
|
#### Scope (alle Punkte erledigt)
|
||||||
|
|
||||||
|
1. ✅ **ERLEDIGT 2026-09-01: `skip-name-resolve` aktiviert.** Vorher `mysql.user` gelesen (User gab
|
||||||
|
den DB-Zugang per `/root/.my.cnf`) — **kein einziger Grant lautet auf einen DNS-Hostnamen**, alle
|
||||||
|
sind `%` / IP-Literal / `localhost`. Damit kann `skip-name-resolve` niemanden aussperren; der
|
||||||
|
Reverse-Lookup war reiner Ballast. Gesetzt als eigenes Drop-in
|
||||||
|
`/etc/mysql/mariadb.conf.d/90-skip-name-resolve.cnf` (nicht die `#`-Zeile in `50-server.cnf`
|
||||||
|
editiert — Paket-Update-stabil), `@@skip_name_resolve=1` nach Neustart verifiziert.
|
||||||
|
**Wirkung: gitea/vw/hass je 0 von 12 frischen Anfragen langsam, max 0,25 s.** Alle drei Clients
|
||||||
|
danach wieder verbunden. Die Ursache ist damit **beseitigt**, nicht nur entschärft.
|
||||||
|
🔴 **Sicherheitsvorfall dabei:** die `.my.cnf` trug `password <wert>` **ohne `=`**, die Maskierung
|
||||||
|
griff nicht ⇒ das **root-DB-Passwort ist ins Transkript geraten** und gehört rotiert (→ TP30).
|
||||||
|
2. ✅ **ERLEDIGT 2026-09-01: `networking.service` + `ifupdown-wait-online.service` in `101`, `102`,
|
||||||
|
`106`, `107` repariert.** **Ursache — dieselbe Altlast wie beim Resolver:** in
|
||||||
|
`/etc/network/interfaces` standen noch `auto`-Stanzas aus dem **alten VLAN1-Schema**
|
||||||
|
(`eth0` → `10.40.41.x`) und aus früheren Versuchen (`veth16`, `veth24`, ein Tippfehler `eth01`) —
|
||||||
|
**alle auf Interfaces, die es im Container nicht gibt.** `ifup -a` scheiterte daran, während das
|
||||||
|
echte `veth20` sauber hochkam: „failed" bei funktionierendem Netz.
|
||||||
|
**Fix:** nur die toten Stanzas entfernt (Backup je Container:
|
||||||
|
`/etc/network/interfaces.bak-20260901`), `lo`/`veth20`/`veth20.2` unangetastet.
|
||||||
|
**Beweis ist ein echter Neustart, nicht der Servicestatus:** `106` neu gestartet ⇒ **influxdb kam
|
||||||
|
nach 5 s von selbst hoch**, `networking active`, **null** fehlgeschlagene Units. Genau der Fall,
|
||||||
|
der vorher scheiterte.
|
||||||
|
🔑 **Nicht durch die Session verursacht:** `101` wurde vor dem Fix nie angefasst und zeigte dasselbe
|
||||||
|
Bild — die Container liefen nur 13+ Tage ohne Neustart, deshalb war es unsichtbar.
|
||||||
|
🟡 **Rest, bewusst liegen gelassen:** `run-rpc_pipefs.mount` (101, 150) und
|
||||||
|
`proxmox-regenerate-snakeoil.service` (108) — vorbestehend, ohne Bezug zu Netz oder DNS.
|
||||||
|
3. ✅ **ERLEDIGT 2026-09-01 (im selben Fenster aufgetaucht): LXC 302 war zu 100 % voll** (62/65 GB),
|
||||||
|
Rootfs `+30G` online gewachsen ⇒ 95 GB / 69 %, MariaDB lief durch. 🔴 **Das ist ein Puffer, kein
|
||||||
|
Fix:** 59 GB davon sind die `homeassistant`-DB (`states.ibd` allein **41 GB**), die unbegrenzt
|
||||||
|
wächst (~1 GB/Tag) — die dauerhafte Lösung ist HA-seitig und liegt in **TP40**.
|
||||||
|
4. ✅ **ERLEDIGT 2026-09-01: Resolver-Sweep durchgezogen — pve UND NAS.** **pve:** alle 13 LXCs
|
||||||
|
(`101,102,105,106,107,108,110,111,112,130,150,302,400`) tragen `nameserver 10.40.20.1`, **kein
|
||||||
|
`.41.254` mehr** — nicht nur die fünf geänderten. **NAS (DS923) via Portainer-API ep14:** alle
|
||||||
|
20 Container gelistet, keiner mit `.41.254`-DNS-Override; alle laufenden lösen über den
|
||||||
|
Embedded-Resolver (`127.0.0.11`) in **66–110 ms** auf (rc=0), inkl. Grenzfall `gitea` (erstellt
|
||||||
|
2026-07-10, um den Host-Fix herum) — **kein eingefrorener Dead-Resolver**, kein Recreate nötig.
|
||||||
|
NAS-Host `/etc/resolv.conf` = `10.40.20.1`. Als **wiederkehrende Kontrolle** bleibt der Sweep als
|
||||||
|
CLAUDE.md-Gotcha verankert (pve-Einzeiler + Synology-DSM-Fallstrick von 2026-07-10).
|
||||||
|
5. ✅ **ERLEDIGT 2026-09-01: Abnahme-Regel festgeschrieben.** „Vor jedem geplanten LXC-Neustart
|
||||||
|
`systemctl --failed` lesen und danach die **Ports gegen vorher** vergleichen" steht als
|
||||||
|
CLAUDE.md-Gotcha (Fall `influxdb2` wäre sonst still durchgerutscht).
|
||||||
|
|
||||||
|
#### Abhängigkeiten
|
||||||
|
|
||||||
|
- Keine blockierenden. Punkt 1 brauchte **DB-Credentials** (siehe **TP30**, Credential-Bestand).
|
||||||
|
- Punkt 2 war unabhängig und lief zuerst.
|
||||||
|
|
||||||
|
#### Abgrenzung
|
||||||
|
|
||||||
|
- **Nicht** TP16.3: dort geht es um cloudflared/Tunnel: der DNS-Fund kam nur *dabei* ans Licht.
|
||||||
|
- **Nicht** TP14.2a: das war 2026-07-10 derselbe Fehlertyp an **anderen** Hosts (NAS + LXC 400) und
|
||||||
|
ist abgeschlossen. **Dass er hier erneut auftrat, ist genau die Begründung für Punkt 4:**
|
||||||
|
die Klasse wurde damals an den bekannten Stellen behoben, nie im Bestand gesucht.
|
||||||
|
- **Nicht** TP31/TP34 (Caddy) und nicht TP11 (Monitoring) — obwohl gilt: ein Monitoring, das
|
||||||
|
DB-Verbindungszeiten kennt, hätte diesen Fall Monate früher gezeigt.
|
||||||
|
- **Nicht** TP40: der HA-Recorder-Wildwuchs (Punkt 3) ist HA-seitig und ein eigenes TP.
|
||||||
|
|||||||
@@ -46,10 +46,17 @@ liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur d
|
|||||||
🚫 **§6 (Abbau) bewusst NICHT** — die drei Alttunnel bleiben als Rückfallebene (healthy/8).
|
🚫 **§6 (Abbau) bewusst NICHT** — die drei Alttunnel bleiben als Rückfallebene (healthy/8).
|
||||||
🔴 **Christoph hat den Flip ausdrücklich vorgezogen freigegeben** („aus Gründen"); die 7-Tage-Regel
|
🔴 **Christoph hat den Flip ausdrücklich vorgezogen freigegeben** („aus Gründen"); die 7-Tage-Regel
|
||||||
betrifft ohnehin §6, nicht den Flip.
|
betrifft ohnehin §6, nicht den Flip.
|
||||||
|
- 🆕 **TP39 ABGESCHLOSSEN + archiviert (2026-09-01):** letzter offener Punkt — der Resolver-Sweep —
|
||||||
|
ist durch: **pve alle 13 LXCs** auf `10.40.20.1`, und die **DS923-Container via Portainer** (ep14)
|
||||||
|
gegengeprüft — kein `.41.254`-Override, alle laufenden lösen in **66–110 ms** auf (inkl. Grenzfall
|
||||||
|
`gitea`, erstellt 2026-07-10), kein eingefrorener Dead-Resolver, kein Recreate nötig. Die
|
||||||
|
Abnahme-Regel („vor jedem LXC-Reboot `systemctl --failed` + Port-Vergleich") steht als
|
||||||
|
CLAUDE.md-Gotcha, der Sweep ist als wiederkehrende Kontrolle dort verankert. **Volltext → Archiv.**
|
||||||
|
🔴 Rest offen nur in **anderen** TPs: root-DB-PW-Rotation (→ TP30), HA-Recorder-Retention (→ TP40).
|
||||||
- 🆕 **TP39 fast durch (2026-09-01):** `skip-name-resolve` auf der MariaDB **aktiviert** (mysql.user
|
- 🆕 **TP39 fast durch (2026-09-01):** `skip-name-resolve` auf der MariaDB **aktiviert** (mysql.user
|
||||||
vorher geprüft — kein Hostname-Grant, gefahrlos; Wirkung: gitea/vw/hass 0 von 36 frischen Anfragen
|
vorher geprüft — kein Hostname-Grant, gefahrlos; Wirkung: gitea/vw/hass 0 von 36 frischen Anfragen
|
||||||
langsam). LXC 302 war **100 % voll** → `+30G` online (95 GB/69 %). 🔴 **root-DB-Passwort dabei ins
|
langsam). LXC 302 war **100 % voll** → `+30G` online (95 GB/69 %). 🔴 **root-DB-Passwort dabei ins
|
||||||
Transkript geraten** (`.my.cnf` ohne `=`), zu rotieren (→ TP30). Offen in TP39: nur noch der Sweep.
|
Transkript geraten** (`.my.cnf` ohne `=`), zu rotieren (→ TP30).
|
||||||
- 🆕 **TP40 angelegt (2026-09-01, User-Okay):** HA-Recorder-Retention — die `homeassistant`-DB frisst
|
- 🆕 **TP40 angelegt (2026-09-01, User-Okay):** HA-Recorder-Retention — die `homeassistant`-DB frisst
|
||||||
59 GB (`states.ibd` **41 GB**), unbegrenzt gewachsen. Das `+30G` aus TP39 ist ein Puffer; die
|
59 GB (`states.ibd` **41 GB**), unbegrenzt gewachsen. Das `+30G` aus TP39 ist ein Puffer; die
|
||||||
dauerhafte Lösung (`purge_keep_days`, `exclude`, `purge repack`) ist HA-seitig und **Christophs
|
dauerhafte Lösung (`purge_keep_days`, `exclude`, `purge repack`) ist HA-seitig und **Christophs
|
||||||
@@ -259,6 +266,35 @@ liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur d
|
|||||||
in den TP5-Kollektor (`10.40.20.18:514`); `/system logging` steht unter der **27. ComplianceRule**
|
in den TP5-Kollektor (`10.40.20.18:514`); `/system logging` steht unter der **27. ComplianceRule**
|
||||||
`system-logging`. Vorher nur Ringpuffer → ein seit Wochen gemeldeter iPhone-Abbruch war rückwirkend
|
`system-logging`. Vorher nur Ringpuffer → ein seit Wochen gemeldeter iPhone-Abbruch war rückwirkend
|
||||||
nicht diagnostizierbar.
|
nicht diagnostizierbar.
|
||||||
|
- ⚖️ **TP25 Fund E — Hebel 1 ZURÜCKGEBAUT, Entscheidung faellt am 2026-09-02 (Stand 09-01 09:2x):**
|
||||||
|
Zwei Sessions haben denselben Fall bewertet und kamen zu entgegengesetzten Schluessen. **Aufgeloest
|
||||||
|
zugunsten der Kollektor-Messung:**
|
||||||
|
- Die Nacht-Session las `get_log … sinceMinutes=1440` → `total 0` und schloss auf „geheilt". Das ist
|
||||||
|
der **fluechtige Ringpuffer des Routers**: live nachgemessen **1000 Zeilen, aeltester Eintrag
|
||||||
|
01.09. 00:38:58** — keine 9 h Tiefe. Der Core-Reboot 14:36 hatte ihn geleert, der 31.08. Vormittag
|
||||||
|
war darin **nicht sichtbar**. 🔴 Genau die Falle, wegen der am 30.08. der persistente Kollektor
|
||||||
|
eingerichtet wurde.
|
||||||
|
- Im **Kollektor** stehen fuer 08:09–14:36 (Hebel 1 **allein**, vor dem Upgrade) **124×
|
||||||
|
`reauthenticating`**, Stundenverteilung 09h=1 · 11h=2 · 12h=20 · 13h=31 · 14h=70, **alle vom
|
||||||
|
iPhone allein** (= Client-Befund nach der eigenen Merkregel „viele MACs = Infrastruktur"), dazu
|
||||||
|
Christophs **zwei erlebte Ausfaelle** um 13:16 und 14:23. Zwischen 09:00 und 14:36 gab es
|
||||||
|
**keinen Reboot**, der sie erklaeren koennte.
|
||||||
|
- ⇒ Hebel 1 hat im upgrade-freien Fenster **nichts** bewirkt; der Einbruch faellt exakt auf 7.24.1.
|
||||||
|
**Deshalb am 2026-09-01 zurueckgebaut** (`ft-over-ds=yes`, Provisionierung nachgezogen, frische
|
||||||
|
DHCP-Lease abgenommen, Transaktion **`zurueckgebaut`**, **Compliance 140/140**). Der Rueckbau **ist
|
||||||
|
das Experiment**: bleibt es ruhig, war 7.24.1 die Ursache; kehrt das Haemmern zurueck, hatte die
|
||||||
|
Nacht-Session recht und Hebel 1 wird als neue Transaktion erneut gezogen. **Bis zur Messung am
|
||||||
|
2026-09-02 frueh committet niemand.** Handoff:
|
||||||
|
[`handoff-20260901-fund-e-hebel1-zurueckgebaut.md`](handoff-20260901-fund-e-hebel1-zurueckgebaut.md).
|
||||||
|
- 🔴 **ABER: neuer Teilbefund am 23:02 (2026-08-31) — `ap2` unterperformt, NICHT FT.** Christoph am
|
||||||
|
Schreibtisch, 5G, kein Telefonat. Log: iPhone `F2:62:4C:E1:AF:09` ping-pongt im Sekundentakt
|
||||||
|
`cap-wifi5 ↔ cap-wifi6` = **beide Radios von ap2** (5G 5220 ↔ 2,4G ch11/2462, Band-Steering-Thrash
|
||||||
|
auf demselben AP), `disconnected, not responding` um 22:37:40 und 23:01:00. Feldstärke **−75…−88 dBm
|
||||||
|
— bei laut Christoph 2 m Abstand** (ap2 auf 2,3 m, gleicher Raum). Bei 2 m wären −35…−45 normal.
|
||||||
|
Aktuell **0 Clients auf ap2**, alle 29 auf ap3. ⇒ kein Coverage-/FT-Problem, sondern **ap2s Funk
|
||||||
|
selbst** (RF/Antenne/HW) und/oder die **DTU-Störung auf ap2/ch11** (Transaktion `TP17.1-dtu-pin-ap2`,
|
||||||
|
−59 dBm auf ap2s 2,4-Radio). Als eigener 🔬-Unterpunkt geführt, In-situ zu messen. Handoff:
|
||||||
|
[`handoff-20260901-tp25-ap2-verdacht.md`](handoff-20260901-tp25-ap2-verdacht.md).
|
||||||
- 🔴 **TP25 Fund E — Hebel 1 ist GESCHEITERT (Stand 2026-08-31 nachmittags):** `sec-main` steht am
|
- 🔴 **TP25 Fund E — Hebel 1 ist GESCHEITERT (Stand 2026-08-31 nachmittags):** `sec-main` steht am
|
||||||
Core auf **`ft=yes ft-over-ds=no`** (seit 08:09), aber das Symptom blieb: **124× `reauthenticating`
|
Core auf **`ft=yes ft-over-ds=no`** (seit 08:09), aber das Symptom blieb: **124× `reauthenticating`
|
||||||
nach dem Eingriff** und **zwei von Christoph erlebte Ausfälle** — 13:16 (Videocall bricht ab,
|
nach dem Eingriff** und **zwei von Christoph erlebte Ausfälle** — 13:16 (Videocall bricht ab,
|
||||||
@@ -426,7 +462,7 @@ nachmessen und dann entscheiden**. Blocker gibt es keine mehr. TP5 ist in der Na
|
|||||||
> | TP20.1 | 🔜 | Vaultwarden → Platform-PG | — |
|
> | TP20.1 | 🔜 | Vaultwarden → Platform-PG | — |
|
||||||
> | TP23 | ✅ | DNS-Policy (Stufe 1+2 ✅) | 2026-08-26 |
|
> | TP23 | ✅ | DNS-Policy (Stufe 1+2 ✅) | 2026-08-26 |
|
||||||
> | TP24 | 🔜 | DC-USV | — |
|
> | TP24 | 🔜 | DC-USV | — |
|
||||||
> | TP25 | 🔬 | WLAN-Stabilisierung (Kern ✅) — **Fund E offen, Hebel 1 `ft-over-ds=no` läuft, Messung bis 09-01** | 2026-08-31 |
|
> | TP25 | 🔬 | WLAN-Stabilisierung (Kern ✅) — **Fund E: Hebel 1 widerlegt + zurückgebaut, Messung bis 09-02; ap2 unterperformt (2 m/−80, In-situ)** | 2026-09-01 |
|
||||||
> | TP28 | ✅ | WLAN/CAPsMAN — dritter AP `ap3` (cAP ax) **live** | 2026-08-30 |
|
> | TP28 | ✅ | WLAN/CAPsMAN — dritter AP `ap3` (cAP ax) **live** | 2026-08-30 |
|
||||||
> | TP29 | 💡 | Anwesenheitserkennung (Idee) | — |
|
> | TP29 | 💡 | Anwesenheitserkennung (Idee) | — |
|
||||||
> | TP30 | 🔜 | Credentials (Etappe 1 ✅, Rest gebündelt) | — |
|
> | TP30 | 🔜 | Credentials (Etappe 1 ✅, Rest gebündelt) | — |
|
||||||
@@ -438,9 +474,8 @@ nachmessen und dann entscheiden**. Blocker gibt es keine mehr. TP5 ist in der Na
|
|||||||
> | TP36 | 🔜 | SSoT via Nautobot für teilprojekte.md-Live-Daten + Datei-Aufteilung | — |
|
> | TP36 | 🔜 | SSoT via Nautobot für teilprojekte.md-Live-Daten + Datei-Aufteilung | — |
|
||||||
> | TP37 | 🔜 | Nautobot als Netzwerkdoku: Hosts/Container/Dienste + CF-Connectoren (Okay 08-30) | — |
|
> | TP37 | 🔜 | Nautobot als Netzwerkdoku: Hosts/Container/Dienste + CF-Connectoren (Okay 08-30) | — |
|
||||||
> | TP38 | 🔜 | OOB-Mgmt: untagged-VLAN99-Port je Switch | — |
|
> | TP38 | 🔜 | OOB-Mgmt: untagged-VLAN99-Port je Switch | — |
|
||||||
> | TP39 | ⏳ | LXC-Hygiene pve (Resolver ✅, `networking.service` ✅, `skip-name-resolve` ✅, Resize ✅ 09-01 — offen: nur Sweep) | — |
|
|
||||||
> | TP40 | 🔜 | HA-Recorder-Retention: 41 GB `states` beschneiden (Okay 09-01) | — |
|
> | TP40 | 🔜 | HA-Recorder-Retention: 41 GB `states` beschneiden (Okay 09-01) | — |
|
||||||
> | — | — | **34 archivierte TPs** in `teilprojekte-archiv.md` | — |
|
> | — | — | **35 archivierte TPs** in `teilprojekte-archiv.md` (inkl. TP39 ✅ 2026-09-01) | — |
|
||||||
|
|
||||||
### TP5.1 — DNS-Visibility & Flow-Observability für Low-Trust-Geräte (Airfryer-Fall) ▸ vorgemerkt
|
### TP5.1 — DNS-Visibility & Flow-Observability für Low-Trust-Geräte (Airfryer-Fall) ▸ vorgemerkt
|
||||||
- **Kontext (2026-07-08/09):** Airfryer „airschreier" (Philips/Versuni, ESP, `10.40.30.180`) bekam per DHCP-Option 6 `dns 1.1.1.1` als Override, weil das OTA-Update über den ap1-DoH-Gateway-Pfad nicht durchging (DoH-Latenz beim primitiven ESP-Stack — **kein** Content-Block, via Gateway-Logs bewiesen, s. `memory/ref_esp_ota_doh_not_block`). Nebenwirkung: public **1.1.1.1 = anonymer Consumer-Resolver ≠ accountgebundener Gateway-DoH** (`px35ynlol3.cloudflare-gateway.com`) → **DNS-Sicht auf das Gerät weg**, Gerät umgeht zudem die Filterung.
|
- **Kontext (2026-07-08/09):** Airfryer „airschreier" (Philips/Versuni, ESP, `10.40.30.180`) bekam per DHCP-Option 6 `dns 1.1.1.1` als Override, weil das OTA-Update über den ap1-DoH-Gateway-Pfad nicht durchging (DoH-Latenz beim primitiven ESP-Stack — **kein** Content-Block, via Gateway-Logs bewiesen, s. `memory/ref_esp_ota_doh_not_block`). Nebenwirkung: public **1.1.1.1 = anonymer Consumer-Resolver ≠ accountgebundener Gateway-DoH** (`px35ynlol3.cloudflare-gateway.com`) → **DNS-Sicht auf das Gerät weg**, Gerät umgeht zudem die Filterung.
|
||||||
@@ -1428,7 +1463,7 @@ des Dimmers (= Lichtausfall in Diele UG/Wohnzimmer) wurde daraufhin **nicht** au
|
|||||||
- **Abh.:** keine harten. **TP15 ✅** (die zu versorgende Hardware steht und hat DC-Eingänge). Verwandt: **TP18** (Garage-Nodes brauchen je Site eine Stromversorgung), **TP11** (USV-Zustand ins Monitoring). **Kein Blocker für TP5/TP6.**
|
- **Abh.:** keine harten. **TP15 ✅** (die zu versorgende Hardware steht und hat DC-Eingänge). Verwandt: **TP18** (Garage-Nodes brauchen je Site eine Stromversorgung), **TP11** (USV-Zustand ins Monitoring). **Kein Blocker für TP5/TP6.**
|
||||||
- **Historie:** war bis 2026-08-16 Unterpunkt von TP15 („🔋 DC-USV: MeanWell LRS-150-48 + DDR-120-48 + LiFePO4 20Ah (~€190), 48V-Bus; CRS326 DC-input passt"). Vollständige Recherche inkl. Schaltbild, Effizienzvergleich und Gerätetabelle: `docs/hw-refresh-requirements.md §9` (+ §10 D/E/F für die offenen Fragen).
|
- **Historie:** war bis 2026-08-16 Unterpunkt von TP15 („🔋 DC-USV: MeanWell LRS-150-48 + DDR-120-48 + LiFePO4 20Ah (~€190), 48V-Bus; CRS326 DC-input passt"). Vollständige Recherche inkl. Schaltbild, Effizienzvergleich und Gerätetabelle: `docs/hw-refresh-requirements.md §9` (+ §10 D/E/F für die offenen Fragen).
|
||||||
|
|
||||||
### TP25 — WLAN-Stabilisierung ▸ 🔬 **FUND E OFFEN, HEBEL 1 LÄUFT (2026-08-31 08:09): `ft-over-ds=no` auf `sec-main`, Messung bis 2026-09-01** · Kern erledigt: 🟢 **(2026-08-22) Dead Spot Terrasse repariert** (43 % → 9 % Verlust, 20,4 s → 1,0 s). **Fund F ✅ aufgelöst (08-24, geräteseitig — kein Netzfehler)**, **5-GHz-Umfeldscan ✅ (08-24)**, Kanalplan für AP 3 ✅ gerechnet. Offen nur noch die Umsetzung, wenn der dritte AP kommt. Nicht mehr kritischer Pfad — Sammel-TP für Christophs Beobachtungen 1–6
|
### TP25 — WLAN-Stabilisierung ▸ 🔬 **FUND E: Hebel 1 widerlegt (124× im upgrade-freien Fenster) und am 2026-09-01 ZURÜCKGEBAUT — Entscheidung faellt mit der Messung am 09-02; NEU: ap2 unterperformt (2 m/−80 dBm, 23:02-Befund) als eigener In-situ-Unterpunkt** · Kern erledigt: 🟢 **(2026-08-22) Dead Spot Terrasse repariert** (43 % → 9 % Verlust, 20,4 s → 1,0 s). **Fund F ✅ aufgelöst (08-24, geräteseitig — kein Netzfehler)**, **5-GHz-Umfeldscan ✅ (08-24)**, Kanalplan für AP 3 ✅ gerechnet. Offen nur noch die Umsetzung, wenn der dritte AP kommt. Nicht mehr kritischer Pfad — Sammel-TP für Christophs Beobachtungen 1–6
|
||||||
> 📚 **Kondensiert am 2026-08-23 (Doku-Session, Punkt F).** Dieser Abschnitt war mit 394 Zeilen
|
> 📚 **Kondensiert am 2026-08-23 (Doku-Session, Punkt F).** Dieser Abschnitt war mit 394 Zeilen
|
||||||
> 18 % der Datei. Die **Langfassung steht vollständig und unverändert** im Archiv:
|
> 18 % der Datei. Die **Langfassung steht vollständig und unverändert** im Archiv:
|
||||||
> [`teilprojekte-archiv.md` → TP25 (Langfassung)](teilprojekte-archiv.md#tp25-lang) — Messchronik (A)–(G),
|
> [`teilprojekte-archiv.md` → TP25 (Langfassung)](teilprojekte-archiv.md#tp25-lang) — Messchronik (A)–(G),
|
||||||
@@ -1800,6 +1835,53 @@ die Redundanzfrage oben.
|
|||||||
- **Abh.:** TP22 ✅ (GC-Deploy-Pipeline). Verwandt **TP3.2** (`docs/wifi-p750w-coverage-and-map.md`),
|
- **Abh.:** TP22 ✅ (GC-Deploy-Pipeline). Verwandt **TP3.2** (`docs/wifi-p750w-coverage-and-map.md`),
|
||||||
**TP29** (nutzt dieselbe Datenquelle als Sensor). **Kein Blocker für irgendetwas.**
|
**TP29** (nutzt dieselbe Datenquelle als Sensor). **Kein Blocker für irgendetwas.**
|
||||||
|
|
||||||
|
#### 🔬 Fund E — 2026-09-01: der `ap2`-Teilbefund (gültig) und eine widerlegte Heilungs-Wertung
|
||||||
|
|
||||||
|
**Anlass:** Christoph meldete **2026-08-31 23:02** eine Störung am Schreibtisch (5G, iPhone, kein
|
||||||
|
Telefonat). Analyse (alles read-only am Manager `crs326-core`):
|
||||||
|
|
||||||
|
- **AP-Karte** (stabil seit letztem CAP-Rejoin 15:57, kein Rejoin danach — Attribution belastbar):
|
||||||
|
`cap-wifi5/6 = ap2`, `cap-wifi3/4 = ap3`, `cap-wifi1/2 = ap1` (funkstill, Radios da, 0 Clients).
|
||||||
|
- **23:02-Ereignis:** iPhone `F2:62:4C:E1:AF:09` ping-pongt im Sekundentakt `cap-wifi5 ↔ cap-wifi6`
|
||||||
|
= **ap2s 5G (5220) ↔ ap2s 2,4G (ch11/2462)** — Band-Steering-Thrash auf **demselben** AP, plus
|
||||||
|
`disconnected, not responding` um 22:37:40 (−76) und **23:01:00** (−82). Feldstärke der Roams
|
||||||
|
**−75…−88 dBm**.
|
||||||
|
- 🔴 **Christophs Fakt kippt die Coverage-Deutung:** iPhone und **ap2 nur 2 m** entfernt, gleicher
|
||||||
|
Raum, ap2 auf 2,3 m. Bei 2 m Sicht wären −35…−45 dBm normal. −80 auf 2 m ist **kein** Coverage-
|
||||||
|
und **kein** FT-Problem. Dazu: **aktuell 0 Clients auf ap2**, alle 29 auf ap3 — die Clients *meiden*
|
||||||
|
ap2. ⇒ **ap2s Funk selbst unterperformt** (RF/Antenne/HW) und/oder die **DTU-Störung auf ap2/ch11**
|
||||||
|
(Transaktion `TP17.1-dtu-pin-ap2`, Wechselrichter `54:F2:9F:12:51:F0` mit −59 dBm auf ap2s 2,4-Radio).
|
||||||
|
- **In-situ zu messen** (nachts nicht möglich — Phone idle auf ap3): Registration-Signal live prüfen,
|
||||||
|
während ein Client auf ap2 hängt; Kandidaten-Eingriffe — DTU-Pin lösen/verlegen, `dirtyvader-main`
|
||||||
|
auf ap2 temporär deaktivieren (ap3 übernimmt den Schreibtisch), ap2-Antenne/HW prüfen. **Keine
|
||||||
|
Änderung ohne diese Messung.**
|
||||||
|
|
||||||
|
🔴 **WIDERRUFEN am 2026-09-01 vormittags — der zweite Teil dieses Abschnitts war ein Messfehler.**
|
||||||
|
Ursprünglich stand hier: „Fund E ist im sauberen Fenster geheilt — 0× `reauthenticating` seit dem
|
||||||
|
14:36-Reboot (`sinceMinutes=1440`, total 0), also hat Hebel 1 sein Ziel erreicht."
|
||||||
|
|
||||||
|
**Warum das nicht trägt:** `get_log` liest den **flüchtigen Ringpuffer des Routers**, nicht den
|
||||||
|
Kollektor. Live nachgemessen fasst er **1000 Zeilen und reicht bis 01.09. 00:38:58 zurück** — keine
|
||||||
|
9 Stunden. Der Core-Reboot um 14:36 hatte ihn geleert; der 31.08. Vormittag war darin gar nicht
|
||||||
|
enthalten. `total 0` hieß **„im Puffer nichts", nicht „in 24 h nichts"**. Das ist exakt die Falle,
|
||||||
|
wegen der am 30.08. das persistente Logging gebaut wurde.
|
||||||
|
|
||||||
|
**Was der Kollektor zeigt:** im upgrade-freien Fenster 08:09–14:36 (Hebel 1 **allein**) **124×
|
||||||
|
`reauthenticating`** — 09h=1 · 11h=2 · 12h=20 · 13h=31 · 14h=70, **alle vom iPhone allein**, dazu
|
||||||
|
Christophs zwei erlebte Ausfälle 13:16 und 14:23. Zwischen 09:00 und 14:36 lag **kein Reboot**.
|
||||||
|
⇒ Hebel 1 wurde am 2026-09-01 **zurückgebaut**; der Rückbau ist das entscheidende Experiment
|
||||||
|
(s. Ist-Stand-Block oben).
|
||||||
|
|
||||||
|
✅ **Der `ap2`-Teilbefund oben bleibt davon unberührt und gültig** — er ist unabhängig gemessen und
|
||||||
|
erklärt die 23:02-Störung, die weder FT noch Coverage erklärt.
|
||||||
|
|
||||||
|
**Commit-Weg (wartet auf Christophs Go — git-push-Kette):** Template `nautobot/mikrotik_routeros.j2`
|
||||||
|
**Z. 220** `sec-main` von `ft-over-ds=yes` → `ft-over-ds=no`; dann Template-Repo nach Nautobot syncen,
|
||||||
|
`gc-configplan.py --refresh-compliance` (Backup→Intended→Compliance), dann
|
||||||
|
`gc-transaktion.py commit --change-id TP25-fund-e-ft-over-ds`. Danach `wifi-security` wieder driftfrei.
|
||||||
|
🔴 Kreuzt git-push (Backup-Guard + Commit-Hinweis-Regel) und Live-Nautobot-Jobs — **nicht autonom.**
|
||||||
|
Handoff: [`handoff-20260901-tp25-ap2-verdacht.md`](handoff-20260901-tp25-ap2-verdacht.md).
|
||||||
|
|
||||||
<a id="tp28"></a>
|
<a id="tp28"></a>
|
||||||
|
|
||||||
### TP28 — WLAN über CAPsMAN auf `crs326-core` ▸ ✅ **ap3 LIVE (2026-08-30)** — wieder geöffnet und durchgezogen
|
### TP28 — WLAN über CAPsMAN auf `crs326-core` ▸ ✅ **ap3 LIVE (2026-08-30)** — wieder geöffnet und durchgezogen
|
||||||
@@ -2732,78 +2814,6 @@ folgenden Absicherungen dazu, und die Entscheidung darüber in die Umsetzungs-Se
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
### TP39 — LXC-Hygiene auf pve: Resolver-Altlasten, `networking.service`, DB-Reverse-Lookup ▸ 🔜 **ANGELEGT 2026-09-01 (User-Okay erteilt)**
|
|
||||||
|
|
||||||
**Auslöser:** ein 10-Sekunden-Hänger auf `gitea`, gefunden am Rand des TP16.3-§5-Flips. Er hatte mit
|
|
||||||
dem Flip nichts zu tun, war aber nur deshalb sichtbar, weil zum ersten Mal jemand systematisch
|
|
||||||
gemessen hat. Beim Beheben kam eine zweite, unabhängige Altlast zum Vorschein. Beide sind
|
|
||||||
**Hygiene an denselben pve-LXCs** und gehören in **ein** Wartungsfenster — deshalb ein TP, nicht zwei.
|
|
||||||
|
|
||||||
#### Was am 2026-09-01 bereits erledigt ist (Ausgangslage, nicht Aufgabe)
|
|
||||||
|
|
||||||
- **Ursache des Hängers:** MariaDB (LXC **302**, `10.40.20.23`) hatte `skip-name-resolve`
|
|
||||||
**auskommentiert** ⇒ Reverse-Lookup bei **jeder neuen Verbindung**; `/etc/resolv.conf` zeigte auf
|
|
||||||
den **toten** `10.40.41.254` (VLAN1-Altschema). **Gemessen: 10.010 ms je Lookup.**
|
|
||||||
Pool-Verbindungen waren schnell ⇒ das Symptom wirkte sporadisch.
|
|
||||||
- **Blast-Radius, per Verbindungstabelle belegt:** an dieser DB hängen **Vaultwarden (`.127`),
|
|
||||||
Home Assistant (`.105`) und gitea (`.157`)**.
|
|
||||||
- **Fix ausgerollt** (`pct set <id> --nameserver 10.40.20.1` + Reboot) für **fünf** LXCs:
|
|
||||||
`302 mariadb`, `102 mqtt5`, `106 influxdb2`, `107 redis`, `150 iob-exposed`.
|
|
||||||
**Nachher: Lookup 21–24 ms, gitea 0 von 25 Proben langsam** (vorher ~10 % bei 10,1 s).
|
|
||||||
|
|
||||||
#### Scope (was dieses TP noch zu tun hat)
|
|
||||||
|
|
||||||
1. ✅ **ERLEDIGT 2026-09-01: `skip-name-resolve` aktiviert.** Vorher `mysql.user` gelesen (User gab
|
|
||||||
den DB-Zugang per `/root/.my.cnf`) — **kein einziger Grant lautet auf einen DNS-Hostnamen**, alle
|
|
||||||
sind `%` / IP-Literal / `localhost`. Damit kann `skip-name-resolve` niemanden aussperren; der
|
|
||||||
Reverse-Lookup war reiner Ballast. Gesetzt als eigenes Drop-in
|
|
||||||
`/etc/mysql/mariadb.conf.d/90-skip-name-resolve.cnf` (nicht die `#`-Zeile in `50-server.cnf`
|
|
||||||
editiert — Paket-Update-stabil), `@@skip_name_resolve=1` nach Neustart verifiziert.
|
|
||||||
**Wirkung: gitea/vw/hass je 0 von 12 frischen Anfragen langsam, max 0,25 s.** Alle drei Clients
|
|
||||||
danach wieder verbunden. Die Ursache ist damit **beseitigt**, nicht nur entschärft.
|
|
||||||
🔴 **Sicherheitsvorfall dabei:** die `.my.cnf` trug `password <wert>` **ohne `=`**, die Maskierung
|
|
||||||
griff nicht ⇒ das **root-DB-Passwort ist ins Transkript geraten** und gehört rotiert (→ TP30).
|
|
||||||
2. ✅ **ERLEDIGT 2026-09-01: `networking.service` + `ifupdown-wait-online.service` in `101`, `102`,
|
|
||||||
`106`, `107` repariert.** **Ursache — dieselbe Altlast wie beim Resolver:** in
|
|
||||||
`/etc/network/interfaces` standen noch `auto`-Stanzas aus dem **alten VLAN1-Schema**
|
|
||||||
(`eth0` → `10.40.41.x`) und aus früheren Versuchen (`veth16`, `veth24`, ein Tippfehler `eth01`) —
|
|
||||||
**alle auf Interfaces, die es im Container nicht gibt.** `ifup -a` scheiterte daran, während das
|
|
||||||
echte `veth20` sauber hochkam: „failed" bei funktionierendem Netz.
|
|
||||||
**Fix:** nur die toten Stanzas entfernt (Backup je Container:
|
|
||||||
`/etc/network/interfaces.bak-20260901`), `lo`/`veth20`/`veth20.2` unangetastet.
|
|
||||||
**Beweis ist ein echter Neustart, nicht der Servicestatus:** `106` neu gestartet ⇒ **influxdb kam
|
|
||||||
nach 5 s von selbst hoch**, `networking active`, **null** fehlgeschlagene Units. Genau der Fall,
|
|
||||||
der vorher scheiterte.
|
|
||||||
🔑 **Nicht durch die Session verursacht:** `101` wurde vor dem Fix nie angefasst und zeigte dasselbe
|
|
||||||
Bild — die Container liefen nur 13+ Tage ohne Neustart, deshalb war es unsichtbar.
|
|
||||||
🟡 **Rest, bewusst liegen gelassen:** `run-rpc_pipefs.mount` (101, 150) und
|
|
||||||
`proxmox-regenerate-snakeoil.service` (108) — vorbestehend, ohne Bezug zu Netz oder DNS.
|
|
||||||
3. ✅ **ERLEDIGT 2026-09-01 (im selben Fenster aufgetaucht): LXC 302 war zu 100 % voll** (62/65 GB),
|
|
||||||
Rootfs `+30G` online gewachsen ⇒ 95 GB / 69 %, MariaDB lief durch. 🔴 **Das ist ein Puffer, kein
|
|
||||||
Fix:** 59 GB davon sind die `homeassistant`-DB (`states.ibd` allein **41 GB**), die unbegrenzt
|
|
||||||
wächst (~1 GB/Tag) — die dauerhafte Lösung ist HA-seitig und liegt in **TP40**.
|
|
||||||
4. 🟡 **Resolver-Sweep als wiederkehrende Kontrolle**, nicht als Einmalaktion — und über pve hinaus:
|
|
||||||
die **NAS-Container** sind nach derselben Logik zu prüfen (der DSM-Fallstrick von 2026-07-10:
|
|
||||||
„Allgemein"-DNS ≠ was `dockerd` liest, laufende Container frieren den Upstream beim Erstellen ein).
|
|
||||||
Sweep über pve: `for c in $(pct list|awk 'NR>1{print $1}'); do pct exec $c -- grep ^nameserver /etc/resolv.conf; done`
|
|
||||||
5. 🟡 **Abnahme-Regel festschreiben:** vor jedem geplanten LXC-Neustart `systemctl --failed` lesen
|
|
||||||
und danach die **Ports gegen vorher** vergleichen — sonst verliert man still einen Dienst
|
|
||||||
(genau so wäre `influxdb2` durchgerutscht).
|
|
||||||
|
|
||||||
#### Abhängigkeiten
|
|
||||||
|
|
||||||
- Keine blockierenden. Punkt 1 braucht **DB-Credentials** (siehe **TP30**, Credential-Bestand).
|
|
||||||
- Punkt 2 ist unabhängig und kann zuerst.
|
|
||||||
|
|
||||||
#### Abgrenzung
|
|
||||||
|
|
||||||
- **Nicht** TP16.3: dort geht es um cloudflared/Tunnel: der DNS-Fund kam nur *dabei* ans Licht.
|
|
||||||
- **Nicht** TP14.2a: das war 2026-07-10 derselbe Fehlertyp an **anderen** Hosts (NAS + LXC 400) und
|
|
||||||
ist abgeschlossen. **Dass er hier erneut auftrat, ist genau die Begründung für Punkt 3:**
|
|
||||||
die Klasse wurde damals an den bekannten Stellen behoben, nie im Bestand gesucht.
|
|
||||||
- **Nicht** TP31/TP34 (Caddy) und nicht TP11 (Monitoring) — obwohl gilt: ein Monitoring, das
|
|
||||||
DB-Verbindungszeiten kennt, hätte diesen Fall Monate früher gezeigt.
|
|
||||||
|
|
||||||
### TP40 — Home-Assistant-Recorder-Retention: die 41-GB-`states`-Tabelle beschneiden ▸ 🔜 **ANGELEGT 2026-09-01 (User-Okay erteilt)**
|
### TP40 — Home-Assistant-Recorder-Retention: die 41-GB-`states`-Tabelle beschneiden ▸ 🔜 **ANGELEGT 2026-09-01 (User-Okay erteilt)**
|
||||||
|
|
||||||
**Auslöser:** LXC 302 (MariaDB) lief am 2026-09-01 auf **100 %** voll. Sofortmassnahme war `+30G`
|
**Auslöser:** LXC 302 (MariaDB) lief am 2026-09-01 auf **100 %** voll. Sofortmassnahme war `+30G`
|
||||||
|
|||||||
@@ -8,7 +8,8 @@
|
|||||||
"reason": "TP25 Fund E Hebel 1: ft-over-ds=no auf sec-main. Nimmt die Aenderung vom 2026-08-17 zurueck; FT bleibt over-the-air via ft=yes. Baseline 93x reauthenticating, 93/93 vom iPhone F2:62:4C:E1:AF:09, 93/93 auf dirtyvader-main (einzige SSID mit ft=yes). 24h messen, dann committen oder Hebel 2 (ft=no).",
|
"reason": "TP25 Fund E Hebel 1: ft-over-ds=no auf sec-main. Nimmt die Aenderung vom 2026-08-17 zurueck; FT bleibt over-the-air via ft=yes. Baseline 93x reauthenticating, 93/93 vom iPhone F2:62:4C:E1:AF:09, 93/93 auf dirtyvader-main (einzige SSID mit ft=yes). 24h messen, dann committen oder Hebel 2 (ft=no).",
|
||||||
"started": "2026-08-31",
|
"started": "2026-08-31",
|
||||||
"expires": "2026-09-03",
|
"expires": "2026-09-03",
|
||||||
"state": "open",
|
"state": "rolledback",
|
||||||
"snapshot": "docs/transaktionen/TP25-fund-e-ft-over-ds.snapshot.rsc",
|
"snapshot": "docs/transaktionen/TP25-fund-e-ft-over-ds.snapshot.rsc",
|
||||||
"device_backup": "pre-tp25-funde-ftoverds.backup"
|
"device_backup": "pre-tp25-funde-ftoverds.backup",
|
||||||
|
"closed": "2026-09-01"
|
||||||
}
|
}
|
||||||
|
|||||||
13
docs/transaktionen/TP25-fund-e-ft-over-ds.rollback.rsc
Normal file
13
docs/transaktionen/TP25-fund-e-ft-over-ds.rollback.rsc
Normal file
@@ -0,0 +1,13 @@
|
|||||||
|
# Rueckbau-VORSCHLAG fuer TP25-fund-e-ft-over-ds (crs326-core, Scope wifi-security)
|
||||||
|
# Aus dem Snapshot vom 2026-08-31. NICHT ungeprueft deployen:
|
||||||
|
# `add`-Zeilen legen neu an, statt zu aendern — was hier gebraucht wird,
|
||||||
|
# ist in der Regel ein `set [find ...]`. Zeilen entsprechend anpassen.
|
||||||
|
|
||||||
|
/interface wifi security
|
||||||
|
add authentication-types=wpa3-psk ft=yes ft-over-ds=yes name=sec-main
|
||||||
|
add authentication-types=wpa2-psk,wpa3-psk disabled=no ft=no name=sec-infra
|
||||||
|
add authentication-types=wpa2-psk,wpa3-psk disabled=no ft=no name=sec-iot
|
||||||
|
add authentication-types=wpa2-psk,wpa3-psk ft=no name=sec-media
|
||||||
|
add authentication-types=wpa2-psk,wpa3-psk disabled=no ft=no name=\
|
||||||
|
sec-untrusted
|
||||||
|
add authentication-types=wpa2-psk,wpa3-psk disabled=no ft=no name=sec-guest
|
||||||
Reference in New Issue
Block a user