diff --git a/docs/books/learning_ansible/02-advanced.it.md b/docs/books/learning_ansible/02-advanced.it.md
index fd06a129cf..5487cedd25 100644
--- a/docs/books/learning_ansible/02-advanced.it.md
+++ b/docs/books/learning_ansible/02-advanced.it.md
@@ -4,29 +4,29 @@ title: Ansibile Intermedio
# Ansibile Intermedio
-In questo capitolo continuerete a imparare come lavorare con Ansible.
+In questo capitolo si continuerà a imparare a lavorare con Ansible.
****
-**Obiettivi**: In questo capitolo imparerai a:
+**Obiettivi**: in questo capitolo imparerete come:
-:heavy_check_mark: lavorare con le variabili;
-:heavy_check_mark: usare i cicli;
-:heavy_check_mark: gestire i cambiamenti di stato e reagire a loro;
+:heavy_check_mark: lavorare con le variabili;
+:heavy_check_mark: usare i cicli;
+:heavy_check_mark: gestire i cambiamenti di stato e reagire a loro;
:heavy_check_mark: gestire le attività asincrone.
:checkered_flag: **ansible**, **moduli**, **playbook**
-**Conoscenza**: :star: :star: :star:
+**Conoscenza**: :star: :star: :star:
**Complessità**: :star: :star:
**Tempo di lettura**: 30 minuti
****
-Nel capitolo precedente, hai imparato come installare Ansible, usarlo dalla riga di comando, o come scrivere playbook per promuovere la riutilizzabilità del tuo codice.
+Nel capitolo precedente si è appreso come installare Ansible, utilizzarlo dalla riga di comando e scrivere playbook per promuovere la riutilizzabilità del codice.
-In questo capitolo, possiamo iniziare a scoprire alcune nozioni più avanzate su come usare Ansible, e scoprire alcune attività interessanti che userete molto regolarmente.
+In questo capitolo, possiamo iniziare a scoprire nozioni più avanzate su come utilizzare Ansible e alcuni task interessanti che utilizzerete regolarmente.
## Le variabili
@@ -45,11 +45,11 @@ Queste variabili possono essere organizzate come:
* dizionari,
* elenchi.
-Una variabile può essere definita in luoghi diversi, come in un playbook, in un ruolo o dalla riga di comando, per esempio.
+Una variabile può essere definita in diversi luoghi, come un playbook, un ruolo o la riga di comando.
Per esempio, da un playbook:
-```
+```bash
---
- hosts: apache1
vars:
@@ -61,8 +61,8 @@ Per esempio, da un playbook:
o dalla riga di comando:
-```
-$ ansible-playbook deploy-http.yml --extra-vars "service=httpd"
+```bash
+ansible-playbook deploy-http.yml --extra-vars "service=httpd"
```
Una volta definita, una variabile può essere utilizzata chiamandola tra due parentesi graffe:
@@ -72,7 +72,7 @@ Una volta definita, una variabile può essere utilizzata chiamandola tra due par
Per esempio:
-```
+```bash
- name: make sure apache is started
ansible.builtin.systemd:
name: "{{ service['rhel'] }}"
@@ -85,7 +85,7 @@ Naturalmente, è anche possibile accedere alle variabili globali (i **fatti**) d
Le variabili possono essere incluse in un file esterno al playbook, in questo caso questo file deve essere definito nel playbook con la direttiva `vars_files`:
-```
+```bash
---
- hosts: apache1
vars_files:
@@ -94,7 +94,7 @@ Le variabili possono essere incluse in un file esterno al playbook, in questo ca
Il file `myvariables.yml`:
-```
+```bash
---
port_http: 80
ansible.builtin.systemd::
@@ -104,7 +104,7 @@ ansible.builtin.systemd::
Può anche essere aggiunto dinamicamente con l'uso del modulo `include_vars`:
-```
+```bash
- name: Include secrets.
ansible.builtin.include_vars:
file: vault.yml
@@ -114,14 +114,14 @@ Può anche essere aggiunto dinamicamente con l'uso del modulo `include_vars`:
Per visualizzare una variabile, è necessario attivare il modulo `di debug` come segue:
-```
+```bash
- ansible.builtin.debug:
var: service['debian']
```
È anche possibile utilizzare la variabile all'interno di un testo:
-```
+```bash
- ansible.builtin.debug:
msg: "Print a variable in a message : {{ service['debian'] }}"
```
@@ -132,7 +132,7 @@ Per salvare il risultato di un compito e per essere in grado di accedervi più t
Uso di una variabile memorizzata:
-```
+```bash
- name: /home content
shell: ls /home
register: homes
@@ -148,17 +148,17 @@ Uso di una variabile memorizzata:
!!! Note "Nota"
- La variabile `homes.stdout_lines` è una lista di variabili di tipo stringa, un modo per organizzare variabili che non avevamo ancora incontrato.
+ La variabile `homes.stdout_lines' è un elenco di variabili di tipo stringa, un modo per organizzare le variabili che non avevamo ancora incontrato.
Le stringhe che compongono la variabile memorizzata possono essere consultate tramite il valore `stdout` (che ti permette di fare cose come `homes.stdout.find("core") != -1`), per sfruttarli usando un ciclo (vedi `loop`), o semplicemente dai loro indici come visto nell'esempio precedente.
-### Esercizi
+### Esercizi:
-* Scrivi un playbook `play-vars.yml` che stampa il nome della distribuzione di destinazione con la sua versione principale, utilizzando variabili globali.
+* Scrivere un playbook, `play-vars.yml,` usando variabili globali che stampino il nome della distribuzione e la versione principale del target.
* Scrivi un playbook usando il seguente dizionario per visualizzare i servizi che verranno installati:
-```
+```bash
service:
web:
name: apache
@@ -176,15 +176,15 @@ Il tipo predefinito dovrebbe essere "web".
## Gestione dei cicli
-Con l'aiuto di loop, è possibile iterare un compito su una lista, un hash, o dizionario, per esempio.
+Un ciclo consente di iterare un'operazione su un elenco, un hash o un dizionario, ad esempio.
!!! Note "Nota"
Ulteriori informazioni possono essere [trovate qui](https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html).
-Semplice esempio di utilizzo, creazione di 4 utenti:
+Un semplice esempio di utilizzo, la creazione di 4 utenti:
-```
+```bash
- name: add users
user:
name: "{{ item }}"
@@ -201,7 +201,7 @@ Ad ogni iterazione del ciclo, il valore della lista utilizzata viene memorizzato
Naturalmente, un elenco può essere definito in un file esterno:
-```
+```bash
users:
- antoine
- patrick
@@ -209,9 +209,9 @@ users:
- xavier
```
-ed essere usato all'interno del task come questo (dopo aver incluso il file var):
+ed essere utilizzato all'interno del task in questo modo (dopo aver incluso il file vars):
-```
+```bash
- name: add users
user:
name: "{{ item }}"
@@ -220,9 +220,9 @@ ed essere usato all'interno del task come questo (dopo aver incluso il file var)
loop: "{{ users }}"
```
-Possiamo usare l'esempio visto durante lo studio delle variabili memorizzate per migliorarlo. Uso di una variabile memorizzata:
+Possiamo utilizzare l'esempio visto durante lo studio delle variabili memorizzate per migliorarlo. Uso di una variabile memorizzata:
-```
+```bash
- name: /home content
shell: ls /home
register: homes
@@ -235,13 +235,13 @@ Possiamo usare l'esempio visto durante lo studio delle variabili memorizzate per
Un dizionario può anche essere usato in un ciclo.
-In questo caso, dovrai trasformare il dizionario in un oggetto con quello che viene chiamato filtro **jinja** (jinja è il motore di modellazione usato da Ansible): `dict2items`.
+In questo caso, è necessario trasformare il dizionario in un elemento con un filtro **jinja** (jinja è il motore di template utilizzato da Ansible): `| dict2items`.
-Nel ciclo, diventa possibile utilizzare `item.key` che corrisponde alla chiave del dizionario, e `item.value` che corrisponde ai valori della chiave.
+Nel ciclo, è possibile utilizzare `item.key`, che corrisponde alla chiave del dizionario, e `item.value`, che corrisponde ai valori della chiave.
Vediamo questo attraverso un esempio concreto, mostrando la gestione degli utenti del sistema:
-```
+```bash
---
- hosts: rocky8
become: true
@@ -267,9 +267,9 @@ Vediamo questo attraverso un esempio concreto, mostrando la gestione degli utent
!!! Note "Nota"
- Molte cose possono essere fatte con i loops. Scoprirete le possibilità offerte dai loop quando il vostro uso di Ansible vi spingerà ad usarli in modo più complesso.
+ I loop possono essere utilizzati per molte cose. Quando l'uso di Ansible vi spingerà a utilizzarli in modo più complesso, scoprirete le possibilità che offrono.
-### Esercizi
+### Esercizi:
* Visualizza il contenuto della variabile `service` dell'esercizio precedente utilizzando un loop.
@@ -287,13 +287,13 @@ Vediamo questo attraverso un esempio concreto, mostrando la gestione degli utent
Ulteriori informazioni possono essere [trovate qui](https://docs.ansible.com/ansible/latest/user_guide/playbooks_conditionals.html).
-L'istruzione `when` è molto utile in molti casi: non eseguire determinate azioni su determinati tipi di server, se un file o un utente non esistono, ecc.
+L'istruzione `when` è molto utile in molti casi, ad esempio per non eseguire determinate azioni su certi tipi di server, se un file o un utente non esiste, ecc.
!!! Note "Nota"
- Dietro la dichiarazione `when` le variabili non hanno bisogno di parentesi graffe doppie (sono infatti espressioni Jinja2...).
+ Dietro l'istruzione `when`, le variabili non hanno bisogno di doppie parentesi (sono infatti espressioni Jinja2...).
-```
+```bash
- name: "Reboot only Debian servers"
reboot:
when: ansible_os_family == "Debian"
@@ -301,7 +301,7 @@ L'istruzione `when` è molto utile in molti casi: non eseguire determinate azion
Le condizioni possono essere raggruppate tra parentesi:
-```
+```bash
- name: "Reboot only CentOS version 6 and Debian version 7"
reboot:
when: (ansible_distribution == "CentOS" and ansible_distribution_major_version == "6") or
@@ -310,7 +310,7 @@ Le condizioni possono essere raggruppate tra parentesi:
Le condizioni corrispondenti a una logica AND possono essere fornite sotto forma di elenco:
-```
+```bash
- name: "Reboot only CentOS version 6"
reboot:
when:
@@ -320,7 +320,7 @@ Le condizioni corrispondenti a una logica AND possono essere fornite sotto forma
Puoi testare il valore di un booleano e verificare che sia vero:
-```
+```bash
- name: check if directory exists
stat:
path: /home/ansible
@@ -338,19 +338,19 @@ Puoi testare il valore di un booleano e verificare che sia vero:
Puoi anche verificare che non sia vero:
-```
- when:
- - file.stat.exists
- - not file.stat.isdir
+```bash
+when:
+ - file.stat.exists
+ - not file.stat.isdir
```
Probabilmente dovrai verificare che esiste una variabile per evitare errori di esecuzione:
-```
- when: myboolean is defined and myboolean
+```bash
+when: myboolean is defined and myboolean
```
-### Esercizi
+### Esercizi:
* Stampa il valore di `service.web` solo quando `type` è uguale a `web`.
@@ -360,15 +360,15 @@ Probabilmente dovrai verificare che esiste una variabile per evitare errori di e
Ulteriori informazioni possono essere [trovate qui](https://docs.ansible.com/ansible/latest/user_guide/playbooks_handlers.html).
-I gestori consentono di avviare operazioni, come il riavvio di un servizio, quando si verificano modifiche.
+Quando si verificano le modifiche, i gestori sono autorizzati a lanciare operazioni, come il riavvio di un servizio.
-Un modulo, essendo idempotente, un playbook può rilevare che c'è stato un cambiamento significativo su un sistema remoto, e quindi innescare un'operazione di reazione a questo cambiamento. Una notifica viene inviata alla fine di un blocco di attività del playbook, e l'operazione di reazione sarà attivata solo una volta anche se più attività inviano la stessa notifica.
+Un modulo, essendo idempotente, un playbook può rilevare che c'è stato un cambiamento significativo su un sistema remoto e quindi attivare un'operazione in reazione a questo cambiamento. Una notifica viene inviata alla fine di un blocco di attività di playbook e l'operazione di reazione verrà attivata una sola volta, anche se più attività inviano la stessa notifica.
-Ad esempio, diverse attività possono indicare che il servizio `httpd` deve essere riavviato a causa di un cambiamento nei suoi file di configurazione. Ma il servizio sarà riavviato solo una volta per evitare riavvi non necessari.
+Ad esempio, diverse attività possono indicare che il servizio `httpd` deve essere riavviato a causa di un cambiamento nei suoi file di configurazione. Tuttavia, il servizio verrà riavviato solo una volta per evitare più avvii inutili.
-```
+```bash
- name: template configuration file
template:
src: template-site.j2
@@ -380,12 +380,12 @@ Ad esempio, diverse attività possono indicare che il servizio `httpd` deve esse
Un gestore è una sorta di compito referenziato da un nome globale unico:
-* È attivato da uno o più notificanti.
+* Uno o più notificatori lo attivano.
* Non inizia immediatamente, ma attende fino a quando tutte le attività sono complete.
Esempio di gestori:
-```
+```bash
handlers:
- name: restart memcached
@@ -401,7 +401,7 @@ handlers:
Dala versione 2.2 di Ansible, i gestori possono anche ascoltare direttamente:
-```
+```bash
handlers:
- name: restart memcached
@@ -428,20 +428,20 @@ tasks:
Ulteriori informazioni possono essere [trovate qui](https://docs.ansible.com/ansible/latest/user_guide/playbooks_async.html).
-Per impostazione predefinita, le connessioni SSH agli host rimangono aperte durante l'esecuzione delle varie attività di playbook su tutti i nodi.
+Per impostazione predefinita, le connessioni SSH agli host rimangono aperte durante l'esecuzione di varie attività del playbook su tutti i nodi.
Ciò può causare alcuni problemi, in particolare:
* se il tempo di esecuzione dell'attività è più lungo del timeout della connessione SSH
-* se la connessione è interrotta durante l'azione (riavvio del server, per esempio)
+* se la connessione viene interrotta durante l'azione (riavvio del server, ad esempio)
-In questo caso, si dovrà passare alla modalità asincrona e specificare un tempo di esecuzione massimo così come la frequenza (di default 10s) con cui si controllerà lo stato dell'host.
+In questo caso, si dovrà passare alla modalità asincrona e specificare un tempo massimo di esecuzione e la frequenza (per impostazione predefinita, 10s) con cui si controllerà lo stato dell'host.
Specificando un valore di misura di 0, Ansible eseguirà l'attività e continuerà senza preoccuparsi del risultato.
Ecco un esempio che utilizza attività asincrone, che consente di riavviare un server e attendere che la porta 22 sia nuovamente raggiungibile:
-```
+```bash
# Wait 2s and launch the reboot
- name: Reboot system
shell: sleep 2 && shutdown -r now "Ansible reboot triggered"
@@ -466,9 +466,9 @@ Puoi anche decidere di lanciare un'attività di lunga durata e dimenticarla (avv
## Risultati delle esercitazioni
-* Scrivi un playbook `play-vars.yml` che stampa il nome della distribuzione della destinazione con la sua versione principale, usando variabili globali.
+* Scrivere un playbook, `play-vars.yml, ' usando variabili globali, che stampi il nome della distribuzione del target e la versione principale.
-```
+```bash
---
- hosts: ansible_clients
@@ -479,7 +479,7 @@ Puoi anche decidere di lanciare un'attività di lunga durata e dimenticarla (avv
msg: "The distribution is {{ ansible_distribution }} version {{ ansible_distribution_major_version }}"
```
-```
+```bash
$ ansible-playbook play-vars.yml
PLAY [ansible_clients] *********************************************************************************
@@ -499,7 +499,7 @@ PLAY RECAP *********************************************************************
* Scrivi un playbook usando il seguente dizionario per visualizzare i servizi che verranno installati:
-```
+```bash
service:
web:
name: apache
@@ -511,7 +511,7 @@ service:
Il tipo predefinito dovrebbe essere "web".
-```
+```bash
---
- hosts: ansible_clients
vars:
@@ -531,7 +531,7 @@ Il tipo predefinito dovrebbe essere "web".
msg: "The {{ service[type]['name'] }} will be installed with the packages {{ service[type].rpm }}"
```
-```
+```bash
$ ansible-playbook display-dict.yml
PLAY [ansible_clients] *********************************************************************************
@@ -551,7 +551,7 @@ PLAY RECAP *********************************************************************
* Sovrascrivi la variabile `type` usando la riga di comando:
-```
+```bash
ansible-playbook --extra-vars "type=db" display-dict.yml
PLAY [ansible_clients] *********************************************************************************
@@ -570,7 +570,7 @@ PLAY RECAP *********************************************************************
* Esternalizza le variabili in un file `vars.yml`
-```
+```bash
type: web
service:
web:
@@ -581,7 +581,7 @@ service:
rpm: mariadb-server
```
-```
+```bash
---
- hosts: ansible_clients
vars_files:
@@ -594,7 +594,6 @@ service:
msg: "The {{ service[type]['name'] }} will be installed with the packages {{ service[type].rpm }}"
```
-
* Visualizza il contenuto della variabile `service` dell'esercizio precedente utilizzando un ciclo.
!!! Note "Nota"
@@ -611,7 +610,7 @@ service:
Con `dict2items`:
-```
+```bash
---
- hosts: ansible_clients
vars_files:
@@ -625,7 +624,7 @@ Con `dict2items`:
loop: "{{ service | dict2items }}"
```
-```
+```bash
$ ansible-playbook display-dict.yml
PLAY [ansible_clients] *********************************************************************************
@@ -648,7 +647,7 @@ PLAY RECAP *********************************************************************
Con `list`:
-```
+```bash
---
- hosts: ansible_clients
vars_files:
@@ -663,7 +662,7 @@ Con `list`:
~
```
-```
+```bash
$ ansible-playbook display-dict.yml
PLAY [ansible_clients] *********************************************************************************
@@ -685,7 +684,7 @@ PLAY RECAP *********************************************************************
* Stampa il valore di `service.web` solo quando `type` è uguale a `web`.
-```
+```bash
---
- hosts: ansible_clients
vars_files:
@@ -705,7 +704,7 @@ PLAY RECAP *********************************************************************
when: type == "db"
```
-```
+```bash
$ ansible-playbook display-dict.yml
PLAY [ansible_clients] *********************************************************************************
diff --git a/docs/books/learning_ansible/03-working-with-files.it.md b/docs/books/learning_ansible/03-working-with-files.it.md
index cc4fcb088a..ef4b6401be 100644
--- a/docs/books/learning_ansible/03-working-with-files.it.md
+++ b/docs/books/learning_ansible/03-working-with-files.it.md
@@ -10,13 +10,13 @@ In questo capitolo imparerai come gestire i file con Ansable.
**Obiettivi**: In questo capitolo imparerai come:
-:heavy_check_mark: modificare il contenuto del file;
-:heavy_check_mark: caricare i file ai server di destinazione;
+:heavy_check_mark: modificare il contenuto del file;
+:heavy_check_mark: caricare i file ai server di destinazione;
:heavy_check_mark: recuperare i file dai server di destinazione.
:checkered_flag: **ansible**, **moduli**, **files**
-**Conoscenza**: :star: :star:
+**Conoscenza**: :star: :star:
**Complessità**: :star:
**Tempo di lettura**: 20 minuti
@@ -41,7 +41,7 @@ Il modulo richiede:
Esempio di utilizzo:
-```
+```bash
- name: change value on inifile
community.general.ini_file:
dest: /path/to/file.ini
@@ -62,7 +62,7 @@ In questo caso, la riga da modificare in un file verrà trovata usando un regexp
Ad esempio, per garantire che la linea che inizia con `SELINUX=` nel file `/etc/selinux/config` contenga il valore `enforcing`:
-```
+```bash
- ansible.builtin.lineinfile:
path: /etc/selinux/config
regexp: '^SELINUX='
@@ -79,7 +79,7 @@ Quando un file deve essere copiato dal server Ansible in uno o più host, è meg
Qui stiamo copiando `myflile.conf` da una posizione all'altra:
-```
+```bash
- ansible.builtin.copy:
src: /data/ansible/sources/myfile.conf
dest: /etc/myfile.conf
@@ -98,7 +98,7 @@ Quando un file deve essere copiato da un server remoto al server locale, è megl
Questo modulo fa il contrario del modulo `copy`:
-```
+```bash
- ansible.builtin.fetch:
src: /etc/myfile.conf
dest: /data/ansible/backup/myfile-{{ inventory_hostname }}.conf
@@ -107,7 +107,7 @@ Questo modulo fa il contrario del modulo `copy`:
## modulo `template`
-Ansible e il suo modulo `template` utilizzano il sistema di template **Jinja2** (http://jinja.pocoo.org/docs/) per generare file sugli host di destinazione.
+Ansible e il suo modulo `template` utilizzano il sistema di template **Jinja2** () per generare i file sugli host di destinazione.
!!! Note "Nota"
@@ -115,7 +115,7 @@ Ansible e il suo modulo `template` utilizzano il sistema di template **Jinja2**
Per esempio:
-```
+```bash
- ansible.builtin.template:
src: /data/ansible/templates/monfichier.j2
dest: /etc/myfile.conf
@@ -126,7 +126,7 @@ Per esempio:
È possibile aggiungere una fase di convalida se il servizio di destinazione lo permette (ad esempio apache con il comando `apachectl -t`):
-```
+```bash
- template:
src: /data/ansible/templates/vhost.j2
dest: /etc/httpd/sites-available/vhost.conf
@@ -140,7 +140,7 @@ Per esempio:
Per caricare file da un sito web o ftp a uno o più host, utilizzare il modulo `get_url`:
-```
+```bash
- get_url:
url: http://site.com/archive.zip
dest: /tmp/archive.zip
diff --git a/docs/books/learning_ansible/05-deployments.it.md b/docs/books/learning_ansible/05-deployments.it.md
index 31e91a57ca..c231ebed4d 100644
--- a/docs/books/learning_ansible/05-deployments.it.md
+++ b/docs/books/learning_ansible/05-deployments.it.md
@@ -10,15 +10,15 @@ In questo capitolo imparerai come distribuire applicazioni con il ruolo Ansible
**Obiettivi**: In questo capitolo imparerai come:
-:heavy_check_mark: Implementare Ansistrano;
-:heavy_check_mark: Configurare Ansistrano;
-:heavy_check_mark: Usare cartelle e file condivisi tra le versioni distribuite;
-:heavy_check_mark: Distribuire diverse versioni di un sito da git;
+:heavy_check_mark: Implementare Ansistrano;
+:heavy_check_mark: Configurare Ansistrano;
+:heavy_check_mark: Usare cartelle e file condivisi tra le versioni distribuite;
+:heavy_check_mark: Distribuire diverse versioni di un sito da git;
:heavy_check_mark: Reagire tra i passaggi di implementazione.
:checkered_flag: **ansible**, **ansistrano**, **ruoli**, **distribuzioni**
-**Conoscenza**: :star: :star:
+**Conoscenza**: :star: :star:
**Complessità**: :star: :star: :star:
**Tempo di lettura**: 40 minuti
@@ -51,7 +51,7 @@ Ansistrano distribuisce applicazioni seguendo questi 5 passaggi:
Lo scheletro di una distribuzione con Ansistrano assomiglia a questo:
-```
+```bash
/var/www/site/
├── current -> ./releases/20210718100000Z
├── releases
@@ -83,7 +83,7 @@ Il server gestito:
Per una maggiore efficienza, useremo il ruolo `geerlingguy.apache` per configurare il server:
-```
+```bash
$ ansible-galaxy role install geerlingguy.apache
Starting galaxy role install process
- downloading role 'apache', owned by geerlingguy
@@ -94,7 +94,7 @@ Starting galaxy role install process
Probabilmente avremo bisogno di aprire alcune regole del firewall, quindi installeremo anche la collezione `ansible.posix` per lavorare con il suo modulo `firewalld`:
-```
+```bash
$ ansible-galaxy collection install ansible.posix
Starting galaxy collection install process
Process install dependency map
@@ -125,7 +125,7 @@ Considerazioni tecniche:
Il nostro playbook per configurare il server: `playbook-config-server.yml`
-```
+```bash
---
- hosts: ansible_clients
become: yes
@@ -136,27 +136,27 @@ Il nostro playbook per configurare il server: `playbook-config-server.yml`
DirectoryIndex index.php index.htm
apache_vhosts:
- servername: "website"
- documentroot: "{{ dest }}current/html"
+ documentroot: "{{ dest }}current/html"
tasks:
- name: create directory for website
file:
- path: /var/www/site/
- state: directory
- mode: 0755
+ path: /var/www/site/
+ state: directory
+ mode: 0755
- name: install git
package:
- name: git
- state: latest
+ name: git
+ state: latest
- name: permit traffic in default zone for http service
ansible.posix.firewalld:
- service: http
- permanent: yes
- state: enabled
- immediate: yes
+ service: http
+ permanent: yes
+ state: enabled
+ immediate: yes
roles:
- { role: geerlingguy.apache }
@@ -164,13 +164,13 @@ Il nostro playbook per configurare il server: `playbook-config-server.yml`
Il playbook può essere applicato al server:
-```
-$ ansible-playbook playbook-config-server.yml
+```bash
+ansible-playbook playbook-config-server.yml
```
Nota l'esecuzione dei seguenti compiti:
-```
+```bash
TASK [geerlingguy.apache : Ensure Apache is installed on RHEL.] ****************
TASK [geerlingguy.apache : Configure Apache.] **********************************
TASK [geerlingguy.apache : Add apache vhosts configuration.] *******************
@@ -183,7 +183,7 @@ Il ruolo `geerlingguy.apache` rende il nostro lavoro molto più facile prendendo
Puoi controllare che tutto funzioni usando `curl`:
-```
+```bash
$ curl -I http://192.168.1.11
HTTP/1.1 404 Not Found
Date: Mon, 05 Jul 2021 23:30:02 GMT
@@ -201,7 +201,7 @@ Ora che il nostro server è configurato, possiamo distribuire l'applicazione.
Per questo, useremo il ruolo `ansistrano.deploy` in un secondo playbook dedicato alla distribuzione delle applicazioni (per una maggiore leggibilità).
-```
+```bash
$ ansible-galaxy role install ansistrano.deploy
Starting galaxy role install process
- downloading role 'deploy', owned by ansistrano
@@ -215,7 +215,7 @@ Le fonti del software possono essere trovate nel [repository github](https://git
Creeremo un playbook `playbook-deploy.yml` per gestire la nostra distribuzione:
-```
+```bash
---
- hosts: ansible_clients
become: yes
@@ -230,7 +230,7 @@ Creeremo un playbook `playbook-deploy.yml` per gestire la nostra distribuzione:
- { role: ansistrano.deploy }
```
-```
+```bash
$ ansible-playbook playbook-deploy.yml
PLAY [ansible_clients] *********************************************************
@@ -257,13 +257,13 @@ TASK [ansistrano.deploy : ANSISTRANO | Change softlink to new release]
TASK [ansistrano.deploy : ANSISTRANO | Clean up releases]
PLAY RECAP ********************************************************************************************************************************************************************************************************
-192.168.1.11 : ok=25 changed=8 unreachable=0 failed=0 skipped=14 rescued=0 ignored=0
+192.168.1.11 : ok=25 changed=8 unreachable=0 failed=0 skipped=14 rescued=0 ignored=0
```
Tante cose fatte con sole 11 righe di codice!
-```
+```html
$ curl http://192.168.1.11
@@ -281,7 +281,7 @@ Ora puoi connetterti da ssh alla tua macchina client.
* Crea un `albero` nella directory `/var/www/site/`:
-```
+```bash
$ tree /var/www/site/
/var/www/site
├── current -> ./releases/20210722155312Z
@@ -289,7 +289,7 @@ $ tree /var/www/site/
│ └── 20210722155312Z
│ ├── REVISION
│ └── html
-│ └── index.htm
+│ └── index.htm
├── repo
│ └── html
│ └── index.htm
@@ -304,7 +304,7 @@ Nota che:
* Dal server Ansible riavviare la distribuzione **3** volte, quindi controllare il client.
-```
+```bash
$ tree /var/www/site/
var/www/site
├── current -> ./releases/20210722160048Z
@@ -324,7 +324,7 @@ var/www/site
│ └── 20210722160048Z
│ ├── REVISION
│ └── html
-│ └── index.htm
+│ └── index.htm
├── repo
│ └── html
│ └── index.htm
@@ -342,7 +342,7 @@ La variabile `ansistrano_keep_releases` è usata per specificare il numero di ri
* Utilizzando la variabile `ansistrano_keep_releases`, mantieni solo 3 rilasci del progetto. Verifica.
-```
+```bash
---
- hosts: ansible_clients
become: yes
@@ -358,14 +358,14 @@ La variabile `ansistrano_keep_releases` è usata per specificare il numero di ri
- { role: ansistrano.deploy }
```
-```
+```bash
---
$ ansible-playbook -i hosts playbook-deploy.yml
```
Sulla macchina client:
-```
+```bash
$ tree /var/www/site/
/var/www/site
├── current -> ./releases/20210722160318Z
@@ -381,7 +381,7 @@ $ tree /var/www/site/
│ └── 20210722160318Z
│ ├── REVISION
│ └── html
-│ └── index.htm
+│ └── index.htm
├── repo
│ └── html
│ └── index.htm
@@ -390,8 +390,7 @@ $ tree /var/www/site/
### Utilizzo di shared_path e shared_files
-
-```
+```bash
---
- hosts: ansible_clients
become: yes
@@ -414,13 +413,13 @@ $ tree /var/www/site/
Sulla macchina client, crea il file `log` nella directory `shared`:
-```
+```bash
sudo touch /var/www/site/shared/logs
```
Quindi esegui il playbook:
-```
+```bash
TASK [ansistrano.deploy : ANSISTRANO | Ensure shared paths targets are absent] *******************************************************
ok: [192.168.10.11] => (item=img)
ok: [192.168.10.11] => (item=css)
@@ -434,7 +433,7 @@ changed: [192.168.10.11] => (item=logs)
Sulla macchina client:
-```
+```bash
$ tree -F /var/www/site/
/var/www/site/
├── current -> ./releases/20210722160631Z/
@@ -487,7 +486,7 @@ Non dimenticare di modificare la configurazione di Apache per tenere conto di qu
Modifica il playbook per la configurazione del server `playbook-config-server.yml`
-```
+```bash
---
- hosts: ansible_clients
become: yes
@@ -498,20 +497,20 @@ Modifica il playbook per la configurazione del server `playbook-config-server.ym
DirectoryIndex index.php index.htm
apache_vhosts:
- servername: "website"
- documentroot: "{{ dest }}current/" # <1>
+ documentroot: "{{ dest }}current/" # <1>
tasks:
- name: create directory for website
file:
- path: /var/www/site/
- state: directory
- mode: 0755
+ path: /var/www/site/
+ state: directory
+ mode: 0755
- name: install git
package:
- name: git
- state: latest
+ name: git
+ state: latest
roles:
- { role: geerlingguy.apache }
@@ -521,7 +520,7 @@ Modifica il playbook per la configurazione del server `playbook-config-server.ym
Cambia il playbook per la distribuzione `playbook-deploy.yml`
-```
+```bash
---
- hosts: ansible_clients
become: yes
@@ -549,7 +548,7 @@ Cambia il playbook per la distribuzione `playbook-deploy.yml`
* Controlla la macchina cliente:
-```
+```bash
$ tree -F /var/www/site/
/var/www/site/
├── current -> ./releases/20210722161542Z/
@@ -588,7 +587,7 @@ La variabile `ansistrano_git_branch` è usata per specificare un `branch` o un `
* Distribuisci il branch `releases/v1.1.0`:
-```
+```bash
---
- hosts: ansible_clients
become: yes
@@ -615,7 +614,7 @@ La variabile `ansistrano_git_branch` è usata per specificare un `branch` o un `
Per divertirti, durante la distribuzione, puoi aggiornare il browser, per vedere in 'live' il cambiamento.
-```
+```html
$ curl http://192.168.1.11
@@ -629,7 +628,7 @@ $ curl http://192.168.1.11
* Distribuisci il tag `v2.0.0`:
-```
+```bash
---
- hosts: ansible_clients
become: yes
@@ -652,7 +651,7 @@ $ curl http://192.168.1.11
- { role: ansistrano.deploy }
```
-```
+```html
$ curl http://192.168.1.11
@@ -685,8 +684,7 @@ Un playbook può essere incluso attraverso le variabili fornite per questo scopo
* Esempio semplice: invia un'email (o qualsiasi cosa desideri come la notifica di Slack) all'inizio della distribuzione:
-
-```
+```bash
---
- hosts: ansible_clients
become: yes
@@ -712,7 +710,7 @@ Un playbook può essere incluso attraverso le variabili fornite per questo scopo
Crea il file `deploy/before-setup-tasks.yml`:
-```
+```bash
---
- name: Send a mail
mail:
@@ -720,7 +718,7 @@ Crea il file `deploy/before-setup-tasks.yml`:
delegate_to: localhost
```
-```
+```bash
TASK [ansistrano.deploy : include] *************************************************************************************
included: /home/ansible/deploy/before-setup-tasks.yml for 192.168.10.11
@@ -728,7 +726,7 @@ TASK [ansistrano.deploy : Send a mail] *****************************************
ok: [192.168.10.11 -> localhost]
```
-```
+```bash
[root] # mailx
Heirloom Mail version 12.5 7/5/10. Type ? for help.
"/var/spool/mail/root": 1 message 1 new
@@ -737,7 +735,7 @@ Heirloom Mail version 12.5 7/5/10. Type ? for help.
* Probabilmente dovrai riavviare alcuni servizi alla fine della distribuzione, per esempio per pulire la cache. Riavviamo Apache alla fine della distribuzione:
-```
+```bash
---
- hosts: ansible_clients
become: yes
@@ -764,7 +762,7 @@ Heirloom Mail version 12.5 7/5/10. Type ? for help.
Crea il file `deploy/after-symlink-tasks.yml`:
-```
+```bash
---
- name: restart apache
systemd:
@@ -772,7 +770,7 @@ Crea il file `deploy/after-symlink-tasks.yml`:
state: restarted
```
-```
+```bash
TASK [ansistrano.deploy : include] *************************************************************************************
included: /home/ansible/deploy/after-symlink-tasks.yml for 192.168.10.11
diff --git a/docs/books/learning_ansible/06-large-scale-infrastructure.it.md b/docs/books/learning_ansible/06-large-scale-infrastructure.it.md
index 794bc019ea..3d60c1cbfa 100644
--- a/docs/books/learning_ansible/06-large-scale-infrastructure.it.md
+++ b/docs/books/learning_ansible/06-large-scale-infrastructure.it.md
@@ -10,12 +10,12 @@ In questo capitolo imparerai come ridimensionare il tuo sistema di gestione dell
**Obiettivi**: In questo capitolo imparerai come:
-:heavy_check_mark: Organizzare il tuo codice per un'infrastruttura di grandi dimensioni;
+:heavy_check_mark: Organizzare il tuo codice per un'infrastruttura di grandi dimensioni;
:heavy_check_mark: Applicare tutto o parte della tua gestione di configurazione a un gruppo di nodi;
:checkered_flag: **ansible**, **config management**, **scale**
-**Conoscenza**: :star: :star: :star:
+**Conoscenza**: :star: :star: :star:
**Complessità**: :star: :star: :star: :star:
**Tempo di lettura**: 30 minuti
@@ -52,7 +52,7 @@ Non ne abbiamo ancora discusso qui, ma dovresti sapere che Ansible può caricare
La documentazione Ansible suggerisce di organizzare il nostro codice come sotto:
-```
+```bash
inventories/
production/
hosts # inventory file for production servers
@@ -82,7 +82,7 @@ L'uso di tag Ansible ti permette di eseguire o saltare una parte delle attività
Ad esempio, modifichiamo l'attività di creazione degli utenti:
-```
+```bash
- name: add users
user:
name: "{{ item }}"
@@ -98,7 +98,7 @@ Ad esempio, modifichiamo l'attività di creazione degli utenti:
Ora puoi riprodurre solo le attività con il tag `users` con l'opzione `ansible-playbook` `--tags`:
-```
+```bash
ansible-playbook -i inventories/production/hosts --tags users site.yml
```
@@ -110,7 +110,7 @@ Concentriamoci su una proposta per l'organizzazione di file e directory necessar
Il nostro punto di partenza sarà il file `site.yml`. Questo file è un po 'come il direttore d'orchestra del CMS in quanto includerà solo i ruoli necessari per i nodi di destinazione se necessario:
-```
+```bash
---
- name: "Config Management for {{ target }}"
hosts: "{{ target }}"
@@ -126,7 +126,7 @@ Naturalmente, questi ruoli devono essere creati sotto la directory `roles` allo
Mi piace gestire i miei vars globali all'interno di un `vars/global_vars.yml`, anche se potrei memorizzarli all'interno di un file situato in `inventories/production/group_vars/all.yml`
-```
+```bash
---
- name: "Config Management for {{ target }}"
hosts: "{{ target }}"
@@ -141,7 +141,7 @@ Mi piace gestire i miei vars globali all'interno di un `vars/global_vars.yml`, a
Mi piace inoltre mantenere la possibilità di disabilitare una funzionalità. Quindi includo i miei ruoli con una condizione e un valore predefinito come questo:
-```
+```bash
---
- name: "Config Management for {{ target }}"
hosts: "{{ target }}"
@@ -160,8 +160,7 @@ Mi piace inoltre mantenere la possibilità di disabilitare una funzionalità. Qu
Non dimenticare di usare i tag:
-
-```
+```bash
- name: "Config Management for {{ target }}"
hosts: "{{ target }}"
vars_files:
@@ -183,7 +182,7 @@ Non dimenticare di usare i tag:
Dovresti ottenere qualcosa di simile:
-```
+```bash
$ tree cms
cms
├── inventories
@@ -218,7 +217,7 @@ cms
Avviamo il playbook ed eseguiamo alcuni test:
-```
+```bash
$ ansible-playbook -i inventories/production/hosts -e "target=client1" site.yml
PLAY [Config Management for client1] ****************************************************************************
@@ -242,14 +241,13 @@ Come puoi vedere, per impostazione predefinita, vengono giocate solo le attivit
Attiviamo nell'inventario la `functionality2` per il nostro nodo mirato e riavviamo il playbook:
-```
+```bash
$ vim inventories/production/host_vars/client1.yml
---
enable_functionality2: true
```
-
-```
+```bash
$ ansible-playbook -i inventories/production/hosts -e "target=client1" site.yml
PLAY [Config Management for client1] ****************************************************************************
@@ -273,7 +271,7 @@ client1 : ok=3 changed=0 unreachable=0 failed=0 s
Prova ad applicare solo `funzionalità2`:
-```
+```bash
$ ansible-playbook -i inventories/production/hosts -e "target=client1" --tags functionality2 site.yml
PLAY [Config Management for client1] ****************************************************************************
@@ -292,7 +290,7 @@ client1 : ok=2 changed=0 unreachable=0 failed=0 s
Eseguiamo l'intero l'inventario:
-```
+```bash
$ ansible-playbook -i inventories/production/hosts -e "target=plateform" site.yml
PLAY [Config Management for plateform] **************************************************************************
diff --git a/docs/books/learning_bash/01-first-script.it.md b/docs/books/learning_bash/01-first-script.it.md
index ea741e19d2..8aa4a8ce10 100644
--- a/docs/books/learning_bash/01-first-script.it.md
+++ b/docs/books/learning_bash/01-first-script.it.md
@@ -23,7 +23,7 @@ In questo capitolo imparerete a scrivere il vostro primo script in bash.
:checkered_flag: **linux**, **script**, **bash**
-**Conoscenza**: :star:
+**Conoscenza**: :star:
**Complessità**: :star:
**Tempo di lettura**: 10 minuti
@@ -46,7 +46,7 @@ Il nome dello script deve rispettare alcune regole:
In queste lezioni l'autore utilizza il simbolo "$" per indicare il prompt dei comandi dell'utente.
-```
+```bash
#!/usr/bin/env bash
#
# Autore : Team di documentazione Rocky
@@ -60,14 +60,14 @@ echo "Hello world!"
Per poter eseguire questo script, come argomento della bash:
-```
+```bash
$ bash hello-world.sh
Hello world !
```
O, più semplicemente, dopo avergli dato il diritto di eseguire:
-```
+```bash
$ chmod u+x ./hello-world.sh
$ ./hello-world.sh
Hello world !
@@ -82,19 +82,19 @@ Hello world !
La prima riga da scrivere in qualsiasi script è quella che indica il nome del binario di shell da usare per eseguirlo. Se si vuole usare la shell `ksh` o il linguaggio interpretato `python`, si sostituisce la riga:
-```
+```bash
#!/usr/bin/env bash
```
con :
-```
+```bash
#!/usr/bin/env ksh
```
o con :
-```
+```bash
#!/usr/bin/env python
```
@@ -115,7 +115,7 @@ I commenti possono essere inseriti su una riga separata o alla fine di una riga
Esempio:
-```
+```bash
# Questo programma visualizza la data
date # Questa riga è la riga che visualizza la data!
```
diff --git a/docs/books/learning_bash/02-using-variables.it.md b/docs/books/learning_bash/02-using-variables.it.md
index 81013cc478..11ef650141 100644
--- a/docs/books/learning_bash/02-using-variables.it.md
+++ b/docs/books/learning_bash/02-using-variables.it.md
@@ -41,7 +41,7 @@ Il contenuto di una variabile può essere modificato durante lo script, poiché
La nozione di tipo di variabile in uno script di shell è possibile, ma viene utilizzata molto raramente. Il contenuto di una variabile è sempre un carattere o una stringa.
-```
+```bash
#!/usr/bin/env bash
#
@@ -76,7 +76,7 @@ Per convenzione, le variabili create da un utente hanno un nome in minuscolo. Qu
Il carattere `=` assegna il contenuto a una variabile:
-```
+```bash
variable=value
rep_name="/home"
```
@@ -85,14 +85,14 @@ Non ci sono spazi prima o dopo il segno `=`.
Una volta creata la variabile, è possibile utilizzarla anteponendole un dollaro $.
-```
+```bash
file=file_name
touch $file
```
Si raccomanda vivamente di proteggere le variabili con le virgolette, come nell'esempio seguente:
-```
+```bash
file=file name
touch $file
touch "$file"
@@ -102,7 +102,7 @@ Poiché il contenuto della variabile contiene uno spazio, il primo `touch` creer
Per isolare il nome della variabile dal resto del testo, è necessario utilizzare le virgolette o le parentesi graffe:
-```
+```bash
file=file_name
touch "$file"1
touch ${file}1
@@ -112,7 +112,7 @@ touch ${file}1
L'uso degli apostrofi impedisce l'interpretazione dei caratteri speciali.
-```
+```bash
message="Hello"
echo "This is the content of the variable message: $message"
Here is the content of the variable message: Hello
@@ -126,7 +126,7 @@ Il comando `unset` consente di cancellare una variabile.
Esempio:
-```
+```bash
name="NAME"
firstname="Firstname"
echo "$name $firstname"
@@ -140,7 +140,7 @@ Il comando `readonly` o `typeset -r` blocca una variabile.
Esempio:
-```
+```bash
name="NAME"
readonly name
name="OTHER NAME"
@@ -195,21 +195,21 @@ La modifica di una variabile esportata in un processo figlio non può essere ric
La sintassi per la sub-esecuzione di un comando è la seguente:
-```
+```bash
variable=`command`
variable=$(command) # Preferred syntax
```
Esempio:
-```
-$ day=`date +%d`
-$ homedir=$(pwd)
+```bash
+day=`date +%d`
+homedir=$(pwd)
```
Con tutto ciò che abbiamo appena visto, il nostro script di backup potrebbe assomigliare a questo:
-```
+```bash
#!/usr/bin/env bash
#
@@ -257,13 +257,13 @@ logger "Backup of system files by ${USER} on ${HOSTNAME} in the folder ${DESTINA
Esecuzione dello script di backup:
-```
-$ sudo ./backup.sh
+```bash
+sudo ./backup.sh
```
questo ci darà:
-```
+```bash
****************************************************************
Backup Script - Backup on desktop
****************************************************************
diff --git a/docs/books/learning_bash/03-data-entry-and-manipulations.it.md b/docs/books/learning_bash/03-data-entry-and-manipulations.it.md
index 83364b032a..e3bdc55432 100644
--- a/docs/books/learning_bash/03-data-entry-and-manipulations.it.md
+++ b/docs/books/learning_bash/03-data-entry-and-manipulations.it.md
@@ -17,9 +17,9 @@ In questo capitolo imparerete a far interagire i vostri script con gli utenti e
**Obiettivi**: In questo capitolo imparerete a:
-:heavy_check_mark: leggere l'input di un utente;
-:heavy_check_mark: manipolare voci di dati;
-:heavy_check_mark: utilizzare argomenti all'interno di uno script;
+:heavy_check_mark: leggere l'input di un utente;
+:heavy_check_mark: manipolare voci di dati;
+:heavy_check_mark: utilizzare argomenti all'interno di uno script;
:heavy_check_mark: gestire variabili posizionali;
:checkered_flag: **linux**, **script**, **bash**, **variable**
@@ -39,13 +39,13 @@ Il comando `read` consente di inserire una stringa di caratteri e di memorizzarl
Sintassi del comando read:
-```
+```bash
read [-n X] [-p] [-s] [variable]
```
Il primo esempio qui sotto richiede l'inserimento di due variabili: "name" e "firstname", ma poiché non c'è alcun prompt, bisogna sapere in anticipo che questo è il caso. Nel caso di questo particolare inserimento, ogni variabile immessa sarà separata da uno spazio. Il secondo esempio richiede la variabile "name" con il testo di richiesta incluso:
-```
+```bash
read name firstname
read -p "Please type your name: " name
```
@@ -56,21 +56,21 @@ read -p "Please type your name: " name
| `-n` | Limita il numero di caratteri da inserire. |
| `-s` | Nasconde l'input. |
-Quando si utilizza l'opzione `-n`, la shell convalida automaticamente l'input dopo il numero di caratteri specificato. L'utente non deve premere il tasto INVIO.
+Quando si utilizza l'opzione `-n`, la shell convalida automaticamente l'input dopo il numero di caratteri specificato. L'utente non deve premere il tasto ++enter++.
-```
+```bash
read -n5 name
```
Il comando `read` consente di interrompere l'esecuzione dello script mentre l'utente inserisce le informazioni. L'input dell'utente viene scomposto in parole assegnate a una o più variabili predefinite. Le parole sono stringhe di caratteri separate dal separatore di campo.
-La fine dell'immissione è determinata dalla pressione del tasto INVIO.
+La fine dell'immissione è determinata dalla pressione del tasto ++enter++.
Una volta convalidato l'input, ogni parola viene memorizzata nella variabile predefinita.
La divisione delle parole è definita dal carattere separatore di campo. Questo separatore è memorizzato nella variabile di sistema `IFS`(**Internal Field Separator**).
-```
+```bash
set | grep IFS
IFS=$' \t\n'
```
@@ -79,9 +79,9 @@ Per impostazione predefinita, l'IFS contiene spazio, tabulazione e avanzamento r
Se utilizzato senza specificare una variabile, questo comando mette semplicemente in pausa lo script. Lo script continua la sua esecuzione quando l'input viene convalidato.
-Viene utilizzato per mettere in pausa uno script durante il debug o per chiedere all'utente di premere INVIO per continuare.
+Viene utilizzato per mettere in pausa uno script durante il debug o per chiedere all'utente di premere ++enter++ per continuare.
-```
+```bash
echo -n "Press [ENTER] to continue..."
read
```
@@ -92,13 +92,13 @@ Il comando cut consente di isolare una colonna in un file o in un flusso.
Sintassi del comando cut:
-```
+```bash
cut [-cx] [-dy] [-fz] file
```
Esempio di utilizzo del comando cut:
-```
+```bash
cut -d: -f1 /etc/passwd
```
@@ -115,7 +115,7 @@ Il vantaggio principale di questo comando sarà la sua associazione con un fluss
Esempio:
-```
+```bash
grep "^root:" /etc/passwd | cut -d: -f3
0
```
@@ -130,7 +130,7 @@ Il comando `tr` consente di convertire una stringa.
Sintassi del comando `tr`:
-```
+```bash
tr [-csd] string1 string2
```
@@ -142,22 +142,28 @@ tr [-csd] string1 string2
Segue un esempio di utilizzo del comando `tr`. Se si usa `grep` per restituire la voce del file `passwd` di root, si ottiene questo risultato:
-```
+```bash
grep root /etc/passwd
```
+
restituisce:
-```
+
+```bash
root:x:0:0:root:/root:/bin/bash
```
+
Ora usiamo il comando `tr` e riduciamo le "o" nella riga:
-```
+```bash
grep root /etc/passwd | tr -s "o"
```
+
che restituisce questo:
-```
+
+```bash
rot:x:0:0:rot:/rot:/bin/bash
```
+
## Estrarre il nome e il percorso di un file
Il comando `basename` consente di estrarre il nome del file da un percorso.
@@ -166,14 +172,17 @@ Il comando `dirname` consente di estrarre il percorso padre di un file.
Esempi:
-```
+```bash
echo $FILE=/usr/bin/passwd
basename $FILE
```
+
Il che si tradurrebbe in "passwd"
-```
+
+```bash
dirname $FILE
```
+
Il risultato sarebbe: "/usr/bin"
## Argomenti di uno script
@@ -190,7 +199,7 @@ Lo svantaggio principale è che l'utente dovrà essere avvisato della sintassi d
Gli argomenti vengono inseriti quando si immette il comando di script. Sono separati da uno spazio.
-```
+```bash
./script argument1 argument2
```
@@ -211,7 +220,7 @@ Queste variabili possono essere utilizzate nello script come qualsiasi altra var
Esempio:
-```
+```bash
#!/usr/bin/env bash
#
# Author : Damien dit LeDub
@@ -235,7 +244,7 @@ echo "All without separation (\$@) = $@"
questo ci darà:
-```
+```bash
$ ./arguments.sh one two "tree four"
The number of arguments ($#) = 3
The name of the script ($0) = ./arguments.sh
@@ -261,7 +270,7 @@ Il comando shift consente di spostare le variabili posizionali.
Modifichiamo l'esempio precedente per illustrare l'impatto del comando shift sulle variabili posizionali:
-```
+```bash
#!/usr/bin/env bash
#
# Author : Damien dit LeDub
@@ -296,7 +305,7 @@ echo "All without separation (\$@) = $@"
questo ci darà:
-```
+```bash
./arguments.sh one two "tree four"
The number of arguments ($#) = 3
The 1st argument ($1) = one
@@ -327,13 +336,13 @@ Il comando `set` divide una stringa in variabili posizionali.
Sintassi del comando set:
-```
+```bash
set [value] [$variable]
```
Esempio:
-```
+```bash
$ set one two three
$ echo $1 $2 $3 $#
one two three 3
diff --git a/docs/books/learning_rsync/03_rsync_demo02.it.md b/docs/books/learning_rsync/03_rsync_demo02.it.md
index a6a4afa64a..2a5c196f35 100644
--- a/docs/books/learning_rsync/03_rsync_demo02.it.md
+++ b/docs/books/learning_rsync/03_rsync_demo02.it.md
@@ -6,6 +6,7 @@ update: 2021-12-25
---
# Dimostrazione basata sul protocollo rsync
+
In vsftpd, ci sono utenti virtuali (utenti impersonali personalizzati dall'amministratore) perché non è sicuro usare utenti anonimi e utenti locali. Sappiamo che un server basato sul protocollo SSH deve garantire che ci sia un sistema di utenti. Quando ci sono molti requisiti di sincronizzazione, può essere necessario creare molti utenti. Questo ovviamente non soddisfa gli standard di gestione e manutenzione GNU/Linux (più utenti, più insicuro), in rsync, per motivi di sicurezza, c'è un metodo di autenticazione il protocollo rsync.
**Come farlo?**
@@ -17,7 +18,7 @@ In vsftpd, ci sono utenti virtuali (utenti impersonali personalizzati dall'ammin
[root@Rocky ~]# vim /etc/rsyncd.conf
```
-Alcuni parametri e valori di questo file sono i seguenti, [ qui ](04_rsync_configure.md) si trovano altre descrizioni dei parametri:
+Alcuni parametri e valori di questo file sono i seguenti, [qui](04_rsync_configure.md) si trovano altre descrizioni dei parametri:
| Elemento | Descrizione |
| ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
diff --git a/docs/books/learning_rsync/04_rsync_configure.it.md b/docs/books/learning_rsync/04_rsync_configure.it.md
index 211153e348..ec272a851e 100644
--- a/docs/books/learning_rsync/04_rsync_configure.it.md
+++ b/docs/books/learning_rsync/04_rsync_configure.it.md
@@ -6,7 +6,7 @@ update: 2021-12-25
# /etc/rsyncd.conf
-Nel precedente articolo [ rsync demo 02 ](03_rsync_demo02.md) abbiamo introdotto alcuni parametri di base. Questo articolo è per integrare altri parametri.
+Nel precedente articolo [rsync demo 02](03_rsync_demo02.md) abbiamo introdotto alcuni parametri di base. Questo articolo è per integrare altri parametri.
| Parametri | Descrizione |
| ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
diff --git a/docs/books/learning_rsync/06_rsync_inotify.it.md b/docs/books/learning_rsync/06_rsync_inotify.it.md
index f8e94b95af..40df5cad4d 100644
--- a/docs/books/learning_rsync/06_rsync_inotify.it.md
+++ b/docs/books/learning_rsync/06_rsync_inotify.it.md
@@ -62,8 +62,10 @@ fs.inotify.max_user_watches = 1048576
## Comandi correlati
Lo strumento inotify-tools ha due comandi, chiamati:
-* **inotifywait**: per il monitoraggio continuo, risultati in tempo reale. È generalmente usato con lo strumento di backup incrementale rsync. Poiché si tratta di un monitoraggio del file system, può essere utilizzato con uno script. Introdurremo lo script specifico in un secondo momento.
-* **inotifywatch**: per il monitoraggio a breve termine, risultati in uscita dopo il completamento dell'attività.
+
+* **inotifywait**: per il monitoraggio continuo, risultati in tempo reale. È generalmente usato con lo strumento di backup incrementale rsync. Poiché si tratta di un monitoraggio del file system, può essere utilizzato con uno script. Introdurremo lo script specifico in un secondo momento.
+
+* **inotifywatch**: per il monitoraggio a breve termine, risultati in uscita dopo il completamento dell'attività.
`inotifywait` ha principalmente le seguenti opzioni:
diff --git a/docs/books/lxd_server/00-toc.it.md b/docs/books/lxd_server/00-toc.it.md
index f713edafe3..e7dcf8b944 100644
--- a/docs/books/lxd_server/00-toc.it.md
+++ b/docs/books/lxd_server/00-toc.it.md
@@ -10,6 +10,20 @@ tags:
# Creare un server LXD completo
+??? warning "Stato attuale di LXD su Rocky Linux!"
+
+ Quasi un anno fa, sulla mailing list lxc-users è stato pubblicato il seguente annuncio:
+
+ > Canonical, il creatore e principale collaboratore del progetto LXD, ha deciso che dopo oltre 8 anni di appartenenza alla comunità di Linux Containers, il progetto sarebbe stato gestito meglio direttamente da Canonical.
+
+ Uno dei fattori decisivi sono state le dimissioni di alcuni sviluppatori principali di LXD, i quali hanno poi effettuato il fork di LXD in Incus, annunciando il fork nell'agosto 2023. Una versione di rilascio (0.1) è stata rilasciata nell'ottobre 2023, e da allora gli sviluppatori hanno rapidamente sviluppato questa versione con rilasci successivi fino alla 0.7 (marzo 2024). Dopo la 0.7 è arrivata la versione di supporto a lungo termine, la 6.0 LTS, il 4 aprile 2024.
+
+ Durante tutto il processo, si pensava che Cannonical avrebbe continuato a mantenere i collegamenti alle immagini dei container fornite da Linux Containers, ma a causa di un [cambio di licenza](https://stgraber.org/2023/12/12/lxd-now-re-licensed-and-under-a-cla/) è diventato impossibile per Linux Containers continuare a offrire le immagini dei container all'interno di LXD. Ciò significa che LXD avrà delle immagini container, ma non saranno le immagini container che ci si aspetta attualmente. Linux Containers continua a ospitare e supportare le proprie immagini se si utilizza Incus.
+
+ Questo documento utilizza LXD, piuttosto che Incus, MA è nostra intenzione riscrivere la procedura per Incus. Speravamo che una versione RPM di Incus venisse rilasciata nell'EPEL e, sebbene sia in lavorazione, non è ancora pronta. Ciò significa che per riscrivere questa procedura per Incus, dobbiamo concentrare i nostri interessi sulla routine di installazione e conversione del pacchetto sorgente. Il motivo di questo lungo avvertimento è che non vogliamo che si prenda il tempo di installare con questa procedura e poi si scopra che le immagini del contenitore (Rocky Linux, per esempio) non sono disponibili in LXD.
+
+ Tenete d'occhio i cambiamenti qui!
+
## Introduzione
LXD è descritto meglio sul sito web [ufficiale](https://documentation.ubuntu.com/lxd/en/latest/), ma consideratelo come un sistema di container che offre i vantaggi dei server virtuali in un container.
diff --git a/docs/books/lxd_server/01-install.it.md b/docs/books/lxd_server/01-install.it.md
index 88147f9706..aade472952 100644
--- a/docs/books/lxd_server/01-install.it.md
+++ b/docs/books/lxd_server/01-install.it.md
@@ -11,19 +11,19 @@ tags:
# Capitolo 1: Installazione e configurazione
-In questo capitolo dovrete essere l'utente root o dovrete essere in grado di fare _sudo_ a root.
+In tutto questo capitolo dovrete essere l'utente root o dovrete essere in grado di passare a root con *sudo*.
## Installare i repository EPEL e OpenZFS
LXD richiede i repository EPEL (Extra Packages for Enterprise Linux), che sono facili da installare:
-```
+```bash
dnf install epel-release
```
Una volta installato, verificare che non vi siano aggiornamenti:
-```
+```bash
dnf upgrade
```
@@ -33,7 +33,7 @@ Se durante il processo di aggiornamento sono stati effettuati aggiornamenti del
Installare il repository OpenZFS con:
-```
+```bash
dnf install https://zfsonlinux.org/epel/zfs-release-2-2$(rpm --eval "%{dist}").noarch.rpm
```
@@ -41,19 +41,19 @@ dnf install https://zfsonlinux.org/epel/zfs-release-2-2$(rpm --eval "%{dist}").n
L'installazione di LXD richiede un pacchetto snap su Rocky Linux. Per questo motivo, è necessario installare `snapd` (e alcuni altri programmi utili) con:
-```
+```bash
dnf install snapd dkms vim kernel-devel
```
Ora abilitate e avviate snapd:
-```
+```bash
systemctl enable snapd
```
Quindi eseguire:
-```
+```bash
systemctl start snapd
```
@@ -63,13 +63,13 @@ Riavviare il server prima di continuare.
L'installazione di LXD richiede l'uso del comando snap. A questo punto, si sta solo installando, non si sta eseguendo la configurazione:
-```
+```bash
snap install lxd
```
## Installare OpenZFS
-```
+```bash
dnf install zfs
```
@@ -83,13 +83,13 @@ Fortunatamente, modificare le impostazioni di LXD non è difficile, basta modifi
Il primo file da modificare è il file `limits.conf.` Questo file è autodocumentato. Esaminate le spiegazioni nei commenti del file per capire cosa fa questo file. Per apportare le modifiche, inserire:
-```
+```bash
vi /etc/security/limits.conf
```
L'intero file è costituito da commenti e, in fondo, mostra le impostazioni predefinite correnti. Nello spazio vuoto sopra il marcatore di fine file (#End of file) è necessario aggiungere le nostre impostazioni personalizzate. Una volta completato, il file avrà il seguente aspetto:
-```
+```text
# Modifications made for LXD
* soft nofile 1048576
@@ -100,15 +100,15 @@ root hard nofile 1048576
* hard memlock unlimited
```
-Salvare le modifiche e uscire. (SHIFT+:+wq! per _vi_)
+Salva le tue modifiche ed esci (++shift+colon+"w"+"q"+exclam++ per *vi*).
### Modifica di sysctl.conf con `90-lxd.override.conf`
-Con _systemd_, è possibile apportare modifiche alla configurazione generale del sistema e alle opzioni del kernel *senza* modificare il file di configurazione principale. Le impostazioni vanno invece inserite in un file separato che sovrascrive le impostazioni specifiche necessarie.
+Con *systemd*, è possibile apportare modifiche alla configurazione generale del sistema e alle opzioni del kernel *senza* modificare il file di configurazione principale. Le impostazioni vanno invece inserite in un file separato che sovrascrive le impostazioni specifiche necessarie.
Per apportare queste modifiche al kernel, si deve creare un file chiamato `90-lxd-override.conf` in `/etc/sysctl.d`. Per farlo, digitare:
-```
+```bash
vi /etc/sysctl.d/90-lxd-override.conf
```
@@ -118,7 +118,7 @@ vi /etc/sysctl.d/90-lxd-override.conf
Inserite il seguente contenuto nel file. Se vi state chiedendo cosa state facendo, il contenuto del file è autodocumentante:
-```
+```bash
## The following changes have been made for LXD ##
# fs.inotify.max_queued_events specifies an upper limit on the number of events that can be queued to the corresponding inotify instance
@@ -176,19 +176,19 @@ Salvare le modifiche e uscire.
A questo punto riavviare il server.
-### Controllo dei valori di _sysctl.conf_
+### Controllo dei valori di *sysctl.conf*
Dopo il riavvio, accedere nuovamente al server come utente root. È necessario verificare che il nostro file di override abbia effettivamente completato il lavoro.
Non è difficile da fare. Non è necessario verificare tutte le impostazioni, a meno che non lo si voglia fare, ma controllarne alcune consente di verificare che le impostazioni siano state modificate. Per farlo, utilizzare il comando `sysctl`:
-```
+```bash
sysctl net.core.bpf_jit_limit
```
Che vi mostrerà:
-```
+```bash
net.core.bpf_jit_limit = 3000000000
```
diff --git a/docs/books/lxd_server/06-profiles.it.md b/docs/books/lxd_server/06-profiles.it.md
index c18f6e422f..bc6b42e50d 100644
--- a/docs/books/lxd_server/06-profiles.it.md
+++ b/docs/books/lxd_server/06-profiles.it.md
@@ -29,7 +29,7 @@ Per il momento, è bene sapere che questo comporta degli svantaggi quando si sce
Per creare il profilo macvlan, utilizzare questo comando:
-```
+```bash
lxc profile create macvlan
```
@@ -37,13 +37,13 @@ Se si dispone di una macchina con più interfacce e si desidera più di un model
Si vuole cambiare l'interfaccia macvlan, ma prima è necessario sapere qual è l'interfaccia principale del nostro server LXD. Si tratta dell'interfaccia che ha un IP assegnato alla LAN (in questo caso). Per individuare l'interfaccia, utilizzare:
-```
+```bash
ip addr
```
Cercare l'interfaccia con l'assegnazione IP LAN nella rete 192.168.1.0/24:
-```
+```bash
2: enp3s0: mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 40:16:7e:a9:94:85 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.106/24 brd 192.168.1.255 scope global dynamic noprefixroute enp3s0
@@ -56,7 +56,7 @@ In questo caso, l'interfaccia è "enp3s0".
Quindi cambiare il profilo:
-```
+```bash
lxc profile device add macvlan eth0 nic nictype=macvlan parent=enp3s0
```
@@ -64,14 +64,13 @@ Questo comando aggiunge al profilo macvlan tutti i parametri necessari per l'uso
Esaminare ciò che questo comando ha creato, utilizzando il comando:
-```
+```bash
lxc profile show macvlan
```
Il risultato sarà simile a questo:
-
-```
+```bash
config: {}
description: ""
devices:
@@ -87,13 +86,13 @@ used_by: []
Per assegnare il profilo macvlan a rockylinux-test-8 è necessario procedere come segue:
-```
+```bash
lxc profile assign rockylinux-test-8 default,macvlan
```
Fare la stessa cosa per rockylinux-test-9:
-```
+```bash
lxc profile assign rockylinux-test-9 default,macvlan
```
@@ -115,18 +114,18 @@ L'assegnazione del profilo, tuttavia, non modifica la configurazione predefinita
Per verificarlo, procedere come segue:
-```
+```bash
lxc restart rocky-test-8
lxc restart rocky-test-9
```
Elencare nuovamente i container e notare che rockylinux-test-9 non ha più un indirizzo IP:
-```
+```bash
lxc list
```
-```
+```bash
+-------------------+---------+----------------------+------+-----------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+-------------------+---------+----------------------+------+-----------+-----------+
@@ -136,19 +135,19 @@ lxc list
+-------------------+---------+----------------------+------+-----------+-----------+
| ubuntu-test | RUNNING | 10.146.84.181 (eth0) | | CONTAINER | 0 |
+-------------------+---------+----------------------+------+-----------+-----------+
-
```
+
Come si può vedere, il nostro contenitore Rocky Linux 8.x ha ricevuto l'indirizzo IP dall'interfaccia LAN, mentre il contenitore Rocky Linux 9.x no.
Per dimostrare ulteriormente il problema, è necessario eseguire `dhclient` sul contenitore Rocky Linux 9.0. Questo mostrerà che il profilo macvlan *è stato* effettivamente applicato:
-```
+```bash
lxc exec rockylinux-test-9 dhclient
```
Un altro elenco di container mostra ora quanto segue:
-```
+```bash
+-------------------+---------+----------------------+------+-----------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+-------------------+---------+----------------------+------+-----------+-----------+
@@ -162,51 +161,51 @@ Un altro elenco di container mostra ora quanto segue:
Ciò sarebbe dovuto accadere con l'arresto e l'avvio del contenitore, ma non è così. Supponendo di voler utilizzare sempre un indirizzo IP assegnato da DHCP, si può risolvere il problema con una semplice voce di crontab. Per farlo, è necessario ottenere l'accesso al container tramite shell, inserendo:
-```
+```bash
lxc exec rockylinux-test-9 bash
```
Quindi, determiniamo il percorso di `dhclient`. Per fare ciò, poiché questo container proviene da un'immagine minimale, è necessario prima installare `which`:
-```
+```bash
dnf install which
```
quindi eseguire:
-```
+```bash
which dhclient
```
che restituirà:
-```
+```bash
/usr/sbin/dhclient
```
Successivamente, modificare il crontab di root:
-```
+```bash
crontab -e
```
Aggiungere questa riga:
-```
+```bash
@reboot /usr/sbin/dhclient
```
-Il comando crontab inserito utilizza _vi_. Per salvare le modifiche e uscire, utilizzare SHIFT+:+wq.
+Il comando crontab inserito utilizza *vi*. Per salvare le modifiche e uscire, utilizzare ++shift+colon+"w"+"q"++.
Uscire dal container e riavviare rockylinux-test-9:
-```
+```bash
lxc restart rockylinux-test-9
```
Un altro elenco rivelerà che al contenitore è stato assegnato un indirizzo DHCP:
-```
+```bash
+-------------------+---------+----------------------+------+-----------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+-------------------+---------+----------------------+------+-----------+-----------+
@@ -225,19 +224,19 @@ Per assegnare staticamente un indirizzo IP, le cose si fanno ancora più complic
Per farlo, è necessario ottenere nuovamente l'accesso al contenitore:
-```
+```bash
lxc exec rockylinux-test-9 bash
```
Successivamente, si creerà uno script bash in `/usr/local/sbin` chiamato "static":
-```
+```bash
vi /usr/local/sbin/static
```
Il contenuto di questo script non è difficile:
-```
+```bash
#!/usr/bin/env bash
/usr/sbin/ip link set dev eth0 name net0
@@ -253,34 +252,33 @@ Cosa stiamo facendo qui?
* si apre la nuova interfaccia "net0"
* è necessario aggiungere la route predefinita per la nostra interfaccia
-
Rendere il nostro script eseguibile con:
-```
+```bash
chmod +x /usr/local/sbin/static
```
Aggiungerlo al crontab di root per il contenitore con il @reboot time:
-```
+```bash
@reboot /usr/local/sbin/static
```
Infine, uscire dal container e riavviarlo:
-```
+```bash
lxc restart rockylinux-test-9
```
Aspettate qualche secondo e elencate di nuovo i contenitori:
-```
+```bash
lxc list
```
Il successo dovrebbe essere visibile:
-```
+```bash
+-------------------+---------+----------------------+------+-----------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+-------------------+---------+----------------------+------+-----------+-----------+
@@ -298,19 +296,19 @@ Fortunatamente, nell'implementazione di Ubuntu di Network Manager, lo stack macv
Proprio come nel caso del contenitore rockylinux-test-9, è necessario assegnare il profilo al nostro contenitore:
-```
+```bash
lxc profile assign ubuntu-test default,macvlan
```
Per scoprire se il DHCP assegna un indirizzo al contenitore, interrompere e riavviare il contenitore:
-```
+```bash
lxc restart ubuntu-test
```
Elencare nuovamente i contenitori:
-```
+```bash
+-------------------+---------+----------------------+------+-----------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+-------------------+---------+----------------------+------+-----------+-----------+
@@ -326,13 +324,13 @@ Riuscito!
La configurazione dell'IP statico è leggermente diversa, ma non è affatto difficile. È necessario modificare il file .yaml associato alla connessione del contenitore`(10-lxc.yaml`). Per questo IP statico si utilizzerà 192.168.1.201:
-```
+```bash
vi /etc/netplan/10-lxc.yaml
```
Cambiare ciò che c'è con quanto segue:
-```
+```bash
network:
version: 2
ethernets:
@@ -348,13 +346,13 @@ Salvare le modifiche e uscire dal container.
Riavviare il container:
-```
+```bash
lxc restart ubuntu-test
```
Quando si elencano nuovamente i containeri, si vedrà il proprio IP statico:
-```
+```bash
+-------------------+---------+----------------------+------+-----------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+-------------------+---------+----------------------+------+-----------+-----------+
diff --git a/docs/books/lxd_server/07-configurations.it.md b/docs/books/lxd_server/07-configurations.it.md
index c8f06bcec9..222bdd2543 100644
--- a/docs/books/lxd_server/07-configurations.it.md
+++ b/docs/books/lxd_server/07-configurations.it.md
@@ -15,13 +15,13 @@ Nel corso di questo capitolo sarà necessario eseguire i comandi come utente non
Esistono numerose opzioni per configurare il container dopo l'installazione. Prima di vederli, però, esaminiamo il comando `info` per un container. In questo esempio, si utilizzerà il container ubuntu-test:
-```
+```bash
lxc info ubuntu-test
```
Verrà visualizzato quanto segue:
-```
+```bash
Name: ubuntu-test
Location: none
Remote: unix://
@@ -60,7 +60,7 @@ Resources:
Ci sono molte informazioni utili, dai profili applicati, alla memoria in uso, allo spazio su disco in uso e altro ancora.
-### Una parola sulla configurazione e su alcune opzioni
+## Una parola sulla configurazione e su alcune opzioni
Per impostazione predefinita, LXD assegna al container la memoria di sistema, lo spazio su disco, i core della CPU e altre risorse necessarie. Ma se si vuole essere più specifici? È assolutamente possibile.
@@ -70,29 +70,29 @@ Ricordate che ogni azione compiuta per configurare un contenitore _può_ avere e
Piuttosto che scorrere tutte le opzioni di configurazione, utilizzare il completamento automatico delle schede per visualizzare le opzioni disponibili:
-```
+```bash
lxc config set ubuntu-test
```
-e TAB.
+e ++tab++.
Mostra tutte le opzioni per la configurazione di un container. Se avete domande su cosa fa una delle opzioni di configurazione, visitate la [documentazione ufficiale di LXD](https://documentation.ubuntu.com/lxd/en/latest/config-options/) e fate una ricerca per il parametro di configurazione, oppure cercate su Google l'intera stringa, ad esempio `lxc config set limits.memory` ed esaminate i risultati della ricerca.
Di seguito esaminiamo alcune delle opzioni di configurazione più utilizzate. Ad esempio, se si vuole impostare la quantità massima di memoria che un container può utilizzare:
-```
+```bash
lxc config set ubuntu-test limits.memory 2GB
```
Questo dice che se la memoria è disponibile per l'uso, ad esempio se ci sono 2 GB di memoria disponibile, il container può effettivamente usare più di 2 GB se è disponibile. Si tratta di un limite morbido, ad esempio.
-```
+```bash
lxc config set ubuntu-test limits.memory.enforce 2GB
```
Ciò significa che il container non può mai utilizzare più di 2 GB di memoria, indipendentemente dal fatto che sia attualmente disponibile o meno. In questo caso si tratta di un limite rigido.
-```
+```bash
lxc config set ubuntu-test limits.cpu 2
```
@@ -104,14 +104,13 @@ Questo dice di limitare a 2 il numero di core della CPU che il container può ut
Ricordate quando avete impostato il nostro pool di archiviazione nel capitolo ZFS? Il pool è stato chiamato "storage", ma avrebbe potuto essere chiamato in qualsiasi modo. Se si desidera esaminarlo, si può usare questo comando, che funziona ugualmente bene anche per gli altri tipi di pool (come mostrato per dir):
-```
+```bash
lxc storage show storage
```
-
Questo mostra quanto segue:
-```
+```bash
config:
source: /var/snap/lxd/common/lxd/storage-pools/storage
description: ""
@@ -129,11 +128,10 @@ locations:
Questo mostra che tutti i container utilizzano il pool di archiviazione dir. Quando si usa ZFS, si può anche impostare una quota disco su un container. Ecco come appare il comando, che imposta una quota disco di 2 GB sul container ubuntu-test:
-```
+```bash
lxc config device override ubuntu-test root size=2GB
```
Come detto in precedenza, usare le opzioni di configurazione con parsimonia, a meno che non si abbia un container che vuole usare molto più della sua quota di risorse. LXD, nella maggior parte dei casi, gestisce l'ambiente in modo autonomo.
Esistono molte altre opzioni che potrebbero essere di interesse per alcuni. La ricerca personale vi aiuterà a scoprire se uno di questi elementi è utile nel vostro ambiente.
-