Du kjenner kanskje til “The quick brown fox jumps over the lazy dog”, en setning som brukes for å vise frem alle bokstavene i det engelske alfabetet.
I dag lærte jeg (fra README-en til skrifttypen Iosevka) at det finnes en norsk ekvivalent:
“Jeg begynte å fortære en sandwich mens jeg kjørte taxi på vei til quiz”.
Vi må nok inrømme at setningen føles ganske konstruert og unaturlig sammenliknet med den engelske, men det er ikke lett å bruke bokstavene x, y og z i samme setning. Ikke bare det, den har jo et tre bokstaver lengere alfabet og jobbe med også.
Her er et par Python-utrykk som kan hjelpe deg med å bekrefte det selv:
set("abcdefghijklmnopqrstuvwxyzåæø ") == \
set("jeg begynte å fortære en sandwich mens jeg kjørte taxi på vei til quiz")
# > True
''.join(sorted(set(
"jeg begynte å fortære en sandwich mens jeg kjørte taxi på vei til quiz"
)))
# > ' abcdefghijklmnopqrstuvwxyzåæø'Jeg var også litt tvilende på om “sandwich” egentlig er et norsk ord, men i følge ordbokene.no er det visst det.
Kravet (1a) “alle bokstavene skal brukes minst én gang” er jo egentlig litt spennende, en strengere versjon ville vært (1b) “alle bokstavene skal brukes eksakt én gang”. Det er også et implisitt krav (2) om at det skal være en setning som gir mening syntaktisk og semantisk.
Det kunne vært litt gøy å lage et program som søker etter setninger som tilfredsstiller kravene.
Vi har et trivielt induksjonsbevis for at det finnes uendelig mange setninger som tilfredsstiller (1a) alene. Fordi du kan ta en vilkårlig setning som tilfredsstiller kravet, og legge på et tilfeldig ord til slutten, hvilket gir deg en ny setning som fortsatt tilfredsstiller (1a). Sandwichfortæringssetningen kan være basistilfelle.
Om krav (1b) kan tilfredsstilles er mer uklart for meg, men om det kan har det definitivt et begrenset antall løsninger, fordi setningen må være eksakt 29 bokstaver lang (alfabetets lengde), og vi har begrenset antall bokstaver å velge fra (29).
Gitt at det ikke finnes et ord tilfredsstiller (1b) alene, kan det ikke være tilfelle at det finnes eksakt én løsning til (1b), da en omordning av ordene i en gyldig løsning vil generere en annen gyldig løsning.
Neste steg vil være å kombinere genererte setninger fra (1a) eller (1b), med kravet (2), som er mye vanskeligere å automatisk validere. Praktisk må (1a)-genereringen være klar over (2) på en sofistikert måte, for den må kunne beskjære bort stier som aldri leder til setninger som tilfredsstiller (2) fra (det uendelige) søketreet ellers generert av naiv (1a).
I dag lærte jeg at en “sparse matrix” kalles en “glissen matrise” på norsk.
Hysterisk ord. Tydeligvis brukes det ofte om tynn skog. God analogi.
Det var alt.
I dag lærte jeg om SSH-klientinstillingen ControlMaster.
Dette gjør at du kan åpne en SSH-tilkobling i bakgrunnen, så bruke den som du vil over et UNIX socket.
Instillingen er tydeligvis brukt i flere programmer som ønsker å gjøre oppgaver samtidig over samme tilkobling.
Jeg brukte den for å måle hvor feil klokka går på en BusyBox-basert enhet som dessverre ikke har NTP. På denne måten kan jeg slippe unøyaktighet grunnet tiden det tar å etablere tilkobling:
#!/usr/bin/env bash
set -euo pipefail
REMOTE="$1"
shift
SSH_OPTS=("$@")
CTRL_PATH="/tmp/ssh_clock"
# Koble til
ssh -o ControlMaster=yes -o ControlPath="$CTRL_PATH" \
-o ControlPersist=30 -o ConnectTimeout=10 \
"${SSH_OPTS[@]}" -fN "$REMOTE"
# Rydd opp når scriptet er ferdig
trap 'ssh -o ControlPath="$CTRL_PATH" -O exit "$REMOTE" 2>/dev/null' EXIT
# Mål klokka lokalt, fjernt, og lokalt igjen
T1=$(date +%s.%N)
T_REMOTE=$(ssh -o ControlPath="$CTRL_PATH" "$REMOTE" \
"/sbin/adjtimex | awk '/tv_sec/{s=\$2} /tv_usec/{printf \"%s.%06d\n\", s, \$2}'")
T4=$(date +%s.%N)
printf '%s\t%s\t%s\n' "$T1" "$T_REMOTE" "$T4"Det er også mulig å bruke dette i dag-til-dag manuelle tilkoblinger. Kanskje det er kjekt om du har en litt eksotisk autentiseringsmekanisme (YubiKeys mv.).
Leif på Hacker News (2011) forklarer sitt oppsett her.
For noen dager siden hadde jeg en diskusjon om domenetapet norsk opplever til fordel for engelsk innen informatikk. Som vi alle vet har vi rett og slett ikke ordene, eller utrykk som er presise nok for å beskrive en rekke konsepter.
Bedre blir det ikke av at IT har ganske mye stammespråk og sjargong som har presis mening blant utøvere, men kan være meningsløs eller lett å blande sammen for utenforstående. Når jeg skriver denne bloggen gjør jeg ofte et bevisst poeng i å bruke utrykk på norsk, fordi jeg synes det har en viss sjarm, og det ser noen ganger litt komisk ut. Ofte er jeg i tvil på om valget av utrykk hadde blitt forstått av noen som ikke allerede kjenner til den engelskspråklige sjargongen for samme konsept, da det føles litt påtvingt å oversette til norsk. Et eksempel på dette er bruk av utrykket “gaffel” eller “å gafle” i artikkelen om CLA-er.
Som en del av diskusjonen ble det nevnt at når de underviser grunnleggende programmering i Sverige bruker de ordet “geledd” for å beskrive det vi kaller “array”. Min diskusjonspartner mente dette var bedre, fordi “studentene har allerede en intuisjon for hva geledd betyr”.
Det kan godt være dette er et meg-problem, men jeg kan aldri huske å ha hørt ordet geledd før. Uformelle undersøkelser blant venner viser at det trolig ikke er et utspredt utrykk blant oss som enda er unge. Jeg har nå lært at det er et ord som tidligere ble brukt i milliær sammenheng for å beskrive soldater som står etter hverandre, skulder mot skulder.
Dette er en god analogi for “array”, da det beskriver en rekke elementer som er pakket sammen etter hverandre i minne (i motsetning til en lenket liste) men om den presise intuisjonen kommer bedre av å bruke “geledd” vet jeg ikke.
(Selvfølgelig må du ikke forveksle bruken av “pakket” med pakking av strukturer, et annet konsept.)
I følge SNL-artikkelen jeg lenket til tidligere bruker forsvaret i dag “linje” for å beskrive soldater som står skulder til skulder. Jeg tror ikke vi kan stjele det utrykket, da det gir (i allefall fra mitt perspektiv) nærmere allusjoner mot geometri.
I samme diskusjon ble det også nevnt at “stakk” høres litt ut som “stack”, men er på ingen måte samme konsept, da en stakk (f.eks.: løvstakk) er en uorganisert haug av ting, men en “stack” er elementer strengt stablet oppå hverandre.
De beste norske oversettelsene er nok “stabel” for “stack”, og “haug” for “heap”. Disse ordene tror jeg er ganske vanlig i undervisning i Norge.
Konseptene jeg har nevnt i denne artikkelen har alle vært ganske basale, og mer komplisert kommer det nok til å bli om vi forsøker å lage norskspråklige utrykk for det avanserte. Diskusjoner kan nok has om hvorvidt det er verdt å prøve engang.
Utfordring til leser: finn et godt norsk utrykk for “concurrent” og “concurrency”.
Hei! Jeg er bare en kode-apekatt, ikke en advokatt. Ta det jeg sier med en pote salt.
Opprinnelig var denne artikkelen en “IDLJ”, om noe jeg lærte om for litt over en måned siden av Morten Linderud på Norge.Chat, men det ballet litt på seg og føles nå mer naturlig som en artikkel.
Jeg har lenge trodd at GPL-3.0 og andre såkalte ‘sterke copyleft’-lisenser betyr følgende: “programvaren kan brukes til alle formål, så lenge du gjør egne modifikasjoner og utvidelser tilgjengelige under samme lisens”. Dette er generelt sett korrekt, med litt variasjon mellom de ulike lisensene på hva som er å anse som en modifikasjon.
Feilaktig har jeg lenge antatt at kravet om å gjøre endringer tilgjengelige under samme lisens også gjelder den som opprinnelig lagde programvaren. I min verden betydde dette at så fort programvare var ‘sterk copyleft’, kommer alltid fremtidige versjoner også til å være det.
Dessverre er dette ikke sant. Disse lisensene er noe opphavsrettholderen gir til andre, men er ikke bundet av selv.
I praksis vil større prosjekter med mange bidragsytere, der bidragsyterene alle deler sin kode med hverandre under samme sterke copyleft-lisens, og alle beholder det opphavsrettslige eierskapet til sin egen kode, være ganske trygge. Dette er fordi de må alle gå sammen i enighet om den skal omlisensieres.
Problemet kommer når et prosjekt du er avhengig av, og har festet tillit til fordi det er ‘sterk copyleft’, enten (1) opphavsrettslig har bare én eier, eller (2) har én entitet med mye sterkere rettigheter til kildekoden enn alle andre. Da har du risiko, fordi en enkelt entitet kan bestemme seg for at fremtidige versjoner av programmet ikke lenger skal være fritt.
For meg virker det som at de fleste prosjekter innen ‘sterk copyleft’-programvare med en eier som ønsker å beholde rettighetene til å omlisensiere i fremtiden, oppnår dette ved bruk av såkalte “CLA”-er (bidragsyters lisensavtale). I disse avtalene beholder bidragsyteren fortsatt opphavsretten, men gir en svært omfattende og ugjenkallelig lisens til prosjektets eier, uten den samme restriksjonen rundt modifikasjoner og utvidelser som kommer med sterke copyleft-lisenser.
Selvfølgelig kan prosjektet “gafles”, og versjonen fra før lisensendringen skjedde vil fortsatt være fri, men det er mange prosjekter (spesielt de som rettes mot utviklere) som markedsføres med at de er fri programvare, men utvikles i all hovedsak av et enkelt selskap, og det er vanskelig å bygge nok momentum til å vedlikeholde en gaffel. Dette utgjør en risiko.
Et eksempel på et slikt prosjekt er Overleaf, en populær nettside i akademia for å samarbeide om LaTeX dokumenter. For i overkant av et år siden priste jeg dem for å være AGPL-3.0-lisensiert fri programvare, men i dag ser jeg at for å bidra til prosjektet må du signere en CLA med eierene av Overleaf, som gir de rettighetene til å ta med din kode i en eventuell fremtidig omlisensiert versjon av programvaren.
Eksempler relativt ferskt i mitt minne på prosjekter som har gjort “åpen-kildekode teppedragning” inkluderer Redis og MinIO. Disse fungerte på litt ulike måter, og det er verdt å nevne at ingen av de var ‘sterk copyleft’+CLA, slik jeg har beskrevet hittil i artikkelen, men MinIO blir ganske nærliggende.
Redis var opprinnelig (frem til versjon 7.2) BSD-3-Clause-lisensiert, og hadde aldri en ‘sterk copyleft’-lisens. De trengte dermed ikke en CLA, da BSD-3-Clause gir veldig brede rettigheter for hva programvaren kan brukes til, og kommer ikke med noe krav om at endringer eller utvidelser skal gis ut under samme lisens.
Redis sin overgang til en såkalt ‘source-available’ lisens i 2024 fikk en rask respons i form av gaffelen “Valkey”, som fortsatt er BSD-3-Clause lisensiert, ser ut til å være godt vedlikeholdt, og eies av Linux Foundation. Redis har siden gjort enda en lisensendring, men min følelse er at utviklere flest fortsatt heller velger å stole på Valkey.
MinIO var annerledes. I april 2021 byttet de fra Apache-2.0 til AGPL-3.0, men krevde fra august 2021 at eksterne bidag ble lisensiert under Apache-2.0. (Hva som skjedde med eksterne bidrag i perioden april-august 2021 vet jeg ikke, dette er kanskje materiale for en fremtidig undersøkelse.) I slutten av 2025 var det klart at selskapet bak MinIO ikke lenger var intressert i å vedlikeholde den åpne versjonen av programvaren, og pekte brukere heller på det proprietære produktet “MinIO AIStor”. Dette kunne de gjøre, fordi eksterne bidragsytere hadde lisensiert sin kode til MinIO på et vis som gav de tillatelse til det. Siden februar 2026 har repoet vært arkivert på GitHub.
Det har ikke på samme måte som Valkey for Redis dukket opp en klar arvtaker etter MinIO. Gafler finnes selvfølgelig, men ingen av de aktivt vedlikeholdt såvidt jeg kan finne.
Andre alternativer som baserer seg på helt selvstendige kodebaser er Garage (AGPL-3.0) og SeaweedFS (Apache-2.0), begge uten CLA. Sistnevnte virker som den mest avanserte løsningen, som prøver å være mye mer enn “bare” en S3-erstatning, men er i all hovedsak laget av én enkelt utvikler, og trolig lite resistent mot likennde teppedragning. Førstnevnte ser litt mer indie og minimalistisk ut, med tilsynelatende 3-4 aktive utviklere.
Et av de mer omtalte alternativene er kanskje RustFS, men det har Apache-2.0 og CLA, så det er ingen grunn til å tro at det samme som skjedde MinIO ikke kan skje her også. Det gir meg også litt avsmak hvor mye de reklamerer for å være skrevet i Rust.
En annen faktor, som kan være grunn til at selskaper foretrekker ‘sterk copyleft’+CLA fremfor ‘permissive licensing’ er konkurransevern. Om selskapet bak produktet ønsker å lage en proprietær versjon med ekstra funksjoner, har de all rett til å gjøre det, men eventuelle konkurrenter må gjøre sine ekstra funksjoner offentlig tilgjengelig under samme lisens. Det kreves selvsagt ikke at eksterne signerer CLA med mindre de vil ha sin endring inn i den “offisielle” versjonen. Personlig har jeg egentlig ikke et stort problem med dette.
Fremover kommer det til å bli viktig for meg å ikke bare sjekke lisensen, men også hvorvidt det kreves at bidragsytere underskriver en CLA, sammen med hvem som står bak og hvor godt vedlikeholdt det er når jeg evaluerer om jeg skal bruke et program. Gullstandarden vil nok være ‘sterk copyleft’ uten CLA, med aktive vedlikeholdere, eller eierskap i en ideell organisasjon, som Linux, Valkey, eller (på den mer ekstreme siden) GNU-programvare.
Diskusjonen med Morten på Norge Chat var grunnet i at jeg sa jeg likte NetBird, et europeisk-utviklet alternativ til Tailscale. NetBird er AGPL-3.0-lisensiert, og markedsfører seg med at det er åpen kildekode, selv om det også er et kommersielt produkt. NetBird krever CLA, og det gjør meg nå usikker på at jeg fortsatt kan bruke i fremtiden, og mer engstlig for å avhenge av det.
Rent filosofisk synes ikke jeg at vi kan gjøre krav på fremtidig innsats fra åpen-kode-bidragsytere i å fortsette å vedlikeholde et prosjekt vi avhenger av. Vi kan heller ikke forvente av et selskap at de skal vedlikeholde åpne prosjekter om det ville vært mer inntektsbringende å gjøre de proprietære. Vi bør likevel være klar over at selskaper kan spekulere i å markedsføre seg som åpent, eller mer generelt å gjøre noe gratis tilgjengelig i begynnelsen, for å bygge en brukerbase som avhenger av de som infrastruktur, for så å gjøre produktet proprietært. Det er dette vi bør kjenne igjen som teppedragning.
Jeg har et nytt prosjekt på gang, som jeg ønsker å bruke som en plattform for å lære de nyeste konseptene i C++. Den nyeste standarden er i skrivende stund C++23, publisert i oktober 2024.
I følge Wikipedia er dette hvordan man nå skal skrive “Hello, world!” i C++23:
import std;
int main() {
std::println("Hello, world!");
}Her ser vi en av de best kjente endringene i C++23: de har lagt til en
println-funksjon
i standardbiblioteket! :eksploderende hode-emoji:
(Det finnes også print, som fungerer som du forventer.)
En annen stor greie her finnes på første linje, artikkelens emne: import std;.
Wikipedia-programmet bruker altså standardbiblioteket som en modul(!), ikke via header-filer.
Denne muligheten er en ny del av C++23-standarden.
(Moduler har eksistert siden C++20, og gir deg en litt mer moderne opplevelse rundt å splitte kode i mange filer enn header- og kildefiler gjør. Det gir også store forbedringer i kompileringstid.)
Jeg ønsker å bruke C++23 for alt det er verdt i prosjektet mitt, så import std; må jeg selvsagt ha.
Utviklingsmiljøet på min bærebare PC har relativt oppdaterte versjoner av ganske industristandard-komponenter:
Å få disse komponentene til å spille på lag slik at “Wikipedia-programmet” kan kjøres har krevd overraskende mye magi. Jeg oppsummerer her de nødvendige faktorene å ta hensyn til, mesteparten også relevant for Linux.
Her er hva jeg tror er en nokså kryss-plattform CMake konfigurasjon,
i allefall så lenge vi bruker clang.
CMake støtter per i dag import std; som en eksperimentell egenskap.
Vi må derfor, avhengig av versjon, skru på CMAKE_EXPERIMENTAL_CXX_IMPORT_STD-variabelen
med en spesifikk UUID, som identifiserer den eksakte CMake-koden som skal kjøre for å skru på støtten.
Alt dokumentert her.
cmake_minimum_required(VERSION 4.2)
set(CMAKE_CXX_STANDARD 23)
set(CMAKE_CXX_STANDARD_REQUIRED True)
set(CMAKE_EXPERIMENTAL_CXX_IMPORT_STD "d0edc3af-4c50-42ea-a356-e2862fe7a444")
set(CMAKE_CXX_COMPILER_IMPORT_STD 1)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -stdlib=libc++")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -stdlib=libc++ -lc++abi")
project(dans LANGUAGES CXX)
add_executable(dans main.cpp)
set_target_properties(dans PROPERTIES
CXX_MODULE_STD 1
)Videre er det slik at for clang er det bare LLVM-implementeringen (libc++) av standardbiblioteket
som støttes som modul. (Man kan altså ikke bruke libstdc++, GNU-implementeringen.)
Dette settes som flagg til kompilator og linker i vist konfigurasjon.
Til slutt må vi spesifikt si at target (her dans) skal ha egenskapen CXX_MODULE_STD slått på.
Om man glemmer variabler her, eller setter de i feil rekkefølge i forhold til deklarasjonen av project(),
kan man få kryptiske eller lite nyttige feilmeldinger.
En spesielt smertefull situasjon kan oppstå om man (som jeg gjorde) går ut fra at det går bra å bare sette
CMAKE_EXPERIMENTAL_CXX_IMPORT_STD til True.
Da blir egenskapen ikke slått på, men gir heller ingen form for feilmelding.
Dette er fortsatt ikke helt nok konfigurasjon, fordi
Clang-CXX-CXXImportStd.cmake
altså CMake-koden som lastes når man skrur på den eksperimentelle støtten og bruker clang,
ikke klarer å detektere en viktig fil på egenhånd: libc++.modules.json, manifestet til
standardbibliotek-modulen.
Dette er et ganske bredt rapportert problem, og mange kilder foreslår denne løsningen,
altså å redigere CMake-koden for å gi den nok informasjon til å finne manifestfilen.
Mange av disse diskusjonene er gamle, og jeg føler ikke for å redigere kode distribuert av pakkebehandleren min.
En kjapp sjekk av Clang-CXX-CXXImportStd.cmake viser at det siden har kommet en ny variabel:
CMAKE_CXX_STDLIB_MODULES_JSON. Det er nok å sette denne til absolutt filbane for manifestet for å korrigere problemet.
Denne løsningen har jeg ikke sett nevnt på noen form for nettsøk.
Til slutt (dette spesifikt fordi jeg bruker Homebrew, og ikke Apple sin innebygde distribusjon av LLVM) må vi instruere CMake om hvor den skal finne operativsystemets headerfiler og biblioteker å linke mot.
Jeg kjører altså CMake med følgende ekstra (plattformspesifikke) argumenter:
-DCMAKE_OSX_SYSROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
-DCMAKE_CXX_STDLIB_MODULES_JSON=/opt/homebrew/opt/llvm/lib/c++/libc++.modules.jsonVi har nå en CMake-konfigurasjon som under verktøykassa fra Homebrew lar oss kjøre og debugge Wikipedia-programmet i og utenfor CLion.
Selv om vi nå har en byggbar CMake-konfigurasjon, får vi feilmeldinger relatert til standardbibliotek-import i CLion, som er plagsomme og gjør at vi ikke får noen form for hjelp i IDE-en. Dette har vært et kjent problem i CLion siden august 2024, tilsynelatende uten noen fiks annet enn nødløsningen foreslått i kommentaren.
Jeg har endt opp med å legge til følgende ekstra (funksjonelt unødvendige) CMake-mål kun for at CLion skal plukke opp standardbibliotek-modulen i sin indeksering.
# Hack to make CLion happy with `import std;`
add_library(unused_std_target STATIC)
target_sources(unused_std_target
PRIVATE
FILE_SET CXX_MODULES
BASE_DIRS /opt/homebrew/opt/llvm/share/libc++/v1
FILES /opt/homebrew/opt/llvm/share/libc++/v1/std.cppm
/opt/homebrew/opt/llvm/share/libc++/v1/std.compat.cppm
)(Her med spesifikke filbaner for min LLVM-installasjon.)
Jeg har nå et greit utviklingsmiljø for å jobbe med C++23, men forstår absolutt hvorfor prosjekter ofte er treige på å adoptere nye C++-standarder. Gleder meg til å få dette til å funke på Linux (og gcc) også…
Mesteparten av problemene her kom ikke av at jeg bare ville bruke import std;,
men heller fordi jeg også ville ha alle de andre fine greiene rundt.
CLion støtter CMake absolutt best, og CMake er for alle sine feil utvilsomt standardverktøyet
for å bygge C++-prosjekter.
Dette er mye mer verktøy enn hva kan rettferdiggjøres for “Hello, world!”,
men vil forhåpentligvis lønne seg i lengden etterhvert som prosjektet legger til avhengigheter
og sine egne biblioteker og interne moduler.
Følg med for å se hva det blir til!
Jeg bruker nginx og certbot for noen tjenester jeg verter. Sistnevnte er et Python script som kan skaffe og automatisk fornye TLS-sertifikater, fortrinnsvis ved å bruke Let’s Encrypt sin HTTP-01 Challenge. Dette fungerer ved at den endrer nginx sin konfigurasjon til å levere en fil på en bestemt URL, som skal bevise at du som forespør et sertifikat også har kontroll over nettsiden.
I morges opplevde jeg at et par av tjenestene hadde utløpte sertifikater.
Rettere sagt fikk jeg en tekstmelding fra en forvirret bruker.
Jeg gikk på server og prøvde å fornye sertifikatene manuelt med sudo certbot renew.
Jeg fikk en feilmelding som så omtrent slik ut:
Certbot failed to authenticate some domains (authenticator: nginx).
The Certificate Authority reported these problems:
Domain: <DOMENENAVN>
Type: unauthorized
Detail: <IPv6-adresse>: Invalid response from
http://<DOMENENAVN>/.well-known/acme-challenge/<CHALLENGE-ID>: 404
Da gir det mening at sertifikatene er utløpt, certbot ikke klarer å fornye dem.
En ting som slo meg var at den prøvde å gjøre det til serverens IPv6-adresse.
Jeg hadde nylig lagt inn en AAAA (altså IPv6) rad i DNS for de påvirkede tjenestene, uten noen videre testing på om det fungerte.
Dette var kilden til feilen. I nginx må du eksplistitt spesifisere at en virtual host skal gjelde begge adressefamilier.
Om du bruker certbot har du sannsynligvis denne typen blokker i nginx-konfigurasjonen din, virtual hosts som lytter for HTTP-trafikk, og omdirigerer det til HTTPS:
server {
if ($host = <DOMENENAVN>) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
server_name <DOMENENAVN>;
return 404; # managed by Certbot
}
Denne spesifiserer listen 80;, hvilket betyr at den mottar trafikk til IPv4 på port 80.
For at blokken også skal være gjeldene for IPv6-trafikk, må du også legge inn listen [::]:80;.
Dette løste problemet og gjorde det mulig for Let’s Encrypt å nå utfordringsfilen.
En ganske amatørmessig feil å gjøre, som kunne lett vært unngått med enten bedre testing av konfigurasjonsendringer, eller kontinuerilg overvåkning av sertifikater som er i ferd med å utløpe. Uansett var det ikke katastrofalt, og god lærdom. Jeg skal sette opp bedre overvåkning snart, jeg lover.
En ting å legge merke til er at på den aktuelle serveren var default virtual hosten i nginx slått på.
Denne lytter eksplistitt på begge adressefamilier, så nginx-prosessen måtte også gjøre det.
Om den hadde vært slått av, kan det være nginx ikke hadde lyttet på IPv6 i det hele tatt, og Let’s Encrypt
hadde fått en TCP-rejection fra serveren.
Da kan det være Let’s Encrypt hadde falt tilbake til IPv4, og fornyelsen hadde gått gjennom.
Dette er spekulasjon, jeg har ikke testet.
Tips: legger du til en liten -v så det blir sudo certbot renew -v, forteller den deg også hva den gjør.
Slik var det klart for meg at den skrev om nginx sin konfigurasjon
på en måte som burde gjøre det mulig å aksessere HTTP-01 utfordringslenken i HTTP virtual hosten til nettsiden.
Oppdatering 30. mars 2026: Jeg har siden publikasjon av denne artikkelen lært mer om nyanser i lisenser og opphavsrett i fri programvare, og har ikke lenger en like positiv mening om denne artikkelens emne.
Overleaf, altså nettsiden som lar deg samarbeide om LaTeX-dokumenter, er fri programvare, lisensiert under AGPL-3.0! Kildekoden er tilgjengelig på GitHub, og programmet kan angivelig selv-vertes.
README-en tar et forbehold om at dokumentkompilering ikke sandbokses i den offentlige versjonen, så den bør ikke brukes om du ikke kan stole på brukerene. Jeg tror heller ikke den har støtte for integrasjoner, for eksempel med Zotero.
Hvordan disse funksjonene kan være propreitære når de bygger på et AGPL-3.0 prosjekt er jeg ikke sikker på. Det er kanskje mulig om de virker som eksterne moduler, ikke integrert i selve kodebasen.