Skip to content

FTP-Server für GeoNetwork

Linux GeoNetwork ist ein Server für Metadaten von Geodaten. Also Daten die beschreiben was in Geodaten drin ist, wo die Informationen her kommen, was man damit machen darf und vielleicht auch noch wie gut sie sind.

Vor allem natürlich, auf welches Gebiet sie sich beziehen, denn man will ja später mit dem GeoNetwork räumlich suchen können. Also ein Gebiet auf der Karte auswählen und nicht nur nach einen Stichwort suchen müssen.

Um die Daten anzubieten bringt GeoNetwork den GeoServer mit, der zu ziemlich alle gängigen Formate an Geodaten von Shape bis GeoTIFF verwerten und einheitlich als WMS und WFS in allen Karten-Projektionen ausliefern kann, damit man sich die Daten komfortabel in das GIS-Programm eigener Wahl als Layer ziehen kann.

Für die eingetragenen Benutzer des GeoNetwork-Knoten ist es aber auch praktisch, die Geodaten selbst auf den Server hochladen zu können. Dafür bietet sich FTP an, ein Protokoll fast so alt wie das Internet selbst und älter als die meisten seiner Benutzer.

Ich stand vor der Aufgabenstellung, nun dem GeoNetwork noch einen FTP-Server zur Seite zu stellen. So ein FTP-Server ist schnell installiert, die Benutzer des GeoNetwork sollten sich auch dort mit dem selben Namen und Passwort einloggen können.

Glücklicherweise ist der proftpd so flexibel, dass er sich auch gegenüber einem SQL-Server authentifizieren kann. Dazu werden Benutzer und Gruppen in zwei Tabellen gehalten. Die Gruppen hab ich mir erspart und die Tabelle nur entsprechend dem Howto angelegt und leer gelassen:

CREATE TABLE ftpgroups (
groupname character varying(30) NOT NULL,
gid integer NOT NULL,
members character varying(255)
)


Für die Benutzer war der erste Plan, die Tabelle anzulegen und einen Trigger zu definieren, der bei Insert/Update auch die Tabelle ftpusers aktualisiert. Mit einer Abfrage gehts aber noch einfacher und vor allem klappt das auch bei einfachen Datenbank-Systemen:

CREATE OR REPLACE VIEW ftpusers AS
SELECT users.id AS pkid, users.username AS userid, users.password AS passwd, 10000+users.id AS uid, NULL::integer AS gid, NULL::text AS homedir, NULL::text AS shell
FROM users;


Wie man leicht erkennen kann wird das SHA1-verschlüsselte Passwort aus der Benutzertabelle des Geonetwork in die Tabelle der FTP-Benutzer gespiegelt, die Benutzer-ID ist der Primärschlüssel plus 10000 (möglicherweise will man hier auch NULL angeben um die Vorgabe der Konfiguration verwenden zu lassen).

Eine passende Konfigurationsdatei für den proftpd lädt nun nur noch die notwendigen Module und weist den FTP-Server an nur noch den Daten aus den Tabellen zu glauben. Die Defaults für UID und GID sind meiner Installation openSUSE 12.1 entnommen und müssen bei Bedarf angepasst werden.

ServerName "CarBioCial FTP Server"
ServerType standalone
DefaultServer on
Port 21
PassivePorts 49152 65534
DebugLevel 0
SystemLog /var/log/proftpd/proftpd.log
UseIPv6 off
Umask 022
MaxInstances 30
User ftp
Group ftp
LogFormat default "%h %l %u %t \"%r\" %s %b"
LogFormat auth "%v [%P] %h %t \"%r\" %s"
LogFormat write "%h %l %u %t \"%r\" %s %b"
LoadModule mod_sql.c
LoadModule mod_sql_postgres.c
LoadModule mod_sql_passwd.c
AuthOrder mod_sql.c
RootLogin off
AuthPAM off
DefaultRoot ~
RequireValidShell off
SQLBackend postgres
SQLAuthenticate on
SQLEngine on
SQLAuthenticate users*
SQLPasswordEngine on
SQLPasswordEncoding hex
SQLAuthTypes SHA1
SQLConnectInfo geonetwork@localhost geonetwork geopasswd
SQLDefaultUID 40
SQLDefaultGID 49
SQLDefaultHomedir /data/ftp
SQLUserInfo ftpusers userid passwd uid NULL NULL NULL
SQLGroupInfo ftpgroups groupname gid members
SQLUserWhereClause true
SQLNegativeCache off
SQLLogFile /var/log/proftpd/proftpd-sql.log


Danach noch den FTP-Server neu starten und die Benutzer können sich mit ihrem universellen GDI-Passwort einloggen und dies auch im GeoNetwork selbst ändern. Diese wäre mit LDAP nicht möglich gewesen, denn GeoNetwork kann sich nicht an den LDAP-Server binden, sondern nur die Anmeldung darüber durchführen lassen.

Noch ein letzter Tipp: Was hier gebaut wurde geht auch mit so ziemlich jeder Web-Anwendung, die Benutzer in einer SQL-Datenbank speichert. Man kann also genau so einfach ein Forum oder ein Blog mit einem FTP-Server erweitern.

Götterdämmerung

Zum Auftakt dieser letzten Folge des Cachetalks in doppelter Länge treffen sich die Protagonisten vergangener Episoden im Raucherzelt vor dem Berolina-Stammtisch und sprechen über Geschehnisse am Anfang der Welt der Geocaching-Podcasts.



Danach gibt es einen Sprung in die Gegenwart. Das Schicksal des Geocaching ist offen, es bleibt abzuwarten, wie Reviewer und Lackeys die Zukunft gestalten. Lethargisch und unter Einfluß alkoholischer Getränke werden noch aktuelle Themen aus der grünen Hölle verarbeitet.

Damit legt der Cachetalker das Mikrofon aus der Hand. Für ihn heißt es nun: Auf zu neuen Taten! Mögen andere nun die Berufung übernehmen, die Geschehnisse bis zum Untergang zu kommentieren.

cachetalk114.mp3

Navigation im Tierpark Berlin mit OpenStreetMap und GPS

OpenStreetMap Für diesen Artikel, in dem ich mal ganz allgemein erklären möchte, wie man mit QGIS recht einfach Geodaten aus der OpenStreetMap auf Garmin GPS-Empfänger bekommt hätte ich auch "Quantum-GIS für Anfänger" als Überschrift nehmen können. Aber das klingt mir dann doch für die Zielgruppe zu technisch und damit abschreckend

QGIS ist freie Software und kann für Windows, Linux und Mac kostenlos heruntergeladen werden. Zumindest für Windows ist die Installation so einfach wie man das von üblichen Windows-Programmen so kennt. Ein praktisches Beispiel soll das Ganze praktisch nützlich verpacken. Die Vorgehensweise ist auch auf andere Aufgaben übertragbar, bei denen Punkte für ein Gebiet aus der OpenStreetMap gewonnen werden sollen.

Kürzlich war ich mit einer Freundin und Kindern im Tierpark Berlin. Um Verwechslungen zu vermeiden, in Berlin gibts ja aus historischen Gründen alles zweimal: Nicht den Zoologischen Garten, sondern den im Ostteil der Hauptstadt.

Man kann sich natürlich dort mit Wegweisern orientieren, allerdings müsste das mit dem GPS (in meinem Fall ein Garmin Oregano) eleganter gehen. Die notwendigen Daten scheinen in der OpenStreetMap schon enthalten zu sein, da waren einige Mapper offensichtlich fleißig. Damit gilt es "nur noch" die Daten abzuholen und zu konvertieren.

Zunächst wählt man auf der OSM-Webseite das Zielgebiet aus und macht dann einen Export. Die Datei heißt map.osm und kann auch unter diesem Namen in einem neuen Verzeichnis gespeichert und dann mit QGIS und dem OpenStreetMap-Plugin geladen werden.


QGIS erzeugt dann drei Layer: Punkt, Linie und Polygon. Die Linien brauchen wir nicht und werfen sie gleich wieder raus. Die verbleibenden Layer werden in ESRI-ArcGis-Shapes gespeichert, damit wir damit arbeiten können.


Der Polygon-Layer braucht etwas Nachbearbeitung, denn als Polygon erfassten Gehege lassen sich so direkt nicht als Wegpunkt aufs Garmin spielen. Daher werden mit dem Geometrie-Werkzeug aus dem Vektor-Menü die Polygonschwerpunkte bestimmt und in einem neuen Layer gespeichert.


Die beiden Punktlayer können dann geladen und zusammengeführt werden.


Nicht nur wer kleine Kinder kennt weiß wie wichtig es ist zu wissen wo die Toiletten sind. Die haben aber keinen Namen (wozu auch). In der Attributtabelle kann man den nun automatisiert nachtragen. Mit der Suche wird nach "toilet" in Feld "tags" gesucht, dadurch werden die passenden Datensätze markiert und dann mit dem Feldrechner der Name ergänzt.

Danach können alle Felder ohne Namen gelöscht werden. Dazu nach dem Namen sortieren, die ersten Datensätze markieren und im Bearbeitungsmodus den roten Löschknopf drücken.

Nun müssen noch mit dem Plugin Table-Manager die Feldnamen der Tabelle korrigiert und überflüssige Felder gelöscht werden, dann ist die GPX-Datei fertig zum Abspeichern.


Die fertige GPX-Datei kann entweder auf die Speicherkarte des Garmin in das GPX-Verzeichnis kopiert werden, wo auch die Pocket-Queries vom Geocaching sind oder mit dem Garmin POI-Loader als POI hochgeladen werden.

Nano zum Large aufmotzen

Wer die Geocaching-News einigermaßen verfolgt wird in letzter Zeit Artikel gesehen haben, in denen angeblich die neuen Definition der Behältergrößen verändert wurde.

Um das nicht alles wiederzukäuen hier mal ein ganz anderes Filmchen aus der Tube zum Thema. Ein Nano ist auch nach den kleinen Änderungen immer noch ein Micro, mit dem gezeigten Trick kann man ihn ganz locker aufmotzen:


Eine kleine Munkiste hat demnach die Innen-Abmessungen 26 cm lang mal 9 cm breit mal 17,5 cm hoch und damit 4095 cm³, also 4 Liter. Damit steigt sie sicher in die Large-Klasse auf.

Bleibt nur zu hoffen dass Petlinge auch weiterhin als Micro gelistet bleiben, obwohl eindeutig größer als eine Filmdose. Sonst muss ich mein Beuteschema weiter eingrenzen.
tweetbackcheck