Die Karten bei snowhow-maps basieren auf den Daten von Openstreetmap und werden um Geländeinformationen ergänzt. Das Ergebnis sind über 7 Millionen Karten-Kacheln im PNG-Format für den Alpenraum, die mit Carto-CSS und Mapnik (Kosmtik) erzeugt werden.

Da wir unter anderem Felszeichnung und Schummerung in der Karte verwenden, kann mit dem JPEG-Format bei relativ geringem Qualitätsverlust einiges an Platz gespart werden. Um die mächtige Dateistruktur mit einem Einzeiler von PNG in JPEG zu konvertieren und dabei noch ansprechende Dateinamen zu erhalten, kann man folgendes Kommando im Wurzelverzeichnis des Tilestore verwenden:

Mein Desktop-Verhalten ist sicher nicht mehrheitsfähig: Die meiste Zeit meiner Arbeit verbringe ich in Konsole-Fenstern, dann ist da noch Firefox (und manchmal Chromium). Statt Thunderbird verwende ich wieder Mutt, weil es einfach schneller geht (ein gutes Web-Mail muss manchmal aushelfen). Vim ist natürlich der beste Editor der Welt. Für manche Projekte verwende ich aber auch Atom oder VSCode.

Früher – mein Hintergrund

Mein erster Kontakt mit Linux reicht in das Jahr 1994 zurück (ja, da war gerade Linux kernel 1.0). Mit den Mailprogrammen elm und später pine vergingen die 90er Jahre, ge-chatted wurde mit Unix talk. NCSA Mosaic und später Netscape Navigator waren sowieso grandios. Aber auch die Freude über die aufkommenden Linux Desktops war groß: KDE selbst zu kompilieren war zwar eine große Aufgabe, aber einen Desktop wie Windows unter Linux zu haben war sensationell.

Schon seit längerer Zeit verwende ich eine selbst gehostete gitlab Instanz um meine Programmierprojekte zu verwalten. Die Features dieser OpenSource Software sind wirklich sehr beeindruckend.

Bei einem closed source Projekt entstand kürzlich die Notwendigkeit docker images gemeinsam zu verwenden. Die in gitlab integrierte docker registry macht das ohne große Klimmzüge möglich:

docker login gitlab.komplett.cc:4567
docker docker build -t gitlab.komplett.cc:4567/meinegruppe/meinprojekt .
docker push gitlab.komplett.cc:4567/meinegruppe/meinprojekt .
[Weiterlesen]
    

Als ich kürzlich die Zeilen

Waiting for 1.2.3.4

und dann noch

Transferring from 1.2.3.4

in der Status-Zeile des Firefox Browser las wurde ich etwas unrund. Die aufgerufene Seite (http://snowhow.info) hatte ich selbst entwickelt und ganz sicher keinen Link auf http://1.2.3.4 eingebaut. Irgendwie schaute die Seite auch anders aus, aber nicht wesentlich. Also den Quellcode der Seite studiert und da steht es: Vor der head-Anweisung hat jemand Javascript-Code aus einer anderen Domain eingeschleust:

Das Problem

Bei snowhow verwenden wir WordPress als Content-Management-System. Die Benutzer-Accounts für die snowhow User werden auch in WordPress verwaltet. Warum? Das System ist sehr weit verbreitet, die User-Verwaltung sollte also ausgereift sein (ge-hashte Passwörter, Passwort per E-Mail zurücksetzen).

Außerhalb von WordPress als CMS setzen wir auf Nodejs und MongoDB. Die aufgezeichneten Freeride-Tracks und Skitouren kommen als GeoJSON direkt in die MongoDB und können dort via räumlicher Suche gefunden werden, herrlich unkompliziert. Aber wie kann der Nodejs-Server (express) auf die Authentifizierung von WordPress zugreifen?

Eigentlich ist das Port-Forwarding im Router so eingestellt, dass der Remote Zugriff auf den Heimserver problemlos funktioniert. Leider hat der Provider aber die Möglichkeit den Router neu zu initialisieren (und damit meine Forward-Regeln zu löschen) und er macht auch massiv Gebrauch davon. Zwar kann der Server dann weiterhin mit dem Internet kommunizieren (und so auch als nagios-Server andere Server überwachen), der Zugriff von außen funktioniert aber nicht mehr.

Mit einem Server im Internet lässt sich dem Problem ein Schnippchen schlagen, in dem man den Heimserver anweist einen reverse ssh tunnel aufzubauen. Über diesen kann man später auf das Heimnetz zugreifen und die Port-Forwarding Regeln neu einspielen. Damit der Tunnel nach der Unterbrechung durch den Provider wieder hergestellt wird hilft autossh. Mit folgendem Eintrag in /etc/rc.local (Ubuntu Server):

Für verschiedene Dienste bekommen wir stündlich, beziehungsweise täglich Daten von unseren Partnern. Diese Systeme verwenden FTP für den Transfer, weshalb wir einen eigenen FTP-Server (vsftp) betreiben müssen. Der Zugriff wird mehrstufig abgesichert:

• Firewall-Regeln, die den Dienst auf das Subnetz des Partners einschränken
• FTP-Zugriff auf die entsprechenden User einschränken. Dazu wird die vsftp.conf um folgende Einträge ergänzt:

userlist_deny=NO
userlist_enable=YES
userlist_file=/etc/vsftpd.user_list
[Weiterlesen]
    

Das Problem

App-Entwicklung mit Cordova funktioniert großartig. Beim Aufzeichnen von GPS Tracks stößt man aber an die Grenzen der Technologie, da es keine Möglichkeit gibt, einen Prozess zu starten, der nicht automatisch vom System beendet werden kann. Dazu benötigt man ein Plugin…

Ein Android Service

Mit ein wenig Java Kenntnissen ist es einfach einen Hintergrund-Dienst (Service) als Plugin für Cordova zu realisieren. Android kann den Service zwar auch beenden, startet ihn aber sofort wieder, wodurch das GPS tracking fortgesetzt wird. Einen Haken gibt es bei der Sache allerdings: Die Kommunikation zwischen Plugin und der Web-app ist schwierig. Die vorhandene Schnittstelle über den Callback-Context funkioniert (nach meinem Wissen) nicht, da der Service abgekoppelt läuft.

Nach dem letzten Crash bin ich dazu übergegangen die virtuellen Maschinen jede Nacht per lvm-snapshot mit lzop komprimiert zu sichern. Eine separat eingebaute Festplatte (/mnt/backup) hält diese backups. Das ultra-kurze Skript dazu sieht so aus:

#!/bin/bash
LVMS="snowhow komplett root"
VG=vg0
BUP_DST=/mnt/backup/snapshot_vms
NICE=15
VERBOSE=0
## cron needs full path to commands
LVCR=/sbin/lvcreate
LVRM=/sbin/lvremove
LVS=/sbin/lvs
VIRSH=/usr/bin/virsh
while getopts ":vl:" opt; do
  case $opt in
    v)
      VERBOSE=1
      ;;
    l)
      LVMS=$OPTARG
      ;;
  esac
done
function doBackup {
  logger -t SNAPSHOT_BACKUP "starting backup for $LV"
  if [ -f $BUP_DST/$LV-snap.lzo ]
  then
    mv $BUP_DST/$LV-snap.lzo $BUP_DST/$LV-snap.lzo.old
  fi
  $VIRSH suspend $LV
  $LVCR -L1G -s -n $LV-snap /dev/$VG/$LV
  $VIRSH resume $LV
  if [ $VERBOSE -eq 1 ]
  then
    $LVS
    SIZE=$($LVS --nosuffix --units b -o lv_size --rows --separator ':' /dev/$VG/$LV | cut -d':' -f2)
    echo $SIZE
    nice -n $NICE bash -c "dd if=/dev/$VG/$LV-snap bs=4M | pv -s $SIZE | lzop -c | dd of=$BUP_DST/$LV-snap.lzo bs=4M"
    $LVS
  else
    nice -n 15 bash -c "dd if=/dev/$VG/$LV-snap bs=4M | lzop -c | dd of=$BUP_DST/$LV-snap.lzo bs=4M"
  fi
  $LVRM -f /dev/$VG/$LV-snap
  logger -t SNAPSHOT_BACKUP "done backup for $LV"
}
for i in $LVMS
do
  LV=$i
  doBackup
done
[Weiterlesen]
    

Unsere Basiskarte wird laufend um Informationen ergänzt (zum Beispiel ein Shapefile mit Skipisten). Nach einer solchen Ergänzung soll nicht der gesamte Karten-Cache (mod_tile/renderd) neu gerechnet werden, sondern nur der Ausschnitt in dem Veränderungen stattgefunden haben.

Lösung

Drei Schritte um die Kartenkacheln neu zu erzeugen:

Extent des Shapefiles ermitteln

ogrinfo -geom=SUMMARY pp.shp pp
...
Extent: (11.015149, 46.848712) - (11.085476, 46.911385)
...
[Weiterlesen]