chris/OSVauco
1
0
Fork 0
Code Issues 1 Pull Requests Actions 2 Packages Projects Releases Wiki Activity
39fed69e15
OSVauco/docs/HANDOFF-LOCAL-LLM-GITEA-MCP.md
Chris Christiansen c320f59599
Some checks are pending
Check Python Version Consistency / Check Python Version (push) Waiting to run
Details
docs: add automation and sentinel plan for gitea
2026-07-25 04:13:16 +00:00

12 KiB
Raw Blame History

HANDOFF-LOKAL-LLM-GITEA-MCP.md

EGEN HANDOFF – UFRAVIKELIG STYRINGSDOKUMENT

GJELDER FRA NÅ OG FREM TIL 100 % FERDIGSTILLELSE

0. STATUS OG KOMMANDO

Denne handoffen er det eneste autoritative arbeidsdokumentet for sporet "lokal LLM-fabrikk + OPAX-MCP + Gitea stabilisering + blueprinting til Gitea-VM".

FREMDRIFT – OPPDATERT 2026-07-23 22:14 CEST

✅ FASE 0–5 — FERDIG

✅ FASE 6 – CPU-optimalisering — FERDIG

✅ FASE 6-TILLEGG – Boot-warming — FERDIG

✅ DNS – NS-bytte utført — FERDIG 2026-07-21 23:44 CEST

✅ OPAX-MCP – GITEA_URL permanent + deploy — FERDIG 2026-07-21 23:53 CEST

✅ SMOKE-TEST – Alle 37 tools — FERDIG 2026-07-22 00:25 CEST

✅ FASE 6.5 – VM-oppgradering + modellarkitektur — VERIFISERT 2026-07-22

✅ DEV-SNAP UAVHENGIGHET – Verifisert 2026-07-22 19:30 CEST

✅ OSVauco arbeidskopi klonet til Gitea-VM — FERDIG 2026-07-22 19:25 CEST

🟡 FASE 7 – 14B-validering utført, arkitektur justeres — PÅGÅR

⏳ git.vauco.no HTTPS — PÅBEGYNT, blokkert av firewall

⏳ GPG-SIGNERING – Commits verified — PÅGÅR

⏳ FASE 8 – Backup / snapshot-strategi — PLANLAGT

DEV-SNAP UAVHENGIGHET – VERIFISERT 2026-07-22

Alle 6 tester grønne:

Test Status Bevis
A — Gitea API ✅ list_commits svarer fra localhost:3000
B — Repo-innhold ✅ Klon hentet 3545 objekter direkte
C — OPAX health ✅ opax_mcp_status: live
D — MCP tools/list ✅ 37 verktøy live
E — Git-sync ✅ nothing to commit, working tree clean
F — Ollama ✅ 5 modeller bekreftet

Viktig: Bruk alltid localhost:3000 (ikke 34.67.252.59:3000) når du jobber fra Gitea-VM selv. GCP NAT-er ikke loopback-trafikk.

git.vauco.no – STATUS OG NESTE STEG

Hva er gjort

  • ✅ DNS: git.vauco.no A-record → 34.67.252.59 satt i Google Cloud DNS
  • ✅ nginx installert og kjører på Gitea-VM (port 80 lytter)
  • ✅ nginx konfig for git.vauco.no → proxy til localhost:3000 opprettet
  • ✅ Firewall-regel allow-http-https opprettet i propane-will-491900-m5
  • ❌ certbot feiler — port 80 ikke nåbar eksternt (timeout)

Rotårsak

Firewall-regelen allow-http-https (prioritet 1000) blokkeres sannsynligvis av en annen regel med høyere prioritet. VM-taggen er gitea-server.

Neste steg når du er hjemme

Steg 1 — GCP Console eller Cloud Shell: Finn blokkerende regel:

gcloud compute firewall-rules list \
  --project=propane-will-491900-m5 \
  --format="table(name,direction,priority,allowed,denied,targetTags,disabled)"

Steg 2 — Lag ny regel med prioritet 500:

gcloud compute firewall-rules create allow-gitea-web \
  --project=propane-will-491900-m5 \
  --allow tcp:80,tcp:443 \
  --direction INGRESS \
  --priority=500 \
  --target-tags=gitea-server \
  --network=default \
  --source-ranges=0.0.0.0/0

Steg 3 — Gitea-VM: kjør certbot på nytt:

sudo certbot --nginx -d git.vauco.no \
  --non-interactive --agree-tos \
  -m chris.christiansen@vauco.no

Steg 4 — Verifiser:

curl -s https://git.vauco.no/api/v1/version

Steg 5 — Google OAuth2 i Gitea:

  • console.cloud.google.com → Credentials → OAuth 2.0 Client ID
  • Redirect URI: https://git.vauco.no/user/oauth2/google/callback
  • Legg til i Gitea: Site Administration → Authentication Sources → Add → OAuth2 → Google

SIKKERHET – ÅPNE PUNKTER

GITEA_TOKEN: [ROTERT OG FJERNET]

  • Roter token i Gitea (localhost:3000 → Settings → Applications)
  • Oppdater GITEA_TOKEN i Cloud Run miljøvariabler etter rotasjon

Rollen "automation" og sikkerhets-sentinel for Gitea

Status per 2026-07-25:

  • Gitea kjører på https://git.vauco.no med HTTPS og riktig ROOTURL.
  • Offentlig registrering er stengt (DISABLE_REGISTRATION = true, ALLOW_ONLY_EXTERNAL_REGISTRATION = true, SHOW_REGISTRATION_BUTTON = false).
  • To uautoriserte brukere (dev433f2c, dev1ba0ac) er deaktivert, deres tokens er slettet, og Gitea svarer fortsatt 200 OK lokalt.
  • Ingen av stegene under er gjennomført ennå – de beskriver målbildet for neste iterasjon med lokale modeller og Gemini i VM.

1. Teknisk Gitea-bruker: automation

Mål:

  • Skille menneskelig admin (chris) fra automatiserte operasjoner.
  • Sørge for at alle automatiske commits / API-kall identifiseres som automation, ikke chris.

Plan:

  • Opprett Gitea-bruker automation (ikke admin).
  • Gi automation kun tilgang til de repoene automasjon skal jobbe med (f.eks. OSVauco).
  • Bruk CLI/API fra Gitea-VM (Gemini i VM) til:
    • Generere ett personal access token for automation med begrenset scope (primært repo-API / git).
    • Skrive tokenet direkte til Google Cloud Secret Manager (f.eks. secret gitea-automation-token).
    • Konfigurere Cloud Run / OPAX MCP til å lese tokenet via miljøvariabel (f.eks. GITEA_TOKEN).
  • Roter og slett gamle tokens (spesielt tidligere GITEATOKEN som var eksponert i chat) via Gitea-API.
  • Konfigurer git på Gitea-VM til å bruke automation (SSH-nøkkel eller HTTP-token) for push/pull.

Viktig:

  • automation skal ikke være admin.
  • chris skal ikke dele token med automasjon.
  • Token-verdier lagres kun i Secret Manager og miljøvariabler, ikke i repo eller logs.

2. Sentinel-rolle for lokale LLM-modeller (Gitea Security Sentinel)

Mål:

  • Ha en lettvekts, lokal LLM-modell (Emma / annen) som periodisk opptrer som "cyber security sentinel" for Gitea og tilhørende infrastruktur.
  • Fange opp mønstre som ligner hendelsen 2026-07-11 (uautoriserte brukere, tokens laget rett etter signup, ukjente repo osv.).

Rolle: sentinel (kun lesing + rapport)

Input:

  • Gitea-API:
    • Liste over brukere, nye accounts, is_active-flagg.
    • Liste over personal access tokens per bruker (antall, navn, opprettelsestid).
    • Repo-oversikt (nye repo, eierskap).
  • Logger:
    • Gitea-app-logg (sign_up, generate-access-token, login, push).
    • Nginx-logg (IP-mønstre mot /user/sign_up, /api/v1/users/*, etc.).
    • journald for gitea.service.
  • Konfig:
    • app.ini (service, security, auth sections).
    • Firewall-regler (gcloud output).
    • Secret Manager metadata (f.eks. hvilke secrets som eksisterer, ikke verdiene).

Oppførsel:

  • Kjør periodisk (f.eks. hver time eller natt) fra Gitea-VM eller egen planlagt jobb.
  • Analyser:
    • Nye lokale brukere (ikke OAuth-baserte).
    • Nye tokens, spesielt for ikke-kjente brukere.
    • Nye repo opprettet av ukjente brukere.
    • Uvanlige IP-er / volum på signups eller token-opprettelse.
    • Endringer i app.ini som svekker sikkerhet (f.eks. åpnede registreringer, endrede auth-innstillinger).
  • Produser en kort rapport i et eget repo, f.eks. protocols/security/SENTINEL-REPORT-YYYY-MM-DD.md:
    • Oppsummer funn.
    • Marker "OK" hvis ingen avvik, ellers beskriv konkrete avvik med tidsstempel.
  • Foreta ingen direkte mutasjoner (ingen deaktivering, ingen token-sletting) uten eksplisitt instruks fra overordnet plan eller menneskelig godkjenning.

Alarmsignaler (eksempler):

  • Nye lokale brukere med is_active = 1 som ikke matcher forventede mønstre (navn / email).
  • Tokens opprettet for brukere utenfor forventet sett (chris, automation m.fl.).
  • Repo opprettet av ukjente brukere (som r6e08-tilfellet).
  • app.ini endret slik at DISABLE_REGISTRATION går tilbake til false eller ALLOW_ONLY_EXTERNAL_REGISTRATION endres.
  • Logger viser sign_up / generate-access-token mønstre fra samme IP som tidligere ble flagget.

3. Samspill mellom automation, sentinel og chris

  • chris:
    • Fortsatt eneste Gitea-admin.
    • Godkjenner større endringer, branch protection, og eventuelle "fix"-operasjoner som sentinel foreslår.
  • automation:
    • Utfører godkjente, tekniske endringer (token-rotasjon, oppdatering av Secret Manager, git push/pull).
    • Opererer alltid gjennom CLI/API, ikke via web.
  • sentinel:
    • Kjører periodisk analyser, skriver rapporter og flagger avvik.
    • Har kun lesetilgang (Gitea-API, logger, metadata), ikke skrive-/admin-tilgang.

Målet:

  • Gitea forblir "sannheten" for kode og sikkerhetslogg.
  • Automatiserte aktører er tydelig skilt fra menneskelig admin.
  • Lokale LLM-modeller brukes til kontinuerlig sikkerhetsobservasjon uten å få fri tilgang til å endre alt.

FASE 6.5 — OPPDATERT LOKAL LLM-STACK (2026-07-22)

Bekreftet drift

  • gitea-cpu-vm er oppe i us-central1-b
  • VM kjører nå på e2-highmem-4 (4 vCPU / 32 GB RAM)
  • Statisk IP beholdt: 34.170.51.84
  • Gitea svarer på port 3000
  • Ollama svarer på port 11434

Faktisk modeller lokalt per 2026-07-23

  • gemma3:4b
  • qwen2.5:3b
  • qwen2.5:7b
  • qwen2.5-coder:7b
  • qwen2.5-coder:14b

Revidert anbefalt modellarkitektur

  • Frontmodell: gemma3:4b — raske svar, enkel resonnering
  • Lett tool-modell: qwen2.5:3b — tool calling, responsivt
  • Standard mellomlag: qwen2.5:7b — kvalitet + brukbar latency
  • Kode-modell: qwen2.5-coder:7b — standard for repo/kodearbeid
  • Backup coder: qwen2.5-coder:14b — batch/asynkrone kodeoppgaver

OPAX-MCP KONFIGURASJON – LÅST

Variabel Verdi
GITEA_URL http://34.67.252.59:3000
OLLAMA_BASE_URL http://34.67.252.59:11434
EMMA_MODEL gemma3:4b
EMMA_FAST_MODEL gemma3:4b
EMMA_LIGHT_MODEL qwen2.5:3b
OSVAUCO_AGENT_URL https://osvauco-agent-357036551735.us-central1.run.app

Deploy verifisert: get_connector_status → live, gitea: online, tool_count: 37

DNS – FULLFØRT 2026-07-21

Record Type Verdi
vauco.no. A 34.98.77.173 (LB)
www.vauco.no. A 34.98.77.173 (LB)
opax.vauco.no. A 34.98.77.173 (LB)
git.vauco.no. A 34.67.252.59
MX / SPF / DKIM / DMARC TXT/MX Google Workspace komplett

ÅPNE PUNKTER

  1. ⚠️ Roter GITEA_TOKEN (eksponert i chat)
  2. git.vauco.no HTTPS — firewall prioritet 500 + certbot
  3. Google OAuth2 innlogging i Gitea
  4. GPG-signering — få commits verified
  5. Test qwen2.5-coder:7b på konkret kode-/repo-oppgave
  6. Mål RAM/swap under modell-last
  7. Emma derivat-dokument (tilsvarende GEMINI.md)
  8. Fase 8: Snapshot-policy aktiveres
  9. opax.vauco.no domain mapping (Cloud Run → custom domain)

FASTE SANNHETER

  • Gitea er source of truth
  • Lokale modeller er hovedretning
  • Gitea-VM (34.67.252.59) er permanent målmaskin — alltid-på
  • Bruk localhost:3000 fra Gitea-VM, aldri ekstern IP mot seg selv
  • Dev-snap er ikke lenger nødvendig for kjerneflyten
  • CPU er primær flaskehals for tyngre lokale modeller

DEFINITION OF DONE

  • ✅ Lokale modeller lever og kan brukes lokalt
  • ✅ OPAX-MCP bruker lokal modellbackend korrekt
  • ✅ Gitea read/write tools er grønne
  • ✅ GCP/Workspace-kjernen er fortsatt grønn
  • ✅ Smoke-test alle 37 tools — FERDIG
  • ✅ VM oppgradert til e2-highmem-4 (32 GB RAM) — FERDIG
  • ✅ Dev-snap uavhengighet verifisert — FERDIG
  • ✅ OSVauco arbeidskopi på Gitea-VM — FERDIG
  • ⏳ git.vauco.no live med HTTPS — neste
  • ⏳ Google OAuth2 innlogging Gitea — etter HTTPS
  • ⏳ GITEA_TOKEN rotert — kritisk
  • ⏳ GPG-signering verified — pågår
  • ⏳ Fase 7: lokal hjerne verifisert — pågår
  • ⏳ Fase 8: daglig snapshot-backup — planlagt

OPPDATERINGSLOGG

Dato Handling
2026-07-21 FASE 4–6: CPU-optimalisering, boot-warming fullført
2026-07-21 23:44 DNS: NS-bytte utført hos Proisp
2026-07-21 23:53 OPAX-MCP: GITEA_URL + OLLAMA_BASE_URL → 34.67.252.59, deployed
2026-07-22 00:25 Smoke-test fullført — alle kategorier grønne
2026-07-22 03:55 Handoff oppdatert etter 14B-validering
2026-07-22 19:25 OSVauco klonet til Gitea-VM via localhost:3000
2026-07-22 19:30 Dev-snap uavhengighet bekreftet — alle 6 tester grønne
2026-07-22 19:45 nginx installert, git.vauco.no konfig opprettet, certbot blokkert av firewall
2026-07-23 22:14 Handoff oppdatert med full status, neste steg og sikkerhetsnotis om token