wiki.smarken.dk

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:

sudo hostnamectl set-hostname pc-aarhus-01

Men den rigtige løsning er at lade en first-boot-mekanisme gøre det automatisk. SUSE's images understøtter tre veje, jf. 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:

#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

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.

Table of Contents