Access denied bij mysql database restore. Alternatief valt in sleep mode.

[Blacky]

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&#95kn&#48t.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?

[Bart L]

En wat staat er op regel 1926 ?


Sent from my iPhone using webhostingtalk mobile app

[Blacky]

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.

[Blacky]

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.

[Bart L]

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

[SmilieBG]

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]

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.

[Bart L]

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]

Lol wat zitten we op 1 lijn met z'n alle.

Het is wat vroeg, maar eigenlijk is dat wel een biertje waard

[Blacky]

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)?

[Blacky]

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.

[SmilieBG]

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?!

[Blacky]

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.

[cyrano]

Al eens geprobeerd "localhost" te vervangen door "127.0.0.1"?

[Blacky]

Waar? In de database bij die ene regel? Zou dat de sleep mode kunnen voorkomen denk je?