Ich will gerade eine neue Datenbank aufsetzten und hab dazu das aktuelle PostgreSQL 13 auf dem gleichen Rechner wie mAirlist installiert. Über pgAdmin4 einen neuen User angelegt, Berechtigungen alle, dann eine neue Datenbank angelegt und im nächsten Schritt in mAirlist (aktuelle Version) versucht eine Verbindung zu 127.0.0.1 aufzubauen.
Es kommt immer die Fehlermeldung “method 10 not supported”
Ok, im Forum steht dazu eine Lösung, “libpq.dll” tauschen, habe ich gemacht. Aber der Fehler ist ach wie vor da. Ich kann keine Verbindung zur Datenbank herstellen.
Ich habe Torben auf diesen Thread angesetzt, er hat derzeit aber noch nicht die Zeit, da in Ruhe drauf zu antworten. Braucht ein wenig, bitte Geduld.
Ich kann mich erinnern, vor einigen Wochen bei einem Kunden PostgreSQL 12 auf seinem Hetzner-Server installiert zu haben und ich meine, genau vor diesem Hintergrund. Aber bitte frag’ mich jetzt nicht nach technischen Details.
Die 12er läuft wie die wilde Wutz, ich habe dort das gesamte Musikarchiv synchronisiert und normalisiert.
@Torben Genau die dll habe ich heruntergeladen und ersetzt. Auf den Post bezog sich meine Aussage zum Post im Forum. Leider funktioniert das aber nicht.
Hab ein ganz frisches Win10 aufgesetzt, also keine altlasten oder sonstwas auf dem System.
Mit der neuen DLL sollte das nicht notwendig sein. Die Konfigurationsänderung (alles zurück auf MD5) war der allererste Workaround, bevor ich die neue DLL aufgetrieben habe.
Mich hat gerade die Grippe umgehauen, daher fehlt mir die Zeit und Ruhe zum Testen. Wenn jemand etwas herausfindet, bitte gerne hier melden.
Mit Docker werde ich nicht so richtig warm. Dieses von aussen irgendwelche Konfigurationen ändern die dann in den Container deployed werden, kriege ich nicht so richtig in den Kopf.
Ich bevorzuge LXC, das Linux da drin verhält sich nahezu wie ein natives Linux.
Einiges was ich nur noch als Docker vernünftig bekomme läuft dann mangels nativer Untersützung meines VM Host, im LXC Container, nested.
Es dauert etwas, bis man sich dran gewöhnt hat - aber in vielen Fällen funktioniert das ganz gut, weil man die Konfiguration dann an einer zentralen Stelle hat, eben in der Container-Konfiguration. Ich mache fast alles mit Compose, und kann die docker-compose.yml (und was ggf. noch an “statischen” Konfigurationsdateien dazukommt) dann schön im Git pflegen.
Nimm als Beispiel Icecast - was muss man da schon groß konfigurieren, wenn man den aufsetzt? Ein Admin-Passwort und ein Source-Passwort reicht in den meisten Fällen. Das wird einfach per Environment aus der docker-compose.yml übergeben und fertig. Und das schöne ist, ich kann x Icecasts auf verschiedenen Ports laufen lassen ohne großes Rumgehampel mit verschiedenen Konfigurationsdateien. Einfach die Container-Konfiguration kopieren und das Port-Binding ändern.
Natürlich brauchen viele Anwendungen (wie PostgreSQL) noch irgendwo ein Daten-Volume, aber auch das kann man schön ordentlich organisieren, zum Beispiel mit ZFS und automatischer Spiegelung auf den Backup-Server. Im Notfall dann dort eben das Git-Repository mit der Container-Konfiguration klonen, docker-compose up, und alles rennt wieder.
Hab hier auch diverse MySQL/MariaDB und MSSQL-Versionen in der Testumgebung laufen, gerade für solche Fälle.