Menu Chiudi

Categoria: LoneStar Network

Addio 32bit

letture

What's the Difference Between 32-Bit and 64-Bit? - The Plug - HelloTechIl mio mail server è stato installato nel 2007 ed è sempre stato un sistema a 32 bit. Originariamente era una macchina fisica, un assemblato Pentium-based. Nel 2010 lo virtualizzai con una operazione di p2v (physical to virtual) eseguita tramite rsync.

Da allora ha sempre girato dentro una virtual machine a 32 bit in VMWare. Nessun particolare problema in quanto Slackware Linux continua ancora adesso a supportare attivamente la distributione a 32 bit tenendola del tutto in sincrono con la versione a 64 bit.

Recentemente però mi sono posto il problema di decidere se avesse senso continuare a tenere questo unico server a 32 bit mentre tutti i miei altri sono a 64 bit. Soprattutto perché, per motivi specifici, ho iniziato a compilare in autonomia il kernel per tutte le mie virtual machine, il che mi ha costretto a predisporre una vm di compilazione per i 64 bit e una per i 32 bit, e dunque a ripetere la compilazione del kernel due volte.

Inoltre il fatto che Slackware Linux continui a supportare la distribuzione a 32 bit non significa che continuerà a farlo per sempre. Praticamente tutte le maggiori distribuzioni negli ultimi anni hanno preso la decisione di offrire solo una versione a 64 bit dotata della compatibilità sufficiente per eseguire anche binari a 32 bit. E’ possibile che prima o poi anche Slackware Linux prenda questo tipo di decisione.

Dunque mi sono convinto a passare il server a 64 bit. Non volevo però effettuare una installazione pulita per poi migrare i servizi. Ci sono 17 anni di configurazioni e customizzazioni in questo server e dover rifare tutto da capo è uno dei motivi per cui non ho mai pensato di convertirlo finora. Inoltre mi piace l’idea di mantenere l’anzianità di installazione di un server, un po’ come quando si cerca di preservare l’uptime per più giorni, mesi, anni possibile.

Ho pensato quindi di utilizzare un metodo di conversione non ufficialmente supportato ma che a rigor di logica aveva tutte le chances di funzionare, ovvero prendere l’ultimo dvd di installazione di Slackware Linux a 64 bit corrispondente al livello di update del mio server a 32 bit, fare il boot della virtual machine con questo dvd e montare la partizione dell’OS installato, per poi sostituire tutti i pacchetti installati con gli equivalenti pacchetti a 64 bit. Alla fine poi reimpostare il kernel per il boot e partire.

Ho testato questa operazione su un clone della vm ed ha funzionato senza problemi. Quindi dopo qualche tempo ho agito sulla macchina effettiva con esito positivo.

Dopo il boot e l’avvio del sistema, adesso divenuto a 64 bit, ho proceduto a ricompilare e reinstallare i binari provenienti da pacchetti non facenti parte del dvd ufficiale.

Il tutto ha richiesto circa 4-5 ore in totale ma ne è valsa la pena. Adesso il mail server è a tutti gli effetti un sistema a 64 bit originariamente installato nel 2007 ma a tutti gli effetti aggiornabile e manutenibile come tutti gli altri sistemi a 64 bit in mio possesso.

 

Rimozione del Facebook Login

letture

Da oggi è stata rimossa l’opzione per utilizzare il login Facebook per autenticarsi su questo blog.

Da quanto ho appreso, nel corso del 2023 Facebook ha cambiato i propri termini di servizio rendendo necessaria la verifica Business degli account developer per poter accedere ai dati necessari all’uso della funzione Login. Inizialmente era comunque possibile verificarsi come Business anche semplicemente fornendo la propria carta di identità.

Dopo qualche mese hanno cambiato nuovamente i propri termini ed è diventato necessario fornire la prova di una vera e propria attività aziendale (iscrizione alla camera di commercio, ecc.).

Di conseguenza non è più possibile utilizzare il Facebook Login per scopi puramente amatoriali da parte di utenti individuali. Mi dispiace, ma non è colpa mia.

Per adesso rimangono attivi i login tramite Google e Twitter.

Reverse proxy e SSO

letture

Nginx logoNegli ultimi tempi ho effettuato dei cambi tecnologici ai servizi LoneStar Network, che non sono direttamente visibili ma che hanno migliorato e reso più sicuri gli stessi. In particolare ho provveduto a posizionare tutti i siti web dietro reverse proxy nginx. In questo modo quindi i vari server web che presentano i servizi non sono direttamente esposti in rete ma si trovano dietro la barriera costituita dal reverse proxy.

Questo ha aggiunto anche una certa flessibilità nel poter aggiungere sottoservizi presentati come subfolder dei siti principali.

Ho anche aggiunto un servizio di Single Sign On, per consentire l’accesso con un account centralizzato. Non tutti i servizi che utilizzo lo supportano ancora, ma con il tempo dovrebbe poter diventare l’unico sistema di login.

Restyling del sito

letture

Come si può notare sto procedendo a un restyling del sito, cosa che avrei già dovuto fare da molti anni.

Il tema wordpress Revolution Code Blue che ho utilizzato fino ad adesso non è stato più aggiornato fin dai primi anni 2000. Ha funzionato senza grossi problemi fino all’uscita di WordPress 5.1, ma con il contemporaneo passaggio a PHP 7.3 e WordPress 5.3 alcune problematiche hanno cominciato a mostrarsi nella corretta visualizzazione degli elementi delle pagine.

Dopo un po’ di infruttuosa ricerca sono approdato al tema Customify, che mi permette di costruire varie parti del sito come voglio invece di dare una struttura obbligatoria. Inoltre si sposa bene con il logo che non avevo intenzione di cambiare.

Non tutto il restyling del sito è ancora completo ma dovrei arrivare presto al look definitivo.

nuovi certificati SSL by Let’s Encrypt

letture

httpsTra ieri ed oggi ho cambiato il certificato SSL utilizzato sui siti web di lonestar.it e unixportal.net, e per i servizi di posta SMTP/IMAP di mail.lonestar.it.

Fino ad oggi avevo utilizzato un certificato di tipo wildcard, regolarmente acquistato su StartSSL. Si trattava di un servizio tutto sommato economico per procurarsi un certificato wildcard valido 2 anni. La comodità consiste nel fatto che il certificato era valido per *.lonestar.it, e quindi in qualunque servizio del network.

Ma la Certification Authority di StartSSL è stata deprecata dai maggiori browser a causa di alcune violazioni commesse dopo l’acquisizione da parte di una azienda cinese.

Come conseguenza, a partire dalle versioni recenti di Firefox e Chrome, i certificati emessi da questa authority non vengono più accettati come validi (colore verde accanto alla barra dell’url), ma vengono invece indicati come non riconosciuti (colore rosso accanto alla barra dell’url).

Allora ho deciso di iniziare a utilizzare il servizio gratuito di Let’s Encrypt, che molto successo ha guadagnato in tempi recenti per via della nuova filosofia di rilascio gratuito di certificati a chiunque, per tempi brevi (90 giorni al massimo), in modo da incoraggiare l’adozione dei protocolli https e tls da parte di tutti.

La breve durata dei certificati impone il passaggio a un meccanismo automatico di rinnovo e sostituzione, rispetto alla consuetudine precedente di ottenere un certificato valido per alcuni anni e quindi procedere a installarlo manualmente nei vari server coinvolti.

Let’s Encrypt offre un client ufficiale basato su python per eseguire queste operazioni automatiche sulle distribuzioni più diffuse e per i servizi più comuni. Ma siccome io utilizzo Slackware come distribuzione e s/qmail come servizio di posta, ho preferito utilizzare lo script Dehydrated, che si basa su bash e curl.

Quindi ho messo a punto alcuni script che richiedono i certificati, non più wildcard ma nominativi per ciascun servizio, e li installano dove necessario.

Sembra funzionare tutto 🙂

CC BY-NC-SA 4.0 .