matt/echo6-docs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

auto: docs sync 2026-06-15T20:08:44+00:00

Browse source 
Files changed: .obsidian/workspace.json PHASE6_DECISION.md PLAN.md appservices.md archive_receiver_discovery.md archivist.md archivist_discovery.md argus.md docs/hardware/environment.md docs/services/services.md docs/software/recon.md echo6-landing-page-data-export.md hookshot_deployment_discovery.md hookshot_e2ee_discovery.md hookshot_payload_discovery.md hookshot_room_targeting_discovery.md matrix_host.md mautrix_signal.md pp_comparison.json projects/headscale-full-deployment.md projects/utility-caddy-initial-setup.md projects/vaultwarden-deployment.md runbooks/add-peertube-channel.md runbooks/authentik-oidc-application.md runbooks/proxmox-create-ubuntu-vm.md runbooks/proxmox-onboard-node.md runbooks/recon-operations.md runbooks/recon-service-integration.md scribd_session.json synapse.md synapse_retention_discovery.md
This commit is contained in:
echo6-autocommit 2026-06-15 20:08:44 +00:00
commit a5299d09a2
31 changed files with 80 additions and 29410 deletions
Download patch file Download diff file Expand all files Collapse all files

4
runbooks/add-peertube-channel.md
View file

@ -6,7 +6,7 @@ Add a YouTube channel to the PeerTube bulk import pipeline. Creates the PeerTube
## Prerequisites
- SSH access from CT 130 (RECON) → CT 110 (PeerTube): working
- SSH access from recon-vm (VM 1130) → CT 110 (PeerTube): working
- Sudoers: `/etc/sudoers.d/recon-mgmt` on CT 110 (allows zvx to run yt-dlp, psql, tee as peertube)
- YouTube cookies at `/opt/bulk-import/config/cookies.txt` on CT 110 (not stale)
@ -35,7 +35,7 @@ PRIORITY="M" # H, M, or L
### Step 1: Resolve Channel Info
```bash
# From CT 130 or cortex:
# From recon-vm or cortex:
ssh zvx@192.168.1.170 "sudo -u peertube /usr/local/bin/yt-dlp \
--cookies /opt/bulk-import/config/cookies.txt \
--print channel --print channel_url --print channel_id \

24
runbooks/authentik-oidc-application.md
View file

@ -4,7 +4,7 @@ Fully automated via Authentik API. No web UI interaction required.
**Prerequisite:** DNS must already exist for the service (run expose-service-contabo.md or expose-service-home.md first).
**Authentik instance:** https://auth.echo6.co (Contabo, 100.64.0.6)
**Authentik instance:** https://auth.echo6.co (Contabo, 100.64.0.1)
---
@ -40,7 +40,7 @@ These conflict with Authentik's internal OAuth2 endpoints and **cannot be used**
Create an API token from the Authentik admin account. This only needs to happen once — reuse the token across all OIDC setups.
```bash
ssh root@100.64.0.6 "docker exec authentik-server \
ssh root@100.64.0.1 "docker exec authentik-server \
ak create_token --user akadmin --identifier oidc-automation --expiring 2>/dev/null \
|| echo 'Token may already exist — check credentials file'"
```
@ -63,7 +63,7 @@ The API requires UUIDs for flows, scope mappings, and signing keys. These are st
### Authorization flow
```bash
ssh root@100.64.0.6 "curl -s \
ssh root@100.64.0.1 "curl -s \
-H 'Authorization: Bearer $AK_TOKEN' \
'$AK_API/flows/instances/?slug=default-provider-authorization-implicit-consent' \
| jq -r '.results[0].pk'"
@ -75,7 +75,7 @@ Store as `AUTH_FLOW_PK`.
```bash
# Get all scope mapping UUIDs at once
ssh root@100.64.0.6 "curl -s \
ssh root@100.64.0.1 "curl -s \
-H 'Authorization: Bearer $AK_TOKEN' \
'$AK_API/propertymappings/provider/scope/?ordering=scope_name' \
| jq -r '.results[] | select(.scope_name == \"openid\" or .scope_name == \"email\" or .scope_name == \"profile\" or .scope_name == \"offline_access\") | \"\(.scope_name): \(.pk)\"'"
@ -86,7 +86,7 @@ Store each UUID: `SCOPE_OPENID_PK`, `SCOPE_EMAIL_PK`, `SCOPE_PROFILE_PK`, `SCOPE
### Signing key
```bash
ssh root@100.64.0.6 "curl -s \
ssh root@100.64.0.1 "curl -s \
-H 'Authorization: Bearer $AK_TOKEN' \
'$AK_API/crypto/certificatekeypairs/?name=authentik+Self-signed+Certificate&has_key=true' \
| jq -r '.results[0].pk'"
@ -117,7 +117,7 @@ fi
Create the provider:
```bash
PROVIDER_RESPONSE=$(ssh root@100.64.0.6 "curl -s \
PROVIDER_RESPONSE=$(ssh root@100.64.0.1 "curl -s \
-X POST '$AK_API/providers/oauth2/' \
-H 'Authorization: Bearer $AK_TOKEN' \
-H 'Content-Type: application/json' \
@ -158,7 +158,7 @@ echo "Client Secret: $CLIENT_SECRET"
## Step 4: Create the Application
```bash
ssh root@100.64.0.6 "curl -s \
ssh root@100.64.0.1 "curl -s \
-X POST '$AK_API/core/applications/' \
-H 'Authorization: Bearer $AK_TOKEN' \
-H 'Content-Type: application/json' \
@ -282,7 +282,7 @@ Check in order:
Debug via API:
```bash
ssh root@100.64.0.6 "curl -s \
ssh root@100.64.0.1 "curl -s \
-H 'Authorization: Bearer $AK_TOKEN' \
'$AK_API/providers/oauth2/?search=$SERVICE_NAME' \
| jq '.results[0] | {name, client_id, signing_key, access_token_validity, refresh_token_validity, property_mappings}'"
@ -291,7 +291,7 @@ ssh root@100.64.0.6 "curl -s \
Or via ak shell:
```bash
ssh root@100.64.0.6 "docker exec authentik-server ak shell -c \"
ssh root@100.64.0.1 "docker exec authentik-server ak shell -c \"
from authentik.providers.oauth2.models import OAuth2Provider
p = OAuth2Provider.objects.get(name='$SERVICE_NAME')
print(f'Access Token: {p.access_token_validity}')
@ -316,7 +316,7 @@ The redirect URI in the app config must **exactly** match what's in Authentik
User isn't authorized for the application. By default all authenticated users have access. If you've added group restrictions via policy bindings, verify the user is in the correct group:
```bash
ssh root@100.64.0.6 "curl -s \
ssh root@100.64.0.1 "curl -s \
-H 'Authorization: Bearer $AK_TOKEN' \
'$AK_API/core/applications/$SERVICE_SLUG/' \
| jq '{name, slug, policy_engine_mode}'"
@ -330,12 +330,12 @@ Missing `offline_access` scope. Without refresh tokens, sessions only last as lo
```bash
# Delete application first (it references the provider)
ssh root@100.64.0.6 "curl -s -X DELETE \
ssh root@100.64.0.1 "curl -s -X DELETE \
-H 'Authorization: Bearer $AK_TOKEN' \
'$AK_API/core/applications/$SERVICE_SLUG/'"
# Then delete provider
ssh root@100.64.0.6 "curl -s -X DELETE \
ssh root@100.64.0.1 "curl -s -X DELETE \
-H 'Authorization: Bearer $AK_TOKEN' \
'$AK_API/providers/oauth2/$PROVIDER_PK/'"
```

6
runbooks/proxmox-create-ubuntu-vm.md
View file

@ -242,7 +242,7 @@ ssh zvx@$VM_IP 'curl -fsSL https://deb.nodesource.com/setup_22.x | sudo bash - &
Generate a preauth key on Contabo first:
```bash
docker exec headscale-standby headscale preauthkeys create --user echo6 --reusable --expiration 72h
docker exec headscale headscale preauthkeys create --user echo6 --reusable --expiration 72h
```
Then register the VM:
@ -254,7 +254,7 @@ ssh zvx@$VM_IP "sudo tailscale up --login-server https://vpn.echo6.co --auth-key
# Verify
ssh zvx@$VM_IP 'tailscale status'
docker exec headscale-standby headscale nodes list
docker exec headscale headscale nodes list
```
## Step 13 — Final Verification
@ -273,7 +273,7 @@ ssh zvx@$VM_IP "
echo '=== Disk ===' && df -h /
"
docker exec headscale-standby headscale nodes list
docker exec headscale headscale nodes list
```
## Post-Creation

9
runbooks/proxmox-onboard-node.md
View file

@ -8,10 +8,11 @@ You install Proxmox. You give CC an IP and a root password. CC does the rest.
| Alias | Local IP | Tailscale IP |
|----------|-----------------|-----------------|
| data | 192.168.1.240 | 100.64.0.20 |
| utility | 192.168.1.241 | 100.64.0.19 |
| cloud | 192.168.1.242 | 100.64.0.22 |
| media | 192.168.1.243 | 100.64.0.21 |
| data | 192.168.1.240 | 100.64.0.6 |
| utility | 192.168.1.241 | 100.64.0.5 |
| cloud | 192.168.1.242 | 100.64.0.4 |
| media | 192.168.1.243 | 100.64.0.3 |
| toc | 192.168.1.244 | 100.64.0.13 |
Management host: **cortex**

4
runbooks/recon-operations.md
View file

@ -2,7 +2,7 @@
## Service Info
- **Host:** recon-vm (VM 131 on data node) — migrated from CT 130 on 2026-04-19
- **Host:** recon-vm (VM 1130 on data node) — migrated from CT 130 on 2026-04-19
- **IP:** 192.168.1.130 / 100.64.0.24
- **Install:** /opt/recon/
- **User:** zvx
@ -186,4 +186,4 @@ sudo systemctl start recon
---
*Last updated: 2026-04-19 — Updated for CT 130 → VM 131 migration*
*Last updated: 2026-04-19 — Updated for CT 130 → VM 1130 migration*

12
runbooks/recon-service-integration.md
View file

@ -8,7 +8,7 @@ Use this when you have a service running on a remote LXC/VM that needs a web man
## Prerequisites
- A running Flask or FastAPI dashboard (e.g., RECON on VM 131, WATCHTOWER on Contabo)
- A running Flask or FastAPI dashboard (e.g., RECON on VM 1130, WATCHTOWER on Contabo)
- The target service running on a reachable host (LXC, VM, or bare metal)
- SSH access from the dashboard host to the target host
- The dashboard runs as a known user (e.g., `zvx`, `recon`, `watchtower`)
@ -20,7 +20,7 @@ Use this when you have a service running on a remote LXC/VM that needs a web man
Prompt the user for all of these before executing:
```
DASHBOARD_HOST= # Host running the dashboard (e.g., "192.168.1.130", "CT 130")
DASHBOARD_HOST= # Host running the dashboard (e.g., "192.168.1.130", "VM 1130")
DASHBOARD_USER= # User the dashboard runs as (e.g., "zvx")
DASHBOARD_APP_PATH= # Path to the dashboard app (e.g., "/opt/recon/lib/api.py")
DASHBOARD_STATIC_PATH= # Path to frontend files (e.g., "/opt/recon/lib/static/")
@ -418,10 +418,10 @@ lines = min(lines, 500) # Cap to prevent abuse
## Usage Examples
### RECON managing pipeline services (CT 130 dashboard → CT 110 PeerTube)
### RECON managing pipeline services (VM 1130 dashboard → CT 110 PeerTube)
```
DASHBOARD_HOST=192.168.1.130 (VM 131, data node)
DASHBOARD_HOST=192.168.1.130 (VM 1130, data node)
DASHBOARD_USER=zvx
TARGET_HOST=192.168.1.170 (CT 110, media node)
SERVICE_NAME=peertube
@ -453,7 +453,7 @@ Services managed:
- pt-downloader (CT 110): start/stop/restart/status/logs
- pt-importer (CT 110): start/stop/restart/status/logs
- pt-transcoder (cortex): start/stop/restart/status/logs
- recon (VM 131): start/stop/restart/status/logs
- recon (VM 1130): start/stop/restart/status/logs
Each service has its own sudoers file on its target host,
its own entry in SERVICE_INTEGRATIONS, and its own UI panel.
@ -461,4 +461,4 @@ its own entry in SERVICE_INTEGRATIONS, and its own UI panel.
---
*Last updated: 2026-04-19 — Updated CT 130 references to VM 131*
*Last updated: 2026-04-19 — Updated CT 130 references to VM 1130*