diff options
Imported another batch of articles from my blog
* this should be the last one, as the remaining articles are not really worth preserving
** at least that is my current assessment
* updated contact page with actual content instead of filler text
Diffstat (limited to 'source/00_content/articles')
6 files changed, 139 insertions, 0 deletions
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 new file mode 100644 index 0000000..9f81703 --- /dev/null +++ b/source/00_content/articles/2010-02-24_traffic_ueberwachung_mit_vnstat.md @@ -0,0 +1,10 @@ +# 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. + +<a href="http://imgur.com/kUgwU"><img src="http://i.imgur.com/kUgwUl.jpg" alt="vnStat" class="full" /></a> + +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-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 new file mode 100644 index 0000000..15f8fca --- /dev/null +++ b/source/00_content/articles/2010-12-09_plugbox_linux_ein_archlinux_port_fuer_den_sheevaplug.md @@ -0,0 +1,12 @@ +# 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 new file mode 100644 index 0000000..74dfa88 --- /dev/null +++ b/source/00_content/articles/2011-03-31_sheevaplug_ueberwachung.md @@ -0,0 +1,81 @@ +# 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: + +<a href="http://imgur.com/2JuGZl"><img alt="Zwei Conky-Instanzen unter XFCE" src="http://i.imgur.com/2JuGZl.jpg" title="Zwei Conky-Instanzen unter XFCE" width="354" height="268" class="full" /></a> + +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: + + 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. + + #!/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: + + #!/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: + + #!/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: + +<a href="http://imgur.com/tHGcG"><img alt="CPU-Graph" class="clear full" src="http://i.imgur.com/tHGcGl.jpg" title="CPU-Graph" /></a> + +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-09-03_die_sache_mit_dem_netzteil.md b/source/00_content/articles/2011-09-03_die_sache_mit_dem_netzteil.md new file mode 100644 index 0000000..6b2fa47 --- /dev/null +++ b/source/00_content/articles/2011-09-03_die_sache_mit_dem_netzteil.md @@ -0,0 +1,7 @@ +# 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. + +<a href="http://i.imgur.com/K99pU"><img alt="Der reparierte SheevaPlug" src="http://i.imgur.com/K99pUl.jpg" title="Der reparierte SheevaPlug" class="full"/></a> + +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 new file mode 100644 index 0000000..fade6af --- /dev/null +++ b/source/00_content/articles/2011-10-01_lighttpd_konfiguration_fuer_symphony.md @@ -0,0 +1,17 @@ +# 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-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 new file mode 100644 index 0000000..65fc7e7 --- /dev/null +++ b/source/00_content/articles/2011-10-16_kurztipp_n900_retten_ohne_neu_zu_flashen.md @@ -0,0 +1,12 @@ +# 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: + + 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). |