FGS installieren: Unterschied zwischen den Versionen

Aktuelle Version vom 25. September 2015, 09:20 Uhr

FGS ist ein vorkompiliertes Paket von maptools.org für LINUX-Systeme mit allen für WebGIS-Anwendungen notwendigen Komponenten. FGS gibt es als Installer-Pakete und dazugehörige Module, die einzeln nach Bedarf dazugeladen werden können, siehe die jeweils aktuellste Release.

Wenn man nicht das vorkompilierte Paket verwenden, sondern aus irgendeinem Grund die Pakete und Module selbst kompilieren möchte, kann man FGS-DEV verwenden. Siehe dazu

• Mapserver in der fgs-dev Umgebung kompilieren und

• PostGIS in der fgs-dev Umgebung kompilieren

Vorarbeiten

Einen Benutzer "fgs" in Yast anlegen (Gruppe "users").

Die Installation von FGS soll mit einem Benutzer "fgs" erfolgen, d.h. nicht als root. FGS kann auch mit dem Benutzer root installiert werden, es ergeben sich dann aber einige schwerwiegende Probleme:

• Der Benutzer root darf den Apache nicht starten
• Wenn man für das starten des Apache einen unterprivilegierten User anlegt, darf der nicht in /opt/fgs schreiben

Der FGS-Benutzer kann natürlich statt "fgs" auch ganz anders heißen.

Download Link von FGS unter: http://dl.maptools.org/dl/fgs/releases/9.5/self-installers/

Den Download Button der gewünschten Version (aktuell: fgs-mapserver_5.6.0-fgs_9.5-linux-i386.bin) wählen.

Unter fgs-mapserver_5.6.0-fgs_9.5-linux-i386.versions kann man die dazugehörigen reinkompilierten Module und deren Versionen abfragen:

mapserver-php:5.6.0
mapserver-base:5.6.0
libstdc++-lib:6.0.8
libgcc-lib:1
apache-base:2.2.11
expat-base:2.0.1
gd-lib:2.0.35
jpeg-lib:6b
freetype-lib:2.3.9
libpng-lib:1.2.35
zlib-lib:1.2.3
curl-lib:7.19.4
openssl-lib:0.9.8k
proj-lib:4.6.1
postgresql-lib:8.3.7
gdal-base:1.6.1
tiff-lib:3.8.2
libgeotiff-lib:1.2.5
xerces_c-base:3.0.1
unixODBC-base:2.2.12
libungif-base:4.1.4
libiconv-base:1.12
proj4_epsg42xxx-support:proj
geos-lib:3.1.0
libxml2-base:2.7.3
agg-lib:2.4
php-base:5.3.0
postgis-lib:1.3.5
gmap-demo:cvs_MS_VERSION_54
ming-lib:0.4.2

Den Installer im Home-Verzeichnis von fgs verstauen.

Installation

Installationsdatei ausführbar machen mit

#>chmod 700 fgs-mapserver_5.6.0-fgs_9.5-linux-i386.bin

und ausführen:

#>./fgs-mapserver_5.6.0-fgs_9.5-linux-i386.bin

Verzeichnis angeben, in dem fgs installiert werden soll. Default ist /opt/fgs (für die Installation als root). Das ändern in /home/fgs/fgs:

Port festlegen unter dem Apache laufen soll. Default ist 8080:

Die Installationsroutine startet. Im Erfolgsfall sollte sie enden wie unten zu sehen.

Letzte Ausgaben auf jeden Fall mal sichern (und wenn es nur ein Screenshot ist). Denn da steht, wie man fgs so startet, dass fgs nach dem Booten automatisch hochfährt und wie man die Umgebungsvariablen für fgs einrichtet und wie man das automatisiert für jedes login.

Vor dem händischen Starten müssen die Umgebungsvariablen gesetzt sein. Das geht durch das Ausführen der Datei setenv.sh. Erstmal nach /home/fgs/fgs wechseln:

#>cd /home/fgs/fgs

Dann die setenv.sh ausführbar machen mit:

#>chmod 700 setenv.sh

und ausführen mit:

#>source setenv.sh

Wenn man möchte, dass setenv.sh automatisch nach dem Einloggen ausgeführt wird, führt man folgendes aus:

#>echo "source /home/fgs/fgs/setenv.sh" >> ~/.bashrc

Damit wird der Aufruf der setenv.sh an die Datei .bashrc des Users angehängt, die immer ausgeführt wird, wenn man sich als fgs anmeldet.

Damit FGS beim Booten des Servers automatisch startet, wird der Startbefehl in die boot.local geschrieben (den Befehl als root ausführen!):

#>echo "su root -c \"( . /home/fgs/fgs/setenv.sh ; fgs start )\"" >> /etc/rc.d/boot.local

und prüfen ob der Aufruf auch in der Datei anschließend drin steht:

#>less /etc/rc.d/boot.local

FGS starten

Nun können wir fgs starten. Einmal abmelden, wieder anmelden und fgs starten:

#>exit
#>fgs start

Dabei stellen wir fest, dass er fgs nicht kennt. setenv.sh wurde ja auch noch nicht ausgeführt. Das machen wir aber nicht, sondern melden uns mal ab und wieder an und probieren dann noch mal und siehe da: Apache läuft schon. Macht nichts, den fahren wir runter mit:

#>fgs stop

Was bei der Gelegenheit gleich beschreibt, wie man fgs runter- und wieder hochfährt. Nu geht’s aber. "+Starting 'apache' :" ist ein gutes Zeichen:

Um zu prüfen, ob nun alles eingerichtet ist, einmal abmelden, als root neu booten und danach wieder anmelden als fgs:

#>exit
#>shutdown -r now

Danach sollten die Umgebungsvariablen gesetzt sein und fgs schon laufen.

Nun können wir uns fgs auch mal vom Internet aus ansehen. Dazu die Adresse des Servers eingeben plus Port 8080, z.B. http://www.pkorduan.de:8080/ Dann erscheint in einem leeren fgs:

Jetzt haben wir den Mapserver, PHP, Apache, Unterstützung für PostgreSQL (die Datenbank selbst aber noch nicht) sowie all die für den Mapserver wichtigen Pakete. Die Unterstützung für MySQL fehlt noch und wird später als Modul installiert (MySQL selbst muss separat installiert werden, wenn nicht schon vorhanden).

SSL Unterstützung für Apache

Die SSL-Unterstützung für den WebServer muss nur eingerichtet werden, wenn mit den Clients per https kommuniziert werden soll.

Das notwendige Modul heißt apache_mod_ssl-module:2.2.8 und kann entweder

• von der Seite http://dl.maptools.org/dl/fgs/releases/9.5/modules/ runtergeladen und in /home/fgs entpackt werden oder
• (der bequemere Weg) per Kommandozeile installiert werden:

#>fgs install apache_mod_ssl-module:2.2.8  http://dl.maptools.org/dl/fgs/releases/9.5/modules/

Dabei werden wir nach dem Port für HTTPS gefragt. Default ist 443.

Nun muss man eigentlich gar nichts mehr machen außer fgs stop und fgs start. Dabei wird Apache im SSL Mode gestartet. Wenn der SSL-Schlüssel mit Passwort versehen wurde, muß dieser vorher manuell eingegeben werden, was zu einem Problem beim automatischen Hochfahren wird.

So sieht es dann jedenfalls nach einem erfolgreichen Start aus:

Und so nach einem erfolgreichen Stop:

SSL - Zertifikat erstellen

Grundsätzlich kann man das Zertifikat selbst erstellen oder ein Zertifikat kaufen. Dazu gibt es im WWW genügend gute Angebote. Das selbstgebaute Zertifikat hat den Vorteil, kostenlos zu sein. Allerdings wird es vom Internet Explorer (aktuell Version 7) als nicht vertrauenswürdig eingestuft, so dass der Client bei jedem Start erstmal eine böse Warnung wegklicken muss. Andere Browser haben mit selbstgebauten Zertifikaten keine Probleme.

Eine gute Doku zur Erstellung von selbstgebauten Zertifikaten gibt es unter: http://www.schirmacher.de/display/INFO/Apache+SSL+Zertifikat+erstellen+und+installieren

Zunächst sollte geprüft werden, ob das Modul openssl bereits im fgs packet enthalten ist. Es sollte unter /home/fgs/fgs/bin stehen. Dann einen Ort suchen, wo man die Dateien ablegt, z.B. unter /home/fgs/fgs/etc/ssl/certs.

CSR erzeugen

Schlüssel mit 2048 Byte erzeugen. Der Name ist eigentlich egal (im Beispiel "nvp-geoport"). Diese müssen dann später nur in der httpd-ssl.conf richtig eingesetzt werden.

#>openssl genrsa -out /home/fgs/fgs/etc/ssl/certs/nvp-geoport.key 2048

Wenn man den Schlüssel mit einem Passwort schützen möchte, folgender Befehl:

#>openssl genrsa -des3 -out nvp-geoport.key 2048

Problem dabei ist, dass man dann fgs nicht im Batch Modus nach dem Hochfahren des Rechners starten kann, weil fgs bis zum St. Nimmerleinstag auf ein Passwort wartet.

Als nächstes ein Certificate Signing Request (CSR) erzeugen mit:

#>openssl req -new -key /home/fgs/fgs/etc/ssl/certs/nvp-geoport.key -out /home/fgs/fgs/etc/ssl/certs/nvp-geoport.csr

Dabei wird man so einiges gefragt. Wenn man nicht antworten will, gibt man einen Punkt ein, z.B. bei Password - und das vermeidet die Abfrage des Passworts beim Booten, auch wenn man den Schlüssel ohne "genrsa" generiert hat!

ACHTUNG: Common Name ist nicht ein beliebiger Name (auch nicht wie suggeriert wird "YOUR name"), sondern der Domainname und muss genau der Domain entsprechen, unter der der Apache startet.

Jetzt kann man noch mal prüfen, ob alle Angaben richtig sind:

#>openssl req -noout -text -in /home/fgs/fgs/etc/ssl/certs/nvp-geoport.csr

Diesen CSR kann man nun an einen Dienstleister seiner Wahl senden oder zur Erstellung eines eigenen Zertifikats verwenden.

Kann sein, dass die Konfigurationsdatei für openssl nicht gefunden wird (Meldung: Unable to load config info from /home/nsavard/fgs-dev/built/openssl/ssl/openssl.cnf). Standardmäßig sucht openssl $FGS_DEV_HOME/built/openssl/ssl/openssl.cnf und nicht in $FGS_HOME. Ich habe das Problem gelöst in dem ich /home/fgs/fgs-dev/built/ angelegt habe und darin einen Link auf /home/fgs/fgs/etc.

#/home/fgs>mkdir fgs-dev
#/home/fgs>cd fgs-dev
#/home/fgs/fgs-dev>mkdir built
#/home/fgs/fgs-dev>cd built
#/home/fgs/fgs-dev/built>ln -s ../../fgs/etc openssl

--Markus Hentschel 13:36, 13. Feb 2012 (CET) Man kann auch die Umgebungsvariable OPENSSL_CONF setzen und auf die OpenSSL-Konfigurationsdatei zeigen lassen (z.B. export OPENSSL_CONF=/home/fgs/fgs/etc/ssl/openssl.cnf)

Ein vorhandenes Zertifikat mit der Endung crt kann wie folgt decodiert werden um sich den Inhalt anzusehen:

$ openssl x509 -in test.crt -text -noout

Das was da ausgegeben wird ist im Prinzip nichts anderes als das, was der Nutzer im Browser sieht, wenn er sich den Inhalt des Zertifikates anzeigen läßt.

Eigenes Zertifikat

Wenn man das Zertifikat nicht kaufen möchte, kann man mit dem CSR ein eigenes Zertifikat erstellen, welches dann von den Browsern akzeptiert werden muss (Die Browser reagieren dann aber erst mal mit einer Warnung und der Nutzer muss das Zertifikat bei sich als vertrauenswürdig einstufen):

#>openssl x509 -req -days 3650 -in /home/fgs/fgs/etc/ssl/certs/nvp-geoport.csr -signkey /home/fgs/fgs/etc/ssl/certs/nvp-geoport.key -out /home/fgs/fgs/etc/ssl/certs/nvp-geoport.crt

Zertifikat eintragen

Das vom Dienstleister erhaltene oder das selbst erzeugte Zertifikat muss abschließend noch auf dem Server bekannt gemacht werden. In der Datei /home/fgs/fgs/www/conf/extra/httpd-ssl.conf sind die Pfade zum Key und zum Zertifikat wie folgt einzutragen:

SSLCertificateFile "$FGS_HOME/etc/ssl/certs/nvp-geoport.crt"
SSLCertificateKeyFile "$FGS_HOME/etc/ssl/certs/nvp-geoport.key"
SSLCACertificateFile  "$FGS_HOME/etc/ssl/certs/nvp-geoport.root.crt"

Dann noch Apache neustarten und fertig.

Neustart und Test

Wer möchte, kann seinen Private Key, sein CSR und das gekaufte/erzeugte Zertifikat auf Richtigkeit prüfen, dafür gibt es ein Prüf-Tool der Fa. Webspace-Forum.

Wenn alles passt: Fertig! "fgs start" kann nun ohne Eingabe eines Passwort erfolgen.

FGS unter Port 80 und 443

Wenn FGS standardmäßig installiert ist, startet man fgs als User fgs und die Ports für den Webserver sind 8080 sowie für den ssl-Verschlüsselten Zugang 8443.

Wenn man den Apache-SSL mit einem anderen Port laufen lassen möchte, den Port in der Datei /home/fgs/fgs/etc/fgs/pkgs/apache_mod_ssl-module/apache_mod_ssl.conf anpassen, z.B.

SSLPORT=443

Nach der Einstellung fgs neu starten.

Welcher Port nach dem fgs start belegt wird, kann man mit folgendem Befehl prüfen:

#>netstat -ln

Um den Apache aus dem fgs Packet auf Port 80 bzw. mit SSL Unterstützung auf 443 starten zu können, muss man fgs als root starten. Das verwirrende dabei ist, dass im Startscript des apache im Falle eines Startens als root die Konfiguration des apache so geändert wird, dass apache als User apache läuft. Folgendes läuft beim Starten von fgs als root ab:

• die Dateien aus dem Verzeichnis $FGS_HOME/etc/init.d werden abgearbeitet. Unter anderem auch apache
• in diese Datei trägt man ein, dass man auf Port 80 starten will und es wird als Nutzer der User eingesetzt, der man gerade beim starten ist (USER=`id -un` GROUP=`id -gn`)
• da man ja als root startet, wird als USER root eingesetzt.
• anschließend wird mit der Zeile if [ $USER = 'root' ] ; then abgeprüft ob man root ist, wenn ja wie in unserem Fall, wird geprüft, ob es einen user apache gibt im Betriebssystem. Dieser ggf. angelegt und versucht apache als user apache zu starten.

Hier wird nun eine Änderung vorgenommen. Man läßt apache einfach als fgs starten in dem man in die Datei /home/fgs/fgs/etc/fgs/pkgs/apache-base/apache.conf wie folgt anpasst.

PORT=80
USER='fgs'
GROUP='users'

• anschließend wird aus init.d die pgsql ausgeführt. Darin wird die $FGS_HOME/etc/fgs/pkgs/postgresql-server/pgsql.conf geladen. Darin muss auch gesetzt werden, dass postgres als fgs gestartet werden soll.

PGUSER=fgs

• jetzt muss man nur noch mal prüfen, dass der Eintrag in der Datei /etc/rc.d/rc.local die Zeile mit su root enthält

su root -c "( . /home/fgs/fgs/setenv.sh ; fgs start)"

• fgs muss jetzt also immer als root gestartet und gestoppt werden: "sudo fgs start apache" bzw. "sudo fgs stop apache".
• Besser als "sudo fgs start apache" / "sudo fgs stop apache" ist der Befehl (als root ausgeführt) "apachectl graceful" im Verzeichnis $FGS_HOME/www/bin

Der Aufruf der eigenen Webseite erfolgt nun mit:
http://mein.server.de/mein-kvwmap/
https://mein.server.de/mein-kvwmap/

Wenn man nun noch den Port 80 für Zugänge von außen in der Firewall sperrt, ist nur noch der Zugang über https erlaubt. Aber vielleicht möchte man ja dennoch eine Seite für alle frei anbieten, z.B. http://mein.server.de mit Einstiegsinformationen und https://mein.server.de/mein-kvwmap/ gesichert. In dem Fall muss die Firewall beide Ports, 80 und 443 zulassen und die Einstellungen zu SSLRequire in der Apache-Konfiguration setzen.

• Entweder: Wenn SSL in einem bestimmten Verzeichnis (z.B. kvwmap) erforderlich sein soll, folgende Eintragung in der Datei $FGS_HOME/www/conf.d/httpd_*.conf (z.B. httpd_kvwmap.conf) in der Directory Directive vornehmen (damit kann der Nutzer allerdings immer noch http-Aufrufe abschicken, bekommt dann aber immer einen 403-Error):

SSLRequireSSL

• Oder: Wenn die Umleitung aller Aufrufe auf diesem Server von http auf https automatisch erfolgen soll, in der Datei httpd.conf im Abschnitt <Directory "$FGS_HOME/www/htdocs/"> folgenden Eintrag vornehmen (der Nutzer setzt einen http-Aufruf ab, landet auf dem Server aber mit https):

RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule (.*) https://%{HTTP_HOST}/$1 [L]

• Oder: Wenn die Umleitung der Aufrufe von http auf https automatisch nur für bestimmte Seiten erfolgen soll (z.B. kvwmap), in der entsprechenden httpd_*.conf (z.B. httpd_kvwmap.conf) folgenden Eintrag vornehmen (wichtig: außerhalb der Directory Directive, also z.B. einfach unten dran):

RewriteEngine On
RewriteRule     ^/kvwmap(.*)$ https://%{SERVER_NAME}/kvwmap$1 [L,R]

Wenn über die - globale oder selektive - Umleitung nur noch SSL-verschlüsselte Aufrufe möglich sind, muss der Eintrag SSLRequireSSL nicht mehr sein.

Weitere FGS-Module hinzufügen

Im Weiteren sind einige Module nachzuinstallieren, die für kvwmap gebraucht werden. Das betrifft Postgresql Server, PostGIS Support sowie pgsql- und mysql-Support für PHP. Nach der Installation des postgres Datenbankservers müssen User, Datenbank als Template sowie die Unterstütztung für PostGIS innerhalb des Template eingerichtet werden und die kvwmap-Datenbank erzeugt werden. Siehe dazu die folgenden Abschnitte.

Für die Nutzung von Mysql in php brauchen wir das Modul fgs-php_mysql-module-5.2.5-linux-i386.tar.gz.

Die Installation erfolgt über:

#>fgs install php_mysql-module:5.2.5 http://dl.maptools.org/dl/fgs/releases/9.5/modules/

Das Gleiche für pgsql:

#>fgs install php_pgsql-module:5.2.5 http://dl.maptools.org/dl/fgs/releases/9.5/modules/

php.ini

Damit die Erweiterungen in PHP auch laufen, müssen die Bibliotheken als shared object library (*.so) in PHP eingebunden werden.

Dazu in /home/fgs/fgs/www/conf/php5.ini.template (nicht in php5.ini!!!!!! Die wird beim fgs start jedes mal neu erzeugt) im Abschnitt Dynamic Extension die folgenden Einträge vornehmen:

extension=php_mysql.so
extension=php_pgsql.so 

Für kvwmap sind außerdem folgende Einträge zu ändern:

session.auto_start = 1

und

magic_quotes_gpc = Off

Achtung! Die Zeile ist auch öfter mal auskommentiert! Da muss dann das Kommentarzeichen am Anfang entfernt werden.

Weitere mögliche Änderungen:

max_execution_time            # Maximum execution time of each script, in seconds
max_input_time	               # Maximum amount of time each script may spend parsing request data
memory_limit                  # Maximum amount of memory a script may consume (8MB)
session.gc_maxlifetime        # wenn die Login-Dauer der User länger als 24 Minuten sein soll
upload_max_filesize           # wenn Uploads von Dokumenten (Scans, Fotos,...) größer als 2 MB erlaubt sein sollen
max_file_uploads              # wenn mehr als 20 Dateien in einem Request uploadbar sein sollen

httpd.conf

Damit in der URL nicht ständig explizit "index.php" angegeben werden muss, muss in /home/fgs/fgs/www/conf/httpd.conf (nicht in live.httpd.conf! Die wird beim fgs start jedes mal neu erzeugt) folgender Eintrag so geändert werden:

<IfModule dir_module>
   DirectoryIndex index.html index.php
</IfModule>

Wenn auf demselben Server z.B. der Geoserver unter tomcat laufen soll, kann der FGS-Apache dazu genutzt werden. Dazu muss ein weiterer Port freigegeben sein, z.B. Port 8080. Dieser Port muss in der tomcat-Konfiguration (Connector port="8080" in server.xml) angegeben werden. In der httpd.conf von FGS wird außerdem folgendes eingetragen:

PROXYPASS /geoserver http://localhost:8080/geoserver
PROXYPASSREVERSE /geoserver http://localhost:8080/geoserver
ProxyPreserveHost On

--Markus Hentschel 13:36, 1. Jul 2011 (CEST) Der WMS, der von diesem Server kommt, bringt möglicherweise die Umlaute in einem GetFeatureInfo nicht richtig rüber. Bei mir hat folgender Eintrag in der httpd.conf geholfen:

AddDefaultCharset Windows-1252

Postgresql-Server installieren

Das Modul (aktuell: postgresql-server:8.3.1) wie gehabt installieren:

#>fgs install postgresql-server:8.3.1 http://dl.maptools.org/dl/fgs/releases/9.5/modules/

(Falls man upgraden will: fgs erstmal runterfahren und force-install statt install verwenden. Dabei wird man nach dem Port für die Datenbank gefragt. Default ist 5432. Wenn man schon eine DB auf diesem Port laufen hat, kann man z.B. 5433 nehmen und die neue erstmal parallel laufen lassen. Der Port steht hinterher in der Datei /home/fgs/fgs/etc/fgs/pkgs/postgresql-server/pgsql.conf und kann angepasst werden)

Die Datenbank wird zunächst initialisiert:

#>cd /home/fgs/fgs/bin 
#>initdb --locale=POSIX -E LATIN1 -U fgs -D /home/fgs/fgs/apps/pgsql/data

Wenn der Parameter -E weggelassen wird, wird die Datenbank auf Encoding=UTF-8 festgelegt und es ist nicht möglich, Datenbanken mit anderen Encodings zu erzeugen. kvwmap benötigt Latin1. Einen Ausweg gibt es dann über die postgresql.conf.

Bei einer Fehlermeldung, dass die Datei snowball_create.sql nicht existiert, wie hier im Screenshot, muss die Option -L angeben mit Verweis auf /home/fgs/fgs/apps/pgsql/share. Oder man kopiert alle Dateien aus /home/fgs/fgs/apps/pgsql/share nach /home/fgs/fgs/share und startet ohne Option -L.

So sieht es aus nach Kopieren der Dateien und ohne Option -L:

Und die Ausschrift sollte so enden:

Danach die Konfiguration der Rechte in pg_hba.conf eintragen im Verzeichnis /home/fgs/fgs/apps/pgsql/data. In /home/fgs/fgs/apps/pgsql/postgresql.conf das Kommentarzeichen vor Parameter listen_addresses = 'localhost' rausnehmen und auf '*' setzen.

FGS lässt sich ja nicht mehr über "fgs start/stop" steuern, weil der Apache als root gestartet werden muss ("sudo fgs start apache" bzw. "sudo apachectl graceful", siehe FGS unter Port 80 und 443). Deswegen wird die PgSQL-DB so gestoppt bzw. gestartet (das muss nicht als root erfolgen):

#>fgs stop pgsql
#>fgs start pgsql

PostGIS installieren

Das PostGIS Modul (aktuell: postgis-lib:1.3.2) wie mehrfach erprobt installieren:

#>fgs install postgis-lib:1.3.2 http://dl.maptools.org/dl/fgs/releases/9.5/modules/

Es sollten zwei User in der Datenbank angelegt werden, ein Superuser und ein normaler User, der für die Zugriffe auf die DB von den Anwendungen aus verwendet wird. Im Beispiel heißt der Superuser kvwmap_super und der normale User kvwmap.

Die neuen User werden mit Hilfe des Users fgs angelegt (der anschließend keine Rolle mehr spielt). Damit der Superuser fgs weitere User anlegen kann, muss in /home/fgs/fgs/apps/pgsql/data/pg_hba.conf der Eintrag rein:

local   all         fgs        trust

Danach:

#>fgs stop pgsql
#>fgs start pgsql

#>cd /home/fgs/fgs/bin 
#>createuser -p 5433 -U fgs -s kvwmap_super -P
#>createuser -p 5433 -U fgs -s kvwmap -P

Die Angabe des Ports mit -p ist nur nötig, wenn nicht der Standard-Port 5432 verwendet wird. Anschließend in pg_hba.conf den obigen Eintrag wieder entfernen und dafür Einträge für kvwmap_super und kvwmap machen. Dann fgs stoppen und starten ("fgs stop/start pgsql").

Eventuell kann folgender Fehler auftreten:

Das liegt daran, weil in dieser FGS-Version (1.0) das Programm psql auf eine falsche Bibliothek zeigt, die in fgs-dev liegt. Geholfen hat, das Ziel mit einem Link auf die aktuelle Datei zu überschreiben.

#> ldd /home/fgs/fgs/bin/psql

zeigt folgendes:

Mit dem Befehl

#>ln -s /home/fgs/fgs/lib/libpq.so.5.1 /home/fgs/fgs-dev/built/postgresql/lib/libpq.so.5

wird der neue Link angelegt, der auf die richtige libpq.so verweist. Vorher - je nachdem was es war - den alten Link oder Datei löschen (/home/fgs/fgs-dev/built/postgresql/lib/libpq.so.5).

Leere Datenbank anlegen. Wenn es eine ALK-DB für kvwmap sein soll, bei kvwmap-Datenbank_für Postgresql weitermachen. Das Anlegen der DB kann man als kvwmap machen, denn die neue Datenbank gehört dann gleich kvwmap:

#> createdb -p 5433 -U kvwmap postgistemplate

Die Angabe des Ports mit -p ist nur nötig, wenn nicht der Standard-Port 5432 verwendet wird.

Sparachunterstützung für Postgresql installieren mit:

#>createlang -p 5433 -U kvwmap plpgsql postgistemplate

Die Angabe des Ports mit -p ist nur nötig, wenn nicht der Standard-Port 5432 verwendet wird.

Abschließend werden die PostGIS Erweiterungen eingelesen. Den Befehl zum Eintragen der Funktionen muss kvwmap_super vornehmen, wenn User kvwmap kein Superuser ist:

#>psql -p 5433 -U kvwmap_super -f /home/fgs/fgs/apps/pgsql/share/postgis.sql -d postgistemplate

Jetzt fehlt nur noch die Tabelle für die Koordinatensysteme:

#>psql -p 5433 -U kvwmap_super -f /home/fgs/fgs/apps/pgsql/share/spatial_ref_sys.sql -d postgistemplate

Die Angabe des Ports mit -p ist nur nötig, wenn nicht der Standard-Port 5432 verwendet wird.

Das Modul postgis-lib überträgt merkwürdigerweise die beiden Dateien postgis.sql und spatial_ref_sys.sql nicht auf den Server. Man kann aber das Modul von http://dl.maptools.org/dl/fgs/releases/9.5/modules/ herunterladen und die beiden Dateien händisch auf den Server übertragen.

Der EPSG:35833 (ETRS89 mit führender "33") sollte angelegt werden. Möglicherweise ist auch EPSG:3857 ("Google Spherical Mercator") interessant.

Verschiedene Postgis- und Proj4-Versionen können zu fehlerhaften Ergebnissen bei Transformationen führen. Es müssen unbedingt Verbesserungen in der Datei epsg und in der Tabelle spatial_ref_sys durchgeführt werden.

kvwmap-Datenbank für Postgresql

Zuerst wird eine Template-Datenbank eingerichtet und die Spracherweiterung installiert:

#>cd /home/fgs/fgs/bin
#>createdb -p 5433 -U kvwmap alktemplate
#>createlang -p 5433 -U kvwmap plpgsql alktemplate
#> psql -p 5433 -U kvwmap_super -f /home/fgs/fgs/apps/pgsql/share/postgis.sql -d alktemplate
#> psql -p 5433 -U kvwmap_super -f /home/fgs/fgs/apps/pgsql/share/spatial_ref_sys.sql -d alktemplate

Die Angabe des Ports mit -p ist nur nötig, wenn nicht der Standardport 5432 verwendet wird.

Das Modul postgis-lib installiert merkwürdigerweise die beiden Dateien postgis.sql und spatial_ref_sys.sql nicht auf den Server. Man kann aber das Modul von http://dl.maptools.org/dl/fgs/releases/9.5/modules/ herunterladen und die beiden Dateien händisch auf den Server übertragen.

Dann wird die Template-DB in PostgreSQL als Template-Datenbank markiert (das muss wieder der Superuser machen):

#> psql -p 5433 -d alktemplate -U kvwmap_super -c "update pg_database set datistemplate = 't' where datname = 'alktemplate';"

Den Erfolg kann man in pgAdmin3 mit folgendem Befehl testen:

select * from pg_database where datname='alktemplate'

Außerdem müssen noch die bundeslandspezifischen Tabellen erzeugt werden. Diese sind im Verzeichnis SQL_Template im Installationspfad von edbs2wkt zu finden:

• die Schlüsseltabelle der Folien (ALK_Folientabelle_MV.SQL)
• die Schlüsseltabelle der Standardtexte (ALK_Standardtext_MV.SQL)
• die Tabelle der Objektarten für Schraffurwinkel (ALK_SchraffurWinkel_MV.SQL)

Damit der edbs2wkt-Konverter auf die richtige PostgreSQL-Installation zugreift, muss im ODBC-Treiber der richtige Port (im Beispiel: 5433) angegeben werden!

Wenn die Template-Datenbank vorbereitet ist, kann die ALK-DB für kvwmap mit dem edbs2wkt-Konverter angelegt werden. Dafür im Menü Datenbank den Punkt "anlegen" wählen und z.B. folgende Konfiguration vornehmen (PostGIS Template=alktemplate und Encoding=LATIN1 ist wichtig!):

MySQL für kvwmap

Wenn MySQL Server unter SuSE mit YaST installiert wurde, wird der Server defaultmäßig mit dem Socket /var/lib/mysql/mysql.sock gestartet. FGS verlangt den Socket aber unter /tmp. Daher muss in der Datei /etc/my.cnf für MySQL Server und MySQL Client folgendes gesetzt werden:

socket = /tmp/mysql.sock

Im /tmp Verzeichnis muss außerdem ein symbolischer Link angelegt werden, der wieder zurück ins ursprüngliche Verzeichnis zeigt (klingt bekloppt, funktioniert aber):

ln -s /var/lib/mysql/mysql.sock mysql.sock

Anschließend den MySQL Server neu starten.

kvwmap

Wenn kvwmap installiert ist, müssen noch bestimmte Parameter gesetzt werden, die Mapserver und PostGIS betreffen.

• Wenn eigene Dienste (WMS) über den Mapserver angebunden werden, muss im entsprechenden Mapfile die maximale Kartengröße gesetzt werden, wenn diese 2048 Pixel (= Standardeinstellung des FGS-Mapservers) überschreitet. Dazu im Mapobjekt notieren:

MAXSIZE 4096 # oder anderen Wert

• Die URL muss stimmen, speziell wenn SSL-verschlüsselt wird:

define('URL','https://geoportal.lk-nvp.de/');

• Für einige Funktionalitäten in kvwmap wird ImageMagick benötigt. Dieses ist außerhalb von FGS zu installieren. Siehe dazu das HowTo zur Installation von ImageMagick.

--Markus Hentschel 15:11, 11. Mär 2010 (CET) Für ImageMagick gibt es jetzt auch ein FGS-Modul (aktuell fgs-imagemagick-base-6.5.1-10-linux-i386.tar.gz). Ich habe es aber noch nicht getestet.

Module upgraden

Um ein vorhandenes Modul zu upgraden, verwendet man folgenden Befehl:

#>fgs force-install module-name:version from-where

Ein Beispiel für das Upgrade von GDAL:

   $ fgs force-install gdal-base:1.6.1 http://www.maptools.org/dl/fgs/releases/9.5/modules/

FGS löst dabei auch Abhängigkeiten auf, möglicherweise werden also gleich auch noch andere Module einem Upgrade unterzogen. Danach ist FGS neu zu starten.