Byg et organisationsejet operativsystem med SUSE/openSUSE-værktøjer: Open Build Service, Keg, KIWI, PXE/netværksboot, iPXE, USB og U-Boot.

Dette dokument er opdelt i fire dele, så hver læser kan gå direkte til det relevante niveau:

• Del 1 – Den korte, ikke-tekniske version: til ledelse og beslutningstagere.
• Del 2 – Den tekniske strategi: til it-chefer og teknisk funderede mellemledere.
• Del 3 – Den detaljerede instruktion: til teknikere og superbrugere, der skal bygge og rulle ud.
• Del 4 – Appendikser: behovsanalyse for forskellige scenarier, faldgruber og komplet linkbibliotek.

Udgangspunktet er SUSE-økosystemet: SUSE Linux Enterprise Server/Desktop (SLES/SLED) 16 til maskiner, hvor der er behov for support og SLA, og openSUSE Leap/ALP, hvor en 100 % fri løsning er ønsket. De to er binærkompatible og bygget med de samme værktøjer, så man kan starte frit og købe support senere – uden vendor lock-in.

Den sikre fjernadgang, der refereres til gennem hele dokumentet, er beskrevet i den eksisterende referencearkitektur på wiki.smarken.dk.

Se også :

• Forside/start på wiki.smarken.dk
• Sikker fjernadgang med åben kildekode - referencearkitektur (totalloesningpoc)
• PC-deploy: installationstyper (manuel, image, AutoYaST/Agama)

I dag installerer de fleste organisationer deres computere én ad gangen: en medarbejder (eller en it-afdeling) sætter en USB-nøgle i maskinen, klikker igennem en installationsguide og håber på, at resultatet ligner maskinen ved siden af. Det er langsomt, fejlbehæftet og umuligt at dokumentere.

Alternativet er at behandle operativsystemet som et produkt, organisationen selv ejer og bygger: én gang definerer man, hvad “vores firmapc” indeholder – programmer, sikkerhedsindstillinger, netværksopsætning, branding – og derefter bygges der færdige, identiske images af den. En ny medarbejder får tildelt en maskine, den tændes, og efter få minutter står der en færdigkonfigureret pc. Uanset om maskinen står på kontoret, i medarbejderens hjem eller på en kundevisit.

Kort sagt: I får jeres egen Linux-distribution – bygget på open source-værktøjer fra SUSE/openSUSE, som selv SUSE bruger til at bygge deres egne produkter.

• Ensartethed og kvalitet. Alle maskiner er bitidentiske. Det, der er testet én gang, er testet overalt. Supportsager falder, fordi “virker på min maskine”-problemer forsvinder.
• Hastighed. En ny maskine er produktiv på minutter i stedet for timer. Udrulning til en hel afdeling sker i én proces.
• Sikkerhed og compliance. Sikkerhedspolitikker (diskkryptering, adgangskontrol, opdateringsdisciplin) er bagt ind fra dag ét – ikke påklistret bagefter. Det giver direkte argumenter over for GDPR-, NIS2- og evt. DORA-krav.
• Digital suverænitet. Alt er open source og kan bygges, auditeres og driftes på egen infrastruktur. Ingen afhængighed af en bestemt cloud eller udenlandsk leverandør.
• Fleksibilitet. Samme fundament kan levere flere “smagsvarianter”: standalone-pc'er, standard firmapc'er, afdelingsspecifikke maskiner og sikre hjemmearbejdspladser – valgt fra en menu, når maskinen tænder.
• Omkostningskontrol. openSUSE er gratis; SLES-abonnement er valgfrit og køber support og SLA, ikke adgang til kode. Man kan altså starte gratis og først betale, når forretningen kræver garantier.

Der er tre poster:

1. Mennesker. Én til to medarbejdere, der lærer værktøjerne (der er rigelig, gratis dokumentation – se Del 4). Det er den vigtigste investering.
2. Infrastruktur. Én byggeserver (kan være en virtuel maskine) og eventuelt en boot-server pr. lokation. Beskeden hardware.
3. Vedligehold. Images genbygges løbende med sikkerhedsopdateringer – men det er automatiseret. Man bør regne med en fast fraktion af en fuldtidsstilling afhængigt af antal profiler.

• Hvilke maskintyper/profiler skal organisationen have? (Forslag til analysemetode: Appendix A.)
• Supportniveau: skal kritiske maskiner have SLES-abonnement med SLA, eller er openSUSE nok?
• Hvem ejer profilerne? Der skal være én beslutningsvej for “hvad er standardskrivebordet” – ellers bliver profilerne for mange og uoverskuelige.
• Hvornår er en maskine “sikker nok”? Fx krav om diskkryptering og flerfaktorgodkendelse for maskiner, der bruges uden for kontoret – jf. referencearkitekturen på wikien.

• “Vi glemmer at opdatere images.” → Automatisk genbygning hver uge/måned; image uden opdateringer ældre end en fast frist må ikke kunne bootes i produktion.
• “Én person byggede det, og han er opsagt.” → Alt er tekstfiler under versionsstyring; enhver kan genbygge. Det er hele pointen med metoden.
• “Det virker ikke på den nye hardware.” → Der testes altid på en pilotmaskine af hver hardwaretype, inden en profil udrulles bredt (se faldgruber i Appendix B).

Anbefalet beslutning: Start med en pilot: én baseprofil + én afdelingsprofil + én hjemmearbejdsplads, 10–15 maskiner, 3 måneder. Evaluer, og skaler derefter.

Pipeline, kort fortalt: Git-repo (Keg-recipes) → OBS-byg → KIWI-images → HTTP/TFTP-distribution → maskinen vælger profil i boot-menu (GRUB2) → første boot-opsætning (cloud-init/Combustion) → registrering i Uyuni + NetBird.

• Beskrivelser frem for snapshots. Image-indholdet er deklareret i tekstfiler (versionsstyret, review'et, diff'et). Ingen “ghost-images”, ingen manuelle ændringer efter byg.
• Skalering af profiler. Keg er lavet præcis til situationen, hvor mange imagebeskrivelser deler stort indhold: en fælles base og små, overskuelige forskelle pr. profil (afdeling, rolle, lokation).
• Kontinuerlig genbygning. OBS genbygger automatisk, når en pakke eller dependency opdateres – sikkerhedsopdateringer flyder ind i nye images uden manuelt arbejde.
• Reproducerbarhed. Samme input → samme output. Krav i enhver audit-sammenhæng.

Der er fire boot-veje, som bør betragtes som én samlet løsning med fælles indhold:

1. PXE/netværksboot (BIOS + UEFI). Standard på kontoret. GRUB2 (evt. shim til Secure Boot) serves via TFTP/HTTP; boot-menuen er den samme GRUB2-menu med profilvalg som USB-varianten. iPXE kan lægges ind som led (chainload) for at få HTTP(S), scripts og nem debug.
2. UEFI HTTP Boot. Nyere firmware kan hente bootloader direkte over HTTP(S) – fjerner TFTP's hastigheds- og skaleringsproblemer.
3. USB. Til standalone-pc'er, feltenheder og som fallback. USB-mediet booter GRUB2 med samme menu/profiler. Kan også bootstrappe via U-Boot på ARM.
4. U-Boot (ARM/edge). Boards uden PC-firmware bruger U-Boot's “distro boot”-mekanisme: standard extlinux.conf/boot script på USB/SD, så samme image-beskrivelse kan ramme edge-hardware.

Fælles menu-princip: Uanset boot-vej ender maskinen i en GRUB2-menu (eller extlinux/U-Boot-ækvivalent), hvor profilen vælges – evt. automatisk pr. DHCP/MAC for bulk-udrulning, manuelt for enkeltmaskiner.

Sikkerheden for hjem/felt følger den eksisterende referencearkitektur for sikker fjernadgang: adgang afgøres af identitet (Keycloak + FreeIPA, MFA/FIDO2) og enheds-compliance (Uyuni/Salt), ikke af netværksplacering – hjemmenetværk og kontor-netværk behandles ens.

Installationstyperne bag det hele (manuel installation vs. præfabrikeret image vs. AutoYaST/Agama) er gennemgået i wikiens deploy-overblik; dette dokument uddyber image-sporet (KIWI), som er det hurtigste og mest reproducerbare.

• Build-cyklus: ugentlig/månedlig automatisk genbyg i OBS; images tagges med dato + git-commit.
• Patch-cyklus: efter deploy håndteres maskinerne af Uyuni (patch, compliance, certifikat-tilbagekald). Images er “fabrikstilstand”; driften er konfigurationsstyret.
• Versionscyklus: fuld profil-rebuild ved hver ny Leap-/SLES-version; gamle versioner udfases med notice, så ingen maskine kører EOL-software.
• Dokumentation: hver profil har en ejer, et formål og et ændringslog-entry i Git – det er samtidig audit-spor.

• Image-ejer (product owner): godkender profilændringer (én pr. profil, samlet forum for basen).
• Build-ingeniør: vedligeholder Keg-recipes, OBS, boot-servere.
• Drift (Uyuni): registrering, patching, compliance.
• Security: godkender hardening-krav og review mod Appendix B pr. release.

1. Uge 1–2: OBS + Git-repo op, base-image bygger.
2. Uge 3–4: PXE/HTTP + USB-boot med profilmenu virker på pilot-hardware.
3. Uge 5–8: Firma-profiler + Uyuni-registrering + NetBird-enrol til hjem/felt-profil.
4. Uge 9–12: Pilot på 10–15 maskiner, justering af profiler, dokumentation.
5. Derefter: bred udrulning afdeling for afdeling.

• Én build-vært: openSUSE Leap eller SLES 16 (virtuel maskine er fint), med adgang til repos.
• Git-repo til image-beskrivelser (fx org-images).
• Netværkssegment til boot-tests, hvor man råder over DHCP (brug proxy-DHCP i produktion – se Appendix B).
• For ARM/U-Boot-scenarier: ét repræsentativt board.
• OBS: enten konto på build.opensuse.org eller self-hostet OBS-instans.

# KIWI (image builder) – fra OBS' builder-repo for nyeste version
sudo zypper addrepo \
  https://download.opensuse.org/repositories/Virtualization:/Appliances:/Builder/openSUSE_Leap_16.0 \
  kiwi-appliance-builder
sudo zypper refresh && sudo zypper install python3-kiwi kiwi-tools
 
# Keg (image description generator)
sudo zypper install python3-kiwi-keg   # eller: pip install kiwi-keg
 
# OBS-klienten
sudo zypper install osc

Bemærk: versionsnavne/<DIST>-mapper følger din distribution – se den aktuelle vejledning i KIWI-dokumentationen og Keg-dokumentationen.

Organiser repo'et, så basen og profilerne er adskilt:

org-images/
├── base/                    # fælles grundlag for alle profiler
│   ├── images.yaml          # imagemetadata, repos, disklayout
│   ├── config.sh            # post-install tilretninger i chroot
│   └── root/                # filer, der kopieres 1:1 ind i image
├── profiles/
│   ├── standalone/
│   ├── firma-base/
│   ├── afdeling-okonomi/
│   └── hjem-felt/
└── .obs/                    # OBS-multibuild: ét subbuild pr. profil

Keg genererer en samlet KIWI-beskrivelse (config.xml/*.kiwi) pr. profil:

# Generér KIWI-beskrivelse for firma-base
keg --recipes-dir org-images --image firma-base --out-dir out/firma-base
 
# Kontrollér resultatet
kiwi-ng --help   # validerings- og build-kommandoer se KIWI-manualen

Regler for repo'et:

• Alt, der er sandt for alle maskiner, ligger i base/. En profil må kun indeholde differenser.
• Ingen hemmeligheder i repo'et (nøgler, kodeord) – se Appendix B.
• Én merge = én rebuild; commit-besked følger profil og formål.

Lokalt build (til test og USB):

# Eksempel: build af et OEM-diskimage fra en beskrivelse
sudo kiwi-ng --type oem system build \
  --description out/firma-base \
  --set-repo https://download.opensuse.org/distribution/leap/16.0/repo/oss \
  --target-dir /var/tmp/build-firma-base

Byg i OBS (anbefalet for produktion):

1. Opret projekt (evt. internt OBS) og pakke pr. profil med _service-opsætning, der trækker Keg-recipes fra Git.
2. Aktivér multibuild med ét subpackage pr. profil (base.image, firma-base.image, …). OBS bygger images med KIWI og genbygger automatisk ved pakkeopdateringer.
3. Publicér resultaterne via OBS' download-repo eller spejl til boot-serveren med rsync/osc getbinaries.

Bemærk: OBS udelukker som standard byg uden profil – brug osc build -M <profil> til lokale testbyg. Mere om OBS+KIWI i KIWI-manualens OBS-kapitel.

Test før alt andet: boot det færdige image i QEMU, før det nogensinde rører fysisk hardware:

sudo qemu-system-x86_64 -boot c \
  -drive file=firma-base.x86_64-*.raw,format=raw,if=virtio \
  -m 4096 -serial stdio

Følg den officielle SLES 16 PXE-server-vejledning som ramme; opsummeret:

1. DHCP (eller proxy-DHCP, så eksisterende DHCP-bevares): next-server + boot-filnavn pr. klientarkitektur (grubx64.efi/shim til UEFI, grub2-i386-pc til legacy BIOS). Kea eller dhcp-server-pakken.
2. TFTP (tftp-pakken eller dnsmasq indbygget) med GRUB2-filer under /srv/tftpboot/.
3. HTTP (nginx) til det tunge indhold: kernel, initrd, squashfs/agama-image og selve disk-imagene. TFTP er kun til bootloaderen.
4. GRUB2-menu med profilvalg – se eksempel nedenfor.
5. Tilføj shim i TFTP-roden for UEFI Secure Boot-maskiner.

Eksempel på GRUB2-menu med profilvalg:

set default=0
set timeout=10

menuentry "Firma-PC (standard)" {
    linuxefi /images/firma-base/linux root=live:http://pxe.example.com/images/firma-base/rootfs.img
    initrdefi /images/firma-base/initrd
}
menuentry "Økonomi-afdelingen" {
    linuxefi /images/afdeling-okonomi/linux root=live:http://pxe.example.com/images/afdeling-okonomi/rootfs.img
    initrdefi /images/afdeling-okonomi/initrd
}
menuentry "Hjemmearbejdsplads" {
    ...
}
menuentry "Lokal disk (ingen udrulning)" {
    exit 1   # GRUB2 falder tilbage til næste boot-prioritet
}

Klientproceduren (hvad teknikeren gør på maskinen) følger SLES 16 PXE-klient-vejledningen: vælg netværksboot i firmware → vælg profil i menuen → resten kører selv.

openSUSE-ækvivalenter: SDB: PXE boot installation og UEFI HTTP Boot-server-setup.

iPXE kan chainloades fra standard PXE og giver HTTP(S)-overførsel, scripting og bedre fejlmeddelelser. openSUSE-wikien har en dedikeret iPXE-side; generelt: ipxe.org-dokumentation.

# iPXE-script (serveres via HTTP)
#!ipxe
menu Vælg profil
item firma Firma-PC (standard)
item okonomi Økonomi-afdelingen
choose target && goto ${target}

:firma
kernel http://pxe.example.com/images/firma-base/linux root=live:http://pxe.example.com/images/firma-base/rootfs.img
initrd http://pxe.example.com/images/firma-base/initrd
boot

Brug iPXE i overgangsperioder (ældre BIOS-maskiner, WAN-link over TFTP-grænser) og til hurtig omskiftning af boot-menu uden TFTP-rod.

Til standalone-pc'er, feltenheder og som fallback:

# 1) Skriv det færdige image direkte (ren kopi, hurtigst)
sudo dd if=firma-base.x86_64-1.16.0.raw of=/dev/sdX bs=4M status=progress conv=fsync
 
# Alternativ: ISO-varianten (live) til maskiner, der skal rulle disk-image ud
sudo dd if=firma-base-live.iso of=/dev/sdX bs=4M status=progress conv=fsync

For en USB-nøgle med flere profiler (uden at skrive hele diske): byg et lille “boot-vælger”-image (KIWI type=“iso” med GRUB2-menu, hvis menuentries peger på kernel/initrd/diskimages liggende som filer på samme nøgle) – eller brug ISO-varianten pr. profil. GRUB2-menuen er identisk med PXE-menuen, så brugeroplevelsen er ens på tværs af boot-veje.

Brugervejledning (kort, til slutbruger):

1. Sæt USB-nøglen i og tænd maskinen (evt. vælg boot-menu med F12/F11/Esc).
2. Vælg din profil i menuen og tryk Enter.
3. Første boot tager 5–15 min (diskimage skrives, maskinen genstarter).
4. Log ind med din organisationsbruger. Ved hjemmearbejdspladsen: sæt din FIDO2-nøgle i ved login. Færdig.

På ARM-boards erstatter U-Boot PC'ens firmware. Den gode nyhed: U-Boot har en distro-agnostisk boot-mekanisme (“distro boot”), der læser standardkonfiguration fra USB/SD – samme mekanismer som GRUB2.

1. Keg/KIWI bygger image til aarch64 (samme beskrivelse, anden arkitektur).
2. På boot-mediet lægges en extlinux.conf (eller boot.scr) – se eksempel nedenfor.

# /boot/extlinux/extlinux.conf på USB-partitionen (ext4)
label firma-base
    kernel /boot/Image
    initrd /boot/initrd
    append root=UUID=<uuid> rw console=ttyAMA0

U-Boot's boot_targets-rækkefølge sørger for usb0 → mmc0 → dhcp osv.; på boards med leverandør-U-Boot genoprettes default-miljøet (env default -a; saveenv), hvis boot skal “distro-styres”. Netværksboot findes også her: bootcmd_pxe/bootcmd_dhcp gør det samme som PC-PXE.

Overordnet dokumentation: docs.u-boot.org.

Image'et er “fabrikstilstand”; til det organisatoriske gøres ved første boot:

• cloud-init/Combustion: hostname pr. serienummer/MAC, LUKS-oprettelse ved behov, NetBird-enrol-nøgle (engangs-token), Uyuni bootstrap.
• Uyuni: Salt aktiveres og maskinen kontakter Uyuni-serveren → patch-status og compliance synligt fra dag ét; efterfølgende policy: maskine uden opdateringer inden for fristen mister NetBird-peering (jf. referencearkitekturen).
• Identitet: brugerlogin mod FreeIPA/Kerberos; web-SSO og MFA via Keycloak.

• Maskinen får ikke boot-fil: journalctl -u dhcpd/kea; tjek next-server/filename, og at klientens arkitektur (BIOS/EFI) matcher.
• GRUB2-menu kommer ikke: grub.cfg-sti/namngivning i TFTP-roden; stole-pil i serielle logs (console=ttyS0).
• Download går langsomt: skift kernel/initrd/rodimage fra TFTP til HTTP (eller iPXE).
• Image booter i QEMU men ikke på hardware: firmware-version/UEFI-opsætning, Secure Boot/shim, RAID/NVMe-drivere i initrd.
• Første boot fejler: første-boot-loggene fra cloud-init/Combustion i /var/log, NetBird/Uyuni-kontakt i journalctl.

1. Indsaml: hvem skal bruge maskinen, hvor, med hvilke data? (Interview 30 min pr. målgruppe.)
2. Klassificér: hvilken profiltype? (Se tabellen i Del 2.) Findes profilen allerede – kan en eksisterende udvides i stedet?
3. Afgræns: hvad skal ind i basen, hvad skal være profil-specifikt? Tommelfingerregel: ind i basen hvis >70 % af alle maskiner har brug for det.
4. Sikkerhedskrav: kategori af data (offentligt/internt/følsomt), lokation (kontor/hjem/felt), → krav til kryptering, MFA, patch-frist.
5. Test-plan: hvilke hardwaretyper skal profilens image bootes på, før den må udrulles? Minimum én af hver.
6. Frigivelse: image-ejer godkender; ændringslog i Git; OBS-byg; pilot før bred udrulning.
7. Evaluering: efter 1 måned – brugertilfredshed, supportsager; justér profilen eller basen.

A.1 Standalone-pc (kontaktworkshop, lab, demonstrationsmaskine) Behov: ingen organisationsintegration, lokal administration, kan fungere offline. Analysefokus: hvem vedligeholder den, hvis der ingen it-tilknytning er? → profil med begrænset levetid eller tvungen auto-opdatering. Faldgrube: standalone-maskiner bliver “forældreløse” med aldrig-opdateret software; overvej rollefordeling eller fælles auto-opdaterings-politik.

A.2 Standard firma-pc (kontor) Behov: fuld integration, ensartethed, hurtig udskiftning. Analysefokus: hvilke apps indgår i “standardskrivebordet”? Find de 2–3 afdelinger med størst overlap og byg basen efter dem – ikke efter flertallet af ønsker (undgå “køkkenvask”-basen). Fokus på onboarding-tid: fra kasse til arbejdsdygtig maskine < 30 min.

A.3 Afdelings-/rolleprofil (fx økonomi, udvikling, design) Behov: firma-base + specialiserede værktøjer/politikker. Analysefokus: er forskellen reelt pakker (så profil i Keg) eller bare indstillinger (så hellere Salt-tilstand i Uyuni – ingen ny image-profil!)? Faldgrube: profil-eksplosion; hver ny profil koster vedligehold, test og byg-tid. Regel: maks. én ny profil pr. kvartal, og kun efter begrundet afvisning af Salt-alternativet.

A.4 Hjemmearbejdsplads Behov: sikkerhed som kontor-PC trods utroværdigt netværk. Analysefokus: hvilke data må arbejdes med hjemmefra? Krav: LUKS fuld diskkryptering, NetBird/WireGuard-tunnel med MFA-enrol, patch-frist (fx 7 dage) håndhævet af Uyuni/NetBird-tilbagekald. Overvej: skal tunge opgaver i stedet køres som fjernskrivebord via Guacamole/Harvester (jf. wikien), så data aldrig forlader datacenteret?

A.5 “Ude i felten” (bærbar, kundebesøg, offshore/dårligt net) Som A.4, plus offline-periode: hvilke funktioner skal kunne afvikles uden forbindelse, og hvor længe? → lokal cache/fil-synkronisering, offline-MFA-fallback (TOTP) jf. referencearkitekturen. Faldgrube: enrolment kræver netværk – onboard maskinen før den forlader huset.

A.6 Kiosk/terminal (fælles maskine, produktionsskærm) Behov: ét formål, ingen personlige data, selvhelbredende. Analysefokus: overvej immutable/transaktionelt OS (openSUSE MicroOS / SLE Micro) – read-only rod, atomiske opdateringer, automatisk rollback. Genstart = altid velkendt tilstand. Her kan profildefinitionen være ekstremt lille.

A.7 ARM/edge og devices med U-Boot Behov: hardware uden PC-firmware. Analysefokus: hvilket board (per U-Boot-version), boot-medie (USB/SD/eMMC), og skal det kunne netværksbootes? Keg-beskrivelsen genbruges til aarch64; test-matrix skal indeholde netop boardet, da U-Boot-varianter afviger. Faldgrube: leverandør-U-Boot med holdt boot-forsinkelse eller skjulte kommandoer – dokumentér nøjagtige tastetryk pr. board.

• Forside/start på wiki.smarken.dk
• Sikker fjernadgang med åben kildekode - referencearkitektur (totalloesningpoc)
• PC-deploy: installationstyper (manuel, image, AutoYaST/Agama)

• KIWI-eksempler/byg-test: build-tests/-mappen i OSInside/kiwi-repoet – den hurtigste start på en egen beskrivelse.
• Sikkerhedsstacken (NetBird, Keycloak, FreeIPA, Uyuni, Guacamole, Wazuh m.m.): referencearkitektur har den fulde, kategoriserede linkliste.

Redaktionel note: Alle eksterne links er verificerede pr. oktober 2026. DokuWiki genererer automatisk indholdsfortegnelse ud fra overskrifterne ( ====== til === ) .