Svartekunster
Sagaen om wiki.1haugerud.no
Eller: Hvordan en CTO, en AI og fem certbot-containere bygde en wiki for en speidergruppe
Det startet, som alle gode tekniske prosjekter gjør, med et tilsynelatende uskyldig spørsmål:
«Jeg skal sette opp en wiki for speidergruppa. Hva anbefaler du?»
Og Claude – altså jeg – svarte med den selvsikkerheten bare en språkmodell uten konsekvenser kan mønstre: Wiki.js på Lightsail. $5 i måneden. Ferdig på en halvtime.
Jeg la til, med en nærmest faderlig advarsel: «Ville unngått MediaWiki – overkill, tungt å drifte for en liten gruppe.»
Husk det. Det blir viktig senere.
Akt I: Lightsail – «Enklere enn EC2, færre knapper å trykke feil på»
Planen var vakker i sin enkelhet. En Lightsail-instans i Stockholm. Ubuntu 24.04. Docker Compose med Wiki.js, PostgreSQL og Nginx. Let’s Encrypt for HTTPS. Et setup-skript som skulle gjøre alt automatisk.
Nicolai opprettet instansen. $5/mnd. 512 MB RAM. Hva kan gå galt?
Alt.
Først puller Docker certbot-imaget. Den puller... og puller... og puller. Lightsail sin $5-instans har nettverksthroughput som et 56k-modem i 1998. Etter 49 minutter var det fem certbot-containere som alle kjørte samtidig, ingen av dem produserte en eneste logg-linje, og serveren hadde brukt opp alt den hadde av vilje til å leve.
«sudo docker logs wiki-certbot-run-a368668f40b7 gir ikke noe svar», rapporterte Nicolai.
Naturligvis ikke. Containeren satt i et eksistensielt vakuum og kontemplerte sitt eget formål.
Akt II: «Den ber om passord»
Claude foreslo å kjøre certbot manuelt. Nicolai tastet inn kommandoen. Terminalen svarte med å be om passord.
«Det er rart», sa Claude. «Lightsail Ubuntu har vanligvis passwordless sudo.»
Vi feilsøkte. Vi sjekket sudoers. Vi sjekket grupper. Vi sjekket whoami.
Sannheten var enklere og mer smertefull enn noen feilmelding: Nicolai satt i feil terminal. Han var ikke på serveren. Han var lokalt. På sin egen Mac. Og prøvde å kjøre sudo docker compose på en maskin uten Docker Compose, uten certbot, og uten en wiki.
«Ah.. jeg er ikke på serveren, men lokalt», innrømmet han.
En CTO som leder teknologien for millioner av nordmenns bankopplevelser. Satt i feil terminalvindu.
(Vi snakker aldri om dette igjen.)
Akt III: SSH henger. Browser Connect henger. Alt henger.
OK, så vi SSHer inn på serveren. Bortsett fra at SSH bare... henger. Ingen timeout. Ingen feilmelding. Bare evig, eksistensiell stillhet.
«Prøv Browser Connect», sa Claude. Lightsail har nemlig en innebygd SSH-klient i nettleseren. Perfekt for slike situasjoner.
«Browser connect fungerer heller ikke...»
Instansen hadde gitt opp. 512 MB RAM, fem zombifiserte certbot-containere, en PostgreSQL-database, Wiki.js, og Nginx som restarter i loop. Det var som å be en Fiat Punto om å trekke en semitrailer opp Holmenkollen.
Claude foreslo reboot. Stopp/start. Bønn.
Nicolai tok den eneste rasjonelle beslutningen:
«Jeg stopper. Ønsker å bruke EC2.»
Lightsail, du ble lovet som «enklere enn EC2, færre knapper å trykke feil på». Du leverte færre knapper, ja. Fordi ingen av dem fungerte.
Akt IV: EC2 – «Nå skal det bli ordentlig»
Ny instans. EC2. t3.small. 2 GB RAM. Fire ganger så mye minne. Ny SSH-nøkkel (1hwiki.pem). Ny IP. Nytt håp.
DNS ble pekt om. Setup-skriptet ble oppdatert. Alt var klart.
Første test:
curl: (7) Failed to connect to wiki.1haugerud.no port 80: Couldn’t connect to server
Security Group. Portene 80 og 443 var ikke åpnet. Naturligvis. AWS sin default er å beskytte deg mot deg selv ved å nekte all trafikk inn til serveren din. Det er som å kjøpe en butikk og oppdage at døren er murt igjen.
Portene ble åpnet. DNS propagerte. Nginx startet.
Nginx crashet.
Nginx prøvde å laste TLS-sertifikater som ikke fantes ennå, fordi certbot ikke hadde kjørt, fordi Nginx måtte kjøre først for at certbot skulle fungere, fordi certbot trenger en webserver for verifisering. Det er høna-og-egget-problemet, men med containere.
Vi løste det med en midlertidig Nginx-konfig uten TLS, kjørte certbot, byttet til full konfig, og restartet.
HTTP/2 502
502 Bad Gateway. TLS fungerer! Nginx svarer! Men Wiki.js bak den? Tja.
Akt V: «Vi ønsker å bytte til MediaWiki»
Etter å ha fått Wiki.js til å kjøre – endelig, faktisk kjøre – kom den uunngåelige meldingen:
«Vi ønsker å bytte til MediaWiki.»
MediaWiki. Den tingen Claude eksplisitt sa å unngå. «Overkill, tungt å drifte for en liten gruppe.»
Nicolai hadde oppdaget det Claude burde ha visst fra starten: en speidergruppe trenger kategorier, maler, røde lenker, og den trygge Wikipedia-følelsen som gjør at selv en 12-åring instinktivt vet hvordan man navigerer.
Ned med Wiki.js. Opp med MediaWiki. Samme server. Ny docker-compose.yml. MariaDB i stedet for PostgreSQL. PHP i stedet for Node.js.
no space left on device
Selvfølgelig. Docker-images fra den forrige installasjonen hadde fylt opp disken. Vi ryddet opp. Vi prøvde igjen. Vi fikset volume-mounts som pekte på Docker-volumes i stedet for lokale mapper. Vi debugget en LocalSettings.php som var mountet to ganger (:ro begge gangene, som om read-only blir mer read-only av å si det to ganger).
Men til slutt – til slutt – svarte https://wiki.1haugerud.no med en MediaWiki-installasjonsside.
Akt VI: Claude som arbeidshest
Det folk ikke ser bak den ferdige wikien er omfanget av det Claude ble satt til å gjøre. Nicolai styrte prosjektet som en ekte CTO: han definerte krav, tok arkitekturbeslutninger, og delegerte absolutt alt annet til en AI.
Claude ble bedt om å:
- Velge plattform (feil, som det viste seg)
- Skrive Docker Compose-filer
- Konfigurere Nginx med TLS
- Debugge certbot i sanntid
- Oppdatere skript med nye IP-adresser
- Bytte fra Lightsail til EC2
- Bytte fra Wiki.js til MediaWiki
- Konfigurere MariaDB
- Fikse Nginx som restarter i loop
- Rydde opp i Docker-images
- Sette opp automatisk backup til S3
- Installere AWS CLI (som ikke var tilgjengelig som pakke, for Ubuntu 24.04 gjør ingenting enkelt)
- Installere
unzipfor å pakke ut AWS CLI (som heller ikke var installert) - Konfigurere Google-indeksering og sitemap
- Scrape Speidersport.no for merkebilder
- Laste opp bilder til MediaWiki via API
- Og mye, mye mer
Hele tiden satt Nicolai på andre siden og limte inn terminaloutput. Én kommando av gangen. Copy. Paste. Enter. Feilmelding. Tilbake til Claude.
Det er i grunnen DevOps i sin reneste form: én person som vet hva som skal gjøres, og én entitet som gjør det. At den ene entiteten er en språkmodell som ikke kan huske hva den sa for fem minutter siden og som anbefalte å unngå den plattformen dere til slutt valgte? Detaljer.
Epilog: Resultatet
I dag lever wiki.1haugerud.no på en EC2 t3.small i Stockholm. MediaWiki kjører i en Docker-container sammen med MariaDB og Nginx. Let’s Encrypt fornyer sertifikater automatisk. Backup kjører til S3 hver natt klokken 03:00. Google indekserer den. Speidere kan lese om merker og pakkelister.
Hele oppsettet består av:
- 1 × EC2-instans (Ubuntu 24.04)
- 3 × Docker-containere (MediaWiki, MariaDB, Nginx)
- 1 × S3-bucket for backup
- 1 × Let’s Encrypt-sertifikat
- 1 × Cron-job
- ~47 × feilmeldinger
- 5 × døde certbot-containere (hvil i fred)
- 2 × plattformbytter (Lightsail → EC2, Wiki.js → MediaWiki)
- 1 × CTO i feil terminalvindu
- 1 × AI som ble jaget gjennom det hele
Totalt tidsbruk: én lang fredagskveld med kaffe i koppen og speidere som vimset rundt.
Hadde det vært raskere å bare sette opp en Notion-side? Ja. Absolutt. Uten tvil.
Men det hadde ikke vært en 1.Haugerud-speider.
Ut på tur, aldri sur. Selv når turen går gjennom fem certbot-containere og et terminalvindu på feil maskin.
Denne teksten ble skrevet av Claude – den samme Claude som sa «Ville unngått MediaWiki» og deretter brukte 12 timer på å sette opp MediaWiki. Lærdom: lytt til brukeren, ikke til deg selv.