Differences

This shows you the differences between two versions of the page.

--- teknik:operativsystemer:deploy:bygditegetos [2026/10/18 22:49] – created smarken
+++ teknik:operativsystemer:deploy:bygditegetos [2026/10/19 05:10] (current) – [Byg din egen Linux-distribution – til din organisation] smarken
@@ Line 1: / Line 1: @@
-Lav din egen Linux-distribution – til din organisation
+====== Byg din egen Linux-distribution – til din organisation ======
+**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 [[teknik:infrastruktur:totalloesningpoc|den eksisterende referencearkitektur på wiki.smarken.dk]].//
+**Se også :**
+  * [[start|Forside/start på wiki.smarken.dk]]
+  * [[teknik:infrastruktur:totalloesningpoc|Sikker fjernadgang med åben kildekode - referencearkitektur (totalloesningpoc)]]
+  * [[teknik:operativsystemer:deploy:start|PC-deploy: installationstyper (manuel, image, AutoYaST/Agama)]]
+----
+====== Del 1 – Den korte version (for ledelse og beslutningstagere) ======
+===== Hvad handler det om? =====
+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.
+===== Hvorfor er det en god forretning? =====
+  * **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.
+===== Hvad koster det? =====
+Der er tre poster:
+  - **Mennesker.** Én til to medarbejdere, der lærer værktøjerne (der er rigelig, gratis dokumentation – se Del 4). Det er den vigtigste investering.
+  - **Infrastruktur.** Én byggeserver (kan være en virtuel maskine) og eventuelt en boot-server pr. lokation. Beskeden hardware.
+  - **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.
+===== Hvad skal ledelsen beslutte? =====
+  * **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.
+===== Hvad er de største risici – og hvad gør vi ved dem? =====
+  * **"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.
+----
+====== Del 2 – Teknisk strategi (for it-chefer og teknisk funderede mellemledere) ======
+===== Værktøjskæden i oversigt =====
+^ Lag ^ Værktøj ^ Rolle ^
+| Kilde/beskrivelse | **Keg** (image description generator) | Modulære "opskrifter" (recipes) på YAML-basis, der genererer KIWI-beskrivelser. Skalering af mange profiler med stort overlap. |
+| Byggeværktøj | **KIWI (KIWI NG)** | Bygger det færdige image (raw-disk, ISO, cloud-image osv.) ud fra beskrivelsen. SUSE's eget appliance-værktøj. |
+| Byggeinfrastruktur | **Open Build Service (OBS)** | Central build-server, der genbygger images automatisk, når pakker opdateres; versionsstyring af artefakter; reproducible builds. Kan være self-hostet eller build.opensuse.org. |
+| Udrulning/boot | **PXE/HTTP-boot, iPXE, GRUB2, U-Boot** | Netværksboot til masseudrulning; USB til standalone og feltenheder; U-Boot på ARM-hardware. |
+| Drift/security | **Uyuni/Salt, NetBird/WireGuard, Keycloak/FreeIPA** | Registrering, patch-styring, zero trust-netværk og identitet – jf. wikien. |
+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.**
+{{ :teknik:operativsystemer:deploy:bygditos.png?700 |}}
+===== Hvorfor Keg + KIWI + OBS frem for håndbyggede images? =====
+  * **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.
+===== Boot- og distributionsstrategi =====
+Der er fire boot-veje, som bør betragtes som én samlet løsning med fælles indhold:
+  - **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.
+  - **UEFI HTTP Boot.** Nyere firmware kan hente bootloader direkte over HTTP(S) – fjerner TFTP's hastigheds- og skaleringsproblemer.
+  - **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.
+  - **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.
+===== Profilmodel =====
+^ Profil ^ Formål ^ Kendetegn ^
+| ''standalone'' | Fristående pc uden organisationsintegration (workshop, laboratorium, gæst) | Ingen registrering, lokal admin, evt. offentligt netværk |
+| ''firma-base'' | Standard arbejdsstation på kontoret | Registrering i Uyuni, SELinux enforcing, LUKS, organisationsapps |
+| ''afdeling-*'' | Firma-base + afdelingens værktøjer (fx ''afdeling-okonomi'', ''afdeling-udvikling'') | Arver base, tilføjer pakker/politikker; hold antallet nede – se Appendix A/B |
+| ''hjem/felt'' | Bærbar til hjemmearbejde og "ude i felten" | Alt i ''firma-base'' + NetBird/WireGuard-tunnel, MFA-onboarding, hårdere patch-frister |
+Sikkerheden for ''hjem/felt'' følger den eksisterende [[https://wiki.smarken.dk/doku.php?id=teknik:infrastruktur:totalloesningpoc|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 [[https://wiki.smarken.dk/doku.php?id=teknik:operativsystemer:deploy:start|wikiens deploy-overblik]]; dette dokument uddyber image-sporet (KIWI), som er det hurtigste og mest reproducerbare.
+===== Livscyklus og drift =====
+  * **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.
+===== Roller =====
+  * **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.
+===== Estimat og plan (tommelfingerregler) =====
+  - **Uge 1–2:** OBS + Git-repo op, base-image bygger.
+  - **Uge 3–4:** PXE/HTTP + USB-boot med profilmenu virker på pilot-hardware.
+  - **Uge 5–8:** Firma-profiler + Uyuni-registrering + NetBird-enrol til hjem/felt-profil.
+  - **Uge 9–12:** Pilot på 10–15 maskiner, justering af profiler, dokumentation.
+  - **Derefter:** bred udrulning afdeling for afdeling.
+----
+====== Del 3 – Detaljeret instruktion (for teknikere og brugere) ======
+===== 3.0 Forudsætninger =====
+  * É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.
+===== 3.1 Værktøjerne på byggeværten =====
+<code bash>
+# 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
+</code>
+//Bemærk:// versionsnavne/''<DIST>''-mapper følger din distribution – se den aktuelle vejledning i [[https://documentation.suse.com/appliance/kiwi-9/single-html/kiwi/|KIWI-dokumentationen]] og [[https://documentation.suse.com/appliance/keg-2/|Keg-dokumentationen]].
+===== 3.2 Struktur: Keg-recipes =====
+Organiser repo'et, så **basen** og **profilerne** er adskilt:
+<code>
+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
+</code>
+Keg genererer en samlet KIWI-beskrivelse (''config.xml''/''*.kiwi'') pr. profil:
+<code bash>
+# 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
+</code>
+**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.
+===== 3.3 Byg image med KIWI =====
+Lokalt build (til test og USB):
+<code bash>
+# 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
+</code>
+Byg i OBS (anbefalet for produktion):
+  - Opret projekt (evt. internt OBS) og pakke pr. profil med ''_service''-opsætning, der trækker Keg-recipes fra Git.
+  - Aktivér **multibuild** med ét subpackage pr. profil (''base.image'', ''firma-base.image'', …). OBS bygger images med KIWI og genbygger automatisk ved pakkeopdateringer.
+  - 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 [[https://documentation.suse.com/appliance/kiwi-9/html/kiwi/working-with-images.html|KIWI-manualens OBS-kapitel]].
+**Test før alt andet:** boot det færdige image i QEMU, før det nogensinde rører fysisk hardware:
+<code bash>
+sudo qemu-system-x86_64 -boot c \
+  -drive file=firma-base.x86_64-*.raw,format=raw,if=virtio \
+  -m 4096 -serial stdio
+</code>
+===== 3.4 PXE/netværksboot-server =====
+Følg den officielle [[https://documentation.suse.com/sles/16.0/html/SLES-PXE-server/index.html|SLES 16 PXE-server-vejledning]] som ramme; opsummeret:
+  - **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.
+  - **TFTP** (tftp-pakken eller dnsmasq indbygget) med GRUB2-filer under ''/srv/tftpboot/''.
+  - **HTTP (nginx)** til det tunge indhold: kernel, initrd, squashfs/agama-image og selve disk-imagene. TFTP er kun til bootloaderen.
+  - **GRUB2-menu** med profilvalg – se eksempel nedenfor.
+  - Tilføj **shim** i TFTP-roden for UEFI Secure Boot-maskiner.
+Eksempel på GRUB2-menu med profilvalg:
+<code>
+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
+}
+</code>
+//Klientproceduren// (hvad teknikeren gør på maskinen) følger [[https://documentation.suse.com/sles/16.0/html/SLES-deployment-pxe-client/index.html|SLES 16 PXE-klient-vejledningen]]: vælg netværksboot i firmware → vælg profil i menuen → resten kører selv.
+openSUSE-ækvivalenter: [[https://en.opensuse.org/SDB:PXE_boot_installation|SDB: PXE boot installation]] og [[https://en.opensuse.org/UEFI_HTTPBoot_Server_Setup|UEFI HTTP Boot-server-setup]].
+===== 3.5 iPXE (kædeled og debugging) =====
+iPXE kan chainloades fra standard PXE og giver HTTP(S)-overførsel, scripting og bedre fejlmeddelelser. openSUSE-wikien har en [[https://en.opensuse.org/SDB:IPXE_booting|dedikeret iPXE-side]]; generelt: [[https://ipxe.org/docs|ipxe.org-dokumentation]].
+<code>
+# 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
+</code>
+Brug iPXE i overgangsperioder (ældre BIOS-maskiner, WAN-link over TFTP-grænser) og til hurtig omskiftning af boot-menu uden TFTP-rod.
+===== 3.6 USB-boot med GRUB2-profilmenu =====
+Til standalone-pc'er, feltenheder og som fallback:
+<code bash>
+# 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
+</code>
+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):**
+  - Sæt USB-nøglen i og tænd maskinen (evt. vælg boot-menu med F12/F11/Esc).
+  - Vælg din profil i menuen og tryk Enter.
+  - Første boot tager 5–15 min (diskimage skrives, maskinen genstarter).
+  - Log ind med din organisationsbruger. Ved hjemmearbejdspladsen: sæt din FIDO2-nøgle i ved login. Færdig.
+===== 3.7 U-Boot fra USB-enhed (ARM/edge) =====
+På ARM-boards erstatter U-Boot PC'ens firmware. Den gode nyhed: U-Boot har en distro-agnostisk boot-mekanisme ("[[https://docs.u-boot.org/en/latest/develop/distro.html|distro boot]]"), der læser standardkonfiguration fra USB/SD – samme mekanismer som GRUB2.
+  - Keg/KIWI bygger image til ''aarch64'' (samme beskrivelse, anden arkitektur).
+  - På boot-mediet lægges en **extlinux.conf** (eller ''boot.scr'') – se eksempel nedenfor.
+<code>
+# /boot/extlinux/extlinux.conf på USB-partitionen (ext4)
+label firma-base
+    kernel /boot/Image
+    initrd /boot/initrd
+    append root=UUID=<uuid> rw console=ttyAMA0
+</code>
+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: [[https://docs.u-boot.org/|docs.u-boot.org]].
+===== 3.8 Første boot: registrering og sikker opsætning =====
+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. [[teknik:infrastruktur:totalloesningpoc|referencearkitekturen]]).
+  * **Identitet**: brugerlogin mod FreeIPA/Kerberos; web-SSO og MFA via Keycloak.
+===== 3.9 Fejlfinding – de første steder man kigger =====
+  * **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''.
+----
+====== Del 4 – Appendikser ======
+===== Appendix A: Behovsanalyse-processen =====
+==== Den generelle proces (alle scenarier) ====
+  - **Indsaml:** hvem skal bruge maskinen, hvor, med hvilke data? (Interview 30 min pr. målgruppe.)
+  - **Klassificér:** hvilken profiltype? (Se tabellen i Del 2.) Findes profilen allerede – kan en eksisterende udvides i stedet?
+  - **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.
+  - **Sikkerhedskrav:** kategori af data (offentligt/internt/følsomt), lokation (kontor/hjem/felt), → krav til kryptering, MFA, patch-frist.
+  - **Test-plan:** hvilke hardwaretyper skal profilens image bootes på, før den må udrulles? Minimum én af hver.
+  - **Frigivelse:** image-ejer godkender; ændringslog i Git; OBS-byg; pilot før bred udrulning.
+  - **Evaluering:** efter 1 måned – brugertilfredshed, supportsager; justér profilen eller basen.
+==== Scenarier ====
+**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.
+===== Appendix B: Faldgruber i processen =====
+^ # ^ Faldgrube ^ Symptom ^ Forebyggelse ^
+| 1 | **Image-drift** – images genbygges aldrig, maskiner "patcher sig selv væk" fra image-tilstand | Nye udrulninger får gammel kernel; svært at bevise systemtilstand i audit | Fast build-cyklus i OBS; "image-alderspolitik": boot-server nægter at serve images ældre end N dage |
+| 2 | **Snapshot-tilstand i stedet for beskrivelse** – nogen retter manuelt i et image efter bygget | Kunne ikke gendannes; differencer uden for Git | Aldrig manuelle ændringer efter byg; alt gennem Keg-repo |
+| 3 | **Hemmeligheder i image/repo** – enrol-nøgler, kodeord bagt ind | Nøgle kompromitteret for alle maskiner | Engangs-tokens pr. maskine (event/batch), hemmeligheder via første-boot-transport, secret-scanning i repo |
+| 4 | **DHCP-kollision i produktion** – en boot-server overtager fx "next-server" på klient-netværket | Pludselig booter //alle// maskiner på netværket mod boot-serveren | proxy-DHCP/option 43-afgrænsning; adskilt VLAN til udrulning; scope-regler godkendt af netværksafdelingen |
+| 5 | **TFTP som flaskehals** – store images over TFTP | Minutlange hængninger, timeouts ved parallel udrulning | Kun bootloader via TFTP; alt andet via HTTP/HTTP-boot/iPXE |
+| 6 | **UEFI Secure Boot** – shim/GRUB2 signaturkæde ikke på plads | "Security Violation"/refuse at boote | Medtag shim i TFTP/USB; test på Secure Boot-aktiveret hardware fra dag ét |
+| 7 | **Firmware/hardware-udfordringer** – image virker på gammel test-maskine, ikke nyere | Kernel mangler driver (NVMe/Wi-Fi), initrd for lille | Test-matrix med repræsentativ ny hardware; opdater build-cyklus ved nyere kerne |
+| 8 | **SLES-registrering ved rå image-kopi** – raw-disk kopieret licensmæssigt ureflekteret | Support/abonnement-tælling utilfreds | Registrer systemer via Uyuni/SUSEConnect ved første boot, ikke i image |
+| 9 | **Profil-eksplosion** – hver lille forskel bliver en ny image-profil | Byg-kø, test-matrix og vedligehold vokser ukontrolleret | Indstillingsforskelle via Salt/Uyuni; kun pakkeforskelle bliver Keg-profiler (se A.3) |
+| 10 | **Manglende før-boot-idé om tid/ur** – HTTPS og cert-godkendelse fejler ved netværksboot | "Certificate expired"/TLS-fejl i boot | NTP (chrony) på boot-server; i hårde tilfælde kilde-tidsafstemning |
+| 11 | **Keg/KIWI-versionskilt** – lokal build virker, OBS (eller omvendt) fejler | Beskrivelse validerer ikke; schemas afviger | Fastgør kiwi/keg-version i OBS-projektets config; CI-test af beskrivelse ved hver ændring |
+| 12 | **Bootloader-arkitekturblanding** – EFI-fil serves til BIOS-maskine eller omvendt | "No bootable device" | GRUB2-pakker til alle målarkitekturer i boot-roden; DHCP-vendor-class-styring |
+| 13 | **Første boot uden netværkskontakt** – maskinen kan ikke enrolle | Lamineret "halvfærdig" maskine | Onboard pipeline-ansvar: maskinen forlader it med succesfuld enrol-test dokumenteret |
+| 14 | **Uoprettelig build-infrastruktur** – OBS-instans/Git-repo uden backup | Genbyg umulig i nedbrudssituation | Backup af Git (mirrors) + OBS-konfiguration; øvelse i genbyg fra backup hvert halve år |
+| 15 | **For lidt pilot** – direkte fuld udrulning på baggrund af tests på 2 maskiner | Organisationsstandsning ved fejl | Minimum 10–15 pilotbrugere pr. profil i ≥2 uger, med definerede exitskriterier |
+===== Appendix C: Linkbibliotek =====
+==== C.1 Interne wikisider (wiki.smarken.dk) ====
+  * [[start|Forside/start på wiki.smarken.dk]]
+  * [[teknik:infrastruktur:totalloesningpoc|Sikker fjernadgang med åben kildekode - referencearkitektur (totalloesningpoc)]]
+  * [[teknik:operativsystemer:deploy:start|PC-deploy: installationstyper (manuel, image, AutoYaST/Agama)]]
+==== C.2 SUSE-dokumentation side om side med openSUSE-dokumentation ====
+^ Emne ^ SUSE (enterprise-dokumentation) ^ openSUSE (fællesskab/upstream) ^
+| KIWI – image-bygning | [[https://documentation.suse.com/appliance/kiwi-9/single-html/kiwi/|Building Linux System Appliances (KIWI 9/NG)]] | [[https://osinside.github.io/kiwi/|KIWI NG upstream-dokumentation (OSInside)]] + [[https://github.com/OSInside/kiwi|OSInside/kiwi på GitHub]] |
+| KIWI + OBS-integration | [[https://documentation.suse.com/appliance/kiwi-9/html/kiwi/working-with-images.html|Working with Images (OBS-kapitel i KIWI-manualen)]] | [[https://en.opensuse.org/openSUSE:Build_Service_Tutorial|openSUSE Build Service-tutorial]] |
+| Keg – image-beskrivelser | [[https://documentation.suse.com/appliance/keg-2/|Keg Image Description Generator 2]] | [[https://github.com/SUSE/keg-recipes|SUSE/keg-recipes på GitHub]] + [[https://www.suse.com/c/create-suse-linux-enterprise-images-for-oci-from-keg-recipes/|artikel: SLE-images fra keg-recipes]] |
+| Open Build Service | [[https://www.suse.com/c/create-suse-linux-enterprise-images-for-oci-from-keg-recipes/|OBS i SUSE-sammenhæng (SLE-images/keg-artikel)]] | [[https://build.opensuse.org|build.opensuse.org]] + [[https://www.openbuildservice.org/|openbuildservice.org]] |
+| PXE-server-setup | [[https://documentation.suse.com/sles/16.0/html/SLES-PXE-server/index.html|Setting Up a PXE Boot Server – SLES 16]] | [[https://en.opensuse.org/SDB:PXE_boot_installation|SDB: PXE boot installation (openSUSE-wiki)]] |
+| PXE-klient/deploy | [[https://documentation.suse.com/sles/16.0/html/SLES-deployment-pxe-client/index.html|Deploying SLES Using Network PXE Boot – SLES 16]] | [[https://www.suse.com/blog/step-by-step-instructions-for-building-a-multiple-architecture-opensuse-leap-pxe-server/|SUSE-blog: Multi-arch openSUSE Leap PXE-server]] |
+| UEFI HTTP Boot | [[https://documentation.suse.com/sles/16.0/html/SLES-PXE-server/index.html|PXE-bootserver (HTTP/nginx-kapitel, SLES 16)]] | [[https://en.opensuse.org/UEFI_HTTPBoot_Server_Setup|UEFI HTTPBoot Server Setup (openSUSE-wiki)]] |
+| Klassisk deploy-/installationsguide | [[https://documentation.suse.com/sles/15-SP6/single-html/SLES-deployment/book-deployment.html|SLES 15 SP6 Deployment Guide]] | [[https://doc.opensuse.org/|openSUSE-dokumentationsportal]] |
+| iPXE | — (SUSE henviser til PXE-standarden; iPXE er upstream) | [[https://en.opensuse.org/SDB:IPXE_booting|SDB: iPXE booting (openSUSE-wiki)]] + [[https://ipxe.org/docs|ipxe.org-dokumentation]] |
+| U-Boot (ARM/USB-boot) | — (SUSE-dokumentation dækker aarch64-installation; se SLES 16-portalen) | [[https://docs.u-boot.org/en/latest/develop/distro.html|U-Boot: Generic Distro Boot Concept]] + [[https://docs.u-boot.org/|docs.u-boot.org]] |
+| Operativsystemet | [[https://documentation.suse.com/en-us/sles/16.0/|SLES 16 – samlet dokumentationsoversigt]] | [[https://doc.opensuse.org/|openSUSE Leap/ALP på doc.opensuse.org]] |
+==== C.3 Øvrige referencer ====
+  * KIWI-eksempler/byg-test: ''build-tests/''-mappen i [[https://github.com/OSInside/kiwi|OSInside/kiwi-repoet]] – den hurtigste start på en egen beskrivelse.
+  * Sikkerhedsstacken (NetBird, Keycloak, FreeIPA, Uyuni, Guacamole, Wazuh m.m.): [[teknik:infrastruktur:totalloesningpoc|referencearkitektur]] har den fulde, kategoriserede linkliste.
+----
+//Redaktionel note: Alle eksterne links er verificerede pr. oktober 2026. DokuWiki genererer automatisk indholdsfortegnelse ud fra overskrifterne ( ====== til === ) .//