Bekijk Volledige Versie : Access denied bij mysql database restore. Alternatief valt in sleep mode.
Ik heb een probleem met het restoren van 2 databases. We zijn van server naar een andere server aan 't verhuizen en alle accounts aan het overzetten.
Bij 2 accounts gebeurt komt er een foutmelding en dat is deze:
Unable to restore database richard_kn0t.sql to richard_kn0t : ERROR 1227 (42000) at line 1926 in file: '/home/richard/backups/backup/richard_kn0t.sql': Access denied; you need (at least one of) the SUPER privilege(s) for this operation
Volgens DA zou dit een oplossing zijn:
http://help.directadmin.com/item.php?id=466
Maar dat werkt niet. De restore komt in een sleep terecht (als ik met mytop kijk) en daar blijft ie mooi in hangen en verder gebeurt er dus totaal niets.
Na wat zoeken op internet kwam ik tegen dat je in de database naar deze regel moest kijken:
/*!50013 DEFINER=`richard_xxx`@`localhost` SQL SECURITY DEFINER */
Deze regel zou je moeten verwijderen zegt een site, een ander zegt dat je hier de database gebruiker van moet maken, maar die staat er al.
Ik heb dus deze regel verwijderd en geprobeerd en ook deze regel aangepast naar da_admin maar dat mag allemaal niet helpen. Als ik met mysql probeer te restoren, dan blijft hij gewoon weer in een sleep proces hangen.
Heeft iemand hier een oplossing voor?
En wat staat er op regel 1926 ?
Sent from my iPhone using webhostingtalk mobile app
Dit is regel 1926 en regel 1927.
/*!50001 CREATE ALGORITHM=UNDEFINED */
/*!50013 DEFINER=`richard_xxxxx`@`localhost` SQL SECURITY DEFINER */
Dat xxxxx is mijn database wachtwoord, maar da's dus regel 1927.
Dit is overigens mysql 5.5.37 op een Centos 6.5 server met nieuwste DA, custombuild 1.2 en mod_ruid.
Net even gaan kijken bij de andere databases, bij eentje komt het voor op regel 53, daar staat iets soortgelijks:
/*!50003 CREATE*/ /*!50017 DEFINER=`megahit_xxxxx`@`localhost`*/ /*!50003 TRIGGER `artiest_maak_extra_zoekvelden` BEFORE INSERT ON 'artiest'
Nummertje 3 heeft het op regel 1969 maar regel 1969 en 1970 zijn exact hetzelfde als eerder bij 1926 en 1927 die voorheen genoemd is. alleen dan met een andere naam bij de definer uiteraard.
DB met de hand aanmaken in DA, en daarna importeren in phpmyadmin zonder alle /*! regels. Daarna kun je bekijken wat er evt nog met de hand moet (views e.d.) maar is de klant in ieder geval online
Genoemde regel is om trigger / view in DB toe te voegen. Daarvoor zijn inderdaad rechten nodig voor de genoemde gebruiker.
Indien je PHPMyAdmin toegang hebt (als root!), dan log je in, zoek je gewenste gebruikers op en verleen je ze tijdelijk deze extra rechten. Dan zou import probleemloos moeten gaan.
Oplossing van BartL kan ook tijdelijk werken; een opmerking daarbij - afhankelijk van wat triggers / views doen welke dan niet geimporteerd zijn, kan het onvoorziene fouten op de website veroorzaken.
systemdeveloper
18/05/14, 10:17
Voor triggers heeft de user waaronder geimporteerd wordt, tijdelijk 'SUPER' rechten nodig. Die kun je met GRANT aan de betreffende user geven als je als root op de mysql ingelogd bent.
Lol wat zitten we op 1 lijn met z'n alle. Laat je nog even weten of het gelukt is ?
Sent from my iPhone using webhostingtalk mobile app
systemdeveloper
18/05/14, 11:34
Lol wat zitten we op 1 lijn met z'n alle.
Het is wat vroeg, maar eigenlijk is dat wel een biertje waard :)
Het is voor mij ook nog vroeg, heb tot 04.30 zitten zoeken naar een oplossing, ben net wakker.:)
Voor triggers heeft de user waaronder geimporteerd wordt
Dit begrijp ik niet helemaal. Bij een restore importeer je de database toch als da_admin user, dat is in feite de root user, die zou toch alle rechten moeten hebben? Raar dat dit niet gewoon overruled wordt dan en dat je als mysql root user bij het importeren van een database op een weigering of een sleep stuit hierdoor.
Ik weet niet veel van mysql en zou het 't liefst zo veilig mogelijk willen doen. Dus om alles goed te behouden lijkt het mij dat importeren met GRANT rechten geven aan de user, het veiligste werkt want dan komt alles van de database er in. Maar welke Grant moet ik geven exact?
Dus heb ik eigenlijk nog 4 vragen.
1.) Is dit het juiste commando om die rechten te geven?
GRANT SUPER ON *.* TO richard_kn0t@'localhost' IDENTIFIED BY 'dbwachtwoord';
FLUSH PRIVILEGES;
Of zou het al volstaan om "create" rechten te geven? Gezien ik ergens anders gelezen had dat iemand alle CREATE statements moest verwijderen uit zijn backup en daarna kon hij hem ook importeren.
2.) Kan ik daarna gewoon de database ongewijzigd importeren?
3.) Is dit het correcte commando voor die rechten weer te ontnemen?
GRANT SUPER OFF *.* TO richard_kn0t@'localhost' IDENTIFIED BY 'dbwachtwoord';
FLUSH PRIVILEGES;
4.) Eigenlijk de belangrijkste.... hoe kan het gebeuren dat dit in zo'n database terecht komt en is dat te voorkomen op een of andere wijze?
Een van die databases is namelijk mijn hobbysite en ik kan me niet herinneren speciale dingen met de database gedaan te hebben. Of kan dit veroorzaakt worden door een plugin zoals Centrora security (firewall voor Wordpress)?
Aanvulling, met dit commando is het wel gelukt. Dus wat dat betreft alvast heel hartelijk dank!! De database was wel op server1 1,79MB en op server 2 slechts 1.40 MB (beiden bekeken in DA bij mysqlbeheer van de user). Zou dat kunnen? Alles lijkt wel te werken.
Ik zat even fout bij het wegnemen, dit moest het commando zijn om die rechten weer weg te halen:
REVOKE SUPER ON *.* FROM richard_kn0t@'localhost' IDENTIFIED BY 'dbwachtwoord';
Blijft natuurlijk vraag 4 en de eerste vraag hoe het kan dat de root user hierop vast loopt terwijl die alle rechten zou moeten hebben, waarom dat niet overruled?
Edit: Nog iets vreemds. Als ik helemaal niets met die GRANT doe en als de user inlog en via phpmyadmin importeer in plaats van via het mysql commando via commandline, is er ook geen probleem raar genoeg. Behalve dat met elke optie de databases kleiner worden aangegeven dan op de oude server.
Vraag 4: het zijn normale zaken in MySQL (triggers e.d.). Deze zijn 99% zeker door een van de applicaties (bij)geinstalleerd.
Blijkbaar had je op het oude DirectAdmin een user met dergelijke rechten - en op de nieuwe DirectAdmin waren deze rechten niet (standaard) aanwezig.
M.b.t. uitgevoerde GRANT en REVOKE rechten, het gedeelte *.* betekent:
eerste * welke database; tweede * welke tabellen in de database. Voortaan kan je rechten specifiek voor 1 database verlenen (en intrekken).
- - - Updated - - -
Na je edit:
hoe ben je ingelogd in PHPMyAdmin? Als dezelfde user (richtard_kn0t) of als root?! :)
V.w.b. vraag 4. Ik had daar alleen da_admin, geen andere user met die rechten. Leuker nog, ik heb op de oude server per ongeluk een andere database met hetzelfde euvel (er waren er 3) weggekiept. Via admin backup/transfer weer proberen te restoren, zelfde foutmelding gekregen.
Daarna weer als die user ingelogt, phpmyadmin gestart als bereffende user (megahit_xxxx) met bijbehorend wachtwoord. En toen wilde hij wel restoren.
Resultaat.... database was ook deze keer weer kleiner. Origineel was ie iets van 7,35 MB volgens DA, na restore nog 5,40 MB.
Al eens geprobeerd "localhost" te vervangen door "127.0.0.1"?
Waar? In de database bij die ene regel? Zou dat de sleep mode kunnen voorkomen denk je?
systemdeveloper
18/05/14, 16:12
Dit heeft directadmin om veiligeheidsoverwegingen gedaan. Een SUPER privilege is behoorlijk heftig en dat wil je niet door elke 'vreemde' backup zomaar overnemen. Dus ook al had je deze rechten op je vorige bak waarop je die backups maakt... via een restore (naar een nieuwe server/user) krijg je die super rechten gewoon niet.
Dat betekent dat er altijd iemand moet zijn die deze rechten wel heeft (de hoster bv) om de backup in te lezen *).
Wat de meesten doen (en afhankelijk van de backupsize natuurlijk) is om de restore te starten, de foutmelding af te wachten (dan is de user tenslotte al aangemaakt op de server), tijdelijk de grant rechten te geven en opnieuw de restore te starten.
*) Indien je na de eerste gefaalde restore, zelf wel in het bezit bent van het wachtwoord van de 'definer' van de trigger/sp en je logt daarmee op mysql in, kun je uiteraard de hele sql file zonder problemen laden.
Dat de datebase kleiner is/lijkt, kan komen door doordat er op voorhand geen optimize over gelopen heeft en dat er een hoop lege space in zat.
Dit heeft directadmin om veiligeheidsoverwegingen gedaan.
Sinds welke versie dan? Ik heb afgelopen jaar diverse server verhuizingen gedaan en dit is de eerste keer dat ik er tegenaan loop met een paar sites.
Ik heb echt het idee dat het door Centrora firewall of zoiets er in gekomen is, met alle andere sites en databases op die server 0 problemen gehad.
Er staat wel een oplossing in de help van directadmin (zie eerste post) maar die werkt gewoonweg niet op die manier.
Dat betekent dat er altijd iemand moet zijn die deze rechten wel heeft (de hoster bv) om de backup in te lezen *).
Ik ben de hoster en/of heb root rechten... dus ik zou die super rechten moeten hebben volgens jou? Waarom lukt het dan niet?
En het is verder wel een nieuwe server, maar het is een admin backup/transfer, dus usernaam en wachtwoord van de user blijven hetzelfde, ook databasenaam en database user en wachtwoord blijven hetzelfde. Er verandert gewoon totaal niets, behalve het ip adres en de naamservers dan.
En zoals gezegd. Op de oude server een backup maken, deze op de oude server terugzetten via admin backup/transfer, gewoon exact hetzelfde probleem.
*) Klopt ook niet. Je kunt makkelijk in bijv. wp-config.php de dbusernaam en dbpassword van betreffende database achterhalen.
mysql -uusernaam -pwachtwoord databasenaam < databasebackup.sql
werkte ook niet, had ik al geprobeerd. Ook dan ging het proces om een of andere reden in een sleep mode, totdat ik die user tijdelijk dus Super rechten gaf, toen ging ie wel door.
Of bedoel je ets anders met het wachtwoord van de "definer"?
Feitelijk zijn er dus maar 2 goede oplossingen denkbaar zoals ik het zie, als je tegen dat probleem aan loopt.
1.) Je geeft de user tijdelijk super user rechten en restored via console als de user (misschien ook als da_admin) of
2.) Je logt in als de user, logt in naar phpmyadmin met zijn dbusernaam en dbpasswd gegevens en importeert de database daar.
In beide gevallen zit je dus met extra werk omdat je de database uit de backup moet gaan trekken en bovenstaande acties moet uitvoeren.
Als dat bij alle accounts zou gebeuren ben je er mooi klaar mee. Ik vind dat geen goede actie van Directadmin, zoiets moet toch opgevangen kunnen worden op een of ander wijze als het om een admin backup/transfer gaat?
systemdeveloper
18/05/14, 17:47
Dat is altijd al zo geweest, maar ik vind het eigenlijk wel goed, aangezien je anders een server wel erg gemakkelijk kunt ownen. Het staat ook ergens op de da site overigens.
Je merkt het ook alleen als een gebruiker a) triggers gebruikt in zijn db en b) als je hem op een nieuwe server aanmaakt (aangezien de user dáár tenslotte nog niet de juiste rechten heeft).
Oke bedankt voor de uitleg.
en b) als je hem op een nieuwe server aanmaakt (aangezien de user dáár tenslotte nog niet de juiste rechten heeft).
Maar dat klopt dus ergens niet, want als ik het op dezelfde (oude) server doe waar die user dan wel al zijn juiste rechten heeft), loop ik tegen hetzelfde probleem aan zoals ik al schreef.
Op zich vind ik het dus wel goed dat je niet zomaar iemand super user rechten geeft, uiteraard. Ik bedoelde te zeggen dat het niet mogelijk moet zijn voor een user om op die wijze een database te blokkeren zodat het middels de admin backup/restore die problemen geeft.
Daarom heb ik ook het idee dat het door die Centrora Firewall veroorzaakt is geworden op een of andere wijze en daardoor ook een lokale restore via admin backup/transfer mislukt. Toch? Of begrijp ik hem nu verkeerd?
Want een van die databases was van mezelf en ik heb niks raars gedaan.
Waar? In de database bij die ene regel? Zou dat de sleep mode kunnen voorkomen denk je?
Yep. En overal waar 't eventueel nog "hard coded" is.
Het is me al enkele keren overkomen dat o.a. MySQL setups van CMS'en e.d. niet werkten met localhost, maar wel met ip. Ik zie niet waar 't verschil zat. Maar hey, als 't werkt, werkt het. Eerste keer was lang geleden op OSX server. Maar later ook op Debian, RH... meegemaakt.
Cyrano het verschil zit in mysql rechten systeem
Zo is root@127.0.0.1 niet hetzelfde als root@localhost
Sent from my Nexus 5 using webhostingtalk mobile app
GlobalServe
18/05/14, 19:01
Doe een import via screen.
Maak de DB via: http://dev.mysql.com/doc/refman/5.0/en/create-database.html
Dan importeren via MySQL console:
mysql -uUSERNAME -p -hlocalhost
use database_dat_je_juist_hebt_gemaakt;
source /path/naar/bestand.sql;
Zou perfect moeten werken zo.
SmilieBG: Op exact gelijk ingeregelde servers zou dat niet moeten hoeven, maar zal het wel proberen als het zich nog eens voordoet.
GlobalServe: Waarom die localhost? Localhost wordt toch als default altijd gebruikt? Gezien ook de foutmelding die je krijgt als je bijv. het wachtwoord vergeet (no access for user@localhost)?
Maar jij logt dus eerst in mysql in. Dat werkt inderdaad prima.
Nu breekt mij klomp, database weer leeg gemaakt, nu probeer ik het oude commando weer:
mysql -uda_admin -p richard_kn0t < richard_kn0t.sql
En werkt perfect zonder dat hij in sleep mode valt.... pfffff... computers doen af en toe echt vaag.