Abilitazione del login automatico e impostazione di un hostname personalizzato

Assicurati di aver completato i passaggi descritti nella pagina di configurazione iniziale prima di iniziare questo tutorial.

Provisioning di Fedora CoreOS

Fedora CoreOS non ha un disco di installazione separato. Invece, ogni istanza inizia da un’immagine disco generica che viene personalizzata al primo avvio tramite [Ignition](https://github.com/coreos/ignition).

I file di configurazione Ignition sono scritti in JSON ma non sono generalmente facili da usare. Le configurazioni sono quindi scritte in un formato più semplice, il Butane config, che viene poi convertito in un Ignition config. Lo strumento responsabile della conversione dei config Butane in config Ignition si chiama Butane.

Prima configurazione di Ignition tramite Butane

Creiamo una piccola configurazione Butane che eseguirà le seguenti azioni:

  • Aggiungi un dropin di systemd per sovrascrivere l’unità di default serial-getty@ttyS0.service.

  • La sovrascrittura farà sì che il servizio accedi automaticamente l’utente core alla console seriale della macchina avviata.

  • Imposta l’hostname del sistema inserendo un file in /etc/hostname,

  • Aggiungi un profilo bash che indica a systemd di non utilizzare un pager per l’output.

Possiamo ora creare un file di configurazione chiamato autologin.bu come segue:

variant: fcos
version: 1.7.0
systemd:
  units:
    - name: serial-getty@ttyS0.service
      dropins:
      - name: autologin-core.conf
        contents: |
          [Service]
          # Override Execstart in main unit
          ExecStart=
          # Add new Execstart with `-` prefix to ignore failure
          ExecStart=-/usr/sbin/agetty --autologin core --noclear %I $TERM
storage:
  files:
    - path: /etc/hostname
      mode: 0644
      contents:
        inline: |
          tutorial
    - path: /etc/profile.d/systemd-pager.sh
      mode: 0644
      contents:
        inline: |
          # Tell systemd to not use a pager when printing information
          export SYSTEMD_PAGER=cat

Questa configurazione può quindi essere convertita in una configurazione Ignition con Butane:

butane --pretty --strict autologin.bu --output autologin.ign

La configurazione Ignition risultante prodotta da Butane come autologin.ign ha il seguente contenuto:

{
  "ignition": {
    "version": "3.4.0"
  },
  "storage": {
    "files": [
      {
        "path": "/etc/hostname",
        "contents": {
          "compression": "",
          "source": "data:,tutorial%0A"
        },
        "mode": 420
      },
      {
        "path": "/etc/profile.d/systemd-pager.sh",
        "contents": {
          "compression": "",
          "source": "data:,%23%20Tell%20systemd%20to%20not%20use%20a%20pager%20when%20printing%20information%0Aexport%20SYSTEMD_PAGER%3Dcat%0A"
        },
        "mode": 420
      }
    ]
  },
  "systemd": {
    "units": [
      {
        "dropins": [
          {
            "contents": "[Service]\n# Override Execstart in main unit\nExecStart=\n# Add new Execstart with `-` prefix to ignore failure\nExecStart=-/usr/sbin/agetty --autologin core --noclear %I $TERM\n",
            "name": "autologin-core.conf"
          }
        ],
        "name": "serial-getty@ttyS0.service"
      }
    ]
  }
}

Butane emette configurazioni Ignition valide. Tuttavia, se si sta modificando la configurazione dopo Butane o si creano manualmente le configurazioni Ignition, sarà necessario verificare che il formato della configurazione sia valido con ignition-validate:

ignition-validate autologin.ign && echo 'Success!'

Avvio di Fedora CoreOS

Ora che abbiamo una configurazione Ignition, possiamo avviare una macchina virtuale con essa. Questo tutorial utilizza l’immagine QEMU con libvirt, ma dovresti essere in grado di utilizzare la stessa configurazione Ignition su tutte le piattaforme supportate da Fedora CoreOS.

Utilizziamo virt-install per creare una nuova macchina virtuale Fedora CoreOS con una configurazione specifica:

# Imposta l'etichetta SELinux corretta per consentire l'accesso alla configurazione
chcon --verbose --type svirt_home_t autologin.ign

# Avvia una macchina virtuale Fedora CoreOS
virt-install --name=fcos --vcpus=2 --ram=2048 --os-variant=fedora-coreos-stable \
    --import --network=bridge=virbr0 --graphics=none \
    --qemu-commandline="-fw_cfg name=opt/com.coreos/config,file=${PWD}/autologin.ign" \
    --disk="size=20,backing_store=${PWD}/fedora-coreos.qcow2"

Il comando virt-install avvierà un’istanza denominata fcos dall’immagine fedora-coreos.qcow2 utilizzando la configurazione Ignition autologin.ign. Esso si collegherà automaticamente alla console seriale della macchina, permettendoti di visualizzare i messaggi di avvio dell’immagine.

Utilizziamo l’opzione backing_store in virt-install --disk per creare rapidamente una nuova immagine disco ed evitare di scrivere sull’immagine originale che abbiamo scaricato. Questa nuova immagine disco può essere facilmente eliminata.

A seconda della tua versione di virt-install, potresti non essere in grado di utilizzare --os-variant=fedora-coreos-stable e ricevere un errore. In tal caso, dovresti scegliere una variante di Fedora più vecchia (ad esempio --os-variant=fedora31). Puoi trovare le varianti supportate dalla tua versione corrente di virt-install con osinfo-query os | grep '^\s*fedora'.

Una volta che la macchina è avviata, dovresti vedere alcuni prompt e poi essere automaticamente autenticato e presentato con una shell bash:

Fedora CoreOS 38.20230709.3.0
Kernel 6.3.11-200.fc38.x86_64 on an x86_64 (ttyS0)

SSH host key: SHA256:Eq0GiuflXh/3E+9h689DV4K2C0VQZ5UsXXfbJ7nB4rw (ECDSA)
SSH host key: SHA256:53uunBzHa2kfCO20q8h4cFeM19QRSscwUWUPoL4BP+4 (ED25519)
SSH host key: SHA256:HXrypq4OjKQ267RPhpptulMMYwsnrVWW3PYuvkIyt3k (RSA)
Ignition: ran on 2023/08/03 15:59:14 UTC (this boot)
Ignition: user-provided config was applied
No SSH authorized keys provided by Ignition or Afterburn
tutorial login: core (automatic login)

Fedora CoreOS 38.20230709.3.0
[core@tutorial ~]$

Verifichiamo che la nostra configurazione sia stata applicata correttamente. Dato che siamo stati automaticamente autenticati sul terminale, possiamo presumere con sicurezza che il dropin di systemd sia stato creato:

[core@tutorial ~]$ systemctl cat serial-getty@ttyS0.service
# /usr/lib/systemd/system/serial-getty@.service
...

# /etc/systemd/system/serial-getty@ttyS0.service.d/autologin-core.conf
[Service]
# Override Execstart in main unit
ExecStart=
# Add new Execstart with `-` prefix to ignore failure
ExecStart=-/usr/sbin/agetty --autologin core --noclear %I $TERM

Possiamo anche verificare che l’hostname sia stato impostato correttamente:

[core@tutorial ~]$ cat /etc/hostname
tutorial
[core@tutorial ~]$ hostnamectl
     Static hostname: tutorial
           Icon name: computer-vm
             Chassis: vm 🖴
          Machine ID: fc4c5d5a14a741babe20559a25dcb846
             Boot ID: 22ed3b3c049d42968fb6ca9e35c8055d
      Virtualization: kvm
    Operating System: Fedora CoreOS 38.20230709.3.0
         CPE OS Name: cpe:/o:fedoraproject:fedora:38
      OS Support End: Tue 2024-05-14
OS Support Remaining: 9month 1w 3d
              Kernel: Linux 6.3.11-200.fc38.x86_64
        Architecture: x86-64
     Hardware Vendor: QEMU
      Hardware Model: Standard PC _Q35 + ICH9, 2009_
    Firmware Version: 1.16.2-1.fc38
       Firmware Date: Tue 2014-04-01

Esplorando gli interni di Fedora CoreOS

Una volta che abbiamo accesso alla console della macchina possiamo navigare un po' per vedere alcuni dei diversi componenti del sistema operativo. Ad esempio, anche se si tratta di un sistema basato su OSTree, è stato comunque composto tramite RPM e possiamo ispezionare il sistema per vedere di cosa è composto:

[core@tutorial ~]$ rpm -q ignition kernel moby-engine podman systemd rpm-ostree zincati
ignition-2.15.0-3.fc38.x86_64
kernel-6.3.11-200.fc38.x86_64
moby-engine-20.10.23-1.fc38.x86_64
podman-4.5.1-1.fc38.x86_64
systemd-253.4-1.fc38.x86_64
rpm-ostree-2023.5-1.fc38.x86_64
zincati-0.0.25-4.fc38.x86_64

Possiamo anche ispezionare la revisione corrente di Fedora CoreOS:

[core@tutorial ~]$ rpm-ostree status
State: idle
AutomaticUpdatesDriver: Zincati
  DriverState: active; periodically polling for updates (last checked Thu 2023-08-03 15:59:23 UTC)
Deployments:
● fedora:fedora/x86_64/coreos/stable
                  Version: 38.20230709.3.0 (2023-07-24T12:25:01Z)
                   Commit: 552de26fe0fe6a5e491f7a4163db125e3d44b144ae53a8f5f488e3f8481c46f9
             GPGSignature: Valid signature by 6A51BBABBA3D5467B6171221809A8D7CEB10B464

E controllare zincati.service, che comunica con il nostro server di aggiornamento e dice a rpm-ostree quando eseguire un aggiornamento e a quale versione aggiornare:

[core@tutorial ~]$ systemctl status --full zincati.service
● zincati.service - Zincati Update Agent
     Loaded: loaded (/usr/lib/systemd/system/zincati.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Thu 2023-08-03 16:06:39 UTC; 18s ago
       Docs: https://github.com/coreos/zincati
   Main PID: 1843 (zincati)
     Status: "periodically polling for updates (last checked Thu 2023-08-03 16:06:39 UTC)"
      Tasks: 6 (limit: 2238)
     Memory: 2.8M
        CPU: 257ms
     CGroup: /system.slice/zincati.service
             └─1843 /usr/libexec/zincati agent -v

Aug 03 16:06:39 tutorial systemd[1]: Starting zincati.service - Zincati Update Agent...
Aug 03 16:06:39 tutorial zincati[1843]: [INFO  zincati::cli::agent] starting update agent (zincati 0.0.25)
Aug 03 16:06:39 tutorial zincati[1843]: [INFO  zincati::cincinnati] Cincinnati service: https://updates.coreos.fedoraproject.org
Aug 03 16:06:39 tutorial zincati[1843]: [INFO  zincati::cli::agent] agent running on node '8fb5386cba574235a21ad3b2d59885d9', in update group 'default'
Aug 03 16:06:39 tutorial zincati[1843]: [INFO  zincati::update_agent::actor] registering as the update driver for rpm-ostree
Aug 03 16:06:39 tutorial zincati[1843]: [INFO  zincati::update_agent::actor] initialization complete, auto-updates logic enabled
Aug 03 16:06:39 tutorial zincati[1843]: [INFO  zincati::strategy] update strategy: immediate
Aug 03 16:06:39 tutorial systemd[1]: Started zincati.service - Zincati Update Agent.
Aug 03 16:06:39 tutorial zincati[1843]: [INFO  zincati::update_agent::actor] reached steady state, periodically polling for updates
Aug 03 16:06:41 tutorial zincati[1843]: [INFO  zincati::cincinnati] current release detected as not a dead-end

Un’altra cosa interessante da fare è visualizzare i log di Ignition nel caso ci sia qualcosa di interessante che potremmo voler investigare:

journalctl -t ignition

E infine, ovviamente possiamo usare il comando podman (o docker) per ispezionare lo stato corrente dei container sul sistema:

podman version
podman info
I comandi podman possono essere eseguiti come root o come utente non-root. I comandi docker devono essere eseguiti come root tramite sudo a meno che l’utente non sia stato aggiunto al gruppo docker.
L’esecuzione di container tramite docker e podman contemporaneamente può causare problemi e comportamenti imprevisti. Fare riferimento alla Voce FAQ per ulteriori dettagli.
Il demone Docker non viene avviato per impostazione predefinita, ma l’esecuzione di qualsiasi comando docker lo avvierà in quanto è socket attivato tramite systemd.

Spegnimento della Macchina Virtuale

Eliminiamo ora quella macchina virtuale in modo da poter ricominciare da zero. Prima disconnettiti dalla console seriale premendo CTRL + ] e poi digita:

virsh destroy fcos
virsh undefine --remove-all-storage fcos

Puoi ora procedere con il secondo tutorial.

Want to help? Learn how to contribute to Fedora Docs ›