===== Tilpasning af et deployet image =====

Et præ-fabrikeret image er – i modsætning til en rigtig installation – **bitidentisk på alle maskiner**. Det er dets styrke, men også dets svaghed: efter deploy skal hver maskine individualiseres, for ellers deler alle kloner samme identitet.

==== Hvad skal altid tilpasses? ====

Et klonet image deler typisk følgende med "originalen", og det skal rettes pr. maskine:

^ Post ^ Fil/mekanisme ^ Hvorfor det er et problem ^
| Hostname | ''/etc/hostname'' | Alle maskiner hedder det samme |
| Machine-ID | ''/etc/machine-id'' | DHCP, journald og andre tjenester kan ikke skelne maskinerne |
| SSH host-nøgler | ''/etc/ssh/ssh_host_*'' | Klonede nøgler = sikkerhedsproblem og host-key-advarsler |
| Netværkskonfig | ''/etc/sysconfig/network/'', NetworkManager | Statiske IP'er/MAC-bindinger fra originalen følger med |
| Brugere & nøgler | ''/etc/passwd'', ''authorized_keys'' | Samme adgangsdata overalt |

==== Maskinnavn (hostname) ====

Den manuelle metode efter deploy er simpel:

<code bash>
sudo hostnamectl set-hostname pc-aarhus-01
</code>

Men den **rigtige løsning** er at lade en first-boot-mekanisme gøre det automatisk. SUSE's images understøtter tre veje, jf. [[https://documentation.suse.com/sles/16.0/html/SLES-Minimal-VM/|SLES Minimal VM-dokumentationen]]:

  * **JeOS Firstboot** – interaktiv guide ved første boot, hvor du selv taster hostname, sprog og root-adgangskode. Velegnet til enkeltmaskiner.
  * **Combustion** – fuldautomatisk: et script (''combustion.iso'' eller ''fw_cfg'') køres ved første boot og kan sætte hostname, brugere, SSH-nøgler osv. uden menneskelig indgriben.
  * **cloud-init** – bruges på cloud-images; en ''user-data''-fil leverer hostname, brugere, SSH-nøgler og kommandoer, fx:

<code yaml>
#cloud-config
hostname: pc-aarhus-01
fqdn: pc-aarhus-01.firma.dk
users:
  - name: soeren
    sudo: ALL=(ALL) NOPASSWD:ALL
    ssh_authorized_keys:
      - ssh-ed25519 AAAA... soeren@laptop
</code>

**Vigtigt ved klonede images:** cloud-init/Combustion rydder selv machine-ID og SSH host-nøgler. Gør du det manuelt, skal du selv slette ''/etc/machine-id'' (og lade systemd generere en ny) og regenerere host-nøgler med ''rm /etc/ssh/ssh_host_* && ssh-keygen -A'' – ellers svarer alle kloner på samme identitet.

==== Tilføjelse af brugere ====

  * **Ved deploy (anbefalet):** brugere defineres i cloud-init ''user-data'', Combustion-scriptet eller AutoYaST/Agama-profilen, så de findes fra første boot – inkl. sudo-rettigheder og SSH-nøgler.
  * **Efter deploy:** klassisk ''useradd''/''usermod'' (eller ''useraddctl'' i SLES 16) – fint til enkeltmaskiner, men det bryder med idéen om reproducerbarhed: maskinen afviger nu fra imaget, og det skal dokumenteres.
  * **Bæredygtig tilgang:** læg fælles brugerstyring i konfigurationsstyring (Ansible, Salt) eller kobling til LDAP/AD/FreeIPA, så brugere ikke "bagt ind" i hvert image.

==== Når imaget er blevet for gammelt ====

Et image er et statisk øjebliksbillede: pakker, certifikater, GPG-nøgler og repos fryses på byggetidspunktet. Der er tre strategier:

**a) Opdatere i stedet for at gen-bygge (nødløsning)**
Boot imaget, kør ''zypper dup'' (eller ''zypper up'' på SLES / ''transactional-update'' på MicroOS), og deployér derefter. Ulemper: tager tid pr. maskine, afviger fra "golden master", og meget gamle images kan have udløbne repo-nøgler eller OS-versioner, der kræver springvis migration.

**b) Regelmæssig genopbygning (anbefalet)**
Byg et nyt image med KIWI efter en fast cadence (fx hver 1.–3. måned, eller ved hver servicepack), gerne automatiseret via OBS eller CI. Så er patch-niveauet altid frisk, og deployment forbliver hurtig. Det er samme filosofi som container-images: **et image bør betragtes som forbrugsgods, ikke som en permanent installation**.

**c) Reducér selve problemet**
Brug et transactionelt/read-only system (openSUSE MicroOS, SLE Micro), hvor imaget i sagens natur er statisk og opdateringer sker atomisk med rollback – her er "gammelt image" mindre kritisk, fordi opdateringen alligevel sker pr. maskine efter deploy.

**Glem ikke ved SLES:** et klonet image skal også registreres pr. maskine (''SUSEConnect''), ellers deler alle kloner én registrering – ligesom med hostname og machine-ID.

==== Huskeregel ====

Individualisering (hostname, machine-ID, SSH-nøgler, brugere) hører hjemme i **first-boot-mekanismen** (cloud-init/Combustion/JeOS Firstboot), ikke i selve imaget. Og imagets "alder" håndteres bedst ved **regelmæssig genopbygning** snarere end ved at lappe et gammelt image i drift – undtagen helt nye images, hvor cloud-init/Combustion fint kan trække nyeste opdateringer ved første boot.