ADMIN Magazin Freie Clouds (Vorschau)

NEU! 

Jetzt mit 

ADMIN 

IT-Praxis & Strategie 

DDOS 

Aus und gegen Clouds 

VHDX 

Interessante Features des 

Formats 

LSI-MegaRAID- 

Controller mit SSD 

Freie Clouds 

Automatisieren in Eigenregie 

Praxiserprobt: CloudStack 

AWS-kompatibel: Eucalyptus 

Shooting Star: OpenStack 

Integrator: OpenNebula 

NetBSD auf dem 

Raspberry Pi 

05/2013 

September 

Die ultimative Pentest-Plattform 

Mit extra-Beilage 

“Storage” 

Bareos 

Was der Bacula-Fork kann 

PostgreSQL 9.3 

Neues im kommenden 

Release 

www.admin-magazin.de 

Oracle 12c 

Paradigmenwechsel 

zur Cloud-DB 

D EUR 9,80 

A EUR 10,80 - BeNeLux EUR 11,25 

CH sfr 19,60 - E / I EUR 12,75 

4 196360 509805 05

Sackgasse 

Editorial 

Der Preis des Privaten 

Seit der Antike kennt die Mathematik Mittelwerte. Immer dienten sie der 

Vereinfachung. Wo die Rechen- und Speicherkapazitäten nicht ausreichten, 

um eine große Zahl an Beobachtungen individuell zu betrachten, da 

verwendete man stellvertretend den Mittelwert. Das Ergebnis war damit im 

Einzelfall nicht exakt – diesen Preis musste man zahlen – doch der Durchschnitt 

ist der Wahrheit nahe. 

Nun ist es wie immer: Man tut, was man kann. Und heute kann man eben 

Exabyte-weise Daten speichern, mit Trillionen Operationen pro Sekunde 

berechnen und rund um den Globus in Echtzeit verknüpfen. Das macht den 

Mittelwert überflüssig. Computer erkennen heute in einem unvorstellbaren 

Datenmeer Unterschiede und Gemeinsamkeiten mit der Granularität eines Tropfens. Von der NSA können, 

aber brauchen wir dabei noch nicht einmal reden. Allein der amerikanische Werbevermarkter bluekai etwa 

pflegt Profile von 150 Millionen Amerikanern, die nach bis zu 30 000 verschiedenen Kriterien sortiert sind. 

Heute erkennt man den gut verdienenden männlichen Akademiker zwischen 30 und 40 zuverlässig aus der 

Millionenmasse, der sich für einen Whiskykenner hält, gebrauchte Sportwagen fährt und auf dem Balkon Tomaten 

züchtet. Seine Hotelbuchung macht man automatisch 10 Prozent teurer – wie bei allen, die mit Apple- 

Notebooks surfen. 

Muss wohl auf Dienstreise sein, sagt der Algorithmus, der die Daten aus dem Smart Grid liest, sonst ging Freitag 

Abend immer die Waschmaschine an. Aber die Mails werden aus Bremen abgerufen, also ist er nicht weit. 

Amazon weiß, dass er im Urlaub Schweden-Krimis auf seinem Kindle liest, die Postanschrift deutet auf Eigentumswohnung. 

Neulich hat er Thai-Curry bestellt. Wohl Hobbykoch. Ein Fall für die WMF-Werbung mit den 

teuren Damaszener-Messern. 

Alles hat seinen Preis: Der Mittelwert und sein Gegenstück, der gläserne Mensch, die Hyper-Individualisierung. 

Die bedeutet das „Ende der Privatheit“ (Mark Zuckerberg). Dafür opfern wir die informationelle Selbstbestimmung. 

Dafür begeben wir uns in die Gefahr, von der vorauseilenden Folgsamkeit des Durchleuchteten 

angesteckt zu werden. Oder vom Zynismus – angesichts der unabwendbaren Ver-Öffentlichung alles Privaten. 

Dafür liefern wir uns dem nie verblassenden Gedächtnis der Automaten aus. Dafür lassen wir uns mit unerbetenen 

Informationen überschütten. Dafür schwören wir ungewollt und ohne Not den Offenbarungseid. 

Man kann nichts dagegen tun? Man könnte. Mails verschlüsseln zum Beispiel, beim Surfen immer Anonymisierer 

wie Tor nutzen, sozialen Netzen auch mal fernbleiben. Dann fände man, zumindest hier und da, wieder 

Deckung hinter dem Durchschnitt. Aber auch das hat seinen Preis: Es kostet Bequemlichkeit. 

@ leserbriefe@admin-magazin.de 

www.facebook.com/adminmagazin www.twitter.com/admagz 


Admin 

Ausgabe 05-2013 

3

Service 

ADMIN 

IT-Praxis & Strategie 

Inhalt 

05/2013 

Skalieren und Automatisieren in eigener 

Regie. Alles dazu in unserem Cloud- 

Schwerpunkt ab Seite 22. 

Liebling 

Eucalyptus - die Amazonkompatible 

freie Cloud mit 40Koalas 

kommerziellem Ableger. 

Login 

Security 

Schwerpunkt: Freie Clouds 

8 Vorgelesen 

Bücher über Sicherheitsfragen und erste 

Schritte mit dem Raspberry Pi. 

10 Branchen-News 

Neues von Firmen und Projekten. 

16 Krieg in den Wolken 

Verteilte Denial-of-Service-Attacken aus 

und gegen Clouds. 

28 Griff zu den Sternen 

OpenNebula 

– der große 

Integrator unter 

den freien Cloud- 

Lösungen. 

14 Spaziergang 

Linux automatisch 

verwalten 

mit dem 

Spacewalk- 

Framework. 

Service 

3 Editorial 

4 Inhalt 

6 Heft-CD 

114 Impressum und Vorschau 

Schwerpunkt: Freie Clouds 

22 Bausteinprinzip 

OpenStack: Der Shooting Star unter den 

Clouds. 

34 Gut vernetzt 

Praxiserprobte und bewährte Cloud 

auch für sehr große Installationen. 

40 Koalas Liebling 

Die eigene AWS-kompatible Cloud 

gelingt mit Eucalyptus. 

4 Ausgabe 05-2013 Admin www.admin-magazin.de

Inhalt 

Service 

Einstöpseln 

Paradigmenwechsel mit 

84Zum 

Oracle 12c. 

was recht ist 

Die Praxis der Rechteverwaltung 

bei MS 62Alles, 

Exchange. 

Licht gebracht 

PostgreSQL-Notifications 

94Ans 

mit Perl programmieren. 

Know-how 

48 Datenbank-Tuning 

Zahlreiche interessante neue Features 

im kommenden PostgreSQL 9.3 unter 

der Lupe. 

56 Besser sichern 

Der Bacula- 

Fork Bareos 

kommt mit 

beachtenswerten 

Neuerungen. 

62 Alles, was recht ist 

Die Rechteverwaltung in MS Exchange in 

der Praxis. 

Netzwerk 

68 Leitstandstechnik 

Open-Source-Netzwerkzukunft: Software 

Defined Networks und der Floodlight- 

OpenFlow-Controller. 

Programmieren 

94 Ans Licht gebracht 

PostgreSQL-Notifications mit Perl programmieren. 

Virtualisierung 

76 Moderne Bilder 

Das neue VHDX-Format für virtuelle Festplatten 

im Überblick. 

80 Technisches K.O. 

Wider das 

Udev-Namenschaos: 

So 

lassen sich 

Devices richtig 

und dauerhaft 

benennen. 

Test 

84 Datenbank zum Einstöpseln 

Oracle Database 12c: Cloud Computing 

mit Multitenant-Architektur. 

92 Rennfieber 

Im Test: Beschleunigerkarte Nytro Mega- 

RAID 8110-4i von LSI. 

FreeX 

101 FreeX 

Artikel und Workshops aus der FreeX. 

102 Scharf gewürzt 

Capsicum – mehr 

Sicherheit für 

FreeBSD durch 

Sandboxing. 

108 Netberry 

Anstelle von Linux: NetBSD auf dem 

Raspberry Pi. 

Mehr Infos auf Seite 6 

• Hunderte Pentest-Tools 

• Von den Machern von BackTrack 

• Spezialdistribution für Profis 

www.admin-magazin.de Admin Ausgabe 05-2013 

5

SErvice 

Heft-CD 

Heft-CD 

Auf dem beiliegenden Datenträger finden Sie die neueste 

Version der Pentesting-Distribution Kali Linux. 

◗ Spezielle Linux-Distribution mit dem Ziel, professionelles 

Penetration Testing und Security Auditing zu verzahnen. 

◗ Von den Machern des bekannten BackTrack 

◗ GPG-signierte Pakete und Repositories 

◗ Mehr als 300 Penetration-Test-Tools 

◗ Umfangreicher Wireless-Support 

Legen Sie einfach die CD in das Laufwerk ein und starten 

Sie den Rechner. Möglicherweise müssen Sie noch im BIOS 

die richtige Boot-Reihenfolge einstellen. Danach können Sie 

die Software entweder von der CD booten oder auf dem 

Rechner als Betriebssystem installieren. 

n 

Info 

[1] Kali Linux: [http://www.kali.org] 

CD kaputt? 

Wir schicken Ihnen kostenlos eine 

Ersatz-CD zu, E-Mail genügt: 

info@admin-magazin.de 


Login 

Bücher 

Bücher für Bastler und Philosophen 

Vorgelesen 

Diesen Monat haben wir das Buch eines Krypto-Gurus gelesen und eine 

Einführung in das Basteln mit Linux und dem Minirechner Raspberry Pi. 

Oliver Frommel, Jens-Christoph Brendel 

Der Sicherheitsexperte Bruce Schneier 

hatte in Insiderkreisen lange Zeit einen 

Ruf als führender Kryptografie-Experte. 

Sein Buch „Applied Cryptography“ galt 

lange Zeit als Standardwerk. Heute 

mischt er in der Kryptografie-Welt immer 

noch mit, wie seine Einreichung zum 

Wettbewerb für eine SHA-3-Hashfunktion 

zeigt. Immer öfter beschäftigt er sich aber 

seit einigen Jahren mit Überlegungen zu 

Sicherheitsfragen auf einer gesellschaftlichen 

Ebene, insbesondere seit den Anschlägen 

vom 11. September 2001. Dabei 

vertritt er eine eher gemäßigte Haltung, 

die viele der getroffenen Maßnahmen in 

Frage stellt. 

Auf Vertrauensbasis 

In die gleiche Kerbe schlägt sein Buch 

„Liars and Outliers“, das unter dem Titel 

„Die Kunst des Vertrauens“ nun auf 

deutsch vorliegt. Wörtlich bedeutet der 

Titel „Lügner und Ausreißer“, und um 

gesellschaftlich konformes Verhalten 

und Ausreißer geht es auch in Schneiers 

Werk. Dabei stellt er zunächst verschiedene 

Regulierungsmechanismen vor, die 

dafür sorgen sollen, dass die Gesellschaft 

weitgehend reibungslos funktioniert. Es 

sind dies etwa der moralische Druck, 

der durch die Erziehung vermittelt wird. 

In die gleiche Richtung geht es, wenn 

Individuen zur Aufrechterhaltung ihrer 

Reputation im Sinn der Gesellschaft handeln. 

Tun sie dies nicht freiwillig, kann 

die Gesellschaft durch institutionellen 

Druck (etwa Gesetze) versuchen, dafür 

zu sorgen. Schneier zeigt dabei auch, 

dass dies in manchen Fällen den umgekehrten 

Effekt hat. 

Die Notwendigkeit für Vertrauen als 

Basis für Gesellschaften leitet Schneier 

historisch-evolutionär ab und zieht sogar 

neurologische Argumente dafür heran. 

Warum das in der „realen Welt“ nicht immer 

wie gewünscht funktioniert, versucht 

ein eigenes Kapitel zu erklären. Letztlich 

argumentiert Schneier dafür, das (verlorene?) 

Vertrauen wiederzugewinnen und 

abzuwägen, wieviel „Abweichung“ eine 

Gesellschaft vertragen kann. 

Weil er dabei versucht, seinen Argumenten 

einen soziologisch-wissenschaftlichen 

Anstrich zu geben, ist das Buch etwas 

trockener als es sein müsste und kommt 

immer wieder auf dieselben Aspekte des 

Themas zurück. Alleine die Anmerkungen 

und Literaturhinweise nehmen beinahe 

150 Seiten ein, was aber auch der 

Typografie geschuldet ist. Es ist schade, 

dass „Die Kunst des Vertrauens“ so theoretisch 

ausgefallen ist, denn in Zeiten, in 

denen die Paranoia die Gesellschaft wie 

auch Firmen regiert, könnte ein wenig 

mehr Vertrauen und Gelassenheit nicht 

schaden. 

Kleincomputer ganz groß 

Während das Herumbasteln am Computer 

eher auf dem Rückzug ist, erlebt die 

Beschäftigung mit Westentaschenrechnern 

wie dem Raspberry Pi paradoxerweise 

einen Hype. Also sehen hier auch 

Verlage eine Marktlücke für neue Magazine 

oder Bücher wie den vorliegenden 

Titel „Linux mit Raspberry Pi“ von Christian 

Immler aus dem Franzis-Verlag. 

Das Buch setzt keine Vorkenntnisse voraus 

und begleitet den Leser von den 

allerersten Schritten bis zu mäßig komplexen 

Projekten. Los geht es mit der 

Installation des Linux-Derivats Raspbian, 

auf dem so gut wie alle Experimente des 

Buchs basieren. 

Anschließend wird mit steigendem 

Schwierigkeitsgrad erläutert, wie man Linux 

bedient, Office-Software oder Spiele 

installiert, den Raspberrry Pi als Mediacenter 

nutzen kann oder als WLAN- 

Zugangspunkt. Die Beschreibungen sind 

gut verständlich und mit vielen Bildern 

versehen, sodass es nicht zu schwierig 

sein sollte, sie nachzuvollziehen. 

Was dem Rezensenten aber nicht sofort 

einleuchtete, war die Frage, worin bei 

den vorgestellten Anwendungen nun der 

Reiz liegt. Jeder Aldi-Laptop bringt sie 

Out-of-the-Box mit. Ja, es gibt auch ein 

kurzes Kapitel über Hardwaresteuerung 

via GPIO. Das gipfelt im Beispiel einer 

blinkenden LED. Dafür aber bräuchte 

man im richtigen Leben genau zwei Transistoren, 

Kondensator, Diode und zwei 

Widerstände – aber keinen Rechner. n 

Liars and Outliers 

Bruce Schneier 

Die Kunst des Vertrauens: 

Liars and Outliers 

Deutsche Ausgabe, mitp 2012 

ISBN: 978-3-8266-9216-1 

464 Seiten, 30 Euro 

Raspberry Pi 

Christian Immler: 

Linux mit Raspberry Pi 

1. Auflage, Franzis Verlag 2013 

ISBN: 978-3-645-60263-1 

319 Seiten, 30 Euro 


Login 

News 

+++ neueste Nachrichten immer auf http://www.admin-magazin.de +++++ neueste Nachrichte 

Neue Software und Produkte 

Branchen-News 

Neuer IBM-Mainframe 

IBM hat mit dem zBC 12 

einen neuen Abkömmling 

seiner kleineren 

Business-Familie von 

Mainframes vorgestellt. 

Der neue Rechner, der 

ab einem Einstiegspreis 

von 100 000 Dollar zu 

haben sein wird, steigert 

bei einer Taktfrequenz 

von 4,2 GHz die Leistung 

gegenüber seinem Vorgänger 

um 36 Prozent. 

Für Linux-Anwendungen In die zEC/zBC-12-Mainframe-Familie 

können sogar 62 Prozent investiert IBM dieses Jahr 50 Mio. Dollar. 

mehr virtuelle Server gelauncht 

werden – das alles bei gleichem Energieverbrauch und 

sogar sinkenden Preisen für Spezialprozessoren. 

Das neue System profitiert weiter von etlichen neuen Features, 

von denen einige zuvor bereits in der größeren Enterprise- 

Variante zEC12 eingeführt wurden. Darunter eine spezielle 

Steckkarte für die Datenkompression, zusätzlicher SSD-Speicher 

als RAM-Ersatz, eine Software, die nach 90-tägigem Training 

automatisch abnormes Systemverhalten erkennt und meldet 

sowie eine Erweiterung der 10-GBit-Ethernet-Technologie für 

besonders schnellen Datenaustausch via Remote-DMA. 

Insgesamt konnte IBMs Mainframe-Sparte ihren Umsatz gegenüber 

dem Vergleichsquartal des letzten Jahres um 11 Prozent 

steigern, die installierte Kapazität wuchs sogar um 23 Prozent. 

Dafür investiert IBM allein in diesem Jahr über 50 Millionen 

US-Dollar in die Entwicklung der zEC/zBC-12-Familie und erwartet, 

dass Mainframes in Rechenzentren noch jahrzehntelang 

unverzichtbar bleiben werden – übrigens gerade auch für 

Cloud-Infrastrukturen. 

In eigener Sache 

Der Verlag freut sich, Ihnen mitteilen zu können, dass das ADMIN- 

Magazin ab sofort monatlich erscheint. Wir gehen damit einen Schritt in 

die entgegengesetzte Richtung vieler Mitbewerber: Wir stocken unsere 

Mannschaft auf und verdoppeln die Zahl der jährlichen Ausgaben, um 

Ihnen noch mehr praxisrelevante, verständliche und sofort nützliche 

Informationen für den Admin-Alltag anbieten zu können. Zu diesem 

Schritt hat uns nicht zuletzt das positive Feedback auf die zurückliegenden 

Ausgaben ermuntert. Gerne greifen wir bei der Gestaltung der 

kommenden Hefte auch Ihre Anregungen auf, die Sie uns in einer E-Mail 

an [redaktion@admin‐magazin. de] mitteilen können. 

IDC-Cloud-Studie 2013 

Unter dem Titel „Cloud Computing in Deutschland 2013“ hat 

IDC eine seit einigen Jahren existierende Studienreihe fortgesetzt. 

In diesem Jahr untersucht die Studie, inwieweit die 

Anforderungen der Fachabteilungen und letztlich ein Wandel 

der Geschäftsmodelle das Cloud Computing vorantreibt. Das 

Optimieren der Geschäftsprozesse war jedenfalls unter den 

260 befragten Firmen aller Größenklassen und Branchen das 

meistgenannte Unternehmensziel (28 Prozent). Von einer Cloud 

verspricht man sich dabei schnellere und flexiblere Abläufe, die 

sich einfacher implementieren und mobil nutzen lassen. Aus 

Sicht der IT-Abteilung spielt zusätzlich das Self-Service-Modell 

und die vereinfachte Integration vom neuen Filialen oder Niederlassungen 

eine große Rolle. 

Als größte Herausforderung wird nach wie vor die Sicherheit 

eingestuft. Das zweitgrößte Problem ist die ungenügende Zusammenarbeit 

von IT und Fachbereich. Technische Schwierigkeiten 

tauchen erst an vierter Stelle auf. In der Folge beobachtet 

die Studie auch eine häufige Inanspruchnahme öffentlicher 

Cloud-Services an der IT-Abteilung vorbei, die allerdings erst 

recht Sicherheitsrisiken heraufbeschwört, schlecht unterstützt 

wird und einer Integration der Dienste im Wege steht. Ein Nutzen 

ist so nur kurzfristig ausweisbar. 

Infolge der zunehmenden strategischen Orientierung auf Cloud 

Services und der wachsenden Rolle der Fachbereiche sieht die 

Studie einen Rollenwandel des CIO und der IT-Mannschaft hin 

zu Integratoren und Beratern. 

TKMon vereinfacht Icinga-Administration 

Ein neues Web-Interface soll die Verwaltung des Monitoring- 

Pakets Icinga vereinfachen. Mit Version 1.3 ist das erste stabile 

Release des Icinga-Frontends TKMon erschienen. Die webbasierte 

grafische Benutzeroberfläche soll das Monitoring-Paket 

auch Administratoren zugänglich machen, die wenig Erfahrung 

mit Linux haben. TKMon wurde von der Firma Netways zusammen 

mit der Thomas Krenn AG entwickelt, die für die eigenen 

Server noch ein zusätzliches Add-on anbietet, das im Fehlerfall 

den hauseigenen Support alarmiert. 

Überwacht werden können mit der Kombination aus Icinga 

und TKMon beispielsweise Serverdienste, aber über die IPMI- 

Schnittstelle auch die Hardware selbst. Die Software steht unter 

der GPL zur Verfügung. Mehr Informationen sind unter der 

Adresse [http://www.thomas‐krenn.com/de/oss/tkmon.html] 

zu finden. Für Ubuntu gibt es dort auch Paketquellen, mit denen 

sich TKMon einfach installieren lässt. Für Support und den Austausch 

zwischen Anwendern gibt es eine eigene Mailingliste. 


n immer auf http://www.admin-magazin.de ++++ neueste Nachrichten immer auf http://www. 

News 

Login 

Kaspersky-Malware-Report 

Kaspersky Lab veröffentlicht seinen Malware-Report für das 

zweite Quartal 2013. Für die deutschen Anwender gab es demnach 

zwischen April und Juni 2013 weniger Bedrohungen, dafür 

läuft immer mehr Schadsoftware über Deutschland. Weltweit 

gesehen steigt die Anzahl mobiler Schädlinge stark an. Und die 

virtuelle Währung Bitcoin rückt ebenfalls immer mehr in den 

Fokus von Cyber-Kriminellen. 

Auch im zweiten Quartal 2013 waren Surfer durch Angriffe aus 

dem Internet stark gefährdet. Das Kaspersky Security Network 

(KSN) meldet für den Zeitraum April bis Juni 2013 weltweit 

genau 577 159 385 Attacken von Internet-Ressourcen. Damit 

wurden 35,2 Prozent aller Rechner mindestens einmal während 

des Surfens angegriffen. 

Kaspersky Lab betrachtet für seine Analyse auch die Herkunftsländer 

der Schadprogramme. Und hier gab es im zweiten Quartal 

für Deutschland, das bislang auf Platz vier der Weltrangliste 

schädlicher Quellen landete, eine unrühmliche Veränderung. 

Mit 14,5 Prozent (11,5 im Vorquartal) tauscht Deutschland jetzt 

mit den Niederlanden den dritten Platz. Mit anderen Worten 

kommt inzwischen jedes siebte gefundene Schadprogramm aus 

Deutschland. An der Spitze liegen hier weiter die USA (24,4 

Prozent) und Russland (20,7 Prozent). 

Mobile Geräte geraten immer mehr ins Visier von Cyber-Kriminellen. 

So musste das KSN zwischen April und Juni 29 695 

neue Modifikationen von Schadprogrammen für mobile Geräte 

verzeichnen. Praktisch alle neuen Schädlinge greifen dabei 

Android-Geräte an. Die Experten von Kaspersky Lab zählen 

nicht die einzelnen modifizierten Apps, sondern die sogenannten 

Schadcode-Samples, welche in unterschiedlichen Apps 

zum Einsatz kommen können. Damit warten inzwischen wohl 

deutlich mehr als 100 000 schädliche Apps auf den Download 

durch arglose Anwender. 

Eingeteilt nach Angriffsarten bestehen die im KSN verzeichneten 

mobilen Schadcodes zu 32,3 Prozent aus Backdoors, zu 

27,7 Prozent aus SMS-Trojanern, und zu 23,2 Prozent aus klassischen 

Trojanern. Spionage-Trojaner kommen auf 4,9 Prozent. 

Dass Cyber-Kriminelle mit der Zeit gehen, zeigt auch das Phänomen 

der sich rasch verbreitenden virtuellen Währung Bitcoin. 

Sie ist nicht nur Zahlungsmittel im Internet, sondern lässt 

sich inzwischen auch in reale, harte Währungen konvertieren 

– mit zwar stark schwankenden, in der Tendenz aber steigenden 

Wechselkursen. Inzwischen ist ein Bitcoin bis zu 130 US-Dollar 

wert. 

Die Tatsache, dass sich Bitcoins durch Rechenleistung generieren 

lassen (Bitcoin-Mining), keiner staatlichen Regulierung 

oder Kontrolle unterliegen und sich Zahlungsvorgänge in dieser 

Währung nicht verfolgen lassen, macht sie für Cyberkriminelle 

extrem attraktiv. So deckte Kaspersky Lab im April 2013 eine 

Kampagne auf, bei der die Kommunikationssoftware Skype von 

Cyber-Kriminellen genutzt wurde, um Bitcoin-Mining zu betreiben. 

Über Social-Engineering-Tricks wurden Skype-Anwender 

zur Installation entsprechender Malware veranlasst. Die Kampagne 

erreichte Klickraten von bis zu 2 000 Stück pro Stunde. Die 

auf den missbrauchten Computern generierten Bitcoins wurden 

natürlich an den Account der Kriminellen gesendet. 

Dell aktualisiert sein Switch-OS FTOS 

Dell hat das einheitliche Betriebssystem seiner Netzwerk-Switche 

auf die neue Firmware-Release FTOS 9.2 aktualisiert. Mit 

dem neuen Release sorgt Dell für eine bessere Unterstützung 

der Protokolle VLT (Virtual Link Trunking) und IPv6, eine Optimierung 

der Prozeduren und des Managements der Switche. 

Das neue Betriebssystem FTOS 9.2 unterstützt die Switch- 

Plattformen S4810, S4820T, Z9000 sowie die Blade Switche MXL 

und I/O Aggregator und damit die wichtigsten Komponenten 

der Dell-Active-Fabric-Architektur. 

FTOS 9.2 optimiert außerdem die Integration von iSCSI und unterstützt 

dabei das Monitoring von iSCSI-Sessions in einem VLT- 

Kontext. Das Session-Monitoring wird nun über das gesamte 

VLT-System synchronisiert und bietet eine ausfallsichere Überwachungsfunktion 

über alle VLT-Knoten. Das entsprechende 

Optimierungspaket ist für iSCSI-Storage-Arrays von Dell Equal- 

Logic und Dell Compellent verfügbar. 

Bereits seit der Version 9.1 ist OpenFlow zur Unterstützung 

von SDN-Lösungen in FTOS integriert. Die Interoperabilität der 

Switche S4810, S4820T, Z9000 und MXL mit den Controllern 

von Big Switch ist getestet, sodass Anwender hier auf validierte 

Lösungen mit Applikationen wie „Big Virtual Switch“ und „Big 

Tap“ zurückgreifen können. 

Anzeige 


Admin 


11

Login 

News 

+++ neueste Nachrichten immer auf http://www.admin-magazin.de +++++ neueste Nachrichte 

SMS trotzt App-Boom 

Stetiger Anstieg der SMS-Nutzung in den letzten Jahren. 

Seit Jahren wird der drohende Niedergang der SMS beschrieben, 

ausgelöst unter anderem durch die zunehmende Konkurrenz 

von Smartphone-Apps. Doch die Handy-Kurzmitteilung trotzt 

dem App-Boom. Viele neue Anwendungen für SMS sind in den 

vergangenen Jahren hinzugekommen: etwa die Benachrichtigung 

über Flugverspätungen, den Parkscheinkauf oder die 

Mobile-TAN fürs Online-Banking. Entsprechend steigt die Zahl 

der verschickten Kurznachrichten seit Jahren unaufhörlich. 

2012 wurden in Deutschland über 59 Milliarden SMS versendet, 

ein Plus von fast 8 Prozent gegenüber dem Vorjahr. 2013 werden 

nach BITKOM-Berechnungen voraussichtlich 63 Milliarden 

SMS versendet, eine Steigerung um gut 6 Prozent. Im Schnitt 

verschickt jeder Deutsche mittlerweile 740 SMS pro Jahr. 1999 

waren es erst 44 SMS. 

Allerdings lässt die wirtschaftliche Bedeutung der Kurznachrichten 

nach. So ist der Anteil des Short Messaging Service 

(SMS) und des Mobile Multimedia Service (MMS) am Umsatz 

mit mobilen Datendiensten seit Jahren rückläufig. 2009 lag er 

über 50 Prozent, 2012 nur bei rund 35 Prozent. Viele Kunden 

nutzen Mobilfunkverträge mit einer SMS-Flatrate. Zudem können 

Kurznachrichten netzintern mittlerweile meist kostenlos 

verschickt werden. Fast 70 Prozent aller SMS werden netzintern 

versendet. 

Lange bevor die E-Mail mobil wurde, ermöglichte die SMS, 

Nachrichten unabhängig von Ort und Zeit zu übermitteln. Die 

Vorteile der SMS: Sie funktionierte ab etwa 1994 auf jedem 

Handy, benötigt keine Internetverbindung und keine gesonderte 

Anmeldung. Günstige Preise und die Einführung der Prepaid- 

Karten Ende der 90er Jahre führten zu einem Handy- und damit 

zu einem SMS-Boom. MMS, also Bilder und Filme, können seit 

einigen Jahren ebenfalls per Handy verschickt und empfangen 

werden. 

In Deutschland gibt es rund 113 Millionen Mobilfunkverträge, 

fast 1,4 pro Einwohner. Laut einer repräsentativen Umfrage im 

BITKOM-Auftrag haben 87 Prozent aller Deutschen ab 14 Jahre 

mindestens ein Handy. Dabei geht der Trend klar zu Smartphones: 

Auch ältere Menschen steigen derzeit auf die modernen 

Geräte um. Aktuell besitzen 40 Prozent aller Deutschen ab 14 

Jahren ein Smartphone. 

Tablets werden Allrounder 

Was stellt man mit einem Tablet-Rechner an? Der Branchenverband 

BITKOM erfragte unter 509 Tablet-Nutzern ab 14 Jahren 

Details zur Verwendung der mobilen Geräte. Mehr als jeder 

zweite Tablet-Nutzer (56 Prozent) spielt auf seinem Gerät, 53 

Prozent kaufen damit in Online-Shops ein. Auch zum Betrachten 

von Fotos (48 Prozent), zum Besuch sozialer Netzwerke (46 

Prozent) und zum Surfen parallel zum Fernsehen als sogenannter 

Second Screen (46 Prozent) werden die Geräte eingesetzt. 

Zudem liest mehr als jeder dritte Tablet-Nutzer (37 Prozent) 

auf seinem Gerät Zeitschriften und Zeitungen, jeder vierte 

(24 Prozent) bearbeitet darauf Dokumente. Zudem setzt jeder 

Neunte (11 Prozent) es als Fernbedienung für TV-Geräte oder 

Musikanlagen ein. 

Am häufigsten werden die flachen Computer mit Touch-Display 

allerdings zum Schreiben von E-Mails genutzt (64 Prozent der 

Tablet-Nutzer), am zweithäufigsten werden sie zum Surfen 

im Internet (60 Prozent) verwendet. „Tablet-Computer sind 

Alleskönner. Sie werden für eine breite Palette an Aufgaben 

genutzt“, sagt Michael Schidlack, BITKOM-Experte für Unterhaltungselektronik. 

Zwischen den Altersklassen gibt es deutliche Unterschiede. 

Jüngere Tablet-Nutzer zwischen 20 und 29 Jahren setzen es 

häufiger für den Medienkonsum ein. 71 Prozent von ihnen 

nutzen ihr Gerät zum Spielen von Gaming-Apps. Bei den 50- 

bis 59-Jährigen sind es dagegen nur 47 Prozent. Ähnlich sieht 

es auch beim Musikhören und Filmeschauen aus. Jeder zweite 

der 20- bis 29-Jährigen (55 Prozent) spielt auf seinem Tablet- 

Computer Musik ab, 42 Prozent lassen darauf Filme und Serien 

laufen. Bei den 50- bis 59-Jährigen sind es dagegen nur 35 

beziehungsweise 17 Prozent. Schidlack: „Für viele jüngere 

Menschen ist der Tablet-Computer zur zentralen Drehscheibe 

für den Medienkonsum geworden. Die Möglichkeit, den Touch- 

Rechner immer mitnehmen zu können, sowie die eingebauten 

hochauflösenden Bildschirme und eine stetig wachsende Zahl 

von Apps aus dem Medienbereich machen ihn als Unterhaltungsgerät 

zunehmend beliebter.“ 

Die Nachfrage nach Tablet-Computern steigt weiterhin sehr 

stark. In diesem Jahr soll der Absatz die 5-Millionen-Marke 

in Deutschland durchbrechen. 2012 wurden 4,4 Millionen der 

flachen Computer mit Touch-Display verkauft. Mittlerweile besitzt 

jeder zehnte Deutsche einen Tablet-Computer. Zudem fällt 

der Durchschnittspreis der Geräte. 2011 wurden im Schnitt 575 

Euro für ein Tablet ausgegeben. Im vergangenen Jahr waren es 

nur noch 475 Euro. . 


News 

Login 

n immer auf http://www.admin-magazin.de ++++ neueste Nachrichten immer auf http://www. 

GlusterFS 3.4 verbessert 

Das verteilte Linux-Dateisystem GlusterFS wurde von den Entwicklern 

in der neuesten Version 3.4 mit einigen nützlichen 

Features ausgestattet. So stellt GlusterFS virtuellen Qemu-Maschinen 

nun Storage über die Libgfapi zur Verfügung, was den 

Zugriff erheblich beschleunigt. Auch zwei andere Änderungen 

verbessern die Performance bei der Verwendung von GlusterFS 

als Storage für virtuelle Maschinen. 

Ebenso wurde die synchrone Replizierung im neuen Release beschleunigt. 

Ressource-Agenten ermöglichen es, GlusterFS in eine 

Cluster-Umgebung zu integrieren, die kompatibel zum Open 

Cluster Framework (OCF) ist – wie etwa Pacemaker. Schließlich 

können Anwender und Programmierer nun Posix-ACLs verwenden, 

wenn sie GlusterFS-Speicher über NFSv3 anbieten. 

CoreOS: minimalistisches Linux 

Unter dem Namen „CoreOS“ arbeiten Entwickler nach eigenen 

Worten an einem „Linux für die Container-Welt“. Dabei handelt 

es sich um eine extrem abgespeckte Linux-Variante, die im wesentlichen 

nur aus einem Kernel und Systemd besteht. Darüber 

hinaus soll die Root-Partition nur lesbar sein, um die Konsistenz 

des Systems zu gewährleisten. 

Anwendungen lassen sich auf diesem System in Linux-Containern 

mit LXC installieren, womit die Isolation der damit 

realisierten Dienste gewährleistet ist. Als Management-Software 

für die Container setzen die CoreOS-Entwickler auf das ebenfalls 

recht neue Docker. Eine Komponente namens Etcd sorgt 

dafür, dass sich die Konfiguration über mehrere Server hinweg 

verteilen lässt. Darüber hinaus unterstützt Etcd auch Service 

Discovery. 

Wer CoreOS ausprobieren möchte, kann sich auf der Website 

für eine Alpha-Version anmelden, die vermutlich die Distribution 

fertiger Images beinhaltet, die auf einer Vielzahl von 

Plattformen betrieben werden können, nämlich Amazon EC2, 

Rackspace Cloud, Digital Ocean, Linode, Azure, Softlayer, physische 

Server von Hetzner, OVH, OpenStack, Virtualbox, KVM, 

Xen, VMware und echter Hardware. 

Microsoft veröffentlicht HTTP-2.0-Server 

Für Tests bietet Microsoft den Quellcode eines Webservers an, 

der wesentliche Teile des kommenden HTTP-2.0-Standards implementiert. 

Er basiert auf dem Katana-Projekt, im Rahmen dessen 

Microsoft einen in C# geschriebenen Web-Stack unter einer 

Open-Source-Lizenz anbietet. Der Code ist unter der Adresse 

[https://github.com/MSOpenTech/http2‐katana] zu finden. 

Implementiert sind bisher die Features Header Compression, 

Stream Multiplexing und Steuerungsmechanismen wie ALPN 

(Application Layer Protocol Negotiation) und HTTP-Upgrade. 

Server Push und Flow Control fehlen bislang noch. 

Um Clients zu testen, bietet Microsoft unter den folgenden 

Adressen auch laufende Server im Netz an: 

HTTP: [http://http2katanatest.cloudapp.net:8080] 

HTTPS mit ALPN: [https://http2katanatest.cloudapp. 

net:8443] 

Eine weitere Implementation des Drafts in der Programmiersprache 

C hat Tatsuhiro Tsujikawa vorgelegt. Sie ist unter [https:// 

github.com/tatsuhiro‐t/nghttp2] zu finden. 

MySQL Workbench aktualisiert 

MySQL Workbench ist ein umfangreiches Visualisierungswerkzeug, 

das Datenmodellierung, SQL-Entwicklung und Administration 

von Server-Konfiguration, Benutzerkontenverwaltung, 

Migration und weitere Verwaltungsfunktionen in nur einem 

Tool vereint. Nun erschien es in einer neuen Version. Die neugestaltete 

GUI beinhaltet einen modernisierten Home Screen 

mit optimierter Benutzeroberfläche. Dabei erlaubt eine vertikale 

Ergebnisanzeige nun die Darstellung von Ergebnissen als 

Spalten-Wert-Paar; ideal für Abfragen mit vielen Spalten, aber 

wenig Zeilen. Eine verbesserte Server-Status-Anzeige stellt nun 

Status und Konfiguration übersichtlicher dar. 

MySQL Workbench 6.0 Enterprise Edition bietet zusätzliche 

Features, unter anderem MySQL Enterprise Backup GUI, welches 

nun Setup, Durchführung und Planung von Backup-Operationen 

erlaubt. MySQL Audit Log Inspector erlaubt Nutzern 

Audit Daten von MySQL Enterprise Audit zu durchsuchen. 


Admin 


13

Login 

Admin-Story 

© NASA 

Linux-Systeme verwalten mit Spacewalk 

Spaziergang 

Mit dem Spacewalk-Server existiert ein umfangreiches Framework zum 

Verwalten von Linux-Systemen. Geht es dann um die Automatisierung von 

Aufgaben, stehen die XML-RPC-basierte API und das Spacecmd-Tool zur 

Auswahl. Dieser Artikel stellt die beiden Varianten gegenüber. Thorsten Scherf 

Das Management-Framework Spacewalk 

war bereits Thema in einer früherer 

ADMIN-Ausgabe [1]. Ich möchte 

daher an dieser Stelle einmal von der 

bekannten Weboberfläche weggehen und 

stattdessen skriptbasierte Lösungen aufzeigen, 

um Aufgaben zu erledigen. Zum 

einen existiert hier mit der Spacewalk- 

API eine sehr umfangreiche Variante, um 

nur alle erdenklichen Aufgaben auf dem 

Server durchzuführen. Allerdings muss 

der Admin teilweise doch recht komplexe 

Skript-Konstrukte bauen, wenn es 

darum geht, umfangreiche Arbeiten auf 

dem Server zu erledigen. Welche Sprache 

hierfür zum Einsatz kommt, ist erstmal 

nebensächlich, wichtig ist lediglich, dass 

sie XML-RPC-Aufrufe unterstützt. Überwiegend 

wird man hier jedoch Perl- und 

Python-Skripte vorfinden. 

Das Tool Spacecmd greift ebenfalls auf 

die XML-RPC-basierte API des Spacewalk-Servers 

zurück, kapselt deren Aufrufe 

aber in handliche Optionen. Das Tool 

wird entweder im interaktiven Modus 

gestartet und nimmt dann entsprechende 

Anweisungen entgegen oder aber man 

übergibt alle notwendigen Optionen und 

kann das Tool somit auch in eigenen 

Bash-Skripten verwenden. Mancher Admin 

hantiert doch lieber mit der Bash 

als mit ellenlangen Python- oder Perl- 

Programmen. Nachfolgend werden die 

beiden Varianten gegenübergestellt und 

miteinander verglichen. 

Spacewalk-API 

Üblicherweise erfordert jedes Skript, das 

mit der Spacewalk-API sprechen möchte, 

ein Client- und ein Session-Objekt. Das 

Session-Objekt dient zur Authentifizierung 

auf dem Server und ist bei jedem 

Methoden-Aufruf mit anzugeben. Damit 

nun nicht in jedem Skript der Benutzername 

und das Passwort für den Zugriff 

auf den Server mit angegeben werden 

muss, bietet es sich an, ein Modul zu 

schreiben und dieses in die jeweiligen 

Skripte einzubinden. 

Listing 1 zeigt ein Beispiel für ein solches 

Modul für die Skriptsprache Perl. Dieses 

Modul speichert man entweder im Ordner 

mit den API-Skripten ab oder legt es 

besser noch in das Verzeichnis der Perl- 

Module. Welche das sind, zeigt beispielsweise 

der Aufruf von »perl ‐V« an. Das 

Modul erfordert eine Konfigura tionsdatei 

»/etc/sysconfig/spacewalk_api.conf«, in 

der, mit Leerzeichen getrennt, der Spacewalk-Server 

sowie der Benutzername 

und Passwort für den Zugriff auf den 

Server aufgeführt sind. Über die Angabe 

von »use RHNSession« im Header eines 

API-Skriptes kann man nun auf dieses 

Modul zurückgreifen. 

Das Skript in Listing 2 zeigt ein einfaches 

Beispiel. Es bindet das soeben erzeugte 

Modul wie beschrieben ein und ruft die 

Methode »channel.listSoftwareChannels« 

Listing 1: »RHNSession.pm« 

01 package RHNSession; 

02 

03 use strict; 

04 use Exporter; 

05 use vars qw($VERSION @ISA @EXPORT @EXPORT_OK %EXPORT_TAGS); 

06 

07 $VERSION = 1.0; 

08 @ISA = qw(Exporter); 

09 @EXPORT = (); 

10 @EXPORT_OK = qw(Session); 

11 %EXPORT_TAGS = ( DEFAULT => [qw(&Session)] ); 

12 

13 sub Session { 

14 open(IN, "/etc/sysconfig/spacewalk_api.conf") or die "Spacewalk‐API 

Config nicht gefunden: $!"; 

15 $_ = ; 

16 my ($server, $user, $pass) = (split); 

17 close(IN); 

18 

19 my $client = new Frontier::Client(url => "http://$server/rpc/api"); 

20 my $session = $client‐>call('auth.login', $user, $pass); 

21 

22 return ($client, $session); 

23 } 


Admin-Story 

Login 

Abbildung 1: Der Spacewalk-Server bietet jede Menge XML-RPCbasierte 

Methoden zur Automatisierung von Aufgaben an. 

auf dem Spacewalk-Server auf, die dann 

eine Liste der verfügbaren Software- 

Kanäle auf dem Bildschirm ausgibt – 

zugegebenermaßen ein recht einfaches 

Skript. 

Mit der Spacewalk-API lassen sich aber 

natürlich auch komplexere Aufgaben 

erledigen, wie beispielsweise das Erzeugen 

oder Modifizieren von Softwareund 

Konfigurations-Kanälen, Kickstart- 

Dateien oder Systemgruppen. Eine Liste 

der zur Verfügung stehenden Methoden 

erhält man unter der URL [http:// 

spacewalk‐server/ rhn/ apidoc/] (Abbildung 

1). Hier finden sich auch einige Beispiele 

für Perl- und Python-Skripte, die 

auf die Spacewalk-API zurückgreifen. 

Spacecmd 

Man kann sich vorstellen, dass je nach 

Anforderung die Skripte recht umfangreich 

werden. Das Tool »spacecmd« verbirgt 

diese Komplexität und macht es 

auch Spacewalk-Einsteigern recht leicht, 

komplexe Aufgaben über einfache Bash- 

Skripte zu automatisieren. Das Tool ist 

mittlerweile Teil der offiziellen Spacewalk-Quellen 

und steht somit über die 

Website [2] zum Download bereit. 

Beim Aufruf von Spacecmd werden die 

beiden Konfigurationsdateien »/etc/ 

spacecmd.conf« und »~/.spacecmd/ 

config ausgewertet«. Hier lassen sich Ser- 

ver- und Authentifizierungs- 

Informationen hinterlegen: 

[spacecmd] 

server=sat.virt.tuxgeek.de 

username=admin 

password=pw 

nossl=0 

Im interaktiven Modus bietet 

das Tool eine Tab Completion 

an, was sehr hilfreich ist, 

wenn man nach einer Methode 

sucht, deren Namen 

aber nicht im Kopf hat. 

Um nun das Beispiel aus Listing 

2 mit dem Spacewalk- 

Tool zu implementieren, reicht 

es aus, im interaktiven Modus 

einfach das Kommando 

»softwarechannel_list« einzugeben. 

Das Ergebnis wird 

identisch mit dem des Perl- 

Skriptes sein. Lediglich der 

Aufwand für die Entwicklung 

des Skriptes ist geringer. 

Für komplexere Aufgaben bietet es sich 

an, die Spacecmd-Aufrufe in einem Bash- 

Skript zusammenzuführen. Listing 3 

zeigt ein einfaches Beispiel, das herausbekommt, 

welche Systeme auf welche 

Software-Kanäle des Spacewalk-Servers 

zurückgreifen. Das Ergebnis des ersten 

Spacecmd-Aufrufs wird dabei in der Variablen 

»CHANNELS« gespeichert. Anschließend 

iteriert man durch die Liste 

und übergibt jedes Element – in der Variablen 

»c« gespeichert – an den zweiten 

Spacecmd-Aufruf. Alles weitere ist nur 

noch Kosmetik. 

Fazit 

Nahezu alle Aufgaben des Spacewalk- 

Servers lassen sich mit beiden hier vorgestellen 

Varianten automatisieren. Wer 

weniger komplexe Skripte haben möchte, 

greift dabei bevorzugt auf Spacecmd zurück. 

Ich würde den direkten Zugriff auf 

Der Autor 

Thorsten Scherf arbeitet als Principal Consultant 

für Red Hat EMEA. Er ist oft 

als Vortragender auf Konferenzen 

anzutreffen. Wenn 

ihm neben der Arbeit noch 

Zeit bleibt, nimmt er gerne 

an Marathonläufen teil. 

die Spacewalk-API mittels Perl oder Python 

nur dann empfehlen, wenn umfangreiche 

Aufgaben anstehen. 

Sollte eine Methode über die API zur 

Verfügung stehen, aber noch nicht im 

Spacecmd-Tool implementiert sein, hilft 

entweder eine freundliche Anfrage auf 

der Mailingliste des Projekts [3] oder 

man legt selbst Hand an. Mittels »git 

clone git://git.fedorahosted.org/spacewalk.git« 

holt man sich die Quellen des 

Spacewalk-Servers auf den eigenen Rechner. 

Im Unterverzeichnis »spacecmd/src/ 

lib«befinden sich die einzelnen Module, 

welche die API-Methoden implementieren. 

(ofr) 

n 

Infos 

[1] Thorsten Scherf, Linux-Systeme mit Spacewalk 

verwalten, ADMIN 4/2010: [http:// 

www. admin‐magazin. de/ Das‐Heft/ 2010/ 04/ 

Linux‐Systeme‐mit‐Spacewalk‐verwalten] 

[2] Spacecmd-Repository: [http:// yum. 

spacewalkproject. org/ nightly/ Fedora/] 

[3] Mailingliste: [https:// www. redhat. com/ 

mailman/ listinfo/ spacewalk‐list] 

Listing 3: »SystemToSWChannel.sh« 

01 #!/bin/sh 

02 

Listing 2: »listSoftwareChannels.pl« 

01 #!/usr/bin/perl 

02 

03 use strict; 

04 use Frontier::Client; 

05 use RHNSession; 

06 

07 my ($client, $session) = RHNSession::Session; 

08 

09 my $channels = $client‐>call('channel. 

listSoftwareChannels', $session); 

10 

11 foreach my $channel (@$channels) { 

12 print $channel‐>{'label'} . "\n"; 

13 } 

14 

15 $client‐>call('auth.logout', $session); 

03 CHANNELS=$(spacecmd ‐‐ softwarechannel_list 2>/dev/ 

null) 

04 

05 for c in $CHANNELS 

06 do 

07 echo "Systeme die auf den Channel $c zurückgreifen:" 

08 spacecmd ‐‐ softwarechannel_listsystems $c 2>/dev/ 

null 

09 echo 

10 done 


Admin 


15

Security 

DDoS 

© jager, 123RF 

Verteilte Denial-of-Service-Attacken aus und gegen Clouds 

Krieg in den Wolken 

Seit Monaten verschärfen sich DDoS-Attacken mit besonders raffinierten Methoden. Die Angreifer bedienen sich 

der Cloud und zielen auf sie. Ihre skalierbare Architektur bietet dann nicht nur keinen Schutz, sondern ermöglicht 

es dem Angreifer im Gegenteil, konventionelle Abwehrmechanismen aufzuheben. Dieser Beitrag erklärt, wie 

eine DDoS-Attacke in der Wolke zustande kommt und wie man sich verteidigt. Filipe Martins und Anna Kobylinska 

Eine rekordverdächtige DDoS-Attacke 

auf Spamhaus [1] (Abbildung 1), einen 

Verwalter von Real-Time-DNS-Blacklists, 

legte im März dieses Jahres mit einer 

Datenflut von bis zu 300 GBit/s Teile 

des Internets lahm. Wer grundlos auf 

eine solche schwarze Liste gelangt war, 

konnte während des Angriffs nicht mehr 

verlangen, von ihr gelöscht zu werden. 

Unschuldige Domains blieben so gesperrt 

und viele legitime E-Mails konnten nicht 

zugestellt werden. 

Erst nachdem Spamhaus den kalifornischen 

Cloud-Sicherheitsanbieter Cloud- 

Flare [2] mit der Verteidigung seiner 

Infrastruktur beauftragt hatte, konnte 

sich der Dienst online zurückmelden. 

Doch die Angreifer ließen nicht locker. 

Eine Woche später, am 23. März, brach 

schließlich LINX, einer der Backbone-Betreiber 

des Internets, unter einer Gesamtdatenlast 

von 1,5 Terabit pro Sekunde 

zusammen. 

Andere Beispiele: Ab Sonntag, dem 

10. März 2013, hat eine DDoS-Attacke 

die Webseite des deutschen Portals Finanzwelt 

(Abbildung 2) [3] für mehrere 

Tage außer Betrieb genommen. Im Herbst 

letzten Jahres fiel die Internet-Infrastruktur 

des deutschen Stromnetzbetreibers 

50Hertz kurzfristig der DDoS-Attacke 

eines Botnets zum Opfer. Im selben Zeitraum 

mussten sich mehrere US-Finanzhäuser 

gegen DDoS-Attacken verteidigen. 

Beim DDoS-Angriff auf das kalifornische 

Geldinstitut Bank of the West konnten die 

Täter das entstandene Chaos nutzen, um 

völlig unbemerkt nahezu eine Milliarde 

US-Dollar (700 Millionen Euro) von den 

Accounts ahnungsloser Bankkunden zu 

entwenden. 

DDoS heute: Viele Vektoren 

und DNS-verstärkt 

Heutige DDoS-Attacken in der Wolke 

haben mit der chaotischen Datenflut einer 

konventionellen DDoS-Attacke der 

vergangenen Jahre nur noch wenig gemeinsam. 

Laut einer Studie von Arbor 

Networks lag eine typische DDoS-Attacke 


DDoS 

Security 

Abbildung 1: Spamhaus, eine Organisation zur Spam-Bekämpfung durch schwarze 

Listen, fiel im März dieses Jahres der größten DDoS-Attacke der Internet- 

Geschichte zum Opfer. 

Bei reflexiven DNS-Attacken sendet der 

Angreifer seine DNS-Anfragen nicht diim 

vergangenen Jahr bei einer Bitrate 

von 1,48 GBit/s. Bei nahezu jedem zweiten 

Vorfall im Jahr 2012 handelte es sich 

um sorgfältig inszenierte Multi-Vektor- 

Angriffe, die zum Teil ununterbrochen 

mehrere Wochen lang anhielten. 

Multi-Vektor-Angriffe adressieren abwechselnd 

und systematisch verschiedene 

Schwächen der Infrastruktur des 

Opfers und terrorisieren den Geschädigten 

mit immer neuen DDoS-Offensiven. 

Unterläuft dem Angegriffenen im Eifer 

des Gefechts dann ein Fehler in der Konfiguration, 

kann das schnell fatale Folgen 

haben. 

Eine besonders beliebte Form von DDoS- 

Attacken in der Wolke nutzt die Schwächen 

des DNS-Systems aus: die DNS- 

Flut-Attacke. Angreifer erzeugen dabei 

DNS-Pakete und senden diese über das 

UDP-Protokoll an DNS-Server, um sie mit 

Anfragen zu überfluten und ihre Rechenzeit-Ressourcen 

aufzubrauchen. Diese 

Angriffsmethode kommt sehr oft vor, da 

sie relativ einfach umzusetzen ist, eine 

enorme Hebelwirkung haben kann und 

Angreifern erlaubt, ihre Identität hinter 

Dritten zu verstecken. 

DNS-Server sind 

als Auskunftsdienst 

ausgelegt. 

Einige Anbieter 

betreiben ihre 

DNS-Server als 

sogenannte Open- 

DNS-Resolver; in 

dieser Konfiguration 

werden auch 

rekursive Anfragen 

der Namensauflösung 

von außerhalb 

der jeweiligen 

administrativen 

Domain beantwortet. 

Anfragen, 

die sich auf große 

Bereiche des Internets 

beziehen, können dadurch massive 

Datenvolumen zu Tage fördern. Laut 

des Geschäftsführers von CloudFlare, 

Matthew Prince, wurde die spektakuläre 

DDoS-Attacke auf Spamhaus durch lediglich 

36 Byte große Datenpakete getrieben, 

die pro Anfrage eine jeweils 3000 Byte 

lange Antwort auslösten. 

Während ein gewöhnlicher Desktop-PC 

von der Stange circa 1 000 DNS-Anfragen 

pro Sekunde erzeugen kann, geht ein einzelner 

DNS-Server üblicherweise bei ungefähr 

10 000 DNS-Anfragen pro Sekunde 

schon mal in die Knie. Bricht ein DNS- 

Server unter Last zusammen, sind davon 

gleich mehrere Hosts schwer betroffen. 

Zudem verlassen sich fast alle Domain- 

Besitzer auf das technische Minimum 

von genau zwei DNS-Servern und da sie 

die Anforderung an die geografische Dispersion 

völlig außer acht lassen, sind bei 

dem geringsten DDoS-Befall gleich alle 

Dienste außer Betrieb. 

Reflexive DNS-Attacken 

rekt an das Opfer, sondern an Dritte, die 

gar nicht das eigentliche Ziel des DNS- 

Angriffs sind. Er fälscht hierbei die IP- 

Adresse der Quelle der DNS-Anfrage so, 

dass sie der des Opfers entspricht. Wenn 

die angesprochenen Hosts nun ordnungsgemäß 

auf die Anfrage reagieren, 

richten sie ihre Antwort an die gefälschte 

Quelladresse und überfluten damit das 

eigentliche Angriffsziel mit Daten. So 

macht sich der reflexive DNS-Angriff 

den immensen Verstärkungsfaktor des 

DNS-Systems zu Nutze, denn die DNS- 

Antwort ist in der Regel drei- bis zehnmal 

umfangreicher als die auslösende DNS- 

Anfrage selbst. 

Bei einer reflexiven DNS-Attacke kann 

der Betroffene auch dann zum Opfer werden, 

wenn er gar nicht über eigene DNS- 

Server verfügt. Die Angreifer brauchen 

aber seine Internetbandbreite auf und/ 

oder setzen die Firewall außer Gefecht. 

Bei reflexiven DNS-Angriffen in der 

Wolke unterscheidet man zwischen drei 

Versionen mit jeweils verschiedenen 

Verstärkungsstufen: native oder selektive 

Angriffe und ausgefeilte Angriffe. 

Im Falle von reflexiven DNS-Angriffen 

vom Typ nativ sind die Antwortpakete 

deutlich umfangreicher als die Anfrage- 

Pakete. Der Verstärkungsfaktor beträgt 

hier lediglich drei bis vier. 

Eine selektive reflexive DNS-Attacke 

nutzt den Umstand, dass DNS-Antworten 

keine einheitliche Länge besitzen. Manche 

DNS-Antworten fallen recht kurz aus, 

Anzeige 

Was ist DDoS? 

Bei DDoS (Distributed Denial of Service) handelt 

es sich um eine verteilte Attacke, die mithilfe 

von Anfragen aus einer Vielzahl von Quellen den 

betroffenen Dienst lahmlegt. 

Volumetrische DDoS-Attacken generieren eine 

Datenflut, mit der sie die Bandbreite ausschöpfen 

und die Datenübertragung stilllegen. TCP- 

State-Exhaustion-Attacken nehmen sich die Verbindungsstatus-Tabellen 

von Firewalls vor, um 

diese Elemente der Infrastruktur außer Gefecht 

zu setzen und das nun nicht mehr geschützte 

Netzwerk zu unterwandern. Angriffe auf der Applikationsebene 

adressieren treffsicher Schwächen 

der betroffenen Software-Architektur mit 

dem geringstmöglichen Datenaufkommen, das 

gerade einen Schaden verursacht. 


Admin 


17

Security 

DDoS 

Abbildung 2: Die Webseite dieses deutschen Finanzportals war im März aufgrund 

einer DDoS-Attacke mehrere Tage nicht erreichbar. 

andere sind wiederum um ein Vielfaches 

länger. Bei dieser Angriffsmethode identifiziert 

der Angreifer zuerst die Domains, 

die eine besonders lange DNS-Antwort 

zurückliefern. Das resultiert typischerweise 

in einer bis zu zehnfachen Verstärkung. 

Im Falle von Spamhaus konnten die Angreifer 

allerdings durch das Anfragen von 

Informationen über die Domain »ripe. 

net« einen Verstärkungsfaktor von 100 

zustande bringen. Weil sie die Attacke 

mit Hilfe eines ferngesteuerten Botnets 

über sagenhafte 30 000 DNS-Resolver verteilt 

auf Spamhaus richten konnten, ist 

dies keinem der einzelnen Betreiber der 

DNS-Server aufgefallen. 

Das Repertoire von reflexiven DNS-Attacken 

ist damit noch nicht ausgeschöpft. 

Einige Angreifer nutzen selbsterstellte 

Top-Level-Domains, die einzig und allein 

dazu dienen, ausgefeilte DNS-Attacken 

auszuführen. Diese Domains erlauben 

es den Tätern, DNS-Antworten zu missbrauchen, 

die einen bis zu 100-fachen 

Verstärkungsfaktor zu Tage fördern. 

Rekursive und DNS- 

Attacken mit Datenmüll 

Die rekursiven DNS-Attacken machen 

sich zunutze, dass ein DNS-Server, der 

auf eine Anfrage keine Auskunft erteilen 

kann, versucht, die fehlenden Informationen 

von anderen DNS-Servern anzufordern. 

Der Server muss dabei vergleichsweise 

viele Ressourcen 

reservieren 

(CPU-Zyklen, 

Arbeitsspeicher 

und Bandbreite), 

um diese Anfragen 

weiterzuleiten und 

zu verwalten. Indem 

ein Angreifer 

Informationen zu 

nicht existierende 

DNS-Einträgen 

anfordert, kann er 

einen DNS-Server 

leicht überlasten 

und seinen Ausfall 

verursachen. 

Eine DNS-Attacke 

mit Datenmüll 

überflutet den 

DNS-Server durch 

das Zustellen großer Datenmengen an 

den UDP-Port 53 (seltener UDP-Port 80). 

In jedem Szenario mit der Ausnahme 

eines DNS-Servers besteht für das Opfer 

die Möglichkeit, den betroffenen Port zu 

sperren. Der DNS-Server kann aber nicht 

den Port sperren, über den er seinen 

Dienst anbietet. 

Anycast zur Verteidigung 

gegen DNS-Fluten 

Bei der Verteidigung von Spamhaus hat 

CloudFlare, der zuständige Anbieter des 

Content Delivery Networks (CDN), seinen 

Kunden mit einem geschickten Trick 

aus der Affäre gezogen: Mit Hilfe der Adressierungsart 

»Anycast«, mit Lastverteilern 

und einem eigenen CDN mit Knoten 

in insgesamt 23 Datenzentren ließ sich 

die Datenflut in der Wolke abfangen. 

Die häufigste Adressierungsart im Internet 

ist »Unicast«, bei der eine eindeutige 

IP-Adresse zu genau einem Host gehört. 

Bei Anycast wird dagegen ein und dieselbe 

IP-Adresse mehreren Hosts zugewiesen 

und der Router stellt die Datenpakete 

an denjenigen Host mit der Zieladresse 

zu, der geografisch am nächsten 

liegt. Dadurch nehmen die Datenpakete 

immer den kürzesten Weg und landen 

dabei nicht auf einem, sondern auf einer 

Vielzahl von Servern. Im Falle von Spamhaus 

streute CloudFlare die betroffenen 

IP-Adressen auf diese Weise über 23 verschiedene 

Datenzentren. Dort wurde der 

auf das jeweilige Datenzentrum entfallende 

Bruchteil der Anfragen erst einmal 

nach verschiedenen Kriterien gefiltert. 

Die Datenpakete wurden schließlich erst 

dann an Spamhaus weitergeleitet, nachdem 

sie Tests ihrer Legitimität bestanden 

hatten. So konnte CloudFlare die Spreu 

vom Weizen trennen und die bösartigen 

Anfragen verwerfen. 

CloudFlare treibt die Anycast-Idee dabei 

auf die Spitze und weist ein und dieselbe 

IP-Adresse allen seinen Kunden zu. Diese 

Strategie, die der Anbieter auf den Namen 

Global-Anycast-DNS taufte, macht 

es den Angreifern unmöglich, auf ihr Ziel 

zu fokussieren. Lastverteiler leiten die 

Anfragen immer an das nächstgelegene 

Datenzentrum mit freien Kapazitäten 

um. So kann kein einzelnes Element der 

Cloud-Infrastruktur auf Grund der Datenflut 

zusammenbrechen (kein Single Point 

of Failure). 

Global-Anycast-DNS ist bei CoudFlare bereits 

im Umfang des Gratis-Basis-Abonnements 

enthalten. Ähnliche Dienste 

wie CloudFlare haben auch andere CDN- 

Anbieter kostenpflichtig im Programm, 

darunter Akamai, neuStar, OpenDNS und 

Prolexic. 

SMURF, ACK-Reflection- und 

SYN-Flood-Attacken 

In einer SMURF-Attacke sendet der Angreifer 

ICMP-Pakete mit einer gefälschten 

Absender-IP, die auf das Opfer verweist, 

an Dritte. Die Angreifer nehmen 

sich dabei einen Router vor, der für die 

Weiterleitung von ICMP-Anfragen an andere 

Geräte verantwortlich ist. Indem die 

Täter die zugehörige Broadcast-Adresse 

(X.X.X.255) ansprechen, können sie alle 

Geräte in dem jeweiligen Netzwerk hinter 

dem Router erreichen. Mangels eines 

Handshake-Verfahrens beim Verbindungsaufbau 

können Empfänger legitime 

von nicht legitimen Anfragen nicht unterscheiden, 

und indem sie auf die ICMP- 

Anfrage vorschriftsmäßig antworten, 

bombardieren sie mit ihren IP-Paketen 

das Opfer. Um eine solche Attacke zu 

verhindern, genügt es, die Weiterleitung 

der ICMP-Anfragen durch die betroffenen 

Router zu unterbinden. 

Eine ACK-Reflection-Attacke macht sich 

den sogenannten TCP-Drei-Wege-Handschlag 

zunutze. Ein TCP-Client initiiert 


DDoS 

Security 

den Verbindungsaufbau durch das Abschicken 

eines SYN-Pakets. Beim Empfang 

dieses Pakets an einem offenen Port 

antwortet der Server mit dem SYN-/ACK- 

Paket, um den Verbindungsaufbau zu akzeptieren. 

Er reserviert Arbeitsspeicher, 

schreibt in die Logs und wartet auf die 

abschließende ACK-Antwort des Kommunikationspartners, 

die den Empfang der 

Nachricht bestätigen soll. Bei einer ACK- 

Reflection-Attacke ist die Absender-IP 

in der SYN-Anfrage allerdings gefälscht, 

sodass der Server seine Antwort an den 

falschen Adressaten sendet, nämlich an 

das Opfer. 

Für eine erfolgreiche Abwehr muss der 

Empfänger der Nachricht unverlangt eingehende 

Handshake-Pakete verwerfen. 

DDoS mit Web Workers und 

Cross-Origin-Anfragen 

Bei einer DDoS-Attacke mit Web Workers 

machen sich die Angreifer einen 

Teil der HTML-5-Spezifikation zunutze: 

Cross-Origin-Requests. Im ersten Schritt 

locken sie Webbesucher auf eine Webseite, 

indem sie ihnen den Link zum Beispiel 

in einem Bild oder mit einem Skript 

wie ein Kuckucksei unterschieben. Die 

Webseite startet dann einen Web Worker, 

der den Browser dazu bringt, Cross- 

Origin-Anfragen an das Opfer zu versenden. 

Diese richten sich vorzugsweise an 

eine URL, die dem Server Schwerstarbeit 

verursacht. Allerdings würde der 

weitere Anfragen verhindern, wenn er 

keine gültige Antwort mit dem Header 

»Access‐Control‐Allow‐Origin« erhält. 

Deshalb muss die URL bei jedem Zugriff 

leicht modifiziert werden. Mit nur 6000 

ahnungslosen Benutzern eines Browsers 

wie Chrome lässt sich so eine Flut von bis 

zu einer Million Anfragen pro Sekunde 

generieren. 

Diese Art der Attacke lässt sich genauso 

leicht verhindern wie auslösen: Da alle 

Cross-Origin-Anfragen den Origin-Header 

beinhalten, genügt eine Einstellung in der 

Firewall, um solche Anfragen anhand des 

Headers zu unterbinden. 

DDoS auf Applikationsebene 

Neuerdings zielen DDoS-Attacken zunehmend 

auf ganz konkrete, gut dokumentierte 

Schwächen bestimmter Server- 

Dienste; man spricht hierbei von DDoS 

auf Applikationsebene (die siebente 

Ebene des OSI-Modells) (Abbildung 3). 

Angreifer gehen hier im Prinzip wie bei 

der sogenannten Slow-Read-Attacke auf 

den Webserver Apache vor: 

Apache öffnet für jede einzelne Verbindung 

einen neuen Thread und behält ihn 

für die Dauer der Kommunikation bei. 

Angreifer nutzen dieses Verhalten aus, 

indem sie Apache mit sorgsam dosierten 

Datenpaketen, extrem langsam und 

aus möglichst vielen Quellen gleichzeitig 

beliefern. So lassen sich die Kapazitäten 

von Apache nämlich am einfachsten 


Admin 


19

Security 

DDoS 

ausschöpfen. Laut der IT- 

Research-Firma Gartner soll 

rund ein Viertel aller DDoS- 

Attacken in 2013 auf Applikationsebene 

stattfinden. 

DDoS via HTTP 

Die Abwehr einer ACK-Reflection 

und SYN-Flops-Attacke 

verläuft nach demselben 

Prinzip – unabhängig davon, 

ob die Angreifer HTTP oder 

HTTPS einsetzen. Dies trifft jedoch auf 

DDoS-Attacken auf Applikationsebene 

überhaupt nicht mehr zu. Leider sind die 

Lösungen zur Schadenbegrenzung bei einer 

DDoS-Attacke nur auf das Abschirmen 

von DDoS via HTTP ausgelegt. 

Datenübertragung via HTTPS wandert im 

Internet verschlüsselt durch die Firewalls, 

andere Rechner und Router bis hin zum 

Lastverteiler oder am Ende zum Webserver. 

Die DDoS-Schutzmaßnahmen des 

Cloud-Anbieters und sogar die eigenen 

Abwehrmechanismen des Geschädigten 

sind komplett wirkungslos, solange die 

Datenpakete verschlüsselt weitergeleitet 

werden. 

Mit WordPress im DDoS- 

Botnet 

Seit 2012 zeichnet sich ein neuer Trend 

ab: die Täter verschaffen sich zunehmend 

Kontrolle nicht über Desktop-PCs 

sondern über hochleistungsfähige Server 

in der Cloud, um sorgfältig inszenierte 

DDoS-Attacken auszuführen. Bei den 

DDoS-Attacken auf US-Finanzinstitute im 

vergangenen Jahr konnten die Täter mit 

einer Handvoll Server die zwanzigfache 

Wirkung eines gewöhnlichen Desktop- 

Botnets erreichen. 

Es verschärfen sich daher Brute-Force- 

Attacken auf WordPress-Seiten in der 

Wolke. Ein Botnet aus über 90 000 IP- 

Adressen feuert an das beliebte CMS- 

System Benutzername-Passwort-Kombinationen. 

Das soll den Tätern Zugriff auf 

seine Upload-Fähigkeiten verschaffen. 

Die Täter installieren dann ihre Skripte 

und richten eine Hintertür ein, um den 

jeweiligen Webserver in ihr bestehendes 

Botnet dauerhaft einzugliedern. 

Das Problem der zunehmenden Verbreitung 

von DDoS-Attacken trifft besonders 

Prozent 

45 

40 

35 

30 

25 

20 

15 

10 

5 

0 

DDoS-Attacken 

stark Unternehmen mit einer skalierbaren 

Infrastruktur. Noch vor einigen Jahren 

war es üblich, unter DDoS einen Teil 

der Last in die Cloud auszulagern, um 

aus der elastischen Skalierbarkeit der 

Wolke einen Nutzen zu ziehen. Inzwischen 

sind die Angriffsmethoden so raffiniert 

geworden, dass der größte Vorteil 

der Cloud, nämlich deren Skalierbarkeit, 

dem Geschädigten zum Verhängnis werden 

kann. 

Skalierbarkeit: ein 

zweischneidiges Schwert 

IT-Sicherheitsexperten konnten ihre Bemühungen 

bisher auf zwei Phasen einer 

DDoS-Konfrontation fokussieren: präventive 

Maßnahmen und nachträgliche 

Verbesserungen. Die eigentliche DDoS- 

Attacke konnte man bisher aussitzen. 

Das ist bei DDoS aus der Wolke nicht 

mehr möglich. Wer die Zwei-Phasen- 

Verteidigung heute noch in die Praxis 

umsetzt, zieht den Kürzeren. DDoS-Angriffe 

in der Wolke dauern typischerweise 

zwischen mehreren Tagen und mehreren 

Wochen, und finden abwechselnd über 

mehrere Vektoren statt. Das IT-Fachpersonal 

kommt nicht mehr umhin, eine 

DDoS-Attacke aktiv zu kontern. 

DDoS aus der Wolke in die 

Wolke 

Das Hosting eines CDNs in der Wolke gewinnt 

zunehmend an Popularität. Doch 

anders als vermutet bietet diese skalierbare 

Cloud-Architektur nicht nur keinen 

Schutz vor DDoS-Attacken, sondern ganz 

im Gegenteil, der Angreifer kann die eigene 

Infrastruktur des Opfers ausnutzen, 

um IP-basierte Abwehrmechanismen auf 

dem Zielserver aufzuheben. Ein CDN 

DDos auf Applikationsebene 

DDoS-Netzwerkattacken 

< 10 MBit/s 10-100 MBit/s 100 MBit/s - 1 GBit/s 1-5 GBit/s 5-10 GBit/s > 10 GBit/s 

Geschwindigkeit 

Abbildung 3: Datenvolumen typischer DDoS-Attacken auf Netzwerkressourcen 

(rot) und auf Server-Applikationen (blau). 

kann Attacken mit einem hohen 

Datenvolumen aufnehmen 

und das Ausschöpfen 

der verfügbaren Ressourcen 

wesentlich erschweren. Leider 

bietet dies den IT-Fachkräften 

ein falsches Gefühl 

der Sicherheit. Anfragen nach 

dynamisch erzeugten Daten 

leitet das CDN an den Origin-Server. 

Indem die Angreifer 

jede Anfrage nach nicht 

vorhandenen Daten leicht 

modifizieren, können sie das CDN dazu 

veranlassen, eine DDoS-Attacke auf das 

eigene Data Center loszutreten. Die Täter 

können das CDN außerdem mit Cache- 

Direktiven im HTTP-Header umgehen, 

zum Beispiel mit: 

cache‐control: no‐cache 

oder 

Pragma: no‐cache 

Werden bösartige Anfragen durch das 

CDN an den Origin-Server weitergeleitet, 

unterlaufen sie außerdem bestehende Sicherheitssysteme, 

weil sie sich nun mit 

einer vertrauenswürdigen IP-Adresse des 

eigenen CDNs ausweisen. Das Resultat 

ist eine DoS-Attacke des eigenen CDNs 

auf das eigene Data Center des Opfers. 

Nicht-legitime Anfragen lassen sich in 

diesem Fall weder anhand der IP-Adresse 

blocken noch anhand des Datenvolumens 

identifizieren. Die Lastverteilung 

eingehender Angriffe auf verschiedene 

Knoten des CDNs sorgt dafür, dass sie 

unerkannt mit legitimen Datenströmen 

im Multiplex-Verfahren gemischt werden 

und erst dann hochkonzentriert die Zielsysteme 

bombardieren. 

Die einzige Methode, um legitime von 

nicht legitimen Anfragen in einer Attacke 

aus dem eigenen CDN zu unterscheiden, 

besteht im Inspizieren des HTTP-Headers. 

Denn erst der X-Forwarded-For-Header 

(XFF) gibt hier endgültigen Aufschluss 

über den tatsächlichen Ursprung der Anfrage 

und ermöglicht dann das gezielte 

Abblocken der Attacke anhand der IP- 

Adresse. (jcb) 

n 

Infos 

[1] Spamhaus: [http:// www. spamhaus. org] 

[2] CloudFlare: [https:// www. cloudflare. com] 

[3] Finanzwelt: [http:// finanzwelt. de] 



OpenStack 

© Vladimir Nenov, 123RF 

OpenStack: Der Shooting Star unter den Clouds 

Bausteinprinzip 

OpenStack bindet im Augenblick sehr viel von der Publicity, die zum Thema Cloud in einschlägigen Medien anfällt. 

Ist die Lösung tatsächlich als Cloud-Primus qualifiziert und was steckt technisch dahinter? Martin Loschwitz 

Wer im Augenblick IT-Nachrichten liest, 

fühlt sich gelegentlich an eine Szene aus 

John Malkovichs „Being John Malkovich“ 

erinnert, in der eben jener eine Reise 

in sich selbst unternimmt und bemerkt, 

dass jeder gesprochene Satz durch „John 

Malkovich“ ersetzt wird. Denn genau 

so ist es in der IT gerade auch: Cloud, 

Cloud, Cloud. 

Und immer häufiger in direktem Zusammenhang 

mit der Cloud OpenStack. Tatsächlich 

profiliert sich die offene Cloud- 

Umgebung des OpenStack-Projektes gerade 

als der Liebling der Community. Ist 

der Hype gerechtfertigt? Dieser Artikel 

gibt einen Überblick über eines der interessantesten 

Projekte der FOSS-Welt. 

Was ist Cloud Computing? 

Cloud Computing zielt in aller Regel darauf 

ab, skalierbare Lösungen zu schaffen. 

Konkret geht es darum, den großen 

IT-Trend der letzten Jahre, die Virtualisierung, 

mit Automatisierung zu verbinden: 

Die Idealvorstellung beim Bau einer 

Cloud ist es, Kunden die Möglichkeit einzuräumen, 

sich mit IT-Dienstleistungen 

selbst zu versorgen. 

Bei virtualisierten Umgebungen genießen 

Unternehmen zunächst ja nur den Vorteil, 

dass sie nicht mehr riesige Rechnerparks 

in ihren Rechenzentren stehen haben, in 

denen einzelne Server nicht ausgelastet 

sind. Zur Erinnerung: Ein heute gekaufter 

Server lässt sich beispielsweise mit einem 

Webserver kaum sinnvoll auslasten. Virtualisierung 

umgeht das Problem, indem 

sie mehrere virtuelle Appliances auf ein 

Blech legt und so für dessen optimale 

Auslastung sorgt. Mit Automatisierung 

hat das aber noch nicht viel zu tun, denn 

auch virtuelle Maschinen müssen häufig 

mühsam durch einen Admin installiert 

werden. 

Cloud Computing erweitert Virtualisierung 

um den Do-It-Yourself-Faktor: 

Kunden klicken sich über ein intuitives 

Web-Interface die Dienste, die sie 

im Augenblick benötigen, einfach selbst 

zusammen. Das Setup erfolgt automatisch, 

die Verrechnung auch. Zu zahlen 

ist allerdings nur, was der Kunde auch 

tatsächlich in Anspruch nimmt. Braucht 

er einen Dienst nicht mehr, stellt er ihn 

über das gleiche Web-Interface ab und 

muss ihn auch nicht mehr bezahlen. 

Reality-Check: OpenStack 

Wie passt OpenStack zu dieser Anforderung? 

Wichtig ist zunächst, dass es sich 

bei OpenStack nicht um ein monolithisches 

Programm handelt. Vielmehr beschreibt 

der Name OpenStack eine mittlerweile 

sehr umfangreiche Sammlung 

verschiedener Komponenten, die sich zusammen 

um Automatisierung kümmern. 

Die verschiedenen OpenStack-Komponenten 

befassen sich dabei jeweils nur 

mit ihrer spezifischen Aufgabe. Innerhalb 

der OpenStack-Welt sind folgende Aufgaben 

im Rahmen der Automatisierung 

definiert: 

n Benutzerverwaltung 

n Image-Verwaltung 

n Netzwerkverwaltung 

n VM-Verwaltung 

n Verwaltung von Blockspeicher für 

VMs 

n Cloud Storage 

n das Frontend zum Benutzer 

Für jede dieser Aufgaben existiert eine 

einzelne OpenStack-Komponente; der Artikel 

stellt diese Komponenten im weiteren 

Verlauf vor. Übrigens: Komponenten 

in OpenStack haben stets zwei Namen, 

einerseits den offiziellen Projektnamen 

und andererseits einen Codenamen. Der 

Artikel nutzt die weitaus geläufigeren 

Codenamen, um die einzelnen Teile von 

OpenStack zu benennen. 

Benutzerverwaltung: 

Keystone 

Da wäre zunächst die Benutzerverwaltung, 

die der Cloud zugrunde liegt. Der 

Punkt klingt banal, ist es aber nicht. 


OpenStack 


Denn: Damit Kunden sich innerhalb einer 

Cloud-Computing-Umgebung ihre 

Dienste zurechtlegen können, muss jene 

zwingend über ein System zur Benutzerverwaltung 

verfügen. In OpenStack 

sorgt Keystone [1] dafür, dass Benutzer 

sich mit ihren Account-Daten einloggen 

können. 

Keystone implementiert aber nicht nur 

ein simples System auf der Grundlage 

von Benutzern und Passwörtern, sondern 

es bietet ein feingranulares Schema 

zum Zuteilen von Berechtigungen: An 

oberster Stelle stehen die Tenants, die in 

der Cloud-Umgebung typischerweise die 

Ebene der Unternehmen darstellen, die 

Kunden des Cloud-Anbieters sind. Dann 

gibt es die Benutzer, die jeweils Mitglied 

eines Tenants sind und dort durchaus 

unterschiedliche Rechte haben können. 

Der Chef eines Unternehmens wird beispielsweise 

die Permissions haben, um 

VMs zu starten oder zu stoppen oder 

neue Admins zu ernennen, während der 

einfache Sysadmin nur virtuelle Systeme 

starten oder stoppen darf. Über Key stone 

lässt sich solch ein Benutzerschema 

nachbilden und zwar für beliebig viele 

Tenants. 

Auch für die interne Kommunikation 

mit den anderen OpenStack-Diensten 

ist Keystone verantwortlich; damit ein 

OpenStack-Dienst mit einem anderen reden 

darf, muss er sich vorher ebenfalls 

über Keystone authentifizieren. Dafür 

gibt es die Keystone-Middleware, eine Art 

Python-Plugin, das jede interne oder externe 

Komponente nutzen kann, um die 

Keystone-Authentifizierung sicher abzuwickeln. 

Apropos Python: Keystone ist – 

wie alle anderen OpenStack-Dienste auch 

– zu 100 Prozent in Python verfasst. 

Und dann wären da noch die Endpunkte: 

Damit die Cloud tut, was sie soll, findet 

zwischen den einzelnen Komponenten 

von OpenStack jede Menge Kommunikation 

statt. Weil Clouds aber skalieren sollen, 

wäre es sehr unpraktisch, für diese 

Kommunikation statische IPs zu nutzen. 

Keystone pflegt deshalb eine Art Telefonbuch 

innerhalb der OpenStack-Cloud: 

Das Endpunkte-Verzeichnis listet auf, 

welcher OpenStack-Dienst gerade wo zu 

erreichen ist. Will ein Dienst mit einem 

anderen reden, befragt er also ganz einfach 

nur Keystone und erhält im Handumdrehen 

die gewünschte Information. 

Ändert sich die Adresse eines Dienstes 

später, ändert der Admin einfach nur die 

Adresse in Keystone, nicht aber in allen 

Konfigurationsdateien für jeden Dienst 

auf jedem Host. 

Image-Verwaltung: Glance 

Cloud-Angebote, die Kunden per Web- 

Interface nutzen sollen, müssen eine zentrale 

Anforderung erfüllen: Sie müssen 

niederschwellig sein. Der Kunde muss per 

Mausklick eine neue VM starten können, 

sonst bringt ihm die ganze Umgebung 

nichts. Daraus ergibt sich zwangsläufig, 

dass es dem Kunden kaum zuzumuten 

ist, sich um die Installation eines Betriebssystems 

innerhalb der VM händisch 

zu kümmern – oft genug wird er gar nicht 

das notwendige Wissen mitbringen, das 

er braucht, um die VM zu installieren. 

Der Admin hat naturgemäß kein Interesse 

daran, dem Kunden die Aufgabe der 

manuellen VM-Installation abzunehmen, 

denn dann wäre der Automatisierungseffekt 

ja dahin. 

Glance [2] schafft eine Lösung für das 

Problem: In Glance legt der Administrator 

einer Cloud-Umgebung fertige Images 

an, die der Benutzer dann bei Bedarf 

einfach für seine neue VM auswählt. Für 

den Admin fällt daher nur einmal Arbeit 

an, nämlich beim Einrichten des Images, 

und der Kunde hat mit dem Thema 

Betriebssystem überhaupt keine Scherereien 

mehr. 

Unter der Haube besteht Glance aus zwei 

Diensten, einer API und einem Tool, das 

sich um die Verwaltung der Images kümmert. 

Diese Einteilung findet sich in ab- 

gewandelter Form in OpenStack häufig. 

Auch Keystone ist ja im Grunde nichts 

anderes als eine HTTP-basierte API, die 

per ReSTful-Prinzip anzusprechen ist. 

Glance gehört zu den eher unauffälligen 

OpenStack-Komponenten, und Admins 

werden nach der ersten Installation mit 

dem Dienst nur noch selten etwas zu tun 

haben. Er unterstützt diverse Image-Formate, 

darunter natürlich das KVM-eigene 

Format Qcow2, VMware-VMDK-Images, 

aber auch Microsofts VDI-Format aus 

Hyper-V. Außerdem lassen sich vorhandene 

Systeme relativ leicht in Glancekompatible 

Images (Raw Images) verwandeln. 

Seinen großen Auftritt hat Glance stets 

dann, wenn es gilt, eine neue VM zu starten: 

Dann kopiert der Dienst nämlich das 

Image für diese VM auf den Hypervisor- 

Host, auf dem die VM lokal laufen soll. 

Für Admins ergibt sich daraus freilich, 

dass in Glance abgelegte Images nicht 

zu groß sein sollten, sonst dauert es eine 

gefühlte Ewigkeit, bis das Image auf dem 

Hypervisor ankommt. Übrigens: Viele 

Distributionen bieten fertige Glance-Images 

an: Ubuntu kommt beispielsweise mit 

seinen UEC-Images [3] daher. 

Netzwerkverwaltung: 

Neutron 

Wer sich mit OpenStack auseinandersetzt, 

landet früher oder später auch bei 

Neutron. Die Komponente genießt nicht 

den besten Ruf und steht im Verdacht, 

übermäßig kompliziert zu sein – das liegt 

allerdings viel weniger an Neutron selbst 

als an seinen umfassenden Aufgaben: 

Abbildung 1: Über das Dashboard erhalten Nutzer Zugriff auf die Images, die in Glance gespeichert sind – per 

Mausklick wählen sie eines aus. 


Admin 


23


OpenStack 

Abbildung 2: Beim Starten einer VM kann der Kunde sich – Neutron sei Dank – 

aussuchen, zu welchem virtuellen Netz die VM eine Verbindung haben soll. 

Es kümmert sich darum, dass in einer 

OpenStack-Umgebung das Netzwerk so 

funktioniert, wie es soll. 

Das Thema Netzwerk-Virtualisierung 

wird gern unterschätzt. Typische Netzwerk-Topologien 

sind eher statisch: Es 

herrscht eine meist sternförmige Struktur. 

Bestimmten Kunden sind bestimmte 

Ports zugewiesen und untereinander 

sind Kunden voneinander über VLANs 

getrennt. In Cloud-Umgebungen funktioniert 

dieses System nicht mehr: Einerseits 

ist nicht vorhersagbar, auf welchem 

Computing-Knoten die VM eines Kunden 

gestartet wird, andererseits skaliert eine 

solche Lösung auch nicht. Die Antwort 

auf dieses Problem ist Software Defined 

Networking, kurz SDN, das im Grunde 

ein einfaches Ziel hat: Switches sind bloß 

noch Blech, VLANs & Co. sind nicht länger 

in Gebrauch und alles, was mit dem 

Netzwerk zu tun hat, wird über Software 

innerhalb der Umgebung kontrolliert. Die 

bekannteste SDN-Lösung ist OpenFlow 

[4] mit dem dazugehörigen Frontend 

Open vSwitch [5]. Und Neutron bildet 

das OpenStack-Gegenstück, nämlich den 

Teil, der aus OpenStack heraus auf die 

Konfiguration von Open vSwitch (oder 

die eines anderen SDN-Stacks) direkten 

Einfluss nimmt. De facto lässt sich mit 

Neutron ein komplettes Netz virtualisieren, 

ohne die Konfiguration einzelner 

Switches anzufassen – über verschiedene 

Plugins ist es aber auch möglich, Switch- 

Konfigurationen direkt aus OpenStack 

heraus zu bearbeiten. 

Wie OpenStack ist nämlich auch Neutron 

[6] modular aufgebaut; die API 

wird durch ein Plugin für eine spezifische 

SDN-Technik (beispielsweise das bereits 

erwähnte Open vSwitch) aufgebohrt, zu 

jedem Plugin gehört 

auf der Seite 

der Computing- 

Knoten ein entsprechender 

Agent, der die SDN-Befehle 

des Plugins umsetzt. 

Die generischen Agents für DHCP und L3 

erfüllen beide spezielle Aufgaben: Ersterer 

sorgt dafür, dass VMs beim Starten von 

Tenants IPs per DHCP bekommen, letzterer 

schafft eine Verbindung zum Internet 

für die laufenden VMs. Auf die Spitze getrieben 

ist es mit Neutron möglich, dass 

sich jeder Kunde innerhalb seiner Cloud 

eine eigene Netzwerk-Topologie baut. 

Die Netzwerke von Kunden dürfen dabei 

durchaus auch überlappende IP-Bereiche 

nutzen, der Fantasie sind letztlich kaum 

Grenzen gesetzt. Der Nachteil dieser 

enormen Funktionsvielfalt ist freilich, 

dass es einiges Vorwissen zu Themen wie 

der Funktionsweise von Software Defined 

Networks braucht, um zu verstehen, was 

Neutron eigentlich tut – und um den Fehler 

zu finden, wenn etwas einmal nicht so 

funktioniert, wie es soll. 

Übrigens: Wer sich in der Vergangenheit 

bereits mit OpenStack beschäftigt hat, 

kennt diese Komponente vielleicht noch 

unter ihrem alten Namen, Quantum. So 

hieß Neutron bis einschließlich Open- 

Abbildung 3: Neutron baut im Hintergrund in der Standardkonfiguration sowohl 

auf OpenFlow als auch auf Open vSwitch auf. 

Stack 2013.1, bis ein Streit um Namensrechte 

in den USA zur Umbenennung in 

Neutron führte. 

VM-Verwaltung: Nova 

Die bisher vorgestellten Komponenten 

erledigen im Rahmen einer Cloud die 

wichtige Vorarbeit, um virtuelle Maschinen 

laufen zu lassen. Nova [7] kommt 

quasi als Exekutive innerhalb einer 

OpenStack-Cloud hinzu: Nova zeichnet 

für das Starten und Stoppen von virtuellen 

Maschinen sowie für die Verwaltung 

der zur Verfügung stehenden Hypervisor- 

Knoten verantwortlich. Weist der Nutzer 

die OpenStack-Cloud an, eine virtuelle 

Maschine zu starten, so erledigt Nova 

stets das Gros der Arbeit: Es schaut bei 

Keystone nach, ob der Benutzer überhaupt 

eine VM starten darf, weist Glance 

an, eine Kopie des Images auf dem Hypervisor 

anzulegen und zwingt Neutron, 

eine IP für die neue VM herauszurücken. 

Ist all das passiert, startet Nova selbst 

die VM auf dem Hypervisor-Knoten und 

Abbildung 4: Neben dem Dashboard bieten auch die einzelnen Client-Tools auf der Kommandozeile die 

Möglichkeit, die einzelnen Komponenten zu bedienen. 


OpenStack 


Weise gesichert ist und sich zum Beispiel 

auf verschiedenen Knoten starten lässt. 

Cloud Storage: Swift 

Abbildung 5: Nova besteht aus vielen einzelnen Komponenten, dazu gehören der Scheduler oder 

»nova‐compute«. 

erlaubt es anschließend auch, sie herunterzufahren, 

zu löschen oder auf einen 

anderen Host umzuziehen. Auch Nova 

besteht aus mehreren Teilen: neben einer 

API namens Nova-API ist es vor allem 

die Nova-Compute-Komponente, die 

auf den Hypervisor-Knoten die Arbeit 

erledigt. Andere Komponenten erfüllen 

spezifische Aufgaben: »nova‐scheduler« 

beispielsweise findet anhand der Konfiguration 

und seiner Informationen über 

vorhandene Hypervisor-Knoten heraus, 

auf welchem Hypervisor die neue VM 

überhaupt zu starten ist. 

Dabei hat Nova übrigens keineswegs das 

Rad neu erfunden: Kommt es zusammen 

mit Libvirt und KVM auf Linux-Servern 

zum Einsatz, setzt es auf die Funktionen 

von Libvirt und baut so auf eine erprobte 

Technologie, anstatt eigene Methoden 

zum Starten und Stoppen von VMs zu 

implementieren. Ähnliches gilt für andere 

Hypervisor-Implementierungen, von 

denen Nova mittlerweile einen ganzen 

Reigen unterstützt: Neben KVM gehören 

beispielsweise Xen, Microsoft Hyper-V 

und auch VMware zu den Zielplattformen. 

Block-Speicher für VMs: 

Cinder 

Schließlich gibt es noch Cinder [8], dessen 

Funktion sich nicht auf den ersten 

Blick erschließt – man versteht sie aber, 

wenn man sich das Problem vergegenwärtigt: 

OpenStack geht grundsätzlich 

davon aus, dass virtuelle Maschinen 

Am Ende der Vorstellung von OpenStack 

steht das Frontend zum Nutzer: Die 

schönste Cloud-Umgebung wäre nichts 

wert, wenn sie für unerfahrene Anwender 

ohne Vorkenntnisse nicht zu bedienen 

wäre. Horizon macht OpenStack nutzbar: 

Das auf Django basierende Web-Interface 

ermöglicht Anwendern das Starten und 

Stoppen virtueller Maschinen wie auch 

die Konfiguration diverser Parameter, die 

mit der Nutzung der Cloud durch die 

Anwender in Verbindung stehen. Wenn 

eine neue VM zu starten ist, erledigen 

Anwender das genauso über Horizon wie 

das Zuweisen einer öffentlichen IP zu 

einer VM [10]. 

Freilich darf an dieser Stelle ein kurzer 

Überblick über die verschiedenen Vernicht 

darauf ausgelegt sind, dauerhaft 

zu laufen. Der radikale Gedanke resultiert 

aus dem hauptsächlich in Amerika vertretenem 

Ansatz, eine Cloud-Umgebung 

müsse nur in der Lage sein, schnell viele 

VMs aus dem gleichen Image zu starten 

– es ist in diesem Prinzip quasi gar nicht 

vorgesehen, dass Daten innerhalb einer 

VM anfallen, die dauerhaft zu speichern 

sind. Deshalb existieren VMs zunächst 

nur als lokale Kopie in den Dateisystemen 

ihres jeweiligen Hypervisor-Knotens. Und 

wenn der abstürzt oder der Kunde die 

VM löscht, sind die Daten weg. Das Prinzip 

trägt den Namen Ephemeral Storage. 

Dass die Realität komplizierter ist, ist 

kein Geheimnis. 

OpenStack bietet durchaus die Möglichkeit, 

Daten in VMs zu sammeln und sie 

über den Neustart der VMs hinweg zu 

sichern. Genau hier kommt Cinder ins 

Spiel: Cinder stattet virtuelle Maschinen 

auf Kundenwunsch mit persistentem 

Blockspeicher aus. Dabei unterstützt es 

eine Vielzahl verschiedener Storage-Backends, 

darunter LVM, Ceph, aber auch 

Hardware-SANs wie IBMs StoreWiz und 

3PAR-Storages von HP. Je nach gewählter 

Implementierung unterscheiden sich 

die technischen Details im Hintergrund. 

Wichtig für den Benutzer ist aber zunächst 

nur, dass er sich einen Speicher 

anlegt und diesen seiner VM zuweist – 

danach greift er in der VM auf den Speicher 

wie auf eine gewöhnliche Festplatte 

zu. Auf Kundenwunsch hin lassen sich 

VMs auch von Block-Devices booten, 

sodass die gesamte VM auf dauerhafte 

Abbildung 6: Die einzelnen VMs auf den Computing-Knoten liegen einfach auf einem Dateisystem lokal – sollen 

sie dauerhaft erhalten bleiben, ist Cinder notwendig. 

Nahezu sämtliche bis hierhin vorgestellten 

Komponenten beschäftigen sich mit 

dem Thema Virtualisierung. Allerdings 

ist es gängige Lehrmeinung, dass eine 

Cloud zusätzlich auch On-Demand-Storage 

bieten muss, also Speicher, welchen 

Anwender bei Bedarf über ein simples 

Interface nutzen können. Dienste wie 

Dropbox oder Google Drive sind der Beweis 

dafür, dass solche Dienste sich einer 

großen Fangemeinde erfreuen. In Open- 

Stack kümmert sich Swift [9] darum, 

dass Benutzer Cloud-Speicher haben. Der 

vom amerikanischen Anbieter Rackspace 

entwickelte Dienst bietet Nutzern über 

ein ReSTful-Protokoll die Möglichkeit, 

Dateien in den Speicher hoch- oder aus 

ihm herunterzuladen. Für Unternehmen 

ist Swift interessant, weil es sich um einen 

Object Store handelt, der Daten in 

Form binärer Objekte ablegt und damit 

nahtlos in die Breite skaliert. Wird der 

Platz knapp, stellen Unternehmen also 

einfach ein paar Storage-Knoten mit frischem 

Plattenplatz dazu, ohne dass der 

Speicher vollläuft. Es ist übrigens auch 

möglich, Swift ohne die anderen Open- 

Stack-Komponenten zu betreiben – damit 

nimmt der Dienst in OpenStack eine Sonderstellung 

ein, denn die anderen Dienste 

bedingen einander zwingend. 

Das Frontend: Horizon 


Admin 


25


OpenStack 

sionen von OpenStack nicht fehlen – das 

Thema stiftet unter Neulingen im Open- 

Stack-Umfeld gelegentlich Verwirrung: 

Grundsätzlich folgt OpenStack einem 

Release-Plan, der jedes halbe Jahr eine 

neue Version vorsieht. 

OpenStack-Versionen 

Die Versionen werden durchnummeriert, 

wobei die Jahreszahl stets Teil der Version 

ist. Die erste OpenStack-Version im Jahre 

2012 hatte folglich die Version 2012.1, 

die erste Version im Jahre 2013 hatte die 

Version 2013.1. Hinzu kommen die von 

der OpenStack-Community ausgewählten 

Codenamen, die weitaus geläufiger sind: 

OpenStack 2012.1 hieß Essex, 2012.2 hieß 

Folsom und OpenStack 2013.1 trägt den 

Namen Grizzly. Die nächste Version, die 

im Oktober 2013 erscheinen wird, hört 

auf den Codenamen Havana. Gewisse 

Ähnlichkeiten zum Versionsschema von 

Ubuntu sind durchaus gegeben. 

Die Community 

OpenStack legt großen Wert darauf, ein 

Community-Projekt zu sein. Das ist auch 

einer der Faktoren, die das Projekt von 

anderen Cloud-Stacks abhebt: Anders als 

bei Eucalyptus oder OpenNebula steht 

bei OpenStack kein Unternehmen im 

Hintergrund, das die Entwicklung der 

Plattform bewusst steuert. OpenStack 

war seit Anbeginn seiner Existenz darauf 

ausgelegt, ein Community-Projekt zu 

sein. Es ging aus einer Kooperation der 

NASA und des amerikanischen Hostinganbieters 

Rackspace hervor, der hierzulande 

als Hoster von GitHub bekannt sein 

dürfte. Die NASA steuerte den Teil bei, 

der sich mit Virtualisierung beschäftigte, 

Rackspace warf Swift als Speicherlösung 

in die Waagschale. 

Seither hat sich viel getan: Die NASA ist 

nicht mehr an der OpenStack-Entwicklung 

beteiligt, aber dafür haben sich Hunderte 

andere Firmen der OpenStack-Bewegung 

angeschlossen, darunter Größen wie Red 

Hat, Intel und HP. Die Projektstruktur 

legt weiterhin großen Wert auf die Community, 

so gibt es beispielsweise eine 

OpenStack-Foundation, deren Board-Mitglieder 

zum Teil direkt von Projektmitgliedern 

gewählt werden. Jede der zuvor 

beschriebenen Komponenten hat einen 

technischen Projektleiter (Project Technical 

Lead, PTL), der ebenfalls demokratisch 

gewählt wird. Und: OpenStack legt 

viel Wert darauf, jedem Interessierten die 

Mitarbeit zu ermöglichen, wer also will, 

findet in OpenStack definitiv etwas, zu 

dem er Sinnvolles beisteuern kann. 

Auf den zweimal jährlich stattfindenden 

Design Summits zelebriert das Projekt 

seine Wurzeln in der Community und 

lädt Entwickler dazu ein, im Rahmen einer 

Konferenz über mehrere Tage hinweg 

Vorträgen zu lauschen oder über Designkonzepte 

zu brüten, die im weiteren Verlauf 

die Entwicklung bestimmen. Keine 

Rede also von einer One-Man-Show. 

Mehr Informationen 

Es würde an dieser Stelle den Rahmen 

des Artikels bei Weitem sprengen, die 

Funktionen der OpenStack-Komponenten 

genauer zu erläutern oder auf weitere 

Hintergründe des Projektes einzugehen. 

Wer mehr wissen möchte, findet 

auf den einzelnen Seiten der OpenStack- 

Komponenten mehr Informationen. Die 

Dokumentation des Projekts kann sich 

mittlerweile sehen lassen [11], und auch 

im Wiki des OpenStack-Projektes finden 

sich viele detaillierte Informationen. 

Für die Aufzeichnungen über Fehlerberichte 

nutzt OpenStack übrigens Launchpad, 

und auch die »Questions«-Funktion 

von Launchpad bietet die Möglichkeit, 

bei hartnäckigen Problemen eine Frage 

in die Runde zu werfen, derer sich nicht 

selten einer der Projektentwickler direkt 

annimmt. 

Der offizielle IRC-Kanal des OpenStack- 

Projektes ist »#openstack« auf Freenode. 

Auch hier finden sich etliche erfahrene 

OpenStack-Anwender, die bei konkreten 

Problemen vielleicht weiterhelfen können. 

Wer OpenStack ausprobieren möchte, 

findet im Netz einige vollständige Installationsanleitungen 

und kann quasi sofort 

loslegen – zum Testen reichen drei virtuelle 

Maschinen völlig aus, eigene Hardware 

ist nicht notwendig. Schließlich sei 

auch auf die verschiedenen OpenStack- 

Artikel des Autors dieses Artikels verwiesen, 

die in den letzten ADMIN-Ausgaben 

erschienen sind. (jcb) 

n 

Infos 

[1] Keystone: [http:// keystone. openstack. 

org/] 

[2] Glance: [http:// glance. openstack. org/] 

[3] Ubuntu-UEC-Images: [http:// cloud‐images. 

ubuntu. com/] 

[4] OpenFlow: [http:// www. openflow. org/] 

[5] Open vSwitch: [http:// www. openvswitch. 

org/] 

[6] Neutron: [http:// quantum. openstack. org/] 

[7] Nova: [http:// nova. openstack. org/] 

[8] Cinder: [http:// cinder. openstack. org/] 

[9] Swift: [http:// swift. openstack. org/] 

[10] Horizon: [http:// horizon. openstack. org/] 

[11] OpenStack-Wiki: [http:// wiki. openstack. 

org/] 

Abbildung 7: Über das Dashboard steuern Nutzer die Dienste, die sie innerhalb der Cloud nutzen, wie etwa 

virtuelle Maschinen. 

Der Autor 

Martin Gerhard Loschwitz arbeitet als Principal 

Consultant bei hastexo. Er beschäftigt sich dort 

intensiv mit Distributed-Storage-Lösungen sowie 

OpenStack. Außerdem ist er Entwickler beim 

Debian-Projekt. 



OpenNebula 

© pitris, 123RF 

OpenNebula – Open-Source-Datacenter-Virtualisierung 

Griff zu den Sternen 

OpenNebula ist eine Enterprise-Cloud-Management-Plattform, die 2005 aus einem EU-Forschungsprojekt hervorgegangen 

ist. Damit ist sie bereits länger am Markt als viele vergleichbare Produkte. Mit der aktuellen Version 

4.2 (Codename Flame) präsentiert sie sich seit Juli 2013 in neuem Gewand. Bernd Erk 

OpenNebula [1] selbst trennt die vorhandenen 

Cloud-Lösungen in die beiden 

Einsatzbereiche Infrastructure Provisioning 

und Datacenter Virtualizsation [2] 

und sieht sich selbst im letztgenannten 

Bereich. Diese Einteilung erlaubt auch 

eine klare Positionierung im Vergleich zu 

anderen Lösungen, worauf der Artikel 

noch eingehen wird. 

Was ist OpenNebula? 

OpenNebula greift zur Bereitstellung von 

Ressourcen auf verschiedene etablierte 

Subsysteme in den Bereichen Virtualisierung, 

Networking und Storage zurück. 

Dies ist bereits ein signifikanter Unterschied 

zu Alternativlösungen wie Open- 

Stack und Eucalyptus. Diese favorisieren 

nämlich eigene Konzepte – am Beispiel 

von Storage und OpenStack via Swift. 

Alle diese Subsysteme [Abbildung 1] 

werden über einen zentralen Daemon 

(»oned«) miteinander verbunden. Zusammen 

mit einem Benutzer- und Rollenkonzept 

werden diese Komponenten 

über Command Line Interfaces und das 

Web-Interface bereitgestellt. Die Bedienung 

der Hosts und VMs ist dadurch 

unabhängig vom eingesetzten Subsystem 

und erlaubt eine transparente Steuerung 

von Xen, KVM und VMware. Auch ein 

gemischter Betrieb dieser Hypervisor ist 

möglich – OpenNebula abstrahiert dabei 

von den jeweils verfügbaren Komponenten 

mithilfe eines einheitlichen Interfaces. 

Genau in dieser transparenten Verbindung 

unterschiedlichster Komponenten 

steckt die Stärke von OpenNebula: seine 

hohe Integrationsfähigkeit. 

Aufbau 

Ein wichtiges Merkmal von OpenNebula 

ist der Schwerpunkt auf Rechenzentrumsvirtualisierung 

mit bestehender 

Infrastruktur. Wichtige Voraussetzung 

dafür ist die Unterstützung einer Vielzahl 

an Infrastrukturkomponenten und deren 

dynamische Verwendung. 

Besonders gut erkennt man das an den 

sogenannten Datastores. Deren Grundidee 

ist simpel: Während beispielsweise 

ein Testsystem jederzeit wieder aus dem 

zentralen Image Repository auf einen Hypervisor 

kopiert werden kann, ist bei einem 

DB-Server die Wiederherstellung der 

letzten Laufzeitumgebung notwendig. Die 

innerhalb einer OpenNebula-Installation 

mehrfach konfigurierbare Definition von 

Datastores bietet die Möglichkeit, sich 

diesen unterschiedlichen Lebenszyklen 

anzupassen. So kann ein persistentes 

Image auf einem NFS-Volume beheimatet 

sein und ein volatiles Image wird zum 

Startzeitpunkt auf den eingesetzten Hypervisor 

kopiert. 

Der Konfigurations- und der Monitoringstack 

sind innerhalb von OpenNebula 


OpenNebula 


vollständig getrennt. Ein klarer Workflow 

stellt Compute-Ressourcen bereit und 

überwacht in der Folge die Verfügbarkeit. 

Ein Ausfall des OpenNebula-Cores 

hat dabei keinerlei Auswirkung auf den 

Runtime-Status der jeweiligen Instanzen, 

da Kommandos nur im Bedarfsfall abgesetzt 

werden. 

Zur Überwachung selbst dienen abhängig 

vom Hypervisor lokale Kommandos. So 

pollt der Core regelmässig alle aktiven 

Hypervisor und prüft, ob die konfigurierten 

Systeme noch aktiv sind. Sollte 

das nicht der Fall sein, werden sie neu 

gestartet. 

Durch die Überwachung von Hypervisor- 

Ressourcen wie Memory und CPU wird 

eine Vielzahl von Systemen im Fehlerfall 

schnell umverteilt und neu gestartet. Typischerweise 

werden bei Ausfall eines 

Hypervisors die betroffenen Systeme so 

schnell verteilt, dass ein Nagios- oder 

Icinga-System im Standardintervall keinen 

Alarm schlägt. Lediglich der Ausfall 

des Hypervisors soll natürlich für Aufmerksamkeit 

sorgen. 

Selfmanagement und Überwachung der 

Ressourcen sind ein wichtiger Bestandteil 

von OpenNebula und im Vergleich 

zu anderen Produkten bereits sehr detailliert 

und variabel verwendbar. Über 

ein Hook-System können darüber hinaus 

noch an allen erdenklichen Stellen Custom-Skripte 

ausgeführt werden. Mit der 

Auto-Scaling-Implementierung OneFlow 

können ab Version 4.2 auch Abhängigkei- 

ten über Systemgrenzen hinweg definiert 

und überwacht werden. Aber dazu später 

mehr. 

Die Installation 

Die Installation von OpenNebula ist im 

Detail stark von den eingesetzten Komponenten 

wie Virtualisierungs-, Storageund 

Netzwerk-Providern abhängig. Für 

alle gängigen Provider bietet der Design- 

Guide [3] jedoch ausführliche Beschreibungen 

und Hinweise zur Vermeidung 

der klassischen Fehlkonfigurationen. In 

der Basis setzt sich eine Installation aus 

vier Komponenten zusammen: 

n Core und Interfaces 

n Hosts 

n Image Repository und Storage 

n Networking 

Der Management-Core (»oned«) bildet 

gemeinsam mit den entsprechenden APIs 

und dem Web-Interface (Sunstone) die 

eigentliche Steuereinheit der Cloud-Installation. 

Auf den Virtualisierungs-Hosts 

muss mit der Ausnahme von Ruby keine 

spezifische Software laufen; jedoch muss 

der Zugriff per SSH auf alle beteiligten 

Hosts möglich sein, um später Statusdaten 

abzurufen oder gegebenfalls Images 

zu übertragen. Für den Aufbau des 

Image Repositories gibt es verschiedene 

Möglichkeiten unter Verwendung von 

Shared- oder Non-shared-Filesystemen. 

Die Entscheidung für die richtige Storage- 

Infrastruktur ist an dieser Stelle wohl 

Abbildung 1: OpenNebula setzt auf existierende Virtualisierungs-Netzwerk- und Storage-Lösungen, die ein 

zentraler Daemon integriert. 

die wichtigste, da eine Umstellung zum 

späteren Zeitpunkt mit großem Aufwand 

verbunden ist. 

Ein Szenario ohne Shared-Filesystem ist 

zwar denkbar, allerdings muss dann auf 

Features wie Live-Migration verzichtet 

werden. Fällt ein Host aus, wäre es dann 

nötig, das entsprechende Image erneut 

zu deployen, und die volatilen Datenänderung 

wären verloren. 

Die Installation der Komponenten kann 

über entsprechende Distributionspakete 

für alle gängigen Plattformen [4] oder 

aus den Sourcen [5] erfolgen und ist 

auf der Projektseite sehr ausführlich 

beschrieben. Nach Installation der notwendigen 

Pakete und Anlage des Open- 

Nebula-Users »oneadmin« ist noch der 

entsprechende SSH-Key zu generieren. 

Anschließend muss man diesen auf den 

eingesetzten Host-Systemen verteilen – 

fertig! Wenn alles richtig gemacht wurde, 

sollte ein Start von OpenNebula mit dem 

Befehl »one start« erfolgreich sein und 

der Zugriff auf den Daemon unter Verwendung 

des CLI ohne Probleme durchlaufen. 

Konfiguration und 

Management 

Als erster Schritt nach der Installation 

müssen dem System die entsprechenden 

Hypervisor hinzugefügt werden, um virtuelle 

Systeme zur Verfügung zu stellen. 

Es werden aktuell Xen, KVM und VMware 

unterstützt. Abhängig vom gewählten 

Hypervisor muss die Konfiguration 

noch im zentralen Konfigurationsfile 

»/etc/one/oned.conf« erweitert werden, 

um die korrekte Ansteuerung des Host- 

Systems sicherzustellen. Im Falle von 

KVM erfolgt die Kommunikation mittels 

»libvirt«, welches als Interface sowohl 

die Verwaltungs- als auch Monitoring- 

Funktionen übernimmt. 

Auch wenn OpenNebula 4.2 mit einer 

sehr schönen neuen Webkonsole (Abbildung 

2) und einem Self-Service-Portal 

daherkommt, ist die Steuerung aller 

Komponenten mittels CLI möglich. Die 

meisten Kommandos arbeiten mit Hostund 

VM-IDs, um diese Komponenten sicher 

zu identifizieren und zu steuern. 

Eine Anbindung von OpenNebula an 

eine CMDB ist ein Kinderspiel – so lassen 

sich automatisch VMs generieren, 


Admin 


29


OpenNebula 

nachdem sie in der Verwaltungsoberfläche 

angelegt wurden. Auch Puppet, Chef 

und Cfengine lassen sich zur Steuerung 

der Cloud-Umgebung heranziehen. 

Funktional wird man mit dem zur Verfügung 

stehenden Feature-Set nichts vermissen. 

Eine gewisse Einarbeitung in das 

Vorgehen und die Funktionen der einzelnen 

Subsysteme bedarf allerdings etwas 

Zeit. Auch ein hybrider Betrieb verschiedener 

Wirtssysteme oder auch die Verlagerung 

von Ressourcen in andere private 

Zonen oder zu Public-Cloud-Anbietern 

ist mit OpenNebula möglich und kann 

unter einer einheitlichen administrativen 

Konsole bewerkstelligt werden. 

Cloud Shaping 

Mit zunehmender Größe einer Cloud- 

Umgebung sind auch Abhängigkeiten zu 

Nutzern, Standorten und Fähigkeiten der 

eingesetzten Systeme zu berücksichtigen. 

OpenNebula verfügt hier mit Gruppen, 

virtuellen Datacenters (kurz VDC) und 

Zones über drei Basiskonzepte. 

Gruppen erlauben es, Systeme mit 

gleichartigen Fähigkeiten zu logischen 

Einheiten zusammenzuschließen. Damit 

können Voraussetzungen für den Betrieb 

bestimmter Systeme definiert und solche 

mit Zugriff auf die gleiche Teilinfrastruktur 

wie Datastore, VLANs und Hypervisor 

zusammengefasst werden. So lässt sich 

zum Beispiel ein KVM-System auf einem 

GlusterFS-Storage natürlich nur auf Servern 

mit KVM-Hypervisor und GlusterFS- 

Zugriff betreiben. Gruppen stellen sicher, 

Abbildung 2: Das neue Web-Interface von OpenNebula 4.2. 

dass genau diese Voraussetzungen auch 

erfüllt sind. 

Wenn eine Sammlung von Ressourcen 

einer Anzahl Benutzer oder auch einem 

Kunden zur Verfügung gestellt werden 

soll, ohne dass Gruppen zum Einsatz 

kommen, dann ist die Verwendung von 

VDC die Lösung. Beliebige Ressourcen 

können zu virtuellen Rechenzentren zusammengefasst 

und über ACLs berechtigt 

werden. Diese zonenübergreifenden Zusammenschlüsse 

bieten neben der Isolation 

von Noisy Neighbors und der Teilzuordnung 

von Ressourcen auch eine sehr 

gute Basis für Individualabrechnung von 

Ressourcen. Auch die Unterteilung aller 

Ressourcen in individuelle Private Clouds 

lässt sich einfach mit VDCs lösen. 

Als drittes Teilkonzept für den Zusammenschluss 

großer Installationen bietet 

OpenNebula Zones. Zones (oZones) ermöglichen 

die zentrale Überwachung 

und Konfiguration individueller Open- 

Nebula-Einzelinstallationen. Dies erlaubt 

die vollständige Isolation einzelner Bereiche 

über die Versionsgrenzen hinweg 

und die gleichzeitige zentrale Steuerung 

der Umgebung. 

Diese Trennung kann das Applikationsprofil, 

aber auch den Standort oder Kunden 

berücksichtigen. Auch wenn man 

eine Vielzahl von OpenNebula-Installationen 

zusammenfasst, ist eine unabhängige 

Steuerung der Einzelsysteme 

möglich. Somit ist die maximale Freiheit 

in der jeweiligen Einzelumgebung bei 

Listing 1: Ressourcen ändern 

01 { 

02 "name": "ONE‐SCALE", 

03 "deployment": "none", 

04 "roles": [ 

05 { 

06 "name": "appserver", 

07 "cardinality": 2, 

08 "vm_template": 0, 

09 

10 "min_vms" : 5, 

11 "max_vms" : 10, 

12 

13 "elasticity_policies" : [ 

14 { 

15 // +2 VMs when the exp. is true for 3 times in a row, 

16 // separated by 10 seconds 

17 "expression" : "CONNECTION > 2000", 

18 

19 "type" : "CHANGE", 

20 "adjust" : 2, 

21 

22 "period_number" : 3, 

23 "period" : 10 

24 }, 

25 { 

26 // ‐10 percent VMs when the exp. is true. 

27 // If 10 percent is less than 2, ‐2 VMs. 

28 "expression" : "CONNECTION < 2000", 

29 

30 "type" : "PERCENTAGE_CHANGE", 

31 "adjust" : ‐10, 

32 "min_adjust_step" : 2 

33 } 

34 ] 

35 } 

36 ] 

37 } 


OpenNebula 


gleichzeitiger zentraler Zusammenfassung 

und Überwachung gewährleistet. 

Neues in Version 4.2 

Bereits mit der Version 4.0 haben viele 

neue Features in OpenNebula Einzug 

gehalten. Gerade im Bereich der Virtualisierungsschicht 

bietet OpenNebula mit 

Features wie Realtime Snapshots und 

Capacity Resizing nun alles, um auch 

mit kommerziellen Lösungen auf Augenhöhe 

zu agieren. Die bereits angesprochene 

Neuerung der Weboberfläche ist 

sicherlich die auffälligste Veränderung 

und verbindet nun die früher getrennten 

Sichten für Admin und Self Service in 

einer Oberfläche. 

Besonders erwähnenswert sind die beiden 

neuen Komponenten OpenNebula Gate 

und OpenNebula Flow. Gate ermöglicht es 

dem Anwender, mithilfe eines Sicherheits- 

Tokens Informationen zwischen VMs und 

OpenNebula auszutauschen. Eine bei 

Template-Erzeugung erstellte URL kann 

so Applikationsmetriken an OpenNebula 

übergeben und mit Hilfe von Sunstone visualisieren. 

Ein Beispiel wäre, die aktiven 

Connections eines virtualisierten Loadbalancers 

in regelmässigen Abständen an 

OpenNebula zu übergeben. 

Sinnvoll ist die anschließende Verarbeitung 

dieser Informationen mit der neuen 

Komponente Flow. Die früher als App- 

Flow verfügbare Erweiterung ist seit 4.2 

fester Bestandteil und wurde im Rahmen 

der Übernahme stark erweitert. Mit Hilfe 

von Flow lassen sich statische, aber auch 

dynamische Regeln auf Basis von Open- 

Nebula-Gate-Werten ausführen. 

Hier trennt OpenNebula in sogenannte 

Scheduled Policies und Elasticity Policies 

(Abbildung 3). Scheduled Policies 

erlauben, wie der Name bereits vermuten 

lässt, die zeitgesteuerte Veränderung von 

Ressourcen-Pools. So können Applikationsserver 

in der Nacht oder am Wochenende 

nach statischen Regeln heruntergefahren 

werden, wenn deren Leistung 

nicht benötigt wird. 

Elasticity Policies können nach Regeln 

und unter Berücksichtigung von Gate- 

Werten Änderungen an Pools vornehmen. 

Nach Definition von Minimal- und 

Maximalgröße eines Pools werden regelgesteuert 

virtuelle Maschinen gestartet 

oder heruntergefahren. Unter Verwendung 

von Expressions und Period-Regeln 

lassen sich dann in variablen Intervallen 

die verfügbaren Ressourcen ändern. 

Listing 1 zeigt die Verwendung einer dynamischen 

Regel auf Basis der Connections. 

Die per OpenNebula Gate übermittelte 

Anzahl aktiver Connections wird 

geprüft und führt in der ersten Teilregel 

nach dreifacher Überschreitung zum Start 

zweier neuer Systeme. Die zweite Teilregel 

erlaubt die Reduzierung des Pools, 

wenn sich die Connections um einen bestimmten 

Prozentsatz verringern. 

Durch Verbindung von dynamischen 

Applikatonsinformationen mit den Möglichkeiten 

des OpenNebula-Kerns sind 

dem Management komplexerer Applikationsszenarien 

keinerlei Grenzen gesetzt. 

Die Syntax ist selbsterklärend und Regeln 

sind in kurzer Zeit für vielfältige Szenarien 

verwendbar. Damit erfüllt OpenNebula 

eine wichtige Anforderungen von 

Applikationsbetreibern und erlaubt die 

bedarfsgerechte Ressourcenzuweisung. 

Da OpenNebula auch über eine Schnittstelle 

zu AWS verfügt, können auch Systeme 

in Richtung AWS als Hybrid-Cloud- 

Modell ausgelagert werden. 

Warum OpenNebula? 

OpenNebula ist eine mächtige Verwaltungs- 

und Provisioning-Plattform für 

das virtualisierte Rechenzentrum. Nach 

Einarbeitung in den Stack und die verwendeten 

Subsysteme wird der Themenkomplex 

Cloud greifbar und die eine oder 

andere Komponente, die seit Jahren im 

Einsatz ist, bekommt unter der Verwaltung 

von OpenNebula einen ganz neuen 

Anstrich. 

Klar wird aber auch, dass Cloud-Computing 

nicht zwangsläufig die Auslagerung 

aller Dienste in fremde Wolken bedeuten 

muss, sondern dass es auch für den eigenen 

Betrieb enorme Chancen bietet. 

OpenNebula erfreut sich gerade dabei als 

Open-Source-Alternative zu VMware immer 

größerer Beliebtheit [6]. Gerade die 

Verwendung heterogener Komponenten 

und die hohe Integrationsfähigkeit zeichnen 

OpenNebula dabei aus, weil es damit 

auch für gewachsene IT-Infrastrukturen 

einen umfassenden Architekturansatz 

bietet. (jcb) 

n 

Abbildung 3: OpenNebula kennt sogenannte Schedulded und Elasticity Policies für die automatische 

Anpassung der Ressourcen. 

Infos 

[1] OpenNebula: [http:// opennebula. org] 

[2] Zwei Cloud-Modelle: [http:// blog. 

opennebula. org/ ? p=4042] 

[3] Design-Guide: [http:// opennebula. org/ 

documentation:rel4. 2# designing_and_installing_your_cloud_infrastructure] 

[4] Distributionspakete: [http:// opennebula. 

org/ documentation:rel4. 2:ignc] 

[5] Source Code: [http:// opennebula. org/ 

documentation:rel4. 2:compile] 

[6] OpenNebula-Konferenz: [http:// 

opennebulaconf. com] 


Admin 


33


CloudStack 

© Shen En-Min, 123RF 

Praxiserprobte, freie Cloud 

Gut vernetzt 

Apache CloudStack ist eine Open-Source-Plattform, die Rechenressourcen 

zusammenführt, um daraus Public-, Private- und Hybrid-IaaS-Clouds zu 

bilden (Infrastructure as a Service). Apache CloudStack managet dabei 

Netzwerk-, Storage- und Compute-Knoten, die zusammen die Infrastruktur 

einer Cloud ausmachen. Geoff Higginbottom 

CloudStack begann sein Leben unter 

dem Namen VMOps in einer 2008 gegründeten 

Firma, die von Sheng Liang 

angeführt wurde, der zuvor bei Sun die 

virtuelle Maschine von Java entwickelt 

hatte. Die allerersten Versionen waren 

noch eng an Xen gebunden, aber schon 

bald erkannte das Team die Vorteile der 

Unterstützung verschiedener Hypervisor. 

Früh im Jahr 2010 gelang der Firma ein 

großer Schritt nach vorn, indem sie die 

Domain cloud.com erwerben konnte und 

die erste Version von CloudStack veröffentlichte, 

die bereits zu 98 Prozent 

freie Software war. Im Juli 2011 wurde 

CloudStack dann von Citrix Systems 

übernommen und auch der verbleibende 

Code unter die GPLv3 gestellt. 

Die nächsten großen Neuigkeiten standen 

im April 2012 an, als Citrix CloudStack 

an die Apache Foundation abgab, wo 

es zunächst als Incubator-Projekt angenommen 

wurde. Im Gegenzug zog sich 

Citrix aus der CloudStack-Initiative zurück. 

Heute ist CloudStack ein Top-Level- 

Projekt der Apache Software Foundation, 

was auch von der Reife des Codes und 

der Qualität der Community zeugt. 

CloudStack bedient verschiedene Unternehmensstrategien 

und unterstützt 

gleichzeitig verschiedene Cloud-Ansätze 

aus der Provider-Perspektive. 

Von Private bis Public 

Gehen Firmen den ersten Schritt über 

die klassische Server-Virtualisierung hinaus, 

erscheinen vielen von ihnen Private 

Clouds als Mittel der Wahl, um sowohl 

die Flexibilität zu erhöhen als auch die 

Kontrolle über die benutzten Services zu 

behalten. Diese Private Clouds können 

sowohl von der eigenen IT-Abteilung 

gehostet als auch von einem externen 

Provider bezogen werden: In jedem Fall 

bleibt das Ziel – umfassende Kontrolle 

und Sicherheit ohne Verletzung von SLAs 

– gewahrt. 

Am anderen Ende des Spektrums finden 

sich die Public-Cloud-Anbieter mit elastischer 

Skalierung der Ressourcen und 

Abrechnung nach Verbrauch (Abbildung 

1). Während Public Clouds oft von Details 

wie der Netzwerktopologie abstrahieren, 

bieten schließlich Hybrid Clouds als weitere 

Variante die Möglichkeit, die Schlüsselaspekte 

unter Kontrolle zu behalten 

und gleichzeitig vom Angebot an freier, 

nach Bedarf skalierender Kapazität zu 

profitieren. 

Die wichtigsten 

CloudStack-Features 

Unterstützung mehrerer Hypervisor: 

CloudStack arbeitet mit diversen Hypervisor 

zusammen und eine einzelne 

Cloud-Installation kann mehrere Hypervisor 

enthalten. Das gegenwärtige 

CloudStack-Release unterstützt Citrix 

XenServer und VMware vSphere sowie 

KVM und Xen unter Ubuntu und Cent OS. 

Die Unterstützung für Hyper-V wird momentan 

entwickelt und in ein kommendes 

Release einfließen. 

Massiv skalierbare Infrastruktur: 

CloudStack kann mit Zehntausenden 


CloudStack 


Servern in geografisch verteilten Rechenzentren 

umgehen. Das zentralisierte 

Management skaliert linear und braucht 

daher keine extra Zwischenschicht auf 

Cluster-Ebene. Der Ausfall einer Komponente 

führt niemals zu einem Clusterweiten 

Stillstand. Periodische Wartungsarbeiten 

können durchgeführt werden, 

ohne die laufenden virtuellen Maschinen 

zu beeinträchtigen. 

Automatisches Konfigurationsmanagement: 

CloudStack konfiguriert die Netzwerk- 

und Storage-Settings seiner Clients 

automatisch. Es verwaltet einen internen 

Pool virtueller Appliances, die den Cluster 

als solchen unterstützen. Diese Appliances 

offerieren Dienste wie Firewalling, 

Routing, DHCP, VPN, Konsolenzugänge, 

Speicherplatz und Storage-Replikation. 

Die ausgedehnte Verwendung virtueller 

Appliances vereinfacht dabei Installation, 

Konfiguration und Verwaltung. 

Grafisches Benutzer-Interface: Cloud- 

Stack bietet sowohl dem Administrator 

wie auch dem Enduser ein grafisches 

Benutzer-Interface an. Damit lässt sich 

die Cloud als Ganzes verwalten und es 

können auch einzelne virtuelle Maschinen 

gestartet und angehalten werden. 

Das GUI kann dem Look&Feel des Providers 

oder des Kundenunternehmens 

angepasst werden. 

API und Erweiterbarkeit: Alle Funktionen 

des Benutzer-Interfaces sind auch 

über ein API erreichbar. Auf dessen Basis 

lassen sich Command Line Tools oder 

grafische Werkzeuge für spezielle Bedürfnisse 

programmieren. Für die Zuteilung 

von Storage oder Hosts kann man neue 

Module entwerfen, die sich in die vorhandene 

Architektur einklinken können. 

CloudStack kann Amazon Web Services 

(AWS) EC2- und S3-API-Calls in native 

CloudStack-API-Aufrufe übersetzen. Daher 

können Benutzer auf Wunsch weiter 

mit ihren gewohnten AWS-Tools arbeiten. 

CloudMonkey ist dagegen ein spezielles, 

in Python geschriebenes Command Line 

Interface (CLI) für CloudStack. Mit seiner 

Hilfe lassen sich leicht Skripte programmieren, 

die komplexe Abläufe bei der 

CloudStack-Administration automatisieren. 

Mehr Informationen dazu finden 

sich bei [1]. 

Der Zugriff auf die API – direkt oder via 

CloudMonkey – wird durch eine Reihe 

von geheimen Schlüsseln und einem Signature 

Hash geschützt. 

Hochverfügbarkeit: CloudStack enthält 

eine Reihe von Features zur Verbesserung 

der Verfügbarkeit. Der Management-Server 

selbst lässt sich in einem Multinode- 

Cluster hinter einem Load Balancer installieren. 

Der Ausfall eines Rechners des 

Clusters würde dann der Load Balancer 

auffangen. Der MySQL-Server kann im 

Interesse einer höheren Verfügbarkeit repliziert 

werden. Gegen den Ausfall des 

Ethernet-Interfaces schützt NIC-Bonding 

(auch bekannt als Trunking oder Teaming) 

oder iSCSI-Multipathing im Storage-Bereich. 

Die Hierarchie der 

Schlüsselkomponenten 

CloudStack besteht aus sechs Schlüsselbausteinen. 

Da wären auf der obersten 

Ebene die Regionen, die ungefähr den 

AWS-Regionen entsprechen. Sie sind 

das erste und größte Bauelement von 

CloudStack. 

Jede Region besteht aus einer oder mehreren 

Verfügbarkeitszonen, dem zweitgröß- 

ten Element. Typischerweise entspricht 

eine solche Zone einem Rechenzentrum. 

Jede Zone enthält Pods, Cluster, Hosts 

und Storage. 

Pods, die drittgrößte Einheit, entsprechen 

oft einem Rack mit Netzwerk-, Rechenund 

Speicherkomponenten. Pods haben 

logische wie physische Eigenschaften, 

beispielsweise eine IP-Adresse. Die Verteilung 

der VMs wird durch Pods beeinflusst. 

Die viertgrößte Einheit sind die Cluster. 

Sie fassen homogene Rechner und Primary 

Storage zu Gruppen zusammen. 

Pro Cluster läuft nur ein bestimmter Hypervisor 

– aber in einer Zone können 

alle unterstützten Hypervisor versammelt 

sein. 

Hosts finden sich auf der fünften Ebene, 

sie bilden den eigentlichen Rechen-Layer, 

auf dem die virtuellen Maschinen laufen. 

Der letzte Baustein ist schließlich der 

Storage. Er kommt in zwei Ausprägungen 

vor, als Primary und Secondary Storage. 

Den Primary Storage verwenden 

die virtuellen Maschinen. Dabei kann 

es sich um lokalen oder Shared Storage 

handeln (NFS, iSCSI, Fibre Channel und 

so weiter). 

Der Secondary Storage nimmt die Virtual 

Machine Templates, ISO-Images 

und Snapshots auf und wird derzeit immer 

mit NFS realisiert. Swift kann verwendet 

werden, um Secondary Storage 

zwischen Zonen zu replizieren, sodass 

User auch bei Ausfall einer Zone immer 

noch Zugriff auf die Snapshots haben. Im 

Moment wird an ziemlich vielen neuen 

Storage-Features entwickelt, die dann in 

eines der nächsten Releases Einzug halten 

werden. 

Private Clouds 

Public Clouds 

On-Premise 

Enterprise Cloud 

Hosted 

Enterprise Cloud 

Multi-Tenant 

Public Cloud 

Dedicated Resources 

Security and Total Control 

Internal Network 

Managed by Enterprise or 3rd Party 

Dedicated Resources 

Security 

SLA Bound 

3rd Party Owned and Operated 

Mix of Shared and Dedicated Resources 

Elastic Scaling 

Pay As You Go 

Public Internet VPN Access 

Abbildung 1: Die verschiedenen Ausprägungen privater und öffentlicher Clouds in der Übersicht. 


Admin 


35


CloudStack 

Das Verbindungsglied zwischen all den 

Bauelementen ist der Netzwerk-Layer. 

CloudStack kennt zwei Netzwerkmodelle: 

Basic und Advanced. 

Networking 

Basic Networking entspricht dem Modell, 

das AWS benutzt, und kann auf 

drei Arten eingesetzt werden, wobei jede 

ein paar weitere Features zum Vorgänger 

hinzufügt: 

n Als einfaches, flaches Netzwerk, in 

dem sich alle VMs einen Adressbereich 

teilen. Isolation gibt es hier nicht. 

n Als Netzwerk mit Security Groups, die 

über Layer-3-Adressfilter ddie VMs 

voneinander isolieren. 

n Als Modell mit Elastic-IP und Elastic 

Load Balancing. Dabei bietet ein 

von CloudStack orchestrierter Citrix 

Net Scaler öffentliche IP-Adressen und 

Load Balancer an. 

Alle drei Ausprägungen des Basic-Netzwerkmodells 

erlauben eine massive 

Skalierung, solange der von den VMs 

genutzte IP-Adressbereich sich innerhalb 

eines Pods befindet. Zonen skalieren horizontal 

durch Hinzufügen weiterer Pods, 

die ihrerseits aus Clustern und Hosts bestehen 

samt den dazugehörigen Netzwerk- 

und Primary-Storage-Ressourcen. 

Fortgeschrittenes 

Netzwerken 

Das Advanced-Netzwerk-Modell bringt 

dem Anwender zusätzlich jede Menge 

mächtiger Features. So sind dort VLANs 

die Standardmethode der Isolation, noch 

darüber hinaus gehen aber die Angebote 

für Software Defined Networks (SDN) 

von Nicira, BigSwitch und bald auch von 

Midokura, die die Beschränkungen von 

VLANs hinter sich lassen. 

CloudStack macht ausgiebigen Gebrauch 

von systemeigenen VMs zur Kontrolle 

und Automation von Storage und Netzwerk. 

Eine solche System-VM ist der 

CloudStack Virtual Router. Die VM mit 

dem unschuldig klingenden Namen stellt 

in Wirklichkeit folgende Dienste bereit: 

DNS und DHCP, Firewall, Client IPsec 

VPN, Load Balancing, Source/Static NAT 

und Port Forwarding. Alle diese Dienste 

sind vom Enduser über die CloudStack- 

GUI oder die CloudStack-API frei konfigurierbar. 

Sobald ein Anwender ein neues Gastnetzwerk 

aufbaut und Gast-VMs in diesem 

Netzwerk erzeugt, werden diese 

VMs automatisch einer eigenen Layer-2- 

Broadcast-Domain zugeordnet, die von 

anderen Domains durch ein VLAN isoliert 

ist. Es besteht volle Kontrolle über 

den eingehenden und ausgehenden Traffic 

inklusive einer direkten Anbindung 

an das öffentliche Internet. 

Firewall- und Port-Forwarding-Regeln 

erlauben es, IP-Adressen auf jede gewünschte 

Anzahl von VMs zu mappen. 

Das Load Balancing ist mit Round-Robin-, 

Least-Connections- und auch mit 

Source-Based-Algorithmen verfügbar. 

App-Cookie- oder LB-Cookie-Stickiness- 

Policies sind von Anfang an verfügbar. 

Abbildung 2: Rechnen, speichern, vernetzen – der schematische Aufbau von CloudStack. 

Ein anderes leistungsstarkes Feature des 

Advanced-Network-Modells ist die Virtual 

Private Cloud (VPC). Damit ist es 

den Benutzern möglich, mehrschichtige 

Netzwerkkonfigurationen innerhalb der 

VLANs für ihre VMs anzulegen. Den Datenfluss 

zwischen den Netzwerkschichten 

und ins Internet kann der Anwender 

über ACLs steuern. Eine typische Konfiguration 

könnte beispielsweise die drei 

Schichten Web, App und DB enthalten, 

wobei nur der Web-Tier Internetzugang 

hätte. 

VPCs bringen darüberhinaus weitere 

Features mit, etwa Site-2-Site-VPNs, mit 

denen sich persistente Verbindungen in 

andere Rechenzentren oder sogar andere 

Clouds aufbauen lassen. Weiter gibt es 

ein VPC-Private-Gateway, das ein zweites 

Gateway neben dem Virtual Router bereitstellt 

und die Verbindung zu anderer 

Infrastruktur, etwa einem MPLS-Network 

anstelle des Internet, ermöglicht. 

Traffic aufteilen 

CloudStack optimiert die Verwendung 

der Netzwerkarchitektur eines Rechenzentrums 

durch die Aufspaltung des Traffics 

auf verschiedene Gruppen einzelner 

oder gebondeter NICs eines Compute- 

Knotens. Insgesamt können vier Typen 

physischer Netzwerke konfiguriert werden, 

die jeweils ein Interface oder einen 

Interface-Verbund (Bond) nutzen. Die 

vier Typen sind: 

Management: Zur Verwendung mit den 

CloudStack-Management-Servern und 

anderen Komponenten. Wird manchmal 

das Orchestration Network genannt. 

Guest: Für alle Gast-VMs zur Kommunikation 

mit anderen Gästen oder Gateways 

wie den Virtual Routers, Juniper 

SX Firewalls, F5 Load Balancers und so 

weiter. Im Advanced-Modus lassen sich 

mehrere Gastnetzwerke einrichten, die 

dann einzelnen Gästen oder Funktionen 

zugeordnet werden können. 

Public: Verbindet im Advanced-Modus 

die Virtual Router mit dem öffentlichen 

Internet. Im Basic Network Mode existiert 

es nur, wenn ein Citrix NetScaler 

verwendet wird. In diesem Fall stellt es 

die Elastic-IP- und Elastic-LB-Services 

bereit. 

Storage: Wird verwendet, um die Verbindung 

zum Secondary Storage herzustel- 


len. So optimiert es den Traffic, 

der beim Erstellen neuer VMs 

aus Templates oder beim Anlegen 

von Snapshots entsteht. 

Diese netzwerkintensiven Operationen 

beeinträchtigen so anderen 

Verkehr nicht. 

Auch der Netzwerkverkehr 

zur Anbindung des Primary 

Storage lässt sich aus Gründen 

der Verfügbarkeit oder Performance 

auf bestimmte NICs 

auslagern. 

Network Service 

Provider 

Neben den Virtual Routern und 

den VPC-Virtual-Routern kann 

CloudStack außerdem echte 

Hardware nutzen. Derzeit werden 

Citrix NetScaler, F5 Big IP 

und Juniper SRX unterstützt, 

an der Integration weiterer Modelle 

wird gearbeitet. 

Sobald ein solches Device integriert 

wurde, kann es der 

Anwender über die Standard- 

GUI oder -API administrieren. 

Der Anwender konstruiert 

die Firewall-Regeln dann der 

CloudStack-GUI. CloudStack 

seinerseits greift dabei auf eine 

API des Herstellers zurück, um 

die Konfiguration an das physische 

Gerät zu übermitteln. 

Wird ein Citrix NetScaler eingesetzt, 

dann ermöglicht er neben 

Load Balancing, NAT und 

Port Forwarding auch AutoScaling. 

Dahinter verbirgt sich 

eine Methode, die Performance 

laufender Gast-VMs zu überwachen 

und bei Bedarf neue 

VMs zu erzeugen. Sinkt die 

Auslastung später wieder unter 

einen Schwellwert, werden 

die zusätzlich erzeugten VMs 

wieder entfernt, um die Kosten 

wieder auf das Ausgangsniveau 

zu senken. Genau ein solches 

Maß an Automatisierung und 

Flexibilität ist die treibende 

Kraft des Cloud Computing. 

Tatsächlich ist CloudStack 

dank seiner GUI, API und den 

CLI-Tools wie CloudMonkey 

leicht aufzusetzen und zu administrieren. 

Ein Wizard begleitet 

den Anwender durch 

die Konfiguration seiner ersten 

Zone-, Networking-, Pod-, 

Cluster-, Host- and Storage- 

Komponente. Das kann bereits 

binnen einiger Stunden erledigt 

sein. 

Management 

Ein einfaches Rollen-basiertes 

Rechtesystem (Role Based Access 

Control, RBAC) definiert 

schon verschiedene Berechtigungs-Level, 

die bei Bedarf 

verfeinert werden können. Die 

Authentifikation kann außerdem 

in ein LDAP-System ausgelagert 

werden (Open LDAP 

oder MS Active Directory). 

Neue Accounts, die Admins anlegen 

können, gehören stets zu 

einer Domain. Auf diese Weise 

entsteht eine hierarchische 

Struktur, die es erlaubt, einen 

bestimmten Ausschnitt der Infrastruktur 

einer bestimmten 

Gruppe von Nutzern zugänglich 

zu machen. Darüberhinaus 

können die Admins über 

Parameter einstellen, wieviel 

vCPUs, RAM und Bandbreite 

bestimmten Anwendern zur 

Verfügung stehen, welches Betriebssystem, 

welche Hardware 

oder welchen Storage sie nutzen 

können. 

Admins haben die volle Kontrolle 

über die Infrastruktur und 

können die Live-Migration jeder 

VM innerhalb eines Clusters 

anstoßen. Angehaltene 

VMs können auch zwischen 

Clustern migriert werden, 

wenn man die ihnen zugeordneten 

Volumes auf den neuen 

Storage verschiebt. 

Benutzererfahrung 

Ein großer Pluspunkt von 

CloudStack ist das gut durchdachte, 

grafische Benutzer-Interface. 

Die Mehrzahl aller Features 

ist über diese GUI verfüg- 


Admin 


37


CloudStack 

GUI 

API 

Abbildung 3: Ein Load Balancer verteilt die Management-Aufgaben auf eine Gruppe von Servern und sorgt so 

gleichzeitig für Ausfallsicherheit. 

bar, nur einige wenige fortgeschrittenere 

erreicht man nur via API. Wegen dieser 

leicht erlernbaren Benutzeroberfläche 

können neue Anwender ihre ersten VMs 

innerhalb weniger Minuten nach ihrem 

ersten Login zum Laufen bringen. 

In sechs Schritten zur 

ersten Cloud 

Das Anlegen einer neuen virtuellen Maschine 

in der GUI vollzieht sich in sechs 

einfachen Schritten: 

n Wahl der Availability Zone, 

n Wahl eines vorgefertigten Templates 

oder ISOs, 

n Auswahl des sogenannten Compute 

Offerings, das über die Anzahl CPUs, 

RAM, Netzwerkbandbreite und Storage 

Tier bestimmt, 

n Konfiguration eines zusätzlichen Daten-Volumes, 

n Anschluss an ein Netzwerk oder einen 

VPC; falls das nicht existiert, wird es 

automatisch erzeugt, 

Load Balancing 

View all 

Internet 

Firewall 

Load Balancer 

View all 

Port Forwarding 

Multi-Node Deployment 

View all 

Abbildung 4: Eine Konfigurationsseite für die 

Virtual-Router-VM in CloudStack. 

Management 

Server 

Management 

Server 

Management 

Server 

MySQL 

DB 

Zones 

n Vergabe eines Namens, der auch als 

Hostname der VM fungiert. Start der 

VM. 

Sobald die ersten VMs laufen, kann der 

Anwender andere Features erkunden, die 

für sie zur Verfügung stehen. So bieten 

beispielsweise Snapshots eine effektive 

Möglichkeit, jede VM abzusichern. Ein 

Snapshot jedes Volumes lässt sich entweder 

ad hoc oder zeitgesteuert anlegen 

(stündlich, täglich, wöchentlich). Werden 

von einer VM mehrere Exemplare benötigt, 

kann man die schnell aus benutzerdefinierten 

Templates generieren, die 

man aus einer VM oder ihrem Snapshot 

gewinnt. 

Volumes, Snapshots und Templates lassen 

sich exportieren, um dieselbe Benutzerumgebung 

in einer anderen Cloud 

wieder anzulegen. 

Warum CloudStack? 

MySQL 

DB 

CloudStack hat eine jederzeit vorzeigbare 

Erfolgsbilanz sowohl im Unternehmensumfeld 

wie bei Service Providern – die 

weltweit größten Clouds basieren auf seiner 

Technologie. Der Autor selbst war bei 

drei großen Implementierungen auf drei 

verschiedenen Kontinenten beteiligt, und 

obwohl es bei jedem großen IT-Projekt 

ein paar Schwierigkeiten gibt, wurden 

alle drei in der geplanten Zeit fertig. 

Im Unterschied zu anderen Open-Source- 

Cloud-Projekten ist CloudStack ein in 

sich abgeschlossenes Projekt mit einheitlichen 

Grundsätzen und Zielen, getragen 

von einer sehr aktiven Community. 

Die Liste der Features, an denen derzeit 

entwickelt wird, ist wahrhaft atemberaubend. 

Nur einige Beispiele für kommende 

Features sind: 

n Ein neues Storage Framework, das 

größere Kontrolle erlaubt und bei dem 

Primary Storage an beliebiger Stelle 

im gesamten Rechenzentrum lokalisiert 

sein kann. 

n XenMotion, das XenServern die Live- 

Migration ihrer VMs ermöglicht. 

n Dedizierte Ressourcen, die sich für 

einen bestimmten Nutzer reservieren 

lassen. 

n Support für das Cisco Virtual Network 

Management Center (VNMC). 

n Mehrere IPs pro Virtual-NIC – das eignet 

sich ideal für Webserver-VMs mit 

mehreren SSL-Zertifikaten. 

n S3 Backed Secondary Storage. 

n Dynamic Scaling für CPU und RAM – 

das ermöglicht das vollautomatische 

Vergrößern und Verkleinern dieser 

Ressourcen einer VM. 

n Support für Midokura Software Defined 

Networking. 

n Zusätzliche Isolation innerhalb eines 

VLANs – unter Verwendung der 

PVLANs (VMware) oder von Security 

Groups (Xen und KVM). 

Zu den Stärken von CloudStack zählt 

seine erprobte, massive Skalierbarkeit: es 

existieren in der Praxis Clouds mit mehr 

als 50 000 Hosts im Produktivbetrieb. 

Die Inbetriebnahme einer Cloud ist bei 

CloudStack in aller Regel nur eine Frage 

von Tagen, nicht von Monaten. 

Die Dokumentation ist exzellent. Es existiert 

ein sicherer Upgrade-Pfad von allen 

Vorgängerversionen auf das aktuelle Release. 

Das grafische User Interface als 

Herzstück einer CloudStack-Implementation 

ist ausgereift und intuitiv bedienbar. 

CloudStack ist das beste Einzelprojekt 

zum Aufbau einer IaaS-Plattform. 

CloudStack unterstützt verschiedene 

SDNs gleichzeitig. Es ist AWS-kompatibel. 

(jcb) 

n 

Infos 

[1] CloudMonkey: [https:// cwiki. apache. 

org/ confluence/ display/ CLOUDSTACK/ 

CloudStack+cloudmonkey+CLI] 

Der Autor 

Geoff Higginbottom arbeitet als CTO und Cloud 

Architect bei der Londoner Beratungsfirma Shape 

Blue und war für mehrere große, internationale 

Cloud-Projekte auf der Basis von CloudStack verantwortlich. 



Eucalyptus 

© petervick167, 123RF 

Die eigene AWS-kompatible Cloud mit Eucalyptus 

Koalas Liebling 

Wer den Cloud-Diensten von Amazon nicht traut oder aus Datenschutzgründen dort keine Kundendaten ablegen 

kann, der schafft sich mit Eucalyptus kurzerhand seine eigene Cloud. Die ist sogar zu den Amazon-Werkzeugen 

kompatibel und dank eines vorbereiteten Installationsmediums ruck, zuck aufgesetzt. Tim Schürmann 

Eucalyptus entstammt ursprünglich einem 

Forschungsprojekt an der University 

of California [1]. Im Jahr 2009 übernahm 

dann das ausgegründete Unternehmen 

Eucalyptus Inc. die Weiterentwicklung 

und Vermarktung. Die Software gibt es 

seitdem in zwei Geschmacksrichtungen: 

kostenlos als Open-Source-Variante, die 

komplett unter der GPLv3-Lizenz steht, 

und die kommerzielle Eucalyptus Enterprise 

Edition, die unter anderem die Einbindung 

von SANs und einer VMware- 

Infrastruktur ermöglicht. 

Amazon zu Hause 

Eucalyptus baut aus mehreren Rechnern 

eine Cloud zusammen, in der man virtuelle 

Maschinen starten und Speicherplatz 

abrufen kann – ganz so, wie es Amazon 

mit seinen AWS-Diensten anbietet. Bei 

Eucalyptus ist man jedoch selbst der Betreiber 

der Cloud. Administratoren haben 

nicht nur die vollständige Kontrolle, die 

Server und somit die Daten verbleiben 

auch im eigenen Unternehmen. Eine Eucalyptus-Cloud 

lässt sich sogar schnell 

auf nur einem Computer einrichten 

(siehe Kasten »Alle auf Einen«). 

Um mit Eucalyptus eine Cloud aufzubauen, 

benötigt man echte Rechner, 

deren Prozessoren über die Virtualisierungsfunktion 

Intel VT beziehungsweise 

AMD-V verfügen. Eine Testinstallation 

unter Virtualbox oder VMware ist somit 

nicht möglich, mit einem Trick klappt 

es jedoch unter KVM [2]. Zudem sollte 

in den Stationen jeweils mindestens 4 

GByte Hauptspeicher sowie eine 250 

GByte große Festplatte stecken – je mehr 

Speicher, desto mehr virtuelle Maschinen 

lassen sich später in der Cloud starten. 

Abschließend braucht man einen zusätzlichen 

Satz freier IP-Adressen, die Eucalyptus 

später den in der Cloud laufenden 

Systemen zuweisen kann. 

Kickstart 

Auch was das Betriebssystem anbelangt, 

ist Eucalyptus äußerst wählerisch: Offiziell 

unterstützen die Entwickler ausschließlich 

die 64-Bit-Versionen der Linux-Distributionen 

CentOS 6 und Red 

Hat Enterprise Linux 6. Für eine kurze 

Zeit war Eucalyptus auch offizieller Bestandteil 

von Ubuntu. Mit Ubuntu 11.10 


Eucalyptus 


Eucalyptus-Cloud 

Node Controller 

(192.168.100.11) 

Walrus 

Cloud Controller 

(CLC) 

Client 

(192.168.100.13) 

Frontend 

(192.168.100.10) 


(192.168.100.12) 

Storage Controller 

(SC) 

Cluster Controller 

(CC) 

G Abbildung 1: Für eine erste kleine Cloud genügen drei physische Rechner und 

ein Client für den Zugriff. Die Node Controller übernehmen die eigentliche Arbeit, 

das Frontend koordiniert sie. 

E Abbildung 2: Eucalyptus besteht aus mehreren Einzelteilen, die aufeinander 

aufbauen. 


(NC) 


(NC) 


(NC) 

(Oneiric) hat es Canonical jedoch gegen 

den Konkurrenten OpenStack ersetzt. Seit 

Eucalyptus 3.2 stellen die Eucalyptus- 

Entwickler zudem keine fertigen Ubuntu- 

Pakete mehr bereit. Eine Eucalyptus- 

Cloud unter RHEL oder CentOS aus den 

bereitgestellten Paketen zu installieren, 

ist obendrein recht zeitaufwendig, da 

die zugrunde liegenden Linux-Systeme 

zahlreiche Bedingungen erfüllen müssen 

– nicht umsonst umfasst die Installationsanleitung 

satte 96 Seiten. 

Glücklicherweise stellen die Eucalyptus- 

Entwickler ein spezielles Installationsmedium 

bereit, mit dem Administratoren in 

wenigen Mausklicks eine kleine Eucalyptus-Cloud 

aufsetzen. Diese FastStart 

genannte Installationsmethode kann aber 

auch als Ausgangspunkt für eine größere 

Cloud dienen: Da Eucalyptus gerne die 

Rechner der Cloud ganz für sich alleine 

haben möchte, können Administratoren 

sich die mühsame Einrichtung sparen, 

einfach die Festplatte der beteiligten 

Rechner löschen und dem FastStart- 

Alle auf Einen 

Die Eucalyptus-Komponenten darf man auch 

allesamt auf einem einzigen physischen Computer 

installieren. Die Eucalyptus-Entwickler 

unterstützen diese Betriebsart sogar ganz offiziell. 

Eine solche Cloud-In-A-Box eignet sich 

insbesondere für kleine Arbeitsgruppen sowie 

Administratoren, die mit den Einstellungen 

experimentieren möchten. 

Besonders schnell zu einer Cloud-In-A-Box 

kommt man ebenfalls mit dem FastStart-Medium: 

Im Bootmenü entscheidet man sich für 

den Punkt »Install CentOS 6 with Eucalyptus 

Cloud‐in‐a‐box«. Die dann vom Assistenten 

gestellten Fragen entsprechen der üblichen 

Installation. 

Image das Einrichten eines frischen 

Eukalyptus-Systems überlassen. Damit 

hat man ganz nebenbei auch schon eine 

funktionierende Basiskonfiguration und 

kann direkt loslegen. 

Der Zugriff und die Verwaltung der laufenden 

Cloud erfolgt von Client-Rechnern 

mit beliebigem Betriebssystem – entweder 

komfortabel mit der Maus in einer 

Weboberfläche oder aber über die offiziellen 

Kommandozeilenwerkzeuge, die 

sogenannten Euca2ools. Letztgenannte 

findet man auch in den Repositories der 

meisten großen Distributionen. 

Eucalyptus selbst besteht aus mehreren 

Komponenten, die jeweils eine ganz 

bestimmte Aufgabe erfüllen. Zunächst 

benötigt man einen oder mehrere Rechner, 

auf denen später die virtuellen Maschinen 

laufen und die zu speichernden 

Daten landen. Auf diesen Knoten (Nodes) 

läuft jeweils ein sogenannter Node 

Fünf ist Trumpf 

Eucalyptus besteht aus fünf Komponenten. Jeder 

von ihnen läuft als Webdienst und greift 

auf die Funktionen der anderen Dienste zurück 

(Abbildung 2). 

Node Controller (NC): Auf den Knoten arbeitet 

der sogenannte Node Controller (kurz NC). Er 

startet, stoppt und verwaltet die auf seinem 

Rechner laufenden virtuellen Maschinen. 

Cluster Controller (CC): Mehrere Knoten fasst 

der Cluster Controller (kurz CC) zu einem Cluster 

zusammen. Der Cluster Controller entscheidet 

darüber, welche virtuelle Maschine auf welchem 

Knoten startet und verwaltet das Netzwerk, in 

dem die virtuellen Maschinen hängen. 

Cloud Controller (CLC): Die Befehlsgewalt über 

die einzelnen Cluster hat der Cloud Controller 

(kurz CLC). Er bastelt aus den Clustern die 

eigentliche Cloud, trifft alle übergeordneten 

Controller (kurz NC). Im Wesentlichen 

startet, stoppt und verwaltet er die auf 

seinem Rechner laufenden virtuellen Maschinen. 

Dienstevielfalt 

Auf welchen der Knoten welche Maschinen 

laufen, entscheidet das Frontend. Es 

stellt zudem die Weboberfläche bereit 

und nimmt die Befehle des Administrators 

entgegen. Tatsächlich besteht auch 

das Frontend aus mehreren weiteren, einzelnen 

Diensten, die der Kasten »Fünf 

ist Trumpf« vorstellt. Dem Frontend 

sollte man ebenfalls einen eigenen Rechner 

spendieren. Eine erste kleine Cloud 

besteht somit aus zwei oder mehr Node- 

Controllern, die die eigentliche Arbeit 

verrichten und einem weiteren Rechner 

mit dem Frontend (wie in Abbildung 1). 

Dank der Trennung in die Komponenten 

Entscheidungen und nimmt die Anfragen der 

Benutzer entgegen. Er stellt auch die Weboberflächen 

bereit. 

Storage Controller (SC): Der Storage Controller 

fasst Speicherplatz zu sogenannten Volumes 

zusammen, die dann wiederum eine virtuelle 

Maschine einbinden oder als Block Device ansprechen 

kann. Der Funktionsumfang entspricht 

dabei Amazons Elastic Block Store (EBC). 

Walrus: Schließlich stellt die Komponente namens 

Walrus noch einen zu Amazon Simple Storage 

Service (S3) kompatiblen Speicherdienst 

bereit. Wie das Vorbild legt er Daten in sogenannten 

Buckets in der Cloud ab. Walrus kann 

man zum einen über die erwähnten Kommandozeilenwerkzeuge 

nutzen oder aber auch aus 

den virtuellen Maschinen heraus in Anspruch 

nehmen. 


Admin 


41


Eucalyptus 

kann man später die Cloud sukzessive 

vergrößern, indem man zum Beispiel 

weitere Node Controller hinzufügt. 

Gordische Knoten 

Das FastStart-Installationsmedium in 

Form eines kleinen ISO-Images erhalten 

Administratoren unter [3]. Das ISO- 

Image dient nur als Boot-Medium und 

holt sowohl ein komplettes CentOS 6 als 

auch die Eucalyptus-Pakete aus dem Internet 

nach. Die Rechner, die später die 

Cloud bilden sollen, müssen folglich an 

das Internet angebunden sein. 

Zunächst startet man das FastStart-Image 

auf den Rechnern, die später als Node 

Controller arbeiten sollen. In Abbildung 

1 würde man das Image auf den Rechnern 

mit der IP-Adresse 192.168.100.11 und 

192.168.100.12 starten. Im Bootmenü 

fällt die Entscheidung für den Punkt 

»Install CentOS 6 with Eucalyptus Node 

Controller«. Das Angebot, das Installationsmedium 

zu prüfen, lässt sich mit 

»Skip« überspringen. Anschließend geht 

es mit »Next« zur Wahl der Sprache, gefolgt 

von der Tastaturbelegung. 

Anschließend richtet man die Netzwerkkarte 

ein (Abbildung 3). Wer den 

Rechnern der Cloud ihre IP-Adressen per 

DHCP zuweist, muss sicherstellen, dass 

sie immer dieselbe Adresse erhalten, die 

dynamische Zuweisung unterstützt Eucalyptus 

nicht. »Weiter« geht es zu den 

Zeiteinstellungen, anschließend folgt das 

Passwort für den Benutzer »root« und die 

Festplattenaufteilung. Da die Node Controller 

viel Speicher benötigen, sollte man 

dem Assistenten den »Gesamten Platz« 

überlassen – was gleichzeitig die Festplatte 

komplett löscht. Nach dem Abnicken 

der Sicherheitsfrage teilt Eucalyptus 

die Festplatte dann nach eigenen Vorstellungen 

auf, holt das System aus dem 

Internet und richtet es ein. Dies kann 

je nach Rechnergeschwindigkeit einige 

Zeit benötigen. Abschließend muss man 

das System ohne das FastStart-Medium 

neu starten und sich als Benutzer »root« 

einloggen. 

Das jetzt startende Konfigurationsskript 

möchte als Erstes wissen, über welche 

Netzwerkschnittstelle der Rechner später 

mit dem Frontend erreichbar ist (Abbildung 

4). Die Eingabetaste übernimmt 

den Vorschlag. Bei der anschließenden 

Abbildung 3: Bei der Einrichtung der Netzwerkkarten kann man über »Advanced Network Configuration« auch 

den unter Linux allseits bekannten Network Manager zu Hilfe rufen. 

Einrichtung richtet das Skript eine Netzwerk-Bridge 

ein (in der Regel heißt sie 

»br0«), an die alle virtuellen Maschinen 

andocken und nach draußen kommunizieren. 

Per »ifconfig« kann man anschließend 

prüfen, ob die Netzwerkschnittstellen 

korrekt erkannt und zugeordnet 

wurden. Sollte man versehentlich die 

falsche Netzwerkschnittstelle erwischen, 

lässt sich das Einrichtungsskript per 

»/usr/local/sbin/eucalyptus‐nc‐config.sh« 

jederzeit erneut anwerfen. Die Rechner 

mit den Node Controllern können weiterlaufen. 

Stirnseite 

Hat man auf diese Weise alle Node Controller 

eingerichtet (in Abbildung 1 die Rechner 

192.168.100.11 und 192.168.100.12), 

folgt der Rechner, der alle übrigen Komponenten 

ausführt. Auch ihn startet man 

Abbildung 4: Die Einrichtung eines Node Controllers ist hier erfolgreich beendet. 

vom FastStart-Medium, wählt aber im 

Boot-Menü »Install CentOS 6 with Eucalyptus 

Frontend«. Die Installation des 

Systems erfolgt jetzt ganz analog zu den 

Node Controllern: Den Medientest übergeht 

man mit »Skip«, wählt Sprache und 

Tastaturbelegung, konfiguriert die Netzwerkkarten, 

stellt die Zeitzone ein und 

vergibt ein Root-Passwort. 

Als Nächstes muss man Eucalyptus einen 

freien IP-Adressbereich nennen. Aus ihm 

weist es später den virtuellen Maschinen 

ihre IP-Adressen zu. Die angegebenen 

Adressen müssen zudem zwingend aus 

dem gleichen Subnetz stammen, in dem 

der Rechner für das Frontend hängt. Im 

Beispiel aus Abbildung 1 könnte man 

die IP-Adressen 192.168.100.100 bis 

192.168.100.200 wählen. Ihre Eingabe 

erfolgt unter »Public IP range/list« mit 

einem Trennstrich, im Beispiel also »192. 

168.100.100‐192.168.100.200« (Abbil- 



Eucalyptus 

ein. Den nächsten Schritt kann man daher 

einfach bestätigen beziehungsweise 

bei Bedarf noch weitere NTP-Zeitserver 

»Hinzufügen«. 

Die Daten des Abschlussbildschirms 

sollte man sich gut notieren. Sie verschaffen 

Zugriff auf gleich zwei von Eucalyptus 

angebotene Weboberflächen: Über 

die User Console können Anwender unter 

anderem neue virtuelle Maschinen 

starten. Mit der Admin Console hingegen 

verwalten Administratoren die Cloud und 

richten insbesondere neue Benutzerkonten 

für die User Console ein. 

Klickibunti 

Abbildung 5: Bei der Installation des Frontends muss man einen Satz freie IP-Adressen spendieren. 

dung 5). Bei allen anderen Einstellungen 

kann man die Vorgaben akzeptieren, womit 

es »Weiter« zur Aufteilung der Festplatte 

geht. Dort sollte man wieder den 

»Ganzen Platz verwenden« und somit die 

Festplatte löschen lassen. Während der 

nun folgenden Installation erstellt der Assistent 

auch ein kleines Image mit einem 

kleinen CentOS-6-System, das man gleich 

direkt in der Cloud starten lassen kann. 

Der erste Neustart des Frontends dauert 

eine Weile und es kann so erscheinen, 

als würde das System hängen. Hier sollte 

man einfach auf die Festplattenaktivität 

achten. Irgendwann erscheint ein grafischer 

Assistent, der dazu auffordert, 

die Lizenz zu bestätigen. Im nächsten 

Schritt tippt man in das Feld die IP-Adressen 

aller Node Controller ein, jeweils 

durch ein Leerzeichen getrennt. Im Beispiel 

wäre das folglich »192.168.100.11 

192.168.100.12« (Abbildung 6). Wenn 

die IP-Adresse nicht bekannt ist, listet der 

Befehl »ifconfig« auf dem Node Controller 

sie auf. Nach einem Klick auf »Vor« fragt 

der Assistent noch die Root-Passwörter 

der Node Controller ab. 

Abschließend gilt es noch, einen normalen 

Benutzer für den Rechner mit dem 

Frontend anzulegen. Im Gegensatz zu 

den Node Controllern installiert das Fast- 

Start-Medium auf dem Frontend-Rechner 

eine vollständige grafische Benutzeroberfläche. 

Eucalyptus setzt voraus, dass die 

Uhren auf allen Rechnern absolut synchron 

laufen. Um dies sicherzustellen, 

richtet das über das FastStart-Medium 

installierte Eucalyptus einen NTP-Server 

Um in der neu aufgebauten Cloud eine 

erste virtuelle Maschine zu starten, steuert 

man folglich die neben »User Console« 

notierte Internetadresse im Browser 

an. Da die beiden Weboberflächen 

ausschließlich gesicherte Verbindungen 

zulassen, muss man bei der Eingabe 

der Internetadresse darauf achten, das 

HTTPS-Protokoll zu verwenden. Die 

komplette Adresse folgt dem Schema: 

»https://Frontend‐Rechner:8888«. Aufrufen 

lässt sie sich von einem beliebigen 

Client-Rechner, in Notfällen kann man 

sich aber auch direkt auf dem Rechner 

mit dem Frontend anmelden und dort 

den beigelegten Firefox verwenden. 

Der Browser beschwert sich jetzt als Erstes 

über ein nicht vertrauenswürdiges 

Zertifikat, das man einfach akzeptiert 

beziehungsweise als Ausnahme hinzufügt 

und damit am Anmeldebildschirm 

landet. Direkt nach der Installation erhält 

man Zugang mit dem Account-Namen 

»demo«, dem User Name »admin« und 

Abbildung 6: Beim ersten Start des Frontends muss man die IP-Adressen der 

Node Controller hinterlegen. 

Abbildung 7: Die User Console bietet Zugriff auf alle wichtigen Funktionen der 

neu eingerichteten Cloud. 


Eucalyptus 


dem Passwort »demo«. Es erscheint das 

Dashboard, das einen Überblick über die 

gerade laufenden virtuellen Maschinen 

(Abbildung 7) gibt. Eucalyptus bezeichnet 

sie als Instanzen – aus einem Betriebssystem-Image 

lassen sich mehrere 

unabhängige Instanzen starten. 

Ein Klick auf »Launch new Instance« 

startet eine neue virtuelle Maschine. Die 

Weboberfläche zeigt jetzt an, welche 

Betriebssystem-Images in der Cloud zum 

Starten bereitstehen. Für einen ersten 

Test bringt das FastStart-Medium bereits 

ein kleines CentOS-6-System mit. Um es 

anzuwerfen, klickt man es an und der 

Hintergrund wird grün eingefärbt. Weiter 

geht es über den Knopf »Select Type«. 

Dort wählt man in der Ausklappliste 

»Select instance type« die Hardware der 

virtuellen Maschine. Das kleine CentOS- 

6-System benötigt nur eine CPU und 256 

MByte Speicher, sodass die vorgeschlagene 

Maschine vom Typ »m1.small« ausreicht 

(Abbildung 8). Die übrigen Einstellungen 

können ebenfalls auf ihren 

Abbildung 8: Eucalyptus lässt die Wahl zwischen verschiedenen virtuellen Computermodellen mit 

unterschiedlicher Hardware. 

Kommandozeilenwerkzeuge 

Eine virtuelle Maschine starten und stoppen 

kann man auch auf der Kommandozeile mit der 

Werkzeugsammlung Euca2ools. Viele Linux-Distributionen 

bieten sie in ihren Repositories an, 

auch auf dem Frontend-Rechner sind sie bereits 

installiert. Um die Euca2ools einsetzen zu können, 

muss man sich zunächst als rechtmäßiger 

Benutzer der Cloud ausweisen. Dazu holt sich 

der Adminstrator zunächst sein Credentials- 

Paket vom Frontend ab: 

usr/sbin/euca_conf ‐‐get‐credentials U 

admin.zip 

unzip admin.zip 

source eucarc 

Abbildung 9: Die Arbeit mit den Euca2ools ist nicht so eingängig 

wie die Benutzeroberflächen. 

Den ersten Befehl muss man als Benutzer root 

ausführen, der letzte Befehl setzt ein paar Umgebungsvariablen 

für die Euca2ools. Anschließend 

erzeugt man noch ein Schlüsselpaar, im 

Folgenden unter dem Namen »eucatest«. Der 

private Schlüssel landet dabei in der Datei »eucatest.private«: 

euca‐add‐keypair eucatest > eucatest.private 

chmod 0600 eucatest.private 

Jetzt kann man sich zunächst alle verfügbaren 

Betriebssystem-Images anzeigen lassen, die 

man in einer virtuellen Maschine starten kann: 

euca‐describe‐images 

Aus dem dann ausgespuckten Textgewirr muss 

man sich das entsprechende Image heraussuchen. 

Jedes Betriebssystem-Image besteht aus 

drei Dateien: dem Kernel, einer 

Ramdisk und dem eigentlichen 

Image. Letzteres erkennt man am 

Kürzel ».img« im Dateinamen. Um 

eine virtuelle Maschine zu starten, 

benötigt man das Image. Dessen 

Zeile findet man am schnellsten 

anhand der Beschreibung in der 

zweiten Zeile. Wichtig ist dabei 

die interne Identifikationsnummer, 

die hinter »IMAGE« steht. 

In Abbildung 9 heißt das Image 

mit dem kleinen CentOS-6-System 

»emi‐AF4736C9«. Diesen Namen 

behält man jetzt im Hinterkopf. 

Alle möglichen virtuellen Computermodelle 

spuckt der folgende 

Befehl aus: 

euca‐describe‐availability‐zones verbose 

In der zweite Spalte stehen die Namen der 

virtuellen Computermodelle, ihre Hardware- 

Konfiguration folgt auf der rechten Seite. So 

hat der Computer mit dem Namen »m1.small« 

nur eine CPU und 256 MByte Hauptspeicher. Interessant 

ist dabei auch die Spalte »free / max«: 

Die Zahl unter »free« verrät, wieviele virtuelle 

Maschinen man selbst von diesem Modell noch 

anwerfen könnte, während »max« die maximal 

mögliche Anzahl der Maschinen nennt. Sobald 

man sich für ein Modell entschieden hat, kann 

man die virtuelle Maschine starten: 

euca‐run‐instances ‐k eucatest emi‐AF4736C9U 

‐t m1.small 

Eucalyptus zeigt jetzt die gleiche Statuszeile, 

wie man sie auch in der User Console zu Gesicht 

bekommt. Wenn noch keine IP-Adressen angegeben 

sind, kann man nach ein paar Sekunden den 

Zustand wieder erneut abrufen: 

euca‐describe‐instances 

Die interne Identifikationsnummer neben »IN- 

STANCE« sollte man sich unbedingt notieren (sie 

beginnt mit einem »i‐«), um sie mit bestimmten 

Befehlen zu benutzen: 

euca‐terminate‐instances i‐45C44614 

Damit kann man eine laufende Instanz später 

wieder abschalten. 


Admin 


45


Eucalyptus 

raus wieder anzuhalten, hakt man ihr 

kleines Kästchen in der ersten Spalte ab 

und wählt dann unter »More actions« die 

gewünschte Aktion – wie etwa »Terminate« 

(Beenden). 

Ausblick 

Abbildung 10: Hier läuft eine virtuelle Maschine (Instanz). 

Vorgaben verbleiben. Weiter geht es mit 

»Next: Select Security«. 

Schlüsseltausch 

Um später die laufende virtuelle Maschine 

warten zu können, muss man sich bei ihr 

per SSH anmelden. Die Authentifizierung 

erfolgt dabei mithilfe eines Schlüsselpaars 

– wer schon einmal mit SSH gearbeitet 

hat, sollte das Prinzip kennen. Um das 

Schlüsselpaar zu generieren, klickt man 

auf den grünen Link »Create new key 

pair« und vergibt einen Namen, wie etwa 

»test«. »Create and Download« erzeugt 

das Schlüsselpaar und bietet den privaten 

Schlüssel umgehend zum Download an, 

im Beispiel in der Datei »test.pem«. Den 

öffentlichen Schlüssel behält Eucalyptus. 

In der Ausklappliste »Key name« stellt 

man anschließend den zuvor vergebenen 

Schlüsselnamen ein (im Beispiel »test«). 

Mitunter dauert es etwas, bis der passende 

Eintrag auftaucht. 

Per »Launch instance(s)« kann man jetzt 

endlich die virtuelle Maschine starten. 

Es dauert allerdings einen Moment, bis 

die virtuelle Maschine läuft und in der 

Liste auftaucht (Abbildung 10). Mit einem 

Klick auf den (grünen) kryptischen 

Namen in der Spalte »Instance« klappt 

ein Register mit unzähligen weiteren Informationen 

auf. In der Spalte »Public IP« 

steht die IP-Adresse, unter der man die 

virtuelle Maschine etwa per SSH erreicht. 

Die »Private IP« dient zur Kommunikation 

der virtuellen Maschinen untereinander. 

Sollten in der Liste noch die IP-Adressen 

»0.0.0.0« stehen, heißt es wieder etwas 

zu warten. Bevor man sich per SSH auf 

der virtuellen Maschine einloggen kann, 

muss man die Zugriffsrechte auf die Datei 

mit dem privaten Schlüssel einschränken, 

etwa mit: 

chmod 0600 test.pem 

Abbildung 11: Die Anmeldung auf der virtuellen Maschine war erfolgreich. 

Anschließend kann man sich mit folgendem 

SSH-Kommando auf der virtuellen 

Maschine einloggen: 

ssh ‐i test.pem ec2‐user@192.168.100.100 

Dabei steht »test.pem« für die Datei 

mit dem privaten Schlüssel und 

»192.168.100.100« für die »Public IP« der 

virtuellen Maschine (Abbildung 11). Der 

Benutzer »ec2‐user« ist im Mini-CentOS- 

System bereits angelegt, 

sonst sollte 

der Benutzername 

»root« zum Ziel 

führen. 

Um die virtuelle 

Maschine aus der 

Weboberfläche he- 

Das vorgegebene Benutzerkonto ist nur 

für die ersten Schritte gedacht. Um es zu 

löschen und anderen Benutzern mit eigenen 

Konten das Starten von virtuellen 

Maschinen zu gestatten, ruft man die Admin 

Console auf. Sie erreicht man unter 

der URL »https://Frontend‐Rechner:8448«. 

Auch hier muss man das Zertifikat als 

Ausnahme hinzufügen. Die Anmeldung 

erfolgt mit dem Account »eucalyptus«, 

dem User »admin« und dem Passwort 

»admin«. Es meldet sich jetzt ein Assistent, 

der die Eingabe einer E-Mail- 

Adresse und aus Sicherheitsgründen eine 

Änderung des Passworts verlangt. Anschließend 

kann man unter »Accounts« 

die Benutzerkonten verwalten. 

Die weitere Bedienung der beiden Weboberflächen 

erläutert das Eucalyptus User 

Console Guide. Wer eigene Betriebssystem-Images 

in die Cloud stellen möchte, 

greift hingegen zum extrem umfangreichen 

Administration Guide. In den Dokumenten 

erfährt man auch, wie man die 

virtuellen Maschinen in Security Groups 

einsperrt, die von Amazon bekannten 

Availability Groups bildet und die Cloud 

Speicherplatz bereitstellen lässt. (ofr) n 

Infos 

[1] Eucalyptus: [http:// www. eucalyptus. com] 

[2] Tim Schürmann, Virtuelle Maschine in 

einer virtuellen Maschine betreiben, 

LinuxCommunity, 30.07.2013: [http:// 

www. linux‐community. de/ Archiv/ 

Tipp‐der‐Woche/ Virtuelle‐Maschine‐in‐eine 

r‐virtuellen‐Maschine‐betreiben] 

[3] Download des FastStart-Images: [http:// 

www. eucalyptus. com/ eucalyptus‐cloud/ 

get‐started/ try/ faststart/ download] 

Der Autor 

Tim Schürmann ist selbstständiger Diplom- 

Informatiker und derzeit hauptsächlich als freier 

Autor unterwegs. Zu seinen Büchern gesellen 

sich zahlreiche Artikel, die in Zeitschriften 

und auf Internetseiten in mehreren Ländern 

veröffentlicht wurden. 


Know-how 


© Nuno Andre, 123RF 

Neues im kommenden PostgreSQL 9.3 

Datenbank-Tuning 

PostgreSQL in der Version 9.3 steht vor der Tür. Das kommende Release bringt einige Neuerungen hinsichtlich 

geschwindigkeit, Benutzbarkeit, aber auch SQL-Standardkonformität. Bernd Helmle 

Mit der Version 9.3 liefert die PostgreSQL- 

Community wieder etliche wichtige, neue 

Features in einer Hauptversion. Sie ist 

das Werk vieler Entwickler weltweit und 

durchlief einen strengen Review-Prozess 

(Commitfest), der die Qualität des Quelltextes 

sicherstellt. In der Regel finden 

sich bis zu 100 Patches in diesen Commitfests 

– wegen der Menge muss besonders 

vor dem Feature Freeze einer neuen 

Hauptversion die dafür veranschlagte 

Zeit regelmäßig verlängert werden. Die 

Liste an hinzugekommenen Funktionen 

ist entsprechend beeindruckend. Dieser 

Artikel stellt die Wichtigsten vor. 

Parallel Dump 

Ein lange von den Anwendern (aber auch 

von Entwicklern) gefordertes Feature ist 

die Möglichkeit, Dumps einer Datenbank 

mit mehreren Threads oder Prozessen 

gleichzeitig auszuführen. PostgreSQL 

verwendet eine Multiprozessarchitektur, 

das heißt, es benutzt keine Threads 

(auch nicht auf Plattformen wie Windows, 

die sie eigentlich favorisieren). Um 

mit »pg_dump« parallel mehrere Objekte 

zu sichern, muss das Programm deshalb 

mehrere Datenbankverbindungen öffnen. 

Da jedoch »pg_dump« die Konsistenz 

eines Dumps auch mit nebenläufigen 

Transaktionen garantiert, müssen diese 

zu »pg_dump« gehörenden Datenbankverbindungen 

nun synchronisiert werden. 

Aus diesem Grund gestaltete sich 

die Entwicklung dieses Features recht 

langwierig. 

Snapshot Cloning 

Die Infrastruktur, die hierfür implementiert 

wurde, nennt sich Snapshot Cloning. 

Dieses Verfahren gestattet es, mehrere 

Transaktionen derart untereinander zu 

synchronisieren, dass sie denselben Zustand 

sehen, obwohl es sich doch um 

separate Datenbankverbindungen handelt. 

Grundsätzlich muss zuerst eine 

Transaktion gestartet werden, die dann 

synchronisiert werden kann. Alle weiteren 

Transaktionen importieren dann den 

dabei erzeugten Snapshot. Dies synchronisiert 

dann die jeweilige Transaktion mit 

ihrer „Elterntransaktion“, beide haben 

dann dieselbe Sicht auf den Zustand der 

Datenbank. 

Abbildung 1 verdeutlicht den Ablauf. Zunächst 

wird eine Transaktion gestartet. 

Diese muss den Isolationsgrad »REPEA- 

TABLE READ« oder »SERIALIZABLE« 

haben. »READ COMMITTED« ist nicht 

möglich, da sich innerhalb dieses Isolationsgrades 

der Snapshot nach jedem 

Kommando ändert und nicht dauerhaft 

für die Transaktion ist. 

Mit der Funktion »pg_export_snapshot()« 

kann in jeder beliebigen Transaktion ein 

Snapshot exportiert werden. Die Rückgabe 

ist ein Datum vom Typ TEXT mit 

dem Bezeichner des Snapshots. Dieser 

Bezeichner kann in einer anderen 

Transaktion mit dem Kommnado »SET 

TRANSACTION SNAPSHOT« importiert 

werden. 

Zu beachten ist, dass dies das erste Kommando 

innerhalb der Transaktion oder 

vor jedem anderen »SELECT«, »INSERT«, 

»UPDATE« oder »DELETE« sein muss. Ferner 

kann eine importierende Transaktion 

mit »SERIALIZABLE«-Isolationsgrad kei- 



Know-how 

nen Snapshot einer Transaktion importieren, 

deren Isolationsgrad kleiner ist. 

Neue Formate und 

Parameter 

»pg_dump« implementiert exakt diese Infrastruktur, 

um mehrere Dump-Prozesse 

zu synchronisieren. Parallel Dump funktioniert 

nur für das neue Ausgabeformat 

»directory«. Der Aufruf von »pg_dump« 

und mehreren synchronisierten Dump- 

Prozessen geschieht mit dem neuen Kommandozeilenparameter 

»‐j«: 

pg_dump ‐j4 ‐Fd ‐f /srv/backups/db/ 

Wichtig ist das Ausgabeformat »directory« 

mit dem Kommandozeilenparameter 

»‐Fd«; »‐f« gibt das Ausgabeverzeichnis 

an, das nicht existieren darf. 

Das Kommando »pg_dump« einer neueren 

Hauptversion ließ sich schon immer 

auch in einer älteren Version verwenden, 

um Migrationen zu ermöglichen. Auch 

Parallel Dump ist abwärtskompatibel 

und lässt sich beispielsweise auch mit 

einer PostgreSQL-Instanz in der Version 

9.2 verwenden. Dann kann »pg_dump« 

aber keine synchronisierten Snapshots 

verwenden, weshalb für die Dauer des 

Dumps keinerlei Änderungen an den 

Datenbanken zugelassen werden sollten, 

um Inkonsistenzen zu vermeiden. 

Alternativ lassen sich synchronisierte 

Snapshots auch explizit mit einem Kommandozeilenparameter 

(»‐‐no‐synchronized‐snapshots«) 

abschalten, sodass 

sich Dumps mit mehreren »pg_dump«- 

Prozessen auch in älteren Versionen anfertigen 

lassen. 

Schreibbare Foreign Data 

Wrapper 

Data Wrapper (FDW) zur Laufzeit konvertiert 

und als Datenbankzeile in der 

Ergebnismenge gemäß der Tabellendefinition 

angezeigt. Zum jetzigen Zeitpunkt 

existieren bereits eine größere Anzahl 

von FDWs für den Zugriff auf andere 

Datenbanksysteme unter PostgreSQL, 

darunter 

n Oracle 

n MySQL 

n Informix 

n ODBC 

n JDBC 

sowie auch solche für die NoSQL-Datenbankquellen 

CouchDB, Redis und MongoDB. 

Der FDW für PostgreSQL selbst hat nun 

mit der Version 9.3 in den Contrib-Zweig 

des Datenbankservers Einzug gehalten. 

Damit lassen sich die Tabellen externer 

PostgreSQL-Datenbanken einbinden. 

Ferner unterstützt der PostgreSQL-FDW 

bereits schreibende DML-Abfragen mit 

»INSERT«, »DELETE« und »UPDATE«. 

Für die jeweiligen Distributionen werden 

diese zusätzlichen Module in der 

Regel in einem PostgreSQL-Contrib-Paket 

bereitgehalten. Ist alles ordnungsgemäß 

installiert, lässt sich der PostgreSQL-FDW 

einfach als Extension aktivieren. Abbildung 

2 zeigt beispielhaft diesen Vorgang. 

Das »\dx«-Kommando gibt in »psql« alle 

derzeit installierten Extensions einer Datenbank 

aus. 

Zugriff auf externe Server 

Um mittels des PostgreSQL-FDW auf 

einen entfernten Datenbankserver zuzugreifen, 

muss zunächst eine entsprechende 

Datenquelle konfiguriert sein. 

Das geschieht mit Hilfe des »CREATE 

SERVER«-Kommandos. Im folgenden 

Beispiel wird auf einen entfernten PostgreSQL-Server 

»archives.mynet.internal« 

zugegriffen. Zunächst muss der FDW jedoch 

per »CREATE EXTENSION« in die 

lokale Datenbank geladen werden. 

Es ist nicht notwendig, einen FDW auch 

auf dem entfernten Datenbankserver 

zu installieren, jedoch muss die lokale 

Datenbank per »pg_hba.conf« eine Zugriffsberechtigung 

auf die gewünschte 

Datenbank erhalten. Es können auch 

alle gängigen PostgreSQL-Schlüsselworte 

für die Datenbankverbindung angegeben 

werden (»host«, »dbname«, »port« und 

so weiter), verboten sind jedoch »user«, 

»password«, »failback_application_name« 

und »client_encoding«. Die beiden letzten 

werden automatisch vom FDW gesetzt: 

CREATE EXTENSION postgres_fdw; 

Anschließend kann die Datenquelle für 

den entfernten Datenbankserver definiert 

werden, wie das folgende Listing zeigt: 

CREATE SERVER pg_archive_server 

FOREIGN DATA WRAPPER postgres_fdw 

OPTIONS(dbname 'archive', host U 

'archives.mynet.internal', port '5432'); 

Um eine Foreign Table erzeugen zu können, 

muss der Datenquelle noch mitgeteilt 

werden, welcher Benutzer sich mit welcher 

Kombination aus Rollennamen und 

Passwort an der entfernten PostgreSQL- 

Instanz anmelden kann. Dafür wird ein 

Mapping für den Benutzer benötigt. Das 

erledigt das Kommandos »CREATE USER 

MAPPING«. Die verwendeten Zugangsinformationen 

unterscheiden sich zwischen 

den einzelnen FDW, für PostgreSQL sind 

Bereits PostgreSQL 9.1 hatte eine Teilimplementierung 

des SQL/MED-Standards 

an Bord, der das Einbinden externer Datenquellen 

in Form einer Foreign Table 

ermöglichte. Dies war jedoch bisher 

nur lesend möglich. Mit PostgreSQL 9.3 

wurde die API auch für Schreiboperationen 

auf Foreign Tables erweitert. 

Externe Datenquellen werden dabei derart 

definiert, dass sie dem PostgreSQL- 

Anwender wie lokale Tabellen erscheinen. 

Die Datensätze werden bei einer 

Abfrage über einen sogenannten Foreign 

Abbildung 1: Die zweite Transaktion rechts bezieht sich auf einen zuvor angelegten Snapshot: So sieht sie 

dieselben Daten. 


Admin 


49

Know-how 


auf jeden Fall Benutzername und gegebenenfalls 

Passwort erforderlich. Letzteres 

ist bei einem User Mapping für Benutzer 

ohne Superuserberechtigung zwingend 

notwendig. Das Schlüsselwort »CUR- 

RENT_USER« wird durch die aktuell in 

der lokalen Datenbanksitzung verwendete 

Rolle automatisch ersetzt: 

CREATE USER MAPPING FOR CURRENT_USER 

SERVER pg_archive_server 

OPTIONS(user 'bernd', password 'bernd'); 

Mit dem Anlegen einer Datenquelle und 

einem Mapping für die Zugangsberechtigungen 

zur jeweiligen Datenquelle kann 

anschließend eine sogenannte Foreign 

Table angelegt werden. Die lokale Definition 

sollte dabei möglichst dem Schema 

der entfernten Datenquelle entsprechen. 

Die lokale Datenbank erhält in Listing 1 

eine Foreign Table, die E-Mails in einem 

Archiv speichert: 

Beispiel: E-Mail-Archiv 

Dies entspricht exakt der Definition auf 

dem Archivserver – dort natürlich ohne 

die Schlüsselwörter »SERVER« und »OP- 

TIONS«, die dort nicht nötigt sind. 

Nun kann die lokale Datenbank die Archivtabelle 

in lokalen Abfragen ohne 

Weiteres verwenden: 

SELECT COUNT(*) FROM mails WHEREU 

mail_from LIKE 'Tom Lane%'; 

count 

‐‐‐‐‐‐‐ 

6238 

(1 row) 

Der FDW ist dafür zuständig, beim erstmaligem 

Ausführen eine für das User 

Mapping und Zielserver entsprechende 

Datenbankverbindung aufzubauen. 

Diese Datenbankverbindung wird pro 

verwendetes User Mapping innerhalb 

der lokalen Datenbanksitzung zur Wiederverwendung 

gecached. 

Listing 1: Foreign Table 

01 CREATE FOREIGN TABLE mails( 

02 id bigint not null, 

03 label_id bigint, 

04 mail_from text not null, 

05 mail_to text not null, 

06 msg text not null, 

07 subject text not null, 

08 msg_id text not null, 

09 date timestamp) 

10 SERVER pg_archive_server 

Der PostgreSQL-FDW unterstützt nicht 

nur lesende, sondern auch schreibende 

Operationen (Data Modyfing Language, 

DML). Werden Transaktionen oder Sicherungspunkte 

(SAVEPOINT) auf der lokalen 

Datenbank verwendet, so koppelt 

der PostgreSQL-FDW diese ebenfalls an 

Transaktionen beziehungsweise Sicherungspunkte 

auf der entfernten Datenbank. 

Dies bedeutet, dass ein ROLLBACK 

von lokalen Datenbanken auch jede Änderung 

einer entfernten PostgreSQL-Datenquelle 

zurückrollt. 

Neue Features mit 

Streaming Replication 

Das mit Version 9.0 eingeführte, eingebaute 

Replikationsverfahren über Streaming 

Replication erfährt von Hauptversion 

zu Hauptversion stetige Verbesserungen. 

Auch PostgreSQL 9.3 bleibt 

dieser Tradition treu und verbessert die 

Handhabung von Streaming Replication 

im Falle eines Failovers oder Recovery des 

primären Servers. 

Wird der primäre Server durch eine Online-Sicherung 

wiederhergestellt, oder 

wird ein Failover auf einen anderen Streaming 

Replication Standby durchgeführt, 

so ändert die betroffene PostgreSQL-Instanz 

die sogenannte Timeline, eine Art 

Zeitschiene, auf die das Transaktionslog 

des Datenbankservers einschwenkt. 

Dies ermöglicht auch das mehrfache Recovern 

einer Online-Sicherung, falls man 

beispielsweise den falschen Zeitpunkt 

für das Ende der Rücksicherung (Point 

In Time Recovery, PITR) gewählt hat. 

Alle anderen Streaming Standby müssen 

dieser Timeline folgen. Bis PostgreSQL 

9.2 ist dies nur mit Hilfe des »restore_ 

command«-Kommandos in der »recovery. 

conf« möglich, da ein Zugriff über ein 

Archiv mit allen archivierten Transaktionslogs 

notwendig ist. Dies enthält die 

sogenannten History-Dateien für den 

Wechsel der Timeline (alle Dateien enden 

mit ».history«), die der Streaming 

Replication Standby benötigt, um diesen 

Wechsel nachzuvollziehen. Mit Version 

9.3 fällt diese Notwendigkeit eines Archivzugriffes 

weg, Streaming Replication 

kann nun direkt einen Wechsel der Timeline 

nachvollziehen. Erforderlich ist nach 

wie vor das Setzen des Parameters »recovery_target_timeline='latest'« 

in der 

Konfigurationsdatei »recovery.conf«. 

Neben der Möglichkeit, einen Hot- 

Standby-PostgreSQL-Server mithilfe des 

Parameters »trigger_file« zu einer vollwertigen 

PostgreSQL-Instanz zu delegieren, 

bietet PostgreSQL zusätzlich noch 

die Möglichkeit, dies über den Befehl 

»pg_ctl promote« zu implementieren. Mit 

der Version 9.3 gibt es hier zusätzlich die 

Möglichkeit, den Standby ohne Warten 

auf einen Checkpoint zur vollwertigen, 

schreibbaren Instanz zu machen. Hierzu 

muss die Kommandozeilenoption »‐m 

fast« verwendet werden. Dies erspart unter 

Umständen eine längere Wartezeit, 

bevor die Instanz zum Schreiben zur Verfügung 

steht. 

Mehr Speicher 

Abbildung 2: PostgreSQL-FDW wird als Extension der Datenbank hinzugefügt. 

Bis einschließlich PostgreSQL 9.2 war 

es für Einstellungen von »maintenance_ 

work_mem« beziehungswiese »work_ 

mem« nicht möglich, effektiv mehr als 2 

GByte für Sortierungen im RAM zu nutzen. 

Dies lag an einer hartcodierten Beschränkung 

innerhalb der Datenbank. Besonders 

für DDL-Kommandos, die diesen 

Konfigurationsparameter nutzen, kommt 

dieser Beschränkung eine wichtige Bedeutung 

zu. So profitiert zum Beispiel 

nun das »CREATE INDEX«-Kommando 

effektiv von einer hohen Einstellung in 

»maintenance_work_mem«, wenn sehr 

große Indexe erzeugt werden müssen. 

Das Sortieren für den Aufbau des Index 

kann dann im Idealfall komplett per 


Know-how 


Quicksort im Speicher des Datenbankservers 

erfolgen, ohne auf das Storage- 

System ausweichen zu müssen. 

Für Altsysteme, die diese Einstellung 

schon immer auf hohe Werte gesetzt hatten 

(auch wenn diese effektiv nie genutzt 

wurden), sollte der Wert jetzt jedoch geprüft 

werden. Ansonsten droht Gefahr, 

wenn die Einstellung plötzlich wirklich 

entsprechend hohe Speicherallozierungen 

auf dem System vornimmt. 

Bereits in älteren PostgreSQL-Versionen 

konnte man mittels sogenannter Expression 

Indexes reguläre Ausdrücke indizieren. 

Allerdings funktionierte das nur für 

statische reguläre Ausdrücke und falls 

mehrere Suchbegriffe indiziert werden 

mussten, wurde es aufgrund der Vielzahl 

der benötigten Indexe schnell ineffektiv. 

Indizierbare reguläre 

Ausdrücke 

Mit Version 9.3 verfügt PostgreSQL nun 

über die Möglichkeit, direkt dynamische 

reguläre Ausdrücke mit Hilfe eines speziellen 

Indexes zu beschleunigen. 

Das Contrib-Modul »pg_trgm« wurde in 

PostgreSQL 9.3 derart erweitert, dass es 

beliebige reguläre Ausdrücke über ei- 

nen Index beantworten kann. Da es sich 

ebenfalls im Contrib-Zweig der Datenbank 

befindet, muss es über »CREATE 

EXTENSION« nachinstalliert werden. Das 

Listing 2 zeigt am Beispiel der Tabelle 

»mails«, wie ein derartiger Index angelegt 

wird und einen Vergleich der Ausführungspläne 

mit und ohne Index. 

Die Unterschiede in den Kosten und 

Ausführungszeiten mit und ohne Index 

zeigen die deutlichen Vorteile in der Abfragegeschwindigkeit. 

Mit der Version 9.3 unterstützt PostgreSQL 

nun auch das im SQL-Standard 

definierte LATERAL-Schlüsselwort. Das 

Listing 2: Indizierte Regex 

01 CREATE EXTENSION pg_trgm; 

02 CREATE INDEX ON mails USING gin(msg gin_trgm_ops); 

03 

04 EXPLAIN ANALYZE SELECT * FROM mails WHERE msg ~ '(updatable|views)'; 

05 QUERY PLAN 

06 ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 

07 Bitmap Heap Scan on mails (cost=128.03..143.74 rows=4 width=961) 

(actual 

08 time=35.454..175.184 rows=672 loops=1) 

09 Recheck Cond: (msg ~ '(updatable|views)'::text) 

10 Rows Removed by Index Recheck: 978 

11 ‐> Bitmap Index Scan on mails_msg_idx (cost=0.00..128.03 rows=4 

width=0) 

12 (actual time=34.925..34.925 rows=1650 loops=1) 

13 Index Cond: (msg ~ '(updatable|views)'::text) 

14 Total runtime: 175.403 ms 

15 (6 rows) 

16 

17 EXPLAIN ANALYZE SELECT * FROM mails WHERE msg ~ '(updatable|views)'; 

18 QUERY PLAN 

19 ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 

20 Seq Scan on mails (cost=0.00..5628.25 rows=4 width=961) (actual 

21 time=2.401..1519.809 rows=672 loops=1) 

22 Filter: (msg ~ '(updatable|views)'::text) 

23 Rows Removed by Filter: 40148 

24 Total runtime: 1519.991 ms 

25 (4 rows) 

Listing 3: Set Returning Function 

01 CREATE OR REPLACE FUNCTION get_buch_by_autorid(IN integer) 

02 RETURNS SETOF text 

03 STRICT 

04 LANGUAGE SQL 

05 AS 

06 $$ 

07 SELECT b.titel FROM buch b WHERE autor_id = $1; 

08 $$; 

09 

10 buch =# SELECT * FROM autor a, get_buch_by_autorid(a.id); 

11 ERROR: function expression in FROM cannot refer to other relations of 

same 

12 query level 

13 LINE 1: SELECT * FROM autor a, get_buch_by_autorid(a.id); 

14 

15 SELECT * FROM autor a, LATERAL get_buch_by_autorid(a.id); 

16 

17 id | name | get_buch_by_autorid 

18 ‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 

19 1 | Bernd Helmle | PostgreSQL Administration 

20 2 | Andreas Eschbach | One Trillion Dollar 

21 3 | Mario Puzo | Der Pate 

22 4 | Peter Eisentraut | PostgreSQL Administration 

23 4 | Peter Eisentraut | PostgreSQL ‐ Das offizielle Handbuch 

24 (5 rows) 

Listing 4: »LATERAL« 

01 SELECT 

02 a.id, a.name, t.titel 

03 FROM autor a, 

04 (SELECT autor_id, titel FROM buch b WHERE b.autor_id = a.id AND 

b.titel LIKE '%PostgreSQL%') AS t; 

05 ERROR: invalid reference to FROM‐clause entry for table "a" 

06 LINE 1: ...CT autor_id, titel FROM buch b WHERE b.autor_id = a.id) AS 

t... 

07 ^ 

08 HINT: There is an entry for table "a", but it cannot be referenced from 

this part of the query. 

09 

10 

11 # Mit LATERAL wird aus dieser Verknüpfung jedoch eine korrekte 

Verknüpfung: 

12 

13 

14 SELECT 

15 a.id, a.name, t.titel 

16 FROM autor a, 

17 LATERAL (SELECT autor_id, titel FROM buch b WHERE b.autor_id = a.id 

AND b.titel LIKE '%PostgreSQL%') AS t; 

18 id | name | titel 

19 ‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 

20 1 | Bernd Helmle | PostgreSQL Administration 

21 4 | Peter Eisentraut | PostgreSQL Administration 

22 4 | Peter Eisentraut | PostgreSQL ‐ Das offizielle Handbuch 

23 (3 rows) 



Know-how 

erlaubt es dem Entwickler, innerhalb von 

Verknüpfungen (Joins) mit Subselects aus 

diesen heraus andere Spalten oder Werte 

der Join-Operation zu referenzieren. 

LATERAL-Statement 

Ein einfaches Beispiel soll dies verdeutlichen: 

In der Regel ist es bisher in 

PostgreSQL nicht möglich, das Ergebnis 

eines Join-Partners als Funktionsargument 

einer Funktion zu verwenden. Bis 

PostgreSQL 9.2 liefert Listing 3 ein stark 

vereinfachtes Beispiel einer sogenannten 

Set Returning Function (SRF). 

Interessant wird LATERAL insbesondere 

bei Verknüpfungspartnern wie Subselects. 

Für diese gilt diesselbe Regelung: 

Vorhergehende Verknüpfungspartner 

können mit LATERAL direkt in der Definition 

des Subselects referenziert werden. 

Hierbei ist das LATERAL-Schlüsselwort 

Pflicht, wie Listing 4 verdeutlicht. 

Für komplexe Subqueries innerhalb von 

Verknüpfungen ist dies eine deutliche Erleichterung, 

allerdings sollte dies nicht 

dazu verleiten, Verknüpfungen als solche 

immer als Subqueries zu formulieren. 

Das vorhergehende Beispiel lässt sich 

beispielsweise recht einfach in einen herkömmlichen 

JOIN umschreiben. 

COPY FREEZE 

Wenn große Datenmengen beispielsweise 

in eine Archivtabelle zu laden waren, so 

bot es sich vor PostgreSQL Version 9.3 

an, nachträglich ein VACUUM FREEZE 

auf die Relation auszuführen, wenn sich 

die Datensätze im Anschluss garantiert 

nicht mehr änderten. Dies hatte den Vorteil, 

dass man sich einen späteren VA- 

CUUM FREEZE sparen konnte. Auf jeden 

Fall entfällt außerdem ein teurer zusätzlicher 

Scan der kompletten Tabelle im 

Anschluss, was gerade bei sehr großen 

Datenbeständen eine beachtliche Zeitersparnis 

ist. 

In PostgreSQL 9.3 gibt es nun die Möglichkeit, 

das sofort beim Ladens der Daten 

erledigen. Das Kommando »COPY« 

wurde um den Parameter »FREEZE« erweitert. 

»COPY« mit »FREEZE« erfordert einige 

Rahmenbedingungen. So muss die Zieltabelle 

in derselben Transaktion erzeugt 

worden sein, die auch den COPY-Befehl 

absetzt. Auch dürfen keine »CURSOR« 

auf diese Tabelle geöffnet sein. Das folgende 

Beispiel zeigt die Verwendung von 

»COPY FREEZE« mit einer CSV-Datei: 

BEGIN; 

CREATE TABLE t3(LIKE t2); 

COPY archive_tbl FROM '/Users/berndU 

/tmp/archive.dat' FREEZE CSV; 

COMMIT; 

Häufiger regten Anwendern die Verfügbarkeit 

von Triggern beim Ausführen bestimmter 

DDL-Kommandos an. Solche 

Trigger können beispielsweise Änderungen 

an der Datenbank selbst verfolgen. 

Anzeige 


Admin 


53

Know-how 


Ein Anwendungsbeispiel sind etwa Replikationssysteme 

wie Slony-I, die auf eine 

entsprechende Benachrichtigung über 

veränderte Objekte angewiesen sind. 

Event Trigger 

Einen Event Trigger erzeugt man über das 

Kommando »CREATE EVENT TRIGGER«. 

Die Syntax folgt der normalen »CREATE 

TRIGGER«-Syntax, das heißt, die Trigger- 

Funktion ist im Vorfeld zu definieren. 

Listing 5 zeigt ein Beispiel, das pauschal 

alle »ALTER TABLE«-Kommandos in einer 

Datenbank mit einem Fehler verhindert: 

Neben dem Event-Trigger-Ereignis 

»ddl_command_start« stehen noch die 

Ereignisse »ddl_command_end« und 

»sql_drop« zur Verfügung. »ddl_command_start« 

wird vor dem Ausführen des 

jeweiligen DDL-Kommandos ausgeführt, 

»ddl_command_end« entsprechend bevor 

das DDL-Kommando beendet wird. Event 

Trigger mit dem »sql_drop«-Ereignis 

werden noch vor »ddl_command_end«- 

Event-Triggern ausgeführt: Für alle Objekte, 

die innerhalb dieses Ereignisses 

entfernt werden. 

Event Trigger lassen sich im Moment in 

PL/pgSQL oder C implementieren. Ein 

CREATE-EVENT-TRIGGER-Kommando 

selbst kann nicht Auslöser eines Event 

Triggers sein. 

Prüfsummen 

Mit PostgreSQL 9.3 lassen sich Datenbankblöcke, 

die auf Festplatte geschrieben 

werden, mit Prüfsummen versehen. 

Listing 5: Event Trigger 

01 CREATE OR REPLACE FUNCTION public.deny_alter_table() 

02 RETURNS event_trigger 

03 LANGUAGE plpgsql 

04 AS $function$ 

05 BEGIN 

06 

07 RAISE EXCEPTION '% is disabled', TG_TAG; 

08 

09 END; 

10 $function$ 

11 

12 CREATE EVENT TRIGGER etg_deny_alter_table 

13 ON ddl_command_start 

14 WHEN tag IN ('ALTER TABLE') 

15 EXECUTE PROCEDURE deny_alter_table(); 

16 

17 ALTER TABLE test ADD COLUMN another_col integer; 

18 FEHLER: ALTER TABLE is disabled 

Das kann die Diagnose von Festplattenproblemen 

erleichtern, indem etwaige 

Datenkorruption erkannt wird. Interessant 

ist das insbesondere für Systeme, die 

auf unsicherer Hardware laufen. 

Ob Prüfsummen verwendet werden sollen, 

muss der Administrator beim Initialisieren 

der PostgreSQL-Instanz mittels 

des Kommandos »initdb« und dessen 

neuen Kommandozeilenparameters 

»‐‐data‐checksums« festlegen. Nachträglich 

kann dieses Feature weder aktiviert 

noch deaktiviert werden. Ferner gilt es 

immer gleich für sämtliche Datenbanken 

und ‐objekte. 

Das Schreiben oder Checken der Prüfsummen 

findet auf Blockebene für alle 

Datenbankobjekte wie Tabellen oder Indexe 

statt. Für einzelne Objekte ist der 

Check der Prüfsummen nicht deaktivierbar. 

Auch muss beachtet werden, dass 

die Aktivierung der Prüfsummen Auswirkungen 

auf die Geschwindigkeit der 

Datenbank hat. 

Verbesserte Concurrency 

für Fremdschlüssel 

Bisher wurde insbesondere bei Änderungen 

an Daten, die mit Fremdschlüssel 

entsprechende Tabellen referenzieren, 

ein sogenannter »FOR SHARE«- beziehungsweise 

»FOR UPDATE«-Lock-Typ 

verwendet. Das Problem mit diesen Typen 

war, dass sie bei einer Vielzahl an 

nebenläufigen Änderungen zu massiven 

Sperrungen führten, was die Geschwindigkeit 

solcher Anwendungen erheblich 

sinken lassen konnte. 

Mit der Version PostgreSQL 9.3 werden 

zwei neue Lock-Typen eingeführt: »FOR 

KEY SHARE« und »FOR NO KEY UP- 

DATE«. Diese beiden Lock-Typen blockieren 

sich nicht mehr gegenseitig. Wird 

nun ein Tupel, das über einen Fremdschlüssel 

verfügt, aktualisiert, so wird 

für den Fall, dass der Schlüssel nicht 

Bestandteil der Aktualisierung ist, nun 

ein neuer »FOR NO KEY UPDATE«-Lock 

angefordert. 

Prüfungen der Fremdschlüsselintegrität 

selbst werden in PostgreSQL seit jeher 

über implizite Trigger realisiert. Diese 

verwenden anstelle von »FOR SHARE« 

nun »FOR KEY SHARE«. Das beschleunigt 

den Großteil der Anwendungen mit 

einem derartigen Anforderungsprofil. In 

der Regel werden sowieso Fremdschlüsselwerte 

als solche nur recht selten aktualisiert. 

Schon seit geraumer Zeit wurde in der 

PostgreSQL-Community über sogenannte 

Background-Prozesse nachgedacht. 

Background Worker API 

Das sind Prozesse, die neben den normalen 

Datenbankverbindungen – die 

ebenfalls separate Prozesse sind – gestartet 

werden und dedizierte Aufgaben 

erledigen können, wie beispielsweise das 

periodische Ausführen spezifischer Aufgaben 

oder Kommandos. PostgreSQL 9.3 

enthält die notwendige Infrastruktur und 

API, um solche Hintergrundprozesse implementieren 

zu können. Eine Referenzimplementierung 

findet sich im Contrib- 

Modul »worker_spi«. Interessierte Entwickler 

können hier die notwendigen 

Schritte studieren. 

Hintergrundprozesse starten bei Start der 

Datenbankinstanz und sind während der 

gesamten Laufzeit der Instanz aktiv. Beendet 

sich ein Hintergrundprozess, so 

wird er sofort vom PostgreSQL-Datenbankserver 

neu gestartet. 

Fazit 

Die beschriebenen neuen Funktionen 

und Ergänzungen stellen die wichtigsten 

und gravierendsten Neuerungen in 

PostgreSQL 9.3 dar. Darüber hinaus gibt 

es eine noch viel größere Anzahl kleinerer, 

aber teilweise dennoch bedeutender 

Änderungen. Das betrifft Geschwindigkeitsverbesserungen 

im Datenbankserver 

selbst oder in Verbindung mit Streaming 

Replication, die alleine schon einen Blick 

auf die neue Version rechtfertigen. 

Zusätzlich hat der JSON-Datentyp, eingeführt 

in PostgreSQL 9.2, nun eine umfangreiche 

Liste an Zusatzfunktionen für 

Zugriff und Datenmanipulation bekommen. 

Dies vereinfacht insbesondere die 

Interaktion interaktiver Webanwendungen 

mit der Datenbank, beispielweise 

über Skriptsprachen, die selbst über weitgehende 

JSON-Funktionalität verfügen. 

Jedoch insbesondere mit dem Einzug 

von DML-fähigen Foreign Data Wrapper 

wird PostgreSQL 9.3 zum Multifunktionswerkzeug 

in heterogenen, verteilten 

Datenbankumgebungen. (jcb) n 


Know-how 

Bareos 

© Maxim Kazmin, 123RF 

Neue Features im Bacula-Fork Bareos 

Besser sichern 

Die auf fast allen Plattformen verfügbare Open-Source-Backup-Software 

Bacula ist bei vielen Administratoren beliebt – nun schickt sich der Fork 

Bareos an, die Vorreiterrolle noch auszubauen. Jörg Steffens, Philipp Storz 

Bevor man sich mit Bacula oder Bareos 

näher befasst oder eine Testinstallation 

ins Auge fasst, ist ein Blick auf die Struktur 

der Anwendung nützlich (Abbildung 

1): Der grundsätzliche Aufbau besteht 

immer aus einer Steuerzentrale, dem 

Backup Director, ein oder mehreren Storage 

Daemons und den File Daemons auf 

den zu sichernden Clients. 

Die File Daemons sind der Teil der Software, 

der auf möglichst vielen Plattformen 

laufen muss. Er ist dafür zuständig, 

die Daten vom Client zu sichern beziehungsweise 

sie bei einer Rücksicherung 

auch wieder dorthin zu bringen. Dieser 

Daemon läuft auf den Clients permanent 

und führt die Anweisungen des Directors 

aus. 

Der Director ist die Steuereinheit: Er enthält 

die gesamte Logik und zu ihm gehören 

die meisten Einstellungen. Seine 

Konfigurationsdatei beschreibt 

n die Datenbank-Konfiguration, 

n alle Client-Systeme und wie diese anzusprechen 

sind, 

n welche Dateien gesichert werden sollen 

(File Sets), 

n die Plugin-Konfigurationen, 

n die Before- und After-Jobs: Programme, 

die vor oder nach einem 

Backup-Job gestartet werden sollen, 

um etwa Dienste zu stoppen und zu 

starten, 

n den Storage- und den Medien-Pool mit 

dessen Eigenschaften und Vorhaltezeiten, 

n die Zeitpläne für die Backups, 

n die Adressen für Meldungen, 

n Jobs und JobDefs. 

Selbst wenn bereits ein Storage, ein File 

Set und ein Client definiert sind, passiert 

erst einmal gar nichts. Zusammengeführt 

werden diese Komponenten erst 

über Jobs. Sie definieren, was wann und 

wohin zu sichern ist. 

Wichtig ist auch, wie lange gesicherte 

Daten aufzuheben sind. Das steuern File 

Retention, Job Retension und Volume Retention. 

Es ist sinnvoll, sich nur auf die 

Volume Retention zur Steuerung der Vorhaltezeiten 

zu beschränken, denn wenn 

sich mehrere Retention-Optionen überschneiden, 

kann es zu überraschenden 

Effekten kommen. 

Die Volume Retention wird pro Pool definiert. 

Durch die Definition mehrerer 

Pools kann man auch mit unterschiedlichen 

Vorhaltezeiten arbeiten, zum Beispiel 

für verschiedene Systeme oder für 

unterschiedliche Sicherungsarten wie 

Voll-, differenzielle oder inkrementelle 

Sicherung. Die angegebenen Zeiten sind 

Mindestaufbewahrungsfristen. 

Bessere Bedienbarkeit 

Ein Schwerpunkt der Bareos-Entwicklung 

ist es, die Hürden für Anfänger möglichst 


Bareos 

Know-how 

Abbildung 1: Struktur einer einfachen Bacula-/Bareos-Installation. 

niedrig zu halten. Weil Neulinge von den 

gebotenen Konfigurationsmöglichkeiten 

meist erschlagen werden, bietet das Bareos-Projekt 

unter [1] Paket-Repositories 

für die gängigen Linux-Distributionen 

und Windows an. Für Windows werden 

sogar zusätzliche Pakete für die Software- 

Management-Lösung OPSI [2] offeriert. 

Alle Versionen werden automatisiert 

durch eine projekteigene Instanz des 

Open Build Service gebaut. Im Vergleich 

dazu bietet Bacula.org nur den Quellcode 

an. Aktuelle Windows-Binaries 

stehen dort nur gegen Bezahlung zur 

Verfügung. 

Unter Linux reicht es zur Installation eines 

Bareos-Servers aus, das entsprechende 

Repository einzubinden und das Paket 

»bareos« zu installieren. Bareos unterstützt 

drei Datenbank-Backends: MySQL, 

PostgreSQL und SQLite. SQLite sollte 

aber nur für Testinstallationen verwendet 

Von Bacula zu Bareos 

Die Open-Source-Variante von Bacula wurde 

erstmals 2002 veröffentlicht und fand rasch Anklang 

in der Community. In den letzten Jahren 

hat sich beim freien Bacula aber immer weniger 

getan. Derzeit gibt es nur alle paar Monate 

neue Commits in das öffentliche Git-Projekt. Es 

scheint, als würden sich die Entwickler auf die 

kommerzielle Bacula Enterprise Edition konzentrieren, 

die nicht öffentlich entwickelt wird. 

Der langjährige Bacula-Entwickler Marco van 

Wieringen hatte deshalb schon 2010 begonnen, 

Erweiterungen und Code-Aufräumarbeiten, 

die entweder gar nicht angenommen wurden 

werden. Der meiste Optimierungsaufwand 

soll zukünftig 

in die PostgreSQL-Anbindung 

fließen. Um sicherzustellen, 

dass wirklich das gewünschte 

Backend installiert wird, sollte 

man die Pakete »bareos« und 

»bareos‐database‐postgresql« 

(oder eben »bareos‐database‐mysql«) 

auswählen. Die 

Datenbank selbst muss separat 

installiert werden, da Bareos 

nur Abhängigkeiten zu den 

Datenbank-Clients beinhaltet. 

Dies ist sinnvoll, weil die Datenbank 

nicht unbedingt auf 

dem Bareos-Director-Rechner 

selbst laufen muss. 

Im Gegensatz zu Bacula wird 

bei Bareos die zu verwendende 

Datenbank in der Konfigurationsdatei 

definiert. Bei Bacula war 

es noch notwendig, eine speziell gegen 

die jeweilige Datenbank kompilierte Version 

einzusetzen. 

Bei der Erstinstallation wird Bareos die 

Konfigurationsdateien im Verzeichnis 

»/etc/bareos« mit sinnvollen Werten belegen. 

Nach der Installation muss der 

Admin die Datenbank initialisieren und 

die Dienste starten (Listing 1). 

Bei der automatischen Konfiguration ist 

die Sicherung auf Festplatte (nach »/var/ 

lib/bareos/storage«) voreingestellt. Bei 

der Sicherung auf Festplatte verhält sich 

Bareos genau so wie bei einer Sicherung 

auf eine Tape Library. Das bedeutet, dass 

unterhalb von »/var/lib/bareos/storage« 

Dateien angelegt werden, die jeweils einem 

Band entsprechen. Das hat den Vorteil, 

dass einheitliche Regeln gelten und 

zum Beispiel Vorhaltezeiten auf Bändern 

und auf Festplatten gleich gehandhabt 

oder für die es nur das Angebot gab, sie in 

die kommerzielle Version einfließen zu lassen, 

in einem eigenen Git-Repository weiterzupflegen. 

Daraus erwuchs die Entscheidung einiger 

ehemaliger Mitglieder der Bacula-Community, 

dies als eigenständigen Fork unter dem Namen 

Bareos weiterzuentwickeln. 

Das erste Stable-Release war Bareos 12.4 im 

April 2013, wobei die Versionsnummer für das 

Jahr und das Quartal des Feature Freeze steht. 

Die Version 13.2 ist derzeit im Beta-Stadium 

und soll spätestens im September 2013 veröffentlicht 

werden. 

werden. Die maximale Größe der Dateien 

und die maximale Anzahl wird im 

Director Daemon in der Pool Ressource 

definiert, das heißt in der Datei »/etc/ 

bareos/bareos‐dir.conf«. 

Um ein solches virtuelles Band anzulegen, 

startet man das Programm »bconsole«, 

das einem mit dem Prompt »*« 

empfängt. Dort gibt man dann »label«, 

einen Namen (hier: »file1«) und danach 

»2« für den Pool »File« an (Listing 2). 

Mittels »status director« kann man sich 

die nächsten geplanten Jobs anzeigen 

lassen (Listing 3). 

Die Sicherungen sind in der Konfigurationsdatei 

auf 23:05 Uhr (BackupClient1: 

Dateisystem) beziehungsweise. 23:10 Uhr 

(BackupCatalog: Datenbank-Eigensicherung) 

voreingestellt. 

Möchte man eine Testsicherung durchführen, 

kann man sie mit dem Kommando 

»run« starten. Dann muss der Admin 

nur noch angeben, welchen Client er 

sichern möchte und schon beginnt die 

Sicherung. Das Ergebnis zeigt dann ein 

Aufruf des Kommandos »status director« 

an (Listing 4). 

E 

01 *label 

Listing 1: Dienste starten 

01 su postgres ‐c /usr/lib/bareos/scripts/create_bareos_ 

database 

02 su postgres ‐c /usr/lib/bareos/scripts/make_bareos_ 

tables 

03 su postgres ‐c /usr/lib/bareos/scripts/grant_bareos_ 

privileges 

04 

05 service bareos‐dir start 

06 service bareos‐sd start 

07 service bareos‐fd start 

Listing 2: Virtuelles Band labeln 

02 Automatically selected Storage: File 

03 Enter new Volume name: file1 

04 Defined Pools: 

05 1: Default 

06 2: File 

07 3: Scratch 

08 Select the Pool (1‐3): 2 

09 Connecting to Storage daemon File at bareos:9103 ... 

10 Sending label command for Volume "file1" Slot 0 ... 

11 3000 OK label. VolBytes=186 Volume="file1" 

Device="FileStorage" (/var/lib/bareos/storage) 

12 Catalog record for Volume "file1", Slot 0 

successfully created. 

13 Requesting to mount FileStorage ... 

14 3001 OK mount requested. Device="FileStorage" (/var/ 

lib/bareos/storage) 

15 * 


Admin 


57

Know-how 

Bareos 

Mittels »status scheduler« kann man sich 

anzeigen lassen, wann Jobs geplant sind, 

mittels »status scheduler days=365« auch 

für ein ganzes Jahr im Voraus. 

Verbesserungen 

Außer bei der Installation gibt es eine 

Reihe weiterer Verbesserungen, die das 

Leben des Bareos-Administrators einfacher 

machen: Wer schon einmal mit 

Baculas Konfigurationsdateien gearbeitet 

hat, wird sich freuen, dass bei Bareos 

fast alles mit sinnvollen Default-Werten 

vorbelegt ist. Bareos kennt nämlich im 

Gegensatz zu Bacula auch Voreinstellungen 

für String-Werte. So muss man 

sich zum Beispiel keine Gedanken mehr 

um die Angabe von »Pid Directory« und 

»Working Directory« in der File-Daemon- 

Konfiguration auf dem Client machen. 

Bareos setzt sinnvolle Werte für die entsprechende 

Plattform, wenn es die Pakete 

erstellt. 

Bei Windows-Systemen ist es jetzt möglich, 

ohne großen Aufwand nicht nur ein 

einzelnes, sondern alle angebundenen 

Laufwerke zu sichern (Windows Drive 

Discovery). Bei Bacula ist dies nur in 

der kommerziellen Version möglich. Dafür 

wurde auch der Aufruf des Volume 

Shadow Copy Service (VSS) intelligenter 

gestaltet. 

Die Handhabung von Tape Libraries 

wurde vereinfacht. So können Bänder 

Listing 4: Status Director 

01 *status director 

02 ... 

03 Terminated Jobs: 

04 JobId Level Files Bytes Status Finished Name 

05 ===================================================== 

06 1 Full 135 6.679 M OK 18‐Jul‐13 16:00 BackupClient1 

07 2 Incr 0 0 OK 18‐Jul‐13 16:01 BackupClient1 

08 

09 ... 

Listing 3: Statusanzeige 

01 *status director 

02 Scheduled Jobs: 

03 Level Type Pri Scheduled Name Volume 

04 ===================================================== 

05 Incremental Backup 10 18‐Jul‐13 23:05 

BackupClient1 file1 

06 Full Backup 11 18‐Jul‐13 23:10 

BackupCatalog file1 

07 ... 

jetzt innerhalb 

der Bconsole von 

Copy Job 

einem Slot zum 

anderen bewegt 

werden. Auch 

kann ein eventuell 

vorhandener Import-/Export-Slot 

bequem mit dem 

Kommando »import« 

Console 

Director 

beziehungs- 

Storage 1 

weise »export« 

angesprochen 

werden. 

Der Tray-Monitor 

(ein kleines Icon 

im Systembereich 

der Taskleiste) läuft 

auf Windows- und 

filedaemon 

auf Linux-Systemen. 

Abbildung 2: Bisher: Kopieren ist nur innerhalb eines Storage Daemons möglich. 

Das Blinken 

des Icons zeigt an, dass auf dem System 

gerade eine Sicherung stattfindet. 

Wenn ein Backup-Job doch mal fehlschlägt, 

ist es jetzt einfach möglich, einen 

Job mit genau den gleichen Parametern 

nochmals zu starten: 

festlegen. Zudem kann man sich mittels 

Soft-Quotas und Grace-Periode auch 

frühzeitig informieren lassen, wenn die 

Quotierung erschöpft ist. 

Außerdem sollte man im Blick behalten, 

dass bei einer Vollsicherung große Datenmengen 

durch das Netz zu transportieren 

*rerun jobid=id 

Der Backup-Administrator muss sicherstellen, 

dass alle relevanten Daten eine 

gewisse Zeit lang aufgehoben werden. 

Für steuerrelevante Daten ist eine Aufbewahrungsfrist 

von 10 Jahren vorgeschrieben, 

die man sorgfältig planen muss. Will 

sind. Da ist es von Vorteil, dass Bareos 

auch die maximal genutzte Netzwerkbandbreite 

pro Client einschränken kann. 

Hierfür dient die Direktive »Maximum 

Bandwidth Per Job«, die zu dem entsprechenden 

Client-Eintrag in »/etc/bareos/ 

bareos‐dir.conf« hinzuzufügen ist: 

man die Daten nach verschiedenen Eigenschaften 

trennen, nutzt man in Bareos 

dafür Pools. Für sie lassen sich unter 

anderem Größen und Aufbewahrungszeiten 

definieren. 

Client { 

Name = client2‐fd 

Address = client2 

Password = "secret" 

Maximum Bandwidth Per Job = 512 k/s 

Komplexe Umgebungen 

Manchmal ist für den Administrator 

schwer kalkulierbar, wie groß ein 

Backup wird. Ein erster Ansatz, damit 

umzugehen, besteht darin, bestimmte 

Verzeichnisse und Datentypen in den die 

Sicherung beschreibenden Dateilisten 

auszuschließen. Alternativ lassen sich 

auch Dateien ab einer bestimmten Größe 

ausschließen. 

Dies garantiert aber nicht, dass auf einem 

Client nicht trotzdem große Datenmengen 

anfallen. Mit einer Client-Quota kann 

man bei Bareos daher die Gesamtmenge 

der zu sichernden Daten eines Clients 

} 

Als grundlegende Neuerung ist die direkte 

Unterstützung von NDMP (Network 

Data Management Protocol) hinzugekommen. 

NDMP ist das native Backup- 

Protokoll großer NAS-Geräte wie etwa 

von NetApp. Mit der Version 12.4 werden 

Vollsicherungen und Rücksicherungen 

unterstützt. Die Wiederherstellung von 

Einzeldateien ist bei Bareos noch in der 

Erprobungsphase. 

Zudem wurde ein neues Plugin zur Sicherung 

von Microsoft-SQL-Server-Datenbanken 

geschrieben. Es beherrscht 

neben Voll- auch inkrementelle und differenzielle 

Sicherungen und befindet sich 

ebenfalls in der Erprobungsphase. 


Bareos 

Know-how 

Das nächste Projekt geht die Sicherung 

virtueller Maschinen von VMware über 

die VStorage-API an. Hier wurden bereits 

die ersten Gehversuche unternommen. 

Copy-Jobs 

Backup-Bänder sind immer noch das 

Mittel der Wahl für das Sichern von Daten, 

aber auch Sicherungen auf Festplatte 

haben ihre Vorteile. Deshalb werden 

häufig beide Ansätze verknüpft: Üblich 

sind Disk-To-Disk-To-Tape-Sicherungen 

(D2D2T). Dabei wird zuerst auf Festplatte 

gesichert, danach werden die Daten über 

einen Migrations- oder Copy-Job auf ein 

Band übertragen. 

Vor Bareos 13.2 konnten Migrations- und 

Copy-Jobs nur innerhalb eines Storage 

Daemons durchgeführt werden (Abbildung 

2). Diese Einschränkung ist mit 

Bareos 13.2 aufgehoben – Daten lassen 

sich nun zwischen Storage Daemons 

transportieren (Abbildung 3). 

Damit ist es möglich, Daten beispielsweise 

in unterschiedlichen Brandschutzabschnitten, 

zu sichern. Ein entsprechender 

Copy-Job kann Daten periodisch 

auch zu einem anderen Storage Daemon 

kopieren. Dabei lassen sich die Eigenschaften 

der Daten anpassen, sodass zum 

Beispiel die Daten auf dem ersten Storage 

Daemon unkomprimiert abgelegt sind, 

für den zweiten aber komprimiert werden. 

Auch Szenarien wie Backup-to-Diskto-Cloud 

sind so abbildbar. 

Passive Clients 

Ein häufiges Problem bei der Einrichtung 

der Backup-Umgebung sind Firewalls. Bei 

Console 

Director 

filedaemon 

einem normalen Verbindungsaufbau in 

einer Bareos-/Bacula-Umgebung würde 

der Backup Director eine Verbindung 

zum Client aufbauen und ihm mitteilen, 

was und wohin er sichern soll. Außerdem 

verbindet er sich mit dem Backup Storage 

Daemon und teilt diesem mit, dass er die 

Daten vom Client in Empfang nehmen 

und speichern soll. Schließlich baut der 

Client die eigentliche Datenverbindung 

zum Storage Daemon auf und überträgt 

seine Daten dorthin. 

Wenn der Client sich hinter einer Firewall 

befindet, dann erschweren Paketfilter 

und Network Address Translation (NAT) 

in der Firewall eine Verbindung vom Client 

zum Storage Daemon oder machen 

diese gar unmöglich. Die problematische 

Verbindung ist also die eigentliche Datenverbindung 

zwischen Client und Storage 

Daemon (Abbildung 4). 

Ab Bareos 13.2 ist dieses Verhalten nun 

konfigurierbar. Mithilfe der Option »Passive 

Client« lassen sich alle Verbindungen 

von den Server-Komponenten her aufbauen. 

Der Client nimmt dann nur noch 

Verbindungen entgegen. Der Aufbau der 

Verbindungen zwischen Director und Client 

und zwischen Director und Storage 

Daemon bleiben wie gehabt, aber die 

eigentliche Datenverbindung wird nun 

nicht vom Client, sondern vom Storage 

Daemon initiiert. Nachdem die Verbindung 

aufgebaut wurde, werden die Daten 

natürlich doch vom Client zum Storage 

Daemon übertragen (Abbildung 5). 

Neben der Firewall-Freundlichkeit hat 

dieser Ablauf noch einen weiteren Vorteil: 

Da der Passive Client keinerlei Datenverbindung 

aufbaut, benötigt er auch 

keine funktionierende Namensauflösung. 

Copy Job 

Storage 1 Storage 2 

Abbildung 3: Neu: Kopieren ist zwischen verschiedenen Storage Daemons über das Netzwerk möglich. 

In der Praxis hat sich gerade die Namensauflösung 

beim herkömmlichen Verfahren 

häufig als Problem herausgestellt. 

Sicherheit 

Bareos bietet im Hinblick auf Sicherheit 

weiterhin die bereits aus Bacula bekannten 

Sicherheits-Features wie: 

n Prüfsummenberechnung auf jeder gesicherten 

Datei und Überprüfung bei 

der Rücksicherung, 

n die Möglichkeit, die Verbindungen 

zwischen den Daemons über TLS zu 

verschlüsseln. 

Zusätzlich wurden zu Bareos aber weitere, 

interessante Sicherheitsfunktionen 

hinzugefügt: 

So kann man nun bei Software-Verschlüsselung 

das Verschlüsselungsverfahrens 

wählen. Bisher konnte dabei immer nur 

AES128 verwendet werden. Nun kommen 

zusätzlich die folgenden Verfahren 

in Frage: AES128, AES192, AES256, CA- 

MELIA128, CAMELIA192, CAMELIA256, 

AES128HNACSHA1, AES256HNACSHA1 

und Blowfish. 

Neben den Verschlüsselungsoptionen der 

Software gibt es jetzt die Möglichkeit, 

direkt die Hardware-Verschlüsselung 

der LTO-Bandlaufwerke zu nutzen. Seit 

LTO4 ist die Verschlüsselung Teil des LTO- 

Standards, sodass alle Laufwerke diese 

Option anbieten. Die Verschlüsselung im 

Bandlaufwerk hat dank Hardware-Unterstützung 

praktisch keine Auswirkung auf 

die Sicherungsgeschwindigkeit. 

Ob man das nutzen möchte, hängt natürlich 

von den Anforderungen ab. Die 

LTO-Hardware-Verschlüsselung ist vor 

allem für diejenigen eine effiziente Option, 

die ihre Bänder auslagern und dabei 

vermeiden möchten, dass Unbefugte sie 

lesen können. 

Die bereits erwähnte Option Passive Client 

stellt ebenfalls einen Sicherheitsgewinn 

dar: Weil keine Verbindung zum Storage 

Daemon mehr notwendig ist, können die 

Firewalls sämtliche Verbindungen zum 

Sicherungsnetzwerk verhindern. 

Bisher war es möglich, dem Client vom 

Director aus beliebige Kommandos zu 

senden. Das waren »backup« (Ausführen 

einer Sicherung), »restore« (Ausführen einer 

Rücksicherung), »verify« (Ausführen 

eines Prüfjobs zum Abgleich zwischen 

Systemdaten und gesicherten Daten), 


Admin 


59

Know-how 

Bareos 

Kommunikation bisher: 

Director 

Kommunikation mit "Passive Client: 

Director 

Console 

Storage 

Console 

Storage 

• Zugriff ins interne Netz 

muss erlaubt werden 

• bei NAT: Portforwarding 

Firewall/NAT 

• Firewall kann alles nach 

Innen blocken 

• NAT ist auch in mehreren 

Stufen kein Problem 

Firewall/NAT 

• gesicherter Server muss 

Verbindung aufbauen dürfen 

• Tricks mit Namensauflösung 

nötig 

filedaemon 

• gesicherter Server baut keine 

Verbindungen auf 

• Namensauflösung nicht nötig 

filedaemon 

Abbildung 4: Bisher: Die Datenverbindung wird vom Client zum Storage Daemon 

initiiert. 

Abbildung 5: Passive Client: Die Datenverbindung wird vom Storage Daemon zum 

Client initiiert. 

»estimate« (Abschätzen der zu erwartenden 

Sicherungsdatenmenge) und 

»runscript« (Ausführen eines Skritpts auf 

dem Client-System). 

Nun ist es möglich, mithilfe der Direktive 

»Allowed JobCommand« diese Befehle 

auf dem Client zu filtern. Nicht erlaubte 

Befehle werden dann vom Client nicht 

akzeptiert und nicht ausgeführt. 

Das Ausführen von Skripten auf dem zu 

sichernden System stellt eine besondere 

Sicherheitsgefährdung dar. Falls es sich 

nicht über »Allowed JobCommand« komplett 

verbieten lässt, kann über die Option 

»Allowed ScriptDir« das Verzeichnis 

gesetzt werden, in dem sich Skripte und 

Befehle befinden müssen. Befehle, die 

sich nicht innerhalb dieses Verzeichnisses 

befinden, werden nicht ausgeführt. 

Integration 

Ein Backup-Client sollte sich möglichst 

effizient auf Client-Systeme verteilen lassen 

und dort pflegeleicht laufen. Dies gilt 

insbesondere, wenn viele verschiedene 

Plattformen angeschlossen sind. Deshalb 

arbeitet Bareos auch mit alten Client- 

Versionen zusammen und unterstützt 

Bacula-File-Daemons ab Version 2.0 (aus 

dem Jahr 2007). 

Für Univention-Corporate-Umgebungen 

gibt es eine Bareos-Version für das Univention 

App Center. Dort kann man über 

die UCS-Oberfläche für jeden Rechner 

angeben, ob er gesichert werden soll. Die 

Bareos-Server-Konfiguration wird daraus 

automatisch erstellt, die Client-Konfiguration 

vorbereitet. 

Bareos stellt auch direkt Pakete für 

die Open-Source-Windows-Software- 

Manage mentlösung OPSI zur Verfügung. 

Sie können auf dem OPSI-Server installiert, 

mit den passenden Voreinstellungen 

belegt und dann auf alle angeschlossenen 

Windows-Systeme verteilt werden. Ein 

Skript erstellt dann mit Hilfe der OPSI- 

JSON-RPC-Schnittstelle die passende 

Bareos-Director-Konfiguration. 

Für Windows bietet Bareos einen nativen 

Installer, der die Grundkonfiguration der 

Software durchführt, Passwörter setzt 

und sogar die Windows-Firewall öffnet. 

File Daemon und Tray-Monitor werden 

so konfiguriert, dass sie sofort zusammenarbeiten. 

Ein sehr gut funktionierendes System 

für das Desaster Recovery von Linux- 

Maschinen stellt das Projekt Relax And 

Recover (REAR) [3] bereit. Der Ansatz 

dieses Projektes ist zweigeteilt. Installiert 

auf dem zu sichernden System, erzeugt 

der Aufruf 

sudo /usr/sbin/rear ‐v mkrescue 

eine Rettungssystem-ISO-Datei von etwa 

60 MByte Größe, inklusive des laufenden 

Kernels, der benötigten Treibermodule, 

der Informationen zur Festplattenanbindung 

und der Netzwerkkonfiguration. 

In einem zweiten Schritt kann das Komplettsystem 

mittels 

sudo /usr/sbin/rear ‐v mkbackup 

gesichert werden, etwa auf ein freigegebenes 

NFS-Verzeichnis. 

Auf diesen zweiten Schritt kann man bei 

einer Sicherung mit Bareos verzichten. 

Stattdessen wird in das Rescue-System 

ein Bareos-Recovery-Modul integriert, 

sodass man nach dem Booten des Recovery-Systems 

die Option präsentiert bekommt, 

das System komplett zu löschen 

und durch das Backup zu ersetzen. Das 

entsprechende Bareos-Modul befindet 

sich gerade in der Testphase. 

Qualitätssicherung 

Die gesamte Entwicklung von Bareos findet 

offen auf Github [4] statt. Die Kommunikation 

erfolgt über Mailing-Listen. 

Feature Requests und Bugs können im 

Bug-Tracking-System [5] eingetragen 

werden. Details gibt es hierzu unter [6]. 

Für die automatisierte Qualitätssicherung 

werden drei unterschiedliche Systeme 

eingesetzt: 

n Build-Tests auf Basis von Travis [7], 

n Regression-Tests auf Basis von 

CDASH, 

n Test der verschiedenen Plattformen 

auf Basis von Jenkins und virtuellen 

Maschinen. 

Jeder in Github durchgeführte Commit 

stößt automatisch einen Build-Prozess auf 

[https:// travis‐ci. org/ bareos/ bareos] 

an. Dort wird der Quellcode kompiliert, 

die Daemons gestartet, eine Sicherung 

und Rücksicherung durchgeführt. Damit 

wird für jeden Commit geprüft, ob Bareos 

danach noch grundsätzlich funktionstüchtig 

ist. 

Weitergehende Tests werden auf einem 

auf CDASH basierenden Regression-Testsystem 

unter [8] durchgeführt. Gegenwärtig 

existieren etwa 130 unterschied- 


liche Tests, die jeweils bestimmte Funktionen 

in Bareos überprüfen. 

Der Entwicklungs-Workflow bei Bareos 

sieht vor, dass ein Ticket erst geschlossen 

werden soll, wenn für eine neue Eigenschaft 

auch ein Regression-Test erstellt 

wurde. Das wird dann im Ticket vermerkt. 

Ein neues Release wird erst erstellt, 

wenn die für Bareos mittels eines Open- 

Build-Servers gebauten Pakete zusätzlich 

einen auf Jenkins basierenden Test erfolgreich 

durchlaufen haben. Bei diesem 

Test werden die Pakete für die verschiedenen 

Plattformen auf entsprechenden 

virtuellen Maschinen getestet. Auf jeder 

Plattform werden automatisiert die Paketinstallation 

sowie Datensicherung und 

Rücksicherung überprüft. 

Auch die Windows-Pakete werden mithilfe 

des OBS und Cross-Kompilierung 

erstellt. Als Ergebnis entstehen dann 

auch die Windows-Installer und die 

OPSI-Pakete. 

Zukunft 

Der bis jetzt beschrittene Weg hat dem 

Bareos-Projekt viel Zuspruch eingebracht. 

Die Entscheidung, sich zum Projektstart 

erst einmal die Infrastruktur für eine 

weitgehende Automatisierung der Paket- 

Erzeugung und die Tests aufzubauen, hat 

sich bewährt. 

Weitere Plattformen können nun mit wenig 

Aufwand hinzugefügt werden, mit 

der Gewissheit, dass Probleme dank der 

kontinuierlichen Tests sehr schnell erkannt 

werden. 

Ebenfalls positiv aufgenommen wurde 

die Tatsache, das Bareos vollständig 

offen entwickelt wird. Auch wenn es 

kommerzielle Angebote für Subscription 

und Support von der Bareos GmbH & Co 

KG gibt, werden alle Ergänzungen und 

neuen Features in dem einen, offenen 

Github-Projekt entwickelt. 

Bei den weiteren Entwicklungen soll der 

bisherige Kurs fortgesetzt werden: 

n einfacher Einstieg, bessere Bedienbarkeit 

für Administratoren, 

n Integration in weitere Projekte/Distributionen, 

n Funktionserweiterungen. 

Der Einstieg soll demnächst durch eine 

weiter verbesserte Default-Konfiguration 

erleichtert werden. Zusätzlich werden 

OSBConf 

Am 25.9.2013 findet die Open Source Backup 

Conference (vormals Bacula Conference) [9] 

wie jeden Herbst in Köln statt. Das Bareos- 

Projekt nutzt diese Gelegenheit, um sich einem 

interessierten Fachpublikum vorzustellen 

und mit den Teilnehmern zu diskutieren. 

Whitepaper bestimmte Themen besser 

beleuchten. 

Ein Teilprojekt beschäftig sich mit der 

Entwicklung einer Konfigurations-API. 

Damit soll erreicht werden, dass sich bestimmte 

Konfigurationsänderungen problemfrei 

zur Laufzeit durchführen lassen, 

zum Beispiel das Hinzufügen eines Clients. 

Das können dann auch Frontends 

wie Webacula nutzen, um ihren Funktionsumfang 

mit einfachen Mitteln zu 

erweitern. (jcb) 

n 

Infos 

[1] Bareos: [http:// download. bareos. org] 

[2] OPSI: [http:// www. opsi. org] 

[3] Relax and Recover: [http:// 

relax‐and‐recover. org] 

[4] Bareos auf Github: [https:// github. com/ 

bareos] 

[5] Bug-Tracking-System: [https:// bugs. bareos. 

org] 

[6] Mitmachen: [http:// www. bareos. org/ 

howto‐contribute. html] 

[7] Build-Tests: [https:// travis‐ci. org] 

[8] Regression-Tests: [http:// regress. bareos. 

org/ index. php? project=bareos] 

[9] OSBConf: [http:// osbconf. org] 

Die Autoren 

Jörg Steffens beschäftigt sich seit 1995 mit Linux, 

unter anderem als Berater bei der SUSE Linux 

AG und seit 2004 als Geschäftsführer des Open- 

Source-Beratungsunternehmen »dass IT GmbH« 

aus Köln. 2012 hat er mit anderen langjährigen 

Bacula-Nutzern das Bareos-Projekt initiiert und 

die Bareos GmbH & Co KG gegründet. 

Philipp Storz beschäftigt sich sein 1998 mit Linux 

und seit 2007 mit Bacula. Seit 2001 beschäftigt 

er sich professionell mit Linux und arbeitet als 

Consultant zunächst bei der SUSE Linux AG und 

seit 2004 als Mitgründer bei der dass IT GmbH 

in Köln. Sein Buch zu Bacula ist 2012 bei Open 

Source Press erschienen. Seit der Gründung des 

Bareos-Projekts und der gleichnamigen Firma 

treibt er gemeinsam mit Marco van Wieringen 

die technische Entwicklung von Bareos voran. 



61

Know-How 

Exchange-Rechte 

© Marek Uliasz, 123RF 

Exchange-Rechteverwaltung in der Praxis 

Alles, was recht ist 

Exchange Server 2013 bietet eine umfangreiche Rechteverwaltung nach einem Rollenmodell. Verwalten lassen 

sich Rechte und Rollen in der Exchange-Konsole, der Powershell oder mit Zusatztools. Dieser Artikel führt alle 

drei Möglichkeiten vor. Thomas Joos 

Mit Exchange 2013 hat Microsoft seinen 

Messaging-Server auf ein rollenbasiertes 

Rechtemodell (RBAC) umgestellt. Unter 

anderem vereinfacht das für den Windows-Administrator 

die Verwaltung der 

Benutzerrechte. 

Es gibt zwei Typen von Rollen, die Sie zuweisen 

können: Administratorrollen und 

Endbenutzerrollen. Administratorrollen 

umfassen Berechtigungen, die Administratoren 

zur Verwaltung eines bestimmten 

Bereichs der Exchange-Organisation 

zugewiesen werden können. Wenn ein 

Benutzer Mitglied mehrerer Rollengruppen 

ist, erteilt Exchange ihm die Berechtigungen 

dieser Gruppen. 

Endbenutzerrollen beginnen mit dem 

Präfix »My«. Beispielsweise dürfen Mitglieder 

der Benutzerrolle »MyDistributionGroups« 

eigene Verteilergruppen 

anlegen und eigene Gruppen löschen. 

Das ist in Unternehmen nicht immer 

gewünscht. Mit der Steuerung der Berechtigungen 

können Sie diese Rechte 

normalen Anwendern entziehen. Der einfachste 

Weg dazu ist, wenn Sie auf Basis 

der vorhandenen Benutzerrolle »MyDistributionGroup« 

eine neue Rolle erstellen, 

ihr die entsprechenden Rechte entziehen 

und sie den Anwendern zuweisen. 

Sie können eine vorhandene Rollengruppe 

kopieren und ändern, unabhängig 

davon, ob es sich um eine Administratorrolle 

oder eine Endbenutzerrolle handelt, 

ohne dass sich das auf die ursprüngliche 

Rollengruppe auswirkt. Wenn Sie die 

Rollengruppe kopieren, legen Sie einen 

neuen Namen fest, fügen optional Rollen 

zur neuen Rollengruppe hinzu oder 

entfernen sie. Vorhandene Rollengruppen 

können ebenfalls geändert werden. 

Sie können Rollen vorhandenen Rollengruppen 

hinzufügen oder sie aus diesen 

Gruppen entfernen und gleichzeitig Mitglieder 

hinzufügen oder entfernen. Für 

die Standardgruppen bietet es sich aber 

an, Kopien zu erstellen, bevor Sie die 

Gruppen ändern. 

In Exchange Server 2013 finden Sie die 

Verwaltungsrollengruppen im Bereich 

»Berechtigungen«. Mit dem Commandlet 

»Get‐RoleGroup« lassen sich die verschiedenen 

Gruppen auch in der Verwaltungsshell 

anzeigen. »Get‐RoleGroupMember« 

zeigt die Mitglieder einer Gruppe an, 

zum Beispiel »Get‐RoleGroupMember 

"Organization Management"«. Um einen 

Benutzer in eine Gruppe aufzunehmen, 

verwenden Sie die Exchange-Verwaltungskonsole 

(Abbildung 1) oder die 

Exchange-Verwaltungsshell: 

Add‐RoleGroupMember VerwaltungsrollengruppeU 

‐Member Benutzerpostfach 

Um Mitglieder aus einer Verwaltungsrollengruppe 

zu entfernen, greifen Sie auch 

auf die Exchange-Verwaltungskonsole 

zurück oder geben in der Exchange-Verwaltungsshell 

den Befehl »Remove‐Role- 

GroupMember Verwaltungsrollengruppe 

‐Member Benutzerpostfach« ein. 

Klicken Sie in der Exchange-Verwaltungskonsole 

auf eine Gruppe, sehen Sie 

im rechten Bereich, welche Rechte die 

Gruppe hat und welche Mitglieder ihr 

zugeordnet sind. Um einen Benutzer in 

eine Gruppe aufzunehmen, klicken Sie 

doppelt auf die Gruppe. Anschließend 

können Sie bei »Mitglieder« neue Benutzer 

hinzufügen oder entfernen. 

Verwaltungsrollen fassen Commandlets 

zusammen, die zum Verwalten von 

Exchange-Komponenten dienen (Abbildung 

2). Benutzer, die Mitglieder einer 

Verwaltungsrollengruppe sind, erhalten 

das Recht, die Commandlets zu nutzen, 

die in den Verwaltungsrollen hinterlegt 

sind, welche wiederum Bestandteil der 

Verwaltungsrollengruppen sind. 

Pflege von Verwaltungsrollengruppen 

delegieren 

Stellvertreter von Verwaltungsrollengruppen 

können Mitglieder zu Verwaltungsrollengruppen 

hinzufügen oder daraus 

entfernen und Eigenschaften einer Rollengruppe 

anpassen, haben aber selbst 

keine Rechte, die Funktionen der Verwal- 



Know-How 

den Sie den Befehl »Get‐RoleGroup |fl 

Managedby«. 

Neben den Standardgruppen können Sie 

auch selbst Verwaltungsrollengruppen 

erstellen und ihnen Benutzer zuordnen. 

Neue Verwaltungsrollengruppen erstellen 

Sie mit dem Commandlet »New‐Role- 

Group«. Ein Beispiel zeigt Listing 1. 

Bestehende Rollengruppen können Sie 

kopieren, wenn Sie selbst Rollengruppen 

erstellen wollen, die zum Beispiel eingeschränkte 

Rechte nutzen. Dazu verwenden 

Sie am besten auch die Exchange- 

Verwaltungsshell zum Kopieren. Im ersten 

Schritt speichern Sie die Rollengruppe 

in einer Variablen: 

Abbildung 1: Die verschiedenen Verwaltungsgruppen steuern Sie in der Exchange-Verwaltungskonsole von 

Exchange Server 2013 im Bereich »Berechtigungen«. 

rollengruppe« die Einstellungen der 

Rollengruppe in einer Variablen. 

n Sie fügen den Stellvertreter zu der 

Rollengruppe hinzu, die Sie als Variable 

gespeichert haben: »$RoleGroup. 

ManagedBy += (Get‐User Postfach, 

das Sie hinzufügen wollen).Identity«. 

Wollen Sie eine universelle Gruppe 

hinzufügen, verwenden Sie das Commandlet 

»Get‐Group«. 

n Wiederholen Sie den obigen Befehl 

für jeden Stellvertreter, den Sie hinzufügen 

wollen. 

n Die Liste in der Variablen müssen Sie 

noch in die echte Verwaltungsrollengruppe 

hinzufügen: »Set‐RoleGroup 

Verwaltungsrollengruppe ‐ManagedBy 

$RoleGroup.ManagedBy«. 

Um die Anwender anzuzeigen, welche 

die Gruppe verwalten dürfen, verwentungsrollengruppe 

zu nutzen. Die Konfiguration 

des Stellvertreters erfolgt durch 

die Option »ManagedBy« für die Commandlets 

»Set‐RoleGroup« oder »New‐RoleGroup«. 

Sollen die Benutzer auch die 

Rechte der Gruppe erhalten, müssen Sie 

diese als Mitglieder der Rollengruppe aufnehmen. 

Die Option »ManagedBy« für 

das Commandlet »Set‐RoleGroup« überschreibt 

immer die gesamte Stellvertreterliste 

für eine Rollengruppe. 

Wollen Sie einzelne Stellvertreter zu einer 

Rollengruppe hinzufügen, ohne die gesamte 

Stellvertreterliste zu löschen, müssen 

Sie vorhandene Mitglieder speichern, 

das neue Mitglied hinzufügen und dann 

die Liste wieder speichern. Gehen Sie 

folgendermaßen vor (Abbildung 3): 

n Sie speichern mit dem Befehl: »$Role- 

Group = Get‐RoleGroup Verwaltungs- 

$RoleGroup = Get‐RoleGroup U 

Gruppe, die Sie kopieren wollen 

Verwenden Sie die folgende Syntax, um 

eine neue Rollengruppe zu erstellen, der 

Rollengruppe Mitglieder hinzuzufügen 

und anzugeben, wer die neue Rollengruppe 

an andere Benutzer delegieren 

kann: 

New‐RoleGroup Name ‐Roles U 

$RoleGroup.Roles‐Members Mitglied1,...U 

‐ManagedBy User1,User2,... 

Wollen Sie zum Beispiel die Rollengruppe 

»Organization Management« kopieren, 

um eine neue Gruppe zu erstellen, die 

weniger Rechte hat, verwenden Sie folgende 

Befehle: 

$RoleGroup = Get‐RoleGroup "Management" 

New‐RoleGroup "Limited Management" ‐Roles U 

$RoleGroup.Roles ‐Members Thomas, Michael, U 

Hans ‐ManagedBy Jean, Fritz 

RBAC-Manager 

Abbildung 2: Verwaltungsrollengruppen verwalten Sie mit einfachen Commandlets auch in der Exchange- 

Verwaltungsshell. 

Wer es bei der Verwaltung etwas komfortabler 

haben möchte, verwendet den 

RBAC-Manager [1]. Er benötigt keine Installation, 

sondern besteht nur aus einer 

Exe-Datei und einer XML-Steuerungsdatei. 

Sind die Exchange-Verwaltungstools 

auf einer Arbeitsstation installiert, können 

Sie den RBAC-Manager auch von 

einer Arbeitsstation aus nutzen (Abbildung 

4). Das Tool ermöglicht die Steuerung 

der Verwaltungsrollen, der Zuweisungsrichtlinien 

und der Verwaltungsrollengruppen. 

Sobald das Programm gestartet ist, geben 

Sie den Namen des Servers ein, mit dem 


Admin 


63

Know-How 


Abbildung 3: Mit Hilfe der Powershell lässt sich die Rollenmitgliedschaft zuweisen und die Zuordnung zu einer 

Verwaltungsrollengruppe ändern. 

Sie sich verbinden wollen, sowie die Anmeldeinformationen. 

Anschließend verbindet 

sich der RBAC-Manager mit der 

Exchange-Organisation und verwendet 

die Rechte des angemeldeten Benutzers. 

Sie müssen dazu auf dem Server aber das 

.NET-Framework 3.5 installieren. In Windows 

Server 2012 verwenden Sie dazu 

den Server-Manager. Im oberen Bereich 

schalten Sie zwischen der Verwaltung 

von Verwaltungsrollen (Management Roles), 

Zuweisungsrichtlinien (Assignment 

Policies), Verwaltungsrollengruppen 

(Role Groups) und Verwaltungsbereichen 

(Management Scopes) um. 

Über »Role Groups« steuern Sie die Mitglieder 

und die Verwaltungsrollen sowie 

die Rollenzuweisungen. Hier lassen sich 

eigene Rollengruppen erstellen oder vorhandene 

anpassen. Änderungen speichert 

der RBAC-Manager in einer Protokolldatei, 

die sich über den Bereich »Tools« 

öffnen lässt. In der Protokolldatei ist das 

Powershell-Commandlet zu sehen, mit 

dem der RBAC-Manager die Konfigurationsaufgabe 

abgearbeitet hat. 

Überwachen der Verwaltung 

von Rollengruppen 

Sie können sich in der Exchange-Verwaltungskonsole 

auch anzeigen lassen, 

wer Änderungen an den Berechtigungen 

vornimmt, also anderen Benutzern Administratorrechte 

zuteilt: 

n Klicken Sie auf »Verwaltung der Richtlinientreue 

| Überwachung | Administrator 

Rollengruppenbericht ausführen«. 

n Wählen Sie die Rollengruppe aus, die 

Sie überwachen wollen. 

n Klicken Sie auf »Suchen«. Im Fenster 

sehen Sie jetzt alle durchgeführten 

Änderungen. 

In der Exchange-Verwaltungsshell können 

Sie die Administratoren und deren 

Berechtigungen anzeigen. Mit der Option 

»GetEffectiveUsers« des Commandlets 

»Get‐ManagementRoleAssignment« zeigen 

Sie die Rechte an: 

Get‐ManagementRoleAssignment ‐Role U 

Verwaltungsrolle ‐GetEffectiveUsers 

Wollen Sie nur einen bestimmten Benutzer 

anzeigen, verwenden Sie den folgenden 

Aufruf: 

Get‐ManagementRoleAssignment ‐Role U 

Verwaltungsrolle ‐GetEffectiveUsers U 

| Where { $_.EffectiveUserName ‐Eq U 

"Benutzername" } 

Wollen Sie alle Verwaltungsrollen eines 

Benutzers anzeigen, verwenden Sie: 

Get‐ManagementRoleAssignment U 

‐GetEffectiveUsers | Where { $_.U 

EffectiveUserName ‐Eq "Benutzername" } 

Endbenutzerrollen 

Neben den Administratorrollen zur Verwaltung 

der Exchange-Server können 

Sie in Exchange auch die Rechte von 

Benutzern für ihr eigenes Postfach und 

Verteilergruppen steuern. Mit Rollenzuweisungsrichtlinien 

können Sie steuern, 

welche Konfigurationseinstellungen Benutzer 

für Postfächer und Verteilergruppen 

ändern können. 

Wollen Sie alle Postfächer anzeigen, denen 

eine bestimmte Zuweisungsrichtlinie 

zugeordnet 

ist, verwenden Sie 

das Commandlet 

»Get‐Mailbox« und 

geben das Ergebnis 

an das Commandlet 

»Where« 

weiter: 

Get‐Mailbox | Where U 

{ $_.RoleAssignmentU 

Policy ‐Eq "ZuweiU 

sungsrichtlinie"} 

Sie können die Zulassungsrichtlinie, 

die einem Benutzerkonto zugewiesen ist, 

auch in den Eigenschaften des Benutzerkontos 

in der Exchange-Verwaltungskonsole 

anzeigen und die Zuweisung ändern. 

Rufen Sie dazu das Menü »Postfachfunktionen« 

auf. Mit dem folgenden Befehl 

ändern sie die Standard-Zuweisungsrichtlinie, 

die Exchange neuen Postfächern 

automatisch zuordnet: 

Set‐RoleAssignmentPolicy U 

Zuweisungsrichtlinie ‐IsDefault 

Neuen Postfächern weist Exchange immer 

die standardmäßige Zuweisungsrichtlinie 

zu, auch dann, wenn sie keine 

Verwaltungsrollen enthält. Ein Postfach 

kann nur eine Rollenzuweisungsrichtlinie 

verwenden. Wollen Sie bestimmten 

Benutzern andere Rechte zuweisen, müssen 

Sie für diese Postfächer eine eigene 

Rollenzuweisungsrichtlinie erstellen und 

diese vergeben. Nachdem Sie im Bereich 

»Berechtigungen | Benutzerrollen« eine 

neue Rollenzuweisungsrichtlinie erstellt 

haben, ordnen Sie ihr die gewünschten 

Verwaltungsrollen zu. Anschließend weisen 

Sie die Rollenzuweisungsrichtlinie 

den gewünschten Postfächern zu. Wollen 

Sie die Richtlinie für alle Postfächer ändern, 

denen eine bestimmte Zuweisungsrichtlinie 

zugewiesen ist, verwenden Sie 

folgenden Befehl: 

Get‐Mailbox | Where { $_.RoleAssignmentU 

Policy ‐Eq "Alte Zuweisungsrichtlinie" } |U 

Set‐Mailbox ‐RoleAssignmentPolicy Neue 

Richtlinie 

Verwenden Sie am Ende des Befehls die 

Option »WhatIf«, können Sie sich anzeigen 

lassen, was der Befehl machen 

würde, ohne die Änderungen tatsächlich 

auszuführen. 

Abbildung 4: Mit dem RBAC-Manager verwalten Sie die Rollengruppen in Exchange. 



Know-How 

Die Verwaltungsrollengruppe »MyDistributionGroup« 

darf in Exchange Server 

2010/2013 nicht nur Mitglieder bestimmter 

Verteilergruppen hinzufügen oder entfernen, 

sondern auch Verteilergruppen 

selbst entfernen und erstellen. Solche 

Vorgänge wollen Administratoren aber 

möglichst verhindern. Es reicht oft aus, 

wenn bestimmte Anwender die Mitgliedschaften 

steuern dürfen. Welche Rechte 

die Benutzerrollengruppe »MyDistributionGroups« 

hat, sehen Sie auch in der 

Exchange-Verwaltungsshell, wenn Sie 

den Befehl »Get‐ManagementRoleEntry 

‐Identity MyDistributionGroups\*« eingeben. 

Einfacher geht das, wenn Sie den 

RBAC-Manager nutzen. 

Verwaltungsrollengruppen 

Die Einstellungen vorhandener Verwaltungsrollengruppen 

sollten Sie nicht anpassen. 

Besser ist es, wenn Sie eine neue 

Verwaltungsrollengruppe erstellen und 

ihr die entsprechenden Mitglieder und 

Rechte zuweisen. In der Exchange-Verwaltungsshell 

verwenden Sie als Beispiel 

für die Verwaltung von Verteilergruppen 

zum Beispiel den Befehl: 

New‐ManagementRole ‐Parent "MyDistributionU 

Groups" ‐Name Contoso‐MyDistributionGroups 

Sie erstellen so eine neue Gruppe und 

weisen ihr die Rechte der übergeordneten 

Gruppe hinzu. Im RBAC-Manager klicken 

Sie die entsprechende Gruppe mit der 

rechten Maustaste an und wählen »New 

Role from Here«. Anschließend geben 

Sie einen Namen ein. Sie können für 

die neue Gruppe jetzt Rechte anpassen, 

indem Sie die Haken bei den Rechten 

der übergeordneten Rollengruppe aus der 

untergeordneten Gruppe entfernen. 

Listing 1: Neue Verwaltungsrollengruppe 

Sie können die Rechte dafür auch in der 

Exchange-Verwaltungsshell steuern. Wollen 

Sie zum Beispiel verhindern, dass 

die Anwender zukünftig Verteilergruppen 

anlegen und löschen dürfen, verwenden 

Sie die beiden Befehle: 

Get‐ManagementRoleEntry ‐Identity "Contoso‐U 

MyDistributionGroups\New‐DistributionGroup" | U 

Remove‐ManagementRoleEntry 

und 

Get‐ManagementRoleEntry ‐Identity "Contoso‐U 

MyDistributionGroups\Remove‐DistributionGroup"| U 

Remove‐ManagementRoleEntry 

Haben Sie die Rechte konfiguriert, können 

Sie sie in der Exchange-Systemsteuerung 

über die Zuweisungsrollenrichtlinie 

den Anwendern zuweisen. In Exchange 

01 New‐RoleGroup ‐Name "Contoso Recipient Management" ‐Roles "Mail Recipients", "Distribution Groups", 

"Move Mailboxes", "UM Mailboxes", "Reset Password" ‐CustomRecipientWriteScope "Contoso Users", 

‐ManagedBy "Thomas", "Tami", "Fynn" ‐Members "Stefan", "Marc", "Marco", "Hans", "Michael" 

Anzeige 


Admin 


65

Know-How 


Abbildung 5: Erstellen einer neuen Gruppenbenennungsrichtlinie. 

Abbildung 6: Konfigurieren der Gruppenmitgliedschaften einer Verteilerliste. 

Server 2013 verwenden Sie dazu die Exchange-Verwaltungskonsole 

und den Bereich 

»Berechtigungen | Benutzerrollen«. 

In den Eigenschaften der »Default Role 

Assignment Policy« weisen Sie die neu 

erstellte Verwaltungsrollengruppe hinzu 

und bestätigen die Änderung. Haben Sie 

eine Rollengruppe kopiert, entfernen Sie 

den Haken für die bereits zugewiesene 

und setzen den Haken bei der von Ihnen 

erstellten Richtlinie, sodass die Anwender 

nur die neuen Rechte erhalten. 

Anschließend wird darüber allen Anwendern 

mit dieser Richtlinie die Verwaltungsrollengruppe 

zugewiesen. Sie 

können für den Vorgang aber auch den 

RBAC-Manager verwenden. Dazu klicken 

Sie auf die Schaltfläche »Show Assignment 

Policies«, wählen die »Default Role 

Assignment Policy« aus und weisen die 

von Ihnen erstellte Verwaltungsrollengruppe 

zu. 

Durch die Zuordnung zur Richtlinie werden 

den entsprechenden Benutzern die 

Rechte erteilt, die Sie der Verwaltungsrollengruppe 

zugewiesen haben. Welche 

Richtlinie einem Benutzer zugewiesen 

ist, sehen Sie wiederum in den Einstellungen 

des entsprechenden Postfachs. 

In Exchange Server 2013 finden Sie die 

Einstellung über Empfänger und dann 

über das Menü »Postfachfunktionen«. 

Nehmen Sie größere Änderungen vor, ist 

es sinnvoll, den Exchange-Server neu zu 

starten. 

Eine Benennungsrichtlinie für Gruppen 

ermöglicht das Standardisieren von Verteilergruppen, 

die von Benutzern und 

anderen Administratoren in der Organisation 

erstellt werden. Sie können 

festlegen, dass dem Namen von neuen 

Verteilergruppen bei der Erstellung ein 

bestimmtes Präfix und Suffix hinzugefügt 

werden muss. Außerdem können 

Sie die Verwendung bestimmter Wörter 

verbieten. 

Ignorierte Richtlinien 

Gruppenbenennungsrichtlinien werden 

nur auf Gruppen angewendet, die von 

Benutzern erstellt werden. Wenn Sie oder 

andere Administratoren mit der Exchange- 

Verwaltungskonsole Verteilergruppen erstellen, 

wird die Gruppenbenennungsrichtlinie 

ignoriert. Sie erstellen Gruppenbenennungsrichtlinien 

am besten in der 

Exchange-Verwaltungskonsole: 

n Wählen Sie in der Exchange-Verwaltungskonsole 

»Gruppen | Mehr ... | 

Gruppenbenennungsrichtlinie konfigurieren«. 

n Konfigurieren Sie unter »Gruppenbenennungsrichtlinie« 

das Präfix, indem 

Sie im Pulldown-Menü entweder »Attribut« 

oder »Text« auswählen (Abbildung 

5). Geben Sie die gewünschte 

Textzeichenfolge ein und klicken Sie 

anschließend auf »OK«. Die eingegebene 

Textzeichenfolge oder das ausgewählte 

Attribut wird als Link dargestellt. 

Klicken Sie auf den Link, um 

die Textzeichenfolge oder das Attribut 

zu ändern. 

n Klicken Sie auf »Hinzufügen«, um weitere 

Präfixe hinzuzufügen. 

Sie können die erstellten Richtlinien auch 

in der Exchange-Verwaltungsshell anzeigen. 

Verwenden Sie dazu den Befehl 

»Get‐OrganizationConfig | fl Distribution- 

GroupNamingPolicy«. Führen Sie folgenden 

Befehl aus, um eine Gruppenbenennungsrichtlinie 

außer Kraft zu setzen: 

New‐DistributionGroup ‐Name GruppeU 

‐IgnoreNamingPolicy 

Gruppenmitgliedschaften 

Über die Seite »Mitgliedschaftsgenehmigung« 

in den Eigenschaften von Verteilergruppen 

steuern Sie, ob für den Beitritt 

zur Gruppe eine Genehmigung des Besitzers 

erforderlich ist. Hier stehen Ihnen 

verschiedene Möglichkeiten zur Konfiguration 

zur Verfügung (Abbildung 6). 

Empfänger können aber Verteilerlisten 

nicht nur beitreten, sondern selbst auch 

aus Gruppen austreten. Auch hierzu verwenden 

Sie die »Outlook Web App« und 

dann »Optionen | Gruppen«. 

Wie man sieht, gibt es in Exchange viele 

Möglichkeiten, Rechte zu delegieren und 

Bereiche wie die Verteilergruppen so zu 

konfigurieren, dass sich diese nach der 

Einrichtung selbst pflegen. Mit etwas 

Mühe und der Anpassung der Berechtigungen 

können Administratoren im laufenden 

Betrieb viel Zeit sparen. (ofr) n 

Infos 

[1] RBAC-Manager: [http:// rbac. codeplex. com] 

Der Autor 

Thomas Joos ist freiberuflicher IT-Consultant und 

seit über 20 Jahren in der IT tätig. Neben seinen 

Projekten schreibt er praxisnahe Fachbücher 

und Fachartikel rund um Windows und andere 

Microsoft-Themen. Online trifft man ihn unter 

[http:// thomasjoos. spaces. live. com]. 


Netzwerk 

Floodlight 

© aurielaki, 123RF 

Open-Source-Netzwerkzukunft: Der Floodlight-OpenFlow-Controller 

Leitstandstechnik 

Die Schlagworte Netzwerkvirtualisierung und Software Defined Networking (SDN) markieren einen Paradigmenwechsel 

im Bereich der Kommunikationsnetze. Der Weg führt zu einem ganzheitlichen Netzwerkkonzept, für das 

mit Floodlight eine vielversprechende Open-Source-Software zur Verfügung steht. Dr. Michael Bredel 

Heutige Kommunikationsnetze basieren 

in weiten Teilen auf den einfachen, 

ursprünglichen Mechanismen von Ethernet 

und TCP/IP. Durch dessen Erfolg und 

das dadurch bedingte enorme Wachstum 

der Netze wurden jedoch immer 

komplexere Kontrollmöglichkeiten wie 

VLANs, ACLs, Firewalls und Deep Packet 

Inspection notwendig. Dabei implementiert 

eine Vielzahl von heterogenen 

Netzwerk-Appliances (Firewalls, Load 

Balancer, IDS, Optimierer und so weiter 

– kurz sogenannte Middleboxes) jeweils 

ihren eigenen proprietären Kontroll-Stack 

sowie ein zumeist herstellerabhängiges 

Management-Interface in Form eines 

CLI, einer Weboberfläche oder eines 

Management-Protokolls. Die Kommunikation 

untereinander erfolgt dezentral 

über immer komplexere Protokolle wie 

Spanning Tree, Shortest Path Bridging, 

Border Gateway oder ähnliches. 

Jede zusätzliche Komponente erhöht somit 

die Komplexität und erschwert ein 

integriertes Netzwerkmanagement. Die 

Folgen sind häufig eine geringe Netzauslastung, 

schlechte Verwaltbarkeit, 

mangelnde Kontrollmöglichkeiten in 

netzübergreifenden Konfigurationen und 

ein Vendor-Lock-in. 

Ausweg OpenFlow 

Einen Ausweg aus diesem Dilemma versprechen 

Software Defined Networks 

(SDNs) und OpenFlow. OpenFlow ist ein 

von der Open Networking Foundation 

(ONF) standardisiertes Protokoll, das die 

komplexen Details einer schnellen und 

effizienten Switching-Architektur abstrahiert 

und einem externen Controller 

direkt zur Verfügung stellt. Mit Open- 

Flow steht heute für Netzwerkkomponenten 

eine offene Kontrollschnittstelle 

zur Verfügung, die mittlerweile von allen 

namhaften Herstellern hardwareseitig implementiert 

wird. Darüber hinaus gibt es 

einige Implementierungen in Form von 

Software-Switches, die den Einsatz in 

virtualisierten Rechenzentren erlauben. 

OpenFlow ermöglicht auch die im Konzept 

von Software Defined Networking 

geforderte Trennung von Daten- und 

Kontrollpfad. Das macht eine Netzwerkarchitektur 

möglich, in der eine zentrale 

Kontrollinstanz – der SDN-Controller 

– eine Vielzahl von OpenFlow-fähigen 

Netzwerkkomponenten steuert und eine 

netzwerkweite Sichtweise etwa auf Datenflüsse, 

Kontroll- und Sicherheitsinformationen 

wie VLANs oder ACLs besitzt. 

Der SDN-Controller selbst kann aus 

Gründen der Ausfallsicherheit oder zum 

Load Balancing verteilt sein. 

Das OpenFlow-Protokoll erlaubt eine einheitliche, 

direkte Kontrolle der Infrastruktur. 

Die Notwendigkeit eines komplexen 

und komplizierten Netzwerkmanagements 

entfällt in weiten Teilen. Dies erhöht 

die Flexibilität und überwindet ganz 

nebenbei die Notwendigkeit, sich auf einen 

einzigen Hardwarehersteller festlegen 

zu müssen. Darüber hinaus besteht 

mit OpenFlow die Möglichkeit zur Entwicklung 

eigener Netzwerkanwendun- 


Floodlight 

Netzwerk 

gen und damit einer besseren Integration 

des Netzwerks in ein Gesamtsystem mit 

Servern und Storage. Gleichzeitig erhofft 

man sich eine deutliche Senkung der Kosten. 

Abbildung 1 zeigt die Unterschiede 

zwischen einem klassisch-konservativen 

Netzwerk und einem SDN-Netzwerk. 

Regeln steuern Pakete 

Die OpenFlow-API arbeitet mit einfachen 

Primitives zur Behandlung von Netzwerkpaketen 

sowie zur Abfrage und Auswertung 

von Statistiken. Auf der Grundlage 

von Matching-Regeln zum Erkennen 

identischer Header-Informationen 

erlaubt OpenFlow das Zusammenfassen 

von Paketen zu sogenannten Flows. Diesen 

Flows kann eine Priorität sowie eine 

Aktion zugewiesen werden. Eine einfache 

OpenFlow-Regel könnte wie folgt 

ausschauen: 

match="dl_type=ip, nw_type=tcp,U 

tp_dst_port=80", action="output=2",U 

priority="10" 

Diese Regel besagt, dass alle IP-Pakete 

mit TCP-Zielport 80 an Port 2 weitergeleitet 

werden sollen. Treffen mehrere Regeln 

auf ein Paket zu, bestimmt die Priorität, 

welche vorrangig angewendet wird. 

In den einfachen Primitives des Open- 

Flow-Protokolls zeigt sich seine große 

Flexibilität. Gleichzeitig stellen sie eine 

Herausforderung dar. So ermöglicht 

OpenFlow zwar die Programmierung eines 

SDN-Netzwerks, macht sie jedoch 

nicht unbedingt einfach. 

Ein Netzwerk nur über OpenFlow-Primitives 

zu managen, wäre so, als würde 

man Software ausschließlich in Maschinencode 

entwickeln. 

Deshalb kommt dem SDN-Controller eine 

wichtige Bedeutung zu. Er übernimmt 

die zentrale Aufgabe der Kommunikation 

mit den OpenFlow-Switches und der Abstraktion 

von der OpenFlow-API. Statt 

mit komplizierten OpenFlow-Primitives 

lassen sich SDN-Netze damit durch höhere 

Befehle der Art „Installiere einen 

Datenpfad von A nach B“ oder „Verwerfe 

alle Pakete an Host X“ steuern. Der Controller 

löst eventuell auftretende Konflikte, 

übersetzt die Befehle in OpenFlow- 

Primitives und installiert diese dann auf 

die entsprechenden Switche. 

Auf Basis dieser Abstraktionen lassen 

sich dann die eigentlichen Netzwerk-Applikationen 

wie MAC-Learning, Spanning 

Tree oder Routing-Protokolle realisieren. 

Auch völlig neue Ideen wie Multipath 

Switching, BYOD-Anwendungen oder 

eine zentrale ACL-Konfiguration sind relativ 

schnell implementiert. Ausgeführt 

werden die Applikationen auf dem Controller 

wie in heutigen Betriebssystemen. 

Im SDN-Jargon spricht man daher auch 

von einem Netzwerkbetriebssystem. 

Noch stehen sowohl die Entwicklung 

von SDN-Controllern wie auch die Suche 

nach den richtigen OpenFlow-Abstraktionen 

am Anfang und sind Teil intensiver 

Forschungsaktivitäten. Kann man jedoch 

mit einigen Einschränkungen leben, so 

steht mit dem Floodlight-OpenFlow-SDN- 

Controller bereits eine vielversprechende 

Open-Source-Software zur Verfügung. 

Floodlight-OpenFlow- 

Controller 

Floodlight ist ein in Java geschriebener, 

hoch performanter Open-Source- 

OpenFlow-Conroller. Er wurde auf der 

Basis von Beacon, einem experimentellen 

OpenFlow-Controller der Universität 

Standford, entwickelt und wird heute von 

einer großen Entwickler-Community unterstützt. 

Mit BigSwitch Networks steht 

hinter Floodlight auch eine Firma, die 

kommerzielle Lösungen vorrangig für 

Rechenzentren anbietet. 

Derzeit implementiert Floodlight die 

OpenFlow-Version 1.0 und arbeitet mit 

allen Switches, Routern, virtuellen Switches 

und Accesspoints zusammen, die 

diese Version ebenfalls unterstützen. 

Floodlight ist unter der Apache-Lizenz 

veröffentlicht und stellt neben dem Kontroll-Framework 

zum Steuern der Netzwerkkomponenten 

mittels OpenFlow 

auch eine Reihe von Netzwerkapplikationen 

zur Verfügung. Das Bereitstellen 

dieser Applikationen ist der eigentliche 

Fokus von Floodlight. 

Floodlight-Architektur 

Floodlight bietet eine Reihe von Funktionen 

und Abstraktionen zum Steuern 

eines OpenFlow-Netzwerks. Dem dient 

eine modulare Architektur der Controller- 

Features sowie eine Reihe von eng an 

den Controller gebundenen Basis-Applikationen. 

Zum optimalen Ausnutzen der 

Ressourcen aktueller Multiprozessorsysteme 

greift Floodlight dabei auf Multithreading 

zurück und ist so in der Lage, 

mehrere Millionen neuer Flows pro Sekunde 

zu verarbeiten. 

Die Westbound-Java-API erlaubt die Entwicklung 

eigener Module in Java und 

die schnelle Anbindung an den Core- 

Controller. Diese werden beim Start des 

Floodlight-Controllers über ein eigenes 

Modulsystem automatisch unter Berück- 

Feature 

Feature 

Network 

Application 

Network 

Application 

Network 

Application 

Operating System 

Feature 

Feature 

Spezialisierte 

Packet Forwarding 

Hardware 

Feature 

Feature 

Network Operating System 





Hardware 

Feature 

Feature 



Hardware 




Hardware 

Abbildung 1: Der Unterschied zwischen einem klassisch-konservativen Netzwerk mit verteilten, heterogenen und vertikal integrierten Netzwerkkomponenten und 

einem SDN-Netzwerk mittels OpenFlow. 


Admin 


69

Netzwerk 

Floodlight 

sichtigung ihrer Abhängigkeiten geladen 

und stehen fortan zur Verfügung. So 

kann man den vollen Funktionsumfang 

des Controllers und der OpenFlow-API 

nutzen und zeitnah auf Ereignisse im 

Netz, wie beispielsweise das Auftauchen 

neuer Pakete oder eines neuen Flows, 

reagieren. Man spricht daher auch von 

reaktiven Applikationen. 

Die Northbound-REST-API erlaubt darüber 

hinaus das Anbinden externer Applikationen 

in einer beliebigen Sprache 

mittels JSON. Im Vergleich zur Java-API 

ist die REST-API jedoch relativ langsam. 

Ein Reagieren auf Events in Echtzeit ist 

damit nicht möglich. Stattdessen erlaubt 

sie neben dem Abfragen von Service- und 

Statusinformationen beispielsweise die 

A-priori-Installation von OpenFlow-Regeln 

durch externe Applikationen. Diese 

nennt man auch proaktive Applikationen. 

Eine der Standardanwendungen, die 

auf die REST-API setzt, ist das Floodlighteigene 

GUI. Darüber hinaus existieren ein 

in Python geschriebener Circuit Pusher, 

welcher automatisch dauerhafte Open- 

Flow-Regeln für die Verbindung zwischen 

zwei IP-Adressen installiert. 

Topologie eines OpenFlow-Netzwerks. 

Mittels eines Link-Discovery-Moduls erzeugt 

der Controller sowohl LLDP- als 

auch Broadcast-Pakete (sogenannte 

BDDPs) und sendet diese in regelmäßigen 

Abständen an alle benachbarten 

Switche. Unter der Annahme, dass alle 

Switche LLDP-Nachrichten konsumieren 

und Broadcast-Pakete weiterleiten, 

kann Floodlight aus empfangenen eigenen 

Nachrichten aktive Verbindungen 

erkennen und die Netzwerktopologie 

berechnen. 

Dabei unterscheidet Floodlight zwischen 

direkten Links und Broadcast-Links, wobei 

eine direkte Verbindung immer dann 

angenommen wird, wenn eigene LLDP- 

Pakete empfangen werden. In diesem Fall 

sind zwei OpenFlow-Switche unter der 

Kontrolle derselben Floodlight-Instanz 

direkt miteinander verbunden. 

Graphen zeigen Wege 

Basierend auf der Information des Link- 

Discovery-Mechanismus berechnet der 

Topology Service eine Topologie-Repräsentation 

in Form eines gerichteten Graphen. 

Der beinhaltet alle relevanten Information 

über die Konnektivität der Switche 

untereinander und kann von anderen 

Applikationen etwa für die Berechnung 

eines Spanning Trees genutzt werden. 

Darüber hinaus lassen sich jedoch durch 

einfache Anwendung der Graphentheorie 

auch weitere Funktionen realisieren. Die 

Berechnung multipler Pfade zwischen 

Start und Ziel oder die Optimierung nach 

multiplen Parametern stellen somit kein 

prinzipielles Problem mehr dar. 

Schleifenfreie Inseln 

Ein weiteres interessantes und wichtiges 

Konzept ist das Zusammenfassen 

von direkt miteinander verbundenen 

OpenFlow-Switches zu Gruppen – sogenannten 

OpenFlow-Inseln – die wiederum 

über Broadcast-Links mit anderen 

Inseln verbunden sein können. Unter gewissen 

Einschränkungen erlaubt Floodlight 

so die Kombination von OpenFlow- 

Weitere Floodlight Applikationen 

Die wichtigsten Floodlight- 

Module 

GUI 

(Javascript) 

Circuit 

Pusher 

(Python) 

OpenStack 

Quantum Plugin 

(Python) 

Network 

Application 

Network 

Application 

Network 

Application 

Link Discovery, Topology Service und 

OpenFlow Islands: In traditionellen 

Netzwerken übernehmen häufig Spanning-Tree- 

oder Routing-Protokolle die 

Aufgabe des Topologie-Managements, 

wie beispielsweise das Sicherstellen der 

Schleifenfreiheit. Durch die verteilten 

Algorithmen dieser Protokolle ergeben 

sich jedoch eine Reihe von Schwierigkeiten, 

wie eine komplexe Konfiguration, 

eine beschränkte Anzahl von Hops oder 

lange Konvergenzzeiten bei Änderungen 

der zugrunde liegenden Netzinfrastruktur. 

Das Ausnutzen mehrerer Pfade zwischen 

Start und Ziel eines Datenflusses 

ist sogar nur mit erheblichem Aufwand 

und der Verwendung weiterer Protokolle 

möglich. 

SDN-Controller dagegen verfügen über 

eine zentrale Sichtweise auf alle Netzwerkkomponenten 

und können das Topologie-Management 

dadurch erheblich 

vereinfachen. Floodlight implementiert 

hierzu einen ausgeklügelten Mechanismus 

zum automatischen Erkennen der 

Module Applications 

VNF 

R 

R 

Firewall 

Hub 

R 

Static 

Flow 

Entry 

Pusher 

R 

R 

Port 

Down 

Reconciliation 

Java API 

R 

Module 

Manager 

R 

Device 

Manager 

R 

Switches 

OpenFlow Switch 



Northbound REST API 

Thread 

Pool 

Packet 

Streamer 

OpenFlow Services 

R 

Controller 

Memory 

Floodlight Controller 

Topology 

Manager/ 

Routing 

Southbound OpenFlow v.1.0 API 

R 

Python 

Server 

R 

Link 

Discovery 

R 

Performance 

Monitor 

Web 

UI 

Flow 

Cache 

R 

Trace 

R 

Unit 

Te s t 

R 

Storage 

Memory 

NoSQL 

R 

Counter 

Store 

Abbildung 2 zeigt die grundsätzliche Architektur und die Relationen zwischen einzelnen in Java 

geschriebenen Modulen des Floodlight-Controllers sowie die RESTfull-Northbound-API zum Anbinden externer 

Applikationen. 


Netzwerk 

Floodlight 

Equipment mit Standard-Netzwerkkomponenten. 

Wichtig ist, dass aufgrund der 

Broadcast-Pakete, Schleifen in den Verbindungen 

mit Nicht-OpenFlow-Switches 

vermieden werden müssen. Daher darf 

jede OpenFlow-Insel nur exakt eine Verbindung 

zu Nicht-OpenFlow-Equipment 

aufweisen. Weiterhin dürfen OpenFlowund 

Nicht-OpenFlow-Inseln an sich keine 

Schleife bilden. Abbildung 4 zeigt eine 

mögliche und erlaubte Topologie mit 

OpenFlow und Nicht-OpenFlow-Equipment. 

Lernende Switche 

Forwarding and Learning Switch: Derzeit 

bietet Floodlight zwei Module zur automatischen 

Paketweiterleitung zwischen 

Endhosts. Das standardmäßig aktivierte, 

jedoch relativ einfach implementierte 

Forwarding-Modul dient hauptsächlich 

der exemplarischen Einführung in 

Floodlight und bietet einen guten Einstiegspunkt 

in Funktionsweise von Floodlight 

sowie OpenFlow im Allgemeinen. 

Es behandelt jedes Paket einzeln und ist 

daher in seiner Leistungsfähigkeit stark 

eingeschränkt. 

Das komplexere Learning-Switch-Modul 

implementiert ein ähnliches Verhalten, 

wie man es von einem Standard-Switch 

bereits kennt: Es erkennt und lernt neue 

Geräte anhand ihrer MAC-Adresse. 

Aufgrund der globalen Sichtweise von 

Floodlight bietet es jedoch darüber hinausgehende 

Funktionen. Erkennt Floodlight 

einen neuen Flow, identifiziert das 

Learning-Switch-Modul anhand der vorliegenden 

Topologie-Information des Topology 

Services den Eingangs- und den 

Ausgangsswitch sowie alle weiteren Switche 

auf dem kürzesten Pfad zwischen 

Start und Ziel. Ist ein Pfad gefunden, 

installiert das Modul die entsprechenden 

OpenFlow-Regeln zur Behandlung des 

neues Flows auf alle beteiligten Switche. 

Anschließend können alle weiteren Pakete 

zu ihrem Ziel finden. 

Im Vergleich zum einfachen Forwarding- 

Modul ist die Leistungsfähigkeit um ein 

Vielfaches höher, da die Paketweiterlei- 

tung nach der Installation der OpenFlow- 

Regeln ausschließlich im Forwarding- 

Pfad der Switche bewerkstelligt wird und 

eine Interaktion mit dem Controller nicht 

für jede Nachricht zwingend notwendig 

ist. 

Koexistenz mit Standard- 

Equipment 

Eine Einschränkungen für beide Module 

ergibt sich, wenn im Netzwerk Open- 

Flow- und Standard-Equipment koexistiert. 

In diesem Fall identifiziert der Algorithmus 

alle OpenFlow-Inseln und leitet 

Pakete nur innerhalb der Insel direkt zum 

Ziel. Ist das Ziel unbekannt oder befindet 

es sich auf einer anderen Insel, werden 

die Pakete geflutet. 

Schon an diesen Modulen lassen sich 

die Vorteile von SDN, OpenFlow und 

Floodlight klar erkennen. Bereits relativ 

einfache Implementierungen bieten 

gegenüber konservativen Netzwerken 

erhebliche Vorteile. Innerhalb einer 

OpenFlow-Domäne wird selbst bei großen 

vermaschten Netzen ein kompliziert 

konfiguriertes Spanning-Tree-Protokoll 

überflüssig. Der SDN-Controller übernimmt 

diese Aufgaben. So lassen sich 

zentral Datenfluss-Optimierungen oder 

ein Traffic Engineering zur Lastverteilung 

durchführen. Ebenso können innerhalb 

einer OpenFlow-Insel ohne großen Aufwand 

Multipath-Verbindungen realisiert 

werden. Im Fall von Link-Ausfällen kann 

der Controller unmittelbar und intelligent 

auf Änderungen der Topologie reagieren 

und beispielsweise bestehende Datenflüsse 

umleiten. Im besten Fall erfolgt 

diese Änderung transparent und ohne 

große Verzögerung. Lange Konvergenzzeiten 

gehören der Vergangenheit an. 

Teile und herrsche 

Abbildung 3: Das Floodlight-GUI stellt alle wichtigen Informationen bezüglich des OpenFlow-Netzwerks dar. 

So erfährt man den Status der Switche sowie der verbundenen Endgeräte. Auch die automatisch erkannte 

Netzwerktopologie lässt sich graphisch darstellen. 

Load Balancer: Ein weiteres Beispiel für 

die Anwendung der fortgeschrittenen 

Paketweiterleitungs- und Manipulationsmöglichkeiten 

von OpenFlow ist eine netzinterne 

Lastverteilung auf verschiedene 

Server. Traditionelle Server-Load-Balancer 

sind typischerweise einzelne Systeme, die 

einer Serverlandschaft vorgeschaltet sind 

und die Last in Abhängigkeit des Dienstes 

auf die zur Verfügung stehenden Anwendungen 

verteilen. Neben der oftmals 


Netzwerk 

Floodlight 

komplexen Konfiguration inklusive einer 

Analyse der zu verteilenden Datenströme 

besteht ein wesentlicher Nachteil dieses 

Ansatzes darin, dass der klassische Load 

Balancer einen schwer zu vermeidenden 

Engpass im Netzwerk darstellt. 

In einem SDN lässt sich dieses Bottleneck 

dagegen leicht vermeiden. Durch 

die umfangreichen Kontrollmöglichkeiten 

von Datenflüssen kann in einem SDN 

das gesamte Netzwerk, also jeder einzeln 

Switch, Router und Netzwerkpfad, 

als Load Balancer fungieren und Datenströme 

auf verteilten Pfaden direkt an 

unterschiedliche Server weiterleiten. Eine 

Überlastung einer einzelnen Netzwerk- 

Appliance wird hierdurch vermieden. 

Stattdessen wird aus dem Server-Load- 

Balancing jetzt ein Dienst des Netzwerks. 

Load Balancing als Dienst 

Auch hierfür bietet Floodlight bereits 

eine rudimentäre Lösung. Die Floodlight- 

Load- Balancer-Applikation ist eine einfache 

Anwendung zur Verteilung von 

UDP-, TCP- oder ICMP-Flows auf verschiedene 

Server. Dabei übernimmt nicht 

eine eigenständige Netzwerkkomponente 

die Aufgabe der Lastverteilung, sondern 

das gesamte Netzwerk. De facto ist jeder 

Switch des Netzes daran beteiligt. 

Steuern lässt sich der Floodlight-Load- 

Balancer über eine REST-API, welche an 

die OpenStack-Quantum-Load-Balanceras-a-Service-API 

(LBaaS) angelehnt ist. 

So lassen sich virtuelle IP-Adressen für 

den Load Balancer erstellen und an diese 

Adressen gerichtete Flows automatisch 

an reale Server im Netz umleiten. Einmal 

konfiguriert, übernehmen die OpenFlow- 

Switche automatisch einen Großteil der 

Arbeit. 

Wie viele andere Floodlight-Applikationen 

befindet sich der Load Balancer 

derzeit noch in der Entwicklung und bietet 

bisher nur eine Basis-Funktionalität. 

So findet die Verteilung der Flows nach 

einem Round-Robin-Verfahren statt und 

berücksichtigt weder die Last des Servers 

noch etwa das tatsächliche Datenaufkommen. 

Dennoch lässt sich bereits 

mit den vorhandenen Komponenten ein 

einfacher, aber leistungsfähiger Server- 

Load-Balancer realisieren. Durch die 

Open-Source-Quellen lässt sich die bestehende 

Software auch einfach den eigenen 

Bedürfnissen anpassen. 

Mehr Sicherheit 

Stateless Firewall: Auch im Bereich Sicherheit 

lassen sich mit SDN und Open- 

Flow neue Wege beschreiten und traditionelle 

Verfahren vereinfachen. Die kongruente 

Installation von Access Control 

Lists (ACLs) auf einer Vielzahl Switche 

eines Netzes etwa erweist sich bis heute 

als aufwendiges Unterfangen. Selbst in 

professionellen Systemen ergeben sich 

immer wieder Diskrepanzen zwischen 

Anforderung, Dokumentation und der 

eigentlichen Konfiguration. Wünschenswert 

ist ein System, das ACLs automatisch 

auf allen Netzwerkkomponenten 

durchsetzt. Auch hier bietet Floodlight 

eine elegante und standardisierte Lösung 

für das Problem. 

Die Floodlight-Stateless-Firewall-Applikation 

ist ein reaktives Floodlight-Modul, 

das netzwerkweite ACL-Konfigurationen 

für alle OpenFlow-Switche zentral vorhält. 

Die Firewall-Regeln (ALLOW oder 

DENY) lassen sich für beliebige Open- 

Flow-Matches relativ komfortabel durch 

eine REST-API konfigurieren und nach 

Prioritäten sortieren. 

Jedes Packet-In-Ereignis, das durch das 

erste Paket eines neuen Flows erzeugt 

wird, wird anschließend mit der Menge 

der existierenden Firewall-Regeln verglichen, 

bis entweder die Menge leer 

ist oder eine passende Regel gefunden 

wurde. Im zweiten Fall bestimmt die 

höchstpriorisierte Regel, ob das Paket 

weitergeleitet oder der Flow blockiert 

wird. Wird keine Regel gefunden oder 

besagt die Regel, dass der Flow erlaubt 

ist, passiert das Packet-In-Ereignis die 

Firewall und wird von nachfolgenden 

Floodlight-Modulen, wie beispielsweise 

dem bereits erwähnten Learning-Switch- 

Modul, regulär verarbeitet und weitergeleitet. 

Findet sich dagegen eine Regel, die 

den Flow blockiert, installiert die Firewall 

eine OpenFlow-Regel auf dem OpenFlow- 

Eingangsswitch zum Verwerfen aller weiteren 

Pakete desselben Flows. 

Die Floodlight-Firewall erlaubt somit zentral 

konfigurierte, netzwerkweite ACL-Regeln, 

die automatisch auf alle (oder ausgewählte) 

Switche durchgesetzt werden. 

Das folgende, einfache Beispiel verdeutlicht 

die Konfigurationsmöglichkeiten. 

Die Regeln erlauben Verbindungen in das 

Subnetz 192.168.1.0/24 ausschließlich 

zu TCP-Port 80. 

Protokoll | Ziel-IP | Ziel-Port | Action | 

Priorität 

----------+---------+------------+-------+ 

--------- 

TCP | 192.168.1.0/24 | 80 | ALLOW | 1 TCP | 

192.168.1.0/24 | * | DENY | 2 

Tutorial: Erste Schritte 

Als Java-Anwendung läuft Floodlight in 

einer Java-VM und steht somit auf praktisch 

allen Betriebssystemen zur Verfügung. 

Für viele gängige Linux-Distributionen 

wie beispielsweise Ubuntu ist oftmals 

sogar ein Release in den Repositories 

vorhanden. Darüber hinaus steht auf der 

Projekt-Homepage ein vorkonfiguriertes 

Virtual Machine Image zum Download 

bereit. Durch die rapide Weiterentwicklung 

von Floodlight empfiehlt es sich 

jedoch, die neueste Version von GitHub 

oder Nightly Builds zu installieren. Diese 

erwiesen sich in der Vergangenheit als 

äußerst stabil und beheben bereits eine 

Reihe von Bugs der alten Releases. 

OpenFlow Island 1 Non-OpenFlow Island 

OpenFlow Island 2 

Abbildung 4: Beispiel einer in Floodlight erlaubten Topologie mit OpenFlow- und Standard-Equipment. Zu 

Nicht-OpenFlow-Inseln dürfen OpenFlow-Inseln jedoch nur exakt eine Verbindung aufweisen. 


Floodlight 

Netzwerk 

Am einfachsten lässt sich Floodlight unter 

Linux (etwa Ubuntu) installieren. Hierzu 

sollte neben einer Java-Umgebung ein 

Git-Client, Python und Apache Ant vorhanden 

sein. Um Floodlight unter Linux 

von GitHub zu laden und zu übersetzen, 

genügen die folgenden Befehle: 

$ git clone git://github.com/floodlightU 

/floodlight.git 

$ cd floodlight 

$ git checkout stable 

$ ant 

Konfigurieren lässt sich Floodlight über 

Java-Properties-Dateien. Unter »./src/ 

main/resources/floodlightdefault.properties« 

finden sich die Standardeinstellungen 

wie Port-Einstellungen und die 

Applikationsmodule, welche automatisch 

geladen werden. Vor einem ersten Test 

empfiehlt es sich, das einfache »net.flood- 

lightcontroller.forwarding.Forwarding«- 

Modul durch das performantere »net. 

floodlightcontroller.learningswitch. 

LearningSwitch«-Modul zu ersetzen. Anschließend 

lässt sich Floodlight mit 

$ java ‐jar target/floodlight.jar 

starten und es erwartet fortan die Verbindung 

von OpenFlow-Switches. 

Steht gerade keine OpenFlow-fähige 

Hardware zur Verfügung, lässt sich mit 

der freien Software MiniNet ein Open- 

Flow-Netzwerk simulieren. Hier empfiehlt 

sich ebenfalls die Installation von 

GitHub: 

$ git clone git://github.com/mininet/mininet 

$ mininet/util/install.sh ‐a 

Die Prozedur dauert circa fünf Minuten 

und installiert alle MiniNet-Komponenten 

inklusive des OpenFlow-Software- 

Switches »Open vSwitch«, einem Wireshark-Dissector 

zum Analysieren von 

OpenFlow-Nachrichten mit Wireshark 

und POX, einem in Python geschriebenen 

weiteren OpenFlow-Controller. 

Zum Starten von MiniNet mit einer minimalen 

Topologie, die zwei Hosts über 

einen OpenFlow-Switch verknüpft und 

eine Verbindung zu einem externen 

Floodlight-Controller aufnimmt, genügt: 

$ sudo mn ‐‐topo=minimal ‐‐controller=U 

remote‐‐ip= ‐‐port=U 

 

Sogleich verbindet sich MiniNet mit 

Floodlight und schon hat man ein kleines 

Software Defined Network zum Ausprobieren 

und Testen. 

Für weitere Hilfe oder Informationen zu 

Floodlight empfiehlt sich ein Blick auf die 

(englischsprachige) Homepage des Projekts 

[1]. Darüber hinaus steht über die 

Mailingliste eine große Entwickler-Community 

jederzeit hilfsbereit zur Seite. 

Fazit 

Der Floodlight-OpenFlow-SDN-Controller 

bietet bereits eine beeindruckende Leistung 

und eine Menge an Applikationen. 

Darüber hinaus entstehen in der Open- 

Source-Community weitere interessante 

Lösungen beispielsweise für effizientes 

Handover in drahtlosen Netzen, Multipath- 

und In-Network-Load-Balancing, 

Application Aware Traffic Engineering 

oder BYOD. Dabei ermöglicht Software 

Defined Networking eine schnelle, hardwareübergreifende 

und vor allem kostengünstige 

Möglichkeit auch für eigene 

Implementierungen 

von Netzwerk-Management-Lösungen. 

Das Floodlight-Projekt 

zeigt eindrucksvoll, 

welches Potenzial 

Software Defined Networking 

hat. 

Zum Einsatz von 

Floodlight in einer produktiven 

Umgebung 

fehlen jedoch noch 

einige entscheidende 

Punkte. So bietet 

Floodlight bisher nur 

ein sehr eingeschränktes 

Konfigurationsmanagement. 

Praktisch 

alle Konfigurationsinformationen 

werden 

ausschließlich im Speicher 

vorgehalten und 

sind bei einem Neustart 

des Controllers 

verloren. Ebenso fehlt 

bisher ein Hochverfügbarkeitsmechanismus. 

Fällt der Controller aus, 

liegt vor allem bei der 

Verwendung reaktiver 

Applikationen schnell 

das gesamte Netzwerk 

lahm. Auch die bisher 

verfügbaren Applikationen stecken zum 

Teil noch in den Kinderschuhen und erlauben 

mitunter nur eine eingeschränkte 

Funktionalität. 

Dennoch eignet sich Floodlight hervorragend, 

um mit Software Defined Networking 

in Kontakt zu treten und kostengünstig 

erste Erfahrungen zu sammeln. In 

Kombination mit der ebenfalls kostenlos 

erhältlichen MiniNet-Software und Open 

vSwitch bedarf es nicht einmal realer 

Hardware, um erste Versuche zu unternehmen 

und eigenes Know-how aufzubauen. 

Noch stehen SDN und OpenFlow 

– und somit auch OpenFlow-Controller 

wie Floodlight – am Anfang. Dennoch 

lässt sich absehen, dass sie die Zukunft 

von Kommunikationsnetzen weitreichend 

verändern werden. (jcb) 

n 

Infos 

[1] OpenFlow-Projekt: [http:// www. 

projectfloodlight. org] 


Admin 


75


VHDX-Disks 

Umgang mit VHDX-Dateien 

Moderne Bilder 

© Alina Pavlova, 123RF 

Gegenüber dem alten Format für virtuelle Festplatten bringen VHDX- 

Dateien einige Verbesserungen mit. Dieser Artikel gibt einen Überblick 

über die interessanten Features. Thomas Joos 

Neben dem Vorteil der größeren Kapazität 

sind VHDX-Dateien auch wesentlich 

unempfindlicher beim Ausfall eines Servers 

oder einem Hardreset. VHD-Dateien 

können bei Problemen des Host-Systems 

sehr schnell zerstört werden. Das passiert 

mit VHDX-Dateien so gut wie nicht mehr. 

Setzen Sie Windows Server 2012 als 

iSCSI-Target ein, erstellen Sie als iSCSI- 

Ziel VHD-Dateien. Windows Server 2012 

kennt zwar bereits VHDX-Dateien, kann 

diese aber nur mit Hyper-V einsetzen, 

nicht als iSCSI-Target. 

Jetzt auch für iSCSI 

Der neue Windows Server 2012 R2 dagegen 

kann VHDX-Festplatten auch als 

iSCSI-Target verwenden. Die erstellten 

VHDX-Festplatten lassen sich ab Windows 

Server 2012 R2 und System Center 

2012 R2 auch direkt in den System-Center-Produkten 

verwalten. Außerdem gibt 

es in Windows Server 2012 R2 die Möglichkeit, 

die Festplatten mehreren virtuellen 

Servern zuzuweisen. Die Shared- 

VHDX-Technologie bietet daher vor allem 

Vorteile beim Betrieb mit Hyper-V 2012 

R2. Ebenfalls neu in Windows Server 

2012 R2 ist die Option, die Größe virtueller 

Festplatten im laufenden Betrieb zu 

ändern. In Windows Server 2012 müssen 

Sie die angebundenen virtuellen Server 

dazu herunterfahren. Außerdem können 

Sie in Windows Server 2012 R2 virtuelle 

Server jetzt im laufenden Betrieb exportieren 

und kopieren. 

VHDX-Dateien nutzen 

Die Steuerung von virtuellen Festplatten 

außerhalb von Hyper-V finden Sie in der 

Festplattenverwaltung über das Menü 

»Aktion«. Klicken Sie auf den Menüpunkt 

»Virtuelle Festplatte erstellen«, um den 

Assistenten zu starten. Im Assistenten 

legen Sie fest, wo Sie die VHDX-Datei der 

Festplatte speichern wollen und wie groß 

die Festplatte sein soll. An dieser Stelle 

bestimmen Sie auch, ob die Festplatte 

anwachsen darf oder ob Sie eine feste 

Größe verwenden wollen. 

Wählen Sie den Befehl »Virtuelle Festplatte 

anfügen«, können Sie bereits bestehende 

Datenträger an den Computer 

anbinden (Abbildung 1). Das funktioniert 

auch, wenn Sie auf eine VHD(X)-Datei 

doppelklicken. Nachdem Sie die virtuelle 

Festplatte erstellt haben, zeigt Windows 

sie in der Datenträgerverwaltung 

an und Sie können sie wie jede andere 

verwalten. 

Haben Sie noch VHD-Dateien im Einsatz, 

können Sie diese in VHDX-Dateien umwandeln. 

Das geht zum Beispiel mit dem 

Hyper-V-Manager oder dem Commandlet 

»convert‐VHD«. Im Hyper-V-Manager rufen 

Sie mit dem Link »Datenträger bearbeiten« 

den entsprechenden Assistenten 

auf. Laden Sie die VHD-Datei und starten 

Sie im Assistenten die Konvertierung, indem 

Sie die Aktion »Konvertieren« auswählen. 

Konvertieren 

Im Rahmen der Umwandlung wählen Sie 

das Datenträgerformat aus und können 

auch zwischen dem Typ der Festplatten, 

also fester Größe oder dynamisch 

erweiterbar, wechseln. Das Commandlet 

»convert‐vhd« steht auch zur Verfügung, 

wenn Sie Hyper-V in Windows 8 installiert 

haben, also nicht nur in den Server- 

Betriebssystemen. 

Ein Vorteil des Commandlets ist die Fähigkeit, 

nicht nur VHD-Dateien in VHDX- 

Dateien umwandeln zu können, sondern 

auch den umgekehrten Weg zu gehen. 

Das heißt, Sie können von den Vorteilen 

des neuen Formats profitieren, aber im 

Notfall auch wieder zurückkonvertieren, 

wenn etwa eine virtuelle Festplatte später 

an ein anderes System gehängt werden 

muss. Die Syntax ist sehr einfach: 

Convert‐VHD ‐Path Pfad zur VHD(X)‐Datei U 

‐DestinationPath Pfad zur Zieldatei 


VHDX-Disks 


Außerdem ist es möglich, den Typ der 

Festplatte zu ändern, zum Beispiel mit: 

Convert‐VHD ‐Path Pfad der VHD/VHDX‐DateiU 

‐DestinationPath Zielpfad und Datei ‐VHDTypeU 

Differencing ‐ParentPath Übergeordnete 

Festplatte 

Ein weiteres Beispiel ist: »Convert‐VHD 

‐Path hd1.vhd ‐DestinationPath hd1.vhdx 

‐VHDType Dynamic«. Alle Optionen des 

Commandlets finden Sie auf der Seite 

[2]. Neben der Möglichkeit das Format 

von Festplatten in der PowerShell 

umzuwandeln, können Sie auch 

die Größe von Festplatten in der 

PowerShell anpassen. Dabei hilft 

das Commandlet »Resize‐VHD«, 

zum Beispiel: 

Resize‐VHD ‐Path c:\vm\owa.vhdx U 

‐SizeBytes 1TB 

Neben diesen Spezialaufgaben 

können Sie auch einfach mit 

»New‐VHD« neue Festplatten erstellen 

und mit »Get‐VHD« Informationen 

zu den Festplatten anzeigen. 

Virtuelle Festplatten lassen sich in 

der PowerShell auch direkt mit virtuellen 

Servern verbinden: 

Add‐VMHardDiskDrive ‐VMName VM ‐PathU 

VHDX‐Datei 

Natürlich können Sie virtuelle Festplatten 

auch am Host-System anbinden, 

zum Beispiel um Daten da- 

rauf zu kopieren, und diese erst dann im 

virtuellen Server einbinden: »mount‐vhd 

VHD‐Datei«. Mit dem Commandlet 

»unmount‐vhd« trennen Sie die virtuelle 

Platte wieder vom System. 

Microsoft unterstützt Administratoren 

mit dem kostenlosen Microsoft Virtual 

Machine Converter [1], um virtuelle Server 

von VMware vSphere zu Hyper-V zu 

migrieren. Die aktuelle Version wurde 

von Microsoft bereits für Windows Server 

2012 und Hyper-V Server 2012 optimiert, 

Abbildung 1: Virtuelle VHDX-Festplatten können Sie auch ohne 

Hyper-V direkt im Betriebssystem als Datenspeicher einbinden. 

unterstützt aber noch nicht das neue 

Festplattenformat VHDX von Windows 

Server 2012. Sie können aber im Hyper- 

V-Manager oder mit »convert‐vhd« die erstellte 

VHD-Datei in eine VHDX-Festplatte 

umwandeln. SCVMM 2012 kann mit dem 

SP1 VHDX-Festplatten von Hyper-V 3.0 

und auch VHD-Dateien in das VHDX- 

Format konvertieren. 

Zu Servern hinzufügen 

Um einem Server eine neue virtuelle 

Festplatte auf Basis einer 

VHDX-Datei hinzuzufügen, gibt 

es verschiedene Möglichkeiten. 

Im laufenden Betrieb lassen sich 

virtuelle Festplatten nur an virtuelle 

SCSI-Controller anbinden. Um 

einen virtuellen SCSI-Controller 

einzubauen, müssen Sie aber den 

virtuellen Server herunterfahren. 

Neue Festplatten fügen Sie im 

Schnelldurchlauf so hinzu: Klicken 

Sie mit der rechten Maustaste auf 

den virtuellen Server und dann auf 

»Einstellungen«. Wählen Sie den 

Controller aus, mit dem die neue 

virtuelle Festplatte verbunden werden 

soll. Klicken Sie auf »Festplatte« 

und dann auf »Hinzufügen«. Aktivieren 

Sie die Option »Virtuelle 

Festplatte« und klicken Sie auf 

»Neu«, um den Assistenten für eine 

neue Festplatte zu starten. E 


Admin 


77


VHDX-Disks 

Abbildung 2: Virtuelle Festplatten können Sie in Hyper-V optimieren. 

Bestätigen Sie die Startseite des Assistenten 

und wählen Sie das Format für 

die neue Festplatte aus, also VHD (bis 

2 TByte) oder VHDX (bis 64 TByte). 

Bestimmen Sie als Nächstes, ob die Festplatte 

eine feste Größe hat, dynamisch 

erweiterbar sein oder auf einer vorhandenen 

Festplatte aufbauen soll (»Differenzierung«). 

Im Anschluss legen Sie den Pfad und 

den Namen fest, unter dem Windows 

Server 2012 die VHDX-Datei speichern 

soll. Auf der nächsten Seite bestimmen 

Sie die Größe der virtuellen Festplatte 

und können auch den Inhalt einer physischen 

Festplatte in die virtuelle Festplatte 

kopieren lassen. Danach erhalten 

Sie noch eine Zusammenfassung und 

erstellen mit »Fertigstellen« schließlich 

die virtuelle Festplatte. Klicken Sie danach 

im Fenster auf »Anwenden«, damit 

die virtuelle Festplatte in den virtuellen 

Server integriert wird. 

Speicher-Migration 

In Windows Server 2012 haben Sie auch 

die Möglichkeit, virtuelle Festplatten auf 

Hyper-V-Hosts zu verschieben – sogar im 

laufenden Betrieb. Klicken Sie dazu mit 

der rechten Maustaste auf den virtuellen 

Server, dessen Festplatten Sie umlagern 

wollen, und wählen Sie den Punkt »Verschieben« 

aus. 

Im Assistenten wählen Sie anschließend 

»Speicher des virtuellen Computers 

verschieben« aus. Auf der folgenden 

Seite bestimmen Sie, ob Sie die Daten 

des virtuellen Servers oder nur die virtuellen 

Festplatten verschieben wollen. 

Dann wählen Sie den entsprechenden 

Ordner aus, in dem Hyper-V die Daten 

des Computers speichern soll. Während 

des Vorgangs läuft der virtuelle Server 

weiter. Sie sehen den Status im Hyper-V- 

Manager. Wollen Sie Daten in verschiedenen 

Ordnern speichern, können Sie die 

entsprechende Option auswählen und im 

nächsten Fenster getrennte Speicherorte 

für Konfigurationsdateien, virtuelle Festplatten 

und Snapshots festlegen. 

Sie können daneben auch Smart-Paging- 

Dateien getrennt speichern. Smart Paging 

soll verhindern, dass sich virtuelle Server 

nicht mehr starten lassen, weil der gesamte 

verfügbare Arbeitsspeicher bereits 

zugewiesen ist. Diese neue Funktion erlaubt 

es virtuellen Servern, beim Neustart 

Teile der Festplatte des Hosts als Arbeitsspeicher 

zu nutzen. Auch diesen Bereich 

können Sie daher getrennt verschieben. 

Nach dem erfolgreichen Start wird der 

Festplattenplatz wieder freigegeben und 

der virtuelle Server erhält durch Dynamic 

Memory wieder seinen Speicher. 

Optimieren 

Im »Aktionen«-Bereich des Hyper-V-Managers 

finden Sie rechts die beiden Menüpunkte 

»Datenträger bearbeiten« und 

»Datenträger überprüfen«. Mit Letzterem 

starten Sie das Scannen einer beliebigen 

virtuellen Festplatte. Anschließend öffnet 

sich ein neues Fenster mit den Daten der 

Festplatte. So erfahren Sie, ob es sich um 

eine dynamisch erweiterbare oder eine 

Festplatte mit fester Größe handelt. 

Auch die maximale Größe sowie die aktuelle 

Datenmenge zeigt das Fenster an. 

Über »Datenträger bearbeiten« stehen Ihnen 

verschiedene Möglichkeiten offen) 

(Abbildung 2): 

n »Komprimieren« steht nur bei dynamisch 

erweiterbaren Festplatten zur 

Verfügung. Der Vorgang löscht leere 

Bereiche in der VHD(X)-Datei, sodass 

diese deutlich kleiner wird. Allerdings 

ist das nur für den Fall sinnvoll, wenn 

zuvor viele Daten von der Festplatte 

gelöscht wurden. 

n Mit »Konvertieren« wandeln Sie dynamisch 

erweiterbare Festplatten in 

Festplatten mit fester Größe um und 

umgekehrt. 

n »Erweitern« hilft dabei, den maximal 

verfügbaren Festplattenplatz einer 

VHD(X)-Datei zu vergrößern. 

n »Zusammenführen« wird nur dann 

angezeigt, wenn Sie eine differenzierende 

Festplatte auswählen, zum 

Beispiel die AVHD(X)-Datei eines 

Snapshots. Da diese Datei nur die aktuellen 

Unterschiede zu der VHD(X)- 

Quelldatei enthält, lassen sich die Daten 

zu einer gemeinsamen VHD(X)- 

Datei zusammenführen, die alle Daten 

enthält. Die beiden Quellfestplatten 

bleiben bei diesem Vorgang erhalten, 

der Assistent erstellt eine neue virtuelle 

Festplatte. 

n »Verbindung wiederherstellen« – für 

eine differenzierende Festplatte ist es 

zunächst einmal notwendig, dass die 

Quelldatei der verifizierten VHD(X)- 

Datei gefunden wird. Eine differenzierende 

Festplatte kann aber auch in 

einer Kette auf eine andere differenzierende 

Datei verweisen, die dann 

wiederum auf die VHD(X)-Datei verweist. 

Das kommt zum Beispiel dann 

vor, wenn mehrere Snapshots aufeinander 

aufbauen. Ist die Kette zerstört, 

zum Beispiel weil sich der Pfad einer 

Festplatte geändert hat, lässt sich mit 

dieser Option die Verbindung wiederherstellen. 

(ofr) 

n 

Infos 

[1] Microsoft Converter: 

[http:// www. microsoft. com/ en‐us/ 

download/ details. aspx? id=34591] 

[2] Commandlet-Optionen: 

[http:// technet. microsoft. com/ en‐us/ 

library/ hh848454. asp] 

Der Autor 

Thomas Joos ist freiberuflicher IT-Consultant 

und seit über 20 Jahren in der IT tätig. 

Neben seinen Projekten schreibt er praxisnahe 

Fachbücher und Fachartikel rund um 

Windows und andere Microsoft-Themen. Online 

trifft man Thomas Joos häufig unter 

[http:// thomasjoos. spaces. live. com]. 



Udev 

© Luciano De Polo, 123RF 

Udev mit virtuellen Maschinen 

Technisches K.O. 

Für viele Cloud-Admins steht das Udev-System des Kernels und die zugehörigen Regeln für eine endlose Neunummerierung 

der Netzwerkschnittstellen und manuelle Anpassungen. Dass man auch ohne wildes Löschen von 

Systemdateien obenauf bleiben kann, zeigt dieser Artikel. Martin Braun 

Das folgende Problem ist sicherlich jedem 

Administrator schon begegnet, der 

einmal ein virtuelles Suse-System geklont 

hat: Die frisch geklonte VM hängt beim 

Booten und wartet auf die Standard- 

Devices (Abbildung 1). Am Ende des 

verlängerten Bootvorgangs ist aus dem 

konfigurierten Netzwerk-Interface (NIC) 

»eth0« des Originals ein NIC mit Namen 

»eth1« geworden und die Nummern weiterer 

NICs wurden ebenfalls um eins erhöht. 

Ähnliches passiert bei nahezu allen 

anderen Linux-Distributionen und ist unabhängig 

vom eingesetzten Hypervisor. 

Damit verliert der Klon seine Netzwerk- 

Konfiguration, und man muss manuell 

über die Konsole nacharbeiten. 

Den schwarzen Peter bekommt dabei 

schnell Udev zugeschoben. Der Udev- 

Geräteverwalter meint es dabei aber nur 

gut: Udev lädt während der Hardware- 

Erkennung des Kernels alle Module 

Listing 1: »80‐net‐name‐slot.rules« 

01 ACTION=="remove", GOTO="net_name_slot_end" 

02 SUBSYSTEM!="net", GOTO="net_name_slot_end" 

03 NAME!="", GOTO="net_name_slot_end" 

04 

asynchron in unbestimmter Reihenfolge. 

Diese hängt von verschiedenen Bedingungen 

ab: der PCI-Bus-Topologie, den 

Gerätetreibern und der Art, wie diese 

nach ihrer Hardware suchen. Dabei kann 

es zu ständig wechselnden Gerätenamen 

kommen. Wenn nun zum Beispiel »eth0« 

und »eth1« vertauscht werden, kann das 

je nach System gravierende Auswirkungen 

haben: von Sicherheitsproblemen bis 

zum Ausfall zentraler Serverdienste. 

Dauerhaft eingerichtet 

Damit ergibt sich die Forderung nach persistenten 

Gerätenamen. Einmal eingerichtete 

Netzwerkkarten sollen ihre Konfiguration 

dauerhaft beibehalten, unabhängig 

davon, ob man weitere Karten hinzufügt 

oder wegnimmt. Viele Distributionen lösen 

diese Anforderung über Udev durch 

die sogenannten Persistent-Net-Regeln. 

05 NAME=="", ENV{ID_NET_NAME_ONBOARD}!="", PROGRAM="/usr/bin/name_dev.py $env{ID_NET_NAME_ONBOARD}", 

NAME="%c" 

06 NAME=="", ENV{ID_NET_NAME_SLOT}!="", PROGRAM="/usr/bin/name_dev.py $env{ID_NET_NAME_SLOT}", NAME="%c" 

07 NAME=="", ENV{ID_NET_NAME_PATH}!="", PROGRAM="/usr/bin/name_dev.py $env{ID_NET_NAME_PATH}", NAME="%c" 

08 

09 LABEL="net_name_slot_end" 

Sie finden sich im Verzeichnis »/etc/ 

udev/rules.d« und sorgen für eine gleichbleibende 

Benennung der Geräte durch 

eine Zuteilung der Namen aufgrund der 

MAC-Adresse eines Gerätes. 

Problem: Virtualisierung 

Diese Lösung bereitet in der Cloud Probleme, 

da eine einzelne Linux-VM in der 

Regel sehr oft geklont wird. Jeder neue 

Klon erhält neue virtuelle Hardware und 

VMware, Libvirt oder auch der Administrator 

generieren für die virtuellen 

Netzwerkkarten neue MAC-Adressen, 

um doppelte MAC-Adressen im Netzwerk 

zu vermeiden. Die neuen Schnittstellen 

erhalten neue Namen mit aufsteigender 

Nummerierung, da die ursprünglichen 

Namen schon für andere MAC-Adressen 

reserviert sind. Damit zeigt sich ein großer 

Nachteil dieses Konzeptes: ein installiertes 

und konfiguriertes Linux kann 

nicht mehr auf einer anderen (virtuellen) 

Hardware ausgeführt werden, denn es 

ändert sich dann auch dessen Konfiguration. 

Der Systemverwalter muss manuell 

das geklonte System einrichten. 

Die oft vorgeschlagene und einfache Lösung, 

die Datei »70‐persistent‐net.rules« 

vor dem Klonen einfach zu löschen, ist 

leider nicht sehr nachhaltig: Bei vielen 

Distributionen wird beim nächsten Klon 


Udev 


Abbildung 1: Ein geklonter SLES wartet beim Booten auf die Devices. 

Seit der Version v197 von Systemd gibt 

es weitere radikale Änderungen, um mit 

sogenannten vorhersagbaren Netzwerk- 

Interface-Namen [3] der Probleme Herr 

zu werden. Ähnlich wie durch »biosdevdiese 

Regeldatei durch eine Persistent- 

Net-Generator-Regel neu erzeugt. Auch 

eigene Änderungen in diesen Regeln im 

Verzeichnis »/lib/udev« sind ungünstig 

– bei einem Update des Udev-Pakets werden 

sie überschrieben. Tabelle 1 zeigt die 

Namen und Speicherorte der Regeln bei 

unterschiedlichen Distributionen. 

Bei der Arbeit mit Udev-Regeln ist zu 

beachten, dass es zu einem Wettlauf 

zwischen Kernel und den Udev-Rules 

kommen kann, wenn beide Namen der 

Form »eth*« vergeben wollen: Wer benennt 

zuerst das Netzwerk-Interface, der 

Kernel oder der Userspace? Daher wird 

auch empfohlen, für eigene Udev-Regeln 

den NICs andere Namen als »eth*« 

zu vergeben, wie zum Beispiel »net0« 

oder »wan1«. Wie so oft in der Open- 

Source-Welt werden Alternativen zu den 

Persistent-Net-Rules von verschiedenen 

Parteien auf unterschiedliche Weise entwickelt, 

auf die der Artikel im Folgenden 

näher eingeht. 

Lösungsansatz von Dell 

Dell beschreibt in einem Whitepaper [1] 

ein eigens entwickeltes Software-Paket 

namens »biosdevname«. Dieses Hilfswerkzeug 

für Udev vergibt Gerätenamen 

Tabelle 1: Udev-Speicherorte 

Distribution 

Ubuntu 12.10, Debian 7.0, SLES 11 SP2 

Open Suse, Red Hat 6 

Chakra Linux 2013.01 

auf Basis des Ortes, an dem sich die Hardware 

befindet. Damit entstehen gleichzeitig 

konsistente und aussagekräftige Namen 

für die Netzwerkkarten: NICs auf 

dem Mainboard beginnen mit dem Präfix 

»em«, gefolgt von der Portnummer von 

eins an gezählt. PCI-Karten haben folgendes 

Namensschema: »pSlotnummerpPort 

nummer«. Beispiele hierfür sind »em1« 

für das erste interne Interface und »p4p1« 

für den ersten Port einer Netzwerkkarte 

im Steckplatz Nummer 4. 

Das Hilfsprogramm liest die nötigen Informationen 

mit Hilfe der System Management 

BIOS Specification (SMBIOS 

[2]) aus. Diese Spezifikation beschreibt, 

wo das BIOS die nötigen Informationen 

über Steckplätze und Netzwerkkarten 

speichert. Falls das BIOS nicht die entsprechenden 

Einträge unterstützt, greift 

»biosdevname« auf die IRQ-Routing-Tabelle 

zurück. 

Lösungsansatz von 

Systemd ab v197 

Pfad 

• /etc/udev/rules.d/70-persistent-net.rules 

• /lib/udev/rules.d/75-persistent-net-generator.rules 

• /etc/udev/rules.d/70-persistent-net.rules 

• keine Net-Generator-Regeln seit 12.3. Stattdessen wird 

das Package »biosdevname« verwendet, um die NICs 

zu benennen. 

• /usr/lib/udev/rules.d/80-net-name-slot.rules 

• keine Net-Generator-Regeln, da Systemd v197 

name« erhalten Netzwerkkarten ihren 

Namen gemäß ihres eindeutigen Orts in 

der (virtuellen) Hardware (siehe Abbildung 

2). 

Zu Beginn stehen zwei Zeichen für die 

Art der Schnittstelle: »en« für Ethernet, 

»wl« für WLAN, »ww« für WWAN. Dann 

folgt die Unterscheidung nach Typ: »oIndex« 

steht für ein Onboard-Interface mit 

Ordnungsnummer, »sSlot« für Steckplatzkarten 

mit Ordnungsnummer und 

»pBussSlot« gibt die Lage der PCI-Karte 

wieder. Beispiele für das Resultat wären 

etwa »enp2s0« oder »enp2s1«. Das ist nur 

ein kleiner Ausschnitt des Namensschemas, 

weitere Informationen finden sich 

unter [4] und [5]. 

Nachwirkungen 

Allerdings fordert die Namensrevolution 

ihre Opfer: Vor allem Programme im 

Enterprise-Umfeld und viele (Installations-)Skripte 

erwarten ein traditionelles 

Schema von Netzwerknamen nach dem 

Muster »eth*« und funktionieren auf einmal 

nicht mehr. In [3] findet sich als Lösungsansatz, 

die Datei »80‐net‐name‐slot. 

rules« umzukopieren: 

cp /usr/lib/udev/rules.d/80‐net‐name‐slot.U 

rules /etc/udev/rules.d/80‐net‐name‐slot.rules 

und die Regeln wie in Listing 1 gezeigt 

so zu ändern, dass sie Gerätenamen nach 

traditionellem Schema vergeben. 

In Listing 1 wird über die »PROGRAM«- 

Direktive ein kleines Python-Skript aufgerufen, 

das ein Mapping auf die alten 

Namen durchführt (Listing 2). 

Das Skript lässt sich ganz einfach durch 

Änderung der Schlüsselwertpaare in 

Zeile 4 an die eigene Umgebung anpassen. 

Damit werden nun die folgenden 

Bedingungen erfüllt: 

n Die Netzwerkkonfiguration ist nicht 

mehr abhängig vom Zufall. E 

Listing 2: »name_dev.py« 

01 #!/usr/bin/env python 

02 import sys 

03 

04 dict = {'enp2s0':'eth0', 'enp2s1':'eth1'} 

05 

06 if sys.argv[1] in dict: 

07 print dict[sys.argv[1]] 

08 else: 

09 print(sys.argv[1]) 

10 exit(0) 


Admin 


81


Udev 

entsprechenden Ordnungszahl 

Schnittstelle 

des Kernels (»%n«). 

Durch das Setzen eines MAC- 

Adressmusters, das den automatisch 

generierten MAC- 

Ethernet (en) 

WLAN (wl) 

Adressen des Hypervisors 

+ 

entspricht, wird die Regel genauer 

Typ 

spezifiziert. Fügt man 

Onboard (o) Bus (p) 

+ 

Index Nr. 

Schacht (s) 

dieser Regel eine passende Zuweisung 

voran, so ist es auch 

möglich, für eine VM-Vorlage 

eine andere Netzwerkkonfiguration 

zu verwenden als für 

die Klone. Bestehende Persistent-Net-Regeln 

werden weder 

= 

beim Update noch durch den 

eno2 

... 

enp5s0 wlp3s0 

Net-Generator überschrieben. 

Bekanntlich gibt es für jede 

Regel auch eine Ausnahme, 

Abbildung 2: Benennung der Netzwerkschnittstellen durch 

»systemd«. 

so auch hier: Die Udev-Regeln 

gehen davon aus, dass der Hypervisor 

(oder die Hardware) 

n Das traditionelle Namensschema wird 

beibehalten. 

n Die Systeme können in der Cloud beliebig 

oft geklont werden. 

Diese Systemd-Version kann man bei 

Chakra Linux [6] ab 2013.01 ausprobieren; 

bei anderen Distributionen wird es 

noch etwas dauern. Fedora 19 soll diese 

Version ebenfalls verwenden. 

die Geräte immer in der konfigurierten 

Reihenfolge aktiviert und diese damit dem 

Kernel in derselben Reihenfolge bekannt 

werden. Für KVM und VMware geht das 

Konzept auf – bei Hyper-V scheint das 

nicht der Fall zu sein (siehe dazu [7]). 

Hier bleibt dann nur die Lösung über 

das Biosdevnames-Paket oder eben die 

manuelle Nacharbeit. 

Im Endeffekt umgeht man mit diesen 

Ein Workaround 

Regeln die Generatoren für die Persistent- 

Net-Regeln und ist damit befreit von den 

Den neuen Bemühungen zum Trotz hat 

man es im Alltag noch oft genug mit den 

Generator-Regeln zu tun (siehe Tabelle 1). 

Glücklicherweise ist das Udev-Regelwerk 

mächtig genug, um sich selbst aus der 

Schlinge zu ziehen. Der folgende Trick 

(Listing 3) nutzt den Umstand aus, dass 

nach erfolgter Zuweisung eines Namens 

für ein Gerät keine weiteren zutreffenden 

Regeln ausgeführt werden. Damit vergibt 

die Udev-Regel einfach den vom Kernel 

vorgeschlagenen Namen (»eth*«) mit der 

Nachteilen, die sie mit sich bringen. Ein 

weiterer Vorteil dieser Vorgehensweise 

ist, dass die traditionellen Gerätenamen 

(»eth*«) beibehalten werden und damit 

Anwendungen und Skripte, die sich exakt 

auf diese Namensgebung verlassen, weiterhin 

funktionieren. Es bleibt allerdings 

bei der Schwierigkeit, dass der Kernel 

den Geräten nach der Reihenfolge ihres 

Erscheinens während des Bootvorgangs 

entsprechende Gerätenummern vergibt. 

Die Regeln im Listing 3 lassen sich somit 

Listing 3: »70‐persistent‐net.rules« 

01 Regel für KVM: 

02 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="52:54:00:*", KERNEL=="eth*", 

NAME="eth%n" 

03 Regel für VMware: 

04 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:56:*", KERNEL=="eth*", 

NAME="eth%n" 

05 Regel für Xen: 

06 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:16:3E:*", KERNEL=="eth*", 

NAME="eth%n" 

nur in Umgebungen erfolgreich einsetzen, 

bei denen diese Reihenfolge immer 

gleich ist. 

Fazit 

Jeder der gezeigten Lösungsansätze hat 

seine Vor- und Nachteile. Mit dem Workaround 

für die Cloud habe ich auf SLES, 

Ubuntu, VMware, KVM und Hardware- 

Blades bisher gute Erfahrungen gemacht. 

Leider ist eine Rundum-sorglos-Lösung 

im Udev-Umfeld nicht in Sicht. Biosdevnames 

und Systemd brechen mit den 

alten Konventionen. Für Systemd gibt 

es hier eine Lösung durch Anpassung 

der Regel in Verbindung mit einem Hilfsskript. 

Systemd wird sich mit seinem 

Ansatz wohl in den nächsten Versionen 

bei den entsprechenden Distributionen 

durchsetzen. Spannend wird es auch 

bei Ubuntu, wo es bei den bestehenden 

Udev-Regeln zu bleiben scheint. Schön 

wäre allerdings ein Admin-freundlicher 

Ansatz, bei dem man nur durch Editieren 

einer Konfigurationsdatei passende und 

gleichbleibende Namen für seine Netzwerkkarten 

vergeben kann. (ofr) n 

Infos 

[1] Consistent Network Device Naming 

in Linux: [http:// linux. dell. com/ files/ 

whitepapers/ consistent_network_device_ 

naming_in_linux. pdf] 

[2] System Management BIOS: 

[http:// en. wikipedia. org/ wiki/ System_Management_BIOS] 

[3] Predictable Network Interface Names: 

[http:// www. freedesktop. org/ wiki/ 

Software/ systemd/ PredictableNetworkInte 

rfaceNames] 

[4] RFC: Predictable Network: [http:// www. 

mail‐archive. com/ systemd‐devel@lists. 

freedesktop. org/ msg07875. html] 

[5] udev-builtin-net_id.c: [http:// cgit. 

freedesktop. org/ systemd/ systemd/ plain/ 

src/ udev/ udev‐builtin‐net_id. c] 

[6] Chakra: [http:// www. chakra‐project. org/] 

[7] Red Hat 5.5 virtual machine NICs bind to 

different configurations: [http:// support. 

microsoft. com/ kb/ 2665504] 

Der Autor 

Martin Braun ist Senior Consultant und DevOps- 

Entwickler im Cloud-Umfeld und Linux-Fan seit 

Suse Linux 5.3. 


Test 

Oracle 12c 

© Jakub Jirsak, 123RF 

Oracle Database 12c: Cloud Computing mit Multitenant-Architektur 

Datenbank zum 

Einstöpseln 

Mehr als 500 neue Features sind in das aktuelle Release Oracle Database 12c eingeflossen. Sie sollen unter anderem 

die Sicherheit, die Hochverfügbarkeit und Analysemöglichkeiten verbessern, bieten aber auch eine neue 

Architektur, die mit ihren Pluggable Databases die Verwaltung einer Private und Public Database Cloud sowie die 

Konsolidierung von Datenbanken erleichtert. Andrea Held, Ronny Egner 

Rund fünf Jahre Entwicklungszeit waren 

für das neue Release erforderlich. Die eigentliche 

Veröffentlichung erfolgte dann 

eher still und leise, ohne Paukenschlag 

und großes Tamtam, wie sonst üblich. 

Die aktuelle Version kann seit Ende Juni 

aus dem Oracle Technology Network 

(OTN) heruntergeladen werden. Sie sollte 

eigentlich früher veröffentlicht werden, 

dann musste man aber doch etwas länger 

testen, um eine möglichst fehlerfreie Software 

auf den Markt zu bringen. 

Aktuell steht das neue Release für Linux 

und Solaris zur Verfügung. Versionen 

für Windows, IBM AIX und HPUX sollen 

in Kürze folgen. Auch ein Release 

für BS2000-Plattformen wird es wieder 

geben. Für die Aktualisierung will der 

Hersteller erneut spezielle Upgrade- 

Assistenten bereitstellen. Sogar der direkte 

Schritt von der älteren Releases 8i 

und 9i auf 12c soll möglich sein. Voraussetzung 

hierfür ist, dass die Datenbank 

den aktuellen Patch-Stand aufweist. 

Oracle will über die bekannten Lizenzmodelle 

hinaus auch einen eigenen Cloud- 

Dienst mit flexiblen Preisen anbieten. Ob 

und wie dies bei den Kunden ankommen 

wird, ist eine spannende Frage: Nicht erst 

nach den jüngsten Berichten über PRISM 

stehen viele Unternehmenskunden den 

Public-Cloud-Modellen eher skeptisch 

gegenüber. Doch neben der Public Cloud 

gibt es künftig einfache Möglichkeiten, 

auch im eigenen Unternehmen mit der 

neuen Multitenant-Architektur eine flexible 

und gut konsolidierbare Datenbank- 

Landschaft bereitzustellen. Die neue 

Multitenant-Architektur bildet so eine Voraussetzung 

für Database as a Service. 

Neues Paradigma 

Eine der wichtigsten Neuerungen ist die 

Mandantenfähigkeit der neuen Architektur. 

Sie soll Cloud Computing erleichtern, 

gleich ob in einer öffentlichen oder in 

der Private Cloud eines Unternehmens. 

Aber auch Hardware-Ressourcen und 

der Verwaltungsaufwand lassen sich so 

reduzieren. 


Oracle 12c 

Test 

Die neue Architektur wird vor allem jenen 

Kunden zugutekommen, die bisher 

zahlreiche einzelne Instanzen im Einsatz 

haben. Bis zu 253 Datenbanken können 

nun in eine Instanz gepackt werden. So 

sollen sich Hardware-Kapazitäten wie 

Arbeitsspeicher, CPU-Leistung und Storage 

gemeinsam und effizienter nutzen 

lassen. Auch das Einspielen von Patches, 

Upgrades der Datenbanksoftware sowie 

Backup- und Recovery-Funktionen werden 

einfacher (Abbildung 2). 

Bei dem Konzept der Pluggable Database 

handelt es sich um eine grundsätzliche 

Veränderung des bisherigen Oracle-Paradigma, 

demzufolge eine Instanz (oder 

mehrere Instanzen eines Clusters) immer 

nur genau eine Datenbank öffnen konnten. 

Mit der Einführung der Pluggable 

Database ändert sich das: Es ist möglich, 

mit einer Instanz mehrere Datenbanken 

zu öffnen und zu betreiben. Oracle zielt 

damit auf eine maximale Datenbank- 

Konsolidierung ab, ohne das dafür Virtualisierung 

nötig wäre. Nach Meinung der 

Autoren kann die neue Architektur die 

Virtualisierung auf Hostebene in großen 

Umgebungen überflüssig machen. 

Um dies zu erreichen, erweitert Oracle 

die Datenbank um eine weitere Ebene: Es 

gibt zukünftig die sogenannte Container 

Database (CDB), die bis zu 253 Pluggable 

Databases (kurz: PDBs) aufnimmt 

(Abbildung 1). Diese erscheinen für den 

Anwender wie normale Datenbanken – 

und sie verhalten sich auch so. Anpassungen 

am Programmcode einer Anwendung 

sind bis auf ganz wenige Fälle nicht 

notwendig, da der Namensraum jeder 

Datenbank individuell ist. 

Die CDB selbst ist eine Instanz mit zugehörigem 

Speicher und Prozessen (wie 

zum Beispiel dem Logwriter LGWR, dem 

DBWriter DBWn, Checkpointer CKPT, 

und so weiter). Die PDBs dagegen haben 

keine eigenen Hintergrundprozesse 

– die Verarbeitung wird von den Hintergrundprozessen 

der Container Database 

erledigt. 

Das Data Dictionary mit den Metadaten 

speichert – wie in den Releases zuvor – 

Informationen wie Benutzer und Berechtigungen, 

Informationen über Tabellen, 

Indizes, Views und alle weiteren Datenbankobjekte. 

Dieses Data Dictionary wird 

in der Multitenant-Architektur jedoch in 

der CDB gespeichert. Die einzelnen PDBs 

Die Verteilung der Ressourcen zwischen 

den einzelnen Datenbanken erfolgt mit 

dem per Default aktivierten Ressource 

Manager von Oracle. Jede Datenbank erhaben 

intern lediglich Pointer auf die entsprechenden 

Bereiche in der Container 

Database. In ihr sind die Objekte des 

Data Dictionary definiert. Die eigentlichen 

Daten des Data Dictionary wie zum 

Beispiel die Rows in der Tabelle »OBJ$« 

sind in den jeweiligen Pluggable Databases 

abgelegt, sodass diese Daten beim 

Kopieren der Datenbank mitgenommen 

werden können. 

Effizienter durch Container 

Dieses Konzept ermöglicht die Trennung 

von Metadaten – also der Beschreibung 

des Data Dictionary – von den eigentlichen 

Daten, dem Inhalt des Data Dictionary. 

Zum einen ist es dadurch möglich, 

die einzelnen PDBs beliebig zu transportieren. 

Sie können entweder innerhalb 

eines oder auch zwischen verschiedenen 

Containern verlegt werden. Zum anderen 

erlaubt dies ab der Version 12c schnellere 

Upgrades: Statt wie bisher das Data 

Dictionary mittels »catproc« upzugraden, 

genügt es künftig, die PDB in eine 

Container Database der Version 12c+1 

„einzupluggen“, um diese auf die Nachfolgeversion 

zu aktualisieren. 

Wie bereits beschrieben verfügen die 

einzelnen PDBs über keine eigenen 

Speicherbereiche oder Prozesse. Hierdurch 

wird eine bessere Auslastung der 

Ressourcen erreicht, da zum einen wesentlich 

weniger Prozesse um die ver- 

Abbildung 1: Eine Container Database nimmt mehrere Pluggable Databases auf. 

fügbaren CPU-Kerne konkurrieren und 

so weniger Context-Switches notwendig 

werden, und zum anderen wesentlich 

mehr Speicher für den Buffer Cache oder 

den Shared Pool bereitsteht, da die mindestens 

350 MByte SGA für den Betrieb 

einer Instanz für die CDB und nicht für 

die PDBs gelten. Dies kann man sich mit 

einem einfachen Rechenbeispiel vergegenwärtigen: 

Bei zehn Datenbanken in 

der Version 11g werden mindestens 10 x 

350 MByte, also rund 3,5 GByte Speicher 

benötigt, um jede Instanz für sich überhaupt 

starten zu können. Der Buffer Pool 

und der Shared Pool haben hier kaum 

Platz, um ihren Funktionen nachkommen 

zu können. Ebenso hat man als Resultat 

mindestens 10 x 6 Hintergrundprozesse, 

die um die CPU konkurrieren. Nutzt man 

nun das Konzept der Pluggable Databases 

und lässt die zehn Datenbanken als 

PDBs in einer CDB laufen, so bleiben davon 

lediglich 6 Prozesse und 350 MByte 

Speicher zum Betreiben der CDB übrig. 

Die restlichen 3,15 GByte im Vergleich 

zur alten Architektur kann man mit dem 

neuen Konzept bereits für den Buffer 

Cache oder den Shared Pool nutzen. 

Ressourcen-Management 


Admin 


85

Test 

Oracle 12c 

hält standardmäßig einen gleichmäßigen 

Anteil an den Ressourcen. Bei zwei Datenbanken 

bekommt jede die Hälfte, bei 

drei ein Drittel der Ressourcen, bei vier 

ein Viertel und so weiter. Die Verteilung 

kann aber bei Bedarf auch angepasst werden. 

Diese Anpassungen können auch 

innerhalb der PDBs erfolgen. So sind zum 

Beispiel garantierte Anteile an der CPUbeziehungsweise 

Begrenzungen der CPU- 

Last einstellbar. Eine Begrenzung der 

I/O-Last ist jedoch nur auf Oracles eigener 

Exadata-Hardware möglich. 

Die physikalischen Speicherstrukturen 

der Datenbanken im Storage sind dagegen 

kaum verändert. So befinden sich die 

Control Files, Redo Logs, die Flashback 

Logs und der UNDO-Tablespace nach 

wie vor auf der Ebene des Containers. 

Der SYSTEM- und SYSAUX-Tablespace 

in der Container Database bildet das 

globale Data Dictionary; die gleichnamigen 

Tablespaces in den einzelnen PDBs 

speichern hingegen nur die eigentlichen 

Nutzdaten des Data Dictionary. Der temporäre 

Tablespace – der vergleichbar dem 

Swapspace auf Betriebssystemebene ist 

– kann global für alle Datenbanken und/ 

oder lokal angelegt werden. Für die Ablage 

von Daten kann man auf allen Ebenen 

User-Tablespaces anlegen. Da der 

Namensraum für jede Datenbank individuell 

ist, ist ein Zugriff über PDB-Grenzen 

hinaus außer über Datenbank-Links 

nicht möglich – auch wenn die Daten 

sich in derselben CDB befinden. Generell 

ist es beim Einsatz dieser Technologie 

nicht empfehlenswert, Benutzerobjekte 

in der Containerdatenbank abzulegen, da 

diese bei einer Migration manuell übertragen 

werden müssten. Perspektivisch 

plant Oracle, diese Möglichkeit ganz abzuschalten. 

Für das Management des Speicherplatzes 

gibt es die Möglichkeit, den pro Datenbank 

maximal belegbaren Speicherplatz 

zu beschränken, sodass innerhalb dieser 

Grenzen ein Management durch weniger 

erfahrene DBAs möglich wird. 

Rechte und Rollen 

Der Verwaltung von Benutzern und 

Rollen kommt in einer hochgradig konsolidierten 

Umgebung natürlich eine 

Schlüsselfunktion zu. Beim Einsatz der 

Pluggable Database ist zwischen sogenannten 

Common- und Local-Benutzern 

und -Rollen zu unterscheiden. Common 

– oder besser global – sind Benutzer und 

Rollen dann, wenn sie auf Ebene der 

CDB angelegt sind und sich damit in alle 

vorhandenen und zukünftigen PDBs vererben. 

Man erkennt solche Benutzer am 

Präfix »C##«. Diese globalen User können 

sich in jede PDB konnektieren, zu der sie 

über die entsprechenden Grants Zugang 

haben. Auf Ebene der PDB lassen sich 

die Rechte über die durch die Common- 

Rollen erteilten Berechtigungen hinaus 

noch erweitern. So ist es möglich, einem 

globalen Benutzer in einer Datenbank 

DBA-Rechte zu geben, während sich derselbe 

Benutzer zur selben Zeit mit einer 

anderen Datenbank erst gar nicht verbinden 

darf. 

Die Verbindung der Benutzer zu einer 

Datenbank erfolgt genau wie in älteren 

Releases über den Listener_Prozess beziehungsweise 

über den Scan-Listener. 

Pro Pluggable Database gibt es per Default 

genau einen gleichnamigen Service, 

der aber noch um zusätzliche Services 

ergänzt werden kann. 

Einschränkungen 

Bei all den Vorteilen gibt es auch Einschränkungen 

im Betrieb einer solchen 

Umgebung. Offensichtlich ist zunächst 

Listing 1: ErstellEN einer PDB 

01 select * from CDB_PDBS order by pdb_id; 

02 SQL> PDB_ID PDB_NAME D BID CON_UID GUID STATUS CREATION_SCN 

03 =====================================================================; 

04 2 PDB$SEED 4062623230 4062623230 E0C9D94CE3B6497BE04380B0A8C06105 

NORMAL 1720734 1 

05 SQL> select name from v$datafile order by 1; 

06 ====================================================================; 

07 DATA01/CDB1/DATAFILE/sysaux.256.820013801 

08 DATA01/CDB1/DATAFILE/sysaux.257.820013845 

09 DATA01/CDB1/DATAFILE/undotbsl.259.820013893 

10 DATA01/CDB1/DATAFILE/users.258.820013891 

11 DATA01/CDB1/DD7C48AA5A4404A2E04325AAE80A403C/DATAFILE/ 

sysaux.265.820013923 

12 DATA01/CDB1/DD7C48AA5A4404A2E04325AAE80A403C/DATAFILE/ 

system.266.820013923 

13 

14 6 rows selected 

15 ; 

16 SQL> create pluggable database pdb001 admin user admin identified by; 

17 

18 Pluggable database created. 

19 

20 SQL> alter pluggable database pdb001 open; 

21 

22 Pluggable database altered. 

23 

24 SQL> select * from CDB_PDBS order by pdb_id; 

25 

26 PDB_ID PDB_NAM DBID CON_UID GUID STATUS 

CREATION_SCN CON_ID 

27 ‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 

28 2 PDB$SEED 4062623230 4062623230 E0C9D94CE3B6497BE04380B0A8C06105 NORMAL 

1720734 1 

29 3 PDB001 1700339437 1700339437 E0D0BE79135B75B0E04380B0A8C00F14 NORMAL 

1956354 1 

30 

31 SQL> select name from v$datafile; 

32 

33 NAME 

34 ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 

35 +DATA01/CDB1/DATAFILE/sysaux.256.820013801 

36 +DATA01/CDB1/DATAFILE/system.257.820013845 

37 +DATA01/CDB1/DATAFILE/undotbs1.259.820013893 

38 +DATA01/CDB1/DATAFILE/users.258.820013891 

39 +DATA01/CDB1/DD7C48AA5A4404A2E04325AAE80A403C/DATAFILE/ 

sysaux.265.820013923 

40 +DATA01/CDB1/DD7C48AA5A4404A2E04325AAE80A403C/DATAFILE/ 

system.266.820013923 

41 +DATA01/CDB1/E0D0BE79135B75B0E04380B0A8C00F14/DATAFILE/ 

sysaux.271.820043565 

42 +DATA01/CDB1/E0D0BE79135B75B0E04380B0A8C00F14/DATAFILE/ 

system.275.820043565 


Test 

Oracle 12c 

einmal, dass alle PDBs einer CDB die gleiche 

Datenbankversion haben. Weiterhin 

müssen alle Datenbanken den gleichen 

Zeichensatz verwenden – verschiedene 

Zeichensätze sind nicht möglich. Hier 

bietet sich Unicode an. Um Migrationen 

nach Unicode einfacher zu gestalten, 

wurde als neues Feature in der 12c die 

maximal mögliche Spaltenbreite von 

VARCHAR2-Spalten von 4 KByte auf 32 

KByte erweitert. Fehler, die durch das 

Erreichen der maximal möglichen Spaltenbreite 

bei der Konvertierung nach 

Unicode hervorgerufen wurden, gehören 

damit der Vergangenheit an. 

Parallel dazu gibt es ebenfalls Einschränkungen 

bezüglich der pro Pluggable 

Database individuell beeinflussbaren 

Datenbankparameter. Eine Übersicht der 

modifizierbaren Parameter kann man mit 

folgender Abfrage erhalten: 

select name from v$parameter where U 

ISPDB_MODIFIABLE ='TRUE' order by 1 

Hauptsächlich die Tuning-Parameter wie 

»OPTIMIZER_***« und »PARALLEL_***« 

sowie die NLS-Parameter sind individuell 

pro PDB modifizierbar. 

Unterstützung der Cloud- 

Architektur 

Dafür, dass die Multitenant-Architektur 

mit Container- und Pluggable-Datenban- 

ken in der ersten Version vorliegen, ist 

die Unterstützung durch die Oracle-Werkzeuge 

bereits weit fortgeschritten. So ist 

die Pluggable Database vollständig RACfähig, 

der RMAN ist in der Lage, Backups 

und Wiederherstellungen auf Ebene der 

PDB vorzunehmen – dies bei Wiederherstellungen 

sogar bis hinunter zu Tabellen 

– und die Integration in Standby-Datenbanken 

mit Data Guard wird ebenfalls 

unterstützt. Einzige Einschränkung bei 

Data Guard ist, dass ein Schwenk nur 

auf Ebene des Containers möglich ist 

und eine automatische Integration einer 

neuen PDB auf der Standby-Seite nur 

in Verbindung mit der zusätzlich kostenpflichtigen 

Active-Data-Guard-Option 

möglich ist. 

Datenbanken 

implementieren 

Das Anlegen einer PDB erfordert zunächst 

einmal, dass die 12c-Datenbank als Container 

Database angelegt wurde. Hat der 

DBA dies bei der Erstellung nicht explizit 

ausgewählt beziehungsweise mit dem 

Schlüsselwort »ENABLE PLUGGABLE 

DATABASE« aktiviert, handelt es sich um 

eine normale Datenbank ohne Möglichkeit 

der Aufnahme weiterer Datenbanken. 

In diesem Fall muss die Datenbank 

neu angelegt werden. Die Erstellung einer 

PDB erfolgt immer als Kopie einer bereits 

vorhandenen PDB. Dies ist entweder die 

sogenannte Seed Database »PDB$SEED«, 

die beim Erstellen des Containers implizit 

mitangelegt wird und nicht verändert 

werden kann, oder eine beliebige 

andere PDB. Sie muss sich allerdings für 

den Zeitraum der Erstellung im »OPEN 

READ‐ONLY«-Status befinden. Zusätzlich 

muss ein PDB-Administrator angegeben 

werden, der die Rolle »PDB_DBA« innehat. 

Diese Rolle ist aber per Default 

mit keinerlei Berechtigungen ausgestattet. 

Sofern gewünscht können aber bei 

Erstellung der PDB dieser Rolle weitere 

Rechte und Rollen zugewiesen werden. 

Bevor die PDB erstellt werden kann, 

muss noch für die Eindeutigkeit der resultierenden 

Dateinamen gesorgt werden. 

Dies geschieht entweder manuell über 

den Parameter »FILE_NAME_CONVERT« 

oder automatisch durch die Nutzung von 

OMF. Die Autoren raten hier der Einfachheit 

halber zur Nutzung von OMF und 

ASM (Listing 1). 

Wie in Listing 1 zu sehen ist, müssen 

PDBs vor der Nutzung und nach jedem 

Start der Instanz manuell geöffnet werden. 

Hierzu kann man einen Trigger 

schreiben oder aber die Grid-Infrastruktur 

benutzen. Über Oracle Restart lassen 

sich wie gehabt Ressourcen und ihre Abhängigkeiten 

registrieren, überwachen, 

gegebenenfalls automatisch neu starten 

beziehungsweise in der richtigen Reihenfolge 

starten und stoppen. Dies geht mit 

PDBs über Services. Sobald man einen 

Service anlegt und diesen mit einer PDB 

verknüpft, wird die verknüpfte Datenbank 

automatisch geöffnet, wenn der 

entsprechende Service startet. 

Die verfügbaren Informationen auf Ebene 

der CDB und der PDB folgen dem Prinzip 

der Sichtbarkeit. So enthält ein AWR- 

Report – ausgeführt in einer PDB – nur 

Informationen über die bestreffende PDB. 

Ein AWR-Report auf Ebene der CDB enthält 

hingegen Informationen über alle 

Datenbanken. Ähnlich verhält es sich mit 

den zusätzlichen Views mit dem Präfix 

»CDB_«. Sie enthalten Informationen 

über alle PDBs. 

Upgrade-Pfade 

Abbildung 2: Auch das notwendige Updaten und Patchen der Datenbank macht das neue Oracle-Release für den 

Administrator nun deutlich einfacher. 

Der Weg von einer Non-PDB zu einer 

PDB erfolgt auf drei Arten: Export/Import 

mittels DataPump (ab 10g Release 1; 


Oracle 12c 

Test 

ältere Versionen müssen gegebenenfalls 

einen Zwischenschritt machen), Golden- 

Gate oder Umwandlung einer Non-CDB 

in eine PDB. Hierbei muss die 10g- oder 

11g-Datenbank auf 12c aktualisiert werden 

(Abbildung 3). Bei der Umwandlung 

kann die Datenbank nach dem Upgrade 

auf 12c mit dem Package DBMS_PDB in 

eine PDB konvertiert und in eine CDB 

eingestöpselt werden. Direkte Upgrades 

sind bisher von 10.2.0.5, 11.1.0.7 und 

11.2.0.2 und höher möglich; das Resultat 

ist dann zunächst eine Non-CDB. 

Die Nutzung dieses neuen Konzepts 

setzt die Enterprise Edition voraus und 

benötigt darüber hinaus zusätzlich die 

Multitenancy-Lizenz. Sie kostet nach Listenpreis 

genauso viel wie die Enterprise 

Edition an sich. Die Standard Edition 

kann auch PDBs benutzen – allerdings 

ist da die Anzahl der möglichen Datenbanken 

auf eine begrenzt. Dies mag wie 

ein schlechter Scherz klingen, aber in 

der nächsten Version 12.2 wird es keine 

klassischen Non-CDB-Datenbanken mehr 

geben, sodass Non-PDB-Datenbanken 

konvertiert werden müssten – auch in 

der Standard Edition. 

Hierarchical Storage 

Management 

Ebenfalls neu in der Version 12c ist die 

Möglichkeit, Tabellen, Partitionen oder 

Blöcke basierend auf dem letzten Zugriff 

(schreibend wie lesend, Full-Table-Scan 

wie Einzelzugriff) automatisch Regeln zu 

unterwerfen, die beschreiben, was mit 

dem Objekt nach Ablauf der jeweiligen 

Frist passieren soll. Diese Regeln sehen 

beispielsweise vor, dass nach einer frei 

definierbaren Menge an Tagen seit dem 

letzten lesenden/schreibenden Full- Table- 

Scan beziehungsweise Single-Row-Access 

die betreffende Tabelle, Partition oder der 

Block entweder komprimiert und/oder 

in einen anderen Tablespace verschoben 

werden kann. 

So ist es zum Beispiel möglich, eine Partition 

nach 30 Tagen ohne Zugriff mittels 

Advanced Compression zu komprimieren, 

um Platz zu sparen. Nach 60 Tagen ohne 

Zugriff kann abermals die Kompression 

durch den Einsatz von (E)HCC erhöht 

werden und nach 90 Tagen ohne Zugriff 

kann die bereits komprimierte Partition 

in einen anderen Tablespace verschoben 

werden, der sich auf einem langsameren, 

aber billigeren Storage befindet. Auf 

diese Art und Weise kann die Datenbank 

häufig genutzte von selten verwendeten 

Daten trennen sowie letztere automatisch 

komprimieren und auf billigeren Storage 

verlagern. 

Flex Cluster / Flex ASM 

Ebenfalls neu in der Version 12c ist das 

Konzept des Flex ASM (Automatic Storage 

Management). Es ermöglicht die 

Nutzung einer ASM-Instanz, die nicht 

lokal auf dem Server läuft. Die Übertra- 


Admin 


89

Test 

Oracle 12c 

gung der Daten erfolgt über ein Netzwerk 

(Ethernet oder Infiniband). Im Extremfall 

ermöglicht dieses neue Feature eine 

Konsolidierung und Trennung des Storage 

von den Datenbanken, indem ein 

zentraler Storage-Cluster aufgebaut wird, 

auf den alle anderen Datenbanken im 

Unternehmen zugreifen. Flex ASM ist die 

Voraussetzung für ein weiteres, neues 

Feature, das die Anzahl der Knoten und 

damit die verfügbare Rechenleistung in 

einem RAC steigert, ohne dass jeder Knoten 

einen Zugriff auf den Shared Storage 

benötigt: Flex Cluster. 

Flex Cluster bestehen aus Hub- und Leaf- 

Nodes. Ein Hub Node ist ein Knoten, der 

direkten Zugriff (zum Beispiel per LAN) 

auf den Storage hat. Ein Leaf Node hingegen 

hat nur indirekt über Flex ASM Zugriff 

auf den Storage – ist aber dennoch 

ein vollwertiges Mitglied der Clusters. 

Application Continuity 

Vor einigen Jahren revolutionierte die 

Einführung von TAF (Transparent Application 

Failover) die bis dato gängigen 

Cluster-Konzepte, bei dem durch einen 

Knotenausfall abgebrochene SELECT- 

Statements (unter bestimmten Bedingungen) 

transparent für den Anwender 

auf einem verbleibenden Knoten erneut 

ausgeführt werden konnten. Mit der Version 

12c erweitert Oracle dieses Konzept 

auf alle Transaktionen und nennt dieses 

Feature Application Continuity. Im besten 

Fall bleibt ein Ausfall eines Knotens 

im RAC damit für den Anwender völlig 

unbemerkt – egal was für eine Art von 

Transaktion er gerade ausgeführt hatte. 

Allerdings bedingt dies Anpassungen am 

Client und ist an die Nutzung bestimmter 

Klassen und Bibliotheken gebunden. 

Derzeit wird JDBC Thin, UCP und Web- 

Logic unterstützt. Die Unterstützung für 

PeopleSoft, Siebel und Oracle Fusion ist 

in Arbeit. 

Kleine Perlen 

Neben all den großen Features gibt es 

auch kleinere nützliche Erweiterungen: 

n So ist es nun möglich, ein Datenfile 

online zu verschieben. 

n Neben den bekannten Rollen SYSDBA 

und SYSOPER gibt es nun weitere Rollen 

zur Abstufung der vorhandenen 

Berechtigungen: SYSBACKUPDBA für 

Backup und Recovery, SYSDGDBA für 

Data Guard und SYSKMDBA zur Verwaltung 

der Wallets. 

n Weiterhin erhielt Data Guard über die 

Far-Sync-Standby-Option die Möglichkeit, 

synchrone Replikationen 

über größere Entfernungen als 40 

bis 100 km zu ermöglichen, indem 

ein lokaler Hub die Daten synchron 

entgegennimmt und die Daten dann 

asynchron an die Remote-Standby- 

Seite transportiert. Der Switchover 

selbst erfolgt zwischen Primary- und 

Remote-Standby – der lokale Hub ist 

darin nicht involviert. 

n Abgebrochene Switchover können nun 

wieder aufgenommen werden. 

n DML auf temporären Tabellen in einer 

Standby-Datenbank erzeugt kein Redo 

und ermöglicht so die Speicherung 

von Daten in temporären Tabellen in 

einer Standby-Datenbank. 

n Sequenzen der Primary-DB können 

auch in der Standby genutzt werden. 

n Datenbankupgrades ohne Downtime 

sind nun (fast) automatisiert. 

n Die Größe der PGA ist jetzt mittels des 

Parameters PGA_AGGREGATE_SIZE_ 

LIMIT begrenzbar. 

n Das Patch Inventory ist direkt aus der 

Datenbank abfragbar. 

n ACFS (Cluster-Filesystem) unterstützt 

nun die Ablage aller Datenfiles. ACFS- 

Snapshots können beschreibbar sein. 

Fazit 

Oracle hat nach einer doch recht langen 

Entwicklungszeit einen großen Wurf 

hingelegt. Neben den vielen kleinen 

Verbesserungen gibt die große Architekturänderung 

hin zur Pluggable und 

Cloud Database viele Möglichkeiten der 

Nutzung. Ob und wie weit diese von 

den Usern angenommen werden, wird 

sich in der nächsten Zeit zeigen. Nach 

anfänglicher Zurückhaltung wird sicher 

eine breite Umstellung folgen. (jcb) n 

Abbildung 3: Etliche Neuerungen betreffen auch die erleichterte Installation und Upgrades von früheren Oracle- 

Versionen auf das neue Release. 

Die Autoren 

Andrea Held ist Leiterin der Frankfurter Datenbanktage 

und Geschäftsführerin der Held Informatik 

GmbH. Sie ist Autorin des Buches "Oracle 

12c New Features" und Co-Autorin von "Der 

Oracle DBA – Administration der Oracle Database 

12c" sowie „Oracle 12c Advanced – Cloud Computing, 

Virtualisierung und Hochverfügbarkeit“, die 

im Hanser-Verlag erscheinen. 

Ronny Egner ist Sprecher der Frankfurter Datenbanktage. 

Er arbeitet als Freiberufler in Projekten 

und ist Dozent rund um das Thema Oracle- 

Datenbanken. Nebenher beschäftigt er sich mit 

SAP HANA, PostgreSQL und der neuen Oracle- 

Datenbank 12c. Seine Schwerpunkte liegen im 

Infrastrukturbereich. So kennt er sich auch mit 

Storage-, Betriebs- und Backupsystemen aus. 


Test 

LSI Nytro MegaRAID 

© Scott Betts, 123RF 

Im Test: Nytro MegaRAID 8110-4i von LSI 

Rennfieber 

Mit dem Versprechen, DAS-Speicher Beine zu machen, tritt der MegaRAID- 

8110-4i-Controller von LSI an. Welcher Performance-Gewinn dabei drin ist, 

zeigt dieser Test. Jens-Christoph Brendel 

Die hier getestete Beschleunigerkarte für 

direkt verbundenen Storage (DAS) von LSI 

ist eine Kombination aus RAID-Controller 

und intelligentem Cache auf Flash-Basis. 

Direct Attached Storage kann damit um 

ein Vielfaches an Tempo zulegen, indem 

ein Algorithmus die häufig verwendeten 

Daten in den schnellen SSD-Cache verschiebt, 

wogegen seltener benutzte auf 

den relativ langsamen Platten 

bleiben. Auch der Rebuild einer 

RAID-Gruppe geht dank 

des Caches übrigens zügiger 

vonstatten. 

An die Karte (Abbildung 1) 

lassen sich direkt mittels eines 

SAS-to-SATA-Adapterkabels 

bis zu vier SATA-Festplatten 

anschließen. Alternativ lässt 

sich ein SAS-Expander konnektieren, 

der dann seinerseits 

mehr und schnellere 

SAS-Platten in einer internen 

Drive Bay ansteuern kann. Für diesen 

Test wählten wir die erste Option und 

verbanden drei SATA-Desktop-Platten 

von Western Digital mit der Karte, auf 

der sich außerdem zwei Flash-Module 

finden, die zusammen ein 90 GByte großes 

Volume bilden (CacheCade). Zum 

Vergleich maßen wir eine dieser Platten 

(WD3200BEKT) als Einzellaufwerk. 

Abbildung 1: Die Nytro-MegaRAID-Controller-Karte 8110-4i. 

Unser Testrechner lief unter Windows 

Server 2008 R2, alternativ werden auch 

Windows Server 2003 SP2/XP SP2/Vista 

SP2 oder Windows 7 SP1 unterstützt, 

zusätzlich eine Reihe von Linux-Distributionen, 

darunter SLES und RHEL, außerdem 

VMware ESXi 4.x und 5 sowie 

Solaris 10 und 11. 

Hürdenlauf 

Die zu beschleunigenden Platten muss 

man im ersten Schritt zu einer RAID- 

Gruppe zusammenfassen. Das gelingt auf 

BIOS-Ebene entweder über eine einfache 

WebBIOS-GUI, die ohne Betriebssystemunterstützung 

auskommen soll, oder 

über ein Command Line Interface (CLI). 

Ersteres funktionierte auf unserem Rechner 

nicht. Das CLI, das wir notgedrungen 

wählen mussten, litt hingegen unter der 

Volkskrankheit der meisten 

Tools dieser Provenienz: benutzerunfreundliche 

Dokumentation 

samt kryptischer 

Syntax und nichtssagender 

Fehlermeldungen. 

Beispielsweise muss der Anwender 

die Platten immer mit 

einer Enclosure- und einer 

Slot-Nummer spezifizieren, 

auch wenn sie gehäuselos verkabelt 

sind. Dann ist für das 

nicht vorhandene Enclosure 

ein Default-Wert von exakt 


LSI Nytro MegaRAID 

Test 

Lohnt sich das? 

Ob sich ein SSD-beschleunigter RAID-Controller 

tatsächlich auszahlt, hängt entscheidend vom 

Workload ab, der ihm zugemutet wird. Nur wenn 

eine Menge von Daten, die das Volumen des 

Cache nicht sprengen, häufig gelesen werden, 

kann der Cache seine Stärken ausspielen. Wo 

überwiegend geschrieben wird oder sich Zugriffe 

kaum wiederholen, greift der Cache ins 

Leere und bewirkt keine Performance-Verbesserung. 

Herkömmliche synthetische Benchmarks 

eignen sich oft nur bedingt, um den Performance-Gewinn 

eines Cache zu messen, weil ihre 

Zugriffsmuster eben nicht denen entsprechen, 

die Applikationen in der Praxis erzeugen. Man 

kann sich hier unter Umständen helfen, denn 

zumindest die besseren Benchmarks lassen sich 

umfangreich parametrisieren, aber das bleibt 

eine Notlösung. 

Eine viel bessere Vorausschau ermöglicht dagegen 

die Nytro Predictor Software von LSI, 

von der man zumindest eine Trial-Version gegen 

Registrierung kostenlos herunterladen kann. 

Die reguläre Verwendung ist allerdings kostenpflichtig. 

Sie beobachtet das I/O-Geschehen 

über einige Stunden und ermittelt, wie gut die 

Caching-Algorithmen des Nytro-RAID-Controllers 

damit zurechtkommen würden. Im Ergebnis 

erhält man eine Prognose des wahrscheinlichen 

Geschwindigkeitsvorteils bei Einsatz der Beschleunigerkarte. 

252 anzugeben, was die Dokumentation 

aber mit keiner Silbe erwähnt. Erraten 

kann man es jedoch auch nicht. Wer es 

etwa mit Enclosure 0 oder 1 versucht, 

was noch einigermaßen nahe liegen 

würde, der erhält stets die vielsagende 

Fehlermeldung „Invalid input“, mit der 

ausnahmslos jede Art von Tipp-, Syntax-, 

oder Sachfehler schmallippig quittiert 

wird. Ohne Hilfe des Support ist man 

hier chancenlos. 

Als zusätzliche Verwaltungsalternative 

lässt sich unter Windows ein MegaRAID 

Storage Manager installieren, der viele 

Einstellmöglichkeiten bietet, den Status 

reportiert und einen Blick ins Log des 

Controllers erlaubt. Allerdings kann man 

mit ihm zwar das Volume für den SSD- 

Lesecache konfigurieren, wir haben aber 

kein Monitoring gefunden, das beispielsweise 

eine Cache Hit Ratio ausgewiesen 

hätte. 

Beim Storage Manager sollte man außerdem 

unbedingt auf eine aktuelle Version 

achten (derzeit 12.x), denn ältere 

Versionen können den Flash-Cache nicht 

managen. Legt man mit ihnen (oder mit 

dem CLI) eine neue RAID-Gruppe an, ist 

der Cache ausgeschaltet und die veraltete 

Software weist weder darauf hin noch 

bietet sie eine Option an, um ihn zu aktivieren, 

noch ein Monitoring, das den 

Fehler aufdecken würde. Die RAID-Konfiguration 

funktioniert, aber ohne Cache 

und mithin ohne entsprechenden Performance-Vorteil. 

Erst neuere Versionen der 

Management-Software erlauben es dem 

Admin, den Cache einzuschalten. 

Benchmarks 

Ist alles glücklich eingestellt, braucht 

das Betriebssystem noch einen passenden 

Treiber und dann kann es losgehen. 

Eine erste überschlägige Messung ergab 

im Vergleich der RAID-Gruppe (zunächst 

ohne Cache) zu einer Einzelplatte, die 

mit den im RAID verbauten identisch 

war, einen Geschwindigkeitszuwachs 

maximal um den Faktor drei, der allein 

auf die Verteilung der Lesezugriffe durch 

das RAID5 auf mehr Spindeln zurückzuführen 

ist. 

Mit zugeschaltetem Cache ergaben sich 

beim sequentiellen Lesen Geschwindigkeiten 

bis knapp 600 MByte/s, was noch 

einmal einer Verdreifachung gegenüber 

den Leseleistungen des unbeschleunigten 

RAID 5 entspricht. Ein ähnliches Ergebnis 

liefert die Reread-Funktion für wiederholtes 

Lesen (Abbildung 2): Bei großer Record 

Size klettern die Werte bei wahlfreien 

Zugriffen über 500 MByte/s und über 

50 000 IOPS. 

Vergleicht man ein paar der Benchmark- 

Resultate (Abbildung 3), zeigt sich, dass 

der Charakter des Workloads eine große 

Rolle spielt. Dominiert das wahlfreie 

Schreiben kleiner Records, kommt die 

Performance auch mit dem Cache kaum 

aus dem Keller. Beim sequentiellen Lesen 

oder beim zufälligen Lesen möglichst 

großer Rekords kann sich dagegen der 

Durchsatz gegenüber einer Einzelplatte 

verfünf- oder -sechsfachen. Gegenüber 

einer RAID-Gruppe ohne Cache verdreifacht 

sich immerhin die Leseleistung in 

der Spitze. 

Fazit 

Der Performance-Gewinn fällt zwar etwas 

geringer aus, als es von einem reinrassigen 

SSD-Laufwerk zu erwarten wäre, 

dafür beschleunigt hier eine relativ kleine 

und daher preiswerte SSD aber auch 

große Volumes, deren komplette Migration 

auf Flash-Speicher womöglich nicht 

wirtschaftlich wäre. Zusätzlich kommt 

mit der RAID-Konfiguration Redundanz 

ins Spiel, die für Ausfallsicherheit sorgt. 

Solange die am häufigsten genutzten 

Daten in den Cache passen und hauptsächlich 

gelesen werden, erweist sich der 

Nytro-MegaRAID-Controller als wahrer 

Nachbrenner für die Platten. 

n 

600.00 

Reread mit und ohne Cache 

(gemessen mit Iozone, File Size 4 GB) 

Lesen und Schreiben 

Einzelplatte vs. RAID mit und ohne Cache 

MByte/s 

500.00 

400.00 

300.00 

200.00 

100.00 

0.00 

Reread mit Cache 

Reread ohne Cache 

4 8 16 32 64 128 256 512 1024 2048 4096 8192 

Record Size 

MByte/s 

600.00 

500.00 

400.00 

300.00 

200.00 

100.00 

0.00 

sequentiell 

Lesen 

sequentiell 

Schreiben 

zufällig Lesen 

512K Records 

Einzelplatte 

RAID5 ohne 

Cache 

RAID5 mit 

Cache 

zufällig Schreiben 

512K Records 

Abbildung 2: Test des Cache mit wiederholtem Lesen. 

Abbildung 3: Besonders das Lesen kann der Cache drastisch beschleunigen. 


Admin 


93

Programmieren 

PostgreSQL-Notifikationen 

© Maxim Kazmin, 123RF 

PostgreSQL Notifications mit Perl 

Ans Licht gebracht 

Eine SQL-Datenbank wird oft als passive Datenablage betrachtet, die nur 

zuständig für die Integrität der Daten ist. PostgreSQL kann aber auch aktiv 

externe Ereignisse auslösen. Mit Perl lässt sich dies für eigene Zwecke 

ausnutzen. Torsten Förtsch 

Als ich vor circa 15 Jahren SQL lernte, 

wunderte ich mich über so ulkige SQL- 

Befehle wie »LISTEN« und »UNLISTEN« 

in der PostgreSQL-Dokumentation. Damals 

konnte ich damit nichts anfangen, 

und so vergaß ich sie wieder für eine 

ganze Weile. Vor ein paar Jahren fiel 

mir dann ein Programm auf, das ausgesprochen 

viel CPU-Zeit verbrauchte. Es 

war ein Daemon, der eine Aktion starten 

sollte, sobald sich in der Datenbank 

ein bestimmter Zustand einstellte. Dieser 

trat selten ein, sodass ich erwartete, dass 

das Programm fast keine CPU-Zeit verbraucht. 

In Wirklichkeit sah es aber anders aus: 

In einem regelmäßigen Zyklus wurde die 

Datenbank gefragt, ob der gewünschte 

Zustand erreicht ist. Wenn ja, wurde die 

Aktion gestartet, wenn nein, der nächste 

Schleifendurchlauf. So verbrauchte der 

Zyklus 100 Prozent der CPU-Kapazität. 

Im Rechenzentrum war es bestimmt 

recht warm. 

In diesem Artikel möchte ich anhand eines 

kleinen Beispiels ein in ähnlichen 

Situationen nützliches Feature vorstellen, 

das im Bewusstsein der Anwender oft ein 

Schattendasein fristet. Es geht um Notifikationen 

in PostgreSQL. Als Beispiel 

dient eine webbasierte Chat-Anwendung 

mit Apache und Mod-Perl. Ich werde dabei 

auf der in [1] vorgestellten »query«- 

Funktion aufbauen und als Seiteneffekt 

eine Methode aufzeigen, wie man in einer 

Mod-Perl-Anwendung zeitnah feststellen 

kann, wenn der Browser die Verbindung 

beendet. 

Die Beispiele in diesem Artikel wurden 

mit PostgreSQL 8.4, einem Apache aus 

der 2.2-Serie und Perl 5.12 erstellt – alles 

schon gut abgehangene Software. Sie 

brauchen also nicht die neueste Distribution. 

Mod-Perl sollte mindestens in 

Version 2.0.5 vorliegen. Als MPM des 

HTTPD kommt »prefork« zum Einsatz. 

Was sind Notifikationen? 

Notifikationen sind Meldungen, die von 

einem Client der Datenbank zum anderen 

geschickt werden können. Sie sind 

asynchron in dem Sinn, dass der Empfänger 

nicht genau weiß, zu welchem Zeitpunkt 

der Sender die Meldung schickte. 

Das einzige, was Empfänger und Sender 

wissen müssen, um über eine Notifikation 

zu kommunizieren, ist ihr Name. 

Empfänger müssen sich registrieren und 

dabei den Namen angeben, den Sender 

beim Abschicken verwenden. 

Ähnlich zu Signalen unter Unix/Linux 

muss die Datenbank nicht alle gesen- 



Programmieren 

deten Notifikationen einzeln zustellen. 

Angenommen, ein Empfänger hat sich 

für die Notifikation »A« registriert. Nun 

schickt ein Sender in schneller Folge 

mehrere Notifikationen »A«. Dann stellt 

die Datenbank mindestens einmal »A« 

zu, aber nicht unbedingt alle. Senden 

mehrere Datenbankprozesse »A«, wird 

von jedem Prozess mindestens ein »A« 

zugestellt. Seit PostgreSQL Version 9 können 

Notifikationen neben dem Namen 

zusätzlichen Inhalt übertragen. Hier stellt 

die Datenbank sicher, dass von jedem 

Senderprozess mindestens einmal die 

Kombination aus Name und Inhalt zugestellt 

wird. 

Notifikationen sind aber auch synchron 

in dem Sinn, dass sie, egal zu welchem 

Zeitpunkt in einer Transaktion versendet, 

erst beim Commit wirklich zugestellt 

werden. Empfänger erhalten Notifikationen 

nur außerhalb von Transaktionen. 

Dies demonstriert das in Listing 1 abgedruckte 

Skript. 

Nach dem Öffnen der Datenbankverbindung 

registriert es sich mit dem 

»LISTEN«-Kommando in Zeile 7 für die 

beiden Notifikationen »foo« und »bar«. 

In Zeile 10 wartet das Programm auf Input 

von der Datenbank. Eigentlich läuft 

gar keine Abfrage. Wie kann dann Input 

auftreten? Sobald jedoch ein anderer Datenbankprozess 

eine Notifikation schickt, 

wird sie vom Server gesendet. Daher 

kann also Input ankommen. 

Mit der »pg_notifies«-Funktion in Zeile 12 

werden dann alle bis dahin aufgelaufenen 

Notifikationen gelesen. Die Funktion 

liefert eine Notifikation pro Aufruf, deshalb 

die innere While-Schleife. Die Notifikation 

selbst ist ein Paar aus dem Namen 

und dem Absender-PID. Für Postgres ab 

Version 9 können hier noch Nutzdaten 

auftauchen. 

Das Skript wird auf der Kommandozeile 

gestartet und liefert zunächst keinen Output. 

Mit dem zu Postgres gehörenden 

Kommandozeilenprogramm »psql« versenden 

wir nun ein paar Notifikationen: 

chat=> notify foo; notify bar; U 

notify foo; notify foo; notify bax; 

NOTIFY 

NOTIFY 

NOTIFY 

NOTIFY 

NOTIFY 

chat=> 

Es werden fünf Benachrichtigungen versandt: 

einmal »bar«, dreimal »foo« und 

einmal »bax«. Obwohl es keinen Empfänger 

für »bax« gibt, ist das Versenden kein 

Fehler. Die Notifikation geht in diesem 

Fall einfach verloren. 

Tue Apr 30 14:12:41 2013: notifications 

foo 12015 


bar 12015 


foo 12015 


foo 12015 

Bemerkenswert hier ist, dass jede Notifikation 

einzeln zugestellt wird. Jeder 

»pg_notifies«-Aufruf liefert genau eine 

Nachricht. Dass das kein Widerspruch 

zu meiner obigen Aussage ist, zeigt das 

Experiment in Listing 2. Hier werden 

Listing 2: Test 

01 chat=> begin; 

02 BEGIN 

03 chat=> notify foo; notify bar; 

notify foo; notify foo; notify bax; 

04 NOTIFY 

05 NOTIFY 

06 NOTIFY 

07 NOTIFY 

08 NOTIFY 

09 chat=> select clock_timestamp(); 

10 clock_timestamp 

11 ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 

Listing 3: »recv1.pl« 

01 use common::sense; 

02 use DBI; 

03 use IO::Select; 

04 

Listing 1: »recv0.pl« 


02 use DBI; 

03 use IO::Select; 

04 

05 my $db=DBI‐>connect('dbi:Pg:dbname=chat', 

'ipp', 

06 undef, {RaiseError=>1}); 

07 $db‐>do('LISTEN '.$_) for (qw/foo bar/); 

05 my $db=DBI‐>connect('dbi:Pg:dbname=chat', 

'ipp', 

06 undef, {RaiseError=>1}); 

07 $db‐>do('LISTEN '.$_) for (qw/foo bar/); 

08 

09 my $sel=IO::Select‐>new($db‐>{pg_socket}); 

10 

11 $db‐>do('BEGIN'); 

12 warn localtime().": start transaction\n"; 

die Notifikationen in einer Transaktion 

versandt. Zu Beginn wird zusätzlich die 

aktuelle Zeit ausgegeben und nach dem 

Versand fünf Sekunden gewartet. 

Sammelzustellung 

Der Empfänger gibt jetzt nur noch folgende 

Zeilen aus: 


bar 12015 

foo 12015 

Die drei Foo-Notifikationen sind zu einer 

zusammengefasst. Außerdem beträgt die 

Zeitdifferenz zwischen dem Absenden 

und dem Empfang deutlich mehr als 

fünf Sekunden. Das heißt, die Notifikationen 

werden erst beim »COMMIT« der 

Transaktion wirklich verschickt. Wird die 

08 

09 my $sel=IO::Select‐>new($db‐>{pg_socket}); 

10 while ($sel‐>can_read) { 

11 warn localtime().": notifications\n"; 

12 while (my $note=$db‐>pg_notifies) { 

13 warn " @$note\n"; 

14 } 

15 } 

12 2013‐04‐30 14:24:16.067244+02 

13 (1 row) 

14 

15 chat=> select pg_sleep(5); 

16 pg_sleep 

17 ‐‐‐‐‐‐‐‐‐‐ 

18 

19 (1 row) 

20 

21 chat=> end; 

22 COMMIT 

23 chat=> 

13 while (1) { 

14 if( $sel‐>can_read(10) ) { 

15 warn localtime().": notifications\n"; 

16 while (my $note=$db‐>pg_notifies) { 

17 warn " @$note\n"; 

18 } 

19 $db‐>disconnect; 

20 exit 0; 

21 } else { 

22 warn localtime().": finish transaction\n"; 

23 $db‐>do('COMMIT'); 

24 } 

25 } 


Admin 


95

Programmieren 


Transaktion abgebrochen (»ROLLBACK«), 

kommen keine Notifikationen an. 

Listing 3 demonstriert dies. Zeile 12 startet 

eine Transaktion und gibt anschließend 

einen Zeitstempel aus. Nun wartet 

das Programm maximal zehn Sekunden 

auf Input von der Datenbank. Im Fall 

eines Timeouts wird die Transaktion beendet 

(Zeile 23) und wieder in Zeile 14 

gewartet. Kommt Input an, werden die 

Notifikationen ausgelesen und das Programm 

beendet. 

Kurz nach dem Start des Programms 

sende ich mit »psql« eine Notifikation 

und gebe die aktuelle Zeit aus: 

chat=> notify foo; select clock_ 

timestamp(); 

NOTIFY 

clock_timestamp 

‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 

2013‐04‐30 14:46:18.638144+02 

Das Skript gibt folgendes aus: 

Tue Apr 30 14:46:16 2013: start transaction 

Tue Apr 30 14:46:26 2013: finish transaction 


foo 12015 

Listing 4: SQL-Schema 

01 create table chat_rooms ( 

02 id serial primary key, 

03 name text not null 

04 ); 

05 

06 create table chat_msgs ( 

07 id serial primary key, 

08 room int references chat_rooms(id) 

09 on update restrict 

10 on delete cascade, 

11 tm timestamp default now() not null, 

12 author text not null, 

13 msg text not null 

14 ); 

Listing 5: Trigger 

01 create or replace function chat_tg_fn() returns 

trigger as $CODE$ 

02 declare 

03 room text; 

04 begin 

05 select into room name from chat_rooms where id=NEW. 

room; 

06 execute 'notify "r_' || room || '"'; 

07 return null; 

08 end; 

09 $CODE$ language plpgsql; 

10 

11 create trigger chat_tg after insert on chat_msgs for 

each row 

12 execute procedure chat_tg_fn(); 

Der zeitliche Ablauf ist somit folgender: 

n 14:46:16 Transaktion startet, 

n 14:46:18 Notifikation wird gesendet, 

n 14:46:26 Transaktion endet und Notifikation 

wird empfangen. 

Transaktionen können lange dauern. In 

realen Anwendungen ist also die Frage zu 

stellen, ob eine Datenbankverbindung für 

normale SQL-Kommandos und Notifikationen 

gemeinsam benutzt werden kann, 

oder ob es nicht besser wäre, mit zwei 

Verbindungen zu arbeiten. 

Ein paar Tabellen 

Mit dem Wissen über Notifikationen 

können wir nun den Chat-Server planen. 

Wegen der Länge der Listings sind sie 

hier nur auszugsweise wiedergegeben. 

Das vollständige Paket kann unter [3] 

heruntergeladen werden. 

Um das Beispiel einfach zu halten, verzichtet 

es auf jegliche Benutzerverwaltung. 

Jeder Teilnehmer kann jeden Chat- 

Raum betreten und unter einer beliebigen 

Identität teilnehmen. Auch können mehrere 

Benutzer gleichzeitig unter demselben 

Namen auftreten. Chat-Räume entstehen 

nach Bedarf. 

In der Datenbank sind zwei Tabellen vorgesehen, 

eine für die Chat-Räume und 

eine für die Nachrichten (Listing 4). 

Der für das Thema interessante Teil ist jedoch 

der in Listing 5 dargestellte Trigger. 

In den Zeilen 11 und 12 wird der Trigger 

erzeugt. Er feuert bei jedem »INSERT« in 

die »chat_msgs«-Tabelle und führt dabei 

die Funktion »chat_tg_fn« aus. Diese ermittelt 

den Namen des Chat-Raums und 

bildet daraus die Notifikation 

r_RAUMNAME 

Zum Test lässt sich das Programm in 

Listing 1 so modifizieren, dass es auf »r_ 

foo« und »r_bar« reagiert. Dann erzeugt 

man mit »psql« einen Chat-Raum »foo« 

und fügt als Nächstes eine Mitteilung 

ein. Das Skript meldet dann eine »r_foo«- 

Notifikation. 

Gerüstbau 

Datenbankseitig war es das schon. Listing 

6 enthält das Gerüst des Perl-Moduls 

für den Chat-Server. Der Einstieg 

ist die Handler-Funktion am Ende. Um 

es einfach zu halten, kommuniziert die 

HTML-Seite mit dem Modul nur über 

AJAX und benutzt dabei die HTTP- 

Methode »POST«. Parameter werden in 

JSON kodiert übertragen. Die Antwort 

wird auch in JSON erwartet. 

Daher liest Zeile 75 den Request-Body 

ein, den Zeile 76 dekodiert. Das Resultat 

landet in der globalen Variable »$data«. 

War das erfolgreich, wird die Verbindung 

zur Datenbank aufgebaut und auch in 

einer globalen Variable gespeichert. Alle 

drei globalen Variablen, die Anfrage »$r«, 

»$data« und die Datenbankverbindung 

»$db«, werden lokalisiert. Das heißt, 

sie werden automatisch zu »undef« zurückgesetzt, 

sobald das Programm die 

Handler-Funktion verlässt, auch wenn 

das mittels »die« in einer Unterfunktion 

passiert. 

Jede Anfrage muss den Parameter »action« 

enthalten. Er gibt an, was eigentlich 

gemacht werden soll. Der Hash »%actions« 

in Zeile 56 verzweigt dann entsprechend 

des Parameters. Im Moment kennt 

das Modul nur die Aktion »test«. 

Diese Architektur widerspricht dem REST- 

Paradigma. In der Praxis gibt es sicher 

einige Aktionen, die idempotent sind und 

daher mittels GET und über eine separate 

URL ansprechbar sein sollten. Aber das 

Ganze ist nur ein Beispiel. 

Der für das Thema interessante Teil spielt 

sich in der Query-Funktion ab. Hier wird 

wie in [1] »AnyEvent« benutzt. Der 

Event-Loop ist also der »recv«-Aufruf auf 

der Condition-Variable in Zeile 50. Hier 

wird gewartet, bis eine der folgenden 

Bedingungen erfüllt ist: 

n die Anfrage ist beendet (Zeile 35), 

n die Anfrage hat ihr Zeitlimit überschritten 

(Zeile 34), 

n ein SIGINT oder SIGTERM ist eingetroffen 

(Zeile 45). 

Nun unterscheidet sich das Umfeld für 

einen Mod-Perl-Handler etwas von einem 

Mod-CGI-Skript. Das SIGTERM hat hier 

eine komplett andere Bedeutung. Es tritt 

nicht auf, wenn der Webserver meint, die 

Anfrage dauere zu lange, sondern nur, 

wenn er sich beenden will. Daher bricht 

der Signal-Handler »$cancel_and_terminate« 

nicht nur die SQL-Anfrage ab, sondern 

setzt mit »child_terminate« auch ein 

Flag, das anzeigt, dass der Prozess enden 

soll, sobald die Anfrage abgearbeitet ist. 

Auch treten in Mod-Perl-Handlern keine 

Timeouts auf. Wie in [1] ausgeführt, be- 



Programmieren 

zieht sich der Timeout des Webservers 

auf die Überwachung von I/O-Strömen. 

Während des Query-Aufrufs gibt es aber 

keinen Datenaustausch mit dem Browser 

– das ist der einzige Kanal, den der 

HTTPD kennt. Von der Datenbankverbindung 

hat er keine Ahnung. 

Eigener Timeout 

Das heißt, man tun gut daran, selbst einen 

Timeout zu implementieren. Das ist 

zum Glück sehr einfach. Es gilt nur zu 

beachten, dass man »AE::now_update« 

vor dem Erzeugen der Condition-Variable 

aufruft. Den Watcher für den Timeout 

erzeugt Zeile 34. 

Wie in [1] erläutert, müssen die Signale 

TERM und INT von der Aktivierung der 

Signal-Handler in den Zeilen 44 bis 46 bis 

zum Ende der »execute«-Anweisung blockiert 

werden, um eine Race-Condition 

zu vermeiden. Nun kann es aber pas- 

Abbildung 1: Ein erster Test auf der Kommandozeile zeigt, dass der Webserver JSON zurückgibt. 

sieren, dass »execute« mit einer Exception 

abgebrochen wird, um die man sich 

normalerweise nicht weiter kümmern 

müsste, weil Mod-Perl daraus automatisch 

eine Antwort mit dem HTTP-Code 

500 (SERVER ERROR) macht. Die Signalmaske 

des Prozesses ist jedoch eine 

globale Eigenschaft, die zurückgesetzt 

werden muss. Sonst stockt der Webserver 

beim Herunterfahren. 

Für solche Fälle ist das Guard-Modul 

hilfreich. In Zeile 40 speichert die Variable 

»$guard« ein Objekt, bei dessen 

Zerstörung der übergebene Code-Block 

ausgeführt und damit die Signalmaske 

zurückgesetzt wird. In Zeile 48 passiert 

das explizit als Teil des Programms. Wenn 

jedoch der Execute-Aufruf abbricht, wird 

dieser Code nicht ausgeführt. Die »$guard‐«Variable 

wird von Perl aber automatisch 

zerstört. Als Nebeneffekt wird die 

Signalmaske wiederhergestellt. 

Und: Action! 

Jetzt, nachdem das Gerüst steht, können 

Aktionen eingefügt werden. Im Moment 

kennt die Anwendung nur »test«. Zudem 

ist sie eigentlich nur ein Platzhalter und 

hat mit der Anwendung nichts zu tun. 

Zum Testen des Gerüsts eignet sie sich 

aber gut. 

E 

Listing 6: Das Gerüst des Perl-Moduls 

01 package Chat; 

02 


04 use Apache2::RequestRec (); 

05 use Apache2::RequestUtil (); 

06 use Apache2::RequestIO (); 

07 use Apache2::Const ‐compile=>qw/OK NOT_FOUND 

08 SERVER_ERROR/; 

09 use JSON::XS (); 

10 use DBI; 

11 use DBD::Pg qw/:async/; 

12 use AnyEvent; 

13 use Guard; 

14 use POSIX qw/SIGTERM SIGINT SIG_BLOCK SIG_ 

UNBLOCK/; 

15 

16 our ($r, $db, $data); 

17 our $query_timeout//=3; 

18 

19 sub query { 

20 my $sql=pop; 

21 my $stmt=$db‐>prepare($sql, {pg_async=>PG_ 

ASYNC}); 

22 

23 AE::now_update; 

24 my $done=AE::cv; 

25 my $cancel=sub { 

26 $db‐>pg_cancel if $db‐>{pg_async_ 

status}==1; 

27 $done‐>send; 

28 }; 

29 my $cancel_and_terminate=sub { 

30 $cancel‐>(); 

31 $r‐>child_terminate; 

32 }; 

33 

34 my $tm_w=AE::timer $query_timeout, 0, 

$cancel; 

35 my $pg_w=AE::io $db‐>{pg_socket}, 0, sub { 

36 $db‐>pg_ready and $done‐>send; 

37 }; 

38 

39 my $sigblock=POSIX::SigSet‐>new(SIGTERM, 

SIGINT); 

40 my $guard=guard { 

41 POSIX::sigprocmask SIG_UNBLOCK, $sigblock; 

42 }; 

43 POSIX::sigprocmask SIG_BLOCK, $sigblock; 

44 my @sig_w=map { 

45 AE::signal $_, $cancel_and_terminate; 

46 } qw/TERM INT/; 

47 $stmt‐>execute(@_); 

48 undef $guard; 

49 

50 $done‐>recv; 

51 

52 return $db‐>{pg_async_status}==1 

53 ? ($db‐>pg_result, $stmt) : (); 

54 } 

55 

56 my %actions= 

57 ( 

58 test=>sub { 

59 my ($rc, $stmt)=query @{$data‐>{param}}, 

$data‐>{q}; 

60 return Apache2::Const::SERVER_ERROR 

unless $rc; 

61 

62 my @l; 

63 push @l, $_ while $_=$stmt‐>fetchrow_ 

hashref; 

64 $r‐>content_type('text/json'); 

65 $r‐>print(JSON::XS::encode_ 

json(+{result=>\@l})); 

66 

67 return Apache2::Const::OK; 

68 }, 

69 ); 

70 

71 sub handler { 

72 local $r=$_[0]; 

73 

74 my $buf=''; 

75 1 while( 0read($buf, 16000, length 

$buf) ); 

76 local $data=eval{ JSON::XS::decode_json 

$buf }; 

77 return Apache2::Const::NOT_FOUND 

78 unless('HASH' eq ref $data and 

79 my $act=$actions{$data‐>{action} 

}); 

80 

81 local $db=DBI‐>connect('dbi:Pg:dbname=chat, 

'ipp', undef, 

82 {RaiseError=>1, pg_ 

enable_utf8=>1}); 

83 return $act‐>(); 

84 } 

85 

86 1; 


Admin 


97

Programmieren 


Doch als erstes muss das Modul noch in 

der »httpd.conf« eingebunden werden. 

Neben der »LoadModule«-Anweisung, 

um Mod-Perl zu laden, ist dazu Folgendes 

nötig: 

PerlModule Chat 

 

SetHandler modperl 

PerlResponseHandler Chat 

 

Außerdem muss das Chat-Modul im Perl- 

Suchpfad gefunden werden (siehe auch 

Kasten „Mod-Perl – eine Einführung“). 

Die Test-Aktion erwartet zwei Parameter: 

eine SQL-Anweisung »q« und eine 

Liste mit Bind-Parametern »param«. 

Abbildung 1 zeigt einen solchen Aufruf 

mit »curl«. Die Option »‐d« erzeugt eine 

POST-Anfrage und übergibt gleichzeitig 

den Request-Body. Normale CGI-Skripte 

erwarten ihre Parameter oft URL-kodiert. 

Dieses erwartet jedoch JSON. Der Javascript-Teil 

im Browser wird dadurch 

einfacher. 

Sonderfälle simulieren 

Der Aufruf in Abbildung 1 zeigt ein erfolgreich 

beendetes SQL-Kommando. Viel 

wichtiger ist es aber, verschiedene vom 

Normalzustand abweichende Zustände 

zu provozieren. Mit dem Kommando 

»select pg_sleep(10)« könnte man beispielsweise 

einen Timeout in der Query- 

Funktion erzeugen. Zeile 17 stellt den 

Timeout auf drei Sekunden ein. Wenn 

ein SQL-Kommando nun länger als drei 

Sekunden dauert, wird es mit »$cancel« 

abgebrochen, und die Query-Funktion 

gibt die leere Liste zurück. In Zeile 60 

wird daraus eine HTTP-Antwort mit dem 

Code 500 (SERVER ERROR) gemacht. 

/chat.html 

enterroom 

enterroom 

listen 

listen 

Browser 1 Server 

Browser 2 

listen 

listen 

Abbildung 2: Die Grundstruktur der realisierten Chat-Anwendung. 

Der Curl-Aufruf mit dem Parameter 

»{"action":"test","q":"select pg_ 

sleep(10)"}« müsste also nach drei Sekunden 

beendet sein und einen Server- 

Error liefern. 

Weiterhin sollte man testen, was passiert, 

wenn eine ungültige SQL-Anweisung 

übergeben wird. Dann bricht der 

Execute-Aufruf in Zeile 47 ab und Curl 

müsste sofort einen Fehler 500 liefern. 

Dann könnte man über »/proc/$PID/ 

status« prüfen, ob die Signalmaske des 

Apache-Prozesses wieder ordentlich zurückgesetzt 

wurde. Einfacher ist es aber, 

den Server zu stoppen. Er muss sich wie 

gewohnt beenden lassen. Wenn die Signalmaske 

nicht zurückgesetzt ist, würde 

er eine ganze Weile brauchen und berichten, 

dass er einigen Prozessen mehrmals 

ein SIGTERM und schließlich ein SIG- 

KILL geschickt hat. 

Wenn ein zeitaufwendiges SQL-Kommando 

läuft und der Webserver gestoppt 

wird, sollte das Kommando abgebrochen 

werden. Das kann man prüfen, indem der 

Timeout zunächst auf einen großen Wert, 

zum Beispiel 300 Sekunden, gesetzt wird. 

/chat.html 

sendmsg 

listen 

listen 

Dann startet man das SQL-Kommando 

»select pg_sleep(50)« und stoppt den 

Webserver. Auf dem Datenbank-Server 

muss der zum SELECT zugehörige Prozess 

verschwinden. Bei geeigneten Logging-Einstellungen 

taucht im Log der 

Datenbank folgendes auf: 

ERROR: canceling statement due to user U 

request 

STATEMENT: select pg_sleep(50) 

Nach dem Test des Gerüsts lassen sich 

weitere Aktionen hinzufügen. Die Chat- 

Anwendung kommt mit drei Aktionen 

aus, die ich »enterroom«, »listen« und 

»sendmsg« getauft habe. 

Chat-Ablauf 

Zeit 

Abbildung 2 zeigt den zeitlichen Ablauf 

während eines Chats. Als erstes 

wird ganz normal die HTML-Seite geladen. 

Alle weiteren Anfragen werden per 

XMLHttpRequest in Javascript erzeugt. 

Daher kann der Request-Body auch sehr 

einfach in JSON kodiert werden. Betritt 

der Benutzer einen Chat-Raum, wird »en- 

Listing 7: Die Listen-Aktion 

01 sub wait_for_notification { 

02 my ($n, $cv, $pg_w, $cl_w, $cl_fd)=(0); 

03 

04 $pg_w=AE::io $db‐>{pg_socket}, 0, sub { 

05 $cv‐>send; 

06 }; 

07 $cl_fd=$r‐>connection 

08 ‐>client_socket 

09 ‐>fileno; 

10 $cl_w=AE::io $cl_fd, 0, sub { 

11 $n=‐1; 

12 $cv‐>send; 

13 }; 

14 

15 $n=1 while $db‐>pg_notifies; 

16 return 1 if $n; 

17 

18 while( $n==0 ) { 

19 $cv=AE::cv; $cv‐>recv; 

20 return if $n==‐1; 

21 $n=1 while $db‐>pg_notifies; 

22 } 

23 return 1; 

24 } 

25 

26 my %actions= 

27 ( 

28 ... 

29 listen=>sub { 

30 $_=check_room and return $_; 

31 

32 (undef, my $stmt)= 

33 query 'LISTEN "r_'.$data‐>{room}.'"'; 

34 $stmt and $stmt‐>finish; 

35 

36 while( reply_messages()


Programmieren 

terroom« aufgerufen. Als Antwort liefert 

der Server die Liste der Mitteilungen in 

dem gewählten Raum. Der Browser zeigt 

diese an und sendet sofort eine »listen«- 

Anfrage für den Raum. Dieser Aufruf 

kehrt erst zurück, wenn neue Mitteilungen 

eingetroffen sind. Will ein Browser 

eine Nachricht senden, benutzt er die 

Aktion »sendmsg«. Von der Chat-Anwendung 

wird daraus ein INSERT-Kommando 

gemacht. Der Datenbank-Trigger löst aus 

und schickt eine Notifikation. Die Empfänger 

lesen die neue Nachricht aus der 

Datenbank, senden sie an den Browser 

und beenden damit ihre »listen«-Anfrage. 

Der Browser zeigt sie an und sendet eine 

neue »listen«-Anfrage. 

Fortlaufende Zähler 

Jede Nachricht besitzt eine ID, die in 

aufsteigender Reihenfolge von der Datenbank 

beim »INSERT« erzeugt (Datentyp 

»SERIAL«) wird. Die Anwendung geht 

und schickt sie dem Browser. Die Anzahl 

wird zurückgegeben. Liefert die Funktion 

0, also keine neuen Nachrichten, wird 

»wait_for_notification« aufgerufen. Diese 

Funktion ist ähnlich zu »query« aufgedavon 

aus, dass dieser Zähler 

nicht überlaufen kann. Beim 

Betreten eines Chat-Raumes 

werden die Nachrichten und 

deren IDs übertragen. Der 

Browser merkt sich die höchsten 

IDs. Diese wird der Listen- 

Aktion als Parameter mitgegeben. 

Diese Aktion kann also 

interpretiert werden als: „Gib 

mir alle Nachrichten im Raum 

mit einer ID größer als N oder 

warte auf neue Nachrichten, 

falls es keine solchen gibt!“ 

Listing 7 zeigt die relevanten 

Teile der Listen-Aktion. Nach 

Prüfung der Parameter wird in 

Zeile 33 die SQL-Operation 

LISTEN r_RAUMNAME 

ausgeführt. Damit hat das Programm sich 

als Empfänger für Notifikationen in dem 

Raum registriert. »reply_messages« in 

Zeile 36 sucht nach neuen Nachrichten 

Abbildung 3: Das Resultat: zwei Chat-Fenster im Browser mit 

PostgreSQL als Backend. 


Admin 


99

Programmieren 


baut. Sie kehrt in zwei Fällen zurück: 

wenn Notifikationen eingetroffen sind 

und wenn der Watcher in Zeile 10 aktiviert 

wurde. Der Event-Loop ist wieder 

mit einer Condition-Variable in Zeile 19 

implementiert. 

Der verschwundene 

Browser 

Neu an der Funktion sind eigentlich nur 

die Zeilen 7 bis 13. Hier wird die TCP- 

Verbindung zum Browser überwacht. 

Das ist nötig, denn im Prinzip kann die 

Aktion unendlich lange auf eine Notifikation 

warten. Wenn der Benutzer nun 

das Fenster schließt oder den Rechner 

ausschaltet, muss das Skript das merken, 

sonst werden die verwendeten Ressourcen 

nicht freigegeben. 

In Zeile 7 wird dazu zunächst der Dateideskriptor 

der Verbindung zum Browser 

ermittelt. Der Watcher wartet dann, dass 

der Socket lesbar wird. Das kann zwei 

Dinge bedeuten: Entweder ist die nächste 

Mod-Perl – eine Einführung 

Mod-Perl ist ein in den Apache-HTTPD eingebetteter 

Perl-Interpreter. Im Gegensatz zu mit 

Mod-CGI eingebundenen Skripten wird der Interpreter 

also nicht für jede Anfrage neu gestartet. 

Im Unterschied zu Techniken wie FastCGI oder 

Tomcat gibt es bei Mod-Perl kein Backend, dem 

die Anfrage vom Webserver übermittelt wird. 

Der Perl-Interpreter läuft im selben Prozess. 

Das Perl-Programm hat daher direkten Zugriff 

auf alle Ressourcen des Webservers, also auch 

auf die TCP-Verbindung zum Browser. Es gibt 

mehrere Wege, einer Anfrage eigenen Perl-Code 

zuzuordnen. Die direkteste ist der sogenannte 

»PerlResponseHandler«. Dazu schreibt man ein 

gewöhnliches Perl-Modul und implementiert darin 

eine Funktion mit dem Namen »handler«. 

Diese Funktion wird dann vom Webserver mit 

einem Parameter aufgerufen, der die Anfrage 

repräsentiert. 

Ein einfaches Hello-World sieht wie folgt aus: 

package Hello::World; 

use Apache2::RequestRec (); 

use Apache2::RequestIO (); 

use Apache2::Const ‐compile=>qw/OK/; 

sub handler { 

my ($r)=@_; 

$r‐>content_type('text/plain'); 

$r‐>print("hello world\n"); 

Anfrage schon in der Pipeline oder es 

kann ein End-of-File gelesen werden. 

HTTP/1.1 erlaubt zwar, Folge-Anfragen 

in einen Socket zu schreiben, ohne auf 

das Resultat der aktuellen Anfrage zu 

warten, die Chat-Anwendung macht das 

aber nicht. 

Wenn der Socket lesbar wird, kann das 

also nur eines bedeuten: Der Browser 

hat die Verbindung geschlossen. 

»wait_for_notification« gibt daraufhin in 

Zeile 20 die leere Liste zurück. Das führt 

in Zeile 37 zum Beenden der Anfrage 

mit dem HTTP-Code 500. Hier könnte 

man einen beliebigen Code benutzen, 

der nur in der Logdatei erscheint. Der 

Browser ist zu diesem Zeitpunkt schon 

verschwunden. 

Die Query-Funktion macht recht viel 

Wind um Signale und Timeouts. Müsste 

»wait_for_notification« nicht auch darauf 

achten? Ein Timeout wäre möglicherweise 

sinnvoll, wenn man sich nicht darauf verlassen 

kann, dass das Schließen der TCP- 

Verbindung seitens des Browsers auch 

return Apache2::Const::OK; 

} 

1; 

Das Modul installiert man im Suchpfad von Perl 

und bindet es in die »httpd.conf« ein: 

LoadModule perl_module libexec/mod_perl.so 

PerlModule Hello::World 

 

SetHandler modperl 

PerlResponseHandler Hello::World 

 

Der Pfad in der LoadModule-Zeile muss eventuell 

angepasst werden. 

Wollen Sie das Modul in einem separaten Suchpfad 

installieren, so kann dieser dem Perl-Interpreter 

entweder beim Start des Webservers 

über die Umgebungsvariable »PERL5LIB« oder 

mittels der Anweisung »PerlSwitches« in der 

»httpd.conf« übergeben werden. 

Beispiel: 

PerlSwitches ‐I/home/ich/mein/modperl 

Nach einem Restart des Webservers kann das 

Modul zum Beispiel mittels »curl« ausprobiert 

werden: 

$ curl http://localhost/hello‐world 

hello world 

Mehr Informationen zu Mod-Perl sind unter [2] 

zu finden. 

wirklich bemerkt wird. Signale werden 

von »query« nur abgefangen, um beim 

Stoppen des Webservers länger dauernde 

Datenbankabfragen zu beenden. Während 

das Programm auf Notifikationen 

wartet, läuft aber keine Abfrage. Hier Arbeit 

zu investieren, hat also keinen Sinn. 

Es wäre jedoch wahrscheinlich sinnvoll, 

die Prüfung auf den verschwundenen 

Browser auch in die Query-Funktion zu 

übernehmen. 

Schlussbemerkungen 

Die vorgestellte Anwendung ist ein Beispiel, 

wie mit Notifikationen die permanente 

Abfrage eines Zustands von der 

Datenbank vermieden werden kann. Für 

eine Chat-Anwendung wird hier jedoch 

mit Kanonen auf Spatzen geschossen, 

denn jeder Client belegt auf dem Webserver 

einen Worker-Prozess und zusätzlich 

einen Prozess auf dem Datenbankserver. 

Das lässt sich mit Techniken wie in [4] 

vorgestellt deutlich verbessern. 

Und wie sieht es mit anderen Datenbanken 

aus? Oracle und Microsoft SQL Server 

haben meines Wissens Funktionen, 

mit denen „tue etwas, sobald sich ein 

bestimmter Zustand einstellt“ abgebildet 

werden kann. Aber MySQL kann es meines 

Wissens nicht. (ofr) 

n 

Infos 

[1] Torsten Förtsch, Ausgefeilt, PostgreSQL 

asynchron, ADMIN-Magazin 04/2013, S. 110: 

[http:// www. admin‐magazin. de/ Das‐Heft/ 

2013/ 04/ PostgreSQL‐asynchron] 

[2] Mod-Perl: [http:// perl. apache. org/] 

[3] Download der Chat-Anwendung: 

[ftp://ftp.admin-magazin.de/downloads/ 

listings/2013/05] 

[4] HTTP-Verbindung an einen anderen Prozess 

weiterreichen: [http:// foertsch. name/ 

ModPerl‐Tricks/ req‐hand‐over. shtml] 

Der Autor 

Dipl.-Inf. Torsten Förtsch [http:// foertsch. name/] 

bearbeitet Projekte für seine Kunden im In- und 

Ausland. Als Freiberufler 

programmiert und betreut 

er Webserver. Mit Perl beschäftigt 

er sich seit 1998. In 

seiner Freizeit arbeitet er an 

Mod-Perl und behebt Bugs, 

wo immer er welche findet. 


Sonderteil 

Auf der folgenden Seite startet der regelmäßige 

FreeX-Sonderteil des ADMIN-Magazins. Hier finden 

Sie Know-how-Artikel und Workshops von erfahrenen 

Autoren aus der langen Tradition der FreeX. 

Capsicum.......................... 102 

Sicheres Sandboxing und fein granulare 

Rechtevergabe unter FreeBSD 9. 

Netberry .......................... 108 

Mal was anderes: NetBSD statt Linux auf dem 

Rasp berry Pi. Allerdings braucht das Projekt 

einiges an Vorbereitung. 

© yewkeo, 123RF 


Admin 


101

Capsicum 

© Krzysztof Slusarczyk, 123RF 

Capsicum – Mehr Sicherheit für FreeBSD 

Scharf gewürzt 

Applikationen wie Webbrowser öffnen durch teilweise nachlässige Programmierung Sicherheitslücken und 

gefährden dann das ganze System. Capsicum bietet als Abhilfe neben einer geschützten Sandbox auch die Möglichkeit 

der fein granulierten Rechtevergabe. Jürgen Dankoweit 

Administratoren treibt es in schöner Regelmäßigkeit 

den Schweiß auf die Stirn, 

wenn in Security Bulletins wieder einmal 

erläutert wird, dass Schadcode für die 

verwendeten Programme kursiert. Betroffen 

sind Webbrowser, E-Mail-Programme, 

Archivierungstools und sogar Office-Pakete. 

Es ist nicht (nur) die Nachlässigkeit 

bei der Verwendung von Bibliotheken, 

die es Eindringlingen erleichtert, Schadcode 

auszuführen, sondern auch der gezielte 

Angriff auf fehlerhafte Anwendungen. 

Mit den unter FreeBSD bekannten 

Mechanismen wie Chroot oder Jails ist 

dem nur schwer beizukommen. 

Abhilfe schafft das Einsperren von Anwendungen 

in eine Sandbox, eine Umgebung, 

die nur extrem limitierte Resourcen 

bereitstellt. Da FreeBSD bis zur 

Version 8 einen solchen Mechanismus 

nicht vorsieht, wurde mit FreeBSD 9 

die Umgebung Capsicum (lateinisch für 

Chili) geschaffen. Sie bietet neben einer 

geschützten Umgebung (Sandbox), aus 

der eine Anwendungen nicht ausbrechen 

kann, auch die Möglichkeit der fein granulierten 

Rechtevergabe. 

Klassische Rechte 

Traditionell besitzt FreeBSD wie Linux 

und andere Unix-Systeme ein sehr simples 

Rechtesystem. Der Grund dafür ist 

in der Geschichte der Unix-Systeme zu 

suchen, die ursprünglich nicht für einen 

im weltweiten Internet vernetzten Desktop 

konzipiert waren. Daraus entstanden 

hauptsächlich zwei Mechanismen 

der Zugriffskontrolle. Zum einen gibt es 

die Discretionary Access Control (DAC, 

diskrete Zugriffskontrolle), die von der 

Benutzerkennung abhängt. Hierbei wird 

die Entscheidung, ob auf eine Ressource 

zugegriffen werden darf, allein auf der 

Basis der Kennung des Users getroffen. 

Das bedeutet, die Zugriffsrechte für Daten 

werden für jeden Benutzer von einem 

Administrator oder vom Benutzer selbst 

festgelegt. Bestes Beispiel hierfür ist ein 

Home Directory, auf das nur der Benutzer 

Zugriff hat, der es auch besitzt. 

Der Nachteil der Methode zeigt sich am 

Kommando »passwd« zum Ändern des 

Benutzerpassworts. Damit jeder User 

selbst sein Passwort in die Benutzerdatenbank 

eintragen und ändern kann, muss 

das »passwd«-Kommando in die Datei 


Capsicum 

»/etc/passwd« schreiben dürfen. 

Es hat aber nur der User 

Root die Berechtigung, sie zu 

verändern. Vereinfacht dargestellt 

bedient man sich eines 

Tricks und setzt für den Befehl 

»passwd« das SUID-Flag 

und das Kommando wird 

mit Root-Rechten ausgeführt 

und die Änderung an »/etc/ 

passwd« wird durchgeführt. 

Unter Umständen ist dieser 

Mechanismus das Einfallstor 

für Schad-Software. 

MAC-Security 

Der andere Mechanismus zur 

Zugriffskontrolle ist die Mandatory 

Access Control (MAC, 

zwingend erforderliche Zugangskontrolle). 

Hierbei wird im Gegensatz 

zur DAC die Zugriffsberechtigung 

auf Basis eines Regelwerks erteilt. Der 

Nachteil dieser Methode ist aber, dass ein 

solches Regelwerk innerhalb der Anwendung 

definiert werden muss, was einen 

erhöhten Programmieraufwand zur Folge 

hat. Außerdem trägt der Programmierer 

die volle Verantwortung für die Vergabe 

der Berechtigungen. 

Die beiden Arten der Zugriffskontrolle 

wurden in erster Linie dafür entwickelt, 

unerlaubten Zugriff auf Dateien zu reglementieren. 

Der Zugriff auf Speicherbereiche 

oder gar Kontrollstrukturen eines 

Namespace 

Prozesskennung 

(PID) 

Dateipfade 

NFS-File-Handles 

Filessystem- 

Kennungen 

Protokoll- 

Adressen 

Sysctl-MIBs 

SystemV-IPC 

Posix-IPC 

Systemuhren 

Jails 

CPU-Sets 

Tabelle 1: Globaler Namespace des FreeBSD-Kernel 

etc 

httpd 

Hauptprozess: 

HTTP-Daemon 

HTTP-Daemon Apache 

Abbildung 1: Sandboxing mit Apache. 

/ 

www-site1 

Subprozess 1: 

HTTP-Daemon 

in Sandbox 

Kernels werden damit nicht unterbunden. 

Auch wurden die Mechanismen nie 

dafür entwickelt, moderne Desktop-Anwendungen 

wie Webbrowser oder Office- 

Pakete abzusichern. 

Das ist eine kritische Angelegenheit, 

wenn man bedenkt, dass sie aus dubiosen 

Quellen stammende Information 

verarbeiten und darstellen. Mit DAC 

oder MAC lässt sich die Ausführung von 

Schadcode eines Javascripts oder Makro- 

Viruses nur schwer verhindern. 

Der FreeBSD-Kenner wird an dieser Stelle 

einwerfen, dass es Jails gibt, mit denen 

man ebenfalls die Möglichkeit hat, eine 

Sandbox aufzubauen. Das 

ist korrekt, aber der Administrationsaufwand 

und Ressourcen-Verbrauch 

sind doch 

enorm, wenn man für jede 

Anwendung eine Jail erstellt. 

Außerdem löst es nicht das 

Problem, dass Schadcode ein 

System infiltriert. 

Zerkleinert 

Eine andere Möglichkeit besteht 

darin, dass man eine Applikation 

in kleinere Prozesse 

zerlegt, die vom Hauptprozess 

gestartet werden, und diese 

mit besonderen Zugriffsrechten 

ausstattet. 

Abbildung 1 zeigt am Beispiel 

des HTTP-Daemons Apache, 

wie man sich eine sichere Umgebung für 

einen Webserver vorzustellen hat. Wenn 

Apache gestartet wird, hat der Hauptprozess 

zunächst alle Rechte, um auf die 

Konfigurationsdateien und die komplette 

Verzeichnisstruktur zuzugreifen. Außerdem 

werden noch die Sockets erstellt, 

über die Webbrowser die Möglichkeit haben, 

die Webseiten abzurufen. Nachdem 

diese Grundkonfiguration abgeschlossen 

ist, werden Subprozesse gestartet, welche 

die eigentliche Aufgabe des HTTP- 

Daemons übernehmen. Jeder Subprozess 

erhält die Berechtigung, auf das ihm zugeordnete 

Verzeichnis und Ressourcen 

Erklärung 

Unix-Prozesse werden durch eine eindeutige Kennung repräsentiert. PIDs werden beim Starten eines Prozesses zurückgegeben 

und lassen sich zum Debugging, zum Senden von Signalen, Monitoring und zum Ermitteln des aktuellen Status heranziehen. 

Unix-Files liegen in einem globalen, hierarchisch aufgebauten Namespace, der durch DAC und MAC geschützt ist. 

Sowohl NFS-Server als auch der NFS-Client benutzen File-Handles, um Dateien und Verzeichnisse zu identifizieren. Davon macht 

die NFS-Zugriffsverwaltung Gebrauch. 

Damit wird die Zuordnung von Mountpoints zu Pfaden bestimmt. Sie werden benutzt, um einen Zwangs-Unmount vorzunehmen, 

wenn kein Pfad mehr existiert. 

Die Protokoll-Familien benutzen Socket-Adressen, um lokale beziehungsweise entfernte Netzwerkendpunkte zu bezeichnen. Sie 

existieren genauso wie IPv4-Adressen und Ports oder die Sockets im globalen Namensraum. 

Das Sysctl-Verwaltungssystem verwendet sowohl numerische als auch alphanumerische Einträge, um Systemparameter auszulesen 

und zu verändern. 

Message-Queues, Semaphoren und Shared Memory dienen der Kommunikation zwischen Prozessen und werden nach dem 

SystemV-Standard abgewickelt. 

Message-Queues, Semaphoren und Shared Memory dienen der Kommunikation zwischen Prozessen und werden nach dem Posix- 

Standard abgewickelt. 

FreeBSD-Systeme stellen mehrere Schnittstellen zur Verwaltung der Systemuhr bereit. 

Jails als auf FreeBSD basierende Virtualisierung nutzt einen eigenen Namespace als Untermenge des globalen Namespace. 

Zuordnung von CPU-Ressourcen zu Prozessen und Threads. 

data 

www 

www-site2 

Subprozess 2: 

HTTP-Daemon 

in Sandbox 


Admin 


103

Capsicum 

zuzugreifen. Das bedeutet, der Prozess 

läuft in einer Sandbox. 

Um einen in dieser Art und Weise abgesicherten 

HTTP-Daemon zu programmieren, 

muss man einen erheblichen Aufwand 

betreiben. Der Grund liegt darin, 

dass für jedes UNIX-System oder BSD- 

Betriebssystem die Zugriffsmechanismen 

eigens implementiert werden müssen. 

Hot Chili Pepper 

Filedeskriptor 

... 

23 

67 

struct 

file 

Ohne Capsicum 

struct capability 

mask = CAP_READ 

struct 

file 

Unter FreeBSD gibt es mit Capsicum eine 

Lösung für das geschilderte Problem. 

FreeBSD dient hier als Referenzplattform 

nicht nur für die anderen BSD-Systeme, 

sondern auch für andere Unix-Plattformen. 

Im Rahmen des Google Summer of 

Code wurde Capsicum in FreeBSD implementiert. 

Ein besonderes Lob gilt hier 

Pawel Jakub Dawidek (pjd) und seinen 

Kollegen im FreeBSD-Entwicklerteam für 

die Betreuung und Durchführung des 

Projekts. 

Bei der Entwicklung des Capsicum- 

Frameworks hat man sich der oben genannten 

Probleme angenommen und 

neue Sicherheitsmerkmale eingeführt, 

um die Abschottung von Anwendungen 

zu unterstützen. Um die Vorteile von 

Capsicum voll auszuschöpfen, müssen 

entweder – im schlechtesten Fall – Anwendungen 

neu entwickelt oder der Code 

neu strukturiert werden. Letzteres muss 

nicht von Nachteil sein. 

Für die Entwicklung von Capsicum stand 

im Vordergrund, dass bestehende Mechanismen 

der Zugriffskontrolle unverändert 

funktionsfähig bleiben. Ebenso sollten die 

Programmierschnittstellen (APIs) nicht 

verändert werden, damit bestehende 

Software weiterhin ohne Einschränkungen 

funktioniert. Daher erweitert das 

Capsicum-System die Unix-Programmierschnittstellen, 

indem es innerhalb des 

Betriebssystemkerns eigene Funktionen 

implementiert. Um Capsicum in eigenen 

Anwendungen und Betriebssystemwerkzeugen 

zu nutzen, werden die C-Header- 

Files »sys/capability.h«, »libcapsicum.h« 

und die Bibliothek »libcapsicum« bereitgestellt, 

die mit den Kernelerweiterungen 

kommuniziert. 

Um Capsicum zu verstehen, sind einige 

nicht triviale Grundlagen zu erläutern. 

Capsicum kennt den sogenannten Capability-Mode. 

Dabei handelt es sich um 

112 

... 

struct 

file 

ein Flag, das von der Funktion »cap_enter()« 

gesetzt wird. Es zeigt an, dass alle 

Datei- und Speicheroperationen von jetzt 

an stark reglementiert sind. Dieses Flag 

wird an alle Kindprozesse vererbt und 

lässt sich nicht löschen. Prozesse, die 

sich im Capability-Mode befinden, haben 

nur extrem eingeschränkten Zugriff 

auf den Namespace des Kernels (siehe 

Tabelle 1). Zusätzlich werden einige Systemschnittstellen 

geschützt. Dazu gehören 

alle Gerätetreiber, die Zugriff auf den 

physischen Speicher oder PCI-Bus gestatten. 

Auch Kommandos wie »reboot« oder 

»kldload« werden geblockt. 

Systemcalls begrenzt 

struct capability 

mask = 

CAP_READ|CAP_WRITE 

Capsicum-Umgebung 

Der Aufruf von Systemfunktionen ist im 

Capability-Mode ebenfalls reguliert: Einige 

Funktionen, die Zugriff auf den globalen 

Namespace haben, sind nicht mehr 

verfügbar, während andere eingeschränkten 

Zugriff haben. Ein kleines Beispiel 

dafür ist das Kommando »sysctl« beziehungsweise 

dessen Pendant »systctl()« 

in der Programmierbibliothek »libc«: Mit 

dessen Hilfe lässt sich die Art und Weise 

der Speicherbelegung abfragen, es lassen 

sich Netzwerkverbindungen belauschen 

oder Kernelparameter modifizieren. Das 

bietet für potenzielle Angreifer unter Umständen 

eine Angriffs- beziehungsweise 

Abhörmöglichkeit. Um die Sicherheit zu 

erhöhen, wurde der Zugriff nur auf circa 

dreißig Parameter erlaubt – gegenüber 

den dreitausend Parametern, die »systctl()« 

bietet. Allein durch Aktivieren des 

Capability-Mode erhält man eine Sandbox, 

aus der es für Applikationen keine 

Möglichkeit gibt, auszubrechen. 

Feiner gesteuert 

Neben dem Capability-Mode werden mit 

Capsicum auch fein granulierte Berechtigungen 

eingeführt, ohne das bisherige 

System der Berechtigungen aufzugeben. 

Dieser Kniff wurde möglich, weil die Entwickler 

die Struktur des Filedeskriptors 

erweitert haben. Ein Filedeskriptor ist 

eine systemweit eindeutige Seriennummer, 

die auf eine Datenstruktur verweist. 

In dieser Datenstruktur – auch Metadaten 

genannt – sind neben dem Dateinamen 

auch die Berechtigungen enthalten. 

Die bekanntesten Filedeskriptoren 

sind STDIN (Standardeingabe), STDOUT 

(Standardausgabe) und STDERR (Standardausgabe 

für Fehlermeldungen). 

Die bisher benutzten Filedeskriptoren 

enthalten bereits die von FreeBSD bekannten 

Berechtigungen. Es handelt sich 

dabei um unveränderliche Merkmale, die 

sich an Kindprozesse weiter vererben 

lassen. Allerdings haben sie – was die 

Sicherheit anbelangt – den Nachteil, dass 

sie Manipulationen an den Metadaten zulassen 

– auch dann, wenn eine Datei oder 

ein Gerät für einen ausschließlichen Leseoder 

Schreibvorgang geöffnet wurde! 

Hier greift Capsicum mit einer Erweiterung 

der zum Filedeskriptor gehörenden 

Datenstruktur ein. Sobald in einer Ap- 

File- 

System 

Abbildung 2: Fein granulierte Berechtigungen als Erweiterung zum bestehenden Rechtesystem von FreeBSD. 


Capsicum 

plikation »cap_enter()« aufgerufen wird, 

erhalten alle Filedeskriptoren eine erweiterte 

Datenstruktur. Sobald ein so ausgestatteter 

Filedeskriptor benutzt wird, 

prüft der Kernel, ob beim Zugriff auf die 

abgesicherte Einheit alles korrekt ist. 

Für den Entwickler von Applikationen, 

die sich des Capsicum-Systems bedienen, 

ist das von Bedeutung, weil er 

entscheiden muss, welche der bereits 

durch »cap_enter()« gesperrten Zugriffsmöglichkeiten 

entweder gelockert, 

weiter verschärft oder weitere Regeln 

hinzugefügt werden sollen. Dazu dient 

der Aufruf von »cap_new()«, der einen 

bereits bestehenden Filedeskriptor und 

die gewünschten Berechtigungen als Parameter 

erwartet. Dabei spielt es keine 

Rolle, ob der Filedeskriptor für Dateien, 

Unix- oder Netzwerk-Sockets, Directories 

oder Geräte angelegt wurde. Die Manpage 

zu »cap_new()« listet alle verfügbaren 

Berechtigungen auf, die mit dem 

Oder-Operator verknüpft an Capsicum 

übermittelt werden. Die Manpage listet 

auch die zahlreichen Systemfunktionen 

der C-Bibliothek »libc« auf, die von Capsicum 

beeinflusst werden. 

Vorher planen 

Capsicum setzt daher voraus, dass man 

Applikationen sehr genau plant. Diese 

Aufgabe ist mit Sicherheit nicht trivial, 

da sie eine sehr genaue Analyse der Ressourcen 

verlangt. Dazu gehört der Einsatz 

von geschütztem Shared Memory 

anstelle eines gemeinsamen, öffentlich 

zugänglichen Speicherbereichs zum Datenaustausch. 

Capsicum gibt dem Programmierer 

die Wahlfreiheit, ob er das 

FreeBSD-eigene Berechtigungssystem 

verwendet oder die Bibliothek »libcapsicum« 

einsetzt. 

Applikationen mit zweifelhaften Privilegien 

lassen sich so umbauen, dass sie 

»cap_enter()« direkt verwenden. So ent- 

steht eine Applikation, deren einzelne 

Prozesse im Capability-Mode laufen 

und spezielle Berechtigungen über ihre 

Filedeskriptoren vererben. Diese Vorgehensweise 

eignet sich gut für einfach gestrickte 

Applikationen, die nach folgendem 

Schema ablaufen: Alle Ressourcen 

öffnen und in einer Schleife alle ein- und 

ausgehenden Daten verarbeiten – ähnlich 

einer UNIX-Pipeline oder bei einer 

Interaktion mit einem Netzwerk. Der Geschwindigkeitsverlust 

durch Capsicum 

ist sehr gering, wenn man die Berechtigungen 

beim Zugriff auf die Ressourcen 

einschränkt. 

Anhand des FreeBSD-Tools zur Netzwerkanalyse 

»tcpdump« wird dieses Ziel 

im Folgenden näher beschrieben. Tcpdump 

ist nach dem genannten Schema 

aufgebaut und daher einfach auf Capsicum 

umzustellen: Das Programm nutzt 

den Berkeley Packet Filter »bpf«, um die 

über ein Netzwerk transportierten Daten 

zu analysieren. Dazu teilt Tcpdump 

dem Paketfilter ein Suchmuster mit. Im 

nächsten Schritt wird der Filter als Eingabequelle 

definiert, um die Informationen 

zur weiteren Verarbeitung an »tcpdump« 

zu senden. Schließlich werden die eingehenden 

Daten in einer Schleife interpretiert, 

aufbereitet und auf der Console dargestellt. 

Somit lässt sich die Anwendung 

mit zwei zusätzlichen Zeilen Programmcode 

in den Capsicum-Capability-Mode 

übertragen: 

if (cap_enter() < 0) 

error("cap_enter: %s", 

pcap_strerror(errno)); 

Diese beiden Zeilen werden vor der 

Schleife eingefügt, welche die Analyse 

des Datenverkehrs durchführt: 

status = pcap_loop(pd, cnt, 

callback, pcap_userdata); 

Damit erhöht sich die Sicherheit beträchtlich. 

Parsen und Analysieren von 

Datenpaketen stellt meistens eine Sicherheitslücke 

dar, weil viele Speicherzugriffe 

durch C-Pointer und Kopieraktionen 

durchgeführt werden. Wie zuvor erläutert, 

unterbindet Capsicum den Zugriff 

auf privilegierte Speicherbereiche, was 

durch den Aufruf von »cap_enter()« realisiert 

wird. Um auch die Kommunikation 

auf STDIN (Standardeingabe), STDOUT 

(Standardausgabe) und STDERR (Standardfehlerausgabe) 

zu beschränken, 

sollte man Listing 1 vor dem ersten Aufruf 

von »cap_enter()« einfügen. 

Mit der hier verwendeten Funktion »cap_ 

rights_limit()« wird der Lesezugriff auf 

das STDIN-Gerät unterbunden, während 

Schreiboperationen auf die Ausgabegeräte 

STDOUT und STDERR sinnvollerweise 

erlaubt werden. 

Reingeschaut 

Eine Analyse mit dem um den Parameter 

»‐C« erweiterten FreeBSD-Kommando 

»procstat« bestätigt diesen Sachverhalt 

und ist als Screenshot in Abbildung 3 zu 

sehen. In der ersten und zweiten Spalte 

sind die Prozess-ID und der Prozessname 

zu sehen; die dritte Spalte zeigt den Filedeskriptor. 

In diesem Beispiel sind das 

Standardeingabe (FD = 0), Standardausgabe 

(FD = 1), Standardfehlerausgabe 

(FD = 2) und der Treiber »bpf« für den 

Berkeley-Paketfilter (FD = 3); Spalte 

vier beschreibt die Art des Filedeskriptors, 

in Spalte »FLAGS« wird dargestellt, 

welche FreeBSD-Berechtigungen gesetzt 

sind. Desweiteren weist der Buchstabe 

»c« darauf hin, dass Capsicum für diesen 

Filedeskriptor aktiv ist. 

Die Spalte »CAPABILITIES« zeigt an, 

welche der Capsicum-Berechtigungen 

gesetzt sind. Die Angabe »FS« (CAP_ 

FSTAT) bedeutet, dass der Status des Filedeskriptors 

abgefragt werden darf, »wr« 

(CAP_WRITE) steht für Schreibberechtigung 

und »se« (CAP_SEEK) bedeutet, 

Abbildung 3: Die Ausgabe von procstat eines durch Capsicum abgesicherten »tcpdump«. 

Listing 1: Standardkanäle limitieren 

if (cap_rights_limit(STDIN_FILENO, 

CAP_FSTAT) < 0) 

error("cap_new: unable to limit STDIN_FILENO"); 

if (cap_rights_limit(STDOUT_FILENO, 

CAP_FSTAT | CAP_SEEK | CAP_WRITE) < 0) 

error("cap_new: unable to limit STDOUT_FILENO"); 

if (cap_rights_limit(STDERR_FILENO, 

CAP_FSTAT | CAP_SEEK | CAP_WRITE) < 0) 

error("cap_new: unable to limit STDERR_FILENO"); 


Admin 


105

Capsicum 

dass der Dateizeiger gesetzt werden darf. 

Eine Übersicht aller Capsicum-Berechtigungen 

findet sich unter [2]. Die letzten 

beiden Spalten zeigen das Protokoll und 

den Gerätetreiber an, der für den jeweiligen 

Filedeskriptor verwendet wird. 

Bei der Verwendung von Capsicum tritt 

aber auch ein unschöner Nebeneffekt auf, 

der sich speziell bei »tcpdump« deutlich 

zeigt: Es wird auch der Zugriff auf den 

Name-Service-Switch unterbunden. Im 

Fall von »tcpdump« betrifft das die Umwandlung 

von IP-Adressen in voll qualifizierte 

Hostnamen. Dies lässt sich aber 

umgehen, indem man Anfragen an einen 

lokalen Domain-Name-Server sendet. 

Aufgeteilt 

Ein schönes Beispiel für die Abschottung 

(engl. Compartmentalisation) stellt das 

Programm »rwhod« dar. Dieser System- 

Daemon ist dafür zuständig, Systeminformationen 

zu ermitteln. Die Informationen 

umfassen, welcher Benutzer aktuell 

angemeldet ist sowie Zeitraum und 

Zeitpunkt des Logons. Um den Daemon 

auf Capsicum umzustellen, wurde zuerst 

Listing 2: Dateioperationen 

if (cap_rights_limit(dirfd, 

CAP_CREATE | CAP_WRITE | CAP_FTRUNCATE | 

CAP_SEEK | CAP_LOOKUP | CAP_FSTAT) < 0 && 

errno != ENOSYS) { 

syslog(LOG_WARNING, "cap_rights_limit: %m"); 

exit(1); 

} 

if (cap_enter() < 0 && errno != ENOSYS) { 

syslog(LOG_ERR, "cap_enter: %m"); 

exit(1); 

} 

Listing 3: Casper 

[...] 

#ifdef HAVE_LIBCAPSICUM 

if (nflag) { 

capcas = NULL; 

capdns = NULL; 

} else { 

capcas = cap_init(); 

if (capcas == NULL) 

error("unable to contact Casper"); 

capdns = cap_service_open(capcas, 

"system.dns"); 

if (capdns == NULL) 

error("unable to open \\ 

system.dns service"); 

/*Limit system.dns to rev. DNS lookups.*/ 

limits = nvlist_create(0); 

der Code bereinigt und die zu schützenden 

Bereiche in Funktionen unterteilt: 

Die zwei wesentlichen Funktionen sind 

»void receiver_process(void)« zum Empfang 

und »void sender_process(void)« 

zum Versenden der angeforderten Informationen 

an einen Client. 

Rechtefrage 

Nachdem die Abschottung in diesem 

Beispiel soweit abgeschlossen ist, muss 

sich der Autor des Programms Gedanken 

darüber machen, welche Zugriffsrechte 

das Tool für die einwandfreie Funktion 

benötigt. Hier gilt es, ein besonderes 

Augenmerk auf die Funktion »void receiver_process(void)« 

zu legen, weil sie 

Daten in die Datei »whod.« 

im Verzeichnis »/var/rwho« schreibt. 

Eingangs wurde erläutert, dass ein Filedeskriptor, 

der zum Schreiben in eine 

Datei angelegt wird, die Möglichkeit bietet, 

eine Datei auszulesen. Für Schadcode 

ist dieser Sachverhalt willkommen, weil 

so Informationen unerwünscht weiterverbreitet 

werden können. Mit der Capsicum-Funktion 

»cap_rights_limit()« lässt 

sich genau dies verhindern, wenn man 

die Flags »CAP_WRITE | CAP_FTRUN- 

CATE | CAP_FSTAT« setzt. Siehe hierzu 

den vollständigen Quellcode [4] ab Zeile 

404: 

if (cap_rights_limit(whod, 

CAP_WRITE | CAP_FTRUNCATE | CAP_FSTAT) < 0 

&& errno != ENOSYS) { 

syslog(LOG_WARNING, "cap_rights_limit: 

%m"); 

exit(1); 

} 

nvlist_add_string(limits, 

"type", "ADDR"); 

nvlist_add_number(limits, 

"family", (uint64_t)AF_INET); 

nvlist_add_number(limits, 

"family", (uint64_t)AF_INET6); 

if (cap_limit_set(capdns, limits) < 0) 

error( 

"unable to limit access to \\ 

system.dns service"); 

nvlist_destroy(limits); 

/*Casper capability no longer needed.*/ 

cap_close(capcas); 

} 

#endif /* HAVE_LIBCAPSICUM */ 

[...] 

Die Flags besagen, dass der Filedeskriptor 

»whod« nur zum Schreiben in die 

Datei (»CAP_WRITE«), zum Ändern der 

Dateigröße (»CAP_FTRUNCATE«) und 

zum Abrufen der Statusinformationen 

(»CAP_FSTAT«) genutzt werden darf. 

Jede andere Operation wird unterbunden. 

Auch für den Fall, dass der Schadcode 

versuchen sollte, die Flags zu manipulieren, 

gibt es keine Chance. Flags, die 

einmal gesetzt wurden, lassen sich nicht 

mehr verändern. 

Weiterhin muss klar definiert sein, welche 

Dateioperationen im Verzeichnis 

»/var/whod« ausgeführt werden dürfen. 

Dazu dient der Code ab Zeile 353 

(Listing 2). 

Diese wenigen Zeile C-Code sind dafür 

verantwortlich, dass im bereits geöffneten 

Verzeichnis mit dem Filehandle 

»dirfd« Dateien angelegt oder ergänzt 

werden dürfen. Ein Auslesen der angelegten 

Dateien ist vom Programm aus 

aber nicht möglich. 

Fenster zur Welt 

Viele Dienstprogramme und Werkzeuge 

müssen Zugriff auf bestimmte Ressourcen 

Zugriff erhalten. Ein Beispiel wurde 

im Zusammenhang mit Tcpdump bereits 

angesprochen. Dieses Tool benötigt Zugriff 

auf den Domain Nameserver, um IP- 

Adressen in Hostnamen umzuwandeln. 

Innerhalb des Programms wird dazu der 

Name-Service-Switch (NSS) aufgerufen. 

Da Capsicum solche Zugriffe allerdings 

unterbindet, musste eine andere Lösung 

gefunden werden. Es entstand das Tool 

Casper (Capsicum Service), das die Möglichkeit 

bietet, als Daemon-Prozess kontrolliert 

Ausnahmeregeln zuzulassen. 

Die Funktionsweise von Casper ist anhand 

Abbildung 4 schnell erklärt. Casper 

startet ein Programm wie das in diesem 

Beispiel genannte »tcpdump«, das in einer 

Sandbox eingeschlossen ist. Bevor 

alle Überwachungsmechanismen scharf 

geschaltet werden, meldet das Programm 

die Ausnahmeregeln beim Casper- 

Daemon an und aktiviert anschließend 

die Schutzmechanismen. 

Eine solche Aktion muss vorher erledigt 

werden, da nach der Aktivierung von 

Capsicum keinerlei Kommunikation mit 

Systemdiensten und auch nicht mit Casper 

möglich ist. Im Beispiel wurde dies 


Capsicum 

tcpdump 

IP-Adresse 

Hostname 

Direktzugriff 

auf 

NIC 

Capsicum-Sandbox 

Casper mit Freigabe für DNS 

wie in Listing 3 realisiert. Der vollständige 

Code findet sich unter [7]. 

Zunächst wird mit »cap_init()« der Casper- 

Daemon kontaktiert und das Programm 

registriert. Im nächsten Schritt meldet 

die Funktion »cap_service_open(...)« die 

gewünschte Ausnahme beim Daemon an. 

In diesem Beispiel sind es DNS-Anfragen, 

was durch die Option »system.dns« gekennzeichnet 

ist. Der Daemon erwartet 

eine durch »limits = nvlist_create(...)« 

bezeichnete Liste mit der genauen Funktionalität. 

Das erste Element beschreibt, 

dass es sich um eine Umwandlung von 

IP-Adressen in Hostnamen handelt, was 

durch »type« und »ADDR« angezeigt 

wird. Die beiden nächsten Einträge beschreiben 

die IP-Adressfamilie. In diesem 

Beispiel sind es IPv4- und IPv6-Adressen 

(AF_INET und AF_INET6). 

Diese Liste übergibt man mit »cap_limit_set(...)« 

an den Daemon Casper 

und löscht sie anschließend, da sie vom 

Programm Tcpdump nicht mehr benötigt 

wird. Ab diesem Zeitpunkt hat Casper 

alle Informationen, um dem Tool einen 

Zugriff auf den Domain Name Service 

zu gestatten. 

Gezielt geöffnet 

STOP 

Abbildung 4: Kommunikationsweg von Tcpdump und Casper bei einer DNS-Anfrage. 

DNS-Server 

über 

Name Service Switch NSS 

Man kann sich die Frage stellen, ob damit 

nicht das Sandbox-Konzept ausgehebelt 

wird. Casper erteilt nicht uneingeschränkt 

Zugriff auf die Ressource, sondern nutzt 

auch hier die unter Capsicum bereitgestellte 

feine Granulierung der Rechtever- 

Netzwerk- 

Hardware 

gabe. Außerdem legt der Autor des Programms 

fest, wie die Kommunikation mit 

der Außenwelt stattfinden darf und nicht 

irgendein externes Programm. 

Scharfe Anwendungen 

Um zu zeigen, dass sich nicht nur Systemprogramme, 

sondern auch Userprogramme 

mit Capsicum absichern lassen, 

wurde von Google der Webbrowser Chromium 

an die neue Umgebung angepasst. 

Googles Chromium erzeugt beim Start 

mehrere Prozesse, denen Aufgaben wie 

Verarbeiten von HMTL-Code, JavaScript 

und Verschlüsselung von Daten zufallen. 

Der ursprüngliche FreeBSD-Port des Webbrowsers 

enthielt keinerlei Sicherheitsmerkmale 

wie Sandboxing. 

Dass das Programm bereits in logische 

Abschnitte unterteilt ist (Stichwort: Compartmentalisation), 

erleichtert die Anpassung 

an die Capsicum-Umgebung von 

FreeBSD erheblich. Der Subprozess, der 

die grafische Darstellung der Webseite 

übernimmt, erhält besondere Berechtigungen, 

um mit dem Grafiksystem von 

X.org zu kommunizieren. Geschützte 

Speicherbereiche dienen zum Transport 

von Daten zwischen den einzelnen Subprozessen. 

Subprozesse zur Kompilierung 

von Javascript, HTML und XML 

haben keinen Zugriff auf Speicherbereiche 

außerhalb der Sandbox. Obwohl der 

Code-Umfang von Chromium gewaltig 

ist – man spricht von 4,3 Millionen Zeilen 

Code – erfolgte die Implementierung von 

Capsicum mit circa einhundert Zeilen 

nahezu reibungslos. Will man beispielsweise 

unter Windows die gleiche Sicherheit 

erreichen, sind mehr als 23 000 

Zeilen Code nötig ([8]). Auch hat der 

Entwickler der GNUStep-Desktop-Suite 

bereits angekündigt, Capsicum in den 

Anwendungen einzusetzen. 

Fazit 

Mit FreeBSD 9 haben die Entwickler den 

Sicherheitsmechanismus Capsicum eingeführt. 

Der volle Umfang der Capsicum- 

Funktionalität wird ab FreeBSD 10 zur 

Verfügung stehen. Alle sicherheitskritischen 

Systemprogramme werden dann 

das neue Framework nutzen. Zusätzlich 

werden möglicherweise weitere Applikationen 

wie Apache an die neue FreeBSD- 

Umgebung angepasst sein. So möchten 

einige Entwickler von GNUStep-Anwendungen 

diese an FreeBSD-Capsicum 

anpassen. Es wurde bereits von KDE- 

Maintainern angekündigt, Capsicum in 

KDE zu implementieren. Man darf daher 

gespannt sein, was die Zukunft für Capsicum 

bringen wird. (ofr) 

n 

Infos 

[1] Kris Kennaway: Introducing Capsicum: 

Practical Capabilities for UNIX 

[2] Capsicum-Berechtigungen: [http:// www. 

dankoweit. de/ FreeBSD/ hp_freebsd_capsicum_capabilities. 

html] 

[3] Manpages: capsicum(4), cap_enter(2), 

cap_new(2) 

[4] Rwhod (BSD-Lizenz): [http:// svnweb. 

freebsd. org/ base/ head/ usr. sbin/ rwhod/ 

rwhod. c? revision=252605& view=markup] 

[5] Compartmentalisation (r252603): [http:// 

lists. freebsd. org/ pipermail/ svn‐src‐head/ 

2013‐July/ 049115. html] 

[6] Capsicum-Flags setzen (r252605): [http:// 

lists. freebsd. org/ pipermail/ svn‐src‐head/ 

2013‐July/ 049116. html] 

[7] Vollständiger Quellcode von tcpdump 

(BSD-Lizenz): [http:// p4db. freebsd. org/ 

fileDownLoad. cgi? FSPC=// depot/ user/ pjd/ 

capsicum/ contrib/ tcpdump/ tcpdump. c& 

REV=17] 

[8] Vergleich der Sandboxing-Technologien, 

Robert N. M. Watson, University of 

Cambridge, Seite 11: [http:// www. cl. 

cam. ac. uk/ ~jra40/ publications/ 2010/ 

USENIXSEC‐capsicum. pdf] 


Admin 


107

Raspberry 

Abbildung 1: Der Raspberry Pi mit seinen diversen Anschlüssen: Links oben (blau) die SD-Karte, darunter der Micro-USB-Stromanschluss, oben Video- (gelb) und 

Audioausgang, unten HDMI, rechts in der Mitte USB, darunter das gelbe Netzwerkkabel. Ein Gehäuse wie das Abgebildete muss man allerdings extra kaufen. 

NetBSD auf dem Raspberry Pi 

Netberry 

Eines der interessantesten Computerprojekte der letzten Zeit ist der 

Rasp berry Pi. Normalerweise wird er mit Linux betrieben, NetBSD funktioniert 

aber auch und sogar ohne lokalen Monitor. Die Vorbereitung ist dann 

nur etwas ungewöhnlich. Jörg Braun und Rosa Riebl 

Seit der ersten Veröffentlichung sind 

laut der Website raspberrypi.org über 

eine Million Exemplare des Raspberry 

Pi verkauft worden. Kein Wunder, denn 

dieser Einplatinencomputer besticht 

durch ein günstiges Preis-/Leistungsverhältnis 

und seine nahezu unbegrenzte 

Ausbaufähigkeit. Als Standardbetriebssystem 

wird Linux empfohlen, von dem 

es ein vorgefertigtes Image gibt, das sich 

zum Booten auf eine mindestens 4 GByte 

große SD-Karte übertragen lässt. Es gibt 

mehrere Distributionen und das speziell 

angepasste Debian GNU/Linux lässt eigentlich 

keine Wünsche offen. 

Der Raspberry Pi ist sehr klein, der dennoch 

vollwertige Computer basiert auf 

einem mit 700 MHz getakteten ARM- 

Prozessor. Die größere und etwas teurere 

Variante Typ B besitzt 512 MByte RAM, 

zwei USB-2-Schnittstellen und eine eingebaute 

Netzwerkkarte mit 10/100 MBit/s 

(kein Gigabit-Netzwerk). Die kleinere 

und etwas günstigere Variante A ohne 

Netzwerk und mit nur 256 MByte RAM 

wurde nicht getestet. Weiteres RAM kann 

man nicht einbauen, aber zusätzliche Peripherie 

lässt sich über einen USB-Hub 

anschließen. 

Der Raspberry besitzt außer den erwähnten 

Schnittstellen einen einfachen 

Video- und Audioausgang und für die 

Ausgabe auf modernen Fernsehern einen 

HDMI-Ausgang – ein Versuch, über einen 

Adapter das HDMI-Signal auch auf einen 

anderen Bildschirm umzuleiten, führte 

zu keinem Ergebnis. Die Stromzufuhr geschieht 

per Micro-USB-Stecker und bei einer 

Leistungsaufnahme von 700 mA beim 

Raspberry Pi Typ B am besten mit einem 

USB-Netzumwandler. An die diversen 

Verbindungskabel und an die Anschaffung 

eines Gehäuses sollte man gleich 

beim Kauf der Platine denken. 

Anschlussfreudig 

Der Raspberry Pi kann, abgesehen von 

einem primären Zweck der Ansteuerung 

unterschiedlicher Peripheriegeräte, 

über sein ausgereiftes Bussystem auch 

als Mini-PC lokal betrieben werden 


Raspberry 

Die Installation beginnt mit dem Download 

eines ISO-Images des aktuellen 

NetBSD-Releases. Das Image des aktuellen 

32-Bit-Systems für Intel-Maschinen 

finden Sie unter [6]. Wie bei NetBSD üblich 

ist das CD-Image »NetBSD‐6.1‐i386. 

iso« mit 312 MByte einigermaßen schlank 

und braucht bei der Installation trotzdem 

keine Internetverbindung für das Nachund 

beispielsweise einen HDMI-fähigen 

Fernseher sehr einfach und kostengünstig 

Internet-tauglich machen. Man kann 

damit aber auch im Netzwerk einen 

stromsparenden Web- oder Dateiserver 

implementieren. Über den Aufbau eines 

Webservers mit dem Raspberry findet 

man unzählige Beiträge im Internet und 

in Zeitschriften. Dabei beschränkt sich 

die eigentlich Rasp berry-typische Arbeit 

auf das Einspielen des Linux-Systems, 

der Rest der Arbeiten ist eins zu eins 

identisch zu denen auf anderen Debianbasierten 

Serversystemen, also Apache 

und PHP einrichten und konfigurieren. 

Linux, nein danke 

Auf den Download-Seiten von [1] findet 

man zwar ständig aktualisierte Linux- 

Distributionen und echte Exoten wie 

Risc OS, daneben aber recht versteckt 

auch Verweise auf FreeBSD und NetBSD. 

FreeBSD empfiehlt sich aber nicht unbedingt, 

denn es gibt bei diesem Betriebssystem 

keine vorkompilierten externen 

Programme; man muss sich alles selbst 

aus den Ports kompilieren. Auf dem 

Raspberry wird das zur echten Geduldsprobe, 

speziell auch deshalb, weil bei 

FreeBSD kein X enthalten ist und dieses 

sehr große Programmpaket ebenfalls aus 

den Ports kompiliert werden muss. 

Die Unterstützung durch NetBSD ist 

besser, was eigentlich nicht verwundert, 

ist NetBSD doch das auf den meisten 

Plattformen verfügbare Betriebssystem 

und für ARM sind sogar mehrere Ports 

erhältlich. Gültig für den Raspberry und 

verwandte Hardware ist NetBSD/evbarm. 

Wie FreeBSD muss man auch NetBSD aus 

den aktuellen Entwicklerquellen installieren, 

was manchmal funktioniert, oft aber 

auch nicht. Eine rudimentäre Anleitung 

dazu gibt es auf [2]. Man kann mit dieser 

Anleitung und etwas Hintergrundwissen 

zu NetBSD das System recht einfach und 

elegant installieren, darf dabei nur zum 

Schluss im Installationsprogramm nicht 

vergessen, den SSHD einzuschalten und 

ein Benutzerkonto anzulegen. Mit den 

Quellen vom 12.6.2013 (siehe [3]) funktioniert 

die Installation auch – nur war 

anschließend kein Einloggen möglich, 

weil keine Bibliothek für die Passwortprüfung 

eingeschaltet wird. Das System 

ist damit unbrauchbar. 

Es gibt aber eine einfachere Möglichkeit, 

NetBSD erfolgreich auf dem Raspberry 

einzurichten. Der Ablauf wirkt nur auf 

den ersten Blick etwas seltsam. Benötigt 

werden dazu nämlich zwei Images, 

eines für den Raspberry Pi von [4] und 

außerdem eines für eine Installation von 

NetBSD/i386 oder NetBSD/AMD64 in 

einer virtuellen Maschine. Letzteres ist 

aber nur nötig, wenn man keinen geeigneten 

Bildschirm für den Raspberry 

zur Verfügung hat und sich mit SSH in 

das Betriebssystems des Winzlings einloggen 

muss. Im vorgefertigten Image ist 

nämlich kein Benutzerkonto angelegt, 

weshalb SSH den Dienst verweigert (es 

arbeitet sich auf dem Intel-System aber 

auch besser als auf dem ursprünglich 

doch recht rudimentären Image). 

Haben Sie bereits eine native Installation 

von NetBSD in Betrieb, können Sie sich 

theoretisch das Anlegen einer virtuellen 

NetBSD-Maschine sparen und die benötigten 

Dateien aus den Verzeichnissen 

»/etc« und »/home« des laufenden Systems 

in das gleichnamige Verzeichnis 

auf dem angelegten Image einspielen. 

Sie übertragen damit aber auch die anderen 

Benutzerkonten, was normalerweise 

nicht gewünscht sein dürfte. 

Wenn Sie die Arbeiten unter Windows 

durchführen wollen, brauchen Sie außer 

den Images für die NetBSD-Installationen 

den Win32DiskImager, können aber 

auf ihn verzichten, wenn Sie NetBSD in 

der virtuellen Maschine (zum Beispiel 

unter VirtualBox) installieren, weil sich 

das Image auch daraus auf die SD-Karte 

schrei ben lässt. Natürlich muss die 

Möglichkeit bestehen, auf dem PC die 

SD-Karte zu beschreiben, entweder mit 

einem eingebauten oder einem per USB 

angeschlossenen Kartenleser. Dies gilt 

aber auch für andere (Linux-)Images des 

Raspberry. 

Lieber NetBSD 

laden fehlender Daten, wie man es von 

kleineren Linux-Images kennt. 

Für die NetBSD-Installation sollten in 

der Virtualisierungslösung eine nicht zu 

kleine Festplatte (5 GByte und mehr reichen 

jedoch) und 512 MByte Arbeitsspeicher 

gewählt werden. NetBSD wird bei 

der VirtualBox als Gastsystem direkt angeboten, 

bei VMware Workstation muss 

FreeBSD gewählt werden (NetBSD-Gäste 

kennt man bei VMware nicht). 

Sie sollten die VirtualBox-Installation um 

die proprietären Erweiterungen ergänzen, 

damit USB-2-Zugriffe möglich sind. Andernfalls 

dauern die Arbeiten unerträglich 

lange – grundsätzlich geht es aber 

ohne. Nach dem Anlegen der virtuellen 

PC-Maschine mit den oben angegebenen 

Daten und nach dem Einbinden des von 

[6] heruntergeladenen ISO-Images als 

CD-Laufwerk wird NetBSD installiert. 

Diese Installation verläuft im Textmodus 

und ist schlicht und funktional. Die einzige 

Stelle, an der Sie aufpassen müssen, 

ist die Definition des Festplattenlabels. 

Zusätzlich zu den vorgeschlagenen BSD- 

Partitionen »a« für das Rootverzeichnis 

und »b« für den Auslagerungsbereich, 

deren Daten übernommen werden können, 

sollte der Rest als Partition »e« dem 

Mountpunkt »/usr« zugewiesen werden. 

Dies geschieht nicht automatisch. 

Benutzer anlegen 

Nach dem Abschluss der Installation 

halten Sie das Gastsystem an, binden 

das ISO-Image aus und booten von der 

virtuellen Festplatte. In das neue System 

loggen Sie sich als Root ein. Jetzt sollte 

dem Administratorkonto »root« mit dem 

Befehl »passwd« ein Passwort vergeben 

und anschließend mit »useradd« ein zusätzliches 

Benutzerkonto definiert werden. 

Die hier getroffenen Angaben gelten 

später auch für den Raspberry. 

Beachten Sie, dass »useradd« nicht interaktiv 

ist und Sie bei seinem Aufruf 

unbedingt den Schalter »‐m« verwenden, 

damit das Verzeichnis für das Konto auch 

angelegt wird. Der Befehl lautet dann 

beispielsweise 

useradd ‐m ‐s /bin/ksh ‐b /home rosa 

wobei »rosa« der Name des neu angelegten 

Kontos und der Name des Home- 

Verzeichnisses ist. Weitere Angaben sind 


Admin 


109

Raspberry 

nicht nötig. Nun müssen Sie mit dem 

Befehl 

passwd rosa 

noch das Passwort festlegen und in der 

»/etc/group« das neue Konto mit »vi« 

der Gruppe »wheel« zuordnen. Die Zeile 

sollte anschließend 

wheel:*:0:root,rosa 

lauten. Das neue Konto kann auf dieselbe 

Weise auch anderen Gruppen wie »operator«, 

»staff« oder »users« zugewiesen 

werden. Dies ist für manche Programme 

günstig, für das Einloggen mit »ssh« aber 

nicht unbedingt nötig. 

Zuerst der virtuelle PC … 

Haben Sie den Schalter »‐m« vergessen, 

müssen Sie als »root« das Verzeichnis 

mit »mkdir« zuerst anlegen und dann 

dem Konto manuell zuweisen. Das sieht 

dann so aus: 

mkdir /home/rosa 

cp /etc/skel/.* /home/rosa 

chown rosa:wheel /home/rosa 

Diese einfache virtuelle Maschine lässt 

sich noch ausbauen, beispielsweise indem 

externe Software-Pakete installiert 

werden. Dafür bearbeiten Sie am einfachsten 

die »/etc/.profile« des Root-Kontos 

und entfernen vor den drei Zeilen mit 

»export PKG_PATH=?« das Gatter-Zeichen. 

Linux-Anwender werden bei dieser 

Gelegenheit feststellen, dass der »vi« von 

NetBSD recht primitiv ist. 

Nach dem Speichern der Datei mit »:w!« 

und dem »:q« loggen Sie sich aus der 

Maschine aus und dann wieder ein und 

können dann mit »pkg_add« beliebige 

Pakete, zum Beispiel »Midnight Commander«, 

den Debian-Editor »Nano« und 

»Sudo« installieren: 

in jedem Fall besser. Unter Unix/Linux 

überträgt man die Image-Datei mit dem 

Befehl »dd« auf das Device, unter NetBSD 

zum Beispiel mit 

dd if=2013‐03‐04‐netbsd‐raspi.img of=U 

/dev/sd0 

Dies gilt allerdings nur dann, wenn 

NetBSD nicht auf einer SCSI-, sondern 

einer IDE- oder SATA-Platte und damit 

auf »wd0« installiert wurde. Wie das Device 

wirklich heißt, sieht man an dem 

grünen Namen, der auf der ersten Konsole 

nach dem Einstecken der SD-Karte 

beziehungsweise von deren Adapter erscheint. 

Unter Windows entpacken Sie 

das Archiv mit dem Win32DiskImager in 

ein beliebiges Verzeichnis und rufen das 

Exe-Programm dort auf. 

Haben Sie NetBSD in einer virtuellen 

Maschine unter Windows installiert, 

spricht überhaupt nichts dagegen, die 

SD-Karte aus der virtuellen Installation 

zu beschreiben. Dazu muss (das ist voreingestellt) 

USB für den Gast eingeschaltet 

sein. Dann stecken Sie die Karte ein. 

Erkennt Windows sie, taucht sie in der 

Statuszeile des VirtualBox-Fensters auf. 

Mit dem Eintrag in der Statuszeile des 

Fensters der virtuellen Maschine wird das 

Gerät Windows entzogen und der VM 

zugeordnet. 

Nach dem Signalton entfernen Sie jetzt 

die Hardware physisch vom PC und binden 

sie dann sofort wieder ein. Erst danach 

wird sie der virtuellen Maschine 

zugeteilt, wie der Name zeigt (siehe Abbildung 

2 und 3). 

Für das Übertragen der Daten wird die 

Karte nicht gemountet. Erst nachdem Sie 

die Daten korrekt mit »dd« aufgespielt 

haben, wird das Device eingebunden. 

Das NetBSD-System befindet sich auf der 

Partition »a«. Die Aufrufe lauten 

dd if=rpi‐20130124.img of=/dev/sd0 

mount /dev/sd0a /mnt 

Das Einbinden des Images in die NetBSD- 

Instanz ist entscheidend, weil jetzt noch 

die angesprochenen Korrekturen folgen. 

Zuerst kopieren Sie die Passwortdateien 

und die Gruppendatei mit »cp« nach »/ 

mnt/etc« (falls die Karte wie gezeigt nach 

»/mnt« eingebunden wurde): 

cp ‐a /etc/passwd /mnt/etc 

cp ‐a /etc/master.passwd /mnt/etc 

cp ‐a /etc/spwd.db /mnt/etc 

cp ‐a /etc/pwd.db /mnt/etc 

cp ‐a /etc/group /mnt/etc 

Der Parameter »‐a« fasst die Rekursion der 

Inhalte und das Beibehalten der Datei- 

Attribute und ‐rechte zusammen. Einfacher 

und bequemer lassen sich die Daten 

mit dem Midnight Commander kopieren. 

Außerdem übertragen Sie das Verzeichnis 

»/home«, in dem sich nur das eine zuvor 

angelegte Benutzerverzeichnis befinden 

sollte, auf das ARM-System: 

cp ‐a /home /mnt 

E 

pkg_add mc nano sudo 

Die Programme stehen nach der Installation 

sofort zur Verfügung. 

… und jetzt der Raspberry 

Im nächsten Schritt laden Sie das NetBSD- 

Image für den Raspberry von [4] herunter, 

packen es aus und übertragen es auf 

die SD-Karte. Die Karte muss dafür mindestens 

2 GByte groß sein, mehr ist aber 

Abbildung 2: Das USB-Gerät wurde von der VirtualBox erkannt und kann zugeordnet werden. 


TEsten Sie 

android user 

Sparen Sie 66 %: 3 Ausgaben lesen - nur eine zahlen*! 

Jetzt bestellen unter: 

www.android–user.de/miniabo 

Telefon 07131 / 2707 274 • Fax 07131 / 2707 78 601 • E-Mail: abo@android-user.de 

(*Mini-Abo: 3x Printausgaben nur 5,90 Euro, 3x PDF-Ausgaben nur 3,99 Euro) 

NEU: MINI-ABO 

NACH WAHL 

ALS Print- oder 

PDF-Version!

Raspberry 

Jetzt fehlen nur noch einige Anpassungen, 

damit das System auch richtig funktioniert. 

Damit benötigt man übrigens 

auch keinen DHCP-Server, der sonst bei 

allen Remote-Raspberry-Installationen 

gefordert wird. In »/mnt/etc« werden 

eine Reihe Dateien angelegt: »myname« 

enthält als Eintrag nur den Namen des 

Systems, beispielsweise »raspberry« ohne 

weitere Umrahmungen und Definitionen. 

»resolv.conf« nimmt die Liste der Nameserver 

auf. Sie kann etwa so aussehen: 

nameserver 192.168.0.1 



In »mygate« steht die IP-Adresse des Routers, 

der ins Internet führt, ohne weitere 

Zusatzangaben, also beispielsweise 

»192.168.0.1«. 

Netzwerkkarte 

Wie die Netzwerkkarte konfiguriert ist, 

stellen Sie in der neu anzulegenden »ifconfig.usmsc0« 

ein. Die Dateiendung ist 

NetBSD-spezifisch und drückt die Gerätekennung 

aus, das »eth0« von Linux 

sucht man bei allen BSD-Systemen vergebens. 

Das führende »u« der Endung 

zeigt im Übrigen an, dass die Karte über 

die USB-Schnittstelle betrieben wird. Dies 

ist der Grund, warum beim Raspberry Pi 

kein Betrieb mit einem Gigabit-Ethernet 

möglich ist. 

Befindet sich ein DHCP-Server im Netzwerk, 

von dem der Raspberry seine IP- 

Adresse dynamisch erhalten soll, reicht 

es, wenn in der Datei der Eintrag »dhcp« 

steht. Bei fester IP-Adresszuweisung wird 

hinter der Kennung »inet« die IP-Adresse 

und nach einem »netmask« in der selben 

Zeile die klassische Maske angegeben. 

Das sieht beispielsweise so aus (die IP- 

Adresse und die Maske müssen natürlich 

angepasst werden): 

inet 192.168.0.20 netmask 255.255.255.0 

Zusätzliche Angaben, die in der Manpage 

zu »ifconfig.if« zu finden sind, werden 

Listing 1: Paketquellen 

01 # Uncomment the following line(s) to install binary packages 

02 # from ftp.NetBSD.org via pkg_add. (See also pkg_install.conf) 

beim Raspberry nicht benötigt. Wollen 

Sie statt einer statischen IP-Adresse lieber 

DHCP nutzen, sind die Angaben zum 

Router und DNS von oben übrigens optional. 

Das »dhclient«-Skript, das die IP- 

Adresse anfordert, erzeugt beim Booten 

automatisch die anderen Dateien. 

Startprogramme 

Jetzt fehlt noch die zentrale Konfigurationsdatei 

»/etc/rc.conf«. Hinter der Zeile 

mit »Add local overrides below« tragen 

Sie die beim Start des Geräts zu ladenden 

Dienste ein: 

sshd=YES 

ntpd=YES 

ntpdate=YES 

wscons=YES 

# SSH‐Daemon 

# Uhrzeit aus 

# dem Netz 

# Konsolendefinition 

Damit das System mit einer deutschen 

Tastatur startet, tragen Sie in »/etc/ 

wscons.conf« die Zeile 

encoding de.nodead 

ein. Andere Tastaturbelegungen werden 

jeweils durch das Voranstellen eines Gatters 

ausgeschaltet. 

Das war es schon fast. Nur noch die 

»/root/.profile« verlangt dringend nach 

einer Anpassung, damit nach dem Start 

des Raspberrys auch Software aus der 

Paketverwaltung installiert werden kann. 

Die Liste muss um die NetBSD-6.1-Pakete 

ergänzt werden. Die internen Variablen 

kann man entfernen, wie die ersten beiden 

Beispiele zeigen (Listing 1). Wichtig 

ist, dass die Angaben insgesamt zwischen 

Anführungszeichen stehen. 

Passende Pakete 

03 export PKG_PATH="ftp://ftp.NetBSD.org/pub/pkgsrc/packages/NetBSD/evbarm/6.1/All" 

Mit diesen Werten sucht die Paketverwaltung 

zuerst nach neueren, dann 

nach älteren Programmpaketen dieser 

Hardware-Plattform, falls sie für neuere 

NetBSD-Versionen nicht kompiliert 

wurden. Hier wurde die in der Originaldatei 

enthaltene Suche nach NetBSD- 

5.0-Paketen entfernt, weil die Erfahrung 

zeigt, dass bei neuen Installationen von 

04 export PKG_PATH="${PKG_PATH};ftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/evbarm/6.0/All/" 

05 export PKG_PATH="${PKG_PATH};ftp://ftp.NetBSD.org/pub/pkgsrc/packages/NetBSD/$(uname ‐m)/5.1/All" 

NetBSD 6.x bereits schon das Einbinden 

von Programmen für NetBSD 5.1 zu Problemen 

führen kann. 

Installiert man beispielsweise auf dem 

Raspberry mit den obigen Angaben den 

Midnight Commander mit dem Aufruf 

pkg_add mc 

wird das Paket aus den Paketquellen von 

NetBSD 5 geholt. Anschließend stimmen 

aber die Verweise auf zwei Linkbibliotheken 

nicht, die bei NetBSD 6.x in der 

Versionskennung 1, bei NetBSD 5 in der 

Versionskennung 0 zu finden sind. Man 

muss dann ins Verzeichnis »/usr/lib« 

wechseln und dort zwei Links für die 

Bibliotheken anlegen: 

ln libintl.so.1 libintl.so.0 

ln libpthread.so.1 libpthread.so.0 

Der Midnight Commander funktioniert 

zwar nach diesen Änderungen, schön ist 

das aber nicht. 

Es ist jedoch unrealistisch zu versuchen, 

Programme auf dem verhältnismäßig leistungsschwachen 

System zu kompilieren. 

Auch das Neukompilieren des Betriebssystems 

ist kaum machbar. Das Dateisystem 

lässt sich zwar mit einem USB-Stick 

recht einfach für »/usr/src« oder »/usr/ 

pkgsrc« erweitern, allein das Auspacken 

der Systemquellen dauerte bei einem solchen 

Versuch aber bereits mehrere Stunden. 

Trotzdem: Wer möchte, kann den 

Raspberry ja so lange laufen lassen, bis 

das Build-Skript seine Arbeit im Hintergrund 

abgeschlossen hat. 

Sind alle benötigten Änderungen am 

ARM-System durchgeführt, wird die SD- 

Karte mit »umount /mnt« ausgebunden, 

in den Raspberry Pi eingesteckt und 

dieser von ihr gebootet. Man muss sich 

etwas in Geduld üben, bis man per SSH 

auf das Gerät zugreifen kann, denn der 

Kernel ist mit Debug-Informationen vollgestopft 

und damit etwas träge. 

Größenänderungen 

Ist NetBSD auf einer mehr als 2 GByte 

großen Karte installiert, stellt sich noch 

die Frage, wie man das Disklabel vergrößert. 

Lokal geht das, wie in [2] beschrieben, 

recht einfach, man muss nur einmal 

die »cmdline.txt« auf der DOS-Partition so 

bearbeiten, dass das Betriebssystem im 

Single-User-Modus startet. Denn unter 


Raspberry 

binden Sie jetzt nicht ein, sondern bearbeiten 

nur die angemeldete und nicht 

eingebundene SD-Karte. Im ersten Schritt 

ist noch einmal der gleiche »fsck« wie 

eben fällig, um sicherzugehen, dass die 

Karte nicht durch ein zu frühes Ausschalten 

des Raspberry Datenfehler aufweist. 

Zu beachten ist, dass je nach Festplattendefinition 

die Karte auch hier wieder 

»sd1« heißen kann, was man aber beim 

Einstecken angezeigt bekommt (siehe 

Abbildung 3). Ist die Prüfung abgeschlossen, 

vergrößern Sie das Disklabel: 

resize_ffs ‐y /dev/rsd0a 

Danach prüfen Sie im letzten Schritt noch 

einmal den Datenträger: 

Abbildung 3: Der SD-Kartenleser mit einer 8-GByte-Karte ist nach dem Aus- und wieder Einstecken der 

NetBSD-Maschine zugewiesen. 

BSD kann nur eine nicht eingebundene 

Partition bearbeitet werden. 

Die Änderungen lassen sich auch bei dem 

Gerät ohne lokalen Monitor durchführen, 

es braucht (und darf) dann aber die 

»cmdline.txt« nicht geändert zu werden. 

Benötigt wird auch hier wieder die virtuelle 

Maschine oder ein natives beliebiges 

anderes NetBSD. Die Schritte sind dann 

im Prinzip dieselben wie in [2]. 

Zuerst booten Sie das NetBSD-System 

auf der SD-Karte auf dem Raspberry, loggen 

sich mit dem Benutzerkonto ein und 

holen sich mit »su« die obligatorischen 

Administratorrechte. Mit 

disklabel ‐i ld0 

gelangen Sie in den interaktiven Modus 

des Programms Disklabel, »ld0« ist hier 

die Kennung der SD-Karte am Raspberry. 

Es erscheint ein Prompt, an dem man 

mit [?] eine kurze Hilfe angezeigt bekommt. 

An diesem Prompt drücken Sie 

[A] (Großbuchstabe!) und sehen eine 

Frage ähnlich der Folgenden: 

Adjust disklabel sector from 4194304U 

to 62333952 [n]? y 

Die Zielgrößenangabe ist natürlich von 

der Gesamtgröße der Karte abhängig. 

Den Befehl »A« kennt das Disklabel- 

Programm der Intel-Version von NetBSD 

nicht, deshalb muss dieser Schritt im 

ARM-System durchgeführt werden. 

Die Änderung des Labels bestätigen Sie 

mit [y]. Im nächsten Schritt werden Sie 

nach der Partition gefragt und müssen 

hier [a] angeben, weil genau diese zu 

vergrößern ist. Wenn Sie nach dem Dateisystem 

gefragt werden, brauchen Sie die 

Voreinstellung 4.2BSD nur mit [Enter] 

zu bestätigen. Auch bei der Frage nach 

dem Start-Offset genügt die Eingabe von 

[Enter]. 

Neu partitionieren 

Anders ist es bei der Definition der Partitionsgröße. 

Hier führt ein $-Zeichen 

dazu, dass der komplette restliche, momentan 

unbelegte Bereich der Label- 

Partition »a« zugeschlagen wird. Mit [W] 

(wiederum per Großbuchstabe) wird das 

Label schließlich geschrieben, wenn Sie 

die dafür verlangte Sicherheitsabfrage 

mit [y] bestätigen. Jetzt können Sie das 

Programm mit [Q] verlassen. Sicherheitshalber 

führen Sie gleich noch einen ersten 

Dateisystem-Check durch: 

fsck ‐fy /dev/rld0a 

Nun fahren Sie NetBSD mit »poweroff« 

auf der Kommandozeile herunter. Ist 

das System nach einiger Zeit zur Ruhe 

gekommen, wird die SD-Karte aus dem 

Raspberry entnommen. 

Die weiteren Arbeitsschritte führen Sie 

wieder in der virtuellen Maschine oder 

in der nativen NetBSD-Installation durch. 

Nach dem Booten von NetBSD auf dem 

PC stecken Sie die Karte ein und melden 

sich an. Das in Grün angezeigte Device 

fsck ‐fy /dev/rsd0a 

Das »/dev/r« bei den Geräteangaben können 

Sie übrigens auch weglassen, es wird 

dann ergänzt. 

Die Karte kann jetzt aus dem Intel-System 

aus- und in den Raspberry eingesteckt 

werden. Nach dem Booten zeigt »df« 

die neue Größe an. Auf dem ursprünglichen 

2-GByte-Image waren fast achtzig 

Prozent des Platzes belegt, bei einer 

4-GByte-Karte sind es jetzt nur noch vierzig 

Prozent. 

Von dieser mühsam produzierten Basis- 

Betriebssysteminstallation sollten Sie am 

besten ein Sicherungs-Image ziehen, unter 

Linux/Unix mit »dd«, unter Windows 

mit dem Win32DiskImager. (ofr) n 

Infos 

[1] Raspberry Pi: 

[http:// www. raspberrypi. org] 

[2] Beschreibung für die Installation von 

NetBSD/evbarm: [http:// wiki. netbsd. org/ 

ports/ evbarm/ raspberry_pi/] 

[3] Offizielle Installationsdateien für NetBSD/ 

evbarm zum Zeitpunkt des Schreibens 

dieses Beitrags: [ftp:// nyftp. netbsd. org/ 

pub/ NetBSD‐daily/ HEAD/ 201306120600Z/ 

evbarm/ binary/ sets/] 

[4] NetBSD-Image für den Raspberry Pi: 

[ftp:// ftp. netbsd. org/ pub/ NetBSD/ misc/ 

jun/ raspberry‐pi/ 2013‐03‐04‐netbsd‐raspi. 

img. gz] 

[5] Win32DiskImager: [http:// sourceforge. net/ 

projects/ win32diskimager/] 

[6] ISO-Images für die Installation von NetBSD 

6.1: [http:// ftp. netbsd. org/ pub/ NetBSD/ 

NetBSD‐6. 1/ iso/] 


Admin 


113

Service 

Impressum und Vorschau 

Impressum ISSN 2190-1066 

ADMIN-Magazin eine Publikation der Medialinx AG 

Redaktionsanschrift Putzbrunner Straße 71 

81739 München 

Tel.: 0 89/99 34 11-0 

Fax: 0 89/99 34 11-99 oder -96 

Internet 


E-Mail 

redaktion@admin-magazin.de 

Geschäftsleitung 

Chefredakteure 

Redaktion 

News/Report 

Software/Test 

Security/Networking 

Ständige Mitarbeiter 

Produktionsleitung 

Grafik 

Abo-Infoseite 

Abonnenten-Service 

Brian Osborn (Vorstand), bosborn@medialinx-gruppe.de 

Hermann Plank (Vorstand), hplank@medialinx-gruppe.de 

Oliver Frommel (V.i.S.d.P.), 

ofrommel@admin-magazin.de (ofr) 

Jens-Christoph Brendel 

jbrendel@admin-magazin.de (jcb) 

ulrich Bantle (Ltg.), ubantle@medialinx-gruppe.de (uba) 

Mathias Huber, mhuber@medialinx-gruppe.de (mhu) 

marcel Hilzinger, mhilzinger@medialinx-gruppe.de, (mhi) 

Kristian Kißling, kkissling@medialinx-gruppe.de, (kki) 

Markus Feilner, mfeilner@medialinx-gruppe.de (mfe) 

Thomas Leichtenstern, tleichtenstern@medialinx-gruppe.de (tle) 

David Göhler (Schlussredaktion), 

Carsten Schnober, Tim Schürmann, Claudia Thalgott 

Christian Ullrich, cullrich@medialinx-gruppe.de 

Klaus Rehfeld 

Titel: Judith Erb, Ausgangsgrafik: Luciano De Polo, 123RF 

www.admin-magazin.de/abo 

Gudrun Blanz (Teamleitung) 

abo@admin-magazin.de 

Tel.: 07131/27 07 274, Fax: 07131/27 07 78 601 

Preise Print Deutschland Österreich Schweiz Ausland EU 

Einzelheft € 9,80 € 10,80 Sfr 19,60 (siehe Titel) 

Mini-Abo (3 Ausgaben) € 9,80 € 10,80 Sfr 19,60 (siehe Titel) 

Jahres-DVD (Einzelpreis) € 14,95 € 14,95 Sfr 18,90 € 14,95 

Jahres-DVD (zum Abo 1 ) € 6,70 € 6,70 Sfr 8,50 € 6,70 

Jahresabo € 99,90 € 109,90 Sfr 159,90 € 129,90 

Preise Digital Deutschland Österreich Schweiz Ausland EU 

Heft-PDF Einzelausgabe € 9,80 € 9,80 Sfr 10,71 € 9,80 

DigiSub (12 Ausgaben) € 89,90 € 89,90 Sfr 129,50 € 89,90 

DigiSub (zum Printabo) € 12,— € 12,— sfr 12,— € 12,— 

HTML-Archiv (zum Abo 1 ) € 48,— € 48,— sfr 48,— € 48,— 

Preise Kombiabos 

Profi-Abo 2 € 181,90 € 198,90 Sfr 235,90 € 219,90 

1 

nur erhältlich in Verbindung mit einem Jahresabo Print oder Digital 

2 

mit Linux-Magazin-Abo und beiden Jahres-DVDs 

Schüler- und Studenten-Ermäßigung: 20 Prozent gegen Vorlage eines Schülerausweises oder einer aktuellen 

Immatrikulationsbescheinigung. Der aktuelle Nachweis ist bei Verlängerung neu zu erbringen. Andere Abo- 

Formen, Ermäßigungen im Ausland etc. auf Anfrage. 

Adressänderungen bitte umgehend mitteilen, da Nachsendeaufträge bei der Post nicht für Zeitschriften gelten. 

Pressemitteilungen info@admin-magazin.de 

Anzeigen/Repräsentanz Es gilt die Anzeigenpreisliste vom 01.01.2013 

National 

Pressevertrieb 

Druck 

Petra Jaser 

Tel.: 089/99 34 11 24, Fax: 089/99 34 11 99 

E-Mail: pjaser@medialinx-gruppe.de 

michael Seiter 

Tel.: 089/99 34 11 23, Fax: 089/99 34 11 99 

E-Mail: mseiter@medialinx-gruppe.de 

MZV, Moderner Zeitschriften Vertrieb GmbH 

Breslauer Straße 5, 85386 Eching 

Tel.: 089/31906-0, Fax: 089/31906-113 

Vogel Druck und Medienservice GmbH 

97204 Höchberg 

Der Begriff Unix wird in dieser Schreibweise als generelle Bezeichnung für die Unix-ähnlichen Betriebssysteme verschiedener 

Hersteller, zum Beispiel Eurix (Comfood), Ultrix (Digital Equipment), HP/UX (Hewlett-Packard) oder Sinix (Siemens) benutzt, 

nicht als die Bezeichnung für das Trademark von X/Open. Linux ist ein eingetragenes Marken zeichen von Linus Torvalds und 

wird in unserem Markennamen mit seiner Erlaubnis verwendet. Alle anderen Marken sind Eigentum der jeweiligen Inhaber. 

Eine Haftung für die Richtigkeit von Veröffentlichungen kann trotz sorgfältiger Prüfung durch die Redaktion vom Verlag 

nicht übernommen werden. Mit der Einsendung von Manu s kripten gibt der Verfasser seine Zustimmung zum Abdruck im 

ADMIN-Magazin. Für unverlangt ein gesandte Manuskripte kann keine Haftung übernommen werden. Die Redaktion behält 

sich vor, Artikel zu kürzen. Das Exklusiv- und Verfügungsrecht für angenommene Manuskripte liegt beim Verlag. Es darf kein 

Teil des Inhalts ohne ausdrückliche schriftliche Genehmigung des Verlags in irgendeiner Form vervielfältigt oder verbreitet 

werden. Copyright © 1994–2013 Medialinx AG 

Inserentenverzeichnis 

Netgear http://www.netgear.de 39 

AddOn Systemhaus GmbH http://www.addon.de 65 

Android User GY http://www.android-user.de 111 

Angel Business Communications Ltd http://www.angelbc.co.uk 71 

ConSol Software GmbH http://www.consol.de 11 

Deutsche Python Konferenz - PyCon http://de.pycon.org 77 

Diavlon GmbH http://www.tuxhardware.de 13 

Fernschule Weber GmbH http://www.fernschule-weber.de 17 

Galileo Press http://www.galileo-press.de 19 

Host Europe GmbH http://www.hosteurope.de 51 

IT-Security Messe http://www.it-sa.de 67 

Kettner Mathias - Linux Experte http://www.mathias-kettner.de 75 

Linux-Hotel http://www.linuxhotel.de 53 

Linux-Magazin http://www.linux-magazin.de 91 

Medialinx IT-Academy http://www.medialinx-academy.de 79, 87, 99 

Netways GmbH http://www.netways.de 61 

outbox AG http://www.outbox.de 2 

pascom - Netzwerktechnik GmbH & Co.KG http://www.pascom.net 37 

PlusServer AG http://www.plusserver.de 7, 9, 21, 27, 30, 43, 55 

QNAP Systems http://www.qnap.com/de/index.php 47 

Raspberry Pi Geek http://www.raspberry-pi-geek.de 115 

Thomas Krenn AG http://www.thomas-krenn.com 116 

Windows Phone User http://www.windows-phone-user.de 73, 89 

Dieser Ausgabe liegt eine Sonderbeilage des ADMIN-Magazin (http://www.admin-magazin.de) bei. 

Wir bitten unsere Leser um freundliche Beachtung. 

Autoren dieser Ausgabe 

Jörg Braun Netberry 108 

Martin Braun Technisches K.O. 80 

Michael Bredel Leitstandstechnik 68 

Jürgen Dankoweit Scharf gewürzt 102 

Bernd Erk Griff zu den Sternen 28 

Torsten Förtsch Ans Licht gebracht 94 

Andrea Held Datenbank zum Einstöpseln 84 

Bernd Helmle Datenbank-Tuning 48 

Geoff Higginbottom Gut vernetzt 34 

Thomas Joos Alles, was recht ist 62 

Thomas Joos Moderne Bilder 76 

Anna Kobylinska Krieg in den Wolken 16 

Martin Loschwitz Bausteinprinzip 22 

Thorsten Scherf Spaziergang 14 

Tim Schürmann Koalas Liebling 40 

Jörg Steffens Besser sichern 56 

Philipp Storz Besser sichern 56 

VORSCHAU 

ADMIN 11/2013 erscheint am 10. Oktober 2013 

Privacy 

Config Packets 

© Maksim Kabakou, 123RF 

Wer nichts tut, steht nackt da: 

Private Daten muss man aktiv 

schützen. Das beginnt bei passwortgesicherten 

Festplatten, führt 

etwa über Security-Plugins für den 

Browser und hört bei Anonymisierern 

wie Tor noch nicht auf. 

Die Idee ist bestechend: Mit der Paketverwaltung 

existiert unter Linux 

bereits ein System, das vielfältige 

Aktionen in einer bestimmten 

Reihenfolge anstoßen kann: Könnte 

man damit nicht die gesamte Konfiguration 

erledigen und verwalten? 

© Dirk Ercken, 123RF

ADMIN Magazin Freie Clouds (Vorschau)

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?