Extra Blog

pgpool und dessen Authentifizierung

Pppool stellt eine interessante Lösung für den Betrieb mehrere Postgres9.0 Instanzen mit readable hot standby Systemen dar. Pgpool kann mehrere Aufgaben übernehmen.

Betriebssteuerung

  • Failover Steuerung 
  • Replikation Failover / Slave Nodes aktiv bringen 

Lastverteilung

  • Nach Gewichtung kann Leselast auch an unterschiedlich Leistungsstarke Systeme verteilt werden. 

Partitionierung

  • Daten können auf identischen Tabellentypen auf verschiedenen Hosts verteilt werden. Die Kriterien können individuell eingestellt werden. 
Soweit genügt das fürs Erste. Über den Funktionsumfang ist pgpool gut beschrieben und kann natürlich auch ein wenig mehr. Schwieriger wird es, wenn man sein DBMS absichern möchte. Hier gilt es ein paar Fallstricke zu vermeiden. Man muss aber Faierweise sagen, dass PGPool in einer 2 Nodeumgebung als Failoverlösung geeignet ist. Bei mehr als 2 Nodes macht das Scripten einer zuverlässigen Lösung für den Restore der Slaves und späteren zuverlässigen Replikation vom neuen Master erheblichen Aufwand!

Zum ersten benötigt pgpool für den Lifecheck einen eigenen Benutzer. Es ist nicht ideal dafür "postgres" zu verwenden der quasi DBA privilegien besitzt. Entsprechend legen wir uns hierfür einen eigenständigen Benutzer z.B. health_check an. Dieser hat gerade mal die Berechtigung sich ein zu loggen.

Fallstrick 1:

pgpool beherrscht selbst keine Athentifizierung für den health_check. Entsprechend muss in der pg_hba.conf eine Vertrauensstellung zum pgpool eingerichtet werden. 

 z.B. 

# TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD

host all health_check 192.168.115.2 255.255.255.255 trust

Der erste Schritt wäre getan um eine weitere Umstellung zu ermöglichen.

Alle anderen Benutzer sollen sich ebenfalls per Passwort authentifizieren. Wenn wir obige Einstellung nicht realisieren, lässt sich pgpool nicht starten. Weder aus den Postgres Logeinträgen noch aus pgpool selbst wird man an der Stelle schlau. Zumal, wenn man alles glaubt fertig konfiguriert zu haben man ggf. die falsche Ursache vermutet.

Fallstrick 2:

Wir wollen natürlich auch die Arbeitsbenutzer z.B. "dbuser100" absichern. Dazu sind 2 Erweiterungen notwendig. Der Proxy, also pgpool muss erfahren, dass eine Passwordauthentifizierung gewünscht ist. (Er reicht letzendlich die Requests nur durch und nutzt die auth. mechanismen der Datenbank. Der Proxy kennt ja die Berechtigungen nicht. prüft aber selbst auch das Passwort.)

# TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD

host all health_check 192.168.115.2 255.255.255.255 trust

host dbuser dbuser 192.168.115.2 255.255.255.255 md5

Selbiges muss auch am pgpool Konfiguriert werden. (Die IPs gehören den Clientsystemen von welchen sich auf die DB Verbunden wird.

host dbuser dbuser 192.168.115.100 255.255.255.255 md5

host dbuser dbuser 192.168.115.101 255.255.255.255 md5

Laut Doku kommt nun pg_md5 zum Einsatz, welches die Passworte generieren soll für die pool_passwd. Pgpool prüft im Vorfeld nur das Passwort auf Richtigkeit. 

Das Format lautet wie folgt: 

<benutzer>:md5<32 stelliger md5>

Allerdings, und das kann einem den letzten Nerv rauben, stimmt der generierte md5 nicht mit dem der Datenbank überein und daher funktioniert ein Login nicht! Neuere Postgres Datenbanken speichern das Passwort als md5 hash.

Hier kann man über psql an den jeweiligen hash des Benutzers kommen:

SELECT usename, passwd FROM pg_shadow;

Dieser ermittelte hash lässt sich dann in der pool_passwd verwenden und ein Login klappt wie gewünscht.

Bitte die pgpool.conf beachten und pool_passwd sowie die pool_hba.conf aktivieren!

Noch keine Kommentare

Die Kommentarfunktion wurde vom Besitzer dieses Blogs in diesem Eintrag deaktiviert.