Im Folgenden werden die für die Mapbender3-Installation aufgeführten Konfigurationsschritte von Mapbender3 näher erläutert. Es sind sechs Schritte notwendig:
Diese Schritte werden mit dem console-Hilfsprogramm des Symfony Frameworks durchgeführt, auf dem Mapbender3 aufbaut. Hier noch ein wichtiger Hinweis, bevor Sie fortfahren:
Das console-Hilfsprogramm wird Dateien in die Verzeichnisse app/cache und app/logs schreiben. Für diese Operationen werden die Benutzerrechte des Benutzers benötigt, mit dem Sie angemeldet sind. Sie benötigen ebenfalls Benutzerrechte für das Verzeichnis app/db und die SQLite Datenbank. Wenn Sie die Applikation in Ihrem Browser öffnen, wird der Server-PHP- Prozess versuchen, auf diese Dateien zuzugreifen oder in die Verzeichnisse zu schreiben mit anderen Benutzerrechten. Stellen Sie sicher, dass Sie den Verzeichnissen und Dateien Schreib- und Leserechte zugewiesen haben.
Wichtiger Hinweis: Die folgenden app/console Schritte gehen davon aus dass Sie sich oberhalb des app-Verzeichnisses befinden (für die git-Installation bedeutet das mapbender3/application/ andernfalls mapbender3/).
cd mapbender3/
oder für die git-basierte Installation
cd mapbender3/application
Die Parameter der Datenbankverbindung sind zusammen mit einigen anderen Konfigurationsparametern in der Datei app/config/parameters.yml gespeichert. In dieser Datei wird YAML Syntax verwendet. Achten Sie darauf keine Tabulatoren für Einrückungen zu verwenden. Verwenden Sie stattdessen Leerzeichen.
Ihre Datenbankkonfiguration könnte in der parameters.yml könnte folgendermaßen aussehen, wenn Sie PostgreSQL verwenden:
database_driver: pdo_pgsql
database_host: localhost
database_port: 5432
database_name: mapbender3
database_path:
database_user: postgres
database_password: geheim
Mehr Informationen dazu finden Sie im Kapitel Konfiguration der Datenbank.
Mit Symfony2 kann die Datenbank erzeugt werden. Beachten Sie, dass dazu die benötigten Datenbank-Benutzerrechte vorliegen. Rufen Sie folgenden Befehl mit dem console-Hilfsprogramm auf:
app/console doctrine:database:create
Erzeugen des Datenbankschemas über Symfony2:
app/console doctrine:schema:create
Jedes Bundle hat seine eigenen Abhängigkeiten - CSS-Dateien, JavaScript-Dateien, Bilder und mehr – diese müssen in das öffentliche web-Verzeichnis kopiert werden:
app/console assets:install web
Sie können auch einen symbolischen Link verwenden, statt die Dateien zu kopieren. Dies erleichtert die Bearbeitung der abhängigen Dateien in den bundle-Verzeichnissen.
app/console assets:install web --symlink --relative
Der erste Benutzer, der alle Privilegien hat, wird mit folgendem Kommando erzeugt:
app/console fom:user:resetroot
Dieses Kommando wird interaktiv alle notwendigen Informationen abfragen und den Benutzer in der Datenbank erzeugen.
Sie können auch den Modus “silent” verwenden, wenn Sie ein Skript nutzen möchten, um Mapbender3 zu installieren und dabei nicht nach Parametern gefragt werden wollen.
app/console fom:user:resetroot --username="root" --password="root" --email="root@example.com" --silent
Fügen Sie die Informationen zu SRS Parametern über den folgenden Aufruf in die Datenbank:
app/console doctrine:fixtures:load --fixtures=./mapbender/src/Mapbender/CoreBundle/DataFixtures/ORM/Epsg/ --append
Sie können die Anwendungen, die in der mapbender.yml definiert sind, in die Datenbank importieren:
app/console doctrine:fixtures:load --fixtures=./mapbender/src/Mapbender/CoreBundle/DataFixtures/ORM/Application/ --append
Die Basiskonfiguration erfolgt in der Datei app/config/parameters.yml. Eine Vorlage app/config/parameters.yml.dist liegt vor.
Die Konfigurationsdatei app/config/config.yml stellt weitere Parameter bereit, z.B. zur Konfiguration der Portalfunktion, Einrichtung des Owsproxy oder Einrichtung einer weiteren Datenbank.
Hinweis: Sie benötigen einen Mailer, wenn Sie die Selbstregistrierung und das Paßwortsetzen nutzen möchten.
Sofern Sie einen Proxy verwenden, müssen Sie diesen in der Datei parameters.yml im Bereich OWSProxy Configuration angeben.
Eine Konfiguration könnte wie folgt aussehen:
# OWSProxy Configuration
ows_proxy3_logging: false
ows_proxy3_obfuscate_client_ip: true
ows_proxy3_host: myproxy
ows_proxy3_port: 8080
ows_proxy3_connecttimeout: 60
ows_proxy3_timeout: 90
ows_proxy3_user: ~
ows_proxy3_password: ~
ows_proxy3_noproxy:
- 192.168.1.123
Hinweis: Sie benötigen einen Mailer, wenn Sie die Selbstregistrierung und das Paßwortsetzen nutzen möchten.
Eine Anwendung kann auf zwei Arten konfiguriert werden. Entweder über die mapbender.yml Datei oder über die Mapbender3 Administration im Browser.
app/console doctrine:fixtures:load --fixtures=./mapbender/src/Mapbender/CoreBundle/DataFixtures/ORM/Application/ --append
Mapbender3 bietet zwei Umgebungen an: eine Produktionsumgebung für den normalen Betrieb- und eine Entwicklerumgebung, in dem die Anwendungen getestet werden können. Dieses Konzept orientiert sich an den “Environments” im Symfony Framework.
Die Produktionsumgebung wird mit der URL http://localhost/mapbender3/app.php aufgerufen, die Entwicklungsumgebung mit der URL http://localhost/mapbender3/app_dev.php. Der Aufruf über app_dev.php kann und sollte nur nur vom localhost erfolgen.
Es gibt Unterschiede im Verhalten von app.php und app_dev.php:
Der Cache-Mechanismus verhält sich in der Entwicklungsumgebung anders: Es werden nicht alle Dateien gecacht, so dass vorgenommene Änderungen direkt sichtbar sind. Dadurch ist der Aufruf einer Anwendung über app_dev.php immer langsamer als im Produktivbetrieb.
Im Detail werden in der Entwicklerumgebung von Mapbender3 u.a. die CSS, JavaScript und Übersetzungsdateien nicht gecacht.
In der Produktionsumgebung werden diese aber in app/cache abgelegt.
In der Entwicklerumgebung werden Fehlermeldungen und ihr Stacktrace direkt an der Oberfläche angezeigt. In der Produktionsumgebung werden die Fehlermeldungen in die Datei app/log/prod.log geschrieben.
Die Entwicklungsumgebung zeigt den Symfony Profiler an. Dort werden Dinge protokolliert, die nur für die Entwickler, aber nicht für Außenstehende sichtbar sein sollten.
Das Verzeichnis app/cache enthält die einzelnen Cache-Dateien. Es werden Verzeichnisse für jede Umgebung (prod und dev) angelegt, das Verhalten des dev-Caches ist aber, wie angesprochen, anders.
Bei Änderungen an der Oberfläche oder im Code von Mapbender3 ist das Cache Verzeichnis (app/cache) zu leeren, damit die Änderungen in der Produktionsumgebung sichtbar werden.
Der folgende Screenshot zeigt den Ort der Cache-Verzeichnisse innerhalb von Mapbender3:
Das Log-Level wird in den Dateien config_dev.yml und config_prod.yml definiert. Diese liegen im Ordner application/app/config/. Die config-Dateien sind für die jeweiligen Umgebungen (siehe Produktions- und Entwicklungsumgebung) verantwortlich.
In der Entwicklungsumgebung (bei der Entwicklung in lokalen Systemen) wird Mapbender3 über die app_dev.php aufgerufen und hier ist die config_dev.yml verantwortlich. Im Produktivbetrieb, bei der die app.php eingesetzt wird, kommt die config_prod.yml zum Einsatz.
Es gibt insgesamt 6 Loglevel (englische Beschreibung):
Die Beschreibung der Loglevels orientiert sich an dem Syslog Protocol der IETF.
Der verantwortliche Teil in der config_dev.yml ist im Abschnitt “monolog” zu finden:
monolog:
handlers:
main:
type: stream
path: %kernel.logs_dir%/%kernel.environment%.log
level: debug
firephp:
type: firephp
level: info
Es sind zwei “Handler” beschrieben, main und firephp.
Diese sind die die bevorzugten Einstellungen für Entwicklungsarbeiten.
monolog:
handlers:
main:
type: fingers_crossed
action_level: error
handler: nested
nested:
type: stream
path: "%kernel.logs_dir%/%kernel.environment%.log"
level: debug
Mit diesen Einstellungen wird ein zweistufiges Logging erreicht. Auch hier haben wir zwei “Debug-Handler”: main und nested.
main: Der main-Handler ist vom Typ fingers-crossed und auf das Level error eingestellt. Das bedeutet, dass dieser Handler nur aktiviert wird, wenn ein Fehler auftritt.
nested: Der main-Handler ruft dann den Handler nested auf, der die Meldungen in die prod.log schreibt.
Dieser Handler ist per Default auf debug eingestellt, so dass bei einem Fehler in der prod.log dann auch die Debug-Meldungen erscheinen.
Möchte man die Ausgabe der Debug-Meldungen unterbinden, kann man dort ebenfalls das Level error eintragen.
Weiterführende Links: