Cam în fiecare lună, primesc următoarea eroare:
Eroare MySQL:: „Acces refuzat pentru utilizatorul „rădăcină”@“localhost”
navighez spre această întrebare StackOverflow despre cum să faceți față erorii și
apoi revin la ceea ce făceam.
Soluția implică de obicei rularea unei instrucțiuni SQL din mysql programul a început de la rădăcină Cont Unix:
ALTER USER 'root'@'localhost' IDENTIFICAT CU mysql_native_password DE 'root';
Cand tu ALTER UTILIZATOR în MySQL, ar trebui să rămână așa până când rulați altul ALTER UTILIZATOR comanda.
Pe Ubuntu, problema revine după un timp. Într-o zi, voi încerca să mă conectez la MySQL și voi observa că parola nu mai funcționează. Nu am scris niciun scenariu de care am uitat. Acest lucru se va întâmpla la o nouă instalare Ubuntu, fie de pe un CD, un Vagrantfile sau o instanță AWS. Uneori, orice scenariu este responsabil pentru acest lucru va strica lucrurile atât de rău, încât ALTER UTILIZATOR afirmația de mai sus nu se mai recuperează din problemă.
Nu este nimic în niciunul din /etc/cron.* directoarele care ar trebui să provoace acest lucru.
Nu există nimic în /etc/mysql/* care să provoace în mod evident acest lucru.
Am analizat întregul sistem de fișiere și am constatat că nu există scripturi necomprimate și necriptate care rulează ALTER UTILIZATOR interogări pentru a efectua reversiunea.
Singurul lucru din /var/log care ar putea fi relevant este upgrade-uri nesupravegheate, dar nu văd cum ar trebui actualizarea MySQL să arunce toate setările de autentificare de fiecare dată.
Ca o soluție, am recurs la forța brută pentru a opri scenariul secret al Canonical:
chattr +i /var/lib/mysql/mysql/user.MYD
Asta face imposibil să alergi ALTER UTILIZATOR comenzi, așa că orice activitate pe care Canonical o are care face asta ar trebui să eșueze. Dar înseamnă, de asemenea, că trebuie să-mi amintesc că am făcut asta dacă trebuie vreodată să fac o schimbare legitimă la acest tabel.
Știe cineva ce software din Ubuntu este responsabil pentru acest comportament?
