Post di On The Cloud Srl

Io fiero! Abbiamo appena fatto il quarto "flip" da green a blue di nuvolaris dot dev e tutto sembra funzionare a dovere. Ogni volta che abbiamo fatto un flip è stato per introdurre miglioramenti. L'ultimo è stato di sbarazzarci del VSwitch di Hetzner che "ogni tanto" dava problemi ed è stato finora l'unica fonte di disservizi. L'ambiente tra l'altro girava da un po' di giorni con uno dei tre server irragiungibile, anche se tutto continuava a funzionare a dovere. Abbiamo sostituito VSwitch con Wireguard, e sono veramente soddisfatto, è una VPN fantastica, semplicissima (relativamente...) da installare e molto robusta ed efficiente. I nostro server tra l'altro sono tutti IPV6 anche se il kubernetes gira su IPV4, quindi abbiamo anche introdotto una bella misura di sicurezza: tutti i server hanno un IPV6 ma i vari nodi di Kubernetes hanno un IPV4 e comunicano tramite wireguard quindi non c'è niente di kubernetes di esposto all'esterno, esponiamo solo le porte http pubbliche. L'unico accesso al kubernetes è una VM che fa da bastion. La migrazione è stata la più indolore: fatto il backup del green, ripristinato sul blue e spostato il load balancer. Dentro ci sono parecchie applicazioni al momento, tutte che usano database, redis, storage, e tutto è stato ripristinato a dovere. Inoltre abbiamo anche ottimizzato l'uso di spazio disco "compattando" il database per eliminare vecchi log che potevano potenzialmente riempire il disco. Insomma il nostro deployment è sempre più robusto, testato e affidabile.

Come tutti gli anni, il 30/31 Dicembre lo dedico all'aggiornamento delle vm che ho in giro... Venti anni fa (ma anche 25 mi sa) andai alla sede di Aruba di persona, che all'epoca era a Soci (Arezzo), se non ricordo male... Avevo il server Sun (sparc64) appena comprato con una Debian appena installata. All'epoca non era necessario aprire nessuno stupido Ticket da qualche stupida pagina web, per comunicare con qualcuno. Chiamai Aruba e chiesi se potevano collegarmi in rete il mio server. Senza troppi giri di parole prendemmo appuntamento. Chi ci apri la porta, ci fece visitare tutta la sede e la sala server: un ammasso di altri PC di tutti i tipi, con la mia Sun Entrylevel mi elevavo parecchio. Montammo il mio rack L1 nell'armadio, e come per miracolo dopo pochi istanti dopo il boot, "Mucca" già rispondeva ai ping. Purtroppo Aruba non è piu' quel covo di nerd che fu... Adesso la macchina a 2 lire non te la tengono piu'. Devi comprarti una vm, costerebbe troppo il server dedicato. ------------ La buona notizia è che ho trovano un altro spacciatore di vm, che non pretende di comunicare con me tramite form/registrazioni e ticket. Sono ad Amsterdam.... (High5! B.V. - OpenBSD Amsterdam / http://openbsd.amsterdam ) Spacciano vm OpenBSD con amore per 5 euro al mese, di cui la metà la devolvono alla fondazione omonima ...ed io sono strafelice di tutto, sia di aver conosciuto loro e sia di usare sempre piu' OpenBSD

RECORD! Ieri mi sono collegato in remoto con i server di un cliente per un controllo di routine, propedeutico per un upgrade dell'infrastruttura. Mi sono imbattuto nell'uptime notevole di questa macchina virtuale. Bene? Non saprei in realtà. Perché se questa VM stava benone, la sua compagna non era proprio un granché. L'altra VM ha 1/4 delle risorse RAM della prima, l'uptime era minore (comunque accesa da più di 1 anno) ma alcuni servizi non erano attivi chissà da quanto tempo. Ecco cosa accade quando un server non è dimensionato nel modo corretto, quando le risorse a disposizione sono troppo poche e si installano col tempo servizi sopra ad altri servizi perché il cliente cresce ma non è disposto ad investire. C'è da dire che questo cliente è uno di quelli che non ha contratto manutentivo, e che si fa sentire una volta all'anno... Ma questi uptime, da simpatico record, avrebbero potuto diventare il record di un disastro, visto che qualche servizio piantato l'ho trovato. Ogni tanto i server vanno riavviati, inutile fare i radicali proclamando che "è meglio Linux", tutti sappiamo che è meglio Linux, ma non è sempre possibile usare Linux. Period. Comunque... Reboot notturno, monitoraggio di buon mattino, e tutto di nuovo online. Un buon controllo ai backup e si va. Ci sarà un motivo se il cliente finalmente ha richiesto un upgrade, o no? 😉

La gestione DNS senza intoppi è finalmente una realtà! 🎉 Abbiamo affrontato un intoppo che causava il caricamento bloccato quando si tentava di visualizzare e modificare i DNS. Attraverso uno sforzo congiunto di troubleshooting e test approfonditi, il problema è stato identificato e risolto. Ora, gli utenti possono godere di accesso e modifica dei DNS senza interruzioni. Il sistema gira senza problemi e carica con fluidità! 🌐✨ Problema risolto e performance ottimizzata: un ulteriore passo avanti verso un’esperienza utente eccellente. 🚀

Ieri, 1 Ottobre, un aggiornamento fallato di PCLinuxOS e per estensione di Cagliari, ha rimosso una serie di pacchetti cruciali per il funzionamento del sistema lasciandolo inusabile. Per chi non avesse fatto l’aggiornamento consiglio di aspettare ancora, verrete avvertiti quando la situazione sarà normalizzata. Per chi invece lo avesse purtroppo fatto, senza aver prima controllato perché l’aggiornamento voleva rimuovere così tanti pacchetti, consigliamo di entrare in modalità provvisoria da grub per ottenere un terminale. 1) digitate timeshift –restore 2) vi verrà mostrato un elenco di istantanee 3) vi verrà chiesto di inserire un numero relativo all’istantanea che volete utilizzare. Non avete mai fatto un backup ? Non rimane che usare una live-usb, recuperare i propri dati e reinstallare.

[..] Una delle particolarità di questa soluzione risiede nella capacità di garantire la #sicurezza operativa senza dover certificare direttamente il #kernel di #Linux. Attraverso l'uso di un monitor di sicurezza esterno, che opera su un #ipervisore analizzando e convalidando le azioni del kernel, è possibile mantenere Linux al di fuori del percorso di certificazione, facilitandone l'aggiornamento e l'adattamento alle esigenze di sicurezza e di performance senza compromettere l'affidabilità del sistema. 📝🚀🚘

Addio #CentOS! Tanti Anni Passati Insieme, tra Server Web, Hosting e Laboratori. La fine del ciclo di vita ufficiale di CentOS 7 è il 30 giugno 2024. La distribuzione Linux era veloce, gratuita e affidabile. Certo, se avevi bisogno di un supporto tecnico di prim’ordine, RHEL era il sistema operativo preferito nella famiglia Red Hat Linux. Ma non tutti avevano bisogno di essere presi per mano. Ora è tempo di cambiare. Operare su una versione obsoleta di CentOS comporta diversi rischi significativi. Inoltre, la conformità alle normative e agli standard di settore sarà messa a repentaglio, portando potenzialmente a gravi conseguenze legali e finanziarie. Anche le inefficienze operative sono motivo di preoccupazione, poiché i sistemi obsoleti potrebbero affrontare problemi di compatibilità con nuovi software e hardware, causando interruzioni e diminuzione della produttività. Addio quindi CentOS. Il tempo è scaduto. CentOS 7 è stato un fedele servitore per anni, ma è ora di lasciare che quel servitore vada in pensione e passi a qualcosa di nuovo e più sicuro.

Proxmox, quando l’assistenza fa la differenza. Un saluto a tutti, In questo breve articolo voglio parlarvi di quanto sia importante mantenere l’assistenza con il fornitore, sopratutto quando si tratta di macchine di produzione che devono essere costantemente aggiornate e tenute efficienti. Come già riportato in diversi articoli di blog, ultimamente siano passati da VMware a Proxmox come ambiente di virtualizzazione e devo dire che non rimpiango assolutamente VMware anzi. Abbiamo acquistato i nostri server presso Atlante Informatica, conosciuta sul web come miniserver, oltre alle solite cose che tutti dicono cortesia e quant’altro, la cosa che più mi dato soddisfazione e sicurezza è l’assistenza, ed ecco il mio caso. Qualche sera fa mi sono prodigato ad eseguire l’aggiornamento dei server in cluster Proxmox, abbiamo una cluster a due nodi e ho iniziato ad aggiornare il secondo nodo, al suo riavvio mi sono trovato con il nodo isolato dal cluster, non ero preso dal panico visto che avrei potuto riattivare le vm senza problemi, più che altro un po indispettito, in quanto non riuscivo a capire da cosa fosse dato il problema. Erano le 23:10 circa e ho scritto una mail all’assistenza descrivendo il problema. Pensando che mi rispondessero Lunedì mattina, invece nel giro di pochi minuti ho ricevuto una mail da Marco dell’assistenza la risposta con la soluzione del problema. Mai avrei pensato ad un problema derivante dal kernel, infatti l’aggiornamento installava il kernel 6.8, Marco mi ha mostrato come tornare indietro dando solo due comandi Fatto questo e riavviato il nodo, tutto è tornato come prima il nodo si è riallineato al cluster, ho riavviato le vm, dopo di che ho fatto o stesso con il nodo1. Di nuovo un grazie all’assistenza, questo è il servizio che si paga volentieri. Un saluto Adam

Ce l'abbiamo fatta! Ripristino di Nuvolaris dot dev effettuato con successo. Ed ecco a voi il post-mortem. Ieri sera ci vengono notificati problemi su Nuvolaris dev, ma siccome quello è un ambiente dev non è presidiato 24h (e lo abbiamo detto sempre a tutti) ci siamo accorti del problema solo stamattina. Io e il CTO di Nuvolaris, Francesco Timperi Tiberi, ci siamo messi a investigare sul problema, perché è importante capire cosa è successo per prevenirlo in futuro. Notiamo problemi non ben identificati su Couchdb che ha il log pieno di errori strani. Restartiamo il couchdb, e abbiamo problemi al reattach del volume, che risolviamo rimuovendo la volumeassociation. Ma purtroppo anche se riparte il database, tutto rimane surgelato, e sembra anche che gli ultimi backup non siano andato a buon fine. Allora tentiamo di salvare i dati del db a mano, e nel farlo ci accorgiamo che non si riescono proprio a leggere i file... A quel punto andiamo a controllare lo stato di Ceph e lo troviamo in errore! Ma sopratutto notiamo che... 298 su 300G sono occupati. La cosa ci sembra stranissima perchè invece il volume di couchdb (che monitoriamo) riporta il 34% libero. Allora ho l'intuizione e vado a controllare il totale del volumi e scropro che tutti i volumi allocati sono 480GB ma su Ceph sono disponibili solo 300GB!!! Ecco il nostro grande errore, abbiamo sovradimensionato i volumi, con Ceph che non ne aveva abbastanza. La soluzione era quindi di aggiungere spazio a Ceph, che per fortuna si può fare. Solo che finora non lo avevamo mai fatto... il dramma di avere un sistema stabile è che gli errori capitano raramente, e quando capitano... E per fortuna era stato lasciato il 30% di spazio sui server fisici, anche questo per evenienze si dovesse ampliare.... Seguiamo tutte le best practices (facciamo sistemi da 25 anni, ragazzi...) Mi impegno a trovare la soluzione visto che di Ceph mi sono occupato io. La maggior parte del tempo la ho spesa cercando di capire come aggiungere volumi. La grana più grossa era che rook sembrava non vederli i volumi aggiuntivi. Ci ho sbattuto la testa per un po'. Grazie all'aiuto di Mirko Danzi che si occupa del supporto capiamo che i dischi aggiunti devono essere raw e non qcow2 (ma strano perchè quelli iniziali SONO qcow2) e sistemato questo dettaglio finalmente Rook li vede e li aggancia al resto e ripartiziona il disco e lo spazio disponibile raddoppia. Verificata la procedura in ambiente di test (non vado ad operare, a cuore aperto, in produzione, una cosa mai fatta) passiamo alla fix in produzione. Faccio l'operazione di ripristino con Franz e Mirko che guardano che faccio (non si va mai ad operare in produzione senza un triplo check!!!), prima scrivo i comandi, loro controllano e poi li eseguo... Creiamo e aggiungiamo i dischi, e in 5 minuti e... il sistema riprende a funzionare! Nessuna perdita di dati anche stavolta e sistema di nuovo operativo. E anche se faccio il gradasso, mi è preso un mezzo infarto.