Configurazione dello storage
Fedora CoreOS viene fornito con un layout di archiviazione predefinito semplice: la partizione root è l’ultima e si espande per occupare l’intera dimensione del disco. A parte la partizione di avvio, tutti i dati sono memorizzati nella partizione root. Consulta la sezione [Layout del disco](xref:#_disk_layout) per maggiori dettagli.
Di seguito, forniamo esempi di vari modi in cui puoi personalizzare questo.
|
Fedora CoreOS richiede che il filesystem root sia di almeno 8 GiB. Per motivi pratici, le immagini disco per alcune piattaforme vengono fornite con un filesystem root più piccolo, che per impostazione predefinita si espande automaticamente per riempire tutto lo spazio disponibile. Se aggiungi partizioni aggiuntive dopo il filesystem root, devi assicurarti di ridimensionare esplicitamente la partizione root come mostrato di seguito, affinché sia di almeno 8 GiB. Attualmente, se il filesystem root è più piccolo di 8 GiB, viene visualizzato un avviso al login. A partire da giugno 2021, se il filesystem root è più piccolo di 8 GiB e seguito da un’altra partizione, Fedora CoreOS si rifiuterà di avviarsi. Per maggiori dettagli, vedi [questo bug](https://github.com/coreos/fedora-coreos-tracker/issues/586). |
Riferimento ai dispositivi di blocco da Ignition
Molti degli esempi seguenti faranno riferimento a un dispositivo a blocchi, come /dev/vda. Il nome dei dispositivi a blocchi disponibili dipende dall’infrastruttura sottostante (bare metal o cloud) e, spesso, dallo specifico tipo di istanza. Ad esempio in AWS, alcuni tipi di istanza dispongono di unità NVMe (/dev/nvme*), mentre altri utilizzano /dev/xvda*.
Se la configurazione del disco è semplice e utilizza lo stesso disco da cui è stato avviato il sistema operativo, è possibile utilizzare il link`/dev/disk/by-id/coreos-boot-disk`per fare comodamente riferimento a quel dispositivo. Questo link è disponibile solo durante la fase di provisioning, al fine di facilitare il riferimento allo stesso disco da cui è stato avviato il sistema operativo.
Se hai bisogno di accedere ad altri dischi, puoi avviare una singola macchina con una configurazione Ignition che includa solo l’accesso SSH, per poi ispezionare i dispositivi a blocchi, ad esempio tramite il comando lsblk.
Per l’hardware fisico, si raccomanda di fare riferimento ai dispositivi tramite i link in /dev/disk/by-id/ o /dev/disk/by-path.
Configurazione di punti di montaggio separati per /var
Ecco un esempio di configurazione Butane per impostare /var su una partizione separata dello stesso disco primario:
variant: fcos
version: 1.7.0
storage:
disks:
- # The link to the block device the OS was booted from.
device: /dev/disk/by-id/coreos-boot-disk
# We do not want to wipe the partition table since this is the primary
# device.
wipe_table: false
partitions:
- number: 4
label: root
# Allocate at least 8 GiB to the rootfs. See NOTE above about this.
size_mib: 8192
resize: true
- size_mib: 0
# We assign a descriptive label to the partition. This is important
# for referring to it in a device-agnostic way in other parts of the
# configuration.
label: var
filesystems:
- path: /var
device: /dev/disk/by-partlabel/var
# We can select the filesystem we'd like.
format: ext4
# Ask Butane to generate a mount unit for us so that this filesystem
# gets mounted in the real root.
with_mount_unit: trueÈ ovviamente possibile montare anche solo una parte di /var in una partizione separata. Ad esempio, per montare /var/lib/containers:
variant: fcos
version: 1.7.0
storage:
disks:
- device: /dev/disk/by-id/coreos-boot-disk
wipe_table: false
partitions:
- number: 4
label: root
# Allocate at least 8 GiB to the rootfs. See NOTE above about this.
size_mib: 8192
resize: true
- size_mib: 0
label: containers
filesystems:
- path: /var/lib/containers
device: /dev/disk/by-partlabel/containers
format: xfs
with_mount_unit: trueIn alternativa, è anche possibile montare dello spazio di archiviazione da un disco separato. Ad esempio, qui montiamo //var/log da una partizione su /dev/vdb:
variant: fcos
version: 1.7.0
storage:
disks:
- device: /dev/vdb
wipe_table: false
partitions:
- size_mib: 0
start_mib: 0
number: 1
label: log
filesystems:
- path: /var/log
device: /dev/disk/by-partlabel/log
format: xfs
with_mount_unit: trueIn questo esempio, cancelliamo il disco e creiamo due nuove partizioni.
variant: fcos
version: 1.7.0
storage:
disks:
-
# Mandatory. We use the World-Wide Number ID of the drive to ensure
# uniqueness.
device: /dev/disk/by-id/wwn-0x50014e2eb507fcdf
# This ensures that the partition table is re-created, along with all
# the partitions.
wipe_table: true
partitions:
# The first partition (slot number 1) is 32 GiB and starts at the
# beginning of the device. Its type_guid identifies it as a Linux
# swap partition.
- label: part1
number: 1
size_mib: 32768
start_mib: 0
type_guid: 0657fd6d-a4ab-43c4-84e5-0933c84b4f4f
# The second partition (implicit slot number 2) will be placed after
# partition 1 and will occupy the rest of the available space.
# Since type_guid is not specified, it will be a Linux native
# partition.
- label: part2Riconfigurazione del file system principale root
È possibile riconfigurare lo stesso file system principale (root). Si può utilizzare il percorso `/dev/disk/by-label/root`root per fare riferimento alla partizione `root`originale. È necessario assicurarsi che anche il nuovo file system abbia root come etichetta (label).
| È necessario disporre di almeno 4 GiB di RAM affinché la riprovisione della root vada a buon fine. |
Ecco un esempio di passaggio da xfs a ext4, riutilizzando però la stessa partizione sul disco primario:
variant: fcos
version: 1.7.0
storage:
filesystems:
- device: /dev/disk/by-partlabel/root
wipe_filesystem: true
format: ext4
label: rootAnalogamente alla sezione precedente, è anche possibile spostare interamente il file system principale (root). In questo caso, stiamo spostando la root su un dispositivo RAID0:
variant: fcos
version: 1.7.0
storage:
raid:
- name: myroot
level: raid0
devices:
- /dev/disk/by-id/virtio-disk1
- /dev/disk/by-id/virtio-disk2
filesystems:
- device: /dev/md/myroot
format: xfs
wipe_filesystem: true
label: root
Non sono necessarie le chiavi path`o`with_mount_unit; FCOS sa che la partizione root è speciale e capirà da solo come trovarla e montarla.
|
Se desideri replicare il disco di avvio su più unità per garantire la resilienza in caso di guasto del disco, è necessario creare un mirror di tutte le partizioni predefinite (root, boot, EFI System Partition e il codice del bootloader). Per fare questo, Butane mette a disposizione una sintassi di configurazione speciale:
variant: fcos
version: 1.7.0
boot_device:
# Change to match target architecture (aarch64, ppc64le, etc.)
layout: x86_64
mirror:
devices:
- /dev/sda
- /dev/sdbDefinizione di un file system
Questo esempio dimostra il processo di creazione del file system definendo ed etichettando le partizioni, unendole in un array RAID e formattando tale array in ext4.
variant: fcos
version: 1.7.0
storage:
disks:
# This defines two partitions, each on its own disk. The disks are
# identified by their WWN.
- device: /dev/disk/by-id/wwn-0x50014ee261e524e4
wipe_table: true
partitions:
-
# Each partition gets a human-readable label.
label: "raid.1.1"
# Each partition is placed at the beginning of the disk and is 64 GiB
# long.
number: 1
size_mib: 65536
start_mib: 0
- device: /dev/disk/by-id/wwn-0x50014ee0b8442cd3
wipe_table: true
partitions:
- label: "raid.1.2"
number: 1
size_mib: 65536
start_mib: 0
# We use the previously defined partitions as devices in a RAID1 md array.
raid:
- name: publicdata
level: raid1
devices:
- /dev/disk/by-partlabel/raid.1.1
- /dev/disk/by-partlabel/raid.1.2
# The resulting md array is used to create an EXT4 filesystem.
filesystems:
- path: /var/publicdata
device: /dev/md/publicdata
format: ext4
label: PUB
with_mount_unit: trueArchiviazione crittografata (LUKS)
Ecco un esempio per configurare un dispositivo LUKS su /var/lib/data.
variant: fcos
version: 1.7.0
storage:
luks:
- name: data
device: /dev/vdb
filesystems:
- path: /var/lib/data
device: /dev/mapper/data
format: xfs
label: DATA
with_mount_unit: trueAnche il file system principale (root) può essere spostato su LUKS. In questo caso, il dispositivo LUKS deve essere vincolato tramite Clevis. I due tipi principali di vincolo (pin) disponibili sono: TPM2 e Tang (o una combinazione di questi ultimi utilizzando lo Shamir’s Secret Sharing).
| Il vincolo (pinning) tramite TPM2 si limita a legare la crittografia alla macchina fisica in uso. Assicurati di comprendere il suo modello di minaccia (threat model) prima di scegliere tra il vincolo con TPM2 e quello con Tang. Per ulteriori informazioni, consulta questa sezione della documentazione del pin TPM2 di Clevis. |
| È necessario disporre di almeno 4 GiB di RAM affinché la riprovisione della root vada a buon fine. |
Butane mette a disposizione una sintassi di configurazione semplificata per configurare la crittografia e il vincolo (pinning) del file system principale (root). Ecco un esempio di come utilizzarla per creare un file system root crittografato e vincolato tramite TPM2:
variant: fcos
version: 1.7.0
boot_device:
luks:
tpm2: trueQuesto equivale alla seguente configurazione estesa:
variant: fcos
version: 1.7.0
storage:
luks:
- name: root
label: luks-root
device: /dev/disk/by-partlabel/root
clevis:
tpm2: true
wipe_volume: true
filesystems:
- device: /dev/mapper/root
format: xfs
wipe_filesystem: true
label: rootLa configurazione estesa non include le chiavi path o with_mount_unit; FCOS sa che la partizione root è speciale e capirà da solo come trovarla e montarla.
Questo prossimo esempio vincola la crittografia del file system principale (root) al PCR 7, che corrisponde all’UEFI Boot Component utilizzato per tracciare il certificato di Secure Boot dalla memoria. Di conseguenza, gli aggiornamenti del firmware UEFI o dei certificati non dovrebbero influire sul valore memorizzato nel PCR 7.
| Il vincolo (binding) per il PCR 8 (l’UEFI Boot Component utilizzato per tracciare i comandi e la linea di comando del kernel) non è supportato, poiché la linea di comando del kernel cambia a ogni aggiornamento del sistema operativo. |
variant: fcos
version: 1.7.0
storage:
luks:
- name: root
label: luks-root
device: /dev/disk/by-partlabel/root
clevis:
custom:
needs_network: false
pin: tpm2
config: '{"pcr_bank":"sha1","pcr_ids":"7"}'
wipe_volume: true
filesystems:
- device: /dev/mapper/root
format: xfs
wipe_filesystem: true
label: rootUlteriore documentazione per i campi di config`è disponibile nelle pagine man di `clevis:`man clevis-encrypt-tpm2`
Il seguente comando `clevis`può essere utilizzato per confermare che la crittografia del file system principale (root) è legata al PCR 7.
$ sudo clevis luks list -d /dev/disk/by-partlabel/root
1: tpm2 '{"hash":"sha256","key":"ecc","pcr_bank":"sha1","pcr_ids":"7"}'Ecco un esempio della sintassi di configurazione semplificata con Tang:
variant: fcos
version: 1.7.0
boot_device:
luks:
tang:
- url: http://192.168.122.1:80
thumbprint: bV8aajlyN6sYqQ41lGqD4zlhe0EIl sistema contatterà il server Tang all’avvio.
| Per ulteriori informazioni sulla configurazione di un server Tang, consulta la documentazione ufficiale. |
È possibile configurare sia il vincolo (pinning) con Tang sia quello con TPM2 (inclusa la presenza di più server Tang per la ridondanza). Di default, per sbloccare il file system principale (root) è richiesto solo il dispositivo TPM2 o un singolo server Tang. Questo comportamento può essere modificato utilizzando la chiave threshold(soglia):
variant: fcos
version: 1.5.0
boot_device:
luks:
clevis:
tang:
- url: http://192.168.122.1:80
thumbprint: "bV8aajlyN6sYqQ41lGqD4zlhe0E"
tpm2: true
# Questo consentirà lo sblocco del rootfs solo se sia il pin TPM2
# sia il server Tang sono accessibili e validi.
threshold: 2Quindi la partizione root:
Se si utilizza Ignition per riconfigurare o spostare la partizione principale (root), tale partizione non viene ingrandita automaticamente al primo avvio (si vedano le discussioni correlate in questo problema). Nel caso in cui si sposti la partizione root su un nuovo disco (o su più dischi), è necessario impostare la dimensione desiderata per la partizione utilizzando il campo size_mib. Se si riconfigura il file system root nella sua posizione attuale, come nell’esempio LUKS precedente, è possibile ridimensionare la partizione esistente utilizzando il campo resize:
variant: fcos
version: 1.7.0
storage:
disks:
- device: /dev/disk/by-id/coreos-boot-disk
partitions:
- label: root
number: 4
# 0 means to use all available space
size_mib: 0
resize: true
luks:
- name: root
device: /dev/disk/by-partlabel/root
clevis:
tpm2: true
wipe_volume: true
filesystems:
- device: /dev/mapper/root
format: xfs
wipe_filesystem: true
label: rootAggiunta dello spazio di swap
This example creates a swap partition spanning all of the sdb device, creates a swap area on it, and creates a systemd swap unit so the swap area is enabled on boot.
variant: fcos
version: 1.1.0
storage:
disks:
- device: /dev/sda
wipe_table: true
partitions:
- label: var
filesystems:
- device: /dev/disk/by-partlabel/var
label: var
format: xfs
wipe_filesystem: false
path: /var
with_mount_unit: trueAggiunta di uno spazio di archiviazione di rete
I sistemi Fedora CoreOS possono essere configurati per montare file system di rete come NFS e CIFS. Il modo migliore per farlo è utilizzare Ignition per creare delle unità systemd. I file system possono essere montati all’avvio creando un’unità di montaggio (mount) standard. In alternativa, è possibile montare un file system nel momento in cui gli utenti accedono al punto di montaggio creando un’unità di montaggio automatico (automount) aggiuntiva. Di seguito sono riportati gli esempi di ciascun metodo per un file system NFS.
Configurazione dei montaggi NFS
|
Creazione di un’unità systemd per montare un file system NFS all’avvio.
Il file ..mount`deve essere nominato in base al percorso di montaggio (ad esempio, `/var/mnt/data`diventa `var-mnt-data.mount)
|
variant: fcos
version: 1.3.0
systemd:
units:
- name: var-mnt-data.mount
enabled: true
contents: |
[Unit]
Description=Mount data directory
[Mount]
What=example.org:/data
Where=/var/mnt/data
Type=nfs4
[Install]
WantedBy=multi-user.targetvariant: fcos
version: 1.3.0
systemd:
units:
- name: var-mnt-data.mount
contents: |
[Unit]
Description=Mount data directory
[Mount]
What=example.org:/data
Where=/var/mnt/data
Type=nfs4
[Install]
WantedBy=multi-user.target
- name: var-mnt-data.automount
enabled: true
contents: |
[Unit]
Description=Automount data directory
[Automount]
TimeoutIdleSec=20min
Where=/var/mnt/data
[Install]
WantedBy=multi-user.targetAdvanced examples
Questo esempio configura un disco di avvio speculare (in RAID 1) con un file system principale (root) crittografato tramite TPM2, sovrascrive le dimensioni delle repliche della partizione root generate automaticamente e aggiunge una partizione `/var`speculare e crittografata che consuma lo spazio rimanente sui dischi.
variant: fcos
version: 1.7.0
boot_device:
# Change to match target architecture (aarch64, ppc64le, etc.)
layout: x86_64
luks:
tpm2: true
mirror:
devices:
- /dev/sda
- /dev/sdb
storage:
disks:
- device: /dev/sda
partitions:
# Override size of root partition on first disk, via the label
# generated for boot_device.mirror
- label: root-1
size_mib: 10240
# Add a new partition filling the remainder of the disk
- label: var-1
- device: /dev/sdb
partitions:
# Similarly for second disk
- label: root-2
size_mib: 10240
- label: var-2
raid:
- name: md-var
level: raid1
devices:
- /dev/disk/by-partlabel/var-1
- /dev/disk/by-partlabel/var-2
luks:
- name: var
device: /dev/md/md-var
# No key material is specified, so a random key will be generated
# and stored in the root filesystem
filesystems:
- device: /dev/mapper/var
path: /var
label: var
format: xfs
wipe_filesystem: true
with_mount_unit: trueStruttura del disco
Tutti i sistemi Fedora CoreOS si avviano con la stessa immagine disco, che varia leggermente a seconda dell’architettura in base a ciò che è necessario per l’avvio (bootloading). Al primo avvio, il file system principale (root) viene espanso per occupare il resto del disco. L’immagine disco può essere personalizzata utilizzando le configurazioni Butane per ripartizionare il disco e creare o formattare i file system. Le installazioni su bare metal non fanno eccezione; l’installer si limita a copiare l’immagine grezza (raw) sul disco di destinazione e a inserire la configurazione specificata in /boot affinché venga utilizzata al primo avvio.
| Vedere Riconfigurazione del file system principale per esempi relativi alle modifiche supportate per la partizione root. |
tabella delle partizioni
L’uso dei numeri di partizione per fare riferimento a partizioni specifiche è sconsigliato; si dovrebbero utilizzare invece le etichette (label) o gli UUID. Fedora CoreOS riserva le etichette boot, boot-<number>, root, root-<number>, BIOS-BOOT, bios-<number>, EFI-SYSTEM ed esp-<number>, nonché i nomi dei dispositivi RAID md-boot e md-root. La creazione di partizioni, file system o dispositivi RAID con queste etichette non è supportata.
Tabella delle partizioni x86_64
L’immagine disco x86_64 è formattata in GPT con un MBR protettivo. Supporta l’avvio sia tramite BIOS sia tramite UEFI (incluso Secure Boot).
Il layout della tabella delle partizioni è cambiato nel tempo. Il layout attuale è:
Number |
Label |
Description |
Partition Type |
1 |
BIOS-BOOT |
Contains BIOS GRUB image |
raw data |
2 |
EFI-SYSTEM |
Contains EFI GRUB image and Secure Boot shim |
FAT32 |
3 |
boot |
Contains GRUB configuration, kernel/initramfs images |
ext4 |
4 |
root |
Contains the root filesystem |
xfs |
La partizione EFI-SYSTEM può essere eliminata o riformattata in caso di avvio tramite BIOS. Allo stesso modo, la partizione BIOS-BOOT può essere eliminata o riformattata in caso di avvio tramite EFI.
Monta Filesystem
Fedora CoreOS utilizza OSTree, un sistema per la gestione di molteplici alberi (tree) di sistemi operativi avviabili che condividono lo stesso spazio di archiviazione. Ogni versione del sistema operativo fa parte del file system /. Tutte le distribuzioni condividono la stessa directory /var, che può trovarsi sul medesimo file system o essere montata separatamente.
Questo mostra i punti di montaggio predefiniti per un sistema Fedora CoreOS installato su un disco /dev/vda:
$ findmnt --real # Some details are elided
TARGET SOURCE FSTYPE OPTIONS
/ /dev/vda4[/ostree/deploy/fedora-coreos/deploy/$hash] xfs rw
|-/sysroot /dev/vda4 xfs ro
|-/etc /dev/vda4[/ostree/deploy/fedora-coreos/deploy/$hash/etc] xfs rw
|-/usr /dev/vda4[/ostree/deploy/fedora-coreos/deploy/$hash/usr] xfs ro
|-/var /dev/vda4[/ostree/deploy/fedora-coreos/deploy/var] xfs rw
`-/boot /dev/vda3 ext4 roIn passato la partizione di sistema EFI I System Partition veniva montata in /boot/efi, ma non è più così. Sui sistemi configurati con il mirroring del dispositivo di avvio, sono presenti partizioni EFI indipendenti su ciascuno dei dischi costitutivi.
/ immutabile, /usr in sola lettura
Poiché OSTree viene utilizzato per gestire tutti i file appartenenti al sistema operativo, i punti di montaggio /`e `/usr`non sono scrivibili. Qualsiasi modifica al sistema operativo deve essere applicata tramite `rpm-ostree.
Allo stesso modo, il punto di montaggio`/boot`non è scrivibile e la partizione di sistema EFI non è montata per impostazione predefinita. Questi file system sono gestiti da rpm-ostree e bootupd, e non devono essere modificati direttamente da un amministratore.
L’aggiunta di directory di primo livello (ad esempio /foo) non è attualmente supportata ed è vietata dall’attributo di immutabilità.
Il vero / (ovvero la radice del file system nella partizione root) è montato in sola lettura in /sysroot e non deve essere modificato o consultato direttamente.
Configurazione in /etc e stato in /var
Le uniche posizioni scrivibili supportate sono /etc e /var. La directory /etc dovrebbe contenere solo file di configurazione e non è destinata alla memorizzazione di dati. Tutti i dati devono essere conservati in /var e non verranno toccati dagli aggiornamenti di sistema. I percorsi tradizionali che potrebbero contenere lo stato del sistema (ad esempio /home o /srv) sono collegamenti simbolici (symlink) a directory presenti in /var (come /var/home o /var/srv).
Selezione della versione e avvio
Viene creata una voce del menu di GRUB per ogni versione di Fedora CoreOS attualmente disponibile sul sistema. Questa voce di menu fa riferimento a una (distribuzione ostree`costituita da un kernel Linux, un initramfs e un hash che si collega a un commit `ostree(passato tramite l’argomento del kernel`ostree=`). Durante l’avvio, `ostree`leggerà questo argomento del kernel per determinare quale distribuzione utilizzare come file system radice. Ogni aggiornamento o modifica al sistema (installazione di pacchetti, aggiunta di argomenti del kernel) crea una nuova distribuzione. Ciò consente di ripristinare (eseguire il rollback a) una distribuzione precedente se l’aggiornamento dovesse causare problemi.
Want to help? Learn how to contribute to Fedora Docs ›