ADMIN Magazin Erste Hilfe - Disaster Recovery (Vorschau)

Jetzt 

mit 

SMB3 für VMs 

und Storage 

UEFI Secure 

Boot und Linux 

ADMIN 

IT-Praxis & Strategie 

Software Defined 

Networking 

Redo 

Backup & Recovery 

03/2014 März 

Erste Hilfe 

Disaster Recovery 

Linux-Recovery mit Boot-CD 

Tipps zur Windows-Rettung 

Datenbank-Recovery 

Hyper-V 

Schnelle Linux-VMs durch 

Integration Services 

CRIU 

Prozesse einfrieren und 

wieder auftauen 

HA-Proxy 

Loadbalancing 

mit SSL-Support 

Spanning Tree 

Ethernet ohne Schleifen 

www.admin-magazin.de 

Raspberry Pi 

Mini-PC mit FreeBSD 

D EUR 9,80 

A EUR 10,80 - BeNeLux EUR 11,25 

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

4 196360 509805 03

Service 

Editorial 

3 

Es war einmal 

Liebe Leserinnen und Leser, 

Es war einmal ein fleißiger Programmierer, der lebte in einem fernen Land. 

Er setzte sich zum Ziel, ein Programm zu schreiben, das Computer überwachen 

sollte. Das taufte er NetSaint, später Nagios. 

Die Kunde von Nagios verbreitete sich rasch und so scharte der Programmierer 

bald ein Häuflein Mitstreiter um sich, das ihm zur Hand ging. Im Lauf 

der Jahre installierten immer mehr Anwender seine Software, immer mehr 

Freiwillige trugen Verbesserungen und Erweiterungen bei. Und bald traten 

landauf, landab auch Berater auf, die sich so manchen Dukaten damit verdienten, 

Nagios für andere einzurichten und anzupassen. 

Allmählich gewann der Programmierer den Eindruck, er habe da einen dicken Fisch an der Angel. Den 

wollte er nicht schwimmen lassen, es sei denn, er habe drei Wünsche frei. Und so rief er: „Mantje, Mantje, 

Timpe Te, Buttje, Buttje in der See.“ Und der Fisch kam angeschwommen und fragte, was er wolle. „Ach“, 

sagte der Programmierer, „ich habe nun meine ganze Freizeit in Nagios investiert, aber reich werden 

andere damit. Ich wünsche mir eine eigene Firma, die mir mein täglich Brot sichern soll.“ „Geh nur hin“, 

sagte der Fisch, „du hast sie schon.“ 

Nach einer Weile kam dem Programmierer jedoch in den Sinn, ob er nicht einen noch viel größeren Reibach 

machen könnte, wenn es nur ihm allein erlaubt wäre, den Namen seiner Software im Munde zu führen. 

Den Webmastern aber, die Zusätze für Nagios hosteten, den Veranstaltern, die Nagios-Konferenzen 

ausrichteten, den Enthusiasten, die Nagios-Foren pflegten und den Programmierern, die Nagios-Plugins 

entwickelten, sollte das fortan verboten sein. Sie alle hatten ihn groß gemacht, doch nun hatten sie ihre 

Schuldigkeit getan. So ging er wieder ans Wasser und rief den Fisch. Der fragte, was er diesmal wolle. 

„Ich möchte, dass niemand mehr irgendetwas nach Nagios benennt. Wer es dennoch tut, soll wegen 

Markenrechtsverletzung vor den Kadi kommen.“ „Geh nur hin“, sagte der Fisch, „das hast du schon.“ 

Wieder arbeitete der Programmierer eine Zeit zufrieden an seiner Software. Da fiel sein Blick auf die letzten 

Getreuen, die Plugins entwickelten und sie auf einer Webseite nagios-plugins.org anboten. Auch mit 

denen wollte er nun kurzen Prozess machen. Reden wollte er nicht. Also rief er den Fisch und das Wasser 

war ganz violett und grau. Und nachdem der Fisch zum dritten Mal von dannen geschwommen war, verbogen 

sich hinterrücks die DNS-Einträge für nagios-plugins.org auf einen Server, den nur der Programmierer 

kontrollierte. Und die ahnungslosen Plugin-Entwickler waren über Nacht ausgesperrt. 

Noch einmal war der Programierer eine kurze Zeit zufrieden, dann rief er den Fisch zum vierten Mal. Da 

war die See ganz schwarzgrau und das Wasser gärte. Und er sagte … Halt! Weiter ist das Märchen noch 

nicht geschrieben. Aber wir ahnen, wie es ausgehen wird. Im Märchen siegt ja oft die Gerechtigkeit. 

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


Admin 

Ausgabe 03-2014

Service 

4 Inhalt 



Erste Hilfeab Seite 36 

n Login 

8 Bücher 

Ansible und SNMP. 

10 Branchen-News 

Neues von Software und Projekten. 

14 Admin-Story 

Systemverwaltung mit OpenLMI. 

n Netzwerk 

18 Spanning Tree Protocol 

Wie organisiert Spanning Tree ein 

Ethernet-Netzwerk? 

24 OpenNMS und OCS 

OCS-Informationen in Überwachung 

mit OpenNMS integrieren. 

32 HA-Proxy 

Passthrough und Offloading: 

HTTPS balancieren mit der nächsten 

HA-Proxy-Version 1.5. 

n Schwerpunkt 

36 Redo Backup 

Systeme vollständig sichern und 

wiederherstellen mit Redo Backup. 

40 Relax and Recover 

Rettungsmedien per Bash im 

laufenden System erzeugen. 

46 Windows-Disaster 

Disaster Recovery mit Windows. 

52 Database Recovery 

Backup und Recovery bei Datenbanken: 

Woran man denken sollte. 

Tree 

Bäume statt Schleifen im 

18Spanning 

Ethernet. 

Service 

3 Editorial 

4 Inhalt 

6 Heft-CD 

114 Impressum und Vorschau 

Ausgabe 03-2014 

Admin 

www.admin-magazin.de

Service 

Inhalt 

5 

Auf Dateizugriffe automatisch 

64Incron 

reagieren. 

86Fedora 

Die neue Version der 

freien Red-Hat-Variante. 

Redo 

Backup & Recovery 

Seite 6 und 36 

n Know-how 

58 Neutron 

OpenStack Neutron als Beispiel für 

eine SDN-Implementierung. 

64 Incron 

Dateien und Verzeichnisse mit 

Incron überwachen. 

68 CRIU 

Linux-Prozesse speichern und 

wieder herstellen mit CRIU. 

74 Cloud Orchestration 

Automatisierung in der Cloud: Alles 

über Orchestration. 

n Security 

80 UEFI Secure Boot 

UEFI Secure Boot und alternative 

Betriebssysteme. 

n Basics 

86 Fedora 20 

Das neue Fedora-Release im Test. 

90 ADMIN-Tipps 

Die monatlichen Praxis-Tipps der 

Redaktion. 

n Virtualisierung 

92 Hyper-V und SMB3 

Von der neuen SMB-Version profitiert 

vor allem Hyper-V. 

96 MS Linux Integration Services 

Linux-VMs unter Hyper-V mit den 

MS Linux Integration Services 

beschleunigen. 

n Programmieren 

100 Go-Entwicklung 

Goroutinen und Channels. 

n FreeX 

106 FreeBSD Raspberry Pi 

FreeBSD läuft auch auf dem 

Rasp berry PI. 

68CRIU 

Linux-Prozesse einfrieren, 

analysieren und migrieren. 

106Raspberry Pi 

So kommt BSD auf den 

populären Mini-Computer. 

Ausgabe 03-2014

6 

Service 

Heft-CD 

CD kaputt? 

Wir schicken Ihnen kostenlos eine Ersatz-CD 

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

Redo Backup 1.0.4 

Heft-CD 

Auf dem beiliegenden Datenträger finden Sie das Backup- und 

Restore-System Redo Backup. Ausführlicher Artikel auf S. 36 

n Info 

Weiterführende Links und 

Informationen zu diesem 

Artikel finden Sie unter: 

www.admin-magazin.de/qr/31687 

[1] Redo Backup: [http://redobackup.org] 

n Recovery-Live-CD basierend auf 

Ubuntu Linux. 

n Sicherung und Wiederherstellung 

ganzer Betriebssysteme. 

n Vereinfachte Benutzeroberfläche 

auf Basis von Openbox und 

ADeskBar. 

n Live-CD mit Partclone, GParted 

und Red Hat Disk Utility für Dateisysteme 

und Partitionen. 

Legen Sie einfach die CD ins Laufwerk 

ein und starten Sie den Rechner. 

Möglicherweise müssen Sie noch im 

BIOS die richtige Boot-Reihenfolge 

einstellen. Danach können Sie Redo 

Backup starten und Ihr System sichern 

oder wiederherstellen und die 

mitgelieferten Tools zur Analyse und 

Reparatur von Partitionen und Dateisystemen 

starten. n 

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

8 

Login 

Bücher 

Galina Peshkova, 123RF 

Neue Bücher zu Ansible und zum Simple Network Management Protocol 

Vorgelesen 

Systemadministratoren erfahren alles über die automatische Serverpflege 

mit Ansible sowie über das Simple Network Management 

Protocol SNMP. Oliver Frommel, Carsten Schnober 

Ansible ist jung und hip: Das quelloffene 

Python-Tool administriert Rechner 

übers Netzwerk via SSH, ganz ohne 

die Installation weiterer 

Software. Der Verlag Packt 

Publishing hat mit »Ansible 

Configuration Management« 

von Daniel Hall ein 

englischsprachiges Buch 

herausgebracht, das einen 

Überblick über das Werkzeug 

gibt. Es ist das bisher 

einzige Buch des Informatikers, 

der als System administrator Ansible 

im Berufsalltag einsetzt. 

Der Autor hält sich nicht mit Exkursen 

auf und setzt voraus, dass die Leser 

mit den grundlegenden Konzepten der 

Linux-Administration vertraut sind und 

bereits das Netzwerk sowie Tools wie 

SSH passend konfiguriert haben. So 

kommt er direkt zum Ansible-Setup. 

Dabei spielt er typische Szenarien an 

realistischen Beispielen wie dem per 

Ansible automatisierten Setup von 

Datenbanken durch. Auf diese Weise 

erhält der Leser einen Einblick in die 

Ansible-übliche Vorgehensweise, aus 

den zweckgebundenen Modulen sogenannte 

Playbooks zu schreiben. 

n Ansible 

Daniel Hall 

Ansible Configuration Management 

Packt Publishing, 2013 

92 Seiten 

25,99 Euro 

ISBN: 978-1783280810 

Von überschaubaren Setups, die in 

Syntax und Aufbau der Playbooks 

einführen, geht es weiter zu komplexeren 

Anwendungen. Bei 

Schleifen und Bedingungen 

kommen Tricks und Design 

Patterns auch für größere 

Umgebungen zur Sprache. Das 

fünfte Kapitel geht abschließend 

auf die Entwicklung und 

Verwendung eigener Ansible- 

Module ein. 

Dem Buch gelingt es, mit anschaulichen 

Beispielen auf 

knapp 100 Seiten einen 

Überblick über die Möglichkeiten 

von Ansible zu 

geben. Die Möglichkeit, 

trotz geringen Umfangs 

auch speziellere Themen 

anzusprechen, verdankt 

es dem ebenfalls auf Übersichtlichkeit 

getrimmten 

Aufbau von Ansible. 

Akronymisch 

Wegen der niedrigen Auflagen sind 

viele Verlage dazu übergangen, ihre 

IT-Fachbücher nur noch „On Demand“ 

zu drucken. So verhält es sich auch 

mit der neuen Auflage des Klassikers 

„SNMPv3, SNMPv2, SNMP and RMON 1 

and 2“ von William Stallings, das inhaltlich 

der dritten Auflage der Hardcover- 

Ausgabe entspricht. 

Der Inhalt ist mit dem Titel detailliert 

beschrieben, auch wenn der Abhandlung 

der Standards noch eine Mini- 

Einführung in Netzwerk-Monitoring 

vor ausgeht. Stallings verortet SNMP 

(Simple Network Management Protocol) 

zunächst im Kontext von TCP/IP. Im 

Detail geht er auf Funktion und Aufbau 

von MIBs sowie das SNMP-Protokoll 

ein. Dann diskutiert er die Motivation 

für die Einführung von RMON, bevor er 

im Detail die Spezifikation durchgeht. 

Auch bei den Erweiterungen SNMPv2/3 

und RMON 2 beschränkt sich der Autor 

darauf, die Spezifikation der Protokolle 

zu kommentieren. Konkrete Tipps 

zum praktischen Einsatz gibt er dabei 

nicht. Im Anhang des Buchs findet sich 

noch eine kurze Erläuterung des TCP/ 

IP-Protokolls und der abstrakten Syntaxnotation 

ASN.1. 

Wer eine Anleitung zum praktischen 

Einsatz von SNMP und RMON 

sucht, wird von dem Buch enttäuscht 

sein. Es wird seinem 

Anspruch, unter anderem auch 

ein „definitive guide“ zu SNMP 

für „network administrators“ 

zu sein, nicht gerecht – es sei 

denn der Netzwerk-Administrator 

möchte die Protokolle 

über den praktischen Einsatz 

hinaus im Detail verstehen. Eher kann 

Stallings’ Buch als Referenz für denjenigen 

dienen, der SNMP- oder RMON- 

Software implementieren und etwas 

mehr Informationen haben möchte, als 

in den RFCs enthalten ist. n 

n SNMPv3 

William Stallings 

SNMPv3, SNMPv2, SNMP and RMON 1 

and 2 

Addison Wesley, 2013 

640 Seiten 

57 Euro 

ISBN-13: 978-0321952028 


10 

Login 

News 

Neue Software und Produkte 

Branchen-News 

BSI: 16 Millionen Online-Accounts gehackt 

Bei der Analyse von Bot-Netzen wurden laut des Bundesamts für Sicherheit 

in der Informationstechnik (BSI) insgesamt 16 Millionen Online-Identitäten 

entdeckt. Das BSI besitzt nun eine Liste dieser aus E-Mail-Adresse und Passwort 

bestehenden Accounts, die als Zugangsdaten für Mail-Konten, Online- 

Shops und andere Internetdienste dienen. 

Im Rahmen der gesetzlichen Warnpflicht bietet das BSI unter der Adresse 

[1] ein Online-Tool an, mit dem sich überprüfen lässt, ob sich die eigene 

Adres se unter den gehackten Accounts befindet. Nachdem man bestätigt 

hat, dass man der Besitzer der Adresse ist, bekommt man eine E-Mail vom 

BSI, die mit einem Code die Echtheit der Mail sicherstellt. Ist die Adresse 

nicht in der Liste vertreten, passiert nichts. Das BSI speichert die eingegebenen 

Adressen zur Verarbeitung zwischen, will sie aber nach der Prüfung 

wieder löschen. 

15 Millionen für Docker 

Die Firma hinter der Linux-Virtualisierungstechnologie 

Docker erhält von 

verschiedenen Geldgebern zusammen 

15 Millionen US-Dollar. Insgesamt wurden 

damit bereits 26 Millionen US-Dollar 

in die ursprünglich unter dem Namen 

dotCloud gegründete Firma investiert. 

Jetzt konzentriert sie sich unter dem Namen 

Docker auf die Entwicklung der unter 

einer Open-Source-Lizenz stehenden 

Virtualisierungstechnologie, die auf den 

Linux-Containern LXC beruhen. 

Im Vergleich zu Hypervisoren wie VMware 

oder KVM erlaubt LXC die vergleichsweise 

geringe Ressourcen erfordernde Virtualisierung 

einzelner Anwendungen. Docker 

stellt eine Infrastruktur bereit, die die 

Installation und Verwaltung von solchen 

Containern stark vereinfacht. 

Innerhalb kürzester Zeit hat Docker einen 

recht hohen Bekanntheits- und Beliebtheitsgrad 

erlangt und auch schnell prominente 

Helfer in der Open-Source- und 

Business-Welt gefunden. So hat Red Hat 

ein Backend für Docker geschrieben, 

das dessen Nutzung auch auf Linux- 

Distributionen erlaubt, die nicht über das 

Overlay-Dateisystem AuFS verfügen, das 

Docker bis dahin voraussetzte. 

Kühlschrank im Bot-Netz? 

Das Security-Unternehmen Proofpoint hat festgestellt, dass bei einer aktuellen Spamund 

Phishing-Attacke knapp 15 Prozent des Traffic nicht von PCs, Laptops und konventionellen 

Mobilgeräten stammt, sondern von gehackten Routern, Multimedia-Centern, 

Fernsehern und „mindestens einem Kühlschrank“. Dabei handle es sich möglicherweise 

um den ersten dokumentierten Angriff mit Beteiligung des Internet of Things, wie die 

zunehmende Vernetzung von Kleingeräten bezeichnet wird. Insgesamt hat Proofpoint 

im Rahmen des Angriffs 750 000 E-Mails registriert, von denen 100 000 nicht von konventionellen 

Rechnern stammen. Der Angriff ereignete sich im Zeitraum vom 23. Dezember 

2013 bis zum 6. Januar 2014. Dabei wurden von jeder einzelnen IP-Adresse nicht mehr 

als zehn Schad-E-Mails verschickt. 

„Bot-Netze sind schon ein großes Sicherheitsproblem, 

und das Auftreten von Thingbots macht 

die Sache noch schlimmer“, so David Knight, der 

General Manager von Proofpoints Abteilung für 

Informationssicherheit. „Viele dieser Geräte sind 

nur schlecht abgesichert und ihre Besitzer haben 

praktisch keine Möglichkeit, festzustellen, ob 

sich Malware darauf eingenistet hat, geschweige 

denn, sie zu entfernen.“ 

Ob sich hinter dem von Proofpoint identifizierten 

Gerät allerdings wirklich ein Kühlschrank 

befindet, ist fraglich, denn konkrete Informationen 

dazu liefert die Firma nicht. Man sei auf 

einen Log in-Prompt „Welcome to your Fridge“ 

gestoßen, was kaum der Realität eines Benutzer- 

Interfaces der wenigen auf dem Markt verfügbaren 

Geräte entsprechen dürfte. Außerdem ist die 

Frage offen, warum der angebliche Kühlschrank 

überhaupt übers Internet erreichbar ist. Oft ist es 

auch nur ein Scherz, ein Unix-System mit einem 

Fake-Prompt wie dem obigen auszustatten. 

Guilherme Martins, 123RF 


Login 

News 

11 

Linux 3.13 löst Iptables ab 

Mit Version 3.13 ist eine neue Version des Linux-Kernels erschienen. 

Darin löst das Tool Nftables das alte Firewall-Konfigurationswerkzeug 

Iptables ab. Das neue Framework bleibt vorerst 

mit Iptables abwärtskompatibel, das Iptables-Nftables-Werkzeugset 

konvertiert Iptables-Regeln direkt in Nftables-Bytecode. 

Es unterstützt sogar bislang von Iptables nicht unterstützte Features 

wie Benachrichtigungen bei Änderungen an der Firewall, 

inkrementelle Updates von Firewall-Regeln und das Ein- und 

Ausschalten einzelner Chains pro Tabelle. 

Neben Nftables erhöht Linux 3.13 die Lese- und Schreibgeschwindigkeit 

auf Speichergeräten im Hinblick auf SSD-Platten. 

Ein neues Design des Block-Device-Zugriffs basiert auf zwei 

separaten Warteschlangen für Lese- und Schreibvorgänge: Die 

erste nimmt pro CPU Zugriffsanfragen entgegen und gibt diese 

an eine eigene Warteschlange der Speicher-Hardware weiter. 

Diese Methode ermöglicht statt der bisher 

höchstens 800 000 Schreib- und Lesezugriffe 

pro Sekunde mehrere Millionen. 

Weiterhin spart die neue Ausgabe des 

Betriebssystem-Kernels mit der Power-Management-Unterstützung 

bei 

vielen AMD-Radeon-Grafikkarten 

Strom und erzielt damit auch 

bessere Performance durch die 

Möglichkeit, die Taktfrequenz 

umzuschalten. 

Weitere neue Features 

umfassen eine Schnittstelle 

für Secure Element, 

über das künftig Anwendungen 

Bezahlungen per 

NFC (Near Field Communication) 

abwickeln können, Performance-Verbesserungen bei 

NUMA-Zugriffen (Non-uniform Memory Access), SquashFS und 

weiteren Komponenten. 

FreeBSD 10.0 fertiggestellt 

Einige Wochen später als geplant haben die FreeBSD-Entwickler 

das neueste Release ihres Betriebssystems veröffentlicht [2]. 

Anwender kommen in den Genuss einiger Neuerungen wie dem 

Compiler LLVM/Clang, der nun standardmäßig verwendet wird – der 

Gnu-Compiler GCC gehört nun nicht mehr zum Basissystem. Neu 

geschrieben wurden der iSCSI-Stack und das CARP-Subsystem, das 

redundante IP-Adressen für hochverfügbare Setups bereitstellt. 

Auch das ZFS-Dateisystem wurde verbessert. Es unterstützt nun für 

SSDs das TRIM-Kommando, das hilft, einen Performance-Abfall der 

Flash-Speicher bei längerer Nutzung zu verhindern. Zur Komprimierung 

von Daten beherrscht ZFS jetzt auch den LZ4-Algorithmus. 

Ein Algorithmus, der das erneute Berechnen von Check summen 

vermeidet und damit potenziell die Performance des Dateisystems 

verbessert, wurde vom Solaris-Fork Illumos übernommen. 

Im Bereich der Virtualisierung wartet FreeBSD mit einem von Grund 

auf neu entwickelten Typ-2-Hypervisor namens Beehyve auf. Für 

die Paravirtualisierung von I/O-Devices unterstützt Beehyve die von 

Linux bekannte VirtIO-Schnittstelle. Beehyve setzt einen Prozessor 

mit den Features VT und EPT voraus, über die moderne Intel- und 

AMD-Prozessoren verfügen. Jenseits der Virtualisierung bietet das 

neue FreeBSD-Release aber umfangreichen Support für ARM-Prozessoren 

und unterstützt beispielsweise auch den Raspberry Pi. 

Anzeige 

SDN: Oracle kauft Corente 

Wie die Firma Oracle bekanntgibt, wird sie den SDN-Anbieter 

(Software Defined Networking) Corente übernehmen. Damit 

will Oracle sein Cloud-Angebot durch WAN-Virtualisierung ergänzen, 

die Corente anbietet. Kunden sollen damit sicher auf 

Anwendungen zugreifen können, die in der Cloud zur Verfügung 

stehen. In den letzten Jahren hat Oracle mit Xsigo und Acme 

Packets bereits andere Anbieter von Netzwerk-Virtualisierungstechnologie 

übernommen. 

Software Defined Networking ist der kommende Trend, bei dem 

traditionelle Anbieter von Virtualisierungssoftware in Konkurrenz 

zu Herstellern von Netzwerk-Hardware wie Cisco und Juniper 

treten, die ihrerseits ebenfalls SDN-Technologien auf den 

Markt bringen oder einkaufen. Die Linux Foundation versucht 

unterdessen, mit dem OpenDaylight-Projekt ein Konsortium 

für die Standardisierung von Software Defined Networking zu 

etablieren. 


12 

Login 

News 

Red Hat integriert freie Linux-Distribution CentOS 

Das Community-Projekt CentOS entwickelt seit zehn Jahren 

eine freie Version der Enterprise-Distribution Red Hat Enterprise 

Linux (RHEL). Die CentOS-Entwickler verwenden die 

dem Betriebssystem zugrunde liegenden freien Quellen und 

veröffentlichen meist wenige Tage bis Wochen nach Erscheinen 

einer neuen RHEL-Version ein freies Pendant. Red Hat 

Enterprise Linux ist hingegen nur mit einem kostenpflichtigen 

Support-Vertrag erhältlich. 

Wie Red Hat jetzt bekannt gegeben hat, integriert die Firma 

CentOS nun ins eigene Portfolio und will neue Technologien 

und Software-Versionen direkt in CentOS einbringen. Damit 

wird die Linux-Strategie der Firma zumindest vorerst dreigleisig: 

Red Hat Enterprise Linux richtet sich weiterhin mit 

langjährigem Support, garantierten Sicherheitsupdates und 

Fehlerkorrekturen, Rechtsschutz sowie Schulungsangeboten 

an Firmenkunden. CentOS soll der Community vor allem 

neue Cloud-, Storage-, Netzwerk- und Infrastrukturtechnologien 

nahebringen. Das ebenfalls freie Fedora soll daneben 

neue Technologien auf der ganzen Breite vom Kernel bis zum 

Desktop integrieren. 

Bislang nutzte Red Hat die freie Linux-Distribution Fedora als 

eine Art Experimentierfeld, in der die breite Entwickler- und 

Benutzer-Community neue Technologien kostenlos ausprobierte 

und durch ihr Feedback und eigene Patches verbesserte. 

Red Hat übernimmt diese daraufhin gegebenenfalls in 

RHEL. Wie Fedora und CentOS sich künftig unterscheiden, 

bleibt abzuwarten. 

Die Integration von CentOS ins Red-Hat-Ökosystem kann 

auch als Scheitern der bisherigen Strategie interpretiert 

werden, bei der Red Hat CentOS anscheinend eher als Dorn 

im Auge betrachtet hatte. So 

veröffentlichte die Firma ihre 

Kernel-Patches seit 2011 nicht 

mehr einzeln, sondern nur als 

impliziten Teil des Quellcodes. Die 

Umstellung zielte zwar vor allem auf ein Konkurrenzprodukt 

von Oracle auf Basis des Red-Hat-Codes ab, machte aber 

auch den CentOS-Entwicklern das Leben schwerer. CentOS- 

Entwickler berichteten in der Vergangenheit außerdem, dass 

Red Hat ihre Konten für die Plattform Red Hat Network (RHN) 

sperrte. 

CentOS-Hauptentwickler Karanbir Singh und andere Mitglieder 

des Entwicklungsteams arbeiten nach Medienberichten 

nun direkt für Red Hat. Singhs Pläne für die nahe Zukunft 

von CentOS sehen vor, den Entwicklungsprozess offener 

zu gestalten, etwa durch die Einrichtung eines öffentlichen 

Git-Repositories mit dem gesamten CentOS-Quellcode, die 

Möglichkeit, an themenspezifischen Arbeitsgruppen (Special 

Interest Groups) mitzuarbeiten und solche ins Leben zu rufen, 

die Erweiterung der Zusatzsoftware-Repositories, einen 

konkreten Release-Zeitplan sowie wöchentliche, öffentlich 

zugängliche Treffen des CentOS-Boards. Bisher scheiterte die 

öffentliche Entwicklung an den Rechten der Marke „Red Hat“. 

Red Hat erhofft sich von dem Schritt eine Festigung der Red- 

Hat-Community. Red Hats Technologiechef Brian Stevens 

sieht in der Integration von CentOS die Möglichkeit, wichtige 

neue Projekte wie OpenStack und Big-Data-Anwendungen 

einem größeren Publikum nahezubringen und Red Hat damit 

die Möglichkeit zu geben, solche Technologien als Erster zu 

implementieren. 

Neuauflage von Linksys-Router WRT54G 

Die Firma Linksys hat einen Nachfolger 

des beliebten WLAN-Routers 

WRT54G vorgestellt. Das neue Modell 

WRT1900AC ähnelt äußerlich seinem 

Vorgänger, wurde aber im Design 

modernisiert. Das Gerät besitzt vier 

abnehmbare Antennen und einen 

eSATA-Port sowie Anschlüsse für USB 

2.0 und 3.0. Netzwerkseitig bringt der 

neue Router Gigabit-Ports für LAN und 

den Internet-Uplink mit. Auch beim 

WLAN unterstützt der WRT1900AC mit 

dem Standard IEEE 802.11ac Gigabit- 

Bandbreiten. 

Nach eigener Aussage trägt Linksys 

mit der Neuauflage des Routers auch 

den vielfachen Wünschen von Kunden 

Rechnung, die gerne den alten Router 

in einer modernisierten Ausgabe gesehen 

hätten. Beliebt war er unter anderem, 

weil er sich gut zur Entwicklung 

von Firmware auf Linux-Basis eignete. 

In dieser Hinsicht gibt sich Linksys offen 

und unterstützt Open-Source-Projekte 

wie DD-WRT, OpenWRT und Tomato, 

deren Custom-Firmware zur Beliebtheit 

des Vorgängers beigetragen hatten. 

Im Frühjar 2014 soll es ein erstes 

Firmware-Image von OpenWRT für den 

neuen Router geben. Kosten soll das 

Gerät etwa 300 US-Dollar. 


IBM-Hauptspeicherlösung für Big Data 

IBM hat die sechste Generation der Enterprise-X-Architektur für Intel-x86-Prozessor-basierte 

IBM-System-x- und PureSystems-Server angekündigt. Sie bietet 

wesentliche Verbesserungen in Leistung und Wirtschaftlichkeit für Analytik- und 

Cloud-Aufgaben. Integrierter eXFlash-Memory-Channel-Speicher – eine branchenweite 

Neuheit – bietet bis zu 12,8 TByte schnellen Flash-Speicher nahe am Prozessor. 

Das erhöht die Anwendungsleistung durch die kürzeste derzeit verfügbare 

Systemschreib latenzzeit, die besonders für Analytik-Anwendungen essenziell 

ist. Besonders Datenbankoperationen profitieren und die Speicherkosten sinken 

durch die Reduzierung oder sogar Abschaffung von externen SAN/NAS-Speichereinheiten. 

Mit einem modularen, skalierbarem Design, das mehrere Generationen an CPUs 

unterstützen soll, fallen die Anschaffungskosten im Vergleich zu Konkurrenzprodukten 

bis zu 28 Prozent geringer aus. Das autonome, selbstheilende CPU- und 

Speichersystem maximiert außerdem die Betriebszeit von Anwendungen, indem 

es potenzielle Ausfälle identifiziert und vorher Gegenmaßnahmen ergreift. 

Die Servermodelle mit der neuen Architektur umfassen derzeit das System x3850 

X6 mit vier Sockeln, das System x3950 X6 mit acht Sockeln und die skalierbaren 

IBM-Flex-System-x880-Rechenknoten. IBM kündigt ebenso den System x3650 M4 

BD-Storage Server an, einen Rack-Server mit zwei Sockeln, der bis zu 14 Laufwerke 

mit bis zu 56 Terabyte an High-Density-Speicher unterstützt. Es bietet eine um bis 

zu 46 Prozent höhere Leistung als vorherige, vergleichbare IBM-System-x-Server 

und ist ideal geeignet für verteiltes Scale-out von Big-Data-Workloads. 

n Info 

Neueste nachrichten 

immer auf 






[1] BSI-Test: [https://www.sicherheitstest.bsi.de/] 

[2] Neues in FreeBSD 10: 

[https://wiki.freebsd.org/WhatsNew/FreeBSD10]

14 

Login 

Admin-Story 

Management mit OpenLMI 

Polyglotter 

Manager 

yadvigagr, 123RF 

Der versierte Linux-Admin verwaltet 

seine Systeme mittels 

Shell-Skripten. Für komplexe 

Aufgaben kommen andere 

Skript-Interpreter wie Python 

und Perl zum Einsatz. Mit Open- 

LMI steht nun eine neue Methode 

zur Verwaltung von Linux-Systemen 

zur Verfügung – sie basiert 

sogar auf einem offenen Industrie-Standard. 

Thorsten Scherf 

Die meisten Administratoren haben 

sich im Lauf der Zeit ihre eigenen Toolboxen 

aus Skripten zusammengestellt. 

Mit deren Hilfe und etwas SSH-Magie 

wird dann der ausufernde System-Zoo 

in Schach gehalten. Neue Software 

oder Funktionen erfordern es jedoch 

immer wieder, diese Toolbox anzupassen 

und auf den neuesten Stand 

zu bringen. Einsteiger haben es aber 

oft schwer, sich überhaupt auf neuen 

Systemen zurechtzufinden – gerade 

auch dann, wenn der eigene System- 

Zoo eine Vielzahl von unterschiedlichen 

Linux-Derivaten enthält. Eine 

einheitliche Methode und Schnittstelle 

zur Verwaltung der Systeme wäre also 

wünschenswert. 

OpenLMI stellt eine solche Schnittstelle 

zur Verfügung. Das Kürzel steht für 

Open Linux Management Infrastructure 

und basiert auf einem offenen Industrie-Standard. 

Struktur im Management 

Das Framework stellt eine Vielzahl von 

Low-Level-Funktionen zur Verfügung, 

mit denen sich unterschiedliche Aufgaben 

auf einem System ausführen 

lassen – lokal wie auch remote. Ob es 

sich hierbei um ein Bare-Metal- oder 

ein virtualisiertes System handelt, 

spielt erst mal keine Rolle. Zu den 

möglichen Aufgaben zählen dabei die 

Konfiguration des Betriebssystems und 

dessen Komponenten, die Verwaltung 


Login 

Admin-Story 

15 

zuständigen CIM-Provider weiterreicht. 

Die Provider decken dabei bestimmte 

Aufgabenbereiche ab. Beispielsweise 

existieren CIM-Provider für Netzwerk, 

Speicher, System-Services, Software, 

Monitoring, Benutzer und so weiter. 

Die XML-Dokumente eines Clients beschreiben 

die Art der Aufgabe, die von 

einem CIM-Provider – also auf dem zu 

verwaltenden System – durchzuführen 

ist. Die Dokumente werden anhand von 

Skripten oder Meta-Kommandos auf 

der Client-Seite erzeugt. Die Provider 

(auch CIM-Agenten genannt) auf einem 

System sind dann dafür verantwortlich, 

dass die gewünschten Aufgaben 

entsprechend durchgeführt werden. 

Die Agenten können dabei von einer 

Vielzahl von Herstellern zur Verfügung 

gestellt werden. [2] beschreibt die Anforderungen, 

die bei der Entwicklung 

eines CIM-Agenten zu beachten sind. 

Auf den Clients existieren eine Vielzahl 

unterschiedlicher Interfaces, 

die über den CIM-Object-Manager 

mit den Agenten auf den Servern 

kommunizieren können. Es gibt ein 

High-Level-Kommandozeilentool, eine 

programmierbare LMI-Shell sowie APIs 

für unterschiedliche Sprachen (Python, 

C/C++, Java), sodass Admins ihre LMI- 

Skripte in einer dieser Sprachen entwickeln 

können. Zur Kommunikation 

zwischen Client und Servern sollte auf 

den Servern der Port 5989 (»wbem‐htvon 

System-Services, das Management 

und Monitoring von Hardware und die 

Software-Verwaltung, um nur einige zu 

nennen. 

OpenLMI basiert dabei auf einem 

DMTF-Standard (Distributed Management 

Task Force) mit dem Namen 

WBEM (Web-Based Enterprise Management) 

(siehe [1]). Der Standard setzt 

sich aus verschiedenen Komponenten 

zusammen und beschreibt eine Reihe 

von Technologien zur einheitlichen Verwaltung 

von Computer-Systemen. Eine 

der verwendeten Komponenten nennt 

sich CIM (Common Information Model) 

und beschreibt in einer Art Schema 

typische Objekte, die auf einem Computer-System 

zum Einsatz kommen 

(Hardware, Software, Benutzer, Konfigurations-Subsysteme 

und so weiter). 

Überlicherweise wird der Begriff CIM 

jedoch nicht nur für das Schema eines 

Objekts verwendet, sondern bezieht 

sich auch auf die eingesetzten Tools 

und Technologien. 

Das OpenLMI-Framework setzt sich 

aus einem CIM-Client und vielen CIM- 

Servern zusammen. Der Client stellt in 

diesem Zusammenhang ein Management-System 

dar, das via XMLRPC mit 

einem CIM-Object-Manager (CIMOM) 

– manchmal auch Object-Broker genannt 

– mit dem CIM-Server spricht. 

Der Client versendet dabei CIM-/XML- 

Dokumente, die der CIMOM an die 

Abbildung 1: OpenLMI basiert auf einem Management-System 

(CIM-Client) und den zu verwaltenden 

Systemen (CIM-Server). 

tps«) geöffnet sein. Über diesen läuft 

die gesicherte Verbindung zwischen 

den Client-Interfaces und dem Object- 

Broker auf den Servern. 

Installation 

OpenLMI ist seit Fedora 18 in den 

Standard-Repositories der Distribution 

enthalten. Ich empfehle jedoch,

16 

Login 

Admin-Story 

n Info 

Fedora 20 und die darin enthaltenen 

Pakete einzusetzen. Im letzten Jahr 

gab es gravierende Änderungen an der 

OpenLMI-Software, sodass es unbedingt 

sinnvoll ist, die neueste Version 

einzusetzen. Für andere Distributionen 

steht unter [3] der OpenLMI-Quellcode 

zur Verfügung. Auf den zu verwaltenden 

Server-Systemen sind der OpenLMI- 

Object-Broker OpenPegasus sowie die 

gewünschten OpenLMI-Agenten zu 

installieren: 

yum install tog‐pegasus openlmi‐U 

providers openlmi‐storage openlmi‐U 

networking openlmi‐powermanagement U 

openlmi‐service openlmi‐account 

Das SBLIM-Projekt [4] stellt ebenfalls 

viele CIM-Provider zur Verfügung. Viele 

davon sind im Fedora-Software-Repository 

enthalten und lassen sich mittels 

Yum installieren. 

Da Server und Client über eine gesicherte 

Verbindung kommunizieren, 

wird im Rahmen der Installation des 





[1] Oliver Frommel, Standards fürs Netzwerk- und 

System-Management, ADMIN 01/2014: 

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

2014/ 01/ Standards‐fuers‐Netzwerk‐und‐Syst 

em‐Management] 

[2] CIM-Provider-Howto: [https:// fedorahosted. 

org/ openlmi/ wiki/ CimProviderHowto] 

[3] OpenLMI-Quellcode: 

[http:// www. openlmi. org/ development] 

[4] SBLIM-CIM-Provider: [http:// sourceforge. net/ 

apps/ mediawiki/ sblim] 

[5] OpenLMI-Skripte: 

[http:// pythonhosted. org/ openlmi‐scripts/] 

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. 

OpenLMI-Object-Broker ein selbstsigniertes 

X.509-Zertifikat erzeugt. Hierfür 

ist das Skript »/usr/share/Pegasus/ 

scripts/genOpenPegasusSSLCerts« 

verantwortlich. Das Zertifikat lässt 

sich nach der Installation des Servers 

mittels »openssl x509 ‐in /etc/Pegasus/ 

server.pem ‐noout ‐text« ansehen. In 

produktiven Umgebungen ist es natürlich 

ratsam, ein Zertifikat von einer 

Certificate Authority (CA) ausstellen 

zu lassen. Hierfür kann beispielsweise 

FreeIPA zum Einsatz kommen. Auf 

dem Client- beziehungsweise Management-System 

ist dann entweder das 

selbst signierte oder CA-Zertifikat zur 

Verfügung zu stellen und entsprechend 

einzubinden: 

# scp server:/etc/Pegasus/server.pemU 

/etc/pki/ca‐trust/source/anchors/U 

remote‐ server.pem 

# update‐ca‐trust 

Fehlt dieser Schritt, so ist auf den 

Clients die Zertifikats-Verifizierung zu 

deaktivieren, wovon ich jedoch ausdrücklich 

abrate. Neben dem Zertifikat 

wurde als Teil der Installation ebenfalls 

ein Benutzer »pegasus« erzeugt. Dieser 

kann für authentifizierte Zugriffe auf 

den Server zum Einsatz kommen. Hierfür 

ist für den Benutzer jedoch mittels 

»passwd pegasus« zuerst ein Passwort 

zu setzen. Schließlich bleibt noch der 

Object Broker auf dem Server zu starten: 

# systemctl start tog‐pegasus.service 

Auf dem Client sollte für erste Tests die 

OpenLMI-Shell oder das Kommandozeilentool 

lmi zum Einsatz kommen. 

Diese installiert man mittels: 

# yum install openlmi‐toolsU 

openlmi‐scripts 

Die OpenLMI-Shell basiert auf Python 

und kann sowohl interaktiv wie auch im 

Batch-Mode verwendet werden. Jede 

CIM-/XML-Anweisung wird über einen 

sicheren HTTPS-Kanal an den Object 

Broker auf den Servern gesendet und 

dort von den zuständigen CIM-Agenten 

verarbeitet. Um die Arbeit mit der 

Shell zu vereinfachen, wandelt diese 

einfach jedes OpenLMI-Objekt in ein 

Python-Objekt um. Wer etwas Python 

beherrscht, kann somit sehr schnell 

OpenLMI-Skripte schreiben. Eine Anleitung 

findet sich unter [5]. 

Wer etwas schneller ans Ziel kommen 

möchte, greift auf das CLI-Tool »lmi« 

zurück. Dieses arbeitet mit Meta-Kommandos, 

die auf den OpenLMI-Client- 

Bibliotheken aufsetzen. Diese kann 

man ebenfalls aus dem Fedora-Repository 

heraus auf den Clients beziehungsweise 

dem Management-System installieren: 

»yum install openlmi-scripts-*«. 

Das folgende Beispiel zeigt, wie sich ein 

beliebiger systemd-Service auf einem 

CLI-Server mithilfe des Tools »lmi« von 

einem zentralen Management-System 

aus steuern lässt: 

# lmi ‐h fedora.virt.tuxgeek.de U 

service show httpd.service | grep Status 

Status=OK 

# lmi ‐h fedora.virt.tuxgeek.de U 

service stop httpd.service 

# lmi ‐h fedora.virt.tuxgeek.de serviceU 

show httpd.service | grep Status 

Status=Stopped 

Genauso einfach lassen sich auch die 

Software-Pakete eines Systems mittels 

lmi verwalten. Diesmal im interaktiven 

Modus: 

# lmi ‐h fedora.virt.tuxgeek.de 

lmi> sw install zsh 

lmi> sw list pkgs zsh 

NEVRA 

Summary 

zsh‐0:5.0.2‐6.fc20.x86_64 PowerfulU 

interactive shell 

Konfigurationsoptionen, wie beispielsweise 

der Benutzername und das Passwort 

zur Authentifizierung am Object 

Broker, liest das Tool aus der globalen 

Datei »/etc/openlmi/lmi.conf« aus. Wie 

üblich können Benutzer eine eigene 

»~/.lmirc« anlegen. 

Rund um OpenLMI ist mittlerweile eine 

aktive Community entstanden. Wer Gefallen 

an dem Management-Framework 

gefunden hat, findet unter [3] Hinweise 

dazu, wie man sich an der Weiterentwicklung 

beteiligen kann. (ofr) n 


germina, 123RF 

Wie organisiert Spanning Tree ein Ethernet-Netzwerk? 

Der Baum im Netzwerk 

Ethernet ist so beliebt, weil es einfach funktioniert und nicht viel kostet. Doch die Seite des Administrators sieht 

etwas komplizierter aus: Damit das Netzwerk rundläuft, muss er wichtige Entscheidungen treffen und den Spanning 

Tree planen. Hannes Kasparick 

Spanning Tree ist eins der grundlegenden 

Protokolle in Ethernet- 

Netzwerken. Es sorgt dafür, dass keine 

Netzwerkschleifen (Loops) entstehen, 

denn durch einen Broadcast-Sturm 

führen sie innerhalb kürzester Zeit zur 

Überlastung eines Netzwerksegments. 

Ethernet-Frames haben im Gegensatz 

zu IP-Paketen keine maximale Lebensdauer 

(Time to Live, TTL) und bewegen 

sich deshalb potenziell unendlich lange 

im Kreis. 

Das Spanning-Tree-Protokoll erreicht 

die Schleifenfreiheit, indem es bestimmte 

Verbindungen zwischen 

Switches deaktiviert. Abbildung 1 zeigt 

drei Beispiele (A, B, C) für Netzwerktopologien, 

die ohne die Blockade einiger 

Switchports durch Spanning Tree 

zum Zusammenbruch des Netzwerks 

führen würden. 

n Rollen und Zustände der Switchports 

In einem Spanning Tree nimmt jeder Port eines Switches eine von vier 

möglichen Rollen ein: 

n Root Port: aktiver Switchport, dessen Upstream in Richtung Root 

Bridge zeigt. Jeder Switch besitzt höchstens einen Root Port. 

n Designated Port: aktiver Port, der weg von der Root Bridge 

(Downstream) zeigt. 

n Alternate Port (nur bei Rapid Spanning Tree): Zeigt ebenfalls zur Root 

Bridge, ist aber nicht aktiv (»Blocked«). 

n Backup Port (nur bei Rapid Spanning Tree): Verbindung zu einem anderen 

Switch, der über einen anderen Switchport günstiger erreicht 

werden kann; ebenfalls nicht aktiv (»Blocked«). 

Neben den beschriebenen Rollen gibt es vier Zustände, die ein Port 

nacheinander einnimmt: »Blocking«, »Listening«, »Learning« und »Forwarding«. 

Im zusätzlichen Zustand »Disabled« verwirft ein Port sämtliche 

Pakete. Das gilt auch in den ersten drei genannten Zuständen; in 

ihnen empfängt und verarbeitet ein Port ausschließlich sogenannte 

BPDUs (Bridge Protocol Data Units), die Informationen über das Netz 

und den Spanning Tree transportieren. In den Zuständen »Listening« 

und »Learning« überträgt ein Port solche Pakete auch weiter, in letzterem 

lernt er dazu die Adressen anderer Netzwerkteilnehmer. Nur im 

»Forwarding«-Modus schließlich leitet ein Port darüber hinaus auch 

Datenpakete weiter. 


Netzwerk 

Spanning Tree 

19 

Variante A in Abbildung 1 bringt technisch 

keinen Vorteil und entsteht normalerweise 

nur aus Unachtsamkeit, 

meist über mehrere Switches hinweg. 

Die Varianten B und C hingegen sind 

oft gewünscht, um die Bandbreite 

zwischen zwei Switches zu vergrößern 

(Variante B), beziehungsweise um eine 

Redundanz für den Fall eines Kabelausfalls 

durch äußere Einflüsse – beispielsweise 

Bauarbeiten zwischen zwei 

Gebäuden – zu erreichen (Variante C). 

Die Blockade durch Spanning Tree in 

Variante B hebt die Bandbreitenbündelung 

zunächst auf. 

Die Switch-Hersteller haben verschiedene, 

teils zueinander inkompatible 

Lösungen entwickelt, etwa »Ether- 

Channel«, »PortChannel«, »virtual 

PortChannel« (Cisco) und »Trunk« (HP). 

Diese Technologien bündeln mehrere 

physische Ethernet-Verbindungen zu einer 

logischen (Variante D in Abbildung 

1). Der Spanning Tree nimmt diese 

logische Verbindung beispielsweise als 

eine 2- GBit-Verbindung statt als zwei 

separate 1-GBit-Verbindungen wahr 

und blockiert daher keine der beiden. 

Variante C lässt sich durch diese Technologien 

allerdings nicht optimieren. 

Hier empfiehlt sich der Einsatz einer 

anderen physischen Verkabelung, die 

die Dreiecksverbindung zwischen den 

Switches ersetzt. 

Für jedes VLAN, also ein logisches 

Netz werksegment, wird ein eigener 

Spanning Tree berechnet. Dieser Artikel 

beschränkt sich deshalb auf ein VLAN. 

Das Spanning-Tree-Protokoll existiert 

heute hauptsächlich in den Ausprägungen 

»Rapid Spanning Tree« (RST) und 

»Rapid per VLAN Spanning Tree« oder 

»Multiple Spanning Tree« (MST), da die 

ursprüngliche Form des Spanning Trees 

zu hohen Konvergenzzeiten und damit 

in komplexen Topologien zu Ausfällen 

von 30 bis 50 Sekunden führt. 

Wahlen ohne Demokratie 

Die Berechnung des Spanning Trees erfolgt 

in drei wesentlichen Schritten: 

n Wahl der Root Bridge, 

n Wahl der Root Ports, 

n Wahl der Designated Ports. 

Es gibt verschiedene Rollen und Zustände 

(siehe Kasten „Rollen und 

A B C D 

Abbildung 1: Das Spanning-Tree-Protokoll verhindert Schleifen in Netzwerktopologien. 

Zustände“), die ein Switchport einnehmen 

kann. Die Variante Rapid Spanning 

Tree fasst »Disabled«, »Blocking« und 

»Listening« zu »Discarding« zusammen. 

Damit Spanning Tree die Gesamttopologie 

berechnen kann, wird zunächst 

die »Root Bridge« gewählt. Sie bildet 

den Referenzpunkt des gesamten 

Spanning Tree und berechnet die Pfade 

und Einstellungen des Baums. Die Wahl 

der Root Bridge erfolgt aufgrund der 

»Bridge-ID«, die sich aus drei Bestandteilen 

zusammensetzt: 

n Bridge Priority 

n System-ID-Extension 

n MAC-Adresse 

Campus 

Core 

Die Bridge Priority liegt zwischen 0 und 

61440 und ist in Schritten von 4096 

konfigurierbar. Die System-ID und die 

MAC-Adresse sind nicht frei wählbar; 

MAC-Adressänderungen sind zwar möglich, 

aber nicht empfohlen. Je höher 

der Wert der Bridge Priority liegt, desto 

weniger kommt der entsprechende 

Switch als Root Bridge in Frage. Ein 

Switch mit der Bridge Priority 0 übernimmt 

höchstwahrscheinlich die Root 

Bridge, es sei denn, ein weiterer Switch 

im Netz hat ebenfalls diesen Wert. 

Sollte mehr als ein Switch die gleiche 

minimale Bridge Priority besitzen, 

geben System-ID-Extension und MAC- 

DataCenter 

Core 

Layer 3 Grenze 

DataCenter 

Aggregation / 

Distribution 

DataCenter 

Access 

Abbildung 2: Die Root Bridge eines Netzwerks sollte in der Aggreations-/Distributionsebene Platz 

finden. 


Admin 

Ausgabe 03-2014

20 

Netzwerk 

Spanning Tree 

Switch A 

Root Bridge 

Switch D 

Switch C 

Switch B 

Abbildung 3: Hat der neue Switch D eine niedrigere 

Bridge-Priority als Switch A… 

Switch A 

Switch D 

Root Bridge 

Switch C 

Switch B 

Abbildung 4: … ändert Spanning Tree die Netzwerktopologie. 

Switch 1 Switch 2 

BLK 19 DP 

RP 

BLK 

RP 

19 19 

19 

Adresse den Ausschlag bei der Wahl zur 

Root Bridge. Dabei gewinnt der Kandidat 

mit den niedrigsten Werten. Erstere 

entspricht der VLAN-Nummer. 

Bei den MAC-Adressen unterbieten 

ältere Switches oft ihre aktuellen Nachfolger, 

da viele Hersteller sie aufsteigend 

vergeben. Dadurch besteht die 

Gefahr, dass der älteste und potenziell 

schwächste Switch zur Root Bridge 

wird. Da Spanning-Tree-Berechnungen 

in großen Netzen aufwendig ausfallen, 

sollte hingegen ein möglichst leistungsfähiger 

Switch die Rolle der Root Bridge 

übernehmen. 

Design-Guides der Hersteller empfehlen, 

die Root Bridge in der Aggregations- 

bzw. Distributionsebene zu platzieren, 

um kurze Konvergenzzeiten bei 

Ausfällen zu erreichen (Abbildung 2). 

Auf Cisco-Switches erfolgt die Konfiguration 

der Bridge Priority mittels 

»spanning‐tree vlan VLAN priority« oder 

alternativ mit dem Root-Bridge-Makro 

»spanning‐tree vlan VLAN root [primary 

| secondary]«. Es konfiguriert die Priorität 

automatisch anhand der aktuell 

im Netz vorhandenen Root Bridge, 

läuft aber nur einmalig beim Aufruf und 

nicht dauerhaft im Hintergrund. 

Putsch gegen die Root Bridge 

Der Austausch der Informationen über 

die Spanning-Tree-Topologie zwischen 

verschiedenen Switches erfolgt über 

sogenannte BPDUs (Bridge Protocol 

Data Unit). Grundsätzlich sendet und 

empfängt jeder Switchport BPDUs. 

Diese Eigenschaft bietet allerdings Angreifern 

die Möglichkeit, die Topologie 

auszulesen und mit gefälschten BPDUs 

zu verändern. Gegenmaßnahmen heißen 

BPDU-Guard und -Filter (siehe Kasten 

„BPDU-Guard und -Filter“). 

Auch nachdem die Root Bridge gewählt 

und der gesamte Spanning Tree aktiv 

ist, können weitere Switches dem 

Netzwerk beitreten, beispielsweise bei 

der Installation eines neuen Stockwerk- 

Switches. Hat eins der neuen Geräte 

eine niedrigere Bridge Priority, würde 

es dann zur neuen Root Bridge. Das 

zöge allerdings eine Änderung der gesamten 

Netzwerktopologie und damit 

möglicherweise suboptimale Pfade sowie 

Performance-Engpässe nach sich. 

Schutz gegen eine versehentliche oder 

auch böswillige Änderung der Root 

Bridge bietet der Root Guard [1]. 

Abbildung 3 zeigt eine Ausgangslage, 

in der Switch D zum Netzwerk hinzukommt. 

Unterbietet dessen Bridge Priority 

aus einem der genannten Gründe 

die der bisherigen Root Bridge, ändert 

sich die Topologie daraufhin wie in Abbildung 

4. 

Um diese Umstellung zu verhindern, 

konfiguriert man den Root Guard auf 

dem in Richtung Switch D weisenden 

Port von Switch C. Das Feature deaktiviert 

den betreffenden Switchport, 

sobald er eine BPDU mit einer zu niedrigen 

Bridge Priority empfängt. 

Kosten, Kosten, Kosten 

Beim Betrieb des Netzwerks stehen 

neben der Zuweisung der Root Bridge 

weitere Berechnungen an. Bei der Wahl 

der Root Ports und der Designated 

Ports, spielen die Verbindungskosten 

eine wichtige Rolle. Die Spanning-Tree- 

Standardkosten für unterschiedliche 

Bandbreiten stellt Tabelle 1 dar. Die 

vordefinierten Werte führen allerdings 

dazu, dass eine 40- und eine 

100-GBit-Verbindung die gleichen 

Spanning-Tree-Kosten ergeben wie 

auch ein PortChannel aus zwei 10-GBit- 

DP DP 

12 

DP 

RP DP 

Switch 3 Switch 4 

Root Bridge 

Abbildung 5: Bei 100-MBit-Leitungen zwischen allen 

Ports ergeben sich für alle Wegkosten Werte von 19, 

außer für die gebündelten Leitungen zwischen den 

Switches 3 und 4. 

n Tabelle 1: Verbindungskosten 

Bandbreite 

Kosten 

10 MBit/s 100 

16 MBit/s 62 

100 MBit/s 19 

200 MBit/s 12 

622 MBit/s 6 

1 GBit/s 4 

10 GBit/s 2 

20+ GBit/s 1 


Netzwerk 

Spanning Tree 

21 

Verbindungen, bei dem sich die Kosten 

aus der Gesamtbandbreite aller zusammengefügten 

Verbindungen berechnet. 

Um in solchen Situationen detaillierter 

zu reagieren, sind die Spanning-Tree- 

Verbindungskosten falls nötig pro Port 

einzeln konfigurierbar. 

Abbildung 5 stellt eine Beispieltopologie 

aus vier 100-MBit-Switches 

dar, in der Switch 4 die Root Bridge 

übernimmt. Da alle Verbindungen eine 

Geschwindigkeit von 100 MBit pro Sekunde 

haben, belaufen sich die Kosten 

für jeden Port gemäß Tabelle 1 auf 19. 

Die einzige Ausnahme bildet der Port- 

Channel zwischen Switch 3 und Switch 

4, der in Summe 200 MBit pro Sekunde 

und damit einen Kostenwert von 12 

vorweist. 

Aus diesen Kosten ergibt sich, dass 

der Root Port (in der Abbildung abgekürzt 

als RP) von Switch 1 in Richtung 

Switch 3 zeigt. Der gegenüberliegende 

Switchport wird zum Designated Port 

(abgekürzt als DP), weil die Kosten auf 

diesem Weg nur 31 (19+12) betragen, 

auf dem Weg über Switch 2 jedoch 38 

(19+19). Gäbe es zwischen Switch 3 und 

Switch 4 keinen PortChannel, ergäben 

sich zwei gleich teure Wege von Switch 

1 zur Root Bridge (Switch 4). Dann 

würden zur Berechnung des Weges die 

Bridge-IDs herangezogen, wobei die 

niedrigere ID den Ausschlag gibt. 

Alle Switchports der Root Bridge 

(Switch 4) sind Designated Ports, 

ebenso wie alle Ports, die einem Root 

Port gegenüberliegen. Bei der Verbindung 

zwischen Switch 1 und Switch 2 

erfolgt die Bestimmung der Port-Rollen 

– die möglichen Optionen lauten hier 

Designated und Blocked – durch die 

Wegkosten zur Root Bridge. Bei Switch 

2 betragen sie 19, bei Switch 1 hingegen 

31. Somit werden die Ports zwischen 

Switch 1 und 2 zu Blocked beziehungsweise 

Designated Ports. Dies gilt analog 

auch für die Verbindung zwischen den 

Switches 2 und 3: Die Wegkosten von 

Switch 3 zur Root Bridge betragen 12, 

deshalb wird der Port Richtung Switch 

2 zum Designated Port. 

Aus der beschriebenen Spanning-Tree- 

Berechnung ergeben sich in Abbildung 

5 die Blockaden zwischen den Switches 

1 und 2 sowie zwischen 2 und 3. Die 

Kommunikation zwischen 1 und 2 erfolgt 

deshalb über den Umweg über die 

Switches 3 und 4. 

Die in Abbildung 5 gezeigte Topologie 

demonstriert, dass die Position der 

Root Bridge im Netzwerk eine wichtige 

Rolle spielt. Dies gilt auch für Spanning-Tree-Weiterentwicklungen, 

die die 

Zahl blockierter Switchports minimieren. 

Denn neben den optimalen Wegen 

gilt es auch die Notwendigkeit eventueller 

Spanning-Tree-Neuberechnungen 

bei Switch-Ausfällen zu bedenken, 

die für optimale Geschwindigkeit ein 

möglichst leistungsfähiger Switch ausführen 

sollte. 

Weitere Gefahren 

Scott Hogg, Technologiechef der Netzwerktechnikfirma 

GTRI, beschreibt in 

seinem Blog [2] weitere häufige Fehler 

im Zusammenhang mit Spanning-Tree- 

Konfigurationen. Einer davon betrifft 

nicht beachtete Größenbegrenzungen 

eines Spanning Trees, also der maximalen 

Anzahl hintereinandergeschalteter 

Switches. Im Idealfall verhindert eine 

sternförmige Verkabelung hinterein- 

FHRP passiv 

AGG1 

ACC1 

IP Core 

FHRP aktiv 

AGG2 

ACC2 

Layer 3 

Grenze 

Abbildung 6: Der ursprüngliche Spanning-Tree- 

Algorithmus führt in diesem Setup zu einem suboptimalen 

Pfad vom Server zum Gateway. 

AGG1 

IP Core 

AGG 

AGG2 

Layer 3 

Grenze 

n BPDU-Guard und ‐Filter 

n BPDU-Guard deaktiviert einen Switchport, sobald er ein BPDU-Paket empfängt. Die 

Ursache kann in einem Angriff oder im unerlaubten Anschließen eines Switches liegen. 

Optional aktiviert der BPDU-Guard einen abgeschalteten Switchport mit einem 

Timer nach Ablauf einer gewissen Zeit automatisch wieder. BPDU-Guard sollte auf 

jedem Access-Switchport konfiguriert sein. Das geschieht im Interface mit »spanning‐tree 

bpduguard enable« oder global mit »spanning‐tree portfast bpduguard 

default«. 

n BPDU-Filter verhindert, dass ein Switch BPDUs über einen Switchport verschickt. 

Auch dieses Feature sollte auf jedem Access-Port aktiviert sein mit »spanning‐tree 

bpdu‐filter enable« im Interface oder global mit »spanning‐tree portfast bpdufilter 

default«. 

ACC1 

ACC 

ACC2 

Abbildung 7: Multichassis-Etherchannel fasst 

Switch es und Netzwerkverbindungen zu logischen 

Einheiten zusammen. 


Admin 

Ausgabe 03-2014

22 

Netzwerk 

Spanning Tree 

RACK 1 

VLAN 100 

VMotion 

VM 

RACK 2 

VLAN 100 

IP Core 

RACK 3 

VLAN 103 

RACK 4 

VLAN 104 

Abbildung 8: Virtuelle Umgebungen schaffen auch fürs Netzwerk neue Herausforderungen. 

RACK 1 

VLAN 100 

VLAN 101 

VLAN 102 

VMotion 

VM 

IP Core 

RACK 2 

VLAN 100 

VLAN 101 

VLAN 102 

RACK 3 

VLAN 100 

VLAN 101 

VLAN 102 

Layer 3 

Grenze 

Abbildung 9: Der Trill-Standard und Ciscos FabricPath-Protokoll erlauben 

die Aggregation von Netzwerkverbindungen. 

Layer 3 

Grenze 

andergehängte Switches vollständig, 

aber dies ist beispielsweise bei einem 

Campus mit mehreren Gebäuden oft 

unmöglich. 

Eine weitere grundsätzliche Schwäche 

von Spanning Tree besteht darin, dass 

der Algorithmus beim Ausbleiben von 

BPDUs auf einem Port davon ausgeht, 

dass daran kein Switch angeschlossen 

ist. Doch dieser Schluss ist potenziell 

falsch und Fehlkonfigurationen oder 

Software-Fehler führen so möglicherweise 

dazu, dass es trotzdem zu Schleifen 

im Netzwerk kommt. 

Eine mögliche Ursache für ausbleibende 

BPDUs liegt in einem Hardware- 

Fehler. Bei Glasfaserverbindungen kann 

einer der beiden Kanäle Schaden nehmen, 

sodass die Verbindung zwar weiterhin 

BPDUs empfangen, aber nicht 

senden kann. Gegen diese Probleme im 

Layer 1 des Netzwerkschichtenmodells 

hilft die »Unidirectional Link Detection« 

(UDLD) [4]. Diese Methode ergänzt der 

»LoopGuard« [3], der Software-Bugs 

mit der gleichen Folge aufspürt. 

Dem Trugschluss, aus dem Spanning 

Tree aus dem Ausbleiben eingehender 

BPDUs folgert, es sei kein Switch angeschlossen, begegnet 

außerdem die »Bridge Assurance«. Diese Technik sollte deshalb 

auf allen Switchports, die eine Verbindung zu anderen 

Switches herstellen, aktiviert sein. Ausnahmen bilden verschiedene 

Ausprägungen von Multichassis-Etherchannels, 

beispielsweise ist Bridge Assurance nicht für Ciscos »virtual 

PortChannels« (vPC) empfohlen. 

Damals und heute 

In älteren Ethernet-Netzwerken ist eine Topologie wie in Abbildung 

6 denkbar. Darin hat Spanning Tree im Layer-2-Bereich 

die Hälfte aller Links deaktiviert und der Server (unten) nutzt 

nur eine von zwei Verbindungen. Die Rolle der Root Bridge 

übernimmt der Switch AGG1. Er bildet mit AGG2 die Grenze 

zwischen Layer 2 und Layer 3, die beiden heißen deshalb 

Layer-3-Switches, obwohl laut des OSI-Schichtenmodells ein 

Switch in Layer 2 arbeitet. Auf den beiden Layer-3-Switches 

läuft ein »First Hop Redundancy Protocol« (FHRP), entweder 

mit dem offenen Standard VRRP oder beispielsweise über 

Ciscos proprietäres Pendant HSRP. Das Protokoll ist allerdings 

nur auf AGG2 aktiv. Der »First Hop« ist das IP-Standard-Gateway 

des Servers. 

Das Problem des suboptimalen Weges der IP-Pakete vom 

Server zum Gateway (AGG2) in Abbildung 6 entsteht, weil aufgrund 

der durch Spanning Tree blockierten Verbindungen alle 

gerouteten Pakete den Umweg über AGG1 nehmen. Um das 

Problem zu beheben, müsste im Beispiel entweder AGG2 die 

Root Bridge übernehmen, oder das FHRP-Protokoll auf AGG1 


Netzwerk 

Spanning Tree 

23 

aktiviert werden. In einer komplexeren 

Topologie fallen die Auswirkungen einer 

solchen ungünstig platzierten Root 

Bridge wie in Abbildung 6 oft noch wesentlich 

gravierender aus. 

Non-Blocking-Architektur 

Aufgrund der hohen Port-Preise und 

Performance-Anforderungen bei Data- 

Center-Switches ist das Blockieren von 

Links durch Spanning Tree generell 

nicht wünschenswert. Deshalb bieten 

verschiedene Hersteller Abhilfe, um 

mehrere physische Verbindungen zwischen 

zwei Switches oder zwischen 

einem Switch und einem Server zu 

jeweils einer logischen Verbindung 

zusammenzufassen (Abbildung 7). Einige 

Lösungen ermöglichen sogar die 

Zusammenfassung von mehr als zwei 

Switches. 

Die Aggregations-Switches AGG1 und 

AGG2 verhalten sich in Abbildung 7 

nun wie ein großer Switch AGG und die 

beiden Access-Switches ACC1 und ACC2 

bilden den logischen Switch ACC. Dafür 

sorgt beispielsweise die »Multichassis 

Etherchannel«-Technik. Das Betriebssystem 

des Servers fasst wiederum 

die beiden Verbindungen zu ACC1 und 

ACC2 zu einer logischen Verbindung 

zusammen (»Netzwerk-Bonding«), sodass 

die volle Bandbreite zur Verfügung 

steht. Letzteres ermöglicht beispielsweise 

das »Link Aggregation Control 

Protocol« (LACP). 

Skalierbarkeit von Layer 2 

Die in Abbildung 7 dargestellte Topologie 

skaliert grundsätzlich gut, allerdings 

ergeben sich in großen Netzen 

einige neue Herausforderungen durch 

die Möglichkeiten der Virtualisierung. 

Abbildung 8 zeigt eine Beispieltopologie. 

Rack 1 und Rack 2 verwenden darin 

das gleiche VLAN, was die Migration 

einer virtuellen Maschine von Rack 1 in 

Rack 2 im laufenden Betrieb erlaubt, 

etwa mit VMotion von VMWare. Andererseits 

steht pro Rack häufig nur ein 

VLAN zur Verfügung, um auch bei einer 

großen Anzahl virtueller Maschinen die 

Broadcast-Domäne möglichst klein zu 

halten – wie bei den Racks 3 und 4. 

Neben der genannten Einschränkung 

bei der Mobilität virtueller Maschinen 

bildet bei Multichassis-Etherchannel 

die Beschränkung auf zwei Switch- 

Paare einen limitierenden Faktor. Dazu 

kommt die teils lange Konvergenzzeit 

von Spanning Tree, auch wenn sie mit 

Rapid Spanning Tree kürzer als im ursprünglichen 

Protokoll ausfällt. Sind 

mehrere hundert VLANs im Einsatz, 

dauert die Neuberechnung des Spanning 

Tree beim Ausfall der Root Bridge 

dennoch etwas. 

Um diesen Herausforderungen zu begegnen, 

erlauben einige proprietäre 

Protokolle Topologien wie in Abbildung 

9. Das Fundament dafür legt der offizielle 

IETF-Standard Trill (Transparent 

Interconnection of Lots of Links). Er 

ermöglicht »Equal Cost Multipathing« 

auch in Layer-2-Netzwerken, statt wie 

zuvor nur in Layer-3-Netzen. 

Auch das Cisco-eigene FabricPath 

basiert auf Trill, bietet aber erweiterte 

Möglichkeiten. So lernt bei FabricPath 

jeder Switch nur die MAC-Adressen, die 

er wirklich benötigt – in klassischen 

Layer-2-Netzen und bei Trill hingegen 

speichert jeder Switch alle MAC-Adressen. 

Die verkleinerten Adresstabellen 

führen bei FabricPath zu einer besseren 

Performance und vermeiden, dass 

Switches an die Speichergrenzen ihrer 

Hardware stoßen. 

Alle Verbindungen zwischen den einzelnen 

Switches in Abbildung 9 werden 

beim Einsatz von Cisco-Geräten im 

Fabric Path-Modus betrieben, aktiviert 

wird dieser durch den Befehl 

»switchport mode fabricpath«. Das 

»Fabric Short est Path First«-Protokoll 

bewerkstelligt das Layer-2-Routing 

und verwendet im Hintergrund wiederum 

IS-IS (»Inter mediate System to 

Intermediate System«). Der Einfluss 

von Spanning Tree endet an dieser 

Stelle – es handelt sich nicht mehr um 

Ethernet-Verbindungen, sondern um 

bloßes FabricPath. 

Die Verbindung zu klassischen Ethernet-Switches 

ist aber weiterhin möglich. 

An der Schnittstelle betritt Spanning 

Tree wieder die Bühne. Es betrachtet 

die gesamte FabricPath-Instanz wie 

einen einzigen großen Switch, wird 

dabei aber nicht durch den FabricPath 

hindurch propagiert. Alle FabricPath- 

Switches mit Verbindung zu einem 

n Info 





[1] Root Guard: [http:// www. cisco. com/ en/ US/ 

tech/ tk389/ tk621/ technologies_tech_note- 

09186a00800ae96b. shtml] 

[2] Scott Hogg: „9 Common Spanning Tree Mistakes“ 

(englisch): [http:// www. networkworld. 

com/ community/ blog/ 9‐common‐spanningtree‐mistakes] 

[3] Cisco LoopGuard: [http:// www. cisco. com/ en/ 

US/ tech/ tk389/ tk621/ technologies_tech_note09186a0080094640. 

shtml] 

[4] Unidirectional Link Detection (UDLD): 

[http:// www. cisco. com/ en/ US/ tech/ 

tk389/ tk621/ technologies_tech_note- 

09186a008009477b. shtml] 

[5] Link Aggregation Control Protocol: 

[http:// www. cisco. com/ en/ US/ docs/ ios/ 

12_2sb/ feature/ guide/ gigeth. html] 

[6] Rapid Spanning Tree: [http:// www. cisco. com/ 

en/ US/ tech/ tk389/ tk621/ technologies_ 

white_paper09186a0080094cfa. shtml] 

[7] Routing Bridges (RBridges): 

[http:// tools. ietf. org/ html/ rfc6325] 

Ethernet-Switch erhalten die gleiche 

Bridge Priority, empfohlen ist der Wert 

8192. 

Der Anschluss eines Servers ans Fabric- 

Path-Netzwerk erfolgt über Ethernet. 

Die Switchports für Server sind entsprechend 

als Ethernet-Ports konfiguriert 

und nicht als FabricPath-Ports. 

VLANs, die über FabricPath transportiert 

werden sollen, konfiguriert der Befehl 

»mode fabricpath« als FabricPath- 

VLANs. 

Fazit 

Spanning Tree bildet einen grundlegenden 

Bestandteil eines Ethernet-Netzwerks. 

Seine Konfiguration erfordert 

deshalb große Sorgfalt, um auch im 

Fehlerfall die Stabilität des Netzwerks 

zu garantieren. (csc) n 

n Autor 

Hannes Kasparick ist Solution-Designer für Rechenzentrumsinfrastruktur 

und Virtualisierung. Im Urlaub 

erkundet er fremde Länder. 


Admin 

Ausgabe 03-2014

Netzwerk 

24 OpenNMS und OCS 

Kheng Ho Toh, 123RF 

OCS-Informationen in die Überwachung mit OpenNMS integrieren 

Automatisch 

überwacht 

Wer große IT-Umgebungen effizient verwalten will, muss automatisieren. Das bedingt oft die Integration 

verschiedener Komponenten über Anwendungsgrenzen hinweg. Dieser Beitrag beschreibt, wie sich Informationen 

aus dem Hard- und Software-Inventar von OCS in das Netzwerk-Monitoring mit OpenNMS 

automatisch überführen lassen. Ronny Trommer, Markus Neumann 

Zunächst lohnt ein kurzer Blick auf die 

an dieser Lösung beteiligten Komponenten 

OCS und OpenNMS. Wofür sind 

sie gut und woher kommen sie? 

OCS 

Mit OCS Inventory NG (OCS) steht Netzwerk- 

und System-Administratoren eine 

Anwendung zur Hard- und Software- 

Inventarisierung zur Verfügung, die ein 

französisches Team unter der GPL 2 in 

Perl und PHP entwickelt. Hinter den 

Entwicklern steht das Unternehmen 

FactorFX, das kommerziellen Support 

und Training anbietet. 

OCS bedient sich bei der Inventarisierung 

eines Software-Agenten, der für 

Linux, Unix, Windows, OS X sowie für 

Android-Betriebssysteme verfügbar ist. 

Für Netzwerkkomponenten steht ein 

SNMP-basierter Discovery-Mechanismus 

zur Verfügung. Der Agent sammelt 

Informationen über: 

n logische Laufwerke und Partitionen, 

n detaillierte Informationen vom Betriebssystem, 

n installierte Programme, 

n angeschlossene Monitore. 

Die gesammelten Daten speichert eine 

MySQL-Datenbank. Die Systeme lassen 

sich im Inventar kategorisieren und 

damit organisieren. Ein SOAP-Web- 

Service macht die OCS-Inventardaten 

für andere Anwendungen verfügbar. 

OpenNMS 

Die Netzwerk-Management-Plattform 

OpenNMS entwickelt überwiegend 

ein amerikanisch-europäisches Team 

unter der GPL v3+ in Java. Im Projekt 

gibt es keine Unterscheidung zwischen 

freier Community- und proprietärer 

Enterprise-Version. Das Unternehmen 

The OpenNMS Group Inc. bietet kommerzielles 

Training, Support und Entwicklung 

an. 

Der Schwerpunkt der Anwendung 

liegt beim Fehler- und Performance- 

Monitoring. Als Plattform steht ein umfangreiches 

Provisionierungssystem zur 

Verfügung. Es kann unterschiedliche 

externe Datenquellen einbinden. Diese 


Netzwerk 

OpenNMS und OCS 

25 

Aufgaben übernimmt in OpenNMS der 

Prozess »provisiond«. So lassen sich 

beispielsweise DNS-Zonen und virtuelle 

Maschinen aus VMwares vCenter [1] 

automatisch in das Monitoring überführen 

und synchronisieren. 

Die Daten gelangen in einem XML-Format 

mittels HTTP zu OpenNMS. Die Zuweisung 

von Monitoren etwa für HTTP, 

SMTP, IMAP und JDBC ist auf mehreren 

Wegen möglich. Entweder erkennen 

Service-Detektoren diese Dienste automatisch 

oder sie lassen sich manuell 

zuweisen. Eine Mischung aus beiden 

Varianten ist ebenfalls möglich. Um 

Systeme automatisch zu kategorisieren 

oder um festzulegen, von welchen 

Netzwerkschnittstellen Leistungsdaten 

zu erfassen sind, lassen sich Richtlinien 

(Policies) nutzen. Damit ein Einsatz in 

größeren Umgebungen möglich ist, 

wurde OpenNMS auf einer ereignisbasierten 

Architektur aufgebaut. 

Verbindungen schaffen 

Wer OCS benutzt, hat umfangreiche 

Informationen von Server-Systemen 

in einem zentralen Inventar zur Verfügung, 

die auch für das Monitoring sehr 

nützlich wären. Modellbezeichnungen 

oder Seriennummern, die von den OCS- 

Agenten ermittelt wurden, können im 

Falle einer Störung in einer Benachrichtigung 

durch OpenNMS dem Administrator 

hilfreiche Informationen liefern. 

Häufig befinden sich in OCS allerdings 

auch Systeme, die für das Monitoring 

nicht relevant sind, beispielsweise Arbeitsstationen 

oder Systeme, die noch 

in der Entwicklungsumgebung stecken. 

Will man nun Systeme über OCS kontrolliert 

und automatisch in das Monitoring 

mit OpenNMS überführen, bietet 

sich ein Aufbau an, wie ihn Abbildung 1 

skizziert. 

Die Installation der OCS-Agenten sorgt 

dafür, dass das OCS die später zu 

überwachenden Systeme überhaupt 

registriert. Neue Server-Systeme befinden 

sich zur Vorbereitung in der 

speziellen Umgebung Development. Im 

vorliegenden Beispiel sind Systeme in 

dieser Umgebung für das Monitoring in 

OpenNMS uninteressant und werden 

nur im OCS-Inventar aufgeführt. Bevor 

Server-Systeme in den Produktivbe- 

trieb gehen, testet man 

sie in einer Staging- 

Umgebung. Falls dort 

irgendwelche Störungen 

auftreten, wird 

das Entwicklungsteam 

informiert. Meldungen 

über Störungen 

bei Systemen aus der 

Produktivumgebung 

sollen in das Network 

Operation Center gelangen. 

Das Monitoring 

interessiert sich lediglich 

für die Systeme in 

Staging und Produktion. 

Um zu zeigen, wie 

Monitoring-Profile 

für spezielle Server 

realisierbar sind, unterscheidet 

dieses Beispiel 

zwischen Mail-, 

Web- und Datenbank- 

Servern. Es geht davon 

aus, dass OpenNMS [2] 

in der stabilen Version 

1.12.3 und OCS in der 

Version 2.1RC1 [3] auf 

einem CentOS-6.5- 

Server installiert sind. 

Zusammenspiel der 

Komponenten 

Neben den beiden Anwendungen 

OpenNMS und OCS ist der OpenNMS 

Integration Server (OIS) nötig. Er extrahiert 

das OCS-Datenmodell, transformiert 

die Daten in das OpenNMS-Node- 

Datenmodell und lässt sich flexibel 

erweitern. Auf der einen Seite werden 

über die SOAP-Schnittstelle von OCS 

die Daten eingelesen und auf der anderen 

Seite die Daten mittels HTTP im 

Abbildung 1: Szenario für die Integration von OCS Inventory und 

OpenNMS. 

XML-Format für Provisiond in OpenNMS 

bereitgestellt. Bei der Transformation 

können bestimmte Regeln und Bedingungen 

ausgewertet und angewendet 

werden. Ein Standardverhalten ist im 

OIS bereits definiert, es bezieht sich 

auf die Netzwerkschnittstellen und 

Inventarinformationen. Damit sich der 

Ablauf wie in Abbildung 1 beschrieben 

realisieren lässt, muss der Admin drei 

selbstdefinierte Attribute in OCS anlegen 

und vom OIS auswerten lassen. 

In Abbildung 2 wird gezeigt, welche Attribute 

zur Steuerung des Monitoring in 

Abbildung 2: Überführen eines OCS-Computers in eine OpenNMS-Requisition. 


Admin 

Ausgabe 03-2014

26 

Netzwerk 


n Listing 1: »global.properties« 

01 ### start an http server that provides access to 

requisition files 

02 driver = http 

03 host = 127.0.0.1 

04 port = 8000 

05 

06 ### file run to create a requisition file in 

target 

07 #driver = file 

08 #target = /tmp/ 

OpenNMS zum Zuge kommen. Die OCS- 

Attribute haben folgende Bedeutung: 

Monitored: Legt fest, ob das System für 

das Monitoring relevant ist. 

Environment: Legt fest, in welcher Umgebung 

sich das System befindet. 

Purpose: Legt fest, welche Aufgaben 

der Server durchführt. 

Für jeden Verwendungszweck wird eine 

OpenNMS-Datenquelle (Requisition) 

angelegt. Sie legt fest, welche spezifischen 

Service-Detektoren für einen 

Web-, Mail- und Datenbank-Server 

nötig sind. Zusätzlich bildet OpenNMS 

die Umgebung über Surveillance- 

Categories ab. Sie erlauben später 

die Zuordnung von unterschiedlichen 

n Listing 2: »requisition.properties« 

01 ### SOURCE ### 

02 ## connect to ocs and read computers 

03 source = ocs.computers 

04 

05 ## OCS SOURCE PARAMETERS ## 

06 ocs.url = http://192.168.30.112 

07 ocs.username = SOAP_USER 

08 ocs.password = mypass 

09 ocs.checksum = 4099 

10 ocs.tags = Server 

11 ocs.accountinfo = MONITORED.Monitored PURPOSE. 

Webserver 

12 

13 ### MAPPER ### 

14 ## Run the default mapper for computers 

15 mapper = default.ocs.computers 

16 

17 ## Run a custom mapper script 

18 #mapper = script 

19 #script = mapper.groovy 

20 

21 ### CATEGORIES ### 

22 categoryMap = categorymap.properties 

Benachrichtigungspfaden für das Netzwerk 

Operation Center oder das Entwicklungsteam. 

SOAP aktivieren 

Bei einer Installation von OCS sind zwei 

Schritte notwendig: Im ersten Schritt 

aktiviert man den SOAP-Web-Service 

und im zweiten Schritt legt man die benutzerdefinierten 

Attribute an. Um den 

SOAP-Web-Service zu aktivieren, ist die 

Perl-Umgebungsvariable in der Datei 

»/etc/httpd/conf.d/z‐ocsinventory‐server.conf« 

auf diese Weise zu bearbeiten: 

# === WEB SERVICE (SOAP) SETTINGS === 

PerlSetEnv OCS_OPT_WEB_SERVICE_ENABLED 1 

Die Web-Service-Schnittstelle ist mit 

einer Basic-Authentication gegen eine 

Benutzerdatei konfiguriert. Um die 

Benutzerdatei zu erzeugen, führt der 

Admin das Kommando 

htpasswd ‐c /etc/httpd/APACHE_AUTH_U 

USER_FILE SOAP_USER 

aus. Im nächsten Schritt werden die 

benutzerdefinierten Attribute für die 

OCS-Computer angelegt. 

Benutzerdefinierte Attribute 

anlegen 

Die Beschreibung orientiert sich an 

Abbildung 3. Im Hauptmenü unter 

»Administrative Data« (1) werden die 

Attribute angelegt. Dazu muss in der 

Auswahlbox (2) »computers« markiert 

sein. Über die Registerkarte (3) »New 

data« werden die Felder mit den entsprechenden 

Datentypen hinzugefügt. 

Das Ergebnis sollte dann wie in (4) dargestellt 

aussehen. 

Um die erzeugten Felder mit Auswahlmöglichkeiten 

zu versehen, muss die 

Detailansicht eines bereits inventarisierten 

Computers aufgerufen werden. 

Nun lassen sich die angelegten Attribute 

wie in Abbildung 4 bearbeiten. 

Mit dem Plus-Symbol (1) wird der Dialog 

zum Hinzufügen eines Attributs 

angezeigt. Mit »New Data« (2) werden 

dann die Umgebungen »Development«, 

»Stage« und »Production« erzeugt. Für 

die Umgebungen sollte man die Attribute 

wie in der Tabelle (3) anlegen. 

Für jeden weiteren neuen Server lässt 

sich über diese drei Auswahlfelder steuern, 

wie sie in OpenNMS im Monitoring 

zu behandeln sind. Die Anpassungen 

in OCS sind abgeschlossen und der 

Admin kann sich der Konfiguration des 

OpenNMS Integration Server (OIS) und 

OpenNMS selbst widmen. 

Installation des Integration- 

Servers 

Die Installation des OIS kann über die 

OpenNMS-Yum- und -Debian-Repositories 

erfolgen. Der Java-Quellcode 

steht ebenfalls zur Verfügung und kann 

selbst übersetzt werden. Die Installationsvarianten 

sind im OpenNMS-Wiki 

zur OCS-Integration [4] beschrieben. 

In diesem Beispiel ist der OIS auf demselben 

Server wie OpenNMS installiert. 

Der Server lauscht auf der lokalen Adresse 

127.0.0.1 auf Port TCP/8000 und 

Abbildung 3: Erstellen der Attribute zur Steuerung des OpenNMS-Imports. 


Netzwerk 


27 

stellt die Daten der zu importierenden 

Server im XML-Format bereit. Den Aufbau 

der Konfigurationsdateien des OIS 

zeigt Abbildung 5. 

Die Verzeichnisse »ocs‐dbserver«, 

»ocs‐mailserver« und »ocs‐webserver« 

repräsentieren die Konfiguration für die 

OpenNMS-Requisition wie in Abbildung 

2 skizziert. Die grundlegende Funktion 

des OIS wird in der Datei »global.properties« 

wie in Listing 1 beschrieben. 

Der Parameter »driver« gibt an, dass 

ein HTTP-Output erwartet wird. Mit 

»host« und »port« lässt sich festlegen, 

auf welcher Netzwerkschnittstelle und 

welchem Port auf eingehende Verbindungen 

gelauscht werden soll. 

In dem Unterverzeichnis »ocs‐webserver« 

liegt eine Datei »requisition.properties«, 

die wie in Listing 2 aufgebaut 

ist. Hier wird festgelegt, von welchem 

OCS-Server die Daten geholt werden 

sollen. Der OCS-Server ist in unserem 

Beispiel unter 192.168.30.112 erreichbar 

und die SOAP-Schnittstelle kann 

mit dem Benutzer »SOAP_USER« und 

dem Passwort »mypass« angesprochen 

werden. 

Der Parameter »ocs.accountinfo« legt 

fest, dass für die Requisition »ocs‐webserver« 

lediglich OCS-Computer auszuwählen 

sind, die »Monitored« und als 

Abbildung 4: So lassen sich die Standardwerte für benutzerdefinierte 

Attribute festlegen. 

Verwendungszweck 

»Webserver« gesetzt 

haben. Für Mail- und 

Datenbank-Server wird 

ebenfalls ein entsprechendes 

Verzeichnis 

angelegt. In der jeweiligen 

»requisition. 

properties« wird der 

Parameter für »ocs. 

accountinfo« entsprechend 

des Verwendungszwecks 

»Mailserver« 

und »Datenbankserver« 

angepasst. 

Der Parameter »mapper« 

legt fest, welche 

Inventarinformationen 

von OCS in OpenNMS 

zu überführen sind. 

Falls das Standardverfahren 

nicht genügt, 

lässt sich ein eigenes Groovy-Skript 

angeben, dass die Daten zuordnet. In 

diesem Beispiel ist das unnötig. 

Der letzte Parameter »categoryMap« 

definiert eine Datei, in der die Umgebung 

(Environment) der OpenNMS-Surveillance-Category 

zugewiesen wird. Im 

vorliegenden Szenario wird definiert, 

dass die Umgebungen für »Production« 

und »Stage« auf gleichnamige Surveillance-Categories 

in OpenNMS zuzuweisen 

sind. Die Datei »categoryMap. 

properties« sieht für Mail-, Web- und 

Datenbank-Server identisch aus: 

ENVIRONMENT.Production=Production 

ENVIRONMENT.Stage=Stage 

Der OIS stellt unter der URL [http:// 

localhost:8000/ ocs‐webserver] die Ser- 

n Listing 3: »provisiond‐configuration.xml« 

01 

02 

10 

11 

22 

23 

24 0 0 0 * * ? * 

25 

26 

27 

28 

29 0 0 0 * * ? * 

30 

31 

32 

33 

34 0 0 0 * * ? * 

35 

36 


Admin 

Ausgabe 03-2014

28 

Netzwerk 


Abbildung 7: Auswahl von Service-Detektoren für Web-Server. 

Abbildung 5: Die Struktur der Konfigurationsdateien 

des OpenNMS-Integration-Servers. 

ver entsprechend der Konfiguration aus 

dem Verzeichnis »ocs‐webserver« zum 

Import zur Verfügung. Der Pfad »/ocswebserver« 

entspricht hier dem angelegten 

Verzeichnis im Dateisystem. 

Entsprechend erhält man unter den 

Pfaden »/ocs‐dbserver« sowie 

»/ocs‐mailserver« kategorisierte Mailund 

Datenbank-Server aus OCS. Die 

Konfiguration des Integration-Servers 

ist abgeschlossen und im nächsten 

Schritt wird OpenNMS für die automatische 

Synchronisation eingerichtet. 

Import mit Provisiond 

Um die Systeme in OpenNMS automatisch 

zu importieren und gegen OCS 

Abbildung 6: Vorbereiten der Requisition in OpenNMS für den automatischen Import. 

abzugleichen, wird der Daemon Provisiond 

von OpenNMS konfiguriert. Dazu 

ist im Verzeichnis »/opt/opennms/etc« 

die Datei »provisiond‐configuration. 

xml« wie in Listing 3 zu bearbeiten. Relevant 

sind hier die Abschnitte der Requisition-Definition 

(»requisition‐def«). 

Für Mail-, Web- und Datenbank-Server 

gibt es jeweils einen entsprechenden 

Eintrag. Er sorgt dafür, dass in 

OpenNMS jeweils eine Requisition für 

Web-, Mail- und Datenbank-Server entsteht. 

Jede Requisition konfiguriert das 

Verhalten für das Monitoring. Listing 3 

legt ebenfalls fest, dass täglich um null 

Uhr, Mail-, Web- und Datenbank-Server 

von einem lokalen OIS über Port 8000 

synchronisiert werden. 

Der nächste Schritt legt die drei Requisitions 

in der OpenNMS-Weboberfläche 

an. Dazu wählt der Administrator im 

Hauptmenü den Punkt »Admin« und 

anschließend »Manage Provisioning 

Requisitions« aus. Über das Eingabefeld 

legt er die drei Requisitions 

»ocs‐webserver«, »ocs‐mailserver« und 

»ocs‐dbserver« wie in Abbildung 6 an. 

Um ein Profil zu erzeugen, das bestimmt, 

wie die Systeme beim Import 

zu behandeln sind, konfiguriert man 

die Service-Detektoren (Detectors) 

für jede Requisition. Dazu gibt man 

unter »Requisition Edit« (1) an, welche 

Service-Detektoren anzuwenden sind. 

Nach dem Anlegen einer Requisition 

werden einfach alle zur Verfügung 

stehenden Service-Detektoren zugeordnet. 

Es ist daher sinnvoll, nur die 

Service-Detektoren auszuwählen, die 

für Mail-, Web- und Datenbank-Server 

passen. Abbildung 7 zeigt, dass für 

Web-Server nur die Service-Detektoren 

ICMP, HTTP, HTTPS und SNMP in der 

Konfiguration behalten und alle anderen 

gelöscht wurden. In der Gruppe der 

Mail- und Datenbank-Server werden 

relevante Service-Detektoren wie zum 

Beispiel SMTP, IMAP, POP3 und JDBC- 

Detektoren ausgewählt. 

Die Konfiguration hat zur Folge, dass 

OpenNMS beim Import aus OCS prüft, 

ob beispielsweise HTTP oder HTTPS 

über das Netzwerk von dem zu importierenden 

Server verfügbar sind. Falls 

ja, werden die Services automatisch 

zugeordnet und automatisch ins Monitoring 

überführt. 

Weiterhin können unter »Foreign 

Source Definition Edit« (2) für eine 

Requisition Richtlinien (Policies) festgelegt 

werden. Sie bestimmen, wie 

beim Import mit der Leistungsdatenerfassung 

umgegangen oder ob eine 

regelbasierte Kategorisierung der Systeme 

vorgenommen werden soll. Für 

das vorliegende Beispiel ist das jedoch 

nicht relevant. Weiterführende Informationen 

zu Richtlinien finden sich im 

OpenNMS-Wiki im Provisioning Users 

Guide [5]. 


Netzwerk 


29 

Benachrichtigungen 

Bis hierher wurde eine automatische 

Synchronisation zwischen OCS und 

OpenNMS konfiguriert. Dabei kann 

OCS kontrollieren, welche Server in 

OpenNMS automatisch zu importieren 

sind. In OpenNMS wird über die 

Requisition ein Monitoring-Profil bestehend 

aus Service-Detektoren für 

Web-, Mail- oder Datenbank-Server 

angewendet. Außerem braucht man 

noch Benachrichtigungen für das NOCund 

Entwicklungsteam. Um Mails zu 

versenden, muss OpenNMS mit einem 

Mailserver kommunizieren. Die Grundkonfiguration 

zum Mailversand sind im 

OpenNMS-Wiki im Abschnitt Notification 

Tutorial [6] detailliert beschrieben. 

Beim Import hatten wir bereits festgelegt, 

dass das OCS-Attribut »Environment« 

als gleichnamige Surveillance- 

Category den OpenNMS-Nodes zuzuweisen 

ist. Diese Surveillance-Category 

verwenden wir jetzt als Benachrichtigungsfilter. 

In OpenNMS werden die beiden Teams 

Entwicklung und NOC über Gruppen 

abgebildet. Jeder der beiden Gruppen 

sind entsprechende OpenNMS- 

Benutzer des Teams zugeordnet. Die 

Kontaktinformation – darunter die E- 

Mail-Adresse des OpenNMS-Benutzers 

– lassen sich für die Benachrichtigung 

nutzen. Die Einrichtung der OpenNMS- 

Benutzer und -Gruppen zeigt Abbildung 

8. Sie lässt sich über die Weboberfläche 

im Administrationsbereich »Admin | 

Configure Users, Groups and On‐Call 

Roles« durchführen. 

Abbildung 9: Anlegen des Benachrichtigungspfades für das NOC. 

Der nächste Schritt erstellt zwei Pfade 

für die Benachrichtigung. Das geschieht 

im Administrationsbereich der Weboberfläche 

unter »Admin | Configure 

Notifications | Configure Destination 

Paths«. Dort werden zwei Pfade – wie 

in Abbildung 9 unter Punkt (1) gezeigt – 

erzeugt. Der neu erstellte Pfad wird 

bearbeitet und als Ziel wird die Benutzergruppe 

NOC ausgewählt. 

Die Konfiguration »Initial Delay« (2) 

legt fest, wie lange eine Benachrichtigung 

bei einer aufgetretenen Störung 

zurückgehalten wird, bevor OpenNMS 

die E-Mail an die Gruppe versendet. 

Beim Bearbeiten des Pfades ist darauf 

zu achten, dass als Benachrichtigungskommando 

der Wert »javaEmail« (4) 

ausgewählt ist. 

Im letzten Schritt wird die eigentliche 

Benachrichtigung konfiguriert. 

Jede Störung erzeugt ein Ereignis in 

OpenNMS. Ereignisse werden durch 

einen Bezeichner – die UEI – identifiziert. 

Für dieses Beispiel konfiguriert 

der Admin eine Benachrichtigung für 

ein »nodeLostService«-Ereignis. Das 

wird erzeugt, wenn beispielsweise 

ein Server über das Netzwerk mittels 

ICMP noch erreichbar ist, jedoch ein 

Service wie HTTP nicht mehr reagiert. 

Dazu wird über das Hauptmenü im 

Administrationsbereich unter »Admin | 

Configure Notification | Configure Event 

Abbildung 8: OpenNMS-Benutzer und -Gruppen für die Benachrichtigung. 


Admin 

Ausgabe 03-2014

30 

Netzwerk 


n Info 

Notifications« die Benachrichtigung für 

»nodeLostService« bearbeitet. Danach 

wird angezeigt, für welchen Ereignis- 

Bezeichner (UEI) die Benachrichtigung 

angelegt wurde. Der Admin bestätigt 

die Vorauswahl mit »Next« und wird 

daraufhin aufgefordert, anzugeben, für 

welche Systeme und Services die Benachrichtigung 

gelten soll. 

Abbildung 10 zeigt unter Punkt (1), welcher 

Filter für die Produktivumgebung 

eingetragen wird. Die hier gezeigte 

Regel »catincProduction« verwendet 

das Prefix »catinc«. Dieses Prefix steht 

für „category include“ und ist equivalent 

zu »categoryname == 'Production'«. 

Wichtiger Hinweis: Leerzeichen 

und deutsche Umlaute sollte man in 





[1] Christian Pape and Ronny Trommer, Durchleuchtet: 

VMware-Monitoring mit OpenNMS. 

ADMIN-Magazin 2/2013, S. 98. 

[2] OpenNMS-Installation: [http:// www. opennms. 

org/ wiki/ Tutorial_Installation] 

[3] OCS: [http:// wiki. ocsinventory‐ng. org/ index. 

php/ Documentation:Server] 

[4] OCS-Integration: [http:// www. opennms. org/ 

wiki/ OCS_Integration] 

[5] Provisioning: [http:// www. opennms. org/ w/ 

images/ c/ ca/ ProvisioningUsersGuide. pdf] 

[6] Notifications: [http:// www. opennms. org/ 

wiki/ Tutorial_Notifications] 

[7] Puppet: [http:// puppetlabs. com] 

[8] Chef: [http:// www. getchef. com] 

[9] OpenNMS-Conference: 

[http:// www. opennms. eu] 

Surveillance-Categories vermeiden. Die 

Filter und Regelauswertungen können 

an manchen Stellen Probleme verursachen. 

Mit der Auswahl »Validate rule 

results« lässt sich anzeigen, auf welche 

Systeme die Filterregel anzuwenden 

sind. Der Assistent wird dann durch 

Auswählen von »Skip results validation« 

fortgesetzt. 

Die Abbildung 10 zeigt unter Punkt (2), 

dass sich die Bezeichnung von »node- 

LostService« auf »NOC: nodeLostService« 

geändert hat. Damit sieht man in 

der Benutzeroberfläche, dass diese Benachrichtigung 

für das NOC-Team gedacht 

ist. Unter »Choose a Path« wählt 

man den zuvor angelegten Benachrichtigungspfad 

»NOC‐Team« aus. 

Falls gewünscht, kann der eigentliche 

Benachrichtigungstext hier geändert 

werden. Ein Textgerüst kann mit Variablen 

wie zum Beispiel »%nodelabel%« 

gefüllt werden. Diese Variablen füllen 

sich dann bei einer Störung mit Werten 

für ein konkretes System. Sicherheitshalber 

sollte man überprüfen, dass die 

Benachrichtigung unter »Admin | Notification 

Status« auf »On« gesetzt ist. Es 

könnten auch einzelne Benachrichtigungen 

deaktiviert sein. Deshalb sollte 

man unter dem Punkt »Admin | Configure 

Notifications | Configure Event Notifications« 

den Punkt »NOC: nodeLost- 

Service« aktivieren. Für die Benachrichtigung 

an das Entwicklungsteam wird 

eine zweite Benachrichtigung für das 

Ereignis »nodeLostService« nach dem 

gleichen Schema erzeugt. Wie in Abbildung 

10 dargestellt, ist als Filterregel 

lediglich »catincStage« einzutragen. 

Für die Benachrichtigung selbst ist 

als Name »Dev: nodeLostService« verwendbar. 

Zum Schluss wird noch der 

Zielpfad für die Benachrichtigung auf 

»Development‐Team« gesetzt. 

Fazit 

Das Zusammenspiel der beiden Anwendungen 

OCS und OpenNMS zeigt, dass 

freie Anwendungen sehr gut von offenen 

Schnittstellen profitieren können. 

Über das hier demonstrierte Beispiel 

hinaus wäre es unter anderem auch 

denkbar, beim Ausrollen der beteiligten 

Systeme mit Puppet [7] oder Chef 

[8] die OCS-Attribute bereits bei der 

Installation der OCS-Agenten setzen zu 

lassen. 

Wer interessiert ist, Anwendungsfälle 

wie den hier vorgestellten direkt mit 

anderen Anwendern und Entwicklern 

zu besprechen, der ist auf der 

OpenNMS User Conference [9] vom 8. 

bis 11. April 2014 an der Universität in 

Southampton herzlich willkommen. Es 

werden dort neben vielen Anwendern 

von OpenNMS auch etliche Entwickler 

von OCS Inventory und OpenNMS 

anwesend sein und Rede und Antwort 

stehen. (jcb) n 

n Autoren 

Die Autoren Ronny Trommer und Markus Neumann 

sind Gründungsmitglieder des gemeinnützigen Vereins 

OpenNMS Foundation Europe. Die Entwicklung 

wurde im OpenNMS-Projekt im Rahmen des Google 

Summer of Code 2013 initiiert und von Markus 

Neumann als Mentor begleitet. Ronny Trommer ist 

nebenberuflich als Dozent im Fachbereich Angewandte 

Informatik an der Hochschule Fulda mit dem 

Schwerpunkt Integrated Networking tätig. 

Abbildung 10: Benachrichtigungsfilter und Ziel auswählen. 


32 

Netzwerk 

HA-Proxy 

tiero, 123RF 

Passthrough und Offloading: HTTPS balancieren mit HA-Proxy 1.5 

Verschlüsselte Last 

HA-Proxy verteilt die Besucherströme vielgenutzter Webseiten auf verschiedene Server; die nächste Version 

optimiert auch verschlüsselte Verbindungen. Zu den Nutzern des Loadbalancer zählen unter anderem 

die extrem häufig frequentierten Seiten Twitter, Stack Overflow, Reddit und Tumblr. Charly Kühnast 

n Autor 

Bei womöglich zehntausend gleichzeitigen 

Zugriffen auf eine Webseite 

muss sich die Last möglichst geschickt 

auf mehrere Server verteilen. Für die 

optimale Nutzung der vorhandenen 

Hardware sorgt HA-Proxy [1]. HTTP- 

Server stoßen allerdings beim Einsatz 

von SSL-verschlüsselten Verbindungen 

schneller an ihre Grenzen, denn jede 

Ent- und Verschlüsselung erfordert 

zusätzliche Rechenleistung. An dieser 

Stelle legt die in Entwicklung befind- 

Charly Kühnast stieg in den frühen 90ern von IBM- 

Mainframes auf Linux um und ist Sysadmin in einem 

niederrheinischen Rechenzentrum. Seine Freizeit 

verbringt er als Aushilfslehrer in verschiedenen 

Hochschulen, als Autor für Medialinx und Galileo 

Press, im Dojo und – am liebsten – in der Küche. 

liche HA-Proxy-Version 1.5 mit neuen 

Features nach. 

Bisher unterscheiden Loadbalancer wie 

HA-Proxy nicht wesentlich zwischen 

HTTPS- und unverschlüsselten HTTP- 

Verbindungen. Sie leiten die geschützten 

Anfragen per SSL-Passthrough 

ungerührt an die passenden Webserver 

weiter. Für HA-Proxy genügt dafür die 

recht übersichtliche Konfiguration in 

Listing 1. 

HTTP mit oder ohne S? 

Der größte Unterschied zwischen HTTPund 

HTTPS-Balancing besteht in der 

Zeile »mode tcp« (unter »https_frontend«), 

während bei der unverschlüsselten 

Variante »mode http« zum Einsatz 

kommt. Im letzteren Modus nutzt 

HA-Proxy die HTTP- Header-Daten, um 

Balancing-Entscheidungen zu treffen. 

Die beiden mit »stick« beginnenden 

Zeilen im Abschnitt »backend« sorgen 

dafür, dass ein Client immer auf 

demselben Webserver landet. Diese 

Zuordnungen merkt sich HA-Proxy in 

einer eigenen Tabelle, der sogenannten 

Stick-Table. 

Das Schlüsselwort »check« in der 

Server-Definition bewirkt, dass HA- 

Proxy die Backend-Server zyklisch auf 

Lebenszeichen prüft. Zusätzlich steht 

hierfür die »httpchk«-Option zur Verfügung. 

Sie bleibt in der noch aktuellen 

Version 1.4 von HA-Proxy dem unverschlüsselten 

HTTP-Verkehr vorbehalten, 

die finale Version 1.5 wird sie auch 

in Verbindung mit SSL erlauben. 

Eingeschaltet wird die erweiterte Prüfung 

im einfachsten Fall mit »option 

httpchk«. HA-Proxy sendet dann einen 

vollständigen HTTP-Request an den 


Netzwerk 

HA-Proxy 

33 

Backend-Server (»OPTIONS /«) und 

betrachtet ihn als gesund, wenn er eine 

Antwort mit den Statuscodes »2xx« 

oder »3xx« zurückbekommt. Sowohl 

die Request-Methode als auch die URL 

lassen sich anpassen: 

option httpchk HEAD / 

option httpchk OPTIONS /documents/all/ 

Die erste Zeile ersetzt die Default- 

Methode »OPTIONS« durch »HEAD«. Die 

zweite verwandelt die Standard-URL 

»/« in »/documents/all«. 

Im Normalfall laufen die Lebenszeichen 

über HTTP 1.0 ab, aber HTTP 1.1 ist 

auch erlaubt. Dazu ist das »Host«-Feld 

erforderlich, das man beginnend mit 

der Zeichenfolge »\r\n« an die Protokollversion 

anhängt: 

option httpchk HEAD U 

HTTP/1.1\r\nHost:\ www 

SSL-Offloading 

Das grundlegende Problem beim 

HTTPS-Balancing besteht in der zusätzlichen 

Last auf den Backend-Servern, 

denn SSL ist rechenintensiv – die 

Server können nicht so viele Clients 

bedienen wie ohne SSL. Für dieses Problem 

hat die in Entwicklung befindliche 

Version 1.5 von HA-Proxy eine Lösung 

an Bord: SSL-Offloading oder SSL-Termination. 

Die neue HA-Proxy-Version 

bringt unter anderem die Möglichkeit 

mit, die Verschlüsselung von SSL- 

Verbindungen schon am Loadbalancer 

zu terminieren, sodass dieser mit den 

Backend-Webservern nur noch HTTP 

spricht. Das entlastet die Webserver 

vom Zeit- und Ressourcen-intensiven 

Ver- und Entschlüsseln. Sofern die 

Hardware des Balancers mitspielt, 

erzielt diese Methode deutliche Geschwindigkeitsvorteile. 

SSL-Offloading ermöglicht beim Kompilieren 

des Quellcodes die Option 

»USE_OPENSSL=1«. Fertig geschnürte 

Pakete stehen für einige populäre 

Linux-Distributionen ebenfalls bereit, 

darunter Debian [2], Ubuntu [3] sowie 

OpenSuse und Suse Linux Enterprise 

Server (SLES) [4]. Listing 2 zeigt die für 

SSL-Offloading abgewandelte Konfiguration. 

Im Abschnitt »frontend« fällt auf, dass 

die »bind«-Zeile jetzt Informationen 

über das SSL-Zertifikat enthält. Für 

einen SSL-Offloading-Test genügt an 

dieser Stelle das von OpenSSL für 

Testzwecke mitgelieferte Snakeoil-Zertifikat. 

Wenn alles richig funktioniert, 

tauscht man es durch ein korrektes 

Zertifikat aus. In die unter »bind« angegebene 

PEM-Datei gehören sowohl das 

Serverzertifikat als auch der zugehörige 

private Schlüssel, sie werden darin aneinandergehängt: 

#~ cat /etc/ssl/certs/ssl‐cert‐snakeoilU 

.pem /etc/ssl/private/ssl‐cert‐U 

snakeoil.key > /etc/haproxy/snakeoil.pem 

Abbildung 1: Die HA-Proxy-Statistik demonstriert die Stickiness: Alle Verbindungen des 

untersuchten Clients landen auf dem Server »web2«. 

Im Abschnitt »backend« sind die Server 

nun von ihrer SSL-Last befreit und lauschen 

auf Port 80. 

Außerdem kümmern sich nun Cookies 

um die sogenannte Stickiness, die 

Zuordnung eines Clients zu einem bestimmten 

Server. Kommt die Anfrage 

n Listing 1: HA-Proxy mit SSL-Passthrough 

01 global 

02 log /dev/log local0 

03 log /dev/log local1 notice 

04 

05 maxconn 1000 

06 daemon 

07 user haproxy 

08 group haproxy 

09 

10 defaults 

11 log global 

12 mode tcp 

13 option httplog 

14 option dontlognull 

15 timeout server 5s 

16 timeout connect 5s 

17 timeout client 5s 

18 errorfile 400 /etc/haproxy/errors/400.http 







25 

26 frontend https_frontend 

27 bind *:443 

28 mode tcp 

29 option httpclose 

30 option forwardfor 

31 reqadd X‐Forwarded‐Proto:\ https 

32 default_backend httpserver 

33 

34 listen stats :2000 

35 mode http 

36 stats enable 

37 stats hide‐version 

38 stats realm Haproxy\ Statistics 

39 stats uri / 

40 stats auth admin:secret 

41 

42 backend httpserver 

43 mode tcp 

44 balance roundrobin 

45 stick‐table type ip size 200k expire 60m 

46 stick on src 

47 server web1 10.0.0.1:443 

48 server web2 10.0.0.2:443 


Admin 

Ausgabe 03-2014

34 

Netzwerk 

HA-Proxy 

n Info 





[1] HA-Proxy: [http:// haproxy. 1wt. eu/] 

[2] HA-Proxy-1.5-Debian-Pakete: [http:// packages. 

debian. org/ de/ experimental/ haproxy] 

[3] HA-Proxy-1.5-Ubuntu-Pakete: 

[https:// launchpad. net/ ~vbernat/ +archive/ 

haproxy‐1. 5] 

[4] HA-Proxy-1.5-Suse-Pakete: [http:// www. 

rpmseek. com/ rpm‐pl/ haproxy‐1. 5. html] 

eines Clients ohne passenden Cookie 

am Balancer an, fügt HA-Proxy einen 

»SERVERID«-Cookie in die Antwort ein, 

der den Namen des Servers enthält, 

etwa »web1«. Bei der nächsten Verbindung 

vom gleichen Client – dieses Mal 

mit Cookie – weiß HA-Proxy, zu welchem 

Server es die Anfrage schicken 

soll. Dieser Trick erspart dem Loadbalancer 

die Pflege einer Stick-Table. 

Listing 3 zeigt einen Ausschnitt der 

HA-Proxy-Debugging-Ausgabe mit der 

Ausgabe des Cookies. 

Vor dem Start steht schließlich eine 

Syntaxprüfung der Konfigurationsdatei 

an: 

#~ haproxy ‐c ‐f /etc/haproxy.cfg 

Antwortet HA-Proxy mit der Meldung 

»Configuration file is valid«, steht der 

ausgewogenen Lastverteilung kaum 

etwas im Wege. Beim Aufruf der HTTPS- 

Adresse beschwert sich der Browser 

zwar noch über das zum Testen 

verwendete, aber wertlose Snakeoil- 

Zertifikat, dem die vertrauenswürdige 

Signatur fehlt. Nach dem Abnicken dieser 

Warnung funktioniert aber alles wie 

gewünscht: Client und Loadbalancer 

unterhalten sich per HTTPS, Balancer 

und Webserver per HTTP. Die Statistik 

(siehe Abbildung 1) zeigt die Stickiness 

auf: Die eingehenden Verbindungen 

eines Clients landen alle auf Server 

»web2«, während der Server »web1« 

auf neue Clients wartet. (csc) n 

n Listing 2: HA-Proxy mit SSL-Offloading 

01 global 

02 log /dev/log local0 

03 log /dev/log local1 notice 

04 

05 maxconn 1000 

06 daemon 

07 user haproxy 

08 group haproxy 

09 

10 defaults 

11 log global 

12 mode http 

13 option httplog 

14 option dontlognull 

15 timeout server 5s 

16 timeout connect 5s 

17 timeout client 5s 








25 

26 frontend https_frontend 

27 bind *:443 ssl crt /etc/haproxy/snakeoil.pem 

28 mode http 

29 option httpclose 

30 option forwardfor 

31 reqadd X‐Forwarded‐Proto:\ https 

32 default_backend httpserver 

33 

34 listen stats :2000 

35 mode http 

36 stats enable 

37 stats hide‐version 

38 stats realm Haproxy\ Statistics 

39 stats uri / 

40 stats auth admin:secret 

41 

42 backend httpserver 

43 mode http 

44 balance roundrobin 

45 cookie SERVERID insert indirect nocache 

46 server web1 10.0.0.1:80 check cookie web1 

47 server web2 10.0.0.2:80 check cookie web2 

n Listing 3: HA-Proxy-Output mit Cookie-Vergabe 

01 0000000e:stats.clireq[0008:ffff]: GET / HTTP/1.1 

02 0000000e:stats.clihdr[0008:ffff]: Host: 10.0.0.150:2000 

03 0000000e:stats.clihdr[0008:ffff]: Connection: keep‐alive 

04 0000000e:stats.clihdr[0008:ffff]: Authorization: Basic YWRtaW46c2VjcmV0 

05 0000000e:stats.clihdr[0008:ffff]: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 

06 0000000e:stats.clihdr[0008:ffff]: User‐Agent: Mozilla/5.0 (X11; Linux x86_64) Ubuntu Chromium/31.0.1650.63 

07 0000000e:stats.clihdr[0008:ffff]: Accept‐Encoding: gzip,deflate,sdch 

08 0000000e:stats.clihdr[0008:ffff]: Accept‐Language: de‐DE,de;q=0.8,en‐US;q=0.6,en;q=0.4 

09 0000000e:stats.clihdr[0008:ffff]: Cookie: SERVERID=web2 


Methee Wongwuttikomjorn, 123RF 

Systeme vollständig sichern und wiederherstellen mit Redo Backup 

Sicherer Kreislauf 

Redo Backup sichert komplette Festplatten übers Netzwerk oder lokal. Im Vordergrund stehen dabei eine 

einfache Bedienung und hohe Zuverlässigkeit in vielfältigen Einsatz-Szenarien. Thomas Zeller 

n Redo-Backup-Live-CD 

Die Redo-Backup-Entwickler stellen unter [5] eine 

ausführliche Schritt-für-Schritt-Anleitung für die Erstellung 

einer eigenen Live-CD zur Verfügung. Basis 

für die dort beschriebene Vorgehensweise ist Ubuntu 

12.04 (Precise Pangolin) und ADeskBar Version 0.4.3. 

Letzteres ist der Python-/GTK-basierende Applikationsstarter 

für Openbox, auf dem das vereinfachte 

Startmenü von Redo Backup basiert. 

Nach Aussage der Entwickler eignen sich auch 

neuere Ubuntu-Releases als Basis für eine eigene 

Live-CD – allerdings wächst dadurch die Größe der 

Image-Datei. Dafür ersetzt man den in der Anleitung 

genannten Versionsnamen »precise« durch den eines 

neueren Ubuntu-Release. Das Ubuntu-Wiki listet sie 

unter [6] vollständig auf. 

Bare Metal: Redo Backup sichert alle 

auf einem Rechner vorhandenen 

Daten, inklusive Bootmanager und 

Betriebssystem. Im Ernstfall stellt es so 

den alten Zustand vollständig wieder 

her und die Arbeit geht sofort weiter. 

Was ist Redo Backup 

Redo Backup [1] ist eine auf Ubuntu 

Linux basierende Live-CD zur einfachen 

Sicherung und Wiederherstellung kompletter 

Festplatten inklusive sämtlicher 

Partitionen und des Master Boot Records 

(MBR). Das zu Redaktionsschluss 

aktuelle Release 1.0.4 liegt diesem Heft 

bei. Es basiert auf Ubuntu 12.04.1 (LTS), 

verwendet als Desktop allerdings den 

Fenstermanager Openbox und liefert 

nur die für den Einsatz als Backup- oder 

Rettungssystem erforderlichen Applikationen 

mit. 

Redo Backup ist sofort einsatzbereit, 

nachdem die 250 MByte große Image- 

Datei auf CD gebrannt ist. Für die 

Sicherung virtueller Maschinen lässt 

sie sich auch direkt als virtuelles CD- 

Laufwerk einbinden. Auf diese Weise 

ermöglicht eine virtuelle Maschine, die 

vom CD-Image bootet, auch im laufenden 

System einen ersten Blick auf das 

Backup-System. 

Was Redo Backup kann... 

Redo Backup vereint die Vorteile eines 

verlässlichen Betriebssystems mit umfangreicher 

Hardware-Unterstützung 

auf einer Live-CD und die Vorzüge des 

Partitionswerkzeugs Partclone [2]. Für 

letzteres stellt Redo Backup ein stark 

vereinfachtes, grafisch bedienbares 

Frontend bereit (siehe Abbildung 1). 

Der Hauptanwendungsfall von Redo 


Disaster-Recovery 

Redo Backup 

37 

Abbildung 1: Die Benutzeroberfläche von Redo Backup beschränkt 

sich aufs Wesentliche. 

Abbildung 2: Redo kann Images auf lokal angeschlossene Datenträger, 

Samba-Shares und FTP-Server sichern. 

dem Partitionen an, löscht, formatiert 

sie und verändert ihre Größe. 

Doch der eigentliche Zweck von Redo 

Backup bleibt die vollständige Wiederherstellung 

von Systemen, zum 

Beispiel nach einem Platten-Crash, 

Viren- oder Malware-Befall oder anderen 

Katastrophen. Doch gibt es – neben 

den erwähnten Vorzügen der Live-CD 

mit ihren Rettungstools – mindestens 

zwei weitere attraktive Einsatzmöglichkeiten: 

Die Virtualisierung physikalischer 

Systeme, auch P2V (physical-tovirtual) 

genannt, und die Übertragung 

virtueller Maschinen auf physikalische 

Hardware (V2P) (Abbildung 3). 

...und was nicht 

Da das Hauptaugenmerk 

von Redo Backup 

auf einer möglichst 

einfachen Sicherungsund 

Wiederherstellungsprozedur 

liegt, 

bleiben andere Administrationsfeatures 

außen vor. Die größte 

Einschränkung von 

Redo Backup besteht 

darin, dass es nur 

komplette Datenträger, 

nicht aber individuelle 

Partitionen sichert. 

Damit fehlt auch die 

Möglichkeit, inkrementelle 

oder differenzielle 

Sicherungen anzule- 

Backup ist also das Sichern auf beziehungsweise 

das Wiederherstellen von 

diesen Medientypen (Abbildung 2): 

n Lokale Datenträger wie Festplatten 

und SSDs, 

n per USB angeschlossene Speichermedien, 

n SMB-/CIFS-Freigaben, 

n FTP-Shares. 

Redo Backup sichert nur Bereiche 

der Festplatte, die tatsächlich Daten 

enthalten und spart per Kompression 

Speicherplatz. Das Backup-Ziel darf 

deshalb kleiner ausfallen als die zu 

sichernde Festplatte, solange es genügend 

Platz für die tatsächlich vorhandenen 

Daten bereitstellt. 

Da Redo Backup von einem Live- 

Medium bootet und einige zusätzliche 

Werkzeuge an Bord hat, eignet es sich 

neben dem Backup auch für Reparaturarbeiten 

am Dateisystem. So enthält 

der Werkzeugkasten neben Dateimanager, 

Bildbetrachter, Terminal, 

Texteditor und Browser auch das Red 

Hat Disk Utility. Es mountet, löscht, erstellt 

und überprüft Dateisysteme und 

fertigt Benchmarks an. 

Mit Baobab steht daneben ein Werkzeug 

zur grafischen Darstellung der 

Datenträgerbelegung zur Verfügung, 

Photoreq und Testdisk sind für die Wiederherstellung 

versehentlich gelöschter 

Dateien zuständig. Drivereset löscht 

bei Bedarf Datenträger komplett und 

setzt sie auf ihren Auslieferungszustand 

zurück. Mit GParted legt man außergen; 

auch die Wiederherstellung einzelner 

Dateien ist unmöglich. Das Ziel 

für die Rücksicherung darf außerdem 

nicht kleiner sein als der Sicherungsdatensatz. 

Leider erzeugt Redo Backup weder 

verschlüsselte Backups noch sichert es 

über SSH. Eine weitere Einschränkung 

betrifft Rechner mit UEFI-Secure-Boot: 

Da die aktuelle Version der Redo- 

Backup-Live-CD noch auf Ubuntu 

12.04.1 LTS basiert, muss man für 

ihren Einsatz Secure Boot im BIOS abschalten. 

Dieses Problem schafft das 

nächste Update von Redo Backup voraussichtlich 

aus der Welt, da Ubuntu 

seit Version 12.04.2 kompatibel mit 

Secure Boot ist [3]. Wer nicht solange 

Abbildung 3: Die Redo-Backup-Live-CD enthält essenzielle Werkzeuge 

zur Datenträger- und Partitionsverwaltung sowie zur Datenrettung. 


Admin 

Ausgabe 03-2014

38 


Redo Backup 

n Info 





[1] Redo Backup: [http:// sourceforge. net/ 

projects/ redobackup/ files/ latest/ download/] 

[2] Partclone: [http:// partclone. org/] 

[3] UEFI unter Ubuntu: [https:// help. ubuntu. com/ 

community/ UEFI] 

[4] Unetbootin: 

[http:// unetbootin. sourceforge. net/] 

[5] Redo-Backup-Wiki: [http:// sourceforge. net/ p/ 

redobackup/ wiki/ Home/] 

[6] Ubuntu-Release-Namen: [https:// wiki. ubuntu. 

com/ DevelopmentCodeNames] 

n Autor 

Thomas Zeller ist IT-Consultant 

und beschäftigt sich seit über 15 

Jahren mit IT-Sicherheit und Open 

Source. Er ist Autor beziehungsweise 

Co-Autor der Bücher Open- 

VPN kompakt und Mindmapping 

mit Freemind. Im richtigen Leben 

ist er IT-Unternehmer und Geschäftsführer 

eines IT-Systemhauses. 

Dort verantwortet er unter 

anderem den Geschäftsbereich 

IT- Sicherheit. 

warten möchte, erstellt sich eine eigene 

Redo-Live-CD (siehe Kasten „Redo- 

Backup-Live-CD“). 

Loslegen mit Redo Backup 

Gleichwohl bietet Redo Backup auch 

bei anderen Admin-Arbeiten Hilfestellung. 

Die aufs Wesentliche reduzierte 

Benutzeroberfläche schafft in stressigen 

Situationen einen Überblick und 

ist etwa bei der telefonischen Unterstützung 

für Laien ohne Blick auf deren 

Bildschirm hilfreich. 

Wem der Start der Live-CD zu lange 

dauert, der überträgt das Redo Backup- 

Image auf einen USB-Stick. Die Entwickler 

empfehlen dafür Unetbootin 

[4], alternativ liefert die Live-CD mit 

dem Ubuntu Startup Disk Creator aber 

auch ein eigenes Werkzeug für diesen 

Zweck mit. 

Nachdem der Rechner von der Live-CD 

oder einem USB-Medium gebootet hat, 

startet Redo Backup automatisch die 

GUI zum Sichern und Wiederherstellen 

der im Gerät eingebauten Datenträger. 

Leider bietet die grafische Oberfläche 

keine Möglichkeit, die Tastaturbelegung 

auf Deutsch umzustellen. Doch 

gerade wegen der häufigen Verwendung 

von Zeichen wie »/« in Pfadangaben 

wird dies schnell lästig. Wer die 

US-Tastatur nicht ohnehin verinnerlicht 

hat, aktiviert deshalb mit dem Kommando 

»setxkbmap de« die deutsche 

Tastenbelegung. 

Wer weiterhin die Ausgabe von Redo 

Backup im Detail verfolgen möchte, 

startet das Backup-Programm im 

Terminal mit »redobackup«. Die weitere 

Bedienung erklärt sich indes von 

selbst: »Backup« sichert den vollständigen 

Datenträger inklusive aller Partitionen 

und Master Boot Record auf eine 

lokal angeschlossene USB-Festplatte, 

ein Netzlaufwerk oder auf einen FTP- 

Server. »Restore« stellt von diesen 

Quellen ein zuvor angelegtes Backup 

wieder her. Das funktioniert über die 

GUI zuverlässig und einfach, aber je 

nach Umfang der Sicherung nehmen 

sowohl Backup als auch Wiederherstellung 

mehrere Stunden in Anspruch. 

Eine typische Windows-7-Standard- 

Installation mit Office lässt sich ohne 

umfangreiche Daten dagegen schon in 

wenigen Minuten sichern und wiederherstellen. 

Fazit 

Redo Backup zielt mit seiner aufs Wesentliche 

reduzierten Benutzeroberfläche 

auch auf weniger versierte Anwender. 

Es verzichtet auf manche Features 

wie die Sicherung einzelner Dateien 

zugunsten seiner präzise und zuverlässig 

erledigten Hauptaufgabe: Disaster 

Recovery. (csc) n 

n Alternativen zu Redo Backup 

Admins, die flexiblere Möglichkeiten zur Sicherung oder Wiederherstellung 

von Datenträgern benötigen, finden nachfolgend eine Auswahl 

alternativer Imaging-Backup-Werkzeuge: 

Free und Open Source: 

n Clonezilla: Auf Debian basierende Live-CD mit textbasierter Menüführung. 

Klont und sichert einzelne Partitionen oder komplette Datenträger 

und stellt sie wieder her. 

n G4L: Vormals »Ghost for Linux« sichert ganze Datenträger, einzelne 

Partitionen und einzelne Dateien. Textbasierte Menüführung, sichert 

auch auf SSHFS. 

n Partimage: Sichert Datenträger oder Partitionen via SSL übers Netzwerk 

mit eigenem Server und Client. Keine Unterstützung für Ext4 

und Btrfs. Stellt auch einzelne Dateien aus den Images wieder her. 

n Mondo Rescue: Disaster-Recovery-Lösung, die Backups vollständiger 

Datenträger erstellt und auf CD oder DVDs verteilt. Eine Boot-CD 

stellt mit diesen Backup-CDs einen Rechner vollständig wieder her. 

n Partclone [2]: Kommandozeilenwerkzeug zum Sichern und Wiederherstellen 

benutzter Partitionsblöcke. 

n Trinity Rescue Kit (TRK): Live-CD und Rettungssystem mit textbasierter 

Menüführung, insbesondere zur Wiederherstellung von Windows- 

Systemen unter anderem mit Passwort-Recovery und Viren-Scanner. 

n SystemRescueCD: Live-System mit zahlreichen Rettungswerkzeugen, 

verwendet Partimage zum Sichern von Festplatten und Partitionen. 

Kommerzielle Systeme: 

n Partedmagic: Seit August 2013 kostenpflichtig; Live-CD mit grafischen 

Tools für Partitionierung, Cloning, Datenrettung und Löschen 

von Daten. 

n Acronis True Image: Disk-Imaging für Windows- und Linux-Server 

mit optionaler Datensicherung in die Cloud. 

n Symantec Ghost Solution Suite: Client-Server-Modell mit zentraler 

Konsole für die Image-Verwaltung. 

n Paragon Festplattenmanager Premium: Disk-Imaging für Windows 

Server mit WinPE-Rettungsumgebung. 

n Storagecraft Shadowprotect: Umfangreiches Disk-Imaging-Werkzeug; 

nur für Windows-Systeme. 


Olha Shtepa, 123RF 

Relax and Recover 

Entspann Dich 

Relax and Recover (ReaR) erzeugt aus einem laufenden System ein passendes Rettungsmedium und 

eignet sich nebenbei auch als Migrationstool. Dieser Beitrag zeigt allen, die das interessante Bash-Tool 

nicht kennen, was sie verpasst haben. Thomas Drilling 

Ein regelmäßig durchgeführtes Backup 

gehört trotz Verfügbarkeit von Imaging- 

Lösungen und dem zunehmenden 

Einsatz von Virtualisierungstechnologien 

zum Pflichtprogramm für alle Unternehmen. 

Fatalerweise wähnen sich 

gerade kleine Unternehmen angesichts 

einer vorhandenen Backup-Lösung 

nicht selten in trügerischer Sicherheit. 

Selbst wer den potenziellen Ernstfall 

sogar personell und finanziell einplant, 

unterschätzt häufig die tatsächlichen 

Folgen. 

Abgesehen davon, dass vorhandene 

Backup-Medien turnusmäßig in 

Stichproben auf Ihre Lesbarkeit und 

Verwendbarkeit geprüft werden sollten, 

müssen Unternehmen auch den 

gesamten Workflow für den Recovery- 

Prozess im Vorfeld testen und im Ernstfall 

beherrschen. Selbstverständlich 

muss für den Ernstfall auch sofort 

einsetzbare Ersatz-Hardware vorhanden 

oder schnell beschaffbar sein, was 

nicht selbstverständlich ist, es sei denn, 

das Unternehmen setzt bereits auf 

Virtualisierung. In jedem Fall stehen im 

Ernstfall je nach Unternehmensgröße 

Stunden bis Tage an Handarbeit an, sogar 

wenn ein Daten-Backup vorhanden, 

vollständig integer und aktuell ist. 

Folgen des Ernstfalls 

So muss zum Beispiel beim Ersatzsystem 

mit möglichst identischer Hardware 

das Partitions-Layout oder die 

Konfiguration eines RAID-Verbundes 

dem Zustand vor dem Crash entsprechen. 

War der Patch-Level vor dem 

Crash auf dem aktuellen Stand und ist 

die Kernel-Version des neu installierten 

Systems noch die gleiche, genügt 

meist eine Basis-Installation des neuesten 

Images und eine anschließende 

Aktualisierung. War das gecrashte 

System nicht auf aktuellem Patch-Level 

oder eine Menge Software von Hand 

installiert, sind Probleme ebenfalls 

vorprogrammiert. Wer bloß von einem 

Backup der Benutzerdaten sein System 

rekonstruieren möchte, kann durchaus 

mit Schwierigkeiten rechnen. Eine Lösung 

für Disaster Recovery hilft, diese 

Problem zu umgehen. 

Das ReaR-Projekt [1] hat seinen Anfang 

im Jahr 2006 als Kooperation zwischen 

dem Berliner Open-Source-Consultant 



ReaR 

41 

und Linux-Enthusiasten Schlomo Schapiro 

und Gratien D’Haese, dem Autor 

von »mkcdrec«. Im Laufe der Zeit kamen 

mit Dag Wieers und Jeroen Hoekx 

zwei weitere Maintainer hinzu, die bis 

heute sehr aktiv sind. Schlomo Schapiro 

kümmert sich im Projekt aktuell 

um architektonische Fragen und ist 

sich für Lobbyarbeit sowie die gesamte 

Kommunikation in Deutschland verantwortlich. 

Als Berliner arbeitet Schlomo 

zudem aktiv am Linuxtag mit und organisiert 

dort den Stand des Yadt- und 

des ReaR-Projekts, die beide seit 2008 

regelmäßig in Berlin vertreten sind. 

Professionell 

Dass inzwischen eine Reihe von Consultants 

wie etwa der Berliner Peer Heinlein 

Geld mit dem Consulting zu ReaR 

verdienen, zeigt, dass es sich beim 

ReaR-Projekt um eine professionelle 

und ernsthafte Angelegenheit handelt. 

In puncto Desaster-Recovery gibt es 

jedenfalls keine vergleichbare freie 

Lösung. Wie aktiv das Projekt ist, zeigt 

auch ein Blick auf Github [2]. Demnach 

arbeiten derzeit 17 Beitragende an der 

unter der GPL stehenden und in Bash 

geschriebenen Software mit. 

Ferner zeigte sich im Laufe unseres 

Tests, dass das Rear-Team in der Lage 

ist, via Mailingliste und Github-Issues 

Support mit einer Reaktionszeit innerhalb 

eines Tages zu leisten, was vermutlich 

eher Regel als Ausnahme ist. 

Darüber hinaus bieten die ReaR-Macher 

wie erwähnt auch kommerziellen 

Support an. Sogar eine beauftragte, 

individuelle Entwicklung weiterer Funktionen 

ist laut Aussage der Projektverantwortlichen 

möglich. Davon profitiert 

auch die Anwendergemeinschaft. 

So haben laut Auskunft von Schlomo 

Schapiro bis heute eine beachtliche Anzahl 

kommerzieller Kunden das Projekt 

mit ihren Anforderung indirekt ebenfalls 

weitergebracht. 

ReaR wird sogar von einigen Anwendern 

als Provisionierungswerkzeug verwendet. 

Hierbei stellt ReaR ein »Golden 

Master Image« wieder her, das dann 

von einem Post-Recovery-Skript angepasst 

wird, wozu die Option »POST_RE- 

COVERY_SCRIPT« zum Einsatz kommt, 

die sich die Fähigkeit der aktuellen 

ReaR-Versionen zunutze macht, das 

Backup an das Zielsystem anpassen zu 

können. 

ReaR als Migrationstool 

Seit Version 1.7 unterstützt ReaR dank 

Udev-Unterstützung neben rein physischen 

Szenarien auch diverse Arten 

vom Virtuellen ins Reale und umgekehrt. 

Somit stellen auch geänderte 

Festplatten-Controller oder Netzwerk- 

Interfaces kein Problem mehr dar. 

ReaR lädt die erforderlichen Treiber 

automatisch und nimmt die notwendigen 

Änderungen an der Initrd vor. 

Auf diese Weise lässt sich ReaR außer 

als Bare-Metal-Recovery-Lösung auch 

als universelles Migrationswerkzeug 

missbrauchen, etwa zum Virtualisieren 

physischer Server (P2V). 

n Migration mit ReaR 

Wie beschrieben eignet sich ReaR auch gut als 

Migrations-Werkzeug, denn bei aktuellen Versionen 

(ab 1.7, [9]) muss die Wiederherstellung nicht mehr 

zwangsläufig auf der gleichen Hardware erfolgen. 

Diese Funktionalität wurde erstmals in einem Projekt 

realisiert, das Schlomo Schapiro gemeinsam mit 

Heinlein Support für einen Großkunden entwickelt 

hatte, war aber von Anfang an geplant und ist seit 

der Version 1.7 standardmäßig in ReaR enthalten. 

Dabei baut ReaR das Rescue-Medium mit sämtlichen 

vorhandenen Treibern auf und passt das wiederhergestellte 

System selbstständig an die geänderte 

Hardware an. Das geht sogar so weit, dass ReaR 

auch geänderte Netzwerkkarten einschließlich eines 

Wegfalls von Bonding bei einer P2V-Migration, abweichende 

Storage-Szenarien mit ihren jeweiligen 

Treibern (zum Beispiel IDE zu SATA, SATA auf CCISS, 

von oder zu RAID und so weiter) und ein geändertes 

Festplattenlayout erkennt. 

Bei relativ einfachen Szenarien, bei denen zum 

Beispiel vor- wie nachher nur ein NIC und eine HD 

existiert, funktioniert das Ganze vollautomatisch. 

Bei komplexeren Migrationen fragt ReaR beim Recovery, 

was es tun soll. In der Dokumentation [10] sind 

exem plarisch eine Reihe von Mapping-Dateien verfügbar, 

mit deren Hilfe sich auch größere Migrationen 

weitgehend automatisieren lassen. Laut Auskunft 

der Entwickler nutzt ein Großkunde diese Funktionalität, 

um mehrere tausend physische Server in einem 

Rutsch nahezu vollautomatisch zu virtualisieren. 

n Tabelle 1: Backup-Lösungen 

Software 

GNU-Tar auf NAS-Share oder Bandlaufwerk 

Rsync auf NAS-Share oder lokales Gerät 

Rsync über Netzwerk 

Rsync Backup Made Easy 

Bacula 

Bareos 

SEP SESAM 

IBM Tivoli Storage Manager 

HP Data Protector 

Symantec NetBackup 

Duplicity/Duply 

CommVault Galaxy 5, 6 und 7 

EMC Networker (ehemals Legato) 

ReaR-Option 

BACKUP=NETFS, BACKUP_PROG=tar 

BACKUP=NETFS, BACKUP_PROG=rsync 

BACKUP=RSYNC – im Unterschied zu BACKUP=NETFS wird hierbei nichts gemountet. Statdessen 

arbeitet Rsync hier direkt mit dem Rsync-Protokoll, sofern vorhanden mit SSH. 

BACKUP=RBME 

BACKUP=BACULA 

BACKUP=BAREOS 

BACKUP=SESAM 

BACKUP=TSM 

BACKUP=DP 

BACKUP=NBU 

BACKUP=DUPLICITY (noch experimentell) 

BACKUP=GALAXY 

BACKUP=NSR 


Admin 

Ausgabe 03-2014

42 


ReaR 

Abbildung 1: Fedora 19 bringt die aktuelle ReaR-Version 1.15 von Haus aus mit. 

ReaR beherrscht aber auch virtual-tophysical 

(V2P) und virtual-to-virtual 

(V2V), womit auch der Rückweg des 

Restaurierens aus einer virtuellen 

Maschine auf einen physischen Server 

oder der Wechsel von einer bestehenden 

Virtualisierungslösung zu einer 

anderen möglich ist. ReaR unterstützt 

KVM, Xen und VMware. Weitere Einzelheiten 

dazu sind im Kasten „Migration 

mit ReaR“ zu finden. 

Abbildung 2: Das ISO-Image landet im Normalfall auch im Backup. 

Was ReaR macht 

ReaR ist eine echte Disaster-Recovery- 

Lösung, die aus einem laufenden 

Linux-System ein Rettungsmedium für 

den Ernstfall erzeugt. Fällt eine Hardwarekomponente 

aus oder muss sie 

aus anderen Gründen ausgetauscht 

werden, kann der Administrator das 

Ersatzsystem von diesem Rettungsmedium 

booten und sein System vollautomatisch 

in den Ursprungszustand versetzen 

– inklusive des Partitionierens 

und Formatierens der Festplatten, des 

Zurückspielens sämtlicher Daten und 

des Installierens des Bootloaders. 

ReaR differenziert dabei aus den beschriebene 

Gründen strikt zwischen 

den Funktionsbereichen Recovery und 

Backup, wobei eine initiale vollständige 

Sicherung des geschützten Systems 

die Grundlage ist. Im Idealfall stellt 

ReaR die Daten aus einem vorhandenen 

Backup wieder her und arbeitet 

dazu mit vielen Backup-Lösungen 

zusammen, darunter Bacula/Bareos, 

SEP SESAM, Tivoli Storage Manager, HP 

Data Protector, Symantec NetBackup, 

CommVault Galaxy und EMC/Legator 

Networker. Weitere Einzelheiten zu den 

unterstützten Backup-Werkzeugen einschließlich 

etwaiger Konfigurationsparameter 

sind Tabelle 1 zu entnehmen. 

Ist keine Backup-Lösung vorhanden, 

kümmert sich ReaR selbst via Tar 

oder Rsync um eine Sicherung, zum 

Beispiel auf einer NFS-Freigabe oder 

einem USB-Device. Mit der Backup- 

Unterstützung kann die sonst bei 

Disaster-Revory-Lösungen obligatorische 

doppelte Datensicherung entfallen. 

ReaR sorgt stets automatisch 

für das Wiederherstellern der jeweils 

neusten Daten. ReaR schreckt auch vor 

komplexen Konfigurationen mit Netzwerk-Bonding, 

Software-RAID, LVM- 

Partitionsschemata und exotischen 

Dateisystemen nicht zurück und bootet 

den restaurierten Server, als wäre nie 

etwas passiert. 

Test-Setup 

Für ein praktisches Test-Setup haben 

wir drei Szenarien durchgespielt, die 

sich auch für eigene Experimente 

aufdrängen, wobei wir uns als Backup- 

Lösung auf die Fähigkeiten von ReaR 

(Tar/Rsync) verlassen haben. Im ersten 

Setup haben wir via Tar auf eine 

NFS-Freigabe unseres NAS gesichert 

und das System anschließend von CD 

wiederhergestellt. Die mit einer etwas 

komfortableren, zentral verwalteten 

Rsync-Variante RBME [3] erstellten 

Backups können – von ReaR über das 

Netz gemountet – direkt wiederhergestellt 

werden; ein Szenario, das wir 

praktisch nicht durchgespielt haben. 

Admins kleiner Umgebungen und 

Heimanwender dürften sich eher mit 

einem Setup identifizieren, bei dem für 

Backup und Recovery ein USB-Storage 

zum Einsatz kommt. Hierbei lässt sich 

ein System auch im mobilen Einsatz 

relativ flexibel auf einem mitgeführten 

USB-Stick oder einer USB- beziehungsweise 

eSATA-Festplatte sichern, die 

dann auch gleichzeitig als bootfähiges 

Disaster-Recovery-Medium dient. 

Ferner haben wir ReaR in einem dritten 

Setup verwendet, um eine VMware-VM 

auf Virtualbox zu migrieren und dabei 

bewusst recht unterschiedliche Hardware 

konfiguriert. Was die Betriebssysteme 

angeht, ist zurzeit lediglich etwas 

Vorsicht mit Fedora 20 [4] und Open- 

Suse 12.3 geboten. Übrigens erstellt 

ReaR für absolut jedes System sein 

persönliches Bootmedium. 



ReaR 

43 

Loslegen mit ReaR 

Das ReaR-Projekt stellt fertige Pakete 

für so ziemlich alle wichtigen Distributionen 

zur Verfügung. Fedora bringt 

von Haus aus ReaR-Pakete mit. Hier 

findet sich eine ältere Version 1.12 im 

Fedora-Repository sowie eine aktuelle 

ReaR-Version 1.15 in Fedora-Updates. 

CentOS-Nutzer finden ReaR im EPEL- 

Repo. Suse Linux Enterprise enthält 

zwar ReaR-Pakete, allerdings nur in 

einer älteren Version. Auch in Open- 

Suse ist ReaR in der Version 1.14 [5] 

zu finden, allerdings gab es im Test 

Probleme mit der Installation. Suse hat 

übrigens sogar ein YaST-Modul [6] für 

ReaR gebaut. Wir haben im ersten Test- 

Setup ein bewährtes Fedora-19-System 

verwendet (Abbildung 1). 

Soll das Desaster-Recovery von einem 

physischen Medium aus erfolgen, 

kann der Systemverwalter jetzt das 

gewünschte Sicherungsmedium vorbereiten, 

seinen USB-Stick mit einer passenden 

Ext2/3/4- oder Btrfs-Partition 

versehen und bootfähig machen. Muss 

er dabei keine Rücksicht auf bestehende 

Daten nehmen, kann er auch 

das komfortabel mit ReaR erledigen: 

/usr/sbin/rear format /dev/sdX 

ReaR erwartet lediglich eine Bestätigung, 

dass es das Medium vollständig 

überschreiben darf und versieht es 

mit der Bezeichnung »REAR‐000«. 

Danach oder bei Szenarien ohne USB- 

Bootmedien geht es ans Bearbeiten der 

Konfigurationsdatei »/etc/rear/local. 

conf«. Dazu kann sich der Systemverantwortliche 

beispielsweise an der 

komplett kommentierten Beispieldatei 

»/usr/share/rear/conf/default.conf« 

entlanghangeln. Die Manpage zu ReaR 

liefert alle benötigten Informationen. 

Darüber hinaus gibt es gute Dokumentation 

und ein etwas ausführlicheres 

User-Guide [7]. 

Einfaches Setup 

Im Großen und Ganzen dreht sich die 

gesamte Konfiguration nur um zwei 

wesentliche Parameter: »OUTPUT=« 

legt die bevorzugte Boot-Methode 

fest und »BACKUP=« die gewünschte 

Backup-Strategie. Mit »OUTPUT=USB« 

beispielsweise sorgt 

der Systemverwalter 

dafür, dass ReaR den 

Rescue-Kernel und 

die Rescue-Initrd auf 

das angegebene USB- 

Medium schreibt und 

dort den Bootloader 

entsprechend konfiguriert. 

Alternativen für die anderen 

skizzierten Szenarien 

wären beispielsweise 

»OUTPUT=ISO«, 

»OUTPUT=PXE« oder 

»OUTPUT=RAMDISK«. 

Mit »OUTPUT=RAM- 

DISK« gibt ReaR nur 

den Kernel und die Initramfs 

aus, der Admin 

kümmert sich um die 

weitere Verarbeitung. 

In der Default-Einstellung 

legt ReaR das fertige 

ISO-Image in einer 

Datei unter »/var/lib/ 

rear/output« ab, wofür 

»OUTPUT_URL=file://« 

verantwortlich ist. 

Generell versucht ReaR 

je nach verwendeter 

Backup-Strategie das 

Bootmedium auch im Backup mit abzulegen. 

Bei TSM wird zum Beispiel das 

Bootmedium durch einen Aufruf der 

Backup-Software mit in die Sicherung 

übernommen. Verwendet der Admin 

das per Default auf Tar eingestellte 

Backup-Verfahren in Verbindung mit 

dem Parameter »BACKUP_URL« zum 

Angeben des Backup-Targets (zum 

Beispiel ein NFS-Share), landet das 

ISO-Image also automatisch auch dort 

(Abbildung 2). 

Hier ist es wesentlich besser aufgehoben, 

denn »/var/lib/rear/output« würde 

im Ernstfall nicht mehr nur Verfügung 

stehen. Abweichend von diesem Verhalten, 

lässt sich mit »OUTPUT_URL=« 

aber auch ein anderes Ziel für das 

Image angeben. Zur Wahl stehen etwa 

»fish«, »ftp(s)«, »http(s)«, »rsync« und 

»sshfs«. 

Die Backup-Strategie gibt »BACKUP=« 

an, wobei ReaR mit »BACKUP=NETFS« 

automatisch Tar benutzt. Mit 

Abbildung 3: Der Simulationsmodus von ReaR. 

»BACKUP_PROG_CRYPT_ENABLED=1« 

klappt das auch verschlüsselt. Eine 

Alternative zu Tar ohne Einsatz eines 

externen Backup-Programms ist beispielsweise 

»BACKUP=RSYNC«. Alternativ 

legt »BACKUP=REQUESTRESTORE« 

fest, dass ReaR nicht automatisch ein 

Backup anfertigt, sondern den Nutzer 

danach fragt. Ebenso lässt sich mit 

»BACKUP=EXTERNAL« eine individuelle 

Backup-Strategie einbeziehen. 

Backup auf NFS oder CIFS 

Wurde das Backup-Verfahren auf 

»NETFS« gesetzt, gibt »BACKUP_URL=« 

das gewünschte Backup-Ziel an, zum 

Beispiel ein USB-Device oder eine NFSbeziehungsweise 

CIFS-Freigabe: 

BACKUP_URL=nfs://NFS‐Server/U 

Freigabe/Pfad ... 

ReaR legt dann unterhalb von »NFS‐Server/Freigabe/Pfad« 

einen Ordner mit 


Admin 

Ausgabe 03-2014

44 


ReaR 

n Info 

dem Namen des Clients an. Es funktioniert 

aber auch eine Datei auf der lokalen 

Festplatte, ein Tape-Device oder 

eine Samba-Freigabe: 

BACKUP_URL=file:///Verzeichnis/U 

Pfad/ 

BACKUP_URL=tape:///dev/nst0, ... 

BACKUP_URL=cifs://Samba‐Server/U 

Freigabe/Pfad.. 

Soll ReaR sich per CIFS/Samba authentifizieren, 

legt der Admin eine entsprechende 

Datei »/etc/rear/.cifs_credentials« 

an, auf die er aus »/etc/rear/local. 

conf« mit 

BACKUP_OPTIONS="cred=/etc/rear/U 

.cifs_credentials" 

verweist und darin Werte für »username«, 

»password« und »domain« 

einträgt. 





[1] ReaR-Projekt-Seite: 

[http:// relax‐and‐recover. org] 

[2] ReaR auf Github: [https:// github. com/ rear/ 

rear/ commits/ master] 

[3] RBME: [https:// github. com/ schlomo/ rbme] 

[4] Git-Issue Fedora: 

[https:// github. com/ rear/ rear/ issues/ 346] 

[5] ReaR in OpenSuse: [http:// software. opensuse. 

org/ package/ rear] 

[6] YaST-Modul für Suse: [http:// software. 

opensuse. org/ package/ yast2‐rear] 

[7] ReaR-User-Guide: [https:// github. com/ 

rear/ rear/ blob/ master/ doc/ user‐guide/ 

03‐configuration. txt] 

[8] SEP-SESAM-Support: 

[http:// wiki. sep. de/ wiki/ index. php/ Disaster_ 

Recovery_for_Linux_3. 0_en] 

[9] ReaR-1.15-Release-Notes: [http:// 

relax‐and‐recover. org/ documentation/ 

release‐notes‐1‐15] 

[10] Aktueller ReaR-Vortrag: [http:// www. 

slideshare. net/ schlomo/ brainshare‐2010‐slcels306‐linux‐disaster‐recovery‐made‐easy] 

Wer »OUTPUT=USB« mit »BACKUP_ 

URL=usb://...« kombiniert, kann sowohl 

das Backup als auch das Rescue-Image 

auf das gleiche USB-Device schreiben, 

was für den Ad-hoc-Einsatz sehr nützlich 

ist, weil man in einem Rutsch ein 

bootfähiges Wiederherstellungsmedium 

erhält, vorausgesetzt, es steht 

genügend Platz zur Verfügung: 

BACKUP_URL=usb:///dev/GerätU 

/Label/REAR‐000 

ReaR legt per Default ein Voll-Backup 

an. Alternativ stehen eine Reihe von 

»EXCLUDE«-Optionen zum Eingrenzen 

des gewünschten Backup-Umfangs zur 

Verfügung. So lassen sich beispielsweise 

mit 

AUTOEXCLUDE_PATH=( /media ) 

gezielt gemountete Verzeichnisse, wie 

etwa Netzwerkfreigaben oder gemountete 

externe Partitionen, vom Backup 

ausnehmen. Dagegen schließt 

AUTOEXCLUDE_DISKS=y 

sämtliche Festplatten und Partitionen 

vom Backup aus, die nicht von gemounteten 

Dateisystemen in Anspruch 

genommen werden. Genauso einfach 

lassen sich mit 

AUTOEXCLUDE_AUTOFS=.. 

sämtliche Automounter-Pfade ausschließen. 

Wer zunächst nur das Rescue-Image 

anlegen und testen will, startet ReaR 

dann mit »rear mkrescue«. Genauso ist 

es möglich, nur das Backup mit »rear 

mkbackuponly« anzuschieben. 

Im Normalfall wird der Administrator 

beides in einen Rutsch erledigen wollen, 

was auch der beschriebenen Kernfunktionalität 

von ReaR entspricht. 

Schweigsam 

Da für den Einsatz in Cronjobs optimiert, 

zeigt ReaR im Regelfall nichts an. 

»rear ‐v« aktiviert den Verbose-Modus. 

Übrigens zeigt ReaR mit »rear ‐s« (Simulationsmodus) 

zunächst nur an, 

was es tun würde. Hierbei zeigt sich 

der modulare Aufbau von ReaR. Eigene 

Erweiterungen lassen sich so einfach 

an der richtigen Stelle einklinken. Dazu 

muss man nur ein passend benanntes 

Shell-Skript im gewünschten Pfad ablegen 


Weitere Optionen für den ReaR-Start 

listet die Manpage. Hier finden sich 

auch alle verfügbaren »BACKUP«- und 

»OUTPUT«-Targets. Danach sollte es 

möglich sein, vom Rescue-Image zu 

booten und ReaR stellt von diesem und 

gegebenenfalls von einem vorhandenen 

Backup-Medium vollautomatisch 

das gesamte System wieder her. 

Was noch geht 

Neben den beschriebenen Standard- 

Funktionen kann ReaR aber noch 

einiges mehr. So kann sich der Admin 

beispielsweise die Ergebnisdateien (unter 

anderem auch das ISO-Image) per 

Mail schicken lassen. Auf diese Weise 

steht ein sehr sicherer Oneway-Übertragungskanal 

zur Verfügung, um das 

Recovery-Image vom zu schützenden 

System herunter zu bekommen. 

Im Übrigen ist das Design des Recovery-Images 

mit Passwörtern, privaten 

Schlüsseln und so weiter kein großes 

Geheimnis – vielleicht mit Ausnahme 

der Authentifizierung für kommerzielle 

Backup-Clients, die man aber etwa bei 

IBM Tivoli Storage Manager deaktivieren 

kann. So muss das Recovery-Image 

nicht besonders geschützt werden, 

sondern stellt lediglich die Integrität 

sicher. Ferner ist ReaR dank des modularen 

Designs sehr einfach erweiterbar. 

Im Übrigen kommt ReaR gut mit (U)EFI 

zurecht und unterstützt auch Itaniumund 

PowerPC-Systeme. 

Fazit 

Obwohl seit 2006 entwickelt, ist das 

außergewöhnliche Recovery-Tool vielen 

Admins unbekannt. Möglicherweise 

wird das Programm auch unterschätzt 

oder aufgrund der Tatsache, dass die 

Software aus Bash-Skripten basiert, 

nicht als professionell wahrgenommen. 

Dabei ist ReaR sehr professionell. Das 

gilt sowohl für den Code selbst als auch 

für das Projekt, das Ökosystem und den 

Entwicklungshintergrund. Die Realisierung 

über Bash-Skripte, die meist nicht 



ReaR 

45 

länger als eine Bildschirmseite sind, 

sorgt nebenbei auch für die einfache 

Handhabung. Der Rest spielt sich in 

den wenigen Konfigurationsdateien ab 

(siehe Tabelle 2). 

Dank gut gewählter Voreinstellungen 

ist die Konfiguration bei kleineren Projekten 

oder einzelnen Servern in der 

Tat sehr einfach und belohnt mit einem 

sehr hohen Automatisierungsgrad, 

erlaubt aber bei komplexen Szenarien 

auch das Einbeziehen sehr individueller 

Details. Offenbar finden aber auch 

Kenner der Software die zahlreichen 

Highlights der Software erst, wenn sie 

sich eingehender mit ReaR beschäftigen 

und sich mit der Funktionsweise 

auseinandersetzen. 

Das Besondere an ReaR liegt im modularen 

Design, der sehr einfachen 

Erweiterbarkeit und der Benutzerfreundlichkeit. 

Die Firma SEP hat ReaR 

sogar als Ersatz für das eigene Disaster- 

Recovery-Tool auserkoren und für die 

erforderliche SESAM-Unterstützung in 

ReaR gesorgt. Einzelheiten finden sich 

in der offiziellen Dokumentation zu 

SEP SESAM [8]. Damit ist SEP der erste 

kommerzielle Hersteller, der sich offen 

zu ReaR bekennt. (ofr) n 

n Tabelle 2: Dateien 

Datei/Verzeichnis 

/usr/sbin/rear 

/etc/rear/local.conf 

/etc/rear/site.conf 

/var/log/rear/ 

/tmp/rear 

/usr/share/rear 

/usr/share/rear/conf/default.conf 

Funktion 

Rear-Tool 

Systemspezifische Konfigurationsdatei 

Site-spezifische Konfigurationsdatei. Wird nicht per Default angelegt. Kann über andere Deployment-Tools oder 

aus anderen RPM-/Debian-Paketen bereitgestellt werden. 

Log-Dateien 

Temporäres Arbeitsverzeichnis. Muss nach einem Fehler manuell gelöscht werden. 

Alle Skript-Komponenten 

Kommentierte Standardkonfiguration mit sämtlichen verfügbaren Parametern, die der Admin nach Bedarf in 

»local.conf« oder »site.conf« kopieren kann. Hier finden sich unter anderem auch sämtliche »EXCLUDE«-Optionen 

zum exakten Festlegen des gewünschten Backup-Umfangs.

Lisa Young, 123RF 

Disaster-Recovery für Windows-Server 

Fensterreparatur 

Um Windows-Server zu reparieren, gibt es einige Möglichkeiten. Dieser Artikel geht sie durch und verrät 

auch, wie man Active Directory und Exchange wiederherstellt. Thomas Joos 

Startet ein Server nicht mehr, ist wohlüberlegtes, 

aber schnelles Handeln 

gefragt. Es gibt einige Möglichkeiten, 

Windows-Server schnell und einfach 

wieder zum Laufen zu bringen – oder 

auch vollends unbrauchbar zu machen. 

Generell ist es empfehlenswert, sich in 

Testumgebungen auf den Ernstfall vorzubereiten. 

Wer mit den Möglichkeiten 

vertraut ist, kann im Notfall den Server 

schneller wiederherstellen. 

Dieser Beitrag zeigt, wie Sie Probleme 

mit Windows beheben, wenn das Betriebssystem 

nicht mehr startet. Die 

Anleitungen sind mit Windows Server 

2012 R2 getestet, die meisten Einstellungen 

funktionieren auch in den Vorgängerversionen 

und mit Windows 7/8. 

Dabei erfahren Sie, wie Sie komplette 

Server wiederherstellen, virtualisierte 

Umgebungen auf Basis von Windows 

reparieren und auch Spezialdienste 

wie Active Directory wieder zum Laufen 

bekommen. 

Bootmanager versagt den 

Dienst 

Startet ein Server nicht mehr, kann 

die Ursache dafür auch ein defekter 

Bootmanager sein. Ihn können 

Sie reparieren, wenn Sie mit einer 

Windows-Server-DVD booten und die 

Computerreparaturoptionen aufrufen. 

In der Befehlszeile stehen verschiedene 

Möglichkeiten zur Verfügung, um einen 

defekten Bootmanager zu reaktivieren. 

Der Befehl »bootrec /fixmbr« schreibt 

den Master Boot Record neu an den Anfang 

der Festplatte. Mit »bootrec 

/scanos« lassen Sie die Betriebssysteme 

anzeigen, die aktuell nicht im 

Bootmanager eingetragen sind. Der 

Befehl »bootrec /rebuildbcd« trägt die 

gefundenen Systeme wieder in den 

Bootmanager ein. Mit »bootrec /fixboot« 

erstellen Sie den Bootmanager 

»Bootmgr« neu. 

Weitere Befehle, um den Bootmanager 

zu reparieren, sind »bootsect /nt60 

SYS« und »bootsect /nt60 ALL«. Die 

Befehle in diesem Abschnitt können 

Sie direkt hintereinander in die Befehlszeile 

eingeben. Natürlich ist das 

nur sinnvoll, wenn der Bootmanager 

nicht mehr funktioniert. Startet der 

Server, bricht dann aber ab, ist nicht 

der Bootmanager defekt, sondern das 

Betriebssystem. 

Windows bootet, startet aber 

nicht mehr 

Manchmal passiert es, dass Windows 

nach der Aktualisierung von Treibern 

nicht mehr korrekt funktioniert oder 

abstürzt. Das gilt für den Server wie für 

den Client. In manchen Fällen werden 



Windows retten 

47 

Systemdateien von Windows so zerstört, 

dass Windows zwar noch startet, 

aber dennoch Fehler erscheinen oder 

einige Funktionen nicht mehr richtig 

gestartet werden können. 

In diesem Fall können Sie entweder zu 

einem Systemwiederherstellungspunkt 

zurückgehen oder die Computerreparaturoptionen 

der Installations-DVD 

aufrufen. Wollen Sie Systemdateien 

im laufenden Betrieb reparieren, öffnen 

Sie eine Eingabeaufforderung mit 

Administratorrechten und rufen den 

Befehl »sfc /scannow« auf. Windows 

scannt wichtige Systemdateien und 

stellt sie wieder her, wenn Probleme 

auftreten. 

Arbeitsspeicher und 

Festplatten testen 

Windows-Rechner lösen Bluescreens 

aus, wenn Hardware im Rechner defekt 

ist, zum Beispiel der Arbeitsspeicher. 

Deshalb ist es empfehlenswert, vor 

einer Software-Reparatur den Speicher 

zu testen (Abbildung 1). Um die Ursache 

für Bluescreens herauszufinden, 

ist die Software BlueScreenView [1] 

hilfreich. Das Tool muss nicht installiert 

werden und lässt sich auch von einem 

USB-Stick aufrufen. 

Windows Server 2012 R2 ist standardmäßig 

so eingestellt, dass nach einem 

Bluescreen der Server automatisch 

neu startet. Erscheint der Bluescreen 

nach jedem Start, landet der Server in 

einer Schleife. Die möglichen Einstellungen, 

wie sich Windows nach einem 

Bluescreen verhalten soll, finden Sie 

unter »Systemsteuerung | System« 

und »Sicherheit | System | Erweiterte 

Systemeinstellungen«. Klicken Sie im 

Abschnitt »Starten und Wiederherstellen« 

auf die Schaltfläche »Einstellungen« 

(Abbildung 2). Zunächst sollten 

Sie die Option »Automatisch Neustart 

durchführen« deaktivieren. Über »Debuginformationen 

speichern« wählen 

Sie aus, welche Art von Informationen 

das Betriebssystem speichern soll. Am 

besten ist die Variante »Automatisches 

Speicherabbild« oder »Kleines Speicherabbild« 

geeignet. BlueScreenView 

analysiert die Datei »memory.dmp«, die 

Windows mit dem Bluescreens erzeugt. 

Vermuten Sie einen Fehler auf der 

Festplatte, zum Beispiel 

wegen klickender 

Geräusche und Einträgen 

in der Windows- 

Ereignisanzeige 

(»Windows‐Protokolle 

| System«), sollten Sie 

die Festplatte und das 

Dateisystem testen. 

Geben Sie in der Eingabeaufforderung 

mit 

Administratorrechten 

»chkdsk /f /r« ein. Weitergehende 

Tests von 

Festplatten nehmen 

zum Beispiel die kostenlosen Seatools 

von Seagate vor. Das Programm testet 

die meisten Festplatten auf Fehler, 

nicht nur die von Seagate hergestellten. 

Sie finden die Seatools und weitere 

Informationen zum Retten von 

Festplatten auf der Seite [2]. Western 

Digital bietet mit Data Lifeguard auf [3] 

ebenfalls ein solches Tool an, das auch 

als Windows-Anwendung zur Verfügung 

steht. Hitachi stellt seine Drive-Fitness- 

Tools als ISO-Datei auf der Seite [4] zur 

Verfügung. 

Kompletten Server 

wiederherstellen 

Um Windows Server 2012 R2 auf Basis 

einer vollständigen Sicherung wiederherzustellen, 

müssen Sie nicht auf 

Dritthersteller-Software setzen. Wenn 

Sie die Windows-Server-Sicherung 

über den Server-Manager installieren 

und den kompletten Server auf einen 

externen Datenträger sichern, können 

Sie diesen auf Basis dieser Sicherung 

vollständig wiederherstellen. 

Um die Windows-Server-Sicherung verwenden 

zu können, installieren Sie sie 

über den Server-Manager. In Windows 

Server 2012 R2 gibt es dazu das Feature 

»Windows Server‐Sicherung«. Nach der 

Installation starten Sie die Sicherung 

über das Menü »Tools« im Server-Manager 

mit »Windows Server‐Sicherung«. 

Alternativ können Sie auf der Startseite 

nach »wbadmin.msc« suchen. 

Das Progamm führt eine vollständige 

blockbasierte Sicherung der Datenträger 

durch. Microsoft empfiehlt zur 

Sicherung einen externen Datenträger, 

der durch das Sicherungsprogramm 

Abbildung 1: Vor einer Reparatur sollten Sie den Arbeitsspeicher eines 

Servers testen. 

automatisch formatiert wird, sodass 

alle bisher darauf gespeicherten Daten 

verloren gehen. Einen neuen Auftrag 

erstellen Sie über »Aktion | Sicherungszeitplan«. 

Bei der benutzerdefinierten 

Sicherung wählen Sie aus, welche 

Partitionen gesichert werden sollen 


Für Skripte oder Core-Server übernimmt 

das Befehlszeilentool »Wbadmin« 

die Verwaltung der Sicherungen. 

Die wichtigsten Funktionen sind: 

n »Wbadmin get versions« zeigt Informationen 

über die verfügbaren 

Sicherungen an. 

n »Wbadmin get status« zeigt den Status 

einer laufenden Sicherung oder 

Wiederherstellung an. 

Abbildung 2: Das Startverhalten von Windows bei 

Bluescreens können Sie in der Systemsteuerung 

festlegen. 


Admin 

Ausgabe 03-2014

48 



Abbildung 3: Mit der Datensicherung in Windows Server 2012 R2 können 

Sie einen Server vollständig sichern und auch wiederherstellen. 

n »Wbadmin start systemstaterecovery« 

stellt den Systemstatus wieder 

her. 

n »Wbadmin start sysrecovery/systemstatebackup« 

startet eine vollständige 

Systemsicherung, die in den 

Computerreparaturoptionen über 

die Installations-DVD von Windows 

Server 2012 R2 wiederhergestellt 

werden kann. 

n »wbadmin start backup ‐allCritical 

‐backuptarget:Zielfestplatte ‐quiet« – 

mit »‐quiet« muss die Eingabe nicht 

bestätigt werden – die Sicherung 

beginnt dann sofort. 

Mit dem folgenden Befehl werden alle 

hinterlegten Partitionen in die Sicherung 

eingeschlossen: 

wbadmin start backup ‐include:U 

Partition1:,...,PartitionN U 

‐backuptarget:Zielfestplatte: ‐quiet 

Die Partitionen werden durch Komma 

ohne Leerzeichen voneinander getrennt. 

Abbildung 4: Sie können einen Windows-Server auf 

Basis der Windows-Sicherung und der Installations- 

DVD vollständig wiederherstellen. 

Statt mit Wbadmin 

können Sie die Datensicherung 

auch in der 

Powershell steuern. 

Der Befehl »Get‐Command 

‐Module WindowsServerbackup« 

zeigt in Windows Server 

2012 R2 die passenden 

Commandlets an. 

Haben Sie auf dem 

Server eine vollständige 

Datensicherung 

erstellt, können Sie 

damit den kompletten 

Server wiederherstellen, 

falls dieser zum Beispiel nicht mehr 

starten kann. 

Dazu muss der Datenträger mit der 

Sicherung mit dem Server verbunden 

und dieser mit der Windows-Server- 

2012-R2-DVD gebootet werden. 

Auf der Startseite des Installations-Assistenten 

klicken Sie auf »Weiter«. Auf 

der nächsten Seite wählen Sie »Computerreparaturoptionen« 

aus. In den 

Systemwiederherstellungsoptionen 

wählen Sie die Option zur Wiederherstellung 

einer Systemabbildsicherung 

aus. Dazu klicken Sie auf »Problembehandlung« 

und »Systemimage‐Wiederherstellung« 


Bare-Metal-Restore auf neuer 

Hardware 

Windows Server 2008 R2 und Windows 

Server 2012/2012 R2 unterstützen die 

Wiederherstellung einer Systemsicherung 

auch auf anderer Hardware. Sie 

können im Assistenten auswählen, auf 

Basis welcher Sicherung Sie den Server 

wiederherstellen wollen. Wichtig ist 

dazu, dass Sie die Bare-Metal-Restore- 

Möglichkeit bei der Sicherung ausgewählt 

haben (Abbildung 5). 

Über »Datenträger ausschließen« wählen 

Sie die Datenträger aus, die nicht 

wiederhergestellt werden sollen, weil 

diese zum Beispiel Daten enthalten, 

aber keine Betriebssystemdateien. 

Mit »Treiber installieren« lassen sich 

wichtige Treiber integrieren, die für die 

Wiederherstellung benötigt werden. In 

den Optionen unter »Erweitert« legen 

Sie fest, dass der Server automatisch 

nach der Wiederherstellung neu starten 

und Datenträger auf Defekte überprüfen 

soll. 

Active Directory sichern und 

wiederherstellen 

Die Sicherung von Active Directory erfolgt 

zusammen mit der Sicherung von 

anderen wichtigen Systemkomponenten 

eines Servers. Bei dieser Sicherung, 

die auch durch das Windows-eigene 

Datensicherungsprogramm durchgeführt 

werden kann, werden alle Daten, 

die Active Directory benötigt, ebenfalls 

gesichert. Aktivieren Sie bei der Sicherung 

die Optionen »Systemstatus« und 

»System‐reserviert«, damit notwendige 

Daten zur Wiederherstellung von 

Active Directory mitgesichert werden. 

Auch die Bare-Metal-Daten sollten Sie 

sichern lassen. Um eine Wiederherstellung 

durchzuführen, starten Sie 

zunächst den Domänencontroller neu 

und drücken direkt nach dem Start die 

Taste [F8], bis das Bootmenü erscheint. 

Achten Sie aber darauf, dass sich die 

Datei, welche die Datensicherung enthält, 

lokal auf dem Server befindet, 

da sie zur Wiederherstellung benötigt 

wird. 

Wählen Sie in den Bootoptionen den 

Menüpunkt »Verzeichnisdienstwiederherstellung« 

aus; anschließend startet 

Windows. Melden Sie sich bei der 

Anmeldung mit dem Kennwort des Verzeichnisdienstwiederherstellungsmodus 

an. Nachdem Sie sich angemeldet 

haben, können Sie die Wiederherstellung 

durchführen. Es ist auch möglich, 

den Verzeichnisdienstwiederherstellungsmodus 

über eine RDP-Sitzung oder 

mit einem Befehl an der lokalen Konsole 

in der Befehlszeile zu aktivieren. 

Soll ein Domänencontroller beim 

nächsten Mal mit dem Verzeichnisdienstwiederstellungsmodus 

gestartet 

werden, geben Sie den Befehl »bcdedit 

/set safeboot dsrepair« ein. Befindet 

sich der Server im Verzeichnisdienstwiederherstellungsmodus, 

startet er 

mit dem Befehl »bcdedit /deletevalue 

safeboot« beim nächsten Mal wieder 

normal. So ersparen Sie sich das Drücken 

der Taste [F8], wenn Sie sich zum 

Beispiel nicht direkt an der Konsole 

befinden. Mit dem Befehl »shutdown t 0 

‐r« wird der Server dann im konfigurier- 




49 

ten Modus neu gestartet. Das Betriebssystem 

muss in der gleichen Version 

wie vor dem Ausfall installiert sein. 

Der Weg, einen Domänencontroller einfach 

neu in die Domäne aufzunehmen, 

statt eine Datensicherung zu verwenden, 

ist oft schneller und sauberer. Bereinigen 

Sie aber vor der erneuten Aufnahme 

in eine Domäne unbedingt die 

Metadaten von Active Directory, damit 

sichergestellt ist, dass keine veralteten 

Daten in Active Directory die erneute 

Heraufstufung des Domänencontrollers 

verhindern. 

Bereinigung von Active 

Directory 

Wird ein Domänencontroller aus Active 

Directory entfernt, sollten Sie einige 

Vorbereitungen treffen, damit die Anwender 

durch seinen Ausfall nicht betroffen 

sind. Stellen Sie sicher, dass der 

Domänencontroller nicht als bevorzugter 

oder alternativer DNS-Server von 

einem anderen Rechner der Domäne 

verwendet wird (auch nicht als DNS- 

Weiterleitungsserver). 

Entfernen Sie – falls möglich – vor der 

Herabstufung den DNS-Dienst von 

diesem Domänencontroller. Haben Sie 

DNS entfernt, überprüfen Sie auf einem 

anderen DNS-Server in den Eigenschaften 

der DNS-Zone, dass der Server auf 

der Registerkarte »Namenserver« nicht 

mehr aufgeführt wird. Entfernen Sie 

aber nicht den Hosteintrag des Servers, 

da er für die Herabstufung noch benötigt 

wird. 

Stellen Sie sicher, dass der Domänencontroller 

nicht an irgendeiner Stelle 

als Domänencontroller explizit eingetragen 

ist, zum Beispiel auf einem 

Linux-Server oder einem Exchange- 

Server. Entfernen Sie dann alle Active- 

Directory-abhängigen Dienste wie 

VPN, Zertifikatsstelle oder andere 

Programme, die nach der Herabstufung 

nicht mehr funktionieren werden. 

Verschieben Sie vor der Herabstufung 

zuerst alle FSMO-Rollen auf andere 

Server. 

Wenn es sich bei diesem Server um 

einen globalen Katalog handelt, konfigurieren 

Sie einen anderen Server als 

globalen Katalog und entfernen Sie im 

Snapin »Active Directory‐Standorte‐ 

und ‐Dienste« unter »Sites | Standort 

des Servers | Servername | Eigenschaften« 

der NTDS-Settings den Haken bei 

»Globaler Katalog«. 

Um einen Domänencontroller herunterzustufen, 

verwenden Sie am 

besten das Powershell-Commandlet 

»Uninstall‐ADDSDomainController« 

(Abbildung 6). Sie müssen mindestens 

noch das lokale Kennwort des Administrators 

über den Befehl festlegen. 

Dieses müssen Sie als Secure-String in 

der Powershell definieren. Die Syntax 

dazu lautet: 

Uninstall‐ADDSDomainController U 

‐LocalAdministratorPassword (Read‐HostU 

‐Prompt Kennwort ‐AsSecureString) 

Mit »Get‐Help Uninstall‐ADDSDomain- 

Controller« erhalten Sie mehr Informationen 

zu dem Befehl. 

Wenn Sie einen Domänencontroller, 

der die Verbindung mit dem Active Directory 

verloren hat, nicht neu installieren 

wollen, können Sie Active Directory 

trotz fehlender Verbindung entfernen. 

Verwenden Sie in diesem Fall zusätzlich 

die Option »‐force«. Die Metadaten von 

Active Directory enthalten alle Einträge 

und Servernamen, die zu Active Directory 

gehören. Wenn ein Domänencontroller 

ausfällt oder erzwungen aus dem 

Active Directory entfernt wird, sollten 

die Metadaten nachträglich bereinigt 

werden. 

Für diese Bereinigung benötigen Sie 

das Befehlszeilentool »Ntdsutil« (Abbildung 

7). Um die Metadaten von Active 

Directory zu bereinigen, starten Sie zunächst 

»Ntdsutil« in der Eingabeaufforderung 

und geben »metadata cleanup« 

ein, gefolgt von »connections«. Verbinden 

Sie sich per »connect to server 

Domänencontroller« mit dem Domain 

Controller und geben Sie »quit« ein, um 

wieder zum Menü »metadata cleanup« 

zurückzugelangen. 

Geben Sie »select operation target« und 

»list domains« ein, dann sehen Sie alle 

Abbildung 5: Im Assistenten zur Wiederherstellung 

wählen Sie den Sicherungssatz aus, auf dessen Basis 

die Sicherung den Server wiederherstellen soll. 

Domänen der Gesamtstruktur. Wählen 

Sie mit »select domain Nummer der Domäne« 

die Nummer der Domäne aus, 

von der Sie einen Domänencontroller 

entfernen wollen. Mit »list sites« erhalten 

Sie alle Standorte der Gesamtstruktur, 

von denen Sie einen mit »select site 

Nummer des Standorts« auswählen. 

Über »list servers in site« sehen Sie alle 

Domänencontroller, die diesem Standort 

zugeordnet sind. Der Befehl »select 

server Nummer des Servers« entfernt 

einen Server aus der Domäne. 

Geben Sie »quit« ein, um wieder zum 

Menü »metadata cleanup« zurückzukehren. 

Mit »remove selected server« 

wird der Server nach einer Bestätigung 

entfernt. 

Nachdem die Metadaten von Active 

Directory bereinigt wurden, sollten Sie 

noch die Einträge im DNS aufräumen. 

Entfernen Sie alle SRV-Records, in 

denen noch der alte Server steht, aus 

der DNS-Zone der Domäne. Danach 

können Sie das Computerkonto des 

Servers löschen. Löschen Sie das Konto 

aus der OU »Domain Controllers« im 

Snapin »Active Directory‐Benutzer und 

‐Computer«. 

Im nächsten Schritt müssen Sie den Domänencontroller 

noch aus dem Standort 

löschen, dem er zugeordnet war. 

Abbildung 6: Domänencontroller lassen sich auch in der Powershell herunterstufen. 


Admin 

Ausgabe 03-2014

50 



Abbildung 7: Funktioniert ein Domänencontroller nicht mehr, entfernen 

Sie ihn aus der Domäne und installieren ihn neu. Das geht meistens 

schneller als eine Wiederherstellung. 

Abbildung 8: Mit der Windows-Server-Sicherung können Sie auch 

Exchange-Datenbanken wiederherstellen. 

n Info 





[1] BlueScreenView: [http:// www. nirsoft. net/ 

utils/ blue_screen_view. html] 

[2] Seatools: [http:// www. seagate. com/ www/ 

de‐de/ support/ downloads/ seatools] 

[3] Data Lifeguard Diagnostic: [http:// support. 

wdc. com/ product/ download. asp? 

groupid=810& sid=3& lang=en] 

[4] Drive-Fitness-Tools: [http:// www. 

hgst. com/ support/ index‐files/ 

simpletech‐legacy‐downloads# DFT] 

Verwenden Sie dazu 

das Snapin »Active 

Directory‐Standorte 

und ‐Dienste«. Navigieren 

Sie zum Standort 

des Domänencontrollers, 

wählen Sie 

im zugehörigen Kontextmenü 

den Befehl 

»Löschen« aus oder 

drücken Sie die [Entf]- 

Taste. Überprüfen Sie 

als nächstes in den 

NTDS-Settings jedes 

Domänencontrollers in 

Active Directory, ob der 

Domänencon troller 

noch als Replikationspartner 

eingetragen 

ist, und entfernen Sie 

in diesem Fall die Verbindung. 

Reparieren der 

AD-Datenbank 

Unter manchen 

Umständen kann es 

vorkommen, dass 

die Active-Directory- 

Datenbank nicht mehr 

funktioniert. Bevor Sie 

einen Domänencontroller 

neu installieren, 

können Sie versuchen, die AD-Datenbank 

zu reparieren. Starten Sie dazu 

den Server im Verzeichnisdienstwiederherstellungsmodus 

und rufen Sie 

»Ntdsutil« auf. Geben Sie »activate instance 

ntds« ein, dann »files«; es startet 

die »file maintenance«. Dort geben Sie 

»integrity« ein und verlassen mit »quit« 

die »file maintenance«. 

Die Datenbankanalyse startet der 

Befehl »semantic database analysis«. 

Einen ausführlichen Report schaltet 

»verbose on« ein. Geben Sie »go fixup« 

ein, dann startet das Tool die Diagnose 

und repariert auf Wunsch die 

Datenbank. Verlassen Sie im Anschluss 

Ntdsutil und starten Sie den Domänencontroller 

neu. 

Exchange-Datensicherung 

Sichern Sie Exchange 2013 mit dem 

internen Sicherungs-Assistenten in 

Windows Server 2008 R2/2012, sichert 

das Programm auch die Exchange-Datenbanken. 

Das Sicherungsprogramm 

unterstützt auch die Onlinesicherung 

der Exchange-Datenbanken. Während 

der Sicherung führt das Sicherungsprogramm 

eine Konsistenzprüfung 

der Exchange-Dateien durch. Erst bei 

einer Wiederherstellung können Sie die 

Exchange-Datenbanken auswählen. 

Eine Wiederherstellung starten Sie im 

Sicherungsprogramm über das Menü 

»Aktion«. Auch hier führt ein Assistent 

durch die einzelnen Schritte der Wiederherstellung. 

Wählen Sie den lokalen 

Server für die Wiederherstellung aus. 

Während der Wiederherstellung hebt 

der Sicherungs-Assistent die Bereitstellung 

der Datenbank, die Sie wiederherstellen, 

selbstständig auf und stellt 

diese nach der Sicherung wieder bereit. 

Legen Sie das Datum sowie die Uhrzeit 

der wiederherzustellenden Sicherung 

fest und wählen Sie als »Wiederherstellungstyp« 

die Option »Anwendungen« 

aus (Abbildung 8). 

Auf der nächsten Seite muss bei »Anwendungen« 

die Option »Exchange« 

aufgelistet sein. Dann ist sichergestellt, 

dass eine Exchange-taugliche Sicherung 

vorhanden ist. Klicken Sie auf »Details 

anzeigen«, um sich die gesicherten 

Exchange-Datenbanken anzeigen zu 

lassen. 

Handelt es sich bei der Sicherung um 

die aktuelle Version der Sicherung, 

erscheint das Kontrollkästchen »Keine 

Rollforward‐Wiederherstellung der 

Anwendungsdatenbanken ausführen«. 

Für eine Rollforward-Wiederherstellung 

benötigen Sie Transaktionsprotokolle, 

die nach der Sicherung erstellt wurden. 

Diese schreibt Exchange anschließend 

in die Datenbank, um die Wiederherstellung 

zu vervollständigen. Aktivieren 

Sie die Option »Am ursprünglichen 

Speicherort wiederherstellen«, stellt 

das Sicherungsprogramm alle gesicherten 

Datenbanken am Ursprungsort 

wieder her. 

Nach der Wiederherstellung können 

Sie die Datendateien in eine Wiederherstellungsdatenbank 

integrieren und 

danach manuell wieder an ihren ursprünglichen 

Speicherort verschieben 

oder einzelne Daten aus der Sicherung 

herstellen. (ofr) n 


Dmitry Kalinovsky, 123RF 

Backup und Recovery bei Datenbanken: Woran man denken sollte 

Rettungsübung 

Datenbank-Backups sind mittlerweile Standard. Doch um nach einem Crash rasch wieder zu einem 

stabilen Produktivbetrieb zurückzukehren, muss das Disaster Recovery sorgfältig geplant und eingeübt 

sein. Sonst besteht die Gefahr, dass Wichtiges vergessen wird. Pierre Strohmeier 

n Autor 

Gerade in einer größeren Umgebung 

stellt die vollständige Wiederherstellung 

einer Datenbank oft eine Herausforderung 

dar, die zudem nicht wenig 

Zeit beansprucht. Die richtige Planung 

des Datenbank-Backups ist dabei ein 

wesentlicher Faktor, um Zeit zu sparen 

und die Kosten einer ungeplanten 

Peter Strohmeier arbeitet als Datenbankadministrator 

für PostgreSQL bei der 25th-floor de Pretis 

& Helmberger KG, einem seit 2004 existierenden 

Full-Service-Dienstleister für komplexe IT-Lösungen 

basierend auf Open-Source-Technologien mit Sitz in 

der österreichischen Hauptstadt Wien. 

Downtime zu minimieren. Unabhängig 

von der Hardware spielen die folgenden 

Fragen eine wichtige Rolle bei der 

Planung des Backups: 

n Wie stark belastet das Backup das 

System? 

n Wie lange dauert ein vollständiges 

Backup? 

n Wie groß darf der Datenverlust maximal 

sein (Recovery Point Objective 

– RPO)? 

n Wie lange dauert ein Recovery? Wie 

lange darf ein System oder Prozess 

stillstehen (Recovery Time Objective 

– RTO)? 

n Was muss neben Standard-Backups 

noch beachtet werden? 

n Wie validiere ich die Vollständigkeit 

und Funktionsweise nach der Wiederherstellung? 

n Wie sicher ist die gewählte Backup- 

Variante? 

Qual der Wahl 

Um Datenverlust und Systembelastung 

entgegenzuwirken, ist vor allem die 

richtige Wahl der Backup-Variante ausschlaggebend. 

Je nach Anwendungsfall 

muss man sich entscheiden, ob man 

physische oder logische Backups bevorzugt 

oder auch beides zeitgleich 

benutzen möchte. Grundlegend unterscheiden 

sich die beiden Varianten 

vor allem in der Größe und Dauer der 




53 

jeweiligen Backups. Gerade das ist 

meist ausschlaggebend dafür, wie viel 

I/O und Netzwerklast durch das Backup 

verursacht wird. 

Beim physischen Ansatz werden die 

Daten von den Platten blockweise auf 

ein Sicherungsmedium kopiert (Binary 

Backup). Diese Backup-Variante benötigt 

nicht zwangsweise eine Verbindung 

zur Datenbank und belastet das System 

anders als ein logisches Backup. 

Wichtig: Werden physische Backups 

bei laufender Datenbank angefertigt, 

sind sie zwangsläufig nicht konsistent. 

Um bei der Wiederherstellung zu einem 

konsistenten Stand zu gelangen, muss 

der Datenbank bekannt sein, welche 

Änderungen während und nach dem 

Backup angefallen sind. Diese Information 

speichern Datenbanken üblicherweise 

in Logdateien, die ebenfalls archiviert 

werden (Beispiele: PostgreSQL, 

SQLite – WAL (Write-Ahead-Log), Oracle 

– Redo Logs). Bei der Wiederherstellung 

werden die archivierten Logdateien 

eingespielt, wodurch letztendlich ein 

konsistenter Stand erreicht wird. Die 

Wiederherstellung kann auch nur bis zu 

einem bestimmten Zeitpunkt erfolgen 

(Point-In-Time-Recovery, PITR) – das ist 

vor allem bei Benutzerfehlern ein wichtiges 

Mittel, um Daten zu retten. 

Diese Möglichkeit ist oft auch die 

Grundlage für Standby-Datenbanken, 

die kontinuierlich im Recovery-Modus 

laufen und die anfallenden Logdateien 

immer wieder einlesen (Abbildung 1). 

Generell gilt: Umso mehr dieser Änderungen 

eingespielt werden müssen, 

desto länger dauert es, den gewünschten 

Datenstand zu erreichen. 

Logische Backups haben dagegen 

den Vorteil, dass damit auch partielle 

Backups möglich sind, bei denen zum 

Beispiel nur bestimmte Tabellen gesichert 

werden. Beim logischen Backup 

werden generell anstelle von Plattensektoren 

Datenbankobjekte mit ihrem 

Inhalt und relationalem Zusammenhang 

gesichert. Zudem werden im Gegensatz 

zu physischen Backups keine 

Indexdaten archiviert, sondern nur die 

Statements, die zum Anlegen der Indizes 

notwendig sind – was Backups zwar 

wesentlich kleiner macht, aber beim 

Wiederherstellen viel Zeit kostet. 

Abbildung 1: Standby-Datenbanken führen die Logs ihrer Master-Datenbank kontinuierlich nach. 

Bei Datenbanksystemen mit Multiversion 

Concurrency Control (MCC 

oder MVCC) kann sich im Laufe der Zeit 

unverwendeter Platz in der Datenbank 

ansammeln (Bloat oder Garbage genannt). 

Die Wiederherstellung größerer 

Datenbanken profitiert daher oftmals 

von logischen Backups, weil bei ihnen 

große Teile dieses unverwendeten 

Platz es nicht gesichert werden. Physische 

Backups, die genaue 1:1-Kopien 

des Originals sind, beziehen diesen 

Platz dagegen ein. 

Eine weitere Überlegung betrifft inkrementelle 

Backups. Man unterscheidet 

dabei zwischen differenziellen- und 

kumulativen Backups. Differenzielle 

Backups bauen seit dem letzten Voll- 

Backup beziehungsweise dem letzten 

differenziellen Backup aufeinander auf 

(Abbildung 2), wogegen kumulative 

Backups sämtliche Änderungen seit 

dem letzten Voll-Backup enthalten. 

Hierbei wird das Backup mit wachsendem 

Zeitabstand immer umfangreicher, 

allerdings braucht man dafür nur 

das jüngste aufzubewahren (Abbildung 

3). Inkrementelle Backups wirken sich 

auch wesentlich auf die Wiederherstellungsdauer 

aus, da man im Falle eines 

Crashs zuerst ein Voll-Backup und anschließend 

sämtliche inkrementellen 

Backups bis zum gewünschten Zeitpunkt 

einspielen muss. 

Jedes Datenbanksystem verfolgt beim 

Thema Backup unterschiedliche Ansätze. 

PostgreSQL [1] bringt beispielsweise 

erst ab Version 9.1.X das »pg_ 

basebackup«-Tool mit, das physische 

Backups und Replikation erleichtert, 

kennt jedoch noch keine Umsetzung 

von inkrementellen oder differenziellen 

Backups. Bei Oracle [2] hingegen kann 

man via RMAN (Oracles Recovery Manager) 

sowohl Voll-Backups als auch 

inkrementelle Backups ziehen. 

Replikation bei Datenbanken 

Um mehr Ausfallsicherheit zu erzielen, 

gibt es auch die Möglichkeit der 

kontinuierlichen (synchronen oder 

asynchronen) Datenbank-Replikation. 

Manche Systeme erlauben es, eine 

Standby-Datenbank etwa über die 

zuvor erwähnten Logdateien auf aktuellem 

Stand zu halten. Eine so aufgesetzte 

Standby-Datenbank befindet 

sich ununterbrochen im Wiederherstellungsmodus 

und versucht dauerhaft 

einlaufende Änderungen bei sich nachzuziehen. 

Hot-Standby-Instanzen können darüber 

hinaus verwendet werden, um 

lesende Prozesse (etwa ein Reporting 

oder wiederum Backups) auszulagern 

und somit I/O- und CPU-Last zu verteilen, 

sprich eine Art von Loadbalancing 

zu erreichen. 

Falls es zu einem Problem bei der 

Master-Instanz kommen sollte, kann 

man später die Standby-Datenbank 

zum Master ernennen (promoten) 

und erspart sich dadurch das erneute 

Aufsetzen einer Datenbank samt Wiederherstellung 

der Daten, woraus eine 

große Zeitersparnis resultieren kann. 

Allerdings besteht der nächste logische 

Schritt dann natürlich darin, wieder 


Admin 

Ausgabe 03-2014

54 



Änderungen 

Änderungen 

Tag 3 

Tag 2 

Tag 1 

Voll- 

Backup 

eine Standby-Instanz aufzusetzen, 

damit die neu ernannte Master-Instanz 

nicht die komplette Schreib- und Leselast 

verarbeiten muss. Daraus lässt sich 

ableiten, dass Standby-Systeme auch 

Hardware-seitig hierfür ausgelegt sein 

müssen, die komplette anfallende Systemlast 

zu schultern. 

Im Zuge eines Failovers müssen auch 

die eingehenden Verbindungen auf die 

mittlerweile als Master-Instanz betriebene 

ehemalige Standby-Datenbank 

umgeleitet werden. Dies kann sowohl 

via Cluster-Manager (etwa via Pacemaker 

[3] und Corosync [4]), aber auch 

mit Bordmitteln und/oder Middleware 

passieren. 

Im Falle eines versehentlich abgesetzten 

Statements – etwa eines UPDATE 

ohne WHERE-Klausel oder eines TRUN- 

CATE am falschen Host – kann es zu einer 

unangenehmen Situation kommen, 

wenn das Statement das Standby- 

System erreicht hat, bevor das Problem 

Tag 3 

Tag 2 

Tag 1 

Voll- 

Backup 

Differenzielle Backups 

differenziell 

T1 

Kumulative Backups 

kumulativ 

(T1) 

differenziell 

T2 

differenziell 

T1 

erkannt wurde. In diesem Fall würde 

der Fehler die Daten auf beiden Seiten 

korrumpieren. Aus diesem Grund kann 

es sinnvoll sein, eine zeitlich versetzte 

Standby-Datenbank zu verwenden, die 

Änderungen erst nach einer bestimmten 

Zeit verarbeitet. 

Vor allem synchrone Replikation kann 

das System aber auch schwer belasten. 

Auf der Netzwerkseite kann das 

Replizieren der Datenbankänderungen 

einen beachtlichen Teil der verfügbaren 

Bandbreite beanspruchen. Die Belastung 

kann hier sehr variieren, je nachdem 

wie viel in die Datenbank geschrieben 

wird. Auch die Query-Performance 

kann darunter leiden, wenn nach 

jedem COMMIT gewartet werden muss, 

bis alle Standby-Instanzen die Änderungen 

bei sich nachgezogen haben 

und auf einem synchronen Stand sind. 

Dies ist zwar bei asynchronen Setups 

nicht der Fall, jedoch sollte man bedenken, 

dass dort die Standby-Datenbank 

kumulativ 

(T1+T2) 

differenziell 

T3 

differenziell 

T2 

differenziell 

T1 

kumulativ 

(T1+T2+T3) 

differenziell 

T3 

differenziell 

T2 

differenziell 

T1 

Voll- 

Backup 

Daten Tag 1 Tag 2 Tag 3 Recovery 

Abbildung 2: Das Prinzip differenzieller Backups: Beim Recovery muss man alle Vorläufer in richtiger 

Reihenfolge einspielen. Dafür bleibt jedes Backup klein. 

kumulativ 

(T1+T2+T3) 

Voll- 

Backup 

Daten Tag 1 Tag 2 Tag 3 Recovery 

Abbildung 3: So funktionieren kumulative Backups: Sie wachsen stetig, dafür braucht man immer 

nur das Letzte. 

gegebenenfalls keinen aktuellen Datenstand 

bereitstellt und zeitlich zurückliegt. 

Das wiederum kann auf Seiten 

der Applikation zu Ungereimtheiten 

und Problemen führen. 

Oracle bietet hier als Feature den 

Oracle RAC (Oracle Real Application 

Cluster [5]), der sowohl Connection 

Pooling und Failover als auch Loadbalancing 

im Cluster-Umfeld ermöglicht. 

Oracle Active Data Guard [6] ist ebenso 

weit verbreitet. 

Bei PostgreSQL kann man ein physisches 

Backup unter anderem via »pg_ 

basebackup« (ab Version 9.1.X) herstellen 

und auch eine Standby-Datenbank 

sowie eine Streaming-Replication 

damit einrichten [7]. Mit einer Middleware 

wie PgBouncer [8] oder Pgpool- 

II [9] ist auch Connection Pooling/ 

Failover möglich. Für Multimaster- und 

Multislave-Systeme können hier Tools 

wie Bucardo [10] oder Postgres-XC [11] 

verwendet werden. MySQL bietet unter 

anderem im Enterprise-Umfeld MySQL- 

Replication [12] als auch MySQL-Cluster 

[13]. Eine Alternative wäre hier der 

Tungsten Replicator [14]. Zudem kann 

man auch auf Percona und deren Percona 

XtraDB Cluster (Dropin-Re placement 

zu InnoDB/MySQL [15]) samt 

Percona XtraBackup ausweichen. 

Backup everything? 

Unabhängig von der gewählten 

Backup-Variante sollte man sich vergewissern, 

was alles notwendig ist, um 

nach einem Crash mit möglichst geringem 

Datenverlust in möglichst kurzer 

Zeit wieder in Produktion gehen zu 

können. In Standard-Backups von Datenbanken 

muss nicht zwingend alles 

Notwendige für eine komplette Wiederherstellung 

enthalten sein! 

Bei PostgreSQL landen beispielsweise 

Konfigurationsdateien wie »postgresql. 

conf« (Hauptkonfiguration), »pg_hba. 

conf« und »pg_ident.conf« (Client- 

Authentifizierung), die relevant für das 

Datenbanksystem sind, weder in logischen 

noch automatisch in physischen 

Backups. Bei physischen Backups 

hängt es davon ab, ob die Dateien im 

Basis-Verzeichnis liegen, was wiederum 

abhängig davon ist, wie PostgreSQL 

installiert wurde. 




55 

Betreibt man sowohl Produktions- als 

auch Entwicklungsumgebungen im 

gleichen Cluster, liegt es durchaus 

nahe, den klassischen Ansatz zu verfolgen 

und Backups via »pg_dump« zu 

ziehen, um nur den Produktionsstand 

zu sichern und um das Backup nicht 

unnötig zu vergrößern. 

Unvollständige Sicherung 

Im Falle eines Crashs kann dann jedoch 

leicht Wichtiges vergessen oder 

nicht bedacht werden. Etwa, dass 

»pg_dump« keine globalen Objekte 

sichert (Rollen/User, Dictionaries und 

so weiter). Generell werden in so einem 

Backup nur datenbankbezogene 

Elemente gespeichert, aber einige im 

Backup enthaltene Teile könnten auf 

globale Elemente zugreifen wollen, die 

im Recovery fehlen (Shared Objects, 

Extensions und so weiter). 

Um solche Fälle auszuschließen, sollte 

man im Vorhinein einige Vorkehrungen 

treffen. Mit pg_dumpall [16] und der 

Option »‐‐globals‐only« lassen sich 

Rollen und User sichern. Die resultierende 

Datei muss eigens gespeichert 

werden. Generell muss man sich auf 

die Gegebenheiten des verwendeten 

Datenbanksystems einstellen, Oracle 

unterscheidet sich diesbezüglich sehr 

von PostgreSQL und MySQL. 

Man sollte sichergehen, dass sämtliche 

in den Konfigurationsdateien definierte 

Pfade im Recovery-System vorhanden 

sind und/oder entsprechende Anpassungen 

treffen. Denn es kann schnell zu 

schwerwiegenden Problemen führen, 

wenn etwa Tablespaces nicht verwendet 

oder angelegt werden können. 

Auch nicht gesetzte Kernel-Parameter 

sind oft der Grund dafür, warum sich 

eine Datenbank nach dem Recovery 

nicht starten lässt. Möglicherweise 

steht dadurch dann zum Beispiel zu 

wenig Shared Memory zur Verfügung. 

Umständlich kann es auch werden, 

wenn die Datenbank in einem falschen 

oder unpassenden Locale/Encoding 

aufgesetzt wurde. 

Konfigurationsdateien, die nicht in den 

Backups enthalten sind, können mittels 

Tools wie »svn«, »git« und »etckeeper« 

[17] versioniert werden. Dadurch lassen 

sich zwei Fliegen mit einer Klappe 

schlagen, denn die Dateien werden 

nicht nur gesichert, sondern die Anpassungen 

können durch die Versionierung 

zeitlich verfolgt werden. 

Ein wichtiger Punkt ist auch, vergleichbare 

(oder im besten Fall: die gleiche) 

Hardware für das wiederhergestellte 

System zu verwenden. Die für das 

neue Datenbanksystem verwendete 

Software-Version sollte außerdem 

nicht allzusehr von der des Originals 

abweichen. Vor allem bei physischen 

Backups können unterschiedliche Datenbankversionen 

schnell zu Inkompatibilitäten 

führen. Verwendet man logische 

Backups, sollte sich zwar zwischen

56 



n Info 





[1] PostgreSQL: [http:// www. postgresql. org] 

[2] Oracle: [http:// www. oracle. com/ 

technetwork/ database/ features/ availability/ 

rman‐overview‐096633. html] 

[3] Pacemaker: [http:// clusterlabs. org] 

[4] Corosync: 

[http:// corosync. github. io/ corosync] 

[5] RAC: [http:// www. oracle. com/ us/ products/ 

database/ options/ real‐application‐clusters/ 

overview/ index. html] 

[6] Oracle Active Data Guard: 

[http:// www. oracle. com/ technetwork/ 

database/ features/ availability/ 

dataguardoverview‐083155. html] 

[7] PostgreSQL-HA: [http:// www. postgresql. org/ 

docs/ current/ static/ high‐availability. html] 

[8] PgBouncer: [http:// pgfoundry. org/ projects/ 

pgbouncer] 

[9] Pgpool-II: [http:// www. pgpool. net)] 

[10] Bucardo: [http:// bucardo. org/ wiki/ Bucardo] 

[11] Postgres-XC: [http:// sourceforge. net/ projects/ 

postgres‐xc] 

[12] MySQL-Replication: [http:// www. mysql. com/ 

products/ enterprise/ replication. html] 

[13] MySQL-Cluster: [http:// dev. mysql. com/ doc/ 

index‐cluster. html] 

[14] Tungsten Replicator: [https:// code. google. 

com/ p/ tungsten‐replicator/] 

[15] Percona XtraDB Cluster: [http:// www. percona. 

com/ software/ percona‐xtradb‐cluster] 

[16] Pg_dumpall: [http:// www. postgresql. org/ 

docs/ current/ static/ app‐pg‐dumpall. html] 

[17] Etckeeper: 

[https:// github. com/ joeyh/ etckeeper] 

[18] Oracle-Backup verifizieren: [http:// docs. oracle. 

com/ cd/ B28359_01/ backup. 111/ b28270/ 

rcmvalid. htm] 

[19] PgTAP: 

[http:// pgtap. org/ documentation. html] 

[20] Oracle-Ausführungspläne verwalten: 

[http:// docs. oracle. com/ cd/ B28359_01/ 

server. 111/ b28274/ optplanmgmt. htm] 

[21] Pg_statements: [http:// www. postgresql. org/ 

docs/ current/ static/ pgstatstatements. html] 

[22] Pg_stat_plans: [https:// github. com/ 

2ndQuadrant/ pg_stat_plans] 

Minor-Upgrades nichts Grundlegendes 

ändern, aber vor einem Umstieg auf 

die nächste Major-Version, sollte man 

(gerade im Falle von Disaster Recovery) 

kein Risiko eingehen. Zumindest muss 

der Umstieg zuvor ausführlich getestet 

worden ein. 

Recovern üben 

Um wirklich auf Nummer sicher zu 

gehen, sollte (zumindest einmal) ein 

komplettes Disaster Recovery mit dem 

Aufsetzen der Datenbank übungshalber 

geplant, durchgespielt und dokumentiert 

werden. Schließlich ist nichts 

unangenehmer, als erst im Ernstfall 

festzustellen, dass doch nicht alles 

Notwendige bedacht wurde und man 

nun entweder vor einem inkonsistenten 

oder neuen Datenbank-Setup 

steht oder es gar nicht erst zum Laufen 

bekommt. Regelmäßige Übungen und 

Testläufe helfen hier sehr! 

Mit Letzteren testet man gleichzeitig 

Backups: Fehlen Inhalte? Sind womöglich 

Blöcke defekt? Oracle bietet 

in diesem Kontext zur Überprüfung 

von Backups auf defekte Blöcke oder 

fehlende Dateien etliche Optionen via 

Oracle RMAN [18]. 

Nach einer erfolgreichen Inbetriebnahme 

des Datenbanksystems samt 

Wiederherstellung der Daten steht immer 

noch die Frage im Raum, ob alles 

wieder normal läuft und voll funktionsfähig 

ist. Gerade das ist meist gar nicht 

so einfach zu beantworten … 

Monitoring hilft 

Erste Ansätze bietet ein genaues I/Ound 

CPU-Load-Monitoring des Servers, 

wobei man hier die aktuellen Werte mit 

den Werten des zuvor vorhandenen 

Setups vergleichen sollte. Bestenfalls 

kann man sogar auf ein Test-Setup zurückgreifen, 

das produktionsnahe Situationen 

simulieren oder reproduzieren 

kann. Auch Unit-Tests der Applikationen, 

die die Datenbank verwenden, 

und Tools zum Testen der Datenbank 

an sich – wie PgTAP [19] – sind oft sehr 

wertvoll, sofern sie gefahrlos auf ein 

Produktionssystem angewendet werden 

können. Automatisiertes Monitoring 

der Datenbanklogs (wie des Oracle 

Alert Log) sollte man generell nutzen 

und natürlich gerade in solchen Situationen 

genau beachten. 

Zudem empfiehlt es sich unbedingt, 

nach jeder Wiederherstellung auch 

interne Statistiken der Datenbank zu 

überprüfen und gegebenenfalls zu 

aktualisieren. Sie werden oft für Query- 

Planer verwendet, um den effizientesten 

Weg für die Ausführung eines Statements 

zu kalkulieren. Via PL/PGSQL- 

Packages bei Oracle (»DBMS_STATS«) 

oder etwa »ANALYZE« bei PostgreSQL 

lassen sich interne Informationen zu 

Tabellen und Indizes neu sammeln und 

Statistiken auf den neuesten Stand 

bringen. 

Zusätzlich zu Query-Plänen sollten 

auch durchschnittliche Query-Laufzeiten 

genauer unter die Lupe genommen 

werden (»EXPLAIN«, »EXPLAIN PLAN« 

und ähnliche Kommandos), denn es 

könnte durchaus der Fall sein, dass 

sich hier etwas geändert hat. Verliert 

beispielsweise ein Index oder eine Tabelle 

nach dem Wiederherstellen etwas 

an Größe (Bloat), so kann es durchaus 

sein, dass der Query-Planer einen anderen 

Weg vorschlägt und lieber einen 

anderen Index in Betracht zieht oder 

sogar dazu tendiert, stattdessen gleich 

die gesamte Tabelle zu lesen. Das kann 

sich gravierend auf die Laufzeiten auswirken. 

Je komplexer die Query, umso 

eher kann sich die Ausführung ändern. 

Datenbank-Tools, die Statistiken über 

Query-Laufzeiten und/oder ‐Pläne 

führen, können hierbei sehr hilfreich 

sein. Bei manchen Datenbanken sind 

sie von Haus aus integriert. Oracle 

bietet beispielsweisde diverse Tools, 

um SQL-Pläne zu managen [20]. Auch 

PostgreSQL liefert zusätzliche Informationen 

über Query-Laufzeiten (»pg_ 

stat_statements« [21]) und ‐Pläne [22] 

via Extensions. Letztendlich darf man 

auch nicht vergessen, dass neu aufgesetzte 

Systeme eine gewisse Anlaufzeit 

brauchen, um wieder warm zu werden. 

So kann es durchaus etwas dauern, 

bis alle heißen Daten wieder im RAM 

gelandet sind. 

Zusammenfassend lässt sich nur sagen: 

Umso öfter Backups wiederhergestellt 

und getestet werden, desto kleiner ist 

das Risiko einer ungeplanten Downtime. 

(jcb) n 


58 

Know-how 

Neutron 

OpenStack Neutron als Beispiel für eine SDN-Implementierung 

Maschen knüpfen 

Im Fahrwasser der Cloud bahnen sich Technologien wie OpenFlow und Open vSwitch den Weg zu einer 

breiten Nutzerbasis. OpenStack Neutron zeigt, wie brauchbares SDN aussehen kann. Martin Loschwitz 

Wer sich in den letzten Monaten mit 

der IT-Szene beschäftigt hat, der trifft 

neben der allgegenwärtigen Wolke 

immer häufiger auch auf andere Themen, 

die quasi im Rahmen der Cloud 

groß werden. Eines davon ist Software 

Defined Networking, kurz SDN. Hinter 

diesem etwas sperrigen Begriff verbirgt 

sich eine relativ simple Idee: Statische 

Netzwerkkonfigurationen, wie sie in 

IT-Setups typischerweise zur Anwendung 

kommen, funktionieren in Clouds 

mehr schlecht als recht, verhindern 

manchmal sogar, dass sich die Cloud- 

Software effektiv nutzen lässt. Indem 

die gesamte Netzwerkkonfiguration 

per Software definiert wird, lassen sich 

Einschränkungen umgehen, die aus 

der Verknüpfung der Konfiguration mit 

physischen Geräten herrühren. SDN ist 

derweil nicht die einzige Technik, bei 

der Software Hardware ablöst: Auch 

das Software Defined Storage ist derzeit 

im Aufwind. 

Implizite Netzwerk- 

Annahmen 

Um die Motivation hinter Software 

Defined Networking gerade im Kontext 

von OpenStack oder jeder anderen 

Cloud-Umgebung zu verstehen, hält 

man sich zuerst vor Augen, welche 

impliziten Annahmen im Hinblick auf 

IT-Netzwerke meist von vornherein 

vorhanden sind. Drei Faktoren spielen 

eine Rolle: 

n Klassische Netzwerke müssen nicht 

besonders gut in die Breite skalieren 

– oft haben sogar einzelne Kunden 

ihre eigenen Switche, auch wenn sie 

diese selbst nicht wirklich auslasten 

können. 

n Klassische Netzwerke unterliegen 

einer zentralen Verwaltung: der Anbieter 

nimmt auf Zuruf des Kunden 

spezifische Konfigurationsänderungen 

vor, sodass der Kunde das nicht 

selbst machen muss. 

n Klassische Netzwerke sind in der 

Entwicklung ihrer Größe und des 

generierten Traffics vorhersagbar, 

sodass eine langfristige Planung 

möglich ist. 

Zusammen haben diese drei Annahmen 

zu typischen Netzwerk-Designs 

in der IT geführt. Einzelne Kunden 

haben entweder ihren eigenen Switch 

oder sind – zur Gewährleistung von 

Sicherheit – in einem separaten VLAN 

am Switch untergebracht. Mehrere vorhandene 

Switche sind gegebenenfalls 

sternförmig konfiguriert, die zentrale 

Verwaltung erfolgt durch den Anbieter, 

wobei die Planung der einzelnen Netzwerktopologien 

durchaus den jeweiligen 

Kunden überlassen sein kann. 

Reality-Check 

Für Clouds funktioniert keine der drei 

Annahmen. Das geht schon damit los, 

dass in einer Cloud alle Hypervisor- 

Hosts zwangsläufig gleichberechtigt 

sein sollten, damit jeder Hypervisor- 

Host die VMs jedes Kunden betreiben 

kann; ein solches System macht auch 

VLANs sehr unkomfortabel. Überdies 

wollen Anbieter durch die Installation 

einer Cloud-Software dafür 

sorgen, dass Kunden 

sich in Form eines 

Service- 

Portals selbst die Dienste buchen 

können, die sie brauchen. Ein neuer 

Kunde muss also in der Lage sein, sich 

anzumelden und sofort in der eigenen 

Netzwerkumgebung VMs zu starten, 

ohne dass dafür das Eingreifen eines 

Admins notwendig ist. Diese Anforderung 

kegelt VLANs endgültig aus dem 

Spiel. Schließlich ist die Entwicklung 

von Cloud-Netzwerken praktisch kaum 

sinnvoll vorhersagbar. Denn ein neuer 

Kunde, der etliche Terabyte Traffic pro 

Monat produziert, kann sich jederzeit 

anmelden, ohne das vorher anzukündigen 

– der Cloud-Anbieter tut gut daran, 

auf solche Szenarien vorbereitet zu 

sein. 

SDN zur Hilfe 

Die Motivation hinter dem Einsatz von 

Software Defined Networking ist für 

die meisten Unternehmen, dass sich 

mit SDN-Umgebungen die genannten 

Nachteile klassischer Netzwerke um- 

Evgeniya Uvarova, 1123RF

Know-how 

Neutron 

59 

gehen lassen. Das wichtigste Wort im 

SDN-Kontext ist Entkopplung: Komponenten 

der Netzwerk-Infrastruktur – besonders 

die Switche – verlieren dabei 

alle Management-Aufgaben. 

Praktisch betrifft das vor allem VLANs: 

Switche nutzen keine VLANs mehr, sondern 

werden zu bloßen Packet-Forwardern 

ohne spezifische Zusatzaufgabe. 

Aus der Sicht des Switches befinden 

sich alle angeschlossenen Hypervisor- 

Hosts auf der gleichen Ebene, etwaige 

Sicherheitsvorkehrungen wickelt die 

SDN-Software selbst ab. Auch ist die 

SDN-Implementierung verantwortlich 

dafür, die Netzwerktopologien der in 

der Cloud vorhandenen Nutzer voneinander 

zu trennen und den Nutzern 

zugleich die Möglichkeit zu geben, ihre 

Netzwerke selbst zu verwalten. Grundlage 

für dieses System ist freilich, dass 

die SDN-Technologie sowie die verwendete 

Cloud-Umgebung grundsätzlich 

eng miteinander verbunden und integriert 

sind. 

Ein vorzügliches Beispiel für diese 

Art der Implementierung ist Neutron, 

die zentrale SDN-Komponente von 

OpenStack. Neutron kümmert sich 

im OpenStack-Kontext um alles, was 

irgendwie mit Netzwerken zu tun hat, 

also um die Netzwerktopologien einzelner 

Cloud-Kunden genauso wie um die 

Verbindung der VMs untereinander im 

Hintergrund. Auch DHCP- und Routing- 

Dienste fallen in den Aufgabenbereich 

der Netzwerkkomponente. Schon aus 

dieser Beschreibung ist ersichtlich, 

dass Neutron sehr komplex ist und 

nicht zufällig ist Neutron auch jene 

Komponente, die für künftige Open- 

Stack-Admins mit Abstand am schwersten 

zu durchblicken ist. 

Der Neutron-Server 

Grundsätzlich ist Neutron modular aufgebaut 

und das in mehrfacher Hinsicht. 

Den Anfang macht der Neutron-Server: 

Er ist quasi das Hirn der Lösung und im 

Hintergrund dafür verantwortlich, die 

Netzwerkkonfiguration zu speichern. 

Er ist auch die erste Anlaufstelle für 

alle anderen Neutron-Komponenten 

auf den anderen Hosts innerhalb der 

Cloud – wollen diese eine Ãnderung 

am Netzwerk vornehmen, so geht das 

nur durch den Neutron-Server. Für sich 

genommen ist die Komponente freilich 

nutzlos, denn ohne eine spezifische 

Netzwerktechnologie erfüllt sie keinen 

Zweck. 

An dieser Stelle kommen die Plugins 

ins Spiel, die sich im Neutron-Server 

laden lassen (Abbildung 1). Ein Plugin 

erweitert den Neutron-Server um die 

Fähigkeit, ganz konkrete Handlungsanweisungen 

für eine spezifische SDN- 

Technologie zu erzeugen. Das Plugin ist 

auch der Teil des Neutron-Servers, der 

die spezifischen Einträge für die Netzwerkkonfiguration 

im Hintergrund in 

einer Datenbank anlegt. 

Standardmäßig setzt Neutron auf 

Open vSwitch, aber es existieren viele 

Plugins für andere SDN-Technologien, 

beispielsweise für VMWares NXS [1] – 

eine Liste von unterstützten Plugins 

findet sich unter [2]. Aktuelle Neutron- 

Versionen erlauben es sogar, über das 

sogenannte Multi-Layer-Framework 

mehrere Plugins zur gleichen Zeit zu 

betreiben. Das Plugin läuft zusammen 

mit dem Server in der Regel auf dem 

Host, der innerhalb der Cloud als 

»Cloud-Controller« designiert ist. 

Den Cloud-Controller zeichnet eine 

spezifische Eigenschaft aus: Er selbst 

betreibt keine virtuellen Maschinen, 

sondern ist nur eine Instanz, die alle 

anderen Cloud-Rechner steuert und 

kontrolliert. Das stellt das System vor 

ein simples Problem: Wie kommen 

Netzwerkanweisungen vom Cloud- 

Controller auf die Knoten innerhalb der 

Wolke, damit sie dort wie gewünscht 

funktionieren? 

Die Neutron-Agents 

Dafür zeichnen die Neutron-Agents 

verantwortlich. Konkret lassen sich drei 

Problemfelder ausmachen: 

n Die Kommunikation einzelner VMs 

untereinander muss sicher funktionieren. 

Weil in OpenStack grundsätzlich 

jede VM jedes Kunden auf 

jedem Host laufen können muss, 

VLANs aber nicht zum Einsatz kommen, 

muss es für VM1 von Kunde 1 

am Host A einen Weg geben, mit der 

VM2 auf Host B sicher zu reden. 

n Die Kommunikation einzelner VMs 

mit der Außenwelt, vorrangig dem 

Internet: Auch hier muss sichergestellt 

sein, dass die VMs der Kunden 

voneinander völlig abgeschottet 

sind. 

n Das DHCP-Problem: Weil jeder 

Kunde sich grundsätzlich seine 

Netze selbst nach eigenem Gutdünken 

definieren kann, muss es eine 

zentrale Instanz geben, die jede 

Kunden-VM mit einer spezifischen 

DHCP-IP ausstattet. 

Für jedes der drei Probleme gibt es in 

OpenStack einen sogenannten Agent. 

Agents sind grundsätzlich die Gegenstücke 

zu Plugins: Sie laufen auf den 

Hosts innerhalb der Cloud und setzen 

dort Netzwerkbefehle so um, wie das 

Plugin im Neutron-Server es vorgibt. 

Neutron unterscheidet dabei zwischen 

Agents, die im Hinblick auf ein Plugin 

spezifisch sind – beispielsweise den 

Open-vSwitch-Agent – und generischen 

Abbildung 1: Der Neutron-Server lädt ein 

Plugin, das verantwortlich dafür ist, die 

Datenbank im Hintergrund zu verwalten – 

verräterische Spuren von OVS finden sich 

im Beispiel (Open vSwitch). 


Admin 

Ausgabe 03-2014

60 

Know-how 

Neutron 

Abbildung 2: Der Lohn der Arbeit: Auf einem Hypervisor-Knoten ist der GRE-Tunnel gut zu erkennen, 

der zum Netzwerkknoten hinführt. 

Agents, die mit allen Neutron-Plugins 

funktionieren. Der Plugin-spezifische 

Agent läuft in der Regel auf jedem Host 

mit Ausnahme des Cloud-Controllers, 

während die generischen Agents meist 

nur auf einigen ausgewählten Hosts 

arbeiten. 

Im konkreten Beispiel von Open 

vSwitch ist das genau so: Der Neutron- 

Open-vSwitch-Agent läuft auf allen 

Hypervisor-Hosts – und zudem auf 

n Listing 1: Tenant-spezifische Netzwerke in Neutron 

dem Netzwerkknoten, den fast alle 

OpenStack-Konzepte derzeit vorsehen. 

Er hat eine maßgebliche Aufgabe: Zwischen 

den einzelnen Hosts baut er GRE- 

Tunnel im Stil eines MESH-Netzwerkes 

auf. Spezifische VMs werden mit virtuellen 

Netzwerkkarten gestartet, die (über 

Umwege) in diese GRE-Tunnel durchgeleitet 

werden. Open vSwitch kümmert 

sich um die Sicherheit: Vereinfacht 

ausgedrückt sind jene GRE-Tunnel die 

01 root@alice:~# neutron net‐list 

02 +‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+ 

03 | id | name | subnets 

04 +‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+ 

05 | 1f0da5f2‐e356‐47e2‐a1b8‐dd22d262487c | ext‐net | 

06 19971fb7‐32ce‐4b0e‐906c‐b68e3658741d 192.168.144.0/24 | 

07 | b08bb789‐7d7c‐4b92‐9f34‐33dafd73d5e9 | admin‐net | 

08 ebf41bb0‐9611‐4d3e‐9d2a‐63d18506fb51 10.5.5.0/24 | 

09 +‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+ 

10 root@alice:~# neutron net‐show admin‐net 

11 +‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+ 

12 | Field | Value | 

13 +‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+ 

14 | admin_state_up | True | 

15 | id | b08bb789‐7d7c‐4b92‐9f34‐33dafd73d5e9 | 

16 | name | admin‐net | 

17 | provider:network_type | gre | 

18 | provider:physical_network | | 

19 | provider:segmentation_id | 1 | 

20 | router:external | False | 

21 | shared | False | 

22 | status | ACTIVE | 

23 | subnets | ebf41bb0‐9611‐4d3e‐9d2a‐63d18506fb51 | 

24 | tenant_id | 013a0318db1f44fd81f315e8b943acbd | 

25 +‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+ 

virtuellen Switche und die NICs der VMs 

die dazugehörigen Ports. 

Open vSwitch selbst ist bekanntlich 

im Wesentlichen ein Frontend für 

OpenFlow, und über OpenFlow-Tags 

sorgt Neutron qua Open vSwitch dafür, 

dass eine Trennung von Paketen auf 

Kundenebene stattfindet. Was über die 

Netzwerkkarte der VM1 vom Kunden 1 

auf Host A in den GRE-Tunnel geht, ist 

also mit einem Tag versehen, das nur 

entsprechend getaggte Interfaces auf 

anderen Hypervisor-Hosts ebenfalls 

zu Gesicht bekommen (Abbildung 2). 

Anhand des OSI-Layer-Modells wird 

deutlich, dass hier im Grunde ein virtueller 

Layer 2 in einem physischen Layer 

3 gebaut wird. Die Plugin-spezifischen 

Agents heißen in OpenStack deshalb 

oft auch L2-Agents. 

Zu den L2-Agents gesellt sich der DHCP- 

Agent zusammen mit dem L3-Agent. 

Wie bereits erwähnt ist es mittlerweile 

durchaus üblich, einen separaten 

Knoten für die Netzwerkdienste einer 

OpenStack-Cloud abzustellen; der 

Netzwerkknoten hat die Aufgabe, sämtliche 

VMs mit der Außenwelt zu verbinden 

und auch dafür zu sorgen, dass neu 

gestartete VMs eine passende IP per 

DHCP erhalten. Darum kümmern sich 

die beiden genannten Agents. 

Der Netzwerkknoten 

Doch wie funktioniert diese Technik genau 

und welche Komponenten sorgen 

auf dem Netzwerkknoten für die reibungslose 

Funktion? Soviel vorab: Ein 

L2-Agent läuft selbstverständlich auch 

auf dem Netzwerkknoten. Denn damit 

VMs über den Netzwerkknoten mit der 

Außenwelt kommunizieren können, 

gelten natürlich die gleichen Bedingungen 

wie für die Kommunikation der VMs 

untereinander. Über den Draht zu den 

Hypervisor-Systemen wandern auch 

die DHCP-Antworten: Für jedes Tenant- 

Netzwerk startet der DHCP-Agent auf 

dem Netzwerkknoten eine Instanz von 

»dnsmasq« [3] mit einer entsprechend 

präparierten Konfiguration. Weil User 

beim Starten einer VM festlegen müssen, 

mit welchem virtuellen Netz die 

VM verbunden sein soll, landet ein 

DHCP-Request von einer VM über den 

GRE-Tunnel zwischen dem Hypervisor- 


Know-how 

Neutron 

61 

Abbildung 3: Network Namespaces haben eine eigenständige Netzwerkkonfiguration; die System- 

NICs sehen sie nicht. 

Host und dem Netzwerkknoten beim 

passenden »dnsmasq« und bekommt 

eine entsprechende Antwort. Ganz ähnlich 

funktioniert auch der Ablauf bei der 

sogenannten Layer-3-Kommunikation, 

also mit der Außenwelt. 

Was in der Theorie simpel klingt, hat in 

der Praxis allerdings einen gewaltigen 

Pferdefuß. Damit Kunden wirklich ihre 

Netzwerktopologien selbst festlegen 

können, anstatt auf eine zentrale 

Verwaltung angewiesen zu sein, ist 

es zwingend notwendig, dass jeder 

Kunde grundsätzlich jedes Netz nutzen 

kann. Kunde 1 muss also das Netz 

192.168.0.0/24 genauso nutzen können 

wie Kunde 2. Solange Netzwerk-Traffic 

nur zwischen den Hypervisor-Hosts 

passiert, ist das – den OpenFlow-Tags 

sei Dank – auch kein größeres Problem. 

Auf dem Knoten, der für das Netzwerk 

verantwortlich zeichnet, entsteht jedoch 

ein großes Problem: Wenn aus 

zwei unterschiedlichen GRE-Tunneln 

Pakete aus dem genannten Netzwerk 

ankommen, die beide über die gleiche 

externe Netzwerkkarte an die Außenwelt 

verschickt werden sollen, muss 

der Netzwerkknoten die Pakete trennen 

können. Der Open-vSwitch-Agent 

in OpenStack Neutron setzt dafür auf 

Namespaces (Abbildung 3). 

Namespaces sind eine Kernel-Funktion, 

die in unterschiedlichen Varianten 

daherkommt; innerhalb eines Namespaces 

sind Prozesse „eingesperrt“, 

sehen den Rest des Systems also 

nicht. Im Grunde sind sie eine Art 

»chroot« – sie stehen für PIDs genauso 

zur Verfügung wie für Netzwerke. Ein 

Prozess, der in einem Network Namespace 

gestartet wird, sieht also nicht 

die Netzwerkkarten des Systems, 

sondern lediglich die innerhalb dieses 

Namespaces existierenden Devices. 

Diesen Umstand macht sich Neutron 

zunutze: Für jedes interne sowie für 

jedes externe Netzwerk existiert auf 

dem Netzwerkknoten jeweils ein spezifischer 

Namespace. In den Namespaces 

landen die Pakete, die zuvor den Netzwerkknoten 

über die GRE-Tunnel erreicht 

haben. Sie befinden sich also von 

Anfang an „am richtigen Ort“, sodass 

der Netzwerkknoten Pakete zuordnen 

kann. Damit ein Kundennetzwerk Zugriff 

auf die Außenwelt hat, muss der 

Kunde der Cloud zudem eine Verbindung 

zwischen dem externen Netzwerk 

und dem internen DHCP-Netz schaffen, 

um eine Brücke zu bauen. Indem der 

Anbieter ein eventuell vorhandenes, externes 

Netz entsprechend fragmentiert 

und Kunden die einzelnen Fragmente 

zur Verfügung stellt, sorgt er also für 

echte Freiheit der Kunden in Sachen 

Netzwerktopologie. 

Externe IP-Adressen 

Technisch betrachtet sorgt der L3- 

Agent über SNAT-Regeln in den 

Iptables-Einträgen der einzelnen 

Network Namespaces für die externe 

Verbindung (Abbildung 4). Nicht unter 

den Tisch fallen soll bei dieser Gele-

62 

Know-how 

Neutron 

Namespace auf dem Netzwerkknoten 

an und erstellt eine DNAT-Regel, die die 

Pakete von der externen IP auf die interne 

DHCP-IP der Ziel-VM umleitet. 

Skalierbarkeit 

Die grundlegenden Funktionen von 

Neutron sind damit im Grunde erläutert 

– wer ob der Idee eines separaten 

Netzwerkknotens an ein künstliches 

Nadelöhr denkt, sei beruhigt: DHCPund 

L3-Agents können mehrmals im 

Netz vorhanden sein, allerdings kommt 

dem Admin in einem solchen Setup 

die Aufgabe zu, die Zuständigkeit einzelner 

Agent-Instanzen für spezisiche 

Tenant-Netzwerke per manuellem 

Konfigurationseintrag festzulegen (Listing 

1). Zukünftige Neutron-Versionen 

sollen Abhilfe schaffen, indem sie jeden 

Hypervisor-Knoten zum dynamischen 

Netzwerkknoten machen, der externe 

Verbindungen für genau die VMs ermöglicht, 

die eben auf ihm laufen. 

Abbildung 4: Innerhalb der Network Namespaces setzt der L3-Agent SNAT-Regeln, um VMs die 

Kommunikation mit der Außenwelt zu ermöglichen. 

n Info 





[1] Das VMWare-NSX-Plugin: 

[http:// www. openstack. org/ summit/ 

openstack‐summit‐hong‐kong‐2013/ 

session‐videos/ presentation/ under‐the‐hoo 

d‐network‐virtualization‐with‐openstack‐ne 

utron‐and‐vmware‐nsx] 

[2] Liste aller Plugins: 

[https:// wiki. openstack. org/ wiki/ Neutron] 

[3] DNSmasq: [http:// www. thekelleys. org. uk/ 

dnsmasq/ doc. html] 

n Autor 

Martin Gerhard Loschwitz arbeitet als Principal 

Consultant bei hastexo. Er beschäftigt sich dort intensiv 

mit den Themen HA, Distributed Storage und 

OpenStack. In seiner Freizeit pflegt er Pacemaker für 

Debian. 

genheit auch die zweite vom L3-Agent 

übernommene Aufgabe, nämlich VMs 

über externe IP-Adressen von außen erreichbar 

zu machen. Der L3-Agent nutzt 

auch hierfür die Namespaces. Es wäre 

aus mehreren Gründen unklug, müssten 

Nutzer externe IP-Adressen in ihren 

VMs von Hand konfigurieren. Denn 

einerseits werden manche Benutzer 

gar nicht wissen, wie sie das anstellen 

sollen, und andererseits müsste dann 

in der Cloud-Umgebung eine statische 

Konfiguration vorhanden sein, die die 

jeweilige externe IP bis zur VM durchroutet. 

Das skaliert in einer größeren Wolke 

aber schon deshalb nicht, weil Kunden 

VMs nicht immer dauerhaft benötigen, 

sondern öffentliche IPs eventuell schon 

nach kurzer Zeit zurückgeben, damit 

sie sie nicht länger bezahlen müssen. 

Neutron behilft sich mit einem Trick: 

Kunden können sich per Web-Interface 

externe IPs aus einem vom Admin einmal 

definierten Netz reservieren und 

sie dann einer VM mittels Mausklick 

zuweisen. Der L3-Agent legt die IP dann 

automatisch im passenden Network 

Fazit 

OpenStack Neutron ist ein faszinierendes 

Beispiel dafür, wie sich aus dem 

eher theoretischen Thema SDN ein 

praktischer Ansatz formen lässt. Ab 

Werk setzt Neutron auf Open vSwitch 

und damit auch auf OpenFlow. Die 

Funktionen, die OpenFlow für Open- 

Stack bereitstellt, genügen dabei 

völlig, um die in typischen Netzwerkinfrastrukturen 

zu findenden Hilfskonstruktionen 

wie VLANs zu ersetzen. 

Als besondere Dreingabe bekommen 

Kunden in gut geplanten Setups mit 

Neutron freie Hand über ihre eigene 

Netzwerktopologie in der Cloud, sodass 

der Cloud-Anbieter sich nicht mehr 

selbst um das Thema kümmern muss. 

Hinzu kommt, dass Neutron längst 

nicht am Ende der Feature-Fahnenstange 

ist: Insbesondere die Havana- 

Version hat zahlreiche neue Features 

wie die VPNaaS- und FWaaS-Agents, 

die On-Demand-VPN und Firewalling 

auf Zuruf komfortabel ermöglichen. 

Das LBaaS-Plugin (Loadbalancer as a 

Service) konfiguriert einen HA-Proxy, 

der eingehenden Traffic auf mehrere 

VMs weiterleitet. Ein Blick auf Neuigkeiten 

zu Neutron lohnt sich also allemal. 

(jcb) n 


watchara rojjanasain, 123RF 

Dateien und Verzeichnisse mit Incron überwachen 

Kontrolldatei 

Incron liefert eine einfache Möglichkeit, Befehle und Skripte durch Dateisystem-Events auszulösen. So 

verschickt das System beispielsweise automatisch E-Mails, wenn neue Dokumente vorliegen. Paul C. Brown 

Wer unter Linux ein Kommando starten 

möchte, sobald ein bestimmtes 

Ereignis eintritt, braucht nicht umständlich 

Log-Dateien auszulesen oder 

regelmäßige Anfragen zu schicken. Das 

Werkzeug Incron setzt auf das Kernel- 

Subsystem Inotify [1], um auf Ereignisse 

zu reagieren, die das Dateisystem 

betreffen, beispielsweise beim Öffnen, 

Erstellen oder Löschen einer Datei, 

einem Zugriff auf ein Verzeichnis oder 

einer Veränderung von Attributen. 

Der Name Incron erinnert absichtlich 

an das Standardwerkzeug Cron. Während 

sich Incron allerdings an Dateisys- 

n Die Wurzeln von Incron 

Der Zusatz »In« in Incron stammt von »Inode«. Diese 

Datenstruktur enthält die Details jeder Datei und 

jedes Verzeichnisses im Dateisystem, etwa den physischen 

Speicherort auf der Platte, die Größe und den 

Besitzer. 

Von Inode leitet sich auch der Name von Inotify ab, 

dem Subsystem des Linux-Kernels, auf dem Incron 

basiert. Es beobachtet Dateien und Verzeichnisse 

und benachrichtigt bei Änderungen auf Anfrage 

Anwendungen aller Art. Beispielsweise zeigt ein 

grafischer Dateimanager ein Symbol für einen neu 

erstellten Ordner im aktuellen Verzeichnis direkt an, 

auch wenn ein anderes Programm diesen erzeugt 

hat. Die Gnome- und KDE-Dateimanager Nautilus 

beziehungsweise Dolphin setzen auf Inotify, wie auch 

einige Texteditoren, die mit Inotify feststellen, ob ein 

anderer Benutzer oder ein anderes Programm eine 

Datei zwischenzeitlich verändert hat. 

temereignissen orientiert, startet Cron 

Jobs auf Basis von Zeitpunkten. 

Nur wenige Distributionen installieren 

Incron standardmäßig, die meisten 

halten es aber in ihren Repositories für 

die Installation mit dem Paketmanager 

vor. Wer die Quellen begutachten und 

kompilieren möchte, findet sie auf der 

Projekt-Homepage [1]. 

Die zentrale Komponente von Incron 

bildet der Daemon »incrond«. Er startet 

Programme gemäß den Einträgen in 

der benutzerspezifischen Incron-Job- 

Tabelle »incrontab«, die man analog 

zu Cron mit dem Befehl »incrontab ‐e« 

editiert. Dabei kommt der in der Umgebungsvariablen 

»$EDITOR« eingetragene 

Texteditor zum Einsatz. 

Je nach Distribution verlangt Incron 

eine explizite Erlaubnis. Dafür trägt 

man die gewünschten Benutzer – ein 

Name je Zeile – in die dafür zuständige 

Incron-Konfigurationsdatei ein, standardmäßig 

»/etc/incron.allow«. 

Jeder Incron-Auftrag besteht aus drei 

Spalten und steht – wiederum wie bei 

Cron – in einer eigenen Zeile. Die drei 

Teile eines Incron-Jobs lauten: 

n Pfad: das zu beobachtende Verzeichnis 

oder eine Datei 

n Maske: die zu registrierenden Ereignisse 

(siehe Tabelle 1) 

n Befehl: der auszuführende Befehl 

oder ein Shell-Skript 

Eine Zeile in der Incrontab-Datei sieht 

beispielsweise so aus: 

/home/$USER/my_dir U 

IN_CREATE /home/$USER/bin/hello.sh 

Es gilt zu beachten, dass es sich bei 

Incron nicht um einen Bash-Interpreter 

handelt. Deshalb empfiehlt sich die 

Verwendung eines Shell-Skripts, um 

beispielsweise die Ausgabe eines Befehls 

umzuleiten. In der Befehlsspalte 

einer Incrontab-Zeile interpretiert 

Incron nur den Befehl und seine Parameter. 

Folgt eine Umleitung wie »>>logfile«, 

erkennt Incron das ebenfalls als 

Befehlsargument; dass es ungültig ist, 

interessiert das Programm nicht. 

Des Weiteren gilt wie bei Cron, dass 

Incron die »$PATH«-Variable des Benutzers 

nicht kennt. Deshalb sollte die Angabe 

des Befehls unter Angabe seines 

vollständigen Pfades erfolgen. 

Um auf die durch Inotify ausgelösten 

Ereignisse gezielt zu reagieren, hält 

Incron die Variablen (Wildcards) aus 

Tabelle 2 vor. Die Ausdrücke beginnen 

mit dem »$«-Zeichen; um das Dollar- 

Symbol selbst zu verwenden, dient der 

Ausdruck »$$«. 

Der folgende Eintrag in der Incrontab 

ruft das Skript »hello.sh« mit dem Namen 

der Datei als Argument auf, die das 

Ereignis »IN_CREATE« ausgelöst hat: 


Know-how 

Incron 

65 

/home/paul/my_dir IN_CREATE U 

/home/paul/bin/hello.sh $# 

Automatischer Apache 

Als praktisches Beispiel startet Incron 

etwa einen Server neu, sobald sich 

dessen Konfigurationsdatei verändert 

hat. Die folgende Zeile startet den Apache-Webserver 

mittels Init-Skript neu, 

sobald sich die Konfigurationsdatei verändert 

hat (siehe Abbildung 1): 

Abbildung 1: Der Apache-Webserver protokolliert einen durch Incron ausgelösten Neustart. 

/etc/apache2/apache2.conf IN_MODIFY U 

/etc/init.d/apache2 restart 

Allerdings verwendet der Apache- 

Webserver üblicherweise verschiedene 

Konfigurationsdateien für seine 

zahlreichen Module. Der folgende 

Incrontab-Eintrag löst deshalb einen 

Neustart aus, sobald ein Benutzer 

eine neue Datei im Unterverzeichnis 

»conf.d« anlegt, das unter Debian die 

Apache-Konfigurationsdateien enthält; 

bei anderen Distributionen weicht der 

Verzeichnisname allerdings ab: 

n Tabelle 1: Ereignisse 

Ereignisname 

Allgemeine Ereignisse 

IN_ACCESS 

IN_ATTRIB 

IN_CLOSE_WRITE 

IN_CLOSE_NOWRITE 

IN_CLOSE 

IN_CREATE 

IN_DELETE 

IN_DELETE_SELF 

IN_MODIFY 

IN_MOVE_SELF 

IN_MOVED_FROM 

IN_MOVED_TO 

IN_MOVE 

IN_OPEN 

Spezielle Ereignisse 

IN_ALL_EVENTS 

IN_DONT_FOLLOW 

IN_ONESHOT 

IN_ONLYDIR 

Wildcard-Ereignisse 

IN_NO_LOOP 

Bedeutung 

/etc/apache2/conf.d/ IN_CREATE U 

/etc/init.d/apache2 restart 

Bei anderen Linux-Varianten käme hier 

etwa das Verzeichnis »/etc/apache2/ 

conf‐enabled« infrage. Außerdem 

verwenden SysV-Init-basierte Distributionen 

den Befehl »service apache2 

restart«, um den Webserver neu zu 

starten. 

Sollen neben neu angelegten Dateien 

auch Veränderungen an bestehenden 

Files den Server-Neustart auslösen, 

reiht man die beiden Ereignisse mit 

Zugriff (Lesen). 

Metadaten geändert (Berechtigungen, Zeitstempel, erweiterte 

Attribute). 

Zum Schreiben geöffnete Datei geschlossen. 

Nicht zum Schreiben geöffnete Datei geschlossen. 

Geöffnete Datei wird geschlossen. 

Datei oder Verzeichnis in beobachtetem Verzeichnis erstellt. 

Datei oder Verzeichnis in beobachtetem Verzeichnis gelöscht. 

Beobachtete Datei oder Verzeichnis gelöscht. 

Datei in beobachtetem Verzeichnis verändert. 

Beobachtete Datei oder Verzeichnis verändert. 

Datei aus beobachtetem Verzeichnis verschoben. 

Datei in beobachtetes Verzeichnis verschoben. 

Datei in oder aus beobachtetem Verzeichnis verschoben. 

Datei geöffnet. 

Irgendein Ereignis. 

Symbolischen Links nicht folgen. 

Datei oder Verzeichnis nur für ein Ereignis beobachten. 

Angegebenen Pfad nur dann beobachten, wenn es ein Verzeichnis 

ist. 

Beobachten unterbrechen, sobald ein Ereignis ausgelöst worden 

ist, bis der entsprechende Befehl beendet ist (verhindert 

Endlosschleifen). 

Kommas getrennt aneinander, denn ein 

Pfad darf nur einmal in der Incrontab- 

Datei auftauchen: 

/etc/apache2/conf.d/ IN_CREATE,U 

IN_CLOSE_WRITE /etc/init.d/apache2 U 

restart 

Die separate Behandlung der Verzeichnisse 

»/etc/apache2« und des Unterverzeichnisses 

»conf.d« in den vorhergehenden 

Beispielen lässt sich übrigens 

nicht einfach umgehen. Incrontab bietet 

keine Möglichkeit, ein Verzeichnis 

rekursiv zu überwachen. 

Gegen die Unendlichkeit 

Das sogenannte Wildcard-Ereignis »IN_ 

NO_LOOP« verhindert, dass ein Event 

in einem Verzeichnis zu einer endlosen 

Kette weiterer Ereignisse führt. 

Typischer Anwendungsfall ist eine 

Konfiguration, in der eine Log-Datei 

die Änderungen in einem Verzeichnis 

protokolliert: 

Verzeichnis IN_CLOSE_WRITE U 

log_changes $# 

Das Kommando »log_changes« im Beispiel 

schreibt den Namen der veränderten 

Datei in eine Log-Datei. Liegt diese 

im selben Verzeichnis, würde der dem 

Protokoll hinzugefügte Eintrag wiederum 

ein Änderungsereignis auslösen. 

n Tabelle 2: Wildcards 

Ausdruck Bedeutung 

»$@« Name des beobachteten Verzeichnisses 

»$#« Name der Datei, die das Ereignis ausgelöst 

hat 

»$%« Ereignisbezeichnung 

»$&« Numerisches Ereignissymbol 


Admin 

Ausgabe 03-2014

66 

Know-how 

Incron 

n Info 





[1] Incron: [http:// inotify. aiken. cz/ ? 

section=incron& page=about] 

Gegen eine solche Endlosschleife hilft 

»IN_NO_LOOP«. Es setzt den Eintrag 

außer Kraft, bis der Befehl »log_changes« 

abgeschlossen ist: 

Verzeichnis IN_CLOSE_WRITE,U 

IN_NO_LOOP log_changes $# 

Stiller Alarm 

Incron lässt sich auch als Hinweisgeber 

verwenden, um Zugriffe auf die Dateien 

eines bestimmten Verzeichnisses zu 

protokollieren. Ein Skript vermerkt im 

folgenden Beispiel jeden Zugriff auf ein 

bestimmtes Verzeichnis unter Angabe 

der Zugriffsart mithilfe des »$%«-Operators: 

/home/$USER/Dokumente IN_ACCESS,U 

IN_CLOSE_WRITE access_control.sh $% 

Hierbei dient der Name des Ereignisses 

(»$%«) als Argument für das Beispiel- 

Skript »access_control.sh«. 

Incrontab dynamisch 

Ein weiteres Praxisbeispiel verwendet 

Incron, um Benutzer über neue Dateien 

in einem Arbeitsverzeichnis zu benachrichtigen. 

Es enthält beispielsweise die 

Warteschlange des Mitarbeiters, in der 

er neue Dokumente vorfindet, die er zu 

bearbeiten hat. Incron befreit ihn von 

der lästigen Pflicht, den Ordner regelmäßig 

auf Neuigkeiten zu überprüfen. 

Eine Schwierigkeit besteht in diesem 

Szenario: Die Dokumente sollen in eine 

Ordnerstruktur unterhalb des Arbeitsverzeichnisses 

eingegliedert werden, 

etwa ein Unterordner für jedes Jahr 

und darunter ein weiterer für jeden 

Monat. Wie erwähnt bietet Incron allerdings 

keine Möglichkeit, Ordner rekursiv 

zu überwachen. Um nicht für jedes 

Verzeichnis einen einzelnen Eintrag in 

der Incrontab erstellen zu müssen, erledigt 

dies das Skript »makeIncrontab. 

sh« aus Listing 2. 

Der Trick besteht darin, die Incron- 

Tabelle automatisch zu bearbeiten, 

und nicht mit dem interaktiven Editor 

(»incrontab ‐e«) . Die Incrontab-Dateien 

liegen unter »/var/spool/incron/«. Für 

jeden Benutzer hält das Programm eine 

eigene Datei vor, benannt nach dessen 

Usernamen. Als Ausgangspunkt für das 

beschriebene Beispiel erstellt zunächst 

Root für jeden Mitarbeiter manuell 

einen Eintrag in seiner Incrontab mit 

»sudo incrontab ‐e«: 

n Listing 1: Automatisch generierte Incrontab-Datei für Benutzer »joe« 

/home/joe/lm75 IN_CREATE send_mail.sh address@admin.com joe@editor.com $# $@ 

/home/joe/lm76 IN_CREATE send_mail.sh address@admin.com joe@editor.com $# $@ 

/home/joe/shell02 IN_CREATE send_mail.sh address@admin.com joe@editor.com $# $@ 

/home/joe/uu04 IN_CREATE send_mail.sh address@admin.com joe@editor.com $# $@ 

/home/joe IN_CREATE U 

/usr/local/bin/makeIncrontab.sh $@ 

/home/jane IN_CREATE U 


/home/jed IN_CREATE U 


... 

Das erfordert zwar weiterhin etwas 

Handarbeit, aber nur beim Hinzufügen 

und Entfernen einzelner Mitarbeiter. 

Incrontab überwacht nun das Home- 

Verzeichnis jedes Mitarbeiters und ruft 

»makeIncrontab.sh« (Listing 2) auf, sobald 

darin ein neues Unterverzeichnis 

angelegt wird. 

Das Skript »makeIncrontab.sh« nimmt 

einen Benutzernamen als Argument 

entgegen – ausgelesen mit »$@« – und 

löscht bereits existierende Incrontab- 

Dateien. Das bringt den Vorteil mit 

sich, dass zuvor angelegte Regeln für 

eventuell nicht mehr bestehende Verzeichnisse 

automatisch verschwinden. 

Danach iteriert »makeIncrontab.sh« 

über alle Unterverzeichnisse im Home- 

Verzeichnis des angegebenen Benutzers. 

Für jedes davon erzeugt es einen 

neuen Incrontab-Eintrag. Sobald einem 

dieser Verzeichnisse eine neue Datei 

hinzugefügt wird, ruft es das Skript 

»send_mail.sh« auf. 

Die E-Mail-Adresse des Benutzers 

entnimmt das Skript der Datei ».emailaddress« 

im Home-Verzeichnis, die 

zu diesem Zweck natürlich existieren 

muss. Daneben verwendet »makeIncrontab.sh« 

das Skript »send_mail.sh«, 

um in diesem Beispiel eine E-Mail an 

den Benutzer zu senden. Listing 1 zeigt 

eine Incrontab-Datei als mögliches Ergebnis 

des Vorgangs. (csc) n 

n Listing 2: »makeIncrontab.sh« erzeugt eine Incrontab 

01 #!/bin/bash 

02 

03 # Der Benutzername wird aus dem überwachten 

04 # Verzeichnis ausgelesen ($@) und von 

05 # Incron als erstes Argument ($1) 

06 # übergeben. 

07 

08 # Die Benutzer‐Incrontab löschen: 

09 rm /var/spool/incron/`echo $1|cut ‐d / ‐f 3` 

10 

11 # Über den Inhalt des Home‐Verzeichnisses iterieren: 

12 for i in $1/* 

13 do 

14 

15 # ... Für jedes Verzeichnis eine 

16 # Incron‐Regel (ignoriere Dateien). 

17 if [ ‐d $i ] 

18 then 

19 echo "$i IN_CREATE send_mail.sh address@admin.com `cat 

$1/.emailaddress`" '$# $@' >> /var/spool/incron/`echo $1|cut ‐d / 

‐f 3` 

20 fi 

21 done 


68 

Know-how 

CRIU 

Valentyn Volkov Volkov, 123RF 

Linux-Prozesse speichern und wiederherstellen mit CRIU 

Auf Eis gelegt 

Einfrieren und Auftauen: Was bei Pizza normal ist, erledigt bei Linux-Prozessen CRIU. Tim Schürmann 

Manche Wartungsarbeiten lassen 

sich nur dann vornehmen, wenn keine 

Produktiv-Software mehr läuft. Doch 

Admins können Prozesse nicht nach 

Gutdünken beenden, sonst droht 

Datenverlust; zeitaufwendige Berechnungen 

müssten von vorne beginnen. 

Abhilfe schafft auf Linux-Systemen das 

kleine Werkzeug Checkpoint/Restore In 

Userspace, kurz CRIU genannt. 

CRIU friert den aktuellen Zustand eines 

Prozesses ein und sichert ihn auf der 

Festplatte. Später lässt sich der Prozess 

wieder zum Leben erwecken und 

arbeitet dann an der Stelle weiter, an 

der CRIU ihn eingefroren hat. Bei virtuellen 

Maschinen heißt dieses Konzept 

Snapshots. 

Das Konservieren hilft nicht nur bei 

Wartungsarbeiten. Angehaltene Prozesse 

lassen sich auch auf andere 

Rechner verschieben und laufen dort 

weiter. Diese Live-Migration hilft beispielsweise 

beim Loadbalancing: Dreht 

ein Rechner gerade Däumchen, transferiert 

man einen Prozess per Skript 

dorthin. Des Weiteren lassen sich verdächtig 

agierende Prozesse einfrieren 

und auf einem anderen System in Ruhe 

analysieren. Bindet man CRIU in die 

Startskripte des Systems ein, sichert es 

Prozesse beim Herunterfahren automatisch 

und bringt sie beim nächsten 

Systemstart zurück in den Speicher. Auf 

diese Weise stellt man nicht nur den 

Zustand vor dem Ausschalten wieder 

her, sondern verkürzt auch den Boot- 

Vorgang. 

Nümmerchen 

Die erste CRIU-Version erschien vor 

nicht einmal zwei Jahren. Von der aktuellen 

Version 1.1 lag bei Redaktionsschluss 

nur der erste Release Candidate 

vor; bei Erscheinen dieses ADMIN- 

Magazins sollte CRIU 1.1 jedoch zur 

Verfügung stehen. Dennoch basieren 

die folgenden Ausführungen auf dem 

Release Candidate. Ältere Versionen 

sammelt das Release-Archiv unter [2]. 

CRIU arbeitet zwar vollständig im 

Userspace, stellt aber mehrere Anforderungen 

ans laufende System. Zunächst 

funktioniert das Programm nur 

auf Systemen mit ARM- oder x86_64- 

Architektur, in letztem Fall muss auch 

ein 64-Bit-Linux laufen. Des Weiteren 

verlangt CRIU einen Linux-Kernel ab 

Version 3.11. Aktuelle Desktop-Distributionen 

erfüllen diese Bedingung, die 

auf Servern beliebten Linux-Varianten 

Debian 7 und CentOS 6.5 jedoch nicht. 

Der Einsatz von CRIU auf diesen Systemen 

setzt deshalb ein Kernel-Upgrade 

voraus. 

Der laufende Kernel muss außerdem 

die von CRIU verlangten Funktionen 

bereitstellen. Tabelle 1 führt die beim 

Kernel-Kompilieren zu aktivierenden 

Einstellungen auf. Liegt ein fertiger 

Kernel vor, prüft CRIU dessen Kompatibilität 

mit »criu check«. 

Aufgrund der detaillierten Ansprüche 

an den Betriebssystemkern stellten die 

CRIU-Entwickler in der Vergangenheit 

eigens einen passenden Kernel bereit. 

Da Linux in Version 3.11 jedoch alle 

notwendigen Funktionen mitbringt, 


Know-how 

CRIU 

69 

fällt diese Notwendigkeit weg und der 

Einsatz alter CRIU-Kernel empfiehlt 

sich nicht mehr. 

Erfüllt der Kernel alle Voraussetzungen, 

muss zudem Googles Protocol- 

Buffers-Bibliothek her [3, 4], die in den 

Repositories der meisten Distributionen 

bereitsteht. Neben der Bibliothek 

selbst benötigt man die zugehörigen 

Entwicklungspakete, die C-Bindings 

und den Protobuf-C-Compiler. Unter 

Ubuntu und Debian heißen die entsprechenden 

Pakete »libprotobuf‐c0‐dev« 

und »protobuf‐c‐compiler«, auf anderen 

Distributionen ähnlich. 

CRIU greift außerdem auf Iproute2 zurück, 

das mindestens in Version 3.5.0 

von August 2012 vorliegen muss. Auch 

dieses Werkzeug haben die meisten 

aktuellen Distributionen an Bord. Falls 

nicht, wie im Fall von Debian 7, gibt es 

den Quellcode unter [5]. 

Testlauf 

Um CRIU zu übersetzen, benötigt man 

nach dem Download der Quellen [1] 

nur noch das Make-Werkzeug und einen 

C-Compiler. Nach dem Entpacken 

des Archivs und dem Kompilieren mit 

»make« ist eine systemweite Installation 

des Werkzeugs weder vorgesehen 

noch notwendig. 

Bevor man die ersten Prozesse schockfrostet, 

empfiehlt sich ein CRIU-Test. 

Dazu initiiert man als Benutzer Root 

auf der Kommandozeile 

diesen Befehl: 

criu check ‐‐ms 

Am Ende sollte CRIU 

die Meldung »Looks 

good« auswerfen 

(siehe Abbildung 1). Andernfalls verrät 

das Werkzeug, welche Funktion fehlt. 

Ältere Versionen des Tools hießen übrigens 

noch »crtools«, deshalb beziehen 

sich manche im Internet kursierende 

Anleitungen noch auf diesen Befehlsnamen. 

Der nächste Testschritt folgt im CRIU- 

Unterverzeichnis 

»test«. Dort ruft man 

als Root das Skript 

»zdtm.sh« auf. Diese 

Test-Suite startet mehrere 

Prozesse und friert 

sie probeweise ein. Ein 

kompletter Durchlauf 

benötigt einige Minuten, 

während derer das 

System immer wieder 

einfrieren kann. Bei 

einem Problem bricht 

die Test-Suite ab und 

nennt die Quelle. Nach 

erfolgreichem Durchlauf 

erscheint nur das 

Resultat des letzten 

Tests (Abbildung 2). 

Abbildung 1: Meldet CRIU »Looks good«, bietet der Kernel alle vom 

Werkzeug benötigten Funktionen. 

Sandmann 

Um nach erfolgreichen Tests einen 

Prozess einzufrieren, benötigt CRIU 

lediglich dessen Prozess-ID und einen 

Speicherort. Der folgende Befehl 

sichert den Prozess mit der PID 2238 

im Unterverzeichnis »checkpoint« des 

User-Home-Ordners: 

Abbildung 2: Die Test-Suite prüft, ob das System alle Voraussetzungen 

für den Betrieb von CRIU erfüllt. 

n Tabelle 1: Notwendige Kernel-Funktionen 

Variable 

CONFIG_EMBEDDED 

CONFIG_EXPERT 

CONFIG_EVENTFD 

CONFIG_EPOLL 

CONFIG_CHECKPOINT_RESTORE 

CONFIG_NAMESPACES 

CONFIG_PID_NS 

CONFIG_FHANDLE 

CONFIG_INOTIFY_USER 

CONFIG_IA32_EMULATION 

CONFIG_UNIX_DIAG 

CONFIG_INET_DIAG 

CONFIG_INET_UDP_DIAG 

CONFIG_PACKET_DIAG 

CONFIG_NETLINK_DIAG 

CONFIG_MEM_SOFT_DIRTY 

Im Konfigurationsmenü zu aktivieren unter 

General setup | Embedded system 

General setup | Configure standard kernel features (expert users) 

General setup | Configure standard kernel features (expert users) | Enable eventfd() system call 

General setup | Configure standard kernel features (expert users) | Enable eventpoll support 

General setup | Checkpoint/restore support 

General setup | Namespaces support 

General setup | Namespaces support | PID Namespaces 

General setup | open by fhandle syscalls 

File systems | Inotify support for userspace 

Executable file formats | Emulations | IA32 Emulation 

Networking support | Networking options | Unix domain sockets | UNIX: socket monitoring interface 

Networking support | Networking options | TCP/IP networking | INET: socket monitoring interface 

Networking support | Networking options | TCP/IP networking | INET: socket monitoring interface | UDP: socket 

monitoring interface 

Networking support | Networking options | Packet socket | Packet: sockets monitoring interface 

Networking support | Networking options | NETLINK: socket monitoring interface 

Processor type and features | Track memory changes 


Admin 

Ausgabe 03-2014

70 

Know-how 

CRIU 

Abbildung 3: Der »top«-Prozess mit der ID 2238 lässt sich erst mit dem 

Parameter »‐‐shell‐job« dumpen. 

criu dump ‐‐images‐dir ~/checkpoint U 

‐‐tree 2238 

Hinter »criu« folgt immer zunächst die 

auszuführende Aktion, in diesem Fall 

erstellt es eine Sicherung – Dump oder 

Image genannt. Hinter »‐‐images‐dir« 

oder »‐D« steht das Verzeichnis, hinter 

»‐‐tree« oder »‐t« die Prozess-ID. CRIU 

benötigt für sämtliche Aktionen Root- 

Rechte. 

Das Einfrieren schlägt jedoch fehl, 

wenn sich der zu speichernde Prozess 

Ressourcen mit dem Eltern- oder einem 

anderen Prozess teilt. Dann bricht CRIU 

sicherheitshalber den Vorgang ab. Bei 

in einer Shell gestarteten Prozessen 

lässt sich eine solche Ressourcenteilung 

oft nicht vermeiden, zur Lösung 

gibt es drei Möglichkeiten: Entweder 

man verschiebt einen 

Prozess in den 

Hintergrund, startet 

ihn in einer separaten 

Session oder übergibt 

CRIU den zusätzlichen 

Parameter »‐‐shell‐job« 

(Abbildung 3): 

criu dump ‐D ~/checkpoint ‐t 2238 U 

‐‐shell‐job 

Im Zielverzeichnis – im Beispiel heißt es 

»~/checkpoint« – legt CRIU für einen gesicherten 

Prozess mehrere Dateien an. 

Jede von ihnen enthält den Zustand 

einer vom Prozess genutzten Ressource 

(Abbildung 4). Bereits vorhandene Dateien 

überschreibt CRIU ohne Warnung. 

Nach dem es ihn gesichert hat, beendet 

CRIU den Prozess. Dessen letzte 

Ausgabe landet gegebenenfalls unformatiert 

im Terminal wie in Abbildung 5. 

Der CRIU-Parameter »‐‐leave‐running« 

sorgt dafür, dass CRIU den gespeicherten 

Prozess weiterlaufen lässt. 

Reanimation 

Der folgende Befehl weckt einen gespeicherten 

Prozess 

wieder auf: 

criu restore ‐D U 

~/checkpoint U 

‐‐restore‐detached 

Der Parameter »‐‐restore‐detached« 

sorgt 

dafür, dass sich CRIU 

nach der Wiederherstellung beendet. 

Der reanimierte Prozess besitzt dann 

Init als Elternprozess und trägt die 

gleiche Prozess-ID wie beim Einfrieren. 

Ist diese PID inzwischen anderweitig 

vergeben, bricht die Restauration mit 

einem Fehler ab. Abhilfe schafft die Option 

»--name spaces« oder »-n« . Damit 

erhält der Task vom System eine neue 

PID und behält seine alte nur intern in 

einem virtuellen Prozessnamensraum. 

Hat man den Prozess mit »‐‐shell‐job« 

gesichert, ist dieser Parameter auch bei 

der Wiederherstellung notwendig (Abbildung 

6). Der Prozess startet dann in 

der Shell, in der man »criu« aufgerufen 

hat. Zudem dauert es unter Umständen 

einen kurzen Moment, bis der Prozess 

tatsächlich die Arbeit aufnimmt. 

Bei der Wiederherstellung bleibt die 

Sicherung im Verzeichnis »checkpoint« 

erhalten. Man kann den Prozess folglich 

jederzeit erneut an derselben Stelle 

wiederbeleben. 

Um den gespeicherten Prozess auf 

einem anderen System aufzuwecken, 

kopiert man das komplette Verzeichnis 

mit der Sicherung auf den anderen 

Rechner und reanimiert dort den 

Prozess mit »criu restore«. Die neue 

Umgebung muss jedoch mit der alten 

übereinstimmen und die benötigten 

Dateien in den gleichen Verzeichnispfaden 

enthalten. Idealerweise handelt 

es sich beim neuen System um einen 

Klon. Oder ein verteiltes Dateisystem 

wie NFS stellt die Dateien bereit. In 

jedem Fall sollten Administratoren die 

Live-Migration testweise durchspielen, 

Abbildung 4: CRIU gewährt Einblick in den Inhalt eines gespeicherten 

Prozesses. 

Abbildung 5: Vom CRIU-gesicherten »top«-Prozess verbleibt die letzte 

Ausgabe auf dem Terminal. 


Know-how 

CRIU 

71 

um fehlenden Bibliotheken, Konfigurationsdateien 

und Dokumenten auf die 

Spur zu kommen. 

Vorausschauend 

CRIU bietet die Möglichkeit, die Sicherung 

eines Prozess vorzubereiten und 

dabei zu beschleunigen. Dazu dient der 

CRIU-Parameter »pre‐dump«: 

criu pre‐dump ‐t 2369 ‐D U 

~/checkpoint/pre 

Der Prozess läuft danach normal weiter. 

Ein erneuter Aufruf des Befehls 

aktualisiert die Vorsicherung jederzeit 

(Abbildung 7). Bei der eigentlichen 

Sicherung verweist man dann mit dem 

Parameter »‐‐prev‐images‐dir« aufs 

Pre-Dump: 

criu dump ‐t 2369 ‐D ~/checkpoint/dump U 

‐‐prev‐images‐dir ../pre 

Der Parameter »‐‐prev‐images‐dir« 

erwartet einen Verzeichnispfad relativ 

zum mit »‐D« angegebenen Speicherort. 

Im obigen Beispiel landet die Vorsicherung 

unter »~/checkpoint/pre«, die 

eigentliche Sicherung unter »~/checkpoint/dump«. 

Die Wiederherstellung 

funktioniert wie bei jedem Dump: 

Sparsame 

Wiederholung 

Wer von einem Prozess 

mehrfach einen 

Schnappschuss anlegen 

möchte, spart Zeit 

und Speicherplatz mit 

einer inkrementellen 

Sicherung. Dazu erstellt 

man einen ersten 

Dump wie gehabt, 

lässt den Prozess aber 

mit dem Parameter 

»‐‐leave‐running« weiterlaufen: 

criu dump ‐t 2334 U 

‐D ~/checkpoint/1/U 

‐‐leave‐running U 

‐‐track‐mem 

Die erste Sicherung wandert hier ins 

Verzeichnis »~/checkpoint/1/«. Mit dem 

Parameter »‐‐track‐mem« lässt CRIU 

den Kernel den Hauptspeicherbereich 

des Prozesses beobachten. Dessen Informationen 

beschleunigen eine zweite 

Sicherung: 

criu dump ‐t 2334 ‐D ~/checkpoint/2/U 

‐‐leave‐running ‐‐track‐mem U 

‐‐prev‐images‐dir ../1/ 

Abbildung 6: Die Wiederherstellung eines mit »‐‐shell‐job« gespeicherten 

Prozesses scheitert ohne Nennung des Grundes, wenn dieser 

Parameter fehlt. 

Abbildung 7: Eine Vorsicherung mit »pre‐dump« beschleunigt den 

Speicherprozess. 

wobei man das Verzeichnis wieder 

relativ zu dem hinter »‐D« definierten 

Ort angibt. Nach dem gleichen Prinzip 

erstellt man weitere Sicherungen. Beim 

letzten Dump lässt man die Parameter 

»‐‐leave‐running« und »‐‐track‐mem« 

weg und beendet damit den Prozess. 

Die anschließende Wiederherstellung 

erfolgt wie zuvor: 

criu restore ‐D ~/checkpoint/2/ U 


criu restore ‐D ~/checkpoint/dump U 


Hier verrät »‐‐prev‐images‐dir« den 

Speicherort der ersten Sicherung, 

Ein Verzeichnis enthält im Normalfall 

eine komplette Sicherung. Auf Wunsch

72 

Know-how 

CRIU 

n Fernsteuerung 

»criu« lässt sich auch als Daemon starten und dann 

über passende RPC-Aufrufe fernsteuern: 

criu service ‐‐daemon ‐o logdatei.txt 

»‐‐daemon« startet CRIU als einen solchen, »‐o« 

nennt den Namen der Log-Datei, in die CRIU seine 

Ausgaben schreibt. Auf RPC-Anfragen wartet das 

Werkzeug dann am Unix-Socket »SOCK_SEQPACKET« 

unter »/var/run/criu‐service.socket«. Dort geben 

Client-Programme Nachrichten in Form des CRIU- 

RPC-Protokolls ab. Deren detaillierten Aufbau führt 

das CRIU-Wiki unter [6] auf, Beispielprogramme für C 

und Python liegen im CRIU-Quellcodeverzeichnis unter 

»test/rpc«. C-Programmierer verwenden alternativ 

die Bibliothek »libcriu«, die Wrapper-Funktionen 

für die entsprechenden RPC-Aufrufe [7] anbietet. 

n Info 

spart CRIU Platz, indem es nur die seit 

dem letzten Dump geschehenen Änderungen 

speichert. Dazu dient das Deduplikationsfeature 

mit dem Parameter 

»--auto‐dedup«: 

criu dump ‐t 2334 ‐D ~/checkpoint/2/U 

‐‐leave‐running ‐‐track‐mem U 

‐‐prev‐images‐dir ../1/ ‐‐auto‐dedup 

CRIU löscht jetzt alle überflüssigen 

Daten in der vorherigen Sicherung, 

nicht aber in der neuen! Unter »~/ 

checkpoint/2« landet folglich ein kompletter 

Dump, unter »~/checkpoint/1« 





[1] CRIU: [http:// criu. org/] 

[2] Release-Archiv: [http:// criu. org/ Releases] 

[3] Google Protocol Buffers: 

[http:// code. google. com/ p/ protobuf/] 

[4] C-Bindings für Googles Protocol Buffers: 

[http:// code. google. com/ p/protobuf‐c/] 

[5] Iproute2: [https:// www. kernel. org/ pub/ linux/ 

utils/ net/ iproute2/] 

[6] CRIU-RPC: [http:// criu. org/ RPC] 

[7] libcriu: [http:// criu. org/ C_API] 

[8] Unterstützte Programme: [http:// criu. org/ 

What_software_is_supported] 

[9] Einfrieren von TCP-Verbindungen: 

[http:// criu. org/ TCP_connection] 

verbleiben nur die Unterschiede zur 

zweiten Sicherung. Liegen bereits inkrementelle 

Sicherungen vor, reduziert 

die Aktion »dedup« diese nachträglich 

auf die Unterschiede: 

criu dedup ‐D ~/checkpoint/2/ 

Stolperfallen 

Das Einfrieren und Auftauen von Prozessen 

funktioniert noch nicht mit 

jedem Prozess. Die CRIU-Entwickler 

führen unter [8] eine kurze Liste offiziell 

unterstützter Software, die Programme 

wie Make und GCC, Tar, Git, 

Apache, MySQL, SSH und MongoDB 

umfasst. Grundsätzlich nicht einfrieren 

lassen sich Prozesse, die gerade auf 

Hardware-Geräte zugreifen, egal ob es 

sich dabei um Block- oder Character- 

Devices handelt. Das hat zwei Gründe: 

Die genaue Funktionsweise des Geräts 

bleibt CRIU verborgen und beim Wiederherstellen 

eines Prozesses könnte 

das Gerät fehlen. 

Da CRIU die gleichen Schnittstellen 

wie ein Debugger verwendet, friert das 

Werkzeug außerdem keine Prozesse 

ein, die bereits der Beobachtung durch 

STrace oder GDB unterliegen. Des 

Weiteren sichert CRIU keine Prozesse, 

die einen Lock auf eine Datei besitzen, 

denn CRIU kann hier nicht feststellen, 

ob nicht doch noch einem anderen Prozess 

der Zugriff auf die entsprechende 

Datei gestattet ist. Der optionale Parameter 

»‐‐file‐locks« zwingt CRIU jedoch, 

den Lock mitzusichern. Des Weiteren 

kommt CRIU in Version 1.1 mit dem 

Dateisystem Btrfs nicht zurecht, die 

Entwickler arbeiten hier jedoch an einer 

Lösung. 

Außerdem können sich nach der Wiederherstellung 

des Prozesses einige 

Werte verändert haben, etwa die IDs 

der Mount-Points und die der Sockets 

sowie die Startzeit des Prozesses. »cat 

/proc/1234/stat« enthüllt letztere Information 

beispielsweise für einen Prozess 

mit der ID 1234 im Feld 22. 

Ins Netz gegangen 

Programme, die über eine TCP-Verbindung 

kommunizieren, konserviert 

CRIU mithilfe des Linux-Kernels. Dabei 

schließt es den betroffenen Socket und 

blockiert mit einer zusätzlichen Firewall-Regel 

die TCP-Verbindung. CRIU 

stellt so sicher, dass die Verbindung im 

selben Zustand wie beim Speichern 

verbleibt. Diese Firewall-Regel muss 

deshalb bei der Wiederherstellung des 

Prozesses noch in der Netfilter-Table 

stehen. 

Um den Umgang mit einer TCP-Verbindung 

auszulösen, übergibt man CRIU 

beim Sichern und Wiederherstellen 

den Parameter »‐‐tcp‐established«. Ein 

so konservierter Prozess lässt sich nur 

genau ein Mal wiederbeleben. Jeder 

weitere Versuch scheitert, weil sich die 

TCP-Verbindung dann in einem anderen 

Zustand befindet. Das CRIU-Wiki 

beschreibt die technischen Hintergründe 

im Detail unter [9]. 

CRIU friert nicht nur den Prozess 

selbst ein, sondern sicherheitshalber 

auch immer dessen Kind- sowie alle 

abhängigen Prozesse. Sprechen zwei 

Programme über eine Pipe oder einen 

Unix-Socket miteinander, legt CRIU 

folglich beide gleichzeitig aufs Eis. 

In manchen Situationen kann CRIU 

jedoch nur einen der beiden Prozesse 

einfrieren; dann verweigert CRIU die 

Arbeit mit der Fehlermeldung »external 

socket is used error«. Über den Parameter 

»‐‐ext‐unix‐sk« beim Sichern 

und Wiederherstellen lässt sich CRIU 

dennoch überreden, zumindest einen 

Prozess zu sichern. Beim Wiederherstellen 

muss man dann allerdings dafür 

sorgen, dass die Gegenstelle bereits 

existiert. 

Fazit 

CRIU bietet äußerst nützliche Funktionalität, 

doch angesichts des Zustands 

der aktuellen Programmversion ist 

beim Produktiveinsatz Vorsicht geboten. 

Sie funktioniert zwar, doch wiederbelebte 

Programme stürzen gelegentlich 

ab. Umfangreiche Vorabtests mit 

dem geplanten Setup sind also eine unabdingbare 

Voraussetzung. Die CRIU- 

Entwicklung schreitet aber in schnellen 

Schritten voran und wer Prozesse 

einfrieren und migrieren möchte, sollte 

CRIU im Auge behalten. Weiterführende 

Informationen, einschließlich der hinter 

CRIU stehenden Techniken, liefert 

das umfangreiche Wiki [1]. (csc) n 


74 

Know-how 

CloudFormation 

Jan Rose, Fotolia 

Automatisierung in der Cloud: Alles über Orchestration 

Orchesterprobe 

Automatisierung etabliert sich im IT-Umfeld allerorten, auch – oder gerade – in der Cloud. Hier heißt das 

Schlagwort: Orchestrierung. Martin Loschwitz 

Wann ist Arbeit eigentlich effizient? 

Die meisten werden Arbeit dann für 

effizient halten, wenn sich durch möglichst 

geringen Einsatz möglichst viel 

Ertrag erzielen lässt – freilich ohne dass 

die Qualität des Produktes leidet und 

man so Kunden (oder Arbeitgeber) vergrault. 

In der IT gilt seit geraumer Zeit 

Automatisierung als ein willkommenes 

Werkzeug, um diesem Ziel ein gutes 

Stück näher zu kommen. Die Grundidee 

besteht darin, regelmäßige Aufgaben 

automatisch zu erledigen, statt einen 

Mitarbeiter damit zu beschäftigen, 

damit der sie manuell ausführt. Mittlerweile 

existiert eine stattliche Anzahl 

gut funktionierender Werkzeuge für 

allgemeine Automatisierungsaufgaben: 

Man denke an Puppet, Chef oder Ansible 

– sie alle buhlen um die Gunst der 

Nutzer. 

Im IT-Umfeld haben sich gerade 

Service-Provider die Automatisierung 

zunutze gemacht, speziell auch solche, 

die Cloud-Services anbieten. Schließlich 

können sich Anwender in einer 

gut geplanten öffentlichen Wolke nach 

Herzenslust selbst bedienen und brauchen 

den Service-Provider bloß noch 

dann persönlich in Anspruch zu nehmen, 

wenn mal etwas schief läuft. Aus 

Provider-Sicht sind Clouds insofern ein 

Segen, denn sie erlauben dem eigenen 

Personal an sinnvollen Neuerungen 

statt an den ewig gleichen Routineaufgaben 

zu arbeiten. 

Automatisierung auf Blech 

Was für Anbieter paradiesisch klingt, 

ist für Anwender zunächst nicht ganz 

so erfreulich. Denn die meisten liebgewonnenen 

Automatisierungswerkzeuge 

tun in der Cloud nicht gar so gut ihren 

Dienst. Das liegt an den verschiedenen 

Konzepten, die physikalischen und virtuellen 

Systemen quasi inhärent sind: 

Ein physischer Server ist ein definiertes 

Stück Hardware, das in der Regel für 

einen spezifischen Zweck angeschafft 

und auch eingesetzt wird. Hat der Server 

es erstmal ins Rack geschafft, bleibt 

er in der Regel dort. 

Für die Automatisierung ergeben sich 

hieraus gleich mehrere Konsequenzen. 

In einem Virtualisierungs-Framework 


Know-how 


75 

Abbildung 1: In OpenStack zeichnet Heat für die Orchestrierung verantwortlich. Der Dienst besteht aus einer Processing-Engine und verschiedenen 

APIs, die sowohl Amazons CFN-Format als auch das native Heat-Format HOT verstehen. 

lässt sich ein physischer Server statisch 

behandeln; anhand der MAC-Adressen 

seiner Netzwerkkarten lässt er sich 

über PXE automatisiert installieren, 

und über Puppet, Chef oder eine der 

diversen anderen Lösungen verpasst 

ihm der Anbieter eine spezifische Konfiguration. 

Ganz anders sieht es mit virtuellen 

Maschinen aus, die Cloud-Kunden als 

Bestandteil ihrer Infrastruktur verwenden. 

Zunächst sind Cloud-VMs häufig 

volatil: Einmal aus einem vorgebauten 

Image gestartet, verschwinden sie 

unter Umständen schon bald wieder, 

wenn sie nicht mehr benötigt werden. 

Fällt eine aus, ist sie leicht zu ersetzen. 

Reparieren lohnt sich hier in der Regel 

also nicht. 

Hinzu kommt, dass sich VMs kaum 

sinnvoll mit den üblichen Konfigurationswerkzeugen 

automatisieren lassen. 

Auf der einen Seite werden Puppet, 

Chef & Co. ja immer erst dann aktiv, 

wenn die VM schon läuft; sie helfen 

dem Benutzer aber nicht dabei, eine 

große Menge benötigter VMs zu starten. 

Denkbar wäre zu Testzwecken eine 

Webserver-Farm, auf der sich die neue 

Version einer Website austesten lässt. 

Und es wäre zwar technisch möglich, 

jeder manuell gestarteten VM mit 

Puppet & Co. eine spezifische Aufgabe 

zuzuteilen, doch ist es eher mühsam, 

für 20 gestartete VMs jeweils einen 

Puppet-Eintrag anzulegen und sie dann 

mittels Puppet-Agent entsprechend zu 

verarzten. 

macht und deutlich besser auf Cloud- 

Verhältnisse zugeschnitten ist. Über die 

AWS-CloudFormation managen Admins 

VMs in ihrer Wolke effizient und schnell. 

Das Prinzip gefiel selbst den Open- 

Stack-Entwicklern so gut, dass sie eine 

CloudFormation-Engine auch für ihr 

Projekt bauten, die mit Amazons Version 

sogar kompatibel ist (Abbildung 1). 

Im Folgenden vermittelt dieser Artikel 

einen Eindruck der Orchestrierungsmöglichkeiten 

in privaten und öffentlichen 

Clouds auf Grundlage von AWS- 

CloudFormation – die AWS-Version und 

die OpenStack-Komponente sind dabei 

mit Blick auf grundlegende Funktionen 

ebenbürtig. 

Voraussetzung für eine funktionierende 

Orchestrierung sind im Wesentlichen 

die Funktionen, die Clouds ohnehin 

schon zur Verfügung stellen. Denn 

das sich ein Nutzer am webbasierten 

Service-Portal einloggen und eine VM 

starten kann, ist ja durchaus auch ohne 

Orchestrierung kein Problem. In aller 

Regel genügt es, den gewünschten 

VM-Typ im Hinblick auf die virtuelle 

Hardware sowie das gewünschte Betriebsystem 

auszuwählen. Nach einem 

abschließenden Klick und ein paar 

Sekunden Wartezeit steht das neue 

System bereits zur Verfügung. Etwaige 

Sonderwünsche sind auch möglich – so 

ist es kein Problem, eine VM direkt von 

persistentem Speicher zu starten oder 

ihr nach dem Starten eine öffentliche IP 

zuzuteilen, damit sie aus dem Internet 

erreichbar ist. 

Es soll also keineswegs der Eindruck 

entstehen, Orchestrierung erfinde all 

diese Funktionen neu; ganz im Gegenteil: 

Orchestrierung zielt darauf ab, die 

Automatisierung à la Cloud 

Effektive Automatisierung in der Wolke 

bedingt also ein anderes Vorgehen als 

fürs Blech. Amazon hat sich als Vorreiter 

im Cloud-Segment quasi eine 

eigene Lösung gestrickt, die aus Automatisierung 

kurzerhand Orchestrierung 

Abbildung 2: Mittels des »template‐validate«-Befehls von Heat können die Autoren von Templates 

diese auf syntaktische Korrektheit hin überprüfen. 


Admin 

Ausgabe 03-2014

76 

Know-how 


vorhandene Funktionalität automatisch 

nutzbar zu machen. Technisch 

gelöst ist das sowohl bei Amazon als 

auch bei OpenStack Heat – der Orchestrierungslösung 

von OpenStack – über 

eine sogenannte Template-Engine. 


Benutzer verfüttern an diese Engines 

Textdateien (Templates), die in einer 

spezifischen Syntax Befehle enthalten; 

die Template-Engine setzt die Befehle 

um und führt über die Cloud-Funktionen 

die gewünschten Aktionen aus (Listing 

1 enthält ein Beispiel-Template). 

Spannend ist dabei insbesondere die 

Frage, wie umfassend die jeweilige 

Template-Engine die angebotenen 

Funktionen der Cloud unterstützt, denn 

nicht jede Funktion lässt sich automatisch 

auch zum Teil von Orchestrierungs-Templates 

machen. Nur wenn 

die Policy es zulässt, ist eine bestimmte 

Aufgabe in der Cloud auch tatsächlich 

automatisierbar. 

Im AWS-Kontext steht freilich die 

CloudFormation-Engine von Amazon 

mitsamt der dazugehörigen Template- 

Syntax im Fokus der Anwender. Im Web 

ist häufig nur von CFN-Templates die 

Rede, wenn es um den Amazon-Dienst 

geht. De facto ist CloudFormation auch 

die Engine mit den meisten Features. 

Gekrönt wird der Dienst von einer ausführlichen 

Dokumentation, die jede 

einzelne Funktion im Detail erläutert 

und in den Kontext anderer Funktionen 

stellt. 

OpenStack Heat 

Die Amazon-Engine bringt den anderen 

Anbietern von öffentlichen oder auch 

privaten Wolken freilich gar nichts; 

wer eine eigene Cloud betreibt und 

das mit OpenStack tut, hat allerdings 

Glück: Seit OpenStack Havana (2013.2) 

ist Heat fester Bestandteil der Cloud- 

Umgebung – und Heat unterstüzt eine 

große Menge der Funktionen (Abbildung 

2), die CloudFormation ebenfalls 

besitzt. Ein Umbau der Templates 

ist dafür nicht nötig, denn Heat kann 

CloudFormation-Templates wie auch 

Templates im eigenen Format (HOT, 

Heat Orchestration Template) lesen 

und interpretieren. Die Entwickler weisen 

auf ihrer Homepage [1] zwar darauf 

hin, dass Heat noch keine Feature-Parität 

mit CFN erreicht hat, die wichtigen 

Funktionen sind aber samt und sonders 

vorhanden – nicht zuletzt auch deshalb, 

weil die Schaffung eines eigenen 

Template-Formats für Heat anfangs gar 

nicht vorgesehen war. Und selbst HOT 

orientiert sich syntaktisch sehr stark an 

den Amazon-Vorgaben; ein HOT-Template 

lässt sich meist sehr leicht so umbauen, 

dass auch CFN damit zurecht 

kommt. Umgekehrt gilt das auch. Der 

einzige zu bemerkende Unterschied ist 

die Tatsache, dass CFN-Templates XMLbasiert 

sind, während das HOT-Format 

auf JSON setzt. 

n Listing 1: Amazon-CloudFormation-Template (Teil 1) 

Orchestrierte VMs verwalten 

Der Fantasie der Autoren sind im Hinblick 

auf Orchestrierungsmöglichkeiten 

im Grunde keine Grenzen gesetzt; 

durchaus üblich ist es, über ein Template 

eine Reihe von virtuellen Maschinen 

gleichzeitig zu starten. Das bringt 

das Problem mit sich, dass die VM- 

Situation schnell unübersichtlich wird. 

Deshalb setzen die Template-Engines 

von Amazon und OpenStack auf Stacks: 

Sämtliche durch einen einzelnen Template-Aufruf 

gestartete VMs gehören zu 

einem Stack, der anschließend separat 

administriert werden kann. Will man 

also die zuvor im Beispiel gestarteten 

Test-VMs schlagartig wieder beenden, 

01 { 

02 "AWSTemplateFormatVersion" : "2010‐09‐09", 

03 

04 "Description" : "AWS CloudFormation Sample Template EC2InstanceSample: Create 

05 an Amazon EC2 instance running the Amazon Linux AMI. The AMI is chosen based 

06 on the region in which the stack is run. This example uses the default 

07 security group, so to SSH to the new instance using the KeyPair you enter, you 

08 will need to have port 22 open in your default security group. **WARNING** 

09 This template an Amazon EC2 instances. You will be billed for the AWS 

10 resources used if you create a stack from this template.", 

11 

12 "Parameters" : { 

13 "KeyName": { 

14 "Description" : "Name of an existing EC2 KeyPair to enable SSH access to 

15 the instance", 

16 "Type": "String", 

17 "MinLength": "1", 

18 "MaxLength": "255", 

19 "AllowedPattern" : "[\\x20‐\\x7E]*", 

20 "ConstraintDescription" : "can contain only ASCII characters." 

21 } 

22 }, 

23 

24 "Mappings" : { 

25 "RegionMap" : { 

26 "us‐east‐1" : { "AMI" : "ami‐7f418316" }, 

27 "us‐west‐1" : { "AMI" : "ami‐951945d0" }, 

28 "us‐west‐2" : { "AMI" : "ami‐16fd7026" }, 

29 "eu‐west‐1" : { "AMI" : "ami‐24506250" }, 

30 "sa‐east‐1" : { "AMI" : "ami‐3e3be423" }, 

31 "ap‐southeast‐1" : { "AMI" : "ami‐74dda626" }, 

32 "ap‐southeast‐2" : { "AMI" : "ami‐b3990e89" }, 

33 "ap‐northeast‐1" : { "AMI" : "ami‐dcfa4edd" } 

34 } 

35 }, 

36 

37 "Resources" : { 

38 "Ec2Instance" : { 


Know-how 


77 

so ginge das alleine dadurch, den entsprechenden 

Stack herunterzufahren. 

Stacks können durchaus noch mehr: So 

lässt sich bei Amazon festlegen, dass 

die Cloud die Zahl der zu einem Stack 

gehörenden VMs konstant halten soll. 

Selbst wenn in einem solchen Szenario 

dann ein Hypervisor-Host ausfiele und 

verschiedene VMs des Stacks mit in 

den Abgrund reißen würde, kümmerte 

sich die Cloud danach selbst darum, 

dass neue VMs nachgestartet werden. 

Hier ist einer der großen Unterschiede 

zwischen Amazon und OpenStack 

erkennbar, denn Heat kann einen 

Stack zumindest derzeit noch nicht so 

umfangreich und wirksam gegen Ausfälle 

schützen. Die Entwickler arbeiten 

n Listing 1: Amazon-CloudFormation-Template (Teil 2) 

allerdings bereits an passenden Features, 

die vermutlich Teil der nächsten 

OpenStack-Release alias Icehouse sein 

werden. 

39 "Type" : "AWS::EC2::Instance", 

40 "Properties" : { 

41 "KeyName" : { "Ref" : "KeyName" }, 

42 "ImageId" : { "Fn::FindInMap" : [ "RegionMap", { "Ref" : "AWS::Region" 

43 }, "AMI" ]}, 

44 "UserData" : { "Fn::Base64" : "80" } 

45 } 

46 } 

47 }, 

48 

49 "Outputs" : { 

50 "InstanceId" : { 

51 "Description" : "InstanceId of the newly created EC2 instance", 

52 "Value" : { "Ref" : "Ec2Instance" } 

53 }, 

54 "AZ" : { 

55 "Description" : "Availability Zone of the newly created EC2 instance", 

56 "Value" : { "Fn::GetAtt" : [ "Ec2Instance", "AvailabilityZone" ] } 

57 }, 

58 "PublicIP" : { 

59 "Description" : "Public IP address of the newly created EC2 instance", 

60 "Value" : { "Fn::GetAtt" : [ "Ec2Instance", "PublicIp" ] } 

61 }, 

62 "PrivateIP" : { 

63 "Description" : "Private IP address of the newly created EC2 instance", 

64 "Value" : { "Fn::GetAtt" : [ "Ec2Instance", "PrivateIp" ] } 

65 }, 

66 "PublicDNS" : { 

67 "Description" : "Public DNSName of the newly created EC2 instance", 

68 "Value" : { "Fn::GetAtt" : [ "Ec2Instance", "PublicDnsName" ] } 

69 }, 

70 "PrivateDNS" : { 

71 "Description" : "Private DNSName of the newly created EC2 instance", 

72 "Value" : { "Fn::GetAtt" : [ "Ec2Instance", "PrivateDnsName" ] } 

73 } 

74 } 

75 } 

CFN-Templates im Detail 

Welche Möglichkeiten haben Autoren, 

um eigene CFN-Templates zu entwickeln 

und so das Starten spezifischer 

Stacks zu vereinfachen? Jedes CFN- 

Template folgt einer gewissen Grundstruktur. 

Das Beispiel in Listing 1 macht 

deutlich, dass zunächst die Version 

des CFN-Standards anzugeben ist, der 

das Template folgt (ähnlich wie bei 

anderen Dokumenttypen gibt es auch 

von CFN mehrere Releases, sodass die 

Versionsangabe dazu dient, die Kompatibilität 

mit der konkreten Version 

einer Template-Engine sicherzustellen). 

Danach folgt eine kurze Beschreibung 

des Templates. Die Beschreibung besteht 

aus frei wählbarem Text und wird 

später auch bei den Eigenschaften des 

Stacks angezeigt, sobald mit dem Template 

ein solcher gestartet worden ist. 

Dann folgen die Parameter, über die 

sich spezifische Eigenschaften eines 

Stacks steuern lassen (Abbildung 3). Parameter 

gibt es in unterschiedlichen Varianten, 

den spezifischen Typ legt das 

gleichnamige Feld („Type“) fest. Strings 

geben Cloud-Nutzern die Option, beliebige 

Zeichenketten an das Template 

zu liefern; sie sind die am häufigsten 

benutzten Parameter. Das Listing 1 

zeigt, wie sich Parameter einsetzen lassen: 

Über sie bestimmt das Template 

beispielsweise die Hardware-Konfiguration 

der VM („InstanceType“) und 

den Namen des SSL-Schlüssels, den die 

neuen VMs mit auf den Weg bekommen 

(„KeyPairName“). Zudem lassen sich 

auch spezifische Parameter für Images 

bestimmen, die dann direkt an die VMs 

weitergegeben werden und dort zu entsprechenden 

Effekten führen. 

Mappings definieren benutzerspezifische 

Daten unter allgemeinen Labels. 

Beim Starten von VMs in Amazon ist 

es beispielsweise üblich, die Region, 

in der die VM laufen soll, mit anzugeben 

– genauso wie den Kernel, den 

das System verwendet. Durch die 

Mappings der standardisierten Ortsbeschreibungen 

wie „eu-west-1“ auf eine 

Architektur und einen Kernel („64“ : 

„ami-534a2d52“) legen Admins bereits 

im Template fest, welches Image und 

welcher Kern für welche Region zum 

Einsatz kommt. Unbedingt festlegen 

muss der Admin das aber im Template 

nicht; stattdessen kann er Nutzern 

auch die Wahl lassen, selbst ein geeignetes 

Image beim Starten eines Stacks 

auszuwählen. 

Ressoucenbedarf 

Der wichtigste Abschnitt im ganzen 

Template ist zweifellos der Abschnitt, 

der mit »Resources« betitelt ist. 

Denn der legt fest, welche Dienste 

die Engine beim Starten eines Stacks 

in OpenStack aufruft. Von zentraler 


Admin 

Ausgabe 03-2014

78 

Know-how 


Abbildung 3: Auch im Dashboard ist die Heat-Integration bereits vorhanden; der Stack erlaubt 

beim Starten die detaillierte Angabe vieler Parameter. 

n Info 





[1] Heat-Website: [https:// wiki. openstack. org/ 

wiki/ Heat] 

[2] CFN-Dokumentation: [http:// aws. amazon. 

com/ de/ documentation/ cloudformation/] 

[3] HOT-Template-Format: [http:// docs. 

openstack. org/ developer/ heat/ template_ 

guide/ hot_guide. html] 

n Autor 

Martin Gerhard Loschwitz arbeitet als Principal 

Consultant bei hastexo. Er beschäftigt sich dort intensiv 

mit den Themen HA, Distributed Storage und 

OpenStack. In seiner Freizeit pflegt er Pacemaker für 

Debian. 

Bedeutung ist an dieser Stelle insbesondere 

»AWS:EC2:Instance«, das 

eine neue virtuelle Maschine startet. 

Anwender können bei diesem Vorgang 

Metadaten angeben, welche die VMs 

per HTTP-Request anschließend vom 

Cloud-Metadaten-Server abfragen. Metadaten 

sind im Cloud-Kontext ein sehr 

wichtiges Werkzeug – interpretiert die 

VM sie wie gewünscht, dann lässt sich 

über Metadaten das Verhalten von VMs 

noch steuern, nachdem sie gebootet 

wurden. 

Am Ende des Templates findet sich 

der »Outputs«-Absatz; dieser legt fest, 

welche Eigenschaften des Stacks die 

Template-Engine für die einzelnen VMs 

exponiert, also gesondert anzeigt und 

beispielsweise auch abfragbar macht. 

Im vorliegenden Beispiel lassen sich 

alle Features, die der Admin den VMs 

beim Start mit auf den Weg gegeben 

hat, zu jedem späteren Zeitpunkt über 

die Engine auch wieder in Erfahrung 

bringen. 

Das dargestellte Template würde 

schließlich Windows-Instanzen starten; 

es handelt sich allerdings nur um ein 

generisches Beispiel und nahezu jede 

andere Kombination wäre denkbar. 

Auch geht das Beispiel nicht auf die 

Möglichkeiten ein, die sowohl Amazon 

als auch OpenStack Heat sonst noch so 

bieten: Wer in VMs mit Linux spezifische 

Pakete nach dem Booten installieren 

möchte, kann über einen entsprechenden 

Absatz im Template beliebige 

Shell-Befehle ausführen. Das ist nicht 

selten deutlich komfortabler als die 

Arbeit mit dem Metadaten-Server. 

Auch die zuvor bereits erwähnten 

Skalierbarkeitsparameter wertet das 

Beispiel nicht aus – für die wäre im 

Template ebenfalls ein eigener Absatz 

fällig. Auch im »Resources«-Absatz sind 

Erweiterungen fast beliebig denkbar; 

CFN stellt viele Funktionen zur Verfügung, 

darunter eine, die einer neu 

gestarteten VM direkt eine öffentliche 

IP-Adresse umhängt – oder die festlegt, 

welches Tenant-Netz ein zu startender 

Stack verwenden soll. Eine umfassende 

Übersicht über die in CFN vorgesehenen 

Funktionen und Parameter bietet 

die AWS-CFN-Dokumentation auf [2]. 

Die meisten der dort vorgestellten Befehle 

funktionieren auch in Heat, das 

eine eigene Dokumentation unter [3] 

anbietet. 

Fazit 

Orchestrierung füllt die Lücke, die Automatisierungswerkzeuge 

in der Cloud 

nicht schließen konnten. Wer den 

Einsatz von Ressourcen in einer Cloud 

plant oder selbst eine Cloud betreibt, 

der sollte sich mit dem Thema Orchestrierung 

jedenfalls sehr genau befassen. 

Kein anderer Ansatz ist effizienter, um 

in der Praxis Arbeitsschritte einzusparen. 

Der vorliegende Artikel kann die 

Vielfalt der Optionen im Orchestrierungskontext 

nur andeuten, de facto 

sind die Möglichkeiten nahezu unbeschränkt. 

Und neue Features kommen 

stetig hinzu, sowohl bei Amazon als 

auch bei OpenStack Heat. Langweilig 

wird die Sache in nächster Zeit jedenfalls 

nicht. (jcb) n 


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

80 

Security 

UEFI-Secure-Boot 

Eugenio Marongiu, 123RF 

UEFI-Secure-Boot und alternative Betriebssysteme 

Einlasskontrolle 

Ist es ein nützliches Sicherheitsfeature oder ein Mechanismus, um freie Betriebssysteme auszubremsen? 

An UEFI-Secure-Boot scheiden sich die Geister. Aber wie schwierig ist es wirklich, in einer UEFI-Umgebung 

ein gängiges Linux zu booten? Hendrik Schwartke, Ralf Spenneberg 

Für das Booten eines Computers war 

in der Vergangenheit das BIOS zuständig: 

Es übernahm die Initialisierung 

und den Start des Betriebssystems. 

Viele moderne Rechner verwenden 

aber inzwischen anstelle des BIOS die 

UEFI-Firmware. Das Unified Extensible 

Firmware Interface (UEFI) unterstützt 

eine einfache Erweiterung der Firmware 

durch unterschiedlichste Module. 

Dazu gehören zum Beispiel ein 

eingebettetes Netzwerkmodul für die 

Fernwartung, Module für Digital Rights 

Management und die BIOS-Emulation 

mit dem Compatibility Support Module 

(CSM). UEFI kennt zudem einen Secure- 

Boot-Mechanismus. Die Secure-Boot- 

Technologie prüft in diesem Fall, ob der 

Bootloader mit einem kryptographischen 

Schlüssel signiert ist, den eine 

in der Firmware enthaltene Datenbank 

autorisiert. Durch die Kontrolle der Signatur 

des Bootloaders, des Kernels und 

möglicherweise weiteren Userspace- 

Codes wird die Ausführung unsignierter 

Software unterbunden. 

Windows 8 ist das erste Betriebssystem, 

das diese Funktion nutzt. Damit 

kann es die Ausführung von Schadcode 

verhindern. Allerdings kann der Eigentümer 

des Rechners nun nicht mehr frei 

entscheiden, welches Betriebssystem 

er installieren kann. 


UEFI-Secure-Boot validiert den Bootvorgang. 

Die UEFI-Spezifikation 2.3 

definiert dafür die folgenden Komponenten 

und Verfahren: 

n eine Programmierschnittstelle für 

den Zugriff auf kryptographisch 

geschützte UEFI-Variablen im Flash- 

Speicher, 

n ein Format zum Speichern von 

X.509-Zertifikaten in UEFI-Variablen, 

n ein Verfahren zur Validierung des 

Bootloaders und der Treiber mithilfe 

von AuthentiCode-Signaturen, 

n einen Mechanismus für den Widerruf 

(Revocation) kompromittierter Zertifikate 

und Signaturen. 

UEFI-Secure-Boot unterscheidet die in 

Tabelle 1 aufgelisteten Schlüssel (Abbildung 

1). 

Des Weiteren beschreibt die Spezifikation 

zwei Modi, in denen sich Secure 

Boot befinden kann. Der Erste ist der 

Setup Mode. Eine UEFI-Firmware, deren 

Secure-Boot-Implementierung in 

diesem Modus betrieben wird, schützt 

die Zertifikatsspeicher nicht vor Manipulation. 

Es ist insbesondere möglich, 

aus einem laufenden Betriebssystem 

heraus Zertifikate als auch Hashes in 

die UEFI-Zertifikatsspeicher einzufügen 

oder zu entfernen. Dieser Modus dient 

primär zur Einrichtung von Secure 

Boot. 

Zweitens existiert der User Mode. 

Befindet sich eine Secure-Boot-Implementierung 

im User Mode, so ist eine 

Manipulation der Zertifikatsspeicher 


Security 


81 

nur sehr eingeschränkt möglich. Insbesondere 

sind Änderungen ohne 

Authentifizierung aus einem laufenden 

Betriebssystem nicht mehr durchführbar. 

Zur Veränderung des db- oder 

dbx-Zertifikatsspeichers ist eine Autorisierung 

mittels des privaten Schlüssels 

eines im KEK-Speicher hinterlegten 

Zertifikats nötig. Zur Änderung des 

KEK- und PK-Speichers bedarf es hingegen 

des privaten Schlüssels des hinterlegten 

Plattform-Key-Zertifikats. 

Der Wechsel vom User Mode in den 

Setup Mode ist zum einen durch das 

Entfernen des Plattform Keys möglich. 

Dies setzt die Kenntnis des privaten 

Schlüssels des installierten Plattform 

Keys voraus. Alternativ kann mittels 

des UEFI-Setups in den Setup Mode gewechselt 

werden. Dabei ist der Zugang 

zur Hardware und gegebenenfalls die 

Kenntnis von Kennwörtern zur Nutzung 

des Setups Voraussetzung. 

UEFI-Secure-Boot verhindert nicht die 

Installation von Malware oder die Modifikation 

des Bootloaders, sondern stellt 

dessen Vertrauenswürdigkeit während 

des Bootvorgangs sicher. Kann die 

Vertrauenswürdigkeit nicht festgestellt 

werden, so wird das Booten unterbunden 

(vereinfacht in Abbildung 2). 

Secure Boot mit Windows 

Microsoft unterstützt Secure Boot ab 

Windows 8. Jedoch ist Secure Boot 

keine zwingende Voraussetzung für die 

Funktionstüchtigkeit des Betriebssystems. 

Ältere Microsoft-Betriebssysteme 

können auf einem System mit aktiver 

Secure-Boot-Funktion nicht eingesetzt 

n Tabelle 1: Secure-Boot-Keys 

Schlüssel 

Platform Key (PK) 

Key Exchange Key (KEK) 

Autorisierte DB (db) 

Nicht autorisierte DB (dbx) 

werden, weil Microsoft für diese noch 

keine signierten Bootloader bereitstellt. 

Hardware-Hersteller, die ihre Systeme 

mit dem Windows-8-Logo ausstatten 

möchten, müssen jedoch UEFI-Secure- 

Boot unterstützen und diese Funktion 

im Auslieferungszustand aktivieren. 

Daher müssen diese Systeme auch 

über das notwendige Schlüsselmaterial 

in der UEFI-Firmware verfügen. 

Hierzu gehört mindestens das 

Microsoft-Windows-Production-PCA- 

2011-Zertifikat, das von Microsoft für 

die Signatur eigener Produkte genutzt 

wird. Die Hardware-Hersteller dürfen 

weitere Microsoft-Zertifikate – wie das 

Microsoft-Corporation-UEFI-CA-2011- 

Zertifikat – und eigene Zertifikate in 

den UEFI-Speicher ablegen. 

UEFI-Secure-Boot wird bisher hauptsächlich 

auf Client-Systemen eingesetzt. 

Zukünftige Microsoft-Betriebssysteme 

werden diese Technologie jedoch 

wahrscheinlich auch auf Serversystemen 

zur Verfügung stellen oder deren 

Nutzung sogar erzwingen. 

Secure Boot mit Linux 

Um Secure Boot auch mit anderen Betriebssystemen 

nutzen zu können, stehen 

grundsätzlich drei Möglichkeiten 

zur Verfügung: 

n Signieren der eigenen Bootloader 

durch Microsoft. 

n Hinterlegen eines eigenen KEK- 

Schlüssels durch den Hardware-Hersteller. 

Offenbar verfügt jedoch kein 

weiterer Betriebssystemanbieter 

über die entsprechende politische 

Funktionen 

Meist ein Schlüssel des Hardware-Herstellers (OEM), PK erlaubt 

die Manipulation der KEK, nur ein einziger PK möglich. 

Mehrere Zertifikate möglich, unterschiedliche Schlüssel für 

unterschiedliche OS-Anbieter möglich, zum Beispiel: Microsoft 

KEK CA; KEK erlaubt die Manipulation der db und 

dbx. 

Mehrere Zertifikate und Hashes möglich, zum Beispiel: Microsoft 

Windows Production CA; zur Identifizierung von vertrauenswürdigem 

Code. 

Mehrere Zertifikate oder Hashes möglich; zur Identifizierung 

von kompromittiertem Code oder Schadcode. 

Abbildung 1: Diese Schlüssel können am Secure- 

Boot-Prozess beteiligt sein. 

Marktmacht, um die Hardware- 

Hersteller flächendeckend von der 

Installation weiterer KEK-Schlüssel 

überzeugen zu können. 

n Erzeugen eines eigenen Platform 

Key (PK) und Hinterlegen in der 

UEFI-Firmware. Durch den Austausch 

des Platform Keys wird ein 

Zugriff auf alle weiteren Zertifikatsspeicher 

möglich. Das Ersetzen eines 

Platform Keys bedingt jedoch physischen 

Zugang zum System. 

Alle von uns untersuchten Betriebssysteme, 

die Secure Boot unterstützen, 

schlagen den ersten Weg ein. Damit ist 

die Installation ihrer Bootloader auf 

einem System mit aktivem Secure Boot 

und installierten Microsoft-Schlüsselmaterial 

möglich. Hierzu bietet Microsoft 

einen Signaturdienst an, der 

ursprünglich nur für die Signatur von 

UEFI-Treibern vorgesehen war. Er 

wurde auch auf alternative Bootloader 

von Drittanbietern erweitert. Dazu sendet 

der Drittanbieter seinen Bootloader 

an Microsoft. Die Firma prüft den 

Bootloader und sendet ihn mit einer 

AuthentiCode-Signatur zurück. Die 

Signatur bestätigt nicht den Urheber, 

sondern lediglich die Unversehrtheit 

des Bootloaders. 

Die Signatur erfolgt mit dem Zertifikat 

Microsoft Corporation UEFI CA 2011. 

Daher ist die Funktionsfähigkeit des 


Admin 

Ausgabe 03-2014

82 

Security 


Bootloaders nicht auf jeder Hardware 

garantiert, denn dieses Zertifikat muss 

nach Microsoft-Spezifikation nicht installiert 

sein. 

Durch das Signieren des Bootloaders 

durch Microsoft bestehen grundsätzlich 

zwei Gefahren bei dem Einsatz in der 

Produktion: 

n Microsoft kann das Zertifikat widerrufen. 

Würde das Zertifikat durch 

Software-Updates in die Revocation- 

Abbildung 2: So läuft der Secure-Boot-Vorgang ab. Kann sich der 

Bootloader nicht als vertrauenswürdig ausweisen, wird das System 

nicht gestartet. 

Lists in der UEFI-Firmware gelangen, 

erlaubt die Firmware die Nutzung 

des entsprechenden Bootloaders 

nicht mehr. 

n Die Signatur ist nur für eine bestimmte 

Zeit gültig. Die UEFI- 

Firmware kann den signierten 

Bootloader nach Ablauf der Signatur 

ablehnen und den Bootvorgang abbrechen. 

Wird nicht erneut signiert, 

kann das System nicht mehr booten. 

Shim 

Beim abgesicherten Booten 

mithilfe des Signierdienstes 

von Microsoft 

wird typischerweise der 

Bootloader Shim eingesetzt. 

Bei Shim handelt 

es sich um einen einfach 

strukturierten Open- 

Source-Bootloader. Er 

startet indirekt Bootloader, 

die nicht von 

Microsoft signiert sind. 

Shim kann somit als 

Bindeglied zwischen der 

von Microsoft geprägten 

Secure-Boot-Umgebung 

und Betriebssystemen 

Dritter eingesetzt werden 


Ermöglicht wird dies unter 

anderem durch eine 

öffentlich zugängliche 

Shim-Version, die von 

Microsoft mittels des 

Zertifikats Microsoft Corporation 

UEFI CA 2011 

signiert ist. Aufgrund dieser 

Signatur kann Shim 

von allen untersuchten 

Hardwareplattformen 

mittels des jeweiligen 

Standardschlüsselmaterials 

mit aktivierten 

Secure Boot gestartet 

werden. Ferner installieren 

einige Linux-Systeme 

wie etwa Ubuntu 13.04 

und Fedora 19 alternative 

Versionen von Shim, 

die ebenfalls von Microsoft 

signiert sind. 

Shim überprüft die 

Signatur des nächsten 

Bootloaders, der zu laden ist. Das 

Schlüsselmaterial für diese Verifizierung 

kann hierbei aus drei Quellen 

stammen: 

n Den UEFI-Zertifikatsspeichern db 

und dbx, 

n der Machine Owner Key List (Mok- 

List): einem Shim-eigenen Zertifikatsspeicher, 

n einem im Shim-Binary hinterlegten 

Zertifikat oder Hash. 

Die MokList kann sowohl Zertifikate als 

auch Hashes speichern. Die Nutzung 

von Zertifikaten bedingt die Signierung 

des zweiten Bootloaders. Die MokList 

wird zwar ebenso wie die UEFI-spezifischen 

Zertifikatsspeicher im NVRAM 

der UEFI-Firmware gespeichert, sie ist 

jedoch zumindest während des Bootvorgangs 

typischerweise ohne Authentifizierung 

modifizierbar. 

Weil sich Zertifikate direkt in der Binärdatei 

von Shim hinterlegen lassen, 

kann der Verifizierungsvorgang unabhängig 

vom Inhalt der Zertifikatsspeicher 

sein. Diesen Weg wählen die 

Linux-Distributionen Ubuntu 13.04 und 

Fedora 19. 

Ist die Verifizierung des zweiten Bootloaders 

– typischerweise Grub2 – erfolgreich, 

so wird er ausgeführt. Schlägt 

sie dagegen fehl, so wird die zu Shim 

gehörende Anwendung MokManager 

aufgerufen. Der MokManager ermöglicht 

es dem Anwender, interaktiv 

Zertifikate oder Hashes in die MokList 

einzufügen und somit die Ausführung 

des zweiten Bootloaders zu erlauben. 

Analyse 

Da die Secure-Boot-Technologie 

weitreichende Auswirkungen auf die 

Installation von alternativen Betriebssystemen 

in Stand-Alone- und Dual- 

Boot-Umgebungen hat, haben die 

Autoren des vorliegenden Artikels die 

Möglichkeiten und Probleme in diesen 

Umgebungen analysiert. 

Erstes Ziel war die Analyse der in der 

UEFI-PreBoot-Umgebung hinterlegten 

Module, Schlüssel und Variablen 

und ihren Einfluss auf den Start des 

Betriebssystems. Betrachtungsgegenstand 

waren je eine 64-Bit-x86- 

kompatible Plattform der Hersteller HP, 

Dell, Lenovo und Medion. Anschließend 


Security 


83 

wurde die Einflussmöglichkeit des 

Eigentümers einer solchen Hardware- 

Plattform auf das durch Secure Boot 

kontrollierte Bootverfahren untersucht. 

Hierbei standen besonders die folgenden 

Fragen im Vordergrund: 

n Kann der Anwender Secure Boot 

deaktivieren? 

n Kann der Anwender alternatives 

Schlüsselmaterial in der UEFI-Firmware 

hinterlegen? 

n Welche Möglichkeiten bietet der 

Hardware-Hersteller für die Modifikation 

des Schlüsselmaterials? 

Darüber hinaus wurde untersucht, 

inwieweit sich die Betriebssysteme 

Windows 8 Pro, Red Hat Enterprise 

Linux 6.4, Ubuntu 13.04, Debian 7.1.0 

und Fedora 19 bei aktivem Secure Boot 

installieren und nutzen lassen. Gegebenenfalls 

wurden Anpassungsschritte 

erarbeitet, um das jeweilige Betriebssystem 

zusammen mit Secure Boot 

benutzen zu können. 

Abschließend wurde der Einsatz 

von Secure Boot in einer Dual-Boot- 

Umgebung bestehend aus Windows 

8 Pro und Debian 7.1.0 untersucht. 

Hier wurde unter anderem analysiert, 

wie Änderungen an der Secure-Boot- 

Konfiguration durch ein Betriebssystem 

unterbunden werden können und wie 

ausgeschlossen werden kann, dass sich 

die Betriebssysteme untereinander 

beeinflussen. 

Hardware-Plattformen 

Alle untersuchten Systeme ermöglichen 

die Veränderung der Zertifikatsspeicher, 

die dem Secure-Boot-Vorgang 

zugrunde liegen. Dazu ist aber oft zusätzliche 

Software nötig, etwa die unter 

einer freien Lizenz stehenden EFI-Tools. 

Mittels des UEFI-Setups können bei 

allen Systemen die ursprünglich vom 

Hersteller ausgelieferten Schlüssel in 

den Zertifikatsspeicher geladen werden 

und so in den vom Hersteller definierten 

Ausgangszustand versetzt werden. 

Auch ermöglicht das UEFI-Setup in 

allen Fällen den Wechsel in den Setup- 

Mode und somit eine anschließende 

Modifizierung der Zertifikatsspeicher. 

Das gezielte Einfügen oder Entfernen 

einzelner Zertifikate oder Hashes 

mithilfe des UEFI-Setups ermöglichte 

jedoch nur das System von Dell. Bei 

allen Rechnern war es aber zumindest 

möglich, die Zertifikatsspeicher im 

Setup Mode mittels der EFI-Tools zu 

modifizieren. 

Darüber hinaus boten alle Systeme die 

Möglichkeit, Secure Boot zu deaktivieren. 

Ferner lieferten alle Hersteller der 

untersuchten Systeme die durch die 

Windows Hardware Certification Requirements 

vorgeschriebenen Zertifikate 

einschließlich des optionalen Zertifikats 

Microsoft Corporation UEFI CA 

2011 mit. Einige Hersteller installierten 

darüber hinaus eigene Zertifikate. 

Die auf der EFI-Partition vorinstallierte 

Software beschränkt sich im Wesentlichen 

auf Diagnose-Software der Hersteller. 

Auf allen zur Verfügung gestellten Systemen 

ist der Anwender somit in der 

Lage, auf die Secure-Boot-Funktionalität 

Einfluss zu nehmen. Er kann Secure 

Boot deaktivieren, in den Setup Modus 

versetzen und eigenes Schlüsselmaterial 

laden. Hierzu kann er teilweise 

die Werkzeuge aus dem UEFI-Setup 

nutzen. In den meisten Fällen muss 

jedoch auf weitere Werkzeuge, wie zum 

Beispiel die EFI-Tools, zurückgegriffen 

werden. 

Praxistest 

Um zu überprüfen, inwieweit aktuelle 

Betriebssysteme unter Nutzung von 

Secure Boot auf den ausgewählten 

Hardware-Plattformen lauffähig sind, 

wurden sie auf jeder Plattform testweise 

installiert. Es wurde ferner überprüft, 

ob das System nach der Installation 

ordnungsgemäß startet und somit 

grundsätzlich funktionstüchtig ist. 

Sofern das jeweilige Betriebssystem 

Secure Boot unterstützt, haben wir 

dessen Umsetzung analysiert. Ist 

eine Unterstützung von Secure Boot 

nicht gegeben, so wurden zusätzliche 

Schritte geprüft, die das System bei aktivem 

Secure Boot einsetzbar machen. 

Hierbei steht die Funktionstüchtigkeit 

im Vordergrund. Auf eine weitergehende 

Beurteilung wird verzichtet. Die 

getesteten Betriebssysteme sind: 

n Microsoft Windows 8 Pro 

n Red Hat Enterprise Linux 6.4 

n Ubuntu 13.04 

Abbildung 3: So läuft das Booten ab, wenn der Open- 

Source-Bootloader Shim im Spiel ist. 

n Debian 7.1.0 

n Fedora 19 

n FreeBSD 9.2 

Ergebnisse 

Trotz der relativ neuen Technik und der 

umfangreichen Spezifikation arbeitet 

Secure Boot auf allen untersuchten 

Plattformen mit den eingesetzten Betriebssystemen 

zusammen. Das Starten 

einer signierten UEFI-Anwendung wie 

etwa eines Bootloaders funktioniert, 

sofern das entsprechende Zertifikat in 

dem db-Zertifikatsspeicher der UEFI- 

Firmware enthalten ist. Auch wird der 

Start einer solchen Anwendung verweigert, 

sofern kein passendes Zertifikat in 

diesem Zertifikatsspeicher vorhanden 

ist. Ebenso funktioniert die Verifikation 

von UEFI-Anwendungen anhand von 

Hashes problemlos. 

Ferner ist die Installation und der Betrieb 

der Betriebssysteme Windows 8 

Pro, Ubuntu 13.04 und Fedora 19 bei 

aktiviertem Secure Boot möglich. Die 

ebenfalls untersuchten Betriebssys- 


Admin 

Ausgabe 03-2014

84 

Security 


teme Red Hat Enterprise Linux 6.4, 

FreeBSD 9.2 und Debian 7.1.0 unterstützen 

Secure Boot nicht und werden 

daher bei deaktiviertem Secure Boot 

installiert. Sie lassen sich jedoch mit 

relativ geringem Aufwand so modifizieren, 

dass sie auch bei aktivem Secure 

Boot laufen können. 

Bei der Integration von Secure Boot 

und dem daraus resultierenden Gewinn 

an Sicherheit gibt es jedoch gravierende 

Unterschiede. Ebenso ist der 

Sicherheitsgewinn bei dem Einsatz von 

Ubuntu 13.04 gering. Zwar werden die 

Bootloader verifiziert, eine effektive 

Überprüfung des Kernels samt seiner 

Module findet jedoch nicht statt. 

Im Gegensatz hierzu findet bei Fedora 

19 nicht nur eine Verifikation der Bootloader, 

sondern auch des Kernels und 

seiner Module statt. 

FreeBSD plant eine ähnliche Umsetzung, 

wie sie bereits Fedora nutzt. 

Wenngleich Windows 8 Pro ebenfalls 

eine Überprüfung des Bootloaders 

und des Kernels durchführt, ist eine 

Beurteilung der Effektivität der Schutzmaßnahmen 

erheblich schwieriger als 

bei den untersuchten Linux-Systemen. 

Grund ist hierfür hauptsächlich das 

komplexe Vorgehen zur Verifikation von 

nachträglich zu ladenden Kernelkomponenten 

wie zum Beispiel Treibern. 

Microsoft setzt hier zur Erkennung von 

Schadsoftware auf eine Zusammenarbeit 

des Kernels mit Anti-Malware- 

Produkten. 

Die Effektivität der Schutzfunktionen 

hängt daher ganz erheblich von der 

Qualität des eingesetzten Produktes 

ab. Auch wird die von Microsoft neu 

eingeführte ELAM-Technik im Rahmen 

dieser Arbeit auf Grund ihrer Komplexität 

nicht bewertet. Ferner bieten die 

nachfolgend für Debian 7.1.0 aufgeführten 

Änderungen, die analog für 

Red Hat Enterprise 6.4 und FreeBSD 

9.2 durchgeführt werden können, nur 

einen geringen Sicherheitsgewinn. Die 

Ergebnisse dieser Tests sind in Tabelle 2 

zusammengefasst. 

Mit eigenen Schlüsseln 

Im Folgenden wird gezeigt, wie Debian 

7.1.0 in einer Dual-Secure-Boot-Umgebung 

neben Windows 8 Pro installiert 

und konfiguriert werden kann. Das 

Debian-System soll hierbei unabhängig 

von den Zertifikaten der Firma 

Microsoft bei aktivem Secure Boot betriebsfähig 

sein. Die Betriebsfähigkeit 

von Windows 8 Pro soll hierdurch nicht 

beeinträchtigt werden. Keines der beiden 

Systeme soll die UEFI-Zertifikatsspeicher 

modifizieren können. 

Sofern die Installation der Betriebssysteme 

erfolgreich abgeschlossen ist, 

muss der Bootloader des Debian-Systems 

signiert oder dessen Hash in den 

db-Zertifikatsspeicher eingetragen werden. 

Das hätte aber einen wesentlichen 

Nachteil: Kommt es zu einem Update 

des Bootloaders, so fehlt diesem eine 

gültige Signatur beziehungsweise der 

Hash wird ungültig. Dadurch würden 

nachfolgende Bootvorgänge scheitern. 

Aus diesem Grund wird ein Secure- 

Boot-Preloader genutzt, der durch die 

Befehle aus Listing 1 installiert wird. 

Im Anschluss hieran wird der Secure- 

Boot-Loader signiert. Dazu dient das 

Werkzeug »sbsign«, das zu der Werkzeugsammlung 

»sbsigntools« gehört. 

Durch Ausführung des Befehls 

sbsign ‐‐key db.key ‐‐cert db.pem.crtU 

/boot/efi/EFI/debian/U 

secure‐boot‐preloader.efi 

wird der Secure-Boot-Loader signiert. 

Hierbei wird davon ausgegangen, dass 

der private Schlüssel, der zur Signierung 

von UEFI-Anwendungen verwendet 

werden soll, in der Datei »db.key« 

enthalten ist und dass das zugehörige 

Zertifikat in der Datei »db.pem.crt« vorliegt. 

Der Signierungsschritt sollte zur 

Sicherheit des privaten Schlüssels nicht 

auf dem betroffenen System selbst, 

sondern in einer sicheren Arbeitsumgebung 

stattfinden. 

Nach erfolgreicher Einrichtung des 

Bootloaders werden die Zertifikatsspeicher 

der UEFI-Firmware gezielt 

modifiziert. Die Modifikation wird mittels 

der EFI-Tools durchgeführt. Hierzu 

wird das zugehörige USB-Image zum 

Beispiel mithilfe des Kommandos »dd« 

auf einen USB-Stick übertragen. Im 

Anschluss wird sowohl das Zertifikat 

Microsoft Windows Production PCA 

2011 als auch die zum eigenen Schlüsselmaterial 

zugehörigen Schlüssel (PK, 

KEK, db) in ein Format umgewandelt, 

das von der UEFI-Firmware verarbeitet 

werden kann. Dazu dient der Befehl 

»cert‐to‐efi‐sig‐list«, der Bestandteil der 

EFI-Tools ist. 

Nun wird das Secure-Boot-System der 

zu konfigurierenden Plattform über das 

UEFI-Setup in den Setup Mode versetzt, 

um die Modifikationen der Zertifikatsspeicher 

durchführen zu können. Das 

genaue Vorgehen hierzu ist plattformspezifisch. 

Hiernach wird von dem vorbereiteten 

USB-Stick gebootet. Mittels der sich öffnenden 

UEFI-Shell wird durch Eingabe 

der folgenden Befehle das Werkzeug 

»keytool« gestartet. Es stellt eine rudimentäre 

textbasierte Oberfläche zur 

Modifikation der UEFI-Zertifikatsspeicher 


n Tabelle 2: Testresultate 

Windows 8 Pro Red Hat Enterprise 

Linux 6.4 

Debian 

7.1.0 

FreeBSD 

9.2 

Ubuntu 

13.04 

Fedora 

19 

Wird Secure Boot im Betrieb unterstützt? Ja Nein Nein Nein Ja Ja 

Wird Secure Boot bei der Installation unterstützt? 

Ja Nein Nein Nein Ja Ja 

Ist eine nachträgliche Unterstützung - Ja Ja Ja - - 

durch Shim möglich? 

Effektiver Umfang der Verifikationskette Bootloader, 

Kernel (bedingt) 

Shim Shim Shim Shim, Grub Shim, Grub2, Kernel, 

Kernelmodule 


Security 


85 

fs0: 

cd EFI 

cd BOOT 

KEYTOOL.EFI 

Über den Menüpunkt »Edit Keys« wird 

ein Untermenü geöffnet, welches es 

ermöglicht, die Zertifikatsspeicher PK, 

KEK, db, dbx und MokList wie folgt zu 

modifizieren: 

MokList: Alle eventuell vorhandenen 

Zertifikate und Hashes entfernen. 

db: Alle eventuell vorhandenen Zertifikate 

und Hashes entfernen, Zertifikat 


2011 einfügen. Eigenes Zertifikat zur 

Sig nierung von UEFI-Anwendungen einfügen. 

Alternativ kann auch ein Hash 

des Bootloaders eingefügt werden. 

dbx: Keine Änderungen notwendig. 

KEK: Alle eventuell vorhandenen Zertifikate 

und Hashes entfernen, eigenes 

Zertifikat des KEK einfügen. 

PK: Zertifikat des eigenen Plattform- 

Keys einsetzen.- 

Hierbei ist zu beachten, dass die Modifikation 

des PK-Zertifikatsspeichers 

der letzte Arbeitsschritt sein muss, da 

durch das Einbringen eines Plattform- 

Keys der Setup Mode verlassen und in 

den User Mode gewechselt wird. Eine 

nachträgliche Manipulation der Zertifikatsspeicher 

ist dann nur noch über 

signierte Updates oder durch Löschen 

des Plattform-Keys mithilfe des UEFI- 

Setups möglich. Nach diesem Schritt 

kann Debian bei aktiviertem Secure 

Boot gestartet werden. 

Fazit 

Abschließend lässt sich festhalten, 

dass die UEFI-Implementierungen der 

untersuchten Plattformen in Bezug 

auf die Umsetzung von Secure Boot – 

soweit dies dieser Artikel untersucht 

hat – getreu der Spezifikation funktionieren. 

Das durch Microsoft im Rahmen 

des Windows Hardware Certification 

Program vorgeschriebene Zertifikat 


2011 wie auch das optionale Zertifikat 

Microsoft Corporation UEFI CA 2011 

liefern alle untersuchten Hardware- 

Plattformen aus. Insbesondere durch 

Letzteres wird die Funktionstüchtigkeit 

von Betriebssystemen, die nicht von 

Microsoft bereitgestellt werden, bei 

aktiviertem Secure Boot grundsätzlich 

ermöglicht. 

Des Weiteren unterstützen viele aktuelle 

Betriebssysteme wie Windows 

8 Pro, Ubuntu 13.04 und Fedora 19 

Secure Boot bereits. Die typische 

Installation dieser Systeme erzeugt 

einen mehr oder weniger umfassenden 

Schutz durch Secure Boot. Die 

untersuchten Betriebssysteme, welche 

Secure Boot von Haus aus nicht unterstützen, 

konkret Debian 7.0.1 und Red 

Hat Enterprise Linux 6.4, können mit 

geringem Aufwand auf allen untersuchten 

Hardware-Plattformen bei aktiviertem 

Secure Boot lauffähig gemacht 

werden. 

Secure Boot besitzt das Potenzial, ein 

System effektiv vor unautorisierten 

Manipulationen zu schützen und die 

Sicherheit des Systems deutlich zu erhöhen. 

Wenngleich für einen umfassenden 

Schutz eines IT-Systems weitere 

Maßnahmen erforderlich sind und es 

einige Herausforderungen bei der Einführung 

von Secure Boot gibt, ermöglicht 

Secure Boot dem Eigentümer die 

Hoheit über sein IT-System zu bewahren. 

Dabei bieten sich dem Anwender 

bei handelsüblichen IT-Plattformen in 

der Regel keine alternativen Methoden 

zur Absicherung des Bootprozesses, 

die ähnlich effektiv eingesetzt werden 

könnten. 

Eine weitere Stärke von Secure Boot 

ist, dass der Eigentümer des IT-Systems 

entscheiden kann, welche konkreten 

Schutzmaßnahmen er für das jeweilige 

System umsetzt. Dadurch ist es ihm 

möglich, das Verhältnis des Arbeitsaufwandes 

zum erzielten Sicherheitsgewinn 

zu optimieren. Darüber hinaus 

kann er individuelle Sicherheitslösungen 

erstellen. 

Ein wesentlicher Nachteil des Einsatzes 

von Secure Boot besteht darin, 

dass zwingend UEFI verwendet werden 

muss. Mit Blick auf die Sicherheit 

UEFI-kompatibler Firmware gibt es 

bislang noch wenig praktische Erfahrung. 

Es besteht also durchaus die 

gefahr, dass ein potenzieller Sicherheitsgewinn, 

der durch Secure Boot 

ermöglicht wird, durch (gewollte und 

ungewollte) Implementierungsfehler 

n Listing 1: Preloader erstellen 

01 # Erstellen der Konfigurationdatei des 

Secure‐Boot‐Preloaders 

02 cat

Fedora 20 angeschaut 

Schrittmacher 

Denis Babenko, 123RF 

Die neueste Fedora-Version „Heisenbug“ lag nur wenige Tage nach dem offiziellen zehnten Geburtstag 

gerade noch rechtzeitig unterm Weihnachtsbaum. Radikale Umbauten erlauben Fedora-Nutzern einen 

Blick in eine mögliche Linux-Zukunft. Dabei ist ein näherer Blick auf den Technologie-Vorreiter nicht nur 

für Red-Hat-Admins empfehlenswert. Thomas Drilling 

Fedora 20 (Heisenbug) ist dem nach 

einem Unfall im Juli verstorben Red- 

Hat-Entwickler Seth Vidal gewidmet. 

Es ist zwar nicht die Linux-Distribution 

mit der größten Verbreitung, sie 

spielt aber eine wichtige Rolle im 

Linux-Ökosystem, denn keine andere 

Linux-Variante bietet mit jedem neuen 

Release so viele neue Technologien. Fedora 

ist aber nicht nur ein Testbett für 

Red Hat Enterprise Linux, sondern setzt 

in der Regel wichtige Impulse für die 

gesamte Branche. Admins und System- 

Integratoren sollten daher einen Blick 

auf die neue Fedora-Version [1] werfen, 

insbesondere was die Funktionen aus 

den Bereichen Server, Cloud und Virtualisierung 

betrifft. 

Fedora 20 lässt sich in verschiedenen 

Varianten beziehen, etwa als Installations-DVD, 

als installierbare Live-CD 

mit Standard-Gnome-Desktop sowie in 

Form verschiedener Live-Medien und 

in den Spin-Varianten mit KDE-, LXDEsowie 

XFCE-Desktop. Ferner stehen alle 

Versionen in der vollständigen Repo- 

Übersicht zur Verfügung – seit Fedora 

19 übrigens auch als virtuelle Images 

im Raw- und QCOW2-Format, die sich 

unter anderem direkt in RHEV, Virtual- 

Box, AWS und OpenStack verwenden 

lassen. 

Desktop und 

Paketverwaltung 

Fedora 20 bootet dank Systemd, bei 

dem im Gegensatz zum klassischen 

Sys-V-Init sämtliche Prozesse soweit 

möglich gleichzeitig starten, sehr zügig. 

Wie bei Red Hat Enerprise Linux und 

Fedora üblich ist SELinux aktiviert. 

Das spürt man im Alltag zwar nicht, 

Admins, die sich erstmals mit Fedora 

befassen, sollten die Tatsache aber im 

Hinterkopf behalten. Dank eines Diagnosewerkzeugs 

für SELinux und eines 

entsprechenden Indikator-Applets 

lassen sich Probleme mit SELinux aber 

recht einfach lösen und zwar nicht nur 

durch das simple Abschalten von SELinux 

oder einen Wechsel in den Permissive 

Mode. 

Standard-Desktop von Fedora 20 ist 

Gnome 3.10, was hier nicht weiter 

thematisiert werden soll, weil die Benutzeroberfläche 

für Admins eine untergeordnete 

Rolle spielt und sich die 

Desktop-Umgebungen Gnome Classic 

Mode, KDE 4.11, LXDE 0.5.5, XFCE 4.10 

oder Openbox 3.5.2 ohnehin wahlweise 

im Zuge der Installation oder später 

aus den Paketquellen problemlos installieren 

lassen. Erwähnenswert ist 

aber in diesem Zusammenhang, dass 

Fedora in Gnome 3.10 auf ein neues, 

ebenfalls auf »packagekit« basierendes, 

grafisches Software-Verwaltungswerkzeug 

setzt. Im Stil von Ubuntus 

Software-Center soll es Einsteigern 

das Suchen, Installieren und Entfernen 

von Anwendungen erleichtern 

und stellt dabei nicht mehr Pakete, 

sondern Software in den Mittelpunkt. 

Nach dem Debüt in Fedora 20 soll der 

neue Software-Installer Gnome-weiter 


Basics 

Fedora 20 

87 

Standard werden. Gleichzeitig wurden 

die bisherigen Frontends zu »gnomepackagekit«, 

»gpk‐update‐viewer« und 

»gpk‐application« entfernt. Sie lassen 

sich bei Bedarf aber zurückholen. 

DNF löst künftig Yum ab 

Für Admins interessanter ist, dass sich 

das Fedora-Team wie Vorbild Red Hat 

schrittweise vom Kommandozeilenwerkzeug 

Yum zugunsten des DNF- 

Paketmanagers [2] zu lösen versucht 

(Abbildung 1). Der wurde in Fedora 20 

von Version 0.3 auf 0.4.10 aktualisiert 

und hat nach Ansicht der Fedora- 

Entwickler inzwischen funktional das 

Leistungsniveau von Yum erreicht. Ob 

und wann DNF aber tatsächlich zum 

Default-Paketmanager in Fedora wird, 

hängt letztlich von der Nutzer-Akzeptanz 

ab. In Fedora 20 ist DNF jedenfalls 

erstmals parallel zu Yum installiert und 

das Fedora-Team ruft ausdrücklich zum 

Testen auf. 

ARM-Support 

Das Fedora-Team hat in Fedora 20 zudem 

ARM zu einer der Primär-Architekturen 

gemacht, was schlicht bedeutet, 

dass die ARM-Version erstmals im ganz 

normalen Rahmen der Fedora-Entwicklung 

parallel und weitgehend zeitgleich 

zu den x86-Varianten vorangetrieben 

wurde, sodass die ARM-Installationsmedien 

vom Start weg alternativ zum 

Download erhältlich sind. Die ARM- 

Architektur steht zudem auch in virtuellen 

Maschinen zur Verfügung, wenn der 

Admin dazu den Standard-Libvirt-Stack 

aus KVM/Qemu, Virsh oder Virt-Manager 

verwendet und funktioniert dank 

der ARM-CPU-Emulation von Qemu in 

Fedora 20 [3] sehr gut, nachdem die 

Entwickler entsprechende Bugs beseitigt 

haben. 

Die ARM-Version von Fedora 20 ist für 

ARMv7hl kompiliert und unterstützt 

damit unter anderem die ARM-Plattformen 

Highbank, Pandaboard, Trimslice 

und Versatile Express. Die Fedora- 

Entwickler arbeiten aber auch an einer 

Portierung für die ARMv8-Architektur 

mit 64-Bit-ARM-Befehlssatz AArch64. 

Ob es bereits von Fedora 20 eine 64-Bit- 

ARM-Version geben wird, ist noch nicht 

entschieden. 

Abbildung 1: Unter den vielen Neuerungen sind die aktualisierte Version 0.4.10 des DNF-Paketmanagers 

und der überarbeitete Virt-Manager mit Support für Live-Snapshots interessant. 

Virtualisierung 

Ferner erlaubt der Libvirt-Client in Fedora 

20 das Setzen von Zugriffsregeln 

für sämtliche von Libvirt verwalteten 

Objekte und API-Aufrufe, wodurch 

sich sämtliche Client-Verbindungen 

auf einen definierten Satz von Regeln 

und Privilegien limitieren lassen. Dazu 

stehen drei Access-Level zur Verfügung: 

»Unauthenticated access« wird initial 

für sämtliche Verbindungen verwendet 

(Default) und entspricht dem bisherigen 

Verhalten. Darüber hinaus gibt es 

in Fedora 20 zwei weitere Access-Level: 

»Unrestricted access«, das vollen Zugriff 

auf alle API-Operationen erlaubt 

und »Restricted« für Read-Only-Access. 

Damit können Admins ab sofort 

Zugriffsregeln für die beiden neuen 

Access-Level definieren. 

Zugriffskontrolle in Libvirt 

Jeder API-Aufruf in Libvirt erhält damit 

einen Satz an Zugriffsregeln, die gegen 

jedes verwendete Objekt validiert 

werden. Eine umfangreiche Dokumentation 

der neuen Policy-Kit-basierten 

Zugriffskontrolle in Libvirt steht sowohl 

auf der Libvirt-Projektseite [4] als 

auch im Fedora-Wiki [5] zur Verfügung. 

Erwähnenswert ist in diesem Zusammenhang 

auch, dass das Anlegen und 

Verwalten von Snapshots mit dem 

Virt-Manager viel komfortabler und 

einfacher funktioniert, wenn Images im 

QCOW2-Format verwendet werden. 

Ausstattung für Admins und 

Entwickler 

Fedora 20 bringt darüber hinaus zum 

ersten mal auch Pakete zum Betrieb 

der Apache Hadoop-Plattform 2.2 

mit. Außerdem ist OpenStack in der 

aktuellen Version Havana an Bord. 

Ferner steht für das Ausführen von 

Java-EE-7-Anwendungen jetzt WildFly 

8 als Anwendungsserver zur Verfügung. 

Der Name steht neuerdings für die 

Community-Version von JBoss. WildFly 

8 läuft laut Red Hat besonders schnell 

und kommt dank optimierter Speicherverwaltung 

mit vergleichsweise wenig 

Speicher aus. 

Fedora 20 eignet sich auch hervorragend 

als Entwicklungsplattform. So 

finden sich im Standard-Lieferumfang 

neben Ruby on Rails 4.0 auch Perl 5.18 

und die C++-Bibliothek Boost 1.54.0. 

Für System-Integratoren und Entwickler 

ebenfalls interessant: Die schemafreie, 

hochperformante, dokumentenorientierte 

Open-Source-Datenbank 

MongoDB wurde in Fedora 20 auf die 

Version 2.4 mit integrierter Volltextsuche 

aktualisiert. Außerdem unterstützt 

MongoDB 2.4 sogenannte »wider array 

of geospatial indexes« und verfügt über 

eine Reihe von Sicherheitserweiterun- 


Admin 

Ausgabe 03-2014

88 

Basics 

Fedora 20 

Abbildung 2: Der neue Network-Manager ist komfortabler, 

einfacher zu handhaben und funktioniert mit 

»nmcli« auch von der Kommandozeile. 

n Info 





[1] Fedora 20: 

[http:// docs. fedoraproject. org/ en‐US/ 

Fedora/ 20/ html/ Release_Notes/ index. html] 

[2] DNF testen: 

[https:// lists. fedoraproject. org/ pipermail/ 

users/ 2013‐December/ 443694. html] 

[3] Virt-ARM: [https:// fedoraproject. org/ wiki/ 

Changes/ Virt_ARM_on_x86] 

[4] Libvirt-Access-Control: 

[http:// libvirt. org/ aclpolkit. html] 

[5] Libvirt-Access-Control Fedora: [https:// 

fedoraproject. org/ wiki/ Changes/ Virt_ACLs] 

[6] Thomas Drilling, Active Directory mit freier 

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

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

Directory‐mit‐freier‐Software/] 

[7] Thorsten Scherf, Der System Security Services 

Daemon, ADMIN 03/2012: [http:// www. 

admin‐magazin. de/ Das‐Heft/ 2012/ 03/ Der‐Sy 

stem‐Security‐Services‐Daemon] 

[8] Neuer Network-Manager: [http:// 

fedoraproject. org/ wiki/ Changes/ 

NetworkManagerCLIAddConnection] 

[9] Fedora-20-Release-Notes: [http:// docs. 

fedoraproject. org/ en‐US/ Fedora/ 20/ 

html/ Release_Notes/ sect‐Release_ 

Notes‐Changes_for_Sysadmin. html] 

[10] Systemd 205 – Neue Unit-Typen: [http:// lists. 

freedesktop. org/ archives/ systemd‐devel/ 

2013‐July/ 011679. html] 

gen. Darüber hinaus bringen der seit 

Längerem in Fedora enthaltene und 

auch von Red Hat favorisierte, auf Identity-Management 

spezialisierte, freie 

Verzeichnisdienst FreeIPA [6] sowie der 

»System Security Services Daemon« 

(SSSD) [7] eine Reihe von Verbesserungen 

im Bereich der Active-Directory- 

Integration mit. Apropos Samba: Der 

SSSD-Daemon spendiert Fedora 20 

auch ID-Mappings für CIFS-Freigaben. 

Ferner haben die Fedora-Entwickler die 

Unterstützung für TrueCrypt mit »systemd‐cryptsetup« 

auch auf Systemd 

und damit den Boot-Prozess ausgeweitet, 

sodass eine einfache Authentifizierung 

beim Boot-Prozess möglich ist. 

Neu in Fedora 20 ist eine Infrastruktur 

zum gemeinsamen Verwenden von 

Zertifikaten für verschiedene Krypto- 

Bibliotheken. Das macht das mehrfache 

Verwalten unterschiedlicher 

Zertifikate für die verschiedenen Verschlüsselungstools 

obsolet. Außerdem 

haben in Fedora 20 die Unterverzeichnisse 

in »/usr/share/doc« keine Versions 

nummern mehr, sondern nutzen 

nur noch den Paketnamen. 

Unter der Haube 

Fedora 20 verwendet beim Installieren 

von den Standard-Installationsmedien 

mit Ausnahme von »netinstall« noch 

einen Kernel 3.11.10-301. Ein aktualisierter 

Kernel 3.12.6-300 rutscht aber 

gleich mit dem ersten System-Update 

nach. Als zentrale C-Systembibliothek 

fungiert die Glibc 2.18. 

Vollständig überarbeitet wurde der Network-Manager 

(Abbildung 2). Er erlaubt 

jetzt auch das Hinzufügen, Entfernen 

und Ändern von Netzwerken mithilfe 

des Befehls »nmcli« auf der Kommandozeile 

[8] und unterstützt Bonding 

und Bridging. Für die Bluetooth-Unterstützung 

kommt die neue BlueZ-Version 

5 zum Einsatz. Fedora 20 installiert 

zudem erstmals kein Sendmail mehr, 

weil die Fedora-Entwickler der Ansicht 

sind, dass ein Mail Transfer Agent bei 

den meisten Nutzern überflüssig ist. 

Das sieht für Administratoren freilich 

anders aus, allerdings installieren die 

in der Regel ohnehin lieber Postfix, der 

sich beim Aufruf kompatibel zu Sendmail 

verhält. 

Ohne Syslog-Daemon 

Fedora 20 installiert im Zuge der Aktualisierung 

auf Systemd 208 jetzt auch 

keinen Syslog-Daemon Rsyslog mehr. 

Der ist laut Fedora-Team obsolet, weil 

sich der Journald aus dem Systemd- 

Paket um das Protokollieren von Ereignissen 

kümmern kann. 

Admins müssen damit etwas umdenken, 

wenn sie Rsyslog nicht einfach 

wieder installieren, was problemlos 

möglich ist. Äquivalente Lösungen zum 

Auswerten der in Fedora 20 standardmäßig 

nicht mehr enthaltenen »/var/ 

log/messages« bietet das Kommando 

»journalctl«. So ersetzt etwa »journalctl« 

ein »cat /var/log/messages«. 

Eine Alternative zu »tail ‐f /var/log/messages« 

ist »journalctl ‐f «. Weitere Alternativen 

nennt das Fedora-Team in den 

Release-Notes [9]. Dank Systemd 208 

dürfen sich Fedora-Admins im Rahmen 

der Ressourcen-Steuerung via Cgroups 

auch mit zwei neuen Unit-Typen 

»scopes« und »slices« auseinandersetzen, 

die mit der Systemd-Version 205 

im Sommer letzten Jahres eingeführt 

wurden – Details dazu finden sich in der 

Produktankündigung zu Systemd 205 

[10] sowie im Changelog. 

Fazit 

Ein rundes Zwanziger-Release – und 

das passend zum zehnten Geburtstag 

des Projektes – deutet auf einen ganz 

großen Wurf hin. Dass Fedora 20 keiner 

ist, sondern ein solides, evolutionäres 

Update mit gegenüber Fedora 19 überschaubarer 

Anzahl an Neuerungen, hat 

zwei Gründe. Bei Fedora gibt es keine 

herausragenden Versionen, etwa mit 

LTS-Support, denn diese Rolle kommt 

ja ohnehin schon Red Hat Enterprise 

Linux zu. 

Zudem machen Rolling Releases bei einer 

Trendsetter-Distribution wie Fedora 

ebenfalls keinen Sinn, denn in diesem 

Punkt spielt Fedora per Definition ohnehin 

an vorderster Front. 

Basis für das kommende Red Hat Enterprise 

Linux 7, das vor wenigen Wochen 

in einer ersten Beta-Version 7 erschienen 

ist, soll im Wesentlichen Fedora 

19 sein, das sich auch in unseren Langzeittests 

als sehr stabil und zuverlässig 

erwiesen hat. (ofr) n 


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 •

pzaxe, 123RF 

90 

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 Augenschonend arbeiten 

Tipps zur Ergonomie am Computer gibt es eine Menge. Um die kleinen 

Tools zur Schonung der Handgelenke soll es aber heute nicht gehen. Und 

auch nicht um die richtige Position des Monitors, die Genickstarre und Rückenschmerzen 

verhindert. Das kleine Programm, das wir heute vorstellen, 

färbt den Bildschirm passend zur Tageszeit ein und will damit vor allem 

besseren Schlaf ermöglichen. 

Nach der Theorie der Macher von f.lux [1] sind Monitore so ausgelegt, dass 

sie farblich wie Tageslicht erscheinen. Starrt man nun auch abends und die 

halbe Nacht auf gleißende Anzeigen, kann dies zu Schlafstörungen führen, 

wie eine ganze Reihe von Studien belegen, die die f.lux-Website aufführt. 

Als Gegenmittel passt f.lux die Farbtemperatur des Bildschirms an die aktuelle 

Tageszeit an. Das funktioniert im Sommer wie im Winter zuverlässig: 

Der Benutzer muss nur seinen Standort eingeben, den Rest erledigt das 

Programm. f.lux gibt es für Windows, OS X und Linux, wobei die kürzlich erschienene 

neue Windows-Version die meisten Features besitzt, etwa einen 

speziellen Modus zum Filmeschauen, der die augenschonende Farbdarstellung 

eine Zeit lang deaktiviert. 

n Rettung mit LVM 

Bei der Rettung eines kaputten Linux-Systems hat sich 

eine Chroot-Umgebung schon tausendfach bewährt. 

Bootet man von einer beliebigen Linux-DVD, die in 

eine Shell führt, muss das Dateisystem des zerschossenen 

Linux nur gemountet werden, dann gelangt 

man mittels »chroot« in eine Umgebung, in der man 

beispielsweise den Grub-Installer neu ausführen kann – 

eventuell sind noch Bind-Mounts für die Proc-, Sys- und 

Dev-Dateisysteme nötig, aber das ist eine andere Geschichte. 

Schwieriger wird das Mounten, wenn es statt klassischer 

Partitionen eine Aufteilung mit dem Logical 

Volume Manager (LVM) gibt, was bei vielen Linux-Distributionen 

die Standard-Einstellung ist. Hier gilt es erst 

einmal die Volumes zu finden, bevor man die passende 

mounten und dann mit der Wiederherstellung fortfahren 

kann. Die Volume Groups gibt der folgende Befehl 

aus: 

# lvm vgscan ‐v 

Als nächstes aktiviert dieser Befehl sie: 

# lvm vgchange ‐a y 

Die logischen Volumes lassen sich dann so anzeigen: 

# lvm lvs ‐‐all 

LV VG Attr LSize Pool U 

Origin Data% Move Log Copy% Convert 

LogVol00 vg_centhost ‐wi‐ao‐‐‐ 297,60g 

Schließlich bleibt nur noch, das Logical Volume am gewünschten 

Ort zu mounten: 

# mount /dev/vg_centhost/LogVol00 /mnt/ 


Basics 

Admin-Tipps 

91 

n Ärger mit Disk-UUIDs 

Wer nachträglich die Größe einer Linux- 

Partition verändern möchte, kann ein 

blaues Wunder erleben. Will man nach 

dem Booten einer Live-CD wie GParted 

etwa die Größe der ersten Partition 

ändern, dann geht das nur, wenn man 

die nachfolgenden Partitionen für das 

Tmpfs und Swap kurzzeitig entfernt. 

Soweit kein großes Problem, denn die 

sind schnell wieder angelegt und mit 

den richtigen Signaturen versehen. 

Die Schwierigkeiten treten erst dann 

auf, wenn man das alte System wieder 

booten möchte, denn beim Neupartitionieren 

haben die Partitionen neue 

UUIDs bekommen. Eine bekannte 

Fehlerquelle ist die Datei »/etc/fstab«, 

die statt Partitionsnamen auf manchen 

Distributionen die UUIDs der Partitionen 

zum Mounten verwendet. Mit einer 

Bootdisk oder in einer Rettungs-Shell 

ist dieses Problem jedenfalls recht 

schnell gelöst. 

Auf manchen Linux-Distributionen, 

etwa Fedora 19, ist das Problem aber 

subtiler: Die UUIDs der Disk sind tief im 

System verankert, etwa mit dem Systemd 

beziehungsweise Udev, die über 

die UUID etwa das Swap-Device ausfindig 

machen. Klappt das nicht, startet 

der Rechner auch nicht: 

Starting Dracut Emergency Shell... 

Warning: /dev/disk/by‐uuid/.... does U 

not exist 

Generating "/run/initramfs/sosreportU 

.txt" 

Entering emergency mode. Exit the U 

shell to continue. 

Type "journalctl" to view system logs 

Die Schwierigkeit liegt darin, dass Dracut 

beim Erstellen der initialen RAM- 

Disk (initramfs) die UUIDs des Swap- 

Devices gespeichert 

hat. Nun gibt es zwei 

Auswege: entweder per 

Hand der Partition die 

alte UUID vergeben, die 

auch beim fehlgeschlagenen 

Boot-Vorgang zu 

sehen ist. Mühsam ist 

dabei nur, sie von Hand 

abzutippen, denn in der 

Rettungskonsole gibt es 

typischerweise kein simples 

Cut-and-Paste. Außerdem 

muss man dazu 

das Tool »mkswap« verwenden, 

denn »tune2fs«, 

über das man normalerweise 

Partitions-UUIDs 

setzt, funktioniert bei Swap-Partitionen 

nicht: 

mkswap ‐U 6220f21b‐32f8‐40ac‐ac8d‐U 

f82e112568f8 /dev/sda2 

Der andere Weg besteht darin, mit Dracut 

die initiale RAM-Disk neu zu schreiben. 

Zuerst legt man in der Rettungs- 

Shell ein Verzeichnis an, um das Root- 

Dateisystem zu mounten. Dann mountet 

man die Pseudodateisysteme des 

Kernels, die auch im später folgenden 

Chroot zur Verfügung stehen sollen: 

mkdir /mnt 

mount /dev/sda1 /mnt 

mount ‐o bind /proc /mnt/proc 

mount ‐o bind /sys /mnt/sys 

mount ‐o bind /dev /mnt/dev 

chroot /mnt 

Nun bleibt nur noch, mit Dracut das 

Init ramfs neu zu schreiben. Weil es 

die Datei schon gibt, ist der Schalter 

»‐‐force« dazu obligatorisch: 

dracut ‐‐regenerate‐all ‐‐force 

Wenn man nun die Chroot-Umgebung 

wieder verlässt und das System rebootet, 

sollte es wie gewohnt starten. 

n Info 





[1] f.lux - software to make your life better: 

[http://justgetflux.com/] 

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 03-2014

92 


SMB 3 

Vladimir Kramin, 123RF 

Hyper-V mit dem SMB-3-Protokoll 

Flotter Feger 

Microsoft hat mit dem Server Message Block 3 (SMB 3) in Windows Server 2012 und Windows Server 2012 

R2 zahlreiche Verbesserungen eingeführt. Vom schnelleren und stabileren Zugriff auf Netzwerk-Storage 

profitiert vor allem Hyper-V. Wir zeigen, was es mit diesen Neuerungen auf sich hat. Thomas Joos 

Das SMB-Protokoll ist vor allem als 

Grundlage für das Datei-Sharing unter 

Windows bekannt und im Zusammenhang 

mit Samba auch Linux-Benutzern 

ein Begriff. Windows 8.1 und Windows 

Server 2012 R2 beherrschen das neuen 

SMB-3-Protokoll, das gegenüber der 

alten Version über zahlreiche Vorzüge 

verfügt. Es wurde zwar bereits mit Windows 

Server 2012 eingeführt, aber in 

Windows Server 2012 R2 noch einmal 

verbessert. Der schnelle Zugriff auf 

Netzwerk-Storage kommt vor allem 

Enterprise-Anwendungen zugute, etwa 

dem SQL Server und den virtuellen 

Festplatten von Hyper-V. 

Die Festplatten von virtuellen Servern 

können mit Windows Server 2012 R2 

auch im Netz gespeichert sein, zum 

Beispiel auf Dateifreigaben oder auf 

iSCSI-Zielen. 

Speichert man große Dateien wie die 

Festplatten virtueller Server dateibasiert 

im Netzwerk, ergeben sich einige 

Vorteile gegenüber der blockbasierten 

Speicherung. So lassen sich solche 

Dateien insbesondere einfacher verwalten. 

Das gilt vor allem, wenn sie 

auf Dateifreigaben gespeichert sind, 

da hier externe Verwaltungswerkzeuge 

wegfallen und Workflows zur Verwaltung 

nicht verändert werden müssen. 

Windows Server 2012 R2 erlaubt die 

Verwendung von VHDX-Dateien als 

iSCSI-Ziel. Auf diesem Weg können 

Hyper-V-Hosts ihre Daten auf iSCSI- 

Festplatten speichern, die dann wiederum 

mit SMB 3 angebunden sind. 

VHDX-Dateien sind außerdem wesentlich 

robuster und erlauben eine Größe 

von bis zu 64 TByte. 

SMB 3 kann auf virtuellen Servern in 

Clustern die SMB-Sitzungen von Serverdiensten 

und Anwendersitzungen weiterreichen. 

Wenn ein virtueller Server 

zwischen Cluster-Knoten verschoben 

wird, bleiben die Sitzungen aktiv; die 

Anwender- und Serverdienste werden 

bei diesem Vorgang nicht voneinander 

getrennt. Das heißt, neben der höheren 

Leistung und besserer Verfügbarkeit 

unterstützt SMB 3 auch Hochverfügbarkeit. 

Neues in SMB 2.0 und 2.1 

SMB wurde seinerzeit von IBM entwickelt 

und von Microsoft über den LAN- 

Manager in Windows Mitte der 1990er 

integriert. Microsoft hat SMB 1.0 angepasst 

und bei der Internet Engineering 

Task Force (IETF) eingereicht. Außerdem 

wurde SMB in CIFS (Common Internet 

File System) umbenannt. 

Microsoft hat gleich nach der Übernahme 

von SMB von IBM mit der Verbesserung 

von SMB begonnen. In die 

Versionen 2.0 von Windows Vista und 

die Version 2.1 von Windows 7 und Windows 

Server 2008 hat Microsoft einige 

Verbesserungen integriert. Seit Version 

2.0 verwendet Microsoft nicht mehr die 

Bezeichnung CIFS, da die ursprünglichen 

Erweiterungen nur für SMB 1.0 

entwickelt wurden. Bei SMB 2.0 spielen 

diese keine Rolle mehr. 

SMB 2.1 bietet vor allem Leistungsverbesserungen 

auch für sehr schnelle 

Netzwerke im 10-Gigabit-Bereich. Die 

Version unterstützt größere Übertragungseinheiten 

(Maximum Transmission 

Units, MTU). Außerdem wurde die 

Energieeffizienz auf den Clients verbessert. 

Clients ab SMB 2.1 können auch 

mit aktivierten SMB-Verbindungen in 

den Energiesparmodus wechseln. 

Verbesserungen in SMB 3.0 sind zum 

Beispiel TCP Windows Scaling und Beschleunigungen 

im WLAN. Zusätzlich 

hat Microsoft die Verbindung zwischen 

Client und Server sowie den Cache auf 



SMB 3 

93 

Transparent Failover 

erlaubt zum Beispiel, 

dass Clients sich mit 

einem Dateiserver in 

einer Clusterumgebung 

verbinden können. 

Wenn der virtuelle 

Datei-Server auf einen 

anderen Cluster-Knoten 

verschoben wird, 

bleiben die Verbindungen 

zu den Clients dennoch 

aktiv. In der aktuellen Version von 

SMB werden offene SMB-Verbindungen 

ebenfalls auf den neuen Knoten umgeleitet 

und bleiben aktiv. Der Vorgang ist 

für Clients und Hyper-V-Hosts vollkommen 

transparent. 

Wenn virtuelle Festplatten auf Dateifreigaben 

in einem Cluster gespeichert 

sind, brechen Serverdienste beim 

Verschieben der Serverdienste nicht 

mehr ab. Ebenfalls neu in SMB 3.0 ist 

SMB Multichannel, bei dem die Bandbreite 

von mehreren Netzwerkadaptern 

zwischen SMB-3-Clients und SMB-3- 

Servern zusammengefasst wird. Dies 

eröffnet vor allem zwei Vorteile: Die 

Bandbreite wird für erhöhten Durchsatz 

auf mehrere Links verteilt. Zusätzlich 

bietet die Technik höhere Fehlertoleranz, 

wenn einmal eine Verbindung 

ausfällt. Die Technik funktioniert ähnlich 

wie Multipath I/O (MPIO) für iSCSIund 

Fibre-Channel-Netzwerke. 

SMB Scale Out verwendet Cluster 

Shared Volumes (CSV) für den parallelen 

Zugriff auf Dateien über alle 

Knoten in einem Cluster. Das erhöht 

die Leistung und die Skalierbarkeit von 

Serverdiensten, da alle Knoten beteiligt 

sind. Die Technologie arbeitet parallel 

zu Funktionen wie Transparent Failover 

und Multichannel. 

Zusätzliche SMB-Leistungsindikatoren 

erlauben die Messung der Nutzung 

und Auslastung von Dateifreigaben, 

einschließlich Durchsatz, Latenz und 

IOPS-Management-Reporting. Die 

neuen Zähler in der Leistungsüberwachung 

von Windows Server 2012 und 

Windows Server 2012 R2 unterstützen 

die Messung für Client und Server, sodass 

die Analyse von beiden Enden der 

SMB-3.0-Verbindung möglich ist. Diese 

neuen Technologien sind für die Prodem 

Client verbessert und optimiert. 

Mit der neuen Pipeline-Funktion können 

Server mehrere Anforderungen 

in die Warteschlange schreiben und 

parallel abarbeiten. Diese neue Technik 

ähnelt den Buffer Credits in der Fibre- 

Channel-Technologie. 

Microsoft hat in der aktuellen Version 

die Datenbreite auf 64 Bit erweitert. 

Das ermöglicht Blockgrößen von mehr 

als 64 KByte, was die Übertragung großer 

Dateien, etwa virtueller Festplatten 

oder Datenbanken, beschleunigt. 

Außerdem hat Microsoft die Verbindungen 

zwischen Client und Server optimiert. 

Das verhindert Verbindungsabbrüche 

in unzuverlässigen Netzwerken 

wie WLANs oder WAN-Umgebungen. 

Neuerungen in SMB 3.0 

In Windows Server 2012 hat Microsoft 

mit der Version 2.2 von SMB weitere 

Verbesserungen integriert. Später 

wurden diese Neuerungen als so weitreichend 

eingestuft, dass die Version 

nachträglich auf 3.0 erhöht wurde. Eine 

neue Funktion in SMB 3.0 sind zum 

Beispiel die serverbasierten Work loads. 

Diese unterstützen Hyper-V und Datenbanken 

mit SQL Server 2012/2014. 

Hyper-V für SMB beherrscht jetzt UNC- 

Pfade als Speicherort von Steuerdateien 

virtueller Server. Auch virtuelle 

Festplatten können jetzt UNC-Pfade 

verwenden, also Dateien direkt im 

Netzwerk speichern. Einfach ausgedrückt 

heißt das, dass der Speicherort 

von virtuellen Festplatten ab Windows 

Server 2012 aus einem Universal- 

Naming-Convention-Pfad (UNC) 

bestehen darf. Sie müssen keinen Laufwerksbuchstaben 

mehr verwenden 

oder Netzwerklaufwerke umleiten. Es 

besteht zum Beispiel jetzt die Möglichkeit, 

die Daten auch über einen Dienstnamen 

anzusprechen, nicht mehr 

ausschließlich über einen physischen 

Servernamen wie bei normalen Laufwerksbuchstaben. 

SMB 3.0 im Enterprise 

SMB 3.0 ist wesentlich robuster, leistungsstärker, 

besser skalierbar und 

bietet mehr Sicherheit als seine Vorgänger. 

Das ist vor allem für große 

Umgebungen ein wichtiger Punkt. SMB 

Abbildung 1: Virtuelle Festplatten von Servern lassen sich mit einem 

Assistenten verschieben. 

blemsuche von Leistungsproblemen 

und die Sicherstellung des stabilen Datenzugriffs 

im Netzwerk praktisch. 

Die neue SMB-Verschlüsselung erlaubt 

es, die Daten von SMB-Verbindungen zu 

verschlüsseln. Diese Technologie ist nur 

beim gemeinsamen Einsatz von SMB- 

3.0-Clients und ‐Servern aktiv. Wenn 

Sie parallel ältere Clients mit SMB 2.0 

und SMB 1.0 einsetzen, wird die Verschlüsselung 

deaktiviert. 

RDMA und Hyper-V 

Normalerweise wird bei jeder Aktion, 

bei der ein Serverdienst wie Hyper-V 

Daten über das Netzwerk sendet, zum 

Beispiel bei einer Live-Migration, der 

Prozessor belastet. Das liegt daran, 

dass der Prozessor Datenpakete für 

das Netzwerk erstellen und berechnen 

muss. Dazu braucht er wiederum Zugriff 

auf den Arbeitsspeicher des Servers. 

Ist das Paket zusammengestellt, 

leitet der Prozessor es zu einem Zwischenspeicher 

auf die Netzwerkkarte 

weiter. Hier warten die Pakete auf die 

Übertragung und werden dann von der 

Netzwerkkarte zum Zielserver oder Client 

gesendet. Wenn Datenpakete beim 

Server eintreffen, findet der gleiche 

Vorgang statt. Diese Vorgänge sind bei 

großen Datenmengen, die zum Beispiel 

bei der Übertragung virtueller Server 

mit der Live-Migration anfallen, sehr 

zeit- und rechenintensiv. 

Die Lösung für diese Probleme trägt 

die Bezeichnung Direct Memory Access 

(DMA). Einfach ausgedrückt können die 

verschiedenen Systemkomponenten, 

zum Beispiel Netzwerkkarten, direkt 

auf den Arbeitsspeicher zugreifen, um 

Daten zu speichern und Berechnungen 

durchzuführen. Dadurch werden der 

Prozessor entlastet sowie Warteschlan- 


Admin 

Ausgabe 03-2014

94 


SMB 3 

Abbildung 2: Der Status beim Verschieben von virtuellen Festplatten ist 

im Hyper-V-Manager zu sehen. 

gen und Vorgänge deutlich verkürzt. 

Das wiederum erhöht die Geschwindigkeit 

des Betriebssystems und der verschiedenen 

Serverdienste wie Hyper-V. 

Remote Direct Memory Access (RDMA) 

ist eine Erweiterung dieser Technologie 

um Netzwerkfunktionen. Die Technik 

erlaubt die Übertragung des Arbeitsspeicherinhalts 

auf einen anderen 

Server im Netzwerk sowie den direkten 

Zugriff von Windows Server 2012/2012 

R2 auf den Arbeitsspeicher eines anderen 

Servers. Microsoft hat RDMA bereits 

in Windows Server 2012 integriert, aber 

in Windows Server 2012 R2 verbessert 

und direkt in Hyper-V integriert. Windows 

Server 2012/2012 R2 kann die 

Technologie automatisch nutzen, wenn 

zwei Server mit Windows Server 2012/ 

2012 R2 im Netzwerk kommunizieren. 

RDMA erhöht den Datendurchsatz im 

Netzwerk deutlich und verringert die 

Latenz bei der Datenübertragung. Auch 

das spielt bei der Live-Migration eine 

wichtige Rolle. 

In Windows Server 2012 R2 können 

Cluster-Knoten auf den Arbeitsspeicher 

des anderen Cluster-Knotens während 

einer Live-Migration zugreifen und auf 

diesem Weg extrem schnell virtuelle 

Server im laufenden Betrieb durch die 

Live-Migration übertragen. Zusätzlich 

beherrscht Hyper-V in Windows Server 

2012 R2 bei der Live-Migration auch 

die Komprimierung der Daten. Diese 

neue Technik und die RDMA-Funktion 

beschleunigen Hyper-V in schnellen 

Netzwerken noch einmal deutlich. 

Interessant ist auch das Data Center 

Bridging in Windows Server 2012 R2, 

das Techniken implementiert, um Datenverkehr 

in sehr großen Netzwerken 

zu steuern. Beherrschen die eingesetzten 

Netzwerkadapter die Funktion Converged 

Network Adapter (CNA), können 

auf diesem Weg Daten auf Basis von 

iSCSI-Datenträger oder RDMA-Techniken 

besser genutzt werden – und zwar 

zwischen verschiedenen Datenzentren. 

Zusätzlich lässt sich auch die Bandbreite 

begrenzen, die diese Technologie 

nutzt. 

Für eine schnelle Kommunikation zwischen 

Servern auf Basis von Windows 

Server 2012 R2 – vor allem auf Cluster- 

Knoten – müssen die Netzwerkkarten 

RDMA unterstützen. Sinnvoll ist der 

Einsatz vor allem bei sehr großen Datenmengen, 

zum Beispiel wenn man 

Windows Server 2012/2012 R2 als NAS- 

Server, also als iSCSI-Ziel, verwendet 

und dort Datenbanken von SQL Server 

2012/2014 speichert. Eingeschränkt 

kann auch SQL Server 2008 R2 diese 

Funktion nutzen, allerdings weder Windows 

Server 2008 R2 noch ältere Versionen 

von Microsoft SQL Server. 

Hyper-V im Netzwerk optimal 

betreiben 

Sind im Unternehmen mehrere Hyper- 

V-Hosts auf Basis von Windows Server 

2012 R2 im Einsatz, können sie, wie 

erwähnt, mit der neuen Multichannel- 

Funktion parallel auf die Daten zugreifen. 

Im Einsatz ist diese Technologie 

zum Beispiel, wenn die virtuellen Festplatten 

von virtuellen Servern nicht auf 

dem Hyper-V-Host liegen, sondern auf 

Freigaben im Netzwerk. 

Die Technologie beschleunigt den 

Datenverkehr zwischen Hyper-V-Hosts 

und virtuellen Servern und sichert virtualisierte 

Serverdienste auch gegen 

den Ausfall eines einzelnen SMB-Kanals 

ab. Dazu ist weder die Installation eines 

Rollendienstes notwendig noch eine 

Konfiguration. Alle Vorteile sind bereits 

Out-of-the-Box in Windows Server 2012 

R2 integriert. 

Um diese Funktionen optimal zu nutzen, 

müssen die Netzwerkadapter 

schnell genug sein. Microsoft empfiehlt 

die Installation eines 10-GBit-Adapters 

oder den Einsatz von mindestens zwei 

1-GBit-Adaptern. Für diese Technik 

lässt sich auch die Teamfunktion von 

Netzwerkkarten in Windows Server 

2012 R2 nutzen. Der Server-Manager 

kann Netzwerkadapter zu Teams zusammenfassen, 

auch 

wenn die Treiber 

dies nicht unterstützen. 

Auch diese 

Teams unterstützen 

den SMB-Verkehr. 

SMB Direct ist zwischen Servern mit 

Windows Server 2012 R2 ebenfalls 

automatisch aktiviert. Damit diese 

Technologie zwischen Hyper-V-Hosts 

eingesetzt werden kann, müssen die 

eingebauten Netzwerkadapter die 

RDMA-Funktion (Remote Direct Memory 

Access) unterstützen und extrem 

schnell sein. Am besten sind Karten für 

iWARP, Infiniband und RDMA over Converged 

Ethernet (RoCE) geeignet. 

Speicher-Migration 

In Windows Server 2012 R2 gibt es die 

Möglichkeit, den Speicherort von virtuellen 

Festplatten auf Hyper-V-Hosts zu 

ändern. Diesen Vorgang können Sie im 

laufenden Betrieb der virtuellen Server 

vornehmen. Klicken Sie dazu im Hyper- 

V-Manager mit der rechten Maustaste 

auf den virtuellen Server, dessen Festplatten 

Sie verschieben wollen, und 

wählen Sie im Menü »Verschieben« 

aus, dann im Assistenten »Speicher 

des virtuellen Computers verschieben« 


Im Assistenten bestimmen Sie, ob Sie 

nur die Konfigurationsdaten des virtuellen 

Servers oder auch die virtuellen 

Festplatten verschieben wollen. Außerdem 

wählen Sie den Ordner aus, in 

dem Hyper-V die Daten des Computers 

speichern soll. Während des Vorgangs 

läuft der virtuelle Server weiter. Sie sehen 

den Status des Vorgangs im Hyper- 

V-Manager (Abbildung 2). Während des 

Verschiebens der Daten werden die 

Anwender nicht vom virtuellen Server 

getrennt. Der komplette Vorgang läuft 

komplett transparent ab. 

Sie können neben Konfiguration, 

Snapshots und den virtuellen Festplatten 

auch Smart-Paging-Dateien 

getrennt speichern. Smart Paging soll 

verhindern, dass sich virtuelle Server 

nicht mehr starten lassen, weil der gesamte 

verfügbare Arbeitsspeicher bereits 

zugewiesen ist. Nutzen Sie Dynamic 

Memory, besteht die Möglichkeit, 

dass andere Server auf dem Host den 

gesamten Arbeitsspeicher nutzen. 

Die Funktion Smart Paging erlaubt 

virtuellen Servern, beim Neustart 

Teile der Festplatte des Hosts als Arbeitsspeicher 

zu nutzen. Auch diesen 

Bereich können Sie daher getrennt 



SMB 3 

95 

verschieben. Nach dem erfolgreichen 

Start wird der Festplattenplatz wieder 

freigegeben und der virtuelle Server 

erhält durch Dynamic Memory wieder 

seinen Speicher. 

Live-Migration mit SMB 

Seit Windows Server 2012 ist es auch 

möglich, die Live-Migration auf Hyper- 

V-Hosts ohne Cluster zu nutzen und 

virtuelle Maschinen zwischen Hyper-V- 

Hosts zu replizieren, ohne diese clustern 

zu müssen. Ebenfalls neu ist die 

Möglichkeit, die virtuellen Festplatten 

eines Servers per Live-Migration zu 

verschieben. Das heißt, die virtuellen 

Server selbst bleiben auf dem aktuellen 

Host, nur der Speicherort der Dateien 

ändert sich. So können Sie zum Beispiel 

die Dateien auf eine Freigabe verschieben. 

In Windows Server 2012 R2 hat 

Microsoft die Funktionen weiter verbessert: 

Speichern Sie Daten im Netzwerk, 

profitieren diese Dienste von SMB 3. 

Bei Hyper-V-Replica replizieren Sie virtuelle 

Server inklusive aller Festplatten 

auf andere Server – ebenfalls im laufenden 

Betrieb. Als Verbindung ist kein 

gemeinsamer Datenträger notwendig, 

da auch die virtuellen Festplatten repliziert 

werden. In Windows Server 

2012 konnten Sie das Synchronisierungsintervall 

nur bis zu minimal fünf 

Minuten einstellen. Windows Server 

2012 R2 bietet die Möglichkeit, alle 

30 Sekunden die Daten zwischen den 

Hosts replizieren zu lassen. Auf der anderen 

Seite lässt sich jetzt das Replikationsintervall 

auf bis zu 15 Minuten ausdehnen. 

Die Replikation findet über das 

Dateisystem und das Netzwerk mit SMB 

statt, ein Cluster ist nicht notwendig. 

Die Replikationen lassen sich manuell, 

automatisiert und nach einem Zeitplan 

ausführen (Abbildung 3). 

Live-Migration ohne Cluster 

Für eine Live-Migration ohne Cluster 

klicken Sie mit der rechten Maustaste 

auf den virtuellen Server, den Sie verschieben 

wollen und wählen Sie im 

Kontextmenü die Option »Verschieben«. 

Anschließend wählen Sie auf der 

Seite »Verschiebungstyp auswählen« 

die Option »Virtuellen Computer verschieben«. 

Danach suchen Sie den Zielcomputer 

aus, auf den Sie den Rechner 

verschieben wollen. 

Im nächsten Fenster können Sie die 

Live-Migration noch genauer spezifizieren. 

Sie haben die Möglichkeit, verschiedene 

Daten des virtuellen Servers 

in unterschiedliche Ordner im Netzwerk 

zu verschieben. Oder Sie bewegen alle 

Daten des Servers inklusive der virtuellen 

Festplatten in einen gemeinsamen 

Ordner (Abbildung 4). Liegt die virtuelle 

Festplatte eines virtuellen Servers auf 

einer Freigabe, können Sie auch nur die 

Konfigurationsdateien zwischen den 

Hyper-V-Hosts verschieben. 

Diesen Vorgang können Sie auch skripten. 

Öffnen Sie dazu auf dem Quellserver 

eine Powershell-Sitzung und geben 

Sie den folgenden Befehl ein: 

Move‐VM Virtueller Server ZielserverU 

‐IncludeStorage ‐DestinationStoragePath U 

Lokaler Pfad auf dem Zielserver 

Um Hyper-V mit Live-Migration in einem 

Cluster zu betreiben, erstellen Sie 

den Cluster und aktivieren die Cluster 

Shared Volumes. Windows legt dann 

auf der Betriebssystempartition im 

Ordner »ClusterStorage« Daten ab. 

Diese liegen aber nicht tatsächlich 

auf der Festplatte »C:« des Knotens, 

sondern auf dem gemeinsamen Datenträger, 

dessen Abruf auf den Ordner 

»C:\ClusterStorage« umgeleitet ist. 

Der Datenträger kann sich auch auf 

einem virtuellen iSCSI-Datenträger in 

Windows Server 2012 R2 befinden. Die 

VHDX-Dateien der VMs liegen in diesem 

Ordner und stehen daher allen Knoten 

gleichzeitig zur Verfügung. 

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 

notwendig ist, 

automatisch über die 

Leitungen des zweiten 

Knotens routen, ohne 

Abbildung 3: Virtuelle Server kann man inklusive der 

Festplatten zwischen Hyper-V-Hosts replizieren. 

dazu ein Failover durchführen zu müssen. 

Sie können einen Cluster so konfigurieren, 

dass die Cluster-Knoten den 

Netzwerkverkehr zwischen den Knoten 

und zu den CSV priorisieren. 

Fazit 

Windows Server 2012 R2 und Hyper-V 

sind beide darauf ausgelegt, Daten 

zentral auf Freigaben im Netzwerk zu 

speichern. Allerdings müssen Sie hier 

auch die Leistung der verwendeten 

Komponenten beachten. Die Netzwerkadapter, 

die Server-Hardware und alle 

Netzwerkgeräte sowie natürlich die 

Verkabelung im Unternehmen müssen 

die neuen Funktionen auch unterstützen. 

(ofr) n 

n Autor 

Thomas Joos ist freiberuflicher IT-Consultant und 

seit über 25 Jahren in der IT tätig, unter anderem für 

Daimler, die Commerzbank und Microsoft. Neben 

seinen Projekten schreibt er praxisnahe Fachbücher 

und Fachartikel rund um Windows und andere 

Microsoft-Themen. Sein Blog ist unter [http:// 

thomasjoos. wordpress. com] zu finden. 

Abbildung 4: Statt einzelner Festplatten lassen sich auch komplette 

Server zwischen Hyper-V-Hosts verschieben. 


Admin 

Ausgabe 03-2014

Galina Peshkova, 123RF 

Linux-VMs unter Hyper-V mit Linux Integration Services beschleunigen 

Durchs Fenster 

Die Linux Integration Services virtualisieren Linux in Hyper-V-Umgebungen schnell und effizient. Nirmal Sharma 

Mit Hyper-V gelang Microsoft der Anschluss: 

Als die Firma 2008 die Gefahr 

erkannte, in Sachen Virtualisierungsund 

Cloud-Dienste ins Hintertreffen zu 

geraten, brachte sie Hyper-V auf den 

Markt. Anfänglich unterstützte es nur 

Windows-Systeme, aber die Redmon- 

n Unterstützte Betriebssysteme 

Microsoft unterstützt momentan die folgenden Distributionen 

als virtuelle Linux-Gastmaschinen auf 

Hyper-V-Servern: 

n Red Hat Enterprise Linux 5.5-5.9, 6.0-6.4, x86 und 

x64 

n CentOS 5.5-5.9, 6.0-6.4, x86 und x64 

n Suse Linux Enterprise Server 10 mit Service Pack 

4, SLES 11 mit Service Packs 1-3 

n Open Suse 12.1 

n Ubuntu 12.04-13.10 

n Oracle Linux 6.4 

Benutzer von Red Hat Enterprise Linux und CentOS 

in Versionen älter als 5.6 benötigen weiterhin Linux 

Integration Services Version 2.1. 

der merkten schnell, dass sie ohne Linux-Unterstützung 

einen großen Anteil 

des IT-Markts nicht bedienen konnten. 

2009 folgte deshalb ein einfacher Treiber 

für Linux-Gastmaschinen (Kasten 

„Unterstützte Betriebssysteme“). 

Linux Integration Services 

Die Basisfunktionalität genügte allerdings 

nicht: Microsoft entwickelte in 

der Folge die Linux Integration Services 

(LIS) als Antwort auf die Nachfrage 

nach besserer Performance und Integration 

von Linux-Systemen auf einem 

Hyper-V-Server. LIS ist das Pendant zu 

den VMware-Tools für virtuelle Maschinen 

auf einem VMware-ESX-Server. 

Ein Linux-Gast läuft auf Hyper-V auch 

ohne die Linux Integration Services, 

aber die LIS-Tools verschaffen eine 

effizientere und umfassende Virtualisierung 

sowie eine bessere Integration 

in die Hyper-V-Verwaltung fürs Monitoring, 

Management und Verteilen 

virtueller Linux-Systeme. LIS setzt auf 

ein System aus Treibern und Diensten 

auf dem Host- und auf dem Gastsystem. 

Deswegen müssen die passenden 

Pakete auch auf letzterem installiert 

werden; manche Distributionen stellen 

diese schon bereit. 

Die LIS-Treiber verbessern die allgemeine 

Performance der virtuellen 

Linux-Maschinen, indem sie den direkten 

Zugriff auf die Hardware des Hosts 

ermöglichen. Die VMBus-Komponente 

beschleunigt das System, indem sie eine 

zusätzliche Kommunikationsschicht 

zwischen Gast und Host aus dem Weg 

räumt. Die Dienste hingegen erledigen 

spezifische Aufgaben. Der LIS-Zeitsynchronisierungsdienst 

hält zum Beispiel 

die Uhr einer virtuellen Linux-Maschine 

im Einklang mit der des Hyper-V-Hosts. 

LIS-Treiber 

Die Linux Integration Services enthalten 

die folgenden Treiber: 




97 

Abbildung 1: Eine Hyper-V-Virtualisierung mit einem Windows-Gast, einem virtuellen Linux-System 

mit LIS und einem ohne LIS. 

muniziert. Das ermöglicht das Modul 

»hv_netsvc«. 

n Hyper-V Balloon: Virtuelle Windows- 

Maschinen unterstützten dynamische 

Speicherzuweisung durch eine 

Kombination aus der sogenannten 

Balloon-Technik und dem Hinzufügen 

und Entfernen von RAM im laufenden 

Betrieb. Seit Red Hat Enterprise 

Linux 6.4 steht ein einfacher 

Balloon-Treiber für die dynamische 

Speicherverwaltung mit dem Modul 

»hv_balloon« auch unter Linux zur 

Verfügung. Er entfernt Speicher 

dynamisch von einer virtuellen 

Maschine. Allerdings fehlt die Möglichkeit, 

im laufenden Betrieb neuen 

Speicher zuzuweisen. 

n Hyper-V-Funktionen ohne LIS 

n VMBus: Ein Kommunikationskanal 

zwischen virtuellen Linux-Maschinen 

und dem Hypervisor. Diese Komponente 

spielt eine wichtige Rolle bei 

der Performance-Verbesserung von 

Linux-Gastmaschinen. VMBus gehört 

zu den zentralen Kommunikationsmodulen 

von Hyper-V; fehlt dieser 

Treiber, operiert eine Linux-Maschine 

im weniger effizienten Emulationsmodus. 

Auf der Linux-Seite implementiert 

das »hv_vmbus«-Modul 

die VMBus-Funktionalität. 

n VSP und VSC: Gast- und Host-System 

kommunizieren miteinander über 

zusammengehörige Paare aus Treibern: 

Virtueller Service-Provider 

(VSP) und Virtueller Service-Client 

(VSC). VSPs laufen auf dem Host- 

System und warten auf Anfragen 

von den zugehörigen VSCs auf den 

Clients. Hyper-V kennt vier Typen 

von VSP- und VSC-Treibern: Netzwerk, 

Grafik, Speicher und Eingabegeräte 

(HID); allerdings fehlt bei LIS 

die Unterstützung für Grafik-VSCs. 

Die VSPs laufen stets in der Elternoder 

Root-Partition des Hyper-V- 

Hosts, während die VSCs in virtuellen 

Linux-Clients mit installierten 

Linux Integration Services laufen. 

Dazwischen steht der VMBus- 

Kommunikationskanal, über den 

die VSCs mit ihren zugehörigen VSPs 

kommunizieren. 

n SCSI-Treiber: Virtuelle Linux-Maschinen 

greifen über LIS auf einzelne 

oder mehrere SCSI-Controller mit 

realen und virtuellen Festplatten 

(VHD) zu. Dafür zeichnet in Linux das 

Modul »hv_storsvc« verantwortlich. 

n IDE-Treiber: LIS unterstützt über das 

Modul »ata_piix« den Zugriff auf IDE- 

Controller. 

n VMBus-Netzwerk-Controller: Einer 

virtuellen Maschine auf einem Hyper-V-Server 

stehen zwei Arten von 

Netzwerkadaptern zur Verfügung: 

»Legacy« für die Rückwärtskompatibilität 

mit herkömmlichen Linux- 

Netzwerktreibern sowie VMBus- 

Netzwerk-Controller. Die letzteren 

setzen die Linux Integration Services 

zwingend voraus. Sie verwenden 

den Netzwerk-VSC, der direkt mit 

dem Netzwerk-VSP des Hosts komn 

Maustreiber: Mit dem »hid_hyperv«- 

Modul steht Linux-Gastsystemen unter 

Hyper-V volle Mausunterstützung 

zur Verfügung. 

LIS-Dienste 

Neben den genannten Treibern sorgen 

die Linux Integration Services für die 

folgenden Dienste: 

n Zeitsynchronisierung: Der 

»Timesync«-Dienst hält die Uhr einer 

virtuellen Linux-Maschine auf dem 

Stand des Hyper-V-Hosts. 

n Gast-Shutdown: Der »shutdown«- 

Befehl im Hyper-V-Manager oder im 

System Center Virtual Machine Manager 

(SCVMM) fährt eine virtuelle 

Maschine herunter. 

Neben den Treibern und Diensten stellen die Linux Integration Services weitere Hyper-V-Funktionen 


n Live-Migration: Dieses Hyper-V-Feature verschiebt virtuelle Maschinen von einem Host auf einen 

anderen, ohne ihn anzuhalten. 

n Jumbo-Frames: Linux-Gastmaschinen verwenden Ethernet-Frames mit einer über die vom Ethernet-Standard 

vorgesehenen Größe von 1518 Byte. Die zusätzliche Kapazität (Payload) erlaubt 

höhere Datenübertragungsraten. 

n VLAN-Tagging und ‐Trunking: Administratoren versehen virtuelle Netzwerkadapter mit einer oder 

mehreren VLAN-IDs. Diese Netzwerkadapter heißen VMBus-Netzwerkadapter; sie stehen einer 

Gastmaschine erst nach der Installation der Linux Integration Services zur Verfügung. 

n Symmetrisches Multiprozessorsystem (SMP): Die von LIS unterstützten Linux-Distributionen verwenden 

mehrere virtuelle Prozessoren in einer virtuellen Maschine. Ihre Anzahl ist nur durch den 

Hyper-V-Server begrenzt. 


Admin 

Ausgabe 03-2014

98 



Abbildung 2: Unter Linux zeigt der Befehl »modinfo«, ob die LSI-Module 

installiert sind. 

Abbildung 3: Die LIS-Module in der Initramfs-Konfigurationsdatei 

»modules«. 

n Heartbeat: Mit dieser Funktion überprüft 

der Virtualisierungsserver regelmäßig, 

ob eine virtuelle Maschine 

noch läuft und reagiert. Ihr Status 

erscheint sowohl im Hyper-V-Manager 

als auch im SCVMM. 

n Datenaustausch: Informationen 

über laufende virtuelle Linux- 

Maschinen gelangen über den Datenaustauschdienst 

(Data Exchange 

Service) zum Host. Bei unterstützten 

Linux-Maschinen übermittelt diese 

Komponente Informationen wie die 

Prozessorarchitektur, Kernel-Version, 

Domain-Namen, die IPv4- und 

IPv6-Adressen sowie die LIS-Version. 

Zuständig dafür ist das »hv_utils«- 

Modul. 

Ein Dienst fehlt in der Liste: Den Client- 

Dienst Volume Shadow Copy Service 

(VSS) zum Erstellen von Snapshots 

im laufenden Betrieb gibt es nicht 

für Linux-Gastmaschinen. Der Kasten 

„Hyper-V-Funktionen ohne LIS“ listet 

Features auf, die auch ohne LIS-Treiber 

und ‐Dienste zur Verfügung stehen. 

LIS gibt Vollgas 

Eine virtuelle Linux-Maschine auf einem 

Hyper-V-Server weiß nicht, ob ihre 

Hardware physisch oder nur virtuell 

existiert. Auch in einer virtuellen Umgebung 

senden die Betriebssystemkomponenten 

Hardware-Zugriffe deshalb 

über native Treiber; an dieser Stelle 

schaltet sich die Virtualisierungsschicht 

ein. Sie fängt Hardware-Zugriffe im 

Rahmen der Geräte-Emulation ab. Die 

entsprechende Komponente stellt deshalb 

stets eine zusätzliche Kommunikationsschicht 

zwischen den virtuellen 

Maschinen und der Hardware dar. 

Microsoft bietet in den Linux Integration 

Services spezielle Komponenten 

an, um diese zusätzliche Schicht zu 

umgehen: Die erwähnten VMBus- sowie 

VSP- und VSC-Komponenten verwalten 

und beschleunigen so die meisten Gerätezugriffe. 

Per Bus vom Client zum Host 

Jede Anfrage, die ein VSC in einer virtuellen 

Linux-Maschine generiert, empfängt 

zunächst der VMBus-Treiber, der 

sie weiterleitet. VMBus funktioniert also 

als Vermittler zwischen den VSC- und 

den VSP-Komponenten. 

Abbildung 1 zeigt drei Arten von virtuellen 

Maschinen: Einen Windows-Gast, 

ein virtuelles Linux-System mit installierten 

Linux Integration Services und 

ein Linux-System ohne LIS. Der Haupt– 

unterschied zwischen den beiden Li- 

Abbildung 4: Die LIS-Module werden beim Systemstart geladen. 

Abbildung 5: »lsmod« zeigt die LSI-Module an. 




99 

nux-Gästen besteht darin, dass VMBus 

und die VSP- und VSC-Komponenten 

nur dem System mit LIS zur Verfügung 

stehen. 

Jeder Hardware-Zugriff erfolgt über die 

Root-Partition des Hyper-V-Servers. Wie 

schnell dessen Virtualisierungstreiber 

die Zugriffsanfragen beantworten, 

hängt von den sendenden Komponenten 

ab: Eine Emulation wie ganz rechts 

in Abbildung 1, also ohne LIS, verwendet 

die nativen Treiber der virtuellen 

Maschine für einen Zugriff. Dass Hyper- 

V diese Zugriffe abfangen muss, erhöht 

die Antwortdauer. 

Mit LIS kommt es hingegen zu einem 

sogenannten synthetischen Request 

durch eine VSC-Komponente des Gastsystems. 

So landet der Zugriff direkt in 

der Hyper-V-Root-Partition, die ihn an 

den entsprechenden VSP weiterleitet. 

Die folgenden Befehle in einem Linux- 

Gastsystem geben Auskunft darüber, 

ob die entsprechenden Module installiert 

sind (Abbildung 2): 

modinfo hv_netvsc 

modinfo hv_storvsc 

modinfo hv_vmbus 

LIS aufsetzen 

Viele Linux-Distributionen enthalten 

inzwischen LIS-Unterstützung. Auch bei 

ihnen muss sie jedoch vor der Benutzung 

aktiviert werden. Die folgenden 

Schritte zeigen das Vorgehen beispielhaft 

anhand von Ubuntu 12.04; bei 

anderen Distributionen kommt es teilweise 

zu abweichenden Dateinamen. 

Zunächst fügt man die folgenden 

LIS-Module mit einem Editor der 

»modules«-Datei unter »/etc/initramfs‐tools« 

hinzu (Abbildung 3): 

hv_vmbus 

hv_storvsc 

hv_blkvsc 

hv_netvsc 

Dieser Befehl erzeugt eine neue Initramfs 

mit den LIS-Modulen: 

sudo update‐initramfs ‐u 

Nach einem Neustart stehen die LIS- 

Module zur Verfügung (Abbildung 4). Ob 

das geklappt hat, lässt sich mit »lsmod« 

überprüfen; die »hv«-Module sollten 

dann wie in Abbildung 5 in den System- 

Logs auftauchen. 

Maßgeschneidert 

Bei Linux-Distributionen ohne eingebaute 

LIS-Unterstützung beginnt die 

Installation mit dem Download der 

LSI-ISO-Datei von [1], »LinuxICv34.iso« 

für die derzeit aktuelle Version 3.4. Sie 

enthält RPM-Pakete und Shell-Skripte 

für die Installation. Zudem aktualisiert 

sie auf Red Hat Enterprise Linux und 

CentOS in den Versionen 5.7, 5.8 und 

6.0 bis einschließlich 6.3 bestehende 

LIS-Installationen. 

Nun hängt man die ISO-Datei als CD 

in die gewünschte virtuelle Maschine 

ein. Darin manövriert man ins zur 

n Info 





[1] Download Linux Integration Services 3.4: 

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

download/ details. aspx? id=34603] 

Distribution passende Verzeichnis, 

etwa »RHEL57« für Red Hat Enterprise 

Linux oder CentOS 5.7. Die dort vorliegenden 

Shell-Skripte »install.sh« 

beziehungsweise »install‐rhel‐57.sh« 

und »‐58.sh« für RHEL und CentOS 

5.7 und 5.8 starten die Installation. 

Nach einem anschließenden Neustart 

helfen wieder die Kommandos »lsmod« 

und »modinfo«, den Erfolg zu überprüfen. 

Das Skript »Upgrade.sh« aktualisiert 

bestehende LIS-Installationen. Es liegt 

in den Verzeichnissen »RHEL6012« und 

»RHEL63« für Installationen von Red 

Hat Enterprise Linux oder Centos 6.0 

bis 6.2 beziehungsweise 6.3 vor. 

Die Deinstallation der Linux Integration 

Services erfolgt durch das Entfernen 

der »hyper‐v«-Pakete, etwa mit »rpm 

‐e kmod‐microsoft‐hyper‐v‐3.4‐1 

microsoft‐hyper‐v‐3.4«, wobei die Paketnamen 

mit der LIS-Version variieren 

können; Debian-basierte Distributionen 

verwenden statt »rpm« wie gewohnt 

»apt‐get«. (csc) n 

n Fehler und Einschränkungen 

Einigen Einschränkungen unterliegen Linux-Systeme auf Microsofts 

Hyper-V-Hosts nach wie vor: 

n Eine VHDX-Datei mit Ext3 zu formatieren, funktioniert nur bis zu einer 

bestimmten Blockgröße zuverlässig. Als Lösung reduziert man die 

Blockgröße der virtuellen Festplatten auf ein MByte oder weniger 

oder verwendet das Ext4-Dateisystem. 

n Ältere Linux-Varianten, etwa Red Hat Enterprise Linux bis Version 6.0, 

unterstützen nur Festplatten mit einer Sektorengröße bis zu 2048 

Byte. Mit diesen funktionieren die ab Windows Server 2012 verfügbaren 

Platten mit einer Blockgröße von 4096 Byte nicht. 

n Virtuelle Maschinen mit Ubuntu 12.04 funktionieren nicht immer problemlos 

mit einem herkömmlichen Netzwerkadapter. Die Verwendung 

virtueller Hyper-V-Netzwerkadapter löst dieses Problem. 

n Damit alle virtuellen Laufwerke in einem Gastsystem sichtbar sind, 

müssen die Bezeichner von SCSI-Laufwerken mit »0« beginnen. 

n Um einen Fehler im Linux-Kernel zu umgehen, setzt man bei der 

Verwendung von mehr als sieben virtuellen Prozessoren die Option 

»numa=off« in der Konfigurationsdatei »boot.cfg« des Grub-Bootloaders 

im Gastsystem. Dieselbe Option ist auch beim Einsatz von mehr 

als 30 GByte Arbeitsspeicher notwendig. 

n Entfernt man die Linux Integration Services von einer virtuellen 

Maschine mit mehr als einem virtuellen Prozessor, funktioniert das 

Herunterfahren dieser Maschine erst nach dem Deaktivieren des 

»irqbalance«-Dienstes wieder. 

n Den LIS-RPM-Paketen fehlt eine digitale Signatur: Wer sie unter Red 

Hat Enterprise Linux mit »rpm ‐K« überprüft, erhält die Meldung 

KEYS ARE NOT OK. 

n Der Dienst SCVMM 2008 stürzt in virtuellen Maschinen mit LIS-Komponenten 

v3.1 für Hyper-V ab. Behoben wird dies durch das Abschalten 

des KVP-Daemons im Linux-Gastsystem. 


Admin 

Ausgabe 03-2014

happystock, 123RF 

Programmieren mit Go 

Kanalisiert 

Viele klassische Programmieraufgaben lassen sich in Go mit wenigen Zeilen Code erledigen. Besonders 

elegant ist die parallele Verarbeitung von Tasks mit Goroutinen. Oliver Frommel 

Der Workshop in der letzten ADMIN- 

Ausgabe hat vorgeführt, wie man mit 

wenigen Zeilen Go-Code ein kleines 

Programm schreibt, das unter Linux 

die laufenden Prozesse auflistet [1]. Die 

Funktionalität ist rudimentär, aber das 

Projekt hat gezeigt, wie man mit Go auf 

Dateien und Verzeichnisse zugreift, Unicode 

verarbeitet sowie Schleifen und 

Funktionen verwendet. Verbesserungsmöglichkeiten 

gibt es noch viele, aber 

es ist nicht übermäßig sinnvoll, die 

Funktionalität des Linux-eigenen »ps« 

bis ins Letzte nachzuprogrammieren. 

In der letzten Version hat das Beispielprogramm 

»lap« für jeden Prozess 

aus der UID den Benutzernamen über 

die Funktion »user.LookupId()« der 

n Listing 1: »usermap« 

01 if val, ok := usermap[procData.uid]; ok { 

02 procData.user = val 

03 } else { 

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

05 procData.user = user.Username 

06 usermap[procData.uid] = user.Username 

07 } 

Go-Standardbibliothek ermittelt. Weil 

typischerweise jeder Benutzer eine 

Reihe von Prozessen besitzt, kommt es 

hier zu einer Menge unnötiger Lookups. 

Je nachdem, wie das Betriebssystem 

die dafür nötige Funktion »getpwuid()« 

implementiert, führt das wiederum zu 

vielen Zugriffen auf das Dateisystem. 

Deshalb ist hier ein Cache sinnvoll, 

der die Zuordnung von der UID zum 

Benutzernamen speichert und für den 

sich eine Map als Datenstruktur anbietet. 

Das Go-Keyword hierfür lautet 

»map«, wobei der Schlüssel in eckigen 

Klammern steht, gefolgt vom Wert. Das 

Builtin »make« initialisiert die Map und 

reserviert initial etwas Speicherplatz: 

var usermap map[string]string 

usermap = make(map[string]string) 

Um die Map als Cache für den Benutzer-Lookup 

zu verwenden, überprüft 

man zuerst, ob sich der gesuchte Wert 

schon in der Map befindet. Fehlt er, 

schlägt die Funktion »user.LookupId()« 

ihn nach und speichert ihn fürs nächste 

Mal in der Map. Etwas ungewöhnlich 

gestaltet sich die Überprüfung, ob der 

Wert schon in der Map steckt. Es gibt 

nämlich keine spezielle Funktion dafür 

wie in anderen Programmiersprachen 

(etwa »hasKey()«), sondern man versucht 

den Wert direkt auszulesen und 

überprüft dann den gleichzeitig zurückgegebenen 

Fehlercode. Packt man den 

Aufruf in eine If-Abfrage, geht das in 

einer Zeile, und man hat anschließend 

gleich den Wert aus der Map, wenn es 

ihn gibt: 

if val, ok := mymap[key]; ok { 

... 

Hier wird der Variablen »val« der Hash- 

Wert zugewiesen (sofern vorhanden) 

und »ok« der Error-Code, den die If- 

Abfrage nach dem Semikolon prüft. 

Diese Kombination von Zuweisung und 

Bedingung ist typisch für Go-Code und 

wird als „comma ok“-Idiom bezeichnet. 

Der komplette Code-Abschnitt für 

das »lap«-Tool ist in Listing 1 zu sehen. 

Weiteres Optimierungspotenzial birgt 


Programmieren 

Go 

101 

das Auslesen der Proc-Dateien, das 

beim aktuellen Entwicklungsstand 

des Tools noch sequenziell abläuft. 

Prinzipiell sind solche Annahmen mit 

Vorsicht zu genießen: Man sollte vor 

jeder Optimierung erst mit einem Profiler 

oder anderen Tools untersuchen, 

in welchen Abschnitten ein Programm 

wirklich viel Zeit verbringt. So würde 

die Parallelisierung von Dateizugriffen 

im Normalfall wohl kaum zu einer 

Beschleunigung führen, weil der Massenspeicher 

(etwa eine Festplatte) 

dann der Flaschenhals wäre. Unter 

Umständen kann es sogar zu einer 

Verschlechterung der Performance 

kommen, wenn durch unbedachte Parallelisierung 

vorhandene Cache-Effekte 

zunichte gemacht werden. 

Virtuelle Dateien 

Im Beispielfall ist die Situation ein bisschen 

anders, weil es sich bei den Proc- 

Dateien nur um virtuelle Files handelt, 

die der Kernel zur Verfügung stellt, also 

ist die Parallelisierung nicht vollkommen 

sinnlos. Riesige Performance- 

Gewinne lassen sich hier im Normalfall 

dennoch nicht erzielen, da die Prozessliste 

nicht besonders lang ist, aber der 

Fall taugt als Beispiel für die parallele 

Verarbeitung in Go. 

Zur parallelen Verarbeitung von Aufgaben 

bietet Go mit den Goroutinen 

ein eigenes Konstrukt an, das ein 

Zwischending zwischen Thread und 

Prozess darstellt. Eine Goroutine teilt 

den Speicher und damit die Variablen 

mit dem Hauptprogramm und gegebenenfalls 

anderen Goroutinen, was die 

Kommunikation vereinfacht. Goroutinen 

sind leichter zu handhaben als 

Threads, somit weniger fehleranfällig 

zu programmieren und verbrauchen 

auch noch weniger Ressourcen. Im einfachsten 

Fall ist nichts anderes zu tun, 

als dem Aufruf einer Funktion ein »go« 

voranzustellen: 

go doSomeThing(); 

Damit führt das Programm die Funktion 

»doSomeThing()« in einer Goroutine 

aus und fährt mit der Ausführung 

fort. Wer in einer Goroutine Text ausgibt, 

bekommt davon eventuell nichts 

zu sehen, weil das Hauptprogramm 

vorher fertig ist. Das ist natürlich nicht 

im Sinne der Erfinder, die deshalb auch 

Synchronisationsmöglichkeiten vorgesehen 

haben. 

n Listing 2: Channels 

01 func sayHello(c chan int) { 

02 fmt.Printf("hello") 

03 c

102 

Programmieren 

Go 

Abbildung 1: Parallelisiert: Am Ende schreibt die Funktion 

das Ergebnis in einen Channel. 

n Info 

Es gibt die bekannten Mutex-Locks 

und Waitgroups, aber der einfachste 

und passendste Mechanismus zur 

Synchronisation von Goroutinen sind 

Channels, die ähnlich funktionieren wie 

Unix-Pipes und zur Kommunikation 

zwischen Goroutinen vorgesehen sind. 

Buffered Channels blockieren bei Leseund 

Schreiboperationen nicht (solange 

noch Platz ist), ungepufferte Channels 

aber schon, weshalb sie sich zur Synchronisation 

eignen. Ein Beispiel ist in 

Listing 2 zu sehen. 

Die Main-Funktion erzeugt mit »make« 

einen Channel für Integer-Werte, der 

in der folgenden Zeile an die Funktion 

»sayHello()« übergeben wird. Weil die 





[1] Oliver Frommel, Programmieren in Go, ADMIN 

2/2014, S. 100: [http:// www. admin‐magazin. 

de/ Das‐Heft/ 2014/ 02/ Programmieren‐in‐Go] 

[2] Google I/O 2012 – Go Concurrency Patterns: 

[http:// www. youtube. com/ watch? 

v=f6kdp27TYZs] 

Funktion mit »go« als Goroutine 

aufgerufen wird, fährt die 

Main-Funktion mit der Verarbeitung 

fort. Das nun folgende 

Statement »


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

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 

Peer Heinlein, 

Heinlein Support GmbH 

Änderungen vorbehalten. 

Powered by 

Presented by 

www.cebit.de/de/open-source 

pluspol.de 

Marketing Kommunikation Internet 

Sponsored by

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. 

FreeBSD auf Raspberry Pi....................106 

Der kleine Rechner auf ARM-Basis ist ein Riesenrenner. 

Statt des Standard-OS auf Linux-Basis 

lässt sich darauf auch FreeBSD installieren. 

ika747, 123RF 

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

106 

freeX 

FreeBSD auf dem Raspberry Pi 

liv Friis-larsen, 123RF 

Raspberry PI 

Himbeere mit Sahne 

Ein FreeBSD-System auf einem Raspberry Pi ist eine interessante Alternative zu den bekannten Linux- 

Systemen. Die Installation geht nicht ganz so leicht von der Hand, aber man wird mit einem äußerst stabilen 

System belohnt. Das ADMIN-Magazin führt durch den Prozess. Jürgen Dankoweit 

Der Raspberry Pi kann praktisch alles. 

Als preiswerter Einplatinencomputer 

in der Größe einer Kreditkarte hat sich 

das Gerät der Raspberry-Pi-Foundation 

schnell zum Publikumsliebling gemausert 

– nicht nur unter Freunden 

der vielen eigens angepassten Linux- 

Distributionen, sondern auch unter 

jenen des ebenfalls freien FreeBSD- 

Betriebssystems [1]. 

Die wichtigste Komponente der Platine 

bildet das auf dem Raspberry Pi sitzende 

Ein-Chip-System von Broadcom. 

Es enthält einen 700-Megahertz-ARM- 

Prozessor sowie je nach Modell 256 

oder 512 MByte Arbeitsspeicher. Man 

spricht von einem System-on-a-Chip 

(SoC), da es die drei Komponenten 

Mikroprozessor, Grafikprozessor, 

Arbeitsspeicher und ein paar Peripheriebausteine 

vereint (siehe Abbildung 

1). Eine echte Festplattenschnittstelle 

fehlt dem Taschencomputer leider. 

Stattdessen kommen SD- oder MMC- 

Speicherkarten zum Einsatz. Darüber 

hinaus lassen sich am USB-Port externe 

Festplatten und USB-Sticks betreiben, 

allerdings nicht als Bootmedium. 

Tabelle 1 zeigt die Ausstattungen der 

beiden erhältlichen Modelle A und B im 

Detail. 

Der Raspberry Pi bietet eine frei programmierbare 

Schnittstelle, bekannt 

als General Purpose Input/Output 

(GPIO). Sie ermöglicht es Programmierern, 

ihrer Fantasie freien Lauf 

zu lassen, indem sie Leuchtdioden, 

Sensoren, Displays und andere Geräte 

darüber ansteuern. Lediglich Apparaturen 

mit hohem Schaltstrom sollte man 

nicht anschließen, denn diese könnte 

die GPIO beschädigen. 

Das System-on-a-Chip bietet sechs 

GPIOs, aber für Anwender ist vor allem 

eine interessant. Der auf der Platine 

mit P1 bezeichnete Anschluss lässt 

sich über eine Pfostenleiste mit 26 Pins 

ansteuern. Einige davon eignen sich 

als SPI (Serial Peripheral Interface) 

beziehungsweise I2C (Inter-Integrated 

Circuit). Diese von Motorola respektive 

Philips entwickelten Schnittstellen 

kommen in der Messtechnik zum 

Einsatz und bieten so vor allem für 

Anwendungen in dieser Richtung Potenzial. 

Revision 2 des Raspberry hat 

eine weitere GPIO-Schnittstelle mit der 

Bezeichnung P6 eingeführt. Sie bietet 

die Möglichkeit, den Raspberry zurückzusetzen 

oder zu starten, nachdem er 

heruntergefahren wurde. 

Zur Steuerung der GPIOs existieren Bibliotheken 

in zahlreichen Programmiersprachen. 

Ihre Portierung für FreeBSD 

läuft allerdings noch, danach steht 

auch dieses Betriebssystem für messtechnische 

Projekte bereit. 

Um die direkte Anbindung einer Kamera 

und eines LC-Displays kümmern 

sich ein CSI- (Camera Serial Interface) 

und ein DSI-Anschluss (Display Serial 

Interface). Für das CSI ist seit Mai 

2013 eine Kamera mit einer Auflösung 

von fünf Megapixel erhältlich; unter 

FreeBSD steuert diese der Treiber 

»bktr(4)« an. Ein passendes Display für 

den DSI-Anschluss befindet sich zwar 

in Entwicklung, allerdings steht der Er- 


freeX 


107 

scheinungstermin noch nicht fest. 

Die Raspberry-Betriebssysteme werden 

in sogenannte Tiers kategorisiert. 

Bei FreeBSD handelt es sich um eine 

Tier-2-Plattform. Das bedeutet, dass 

sich Tools und Kernel-Quelltexte in 

der Entwicklungsphase befinden. Das 

Betriebssystem eignet sich durchaus 

für Produktiveinsätze, aber Installation 

und Upgrade laufen nicht ganz so flüssig 

von der Hand. 

Karten austeilen 

Der FreeBSD-Bootvorgang auf dem 

Raspberry Pi setzt eine SD-Karte mit 

mindestens 4 GByte Speicherplatz und 

zwei passend präparierten Slices voraus. 

Slices heißen die BSD-Pendants 

zu den unter Windows und Linux als 

Partitionen bezeichneten Abschnitten, 

während unter BSD die im Slice enthaltenen, 

mit Buchstaben gekennzeichneten 

Segmente Partitionen heißen. 

Das erste Slice besteht aus einem 

bootfähigen FAT32- oder FAT16-Dateisystem. 

Beim Raspberry enthält nicht 

wie bei PCs üblich ein Flash-ROM die 

Firmware, sondern sie befindet sich im 

ersten Slice auf der SD-Speicherkarte 

(siehe Abbildung 2). 

Die Firmware eines Raspberry Pi enthält 

die folgenden Dateien: 

n Der Phase-3-Bootloader »start_ 

cd.elf« kommt zum Zug, wenn der 

für die GPU reservierte Speicher 

weniger als 32 MByte Kapazität 

aufweist (»gpu_mem=16«). Dabei 

handelt es sich um eine abgespeckte 

Version der Programmdatei »start. 

elf«. 

n Die Dateien »fixup.dat« und »fix up_ 

cd.dat« enthalten den Programmcode, 

der den Speicher zwischen 

GPU und CPU aufteilt. Sie kommen 

in der dritten Phase des Bootvorgangs 

zum Einsatz. »fixup_cd.dat« 

wird wiederum für GPU-Speichergrößen 

von 16 MByte benötigt. 

n Bei dem File »boot.scr« handelt es 

sich um ein Skript, das aus der Datei 

»boot_ubl.txt« ins Binärformat übertragen 

wurde und das zu ladende 

Betriebssystem definiert. Im Fall 

von FreeBSD entspricht es dem an 

den Raspberry Pi angepassten Bootloader 

»ubldr«. Dieses Tool lädt in 

LAN 

USB 

Audio 

Kamera 

CSI 

LAN-Chip 

der Folge den Betriebssystemkern 

von FreeBSD. 

n Die Datei »devtree.dat« enthält alle 

verwendeten Gerätetreiber. 

Das zweite Slice enthält schließlich das 

gewünschte Betriebssystem selbst, 

also FreeBSD. Um zu verstehen, wie 

man FreeBSD bootfähig auf der Speicherkarte 

installiert, folgt zunächst 

eine genauere Betrachtung des Bootvorgangs. 

Mit der Kirche ums Kreuz 

Der erste außergewöhnliche Schritt 

beim Booten des Raspberry Pi besteht 

darin, dass der Grafikprozessor (GPU) 

vor dem Mikroprozessor startet. Sobald 

der kleine Rechner mit Strom versorgt 

wird, startet ein Miniprogramm, das 

bei der Herstellung des Chips ins ROM 

gebrannt wurde. Es aktiviert zunächst 

das Boot-Slice der SD-Karte. Diesen Abschnitt 

des Bootprozesses nennt man 

First Stage und das Programm im ROM 

entsprechend Phase-1-Bootloader oder 

First Stage Bootloader. Darüber erhält 

das System Zugriff auf den Phase-2- 

Bootloader oder Second Stage Bootloader, 

zu dessen Programmcode die 

Datei »bootcode.bin« gehört. 

Weil Mikroprozessor und Arbeitsspeicher 

an dieser Stelle immer noch nicht 

aktiviert sind, übernimmt die GPU 

den weiteren Bootvorgang. Dazu lädt 

HDMI 

GPU, CPU, 

RAM 

Video 

(FBAS) 

Reset 

Abbildung 1: Die Bausteine und Anschlüsse eines Raspberry Pi, Modell B. 

GPIO 

das System den Programmcode aus 

»bootcode.bin« in den Cache der GPU 

und führt ihn aus. Erst jetzt wird der 

Arbeitsspeicher aktiviert und die GPU 

liest die Datei »start.elf« von der Speicherkarte. 

Sie steht für den Third Stage 

Bootloader oder Phase-3-Bootloader. 

Es handelt sich dabei um die Firmware 

des Grafikprozessors. 

Der jetzt folgende dritte Schritt ist der 

wichtigste während der gesamten 

Initialisierungsphase. Der Third Stage 

Bootloader enthält Programmcode, 

der die Aufteilung des Arbeitsspeichers 

zwischen GPU und CPU vornimmt und 

anschließend die Konfigurationsdatei 

»config.txt« verarbeitet. 

Im letzten Schritt wird die CPU initialisiert. 

Dazu lädt die GPU das Betriebssystem 

für den Mikroprozessor gemäß 

des Parameters »kernel=« in der Datei 

»config.txt« und aktiviert die CPU. 

Bei FreeBSD lädt der Phase-3-Bootloader 

die Datei »uboot.img«. Dabei 

handelt es sich um ein Betriebssystem 

für die CPU; es fährt in diesem Fall also 

das FreeBSD-System hoch. Abbildung 4 

illustriert den Bootvorgang. 

Die Kompilierung von FreeBSD für den 

Raspberry Pi geschieht unter einem 

existierenden FreeBSD-Host-System. 

Dabei spielt es keine Rolle, ob dieses 

nativ oder in einer virtuellen Umgebung 

installiert ist. Mit der stabilen Ver- 

Betriebsspannung 

Display 

DSI 

SD-Card 


Admin 

Ausgabe 03-2014

108 

freeX 


sion 10 ist man auf der sicheren Seite, 

nur etwas abenteuerlustigere Raspberry-Besitzer 

weichen auf die momentan 

unter »CURRENT« firmierende Version 

11 aus. 

Für die Installation legt man auf dem 

Host-System als Root ein separates 

Verzeichnis an. Das verhindert, dass 

sich Dateien des Hosts mit den für den 

Raspberry kompilierten vermischen; 

andernfalls käme es spätestens bei der 

Aktualisierung des Host-Systems zum 

Chaos. 

$ su root 

# mkdir /home/raspberry 

# cd /home/raspberry 

Damit FreeBSD auf dem Raspberry 

bootet, benötigt man außerdem den 

Bootloader: 

# fetch http://www.dankoweit.de/U 

Downloads/Raspberry/U 

freebsd‐uboot‐20140101.tar.gz 

Seit FreeBSD 9.2 kommt für die Verwaltung 

des Betriebssystem-Sourcecodes 

Subversion statt Csup zum Einsatz. Die 

Installation erfolgt – falls nicht ohnehin 

bereits geschehen – über die Paketverwaltung: 

# pkg_add ‐r subversion 

Alternativ holt man Subversion vom 

Portstree: 

# make ‐C /usr/ports/devel/subversion U 

install clean 

Der letzte Schritt in der Vorbereitungsphase 

betrifft das Anlegen eines Disk- 

Image für die SD-Karte. Es sollte mindestens 

512 MByte bemessen; besser 

sind 1024 MByte, damit Platz für den 

Portstree bleibt. Zunächst legt man 

mit »dd« eine leere Datei an, die das 

Kommando »mdconfig« dann in eine 

Memory Disk mit dem Treiber »md0« 

umwandelt: 

# dd if=/dev/zero of=./rpi.img bs=1m U 

count=1024 

# mdconfig ‐a ‐t vnode ‐f ./rpi.img U 

md0 

Da sich die Datei »./rpi.img« wie eine 

Festplatte verhält, lassen sich im folgenden 

Schritt die einzelnen Slices 

anlegen. Als Partitionierungsschema 

ist die Auswahl von MBR (Master Boot 

Record) zwingend notwendig, weil die 

Firmware des Raspberry nur damit zurecht 

kommt. 

Zuerst erstellt und formatiert man das 

Boot-Slice, auf das die Raspberry-Firmware 

kommt. Bei dessen Größe reichen 

32 MByte aus: 

# gpart create ‐s MBR md0 

# gpart add ‐s 32m ‐t '!12' md0 

# gpart set ‐a active ‐i 1 md0 

# newfs_msdos ‐L boot ‐F 16 /dev/md0s1 

Danach legt man das FreeBSD-Slice an 

und formatiert es ebenfalls. Es nimmt 

den gesamten restlichen Speicherplatz 

ein: 

# gpart add ‐t freebsd md0 

# gpart create ‐s BSD md0s2 

# gpart add ‐t freebsd‐ufs md0s2 

# newfs ‐U ‐j /dev/md0s2a 

Es folgt der Download der Quelltexte 

der gewünschten FreeBSD-Version. Der 

folgende Aufruf holt FreeBSD 10 aus 

dem Subversion-Repository: 

# svn co svn://svn.freebsd.org/base/U 

stable/10./fbsd 

Diese Eingabe holt alternativ FreeBSD 

»CURRENT«, also derzeit Version 11: 

# svn co svn://svn.freebsd.org/base/ U 

head ./fbsd 

In beiden Fällen landet der Quellcode 

im Unterverzeichnis »fbsd«, der Aufruf 

sollte deshalb aus dem anfangs eigens 

für diesen Zweck erstellten Verzeichnis 

»/home/raspberry« erfolgen. 

n Tabelle 1: Die Modellvarianten des Raspberry Pi 

Modell A 

Modell B 

Preis 25 bis 30 Euro 40 bis 45 Euro 

Größe 

85,60mm x 53,98mm x 17mm (Kreditkartengröße) 

System-on-Chip (SoC): 

Broadcom BCM2835 

Prozessor 

ARM1176JZF-S (700 MHz) 

Grafik 

Broadcom VideoCore IV 

Arbeitsspeicher (SDRAM) 256 MByte 512 MByte (ab November 2012) 

USB-2.0-Anschlüsse 1 2 (über integrierten Hub) 

Video 

FBAS (Cinch), HDMI 

Ton 

3,5-mm-Klinkenstecker (analog) oder HDMI (digital) 

Nicht flüchtiger Speicher 

Kartenleser für SD (SDHC und SDXC)/MMC/SDIO 

Netzwerk – 10/100-MBit-Ethernet-Controller 

(LAN9512 von SMSC) 

Schnittstellen 

Bis 17 GPIO-Pins, SPI, I2C, UART, EGL 

Echtzeituhr – 

Leistungsaufnahme 5 V, 500 mA (2,5 Watt) 5 V, 700 mA (3,5 Watt) 

Stromversorgung 

5-V-Micro-USB-Anschluss (Micro-B) 

Betriebssysteme GNU/Linux, BSD, RISC OS, Plan 9 

Speicherteilung 

Als nächstes steht die Zuweisung von 

Arbeitsspeicher an. GPU und CPU 

teilen sich das RAM, man berechnet 

also deren jeweiligen Anteil. Wie viel 

Speicher die GPU benötigt, hängt vom 

angedachten Anwendungsfall ab: Bei 

grafik intensiven Applikationen sollte 

man ihr 64 oder 128 MByte reservieren, 

bei textlastigem Betrieb genügen 16 

oder 32 MByte. Die Differenz vom insgesamt 

verfügbaren Speicher, also je 

nach Modell 256 oder 512 MByte, ergibt 

das für die CPU verbleibende RAM. Der 

folgende Shell-Aufruf berechnet sie und 

gibt direkt den anschließend benötigten 

Hexadezimalwert aus. RPI und GPU 

stehen für die Gesamtgröße des Arbeitsspeichers 

und den für die GPU zu 

reservierenden Anteil, beide Angaben 

jeweils in MByte: 


freeX 


109 

# printf "%X\n" $(((RPI‐U 

GPU)*1024*1024)) 

Den so ermittelten Wert, trägt man in 

die Konfigurationsdatei »rpi.dts« im 

Verzeichnis »sys/boot/fdt/dts« ein. Darin 

sucht man diese Zeilen: 

memory { 

device_type = "memory"; 

reg = ; /* 128 MByte */ 

}; 

Den vorgegebenen Wert »08000000« 

(128 MByte) ersetzt man durch den 

oben berechneten Hexadezimalwert. 

Um den Kernel des Betriebssystems anzupassen, 

findet man in »sys/arm/conf/ 

RPI‐B« die passende Konfigurationsdatei. 

Unter [2] stellt der Autor ein funktionierendes 

Beispiel zur Verfügung. 

Grundsätzlich gilt aufgrund des im 

Vergleich zu modernen PCs sehr eingeschränkten 

Arbeitsspeichers, dass man 

nur wirklich notwendige Funktionen 

aktivieren sollte. Die Monitorausgabe 

über den HDMI-Anschluss aktiveren 

beispielsweise die folgenden Zeilen: 

device sc 

options SC_DFLT_FONT 

makeoptions SC_DFLT_FONT=cp850 

Außerdem kommentiert man diese 

Zeile aus: 

device vt 

Wer eine Maus an den Raspberry anschließen 

möchte, aktiviert den Treiber 

für USB-Mäuse: 

device ums 

Crosscompiling 

Nach der Konfiguration des gewünschten 

Kernels geht es nun zum Kompilieren. 

Da die Zielplattform eine andere 

als die des kompilierenden Systems ist, 

kommt Crosscompiling zum Einsatz. 

In diesem Beispiel läuft FreeBSD auf 

einem 32- oder 64-Bit-System von Intel 

oder AMD, während der Zielplattform 

Raspberry eine ARM-CPU zugrunde 

liegt. Deshalb setzt man zunächst die 

folgende Umgebungsvariable: 

SD-Card 

Boot-Block: 

512 Byte 

# export TARGET_ARCH=armv6 

Der nächste Befehl generiert die fürs 

Crosscompiling nötigen Tools wie Compiler 

und Linker: 

# make kernel‐toolchain 

Boot-Slice: 

512 Byte FAT16- oder FAT32-Slice: 

32MiB 

Nun erfolgt die Übersetzung des Kernels. 

Die Option »WITH_FDT=yes« 

ist hierbei nötig; sie aktiviert den 

Flatten ed Device Tree, über den der 

FreeBSD-Kernel den einzelnen Geräten 

Treiber zuweist. 

# make KERNCONF=RPI‐B WITH_FDT=yes U 

buildkernel 

Dieser Schritt dauert je nach Hardware 

etwa eine halbe Stunde. Es folgt der 

gleiche Prozess fürs Userland, der noch 

etwa viermal soviel Zeit in Anspruch 

nimmt: 

# make MALLOC_PRODUCTION=yes buildworld 

Ist die Kompilierung fehlerfrei durchgelaufen, 

ermittelt der folgende Befehl 

die restlichen Umgebungsvariablen für 

die spätere Installation: 

# buildenv=`make buildenvvars | U 

sed 's/MACHINE_ARCH=armv6/MACHINE_U 

ARCH=arm/'` 

Nun geht es weiter mit dem Raspberryspezifischen 

Bootloader: 

# cd sys/boot 

# eval $buildenv make MK_NAND=no U 

BOOTCODE.BIN, START.ELF, 

CONFIG.TXT, UBOOT.IMG, 

BOOT.SCR, DEVTREE.DAT 

FreeBSD-Slice: 

bootloader 

boot/kernel/kernel 

sbin/init, /etc/rc.conf 

restliches Betriebssystem 

UFS2-Slice: 

mind. 512 MiB 

Abbildung 2: Einteilung einer SD-Karte für den Einsatz von FreeBSD auf dem Raspberry Pi. 

UBLDR_LOADADDR=0x2000000 clean obj all 

# cd /home/raspberry/fbsd 

Installation 

Damit ist der langwierigste Teil der 

Arbeit abgeschlossen. Der folgende Installationsvorgang 

verlangt dennoch 

die gleiche Sorgfalt wie die zurückliegenden 

Schritte. Man hängt als erstes 

das Firmware-Slice ein und kopiert den 

Bootloader und die Device-Datenbank 

darauf: 

# mount ‐t msdosfs /dev/md0s1 /mnt 

# tar ‐C /mnt ‐xvzf /home/raspberry/U 

freebsd‐uboot‐20140101.tar.gz 

# cp ‐iv /usr/obj/arm.armv6/home/U 

raspberry/ fbsd/sys/boot/arm/uboot/U 

ubldr /mnt/ 

# cp ‐iv /usr/obj/arm.armv6/home/U 

raspberry/ fbsd/sys/RPI‐B/rpi.dtb U 

/mnt/devtree.dat 

Weiterhin editiert man die Konfiguration, 

damit sowohl CPU als auch GPU 

die Geräte korrekt ansprechen: 

device_tree=devtree.dat 

device_tree_address=0x100 

disable_commandline_tags=1 

gpu_mem_512=GPUMEM 

gpu_mem_256=GPUMEM 

Der Platzhalter GPUMEM definiert die 

zuvor ermittelte Speichergröße für die 

GPU. Die Parameter »gpu_mem_512« 

und »gpu_mem_256« repräsentieren 

einen Raspberry Pi mit 512 MByte beziehungsweise 

256 MByte physischen 

Arbeitsspeicher. 


Admin 

Ausgabe 03-2014

110 

freeX 


Abbildung 3: Eine Remote-Sitzung per SSH an einem Raspberry Pi mit 

FreeBSD »CURRENT«. 

An dieser Stelle weicht die offizielle 

Dokumentation ab, sie legt zu diesem 

Zweck den Parameter »gpu_mem« 

nahe. Das ADMIN-Magazin hat im Test 

jedoch herausgefunden, dass in der 

Realität nur die Angabe »gpu_mem_ 

(512|256)« die RAM-Größe korrekt 

einstellt. 

Das Boot-Slice hängt man anschließend 

aus und mountet das zweite Slice. 

Dort installiert man das Betriebssystem 

nebst Kernel: 

# umount /mnt 

# mount /dev/md0s2a /mnt 

# make KERNCONF=RPI‐B DESTDIR=/mnt U 

installkernel 

# make DESTDIR=/mnt DB_FROM_SRC=1 U 

installworld distribution 

Damit sind die Installationsarbeiten 

abgeschlossen, es fehlen nur noch 

einige Einstellungsoptionen. Zunächst 

ergänzt man die Konfiguration des 

Kernel-Bootloaders in »/mnt/boot/loader.rc«. 

Damit der Kernel den Flattened 

Device Tree findet, teilt man ihm die 

Einsprungadresse mit: 

fdt addr 0x100 

Des Weiteren muss der Kernel wissen, 

von welchem Device er booten soll. 

Dafür ist die Filesystem-Tabelle in 

»/mnt/etc/fstab« zuständig. Da außerdem 

meistens das »proc«-Filesystem 

benötigt wird, trägt man dieses gleich 

mit ein: 

/dev/mmcsd0s2a / ufs U 

rw,noatime 1 1 

procfs /proc procfs rwU 

0 0 

Der Treiber »/dev/ 

mmcsd0« spricht die 

Speicherkarte an. 

Das Suffix »s2a« bedeutet, 

dass es sich 

um das zweite Slice 

und die Partition »a« 

handelt. Das mit UFS 

formatierte Medium 

wird zum Schreiben 

und Lesen (»rw«) ins 

Root-Directory »/« 

gemountet. Um die 

Schreibgeschwindigkeit nicht auszubremsen, 

wird der Zeitstempel des 

Zugriffs (Access Time) an dieser Stelle 

nicht protokolliert (»noatime«). 

Nun überarbeitet man die zentrale 

FreeBSD-Konfiguration in »/mnt/etc/ 

rc.conf«. Die Netzwerkkonfiguration per 

DHCP gestaltet sich einfach: 

hostname="raspberry.your.domain" 

ifconfig_ue0="DHCP" 

Ohne DHCP-Server setzt man die Standardroute 

manuell; ansonsten bliebe 

der Raspberry im Netz unerreichbar: 

ifconfig_ue0="IP‐Adr netmask Netzmaske" 

defaultrouter="DefRouter" 

Die Platzhalter IP‐Adr und Netzmaske 

stehen für die IPv4-Adresse und Netzmaske 

des Subnetzes. Mit DefRouter 

gibt man die Adresse des Default- 

Routers an, über den sämtliche Datenpakete 

laufen. Zusätzlich konfiguriert 

man die Namensauflösung in »/mnt/ 

etc/resolv.conf«: 

nameserver DNS‐Adr 

In »/mnt/etc/hosts« muss zudem diese 

Zeile stehen: 

RPI‐Adr raspberry.heim.netz raspberry 

Schließlich aktiviert man noch zwei 

essenzielle Tools: Den Secure-Shell- 

Daemon »sshd« und den NTP-Client. 

Letzterer ist wichtig, da der Raspberry 

keine batteriegestützte Echtzeituhr besitzt, 

er benötigt deshalb nach jedem 

Neustart wieder die korrekte Uhrzeit. 

Diese Information holt er vom Zeitserver 

mit der IP-Adresse NTP‐Adr: 

sshd_enable="YES" 

ntpdate_enable="YES" 

ntpdate_hosts="NTP‐Adr" 

Abschließend schaltet man das Speichern 

von Dump-Files ab: 

dumpdev="NO" 

Damit man nach dem ersten Start die 

Möglichkeit hat, sich am System als 

Root-User zu authentifizieren, fügt man 

in der Konfiguration des SSH-Daemons 

»/mnt/etc/ssh/sshd_config« diese Zeile 

hinzu: 

PermitRootLogin yes 

Man deaktiviert weiterhin den Authentifizierungsprozess 

in »/mnt/etc/pam.d/ 

sshd«, indem man die folgende Zeile 

auskommentiert. 

auth required pam_unix.so no_warn U 

try_first_pass 

Stattdessen kommt die folgende Zeile 

hinzu: 

auth required pam_permit.so 

Abschließend setzt man die korrekte 

Zeitzone. Für Mitteleuropa erledigt das 

diese einfache Kopieraktion: 

# cp ‐iv /mnt/usr/share/zoneinfo/ U 

Europe/Berlin /mnt/etc/localtime 

Die anderen Zeitzonendefinitionen 

liegen auch im Verzeichnis »/mnt/usr/ 

share/zoneinfo/« und kommen bei Bedarf 

auf die gleiche Weise zum Einsatz. 

Auf die Karte! 

Abschließend kopiert man jetzt das 

fertige Image auf die Speicherkarte. In 

der hier vorgestellten Installation und 

dem zugrunde liegenden System repräsentiert 

»/dev/da0« die Speicherkarte; 


freeX 


111 

das Device kann bei anderen Systemen 

abweichen: 

# umount /mnt 

# mdconfig ‐d ‐u md0 

# dd if=/root/rpi.img of=/dev/da0 bs=1m 

Stapellauf 

Nachdem man die Speicherkarte in den 

Slot gesteckt und die Stromversorgung 

an den Raspberry Pi angeschlossen 

hat, startet der Bootvorgang. Man 

sieht auf dem Monitor die von FreeBSD 

bekannten Boot meldungen. Die grüne 

Leuchtdiode bleibt dunkel, da der 

FreeBSD-Kernel sie ignoriert. 

Gelegentlich stoppt ein Bootvorgang 

mit einer Fehlermeldung, derzufolge 

das Boot-Slice fehlt. Das liegt in der 

Regel daran, dass manche SD-Karten 

nicht fehlerfrei mit dem Controller des 

Raspberry harmonieren. Meist klappt 

es beim zweiten Bootversuch. 

Nach dem ersten Login per SSH reaktiviert 

man als erstes die bei der Grundkonfiguration 

ausgeschalteten Sicherheitsvorkehrungen. 

Root sollte sich 

dann nicht mehr per SSH anmelden 

dürfen, stattdessen legt man für diesen 

Zweck einen gewöhnlichen Benutzer 

an, beispielsweise »pi« (Abbildung 3): 

# mkdir ‐p /home/pi 

# pw group add users ‐g 1001 

# pw user add pi ‐s/bin/tcsh ‐d /home/U 

pi ‐g users ‐G wheel 

# passwd ‐l pi 

Nun empfiehlt es sich, den Speicherplatz 

auf dem Betriebssystem-Slice zu 

vergrößern, damit auch zusätzliche 

Tools darauf Platz finden. »gpart« zeigt 

die aktuelle Partitionierung an; in den 

ersten beiden Spalten finden sich die 

Größenangaben: 

# gpart show mmcsd0 

=> 1 15564799 mmcsd0 MBR (7.4G) 

1 8 ‐ free ‐ (4.0K) 

9 65529 1 !12 [active] (32M) 

65538 983034 2 freebsd (480M) 

1048572 14516228 ‐ free ‐ (6.9G) 

Das Slice mit Nummer 2 vom Typ 

»freebsd« enthält das Betriebssystem 

und wird wie folgt bearbeitet: 

# gpart resize ‐i 2 mmcsd0 

mmcsd0 resized 

# gpart show mmcsd0 

=> 1 15564799 mmcsd0 MBR (7.4G) 

1 8 ‐ free ‐ (4.0K) 

9 65529 1 !12 [active] (32M) 

65538 15499260 2 freebsd (7.4G) 

15564798 2 ‐ free ‐ (1.0K) 

Nach dieser Aktion startet man das 

System neu und lässt sich danach die 

aktuelle Slice-Tabelle anzeigen: 

# gpart show 

=> 1 15564799 mmcsd0 MBR (7.4G) 

1 8 ‐ free ‐ (4.0K) 

9 65529 1 !12 [active] (32M) 

65538 15499260 2 freebsd (7.4G) 

15564798 2 ‐ free ‐ (1.0K) 

=> 0 15499260 mmcsd0s2 BSD (7.4G) 

0 983034 1 freebsd‐ufs (480M) 

983034 14516226 ‐ free ‐ (6.9G) 

Wichtig ist hierbei das Slice mit dem 

Namen »mmcsd0s2«, das an die neue 

Verteilung angepasst werden muss: 

# gpart resize ‐i 1 mmcsd0s2 

mmcsd0s2a resized 

Zur Kontrolle hilft ein Blick auf die Ausgabe 

des folgenden Kommandos: 

# gpart show mmcsd0s2 

=> 0 15499260 mmcsd0s2 BSD (7.4G) 

0 15556606 1 freebsd‐ufs (7.4G) 

15556606 8182 ‐ free ‐ (4M) 

Zum Schluss werden die neu hinzugekommenen 

Blöcke formatiert: 

# growfs / 

[...] 

OK to grow filesystem on /dev/mmcsd0s2a, 

mounted on /, from 480MB to 7.4GB? 

[Yes/No] Yes 

super‐block backups (for fsck ‐b #) at: 

983232, [...], 15483072 

Nach Abschluss dieser Tätigkeiten startet 

man zur Sicherheit den Raspberry 

neu und beobachtet die Ausgabe auf 

dem Monitor. Wie bei anderen Systemen 

gilt hier, dass ein geordneter 

Shutdown vor dem Kappen der Stromversorgung 

für die Konsistenz des 

Datei systems notwendig ist: 

# shutdown ‐h now 

Über ein Powermanagement-System 

wie APM oder ACPI verfügt der Raspberry 

Pi übrigens nicht, deshalb kann 

er sich nach dem System-Shutdown 

nicht per Software ausschalten. Ohne 

angeschlossenen Bildschirm bleiben 

nur zwei Möglichkeiten: Entweder man 

wartet nach dem Befehl zum Herunterfahren 

etwa zehn Minuten, bevor man 

das Gerät ausschaltet, oder man hängt 

das Dateisystem als nur lesbar (Read 

Only) ein. Dazu ändert man den Eintrag 

in »/etc/fstab« von 

/dev/mmcsd0s2a / ufs rw,noatime 1 1 

zu 

/dev/mmcsd0s2a / ufs ro,noatime 1 1 

Bei dieser Konfiguration kann das System 

allerdings keine Protokolle mehr 

ins Verzeichnis »/var/log/« schreiben. 

Abhilfe schafft die Möglichkeit, die Systemprotokolle 

stattdessen übers Netz 

auszuliefern. In der Datei »/etc/rc.conf« 

fügt man zu diesem Zweck die folgende 

Zeile ein: 

SD-Card 

Bootsektor 

Boot-Slice 

BOOTCODE.BIN 

START.ELF 

CONFIG.TXT 

UBOOT.IMG 

FreeBSD-Slice 

FreeBSD-Kernel 

Raspberry Pi 

SoC 

GPU 

CPU 

Abbildung 4: Schematische Darstellung des Bootvorgangs 

eines Raspberry Pi. 


Admin 

Ausgabe 03-2014

112 

freeX 


syslogd_enable="YES" 

Nun trägt man das Zielsystem in der 

Syslogd-Konfiguration ein und kommentiert 

alle anderen darin enthaltenen 

Zeilen aus: 

*.* @Zielsystem 

Der Syslog-Daemon des Zielsystems 

muss die vom Raspberry eingehenden 

Protokolle allerdings explizit akzeptieren. 

Handelt es sich dabei ebenfalls um 

ein FreeBSD-System, sorgt dafür dieser 

Eintrag in »/etc/rc.conf«. Bei Linux-Systemen 

erfolgt die Konfiguration etwa in 

»/etc/rsyslog.conf« oder dem Verzeichnis 

»/etc/rsyslog.d/«: 

syslogd_enable="YES" 

syslogd_flags="‐a $netzwerk/$maske ‐4 \ 

‐b ${adr_syslog}" 

Administrative Aufgaben 

Nach der nun abgeschlossenen Installation 

und Grundkonfiguration von 

FreeBSD bietet der Raspberry Pi eine 

gute Ausgangsbasis für weitere Projekte 

mit diesem Rechnersystem. Die 

Vielzahl portierter Anwendungen legt 

das Fundament für vielfältige Einsatzmöglichkeiten. 

Wie immer unter FreeBSD stehen auch 

auf dem Raspberry-System Softwarepakete 

zum Selbstkompilieren oder 

bereits übersetzte zur Wahl. Ersteres 

erleichtert der Portstree, indem er die 

Abhängigkeiten automatisch auflöst. 

Bei der für die Raspberry-Plattform ohnehin 

überschaubaren Auswahl fertiger 

Softwarepakete empfiehlt sich deshalb 

diese Methode. 

Für die Portstree-Installation meldet 

man sich zunächst wieder am Raspberry 

an und wechselt zum Root-User. 

Danach holt man im Verzeichnis »/ 

usr/« per FTP das Tar-File mit der Ports- 

Struktur: 

# su root 

# cd /usr 

# fetch ftp://ftp.freebsd.org/pub/U 

FreeBSD/ports/ports/ports.tar.gz 

# tar ‐xzvf ports.tar.gz 

Portstree inklusive 

Alternativ bietet es sich an, den Portstree 

bereits während der Image-Konfiguration 

auf die SD-Karte zu laden und 

zu entpacken. Das erfolgt in ähnlicher 

Weise wie zuvor, aber erst nachdem 

das Betriebssystem im Raspberry- 

Image gespeichert ist: 

# cd /mnt/usr 

# fetch ftp://ftp.freebsd.org/pub/U 

FreeBSD/ports/ports/ports.tar.gz 

# tar ‐xzvf ports.tar.gz 

Der große Vorteil dieser Methode liegt 

darin, dass sie eine Menge Zeit spart, 

weil die Host-Maschine üblicherweise 

mehr Rechenleistung bietet als der rechenschwache 

Raspberry Pi. Allerdings 

fällt dafür das Image größer aus, man 

sollte mindestens 200 MByte einplanen. 

Fensterln mit FreeBSD 

Die Hardware des Raspberry Pi stellt 

einen leistungsfähigen Grafikprozessor 

und einen HDMI-Port zum Anschluss 

eines Monitors oder anderer Videokomponenten 

zur Verfügung. Um diese zu 

nutzen, liegt es nahe, Xorg zu installieren. 

Desktop-Umgebungen wie Gnome 

oder KDE fallen aufgrund der begrenzten 

Speicherkapazität jedoch aus. Der 

Window-Manager TWM bietet eine angemessenere 

grafische Umgebung. 

Die Installation von Xorg verläuft auf 

dem Raspberry etwas anders als auf 

einem klassischen Desktop-System. 

Derzeit passen die Entwickler den gesamten 

Portstree auf das Zielsystem 

FreeBSD-ARM an; noch kommt es aber 

vereinzelt zu Fehlern beim Kompilie- 

n Listing 1: »xorg.conf« für den Raspberry Pi 

01 Section "Files" 

02 EndSection 

03 

04 Section "Module" 

05 Load "dbe" 

06 Disable "dri" 

07 Disable "dri2" 

08 Disable "glx" 

09 SubSection "extmod" 

10 Option "omit xfree86‐dga" 

11 EndSubSection 

12 EndSection 

13 

14 Section "ServerFlags" 

15 Option "AIGLX" "false" 

16 Option "NoAccel" "True" 

17 Option "NoDRI" "True" 

18 Option "DRI" "False" 

19 Option "DRI2" "False" 

20 EndSection 

21 

22 Section "InputDevice" 

23 Identifier "Keyboard1" 

24 Driver "kbd" 

25 EndSection 

26 

27 Section "InputDevice" 

28 Identifier "Mouse1" 

29 Driver "mouse" 

30 Option "Protocol" "auto" 

31 Option "Device" "/dev/sysmouse" 

32 EndSection 

33 

34 Section "Monitor" 

35 Identifier "Monitor" 

36 Mode "1024x600" 

37 DotClock 25.175 

38 HTimings 1024 1048 1148 1200 

39 VTimings 600 610 620 700 

40 EndMode 

41 EndSection 

42 

43 Section "Device" 

44 Identifier "Generic FB" 

45 Driver "scfb" 

46 Option "NoAccel" "True" 

47 EndSection 

48 

49 Section "Screen" 

50 Identifier "Screen" 

51 Device "Generic FB" 

52 Monitor "Monitor" 

53 DefaultDepth 16 

54 SubSection "Display" 

55 Depth 16 

56 Modes "1024x600" 

57 EndSubsection 

58 EndSection 

59 

60 Section "ServerLayout" 

61 Identifier "layout" 

62 Screen 0 "Screen" 0 0 

63 InputDevice "Mouse1" "CorePointer" 

64 InputDevice "Keyboard1" "CoreKeyboard" 

65 EndSection 


freeX 


113 

ren – Bug-Reports helfen den Programmierern, 

Fehler schneller zu finden und 

auszuräumen. 

Um Xorg unfallfrei auf einem Raspberry 

zu installieren, steht an erster Stelle 

unbedingt die Aktualisierung des Portstrees, 

um alle notwendigen Patches zu 

erhalten. Zudem sollte man den direkten 

Zugriff auf die Grafikhardware per 

DRI (Direct Rendering Infrastructure) 

ausschalten. Das erledigt diese Zeile in 

der Datei »/etc/make.conf«: 

WITHOUT_DRI=yes 

Das anschließende Kompilieren nimmt 

wieder viel Zeit in Anspruch. Anschließend 

erfolgt die manuelle Xorg-Konfiguration. 

Listing 1 zeigt eine funktionierende 

Version von »/etc/X11/xorg. 

conf«. Von besonderem Interesse sind 

die Abschnitte »ServerFlags« und »Module«. 

Auch hier ist die Deaktivierung 

der DRI-Unterstützung nötig, damit 

Xorg startet. Außerdem aktiviert man 

den Grafiktreiber im Abschnitt »Device« 

mit diesen Einträgen: 

Driver "scfb" 

Option "NoAccel" "True" 

Entfernter Bildschirm 

Wem es zu lange dauert, bis Xorg 

kompiliert ist, dem bietet Remote-X 

eine Alternative. Dabei erfolgt die 

Bildschirm ausgabe statt auf dem 

Raspberry-Monitor übers Netzwerk. 

Möchte man beispielsweise Xclock auf 

dem Raspberry starten und auf einem 

anderen Rechner anzeigen – andere 

grafische Programme funktionieren auf 

die gleiche Weise –, installiert man zunächst 

das Programm selbst aus dem 

entsprechenden Portstree-Verzeichnis: 

# cd /usr/ports/x11‐clocks/xclock 

# make install clean 

Die Authentifizierung setzt außerdem 

die Installation von Xauth für die 

Authentifizierung des verwendeten X- 

Clients voraus: 

# cd /usr/ports/x11/xauth 

# make install clean 

Abbildung 5: Das Xclock-Fenster rechts stammt vom Raspberry, gestartet via SSH (links). 

Die folgende Zeile in der Konfiguration 

des SSH-Servers auf dem Raspberry, 

»/etc/ssh/sshd_config«, aktiviert das X- 

Forwarding. Damit landen alle X11-Protokoll-Tokens 

durch einen verschlüsselten 

Tunnel automatisch auf dem SSH- 

Client-System. Damit das klappt, muss 

übrigens auch die Namensauflösung 

funktionieren. 

X11Forwarding yes 

Die Client-Seite benötigt die Tools 

Xauth und Xhost sowie einen Display- 

Manager (XDM, GDM oder KDM). Des 

Weiteren ergänzt man die Konfiguration 

des SSH-Clients um die folgenden 

Angaben: 

Host * 

ForwardAgent yes 

ForwardX11 yes 

XAuthLocation /usr/bin/xauth 

ForwardX11Trusted yes 

Es folgt der Aufruf von Xhost auf dem 

Client, damit dieser die Daten der X11- 

Applikationen des Raspberry annimmt: 

$ xhost +IP‐Adresse Raspberry 

Meldet man sich anschließend mit »ssh 

pi@raspberry X11‐Applikation« auf dem 

Raspberry an, erscheint auf dem Desktop 

des Clients ein Fenster mit der auf 

dem kleinen Rechner gestarteten X11- 

Anwendung. Abbildung 5 zeigt dies am 

Beispiel von Xclock. 

Zur Anwendung 

Der FreeBSD-Raspberry bietet viele 

Anwendungsmöglichkeiten, vom einfachen 

Router, bei Bedarf mit Paketfilter, 

über einen TOR-Anonymisierungsproxy 

bis zum Viren-Scanner und Spam-Filter 

für Windows-Netzwerke. (csc) n 

n Info 





[1] FreeBSD: [http:// www. freebsd. org] 

[2] Homepage des Autors mit Kernelkonfiguration 

und Images: [http:// www. dankoweit. de/ 

FreeBSD/ hp_freebsd_raspberry. html] 

[3] FreeBSD Installieren – Konfigurieren – Administrieren, 

J. Dankoweit (Hrsg.), C&L-Verlag 

[4] FreeBSD-Handbuch: [http:// www. freebsd. org/ 

doc/ de_DE. ISO8859‐1/ books/ handbook/] 

[5] FreeBSD-Entwickler-Handbuch: 

[http:// www. freebsd. org/ doc/ de/ books/ 

developers‐handbook/] 

[6] Raspberry Pi: [http:// www. raspberry. org] 

[7] Raspberry-Pi-Dokumentation: 

[http:// www. raspberrypi. org/ technical‐helpand‐resource‐documents] 


Admin 

Ausgabe 03-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: spectral, 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–2014 Medialinx AG 

n Autoren dieser Ausgabe 

Paul Brown Kontrolldatei 64 

Jürgen Dankoweit Himbeere mit Sahne 106 

Thomas Drilling Entspann Dich 40 

Thomas Drilling Schrittmacher 86 

Thomas Joos Fenster-Reparatur 46 

Thomas Joos Flotter Feger 92 

Hannes Kasparick Der Baum im Netzwerk 18 

Charly Kühnast Verschlüsselte Last 32 

Martin Loschwitz Maschen knüpfen 58 

Martin Loschwitz Orchesterprobe 74 

Thorsten Scherf Polyglotter Manager 14 

Tim Schürmann Narkosemittel 68 

Nirmal Sharma Durchs Fenster 96 

Ralf Spenneberg Einlasskontrolle 80 

Pierre Strohmeier Rettungsübung 52 

Ronny Trommer Automatisch überwacht 24 

Thomas Zeller Sicherer Kreislauf 36 

n Inserentenverzeichnis 

1&1 Internet AG http://www.einsundeins.de 9 

ADMIN http://www.admin-magazin.de 89, 103 

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

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

hostNET Medien GmbH http://www.hostnet.de 2 

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

Linux-Magazin http://www.linux-magazin.de 71, 115 

M-Promotion http://www.poland-it.pl 67 

Medialinx AG http://www.medialinx-gruppe.de 79, 104 

Medialinx IT-Academy http://www.medialinx-academy.de 45, 55, 101 

outbox AG http://www.outbox.de 35 

PlusServer AG http://www.plusserver.de 17, 31, 39, 51, 57, 63 

ppedv http://www.visualstudio1.de 15 

Strato AG http://www.strato.de 116 

Thomas Krenn AG http://www.thomas-krenn.com 7 

WHD.global 2013 http://www.worldhostingdays.com 73 

Windows Phone User http://www.windows-phone-user.de 61 

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. 

n Vorschau: ADMIN 04/2014 erscheint am 13. März 2014 

watchara rojjanasain, 123RF 

Netzwerk-Dateisysteme 

Wohin mit den ganzen Daten? 

Will man sie netzwerkweit 

speichern, bieten sich neben 

den Klassikern NFS und Samba 

auch jede Menge Alternativen 

an. Mit interessanten Features 

für zuverlässiges Storage im 

Netz liefern sich GlusterFS und 

Ceph ein spannendes Rennen. 

Hybrid-Speicher 

im Test 

Festplatte oder SSD – das 

erfordert die schwierige Entscheidung 

zwischen großen 

Kapazitäten und schnellen 

Zugriffsgeschwindigkeiten. 

Hybrid-Speicher sollen dieses 

Dilemma auflösen. Wir testen, 

wie gut ihnen das gelingt. 

arcoss, 123RF 


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

ADMIN Magazin Erste Hilfe - Disaster Recovery (Vorschau)

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?