Consiglio quindi di non installare la versione di mysqltuner presente nel repository ufficiale, ma piuttosto:

wget -O /usr/local/bin/mysqltuner https://raw.githubusercontent.com/major/MySQLTuner-perl/master/mysqltuner.pl
chmod +x /usr/local/bin/mysqltuner

enjoy!

L’installazione è molto semplice:

sudo -v ; curl https://rclone.org/install.sh | sudo bash

Oppure in modo specifico per MacOS:

brew install rclone

alla prima esecuzione bisogna configurare i dati di connessione:

rclone config

Questi gli step durante la configurazione (che poi viene scritta nel file ~/.config/rclone/rclone.conf):

• Premi n per n) New remote.
• Inserisci un nome, es eu2.
• Inserisci 5 per Amazon S3 Compatibile oppure 4 per Ceph Object Storage.
• Inserisci 1 per impostare le credenziali AWS o compatibili nel successivo step.
• Inserisci access_key per access_key_id.
• Inserisci secret_key, per secret_access_key.
• Premi invio per saltare la regione
• Inserisci l’endpoint url S3, es https://eu2.storage.ext.
• Premi invio per saltare la location_constraint.
• Premi invio per saltare le acl.
• Premi invio per saltare server_side_encryption.
• Premi invio per saltare sse_kms_key_id.
• Inserisci n per Modificare la configurazione avanzata.
• Inserisci y per confermare.
• Premi q per uscire dalla configurazione.

Dopo aver configurato la connessione, vediamo i principali comandi. Ipotizziamo che il nostro server si chiami eu2.

elenco file nel bucket test su server eu2:

rclone ls eu2:test/

elenco file, con dettagli, nel bucket test su server eu2:

rclone lsl eu2:test/

copio ker.txt dal bucket test dal server eu2 sul disco locale:

rclone copy eu2:test/ker.txt .

sync da /backup/ (source) verso server eu2 sul bucket cpanel(dest):

rclone sync -P /backup/ eu2:cpanel/ --s3-no-head

creo la cartella pluto:

rclone mkdir eu2:test/pluto

sposto pippo.txt nella cartella pluto:

rclone move eu2:test/pippo.txt ue2:test/pluto/

cancello la cartella pluto ed il realtivo contenuto, tipo rm -fr:

rclone purge eu2:test/pluto

cancello il file pippo.txt:

rclone delete eu2:test/pluto/pippo.txt

montare la cartella remota pluto in locale:

rclone mount eu2:pluto /mnt --vfs-cache-mode full --vfs-fast-fingerprint --no-modtime

enjoy!

102.219.170.XXX - - [30/Mar/2026:19:45:13 +0200] "GET /16/page/15/?lang=ko HTTP/1.1" 404 154085 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36"
103.189.194.XXX- - [30/Mar/2026:19:45:13 +0200] "GET /35/page/42/?lang=ko HTTP/1.1" 404 154085 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36"
200.8.173.XXX - - [30/Mar/2026:19:45:14 +0200] "GET /21/page/23/?lang=ko HTTP/1.1" 404 154085 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36"

Si tratta sicuramente di uno scanner/bot che prova URL generati automaticamente e che non esistono nel sito. Come anticipato, il sito è attivo su WHM/cPanel ed ha nginx come reverse proxy (EA4 + nginx).

La soluzione più efficace in questo caso è creare una regola di nginx che blocchi le richieste prima ancora di essere passate ad apache.

Il file con le regole di nginx va posizionato in /etc/nginx/conf.d/users/[USERNAME]/ e chiamato con un suffisso .conf. In questo caso specifico possiamo scrivere nel file:

location ~ ^/[0-9]+/page/ {
access_log off;
return 444;
}

e poi riavviare nginx. Questo fa si che le richieste vengano direttamente chiuse senza risposta, senza scrivere log e senza avviare PHP.

enjoy!

In questo caso basterà digitare:

dpkg-reconfigure tzdata

e cambiare il fusorario da utilizzare.

enjoy!

1 – ss

ss -tulnp | grep :PORTA

2 – lsof

lsof -i :PORTA

enjoy!

Vediamo come procedere. Innanzitutto ci assicuriamo che il sistema sia aggiornato:

apt update && apt upgrade

Passiamo poi all’installazione dei pacchetti che servono:

apt install certbot python3-certbot-apache

Procediamo ora con l’emissione di un certificato. Innanzitutto bisogna assicurarsi che il sito sia raggiungibile sulla porta 80 e che anche la porta 443 sia aperta sul firewall, poi eseguiamo:

certbot --apache --agree-tos --non-interactive --no-eff-email --redirect --key-type ecdsa --email admin@example.com -d example.com

dove admin@example.com ed example.com saranno una email di riferimento ed il sito per cui generare il certificato.

I vari flag significano:

--apache: Utilizza il plugin di installazione di Apache per modificare l'host virtuale corrispondente.
--agree-tos: Accetta il contratto di abbonamento di Let's Encrypt per questo account.
--non-interactive: Impedisce al comando di interrompersi in caso di richieste relative all'account o al programma di installazione.
--no-eff-email: Rifiuta la condivisione facoltativa dell'email con l'Electronic Frontier Foundation.
--redirect: Aggiunge un reindirizzamento permanente da HTTP a HTTPS nella configurazione di Apache.
--key-type ecdsa: Richiede una chiave di certificato ECDSA in modo che Debian 11, 12 e 13 utilizzino lo stesso tipo di chiave.
--email: Imposta l'indirizzo email dell'account Let's Encrypt per il rinnovo e le notifiche di sicurezza.

Se tutto è andato a buon fine possiamo procedere con la verifica del certificato:

certbot certificates

Se abbiamo più nomi a dominio su cui abilitare il certificato HTTPS, possiamo digitare:

certbot --apache --agree-tos --non-interactive --no-eff-email --redirect --key-type ecdsa --email admin@example.com -d example.com -d www.example.com -d blog.example.com

Se invece non abbiamo un elenco o vogliamo farci chiedere come gestire l’emissione del certificato, possiamo digitare semplicemente:

certbot --apache

a cui seguiranno una serie di domande, a partire dalla scelta dei domini per cui emettere i certificati.

A questo punto resta solo da gestire il rinnovo automatico dei certificati. Possiamo digitare:

systemctl is-enabled certbot.timer
systemctl is-active certbot.timer

e se vogliamo fare un test di rinnovo senza effettivamente farlo, digitiamo:

certbot renew --dry-run

Se vogliamo verificare che il certificato sia stato correttamente emesso e sia configurato correttamente, possiamo usare il servizio, es:

https://www.ssllabs.com/ssltest/analyze.html?d=example.com

Qualora sia necessario aggiungere un nuovo dominio al certificato, possiamo digitare:

certbot --apache

scegliere i nomi a dominio per cui generare il certificato e poi espandere (premendo il pulsante E) il certificato corrente.

enjoy!

Partiamo intanto vedendo come si crea un ambiente venv:

python3 -m venv ambiente_venv

questo crea nella cartella chiamata ambiente_venv il nostro ambiente di sviluppo. All’interno di questa cartella vengono create una serie di altre cartelle (es bin, lib) con quello che ci occorre. Una volta creato l’ambiente bisogna attivarlo e questo si fa scrivendo:

cd ambiente_venv
source bin/activate

mentre per uscire basterà digitare:

deactivate

Nota: Ovviamente possiamo anche eseguire gli script python direttamente scrivendo bin/python3 in modo da avviare automaticamente l’ambiene per lo script richiamato.

A questo punto ipotizziamo di aver installato una serie di librerie e che sia necessario replicare questo ambiene su una seconda macchina. Sulla prima macchina scriviamo:

pip freeze > requirements.txt

se abbiamo prima attivato l’ambiente, oppure direttamente:

bin/pip freeze > requirements.txt

e questo creerà il classico file requirements.txt con l’elenco delle librerie installate. Ora creiamo l’ambiene venv nella seconda macchina con:

python3 -m venv ambiente_venv

poi copiamo il file requirements.txt dalla prima alla seconda macchina, attiviamo l’ambiente venv:

cd ambiente_venv
source bin/activate

ed infine reinstalliamo tutte le librerie necessarie:

pip install -r requirements.txt

enjoy!

Si è verificato un errore nel verificare la firma. Il repository non è aggiornato e verranno usati i file indice precedenti. Errore GPG: https://packages.gitlab.com/gitlab/gitlab-ce/debian bookworm InRelease: Le seguenti firme non erano valide: EXPKEYSIG 3F01618A51312F3F GitLab B.V. (package repository signing key) packages@gitlab.com

significa che la chiave GPG del repository GitLab è scaduta (EXPKEYSIG 3F01618A51312F3F) e va aggiornata/sostituita nel keyring usato da APT.

Se hai configurato GitLab seguendo le istruzioni recenti (con file in /usr/share/keyrings/), per GitLab CE di solito il keyring è /usr/share/keyrings/gitlab_gitlab-ce-archive-keyring.gpg

Puoi aggiornare così la chiave:

wget -qO- https://packages.gitlab.com/gpg.key | \
gpg --no-default-keyring \
           --keyring /usr/share/keyrings/gitlab_gitlab-ce-archive-keyring.gpg \
           --import

e questo mostrerà un avviso di conferma tipo questo:

gpg: Key 3F01618A51312F3F: "GitLab B.V. (package repository signing key) <packages@gitlab.com>" 2 new signatures
gpg: Total number of edited keys: 1
gpg: new signatures: 2

enjoy!

Questo accade sicuramente sul pacchetto util-linux 2.38 ed è stato risolto nella versione util-linux 2.39, solo che non tutte le distribuzioni aggiornano il pacchetto. Prima della versione 2.38, l’uscita alla fine del file (EOF) era abilitata a meno che more non venisse eseguito in un terminale; nella versione 2.38, l’uscita alla fine del file è stata disabilitata per impostazione predefinita per rendere more conforme alle specifiche POSIX. Come anticipato questa modifica è stata ripristinata nella versione 2.39 (ovvero l’uscita alla fine del file è ora abilitata a meno che non sia impostata la variabile d’ambiente POSIXLY_CORRECT).

Fortunatamente esiste un’opzione che abilita l’uscita alla fine del file: -e. Quindi è possibile creare un alias per more -e per ripristinare il vecchio comportamento oppure definire una variabile d’ambiente MORE come segue:

export MORE=-e

enjoy!

Creiamo un nuovo file chiamato /etc/fail2ban/filter.d/wordpress.conf in cui scriviamo:

[Definition]
failregex = ^<HOST> -.*"(GET|POST).*(/wp-login.php|/xmlrpc.php).*" 200
ignoreregex =

Ora inseriamo nel file /etc/fail2ban/jail.d/defaults-debian.conf queste righe:

[wordpress]
enabled = true
port = http,https
logpath = %(apache_access_log)s
filter = wordpress
maxretry = 5
findtime = 1800
bantime = 3600

(in questo esempio controllo se ci sono almeno 5 tentativi in 1800 secondi (30 minuti), blocco quindi per 3600 secondi (1 ora) riavviamo fail2ban:

systemctl restart fail2ban.service

e dopo qualche minuto vediamo come la regola sta funzionando:

fail2ban-client status wordpress

enjoy!