Habilitar el inicio de sesión automático y configurar un nombre de host personalizado

Asegúrese de que ha completado los pasos descritos en la página inicial de ajuste antes de empezar con este tutorial.

Proporcionar Fedora CoreOS

Fedora CoreOS no tiene un disco de instalación separado. En su lugar, cada instancia comienza a partir de una imagen de disco genérica que se personaliza en el primer arranque por medio de Ignition.

Los archivos config de Ignition se escriben en JSON, pero no suelen ser intuitivos. Por lo tanto, las configuraciones se escriben en un formato más simple, la configuración de Butane, que luego se convierte en una configuración de Ignition. La herramienta encargada de convertir las configuraciones de Butane en configuraciones de Ignition se llama Butane.

El primer config de encendido mediante Butane

Creemos una configuración pequeña de Butane que realizará las siguientes acciones:

  • Añade un dropin systemd para anular el valor predeterminado de serial-getty@ttyS0.service.

  • La anulación hará que el servicio inicie sesión automáticamente al usuario core en la consola serial de la máquina iniciada.

  • Establezca el nombre de host del sistema soltando un archivo en /etc/hostname,

  • Añade un perfil bash que diga a systemd no utilizar un paginador de salida.

Podemos crear un archivo de config con el nombre autologin.bu ahora como:

variant: fcos
version: 1.6.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

Esta configuración puede entonces ser convertida en una configuración de Ignition con Butane:

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

El resultado de la configuración de Ignition producida por Butane como autologin.ign tiene el contenido siguiente:

{
  "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 genera configuraciones de Ignition válidas. Sin embargo, si modifica la configuración después de usar Butane o crea manualmente configuraciones, tendrá que verificar que el formato de configuración sea válido con ignition-validate:

ignition-validate autologin.ign && echo '¡Logrado!'

Arranque con Fedora CoreOS

Ahora que tenemos un config de Ignition, podemos arrancar una máquina virtual con ello. Este tutorial utiliza la imagen QEMU con libvirt pero sería capaz de utilizar la misma config de Ignition en todas las plataformas mantenidas por Fedora CoreOS.

Usamos virt-install para crear una máquina virtual nueva de Fedora CoreOS con una configuración específica:

# Configura la etiqueta SELinux correcta para conceder acceso al config
chcon --verbose --type svirt_home_t autologin.ign

# Inicia una máquina virtual de 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"

El comando virt-install iniciará una instancia nombrada como fcos desde la imagen fedora-coreos.qcow2 usando la config de Ignition autologin.ign. Se adjuntará automáticamente a la consola serial de la máquina tal que será capaz de ver los mensajes de arranque de la imagen.

Usamos la opción backing_store de virt-install --disk para crear rápidamente una imagen de disco nueva y evitar escribir en la imagen original que descargamos. Esta imagen de disco nueva se puede descartar fácilmente.

Depender en su versión de virt-install, tal vez no es capaz de utilizar --os-variant=fedora-coreos-stable y obtendrá un error. En este caso, tomaría una variante Fedora más anterior (--os-variant=fedora31 por ejemplo). Puede encontrar las variantes que están admitidas por ti en la versión actual de virt-install con osinfo-query os | grep '^\s*fedora'.

Una vez que la máquina es arrancada verías unas pocas solicitudes y después automáticamente accedería y sería presentado con un intérprete de 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: ejecutado el 2023/08/03 15:59:14 UTC (este arranque)
Ignition: fue aplicado el config proporcionado por el usuario
No hay claves autorizadas por SSH proporcionadas por Ignition o Afterburn
tutorial login: core (acceso automático)

Fedora CoreOS 38.20230709.3.0
[core@tutorial ~]$

Verifiquemos que nuestra configuración se ha aplicado correctamente. Como hemos iniciado sesión automáticamente en el terminal, podemos suponer con seguridad que se ha creado la visita improvisada de systemd:

[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

También podemos comprobar que el nombre del host se ha configurado correctamente:

[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

Explorar los componentes internos de Fedora CoreOS

Una vez que tengamos acceso a la consola de la máquina, podremos explorar brevemente para ver algunos de los diferentes componentes del sistema operativo. Por ejemplo, aunque este sistema se basa en OSTree, se compuso mediante RPM y podemos inspeccionar el sistema para ver de qué estaba compuesto:

[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

Además podemos inspeccionar la revisión actual de 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

Y comprueba zincati.service, el cual se comunica con nuestro servidor de actualizaciones e indica a rpm-ostree cuando realizar una actualización y a qué versión actualizar:

[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

Una otra cosa interesante para hacer es ver las bitácoras desde Ignition en caso que haya cualquier cosa interesante allí podemos desear investigar:

journalctl -t ignition

Y finalmente, por supuesto, podemos usar el comando podman (o docker) para inspeccionar el estado actual de los contenedores en el sistema:

podman version
podman info
Los comandos podman se pueden ejecutar como root o como usuario no root. Los comandos docker deben ejecutarse como root a través de sudo a menos que el usuario haya sido agregado al grupo docker.
Ejecutar contenedores mediante docker y podman simultáneamente puede causar problemas y generar un comportamiento inesperado. Consulte la entrada de P+F para obtener más detalles.
El demonio Docker no se inicia de manera predeterminada, pero ejecutar cualquier comando docker lo iniciará ya que está activado por socket a través de systemd.

Descolgar la Máquina Virrtual

Ahora eliminemos esa máquina virtual para poder empezar desde cero. Primero, salga de la consola serie presionando CTRL + ] y luego teclee:

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

Ahora puede proceder con el segundo tutorial.