ADMIN Magazin Enterprise-Linux (Vorschau)

NEU! 

Jetzt mit 

ADMIN 

Netzwerk & Security 

Enterprise- 

Linux 

Vergleich der Marktführer 

Ubuntu-Firmen-Desktop 

Red Hat zentral verwaltet 

IPv6-Tunnel 

Alle Techniken erklärt 

SQL-Injection 

Gefährliche Lücken enttarnen 

Windows 2012 

Die besten Tricks für jeden 

Server-Admin 

Prey: Gestohlene Handys 

und Laptops orten 

Proxmox: Ein freier 

VMware-Konkurrent 

01 2013 

Jan. – Feb. 

Auf Heft-CD: 

FOSS-Cloud 1.0.2 

FreeX ‘12 komplett 

Python 

Webapps mit Flask 

Open Stack 

Konfigurieren Step by Step 

www.admin-magazin.de 

D EUR 9,80 

A EUR 10,80 - BeNeLux EUR 11,25 

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

4 196360 509805 01

Born to 

be ROOT! 

HOSTED 

IN GERMANY 

Root Server Linux Level 1 

29 ,00 

€/ 

€/Mon.* 

CPU 

Intel Sandy Bridge G530 

Leistung 

2 x 2,4 GHz 

RAM 

4 GB 

HD 

1.000 GB 

Traffic 

Unlimited* 

EFFIZIENTER SPRINTER ZUM MINIPREIS 

Beschleunigen eun n Sie 

Ihre Projekte mit einem em 

zierten Root ot Server 

von STRATO. TO. 

Mit 

eigener Hard- 

ware steht Ihnen n 

immer m 

die volle Leistung von 

RAM, CPU, Festplatte e und 

Traffic zur Verfügung. 

STRATO TO 

setzt auf Qualität und arbeitet et ausschließlich h mit führen- 

den internationalen na alen 

Hardware-Herstellern re 

er ellern zusammen. men. Jedes Bau- 

teil ist 

optimal für den Einsatz im dedizierten Server abgestimmt. 

mt. 

Das 

sorgt für 

höchste Zuverlässigkeit und 

Ausfall llsich 

sicherheit. 

eit 

Zu- 

sammen me 

mit dem Minipreis is sind STRATO Root Server unschlagbar. 

dedidi- 

* Traffic-Unlimited: Keine zusätzlichen Kosten durch Traffic (bei Traffic-Verbrauch über 1.000 GB/ Monat 

und danach je weitere 300 GB erfolgt eine Umstellung der Anbindung auf max. 10 MBit/s. Erneute 

Freischaltung der vollen Bandbreite jeweils kostenlos über den Kundenservicebereich). Preis inkl. MwSt. 

Info: 030 – 300 146 111 | strato-pro.de

Backflip 

Editorial 

Backflip 

Kleine Städte können es. Schwäbisch Hall zum Beispiel, wo man schon 1997 bei Internetdiensten 

auf Linux setzte und heute in der Verwaltung flächendeckend unter 

dem freien Betriebssystem arbeitet. Größere Städte können es. Etwa Leipzig, wo 

man allein im Verlauf des letzten Jahres 3900 von 4200 PC-Arbeitsplätzen auf 

Open Office migrieren konnte. Ziemlich große Städte können es. Beispiel München, 

das mit der Umstellung von über 11 000 Arbeitsplätzen auf Linux 10 Millionen Euro 

sparte. Ganze Länder können es. Portugal ist ein Exempel: Dort stellt man die gesamte 

öffentliche Verwaltung auf das Open-Document-Format um. 

Freiburg konnte es nicht. Nachdem man sich dort 2007 zur Umstelllung auf Open 

Office entschlossen hatte, migriert man jetzt zurück zu Microsoft Office, weil man 

ansonsten angeblich auf Funktionen verzichten müsste, nur noch ineffektiv arbeiten könne, Software ohne Zukunft 

nutzen würde und keine Akzeptanz bei den Anwendern fände. Jedenfalls sagt das ein Gutachter, der zufällig 

Aufsichtsrat eines Microsoft-Gold-Partners, dafür aber verständlicherweise in Sachen freier Software nicht ganz 

so firm ist. Open-Source-Experten reiben sich bei der Lektüre zahlreicher fragwürdiger Behauptungen jedenfalls 

die Augen. 

Freiburg nimmt also Anlauf zu einem kostspieligen Rückwärtssalto. Aber woran lag es? Am freien Officepaket 

jedenfalls sicherlich nicht. Das ist inzwischen ausgereifte und stabile Software, die auch beim Funktionsumfang 

keinen Vergleich zu scheuen braucht. Aber das reicht eben nicht. Ein Migrationsprojekt ist kein Selbstläufer. Es 

braucht sorgfältige Planung und konsequente Umsetzung. Beides gab es in Freiburg nicht, wo man stattdessen 

einen fatalen Mischbetrieb aus veralteten Microsoft- und nicht aktuellen Open-Office-Versionen zuließ. 

Doch selbst ein wohl durchdachtes und konsequent verwirklichtes Vorhaben wird misslingen, wenn man, wie in 

Freiburg, die Anwender nicht mit ins Boot bekommt. Man weiß seit Langem, dass psychologische Faktoren der 

Hauptgrund für das Scheitern solcher Projekte sind: latente Widerstände, der Unwille angesichts von Veränderungen, 

das Festhalten am Altbekannten. 

Wie man trotzdem erfolgreich Neues implementieren kann, ist auch kein Geheimnis, eine ganze Disziplin, das sogenannte 

Change Management, beschäftigt sich damit. Es gilt die Betroffenen früh einzubeziehen, sie davon zu 

überzeugen, dass sie persönliche Vorteile haben, ihre Sorgen ernst zu nehmen, sie immer auf dem Laufenden 

zu halten und noch fehlende Fertigkeiten zu trainieren. Dann identifizieren sich die Mitarbeiter mit einem tollen 

Projekt wie der Office-Migration, das ihnen Unabhängigkeit zurückgibt, das zukunftsweisend ist und dabei Kosten 

spart. Dann laden sie nicht diffusen IT-Frust bei den Neuerungen ab, dann gehen sie nicht einem zweifelhaften 

Gutachter auf den Leim, sondern sind stolz, ein Vorreiter zu sein. 

@ leserbriefe@admin-magazin.de 

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


Admin 

Ausgabe 01-2013 

3

Service 

Inhalt 



01/2013 

In diesem Heft-Schwerpunkt: 

Linux-Distributionen mit professionellem 

Support für den Firmeineinsatz (ab S. 36) 

halten 

Was leisten Red Hat, 

36Kurs 

Suse, Oracle und Co.? 

Wir geben einen Überblick. 

Login 

8 Vorgelesen 

Bücher über Linux-Cluster und die 

Virtualisierung mit KVM. 

10 Branchen-News 

Neues von Firmen und Projekten. 

16 Recht 

Verarbeitet ein Dienstleister personenbezogene 

Daten gelten strenge Regeln. 

Netzwerk 

24 Nagios und VoIP 

Nagios lernt anzurufen und so seinen 

Admin sicher zu alarmieren. 

28 Rausgegraben 

Für den Übergang: IPv6-Tunneltechnologien 

im Vergleich. 

Schwerpunkt: Enterprise-Linux 

36 Kurs halten 

Die kommerziellen Linux-Distributionen 

versprechen langfristige Stabilität und 

professionellen Support. 

46 Neu gemischt 

Eine Ubuntu-Variante fürs Büro: der 

Ubuntu Business Desktop Remix. 

48 Paketversand 

Enterprise Software Management mit 

dem Red Hat Satellite Server. Ganze 

Netze automatisch patchen. 

20 Admin-Story 

Instant-Webanwendungen mit MongoDB 

und Bottle. 

Service 

3 Editorial 

4 Inhalt 

6 Heft-CD 

130 Impressum und Vorschau 

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

98 

Gift für alle Fälle 

SQL-Injection- 

Lücken erklärt und 

automatisiert aufgespürt. 

Inhalt 

Service 

Linux-Virtualisierung 

66Proxmox 

auf Debian-Basis mit 

Support für KVM und OpenVZ. 

Gewand 

Neuheiten bei der 

82Neues 

Windows-Nachrichtenzentrale 

Exchange 2013. 

Know-how 

56 Schatztruhe 

Einfacher verwaltet: 

zwölf praktische 

Tipps für den 

Windows Server 

2012. 

62 Schwere Beute 

Prey lokalisiert gestohlene Laptops und 

Mobiltelefone. 

Virtualisierung 

66 Proxmox 

Die freie Linux-Virtualisierungsplattform 

für KVM und OpenVZ. 

72 Einrichtungsberater 

Open-Stack-Workshop, Teil 2: Schritt für 

Schritt zur Cloud-Installation. 

Test 

82 Neues Gewand 

Was ist neu im Exchange Server 2013, 

lohnt sich ein Update? 

88 Schön schlank 

Stromsparend 

und leise , aber 

auch leistungsfähig? 

Der Krenn 

Low Energy Server 

im Test. 

Security 

90 Uneinsichtig 

SHA-3, der neue Hash-Standard — notwendige 

oder überflüssige Sicherheit? 

94 Leider geöffnet 

Automatisierte Portscans finden 

Schwachstellen in großen Computernetzen. 

98 Gift für alle Fälle 

Wie SQL-Injection-Lücken funktionieren 

und man sie automatisiert aufspürt. 

Programmieren 

102 Edler Tropfen 

Die Alternative 

zum Django- 

Framework: 

Webanwendungen 

mit Flask. 

106 Patchwork 

Effiziente Server- 

Fernsteuerung 

mit Python- 

Skripts. 

freeX 

109 freeX 

Artikel und Workshops aus der freeX. 

110 Sicher hinter Gittern 

Wie Jails in FreeBSD einzelne Prozesse 

sicher voreinander isolieren. 

120 Neubau 

Das neue Paketmanagement in FreeBSD. 

124 Hochzeit 

FreeBSD und KVM-Virtualisierung. 

Mehr Infos auf Seite 6 

FOSS-Cloud 

n Cloud und Virtualisierung mit freier Software 

n Kompletter Jahrgang 2012 der FreeX im PDF-Format 

www.admin-magazin.de Admin Ausgabe 01-2013 5

SErvice 

Heft-CD 

Heft-CD 

Auf dem beiliegenden Datenträger finden Sie die aktuelle 

Version der FOSS-Cloud-Distribution [1], eine Umgebung für 

den Betrieb virtueller Maschinen. 

◗ Cloud und Virtualisierung für Linux und Windows. 

◗ Server- und Desktop-Virtualisierung. 

◗ Support für Audio, Video, USB und Smartcards. 

◗ Basiert auf freier und Open-Source-Software (FOSS). 

◗ Erfordert zur Installation eine komplette Festplatte (Partition 

genügt nicht). 

Mehr Informationen geben zwei Artikel in der FreeX 

05/2012, die Sie auf der CD im Verzeichnis "admin-freex" 

finden. 

Legen Sie einfach die CD in das Laufwerk ein, und starten 

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

BIOS die richtige Boot-Reihenfolge einstellen, damit das 

Laufwerk vor der Festplatte an die Reihe kommt. n 

CD kaputt? 

Wir schicken Ihnen kostenlos eine 

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

info@admin-magazin.de 

Info 

[1] FOSS Cloud: [http://www.foss-cloud.org/de] 

6 Ausgabe 01-2013 

Admin www.admin-magazin.de

vServer Cloud 2.0 

Voller Root- und Administrator-Zugriff 

• Cloud-Funktion mit höchster Flexibilität 

• Kostenkontrolle durch tagesgenaue Abrechnung 

• Garantiert in 12 Stunden verfügbar 

• Jetzt ab sofort mit PrePaid-Funktion 

50% Rabatt 

in den ersten 3 Monaten 

vServer S 2.0 

vServer M 2.0 

vServer L 2.0 

vServer XL 2.0 

Core`s (jeweils 2.000 MHz) 1 

2 

3 

4 

RAM 1.024 MB 2.048 MB 4.096 MB 8.192 MB 

RAM Dynamisch 2.048 MB 4.096 MB 8.192 MB 16.384 MB 

Festplatte NEU 100 GB NEU 150 GB 

NEU 200 GB NEU 300 GB 

Traffic 

Betriebssysteme 

100 Mbit Full-Flatrate 

Linux (Debian 6.0.6, CentOS 6.3, openSUSE 12.2 & Ubuntu 12.04) oder ohne Aufpreis Windows 2008 R2 Standard-Edition 

.de Domain inklusive 

IPv4 Adressen inkl. 

IPv6 Subnetz (/64) Inkl. 

1 

1 

2 

2 

3 

3 

4 

4 

Extras 

Firewall, Reboot, Recovery, Monitoring, Reverse DNS 

Monatsgrundgebühr 

Preis für die ersten 3 Monate 

4,49€ 

8,99 € 18,99 € 38,99 € 38,99 € 

9,99€ 14,99€ 19,99€ 

Jetzt informieren und bestellen Tel.: 0211 / 545 957 - 330 www.webtropia.com 

PLATINUM PARTNER

Login 

Bücher 

Bücher über HA-Cluster und KVM 

Vorgelesen 

Der technische Fortschritt in der Linux-Welt hat einem Cluster-Buch zu 

einer modernisierten dritten Auflage verholfen. Ein weiteres Werk widmet 

sich dem Aufsteiger KVM. Jens-Christoph Brendel, Udo Seidel 

KVM ist der Shooting Star der Virtualisierungstechniken 

unter Linux und hat 

in den letzten Jahren Xen und andere 

Hypervisors mit Blick auf die Popularität 

klar abgehängt. Entsprechendes Publikumsinteresse 

kann man sicher für den 

Titel „KVM für die Server-Virtualisierung“ 

voraussetzen, den zwei namhafte 

Linux-Publizisten, Michael Kofler und 

Ralf Spenneberg, nun vorlegen. 

KVM en Detail 

Im Untertitel konnten die Autoren das offenbar 

obligatorische Schlagwort „Cloud“ 

nicht vermeiden, was im Buch dann aber 

auf den drei Seiten eines Alibi-Abschnitts 

dazu folgt, hätte man ebensogut weglassen 

können. Für den eigentlichen Gegenstand, 

KVM, gilt jedoch im Gegenteil, 

dass er in vielen Facetten, tiefgründig 

und dabei auch gut verständlich vorgestellt 

wird. 

Verdienstvollerweise geht es nicht nur 

um die Virt-Manager-GUI, stattdessen ist 

der Administration auf der Kommandozeile 

ein ganzes Kapitel gewidmet, das 

alle KVM- oder Libvirt-Kommandos eingehend 

bespricht. Weitere Kapitel wenden 

sich dann den Ressourcen virtueller 

Maschinen zu, wie virtuellen Datenträgern, 

Grafik, CPU, Hauptspeicher, an- 

deren Komponenten wie USB oder dem 

Netzwerk. Ein eigenes Kapitel beleuchtet 

den wichtigen Aspekt Sicherheit. 

Besondere Vorkenntnisse sind kaum nötig. 

An manchen Stellen gehen die Kompromisse 

mit Blick auf gute Verständlichkeit 

vielleicht ein bisschen weit. „Eine 

Bridge ist ein Switch“ (S.150) stimmt 

zum Beipsiel eher umgekehrt. Davon 

aber abgesehen, beleuchtet gerade das 

Netzwerkkapitel auch fortgeschrittene 

Techniken wie Passtrough, Bandbreitenregulierung 

oder Firewalling. 

Alles in allem ist das Buch zu KVM eine 

gelungene Einführung in ein aktuelles 

Thema, das man Einsteigern empfehlen 

kann, das aber auch dem erfahrenen Admin 

noch den einen oder anderen Tipp 

zu vermitteln vermag. 

Immer bereit 

Hochverfügbarkeit mit Linux hat eine 

wechselhafte Geschichte. Seit Pacemaker 

und Co. befindet sich das HA-Schiff 

aber in ruhigeren Gewässern. In der 3. 

Auflage seines Clusterbau-Buches zeigt 

Michael Schwartzkopff, wie Hochverfügbarkeit 

mit dem freien Betriebssystem 

funktioniert. 

Die rasche und teilweise turbulente Entwicklung 

des ursprünglichen Heartbeat- 

Projektes macht die Aktualisierung eines 

solchen Bands unumgänglich. Auch die 

generelle Technik in der IT entwickelt 

sich weiter: Cluster-Interconnects über 

serielle Schnittstellen sind schon lange 

nicht mehr zeitgemäß und finden daher 

auch hier keine Beachtung mehr. 

Die Anforderung „Das System muss immer 

verfügbar sein“ ist einfach formuliert 

– die entsprechende Umsetzung muss 

einige Hürden überwinden. Michael 

Schwartzkopff führt sehr schön in das 

Thema Hochverfügbarkeit ein. Zunächst 

erklärt er Begriffe wie „immer“ oder 

„Dienst“. 

Im nächsten Kapitel folgt ein historischer 

Abriss über das bekannte Linux-Projekt 

Heartbeat. Die saubere Erklärung der 

Komponenten und der verwendeten Terminologie 

ist dabei besonders hervorzuheben. 

Seit den Heartbeat-Versionen 1 

und 2 hat sich viel verändert – der Autor 

stellt die einzelnen Komponenten wie 

Pacemaker oder Open AIS vor und erläutert 

deren Aufgaben. So stellt er sicher, 

dass Leser mit egal welchem Ausgangsniveau 

genau wissen, worüber er gerade 

schreibt. 

Auf circa 400 Seiten behandelt der Text 

die Installation, erste Konfigurationen, 

die Verwaltung per Kommandozeile oder 

GUI und zeigt Beispielszenarien. Kapitel 

über den Betrieb und detaillierte Informationen 

über Cluster-Agenten runden 

das Buch ab. Neu ist das Kapitel zur 

geeigneten Infrastruktur, welches das HA- 

Konzept über die Server-Grenzen hinaus 

erweitert. 

Für rund 45 Euro erhält man eine umfassende 

Dokumentation zum Thema 

Hochverfügbarkeit mit Linux. Wer die 

erste Auflage von 2008 besitzt, sollt diese 

nun beiseite legen und das aktuelle Buch 

kaufen. 

n 

KVM 

Michael Kofler, Ralf Spenneberg 

KVM für die Server-Virtualisierung 

Addison-Wesley, 2012 

341 Seiten 

41 Euro 

ISBN 978-3-8273-3149-6 

Clusterbau 

Michael Schwartzkopff 

Clusterbau: Hochverfügbarkeit mit 


O’Reilly, 3. Auflage 2012 

420 Seiten 

45 Euro 

ISBN 978-3-86899-358-5 


Ein vollwertiger Server, 

im Taschenbuchformat! 

Green-IT 

Stromverbrauch: ca. 6 - 9 Watt 

Unauffällig 

Klein und absolut geräuschlos 

Kein PC 

Echte Serverkomponenten 24/7 zertifiziert 


Bestens geeignet für Anwendungs- und 

Softwareentwickler - ebenso als Firewalllösung oder 

Router und aufgrund der geringen Größe für den 

mobilen Einsatz. Dank des sparsamen Verbrauchs 

ist der LES ebenfalls als kleiner Webserver praktisch. 

Sparen Sie im Jahr über 100 Euro an 

Stromkosten gegenüber einem vergleichbaren 

Server auf Atombasis. 

Nur bei Thomas 

Krenn ab: 

€ 

499,– 

www.thomas-krenn.com/les_499 

TRY 

& 

BUY 

Diesen und andere Thomas Krenn Server 

können Sie auch per Try & Buy testen 

DE: +49 (0) 8551 9150 - 0 

CH: +41 (0) 848207970 

AT: +43 (0)732 - 2363 - 0 

Verkauf erfolgt ausschließlich an Gewerbetreibende, Firmen, Freiberufler (Ärzte, Rechtsanwälte etc.), staatliche Institutionen und Behörden. Druckfehler, Irrtümer und Änderungen in Preis und Ausstattung 

vorbehalten. Unsere Versandkosten richten sich nach Gewicht und Versandart - mehr unter: www.thomas-krenn.com/versandkosten.Thomas-Krenn.AG, Speltenbach-Steinäcker 1, D-94078 Freyung

Login 

News 

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

Neue Software und Produkte 

Branchen-News 

Freiburg verabschiedet sich von Open Office 

Der Freiburger Gemeinderat hat mit 

knapper Mehrheit dafür votiert, in der 

Stadtverwaltung kein Open Office mehr 

einzusetzen. Stattdessen soll Microsoft 

Office künftig als Bürosuite dienen. Damit 

folgten Stimmberechtigten der Empfehlung 

eines Gutachtens, 

das im Jahr 2011 

die städtische IT untersucht 

hatte. 

Dieses Gutachten hatten 

vier Verbände im Vorfeld 

der Entscheidung 

kritisiert: Open Source 

Business Alliance, Free 

Software Foundation 

Europe (FSFE), der Bundesverband 

Informations- 

und Kommunikationstechnologie 

sowie 

Der Gemeinderat Timothy Simms 

findet, bei der Migration habe die 

Verwaltung vieles falsch gemacht. 

die Document Foundation (TDF). Das 

vierseitige Schreiben bemängelt Fehleinschätzungen 

bezüglich der Situation auf 

dem Markt der freien Office-Varianten. 

Daneben sieht es Auslassungen bei den 

Handlungsalternativen, die einen reinen 

Einsatz von freier Office- 

Software gar nicht mehr 

in Betracht ziehen, sondern 

als gescheitert ablehnen. 

Die Freiburger ziehen 

in der Mehrheit ein 

negatives Resümee 

der versuchten Open- 

Office-Einführung. 

„Eine 3000-Personen- 

Verwaltung kann nicht 

dauerhaft im Trial-anderror-Modus 

laufen“, 

zitiert das Presseamt den SPD-Stadtrat 

Kai-Achim Klare. Gegen den Open-Office- 

Ausstieg stimmte beispielsweise Timothy 

Simms, stellvertretender Vorsitzender 

der Stadtratsfraktion Junges Freiburg/Die 

Grünen. Im Gespräch mit dem Linux- 

Magazin sagte er: „Freiburg – das war 

uns vorher gar nicht so bewusst – hat nie 

richtig zu Open Office gewechselt, vielmehr 

wurde in der Regel parallel mit dem 

veralteten MS Office 2000 gearbeitet. Dazu 

kam eine allgemeine Unzufriedenheit 

seitens der Fachverwaltungen gegenüber 

der IT. Dann ist Open Office ein Stück 

weit zu einem Symbol geworden für alles, 

was zwischen IT und Verwaltung nicht 

funktionierte.“ Die Stadt im Breisgau ist 

seiner Meinung nach ein Beispiel dafür, 

„wie man eine Migration besser nicht 

angeht“. 

Samba 4 ist da 

Das Samba-Team hat nach langen Jahren der Entwicklungszeit 

die vierte Version des SMB-Servers veröffentlicht. Der kann 

jetzt auch Active-Directory-Server spielen und bringt auch sonst 

einige lang erwartete Neuerungen. 

Hersteller wie Univention hatten Backports auf Samba 4 mithilfe 

eigener Addons schon länger im Programm (das Linux-Magazin 

berichtete ), doch die Samba-Entwickler selbst traten lange auf 

die Bremse und wollten offenbar nicht zu früh veröffentlichen 

und so eventuell zahlreiche Windows-Client-User vergrätzen. 

Jetzt ist die Samba-Server-Suite veröffentlicht, Version 4 steht 

zum Download bereit. 

Die wichtigsten Änderungen stellen nach der langen Entwicklungszeit 

dann auch keine wirklichen Neuheiten mehr dar. 

Erwartungsgemäß kann Samba 4 jetzt einen Active-Directory- 

Server vollständig ersetzen (AD 2000 und später): Das Domänenlogon 

für Clients mit Kerberos und LDAP über CIFS 

funktioniere jetzt sauber, schreiben die Entwickler in ihrem 

Announcement. 

Dazu kommen mit NTVF ein neuer Fileserver, zwei DNS- 

Varianten, NTP-Integration und ein Python Scripting Interface. 

Einige Probleme gäbe es zwar noch, zum Beispiel bei der Replikation 

auf BSD-Hosts, doch die Workarounds kämen in den 

nächsten Versionen. 

GUUG-Frühjahrsfachgespräch 2013 

Das Programm des Frühjahrsfachgesprächs der German Unix 

User Group (GUUG), das vom 26. Februar bis 1. März an der 

Fachhochschule Frankfurt am Main stattfindet, steht jetzt fest. 

Wegen der Vielzahl an Einsendungen stockte das Programmkomitee 

dieses Jahr den ersten Konferenztag mit einem dritten 

Track auf. Insgesamt 37 Vorträge mit den Schwerpunkten Netzwerk- 

und IT-Sicherheit, Dateiverwaltung, Ressourcen-Management, 

Softwareverteilung oder Virtualisierung warten nun auf 

die 200 Teilnehmer. 

Eine große Rolle nimmt IPv6 ein: Sicherheitsexperte Christoph 

Wegener ist nicht nur am zweitägigen Tutorium zum IPv6- 

Monitoring beteiligt, sondern widmet sich gemeinsam mit dem 

IT-Anwalt Jörg Heidrich den datenschutzrechtlichen Fragen des 

Internetprotokolls. Der IT-Berater Marc Haber deckt in einem 

Vortrag die „Marketinglügen“ über IPv6 auf. 

Daniel Kobras und Michael Weiser führen den FFG-Dauerbrenner 

schlechthin fort: Auch 2012 geben sie ein zweitägiges Tutorium 

zur Sicherheit plattformübergreifender Dateidienste. Kobras 

ergänzt das Thema durch einen weiteren Vortrag zum Lustre/ 

ZFS-Projekt, einer Initiative, die die Vorteile von verteilten und 

lokalen Dateisystemen vereinen soll. Entscheidungshilfen dazu 

gibt es bei Lenz Grimmer und Ulrich Gräf, die ZFS mit dem 

Linux-Dateisystem Btrfs vergleichen. 


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

Inktank und Suse bieten Support für Ceph 

In einer Pressemitteilung haben Suse und der kalifornische 

Storage-Spezialist Inktank angekündigt, künftig gemeinsam 

Support für Anwender des verteilten Speichersystems Ceph 

anzubieten. Zumindest in der Suse Cloud soll es demnächst 

Enterprise-Support auch für das Filesystem geben. Das Netzwerkdateisystem 

arbeitet mit Open Stack zusammen, von beidem 

macht Suses Wolke ausgiebig Gebrauch. Inktank [http:// 

www.inktank.com] ist nach eigener Aussage der erste Anbieter, der 

Unternehmenssupport für Ceph anbietet. 

Suses Cloud gewinnt damit einen weiteren wichtigen Partner, 

nachdem die Nürnberger erst vor wenigen Monaten Dells 

Deploymenttool Crowbar integriert hatten. 

TM 

MobyDick 

D i e Z u k u n f t der Telefonie 

Mit der MobyDick Telefonanlage haben Sie alle Fäden selbst in 

der Hand. Außerdem verbinden Sie die Features modernster 

Telefonie mit den Vorteilen von Voice over IP. 

Die Kommunikationslösung für Ihr 

Unternehmen 

Umweltschützer speichern vor Ort 

Eine Studie des Öko-Instituts Freiburg kommt zu dem Schluss, 

dass lokale NAS-Speicher für Heimanwender günstiger und 

umweltverträglicher sind als Speicherangebote im Internet. 

So fielen für das Speichern von 4,7 GByte Daten in einem 

Online-Speicher 55 Kilogramm CO2-Äquivalente an. Ein energieeffizienter 

NAS-Speicher im Heimnetzwerk verbrauche für 

die gleiche Datenmenge nur 150 Gramm. Die Speicherung 

im lokalen NAS soll auch kostengünstiger sein. So kostet der 

lokale Netzwerkspeicher nach Berechnungen des Instituts pro 

TByte und Jahr rund 100 Euro. Die Cloud-Speicher bieten zum 

gleichen Preis nur etwa 100 GByte Speicherplatz. 

Das Öko-Institut [http://oeko.de], das Vergabekriterien für das 

Umweltzeichen „Der Blaue Engel“ entwickelt, hat Empfehlungen 

für den Kauf kleiner Netzwerkspeicher abgeleitet. Ran 

Liu, eine wissenschaftliche Mitarbeiterin des Öko-Instituts, rät: 

„Beim Kauf sollten Verbraucherinnen und Verbraucher auf 

den Stromverbrauch der Geräte achten. Ein energieeffizienter 

Netzwerkspeicher mit zwei Festplatten verbraucht maximal 58 

Kilowattstunden pro Jahr. Ineffiziente Geräte können leicht das 

Doppelte verbrauchen.“ Die Geräte sollten dabei über einen 

Standby-Modus mit weniger als 4 Watt verfügen. 

Standard HSTS soll Web sicherer machen 

Der neue Standard HSTS soll künftig dafür sorgen, dass Websites 

nur noch über HTTPS erreichbar sind, wenn sie entsprechend 

konfiguriert sind. 

Die Internet Engineering Task Force (IETF) hat den RFC 6797 

veröffentlicht und damit HTTP Strict Transport Security (HSTS) 

formal als Internet-Standard festgeschrieben. Webserver, die 

entsprechend konfiguriert sind, erlauben damit nur noch verschlüsselte 

Verbindungen. Dies setzt allerdings voraus, das 

Webbrowser auf das vom Server verschickten Header-Feld wie 

gewünscht reagieren. Gleichzeitig ist der Sicherheitsmechanismus 

nicht von Haus aus immun gegen Man-in-the-Middle- 

Angriffe, die den Header manipulieren. Browser wie Chrome 

und Firefox wollen deshalb eine Liste von Websites führen, die 

HSTS-kompatibel sind. 


Unified Communications: 

Telefon 

Video 

VoiceMail 

Präsenzmanager 

Instantmessaging 

FaxEmail Gateway 

PrintFax Gateway 

Conferencing 

Voicemailboxen 

Mehr Informationen finden Sie unter: 

http://www.pascom.net 

http://community.pascom.net 

NEU 

Kostenlose 

Community 

Version 

erhältlich 

pascom 

Netzwerktechnik GmbH & Co. KG 

Berger Straße 42 

94469 Deggendorf 

Tel.: +49 991 27006 - 0 


11

Login 

News 

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

Die Daten liegen draußen 

Der erste Digital Information Index von Symantec unterstreicht 

die Bedeutung von Cloud Computing und Mobilität für moderne 

Unternehmen. Der Studie zufolge werden Unternehmensdaten 

immer häufiger außerhalb des Rechenzentrums genutzt und 

gespeichert. 

Weltweit wird fast die Hälfte aller Unternehmensinformationen 

(46 Prozent) außerhalb des eigenen Rechenzentrums 

gespeichert. Kleine und mittelständische Unternehmen (KMU) 

liegen dabei mit 53 Prozent vor Konzernen, insbesondere, wenn 

mobile Endgeräte und Laptops genutzt werden. Deutschland 

befindet sich hier mit 48 Prozent etwas über dem weltweiten 

Durchschnitt, während Länder wie Indien (83 Prozent), China 

(60 Prozent) und Singapur (60 Prozent) deutlich darüber liegen. 

Dabei hat mehr als ein Drittel der befragten Firmen bereits 

vertrauliche Informationen durch Verlust oder Diebstahl von 

mobilen Geräten verloren. Zudem geben die Befragten an, es sei 

schwierig, immer die richtigen Daten zu finden, da Mitarbeiter 

die Informationen weitgehend unorganisiert speichern. 

Weltweit werden 14 Prozent der Unternehmensinformationen 

auf Smartphones und Tablets gespeichert – in Deutschland 

sogar 16 Prozent. Vergleicht man hier die Unternehmensgröße, 

liegen große Firmen mit 14 Prozent vor KMU (11 Prozent). Global 

werden außerdem bereits 28 Prozent der Informationen von 

unterwegs abgerufen – auch hier führen große Unternehmen 

mit 31 Prozent das Feld vor den KMU (25 Prozent) an. 

Virtuelles Red-Hat-Training für Europa 

Das Open-Source-Unternehmen Red Hat bietet seine Schulungen 

im virtuellen Format nun auch in Europa an. 

Das Angebot soll sich auf eine große Liste von Themen und 

Zertifizierungen erstrecken, vom bekannten RHCE über Kurse 

zu Solaris bis zur Jboss-Administration und ‐Entwicklung. Die 

Termine für Deutschland finden sich unter [http://www.europe. 

redhat.com/training/dates/?country=DEV] 

Die Online-Schulungen werden live von Trainern betreut und 

bieten die Gelegenheit zu praktischen Übungen an virtualisierten 

Systemen. Sie erstrecken sich über drei bis fünf Tage, an 

denen je fünfeinhalb Stunden Schulung stattfinden. 

ISO normiert digitale Beweissicherung 

Mit ISO/IEC 27037:2012 ist ein internationaler Standard für 

die elektronische Beweissicherung verabschiedet worden. Die 

Norm enthält Richtlinien für die Beschaffung, Sammlung und 

Sicherung digitaler Beweise und den Erhalt ihrer Glaubwürdigkeit. 

Sie richtet sich an Personen und Organisationen, die 

mit der Auswertung digitaler Beweise befasst sind, aber auch 

an einschlägige Normungsgremien. Der Standard ersetzt keine 

rechtlichen Bestimmungen, sondern versteht sich als Praxis- 

Leitfaden. Entwickelt wurde er durch das Komitee ISO/IEC JTC 

1, Information Technology. 

UEFI Secure Boot: Mühe mit der Microsoft-Signatur 

Die Bemühungen der Linux Foundation, einen UEFI-Bootloader 

von Microsoft signieren zu lassen, gestalten sich mühsam. Das 

berichtet James Bottomley, Vorsitzender des technischen Beirats 

der Organisation, in seinem Blog. Die Foundation möchte für 

Linux-Anwender Tools bereitstellen, mit denen sie UEFI Secure 

Boot deaktivieren und umkonfigurieren können. Zudem soll es 

einen Pre-Bootloader geben, der beliebige andere Bootloader 

wie etwa Grub für Linux startet. 

In seinem Beitrag beschreibt Bottomley nun, dass sich die 

Prozedur für die signierten UEFI-Executables langwieriger 

und schwieriger gestalte als erwartet. Das „Abenteuer“, wie 

er es bezeichnet, beginnt 

mit dem Erwerb eines Verisign-Schlüssels, 

mit dem 

man sich auf der Microsoft 

Sysdev-Seite anmeldet und 

seine Identität beweist. Dazu 

signiert der Benutzer ein 

Binary und lädt es hoch. 

Eigentlich sollte das mit einer 

bestimmten Windows- 

Version geschehen, doch offenbar 

erfüllt auch das freie 

Tool Sbsign seinen Zweck. James Bottomley bemüht sich, von 

Vor dem Signierenlassen Microsoft einen signierten UEFIvon 

UEFI-Programmen muss Bootloader zu bekommen. 

dann der Vertragsschluss mit Microsoft erfolgen. Hier berichtet 

James Bottomley von zahlreichen Klauseln, die über die eigentlichen 

UEFI-Executables hinausgingen und beispielsweise 

GPL-Treiber ausschlössen. Einem Bootloader steht aber offenbar 

nichts im Wege. 

Das Signieren erfordert dann, die Binärdatei in eine Microsoft 

Cabinet-Datei zu verpacken, wozu das Open-Source-Programm 

Lcab taugt. Anschließend muss der Benutzer das Archiv mit seinem 

Verisign-Schlüssel signieren. Glücklicherweise gibt es auch 

hierfür mit Osslsigncode eine freie Lösung. Beim Upload kommt 

dann Microsofts Silverlight-Technologie zum Einsatz. 

Die bisherigen Versuche haben offenbar noch nicht zum Erfolg 

geführt. Somit gibt es derzeit noch keinen passend von Microsoft 

signierten UEFI-Bootloader der Linux Foundation. James 

Bottomley möchte sich weiter bemühen und die Datei auf die 

Website der Linux Foundation stellen. 

In der Zwischenzeit hat der Open-Source-Entwickler Matthew 

Garrett seinen Bootloader namens Shim in einer gebrauchsfertigen 

Version veröffentlicht. Im Unterschied zum Loader 

der Linux-Foundation setzt er voraus, dass der Anwender sein 

eigenes Zertifikat im UEFI einspielt und den Bootloader selbst 

signiert. Somit ist kein Schlüssel eine Dritten wie etwa Microsoft 

erforderlich. Shim 0.2 steht im Quelltext und als EFI-Binary 

unter [http://www.codon.org.uk/~mjg59/shim‐signed/] zum Download 

bereit. Er soll unter anderem in Fedora LInux 18 zum Einsatz 

kommen. 


News 

Login 

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

Vorträge für Cebit 2013 gesucht 

Das Open-Source-Forum der Cebit bildet den Rahmen für Vorträge zu Linux und 

freier Software. 

Mit dem Umzug in Halle 6 räumt die Cebit dem Thema Open 

Source im Jahr 2013 mehr Raum ein. Davon profitiert auch das 

Open Source Forum, das zusammen mit der Ausstellung des 

Open Source Parks das Thema Linux und freie Software auf der 

Cebit prägt. Die Cebit 2013 findet vom 5. bis 9. März 2013 in 

Hannover statt. Organisiert von der Medialinx AG (Herausgeber 

des ADMIN-Magazins), bietet das Open Source Forum dem 

Cebit-Publikum ein umfangreiches Vortragsprogramm, das alle 

Facetten der Linux- und Open Source-Welt beleuchtet 

Mit dem Call for Papers sind Entwickler und Strategen aus 

Community, Unternehmen und Behörden aufgerufen, ihre Vortragsvorschläge 

einzureichen. Gesucht werden Praktiker, die 

über ihre Erfahrungen bei der Entwicklung und beim Einsatz 

freier Software berichten. Gefragt sind innovative Produkte 

und neue Projekte sowie Open Source- und Linux-spezifische 

Technologien. Von besonderem Interesse ist der Themenbereich 

„Open Source in der Mobile-IT“ sowie Themen, die an das 

Cebit-Leitthema 2013 „Shareconomy“ anknüpfen. 

Ihre Vorschläge können Interessierte per Formular unter [http:// 

www.linux‐magazin.de/cfp] einreichen. Über die Vergabe der 

Vortragsplätze entscheidet eine internationale Jury aus Open- 

Source-Experten. 

Red Hats PaaS: Open Shift ist fertig 

Nach RHEV und diversen anderen Produkten legt Red Hat nach 

und bringt jetzt mit Open Shift auch seine eigene PaaS-Lösung 

für die private, public oder hybride Cloud auf den Markt. 

Open Source durch und durch, das sei Open Shift, schreibt 

Red Hat in seinem Announcement. Zwar ist die Plattform für 

Webentwickler schon länger erhältlich, doch die Enterprise- 

Edition hat der Hersteller erst jetzt als Generally Available 

(GA) freigegeben. Produktinformationen gibt es unter [https:// 

openshift.redhat.com/app]. 

Open Shift Enterprise setzt auf RHEL, Jboss, Java, Ruby, Python, 

PHP und Perl und nutzt eine sogenannte Cartridge-Architektur 

aus Virtualisierungscontainern (einer Kombination aus SE Linux, 

Cgroups und Namespaces), um die Middleware-Services 

für Entwickler leichter skalierbar zu machen. 

Red Hats Ashesh Badani (General Manager der Cloud Business 

Unit und von Open Shift) nennt das Produkt „die einzige offene 

PaaS-Umgebung für den Einsatz im eigenen Rechenzentrum“. 

Den guten Chancen am Markt pflichtet in der Pressemitteilung 

auch die IDC bei: Stephen Hendrick, Group Vice President 

Application Development und Deployment Research spricht von 

40 Prozent zu erwartenden Zuwächsen im PaaS-Bereich, die 

sich auch im eigenen Rechenzentrum abspielen werden. 

Linux Schulungen 2013 – Nicht verpassen! 

• Softwarepaketierung unter Linux mit RPM: 19.02.13 

NEU 

KVM - Server- 


unter Linux: 

22.04.13 

• Erweiterungen programmieren für Check_MK: 25.02., 03.06.13 

• Linux - Crashkurs für Administratoren: 04.03., 13.05.13 

Oracle sammelt Red-Hat-Patches 

Unter dem Namen Redpatch hat Oracle ein neues Git-Repository 

veröffentlicht, das alle Patches für den Enterprise-Kernel von 

Red Hat sammelt. Die einzelnen Patches sind dort unter der 

GPL-Lizenz frei verfügbar. Unter den gleichen Bedingungen bietet 

Oracle auch die Patches für den eigenen „Unbreakable Enterprise 

Kernel“ an. Zu dem Schritt habe Oracle sich entschlossen, 

weil Red Hat Anfang 2011 die Art der Veröffentlichung seiner 

Kernel-Änderungen geändert hat. Seither publiziert Red Hat 

nicht mehr einzelne Patches, sondern den gesamten Kernel- 

Code und einen einzigen Patch, der alle Änderungen enthält. 

Für die Arbeit an Ksplice zerlege Oracle seit Red Hats Umstellung 

den monolithischen Patch in einzelne Teile und sammle sie 

in einem eigenen Repository. Mit Redpatch sei dieses nun auch 

öffentlich verfügbar (siehe den Artikel zu Enterprise-Linux in 

diesem Heft). (jcb/hje/ofr/mfe/mhu) 

• Fortgeschrittenes Monitoring mit Nagios & Check_MK: 11.03., 10.06.13 

• Linux Administration für Fortgeschrittene: 18.03.13 

• Systemmonitoring mit Nagios und Check_MK: 08.04.13 

• NEU KVM - Server-Virtualisierung unter Linux: 22.04.13 

Gerne machen wir auch Inhouse-Schulungen direkt bei Ihnen vor Ort. 

Fragen Sie uns nach einem Angebot zu Ihrem Wunschthema. 

Besuchen Sie uns 

auf der CeBIT, Halle 6, 

Open Source Park. 

089 / 18 90 435 - 0 


Admin 


schulung@mathias-kettner.de 

13 

www.mathias-kettner.de

1&1 feiert Geburtstag – feiern Sie mit! Wir schenken Ihnen 

50,– € Jubiläums-Bonus! 

* 

DOMAINS | E-MAIL | WEBHOSTING | E-SHOPS | SERVER 

* 1&1 Jubiläumsaktion bis 31.01.2013 für Neukunden: 1&1 WebHosting Pakete 6 Monate 0,– €/Monat, danach z. B. 1&1 Dual Unlimited 24,99 €/Monat, 14,90 € Einrichtungsgebühr, 

einmaliger Jubiläumsbonus 50,– €. 1&1 Dynamic Cloud Server Basiskonfi guration 3 Monate 0,– €/Monat, danach 39,99 €/Monat, 39,– € Einrichtungsgebühr, einmaliger Jubiläumsbonus

1&1 WEBHOSTING 

1&1 feiert 25-jähriges Jubiläum. Profitieren Sie von 25 Jahren Erfahrung und geben Sie Ihren Web-Projekten eine sichere 

Zukunft. Denn mit weltweit über 11 Mio. Kundenverträgen, 5.000 Mitarbeitern und 5 Hochleistungs-Rechenzentren ist 

1&1 einer der größten Webhoster weltweit. Als Kunde profitieren Sie von unserem langjährigen Know-how und unserem 

24/7 Experten-Support. Und das Beste ist: Allen, die sich bis 31.01.13 für 1&1 entscheiden, schenken wir bis zu 50,– € 

Jubiläums-Bonus! 

1&1 WebHosting 

1&1 Cloud Server 

1&1 Dedicated Server 

■ Optimale Sicherheit durch parallelen 

Betrieb und tägliche Backups 

■ Bis zu 8 Inklusiv-Domains 

■ Freie Wahl des Betriebssystems 

(Linux oder Windows) 

■ NEU! PHP 5.4 inklusive 

■ Inklusive aller Tools zur Realisierung 

Ihrer Ideen 

■ Unlimited Traffic inklusive 

■ Voller Root Zugriff 

■ Individuelle Kombination aus CPU, 

RAM und Festplattenspeicher 

■ Abrechnung stundengenau und 

konfigurationsbasierend 

■ Optimale Sicherheit durch parallelen 

Betrieb 

■ Wiederherstellung per Snapshot 


■ Voller Root Zugriff 

■ Bis zu 32 Cores und 64 GB RAM 

■ Große Auswahl an Betriebssystemen 

■ Bereitstellung und Austausch 

innerhalb von 24h 

■ Nahezu 100 % Verfügbarkeit und 

Erreichbarkeit 


6 MONATE 

0,– 

€ * 0,– 

€ 

0,– 

€ 

50,– € * 

* 

* 

50,– 

€ * 

3 MONATE 

+ BONUS 

+ 

JUBILÄUMS- 

BONUS 3 MONATE 

BONUS 

+ 

50,– 

JUBILÄUMS- 

JUBILÄUMS- 

50,– 

€ * 

0 26 02 / 96 91 

0800 / 100 668 

1und1.info 

50,– €. 1&1 Dedicated Server 3 Monate 0,– €/Monat, danach z. B. 1&1 Server XXL24i 399,– €/Monat, 99,– € Einrichtungsgebühr, einmaliger Jubiläumsbonus 50,– €. Für alle Aktionsangebote 

12 Monate Mindestvertragslaufzeit. Jubiläumsbonus wird mit der jeweiligen monatlichen Grundgebühr ab dem ersten Bezahlmonat verrechnet. Preise inkl. MwSt.

Login 

Auftragsdatenverarbeitung 

© Steve Cukrov, 123RF 

Wie man externe Dienstleister richtig beauftragt 

Arbeit im 

Auftrag 

Manches erledigt ein spezialisierter Dienstleister effizienter als man es 

selbst könnte, Stichwort Outsourcing. Wenn dabei personenbezogene Daten 

ins Spiel kommen, macht das Bundesdatenschutzgesetz sehr konkrete 

Vorgaben für die sogenannte Auftragsdatenverarbeitung. Ignoranz kann 

teuer werden. Vilma Niclas 

Ein Beispiel: Die Geschäftsführer eines 

Unternehmens aus Bremen versandten 

einen Newsletter an Kunden durch eine 

externe Medienfirma. Der bremische Landesbeauftragte 

für den Datenschutz verhängte 

ein Bußgeld von insgesamt 8 000 

Euro und rügte: Die Aufträge waren nicht 

richtig erteilt worden, es fehlte an der 

Schriftform, der Vertrag enthielt nicht die 

Inhalte, die das Gesetz zwingend 

vorschrieb, und das Unternehmen 

habe es versäumt, 

vor Beginn des Auftrages zu 

prüfen, welche technischen 

und organisatorischen Maßnahmen 

der Dienstleister in 

datenschutzrechtlicher Hinsicht 

getroffen habe. Die Geschäftsführer 

zahlten die Bußgelder 

ohne Widerspruch. 

Datenschutzfalle: 

Google Analytics 

© Oleksandr Nebrat, 123RF 

Viele Unternehmen nutzen 

Google Analytics auf ihren 

Webseiten, ein Statistikprogramm, 

das IP-Adressen speichert. Nach 

Ansicht von Datenschützern sind dies 

personenbezogene Daten, die Google im 

Auftrag des Webseitenbetreibers verarbeitet. 

Der Webseitenbetreiber ist für den 

Datenschutz verantwortlich. Der Hamburger 

Datenschutzbeauftragte hatte sich 

Ende 2011 mit Google daraufhin geeinigt, 

dass Webseitenbetreiber das Tool nutzen 

Abbildung 1: Analysetools wie Google Analytics arbeiten häufig mit personenbezogenen 

Daten und beinhalten dann eine Auftragsdatenverarbeitung. 

können, sofern diese mit Google einen 

Vertrag zur Auftragsdatenverarbeitung 

nach deutschem Bundesdatenschutzgesetz 

schließen. Zudem muss Google 

mithilfe eines Deaktiverungs-Add-ons 

für den Browser dafür sorgen, dass jeder 

Internetnutzer der Erfassung seiner 

Daten widersprechen kann. Der Datenschutzhinweis 

auf der Website des jeweiligen 

Anbieters müsse darauf hinweisen. 

Zudem muss der Webseitenbetreiber 

per Programmcode auf der Website die 

Möglichkeit haben, die IP-Adressen nur 

anonymisiert zu erfassen und die letzten 

Stellen zu löschen. 

Der Bayerische Landesdatenschutzbeauftragte 

stellte fest, nur wenige Unternehmen 

halten sich daran und informierte 

einige Unternehmen [1]. Nachdem die 

Folgeprüfung ergab, dass einige noch immer 

nichts unternommen hatten, erließ 

man 106 Bußgeldbescheide. Auch dieses 

Beispiel zeigt, wie wichtig es ist, zu prüfen, 

ob die Vorgaben zur Auftragsdatenverarbeitung 

eingehalten werden. 

Bis 50 000 Euro Bußgeld 

Bei einem Verstoß gegen die Vorgaben zur 

Auftragsdatenverarbeitung kann dies mit 

einem Bußgeld von bis zu 50 000 Euro 

geahndet werden. In § 43 I Nr. 2 b BDSG 

heißt es: „Ordnungswidrig handelt, wer 

vorsätzlich oder fahrlässig … entgegen 

§ 11 Absatz 2 Satz 2 einen Auftrag nicht 

richtig, nicht vollständig oder nicht in der 

vorgeschriebenen Weise erteilt oder entgegen 

§ 11 Absatz 2 Satz 4 sich nicht vor 

Beginn der Datenverarbeitung von der 

Einhaltung der beim Auftragnehmer 

getroffenen technischen 

und organisatorischen 

Maßnahmen überzeugt.“ Im 

Gesetz heißt es weiter: „Die 

Geldbuße soll den wirtschaftlichen 

Vorteil, den der Täter 

aus der Ordnungswidrigkeit 

gezogen hat, übersteigen. 

Reichen die in Satz 1 genannten 

Beträge hierfür nicht aus, 

so können sie überschritten 

werden.“ 

Die Aufsichtsbehörden prüfen, 

ob Unternehmen sich daran 

halten. Ein weiteres Beispiel: 

Die Europcar Autovermietung 

GmbH hatte einen Teil ihrer 



Login 

Autos ohne Wissen der Mieter per GPS 

orten lassen. Der Hamburgische Beauftragte 

für Datenschutzschutz und Informationsfreiheit 

ahndete dies mit einem 

Bußgeld von 54 000 Euro. Die Mieter der 

Fahrzeuge wussten nichts von der Ortung 

und hatten ihr nicht zugestimmt. Der Vertrag 

über die Auftragsdatenverarbeitung 

mit dem Ortungsunternehmen fehlte. 

An die Auftragsdatenverarbeitung stellt 

das Bundesdatenschutzgesetz hohe Anforderungen. 

Sobald ein externer Dienstleister 

beauftragt wird und dieser personenbezogene 

Daten bearbeitet, die er 

vom Auftraggeber erhält, muss man sich 

mit dem Anbieter unterhalten: Wie steht 

es um den Datenschutz? Zwar delegiert 

man Aufgaben mit einem Werk- oder 

Dienstvertrag. Die Verantwortung für den 

Datenschutz für diese Kundendaten kann 

man aber oft nicht in derselben Weise 

delegieren. 

Einen seriösen und kompetenten Dienstleister 

erkennt man daran, dass er auf 

die Frage nach der Auftragsdatenverarbeitung 

nicht die Stirn runzelt, sondern 

eine kompetente Antwort parat hat und 

vielleicht auch schon einen Vertragsvorschlag, 

sofern er nötig ist. Es kann gravierende 

Folgen haben, wenn man mit 

einem Dienstleister zusammenarbeitet, 

der den Datenschutz nicht ernst nimmt. 

Den richtigen Dienstleister 

auswählen 

Das deutsche Datenschutzrecht verlangt: 

1. eine Vorabprüfung des Dienstleisters, 

2. eine schriftliche Datenschutzvereinbarung 

mit dem Dienstleister (sogenannter 

Vertrag zur Auftragsdatenverarbeitung), 

3. zu kontrollieren, ob die Vereinbarung 

eingehalten wird. 

Diese Datenschutzvereinbarung ergänzt 

den Werk- oder Dienstvertrag für die 

Dienstleistung. Das Gesetz regelt genau 

den Mindestinhalt einer solchen Vereinbarung. 

Einigermaßen kompliziert wird 

es, wenn der IT-Dienstleister im Ausland 

beziehungsweise außerhalb der Europäischen 

Union seinen Sitz hat und dort 

die Daten verarbeitet (siehe Kasten 

"Server im Ausland)". Spätestens dann 

sollte man einen beratenden Anwalt hinzuziehen, 

und gegebenenfalls muss man 

sich nach einem alternativen Anbieter 

umsehen. 

Wann liegt Auftragsdatenverarbeitung 

vor? 

Die sogenannte Auftragsdatenverarbeitung 

ist in § 11 des Bundesdatenschutzgesetzes 

(BDSG) geregelt. Dort heißt es 

in Absatz 1: „Werden personenbezogene 

Server im Ausland – welches Recht gilt? 

Viele große Cloud-Computing-Anbieter erfassen 

Daten in Deutschland, speichern sie jedoch auf 

Servern irgendwo außerhalb der EU, etwa in den 

USA. Nicht jedes Land bietet ein so hohes Datenschutzniveau 

wie Deutschland. Das strenge 

deutsche Datenschutzrecht gilt in vielen Fällen 

auch dann, wenn im Inland ordnungsgemäß erhobenen 

Daten in ein anderes Land übermittelt 

werden. Der Auftraggeber sollte sich im Vorfeld 

darüber informieren, wo die Daten verarbeitet 

werden. Zum Schutz gilt: Diese Daten dürfen 

nur innerhalb Deutschlands und der EU, sowie 

Norwegen, Island und Liechtenstein ohne Weiteres 

von den Unternehmen weiter übermittelt 

werden. 

Niveau ausreichend 

Darüber hinaus hat die Europäische Kommission 

einigen Ländern bescheinigt, dass ihr Datenschutzniveau 

hoch genug sei. Dazu gehören 

etwa: Kanada, Israel, die Schweiz und Argentinien. 

Für die USA hat die EU-Kommission die sogenannten 

„Safe Harbor Principles“ anerkannt. 

Unternehmen, die diese Standards akzeptieren, 

gewährleisten von sich aus einen höheren Datenschutz, 

als es das Gesetz verlangt. Dies sind etwa 

Amazon, Google und Microsoft. Bevor Sie einen 

Anbieter auswählen, erkundigen Sie sich, ob mindestens 

die „Safe Harbor Principles“ anerkannt 

werden. Zudem gibt es bei Datenübertragungen 

ins Ausland die Möglichkeit, einen ähnlich hohen 

Datenschutz wie in der EU zu vereinbaren, etwa 

mit EU-Standardvertragsklauseln [4]. 

Vorsicht gilt aber, sobald man diese Klauseln modifiziert. 

Bei Anbietern aus den USA muss man 

zudem wissen: Diese unterliegen dem „Patriot 

Act“, der es US Behörden erlaubt, zur Terrorabwehr, 

auf Daten der Unternehmen zuzugreifen. 

Dies gilt auch für europäische Niederlassungen 

von US-Unternehmen. Dies kann Bußgelder für 

den Auftraggeber wegen eines Verstoßes gegen 

deutsches Datenschutzrecht nach sich ziehen, 

wenn man diesen Zugriff nicht bedenkt. Entweder 

wählt man einen anderen Anbieter oder 

versucht per Vertrag den Speicherstandort festzuklopfen 

und/oder versucht mit anwaltlicher 

Hilfe zu prüfen, ob man mit einer klaren vertraglichen 

Regelung, den Zugriff der Behörden 

auf die Daten ausschließen kann, etwa indem 

man die Weitergabe der Daten bei Vertragsstrafe 

verbietet, insbesondere an US-Behörden. 

Standortfrage 

Die Orientierungshilfe der Datenschutzbehörden 

zum Cloud Computing: „Durch vertragliche 

Vereinbarungen zwischen dem Cloud-Anwender 

und dem Cloud-Anbieter muss der Ort der technischen 

Verarbeitung personenbezogener Daten 

vereinbart werden. Cloud-Anbieter sowie 

Unter-Anbieter können so verpflichtet werden, 

nur technische Infrastrukturen zu verwenden, 

die sich physisch auf dem Gebiet des EWR befinden. 

Es ist daher nicht hinnehmbar, dass der 

Cloud-Anbieter eine Auskunft zu den Standorten 

der Datenverarbeitung verweigert, keinesfalls 

dürfte bei einer Verweigerung pauschal von 

einer Cloud im innereuropäischen Raum ausgegangen 

werden.“ 

Bei einem IT-Dienstleister, der außerhalb 

Deutschlands, aber in der Europäischen Union 

arbeitet, ist nach der Europäischen Richtlinie 

95/46/EG ein Vertrag zur Auftragsdatenverarbeitung 

erforderlich. Die „Artikel 29 Gruppe“, 

eine Datenschutzgruppe konkretisierte in einem 

Working Paper Nr. 196 vom Juli 2012 (S. 16 ff.) 

die Inhalte [5]. 

Darin heißt es: „Sollte der für die Verarbeitung 

Verantwortliche Niederlassungen in mehreren 

Mitgliedstaaten haben und die Daten als Teil 

seiner Tätigkeit in diesen Ländern verarbeiten, 

ist jeweils das Recht jedes Mitgliedstaates anzuwenden, 

in dem die Verarbeitung stattfindet.“ 

Auch Kleine verantwortlich 

Oft haben KMUs das Problem, dass Cloud Computing 

Anbieter die Vertragsklauseln starr 

vorgeben. Darauf haben kleinere Kunden nicht 

immer einen Einfluss. Das Working Paper dazu: 

„Es sollte angemerkt werden, dass Anbieter von 

Cloud-Diensten in vielen Fällen Standarddienste 

und von den für die Verarbeitung Verantwortlichen 

zu unterzeichnende Standardverträge 

anbieten, die ein Standardformat für die Verarbeitung 

personenbezogener Daten festlegen. 

Das Ungleichgewicht in der Vertragsposition 

zwischen einem kleinen für die Verarbeitung 

Verantwortlichen und großen Dienstleistern darf 

nicht als Rechtfertigung dafür gelten, dass für 

die Verarbeitung Verantwortliche Vertragsklauseln 

und ‐bedingungen akzeptieren, die gegen 

das Datenschutzrecht verstoßen.“ Es befreit 

den Nutzer von Cloud-Diensten nicht von den 

Anforderungen des deutschen Datenschutzrechtes, 

wenn sich der mächtigere Cloud-Anbieter 

nicht um die Vorgaben nach europäischem Recht 

kümmert. Der Kunde bleibt für den Datenschutz 

verantwortlich und sollte mit Kontrollen der Aufsichtsbehörden 

rechnen. 


Admin 


17

Login 


© stylephotographs, 123RF 

Daten im Auftrag durch andere Stellen 

erhoben, verarbeitet oder genutzt, ist 

der Auftraggeber für die Einhaltung der 

Vorschriften dieses Gesetzes und anderer 

Vorschriften über den Datenschutz verantwortlich… 

." Die Verantwortung für 

den Datenschutz trägt weiterhin der Auftraggeber, 

wenn ein anderes Unternehmen 

die Daten von Kunden im Auftrag 

verarbeitet. In der Praxis haben Unternehmen 

oft Schwierigkeiten einzustufen, 

ob das konkrete Outsourcing-Projekt eine 

Auftragsdatenverarbeitung ist oder nicht. 

Ein Kriterium ist: Der Dienstleister ist 

weisungsgebunden und muss die Anweisungen 

des Auftraggebers ausführen. 

Anders ist dies bei der sogenannten 

Funktionsübertragung, bei der der externe 

Dienstleister nicht den Weisungen 

des Auftraggebers unterliegt. Ein weiteres 

Kriterium für Auftragsdatenverarbeitung 

ist, dass der Auftragnehmer die Daten 

nur im Rahmen der Weisungen des Auftraggebers 

verarbeiten darf. Sobald der 

Dienstleister die Daten für eigene Zwecke 

nutzt, handelt es sich nicht mehr um 

Auftragsdatenverarbeitung. Diese Form 

der Datenübermittlung ist dann nach den 

§§ 28 ff BDSG zu prüfen. Die Grenze ist 

oft nicht eindeutig und fließend. 

Beispiele für Auftragsdatenverarbeitung 

können je nach konkretem Inhalt des 

individuellen Vertrages und Art der Daten 

sein: Entsorgungsunternehmen für 

Akten oder Daten, Hostingprovider, ASP- 

Provider, Archivierungsdienste, Backup- 

Dienstleister, Schreibbüros, Rechenzentren, 

Adressdienstleister, Newsletterversand 

durch Werbeagentur. 

Nicht jeder Outsourcing-Prozess 

ist Auftragsdatenverarbeitung. 

Man sollte sich bei 

der Einstufung an der Frage 

orientieren: Besteht der Kern 

der Dienstleistung darin, 

personenbezogene Daten zu 

verarbeiten oder nicht. Sieht 

eine Supportfirma während 

des Supports in einer Datenmaske 

personenbezogene 

Daten, muss es sich je nach 

Auftragsumfang nicht unbedingt 

um Auftragsdatenverarbeitung 

handeln. Dennoch 

sollte man diese Unternehmen 

auf die Geheimhaltung 

verpflichten oder Daten verschlüsseln. 

Bei der Datenübertragung an 

einen Steuerberater handelt es sich nicht 

um Auftragsdatenverarbeitung. 

Schriftform gefordert 

Der Auftrag ist schriftlich zu erteilen, 

wobei insbesondere im Einzelnen festzulegen 

sind: 

1. der Gegenstand und die Dauer des 

Auftrags, 

2. der Umfang, die Art und der Zweck der 

vorgesehenen Erhebung, Verarbeitung 

oder Nutzung von Daten, die Art der Daten 

und der Kreis der Betroffenen, 

3. die nach § 9 zu treffenden technischen 

und organisatorischen Maßnahmen, 

4. die Berichtigung, Löschung und Sperrung 

von Daten, 

5. die nach Absatz 4 bestehenden Pflichten 

des Auftragnehmers, insbesondere 

Kontrollen, 

6. die etwaige Berechtigung zur Begründung 

von Unterauftragsverhältnissen, 

7. die Kontrollrechte des Auftraggebers 

und die Duldungs- und Mitwirkungspflichten 

des Auftragnehmers, 

8. mitzuteilende Verstöße des Auftragnehmers 

oder der bei ihm beschäftigten 

Personen gegen Vorschriften zum Schutz 

personenbezogener Daten oder gegen die 

im Auftrag getroffenen Festlegungen, 

9. der Umfang der Weisungsbefugnisse, 

die sich der Auftraggeber gegenüber dem 

Auftragnehmer vorbehält, 

10. die Rückgabe überlassener Datenträger 

und die Löschung beim Auftragnehmer 

gespeicherter Daten nach Beendigung 

des Auftrags. 

Abbildung 2: Wer die Verarbeitung personenbezogener Daten in Auftrag gibt, ist 

verpflichtet, den Dienstleister vorher unter die Lupe zu nehmen. 

Da der beauftragte Dienstleister seine 

Dienstleistung am besten kennt, fragt 

man am besten diesen nach einem Muster, 

das seine Angaben bereits enthält 

und passt dies an den konkreten Auftrag 

an. Zur Orientierung dient die von der 

BITKOM vorgeschlagene Mustervertragsanlage 

[2]. 

Technische und organisatorische 

Maßnahmen 

Einen Schwerpunkt der Vereinbarung 

bilden die technischen und organisatorischen 

Maßnahmen nach § 9 BDSG, die 

der Dienstleister garantiert. 

§ 9 BDSG regelt: „Öffentliche und nichtöffentliche 

Stellen, die selbst oder im Auftrag 

personenbezogene Daten erheben, 

verarbeiten oder nutzen, haben die technischen 

und organisatorischen Maßnahmen 

zu treffen, die erforderlich sind, um 

die Ausführung der Vorschriften dieses 

Gesetzes, insbesondere die in der Anlage 

zu diesem Gesetz genannten Anforderungen, 

zu gewährleisten. Erforderlich sind 

Maßnahmen nur, wenn ihr Aufwand in 

einem angemessenen Verhältnis zu dem 

angestrebten Schutzzweck steht.“ 

Die Anlage zu § 9 BDSG sieht die im Kasten 

Die acht Gebote der IT-Sicherheit 

genannten Gebote vor. 

Der Auftraggeber ist in der Pflicht, den 

Dienstleister im Vorfeld unter die Lupe 

zu nehmen. Mögliche Experten beim 

Dienstleister, die man ansprechen kann 

sind: Datenschutz- oder IT-Sicherheitsbeauftragter, 

IT-Leiter, IT-Revisor oder der 

externe IT-Dienstleister. Diese sollte man 

nach Dokumentationen fragen, 

um die Prüfung vor Ort 

vorzubereiten. Anhand des 

ersten Eindrucks der Unterlagen 

sieht man oft schon, wie 

gut der Dienstleister arbeitet 

und ob er für die Prüfung vorbereitet 

ist und sich mit den 

Themen auseinandergesetzt 

hat. 

Bevor man einen Dienstleister 

prüft, sollte man sich einen 

Fragenkatalog zusammenstellen, 

der sich an der Anlage 

nach § 9 BDSG orientiert. Eine 

Vorbereitung für die Prüfung 

bietet unter anderem der IT- 

Grundschutzkatalog des BSI. 



Login 

Fragen Sie den Dienstleister, wie er bei 

bestimmten Problemen in der Praxis verfährt, 

ob es Notfallpläne gibt, wo er die 

Daten speichert, wie der Datentransfer 

erfolgt, wie die Zugriffsrechte der Mitarbeiter 

geregelt sind und vieles mehr. 

Ferner gehört in den Fragenkatalog, ob 

sich die Mitarbeiter im Unternehmen des 

Dienstleisters schriftlich auf das Datengeheimnis 

nach § 5 BDSG verpflichtet haben 

und über die sich aus diesem Auftrag ergebenden 

besonderen Datenschutzpflichten 

sowie die bestehende Weisungs- oder 

Zweckbindung belehrt sind. 

Neben den technischen Einzelheiten liefern 

die Antworten einen ersten Eindruck 

vom Datenschutz in diesem Unternehmen. 

Die Prüfung ist zu protokollieren, 

und am Ende sollte eine Anlage zum Vertrag 

über die Auftragsdatenverarbeitung 

stehen, die die getroffenen technischen 

und organisatorischen Vorgaben zusammenfasst. 

Einen Mustervertrag der GDD, 

an dem man sich gut orientieren kann, 

findet man hier [3]. 

Vor-Ort-Kontrolle nicht 

immer möglich 

Es ist schwer denkbar, dass ein Cloud 

Computing Anbieter am anderen Ende 

der Welt zu sich einlädt, um sich prüfen 

zu lassen. Der von Google vorgeschlagene 

Vertrag für Google Analytics enthält 

in der Anlage 2 die technischen und organisatorischen 

Maßnahmen. Google hält 

für die Prüfung der Maßnahmen einen 

Die acht Gebote der IT-Sicherheit 

1. Unbefugten den Zutritt zu Datenverarbeitungsanlagen 

verwehren, mit denen personenbezogene 

Daten verarbeitet oder genutzt 

werden (Zutrittskontrolle), 

2. Verhindern, dass Unbefugte Datenverarbeitungssysteme 

nutzen (Zugangskontrolle), 

3. Gewährleisten, dass die zur Benutzung eines 

Datenverarbeitungssystems Berechtigten ausschließlich 

auf die ihrer Zugriffsberechtigung 

unterliegenden Daten zugreifen können, und 

dass personenbezogene Daten bei der Verarbeitung, 

Nutzung und nach der Speicherung nicht 

unbefugt gelesen, kopiert, verändert oder entfernt 

werden können (Zugriffskontrolle), 

4. Garantieren, dass personenbezogene Daten 

bei der elektronischen Übertragung oder während 

ihres Transports oder ihrer Speicherung 

auf Datenträger nicht unbefugt gelesen, kopiert, 

verändert oder entfernt werden können, 

Prüfbericht bereit von einem unabhängigen 

Wirtschaftsprüfer, der alle 24 Monate 

erneuert wird. Dies reicht aus. Es muss 

nicht immer eine Vor-Ort-Prüfung sein, 

sondern man kann sich aktuelle Prüfberichte, 

Testate unabhängiger Instanzen 

vorlegen lassen (z.B. Wirtschaftsprüfer, 

Revision, Datenschutzbeauftragter, IT- 

Sicherheitsabteilung, Datenschutzauditoren, 

Qualitätsauditoren) oder eine 

geeignete Zertifizierung durch IT-Sicherheits- 

oder Datenschutzaudits (z.B. nach 

BSI-Grundschutz). Die Unterlagen sollte 

man in Kopie verlangen und prüfen und 

nicht nur abheften. Nur dann ist die Kontrollpflicht 

erfüllt. Es ist ratsam, sich zusätzlich 

eine Vor-Ort-Kontrolle vertraglich 

vorzubehalten. 

Mit der erstmaligen Prüfung vor Auftragsbeginn 

ist es nicht getan. „Der Auftraggeber 

hat sich vor Beginn der Datenverarbeitung 

und sodann regelmäßig von 

der Einhaltung der beim Auftragnehmer 

getroffenen technischen und organisatorischen 

Maßnahmen zu überzeugen. 

Das Ergebnis ist zu dokumentieren.“ Man 

muss sich in regelmäßigen Abständen 

wieder von der IT-Sicherheit überzeugen. 

Wie oft dies zu geschehen hat, regelt das 

Gesetz nicht. Ein Anlass könnten bekannt 

gewordene Sicherheitsmängel sein. 

Praxisproblem: 

Subunternehmer 

In dem Vertrag mit dem IT-Dienstleister 

sollten sämtliche Unterauftragnehmer 

und dass überprüft und festgestellt werden 

kann, an welchen Stellen eine Übermittlung 

vorgesehen ist (Weitergabekontrolle), 

5. Sorge tragen, dass nachträglich überprüft 

und festgestellt werden kann, ob und von wem 

personenbezogene Daten in Datenverarbeitungssysteme 

eingegeben, verändert oder entfernt 

worden sind (Eingabekontrolle), 

6. Verantwortung dafür übernehmen, dass personenbezogene 

Daten, die im Auftrag verarbeitet 

werden, nur entsprechend den Weisungen 

des Auftraggebers verarbeitet werden können 

(Auftragskontrolle), 

7. Gewährleisten, dass personenbezogene Daten 

gegen zufällige Zerstörung oder Verlust 

geschützt sind (Verfügbarkeitskontrolle), 

8. Garantieren, dass zu unterschiedlichen Zwecken 

erhobene Daten getrennt verarbeitet werden 

können. (Datentrennung) 

aufgeführt sein, denen sich der IT-Dienstleister 

bedient und geregelt werden, unter 

welchen Voraussetzungen dies erlaubt 

ist. Der IT-Dienstleister muss den Subunternehmer 

ebenfalls nach den Regeln der 

Auftragsdatenverarbeitung kontrollieren 

und sollte seine Pflichten weiterreichen. 

Der Dienstleister sollte einen Datenschutzbeauftragten 

benennen. Gesetzlich 

vorgeschrieben ist dieser, sofern personenbezogene 

Daten erhoben, verarbeitet 

oder genutzt werden und damit in der 

Regel mindestens 20 Personen beschäftigt 

sind. Auch der Auftraggeber tut gut 

daran, einen Datenschutzbeauftragten zu 

benennen. Wer entgegen dem Gesetz keinen 

Datenschutzbeauftragten hat, dem 

drohen Sanktionen. Man tut also gut 

daran, noch heute den Geschäftsführer 

auf Defizite im Bereich Datenschutz hinzuweisen 

und vielleicht schon morgen 

einen Datenschutzbeauftragten zu benennen, 

der Outsourcing-Projekte genau 

unter die Lupe nimmt. (jcb) 

n 

Infos 

[1] FAQ des bayerischen Datenschutzbeauftragten: 

[http:// www. lda. bayern. de/ 

onlinepruefung/ googleanalytics. html# faq] 

[2] Mustervorlage des BITKOM: [http:// 

www. bitkom. org/ de/ publikationen/ 

38336_45940. aspx] 

[3] Mustervertrag der GDD: [https:// www. gdd. 

de/ nachrichten/ news/ neues‐gdd‐muster‐zu 

r‐auftragsdatenverarbeitung‐gemas‐a7‐11‐ 

bdsg] 

[4] EU-Standardvertragsklauseln: [http:// 

eur‐lex. europa. eu/ LexUriServ/ LexUriServ. 

do? uri=OJ:L:2010:039:0005:0018:DE:PDF] 

[5] Working Paper der Artikel-29- 

Gruppe: [http:// ec. europa. eu/ justice/ 

data‐protection/ article‐29/ documentation/ 

opinion‐recommendation/ files/ 2012/ 

wp196_de. pdf] 

Die Autorin 

Die Autorin ist Rechtsanwältin & Fachjournalistin 

für IT-Recht in Berlin. Sie veröffentlicht seit 

1997 zu Fragen des IT-Rechtes. Darüber hinaus 

referiert sie zu aktuellen Fragen des Internetrechtes, 

gibt Workshops zum 

Softwarelizenzrecht oder 

zur IT-Sicherheit und unterrichtet 

als Lehrbeauftragte 

für IT-Recht an der Beuth 

Hochschule für Technik. 

© Mira Burgund 


Admin 


19

Login 

Admin-Story 

© Mikhail Dudarev, 123RF 

Eine Webanwendung mit MongoDB und Bottle 

Flaschengeist 

Für ein aktuelles Projekt habe ich vor Kurzem nach einem stabilen, 

flexiblen und gut skalierbaren Datenbackend für eine Webapplikation 

gesucht. Bereits nach kurzer Zeit fiel die Wahl auf die NoSQL-basierte 

MongoDB. Thorsten Scherf 

Die üblichen Verdächtigen für Datenbank-Systeme 

im OpenSource-Bereich 

waren in der Vergangenheit schnell ausgemacht. 

In Zeiten von Web 2.0 hat sich 

jedoch einiges geändert. Statt von MySQL 

oder PostgreSQL spricht man heute eher 

von CouchDB, FluidDB oder MongoDB. 

Diese Datenbanken haben einen ähnlichen 

Funktionsumfang wie klassische 

SQL-Server, besitzen dabei allerdings 

eine wesentlich höhere Performance und 

Skalierbarkeit. Diese reicht zwar nicht 

an Systeme wie Memcached oder andere 

einfache Key/Value-Store-Systeme 

heran, jedoch wird dieses Manko durch 

den erhöhten Funktionsumfang bei immer 

noch ausgezeichneter Performance 

wettgemacht. 

Hinzu kommt, dass die Performance von 

solchen Systemen sehr gut in der Breite 

skaliert. Anstatt also teure Hardware 

einkaufen zu müssen, lässt sich eine 

Datenbank leicht über mehrere Systeme 

verteilen, ohne dass negative Auswirkungen 

auf die Funktionalität zu befürchten 

wären. 

MongoDB 

MongoDB ist in allen größeren Linux- 

Distributionen bereits enthalten. Im 

Zusammenspiel mit Python und einem 

Webframework lassen sich hiermit in 

kurzer Zeit beachtliche Erfolge erzielen. 

In meinem Beispiel kommt das Micro- 

Webframework Bottle zum Einsatz. Dieses 

sehr einfache Framework besteht aus 

einer einzelnen Datei, welche mittels 

»easy_install« auf dem eigenen System 

installiert wird. Das Framework eignet 

sich für erste Tests mit MongoDB sehr 

gut, da es keinerlei Abhängigkeiten, ausser 

auf die Python-Standard-Bibliothek, 

besitzt, dabei jedoch eine Menge an 

Funktionalität anbietet. So unterstützt es 

beispielsweise auch Templates und bringt 

einen Webserver von Haus aus mit. Als 

Schnittstelle zwischen dem MongoDB- 

Service und dem Webframework Bottle 

setze ich Pymongo ein, welches ebenfalls 

in den meisten Distributionen bereits zur 

Verfügung stehen sollte. 

MongoDB unterteilt eine Datenbank in 

sogenannte Collections, in denen Dokumente 

gespeichert sind. Diese enthalten 

die Datenbank-Objekte im JSON-Format. 

Das Schöne dabei ist, dass die Collections 

keinem Schema unterliegen. Das bedeutet, 

man kann einfach die gewünschten 

Daten in die Datenbank übertragen, ohne 

sich groß Gedanken über Schema-Anpassungen 

machen zu müssen. Das vereinfacht 

die Arbeit ungemein. Die einzelnen 

Felder eines Dokuments können dabei 

immer noch nach Belieben angefragt 

werden, und auch Indizes lassen sich für 

oft abgefragte Felder setzen. 


Admin-Story 

Login 

Für einen ersten Test verwende ich die 

Mongo-Shell, um ein solches Dokument 

zu erzeugen (Listing 1). 

Schemalos 

In dem Beispiel ist schön zu sehen, dass 

sich die Datensätze durch das Feld Mitglieder 

unterscheiden. In zwei Datensätzen 

ist es enthalten, im dritten Dokument 

fehlt es komplett, was aber kein Problem 

ist, da MongoDB ja über kein fixes 

Schema verfügt. 

Wer seine Dokumente bereits im JSON- 

Format vorliegen hat, der kann diese 

Abbildung 1: Über ein einfaches HTML-Eingabeformular 

soll der Benutzer seinen Lieblingsverein 

angeben. 

ganz in einem Streich in die Datenbank 

importieren: 

# mongoimport ‐d football ‐c clubs ‐‐file U 

/tmp/myclubs.json 

connected to: 127.0.0.1 

Mon Dec 3 08:43:26 imported 23 objects 

Ein Dokument mit einem bestimmten 

Feld abzufragen, ist auch recht einfach: 

> db.clubs.find({Mitglieder: {"$gt": U 

100000}}){ "_id" : ObjectId("50bd2169a80eU 

4531863ea2a8"), "Name" : "FC Schalke 04", U 

"Farben" : "BlauWeiß", "Mitglieder" : U 

111000, "Anschrift" : [ { "Strasse" : U 

"Ernst‐Kuzorra‐Weg 1", "PLZ" : 45891, U 

"Stadt" : "Gelsenkirchen" } ] } 

Abbildung 2: Die Auswahl bekommt der Benutzer 

dann auf einer neuen Seite angezeigt, zusammen 

mit der Information, wie oft der Verein bereits von 

anderen Benutzern angegeben wurde. 

Für eine kleine Webanwendung fehlt nun 

noch ein passendes Framework und ein 

Stück Software, welches die Verbindung 

zwischen Framework und MongoDB herstellt. 

Für Erstes kommt, wie eingangs erwähnt, 

das Micro-Framework Bottle zum 

01 # mongo 

Listing 1: Test 

02 MongoDB shell version: 2.2.0 

03 connecting to: test 

04 > use football 

05 switched to db football 

06 > db.clubs.save({ Name:"FC Schalke 04", 

Farben:"BlauWeiß", Mitglieder:111000, 

Anschrift:[{Strasse: 

"Ernst‐Kuzorra‐Weg 1", PLZ: 45891, Stadt: 

"Gelsenkirchen"}] }) 

07 > db.clubs.save({ Name:"St. Pauli", Farben:"BraunWeiß", 

Mitglieder:15000, Anschrift:[{Strasse: 

"Heiligengeistfeld 1", PLZ: 20359, Stadt: 

"Hamburg"}] }) 

08 > db.clubs.save({ Name:"FC Nürnberg", Farben:"RotWeiß", 

Anschrift:[{Strasse:"Valznerweiherstrasse 200", PLZ: 

90480, Stadt: "Nürnberg"}] } 

Anzeige 

Die heute führenden Spezialisten stammen oft aus der "Freie Software-Szene" und schulen seit 

Jahren im Linuxhotel. Das erklärt die Breite und Qualität unseres Schulungsangebotes: 

AJAX * Amavis * Android * Angriffstechniken * Apache * Asterisk * BaseX * BayesianAnalysis * Bind * C/C++ * Cassandra * 

CiviCRM * Cloud * Cluster * ClusterFS * CouchDB * CSS3 * CUPS * Debian * DHCP * DNS * DNSSEC * Echtzeit Linux * 

Embedded Linux * eXist-db * Faces * FAI * Firewall * Forensik * FreeBSD * FreeRADIUS * GeoExt * Git * Grails * GRASS * 

Groovy * hadoop * Hochverfügbarkeit * HTML5 * Hudson * iSCSI * IPv6 * ITSM * Java * JavaScript * Jenkins * Kernel * KVM 

* LDAP * LibreOffice * Linux * LPI * m23 * MacOSX * MapFish * Mapserver * Maven * Mikrocontroller * MVS/380 * MySQL * 

Nagios * Node.js * OpenBSD * OpenLayers * OpenOffice * openQRM * OpenVPN * OPSI * OSGi * OTRS * Perl * PHP * 

Postfix * PostgreSQL * Puppet * Python * QuantumGIS * R * Rails * RedHat * Routing * Request-Tracker RT * Ruby * Samba 

* SAN * Scala * Scribus * Shell * Sicherheit * SNMP * Spacewalk * Spamfilter * SQL * Struts * Subversion * SuSE * TCP/IP * 

Tomcat * Treiber * TYPO3 * Ubuntu * UML * Unix * Univention * Virenfilter * Virtualisierung * VoIP * WebGIS * Webservices * 

Windows Autoinstall * Windowsintegration * x2go * xen * XML * Xpath * Xquery * z/OS * Zabbix * Zend 

Fast 100% der Teilnehmer empfehlen uns weiter. Siehe www.linuxhotel.de 

Ja, wir geben es zu und haben überhaupt kein schlechtes Gewissen dabei: Unsere Schulungen machen auch Spaß ;-) 


Admin 


21

Login 

Admin-Story 

Einsatz. Um die Funktionen zu demonstrieren, 

greift die Beispielanwendung auf 

Templates und Views zurück, auch wenn 

dies hier nicht zwingend erforderlich ist. 

Pymongo stellt die Schnittstelle zwischen 

Framework und Datenbank her und überträgt 

die Dokumente im BSON-Format 

über das Netz. 

Views 

Meine Anwendung besteht aus einer 

Steuerungsdatei (Listing 2) und 2 View- 

Dateien, die als Templates definiert sind 

(Listing 3 und 4). Bottle erwartet die 

View-Dateien dabei im Ordner »views« 

unterhalb der eigentlichen Anwendung. 

In der Datei »survey.py« erzeugt der Aufruf 

in Zeile 6 ein »connection«-Objekt 

zur Kommunikation mit dem MongoDB- 

Service auf dem gleichen System, auf 

dem auch das Webframework läuft. 

Listing 3: »views/main.tpl« 

01 

02 

03 

04 

05 My little Bottle example 

06 

07 

08 

09 Hi World..here is my little survey! 

10 

Listing 2: »survey.py« 

01 #!/usr/bin/python 

02 

03 import bottle 

04 import pymongo 

05 

06 connection = pymongo.Connection('localhost', 

27017) 

07 db = connection.survey 

08 clubs = db.clubs 

09 

10 @bottle.route('/') 

11 def index(): 

12 return bottle.template('main') 

13 

14 @bottle.post('/survey') 

In den Zeilen 7-8 wird dann ein Handler 

für die Datenbank und die gewünschte 

Collection definiert. In Zeile 10 und Zeile 

14 wird jeweils eine Route, sprich, eine 

URL mit dem dazugehörigen Code definiert. 

Die Einsprungsseite (»/«) gibt 

lediglich ein Template zurück, das dem 

Benutzer eine einfach Umfrageseite präsentiert 

(»main.tpl«). Die daraus resultierende 

Post-Anweisung wird über die 

zweite URL (»/survey«) verarbeitet. Hier 

wird das Ergebnis der Umfrage in einem 

Dokument mit einem einzigen Feld 

(»club«) in der Datenbank gespeichert, 

und der Benutzer bekommt einer Ausgabe, 

welchen Verein er denn als seinen 

Lieblingsverein angegeben hat, und wie 

oft dieser schon von anderen Benutzern 

angegeben wurde. 

Das zweite Template bekommt dabei eine 

Variable »club« und »results« übergeben 

(Zeile 25). »club« wird dabei der Inhalt 

15 def survey(): 

16 club = bottle.request.forms.get("club") 

17 if (club == None or club == ""): 

18 club="No club defined..." 

19 

20 clubs.save({"club":club}) 

21 results= clubs.find({"club":club}) 

22 results = results.count() 

23 

24 

25 return bottle.template('result', {"club":club, 

"results":results}) 

26 

27 bottle.run(host='localhost', port=8080, 

debug=1) 

11 

12 What is your favorite club? 

13 

14 input type="submit" value="Submit"> 

15 

16 

17 

18 

19 

des Eingabebox aus dem ersten Template 

und enthält den angegeben Lieblingsverein. 

»results« ist das Ergebnis einer Suche 

in der Datenbank, wie oft dieser Verein 

dort schon aufgeführt ist. Beide Variable 

werden dann in dem View-Template 

( Listing 4) in Zeile 9 und Zeile 10 verwendet. 

Die Anwendung sieht im Webbrowser 

dann so aus wie in Abbilung 1 

und Abbildung 2 dargestellt. 

Zusammenspiel 

Das Beispiel zeigt, wie simpel es ist, mit 

der Kombination aus Python, MongoDB, 

Bottle und Pymongo eine Webanwendung 

zu entwickeln. Das Beispiel ist natürlich 

bewusst einfach gehalten, aber 

zeigt, wie die einzelnen Komponenten 

zusammenarbeiten. Das Beispiel geht 

auch davon aus, dass MongoDB nur auf 

einem einzelnen Server läuft, und dass 

der in Bottle eingebaute Webserver zum 

Einsatz kommt. In produktiven Umgebungen 

sollte dies natürlich anders sein, 

aber für Entwicklungsarbeiten eignet sich 

das hier vorgestellte Setup sehr gut. 

Mittlerweile bin ich dazu übergegangen, 

Test-Anwendungen als PaaS-Apps in 

Openshift laufen zu lassen. Hier verweise 

ich auf einen anderen Artikel von mir 

zu der Thematik [1]. Mittlerweile kennt 

Openshift auch eine Cartridge, mit der 

sich MongoDB als Erweiterung installieren 

lässt. 

Wer sich nun näher mit dem Thema auseinandersetzen 

möchte, findet unter [2] 

jede Menge hilfreiche Dokumentation. 

Dort gibts auch genaue Beschreibung, 

wie eine Installation von MongoDB unter 

Openshift funktioniert. (ofr) 

n 

Infos 

[1] Thorsten Scherf, Auf Knopfdruck, ADMIN 

05/2011, [http:// www. admin‐magazin. de/ Das‐ 

Heft/ 2011/ 05/ Tagebuch‐eines‐IT‐Nomaden/] 

[2] MongoDB: [http:// mongodb.org] 

Listing 4: »views/result.tpl« 

01 

02 

03 

04 

05 Results 

06 

07 

08 

09 Favorite club: {{club}} 

10 It has mentioned {{results}} times far. 

11 

12 

13 

Der Autor 

Thorsten Scherf arbeitet als Senior Consultant für 

Red Hat EMEA. Er ist oft als 

Vortragender auf Konferenzen 

anzutreffen. Wenn neben 

Arbeit und Familie noch 

Zeit bleibt, nimmt er gerne 

an Marathonläufen teil. 


Open Source goes 

Präsentieren auch Sie sich auf der größten Sonderausstellung 

der CeBIT 2013 in Halle 6 zum Thema Linux und freie Software. 

Kleine und mittlere Unternehmen treffen hier auf hochrangige 

Entscheider. Nirgendwo sonst finden Sie eine bessere Business- 

Umgebung für Ihre Open Source Lösungen. 

Ein rundum perfekter Messeauftritt ‒ 

maximaler Erfolg mit minimalem Aufwand: 

• individuelle Standgrößen ab 4 m² 

• Alles-inklusive-Service (Standbau, Catering, Konferenzräume, u.v.m.) 

• direkte Ansprache zahlreicher Neukunden 

• ausgewählte Fachvorträge und Keynotes im Open Source Forum 

• Kontakt zur internationalen Open Source Community 

Jetzt anmelden! 

www.open-source-park.de 

oder 0 26 1 - 20 16 902 

Wir sind dabei! 

83degrees South Ltd., agorum® 

Software GmbH, Alfresco Software Ltd., 

All for Accounting GmbH, Ancud IT-Beratung 

GmbH, B1 Systems GmbH, CADEMIA-Consult 

GmbH, FOSS Group GmbH, GRAU DATA AG, 

Heinlein Support GmbH, IFE GmbH, Inmedias.it 

GmbH, ITOMIG GmbH, Mathias Kettner GmbH, 

Metaways Infosystems GmbH, NETWAYS GmbH, 

Opensides Sprl, Open Source Press GmbH, 

Pentaprise GmbH, Synetics gesellschaft für 

systemintegration mbh, uib gmbh, visual4 

GmbH, Würth Phoenix GmbH 

und viele mehr... 

Veranstalter: 

pluspol.de 

Marketing Kommunikation Internet 

In Kooperation mit: 

MEDIALINX AG

Netzwerk 

Nagios und VoIP 

© Natalia Lukiyanova, 123RF 

Nagios-Alarme via VoIP einfach realisiert 

Nagios am Apparat 

Von Hause aus kann Nagios bei Ausfall eines Dienstes die Admins nur per E-Mail alarmieren. Doch diese Mails 

können leicht übersehen werden. Ein Anruf wirkt da nachhaltiger. Benjamin Fleckenstein 

Ein klingelndes Telefon ist schwer zu 

überhören, und so liegt es nahe, Nagios 

das Telefonieren beizubringen, damit es 

wahrgenommen wird. Das gelingt beispielsweise 

mit einer Kombination von 

Nagios und Asterisk. Asterisk ist allerdings 

nicht trivial zu konfigurieren, und 

eine ganze Telefonanalage nur für das 

Monitoring aufbauen und betreuen zu 

müssen, ist womöglich doch etwas zu 

viel des Guten. 

Mithilfe eines SIP-Accounts, den man 

für wenig Geld im Internet bekommt, 

eines CLI-SIP Clients und eines einfachen 

Shellskriptes lässt sich das Gleiche mit 

weniger Aufwand realisieren. 

Zunächst der SIP Account: Hier hat man 

die Qual der Wahl, welchen Anbieter 

man verwenden möchte. Prinzipiell geht 

es mit jedem VoIP-Anbieter. Die Einrichtung 

des Accounts ist trivial, man füllt 

das entsprechende Online-Formular aus, 

wartet auf die Bestätigungsmail und richtet 

sich ein Konto ein. 

Der passende SIP-Client 

Nun der CLI-SIP-Client: Hier wird es etwas 

komplizierter. Es gibt zwar einige 

VoIP-Clients, die meisten sind jedoch 

für den Desktop gedacht und lassen sich 

schlecht bis gar nicht per Skript steuern. 

Letzlich erwies sich PJSUA als beste 

Wahl. PJSUA ist die Referenzimplementierung 

von PJSIP, was wiederum eine 

Kommunikationsbibliothek für SIP, RTP, 

STUN und einige weitere VoIP-bezogene 

Protokolle darstellt. 

Abbildung 1: Wie zu sehen, fungiert als Kommando, das die Benachrichtigung übernimmt, hier das E-Mail-Skript. 

Leider gibt es keine Pakete von PJSUA, 

sodass man es sich selbst aus den Quelle 

kompilieren muss, was aber zum Glück 

leicht gelingt. Die Quellen von PJSIP/ 

PJSUA besorgt man sich via: 

wget http://www.pjsip.org/release/2.0.U 

/pjproject‐2.0.1.tar.bz2 

In dem Verzeichnis, in dem man sie entpackt 

hat, reicht dann: 

./configure 

make dep 

make 

Nun liegt im Verzeichniss »pjsip‐apps/ 

bin« eine Datei, die mit »pjsua« beginnt. 

Das ist der SIP Client. Ihn kopiert man 

sich an eine beliebige Stelle des Systems 

und macht ihn dort ausführbar. Nun benötigt 

man noch eine Konfigurationsdatei 

für den Client, in der man die Zugangsdaten 

zum SIP-Provider angibt. 

Dafür erstellt man eine Textdatei mit den 

Inhalt aus Listing 1. Die Daten muss man 

natürlich an den eigenen SIP-Provider 




Inklusive: 

Der komplette 

Jahrgang 2012! 

JAHRES-DVD 2012 

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 

Außerdem auf der DVD: 

die admin-toolbox! 

Jetzt gleich bestellen! 

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

Netzwerk 

Nagios und VoIP 

anpassen, was nicht immer ganz einfach 

ist, da die Provider gerne eigene 

Bezeichnungen für ID und Realm verwenden. 

Im Zweifelsfall hilft die Hotline 

des Provider wahrscheinlich gerne weiter. 

»‐‐null‐audio« sorgt dafür, dass der Server 

keine Audioausgabe verwendet und so 

der Rechner das Gespräch nicht über die 

Lautsprecher ausgibt. 

Das Anruf-Skript 

Jetzt braucht man noch ein Skript, das 

Nagios im Fall der Fälle aufrufen kann. 

Dieses Skript sorgt auch dafür, dass sich 

die Benachrichtigungen nicht gegenseitig 

in die Quere kommen. Wenn Nagios zwei 

Telefonate kurz nacheinander absetzen 

muss, so sorgt das Skript dafür, dass der 

Listing 1: Provider-Daten 

01 ‐‐null‐audio 

02 ‐‐registrar sip:sipgate.de 

03 ‐‐realm=sipgate.de 

04 ‐‐id sip:username@sipgate.de 

05 ‐‐username sipgateusername 

06 ‐‐password sipgatepasswort 

Listing 3: »resource.cfg« 

01 # Additional commands, so that nagios can call the 

sysadmins 

02 define command { 

03 command_name notify‐host‐by‐phone 

04 command_line /opt/pjsua_wrapper 

05 } 

06 

07 define command { 

08 command_name notify‐service‐by‐phone 

09 command_line /opt/pjsua_wrapper 

10 } 

erste Anruf beendet ist, bevor es den 

zweiten startet. Sonst würde der Client 

den Dienst verweigern, weil die Leitung 

belegt ist, und die zweite Benachrichtigung 

würde verloren gehen. 

Das Skript benötigt noch zwei weitere 

Tools: »expect«, damit es »pjsua« steuern 

kann und »text2wave«, damit es aus 

einer Textzeile eine WAV Datei erzeugen 

kann. Das Tool »text2wave« ist Bestandteil 

von Festival, einem Programm zur 

Sprachsynthese. Beide Pakete kann man 

wieder über die Paketverwaltung installieren. 

Danach macht man das Skript aus 

Listing 2 ausführbar. 

Den Wert von »NUMBER« stellt man auf 

die Telefonnummer ein, die Nagios anrufen 

soll. »MESSAGE« enthält das, was 

der Angerufene zu hören bekommt. Wer 

die Telefonnummer nicht fest im Skript 

verdrahten möchte, kann Nagios die 

Nummer auch übergeben lassen. Über 

»DURATION« kann man einstellen, wie 

lange der Anruf maximal dauern soll. 

Geht in dieser Zeit keiner ans Telefon, 

legt das Skript wieder auf. Bei Anrufannahme 

spielt es die Nachricht in einer 

Schleife ab. In der Zeile, die mit »spawn« 

beginnt, muss man gegebenfalls das 

letzte Argument an den eigenen SIP Provider 

anpassen. 

Auf Kommando 

Schlussendlich muss man noch Nagios 

umkonfigurieren, sodass es das Skript 

im Alarmfall aufruft. Zunächst definiert 

man dazu ein neues Kommando. Nutzt 

man Ubuntu 12.04 und Nagios3, dann 

liegt unter »/etc/nagios3/resource.cfg« 

die passende Datei. Bei anderen Distributionen 

dürfte der Pfad nur geringfühig 

unterschiedlich sein. Dort fügt man den 

Inhalt von Listing 3 ein. 

In Listing 3 ist »/opt/pjsua_wrapper« ist 

der Pfad, unter dem das Skript gefunden 

werden kann. Gegebenenfalls muss 

man ihn anpassen. Anschließend ist nur 

noch die »contact«-Definition des Admins 

in Nagios anzupassen. Überlicherweise 

sieht die Konfiguration etwa so aus: 

define contact { 

... 

service_notification_commands U 

notify‐service‐by‐email 

host_notification_commands U 

notify‐service‐by‐email 

... 

} 

Die beiden Parameter erweitert man einfach 

um die neuen Kommandos: 

define contact { ... 

service_notification_commands 

notify-service-by-email,notify-host- U 

by-phone host_notification_commands U 

notify-service-by-email, 

notify-service-by-phone … } 

Anschließend Nagios neu starten, und 

schon wird der Admin angerufen. (jcb)n 

Der Autor 

Benjamin Fleckenstein ist Sysadmin bei einem 

Hosting und Telekommunikationsunternehmen in 

Frankfurt und kümmert sich dort um die Server 

namhafter Kunden. In seiner Freizeit beschäftigt 

er sich mit Open-Source-Gebäudeautomation und 

baut aktuell das notwendige Gebäude. 

Listing 2: Anruf-Skript 

01 #! /bin/bash 

02 

03 EXPECT=/usr/bin/expect 

04 PJSUA=/opt/pjsua 

05 PJSUACONFIG=/opt/pjsua.conf 

06 SOUNDFILE=/tmp/alert.wav 

07 TEXT2WAVE=/usr/bin/text2wave 

08 DURATION=20 

09 NUMBER=01234567890 

10 MESSAGE="Monitoring Alert" 

11 

12 # Setting a lock file 

13 # We can't make more than one call 

14 # at a time, because pjsua blocks the port 

15 # so we have to make sure that nobody else 

tries to call 

16 # If there is already a call we have to wait. 

17 

18 locked=false 

19 while [[ $locked == false ]]; do 

20 if [[ ! ‐f /tmp/caller.lock ]]; then 

21 touch /tmp/caller.lock 

22 locked=true 

23 else 

24 sleep 5 

25 fi 

26 done 

27 

28 # Generating the message 

29 $TEXT2WAVE ‐o $SOUNDFILE ‐f 8000

Netzwerk 

IPv6-Migration 

© Don Garcia, 123RF 

IPv6-Tunneltechnologien 

Rausgegraben 

Nachdem IPv6 nun das offizielle Internet-Protokoll ist, bleibt nur noch die 

Kleinigkeit, alle Rechner im Internet umzustellen. Bis das passiert, verschaffen 

Tunneltechnologien eine Übergangslösung. Eric Amberg 

Die Migration auf IPv6 nimmt Fahrt auf. 

Im Herbst 2012 ließ die Deutsche Telekom 

verlauten, dass DSL-Neukunden jetzt mit 

Dualstack-Anschlüssen (IPv4+IPv6) angebunden 

werden. Auch andere Provider 

werden in den nächsten Monaten nachziehen. 

In vielen größeren Unternehmen 

ist die Umstellung jedoch keine Sache 

von wenigen Tagen, sondern von Jahren. 

Bereits im Design berücksichtigten die 

IPv6-Entwickler, dass die Einführung von 

IPv6 in vorhandene IPv4-Netzwerke eine 

zum Teil lange Übergangszeit erfordert, 

in der beide Technologien nebeneinander 

existieren werden. Dieser Artikel erläutert 

die verschiedenen Tunneltechnologien 

von IPv6. 

In der Übergangsphase muss sichergestellt 

sein, dass IPv6-Systeme sowohl untereinander 

als auch mit IPv4-Systemen 

kommunizieren können. Der Begriff 

„Knoten“ beschreibt in der IETF-Terminologie 

ein aktives System im Netzwerk, 

das über IPv4 oder IPv6 kommuniziert. 

Dies umfasst neben normalen Workstations 

und Servern unter anderem auch 

Router. Der RFC 4213 (Transition Mechanisms 

for IPv6 Hosts and Routers) 

beschreibt folgende Knoten-Typen: 

n IPv4-Only-Knoten: Auf dem System 

läuft ausschließlich IPv4. 

n IPv6-Only-Knoten: Auf dem System 

läuft ausschließlich IPv6. 

n IPv6/IPv4-Knoten: Auf dem System 

laufen beide IP-Stacks parallel. 

n IPv4-Knoten: Das System kommuniziert 

mit IPv4. Dies kann entweder 

ein IPv4-Only-Knoten oder ein IPv6/ 

IPv4-Knoten sein. 

n IPv6-Knoten: Das System kommuniziert 

mit IPv6. Dies kann entweder 

ein IPv6-Only-Knoten oder ein IPv6/ 

IPv4-Knoten sein. 

Im Folgenden geht es um die Frage, wie 

man IPv6 schrittweise und parallel zu 

IPv4 einführen kann. Die Herausforderung 

dabei besteht in der Überbrückung 

und Zusammenführung der beiden Welten. 

Hierzu gibt es grundsätzlich die folgenden 

Ansätze: 

n Dual-Stack: Auf den Systemen im 

Netzwerk laufen sowohl IPv4 als auch 

IPv6. 

n Tunnelmechanismen: In der Regel geht 

es hierbei darum, IPv6-Kommunikation 

durch IPv4-Bereiche zu tunneln. 

Hier werden IPv6-Inseln miteinander 

verbunden. 

n Translationsmechanismen: Analog 

zum NAT-Prinzip kommunizieren 

IPv4-Systeme über entsprechende 

Mechanismen mit IPv6-Systemen und 

umgekehrt. 

Während Dual-Stack-Implementationen 

die bevorzugte Wahl bei der parallelen 

Einführung von IPv6 in ein vorhandenes 

IPv4-Netzwerk darstellen, bieten Translationstechnologien 

einen Übergang von 

einem IP-Stack in den anderen. Jedoch 

sind nur Tunneltechnologien in der Lage, 

IPv6-Knoten über IPv4-Only-Infrastrukturen 

so miteinander zu verbinden, dass 

sie direkt über IPv6 miteinander kommunizieren 

können. 

Tunnel graben 

IPv6 wird in vielen Netzwerken schrittweise 

und nicht sofort flächendeckend 

eingeführt. Ein typisches Szenario in der 

Übergangszeit ist also die Kommunikation 

von IPv6-Knoten, die über ein IPv4- 

Netzwerk miteinander kommunizieren. 

Somit muss die IPv6-Kommunikation 

über IPv4 transportiert werden, also IPv6 

in IPv4 getunnelt. Das bedeutet, dass 

das IPv6-Datenpaket in einen IPv4-Header 

eingekapselt wird. Der IPv6-Knoten 

selbst oder ein Gateway verpackt das 

IPv6-Paket in IPv4 und schickt es auf 

den Weg. Dabei setzt er das Protocol-Feld 

des IPv4-Headers auf den Wert 41. Dies 



Netzwerk 

steht laut Standard für „IPv6 

in IPv4“ (Abbildung 1). 

Der IPv6-Header enthält die 

IPv6-Adressen der Ende-zu- 

Ende-Kommunikation, also 

der kommunizierenden Endpunkte. 

Der IPv4-Header enthält 

die Quell- und Zieladresse 

der Endpunkte innerhalb des 

IPv4-Netzwerks. Diese Endpunkte 

können bei bestimmten Tunnelmechanismen 

den „echten“ Endpunkten 

der IPv6-Kommunikation entsprechen. 

Meistens wird die Einkapselung jedoch 

durch Tunnel-Gateways vorgenommen. 

Dies sind regelmäßig die Border-Router 

beziehungsweise Firewalls an den Grenzen 

des lokalen Netzwerks. 

Aus Sicht eines IPv6-Pakets ist die IPv4- 

Einkapselung nichts anderes als eine gewöhnliche 

Verkapselung auf Link-Layer- 

Ebene, analog zu Ethernet. In solchen 

Tunnelszenarien kann demnach auf IPv6- 

Ebene eine komplett andere Netzstruktur 

vorhanden sein als auf IPv4-Ebene. Somit 

kann zum Beispiel eine ganze IPv4-Infrastruktur, 

bestehend aus vielen Routern 

und Netz-Segmenten, aus IPv6-Sicht in 

einem „Hop“ zwischen Quelle und Ziel 

übersprungen werden. 

Der Vorteil von Tunnellösungen liegt in 

der Flexibilität, einzelne IPv6-Inseln im 

„IPv4-Meer“ zu verbinden. Dennoch sind 

Tunneltechnologien gegenüber nativer 

IPv6-Kommunikation immer nur zweite 

Wahl, da sie zum einen teilweise komplex 

zu konfigurieren und zum anderen 

fehleranfällig sind. So gilt der Tunnelmechanismus 

Teredo als nur bedingt nutzbar, 

da er in der überwiegenden Anzahl 

aller Fälle nicht korrekt funktioniert [1]. 

Ähnlich wie VPN-Tunnel lassen sich IPv6- 

Tunnel zwischen verschiedenen Punkten 

erstellen. RFC 4213 sieht folgende Tunnelkonfigurationen 

vor: 

n Router-to-Router 

n Host-to-Router und Router-to-Host 

n Host-to-Host 

Dabei verbinden Router-to-Router-Tunnel 

IPv6-Infrastrukturen über einen einzige 

virtuellen Hop über eine IPv4-Only-Infrastruktur 

miteinander. Dies ist der einfachste 

und häufigste Fall eines Tunnels, 

da die Tunnelkonfiguration nur auf einem 

oder wenigen Systemen des Netzwerks 

stattfinden muss und die IPv6-Knoten davon 

nichts wissen müssen. Ein typisches 

Abbildung 1: IPv6 in IPv4 gekapselt: Das IPv6-Paket wird in ein IPv4-Paket 

gepackt und wie normale Nutzdaten verschickt. 

Beispiel für Router-to-Router-Tunnel ist 

ein 6to4-Tunnel. In vielen Fällen verbindet 

der Tunnel zwei entsprechende 

Router über das IPv4-Internet, um IPv6- 

Netzwerke standortübergreifend zu verbinden 

(Abbildung 2). 

Der Host-to-Router-Tunnel verbindet 

einen IPv6/IPv4-Knoten in einem IPv4- 

Only-Netzwerk mit einem IPv6/IPv4- 

Router (Abbildung 3). Hierzu nutzt der 

Host ein Tunnel-Interface und entsprechende 

Routing-Einträge (zum Beispiel 

in Form des Standard-Gateways), die den 

entsprechenden Traffic zum Tunnel-Interface 

routen. Das Tunnel-Interface verpackt 

die IPv6-Pakete in IPv4-Pakete und 

sendet sie zum IPv6/IPv4-Router, der die 

IPv6-Pakete zum IPv6-Ziel weiterleitet. 

Der Weg zurück (Router-to-Host) funktioniert 

analog. ISATAP ist eine Tunneltechnologie, 

die nach diesem Prinzip arbeitet. 

Dieser Tunnel-Typ dient vorwiegend der 

Verbindung von IPv6-Knoten innerhalb 

eines Netzwerks einer Organisation. 

Ein Host-to-Host-Tunnel verbindet die 

kommunizierenden Endpunkte direkt 

miteinander über einen IPv4-Tunnel. 

Erst am Endpunkt der Kommunikation 

wird das gekapselte IPv6-Paket wieder 

entpackt. Dieses Prinzip kommt ebenfalls 

bei der ISATAP-Tunneltechnologie zum 

Einsatz und dient der Kommunikation 

zwischen zwei IPv6-Knoten 

innerhalb eines IPv4-Unternehmensnetzwerks. 

Tunnel-Typen 

Es gibt grundsätzlich zwei 

verschiedene Arten von IPv6- 

Tunnels: konfigurierte Tunnel 

und automatische Tunnel. Bei 

konfigurierten Tunneln muss der Administrator 

die Tunnel manuell auf den jeweiligen 

Tunnel-Endpunkten einrichten. 

Hierbei wird die IPv4-Zieladresse des 

Remote-Endpunkts nicht in der IPv6- 

Adresse eingebettet, wie das bei automatischen 

Tunneln in der Regel der Fall 

ist. Konfigurierte Tunnel nutzen manuell 

erstellte Tunnel-Interfaces, die eine feste 

Quell- und Zieladresse definieren. 

Bei automatischen Tunneln ist keine manuelle 

Konfiguration erforderlich. Die 

Tunnel werden dynamisch bei Bedarf aufgebaut, 

die IPv4-Zieladressen sind meistens 

in der IPv6-Adresse eingebettet. Es 

gibt verschiedene Tunneltechnologien: 

n 6to4: wird für die Verbindung zwischen 

IPv6-Knoten über das IPv4-Internet 

verwendet. 

n 6rd: eine Weiterentwicklung von 6to4 

ohne die Einschränkung der fest definierten 

6to4-Präfixe. 

n ISATAP: für die Verbindung zwischen 

IPv6-Knoten in einem IPv4-Intranet. 

n Teredo: Ermöglicht die Verbindung 

von IPv6-Knoten über NAT. 

6to4 – fürs Internet 

6to4 kann als Router-to-Router-, Hostto-Router- 

und Router-to-Host-Tunnel 

dienen [2]. In der Regel baut man den 

Abbildung 2: Router-zu-Router-Tunnel verbinden zum Beispiel zwei IPv6-fähige Standorte. 

Abbildung 3: Ein Host-zu-Router-Tunnel bindet einen IPv6-fähigen Rechner über ein IPv4 an einen IPv6- 

Router an, etwa im Firmennetz. 


Admin 


29

Netzwerk 


Abbildung 4: Ein 6to4-Tunnel kann als Router-to-Router-, Host-to-Router- und 

Router-to-Host-Tunnel dienen. 

Tunnel jedoch als Router-to- 

Router-Konfiguration auf. 

Dabei behandelt 6to4 das gesamte 

IPv4-Internet als einen 

einzigen Link. Das Präfix von 

6to4 lautet 2002::/16, beginnt 

also immer mit 2002. Daran 

ist eine 6to4-Tunneladresse zu erkennen. 

Die nächsten 32 Bit der Adresse enthalten 

die hexadezimale IPv4-Adresse des Remote-Endpunkts 

des Tunnels, also in der 

Regel ein 6to4-Router beziehungsweise 

6to4-Relay im Internet. Dann folgen die 

16 Bit lange Subnet-ID und die Interface- 

ID des Zielsystems (Abbildung 4). 

Windows-Systemen ab Windows Vista 

erstellen automatisch ein 6to4-Tunnelinterface, 

wenn das System auf einer 

seiner Schnittstellen eine öffentliche 

IPv4-Adresse verwendet und keine andere 

IPv6-Konnektivität (nativ oder über 

ISATAP) feststellt. In diesem Fall erhält 

das 6to4-Tunnelinterface die IPv6-Adresse 

2002:WWXX:YYZZ::WWXX:YYZZ, 

wobei WWXXYYZZ für die öffentliche 

IPv4-Adresse steht. Ist die öffentliche 

IPv4-Adresse eines Windows Server 

2012-Computers also zum Beispiel 

131.107.1.1, so lautet die 6to4-Tunneladresse 

2002:836B:101::836B:101. 

6to4 nutzt einige Komponenten, die unterschiedliche 

Aufgaben übernehmen: 

n 6to4-Host: ein nativer IPv6-Host, der 

mindestens eine 6to4-Adresse besitzt 

(Präfix 2002::/16), über die er erreichbar 

ist. Er hat jedoch kein 6to4-Tunnel-Interface, 

da er nicht über IPv4 

kommuniziert. Er ist der Endpunkt 

einer IPv6-Kommunikation, die über 

einen 6to4-Tunnel geleitet wird. 

n 6to4-Router: ein IPv6/IPv4-Router, der 

ein 6to4-Tunnel-Interface hat, über das 

er Traffic zwischen 6to4-Hosts zu einem 

anderen 6to4-Router, 6to4-Relay 

oder 6to4-Host weiterleitet. 6to4-Router 

müssen entsprechend konfiguriert 

werden – egal auf welcher Plattform. 

n 6to4-Host/Router: ein IPv6/IPv4-Host, 

der direkt ans Internet angeschlossen 

ist. Im Gegensatz zum 6to4-Router 

leitet er nur seinen eigenen Traffic 

über 6to4 zu anderen IPv6-Knoten 

weiter, nicht aber den Traffic anderer 

Systeme. 

n 6to4-Relay: im Gegensatz zu 6to4-Routern 

leitet ein 6to4-Relay den Traffic 

direkt in das IPv6-Internet. Das bedeutet, 

dass ein 6to4-Relay über BGP an 

das Internet angeschlossen sein muss, 

während 6to4-Router ein bestimmtes 

IPv6-Unternehmensnetzwerk verbinden. 

So funktioniert 6to4 

Jede 6to4-Site besitzt ein eigenes 6to4- 

Präfix (2002:WWXX:YYZZ::/48). Der 

Rest der 6to4-Adresse definiert das Subnetz 

und die Interface-ID des Hosts in der 

Site. Aus Sicht eines 6to4-Host/Routers 

besteht die gesamte 6to4-Site aus einem 

einzigen Computer: ihm selbst. Für einen 

6to4-Router kann die 6to4-Site aus bis 

zu 65 536 Subnetzen bestehen. In jedem 

Fall sieht er sämtliche Subnetze der Site. 

Eine 6to4-Site kann andererseits aus einer 

einzigen IPv4-Adresse bestehen, über die 

die Site erreichbar ist. Der 6to4-Router 

propagiert in seinen Router Advertisements 

das 6to4-Präfix an die internen 

Knoten, sodass 6to4 auch problemlos mit 

Autoconfiguration funktioniert. 

Der Trick ist nun, dass die IPv4-Adresse 

der Site des Zielhosts in der 6to4-Zieladresse 

enthalten ist. Die beteiligten Systeme 

extrahieren diese Adresse und nutzen 

sie, um den IPv4-Teil der Wegstrecke 

zu überbrücken. Im Beispielszenario von 

Abbildung 5: WKS1 möchte mit WKS2 

Abbildung 5: Ein Beispiel-Szenario für den Einsatz von 6to4. 

kommunizieren und löst den 

FQDN (Fully Qualified Domain 

Name) von WKS2 auf. 

Der DNS-Server liefert die 

Adresse 2002:9D3C:101:F::1 

zurück. Aus dem Präfix entnimmt 

WKS1 zunächst, dass 

es sich hierbei um eine 6to4-Adresse 

handelt. Da er als 6to4-Host/Router mit 

einer öffentlichen IPv4-Adresse selbst in 

der Lage ist, das IPv6-Paket in IPv4 zu 

tunneln, identifiziert er durch die Bits 

17 bis 48 des Präfixes die IPv4-Adresse 

des 6to4-Routers als 157.60.1.1. Das getunnelte 

Paket wird nun an den 6to4- 

Router gesendet, der das Paket wieder 

entpackt und entsprechend nach intern 

weiterleitet. Da WKS1 seinerseits als Absenderadresse 

seine 6to4-Tunneladresse 

2002:836B:101::836B:101 verwendet hat, 

kann der 6to4-Router das Antwortpaket 

von WKS2 an die korrekte IPv4-Adresse 

131.107.1.1 zustellen, die er dem Präfix 

von WKS1 entnimmt. 

Suche Relay 

Sollen native IPv6-Adressen im IPv6-Internet 

angesprochen werden, sucht der 

6to4-Router beziehungsweise 6to4-Host 

ein nahes 6to4-Relay. Hierfür existiert die 

IPv4-Anycast-Adresse 192.88.99.1. IPv6- 

Pakete an native IPv6-Adressen werden 

also von 6to4-aktivierten Knoten ebenfalls 

eingekapselt, wobei die Zieladresse 

des IPv4-Headers 192.88.99.1 ist. Diese 

Pakete landen beim nächstgelegenen 

6to4-Relay und werden gemäß normaler 

IPv6-Routing-Mechanismen zugestellt. 



Netzwerk 

Die Rückantwort des IPv6-Only-Knotens 

wird ebenfalls über ein 6to4-Relay geroutet, 

wobei dies nicht zwangsläufig dasselbe 

sein muss wie auf dem Hinweg. 

Dies kann in der Praxis zu den typischen, 

durch asymmetrisches Routing verursachten 

Problemen führen, zum Beispiel 

bei Stateful-Firewalls, die Antwortpakete 

nicht zuordnen können. In diesem Zusammenhang 

muss auch sichergestellt 

sein, dass die Knoten im IPv6-Internet 

eine Route zu einem 6to4-Relay kennen 

– dies ist jedoch derzeit nicht immer der 

Fall. Daneben hat 6to4 den Nachteil, dass 

NAT nur dann unterstützt wird, wenn 

der 6to4-Router beziehungsweise das 

6to4-Relay gleichzeitig das NAT-Device 

ist. 6to4 wird von den meisten gängigen 

Betriebssystem-Plattformen unterstützt. 

6rd – die Evolution 

Die Tunneltechnologie 6rd [3] basiert auf 

6to4 und wurde von Rémi Després entworfen. 

6rd und 2007 vom französischen 

Provider FREE in wenigen Monaten eingeführt. 

Die Buchstaben „RD“ stehen einerseits 

für Rapid Deployment und andererseits 

für die Initialen des Entwicklers. 

Im Gegensatz zu 6to4 arbeitet 6rd mit den 

Präfixen der Endkunden, statt ein eigenes 

Präfix zu nutzen. Dies vereinfacht die 

Einführung deutlich. Nachdem zunächst 

ein von Després selbst geschriebener 

Informational-RFC veröffentlicht wurde, 

bereitet die IETF die Standardisierung 

nun im Standard-RFC 5969 vor. 

Im Gegensatz zu 6to4 wandern die Daten 

für die Kommunikation zwischen in- 

Ein Windows-System erstellt für jedes 

LAN-Interface, das ein eigenes DNS-Suffix 

erhält (und damit in einem eigenen 

Subnetz ist), ein separates ISATAP-Tunternen 

IPv6-Only-Knoten und externen 

IPv6-Only-Knoten, die über das IPv4- 

Internet verbunden sind, über Providereigene 

6rd-Relays. Der Provider behält 

die vollständige Kontrolle über die IPv6- 

Kommunikation, die über ihn läuft und 

kann daher auch seine eigenen Präfixe 

nutzen. Da auch hier die öffentliche 

IPv4-Adresse des 6rd-Relays kommuniziert 

werden muss, ist sie ebenfalls in die 

IPv6-Adresse integriert. 

Eine Besonderheit bei 6rd ist allerdings, 

dass das einem Provider zugewiesene 

Präfix flexibel ist und somit bei längeren 

Präfixen nicht mehr genügend Bits in 

der IPv6-Adresse zur Verfügung stehen. 

Erhält der Provider ein Standard-Präfix 

(/32) von der Regional Internet Registry 

(RIR), so kann er zwar die IPv4-Adresse 

in den folgenden 32 Bits unterbringen, 

dem Kunden aber dann nur noch ein 

einzelnes Subnetz zur Verfügung stellen, 

da die hinteren 64 Bits der IPv6-Adresse 

für die Interface-ID reserviert sind. 

Im Fall von FREE erhielt der Provider 

später ein /26-Präfix. Die Adresse wurde 

so aufgeteilt, dass nach dem Präfix die 

IPv4-Adresse hexadezimal eingebettet 

ist, dann zwei reservierte Bits folgen 

und schließlich die 4 Bit lange Subnet- 

ID. Eine andere Variante, um bei längeren 

Provider-Präfixen festgelegte Bits zu 

sparen, besteht darin, redundante Teile 

der IPv4-Adresse auszulassen. Nutzt ein 

Provider für seine Kunden zum Beispiel 

immer ein bestimmtes /18-Subnetz, kann 

er die vorderen 18 Bits der IPv4-Adresse 

weglassen, ohne relevante Informationen 

zu verlieren. 6rd ist ein interessanter An- 

satz mit dem Potenzial, das alte 6to4 

mittelfristig weitgehend abzulösen. 

ISATAP – fürs Intranet 

Das Intra-Site Automatic Tunnel Addressing 

Protocol (ISATAP) kommt bei Hostto-Host-, 

Host-to-Router- und Router-to- 

Host-Verbindungen zum Einsatz. Router-to-Router-Verbindungen 

sind nicht 

vorgesehen. ISATAP wird genutzt, um 

in einem Organisationsnetzwerk IPv6/ 

IPv4-Knoten über eine IPv4-Infrastruktur 

miteinander zu verbinden. Es ist nicht für 

die Verbindung über das Internet konzipiert. 

ISATAP sollte nicht in produktiven 

Netzwerken eingesetzt werden sollte, 

weil es in erster Linie Testzwecken dient 


ISATAP ist in RFC 5214 festgelegt und 

erfordert auf den Hosts keine manuelle 

Konfiguration. Es wurde von Cisco und 

Microsoft entwickelt, wird aber auch von 

Linux unterstützt [4]. Wie auch 6to4 

nutzt ISATAP ein virtuelles Tunnel-Interface, 

das automatisch angelegt und mit 

einer IPv6-Adresse versehen wird. Dabei 

kann ein beliebiges Unicast-/64-Präfix 

genutzt werden (also auch Link-Local). 

Die IPv4-Adresse des jeweiligen LAN- 

Interfaces wird am Ende der Interface-ID 

eingebunden. Je nachdem, ob es sich 

um eine globale IPv4-Adresse oder eine 

private IPv4-Adresse nach RFC 1918 

handelt, haben ISATAP-Adressen das folgende 

Format: 

n Globale IPv4-Adressen: 64-Bit-Unicast- 

Präfix:200:5EFE:w.x.y.z 

n Private IPv4-Adressen: 64-Bit-Unicast- 

Präfix:0:5EFE:w.x.y.z 

Hierbei steht w.x.y.z für eine IPv4-Adresse 

in normaler Punktnotation. Eine 

mögliche ISATAP-Adresse wäre dann zum 

Beispiel 2001:db8:200:5EFE:85.25.66.51. 

Das ISATAP-Tunneling-Interface betrachtet 

den IPv4-Teil des Netzwerks übrigens 

als ein einziges Link-Layer-Segment, analog 

zu Ethernet. Die Link-Layer-Verkapselung 

geschieht demnach aus Sicht von 

ISATAP durch IPv4. 

So funktioniert ISATAP 

Abbildung 6: Bei 6rd wandern die Daten für die Kommunikation zwischen internen IPv6-Only-Knoten über 

Provider-eigene 6rd-Relays. 


Admin 


31

Netzwerk 


neling-Interface. Diese ISATAP-Interfaces 

befinden sich ab Vista SP1 zunächst im 

Status „Disconnected“, solange der Name 

ISATAP nicht aufgelöst werden kann. Hinter 

diesem DNS-Namen verbirgt sich die 

IPv4-Adresse eines ISATAP-Routers. Kann 

der Name „ISATAP“ aufgelöst werden, 

geschieht Folgendes: 

n Die ISATAP-Interfaces weisen 

sich eine Link-local-Adresse zu: 

FE80::5EFE:w.x.y.z beziehungsweise 

FE80::200:5EFE:w.x.y.z. 

n Die ISATAP-Hosts senden über das 

ISATAP-Tunneling-Interface per IPv4 

eine Router-Solicitation-Nachricht unicast 

an die IPv4-Adresse des ISATAP- 

Routers 

n Der ISATAP-Router antwortet mit einer 

IPv4-Router-Advertisement-Nachricht 

unicast an die IPv4-Adresse des ISA- 

TAP-Hosts, in der er sich selbst als 

Standardgateway ankündigt und das 

Präfix für das ISATAP-Subnetz propagiert. 

Dies kann ein Global-Unicastoder 

ein Unique-Local-Präfix sein. 

Die Kommunikation mit dem Router 

geschieht per IPv4-Unicast, da der normale 

Weg per IPv6-Multicast nicht zur 

Verfügung steht, um Router Solicitationund 

Router-Advertisement-Nachrichten 

auszutauschen. IPv4 Multicast kann hier 

nicht verwendet werden, da dies eine 

subnetzübergreifende IPv4-Multicast- 

Infrastruktur erfordern würde. 

Der ISATAP-Router ist in einem ISATAP- 

Netzwerk zur initialen Aktivierung der 

ISATAP-Tunneling-Interfaces nötig. Er 

muss aber nicht unbedingt Präfixe zuweisen, 

da in einem lokalen ISATAP- 

Segment die ISATAP-Hosts untereinander 

über ihre Link-Local-Adressen kommunizieren 

können. Der ISATAP-Router kann 

darüber hinaus jedoch ISATAP-Hosts mit 

dem nativen IPv6-Teil des Unternehmens- 

Netzwerks verbinden. Dazu ist allerdings 

ein Global-Unicast- oder Unique-Local- 

Präfix nötig, das über die Router Advertisements 

zugewiesen werden muss. In 

diesem Fall können die ISATAP-Hosts 

über die per Autoconfiguration gebildeten 

Adressen auch mit IPv6-Knoten außerhalb 

des eigenen ISATAP-Subnetzes 

kommunizieren, in dem sie den ISATAP- 

Router als Standardgateway verwenden. 

Im Gegensatz zu den ISATAP-Hosts muss 

der ISATAP-Router entsprechend manuell 

konfiguriert werden. 

Abbildung 7: Das ISATAP-Protokoll konfiguriert Rechner automatisch. Der Einsatz ist jedoch aufs Intranet 

beschränkt und dient vorwiegend Testzwecken. 

ISATAP hat unter Windows den Vorteil, 

schnell implementiert werden zu können. 

Der Nachteil besteht darin, dass die 

Kommunikation auf das Unternehmensnetzwerk 

beschränkt ist und nicht für die 

Kommunikation mit Systemen im Internet 

ausgelegt ist. Weiterhin ist ISATAP in 

vielen NAT-Szenarien nicht nutzbar. 

Teredo 

6to4 bietet IPv6-Tunnel über das IPv4- 

Internet, hat jedoch den Nachteil, dass 

die 6to4-Router immer eine offizielle 

IPv4-Adresse benötigen. Liegen sie hinter 

einem NAT-Device, funktioniert 6to4 

nicht. Hier setzt Teredo an. Dabei handelt 

es sich um eine Tunneltechnologie, die 

von Mircosoft entwickelt wurde und insbesondere 

dort zum Einsatz kommt. Es 

gibt jedoch auch eine Implementation für 

Linux [5]. Der Name leitet sich übrigens 

von „Teredo navalis“ ab und ist die Bezeichnung 

für einen Schiffsbohrwurm. 

Teredo ist in den RFCs 4380 und 5991 

definiert und bietet IPv6-Tunnel für IPv6- 

Knoten an, die sich hinter NAT-Devices 

befinden, die keine 6to4-Router sind. 

Dazu tunnelt Teredo die IPv6-Pakete 

nicht nur in IPv4, sondern zusätzlich in 

UDP. Das bedeutet, dass das originale 

IPv6-Paket als Payload von UDP transportiert 

wird. Dies erhöht die Chance, durch 

NAT-Devices hindurchzukommen. Dabei 

kann das getunnelte Paket grundsätzlich 

auch problemlos mehrere NAT-Stufen 

durchqueren. 

Dabei spielen die NAT-Typen eine wichtige 

Rolle. Nach RFC 3489 wird unterschieden 

in: 

n Cone-NAT: Es existiert eine 1-zu-1- 

Zuordnung zwischen internen und 

externen Adressen, die dementsprechend 

auch von extern angesprochen 

werden können. 

n Restricted-NAT: Die Kontaktaufnahme 

von außen kann nur dann geschehen, 

wenn von innen bereits eine Verbindung 

zuvor aufgebaut wurde. 

n Symmetric-NAT: Die interne Adresse 

kann verschiedenen externen Adressen 

zugewiesen werden und ist daher 

von außen nicht eindeutig identifizierbar. 

In der Praxis ist diese Unterscheidung jedoch 

nur ein Anhaltspunkt, da viele NAT- 

Router Mischformen verwenden. Teredo 

funktioniert grundsätzlich mit Cone-NAT 

und Restricted-NAT. Teredo definert die 

folgenden Komponenten: 

n Teredo-Clients: Dies sind IPv6/IPv4- 

Knoten, die Teredo-Tunneling-Interfaces 

unterstützen (ab Windows XP 

SP1). 

n Teredo-Server: IPv6/IPv4-Knoten, die 

sowohl an das IPv4- als auch an das 

IPv6-Internet angeschlossen sind. Sie 

weisen Teredo-Präfixe zu und unterstützen 

die Teredo-Clients bei der 

Kontaktaufnahme zu anderen Teredo- 

Clients oder IPv6-Only-Knoten. Teredo-Server 

lauschen per Default auf 

Port 3544/udp. 

n Teredo-Relays: IPv6/IPv4-Router, die 

Pakete von Teredo-Clients aus dem 

IPv4-Internet in das IPv6-Internet 

weiterleiten. Sie arbeiten teilweise mit 

Teredo-Servern zusammen. 

n Host-spezifisches Teredo-Relay: Dieses 

Relay ist ebenfalls im IPv6- und 



Netzwerk 

IPv4-Internet angeschlossen. Ist ein 

IPv6-Knoten auch IPv4-fähig, kann er 

über ein Host-spezifisches Teredo-Relay 

direkt über IPv4 mit dem Teredo- 

Client kommunizieren. In diesem Fall 

ist kein Teredo-Relay notwendig und 

damit keine Kommunikation über das 

IPv6-Internet. 

Die Teredo-Adresse besteht aus einem 

32-Bit-Präfix (2001::/32), gefolgt von der 

hexadezimalen IPv4-Adresse des Teredo- 

Servers. Die hinteren 64-Bits teilen sich 

in drei Bestandteile auf. Die Flags (16 

Bits) definieren insbesondere die Art des 

NAT. Der chiffrierte externe Port (16 Bits) 

gibt den Port an, über den der interne 

Teredo-Client durch das NAT-Device von 

außen erreichbar ist. Diesen bestimmt 

der Teredo-Server durch die Analyse des 

Source-Ports der Pakete, die vom Client 

bei ihm ankommen und nennt ihn dem 

Client im Antwortpaket. Da einige NAT- 

Geräte versuchen, eine im Payload enthaltende 

Port-Angabe auf die interne 

Portnummer zu übersetzen, wird dieser 

Wert mit XOR verschlüsselt. Die letzten 

32 Bits enthalten die chiffrierte externe 

IPv4-Adresse, über die der Client 

erreichbar ist. 

IPv6-Blase 

Teredo-Adressen dieser Art werden ausschließlich 

den Teredo-Clients zugewiesen. 

Teredo-Server und ‐Relays erhalten 

nur native IPv4- beziehungsweise IPv6- 

Adressen. Die Kommunikation wird nun 

von den Teredo-Clients über die Teredo- 

Server initiiert, die den Teredo-Clients 

mitteilen, über welche offiziellen IP- 

Adressen und Ports sie zu sehen sind. 

Mit diesen Informationen macht Teredo 

sich die NAT-Session-Einträge zunutze, 

um die internen Systeme auch von außen 

ansprechen zu können. 

Um die NAT-Verbindungen aufrechtzuerhalten, 

senden Teredo-Clients in regelmäßigen 

Abständen sogenannte Bubble-Pakete 

an den Teredo-Server. Dabei handelt 

es sich um „leere“ IPv6-Pakete, die in 

einem IPv4-UDP-Paket eingekapselt sind. 

Möchten zwei Teredo-Clients am selben 

Link miteinander kommunizieren, so 

nutzen sie Bubble-Pakete als Ersatz für 

den Neighbor Discovery-Prozess, um die 

Kommunikation zu initiieren. Möchte ein 

Teredo-Client mit einem anderen Teredo- 

Client einer Remote-Site sprechen, hängt 

die Kommunikation vom NAT-Typ ab. 

Befinden sich beide Knoten hinter einem 

Cone-NAT, können die Systeme 

direkt miteinander in Verbindung treten, 

da die Verbindungsaufnahme nach 

der Definition von Cone-NAT von jeder 

Source-IP-Adresse aus möglich ist. 

Befinden sich die Knoten jedoch hinter 

Routern, die Restricted-NAT verwenden, 

so werden zunächst Bubble-Pakete zu 

den Remote-Sites und zum Teredo-Server 

gesendet, der die Verbindung initiiert. Die 

eigentliche Kommunikation geht nach 

der initialen Öffnung der Verbindung direkt 

zwischen den beiden Kommunikationspartnern, 

der Teredo-Server hilft hier 

nur beim Verbindungsaufbau. 

Im Falle der Verbindung eines Teredo- 

Clients mit einem nativen IPv6-Knoten 

im IPv6-Internet dient der Teredo-Server 

jedoch auch als Router in das IPv6-Internet. 

Verbindungen, die vom IPv6-Internet 

zu einem Teredo-Client aufgebaut werden 

sollen, werden mithilfe des nächstgelegenen 

Teredo-Relays beziehungsweise 

Host-spezifischen Relays realisiert. 

Durch diese komplexen Mechanismen ist 

Teredo zum einen sehr langsam beim 

Verbindungsaufbau (unter anderem wegen 

Timeouts) und zum anderen unzuverlässig, 

weil die Verbindungen nur unter 

bestimmten Bedingungen überhaupt 

aufgebaut werden können. Für einen 

produktiven Einsatz ist Teredo derzeit 

eher nicht geeignet. 

Fazit und Ausblick 

Wer die Wahl hat, sollten immer native 

IPv6-Verbindungen verwenden. Leider ist 

das aber bisher in den seltensten Fällen 

möglich. Daher sind IPv6-Tunnel der- 

Abbildung 8: Eine Teredo-Adresse kodiert neben dem Teredo-Server die NAT-Flags, den Port und die externe 

Adresse. Der Verbindungsaufbau dauert aber seine Zeit. 

zeit oft die einzige Möglichkeit, IPv6- 

Systeme miteinander zu verbinden. Je 

nach Anwendungsgebiet gibt es hierfür 

verschiedene, in diesem Artikel vorgestellte 

Tunnel-Technologien, von denen 

jede ihre Vor- und Nachteile besitzt. 

Grundsätzlich ist jedoch kein einziger 

Tunnelmechanismus dafür ausgelegt, auf 

Dauer zu bestehen – letztlich sollen alle 

Tunnel irgendwann durch native IPv6- 

Verbindungen ersetzt werden. Dies sollte 

man auch bei der Planung der Migration 

berücksichtigen. Denn der Abbau eines 

etablierter Tunnelmechanismus bedeutet 

in einigen Jahren unter Umständen zusätzlichen 

Aufwand. 

Neben den hier vorgestellten Technologien 

existieren zusätzlich sogenannte 

Tunnelbroker (wie zum Beispiel SixXS), 

die für Enduser die Möglichkeit schaffen, 

über verschiedene, teils proprietäre 

Technologien inklusive Tunnel-Client- 

Software, aus dem internen Netz IPv6- 

Systeme im Internet ansprechen zu 

können. Doch auch diese Lösungen 

sind letztlich Provisorien, die den Zeitraum 

bis zur Bereitstellung nativer IPv6- 

Anbindungen überbrücken sollen. Die 

Erfahrung zeigt aber: Manchmal sind 

Provisorien die besten Dauerlösungen 

(ofr) 

n 

Infos 

[1] Untersuchung der Effektivität von Teredo: 

[http:// www. sigcomm. org/ sites/ 

default/ files/ ccr/ papers/ 2012/ October/ 

2378956‐2378959. pdf] 

[2] 6to4 siehe RFC 3056 (Connection of IPv6 

Domains via IPv4 Clouds) 

[3] 6rd für Linux: [http:// www. litech. org/ 6rd/] 

[4] ISATAP für Linux: [http:// www. 

saschahlusiak. de/ linux/ isatap. htm] 

[5] Teredo für Linux: 

[http:// www. remlab. net/ miredo/] 

Der Autor 

Eric Amberg ist Geschäftsführer der ATRACON 

GmbH ([http:// www. atracon. de]), seit vielen 

Jahren im Bereich IT-Infrastruktur als Trainer 

und Consultant tätig und verfügt über langjährige 

Projekterfahrung. Sein 

besonderer Fokus liegt auf 

Netzwerk-Themen. In seinen 

Seminaren legt er großen 

Wert auf eine praxisnahe 

Schulung. 


Admin 


33

Enterprise-Linux 

Enterprise-Distributionen 

© Wojciech Kaczkowski, 123RF 

Enterprise-Linux-Distributionen 

Kurs halten 

Red Hat Enterprise Linux dient als Blaupause für Klone wie Oracle Linux oder CentOS. Suse geht dagegen seinen 

eigenen Weg. Wir durchforsten den Angebotsdschungel der Enterprise-Linuxe und beleuchten technische Unterschiede, 

Subskriptionsmodelle und Kosten. Thomas Drilling 

Wer Linux schon seit 1995 verwendet, 

wird sich vielleicht fragen, was das sein 

soll, eine Enterprise-Distribution. Der 

Name rührt daher, dass sich Enterprise- 

Betriebssysteme an den mutmaßlichen 

Anforderungen von Unternehmen orientieren. 

Das sind: Stabilität und möglichst 

lange Produktlebenszyklen, innerhalb 

derer Unternehmen in Abhängigkeit des 

Umfangs der erworbenen Subscription 

Unterstützung in Form von Programm-, 

System- und Sicherheits-Updates, sowie 

Fehlerkorrekturen erhalten. Zudem sind 

viele, ebenfalls „Enterprise-taugliche“ 

Software-Pakete wie etwa Oracle-Datenbanken, 

nur für Enterprise-Linuxe zertifiziert. 

Mit seinem Red Hat Enterprise Linux 

(RHEL, Abbildung 1) ist Red Hat heute 

Weltmarktführer in dieser Sparte. RHEL 

bietet standardmäßig sieben Jahre Unterstützung 

für das jeweils aktuelle Release, 

das sich ab RHEL 6 nach Bedarf auch 

auf 10 Jahre uneingeschränktem Support 

ausdehnen lässt. Die Konkurrenz zieht 

damit aber gleich: Der Support für Suses 

Enterprise Server (SLES) lässt sich auf 

Wunsch ebenfalls auf bis zu 10 Jahre 

ausdehnen. 

E Red Hat 

Red Hat ist aus wirtschaftlicher Sicht 

heute das Vorzeigeunternehmen im Linux-Sektor 

und verbuchte im Geschäftsjahr 

2011/2012 einen Gesamtumsatz von 

1,13 Milliarden US-Dollar. Dass ein großer 

Anteil an Red Hats Einnahmen aus 

dem Subskriptions-Geschäft resultiert, 

zeigt, welchen Stellenwert Red Hat Enterprise 

Linux im eigenen Unternehmen genießt, 

trotz anderer Red-Hat-Produkte im 

Cloud-Sektor, dem Middleware-Bereich 

oder dem Storage-Segment. 

Gelegentlich hilft Red Hat bei der Weiterentwicklung 

neuer Produkte und Technologien 

zuweilen auch mit der Akquisition 

von Unternehmen und Technologien 

nach, etwa bei der JBoss-Middleware 

oder im Bereich Virtualisierung. Zumal 

Red Hat Schlüsseltechnologien wie KVM 

oder Spice nach der Anpassung durch 

eigene Entwickler wieder als freie Software 

veröffentlicht. Darüber hinaus sind 

viele von Red Hat bezahlte Entwickler 

in anderen Open-Source-Projekten aktiv, 

neben dem Fedora-Projekt auch in der 

Linux-Kernel-Entwicklung, namentlich 

bei den KVM-Komponenten. 

In diesem Zusammenhang ist bemerkenswert, 

dass sich Red Hat wiederholt 

in der Top-10-Unternehmensliste der 

Linux Foundation platziert hat, deren 

Entwickler die meisten Commits zum 

Linux-Kernel lieferten. So stammten im 

Jahr 2010 12,4 Prozent der Arbeiten am 

Linux-Kernel von Red-Hat-Entwicklern, 

Platz 2 hinter „unbekannten Beitragenden“. 

Erst im April letzten Jahres ist Red 

Hat (in Deutschland auch Gründungsmitglied 

der Open Source Business Alliance) 

dem Open-Stack-Projekt beigetreten. 




Red Hat stellt sämtliche Quellpakete seiner 

RHEL-Distributionen (Server, Desktop, 

Workstation) gemäß der GPL-Richtlinien 

im Quellcode frei zur Verfügung 

[1], allerdings keine Binärpakete und 

keine Installations-Images. Nach einmaligem 

Registrieren im „Red Hat Customer 

Portal“ darf der Anwender aber eine 

60-Tage-Testversion von RHEL herunterladen. 

Red Hat Enterprise Linux lässt sich 

ausschließlich in Form von Abonnementund 

Support-Verträgen (Subscriptions) 

nutzen. 

Auch als Desktop 

Für den Desktop-Bereich offeriert Red 

Hat die Abonnement-Varianten Workstation 

und Desktop. Die Workstation- 

Version schlägt mit 179 US-Dollar in der 

sogenannten „Self-support-Subscription“ 

und mit 299 US-Dollar pro Jahr in der 

Standard-Subscription zu Buche. Für 

die meisten Unternehmen dürfte eher 

die Server-Version von Interesse sein. 

Die beginnt für x86-(32/64)-Systeme bei 

349 US-Dollar in der 2-Socket-Version 

inklusive Unterstützung für lediglich einen 

virtuellen Gast und endet bei der 

Premium-Subscription für 6498 US-Dollar 

im Jahr für 4-Socket-Systeme und eine 

unbegrenzte Anzahl virtueller Gäste. 

Eine Übersicht aller Varianten liefert die 

zugehörige Seite [2] im Red Hat Store. 

Die Subscriptions sind bei Red Hat übrigens 

nicht versionsspezifisch, sondern 

gelten stets gleichermaßen für alle aktuell 

gepflegten Varianten, derzeit RHEL 5 und 

RHEL 6. 

Installiert der Admin unter RHEL Pakete 

aus auf RPM basierenden Fremdquel- 

Abbildung 1: Red Hat ist unter Herstellern von Linux-Enterprise-Distributionen am längsten im Geschäft. 

len, wie RPM Fusion oder RPM Forge, 

verliert er den Support-Anspruch. Das 

macht aber auch wenig Sinn bei einer 

Enterprise-Distribution, denn deren Wert 

liegt gerade in der auf den angebotenen 

Paketen basierenden Stabilität. Red Hat 

Enterprise Linux verwaltet sämtliche mit 

RHEL gelieferte Pakete, sowie Aktualisierungen 

in sogenannten „Channels“ im 

„Red Hat Network“ (RHN), dem weltweit 

verfügbaren Software-Repository von Red 

Hat Enterprise Linux. 

Nur wer eine Subscription erwirbt, hat 

nach erstmaliger Registrierung Zugriff 

auf das RHN. Die einzelnen Channels 

unterscheiden sich je nach erworbener 

Subskription. Das gilt auch für die Installationsmedien. 

Wer eine Desktop-Subskription 

erwirbt, hat auch nur Zugriff 

auf den zugehörigen Channel. Außerdem 

ist es im Firmennetzwerk jederzeit möglich, 

einen eigenen Satellite-Server für 

RHN aufzusetzen und zu betreiben. Das 

Software-Management selbst basiert auf 

RPM-Raketen, mit Yum als Kommandozeilen-Frontend, 

das sich auch um das 

Auflösen von Abhängigkeiten kümmert. 

Von lizenzrechtlich bedingten und gewollten 

Unterschieden der einzelnen 

RHEL-Versionen, die sich aus der Paketauswahl 

in den Channels ergeben, abgesehen, 

verwendet RHEL einen von den 

Red-Hat-Entwicklern stark modifizierten 

Kernel 2.6.32. Der integriert unter anderem 

die von Red Hat entwickelte Kernel- 

Erweiterung SE Linux. 

Dass Red Hat seit der RHEL-Version 6 bestrebt 

ist, seine Kernel-Patches möglichst 

Redpatch und Ksplice 

Red Hat liefert seit der RHEL-Version 6 Anfang 

2011 seine Änderungen am Linux-Kernel nur 

noch in Form eines einzigen großen kumulierten 

Pakets aus, in dem sämtliche von Red Hat 

vorgenommene Anpassungen vermischt sind. 

Die Strategieänderung soll vermutlich der Konkurrenz 

von Oracle und Novell/Suse die Arbeit 

erschweren. Die müssen seitdem sämtliche Änderungen 

selbst ausfindig machen, denn laut 

Red Hat bieten Unternehmen wie Oracle und 

Novell auch Support für RHEL-Kunden an. Suse 

offeriert etwa auf seinen SLES-Produktseiten 

einen Migrationspfad für RHEL beziehungsweise 

ein Support-Paket, das auch Unterstützung für 

Red-Hat-Produkte einschließt [13]. 

Laut Red-Hat-Chef Brian Stevens könne das 

Unternehmen mit der Änderung solchen Tendenzen 

entgegensteuern und für das Anbieten 

von Support-Leistungen essenzielle Informationen 

verbergen, ohne den Grundgedanken von 

freier Software zu verletzen. Offenbar betraf die 

Änderung aber nicht nur Unternehmen wie Novell, 

sondern auch Projekte wie das von Oracle 

übernommene Ksplice-Projekte. Da Ksplice auf 

das Vorhandensein der einzelnen Patches am 

RHEL-Kernel angewiesen ist, hatten die Ksplice- 

Entwickler laut Oracle schon kurz nach der Bekanntgabe 

von Red Hats Maßnahme ein eigenes 

Respository gestartet, das die Änderungen am 

RHEL-Kernel in Einzelteile zerlegt. 

Seit Kurzem macht Oracle die einzelnen Änderungen 

im Rahmen seines Redpatch-Projekt 

auch allgemein verfügbar und pflegt im dazu 

im eigens aufgesetzten Redpatch-Repository 

[14] den Quellcode des RHEL-Kernel in Form 

eines öffentlich zugänglichen Git-Depots [15], 

das sämtliche von Red Hat vorgenommenen 

Änderungen wieder als einzelne Patches zur 

Verfügung stellt. Ksplice ist eine von Oracle erworbene 

Technologie, die das Anwenden von 

Patches auf den Linux-Kernel ohne Neustart ermöglicht. 

So kann Ksplice beispielsweise viele 

Fehler und Sicherheitslücken zur Laufzeit korrigieren. 

Oracle verkauft Ksplice übrigens auch als 

Service-Dienstleistung an RHEL-Anwender. 


Admin 


37



schwer nachvollziehbar zu machen, sorgt 

übrigens seit einiger Zeit für Unmut in 

der Community und hat Konkurrent 

Oracle veranlasst, die Kernel-Patches von 

RHEL 6 wieder aufzudröseln und in Form 

eines eigenen, öffentlich zugänglichen 

Repositories (Redpatch-Projekt) der Gemeinschaft 

zugänglich zu machen (siehe 

Kasten „Redpatch und Ksplice“). 

RHEL lässt sich ebenso wie Fedora mithilfe 

des grafischen Anaconda-Installers 

installieren, unterstützt via Kickstart aber 

auch ein automatisiertes Deployment. 

Zur Konfiguration stehen neben der Kommandozeile 

eine Auswahl von speziell 

von Red Hat entwickelten Werkzeugen 

zur Verfügung, die allesamt dem Bezeichnungsschema 

»system‐config‐name« folgen 

und nach den für Red Hat und Fedora 

gültigen Prinzipien entwickelt wurden. 

Das bedeutet, dass Management-Werkzeuge 

zur Systemverwaltung stets nur 

eine einzige Aufgabe erfüllen und zudem 

keine exklusive Kontrolle über Konfigurationsdateien 

benötigen. Trotzdem ist 

es unter RHEL unerlässlich, dass Administratoren 

in der Lage sind, das System 

manuell durch das Bearbeiten von Konfigurationsdateien 

zu verwalten. 

RHEL: Virtualisierung und 

Cluster-Suite 

Erwähnenswert im Bereich der Virtualisierungsfunktionen 

ist, dass RHEL seit 

der Version 6.3 in Gästen 160 statt wie 

bisher 64 virtuelle CPUs unterstützt. Ferner 

enthält RHEL seit der Version 6.3 das 

neue Werkzeug »virt‐v2v«, das es dem 

Admin ermöglicht, auf anderen Systemen 

wie beispielsweise Xen und VMware ESX 

erstellte virtuelle Maschinen zu importieren 

beziehungsweise konvertieren. 

Mit RHEL 6 wandte sich Red Hat vom 

noch in RHEL 5 favorisierten Xen-Hypervisor 

zugunsten des aus dem eigenen 

Hause stammenden KVM ab, was aber 

nicht bedeutet, dass RHEL 6 nicht als 

Gastsystem unter Xen läuft. Detaillierte 

Informationen zu den Virtualisierungsfunktionen 

finden sich unter [3]. Ferner 

erlaubt die in RHEL enthaltene Cluster- 

Suite ab RHEL 6.3, die HA-Infrastruktur 

auch für ein Failover virtueller Maschinen 

zu verwenden. RHEL 6 kann zudem auch 

als iSCSI-Initiator und Storage-Server arbeiten. 

Abbildung 2: Auch Suse gehört zu den Pionieren im Linux-Geschäft, bot den Enterprise-Server aber erst nach 

den frühen Distributionen für Privatanwender an. 

Weitere Besonderheiten: RHEL 5 und 

RHEL 6 sind LSB-3.1-zertifiziert. Unter 

anderem dank SE Linux genügen RHEL 5 

und RHEL 6 auch den Anforderungen des 

US-Sicherheitsstandards „EAL4+“ (EAL4 

mit Zusätzen). Die EAL4 (Common Criteria 

Evaluation Assurance Level)-Zertifizierung 

ist der höchste erreichbare Level, 

den ein allgemein verfügbares Standard- 

Betriebssystem ohne spezielle Modifikationen 

erlangen kann. 

Zertifziert 

Ferner kann Red Hat der US-Regierung 

die IPv6-Tauglichkeit von RHEL nachweisen. 

Zudem ist RHEL für SAP zertifiziert. 

Bleibt noch zu erwähnen, dass Red Hat 

Enterprise Linux 6 keine Unterstützung 

mehr für Intels Itanium-Architektur bietet. 

Red Hat lässt sämtliche IA64-Entwicklungen 

ausschließlich in Red Hat 

Enterprise Linux 5 einfließen. Die Unterstützung 

für RHEL 5 endet im März 2014. 

Allerdings können Kunden erweiterten 

Support von RHEL 5 für Itanium bis März 

2017 erwerben. 

RHEL 6 unterstützt auch die POWER- 

Architektur und benötigt dazu mindestens 

eine POWER6- oder neuere CPU. PO- 

WER5-Prozessoren werden von RHEL 6 

nicht unterstützt. Übrigens fungiert nicht 

nur RHEL selbst als Blaupause für RHEL- 

Klone oder zumindest für Enterprise-Distris, 

die den RHEL-Kernel verwenden, 

RHEL ist auch Basis für zahlreiche Cloudund 

Middleware-Produkte im eigenen 

Unternehmen. So wundert es kaum, dass 

auch Red Hats eigene Open-Stack-Variante 

Red Hat Enterprise Linux als Basis 

verwendet. Red Hats Open-Stack-Version 

wurde mit RHEL 6.3 getestet und benötigt 

selbstverständlich außerdem Red 

Hats Enterprise Virtualization (RHEV). 

RHEL ist außerdem ein essenzieller Bestandteil 

von Red Hats Plattform-as-a- 

Service-Strategie „OpenShift“. 

E Suse Linux 

Enterprise Server 

Red-Hats direkter Konkurrent im Sektor 

Enterprise-Distributionen ist die nach 

der Übernahme von Novells Linux-Sparte 

durch Attachmate im Mai 2011 wieder 

relativ unabhängig agierende Nürnberger 

Suse Linux GmbH. Sie hat als Pionier der 

Branche seit dem Jahr 2000 eine Enterprise-Distribution 

„Suse Linux Enterprise 

Server“ (SLES) [4] im Angebot. 

Nach Aussage von Suse nutzen derzeit 

13 000 Unternehmen SLES. SLES stellt 

damit rein wirtschaftlich zwar keine 

Konkurrenz zum RHEL dar, spielt aber 

technologisch in der gleichen Liga, hat 

historisch bedingt zahlreiche Kunden in 

Deutschland und verbucht im Detail den 

einen oder anderen Mehrwert gegenüber 




RHEL. Die Suse Linux GmbH spricht 

zudem von einer Lizenzkostenersparnis 

gegenüber dem direkten Konkurrenten 

RHEL von 50 Prozent, was sich aber anhand 

der Preislisten für die Subscriptions 

kaum nachvollziehen lässt. 

Die seinerzeit erste SLES-Version „Suse 

Linux Enterprise Server for S/390“ wurde 

von einem kleinen Entwicklerteam speziell 

für IBM-Großrechner (S/390) entwickelt. 

Erst mit der Version SLES 7 war 

SLES dann 2001 für die x86-Architektur 

verfügbar. Die derzeit aktuelle Version 

SLES 11 SP2 ist im Februar dieses Jahres 

erschienen und für die Plattformen x86/ 

x64), Intel Itanium, IBMs System z- und 

POWER-Plattformen, sowie in Amazons 

EC2-Cloud und als VMware-Appliance 

verfügbar. 

Wie der Name schon andeutet, ist SLES 

eine Server-Distribution. Suse bietet 

aber auch ein Desktop-Produkt, das als 

Nachfolger des Suse Linux Desktop beziehungsweise 

des Novell Linux Desktop 

aktuell auf den Namen Suse Linux 

Enterprise Desktop SLED hört. Seit SLES 

10 verwenden SLES und SLED eine identische 

Code-Basis. Aktuell wird SLES von 

Suse in vier Varianten aktiv gepflegt. SLES 

9 basiert auf einen Kernel 2.6.5. SLES 10 

SP3 nutzt einen Kernel 2.6.16, während 

SLES 11 SP1 wie RHEL auf einem Kernel 

2.6.32 aufsetzt. 

Die aktuelle Version SLES 11 SP2 kann 

bereits mit einem aktuellen Kernel 3.0 

aufwarten. Im Gegensatz zu zahlreichen 

anderen Enterprise-Linuxen basiert SLES 

nicht auf RHEL, sondern pflegt sowohl 

seinen Kernel als auch seine Paket-Basis 

selbst. 

Btrfs 

Btrfs gilt gemeinhin als Linux-Dateisystem der 

Zukunft und bietet gegenüber traditionelleren 

Dateisystemen interessante Möglichkeiten, 

wie etwa eine Unterstützung von Snapshots, 

Subvolumes, Kompression und RAID. SLES und 

Oracle Linux unterstützen Btrfs im Gegensatz 

zu RHEL bereits, wenn auch nicht als Standard- 

Dateisystem. 

Verwendet der SLES-Admin Btrfs für die Root- 

Partition, kümmert sich Yast automatisch um 

das Einrichten der benötigten Snapper-Infrastruktur. 

Die erzeugt mithilfe der in Btrfs enthaltenen 

Funktionen eine einstellbare Anzahl 

von Snapshots des kompletten Dateisystems, 

sodass veränderte oder gelöschte Dateien 

stets eine gewisse Zeit verfügbar bleiben. 

Auch Suse Enterprise Linux lässt sich 

ausschließlich über Subscriptions nutzen. 

Das Angebot ist allerdings etwas anders 

gegliedert als bei Red Hat. Der Kunde 

muss sich auf der SLES-Bestellseite lediglich 

für den CPU-Typ „x86 und x86_64“ 

oder „Power or Itanium“ entscheiden, 

sowie die Anzahl physischer oder virtueller 

Kerne angeben. Ist das geschehen, 

stehen drei Subscriptions „Basic“, 

„Standard“ und „Priority“ zur Verfügung, 

wobei zum Beispiel „Basic“ nur Maintenance 

enthält, keinen Support. Die preiswerteste 

Variante „Basic-Subscription 

für x86-CPUs mit 2 physischen Kernen“ 

schlägt dann mit 349 US-Dollar für den 

1-Jahres-Vertrag, 950 US-Dollar für den 

3-Jahres-Vertrag und 1400 US-Dollar für 

einen 5-Jahres-Vertrag zu Buche. 

Neuerer Kernel 

Die Suse-Entwickler pflegen einen eigenen 

Kernel für ihren Enterprise-Server, 

sodass die Entwicklung unabhängig vom 

Entwicklungsstand des RHEL-Kernels ist. 

So enthält die aktuelle SLES-Version SLES 

11 SP2 vom Februar 2012 immerhin einen 

deutlich aktuelleren Kernel 3.0 und 

zeichnet sich gegenüber RHEL dadurch 

aus, dass SLES bereits Btrfs-Unterstützung 

bietet (siehe Kasten „Btrfs“) und 

Funktionen zur Container-Virtualisierung 

auf Basis von Linux Container (LXC) zur 

Verfügung stellt. 

Suse weist in seinem LXC-Quickstart- 

Guide [5] allerdings auch auf die Nachteile 

und Gefahren (hoher Verwaltungsaufwand, 

größeres Sicherheitsrisiko, wegen 

prinzipiell schlechter gegeneinander 

Ferner zeigt ein Snapper-Modul für Yast die 

Unterschiede zur aktuellen Datei-Version und 

versetzt den Admin in die Lage, gegebenenfalls 

Änderungen zurücknehmen zu können. Sogar 

eingespielte Updates lassen sich rückgängig 

machen. 

Für die Boot-Partition lässt sich Btrfs allerdings 

nicht nutzen. Daher kann der Admin 

etwa Kernel-Updates oder Änderungen an der 

Boot-Konfiguration nicht mit Snapper managen. 

SLES unterstützt übrigens noch nicht die 

Btrfs-Funktion, mehrere Datenträger zu einem 

RAID zusammenfassen zu können. Inzwischen 

ist auch das Werkzeug fsck.btrfs im Update- 

Channel der Distribution verfügbar. Oracle Linux 

bietet ebenfalls Unterstützung für Btrfs. 

abgeschirmter VMs) der Container-Virtualisierung 

hin und empfiehlt, die Technik 

nicht in sicherheitskritischen Bereichen 

einzusetzen. Bekanntlich machen Webhoster 

häufig von der Container-Virtualisierung 

Gebrauch, nutzen jedoch meist 

eher das ebenfalls freie OpenVZ oder 

dessen kommerziellen Ableger Parallels 

Virtouzzo. 

Wie bei Red Hat lassen sich die aktuellen 

SLES-Versionen nur noch als Xen-Gäste 

betreiben, da auch Suse den Xen-Hypervisor 

– zumindest in der 32-Bit-Version 

– nicht mehr mitliefert und vollständig 

auf KVM setzt. Die 64-Bit-Ausgabe enthält 

derzeit zwar noch Xen, es ist aber 

absehbar, wohin die Reise geht. Unabhängig 

davon, was vom Support-Vertrag 

abgedeckt ist, unterstützt die Virtualisierung 

mit KVM in SLES bis zu 64 Prozessorkerne 

im Gastsystem. SLES 11 SP2 

enthält erstmals auch VirtFS [6] (Plan 9 

folder sharing over Virtio), mit dessen 

Hilfe mit Qemu/KVM betriebene Gäste 

auf Wunsch schneller auf Teile des Host- 

Dateisystems zugreifen können. 

Windows-Gäste 

Hinsichtlich der Paravirtualisierung ist 

noch erwähnenswert, dass der SLES- 

Support in der aktuellen Version auch 

den Einsatz von Windows-Gastsystemen 

unter KVM einschließt, wozu Suse allerdings 

rät, die von Suse angebotenen 

kommerziellen Virtio-Treiber des VMDP 

[7] (Virtual Machine Driver Pack) zu 

verwenden. 

Nachdem SLES 11 bei seinem ersten 

Erscheinungstermin noch einen Kernel 

2.6.27 enthielt, vollzog SLES 11 SP bereits 

im Februar diesen Jahres den Sprung vom 

Kernel 2.6.32 (SP1) auf einen leidlich aktuellen 

Kernel 3.0 im SP2, auf dem Papier 

immerhin ein Vorteil gegenüber dem in 

RHEL 6.3 noch verwendeten, allerdings 

stark modifizierten Kernel 2.6.32. Suse 

weist jedoch in den Release Notes darauf 

hin, dass offenbar einige Programme aus 

dem Tritt geraten, wenn die Versionsnummer 

des Kernels mit einer 3 beginnt 

und empfiehlt daher, betreffende Programme 

mithilfe des mitgelieferten Tools 

„name26“ als Parameter aufzurufen. 

Laut Suse enthält der SLES-Kernel auch 

die im Kernel 3.2 enthaltene Funktion 

„CFS Bandwidth Controller“ als Back- 


Admin 


39



port, womit es möglich ist, die Prozessorzeit 

für einzelne Prozesse einzuschränken, 

auch „CPU Hard Limits“ genannt. 

Zudem verwendet der SLES-Kernel per 

Default Transparent Huge Pages (THP), 

womit sich die CPU-Ressourcen zur Speicherverwaltung 

besser ausnutzen lassen 

sollen. Suse hat die eigene Sicherheits- 

Erweiterung App Armor für SLES schon 

Mitte 2008 aufgegeben. Die aktuellen 

Support-Verträge decken daher seit der 

SLES-Version 11 SP1 auch den Einsatz 

von Red Hats Sicherheitserweiterung SE 

Linux ab, allerdings ist SE Linux bei Suse 

im Gegensatz zu Red Hat per Default deaktiviert. 

Außerdem bietet SLES 11 volle 

Unterstützung für den Tomcat Servlet 

Container in der Version 6 

SLES-Treiber 

Das Kernel-Update bescherte SLES 11 

SP2 übrigens auch eine Reihe neuer Treiber, 

etwa für USB 3 oder für die Version 

3.0 von Intels „Rapid Storage Technology“ 

(RSTe3.0). Ferner kann OpenSSL 

in SLES 11 SP2 Intels AES-NI (AES New 

Instructions) nutzen, eine Funktion, mit 

der aktuelle Intel-Prozessoren Aufgaben 

beim Ver- oder Entschlüsseln mit AES 

(Advanced Encryption Standard) mit 

übernehmen. Die Suse-Entwickler haben 

zudem die Unterstützung für Intels AMT 

(Intel Active Management Technology) 

entfernt, weil die Technologie von Intel 

offenbar nicht mehr gepflegt wird. 

Wie bei RHEL gehört auch beim SLES 

der System Security Services Daemon 

(SSSD) zum Lieferumfang, der Vermittlungsdienste 

beim Authentifizieren über 

LDAP oder Kerberos übernimmt. Trotz 

eingebauter Btrfs-Unterstützung ist bei 

SLES immer noch Ext3 das Standarddateisystem 

(bei RHEL 6.32 ist es Ext4), SLES 

11 SP2 unterstützt aber auch Reiserfs 3.6 

und XFS. Das im Suse-Kernel enthaltene 

Ext4-Modul kann Ext4-Dateisysteme nur 

lesen und wird bei SLES lediglich zum 

Umwandeln von Ext-Dateisystemen nach 

Btrfs benötigt. Wer Ext4-Schreib-Untersützung 

braucht, muss bei SLES das vom 

SLES-Support nicht abgedeckte Kernel- 

Modul-Paket (KMP) „ext4-writeable“ installieren. 

Alle wichtigen Informationen zur aktuellen 

SLES-Version 11 SP2 finden sich 

auf der Produkt-Webseite, in den Release 

Notes und auf der offiziellen Dokumentationsseite. 

Eine 60-Tage Test-Version gibt 

es ebenfalls zum Herunterladen. Wie bei 

RHEL stehen auch bei Suse-Enterprise 

Server sämtliche Sourcen der einzelnen 

Produkte unter zum Download zur Verfügung. 

Auch Suse verwendet das RPM-Paket- 

Format, als Frontends zum Installieren 

von Paketen aus den Online-Paketquellen 

des NCC (Novell Customer Service) kommen 

Yast oder das in C++ geschriebene 

Tool Zypper zum Einsatz. Zugang zu 

den Online-Repositorien (auch bei SLES 

„Channels“ genannt) erhält nur, wer sich 

mit dem beim Erwerb der Subskription 

erhaltenen Acivation Code im Novell 

Customer Center registriert. 

Bei SLES 11 gibt es lediglich einen einzigen 

Base-Channel „SLES11-SP1-Pool“, 

der sämtliche Pakete enthält und dessen 

Inhalt sich über den gesamt Produkt- 

Lebenszyklus nicht ändert. SLES bezieht 

sämtliche zu installierenden Pakete aus 

dieser Quelle, solange es kein Updates 

gibt. Updates verwaltet SLES 11 im 

Channel „SLES11-SP1-Updates“. Erst mit 

SLES 11 SP2 sind zwei weitere Channels 

„SLES11-SP2-Core“ und „SLES11- 

SP2-Updates“ hinzugekommen, wobei 

„SP2-Core“ ein Subset an Paketen aus 

„SP1-Pool“ enthält. Bei Suse erscheinen 

Service Packs alle 18 Monate. Über 

den regulären Support hinaus lässt sich 

optional ein „Long Term Service Pack 

Support“ erwerben, das jeweils 12, 24 

oder 36 Monate über das erste Service 

Pack hinaus gehenden Support bietet, 

sodass sich auch der SLES-Support wie 

bei RHEL im Bedarfsfall über die regulär 

maximal möglichen sieben Jahre auf 

einen Unterstützungszeitraum von zehn 

Jahre ausbauen lässt. Übrigens wird SLES 

11 stets mit der zum Zeitpunkt der Veröffentlichung 

aktuellen Version der Linux 

Standard Base zertifiziert also LSB 4.0 

für SLES 11 SP2. Bei SLES 10 ist das 

3.0, bei SLES 9 2.0. Ältere Versionen des 

SLES sind nach älteren LSB-Standards 

zertifiziert. 

RHEL-Klone 

Dass es eine ganze Reihe voll kompatibler 

Red-Hat-Klone gibt, liegt an der GPL, 

die vorschreibt, dass ein unter der GPL 

stehendes Produkt wie RHEL im Source- 

Code veröffentlicht werden muss. Das 

gilt auch für abgeleitete Produkte, an 

denen der Hersteller Erweiterungen und 

Veränderungen vorgenommen hat. Auch 

die SLES-Sourcen sind wie erwähnt frei 

verfügbar. Bekannte freie Red-Hat-Klone 

sind zum Beispiel CentOS, Scientific 

Linux oder Yellow Dog Linux. 

Deren Macher müssen theoretisch nur 

die Source-Pakete (SRPMs) vom Red-Hat- 

Server laden und können das Produkt 

Abbildung 3: Oracle bietet ein eigenes, auf RHEL basierendes Produkt an, das es mit einem optimierten Kernel 

versehen hat. 




nach dem Anpassen von Texten, Logos 

oder Bildern einfach neu übersetzen, 

was einen voll kompatiblen RHEL-Klon 

zur Folge hätte. Was theoretisch simpel 

klingt, ist in der Praxis nicht ganz so 

einfach, woran insbesondere der Kernel 

schuld ist. Damit sämtliche Einsprungadressen 

an den richtigen Positionen liegen, 

muss das Übersetzen mit exakt dem 

gleichen gcc-Compiler und identischen 

Compiler-Optionen erfolgen, wobei Red 

Hat seine Konkurrenten verständlicherweise 

nicht unterstützt. 

Zudem ist der Red-Hat-Kernel stark modifiziert, 

die von Red Hat vorgenommenen 

Einzel-Patches lassen sich aber nur 

schwer nachvollziehen. Daher dauert es 

nach dem Erscheinen eines neues Red Hat 

Releases immer einer Weile, bis auch die 

Klon-Herstellers nachziehen. So erschien 

beispielsweise das aktuelle Cent OS 6.3 

am 10. Juli diesen Jahres, knapp drei Wochen 

nach dem Original. Neben voll binär 

kompatiblen RHEL-Klonen gibt es auch 

Tabelle 1: Preise und Supportleistungen 

Red Hat Suse Oracle 

Basis-Preise für ein Jahr 

CPUs/Cores 2 physische Cores 2 physische Cores unbegrenzt 

Support- 

Umfang 

„Self-Support“: Kein 

Support, nur Maintenance 

(Updates) 

„Basic“: Kein Support, 

nur Maintenance 

(Updates) 

„Network Support“: kein 

Support, nur Maintenance 

(Patches, Updates, 

Security Fixes) 

Preis 349 US-Dollar 349 US-Dollar 94 Euro 

Standard-Preise für ein Jahr 

CPUs/Cores 4 physische Cores 4 physische Cores 2 Cores / unbegrenzt 

Support- 

Umfang 

„Standard“: Support (12/ 

5 via Web, Telefon) + 

Maintenance (Updates) 

„Standard“: Support (12/ 

5 via E-Mail, Web, Chat, 

Telefon) + Maintenance 

(Updates+Patches) 

„Basic Limited Support“: 

Support (24/7 via Web, 


(Patches, Updates, 

Security Fixes) 

Preis 1598 US-Dollar 1598 US-Dollar 396 Euro / 948 Euro 

Premium-Preise für ein Jahr 

CPUs/Cores 4 physische Cores 8 physische Cores 2 Cores / unbegrenzt 

Support- 

Umfang 

„Premium“: Support (24/ 

7 via, Web, Telefon) + 

Maintenance (Updates) 

„Priority“: Support (24/ 

7 via E-Mail, Web, Chat, 


(Updates+Patches) 

„Premier Limited 

Support“: Support (24/ 

7 via Web, Telefon) + 

Maintenance (Patches, 

Updates, Security Fixes) 

Preis 6498 US-Dollar 5996 US-Dollar 1104 Euro / 1812 Euro 

Die Admin-Bibel 

für Linux-Server! 

Dieses Buch lässt das Herz eines Linux-Administrators 

garantiert höher schlagen: Backup, Sicherheit, Samba, 

LDAP, Web-, Mail- und FTP-Server, Datenbanken, 

Kerberos-Authentifizierung, IPv6, NFSv4 u. v. m. 

übersichtlich erklärt! 

Mehr Bücher für Administratoren: 

www.GalileoComputing.de 

948 Seiten, 2. Auflage 2012, 49,90 €, ISBN 978-3-8362-1879-5 

Jetzt 

reinschauen! 


Admin 


41 

Wissen, wie’s geht.



eine Reihe von Distributionen, die einen 

aktuellen RHEL-Kernel verwenden. 

Was die RHEL-Klone angeht, haben wir 

auf freie, zum Teil vollständig kompatible 

Ableger wie CentOS verzichtet, weil die 

mangels Support den primären Zweck einer 

Enterprise-Distribution nicht erfüllen, 

obwohl Sie insbesondere bei Internet- 

Providern sehr beliebt sind. Wer nur die 

stabile technische Basis einer Enterprise- 

Distribution genießen möchte, aber keinen 

Support braucht, ist mit CentOS gut 

bedient. Übrigens bietet pikanterweise 

ausgerechnet Microsoft Support für CentOS-Systeme 

an, wenn man sie in der 

Microsoft-Cloud Azure betreibt. 

E Oracle Linux (OEL) 

Unter den kommerziellen RHEL-Klonen 

ist vor allem Oracle Linux (OEL) [8] 

erwähnenswert, das Oracle im Jahr 2006 

auf den Markt brachte. OEL ist auf Paket- 

Ebene weitgehend kompatibel mit RHEL, 

verwendet aber einen eigens angepassten 

Kernel, den Oracle unter dem Namen 

„Unbreakable Enterprise Kernel R.2“ [9] 

anpreist. Bei Oracles Unbreakable Enterprise 

Kernel handelt es sich um einen von 

Oracle modifizierten Kernel 3.0.16 für 

x86- und x64-Systeme, der insbesondere 

die Zusammenarbeit mit Oracles Datenbank-, 

Middleware- und Hardware-Systemen 

optimiert ist. 

Laut Oracle soll OEL Linux 75 Prozent 

bessere Performance bieten als RHEL 

und wie SLES und darüber hinaus Btrfs 

und Linux Containers (LXC) unterstützen. 

Neben seinem Ubreakable Kernel 

(UEK) liefert Oracle Linux (OEL) stets 

auch einen vollständig RHEL-kompatiblen 

Kernel (2.6.32) mit. Administratoren, 

die planen, den UEK-Kernel einzusetzen, 

sollten wissen, dass damit die Binärkompatibilität 

bei Treibern verloren gehen, 

nicht jedoch die Binärkompatibilität von 

Userland-Prozessen. 

Unzerbrechlich 

auf ganz verschiedene Aspekte. So soll 

etwa die Netzwerk-Performance dank 

im UEL-Kernel enthaltenen „Receive 

Steering“ höher sein. Laut Oracle haben 

die eigenen Entwickler außerdem die 

asynchrone I/O-Leistung verbessert und 

Optimierung für SSDs eingebaut. Ferner 

unterstützt OEL das von Oracle entwickelte 

Protokol „Reliable Datagram Sockets 

(RDS)“, was ebenfalls eine höhere 

Performance in schnellen Netzen mit geringer 

Latenz ermöglichen soll, etwa für 

die NAS-Anbindung. 

Die herausragende Besonderheit beim 

UEK ist jedoch die Unterstützung der 

Ksplice-Technologie [10] (siehe Kasten 

Redpatch und Ksplice). Sie erlaubt es, 

Updates für den Kernel, sowie Treiber 

ohne einen Reboot einzuspielen, ein bei 

Servern interessantes Alleinstellungsmerkmal. 

Ksplice erlaubt es im Prinzip, 

neue Kernel-Patches unmittelbar in den 

Hauptspeicher zu laden, was theoretisch 

einen Linux-Server ermöglicht, der quasi 

ununterbrochen läuft, weil er nie neu 

gestartet werden muss. 

Seit Ksplice von Oracle übernommen 

wurde, ist die Technologie allerdings nur 

noch kostenpflichtig für Oracle Linux 

verfügbar. Die sonstigen Eckdaten von 

Oracle Linux sind weitgehend identisch 

mit Red Hat Enterprise Linux. Auch die 

Versionierung folgt dem RHEL-Schema. 

Die aktuelle Version von Oracle Linux 

trägt also ebenfalls die Versionsnummer 

6.3 und ist am 03. Juli diesen Jahres 

erschienen. 

Was das Subsciptions-Modell angeht, 

ist festzuhalten, dass Oracle Linux keines 

hat. Jeder kann die ISO-Images von 

Oracle Linux kostenlos aus der Oracle 

Software Delivery Cloud herunterladen. 

Das gilt sowohl für die ISO-Images der 

Installationsmedien als auch für die Sourcen, 

die außerdem auf zahlreichen Spiegelservers 

liegen, in Deutschland etwa 

unter [11]. Kostenpflichtig ist bei Oracle 

Linux lediglich der Support. Neue Nutzer 

müssen sich allerdings einmalig beim 

„Oracle E-Delivery Service“ registrieren. 

Die Produktstrategie von OEL basiert 

hauptsächlich auf dem Ubreakable Kernel, 

der den Hauptanteil an den genannten 

Vorteilen von OEL gegenüber RHEL 

hat. Der ebenfalls mitgelieferte Standard- 

RHEL-Kernel ist mit diesem identisch und 

vorrangig an Bord, sollte ein bestimmtet 

Programm unter Oracle Linux Probleme 

bereiten. Die einzelnen Support-Staffeln 

von OEL sind im Online-Shop von Oracle 

zu finden. Oracle ist grundsätzlich nur 

für X86-32-/64-Plattfomen und Itanium 

verfügbar. Letztere wie Red Hat Enterprise 

Linux allerdings nur bis einschließlich 

der Version 5.5. 

Die preiswerteste Stufe (neben dem Verzicht 

auf Support) ist „Oracle Linux Network 

Support“. Der kostet für ein Jahr 

93,96 Euro. Weitere Besonderheit bei 

Oracle-Linux: Jeder Admin kann sich die 

Mit „unbreakable“ will Oracle andeuten, 

dass man die Stabilität gegenüber dem 

RHEL-Kernel verbessert hat. Außerdem 

hat Oracle eine Reihe von Funktionen in 

seinen UEK eingebaut, die es in sich haben. 

Die versprochene bis zu 75 Prozent 

höhere Performance bezieht sich indes 

Abbildung 4: Ein weiterer Klon der Red-Hat-Distribution ist der Newcomer ROSA Linux. Im Gegensatz zu etwa 

CentOS hat ROSA aber kommerzielle Ambitionen. 




lizensierte Software auf Wunsch auch 

in Form eines physischen Datenträgers 

(Media Pack) zusenden lassen. Der kostet 

dann 59,20 Euro. 

Ein Vergleich der drei bisher vorgestellten 

Enterprise-Systeme ist noch einmal 

in Tabelle 1 zu sehen. Weil jede 

Firma bereits eine Fülle unterschiedlicher 

Lizenzmodelle und Support-Pakete 

bietet und diese sich kaum direkt 

vergleichen lassen, kann die Tabelle 

nur eine grobe Orientierung geben. 

Beispielsweise berechnen Suse und Red 

Hat ihre Modelle auf der Basis von Rechnerkernen. 

Oracle bietet ein Support- 

Modell, das ebenfalls auf Cores basiert, 

erlaubt aber beim Basis-Support eine unbegrenzte 

Zahl. 

E ROSA Enterprise Linux 

Ein weiterer relativ junger RHEL-Abkömmling 

ist der „ROSA Enterprise Linux 

Server (RELS) 2012“ (Codename 

Helium), des russischen Distributors 

ROSA Labs. ROSA kooperiert bekanntlich 

bei seiner Desktop-Distribution „ROSA 

Marathon 2012“ mit Mandriva. RELS 

dagegen basiert auf RHEL und bietet 

fünf Jahre Support bei der kommerziellen 

Variante, bietet RELS aber auch als 

Community-Version an. Die Distribution 

ist ausschließlich für 32- und 64-Bit-x86- 

Systeme verfügbar. 

ROSA hat seiner Distribution allerdings 

im Vergleich zu den Paketen von RHEL 

6 einige Aktualisierungen, sowie eine 

handvoll zusätzlicher Pakete spendiert 

und ein Verwaltungswerkzeug entwickelt. 

ROSA Helium ist ebenfalls binärkompatibel 

zu RHEL 6. Die freie Version 

steht unter [12] zum Herunterladen zur 

Verfügung. Die Shop-Seite von Rosalab 

war bis Redaktionsschluss noch „Under 

Construction“. 

Alternativen 

Neben den erwähnten Distributionen 

gibt es noch eine Reihe kleinerer 

Anbieter, die ebenfalls die Nachfrage 

von Firmen bedienen, die Linux im 

Geschäftsumfeld einsetzen wollen. 

Das ist etwa der Univention Corporate 

Server, der schon mehrfach im ADMIN 

vorgestellt wurde und auf Debian Linux 

aufbaut. Auch für Debian selbst gibt es 

einige Anbieter im deutschen Raum, die 

kommerziellen Support für die ansonsten 

unveränderte Distribution leisten. 

Ubuntu-Support gibt es beim Unternehmen 

Canonical. Mehr dazu verrät der 

Artikel auf den folgenden Seiten. 

Fazit 

Der Nutzen von Enterprise-Distributionen 

besteht primär in einer möglichst 

langen Support-Dauer. So bieten sowohl 

RHEL, als auch SLES die Möglichkeit, ein 

System mit uneingeschränktem Herstellersupport 

bis zu zehn Jahre lang zu nutzen, 

ohne Pakete migrieren zu müssen. 

Durch die langen Support-Zeiträume haben 

auch große Softwarehäuser wie SAP 

ein Interesse daran, das Betriebssystem 

für ihre Anwendungen zu zertifizieren, 

was Enterprise-Distributionen für viele 

Firmen interessant macht. 

Eine konkrete Empfehlung für eine der 

Distributionen ist naturgemäß schwierig, 

ein paar Denkanstöße seien aber erlaubt. 

RHEL ist der Marktführer, und der Umsatz, 

den Red Hat mit RHEL-Subscriptions 

erwirtschaftet, sowie die Unternehmensgröße 

und die Anzahl installierte 

Kundensysteme sprechen jedenfalls für 

eine rosige Zukunft. Zudem sind viele 

Programme im Enterprise-Umfeld explizit 

für den RHEL-Kernel getestet , was ebenfalls 

für die Distribution spricht. 

Zudem ist RHEL nicht einmal der teuerste 

Vertreter. Die Subskriptions-Modelle 

lassen sich zwar nicht direkt vergleichen 

und Subskriptions-Kosten sollten auch 

sicher nicht das einzige Auswahlkriterium 

sein, auf zumindest auf dem Papier 

erscheint SLES kostspieliger. Dafür bietet 

SLES aber auch mehr: neben einem aktuelleren 

Kernel mit Btrfs- und LXE-Untersützung 

auch eine von RHEL unabhängige, 

erweiterte Paket-Basis. Bei Oracle 

Linux ist vor allem der Unbreakable- 

Kernel ein Novum und für viele Kunden 

sicher ein Argument, zumal Oracle Linux 

das derzeit übersichtlichste und kostengünstigste 

Support-Modell anbietet. 

Dass Oracle in Teilen der Linux-Community 

keinen guten Ruf genießt, weil es 

im Umgang mit der Freien-Software-Welt 

nicht immer glücklich agiert hat, etwa 

bei der Klage gegen Google, muss bei 

der Kaufentscheidung nicht unbedingt 

eine Rolle spielen. Übrigens: Sowohl Red 

Hat als auch Suse und Oracle schließen 

in ihren Enterprise-Distributionen eine 

Versicherung ein, die Kunden vor potenziellen 

Copyright-und Patentklagen 

schützt. (ofr) 

n 

Infos 

[1] RHEL Sourcen: [http:// ftp. redhat. com/ 

pub/ redhat/ linux/ enterprise/] 

[2] RHEL alle Versionen: [https:// www. redhat. 

com/ wapps/ store/ allProducts. html] 

[3] RHEL Virtualisierungsfunktionen: [https:// 

access. redhat. com/ knowledge/ docs/ 

de‐DE/ Red_Hat_Enterprise_Linux/ 6/ html/ 

Release_Notes/ virtualization. html] 

[4] Suse Linux Enterprise Server: [https:// 

www. suse. com/ de‐de/ products/ server/] 

[5] SLES-LXC-Quickstart-Guide: 

[http:// www. suse. com/ documentation/ 

sles11/ singlehtml/ lxc_quickstart/ lxc_ 

quickstart. html] 

[6] VirtFS: [http:// wiki. qemu. org/ 

Documentation/ 9psetup] 

[7] Suse Virtual Machine Driver Pack:[http:// 

www. suse. com/ products/ vmdriverpack/] 

[8] Oracle Linux: [http:// www. oracle. com/ de/ 

technologies/ linux/ overview/ index. html] 

[9] Oracle Unbreakable Kernel (UEK): [http:// 

www. oracle. com/ us/ technologies/ linux/ ue 

k‐r2‐features‐and‐benefits‐1555063. pdf] 

[10] Ksplice: [http:// www. ksplice. com] 

[11] Sourcen und ISOs OEL 6.3:[http:// mirror. 

netcologne. de/ oracle‐linux/ OL6/ U3/] 

[12] ROSA Enterprise Linux Server (RELS) 

2012: [http:// mirror. rosalab. ru/ 

rosa‐server2012/ iso/] 

[13] Novell-Support für RHEL:[https:// 

www. suse. com/ de‐de/ solutions/ 

enterprise‐linux‐servers/ redhat‐to‐suseli 

nuxenterprise‐migration. html] 

[14] Redpatch-Repository: [https:// oss. oracle. 

com/ projects/ RedPatch] 

[15] Redpatch Git-Depot: [https:// oss. oracle. 

com/ git/ ? p=redpatch. git;a=shortlog] 

Der Autor 

Thomas Drilling ist seit mehr als zehn Jahren 

hauptberuflich als freier Journalist und Redakteur 

für Wissenschafts- und IT-Magazine tätig. 

Er selbst und das Team seines Redaktionsbüros 

verfassen regelmäßig Beiträge zu den Themen 

Open Source, Linux, Server, IT-Administration und 

Mac OS X. Außerdem arbeitet Thomas Drilling als 

Buchautor und Verleger, berät als IT-Consultant 

kleine und mittlere Unternehmen und hält Vorträge 

zu Linux, Open Source und IT-Sicherheit. 


Admin 


43


Ubuntu Enterprise 

© Parinya Niranatlumpong, 123RF 

Distributionen zumindest aus Kostengesichtspunkten 

um je eine Server- und 

Desktop-Variante von Ubuntu ergänzen 

lässt (siehe Tabelle 1). 

Übrigens verspricht Canonical mit dem 

Advantage-Programm seinen Kunden 

unter dem Namen „Ubuntu Assurance“ 

auch eine Art Versicherung gegen Patent-Klagen 

im Zusammenhang mit dem 

Einsatz von Ubuntu im Unternehmen. 

Canonical sichert seinem Advantage- 

Kunden im Falle eines Falles sowohl die 

Verteidigung als auch die Übernahme 

der entstandenen Kosten zu. Im Zusammenhang 

mit dem Advantage-Programm 

ist auch Canonicals Landscape [3] zur 

zentralen Verwaltung von Ubuntu-Installationen 

erwähnenswert (siehe Kasten 

„Landscape“). 

Ubuntu Business Desktop Remix 12.04 LTS 

Neu gemischt 

Mit seiner erstmals mit der Version 11.04 veröffentlichten Variante 

„Ubuntu Business Desktop Remix“ möchte Canonical nicht nur Windows 

vom Unternehmens-Desktops verdrängen, sondern vor allem auch eine 

kostengünstige Alternative zu den Unternehmens-Desktops von Red Hat 

und Suse bieten. Thomas Drilling 

Zwei Wochen nach der Veröffentlichung 

von Ubuntu 12.04 LTS (Long Termin Support) 

im Mai 2012 hat Canonical die erste 

Aktualisierung seiner „Business Desktop 

Remix“ [1] genannten Unternehmens- 

Variante herausgegeben. Erstmalig hatte 

man sie in der Version 11.10 mit dem Ziel 

veröffentlicht, den Enterprise-Desktop- 

Produkten von Red Hat und Suse eine 

Ubuntu-Variante gegenüberzustellen. Mit 

der Version 12.04 erlangte auch der Business 

Desktop Remix den LTS-Standard 

und ist daher aufgrund der von Canonical 

für einen Zeitraum von fünf Jahren 

garantierten Verfügbarkeit von Updates 

möglicherweise eine Alternative zu den 

kommerziellen Unternehmens-Desktops 

von Red Hat (RHEL für Desktops) und 

Suse (SLED – Suse Linux Enterprise 

Desktop). 

Beim Studium der Papierform wird aber 

schnell klar, dass ein Vergleich mit den 

genannten Enterprise-Desktops hinkt. 

Zum einen ist der Ubuntu Business 

Desktop Remix im Unterschied zu RHEL 

und SLED nach einmaliger Registrierung 

kostenlos verfügbar. Zum zweiten unterscheidet 

sich die Distribution faktisch 

kaum von einer regulären Ubuntu-Distribution; 

was die Installation angeht bis 

auf den Startbildschirm überhaupt nicht. 

Die Enterprise-Versionen von Suse und 

Red Hat dagegen weichen dagegen erheblich 

von Open Suse und Fedora ab. 

Vorteil Ubuntu 

Im Rahmen des Advantage-Programms 

[2] bietet Canonical allerdings auch ein 

kostenpflichtiges Support-Programm, 

wahlweise für Server-, Desktop- und 

Cloud-Dienste beziehungsweise Produkte, 

sodass sich auch unsere Übersicht 

der aktuell verfügbaren Enterprise- 

Durchleuchtet 

Der Business Desktop Remix steht nach 

einer obligatorischen Registrierung zum 

kostenlosen Download in 32- und 64-Bit- 

Varianten für x86-Systeme zur Verfügung. 

Aus technischer Sicht unterscheidet sich 

Ubuntu Business Desktop 12.04 nicht 

von der Standard-Version, im Gegensatz 

zu den Desktop-Produkten von Red Hat 

und Suse. 

Das Ziel des Ubuntu Desktop Remix besteht 

laut Canonical [4] darin, Administratoren 

in Unternehmen ein Fundament 

zur Verfügung zu stellen, das diese 

nach Belieben für ihre Zwecke adaptieren 

können. Daher hat Canonical beim 

Business-Desktop Remix in erster Linie 

Spiele und Anwendungen, die sich mit 

sozialen Netzwerken verbinden, sowie 

Filesharing-Tools aus der Distribution 

Landscape 

Neben kommerziellen Support bietet Canonical 

mit Landscape auch professionelle Unterstützung 

beim „Ausrollen“ der Distribution 

an. Landscape ist eine Management-Software, 

mit deren Hilfe der Administrator Server-, 

Desktop- und Cloud-Dienste verwalten kann, 

vergleichbar mit dem Satellite Server von Red 

Hat (siehe Artikel in diesem Schwerpunkt). 

Mit Landscape ist es beispielsweise möglich, 

Sicherheits-Updates auf mehren hundert Maschinen 

gleichzeitig einzuspielen. Canonical 

bietet Landscape optional zu seinem Advantage-Support-Dienst 

an. Darüber hinaus bietet 

Landscape dem Admin exklusiven Zugriff auf 

Canonicals Knowledge-Datenbank. 


Ubuntu Enterprise 


Abbildung 1: Remmina ist ein vielseitiger, leistungsfähiger und erweiterbarer 

Remotedesktop-Client. 

entfernt, ebenso wie eine Reihe weiterer 

Programme und Werkzeuge. Das sind im 

Prinzip vor allem Programme, die sich an 

Heimanwender richten. 

Dafür hat Canonical seiner Business-Variante 

im Gegenzug eine Reihe von speziell 

im Unternehmen nützlichen Anwendungen 

spendiert, wie das Adobe Flash 

Plugin, OpenJDK und VMware View oder 

Unterstützung für MS Windows RDP 7.1 

in Form des „Remmina Remote Desktop 

Client“ eingebaut (Abbildung 1). Der 

universelle Remote-Desktop-Client unterstützt 

über Plugins neben RDP auch die 

Protokolle für VNC, NX, Telepathy oder 

XDMCP. 

Alles davon lässt 

sich naturgemäß 

auch bei einer regulären 

Ubuntu- 

Varainte nachinstallieren, 

allerdings 

erspart der 

Ubuntu Desktop 

Remix dem Administrator, 

dank fehlender 

Spiele und 

Heim-Anwendungen 

viel Arbeit. 

Darüber hinaus 

wird sich der eine 

oder andere Admin 

über nützliche 

Kleinigkeiten, 

wie einen Libre-Office-Import-Filter für 

Microsoft Visio freuen. 

Fazit 

Ubuntu Business Desktop klingt auf dem 

ersten Blick nach einer interessanten und 

preiswerten Alternative zu den Enterprise-Versionen 

von Suse und Red Hat. 

Updates gibt es bei Canonical allerdings 

ohnehin kostenlos, bei den LTS-Versionen 

sogar fünf Jahre lang. Support kann man 

bei Bedarf dazu kaufen und ist in der 

Standard-Variante mit 105 US-Dollar im 

Jahr auf der sicheren Seite. Das gilt aber 

für alle Ubuntu-Versionen. 

Tabelle 1: Preise und Supportleistungen 

Distribution Ubuntu-Server Ubuntu-Desktop 

Basis-Preise für ein Jahr 

Anzahl 1 Server – 

Support-Umfang „Essential“: Landscape, Ubuntu – 

Assurance, Wissensdatenbank, 

Installation 

Preis 320 US-Dollar – 

Standard-Preise für ein Jahr 

Anzahl 1 Server 1 Desktop 

Support-Umfang „Standard“: Landscape, Ubuntu 


Installation, Windows-Integration, 

„Standard“: Landscape, Ubuntu 


Installation 


Preis 700 US-Dollar 105 US-Dollar 

Premium-Preise für ein Jahr 

Anzahl 1 Server 1 Desktop 

Support-Umfang „Advanced“: Landscape, Ubuntu 


Installation, Windows-Integration, 

Virtualisierung, Clustering, angepasstes 

„Advanced“: Landscape, Ubuntu 


I nstallation, Desktop-Virtualisierung, 

Entwickler-Tools 

Paket-Repository 

Preis 1300 US-Dollar 165 US-Dollar 

Die von Canonical zum Business-Desktop-Remix 

formulierte Philosophie [4], 

eine Distribution für den Unternehmenseinsatz 

zu liefern, ist fundiert. Vorteile 

für den Anwender sind hierbei die einfache 

Benutzbarkeit, freie Software, zertifizierte 

proprietäre Anwendungen und 

Viren-Freiheit. Alle diese Vorteile könnte 

eine maßgeschneiderte Ubuntu-Variante 

liefern, aber so maßgeschneidert ist Business 

Remix nicht. 

Das soll keine Abwertung einer an sich 

gelungenen Distribution sein, sondern 

lediglich die Feststellung, dass eine gewöhnliche 

LTS-Version von Ubuntu denwohl 

vor allem als Marketing-Instrument 

konzipiert, das „Business“-Kunden die 

bei Heimandwendern populäre Ubuntu- 

Distribution nahe bringen soll. Das aber 

hat Canonical in Anbetracht seines fairen 

Support-Agebots eigentlich aber gar nicht 

nötig. Andererseits böte das Thema einer 

für den Unternehmens-Einsatz optimierten 

Desktop-Variante von Ubuntu durchaus 

noch Potenzial. 

So oder so stellt derzeit auch ein reguläres 

LTS-Ubuntu im Zusammenhang mit 

dem Advantage-Support-Paket und der 

Verwaltungs-Software Landscape bereits 

eine stimmige Lösung für den Einsatz 

in kleinen Unternehmen dar, nicht nur, 

wenn auch auf Server-Seite ein Ubuntu- 

System seinen Dienst verrichtet. (ofr) n 

Infos 

[1] Ubuntu Business Desktop Remix: [http:// 

www. ubuntu. com/ business/ desktop/ remix] 

[2] Advantage-Programm: [http:// www. ubuntu. 

com/ business/ advantage] 

[3] Ubuntu-Landscape: [http:// www. ubuntu. 

com/ business/ landscape] 

[4] Ziele Business Desktop Remix: [http:// 

blog. canonical. com/ 2012/ 05/ 10/ the‐new‐b 

usiness‐desktop‐remix‐is‐out‐now] 

Der Autor 

Thomas Drilling ist seit mehr als zehn Jahren 

hauptberuflich als freier Journalist und Redakteur 

für Wissenschafts- und IT-Magazine tätig. 

Er selbst und das Team seines Redaktionsbüros 

verfassen regelmäßig Beiträge zu den Themen 

Open Source, Linux, Server, IT-Administration und 

Mac OS X. Außerdem arbeitet Thomas Drilling als 

Buchautor und Verleger, berät als IT-Consultant 

kleine und mittlere Unternehmen und hält Vorträge 

zu Linux, Open Source und IT-Sicherheit. 


Admin 


47


Satellite Server 

© Dirk Ercken, 123RF 

Enterprise Software Management mit dem Red Hat Satellite Server 

Paketversand 

Red Hats Satellite Server, ein unternehmenstaugliches Patch-Management-System, hält das gesamte Netzwerk 

auf dem Laufenden. James Dade 

Unsere Organisation folgt momentan einem 

systematischen, händischen Ansatz 

beim Patch Management. Das schließt 

die Identifikation der Notwendigkeit von 

Patches, ihre Beschaffung, das Testen 

und die Lösung von Problemen im Zusammenhang 

mit Patches sowie das Einspielen 

der Patches ein. Bei uns erhalten 

die Administratoren Hinweise auf Patches 

in der Regel per E-Mail entweder von den 

Herstellern oder aufgrund von Recherchen. 

Das Information Assurance Team 

(IA) veröffentlicht außerdem Sicherheitswarnungen 

in der Regel etwa eine Woche 

nach den Herstellermeldungen. 

Nachdem ein Admin einen Hinweis auf 

einen nötigen Patch erhalten hat, lädt 

er den Patch von den Webseiten eines 

Herstellers herunter und speichert ihn 

in einem eigenen Repository. Sobald 

der Patch dort angelangt ist, testet ihn 

der Admin in einer speziellen Test- oder 

Entwicklungsumgebung. Tauchen dabei 

Probleme auf, kontaktiert der Admin den 

Herausgeber des Patchs und löst sie. 

Nach Abschluss der Tests ist der Patch für 

das Einspielen auf den Produktivsystemen 

im nächsten Wartungsfenster bereit. 

Danach wandert der Patch in ein anderes 

Repository, wo er archiviert wird. 

Red Hats Methode der Automatisierung 

solcher Software-Updates ist der Satellite 

Server. Seine Rolle entspricht ungefähr 

der von Microsofts Systems Management 

Server (SMS). Die Einführung eines Satellite 

Server muss nicht notwendigerweise 

den ganzen Patch-Management-Prozess 

umkrempeln, aber ein solcher Server automatisiert 

fortan das Abrufen, Speichern 

und Ausbringen der Patches. Außerdem 

pflegt der Satellite Server eine Sammlung 

aller Software Packages auf allen von ihm 

verwalteten Systemen. Der Satellite Server 

besorgt sich automatisch zu jedem 

erforderlichen Patch auch die Dokumentation, 

aus der hervorgeht, warum er eingespielt 

wurde. 

Forschungsansatz 

Als primäre Tools für die vorliegende Recherche 

dienten die verschiedenen Handbücher 

zum Red Hat Satellite Server 5.4. 

Red Hats Solutions Architect war ebenfalls 

eine hilfreiche Quelle. Drei Monate 

lang testeten wir den Red Hat Satellite 

Server, der auf einem HP Proliant DL380 




G5 installiert war, auf dem RHEL 6.1 mit 

einer Basisausstattung an Paketen lief. 

Als Test-Clients dienten ein Proliant 

DL380 G5 und ein HP Proliant WS 460 

G6, der in einem HP Blade-System C7000 

steckte. Abbildung 1 zeigt die Testumgebung. 

Patchen mit dem Satellite 

Server 

Red Hat generiert Patches nach Bedarf, 

manchmal vier- oder fünfmal die Woche 

für bestimmte Programme. Diese Patches 

haben oft mehrfache Abhängigkeiten. 

Wollte man die Patches manuell einspielen, 

könnte es leicht Stunden wenn 

nicht Tage dauern, die Abhängigkeiten 

aufzulösen und die nötigen Files zu den 

Rechnern zu transferieren, die gepatchet 

werden sollen. 

Theoretisch kann man ein Red-Hat-System 

mit nichts als Yum aktuell halten 

(siehe Kasten „Patching mit Yum“), 

aber in der Praxis führt der Zeitbededarf, 

und das Risiko, dass einem ein wichtiger 

Patch durch die Lappen geht, dazu, dass 

man ein Tool braucht, das die Patches 

ordnet, verwaltet, zeitlich plant und einspielt. 

Ein solches Werkzeug, das Patches (Security 

Fixes wie Funktionserweiterungen) 

halbautomatisch implementiert, ist der 

Red hat Satellite Server. Die von ihm 

verwalteten Server müssen dabei keine 

Abbildung 1: Die Testumgebung für die Versuche mit dem Red Hat Satellite Server. 

Abbildung 2: Single-Server-Konfiguration: Ein einziger Satellite Server bedient das gesamte interne Netz. 

8,90€ * 

124 Seiten Linux 

+ DVD 

Die aktuelle Ausgabe von LinuxUser Spezial 

dringt in die Tiefen des Linux-Systems ein 

und zeigt, wie Sie Ihren Rechner auf der 

Kommandozeile administrieren. 


Jetzt bestellen 

unter: www.linuxuser.de/spezial 

Tel.: 089-9934110, Admin Fax: 089-99341199, E-Mail: Ausgabe order@linuxuser.de 

01-2013 

49



Patching mit Yum 

Der Yellowdog Updater Modified (Yum) ist ein 

freies Kommandozeilentool für den Red Hat 

Package Manager, den Red Hat, Suse, Fedora 

und einige andere Distributionen nutzen. 

Um Yum benutzen zu können, muss der Server 

mit dem Internet verbunden sein. Yum unterstützt 

eine Anzahl verschiedener Package 

Repositories. Wer seine Pakete aus den Repositories 

im Red Hat Network bezieht, der muss 

das zu patchende System bei einem RHN-Server 

registrieren. 

Der YUM Package-Management-Prozess öffnet 

die folgenden Sicherheitslöcher im Netzwerk: 

n Jeder Red Hat Server braucht eine Internetverbindung. 

n Die Serverkonfiguration ist für Red Hat einsehbar 

und damit im Falle eines Sicherheitslecks 

bei Red Hat auch für die Welt. 

Die Herangehensweise mit Yum ist akzeptabel, 

wenn der fragliche Client ohnehin mit dem Internet 

verbunden ist, wie das etwa bei einem 

Webserver wäre, der ohnehin offene Ports hat, 

und für den Durchlässe in der Firewall sowieso 

existieren müssen. 

Für alle Server mit Red Hat Enterprise Linux 

(RHEL) empfiehlt der Autor jedoch, auf Yum zu 

verzichten, weil so zu viele Angriffsmöglichkeiten 

eröffnet werden, die unter Umständen das 

ganze Netzwerk unsicher machen können. Jeder 

Rechner mit RHEL könnte zum Ziel einer Attacke 

werden, wenn seine Software auf einem Server 

außerhalb des eigenen Kontrollbereichs inventarisiert 

wird. 

Red Hat-Maschinen sein, Satellite Server 

unterstützen auch Solaris- und Microsoft- 

Systeme. Der Satellite Server hat eine Internetverbindung 

und ist – als einziger 

Server – bei dem Server des Red Hat 

Network registriert, der die Patches bereitstellt. 

Der Admin legt eine Zeit in der 

Nacht fest, zu der der Satellite Server im 

RHN nach Updates sucht. 

Inventar in Datenbank 

Der Satellite Server unterhält ein Inventar 

der Software auf jedem Client, das 

in einer Oracle Datenbank gespeichert 

ist, die sich entweder auf dem Satellite 

Server oder einem extra Datenbankserver 

befinden kann. Sobald alle Patches heruntergeladen 

wurden, berechnet der Satellite 

Server, wer welchen Patch braucht. 

Danach erstellt er für jeden Client einen 

Zeitplan. Die eigentliche Installation 

des Patches plant dann der Admin des 

Clients. Damit bietet der Satellite Server 

eine Lösung für Anwender, die eine absolute 

Kontrolle benötigen, über die auf 

ihren Servern eingespielten Sicherheitspackages 

und alle Informationen darüber. 

Er erlaubt Red-Hat-Kunden die größte 

Flexibilität und zugleich Sicherheit beim 

Updaten ihrer Server. 

Der Satellite Server braucht wie bereits 

erwähnt eine Datenbank, die auf einem 

separaten Server oder auf dem Satellite 

Server selbst laufen kann. Beide Optionen 

sind weitgehend identisch, aber 

nicht ganz. Unterschiede ergeben sich 

insbesondere bei den Hardwareanforderungen, 

bei den Installationsschritten 

und bei der Wartung. 

Für die Einbindung des Satellite Servers 

in ein Netzwerk bieten sich drei verschiedenen 

Topologien an: einzelner Satellite 

Server, mehrere Satellite Server, horizontal 

abgestuft und vertikal abgestufter 

Satellite-Proxy. 

Die Single-Server-Topologie mit einem 

einzigen Satellite Server für das gesamte 

Netzwerk zeigt Abbildung 2. Diese Konstellation 

ist ideal für Laborumgebungen, 

eignet sich aber nicht besonders gut, 

wenn das Netz in Subnetze aufgeteilt 

ist, wo einzelne Abteilungen ihre eigenen 

Server warten. Die Single-Server- 

Konfiguration ist vergleichsweise billig 

und leicht zu administrieren, ist aber auf 

eine nicht-hierarchische Netzwerkstruktur 

ausgelegt und skaliert in größeren 

Umgebungen schlecht. 

Bei der Topologie mit mehreren Satellite 

Servern und horizontaler Gliederung, 

sind verschiedene Satellite Server mit 

Abbildung 3: Mehrere Satellite Server mit horizontaler Gliederung der Topologie: Eine Anzahl Server bedient 

jeweils ein Subnetz. 

Abbildung 4: Topologie mit einem zentralen Satellite Server und Proxies bei vertikaler Gliederung. 


Satellite-Server-Systemanforderungen 

n 8 GByte RAM (2 GByte reichen prinzipiell, mit verbundenen Proxies ist der Server dann aber 

sehr langsam). 

n 30 GByte Plattenplatz pro Software-Kanal; eine separate Partition /var/satellite 

n 12 GByte Plattenplatz für die eingebettete Datenbank; eine separate Partition /rhnsat 

n Intel Multicore-Prozessor mit mindestens 2,4 GHz 

n 5 GByte Plattenplatz für RHEL 6.1 

n 10 GByte Plattenplatz für den Cache auf einer separaten Partition /var/cache/rhn 

dem Internet verbunden (Abbildung 

3). Jeder Server wird mit allen anderen 

synchronisiert. Bei dieser Variante hat 

jedes Subnetz oder Projekt seinen eigenen 

Satellite Server. Zusätzlich ist ein 

Failover möglich, falls einer der Server 

ausfällt. Allerdings erhöht diese Variante 

mit vielen Servern die Kosten erheblich, 

denn jeder Server braucht eine eigene 

Lizenz, und das gesamte System ist auch 

wesentlich aufwendiger zu konfigurieren 

und zu warten. 

Mit Proxy 

Die Version Satellite Proxy mit vertikaler 

Gliederung zeigt Abbildung 4. Einem 

einzelnen Satellite Server steht hier eine 

Anzahl von Satellite Proxies in den verschiedenen 

Subnetzen gegenüber. Der 

Proxy-Server fungiert als Pakete-Cache, 

der die erforderliche Bandbreite der 

Verbindung zum RHN-Server reduziert. 

Dabei hat nur der Satellite Server eine 

direkte Internetverbindung. Die Proxy- 

Server reden nur mit den Clients, die sie 

managen, und mit dem Satellite Server. 

Zwar liegen die Pakete nun auf den 

Proxy-Servern, aber die Profile und User- 

Informationen der Clients speichert weiterhin 

der Satellite Server. Der Proxy-Server 

agiert als Vermittler zwischen Client 

und Satellite Server. Sobald Red Hat einen 

Patch freigibt, lädt ihn der Satellite 

Server herunter und prüft, für welches 

Clientsystem er infrage kommt. Dann 

verschiebt er den Patch auf den jeweils 

zuständigen Proxy-Server [3]. 

Auf den Proxies werden nur Paket-Dateien 

gespeichert. Jede Transaktion wird weiter 

durch den Satellite Server authentisiert. 

Der Red Hat Update Agent überprüft die 

GPG-Signatur jedes Pakets, das er vom 

lokalen RHN Proxy Server oder dem Satellite 

Server erhält. Die Signaturen werden 

bei der Installation erzeugt und jedes 

System hat zur Identifikation, eine Kopie 

der Signaturen von Satellite und Proxy- 

Server. Der Proxy Server kann auch so 

konfiguriert werden, dass er neben den 

offiziellen Red-Hat-Paketen zusätzlich 

solche aus privaten Kanälen verwendet. 

Abbildung 5: Realistisches Beispiel einer Proxy-Server-Konfiguration mit vertikaler Gliederung. 



51



Beispielsweise könnte eine Firma ihre 

eigene Software entwickeln, paketieren 

und mit ihrer eigenen GPG-Signatur signieren. 

Die lokalen RHN-Proxies könnten 

dann alle individuellen Systeme mit der 

neuesten Version dieser Software versorgen. 

(Tatsächlich wäre ein vergleichbares 

Szenario auch mit den anderen beiden 

Topologien realisierbar.) 

Empfehlenswert 

Abbildung 6: Das Webinterface des Satellite Servers mit der Übersichtsseite. 

Die vertikal gegliederte Proxy-Topologie 

ist sicher und skalierbar. Sie schont 

gleichzeitig die Bandbreite, weil die benötigten 

Pakete nur einmal aus dem Internet 

heruntergeladen werden müssen, 

und sie vereinfacht die Konfiguration für 

spezielle Architekturen und Betriebssystemversionen. 

Die Proxy-Lizenzen sind 

zudem billiger als komplette Satellite- 

Server-Lizenzen, was Kosten spart. Auf 

der anderen Seite fallen im Vergleich mit 

der Single-Server-Version natürlich mehr 

Lizenzkosten an, und das Personal muss 

trainiert werden, diese Variante zu beherrschen. 

Abbildung 5 illustriert, wie 

eine Firma die Proxy-Server-Topologie 

einsetzen könnte, um Updates und Softwareverteilung 

über mehrere Standorte 

hinweg zu vereinfachen. 

Testresultate 

Abbildung 7: Die Systems-Seite zeigt eine Zusammenfassung zu den verwalteten Systemen. 

Abbildung 8: Die Errata Page zeigt verfügbare Patches. 

Im Zuge der Evaluierung des Satellite Servers 

haben wir den Eindruck gewonnen, 

dass die Dokumentation von Red Hat 

einen guten Überblick verschafft, aber 

nicht zu wörtlich genommen werden 

sollte. Die Handbücher enthalten eine 

Reihe von Fehlern und Auslassungen. 

Außerdem hat Red Hat die Namen aller 

Kommandos von der vorhergehenden zur 

aktuellen Version geändert, aber die Dokumentation 

nicht angepasst. 

Der Kasten „Satellite Server Systemanforderungen“ 

enthält eine Zusammenfassung 

der Anforderungen. Außerdem 

sollte man bedenken, dass für den Satellite 

Server eine Reihe von Ports geöffnet 

und die Firewallregeln dafür entsprechend 

modifiziert werden müssen. Im 

Einzelnen geht es dabei um die Ports 80, 

443 und 4545 eingehend und ausgehend, 

sowie 5222 nur eingehend. Im Fall der 

Konfiguration mit Proxy Servern muss 

außerdem der Port 5369 offen sein. 




Tabelle 1: Kostenvoranschläge (in US-Dollar) 

Produkt Anzahl Händler A Händler B Händler C 

Satellite Server Subscription 1 4423,19 8100,00 8012,09 

Proxy Server Subscription 2 4500,00 3850,00 4006,04 

Management/Provisioning 

Subscription 

Weiter wird eine Quelle für die Zeitsynchronisation 

via NTP benötigt, und der 

zugehörige Port 123 muss konfiguriert 

werden. Der qualifizierte Domänname 

des Servers (FQDN) muss im DNS-System 

registriert sein. 

Red Hat setzt voraus, dass der Satellit 

Server komplett installiert ist, bevor irgendwelche 

spezifischen Sicherheitseinstellungen 

konfiguriert werden. Per 

Abbildung 9: Die Zeitsteuerung für das Einspielen der Patches. 

2 339,78 144,00 307,66 

Summe 9262,97 12094,00 12325,79 

Default sind die folgenden Services abgeschaltet: 

Telnet, FTP und TFTP. Zum 

Einloggen verwendet man SSH. 

Für den Satellite Server 5.4.1 muss sich SE 

Linux im sogenannten Permissive Mode 

befinden im Enforcing Mode kommt es 

zu Fehlern (das soll im nächsten Release 

behoben sein). Für diesen Test lief der Satellite 

Server virtualisiert unter VMware 

oder KVM mit eingebetteter Datenbank. 

Der Satellite Server wird über ein Webinterface 

administriert (Abbildung 6). Sein 

Installationsskript richtet dafür einen 

Apache Webserver 2.2 ein. Abbildung 

6 zeigt die Übersichtsseite, die Aufgaben 

und kritische Systeme zusammenfasst. 

Um zu der Systems-Seite zu wechseln, 

auf der der Administrator die meiste Zeit 

verbringen wird, klickt man auf den Reiter 

„Systems“ (Abbildung 7). 

Administration via Web 

Die Legende an der linken Seite ist wichtig 

für einen Überblick über den Systemstatus. 

Die Icons stehen für spezifische 

Zustände. Im Beispiel kann man erkennen, 

dass der Server SAS-Testing einige 

kritische Patches benötigt, die eingetaktet 

werden müssen. Für detaillierte Information 

klickt man auf den Servernamen 

oder wählt einen der Parameter unter 

»Overview«. Wählt man zum Beispiel die 

Nummer 4 unter »Errata« für den Server 

SAS-Testing, so landet man auf der 

Errata-Seite (Abbildung 8). Hier wählt 

man »Select All« und dann »Apply Errata« 

aus. Auf der nächsten Seite (Abbildung 

9) entscheidet man sich dann für einen 

Zeitpunkt, zu dem der Patch eingespielt 

werden soll, und klickt »Confirm«. 

Abbildung 10 zeigt die beiden jetzt zeitlich 

eingeplanten Patches und zwei mit 

ihnen verbundene Bugfixes. Wieder kann 

man entweder jeden Patch einzeln oder 

»Select all« und dann »Apply Errata« anklicken. 

E 

C13 

Abbildung 10: Eine Zusammenfassung für das eingetaktete Update. 


Admin 


53



Abbildung 11: Die Details-Page zeigt viele wichtige Einzelheiten. 

Eine andere nützliche Zusammenstellung 

von Informationen erscheint, wenn man 

auf »System Details« klickt (Abbildung 

11). Diese Seite zeigt den Typ der verfügbaren 

Updates (Kritisch, nicht-kritisch), 

die IP-Adresse des Servers, die 

Kernelversion und mehr. Klickt man auf 

»Packages« (jeder Text in blauer Farbe 

ist ein Link), erscheinen die verfügbaren 

Updates von Paketen, wie man in 

Abbildung 12 sieht. Die Liste enthält 

alle installierten Pakete, und man kann 

auf einen Paketnamen klicken, um eine 

Beschreibung des Paketinhalts zu bekommen. 

Ein Klick auf den Paketnamen (oder 

auf »Select All«) und danach auf »Install 

Selected Packages« startet schließlich den 

Installationsprozess. 

Lizenzierung 

Red Hats Lizenzierung gleicht eher einem 

Abo-Modell: Man muss die Subskriptions-Gebühr 

jedes Jahr bezahlen, 

solange der Server läuft. Wir haben Kostenvoranschläge 

von drei autorisierten 

Red-Hat-Händlern eingeholt. Tabelle 1 

zeigt die Ergebnisse für eine Lizenz des 

Red Hat Satellite Server plus Lizenzen 

für zwei Proxy Server und Management/ 

Provision-Module. 

Fazit 

Der Satellite Server bietet ein automatisiertes 

Verfahren, um Patches auf Server 

einzuspielen. Es kann diesen ansonsten 

langwierigen und zeitintensiven Prozess 

enorm vereinfachen. Nichtsdestotrotz 

müssen auch weiterhin alle Patches vorher 

getestet werden, doch ist das für den 

Admin nun viel einfacher. 

Während unserer Tests des Satellite Servers 

stießen wir auf ein IDC-Whitepaper 

mit dem Titel „Linux Management mit 

Red Hat Network Satellite: Measuring 

Business Impact and ROI“ von Tim Grieser, 

Randy Perry und Eric Hatcher. Die 

Autoren kommen zu dem Schluss, „… 

auf der Grundlage von Interviews mit IT 

Managern aus 10 Unternehmen, die Red 

Hat Network Satellite einsetzen, ergibt 

sich im Durchschnitt ein ROI von 338 

Prozent, es wird also das Dreifache der 

Investitionskosten erwirtschaftet. Und 

das binnen weniger als 5 Monaten.“ 

Wir empfehlen die Topologie mit Proxy- 

Servern und vertikaler Gliederung. Diese 

Lösung garantiert eine hohe Granularität 

beim Einspielen der Patches. Auch die 

Implementierung des Satellite Servers in 

einer Virtualisierungsumgebung ist empfehlenswert 

(infrage kommen KVM oder 

VMware). Das spart deutlich Kosten und 

wird von Red Hat auch vollständig unterstützt. 

(jcb)) 

n 

Abbildung 12: Die Seite »Packages« zeigt, welche Pakete veraltet sind. 

Infos 

[1] Red Hat Network Satellite documentation: 

[https:// access. redhat. com/ knowledge/ 

docs/ Red_Hat_Network_Satellite/] 

[2] „The Red Hat Enterprise Linux 

Advantage“-Whitepaper: [http:// www. 

redhat. com/ f/ pdf/ rhel/ RHEL6_Advantage_ 

WP. pdf] 

[3] Scott Carpenter:„Patch Management for 

the Real World A Managers Guide“ [http:// 

www. whitepapersdb. com/ whitepaper/ 

9083/ patch‐management‐for‐the‐real‐worl 

d‐a‐managers‐guide] 

[4] Linux Management with Red „Hat Network 

Satellite: Measuring Business Impact 

and ROI“: [www. redhat. com/ f/ pdf/ rhn/ 

IDC_RHN_approach. pdf] 


Know-how 

Windows Server 2012 

© Jaroslav Machacek, 123RF 

Die 12 besten Tricks für Windows Server 2012 

Schatztruhe 

Anwender von Windows Server 2012 profitieren von zahlreichen Neuerungen, 

vor allem in den Bereichen Virtualisierung, Hochverfügbarkeit 

und Storage. Wir zeigen Ihnen einige Tricks, die den Umgang mit dem 

neuen System deutlich erleichtern. Thomas Joos 

Während sich die Anwender noch um 

die Usability von Windows 8 streiten, 

müssen sich Administratoren Gedanken 

um die Nutzung von Windows Server 

2012 machen, der entweder auch gekachelt 

daherkommt oder auf Wunsch 

auch ganz ohne GUI. Darunter hat die 

neue Windows-Server-Variante Schätze 

zu bieten, die die folgenden Tricks an die 

Oberfläche heben. 

E Server-Manager 

effizient nutzen 

Bereits mit Windows Server 2008 R2 

konnten Sie Server teilweise mit dem 

Server-Manager im Netzwerk verwalten. 

Das war allerdings nur sehr rudimentär 

möglich. So kann der Server-Manager in 

Windows Server 2008 R2 zum Beispiel 

keine Rollen über das Netzwerk installieren, 

und auch die Verwaltung der Serverrollen 

ist nicht sehr effizient gelöst. Hier 

ist Windows Server 2012 deutlich besser. 

In Windows Server 2012 ist es zum Beispiel 

möglich, Serverrollen und Features 

über das Netzwerk auf anderen Servern 

zu installieren (Abbildung 1). 

Den Assistenten zur Installation von 

Serverrollen und Features hat Microsoft 

zu einem einzelnen Assistenten zusammengefasst. 

So lassen sich diese einfacher 

und schneller installieren, da nur 

ein Installationsvorgang notwendig ist. 

Installierte Serverrollen und die entsprechenden 

Server zeigt der Server-Manager 

automatisch gruppiert an. Verwaltungswerkzeuge 

listet der Server-Manager direkt 

über das Tools-Menü an. Sie können 

das Toolsmenü sogar bearbeiten. Dazu 

finden Sie in der Systemsteuerung den 

Bereich »System und Sicherheit\Verwaltung«. 

Alle Verknüpfungen in diesem 

Bereich zeigt der Server-Manager im 

Menü »Tools« an. Sie können an dieser 

Stelle weitere Verknüpfungen hinzufügen, 

Verknüpfungen entfernen und sogar 

eine Ordnerstruktur erstellen. Um im 

Server-Manager in Windows Server 2012 

weitere Server anzubinden, klicken Sie 

auf »Verwalten« und dann auf »Server 

hinzufügen«. Im Fenster können Sie anschließend 

nach Servern suchen, um sie 

im lokalen Server-Manager zu verwalten. 

Auf diesem Weg erstellen Sie auch 

eigene Servergruppen, die Sie im Server- 

Manager zusammenfassen. Von diesen 

Gruppen können Sie dann Ereignismeldungen 

anzeigen lassen. Sie können nur 

Serverrollen und ‐Features installieren, 

wenn Sie den entsprechenden Server vorher 

angebunden haben. 

E NIC-Teaming 

Windows Server 2012 kann ohne Zusatzwerkzeug 

bis zu 32 kompatible Netzwerkkarten 

zu Teams zusammenfassen. 

Sie können während der Einrichtung auswählen, 

ob Sie einzelne Adapter im Team 

als Standby-Adapter nutzen wollen, also 

zur Ausfallsicherheit, oder ob Sie die Geschwindigkeit 

der Adapter zusammenfassen 

wollen, um die Leistung zu erhöhen. 

Sie können nur Ethernet-Verbindungen 

zu Teams zusammenfassen. Bluetooth 


kinderleicht 

+ ausgereift 

IPTAM ® PBX VoiP Telefonanlage 

mit bester ISDN-Integration 

Abbildung 1: Mit dem Server-Manager in Windows Server 2012 verwalten Sie alle Rollen und Features in einer 

übersichtlichen Oberfläche. 

oder WLAN gehören nicht zu den unterstützten 

Funktionen. Außerdem müssen 

alle Netzwerkkarten mit der gleichen Geschwindigkeit 

angeschlossen sein. 

Um ein NIC-Team zu erstellen, starten 

Sie den Server-Manager, und klicken Sie 

auf »Lokaler Server«. Standardmäßig ist 

das Teaming deaktiviert. Um die Funktion 

zu aktivieren, klicken Sie auf den 

Link bei »Deaktiviert«. Anschließend öffnet 

sich ein neues Fenster. Hier sehen 

Sie im unteren rechten Bereich, welche 

Netzwerkadapter im Server kompatibel 

zum NIC-Teaming sind. Um ein Team 

zu erstellen, klicken Sie mit der rechten 

Maustaste in das Fenster bei »Adapter 

und Schnittstellen« und wählen »Zum 

neuen Team hinzufügen«. Über den Link 

»Weitere Eigenschaften« können Sie zusätzliche 

Einstellungen vornehmen, um 

das NIC-Team zu konfigurieren. Windows 

Server 2012 verwendet als MAC-Adresse 

des Teams die MAC-Adresse der primären 

Netzwerkkarte. Auch Core-Server unterstützen 

NIC-Teams. Hier können Sie die 

Einrichtung entweder über den Server- 

Manager von einem anderen Server aus 

durchführen, oder Sie verwenden die 

Powershell. 

In der Powershell können Sie sich mit 

dem Befehl »Get‐NetAdapter« die einzelnen 

möglichen Team-Adapter anzeigen 

lassen, und mit »Enable‐NetAdapter« 

beziehungsweise »Disable‐NetAdapter« 

Kinderleichte Administration 

n per CD auf einem Server 

Ihrer Wahl 

n oder als Fertiggerät 

(Appliance) 

n Vorbildliche Dokumentation: 

www.iptam.com/wiki/ 

Ausgereifte Funktionalität 

n Bequeme Bedienung 

über Web-Oberfläche 

n Einspielen von Patches, 

Lizenzerweiterung, ISDN- 

Konfiguration mit 3 Klicks 

n Und natürlich alle gängigen 

Funktionen: Voicemail, Instant 

Messaging Server, Fax-Server, 

Konferenzräume, Warteschlangen, 

Sprachmenüs, Klingelgruppen, 

Durchsagefunktion, Konfiguration 

der Telefone über die Anlage .... 

selber 

testen! 

Die IPTAM PBX 5 

kostenlos 

downloaden: 

www.iptam.com 

Demosystem 

online testen: 

www.iptam.com/demo 

Abbildung 2: Anzeigen des Status des NIC-Teamings. 


www.iptam.com 


57

Know-how 


einzelne Adapter aktivieren oder deaktivieren. 

Alle Commandlets für die Verwaltung von 

NIC-Teams lassen Sie sich mit »Get‐Command 

‐Module NetLbfo« anzeigen. Um 

ein neues Team zu erstellen, verwenden 

Sie das Commandlet »New‐NetLbfoTeam 

Teamname Netzwerkkarten«. Die Netzwerkkarten 

werden hierbei durch Kommas 

getrennt aufgeführt. Windows Server 

2012 entfernt die IP-Bindung von den 

physischen Netzwerkkarten und verbindet 

sie mit dem neuen virtuellen Adapter, 

den der Assistent für das Team erstellt. 

Sie sehen den Status des Teams, wenn 

Sie im Server-Manager in der Kategorie 

»Lokaler Server« bei »NIC‐Teamvorgang« 

auf den Link »Aktiviert« klicken (Abbildung 

2). 

Werden das Team und die verbundenen 

Karten als »Aktiv« gekennzeichnet, passen 

Sie die Netzwerkeinstellungen des 

Teams an. Dazu rufen Sie die Adaptereinstellungen 

auf, indem Sie »ncpa.cpl« 

auf der Startseite eingeben. Hier sehen 

Sie das neue Team. Sie können auf Hyper-V-Hosts 

mehrere virtuelle Switches 

auf Basis der verschiedenen physischen 

Netzwerkkarten erstellen und innerhalb 

von virtuellen Servern dann NIC-Teams 

erstellen. Diese verwenden die einzelnen 

virtuellen Switches des Hyper-V-Hosts als 

Grundlage. 

E VDC – Klonen und 

Snapshots 

Mit Windows Server 2012 hat Microsoft 

den Betrieb von virtuellen Domänencontrollern 

optimiert. Im Gegensatz zu 

Vorgängerversionen stellen Snapshots 

und geklonte Domänencontroller keine 

Gefahr mehr für das komplette Active Directory 

dar. Damit Sie Domänencontroller 

optimal virtualisieren und auch klonen 

können, müssen mindestens folgende 

Bedingungen eingehalten werden. 

Der PDC-Emulator muss sich auf einem 

Domänencontroller mit Windows Server 

2012 befinden. Den PDC-Emulator 

können Sie nicht klonen, er muss während 

des Klonvorgangs immer 

verfügbar sein. Die Domäne 

muss bereits über mindestens 

zwei Domänencontroller mit 

Windows Server 2012 verfügen, 

da Sie nur den zweiten 

klonen können. Der erste stellt den PDC- 

Emulator zur Verfügung. Die Virtualisierungslösung 

muss diese neue Technik 

unterstützen (VM-Generation ID). Aktuell 

ist das nur Hyper-V in Windows 

Server 2012. 

Ob die von Ihnen eingesetzte Virtualisierungslösung 

die neue VM-Generation 

ID unterstützt, erkennen Sie im Geräte- 

Manager eines virtualisierten Servers 

mit Windows Server 2012. Bei den Systemgeräten 

muss der Treiber »Microsoft 

Hyper‐V‐Generierungszähler (Microsoft 

Hyper‐V Generation Counter)« mit der 

Treiberdatei »vmgencounter.sys« existieren. 

Bevor Sie einen virtuellen Domänencontroller 

klonen, müssen Sie auf dem Server 

das Cmdlet »Get‐ADDCCloningExcludedApplicationList« 

ausführen. Das Cmdlet 

überprüft, ob es auf dem virtuellen Server 

Anwendungen gibt, die das Klonen 

nicht unterstützen. Entdeckt das Cmdlet 

nicht-kompatible Dienste, zum Beispiel 

den DHCP-Dienst oder einen installierten 

Virenscanner, erhalten Sie entsprechende 

Informationen. Die Konfiguration für das 

Klonen nehmen Sie in der Datei »DC- 

CloneConfig.xml« vor. Die Beispieldatei 

»SampleDCCloneConfig.xml« finden Sie 

im Ordner »C:\Windows\System32«. 

Nachdem Sie die Datei »DCCloneConfig. 

xml« erstellt haben, kopieren Sie diese 

in den Ordner mit der Active Directory- 

Datenbank, also normalerweise in den 

Ordner »C:\Windows\NTDS«. 

Nicht für alle 

Abbildung 3: Windows Server 2012 klont Active Directory auf dem neuen 

virtuellen Domänencontroller. 

Sie können nur Quelldomänencontroller 

klonen, die Mitglied der Gruppe »Klonbare 

Domänencontroller« in Active Directory 

sind. Sie können außerdem nur 

Domänencontroller klonen, die nicht eingeschaltet 

sind. Das heißt, Sie müssen 

den entsprechenden Domänencontroller 

herunterfahren, bevor Sie ihn klonen 

können. Bevor Sie den neuen Domänencontroller 

in Active Directory aufnehmen 

können, müssen Sie die durch den Klonvorgang 

angepasste Datei »DCCloneConfig.xml« 

vom Quellcomputer in den Ordner 

mit der Active Directory-Datenbank, 

also normalerweise in den Ordner »C:\ 

Windows\NTDS« vom Quell- auf den 

Zielcomputer kopieren. Windows hat den 

Namen der Datei angepasst, um zu zeigen, 

dass ein Klonvorgang stattgefunden 

hat. Ändern Sie den Namen wieder um 

zu »DCCloneConfig.xml«. 

Anschließend erstellen Sie entweder einen 

neuen virtuellen Computer und verwenden 

die kopierte Festplatte, oder Sie 

importieren den exportierten Server mit 

dem Hyper-V-Manager oder der Power- 

Shell. Beim Importieren wählen Sie die 

Option »Virtuellen Computer kopieren« 

aus. Starten Sie den Domänencontroller, 

liest er die Datei »DCCloneConfig.xml« 

ein und bereitet sich selbst für das Klonen 

vor. Während des Windows-Starts 

erhalten Sie auch eine entsprechende 

Meldung (Abbildung 3). 

E Namen, Ansicht und 

IE anpassen 

Viele Aufgaben, die zur Grundkonfiguration 

des Servers gehören, nehmen Sie 

direkt im Server-Manager vor. Dazu klicken 

Sie auf »Lokaler Server«. Im mittleren 

Bereich sehen Sie die verschiedenen 

Aufgaben, deren Assistenten Sie über 

einen Klick auf den entsprechenden Link 

erreichen. 

Über das Menü Ansicht deaktivieren Sie 

die »Kachel für Willkommen«, und über 

»Verwalten/Server‐Manager‐Eigenschaften« 

aktivieren Sie die Option »Server‐Manager 

beim Anmelden nicht automatisch 

starten«. Für die Installation von Treibern 

benötigen Sie normalerweise den Internet 

Explorer. Bei Windows Server 2012 

ist automatisch die verstärkte Sicherheit 

des Internet Explorers aktiv, was beim 

Herunterladen von Treibern durchaus 

stören kann. 

Sie können die erweiterte Sicherheit des 

Internet Explorers im Server-Manager deaktivieren: 

Öffnen Sie den Server-Manager. 

Klicken Sie auf der linken Seite auf 

»Lokaler Server«. Klicken Sie im rechten 

Bereich im Abschnitt Eigenschaften 

neben »Verstärkte 

Sicherheitskonfiguration für 

IE« auf den Link »Ein«. Deaktivieren 

Sie im daraufhin 

geöffneten Dialogfeld die Op- 



Know-how 

tion für alle Benutzer oder nur für Administratoren. 

E Windows Server 2012 

mit Win 8 verwalten 

Um Windows Server 2012 mit Windows 

8 zu verwalten, bietet Microsoft die Remoteserver-Verwaltungstools 

(Remote 

Server Administration Tools, RSAT) zum 

Download an. Mit den Tools installieren 

Sie auf einer Arbeitsstation mit Windows 

8 alle Verwaltungsprogramme die zur 

Verwaltung von Windows Server 2012 

notwendig sind. 

Neben den verschiedenen Verwaltungstools 

der Serverrollen integriert der Installations-Assistent 

von RSAT auch den 

neuen Server-Manager von Windows 

Server 2012 in Windows 8. Über den 

Server-Manager binden Sie die verschiedenen 

Server im Netzwerk an, auf denen 

Windows Server 2012 installiert ist. Sie 

können mit dem Server-Manager auf diesem 

Weg auch über Windows 8-Arbeitsstationen 

aus Serverrollen auf Servern 

installieren. 

Die Remoteserver-Verwaltungstools für 

Windows 8 umfassen Server-Manager, 

Verwaltungstools der Serverrollen und 

Features von Windows Server 2012, PowerShell 

XE „PowerShell“ ‐Cmdlets und 

Befehlszeilentools für die Verwaltung von 

Rollen und Features. Die Remoteserver- 

Verwaltungstools laden Sie als .msu-Datei 

direkt im Downloadcenter [1] herunter. 

Um im Server-Manager in Windows Server 

2012 und Windows 8 weitere Server 

anzubinden, klicken Sie auf »Verwalten« 

und dann auf »Server hinzufügen«. Im 

Fenster können Sie anschließend nach 

Servern suchen, um sie im lokalen Server-Manager 

zu verwalten. 

E Core-Server, Minimal 

Server Interface, GUI 

stallation des Core-Server-Modus auswählen. 

Nach der Installation lassen sich 

in Windows Server 2012 aber problemlos 

die Verwaltungstools und die grafische 

Oberfläche installieren. 

Neu in Windows Server 2012, neben der 

Möglichkeit, die grafischen Verwaltungstools 

auf Core-Servern zu installieren, 

ist das »Server Minimal Interface«, auf 

deutschen Servern als »minimale Serverschnittstelle« 

bezeichnet. Dabei handelt 

es sich um eine Installation der wichtigsten 

Verwaltungsprogramme für die 

grafische Oberfläche, aber keine Zusatzanwendungen 

wie Media Player, Explorer 

und Internet Explorer. Auch der Desktop 

fehlt bei dieser Option. 

Viele Programme aus der Systemsteuerung 

und die meisten Verwaltungsprogramme 

für Serverrollen und Features 

funktionieren. Bei der minimalen Serverschnittstelle 

(Minimal Server Interface) 

handelt es sich um eine Zwischenstufe 

zwischen Core-Server und Server mit 

grafischer Oberfläche, nur ohne Explorer 

und Internet Explorer 10. 

Die grafische Oberfläche deinstallieren 

Sie entweder im Server-Manager oder der 

PowerShell. Im Server-Manager verwenden 

Sie »Verwalten/Rollen und Features 

entfernen«. Auf der Seite »Features entfernen« 

stehen im Bereich »Benutzeroberflächen 

und Infrastruktur« drei Optionen 

zur Verfügung: »Tools und Infrastruktur 

für die grafische Verwaltung« – hierbei 

handelt es sich um die Verwaltungskonsolen 

der wichtigsten grafischen Werkzeuge 

auf dem Server. Ist nur dieses Feature 

installiert und nicht die Features »Grafische 

Shell für Server und Desktopdarstellung«, 

handelt es sich um einen Server 

mit dem Minimal Server Interface. »Desktopdarstellung« 

– dieses Feature ist vor 

allem für Remotedesktop-Server gedacht. 

Es wandelt die Oberfläche des Servers 

in eine Windows-8-Oberfläche um und 

bietet Tools wie Media Player, Fotoverwaltung, 

Themes und mehr. »Grafische 

Shell für Server« – dieses Feature deinstallieren 

Sie zusammen mit der Desktopdarstellung, 

um das Server Minimal 

Interface zu erhalten. Sie entfernen dabei 

auch den Explorer (ehemals Windows 

Explorer) und den Internet Explorer vom 

Server. Sie können dieses Feature auch 

in der Powershell mit dem Befehl »Uninstall‐WindowsFeature 

Server‐Gui‐Shell« 

entfernen. 

Installieren Sie einen Core-Server, fehlen 

auf dem Server auch die Binärdateien, 

um die grafische Oberfläche zu installieren. 

Sie müssen zur Installation entweder 

eine Internetverbindung für den 

Server konfigurieren, damit dieser die 

benötigten Daten von Windows-Update 

herunterladen kann, oder Sie müssen den 

Ordner mit den Windows Server 2012-Installationsdateien 

angeben. 

Die Installation können Sie auf Core- 

Servern mit der PowerShell und dem 

Befehl »Install‐WindowsFeature Server‐Gui‐Mgmt‐Infra« 

durchführen, oder 

Sie verbinden sich mit dem Server über 

den Server-Manager von einem Server im 

Netzwerk aus. Alternativ verwenden Sie 

die folgenden Befehle in der Powershell: 

Jede Installation von Windows Server 

2012 besteht als Grundlage aus einem 

Core-Server. Dieser bietet alle wesentlichen 

Verwaltungsprogramme der Eingabeaufforderung 

und der. Es fehlen alle 

grafischen Verwaltungstools, Sie müssen 

den Server über andere Server oder mit 

den Remoteserver-Verwaltungstools von 

Windows 8 aus verwalten. Während der 

Installation können Sie auch nur die In- 

Abbildung 4: Virtuelle Server können Sie kostenlos sichern. 


Admin 


59

Know-how 


Import‐Module Dism 

Enable‐WindowsOptionalFeature ‐online U 

‐Featurename ServerCore‐FullServer,Server‐U 

Gui‐Shell,Server‐Gui‐Mgmt 

Alternativ kann der Administrator mit 

dem folgenden Befehl die grafische Oberfläche 

installieren: 

Dism /online /enable‐feature /featurename:U 

ServerCore‐FullServer /featurename:Server‐U 

Gui‐Shell /featurename:Server‐Gui‐Mgmt 

E Virtuelle Server 

kostenlos sichern 

Der bekannte Hersteller für die Sicherung 

von virtuellen Servern, Veeam, bietet 

ein kostenloses Tool, mit dem sich 

die Datensicherung virtueller Exchange- 

Server vollkommen kostenlos auslesen 

und einzelne Objekte wiederherstellen 

lassen (Single-Item-Recovery). Auch herkömmliche 

Server können Sie auf diesem 

Weg sichern und wiederherstellen. Basis 

des Tools ist das Produkt Veeam Backup 

Free Edition [2]. Mit der kostenlosen 

Sicherungssoftware lassen sich virtuelle 

Server ohne Downtime sichern, nicht nur 

virtuelle Exchange-Server. 

Die Software unterstützt VMware und Microsoft 

Hyper-V. Mit Veeam Backup Free 

Edition können Sie sogar System Center 

Virtual Machine Manager 2008 R2/2012 

anbinden und auch Hyper-V-Cluster integrieren. 

Binden Sie einen SCVMM-Server 

an Veeam Backup an, kann die Software 

alle angebundenen Server automatisch 

einlesen und die darauf gespeicherten 

virtuellen Server sichern (Abbildung 4). 

Die Software sichert nicht die einzelnen 

Virtualisierungshosts, sondern ist auf die 

Sicherung der virtuellen Server spezialisiert. 

E Replikation in der 

Powershell testen 

Den Status der Active-Directory-Replikation 

erfahren Sie auch in der Powershell. 

Dazu verwenden Sie das Commandlet 

»Get‐ADReplicationUpToDatenessVector- 

Table Servername«. Eine Liste aller Server 

liefert: 

Um sich die einzelnen Standorte und die 

Domänencontroller der Standorte anzuzeigen, 

verwenden Sie die beiden Commandlets: 

Get‐ADReplicationSite XE "Get‐U 

ADReplicationSite" ‐Filter * | ft NameU 

Get‐ADDomainController ‐Filter * | ft U 

Hostname,Site. 

Sie können die Replikationsverbindungen 

auch in der Powershell anzeigen. Dazu 

verwenden Sie den Befehl »get‐adreplicationconnection«. 

Sie können sich in 

der PowerShell auch ausführliche Informationen 

zu den einzelnen Standorten 

anzeigen lassen. Dazu verwenden Sie 

den Befehl »Get‐ADReplicationSite ‐Filter 

*«. Weitere interessante Commandlets in 

diesem Bereich sind: 

Get‐ADReplicationPartnerMetadata XE U 

"Get‐ADReplicationPartnerMetadata" 

Get‐ADReplicationFailure XE U 

"Get‐ADReplicationFailure" 

Get‐ADReplicationQueueOperation 

E Hyper-V-Replikation 

nutzen 

Mit Hyper-V-Replica lassen sich in Windows 

Server 2012 und Hyper-V Server 

2012 virtuelle Festplatten und komplette 

virtuelle Server asynchron zwischen verschiedenen 

Hyper-V-Hosts im Netzwerk 

replizieren und synchronisieren. Ein Cluster 

ist nicht notwendig. Die Replikationen 

lassen sich manuell, automatisiert oder 

nach einem Zeitplan ausführen. Fällt ein 

Hyper-V-Host aus, lassen sich die replizierten 

Server online schalten. 

Damit ein Hyper-V-Host für Replikate 

zur Verfügung steht, müssen Sie auf 

dem entsprechenden Server in den »Hyper‐V‐Einstellungen« 

im Bereich »Replikationskonfiguration« 

diese Funktion 

zunächst aktivieren und konfigurieren. 

Sie legen hier den Datenverkehr und die 

Server fest, von denen der aktuelle Server 

Replikate entgegennimmt. Daher müssen 

Sie diese Funktion zunächst auf allen 

Hyper-V-Hosts aktivieren. Setzen Sie Hyper-V 

Server 2012 ein, können Sie diesen 

Server auch über den Hyper-V-Manager 

von einem anderen Server aus verwalten 

und auf diesem Weg die gleichen Einstellungen 

vornehmen. Hier gibt es keinerlei 

Unterschiede zu den kostenpflichtigen 

Editionen von Windows Server 2012. 

Achten Sie darauf, noch die Regel in der 

erweiterten Konfiguration der Firewall 

(»wf.msc«) für »Hyper‐V‐Replica« zu aktivieren. 

Diese hat die Bezeichnung »Hyper‐V‐Replikat 

HTTP‐Listener«. Es gibt 

auch einen Listener für HTTPS. 

Um einen virtuellen Server auf einen anderen 

Hyper-V-Host mit Windows Server 

2012 oder Hyper-V Server 2012 zu replizieren, 

klicken Sie nach der Konfiguration 

der Hosts mit der rechten Maustaste 

auf den entsprechenden virtuellen Server 

und wählen Replikation aktivieren. Es 

Get‐ADReplicationUpToDatenessVectorTableU 

* | sort Partner,Server | ft 

Partner,Server, UsnFilter 

Abbildung 5: Mit Hyper-V-Replica replizieren Sie virtuelle Server zwischen Hosts. 



Know-how 

Abbildung 6: Konfigurieren der Failoverbeziehung in Windows 

Server 2012 stellt DHCP ausfallsicher zur Verfügung. 

startet ein Assistent, in dem Sie festlegen, 

wie Sie den ausgewählten Server vom 

Quellserver auf den Zielserver replizieren. 

Der virtuelle Server auf dem Quellserver 

bleibt dabei erhalten. 

Im Assistenten legen Sie außerdem zunächst 

den Zielserver und anschließend 

den Authentifizierungstyp fest. Welche 

Authentifizierung der Zielserver akzeptiert, 

bestimmen Sie wiederum auf dem 

Zielserver in den Hyper-V-Einstellungen 

über »Replikationskonfiguration«. Außerdem 

steuern Sie im Assistenten, welche 

virtuellen Festplatten Sie replizieren wollen. 

Damit die Replikation funktioniert, 

müssen Sie auf dem Zielserver in den 

erweiterten Einstellungen der Windows- 

Firewall (»wf.msc«) die Regeln für den 

HTTP-Listener oder den HTTPS-Listener 

aktivieren, je nachdem, welchen Datenverkehr 

Sie verwenden wollen. Die 

Regeln sind bereits angelegt, aber noch 

nicht aktiviert. 

E Failover mit Hyper-V- 

Replica 

Der Vorteil von Hyper-V-Replica ist, dass 

Sie bei Ausfall eines Servers ein Failover 

durchführen können. Dazu klicken Sie 

den entsprechenden virtuellen Server, 

den Sie repliziert haben, im Hyper-V- 

Manager an und wählen im Kontextmenü 

»Replikation | Failover« (Abbildung 5). 

Sie können auch ein geplantes Failover 

starten. In diesem Fall starten Sie das 

Failover vom Server aus, auf dem Sie die 

Quell-VM betreiben. Anschließend wählen 

Sie aus, zu welchem Wiederherstellungspunkt 

Sie den Failover durchführen 

wollen und können den Failover starten. 

Das funktioniert aber nur, wenn die 

Quell-VM auch ausgeschaltet ist. Während 

des Failovers startet der Assistent 

den replizierten Server, der 

im Netzwerk dann zur Verfügung 

steht, genau wie die 

Quell-VM. 

Der Vorteil bei einem geplanten 

Failover – vom Quell- 

Hyper-V-Host aus – ist, dass 

Hyper-V noch nicht replizierte 

Änderungen an den Zielserver 

senden kann, sodass dieser 

über den neuesten Stand verfügt. 

Haben Sie ein geplantes 

Failover durchgeführt, ist der 

alte Quell-VM später die neue Ziel-VM, 

und die alte Ziel-VM die neue Quell-VM 

für die Replikation. Das heißt, Sie können 

diesen Vorgang auch wieder umkehren. 

E DHCP für Failover 

konfigurieren 

DHCP-Failover in Windows Server 2012 

ermöglicht die Bereitstellung einer ausfallsicheren 

DHCP-Serverstruktur auch 

ohne Cluster. DHCP-Failover unterstützt 

zwei Server mit IPv4-Konfiguration. Die 

Server können auch Mitglied einer Arbeitsgruppe 

sein, eine Domänenmitgliedschaft 

ist nicht unbedingt erforderlich. 

Mit dem DHCP-Failover-Feature können 

zwei DHCP-Server IP-Adressen und Optionskonfiguration 

für dasselbe Subnetz 

oder denselben Bereich bereitstellen. 

Zwischen den zwei DHCP-Servern werden 

Lease-Informationen repliziert. Es 

ist auch möglich, das Failover in einer 

Lastausgleichskonfiguration zu konfigurieren, 

in der Clientanforderungen auf die 

zwei Server verteilt sind. 

Öffnen Sie auf dem DHCP-Server die 

DHCP-Konsole, klicken Sie mit der rechten 

Maustaste auf den DHCP-Bereich den 

Sie ausfallsicher betreiben wollen, und 

klicken Sie dann auf »Failover konfigurieren«. 

Geben Sie auf der zweiten Seite 

den Partnerserver, und klicken Sie dann 

auf »Weiter«. Legen Sie auch einen gemeinsamen 

geheimen Schlüssel für diese 

Failover-Beziehung fest. Sie können hier 

auch den Modus auswählen, mit dem 

Sie die Ausfallsicherheit verwenden wollen. 

Sie können Lastenausgleich oder Hot 

Standby auswählen. Standardmäßig ist 

»Lastenausgleich« ausgewählt. Damit teilen 

sich die Server die Anfragen. 

Nachdem Sie die Einrichtung angeschlossen 

haben, können Sie das Failover in 

den Eigenschaften des IP-Bereiches auf 

der Registerkarte »Failover« anzeigen 


E iSCSI-Ziele über 

virtuelle Disks anbieten 

Windows Server 2012 kann nicht nur auf 

iSCSI-Ziele zugreifen, sondern kann auch 

selbst virtuelle Festplatten als iSCSI-Ziel 

im Netzwerk zur Verfügung stellen. Dazu 

müssen Sie über den Server-Manager mit 

»Verwalten/Rollen und Features hinzufügen« 

den Rollendienst »iSCSI‐Zielserver« 

über »Datei‐ und Speicherdienste/Dateiund 

iSCSI‐Dienste installieren«. 

Nach der Installation des Rollendienstes 

können Sie über den Server-Manager 

und der Auswahl von »Datei‐/Speicherdienste/iSCSI« 

virtuelle Festplatten erstellen, 

die als iSCSI-Ziel im Netzwerk konfiguriert 

werden können. Sie können über 

den Assistenten, wie überall im Server- 

Manager, auch auf anderen Servern im 

Netzwerk virtuelle iSCSI-Ziele erstellen. 

Damit das funktioniert, muss auf dem 

entsprechenden Server der Rollendienst 

iSCSI-Zielserver installiert sein. 

Im Rahmen der Einrichtung legen Sie die 

Größe und den Speicherort der VHD(X)- 

Datei fest. Außerdem können Sie über 

den Assistenten steuern, welche Server 

im Netzwerk auf das iSCSI-Ziel zugreifen 

dürfen. Mit einem iSCSI-Ziel können Sie 

auch mehrere virtuelle iSCSI-Festplatten 

zur Verfügung stellen. Nachdem Sie die 

virtuellen Festplatten erstellt haben, können 

Sie über das Kontextmenü die Einstellungen 

ändern. (ofr) 

n 

Infos 

[1] Remoteserver-Verwaltungstools für Windows 

8: 

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

download/ details. aspx? id=28972] 

[2] Veeam Backup Free Edition für VMware 

und Hyper-V: [http:// www. veeam. com/ 

free‐backup] 

Der Autor 

Thomas Joos ist freiberuflicher IT-Consultant und 

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

Projekten schreibt er praxisnahe Fachbücher 

und Fachartikel rund um Windows und andere 

Microsoft-Themen. Online trifft man ihn unter 

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


Admin 


61

Know-how 

Prey 

© rioblanco, 123RF 

Prey lokalisiert gestohlene Laptops und Mobiltelefone 

Schwere Beute 

Das Programm Prey überprüft regelmäßig den Status von Mobiltelefonen 

und Laptops. Meldet der Benutzer das Gerät als gestohlen, versucht das 

Tool, seinen Aufenthaltsort zu ermitteln und Spuren zu sichern. Oliver Frommel 

Selbst auf den besten Open-Source-Konferenzen 

kommt es vor: Man lässt seine 

Tasche einen Moment aus den Auge, und 

schon ist sie weg. Und damit auch das 

schöne neue Macbook, auf dem in unzähligen 

Stunden Ubuntu installiert und 

so konfiguriert wurde, dass sogar die 

Sondertasten alle richtig funktionierten. 

Unschuldig sind dabei meist die anderen 

Konferenzteilnehmer, denn professionelle 

Diebe wissen um die hohe Gerätedichte 

auf solchen Veranstaltungen und gehen 

dort gezielt auf die Suche nach Opfern. 

Deshalb gilt es auch wachsam zu sein, 

selbst wenn man sich von gleichgesinnten 

Gutmenschen umgeben glaubt. 

Das alles hilft aber nichts mehr, wenn die 

Maschine erst einmal weg ist. Was dann 

allerdings noch helfen kann, ist ein kleines 

Programm namens Prey [1], das aber 

auch schon installiert sein muss, bevor 

der Schaden entstanden ist. Kurz gesagt 

läuft Prey regelmäßig auf dem Computer 

und tut einfach nichts, solange ein 

paar Bedingungen erfüllt sind, die der 

Anwender festlegt. Meldet er das Gerät 

als gestohlen, liest Prey diesen Status 

vom Server und handelt entsprechend: 

Es gibt seinen Standort durch, speichert 

einen Screenshot und nimmt im Optimalfall 

ein Foto des Diebs mit der Laptopkamera 

auf. 

Viele Plattformen 

Los geht es damit, die Prey-Clientsoftware 

auf dem eigenen Gerät zu installieren. 

Pakete gibt es für Windows, Mac 

OS X, Linux allgemein und Ubuntu sowie 

Mobilgeräte mit iOS und Android. 

Unter Ubuntu installieren Sie das Paket 

mit dem Paketmanager mit »sudo dpkg ‐i 

prey_0.5.3‐ubuntu2_all.deb«. Der Befehl 

»apt‐get ‐f install« löst dann die dadurch 

entstandenen Abhängigkeiten auf und 

installiert die nötigen Pakete aus dem 

Ubuntu-Repository nach. 

Prey geht davon aus, dass auf dem zu bewachenden 

Rechner ein grafischer Desktop 

installiert ist, zum Beispiel Gnome. 

Dann findet sich nach der Installation 

ein grafisches Konfigurationsprogramm, 

der Prey Configurator, im Menü »Applications 

| System Tools« (Abbildung 1). Auf 

der Kommandozeile lässt es sich per »/ 

usr/share/prey/platform/linux/prey‐config.py« 

starten. Dummerweise funktioniert 

es nicht mit »sudo«, Sie müssen 

also wirklich das Passwort des Benutzers 

»root« eingeben (und dies vorher gegebenenfalls 

erst erstellen) oder zum Beispiel 

mit »sudo su« in einem Terminal in den 

Root-Account wechseln. 

Bei der Default-Konfiguration verlangt 

Prey Root-Rechte und die Konfigurationsdatei 

»config« in »/usr/share/prey« 

ist entsprechend geschützt. Sie lässt sich 

auch ohne das grafische Konfigurationstool 

im Editor bearbeiten, was auch 

nötig ist, wenn Sie das Programm überhaupt 

in Betrieb nehmen wollen. Woran 

es noch mangelt, verrät ein Aufruf von 

»/usr/share/prey/prey.sh ‐‐check« (Abbildung 

2). 

Um an die fehlenden Keys zu gelangen, 

müssen Anwender sich auf der Prey- 

Website registrieren. Nach dem Opt-in 

per E-Mail und dem Einloggen gelangen 

Sie in den eigenen Administrationsbereich, 

wo Sie in den Profilinformationen 

auf der linken Seite den API-Key finden. 

Haben Sie ihn in der Konfigurationsdatei 

als »api_key« eingetragen, führen SIe wieder 

das Prey-Skript aus. In der Ausgabe 

des Befehls finden sich die folgenden 

Zeilen: 

‐‐ Gathering PC info... 

‐‐ Sending request to Control Panel... 

‐‐ Device succesfully added! U 

Applying configuration... 

Im leider wenig übersichtlichen Verwaltungsbereich 

auf der Prey-Site ist nun 

das registrierte Gerät zu sehen. Den Device 

Key finden Sie wieder auf der linken 

Seite, wenn Sie auf das Gerät klicken. 

Tragen Sie ihn in der Konfigurationsdatei 

als »device_key« ein, sonst legt Prey jedes 

Mal ein neues Gerät an, wenn Sie das 

Skript starten. 

Unter Ubuntu hat die Installationsroutine 

des Pakets auch einen Cronjob für 

den Benutzer »root« eingerichtet, den 

»crontab ‐e« (als Root) anzeigt: 

*/25 * * * * /usr/share/prey/prey.sh > U 

/var/log/prey.log 


Prey 

Know-how 

Sie können das Skript aber auch jederzeit 

von Hand ausführen, wenn Sie sehen 

wollen, was passiert. Der springende 

Punkt ist, dass der Cronjob das Prey- 

Skript auch ausführt, wenn der Laptop 

in falsche Hände gerät. 

Online-Check 

Bei jedem Durchlauf verbindet sich das 

Skript mit der Prey-Website und prüft 

dort den aktuellen Status, der OK oder 

Missing sein kann. Ist er OK, schreibt das 

Skript einfach seine Logdatei und tut ansonsten 

nichts. Ist der Laptop gestohlen, 

schaltet der Anwender im Webinterface 

auf Missing. Nun tritt Prey in Aktion und 

führt eine Reihe von Aktionen aus, die 

sich im Webinterface einstellen lassen. 

So versucht es, über GPS – sofern vorhanden 

– oder WLAN-Lokalisierung dein 

eigenen Ort zu ermitteln. All dies lässt 

sich gefahrlos testen, indem man den 

Laptop im Webinterface als vermisst meldet, 

denn außer einem selbst bekommt 

niemand davon etwas mit. 

Prey kann auch Alarme auslösen, den 

Bildschirm sperren oder sensible Daten 

auf dem Rechner löschen. Hier hat der 

Anwender viele Möglichkeiten, sollte 

aber gut überlegen, ob es sinnvoll ist, 

den Dieb darauf aufmerksam zu machen, 

dass man ihm auf der Spur ist. Auch ist 

es wenig wünschenswert, wegen eines 

Versehens wichtige private Daten durch 

das Programm gelöscht zu bekommen. 

Auf Wunsch bekommt es noch mehr Details 

über die eigene Netzwerkumgebung 

sowie andere WLANs in der Umgebung 

heraus – vielleicht hilft dies ja bei der Lokalisierung 

des Geräts. Prey macht auch 

einen Screenshot des Desktops, über 

den sich unter Umständen der Benutzer 

identifizieren lässt, wenn er gerade 

seine Webmail auf dem gestohlenen Gerät 

liest. Die Spuren sichert Prey immer 

wieder, solange der Cronjob läuft und 

der Status des Geräts auf Missing steht. 

Alles dies setzt natürlich voraus, dass 

der Rechner ans Internet angeschlossen 

ist, was die Crux des ganzen Ansatzes 

ist. Man ist also darauf angewiesen, dass 

der Dieb selbst den Rechner mit dem Internet 

verbindet, was wohl nicht in jedem 

Fall passieren wird. Alternativ kann Prey 

auch offene WLANs verwenden, um sich 

selbst mit dem Netz zu verbinden, aber 

auch dafür muss man Glück haben. 

Mit dem kostenlosen Prey-Dienst lassen 

sich bis zu drei Geräte verwalten, für die 

es bis zu zehn Reports gibt. Wer mehr 

will, kann eines der kostenpflichtigen 

Angebote von Prey nutzen, die bei fünf 

US-Dollar im Monat starten und bis zu 

399 US-Dollar pro Monat gehen und dann 

500 Geräte abdecken. 

Alternativ lässt sich Prey, dessen Client- 

Quellcode unter der GPLv3 frei verfügbar 

ist, auch ohne den Prey-Dienst mit einem 

eigenen Server verwenden. Dazu aktiviert 

man auf dem eigenen Webserver 

eine URL, die Prey zur Überprüfung verwendet. 

Ist das Gerät gestohlen, löscht 

man die URL, geht Prey von einem Diebstahl 

aus und schickt seine Benachrichtigungen 

los, die der Anwender dann per 

E-Mail erhält. Eine 

funktionierende 

SMTP-Konfigura- 

tions ist dann ebenfalls obligatorisch. Als 

experimentelles Feature gibt es noch die 

Benachrichtigung per SSH beziehungsweise 

SFTP. Hierzu sind allerdings wieder 

auf dem Laptop abgelegte Public Keys nötig, 

die einen Zugang zum eigenen Server 

verschaffen, den man dem Dieb vielleicht 

nicht unbedingt noch als zusätzliches Geschenk 

machen will, wenn man ihn nicht 

besonders abgesichert hat. 

Fazit 

Der Einsatz von Prey ist sicher kontrovers. 

Im Optimalfall verhilft das Tool 

dazu, einen gestohlenen Laptop oder ein 

Mobiltelefon wieder zurückzubekommen. 

Entsprechende Erfolgsgeschichten 

sind auf der Prey-Website dokumentiert 

und bebildert. Andererseits setzt dies 

günstige Umstände voraus, etwa eine 

funktionierene Netzwerkverbindung 

nach dem Diebstahl. Demgegenüber 

stehen einige Bedenken, auf dem eigenen 

Rechner eine permanente Überwachungsmaschinerie 

laufen zu lassen, die 

unter Umständen private Daten ins Internet 

lädt (etwa Screenshots von eigener 

E-Mail). Im Prinzip ist ein Missbrauch 

ausgeschlossen, denn man hat im Prey- 

Webinterface nur selbst Zugang auf diese 

Daten. Wer hierbei keine Bedenken hat, 

verschafft sich mit Prey immerhin eine 

gewisse Chance, ein gestohlenes Gerät 

zurückzubekommen. 

n 

Infos 

[1] Prey: [http:// preyproject. com] 

[2] Sourcecode: [https:// github. com/ prey] 

[3] Forum: [http:// answers. preyproject. com] 

Abbildung 1: Im Prey Configurator lassen sich die Grundeinstellungen für das Tool 

vornehmen, für alles andere muss die Konfigurationsdatei herhalten. 

Abbildung 2: »prey.sh ‐‐check« verrät hier, dass noch der API-Key und der 

Device-Key fehlen, damit Prey funktioniert. 


Admin 


63


Proxmox 

© Artem Merzlenko, 123RF 

Proxmox Virtual Environment 2.2 unter der Lupe 

Virtualisierungswarte 

Proxmox Virtual Environment entwickelt sich von Version zu Version vom Geheimtipp zum kostenlosen VMware 

ESXi/vSPhere-Klon. Wir werfen einen Blick auf die Neuerungen der Version 2.2. Thomas Drilling 

Proxmox Virtual Environment (PVE) [1] 

ist eine Open-Source-Virtualisierungslösung, 

die seit 2004 von der Wiener Proxmox 

Server Solutions GmbH entwickelt 

wird. Da Proxmox VE vollständig unter 

der GPLv2 lizensiert ist, bestehen auch 

hinsichtlich einer geschäftlichen Nutzung 

keine Einschränkungen – im Unterschied 

zu manchen Free- oder Personal-Lizenzen 

vergleichbarer Konkurrenzprodukte. 

Die Proxmox Server Solutions GmbH bietet 

allerdings für Unternehmenskunden 

auch ein Subskriptions-Modell [2] mit 

verschiedenen Support-Leveln zwischen 

120 Euro und 800 Euro pro Jahr an. 

Die Lösung war von Anfang an als einfach 

installierbare Appliance mit Bare- 

Metal-Installer konzipiert, die sich über 

eine Weboberfläche konfigurieren lässt 

und wahlweise KVM-basierte Gäste oder 

OpenVZ-Container bereitstellen kann. 

Diese relativ ungewöhnliche Kombination 

macht deutlich, dass PVE auf den 

Unternehmenseinsatz abzielt, wenngleich 

die frühen Versionen dafür noch 

die eine oder andere Funktion vermissen 

ließen. 

Auch eine Cluster-Funktion war schon 

von Anfang an enthalten, mit deren Hilfe 

der Admin aus zwei oder mehr PVE- 

Rechnerknoten auch ohne SAN eine redundante 

Virtualisierungsumgebung 

erstellen konnte. Der Leistungsumgang 

steigerte sich von Version zu Version. 

Wenn es an früheren Versionen etwas 

auszusetzen gab, dann dass die Web-GUI 

Funktionen vorspiegelte, die sie allein 

nicht hatte. Stattdessen war oft eine vorherige 

manuelle Konfiguration auf der 

Kommandozeile nötig, etwa im Bereich 

der Cluster-Funktionen oder beim Befüllen 

eines Storages, sei das ein lokales Verzeichnis 

auf dem jeweiligen PVE-Node 

oder ein Netzwerkverzeichnis (NFS, 

CIFS) oder ein SAN (iSCSI, FC). 

Funktionsumfang 

Proxmox bezeichnet sich selbst als „Open 

Source-Virtualisierungsplattform mit 

Web-Oberfläche zum Betrieb und Management 

von Virtual Appliances mit integrierter 

VNC-Konsole“. Proxmox spielte 

schon 2012 vor der Veröffentlichung der 

Version 2.0 in einer Liga mit dem (heute 

nicht mehr erhältlichen) VMware-Server 

und positioniert sich in der aktuellen 

Version 2.2 als direkter Konkurrent zu 

VMware ESXi und Citrix Xen Server. Laut 

einer Vergleichstabelle [5] der Proxmox- 

Entwickler kann PVE 2.2 sogar mehr als 

vSPhere, XenServer und MS Hyper V. 

In der Tat kam die Veröffentlichung der 

Version 2.0 im Frühjahr letzten Jahres 

mit komplett neuer JavaScript-Weboberfläche, 

auf dem Corosync-Cluster-Communication-Stack 

basierender HA-Unterstützung, 

Backup/Restore-Funktion via 

GUI und seinem RESTful Web API (Proxmox_VE_API) 

[6] einem Quantensprung 

in der Entwicklung gleich. 

Dieser Beitrag soll neben den Neuerungen 

der Version 2.2 vorrangig zwei für 

Admins interessante Funktionen im Detail 

beschreiben, nämlich das Erstellen 

eines HA-Clusters und das individuelle 

Aufsetzen von Proxmox VE auf einem 

Debian-System. 

Eine Besonderheit von Proxmox-VE besteht 

darin, dass das System im Kern 

auf Debian-GNU-Linux (aktuell Version 

6.0.6) basiert. Das ist – gerade für Windows-Admins 

– nicht unbedingt ersichtlich, 

weil sich die Software mit ihrem 

Bare-Metal-Installer (ohne große Möglichkeiten 

der Einflussnahme) in knapp 5 

Minuten installieren lässt und die weitere 


Proxmox 


Konfiguration über das Webinterface erfolgt. 

Dank Debian-Fundament kann der 

Admin aber beliebige Komponenten aus 

dem Debian-Projekt nachinstallieren und 

seinen Proxmox-Node so nach Belieben 

zu einer kompletten Workstation oder zu 

einem Server ausbauen, der neben der 

Virtualisierung auch andere Aufgaben 

übernimmt. Das Installieren, sowie erste 

Konfigurationsschritte im neuen Web- 

GUI erläutert der Kasten „Installation 

und erste Schritte“. 

Clustern mit Proxmox 

Wer einen Cluster-Verbund mit PVE aufbauen 

will, tut sich leichter, wenn ein 

externer Shared-Storage, etwa in Form 

eines SAN oder NFS-Servers zur Verfügung 

steht. PVE kennt die Storage-Technologien 

iSCSI, Fibre Channel, CIFS, NFS, 

DRBD und ATA over Ethernet (AoE). 

PVE unterstützt schon von je Cluster. Dabei 

unterscheidet es zwischen gewöhnlichen 

Clustern und Hochverfügbarkeits- 

Clustern. Erstere sind ein Verbund von 

Rechnern einer PVE-Installation (Virtualisierungsknoten). 

Ein solcher Proxmox- 

VE-Cluster besteht stets aus einem Master 

und mindestens einem Node. Wie 

man ein solches Setup aufsetzt, ist im 

Proxmox-Wiki [7] beschrieben. Die dortigen 

Erläuterungen und Abbildungen 

zum Verwenden des Cluster-Setups beziehen 

sich jedoch auf die Version 1.9 mit 

alter GUI. Nach abgeschlossener Konfiguration 

über das GUI lassen sich virtuelle 

Maschinen zum Beispiel auf einen 

anderen Proxmox-Knoten migrieren. Seit 

der Version 2.0 ist das Produkt auch hoch 

verfügbar, was in Konkurrenz zu kommerziellen 

Lösungen wie VMware ESX 

essenziell ist. Zum Realisieren eines HA- 

Clusters mit PVE gibt es seit der Version 

2.0 zwei Möglichkeiten. Die erste funktioniert 

auch mit älteren Versionen. Hat der 

Admin einen gewöhnlichen PVE-Cluster 

konfiguriert, kann er mithilfe von DRDB 

einen sogenannten Two-Node-HA-Cluster 

aufsetzen, was ebenfalls im Wiki [8] beschrieben 

ist. Das funktioniert, weil PVE 

wie erläutert (auch) ein ganz gewöhnliches 

Debian-System ist. Eine DRDB- 

Konfiguration beschränkt sich stets auf 

zwei Knoten und ist im Proxmox-Wiki 

ausführlich erläutert [9]. Da DRDB zwei 

PVE-Hosts synchronisieren hilft, die so 

als Basis für den HA-Cluster dienen, reduziert 

sich der Aufwand an benötigten 

Komponenten auf zwei PVE-Hosts. 

Clustern mit Corosync 

Die HA-Fähigkeit eines Proxmox-VE-2- 

Clusters beruht dagegen auf dem Corosync-Kommunikations-Stack 

[10] sowie 

der Red Hat Cluster-Suite [11]. Das 

dazu eigens entwickelte Datenbank- und 

FUSE-basierte Proxmox Cluster Filesystem 

(»pmxcfs«) [12] ermöglicht es, die 

Konfiguration der einzelnen Cluster- 

Knoten über den Corosync-Kommunikations-Stack 

zu nutzen und auf DRBB zu 

verzichten. 

Da Proxmox auf diese Weise sämtliche 

Konfigurationsdateien, die clusterweit 

identisch sein müssen, im Pmxcfs vorhält, 

können auch alle PVE-Nodes darauf 

zugreifen. Ferner unterstützt ein Proxmox-VE-2-Cluster 

verschiedene Authen- 

tifizierungsverfahren, neben der lokalen 

Authentifizierung auch Active Directory 

und LDAP. Darüber hinaus beherrscht 

er die Rollen-basierte Verwaltung sämtlicher 

Cluster-Objekte (Nodes, Storages, 

virtuelle Maschinen) und ist außerdem 

in der Lage, Multi-Master-Cluster zu erstellen 

(wie beschrieben unterstützten 

gewöhnliche Proxmox-VE-Cluster nur 

Single-Master-Setups). 

Cluster Manager Toolkit 

Die erforderliche Corosync-Konfiguration 

wird mithilfe der Befehle des Proxmox VE 

Cluster Manager Toolkit [13] automatisch 

auf jedem Knoten erzeugt und ist unter 

anderem dafür verantwortlich, dass 

die Nodes im Cluster miteinander kommunizieren, 

was wiederum voraussetzt, 

dass sich sämtliche Nodes im gleichen 

Subnetz befinden. Das automatische Abstimmen 

der Nodes erfolgt dann via IP 

Multicasts, was allerdings bei manchen 

Switches eine manuelle Aktivierung erfordert. 

Ferner müssen Datum und Zeit 

zwischen den Notes synchronisiert sein. 

Außerdem nutzt die Konfiguration einen 

SSH-Tunnel auf Port 22. Der Datenverkehr 

der VNC-Konsole ist dagegen seit 

PVE 2.0 über SSL gesichert und nutzt die 

Ports 5900 und 5999. 

Für das weitere Vorgehen muss der Admin 

zunächst auf jedem für den PVE-2- 

HA-Cluster vorgesehenen Node PVE über 

den Bare-Metal-Intaller installieren. 

Dabei muss er darauf achten, gleich zu 

Angfang den finalen Hostnamen und eine 

statische IP-Konfiguration festzulegen, 

weil das Ändern der IP-Adresse oder des 

Abbildung 1: Das PVE-Cluster-Manager-Toolkit bietet eine 

eigene Kommandoschnittstelle. 

Abbildung 2: Zum Hinzufügen eines Nodes zum bestehenden Cluster loggt sich der Admin via SSH auf 

einem anderen PVE-Node ein und fügt dort diesen Node zum angegebenen Cluster hinzu. 


Admin 


67


Proxmox 

Abbildung 3: Ist der HA-Cluster grundlegend konfiguriert, erfolgt das Verwalten über das Web-GUI. 

Hostnamens nach der Cluster-Erzeugung 

nicht mehr möglich ist. Auch wenn der 

fertige Cluster inzwischen über das Webinterface 

verwaltet und genutzt werden 

kann, muss der Admin zum Aufsetzen 

des PVE-HA-Clusters auf das Proxmox 

VE Cluster Manager Toolkit zurückgreifen, 

das auf jedem Node die Corosync- 

Konfiguration erzeugt. Seine vollständige 

Syntax findet sich hier [15]. 

Um einen Cluster anzulegen, meldet sich 

der Admin zunächst via SSH auf dem 

ersten VE-Node an und erzeugt mit 

»pvecm create Cluster‐Name« einen ersten 

Cluster, dessen Status er anschließend 

mit »pvecm status« prüfen (Abbildung 

1) kann. 

Zum Hinzufügen eines Nodes zu einem 

bereits existierenden Cluster loggt sich 

der Admin via SSH auf einem anderen 

PVE-Node ein und fügt dort diesen Node 

mit dem Befehl »pvecm add IP‐Cluster« 

zum angegebenen Cluster hinzu (Abbildung 

2). 

Ist das geschehen, lässt sich auch hier 

mit »pvecm status« der neue Status des 

Clusters verifizieren. Mit »pvecm nodes« 

dagegen kann der Admin sämtliche im 

Cluster enthaltenen Nodes anzeigen. 

Zum Entfernen eines Cluster-Nodes muss 

der Admin ebenfalls die Kommandozeile 

bemühen. Lediglich das Löschen oder 

Migrieren von virtuellen Maschinen kann 

und muss über das Webinterface erfolgen. 

Soll ein Cluster-Node entfernt werden, 

muss der Admin etwaige existente 

und noch benötigte VMs vorher durch 

Migrieren oder Sichern (Snapshot) erhalten. 

Das Löschen des Nodes funktioniert 

dann mit »pvecm delnode «. 

Wurde die Corosync-Konfiguration auf 

diese Weise erstellt, lässt sich im Web- 

GUI im Reiter „HA“ (Abbildung 3) wahlweise 

eine Failover-Domain hinzufügen 

oder eine HA-managed-VM beziehungsweise 

ein HA-managed-CT (Ressource- 

Container) hinzufügen. 

Das GUI zeigt die dazu notwendigen Änderungen 

im Bereich „Ausstehende Änderungen“ 

an. 

Mit einen Klick auf „Aktivieren“ lässt sich 

die Konfiguration abschließen. Dank Corosync 

wird der Zustand jedes Nodes zwischen 

allen Knoten repliziert, die in die 

Corosync/HA-Konfiguration eingebunden 

sind. Außerdem lassen sich problemlos 

VMs oder CTs zwischen den beteiligten 

physischen Nodes migrieren (Abbildung 

4). Die Konfiguration sorgt außerdem für 

ein Cluster-weites Logging. 

Proxmox auf Debian 

Abbildung 4: Ein Cluster-Setup erlaubt auch das Migrieren einer VM von einem Knoten zum nächsten. 

Der Bare-Metal-Installer macht das Aufsetzen 

eines PVE-Servers nebst Webinterface 

und allem drum und dran zum 

Kinderspiel, lässt dem Admin jedoch 

wenig Entscheidungsfreiheit und erlaubt 

auch kein Partitionieren. Zwar ist es über 

Kernel-Parameter in gewissen Umfang 

möglich, die Größen für die Root- und 

Swap-Partition vorzugeben, ein eigenes 

Partitionslayout, das beispielsweise auch 

existente Systeme berücksichtigt, ist 

mit dem Bare-Metal-Installer allerdings 

nicht möglich. Bestehende Partitionen zu 

berücksichtigen, entspricht auch nicht 

dem Sinn einer Appliance-Lösung, es 

mag aber doch den einen oder anderen 

Admin geben, der PVE nur ausprobieren 

oder aus anderen Gründen auf ei- 


Proxmox 


nem existenten Debian-Server aufsetzen 

möchte. Zudem liegt die Idee nahe, ein 

Debian-System nicht nur als Proxmox- 

Fundament, sondern auch für andere 

Services zu nutzen. 

Die Proxmox Server Solutions GmbH 

bietet zu diesem Zweck ein eigenes Apt- 

Repositoy für Debian-Systeme an, mit 

dessen Hilfe es möglich ist, den Proxmox- 

Kernel (aktuell ein von den Proxmox- 

Entwicklern modifizierter RHEL-Kernel 

2.6.32-042) und das eigentliche Proxmox 

Virtual Environment (proxmox-ve-2.6.32) 

als Deb-Pakete zu installieren. Hat der 

Admin ein Debian-System mit individuellem 

Partitions-Layout erstellt (die Proxmox-Entwickler 

bevorzugen übrigens ein 

LVM-basiertes Partitionsschema, was das 

spätere Erweitern flexibler macht) oder 

ist ein laufendes Debian-System vorhanden, 

muss er lediglich das Repository 

»http://download.proxmox.com/debian 

squeeze pve« in seine »/etc/apt/sources. 

list« einfügen: 

Ist das erledigt muss der Admin lediglich 

noch die Pakete »postfix«, »lvm2«, 

»ntp«, »ssh«, »ksm‐control‐daemon« und 

»vzprocps« installieren. Ist auch das gedeb 

http://ftp.at.debian.org/debian U 

squeeze main contrib 

deb http://security.debian.org/ U 

squeeze/updates main contrib 

# PVE‐Pakete 

deb http://download.proxmox.com/debian U 

squeeze pve 

Das Importieren des nötigen Schlüssels 

klappt am einfachsten mit 

wget http://download.proxmox.comU 

/debian/key.asc 

apt‐key add key.asc 

Anschließend müssen zunächst die Repoliste 

und dann das komplette System 

aktualisiert werden 

aptitude update 

aptitude full‐upgrade 

Ist das geschehen, ist zunächst der auf 

einem RHEL-Kernel basierende Proxmox- 

Kernel zu installieren: 

apt‐get install pve‐firmware 

aptitude install pve‐kernel‐2.6.32‐16‐pve 

Die PVE-Kernel-Header werden nur benötigt, 

wenn später weitere individuelle 

Modifikationen durch das Anpassen des 

Kernels oder das Übersetzen von Kernel- 

Modulen anstehen. Beim Reboot ist unbedingt 

darauf zu achten, dauch tatsächlich 

den Proxmox-Kernel zu booten. Normalerweise 

sollte Grub2 eine entsprechende 

Boot-Auswahl automatisch konfiguriert 

haben. Läuft das System mit PVE-Kernel, 

kann der Admin das eigentliche Proxmox- 

Virtual-Environment mit »apt‐get insstall 

proxmox‐ve‐2.6.32« installieren. Das 

Aktivieren des Proxmox-Webinterfaces 

durch Hinzufügen eines Virtual Hosts mit 

anschließendem Apache-Neustart klappt 

am schnellsten mit 

a2ensite pve‐redirect.conf 

/etc/init.d/apache2 restart 

Abo abschließen und gewinnen! 

Sparen Sie 15% beim 

Print- oder Digital-Abo 

und gewinnen Sie eins von zwei 

Archos 101 XS Gen 10 im Wert 

von circa 380 E! 

Die Verlosung erfolgt am 28.02.13 um 12 Uhr 

unter allen Abonnenten (außer Miniabos) 

Die Monatszeitschrift für Android-Fans, Smartphone- und Tablet-Nutzer 

Jetzt bestellen unter: 

www.android–user.de/abo 

Telefon 07131 www.admin-magazin.de 

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


69


Proxmox 

schehen, sollte eine Verbindung zum 

Proxmox-Webinterface unter der Adresse 

»https://

Proxmox 


Infos 

Abbildung 5: Dank Bare-Metal-Installer ist das System nach wenigen Eingaben einsatzbereit. 

Abbildung 6: Essenziell ist das Anlegen eines Storage, im einfachsten Fall ein lokales Verzeichnis. 

Abbildung 7: Im Reiter General sind der betreffende Knoten sowie die ID der virtuellen Appliance vorgegeben. 

[1] Proxmox-Projektseite: 

[http:// www. proxmox. com/] 

[2] Proxmox-Shop: 

[https:// shop. maurer‐it. com/ cart. php] 

[3] Thomas Drilling: Artikel überProxmox VE 

in ADMIN 05/2010 

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

2010/ 05/ Container‐und‐Hardware‐Virtuali 

sierung‐unter‐einem‐Dach] 

[4] Artikel Proxmox VE in LM 10/2012 von 

Martin Loschwitz: 

[http:// www. linux‐magazin. de/ Ausgaben/ 

2012/ 10/ Proxmox‐VE] 

[5] Proxmox im Vergleich mit VMware und 

HyperV: [http:// www. proxmox. com/ 

products/ proxmox‐ve/ comparison] 

[6] Proxmox_VE_API:[http:// pve. proxmox. 

com/ wiki/ Proxmox_VE_API] 

[7] Gewöhnlicher PVE-Cluster: 

[http:// pve. proxmox. com/ wiki/ Proxmox_ 

VE_Cluster] 

[8] PVE Two-Node_High_Availability_ 

Cluster:[http:// pve. proxmox. com/ wiki/ 

Two‐Node_High_Availability_Cluster] 

[9] PVE DRDB: 

[http:// pve. proxmox. com/ wiki/ DRBD] 

[10] Corosync-Kommunikation-Stack: 

[http:// www. corosync. org] 

[11] Red Hat Clutser Suite: [https:// access. 

redhat. com/ knowledge/ docs/ de‐DE/ 

Red_Hat_Enterprise_Linux/ 5/ html/ 

Cluster_Suite_Overview/ ch. gfscs. 

cluster‐overview‐CSO. html] 

[12] Proxmox Cluster Filesystem: 

[http:// pve. proxmox. com/ wiki/ Proxmox_ 

Cluster_file_system_(pmxcfs)] 

[13] Proxmox VE cluster manager toolkit: 

[https:// pve. proxmox. com/ pve2‐api‐doc/ 

man/ pvecm. 1. html] 

[15] Synoptic Proxmox VE cluster manager 

Toolkit: [https:// pve. proxmox. com/ 

pve2‐api‐doc/ man/ pvecm. 1. html] 

[16] Proxmox Roadmap: 

[http:// pve. proxmox. com/ wiki/ Roadmap] 

[17] Ceph: [http:// ceph. com/ docs/ master/] 

[18] PVE-Download PVE: [http:// www. 

proxmox. com/ downloads/ proxmox‐ve/ 

17‐iso‐images] 

[19] Proxmox Hardware-Anforderungen: 

[http:// proxmox. com products/ 

proxmox‐ve/ system‐requirementsproxmox‐ve] 

[20] Das Proxmox-Storage Modell: 

[http:// pve. proxmox. com/ wiki/ Storage_ 

Model] 


Admin 


71


Open Stack 

© JY Lee, 123RF 

OpenStack-Workshop, Teil 2: Eine Schritt-für-Schritt Cloud-Installation 

Einrichtungsberater 

Der erste Artikel dieses Workshops hat die Theorie hinter OpenStack beleuchtet, der zweite Teil kümmert sich 

um die Praxis: Wie lässt sich eine Open-Stack-Wolke aus dem Boden stampfen? Martin Loschwitz 

Eingedenk der am Markt herrschenden 

Vielfalt verschiedener Cloud-Lösungen 

ist die Auswahl des passenden Systems 

für die eigenen Ansprüche eine eher 

schwierige Angelegenheit. Haben die Planer 

von IT-Umgebungen diesen Schritt 

hinter sich gebracht und sich dabei für 

Open Stack entschieden, fängt jedoch das 

Leiden meist erst richtig an. Denn Open 

Stack genießt nicht unbedingt den Ruf, 

das bestdokumentierte Projekt der Open- 

Source-Szene zu sein. Zwar ist in den 

letzten Monaten die Dokumentation ein 

ganzes Stück besser geworden, was nicht 

zuletzt an der Hartnäckigkeit von Anne 

Gentle liegt – der Leiterin des Dokumentationsteams. 

Doch hapert es noch immer 

an einigen Stellen – so fehlt beispielsweise 

ein Dokument, das die Installation 

einer Open Stack-Wolke durchgängig von 

der Installation der Pakete bis hin zu der 

ersten VM erläutert. 

Keine Panik: Open Stack wirkt umfangreich, 

doch die meisten Teile der ab Werk 

gelieferten Konfiguration lassen sich eins 

zu eins nutzen. Dieser Text beschäftigt 

sich mit der Frage, welche Open-Stack- 

Komponenten notwendig für eine Open- 

Stack-Basisinstallation sind und wie deren 

Konfiguration klappt. Das Ziel ist eine 

Open-Stack-Referenzimplementation bestehend 

aus drei Knoten: Ein Knoten dient 

als Cloud-Controller, ein weiterer fungiert 

als Knoten für den Open-Stack-Netzwerkdienst 

Quantum, und der dritte Knoten 

beheimatet als klassischer Hypervisor die 

virtuellen Maschinen der Umgebung. 

Zur Vorbereitung: NTP, 

RabbitMQ und MySQL 

Die gute Nachricht vorweg: NTP und 

RabbitMQ bedürfen nach der Installation 

auf Alice keiner Veränderungen; beide 

Dienste funktionieren unmittelbar nach 

der Installation mit Standardwerten. 

Etwas anders sieht es für MySQL aus: 

Sämtliche Open-Stack-Dienste benötigen 

eine eigene Datenbank in MySQL, die 

händisch anzulegen ist. Das Listing 1 

hat die notwendigen Befehle. Das Beispiel 

geht davon aus, dass für den Root- 

User in MySQL kein Passwort gesetzt ist. 

Falls das im lokalen Setup anders ist, 

so ist den MySQL-Aufrufen jeweils der 

„-p“-Parameter hinzuzufügen, sodass 

der MySQL-Client jeweils nach dem Datenbank-Passwort 

fragt. Überdies muss 

MySQL so konfiguriert sein, dass es auf 

allen Interfaces lauscht – und nicht nur 

auf der Localhost-Adresse »127.0.0.1«. 

Dazu ist in »/etc/mysql/my.cnf« der Wert 

von »bind_address =« auf »0.0.0.0« zu 

ändern. Wenn also die Datenbanken angelegt 

sind, und die IP-Adresse entsprechend 

angepasst ist, kann es mit den 

eigentlichen Open-Stack-Komponenten 

weitergehen. 

Aller Anfang: Open Stack 

Keystone 

Keystone ist die Autentizifierungskomponente 

von Open Stack. Es handelt sich 

um den einzigen Dienst, der keinen an- 


Open Stack 


Benötigte Pakete 

Der Artikel geht davon aus, dass Ubuntu 12.04 zum Einsatz kommt. Um in 

den Genuss von OpenStack Folsom zu gelangen, reichen die Paketlisten von 

Ubuntu 12.04 allerdings nicht aus, denn diese enthalten nur Pakete für die 

Vorgängerversion Essex. Glücklicherweise stellt das Ubuntu-Cloud-Team 

für Precise Pangolin aber in einem eigenen Repository Pakete von Essex 

bereit, die sich wie gehabt installieren lassen. Damit die Installation klappt, 

ist das Paket »ubuntu‐cloud‐keyring« notwendig, das den GPG-Schlüssel 

des Cloud-Teams enthält. In »/etc/apt/sources.list.d/cloud.list« sorgt im 

Anschluss der Eintrag 

»deb http://ubuntu‐cloud.archive. canonical.com/ubuntu precise‐updates/ 

folsom main« 

dafür, dass die benötigten Paketlisten tatsächlich auch in die Verwaltung 

des Systems gelangen. Die Installation einzelner Pakete erfolgt danach wie 

gewohnt über Werkzeuge wie »apt‐get« oder »aptitude«. 

Pakete auf dem Cloud Controller 

Der Host »alice« spielt im Beispiel den Cloud Controller; damit der Host 

diese Aufgabe erfüllen kann, benötigt er den Basis-Satz an Paketen für 

OpenStack. Die folgenden Pakete samt Abhängigkeiten sind also Voraussetzung: 

n ntp 

n tgt / open-iscsi / open-iscsi-utils 

n rabbitmq-server 

n mysql-server / python-mysqldb 

n keystone / python-keystone / python-keystoneclient 

n glance / glance-api / glance-common / glance-registry / pythonglance 

n nova-api-metadata / nova-api-os-compute / nova-api-os-volume / novaapi-ec2 

n nova-cert / nova-common / nova-doc / nova-objectstore / nova-scheduler 

n nova-consoleauth / nova-novncproxy / python-nova / python-novaclient 

n openvswitch-switch 

n quantum-server / python-cliff / python-pyparsing 

n cinder-api / cinder-scheduler 

n cinder-volume / iscsitarget / open-iscsi / python-cinderclient 

n libapache2-mod-wsgi / openstack-dashboard / python-memcache 

Auf dem Compute-Host sind ebenfalls ein paar Pakete notwendig, jedoch 

deutlich weniger als auf dem Cloud Controller: 

n kvm / libvirt-bin / pm-utils 

n nova-compute-kvm 

n quantum-plugin-openvswitch-agent / bridge-utils 

Schließlich gibt es noch den Netzwerk-Knoten, der auch ein Basisset an 

Paketen braucht. Damit er tut wie ihm verheißen, dürfen die folgenden 

Pakete also nicht fehlen: 

n bridge-utils 

n quantum-plugin-openvswitch-agent / quantum-l3-agent / quantumdhcp-agent 

n python-keystone / python-keystoneclient 

deren Dienst voraussetzt. Deshalb ist es 

sinnvoll, mit der Keystone-Installation auf 

Alice zu beginnen. Direkt nach der Installation 

der Keystone-Pakete empfiehlt 

es sich, die Keystone-Konfiguration in 

»/etc/keystone/keystone.conf« per Editor 

zu bearbeiten. 

Wichtig ist, dass in der Zeile »admin_token 

= « ein entsprechender Wert als Admin-Token 

festgelegt wird. Das Admin- 

Token ist der Generalschlüssel für Open 

Stack: Wer den Wert kennt, kann nach 

Belieben Veränderungen in Keystone 

vornehmen. Es ist deshalb empfehlenswert, 

die Zugriffsrechte von »keystone. 

conf« so zu setzen, dass nur »root« die 

Datei lesen kann. Für das Beispiel kommt 

das Admin-Token »geheim« zum Einsatz. 

Keystone muss auch wissen, wo es seine 

eigene MySQL-Datenbank erreicht. Das 

geht über den SQL-Connection-String, 

der in »keystone.conf« innerhalb des 

»[sql]«-Blocks definiert ist. In der Standardkonfiguration 

verweist die Datei dort 

auf eine SQlite-Datenbank, für das konkrete 

Beispiel – MySQL ist auf Alice beheimatet 

– ist der Eintrag im Hinblick auf 

die zuvor angelegte MySQL-Datenbank 

wie folgt zu setzen: 

[sql] 

connection = mysql://keystonedbadmin:U 

Ue0Ud7ra@192.168.122.111/keystone 

idle_timeout = 200 

Damit Keystone weiß, wie es seine 

Service-Definitionen zu speichern hat, 

sollten in »keystone.conf« außerdem die 

folgenden Einträge zugegen sein: 

[identity] 

driver = keystone.identity.backends.sql.U 

Identity 

[catalog] 

driver = keystone.catalog.backends.sql.U 

Catalog 

»keystone.conf« ist damit bereits fertig; 

wenn die Datei gespeichert und der Editor 

geschlossen ist, folgt im nächsten 

Schritt das Anlegen aller von Keystone 

benötigten Tabellen in seiner Datenbank. 

Das geht mit dem dafür vorgesehenen 

Listing 1: Datenbanken anlegen 

Die folgenden Befehle legen die in MySQL benötigten Datenbanken an: 

mysql ‐u root


Open Stack 

Werkzeug: »keystone‐manage db_sync«. 

Im Anschluss startet »service keystone 

restart« den Dienst neu, sodass er einsatzbereit 

ist. 

Des Admins erste Handlung nach der 

Konfiguration ist es sinnvollerweise, einen 

Grundstock an Tenants und Benutzern 

anzulegen. In der Praxis geschieht 

das nicht händisch, sondern mittels vorgefertigter 

Skripte. Ein speziell auf diesen 

Artikel abgestimmtes Skript findet sich 

unter [1]. Es nutzt den zuvor in »keystone.conf« 

genutzten Schlüssel »geheim« 

und legt damit einen Tenant namens 

»admin« an, dem ein Benutzer gleichen 

Namens angehört und der als Passwort 

ebenfalls »geheim« nutzt. Zudem kümmert 

sich das Skript darum, dass ein 

»service«-Tenant entsteht, der Benutzer 

für sämtliche Dienste enthält und für jeden 

dieser Benutzer als Passwort auch 

Das Netzwerk der Wolke 

OpenStack Folsom bringt Quantum als zentrale 

Komponente für das Netzwerk. Die Komponente 

hilft dabei, Netzwerke zu virtualisieren – damit 

sie diese Rolle wahrnehmen kann, muss der Admin 

allerdings verstehen, wie Quantum im Ansatz 

funktioniert und welche Voraussetzungen 

auf den einzelnen Knoten zu erfüllen sind, damit 

das Quantum-Prinzip funktioniert. 

Grundsätzlich gilt: In Quantum bekommt der 

Admin es mit einer Reihe von Netzwerken zu 

tun, die die Kommunikation der Knoten untereinander 

und der virtuellen Maschinen ermöglichen. 

Die Quantum-Entwickler unterscheiden 

in diesem Falle zwischen vier verschiedenen 

Netzwerken (Abbildung 1) 

Das Management-Network ist das Netzwerk, das 

die physikalischen Server der OpenStack-Installation 

nutzen, um miteinander zu kommunizieren. 

Über dieses Netzwerk laufen beispielsweise 

interne Anfragen an den Keystone-Dienst, der 

für die Autentifizierung innerhalb des Setups 

verantwortlich ist. In diesem Beispiel ist das 

Management-Netz 192.168.122.0/24, und alle drei 

Knoten haben eine direkte Verbindung in dieses 

Netz über die Netzwerkschnittstelle eth0. 

»alice« hat dabei die IP-Adresse 192.168.122.111, 

»Bob« hat die IP 192.168.122.112 und »Charlie« 

hat die IP-Adresse 192.168.122.113. Zudem geht 

das Beispiel davon aus, dass die Default-Route 

aller drei Rechner zur Außenwelt ebenfalls in 

diesem Netzwerk liegt und dass das Default- 

Gateway in allen Fällen 192.168.122.1 ist (Abbildung 

2). Hinzu kommt das Data Network: Dieses 

nutzen die virtuellen Maschinen auf dem Comute-Host 

(Bob), um mit dem Netzwerk-Dienst 

auf Charlie zu sprechen. Das Data-Netz ist im 

Beispiel 192.168.133.0/24, Bob hat als IP-Adresse 

in diesem Netz 192.168.133.112 und Charlie hat 

192.168.133.113 – auf beiden Hosts liegt das Netz 

auf dem Interface »eth1« an, das seinerseits 

auch als Bridge für die virtuellen Maschinen 

dient (diese werden IP-Adressen im privaten 

Netzwerk 10.5.5.0/24 haben, um miteinander zu 

sprechen). 

Weiterhin existiert das »External Network«: 

Aus diesem beziehen die virtuellen Maschinen 

später öffentliche IP-Adressen. In Ermangelung 

echter öffentlicher IPs nutzt das Beispiel für 

dieses Netz »192.168.144.0/25«. Weil in Quantum 

die einzelnen VMs die öffentlichen IP-Adressen 

nicht direkt zugewiesen bekommen, sondern der 

Zugriff hierauf über den Netzknoten und dort 

gesetzte iptables-DNAT-Regeln funktioniert, benötigt 

nur der Host für Quantum, also Charlie, 

ein Interface in diesem Netz. 

Die Zuteilung einer IP erfolgt durch Quantum automatisch, 

sodass auf Charlie nur das Interface 

»eth2« vorhanden sein muss – aus der Konfiguration 

erfährt Quantum im weiteren Verlauf, 

dass es dieses Interface für das öffentliche Netz 

nutzen soll. 

Schließlich existiert das »API«-Netzwerk: Dieses 

ist nicht zwingend vorgeschrieben, erlaubt 

es aber, die APIs der OpenStack-Dienste über 

ein öffentliches Interface der Außenwelt zur 

Verfügung zu stellen. Das Netz kann im gleichen 

Segment liegen, wie das External Network 

(beispielsweise könnte das gesamte zur 

Verfügung stehende Netz 

192.168.144.0/24 sein, auf 

Quantum-Ebene ist das 

definierte öffentliche Netz 

dann 192.168.144.0/25, und 

das Netz 192.168.144.129/ 

25 steht als API-Netz zur 

Verfügung). Falls die APIs 

von OpenStack von außen erreichbar sein wollen, 

muss auf Alice dafür ein Interface existieren, 

das eine entsprechende IP enthält. 

Asynchrones Routing aktivieren 

Eine überaus lästige Default-Einstellung in 

Ubuntu 12.04 führt bisweilen zu Problemen, gerade 

in Setups mit OpenStack Quantum. Ubuntu 

setzt ab Werk den Wert für die »rp_filter«- 

Syscontrol-Variable auf 1. Das bedeutet, dass 

ein Antwortpaket für einen Netzwerkrequest 

nur über genau das Interface den Weg in das 

System nehmen darf, über das die ursprüngliche 

Anfrage das System zuvor verlassen hat. 

In Quantum-Setups kann es allerdings durchaus 

vorkommen, dass Pakete über andere Interfaces 

rausgehen, als deren Antworten den Weg zurück 

in das System finden. Es empfiehlt sich daher, 

das asynchrone Routing auf Ubuntu großflächig 

zu erlauben. In »/etc/sysctl.conf« erledigen das 

die folgenden beiden Einträge: 

net.ipv4.conf.all.rp_filter = 0 

net.ipv4.conf.default.rp_filter = 0 

Selbstverständlich muss auch das Packetforwarding 

aktiviert sein: 

net.ipv4.ip_forward=1 

Ein Reboot im Anschluss sorgt dafür, dass die 

neue Konfiguration aktiv ist. 

IPTables und Masquerading 

Last but not least ist freilich auch die Firewall- 

Konfiguration der Hosts zu beachten. Grundsätzlich 

gilt, dass iptables-Regeln nicht den Traffic 

der einzelnen Interfaces behindern sollten. 

Kommt wie im Beispiel zudem ein Gateway für 

das externe Netzwerk zum Einsatz, das kein 

vom Provider separat gesteuerter Router ist, 

sondern ein lokaler Rechner, so sind auf diesem 

die Regeln für DNAT und SNAT so zu setzen, dass 

sie zum Setup passen. 

Abbildung 1: Ein OpenStack-Standardsetup sieht mindestens vier 

Netzwerke vor, die jeweils eine eigene Rolle spielen. 

Abbildung 2: Nach dem Anlegen der Netzwerke in Quantum stehen zwei Netzwerke 

sowie ein Router zur Verfügung. 


Open Stack 


»geheim« verwendet. Das Skript ist lediglich 

herunterzuladen und dann auf Alice 

über die Kommandozeile auszuführen. 

Endpoints in Keystone 

definieren 

Keystone führt die sogenannte »Endpoint«- 

Datenbank. Ein Endpoint in Keystone ist 

die Adresse einer API eines der Open- 

Stack-Dienste. Möchte ein Open-Stack- 

Dienst wissen, wie er mit der API eines 

anderen Dienstes direkt kommunizieren 

kann, so erhält er diese Information 

aus eben dieser Liste in Keystone. Für 

Admins bedeutet das, dass sie die Liste 

anfänglich anzulegen haben; auch diese 

Aufgabe übernimmt ein Skript, das unter 

[2] zu finden ist. Wenn das Skript den 

Weg auf die Platte gefunden hat, klappt 

sein Aufruf so: 

./endpoints.sh \ 

‐m 192.168.122.111 \ 

‐u keystonedbadmin \ 

‐D keystone \ 

‐p Ue0Ud7ra \ 

‐K 192.168.122.111 \ 

‐R RegionOne \ 

‐E "http://192.168.122.111:35357/v2.0" \ 

‐S 192.168.122.113 \ 

‐T geheim 

Die einzelnen Parameter sind dabei deutlich 

weniger kryptisch als es auf den ersten 

Blick scheint. »‐m« gibt die Adresse 

an, unter der MySQL zu erreichen ist. 

»‐u«, »‐D« und »‐p« geben die Zugangsdaten 

für MySQL an (der Benutzer ist »keystonedbadmin«, 

die Datenbank »keystone« 

und das Passwort ist »Ue0Ud7ra«. Der 

Parameter »‐K« gibt an, auf welchem Host 

Keystone lauscht und »‐R« legt die Open 

Stack-Region fest, für die diese Angaben 

gelten. Über den Parameter bei »‐E« 

erfährt das Script, wo es sich selbst an 

Keystone anmelden muss, um die Änderungen 

überhaupt machen zu können. 

»‐S« gibt die Adresse für die Open 

Stack Object Storage Lösung mit Namen 

»Swift« an, die nicht Bestandteil dieses 

Howtos ist, aber später unter Umständen 

trotzdem noch das Setup erweitern soll. 

»‐T« bezeichnet das Admin-Token wie in 

»keystone.conf« festgelegt. Achtung: Das 

Skript ist für die Daten dieses Beispiels 

ausgelegt. Kommen beispielsweise andere 

IPs zum Einsatz, so ist das Skript 

entsprechend zu adaptieren. 

Hat das Hinzufügen der Endpoints funktioniert, 

ist Keystone bereit für den Einsatz 

in Open Stack. 

Open Stack-Credentials 

speichern 

Sobald Keystone scharf geschaltet ist, 

bedingt jede Interaktion mit dem Dienst 

die vorherige Autentifizierung. Sämtliche 

Open Stack-Tools für die Kommandozeile 

haben sich allerdings auf Umgebungsvariablen 

geeinigt, die die Anmeldung an 

Keystone vereinfachen. Sind diese Variablen 

definiert, müssen sich Admins nicht 

mehr um die händische Autentifizierung 

kümmern. Es empfiehlt sich, eine Datei 

namens ».openstack‐credentials« im 

persönlichen Ordner anzulegen. Im konkreten 

Beispiel könnte diese so aussehen 

wie in Listing 2. 

Anschließend lässt sich diese Datei mittels 

». .openstack‐credentials« in die 

laufende Umgebung einbinden. Danach 

sollten die Open Stack-Befehle auf der 

Kommandozeile klaglos funktionieren. 

Der Image-Automat Glance 

Keine Wolke ohne Images von Betriebssystemen: 

Damit Benutzer schnell und 

ohne großes Vorwissen virtuelle Maschinen 

starten können, haben Admins ihnen 

entsprechende Images zur Verfügung zu 

stellen – sonst wird es nichts mit der 

Wolke. Glance übernimmt in Open Stack 

genau diese Aufgabe. De facto besteht 

der Dienst aus zwei einzelnen Komponenten: 

Der API (»glance‐api«) sowie der 

Registry (»glance‐registry«). Erstere bietet 

ein Interface für alle anderen Open Stack- 

Dienste, zweitere kümmert sich um die 

Pflege der Datenbank von Glance selbst. 

Den Anfang macht die Konfigurationsdatei 

von »glance‐api«. Die liegt in 

»/etc/glance/glance‐api.conf«. An ihrem 

Ende findet sich ein Eintrag namens 

»[keystone_authtoken]«. Ein solcher oder 

ähnlicher Eintrag begegnet Open Stack- 

Admins häufig – jeder Dienst muss sich, 

bevor er mit Keystone sprechen darf, 

selbst erstmal bei ihm anmelden. Die zitierte 

Stelle in »glance‐api.conf« ist der 

richtige Ort, um dafür die Credentials zu 

definieren. Der Vorteil: Die Konfiguration 

ist für fast alle Open Stack-Dienste ähnlich 

aus oder sogar identisch. 

Für den weiteren Verlauf des Artikels 

gilt deshalb: »auth_host« ist stets 

»192.168.122.111 «, »admin_tenant_name« 

ist stets »service« und »admin_password« 

ist stets »geheim«. »admin_user« ist stets 

der Name des Open Stack-Dienstes, der 

sich an Keystone anmelden soll, also 

»glance« im vorliegenden Fall, » nova« für 

Open Stack Nova, »quantum« für Open 

Stack Quantum und so weiter. Einige 

Dienste fragen nach einer »auth_url« – 

diese ist im Rahmen dieses Artikels stets 

»http://192.168.122.111:5000/v2.0/«. 

Wenn im lokalen Setup andere IPs zum 

Einsatz kommen, so sind diese freilich 

für »auth_host« und »auth_url« zu nutzen. 

Damit steht fest, was in »glance‐api. 

conf« für die jeweiligen Werte bei »[keystone_authtoken]« 

einzusetzen ist. 

Wie zuvor »keystone.conf« findet sich 

auch in »glance‐api.conf« die SQL-Anweisung 

in einer Zeile, die mit »sql_connection« 

beginnt. Nach der Glance-Installation 

steht dort eine SQLite-Datenbank, 

im konkreten Beispiel ist die SQL-Verbindung 

diese: 

sql_connection = mysql://glancedbadmin:U 

ohC3teiv@192.168.122.111/glance 

Weiter unten im File findet sich eine 

Sektion namens »[paste_deploy]«. Hier 

möchte Glance wissen, welche Authentifizierungs-Methode 

es verwenden soll 

und wo es nähere Einstellungen dazu 

findet. Für »glance‐api.conf« lautet der 

korrekte Eintrag bei »config_file =« in 

dem Abschnitt folglich »/etc/glance/ 

glance‐api‐paste.ini« und bei »flavor=« 

führt der Wert » keystone« zum gewünschten 

Resultat. Nach diesen Änderungen ist 

die Datei für den Einsatz bereit. Analog 

zu ihr ist »/etc/glance/glance‐registry. 

conf« zu bearbeiten: Die Werte für die 

verschiedenen »auth_«-Variablen sind 

dieselben wie für »glance‐api«, auch die 

Datenbankverbindung sowie der Text 

Listing 2: Credentials 

01 OS_AUTH_URL="http://192.168.122.111:5000/v2.0/" 

02 OS_PASSWORD="geheim" 

03 OS_TENANT_NAME="admin" 

04 OS_USERNAME="admin" 

05 OS_NO_CACHE=1 

06 

07 export OS_AUTH_URL OS_PASSWORD 

08 export OS_TENANT_NAME OS_USERNAME 

09 export OS_NO_CACHE 


Admin 


75


Open Stack 

bei »flavor=« sind identisch. Lediglich 

bei »config_file« unterscheidet sich der 

Eintrag, denn für »glance‐registry.conf« 

ist dieser entsprechend »/etc/glance/ 

glance‐registry‐paste.ini«. Damit ist die 

Konfiguration der Glance-Komponenten 

fertig. 

Höchste Zeit also, die Tabellen in den 

Glance-Datenbanken anzulegen. Dabei 

hilft »glance‐manage«: 

glance‐manage version_control 0 

glance‐manage db_sync 

Es folgt ein Neustart der beiden Glance- 

Dienste mittels »service glance‐api restart 

&& service glance‐registry restart«. 

Nun ist der Image-Store bereit für das 

erste Test-Image. Glücklicherweise unterstützt 

der Glance-Client den direkten 

Download von Images aus dem Netz. Um 

ein Ubuntu-12.04-Cloud-Image in den 

Image-Store aufzunehmen, genügt daher 

der folgende Befehl aus Listing 3. 

Im Anschluss sollte »glance image‐list« 

das entsprechende Image auch anzeigen 

– sobald im Feld »Status« der Wert »AC- 

TIVE« aufscheint, ist das Image bereit für 

die Nutzung. 

Quantum: Die Netzwerk- 

Hydra 

Zweifellos die aufwendigste Konfiugurationsarbeit 

erwartet Admins, wenn es um 

den Netzwerkdienst Quantum geht. Denn 

damit dieser funktioniert, sind auf allen 

drei Hosts Dienste einzurichten. Den 

Anfang macht Alice: Hier muss der eigentliche 

Quantum-Server samt entsprechendem 

Plugin laufen. Dieses Beispiel 

nutzt als Plugin OpenVSwitch, sodass 

der Quantum-Server selbst wie auch das 

OpenVSwitch-Plugin zu konfigurieren 

sind (Abbildung 3). 

Nach der Installation ist zunächst »/etc/ 

quantum/api‐paste.ini« an der Reihe. 

Im Abschnitt »[filter:authtoken]« finden 

Listing 3: Image integrieren 

01 glance image‐create \ 

02 ‐‐copy‐from http://uec‐images. 

ubuntu.com/releases/12.04/release/ 

ubuntu‐12.04‐server‐cloudimg‐amd64‐disk1.img \ 

03 ‐‐name="Ubuntu 12.04 cloudimg amd64" \ 

04 ‐‐is‐public true \ 

05 ‐‐container‐format ovf \ 

06 ‐‐disk‐format qcow2 

Abbildung 3: Auf der Kommandozeile verrät der Befehl »ovs‐vsctl show«, was Quantum in der OpenVSwitch- 

Konfiguration verändert. 

sich die schon von Glance her bekannten 

Einträge, die durch die Werte für dieses 

Beispielsetup zu ersetzen sind. Als 

»auth_port« muss zwingend »35357« in 

der Datei stehen. Dann folgt die Konfiguration 

des OVS-Plugins: Dessen Konfigurationsdatei 

ist » /etc/quantum/plugins/ 

openvswitch/ovs_quantum_plugin.ini«. 

Darin findet sich eine Zeile, die mit »sql_ 

connection« anfängt und die Quantum 

verrät, wie es auf seine eigene MySQL- 

Datenbank zugreift. Hier lautet der korrekte 

Eintrag »sql_connection = mysql:// 

quantumdbadmin:wozohB8g@192.168.1 

22.111/quantum«. Weiter unten sind in 

der Datei hinter der Zeile »# Example: 

bridge_mappings = physnet1:br-eth1« 

folgende drei Zeilen einzutragen: 

tenant_network_type = gre 

tunnel_id_ranges = 1:1000 

enable_tunneling = True 

Der Einfachheit halber empfiehlt es sich, 

diese Datei nun zu speichern und an die 

gleiche Stelle auf »bob« zu kopieren (für 

die Hosts Bob und Charlie werden später 

allerdings noch Veränderungen notwendig). 

Auch »/etc/quantum/api‐paste.ini« 

lässt sich eins zu eins auf den beiden 

Knoten übernehmen. 

Auf Alice lässt sich der Quantum-Server 

(Abbildung 4) samt OpenVSwitch-Plugin 

nun schon starten: »service quantum‐server 

start« erledigt das. 

Auf Bob läuft kein Quantum-Server, nachdem 

es sich allerdings im Beispiel um den 

Computing-Knoten handelt, braucht Bob 

zwingend den » quantum‐plugin‐openvswitch‐agent«, 

den Agent, der zum 

OpenVSwitch-Plugin gehört. Über ihn erhält 

Bob später sämtliche relevanten Netzwerkinfos 

von Alice (»quantum‐server«) 

und Charlie (»DHCP«- und »L3«-Plug in), 

um sein eigenes Netzwerk richtig zu konfigurieren. 

Das Paket für diesen Agent 

sollte bereits vorhanden sein, sodass jetzt 

noch die Agent-Konfiguration ansteht. 

Die findet sich in » /etc/quantum/plugins/openvswitch/ovs_quantum_plugin. 

ini«. Hinter der Zeile »# Example: bridge_ 

mappings = physnet1:br‐eth1« sorgt der 

folgende Absatz für die korrekte Funktion 

des Agents auf Bob: 

tenant_network_type = gre 

tunnel_id_ranges = 1:1000 

integration_bridge = br‐int 

tunnel_bridge = br‐tun 

local_ip = 192.168.133.112 

enable_tunneling = True 

Mit diesen Zeilen startet der Open- 

VSwitch-Agent automatisch einen Tunnel 

zwischen Bob und dem Netzwerk-Knoten 

Charlie, über den die beiden Hosts dann 

Informationen austauschen. 


Open Stack 


Wenn die Änderungen an »ovs_quantum_plugin.ini« 

vollzogen sind, sollte 

ein Duplikat der Datei von Bob am gleichen 

Ort auf Charlie landen, wobei für 

Charlie die IP-Adresse »192.168.133.112« 

durch »192.168.133.113« zu ersetzen 

ist. Auf beiden Hosts – Bob und Charlie 

– ist zusätzlich in » /etc/quantum/ 

quantum.conf« noch »# rabbit_host« zu 

entkommentieren und mit dem Wert 

»192.168.122.111« zu versehen – nur so 

wissen die Agents auf Bob und Charlie, 

wie sie den RabbitMQ-Server auf Alice 

erreichen. 

Schließlich braucht Charlie noch spezifische 

Veränderungen, weil auf ihm 

auch der »quantum‐l3‐agent« und der 

»quantum‐dhcp‐agent« laufen. Die beiden 

Dienste versorgen VMs im Setup 

später einerseits mit DHCP-Adressen, 

und andererseits stellen sie per »iptables« 

die Möglichkeit her, die VMs über 

öffentliche IP-Adressen zu erreichen (im 

Beispiel 192.168.144.0/25). Die gute 

Nachricht ist: Der DHCP-Agent braucht 

überhaupt keine Veränderungen an der 

Konfiguration – der L3-Agent hingegen 

schon: Seine Konfigurationsdatei ist 

»/etc/quantum/l3_agent.ini«. 

Externe Netze anlegen 

Eingangs sind wie gewohnt die Werte 

für die »auth_«-Variablen in die Konfiguration 

einzutragen. Weiter unten in 

der Datei findet sich überdies der Eintrag 

»# metadata_ip =«, der zu entkommentieren 

ist und im Beispiel den Wert 

»192.168.122.111« enthält – mehr zum 

Metadaten-Server später. Die Konfigurationsdatei 

bedarf weiterer Anpassungen, 

die derzeit allerdings noch nicht möglich 

sind. Denn dafür wären die IDs des 

externen Routers wie auch die ID des 

externen Netwerks nötig, die allerdings 

erst exisiteren, nachdem die Netzwerke 

entsprechend angelegt sind. Genau das 

ist daher der nächste Schritt: Das Anlegen 

der Netzwerke in Quantum. Dieser 

Schritt findet auf Alice statt. 

Weil auch das Anlegen von Netzwerken 

einige Kommandos umfasst, stellt der 

Autor dieses Artikels ein Skript unter [3] 

zur Verfügung. Dieses legt die im Beispiel 

vorgesehenen Netzwerke an: Einerseits 

ein „privates“ Netzwerk für die Kommunikation 

der virtuellen Maschinen untereinander, 

andererseits auch das pseudoöffentliche 

Netzwerk »192.168.144.0/25«, 

aus dem die VMs dann im weiteren Verlauf 

dynamische IP-Adressen („floating 

IPs“) erhalten. Nach dem Download 

und dem Ausführen des Skriptes gilt es, 

die Quantum-interne ID des Routers für 

das Floating-Netz wie auch die ID des 

Floating-Netztes selbst in Erfahrung zu 

bringen. Den ersten Wert fördert »quantum 

router‐list« auf den Bildschirm – der 

Wert bei »ID« in der Zeile für den Router 

»provider‐router« ist von Interesse. Dieser 

wiederum landet in der eben bereits bearbeiteten 

»/etc/quantum/l3_agent.ini« auf 

Charlie. Die ID des Floating-Netzwerkes 

lässt sich mit »quantum net‐list« erfragen 

– dabei ist der Wert des »ID«-Feldes 

beim Eintrag interessant, dessen Name 

» ext_net« ist. Der Wert landet in »/etc/ 

quantum/l3_agent.ini« hinter dem Wert 

»gateway_external_net_id = «. Beide zu 

ändernden Werte sind auch zu entkommentieren, 

sodass die Quantum-Agents 

sie tatsächlich betrachten. Damit sind die 

Quantum-Konfigurationsdateien fertig. 

Mit Quantum kann es nun fast losgehen: 

Auf Bob und Charlie fehlen nur noch 

die internen Bridges, die OpenVSwitch 

verwendet, um die Quantum-Interfaces 

an die lokale Netzwerk-Konfiguration 

anzuschließen. Auf Bob und Charlie legt 

»ovs‐vsctl add‐br br‐int« die Bridge an, 

die für die VM-interne Kommunikation 

zuständig ist. Zusätzlich braucht Charlie 

auch die Bridge nach außen: » ovs‐vsctl 

add‐br br‐ext« und »ovs‐vsctl add‐port 

br‐ext eth2« erledigen die notwendige 

Konfiguration. Am Ende des Vorgangs 

steht ein Neustart aller Agents auf Bob 

und Charlie an: »restart quantum‐plugin‐openvswitch‐agent« 

sind sowohl 

auf Bob als auch auf Charlie notwen- 

dig, auf Charlie sorgt zudem »restart 

quantum‐l3‐agent« und »restart quantum‐dhcp‐agent« 

dafür, dass die Agents 

ihre Konfiguration neu laden. 

Direkt angenehm im Vergleich zu Quantum 

gestaltet sich die Konfiguration von 

Cinder. Die Komponente war in der letzten 

Open-Stack-Version Essex noch unter 

dem Namen »nova‐volume« Teil der 

Computing-Komponente, führt nun aber 

ein Eigenleben. 

Block-Storage mit Cinder 

Voraussetzung dafür, dass Cinder funktioniert, 

ist eine LVM-Volume-Gruppe 

namens »cinder‐volumes« auf dem Host, 

auf dem Cinder läuft. Meistens wird Cinder 

auf dem Cloud-Controller beheimatet 

sein, auch in diesem Beispiel werkelt das 

Programm auf Alice. Welche Storage-Devices 

Teil der LVM-Volume-Gruppe sind, 

ist Cinder übrigens herzlich egal – wichtig 

ist nur, dass es in dieser Volume-Gruppe 

selbst Volumes anlegen kann. Auf Alice 

ist entsprechend eine Volume-Gruppe 

»cinder‐volumes« für dieses Beispiel da. 

Nach der Installation der Cinder-Dienste 

ist der wichtigste Teil, dass in »/etc/ 

cinder/cinder.conf« das Programm über 

»sql_connection« erfährt, wie es an seine 

Datenbank kommt. Der korrekte Eintrag 

im Rahmen des Artikels ist »sql_connection 

= mysql://cinderdbadmin:ceeShi4 

O@192.168.122.111:3306/cinder«. Anschließend 

steht »/etc/cinder/api‐paste. 

ini« auf dem Programm – die nötigen 

Anpassungen sind analog zu den Veränderungen 

von »api‐paste.ini« der anderen 

Programme, wobei die »service_«- 

Einträge die gleichen Werte erhalten wie 

ihre »auth_«-Pendants. »admin_user« ist 

»cinder«. 

Auch Cinder benötigt Tabellen in seiner 

MySQL-Datenbank, die das Kommando 

»cinder‐manage db sync« anlegt. 

Es folgt ein Restart der Cinder-Dienste: 

»for i in api scheduler volume; do restart 

cinder‐"$i"; done«. Zuletzt gilt es, 

einen lästigen Bug im »tgt«-iSCSI-Target 

Abbildung 4: Auf dem Cloud Controller läuft in einer Default-Installation nur der eigentliche Quantum-Server. 


Admin 


77


Open Stack 

zu umgehen, der sonst die korrekte Funktion 

von Cinder verhindert: Dazu ist der 

vorhandene Eintrag in »/etc/tgt/targets. 

conf« durch den Eintrag »include /etc/ 

tgt/conf.d/cinder_tgt.conf« zu ersetzen. 

Danach ist Cinder bereits fertig – der 

Befehl »cinder list« sollte eine leere Liste 

ausgeben, es sind ja noch keine Volumes 

konfiguriert. 

Die Computing-Komponente 

Nova 

Abbildung 5: Nach der Installation der Compute-Komponenten fungiert Bob als Compute-Knoten. 

Bis zu dieser Stelle ist bereits eine bunte 

Mischung an Open-Stack-Diensten bereit 

für ihren Einsatz – der wichtigste 

von allen fehlt aber immer noch: Nova. 

Das ist die Computing-Komponente, also 

eben jene, die virtuelle Maschinen auf 

den Hosts der Wolke startet und sie später 

auch wieder stoppt. Um Nova auf 

Touren zu bringen, sind in diesem Szenario 

Dienste sowohl auf dem Host Alice 

als auch auf Bob zu konfigurieren. Der 

Host Charlie, der ja in diesem Beispiel 

als Netzwerk-Knoten fungiert, braucht 

dagegen keine eigene Nova-Komponente 


Zuerst die gute Nachricht: Die Nova-Konfiguration 

in »/etc/nova/nova.conf« kann 

auf den Hosts Alice und Bob identisch 

sein, Gleiches gilt für die API-Paste-Datei 

von Nova, die »/etc/nova/api‐paste.ini« 

heißt. Bob als Compute-Knoten braucht 

im Anschluss nur noch einige kleinere 

Anpassungen der Qemu-Konfiguration 

von Libvirt, um virtuelle Maschinen starten 

zu können. Aber langsam und der 

Reihe nach. 

Den Anfang macht Alice. In »/etc/nova/ 

api‐paste.ini« findet sich die Keystone- 

Konfiguration des Dienstes in dem Eintrag 

»[filter:authtoken]«. Die einzutragenden 

Werte sind äquivalent zu denen der 

»api‐paste.ini«-Files der anderen Dienste, 

als Wert für »admin_user« dient hier aber 

»nova«. 

Zudem finden sich in der Datei auch noch 

diverse Einträge, die den Begriff »volume« 

in ihrem Namen haben, zum Beispiel 

»[composite:osapi_volume]«. Sämtliche 

Einträge dieser Art, in deren Namen also 

das Wort »volume« vorkommt, muss 

der Admin aus der Konfiguration entfernen, 

weil sich unter Umständen sonst 

»nova‐api« und »cinder‐api« gegenseitig 

in die Haare geraten. Nach dieser Änderung 

ist »api‐paste.ini« an die gleiche 

Stelle auf Bob zu kopieren. 

nova.conf für Open Stack 

Compute 

Dann folgt die eigentliche Konfigurationsdatei 

der Compute-Komponente, 

die »/etc/nova/nova.conf« heißt. Eine 

generische Version der Datei stellt der 

Autor dieses Artikels unter [4] bereit. 

Eine Übersicht der möglichen Parameter 

für »nova.conf« ist auf der Open Stack- 

Website unter [5] verfügbar. Die Beispielkonfiguration 

lässt sich so in nahezu 

jeder Open-Stack-Umgebung verwenden, 

allerdings sind möglicherweise die in ihr 

benutzten IP-Adressen zu ändern. Sowohl 

Alice als auch Bob sollten die Datei 

als »/etc/nova/nova.conf« haben – ist sie 

an Ort und Stelle, folgt das Anlegen der 

Nova-Tabellen in MySQL auf Alice: 

nova‐manage db sync 

Die Konfiguration von Nova ist damit 

abgeschlossen, auf Bob sind allerdings 

noch Veränderungen an der Qemu-Konfiguration 

von Libvirt und an der Libvirt- 

Konfiugration selbst nötig. Die Qemu- 

Konfiguration von Libvirt liegt in »/etc/ 

libvirt/qemu.conf« – am Ende des Files 

sind noch folgende Zeilen anzuhängen: 

cgroup_device_acl = [ 

"/dev/null", "/dev/full", "/dev/zero", 

"/dev/random", "/dev/urandom", 

"/dev/ptmx", "/dev/kvm", "/dev/kqemu", 

"/dev/rtc", "/dev/hpet","/dev/net/tun", 

] 

Auch die Libvirt-Konfiguration selbst 

braucht eine Änderung – an das Ende 

von »/etc/libvirt/libvirtd.conf« gehören 

die folgenden Zeilen: 

listen_tls = 0 

listen_tcp = 1 

auth_tcp = "none" 

Diese Einträge sorgen dafür, dass Libvirt 

einen TCP/IP-Socket öffnet, um später 

Funktionen wie Live-Migration zu unterstützen. 

Damit das auch wirklich funktioniert, 

ist in »/etc/default/libvirt‐bin« 

die Zeile »libvirtd_opts="‐d"« durch »libvirtd_opts="‐d 

‐l"« zu setzen. 

Anschließend wird ein Neustart aller betroffenen 

Komponenten fällig, auf Alice 

geht das mit »for i in nova‐api‐metadata 

nova‐api‐os‐compute nova‐api‐ec2 

nova‐objectstore nova‐scheduler 

nova‐novncproxy nova‐consoleauth 

nova‐cert; do restart "$i"; done«. Auf 

Bob sorgt der Befehl »for in in libvirt‐bin 

nova‐compute; do restart $i; done« für 

den Neustart der wichtigen Komponenten. 

Ein »nova‐manage service list « sollte 

Abbildung 6: Ist das Dashboard installiert, erlaubt es das bequeme Starten und Stoppen neuer virtueller 

Maschinen über die grafische Oberfläche. 


Open Stack 


danach die Nova-Dienste auf Alice und 

Bob auflisten und dabei für jeden Dienst 

als Status „:-)“ eingetragen haben. 

Im Grunde ist die Wolke damit bereits 

einsatzbereit, über die Konsole ließen 

sich bereits virtuelle Maschinen starten. 

Was noch fehlt, ist das Open Stack-Dashboard 

(Abbilung 6), das als Service-Servicing-Portal 

Endbenutzern das Anlegen 

virtueller Maschinen ermöglicht. 

Das Open-Stack-Dashboard 

Dessen Konfiguration ist nicht weiter 

schwierig: Nach der Installation der benötigten 

Pakete auf Alice ist die Datei 

»/etc/openstack‐dashboard/local_settings.py« 

für diese Aufgabe von Interesse. 

Am Ende dieser Datei fehlen ein paar 

Einträge für die korrekte Funktion des 

Dashboards: 

OPENSTACK_HOST = '192.168.122.111' 

QUANTUM_ENABLED = True 

SWIFT_ENABLED = True 

Danach sorgt ein Neustart des Apache2-Webservers 

mittels »restart apache2« 

dafür, dass das Dashboard seine 

Konfiguration neulädt. Direkt im Anschluss 

steht das Webinterface unter 

»http://192.168.122.111/horizon« zur 

Verfügung (Abbildung 7) – der Login 

geschieht mit dem Benutzernamen 

»admin«, das Passwort ist »geheim«. 

Die Sache mit dem 

Metadata-Server 

Virtuelle Maschinen, die aus speziellen 

Images stammen – nämlich aus solchen 

Images, die offiziell für Cloud-Umge- 

bungen vorbereitet sind – zeichnen sich 

durch eine Besonderheit aus: Sie versuchen 

nämlich während des Bootvorgangs 

per HTTP-Request Informationen über 

sich selbst von einem Cloud-Metadatenserver 

zu erhalten. Diese Technik stammt 

ursprünglich aus Amazons EC2-Umgebung 

– sie stellt sicher, dass eine virtuelle 

Maschine ihren Hostname kennt und 

diverse Parameter beim Systemstart zur 

Verfügung hat, beispielsweise die Konfiguration 

hinsichtlich des zu startenden 

SSH-Servers. 

Die Ubuntu-UEC-Images sind ein gutes 

Beispiel für den Einsatz dieser Funktion: 

Eine Maschine, die aus einem Ubuntu- 

Image für UEC-Umgebungen stammt, 

führt eben jenes »cloud‐init« genannt 

Tool beim Starten aus. Das Schema ist 

immer das gleiche: Ein HTTP-Request auf 

die URL »http://169.254.169.254:80« soll 

die entsprechenden Details beim Cloud- 

Controller abfragen. Damit diese Technik 

funktioniert, ist einerseits eine entsprechende 

IPTables-Regel notwendig, die 

jene IP-Adresse auf den Computing-Knoten 

auf den „richtigen“ Cloud-Controller 

per DNAT-Regel weiterleitet. 

Der „richtige“ Controller ist in diesem 

Beispiel »nova‐api‐metadata«, der auf 

Alice am Port 8775 lauscht. Die gute 

Nachricht ist: Die DNAT-Regel setzt der 

L2-Agent auf den Compute-Knoten automatisch. 

Die schlechte: Damit auch der 

Rückkanal vom Cloud-Controller hin zu 

den VMs funktioniert, ist auf dem Cloud- 

Controller – also Alice – eine entsprechende 

Route zu setzen. Diese enthält als 

Netzwerk das private VM-Netzwerk (im 

Beispiel 10.5.5.0/24) und als Gateway die 

IP-Adresse, die auf dem Netzwerk-Host 

als Gateway-IP für virtuelle Maschinen 

dient. Je nach Konfiguration unterscheidet 

sie sich. Um sie herauszufinden, sind 

zwei Arbeitsschritte nötig: 

Per »quantum router‐list« ist zunächst die 

ID des Routers zu finden, die das externe 

Netzwerk nutzt. Danach fördert der Befehl 

»quantum port‐list ‐‐ ‐‐device_id ID 

‐‐device_owner network:router_gateway 

« das Gateway zu Tage, im Beispiel also 

192.168.144.100. Die korrekte Route auf 

Alice setzt der Admin dann per »ip route 

add 10.5.5.0/24 via 192.168.144.100«. 

Danach klappt der Zugriff auf den Metadatenserver. 

Dieser doch etwas umständliche 

Prozess wird wohl in einer 

der kommenden Open Stack-Versionen 

durch eine neue und bequemere Prozedur 

ersetzt werden. 

Perspektiven 

Die hier vorgestellte Open Stack-Installation 

ist das grundlegende Setup, das 

aus drei Knoten eine Wolke konstruiert. 

Themen wie die Hochverfügbarkeit einzelner 

Dienste oder das Zuweisen von 

„öffentlichen“ IP-Adressen an die VMs 

behandelt dann der dritte Teil der Serie 

im kommenden Admin-Magazin 02/2013 

ausführlich. (jcb) 

n 

Infos 

[1] Keystone-Data-Skript: [http:// people. 

madkiss. org/ ~madkiss/ openstack/ 

keystone_data. sh] 

[2] Keystone-Endpoints-Skript: [http:// 

people. madkiss. org/ ~madkiss/ openstack/ 

endpoints. sh] 

[3] Quantum-Networking-Skript: [http:// 

people. madkiss. org/ ~madkiss/ openstack/ 

quantum‐networking. sh] 

[4] Beispielhafte nova.conf [http:// people. 

madkiss. org/ ~madkiss/ openstack/ nova. 

conf] 

[5] nova.conf-Referenz: [http:// docs. 

openstack. org/ essex/ openstack‐compute/ 

admin/ content/ compute‐options‐reference. 

html] 

Abbildung 7: Das Dashboard zeigt zu gestarteten VMs diverse Informationen wie die zugewiesene IP-Adresse 

und auch die Hardware-Konfiguration an. 

Der Autor 

Martin Gerhard Loschwitz arbeitet als Principal 

Consultant bei hastexo. Er beschäftigt sich dort 

intensiv mit Hochverfügbarkeitslösungen und 

pflegt in seiner Freizeit den Linux-Cluster-Stack 

für Debian GNU/Linux. 


Admin 


79

Test 

Exchange 2013 

© Wojciech Kaczkowski, 123RF 

Änderungen in Exchange Server 2013 

Neues Gewand 

Mit Exchange Server 2013 [1] hat Microsoft die neueste Version seiner 

Groupware-Lösung fertiggestellt. Dieser Artikel stellt die Neuerungen des 

Servers vor und berichtet, welche Funktionen weggefallen sind. Thomas Joos 

Schon während der Installation von Exchange 

Server 2013 fällt auf, dass der 

neue Server weitaus weniger Optionen 

anbietet. Die Serverrollen Hub-Transport 

und Unified-Messaging hat Microsoft gestrichen. 

Die Funktion der beiden Rollen 

übernehmen die Postfachserver und 

Clientzugriffserver in der neuen Version. 

Für den E-Mail-Transport in Exchange 

Server 2013 sind die drei Dienste Front- 

End Transport Service (FET), Hub Transport 

Service (HT) und Mailbox Transport 

Service (MT) zuständig, die jetzt zur 

Postfachserver-Rolle gehören. 

Die Transportdienste sind auch für die 

Umsetzung der verbesserten Transportregeln 

zuständig (Abbildung 1). Letztere 

tragen die Bezeichnung Data Loss Prevention 

(DLP) und sollen verhindern, 

dass sensible Daten noch das Firmennetz 

verlassen. Zusätzlich ist in Exchange Server 

2013 ein Virenscanner integriert. Die 

Server scannen alle ein- und ausgehenden 

E-Mails nach Viren. Unternehmen, 

die auf einen Virenscanner von Drittherstellern 

setzen, können diese Funktion 

natürlich deaktivieren. 

Hot gefixt 

Exchange Server 2013 lässt zwar generell 

in bestehende Organisationen mit 

Exchange Server 2007/2010 installieren. 

Dazu ist aber das SP3 für Exchange Server 

2010 notwendig, sowie ein Hotfix für 

Exchange Server 2007. Ältere Versionen 

wie Exchange Server 2000/2003 lassen 

sich nicht mit Exchange Server 2012 betreiben. 

Öffentliche Ordner-Datenbanken gibt es 

in Exchange Server 2013 in der bekannten 

Form nicht mehr, aber öffentliche 

Ordner sind natürlich weiterhin verfügbar. 

Gemeinsame Inhalte werden jetzt 

über spezielle Postfächer zur Verfügung 

gestellt, die wiederum zur Ausfallsicherheit 

mit Datenbankverfügbarkeits-Gruppen 

(DAG) abgesichert werden. Diese 

sind auch in der neuen Version noch 

verfügbar. Öffentliche Ordner sind daher 

in Exchange Server 2013 als Postfach innerhalb 

der Postfachdatenbank abgebildet. 

Um öffentliche Ordner zu nutzen, 

erstellen Sie zunächst ein Postfach für 

öffentliche Ordner und danach die öffentlichen 

Ordner in diesem Postfach. 

Exchange Administrative 

Center 

Die Verwaltung der Exchange-Infrastruktur 

findet vermehrt im erweiterten und 

webbasierten Exchange Administration 

Center (EAC) statt. Es gibt auch weiterhin 

die Exchange Verwaltungsshell, die jetzt 

auf der Powershell 3.0 basiert. Die Exchange-Verwaltungskonsole 

gibt es in Exchange 

Server 2013 nicht mehr. Die EAC 

ist nach der Installation über »https:// 

Servername/ecp« erreichbar (Abbildung 

2). Sie haben auch die Möglichkeit, 

Office 365 an diese Konsole anzubinden. 

Die Kommunikation von Outlook und 

Exchange findet in den neuen Versionen 

über HTTP(S) statt, MAPI findet keine 

Verwendung mehr. Aus diesem Grund 

lassen sich nur noch Outlook 2007/2010 


Exchange 2013 

Test 

und 2013 an Exchange Server 2013 anbinden. 

Ältere Versionen, zum Beispiel 

Outlook 2000/2003, werden nicht mehr 

unterstützt. 

Die Datenbankverfügbarkeitsgruppen 

(DAG) gibt es bereits in Exchange Server 

2010. Diese haben als Betriebssystem 

Windows Server 2008/2008 R2 Enterprise/Datacenter 

als Betriebssystem vorausgesetzt. 

Da in Windows Server 2012 

die Editionen Standard/Datacenter identisch 

sind, und es keine Enterprise-Edition 

mehr gibt, lassen sich DAG auch mit 

Windows Server 2012 Standard nutzen. 

DAG sind auch Bestandteil der Standard- 

Edition von Exchange Server 2013. 

Das Verschieben von Postfächern zu Exchange 

Server 2013 hat Microsoft ebenfalls 

verbessert. Es lassen sich mehr Postfächer 

und E-Mail-Benachrichtigungen 

auf einmal verschieben. Bei Problemen 

kann der Assistent wiederholen, und 

Postfächer können priorisiert werden. 

Außerdem besteht die Möglichkeit, den 

Zugriff nach dem Verschieben erst nach 

einer Überprüfung freizuschalten. 

Exchange Server 2013 

installieren 

Um Exchange Server 2013 zu installieren, 

ist auf dem Server die Erweiterung 

Microsoft Unified Communications Managed 

API 4.0, Core Runtime 64-Bit [2] 

notwendig, ebenso wie Microsoft Office 

2010 Filter Packs – Version 2.0 [3] 

und Microsoft Office 2010 Filter Packs 

– Version 2.0 – Service Pack 1 [4]. Diese 

drei Voraussetzungen müssen Sie manuell 

installieren, alles andere kann der 

Exchange-Installationsassistent automatisch 

laden. Die neue Version ist nur als 

64-Bit-System verfübar. Die Domäne darf 

zwar auf Domänencontroller basieren, 

die mit 32-Bit-Versionen von Windows 

Server 2003 laufen, Microsoft empfiehlt 

aber auch, die Domänencontroller mit 

einem 64-Bit-System zu installieren. 

Microsoft empfiehlt für Postfachserver 

mindestens 8 GByte freien Arbeitsspeicher, 

für Clientzugriff-Server mindestens 

4 GByte. Sie können Exchange nicht auf 

Core-Servern installieren, es ist eine vollständige 

Installation von Windows Server 

2008 R2 oder am besten Windows Server 

2012 notwendig. Die Verwaltungstools 

von Exchange Server 2013 können Sie 

Abbildung 1: Mit neuen Transportregeln lässt sich Exchange Server 2013 besser absichern. 

auch auf Arbeitsstationen mit Windows 

7/8 installieren. 

Erweitertes Schema 

Vor der Installation von Exchange Server 

2013 bietet es sich an, über den Server- 

Manager die Remoteserververwaltungs- 

Tools für Active Directory auf dem Exchange-Server 

zu installieren, das Snap-In 

Active Directory-Schema zu starten und 

über das Kontextmenü eine Verbindung 

zum Schemamaster aufzubauen. Wie 

jede neue Exchange-Version erweitert 

auch Exchange Server 2013 das Schema. 

Bei einer Neuinstallation von Exchange 

Server 2013 geben Sie den Befehl »setup 

Abbildung 2: Die Verwaltung von Exchange Server 2013 findet webbasiert statt. 

/prepareAd /IAcceptExchangeServer- 

LicenseTerms /OrganizationName: Organisationsname« 

ein, damit der Assistent 

das Active Directory-Schema erweitert. 

Neben Schemaerweiterungen und Rechten, 

legen diese Befehle eine neue OU mit 

den entsprechenden Sicherheitsgruppen 

an. Mit »setup /PrepareAllDomains« bereiten 

Sie alle Domänen der Gesamtstruktur 

für Exchange vor. 

Die Schemaerweiterungen sollten Sie 

am besten direkt auf dem Schemamaster 

durchführen. Welcher das in der Gesamtstuktur 

ist, lässt sich über »dsquery 

server ‐hasfsmo schema« erfahren. In 

einigen Fällen erscheint ein Schema-Erweiterungsfehler 

mit der Nummer 8224. 


Admin 


83

Test 

Exchange 2013 

Abbildung 3: Den E-Mail-Fluss verwalten Sie in der Exchange-Verwaltungskonsole an der zentralen Stelle 

»Nachrichtenfluss«. 

Dieser ist vor allem auf virtuellen Servern 

häufig. Das Problem liegt an TCP Chimney 

Offload and Receive Side Scaling, da 

hier die Funktionen von der CPU, nicht 

der Netzwerkkarte berechnet werden. 

Das Problem lässt sich lösen, indem man 

die beiden Funktionen deaktiviert. Das 

funktioniert in der Befehlszeile mit: 

netsh int tcp set global rss=disabled 

netsh int tcp set global chimney=disabled 

Der Befehl »netsh int tcp show global« 

zeigt den Status an. 

E-Mail-Versand und 

‐Empfang konfigurieren 

Der Empfang- und Versand von E-Mails 

setzt sich aus verschiedenen Bereichen 

zusammen. Nach der Installation kann 

ein Exchange-Server zunächst noch 

keine E-Mails empfangen und senden. 

Sie müssen dazu erst einige Einstellungen 

in der Exchange-Verwaltungskonsole 

vornehmen. Hier fällt auf, dass Microsoft 

die verschachtelte Struktur der alten Exchange-Verwaltungskonsole 

überarbeitet 

und die notwendigen Befehle in einen 

gemeinsamen Bereich integriert hat: 

»E‐Mail‐Empfang – Exchange« nimmt 

zunächst nur E-Mails für Domänen an, 

die im Menü »Nachrichtenfluss« bei »Akzeptierte 

Domänen« hinterlegt sind (Abbildung 

3). Damit ein Exchange-Server 

E-Mails entgegennehmen kann, muss ein 

Empfangsconnector erstellt und so konfiguriert 

sein, dass er E-Mails vom sendenden 

Server akzeptiert. Empfangsconnectoren 

finden Sie über »Nachrichtenfluss 

| Empfangsconnectors«. Standardmäßig 

legt Exchange bereits Connectoren an. 

Damit Exchange-Server E-Mails intern 

zustellen können, muss die E-Mail- 

Adresse in der E-Mail in der Organisation 

vorhanden sein. Welche E-Mail- 

Adressen der Server an die Anwender 

verteilt, sehen Sie auf der Registerkarte 

»E‐Mail‐Adressenrichtlinie« im Bereich 

»Nachrichtenfluss«. Postfächer für Anwender 

erstellen Sie über »Empfänger | 

Postfächer«. An dieser Stelle können Sie 

auch gleich neue Benutzerkonten im Active 

Directory anlegen. Damit Exchange 

E-Mails nach extern versenden kann, 

muss mindestens ein Sendeconnector 

erstellt sein. Diese Konfiguration finden 

Sie über »Nachrichtenfluss« auf der Registerkarte 

»Sendeconnectors«. Nach der 

Installation ist noch kein solcher Sendeconnector 

vorhanden. 

Hilfe bei der SMTP- 

Diagnose 

Ein wichtiges Diagnoseprogramm für den 

E-Mail-Fluss ist Smtpdiag, das Sie von 

der Microsoft-Internetseite [5] kostenlos 

he runterladen können. Mit diesem Tool 

können Sie Probleme beim SMTP-Versand 

in der Eingabeaufforderung diagnostizieren 

und so die Sendeconnectors des Servers 

testen. Die Installationsdateien des 

Tools enthalten ein ausführliches Word- 

Dokument, das die Verwendung erklärt. 

Das Tool überprüft, ob eine E-Mail per 

SMTP zugestellt werden kann. Geben Sie 

den Befehl »smtpdiag Absenderadresse 

Empfängeradresse« ein, zum Beispiel 

»smtpdiag joost@contoso.com thomas. 

joos@web.de«. Das Tool überprüft dann, 

ob der Server die E-Mail durch die DNS- 

Auflösung zustellen könnte, und gibt 

Probleme sehr detailliert aus. Sie sehen 

bei der Ausgabe auch, wenn Server Verbindungen 

nicht akzeptieren und können 

gezielt bei den entsprechenden Servern 

zur Fehlerbehebung ansetzen. 

Über die Microsoft-Seite [6] können Sie 

die Verbindung Ihrer Exchange-Organisation 

mit dem Internet testen. Das Tool 

dient zum Testen der Verbindung von 

Outlook, Smartphones oder Office 365. 

Haben Sie den gewünschten Test ausgewählt, 

geben Sie noch die Daten des 

Exchange-Servers ein, den Sie testen wollen, 

und die Benutzerdaten, mit denen 

Sie die Verbindung aufbauen. Anschließend 

testet das Tool die Verbindung und 

zeigt an, ob die Konfiguration funktioniert 


Exchange Server 2013 und 

Sharepoint Server 2013 

Unternehmen, die Sharepoint 2013 einsetzen, 

können über Sharepoint besser 

Postfächer und öffentliche Ordner in Exchange 

Server 2013 durchsuchen. Dazu 

verwendet der neue Exchange-Server 

eine vollkommen neue Suchschnittstelle. 

E-Mails die Anwender in Sharepoint 2013 

auf Servern mit Exchange Server 2013 

finden, lassen sich sogar in PST-Dateien 

exportieren. Auch an Fast Search Server 

lässt sich Exchange anbinden. Die neue 

Exchange-Version lässt sich auch an Domänen 

anbinden, die auf Windows Server 

2003 basieren, es ist nicht unbedingt 

Windows Server 2012 notwendig. Sie können 

Exchange Server 2013 zwar auf Domänencontrollern 

installieren, Microsoft 

empfiehlt das allerdings nicht. Wenn Sie 

Exchange installiert haben, können Sie 

allerdings den Server weder zu einem 

Domänencontroller heraufstufen, noch 

einen Domänencontroller herabstufen, 

nachdem Exchange installiert ist. 

Microsoft gibt Exchange Server 2013 auch 

für die Virtualisierung [7] frei. Optimal 

dazu geeignet ist Hyper-V in Windows 

Server 2012, aber auch Windows Ser- 


Exchange 2013 

Test 

ver 2008 R2 wird unterstützt. 

Outlook 2003 und verknüpfte 

Connectoren sind in Exchange 

Server 2013 nicht mehr verfügbar. 

Diese lassen sich daher 

nicht mehr nutzen. Bei 

einer solchen Verknüpfung 

sendet Exchange alle E-Mails, 

die über einen bestimmten 

Empfangsconnector eingehen, 

unabhängig von anderen 

Regeln über den verknüpften 

Sendeconnector. Eine solche 

Verknüpfung hat immer Vorrang. 

Die Verknüpfung erfolgt 

über die Exchange-Verwaltungsshell. 

Für verknüpfte 

Connectoren werden andere 

Connectoren und Regeln immer 

deaktiviert. Vor dem Einsatz von 

Exchange Server 2012 müssen Sie diese 

Connectoren daher auflösen. 

Auch die verwalteten Ordner sind nicht 

mehr verfügbar. Deren Funktionen sind 

jetzt in den Retention Policies integriert. 

Aktivieren Sie die Anti-Spam-Filter auf 

Postfach-Servern, lassen sich diese nur 

noch in der Exchange-Verwaltungsshell 

verwalten. Die Hub-Transport- und Unfied-Messaging-Serverrollen 

sind nicht 

mehr verfügbar. Die Funktion dieser 

Server übernehmen Postfachserver und 

Clientzugriffserver. Die MMC-basierte 

Management-Konsole gehört der Vergangenheit 

an. Die Verwaltung findet entweder 

über die Exchange-Verwaltungsshell 

oder die webbasierte Verwaltungskonsole 

statt. 

Die Verwaltung der Datenbanken, der 

angebundenen Smartphones/Tablets 

und der Grenzwerte für Postfächer hat 

Microsoft enorm vereinfacht. Es gibt we- 

Abbildung 4: Microsoft unterstützt bei der Diagnose von Verbindungen. 

niger Menüs und keine verschachtelten 

Strukturen mehr. 

Die neue Exchange-Version unterstützt 

keinen Zugriff mehr auf freigegebene 

Postfächer anderer Benutzer, die Moderation 

von Verteilerlisten, S/MIME und Anpassungen 

des Lesebereichs in Outlook 

Web App. Außerdem hat Microsoft viele 

Tools wie den Best Practices Analyzer 

entfernt. Die Tools unterstützen nur noch 

Exchange Server 2010. Neben diesen Tool 

hat Microsoft auch den Log-Viewer und 

andere Anwendungen aus der Toolbox 

entfernt. 

Outlook Web App 

Für Anwender hat Microsoft die Oberfläche 

von Outlook Web App erneuert. 

Diese ist an Outlook 2013 orientiert. Einmal 

synchronisiert, können Anwender 

auch offline mit Outlook Web App 2013 

arbeiten. Neu ist auch die Integration von 

Abbildung 5: Die Outlook Web App hat Microsoft an seine aktuelle Design-Strategie angepasst. 

Apps für Outlook Web App. 

So lässt sich die Oberfläche 

mit neuen Funktionen erweitern. 

OWA 2013 funktioniert 

am besten mit Firefox ab Version 

14, Chrome ab Version 

18 und Internet Explorer ab 

Version 10. Die neue Oberfläche 

hat Microsoft auch für 

den Touch-Betrieb optimiert, 

sodass auch Anwender mit 

Tablets und Clients damit 

arbeiten können (Abbildung 

5). Auch die Ansicht des Kalenders 

und der Kontakte hat 

Microsoft verbessert. 

Exchange-Zertifikat 

ändern 

Exchange Server 2013 setzt wie die Vorgänger 

auf SSL-gesicherte Verbindungen 

und Verschlüsselung. Aus diesem Grund 

benötigt jeder Exchange-Server ein eigenes 

Serverzertifikat. Während der Installation 

stellt sich jeder Exchange-Server 

ein selbst signiertes Zertifikat aus. Das 

Problem dabei ist, dass kein Client dieser 

Zertifizierungsstelle vertraut, was in Zertifikatsfehlermeldungen 

resultiert. Eine 

Lösung für das Problem ist entweder auf 

eine interne Zertifizierungsstelle auf Basis 

der Active Directory-Zertifikatsdienste zu 

setzen, oder ein Zertifikat eines Drittherstellers. 

Internen Zertifizierungsstellen 

vertrauen Clients, die Mitglied der gleichen 

Active Directory-Gesamtstruktur 

sind, automatisch. Bei Zertifizierungsstellen 

von Drittherstellern müssen Sie 

das Zertifikat der Zertifizierungsstelle 

manuell in die vertrauenswürdigen 

Stammzertifizierungsstellen integrieren, 

sofern diese noch nicht bekannt ist. 

In Exchange Server 2013 haben Sie die 

Möglichkeit, Serverzertifikate direkt in 

der webbasierten Exchange-Verwaltungskonsole 

zu verwalten. Um dem Server 

ein Zertifikat zuzuweisen, klicken Sie in 

der Exchange-Verwaltungskonsole auf 

Server und dann auf »Zertifikate«. Jeder 

Exchange-Server in der Organisation erhält 

sein eigenes Zertifikat. Um ein neues 

Zertifikat zu installieren, klicken Sie zunächst 

auf das Pluszeichen. Der Assistent, 

erstellt eine Zertifikatanforderung 

die Sie dann entweder über die Active- 

Directory-Zertifikatdienste anfordern 


Admin 


85

Test 

Exchange 2013 

oder über das Webfrontend 

des Drittherstellers. 

Anbinden 

den Zertifikaten dieser Zertifizierungsstelle 

vertraut. 

Fazit 

Im ersten Schritt des Assistenten 

geben Sie den Namen 

ein, mit dem das Zertifikat in 

der Konsole angezeigt werden 

soll. Auf der nächsten Seite 

legen Sie fest, dass Sie auch 

untergeordnete Domänen mit 

dem gleichen Zertifikat anbinden 

wollen. Anschließend 

wählen Sie den Server aus, 

auf dem Sie die Anforderung 

des Zertifikats speichern wollen 


Im Assistenten geben Sie noch den Namen 

der Domäne ein, über die von extern 

oder intern auf die Server zugegriffen 

werden soll. Ihnen zeigt der Assistent 

an, welche Domänen im Zertifikat für 

den Zugriff hinterlegt sind. Sehr wichtig 

an dieser Stelle ist, dass Sie den Namen 

mit dem der Server aus dem Internet 

erreichbar ist, als allgemeiner Name hinterlegen. 

Ansonsten erhalten Clients, die aus dem 

Internet auf den Server zugreifen, eine 

Fehlermeldung, da der Name des Zertifikats 

nicht mit der URL für den Zugriff 

übereinstimmt. Dieser Bereich ist 

vor allem für die Verwendung von Outlook 

Anywhere sehr wichtig. Wenn ein 

Zertifikatsfehler in Outlook Web App erscheint, 

können Anwender diesen ohne 

große Auswirkungen bestätigen, Outlook 

verweigert allerdings die Verbindung bei 

solchen Fehlern. Auf der nächsten Seite 

geben Sie noch Daten zu dem Zertifikat 

und Ihrer Organisation an und speichern 

anschließend die Anforderung als Text- 

Datei. Mit dieser Datei fordern Sie das 

Zertifikat anschließend an. 

Webkonfiguration 

Im nächsten Schritt öffnen Sie das 

Webfrontend des Zertifikateausstellers. 

Arbeiten Sie mit den Active Directory- 

Zertifikatdiensten, können Sie diese über 

die Adresse »https://Servername/certsrv« 

erreichen. Als Nächstes wählen Sie die 

Option »Reichen Sie eine Zertifikatanforderung 

ein, die eine Base64‐codierte 

CMD‐ oder PKCS10‐Datei verwendet, 

Abbildung 6: Über SSL-Zertifkate sichern Sie Exchange vor Gefahren ab. 

oder eine Erneuerungsanforderung, die 

eine Base64‐codierte PKCS7‐Datei verwendet«. 

Im nächsten Fenster, geben Sie im Feld 

»Gespeicherte Anforderung« den kompletten 

Text der »*.req«-Datei ein, die 

Sie im Vorfeld erstellt haben. Sie können 

dazu die Datei im Editor öffnen und den 

Inhalt in die Zwischenablage kopieren. 

Sie müssen den kompletten Text der Datei 

dazu verwenden. Klicken Sie dazu in die 

Datei, und markieren Sie den kompletten 

Text mit [Strg]+[A]. Mit [Strg]+[C] 

kopieren Sie den Text in die Zwischenablage, 

mit [Strg]+[V] fügen Sie ihn in das 

Feld ein. Wählen Sie als Zertifikatvorlage 

noch »Webserver«, und klicken Sie dann 

auf »Einsenden«. 

Anschließend laden Sie das Zertifikat als 

»*.cer«-Datei herunter und speichern sie 

auf dem Server. Danach wechseln Sie 

wieder in die Exchange-Verwaltungskonsole 

und klicken auf »Server | Zertifikate«. 

Klicken Sie auf das Zertifikat in der Konsole 

und dann auf »Abschließen«. Geben 

Sie anschließend den Pfad der »*.cer«- 

Datei ein, und schließen Sie den Vorgang 

ab. Das Zertifikat sollte jetzt als »Gültig« 

angezeigt werden. Dazu muss es der Zertifizierungsstelle, 

von der Sie das Zertifikat 

stammt, bei den vertrauenswürdigen 

Stammzertifizierungsstellen auf dem Exchange-Server 

hinterlegt sein. Arbeiten 

Sie mit den Active-Directory-Zertifikatsdiensten, 

installiert der Exchange-Server 

das Zertifikat der Vertrauensstellung automatisch 

über die Gruppenrichtlinien. 

Das Zertifikat der Stammzertifizierungsstelle 

muss auf dem Exchange-Server hinterlegt 

sein, damit der Exchange-Server 

Exchange Server 2013 enthält 

zahlreiche Neuerungen, die 

nicht unbedingt eine Aktualisierung 

von Exchange Server 

2007/2010 rechtfertigen. Lange 

erwartete Änderungen wie die 

Integration der Datenbanken 

in SQL-Server sucht man vergebens. 

Die Verwaltung ist 

etwas einfacher, allerdings ist 

die Weboberfläche nicht ganz 

so bequem wie die bewährte 

Exchange-Verwaltungskonsole. Die Integration 

eines Virenschutzes ist schön, 

allerdings hat eh jedes Unternehmen, das 

auf Exchange setzt, schon einen Scanner 

für Postfächer. Die neuen Transportregeln 

dienen vor allem der Sicherheit. 

Office 365 lässt sich genauso an Exchange 

Server 2010 anbinden wie an Exchange 

Server 2013. Aus unserer Sicht 

rechtfertigen die Änderungen kaum ein 

Update. Nur Unternehmen die von anderen 

Systemen zu Exchange wechseln 

wollen, sollten gleich die neue Version 

verwenden. Diese ist im Vergleich natürlich 

etwas schneller, unterstützt Windows 

Server 2012 besser und arbeitet besser 

mit Sharepoint zusammen. Revolutionäre 

Änderungen gibt es nicht. (ofr) n 

Infos 

[1] Exchange Server 2013: [http:// technet. 

microsoft. com/ en‐US/ exchange/ fp179701] 

[2] Unified Communications Managed API 4.0 

Runtime: [http:// go. microsoft. com/ fwlink/ 

? LinkId=260990] 

[3] Microsoft Office 2010 Filter Packs: [http:// 

go. microsoft. com/ fwlink/ ? LinkID=191548] 

[4] Service Pack 1 for Microsoft Office Filter 

Pack 2010: [http:// go. microsoft. com/ 

fwlink/ ? LinkId=262358] 

[5] Smtpdiag: 

[http:// www. microsoft. com/ downloads/ 

details. aspx? displaylang=de& FamilyID=bc1 

881c7‐925d‐4a29‐bd42‐71e8563c80a9] 

[6] Remote Connectivity Analyzer: [https:// 

www. testexchangeconnectivity. com] 

[7] Exchange 2013 Virtualization: 

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

library/ jj619301. aspx] 


Linux-Magazin 

ACADEMY 

JETZT MIT NEUEN 

Lernzielen! * 

*Anpassung der Lernziele 2012 

Online-Training 

Prüfungsvorbereitung 

für LPIC 1 & 2 

20% 

Treue-Rabatt für 

Abonnenten 

Besorgen Sie sich Brief und Siegel für Ihr 

Linux-Knowhow mit der LPI-Zertifizierung. 

- Training für die Prüfungen LPI 101 und 102 

- Training für die Prüfungen LPI 201 und 202 

Sparen Sie mit Paketpreisen! 

Auszug aus dem Inhalt: 

❚ Hardware-Einstellungen, 

Paketverwaltung 

❚ Arbeiten auf der Kommandozeile 

❚ Partitionen und Dateisysteme 

❚ Shell-Umgebung 

❚ Netzkonfiguration und -verwaltung 

❚ Protokolle 

❚ DNS-Server einrichten und verwalten 

❚ Verschlüsselung und Rechteverwaltung 

❚ Kernel kompilieren und patchen 

❚ RAID-Konfiguration, 

Logical Volume Manager 

❚ Web-, Proxy-, Samba-Server 

Mit vielen Praxisbeispielen! 

* Anpassung der Lernziele in 2012 

academy.linux-magazin.de/lpic

Test 


© Sunagatov Dmitry, 123RF 

Im Test: Thomas Krenns Low Energy Server 

Schön schlank 

Kleiner als ein externes CD-Laufwerk, leicht, leise und extrem sparsam im 

Energieverbrauch – so präsentiert sich Thomas Krenn’s Low Energy Server. 

Das ADMIN-Magazin hat ihn getestet. Jens-Christoph Brendel 

weiter, wenn man das Kistchen als Server 

ernst nimmt – als Client für eine Webanwendung 

oder eine Desktopvirtualisierung 

zum Beispiel ist es so allerdings 

nicht nutzbar. 

Gut vorstellbar sind aber Anwendungen 

als LDAP-Server, als FTP- oder Fileserver, 

als Name- oder DHCP-Server, als (kleiner) 

Web- oder Mailserver und dergleichen 

– an passender Software mangelt 

es in den Debian-Repositories jedenfalls 

nicht. Hinzukommen manche Bereiche 

der Softwareentwicklung, wo es nicht 

um Performancetests geht und wo keine 

Projekte im Kernel-Format kompiliert 

werden. Dort tut der Kleine sicher gute 

Dienste. Auch wo der Server mobil sein 

soll, beispielsweise für Kunden-Demos, 

kann das Modell von Krenn seine Vorteile 

ausspielen. Wo genau die Grenzen verlaufen, 

sollen Benchmarks klären. 

Server werden normalerweise ja mit 

dem Hubwagen angeliefert, diesen aber 

konnte man getrost einhändig zum 

Schreibtisch tragen, denn Thomas Krenns 

„Low Energy Server“ im Format einer 

Zigarrenkiste (4,5 H x 12 B x 16 T cm) 

bringt es nur auf 875 Gramm (Abbildung 

1). Das 18-Watt-Netzteil kommt separat, 

ein optisches Laufwerk ließe sich auch 

nur extern via USB konnektieren, und an 

die Stelle einer Grafikkarte tritt Intels in 

den Chipsatz integrierter Graphics Media 

Accelerator in der kleinsten Ausführung 

GMA 500. 

Sparsam und schlank 

Lohn der Zurückhaltung bei der Ausstattung 

ist ein tatsächlich bemerkenswert 

niedriger Energieverbrauch: Um die 6 

Watt sind es in Ruhe. Selbst wenn man 

den kleinen Server etwa mit dem Linux- 

Tool »stress« schwer beschäftigt, kommt 

man unter hoher CPU-Last kaum über 

8 Watt und bleibt bei I/O-Stress immer 

noch unter 9 Watt. Ein normaler PC-Tower 

schluckt unter diesen Bedingungen 

schon mal gerne 150 Watt. Bei all dem 

bleibt das Gehäuse handwarm und absolut 

lautlos – denn es gibt keinen Lüfter 

(Abbildung 2), die Kühlung funktioniert 

rein passiv. In unser Exemplar passte 

eine optionale, zweite Gigabit-Ethernet- 

Schnittstelle, alternativ wäre auch WLAN 

möglich gewesen. 

Eine reine Serveranwendung bräuchte sicher 

keinen permanenten Monitor. Rechnet 

man den nämlich mit ein, relativiert 

sich der Energiesparvorteil ein wenig, 

denn ein Standard-Monitor frisst alleine 

dreimal so viel Strom wie der unbelastete 

Low Energy Server. In dieser Konstellation 

sparte ein Netbook mehr Energie, 

das mit einer ähnlichen CPU selbst unter 

Last mit 18 Watt auskommt und damit 

auch sein – freilich kleineres – Display 

versorgt. 

Nach dem Booten – was unser Exemplar 

dank Intel-SSD an Stelle einer Festplatte 

recht zügig absolvierte – landet man in 

einem ASCII-Terminal unter einem sehr 

schlanken Debian 6.0.6 mit weniger als 

300 installierten Paketen. Ein grafischer 

Desktop ist nicht am Start. Das stört nicht 

Benchmarks 

Für diese Benchmarks haben wir eine 

Reihe anderer Geräte zum Vergleich 

herangezogen. Der am leichtesten zu 

schlagende Konkurrent war ein Netbook 

HP mini, ebenfalls mit Atom-CPU unter 

einem aktuellen Ubuntu 12.04. Eine 

Stufe über ihm rangierte ein Mittelklasse 

Laptop als Mitbewerber, ein ThinkPad 

Edge mit Pentium B940-CPU und 4 GByte 

RAM. Und schließlich ließen wir auch 

noch einen ausgewachsenen kleinen Server 

antreten, einen Dell PowerEdge T110 

mit Intel Core i3-CPU und 8 GByte RAM 

(Tabelle 1). 

Gemessen haben wir mit dem Sysbench- 

Benchmark [1], der sowohl Aussagen 

über die Rechenleistung als auch über die 

I/O-Performance bietet und gemeinsam 

mit MySQL auch eine OLTP-Last bewältigt. 

Eigentlich ist dieser Benchmark einmal 

für Datenbanken entwickelt worden, 

aber das Zusammenspiel seiner Komponenten 

ergibt auch für manche andere 

Anwendungen einen einen ganz guten 

Querschnitt des aktuellen Leistungsvermögens. 

Tabelle 1: Die Probanden 

Krenn-Server Netbook Laptop DELL-Server 

CPU-Typ Intel Atom Z530 Intel Atom N450 Intel Pentium B940 Intel Core i3 530 

Takt (GHz) 1,6 1,66 2 2,93 

RAM (GByte) 1 1 4 8 

Platte/SSD Intel SSD SA2CW080G3 Hitachi Travelstar 7K500 WDC WD5000BPVT WDC WD1002FBYS 

Plattenkapazität (MByte) 80 500 500 1000 



Test 

Abbildung 1: Ein Server im Format einer 

Zigarrenkiste – außerdem geräuschlos und sehr 

genügsam im Stromverbrauch. 

Das Rechnen, so viel ist schnell klar, ist 

nicht die große Stärke des Stromsparservers. 

In dieser Disziplin belegt er den 

letzten Platz, noch hinter seinem Atom- 

Geschwister, dem Netbook. Beide werden 

von den Konkurrenten mit den stärkeren 

CPUs klar distanziert (Abbildung 3). 

Anders sieht es beim I/O aus: Hier ist 

der Stromsparserver in seinem Element, 

denn an seine SSD kommen mechanische 

Platten natürlich nicht heran (Abbildung 

4). Der Dell-Server hat allerdings so viel 

RAM, dass die 10 GByte Testfiles fast 

komplett in seinen Cache passen. Dadurch 

kommt er trotz herkömmlicher 

Abbildung 2: Lüfter finden sich keine in dem Mini- 

Server, die CPU wird passiv gekühlt und gibt die 

Abwärme über das Gehäuse ab. 

Festplatte auf kokurrenzfähige Werte. 

Die beiden mit RAM nicht so gut ausgestatteten 

Probanden stoßen dagegen an 

die Grenzen der Plattenmechanik. Die 

Kehrseite der Medaille ist freilich, dass 

man die drei Rechner mit Platten und 

ganz besonders den Dell-Server mit moderaten 

Kosten auf viel höhere Speicherkapazitäten 

aufrüsten kann, wogegen das 

Volumen der SSD des Stromsparservers 

nicht auf ein Vielfaches wachsen könnte, 

soll er bezahlbar bleiben. 

In der Disziplin OLTP-Workload, bei der 

sich Zugriffe auf den Massenspeicher mit 

Berechnungen mischen, haben wieder die 

beiden Testteilnehmer mit den schwachbrüstigen 

Atom-CPUs das Nachsehen 

(Abbildung 5). Das Rennen machte der 

überraschend gut platzierte Laptop Kopf 

an Kopf mit dem DELL-Server. 

Fazit 

Verglichen mit einem Standard-PC kann 

man mit dem Low Energy Server im Jahr 

vielleicht an die 140 Euro Stromkosten 

sparen. Dann hätte er sich in gut drei Jahren 

amortisiert – die Preise beginnen bei 

500 Euro. Wenn die Entwicklungsabteilung 

geschlossen umsteigt, kann sie sich 

so die Weihnachtsfeier finanzieren. Das 

aber wäre nicht der einzige Vorteil: Es 

stünden zusätzlich mehr Platz auf dem 

Schreibtisch oder im Serverraum, viel 

weniger Lärm und keine Abwärme auf 

der Haben-Seite. Wo die Rechenleistung 

für den Wechsel ausreicht – das ist das 

hauptsächliche Gegenargument – sollte 

der sparsame Server Kunden für sich gewinnen 

und zufriedenstellen können. n 

Infos 

[1] Sysbench: [http:// sysbench. sourceforge. 

Primzahlen bis 20 000 

Laufzeit der Berechnung (größer ist schlechter) 

Random File-I/O 

Mittlere Zugriffszeit pro Request (kleiner ist besser) 

OLTP-Workload 

Transactions pro Sekunde (größer ist besser) 

Sekunden 

ms 

transactions/s 

Krenn- 

Server 

Netbook 

Kandidaten 

Laptop 

DELL- 

Server 

Krenn- 

Server 

Netbook 

Kandidaten 

Laptop 

DELL- 

Server 

Krenn- 

Server 

Netbook 

Kandidaten 

Laptop 

DELL- 

Server 

Abbildung 3: In puncto Rechenleistung bewegt sich 

der Low Energy Server auf Netbook-Niveau. 

Abbildung 4: Dank der eingebauten SSD kann der 

Energiesparserver beim I/O punkten. 

Abbildung 5: Der OLTP-Aufgabenmix zwingt die Kontrahenten 

mit Atom-CPU deutlich früher in die Knie. 

MAGAZIN 

ONLINE 

Linux-Magazin newsLetter 

Newsletter 

informativ 

Nachrichten rund um die Themen Linux und 

Open Source lesen Sie täglich im Newsletter 

des Linux-Magazins. 

kompakt 


tagesaktuell 

www.linux-magazin.de/newsletter 

Admin 

Ausgabe 01-2013 89

Security 

SHA-3 

© crstrbrt, 123RF 

SHA-3, der neue Hash-Standard 

Uneinsichtig 

Nach fünf Jahren hat die US-Standardisierungsorganisation vor Kurzem den Algorithmus Keccak zum neuen 

kryptographischen Hash-Standard gekürt. In der Praxis lässt jedoch selbst die Umstellung auf den Vorgänger 

SHA-2 noch auf sich warten. Hanno Böck 

Kryptographische Hash-Funktionen 

sind ein wichtiger Baustein bei der sicheren 

Kommunikation im Internet. In 

den letzten Jahren geriet hier einiges in 

Bewegung. Die lange Zeit eingesetzten 

Verfahren MD5 und SHA-1 waren sich 

plötzlich nicht mehr so sicher wie ursprünglich 

gedacht. So nutzte der Virus 

Flame, der im Mai diesen Jahres auf 

zahlreichen Rechnern im nahen Osten 

entdeckt wurde, die Schwäche von MD5, 

um sich über den Update-Service von 

Windows zu installieren. 

Infolge der kryptographischen Durchbrüche 

entschied die US-Standardisierungsbehörde 

NIST (National Institute 

for Standards and Technology), einen 

Wettbewerb [1] zur Entwicklung eines 

neuen Hash-Standards ins Leben zu rufen. 

Vor wenigen Wochen wurde der Sieger 

gekürt: Der Algorithmus Keccak [2], 

entwickelt von einem belgischen Team 

von Wissenschaftlern. Es ist der zweite 

Wettbewerb dieser Art: Bereits der symmetrische 

Verschlüsselungsstandard AES, 

der heute in fast allen kryptographischen 

Anwendungen zu finden ist, wurde mithilfe 

eines ähnlichen Wettbewerbs 2003 

verabschiedet. 

Fingerabdruck 

Doch worum geht es bei kryptographischen 

Hash-Funktionen eigentlich? Kryptographische 

Hash-Funktionen bilden 

eine beliebige Eingabe, etwa eine Datei, 

auf eine Ausgabe fester Länge ab. Die 

Ausgabe wird in der Regel als sogenannte 

Hexadezimalzahl angegeben. Der MD5- 

Hash des Wortes „Hallo“ beträgt etwa 

d1bf93299de1b68e6d382c893bf1215f. 

Um als sicher zu gelten, muss eine kryptographische 

Hash-Funktion zwei Bedingungen 

erfüllen: 

n Nicht umkehrbar: Es soll extrem 

schwierig sein, bei einem gegebenen 

Hash eine Eingabe zu finden, die diesen 

Hash als Ausgabe produziert. 

n Kollisionsresistenz: Es soll extrem 

schwierig sein, zwei Eingaben zu 

finden, die dieselbe Ausgabe produzieren. 

Kryptographische Hash-Funktionen 

werden zu vielen Zwecken eingesetzt. 


SHA-3 

Security 

Der wichtigste sind digitale Signaturen. 

Signaturverfahren wie RSA werden dabei 

nicht über die gesamte Eingabe gebildet, 

sondern nur über den Hash einer 

Eingabe. Doch auch an vielen anderen 

Stellen finden Hash-Funktionen Anwendung. 

Sichere Protokolle wie SSL/ 

TLS sind komplexe Konstruktionen, die 

Hash-Funktionen als Bausteine für unterschiedliche 

Zwecke einsetzen. 

MD5 gebrochen, SHA-1 

gefährdet 

Im Jahr 2004 gelang es einem Team 

um die chinesische Wissenschaftlerin 

Xiaoyun Wang erstmals, eine praktische 

Kollision der MD5-Funktion zu zeigen 

und zwei Eingabedateien zu produzieren, 

die denselben MD5-Hash besitzen. Doch 

Warnsignale gab es schon lange: Bereits 

1996 warnte der inzwischen verstorbene 

Bochumer Professor Hans Dobbertin vor 

Schwächen in MD5. 

Die chinesischen Forscher beließen es 

jedoch nicht beim Angriff auf MD5: Im 

Jahr 2005 verbesserte Wangs Team bekannte 

Angriffe gegen den bis dahin als 

sicher geltenden Standard SHA-1 mehrmals. 

Zwar blieben diese theoretisch – 

bis heute konnte noch niemand eine reale 

Kollision vorführen – doch klar war: Auch 

SHA-1 konnte mittelfristig nicht mehr als 

sicher gelten. 

Übrig blieben die bis dahin kaum 

genutzten Hash-Funktionen der SHA- 

2-Familie mit den Namen SHA-224, 

SHA-256, SHA-284 und SHA-512. Doch 

selbst hier schwante manchen Kryptographen 

Unheil: Denn die Methoden, die 

bei SHA-2 genutzt werden, unterscheiden 

sich nur geringfügig von denen in MD5 

und SHA-1. 

Die US-Behörde NIST kündigte daraufhin 

an, einen neuen Hash-Standard entwi- 

Nutzung von SHA-2 

Auf Unix-Systemen stehen in der Regel eine 

Reihe von Kommandozeilentools bereit, um 

Hash-Funktionen zu berechnen. Für die alten, 

inzwischen unsicheren Funktionen gibt es 

»md5sum« oder »sha1sum«, analog dazu existieren 

die Tools »sha256sum«, »sha224sum«, 

»sha384sum« und »sha512sum«. 

In den meisten modernen Programmiersprachen 

stehen Funktionen bereit, um die Hash- 

Funktionen zu berechnen. In Python stehen die 

ckeln zu wollen. Dafür wurde ein Wettbewerb 

ausgerufen: Weltweit sollten die 

besten Kryptografen Vorschläge für den 

neuen Standard einreichen. Diese wurden 

auf mehreren Konferenzen diskutiert 

und auf mögliche Schwächen abgeklopft. 

Neben den nahe liegenden Gründen war 

auch der Ruf lautgeworden, generell dem 

Thema mehr Aufmerksamkeit zu widmen. 

Kryptografische Hash-Funktionen 

seien bislang von der Forschung vernachlässigt 

worden. 

64 Vorschläge [3] wurden eingereicht, 

die sich dann in mehreren Runden zunächst 

auf 15 und dann auf 5 Finalisten 

reduzierten. Den Kandidaten, die es in 

Runde zwei schafften, war es danach 

erlaubt, kleine Verbesserungen an ihren 

Algorithmen vorzunehmen, um auf mögliche 

Kritikpunkte zu reagieren. 

Krypto-Wettbewerb 

Der Wettbewerb trug nicht nur dazu bei, 

dass zahlreiche neue Hash-Funktionen 

entwickelt wurden, er verbesserte auch 

deutlich das Verständnis der Kryptografen. 

Eine nicht unbedeutende Erkenntnis 

des Wettbewerbs: Die SHA-2-Funktionen 

sind offenbar besser als viele dachten. 

Der bekannte Kryptograf Bruce Schneier 

schlug wenige Wochen vor der finalen 

Entscheidung daher vor, den Wettbewerb 

ohne Sieger zu beenden [4]. Keiner der 

Finalisten sei deutlich besser als SHA- 

512, einige seien geringfügig schneller, 

aber nicht so viel schneller dass 

es einen neuen Standard rechtfertigen 

würde. Schneier selbst hatte zusammen 

mit anderen mit der Hashfunktion Skein 

einen der aussichtsreichen Kandidaten 

für SHA-3 ins Rennen geschickt. Egal, 

wie der Wettbewerb ausgeht: Schneier 

empfahl allen Anwendungsentwicklern, 

unabhängig vom Ausgang zumindest 

Funktionen der »hashlib«-Bibliothek zur Verfügung, 

ein Aufruf von »hashlib.sha512.("Hallo"). 

hexdigest()« gibt den hexadezimalen Hash aus. 

Die folgenden Zeilen machen das Gleiche mit 

PHP: 

$input = "Hallo"; 

echo hash('sha512',$input); 

Die die entsprechende Funktion heißt also 

»hash« und übernimmt den Typ als Parameter. 

vorerst weiterhin auf SHA-512 zu setzen, 

da der Algorithmus bewährt und gut untersucht 

sei. 

Doch Schneiers Worte bleiben ungehört. 

Am 2. Oktober verkündete das NIST den 

Sieger: Keccak, eine Entwicklung eines 

belgischen Wissenschaftsteams, soll zum 

neue SHA-3-Standard werden. Für den 

Mitentwickler Joan Daemen war dies ein 

besonderer Erfolg: Er hatte bereits den 

Verschlüsselungsalgorithmus Rijandel 

mitentworfen, der später zum Standard 

AES wurde. 

Das NIST begründete seine Entscheidung 

damit, dass Keccak von der internen 

Struktur deutlich anders aufgebaut sei 

als die bestehenden SHA-2-Funktionen. 

Sollten sich in Zukunft doch Probleme 

zeigen, hätte man eine Alternative, die 

davon höchstwahrscheinlich nicht betroffen 

ist. Auch Bruce Schneier konnte mit 

der Entscheidung gut leben. Trotz seiner 

vorigen Kritik betonte er, dass er keinerlei 

Sorgen um die Sicherheit von Keccak 

habe und es eine gute Entscheidung sei. 

Den endgültigen SHA-3-Standard hat das 

NIST bisher noch nicht veröffentlicht, 

somit ist auch bisher eine Nutzung von 

SHA-3 kaum anzuraten. Der Hintergrund: 

Der Keccak-Algorithmus bietet zahlreiche 

Varianten, in denen er genutzt werden 

kann, erst nach Veröffentlichung des 

Standards wird klar sein, mit welchen 

genauen Parametern die Funktion dann 

genutzt werden soll. 

SHA-2 wenig verbreitet 

Nach wie vor gilt also: Sichere Anwendungen 

sollten vorerst auf die SHA-2- 

Funktionen setzen. Doch obwohl die 

Prob leme in SHA-1 nun schon seit sieben 

Jahren bekannt sind, tun sich hier zahlreiche 

Probleme auf. SHA-1 ist noch weit 

verbreitet und auch MD5 längst nicht 

ausgerottet. 

Im Jahr 2008 konnte ein Forscherteam 

auf dem 25C3, dem Jahreskongress des 

Chaos Computer Clubs, einen Angriff 

auf MD5-Signaturen präsentieren [5], 

der es ihnen ermöglichte, ein gefälschtes 

Root-Zertifikat einer von allen Browsern 

unterstützten SSL-Zertifizierungsstelle zu 

erzeugen. Erst infolge dieses Praxisangriffs 

ließen sich die Zertifizierungsstellen 

überzeugen, die Nutzung von MD5 

zu beenden. Doch statt direkt auf SHA-2 


Admin 


91

Security 

SHA-3 

01 $$nonumber 

zu wechseln, nutzen die meisten 

inzwischen den ebenfalls 

potenziell anfälligen Algorithmus 

SHA-1. 

Fehler potenziert 

Das Interessante hierbei: Eigentlich 

sollte ein solcher Angriff 

selbst mit der unsicheren 

MD5-Funktion überhaupt 

nicht möglich sein. Denn SSL- 

Zertifizierungsstellen fügen in 

das Zertifikat eine zufällig erzeugte 

Seriennummer ein. Für 

den erfolgreichen Angriff war 

es aber nötig, zwei Zertifikate 

mit identischem MD5-Hash zu 

erzeugen, die Angreifer mussten 

also vorher exakt wissen, 

welche Daten in das Zertifikat 

eingetragen werden. Doch sie fanden einen 

Fehler bei der Zertifizierungsstelle 

RapidSSL: Diese fügte keine zufällige 

Seriennummer ein, sondern eine inkrementell 

erhöhte. Da die Zertifikate relativ 

günstig waren, konnten die Angreifer 

eine wahrscheinliche Seriennummer raten 

und nach mehreren Versuchen gelang 

ihnen der Angriff. 

Ein Angriff auf MD5 mit ganz praktischen 

Auswirkungen wurde dann 2012 

bekannt: Der Virus Flame enthielt eine 

gültige Code-Signatur von Microsoft [6] 

und konnte sich so über den Windows- 

Update-Service verbreiten. Die genauen 

Details der Attacke sind unbekannt, doch 

Kryptografen gehen davon aus, dass die 

Programmierer von Flame Wissen über 

weitere Schwächen von MD5 haben, die 

bisher nicht öffentlich bekannt sind. 

Umstellung auf SHA-2 

schleppend 

Im Jahr 2011 waren noch nahezu alle 

SSL-Zertifikate mit einer SHA-1-Signatur 

versehen (Abbildung 1). Erst im Jahr 2012 

fingen erste Zertifizierungsstellen mit 

dem Wechsel auf SHA-2 an. Das Prob lem 

hierbei: die Abwärtskompatibilität. Fragte 

Listing 1: Apache-Konfiguration 

02 SSLProtocol ‐SSLv2 +SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2 

03 SSLCipherSuite TLSv1:SSLv3:!SSLv2:HIGH:MEDIUM:!LOW: 

!MD5 

Abbildung 1: Heute noch absoluter Normalfall: Zertifikat enthält SHA-1-Signatur. 

man bei den Zertifizierungsstellen nach, 

so erhielt man die Antwort, dass das 

nach wie vor häufig genutzte Windows 

XP vor dem Service Pack 3 keine SHA-2- 

Signaturen unterstützt. Derartige Kompatibilitätsprobleme 

dürften in Zukunft 

eher noch zunehmen. Wer will schon von 

seinem Webservice für einen geringen 

Sicherheitsgewinn etwa die Nutzer alter 

Smartphones ausschließen? 

Noch schwieriger sieht die Situation bei 

den Übertragungsprotokollen aus. Der 

alte, nach wie vor häufig genutzte SSL- 

Standard in der Version 3 unterstützt nur 

MD5- und SHA-1-Signaturen. Auch die 

Nachfolger TLS 1.0 und 1.1 bringen keine 

Besserung, erst mit TLS 1.2 werden neuere 

Algorithmen mit SHA-2 unterstützt. 

Auf der Serverseite wird für die Aktivierung 

von TLS 1.2, etwa im Apache-Webserver, 

die Version 1.0.1 von OpenSSL benötigt. 

Doch bisher unterstützt einzig der 

Opera-Browser TLS 1.2. Somit können 

Serveradministratoren zwar den neuen, 

sichereren Standard aktivieren, genutzt 

wird er aber vermutlich kaum. Und die 

Abschaltung der alten Algorithmen dürfte 

für die lange Zeit nicht infrage kommen. 

Die Abschaltung von MD5-Signaturen ist 

aber schon heute bedenkenlos möglich 

und empfehlenswert. 

Aktiviert werden kann TLS 1.2 – OpenSSL 

1.0.1 und eine aktuelle 2.2 oder 2.4-Version 

des Apache-Webservers vorausgesetzt 

– mit der Konfigurationsoption »SS- 

LProtocol«. Eine mögliche Serverkonfiguration 

könnte wie in Listing 1 

aussehen. 

Mit hoher Wahrscheinlichkeit 

bestehen heute noch keinerlei 

Sicherheitsprobleme, wenn 

man SHA-1 verwendet. Doch 

die Erfahrung mit MD5 lehrt, 

dass die Umstellung weg von 

schwachen Algorithmen sehr 

lange dauert. Trotz der seit 

1996 bekannten Probleme 

konnte der Flame-Virus noch 

2012 – ganze 18 Jahre später 

– erfolgreich die MD5-Signaturen 

des Windows-Update- 

Service angreifen. 

Zukunftsunsicher 

Erste Kollisionen von SHA-1 

werden vermutlich innerhalb 

der nächsten Jahre vermeldet. Für praxisrelevante 

Angriffe ist aber die genaue Art 

der Kollision entscheidend: Die Probleme 

bei MD5 wurden erst dann relevant, als 

es auch möglich war, sinnvolle Daten, 

etwa Zertifikate, mit einer Kollision zu 

erzeugen. Doch das dauerte bei MD5 

nur kurze Zeit, und die Angriffe wurden 

schnell besser. (ofr) 

n 

Infos 

[1] SHA-3-Wettbewerb beim NIST: [http:// csrc. 

nist. gov/ groups/ ST/ hash/ sha‐3/] 

[2] Keccak-Algorithmus: [http:// keccak. 

noekeon. org/] 

[3] Alle Vorschläge im SHA-3-Wettbewerb: 

[http:// ehash. iaik. tugraz. at/ wiki/ The_ 

SHA‐3_Zoo] 

[4] Blogeintrag von Bruce Schneier: [http:// 

www. schneier. com/ blog/ archives/ 2012/ 09/ 

sha‐3_will_be_a. html] 

[5] Vortrag auf 25C3 über gefälschte MD5- 

Signatur: [http:// media. ccc. de/ browse/ 

congress/ 2008/ 25c3‐3023‐en‐making_the_ 

theoretical_possible. html] 

[6] Analyse der MD5-Kollision im Flame-Virus: 

[http:// www. research. leiden. edu/ news/ 

cryptanalyst. html] 

Der Autor 

Hanno Böck ist freier Journalist und ehrenamtlicher 

Entwickler bei Gentoo Linux. Nebenher arbeitet 

er beim Webhosting-Unternehmen schokokeks.org 

mit, das für den Betrieb seiner Dienste 

ausschließlich auf freie Software setzt. 


R 

CeBIT Open Source 

5.–9.3.2013 

Werfen Sie einen Blick hinter die Kulissen 

von Linux und Open Source! 

Das tägliche Vortragsprogramm liefert Ihnen 

Hintergrundinformationen aus erster Hand! 

Jetzt in Halle 6! 

Stand F02 

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 

Powered by 

Presented by 

Sponsored by 


Professional 

Institute

Security 

Automatische Portscans 

© Paul Vasarhelyi, 123RF 

Automatisierte Portscan-Auswertung in großen Netzen 

Leider geöffnet 

Das eigene Netz regelmäßig mit einem Portscan abzusuchen, beugt ungewollt laufenden Serverdiensten vor. 

Bei mehreren Hundert Servern ist das allerdings kein leichtes Unterfangen. Dr. Portscan bietet eine Lösung. 

Felix von Eye, Michael Grabatin, Wolfgang Hommel, Stefan Metzger 

Eines der Hauptprobleme regelmäßiger 

Portscans in großen Netzen ist ihr 

Aufwand: Mit der Serveranzahl wächst 

die Liste offener Ports schnell in eine 

Größenordnung, die manuell nicht mehr 

überschaubar ist. Notwendig wäre eine 

sorgfältige, deshalb sehr zeitintensive 

Auseinandersetzung mit den Scan-Ergebnissen 

– aber dafür fehlt oft das Personal. 

Zudem gibt es in vielen Organisationen 

keinen präzise definierten, zentral verfügbaren 

Soll-Zustand, mit dem das Ergebnis 

abgeglichen werden könnte. Das 

ist insbesondere dann so, wenn einzelne 

Abteilungen eigenständig neue Server in 

Betrieb nehmen dürfen. 

Analysiert man seine Netze zudem von 

unterschiedlichen Standorten aus, etwa 

organisationsintern und von außen, hat 

man zusätzlich mit unterschiedlichen Ergebnislisten 

zu kämpfen. Die resultieren 

unter anderem aus Verbindungen, die 

Firewalls blockieren, oder den Scan-Zeitpunkten. 

Die manuelle Auswertung und 

das Erkennen von Veränderungen sind 

dann noch mühsamer. 

Reporting-Tool 

Ein im Deutschen Forschungsnetz (DFN) 

entstandenes Open-Source-Werkzeug 

hilft bei der Automatisierung verteilter 

Portscans und deren Auswertung. Dr. 

Portscan ist ein Delta-Reporting Tool, das 

nahezu beliebige Portscan-Werkzeuge unterstützt, 

die parallel oder zeitversetzt in 

beliebigen Zeitintervallen beliebig überlappende 

Netz- und Portbereiche analysieren. 

Die Ergebnisse dieser Scan-Läufe 

werden automatisiert aggregiert und 

miteinander verglichen. Dabei entdeckte 

Veränderungen können in Berichte für 

verschiedene Zielgruppen einfließen oder 

als Parameter an Skripte und Programme 

übergeben werden. Auf dieser Basis können 

verfeinerte Diagnosen gestellt und 

das Ergebnis mit einem definierten Soll- 

Zustand abgeglichen werden. 

Im Folgenden beschreiben wir den allgemeinen 

Aufbau verteilter Portscan- 

Infrastrukturen, die Architektur und 

Funktionsweise von Dr. Portscan und 

grundlegende Schritte zu Installation und 

Inbetriebnahme. 

Verteilte Portscans 

Der Einsatz von Portscans als proaktive 

Sicherheitsmaßnahme muss zunächst 

sorgfältig geplant werden, um 

zu aussagekräftigen Ergebnissen zu 

kommen. Mit den folgenden Fragestellungen 

sollte sich der Administrator dabei 

auseinandersetzen: 

n Welche Portscan-Werkzeuge sollen 

eingesetzt werden? Neben dem Klassiker 

»nmap« gibt es zahlreiche weitere 

kostenlose, aber auch kommerzielle 

Scanner. Auch Sicherheits- und 

Netzmanagement-Werkzeuge können 

explizit oder implizit Informationen 

über offene Ports liefern und somit als 

Datenquelle dienen. 

n Von wie vielen und welchen Systemen 

aus sollen die Portscans laufen? Durch 

eine entsprechende Platzierung mehrerer 

Portscanner lassen sich zum Beispiel 

Innen- und Außenansichten der 

analysierten Netze unterscheiden. 

n Wie häufig soll von diesen Systemen 

aus gescannt werden? Dabei ist beispielsweise 

zu beachten, dass einige 

Internet-basierte Portscan-Dienste nur 

fixe Intervalle vorsehen. 

n In welchem Umfang soll jeweils gescannt 

werden? Portscans von außen 

sind im Allgemeinen langsamer als 

LAN-interne Scans. Deshalb möchte 

man sie eventuell auf einzelne Subnetze 

oder nur eine Teilmenge der 

möglichen TCP/UDP-Ports einschränken. 

n Wie können die ermittelten offenen 

Ports validiert, also einem Soll-Zustand 

gegenübergestellt werden? Neben einem 

Initialscan mit anschließender 



Security 

manueller Prüfung kann gegebenenfalls 

der in einer Asset-Datenbank oder 

in einem Configuration-Management- 

System dokumentierte Soll-Zustand 

herangezogen werden. 

Abbildung 1 zeigt etwas vereinfacht die 

aktuelle Konfiguration als Beispiel, anhand 

dessen wir nun auf den Einsatz von 

Dr. Portscan eingehen. 

Dr. Portscan im Überblick 

Im Vergleich zum bekannten Werkzeug 

»ndiff«, das die Gegenüberstellung von 

genau zwei Nmap-Scan-Ergebnissen 

möglich macht, erlaubten die Skripte, auf 

die Dr. Portscan zurückgeht, von Anfang 

an die Gegenüberstellung einer beliebigen 

Anzahl von Portscan-Ergebnislisten, 

die von verschiedenen Maschinen aus 

erzeugt wurden. Nach einiger Zeit wurde 

jedoch das Arbeiten mit in unterschiedlichen 

Intervallen erzeugten Outputs so 

unübersichtlich und war zudem fest an 

ein einziges Portscan-Produkt gebunden, 

dass eine vollständig neue, modulare 

und um beliebige Portscan-Werkzeuge 

erweiterbare, datenbankbasierte Lösung 

geschaffen wurde, mit der Portscan-Berichte 

erstellt und skriptbasierte Reaktionen 

auf Veränderungen in den Portscan- 

Ergebnissen gezielt angestoßen werden 

können. 

Abbildung 2 zeigt die Systemarchitektur 

von Dr. Portscan mit ihren wichtigsten 

Komponenten: Als Datenquellen 

(1) dienen beliebig viele verschiedene 

Hosting 

Provider 

Werkzeug: 

Ort: 

Intervall: 

Scanbereich: 

Ports: 

W erkzeug: nm ap 

O rt: 

Intern (zentral) 

Intervall: Täglich/4 Stunden 

Scanbereich: xxx.xxx.xxx.0/1 6 

Ports: alle 65535 TCP/U DP 

S1 

N etzm anagem ent 

CM S 

nmap 

Extern 

28 Tage 

xxx.xxx.xxx.0/24 

ca. 2500 TCP/UDP 

S4 

D r. Portscan 

Portscan-Werkzeuge. Sogenannte Input- 

Agenten (2) sind für das Konvertieren der 

produktspezifischen Scan-Ergebnisse in 

ein einheitliches Format zuständig. Der 

Input-Agent für Nmap enthält beispielsweise 

Parser für die XML- und die sogenannte 

grep-bare Ausgabe von Nmap 

ab Version 5. Der Aufwand für die Implementierung 

weiterer Input-Agenten ist 

vom anzubindenden Portscan-Werkzeug 

abhängig, bleibt in der Regel aber überschaubar, 

da durch die anzupassenden 

Code-Teile lediglich eine Liste der ermittelten 

IP-Adressen und offenen Ports generiert 

werden muss. 

Der Delta-Reporter (3) überträgt die von 

den Input-Agenten gelieferten Ergebnisse 

in eine Datenbank (4), die die Ergebnisse 

aller Portscans erfasst und auswertet. Die 

dabei generierten Informationen weisen 

auf Veränderungen gegenüber den letzten 

Scan-Läufen hin. 

Output-Agenten 

Die frei definierbaren Output-Agenten (5) 

können eine Gesamtübersicht liefern, Berichte 

über Veränderungen in einzelnen 

Subnetzen erstellen und per E-Mail an 

den zuständigen Administrator verschicken 

oder beliebige Skripte anstoßen, um 

nähere Informationen über den Dienst, 

der hinter einem neu geöffneten Port 

steckt, einzuholen oder mit einem definierten 

Soll-Zustand abzugleichen. 

Dr. Portscan ist auf eine zentrale, relationale 

Datenbank ausgelegt, um zunächst 

S3 

S2 

W erkzeug: 

O rt: 

Intervall: 

Scanbereich: 

Ports: 

Vulnerability- 

Scanner 

Hosting Provider 

W erkzeug: 

O rt: 

Intervall: 

Scanbereich: 

Ports: 

nm ap 

Extern 

Täglich 

xxx.xxx.xxx.0/23 

ca. 1 0000 TCP 

sam hain 

Intern (System -lokal) 

5 M inuten 

xxx.xxx.xxx.xxx/32 

0-1 023 TCP/U DP 

die Ergebnisse der dezentralisiert durchgeführten 

Portscans an einer Stelle in 

einem einheitlichen Format zu sammeln. 

Da sowohl die Input-Agenten, der Delta- 

Reporter als auch die Output-Agenten 

in Perl implementiert sind, kommt ein 

breites Spektrum an Open-Source- und 

kommerziellen Datenbank-Produkten in 

Frage. Die minimal gehaltene Beispielkonfiguration 

setzt auf SQLite. Damit 

ist ein schnelles Ausprobieren von Dr. 

Portscan möglich, ohne zusätzlich einen 

Datenbank-Server und eine neue Datenbank 

einrichten zu müssen. Für größere 

Installationen bietet sich die Verwendung 

von MariaDB, PostgreSQL oder ein anderes 

relationales Datenbankmanagementsystem 

an, für das Perl-DBI-Module 

verfügbar sind. 

Die Datenbank speichert alle Informationen 

für jede gescannte Maschine und 

jeden auffällig gewordenen Port. Ausschlaggebend 

dabei sind die Veränderung 

gegenüber dem letzten Lauf des Portscanners, 

auf den der Eintrag zurückgeht. Die 

Tabelle 1 zeigt die derzeit unterstützten 

Veränderungstypen. 

Datenquellen und Input- 

Agenten 

Die eigentlichen Datenquellen, also die 

Portscan-Werkzeuge, sind zunächst 

unabhängig von den Input-Agenten zu 

konfigurieren. Beispielsweise könnte 

auf einer Linux-Maschine das Werkzeug 

»nmap« per Cronjob automatisiert einmal 

pro Tag wie folgt aufgerufen werden, um 

alle Ports eines Netzbereichs zu scannen, 

der einem herkömmlichen Class-B-Netz 

entspricht: 

/usr/bin/nmap ‐v ‐v ‐oG ‐ ‐p 1‐65535 U 

10.1.0.0/16 > /tmp/nmap‐results.txt 

Jeder Datenquelle ist ein Input-Agent 

zugeordnet; seine Hauptaufgabe ist das 

Erzeugen einer Liste aller IP-Adressenund 

Port-Paare, die von der Datenquelle 

als offen erkannt wurden. Er liest die 

Ausgabe des Scan-Werkzeugs und parst 

sie. Der obige Nmap-Aufruf würde beispielsweise 

bei einem Webserver folgende 

Textausgabe liefern: 

Host: 10.1.123.123 (www.example.com) U 

Ports: 80/open/tcp//http///, 443/open/tcpU 

Abbildung 1: Beispielszenario für verteilte Portscans mit dem Werkzeug Dr. Portscan. 

//https/// 

Ignored State: filtered 


Admin 


95

Security 


Nr. 

Tabelle 1: Veränderungstypen 

Beschreibung 

0 Keine Veränderung gegenüber dem 

letzten Scan-Lauf 

1 Neue Maschine (IP-Adresse ist zum 

ersten Mal auffällig geworden) 

2 Maschine läuft nicht mehr 

4 Veränderter DNS-Name 

8 Neuer offener Port, der vorher noch 

nie offen war 

16 Port inzwischen geschlossen (Port war 

früher offen) 

32 Port wieder geöffnet, nachdem er zwischenzeitlich 

geschlossen war 

Das Ergebnis des Input-Agents – eine 

einfache Textdatei mit einer IP-Adresse, 

einem Port sowie der Protokollangabe 

und optional einem Zeitstempel pro Zeile 

– wird anschließend entweder zur Abholung 

durch den Delta-Reporter hinterlegt 

oder im Push-Verfahren, etwa per »scp«, 

auf eine andere Maschine übertragen. 

Dieser Zwischenschritt ist oft deshalb 

notwendig, weil die von Dr. Portscan in 

der Default-Konfiguration verwendete 

SQLite-Datenbank (ohne Zusatzsoftware 

wie cubeSQL) gar nicht über das Netz 

erreichbar ist und auch andere Datenbanken 

häufig per Firewall gegenüber 

Zugriffen aus dem Internet abgeschottet 

werden, sodass kein direktes Eintragen 

der Ergebnisse in die zentrale Datenbank 

möglich wäre. 

Delta-Reporter, Output- 

Agenten und Reports 

Zunächst überträgt der Delta-Reporter 

die von den Input-Agenten gelieferten 

Portscan-Ergebnisse in die zentrale Datenbank. 

Dabei überprüft er für jedes 

IP-Adress- und Port-Paar unter Berücksichtigung 

des Layer-4-Protokolls, ob 

zum entsprechenden Scanner bereits ein 

Eintrag vorliegt oder neu erzeugt werden 

muss. Bei Aktualisierung vorhandener 

Einträge wird der Veränderungstyp entsprechend 

gesetzt. 

Nach Abschluss des Imports aller 

Portscan-Ergebnisse kann der Output- 

Agent den zentralen Datenbestand auswerten. 

Da primär Veränderungen gegenüber 

dem bisherigen Zustand interessant 

sind, suchen Output-Agenten in der Regel 

nur nach Datenbank-Einträgen mit passendem 

Veränderungstyp. Um zu verhindern, 

dass ein Output-Agent mehrfach 

dasselbe Ereignis bearbeitet, trägt dieser 

seinen Identifikator in eine entsprechende 

Spalte der Datenbanktabelle ein. 

Anzahl und Art der verwendeten Output- 

Agenten sind beliebig an den eigenen 

Bedarf anpassbar. Dr. Portscan bietet einen 

vorgefertigten Output-Agenten, der 

dem Administrator einen Gesamtüberblick 

über alle Veränderungen seit dem 

letzten Bericht liefert. Die Auswertung 

durch die Output-Agenten lässt sich aber 

auch gezielt einschränken. So ist es denkbar 

nur Ereignisse bestimmter Subnetze 

zu betrachten, um gezielt dafür zuständige 

Server- oder Netzverantwortliche 

zu informieren, oder nur ausgewählte 

Ereignisse, zum Beispiel neu geöffnete 

Ports, um diese einem definierten Soll- 

Zustand gegenüberzustellen. Um generell 

Mehrfachmeldungen und Fehlalarme zu 

vermeiden, empfiehlt sich das folgende 

Vorgehen: 

n Ports werden erst als offen oder geschlossen 

gemeldet, wenn frei konfigurierbare, 

Scanner-spezifische 

Schwellenwerte überschritten werden. 

Diese Schwellenwerte tragen zu einer 

Stabilisierung des Portscans bei und 

vermeiden Falschmeldungen. Denn es 

kommt immer wieder vor, dass ein 

gescanntes System just zum Zeitpunkt 

des Scans temporär nicht erreichbar 

ist oder dass bei Scans aus dem Internet 

bei aggressiveren Timing-Werte 

der Portscan-Tools nicht immer alle 

offenen Ports zuverlässig erkannt werden. 

n Bei jeder Meldung wird geprüft, ob sie 

bereits durch andere Output-Agenten 

mit derselben Report-Zielgruppe beziehungsweise 

vom selben Output-Agenten 

aufgrund der Ergebnisse eines anderen 

Scanners berichtet wurden. In 

diesem Fall kann die erneute Meldung 

gänzlich unterdrückt oder explizit als 

Bestätigung eines bereits bekannten 

Sachverhalts gekennzeichnet werden. 

n Diskrepanzen zwischen den Ergebnissen 

verschiedener Scanner sind im Regelfall 

legitim und können etwa durch 

unterschiedlichen Scanzeitpunkt, 

Scanumfang oder Scannerstandort 

verursacht werden. Diese unterschiedlichen 

Sichten auf dasselbe System gilt 

es im Report geeignet aufzubereiten, 

zum Beipsiel indem pro Berichtspunkt 

die aktuell vorliegenden Ergebnisse der 

unterschiedlichen Scanner aufgeführt 

werden. In der Konfiguration wird jeder 

Scanner einer Gruppe zugeordnet, 

innerhalb derer alle Sensoren dieselbe 

Sicht haben sollten, um Inkonsistenzen 

erkennen zu können. 

Durch Veränderungen der Scanner-Infrastruktur 

kann es von Zeit zu Zeit notwendig 

werden, den gespeicherten Datenbestand 

zu bereinigen. In Dr. Portscan 

enthaltene und optional zu verwendende 

Skripte löschen beispielsweise Einträge 

mit sehr alten Zeitstempeln, eines bestimmten 

Scanners, (wenn dieser außer 

Betrieb genommen wurde), alle Einträge 

in einem bestimmten Netzbereich oder 

alle Einträge zu einer IP-Adresse, (zum 

Beispiel wenn im eine Maschine durch 

eine andere mit derselben IP-Adresse ersetzt 

wird). 

Installation und 

Inbetriebnahme 

Die folgende Installationsbeschreibung 

geht davon aus, dass der Delta-Reporter, 

die Output-Agenten und die Datenbank 

auf derselben Maschine installiert werden. 

Die Scanner laufen im Gegensatz 

dazu auf beliebigen Systemen. Sie müssen 

lediglich ihre Scanergebnisse an die 

zentrale Delta-Reporting-Instanz übermitteln 

können. 

Die aktuellste Version von Dr. Portscan 

kann über ein git-Repository [1] bezogen 

werden. Alternativ zum Download per 

Webbrowser erhält man das komplette 

Repository mittels 

git clone git://git.lrz.de/DrPortScan.git 

Voraussetzung für den Betrieb der einfachsten 

Installationsvariante sind SQ- 

Lite3, Perl und die folgenden Perl-Module, 

die sich zum Beispiel über CPAN inklusive 

ihrer Abhängigkeiten installieren lassen: 

DBD::SQLite, XML::LibXML, DateTime 

und DateTime::Format::Strptime. 

Die Installation erfolgt durch Aufruf des 

Skripts »setup.pl«. Das prüft, ob alle notwendigen 

Perl-Module installiert sind. 

Sollte dies nicht der Fall sein, wird eine 

Meldung ausgegeben, die angibt, welches 

Modul nachzuinstallieren ist. Weiterhin 

übernimmt dieses Skript auch das Anlegen 

der zum Betrieb von Dr. Portscan 



Security 

nötigen Verzeichnisstruktur für Ein- und 

Ausgabedaten. Das Anlegen und Initialisieren 

einer SQLite-Datenbank erfolgt 

anschließend durch einen Aufruf des 

Skripts »create_db.sh«. Es registriert nach 

der Erstellung der Datenbank auch einige 

Test-Scanner, die als Vorlage für eigene 

Scanner-Definitionen verwendbar sind. 

Das bietet die Möglichkeit, beim Einrichten 

der Datenbank gleich alle Sensoren 

mitzuregistrieren, sodass Nachkonfigurationen 

unnötig werden. 

Will man von dieser Möglichkeit keinen 

Gebrauch machen, kann man die Administration 

der Scanner auch später noch 

mit dem Skript »configuration.pl« erledigen. 

Neben der Auflistung aktuell in der 

Datenbank registrierten Scanner erlaubt 

dieses Skript auch das Neueintragen, Ändern 

und Entfernen eines Scanners. 

Scannen mit dem 

Standardwerkzeug Nmap 

Im Folgenden beschreiben wir die Verwendung 

im Zusammenspiel mit dem 

Standardwerkzeug Nmap. Für Nmap 

bringt Dr. Portscan bereits einen vorkonfigurierten 

Input-Agent mit, den wir 

nachfolgend über seine XML-Ausgabe 

anbinden wollen. Für die Durchführung 

eines Nmap-Scans mit detaillierter XML- 

Ausgabe kann ein Skript verwendet werden, 

dessen Kern der folgende Aufruf 

bildet: 

nmap ‐oX /pfad/zur/ablage/ nmap‐xml_scannerU 

_timestamp.xml IP-Range 

Für andere Scanner-Software muss, falls 

Dr. Portscan keinen passenden Input- 

Zu scannende Systeme 

Portscan 

Geblockte 

Verbindung 

Firewall 

Portscan 

Datenquellen 

1 

Internes nmap 

Externer Scanner 

Abbildung 2: Die Systemarchitektur von Dr. Portscan. 

1 

Agent mitliefert, ein eigener implementiert 

werden; das vorhandene Template 

kann als Ausgangsbasis dafür verwendet 

werden. 

Die Ausgabe eines Scans muss letztlich 

auf der zentralen Maschine im Eingabeordner 

von Dr. Portscan landen. Der 

Dateiname der Ausgabedatei muss dabei 

einem bestimmten Schema folgen, damit 

festgestellt werden kann, mit welchem 

Input-Agenten die Datei behandelt 

werden soll. Weiterhin muss angegeben 

werden, von welchem Scanner die Datei 

kommt und zu welchem Zeitpunkt der 

Scan durchgeführt wurde. 

Dabei ist die Angabe des Scanners diejenige, 

mit der der Scanner auch in der 

zentralen Datenbank registriert wurde 

und das Datum muss in der Form 

»YYYYMMDDHHMMSS« formatiert sein. 

Somit muss der Dateiname dem Schema 

input-agent_scanner_datum.* folgen. 

Auf welche Art und Weise die Dateien 

von externen Scannern auf die zentrale 

Delta-Reporting-Instanz kopiert oder verschoben 

werden, ist unerheblich. Es bietet 

sich an, »scp« oder »sftp« per Cronjob 

zum Abrufen neuer Scan-Ergebnisse zu 

verwenden, wenn das Delta-Reporting- 

System von außen nicht erreichbar sein 

soll. 

Delta-Reporting 

Die zentrale Komponente von Dr. Portscan 

ist die Delta-Reporting-Instanz. Die Überprüfung, 

ob neue Scanergebnisse bearbeitet 

werden müssen, übernimmt das Skript 

»input‐watcher.pl«. Zunächst werden die 

Dateien zeitlich sortiert, anschließend 

Input-Agenten 

2 

meldetan 

meldetan 

2 

schreiben in 

5 

Output-Agent 

(z. B. E-Mail) 

5 

Output-Agent 

(z. B. CMS-Abgleich) 

Einheitliches 

Datenformat 

liest und wertet aus 

lesen Daten 

aus 

Delta-Reporter 

Datenbank 

4 

3 

schreibt in 

der entsprechende Input-Agent gesucht, 

die eingelesenen Daten durch diesen in 

ein einheitliches Datenformat konvertiert 

und an den Delta-Reporter zur Weiterverarbeitung 

geschickt. Wird diese Vorverarbeitung 

ohne Fehler abgeschlossen, 

wird die Datei in das Verzeichnis »old« 

verschoben, ansonsten in »failed«. Um 

eine regelmäßige Ausführung des Input- 

Watcher-Skripts zu gewährleisten, ist 

es zweckmäßig, das einem Cronjob zu 

übertragen. 

Der Delta-Reporter vergleicht nun die aktuellen 

Ergebnisse mit denen der letzten 

Scans und trägt die Ergebnisse in die 

Datenbank ein. Die Output-Agenten bereiten 

diese für die weitere Verwendung 

geeignet auf. Ein erster Schritt in der 

typischen Anwendung ist der Output- 

Agent »xml‐out.pl«, der die ermittelten 

Änderungen wiederum als XML-Dokument 

ausgibt. Dieses kann durch das 

Skript »xml2plaintex.pl« in eine textbasierte 

Version umgewandelt werden, die 

zum Beispiel per E-Mail verschickt wird. 

Alternativ dazu lässt sich das XML-Dokument 

etwa nach HTML konvertieren, 

um die Ergebnisse per Browser einsehen 

zu können. 

Die Zukunft von Dr. 

Portscan 

Dr. Portscan wird aktiv weiterentwickelt 

und soll in der nächsten Version insbesondere 

um ein mandantenfähiges Konfigurations- 

und Reportingtool erweitert 

werden. So sollen Administratoren, die 

nur für einige Teile des gesamten Netzes 

zuständig sind, den Scan-Umfang und 

die gewünschten Eckdaten der erstellten 

Reports über ein Webfrontend selber 

frei konfigurieren können. Zudem 

soll das Reporting für IPv4-/IPv6-Dual- 

Stack-Umgebungen verbessert werden, 

um beispielsweise zueinander inkonsistente 

IPv4- und IPv6-Firewall-Regeln 

identifizieren zu können. Ebenso ist ein 

Output-Agent zur Meldung der Portscan- 

Ergebnisse an bekannte Security Information 

und Event-Management-Systeme 

wie zum Beispiel AlienVault OSSIM in 

der Planung. (jcb) 

n 

Infos 

[1] Dr.Portscan: [git://git.lrz.de/DrPortScan. 

git] 


Admin 


97

Security 

SQL-Injections 

© Andrei Kuzmik, 123RF 

SQL-Injection-Lücken finden 

Gift für alle Fälle 

Kaum ein Tag vergeht ohne Meldungen über Einbrüche in Regierungs-, Militär- oder Firmen-Server. Wer die Vorgehensweise 

der Hacker genauer analysiert, wird schnell feststellen, dass in fast 90 Prozent der Fälle eine sogenannte 

SQL-Injection zur Komprimierung des Servers geführt hat. Patrik Fehrenbach 

Hacker-Gruppen wie Anonymous oder 

Lulzsec sind für jeden Administrator 

ein Albtraum. Innerhalb von nur wenigen 

Stunden können Angreifer in der 

Lage sein, eine vollständige Server-Infrastruktur 

kompromittieren. Oft ist das 

Einfallstor für die Angreifer ein klassischer 

Fehler in einer Webanwendung: 

die Anfälligkeit für SQL Injection. Nicht 

nur sensible Daten sind in Gefahr, die 

gesamte Server-Infrastruktur kann von 

Angreifern übernommen werden. Die 

bereits seit über zwölf Jahre bekannte 

Lücke ist nach wie vor das beliebteste 

Angriffsziel von Hackern. 

Dieser Artikel beschreibt anhand von realitätsnahen 

Beispielen die Angriffsvektoren 

einer SQL-Injection, erklärt wie diese 

durch Unachtsamkeit auftreten können 

und wie weitreichend solch eine Lücke 

sein kann. Demonstriert wird dies zunächst 

manuell an einem potenziell verwundbaren 

Skript und dann mithilfe des 

Tools SQLmap in einer Testumgebung mit 

entsprechend verwundbarer Software. 

Ein Merkmal, das fast alle Webapplikationen 

gemeinsam haben, ist die Anbindung 

an eine oder mehrere Datenbanken. Ob 

zum Abrufen von E-Mails, Einkaufen im 

Internet oder zum Lesen von News: Eine 

oder gar mehrere Datenbanken stecken 

immer dahinter. Egal, in welcher Programmiersprache 

die Web-Applikation 

geschrieben wurde, die Kommunikation 

mit der Datenbank erfolgt immer nach 

demselben Prinzip: Das serverseitig abgelegte 

Skript übermittelt die SQL-Abfragen 

an die Datenbank, wertet die zurückgegeben 

Werte aus und liefert diese dem 

Anwender zurück. 

Ungenügend informiert 

Die Ursache für Sicherheitslücken in 

Web-Applikationen ist oft im mangelnden 

Sicherheitsbewusstsein von Programmierern 

zu suchen. Die wesentlichen Probleme 

entstehen vor allem durch fehlende 

Überprüfung der eingehenden Werte. Das 

folgende PHP-Skript, das zu einem gängigen 

Login-Screen gehört, demonstriert 

einen typischen Programmierfehler. 

$query = "SELECT * FROM users WHERE U 

user='" . $_POST['username'] . " ' AND U 

password=' " . $_POST['password'] . " ' "; 

$response = mysql_query($query) ; 

Entgegengenommen werden als Werte 

der Username und das Passwort. Das 

Skript überprüft nun nach Eingabe der 

jeweiligen Daten, ob sie mit den in der 

Datenbank hinterlegten übereinstimmen. 

Wird der jeweilige User in der Datenbank 

gefunden, und passt das angegebene 

Passwort, so ist der Nutzer legitimiert. 

Das hierfür zuständige SQL Statement 

wird folgendermaßen übergeben : 

SELECT * FROM users WHERE U 

user='...' AND password='...' 

Die Datenbankabfrage wird demnach 

durch die zwei Variablen Username und 

Passwort ergänzt. In der Theorie funktioniert 

dies, bis ein Angreifer die Abfrage 

folgendermaßen abändert: 



Security 

Password = ' OR 'a' = 'a' 

Die Anfrage an die Datenbank sieht nun 

folgendermaßen aus : 

SELECT * FROM users WHERE user = U 

'Patrik' AND password = ' ' OR 'a' = 'a' 

Die hierbei neu generierte SQL-Abfrage 

prüft zuerst die OR-Verknüpfung und 

anschließend die AND-Verknüpfung. 

Die OR-Verknüpfung prüft, ob sich mindestens 

eines der beiden Argumente als 

wahr erweist. Die logische Abfrage, ob ’a’ 

= ’a’ ergibt, ist immer wahr. Die AND- 

Verknüpfung überprüft, ob der Username 

»Patrik« in der Datenbank vorhanden ist. 

Ist dies der Fall, wird auch dies als wahr 

zurückgegeben. Da beide dieser Argumente 

sich als wahr erweisen, wird der 

Angreifer auf dem System authentifiziert, 

ohne überhaupt das Passwort zu kennen. 

Weil hier statt einfachen String-Werten 

vom böswilligen Anwender SQL-Befehle 

in die ursprüngliche Abfrage „injiziert“ 

wird, spricht man von einer SQL Injection. 

Verhindern lässt sich ein solcher Angriff, 

indem die Webanwendungen alle Eingaben 

prüft und statt einfacher String- 

Verkettung sogenannte Prepared Statements 

verwendet. Die Skriptsprache stellt 

dann sicher, dass nur die gewünschten 

Datentypen wie Strings in die Abfrage 

gelangen. 

Verdammt verletzlich 

Um weitere Angriffsmethoden für SQL- 

Injection zu demonstrieren, verwendet 

der Rest des Artikels eine potenziell verwundbare 

Testumgebung. Dies ist ein 

XAMPP-Webserver mit einer vorsätzlich 

fehlerhaften Anwendung namens DVWA 

(Damn Vulnerable Web Application [1]). 

Es handelt sich hierbei um eine Web- 

Applikation die auf PHP und MySQL aufbaut 

und speziell für Sicherheitsspezialisten 

konzipiert ist. Damit ist es möglich, in 

einem legalen Umfeld verschiedenste Angriffe 

auf Web-Applikationen zu testen. 

Nach der Installation des Microsoft Windows 

Server 2003 und der Einrichtung der 

Webapplikation DVWA muss sich der Benutzer 

zunächst über das Login-Feld mit 

dem Benutzernamen »Admin« und dem 

Passwort »Password« auf dem System anmelden. 

DVWA bietet drei verschiedene 

Schwierigkeitsmodi, die unterschiedliche 

Szenarien der Server-Sicherheitseinstellungen 

simulieren können. Für die Demonstration 

der SQL-Injection muss im 

Reiter »DVWA Security« die Einstellungen 

auf »Low« gestellt werden, um sicherzustellen, 

dass alle Sicherheitsmechanismen, 

die eine SQL-Injection verhindern 

könnten, ausgeschaltet sind. 

Nun kann das entsprechend verwundbare 

Modul links im Reiter ausgewählt 

werden. In diesem Artikel ist dies das 

Modul »SQL‐Injection« (Abbildung 1). 

Das Hochkomma 

Um nun auf eine potenzielle SQL-Injection 

Lücke zu überprüfen, trägt man in 

das Feld zunächst ein Hochkomma ein. 

Eine SQL Injection ist nur dann möglich, 

wenn eine Applikation Benutzereingaben 

als Teil einer SQL-Abfrage an den Server 

weiterleitet, ohne die Benutzereingaben 

auf etwaige enthaltene Metazeichen (umgekehrter 

Schrägstrich, Apostroph, Anführungszeichen, 

Semikolon) zu prüfen 

und diese zu maskieren. Im Testfall gibt 

die Datenbank folgende Fehlermeldung 

aus: 

You have an error in your SQL syntax; U 

check the manual that corresponds to your U 

MySQL server version for the right syntax U 

to use near ''''' at line 1 

Dies ist ein erster Hinweis auf eine potenzielle 

SQL-Injection-Lücke. 

Ziel einer SQL-Injection-Attacke ist es, 

möglichst sensible Informationen aus ei- 

ner Datenbank zu extrahieren, doch ein 

Angriff auf eine Datenbank kann noch 

viel weiter reichende Folgen haben. 

SQLmap 

Abbildung 1: Das SQL-Injection-Modul der Damn Vulnerable Web Application. 

Die quelloffene Software SQLmap bietet 

die perfekte Basis für einen umfangreichen 

Angriff auf Datenbanksysteme. Es 

ist in Python geschrieben, daher systemunabhängig 

und lässt sich beliebig 

durch Module erweitern. SQLmap benötigt 

Python mindestens in Version 2.6. 

Für die Takeover-Funktionen setzt es eine 

Installation des Metasploit-Frameworks 

voraus. SQLmap unterstützt alle gängigen 

Datenbanksysteme wie MySQL, 

PostgreSQL, Oracle und Microsoft SQL 

Server. Darüber hinaus kennt es fünf 

verschiedene SQL-Injection-Methoden: 

boolean-based blind, time-based blind, 

error-based, UNION query, stacked queries 

und out-of-band. Der Befehl »python 

sqlmap.py« startet das Tool auf der Kommandozeile. 

Die zu überprüfende URL folgt hinter 

dem Parameter »‐u« in Anführungszeichen. 

Mit dem Wissen, dass die Sql-Injection-Lücke 

im Eingabefeld »ID« zu finden 

ist, wird der Aufruf um den Parameter 

»‐‐forms« erweitert, der SQLmap anweist, 

alle Eingabefelder auf SQL-Injection-Lücken 

zu testen. Durch einen früheren 

Login-Versuch hat der Benutzer ein Session 

Cookie bekommen, das man Sqlmap 

unbedingt mitteilen muss, damit der Angriff 

gelingt. Dies lässt sich beispielsweise 

mit dem Firefox-Plugin „Tamper Data“ 


Admin 


99

Security 


python sqlmap.py ‐u "http://127.0.0.1/U 

dvwa/vulnerabilities/sqli/?id=1&Submit=U 

Submit#" ‐‐cookie="PHPSESSID=ce0aa7922720f3U 

190bf9bbff7f24c434;security=low" ‐‐forms U 

‐D dvwa ‐T users ‐‐columns ‐‐dump 

herausfinden. Der zusammengesetzte 

Befehl sieht nun so aus : 

sqlmap.py ‐u "http://127.0.0.1/dvwa/U 

vulnerabilities/sqli/?id=1&Submit=Submit#"U 

‐‐cookie="PHPSESSID=ce0aa7922720f3190bf9U 

bbff7f24c434;security=low" ‐‐forms 

SQLmap findet nach kurzer Zeit das passende 

Feld »ID« und fragt nach, ob dieses 

Feld überprüft werden soll. Nach dem Bestätigen 

startet die Analyse des Feldes. 

GET http://127.0.0.1:80/dvwa/U 

vulnerabilities/sqli/?id=&Submit=Submit 

Cookie: PHPSESSID=U 

ce0aa7922720f3190bf9bbff7f24c434;U 

security=low 

do you want to test this form? [Y/n/q] 

Nach einem erfolgreichen Scan präsentiert 

SQLmap die möglichen Angrifsvektoren 

in Form fertiger SQL-Statements. 

An diesem Punkt kann der Benutzer 

entscheiden, ob er den Angriff manuell 

fortführt oder ob SQLmap versuchen soll, 

die Lücke auszunützen. Nach der Bestätigung 

ist die Arbeit erledigt, da es keine 

weiterführenden Parameter gibt. 

Datenbank auslesen 

SQLmap kann beispielsweise mit 

»‐‐dump‐all« ungefiltert den kompletten 

Inhalt der Datenbank ausgeben, oder nur 

Listing 1: Users-Tabelle 

01 Table: users 

02 [6 columns] 

Abbildung 2: Die Password-Knack-Funktion findet mithilfe eines Brute-Force-Angriffs die Passwörter heraus. 

03 +‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐+ 

04 | Column | Type | 

05 +‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐+ 

06 | avatar | varchar(70) | 

07 | first_name | varchar(15) | 

08 | last_name | varchar(15) | 

09 | password | varchar(32) | 

10 | user | varchar(15) | 

11 | user_id | int(6) | 

12 +‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐+ 

einzelne Datensätze durch »‐‐dbs«. Da 

eine Datenbank viele irrelevante Informationen 

enthalten kann, ist es sinnvoll, 

die Attacke auf die wichtigen Daten zu 

beschränken und damit den Vorgang zu 

beschleunigen. Die Befehlskette wird um 

»‐‐dbs« erweitert, und der Benutzer erhält 

die verfügbaren Datenbanken. 

available databases [5]: 

[*] cdcol 

[*] dvwa 

[*] information_schema 

[*] mysql 

[*] test 

Besonderes Augenmerk sollte man auf 

die Datenbanken »information_schema« 

und »dvwa« legen. Die Datenbank »information_schema« 

gibt Auskunft über Metadaten 

der Datenbank wie Datentypen 

oder Zugriffsberechtigungen, dies kann 

bei gezielten Attacken als wertvolle Informationsquelle 

dienen. »dvwa« ist allem 

Anschein nach die Datenbank von Interesse. 

Um die darin enthaltenen Datensätze 

zu erhalten, wird die Befehlskette 

mit der Option »‐D dvwa« erweitert. 

Database: dvwa 

[2 tables] 

+‐‐‐‐‐‐‐‐‐‐‐+ 

| guestbook | 

| users | 

+‐‐‐‐‐‐‐‐‐‐‐+ 

Nun hat der User einen Überblick über 

die verfügbaren Tabellen der Datenbank. 

Um an wertvolle Informationen zu gelangen, 

wird die Tabelle »users« näher 

betrachtet. Der Befehl wird durch »‐T 

users« erweitert. Die Ausgabe listet anschließend 

die verfügbaren Spalten aus, 

und von welchem Datentyp diese sind 

(Listing 1). Um nun den Inhalt der Tabelle 

zu erhalten, wird durch »‐‐dump« 

erweitert. Die finale Befehlskette sieht 

jetzt folgendermaßen aus : 

Sqlmap hat erkannt, dass sich in der 

Tabelle »password« Passwort-Hashes 

befinden, die das Programm mithilfe 

von Wörterbuchattacken knacken kann. 

Nach wenigen Sekunden sind die Benutzerpasswörter 

im Klartext verfügbar 


Innerhalb von nur etwa 35 Sekunden war 

SQLmap in der Lage, sensible Daten aus 

der Datenbank zu extrahieren. 

Takeover 

SQLmap bietet in Verbindung mit Metasploit 

die Option, das zugrunde liegende 

System zu übernehmen. Dabei 

kann der Anwender aus verschiedenen 

Modulen wählen. Abhängig von der Datenbank 

gibt es verschiedene Exploits, 

die Zugriff auf den Server verschaffen. 

Hier wird die Option »‐‐os‐pwn« verwendet, 

die bei Servern mit Windows 2003 

R2 eine Remote Shell verschaffen kann. 

Nach der Erweiterung des Befehls um 

»‐‐os‐pwn« wählt man zum Beispiel 

die Option 1 (»TCP : Metasploit Framework«), 

wenn das Programm wissen will, 

auf welche Art es einen Tunnel erstellen 

soll. SQLmap versucht nun, eine Datei 

auf dem Server System abzulegen und sie 

dann aufzurufen (Abbildung 3). 

Angriffsoptionen 

Anschließend muss der Benutzer die Payload 

wählen (die Funktion, die nach dem 

Ausführen des Exploits aufgerufen wird). 

Zur Auswahl stehen Meterpreter, Shell 

oder VNC. Meterpreter ist eine Sammlung 

von Funktionen, die auf dem System 

ausgeführt werden können. Shell gibt 

dem Benutzer eine System Shell auf dem 

gekaperten Server und VNC stellt eine 

Verbindung zum Server her, über die der 

User Zugriff auf den Desktop bekommt. 

Dieser Testangriff beschränkt sich auf 

die Shell-Option, für einen umfangreichen 

Angriff würde sich die Option des 

Meterpreters anbieten. Meterpreter kann 

beispielsweise in Prozesse migrieren, 

um erweiterte Rechte zu erhalten, oder 

sich auf dem System so tief einnisten, 



Security 

G Abbildung 3: Die durch die SQL-Injection abgelegten Dateien auf dem Server, 

die zum Beispiel eine Remote Shell realisieren. 

E Abbildung 4: Meterpreter feuert eine ganze Breitseite auf den Server ab und 

installiert auf Wunsch sogar Backdoors. 

auszubeuten und gar unbrauchbar zu 

machen. 

SQL-Injections sind nach wie vor die gefährlichsten 

Sicherheitslücken, mit denen 

Web-Administratoren konfrontiert sind. 

Durch die Entwicklung von Tools wie 

SQLmap ist es ein Kinderspiel für Hacker, 

in Systeme einzubrechen und enormen 

Schaden zu verursachen. Umso mehr ist 

es für Entwickler und Administratoren 

wichtig, den auf dem Server laufenden 

Code genau auf diese Schwachstellen zu 

überprüfen. Ein striktes Regelwerk für 

Programmierer kann zu einer Regulierung 

dieser Lücken führen. Auch das regelmäßige 

Auditieren von Web Anwendungen 

bringt Sicherheit, empfohlen wird bei 

umfangreichen Anwendungen, die stedass 

er für den Angreifer ständig verfügbar 

ist, man spricht hier auch von einer 

Backdoor. Diese Funktionalitäten würden 

aber den Umfang des Artikels sprengen. 

Nach der Auswahl »Shell« stellt SQLmap 

mithilfe von Metasploit die Verbindung 

zum Server her, der Benutzer erhält eine 

Remote-Shell und hat durch diese vollen 

Zugriff auf den Server. 

Fazit 

Durch eine SQL-Injection war es möglich, 

Administratorenrechte auf dem betroffenen 

System zu erlagen. Angreifer 

haben nun kompletten Zugriff auf alle 

Systemressourcen des Servers und sind 

in der Lage, den Server zu kontrollieren, 

tig weiterentwickelt werden, eine monatliche 

Überprüfung. Die regelmäßige 

Überprüfung der Log-Dateien gibt zudem 

Aufschluss über mögliche Angriffe auf 

das System. (ofr) 

n 

Infos 

[1] Damn Vulnerable Web Application: [http:// 

www. dvwa. co. uk/] 

[2] SQLmap: [http:// sqlmap. org] 

[3] Metasploit: [http:// www. metasploit. com] 

Der Autor 

Patrik Fehrenbach ist Student für Computer Networking 

an der Hochschule Furtwangen University, 

Nerd aus Leidenschaft, und Mitgründer von 

IT-Securityguard. 

Probelesen ohne risiko 

sonDerAkTion! 

Testen sie jetzt 

3 Ausgaben für 

nUr 3€* 


Admin 

Telefon: 07131 /2707 274 

Fax: 07131 / 2707 78 601 

E-Mail: abo@linux-user.de 

Mit großem Gewinnspiel unter: 

www.linux-user.de/probeabo 

* Angebot gilt innerhalb Deutschlands 

und Österreichs. In der Schweiz: SFr 4,50. 

Weitere Preise: www.linux-user.de/produkte 


101

Programmieren 

Flask 

Webanwendungen mit Flask 

Edler 

Tropfen 

© Igor Klimov, 123RF 

Für Python-Webanwendungen gibt es viele Ansätze. Zu den weniger bekannten 

zählt Flask, das dieser Artikel näher vorstellt. Oliver Frommel 

Wer sich überlegt, mit Python eine Webanwendung 

zu programmieren, stößt 

recht schnell auf Django, das einen ähnlichen 

Rang in der Python-Welt einnimmt 

wie Rails in der Ruby-Community. Eine 

Alternative zu Django ist Flask [1], das 

seit seiner Entstehung im Jahr 2010 immer 

populärer wurde. 

Django besitzt den Vorteil, dass es mehr 

oder weniger schon alles mitbringt, was 

man für viele Webanwendungen braucht: 

Templates, Datenbankanbindung, User- 

Authentifizierung und so weiter. Dafür 

ist es aber auch schwierig, Komponenten 

wegzulassen oder auszutauschen. Wer 

Listing 1: Simple Flask-App 

01 from flask import Flask 

02 app = Flask("Meine App") 

03 

04 @app.route('/') 

05 def homepage(): 

06 return 'Das ist die Homepage' 

07 

08 if __name__ == '__main__': 

09 app.run() 

es gerne etwas flexibler hat, sollte einen 

Blick auf Flask werfen. Von Haus 

aus setzt Flask beim Unterbau auf eine 

WSGI-Bibliothek namens Werkzeug [2], 

die vom Flask-Autor Armin Ronacher 

stammt. Ebenso die Template-Bibliothek 

Jinja2, die von Flask standardmäßig verwendet 

wird. 

WSGI 

WSGI [3] ist eine Spezifikation, die festlegt, 

wie eine Webserver-Software und 

eine Webanwendung, die in Python 

geschrieben sind, miteinander kommunizieren. 

Das können zum Beispiel der 

Apache- oder der Nginx-Webserver mithilfe 

ihrer WSGI-Module oder spezielle 

WSGI-Webserver wie wie Gunicorn oder 

uWSGI sein. Für die Entwicklung enthält 

auch die Flash-Bibiothek einen eigenen 

Webserver. 

Die aktuellste Flask-Version 0.9 erschien 

im Juli 2012, wann Version 0.10 erscheint, 

ist noch ungewiss. Flask setzt mindestens 

Python 2.5 voraus, Python 3 wird derzeit 

noch nicht unterstützt. Am einfachsten 

installieren Sie Flask mit Virtualenv, das 

in einem Verzeichnis eine lokale Version 

von Python und seinen Modulen pflegt, 

die anderen Projekten auf einem Server 

nicht ins Gehege kommen. Virtualenv 

selbst ist in den meisten Linux-Distributionen 

vorhanden. Alternativ lässt es sich 

mit den Python-Paketmanagement-Tools 

»pip« und »easy_install« installieren. 

Die folgenden Befehle legen ein neues 

Projektverzeichnis an, wechseln in dieses 

Verzeichnis und lesen die Shell-Variablen 

ein, die die virtuelle Python-Umgebung 

bestimmen (Abbildung 1): 

virtualenv webprojekt 

cd webprojekt 

source bin/activate 

Wieder zurück in die normale Python- 

Umgebung der Systemebene gelangen Sie 

mit »deactivate«. Solange Sie sich noch 

im Virtualenv befinden, was durch das 

Prompt-Präfix »(webprojekt)« angezeigt 

wird, können Sie Python-Module installieren, 

die dann nur im aktuellen Verzeichnisbau 

landen. Installieren Sie mit 

»pip install Flask« die Bibliothek, ist sie 

danach in »webprojekt/lib/python2.7/ 

site‐packages/flask« zu finden. Werk- 


zeug und Jinja2 werden dann von Pip 

mitinstalliert. 

Routing 

Flask selbst ist kaum mehr als ein Bindeglied, 

das die WSGI-Schicht und die 

Template-Bibliothek zusammenhält. 

Insbesondere kümmert es sich um das 

sogenannte Routing, das URLs auf Funktionen 

abbildet. Die Blaupause hierzu 

stammt vom Ruby-Framework Sinatra 

[5], das seither in zig Varianten in allen 

möglichen Programmiersprachen kopiert 

wurde. Neben Flask ist Bottle ein weiteres 

Python-Beispiel, um das es in der 

Admin-Story dieses Heftes geht. 

Im Prinzip weist der Programmierer bei 

Flask-Anwendungen einzelnen URLs mit 

hilfe von Python-Dekoratoren Funktionen 

zu, die dann mithilfe von Template 

einzelne Webseiten rendern. Im einfachsten 

Fall sieht das so aus: 

@app.route('/') 

def homepage(): 

return "Das ist die Homepage" 

Damit das funktioniert, müssen Sie natürlich 

zu Beginn des Skripts das Flask-Modul 

importieren. Der Name der Funktion 

ist an dieser Stelle erst einmal beliebig. 

Wichtig ist nur, dass die im Dekorator »@ 

app.route« spezifizierte URL »/« mit einer 

Funktion verknüpft ist. Die komplette minimale 

Webanwendung ist in Listing 1 

zu sehen. Das typische Python-Idiom in 

Zeile sorgt dafür, dass »app.run()« nur 

dann abläuft, wenn das Skript vom Interpreter 

aufgerufen und nicht von einem 

anderen Modul importiert wird. 

Bei Pfadnamen sollte man übrigens auf 

den abschließenden Schrägstrich achten. 

Schreibt man ihn hin, etwa bei »@app. 

route("/artikel/")«, funktioniert die URL 

mit oder ohne ihn. Schreibt man dagegen 

nur »"/artikel"«, führt ein Aufruf von 

»http://Server/artikel/« zu einer 404-Fehlermeldung. 

Wer beim Aufruf einer URL 

nach dem HTTP-Verb differenzieren 

möchte, wie man es typischerweise bei 

REST-Anwendungen tut, kann das mit 

dem Keyword-Parameter »methods« tun. 

Die folgende URL lässt sich so nur per 

POST aufrufen: 

@app.route('/login', methods=['POST']) 

Per Default läuft der eingebaute Webserver 

mit der IP-Adresse 127.0.0.1 auf 

Port 5000. Um das zu ändern, übergeben 

Sie die Keyword-Parameter »host=IP‐Adresse« 

und »port=Portnummer« der Methode 

»run()«. Dabei muss man unbedingt 

darauf achten, die eigene Anwendung 

nicht über eine im Internet erreichbare 

Adresse anzubieten, wenn sie im 

Debug-Mode läuft. Dann ist es nämlich 

möglich, über den Webbrowser eigene 

Python-Anweisungen auf dem Server 

auszuführen! 

Templates 

Die schlechte alte Zeit, in der Webseiten 

noch mit Print-Statements ausgegeben 

wurden, sollten längst der Vergangenheit 

angehören. Die alte Praxis führt nicht nur 

zu unwartbarem Code, sondern öffnet 

typischerweise auch leicht Sicherheitslücken. 

Die Alternative dazu ist in Templates 

zu finden, die Code und Präsentation 

trennen. Mit Flask und der Jinja2-Bibliothek 

gelingt dies in einer Zeile: 

render_template("homepage.html") 

E 

OSDC.de 

OPEN SOURCE DATA 

CENTER CONFERENCE 

17. - 18. APRIL 2013 | NUREMBERG 

wwww.netways.de/osdc 

presented by 

NETWAYS ® 


Abbildung 1: Virtualenv installiert eine Python-Umgebung in einem Verzeichnis. Neu installierte 

Erweiterungsmodule landen dann dort in einem Unterverzeichnis. 


presented by 


presented by 

NETWAYS ® 

NETWAYS ® 


103

Programmieren 

Flask 

Weil sich hiermit nur eine statische Seite 

ausliefern ließe, verarbeitet »render_template« 

selbstverständlich auch die Übergabe 

von Variablen, die das Template 

mit »{{ Variable }}« ausgibt. Darüber 

hinaus gibt es auch Kontrollstrukturen, 

etwa For-Loops, die über Sequenzen iterieren 

(Listing 2). Diese sind in »{%« 

und »%}«, aber die Syntax lässt sich auf 

Wunsch auch verändern. Enthält eine 

Variable HTML-Code, maskiert Jinja2 sie 

automatisch vor der Ausgabe – wieder 

eine Maßnahme gegen das ungewollte 

Einschleusen von Exploit-Code. Wer sich 

der Inhalte einer Variable sicher ist, kann 

dieses Verhalten aber auch von Hand 

verhindern. 

Listing 2: Template 

01 

02 

03 {% block head %} 

04 

05 {% endblock %} 

06 

07 

08 

09 {% for item in seq %} 

10 {{ item }} 

11 {% endfor %} 

12 

13 

14 

Abbildung 2: Flask beschränkt sich auf das Wesentliche: WSGI, 

Routing und Templates. Viele andere Funktionen stehen über 

Extensions bereit. 

Besonders interessant ist, dass 

die Templates auch Vererbung 

unterstützen. Somit lassen 

sich gemeinsame Elemente 

aller Webseiten in ein Basis- 

Template auslagern, von dem 

sich alle anderen Templates 

ableiten. Hierbei kann das 

Basis-Template Default-Blocks 

definieren, die davon abgeleitete 

Templates mit jeweils eigenene 

Inhalten „überschreiben“. 

Alternativ dazu können 

Templates andere Templates 

einbinden, womit sich die 

Webseite ebenfalls modular 

strukturieren lässt. 

Variablen 

Damit aus statischen HTML- 

Seiten auch Webanwendungen 

werden, müssen sie dynamisch 

auf Benutzereingaben 

reagieren, die der Webbrowser 

mit GET- oder POST-Requests übermittelt. 

Folgt etwa hinter dem Verzeichnis 

für die Blog-Einträge eine ID, kann Flask 

sie im folgenden Code-Block weiterverarbeiten: 

@app.route('/blog/') 

def show_blog(blog_id): 

render_template("blog.html", post_id) 

Ergänzend dazu darf man die Variable 

auch direkt von einem String in einen 

anderen Typ umwandeln, etwa in einen 

Integer-Wert: »«. 

Um an die Variablen zu kommen, die 

zum Beispiel beim Abschicken eines 

HTML-Formulars per POST übermittelt 

werden, bietet Flask den Zugriff auf das 

HTTP-Request-Objekt, das die Anweisung 

»from flask import request« ins Skript 

importiert. Über das Python-Dictionary 

»form« des Requests-Objekts finden Sie 

dann die Form-Variablen: 

login = request.form['login'] 

Wird die Variable nicht gefunden, erzeugt 

die Methode ein Exception vom 

Typ »KeyError«. Kümmert man sich nicht 

selbst um diesen Fehler, gibt die Webanwendung 

einen HTTP-Fehler 400 „Bad 

Request“ aus. 

Um Variablen von einem Request zum 

nächsten zu speichern, bietet Flask ein 

Session-Objekt an, das ebenfalls wie ein 

Python-Dictionary funktioniert. Aus Sicherheitsgründen 

ist es hierbei wichtig, 

auf einen sicheren (das heißt möglichst 

zufälligen) Schlüssel zu achten, mit dem 

die Sessions signiert werden. 

Datenbanken 

Auch wenn Flask von Haus aus keine 

Datenbank unterstützt, gibt es eine Reihe 

von Extensions, mit denen sich Daten 

permanent speichern lassen. Natürlich 

braucht man hierzu erst einmal gar kein 

besonderes Flask-Modul, denn zum Beispiel 

kann man im eigenen Code mit 

den Python-Standard-Modulen etwa auf 

MySQL und PostgreSQL zugreifen. Ein 

paar Flask-Extensions bieten dabei aber 

etwas mehr Komfort. 

Allen voran geht hierbei Flask- 

SQLAlchemy, das eines der gebräuchlichsten 

Module für den datenbankübergreifenden 

objektorientierten Datenbankzugriff 

(ORM) in Flask integriert. Weitere 

Exntesions gibt es zum Beispiel für beliebte 

NoSQL-Datenbanken wie CouchDB 

und MongoDB. 

Fazit 

Flask ist eine interessante Alternative zu 

Django für alle Python-Webentwickler, 

die nicht gleich den kompletten Funktionsumfang 

das Django-Frameworks nutzen 

wollen. Insbesondere der saubere 

Code und die gute Dokumentation machen 

den Einstieg in Django einfacher. 

Auch gibt es mittlerweile eine fleißige 

Community rund um Flask, die etwa bei 

Problemen hilft und Third-Party-Erweiterungen 

(Abbildung 2, [6]) beisteuert. 

Schade ist nur, dass der Programmautor 

Armin Ronacher wegen beruflicher Verpflichtungen 

weniger Zeit zur Betreuung 

von Flask aufwenden kann. Dank Open 

Source können da andere einspringen.n 

Infos 

[1] Flask: [http:// flask. pocoo. org] 

[2] Werkzeug: [http:// werkzeug. pocoo. org] 

[3] WSGI: [http:// wsgi. readthedocs. org] 

[4] Virtualenv: [http:// www. virtualenv. org] 

[5] Sinatra: [http:// www. sinatrarb. com] 

[6] Flask Extensions: 

[http:// flask. pocoo. org/ extensions] 


Admin-MAGAZIN 

im Jahres-Abo 

Praktisch anwendbares Wissen und ausführliche 

Hintergrundberichte für alle IT-Administratoren 

von Linux, Unix und Windows. 

JETZT Zugreifen 

und über 15% Sparen! 

IHRE vorteile 

• 6 Ausgaben im Jahr Frei Haus 

• inklusive 6 ADMIN-Specials 

(unter anderem zu IPv6 und SSD) 

als PDF-Download im Wert von 

über 35 Euro 

sichern Sie Sich Ihr 

gratis Multitool! 

Jetzt abonnieren: 

www.admin-magazin.de/abo 

(Printabo 49,90 Euro, digitales Abo nur 44,90 Euro) 

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

Programmieren 

Fabric 

© Rusty-Elliott, 123RF 

Serververwaltung mit Python und Fabric 

Patchwork 

Fabric macht es einfach, auf einer Vielzahl von Servern sich wiederholende 

Tasks auszuführen. Voraussetzung dafür sind nur Python und eine 

funktionierende SSH-Konfiguration. Frank Wiles 

Die beiden Tools Chef und Puppet [1] 

sind hervorragend dazu geeignet, große 

Serverlandschaften zu verwalten, erfordern 

aber einen ziemlichen Konfigurationsaufwand. 

Wer regelmäßig auf mehreren 

Servern bestimmte Befehle ausführen 

möchte, sollte alternativ einen Blick auf 

Fabric [2] werfen, ein beeindruckendes 

Python-Modul, das solche Aufgaben als 

flexible Kochrezepte verwaltet. 

Tägliche Aufgaben in Fabric-Tasks zu 

verwandeln, ist eine Hilfe für jeden, der 

mit unterschiedlichen Systemen arbeitet. 

Diese Tasks lassen sich mit dem Befehl 

»fab« ausführen. Ursprünglich verfügte 

Fabric nur über ein paar einfache Features, 

aber im Lauf der Jahre hat es so 

viele dazugewonnen, dass es in manchen 

Fällen Chef und Puppet bereits ersetzen 

kann. 

Setzt auf SSH 

Wenn schon eine SSH-Konfiguration 

existiert, um sich auf einem anderen 

Rechner einzuloggen, kann Fabric davon 

Gebrauch machen. Lokal funktioniert 

Fabric aber natürlich auch. Fabric kann 

einzelne Hosts in bestimmte Tasks einoder 

ausschließen, entweder direkt über 

ihre Namen oder über zugewiesene Rollen. 

Tasks kann Fabric dabei parallel oder 

hintereinander ausführen. Zur besseren 

Kontrolle zeigt Fabric auf Wunsch immer 

an, was es gerade macht – das hilft zum 

Beispiel bei der Fehlersuche. Einfache 

Fähigkeiten für das Management von 

Dateien bringt Fabric im Modul »fabric. 

contrib.files« mit. Mithilfe von »pip« ist 

Fabric einfach zu installieren: 

pip install fabric 

Wer Pip nicht installiert hat, kann es 

stattdessen mit Easy-Install versuchen: 

easy_install fabric 

Alternativ funktioniert normalerweise 

auch die Installation aus dem Quellcode 

ohne große Probleme. 

Ruft man »fabric« auf, sucht das Tool 

im aktuellen Verzeichnis nach der Datei 

»fabfile.py« oder wandert die Verzeichnishierarchie 

nach oben, bis es eine 

solche Datei findet. Auf diese Art ist es 

einfach, in verschiedenen Verzeichnissen 

unterschiedliche Tasks zu verwalten. Mit 

dem Schalter »‐f« lässt sich das Taskfile 

auch direkt angeben. 

Ein erster einfacher Fabric-Task sieht in 

etwa so aus: 


Fabric 

Programmieren 

Abbildung 1: Deployment einer Webanwendung mithilfe von Fabric. 

from fabric import * 

def uptime(): 

run(uptime) 

Er führt das Uptime-Kommando auf jedem 

Rechner aus, der beim Aufruf auf 

der Kommandozeile aufgeführt wird, 

zum Beispiel: 

fab ‐H localhost uptime 

Eine Liste aller verfügbaren Fabric-Tasks 

zeigt »fab ‐l«, allerdings sind dies die 

sogenannten „old style“ Tasks, die alle 

definierten Funktionen einschließen. 

Besser ist es, die new style Tasks zu verwenden, 

bei denen nur Tasks angezeigt 

werden, die sich auch verwenden lassen 

und nicht solche, die nur für interne Zwecke 

eingesetzt werden. Definiert man den 

obigen Task wie folgt neu: 

def uptime(): 

run(uptime) 

definieren. Es verwendet 

Fabric, 

um eine Website 

basierend Git zu 

deployen. Weil die 

Hosts in der Datei 

definiert sind, genügt 

es, auf der 

Kommandozeile 

»fab deploy« auszuführen. 

Zuerst verwendet 

das Skript das 

Python-Datetime- 

Modul, um einen 

Git-Tag-String 

zusammenzusetzen, 

welcher den 

Deployment-Zeitpunkt 

widerspiegelt. 

Dieser Task soll nur einmal ausgeführt 

werden, dafür sorgt der Dekorator »@ 

runs_once«. Der »deploy«-Task führt den 

»tag_deployment«-Task aus und wechselt 

ins Verzeichnis »/home/web«, um dort 

das Git-Kommando zu starten. Am Ende 

des With-Blocks wechselt das Skript automatisch 

wieder zurück ins vorherige 

Verzeichnis und startet mit »sudo« den 

Apache-Webserver neu. Abbildung 1 

zeigt den Ablauf. 

Rollenbasierte Verwaltung 

In größeren Umgebungen sind oft eine 

ganze Reihe von Servern für bestimmte 

Aufgaben zuständig. Mit den von Fabric 

angebotenen Rollen lassen sie sich zusammenfassen 

und in eigenen Skripts 

verwenden. Dazu dient die Variable 

»roledefs«: 

env.hosts = ['www1', 'www2'] 

env.roledefs = { 

'web': ['www1', 'www2'] 

} 

Um einen Task nur für bestimmte Rollen 

auszuführen, gibt man ihn auf der 

Kommmandozeile hinter dem Schalter 

»‐R« an. 

Ein etwas komplizierteres Beispiel legt 

eine Django-basierte Webanwendung zugrunde, 

bei der typischerweise während 

der Entwicklung die Datenbank mit sogenannten 

Migrations regelmäßig zu aktualisieren 

ist (Listing 2). Der dazu gehörige 

Fabric-Task aktualisiert also erst die notwendigen 

Python-Pakete, installiert den 

Code auf allen beteiligten Rechnern und 

führt die Datenbankoperationen einmalig 

auf dem Datenbank-Server aus. List 3 

zeigt das Skript dafür. 

Angepasst 

Der mit »fab deploy« gestartete »deploy«- 

Task führt zuerst auf allen Rechnern »git 

pull« im Verzeichnis »/home/web« aus. 

Auch die in der Datei »/home/web/requirements.txt« 

aufgeführen Python-Pakete 

werden auf allen Rechnern aktualisiert. 

Der Sub-Task »update_tables« läuft dagegen 

nur einmal (»@runs_once«) und 

Listing 1: Uptime von zwei Rechnern 

01 [web1.example.com] Executing task 'get_uptime' 

02 [web1.example.com] run: uptime 

03 11:22 up 17 days, 12:13, 5 users, load averages: 

1.03 1.88 1.32 

04 [web2.example.com] Executing task 'get_uptime' 

05 [web2.example.com] run: uptime 

06 11:22 up 12 days, 22:11, 3 users, load averages: 

1.43 1.38 1.34 

@task 

Listing 2: Migration einer Django-Datenbank 

def get_uptime(): 

01 def get_code(): 

14 # Migrate existing tables and data 

uptime() 

02 with cd("/home/web"): 

15 run('./manage.py migrate') 

zeigt »fab ‐l« nur noch »get_uptime« an 

und übergeht die »uptime«-Funktion. Wie 

das Ergebnis aussieht, wenn man den 

Task mit zwei Hosts aufruft, zeigt das 

Listing 1. 

03 run("git pull ‐t origin master") 

04 

05 def update_pip(): 

06 run("pip install ‐U ‐r /home/web/ 

requirements.txt") 

16 

17 @task 

18 @roles('web') 

19 def restart_apache(): 

20 sudo("/etc/init.d/apache2 restart") 

07 

21 

Hosts in der Datei 

08 @task 

09 @runs_once 

22 @task 

23 def deploy(): 

Die Hosts immer wieder auf der Kommandozeile 

anzugeben, ist auf Dauer 

mühsam. Wie das nächste Beispiel zeigt, 

kann man sie auch direkt in einem Task 

10 @roles('db') 

11 def update_tables(): 

12 # Create new tables 

13 run('./manage.py syncdb') 

24 get_code() 

25 update_pip() 

26 execute('update_tables') 

27 execute('restart_apache') 


Admin 


107

Programmieren 

Fabric 

nur auf dem Datenbank-Server (»@ 

roles('db')«) ab. Analog wird der Apache- 

Servern auf allen Rechnern der »web«- 

Rolle neu gestartet. 

Parallelisiert 

Per Default führt Fabric die definierten 

Tasks hintereinander aus, jeweils auf einem 

Rechner nach dem anderen. Effizienter 

ist es aber, unabhängige Tasks auf 

mehreren Rechnern parallel auszuführen, 

was aktuelle Fabric-Versionen beherrschen. 

Dazu dient der Schalter »‐P«. 

Um genau zu kontrollieren, welche Tasks 

hintereinander und welche parallel abgearbeitet 

werden, bietet Fabric die Dekoratoren 

»@serial« und »@parallel«. 

Um Tasks flexibler zu gestalten, bietet 

Fabric die Möglichkeit, sie zu parametrisieren. 

Definiert werden solche Tasks 

etwa so: 

@task 

def apache(cmd): 

sudo("/etc/init.d/apache2 %s" % cmd) 

Hiermit ruft Fabric das Init-Skript von 

Apache mit dem übergebenen Parameter 

auf. Der dazu gehörige Aufruf lautet dann 

Listing 4: Farbige Ausgabe 

01 from fabric.api import * 

02 from fabric.colors import green, red 

03 

04 @task 

Listing 3: »apache.py« 

01 from fabric.api import * 

02 

03 @task 

04 def start(): 

05 sudo("/etc/init.d/apache2 start") 

06 

07 @task 

08 def stop(): 

09 sudo("/etc/init.d/apache2 stop") 

10 

11 @task 

12 def restart(): 

13 sudo("/etc/init.d/apache2 restart") 

05 def colored_and_silent(): 

06 print green("Running noisy command silently...") 

07 with settings(hide('running', 'stdout', 

'stderr')): 

08 run('/path/to/noisy‐command') 

09 print red("Commands are noisy again") 

10 run('/path/to/another‐noisy‐command') 

zum Beispiel »fab apache:restart«. Um bei 

komplizierten Aufgaben den Überblick 

nicht zu verlieren, bietet sich die Modularisierung 

von Tasks an. Hierbei lassen 

sich Unteraufgaben in eigene Module 

ausgliedern, die sich dank Namespaces 

nicht gegenseitig ins Gehege kommen. 

Ein Beispiel für eine einfach Apache- 

Bibliothek zeigt Listing 3. 

Unter dem Namen apache.py gespeichert, 

lässt sich dieses Modul dann in anderen 

Fabfiles verwenden: 

from fabric.api import * 

import apache 

@task 

def uptime(): 

run('uptime') 

Nun zeigt »fab ‐l« den in dieser Datei 

definierte Task neben den vom Apache- 

Modul importieren an: 

Available commands: 

uptime 

apache.start 

apache.stop 

apache.restart 

Parameter und alles andere funktionieren 

damit weiterhin, die Namespaces bringen 

nur etwas Ordnung in die Skriptsammlung. 

Dateioperationen 

Wie man es von einem solchen Tool 

vielleicht erwarten könnte, bringt es ein 

paar eigene Tasks mit, um mit Dateien 

zu arbeiten. Die Core-API bietet »put()« 

und »get()«, um lokale Dateien auf den 

Server zu laden und umgekehrt. Das 

Modul »contrib.files« enthält noch einige 

Funktionen, die typische Aufgaben abdecken, 

etwa: 

n »append(Dateiname, Text)« hängt einen 

String oder eine Liste von Strings 

an eine Datei an, wenn sie noch nicht 

in der Datei enthalten sind. 

n »comment(Dateiname, Regex)« / 

»uncomment(Dateiname, Regex)« 

kommentiert eine Zeile in einer Datei 

ein oder aus, auf die die aufgeführte 

Regular Expression zutrifft. 

n »contains(Dateiname, Regex)« gibt 

»True« zurück, wenn die Regular Expression 

zutrifft. 

n »exists(Pfad)« liefert den Wert True, 

wenn der Pfad existiert. 

n »first(Pfad)« prüft eine Liste von Pfaden 

und gibt den ersten zurück, der 

existiert. Das ist zum Beispiel praktisch, 

wenn man mehrere potenzielle 

Orte für Konfigurationsdateien durchgehen 

möchte. 

Die Funktion »upload_template()« lädt 

eine Template-Datei, trägt die übergebenen 

Werte ein und lädt das Ergebnis auf 

den Server hoch. Per Default verwendet 

die Funktion das Python-Format für 

String Interpolation. Es ist empfehlenswert, 

stattdessen das Jinja2-Template- 

Format zu verwenden, das sich mit dem 

Parameter »use_jinja=True« einschalten 

lässt. 

Vielfalt 

Mit »‐l« aufgerufen, listet Fabric nur die 

definierten Tasks auf, was in vielen Anwendungsfällen 

genügt. Wer Wert auf 

bessere Dokumentation legt, kann mehr 

Informationen zu jedem Task in den typischen 

Python-Docstrings ablegen, die 

als Erstes nach der Funktions-Definition 

folgen und in drei Anführungszeichen 

eingeschlossen werden: 

@task 

def complicated_steps(): 

""" This task does all of the U 

complicated steps for us. """ 

run(...) 

Jetzt listet »fab ‐l« genauso den Task 

»complicated_steps« auf, gibt aber dazu 

noch die Beschreibung aus. 

Einige weitere Funktionen erlauben mehr 

Kontrolle über die Ausgabe, das Listing 

4 gibt dafür ein Beispiel. So färbt die 

Funktion »green()« die Ausgabe grün, 

wie die Zeile 6 zeigt. In einem With-Block 

eingeschlossen, verhindert das folgende 

»hide()« alle Meldungen des ausgeführten 

Befehls. Eine Zwischenmeldung wird 

mit »red()« rot hervorgehoben, bevor ein 

weiterer Befehl wieder die Standard-Meldungen 

ausgibt. (ofr) 

n 

Infos 

[1] Thomas Gelf, Am Schnürchen, Konfigurationsverwaltung 

mit Puppet, ADMIN 06/ 

2010, S. 50 

[2] Fabric: [http:// fabfile. org] 

[3] Oliver Frommel, Eingepackt, RPMs von und 

für Python, ADMIN 03/2012, S. 120 


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. 

Sicher hinter Gittern.................110 

Mit seinen Jails bietet FreeBSD einen einzigarti - 

gen Mechanismus, um Anwendungen im Interesse 

der Sicherheit voneinander zu isolieren. 

Neubau ........................... 120 

Eine Übersicht über das neue Paketverwaltungssystem 

PKG-NG in FreeBSD. 

Hochzeit .......................... 124 

Wie sich FreeBSD-Server in der KVM-basierten 

FOSS-Cloud virtualisieren lassen. 

© yewkeo, 123RF 


Admin 


109

Jails 

© FFernando Gregory, 123RF 

Wie man Jails in FreeBSD konfiguriert und benutzt 

Sicher hinter 

Gittern 

Heute, wo IT-Sicherheit eine immer größere Rolle spielt, findet ein Feature 

von FreeBSD besondere Beachtung: die Jails. Worin das Sicherheitsplus 

besteht, das sie versprechen, beleuchtet dieser Artikel. Jürgen Dankoweit 

Die Verwaltung der Zugriffsrechte unter 

UNIX und damit auch unter FreeBSD 

kennt im Grunde genommen zwei Typen 

von Benutzern: User mit und User ohne 

Administrator-Privilegien. Dieses Modell 

stößt aber an seine Grenzen, wenn zum 

Beispiel ein Web-Administrator angelegt 

werden soll. Er benötigt Berechtigungen, 

um bestimmte Konfigurationsdateien ändern 

zu dürfen oder den HTTP-Daemon 

neu zu starten – soll aber die Systemkonfiguration 

nicht ändern können. Eine Lösung 

dieses Problems bestünde in einer 

höheren Granularität der Zugriffsrechte. 

In FreeBSD gibt es dafür die Möglichkeit 

mit File Access Control Lists (FACL) zu 

arbeiten oder das Capability- und Sandboxing-Framework 

Capsicum einzusetzen. 

Doch leider erhöht dies den Verwaltungsaufwand 

nicht unerheblich, was 

sich wiederum negativ auf die Sicherheit 

auswirken kann. 

Als ein Ausweg aus diesem Dilemma 

wurde einst die Chroot-Umgebung erfunden, 

die unter Sicherheitsgesichtspunkten 

jedoch Mängel aufweist. Beispielsweise 

sind bei einem FTP-Server, der 

anonymen Zugriff gestattet, Möglichkeiten 

bekannt geworden, aus der Chroot- 

Umgebung auszubrechen. Im Laufe der 

Zeit kamen einige Verbesserungen hinzu, 

aber Probleme wie das Beeinflussen von 

Prozessen außerhalb von Chroot, wurden 

letztlich nicht behoben. 

Das Konzept der Jails 

Hier kommt nun das Konzept der Jails ins 

Spiel: Es nutzt die positiven Eigenschaften 

von Chroot und bietet gleichzeitig 

einen absoluten Schutz vor der Manipulation 

von Prozessen außerhalb der Jail. 

Da eine Jail auf einem Unterverzeichnisbaum 

aufsetzt, ist es einem Prozess 

innerhalb der Jail nicht mehr möglich, 

auf Verzeichnisse und Dateien außerhalb 

zuzugreifen. Weiterhin ist es einem Prozess 

in einer Jail nicht mehr möglich, 

manipulierend auf Prozesse des Hosts 

einzuwirken. Damit bieten sich Jails an, 

um in ihnen Netzwerkdienste laufen zu 

lassen. 

Allerdings erhöht ein Jail nicht die Sicherheit 

eines Daemons selbst. Wenn 

ein FTP-Daemon eine Sicherheitslücke 

aufweist, dann hat er sie auch in der 

Jail. Ein Angreifer könnte diese Lücke 

ausnutzen und sich so Zugang zur Jail 

verschaffen und dort womöglich sogar 

Root-Rechte erlangen. Dennoch bliebe 

ein großer Sicherheitsvorteil bestehen, 

denn der Angreifer könnte nur in der Jail 

sein Unwesen treiben. Er hätte keinerlei 

Zugang zum Hostsystem! Dabei erhöht 


Jails 

sich anders als bei einer fein granulierten 

Zugriffsverwaltung der Aufwand nur 

moderat. Das Ausbrechen von Prozessen 

oder die Beeinflussung anderer Prozesse 

außerhalb einer Jail sind nicht mehr 

möglich. 

In einer Jail gibt es wieder einen Root- 

User, allerdings mit etwas eingeschränkten 

Möglichkeiten. Unter anderem hat 

er keine Chance, den Host oder die IP- 

Adresse der Jail zu manipulieren. Durch 

bestimmte Sysctl-MIBs lassen sich die 

Befugnisse von root innerhalb der Jail 

noch weiter einschränken. Es ist möglich, 

einer Jail keine oder mehrere IPv4- beziehungsweise 

IPv6-Adressen zuzuordnen, 

was sie zu einer Routing-fähigen Jail 

macht. Die Adresse wird beim Start der 

Jail mit angegeben. Auch die Loopback- 

Adresse 127.0.0.1 und ihr IPv6-Pendant 

::1 dürfen mit einer Jail verknüpft werden. 

Man spricht dann von einer internen 

Jail. 

Innerhalb einer Jail steht dem Benutzer 

ein komplettes FreeBSD zur Verfügung. 

Damit bieten Jails auch eine Art 

von Virtualisierung wie VMware oder 

Xen. Seit FreeBSD 8 besteht sogar die 

Möglichkeit, in einer Jail weitere Jails 

anzulegen (Hierachical Jails). Das mit 

FreeBSD 4 eingeführte Konzept der Jails 

hat vor einiger Zeit auch einen anderen 

Betriebssystemanbieter überzeugt: Sun 

Microsystems (heute Oracle). In Solaris 

heißen die Jails Zones. 

Beschränkungen 

Innerhalb einer Jail gibt es aufgrund der 

Implementierung wichtige Einschrän- 

Tools zur Verwaltung von Jails 

Um die Verwaltung von Jails vom Hostsystem 

aus zu ermöglichen, gibt es ein paar Tools, die 

kurz beschrieben werden. jail [-i] [-l ‐u 

| ‐U ] 

: Startet eine Jail im 

angegebenen Pfad, mit der IP-Adresse und dem 

Kommando. Falls die Option ‐l gesetzt ist, wird 

vor dem Start das Environment auf Standardwerte 

gesetzt. Das angegebene Kommando wird 

dabei mit den User-Rechten des Hostsystems 

(-u) oder mit den Rechten des Users innerhalb 

der Jail (-U) ausgeführt. jexec [-u | 

‐U ] : Führt ein Kommando mit den 

Parametern innerhalb einer Jail aus. Dabei startet 

es mit den User-Rechten des Hostsystems 

kungen. Remote-Procedure-Calls (RPC) 

funktionieren im Jail-Betrieb aus Sicherheitsgründen 

nicht mehr. Daher gibt es 

keine Möglichkeit, NFS innerhalb einer 

Jail zu nutzen. Daemon-Prozesse auf dem 

Host müssen sehr sorgfältig konfiguriert 

sein, damit es nicht zu Adresskonflikten 

zwischen Jail und Host kommt. Das Laden 

oder Entladen von Kernelmodulen 

ist innerhalb einer Jail genauso unterbunden 

wie das Erstellen von Device- 

Nodes. Das Mounten und Unmounten 

von Dateisystemen ist nicht möglich. 

Das Modifizieren der Netzwerkkonfiguration, 

der Netzwerkadressen oder auch 

der Routing-Tabellen ist verboten. Der 

Zugriff auf sogenannte Raw-Sockets des 

Hostsystems ist nicht mehr möglich, aber 

innerhalb der Jail besteht die Möglichkeit, 

auf diesen Typ von Sockets zuzugreifen. 

Ebenso ist es nicht gestattet, Semaphoren 

des Hostsystems anzusprechen. 

Aus den meisten dieser Einschränkungen 

resultiert bei genauer Betrachtung ein Sicherheitsgewinn 

im Vergleich zu einer 

Chroot-Umgebung. 

Implementierung der Jails 

Bei den Jails lohnt ein Blick hinter die 

Kulissen. Das Konzept besteht aus zwei 

Komponenten: Zum einen das Tool »jail«, 

das die Benutzerschnittstelle zwischen 

dem Kernel und dem Userland darstellt, 

zum anderen Code im Kernel, der per 

Systemcall angesprungen wird. 

Das Tool »jail« benötigt folgende Parameter: 

den Pfad zur Jail, den Hostnamen der 

Jail, die korrespondierende IP-Adresse 

und das auszuführende Kommando. 

(-u) oder mit den Rechten des Users innerhalb 

der Jail (-U). Zur eindeutigen Identifizierung 

der Jail ist auch hier wieder die JID anzugeben. 

jls: Erzeugt eine Liste aller im Moment 

gestarteten Jails. Es werden dabei die Identifizierungsnummer 

der Jail (JID), IP-Adresse, 

Hostname und Pfad zur Jail ausgegeben. Die JID 

ist eine fortlaufende Nummer, unter der die Jail 

eindeutig identifiziert wird. Die JID ist für killall 

wichtig. killall ‐j - : 

Damit wird an einen Prozess innerhalb einer 

Jail ein Signal gesendet. Wenn kein Prozessname 

und Signal angegeben ist, dann wird die 

ganze Jail beendet. „Signal“ bezeichnet die in 

UNIX üblichen Signale wie SIGTERM, SIGKILL 

et cetera. 

Wie in einem Auszug aus dem Quellcode 

zu ersehen ist (Listing 1), enthält der 

Funktionsaufruf »jail« eine Struktur »jail« 

(struct jail: »/usr/include/sys/jail.h«), in 

der die eben genannten Parameter gespeichert 

sind. 

Nachdem die Struktur mit Informationen 

versorgt ist, sperrt sich das Tool »jail« 

selbst ein »(i = jail(&j))« und erzeugt 

in dieser Umgebung einen Tochterprozess, 

der das gewünschte Kommando 

mittels »execv()« ausführt. Wie eingangs 

erwähnt, wird die Kernelfunktion »jail« 

aufgerufen: 

int jail(struct proc *p, struct U 

*jail_args uap); 

Diese Funktion kopiert die in »uap« 

(struct jail) gespeicherten Informationen 

in den Kernel-Memory-Space und 

speichert einen Teil der Informationen in 

einer C-Struktur »prison«. Danach wird 

»chroot()« mit zwei Parametern aufgrufen, 

die zum einen den Pfad der Jail 

enthalten und zum anderen den aufrufenden 

Prozess. 

Einschluss 

Wie wird ein Prozess in eine Jail „eingesperrt“? 

In FreeBSD wird jeder Prozess 

durch eine C-Struktur »proc« dargestellt, 

die in »/usr/include/sys/proc.h« beschrieben 

ist. Sie enthält einen Pointer, 

der auf die Struktur »prison« zeigt. Das 

Feld »p_flag« mit dem Wert »P_JAILED« 

zeigt der Prozessverwaltung an, dass der 

Prozess in einer Jail auszuführen ist. E 

Listing 1: »struct jail« 

101 main(int argc, char **argv) 

02 { 

03 struct jail j; 

04 int i; 

05 [...] 

06 /* Belegen der Struktur jail */ 

07 memset(&j, 0, sizeof(j)); 

08 j.version = 0; 

09 j.path = ; 

10 j.hostname = ; 

11 j.ip_number = ; 

12 /* system‐call aufrufen */ 

13 i = jail(&j); 

14 [...] 

15 execv(, ...); 

16 [...] 

17 exit(0); 

18 } 


Admin 


111

Jails 

Die hohe Schutzwirkung begründet sich 

in der Art und Weise, wie die Prozess- 

Verwaltung des FreeBSD-Kernels die 

C-Struktur struct »proc« verarbeitet. 

Sobald ein Prozess durch das Zeitscheibenverfahren 

wieder Rechenzeit zugewiesen 

bekommt, wird anhand von 

»proc‐>prison‐>p_flag« geprüft, ob der 

Prozess einer Jail angehört oder nicht. 

Bei Prozessen, die innerhalb einer Jail 

gestartet wurden, ist dieses Flag bedingungslos 

gesetzt. Viele andere Kernel- 

Dienste entscheiden bei jedem Zugriff 

anhand des genannten Flags, ob und wie 

auf Ressourcen zugegriffen werden darf. 

Ein Auszug aus dem Quellcode verdeutlicht 

den Ablauf (Listing 2). Abbildung 1 

stellt die Kommunikationswege dar. 

Installation, Konfiguration 

und Aktualisierung 

Die Installation von Jails ist nicht sonderlich 

schwer, erfordert aber Sorgfalt bei der 

Konfiguration. Schließlich steht die Sicherheit 

an vorderster Stelle. Alle Befehle 

dürfen nur vom Root-User ausgeführt 

werden. Um eine Jail zu erstellen, benötigt 

man mindestens 150 MByte freie Plattenkapazität. 

Sobald Dienstprogramme 

dazukommen natürlich entsprechend 

mehr. Als Beispiel sei eine Jail erstellt, die 

Web-Services beherbergt. Dafür benötigt 

man in etwa 4 GByte Platz. Damit ist es 

dann auch möglich, einen FAMP-Server 

(FreeBSD, Apache, MySQL, PHP) oder 

ein Content-Management-System (CMS) 

aufzusetzen. Des Weiteren sollten die 

Betriebssystem- und Kernel-Quelltexte 

installiert sein. Die Vorgehensweise ist 

im Handbuch ausführlich beschrieben. 

Um eine Jail zu erstellen, sind die nachfolgenden 

Schritte auszuführen: 

# mkdir ‐p /jail/www 

# cd /usr/src 

# make world DESTDIR=/jail/www 

# cd etc 

# make distribution DESTDIR=/jail/www 

# mount_devfs devfs /jail/www/dev 

# cd /jail/www 

# ln ‐sf dev/null kernel 

Nachdem alles kompiliert und installiert 

ist, werden der Jail über das Device- 

Filesystem (»devfs«) Geräte zugänglich 

gemacht. Dieses Mounting muss unbedingt 

vor dem Start der Jail abgeschlossen 

sein. Weil einige Programme eine 

Datei »/kernel« erwarten, wird sie ihnen 

mit einem symbolischen Link vorgegaukelt. 

Tatsächlich ist aber der Kernel des 

Hostsystems für alle Jails zuständig. 

Bevor die Jail das erste Mal gestartet 

wird, sind einige Dienstprogramme auf 

dem Host dahingehend zu prüfen, ob 

sie an die IP-Adresse des Hostsystems 

gebunden sind. Dies geschieht mit dem 

einfachen Befehl 

# sockstat | grep "\*:[0‐9]" 

In der Beschreibung zu »rc.conf(5)« werden 

die Dienste aufgeführt, die per Parameter 

an eine feste IP-Adresse gebunden 

werden müssen. Ein Beispiel hierfür ist 

der Dienst inetd: 

inetd_flags="‐wW ‐a IP‐Adresse U 

Hostsystem" 

Der Mail-Dienst sendmail sollte auf dem 

Hostsystem so gestartet werden, dass 

er nur noch auf die localhost-Adresse 

hört (»sendmail_enable="NO"«). Zum 

Abschluss der Installation der Jail wird 

das Netzwerk-Interface des Hostsystems 

konfiguriert. 

Routingfähige Jails 

Einer Routing-fähigen Jail muss man mit 

folgendem Kommando eine IP-Adresse 

zuordnen: 

# ifconfig netif0 inet alias 

IP‐Adresse Jail/32 

Wobei »netif0« das Netzwerk-Interface 

ist. Dies sollte auch so in die Datei »/ 

etc/rc.conf« des Hostsystems eingetragen 

werden: 

ifconfig_netif0_alias0="inet U 

IP‐Adresse Jail netmask U 

255.255.255.255" 

Eine interne Jail dagegen bekommt immer 

die IP-Adresse des Loopback-Interfaces 

zugewiesen: 

# ifconfig lo0 inet alias 

127.0.0.1/32 

Wobei »lo0« das Loopback-Interface ist. 

Auch dies sollte man so in die Datei 

»/etc/rc.conf« des Hostsystems eintragen: 

ifconfig_lo0_alias0=U 

"inet 127.0.0.1 netmask 255.255.255.255" 

Für die folgenden Schritte spielt es keine 

Rolle mehr, ob es sich um eine interne 

oder Routing-fähige Jail handelt. 

Nachdem die Installation soweit abgeschlossen 

ist, wird die Jail mit dem 

Hostnamen »www.heimnetz.net«, der IP- 

Adresse »192.168.1.200« und der Shell 

»/bin/sh« für die Konfiguration manuell 

gestartet: 

Listing 2: Ressourcenzugriff 

01 int jail(struct thread *td, 

02 struct jail_args *uap) 

03 { 

04 struct prison *pr, *tpr; 

05 struct jail j; 

06 struct jail_attach_args jaa; 

07 [...] 

08 error = copyin(uap‐>jail, &j, 

09 sizeof(j)); 

10 [...] 

11 MALLOC(pr, struct prison *, 

12 sizeof(*pr), 

13 M_PRISON, M_WAITOK | M_ZERO); 

14 [...] 

15 error = copyinstr(j.path, 

16 &pr‐>pr_path, sizeof(pr‐>pr_path), 0); 

17 [...] 

18 error = copyinstr(j.hostname, 

19 &pr‐>pr_host, sizeof(pr‐>pr_host), 0); 

20 [...] 

21 pr‐>pr_ip = j.ip_number; 

22 pr‐>pr_linux = NULL; 

23 pr‐>pr_securelevel = securelevel; 

24 [...] 

25 error = jail_attach(td, &jaa); 

26 [...] 

27 FREE(pr, M_PRISON); 

28 [...] 

29 return (error); 

30 } 

31 

32 int jail_attach(struct thread *td, 

33 struct jail_attach_args *uap) 

34 { 

35 struct proc *p; 

36 struct prison *pr; 

37 

38 [...] 

39 p = td‐>td_proc; 

40 [...] 

41 error = change_dir(pr‐>pr_root, td)); 

42 [...] 

43 change_root(pr‐>pr_root, td); 

44 [...] 

45 return (error); 

46 } 


Jails 

# jail /jail/www www.heimnetz.net U 

192.168.1.200 /bin/sh 

Ab jetzt befindet sich der Administrator 

innerhalb der Jail. Zunächst 

ist das Passwort für den Root-User 

zu setzen. Es sollte auch ein User 

angelegt werden, der wie root der 

Gruppe »wheel« angehört und unter 

dessen Kennung man sich später 

per SSH einloggt. Um Warnungen 

wegen einer nicht vorhandenen 

Filesystem-Tabelle zu vermeiden, 

ist eine leere »/etc/fstab« zu erzeugen. 

Die Datei »/etc/rc.conf« sollte 

mindestens wie nachfolgend aussehen: 

rpcbind_enable="NO" 

network_interfaces="" 

hostname="www.heimnetz.net" 

sshd_enable="YES" 

sshd_flags="‐p Port Jail" 

sendmail_enable="NO" 

syslogd_enable="YES" 

syslogd_program="/usr/sbin/syslogd" 

syslogd_flags="‐ss" 

defaultrouter="IP‐Adresse Router" 

Des Weiteren ist die Konfiguration für 

den SSH-Daemon in der Datei »/etc/ssh/ 

sshd_config« zu ändern: 

ListenAddress IP‐Adresse Jail 

sowie in die Datei »/etc/resolv.conf« den 

oder die Domain-Name-Server einzutragen: 

»nameserver IP‐Adresse DNS«. 

Logs in der Jail 

In einer Jail werden genauso wie auf dem 

Hostsystem durch den Daemon »syslogd« 

Logfiles erzeugt. Um zu kontrollieren, 

was in den einzelnen Jails geschieht, ist 

es umständlich, sich in jeder Jail anzumelden. 

Einfacher geht es, wenn man die 

Ausgaben des »syslogd« auf den Host umleitet. 

In der Systemkonfiguration »/etc/ 

rc.conf« der Jail aktiviert man zunächst 

den Daemon: »syslogd_enable="YES"«. 

In »/etc/syslog.conf« trägt man als einzige 

Zeile 

*.* @ Adresse des Syslog‐Hosts 

FreeBSD- 

Userland 

ein und startet den Daemon mit »/etc/ 

rc.d/syslogd restart« neu. 

Damit ist die Konfiguration innerhalb 

der Jail abgeschlossen, und mit »exit« 

verlässt man sie wieder. Für einen ab- 

FreeBSD- 

Kernel 

jail() 

jail() 

execv() 

Prozessverwaltung 

chroot() 

Treiber 

Dateisystem 

Wenn das Hostsystem auf den neuesten 

Stand gebracht wird, müssen die Jails 

ebenfalls aktualisiert werden. Dazu wechschließenden 

Test startet man die Jail so, 

wie sie später beim Booten hochgefahren 

wird 

# jail /jail/www www.heimnetz.net 

192.168.1.200 /bin/sh /etc/rc 

Mit »ssh root@www.heimnetz.net ‐pPort 

Jail« meldet man sich an der Jail an. 

Wenn alles korrekt konfiguriert ist, erscheint 

der Prompt der Jail. 

Am Hostsystem müssen noch letzte Konfigurationsarbeiten 

erledigt werden. Da 

die Jail beim nächsten Systemboot mit 

gestartet werden soll, sind in der Datei 

»/etc/rc.conf« Ergänzungen vorzunehmen: 

jail_enable="YES" 

jail_list="www" 

jail_www_rootdir="/jails/www" 

jail_www_hostname="Hostname Jail" 

jail_www_ip="IP‐Adresse Jail" 

jail_www_exec="/bin/sh /etc/rc" 

jail_www_devfs_enable="YES" 

jail_www_devfs_ruleset="devfsrules_jail" 

jail-Tool 

Kernel 

Abbildung 1: Kommunikation zwischen Userland und Kernel beim 

Erstellen einer Jail. 

Die Bedeutung der einzelnen Zeilen sei 

hier kurz erläutert. Um eine Jail zu starten 

muss der Eintrag »jail_enable="YES"« 

gesetzt sein. Falls mehrere Jails vom 

Hostsystem gestartet werden sollen, sind 

diese in eine Liste unter dem Schlüsselwort 

»jail_list« durch Leerzeichen 

getrennt einzutragen. Sie werden dann 

auch in der angegebenen Reihenfolge 

hochgefahren. Auffallend ist die letzte 

Zeile. In ihr wird das Regelwerk für den 

Device-Filesystem-Dienst festgelegt. Damit 

alles korrekt funktioniert, muss in 

eine vorhandene Konfiguration »/etc/ 

devfs.rules« der Inhalt aus »/etc/defaults/ 

devfs.rules« eingefügt werden. Die ande- 

ren Angaben sind für jede einzelne 

Jail zu machen. Zu beachten ist 

aber, dass der in »jail_list« angegebene 

Name sich in den anderen 

Angaben wiederfindet, wie es im 

Beispiel zu sehen ist. 

Zusätzlich ersetzt oder ergänzt man 

in der Konfiguration »/etc/rc.conf« 

die Angaben für den Syslog-Daemon 

um diesen Eintrag: 

syslogd_flags= U 

"‐a IP‐Adresse des Netzwerks/24 

‐4 U 

‐b hostdresse" 

Anschließend startet man den Syslog-Daemon 

neu. 

Starten und Stoppen 

Sobald alle Parameter in »/etc/rc.conf« 

eingetragen sind, lässt sich die Jail wie 

folgt starten: 

# /etc/rc.d/jail start Name der Jail 

Angehalten wird sie mit »stop Name der 

Jail« Wenn alle Jails gestoppt werden sollen, 

lässt man den Namen der Jail weg. 

Software lässt sich auf die gleiche Art und 

Weise installieren wie auf dem Hostsystem. 

Entweder in Form von Binärpaketen 

mit »pkg_add ‐r Paketname« oder über 

die Ports. Dazu muss allerdings der Ports- 

Tree vom Hostsystem in die Jail gemountet 

werden, und es muss das Verzeichnis 

»/usr/ports« in der Jail existieren. Zu 

diesem Zweck gibt es das Dateisystem 

»nullfs«. Auf dem Hostsystem wird dieser 

Befehl ausgeführt: 

# mount_nullfs ‐o ro /usr/ports 

/jail/www/usr/ports 

und man ergänzt »/etc/fstab« des Hosts 

um den folgenden Eintrag: 

/jails/www/usr/ports /usr/ports 

nullfs rw 0 0 

Zusätzlich sind dann noch zwei Änderungen 

an »/etc/make.conf« der Jail notwendig: 

WRKDIRPREFIX=/tmp 

DISTDIR=/tmp/distfiles 


Admin 


113

Jails 

selt man als Root-User in das Verzeichnis 

»/usr/src«. Da ein »make buildworld« auf 

dem Host meist schon ausgeführt wurde, 

ist es für die Jail nicht mehr notwendig. 

So genügt 

# cd /usr/src 

# mergemaster ‐p ‐D Pfad zur Jail 

# make installworld DESTDIR=U 

Pfad zur Jail 

# mergemaster ‐D Pfad zur Jail 

Damit ist das Update einer Jail abgeschlossen. 

Manchmal ist es wichtig zu 

sehen, ob und welche Prozesse innerhalb 

einer Jail wirklich laufen. Da hilft das 

Kommando »ps ‐ax« weiter. Der folgende 

Auszug aus der Prozessliste zeigt, welche 

Prozesse in einer Jail laufen. Zu erkennen 

ist es am zusätzlichen »J« in der Spalte 

Status (STAT). 

# ps ‐ax 

708 ?? SsJ 0:00,42 /usr/sbin/syslogd ... 

722 ?? SsJ 0:17,19 /usr/sbin/named ... 

774 ?? SsJ 0:00,12 /usr/sbin/sshd ... 

781 ?? IsJ 0:00,87 /usr/sbin/cron ‐s 

... 

Mit dem Kommando »jls« lassen sich alle 

derzeit aktiven Jails anzeigen: 

# jls 

JID IP Address Hostname Path 

1 192.168.1.201 dns.domain.tld 

/home/jail/dns 

2 192.168.1.202 www.domain.tld 

/home/jail/www 

3 192.168.1.203 xwindow.domain.tld 

/home/jail/xwindow 

Jails, vereinfacht 

Eine alternative und deutlich einfachere 

Möglichkeit Jails auf einem Host zu erstellen, 

geschieht mit der Skript-Sammlung 

»ezjail«. Sie befindet sich in den Ports in 

Listing 3: DHCP-Konfiuration 

01 dhcpd_enable="YES" 

02 dhcpd_flags="‐q" 

03 dhcpd_conf="/usr/local/etc/dhcpd.conf" 

04 dhcpd_umask="022" 

05 dhcpd_chuser_enable="YES" 

06 dhcpd_withuser="dhcpd" 

07 dhcpd_withgroup="dhcpd" 

08 dhcpd_devfs_enable="YES" 

09 dhcpd_makedev_enable="NO" 

10 dhcpd_chroot_enable="NO" 

11 dhcpd_jail_enable="NO" 

12 dhcpd_rootdir="/var/db/dhcpd" 

13 dhcpd_hostname="dns" 

14 dhcpd_ipaddress="" 

der Rubrik »sysutils« und lässt sich mit 

»portinstall« oder »pkg_add ‐r« schnell installieren. 

Die folgenden Schritte sind als 

Root-User auszuführen. Im ersten Schritt 

erstellt man eine Basis-Jail, die als Schablone 

für alle weiteren Jails dient. Dazu 

dient das Kommando 

# ezjail‐admin update ‐pP 

Dieser Prozess dauert je nach Leistung 

des System etwa zwei bis fünf Stunden, 

da durch das Ausführen von »make 

world« alles neu kompiliert wird. Mit 

dem Parameter »‐i« anstelle von »‐pP« 

lässt sich diese Prozedur umgehen, da 

dann nur noch »make installworld« ausgeführt 

wird. Für die weiteren Schritte gilt 

wieder, dass der Unterschied zwischen 

internen und Routing-fähigen Jails nur in 

der Vergabe der IP-Adresse besteht. 

Der folgende Schritt erzeugt eine Jail: 

# ezjail‐admin create Jail‐Name U 

IP‐Adresse 

Wie oben beschrieben, sind in »/etc/ 

rc.conf« die entsprechenden Parameter 

für das Netzwerkinterface und die Jails 

einzutragen. Sie unterscheiden sich übrigens 

nicht. Zusätzlich ist diese Zeile 

einzutragen: 

# Jails mit ezjail starten 

ezjail_enable="YES" 

Jetzt lassen sich die Jails mit »/usr/ local/ 

etc/rc.d/ezjail.sh start« starten. Alternativ 

bietet sich sich an: »ezjail‐admin start«. 

Der Aktualisierungsprozess gerät mithilfe 

von »ezjail« zum Kinderspiel. Ein einfacher 

Aufruf von »ezjail‐admin update ‐i« 

genügt und die Jail wird auf den neuesten 

Stand gebracht. Die Anwendungen innerhalb 

der Jail müssen allerdings in einem 

weiteren Schritt aktualisiert werden. Wie 

der geübte Administrator schnell erkennt, 

bedeutet die Skript-Sammlung »ezjail« 

eine enorme Arbeitserleichterung. Man 

muss nicht mehr die einzelnen »make«- 

Befehle eingeben und ausführen lassen. 

Viele Dienste, eine Jail 

Wie bereits beschrieben, dient eine Jail 

unter anderem zur Absicherung des Hosts 

vor Hacking-Angriffen auf bestimmte 

Dienste. Bekannteste Beispiele sind der 

DNS-Dienst »bind« und der Webserver. 

Bei allen Diensten kommt es darauf an, 

dass sie immer nur an die IP-Adresse 

der Jail gebunden werden. Das nächste 

Beispiel installiert den DNS-Dienst »bind« 

in einer Jail. Für kleine Netzwerke muss 

man nicht unbedingt einen eigenen Rechner 

für »bind« vorsehen, da genügt eine 

Jail auf dem zentralen FreeBSD-Server 

vollkommen. Aber Primary- und Secondary-DNS 

sollte man niemals jeweils in 

einer Jail auf einem Hostsystem laufen 

lassen. Würde das Hostsystem ausfallen, 

wären weder der Primary- noch der 

Secondary-DNS erreichbar. In der Konfigurationsdatei 

von »bind« genügt folgender 

Eintrag: 

listen‐on port 53 { 

IP‐Adresse der Jail; 

}; 

Weiterhin muss die Datei »/etc/resolv. 

conf« auf jedem Rechner – einschließlich 

des Hostsystems! – im Netzwerk angepasst 

werden. 

DHCP und Mail in der Jail 

Es ist möglich, einen DHCP-Server [10] 

in einer Jail zu betreiben. Dazu muss der 

Port ISC-DHCP3-SERVER aus dem Verzeichnis 

»/usr/ports/net/isc‐dhcp3‐server« 

so kompiliert werden: 

# make install ‐DDHCP_PARANOIA 

‐DDHCP_JAIL ‐DDHCP_SOCKETS 

# make clean 

In der Jail wird in die Systemkonfiguration 

»/etc/rc.conf« eingetragen, was 

Listing 3 zeigt. 

Die Konfigurationsdatei »/usr/local/etc/ 

dhcpd.conf« des DHCP-Daemons muss 

durch diese Zeile ergänzt werden: 

local‐address IP‐Adresse Jail; 

Auf dem Hostsystem aktiviert man im 

Kernel den Treiber für das Berkeley Packet 

Filter (»bpf«). Zusätzlich ist das 

Regelwerk für den devfs-Daemon im 

Abschnitt [devfsrules_jail=4] um diesen 

Eintrag zu erweitern: »add path 'bpf*' 

unhide«. 

Die HTTP-Dienste Apache oder Lighttp 

müssen ebenfalls an eine Adresse gebunden 

werden. Der Eintrag in »httpd.conf« 

lautet wie folgt: »Listen :80« 

Man kann auch einen Mail-Server innerhalb 

einer Jail installieren. Die Anpas- 


JETZT 

MIT DVD! 

MAGAZIN 

Sonderaktion 

Testen Sie jetzt 

3 Ausgaben 

für 3 Euro! 

Jetzt schnell bestellen: 

• Telefon 07131 / 2707 274 

• Fax 07131 / 2707 78 601 

• E-Mail: abo@linux-magazin.de 

• Web: www.linux-magazin.de/probeabo 

Mit großem Gewinnspiel unter: 

www.linux-magazin.de/probeabo 

Gewinnen Sie... 

eines von zwei tollen Gadgets (das Los entscheidet) 

Einsendeschluss ist der 15.03.2013

Jails 

NAT 

Paket-Filter 

PF 

Jail 1 

------------- 

WWW 

192.168.1.201 

Jail 2 

------------- 

DNS 

192.168.1.202 

Hostsystem 

server.heimnetz.net 

192.168.1.1 

Jail 3 

------------- 

Mail 

192.168.1.203 

Port 80 Port 53 Port 25 

ssh 

ssh 

ssh 

NAT 

Paket-Filter 

PF 

WWW 

Jail 1 

------------- 

WWW 

192.168.1.201 

Web-GUI für 

Datenbank 

Port 80 Port 22 Port Datenbank 

ssh 

Hostsystem mit Datenbank 

server.heimnetz.net 

192.168.1.1 

G Abbildung 3: Datenbank-Server mit WWW-Anbindung. 

F Abbildung 2: Server mit Diensten in einer Jail. 

Datenbank 

sung ist aber umfangreicher, als bei den 

vorangegangenen Beispielen. An einem 

Mail-Server mit Postfix-MTA [11] mit 

Spam-Filter und Viren-Scanner soll die 

Vorgehensweise beschrieben werden. 

In den Konfigurationsdateien von Postfix 

»/usr/local/etc/postfix/main.cf« und 

»/usr/local/etc/postfix/master.cf« ist 

die IP-Adresse des localhost durch die 

IP-Adresse der Jail zu ersetzen. Selbstredend 

muss auch der Hostname »localhost« 

gegen den Hostnamen der Jail 

getauscht werden, sofern die Jail nicht 

die IP-Adresse des Localhost verwendet. 

Das Gleiche gilt für die Konfiguration des 

Spam-Filters und des Viren-Scanners. 

Damit nun auf dem Hostsystem E-Mails 

Regeln für die Paketfilter PF und IPFW 

Damit Routing-fähige Jails auch von außen erreichbar 

sind, müssen entsprechende Regeln für 

PF und IPFW [9] geschrieben werden. Zunächst 

zu PF, dem Paketfilter, der von OpenBSD portiert 

wurde. 

# NAT‐Regeln fuer PF 

# ================= 

extif = "Internet‐Interface" 

intif = "Intranet‐Interface" 

nat_jail = "Jail‐IP‐Adresse" 

nat on $extif from $intif:network toU 

any ‐> ($extif) 

rdr on $extif proto tcp from any toU 

any port Port ‐> $nat_jail 

pass in on $extif inet proto tcp U 

from any to $nat_jail port Port 

Zunächst wird festgelegt, auf welchem Netzwerk-Interface 

(»$extif«) der Datenstrom belauscht 

werden soll. Anschließend leitet PF alle 

Daten in einer Datenbank besonders 

geschützt sein sollten. Daher installiert 

man das Datenbanksystem auf dem Host 

und kommuniziert über eine IP-Adresse 

mit der Datenbank. Ähnliches gilt auch 

für Datenbank-Server, die über ein Web- 

Interface, administriert werden. Es gelten 

dabei besondere Sicherheitsvorkehrungen. 

Der WWW-Dienst sollte hierbei 

unbedingt in einer Jail laufen, damit im 

Falle einer ausgenutzten Schwachstelle 

im Daemon-Prozess nicht der gesamte 

Datenbestand der Datenbank auf dem 

Spiel steht. Abbildung drei zeigt eine solche 

Konfiguration. 

Dienste, die auf dem RPC-Protokoll basieren, 

lassen sich in einer Jail nicht bevom 

System weiterhin verschickt werden, 

muss der DNS-Dienst im Netzwerk einen 

sogenannten MX-Record enthalten. 

Alle Jails auf einem Host 

Es ist natürlich möglich und für kleine 

Firmen und Heim-Netzwerke interessant, 

alle Dienste jeweils in einer Jail auf einem 

Hostsystem zu installieren. Abbildung 

zwei verdeutlicht die Konfiguration. 

Oftmals liest man in diversen Foren, dass 

es Administratoren gibt, die einen Datenbankserver 

in einer Jail installieren. 

Das sollte man unterlassen, da einige 

Datenbanksysteme über System-V-IPC 

kommunizieren beziehungsweise die 

TCP-Daten, die über das externe Interface an 

Port »Port« gesandt werden, an die IP-Adresse 

der Jail (»$nat_jail«) um. Damit die Daten auch 

ungehindert durch den Paketfilter fließen, wird 

mit »pass« ein Kanal freigeschaltet. 

Bei IPFW ist die Sache umfangreicher. Es müssen 

das IPFW-Skript und NAT-Regeln für den NAT- 

Daemon erstellt werden. Die Regeln für den NAT- 

Daemon (»natd«): 

# NAT‐Regeln fuer natd 

# /etc/natd.conf 

# ================= 

redirect_port tcp : U 

 

redirect_port tcp : U 

 

Damit IPFW im System verfügbar ist, müssen 

diverse Optionen im Kernel aktiviert sein. Dazu 

ist es ratsam, sich die einschlägige Literatur wie 

beispielsweise das sehr gute Handbuch durchzulesen. 

Damit alles lesbarer ist, setzt man eine 

Variable: »fwcmd="/sbin/ipfw ‐f"« Dann muss 

auch hier wieder der Datenverkehr, der über 

das Interface tun0 führt, für den NAT-Daemon 

zugänglich gemacht werden. Die folgende Regel 

sollte eine der ersten Angaben im Skript sein: 

${fwcmd} add divert natd all from any to 

any via tun0 

Damit keiner über den umgeleiteten Datenstrom 

Schaden anrichten kann, folgt eine weitere Regel: 

${fwcmd} add allow tcp from any to any 

setup keep‐state 

@KL: Die letzte Regel sollte immer sein: 

${fwcmd} add deny ip from any to any 

Nach dem Einlesen des Konfiguration bei PF 

oder dem Ausführen des Skripts für IPFW werden 

die Regeln aktiv. Zu jeweiligen Konfiguration 

sei dringend auch die Dokumentation zu Tools 

empfohlen. 


3 Ausgaben 

für nur 5,90 E 

Jetzt bestellen: 3 Hefte zum Preis von einem. Sie sparen 66 %! 

Kennenlernangebot: 

3 Ausgaben 

für nur 5,90 E 


www.android–user.de/miniabo 

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

Jails 

treiben. Dies trifft insbesondere auf NIS 

(Network Information Service) zu. Falls 

eine Benutzerverwaltung innerhalb einer 

Jail unbedingt erwünscht ist, dann muss 

der Systemadministrator entweder die 

»/etc/passwd« des Hostsystems in 

die Jail kopieren, oder aber er muss 

LDAP aufsetzen. Die Vorgehensweise 

bei LDAP ist die gleiche, wie bei der 

Installation auf einem Client-System. 

Zu beachten ist allerdings, dass in einer 

Jail keine User-IDs verwendet werden sollten, 

die auch auf dem Host angelegt sind. 

Der Grund ist einfach: Falls auf dem 

Host ein SSH-Dienst läuft, und sofern 

ein Benutzerkonto gehackt wurde, hat es 

der Angreifer leicht, sich auch auf dem 

Hostsystem einzuloggen und Schaden 

anzurichten. 

Daher gilt, dass man so wenig wie 

möglich Benutzerkonten einrichtet und 

gleiche Benutzernamen vermeidet. Bei 

Systemkonten und dem Root-User lässt 

sich das nicht vermeiden. In diesem 

Zusammenhang ist es außerordentlich 

wichtig, dass die Passwörter des Root- 

Users auf dem Host und in der Jail unterschiedlich 

sind! 

Fensterln mit Jails 

Jails lassen sich nicht nur für Sicherheitszwecke 

einsetzen, sie sind unter anderem 

auch ein gutes Mittel, um Schulungsumgebungen 

aufzubauen. Jeder Schulungsteilnehmer 

bekommt eine Jail, in der 

er seine Kurseinheiten absolviert. Auch 

grafische Benutzeroberflächen (GUI) auf 

X11-Basis lassen sich zu diesem Zweck in 

einer Jail installieren. Ein wichtiger Punkt 

ist hierbei, dass der Xserver nicht in einer 

Jail funktioniert, da dieser direkten 

Zugriff auf die Hardware verlangt. Aber 

dank des X11-Protokolls leitet man die 

Ausgabe beispielsweise auf einen Thin- 

Client um. Die Konfiguration ist nicht 

sonderlich schwer, hält aber einige Fallstricke 

bereit. Zunächst installiert man in 

der Jail die gewünschten X11-Applikationen 

entweder über den Ports-Tree oder 

mittels »pkg_add ‐r«. In beiden Fällen 

werden alle benötigten Bibliotheken und 

Programme automatisch mit installiert. 

Weiter wird das Programm »xauth« benötigt, 

um eine Authentifizierung zu ermöglichen. 

Zu finden ist es in »/usr/ 

ports/x11/xauth«. Im nächsten Schritt 

ändert man Einstellungen in »/etc/ssh/ 

sshd_config« des ssh-Daemons: »X11Forwarding 

yes« Damit werden alle X11-Protokoll-Tokens 

durch den SSH-Tunnel geleitet. 

An dieser Stelle ein wichtiger Hinweis: 

Die Namensauflösung muss einwandfrei 

funktionieren! Auf der Client-Seite müssen 

die Tools »xauth« und »xhost« ebenso 

wie ein Display-Manager (»xdm«, »gdm« 

oder »kdm«) nach Wahl installiert sein. 

Zunächst ergänzt man die Konfiguration 

des ssh-Clients um folgende Angaben: 

Host * 

ForwardAgent yes 

ForwardX11 yes 

XAuthLocation /usr/bin/xauth 

ForwardX11Trusted yes 

Ebenso teilt man dem Xserver des Clients 

mit, dass er Daten von den X11-Applikationen 

der Jail akzeptieren soll: 

Wichtige Flags für Jails 

Für Jails gibt es sechs MIBs (Management Information Base), die nur vom Hostsystem aus geändert werden dürfen, und zwei Parameter lassen sich vom 

Root-User innerhalb der Jail manipulieren. Die Flags werden mittels »sysctl« gesetzt: »sysctl ‐w $MIB=0 oder sysctl ‐w $MIB=1. Mit sysctl $MIB« lässt 

sich der aktuelle Status erfragen. Zuerst die MIBs, die vom Hostsystem geändert werden dürfen und sich auf alle Jails gleichermaßen auswirken: 

Bezeichnung der MIB Erklärung Standard Soll 

security.jail.set_hostname_allowed 

security.jail.socket_unixiproute_only 

security.jail.sysvipc_allowed 

security.jail.allow_raw_sockets 

security.jail.getfsstatroot_only 

security.jail.chflags_allowed 

Der root-User darf innerhalb einer Jail den Hostnamen mit hostname(1), sethostname(3) 

oder mit dem MIB kern.hostname ändern.Die Jail nutzt den Hostnamen, um 

mit dem Hauptsystem in Verbindung zu bleiben. Daher sollte dieser Parameter immer 

auf „0“ gesetzt sein. 

Diese MIB entscheidet, ob die Kommunikation der Jail über IP kommuniziert, oder 

über UNIX-Sockets. Letzteres ist als gefährlich einzustufen, da dies ein Loch in das 

Konzept reißen würde. 

Falls dieses Flag gesetzt ist, ist eine Kommunikation mit Prozesses außerhalb der Jail 

über mittels System V IPC (Interprocess communication) möglich. Es gibt Datenbanken, 

die ein gesetztes Flag unbedingt benötigen. Aber Vorsicht! 

Diese MIB erlaubt es, innerhalb einer Jail die sogenannten raw-sockets zu verwenden. 

Damit ist es unter anderem möglich, Tools wie ping(8) oder traceroute(8) zu verwenden. 

Es ist aber auch zu berücksichtigen, dass die raw-sockets auch vom Netzwerk- 

Subsystem verwendet werden! 

Damit lässt sich einstellen, ob User innerhalb einer Jail alle Mount-Points sehen können 

oder nicht. 

Diese MIB kontrolliert, ob ein privilegierter User, die File-Flags (chflags(8)) ändern 

darf, oder nicht. 

Innerhalb einer Jail dürfen zwei MIBs geändert werden, sofern dies erlaubt wurde! 

1 0 

1 1 

0 0 

0 0 

1 1 

0 0 

Bezeichnung des MIBs Erklärung Standard Soll 

kern.hostname 

Falls im Hostsystem security.jail.set_hostname_allowed = 1 ist, dann kann innerhalb 1 0 

der Jail der Jail-Hostname geändert werden. 

kern.securelevel Die Jail kann ebenso wie der Host mit verschiedenen Securelevels arbeiten. ‐1 


Jails 

Make- Parameter »TARGET=i386«. Die 

nächsten Schritte folgen dem weiter oben 

dargestellten Schema. 

Fazit 

Abbildung 4: Rechts ist die in einer Jail gestartete X11-Anwendung (xclock) auf einem Gnome3-Desktop zu 

sehen. Im linken Fenster das zugehörige SSH-Terminal. 

$ xhost + 

Wenn man sich anschließend mit »ssh 

user@x11jail X11‐Applikation« an der Jail 

anmeldet, so erscheint auf dem Desktop 

des Clients ein Fenster mit der in der 

Jail gestarteten X11-Anwendung. Siehe 

hierzu auch Abbildung 4. Darauf aufbauend 

lassen sich mit wenigen Handgriffen 

auch Linux-Applikationen in einer Jail 

betreiben. Interessant ist dies, wenn man 

Anwendungen hat, die bereits für Linux 

verfügbar sind, aber für FreeBSD noch 

nicht. Man macht sich zunutze, dass es 

für FreeBSD Bibliotheken gibt, die eine 

Linux-Kompatibilität herstellen. Dazu 

installiert man auf dem Host den Port 

linux_base: 

# cd /usr/ports/compat/linux_base 

# make install clean 

Anschließend mountet man das Verzeichnis 

mit den Bibliotheken in das Verzeichnis 

der Jail: 

# mount_nullfs /compat/ 

Pfad zur Jail/compat/ 

# mount ‐t linprocfs linprocfs 

Pfad zur Jail/compat/linux/proc 

Wichtig ist, dass man auch das Linux- 

Process-Filesystem mountet, weil die 

Linux-Prozessverwaltung in einem Dateisystem 

abgebildet wird. Damit nach einem 

Neustart der Mount erhalten bleibt, 

ergänzt man »/etc/fstab« des Hosts entsprechend 

um die folgenden jeweils in 

einer Zeile geschriebenen Einträge: 

Pfad zur Jail/compat/ U 

/compat nullfs rw 0 0 

linprocfs Pfad zur Jail/compat/U 

linux/proc linprocfs rw 0 0 

Weiterhin trägt man in die Systemkonfiguration 

»/etc/rc.conf« des Hosts 

und der Jail diese Zeile ein: »linux_ 

enable="YES"«. 

Zwei Welten, ein System 

Die im letzten Abschnitt gezeigten Beispiele 

lassen sich zu einer Art Virtualisierungslösung 

ausbauen. Das Jails-Konzept 

von FreeBSD bietet die Möglichkeit, auf 

64-Bit-Hosts Jails bereitzustellen, die 

32-Bit-Anwendungen ausführen. Die 

Vorgehensweise bei der Installation und 

Konfiguration ist bis auf kleine Unterschiede 

die gleiche: 

# setenv UNAME_m i386 

# setenv UNAME_p i386 

# cd /usr/src 

# make buildworld TARGET=i386 

# make installworld TARGET=i386 U 

DESTDIR=Pfad zur Jail 

# cd etc/ 

# make distribution DESTDIR=U 

Pfad zur Jail 

# mount ‐t devfs devfs U 

Pfad zur Jail/dev 

Zunächst werden die Umgebungsvariablen 

für die korrekte Ausgabe des Kommandos 

»uname« gesetzt. Nachdem in 

das Verzeichnis »/usr/src« gewechselt 

worden ist, kommen die Make-Aufrufe 

an die Reihe. Damit eine 32-Bit- 

Jail erstellt wird, verwendet man den 

Das Konzept der Jails unter FreeBSD 

ist nicht allein ein Sicherheitskonzept, 

sondern es stellt auch eine kleine 

Virtualisierungslösung dar. Dadurch 

bekommen nicht nur Administratoren in 

Rechenzentren ein mächtiges Werkzeug 

an die Hand. Auch Internet-Providern 

bietet sich hier die Chance, ihren Kunden 

Root-Shells zur Verfügung zu stellen und 

diese nutzen zu lassen. Die Sicherheit 

ist dabei bedingt durch das Konzept in 

vollem Umfang gewährleistet. 

Den Administratoren eines Heimnetzwerks 

bieten die Jails ebenfalls einen 

erheblichen Sicherheitsgewinn. Besonders, 

wenn sie nicht nur einen kleinen 

DNS-Dienst einsperren, sondern beispielsweise 

einen Webbrowser in einer 

Jail installieren. Alles in allem zeigt sich: 

Die Jails unter FreeBSD sind ein echtes 

Highlight und zugleich sehr vielseitig 

einsetzbar. (jcb) 

n 

Infos 

[1] J. Dankoweit: FreeBSD Installieren – Konfigurieren 

– Administrieren, (Hrsg.), C&L- 

Verlag 

[2] FreeBSD-Handbuch (online): [http:// www. 

freebsd. org/ doc/ de_DE. ISO8859‐1/ books/ 

handbook/ index. html] 

[3] Evi Nemeth et al.: UNIX-Systemverwaltung 

, Markt&Technik 

[4] Evan Sarmiento: The Jail Subsystem: 

[http:// www. freebsd. org/ doc/ en_US. 

ISO8859‐1/ books/ arch‐handbook/ jail. html] 

[5] Poul-Henning Kamp: Jails: Confining the 

omnipotent root 

[6] Kirk McKusik: The Design and Implementation 

of the FreeBSD Operating System, 

Chapter 4: The Jail Facility in FreeBSD 5.2 

[7] man-pages: jail(8), jexec(8), jls(8), 

killall(1), ipfw(8), ezjail-admin(1), mount_ 

nullfs(8) 

[8] Englischsprachiges BSD-Forum: [www. 

bsdforums. org] 

[9] Handbuch zum Paketfilter PF: [http:// 

www. openbsd. org/ faq/ pf/ de/ index. html] 

[10] ISC-DHCP-Daemon: [http:// www. isc. org/ 

index. pl] 

[11] Postfix-MTA: [www. postfix. org] 


Admin 


119

PKG-NG 

© Konstantin Semenov, 123RF 

Das neue Paketmanagement in FreeBSD 

Neubau 

Seit Langem warten die FreeBSD-Anwender auf eine Runderneuerung 

der in die Jahre gekommenen Paketverwaltung. Im Oktober wurde in 

CURRENT mit PKG-NG ein radikaler Schnitt gemacht – bei den Binärpaketen 

wird vieles anders und manches besser. Jörg Braun, Rosa Riebl 

des Systems und zum Umgang damit, 

auch mit Seitenblicken auf OpenBSD und 

NetBSD finden sich etwa [1]. 

Das Paketsystem aller drei BSD-Systeme 

legt zur Verwaltung einen Verzeichnisbaum 

in »/var/db/pkg/« an. Es ist eine 

rein verzeichnisbasierte Datenbank, in 

der jedes Softwarepaket ein Unterverzeichnis 

mit genau seinem Namen und 

der vollen Versionsnummer erhält. In diesem 

Verzeichnis befinden sich eine Reihe 

Text-Steuerdateien. 

Anders als bei Windows und Mac OS 

X, bei denen jeder Softwarehersteller für 

die Installation und Deinstallation seiner 

Anwendung selbst verantwortlich 

ist, kümmern sich die Unix-artigen Betriebssysteme 

selbst um die verfügbaren 

Programme. Bei Linux sind die Distributoren, 

bei BSD die Projekte für die 

hier enthaltenen Daten zuständig. Der 

Linux-Anwender (außer er arbeitet mit 

Gentoo) wählt normalerweise die Binärdateien 

der Programme als RPM- oder 

Deb-Dateien in einem Frontend, und die 

Softwareverwaltung macht den Rest. Das 

alles geht schnell, ist aber wenig flexibel, 

weil alle Programme mit Voreinstellungen 

vorkompiliert sind. 

Bei BSD ist das ganz anders. Der erfahrene 

Administrator installiert im Regelfall 

Programme exakt angepasst aus 

deren Quellen. Dieses Verfahren ist bei 

FreeBSD, NetBSD und OpenBSD fast 

identisch, auch wenn dies bei NetBSD 

Package Sources und bei den anderen 

beiden Betriebssystemen Ports heißt. Das 

Einspielen von Programmen auf diese 

Weise ist sehr langwierig. Wer zu schnelleren 

Ergebnissen kommen will, kann 

die Programme – dann nur mit den Standardvorgaben 

– mit den Kommandozeilenprogrammen 

»pkg_add« installieren, 

mit »pkg_delete« deinstallieren und sich 

weiterhin mit »pkg_info« Basisinformationen 

zu den installierten Paketen anzeigen 

lassen. 

Es gibt noch einige weitere Hilfsprogramme, 

die aber für die meisten Anwender 

nicht von Bedeutung sind. Diese Programme 

gibt es bei allen BSD-Betriebssystemen, 

die das Paketsystem vor Jahren 

von FreeBSD übernommen hatten. Ausführliche 

Beschreibungen zum Aufbau 

Überarbeitet 

Im Oktober 2012 wurde diese Softwareverwaltung 

bei FreeBSD CURRENT 

durch einen PKG NG genannten Nachfolger 

abgelöst. Das Absonderliche ist 

nicht, dass endlich die Paketverwaltung 

modernisiert wird, sondern dass sich 

»pkg« gar nicht im Lieferumfang von 

FreeBSD befindet. Ruft man nach der Installation 

das Programm auf, wird nur die 

Meldung angezeigt, dass das Programm 

installiert werden sollte, es befindet sich 

nämlich in den Ports und muss erst gebootstrappt 

werden. Selbst wenn man 

ein Paket des Programms »pkg« vorliegen 

hat, nützt das aber nichts – »pkg« 

ist ja nicht installiert. Diesen Konflikt 

versucht FreeBSD über einen Download 

des Binaries zu lösen, was bei diversen 

Versuchen fehlschlug. 


PKG-NG 

Da das Paket in den Ports vorhanden 

ist, reicht alternativ ein »cd /usr/ports/ 

ports‐mgmt/pkg ; make install clean«, 

um anschließend mit dem Programm arbeiten 

zu können. Vertrauenerweckend 

erscheint diese Einführung der neuen 

Paketverwaltung jedoch nicht. Immerhin 

weist sie bei der Installation darauf hin, 

dass der Aufruf von »pkg2ng« eine alte 

Paketdatenbank in das neue Format umzieht. 

Er ist aber nur dann nötig, wenn 

man »pkg‐ng« bei einer älteren FreeBSD- 

Version nutzen möchte, bei der schon 

Programme installiert wurden, möglich 

ist das ab FreeBSD 8. 

Zweiteilung 

»pkg‐ng« besteht aus zwei Programmen, 

die in »/usr/local/sbin« abgelegt werden 

und »pkg« und »pkg‐static« heißen. Nach 

der Installation sollte man Letzteres an 

einen sicheren Ort wie beispielsweise »/ 

usr/sbin« kopieren. Weiterhin elementar 

ist die Konfiguration 

»/usr/local/ 

etc/pkg.conf«. 

Diese Datei gibt 

es nach der Installation 

aber nicht, 

das in »/usr/local/ 

etc« abgelegte Template »pkg.conf.sample« 

muss erst wahlweise umbenannt 

oder umkopiert werden. Der auffälligste 

Unterschied zum alten Paketsystem ist 

aber, dass man nicht mehr einfach Namen 

und Version eines installierten Paketes 

durch ein »ls« nach »/var/db/pkg« 

ermitteln kann. Die Zeiten, in denen mit 

den Standardwerkzeugen des Betriebssystems 

nach Daten forschen und man 

über das Editieren einer Datei einen kleineren 

Tweak durchführen konnte, sind 

vorbei. Der Entwickler von »pkg« hat sich 

der auch schon anderweitig bei freien 

Unix-Systemen um sich greifende Unsitte 

angeschlossen und schreibt die Daten in 

eine SQLite-Datei. 

Abbildung 1: Die herkömmlichen Paketverwaltungsprogramme weisen bei 

FreeBSD CURRENT auf das neue Programm hin. 

Nach der Installation ändert sich aber 

sonst bei der Installation eines Paketes 

erst einmal nicht sehr viel. Liegt die Paketdatei 

lokal vor, ruft man anstelle von 

»pkg_add« jetzt nur »pkg add« ohne den 

Unterstrich auf. Möchte man Anwendungen 

aus dem Internet installieren, heißt 

es jetzt nicht mehr »pkg_add ‐r«, sondern 

»pkg install«. Gelöscht werden die Daten 

mit »pkg delete«. Tabula rasa mit »pkg 

delete ‐a« geht aber nicht, der Anwender 

muss jetzt mit »‐af« das Löschen erzwingen. 

Hier zeigt sich auch die Tücke des 

Objekts und warum man »pkg‐static« in 

Sicherheit bringen muss: Das Paketverwaltungsprogramm 

wird als Paket aus 

den Ports gleich mitgelöscht und muss 



Online-Archiv 

Rund 2.000 Seiten Artikel, 

Studien und Workshops aus 

fünf Jahren Technical Review 

+ 

nur 

4,-e* 

im Monat 

Onlinezugriff auf 

Heftartikel aus dem 

ADMIN-Magazin von 

2009 bis 2012! 

Volltextsuche 

Praxisrelevante Themen 

für alle IT-Administratoren 

* Angebot gültig nur 

für Abonnenten eines 

Print- oder vollen 

digitalen ADMIN Abos 


Admin 


Bestellen Sie unter: www.admin-magazin.de/archiv 

121

PKG-NG 

vor der Installation neuer Pakete erst wieder 

installiert werden. 

Nicht perfekt 

Da »ls /var/db/pkg« keinen Nutzen mehr 

bringt, müssen die Daten zur Installation 

beim neuen Paketsystem jetzt mit 

»pkg info« und »pkg query« abgefragt 

werden. Hier zeigt sich leider eine der 

großen Schwächen des Paketsystems von 

FreeBSD, offensichtlich kennt man die 

viel intelligenteren Anwendungen des 

Package-Source-Systems von NetBSD 

nicht, die auch Wildcards in den Paketnamen 

erkennen und intelligent ergänzen. 

Die in dieser Hinsicht absolute tumbe 

Paketverwaltung von FreeBSD versteht 

zwar noch ein »pkg info xorg« und gibt 

die Versionsnummer und die einzeilige 

Beschreibung aus, um aber zu erfahren, 

Tabelle 1: Paket-Befehle 

Steueranweisung 

add 

audit 

autoremove 

backup 

check 

clean 

create 

delete, remove 

fetch 

help 

info 

install 

query 

register 

repo 

rquery 

search 

set 

shell 

shlib 

stats 

update, upgrade 

updating 

version 

which 

welche X-Treiber installiert sind, hilft 

kein »pkg info xf86‐drivers«. Hier muss 

man das »pkg info ‐a xorg« mit »more« 

oder »less« anzeigen oder die Ausgabe 

des Befehls mit »grep xf86« durchsuchen, 

um eine Liste der Treiber zu sehen. 

Die Entwickler des Programms »pkg« heben 

hervor, dass man mit ihm in einer 

Chroot-Umgebung oder gar einem Jail 

arbeiten kann. Man konnte vorher zwar 

auch in lokalen Umgebungen Pakete 

installieren, es war aber nicht so elegant. 

Ein Fortschritt gegenüber dem alten Paketsystem 

ist aber, dass mit »pkg update« 

und »pkg upgrade« die lokale Repository- 

Datenbank und derzeit wenigstens in 

Teilen auch die installierten Programme 

schnell und bequem auf einen aktuellen 

Stand gehoben werden können. Linux- 

Anwender können über die bisherigen 

mühseligen Aktualisierungsversuche mit 

Aufgabe 

Installiert ein Paket im System. 

Meldet sicherheitskritische Pakete. 

Löscht überflüssige verwaiste Abhängigkeiten. 

Sichert und restauriert die lokale Paketdatenbank. 

Prüft die Paketverwaltung. 

Löscht alte Pakete aus dem Cache. 

Legt Distributionspakete an. 

Löscht Pakete vom System und aus der lokalen Datenbank. Die Aufrufe sind 

synonym. 

Holt Pakete aus dem Remote-Repository. 

Anzeigen der Hilfe des Programms. 

Gibt Informationen zu installierten Paketen oder zu Paketdateien aus. 

Installiert Pakete aus dem Remote-Repository. 

Zeigt Informationen zu einem installierten Paket an. Dem Befehl muss ein 

recht komplizierter Formatstring übergeben werden, seine zahlreichen Optionen 

verrät die Manpage pkg-query. 

Meldet ein Paket in der lokalen Datenbank an. 

Schreibt einen Paketkatalog. 

Ruft Informationen in Repository-Katalogen ab. 

Durchsucht den Katalog eines Repositories. 

Ändert Paketinformationen in der lokalen Datenbank. 

Öffnet eine Debug-Shell. 

Zeigt an, welches Paket eine bestimmte Bibliothek benötigt. 

Anzeigen der Datenbankstatistik. 

Aktualisiert den Paketkatalog und bei Bedarf auch die lokalen Pakete nach 

dem Alles-oder-nichts-Prinzip. Einzelpakete lassen sich nicht austauschen. Die 

beiden Aufrufe sind ähnlich aber nicht synonym! 

Zeigt die Aktualisierungsinformationen zu einem Paket an. 

Zeigt die Versionsnummern aller installierten Programmpakete an. Dabei wird 

mitgeteilt, ob das Programm auf den aktuellen Stand ist oder nicht, was aber 

nicht bedeutet, dass alle veralteten Pakete anschließend mit »pkg update« 

ersetzt werden können. 

Informiert, welches Paket eine bestimmte Datei installiert hat. 

»portupgrade« nur mitleidig lächeln. Eine 

Paketaktualisierung dauerte damit ein 

Mehrfaches der Zeit, die das komplette 

Löschen und Neuinstallieren gedauert 

hat. Eine Liste der verfügbaren Befehle 

von »pkg« zeigt Tabelle 1. Sie alle erhalten 

noch zusätzliche Schalter, die in den 

Manpages zu »pkg‐Befehl« nachzulesen 

sind. 

Fazit 

FreeBSD hat sich mit der neuen Paketverwaltung 

einen radikalen Schnitt vollzogen. 

Dass die Verwaltungssoftware nicht 

im Basissystem enthalten ist, überrascht 

und ist wenig sinnvoll. Vielleicht möchte 

man aber auch erst die Reaktionen der 

Anwender testen, bevor man »pkg‐ng« 

vom Current in den Release-Zweig 

schiebt. Wem das Ganze zu suspekt erscheint, 

kann deshalb auch unter CUR- 

RENT darauf verzichten. Das gelingt mit 

der Variablen »WITH_PKGNG=YES« in 

der Datei »/etc/make.conf«. 

Nur dann werden selbst kompilierte Anwendungen 

nicht im neuen Txz-, sondern 

im gewohnten Tbz-Format und mit 

dem alten Paketinhalt geschrieben. Hier 

liegt auch der größte Nachteil der neuen 

Pakete, nämlich dass sie nicht mehr kompatibel 

sind. Deshalb findet »pkg_add 

‐r« bei FreeBSD 10 auch keine Pakete 

mehr im Internet, und der Mutige, der 

unter FreeBSD 8 oder 9 »pkg‐ng« testen 

will, muss ebenfalls auf die bequeme 

und vor allem schnelle Installation der 

Programme direkt vom FreeBSD-Server 

verzichten. 

Mit dem Abschied von »sysinstall« und 

der darin enthaltenen und schon lange 

nicht mehr gepflegten Softwareverwaltung 

ist der Schritt zu etwas ganz Neuem 

aber nur konsequent. Fragt sich nur, ob 

die FreeBSD-Entwickler dieses Mal etwas 

Neues nicht nur grob zusammenschustern 

und dann die Anwender damit weghumpeln 

lassen, wie es zuletzt bei dem 

jämmerlichen BSD-Installer in FreeBSD 9 

der Fall ist, oder ob sie wenigstens diese 

Baustelle komplett bis zum Ende fertigstellen. 

Es wäre wünschenswert. (ofr) n 

Infos 

[1] Jürgen Dankoweit (Hrsg.): FreeBSD. C&L- 

Verlag 2009, ISBN 978-3-936546-41-5./ 


Das Magazin für die 

mobile Windows-Welt 

Digitales Abo: nur 19,90 * Euro (6 PDFs) 

NEU! 

Ihre Vorteile: 

Lesen Sie News und Artikel 

schon 1 Woche vor dem 

Kiosk-Termin! 

Hardware und App-Tests, 

Workshops, Tipps und Tricks 

für Anfänger und Profis! 

Nutzbar auf Smartphone, 

Tablet oder Notebook/PC! 


windows-phone-user.de/digisub 

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

* Abopreis gilt für 1 Jahr, das Angebot gilt innerhalb Deutschlands.

FreeBSD und KVM 

© Andrey Bourdioukov, 123RF 

FreeBSD und KVM-Virtualisierung 

Hochzeit 

Die KVM-basierte FOSS-Cloud ist eine Alternative zu teuren kommerziellen 

zentralen Virtualisierungslösungen für Windows- und Linux-Gäste. Mit 

einigen kleineren Vorarbeiten lassen sich damit auch FreeBSD-Server virtualisieren. 

Dieser Workshop beschreibt genau, wie es geht. Jörg Braun, Rosa Riebl 

Der FreeBSD-Kernel ist wie der Linux- 

Kernel modular, das heißt, Hardware- 

Treiber können in Form von Kernelmodulen 

nachgeladen werden. Das Problem 

bei FreeBSD 8 und 9 ist aber, dass die 

Virtio-Treiber nicht zum Standard-Lieferumfang 

gehören, sondern in den Ports 

enthalten sind. Erst bei FreeBSD 10, der 

aktuellen CURRENT-Version, sind sie im 

Standard-Repertoire enthalten. 

Selbst gemeistert 

In der Ausgabe 5/2012 der FreeX wurde 

ausführlich das Konzept der FOSS-Cloud 

[1] als rein opensource-basierte Virtualisierungslösung 

beschrieben [2]. Selbst 

Windows-XP-Gäste lassen sich auf dem 

KVM-basierten Server installieren, wenn 

solche Desktops im Netz verteilt werden 

sollen [3]. 

Die FOSS-Cloud sieht als Gäste eigentlich 

nur Windows und Linux-Distributionen 

vor, und Stellschrauben für die 

Anpassung gibt es dabei praktisch keine. 

Stattdessen wird erwartet, dass der Gast 

die Festplatte, das Netzwerk und den 

Speicher paravirtualisiert mit den zugehörigen 

Virtio-Treibern zugewiesen bekommt. 

Diese Virtio-Treiber gibt es auch 

für FreeBSD ab Version 8, weshalb es 

machbar erscheint, es ebenfalls mit KVM 

in der FOSS-Cloud zu virtualisieren. 

Treiber verlangt 

Die Installation eines Betriebssystems auf 

dem Datenträger ist nur möglich, wenn 

die notwendigen Festplattentreiber geladen 

sind. Das ist bei FreeBSD bei SCSI-, 

IDE- und SATA-Platten der Fall [4], und 

damit ist die Installation des Betriebssystems 

bei allen Virtualisierungslösungen 

möglich, die diese Datenträger emulieren. 

KVM mit seinen paravirtualisierten 

Geräten besitzt jedoch die speziellen Virtio-Devices, 

die bei der Betriebssysteminstallation 

nur dann akzeptiert werden, 

wenn die richtigen Treiber geladen sind. 

Um das Betriebssystem überhaupt installieren 

zu können, muss deshalb ein 

neuer Installations-Datenträger zusammengestellt 

werden. Dies ist prinzipiell 

sehr einfach, Voraussetzung ist, dass 

man genau die richtigen VirtIO-Treiber 

für den gewünschten Installations-Datenträger 

besitzt. Es ist nicht möglich, 

die Treiber beispielsweise unter FreeBSD 

9-STABLE für den Installationskernel eines 

FreeBSD-9.0-RELEASE zu kompilieren, 

die Dateien werden beim Booten von 

der CD abgelehnt und nicht geladen. 

Da die Installation von 8.x, 9.x und 

CURRENT in der FOSS-Cloud aber unterschiedliche 

Arbeitsvorbereitungen und 

‐abläufe verlangen, sind hier alle drei Betriebssystemvarianten 

berücksichtigt. 



Paravirtualisierung mit KVM 

Die Beschreibungen hier beziehen sich zwar 

auf die FOSS-Cloud. Die Treiberproblematik 

und die Lösungen gelten aber immer, wenn 

FreeBSD in KVM-basierten Umgebungen installiert 

werden soll, bei denen die Standard- 

Festplatten- und ‐Netzwerkkartenemulationen 

nicht verfügbar sind. 

FreeBSD, KVM und die Maus 

Mit der hier nachzulesenden Beschreibung 

kann derzeit nur ein Server beziehungsweise 

ein konsolenorientiertes FreeBSD installiert 

werden. Die X-Oberfläche funktioniert nicht, 

weil die Maus nicht richtig initialisiert wird. 

Beim Booten wird richtigerweise ein USB-Gerät 

mit dem Namen »QEMU 1.0 QEMU USB Tablet, 

class 0/0, rev 1.00/0.0, addr 2« als »/dev/hid0« 

angelegt, und dieses Gerät reagiert auch im 

Test mit »usbhidctl ‐f /dev/uhid0 ‐l ‐a« richtig, 

es gibt aber kein Maus-Device »/dev/ums0« für 

die USB-Maus. Der Autor hat leider keinen Weg 

gefunden, diesen Fehler zu korrigieren. Falls 

jemand die Lösung kennt, wird er/sie hiermit 

gebeten, sie der ADMIN-Redaktion zukommen 

zu lassen. 

Da ohnehin die Original-CD von FreeBSD 

oder deren ISO-Image benötigt wird, bietet 

es sich an, falls kein FreeBSD auf echter 

Hardware installiert ist, die Vorarbeiten 

in einer lokalen virtuellen Maschine 

auszuführen. Die 32- und die 64-Bit-Version 

von FreeBSD lassen sich problemlos 

mit VMware Workstation, Parallels 

Workstation und Oracle Virtualbox [5] 

virtualisieren. 

Für eine saubere Installation sollte man 

am besten mit der Release-Version einer 

aktuellen Version von FreeBSD 8 oder 

9 arbeiten. Der Kernel des installierten 

Betriebssystems darf gegenüber dem 

auf der CD/DVD nicht aktualisiert sein. 

Bei FreeBSD 8 ist die DVD für die FOSS- 

Cloud nötig, bei FreeBSD 9 reicht eine 

Installations-CD. Alle Arbeiten sind bei 

der 32- und der 64-Bit-Version identisch. 

Es ist außerdem nicht sinnvoll, ein älteres 

FreeBSD 9.0 zu verwenden, weil sich 

hier der Pfad der Treiber zwischenzeitlich 

geändert hat, was bei der Installation zu 

Irritationen führen könnte. 

Die Ports können aktualisiert sein, es ist 

aber nicht unbedingt nötig. Möchte man 

sie auf den neuesten Stand bringen (zu 

empfehlen nur bei einem Release, das älter 

ist als ein halbes Jahr), geschieht das 

am einfachsten mit Root-Rechten auf der 

Kommandozeile mit dem Aufruf »portsnap 

fetch extract«. Dazu muss das System 

natürlich auf das Internet zugreifen können. 

Auch alle weiteren hier geschilderten 

Arbeiten setzten Administratorrechte 

voraus. 

Gut angepasst 

Regulär legt man einen neuen Distributionsdatenträger 

über die Quellen an. Bei 

FreeBSD 8 und 9 ist das nicht nötig. Man 

kann auch aus der originalen CD oder 

DVD eine angepasste anlegen, was sehr 

viel schneller geht. Dazu muss zuerst die 

Original-Installations-CD eingebunden 

werden. Das geschieht nach dem Einlegen 

des Datenträgers oder dem Anbinden 

der CD oder des ISO-Images in einer Virtualisierungslösung 

mit dem Aufruf 

mkdir /cdrom 

mount ‐t cd9660 /dev/cd0 /cdrom 

Das Schreiben eines neuen ISO-Images 

erfordert ein Mastering-Verzeichnis, das 

nach dem Abschluss der Arbeiten wieder 

komplett entfernt werden kann. Weiterhin 

bietet es sich an, die Dateien aus 

Gründen der Bequemlichkeit mit dem 

Midnight Commander (»mc«) anstatt mit 

»cp« zu kopieren. Für das Schreiben des 

ISO-Images ist weiterhin »mkisofs« aus 

den CDR-Tools nötig; um Platz im ISO- 

Image zu sparen, das Programm »dupmerge« 

[6], das sich ebenfalls in den 

Ports befindet. Es lohnt sich nicht, diese 

Programme aus den Quelltexten zu installieren, 

das Einspielen aller benötigten 

Daten direkt vom FreeBSD-FTP-Server 

übernimmt: 

pkg_add ‐r mc dupmerge cdrtools virtio‐kmod 

Ist das eine oder andere Programm bereits 

installiert, stört das nicht weiter, 

seine Installation wird dann einfach 

übergangen. Können die Treiber nicht auf 

dem Server gefunden werden, muss man 

sie selbst kompilieren. Danach kann mit 

Virtio-Treiber aus dem Port 

Die Virtio-Treiber sind nicht unbedingt bei jeder 

FreeBSD-Unterversion vorkompiliert verfügbar. 

Schlägt der Aufruf von »pkg_add ‐r virtio‐kmod« 

für ihre Installation fehl, muss man den Port aus 

den Quellen installieren. Das ist nur möglich, 

wenn auch die Betriebssystemquellen installiert 

sind. 

Um den Port zu kompilieren, muss man in »/ 

usr/ports/emulators/virtio‐kmod« den Befehl 

»make package« aufrufen. Dieser Hinweis gilt 

nicht bei FreeBSD-CURRENT, hier sind die Treiber 

im Standardumfang des Kernels enthalten. 

Zuerst werden je ein Mastering-Verzeichnis und 

eines für den Baum mit den Daten der neuen 

dem Mastern der neuen Installations-CD 

oder ‐DVD begonnen werden. 

Der Parameter »‐p« von »mkdir« legt den 

gesamten Pfad in einem Rutsch an, das 

»‐Rvp« von »cp« bedeutet, dass alle Daten 

rekursiv kopiert werden, dabei das 

Programm gesprächig ist und alle aktuellen 

Rechte beibehält. Wer es bequemer 

will, kopiert die Daten mit dem Midnight 

Commander, übergeht dabei aber das 

Verzeichnis ».rr_moved«. 

Treiber kopieren 

Im nächsten Schritt müssen die zuvor 

installierten VirtIO-Treiber ebenfalls in 

das Mastering-Verzeichnis übertragen 

werden. Sie befinden sich in »/boot/modules«: 

cp /boot/modules/virt*ko U 

/usr/tree/boot/modules 

cp /boot/modules/if_vtnet*ko U 

/usr/tree/boot/modules 

cd /usr/tree/boot/modules 

kldxref 

Nun muss die Datei »/usr/tree/boot/loader.conf« 

angepasst werden. Sie legt fest, 

welche externen Gerätetreiber der Kernel 

zusätzlich lädt. In der FreeBSD-Version 9 

gibt es diese Datei noch nicht. Sie muss 

nach dem Editieren, zum Beispiel mit 

dem Befehl »ee /usr/tree/boot/loader. 

FreeBSD-Installations-CD angelegt, wobei auf 

ausreichend freien Platz im Verzeichnis zu 

achten ist (bei FreeBSD 9 mit CD knapp 1,5 

GByte, bei der DVD-Version insgesamt etwa 4,5 

GByte): 

mkdir ‐p /usr/cd/tree 

cd /usr/tree 

chmod 777 /usr/tree 

cp ‐Rvp /cdrom/* . 

cp ‐p /cdrom/.cshrc* . 

cp ‐p /cdrom/.profile* . 

Die Angabe des Basisverzeichnisses hier ist nur 

ein Vorschlag. 


Admin 


125


Abbildung 1: Alle Treiber wurden wie gewünscht beim Systemstart geladen. 

Außer den Virtio-Treibern sind dies auch noch die Module für die Linux- 

Emulation. 

Abbildung 2: Die Aufteilung der virtuellen Festplatte mit einem klassischen 

Master Boot Record in FreeBSD 9. Neben der Root-Partition gibt es noch eine 

Partition für Swap und eine separate Usr-Partition. 

conf«, die folgenden Konfigurationszeilen 

enthalten: 

virtio_load="YES" 

virtio_pci_load="YES" 

virtio_blk_load="YES" 

if_vtnet_load="YES" 

virtio_balloon_load="YES" 

Ohne diese Daten ist die Installation zwar 

auch möglich, aber extrem umständlich. 

Der Installationsdatenträger von FreeBSD 

8 und 9 unterscheidet sich an dieser Stelle 

übrigens drastisch. Bis inklusive FreeBSD 

8 wird nämlich in eine RAM-Disk gebootet, 

die von einer Zeile in »loader.conf« 

eingeschaltet wird, sodass die Datei am 

Schluss so aussehen sollte: 

mfsroot_load="YES" 

mfsroot_type="mfs_root" 

mfsroot_name="/boot/mfsroot" 




virtio_blk_load="YES" 


Von dem so vorbereiteten Datenträger 

kann das FreeBSD-System bereits erfolgreich 

installiert werden. Besser ist es, außerdem 

den Virtio-Port auf dem Datenträger 

abzulegen. Falls man ihn kompiliert 

hat, ist das kein Problem, er befindet 

sich entweder in »/usr/ports/packages/ 

All« oder, falls »/usr/ports/packages« 

nicht vorhanden ist, im Verzeichnis »/ 

usr/ports/emulators/virtio‐kmod« als Archiv 

mit der Endung ».tbz«. Diese Datei 

sollte man in ein Verzeichnis »packages/ 

All« auf den Master kopieren. 

Im vorletzten Arbeitsschritt muss jetzt 

der Master von Dateiduplikaten befreit 

werden. Der Grund ist, dass beim ursprünglichen 

Kopieren der ISO-Datei 

Links aufgelöst und durch Einzeldateien 

im Verzeichnis »tree« ersetzt wurden. 

Brennt man einen neuen Master ohne 

dies zu berücksichtigen, wird er erheblich 

größer als sein Original. Wieder zu 

Links werden die jetzigen Dateien durch 

einen Aufruf von des Filters »dupmerge«. 

Die Syntax des Aufrufs erfährt man mit 

»dupmerge ‐h«. Sie lautet hier 

cd /usr/cd/tree 

find ./ ‐type f ‐print0 | dupmerge 

Dies spart etwa 200 000 Blöcke zu je 

512 Byte auf dem Datenträger und damit 

nicht ganz 100 MByte. Im letzten Arbeitsschritt 

wird das ISO-Image gebrannt: 

cd /usr/cd 

mkisofs ‐R ‐J ‐no‐emul‐boot ‐c boot/.catalog U 

‐hide‐rr‐moved ‐b boot/cdboot ‐V "FREEBSD_U 

INSTALL" ‐o fbsd91‐foss.iso tree/ 

chmod 666 fbsd91‐foss.iso 

Die Angaben »‐R« und »‐J« legen lange 

Dateinamen nach der Unix- (Rockridge) 

und Windows-Konvention (Joliet) fest, 

die weiteren Parameter werden für das 

Bootsystem gebraucht. Sehr wichtig ist 

ab FreeBSD 9.0 die Bezeichnung »‐V 

"FREEBSD_INSTALL"«, über die das 

Installationssystem den Datenträger identifiziert. 

Für alle lesbar 

Die Rechtevergabe zum Schluss soll sicherstellen, 

dass das Image von jedem 

beliebigen Benutzerkonto aus auf den 

Server mit der FOSS-Cloud-Installation 

übertragen und auch gelöscht werden 

kann. Außerdem werden die Attribute bei 

der Übertragung auf dem Server angeglichen, 

und die Datei ist nur so in der FOSS- 

Cloud nutzbar. Anschließend kopiert der 

folgende Befehl das ISO-Image per »scp« 

auf den Server der FOSS-Cloud: 

scp fbsd9‐foss.iso root@192.168.0.8:U 

/var/virtualization/iso‐choosable/ 

Hier ist natürlich die richtige IP-Adresse 

des Servers anzugeben. »scp« ist im Standardumfang 

von FreeBSD enthalten. 

FreeBSD 9 

Die Installation von FreeBSD in einem 

FOSS-Cloud-Template gelingt mit dem 

angepassten Image bei FreeBSD 9 in einem 

Schritt, bei FreeBSD 8 muss zwischenzeitlich 

noch ein zweites Mal von 

der DVD gebootet werden. Für FreeBSD 

wird im Webfrontend der FOSS-Cloud, 

die nur Linux und Windows kennt, je 

nach Bedarf eine 32- oder 64-Bit-Linux- 

Installation gewählt, dieser das Image 

zugewiesen und dann gebootet. 

Die FreeBSD-Installation braucht hier 

nicht in aller Ausführlichkeit geschildert 

zu werden. Wichtig ist nur, beim Booten 

der CD die Virtio-Treiber zu laden. Man 

sieht den Ladevorgang bereits beim Booten 

des Kernels, muss dafür aber zu diesem 

Zeitpunkt schon ein SPICE-Fenster 

geöffnet haben. Man kann sich aber auch 

später davon überzeugen, wenn man im 

ersten Fenster der Setuproutine nicht 

zur Installation weitergeht, sondern eine 

Shell öffnet und hier den Befehl »kldstat« 

aufruft. 

Achtung: In dieser Shell ist bei FreeBSD 

9.0/9.1 noch keine deutsche Tastaturbelegung 

eingeschaltet, sodass der Slash (/ 

) auf der deutschen Tastatur mit dem [-] 



zu erreichen ist. Für den Unterstrich (_) 

ist [ß] zu drücken (Abbildung 1). Wird 

hier nur die Datei »kernel« angezeigt, 

stellt sich die Frage, warum die Treiber 

nicht eingebunden wurden. Mögliche 

Gründe können Tippfehler in der »/boot/ 

loader.conf« oder nicht zum Kernel passende 

Module sein. Im ersten Fall muss 

man die Treiber manuell mit »kldload« 

nachladen, im zweiten Fall einen neuen 

Installa tionsdatenträger mit den richtigen 

Dateien schreiben. 

Virtuell installiert 

Die Installation selbst unterscheidet sich 

kaum von der auf echter Hardware und 

in anderen Virtualisierungslösungen, 

nur dass hier die Festplatte die Kennung 

»vtdb« anstelle des gewohnten »ad« beziehungsweise 

»da« besitzt und die Netzwerkkarte 

den Namen »vtnet0« trägt. Ob 

man bei der Festplattenaufteilung GPT 

oder MBR nutzt, ist Geschmackssache 

In der Weboberfläche stellt man jetzt 

die Bootreihenfolge um und startet das 

FreeBSD-Template für die weitere Anpassung 

des Betriebssystems neu von Festplatte. 

Anschließend sollte der Virtio-Port 

installiert werden, damit die Zusatztreiber 

bei der Softwareverwaltung angemeldet 

sind. Man darf allerdings dann die 

Ports jedoch auf keinen Fall mehr mit der 

Kommandozeilenanweisung »pkg_delete 

‐a« vollständig für eine Neuinstallation 

löschen und dann neu booten, weil das 

System ohne die Treiber nicht mehr von 

der virtuellen Festplatte startet. 

Anders als bei FreeBSD 9 muss man 

FreeBSD 8 zweimal von der Installationsund 

für den Betrieb unwichtig (Abbildung 

2). 

Sind die virtuelle Festplatte strukturiert, 

das Netzwerk eingerichtet und 

alle restlichen Einstellungen getroffen, 

unterscheiden sich die weiteren Schritte 

bei FreeBSD 8 und 9, denn im letzten 

Schritt muss unbedingt eine »loader.conf« 

in der Installation abgelegt werden. Bei 

FreeBSD 9 geht das ohne vorherigen Neustart, 

wenn man nach dem Abschluss der 

Installation direkt eine Shell öffnet (siehe 

auch Abbilundg 5). Hier gibt man die 

beiden Befehle 

umount /mnt/usr 

umount ‐f /mnt 

ein. Damit wird die aktuell nicht bearbeitbare 

Festplatte gewaltsam ausgehängt. 

Die Shell springt nach dieser groben Aktion 

sofort wieder in das Installationsskript 

zurück, das jetzt das Live-System 

startet. In ihm wird das Hauptverzeichnis 

der Festplatte gemountet, dann die 

Treiber und die Konfigurationsdatei auf 

die Festplatte kopiert und die Installation 

von FreeBSD endgültig abgeschlossen. 

Abbildung 3 zeigt dies bei einer MBR- 

Installation. 

Anders booten 

Linux-Magazin 

ACADEMY 

Online-Training 

IT-Sicherheit Grundlagen 

mit Tobias Eggendorfer 

Themen (Auszug): 

❚ physikalische Sicherheit 

❚ Sicherheitskonzepte 

❚ Sicherheitsprüfung 

❚ logische Sicherheit 

• Betriebssystem 

• Netzwerk 

Deckt in Teilbereichen auch das Prüfungswissen für LPIC-303-Inhalte ab. 

Inklusive Benutzer- und Rechteverwaltung, Authentifizierung, ACLs sowie 

wichtige Netzwerkprotokolle und mehr! 

Das Grundlagentraining für IT-Sicherheit richtet sich an Systemadministratoren 

und solche, die es werden wollen ebenso wie an ambitionierte Heimanwender. 

Nur 299 Euro inkl. 19 % MwSt. 

@Kirsty Pargeter, 123RF 

20% 

Treue-Rabatt für 

Abonnenten 

Informationen und Anmeldung unter: 


Admin 


academy.linux-magazin.de/sicherheit 

127


Abbildung 3: Die Treiberdateien und die »/boot/loader.conf« werden von der 

Installations-CD auf die virtuelle Platte übertragen. 

Abbildung 4: Die Bestätigung, dass die Installation beendet ist. Hier muss 

mit YES eine Konsole geöffnet werden, dann werden »/mnt/usr« und »/mnt« 

ausgehängt, worauf sich automatisch die Konsole in Abbildung 6 öffnet. Dies 

sieht bei FreeBSD 9 und bei FreeBSD 10 genau gleich aus. 

DVD starten. Da ein Live-System benötigt 

wird, mit dem die Zusatzdateien auf die 

Festplatte kopiert werden, setzt die Installation 

die Installations-DVD voraus, was 

aber außer wegen des erhöhten Platzbedarfs 

keine besondere Rolle spielt. Die 

eigentliche Installation läuft auch hier, 

wenn die Treiber vom Kernel akzeptiert 

werden, ganz normal ab. Die Gerätenamen 

sind dieselben wie bei FreeBSD 9. 

Geplanter Fehler 

Ist die Installation erfolgreich abgeschlossen, 

gelangt man wieder in das Hauptmenü 

von »sysinstall« zurück. Es ist hier 

nicht möglich, die Treiber im Fixit-System 

auf die Festplatte zu übertragen, deshalb 

wird noch einmal von der DVD gebootet. 

Der einfache Neustart schlägt in der 

FOSS-Cloud an dieser Stelle grundsätzlich 

fehl, man muss die Maschine im 

Webfrontend ohne Änderung des Boot- 

Devices von CD-ROM auf Platte manuell 

aus- und wieder einschalten. 

Im Hauptmenü von »sysinstall« wählt 

man dann den Punkt »Fixit« und dort 

»CDROM/DVD«. Man landet an einem 

Prompt mit der Kennung »Fixit#«. Hier 

laden die folgenden Befehle die Root- 

Partition der Festplatte und übertragen 

alle wichtigen Dateien von der Installations-CD: 

mount /dev/vtbd0s1a /mnt 

cd /mnt/boot/modules 

cp /dist/boot/modules/* . 

cd .. 

cp /dist/boot/loader.conf . 

Im letzten Schritt der Installation muss 

man noch die soeben kopierte Datei mit 

»ee loader.conf« in den Systemeditor laden 

und bearbeiten. In der Datei müssen 

die ursprünglichen Verweise auf das 

Starten von der RAM-Disk entfernt oder 

auskommentiert werden: 

# mfsroot_load="YES" 

# mfsroot_type="mfs_root" 

# mfsroot_name="/boot/mfsroot" 


... 

Damit ist die Installation von FreeBSD 8 

in der FOSS-Cloud beendet. Die Eingabe 

von »exit« beendet das Fixit-System. Über 

das Hauptmenü von »sysinstall« startet 

man das System neu. Im Webfrontend 

muss dafür noch die Bootreihenfolge umgestellt 

werden. Falls das System jetzt 

nicht booten will, wird es noch einmal 

gewaltsam im Webfrontend ausgeschaltet 

und dann wieder aufgerufen. Sobald es 

sauber von Festplatte startet, sind die 

Bootprobleme beseitigt. 

Bei FreeBSD 10, dem derzeitigen CUR- 

RENT, ist das Virtio-System in den normalen 

Quelltexten enthalten. Die Treiber 

brauchen also nicht mehr aus den Ports 

installiert und gesondert auf den Master 

übertragen zu werden. 

Leider findet man auf dem FTP-Server 

des Projekts derzeit keine vorgefertigten 

Images, sodass man das System selbst 

entweder für jede Installation aus den 

Quellen aus FreeBSD 9 aktualisieren 

muss (bei einer lokalen Installation akzeptabel) 

oder man baut sich für das 

spätere serverbasierte Einrichten selbst 

zuvor in einer anderen FreeBSD-Installation 

eine Installations-CD für CURRENT. 

Dazu müssen lokal einmal entweder über 

CTM oder aus dem CVS beziehungsweise 

SVN die Quellen zentral besorgt und dann 

durchkompiliert werden (siehe [4]). 

Die folgend gezeigten Schritte gehen davon 

aus, dass die Quellen von FreeBSD 

10 bereits installiert sind und das System 

mit den Aufrufen 

cd /usr/src 

make buildworld buildkernel 

make installkernel installworld 

reboot 

aktualisiert wurde. Auch das Portverzeichnis 

wird benötigt, es wird bei Be- 

Listing 1: FreeBSD-10-Installations-CD 

01 pkg_delete ‐a # Alle alten Programme müssen weg 

02 cd /usr/ports/sysutils/cdrtools # Hier sind die CD‐Hilfsprogramme 

03 make install clean # Programmpaket installieren 

04 setenv DESTDIR /usr/dist # Zielpfad, nicht im normalen Baum 

05 make installworld installkernel # ... und alles dorthin installieren 

06 cd /usr/src/etc # Im nächsten Schritt Baum ergänzen 

07 make distribution # Die Distribution aufgebauen 

08 cd /usr/dist/usr # Das obj‐Verzeichnis ist leer ... 

09 rmdir obj # ... und weg damit 

10 ln /usr/obj obj # Die Standard‐Dateien umlinken 

11 cd /usr/src/release # Der dritte Make‐Schritt 

12 make NOPORTS=YES NOSRC=YES cdrom # CD‐ROM in /usr/dist aufbauen 

13 cd /usr # Es müssen Sicherheitsflags ge‐ 

14 chflags ‐R noschg dist/ # löscht werden, damit man am Schluss 

15 # den Baum wieder loswerden kann. 

16 rm ‐r dist # Und weg mit dem temp. Baum 



darf mit »portsnap fetch install« 

aufgebaut. Auf keinen 

Fall dürfen nach dem Bauen 

des neuen Betriebssystems 

die Intermediärdateien im 

Quellbaum mit »make clean« 

gelöscht werden, denn sie 

werden noch gebraucht. Nach 

dem Neustart muss man außerdem 

»uname ‐a« prüfen, 

ob tatsächlich ein CURRENT- 

System installiert ist. Anschließend 

geht es so weiter 

wie in Listing 1 gezeigt. 

Die Make-Läufe müssen 

einmal in »src« selbst, dann 

in »src/etc« und abschließend in »src/ 

release« durchgeführt werden. Die ISO- 

Datei befindet sich zum Schluss in »/usr/ 

obj/usr/src/release/«. Die eigentliche Arbeitsdatei 

heißt »release.iso«. Sie enthält 

keine modifizierte Kernelkonfiguration. 

Beim Booten auf dem FOSS-Cloud-Server 

muss man deshalb die Treiber manuell 

vor der eigentlichen Installation laden. Im 

Verzeichnis »/usr/obj/usr/src/release/« 

sind noch weitere Dateien abgelegt, sie 

werden aber nicht benötigt. 

Image vom Image 

Hat man ein Standard-ISO-Image angelegt, 

kann man damit auch wieder ein 

neues angepasstes erzeugen. Dazu wird 

das soeben angelegte ISO-Image zuerst 

als Pseudolaufwerk eingebunden, dann 

werden die darin enthaltenen Dateien extrahiert 

und der neue Master wie oben bereits 

beschrieben angepasst und auch mit 

zusätzlichen Daten bestückt. Von diesem 

Master wird dann wieder ein korrigiertes 

Image für die FOSS-Cloud geschrieben. 

Wichtig: Aus den Ports oder den Paketen 

muss außerdem das Programm »dupmerge« 

installiert werden. Eingebunden 

wird das Image folgendermaßen: 

mkdir /mnt/iso 

mdconfig ‐a ‐t vnode ‐f U 

/usr/obj/usr/src/release/release.iso 

md0 

mount ‐t cd9660 /dev/md0 /mnt/iso 

»/dev/md0« ist ein Memory-Device, das 

nach dem Kopieren der Dateien wieder 

freigegeben werden muss. (Ist »md0« 

bereits vorher in Betrieb gewesen, wird 

automatisch ein Geräteeintrag mit einer 

höheren Nummer angelegt.) Zuerst wer- 

Abbildung 5: In dieser Konsole werden bei FreeBSD 9 und 10 die Nacharbeiten 

durchgeführt. Zum Schluss wird die Live-Session mit »poweroff« beendet. 

den aber mit den folgenden Befehlen die 

Dateien übertragen: 

mkdir ‐p /usr/foss/tree 

cd /usr/foss/tree 

cp ‐Rp /mnt/iso/* . 

cp /mnt/iso/.p* . 

cp /mnt/iso/.c* . 

find ./ ‐type f ‐print0 | dupmerge 

ee boot/loader.conf 

Jetzt müssen wie bereits bei der Vorversion 

die Treiber in eine neue »boot/ 

loader.conf« geschrieben werden: 





Das ursprüngliche Image kann nun mit 

umount ‐f /dev/md0 

mdconfig ‐l 

md0 

mdconfig ‐d ‐u md0 

mdconfig ‐l 

ausgebunden und danach »md0« bei Bedarf 

wieder anderweitig genutzt werden. 

Hat das Ausbinden des Geräteknotens 

geklappt, zeigt ein anschließender Aufruf 

von »mdconfig ‐l« kein eingebundenes 

Device mehr an. Das hier gezeigte »‐f« 

bei »umount« ist nur nötig, wenn das 

System meldet, das Device sei noch belegt 

ist. Erst ein freigegebenes md-Gerät 

kann abgeschaltet werden. 

Erst testen 

Im letzten Arbeitsschritt wird auch hier 

wieder mit demselben Aufruf wie schon 

weiter oben gezeigt ein ISO-Image gebrannt, 

mit den richtigen Dateiattributen 

(666) ausgestattet und per »scp« auf den 

Server übertragen. Erst wenn 

sich das Image als korrekt erwiesen 

hat und die Installation 

in der FOSS-Cloud ordnungsgemäß 

abläuft (Abbildung 4, 

Abbildung 5), sollte der in »/ 

usr/cd/tree« angelegte Verzeichnisbaum 

wieder gelöscht 

werden. 

Die Installation selbst läuft 

dann genauso wie bei FreeBSD 

9 ab, nur die Treiber müssen 

zum Schluss nicht übertragen 

werden. Die »/boot/loader. 

conf« braucht man aber natürlich 

auch, und sie wird genauso 

wie bereits bei FreeBSD 9 geschildert 

direkt nach der Installation im Live- 

System auf den Server übergespielt. Wer 

bei FreeBSD 10 versucht, die virtuelle 

Festplatte mit einem Master Boot Record 

anstelle des GPT auszustatten, kann das 

auch tun, es ist nur etwas frickelig, weil 

der Installer hier fehlerhaft ist. Man muss 

also etwas herumprobieren, muss aber 

keine manuelle Installation mit »fdisk« 

und »disklabel« durchführen. 

Und es geht doch 

Die Ports von FreeBSD 10 waren bei 

Redaktionsschluss nicht fehlerfrei, und 

es war nicht möglich, einen modernen 

Desktop damit aufzubauen, denn das 

Kompilieren und auch die Binärinstallationen 

von Gnome 2, KDE 3 und KDE 4 

waren nicht vollständig möglich. Bei der 

FOSS-Cloud und KVM ist das aber nicht 

weiter schlimm, weil wegen des defekten 

Maustreibers X ohnehin nicht genutzt 

werden kann. Ein Serversystem lässt sich 

aber allemal einrichten. (ofr) 

n 

Infos 

[1] Webseite der FOSS-Cloud: 

[http:// www. foss‐cloud. org/ de/] 

[2] Jörg Braun: Der wolkige Desktop. FreeX 

5’2012, S. 70 

[3] Jörg Braun: XP-Gast in der FOSS-Cloud. 

FreeX 5’2012, S. 78 

[4] Jürgen Dankoweit (Hrsg.): FreeBSD. C&L- 

Verlag 2009, ISBN 978-3-936546-41-5. 

[5] Jörg Braun: Das VirtualBox-Buch. C&L- 

Verlag 2012, ISBN 978-3-936546-71-2. 

[6] Jörg Braun und Dr. Rolf Freitag: Duplikate 

von der Platte. FreeX 5’2011, S. 90. 


Admin 


129

Service 

Impressum und Vorschau 

Impressum ISSN 2190-1066 

ADMIN-Magazin eine Publikation der Medialinx AG 

Redaktionsanschrift Putzbrunner Straße 71 

81739 München 

Tel.: 0 89/99 34 11-0 

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

Internet 


E-Mail 

redaktion@admin-magazin.de 

Geschäftsleitung 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/Test 

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

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 Elke Knitter (Schlussredaktion), 

Carsten Schnober, Tim Schürmann, Claudia Thalgott 

Produktionsleitung Christian Ullrich, cullrich@medialinx-gruppe.de 

Grafik 

Klaus Rehfeld, Judith Erb 

Titel: Judith Erb, Ausgangsgrafik: alienforce, 123RF 

Abo-Infoseite 

Abonnenten-Service 

www.admin-magazin.de/abo 

Veronika Kramer 

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 (2 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 € 49,90 € 54,90 Sfr 99,90 € 59,90 

Preise Digital Deutschland Österreich Schweiz Ausland EU 

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

DigiSub (6 Ausgaben) € 44,90 € 44,90 Sfr 49,05 € 44,90 

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

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

Preise Kombiabos 

Profi-Abo 2 € 136,60 € 151,70 Sfr 259,90 € 165,70 

1 

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

2 

mit Linux-Magazin-Abo und beiden Jahres-DVDs 

Schüler- und Studentenermäß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.2012 

National 

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 

Pressevertrieb MZV, Moderner Zeitschriften Vertrieb GmbH 

Breslauer Straße 5, 85386 Eching 

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

Druck 

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 eingetragenes Marken zeichen von 

Linus Torvalds und wird in unserem Markennamen mit seiner Erlaubnis verwendet. Alle anderen Marken sind Eigentum 

der jeweiligen Inhaber. Eine Haftung für die Richtigkeit von Veröffentlichungen kann trotz sorgfältiger Prüfung durch 

die Redaktion vom Verlag nicht übernommen werden. Mit der Einsendung von Manu s kripten gibt der Verfasser seine 

Zustimmung zum Abdruck im Admin-Magazin. Für unverlangt ein gesandte Manuskripte kann keine Haftung übernommen 

werden. Die Redaktion behält sich vor, Artikel zu kürzen. Das Exklusiv- und Verfügungsrecht für angenommene 

Manuskripte liegt beim Verlag. Es darf kein Teil des Inhalts ohne ausdrückliche schriftliche Genehmigung des Verlags in 

irgendeiner Form vervielfältigt oder verbreitet werden. Copyright © 1994–2013 Medialinx AG 

Inserentenverzeichnis 

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

ADMIN http://www.admin-magazin.de 25, 105, 121 

Android User GY http://www.android-user.de 69, 117 

Deutsche Messe AG http://www.cebit.de 55 

DFN-Cert Services GmbH http://www.dfn-cert.de 27 

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

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

German Unix User Group (GUUG) e.V. http://www.guug.de 51 

Hetzner Online AG http://www.hetzner.de 132 

IPTAM GmbH http://www.iptam.com 57 

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

Linux New Media AG http://www.linuxnewmedia.de 93 

Linux User Spezial http://www.linux-user.de/spezial 49 

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

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

Linux-Magazin Academy http://www.academy.linux-magazin.de 87, 127 

Linux-Magazin Online http://www.linux-magazin.de 89 

LinuxUser http://www.linuxuser.de 101 

Netways GmbH http://www.netways.de 103 

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

pascom - Netzwerktechnik 

GmbH & Co.KG http://www.pascom.net 11 

Pluspol GmbH http://www.pluspol.de 23 

PlusServer AG http://www.plusserver.de 34, 44, 64, 80 

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

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

Webtropia http://www.webtropia.com 7 

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

Einem Teil dieser Ausgabe liegt ein Beilage der Firma HACKATTACK IT SECURITY GmbH 

(http://www.hackattack.com ) bei. Wir bitten unsere Leser um freundliche Beachtung. 

Autoren dieser Ausgabe 

Eric Amberg Rausgegraben 28 

Jörg Braun Hochzeit 124 

Jörg Braun Neubau 120 

Hanno Böck Uneinsichtig 90 

James Dade Paketversand 48 

Jürgen Dankoweit Sicher hinter Gittern 110 

Thomas Drilling Kurs halten 36 

Thomas Drilling Neu gemischt 46 

Thomas Drilling Virtualisierungswarte 66 

Felix von Eye Leider geöffnet 94 

Patrik Fehrenbach Gift für alle Fälle 98 

Benjamin Fleckenstein Nagios am Apparat 24 

Michael Grabatin Leider geöffnet 94 

Wolfgang Hommel Leider geöffnet 94 

Thomas Joos Neues Gewand 82 

Thomas Joos Schatztruhe 56 

Martin Loschwitz Einrichtungsberater 72 

Stefan Metzger Leider geöffnet 94 

Vilma Niclas Arbeit im Auftrag 16 

Rosa Riebl Hochzeit 124 

Rosa Riebl Neubau 120 

Thorsten Scherf Im Dickicht 20 

Frank Wiles Patchwork 106 

VORSCHAU 

ADMIN 02/2013 erscheint am 14. März 2013 

Samba 4 

Am Schnürchen 

© Roman Dekan, 123RF 

Seit Jahren erwartet, ist die Version 

4 des Samba-Servers nun endlich 

Realität geworden. Wir werfen einen 

Blick auf die neuen Fähigkeiten und 

zeigen, wie sich Samba 4 in Linuxund 

Windows-Netzwerken einsetzen 

lässt. 

Software zum zentralen Management 

der Rechnerkonfiguration 

wird in Serverräumen immer 

beliebter. Mit dem auf Puppet 

basierenden Foreman gibt es eine 

zentrale Stelle für alle Management-Belange. 

© Glenda Powers, 123RF 


globalBusiness: 

weltweit mehr 

als 4.000 Orte 

verfügbar 

New York – Berlin zum Ortstarif: 

globalBusiness verbindet Sie mit der Welt. 

Und so geht’s: Sie erhalten von der outbox AG 

eine lokale Rufnummer z.B. aus New York. 

Alle Anrufe darauf werden umgehend auf Ihre 

Festnetznummer in Berlin – oder auf jedes 

andere beliebige Ziel – weitergeleitet. So sind 

Sie in Ihrem Büro in Deutschland für internationale 

Kunden zu deren Ortstarif erreichbar. 

Bieten Sie Ihren Kunden und Interessenten mit 

globalBusiness diese persönliche und günstige 

Kontaktmöglichkeit und sichern Sie sich Ihren 

Wettbewerbsvorteil. Alle verfügbaren Länder 

und Vorwahlen im Web: www.outbox.de/admin 

Infos und Beratung: 0800 / 66 474 640 

www.outbox.de/admin

€ 59 

Hetzner Online unterstützt mit der 

Verwendung von 100% regenerativem 

Strom aktiv den Umweltschutz. 

Entscheiden Sie sich gemeinsam 

mit uns für eine saubere Zukunft. 

49

ADMIN Magazin Enterprise-Linux (Vorschau)

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?