Non c'è amministratore di sistema abituato a lavorare con MySQL che non abbia mai fatto uso di qualche console script per gestire backup, operazioni di manutenzione, allineamenti o altre procedure periodiche: nella maggior parte dei casi questi script vengono realizzati in PHP/bash (su OS Linux) oppure PHP/batch/Powershell (su OS Windows), quindi pianificati per una esecuzione periodica tramite cron job, operazioni pianificate, software di backup e via dicendo.
Si tratta di un approccio particolarmente efficace, specialmente per chi non ha intenzione di spendere soldi acquistando la licenza di altri software di gestione/automazione. Non è però un metodo esente da problemi, soprattutto in ottica di sicurezza: è infatti necessario inserire le credenziali dell'utente MySQL all'interno dello script e in modalità non criptata, mettendone quindi a rischio la password.
Consideriamo l'esempio seguente:
1 |
"C:\Program Files\MySQL\MySQL Server 5.6\bin\mysqlcheck" --user=USER --password=PASSWORD --auto-repair --optimize --all-databases |
Si tratta di un classico repair & optimize script, qualcosa che potrebbe tranquillamente trovarsi all'interno di una tipica rocedura di manutenzione notturna di una macchina adibita a Database Server. Il problema, come detto poco fa, è che la password si trova in bella vista all'interno del file: una cosa che sarebbe certamente meglio evitare.
Un possibile workaround che, se non altro, consente di non avere la password all'interno dello script è quello di definire una utenza di default nel my.cnf, ovvero file di configurazione di MySQL, nel seguente modo:
1 2 3 |
[client] user=mysqluser password=mysqlpass |
Una volta fatto questo, è tecnicamente possibile eseguire qualsiasi script facendo riferimento al file di cui sopra:
1 |
"C:\Program Files\MySQL\MySQL Server 5.6\bin\mysqlcheck" --defaults-file=/path/to/my.cnf --auto-repair --optimize --all-databases |
A una prima occhiata potrebbe sembrare tutto ok, ma di fatto è evidente che un approccio del genere non comporta miglioramenti significativi in termini di sicurezza: abbiamo tolto la chiave dalla serratura ma ci siamo limitati a nasconderla sotto il tappeto, lasciando peraltro una chiara indicazione su dove trovarla.
Per nostra fortuna, a partire dalla versione 5.6 di MySQL, è stata inserita una funzionalità aggiuntiva che consente di risolvere il problema in modo adeguato. Stiamo parlando dell'utility mysql_config_editor, il cui funzionamento è descritto dettagliatamente nella documentazione MySQL ufficiale. Questo tool può essere utilizzato per definire uno o più Host Alias, ovvero dei placeholder che hanno lo scopo di contenere un hash criptato delle credenziali username/password di un qualsiasi utente MySQL. Per creare un Host Alias è sufficiente eseguire una tantum il seguente comando console:
1 |
mysql_config_editor set --login-path=ALIASNAME --host=localhost --user=USER --password |
Il sistema, prima di creare l'Host Alias, richiederà la password dell'utente in questione: è opportuno notare che, sebbene sia possibile creare un Host Alias anche per l'utente root, è opportuno non farlo per ovvie ragioni di sicurezza: è decisamente preferibile creare un utente di servizio apposito, attribuendogli le autorizzazioni adeguate alle attività che dovrà eseguire.
Una volta creato, il nuovo Host Alias potrà essere utilizzato in luogo delle credenziali dell'utente a cui fa riferimento tramite il nuovo parametro --login-path , nel seguente modo:
1 |
"C:\Program Files\MySQL\MySQL Server 5.6\bin\mysqlcheck" --login-path=ALIASNAME --auto-repair --optimize --all-databases |
Problema risolto! Niente più password in chiaro all'interno dei nostri script.
Se avete voglia di comprendere meglio il funzionamento degli Host Alias, vi suggerisco di leggere la documentazione relativa al comando mysql_config_editor sul sito ufficiale di MySQL. Scoprirete, tra le altre cose, che gli Host Alias vengono creati e custoditi all'interno di un file criptato chiamato .mylogin.cnf, che si trova all'interno della cartella di sistema \%APPDATA%\MySQL (su sistemi Windows) o nella cartella /home/ dell'utente (su tutti gli altri sistemi).
Per il momento è tutto: felice scripting!