New Crowdin updates

docs/gemstones/xorriso.de.md

@@ -1,12 +1,12 @@
 ---
 title: Mit Xorriso auf physische CDs/DVDs brennen
 author: Joseph Brinkman
-contributors: Steven Spencer
+contributors: Steven Spencer, Ganna Zhyrnova
 ---
 
 ## Einleitung
 
-Der Autor stellte kürzlich fest, dass das Brennen von Hybrid-ISOs auf eine physische CD/DVD unter Rocky Linux mit grafischen Werkzeugen eine Herausforderung darstellt. Zum Glück ist Xorriso eine einfach zu bedienende CLI-Anwendung, die diese Aufgabe gut erledigt!
+Der Autor stellte kürzlich fest, dass das Brennen von Hybrid-ISOs auf eine physische CD/DVD unter Rocky Linux mit grafischen Tools eine Herausforderung darstellt. Zum Glück ist Xorriso eine einfach zu bedienende CLI-Anwendung, die diese Aufgabe gut bewältigt!
 
 ## Problembeschreibung
 
@@ -38,7 +38,7 @@ Xorriso verwendet eine C-Bibliothek namens `libisofs`. Mehr über `libisofs` erf
 
 ## Zusammenfassung
 
-In diesem Kurs haben Sie gelernt, wie man mit Xorriso eine ISO-Datei auf eine physische Disk schreibt! Beachten Sie, dass `Xorriso` auch zum Schreiben anderer Dateitypen auf physische Datenträger verwendet werden kann, aber der Autor fand es besonders praktisch für das hybride ISO-Format, mit dem grafische Tools nicht umgehen konnten.<small>
+In diesem Kurs haben Sie gelernt, wie man mit Xorriso eine ISO-Datei auf eine physische Festplatte schreibt! Beachten Sie, dass `Xorriso` auch zum Schreiben anderer Dateitypen auf physische Datenträger verwendet werden kann, aber der Autor fand es besonders praktisch für das hybride ISO-Format, mit dem grafische Tools nicht umgehen konnten.<small>
 <br/><br/>
 🌐 Übersetzungen: 
 <a href="https://crowdin.com/project/rockydocs/de">crowdin.com/project/rockydocs</a>

docs/gemstones/xorriso.it.md

@@ -1,7 +1,7 @@
 ---
 title: Scrivere su CD/DVD fisici con Xorriso
 author: Joseph Brinkman
-contributors: Steven Spencer
+contributors: Steven Spencer, Ganna Zhyrnova
 ---
 
 ## Introduzione

docs/gemstones/xorriso.uk.md

@@ -1,7 +1,7 @@
 ---
 title: Запис на фізичний CD/DVD за допомогою Xorriso
 author: Joseph Brinkman
-contributors: Steven Spencer
+contributors: Steven Spencer, Ganna Zhyrnova
 ---
 
 ## Вступ

docs/guides/virtualization/cloud-init/01_fundamentals.it.md

@@ -0,0 +1,90 @@
+---
+title: 1. cloud-init fundamentals
+author: Wale Soyinka
+contributors: Steven Spencer
+tags:
+  - cloud-init
+  - cloud
+  - automation
+---
+
+## L'architettura del primo boot
+
+Questa guida esplora `cloud-init`, lo strumento essenziale per automatizzare la configurazione iniziale delle istanze cloud di Rocky Linux 10. Quando parliamo di implementazione di server nel cloud, o anche nel vostro laboratorio di virtualizzazione locale, spesso diamo per scontata la transizione quasi istantanea da un'immagine vuota a una macchina completamente funzionante e pronta per la rete. Questa impresa di alchimia digitale è compiuta da un unico, instancabile strumento: cloud-init.
+
+## 1. Il dilemma del bootstrapping
+
+### Il problema: quando un server si riattiva alla cieca
+
+Immagina un'immagine generica Rocky Linux 10 QCOW2. È una copia perfetta, immacolata, ignara della sua destinazione finale. Non conosce il proprio nome host, quale account utente dovrebbe avere accesso SSH, in quale fuso orario si trova o se necessita di Apache o NGINX.
+
+Se si stesse implementando hardware fisico, un amministratore di sistema configurerebbe manualmente tutti questi parametri. Ma nel cloud, i server sono effimeri, scalabili verso l'alto e verso il basso a migliaia. Abbiamo bisogno di un meccanismo standardizzato, generico e affidabile per inserire il contesto necessario in quell'immagine vuota al primo avvio.
+
+Questo è il problema che **cloud-init** risolve.
+
+### Cosa è cloud-init
+
+In parole povere, cloud-init è il pacchetto multi-distribuzione standard del settore che gestisce l'inizializzazione iniziale delle istanze cloud. È il servizio principale responsabile di prendere un'immagine generica (come quella che stiamo utilizzando) ed eseguire le attività di configurazione necessarie per trasformarla in un server unico e pronto per la produzione.
+
+Si trova letteralmente al centro del processo di provisioning, interpretando i **metadati** e le **istruzioni definite dall'utente** per configurare il sistema. Senza di esso, la tua istanza cloud è solo un kernel Linux ben compilato con una crisi di identità.
+
+### L'ecosistema di cloud-init
+
+cloud-init è un consumatore, non un creatore. Si affida alla piattaforma cloud sottostante (AWS, Azure, GCP, OpenStack o strumenti locali come libvirt) per fornire le informazioni di configurazione.
+
+- I **fornitori di servizi cloud** espongono i dati tramite una _fonte dati_ specializzata (spesso un endpoint HTTP locale, un'etichetta disco specifica o un parametro del kernel).
+- **cloud-init** rileva questa fonte di dati, legge la configurazione ed esegue i passaggi di configurazione appropriati.
+
+Questo disaccoppiamento, in cui l'immagine è generica e la configurazione viene fornita esternamente, è il genio fondamentale dell'intero modello di implementazione cloud.
+
+## 2. Rocky Linux 10 e l'immagine cloud generica
+
+Per questa guida utilizzeremo il file ufficiale [Rocky-10-GenericCloud-Base.latest.x86_64.qcow2](https://dl.rockylinux.org/pub/rocky/10/images/x86_64/Rocky-10-GenericCloud-Base.latest.x86_64.qcow2).
+
+### L'immagine target: un cavallo di battaglia precablato
+
+Questa immagine è speciale perché include il pacchetto cloud-init preinstallato e abilitato. È stato _generalizzato_, il che significa che tutti gli identificatori specifici della macchina, le chiavi host SSH e i file di log sono stati eliminati. È pronto per ricevere la sua nuova identità al primo avvio.
+
+!!! warning "Utilizzare l'Immagine Raccomandata"
+
+    Se provi a utilizzare cloud-init su un'installazione standard di Rocky Linux (come un'installazione ISO minimale), scoprirai che non è presente di default. Utilizza l'immagine **Generic Cloud** per evitare inutili complicazioni e assicurarti che tutto funzioni esattamente come previsto. Provare a eseguire gli esercizi descritti in questa guida con altre immagini probabilmente non funzionerà e non è supportato.
+
+### Concetti fondamentali: dati utente vs. metadati
+
+Le informazioni di configurazione elaborate da cloud-init sono classificate in due tipi principali. Comprendere questa distinzione è fondamentale per sapere cosa è possibile controllare e cosa controlla il fornitore di servizi cloud.
+
+Pensate come alla costruzione di una casa: i **metadati** sono l'indirizzo assegnato dal comune, mentre i **dati utente** sono il progetto che fornite per l'interior design.
+
+| Tipo          | Origine e scopo                                                                                                                                                                                                                                       | Tipo di configurazione   |
+| :------------ | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------- |
+| **Meta-Data** | Fornito dalla piattaforma cloud (sola lettura). Contiene identificatori di sistema quali ID istanza, nome host (se fornito dalla piattaforma), regione e zona di disponibilità. | _Contesto di sistema_    |
+| **User-Data** | Fornito dall'utente. Questo è il tuo set di istruzioni: blocchi di configurazione YAML o script di shell che personalizzano il server.                                                                | _Istruzioni dell'utente_ |
+
+I **metadati** indicano a cloud-init _dove_ si trova. **User-Data** indica a cloud-init _cosa fare_.
+
+Ci concentreremo principalmente sulla creazione di file **User-Data** efficaci, che in genere iniziano con l'intestazione YAML obbligatoria:
+
+```yaml
+#cloud-config
+```
+
+## 3. Il ciclo di vita: le quattro fasi di inizializzazione di cloud-init
+
+cloud-init non si limita a eseguire uno script e chiudersi, ma esegue una serie di fasi altamente strutturate che si allineano con il processo di avvio del server. Questo approccio metodico garantisce che le dipendenze siano soddisfatte (ad esempio, la rete viene configurata prima che i pacchetti vengano scaricati).
+
+Comprendere questo ciclo di vita è fondamentale per il debug e per sapere con precisione quando vengono eseguite le istruzioni personalizzate.
+
+| Stage         | Tempistiche e descrizione                                                                                                                                                                                                  | Azioni chiave/Moduli                                                                                                                                                                                       |
+| :------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **Generator** | Viene eseguito all'inizio del processo di avvio. Imposta le directory interne ed esegue controlli di configurazione di base.                                                               | Configurazione interna, inizializzazione del registro.                                                                                                                                     |
+| **Local**     | Funziona prima che la rete sia necessariamente attiva. Elabora fonti di dati locali come CD-ROM o unità virtuali (che useremo nel nostro laboratorio).                  | Impostazione del nome host dai dati locali, configurazione iniziale del disco.                                                                                                             |
+| **Network**   | Viene eseguito una volta che la rete è completamente configurata e operativa. Interroga fonti di dati basate sulla rete (come l'API del fornitore di servizi cloud).    | Configura le interfacce di rete, recupera le chiavi dai metadati di rete.                                                                                                                  |
+| **Final**     | Ultimo in esecuzione. È qui che avviene la maggior parte della configurazione definita dall'utente, poiché tutti i prerequisiti (utenti, rete, dischi) sono ora pronti. | Installazione di pacchetti, esecuzione di script personalizzati (runcmd), scrittura di file (write_files), pulizia del sistema. |
+
+!!! tip "Controllare i log"
+
+    Durante la risoluzione dei problemi, controllare sempre `/var/log/cloud-init.log`. Questo file è il rapporto diagnostico del processo `cloud-init`, che mostra esattamente quando ogni fase è iniziata e terminata e quali moduli sono stati eseguiti durante il processo. Se lo script non è stato eseguito, il log indicherà esattamente il motivo e quale fase ha avuto esito negativo.
+
+## Cosa succederà
+
+Ora che avete compreso l'architettura fondamentale di `cloud-init` — il “cosa” e il “perché”, i diversi tipi di dati e le fasi di avvio — siete pronti per passare dalla teoria alla pratica. Il prossimo capitolo ti guiderà attraverso il tuo primo esercizio pratico: avviare l'immagine cloud di Rocky Linux 10 ed eseguire una semplice personalizzazione reale.

docs/guides/virtualization/cloud-init/02_first_contact.it.md

@@ -0,0 +1,160 @@
+---
+title: 2. Primo contatto
+author: Wale Soyinka
+contributors: Ganna Zhyrnova
+tags:
+  - cloud-init
+  - cloud
+  - automation
+---
+
+## Avvio semplice con l'immagine QCOW2 di Rocky Linux 10
+
+Nel capitolo precedente abbiamo trattato i concetti fondamentali di `cloud-init`. Ora è il momento di passare dalla teoria alla pratica. Questo capitolo è la tua  prima missione pratica: prenderai l'immagine ufficiale Rocky Linux 10 Generic Cloud, le fornirai una serie di semplici istruzioni e la guarderai configurarsi da sola al primo avvio.
+
+## 1. Preparazione dell'ambiente
+
+Prima di poter avviare la nostra prima istanza, dobbiamo preparare il nostro ambiente di lavoro in locale. Per questi esercizi, simuleremo un ambiente cloud utilizzando strumenti di virtualizzazione Linux standard.
+
+### Prerequisiti: tools su host
+
+Assicurarsi di avere i seguenti strumenti installati sul computer host. Su un host Rocky Linux, è possibile installarli con `dnf`:
+
+```bash
+sudo dnf install -y libvirt qemu-kvm virt-install genisoimage
+```
+
+- **Hypervisor di virtualizzazione:** uno strumento come KVM/QEMU o VirtualBox.
+- `virt-install`: un'utility da riga di comando per il provisioning di nuove macchine virtuali.
+- `genisoimage` (o `mkisofs`): uno strumento per creare un filesystem ISO9660.
+
+### L'immagine QCOW2
+
+Scaricare l'immagine ufficiale Rocky Linux 10 Generic Cloud.
+
+```bash
+curl -L -o Rocky-10-GenericCloud.qcow2 \
+https://dl.rockylinux.org/pub/rocky/10/images/x86_64/Rocky-10-GenericCloud-Base.latest.x86_64.qcow2
+```
+
+Per conservare l'originale, crea una copia di lavoro dell'immagine per la tua VM.
+
+```bash
+cp Rocky-10-GenericCloud.qcow2 first-boot-vm.qcow2
+```
+
+!!! tip "Risparmia spazio su disco con i file di backup"
+
+    Una copia completa dell'immagine può essere di grandi dimensioni. Per risparmiare spazio su disco, è possibile creare un _clone collegato_ che utilizza l'immagine originale come file di supporto. In questo modo si crea un file `qcow2` molto più piccolo che memorizza solo le differenze rispetto all'originale.
+
+    `bash     qemu-img create -f qcow2 -F qcow2 \     -b Rocky-10-GenericCloud.qcow2 first-boot-vm.qcow2     `
+
+## 2. Metodo 1: Il `NoCloud` datasource (ISO)
+
+Uno dei modi più comuni per fornire dati a `cloud-init` in un ambiente locale è il `NoCloud` datasource. Questo metodo richiede l'inserimento dei file di configurazione in un CD-ROM virtuale (un file ISO) che `cloud-init` rileverà e leggerà automaticamente all'avvio.
+
+### Creazione dei file di configurazione
+
+1. **Crea una cartella per salvare i file di configurazione:**
+
+    ```bash
+    mkdir cloud-init-data
+    ```
+
+2. **Creare il file `user-data`:** questo file contiene le istruzioni principali. Per crearlo useremo un `cat` heredoc .
+
+    ```bash
+    cat <<EOF > cloud-init-data/user-data
+    #cloud-config
+    hostname: cloud-rockstar-01
+    runcmd:
+      - [ sh, -c, "echo 'Hello from the cloud-init Final Stage!' > /root/boot_done.txt" ]
+    EOF
+    ```
+
+3. **Creare il file `meta-data`:** questo file fornisce informazioni _sul_ contesto L'`instance-id` è particolarmente importante, poiché `cloud-init` lo utilizza per determinare se è già stato eseguito su questa istanza in precedenza. La modifica dell'ID causerà il riavvio di `cloud-init`.
+
+    ```bash
+    cat <<EOF > cloud-init-data/meta-data
+    {
+      "instance-id": "i-first-boot-01",
+      "local-hostname": "cloud-rockstar-01"
+    }
+    EOF
+    ```
+
+4. **Creare l'ISO:** Utilizzare `genisoimage` per comprimere i file in `config.iso`. L'etichetta del volume `-V cidata` è la chiave magica che `cloud-init` cerca.
+
+    ```bash
+    genisoimage -o config.iso -V cidata -r -J cloud-init-data
+    ```
+
+### Avvio e verifica
+
+1. **Avvia la VM** con `virt-install`, allegando sia l'immagine della VM che il file `config.iso`.
+
+    ```bash
+    virt-install --name rocky10-iso-boot \
+    --memory 2048 --vcpus 2 \
+    --disk path=first-boot-vm.qcow2,format=qcow2 \
+    --disk path=config.iso,device=cdrom \
+    --os-variant rockylinux10 \
+    --import --noautoconsole
+    ```
+
+2. **Trova l'IP e connettiti tramite SSH.** L'utente predefinito è `rocky`.
+
+    ```bash
+    virsh domifaddr rocky10-iso-boot
+    ssh rocky@<IP_ADDRESS>
+    ```
+
+       !!! tip "Accedi in modo sicuro con le chiavi SSH"
+
+        ```
+         Connettersi con un utente predefinito è comodo per un rapido test di laboratorio, ma non è una pratica sicura. Nel prossimo capitolo vedremo come utilizzare `cloud-init` per inserire automaticamente la tua chiave pubblica SSH, consentendo accessi sicuri e senza password.
+        ```
+
+3. **Verifica le modifiche:** controlla il nome host e il file creato da `runcmd`.
+
+    ```bash
+    hostname
+    sudo cat /root/boot_done.txt
+    ```
+
+## 3) Metodo 2: Iniezione diretta con `virt-install`
+
+La creazione di un ISO è un metodo affidabile, ma per gli utenti di `libvirt` e `virt-install` esiste un modo molto più semplice. Il flag `--cloud-init` consente di passare direttamente `user-data`, lasciando che `virt-install` gestisca automaticamente la creazione dell'origine dati.
+
+### `user-data` semplificato
+
+Crea un semplice file `user-data.yml`. È anche possibile aggiungere preventivamente la chiave SSH.
+
+```bash
+cat <<EOF > user-data.yml
+#cloud-config
+users:
+  - name: rocky
+    ssh_authorized_keys:
+      - <YOUR_SSH_PUBLIC_KEY>
+EOF
+```
+
+### Avvio e verifica
+
+1. **Avvia la VM** utilizzando il flag `--cloud-init`. Si noti che qui è possibile impostare direttamente il nome host.
+
+    ```bash
+    virt-install --name rocky10-direct-boot \
+    --memory 2048 --vcpus 2 \
+    --disk path=first-boot-vm.qcow2,format=qcow2 \
+    --cloud-init user-data=user-data.yml,hostname=cloud-rockstar-02 \
+    --os-variant rockylinux10 \
+    --import --noautoconsole
+    ```
+
+2. **Trova l'IP e connettiti.** Se hai aggiunto la tua chiave SSH, dovresti essere in grado di connetterti senza password.
+
+3. **Verifica il nome host.** Dovrebbe essere `cloud-rockstar-02`.
+
+Questo metodo diretto è spesso più veloce e conveniente per lo sviluppo locale e il testing con `libvirt`.