MariaDB mit UniDAC

[EmWieMichael]

Mein Internethoster hat die Datenbanken von MySQL auf MariaDB umgestellt. Der Zugriff auf die Datenbanken von meinen Internetseiten (PHP) funktioniert nach wie vor problemlos. Meine Delphiprogramme hingegen brechen den Verbindungsaufbau mit "#28000 Access denied for user... (using password: YES)" ab. Der Zugriff erfolgt über UniDAC (Provider: MySQL). User und Passwort sind definitiv korrekt.
Müssen dem MySQL-Provider irgendwelche (Extra-) Informationen mitgegeben werden?

Michael.

[peer81]

Hallo,

das sollte nichts mit Unidac zu tun haben. Bei der Umstellung wurde wohl noch was geändert. Alle Datenbanken per localhost erreichbar.
Kannst du die Rechte für den Datenbank User anpassen/ändern? Da sollte es sowas geben.

Zugriffssteuerung:
Nur lokale Verbindungen zulassen
Remoteverbindungen von beliebigem Host zulassen
Remoteverbindungen zulassen von ...

Ansonsten muss dein Internethoster das auf "Remoteverbindungen von beliebigem Host zulassen" für deinen User setzen. Dann sollte das auch wieder gehen.

MfG

[Medium]

Ich kann bestätigen, dass MariaDB mit UniDAC's MyProvider reibungslos spielt. Leider sonst aber auch nur mutmaßen, dass dort ggf. Änderungen an den Usern passiert sind.

[Commander Tom]

Bitte auch den Port prüfen, MariaDB braucht 3007, MYSQL 3006. Außerdem nochmals den DB-Benutzer prüfen, ob der volle Rechte hat auf die DB.

[blawen]

Zitat:

Zitat von EmWieMichael (Beitrag 1515666)

Mein Internethoster hat die Datenbanken von MySQL auf MariaDB umgestellt. Der Zugriff auf die Datenbanken von meinen Internetseiten (PHP) funktioniert nach wie vor problemlos. Meine Delphiprogramme hingegen brechen den Verbindungsaufbau mit "#28000 Access denied for user... (using password: YES)" ab. Der Zugriff erfolgt über UniDAC (Provider: MySQL). User und Passwort sind definitiv korrekt.

Grundsätzlich klappt die Verbindung, insofern denke ich an die beiden Szenarien:


- Sehr viele Provider sperren per Voreinstellung den externen Zugriff.
Ggf. kannst Du dies im Portal einstellen, andernfalls müsste dies der Provider freigeben.

- Du musst noch Deinen Hostingnamen im DB-Namen und/oder Usernamen voranstellen
z.B. MyHosting_Username, MyHosting_DBName

[Medium]

Zitat:

Zitat von Commander Tom (Beitrag 1515680)

Bitte auch den Port prüfen, MariaDB braucht 3007, MYSQL 3006. Außerdem nochmals den DB-Benutzer prüfen, ob der volle Rechte hat auf die DB.

MySQL Standard-Port ist 3306, und das hat, zumindest bei mir immer, auch bei der MariaDB Installation standardmäßig drin gestanden. Der Port lässt sich aber problemlos ändern (my.ini bzw. my.cnf, bei beiden), und keine der beiden "braucht" die genannten Ports. Sie brauchen den, der eingestellt ist. (Zudem würde die Fehlermeldung nicht zu einem falsch eingestellten Port passen, weil dann würde der Server erst garnicht gefunden, und könnte die o.g. Meldung nicht zurückgeben.)

[MyRealName]

Zitat:

Zitat von peer81 (Beitrag 1515667)

Hallo,

das sollte nichts mit Unidac zu tun haben. Bei der Umstellung wurde wohl noch was geändert. Alle Datenbanken per localhost erreichbar.
Kannst du die Rechte für den Datenbank User anpassen/ändern? Da sollte es sowas geben.

Zugriffssteuerung:
Nur lokale Verbindungen zulassen
Remoteverbindungen von beliebigem Host zulassen
Remoteverbindungen zulassen von ...

Ansonsten muss dein Internethoster das auf "Remoteverbindungen von beliebigem Host zulassen" für deinen User setzen. Dann sollte das auch wieder gehen.

MfG

Ich erinner mich auch an eine solche Einstellung, wo man angeben musste von welchem Rechner (IP) man auf die Datenbank zugreifen will. Diese Einstellung wurde eventuell nicht übernommen als von MySQL auf MariaDB umgestellt wurde.

[EmWieMichael]

Moin!
Vielen Dank für Eure Antworten.
Ich habe jetzt noch einiges probiert und geprüft:
- an den Einstellungen beim Hoster hat sich nichts geändert; der externe Zugriff ist aktiviert (weitere Vorgaben bezüglich externer Zugriffe gibt es auch nicht),
- andere Ports funktionieren auch nicht,
- anderer Rechner: nix,
- anderer Internetzugang: nix,
- Zugriff per FireDAC: gleicher Fehler.

Werde jetzt Kontakt zum Hoster aufnehmen...

[Klaus01]

.. vielleicht sind die Firewall-Settings auf dem Server nicht angepasst worden.

gut kann man vergessen - Access denied - passt nicht zur blockierenden FW.

Grüße
Klaus

[Commander Tom]

Zitat:

Zitat von EmWieMichael (Beitrag 1515697)

Moin!
Vielen Dank für Eure Antworten.
Ich habe jetzt noch einiges probiert und geprüft:
- an den Einstellungen beim Hoster hat sich nichts geändert; der externe Zugriff ist aktiviert (weitere Vorgaben bezüglich externer Zugriffe gibt es auch nicht),
- andere Ports funktionieren auch nicht,
- anderer Rechner: nix,
- anderer Internetzugang: nix,
- Zugriff per FireDAC: gleicher Fehler.

Werde jetzt Kontakt zum Hoster aufnehmen...

Handelt es sich hier beim Hoster möglicherweise um WebGo? Dort gab es größere Änderungen bzgl DB. Man muss nun den DB-Hauptbenutzer benutzen und nicht mehr den datenbankspezifischen Benutzer, also z.b. web33 anstatt web33_db35. Der DB-Hauptbenutzer muss vorher angelegt sein, damit das klappt.

[omnibrain]

Zitat:

Zitat von EmWieMichael (Beitrag 1515697)

Ich habe jetzt noch einiges probiert und geprüft:
(...)

Hast du denn mal probiert per mySQL Workbench oder einem anderen Programm wie HeidiSQL zuzugreifen?

[EmWieMichael]

Zitat:

Zitat von Commander Tom (Beitrag 1515726)

Handelt es sich hier beim Hoster möglicherweise um WebGo? Dort gab es größere Änderungen bzgl DB. Man muss nun den DB-Hauptbenutzer benutzen und nicht mehr den datenbankspezifischen Benutzer, also z.b. web33 anstatt web33_db35. Der DB-Hauptbenutzer muss vorher angelegt sein, damit das klappt.

Jo, WebGo. Die Sache mit dem Hauptbenutzer habe ich gerade ausprobiert: funktioniert auch nicht. Hätte mich aber auch etwas gewundert, da der Zugriff mit dem Benutzer web33_2 ansonsten auch mit PHP nicht funktionieren dürfte (aber, man weiß ja nie...).

[EmWieMichael]

Zitat:

Zitat von omnibrain (Beitrag 1515730)

Hast du denn mal probiert per mySQL Workbench oder einem anderen Programm wie HeidiSQL zuzugreifen?

Hatte ich bisher nicht; danke für den Tipp. Eben HeidiSQL getestet: gleicher Fehler. Auf ein weiteres Programm kann ich wohl verzichten.
:(

[gmc616]

Fangen wir's mal anders rum an.
Einen falscher Port oder eine blockierende FW kannst du ausschließen, denn die Antwort "#28000 Access denied for user... (using password: YES)" kommt direkt vom SQL-Server. Eine typische MySQL-Fehlermeldung.

MariaDB und auch HeidiSQL sind Forks von MySQL, entstanden dadurch, dass Oracle das MySQL-Projekt gekauft hat, aber auf Grund der Lizenzen, nicht den kompletten Code für sich einheimsen konnte. Aus den öffentlichen Sourcen sind dann eben MariaDB und HeidiSQL entstanden und weiter entwickelt worden. Das ist aber mittlerweile ne ganze Zeit her.

"WebGo" kenne ich nicht. Hört sich an wie "FckDich^^, wir sind billig" ("New StartUp" :wall:)

Dein Provider hat sich offenbar dazu entschieden die/den DB-Server zu updaten ("mit der Zeit gehen", MySQL ist ja quasi tot), und da sich die DB's von MySql auf MariaDB übertragen lassen (weil sie ja immernoch MySQL-DBs sind), war die Wahl auf MariaDB providerseitig quasi einfach und gegeben. Kostet nix, außer Zeit.

Das SQL-Benutzer-Rechte-System ist aber mWn in MariaDB umgebaut worden. (habe schon zu diesem Zeitpunkt nicht mehr viel mit MySql/MariaDB zu tun gehabt, wegen Oracle).

... anders:
Kommst du per Konsole auf den MariaDB-Server? Dann setze die Benutzer-Rechte neu.
Oder aber per phpmyAdmin? Der unterstützt so weit ich weiß auch MariaDB. Und dort kannst du die Benutzerrecht auch neu setzen.
Wie das geht, steht sicherlich in einer ergoogle-baren Doku. Will damit sagen, dass das Problem nicht im Delphi-Code liegt, sondern an der Gegenseite.

Deine PHP-Seiten greifen quasi lokal (innerhalb des Provider-Netzwerks) auf den Maria-DB-Server zu.
Deine Delphi-Programme aber, (vermute ich), von außerhalb des Provider-Netzwerkes.
Es würde mich nicht wundern, wenn man den Zugriff, providerseitig, für den Zugriff auf die DB gesperrt hat. Das würde Sinn ergeben, denm Du sollst die DB nur für deine Webseite nutzen, aber nicht weltweit für irgendwelche deiner APPs.
Dagegen spricht allerdings die Antwort des SQL-Servers. Er antwortet, und zwar mit "Access denied for user...".
Das ist i.m.A. "nur" ein Rechte-Problem innerhalb den MariaDB-Servers, kein Problem deiner Delphi-Anwendungen und keine Sperre seitens Providers.


Sorry, aber so sieht's in meinen Augen aus. Ich habe keine Lösung, ich versuche mich nur in einer Analyse des Problems.

[peer81]

Hallo,

bei MariaDB muss man in der globalen Config den externen Zugriff freigeben. Nur beim User externe Zugriffe freigeben hat sonst keine Auswirkung, wenn das in der globalen Config vom DB Server verboten ist.

In der globalen Config muss folgendes gesetzt/geändert werden sein:
bind-address = 0.0.0.0

Aktuell wird da die lokale IP stehen denke ich. Also auf 0.0.0.0 setzen und DB Server neustarten.

MfG

[Commander Tom]

Sicherlich hast Du den externen Datenbankzugriff in der Datenbankverwaltung für die Datenbank aktiviert, oder?

In HeidiSQL sieht es bei mir dann so aus (Siehe Anhang). Das funktioniert einwandfrei.

[EmWieMichael]

@Tom
Der externe Zugriff ist aktiviert (siehe auch Posting #8).
Deine Screenshots könnten von mir sein :thumb:

Ich habe bei webGo eine entsprechende Anfrage laufen...

[EmWieMichael]

Lichtstreif am Horizont:

Ich bin gerade auf die glorreiche Idee gekommen, doch mal eine neue Datenbank anzulegen: externer Zugriff funktioniert :-D.
Jetzt muss ich nur noch herausfinden, warum das mit den bestehenden DB´en nicht klappt.

[Commander Tom]

Vielleicht auch mal das Häkchen bei "externer Zugriff" bei den bestehenden DB löschen und wieder setzen. Keine Ahnung, ob das was ändert.

[EmWieMichael]

Zitat:

Zitat von Commander Tom (Beitrag 1515797)

Vielleicht auch mal das Häkchen bei "externer Zugriff" bei den bestehenden DB löschen und wieder setzen. Keine Ahnung, ob das was ändert.

Aber ich habe Ahnung :). Das ändert was! Es funktioniert. :thumb:
"Eigentlich" hatte ich das vorher schon probiert; mein Fehler war wohl, dass ich lediglich nochmal die Aktivierung bestätigt habe, ohne zuvor tatsächlich die Deaktivierung zu speichern. Mist! Die Tücke liegt halt manchmal im Detail.

Tom, herzlichen Dank für Deinen "Anstoß"!

Gruß Michael

[himitsu]

Natürlich hat "jemand" auch mal beim Support nachgefragt?




Erstmal gibt es viele Provider, welche keinen externen Zugriff erlauben. Vor allem bei den günstigeren "Hosting"-Paketen,
aber normal lassen sie dann auch garnicht erst den "Zugriff" auf diesen Port zu, bzw. reichen ihn nicht nach außen.

Zitat:

Zitat von gmc616 (Beitrag 1515758)

"WebGo" kenne ich nicht. Hört sich an wie "FckDich^^, wir sind billig" ("New StartUp" :wall:)

gibt es schon 18 Jahre, also wohl nix mit "New".

Zitat:

webgo ist ein Full-Service-Provider aus Hamburg ...

War nicht alles cool, was von dort kommt?
und außerdem

Zitat:

... mit besonderem Fokus auf Kundenzufriedenheit.

Und dann ist der seit 6 Jahren auch noch ungebrochener "Webhoster des Jahres" und mehr. :stupid:

[EmWieMichael]

Zitat:

Zitat von himitsu (Beitrag 1515812)

Natürlich hat "jemand" auch mal beim Support nachgefragt?
...

Hat "jemand", siehe Posting #17.
Auf Antwort warte ich noch. Aber egal, hat sich ja erledigt.

[TBx]

Zitat:

Zitat von gmc616 (Beitrag 1515758)

MariaDB und auch HeidiSQL sind Forks von MySQL

HeidiSQL ist kein Fork von MySQL sondern ein DBDesignment/DBManagement-Tool ;-)

[Commander Tom]

Zitat:

Zitat von EmWieMichael (Beitrag 1515809)

Zitat:

Zitat von Commander Tom (Beitrag 1515797)

Vielleicht auch mal das Häkchen bei "externer Zugriff" bei den bestehenden DB löschen und wieder setzen. Keine Ahnung, ob das was ändert.

Aber ich habe Ahnung :). Das ändert was! Es funktioniert. :thumb:
"Eigentlich" hatte ich das vorher schon probiert; mein Fehler war wohl, dass ich lediglich nochmal die Aktivierung bestätigt habe, ohne zuvor tatsächlich die Deaktivierung zu speichern. Mist! Die Tücke liegt halt manchmal im Detail.

Tom, herzlichen Dank für Deinen "Anstoß"!

Gruß Michael

Gerne Michael, oft sind es die Kleinigkeiten, die am Ende eine große Wirkung haben. Aber klasse ist es, wenn es nun (wieder) funktioniert.