Ubuntu - Installation auf USB-Stick

Vor dem Urlaub bestand für mich die Notwendigkeit, Ubuntu (meine favorisierte Linux-Distribution) auf einen USB-Stick zu installieren, da ich nur ein geliehenes Netbook mit hatte, auf das ich kein Ubuntu fix installieren durfte (wollte).

Also musste eine USB-Stick her. Gekauft habe ich einen 16GB Stick von Lexar, wobei ich vorab nicht speziell auf die Schreib- / Lesegeschwindigkeit geachtet habe, sondern nur darauf, dass es eine Marken-Stick ist. Die Installation sollte "echt" sein, also kein Live-System von USB, sondern richtig, wie man auf eine HD halt auch installiert.

Üblicherweise nutzte ich GNOME bzw. seit Natty 11.04 Unity, für den Stick habe ich dann aber Xubuntu gewählt. Grund: 1) wollte ich es nochmal ausprobieren und 2) vielleicht etwas performanter vom Stick als K|Ubuntu. Also flux das Alternate-ISO von Xubuntu 11.04 heruntergeladen, gebrannt, Stick eingesteckt und die CD gestartet.

Die Installation an sich läuft wie auf jedes andere Laufwerk auch. Man sollte halt nur als Ziel den Stick wählen (wenn man eine HD hat wird der Stick i.d.R. als /dev/sdb eingebunden - bei mir jedenfalls) und diesen dann von Hand Partitionieren. Hat man bereits eine Linux-Installation auf der regulären Festplatte, dann will der Installer wahrscheinlich die vorhandene Swap-Partition nutzen. Da man den Stick aber "stand-alone" nutzen will, muss man diese dann händisch abwählen und Swap auf dem Stick anlegen (oder weg lassen, je nach eigenem Geschmack). Außerdem sollte man tunlichst darauf achten, dass der Bootloader ebenfalls auf den Stick geschrieben wird und man sich nicht aus versehen den Bootloader auf der HD abschießt. Der Rest der Installation läuft dann wieder wie gewohnt.

Ein Punkt ist noch anzumerken: Der Bootloader GRUB2 erkannt alle Laufwerke auf dem aktuellen Rechner und fügt diese dem Bootmenü hinzu. Somit stimmt das Bootmenü natürlich nicht, wenn man den USB-Stick auf einem anderen Rechner nutzt. Natürlich kann man Ubuntu auf dem Stick darüber booten, aber halt nicht die anderen Betriebssysteme, welche auf der jeweiligen lokalen HD sind. Wer dies unbedingt braucht muss halt jedes mal GRUB2 aktualisieren und neu booten. Von Ubuntu aus kann man später natürlich auf den Inhalt der lokalen Laufwerke zugreifen.

Nach der Installation ist der Stick bereit und man kann Ubuntu so auf jedem Rechner nutzen, der von einem USB-Stick booten kann. Der Performance fand ich ok, heißt der Bootvorgang ist zügig genug und auch das Arbeiten läuft relativ flüssig. Lediglich wenn man viel I/O hat, d.h. mehrere Programme gleichzeitig startet oder ein Update von Paketen macht wird es ein bisschen langsamer - aber immer noch deutlich schneller als ein Live-System von CD oder DVD.

Python CGI und Templates - die Eleminierung von überflüssigen print-Statements

Zugegebener Maßen ist es vielleicht nicht mehr ganz auf der Höhe der Zeit, über Python und CGI-Programmierung zu schreiben. Schließlich ist WSGI der Stand der Technik und absolut die 1. Wahl bei der Webprogrammierung mit Python.

Nun ist aber auch so, dass das Urgestein CGI noch lange nicht am Ende ist. Das hat wohl mehrere Gründe: So unterstützt quasi jeder Webserver CGI mit Bordmitteln, während WSGI-Unterstützung - so fern überhaupt vorhanden - in der Regel nachträglich installiert und konfiguriert werden muss. Ein weiterer Punkt ist, dass inzwischen zwar relativ viele Anbieter von Homepage-Paketen / Webspace Python unterstützen - aber eben nur für CGI-Skripte. WSGI ist hier die absolute Ausnahme und wirklich rar.

Daher ist es auch nicht so verwunderlich, dass in Python Support-Foren auch immer wieder Fragen zu Thema „Python + CGI“ auftauchen.

Nun, weiter schwierig ist das Thema wirklich nicht. Eine Standardinstallation von Python enthält bereits ein Modul für CGI, Tutorials gibt es haufenweise im Web.

Eine Sache findet man jedoch recht selten: Die Nutzung von Standard-Templates (im Python String-Modul enthalten) in Kombination mit CGI. In vielen CGI Tutorials findet man eher ellenlange print Statements. Gut, zum einen könnte es daran liegen, dass das Templates erst seit Python 2.4 an Bord sind, viele Tutorials sind aber (wahrscheinlich) älter. Durch die Verwendung von Templates wird aber die Programmlogik von der Darstellung / Ausgabe getrennt, was das Programm an sich zum einen wesentlich übersichtlicher macht und zum anderen die Codepflege vereinfacht.

Das Vorgehen dabei ist eigentlich simpel: Man erstellt eine Template-Datei, was nichts anderes als eine „normale“ HTML-Datei ist, die aber die Platzhalter für die spätere Ersetzung enthält. Das CGI-Skript lädt dann diese Datei, generiert ein Dict, welches die Werte für die Substitution enthält und lässt das Template dann am Ende ausgeben.

Das folgende minimalistische Beispiel verdeutlicht dies. Es werden drei Dateien erstellt: die HTML-Datei namens „index.html“, welche das Eingabeformular enthält, das Template „ausgabe.html“ und das CGI-Skript „ausgabe.cgi“.

index.html:

<html>
<head>
<title>Python CGI und Templates</title>
</head>
<body>
<form action="cgi-bin/ausgabe.cgi">
<p>Bitte Namen eingeben: <input type="text" name="name"></p>
<p><input type="submit"></p>
</form>
</body>
</html>

ausgabe.html:

<html>
<head>
<title>Hallo CGI-Welt!</title>
</head>
<body>
<p>Hallo $name!</p>
</body>

ausgabe.cgi:

#!/usr/bin/env python

import cgi
from string import Template

form = cgi.FieldStorage()
name = form['name'].value
ersetzung = {'name': name}
temp = Template(open('ausgabe.html').read())

print 'Content-type: text/html'
print
print temp.substitute(ersetzung)

Letztendlich also nicht anderes als ein reguläres Template, nur halt in einem CGI angewendet.

Natürlich könnte man auch ein „echtes“ Template-Modul wie z.B. Jinja2, Mako oder Genshi einsetzen, sofern man selber Python-Module installieren kann bzw. darf. Für einfache Seiten reichen die Templates aus dem String-Modul aber alle Mal.

Zum Abschluss dann noch der obligatorische Hinweis, dass man dieses Beispiel natürlich nicht 1:1 für seine Anwendung übernehmen darf, da keinerlei Prüfung etc. des Eingabewerts „name“ erfolgt, was in realen Anwendungen eine Sicherheitslücke darstellen würde.

Pulley "The long and the short of it" - Rezension

Nach zwei Jahren Pause ist vor Ende Juni 2011 die neue EP von Pulley erschienen, Titel "The long and the short of it".

Pulley gehört zu meinen Lieblingsbands - schöner Westcoast-Punkrock, melodisch und straight.

Leider hat die neue EP nur drei Tracks und somit eine Gesamtspielzeit von etwas weniger als 9 Minuten... Nicht viel, aber besser als gar nichts.

Im Vergleich zu den Vorgängeralben und EPs finde ich "The long and the short of it" etwas rauer - klingt aber immer noch nach Pulley. Sprich, wer Pulley mag, dem wird auch diese EP mögen. Und wer Pulley noch nicht kennt, aber Westcoast-Punkrock mag, der sollte sich diesen Release mal anhören. Mir gefällt's jedenfalls.

Ein einfacher HTTP und HTTP/CGI Server mit Python

Es gibt Situation, da braucht man einfach nur mal schnell einen simplen (CGI-fähigen) HTTP-Server - sei es, um z.B. HTML-Seiten oder CGI-Skripte zu testen oder von unterwegs temporär Dateien zum Download freizugeben.

Dazu braucht man keinen kompletten Webserver wie Apache & Co., es reicht auch Python. Der Vorteil ist, dass zumindest so gut wie alle Linux-Distributionen Python an Bord haben, man hat also alles dabei, was man braucht. Beide Serverarten lassen sich übrigens mit Bordmitteln von Python umsetzen, es sind nur Module notwendig, welche in der Standardinstallation enthalten sind.

HTTP-Server

Die schnellste Varianten besteht nur aus einem einzigen Befehl:

python -m SimpleHTTPServer

bzw. für Python 3:

python3 -m http.server

Dabei wird einfach das Python-Modul "SimpleHTTPServer" direkt aufgerufen. Dieses startet dann automatisch einer HTTP-Server, welcher generell (!) erreichbar ist und auf Port 8000 lauscht. Somit ist der Server auch von außen zu erreichen, sofern der Rechner mit dem Internet verbunden ist.
Ausgeliefert werden können alle (und alle heißt wirklich alle!) Dateien, welche im Verzeichnis und allen Unterverzeichnissen liegen, in dem der Befehl ausgeführt wurde. Gibt es in diesem Verzeichnis eine Datei "index.html" so wird diese - wie bei anderen HTTP-Servern auch - standardmäßig ausgeliefert, sofern die die URL des Servers ohne weitere Angaben aufgerufen wird.
Zum Testen kann man den Server nur per Browser auf dem gleichen Rechner über die URL http://localhost:8000 erreichen.

WARNUNG: Wie oben bereits erwähnt, liefert der Server alle Dateien aus, die im gleichen Verzeichnis liegen, vom dem der Aufruf erfolgte, inklusive aller Unterverzeichnissen. Ruft man den Befehl also im Wurzelverzeichnis des Dateisystems auf, so wäre prinzipiell das komplette Dateisystem zum Download "offen"! Daher sollte man immer doppelt prüfen, in welchem Verzeichnis man sich befindet, bevor man den Befehl ausführt! Außerdem ist zu bedenken, dass der Server immer mit den Rechten des Nutzers läuft, der ihn gestartet hat.

CGI-Server

Für einen CGI-fähigen HTTP-Server braucht man ein paar Zeilen mehr Code, da man dem HTTP-Server noch zusätzlich mit einem CGI-fähigen "Requesthandler" versehen muss.
Dies ist aber auch mit vier Zeilen Code möglich:

#!/usr/bin/env python

from BaseHTTPServer import HTTPServer

from CGIHTTPServer import CGIHTTPRequestHandler

serv = HTTPServer(('',8080),CGIHTTPRequestHandler)

serv.serve_forever()

Dies kann man nun z.B. als "mein_server.py" speichern.

Nutzt man Python3, so muss man lediglich die from ... import ... Befehle ändern:

from http.server import HTTPServer, CGIHTTPRequestHandler

CGI-Skripte müssen nun im Unterverzeichnis "/cgi-bin" liegen, welches unmittelbar unterhalb der Serververzeichnisse liegen muss, und die Endung .cgi haben. Außerdem muss unter Linux das Executeable-Bit gesetzt sein, sonst kann das CGI-Skript nicht ausgeführt werden (sondern wird nur zum Downlaod angeboten).
Hat man nun z.B. ein Skript Namens "mein_skript.cgi", wie

#!/usr/bin/env python

print 'Content-Type: text/html'
print                         
print '<h1>Hallo Welt</h1>'

so kann man diese gemäß dem obigen Servercode über http://localhost:8080/mein_skript.cgi aufgerufen werden, nachdem der Server mit

python mein_server.py

gestartet wurde.

WARNUNG: Auch hier gilt, dass alle Verzeichnisse und Dateien, die unterhalb des Aufrufverzeichnisses liegen, über den Server ausgeliefert werden!

Abschließende Worte

Wie man sieht ist es sehr einfach, mit Python Bordmitteln schnell und unkompliziert einen HTTP-Server bzw. CGI-fähigen HTTP-Server zu erstellen. Dabei muss man aber immer im Hinterkopf haben, dass die Server keinerlei Rechteverwaltung kennen, d.h. es sind immer alle Dateien im Serververzeichnis und allen Unterverzeichnissen erreichbar. Des weiteren sind die Server per Voreinstellung immer über das Netzwerk bzw. Internet erreichbar.
Von daher ist vom produktiven Einsatz - zumindest in der hier gezeigten Form - dringend abzuraten. Zumal die Server "single-threaded" sind, d.h. immer nur eine Anfrage gleichzeitig bearbeiten können.
Für Testzwecken bzw. zum lokalen Testen hingegen sind die Server sehr gut geeignet.

Me First and the Gimme Gimmes "Go down under" - Rezension

Es ist ja schon ein bisschen her, dass Me First and the Gimme Gimmes einen Release rausgebracht haben. Vor ein paar Monaten war es dann (endlich) wieder soweit. Zwar ist es kein Longplayer, sondern "nur" eine 5-Track EP - aber besser als gar nichts.

Wie fast alle anderen Releases gibt's auch ein Motto, in diesem Fall, wie der Titel "Go down under" schon vermuten lässt, Australien. Es werden also fünf Stücke von australischen Bands gecovert.

Während man bei den meisten Stücken der Gimme Gimmes ein Deja-Vu hat (bzw. sich das "kommt mir irgendwie bekannt vor" Gefühl einstellt), bleibt dieses bei dieser EP aus. Zumal von den "großen" australischen Künstler (AC/DC, Kylie Minogue, Midnight Oil, INXSl) "nur" letztere gecovert werden. Das macht aber nix, die Stücken punkrocken trotzdem locker-flockig vor sich hin, so wie man es gewöhnt ist.

Fazit: Gutes Album, keine Ausrutscher trotz "unbekannter" Lieder. Auf jeden Fall empfehlenswert, nicht nur für Me First and the Gimme Gimmes Fans, sondern auch für alle, die gute Punkrock Coverversionen von Pop-Songs mögen.

Evile "Enter the grave" - Rezension

Ok, Metal jedlicher Form ist nur in den seltensten Fällen mein Geschmack. Auf Evile bin ich durch einen Sampler aus der Visions 219 (erschienen 5/2011) aufmerksam geworden, auf dem ein Song von der Band drauf ist. Dieser wiederum hat mir gut gefallen.

Online gekauft habe ich mir dann "Enter the grave", der erste (?) Release von Evile, erschienen auf Earache. Musikalisch liegt Evile irgendwo zwischen den frühen Metallica und Slayer, nur halt in modern. Dabei ist das Spiel durchaus abwechslungsreich, die Doublebass schnell und der Gesang gefällig. Lediglich die Gitarrensoli klingen ein bisschen dünn, wobei die Lieder im Gesamten schon Druck haben, also am Mix alleine liegt das wohl nicht. Textlich ist es nicht so wirklich meine Richtung, aber darüber kann man auch hinweg sehen (hören). Insgesamt umfasst "Enter the grave" zehn Lieder, die Spielzeit beträgt ca. 53 min.

Wer mit den beiden zuvor genannten Bands was anfangen kann, der sollte mal ein Auge bzw. ein Ohr auf Evile werfen. Denn die wissen zu gefallen und könnten in der Zukunft durchaus noch "größer" werden.

Bottle und statischer Inhalt - Verwendung von static_file

Der der Verwendung von in Python geschriebenen WSGI-basieren Webapplikationen kommt es immer wieder zu Verwirrungen, wenn dynamisch generierter Inhalt mit statischem (wie Bilder, CSS-Dateien) gemischt werden soll.

Dies oft dadurch bedingt, dass man beim Programmieren noch das "klassische" HTML und die zugrunde liegende Datei- / Verzeichnisstruktur im Kopf hat. Nur: WSGI-Applikation können im Server grundsätzlich an einen beliebigen Pfad ("Route") gebunden werden, der vom Speicherort der Datei(en) auf der Festplatte unabhängig ist.

Um nun statischen Content auszuliefern gibt es zwei Möglichkeiten: entweder man holt diesen von einer anderen URL, die außerhalb der Routen der Applikation liegen oder - geschickter - man definiert eine Route, welche für das Ausliefern zuständig ist.

Verwendet man das Bottle Microframework so kann eine Lösung wie folgt aussehen:

Applikation, "test_static.py":
#!/usr/bin/python
# -*- coding: utf-8 -*-

from bottle import route, static_file, template, run, debug

@route('/test')
def test():
return template('test.tpl')

@route('/test/static/:filename')
def static(filename):
rootpath = '/home/jochen/code/bottle_test/static/'
return static_file(filename,root=rootpath)

if __name__ == "__main__":
debug(True)
run(reloader=True)

Das Template "test.tpl" sieht so aus:
<html>
<head>
<title>Bottle test</title>
<link rel="stylesheet" type="text/css" href="/test/static/format.css">
</head>
<body>
<h1>Hallo Welt</h1>
<p>Wie geht's</p>
<p class="kursiv">Ich hoffe gut!</p>
</p>
</body>
</html>


Und die CSS-Datei "format.css" so:
.kursiv {font-style: italic; color: red; }

So weit, so gut. Prinzipiell sollte sich das Beispiel auch auf andere Framework übertragen lassen.

Zwei Dinge sind dabei essentiell wichtig: Erstens, dass bei der Option "root" von "static_file" der absolute Pfad zu den statischen Dateien im Dateisystem angegeben wird. Zweitens, dass in der Template-Datei die korrekte Route bezogen auf die Applikation angegeben wird. Dann sollte die Applikation auch statische Inhalte problemlos ausliefern können.

Hinweis: getestet mit Python 2.6. und Bottle 0.8.

Nomeansno - 2.6.2011 live in Köln

Ich weiß gar nicht mehr so genau, wenn ich die erste Platte von Nomeansno gekauft habe. Ist wahrscheinlich über 20 Jahre her. Jedenfalls habe ich die Band noch nie live gesehen, obwohl Nomeansno zu meinen Lieblingsbands gehört. Gestern Abend war es dann endlich so weit: Nomeansno live im Gebäude 9 in Köln, und das zu einem moderaten Eintrittspreis von ca. 17 Euro,

Überpünktlich um 20.55 fing die Vorband an, Guts Pie Earshot. War mir bis dato  nicht bekannt, ist aber sehr cool. Nur zwei Leute, ein Schlagzeuger und ein Cellist mit einem E-Cello. Musikalisch ein Cross-Over aus Techno, EBM, ein bisschen New-Metal, ein bisschen Klassik und ein bisschen von vielem anderen. Kam auf jeden Fall gut an.

Gegen 22 Uhr haben dann Nomeansno los gelegt. Cool sind die Jungs ja: Soundcheck mal schnell selber gemacht und dann los. Zum Anfang wurden ein paar schnellere, punkigere Stücke gespielt und ab dem zweiten Lied tobte der Saal. Es wurden Stücke von allen Platten von alt bis neu gespielt. Zur Mitte des Sets wurde es etwas langsamer und ruhiger, bevor zum Schluss wieder Gas gegeben wurde. Aber es war so wie so egal, was gespielt wurde: Der Saal gehörte Nomeansno. Nach zwei Zugaben war denn kurz nach Mitternacht Schluss.

Wie nicht anders zu erwarten war, war das Publikum etwas älter, der Schnitt lag wahrscheinlich kurz über 40. Und es waren, verglichen mit anderen Konzerten, viele Frauen anwesend. Apropos Alter: Ich habe keine Ahnung, wie als Rob, John und Tom von Nomeansno sind - aber die drei haben immer noch mehr Power als viele "junge" Bands. Der Sound war ok, tight und druckvoll spielen Nomeansno ja so wie so.

Alles in allem: Super Konzert, ein gelungener Abend! Und Nomeansno ist live wohl immer eine Empfehlung.