MySQL 5.6 and MariaDB 10.1 End of Life: ultimo atto
Il 20/01/2021 MySQL 5.6.51 è stata rilasciata come ultima versione del ramo 5.6. A inizio febbraio di quest'anno cPanel L.L.C. ha annunciato un nuovo step nell'abbandono di MySQL 5.6 nei suoi software di gestione dei servizi di hosting (cPanel e WHM) e vista la fetta di mercato che possiede fra gli Hosting questo determinerà l'effettiva uscita di scena veloce e definitiva della versione 5.6 MySQL e 10.1 di MariaDB. (...)
La maggior parte dei "software web" ha già implementato il supporto per la versione 5.7/8.0 di MySQL o 10.2/10.3 di MariaDB (Wordpress/Joomla/NextCloud/Matomo/etc) ma alcuni prodotti "legacy" utilizzano codice non compatibile con le nuove versioni di MySQL/MariaDB, quindi quando queste versioni verranno aggiornate dai server di hosting questi prodotti con buona probabilità cesseranno di funzionare o andranno in contro a malfunzionamenti di varia natura. Per tanto non è più possibile rimandare, è necessario programmare nei prossimi 30/60 gg una soluzione "definitiva", o al minimo verificare in quale situazione ci si ritroverà.
Come procedere con gli aggiornamenti? Iniziamo dalle cose semplici.
Sito web di "archivio" storico.
Nel caso di siti che non pubblicano più nuovi contenuti, o ne pubblicano raramente, il passaggio a un sito statico in html è sicuramente la soluzione più rapida, definitiva e sicura. Ricordiamo che un sito web statico è per certo un sito sicuro, e che un sito web dinamico non aggiornato è per certo un sito attaccabile. Assolutamente negli anni a venire avere un sito storico come archivio ma ancora con CMS non aggiornato è da evitare. Con cosa si staticizza un sito web? Due soluzioni semplici e funzionali sono Wget e HTtrack.
Sito web ancora attivo.
Nel caso di sito web ancora in attività con pubblicazione regolari di nuovi contenuti (anche se non frequente) la soluzione staticizzazione non è la migliore e sarebbe necessario quindi ricorrere alla migrazione del CMS a una versione aggiornata che già implementa il supporto per le versione 5.7/8.0 di MySQL. Per questo tipo di soluzione ci sono tre fonti di possibili problemi di cui tener presente:
- importazione dei dati. Ci sono tool per i vari CMS per migrare da una versione non più supportata a una aggiornata, o per passare da un CMS ad un altro. Di solito con un paio di tentativi e di configurazioni si ottiene un buon risultato
- compatibilità fra estensioni. Il passaggio alla versione più recente di MySQL può rilevare delle incompatibilità fra estensioni/plugin e la versione di MySQL o fra la versione dell'estensione/plugin e quella del CMS. Verificare prima cosa è in rinunciabile fra le estensioni/plugin del CMS aiuta moltissimo in questo caso a prendere le giuste decisioni.
- la grafica e il template. Questo è un punto che va tenuto in considerazione non tanto perché crea grossi problemi, ma per via del fatto che ha un impatto ben visibile agli occhi dei nostri utenti, e quindi bisogna sempre valutare se impegnarsi per importare il template nel nuovo CMS o se con l'occasione affidarsi anche a un nuovo template.
Quanto detto sopra per la sicurezza di un sito di tipo archivio vale anche per un sito di basso profilo di pubblicazione, lasciarlo con un CMS non aggiornato, è una cosa assolutamente da evitare.
Applicativo in sviluppo ma non aggiornato.
Nel caso di uso di un applicativo non aggiornato, ma di cui si sa o si ritiene che è già uscita una versione che supporta MySQL e MariaDB la cosa migliore da fare è dare un occhio al sito degli sviluppatori alla ricerca di informazioni sulla compatibilità e sulle procedure di aggiornamento, se non si trovano risposte provare a cercare con un motore di ricerca e con buona probabilità si troveranno già le risposte alle nostre domande.
Applicativo custom legacy.
Qui la situazione è un po' più complessa. Come prima cerchiamo di semplificare, se ci sono dei fondi richiedere all'originale sviluppatore o ad un'altra società un adeguamento del codice PHP/SQL è una soluzione semplice e lineare, fatto l'aggiornamento tutto continuerà a funzionare come sempre per i prossimi anni a venire. A seconda della complessità dell'Applicativo Custom ci possono essere dei costi più o meno importanti.
Nel caso questa soluzione non sia praticabile l'alternativa è cercare un servizio di hosting che "supporti" la versione 5.6 di MySQL per qualche tempo ancora, questo permetterà di andare avanti fino a che... non uscirà una criticità di sicurezza legata al codice legacy PHP/MySQL dell'applicativo custom, a quel punto si dovrà nuovamente scegliere.
Se siamo nel caso in cui l'applicativo può essere protetto da una schermata di login gestita direttamente dal WebServer (Apache/Nginx/ISS) si potrà adottare questa soluzione, impedendo di fatto a "Internet" di accedere ai file dell'applicativo se sprovvisti di credenziali di accesso del Webserver. Gli operatori autorizzati dovranno invece fare un doppio login, prima per bypassare la protezione del Webserver e poi per accedere all'applicativo stesso, poco male.
Se questa ultima soluzione non è praticabile e l'applicativo non può essere protetto da schermata sarà necessario aggiornare tutto il prima possibile onde evitare di ritrovarsi a subire un attacco, che ci obbligherà ad aggiornare, sotto stress temporale e con una base di dati compromessa. Aggiornare prima è sicuramente il problema minore :-)
