What is your best varieties of cabbages have you ever grown from your garden?
And could you share why you liked that variety?
On the other hand,let me know how one of your best growings weighed.
And could you also share some challenges that you undergone as you practised cabbage growing and how you overcome them?
#vegetables #cabbage #gardening #photography #fediverse #linux #mastodon #food #Climate #ClimateChange #garden #agriculture #sustainability #farming #wednesday #farmlife #nature

Le ultime settimane sono state molto particolari, soprattutto per l’attivismo online italiano e per il fattore sicurezza.

Da poco, degli attivisti italiani sono stati attaccati sulla loro piattaforma, riaccendendo il dubbio in tutti noi, di quanto siano sicuri i nostri portali e siti web. Sono stato il primo, che ho rivisto un po’ tutte le impostazioni, per essere sicuro di non aver tralasciato nulla.

Dopo aver rivisto il contesto, ed essermi assicurato di essere meno esposto possibile, vorrei iniziare questa guida ricordando una regola fondamentale:

“Se quel dato non lo conservi, non può essere rubato.”

Primo passo, tutto deve essere aggiornato…Gli aggiornamenti non migliorano solo le prestazioni o gli aspetti meramente funzionali ed estetici del tuo sito web, ma spesso includono importanti miglioramenti in termini di sicurezza e stabilità. Assicurati di avere le versioni più aggiornate di tutto ciò che concerne il tuo portale.

ATTENZIONE! IL BACKUP E’ DA ADESSO FORTEMENTE CONSIGLIATO – NEXTRED SI SOLLEVA DA OGNI RESPONSABILITÀ

Procediamo con ordine. Io controllerei e relativamente aggiornerei ad ultima versione i seguenti elementi:

versione di WordPress;

versione PHP;

MySQL/MariaDB;

plugin;

tema;

plugin e temi non più utilizzati.

L’ultima voce segnala plugin e temi non utilizzati. WordPress stesso, nella sezione Stato di Salute del tuo Sito, ti consiglia di disinstallare tutto ciò che non utilizzi. Non per una questione di mero ordine, quando per la riduzione effettiva della superficie d’attacco. Il fatto che un plugin o un tema non sia attivo, non significa che non potrebbe essere vulnerabile comunque. Il consiglio è comune di mantenere un tema di backup, nel caso quello in uso dovesse in qualche modo rompersi. Comunemente si tende a lasciare uno dei temi preimpostati di WordPress. La comodità deriva dal fatto che i temi sono leggeri e mantenuti.

Altra cosa importante, è ricordarsi che un plugin non mantenuto ma di cui non si segnalano vulnerabilità non è necessariamente migliore di uno in cui si sono resi conto di una vulnerabilità e hanno corretto il problema con una patch. Scegli sempre software mantenuto e che garantisca aggiornamenti di sicurezza minimi.

Secondo passo, (pre)occupati del file wp-config.php…Il file wp-config.php è essenzialmente uno dei file più delicati del tuo sito. All’interno ci trovi molte informazioni importanti. Informazioni per accedere al database e chiavi wordpress e tante altre informazioni utili possono essere estrapolate da questo file.

In generale, se su un forum ti stanno dando assistenza, mai copiare ed inviare queste informazioni:

DB_NAME
DB_USER
DB_PASSWORD
DB_HOST
Authentication Keys
Salts
API keys e token

Quando compatibile è buona norma negare l’accesso tramite webserver:

<Files “wp-config.php”>
Require all denied
</Files>

Attenzione però non è una buona idea aggiungere codice a caso preso da internet. Nell’articolo io inserirò una serie di comandi, che dovrete voi valutare e vagliare e comprendere se compatibile con il vostro sito e le impostazioni scelte.

Terzo passo, se qualcuno entra è meglio far trovare porte chiuse…Il rischio c’è, dobbiamo dircelo. C’è sempre. Dunque se qualcuno entra, o riesce ad utilizzare una vulnerabilità per aumentare i privilegi fino ad amministratore, potrebbe trovare porte aperte dovunque. Se però tu chiudi tutto, a lui sarà più complesso aprire ogni porta (cosa che ovviamente presumibilmente potrà fare comunque) e a te sarà concesso più tempo per bloccare accessi e prenderti nuovamente la gestione del tuo sito.

L’edito di codice di wordpress è uno strumento molto importante, ma al contempo non sempre necessario. Se è qualcosa che normalmente utilizzi, puoi superare questo paragrafo, altrimenti conviene disabilitare la funzionalità sempre dal file wp-config.php.

(A QUESTO PUNTO MI ASPETTO CHE TU ABBIA GIA’ FATTO UN BACKUP, SE ANCORA NON L’HAI FATTO, PENSA A QUANDO È COMODO AVERE UNA COPIA DI CIÒ CHE C’ERA PRIMA DI ROMPERE TUTTO)

Inserisci nel file suddetto:

define( ‘DISALLOW_FILE_EDIT’, true );

Questo blocca la possibilità ad un nuovo amministratore di mettere mano a plugin e temi direttamente. Ovvio che se ha accesso non a wordpress ma al tuo FTP, CPanel oppure al tuo account host il giochetto non funziona. Motivo per cui le password devono essere sempre differenti e l’autenticazione a due fattori sempre attiva.

Attenzione! Non confondiamo però il comando scritto con il seguente:

DISALLOW_FILE_MODS

Questo infatti ha conseguenze molto più vaste. Il rischio è di bloccare aggiornamenti e funzionalità essenziali del sito.

Quarto passo, siamo sicuri che tutti i file debbano essere alla portata di tutti…Se stai avendo problemi ad accedere a dei file, oppure a fare funzionare qualcosa, concedere permessi illimitati di una cartella in modo che il tuo flow non si blocchi, non è per niente una buona idea. Ci sono bot e malintenzionati che non vedono l’ora di mettere mano a configurazioni errate di questo genere.

Normalmente, file e directory avranno impostazioni

File:       644
Directory:  755

Ma ovviamente bisogna discriminare con attenzione i permessi che vogliamo concedere. Non possiamo dunque dire che questa è una regola generale: hosting, ownership, PHP handler e configurazioni server possono essere diversi.

Dunque attenzione. 777 è una configurazione molto rischiosa. Se l’avete scelta per risolvere problemi di permessi avete appena aperto una porta a dei malintenzionati. E se ve ne dimenticate, sarà anche molto arduo ritrovare la vulnerabilità.

Quinto passo, non tutti i file che potrebbero essere letti, devono essere letti….Alcuni file, non hanno ragione di essere consultabili. Per tal motivo si può impedirne l’accesso HTTP. Un esempio interessante è l’aggiunta della configurazione

BEGIN SITE SECURITY

<FilesMatch “^(wp-config.php|.htaccess|readme.html|license.txt)$”>
  Require all denied
</FilesMatch>

END SITE SECURITY

Giusto per essere un po’ più essenziali, ricordiamo che queste aggiunte di codice vanno inserite fuori dai blocchi generali creati da WordPress per il funzionamento. Il rischio è che venga visto come una modifica di quel blocco e al primo aggiornamento interamente cancellato. Dunque se troviamo un # BEGIN WordPress / # END WordPress o qualcosa di simile riguardo plugin e altro, meglio non inserire nulla tra i due hashtag.

Sesto passo, attenzione alla cartella upload, la porta di ingresso alla tua fortezza…Ovviamente non si può dare ad un utente non registrato la possibilità di caricare in upload tutti i file che si vuole. Sarebbe da sprovveduti e anche un po’ da folli.

Ma anche l’upload da utenti con livelli di accesso superiori (incluso gli amministratori) dovrebbero essere limitati. Nella cartella wp-content/upload salvo necessità differenti, dovrebbero starci file PDF, o immagini di vario formato. Se dovesse esserci codice PHP, questo non dovrebbe avviarsi.

Per tal motivo buona norma è quella di rimuovere la possibilità di eseguire un file PHP in upload. Si può utilizzare una configurazione, come segue, di un file .htaccess dedicato all’interno della cartella upload (versione Apache permettendo):

Prevent PHP execution in uploads

<FilesMatch “.(php|php[0-9]?|phtml|phar)$”>
    Require all denied
</FilesMatch>

Questo può creare una ulteriore difesa. Soprattutto nel caso una vulnerabilità concedesse ad un malintenzionato di caricare un file php. A quel punto, bloccare la sua esecuzione è l’ultima linea di difesa.

Settimo passo, i Security Headers…Un intervento che possiamo fare è quello di sfruttare alcune impostazioni dei nuovi browser. Le seguenti impostazioni sono relativamente conservative.

Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"Gli header che hai appena letto, intervengono su: MIME sniffing (intercettazione passiva dei dati), embedding/framing delle pagine e quantità di informazioni trasmesse attraverso il Referer (Nel protocollo HTTP, il referer o HTTP referer è un campo di intestazione HTTP opzionale che identifica l’indirizzo della pagina web da cui è stata richiesta la risorsa. Cit. Wikipedia).

Attenzione! non è sufficiente inserire codice per essere sicuro che questo funzioni. Ricorda di provare dal terminale Linux, la risposta dei cambiamenti effettuati

curl -I https://example.org/

Infatti può succedere che cache, configurazione hosting, CDN e reverse proxy cambino la risposta finale

Ottavo passo, laddove possibile prediligere HSTSHSTS è l’acronimo di HTTP Strict Transport Security. Si tratta di un metodo utilizzato dai siti Web per dichiarare che dovrebbe essere accessibile solo utilizzando una connessione sicura (HTTPS). Se un sito Web dichiara un criterio HSTS, il browser deve rifiutare tutte le connessioni HTTP e impedire agli utenti di accettare certificati SSL non sicuri.

Se il sito è totalmente disponibile su HTTPS, ed è attivato il redirect di HTTP, è possibile pensare a HSTS. I moderni browser lo supportano senza grossi problemi.

Header always set Strict-Transport-Security “max-age=2592000”

solitamente si imposta 31536000 (1 anno) come età massima. 2592000 invece equivale ad un mese. E va bene nelle prime fasi di testing.

Controllate che la risposta sia corretta richiamando dal terminale:

curl -I http://example.org/
curl -I https://example.org/

Nono passo, impedite di attivare funzionalità non utili nel vostro sito…Se per il tuo sito non è essenziale geo-localizzazione, fotocamera e microfono, bloccate tutto a monte. Dire semplicisticamente che non esistono come funzionalità non significa chiudere quelle porte. Se non servono, chiudete!

Header always set Permissions-Policy “camera=(), microphone=(), geolocation=()”

Decimo passo, proteggi l’amministratore…L’amministratore è il re della fortezza. E la tua fortezza deve difendere anche chi ha il potere di modificarla o peggio farla sparire. Non puoi usare una semplice password per difendere l’account (o gli account) più importanti e critici del sito.

Prima di tutto, non tutti devono essere amministratori. Rivedi le tue policy, e riduci il numero di amministratori. Inoltre attiva la funzionalità di accesso a doppio fattore. Aumenta gli standard minimi delle password, o meglio usa un password manager. Proteggi anche le email degli amministratori con autenticazione a due fattori. Monitora periodicamente le sessioni attive.

Undicesimo passo, controlla XML-RPC e REST APIL’idea iniziale è di bloccare tutto. Ma se il tuo sito è federato o ha delle funzionalità particolari, questi endopoint possono essere utili. Su questo è meglio approfondire il discorso in un altro articolo. Ma sappi che anche questo va controllato. Bloccare questi endopoint può ridurre la superficie d’attacco e avere maggiore resistenza nei brute-force e attacchi, ma è legato anche al malfunzionamento di alcuni plugin importanti del sito.

Dodicesimo passo, se hai due copie del sito web puoi rinascere velocemente…Il backup è una panacea. Due backup è perfezione. Lascia che il tuo servizio di hosting faccia il backup periodico, ma non lasciare tutto solo a lui. Ciclicamente, salva in locale il tuo sito e le tue impostazioni. E’ il modo migliore per proteggersi da eventuali perdite di dati.

Dunque, lascia che il provider faccia il suo backup, ma tu salva le varie versioni del tuo sito. Può essere comodo!

Tredicesimo passo, non conservare nulla…So che questo non è hardening. Ma in senso lato può essere considerato tale. Non avere dati di alcun genere sul vostro sito web è una buona scelta. Se non c’è nulla, non si può rubare nulla. Inoltre se non c’è nulla, perché non entrare altrove allora? Prediligi la privacy dell’utente e non raccogliere informazioni se riesci. Questo ti renderà una vittima poco interessante.

Chiudiamo questa guida…Questa guida non ha la presunzione di difendervi dai mali dell’internet, ma spero che vi faccia interrogare su ciò che deve essere fatto per migliorare e proteggere il vostro sito web. Fare hardening significa indurire e ridurre la superficie esposta. Lo scopo è quello di rispondere prontamente e rendere complesso il lavoro dei malintenzionati che hanno scelto voi come vittima.

Link e Fonti:

https://developer.wordpress.org/advanced-administration/security/hardening/

https://xlogic.org/kb/knowledgebase/xml-rpc-wordpress-sicurezza/

Coretech – https://www.coretech.it/it/service/articoli/articoli.php?ID=1281

Wikipedia – https://it.wikipedia.org/wiki/Referer

Hey folks, GYM needs your assistance to acquire land through your donation or even sharing with your network about our cause.
One share can create more awareness and impact.
Just an update, we have not received any donation in the previous ten days and this keeps us late to achieve land for our home where we can do more work permanently.
https://gofund.me/8da0ff4a0

#mastodon #Fediverse #linux #Photography #nature #agriculture #climate #ClimateChange #ClimateCrisis #ClimateDiary #climateemergency

Hey folks, GYM needs your assistance to acquire land through your donation or even sharing with your network about our cause.
One share can create more awareness and impact.
Just an update, we have not received any donation in the previous ten days and this keeps us late to achieve land for our home where we can do more work permanently.
https://gofund.me/8da0ff4a0

#mastodon #Fediverse #linux #Photography #nature #agriculture #climate #ClimateChange #ClimateCrisis #ClimateDiary #climateemergency

Shotwell da el salto a la versión 33, con un importante cambio a GTK4, corrije multitud de fallos y se prepara para seguir evolucionando en versiones futuras.

https://www.linuxadictos.com/shotwell-33-llega-con-el-ansiado-port-a-gtk4.html

#Shotwell #Gnome #fotografía #photography #Gnu #Linux #SoftwareLibre #opensource

🇨🇭🐀 La Svizzera apre a Opendesk, una piattaforma open source per posta, documenti, calendario e videoconferenze.

Entro il 2027 sarà disponibile per circa 3.000 dipendenti federali. Non una fuga immediata da Microsoft, ma indipendenza digitale costruita passo dopo passo.

@opensource@diggita.com

#OpenSource #DigitalSovereignty #Linux

Some folks are confused about #BrightTable. Fair, because it isn't your ordinary photo viewer.

If you have Immich installed and edit raw files, this product is for you. If you don't know what either of those things are, take a look at #shotwell.

I put these two explainer slides together to better describe the concept of BrightTable.

https://github.com/brownphotographic/BrightTable

#Immich #RawTherapee #DarkTable #Linux #Photography #foss

A little stop-motion of trains arriving at the U-Bahn station.

Made from 99 burst shots. The images were resized with ImageMagick and combined into an animated WebP with FFmpeg at 15 fps.

#Vienna #Wien #Ubahn #WienerLinien #TrainPhotography #Trainspotting #PublicTransport #UrbanPhotography #RainyVienna #RainyDay #StreetPhotography #Photography #Längenfeldgasse #ImageMagick #FFmpeg #WebP #Linux

Ciao! 👋 #Introduction #Introduzione

Dev / system architect e content creator su YouTube per hobby. 🎬

Qui per fare rete, confrontarmi e condividere risorse tech.

💻 Temi:
• Linux & Open Source
• Self-hosting & Home Lab
• Architettura software

🔗 Canale YouTube: https://www.youtube.com/@conte_zero

Cerco account da seguire, un boost è super gradito! 🐘

#Linux #Opensource #SelfHosting #HomeLab #TechIta #technology #developers #devita

Il sintomo che inganna: load average alto, CPU quasi fermaCapita spesso a chi gestisce server #Linux in produzione: il monitoraggio segnala un load average sopra 30 su una macchina con 24 core, gli utenti si lamentano di risposte lente, ma top mostra la #CPU idle al 70%. Il riflesso istintivo è cercare il processo che “mangia CPU”, ma qui il colpevole non c’è da nessuna parte nella lista dei consumi di calcolo: il collo di bottiglia è l’I/O su disco, e la differenza tra i due scenari cambia completamente la strategia di intervento.

Il load average di Linux non misura solo i processi che vogliono la CPU: conta anche quelli bloccati in stato D (uninterruptible sleep), cioè in attesa che il #kernel completi un’operazione di I/O. Un load di 30 con CPU libera significa quasi sempre che decine di thread sono in coda per il disco, non per il processore. Diagnosticare questo scenario richiede un metodo diverso da quello usato per un semplice sovraccarico di calcolo, e la differenza si vede negli strumenti da usare e nell’ordine in cui usarli.

Il metro di misura: I/O wait e perché da solo non bastaL’I/O wait (colonna wa in top) è la percentuale di tempo in cui la CPU è rimasta inattiva pur avendo almeno una richiesta di I/O ancora in sospeso. È un indicatore utile ma ingannevole: se il sistema ha altro lavoro da eseguire mentre il disco è lento, la CPU si tiene occupata e il valore di wa scende, anche se lo storage sottostante continua a rispondere altrettanto male. Per questo motivo l’I/O wait va sempre incrociato con metriche a livello di dispositivo, non usato come unico segnale.

Il flusso diagnostico corretto segue quattro passaggi in sequenza:

Controllare load average e colonna wa in top (premendo 1 per espandere le statistiche per singolo core)

Confermare il sospetto a livello di dispositivo con iostat -xz 1 o /proc/pressure/io

Solo a questo punto, andare a caccia dei processi responsabili con atop e iotop

Misurare in modo oggettivo con un benchmark reale (dd o fio), perché un numero concreto chiude ogni discussione

Passo 1 — Individuare i processi bloccatiPrima di aprire strumenti dedicati, un controllo rapido dei processi in stato “uninterruptible sleep” dà già un’indicazione:

ps -eo state,pid,comm | grep "^D"Se questo comando restituisce più righe, ripetutamente, su un sistema che dovrebbe essere reattivo, l’ipotesi I/O-bound si rafforza. Il passo successivo è capire quanto è grave la situazione a livello di dispositivo di blocco.

Passo 2 — iostat: la vista a livello di dispositivoiostat -xz 1I flag hanno un significato preciso:

-x: statistiche estese, incluse le latenze medie di lettura e scrittura

-z: nasconde i dispositivi inattivi, per non affollare l’output con righe a zero

1: intervallo di refresh in secondi

Le colonne da guardare con attenzione sono r_await e w_await, che esprimono in millisecondi il tempo medio di attesa per operazione di lettura e scrittura: su storage sano questi valori restano a una cifra; valori a due o tre cifre indicano un disco sotto stress severo. La colonna %util va invece presa con cautela sui dispositivi SSD/NVMe, dove può risultare fuorviante a causa del parallelismo interno dei controller moderni, che gestiscono più richieste contemporaneamente senza che questo si traduca in saturazione reale.

Un dettaglio pratico spesso ignorato: il primo report stampato da iostat va scartato, perché media tutte le statistiche dall’avvio del sistema e può “truccare” in positivo un disco che in realtà ha iniziato a comportarsi male solo poche ore prima.

Passo 3 — Pressure Stall Information: la metrica più modernaDai kernel 4.20 in poi è disponibile un meccanismo più sofisticato dell’I/O wait tradizionale: la Pressure Stall Information (PSI), esposta in /proc/pressure/io:

cat /proc/pressure/ioUn output tipico in condizioni di forte stress si presenta così:

some avg10=44.21 avg60=39.07 avg300=31.88 total=8814592211
full avg10=38.90 avg60=35.62 avg300=29.15 total=7913804412La riga some indica la percentuale di tempo in cui almeno un task era bloccato in attesa di I/O; la riga full indica la percentuale di tempo in cui tutti i task non idle erano bloccati contemporaneamente — un segnale molto più grave, perché significa che l’intero sistema è fermo in attesa dello storage. Su alcune distribuzioni PSI richiede il parametro di avvio del kernel psi=1 per essere attivo; vale la pena verificarlo prima di fare affidamento su questi dati in produzione.

Passo 4 — Trovare il colpevole con atop e iotopUna volta confermato che il collo di bottiglia è reale a livello di dispositivo, resta da capire quale processo lo sta generando.

atop mostra le statistiche di I/O per disco direttamente nella vista principale; premendo d durante l’esecuzione si passa alla vista dedicata ai processi che stanno consumando I/O. È utile anche per individuare thread kernel come flush-8:0 (il thread di writeback che scarica su disco le pagine sporche dalla cache) o jbd2/sda5-8 (il journaling di ext4), che spesso vengono scambiati per processi “misteriosi” da chi non li conosce.

iotop offre una vista più mirata:

iotop -oPa-o (--only): mostra solo i processi che stanno effettivamente generando I/O in quel momento

-P (--processes): aggrega per processo invece di elencare ogni singolo thread

-a (--accumulated): mostra il totale di I/O accumulato dall’avvio dello strumento, utile per individuare pattern intermittenti

Un requisito spesso trascurato: dal kernel 5.14 il delay accounting è disabilitato di default, e senza di esso iotop non riesce a calcolare correttamente le statistiche per processo. Va abilitato con:

sudo sysctl kernel.task_delayacct=1Per renderlo persistente ai riavvi è necessario aggiungere delayacct ai parametri di boot del kernel (tramite GRUB), oltre a impostare il sysctl in /etc/sysctl.d/.

Chiudere la discussione con un numero: dd e fioQuando la diagnosi è fatta, spesso serve convincere qualcun altro (un cliente, un team infrastrutturale, un fornitore di storage) che il problema è reale. Un test rapido e riproducibile con dd:

dd if=/dev/zero of=diskbench bs=1M count=1024 conv=fdatasyncIl flag conv=fdatasync è essenziale: forza la sincronizzazione dei dati su disco prima che dd riporti il tempo trascorso, altrimenti si misurerebbe solo la velocità della cache di scrittura del kernel. Un risultato come “1073741824 bytes (1.1 GB) copiati, 46.0156 s, 23.3 MB/s” su uno storage che dovrebbe erogare centinaia di MB/s parla da solo, ed è molto più difficile da contestare di un’opinione: un host può discutere con la vostra opinione, molto più difficilmente lo farà con 23,3 MB/s misurati.

Per un quadro più completo, che tenga conto anche di IOPS e latenza sotto carico concorrente (lo scenario tipico di un database o di un server #web sotto traffico reale), lo strumento di riferimento è fio, che permette di simulare pattern di accesso realistici con più job paralleli, dimensioni di blocco configurabili e miscele di letture/scritture.

Il caso reale: quando il disco lento innesca un effetto dominoUn caso concreto che vale la pena analizzare riguarda un server con un’istanza MySQL configurata con max_connections=2000, un valore decisamente eccessivo per l’hardware disponibile. Ogni connessione MySQL alloca buffer per-thread; moltiplicando la memoria per singolo thread per il numero massimo di connessioni e sommando i buffer globali, il calcolo della memoria potenzialmente necessaria superava ampiamente la RAM installata.

Finché il traffico restava basso, il problema non si manifestava. Ma con un disco già lento (a causa di I/O wait elevato) e un picco di connessioni concorrenti, le richieste si sono accumulate in coda, la pressione di memoria è salita rapidamente, e l’OOM killer del kernel è intervenuto terminando processi critici. Un problema di storage, in altre parole, si è propagato fino a diventare un incidente di memoria e disponibilità.

Buone pratiche per prevenire il problemaAlcune misure pratiche riducono sensibilmente il rischio di trovarsi in questa situazione:

Ridurre la frequenza di scrittura dei log di #Nginx/Apache in scenari ad alto traffico, dove i log di accesso possono generare un volume di I/O sorprendentemente alto

Spostare la cache in memoria (ad esempio su tmpfs) invece che su disco durante i picchi di concorrenza, per eliminare completamente la latenza di storage dal percorso critico

Dimensionare correttamente pm.max_children in #PHP-FPM: un valore troppo basso rifiuta traffico legittimo, uno troppo alto amplifica la pressione su disco e memoria nello stesso momento

Valutare l’hardware: il salto da storage a rotazione a SSD, e da SSD a NVMe, cambia le soglie di r_await/w_await di un ordine di grandezza

Introdurre un livello di #caching come Varnish davanti all’applicazione, una volta che la cache è “primed” e può assorbire la maggior parte delle richieste senza toccare il backend

ConclusioneUn load average alto con CPU libera non è un paradosso: è un sintomo preciso che indica dove guardare. Il metodo — top per una prima ipotesi, iostat e PSI per confermarla a livello di dispositivo, atop/iotop per individuare il processo responsabile, e un benchmark con dd o fio per quantificare il problema in modo indiscutibile — si applica a qualunque stack, dai database ai server web, ed evita di perdere tempo a ottimizzare la CPU quando il vero collo di bottiglia sta girando a 23 MB/s su un disco che dovrebbe farne dieci volte tanto.

Fonte originale: Linux server performance: Is disk I/O slowing your application? – LinuxBlog.io

Container gardening helps to use every space available for production.
We need to educate this to everyone since food insecurity increases every day especially in Central Uganda.
#gardening #agriculture #sustainability #Climate #food #ClimateCrisis #Economy #environment #Linux #Fediverse #Mastodon #farming #soil #raisedgardenbed #plants #SilentSunday #solarpunk #solarpunksunday #Sunday #photography #NaturePhotography #food #wastemanagement #productivity #recycling #reusematerials #plastic

Perché il TLS handshake è ancora il vostro nemico nascosto del TTFBIl 95% del traffico #web oggi viaggia su HTTPS, ma la maggior parte delle configurazioni #Nginx in produzione #usa ancora i parametri di default che erano ragionevoli cinque anni fa e oggi lasciano sul tavolo decine di millisecondi di Time To First Byte. La buona notizia è che si tratta quasi sempre di ottimizzazioni “una tantum”: si toccano poche direttive, si ricarica Nginx e il guadagno resta lì, per ogni richiesta, per sempre.

In questo articolo vediamo come intervenire su cache di sessione, cifrari, buffer TLS, HTTP/3 e header di sicurezza, con un occhio a cosa è cambiato di recente (OCSP stapling è ormai carta straccia con Let’s Encrypt, HTTP/3 con 0-RTT richiede #OpenSSL aggiornato) e cosa invece continua a essere un mito da sfatare.

Il conto salato dell’handshake TLS ripetutoOgni nuova connessione TLS 1.2 costa un round trip aggiuntivo rispetto a una connessione già “nota” al server; TLS 1.3 lo riduce a un solo round trip nel caso normale, e a zero con il resumption. Il problema è che di default la session cache di Nginx è minuscola e la sua durata troppo breve per traffico reale distribuito su più server.

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets on;
Un dettaglio che quasi nessuno controlla: 1 MB di cache condivisa contiene circa 4.000 sessioni. Con 10m si arrivano a 40.000 sessioni attive, un valore ragionevole per un sito di media grandezza ma da ricalcolare se avete decine di migliaia di client concorrenti (osservate ssl_session_cache statistiche via nginx -V con modulo stub_status compilato, oppure strumentate a livello di access log).

Se gestite un parco di più server dietro un load balancer, i session ticket devono usare la stessa chiave su tutte le istanze, altrimenti ogni volta che il bilanciatore sposta il client su un nodo diverso l’handshake riparte da zero, vanificando il resumption. La chiave va generata una volta e distribuita in modo sicuro (es. tramite un secret manager), non rigenerata ad ogni deploy.

Cifrari: meno scelta, meno lavoro per la CPUSu TLS 1.3 il set di cifrari è già ristretto e sicuro per design, ma su TLS 1.2 — che va ancora mantenuto attivo per compatibilità con client legacy su siti pubblici — vale la pena essere espliciti ed escludere tutto ciò che non è AEAD (GCM o ChaCha20-Poly1305):

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:
ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
Nota sul ssl_prefer_server_ciphers off: con TLS 1.3 e client moderni è il client a scegliere in modo sensato, quindi forzare l’ordine lato server (utile in epoca TLS 1.0/1.1 per evitare cifrari deboli) oggi aggiunge solo complessità. Se avete ancora bisogno di forzare l’ordine per policy di #compliance, impostatelo su on e mantenete la lista sopra come riferimento.

Per non reinventare la ruota ogni volta, usate il generatore di configurazione SSL di Mozilla, che tiene aggiornati i profili “modern”, “intermediate” e “old” in base alle #CVE e al supporto #browser corrente.

Il buffer TLS che nessuno ridimensionaUna delle ottimizzazioni meno note e più efficaci riguarda ssl_buffer_size. Di default Nginx usa un buffer da 16 KB per i record TLS, pensato per massimizzare il throughput su file di grandi dimensioni. Per pagine HTML, API JSON e asset piccoli — cioè la stragrande maggioranza del traffico applicativo — questo significa che il client deve attendere di ricevere l’intero buffer prima di poter iniziare a renderizzare qualsiasi cosa.

ssl_buffer_size 4k;
Riducendo il buffer a 4 KB il primo record TLS utile arriva prima, con un impatto misurabile sul TTFB percepito (tipicamente nell’ordine di 30-50ms su connessioni con latenza medio-alta). Il compromesso è un overhead leggermente maggiore per trasferimenti di grandi file per via del maggior numero di record; per questo motivo, se servite prevalentemente download di file di grandi dimensioni da un host dedicato, vale la pena valutare un buffer intermedio (es. 8k) o configurazioni separate per server block diversi.

OCSP stapling: una direttiva ormai innocuaPer anni la configurazione “corretta” includeva l’OCSP stapling per evitare che il browser dovesse contattare l’authority per verificare la revoca del certificato:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /path/to/full_chain.pem;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
Se usate Let’s Encrypt, sappiate che questa configurazione oggi non fa più nulla: dal 6 agosto 2025 Let’s Encrypt ha terminato il supporto agli endpoint OCSP, spostandosi esclusivamente su Certificate Revocation List (CRL) a corto raggio. Non è un errore lasciare le direttive nella configurazione (sono semplicemente inerti), ma se il vostro certificato proviene da un’altra CA verificate lo stato del suo servizio OCSP prima di considerarle superflue.

HTTP/3 e QUIC: attenzione al firewall, non solo a NginxHTTP/3 è disponibile in mainline Nginx dalla versione 1.25.0 e nei pacchetti binari ufficiali di nginx.org; l’adozione globale è ancora intorno al 21% contro il 50%+ di HTTP/2, ma per applicazioni con utenti su reti mobili o ad alta latenza il guadagno di QUIC (0-RTT, niente head-of-line blocking a livello di trasporto) è reale.

listen 443 ssl;
listen 443 quic reuseport;
http2 on;
add_header Alt-Svc 'h3=":443"; ma=86400';
Due avvertenze pratiche, spesso trascurate:

reuseport deve comparire su una sola direttiva listen, altrimenti Nginx non parte o bilancia male tra i worker.

QUIC viaggia su UDP: se la porta 443/UDP non è aperta sul firewall, il fallimento è silenzioso. Il browser prova QUIC, non riceve risposta e ricade automaticamente su HTTP/2 senza loggare alcun errore visibile lato client. Verificate esplicitamente con ufw allow 443/udp (o l’equivalente per il vostro firewall) e controllate con curl --http3 o la colonna “Protocol” di #Chrome DevTools.

Per il 0-RTT (early data) su QUIC serve OpenSSL 3.5.1 o successivo: con versioni precedenti HTTP/3 funziona comunque, semplicemente senza questa ottimizzazione aggiuntiva sul primo round trip.

Header di sicurezza che costano zero millisecondiNon influenzano il TTFB ma sono ormai lo standard minimo per qualunque endpoint HTTPS in produzione:

add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
add_header X-Frame-Options sameorigin;
add_header X-Content-Type-Options nosniff;
Da notare: X-XSS-Protection va rimosso, non aggiunto — i browser moderni lo ignorano e in alcuni casi storici introduceva vulnerabilità XSS reflected invece di prevenirle.

Il limite di questa ottimizzazione: dove il TLS tuning non arrivaVale la pena essere onesti su un punto: il tuning TLS riduce l’overhead del trasporto sicuro, ma non corregge un’applicazione lenta. Se il vostro TTFB è dominato da query database non indicizzate, da un backend PHP-FPM sottodimensionato o dall’assenza di una cache applicativa, i millisecondi guadagnati qui sono nell’ordine del rumore statistico rispetto ai secondi persi altrove. Il tuning TLS va trattato come l’ultimo 10% dell’ottimizzazione, da applicare dopo aver sistemato caching, query e CDN — non come sostituto.

Procedura di verificaDopo ogni modifica, il ciclo è sempre lo stesso:

nginx -t
nginx -s reload
nginx -t valida la sintassi prima del reload, evitando downtime per un errore di battitura in produzione. Per validare l’effetto reale, misurate il TTFB prima e dopo con strumenti come curl -w "%{time_starttransfer}\n" -o /dev/null -s https://vostro-sito.tld ripetuto più volte, oppure con WebPageTest per una view completa lato client reale.

ConclusioneNessuna di queste modifiche richiede un downtime pianificato o un cambio architetturale: sono direttive di configurazione che si testano e si applicano in pochi minuti. Il ritorno, moltiplicato per milioni di richieste al mese, è tutt’altro che trascurabile — ed è uno di quei rari casi in cui “ottimizzazione infrastrutturale” non significa comprare più hardware, ma semplicemente smettere di lasciare Nginx sui default di cinque anni fa.

Fonte originale: Nginx tuning tips: HTTPS/TLS – Turbocharge TTFB/Latency, LinuxBlog.io. Approfondimenti aggiuntivi su HTTP/3 in produzione: Serving HTTP/2 and HTTP/3 with Nginx in 2026.

The main aim is to plant a tree. We are over 8 billion world citizens, and what could happen if each of us planted a tree just near where everyone lives?
Here at GYM,we are looking forward to promote birthday tree cakes as the strategy for whoever celebrates the birthday, he has to plant a fruit 🌳
#Photography #NaturePhotography #ClimateChange #ClimateCrisis #ClimateDiary #climateemergency #nature #solarpunk #Mastodon #linux #Photography #Trees #biodiversity #environment #climate #ecosystem

Hello folks, I have people's fundraisers move on to the goal and even exceeding its goal that was set,but I do not know what is wrong with ours!

I am reaching out for everyone who appreciates the work of GYM that is being done in the communities to join us and find possible ways on how we can raise land that we want to use in the bext season.

Your advice today, may be a pillar to getting land.
#Fediverse ##solarpunksunday #Climate #food #Photography #linux #Monsterdon #environment #nature

This almost looks impressive if you don't know this is an ancient laptop that belonged to my mother, now fighting for it's life just to run Lubuntu.

It's connected to the cheapest monitor I could find in my Madagascar neighborhood. (I really need a new computer.)

It's surprisingly hard to find laptops with QWERTY keyboards in Madagascar.

#Ubuntu #Lubuntu #Linux #Madagascar #Antananarivo #Photography #OriginalPhoto #HalfHeartedFanatic

Last review of the season, and let's go to the point: it's a bad model. I don't recommended this one. I'm not even submitting the video to Gaomon for review before posting because I know they would ask me to not post it (it happened in the past with another brand). But I think it should be also known, that's my role in reviews: cover the bad and the good.

• On Youtube: https://www.youtube.com/watch?v=YOf02Ss4HvY
• On Peertube: https://peertube.touhoppai.moe/w/eFHWMqujXHNvTo7NeDuvvB

#linux #hardware #gaomon #review

STOP DOING SWAP PARTITIONS

HARD DRIVES WERE NOT SUPPOSED TO ACT LIKE RAM

YEARS OF LINUX SYSADMINNING yet NO REAL-WORLD USE FOUND for going beyond CLOSING A FEW TABS

Wanted to avoid the OOM killer anyway for a laugh? We had a tool for that: It was called ZRAM

"Yes please give me a dedicated 64GB logical volume of SWAP. Please give me unresizable block devices trapped at the end of my disk." - STATEMENTS DREAMED UP BY THE UTTERLY DERANGED

LOOK at what Neckbeards have been demanding your Respect for all this time, with all the fdisk and GParted Live USBs we built for them. (This is REAL PARTITIONING, done by REAL LINUX USERS):

mkswap /dev/nvme0n1p3

echo /dev/nvme0n1p3 none swap sw 0 0 >> /etc/fstab

swapon -a

"Hello I would like to torture my SSD's FTL because I left three Electron apps open."

They have played us for absolute fools.

#linux #sysadmin

Greetings #mastodon.
I had a deep thought today and I need your contribution!
[1]Could the world face hunger if each person knew how to grow food and has access to the land to grow from? https://gofund.me/8da0ff4a0
[2]How many trees could the world have if each of us planted two trees as birthday tree cakes?
#environment #trees #afforestation #food #nature #fruits #gardening #agriculture #biodiversity #sustainability #linux #photography #fediverse #climate #wildlife #hunger #soil #flora #climate

Dear folks, I am reaching out requesting for your donations and boosts to our land fundraiser as we are preparing to use our own land next season for sufficient food production that will support the most vulnerable families in our communities.
One donation or boost can make a huge difference.

https://gofund.me/8da0ff4a0

#Mastodon #Fediverse #Photography #linux #Monsterdon #MutualAid #solarpunk #farming #Climate #food @chris@mstdn.chrisalemany.ca @iamchrismays@mas.to @sarahtaber@mastodon.online @JanetteSpeyer@flipboard.com @LisaMarcAurele@flipboard.com ##ClimateChange

Salve Feelers!
Siete pronti per questa nuova Stagione di video?

Ho appena finito di ristrutturare la programmazione e mi ritengo davvero soddisfatto. Mi avete chiesto un po' di recensioni a tema #linux (che arriveranno presto), nuovi software da consigliare, metodologie di lavoro e persino consigli operativi in base alla mia esperienza lavorativa!

Premesso che comunque avrò un focus sulle #tecnologie #foss ed #OpenSource , faremo anche qualche video con qualche tecnologia più di nicchia per esplorare nuove possibilità.

Mi voglio concentrare anche sulla questione #SovranitàDigitale , #AI , #fediverso e software etici. La #privacy e la #profilazione sono due temi che mi stanno particolarmente a cuore, e farò di tutto per dargli spazio nella programmazione.

Infine, parleremo tanto di attualità, avremo un po' di ospiti (il primo arriva il 3 Ottobre - spoilerone) e soprattutto mi potrete vedere anche dal vivo al @fossday@poliversity.it !

Insomma, ho preparato tutto al meglio delle mie possibilità per potervi dare la qualità che meritate, in un palinsesto che rispetta al massimo la mia attuale evoluzione, gli argomenti che mi stanno a cuore e tutti i valori che mi contraddistinguono come persona.

Io sono emozionato.
Non vedo l'ora di ricominciare a registrare ora che finalmente è tutto pronto.

#StayTuned
#FeelTechnologies