DEV Community: minnogit

Hardening Apache Reverse Proxy in produzione

minnogit — Tue, 17 Feb 2026 11:52:41 +0000

Guida completa a timeout, worker e gestione dei carichi applicativi

In un'infrastruttura dove Apache HTTP Server funge sia da frontend (TLS, routing, bilanciamento) che da tramite verso container Docker, la stabilità non dipende dalla potenza dell'hardware, ma dalla coerenza della catena dei timeout, dai limiti del sistema operativo e dal dimensionamento dell'intero stack applicativo.

Questa guida è focalizzata sul caso reale in cui:

Apache frontend agisce da reverse proxy e load balancer
Il backend applicativo gira in container
In alcuni casi Apache è anche il web server dentro il container
L’applicazione è PHP (ma i principi restano validi anche per Python o altri stack)

1. Il Sistema Operativo: Preparare il terreno (Systemd)

Prima di configurare Apache, dobbiamo assicurarci che il sistema operativo gli permetta di lavorare.

Sui sistemi moderni come Debian o Ubuntu, il limite di processi e thread per servizio è gestito da systemd tramite i Cgroups.

Il problema

Sotto carico Apache può raggiungere il limite di task e generare errori nei log simili a:

Fork Rejected

La soluzione

Aumentare TasksMax per il servizio Apache.

systemctl edit apache2.service

Inserire:

[Service]
TasksMax=3000

Applicare:

systemctl daemon-reload
systemctl restart apache2

Per un server con 4 GB RAM e ~400 worker, 3000 è un valore equilibrato.

2. Monitoraggio in tempo reale: i comandi “Manometro”

Per capire se il limite è corretto, interroga direttamente i Cgroups:

cat /sys/fs/cgroup/system.slice/apache2.service/pids.current
cat /sys/fs/cgroup/system.slice/apache2.service/pids.max

Se pids.current si avvicina a pids.max, il server inizierà a rifiutare connessioni.

Questo è il primo indicatore reale di saturazione.

3. Il Motore: MPM Event dimensionato per 4GB RAM

Il modulo MPM Event gestisce le connessioni in modo asincrono, evitando che i thread restino bloccati su KeepAlive.

Configurazione:

/etc/apache2/mods-available/mpm_event.conf

<IfModule mpm_event_module>
    ServerLimit              16
    StartServers             3
    ThreadsPerChild          25
    MaxRequestWorkers        400
    MinSpareThreads          25
    MaxSpareThreads          75
    MaxConnectionsPerChild   10000
</IfModule>

Perché questi numeri?

16 processi × 25 thread = 400 richieste simultanee
circa 800 MB occupati da Apache
RAM restante per PHP, sistema e cache

Se PHP cresce, Apache deve ridursi.

4. La Catena dei Timeout: Sincronia Proxy-Backend

Se proxy e backend non sono coordinati, i worker restano occupati inutilmente.

Regola fondamentale: l’applicazione deve morire prima del proxy.

Parametro	Proxy	Backend	Note
KeepAliveTimeout	3s	5s	Il backend aspetta di più
Timeout	60s	65s	Ricezione dati
ProxyTimeout	300s	–	Attesa risposta backend
PHP max_execution_time	–	290s	L’app muore prima del proxy

5. Configurazione Globale dei Timeout (operativa)

Creare:

/etc/apache2/conf-available/global-timeouts.conf

KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 3

Timeout 60
ProxyTimeout 300

Attivare:

a2enconf global-timeouts
systemctl reload apache2

Questo file evita configurazioni duplicate nei VirtualHost.

6. Bilanciamento e Failover Rapido

Il failover lento è uno dei problemi più comuni nei proxy Apache.

Usiamo connectiontimeout per forzare il rilevamento immediato dei nodi down.

<Proxy "balancer://app_cluster">
    BalancerMember "http://node01:8080" route=n1 connectiontimeout=2 retry=30
    BalancerMember "http://node02:8080" route=n2 connectiontimeout=2 retry=30
    ProxySet lbmethod=bybusyness timeout=60
</Proxy>

Con questo:

un nodo morto viene escluso in ~2 secondi
il traffico migra subito sugli altri

7. Separare traffico veloce e lento

Questa tecnica serve a proteggere le richieste normali da quelle pesanti.

È corretta solo se il backend lento ha risorse dedicate.

# Pool veloce
<Proxy "balancer://app_fast">
    BalancerMember "http://app:8080" connectiontimeout=2
    ProxySet timeout=60
</Proxy>

# Pool lento
<Proxy "balancer://app_slow">
    BalancerMember "http://app_dedicated:8080" connectiontimeout=2
    ProxySet timeout=1200
</Proxy>

Se entrambi puntano allo stesso backend, non serve a nulla.

8. PHP-FPM: il vero limite della capacità

Apache accetta la richiesta, ma PHP la esegue.

Per 4 GB con 2 GB dedicati a PHP:

pm.max_children ≈ RAM_php / memoria_media_script

Configurazione:

/etc/php/8.x/fpm/pool.d/www.conf

pm = dynamic
pm.max_children = 40
pm.start_servers = 10
pm.max_requests = 500
request_terminate_timeout = 300s

Se PHP si satura, Apache sembra lento anche se non lo è.

9. Quando il tuning non basta: strategie architetturali

Il tuning dei timeout migliora la stabilità, ma non cambia il modello di carico.

Le operazioni lunghe dovrebbero diventare asincrone.

Soluzioni tipiche

code con Redis
code con RabbitMQ
job worker separati
risposta immediata “presa in carico”

Questo libera i worker Apache in pochi millisecondi.

10. Checklist finale operativa

✔ TasksMax aumentato e verificato
✔ MPM Event dimensionato sulla RAM
✔ Timeout coerenti tra proxy, backend e PHP
✔ Failover rapido con connectiontimeout
✔ Backend lento separato solo se realmente isolato
✔ PHP-FPM dimensionato sulla RAM reale
✔ Monitoraggio periodico dei pids Apache

Conclusione

La stabilità di un reverse proxy Apache non dipende da un singolo parametro, ma dall'allineamento di:

limiti del sistema operativo
modello di concorrenza di Apache
timeout della catena proxy-backend
capacità reale dell’applicazione

Quando questi quattro livelli sono coerenti, Apache diventa estremamente stabile anche sotto carico elevato.

Eseguire Backup grandi su Debian: Compressione, Split e Sessioni Persistenti

minnogit — Fri, 23 Jan 2026 15:52:34 +0000

Gestire dataset massivi (100GB+) su un server remoto presenta due sfide principali: la gestione delle risorse (RAM/CPU) e la stabilità della connessione. Se la sessione SSH cade mentre stai creando un archivio enorme, il processo viene interrotto bruscamente, obbligandoti a ricominciare da capo.

In questa guida vedremo come usare 7-Zip per creare archivi multi-volume e come proteggere il processo con screen.

1. Il problema della disconnessione SSH

Quando avvii un comando tramite SSH, questo è legato alla tua sessione. Se la tua connessione internet vacilla o chiudi il terminale, il sistema invia un segnale di "hangup" (SIGHUP) e interrompe il lavoro. Per un backup di molto grande che può richiedere ore, questo è un rischio inaccettabile.

La soluzione: GNU Screen

screen è un multiplexer di terminale che permette di avviare un processo in una sessione virtuale che sopravvive anche se ti disconnetti.

Installazione:

sudo apt update && sudo apt install screen p7zip-full

2. Flusso di lavoro con Screen

Prima di lanciare il comando di compressione, crea una sessione dedicata:

Crea una sessione: screen -S backup_cliente
Lancia il comando di compressione (vedi sezione successiva).
Scollegati (Detach): Premi CTRL + A e poi il tasto D. Ora puoi chiudere il terminale e spegnere il tuo PC; il server continuerà a lavorare.
Ricollegati (Resume): Quando vuoi controllare l'avanzamento, torna nel terminale e scrivi:

screen -r backup_cliente

3. Il comando 7-Zip ottimizzato (Low RAM)

Per evitare che il server vada in crash per esaurimento memoria (OOM Error), utilizziamo parametri che limitano l'uso della RAM e della CPU:

7z a -v1g -mx=1 -md=16m -mmt=2 -p -mhe=on archive_name.7z ./source_folder/

Analisi dei parametri:

a: Aggiunge i file all'archivio.
-v1g: Divide l'archivio in parti da 1GB (ideale per upload/download FTP stabili).
-mx=1: Compressione minima (ultra-rapida). Fondamentale per risparmiare tempo.
-md=16m: Riduce il "dizionario" di compressione a 16MB per mantenere basso l'uso della RAM.
-mmt=2: Limita l'uso a 2 thread della CPU.
-p: Richiede una password in modo sicuro (non apparirà in chiaro nei log).
-mhe=on: Cifra anche i nomi dei file (senza password non si vede il contenuto).

5. Verifica e Consegna al Cliente

Una volta terminato, verifica l'integrità dei volumi prima di caricarli sull'FTP:

7z t archive_name.7z.001

Istruzioni per il cliente:
Comunica al destinatario che per estrarre i dati dovrà:

Scaricare tutti i file (.001, .002, ... fino al file .7z).
Usare software come 7-Zip (Windows).
Aprire esclusivamente il primo file della serie; il programma ricomporrà automaticamente l'intero archivio.

Ripristinare il backup di un database PostgreSQL su AWS senza accesso diretto al server DB

minnogit — Tue, 20 Jan 2026 18:25:27 +0000

In molte infrastrutture AWS ben progettate, il server PostgreSQL non è esposto su Internet:
non ha un IP pubblico statico e non è accessibile direttamente via SSH.

Il database risiede in una subnet privata all’interno di una VPC, mentre l’accesso avviene tramite un server ponte (jump host / bastion host) con IP pubblico.

In questo articolo vediamo come ripristinare un database PostgreSQL partendo da un file .sql presente sul proprio PC, analizzando le diverse soluzioni possibili, i pro e contro, e raccogliendo in fondo una serie di comandi PostgreSQL di uso comune come note operative.

Scenario di riferimento

PC locale: Debian Linux, con file db.sql
Server ponte: accessibile via SSH con chiave (serverponte.dominioaziendale.it)
Server PostgreSQL:
- Debian
- IP privato statico (es. serverpostgresql.ipprivato.domioaziendale.it)
- Accessibile solo dalla VPC
Utenti DB disponibili:
- postgres (superuser)
- admin (utente applicativo)
Obiettivo: ripristinare il database NomeDB da script SQL

Problema tipico

Lo script SQL non viene eseguito correttamente usando DBeaver con l’utente admin e produce errori come:

permessi insufficienti
impossibilità di creare estensioni
errori su OWNER TO postgres
messaggi legati a pg_hba.conf

👉 Questo accade perché un file .sql spesso contiene operazioni da superuser, anche se il database esiste già.

Le possibili soluzioni

✔️ Soluzione 1 – Tunnel SSH + `psql` locale (consigliata)

È la soluzione più pulita, sicura e professionale.
Non richiede di copiare file sui server e sfrutta il port forwarding SSH.

Schema logico

PC locale → tunnel SSH → server ponte → rete privata → PostgreSQL

Apertura del tunnel

Dal PC locale:

ssh -L 5433:serverpostgresql.ipprivato.domioaziendale.it:5432 serverponte.dominioaziendale.it

5433 → porta locale
5432 → porta PostgreSQL remota
il tunnel resta attivo finché la sessione SSH è aperta

Ripristino del database

In un secondo terminale locale:

psql -h localhost -p 5433 -U admin -d NomeDB < db.sql

⚠️ In questo scenario l’utente admin deve essere SUPERUSER, altrimenti lo script potrebbe fallire.

✔️ Soluzione 2 – Promuovere temporaneamente `admin` a superuser

Se pg_hba.conf blocca le connessioni dell’utente postgres da remoto (caso molto comune in ambienti gestiti con Puppet), la soluzione più pragmatica è:

ALTER USER admin WITH SUPERUSER;

Dopo il ripristino:

ALTER USER admin WITH NOSUPERUSER;

✔️ Veloce
✔️ Non richiede modifiche a pg_hba.conf
✔️ Adatta a interventi manuali controllati

✔️ Soluzione 3 – Copiare il file sul server DB ed eseguire localmente

Indicata per file molto grandi o connessioni instabili.

scp db.sql serverponte.dominioaziendale.it:/tmp/
# poi dal jump host verso il DB
scp /tmp/db.sql serverpostgresql.ipprivato.domioaziendale.it:/tmp/

Sul server DB:

su - postgres
psql NomeDB < /tmp/db.sql

✔️ Massima affidabilità
❌ Più passaggi manuali

Perché DBeaver spesso non basta

DBeaver funziona bene per:

restore da dump binari
operazioni standard
utenti applicativi

Ma fallisce con script SQL complessi che contengono:

CREATE EXTENSION
ALTER OWNER
SET ROLE
operazioni su schemi di sistema

👉 In questi casi psql è lo strumento giusto.

Note operative – Comandi PostgreSQL di uso comune

Creare un database

CREATE DATABASE NomeDB;

Creare una copia da un database esistente

CREATE DATABASE testCopia WITH TEMPLATE 'NomeDB';

Assegnare tutti i permessi a un utente

GRANT ALL PRIVILEGES ON DATABASE NomeDB TO admin;

Collegarsi a un database con un utente specifico

psql -U admin -d NomeDB -h localhost

Eliminare un database

$ psql -U postgresql -h localhost
DROP DATABASE database_da_eliminare WITH (FORCE);

Backup con `pg_dump`

Creare un dump SQL

pg_dump -f /tmp/nome_database_dump.sql -U postgres -W nome_database

Significato opzioni:

-f → file di output
-U postgres → utente DB
-W → richiede password
nome_database → nome database

Evitare la richiesta password (automazioni)

Metodo consigliato: `.pgpass`

File ~/.pgpass:

hostname:port:database:username:password

Permessi obbligatori:

chmod 600 ~/.pgpass

Metodo rapido (meno sicuro)

export PGPASSWORD='password'

Ripristino di un database PostgreSQL: scegliere il comando giusto

Il comando da usare per il ripristino dipende dal formato del backup, ovvero da come è stato creato con pg_dump.

È un aspetto fondamentale: usare lo strumento sbagliato porta a errori o a ripristini incompleti.

1️⃣ Ripristino da file SQL (Plain Text)

Se il backup è stato creato senza opzioni di formato (output leggibile, .sql):

pg_dump nome_database > backup.sql

oppure:

pg_dump -f /tmp/pnd_dump.sql nome_database

il ripristino va fatto con psql, che esegue sequenzialmente le istruzioni SQL contenute nel file.

psql -U postgres -d nome_database -f /tmp/nome_database_dump.sql

Note importanti:

Il database di destinazione deve già esistere
Il file è leggibile e modificabile
Su database molto grandi può essere più lento

2️⃣ Ripristino da file Custom o Directory (`.dump`, `.bak`)

Se il backup è stato creato con:

pg_dump -Fc nome_database > backup.dump

oppure:

pg_dump -Fd nome_database -f backup_dir

si tratta di un formato binario/speciale, che non può essere eseguito con psql.

In questo caso va usato pg_restore:

pg_restore -U postgres -d nome_database -v backup.dump

Opzioni utili:

-v → modalità verbose
--clean → elimina gli oggetti prima di ricrearli
--if-exists → evita errori se gli oggetti non esistono

Ripristino in parallelo (solo con `pg_restore`)

Uno dei grandi vantaggi dei formati custom o directory è la possibilità di usare più core CPU:

pg_restore -j 4 -U postgres -d nome_database backup.dump

👉 Ideale per database grandi in ambienti server.

Tabella rapida di riferimento

Formato backup	Strumento	Quando usarlo
`.sql` (plain text)	`psql`	Backup leggibile, semplice
`.dump` (custom)	`pg_restore`	Backup compresso, selettivo
directory	`pg_restore`	Ripristino veloce e parallelo

Nota operativa importante

Se il database di destinazione è già in uso, il ripristino può fallire per:

connessioni attive
oggetti già esistenti
lock sulle tabelle

In questi casi è consigliabile:

ripristinare su un database vuoto
oppure usare --clean con attenzione

Conclusione

In ambienti AWS con PostgreSQL in subnet private:

non si espone mai il DB su Internet
il jump host è la chiave
psql è lo strumento più affidabile
i permessi contano più della GUI

Il tunnel SSH + psql resta la soluzione più solida, ripetibile e sicura per ripristinare database PostgreSQL in infrastrutture cloud ben progettate.

Inizializzare GIT e configurare autenticazione SSH GitHub

minnogit — Thu, 08 May 2025 08:54:46 +0000

git --version

git config --global color.ui true
git config --global user.name 'Mario Rossi'
git config --global user.email emailAccount

git config --global core.editor nano
O questo per usare vscode:
git config --global core.editor "code --wait"

git config --global gui.editor gedit
git config --global init.defaultBranch main

Se non si mette --global la configurazione sarà relativa al repository.

Creare chiave ssh:

ssh-keygen -t ed25519 -C "your_email@example.com"
cat ~/.ssh/id_ed25519_sk.pub

Aggiungere al profilo Github la chiave pubblica.

Clonare il repository con ssh
Ad es.: git clone git@github.com:organizzazione/progetto.git
Si può fare anche da VSCode.

Se si ottiene errore Permission denied (publickey) vuol dire che il comando git non trova o non può usare la chiave SSH per parlare con GitHub.
Mi è successo in ambiente di sviluppo Dev Container con Docker Rootless in cui il Dev Container cerca di passare le chiavi dall'host al container.
Per risolvere, verificare se l'agente SSH è vivo:

echo $SSH_AUTH_SOCK

Se l'output è vuoto: VS Code non sta passando l'agente SSH al container.
Se vedi un percorso (es. /tmp/vscode-ssh-auth...): L'agente è passato, ma dobbiamo vedere se possiamo usarlo.

ssh-add -l

Se dice "The agent has no identities": L'agente è collegato ma "vuoto" (devi fare ssh-add sul tuo host Linux).

Verificare la connessione con ssh -vT git@github.com.

Elenco in Conky di applicazioni con l'uso della swap

minnogit — Thu, 20 Apr 2023 15:30:00 +0000

In continuazione del precedente post, adesso vediamo come stampare in Conky un elenco di programmi con la relativa quantità di swap usata.

Prepariamo uno script bash che restituisce il testo che vogliamo visualizzare in Conky basato sul comando spiegato in precedenza ma con una differenza in particolare: ci possono essere più processi in esecuzione dello spesso comando (ad esempio 5 processi per Chrome) ma quello che voglio visualizzare in Conky, è la somma della swap usata da tutti i processi dello stesso comando.

unioneTest=""
for file in /proc/*/status; do
  if [[ -f "$file" ]]; then
    test=$(awk '/^(Name:)/ {awk_name=$2} /^(VmSwap:)/ {awk_vmswap=$2" "$3} /^(Pid:)/ {awk_pid=$2} END { if (awk_vmswap && substr(awk_vmswap,1,1) != '0' ) print awk_name" "awk_pid" "awk_vmswap}' $file)
    if [ -n "$test" ]; then
      unioneTest+=$test"\n"
    fi
  fi
done

A differenza del comando precedente, alla fine dell'analisi awk di ogni file, viene verificato se la variabile awk_vmswap non è vuota e se il primo carattere non è "0". Se queste condizioni sono soddisfatte, viene creato un nuovo record di informazioni sul processo, che viene memorizzato nella variabile test.
Se la variabile test non è vuota, viene aggiunto alla variabile unioneTest e viene inserito un carattere di nuova linea ("\n") per separare i record.
Alla fine, $unioneTest conterrà l'elenco dei processi che usano la swap.

Il passo successivo, è sommare tra loro i valori di swap degli stessi comandi.
Per farlo, creo un array associativo denominato somma mediante il comando declare -A.
Questo array verrà utilizzato per accumulare i valori della terza colonna (ovvero la quantità di swap usata) dei processi che hanno lo stesso nome.

dati=$unioneTest
declare -A somma

while read -r linea; do
  nome=$(echo "$linea" | cut -d ' ' -f1)
  valore=$(echo "$linea" | cut -d ' ' -f3)
  ((somma[$nome] += valore))
done <<<"$(echo -e "$unioneTest")"

Il ciclo while viene alimentato con un here-string (<<<) che contiene l'output di un comando echo -e che converte una stringa contenente i dati da elaborare.

Infine, stampiamo l'elenco dall'array somma inserendo in ogni riga il numero di spazi necessario ad avere una lunghezza prestabilita. Gli spazi vengono inseriti tra il nome del comando e la quantità di swap usata.
La lunghezza delle righe, verrà specificata da un parametro dello script.

elenco=""
  for nome in "${!somma[@]}"; do
    tmp="$nome${somma[$nome]} kB\n"
    nrSpacesToAdd=$(expr $spaces - ${#tmp})
    elenco+="$nome$(printf '%*s' $nrSpacesToAdd)${somma[$nome]} kB\n"
  done
  echo -e "$elenco" | sort -k 2 -n -r

nrSpacesToAdd calcola il numero di spazi da aggiungere ad una stringa, in modo da ottenere una stringa di una lunghezza specifica.
La variabile $spaces rappresenta il numero totale di spazi che si desidera avere nella stringa finale.
La variabile ${#tmp} rappresenta la lunghezza della stringa tmp.

(printf '%*s' $nrSpacesToAdd) viene utilizzato per generare una stringa di spazi della lunghezza $nrSpacesToAdd.

Questo è lo script completo:

#!/bin/bash

if [ $# -eq 0 ]; then
  echo "Specificare la lunghezza delle stringhe"
  exit 1
fi

# Lunghezza voluta delle stringhe
spaces=$1

unioneTest=""
for file in /proc/*/status; do
  if [[ -f "$file" ]]; then
    test=$(awk '/^(Name:)/ {awk_name=$2} /^(VmSwap:)/ {awk_vmswap=$2" "$3} /^(Pid:)/ {awk_pid=$2} END { if (awk_vmswap && substr(awk_vmswap,1,1) != '0' ) print awk_name" "awk_pid" "awk_vmswap}' $file)
    if [ -n "$test" ]; then
      unioneTest+=$test"\n"
    fi
  fi
done

if [ -n "$unioneTest" ]; then
  dati=$unioneTest
  declare -A somma

  while read -r linea; do
    nome=$(echo "$linea" | cut -d ' ' -f1)
    valore=$(echo "$linea" | cut -d ' ' -f3)
    ((somma[$nome] += valore))
  done <<<"$(echo -e "$unioneTest")"

  elenco=""
  for nome in "${!somma[@]}"; do
    tmp=" $nome${somma[$nome]} kB\n"
    nrSpacesToAdd=$(expr $spaces - ${#tmp})
    elenco+="$nome$(printf '%*s' $nrSpacesToAdd)${somma[$nome]} kB\n"
  done
  echo -e "$elenco" | sort -k 2 -n -r
fi

Esempio di output:

$ ./swapUsed.sh 41
java                           94708 kB
apache2                        16188 kB
gnome-software                  8792 kB
chrome                           632 kB
pipewire-pulse                   564 kB
dbus-launch                      452 kB
exim4                            388 kB
dbus-daemon                      388 kB
postgres                          72 kB
(sd-pam)                          64 kB
containerd                        60 kB
spotify                           52 kB

Per usare il comando in Conky, ho aggiunto al file di configurazione .conkyrc le seguenti linee nella sezione conky.text:

...
$hr
${color grey}Name                          Swap used
${color lightgrey}${execi 30 ~/swapUsed.sh 41 | head -n 10}

Questo fa si che il comando venga eseguito ogni 30 secondi con il parametro 41 che specifica la lunghezza delle stringhe corretta per la mia configurazione Conky.
Con head -n 10, indico di stampare solo le prime 10 righe.

Qui il file .conkyrc completo:

-- Conky, a system monitor https://github.com/brndnmtthws/conky
--
-- This configuration file is Lua code. You can write code in here, and it will
-- execute when Conky loads. You can use it to generate your own advanced
-- configurations.
--
-- Try this (remove the `--`):
--
--   print("Loading Conky config")
--
-- For more on Lua, see:
-- https://www.lua.org/pil/contents.html

conky.config = {
    alignment = 'top_right',
    background = false,
    border_width = 1,
    cpu_avg_samples = 2,
    default_color = 'white',
    default_outline_color = 'white',
    default_shade_color = 'white',
    double_buffer = true,
    draw_borders = false,
    draw_graph_borders = true,
    draw_outline = false,
    draw_shades = false,
    extra_newline = false,
    font = 'DejaVu Sans Mono:size=8',
    gap_x = 60,
    gap_y = 60,
    minimum_height = 5,
    minimum_width = 5,
    net_avg_samples = 2,
    no_buffers = true,
    out_to_console = false,
    out_to_ncurses = false,
    out_to_stderr = false,
    out_to_x = true,
    own_window = true,
    own_window_colour = '000000',
    own_window_class = 'Conky',
    own_window_type = 'desktop',
    own_window_transparent = true,
    own_window_argb_visual = true,
    own_window_hints = 'undecorated,below,sticky,skip_taskbar,skip_pager',
    show_graph_range = false,
    show_graph_scale = false,
    stippled_borders = 0,
    update_interval = 5.0,
    uppercase = false,
    use_spacer = 'none',
    use_xft = true,
}

conky.text = [[
${color grey}Uptime:$color $uptime
${color grey}RAM Usage:$color $mem/$memmax - $memperc% ${membar 8}
${color grey}Swap Usage:$color $swap/$swapmax - $swapperc% ${swapbar 8}
${color grey}CPU Usage:$color $cpu% ${cpubar 8}
${color grey}Processes:$color $processes  ${color grey}Running:$color $running_processes
$hr
${color grey}File systems:
 root $color${fs_used /}/${fs_size /} ${fs_bar 8 /}
 ec2-free $color${fs_free /mnt/ec2_export}/${fs_size /mnt/ec2_export} ${fs_bar 8 /mnt/ec2_export}
 qnap $color${fs_used /mnt/u_rsync}/${fs_size /mnt/u_rsync} ${fs_bar 8 /mnt/u_rsync}
${color grey}Networking:
Up:$color ${upspeed} ${color grey} - Down:$color ${downspeed}
$hr
${color grey}Name              PID     CPU%   MEM%
${color lightgrey} ${top name 1} ${top pid 1} ${top cpu 1} ${top mem 1}
${color lightgrey} ${top name 2} ${top pid 2} ${top cpu 2} ${top mem 2}
${color lightgrey} ${top name 3} ${top pid 3} ${top cpu 3} ${top mem 3}
${color lightgrey} ${top name 4} ${top pid 4} ${top cpu 4} ${top mem 4}
${color lightgrey} ${top name 5} ${top pid 5} ${top cpu 5} ${top mem 5}
$hr
${color grey}Name                          Swap used
${color lightgrey}${execi 30 ~/swapUsed.sh 41 | head -n 10}
]]

Gestire la cache di npm e considerazioni per Docker

minnogit — Mon, 17 Apr 2023 09:06:54 +0000

Quando si richiede di installare un pacchetto npm, questo viene scaricato da internet e salvato nella cartella di cache, se non è già presente, e poi installato nell'applicazione che lo richiede.
Dalla versione 5 di npm, la gestione della cache è self-healing per cui dovrebbe riconoscere eventuali pacchetti incompleti, danneggiati o obsoleti e, in tal caso, scaricarli nuovamente cercando anche di risolvere automaticamente le dipendenze nel modo migliore.
Tuttavia in alcuni casi, anche per risolvere problemi di installazione, è utile pulire la cache di npm con il comando:

$ npm --global cache verify
Cache verified and compressed (~/git/.npm/_cacache)
Content verified: 9127 (1525196266 bytes)
Content garbage-collected: 3491 (5398705346 bytes)
Index entries: 9129
Finished in 34.248s

La cartella della cache normalmente è ~/.npm (nell'es. sopra è ~/git/.npm) ma è possibile spostarla.
Possono esserci diversi motivi per cui si potrebbe voler controllare il percorso della cache:

la cartella può arrivare a occupare uno spazio considerevole e si potrebbe volerla spostare.
si vuole usare una cartella di cache condivisa tra più host per velocizzare le installazioni.
si vuole una cache condivisa tra gli utenti della stessa macchina.

Il comando per spostare la cartella di cache è:

npm config set cache nuovaCartella --global

Al posto di modificare la configurazione del file di configurazione di npm, è anche possibile impostare il percorso della cache in una variabile di ambiente:

export npm_config_cache=/path/to/cache

Dopo aver spostato la cache, lanciare il comando di verifica:

npm --global cache verify`

E' possibile vedere la configurazione attuale con il comando:

npm config list

Il comando di verifica non cancella pacchetti scaricati ma non più usati, perciò si potrebbe voler cancellare tutta la cache con il comando:

npm cache clean

Considerazioni per Docker

Se stiamo usando Docker, è possibile impostare la cartella della cache con:

docker run -e npm_config_cache=/path/to/cache mydockerimage:tag

In questo modo, il comando docker run consente di eseguire un container Docker configurato per utilizzare una specifica directory per la cache dei pacchetti npm.
Controllando dove i pacchetti vengono salvati, si può condividere la cache tra diversi container o host, ad esempio per ridurre il tempo di download dei pacchetti npm o per evitare di scaricare i pacchetti più volte.
Inoltre, ci permette di usare la stessa cartella di cache anche quando si avvia il container con un utente diverso da quello attuale (ogni utente ha la sua cartella di cache).

Dividere il monitor in 4 terminali con Terminator

minnogit — Thu, 13 Apr 2023 10:56:31 +0000

Una delle prime cose che faccio quando la mattina entro nel pc al lavoro, è aprire alcuni terminali.

Di solito uso Terminator che è un emulatore di terminale per Linux che consente di aprire e gestire più finestre di terminale all'interno di una sola finestra.
Ha diverse caratteristiche interessanti, anche se la sua configurazione non è molto intuitiva per certi aspetti.

La suddivisione in 4 terminali della finestra di Terminator è definita come un layout nel suo file di configurazione.
Ho quindi aggiunto un layout personalizzato server dalla finestra delle preferenze.

Si può anche modificare direttamente il file di configurazione:

$ nano ~/.config/terminator/config

[global_config]
  enabled_plugins = CustomCommandsMenu, APTURLHandler
  suppress_multiple_term_dialog = True
[keybindings]
[profiles]
  [[default]]
    background_darkness = 0.85
    font = Monospace 9
    scrollback_lines = 2000
    use_system_font = False
[layouts]
  [[default]]
    [[[child1]]]
      parent = window0
      type = Terminal
      command = ""
    [[[window0]]]
      parent = ""
      type = Window
  [[servers]]
    [[[child0]]]
      type = Window
      parent = ""
      order = 0
      position = 0:0
      maximised = True
      fullscreen = False
      size = 1920, 995
      title = admin@node01: ~
      last_active_term = 428ce1c8-9aed-4acf-a481-45a18c5f54a9
      last_active_window = True
    [[[child1]]]
      type = HPaned
      parent = child0
      order = 0
      position = 958
      ratio = 0.5002610966057441
    [[[child2]]]
      type = VPaned
      parent = child1
      order = 0
      position = 495
      ratio = 0.5
    [[[terminal3]]]
      type = Terminal
      parent = child2
      order = 0
      profile = default
      uuid = a1b21c6d-82fa-4907-9b35-838b3743bb62
      command = ""
    [[[terminal4]]]
      type = Terminal
      parent = child2
      order = 1
      profile = default
      uuid = 9a8f88b6-22e6-49f4-865f-d100a84fa56e
      command = ""
    [[[child5]]]
      type = VPaned
      parent = child1
      order = 1
      position = 496
      ratio = 0.5
    [[[terminal6]]]
      type = Terminal
      parent = child5
      order = 0
      profile = default
      uuid = 716efc36-9385-4b79-898f-a437165c439b
      command = ""
    [[[terminal7]]]
      type = Terminal
      parent = child5
      order = 1
      profile = default
      uuid = 428ce1c8-9aed-4acf-a481-45a18c5f54a9
      command = ""
[plugins]

Adesso è possibile avviare Terminator specificando di usare il layout server:

terminator --layout=servers

Infine, ho creato un launcher apposito per gnome-shell con MenuLibre per eseguire il comando sopra.

Stampare un elenco dei processi ordinato per la quantità di swap che usano

minnogit — Wed, 15 Mar 2023 22:21:24 +0000

Cercando su internet possiamo trovare questo comando per stampare l'elenco dei processi ordinato per uso del file di Swap:

for file in /proc/*/status ; do awk '/VmSwap|Name/{printf $2 " " $3}END{ print ""}' $file; done | sort -k 2 -n -r | less

Poiché per me è abbastanza magico, ho cercato di capire come funziona:

for file in /proc/*/status - Ciclo su tutti i file di stato dei processi attualmente in esecuzione. La variabile "file" assume il valore di ogni percorso di file corrispondente. Il contenuto del file di stato ad es. può essere:

cat /proc/6377/status
Name:   gnome-software
Umask:  0022
State:  S (sleeping)
Tgid:   6377
Ngid:   0
Pid:    6377
PPid:   6154
TracerPid:  0
Uid:    1000    1000    1000    1000
Gid:    1000    1000    1000    1000
FDSize: 256
Groups: 24 25 27 29 30 33 44 46 106 109 112 114 999 1000 
NStgid: 6377
NSpid:  6377
NSpgid: 6154
NSsid:  6154
VmPeak:  2922312 kB
VmSize:  2791180 kB
VmLck:         0 kB
VmPin:         0 kB
VmHWM:    459088 kB
VmRSS:    163004 kB
RssAnon:      130664 kB
RssFile:       32340 kB
RssShmem:          0 kB
VmData:   621548 kB
VmStk:       728 kB
VmExe:       368 kB
VmLib:    184796 kB
VmPTE:      1384 kB
VmSwap:   218708 kB
HugetlbPages:          0 kB
CoreDumping:    0
THP_enabled:    1
Threads:    36
SigQ:   2/63374
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000001000
SigCgt: 0000000100000000
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 000001ffffffffff
CapAmb: 0000000000000000
NoNewPrivs: 0
Seccomp:    0
Seccomp_filters:    0
Speculation_Store_Bypass:   thread vulnerable
SpeculationIndirectBranch:  conditional enabled
Cpus_allowed:   f
Cpus_allowed_list:  0-3
Mems_allowed:   00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
Mems_allowed_list:  0
voluntary_ctxt_switches:    83533
nonvoluntary_ctxt_switches: 8663

do awk '/VmSwap|Name/{printf $2 " " $3}END{ print ""}' $file; done - Per ogni percorso del file ($file), viene eseguito il comando awk. Il comando awk cerca le righe che contengono "VmSwap" o "Name" nel file di stato del processo e quindi utilizza il comando "printf" per stampare il secondo e il terzo campo di ogni riga. Nell' esempio del file di stato sopra, troviamo prima Name e poi VmSwap che verranno quindi trovati da awk in questo ordine. Quando la riga contiene Name, il secondo campo corrisponde al nome del processo e il terzo è vuoto. Quando la riga contiene VmSwap, il secondo campo contiene la memoria usata e il terzo l'unità di misura. Alla fine, la clausola "END" viene utilizzata per stampare una riga vuota per separare l'output dei diversi processi.
sort -k 2 -n -r - Ordina l'output in base al secondo campo (-k 2) in ordine numerico (-n) in ordine inverso (-r).
Significa che la quantità di swap usata dai processi è ordinata dal più grande al più piccolo.
less - Visualizzare l'output paginato nel terminale.

Es. di output del comando:

for file in /proc/*/status ; do awk '/VmSwap|Name/{printf $2 " " $3}END{ print ""}' $file; done | sort -k 2 -n -r | less
gnome-software 218708 kB
mariadbd 155576 kB
code 147548 kB
code 134844 kB
firefox 111212 kB
WebExtensions 71236 kB
java 70472 kB

Se vogliamo aggiungere la stampa del Pid possiamo modificare il comando in questo modo:

for file in /proc/*/status ; do awk '/^(VmSwap:|Name:|Pid:)/ {printf $2 " " $3}END{ print ""}' $file; done | sort -k 3 -n -r | less

Adesso, il pattern di ricerca usa il carattere ^ che specifica che la corrispondenza deve iniziare esattamente con una delle stringhe specificate.
In questo modo, le righe che iniziano ad es. con "PPid" non vengono selezionate da awk.
Adesso il secondo campo stampato sarà il Pid del processo e il terzo la swap usata.
Il sort lo facciamo quindi sul terzo campo.

Es. di output del comando:

for file in /proc/*/status ; do awk '/^(VmSwap:|Name:|Pid:)/ {printf $2 " " $3}END{ print ""}' $file; done | sort -k 3 -n -r | less
gnome-software 6377 218708 kB
mariadbd 46522 155576 kB
code 41703 147548 kB
code 40429 134844 kB
firefox 8840 111212 kB

Modificare allarme di spazio libero per un disco in Netdata

minnogit — Mon, 13 Mar 2023 14:01:40 +0000

Dall'interfaccia web di Netdata, in alto a destra, si vedono gli allarmi e, nei dettagli di ognuno, sono specificati i relativi file di configurazione.

Ad es., dai dettagli sopra si vede che l'allarme è configurato nel file /opt/netdata/usr/lib/netdata/conf.d/health.d/disks.conf

Se vogliamo che l'allarme per il disco /mnt/disco_utenti abbia regole diverse rispetto a quelle per gli altri dischi, possiamo modificare la configurazione così:

nano /opt/netdata/usr/lib/netdata/conf.d/health.d/disks.conf

Escludo il disco /mnt/disco_utenti dalla configurazione attuale modificando la lista families:

# -----------------------------------------------------------------------------
# low disk space

# checking the latest collected values
# raise an alarm if the disk is low on
# available disk space

 template: disk_space_usage
       on: disk.space
    class: Utilization
     type: System
component: Disk
       os: linux freebsd
    hosts: *
 families: !/mnt/disco_utenti !/mnt/disco_utenti !/dev !/dev/* !/run !/run/* *
     calc: $used * 100 / ($avail + $used)
    units: %
    every: 1m
     warn: $this > (($status >= $WARNING ) ? (80) : (90))
     crit: $this > (($status == $CRITICAL) ? (90) : (98))
    delay: up 1m down 15m multiplier 1.5 max 1h
     info: disk ${label:mount_point} space utilization
       to: sysadmin

Aggiungo alla configurazione una nuova sezione per l'allarme del disco /mnt/disco_utenti:

# -----------------------------------------------------------------------------
# low disk space

# checking the latest collected values
# raise an alarm if the disk is low on
# available disk space

 template: disk_space_usage
       on: disk.space
    class: Utilization
     type: System
component: Disk
       os: linux freebsd
    hosts: *
 families: /mnt/disco_utenti
     calc: $used * 100 / ($avail + $used)
    units: %
    every: 10m
     warn: $this > (($status >= $WARNING ) ? (96) : (98))
     crit: $this > (($status == $CRITICAL) ? (98) : (99))
    delay: up 1m down 15m multiplier 1.5 max 1h
     info: disk ${label:mount_point} space utilization
       to: sysadmin

 template: disk_inode_usage
      on: disk.inodes
    class: Utilization
     type: System
component: Disk
       os: linux freebsd
    hosts: *
 families: !/dev !/dev/* !/run !/run/* *
     calc: $used * 100 / ($avail + $used)
    units: %
    every: 1m
     warn: $this > (($status >= $WARNING)  ? (80) : (90))
     crit: $this > (($status == $CRITICAL) ? (90) : (98))
    delay: up 1m down 15m multiplier 1.5 max 1h
     info: disk ${label:mount_point} inode utilization
       to: sysadmin

Riavviare Netdata:

systemctl restart netdata

DEV Community: minnogit

Hardening Apache Reverse Proxy in produzione

Guida completa a timeout, worker e gestione dei carichi applicativi

1. Il Sistema Operativo: Preparare il terreno (Systemd)

Il problema

La soluzione

2. Monitoraggio in tempo reale: i comandi “Manometro”

3. Il Motore: MPM Event dimensionato per 4GB RAM

Perché questi numeri?

4. La Catena dei Timeout: Sincronia Proxy-Backend

5. Configurazione Globale dei Timeout (operativa)

6. Bilanciamento e Failover Rapido

7. Separare traffico veloce e lento

8. PHP-FPM: il vero limite della capacità

9. Quando il tuning non basta: strategie architetturali

Soluzioni tipiche

10. Checklist finale operativa

Conclusione

Eseguire Backup grandi su Debian: Compressione, Split e Sessioni Persistenti

1. Il problema della disconnessione SSH

La soluzione: GNU Screen

2. Flusso di lavoro con Screen

3. Il comando 7-Zip ottimizzato (Low RAM)

Analisi dei parametri:

5. Verifica e Consegna al Cliente

Ripristinare il backup di un database PostgreSQL su AWS senza accesso diretto al server DB

Scenario di riferimento

Problema tipico

Le possibili soluzioni

✔️ Soluzione 1 – Tunnel SSH + psql locale (consigliata)

Schema logico

Apertura del tunnel

Ripristino del database

✔️ Soluzione 2 – Promuovere temporaneamente admin a superuser

✔️ Soluzione 3 – Copiare il file sul server DB ed eseguire localmente

Perché DBeaver spesso non basta

Note operative – Comandi PostgreSQL di uso comune

Creare un database

Creare una copia da un database esistente

Assegnare tutti i permessi a un utente

Collegarsi a un database con un utente specifico

Eliminare un database

Backup con pg_dump

Creare un dump SQL

Evitare la richiesta password (automazioni)

Metodo consigliato: .pgpass

Metodo rapido (meno sicuro)

Ripristino di un database PostgreSQL: scegliere il comando giusto

1️⃣ Ripristino da file SQL (Plain Text)

2️⃣ Ripristino da file Custom o Directory (.dump, .bak)

Ripristino in parallelo (solo con pg_restore)

Tabella rapida di riferimento

Nota operativa importante

Conclusione

Inizializzare GIT e configurare autenticazione SSH GitHub

Elenco in Conky di applicazioni con l'uso della swap

Gestire la cache di npm e considerazioni per Docker

Considerazioni per Docker

Dividere il monitor in 4 terminali con Terminator

Stampare un elenco dei processi ordinato per la quantità di swap che usano

Modificare allarme di spazio libero per un disco in Netdata

✔️ Soluzione 1 – Tunnel SSH + `psql` locale (consigliata)

✔️ Soluzione 2 – Promuovere temporaneamente `admin` a superuser

Backup con `pg_dump`

Metodo consigliato: `.pgpass`

2️⃣ Ripristino da file Custom o Directory (`.dump`, `.bak`)

Ripristino in parallelo (solo con `pg_restore`)