Wer mit PostGIS und den passenden Clients wie pgAdmin oder QGIS arbeitet, kennt die Dialoge zur Verbindung mit PostGIS-Datenbanken auswendig. Stets sind „Host“, „Port“, „Benutzername“ und „Passwort“ auszufüllen und dies oft nicht nur am eigenen Rechner, sondern auch bei Kolleg:innen und Kund:innen.
PostGIS-Zugangsdaten in QGIS zu speichern kann unerwünschte Folgen haben
Das manuelle Verbinden von PostGIS-Datenbank mit den unterschiedlichen Clients ist nicht nur umständlich, sondern auch fehleranfällig. Es kann darüber hinaus sicherheitstechnisch riskant sein, wie uns der Warnhinweis von QGIS „Zugangsdaten werden im Klartext in der Projektdatei gespeichert“ sagt.
Gut, mag man denken, wenn die Projektdatei weitergegeben wird, soll die/der Empfänger:in ja auch damit arbeiten und entsprechenden Zugriff auf die Datenbank haben. Es ist jedoch nicht unüblich, dass andere Personen mit anderen Zugangsdaten arbeiten (sollen), als man selbst. Und dann ist schnell versehentlich das Admin-Passwort bei GIS-Bearbeiter:innen gelandet oder die Kolleg:innen arbeiten mit meiner Kennung in der Datenbank.
Auslagerung von Zugangsdaten über pg_service.conf
Um diese Probleme zu vermeiden, gibt es die Möglichkeit, die Zugangsdaten in einer gesonderten Datei vorzuhalten. Auf diese ausgelagerten Zugangsdaten können auch QGIS und pgAdmin zugreifen, sie müssen somit nicht doppelt eingegeben werden.
Nutzt man diese Möglichkeit, sehen die Angaben in den Dialogen zu den Dantenbank-Verbindungen fast erschreckend leer aus, es muss lediglich das Feld „Dienst“ ausgefüllt werden:
Die Datei, in die die Verbindungsparameter ausgelagert werden, ist die .pg_service.conf – mit oder ohne vorangestellten Punkt, das hängt vom Betriebssystem und dem Speicher-Ort ab. Der zu den hier gezeigten Abbildungen passenden Eintrag in diese Datei lautet:
[osm_dev]
host=localhost
port=5432
user=osm_dev
password=xxxxxxxxxxxxxx
dbname=osm_dev
In den eckigen Klammern steht der frei wählbare Service- oder Dienstname, der in den Verbindungsdialogen von QGIS und pgAdmin genutzt werden kann; der Rest ist selbsterklärend. Indem die Blöcke untereinander geschrieben werden, können in der pg_service.conf direkt mehrere Verbindungen definiert werden.
Speicherung der Konfigurationsdatei
Das wäre eigentlich schon alles, wenn da nicht noch die Frage nach dem Speicherort für die Konfigurationsdatei wäre.
Die Antwort für Linux lautet: Speicherort ist das home-Verzeichnis des jeweiligen Users bzw. der jeweiligen Userin. Die Datei gilt dann nur für diese Person und kann mit einem Punkt beginnen, um die Datei zu verstecken. Alternativ kann sie auch für alle User:innen unter /etc/pg_service.conf gespeichert werden. Wem das nicht genug Alternativen sind oder wer die Datei anders benennen möchte, kann in der Umgebungsvariable PGSERVICEFILE auf die Konfigurationsdatei verweisen.
Unter Windows gibt es kein Standard-Verzeichnis für die pg_service.conf. Sie kann an einem beliebigen Ort gespeichert werden, muss aber über die Umgebungsvariable PGSYSCONFDIR dem Betriebssystem bekannt gemacht werden. Nach meinen Erfahrungen sollte der führende Punkt im Dateinamen unter Windows nicht genutzt werden, da es damit zu Problemen kommt.
Vorteile von pg_service.conf
Zu Beginn wurde erwähnt, dass das Passwort normalerweise in der QGIS-Projektdatei gespeichert wird. Nach meinen Empfehlungen wird es nun in der pg_service.conf gespeichert.
Ist das besser? Die klare Antwort lautet: Ja!
Denn so kann die conf-Datei nicht „aus Versehen“ mit der Projekt-Datei weitergegeben werden. Sie liegt auch nicht auf einem zentralen Dateiserver - wie vielleicht die qgz-Datei -, sondern in einem Verzeichnis, an das andere Nutzer:innen nicht ohne Weiteres herankommen. Hinzu kommt der vereinfachte Verbindungsaufbau aus den verschiedenen Clients. Ändern sich die Zugangsdaten, müssen sie nur an einer Stelle angepasst werden. Außerdem ist die pg_service.conf auch mit der pgpass.conf kombinierbar.
pg_service.conf wird übrigens auch, um noch einen dritten Client zu erwähnen, von psql unterstützt und darüber hinaus sicher auch von weiteren Clients, die ich persönlich nicht im Einsatz habe.