Keyboard Interrupt

Im Zweifel Control-C

Dockerizing s3cmd

Dieser Artikel beschreibt (hoffentlich verständlich) wie s3cmd "dockerisiert" werden kann. Hintergrund ist der, dass ich nach einer Möglichkeit gesucht habe, Daten aus einem Docker-Container nach Amazon S3 zu schreiben/lesen.

Was ist dieses Docker? Bevor ich eine holprige Erklärung abliefere, hier die Beschreibung von https://www.docker.com/whatisdocker/:

What is Docker?

Docker is an open platform for developers and sysadmins to build, ship, and run distributed applications. Consisting of Docker Engine, a portable, lightweight runtime and packaging tool, and Docker Hub, a cloud service for sharing applications and automating workflows, Docker enables apps to be quickly assembled from components and eliminates the friction between development, QA, and production environments. As a result, IT can ship faster and run the same app, unchanged, on laptops, data center VMs, and any cloud.

Bei s3cmd handelt es sich um einen Amazon S3 Command Line Client, der die S3-API abbildet, dies ermöglicht das komfortable Manipulieren von S3-Buckets, Upload/Download von Daten und, für mich der entscheidende Punkt, eine rsync-ähnliche Funktionalität zur Erstellung von etwa Backups.

Erstellen der s3cmd-Config

Am einfachsten ist es, die Konfiguration s3cmd zu überlassen, dazu verwendet man folgendes Commmand

% s3cmd --configure

Nachdem alle abgefragten Optionen gesetzt sind, wird im Home-Verzeichnis die Datei .s3cfg erstellt, die s3cmd zukünftig für die Kommunikation mit S3 benutzt. Eine .s3cfg könnte ungefähr so aussehen

[default]
access_key = AWSACCESSKEY
bucket_location = US
cloudfront_host = cloudfront.amazonaws.com
cloudfront_resource = /2010-07-15/distribution
default_mime_type = binary/octet-stream
delete_removed = False
dry_run = False
encoding = UTF-8
encrypt = False
follow_symlinks = False
force = False
get_continue = False
gpg_command = /usr/local/bin/gpg
gpg_decrypt = %(gpg_command)s -d --verbose --no-use-agent --batch --yes --passphrase-fd %(passphrase_fd)s -o %(output_file)s %(input_file)s
gpg_encrypt = %(gpg_command)s -c --verbose --no-use-agent --batch --yes --passphrase-fd %(passphrase_fd)s -o %(output_file)s %(input_file)s
gpg_passphrase = supersecretpassphrase
guess_mime_type = True
host_base = s3.amazonaws.com
host_bucket = %(bucket)s.s3.amazonaws.com
human_readable_sizes = False
list_md5 = False
log_target_prefix = 
preserve_attrs = True
progress_meter = True
proxy_host = 
proxy_port = 0
recursive = False
recv_chunk = 4096
reduced_redundancy = False
secret_key = ACCESS SECRET KEY
send_chunk = 4096
simpledb_host = sdb.amazonaws.com
skip_existing = False
socket_timeout = 300
urlencoding_mode = normal
use_https = True
verbosity = WARNING

Generieren des Docker-Images

Docker-Images lassen sich am einfachsten mit Hilfe von Dockerfiles erstellen, meins sieht wie folgt aus

# Base system is the LTS version of Ubuntu.
FROM    ubuntu:14.04

# Make sure we don't get notifications we can't answer during building.
ENV     DEBIAN_FRONTEND noninteractive

# Download and install everything from the repos.
RUN     apt-get update && apt-get -y upgrade; \
        apt-get -y install s3cmd; \
        apt-get clean

ADD     .s3cfg .s3cfg

ENTRYPOINT  ["/usr/bin/s3cmd"]

Achtung: Damit Docker das Image erfolgreich bauen kann ist es notwendig, dass die zuvor erstellte s3cmd-Config am selben Ort wie das Dockerfile liegt.

Alle Voraussetzungen wären damit erfüllt, man wechselt nun in das Verzeichnis des Dockerfiles und erstellt das Image:

% docker build -t "s3backup" .
% docker images # zeigt das neue Image im Repository

Benutzung

Ein aus diesem Image erstellter Container kann jetzt wie die Anwendung s3cmd selbst genutzt werden, z.B. lässt man sich mit dem nächsten Command die Hilfe ausgeben

% docker run --rm s3backup --help

Mein Anwendungsszenario besteht darin, Daten aus einem "data-only"-Container nach S3 zu synchronisieren. Folgender Befehl zeigt, wie so etwas aussehen könnte:

% docker run --rm --volumes-from data-only s3backup sync --delete-removed -r /data/service/ s3://bucket-name

Durch die Flexibilität kann das Image aber auch für jegliche andere S3-Operation genutzt werden. Wie immer, bei Anmerkung o.ä. findet ihr rechts Links zu meinem ADN, Google+ und GitHub-Profilen.

Lesestoff

Mein neues Blog mit Nikola

Mein Blog ist nun endlich auf meinen eigenen Server umgezogen und wird jetzt von Nikola generiert. Nikola ist ein in Python geschriebener Static Site Generator von Roberto Alsina, Static heißt: kein PHP, keine Datenbank, kein krudes CMS, nur schlichtes HTML, CSS und Javascript, was natürlich einige Vorteile mit sich bringt:

  • geringe Ladezeiten der Seiten
  • mehr Sicherheit
  • Kompatibilität mit so ziemlich jedem Webhoster
  • Wartungsaufwand hält sich in Grenzen
  • Posts lassen sich in den gängigen Markup-Sprachen schreiben

Dann erzähl' ich mal wie der Umzug abgelaufen ist, wer zudem genauer wissen will wie Nikola bedient wird, kann das im Nikola Handbook nachlesen oder auch im IRC-Channel #nikola auf irc.freenode.net direkt mit den Entwicklern sprechen. Die Beschreibungen sollten unter Mac OSX und Linux funktionieren, wie es mit Windows aussieht, kann ich leider nicht beurteilen.

Installation

Nikola lässt sich relativ einfach via pip installieren, am Besten in ein virtual environment. Dazu wird das Python Package virtualenv benötigt.

pip install virtualenv

Jetzt einfach einen Ordner für das Blog anlegen

mkdir -p website/blog

und ein virtualenv direkt im Projektordner erstellen

cd website/blog
virtualenv --no-site-packages venv
. venv/bin/activate     # aktiviert das virtualenv

Nun kann Nikola (und für später, jinja2 und feedparser) installiert werden, ohne dass dessen Abhängigkeiten in der Python-Umgebung des Systems landen.

pip install nikola jinja2 feedparser

Blogger-Import

Damit sind die Voraussetzungen geschaffen, die bereits geschriebenen Zeilen von Blogspot zu importieren. Nikola bietet hierfür einen Blogger- bzw. Wordpress-Import. Zunächst benötigt man Posts und deren Metadaten von Google. Dafür meldet man sich mit seinem Account auf www.blogger.com an, wählt sein Blog aus, geht in dessen Einstellungen und klickt unter Sonstiges auf Blog exportieren.

Anschließend wird das Blog im zuvor erstellten Projektverzeichnis initialisiert, um die exportierten Blogspot-Daten importieren zu können.

nikola init .
nikola import_blogger -o . pfad/zum/blogspot_export.xml
mv conf.py.import_blogger-date conf.py

Die einzelnen Blogposts befinden sich jetzt im Ordner posts als html-Dateien. Leider ist bei meinem Import ein Post verschütt gegangen, also am besten noch mal kontrollieren, ob auch wirklich alles da ist.

Nun geht's an die Konfigurationsdatei conf.py. Für den Anfang reicht es aus, folgende Einträge zu editieren:

Auszug aus meiner conf.py:

# Data about this site
BLOG_AUTHOR = "Name"
BLOG_TITLE = "Keyboard Interrupt"
# This is the main URL for your site. It will be used
# in a prominent link
SITE_URL = "http://keyboard-interrupt.de"
# This is the URL where nikola's output will be deployed.
# If not set, defaults to SITE_URL
BASE_URL = "http://keyboard-interrupt.de/"
BLOG_EMAIL = "email@adresse.tld"
BLOG_DESCRIPTION = "Im Zweifel Control-C"

# What is the default language?
DEFAULT_LANG = "de"

Mit diesen Einstellungen ist es an der Zeit, sich das Blog zum ersten Mal anzusehen. Dafür wird kein eigenständiger Webserver benötigt, denn Nikola stellt selbst einen für die Entwicklung zur Verfügung, der unter http://localhost:8000 erreichbar ist.

nikola build  # generiert alle notwendigen Dateien in output/
nikola serve  # startet den Webserver

Sieht alles schön aus, könnten die Dateien aus dem output-Ordner einfach auf den Webspace kopiert werden und fertig ist die Laube.

Theme

Vielleicht hat man aber auch noch Lust auf ein anderes Theme. Unter http://themes.getnikola.com finden sich einige Themes, die in Nikola zur Verfügung stehen. Mit den folgenden Befehlen lassen sich die Themes auflisten, bzw. installieren (vorausgesetzt das requests Package ist installiert).

nikola install_theme --list     # listet Themes des Repositories
nikola install_theme theme-name # installiert das Theme

Zum Aktivieren trägt man das Theme in die conf.py ein.

# Name of the theme to use.
THEME = "controlc"

Anfangs wollte ich das Theme bootstrap3-jinja verwenden, musste aber leider feststellen, dass der Text der Sites auf mobilen Geräten links und rechts abgeschnitten wird. Somit habe ich das Theme dieser Seite selbst erstellt, bzw. von diesem Bootstrap-Template by Mark Otto abgeschaut und Teile des Nikola-Bootstrap-Themes verwendet. Dazu wirds ggf. einen eigenen Post geben. Infos zum Theming gibt's in diesem Tutorial oder dort: NIKOLA: THE STATIC BLOG ENGINE A.K.A. HOW I BUILD SHISAA.JP

Deployment

Hier fehlt mir leider noch ein geeigneter Workflow. Momentan baue ich das Blog, Lösche den Inhalt aus dem Document Root des Webservers und kopiere die neu erzeugten Dateien via scp aus dem output-Ordner auf den Server. Etwas umständlich wie ich finde, steht aber auf der TODO-Liste.

TODO

Das wären dann die Dinge, die noch zu erledigen sind:

  • Überarbeitung einiger HTML-Elemente
  • einfacheres Deployment des Blogs (wahrscheinlich via fabfile)
  • Einfügen des fehlenden Blogposts
  • Veröffentlichung der Dateien auf Github (da bin ich mir noch nicht sicher)
  • Ändern der E-Mail-Adresse des Blogs

Soweit so gut. Für Anregungen, Fragen oder sonstige Bemerkungen gibt's mich auf Google+ oder App.net (siehe rechts, bzw. ganz unten, je nach Gerät).

Flask und flaskenv

Ich beschäftige mich nun seit einigen Tagen mit Flask, einem in Python geschriebenen Micro-Web-Framework, und wie das am Anfang so ist, probiere ich viel aus und erstelle ein Projekt nach dem anderen.  Die Struktur eines solchen Projekts sieht in etwa so aus:

<project name>
|- app
| |- templates
| |- static
| |- venv
| |- __init__.py
| |- views.py
|- run.py
Und da es mir etwas zu umständlich war, ständig diese Verzeichnisse und Dateien (inklusive grundlegendem Inhalt) anzulegen, habe ich flaskenv geschrieben, was mir die ganze Arbeit abnimmt. Die Benutzung ist denkbar einfach, man führt einfach folgenden Befehl aus
flaskenv.py <project name>
Anschließend muss lediglich das Virtualenv aktiviert
. <project_name>/venv/bin/activate
und natürlich Flask installiert werden
pip install flask

Die Anwendung setzt Python 3.3 voraus, läuft auf Mac OS X und sollte auch unter Linux keine Probleme machen.

Sollte es jemandem ähnlich gehen, flaskenv, sowie den dazugehörigen Code gibt es hier https://github.com/grimlck/flaskenv. Es ist nicht das schönste Python, aber das Script macht was es soll und für Verbesserungsvorschläge bin ich immer offen.

Wer sich ebenfalls für Flask interessiert aber noch nicht den richtigen Einstieg gefunden hat, dem empfehle ich das Flask - Mega Tutorial von Miguel Grinberg.

Viel Spaß beim Ausprobieren.





LinuxTag 2013 Tag 4

Last but not least, gibt es auch die Zusammenfassung von Tag 4 des LinuxTag 2013.

Die Themen an diesem Samstag waren vorwiegend Security und Device Freedom, wobei mich die Security-Tracks mehr interessiert haben, wie man an meinen besuchten Vorträgen sehen kann. Das komplette Vortragsprogramm und weitere Information zum LinuxTag kann man unter http://www.linuxtag.org/2013/

Viel Spaß.

Verteilter Pastebin mit HTML5: DistPaste

Sprecher: Jan-Ole Malchow

In erster Linie ging es um die Neuheiten in HTML5, was man damit anstellen kann und welche Gefahren es birgt. Eine der ersten Aussagen war: "HTML5 Rocks". Warum? Es läuft in allen gängigen Browsern und bietet mit Hilfe von Javascript Zugriff auf Netzwerkstack und Webstorage, jedoch weicht es auch den Zugriff auf Ressourcen über Domaingrenzen hinweg (Cross Origin Resource Sharing, kurz CORS) auf. Somit ist es nun auch möglich komplexe Netzwerkanwendungen zu programmieren, was Jan-Ole mit DistPaste demonstriert hat. DistPaste ist ein verteiltes Pastebin, welches die Text-Snippets nicht auf einem Server ablegt, sondern im Webstorage der Browser, die sich mit der DistPaste-Website verbinden. Die eigentliche Koordination und die Verteilung der Daten auf die einzelnen Clients erfolgt durch einen, in Node.js geschriebenen, Server, die Client-Anwendung wurde in wenigen Zeilen Javascript-Code implementiert.

So schön die Neuheiten auch sind, stellen sich einige Fragen zur Sicherheit, zu denen die Antwort noch aussteht.

  • Woher stammt das Javascript, das auf dem Client ausgeführt wird?
  • Was kann damit alles angestellt werden? (möglichen wären DDoS-Angriffe; Nachladen von schlechtem Code, durch Trojaner; usw)
  • Wem gehören die Daten im Webstorage?
  • Wer ist für die Netzwerkverbindung verantwortlich? (Stichwort: Störerhaftung)

Wer sich dadurch verunsichert fühlt, kann in seinem Browser, Javascript einfach deaktivieren und muss leider auf die Dynamik auf Webseiten verzichten :D

Home Network Horror Stories

Sprecher: Michael Messner

Viele von uns nennen wahrscheinlich eine dieser kleinen, weißen oder auch grauen Boxen ihr Eigen, die meist in der Nähe vom Telefonanschluss verstauben und aus denen Internet fällt, damit wir Blogposts wie diesen lesen können. Die Rede ist von Plasteroutern, die auch Thema dieses Talks waren. Es wurde jedoch nicht gelobt wie toll sie ihren Job erledigen, sondern wie unsicher die Dinger eigentlich sind. Aber was will man auch erwarten, wenn man viele Router im Laden mit dem großen M hinterhergeworfen bekommt und wie kann da noch ein Hersteller auf Sicherheit achten?

Michael hat in seinem Vortrag gezeigt, was mit den Geräten eigentlich nicht stimmt. Es geht damit los, dass die Webserver der Router die Firmware-Revision verraten, das Webinterface wird unverschlüsselt via HTTP ausgeliefert, der Werbserver läuft als root, Passwortänderung ohne Eingabe des aktuellen Passworts und/oder Passwörter werden im Klartext gespeichert.

Weitere Sicherheitsprobleme haben die Webinterfaces, viele sind anfällig für:

  • Cross-site scripting (XSS)
  • Cross Site Request Forgery (CSRF)
  • Directory Traversal
  • Auth Bypass
  • OS Command Injection

Im Großen und Ganzen, meinte Michael, sind viele Router-Webinterfaces mit den OWASP Top10 Vulnerabilities angreifbar.

Demonstriert hat er einige der Schwachstellen an den Geräten D-Link DIR-300/DIR-600 und Linksys WRT54GL.

Also Augen auf beim Routerkauf, oder man bastelt sich seinen Router aus alter Hardware zusammen und ist selbst für die Sicherheit  verantwortlich.

Anifeatures - Keynote

Sprecher: Benjamin Mako Hill

Antifeatures sind eigentlich der Grund, warum Free and Open Source Software (FOSS) the way to go ist. Beispiele für Antifeatures sind:

  • Sonys Fresh Start "Feature", das sie auf früheren Laptops ausgeliefert hat, eigentlich war es Bloat-Software, damit dieses Fresh Start nicht aufgedrückt bekommt, musste man schlappe 50 $ zahlen
  • Microsoft 7 Starter, erlaubt nur 3 gleichzeitig geöffnete GUI-Programme, möchte man mehr (und jaaaa das möchte man), muss man die nächst größe Windows 7-Variant kaufen
  • Digital Restriction Management (DRM) auf digitalen Medien
  • Chips in Druckerpatronen, damit nur Originalhardware eingesetzt werden kann
  • Copyright-Warnings auf DVDs/BluRays

Unternehmen verkaufen uns Dinge die wir nicht brauchen und verlangen zusätzliches Geld um sogenannte Antifeatures wieder loszuwerden. Wenn das nicht für FOSS spricht!

Totalschaden: Ein gehackter Server auf dem OP-Tisch

Sprecher: Peer Heinlein

Ein Anruf beim Support, "Mein Server wurde gehackt, bringt mir meinen Shop wieder zurück!" und das natürlich so schnell wie möglich. Peer Heinlein hat in seinem Vortrag gezeigt, wie er mit diesem Fall umgegangen ist und welche Funde er gemacht hat.

Wie kam nun der vermeintliche Hacker auf das System? Hier gab /var/log/auth.log Aufschluss, und zwar wurde der SSH-Zugang einer BruteForce-Attacke unterzogen, die zum Erfolg führte. Anschließend platzierte der Angreifer einige verdächtige Perl-Skripte, die am Zeitstempel und anhand verdächtiger UIDs und GIDs erkennbar waren. Nachdem diese gelöscht und der SSH-Zugriff auf wenige IPs beschränkt wurde, war die Webseite des geschädigten auch wieder erreichbar. Bis zum nächsten Anruf.

Wieder hat sich ein Angreifer Zugriff zum System verschafft, diesmal jedoch nicht über SSH. Verdächtige Prozesse waren mit ps oder top nicht auszumachen, nach längerem Suchen, fiel dann aber ein Ordner mit dem Namen "..." auf. Manchmal sind die offensichtlichsten Verstecke die besten, den der Name reiht sich so schön in die Ausgabe von ls -la ein (".", "..", "..."?). Was Peer Heinlein an dieser Stelle noch sagte, man sollte für die Analyse solcher Fälle, weniger bekannte Tools, wie zum Beispiel_ lsof _verwenden. Denn damit hat er herausgefunden, dass eine Anwendung SSH-Verbindungen in die ganze Welt aufbaut. Die o.g. Tools wurden nämlich durch das Rootkit auf dem Server ersetzt und lieferten keine verlässlichen Ausgaben mehr. Ein weiterer Trick der Angreifer sind wohl unauffällige Namen, der Prozess, der die SSH-Verbindungen aufbaute hier "3". Die schlechten Dateien wurden dann auch wieder entfernt und die Website konnte wieder online gehen.

Am besten man gibt die Verwaltung eines solchen Systems in die Hände eines fähigen Admins.

Hacking Contest

Moderation: Kester Habermann und Nils Magnus

Wo wir schon bei gehackten Servern sind.

Es traten an die "Gotischen Systemquaeler" gegen das Team "Legofan". Der Contest teilte sich in drei Runden auf.

  1. Beide Teams mussten, innerhalb von 15 Minuten auf einem Standard-System mit Debian Wheezy, so viele Backdoors mit Bordmitteln einbauen, wie möglich. Auf Leinwänden wurde gezeigt, was die Kontrahenten mit den Systemen anstellten. Leider kann ich das hier nicht beschreiben, da es einfach meinen Horizont überschritten hat. Ich sag nur soviel, lange Perl-Einzeiler, Byte-Mounts und das andocken an system-daemons.
  2. Nun wurden die System getauscht und es mussten die Backdoors der Teams gefunden und unschädlich gemacht werden. Für jede erkannte Hintertür gab's Punkte.
  3. Wieder an den ursprünglichen und nun eventuell sauberen System, zeigten die Teams, welche Backdoors nicht gefunden worden sind und wie sie für den Erhalt von root-Shells ausgenutzt werden können. Remote-Shells waren wertvoller als Local-Shells.

Gewonnen haben die "LegoFan"s, die eigene Zählung ergab nämlich ACHT nicht beseitigte Remote-Shells und ein paar lokale.

Und das war's mit dem LinuxTag 2013, ich freu' mich schon auf nächstes Jahr.

LinuxTag 2013 Tag 3


LinuxTag LogoZwar ein bisschen verspätet, aber dennoch will ich auch die Vorträge vom dritten Tag zusammenfassen. Zusätzlich habe ich auch am Workshop "Django: Schnell performante Web-Applikationen entwickeln" vom Deutschen Django Verein e.V.  teilgenommen, auf den ich auch noch kurz eingehe.
Aber das wichtigste zuerst, es gab Club Mate! von Microsoft!, woanders habe ich nämlich auch an diesem Tag keine entdeckt. Fotos vom LinuxTag sind auf meinem Google+ Profil zu finden bzw. direkt über diesen Link https://plus.google.com/photos/106298310868954824836/albums/5881630734988897921.

Und los geht's.

Am dritten Tag fand zusätzlich zum Vortragsprogramm des LinuxTags der OpenStack DACH Day statt, an dem sich die OpenStack Community, Nutzer und Interessierte zusammenfinden, um u.a. einen Einblick zu bekommen, wie OpenStack "in the wild" verwendet wird.

Ein Auszug aus der Wikipedia:
OpenStack ist ein Softwareprojekt, welches eine freie Architektur für Cloud-Computing zur Verfügung stellt. Initiiert wurde es von Rackspace Cloud sowie der NASA und wird von diversen anderen Firmen, unter anderem SUSE Linux GmbH, DellCanonicalCitrix SystemsHewlett-PackardAMD und Intel, unterstützt. Zuletzt traten im April 2012 Red Hat und IBM OpenStack bei. Entwickelt wird OpenStack als freie Software, in der Programmiersprache Python. OpenStack ist unter der Apache-Lizenz lizenziert.
http://de.wikipedia.org/wiki/OpenStack

Den Auftakt gab Jonathan Bryce, Executive Director der OpenStack Foundation, mit seiner Keynote. Er erklärte die Motivation hinter OpenStack und betonte die hohe Popularität, die OpenStack in so kurzer Zeit erlangt hat.

Weiter ging es mit dem Talk von Kurt Garloff, Engineering Department Cloud Services der Deutschen Telekom, in dem er das SaaS-Projekt "BusinessMarketplace" der Telekom erklärte, bei dem OpenStack     zur Verwendung kommt. Ein eigens dafür zusammengestelltes Entwickler-Team kümmert sich um die Anpassung und die Erweiterung von OpenStack und lässt seine Errungenschaften in das Projekt zurückfließen.

Den letzten Vortrag aus dem OpenStack-Track, den ich besucht habe, wurde gehalten von Muharem Hrnjadovic (Rackspace), dessen Titel war "Elasticity in the OpenStack cloud". Wie der Name schon vermuten lässt, ging um das Scaling bzw. das Auto-Scaling in der Cloud und wie es bei OpenStack realisiert ist. Natürlich ist es möglich manuell zu Skalieren, aber wer will das schon. Zum Auto-Scaling kann das OpenStack Orchestrion-Tool HEAT (https://wiki.openstack.org/wiki/Heat) verwendet, damit können bei etwaigen Lastspitzen etwa neu Instanzen zugeschaltet und anschließend auch wieder entfernt werden. Alles weitere kann im OpenStack Wiki.

Soviel zum OpenStack DACH Day.

Nun zum Django-Workshop "Django: Schnell performante Web-Applikationen entwickeln" vom Deutschen Django Verein e.V. Ziel war es, eine Web-App zur Verwaltung von Booksmarks, mit dem Namen "Marcador", zu entwickeln.

Nachdem noch einmal erklärt wurde, worum es sich bei Django eigentlich handelt und wie es aufgebaut ist, siehe auch mein Post zu seinem Vortrag, hätte es eigentlich losgehen können. Leider hat uns jedoch das LinuxTag-WiFi im Stich gelassen, was bei der Installation von Django und dem HTML5-Bootstrap etwas hinderlich war, zudem gab es die Workshop-Unterlagen auch nur online. Doch das Workshop-Team hat schnell reagiert und alle notwendigen Dateien via USB-Stick verteilt. Und ging es dann wirklich los, der Workshop vermittelte alle wichtigen Aspekte des Umgans mit Django, von der Installation, über das Anlegen der Models (Datenbankstruktur), Umgang mit dem django-admin, Konfigurieren der Views, Erstellen von HTML-Templates und und Formularen, bis hin zur fertigen Applikation. Alles in allem eine sehr schöne Einführung. Wer sich selbst mit Django beschäftigen möchte, findet das Tutorial hier http://django-marcador.keimlink.de.

Das war's vom dritten Tag des LinuxTag 2013. Der vierte und letzte Teil kommt in den nächsten Tagen.

Linuxtag 2013 Tag 2


Der zweite Tag ist nun vorüber. Die angesprochene Parkplatzsituation hat sich entspannt, man muss halt nur den richtigen wählen :D .  Mir ist aufgefallen, dass es anscheinend nur ausgewählte Personen "Club Mate" bekommen, dafür gab's im CMS-Garden aber die üblichen Messemitbringsel.
Messemitbringsel


So und nun zu meinem Vortragsprogramm an Tag 2.

Django 1.5 - Erste Schritte und neue Features
Sprecher: Markus Zapke-Gründemann
Markus hat hier eine Einführung zum Python Web-Framework Django gegeben. Er ist auf die Architektur (siehe Slide aus dem Vortrag) und die Komponenten, die Django von Haus aus bietet, eingegangen. Hier ein paar Beispiele:

  • Sessions-Management
  • Authentifizierung
  • Formular- und Validierungsframework
  • Internationalisierung
  • Lokalisierung
  • Testing
  • Caching
  • Security
  • File Storage API
Wem das nicht reicht, kann über den Python Package Index unzählige Module nachinstallieren.

Herausgehoben wurde der Django-Admin, über den die Inhalteverwaltung, basierend auf der Datenbankstruktur (den Models) geschieht. Weiterhin hat Markus die Neuerungen in Django 1.5 angesprochen, dazu zählen:

  • experimenteller Python 3 Support
  • konfigurierbare Usermodel
  • Speichern von Modelsubsets
  • verbessertes HTTP-Streaming
  • Unterstützung von PostGIS2.0

Django wird von vielen Projekten und Unternehmen eingesetzt, unter anderem, Washington Post, ubuntuusers.de, Vodafon, BitBucket, Mozilla Add-Ons oder VMWare.

Die Slides zum Vortrag gibt's hier: https://speakerdeck.com/keimlink/django-1-dot-5-erste-schritte-und-neue-features
Und wer mehr über Django oder Python erfahren möchte, ist hier richtig:
https://www.djangoproject.com
http://python-verband.org
http://python.org

Which filesystem should I use?
Sprecher: Heinz Mauelshagen
Hier ging es um Vorteile und Nachteile der lokalen Linux-Dateisysteme ext3, ext4, xfs und btrfs. Meine Notizen dazu sind folgende (wenn auch nicht vollständig):
ext3:

  • langsames block mapping
  • langsames fsck für große Dateisysteme mit vielen Dateien
  • langsamer als andere lokale Dateisysteme
  • 16 TB Dateisystemlimit und 2 TB Dateigrößenlimit
  • dafür ist es aber weit verbreitet und die Admins wissen in der Regel womit sie es zu tun haben

ext4:

  • kleine Dateien werden effizient gespeichert
  • höhere Bandbreite als ext3
  • schneller bei mkfs und fsck (10x gegenüber ext3)
  • nicht benutzbar für die heutigen, riesigen Dateisystemgrößen

xfs:

  • geeignet für große Speichersysteme
  • > 16TB
  • hohe Bandbreite
  • nicht allzu bekannt
  • keine in-place-Migration von ext-Dateisystemen
  • Performance-Probleme mit Meta-data workloads (rm -rf kann lange dauern)

btrfs:

  • internes Raid
  • Snapshot/clone
  • Kompression
  • Data integrity checks für Meta- UND Benutzerdaten (checksums)
  • dynamisches vergrößern und verkleinen (beides online)
  • in-place ext conversion (vor und zurück), dank der Snapshots
  • noch nicht weit verbreitet und bekannt
  • kein full-featured fsck
  • noch nicht für den produktiven Einsatz empfohlen

Weiterhin waren auf den Slides einige Dateisystems-Tools zu finden, die ich hier nur in den Raum werfe:
e2fsprogs, xfsprogs, btrfs-progs, fstrim, ssm (Vereinheitlichung des Dateisystem Managements)
Zusammenfassend ist wohl zu sagen, btrfs ist der heiße Scheiß den man einsetzen möchte, sofern es denn mal fertig ist.

Puppet, klar. Und dann?
Sprecher: Thomas Gelf
In diesem Vortrag wurden weiterführende Puppet-Themen besprochen. Dazu gehörten:

  • Abhängigkeiten beim Management, Run Stages
  • systemübergreifende Konfiguration (Clustermitglieder, automatisches Eintragen von known_hosts Fingerring, sobald ein neuer Rechner ausgerollt wird)
  • PuppetDB
  • MCollective: MQ-basierte Software zur Steuerung von Servers
  • Node-Definitions
Ohne die Basics sind die o.g. Punkte aber böhmische Dörfer, um sich diese jedoch anzueignen, gibt es ein paar Anlaufstellen:
Puppet Docs: http://docs.puppetlabs.com/learning
Puppet Fundamentals: http://www.netways.de/de/units/training/puppet/

Systemadministratoren: "Überleben" in einer agilen Welt
Sprecher: Ralph Angenendt
Es ging mit einer Übersicht los, inwieweit sich die Softwareentwicklung im Laufe der Zeit gewandelt hat, nämlich vom Wasserfallmodell zu Scrum und was das für einen Administrator bedeutet. Und zwar muss Software nun nach kurzen Entwicklungszyklen (Sprints) und kontinuierlich deployt werden, wobei die herkömmliche Arbeitsweise der Administration nicht mehr funktioniert. Ralph hat in seinem Vortrag erklärt, wie sein Team die Herausforderungen mit Hilfe von Kanban meistert.

Kanban - der aktuelle Stand


Beyond open source configuration management - Rapidly building any cloud at scale
Sprecher: Tom Hatch
In diesem Vortrag wurde Salt, eine in Python entwickelte Software zum  Configuration Management und der Orchestration von Servern, seeeehr philosophisch erklärt.
Salt stellt eigentlich die gleichen Funktionalitäten wie Puppet oder Chef bereit (auch wenn Tom Hatch das nicht gern hören wird), erweitert diese aber durch ein Monitoring der States, wenn ich das richtig verstanden habe.
Unter http://saltstack.com/community.html findet man alle weiteren Information.

That's it. Die Vorträge waren alle sehr gelungen, nur dass die Sprecher leider wenig Zeit haben, somit werden viele Dinge lediglich angerissen, schade.

LinuxTag 2013 Tag 1

Es ist wieder soweit, der Linuxtag findet vom 22.05. bis zum 25.05. in Berlin auf dem Messegelände statt.

Mein Resümee des ersten Tages: Interessante Veranstaltung, viele Aussteller und informative Vorträge. Nur die Parkplatzsituation war unter aller Kanone. Der auf der Linuxtag-Webseite ausgewiesene Parkplatz 17 des Messegeländes hat keinen direkten Zugang über das Messegelände zu Halle 7, in der die Veranstaltung stattfindet, man muss also drumherum laufen, was bei dem heutigen Wetter eher unangenehm war. Es ist eben nicht alles Gold, blablabla.
Kurz zu den Talks die ich besucht habe:

Git-Einführung

Sprecher: Julius Plenz
Die Einführung in Git war gelungen, Thema war weniger die detaillierte Benutzung von git, sondern eher wie es unter der Haube funktioniert. Für tiefergehende Informationen und die eigentliche Bedienung von Git wurden unter anderem das Buch "Git. Verteilte Versionsverwaltung für Code und Dokumente" (wobei Julius einer der Autoren ist), sowie die interaktive Website try.github.io empfohlen.

Gitblit and SCM-Manager - inhouse Github alternatives for comapanies

Sprecherin: Sarah Haselbauer
Gitblit and SCM-Manager sind web-based management tools für Git und weitere Version Control Systems. Beide sind in Java geschrieben und stehen in Konkurrenz zu Gitlab oder gitorious. Die Installation und Einrichtung soll bei beiden recht einfach ablaufen. Schön war auch zu erfahren, wie der Entscheidungsprozess für die jeweilige Software ablief. Hier http://bizware.spree.de/lnx-2013/#/title gibt's die Slides, darin findet sich auch die Entscheidungsmatrix für bzw. gegen die jeweilige Software.
gitblit: http://gitblit.com
scm-manager: http://www.scm-manager.org

Samba 4 AD und File Server

Sprecher: Volker Lendecke (Samba Team)
Hier wurde Samba 4 vorgestellt, derzeitiger Stand der Entwicklung (momentan wird SMB 2 voll unterstützt) und was noch zu tun ist (nämlich die Implementierung von SMB 3).

Gitifizierung des Admin-Alltags - Gitify your digital life

Sprecher: Richard Hartmann
Wie kann git mein Leben leichter machen? Vorgestellt wurden folgende Projekte:
Die Slides von diesem und weiteren Talks von Richard gibt's hier http://richardhartmann.de/talks

Virtuelle Entwicklungsumgebung mit Vagrant:
Sprecher: Markus Zapke-Gründemann
Vagrant ist eine Management-Software für virtuelle Maschinen, anfangs nur für VirtualBox-VMs, jetzt aber auch, gegen Bezahlung, für VMWare, Amazon EC2, oder LXC. Markus hat die grundlegende Funktion vom Erstellen der Box, bis zu einem einfachen Provisioning erklärt, natürlich im Rahmen eines 45 Minuten-Vortrags.

Danach gab's für mich nur noch einen halben Vortrag, den ich daher nicht erwähnen werde. Morgen geht's dann weiter, den Start macht "Django 1.5 - Erste Schritt und neue Features", ich bin gespannt.

tbc

Wie kommt eigentlich dieser Flattr-Button auf mein Blog?

Ja wie denn?

Da ich keinen Schimmer von JavaScript und der "blogger templating engine" habe und auch keine Zeit und Lust mich damit auseinanderzusetzen, suchte ich nach einer Alternative dieses Blog mit Flatter zu verbinden. Und hier ist sie, http://tools.flattr.net/blogger/. An dieser Stelle vielen Dank für das nette Tool.

Einfach die Flattr User-ID eingeben, nach belieben die Optionen wählen, sich bei bei blogger.com einloggen, Blog auswählen, Namen für das Widget eingeben und anschließend auf dem Blog platzieren. That's it.

Flattr-Tools für weitere CMSe, Blogs, Wikis, etc. sind hier zu finden http://developers.flattr.net/tools/.

Und wer immer noch nicht weiß, was Flattr eigentlich ist, der guckt hier https://flattr.com oder wer nicht lesen möchte hier




CentOS 6.4 in Virtualbox 4

Eigentlich benutze ich Debian bzw. Ubuntu als Betriebssysteme, aber zu Testzwecken brauche ich diesmal zusätzlich irgendetwas rpm-basiertes und habe mich für CentOS 6.4 entschieden. Da die Installation nicht so einfach von der Hand ging, beschreibe ich mal mein Vorgehen.

Zuerst benötigt man natürlich ein Installationsmedium, für den Download verwende ich gerne die torrent-Datei, hier gibt es diese für CentOS 6.4 64 bit oder wer sich selbst was aussuchen möchte, findet hier die CentOS Mirror-Liste.

Nachdem das erledigt ist geht es mit der Installation los, also VirtualBox starten.

1. neue virtuelle Maschine Anlegen








2. Namen eingeben und Betriebssystem auswählen (Typ: Linux, Version Red Hat 64 bit)




















3. Arbeitsspeichergröße angeben, 512 MB sollte zum testen ohne X ausreichen
 
4. neue Festplatte erzeugen (VDI), dynamisch alloziert und eine Größe von 15 GB (je nach Verwendungszweck anpassen)































In den Einstellung kann man noch je nach Bedarf, einige Einstellungen ändern, da ich z.B. kein XServer installiere, entferne ich das Sound-Device. Ansonsten kann die Maschine jetzt gestartet werden.

Auf die CentOS-Installation gehe ich hier nicht genauer ein, ich möchte nur auf drei Dinge hinweisen. Erstens, die Standard-Installation legt m.E. ein, für Testzwecke, zu komplexes Partitions-Layout an, nämlich mittels LVM. Wer das nicht möchte, kann sein Layout manuell generieren. Bei mir sieht das wie folgt aus:
  • 1024 MB für swap
  • der Rest für /
Zweitens, aus mir unerklärlichen Gründen fährt CentOS by default die Netzwerk-Interfaces beim Booten nicht hoch. Da man das in der Regel möchte, ändert man die Option ONBOOT in /etc/sysconfig/network-scripts/ifcfg-[interface_name] auf yes.

Und drittens, befinden wir uns in einer virtuellen Maschine und um alle Features nutzen zu können, benötigt man die VirtualBox Guest Additions, deren Installation sieht so aus:
  • Hinzufügen des "repoforge" Repositories
    • aktuelles rpm herunterladen http://packages.sw.be/rpmforge-release/
    • GPG-Key importieren# rpm --import http://apt.sw.be/RPM-GPG-KEY.dag.txt
    • Integrität des rpms überprüfen # rpm -K rpmforge-release-0.5.3-1.el6.rf.*.rpm
    • rpm installieren
      # rpm -i rpmforge-release-0.5.3-1.el6.rf.*.rpm
  • Build-Umgebung installieren
    • # yum groupinstall "Development Tools"
    • # yum install kernel-devel kernel-headers
  • GuestAddition.iso einbinden und mounten
    # mkdir /media/cdrom && mount /dev/sr0 /media/cdrom && cd /media/cdrom
  • Guest Additions installieren # ./VBoxLinuxAdditions.run
Anschließend noch einen Reboot durchführen und die Maschine kann verwendet werden. Viel Spaß.


Mein Kondensat der CentOS Konfigurations gibt es hier noch in Ausführlich

Dell Notebook, eine SSD und die Windows-Recovery-Hölle

Ich bin gerade dabei meinen Dell XPS 15 L502X so herzurichten, dass ich ihn verkaufen kann. Also im Großen und Ganzen wollte ich nur die Recovery DVD einspielen. Man möchte meinen das sollte kein Problem sein, Fehlanzeige.

Problem Nummer 1 war die nachträglich eingebaute 128 Samsung 830 SSD. Die Recovery-DVD habe ich nämlich mit eigebauten 500 GB Originalfestplatte erstellt, folglich wollte der Recovery-Prozess auch ein Speichermedium mit mindestens 500 GB, damit die Partitionen wiederhergestellt werden können. Na gut, bau ich halt das Original ein und zack, die Wiederherstellung läuft ohne Probleme durch.

Problem 1,5 war dann Windows 7 an sich, diese Update-installier-reboot-Orgie ist nicht auszuhalten.
Gefühlte 15 Stunden später hatte ich ein aktuelles Windows 7 System und konnte die HDD auf die SSD clonen.

Wo wir auch schon zu Problem 2 kommen. Samsung ist so nett, der SSD Norton Ghost 15 beizulegen. Man kann über Symantec sagen was man will, diese Software funktioniert, außer man versucht die Partitionen einer Dell-Installation zu clonen. Wie ich feststellen musste, handelte es sich bei der ersten 100 MB Partition nicht um die, wie bei Windows 7 übliche, system-reservierte (die mit dem ganzen Bootgeraffel), sondern um eine Dell-eigene OEM-Partition, was dazu führte, dass sich C:\ nicht mehr clonen ließ. Also ab in die Datenträgerverwaltung und die Partition von der SSD löschen, denkste, geht nicht. Meiner Ansicht nach, hätte hier Otto Normal-Computerbenutzer die SSD zurückgeschickt. Man kann aber auch ein Linux von einer Live-CD booten, in meinem Fall "Parted Magic".

Hier ganz kurz wie ich vorgegangen bin, um die "fehlerhafte" Partition zu löschen:

  1. Festplatte via USB verbunden
  2. mit dmesgherausgefunden um welches Block-Device es sich halt (hier /dev/sdb)
  3. # fdisk /dev/sdb
    > p # ausgeben der Partitiontabelle
    > d # löschen der Partiton
    > w # schreiben der neuen Partitionstabelle
    # fdisk -l /dev/sdb # überprüfen der Partitionstabelle
  4. # reboot # zurück zum Windows

Wieder im Windows konnte jetzt die "richtige" Partition geclont werden, und zwar C:\, was auch schnell erledigt war. Nun konnte ich die HDD wieder gegen die SSD tauschen, alles wieder zusammenbauen und den Laptop einschalten.

Da begrüßt mich Problem Nummer 3 mit der netten Meldung "BOOTMGR nicht gefunden". Dooh... trotzdem! ich den Master Boot Record mitkopiert habe (das bietet Norton Ghost ebenfalls). Gut das hier noch ein Windows 7 Installationsmedium herumlag, denn damit können Startoptionen, über die Reparaturkonsole gefixt werden.

Gesagt, getan, anschließend ein Reboot, um die Recovery-Odyssee abzuschließen und Windows 7 läuft wieder in der Grundkonfiguration auf der SSD.

Mir ist fraglich wie ein "normaler" Computerbenutzer seinen Rechner reparieren soll, ohne wahnsinnig zu werden, aber vielleicht hilft dieser Beitrag dem einen oder anderen dabei.