From 606504d1bad173a341ffbe77bab4e5ba2e3625b4 Mon Sep 17 00:00:00 2001 From: Rocky Linux Automation <75949597+rockylinux-auto@users.noreply.github.com> Date: Sun, 2 Mar 2025 15:33:54 -0500 Subject: [PATCH] New Crowdin updates (#2613) * New translations templates-automation-packer-vsphere.md (French) * New translations podman_guide.md (Ukrainian) * New translations 052-load-balancer-proxies-varnish.md (Italian) * New translations 09-backups.md (Italian) * New translations 053-load-balancer-proxies-squid.md (Italian) * New translations rockydocs_webdev_v2.md (Ukrainian) * New translations nsd_authoritative_dns.md (Ukrainian) * New translations import_rocky_to_wsl.md (Ukrainian) * New translations nsd_authoritative_dns.md (French) --- docs/books/admin_guide/09-backups.it.md | 6 +- .../052-load-balancer-proxies-varnish.it.md | 703 ++++++++++++++++++ .../053-load-balancer-proxies-squid.it.md | 568 ++++++++++++++ .../templates-automation-packer-vsphere.fr.md | 2 +- docs/guides/containers/podman_guide.uk.md | 2 +- .../localdocs/rockydocs_webdev_v2.uk.md | 8 +- docs/guides/dns/nsd_authoritative_dns.fr.md | 4 +- docs/guides/dns/nsd_authoritative_dns.uk.md | 80 +- .../import_rocky_to_wsl.uk.md | 10 +- 9 files changed, 1365 insertions(+), 18 deletions(-) create mode 100644 docs/books/web_services/052-load-balancer-proxies-varnish.it.md create mode 100644 docs/books/web_services/053-load-balancer-proxies-squid.it.md diff --git a/docs/books/admin_guide/09-backups.it.md b/docs/books/admin_guide/09-backups.it.md index e704d4ea77..606f9164f9 100644 --- a/docs/books/admin_guide/09-backups.it.md +++ b/docs/books/admin_guide/09-backups.it.md @@ -555,7 +555,7 @@ A differenza del comando `tar`, non esiste un'opzione per eseguire il backup e l `cpio` ha tre modalità operative, ciascuna corrispondente a una funzione diversa: -1. **copy-out mode** - Creare un backup (archivio). È possibile attivare questa modalità mediante l'opzione `-o` o `--create`. In questa modalità, è necessario generare un elenco di file con un comando specifico (`find`, `ls` o `cat`) e passarlo a cpio. +1. **copy-out mode** - Crea un backup (archivio). È possibile attivare questa modalità mediante l'opzione `-o` o `--create`. In questa modalità, è necessario generare un elenco di file con un comando specifico (`find`, `ls` o `cat`) e passarlo a cpio. * `find` : naviga in un albero, ricorsivo o meno; * `ls` : elencare una directory, ricorsiva o meno; @@ -572,14 +572,14 @@ A differenza del comando `tar`, non esiste un'opzione per eseguire il backup e l Come per il comando `tar`, gli utenti devono prestare attenzione a come viene salvato l'elenco dei file (**percorso assoluto** o percorso relativo) quando si crea un archivio. -funzione secondaria: +Funzione secondaria: 1. `-t` - Stampa un indice del contenuto dell'input. 2. `-A` - Aggiunge a un archivio esistente. Funziona solo in modalità copy-in. !!! note "Nota" - Alcune opzioni di `cpio` devono essere combinate con la modalità operativa corretta per funzionare correttamente, vedere `man 1 cpio` + Alcune opzioni di `cpio` devono essere combinate con la modalità operativa corretta per funzionare correttamente. Vedere `man 1 cpio` ### modalità copy-out diff --git a/docs/books/web_services/052-load-balancer-proxies-varnish.it.md b/docs/books/web_services/052-load-balancer-proxies-varnish.it.md new file mode 100644 index 0000000000..4fb9752286 --- /dev/null +++ b/docs/books/web_services/052-load-balancer-proxies-varnish.it.md @@ -0,0 +1,703 @@ +--- +author: Antoine Le Morvan +contributors: Ganna Zhyrnova +title: Parte 5.2 Varnish +--- + +## Varnish + +Questo capitolo presenta l'acceleratore web proxy cache : Varnish. + +**** + +**Obiettivi**: si imparerà come: + +:heavy_check_mark: Installare e configurare Varnish;\ +:heavy_check_mark: Mettere in cache il contenuto di un sito web. + +:checkered_flag: **reverse-proxy**, **cache** + +**Conoscenza**: :star: :star: +**Complessità**: :star: :star: :star: + +**Tempo di lettura**: 30 minuti + +**** + +### Generalità + +Varnish è un servizio di reverse-proxy-cache HTTP o un acceleratore di siti web. + +Varnish riceve le richieste HTTP dai client: + +- se la risposta alla richiesta in cache è disponibile, restituisce la risposta direttamente al client dalla memoria del server, +- se non ha la risposta, Varnish si rivolge al server web. Varnish invia quindi la richiesta al server web, recupera la risposta, la memorizza nella sua cache e risponde al client. + +La risposta dalla cache in-memory migliora i tempi di risposta dei client. In questo caso, non c'è accesso ai dischi fisici. + +Per impostazione predefinita, Varnish ascolta sulla porta **6081** e utilizza **VCL** (**V**arnish **C**onfiguration **L**anguage) per la sua configurazione. Grazie a VCL, è possibile: + +- Decidere il contenuto che il client riceve tramite trasmissione +- Che cos'è il contenuto in cache +- Da quale sito e in che modo si verificano le modifiche della risposta? + +Varnish è estensibile con i moduli VMOD (Varnish Modules). + +#### Garantire l'high availability + +L'uso di diversi meccanismi garantisce l'high availability in tutta la catena web: + +- Se Varnish si trova dietro a Load Balancer (LB), sono già in modalità HA, poiché i LB sono generalmente in modalità cluster. Un controllo da parte dei LB verifica la disponibilità di Varnish. Se un server Varnish non risponde più, viene automaticamente rimosso dal pool di server disponibili. In questo caso, Varnish è in modalità ACTIVE/ACTIVE. +- Se il varnish non è dietro un cluster LB, i client si rivolgono a un VIP (vedere il capitolo Heartbeat) condiviso tra i due Varnish. In questo caso, varnish è in modalità ACTIVE/PASSIVE. Il VIP passa al secondo nodo Varnish se il server attivo non è disponibile. +- Quando un backend non è più disponibile, è possibile rimuoverlo dal pool di backend di Varnish, sia automaticamente (con un controllo dello stato health) sia manualmente in modalità CLI (utile per facilitare gli aggiornamenti). + +#### Assicurare la scalability + +Se i backend non sono più sufficienti a supportare il carico di lavoro: + +- o aggiungere più risorse ai backend e riconfigurare il middleware +- oppure aggiungere un altro backend al pool di backend di Varnish + +#### Agevolare la scalability + +Una pagina web è spesso composta da HTML (spesso generato dinamicamente da PHP) e da risorse più statiche (JPG, gif, CSS, js e così via) durante la creazione. Diventa subito interessante mettere in cache le risorse memorizzabili (quelle statiche), scaricando molte richieste dai backend. + +!!! NOTE "Nota" + +``` +Il caching delle pagine web (HTML, PHP, ASP, JSP, ecc.) è possibile ma più complicata. È necessario conoscere l'applicazione e sapere se le pagine sono memorizzabili nella cache, cosa che dovrebbe essere vera con un'API REST. +``` + +Quando un client accede direttamente a un server Web, il server deve restituire la stessa immagine tutte le volte che il client la richiede. Una volta che il client ha ricevuto l'immagine per la prima volta, questa viene memorizzata nella cache del browser, a seconda della configurazione del sito e dell'applicazione web. + +Quando si accede al server dietro un server di cache correttamente configurato, il primo client che richiede l'immagine inizierà una richiesta iniziale al backend. Tuttavia, la memorizzazione nella cache dell'immagine avverrà per un certo periodo di tempo e la consegna successiva sarà diretta ad altri client che richiedono la stessa risorsa. + +Sebbene una cache lato browser ben configurata riduca il numero di richieste al backend, essa integra l'uso di una cache proxy varnish. + +#### Gestione dei certificati TLS + +Varnish non può comunicare in HTTPS (e non è suo compito farlo). + +Il certificato deve quindi essere fornito con una delle seguenti opzioni: + +- trasportato dal LB quando il flusso lo attraversa (la soluzione consigliata è quella di centralizzare il certificato, ecc.). Il flusso passa quindi in modo non criptato attraverso il data center. +- da un servizio Apache, Nginx o HAProxy sul server varnish stesso, che agisce solo come proxy verso Varnish (dalla porta 443 alla porta 80). Questa soluzione è utile se si accede direttamente a Varnish. +- Allo stesso modo, Varnish non può comunicare con i backend sulla porta 443. Se necessario, è necessario utilizzare un reverse proxy Nginx o Apache per decifrare la richiesta per varnish. + +#### Come funziona + +In un servizio Web di base, il client comunica direttamente con il servizio tramite TCP sulla porta 80. + +![How a standard website works](img/varnish_website.png) + +Per utilizzare la cache, il client deve comunicare con il servizio web sulla porta predefinita 6081 di Varnish. + +![Come funziona Varnish di default](img/varnish_website_with_varnish.png) + +Per rendere il servizio trasparente al client, è necessario modificare la porta di ascolto predefinita per Varnish e i vhost del servizio web. + +![Implementazione trasparente per il cliente](img/varnish_website_with_varnish_port_80.png) + +Per fornire un servizio HTTPS, aggiungere un Load Balancer a monte del servizio Varnish o un servizio proxy sul server Varnish, come Apache, Nginx o HAProxy. + +### Configurazione + +L'installazione è semplice: + +```bash +dnf install -y varnish +systemctl enable varnish +systemctl start varnish +``` + +#### Configurare il servizio daemon di Varnish + +Da `systemctl`, i parametri di Varnish sono impostati grazie al file di servizio `/usr/lib/systemd/system/varnish.service`: + +```bash +[Unit] +Description=Varnish Cache, a high-performance HTTP accelerator +After=network-online.target + +[Service] +Type=forking +KillMode=process + +# Maximum number of open files (for ulimit -n) +LimitNOFILE=131072 + +# Locked shared memory - should suffice to lock the shared memory log +# (varnishd -l argument) +# Default log size is 80MB vsl + 1M vsm + header -> 82MB +# unit is bytes +LimitMEMLOCK=85983232 + +# Enable this to avoid "fork failed" on reload. +TasksMax=infinity + +# Maximum size of the corefile. +LimitCORE=infinity + +ExecStart=/usr/sbin/varnishd -a :6081 -f /etc/varnish/default.vcl -s malloc,256m +ExecReload=/usr/sbin/varnishreload + +[Install] +WantedBy=multi-user.target +``` + +Modificare i valori predefiniti con `systemctl edit varnish.service`: questo creerà il file `/etc/systemd/system/varnish.service.d/override.conf`: + +```bash +$ sudo systemctl edit varnish.service +[Service] +ExecStart=/usr/sbin/varnishd -a :6081 -f /etc/varnish/default.vcl -s malloc,512m +``` + +È possibile selezionare l'opzione più volte per specificare un backend di memorizzazione della cache. I tipi di memoria possibili sono `malloc` (cache in memoria, poi swap se necessario), o `file` (creare un file su disco, poi mappare in memoria). Le dimensioni sono espresse in K/M/G/T (kilobyte, megabyte, gigabyte o terabyte). + +#### Configurazione dei backend + +Varnish utilizza un linguaggio specifico chiamato VCL per la sua configurazione. + +Questo comporta la compilazione del file di configurazione VCL in C. Se la compilazione ha esito positivo e non ci sono allarmi, il servizio può essere riavviato. + +È possibile verificare la configurazione di Varnish con il seguente comando: + +```bash +varnishd -C -f /etc/varnish/default.vcl +``` + +!!! NOTE "Nota" + +``` +È consigliabile controllare la sintassi del VCL prima di riavviare il daemon `varnishd`. +``` + +Ricaricare la configurazione con il comando: + +```bash +systemctl reload varnishd +``` + +!!! warning "Attenzione" + +Un `systemctl restart varnishd` svuota la cache di varnish e causa un picco di carico sui backend. Si dovrebbe quindi evitare di ricaricare `varnishd`. + +!!! NOTE "Nota" + +``` +Per configurare Varnish, seguire le raccomandazioni riportate in questa pagina: . +``` + +### Linguaggio VCL + +#### Subroutine + +Varnish utilizza file VCL, segmentati in subroutine contenenti le azioni da eseguire. Queste subroutine vengono eseguite solo nei casi specifici che definiscono. Il file predefinito `/etc/varnish/default.vcl` contiene le routine `vcl_recv`, `vcl_backend_response` e `vcl_deliver`: + +```bash +# +# This is an example VCL file for Varnish. +# +# It does not do anything by default, delegating control to the +# builtin VCL. The builtin VCL is called when there is no explicit +# return statement. +# +# See the VCL chapters in the Users Guide at https://www.varnish-cache.org/docs/ +# and http://varnish-cache.org/trac/wiki/VCLExamples for more examples. + +# Marker to tell the VCL compiler that this VCL has been adapted to the +# new 4.0 format. +vcl 4.0; + +# Default backend definition. Set this to point to your content server. +backend default { + .host = "127.0.0.1"; + .port = "8080"; +} + +sub vcl_recv { + +} + +sub vcl_backend_response { + +} + +sub vcl_deliver { + +} +``` + +- **vcl_recv**: routine chiamata prima di inviare la richiesta al backend. In questa routine è possibile modificare le intestazioni HTTP e i cookie, scegliere il backend, ecc. Vedere le azioni `set req`. +- **vcl_backend_response**: routine chiamata dopo la ricezione della risposta del backend (`beresp` significa BackEnd RESPonse). Vedere le azioni `set bereq.` e `set beresp.`. +- **vcl_deliver**: Questa routine è utile per modificare l'output di Varnish. Se è necessario modificare l'oggetto finale (ad esempio, aggiungere o rimuovere un'intestazione), è possibile farlo in `vcl_deliver`. + +#### VCL operatori + +- `=`: assegnazione +- `==`: confronto +- `~`: confronto in combinazione con un'espressione regolare e ACL +- `!`: negazione +- `&&`: and logico +- `||`: or logico + +#### Oggetti di Varnish: + +- **req**: l'oggetto richiesta. Crea il `req` quando Varnish riceve la richiesta. La maggior parte del lavoro della subroutine `vcl_recv` riguarda questo oggetto. +- **bereq**: l'oggetto richiesta destinato al server web. Varnish crea questo oggetto da `req`. +- **beresp**: l'oggetto risposta del server web. Contiene le intestazioni degli oggetti dell'applicazione. È possibile modificare la risposta del server nella subroutine `vcl_backend_response`. +- **resp**: la risposta HTTP inviata al client. Modificare questo oggetto con la subroutine `vcl_deliver`. +- **obj**: l'oggetto memorizzato nella cache. Read-only. + +#### Azioni in Varnish + +Le azioni più frequenti: + +- **pass**: Quando fornita, la richiesta e la successiva risposta provengono dal server delle applicazioni. La cache non viene utilizzata. `pass` restituita dalla subroutine `vcl_recv`. +- **hash**: Quando viene restituito da `vcl_recv`, Varnish servirà il contenuto dalla cache anche se la configurazione della richiesta specifica il passaggio senza cache. +- **pipe**: Utilizzato per gestire i flussi. In questo caso, Varnish non ispezionerà più ogni richiesta, ma lascerà passare tutti i byte al server. Le websocket o la gestione dei flussi video, ad esempio, utilizzano `pipe`. +- **deliver**: Invia l'oggetto al client. Di solito dalla subroutine `vcl_backend_response`. +- **restart**: Riavvia il processo di elaborazione della richiesta. Mantiene le modifiche all'oggetto `req`. +- **retry**: Trasferisce la richiesta al server delle applicazioni. Utilizzato da `vcl_backend_response` o `vcl_backend_error` se la risposta dell'applicazione non è soddisfacente. + +In sintesi, il diagramma seguente illustra le possibili interazioni tra le subroutine e le azioni: + +![Implementazione trasparente per il cliente](img/varnish_interactions.png) + +### Verifica/Testing/Troubleshooting + +È possibile verificare che una pagina provenga dalla cache di Varnish dalle intestazioni della risposta HTTP: + +![Operazione varnish semplificata](img/varnish_troobleshooting.png) + +### Backends + +Varnish usa il termine `backend` per i vhost che deve proxyare. + +È possibile definire più backend sullo stesso server Varnish. + +La configurazione dei backend avviene tramite `/etc/varnish/default.vcl`. + +#### Gestione ACL + +```bash +# Deny ACL +acl deny { +"10.10.0.10"/32; +"192.168.1.0"/24; +} +``` + +Applicare ACL: + +```bash +# Block ACL deny IPs +if (client.ip ~ forbidden) { + error 403 "Access forbidden"; +} +``` + +Non memorizzare nella cache alcune pagine: + +```bash +# Do not cache login and admin pages +if (req.url ~ "/(login|admin)") { + return (pass); +} +``` + +#### Impostazioni POST e cookie + +Varnish non memorizza mai nella cache le richieste HTTP POST o le richieste contenenti cookie (sia dal client che dal backend). + +Se il backend utilizza i cookie, la cache dei contenuti non si verifica. + +Per correggere questo comportamento, è possibile disattivare i cookie nelle richieste: + +```bash +sub vcl_recv { + unset req.http.cookie; +} + +sub vcl_backend_response { + unset beresp.http.set-cookie; +} +``` + +#### Distribuire le richieste a diversi backend + +Quando si fa hosting di diversi siti, come un server di documenti () e un wiki (), è possibile distribuire le richieste al backend giusto. + +Dichiarazione dei backend: + +```bash +backend docs { + .host = "127.0.0.1"; + .port = "8080"; +} + +backend blog { + .host = "127.0.0.1"; + .port = "8081"; +} +``` + +La modifica dell'oggetto `req.backend` avviene in base all'host chiamato nella richiesta HTTP nella subroutine `vcl_recv`: + +```bash +sub vcl_recv { + if (req.http.host ~ "^doc.rockylinux.org$") { + set req.backend = docs; + } + + if (req.http.host ~ "^wiki.rockylinux.org$") { + set req.backend = wiki; + } +} +``` + +#### Distribuzione del carico + +Varnish può gestire il bilanciamento del carico con backend specifici chiamati directors. + +Il director del round-robin distribuisce le richieste ai backend del round-robin (alternativamente). È possibile assegnare un peso a ciascun backend. + +Il client director distribuisce le richieste in base a un sticky session affinity su qualsiasi elemento dell'intestazione (cioè con un cookie di sessione). Il client director distribuisce le richieste in base a uno sticky In questo caso, un client viene sempre rinviato allo stesso backend. + +Backends declaration + +```bash +backend docs1 { + .host = "192.168.1.10"; + .port = "8080"; +} + +backend docs2 { + .host = "192.168.1.11"; + .port = "8080"; +} +``` + +Il `director` consente di associare i 2 backend definiti. + +Director declaration: + +```bash +director docs_director round-robin { + { .backend = docs1; } + { .backend = docs2; } +} +``` + +Non resta che definire il director come backend delle richieste: + +```bash +sub vcl_recv { + set req.backend = docs_director; +} +``` + +#### Gestire i backends con CLI + +È possibile contrassegnare i backend come **sick** o **healthy** per scopi di amministrazione o manutenzione. Questa azione consente di rimuovere un nodo dal pool senza modificare la configurazione del server Varnish (senza riavviarlo) o arrestare il servizio backend. + +Visualizza lo stato dei backend: Il comando `backend.list` visualizza tutti i backend, anche quelli senza controllo dello stato di salute (probe). + +```bash +$ varnishadm backend.list +Backend name Admin Probe +site.default probe Healthy (no probe) +site.front01 probe Healthy 5/5 +site.front02 probe Healthy 5/5 +``` + +Passare da uno stato all'altro: + +```bash +varnishadm backend.set_health site.front01 sick + +varnishadm backend.list +Backend name Admin Probe +site.default probe Healthy (no probe) +site.front01 sick Sick 0/5 +site.front02 probe Healthy 5/5 + +varnishadm backend.set_health site.front01 healthy + +varnishadm backend.list +Backend name Admin Probe +site.default probe Healthy (no probe) +site.front01 probe Healthy 5/5 +site.front02 probe Healthy 5/5 +``` + +Per lasciare che sia Varnish a decidere lo stato dei suoi backend, è necessario commutare manualmente i backend in malati o sani e tornare alla modalità automatica. + +```bash +varnishadm backend.set_health site.front01 auto +``` + +La dichiarazione dei backend avviene come segue: . + +### Logs Apache + +Poiché il servizio HTTP viene sottoposto a reverse proxy, il server web non avrà più accesso all'indirizzo IP del cliente, ma al servizio Varnish. + +Per tenere conto del reverse proxy nei log Apache, modificare il formato del log degli eventi nel file di configurazione del server: + +```bash +LogFormat "%{X-Forwarded-For}i %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i"" varnishcombined +``` + +e tenere conto di questo nuovo formato nel vhost del sito web: + +```bash +CustomLog /var/log/httpd/www-access.log.formatux.fr varnishcombined +``` + +e renderlo compatibile con Varnish: + +```bash +if (req.restarts == 0) { + if (req.http.x-forwarded-for) { + set req.http.X-Forwarded-For = req.http.X-Forwarded-For + ", " + client.ip; + } else { + set req.http.X-Forwarded-For = client.ip; + } +} +``` + +### Pulizia della Cache + +Alcune richieste di svuotamento della cache: + +a linea di comando: + +```bash +arnishadm 'ban req.url ~ .' +``` + +utilizzando un secret e una porta diversa da quella predefinita: + +```bash +varnishadm -S /etc/varnish/secret -T 127.0.0.1:6082 'ban req.url ~ .' +``` + +con il CLI: + +```bash +varnishadm + +varnish> ban req.url ~ ".css$" +200 + +varnish> ban req.http.host == example.com +200 + +varnish> ban req.http.host ~ . +200 +``` + +tramite una richiesta HTTP PURGE: + +```bash +curl -X PURGE http://example.com/foo.txt +``` + +La configurazione di Varnish per accettare questa richiesta si effettua con: + +```bash +acl local { + "localhost"; + "10.10.1.50"; +} + +sub vcl_recv { + # directive to be placed first, + # otherwise another directive may match first + # and the purge will never be performed + if (req.method == "PURGE") { + if (client.ip ~ local) { + return(purge); + } + } +} +``` + +### Gestione del log + +Varnish scrive i suoi log in memoria e in binario per non penalizzare le sue prestazioni. Quando esaurisce lo spazio di memoria, riscrive i nuovi record sopra quelli vecchi, partendo dall'inizio del suo spazio di memoria. + +È possibile consultare i log con gli strumenti `varnishstat` (statistiche), `varnishtop` (top per Varnish), `varnishlog` (verbose logging) o `varnishnsca` (log in formato NCSA, come Apache): + +```bash +varnishstat +varnishtop -i ReqURL +varnishlog +varnishnsca +``` + +L'utilizzo dell'opzione \`-q' per applicare i filtri ai registri si effettua utilizzando: + +```bash +varnishlog -q 'TxHeader eq MISS' -q "ReqHeader ~ '^Host: rockylinux\.org$'" +varnishncsa -q "ReqHeader eq 'X-Cache: MISS'" +``` + +I demoni `varnishlog` e `varnishnsca` registrano i log su disco indipendentemente dal daemon `varnishd`. Il daemon `varnishd` continua a popolare i suoi registri in memoria senza penalizzare le prestazioni dei client; quindi, gli altri demoni copiano i registri su disco. + +### Workshop + +Per questo workshop è necessario un server con i servizi Apache installati, configurati e protetti, come descritto nei capitoli precedenti. + +Si configurerà una cache reverse proxy davanti ad essa. + +Il server ha i seguenti indirizzi IP: + +- server1: 192.168.1.10 + +Se non si dispone di un servizio di risoluzione dei nomi, inserire nel file `/etc/hosts` un contenuto simile al seguente: + +```bash +$ cat /etc/hosts +127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 +::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 + +192.168.1.10 server1 server1.rockylinux.lan +``` + +#### Task 1: Installazione e configurazione di Apache + +```bash +sudo dnf install -y httpd mod_ssl +sudo systemctl enable httpd --now +sudo firewall-cmd --permanent --add-service=http +sudo firewall-cmd --permanent --add-service=https +sudo firewall-cmd --reload +echo "Node $(hostname -f)" | sudo tee "/var/www/html/index.html" +``` + +Verifica: + +```bash +$ curl http://server1.rockylinux.lan +Node server1.rockylinux.lan + +$ curl -I http://server1.rockylinux.lan +HTTP/1.1 200 OK +Date: Mon, 12 Aug 2024 13:16:18 GMT +Server: Apache/2.4.57 (Rocky Linux) OpenSSL/3.0.7 +Last-Modified: Mon, 12 Aug 2024 13:11:54 GMT +ETag: "36-61f7c3ca9f29c" +Accept-Ranges: bytes +Content-Length: 54 +Content-Type: text/html; charset=UTF-8 +``` + +#### Task 2: Installare Varnish + +```bash +sudo dnf install -y varnish +sudo systemctl enable varnishd --now +sudo firewall-cmd --permanent --add-port=6081/tcp --permanent +sudo firewall-cmd --reload +``` + +#### Task 3: Configurare Apache come backend + +Modificare `/etc/varnish/default.vcl` per usare apache (porta 80) come backend: + +```bash +# Default backend definition. Set this to point to your content server. +backend default { + .host = "127.0.0.1"; + .port = "80"; +} +``` + +Riavviare Varnish + +```bash +sudo systemctl reload varnish +``` + +Controllare se la Varnish funziona: + +```bash +$ curl -I http://server1.rockylinux.lan:6081 +HTTP/1.1 200 OK +Server: Apache/2.4.57 (Rocky Linux) OpenSSL/3.0.7 +X-Varnish: 32770 6 +Age: 8 +Via: 1.1 varnish (Varnish/6.6) + +$ curl http://server1.rockylinux.lan:6081 +Node server1.rockylinux.lan +``` + +Come si può vedere, Apache serve la pagina di index. + +Sono state aggiunte alcune headers, che ci informano che la nostra richiesta è stata gestita da varnish (header `Via`) e il tempo di cache della pagina (intestazione `Age`), che ci dice che la nostra pagina è stata servita direttamente dalla memoria di varnish invece che dal disco con Apache. + +#### Task 4: Rimuovare alcuni headers + +Rimuoveremo alcuni headers che possono fornire informazioni non necessarie agli hacker. + +Nella sottoparte `vcl_deliver`, aggiungere quanto segue: + +```bash +sub vcl_deliver { + unset resp.http.Server; + unset resp.http.X-Varnish; + unset resp.http.Via; + set resp.http.node = "F01"; + set resp.http.X-Cache-Hits = obj.hits; + if (obj.hits > 0) { # Add debug header to see if it is a HIT/MISS and the number of hits, disable when not needed + set resp.http.X-Cache = "HIT"; + } else { + set resp.http.X-Cache = "MISS"; + } +} +``` + +Verificare la configurazione e ricaricare varnish: + +```bash +$ sudo varnishd -C -f /etc/varnish/default.vcl +... +$ sudo systemctl reload varnish +``` + +Controlla le differenze: + +```bash +$ curl -I http://server1.rockylinux.lan:6081 +HTTP/1.1 200 OK +Age: 4 +node: F01 +X-Cache-Hits: 1 +X-Cache: HIT +Accept-Ranges: bytes +Connection: keep-alive +``` + +Come si può vedere, la rimozione delle intestazioni indesiderate avviene mentre si aggiungono quelle necessarie (per la risoluzione dei problemi). + +### Conclusione + +Ora avete tutte le conoscenze necessarie per impostare un server cache primario e aggiungere funzionalità. + +Avere un server Varnish nella propria infrastruttura può essere molto utile per molte cose oltre alla cache: per la sicurezza del server backend, per la gestione delle intestazioni, per facilitare gli aggiornamenti (modalità blu/verde o canary, per esempio), ecc. + +### Verificare le proprie Conoscenze + +:heavy_check_mark: Varnish può ospitare file statici? + +- [ ] Vero +- [ ] Falso + +:heavy_check_mark: La cache di varnish deve essere memorizzata? + +- [ ] Vero +- [ ] Falso diff --git a/docs/books/web_services/053-load-balancer-proxies-squid.it.md b/docs/books/web_services/053-load-balancer-proxies-squid.it.md new file mode 100644 index 0000000000..360e606a2c --- /dev/null +++ b/docs/books/web_services/053-load-balancer-proxies-squid.it.md @@ -0,0 +1,568 @@ +--- +author: Antoine Le Morvan +contributors: Ganna Zhyrnova +title: Part 5.3 Squid +tags: + - squid + - proxy + - http +--- + +## Squid + +Questo capitolo illustra Squid, la cache proxy HTTP. + +**** + +**Obiettivi**: si imparerà come: + +:heavy_check_mark: installare squid\ +:heavy_check_mark: configurarlo come un proxy e memorizzare il contenuto HTTP. + +:checkered_flag: **squid**, **proxy**, **HTTP** + +**Competenze**: :star: :star:\ +**Complessità**: :star: :star: + +**Tempo di lettura**: 20 minuti + +**** + +### Generalità + +L'impostazione di un server proxy comporta la scelta tra due tipi di architettura: + +- Un'architettura proxy standard che richiede una configurazione specifica di ogni client e dei loro browser web +- Architettura captive proxy, che prevede l'intercettazione dei frame inviati dal client e la loro riscrittura al server proxy + +In entrambi i casi, si verifica un'interruzione della rete: Un client non può più collegarsi fisicamente a un server remoto direttamente senza passare attraverso un server proxy. + +Due firewall proteggono la workstation client ma non comunicano mai direttamente con la rete esterna. + +![Proxy-based architecture](img/squid-architecture-proxy.png) + +!!! Note "Nota" + +``` +Questa architettura richiede la configurazione del browser sulla workstation client. +``` + +Non è necessario configurare tutte le workstation client con un captive proxy. + +La configurazione avviene a livello del gateway, che riceve le richieste dei client e riscrive in modo trasparente i frame per inviarli al proxy. + +![Captive proxy-based architecture](img/squid-architecture-proxy-captif.png) + +!!! Note "Nota" + +``` +Questa architettura richiede una configurazione specifica sul router. +``` + +Nel caso di un'architettura proxy standard o captive proxy, uno degli interessi principali di questo tipo di servizio è quello di fungere da cache. + +In questo modo, un file scaricato una volta dalla WAN (potenzialmente da un collegamento più lento della LAN) si memorizza nella cache del proxy per essere utilizzato dai client successivi. In questo modo si ottimizza la larghezza di banda sul collegamento più lento. + +Come si vedrà in seguito, esistono altri usi del proxy. + +L'implementazione di un proxy può: + +- Negare l'accesso a risorse specifiche in base a vari parametri. +- Impostare l'autenticazione e il monitoraggio delle attività Internet dei client. +- Impostare una gerarchia di cache distribuite +- Nascondere l'architettura della LAN da un punto di vista WAN (quanti client ci sono sulla LAN?) + +Tra i vantaggi vi sono i seguenti: + +- Anonimato su Internet +- Autenticazione +- Registrazione dell'attività del Client +- Applicazione di filtri +- Restrizioni di accesso +- Ottimizzazione della larghezza di banda +- Controllo Sicurezza + +!!! Note "Nota" + +``` +L'implementazione dell'autenticazione blocca molti degli effetti dannosi dei virus sulla LAN. +``` + +!!! warning "Attenzione" + +``` +Il servizio proxy diventa un servizio critico che richiede High Availability +``` + +Quando si utilizza un server Squid Proxy, l'amministratore deve sfruttare i registri. Pertanto, è essenziale conoscere i principali codici di risposta HTTP. + +| Codice | Categorie | +| ------ | ---------------------- | +| 1XX | Info | +| 2XX | Success | +| 3XX | Redirection | +| 4XX | Customer request error | +| 5XX | Server error | + +Esempi: + +- 200: ok +- 301: Trasferito definitivamente +- 302: Trasferito temporaneamente +- 304: Non modificato +- 400: Bad request +- 401: Non autorizzato +- 404: Not trovato + +#### Informazioni su Squid + +Squid supporta i protocolli HTTP e FTP. + +I vantaggi dell'installazione di una soluzione basata sul server Squid: + +- Soluzioni hardware sono costose +- Sviluppato dal 1996 +- Rilasciato sotto licenza GNU/GPL + +##### Dimensionamento + +- Assicurare l'High Availability +- Utilizzo di dispositivi di storage veloci per la cache +- La RAM e la CPU devono essere dimensionate correttamente + +!!! Note "Nota" + +``` +Consentire 14 MB di RAM per ogni GB di cache del disco. +``` + +### Installazione + +Installazione del package `squid` + +```bash +sudo dnf install squid +``` + +!!! warning "Attenzione" + +``` +Fare attenzione a non avviare il servizio prima che la cache sia stata inizializzata! +``` + +#### Il tree e i file del server Squid + +Il singolo file di configurazione è `/etc/squid/squid.conf`. + +I log del servizio (arresto e riavvio) sono in `/var/log/squid.cache.log`, mentre le richieste dei client sono in `/var/log/squid/access.log`. Per impostazione predefinita, i file della cache si trovano in `/var/spool/squid/`. + +#### Il comando `squid` + +Il comando `squid` controlla il server squid. + +Sintassi del commando: + +```bash +squid [-z|-s|-k parse|-k rotate] +``` + +| Opzione | Descrizione | +| ----------- | ------------------------------- | +| `-z` | Inizializza la directory cache | +| `-s` | Abilita il log di syslog | +| `-k parse` | Testa il file di configurazione | +| `-k rotate` | Turnazione dei file di log | + +Il Logging delle richieste dei client può portare rapidamente alla archiviazione di grandi quantità di dati. + +È buona norma creare regolarmente un nuovo file di log e archiviare quello vecchio in formato compresso. + +È possibile farlo manualmente, con l'opzione `-k rotate` del comando `squid`, oppure automaticamente con il servizio Linux dedicato `logrotate`. + +### Configurazione + +Configurare Squid su `/etc/squid/squid.conf`. + +- `http_port` configura la porta del proxy (porta di ascolto) + +```bash +http_port num_port +``` + +!!! Note "Nota" + +``` +La porta è impostata di default su 3128, ma spesso viene modificato in 8080. Ricordarsi di aprire la porta corrispondente del firewall! +``` + +Al riavvio del servizio, il server Squid si metterà in ascolto sulla porta definita dalla directive `http_port`. + +- `cache_mem` definisce la RAM riservata + +```bash +cache_mem taille KB|taille MB|taille GB +``` + +Per esempio: + +```bash +cache_mem 1 GB +``` + +!!! Tip "Suggerimento" + +``` +Best practice: allocare 1/3 della RAM totale +``` + +- Internet Cache Protocol (ICP) `icp_port` + +L' Internet Cache Protocol (ICP) consente ai server Squid vicini di scambiarsi le richieste. È prassi comune proporre una gerarchia di proxy che condividono le loro basi informative. + +La direttiva `icp_port` definisce la porta che Squid utilizza per inviare e ricevere richieste ICP dai server Squid vicini. + +!!! Tip "Suggerimento" + +``` +Impostare a 0 per disattivarlo. +``` + +- L'utente anonimo FTP `ftp_user` + +La direttiva `ftp_user` associa un utente FTP alle connessioni FTP anonime. L'utente deve avere un indirizzo e-mail valido. + +```bash +ftp_user bob@rockylinux.lan +``` + +- Impostare le liste di controllo degli accessi + +Sintassi ACL: + +```bash +acl name type argument +http_access allow|deny aclname +``` + +Esempio: + +```bash +acl LUNCHTIME time 12:00-14:00 +http_access deny LUNCHTIME +``` + +Una trattazione più approfondita delle ACL è contenuta nella sezione “Configurazione avanzata”. + +- Dimensione massima di un oggetto memorizzato nella cache `maximum_object_size` + +Sintassi della direttiva `maximum_object_size`: + +```bash +maximum_object_size size +``` + +Esempio: + +```bash +maximum_object_size 32 MB +``` + +L'oggetto non viene memorizzato nella cache se la dimensione dell'oggetto è superiore al limite `maximum_object_size`. + +- Nome del server proxy `visible_hostname` + +Sintassi della direttiva `visible_hostname`: + +```bash +visible_hostname name +``` + +Esempio: + +```bash +visible_hostname proxysquid +``` + +!!! Note "Nota" + +``` +Il valore fornito può essere diverso dal nome dell'host. +``` + +- Definire una cache per Squid `cache_ufs` + +```bash +cache_ufs format path size nbFolderNiv1 nbFolderNiv2 +``` + +È possibile definire più cache su file system diversi per ottimizzare i tempi di accesso. + +Esempio: + +```bash +cache_dir ufs /var/spool/squid/ 100 16 256 +``` + +| Opzione | Descrizione | +| ------- | ------------------------ | +| ufs | Unix File System | +| 100 | Dimensioni in Mega | +| 16 | 16 top-level folders | +| 256 | 256 second-level folders | + +Quando il servizio viene lanciato per la prima volta, genera la directory della cache: + +```bash +sudo squid -z +sudo systemctl start squid +``` + +### Configurazione avanzata + +#### La Lista di Controllo Accessi (ACL) + +Sintassi della direttiva 'http_access' + +```bash +http_access allow|deny [!]acl_name +``` + +Esempio: + +```bash +http_access allow LUNCHTIME +http_access deny !LUNCHTIME +``` + +La negazione di ACL `!acl_name' significa l'opposto di ACL `acl_name\`. + +Sintassi della direttiva 'acl': + +```bash +acl name type argument +``` + +L'ordine delle ACL è cumulativo. Più ACL con lo stesso nome rappresentano una singola ACL. + +Esempi: + +Autorizzazione LUNCHTIME + +```bash +acl LUNCHTIME time 12:00-14:00 +http_access allow LUNCHTIME +``` + +Proibire VIDEOS: + +```bash +acl VIDEOS rep_mime_type video/mpeg +acl VIDEOS rep_mime_type video/avi +http_access deny VIDEOS +``` + +Gestire indirizzi IP: + +```bash +acl XXX src 192.168.0.0/255.255.255.0 +acl XXX dst 10.10.10.1 +``` + +Gestione di FQDN: + +```bash +acl XXX srcdomain .rockylinux.org +acl XXX dstdomain .linux.org +``` + +Gestione delle porte: + +```bash +acl XXX port 80 21 +``` + +Gestire protocolli: + +```bash +acl XXX proto HTTP FTP +``` + +#### Algoritmi di cache + +Esistono diversi algoritmi di cache con caratteristiche differenti: + +- LRU - _Least Recently Used_: rimuove dalla RAM gli oggetti più vecchi. +- LRU-THOLD: copia un oggetto nella cache in base alla sua dimensione. +- MRU: _Most Recently Used_: cancella i dati meno richiesti. +- GDSF: _Greedy Dual Size Frequency_: cancella in base alla dimensione originale e al tempo di accesso conservando quelli più leggeri. +- LFUDA: _Least Frequently Used With Dynamic Aging_: come GDSF, ma senza la nozione della dimensione. Utile per memorizzare in cache in presenza di file molto grandi. + +#### Autenticazione del Client + +Squid si affida a programmi esterni per gestire l'autenticazione. Può essere basato su un semplice file piatto come `htpasswd` o su LDAP, SMB, PAM o altri servizi. + +L'autenticazione può anche essere una necessità legale. Ricordatevi di far firmare agli utenti una carta d'uso! + +### Tools + +#### Il comando `squidclient` + +Usare il comando `squidclient` per testare una richiesta al server squid. + +Sintassi del comando `squidclient`: + +```bash +squidclient [-s] [-h target] [-p port] url +``` + +Esempio: + +```bash +squidclient -s -h localhost -p 8080 http://localhost/ +``` + +| Opzione | Descrizione | +| ------- | ------------------------------------------------------------------- | +| `-s` | Modalità silenziosa (Non mostra nulla a console) | +| `-h` | Definisce il proxy target | +| `-p` | In ascolto sulla porta (default 3128) | +| `-r` | Forza il server a ricaricare l'oggetto | + +#### Analizzare logs + +È possibile monitorare i record del log di Squid con il comando: + +```bash +tail -f /var/log/squid/access.log +``` + +Scomposizione di un record di log: + +| Opzione | Descrizione | +| -------------------- | ------------------------------------------------------------------------ | +| Date | Data e Ora di registrazione del log | +| Response time | Il tempo di risposta alla richiesta | +| @client | Indirizzo IP del client | +| Status code | Codice di risposta HTTP | +| Size | Dimensione di trasferimento | +| Metodo | Metodo HTTP (Put / Get / Post / ecc.) | +| URL | URL Richiesta | +| Peer Code | Codice di risposta interproxy | +| File type | Tipo di mime della richiesta di destinazione | + +### Sicurezza + +Il firewall deve essere aperto per la porta di ascolto: + +```bash +sudo firewall-cmd --add-port=3128/tcp --permanent +sudo firewall-cmd --reload +``` + +### Workshop + +In questo workshop, si installerà Squid sul vostro server e lo userete per scaricare gli aggiornamenti. + +#### Task 1: Installare e configurare + +Installazione di Squid: + +```bash +sudo dnf install squid +sudo systemctl enable squid +sudo firewall-cmd --add-port=3128/tcp --permanent +sudo firewall-cmd --reload +``` + +Rimuovere il commento in questa riga del file \`/etc/squid/squid.conf' per creare una directory di cache su disco: + +```bash +cache_dir ufs /var/spool/squid 100 16 512 +``` + +Regolare la dimensione della cache come richiesto. + +Creare le directory della cache e avviare il servizio + +```bash +sudo squid -z +sudo systemctl start squid +``` + +#### Compito 2: utilizzare il proxy con curl + +Aprire un nuovo terminale sul server proxy per seguire l'accesso del proxy. + +```bash +sudo tail -f /var/log/squid/access.log +``` + +Sul secondo terminale, utilizzare `curl` per accedere a una pagina web attraverso il proxy: + +```bash +$ curl -I --proxy "http://192.168.1.10:3128" https://docs.rockylinux.org +HTTP/1.1 200 Connection established + +HTTP/2 200 +content-type: text/html +... +``` + +Come si può vedere, esistono due connessioni HTTP. Il primo è con il proxy e il secondo è dal proxy al server remoto. + +È possibile vedere la traccia sul secondo terminale: + +```bash +1723793294.548 77 192.168.1.10 TCP_TUNNEL/200 3725 CONNECT docs.rockylinux.org:443 - HIER_DIRECT/151.101.122.132 - +``` + +Il contenuto non viene memorizzato nella cache, poiché si richiede una connessione `https` al server remoto. + +#### Task 3: Configurare il DNS per utilizzare il server proxy + +Modificare il file \`/etc/dnf/dnf.conf' per utilizzare il proxy squid: + +```bash +[main] +gpgcheck=1 +installonly_limit=3 +clean_requirements_on_remove=True +best=True +skip_if_unavailable=False +proxy=http://192.168.1.10:3128 +``` + +Pulire la cache di `dnf` e provare ad aggiornare: + +```bash +sudo dnf clean all +sudo dnf update +``` + +Verificare sul terminale che la connessione `dnf` utilizzi il proxy per scaricare l'aggiornamento. Si noti che l'“URL del repository” nella riga che segue sarà sostituito con l'URL effettivo del mirror: + +```bash +1723793986.725 20 192.168.1.10 TCP_MISS/200 5238 GET "URL of repository"/9.4/extras/x86_64/os/repodata/7d78a729-8e9a-4066-96d4-ab8ed8f06ee8-FILELISTS.xml.gz - HIER_DIRECT/193.106.119.144 application/x-gzip +... +1723794176.255 1 192.168.1.10 TCP_HIT/200 655447 GET "URL of repository"/9.4/AppStream/x86_64/os/repodata/1af312c9-7139-43ed-8761-90ba3cd55461-UPDATEINFO.xml.gz - HIER_NONE/- application/x-gzip +``` + +In questo esempio, si può notare una connessione con TCP_MISS (non presente nella cache) e un'altra con TCP_HIT (utilizza la cache per rispondere al client). + +### Conclusione + +Ora sapete come installare Squid sulla vostra rete locale. Questo vi permetterà di centralizzare le connessioni in uscita verso Internet e di proteggere la vostra rete locale. + +### Verificare le proprie Conoscenze + +:heavy_check_mark: Qual è la porta ascoltata da un server squid per impostazione predefinita? + +- [ ] 8080 +- [ ] 1234 +- [ ] 443 +- [ ] 3128 + +:heavy_check_mark: Che cos'è Squid? + +- [ ] Un cache reverse proxy +- [ ] Un cache proxy diff --git a/docs/guides/automation/templates-automation-packer-vsphere.fr.md b/docs/guides/automation/templates-automation-packer-vsphere.fr.md index 37ab1a70bf..fa11817b9c 100644 --- a/docs/guides/automation/templates-automation-packer-vsphere.fr.md +++ b/docs/guides/automation/templates-automation-packer-vsphere.fr.md @@ -525,7 +525,7 @@ logvol / --fstype="xfs" --size=10240 --name=lv_root --vgname=vg_root logvol swap --fstype="swap" --size=4092 --name=lv_swap --vgname=vg_root ``` -The next section concerns the packages that will be installed. Une « bonne pratique » consiste à limiter la quantité de packages installés à ceux dont vous avez besoin, ce qui limite la surface d'attaque, en particulier dans un environnement serveur. +La section suivante concerne les packages qui seront installés. Une « bonne pratique » consiste à limiter la quantité de packages installés à ceux dont vous avez besoin, ce qui limite la surface d'attaque, en particulier dans un environnement serveur. !!! note "Remarque" diff --git a/docs/guides/containers/podman_guide.uk.md b/docs/guides/containers/podman_guide.uk.md index 02b8c4a47a..b5813bea7f 100644 --- a/docs/guides/containers/podman_guide.uk.md +++ b/docs/guides/containers/podman_guide.uk.md @@ -136,7 +136,7 @@ podman run -d -p 8080:80 nextcloud - `/etc/containers/systemd/users/$(UID)` - `/etc/containers/systemd/users/` -Окрім окремих контейнерів, підтримуються файли pod, image, network, volume і kube. Давайте зосередимося на нашому прикладі Nextcloud. Створіть новий файл ~/.config/containers/systemd/nextcloud.cotainer із таким вмістом: +Окрім окремих контейнерів, підтримуються файли pod, image, network, volume і kube. Давайте зосередимося на нашому прикладі Nextcloud. Створіть новий файл `~/.config/containers/systemd/nextcloud.container` з таким вмістом: ```systemd [Container] diff --git a/docs/guides/contribute/localdocs/rockydocs_webdev_v2.uk.md b/docs/guides/contribute/localdocs/rockydocs_webdev_v2.uk.md index fed18b690e..7e61970c0b 100644 --- a/docs/guides/contribute/localdocs/rockydocs_webdev_v2.uk.md +++ b/docs/guides/contribute/localdocs/rockydocs_webdev_v2.uk.md @@ -5,9 +5,13 @@ contributors: Ganna Zhyrnova update: 13 лютого 2023 р --- +!!! warning "Можливість збою!" + + Люди, які намагалися створити нещодавні збірки за допомогою цієї процедури, повідомляли про невдачі. Продовжуйте на свій страх і ризик. Ймовірно, у майбутньому цю процедуру буде оновлено або архівовано. + # Запуск веб-сайту docs.rockylinux.org локально для веб-розробки | Podman -У цьому документі описано, як відтворити та запустити локальну копію всього веб-сайту docs.rockylinux.org на вашій локальній машині. Запуск локальної копії веб-сайту документації може бути корисним у таких випадках: +Цей документ допоможе вам створити та запустити локальну копію всього веб-сайту docs.rockylinux.org на вашій локальній машині. Запуск локальної копії веб-сайту документації може бути корисним у таких випадках: - Вам цікаво дізнатися про аспекти веб-розробки веб-сайту docs.rockylinux.org і зробити свій внесок у них - Ви автор і хотіли б побачити, як ваші документи відображатимуться/виглядатимуть на веб-сайті документів, перш ніж надсилати їх @@ -64,7 +68,7 @@ sudo chmod 666 /var/run/docker.sock git clone https://github.com/rocky-linux/docs.rockylinux.org.git ``` -Тепер у вас буде папка `$ROCKYDOCS/docs.rockylinux.org`. У цій папці ви можете експериментувати зі своїми внесками в веб-розробку. +Тепер у вас є папка `$ROCKYDOCS/docs.rockylinux.org`. У цій папці ви можете експериментувати зі своїми внесками в веб-розробку. ## Створіть і запустіть середовище веб-розробки RockyDocs diff --git a/docs/guides/dns/nsd_authoritative_dns.fr.md b/docs/guides/dns/nsd_authoritative_dns.fr.md index e925b66d6f..9c1e2940e4 100644 --- a/docs/guides/dns/nsd_authoritative_dns.fr.md +++ b/docs/guides/dns/nsd_authoritative_dns.fr.md @@ -117,7 +117,7 @@ example.com mail is handled by 10 mail.another.com. ## Serveur DNS secondaire -Il est généralement courant d’exécuter un ou plusieurs serveurs DNS secondaires faisant autorité au cas où le serveur principal tomberait en panne. NSD dispose d'une fonctionnalité qui permet la synchronisation des enregistrements DNS d'un serveur principal vers un ou plusieurs serveurs de sauvegarde. +L’exécution d’un ou plusieurs serveurs DNS secondaires faisant autorité est généralement la norme. Ceci est particulièrement utile lorsque le serveur principal tombe en panne. `NSD` possède une fonctionnalité permettant de synchroniser les enregistrements DNS d'un serveur principal vers un ou plusieurs serveurs de sauvegarde. Pour activer un serveur de sauvegarde, générez les clés de signature sur la zone primaire : @@ -193,6 +193,6 @@ Remplacez `NS2_IP2` par les adresses IP publiques du serveur de noms secondaire. ## Conclusion -La plupart des gens utilisent des services tiers pour le DNS. Cependant, il existe des scénarios dans lesquels l'auto-hébergement DNS est souhaitable. Les sociétés de télécommunications, d’hébergement et de médias sociaux, par exemple, hébergent de nombreuses entrées DNS dans lesquelles les services hébergés ne sont pas souhaitables voire indésirables. +La plupart des gens utilisent des services tiers pour le `DNS`. Cependant, il existe des scénarios dans lesquels l'auto-hébergement `DNS` est souhaitable. Les sociétés de télécommunications, d’hébergement et de médias sociaux, par exemple, hébergent de nombreuses entrées DNS dans lesquelles les services hébergés ne sont pas souhaitables voire indésirables. NSD est l’un des nombreux outils open source qui rendent possible l’hébergement DNS. diff --git a/docs/guides/dns/nsd_authoritative_dns.uk.md b/docs/guides/dns/nsd_authoritative_dns.uk.md index bbed0f9f06..0ed9f80dfd 100644 --- a/docs/guides/dns/nsd_authoritative_dns.uk.md +++ b/docs/guides/dns/nsd_authoritative_dns.uk.md @@ -115,8 +115,84 @@ example.com mail is handled by 10 mail.another.com. % ``` +## Вторинний сервер DNS + +Запуск одного або кількох вторинних авторитетних DNS-серверів зазвичай є нормою, якщо основний сервер вийде з ладу. NSD має функцію, яка дозволяє синхронізувати записи DNS з основного сервера на один або кілька резервних серверів. + +Щоб увімкнути резервний сервер, згенеруйте ключі підпису в основній зоні: + +```bash +nsd-control-setup +``` + +Вам потрібно буде скопіювати наступні файли на сервер резервного копіювання в каталог `/etc/nsd/`: + +- `nsd_control.key` +- `nsd_control.pem` +- `nsd_server.key` +- `nsd_server.pem` + +На всіх DNS-серверах додайте наступне перед директивою `zone:`: + +```bash +remote-control: + control-enable: yes + control-interface: 0.0.0.0 + control-port: 8952 + server-key-file: "/etc/nsd/nsd_server.key" + server-cert-file: "/etc/nsd/nsd_server.pem" + control-key-file: "/etc/nsd/nsd_control.key" + control-cert-file: "/etc/nsd/nsd_control.pem" +``` + +Також увімкніть записи брандмауера: + +```bash +firewall-cmd --zone=public --add-port=8952/tcp +firewall-cmd --runtime-to-permanent +``` + +На основному сервері змініть зону так, щоб вона відповідала наступному: + +```bash +zone: + name: example.com + zonefile: /etc/nsd/example.com.zone + allow-notify: NS2_IP NOKEY + provide-xfr: NS2_IP NOKEY + outgoing-interface: NS1_IP +``` + +Замініть `NS1_IP1` і `NS2_IP2` загальнодоступними IP-адресами основного та додаткового серверів імен. + +На вторинному сервері додайте зону: + +```bash +zone: + name: fourplex.net + notify: NS1_IP NOKEY + request-xfr: NS1_IP NOKEY + outgoing-interface: NS2_IP +``` + +Замініть `NS1_IP1` і `NS2_IP2` загальнодоступними IP-адресами основного та додаткового серверів імен. + +Перезапустіть NSD на обох серверах імен: + +```bash +NS1# systemctl restart --now nsd +``` + +Щоб завантажити файл зони на вторинний сервер імен з основного: + +```bash +nsd-control notify -s NS2_IP +``` + +Замініть `NS2_IP2` загальнодоступними IP-адресами вторинного сервера імен. + ## Висновок -Більшість людей використовують сторонні служби для DNS. Однак є сценарії, коли бажано самостійно розмістити DNS. Наприклад, телекомунікаційні, хостингові та соціальні медіа компанії розміщують багато записів DNS, де розміщені послуги є небажаними. +Більшість людей використовують сторонні служби для DNS. Однак є сценарії, коли бажано самостійно розміщувати DNS. Наприклад, телекомунікаційні, хостингові та соціальні медіа компанії розміщують багато записів DNS, де розміщені послуги є небажаними. -NSD є одним із багатьох інструментів з відкритим кодом, які роблять можливим розміщення DNS. Вітаємо, у вас є власний DNS-сервер! +NSD є одним із багатьох інструментів з відкритим кодом, які роблять можливим розміщення DNS. diff --git a/docs/guides/interoperability/import_rocky_to_wsl.uk.md b/docs/guides/interoperability/import_rocky_to_wsl.uk.md index 1c0b8fe8bb..0fc368c7f0 100644 --- a/docs/guides/interoperability/import_rocky_to_wsl.uk.md +++ b/docs/guides/interoperability/import_rocky_to_wsl.uk.md @@ -15,7 +15,7 @@ tags: Необхідно ввімкнути функцію Windows-Subsystem для Linux. Це можливо за допомогою одного з цих варіантів: -- Оскільки незабаром [нова версія WSL доступна в Microsoft Store](https://apps.microsoft.com/store/detail/windows-subsystem-for-linux/9P9TQF7MRM4R), який має більше функцій, використовуйте це, якщо можливо +- [Новіша версія WSL із додатковими функціями доступна в Microsoft Store](https://apps.microsoft.com/store/detail/windows-subsystem-for-linux/9P9TQF7MRM4R). Використовуйте цю новішу версію, коли це можливо. - Відкрийте адміністративний термінал (PowerShell або Command-Prompt) і запустіть `wsl --install` ([посил.](https://docs.microsoft.com/en-us/windows/wsl/install)) - Перейдіть до графічних налаштувань Windows і ввімкніть додаткову функцію `Підсистема Windows для Linux` @@ -26,12 +26,8 @@ tags: 1. Отримайте контейнер rootfs. Це можливо кількома способами: - **Бажано:** Завантажте зображення з CDN: - - 8: [Base x86_64](https://dl.rockylinux.org/pub/rocky/8/images/x86_64/Rocky-8-Container-Base.latest.x86_64.tar.xz), [Minimal x86_64](https://dl.rockylinux.org/pub/rocky/8/images/x86_64/Rocky-8-Container-Minimal.latest.x86_64.tar.xz), [UBI x86_64](https://dl.rockylinux.org/pub/rocky/8/images/x86_64/Rocky-8-Container-UBI.latest.x86_64.tar.xz), - - [Base aarch64](https://dl.rockylinux.org/pub/rocky/8/images/aarch64/Rocky-8-Container-Base.latest.aarch64.tar.xz), [Minimal aarch64](https://dl.rockylinux.org/pub/rocky/8/images/aarch64/Rocky-8-Container-Minimal.latest.aarch64.tar.xz), [UBI aarch64](https://dl.rockylinux.org/pub/rocky/8/images/aarch64/Rocky-8-Container-UBI.latest.aarch64.tar.xz) - - 9: [Base x86_64](https://dl.rockylinux.org/pub/rocky/9/images/x86_64/Rocky-9-Container-Base.latest.x86_64.tar.xz), [Minimal x86_64](https://dl.rockylinux.org/pub/rocky/9/images/x86_64/Rocky-9-Container-Minimal.latest.x86_64.tar.xz), [UBI x86_64](https://dl.rockylinux.org/pub/rocky/9/images/x86_64/Rocky-9-Container-UBI.latest.x86_64.tar.xz), - - [Base aarch64](https://dl.rockylinux.org/pub/rocky/9/images/aarch64/Rocky-9-Container-Base.latest.aarch64.tar.xz), [Minimal aarch64](https://dl.rockylinux.org/pub/rocky/9/images/aarch64/Rocky-9-Container-Minimal.latest.aarch64.tar.xz), [UBI aarch64](https://dl.rockylinux.org/pub/rocky/9/images/aarch64/Rocky-9-Container-UBI.latest.aarch64.tar.xz) + - 8: [Base x86_64](https://dl.rockylinux.org/pub/rocky/8/images/x86_64/Rocky-8-Container-Base.latest.x86_64.tar.xz), [Minimal x86_64](https://dl.rockylinux.org/pub/rocky/8/images/x86_64/Rocky-8-Container-Minimal.latest.x86_64.tar.xz), [UBI x86_64](https://dl.rockylinux.org/pub/rocky/8/images/x86_64/Rocky-8-Container-UBI.latest.x86_64.tar.xz), [Base aarch64](https://dl.rockylinux.org/pub/rocky/8/images/aarch64/Rocky-8-Container-Base.latest.aarch64.tar.xz), [Minimal aarch64](https://dl.rockylinux.org/pub/rocky/8/images/aarch64/Rocky-8-Container-Minimal.latest.aarch64.tar.xz), [UBI aarch64](https://dl.rockylinux.org/pub/rocky/8/images/aarch64/Rocky-8-Container-UBI.latest.aarch64.tar.xz) + - 9: [Base x86_64](https://dl.rockylinux.org/pub/rocky/9/images/x86_64/Rocky-9-Container-Base.latest.x86_64.tar.xz), [Minimal x86_64](https://dl.rockylinux.org/pub/rocky/9/images/x86_64/Rocky-9-Container-Minimal.latest.x86_64.tar.xz), [UBI x86_64](https://dl.rockylinux.org/pub/rocky/9/images/x86_64/Rocky-9-Container-UBI.latest.x86_64.tar.xz), [Base aarch64](https://dl.rockylinux.org/pub/rocky/9/images/aarch64/Rocky-9-Container-Base.latest.aarch64.tar.xz), [Minimal aarch64](https://dl.rockylinux.org/pub/rocky/9/images/aarch64/Rocky-9-Container-Minimal.latest.aarch64.tar.xz), [UBI aarch64](https://dl.rockylinux.org/pub/rocky/9/images/aarch64/Rocky-9-Container-UBI.latest.aarch64.tar.xz) - Видобудьте зображення з Docker Hub або Quay.io ([посил.](https://docs.microsoft.com/en-us/windows/wsl/use-custom-distro#export-the-tar-from-a -container)) ```sh