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

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.

Code:

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?

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.

Oorspronkelijk geplaatst door Blacky

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

Doe een import via screen.
Maak de DB via: http://dev.mysql.com/doc/refman/5.0/...-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:

Code:

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.