diff options
Diffstat (limited to 'source/00_content/articles')
35 files changed, 0 insertions, 2843 deletions
diff --git a/source/00_content/articles/2010-02-06_debian_auf_dem_sheevaplug.md b/source/00_content/articles/2010-02-06_debian_auf_dem_sheevaplug.md deleted file mode 100644 index fb82abb..0000000 --- a/source/00_content/articles/2010-02-06_debian_auf_dem_sheevaplug.md +++ /dev/null @@ -1,59 +0,0 @@ -# Debian auf dem SheevaPlug - -Auf dem herkömmlichen [Weg](http://www.cyrius.com/debian/kirkwood/sheevaplug/) ist es zwar möglich ein Debian auf dem SheevaPlug zu installieren, jedoch nur auf einem externen USB-Stick oder auf einer SD-Karte. Die Installation auf dem 512MB großen internen Flashspeicher des Plugs ist damit nicht möglich. Es gibt jedoch einen Weg um Debian auch im internen Speicher zu installieren, der auch noch um einiges komfortabler als der oben verlinkte Weg ist. - -Als erstes laden wir uns den normalen SheevaInstaller herunter mit dem man Ubuntu 9.04 auf dem Sheeva installieren kann ([klick](http://www.plugcomputer.org/index.php/us/resources/downloads?func=select&id=5)). Nach dem wir den Tarball heruntergeladen haben sollte man ihn entpacken. Als nächstes laden wir ein Debian Lenny / Squeeze Prebuild von [hier](http://www.mediafire.com/sheeva-with-debian) herunter. Nun ersetzen wir die „rootfs.tar.gz“ mit der neuen Debian „rootfs.tar.gz“. Bevor wir jedoch mit der Installation beginnen müssen wir die neue „rootfs.tar.gz“ mit „tar“ entpacken. Dazu führen wir auf der Konsole - -```sh -mkdir rootfs -cd rootfs -tar xfvz rootfs.tar.gz -``` - -aus. In dem Ordner führen wir nun ein - -```sh -mknod -m 660 dev/ttyS0 c 4 64 -``` - -aus. Mit diesem Befehl wird die fehlende serielle Konsole erstellt. Jetzt verpacken wir das Archiv wieder mit - -```sh -tar cfvz ../rootfs.tar.gz * -``` - -Den gesamten Inhalt des Ordners /install im SheevaInstaller-Verzeichniss müssen wir jetzt auf einen mit FAT formatierten USB-Stick kopieren. Diesen stecken wir schon einmal in den USB-Port des Sheevas. Als nächstes verbinden wir den SheevaPlug mit einem Mini-USB Kabel mit unserem Computer und führen das Script „runme.php“ aus. Wenn alles klappt wird nun ein neuer Boot-Loader und das rootfs auf den Plug kopiert. Dannach ist unser Debian einsatzbereit. -Sollte der Plug den USB-Stick nicht erkennen und somit auch das rootfs nicht kopieren können hilft es einen anderen USB-Stick zu verwenden. Beispielsweise wurde mein SanDisk U3 Stick trotz gelöschtem U3 nicht erkannt. Mit einem anderen Stick funktionierte es jedoch tadelos. Auch sollte der Stick partitioniert sein. Der Bootloader des SheevaPlugs kann nicht gut mit direkt auf dem Stick enthalten Dateisystemen umgehen. Wenn die MiniUSB Verbindung beim Ausführen des runme-Scripts nicht funktionieren sollte hilft oft ein - -```sh -rmmod ftdi_sio -``` - -und - -```sh -modprobe ftdi_sio vendor=0x9e88 product=0x9e8f -``` - -(beides als root). Ebenfalls sollte kein zweites Serielles-Gerät am Computer angeschlossen sein. -Bei neueren Plugs kann man bei Problemen bei der Installation die Datei „uboot/openocd/config/interface/sheevaplug.cfg“ im SheevaInstaller-Ordner nach - -```sh -interface ft2232 -ft2232_layout sheevaplug -ft2232_vid_pid 0×0403 0×6010 -#ft2232_vid_pid 0x9e88 0x9e8f -#ft2232_device_desc “SheevaPlug JTAGKey FT2232D B” -jtag_khz 2000 -``` - -umändern. -Wenn Debian jetzt auf dem SheevaPlug läuft und man sich über SSH einloggen konnte (pwd: nosoup4u), sollte man als erstes ein Update machen. - - apt-get update && apt-get dist-upgrade - -Über die Paketverwaltung kann man jetzt ganz einfach die benötigte Software installieren. Ich setzte auf meinem Plug z.B. lighttpd als Webserver mit PHP5 und MySQL für diese Website ein. Es empfielt sich /var und /tmp auszulagern um Löschzyklen zu sparen. Für /tmp eignet sich eine ramdisk. - -## Erfahrungen - -Ein Debian ist eine gute Alternative zu dem vorinstallierten Ubuntu 9.04. Denn dieses wirft Fehler bei booten aus und hat anfangs Konfigurationsprobleme. Auch braucht es im Vergleich zum Debian eine Ewigkeit zum booten. Das mag bei einem Server nicht wichtig sein, aber ich finde es dennoch schön schnell rebooten zu können. Das gute ist, dass man wenn man schon Erfahrung mit Ubuntu hat auch sehr gut mit Debian zurechtkommt. Aber Ubuntu Karmic lässt sich leider nicht mehr auf dem SheevaPlug installieren. Der SheevaPlug ist erstaunlich schnell. Er erstellt die Seiten etwa doppelt so schnell wie die Server des vorher von mir verwendeten Gratishoster “bplaced.net”. Auch hat er einen sehr geringen Stromverbrauch von nur 5 Watt. Und selbst wenn Webhostingangebote zumindest in der Internetanbindung schneller sein mögen, hat man mit einem SheevaPlug einen sehr günstigen Root-Server, auf dem man tun und lassen kann was man will. diff --git a/source/00_content/articles/2010-02-24_traffic_ueberwachung_mit_vnstat.md b/source/00_content/articles/2010-02-24_traffic_ueberwachung_mit_vnstat.md deleted file mode 100644 index 9178cab..0000000 --- a/source/00_content/articles/2010-02-24_traffic_ueberwachung_mit_vnstat.md +++ /dev/null @@ -1,10 +0,0 @@ -# Traffic-Überwachung mit vnstat - -Heute möchte ich euch ein kleines und praktisches Programm zum Überwachen des Netzwerkverkehrs vorstellen: [vnstat](http://humdi.net/vnstat/). -vnStat ist ein konsolenbasierter Netzwerkverkehrmonitor der Logs mit der Menge des Datenverkehrs auf beliebigen Netzwerkschnittstellen speichert. Aus diesen Logs generiert vnStat dann diverse Statistiken. - -{.full} - -Installieren kann man vnstat unter Debian bequem aus den Paketquellen mit `apt-get install vnstat` oder unter ArchLinux mit `pacman -S vnstat`. Gestartet wird vnStat mit `vnstat`. Sobald der Daemon läuft schreibt vnstat den aktuellen Netzwerkverkehr in eine Datenbank. Durch Anhängen von Argumenten kann man jetzt schöne Statistiken auf der Konsole ausgeben, z.B. eine Statistik über die letzten Tage mit `vnstat -d` (siehe Bild) oder über die letzten Wochen mit `vnstat -w`. Eine Übersicht über alle möglichen Argumente bekommt man wie Üblich über `vnstat –help`. Eine sehr Interessante Funktion wie ich finde ist die Möglichkeit zur live-Anzeige des Verkehrs mit `vnstat -h`. - -Ich finde vnStat zum Überwachen des Netzwerkverkehrs wirklich sehr praktisch, und auch das Anzeigen des Verkehrs über die letzen Tage, Wochen oder Monate ist nützlich. vnStat ist dabei sehr ressourcenschonend und verlangsamt das Netzwerk selbst nicht (es schaltet sich nicht etwa zwischen System und Netzwerkkarte). Für die Anzeige des Traffics auf einer schicken Internetseite gibt es auch das [vnStat PHP frontend](http://www.sqweek.com/sqweek/index.php?p=1). Weiterführende Informationen bekommt ihr auch auf der [Webpräsenz von vnStat](http://humdi.net/vnstat/). diff --git a/source/00_content/articles/2010-03-16_erfahrungen_mit_dem_sheevaplug_im_laengeren_einsatz.md b/source/00_content/articles/2010-03-16_erfahrungen_mit_dem_sheevaplug_im_laengeren_einsatz.md deleted file mode 100644 index 2e2369e..0000000 --- a/source/00_content/articles/2010-03-16_erfahrungen_mit_dem_sheevaplug_im_laengeren_einsatz.md +++ /dev/null @@ -1,22 +0,0 @@ -# Erfahrungen mit dem SheevaPlug im längeren Einsatz - -Da ich den SheevaPlug ja jetzt schon seit längerer Zeit einsetze und auch dieses Blog auf ihm gehostet ist, will ich jetzt einmal über meine Erfahrungen mit dem Einsatz des SheevaPlugs über längere Zeit als Webserver berichten. - -Der SheevaPlug ist wirklich stabil und läuft ohne Probleme mit Debian Lenny. Als Webserver setze ich, wie schoneinmal geschrieben Lighttpd ein. Apache2 läuft zwar auch einwandfrei, jedoch ist die Erstellungszeit der Seiten mit PHP bei Lighttpd doch noch etwas schneller. Auch ist der Speicherverbrauch im RAM merklich geringer, was bei den 512 MB Ram des Plugs doch ganz nett ist. - -Als Datenbankserver verwende ich MySQL, welches zwar doch eine ganz schöne größe auf dem NAND-Speicher hat aber wirklich gut funktioniert. Zur Verwaltung der Datenbanken verwende ich phpMyAdmin. Auch das läuft wirklich zufriedenstellend und schnell übers Netzwerk. - -Da ich mit den Schreibzyklen und der Kapazität des NANDs möglichst sparsam umgehen möchte, habe ich /var komplett auf eine SD-Karte ausgelagert. Der SD-Reader ist schnell genug, nur wäre es schön, wenn die Karte irgendwie einrasten würde, da sie beim versehentlichen Verschieben des Plugs gerne herausrutscht. Jedoch bereue ich es mittlerweile, dass ich nicht das komplette System auf eine SD-Karte ausgelagert und im NAND nur ein Backup-OS belassen habe, da man mit nur 462 MB nicht wirklich viel machen kann. Auch steigt die Datenmenge im Speicher während der Plug läuft “zufällig” an. Er wird über die Wochen immer voller und kraxelt gemütlich den 65% entgegen (zumindest kann ich keine bestimmte Aktion meinerseits damit verbinden). Hat einer von euch eventuell eine Idee woran das liegen könnte? - -Auch verursacht der MySQL-Server in ebanfalls ungleichen Abständen eine 100%ige CPU-Auslastung, ich kann daraufhin nurnoch mit SSH und nicht mer über den Webserver auf den Plug zugreifen. Das abschießen von MySQL und auch ein reboot funktionieren nicht. Gebe ich “reboot” als root ein, werden zwar entsprechende Meldungen ausgegeben, rebooten tut der PlugComputer jedoch nicht (dann hilft nurnoch der harte Weg – Strom weg). Es ist so wirklich kein guter Zustand, sollte ich einmal für mehrere Tage keinen HW-Zugriff auf den SheevaPlug haben und es würde wieder anfangen, könnte ich nichts machen um den Fehler zu beheben. Hat auch zu diesem Problem (das vllt. nicht unbedingt am Plug, sondern auch an einer Fehlkonfiguration von mir liegt) vielleicht einer von euch eine mögliche Lösung parat? - -Das Netzwerkinterface des Plugs ist für mich ausreichend schnell (macht bei dem mageren DSL 2000 eh nichts aus), so wie es aussieht ist das einzige was wirklich ausbremst die Schreib- und Lesegeschwindigkeit des Speichers. Für einen Webserver reicht es jedoch ohne Probleme, nur zum Sichern der Backups könnte es schneller sein. - -Im Betrieb wird der Plug nur Handwarm, das einzige was man vllt. verbessern könnte wäre das störende Blinken des Netzwerkanschlusses. Damit könnte man den Energieverbrauch sicher noch ein wenig weiter senken, denn der Plug ist wirklich festlich beleuchtet. Sitzt man im dunkeln direkt daneben, kann das Blinken und Leuchten wirklich stören. -Die 1.2 Ghz der CPU reichen gut aus, schneller muss es für einen Webserver bei nicht explodierenden Besucherzahlen nicht sein (wobei das Problem vorher eher die Netzwerkanbindung nach außen wäre, aber für solche Belastungen ist der Plug ja auch nicht gebaut). - -Noch etwas zu den Anwendungen die ich auf dem SheevaPlug einsetze: WordPress für diesen Blog, Piwik um euch zu überwachen und phpMyAdmin für die Datenbanken. Ebenfalls läuft Dovecot als IMAP-Server in dem die Mails meiner verschiedenen Postfächer per fetchmail gesammelt und mit procmail sortiert werden. Torrents lade ich über das Webinterface von Transmission herunter, anderes über Nacht mit at und wget. - -Man sieht, der SheevaPlug lässt sich wirklich zu einigem gebrauchen und er funktioniert auch über längere Zeit gut. Als Alternative zu Debian bin ich neulich über [ArchMobile](http://www.archmobile.org/) gestolpert, einer Variante meiner Lieblingsdistribution für ARM, welche auch auf dem SheevaPlug läuft. Die Paketquellen sind allerdings noch etwas leer und beinhalten nicht alle Software die ich für den Webserver bräuchte. Und da ich keine Lust habe alles selber zu kompilieren (vor Arch habe ich Gentoo auf meinem Desktop eingesetzt), kommt es zur Zeit als Alternative für mich leider noch nicht in Frage. Werde aber trozdem informiert bleiben und eventuell auch einmal näher darüber [berichten](/symphony/artikel/plugbox-linux-ein-archlinux-port-fuer-den-sheevaplug). - -Der SheevaPlug ist wirklich ein wunderbares kleines Teil und ich habe durch ihn viel über Linux gelernt – allein dadurch hat er sich schon gelohnt. diff --git a/source/00_content/articles/2010-07-12_ocr_und_automatische_uebersetzung_mit_dem_n900.md b/source/00_content/articles/2010-07-12_ocr_und_automatische_uebersetzung_mit_dem_n900.md deleted file mode 100644 index 7ccc7ec..0000000 --- a/source/00_content/articles/2010-07-12_ocr_und_automatische_uebersetzung_mit_dem_n900.md +++ /dev/null @@ -1,17 +0,0 @@ -# OCR und automatische Übersetzung mit dem N900 - -Heute bin ich auf einem Streifzug durch das Maemo5 testing-Repository auf ein sehr praktisches Programm gestoßen: PhotoTranslator. Mit ihm lässt sich der Text aus Bildern extrahieren und mittels Google-Translate übersetzen. - -{.full width="600px"} - -Das ist z.B. praktisch um fremdsprachige Speisekarten o.ä. in die eigene Sprache zu übersetzen. Nachdem man ein Bild ausgewählt oder direkt aus dem Programm heraus eines erstellt hat (funktioniert in der aktuellen Alpha-Version von PhotoTranslator noch nicht richtig) muss man als erstes den gewünschten Textteil mittels eines Rahmens, wie man ihn auch zum Zuschneiden von Fotos im Bildbetrachter des N900 verwendet auswählen – zur Zeit geht das jedoch leider nur mit einzelnen Zeilen und nicht mit ganzen Textblöcken. - -{.full width="600px"} - -Danach muss man nurnoch die Ausgangs und Zielsprache wählen, kurz warten und schon bekommt man den eingescannten Ausgangstext und die Übersetzung präsentiert. Das funktioniert auch schon in dieser frühen Alpha-Version sehr gut. - -{.full width="600px"} - -PhotoTranslator lässt sich aber nicht nur zum Übersetzen von Bildern, sondern auch als einfache Oberfläche für Google-Translate mit Texteingabe über die Tastatur verwenden. -Weitere Informationen und ein Demo-Video findet ihr unter [cybercomchannel.com](http://www.cybercomchannel.com/?p=63). Installieren lässt sich PhotoTranslator bei aktivierten extras-testing Repositories bequem aus der Paketverwaltung des N900 heraus. -Anmerkung: Auch diesen Artikel habe ich komplett aus dem Browser des N900 heraus geschrieben – das Gerät ist einfach fantastisch, ich kann es nur empfehlen. diff --git a/source/00_content/articles/2010-12-09_plugbox_linux_ein_archlinux_port_fuer_den_sheevaplug.md b/source/00_content/articles/2010-12-09_plugbox_linux_ein_archlinux_port_fuer_den_sheevaplug.md deleted file mode 100644 index 56d992f..0000000 --- a/source/00_content/articles/2010-12-09_plugbox_linux_ein_archlinux_port_fuer_den_sheevaplug.md +++ /dev/null @@ -1,12 +0,0 @@ -# PlugBox Linux - Ein ArchLinux Port für den SheevaPlug - -Nachdem ich ja jetzt einige Zeit Debian Lenny auf meinem SheevaPlug eingesetzt habe, verwende ich seit kurzem Plugbox Linux. [Plugbox](http://archlinuxarm.org/) ist eine Portierung von [ArchLinux](https://archlinux.de) auf den SheevaPlug und einige andere ARM-Hardware wie PogoPlug, Dockstar, GuruPlug und diverse Smartphones wie das N900. - -Seit einiger Zeit läuft Arch also jetzt nicht mehr nur auf meinem Desktop sondern auch auf meinem Plug – und was soll ich sagen, ich bin einfach begeistert! -Es läuft über längere Zeit zu meinem Erstaunen um einiges besser und stabiler als Debian. Ich habe bis jetzt keinerlei Probleme mehr mit MySQL CPU-Auslastung oder Zulaufen des Arbeitsspeichers. Ich kann den Plug jetzt tatsächlich über Monate ohne Reboot laufen lassen – bei Debian war ja leider öfter nötig. - -Nett ist es auch, dass ich mich nicht an neue Konfigurationsdateien gewöhnen und Pacman als Paketverwaltung verwenden kann. Auch die Installation von Paketen aus dem AUR wird unterstützt. Das war bei mir allerdings bis jetzt noch nicht nötig, da alles was ich zur Zeit brauche (Lighttpd, MySQL, php, python etc.) schon vorkompiliert in den Paketquellen vorhanden ist. Die Pakete werden übrigens nicht crosskompiliert o.ä. sondern werden direkt auf einem SheevaPlug erstellt. - -## Installation - -Installieren kann man das rootfs Image mit dem [SheevaPlug Installer 1.0](http://plugcomputer.org/data/docs/sheevaplug-installer-v1.0.tar.gz) sowohl im NAND des Plugs als auch auf einer SD Karte. Bei der Installation auf einer SD Karte musste ich für einen fehlerfreien Bootvorgang die Uboot bootcmd um ein zweites “mmcinit;” erweitern – ohne diese Anpassung blieb der Bootloader bei einem Kaltstart hängen. diff --git a/source/00_content/articles/2011-03-31_sheevaplug_ueberwachung.md b/source/00_content/articles/2011-03-31_sheevaplug_ueberwachung.md deleted file mode 100644 index 311f34c..0000000 --- a/source/00_content/articles/2011-03-31_sheevaplug_ueberwachung.md +++ /dev/null @@ -1,89 +0,0 @@ -# SheevaPlug Überwachung - -Um den Überblick über die Auslastung und den Traffic meines SheevaPlugs zu behalten setze ich [Conky](http://conky.sourceforge.net/), [dstat](http://freshmeat.net/projects/dstat/) und [gnuplot](http://www.gnuplot.info/) ein. - -Den Systemmonitor Conky lasse ich mit dem Befehl `ssh -X -vv -Y -p 22 adrian@asterix "conky -c /home/adrian/.conkyrc"` über X-forwarding in meiner XFCE-Session anzeigen. Das klappt einwandfrei und ergibt zusammen mit dieser [Conky-Konfiguration](http://adrianktools.redirectme.net/files/.conkyrc) und einer lokalen Conky-Instanz folgendes Bild: - -{.full} - -Zusätzlich loggt der SheevaPlug regelmäßig die aktuellen Systemdaten wie CPU-Auslastung, Netzwerkverkehr und belegten Arbeitsspeicher und generiert sie zu Graphen die mir dann jede Nacht per eMail zugesand werden. -Zum Loggen der Daten verwende ich dstat das mit folgendem, von einem Cron-Job gestarteten Befehl aufgerufen wird: - -```sh -dstat -tcmn 2 1 | tail -1 >> /var/log/systat.log -``` - -Die Argumente -tcmn geben hierbei die zu loggenden Systemdaten und deren Reihenfolge an – heraus kommen Zeilen wie diese: - - 31-03 19:40:04 | 2 4 95 0 0 0 | 141M 11.3M 71.6M 277M | 684B 736B - -Um 0 Uhr wird dann die Log-Datei von einem Cron-Job mit diesem Script wegkopiert, Graphen werden von gnuplot generiert und dann mit einem kleinen Python-Programm versendet. - -```sh -#!/bin/sh -mv /var/log/systat.log /root/sys_graph/stat.dat -cd /root/sys_graph/ -./generate_cpu.plot -./generate_memory.plot -./generate_network.plot -./send_report.py -``` - -Hier das gnuplot-Script zur Erzeugung des CPU-Graphen als Beispiel: - -```sh -#!/usr/bin/gnuplot -set terminal png -set output "cpu.png" -set title "CPU usage" -set xlabel "time" -set ylabel "percent" -set xdata time -set timefmt "%d-%m %H:%M:%S" -set format x "%H:%M" -plot "stat.dat" using 1:4 title "system" with lines, \ -"stat.dat" using 1:3 title "user" with lines, \ -"stat.dat" using 1:5 title "idle" with lines -``` - -… und hier noch das Python-Programm zum Versenden per Mail: - -```python -#!/usr/bin/python2 -import smtplib -from time import * -from email.mime.image import MIMEImage -from email.mime.multipart import MIMEMultipart - -lt = localtime() - -# Mail-Header -msg = MIMEMultipart() -msg['Subject'] = strftime('Leistungsreport – %d%m%Y', lt) -msg['From'] = 'reports@asterix' -msg['To'] = 'mail@mail.mail' - -msg.preamble = strftime('Leistungsreport – %d%m%Y', lt) - -# Attachments -fileArray = ['cpu.png','memory.png','network.png'] -for file in fileArray: - fp = open(file, ‘rb’) - img = MIMEImage(fp.read()) - fp.close() - msg.attach(img) - -# Login in SMTP-Server -s = smtplib.SMTP('smtpmail.t-online.de') -s.login('mail@mail.mail', '#####') - -s.sendmail('mail@mail.mail', 'mail@mail.mail', msg.as_string()) -s.quit() -``` - -Als Endergebniss erhalte ich dann täglich solche Grafiken per Mail: - -{.full .clear} - -Ich finde es immer wieder erstaunlich mit wie wenigen Zeilen Quelltext man interessante Sachen unter Linux erzeugen kann – oder besser wie viel Programme wie gnuplot mit nur wenigen Anweisungen erzeugen können. So hat das komplette Schreiben dieser Scripts mit Recherche nur etwa 1,5 Stunden gedauert – inklusive Testen. -Alle verwendeten Programme sind in den ArchLinux Paketquellen vorhanden – auch in denen von PlugBox-Linux, einer Portierung von ArchLinux auf ARM-Plattformen die ich nur immer wieder empfehlen kann – besonders nach den jetzt oft erscheinenden Paket-Updates. Aber dazu auch dieser Artikel: [Plugbox Linux – Ein ArchLinux Port für den SheevaPlug](/article/plugbox_linux_ein_archlinux_port_fuer_den_sheevaplug/). diff --git a/source/00_content/articles/2011-06-14_darstellen_von_gps_daten_mit_gnuplot.md b/source/00_content/articles/2011-06-14_darstellen_von_gps_daten_mit_gnuplot.md deleted file mode 100644 index 28c95de..0000000 --- a/source/00_content/articles/2011-06-14_darstellen_von_gps_daten_mit_gnuplot.md +++ /dev/null @@ -1,99 +0,0 @@ -# Darstellen von GPS Daten mit gnuplot - -Bei meiner letzten Wanderung in den Schweizer Alpen habe ich spaßeshalber das N900 alle 10 Sekunden meine Position loggen lassen. Als Ergebnis erhielt ich dann ein aus 1991 Messpunkten bestehendes XML entsprechend der GPX Spezifikation. - -Die Daten der Messpunkte sind im XML als `trkpt`-Tags gespeichert. Enthalten sind jeweils der Längen- und Breitengrad, die Uhrzeit, der Modus (3d / 2d), die Höhe über Null und die Anzahl der zur Positionsbestimmung genutzten Satelliten. Aussehen tut das ganze dann z.B. so: - -```xml -<trkpt lat="47.320591" lon="9.329439"> - <time>2011-06-12T07:57:39Z</time> - <fix>3d</fix> - <ele>870</ele> - <sat>6</sat> -</trkpt> -``` - -Diese Daten lassen sich nun sehr einfach Verarbeiten – ich habe das Python `xml.dom.minidom` Modul verwendet. Um die Positionen einfacher verwenden zu können, werden sie mit dieser Funktion in Listenform gebracht: - -```python -def getPositions(xml): - doc = minidom.parse(xml) - node = doc.documentElement - rawTrkPt = doc.getElementsByTagName("trkpt") - positions = [] - for TrkPt in rawTrkPt: - pos = {} - pos["lat"] = TrkPt.getAttribute("lat") - pos["lon"] = TrkPt.getAttribute("lon") - pos["ele"] = int(TrkPt.getElementsByTagName("ele")[0].childNodes[0].nodeValue) - positions.append(pos) - return positions -``` - -Aus dieser Liste kann ich jetzt schon einige Kennzahlen ziehen: - -```python -def printStats(gpxPositions): - highEle = gpxPositions[0]["ele"] - lowEle = gpxPositions[0]["ele"] - for pos in gpxPositions: - if pos["ele"] > highEle: - highEle = pos["ele"] - if pos["ele"] < lowEle: - lowEle = pos["ele"] - eleDiv = highEle - lowEle - print "Measure points: " + str(len(gpxPositions)) - print "Lowest elevation: " + str(lowEle) - print "Highest elevation: " + str(highEle) - print "Height difference: " + str(eleDiv) -``` - - -Die Kennzahlen für meine Testdaten wären: - - Measure points: 1991 - Lowest elevation: 863 - Highest elevation: 1665 - Height difference: 802 - -Da die Daten ja, wie schon im Titel angekündigt, mit gnuplot dargestellt werden sollen werden sie mit dieser Funktion in für gnuplot lesbares CSV gebracht: - -```python -def printCsv(gpxPositions): - separator = ';' - for pos in gpxPositions: - print pos["lat"] + separator + pos["lon"] + separator + str(pos["ele"]) -``` - -## Plotten mit gnuplot - -{.full .clear} - -Eine solche, dreidimensionale Ausgabe der GPS Daten zu erzeugen ist mit der `splot`-Funktion sehr einfach. - -```sh -#!/usr/bin/gnuplot -set terminal png size 1280,1024 -set output "output.png" -set multiplot -set yrange [9.365:9.31] -set xrange [47.325:47.28] -set zrange [800:1700] -set view 28,272,1,1 -set ticslevel 0 -set grid -set datafile separator ';' -splot "/home/adrian/projects/gpxplot/wanderung_120611.csv" with impulses lt 3 lw 1 -splot "/home/adrian/projects/gpxplot/wanderung_120611.csv" with lines lw 2 -unset multiplot -``` - -Mit `set terminal png size 1280,1024` und `set output "output.png"` werden zuerst das Ausgabemedium, die Größe und der Dateiname der Ausgabe definiert. Dannach aktiviert `set multiplot` den gnuplot-Modus, bei dem mehrere Plots in einer Ausgabe angezeigt werden können. Dieses Verhalten brauchen wir hier, um sowohl die Strecke selbst als rote Line, als auch die zur Verdeutlichung verwendeten blauen Linien gleichzeitig anzuzeigen. -Mit `set [y,x,z]range` werden die Außengrenzen des zu plottenden Bereichs gesetzt. Dies ließe sich natürlich auch über ein Script automatisch erledigen. Als Nächstes wird mit `set view 28,272,1,1` die Blickrichtung und Skalierung definiert. `set ticslevel 0` sorgt dafür, dass die Z-Achse direkt auf der Grundebene beginnt. Um ein Gitter auf der Grundfläche anzuzeigen, gibt es `set grid`. -Als letztes werden jetzt die zwei Plots mit `splot` gezeichnet. Die Angaben hinter `with` steuern hierbei das Aussehen der Linien. - -Falls jemand den Artikel mit meinen Daten nachvollziehen möchte - das GPX-File kann hier heruntergeladen werden: [2011-06-12.gpx](https://static.kummerlaender.eu/media/2011-06-12.gpx) - -Zum Schluss hier noch ein Blick vom Weg auf den Kronberg Richtung Jakobsbad im Appenzell: - -{.full} diff --git a/source/00_content/articles/2011-09-03_die_sache_mit_dem_netzteil.md b/source/00_content/articles/2011-09-03_die_sache_mit_dem_netzteil.md deleted file mode 100644 index 4da8fdb..0000000 --- a/source/00_content/articles/2011-09-03_die_sache_mit_dem_netzteil.md +++ /dev/null @@ -1,7 +0,0 @@ -# Die Sache mit dem Netzteil - -Diese Woche hat meinen SheevaPlug das selbe Schicksal getroffen wie viele andere auch – nach dem Urlaub war das Netzteil kaputt. Mit einem externen von [Conrad](http://www.conrad.de/ce/de/product/510820/Dehner-SYS1308-Netzt-fests-5V15W%22%22) geht er jetzt aber wieder einwandfrei. - -{.full} - -Als sehr nützlich, um in der Zeit bis der Plug repariert war wenigstens eine _Netzteil-Kaputt_-Meldung auf der Webseite anzeigen zu können, erwies sich [Staticloud](http://staticloud.com) – ein netter Webservice um statische Webseiten per drag ‘n drop kostenlos in der Amazon-Cloud hosten zu können. Um die Inhalte zugänglich zu halten (Backup habe ich natürlich schon – aber bis jetzt nur als MySQL-Dump, ab jetzt wohl auch das ganze als HTML ) half mir Google – der gesammte Blog hängt praktischerweise dort im Cache. diff --git a/source/00_content/articles/2011-10-01_lighttpd_konfiguration_fuer_symphony.md b/source/00_content/articles/2011-10-01_lighttpd_konfiguration_fuer_symphony.md deleted file mode 100644 index 90fa82e..0000000 --- a/source/00_content/articles/2011-10-01_lighttpd_konfiguration_fuer_symphony.md +++ /dev/null @@ -1,19 +0,0 @@ -# Lighttpd Konfiguration für Symphony - -Da ich die Neuauflage dieser Seite nicht mehr auf Wordpress, sondern auf dem [Symphony CMS](http://http://symphony-cms.com/) aufgebaut habe, aber nicht den Webserver wechseln wollte, musste ich einen Weg finden die Apache URL-Rewrites in Lighttpd nachzubilden. - -Von den im Netz verfügbaren [Beispielen](http://blog.ryara.net/2009/12/05/lighttpd-rewrite-rules-for-symphony-cms/) hat jedoch keines ohne Einschränkungen funktioniert. Aus diesem Grund habe ich auf Basis der oben verlinkten Konfiguration ein funktionierendes Regelwerk geschrieben: - -``` -url.rewrite-once += ( - "^/favicon.ico$" => "$0", - "^/robots.txt$" => "$0", - "^/symphony/(assets|content|lib|template)/.*$" => "$0", - "^/workspace/([^?]*)" => "$0", - "^/symphony(\/(.*\/?))?(.*)\?(.*)$" => "/index.php?symphony-page=$1&mode=administration&$4&$5", - "^/symphony(\/(.*\/?))?$" => "/index.php?symphony-page=$1&mode=administration", - "^/([^?]*/?)(\?(.*))?$" => "/index.php?symphony-page=$1&$3" -) -``` - -Dieses läuft mit der aktuellsten Symphony Version einwandfrei. Zu finden ist die Konfiguration übrigens mit den restlichen Quellen meines neuen Webseiten-Setups auf [Github](https://github.com/KnairdA/blog.kummerlaender.eu). diff --git a/source/00_content/articles/2011-10-02_tarsnap_backups_fuer_paranoide.md b/source/00_content/articles/2011-10-02_tarsnap_backups_fuer_paranoide.md deleted file mode 100644 index d3dca15..0000000 --- a/source/00_content/articles/2011-10-02_tarsnap_backups_fuer_paranoide.md +++ /dev/null @@ -1,34 +0,0 @@ -# Tarsnap - Backups für Paranoide - -Für meine Backups nutze ich jetzt seit einiger Zeit den Online-Service [Tarsnap](http://www.tarsnap.com/). Dabei handelt es sich um einen Client der es ermöglicht verschlüsselte Backups in der Amazon-Cloud zu speichern und zu verwalten. - -Das ganze ist so aufgebaut, dass immer nur veränderte und neue Dateien übertragen werden müssen. Alle Daten werden schon vom Client verschlüsselt, sodass keine unverschlüsselten Daten übers Netzwerk fließen und weder die Entwickler von Tarsnap noch Amazon den Inhalt der Daten auslesen können. - -Der Service ist nicht kostenlos, aber sehr günstig - der Preis pro Byte Speicher / Datenverkehr beträgt 300 Picodollar, ein Gigabyte kostet also pro Monat nur 0,30 Dollar. - -Der Tarsnap-Client ist im Quellcode verfügbar (aber nicht unter einer Open Source Lizenz) und lässt sich problemlos auch auf ARM Prozessoren kompilieren, sodass ich auch vom N900 und SheevaPlug aus Zugriff auf meine Backups haben kann. Die Authentifizierung mit dem Server funktioniert über einen Schlüssel, der sich nach Eingabe des Passworts mit folgendem Befehl generieren lässt: - -```sh -tarsnap-keygen --keyfile [pfad-zum-schlüssel] --user [email] --machine [hostname] -``` - -Die resultierende Datei ermöglicht ohne zusätzliche Authentifizierung Zugriff auf die Backups und sollte somit sicher aufbewahrt werden und nicht in falsche Hände geraten, denn ohne sie hat man keinen Zugriff mehr auf seine Daten. - -Ein neues Backup lässt sich über diesen Befehl anlegen: - -```sh -tarsnap -c -f [name-des-backups] [zu-sichernder-pfad] -``` - -Jedes weitere Backup geht danach um einiges schneller weil Tarsnap nur veränderte Daten überträgt. Standardmäßig wird dieser Cache unter "/usr/local/tarsnap-cache" und der Schlüssel unter "/root/tarsnap.key" erwartet, dies lässt sich jedoch über entsprechende Parameter steuern - näheres dazu findet sich auf der [Manpage](http://www.tarsnap.com/man-tarsnap.1.html). - -Sollte man dann einmal in die nicht wünschenswerte Situation kommen Zugriff auf sein Backup zu benötigen, reicht dieser Befehl um die Daten wiederherzustellen: - -```sh -tarsnap -x -f [name-des-backups] [wiederherzustellender-pfad] -``` - -Tarsnap kann ich wirklich empfehlen, es hat mich vom [Konzept](http://www.tarsnap.com/design.html) und der Umsetzung her voll überzeugt und ist auf jeden Fall eine ernst zunehmende Alternative zu anderen Backuplösungen in der _Wolke_. - -Der Tarsnap Client ist direkt aus den ArchLinux Repositories verfügbar: [tarsnap](http://www.archlinux.org/packages/community/i686/tarsnap/) - diff --git a/source/00_content/articles/2011-10-16_kurztipp_n900_retten_ohne_neu_zu_flashen.md b/source/00_content/articles/2011-10-16_kurztipp_n900_retten_ohne_neu_zu_flashen.md deleted file mode 100644 index 4084d69..0000000 --- a/ |