New Crowdin updates (#3057)

* New translations tor_onion_service.md (Ukrainian)

* New translations tor_onion_service.md (Italian)

* New translations tor_onion_service.md (German)

* New translations php.md (Italian)

* New translations 10_1.md (Italian)

* New translations 04_advanced_provisioning.md (Italian)

* New translations 9_0.md (Italian)

* New translations index.md (Italian)

* New translations 8_7.md (Italian)

* New translations 8_5.md (Italian)

* New translations 9_1.md (Italian)

* New translations 8_9.md (Italian)

* New translations 9_4.md (Italian)

* New translations 8_10.md (Italian)

* New translations 9_5.md (Italian)

* New translations 9_6.md (Italian)

* New translations 10_0.md (Italian)

* New translations 05_image_builders_perspective.md (Italian)

* New translations 10_1.md (German)

* New translations 06_troubleshooting.md (Italian)

* New translations 07_contributing.md (Italian)

* New translations index.md (Italian)

* New translations lab3-system_utilities.md (Italian)

* New translations lab5-networking.md (Italian)

* New translations lab6-user_and_group_management.md (Italian)

* New translations php.md (Italian)

Author: rockylinux-auto

docs/guides/virtualization/cloud-init/04_advanced_provisioning.it.md

@@ -0,0 +1,237 @@
+---
+title: 4. Provisioning avanzato
+author: Wale Soyinka
+contributors: Steven Spencer
+tags:
+  - cloud-init
+  - rocky linux
+  - cloud
+  - automation
+  - networking
+---
+
+## Networking e multi-part payload
+
+Nel capitolo precedente si è imparato a utilizzare i moduli principali di `cloud-init` per la gestione di utenti, pacchetti e file. Ora è possibile creare un server ben configurato in modo dichiarativo. Ora è il momento di esplorare tecniche più avanzate che ci consentano un controllo ancora maggiore sulla configurazione della vostra istanza.
+
+Questo capitolo tratta due argomenti avanzati e molto importanti:
+
+1. Configurazione di rete dichiarativa: come andare oltre il DHCP e definire configurazioni di rete statiche per le tue istanze.
+2. Payload MIME multiparte: come combinare diversi tipi di dati utente, come script di shell e file `#cloud-config`, in un unico potente payload.
+
+## 1) Configurazione per rete dichiarativa
+
+Per impostazione predefinita, la configurazione della maggior parte delle immagini cloud prevede l'acquisizione di un indirizzo IP tramite DHCP. Sebbene sia comodo, molti ambienti di produzione richiedono che i server abbiano indirizzi IP statici. Il sistema di configurazione di rete `cloud-init` offre un modo dichiarativo e indipendente dalla piattaforma per gestire tutto questo.
+
+Le specifiche delle configurazioni di rete sono contenute in un documento YAML separato dal `#cloud-config` principale. I processi `cloud-init` provengono entrambi dallo stesso file e utilizzano il separatore standard dei documenti YAML (`---`) per distinguerli.
+
+!!! note "Come `cloud-init` applica lo stato della rete"
+
+    Su Rocky Linux, `cloud-init` non configura direttamente le interfacce di rete. Agisce invece come un traduttore, convertendo la sua configurazione di rete in file che **NetworkManager** (il servizio di rete predefinito) è in grado di comprendere. Quindi passa il controllo a NetworkManager per applicare la configurazione. È possibile ispezionare i profili di connessione risultanti in `/etc/NetworkManager/system-connections/`.
+
+### Esempio 1: Configurazione di un singolo IP statico
+
+In questo esercizio configureremo la macchina virtuale con un indirizzo IP statico, un gateway predefinito e server DNS personalizzati.
+
+1. **Creare `user-data.yml`:**
+
+   Questo file contiene due documenti YAML distinti, separati da `---`. Il primo è il `#cloud-config` standard. Il secondo definisce lo stato della rete.
+
+    ```bash
+    cat <<EOF > user-data.yml
+    #cloud-config
+    # Possiamo comunque includere i moduli standard.
+    # Installiamo uno strumento per la risoluzione dei problemi di rete.
+    packages:
+      - traceroute
+    
+    ---
+    
+    # Questo secondo documento definisce la configurazione di rete.
+    network:
+      version: 2
+      ethernets:
+        eth0:
+          dhcp4: no
+          addresses:
+            - 192.168.122.100/24
+          gateway4: 192.168.122.1
+          nameservers:
+            addresses: [8.8.8.8, 8.8.4.4]
+    EOF
+    ```
+
+2. **Spiegazione delle Key directives:**
+
+   - `network:`: Chiave di primo livello per la configurazione di rete.
+   - `versione: 2`: specifica che stiamo utilizzando la sintassi moderna, simile a Netplan.
+   - `ethernets:`: un dizionario delle interfacce di rete fisiche da configurare, ordinate in base al nome dell'interfaccia (ad esempio, `eth0`).
+   - `dhcp4: no`: Disabilita il DHCP per IPv4 su questa interfaccia.
+   - `indirizzi`: un elenco di indirizzi IP statici da assegnare, specificati in notazione CIDR.
+   - `gateway4`: Il gateway predefinito per il traffico IPv4.
+   - `nameservers`: un dizionario contenente un elenco di indirizzi IP per la risoluzione DNS.
+
+3. _Boot e verifica._\*
+
+   La verifica è diversa questa volta, poiché la VM non otterrà un indirizzo IP dinamico. È necessario connettersi direttamente alla console della VM.
+
+    ```bash
+    # Utilizzare un nuovo disco per questo esercizio
+    qemu-img create -f qcow2 -F qcow2 -b Rocky-10-GenericCloud.qcow2 static-ip-vm.qcow2
+    
+    virt-install --name rocky10-static-ip \
+    --memory 2048 --vcpus 2 \
+    --disk path=static-ip-vm.qcow2,format=qcow2 \
+    --cloud-init user-data=user-data.yml,hostname=network-server \
+    --os-variant rockylinux10 \
+    --import --noautoconsole
+    
+    # Connettere la virtual console
+    virsh console rocky10-static-ip
+    
+    # Loggarsi dentro e controlloare l'IP
+    [rocky@network-server ~]$ ip a show eth0
+    ```
+
+   L'output dovrebbe mostrare che `eth0` ha l'indirizzo IP statico `192.168.122.100/24`.
+
+### Esempio 2: Configurazione multi-interfaccia
+
+Uno scenario comune nel mondo reale è un server con più interfacce di rete. Qui creeremo una VM con due interfacce: `eth0` utilizzerà DHCP, mentre `eth1` avrà un IP statico.
+
+1. **Create `user-data.yml` per due interfacce:**
+
+    ```bash
+    cat <<EOF > user-data.yml
+    #cloud-config
+    packages: [iperf3]
+    
+    ---
+    
+    network:
+      version: 2
+      ethernets:
+        eth0:
+          dhcp4: yes
+        eth1:
+          dhcp4: no
+          addresses: [192.168.200.10/24]
+    EOF
+    ```
+
+2. **Boot di una VM con due schede di rete:** aggiungiamo un secondo flag `--network` al comando `virt-install`.
+
+    ```bash
+    virt-install --name rocky10-multi-nic \
+    --memory 2048 --vcpus 2 \
+    --disk path=... \
+    --network network=default,model=virtio \
+    --network network=default,model=virtio \
+    --cloud-init user-data=user-data.yml,hostname=multi-nic-server \
+    --os-variant rockylinux10 --import --noautoconsole
+    ```
+
+3. **Verifica:** esegure SSH all'indirizzo assegnato dal DHCP su `eth0`, quindi controlla l'IP statico su `eth1` con `ip a show eth1`.
+
+## 2) Unificazione dei payload con MIME multi-part
+
+A volte è necessario eseguire uno script di configurazione _prima_ dell'esecuzione dei moduli principali `#cloud-config`. I file multi-part MIME sono la soluzione ideale, poiché consentono di raggruppare diversi tipi di contenuti in un unico payload ordinato.
+
+È possibile visualizzare la struttura di un file MIME come segue:
+
+```
++-----------------------------------------+
+| Main Header (multipart/mixed; boundary) |
++-----------------------------------------+
+|
+| --boundary                              |
+| +-------------------------------------+
+| | Part 1 Header (e.g., text/x-shellscript)  |
+| +-------------------------------------+
+| | Part 1 Content (#/bin/sh...)        |
+| +-------------------------------------+
+|
+| --boundary                              |
+| +-------------------------------------+
+| | Part 2 Header (e.g., text/cloud-config)   |
+| +-------------------------------------+
+| | Part 2 Content (#cloud-config...)   |
+| +-------------------------------------+
+|
+| --boundary-- (closing)                  |
++-----------------------------------------+
+```
+
+### Hands-on: uno script per il controllo preventivo
+
+Creeremo un file composto da più parti che prima esegue uno script shell e poi procede al `#cloud-config` principale.
+
+1. **Creare il file multiparte `user-data.mime`:**
+
+   Si tratta di un file di testo con un formato speciale che utilizza una stringa “di delimitazione” per separare le parti.
+
+    ```bash
+    cat <<EOF > user-data.mime
+    Content-Type: multipart/mixed; boundary="//"
+    MIME-Version: 1.0
+    
+    --//
+    Content-Type: text/x-shellscript; charset="us-ascii"
+    
+    #!/bin/sh
+    echo "Running pre-flight checks..."
+    # In a real script, you might check disk space or memory.
+    # If checks failed, you could 'exit 1' to halt cloud-init.
+    echo "Pre-flight checks passed." > /tmp/pre-flight-status.txt
+    
+    --//
+    Content-Type: text/cloud-config; charset="us-ascii"
+    
+    #cloud-config
+    packages:
+        - htop
+        runcmd:
+          - [ sh, -c, "echo 'Main cloud-config ran successfully' > /tmp/main-config-status.txt" ]
+    
+    --//--
+    EOF
+    ```
+
+       !!! note "Informazioni sul delimitatore  MIME"
+
+        ```
+         La stringa di delimitazione (in questo caso `//`) è una stringa arbitraria che non deve comparire nel contenuto di nessuna parte. Viene utilizzata per separare le diverse sezioni del file.
+        ```
+
+2. _Boot e verifica._\*
+
+   Questo file viene passato a `virt-install` allo stesso modo di un file `user-data.yml` standard.
+
+    ```bash
+    # Use a new disk image
+    qemu-img create -f qcow2 -F qcow2 -b Rocky-10-GenericCloud.qcow2 mime-vm.qcow2
+    
+    virt-install --name rocky10-mime-test \
+    --memory 2048 --vcpus 2 \
+    --disk path=mime-vm.qcow2,format=qcow2 \
+    --cloud-init user-data=user-data.mime,hostname=mime-server \
+    --os-variant rockylinux10 \
+    --import --noautoconsole
+    ```
+
+   Dopo il boot, accedere alla VM tramite SSH e verificare che entrambe le parti siano state eseguite cercando i file che hanno creato:
+
+    ```bash
+    cat /tmp/pre-flight-status.txt
+    cat /tmp/main-config-status.txt
+    ```
+
+!!! tip "Altri tipi di contenuti Multi-part"
+
+    `cloud-init` supporta altri tipi di contenuto per casi d'uso avanzati, come `text/cloud-boothook` per script  iniziali di boot o `text/part-handler` per l'esecuzione di codice Python personalizzato. Per ulteriori dettagli, consultare la documentazione ufficiale.
+
+## Prossimo passo
+
+Ora avete imparato due potenti tecniche avanzate di `cloud-init`. Ora è possibile definire reti statiche e orchestrare flussi di lavoro di provisioning complessi con dati utente multi-part.
+
+Nel prossimo capitolo, sposteremo la nostra prospettiva dal _consumo_ di `cloud-init` su base individuale alla _personalizzazione del suo comportamento predefinito_ per creare le vostre “immagini golden” preconfigurate.

docs/guides/virtualization/cloud-init/05_image_builders_perspective.it.md

@@ -0,0 +1,141 @@
+---
+title: 5. La prospettiva del image builder
+author: Wale Soyinka
+contributors: Steven Spencer
+tags:
+  - cloud-init
+  - rocky linux
+  - cloud
+  - automation
+  - image-building
+---
+
+## Impostazioni predefinite e generalizzazione
+
+Finora, il nostro percorso si è concentrato sulla configurazione delle singole istanze all'avvio utilizzando `user-data`. In questo capitolo, cambieremo prospettiva e assumeremo quella di un **image builder**. Cioè qualcuno che crea e gestisce le “golden images” che fungono da modelli per altre macchine virtuali.
+
+Il nostro obiettivo è quello di creare una nuova immagine personalizzata con le nostre policies ed impostazioni predefinite integrate. Ciò comporta due passaggi fondamentali:
+
+1. **Personalizzazione delle impostazioni predefinite a livello di sistema:** Modifica della configurazione `cloud-init` _all'interno dell'immagine stessa_.
+2. **Generalizzazione dell'immagine:** utilizzo di strumenti quali `cloud-init clean` e `virt-sysprep` per rimuovere tutti i dati specifici della macchina, preparando l'immagine per la clonazione.
+
+## 1) Configurazione del laboratorio di personalizzazione
+
+Per iniziare, abbiamo bisogno di un'istanza funzionante dell'immagine cloud di base da poter modificare. Avvieremo questa VM _senza_ fornire alcun `dato utente` per ottenere un sistema pulito.
+
+```bash
+# Create un'immagine disco per il nostro nuovo modello
+qemu-img create -f qcow2 -o size=10G golden-image-template.qcow2
+
+# Avviate l'immagine di base utilizzando virt-install
+virt-install --name golden-image-builder \
+--memory 2048 --vcpus 2 \
+--disk path=golden-image-template.qcow2,format=qcow2 \
+--cloud-init none --os-variant rockylinux10 --import
+
+# Connettersi alla console ed effettuare il login come utente predefinito “rocky”.
+virsh console golden-image-builder
+```
+
+## 2. Configurazione a livello di sistema con `cloud.cfg.d`
+
+All'interno della nostra VM in esecuzione, ora possiamo personalizzare la configurazione `cloud-init` a livello di sistema. Non modificare mai direttamente il file master, `/etc/cloud/cloud.cfg`. La posizione corretta e sicura per gli aggiornamenti delle personalizzazioni è la directory `/etc/cloud/cloud.cfg.d/`. `cloud-init` legge tutti i file `.cfg` qui presenti in ordine alfabetico dopo il file principale `cloud.cfg`, consentendo di sovrascrivere le impostazioni predefinite.
+
+### Hands-on: impostazione dei valori predefiniti della golden image
+
+Applichiamo una policy sul nostro golden image: disabiliteremo l'autenticazione tramite password, imposteremo un nuovo utente predefinito e garantiremo che sia sempre installato un set di pacchetti di base.
+
+1. **Creare un file di configurazione personalizzato:** dall'interno della VM, creare `/etc/cloud/cloud.cfg.d/99-custom-defaults.cfg`. Il prefisso “99-” assicura che venga letto per ultimo.
+
+    ```bash
+    sudo cat <<EOF > /etc/cloud/cloud.cfg.d/99-custom-defaults.cfg
+    # Golden Image Customizations
+    
+    # Define a new default user named 'admin'
+    system_info:
+      default_user:
+        name: admin
+        sudo: ["ALL=(ALL) NOPASSWD:ALL"]
+        shell: /bin/bash
+    
+    # Enforce key-based SSH authentication
+    ssh_pwauth: false
+    
+    # Ensure a baseline of packages is always installed
+    packages:
+      - htop
+      - vim-enhanced
+    EOF
+    ```
+
+!!! tip "Disabilitazione di moduli specifici"
+
+    Una tecnica per una sicurezza efficace consiste nel disabilitare completamente determinati moduli `cloud-init`. Ad esempio, per impedire a qualsiasi utente di utilizzare `runcmd`, è possibile aggiungere quanto segue al file `.cfg` personalizzato. In questo modo si indica a `cloud-init` di eseguire un elenco vuoto di moduli durante la fase finale.
+    
+    `yaml     cloud_final_modules: []     `
+
+## 3. Generalizzare l'immagine
+
+La nostra VM ora contiene la nostra configurazione personalizzata, ma contiene anche identificatori univoci della macchina (come `/etc/machine-id`) e chiavi host SSH. Prima di poterlo clonare, dobbiamo rimuovere questi dati attraverso un processo chiamato **generalizzazione**.
+
+### Metodo 1: `cloud-init clean` (all'interno della VM)
+
+`cloud-init` fornisce un comando integrato per questo scopo.
+
+1. **Eseguire `cloud-init clean`:** dall'interno della VM, eseguire il seguente comando per rimuovere i dati specifici dell'istanza.
+
+    ```bash
+    sudo cloud-init clean --logs --seed
+    ```
+
+       !!! note "Riguardo a `cloud-init clean --seed`"
+
+        ```
+         Questo comando rimuove il seed univoco utilizzato da `cloud-init` per identificare l'istanza, costringendola a eseguire il processo da zero al successivo avvio. **Non** rimuove le configurazioni personalizzate in `/etc/cloud/cloud.cfg.d/`. Questo passaggio è essenziale per creare un modello veramente generico.
+        ```
+
+2. **Spegnimento immediato:** dopo la pulizia, spegnere immediatamente la VM.
+
+    ```bash
+    sudo poweroff
+    ```
+
+### Metodo 2: `virt-sysprep` (dall'host)
+
+Uno strumento ancora più completo e conforme agli standard del settore è `virt-sysprep`. È possibile eseguire questa operazione dal computer host sul disco della macchina virtuale spenta. Esegue tutte le azioni di `cloud-init clean` e molto altro ancora, come cancellare la cronologia dei comandi, rimuovere i file temporanei e reimpostare i file di log.
+
+1. **Assicurarsi che la VM sia spenta.**
+
+2. **Eseguire `virt-sysprep` dal vostro host:**
+
+    ```bash
+    sudo virt-sysprep -a golden-image-template.qcow2
+    ```
+
+Una volta completato il processo di generalizzazione, il file su disco (`golden-image-template.qcow2`) diveterà la vostra nuova nuova golden image.
+
+!!! note "Convenzioni di denominazione delle golden image"
+
+    È buona norma assegnare alle golden image nomi descrittivi che includano il sistema operativo e il numero di versione, ad esempio `rocky10-base-v1.0.qcow2`. Ciò facilita il controllo delle versioni e la gestione dell'infrastruttura.
+
+## 4. Verificare la golden image
+
+Proviamo la nostra nuova immagine avviando una nuova istanza _da_ essa senza alcun `user-data`.
+
+1. **Creare un nuovo VM disk dalla nostra golden image:**
+
+    ```bash
+    qemu-img create -f qcow2 -F qcow2 -b golden-image-template.qcow2 test-instance.qcow2
+    ```
+
+2. **Avviare l'istanza di prova:**
+
+    ```bash
+    virt-install --name golden-image-test --cloud-init none ...
+    ```
+
+3. **Verifica:** Connettersi alla console (`virsh console golden-image-test`). La richiesta di accesso dovrebbe essere per l'utente `admin`, non per `rocky`. Una volta effettuato l'accesso, è anche possibile verificare l'installazione di `htop` con (`rpm -q htop`). Questo conferma che le impostazioni predefinite integrate funzionano correttamente.
+
+## Il passo successivo
+
+Ora avete imparato come creare modelli standardizzati integrando le impostazioni predefinite nella configurazione di sistema di `cloud-init` e generalizzandoli correttamente per la clonazione. Nel prossimo capitolo tratteremo le competenze essenziali per la risoluzione dei problemi quando `cloud-init` non funziona come previsto.