diff --git a/docs/books/admin_guide/08-process.zh.md b/docs/books/admin_guide/08-process.zh.md index d41f4d6203..a8bd1a1b6f 100644 --- a/docs/books/admin_guide/08-process.zh.md +++ b/docs/books/admin_guide/08-process.zh.md @@ -31,8 +31,8 @@ title: 进程管理 每个进程都有： -* *PID*：***P**rocess **ID**entifier*，唯一的进程标识符 -* *PPID*：***P**arent **P**rocess **ID**entifier*，父进程的唯一标识符 +* *PID*：_**P**rocess **ID**entifier_，唯一的进程标识符 +* *PPID*：_**P**arent **P**rocess **ID**entifier_，父进程的唯一标识符 通过连续的隶属关系，`init` 进程是所有进程之父。 @@ -41,13 +41,9 @@ title: 进程管理 进程之间存在父/子关系。 子进程是父进程调用 *fork()* 原语并复制自己的代码来创建子进程的结果。 子进程的 *PID* 会返回给父进程，以便父进程与之对话。 每个子进程都有父进程的标识符 *PPID* 。 -*PID* 数字代表执行时的进程。 当进程结束时，该数字可再次用于另一个进程。 多次运行同一命令将每次产生不同的 *PID*。 +*PID* 数字代表执行时的进程。 当进程结束时，该数字可再次用于另一个进程。 多次运行同一命令将每次产生不同的 *PID*。!!! note "说明" - - -!!! note "说明" - - 请不要将进程与 _线程_ 混淆。 每个进程都有自己的内存上下文（资源和地址空间），而来自同一进程的 _线程_ 则 共享相同的上下文。 + 请不要将进程与 _线程_ 混淆。 每个进程都有自己的内存上下文（资源和地址空间），而来自同一进程的 _线程_ 则共享相同的上下文。 ## 查看进程 diff --git a/docs/books/incus_server/09-snapshot_server.it.md b/docs/books/incus_server/09-snapshot_server.it.md new file mode 100644 index 0000000000..0b5d581d28 --- /dev/null +++ b/docs/books/incus_server/09-snapshot_server.it.md @@ -0,0 +1,165 @@ +--- +title: 9 Server Snapshot +author: Spencer Steven +contributors: Ezequiel Bruni, Ganna Zhyrnova +tested_with: 9.4 +tags: + - incus + - enterprise + - incus snapshot server +--- + +In questo capitolo si utilizzeranno una combinazione di utenti privilegiati (root) e non privilegiati (incusadmin) in base alle attività che si eseguiranno. + +Come indicato all'inizio, il server snapshot di Incus deve essere un mirror in tutto e per tutto al server di produzione. Potrebbe essere necessario metterlo in produzione se l'hardware del server principale si guastasse, infatti disporre di un backup e di un modo rapido per riavviare i container di produzione consente di ridurre al minimo le telefonate e gli SMS di panico degli amministratori di sistema. E questo è SEMPRE un bene! + +Il processo di creazione del server snapshot è esattamente come quello del server di produzione. Per emulare pienamente la configurazione del server di produzione, si ripetano i capitoli 1-4 sul server snapshot e, una volta completati, tornare a questo punto. + +Se si è arrivati fino a qui, è stata completata l'installazione di base del server snapshot. + +## Impostazione del rapporto tra server primario e snapshot + +È necessario fare un po' d'ordine prima di proseguire. Innanzitutto, se si opera in un ambiente di produzione, probabilmente si ha accesso a un server DNS per impostare la risoluzione dei nomi ed IP. + +Nel vostro ambiente di prova non si ha questo lusso. Forse anche voi avete lo stesso scenario. Per questo motivo, si aggiungeranno gli indirizzi IP e i nomi dei server nel file \`/etc/hosts' sul server primario e sul server snapshot. È necessario eseguire questa operazione come utente root (o _sudo_). + +Nell'ambiente di prova, il server primario di Incus è in esecuzione su 192.168.1.106 e il server snapshot di Incus è in esecuzione su 192.168.1.141. Accedere a ciascun server tramite SSH e aggiungere quanto segue al file `/etc/hosts`: + +```bash +192.168.1.106 incus-primary +192.168.1.141 incus-snapshot +``` + +Successivamente, è necessario consentire tutto il traffico tra i due server. Per farlo, si modificheranno le regole di `firewalld`. Per prima cosa, sul server incus-primario, si aggiunga questa riga: + +```bash +firewall-cmd zone=trusted add-source=192.168.1.141 --permanent +``` + +E sul server snapshot, aggiungere questa regola: + +```bash +firewall-cmd zone=trusted add-source=192.168.1.106 --permanent +``` + +Quindi ricaricare: + +```bash +firewall-cmd reload +``` + +Successivamente, come utente non privilegiato (incusadmin), è necessario stabilire una relazione di trusting tra le due macchine. Questo si ottiene eseguendo su incus-primary quanto segue: + +```bash +incus remote add incus-snapshot +``` + +Visualizza il certificato da accettare. Accettate e vi verrà richiesta la password. Si tratta della “trust password” impostata durante la fase di inizializzazione di Incus. Spero che stiate tenendo traccia di tutte queste password. Quando si inserisce la password, si riceve questo messaggio: + +```bash +Client certificate stored at server: incus-snapshot +``` + +Si può fare anche al contrario. Ad esempio, la trust relation può essere impostata anche sul server incus-snapshot. Se richiesto, il server incus-snapshot può inviare gli snapshots al server incus-primario. Ripetete i passaggi e sostituite “incus-primary” con “incus-snapshot” + +### Migrazione del primo snapshot + +Prima di migrare la prima snapshot, è necessario ricreare tutti i profili sull'incus-snapshot creati sull'incus-primario. In questo caso specifico, si tratta del profilo “macvlan”. + +È necessario crearlo per incus-snapshot. Tornare al [Capitolo 6](06-profiles.md) e creare il profilo “macvlan” su incus-snapshot, se necessario. Se i due server hanno gli stessi nomi di interfaccia madre (“enp3s0”, ad esempio), è possibile copiare il profilo “macvlan” su incus-snapshot senza ricrearlo: + +```bash +incus profile copy macvlan incus-snapshot +``` + +Avendo tutte le relazioni e i profili impostati, il prossimo passo è quello di inviare uno snapshot dal incus-primario al incus-snapshot. Se si è seguito esattamente questa procedura, probabilmente si avrà cancellato tutti gli snapshot. Creare un'altro snapshot: + +```bash +incus snapshot rockylinux-test-9 rockylinux-test-9-snap1 +``` + +Se si esegue il comando “info” per `incus`, si può vedere lo snapshot in fondo all'elenco: + +```bash +incus info rockylinux-test-9 +``` + +Che mostrerà qualcosa di simile in basso: + +```bash +rockylinux-test-9-snap1 at 2021/05/13 16:34 UTC) (stateless) +``` + +Provare a migrare lo snapshot: + +```bash +incus copy rockylinux-test-9/rockylinux-test-9-snap1 incus-snapshot:rockylinux-test-9 +``` + +Questo comando dice che all'interno del container rockylinux-test-9, si vuole inviare lo snapshot rockylinux-test-9-snap1 a incus-snapshot e nominarlo rockylinux-test-9. + +Dopo poco tempo, la copia sarà completa. Volete scoprirlo con certezza? Eseguire `incus list` sul server incus-snapshot. Che dovrebbe restituire quanto segue: + +```bash ++-------------------+---------+------+------+-----------+-----------+ +| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | ++-------------------+---------+------+------+-----------+-----------+ +| rockylinux-test-9 | STOPPED | | | CONTAINER | 0 | ++-------------------+---------+------+------+-----------+-----------+ +``` + +Successo! Provate ad avviarlo. Poiché si avvia sul server incus-snapshot, è necessario arrestarlo prima sul server incus-primary per evitare un conflitto di indirizzi IP: + +```bash +incus stop rockylinux-test-9 +``` + +E sul server incus-snapshot: + +```bash +incus start rockylinux-test-9 +``` + +Supponendo che tutto questo funzioni senza errori, arrestare il container su incus-snapshot e riavviarlo su incus-primary. + +## Impostazione di `boot.autostart` su off per i containers + +Gli snapshot copiati su incus-snapshot saranno disattivati durante la migrazione, ma se si verifica una anomalia nell'alimentazione del server o è necessario riavviare il server di snapshot a causa di aggiornamenti o altro, si verificherà un problema. Questi container cercheranno di avviarsi sul server snapshot, creando un potenziale conflitto di indirizzi IP. + +Allo scopo di evitare questo problema, è necessario impostare i container migrati in modo che non vengano avviati al riavvio del server. Per il container rockylinux-test-9 appena copiato, si procederà come segue: + +```bash +incus config set rockylinux-test-9 boot.autostart 0 +``` + +Eseguire questa operazione per ogni snapshot sul server incus-snapshot. Lo "0" nella riga di comando imposta `boot.autostart` in off. + +## Automatizzazione del processo di snapshot + +È importante avere la possibilità di creare snapshot quando necessario, ma a volte è necessario creare un snapshot manualmente. Si potrebbe anche copiare manualmente su incus-snapshot. Ma per tutte le altre volte, in particolare per molti container in esecuzione sul server incus-primary, l'ultima cosa da fare è passare un pomeriggio a cancellare le istantanee sul server snapshot, creare nuove istantanee e inviarle al server snapshot. Per la maggior parte delle operazioni, è preferibile automatizzare il processo. + +È necessario pianificare un processo per automatizzare la creazione di snapshot su incus-primary. Questa operazione viene eseguita per ogni container sul server incus-primary. Una volta completata, si occuperà di questo aspetto in futuro. Per farlo, si utilizza la seguente sintassi. Si noti la somiglianza con una voce di crontab per il timestamp: + +```bash +incus config set [container_name] snapshots.schedule "50 20 * * *" +``` + +Questo significa: eseguire un snapshot del container_name ogni giorno alle 20.50. + +Per applicare questo al container rockylinux-test-9: + +```bash +incus config set rockylinux-test-9 snapshots.schedule "50 20 * * *" +``` + +È inoltre necessario impostare il nome del snapshot in modo che sia significativo per la sua data. Incus utilizza ovunque UTC, quindi la cosa migliore per tenere traccia delle cose è impostare il nome del snapshot con una data e un'ora in un formato più comprensibile: + +```bash +incus config set rockylinux-test-9 snapshots.pattern "rockylinux-test-9{{ creation_date|date:'2006-01-02_15-04-05' }}" +``` + +OTTIMO, ma di certo non volete un nuovo snapshot ogni giorno senza sbarazzarvi di quello vecchio. L'unità si riempirebbe di istantanee. Per risolvere questa cosa, eseguire il seguente comando: + +```bash +incus config set rockylinux-test-9 snapshots.expiry 1d +``` diff --git a/docs/books/incus_server/10-automating.it.md b/docs/books/incus_server/10-automating.it.md new file mode 100644 index 0000000000..44a7544503 --- /dev/null +++ b/docs/books/incus_server/10-automating.it.md @@ -0,0 +1,70 @@ +--- +title: 10 Automatizzare +author: Spencer Steven +contributors: Ezequiel Bruni, Ganna Zhyrnova +tested_with: 9.4 +tags: + - incus + - enterprise + - incus automation +--- + +Nel corso di questo capitolo, è necessario essere l'utente root o essere in grado di eseguire con i privilegi di root con sudo. + +L'automazione del processo di snapshot rende le cose molto più facili. + +## Automatizzazione del Processo di Copia di Istantanee + +Eseguire questa procedura su incus-primary. La prima cosa da fare è creare uno script che verrà eseguito da cron in /usr/local/sbin chiamato "refresh-containers" : + +```bash +sudo vi /usr/local/sbin/refreshcontainers.sh +``` + +Lo script è piuttosto semplice: + +```bash +#!/bin/bash +# This script is for doing an lxc copy --refresh against each container, copying +# and updating them to the snapshot server. + +for x in $(/var/lib/snapd/snap/bin/lxc ls -c n --format csv) + do echo "Refreshing $x" + /var/lib/snapd/snap/bin/lxc copy --refresh $x incus-snapshot:$x + done + +``` + +E poi renderlo eseguibile: + +```bash +sudo chmod +x /usr/local/sbin/refreshcontainers.sh +``` + +Cambiare la ownership di questo script all'utente e al gruppo incusadmin: + +```bash +sudo chown incusadmin.incusadmin /usr/local/sbin/refreshcontainers.sh +``` + +Impostare il crontab per l'utente incusadmin per l'esecuzione di questo script, in questo caso alle 10 di sera: + +```bash +crontab -e +``` + +La voce avrà il seguente aspetto: + +```bash +00 22 * * * /usr/local/sbin/refreshcontainers.sh > /home/incusadmin/refreshlog 2>&1 +``` + +Salvare le modifiche e uscire. + +Questo creerà un log, nella home directory di incusadmin, chiamato “refreshlog”, che permetterà di sapere se il processo ha funzionato o meno. Molto importante! + +La procedura automatica a volte fallisce. Questo accade generalmente quando un particolare container non riesce ad aggiornarsi. È possibile eseguire manualmente l'aggiornamento con il seguente comando (assumendo rockylinux-test-9 qui, come nostro contenitore): + +```bash +lxc copy --refresh rockylinux-test-9 incus-snapshot:rockylinux-test-9 +``` diff --git a/docs/books/incus_server/30-appendix_a.it.md b/docs/books/incus_server/30-appendix_a.it.md new file mode 100644 index 0000000000..0fdd3fad0a --- /dev/null +++ b/docs/books/incus_server/30-appendix_a.it.md @@ -0,0 +1,184 @@ +--- +title: Appendice A - Configurazione Workstation +author: Spencer Steven +contributors: Ganna Zhyrnova +tested_with: 9.4 +tags: + - incus + - workstation +--- + +# Appendice A - Configurazione Workstation + +Anche se non fa parte dei capitoli per un server Incus, questa procedura aiuterà coloro che desiderano avere un ambiente di prova o un sistema operativo e un'applicazione semi-permanente in esecuzione su una workstation o un laptop Rocky Linux. + +## Prerequisiti + +- a proprio agio alla riga di comando +- essere in grado di utilizzare fluentemente un editor a riga di comando, come `vi` o \`nano +- necessità di un ambiente di test stabile da utilizzare quotidianamente o secondo necessità +- essere in grado di accedere come root o di avere privilegi `sudo` + +## Installazione + +Dalla riga di comando, installare il repository EPEL: + +```bash +sudo dnf install epel-release -y +``` + +Al termine dell'installazione, eseguire un aggiornamento: + +```bash +sudo dnf upgrade +``` + +Installare le altre repositories: + +```bash +sudo dnf config-manager --enable crb +sudo dnf copr enable neil/incus +``` + +Installare pacchetti necessari: + +```bash +sudo dnf install dkms vim kernel-devel bash-completion +``` + +Installare e abilitare Incus: + +```bash +sudo dnf install incus incus-tools +sudo systemctl enable incus +``` + +Riavviare il notebook o la workstation prima di continuare. + +## Inizializzazione di Incus + +Se avete letto i capitoli sul server di produzione, questa procedura è quasi identica a quella di inizializzazione del server di produzione. + +```bash +sudo incus admin init +``` + +Si aprirà una finestra di dialogo a domande e risposte. + +Ecco le domande e le nostre risposte per lo script, con una piccola spiegazione dove necessario: + +```text +Would you like to use clustering? (yes/no) [default=no]: no +Do you want to configure a new storage pool? (yes/no) [default=yes]: yes +Name of the new storage pool [default=default]: storage +``` + +Facoltativamente, è possibile accettare l'impostazione predefinita. + +```text +Name of the storage backend to use (btrfs, dir, lvm, ceph) [default=btrfs]: dir +``` + +Si noti che `dir` è un po' più lento di `zfs`. Se si può lasciare un disco vuoto, si può usare quel dispositivo (ad esempio: /dev/sdb) per il dispositivo `zfs` e poi selezionare `zfs`. + +```text +Would you like to connect to a MAAS server? (yes/no) [default=no]: +``` + +Il Metal As A Service (MAAS) non rientra nell'ambito di questo documento. + +```text +Would you like to create a new local network bridge? (yes/no) [default=yes]: +What should the new bridge be called? [default=incusbr0]: +What IPv4 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]: +What IPv6 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]: none +``` + +È possibile attivare questa opzione se si desidera utilizzare IPv6 sui propri container Incus. + +```text +Would you like the Incus server to be available over the network? (yes/no) [default=no]: yes +``` + +Questa operazione è necessaria per eseguire lo snapshot della workstation. Rispondere "sì" in questo caso. + +```text +Address to bind Incus to (not including port) [default=all]: +Port to bind Incus to [default=8443]: +Trust password for new clients: +Again: +``` + +Questa trust password è il modo in cui ci si connette o si torna indietro dal server snapshot. Impostatela con qualcosa che abbia senso nel vostro ambiente. Salvare questa voce in un luogo sicuro, ad esempio in un gestore di password. + +```text +Would you like stale cached images to be updated automatically? (yes/no) [default=yes] +Would you like a YAML "incus admin init" preseed to be printed? (yes/no) [default=no]: +``` + +## Privilegi dell'utente + +La prossima cosa da fare è aggiungere il proprio utente al gruppo `incus-admin`. Anche in questo caso, è necessario utilizzare `sudo` o essere root: + +```text +sudo usermod -a -G incus-admin [username] +``` + +Dove [username] è l'utente del sistema. + +## Impostazione dei valori `subuid` e `subgid` per `root` + +È necessario impostare sia il valore del `subuid` che del `subgid` dell'utente root (l'intervallo di ID degli utenti e dei gruppi subordinati). I parametri dovrebbero essere: + +```bash +root:1000000:1000000000 +``` + +Per farlo, modificare `/etc/subuid` e aggiungere questa riga. Quando completo, il file dovrebbe essere: + +```bash +root:1000000:1000000000 +``` + +Aggiungere nuovamente questa riga al file `/etc/subgid`. Il file avrà un aspetto simile a questo: + +```bash +incusadmin:100000:65536 +root:1000000:1000000000 +``` + +A questo punto saranno state apportate una serie di modifiche. Quindi prima di procedere oltre, riavviare il computer. + +## Verifica dell'installazione + +Per assicurarsi che `incus` sia stato avviato e che il vostro utente abbia i privilegi, dal prompt della shell eseguire: + +```text +incus list +``` + +Si noti che qui non è stato usato `sudo`. L'utente può inserire questi comandi. Vedrete qualcosa di simile a questo: + +```bash ++------------+---------+----------------------+------+-----------+-----------+ +| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | ++------------+---------+----------------------+------+-----------+-----------+ +``` + +Se lo fate, avete un bell'aspetto! + +## Il resto + +A questo punto, è possibile utilizzare i capitoli del nostro “Incus Production Server” per continuare. Ci sono alcuni aspetti della configurazione di una workstation a cui è necessario prestare meno attenzione. Ecco i capitoli consigliati per iniziare: + +- [Capitolo 5 - Impostazione e gestione delle immagini](05-incus_images.md) +- [Capitolo 6 - Profili](06-profiles.md) +- [Capitolo 8 - Container Snapshots](08-snapshots.md) + +## Ulteriori informazioni + +- [Panoramica e documentazione ufficiale di Incus](https://linuxcontainers.org/incus/docs/main/) + +## Conclusione + +Incus è un potente strumento per aumentare la produttività di workstation e server. È ottimo per i test di prova su una workstation e può anche mantenere istanze semi-permanenti di sistemi operativi e applicazioni disponibili nel loro spazio privato. diff --git a/docs/books/learning_ansible/09-working-with-jinja-template.it.md b/docs/books/learning_ansible/09-working-with-jinja-template.it.md index 6655fc5335..67d5706b41 100644 --- a/docs/books/learning_ansible/09-working-with-jinja-template.it.md +++ b/docs/books/learning_ansible/09-working-with-jinja-template.it.md @@ -1,21 +1,19 @@ --- -title: Lavorare con i Modelli Jinja +title: Lavorare con i modelli Jinja in Ansible author: Srinivas Nishant Viswanadha contributors: Steven Spencer, Antoine Le Morvan, Ganna Zhyrnova --- -# Capitolo: Lavorare con i modelli Jinja in Ansible - ## Introduzione -Ansible fornisce un modo potente e semplice per gestire le configurazioni utilizzando i modelli Jinja attraverso il modulo integrato `template`. Questo capitolo esplora due modi essenziali per utilizzare i modelli Jinja in Ansible: +Ansible fornisce un modo potente e semplice per gestire le configurazioni utilizzando i modelli Jinja attraverso il modulo integrato `template`. Questo documento esplora due modi essenziali per utilizzare i modelli Jinja in Ansible: - aggiungere variabili a un file di configurazione - costruire file complessi con loop e strutture di dati intricate. ## Aggiunta di variabili a un file di configurazione -### Passo 1: creare un modello Jinja +### Step 1: Creare un template Jinja Creare un file modello Jinja, ad esempio `sshd_config.j2`, con segnaposti per le variabili: @@ -27,7 +25,7 @@ PermitRootLogin {{ permit_root_login }} # Add more variables as needed ``` -### Passo 2: utilizzare il modulo template di Ansible +### Step 2: Utilizzare il modulo template di Ansible Nel playbook di Ansible, utilizzare il modulo `template` per rendere il template Jinja con valori specifici: @@ -46,7 +44,7 @@ Nel playbook di Ansible, utilizzare il modulo `template` per rendere il template # Add more variables as needed ``` -### Passo 3: applicare le modifiche alla configurazione +### Step 3: Applicare la modifica della configurazione Eseguire il playbook Ansible per applicare le modifiche agli host di destinazione: @@ -58,9 +56,9 @@ Questa fase garantisce che le modifiche alla configurazione siano applicate in m ## Costruire un file completo con loop e strutture dati complesse -### Passo 1: migliorare un modello Jinja +### Step 1: Migliorare il template Jinja -Estendere il modello Jinja per gestire loop e strutture di dati complesse. Ecco un esempio di configurazione di un'ipotetica applicazione con più componenti: +Estendere il modello Jinja per gestire loop e strutture di dati complesse. Ecco un esempio di configurazione di un'ipotetica applicazione con diversi componenti: ```jinja # /path/to/app_config.j2 @@ -73,7 +71,7 @@ Estendere il modello Jinja per gestire loop e strutture di dati complesse. Ecco {% endfor %} ``` -### Passaggio 2: integrare il modulo template Ansible +### Step 2: Integrazione del modulo template di Ansible Nel playbook di Ansible, integrare il modulo `template` per generare un file di configurazione completo: @@ -105,7 +103,7 @@ ansible-playbook your_playbook.yml Questa fase garantisce che le modifiche alla configurazione siano applicate in modo coerente a tutta l'infrastruttura. -Il modulo `template` di Ansible può utilizzare i template Jinja per generare dinamicamente file di configurazione durante l'esecuzione del playbook. Questo modulo consente di separare la logica di configurazione e dati, rendendo i playbook Ansible più flessibili e facili da gestire. +Il modulo `template` di Ansible consente di utilizzare i modelli Jinja per generare dinamicamente i file di configurazione durante l'esecuzione del playbook. Questo modulo consente di separare la logica di configurazione dai dati, rendendo i playbook di Ansible più flessibili e mantenibili. ### Caratteristiche principali @@ -123,7 +121,7 @@ Il modulo `template` di Ansible può utilizzare i template Jinja per generare di - Le variabili possono essere passate direttamente nel playbook o caricate da file esterni, consentendo la generazione di configurazioni flessibili e dinamiche. 5. **Esecuzione idempotente:** - - Il modulo template supporta l'esecuzione idempotente, garantendo che il template venga applicato solo se vengono rilevate modifiche. + - Il modulo dei template supporta l'esecuzione idempotente, assicurando che il template venga applicato solo se vengono rilevate delle modifiche. ### Esempio di un playbook diff --git a/docs/guides/desktop/kde_installation.it.md b/docs/guides/desktop/kde_installation.it.md index ded3d3c6ec..3afd5c5b83 100644 --- a/docs/guides/desktop/kde_installation.it.md +++ b/docs/guides/desktop/kde_installation.it.md @@ -25,7 +25,7 @@ Grazie al team di sviluppo di Rocky Linux, sono disponibili immagini live per di ## Ottenere, verificare e scrivere l'immagine live di KDE -Prima dell'installazione, il primo passo è scaricare l'immagine live e scriverla su un DVD o una chiavetta USB. Come detto in precedenza, l'immagine sarà avviabile, proprio come qualsiasi altro supporto di installazione per Linux. È possibile trovare l'ultima immagine di KDE nella sezione download di Rocky Linux 9 [immagini live](https://dl.rockylinux.org/pub/rocky/9.4/live/x86_64/). +Prima dell'installazione, il primo passo è scaricare l'immagine live e scriverla su un DVD o una chiavetta USB. Come detto in precedenza, l'immagine sarà avviabile, proprio come qualsiasi altro supporto di installazione per Linux. È possibile trovare l'ultima immagine di KDE nella sezione download di Rocky Linux 9 [immagini live](https://dl.rockylinux.org/pub/rocky/9.5/live/x86_64/). Si noti che questo particolare collegamento presuppone x86_64 come architettura del processore. Se si dispone di un'architettura aarch64, è possibile utilizzare questa immagine. Scaricare l'immagine live e i file di checksum. diff --git a/docs/guides/desktop/mate_installation.it.md b/docs/guides/desktop/mate_installation.it.md index 4999095c37..a2c09aa59a 100644 --- a/docs/guides/desktop/mate_installation.it.md +++ b/docs/guides/desktop/mate_installation.it.md @@ -29,20 +29,20 @@ Questa procedura vi permetterà di utilizzare MATE su Rocky Linux. ### 9: Ottenere, verificare e scrivere l'immagine live di MATE - Prima dell'installazione, il primo passo è scaricare l'immagine live e scriverla su un DVD o una chiavetta USB. Come detto in precedenza, l'immagine sarà avviabile, proprio come qualsiasi altro supporto di installazione per Linux. È possibile trovare l'ultima immagine MATE nella sezione download di Rocky Linux 9 [immagini live](https://dl.rockylinux.org/pub/rocky/9.4/live/x86_64/). Si noti che questo particolare collegamento presuppone che l'architettura sia x86_64 e, al momento in cui scriviamo, questa è l'unica immagine live disponibile. Scaricare sia l'immagine live che i file di checksum. + Prima dell'installazione, il primo passo è scaricare l'immagine live e scriverla su un DVD o una chiavetta USB. Come detto in precedenza, l'immagine sarà avviabile, proprio come qualsiasi altro supporto di installazione per Linux. È possibile trovare l'ultima immagine MATE nella sezione download di Rocky Linux 9 [immagini live](https://dl.rockylinux.org/pub/rocky/9.5/live/x86_64/). Si noti che questo particolare collegamento presuppone che l'architettura sia x86_64 e, al momento in cui scriviamo, questa è l'unica immagine live disponibile. Scaricare sia l'immagine live che i file di checksum. Verificare l'immagine con il file CHECKSUM nel modo seguente (si noti che questo è un esempio! Assicurarsi che il nome dell'immagine e i file CHECKSUM corrispondano): ``` - sha256sum -c CHECKSUM --ignore-missing Rocky-9.4-MATE-x86_64-20221124.0.iso.CHECKSUM + sha256sum -c CHECKSUM --ignore-missing Rocky-9.5-MATE-x86_64-20221124.0.iso.CHECKSUM ``` Se tutto va bene, riceverete questo messaggio: ``` - Rocky-9.4-MATE-x86_64-20221124.0.iso: OK + Rocky-9.5-MATE-x86_64-20221124.0.iso: OK ``` diff --git a/docs/guides/desktop/xfce_installation.it.md b/docs/guides/desktop/xfce_installation.it.md index d1710fbeb9..727c9e1f33 100644 --- a/docs/guides/desktop/xfce_installation.it.md +++ b/docs/guides/desktop/xfce_installation.it.md @@ -1,5 +1,5 @@ - - - -title: XFCE Desktop author: Gerard Arthus, Steven Spencer, Emre Camalan contributors: Steven Spencer, Antoine Le Morvan, K.Prasad, Ganna Zhyrnova tested_with: 8.9, 9.3 tags: +title: XFCE Desktop author: Gerard Arthus, Steven Spencer, Emre Camalan contributors: Steven Spencer, Antoine Le Morvan, K.Prasad, Ganna Zhyrnova tested_with: 8.9, 9.5 tags: - xfce - desktop - - - @@ -24,7 +24,7 @@ L'ambiente desktop XFCE, creato come fork del Common Desktop Environment (CDE), ## 9: Ottenere, verificare e scrivere l'immagine live di XFCE - Prima dell'installazione, il primo passo è scaricare l'immagine live e scriverla su un DVD o una chiavetta USB. Come detto in precedenza, l'immagine sarà avviabile, proprio come qualsiasi altro supporto di installazione per Linux. È possibile trovare l'ultima immagine di XFCE nella sezione download di Rocky Linux 9 [immagini live](https://dl.rockylinux.org/pub/rocky/9.4/live/x86_64/). Si noti che questo particolare collegamento presuppone che x86_64 sia l'architettura del vostro processore. + Prima dell'installazione, il primo passo è scaricare l'immagine live e scriverla su un DVD o una chiavetta USB. Come detto in precedenza, l'immagine sarà avviabile, proprio come qualsiasi altro supporto di installazione per Linux. È possibile trovare l'ultima immagine di XFCE nella sezione download di Rocky Linux 9 [immagini live](https://dl.rockylinux.org/pub/rocky/9.5/live/x86_64/). Si noti che questo particolare collegamento presuppone che x86_64 sia l'architettura del vostro processore. Al momento è possibile utilizzare architetture x86_64 o aarch64 per questa immagine live. Scaricare l'immagine live e i file di checksum. diff --git a/docs/guides/virtualization/cockpit-machines.fr.md b/docs/guides/virtualization/cockpit-machines.fr.md new file mode 100644 index 0000000000..6525f82766 --- /dev/null +++ b/docs/guides/virtualization/cockpit-machines.fr.md @@ -0,0 +1,96 @@ +--- +title: Cockpit KVM Dashboard +author: Neel Chauhan +contributors: Ganna Zhrynova +tested on: 9.3 +tags: + - virtualisation +--- + +# Cockpit KVM – Tableau de Bord + +## Introduction + +Cockpit est un outil d'administration qui fournit un tableau de bord facile à utiliser pour gérer votre serveur. L'une des fonctionnalités de Cockpit est qu'avec un package, il peut gérer les machines virtuelles KVM à partir d'une interface Web similaire à VMware ESXi ou Proxmox. + +## Prérequis + +- Un serveur Rocky Linux avec virtualisation matérielle activée +- Accès aux dépôts Rocky Linux `dnf` + +## Installation de Cockpit + +Cockpit est fourni par défaut dans Rocky Linux. Cependant, la prise en charge de KVM n'est pas installée prête à l'emploi. Nous allons l'installer via `dnf` : + +```bash +dnf install -y cockpit-machines +``` + +Installez également `libvirtd` : + +```bash +dnf install -y libvirt +``` + +## Activation de `cockpit` + +Pour activer à la fois la virtualisation KVM et Cockpit, activez les services `systemd` correspondants : + +```bash +systemctl enable --now libvirtd cockpit.socket +``` + +Après avoir activé `cockpit`, ouvrez un navigateur sur **http://ip_address:9090** (remarque : remplacez **ip_address** par l'adresse IP de votre serveur) : + +![Cockpit login screen](../images/cockpit_login.png) + +Connectez-vous en tant qu'utilisateur non root et vous devriez voir un dashboard similaire à celui présenté ici : + +![Cockpit dashboard](../images/cockpit_dashboard.png) + +## Création de machine virtuelle + +Dans ce guide, vous allez créer une machine virtuelle Rocky Linux 9 sur votre système hôte, en utilisant l'automatisation pour ajouter un nom d'utilisateur et un mot de passe root. + +Pour créer une machine virtuelle dans Cockpit, cliquez d'abord sur le bouton bleu **Activer l'accès administrateur** et entrez votre mot de passe si nécessaire : + +![Cockpit dashboard as root](../images/cockpit_root_dashboard.png) + +Vous êtes maintenant connecté en tant que `root` dans Cockpit. Dans la barre latérale, cliquez sur **Machines virtuelles** : + +![Cockpit Virtual Machine dashboard](../images/cockpit_vm_dashboard.png) + +Cliquez ensuite sur **Create VM** : + +![Virtual Machine create dialog](../images/cockpit_vm_create_1.png) + +Dans le menu déroulant **Operating System**, sélectionnez **Rocky Linux 9 (Blue Onyx)** : + +![VM create dialog with Rocky Linux 9 selected](../images/cockpit_vm_create_2.png) + +Ensuite, cliquez sur **Automation** et renseignez les informations de connexion que vous souhaitez sur votre nouvelle VM : + +![VM create dialog with root password and username filed in](../images/cockpit_vm_create_2.png) + +Enfin, sélectionnez **Create and run**. + +Dans quelques minutes, sélectionnez votre VM nouvellement créée et vous obtiendrez son adresse IP : + +![Our VM's IP address](../images/cockpit_vm_ip.png) + +Connectez-vous en SSH à votre hyperviseur et connectez-vous avec SSH à l'adresse IP de Cockpit. Dans cet exemple, il s'agit de **172.20.0.103**. Vous serez connecté à votre nouveau serveur : + +![Our VM's terminal](../images/cockpit_vm_terminal.png) + +## Limitations + +Bien que Cockpit soit idéal pour créer et gérer des machines virtuelles, il y a quelques limitations à prendre en compte : + +- Vous ne pouvez pas créer une interface bridge. +- Vous ne pouvez pas créer une nouvelle image dans un pool de stockage, uniquement celui « par défaut ». + +Heureusement, vous pouvez les créer en ligne de commande, puis Cockpit peut les utiliser. + +## Conclusion + +Cockpit est un outil précieux pour gérer un serveur Rocky Linux via une interface Web. C'est, du point de vue de l'auteur, l'outil de référence pour créer des machines virtuelles dans son laboratoire personnel. Même si les « machines cockpit » ne sont peut-être pas aussi complètes que sous ESXi ou Proxmox, elles font le travail dans 90 % des cas d'utilisation d'hyperviseur. diff --git a/docs/guides/virtualization/libvirt-rocky.fr.md b/docs/guides/virtualization/libvirt-rocky.fr.md new file mode 100644 index 0000000000..271a0bb3b8 --- /dev/null +++ b/docs/guides/virtualization/libvirt-rocky.fr.md @@ -0,0 +1,173 @@ +--- +title: libvirt et Rocky Linux +author: Howard Van Der Wal +contributors: Steven Spencer +tested with: 9.5 +tags: + - libvirt + - kvm + - virtualisation +--- + +## Introduction + +[libvirt](https://libvirt.org/) est une API qui permet la virtualisation de presque tous les systèmes d'exploitation de votre choix avec la puissance de KVM comme hyperviseur et de QEMU comme émulateur. + +Ce document fournit les instructions de configuration de `libvirt` sur Rocky Linux 9. + +## Prérequis + +- Une machine 64bit fonctionnant sous Rocky Linux 9. +- Assurez-vous de l'activation de la virtualisation dans les paramètres de votre BIOS. Si la commande suivante renvoie un résultat, cela signifie que l'activation de la virtualisation est terminée : + +```bash +sudo grep -e 'vmx' /proc/cpuinfo +``` + +## Mise en place du référentiel et installation des packages + +- Activez le dépôt EPEL (Extra Packages for Enterprise Linux) : + +```bash +sudo dnf install -y epel-release +``` + +- Installez les packages requis pour `libvirt` (en option pour `virt-manager` si vous souhaitez utiliser une interface graphique pour gérer vos machines virtuelles) : + +```bash +sudo dnf install -y bridge-utils virt-top libguestfs-tools bridge-utils virt-viewer qemu-kvm libvirt virt-manager virt-install +``` + +## Configuration de l'utilisateur `libvirt` + +- Ajoutez votre utilisateur au groupe `libvirt`. Cela permet de gérer vos VM et d'utiliser des commandes telles que `virt-install` en tant qu'utilisateur non root : + +```bash +sudo usermod -aG libvirt $USER +``` + +- Activez le groupe `libvirt` en utilisant la commande `newgrp` : + +```bash +sudo newgrp libvirt +``` + +- Activez et démarrez le service `libvirtd` : + +```bash +sudo systemctl enable --now libvirtd +``` + +## Configuration de l'interface `Bridge` pour un accès direct aux machines virtuelles + +- Vérifiez les interfaces actuellement utilisées et notez l'interface principale avec une connexion Internet : + +```bash +sudo nmcli connection show +``` + +- Supprimez l'interface connectée à Internet et toutes les connexions de pont virtuel actuellement présentes : + +```bash +sudo nmcli connection delete +``` + +!!! warning "Avertissement" + +``` +Assurez-vous d'avoir un accès direct à la machine. Si vous configurez la machine via SSH, la connexion sera interrompue après la suppression de la connexion à l'interface principale. +``` + +- Créer la nouvelle connexion de pont : + +```bash +sudo nmcli connection add type bridge autoconnect yes con-name ifname +``` + +- Attribuez une adresse IP statique : + +```bash +sudo nmcli connection modify ipv4.addresses ipv4.method manual +``` + +- Attribuez une adresse de passerelle : + +```bash +sudo nmcli connection modify ipv4.gateway +``` + +- Attribuez une adresse DNS : + +```bash +sudo nmcli connection modify ipv4.dns +``` + +- Ajoutez la connexion esclave du pont : + +```bash +sudo nmcli connection add type bridge-slave autoconnect yes con-name ifname master +``` + +- Démarrer la connexion du pont : + +```bash +sudo nmcli connection up +``` + +- Ajoutez la ligne `allow all` à `bridge.conf` : + +```bash +sudo tee -a /etc/qemu-kvm/bridge.conf < +``` + +- Pour forcer l'arrêt d'une VM qui ne répond pas, utilisez la commande `destroy` : + +```bash +virsh destroy --domain +``` + +## Comment supprimer une machine virtuelle + +- Utilisez la commande `undefine` : + +```bash +virsh undefine --domain --nvram +``` + +- Pour plus de commandes `virsh`, consultez les pages de manuel `virsh`. + +## Conclusion + +- libvirt offre de nombreuses possibilités et vous permet d'installer et de gérer vos machines virtuelles en toute simplicité. Si vous avez des ajouts ou des modifications à apporter à ce document que vous souhaiteriez partager, l’auteur vous invite volontiers à le faire. diff --git a/docs/guides/web/apache_hardened_webserver/index.it.md b/docs/guides/web/apache_hardened_webserver/index.it.md index 4bbe5946a7..b4309af691 100644 --- a/docs/guides/web/apache_hardened_webserver/index.it.md +++ b/docs/guides/web/apache_hardened_webserver/index.it.md @@ -33,7 +33,7 @@ L'hardening dei server Web può assumere molte forme, tra cui uno o tutti gli st Potreste utilizzare un paio di questi strumenti e non gli altri. Per chiarezza e leggibilità, questo documento è suddiviso in documenti separati per ogni strumento. L'eccezione sarà il firewall basato sui pacchetti`(firewalld`) di cui al presente documento principale. -* Un buon firewall con filtro dei pacchetti basato sulle porte (iptables, firewalld, o firewall hardware - utilizzaremo `firewalld` per i nostri esempi) [procedura`firewalld`](#iptablesstart) +* Un buon firewall con filtro dei pacchetti basato sulle porte (iptables, firewalld o hardware firewall - useremo `firewalld` per i nostri esempi) procedura `firewalld` * Un sistema di rilevamento delle intrusioni basato su host (HIDS), in questo caso _ossec-hids_ [Apache Hardened Web Server - ossec-hids](ossec-hids.md) * Un firewall per applicazioni basate sul Web (WAF), con regole `mod_security` [Apache Hardened Web Server - mod_security](modsecurity.md) * Rootkit Hunter`(rkhunter`): Uno strumento di scansione che controlla il malware Linux [Apache Hardened Web Server - rkhunter](rkhunter.md) @@ -72,9 +72,9 @@ Il diagramma mostra la nostra disposizione generale. Il `firewalld`, basato sui In ogni sezione del pacchetto sono elencati i file di installazione necessari e le procedure di configurazione. -## Configurazione di `firewalld` +## Configurazione di `firewalld` -``` +```bash firewall-cmd --zone=trusted --add-source=192.168.1.2 --permanent firewall-cmd --zone=trusted --add-service=ssh --permanent firewall-cmd --zone=public --remove-service=ssh --permanent @@ -85,6 +85,7 @@ firewall-cmd --zone=public --add-port=20/tcp --permanent firewall-cmd --zone=public --add-port=7000-7500/tcp --permanent firewall-cmd --reload ``` + Ecco cosa sta succedendo: * impostare la nostra zona fidata sull'indirizzo IP del firewall hardware diff --git a/docs/guides/web/apache_hardened_webserver/rkhunter.it.md b/docs/guides/web/apache_hardened_webserver/rkhunter.it.md index 8cf0944cd9..3ac334fc83 100644 --- a/docs/guides/web/apache_hardened_webserver/rkhunter.it.md +++ b/docs/guides/web/apache_hardened_webserver/rkhunter.it.md @@ -9,7 +9,7 @@ tags: - rkhunter --- -# Rootkit hunter +# Rootkit Hunter ## Introduzione diff --git a/docs/guides/web/caddy.it.md b/docs/guides/web/caddy.it.md index f137f0b389..c68484db28 100644 --- a/docs/guides/web/caddy.it.md +++ b/docs/guides/web/caddy.it.md @@ -160,10 +160,10 @@ Per installare PHP, aggiungere prima il repository Remi (nota: se si utilizza Ro dnf install https://rpms.remirepo.net/enterprise/remi-release-9.rpm ``` -Successivamente, occorre installare PHP (nota: se si utilizza un'altra versione di PHP, sostituire la versione desiderata al posto di php81): +Successivamente, occorre installare PHP (nota: se si utilizza un'altra versione di PHP, sostituire la versione desiderata con php83): ```bash -dnf install -y php81-php-fpm +dnf install -y php83-php-fpm ``` Se sono necessari altri moduli PHP (ad esempio, GD), aggiungerli al comando precedente. @@ -171,13 +171,13 @@ Se sono necessari altri moduli PHP (ad esempio, GD), aggiungerli al comando prec Quindi, occorre configurare PHP per l'ascolto su un socket TCP: ```bash -vim /etc/opt/remi/php81/php-fpm.d/www.conf +vim /etc/opt/remi/php83/php-fpm.d/www.conf ``` Quindi, trovare la riga: ```bash -listen = /var/opt/remi/php81/run/php-fpm/www.sock +listen = /var/opt/remi/php83/run/php-fpm/www.sock ``` Sostituirla con questa: @@ -186,7 +186,7 @@ Sostituirla con questa: listen = 127.0.0.1:9000 ``` -Quindi salvare e uscire dal file www.conf e aprire il file Caddy: +Quindi salvare e uscire dal file www\.conf e aprire il file Caddy: ```bash vim /etc/caddy/Caddyfile diff --git a/docs/guides/web/mod_SSL_apache.it.md b/docs/guides/web/mod_SSL_apache.it.md index 7babc3e79d..a15b219a17 100644 --- a/docs/guides/web/mod_SSL_apache.it.md +++ b/docs/guides/web/mod_SSL_apache.it.md @@ -160,7 +160,7 @@ Inserite il seguente contenuto e salvate il file, sostituendo "your-server-hostn Servername rocky8 Redirect permanent / https://your-server-hostname/ - + ``` Applicare la modifica eseguendo: diff --git a/docs/release_notes/9_4.it.md b/docs/release_notes/9_4.it.md index fe1fc0f367..0841078fb9 100644 --- a/docs/release_notes/9_4.it.md +++ b/docs/release_notes/9_4.it.md @@ -17,7 +17,7 @@ tags: !!! Note "Nota" ``` -Rocky Linux non offre un percorso di aggiornamento da qualsiasi versione di Rocky Linux 8. Si consiglia di eseguire un'installazione ex novo del sistema operativo per passare a Rocky Linux 9.4. +Rocky Linux non offre un percorso di aggiornamento da qualsiasi versione di Rocky Linux 8. Per passare a Rocky Linux 9.4 si consiglia di eseguire una nuova installazione del sistema operativo. ``` ## Immagini diff --git a/docs/release_notes/9_5.it.md b/docs/release_notes/9_5.it.md index ed43b4e38c..ad1c238a77 100644 --- a/docs/release_notes/9_5.it.md +++ b/docs/release_notes/9_5.it.md @@ -55,7 +55,7 @@ I punti salienti e le nuove funzionalità di questa versione sono illustrati di Di seguito sono elencati i punti salienti relativi alla sicurezza dell'ultima release Rocky Linux 9.5. Per un elenco completo delle modifiche relative alla sicurezza, consultare il [link upstream qui](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-single/9.5_release_notes/index#new-features-security). - **SELinux** La politica SELinux ora fornisce un booleano che permette a QEMU Guest Agent di eseguire comandi confinati -- **OpenSSL** TLS toolkit aggiornato alla 3.2.2. OpenSSL ora supporta la compressione dei certificati e aggiunge le curve Brainpool al protocollo TLS 1.3 +- **OpenSSL** TLS toolkit aggiornato alla 3.2.2. OpenSSL ora supporta l'estensione della compressione dei certificati e aggiunge le Curve di Brainpool al protocollo TLS 1.3 - Il programma **ca-certificates** ora fornisce roots CA affidabili nel formato della directory OpenSSL - I pacchetti **crypto-policies** sono aggiornati per estendere il controllo alle sezioni degli algoritmi in Java - Il toolkit crittografico **NSS** è stato aggiornato alla versione upstream 3.101 @@ -98,8 +98,9 @@ Aggiornati gli strumenti del compilatore: - **Rust Toolset 1.79.0** - **Go Toolset 1.22** -Aggiornata l'implementazione predefinita di Java a `java-17-openjdk`:\ -Dopo questo aggiornamento i pacchetti `java`, `java-devel` e `jre` installeranno Java 17 invece di Java 11. +Aggiornata l'implementazione predefinita di Java a `java-17-openjdk`: + +- Dopo questo aggiornamento, i pacchetti `java`, `java-devel` e `jre` installeranno Java 17 invece di Java 11. ### Web console