Raspi-Webzugriff ohne extra Serverinstallation

Wenn man einen Raspberry-Pi remote betreibt, dann bleibt für die Interaktion nicht viel mehr übrig, als die Remote-Shell, ein Web-Frontend oder das Umleiten des X-Servers auf die Host-Maschine. In diesem Beitrag will ich mich auf die zweite Variante konzentrieren und aufzeigen, wie das sehr schnell ohne Installation eines eigenen Webservers, wie den Apache oder Nginx, geht.
Das Setup, welches ich gewählt habe, ist CherryPy, weil mit diesem Framework ein Web-Server mitkommt und außerdem mit der Raspberry-Pi Haus- und Hof-Programmiersprache Python gefüttert wird.
Bei meinen Programmierausflügen mit Python versuche ich immer auf die 3er Version von Python zu setzen, weswegen ich hier auch die Anleitung dafür auslege.
Als erstes muss man sich den Python Package Manager PIP installieren, um damit dann CherryPy zu installieren – das alles habe ich bereits in meinem Artikel PIP für Python 3.x unter Linux installieren beschrieben.
Als nächsten Schritt legt man am besten ein cherryPy-Verzeichnis an und speichert darin die cherryPy-Scripte. Hier darf natürlich das obligatorische Hello-World nicht fehlen. Auf der CherryPy-Seite ist dieses auch gleich an erster Stelle platziert. Ist man mit der graphischen Oberfläche direkt auf dem RasPi unterwegs so funktioniert das auf Anhieb, aber in meinem Fall soll der Zugriff ja remote innerhalb des Hausnetzwerkes erfolgen. Dazu muss das Script noch etwas angepasst werden und zusätzlich noch eine Konfigurationsdatei angelegt werden. Man könnte zwar die Konfiguration auch noch mit in das Python-Script packen, aber wir wollen bei unseren Experimenten ja nicht jedes Mal die selbe Konfiguration mit in das Script packen – das Angeben einer externen Konfigurationsdatei ist hier wohl deutlich komfortabler.
So habe ich das helloWorld-Beispiel folgendermaßen abgewandelt

#!/usr/bin/python3

import cherrypy

class HelloWorld(object):
    def index(self):
        return "Hello World!"
    index.exposed = True

if __name__ == '__main__':
	cherrypy.quickstart(HelloWorld(), config="cherryPy.conf")

und die dazugehörige Konfigurationsdatei cherryPy.conf wie folgt aufgebaut:

[global]
server.socket_host = "192.168.10.17"
server.socket_port = 8080
server.thread_pool = 10

Startet man nun das Script mit python3 cpHelloWorld.py, so sieht man wie der Server aufgesetzt wird.

pi@raspberrypi ~/cherryPy $ python3 cpHelloWorld.py 
[04/Apr/2015:09:52:37] ENGINE Listening for SIGHUP.
[04/Apr/2015:09:52:37] ENGINE Listening for SIGTERM.
[04/Apr/2015:09:52:37] ENGINE Listening for SIGUSR1.
[04/Apr/2015:09:52:37] ENGINE Bus STARTING
[04/Apr/2015:09:52:37] ENGINE Started monitor thread 'Autoreloader'.
[04/Apr/2015:09:52:37] ENGINE Started monitor thread '_TimeoutMonitor'.
[04/Apr/2015:09:52:37] ENGINE Serving on http://192.168.10.17:8080
[04/Apr/2015:09:52:37] ENGINE Bus STARTED

Die Hello-World Seite kann nun von jeder beliebigen Maschine im Netz unter der angegebenen IP-Adresse aufgerufen werden:
cherryPyHelloWorld
Und das tolle an diesem Setup ist, dass das Script nach einer Änderung nicht jedes Mal neu gestartet werden muss, sondern das Framework eine Modifikation der Datei automatisch erkennt und diese neu ausliefert.
Einfach mal ausprobieren und im Script aus „Hello World“ ein „Hello Raspi-World“ machen und die Datei abspeichern. Die Konsolenausgabe zeigt an, dass die Änderung erkannt wurde:

[04/Apr/2015:12:21:55] ENGINE Restarting because /home/pi/cherryPy/cpHelloWorld.py changed.
[04/Apr/2015:12:21:55] ENGINE Stopped thread 'Autoreloader'.
[04/Apr/2015:12:21:55] ENGINE Bus STOPPING
[04/Apr/2015:12:21:55] ENGINE HTTP Server cherrypy._cpwsgi_server.CPWSGIServer(('192.168.10.17',8080)) shut down
[04/Apr/2015:12:21:55] ENGINE Stopped thread '_TimeoutMonitor'.
[04/Apr/2015:12:21:55] ENGINE Bus STOPPED
[04/Apr/2015:12:21:55] ENGINE Bus EXITING
[04/Apr/2015:12:21:55] ENGINE Bus EXITED
[04/Apr/2015:12:21:55] ENGINE Waiting for child threads to terminate...
[04/Apr/2015:12:21:55] ENGINE Re-spawning cpHelloWorld.py
[04/Apr/2015:12:21:58] ENGINE Listening for SIGHUP.
[04/Apr/2015:12:21:58] ENGINE Listening for SIGTERM.
[04/Apr/2015:12:21:58] ENGINE Listening for SIGUSR1.
[04/Apr/2015:12:21:58] ENGINE Bus STARTING
[04/Apr/2015:12:21:58] ENGINE Started monitor thread 'Autoreloader'.
[04/Apr/2015:12:21:58] ENGINE Started monitor thread '_TimeoutMonitor'.
[04/Apr/2015:12:21:59] ENGINE Serving on http://192.168.150.175:8080
[04/Apr/2015:12:21:59] ENGINE Bus STARTED

Nun gilt es nur noch im Browser einen Reload zu veranlassen und siehe da, schon erscheint die Änderung im Browser.
cherryPy_helloRaspiWorld
Nun lässt sich das Script beliebig erweitern. Dazu rate ich die Tutorials der cherryPy-Dokumentation genauer zu studieren – evtl. gibt es ja auch noch einen weiteren Beitrag zu diesem Thema. Mal schauen, was die Zeit bringt.
Noch viel Spaß beim Ausprobieren!

Von Linux aus bequem auf Raspi-Dateien remote zugreifen

wer so wie ich mehrere Raspberry-Pis im Einsatz hat, auf diese vornehmlich remote zugreift und daran auch noch Daten produzierende Sensoren hat, der wird sich wohl auch schon das ein oder andere Mal gewünscht haben, bequem auf diese Dateien zugreifen zu können. Ich habe für mich die Lösung mittels SSH-Filesystem gefunden. Dazu muss auf dem Raspberry-Pi SSH aktiviert sein – das kann man über raspi-config erledigen:
sudo raspi-config
Unter dem Menüpunkt 8 Advanced Options befindet sich der Untermenüpunkt A4 SSH, der erlaubt SSH einzuschalten – enable.
raspiconfig-main

raspiconfig-advanced

raspiconfig-ssh

Nach diesem Schritt kann man sich remote über sein Netzwerk auf dem Raspberry-Pi einloggen und diesen damit headless betreiben. Unter Windows geht das z.B. über Putty, unter Linux über das Terminal – nämlich mit dem Kommando:
ssh pi@<ip-adresse/alias> z.B. ssh pi@192.168.10.12
Was nun aber zu nerven beginnt, ist das Eingeben des Passwortes, sobald man sich über SSH auf dem Raspi einlogged. Aber dafür gibt es auch Abhilfe.
Wenn man auf dem Rechner,von dem aus man sich auf dem Raspi einloggen will noch kein SSH-Schlüsselpaar liegen hat, so muss man sich erst mal ein neues SSH-Schlüsselpaar erzeugen.
Ob bereits ein Schlüsselpaar vorhanden ist, kann man einfach überprüfen, indem man sein home-Verzeichnis nach einem .ssh Unterverzeichnis durchsucht.
cd ~
ls -a | grep ssh
Ist das Verzeichnis vorhanden, so sollten sich mindestens folgende Dateien darin befinden (ls .ssh):
id_rsa id_rsa.pub
Ist das nicht der Fall, so kann man gleich ein neues Schlüsselpaar erzeugen:
ssh-keygen -t rsa
Bei der Aufforderung zur Eingabe des Speicherortes und des Passworts einfach Return drücken. Ich habe das mal auf einem frisch aufgesetzten Raspi nachvollzogen:
raspi-ssh-keygen
Und nun gilt es, den public-key (id_rsa.pub) auf den Zielrechner zu bekommen. Und hier kommt bereits das SSHFS zum Einsatz. Ist es noch nicht auf dem Host-Rechner installiert, so kann das ganz einfach über sudo apt-get install sshfs erledigt werden. Nun gilt es noch das Mount-Verzeichnis auf der Host-Seite einzurichten, was der Befehl mkdir <Zielverzeichnis> für uns erledigt. Wer so wie ich mehrere Raspberry-Pis sein Eigen nennt, dem empfehle ich zunächst ein Unterverzeichnis für die Raspberries anzulegen und darunter jedem Raspi sein eigenes Mount-Verzeichnis einzurichten:
mkdir ~/raspberry && cd ~/raspberry
mkdir pi_1 pi_2 pi_n
Nun steht dem SSHFS-Mount nichts mehr im Wege.
sshfs pi@<ip-adresse>:/home/pi ~/raspberry/pi_1
In diesem Fall wird nochmals das Passwort abgefragt, aber mit nachfolgenden Schritten kann das abgestellt werden.
Wenn auf dem Remote-Pi bereits ein .ssh-Verzeichnis im Home-Verzeichnis besteht und in diesem Verzeichnis bereits eine Datei namens authorized_keys liegt, so kann man den neuen Key über folgendes Kommando dazu fügen:
cat ~/.ssh/id_rsa.pub >> ~/raspberry/pi_1/.ssh/authorized_keys
Sollte das .ssh-Verzeichnis im Home-Verzeichnis des „remote-Raspi“ noch nicht existieren, so muss es angelegt werden:
mkdir ~/raspberry/pi_1/.ssh
um anschließend den Public-Key zu kopieren:
cp ~/.ssh/id_rsa.pub ~/raspberry/pi_1/.ssh/authorized_keys
Nun kann der Mount-Point über das Kommando
fusermount -u ~/raspberry/pi_1
ausgehängt werden, um ihn anschließend ohne Angabe des Passwortes wieder einhängen zu können:
sshfs pi@<ip-adresse>:/home/pi ~/raspberry/pi_1
Ich muss wohl kaum erwähnen, dass nun auch bequem über den Dateimanager auf die Files des „remote-Raspies“ zugegriffen werden kann.
Und als kleines Schmankerl kommt nachfolgend noch ein Bash-Script, welches erlaubt, auf einen Rutsch gleich mehrere Raspies zu mounten:

#!/bin/bash

piIpBase=192.168.10.
piIpList="1 2 5"

for piName in $piIpList; do
    ping -c 1 -q $piIpBase$piName
    echo "ping-result: $?"
    if [ $? -eq 0 ]; then
        echo "$piIpBase$piName available - try to mount it."
        sshfs pi@$piIpBase$piName:/home/pi ~/raspberry/pi$piName/
    else
        echo "$piIpBase$piName NOT available!"
    fi
done

Obigen Text einfach in eine Datei speichern (z.B. mount_pi.sh) und nicht vergessen, diese dann ausführbar zu machen:
chmod +x mount_pi.sh
So lassen sich über den Aufruf von mount_pi.sh gleich mehrere (in obigem Fall: drei) RaspberryPies auf einen Rutsch in sein lokales File-System einhängen – vorausgesetzt man hat nicht vergessen die Mount-Verzeichnisse dafür anzulegen.

Auf der Github-Hilfeseite ist auch noch gut beschrieben, wie man sich einen SSH-Key erzeugen kann.

PIP für Python 3.x unter Linux installieren

Jetzt bin ich schon zum dritten Mal über die Notwendigkeit gestolpert, den python package-manager pip für Python 3.x zu installieren und habe jedes Mal danach im Internet suchen müssen – nein, nicht googeln, sondern suchen mit DuckDuckGo.
Nachdem meine Linux-Maschinen alle auf Debian basieren, reicht mir die Installation via Debian Package Manager => Advanced Package Tool (APT).
Es genügt dafür folgende Eingabe auf der Kommandozeile:
sudo apt-get install python3-pip
Danach kann man dann Module für Python 3.x installieren indem man folgende Befehlssyntax verwendet:
sudo pip-3.2 install cherrypy
Bei meiner Installation (auf dem Raspberry-Pi mit Raspbian) waren noch folgende Alternativen möglich:
pip pip-2.6 pip-2.7 pip-3.2
Zumindest weiß ich jetzt beim nächsten mal, wo ich ohne Suchen nachschauen kann und hoffe, dass dieser kurze Artikel vielleicht dem Einen und/oder der Anderen dort draußen in den Weiten des Internet auch hilfreich ist.

webcam/USB-Mikroskop unter Linux nutzen

Es ist noch gar nicht so lange her, da habe ich mir/uns ein USB-Mikroskop geleistet, um z.B.

  • ganz kleine Schrift entziffern zu können, wie sie z.B. auf Uhren-Batterien zu finden ist
  • den Kindern den Mikrokosmos etwas erschließen zu können

Nachdem ich aber mittlerweile auf meinen Privat-Rechnern kein Windows-Betriebssystem mehr im Einsatz habe, sondern Linux/OSX, konnte ich die mitgelieferte Software nicht mehr verwenden.
Ich hatte nun aktuell die Notwendigkeit, das Mikroskop zur Entzifferung des Typs einer Armbanduhrenbatterie zu verwenden und war deswegen auf der Suche nach geeigneter Linux-Software. Ich musste nicht lange recherchieren um zwei Kandidaten zu finden, die mir beide zumindest ermöglichten, das Bild auf den Desktop zu bekommen. Auf die Remote-Steuerung des Fokus kann ich gerne verzichten – das geht auch gut über die Tasten am Mikroskop. Die besagten Programme wären:

Beide Programme konnte ich problemlos über den Synaptik Paketmanager einspielen.

Lubuntu auf Cubietruck installieren

Ich habe schon seit längerem mir ein Cubietruck-Board zugelegt.

Nun habe ich mir endlich die Zeit genommen, das im Flash liegende Android durch ein Lubuntu zu ersetzen. Dabei hat mir folgende Anleitung geholfen:
http://dyhr.com/2013/11/22/how-to-install-lubuntu-server-on-cubietruck-from-mac-os-x/
bzw.
http://docs.cubieboard.org/tutorials/ct1/installation/cb3_lubuntu-12.10-desktop_nand_installation_v1.00

Nach der Installation hatte ich noch das Problem, dass mein Keyboard-Layout auf US eingestellt war. Abhilfe schafft der Aufruf von:

# dpkg-reconfigure console-setup

Kaum hatte ich alles soweit am Laufen, wollte ich dem System ein update/upgrade gönnen und gab den Befehl dazu:

# sudo apt-get install update

Leider war die Aktion nicht mit dem Erfolg gekrönt. Statt einem satten Update teilte mir der Rechner mit, dass einige Update URLs nicht erreichbar wären:

Hit http://ppa.launchpad.net raring Release.gpg
Ign http://ports.ubuntu.com raring Release.gpg
Hit http://ppa.launchpad.net raring Release
Ign http://ports.ubuntu.com raring Release
Ign http://ports.ubuntu.com raring/main Sources/DiffIndex
Hit http://ppa.launchpad.net raring/main Sources
Ign http://ports.ubuntu.com raring/universe Sources/DiffIndex
Hit http://ppa.launchpad.net raring/main armhf Packages
Ign http://ports.ubuntu.com raring/main armhf Packages/DiffIndex
Hit http://ppa.launchpad.net raring/main/debug armhf Packages
Ign http://ports.ubuntu.com raring/universe armhf Packages/DiffIndex
Ign http://ppa.launchpad.net raring/main Translation-en
Ign http://ppa.launchpad.net raring/main/debug Translation-en
Ign http://ports.ubuntu.com raring/main Translation-en
Ign http://ports.ubuntu.com raring/universe Translation-en
Err http://ports.ubuntu.com raring/main Sources
404 Not Found [IP: 91.189.88.140 80]
Err http://ports.ubuntu.com raring/universe Sources
404 Not Found [IP: 91.189.88.140 80]
Err http://ports.ubuntu.com raring/main armhf Packages
404 Not Found [IP: 91.189.88.140 80]
Err http://ports.ubuntu.com raring/universe armhf Packages
404 Not Found [IP: 91.189.88.140 80]
W: Failed to fetch http://ports.ubuntu.com/ubuntu-ports/dists/raring/main/source/Sources 404 Not Found [IP: 91.189.88.140 80]

W: Failed to fetch http://ports.ubuntu.com/ubuntu-ports/dists/raring/universe/source/Sources 404 Not Found [IP: 91.189.88.140 80]

W: Failed to fetch http://ports.ubuntu.com/ubuntu-ports/dists/raring/main/binary-armhf/Packages 404 Not Found [IP: 91.189.88.140 80]

W: Failed to fetch http://ports.ubuntu.com/ubuntu-ports/dists/raring/universe/binary-armhf/Packages 404 Not Found [IP: 91.189.88.140 80]

E: Some index files failed to download. They have been ignored, or old ones used instead.

Eine Blick in die Versionstabelle der Ubuntu Releases unter Wikipedia zeigte, dass für die Raring-Ringteil Version 13.04 der Support abgelaufen war und deshalb die Packages in den .. verschoben wurden – die 13.04 hat einfach kein LTS = Long-Term-Support. Eine neuere Version für das Cubie-Truck-Nand gibt es leider noch nicht – 14.04 hätte LTS. Und wichtig – man sollte sich hüten, eine nicht NAND-Version ins Nand-Flash zu überspielen!
Es gibt Leute, die biegen die URLs für APT um, um die Fehlermeldungen zu umgehen. Dabei Frage ich mich schon, welchen Sinn das macht, wenn es für diese Pakete keinen Support, also Update, mehr gibt.
Deswegen habe ich mich entschlossen, diese Version im NAND zu lassen, bis es eine NAND-Flash-Version für 14.04 gibt und das OS von SD-Karte zu booten.

sudo dd if=path_of_your_image.img of=/dev/diskn bs=1M

Hardware Informationen unter Linux auslesen

unter Windows kann man ganz einfach mit Hilfe des Programms msinfo32.exe sämtliche Hardware Informationen seines Rechners auslesen und anzeigen lassen. Das geht auch unter Linux. Alles was man dazu braucht ist

inxi

Falls es noch nicht installiert ist, kann das sehr schnell auf der Kommandozeile nachgeholt werden.

sudo apt-get install inxi

Ein Aufruf von

inxi -Fxz

bringt dann z.B. folgende Informationen ans Tageslicht:
inxi_output

  • Die Option „F“ sorgt dafür, dass alle Informationen (Full) ausgegeben werden
  • „x“ soll noch für eXtra Daten sorgen
  • und „z“ soll verhindern, dass Sicherheitsrelevante Daten gezeigt werden – wenn man z.B. seine Hardware-Informationen in einer Newsgroup oder wie ich hier auf einem Blog veröffentlichen will.

Und ja, natürlich gibt es auch ein graphisches Tool, dass sich sehr stark an msinfo32.exe anlehnt. Wer meine Systeminformationen angeschaut hat, der sieht, dass ich KDE benutze. Unter KDE kann man das „kinfocenter“ bemühen. Also einfach „Alt + F2“ drücken und „kinfocenter“ eingeben und schwubs hat man die Hardware-Informationen schön aufbereitet in einem Fensterchen liegen.

kinfocenter

SSHFS: remote Verzeichnise unter Linux mounten

wenn man so wie ich ein paar Raspberry-Pi’s im Netzwerk und an diesen ein paar Sensoren hängen hat, so ist es natürlich interessant, die Werte auch immer wieder mal abfragen bzw. sich die Log-Dateien auf den Geräten ansehen zu können. Eine Möglichkeit wäre sich per sftp die Dateien zu holen oder sich per SSH einzuloggen um die Dateien vor Ort anzusehen. Eine andere und in meinen Augen auch elegantere Methode ist, sich das entsprechende Remote-Verzeichnis per SSHFS in das lokale Filesystem ein zu hängen.
Dazu benötigt man unter Linux das sshfs-Paket, welches man sich auf der Kommandozeile per

sudo apt-get install -y sshfs

installieren kann. Anschließend legt man am besten im eigenen Home-Verzeichnis einen Mount-Point an:

mkdir ~/raspi

Anschließend braucht nur noch über den Befehl

sshfs user@server:dir_remote dir_local

das Remote-Verzeichnis in den zuvor erstellten Mount-Point eingehängt zu werden. Konkret kann das dann folgendermaßen aussehen:

sshfs pi@192.168.13.13:/home/pi ~/raspi

Will man den Mount-Point wieder lösen, so gibt man einfach folgenden Befehl auf der Bash ein:

fusermount -u ~/raspi