bye bye username e password per protocolli antichi

Qualche giorno fa ho ricevuto da Google una email che recitava:

Dal 30 maggio potresti perdere l’accesso alle app che utilizzano una tecnologia di accesso meno sicura

e poi:

Per proteggere meglio il tuo account, Google non supporterà più l’uso di app o dispositivi di terze parti che ti chiedono di accedere all’Account Google utilizzando solo il nome utente e la password. Dovrai invece accedere utilizzando Accedi con Google o altre tecnologie più sicure, ad esempio OAuth 2.0. Scopri di più

Presto getmail sul mio hosting privato non riuscirà più a scaricare le email di GMail e dovrò iniziare a controllare due caselle personali invece che una, oltre le altre aziendali. Di colpo mi sono sentito più vecchio, me lo aspettavo ma non ci pensavo a quando sarebbe arrivato il momento di abituarsi a nuovi metodi di autenticazione che non erano solo nome utente e password… anzi, li ho sempre evitati perché ero abituato così, con password robuste cambiate periodicamente, pensavo bastassero nonostante vedessi autenticazioni federate ed autenticazioni a due fattori nascere e diffondersi tanto da iniziare a diventare necessarie quasi pure per loggarsi sul proprio PC. Ma cosa è davvero più sicuro?

Boh

Proxmox – Ceph su nodo singolo (per test)

Qualche anno fa avevo provato a fare su Virtualbox un cluster Proxmox di 3 nodi per smanettare con Ceph, ovviamente in virtuale le performance erano ridicole ma sono rimasto sorpreso dalla resilienza che Ceph può offrire se ben dimensionato. Più avanti ho testato con due nodi bare metal ma il fatto di avere solamente porte ethernet da 1 Gigabit lo rendeva davvero poco performante. Adesso ho 3 server che si stanno liberando ed uno switch SFP+ a 10 Gigabit e penso proprio che comprerò tre schede ethernet a 10 Gigabit e proverò seriamente ad implementarlo ma visto che dai primi test che ho citato sono passati più di 5 anni e siamo arrivati a Proxmox 7 ho deciso di smanettarci per capire meglio le varie configurazioni partendo da un singolo nodo.

Ceph su un singolo nodo Proxmox è pressoché inutile tant’è che non funziona in una installazione pulita perchè giustamente ci si aspetta almeno un altro host dove effettuare le repliche, nonostante è possibile aggiungere ed inizializzare gli OSD e creare un pool questo non diviene mai operativo e lo storage non è utilizzabile. Ma facendo qualche ricerca ho trovato un folle che spiega come e cosa modificare nella configurazione per far replicare sugli stessi OSD piuttosto che su un altro host. Non è semplicissimo se non si conosce Ceph ed infatti ho imparato un sacco di cose.

E’ necessario decompilare la crush map di Ceph, modificare una riga, ricompilarla e settarla. Vediamo rapidamente come fare:

ceph osd getcrushmap -o comp_crush_map.cm
crushtool -d comp_crush_map.cm -o crush_map.cm

editare crush_map.cm e modificare la riga

step chooseleaf firstn 0 type host

con

step chooseleaf firstn 0 type osd

e poi ricompilare e settare la crush map:

crushtool -c crush_map.cm -o new_crush_map.cmceph osd setcrushmap -i new_crush_map.cm

Così lo storage pool diverrà operativo e potrete divertirvi come scimmie ad installare qualcosa in una macchina virtuale e nel frattempo giocare a mettere In/Out/Up/Down i dischi per ore e vedere come reagisce ed opera Ceph: una figata!

Switch NETONIX ed ERR_SSL_VERSION_OR_CIPHER_MISMATCH

Mi stavo accingendo a controllare la configurazione di uno switch Netonix up da un paio d’anni e mai aggiornato (perché non ha mai dato problemi e me ne sono dimenticato) e mi sono ritrovato su qualunque browser di fronte una schermata citante:

ERR_SSL_VERSION_OR_CIPHER_MISMATCH

Avevo sentito dire in questi anni che stavano aggiornando un po’ dappertutto la versione di TLS ma non me ne sono preoccupato sino ad oggi: brutta storia. Come fare? Di default il Netonix da accesso solo HTTPS e quello HTTP va esplicitato nella configurazione. Fortunatamente di default anche SSH é attivo (o l’ho attivato io e non me ne ricordo) dunque vediamo come abilitare l’accesso HTTP all’interfaccia di configurazione del nostro amato switch via ssh.

$ ssh nomeutentescelto@xxx.yyy.zzz.www

NTX-MZ-S# configure
NTX-MZ-S(config)# https-server allow-http
NTX-MZ-S(config)# exit
% Applying configuration...
Press ENTER to confirm configuration change. If you do not hit enter within 60 seconds the switch will revert to the previous configuration.

NTX-CR# exit
% Quitting

Fatto, adesso l’accesso HTTP é stato abilitato e sarà possibile accedere nuovamente all’interfaccia web. Il browser per la history forzerá HTTPS anche se togliete la ‘s’ da https:// ma con una nuova finestra anonima del browser vi fará entrare subito.

Questo é successo mentre runnavo il firmare 1.5.2… nel forum ufficiale leggo che sono arrivati alla versione 1.5.10 (contenente la fix per TLS) ed addirittura alla 1.5.11 ma non consigliata per alcuni modelli. I Netonix sono switch poe favolosi e versatilissimi ma molto molto molto delicati, quindi credo che per adesso lavoreró alle modifiche che mi servono via HTTP e prima di effettuare qualsiasi aggiornamento firmware chiederó conferma direttamente al produttore, essendo switch che gestiscono dei pop davvero importanti e non posso permettermi fail e downs.

Spegnere, riavviare e sospendere Windows da WSL

Alla fine ho sempre WSL aperto o a portata di mano ed avendo usato Linux per vent’anni sono abituato a fare la maggior parte delle cose da terminale, tra cui riavviare, spegnere e sospendere il sistema. Essendo virtualizzato ovviamente WSL non può interagire direttamente con Windows per fare queste tre operazioni ma può lanciare e passare comandi a cmd.exe inglobati i degli shell aliases.

Dunque ho messo questi alias in ~/.bash_aliases:

alias poweroff='cmd.exe /C "shutdown /p"'
alias reboot='cmd.exe /C "shutdown /r /t 2"'
alias sospendi='sleep 6 ; cmd.exe /C "rundll32.exe powrprof.dll,SetSuspendState 0,1,0"'

Per la sospensione ho aggiunto un wait di 6 secondi che mi servono a spegnere tastiera e mouse wireless, altrimenti è immediato ed appena sollevo il mouse per spegnerlo si innesca il wake dalla sospensione.

Uno sguardo veloce a CrowdSec con iptables

Inizio questo 2022 testando CrowdSec in vista di rifare un server importante up da anni ed ormai non più coperto da aggiornamenti LTS. Attualmente ci uso csf/lfd e prima di scegliere se riusarlo nel nuovo volevo provare qualcosa di più fresco, che non fosse fail2ban.

La configurazione in formato yaml è molto intuitiva e semplice, durante l’installazione da repository si autoconfigura in base ai log che trova e funziona out-of-the-box subito, tranne il bouncer che di default non è attivato… motivo per cui scrivo questo post, ovvero appuntarmi che il bouncer va attivato come servizio, sennò non blocca nessuno:

systemctl enable crowdsec-firewall-bouncer

E se durante i test vi fate bloccare bisogna sapere che utilizza ipset (che non conoscevo ancora) e per sbloccarvi dovete lanciare:

ipset del crowdsec-blacklists IP.xxx.yyy.xxx

la cui lista troverete già popolata da un bel po’ di IP mascarati, che non siciliano non vuol dire nattati col masquerade ma bensì poco raccomandabili.

Mi piace il concept implementativo di questa applicazione, anche se out-of-the-box non ha notifiche email per le azioni (anche se ha svariati plugin) ed a differenza di csf non imposta alcuna impalcatura firewall atta a rilevare e bannare i port scanners (che per alcuni server rompono i coglioni più che i brute force login): la policy di firewall dovete integrarla voi.

Non so ancora se userò di nuovo csf o CrowdSec, manca qualche feature a cui ero abituato ma comunque mi sta piacendo, lo seguo e se continuerò a smanettarci scriverò cosa sono riuscito a farci!

Da Zabbix 3.2 a 5.0, prima e dopo PostgreSQL/TimescaleDB passando per MySQL

In questo post voglio raccontarvi la mia personale esperienza con Zabbix negli ultimi 5 anni circa, ovvero da quando lavoro al NOC di un provider locale in costante crescita. Conoscevo Zabbix da tempo ma lo avevo usato in ambiti dove non c’erano da monitorare più di 30 dispositivi e quindi le risorse hardware necessarie non erano particolareggiate, una VM Debian con MySQL su 4GB di RAM, 64GB di disco ed un paio di vCPU mi era sempre bastata, ed infatti per i primi due anni queste stesse risorse sono bastate tranquillamente a far girare Zabbix 3.2 dentro una VM e monitorarci i primi pezzi di infrastruttura ed i primi clienti.

Poi MySQL ha iniziato ad ingolfarsi ed ho deciso di lasciare zabbix-server sulla vm e spostare MySQL bare metal su un HP Microserver Gen8 con 16GB di RAM, Debian/ZFS con due dischi meccanici RAID 1 più due dischi SSD per cache e ZIL. Si è ripreso alla grande ed è andato avanti per altri due anni, fino a quando ha raggiunto il limite. Con 1200+ dispositivi SNMP da monitorare e 600+ VPS (Valori Per Secondo di Zabbix) il DB era arrivato a 120GB e le slow query erano troppe, rallentavano l’operatività del server e generavano troppi falsi positivi.

Ho provato allora il partitioning MySQL che ha funzionato facendo tirare la baracca ancora qualche mese per poi ricominciare con le slow query, ingolfamenti e falsi positivi. Iniziavo a valutare alternative perché stare col dubbio che si tratta di un falso positivo che rientrerà in non-sai-quanti-minuti appena completate le slow query o stare col dubbio che un cliente, magari pure importante, o un apparato è realmente down è davvero snervante. Ho dunque iniziato a documentarmi sulle nuove versioni di Zabbix e le nuove funzionalità, ho anche provato a tenere la configurazione ed svuotare lo storico convinto che fossero eventuali record orfani a fare ingolfare 4 anni di MySQL… durava una settimana poi si ingolfava di nuovo, avevo capito che ero incappato in una legge di Murphy:

Una volta aperta una scatola di vermi, l’unico modo di rimetterli in scatola è usarne una più grande.

Prima legge di Zymurgy sulla dinamica dei sistemi in evoluzione

Non avendo mai prima scalato Zabbix su così tanti dispositivi non avevo abbastanza esperienza, ho alzato bandierina bianca e chiesto aiuto a dei consulenti certificati che mi hanno rassicurato che con TimescaleDB non avrei avuto problemi e sarebbe bastata anche una sola VM un po’ più grossa delle precedenti e nemmeno un proxy! Non ci credevo ma non avevo altro da fare che fidarmi e farmi seguire nell’aggiornamento a Zabbix 5.0.

Abbiamo dunque messo su Zabbix 5.0 su una VM con 16GB di RAM, 4 vCPU e 512GB di disco, importato la configurazione di host, gruppi e templates e fatto macinare il tutto… solo che per una svista durante la procedura non abbiamo attivato l’estensione TimescaleDB di PostgreSQL. Questo è stato un errore che mi è servito parecchio a rendermi conto per la prima volta di come funziona e macina dati PostgreSQL… perchè praticamente con questo errore stavo usando Zabbix con un DB PostgreSQL pulito senza alcuna estensione o TimescaleDB, solo che ancora non lo sapevo!

La prima cosa di cui ti accorgi, più che le performances è la stabilità nonostante i rallentamenti notturni dovuti ai backup: nettamente superiori a MySQL, pur senza partitioning (che TimescaleDB poi di fatto implementa ma un PostgreSQL pulito no!) il sistema non si è mai ingolfato ne rallentato nonostante il DB fosse arrivato a quasi 300GB!! Allucinante per me che avevo visto MySQL ingolfarsi su un DB di 120GB su un server bare metal! PostgreSQL su una VM invece continuava tranquillo ad ingurgitare dati con ottime performance e nel frattempo gestiva le query in lettura del frontend come se gli stessero facendo il solletico! Credevo che semplicemente TimescaleDB fosse questo: una figata, fin quando non si è riempito il disco e si è piantato tutto. Solo pochi giorni dopo ho capito che PostgreSQL/TimescaleDB era una iper-figata.

Da un lato ero gasato che le performance erano nettamente superiori a prima nonostante un DB così grosso, dall’altro ero deluso perché ero reincappato nella stessa legge di Murphy e pensavo mi servisse hardware dedicato più costoso. Il disco pieno rendeva la VM inutilizzabile, dunque ho ripristinato il backup del giorno prima con ancora qualche GB libero e mi ci sono fatto un giro per revisionare la situazione… è stato li che mi sono accorto che l’estensione TimescaleDB non era attiva, ci era scappata. Dunque l’ho attivata e ricaricato lo schema del DB, è partita una stored procedure che ha macinato più di 24 ore e poi il miracolo sintetizzato da questo grafico: la prima metà è il DB PostgreSQL di Zabbix 5.0 senza TimescaleDB… la seconda metà è lo stesso DB PostgreSQL con TimescaleDB pienamente operativo: ditemi voi se non è ALLUCINANTE.

Ubiquiti AirControl su Fedora 33

Non essendo uno sviluppatore Java ed avendo a che fare -fortunatamente- con pochissima roba in Java ci sono stato un po’ a capire perché lanciando AirControl ottenevo solo una finestra nera. Qualche anno fa, sempre con AirControl, avevo avuto bisogno di esportare una variabile di ambiente (che ho perso e non ricordo più) per farlo partire… era legata all’accelerazione grafica, tanto che -visto che AirControl non è più sviluppato in favore di UNMS- mi ero convinto non ci fosse nulla da fare e che il problema fosse legato a Wayland o X.Org. Conoscendo davvero poco le differenze tra versioni di JRE/JDK che pensavo essere retrocompatibili mi ero convinto definitivamente che quindi la finestra nera era per forza qualcosa di legato al rendering/compositing della mia scheda video.

Minchiate: è una questione di versione di Java. Non chiedetemi perché, non lo voglio nemmeno sapere! Di Java mi serve solo AirControl e così mi sta benone.

Fedora 33 esce con java-11-openjdk di default che è una dipendenza di libreoffice. AirControl ha invece bisogno che java-1.8.0-openjdk sia il JRE di default per girare correttamente. Quindi:

$ sudo dnf install java-1.8.0-openjdk icedtea-web

[...]

$ sudo alternatives --config java

Ci sono 2 programmi che forniscono 'java'.

  Selezione    Comando
-----------------------------------------------
 + 1           java-1.8.0-openjdk.x86_64 (/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.272.b10-0.fc33.x86_64/jre/bin/java)
*  2           java-11-openjdk.x86_64 (/usr/lib/jvm/java-11-openjdk-11.0.9.11-0.fc33.x86_64/bin/java)

Invio per mantenere l'attuale selezione[+], o inserire il numero di selezione: 1

PS: proprio oggi leggevo che Python sta scalando Java nella classifica dei linguaggi più utilizzati, ci sarà un motivo :-)