From 58e3917806f6fd08a0da3b763fa29d3f136ceea7 Mon Sep 17 00:00:00 2001 From: Rocky Linux Automation <75949597+rockylinux-auto@users.noreply.github.com> Date: Sat, 30 Nov 2024 14:06:56 -0500 Subject: [PATCH] New Crowdin updates (#2520) * New translations 00-toc.md (Italian) * New translations 02-web-servers-intro.md (Italian) * New translations 00-toc.md (Italian) * New translations disa_stig_part3.md (Italian) * Update 00-toc.it.md --------- Co-authored-by: sspencerwire --- docs/books/disa_stig/disa_stig_part3.it.md | 44 ++++----- docs/books/lxd_server/00-toc.it.md | 28 +++--- docs/books/web_services/00-toc.it.md | 8 +- .../web_services/02-web-servers-intro.it.md | 93 +++++++++++++++++++ 4 files changed, 134 insertions(+), 39 deletions(-) create mode 100644 docs/books/web_services/02-web-servers-intro.it.md diff --git a/docs/books/disa_stig/disa_stig_part3.it.md b/docs/books/disa_stig/disa_stig_part3.it.md index 51153c1e0a..cb6c8af433 100644 --- a/docs/books/disa_stig/disa_stig_part3.it.md +++ b/docs/books/disa_stig/disa_stig_part3.it.md @@ -12,14 +12,14 @@ tags: # Introduzione -Nella prima parte di questa serie abbiamo spiegato come costruire il nostro server web con la STIG RHEL8 DISA di base applicata e nella seconda parte abbiamo imparato a testare la conformità STIG con lo strumento OpenSCAP. Ora faremo qualcosa con il sistema, costruendo una semplice applicazione web e applicando la STIG del server web DISA: +Nella prima parte di questa serie, abbiamo spiegato come costruire il nostro server web con la STIG RHEL8 DISA di base applicata e, nella seconda parte, abbiamo imparato a testare la conformità STIG con lo strumento OpenSCAP. Ora faremo qualcosa con il sistema, costruendo una semplice applicazione web e applicando la STIG del server web DISA: https://www.stigviewer.com/stig/web_server/ -Per prima cosa confrontiamo ciò che stiamo affrontando: la STIG DISA di RHEL 8 è indirizzata a una piattaforma molto specifica, quindi i controlli sono abbastanza facili da capire in quel contesto, da testare e da applicare. Le STIG delle applicazioni devono essere portabili su più piattaforme, quindi il contenuto è generico per funzionare su diverse distribuzioni Linux (RHEL, Ubuntu, SuSE, ecc.) **. Ciò significa che strumenti come OpenSCAP non ci aiuteranno a verificare/rimediare la configurazione, dovremo farlo manualmente. Questi STIG sono: +Per prima cosa confrontiamo ciò che stiamo affrontando: la STIG DISA di RHEL 8 è indirizzata a una piattaforma molto specifica, quindi i controlli sono abbastanza facili da capire in quel contesto, da testare e da applicare. Le STIG delle applicazioni devono essere portabili su più piattaforme, quindi il contenuto qui presente è generico per funzionare su diverse distribuzioni Linux (RHEL, Ubuntu, SuSE, ecc.)**. Strumenti come OpenSCAP non ci aiutano a verificare/recuperare la configurazione. Andremo a farlo manualmente. Questi STIG sono: * Apache 2.4 V2R5 - Server; che si applica al server web stesso * Apache 2.4 V2R5 - Sito; Che si applica all'applicazione web/sito web -Per la nostra guida, creeremo un semplice server web che non fa altro che servire contenuti statici. Possiamo usare le modifiche apportate qui per creare un'immagine di base e poi usare questa immagine di base quando costruiamo server web più complessi in seguito. +Per la nostra guida, creeremo un semplice server web che non fa altro che servire contenuti statici. Possiamo usare le modifiche apportate qui per creare un'immagine di base, che potremo poi usare quando costruiremo server web più complessi. ## Avvio rapido del server Apache 2.4 V2R5 @@ -38,16 +38,16 @@ sed -i 's/^\([^#].*\)**/# \1/g' /etc/httpd/conf.d/welcome.conf dnf -y remove httpd-manual dnf -y install mod_session -echo “MaxKeepAliveRequests 100” > /etc/httpd/conf.d/disa-apache-stig.conf -echo “SessionCookieName session path=/; HttpOnly; Secure;” >> /etc/httpd/conf.d/disa-apache-stig.conf -echo “Session On” >> /etc/httpd/conf.d/disa-apache-stig.conf -echo “SessionMaxAge 600” >> /etc/httpd/conf.d/disa-apache-stig.conf -echo “SessionCryptoCipher aes256” >> /etc/httpd/conf.d/disa-apache-stig.conf -echo “Timeout 10” >> /etc/httpd/conf.d/disa-apache-stig.conf -echo “TraceEnable Off” >> /etc/httpd/conf.d/disa-apache-stig.conf -echo “RequestReadTimeout 120” >> /etc/httpd/conf.d/disa-apache-stig.conf +echo "MaxKeepAliveRequests 100" > /etc/httpd/conf.d/disa-apache-stig.conf +echo "SessionCookieName session path=/; HttpOnly; Secure;" >> /etc/httpd/conf.d/disa-apache-stig.conf +echo "Session On" >> /etc/httpd/conf.d/disa-apache-stig.conf +echo "SessionMaxAge 600" >> /etc/httpd/conf.d/disa-apache-stig.conf +echo "SessionCryptoCipher aes256" >> /etc/httpd/conf.d/disa-apache-stig.conf +echo "Timeout 10" >> /etc/httpd/conf.d/disa-apache-stig.conf +echo "TraceEnable Off" >> /etc/httpd/conf.d/disa-apache-stig.conf +echo "RequestReadTimeout 120" >> /etc/httpd/conf.d/disa-apache-stig.conf -sed -i “s/^#LoadModule usertrack_module/LoadModule usertrack_module/g” /etc/httpd/conf.modules.d/00-optional.conf +sed -i "s/^#LoadModule usertrack_module/LoadModule usertrack_module/g" /etc/httpd/conf.modules.d/00-optional.conf sed -i "s/proxy_module/#proxy_module/g" /etc/httpd/conf.modules.d/00-proxy.conf sed -i "s/proxy_ajp_module/#proxy_ajp_module/g" /etc/httpd/conf.modules.d/00-proxy.conf sed -i "s/proxy_balancer_module/#proxy_balancer_module/g" /etc/httpd/conf.modules.d/00-proxy.conf @@ -68,7 +68,7 @@ systemctl start httpd ## Panoramica dei Controlli Dettagliati -Se siete arrivati fin qui, probabilmente siete interessati a saperne di più su ciò che la STIG vuole che facciamo. È utile capire l'importanza del controllo e quindi come si applica all'applicazione. A volte il controllo è tecnico (cambiare l'impostazione X in Y) e altre volte è operativo (come lo si usa). In generale, un controllo tecnico è qualcosa che si può modificare con il codice, mentre un controllo operativo probabilmente no. +Se siete arrivati fin qui, probabilmente siete interessati a saperne di più su ciò che la STIG vuole che facciamo. Aiuta a capire l'importanza del controllo e come si applica all'applicazione. A volte il controllo è tecnico (cambiare l'impostazione X in Y); altre volte è operativo (come lo si usa). In generale, un controllo tecnico è qualcosa che si può modificare con il codice, mentre un controllo operativo probabilmente no. ### Livelli @@ -81,7 +81,7 @@ Se siete arrivati fin qui, probabilmente siete interessati a saperne di più su * Tecnico - 24 controlli * Operativo - 23 controlli -In questo articolo non tratteremo il "perché" di queste modifiche, ma solo ciò che deve accadere se si tratta di un controllo tecnico. Se non c'è nulla da modificare, come nel caso di un controllo Operational, il campo **Fix:** sarà vuoto. La buona notizia è che in molti di questi casi si tratta già dell'impostazione predefinita di Rocky Linux 8, quindi non è necessario cambiare nulla. +In questo articolo non tratteremo il “perché” di queste modifiche; discuteremo di ciò che deve accadere se si tratta di un controllo tecnico. Se non c'è nulla da modificare, come nel caso di un controllo Operational, il campo Fix: sarà vuoto. La buona notizia in molti di questi casi è che questa è già l'impostazione predefinita in Rocky Linux 8, quindi non è necessario cambiare nulla. ## Apache 2.4 V2R5 - Dettagli del Server @@ -165,7 +165,7 @@ dnf remove httpd-manual ```bash dnf install mod_session -echo “SessionCookieName session path=/; HttpOnly; Secure;” >> /etc/httpd/conf.d/disa-apache-stig.conf +echo "SessionCookieName session path=/; HttpOnly; Secure;" >> /etc/httpd/conf.d/disa-apache-stig.conf ``` **(V-214269)** Il server web Apache deve rimuovere tutti i cifrari di esportazione per proteggere la riservatezza e l'integrità delle informazioni trasmesse. @@ -217,7 +217,7 @@ echo “SessionCookieName session path=/; HttpOnly; Secure;” >> /etc/httpd/co **Fix:** ```bash -echo “MaxKeepAliveRequests 100” > /etc/httpd/conf.d/disa-apache-stig.conf +echo "MaxKeepAliveRequests 100" > /etc/httpd/conf.d/disa-apache-stig.conf ``` **(V-214229)** Il server web Apache deve eseguire la gestione della sessione lato server. @@ -227,7 +227,7 @@ echo “MaxKeepAliveRequests 100” > /etc/httpd/conf.d/disa-apache-stig.conf **Fix:** ```bash -sed -i “s/^#LoadModule usertrack_module/LoadModule usertrack_module/g” /etc/httpd/conf.modules.d/00-optional.conf +sed -i "s/^#LoadModule usertrack_module/LoadModule usertrack_module/g" /etc/httpd/conf.modules.d/00-optional.conf ``` **(V-214266)** Il server web Apache deve vietare o limitare l'uso di porte, protocolli, moduli e/o servizi non sicuri o non necessari. @@ -320,7 +320,7 @@ Fare riferimento a per **Fix:** ```bash -echo “Session On” >> /etc/httpd/conf.d/disa-apache-stig.conf +echo "Session On" >> /etc/httpd/conf.d/disa-apache-stig.conf ``` **(V-214250)** Il server web Apache deve invalidare gli identificatori di sessione al momento del logout dell'utente dell'applicazione ospitata o al termine di un'altra sessione. @@ -330,7 +330,7 @@ echo “Session On” >> /etc/httpd/conf.d/disa-apache-stig.conf **Fix:** ```bash -echo “SessionMaxAge 600” >> /etc/httpd/conf.d/disa-apache-stig.conf +echo "SessionMaxAge 600" >> /etc/httpd/conf.d/disa-apache-stig.conf ``` **(V-214252)** Il server Web Apache deve generare un ID di sessione sufficientemente lungo da non poter essere indovinato con la forza bruta. @@ -340,7 +340,7 @@ echo “SessionMaxAge 600” >> /etc/httpd/conf.d/disa-apache-stig.conf **Fix:** ```bash -echo “SessionCryptoCipher aes256” >> /etc/httpd/conf.d/disa-apache-stig.conf +echo "SessionCryptoCipher aes256" >> /etc/httpd/conf.d/disa-apache-stig.conf ``` **(V-214255)** Il server web Apache deve essere regolato per gestire i requisiti operativi dell'applicazione ospitata. @@ -350,7 +350,7 @@ echo “SessionCryptoCipher aes256” >> /etc/httpd/conf.d/disa-apache-stig.con **Fix:** ```bash -echo “Timeout 10” >> /etc/httpd/conf.d/disa-apache-stig.conf +echo "Timeout 10" >> /etc/httpd/conf.d/disa-apache-stig.conf ``` **(V-214254)** Il server web Apache deve essere costruito in modo da fallire in uno stato sicuro noto se l'inizializzazione del sistema fallisce, lo spegnimento fallisce o le interruzioni falliscono. @@ -366,7 +366,7 @@ echo “Timeout 10” >> /etc/httpd/conf.d/disa-apache-stig.conf **Fix:** ```bash -echo “TraceEnable Off” >> /etc/httpd/conf.d/disa-apache-stig.conf +echo "TraceEnable Off" >> /etc/httpd/conf.d/disa-apache-stig.conf ``` **(V-214230)** Il server Web Apache deve utilizzare la crittografia per proteggere l'integrità delle sessioni remote. diff --git a/docs/books/lxd_server/00-toc.it.md b/docs/books/lxd_server/00-toc.it.md index e7dcf8b944..7b079c01c5 100644 --- a/docs/books/lxd_server/00-toc.it.md +++ b/docs/books/lxd_server/00-toc.it.md @@ -10,19 +10,21 @@ tags: # Creare un server LXD completo -??? warning "Stato attuale di LXD su Rocky Linux!" +!!! info "Informazione" - 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. + Questa procedura dovrebbe funzionare per Rocky Linux 8.x o 9.x. Se cercate un'implementazione moderna di questo progetto degli ex sviluppatori di LXD, ma disponibile solo per Rocky Linux 9.x, date un'occhiata a [il libro di Incus Server] (../incus_server/00-toc.md). + +!!! info "Cosa è successo al progetto LXD" + + Più di un anno fa, nella mailing list lxc-users è stato pubblicato il seguente annuncio: - 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. + > Canonical, the creator and main contributor of the LXD project has decided that after over eight years as part of the Linux Containers community, the project would now be better served directly under Canonical’s own set of projects. - 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. + 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, e ora la 6.4 LTS (da settembre 2024). - 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. + 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. Tuttavia, 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. Mentre Linux Containers non può più fornire immagini di container a LXD, il progetto LXD è riuscito a costruire alcuni container, compresi quelli per Rocky Linux. - Tenete d'occhio i cambiamenti qui! + Questo documento utilizza LXD anziché Incus. ## Introduzione @@ -39,10 +41,10 @@ Per coloro che desiderano utilizzare LXD come ambiente di laboratorio sui propri ## Prerequisiti e presupposti * Un server Linux Rocky, ben configurato. Considerare un disco rigido separato per lo spazio disco ZFS (è necessario se si usa ZFS) in un ambiente di produzione. E sì, il presupposto è un server bare metal, non un VPS (Virtual Private Server). -* Si tratta di un argomento avanzato, ma non è troppo difficile da capire e se si seguono queste istruzioni fin dall'inizio si dovrebbe avere successo. Detto questo, conoscere alcune nozioni di base sulla gestione dei container vi porterà lontano. -* Comfort alla riga di comando sulla/e macchina/e e dimestichezza con l'editor della riga di comando. (In questi esempi si utilizza _vi_, ma è possibile sostituirlo con il proprio editor preferito.) +* Si tratta di un argomento avanzato, ma non troppo difficile da comprendere. Se si seguono queste istruzioni fin dall'inizio, si dovrebbe avere successo. Detto questo, la conoscenza di alcune nozioni di base sulla gestione dei container è molto utile. +* Comfort dalla riga di comando sulla/e macchina/e e dimestichezza con l'editor della riga di comando. (In questi esempi si utilizza _vi_, ma è possibile sostituirlo con il proprio editor preferito.) * Per la maggior parte di questi processi è necessario essere un utente non privilegiato. Per le prime fasi di configurazione, è necessario essere l'utente root o essere in grado di usare `sudo` per diventarlo. In tutti questi capitoli si assume che l'utente non privilegiato sia "lxdadmin". L'account utente dovrà essere creato più avanti nel processo. -* Per ZFS, assicurarsi che l'avvio sicuro UEFI NON sia abilitato. Altrimenti, si finirà per dover firmare il modulo ZFS per farlo caricare. +* Per ZFS, assicurarsi che il UEFI secure boot NON sia abilitato. Altrimenti, si finirà per dover firmare il modulo ZFS per farlo caricare. * Utilizzo di container basati su Rocky Linux per la maggior parte del tempo ## Sinossi @@ -52,7 +54,7 @@ Per coloro che desiderano utilizzare LXD come ambiente di laboratorio sui propri * Il **Capitolo 3: Inizializzazione di LXD e configurazione dell'utente** si occupa dell'inizializzazione di base e delle opzioni, nonché della configurazione dell'utente non privilegiato che verrà utilizzato per la maggior parte del resto del processo * **Capitolo 4: Impostazione del firewall** Ha le opzioni di configurazione di `firewalld` * Il **capitolo 5: Impostazione e gestione delle immagini** descrive il processo di installazione delle immagini del sistema operativo in un contenitore e la loro configurazione -* Il **Capitolo 6: Profili** si occupa dell'aggiunta di profili e della loro applicazione ai contenitori, in particolare di macvlan e della sua importanza per l'indirizzamento IP sulla LAN o sulla WAN +* Il **Capitolo 6: Profili** si occupa dell'aggiunta di profili e della loro applicazione ai container, in particolare di macvlan e della sua importanza per l'indirizzamento IP sulla LAN o sulla WAN * Il **capitolo 7: Opzioni di configurazione dei contenitori** copre brevemente alcune delle opzioni di configurazione di base per i contenitori e offre alcuni vantaggi ed effetti collaterali per la modifica delle opzioni di configurazione * Il **capitolo 8: Istantanee dei contenitori** illustra in dettaglio il processo di istantanea dei contenitori sul server primario * Il **capitolo 9: Il server snapshot** tratta l'impostazione e la configurazione del server snapshot e come creare una relazione simbiotica tra il server primario e il server snapshot @@ -63,4 +65,4 @@ Per coloro che desiderano utilizzare LXD come ambiente di laboratorio sui propri Questi capitoli consentono di configurare efficacemente un server LXD primario e uno snapshot di livello aziendale. Nel corso di questo processo, imparerete molto su LXD. Siate consapevoli che c'è ancora molto da imparare e considerate questi documenti come un punto di partenza. -Il vantaggio principale di LXD è che è economico da usare su un server, consente di avviare rapidamente le installazioni del sistema operativo e permette di eseguire molti server applicativi stand-alone su un singolo pezzo di hardware, sfruttando l'hardware per il massimo utilizzo. +Il vantaggio principale di LXD è che è economico da usare su un server, consente di avviare rapidamente le installazioni del sistema operativo e permette di eseguire molti server applicativi stand-alone su un singolo componente hardware, sfruttando l'hardware per il massimo utilizzo. diff --git a/docs/books/web_services/00-toc.it.md b/docs/books/web_services/00-toc.it.md index 4db941eccb..1f88553355 100644 --- a/docs/books/web_services/00-toc.it.md +++ b/docs/books/web_services/00-toc.it.md @@ -1,7 +1,7 @@ --- title: Prefazione author: Antoine Le Morvan -contributors: Steven Spencer, Franco Colussi +contributors: Steven Spencer, Franco Colussi, Ganna Zhyrnova tags: - web - services @@ -15,16 +15,16 @@ Il web non sarebbe quello che è senza la posta elettronica. I servizi web fanno A volte questi servizi sono estremamente trafficati o richiedono servizi altamente disponibili. In questi casi, è possibile implementare altri servizi per garantire prestazioni ottimali (Heartbeat, PCS). -Ogni capitolo di questo libro può essere consultato indipendentemente, a seconda delle proprie esigenze, e non è necessario leggere i capitoli in ordine. +Ogni capitolo di questo libro può essere consultato indipendentemente, a seconda delle proprie esigenze, e la lettura dei capitoli in ordine non è obbligatoria. Anche questo libro fa parte di una serie di libri dedicati all'amministrazione di sistema in Linux (Guida amministrativa, Imparare Bash, Imparare Ansible). Se necessario, sarete invitati a rivedere i concetti che vi mancano nei capitoli corrispondenti dei libri sopra citati. ## Pubblico -Il target di questo libro è costituito da amministratori di sistema già addestrati all'uso dei comandi di amministrazione del sistema (si veda [il nostro libro Admin Guide](../admin_guide/00-toc.md)), che desiderano installare, configurare e proteggere i propri servizi web. +Il pubblico a cui si rivolge questo libro è quello degli amministratori di sistema già abituati all'uso dei comandi di amministrazione del sistema (si veda [il nostro libro Admin Guide](../admin_guide/00-toc.md)) che vogliono installare, configurare e proteggere i loro servizi web. ## Come utilizzare questo libro -Questo libro è stato concepito come un manuale di formazione, in modo da poter essere utilizzato in diversi modi. Sia come ausilio alla formazione dei formatori, sia come ausilio all'autoformazione degli amministratori che desiderano acquisire nuove competenze o rafforzare le proprie conoscenze. +Questo libro è stato concepito come un manuale di formazione, in modo da poter essere utilizzato in diversi modi. Può essere utilizzato come strumento di formazione per i formatori o come strumento di autoformazione per gli amministratori che desiderano acquisire nuove competenze o rafforzare le conoscenze esistenti. Per implementare alcuni dei servizi presentati in questo libro, potrebbero essere necessari due (o più) server per mettere in pratica la teoria. diff --git a/docs/books/web_services/02-web-servers-intro.it.md b/docs/books/web_services/02-web-servers-intro.it.md new file mode 100644 index 0000000000..b52755491e --- /dev/null +++ b/docs/books/web_services/02-web-servers-intro.it.md @@ -0,0 +1,93 @@ +--- +author: Antoine Le Morvan +contributors: Steven Spencer, Ganna Zhyrnova +title: Capitolo 2. Introduzione ai server web +--- + +## Introduzione + +### Protocollo HTTP + +Il **HTTP** (**H**yper**T**ext **T**ransfer **P**rotocol) è il protocollo più utilizzato in Internet dal 1990. + +Questo protocollo consente il trasferimento di file (principalmente in formato HTML, ma anche CSS, JS, AVI, ecc.). Individuato da una stringa di caratteri chiamata **URL** tra un browser (il client) e un server Web (chiamato `httpd` su macchine UNIX). + +L'HTTP è un protocollo “request-response” che opera sulla base del **TCP** (**T**ransmission **C**ontrol **P**rotocol). + +1. Il client apre una connessione TCP al server e invia una richiesta. +2. Il server analizza la richiesta e risponde in base alla sua configurazione. + +Il protocollo HTTP è “**STATELESS**”: non conserva alcuna informazione sullo stato del client da una richiesta all'altra. I linguaggi dinamici come PHP, Python o Java memorizzano le informazioni di sessione del cliente (come in un sito di e-commerce). + +Gli attuali protocolli HTTP sono la versione 1.1, ampiamente utilizzata, e le versioni 2 e 3, che si stanno diffondendo. + +Una responce HTTP è un insieme di righe inviate al browser dal server. Che include: + +- Una **status line**: specifica la versione del protocollo e lo stato di elaborazione della richiesta utilizzando un codice e un testo esplicativo. La riga comprende tre elementi separati da uno spazio: + - La versione del protocollo utilizzata + - Lo status code + - Il significato del codice + +- **Response header fields**: queste righe opzionali forniscono informazioni aggiuntive sulla risposta e/o sul server. Ogni riga è composta da un nome che qualifica il header type, seguito da due punti (:) e dal header value. + +- **The response body**: contiene il documento richiesto. + +Ecco un esempio di risposta HTTP: + +```bash +$ curl --head --location https://docs.rockylinux.org +HTTP/2 200 +accept-ranges: bytes +access-control-allow-origin: * +age: 109725 +cache-control: public, max-age=0, must-revalidate +content-disposition: inline +content-type: text/html; charset=utf-8 +date: Fri, 21 Jun 2024 12:05:24 GMT +etag: "cba6b533f892339d3818dc59c3a5a69a" +server: Vercel +strict-transport-security: max-age=63072000 +x-vercel-cache: HIT +x-vercel-id: cdg1::pdqbh-1718971524213-4892bf82d7b2 +content-length: 154696 +``` + +!!! NOTE "Nota" + +``` +Imparare a usare il comando `curl` sarà molto utile per la risoluzione dei problemi sui server in futuro. +``` + +Il ruolo del server web è quello di tradurre un URL in una risorsa locale. Consultare la pagina e' come mandare una richiesta HTTP a questa server. Il servizio DNS gioca un ruolo essenziale. + +### URLs + +Un **URL** (**U**niform **R**esource **L**ocator) e' una stringa di caratteri in ASCII utilizzata per identificare risorse su Internet. Viene informalmente chiamato indirizzo web. + +Un URL ha tre parti: + +```text +://:/ +``` + +- **Protocol name**: si tratta del linguaggio utilizzato per comunicare in rete, come HTTP, HTTPS, FTP, ecc. I protocolli più utilizzati sono l'HTTP (HyperText Transfer Protocol) e la sua versione sicura, l'HTTPS, utilizzata per lo scambio di pagine Web in formato HTML. + +- **Login** e **password**: Questa opzione consente di specificare i parametri di accesso a un server sicuro. Non è consigliabile, poiché la password è visibile nell'URL (per motivi di sicurezza). + +- **Host**: È il nome del computer che ospita la risorsa richiesta. È possibile utilizzare anche l'indirizzo IP del server, ma ciò rende l'URL meno leggibile. + +- **Port number**: È associato a un servizio che consente al server di conoscere il tipo di risorsa richiesta. La porta predefinita del protocollo HTTP è la 80 e la 443 per HTTPS. Pertanto, il numero di porta è facoltativo quando il protocollo è HTTP o HTTPS. + +- **Resource path**: Questa parte consente al server di conoscere la posizione della risorsa. In genere, si tratta della posizione (directory) e del nome del file richiesto. Se l'indirizzo non specifica una posizione, indica la prima pagina dell'host. Altrimenti, indica il percorso della pagina da visualizzare. + +### Porte + +Una richiesta HTTP arriva sulla porta 80 (la porta predefinita per HTTP) del server in esecuzione sull'host. Tuttavia, l'amministratore è libero di scegliere la porta di ascolto del server. + +Il protocollo HTTP è disponibile in una versione sicura: il protocollo HTTPS (porta 443). Si implementa questo protocollo criptato con il modulo `mod_ssl`. + +È possibile utilizzare anche altre porte, come la porta `8080` (utilizzata dai server di applicazioni Java EE). + +## Apache ed Nginx + +I due server web più comuni per Linux sono Apache e Nginx. Saranno discussi nei prossimi capitoli.