Um derartigen Unklarheiten zukünftig aus dem Weg zu gehen, schlage ich vor, dass jetzt jeder hier postet, ob er es schon wusste oder nicht. Vielleicht können wir dann auch diese Informationen mit OpenOffice in eine Postgres Datenbank aufnehmen.
Editieren Sie /var/lib/postgres/data/pg_hba.conf als User postgres bzw. in neueren Linux-Versionen /etc/postgresql/pg_hba.conf als User root:
host all all 127.0.0.1 255.255.255.255 trust
Hallo,
erstmal vielen Dank für den Tipp - auch wenn ich für ein Adressbuch für HylaFax unter dem guten WHFC (http://www.uli-eckhardt.de/whfc/) wohl nicht um ODBC herumkomme.
Die Einstellung "host all all 127.0.0.1 255.255.255.255 trust" erscheint mir allerdings etwas zu sehr vertrauensselig für eine Datenbank. Mit "host all all 127.0.0.1/32 ident omicron" und einer entsprechenden pg_ident.conf läßt sich der Zugriff beschränken:
So kann (nach Betriebssystem-Authentifizierung, mit PAM ließen sich sicher dolle Sachen machen) "nashorn" als dieser oder per "psql -U postgres" als Datenbanksupernutzer arbeiten, "elefant" entsprechend mit den Zugriffsrechten von "nashorn" - und der Webserver nur mit den Rechten des Datenbanknutzers "readonly".
In Verbindung mit den IP-Bereichen der pg_hba.conf (und den datenbankinternen Zugriffsrechten) ergibt sich damit eine sehr feine Zugriffkontrolle. Wie mir gerade erst klar wird - z.B. als "nashorn" aus dem LAN Vollzugriff über die "MAP omicron", für andere Netze wird gleicher Nutzer per anderer "Map" ggf. auf "readonly" umgeleitet - oder bekommt gar keinen Zugriff. Endlich habe ich den Sinn von "MAPNAME" verstanden ;-)
Von Peter Eisentraut am Mi, 3. August 2005 um 10:21 #
Welche Vorteile hat der SDBC-Treiber gegenüber der Verwendung von ODBC oder JDBC, neben der oben erwähnten, aber von mir nicht ganz nachvollziehbaren Umständlichkeit?
das zusätzkliche Editieren von 2 ODBC-Konfigurationsdateien kann man schon als Mehraufwand ansehen - und für nicht-Profis auch als Hürde ...
Logischerweise solllte der Einsatz einer zusätzlichen Treiberschicht (ODBC) zu Performanceeinbussen, mehr Hauptspeicherbedarf und Prozessorlast führen.
Andererseits beschränkt ODBC die Funktionalität der Datenbank mindestens auf ein bestimmtes SQL-Niveau; spezifische PostgreSQL-Funktionen kommen garantiert zu kurz.
Von André Schnabel am Do, 4. August 2005 um 10:36 #
OpenOffice.org zieht (imho) viel zu viel Metadaten .. durch die zusätzliche ODBC bzw. JDBC Treiberschicht geht dann die Performance an Stellen in die Knie, wo es einfach nur noch nervig ist (z.B. auflisten der Tabellen einer DB, die wirklich remote liegt). Ausserdem werden per ODBC/JDBC nicht immer alle Datentypen korrekt erkannt (ist mit 1.1 besser geworden und mit 2.0 fast perfekt . aber eben nicht ganz). Zugegebenermassen hab ich mir den SDBC-Treiber schon länger nichtmehr angeschaut, werde ich aber nochmal machen und hoffe, es gibt spürbare Unterschiede :-)
Ach ja bzgl. der "oben beschriebenen Umständlichkeit": nur Pkt. 2 und 3 beziehen sich wirklich auf OOo. Pkt. 2 wird ab OOo 2.0 wesentlich vereinfacht, denn dann kann man das Paket direkt über einen OOo-Dialog in die Umgebung einbinden. Pkt. 3 bleibt gleich, ist aber auch nicht anders, als eine jdbc-Verbindung zu definieren.
Wer das nicht mag, der kann auch die DomainSocket-Unterstützung -Gott ist das spät hiess das wirklich so?- nutzen, um mit PostgreSQL zu kommunizieren, man lässt dann einfach den TCPIP-Support weg
postgresql-sdbc-0.6.2.zip funzt super bei Nutzung unter M$-Windows. Ich versuche bislang vergeblich, das Paket unter Linux (Fedora Core 5) zu nutzen.
Installation in OpenOffice (per Paketmanager) reibungslos, das installierte(?!) Paket wird auch aufgelistet (Paketmanager).
Problem: der Treiber ("postgresql") erscheint nirgends!?! (Treiber wie MYSQL; ORACLE JDBC, JDBC usw. sind alle da)
Dasselbe funktioniert problemlos im OO unter M$-Windows, ich "denke" also keine Anfänger-Fehler bzgl. Installation zubegehen.
Ich arbeite bereits mit Formularen/Abfragen unter M$-Windows, welche auf eine Linux-basierte Postgres zugreifen, ich würde gerne direkt unter Linux bleiben. Verbindungen mittels Standard-JDBC Konfiguration gehen irgendwie..., allerdings bekomme ich Fehler die dazu führen, dass ich keine NEUEN Daten anlegen kann (nur bereits bestehende bearbeiten
vielen Dank fr den Tip, aber ich wusste es schon!
Danke,
ice
Editieren Sie /var/lib/postgres/data/pg_hba.conf als User postgres bzw. in neueren Linux-Versionen /etc/postgresql/pg_hba.conf als User root:
host all all 127.0.0.1 255.255.255.255 trust
Hallo,
erstmal vielen Dank für den Tipp - auch wenn ich für ein Adressbuch für HylaFax unter dem guten WHFC (http://www.uli-eckhardt.de/whfc/) wohl nicht um ODBC herumkomme.
Die Einstellung "host all all 127.0.0.1 255.255.255.255 trust" erscheint mir allerdings etwas zu sehr vertrauensselig für eine Datenbank. Mit "host all all 127.0.0.1/32 ident omicron" und einer entsprechenden pg_ident.conf läßt sich der Zugriff beschränken:
# MAPNAME IDENT-USERNAME PG-USERNAME
omicron nashorn nashorn
omicron nashorn postgres
omicron elefant nashorn
omicron www-data readonly
So kann (nach Betriebssystem-Authentifizierung, mit PAM ließen sich sicher dolle Sachen machen) "nashorn" als dieser oder per "psql -U postgres" als Datenbanksupernutzer arbeiten, "elefant" entsprechend mit den Zugriffsrechten von "nashorn" - und der Webserver nur mit den Rechten des Datenbanknutzers "readonly".
In Verbindung mit den IP-Bereichen der pg_hba.conf (und den datenbankinternen Zugriffsrechten) ergibt sich damit eine sehr feine Zugriffkontrolle. Wie mir gerade erst klar wird - z.B. als "nashorn" aus dem LAN Vollzugriff über die "MAP omicron", für andere Netze wird gleicher Nutzer per anderer "Map" ggf. auf "readonly" umgeleitet - oder bekommt gar keinen Zugriff. Endlich habe ich den Sinn von "MAPNAME" verstanden ;-)
PostgreSQL hat was für sich.
Es grüßt
ein Nashorn
das zusätzkliche Editieren von 2 ODBC-Konfigurationsdateien kann man schon als Mehraufwand ansehen - und für nicht-Profis auch als Hürde ...
Logischerweise solllte der Einsatz einer zusätzlichen Treiberschicht (ODBC) zu Performanceeinbussen, mehr Hauptspeicherbedarf und Prozessorlast führen.
Andererseits beschränkt ODBC die Funktionalität der Datenbank mindestens auf ein bestimmtes SQL-Niveau; spezifische PostgreSQL-Funktionen kommen garantiert zu kurz.
Bye brum
Ausserdem werden per ODBC/JDBC nicht immer alle Datentypen korrekt erkannt (ist mit 1.1 besser geworden und mit 2.0 fast perfekt . aber eben nicht ganz).
Zugegebenermassen hab ich mir den SDBC-Treiber schon länger nichtmehr angeschaut, werde ich aber nochmal machen und hoffe, es gibt spürbare Unterschiede :-)
Ach ja bzgl. der "oben beschriebenen Umständlichkeit":
nur Pkt. 2 und 3 beziehen sich wirklich auf OOo.
Pkt. 2 wird ab OOo 2.0 wesentlich vereinfacht, denn dann kann man das Paket direkt über einen OOo-Dialog in die Umgebung einbinden.
Pkt. 3 bleibt gleich, ist aber auch nicht anders, als eine jdbc-Verbindung zu definieren.
André
das spät hiess das wirklich so?- nutzen, um mit PostgreSQL zu kommunizieren,
man lässt dann einfach den TCPIP-Support weg
Ich versuche bislang vergeblich, das Paket unter Linux (Fedora Core 5) zu nutzen.
Installation in OpenOffice (per Paketmanager) reibungslos, das installierte(?!) Paket wird auch aufgelistet (Paketmanager).
Problem: der Treiber ("postgresql") erscheint nirgends!?!
(Treiber wie MYSQL; ORACLE JDBC, JDBC usw. sind alle da)
Dasselbe funktioniert problemlos im OO unter M$-Windows, ich "denke" also keine Anfänger-Fehler bzgl. Installation zubegehen.
Ich arbeite bereits mit Formularen/Abfragen unter M$-Windows, welche auf eine Linux-basierte Postgres zugreifen, ich würde gerne direkt unter Linux bleiben.
Verbindungen mittels Standard-JDBC Konfiguration gehen irgendwie..., allerdings bekomme ich Fehler die dazu führen, dass ich keine NEUEN Daten anlegen kann (nur bereits bestehende bearbeiten
Hat irgendwer einen Tip?