Anmeldung am JDisc-Server scheitert
-
Hallo
wir wollen für eine Erstbefüllung mit JDisc scannen.
Das neue JDisc scheint aber mit einer anderen Verschlüsselung zu arbeiten, jedenfalls schlägt die Anmeldung am JDisc-Server im i-doit mit folgender Meldung fehl:
Could not establish connection: "Database error : SQLSTATE[08006] [7] SCRAM authentication requires libpq version 10 or above ". Please check your configuration of the selected jdisc server.
Ich habe in den beiden Config-Files (https://www.jdisc.com/de/support/faq.html#c2263) des JDisc schon alle scram-Einträge auf md5 geändert, aber ohne Erfolg.Hat das schon jemand gelöst?
-
@mwilhelmi
Hallo,macht ihr das über:
Extras CMDB - Import - Jdisc ?
Bei mir wird das über einen cron job gemacht. Mir ist ja jetzt bewusst noch kein Problem aufgefallen.
Ich werde mir das aber morgen ansehen. Mein Import-Job läuft erst heute Nacht. -
@StephanBuerger
Wir richten es in der GUI ein und der Fehler kommt schon beim "check connection".
Auf der Console kommt dann "Something went wrong with message: General error: PHP extension "SOAP" is missing."Ich habe dazu aber weiter recherchiert und das Problem ist offenbar, dass in der aktuellen Version des JDisc eine neue Postgresql-DB genutzt wird, die statt des bisherigen MD5 SCRAM zur Verschlüsselung nutzt.
Damit kann offenbar der Postgresql-Client auf dem i-doit nicht klar. Abschalten des SCRAM scheint nicht zu funktionieren.
Ein Update auf libpq-dev in der Version 11 hat leider auch nicht geholfen -
@mwilhelmi
Ich habe eben einmal nachgeschaut.
Ich habe die JDISC 5.0 Build 5106 und i-doit 1.17.2 installiert.
Ein Gerät, das am 15. März von JDISC neu gefunden wurde, ist heute Nacht nach i-doit übertragen worden. -
@StephanBuerger
Ich habe auch 5106, allerdings frisch installiert.
Das Thema ist wirklich der Verschlüsselung per SCRAM.
Was geholfen hat:- die Methode in pg_hba.conf von scram auf md5 umstellen
- Im postgresql.conf password_encryption = md5 setzen
- serverdienst neu starten
- per lgadmin ein neues Passwort für den postgresro setzen, damit die Verschlüsselung auf md5 geändert wird
Danach konnte ich mich aus der GUI wieder verbinden, zumindest der connection check ist erfolgreich.
Jetzt haben wir offenbar noch ein grundsätzliches Problem, denn der SOAP-Fehler auf der Konsole kommt weiter und in der GUI rennt er sich tot