aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--articles/2010-02-06_debian_auf_dem_sheevaplug.md59
-rw-r--r--articles/2010-02-24_traffic_ueberwachung_mit_vnstat.md10
-rw-r--r--articles/2010-03-16_erfahrungen_mit_dem_sheevaplug_im_laengeren_einsatz.md22
-rw-r--r--articles/2010-07-12_ocr_und_automatische_uebersetzung_mit_dem_n900.md17
-rw-r--r--articles/2010-12-09_plugbox_linux_ein_archlinux_port_fuer_den_sheevaplug.md12
-rw-r--r--articles/2011-03-31_sheevaplug_ueberwachung.md89
-rw-r--r--articles/2011-09-03_die_sache_mit_dem_netzteil.md7
-rw-r--r--articles/2011-10-02_tarsnap_backups_fuer_paranoide.md34
-rw-r--r--articles/2011-10-16_kurztipp_n900_retten_ohne_neu_zu_flashen.md14
-rw-r--r--articles/2011-11-08_informationen_umformen_mit_xsl.md140
-rw-r--r--articles/2012-01-25_erfahrungen_mit_openslides.md48
-rw-r--r--articles/2013-12-21_musikalischer_jahresruekblick_2013.md49
-rw-r--r--articles/2014-09-13_lessons_learned_in_five_years_of_self_hosting.md3
l---------tags/development/2011-03-31_sheevaplug_ueberwachung.md1
l---------tags/development/2011-11-08_informationen_umformen_mit_xsl.md1
l---------tags/german/2010-02-06_debian_auf_dem_sheevaplug.md1
l---------tags/german/2010-02-24_traffic_ueberwachung_mit_vnstat.md1
l---------tags/german/2010-03-16_erfahrungen_mit_dem_sheevaplug_im_laengeren_einsatz.md1
l---------tags/german/2010-07-12_ocr_und_automatische_uebersetzung_mit_dem_n900.md1
l---------tags/german/2010-12-09_plugbox_linux_ein_archlinux_port_fuer_den_sheevaplug.md1
l---------tags/german/2011-03-31_sheevaplug_ueberwachung.md1
l---------tags/german/2011-09-03_die_sache_mit_dem_netzteil.md1
l---------tags/german/2011-10-02_tarsnap_backups_fuer_paranoide.md1
l---------tags/german/2011-10-16_kurztipp_n900_retten_ohne_neu_zu_flashen.md1
l---------tags/german/2011-11-08_informationen_umformen_mit_xsl.md1
l---------tags/german/2012-01-25_erfahrungen_mit_openslides.md1
l---------tags/german/2013-12-21_musikalischer_jahresruekblick_2013.md1
l---------tags/linux/2010-02-06_debian_auf_dem_sheevaplug.md1
l---------tags/linux/2010-02-24_traffic_ueberwachung_mit_vnstat.md1
l---------tags/linux/2010-03-16_erfahrungen_mit_dem_sheevaplug_im_laengeren_einsatz.md1
l---------tags/linux/2010-07-12_ocr_und_automatische_uebersetzung_mit_dem_n900.md1
l---------tags/linux/2010-12-09_plugbox_linux_ein_archlinux_port_fuer_den_sheevaplug.md1
l---------tags/linux/2011-10-16_kurztipp_n900_retten_ohne_neu_zu_flashen.md1
l---------tags/network/2010-02-24_traffic_ueberwachung_mit_vnstat.md1
l---------tags/opinion/2013-12-21_musikalischer_jahresruekblick_2013.md1
l---------tags/sheevaplug/2010-02-06_debian_auf_dem_sheevaplug.md1
l---------tags/sheevaplug/2010-03-16_erfahrungen_mit_dem_sheevaplug_im_laengeren_einsatz.md1
l---------tags/sheevaplug/2010-12-09_plugbox_linux_ein_archlinux_port_fuer_den_sheevaplug.md1
l---------tags/sheevaplug/2011-03-31_sheevaplug_ueberwachung.md1
l---------tags/sheevaplug/2011-09-03_die_sache_mit_dem_netzteil.md1
l---------tags/sheevaplug/2014-09-13_lessons_learned_in_five_years_of_self_hosting.md1
41 files changed, 1 insertions, 531 deletions
diff --git a/articles/2010-02-06_debian_auf_dem_sheevaplug.md b/articles/2010-02-06_debian_auf_dem_sheevaplug.md
deleted file mode 100644
index fb82abb..0000000
--- a/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/articles/2010-02-24_traffic_ueberwachung_mit_vnstat.md b/articles/2010-02-24_traffic_ueberwachung_mit_vnstat.md
deleted file mode 100644
index 9178cab..0000000
--- a/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.
-
-![vnStat](https://static.kummerlaender.eu/media/vnstat.jpg){.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/articles/2010-03-16_erfahrungen_mit_dem_sheevaplug_im_laengeren_einsatz.md b/articles/2010-03-16_erfahrungen_mit_dem_sheevaplug_im_laengeren_einsatz.md
deleted file mode 100644
index 2e2369e..0000000
--- a/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/articles/2010-07-12_ocr_und_automatische_uebersetzung_mit_dem_n900.md b/articles/2010-07-12_ocr_und_automatische_uebersetzung_mit_dem_n900.md
deleted file mode 100644
index 7ccc7ec..0000000
--- a/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.
-
-![PhotoTranslator - Start](https://static.kummerlaender.eu/media/n900_photo_translator1.jpg){.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.
-
-![PhotoTranslator - Textauswahl](https://static.kummerlaender.eu/media/n900_photo_translator2.jpg){.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.
-
-![PhotoTranslator - Übersetzung](https://static.kummerlaender.eu/media/n900_photo_translator3.jpg){.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/articles/2010-12-09_plugbox_linux_ein_archlinux_port_fuer_den_sheevaplug.md b/articles/2010-12-09_plugbox_linux_ein_archlinux_port_fuer_den_sheevaplug.md
deleted file mode 100644
index 56d992f..0000000
--- a/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/articles/2011-03-31_sheevaplug_ueberwachung.md b/articles/2011-03-31_sheevaplug_ueberwachung.md
deleted file mode 100644
index 311f34c..0000000
--- a/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:
-
-![Zwei Conky-Instanzen unter XFCE](https://static.kummerlaender.eu/media/remote_conky.jpg){.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:
-
-![CPU Plot](https://static.kummerlaender.eu/media/cpu_plot.jpg){.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/articles/2011-09-03_die_sache_mit_dem_netzteil.md b/articles/2011-09-03_die_sache_mit_dem_netzteil.md
deleted file mode 100644
index 4da8fdb..0000000
--- a/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.
-
-![Der reparierte SheevaPlug](https://static.kummerlaender.eu/media/sheevaplug_repair.jpg){.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/articles/2011-10-02_tarsnap_backups_fuer_paranoide.md b/articles/2011-10-02_tarsnap_backups_fuer_paranoide.md
deleted file mode 100644
index d3dca15..0000000
--- a/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/articles/2011-10-16_kurztipp_n900_retten_ohne_neu_zu_flashen.md b/articles/2011-10-16_kurztipp_n900_retten_ohne_neu_zu_flashen.md
deleted file mode 100644
index 4084d69..0000000
--- a/articles/2011-10-16_kurztipp_n900_retten_ohne_neu_zu_flashen.md
+++ /dev/null
@@ -1,14 +0,0 @@
-# Kurztipp: N900 retten ohne neu zu flashen
-
-Letztens habe ich es beim herumexperimentieren mit dem [Speed- und Batterypatch](http://talk.maemo.org/showthread.php?t=73315) für das N900 geschafft einen endlosen Reboot zu erzeugen.
-Ich wusste, dass ich zum Korrigieren des Problems nur einen Wert in der Konfiguration des Batterypatch anpassen musste - konnte jedoch aufgrund des andauernden Neustartens nicht auf das rootfs zugreifen.
-
-Erst sah es so aus, als würde ich nicht darum herum kommen das Betriebsystem neu zu flashen und den Großteil meiner Einstellungen neu zu setzen, doch dann stieß ich auf das N900 [rescueOS](http://n900.quitesimple.org/rescueOS/).
-
-Dabei handelt es sich um ein kleines Linux welches mithilfe des normalen [Flashers](http://tablets-dev.nokia.com/maemo-dev-env-downloads.php) direkt in den RAM des N900 kopiert und dort gebootet werden kann. Vom rescueOS aus kann man dann das Root-Dateisystem problemlos einbinden und Probleme beheben. Zum Starten reicht das [initrd Image](http://n900.quitesimple.org/rescueOS/rescueOS-1.0.img) und folgender Befehl:
-
-```sh
-flasher-3.5 -k 2.6.37 -n initrd.img -l -b"rootdelay root=/dev/ram0"
-```
-
-Nähere Informationen zur Verwendung und den Funktionen finden sich in der rescueOS [Dokumentation](http://n900.quitesimple.org/rescueOS/documentation.txt).
diff --git a/articles/2011-11-08_informationen_umformen_mit_xsl.md b/articles/2011-11-08_informationen_umformen_mit_xsl.md
deleted file mode 100644
index f84f17c..0000000
--- a/articles/2011-11-08_informationen_umformen_mit_xsl.md
+++ /dev/null
@@ -1,140 +0,0 @@
-# Informationen umformen mit XSL
-
-Im Rahmen meiner Vorstandstätigkeit beim KV Konstanz der Piratenpartei betreue ich die Webseite [piraten-konstanz.de](http://piraten-konstanz.de)
-
-Unsere Termine organisieren wir üblicherweise im [Wiki](http://wiki.piratenpartei.de/Kreisverband_Konstanz) - seit der Einführung der neuen KV Seite auf Basis von Wordpress müssen wir diese Termine doppelt pflegen. Da dies kein Zustand ist welcher mir auf Dauer gefällt, habe ich nach Möglichkeiten zum Auslesen der Terminliste im Wiki und dem anschließenden Darstellen in Wordpress gesucht.
-
-Schlussendlich habe ich dann eine [XSLT](http://de.wikipedia.org/wiki/XSLT) geschrieben und rufe diese von einem einfachen [PHP-Script](http://piraten-konstanz.de/wp-content/tool/events_rss.php) auf.
-
-Mit XSL lassen sich XML Dateien in andere Formen bringen. Da Mediawiki mehr oder weniger valides XHTML ausgibt, kann man, nachdem das XHTML mit [Tidy](http://tidy.sourceforge.net) ein wenig aufgeräumt wurde, sehr einfach die [Terminliste](http://wiki.piratenpartei.de/BW:Kreisverband_Konstanz/Termine) extrahieren und gleichzeitig in RSS umformen:
-
-```xsl
-<xsl:stylesheet version="1.0"
- xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
- xmlns:x="http://www.w3.org/1999/xhtml"
- exclude-result-prefixes="x">
-
-<xsl:import href="date-time.xsl"/>
-
-<xsl:output method="xml"
- doctype-public="-//W3C//DTD XHTML 1.0 Strict//EN"
- doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"
- omit-xml-declaration="yes"
- encoding="UTF-8"
- indent="no" />
-
-<xsl:template match="/">
- <rss version="2.0">
- <channel>
- <title>Termine des KV Konstanz</title>
- <link>http://wiki.piratenpartei.de/BW:Kreisverband_Konstanz/Termine</link>
- <description>Termine des KV Konstanz</description>
- <xsl:apply-templates/>
- </channel>
- </rss>
-</xsl:template>
-
-<xsl:template match="x:div[@id='pkn_main']/x:table/x:tr[position() &gt; 1]">
- <item>
- <title>
- <xsl:value-of select="x:td[3]"/>
- <xsl:text> am </xsl:text>
- <xsl:call-template name="format-date">
- <xsl:with-param name="date" select="x:td[1]/x:span/."/>
- <xsl:with-param name="format" select="'d.n.Y'"/>
- </xsl:call-template>
- <xsl:text> um </xsl:text>
- <xsl:value-of select="x:td[2]"/>
- <xsl:text> Uhr</xsl:text>
- </title>
- <link>
- <xsl:text>http://wiki.piratenpartei.de</xsl:text>
- <xsl:value-of select="x:td[3]/x:a/@href"/>
- </link>
- </item>
-</xsl:template>
-
-<xsl:template match="text()"/>
-
-</xsl:stylesheet>
-```
-
-Der Kern dieses XSL ist nicht mehr als ein Template welches auf den [XPATH](http://de.wikipedia.org/wiki/XPATH) zum Finden der Terminliste reagiert. Die For-Each-Schleife iteriert dann durch die Termine und formt diese entsprechend in RSS um.
-Der einzige Knackpunkt kommt daher, dass XHTML kein normales XML ist und somit seinen eigenen Namespace hat. Diesen sollte man im Element `xsl:stylesheet` korrekt angeben, sonst funktioniert nichts. Auch muss im XPATH Ausdruck dann vor jedem Element ein `x:` eingefügt werden um dem XSL Prozessor den Namespace für das jeweilige Element mitzuteilen.
-
-Das leere Template `xsl:template match="text()"` sorgt dafür, dass alle XML-Zweige, die nicht auf ein anderes Template passen, nicht ausgegeben werden.
-`xsl:template match="/"` springt auf das Root-Element der XHTML-Seite an, bildet die RSS Grundstruktur und bindet dann alle anderen Templates ein.
-
-Zum Anpassen des Datums verwende ich - wie auch in diesem Blog - die [date-time.xsl](http://symphony-cms.com/download/xslt-utilities/view/20506/) Transformation.
-
-## Generieren des RSS Feed
-
-Mit der eben beschriebenen XSLT lässt sich jetzt in drei Schritten das fertige RSS generieren:
-
-```sh
-#!/bin/sh
-wget -O termine_wiki.html "http://wiki.piratenpartei.de/BW:Kreisverband_Konstanz/Termine"
-tidy -asxml -asxhtml -O termine_tidy.html termine_wiki.html
-xsltproc --output termine_kvkn.rss --novalid termine_kvkn.xsl termine_tidy.html
-```
-
-In PHP ist das ganze dann zusammen mit sehr einfachem Caching auch direkt auf einem Webserver einsetzbar:
-
-```php
-define('CACHE_TIME', 6);
-define('CACHE_FILE', 'rss.cache');
-
-header("Content-Type: application/rss+xml");
-
-if ( file_exists(CACHE_FILE) )
-{
- if ( !filemtime(CACHE_FILE) < time() - CACHE_TIME * 3600 ) {
- readfile(CACHE_FILE);
- }
- else {
- if ( !generate_rss() ) {
- readfile(CACHE_FILE);
- }
- }
-}
-else {
- ob_start();
-
- generate_rss();
-
- ob_end_flush();
-
- $cache_file = fopen(CACHE_FILE, 'w');
- fwrite($cache_file, ob_get_contents());
- fclose($cache_file);
-}
-
-function generate_rss()
-{
- $even