25.02.2014 Aufrufe

ADMIN Magazin Enterprise-Linux (Vorschau)

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.

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

www.admin-magazin.de

Admin

Ausgabe 01-2013

3


Service

Inhalt

ADMIN

Netzwerk & Security

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

Linux

O’Reilly, 3. Auflage 2012

420 Seiten

45 Euro

ISBN 978-3-86899-358-5

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


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

Low Energy Server

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.

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


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.

www.admin-magazin.de

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

Ausgabe 01-2013

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.

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


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-

Virtualisierung

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

www.admin-magazin.de

Admin

Ausgabe 01-2013

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

■ Unlimited Traffic inklusive

■ 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

■ Unlimited Traffic inklusive

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

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


Auftragsdatenverarbeitung

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.

www.admin-magazin.de

Admin

Ausgabe 01-2013

17


Login

Auftragsdatenverarbeitung

© 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.

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


Auftragsdatenverarbeitung

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

www.admin-magazin.de

Admin

Ausgabe 01-2013

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.

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


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ß ;-)

www.admin-magazin.de

Admin

Ausgabe 01-2013

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.

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


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

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


ADMIN

Netzwerk & Security

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

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


IPv6-Migration

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.

www.admin-magazin.de

Admin

Ausgabe 01-2013

29


Netzwerk

IPv6-Migration

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.

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


IPv6-Migration

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

(Abbildung 7).

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.

www.admin-magazin.de

Admin

Ausgabe 01-2013

31


Netzwerk

IPv6-Migration

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

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


IPv6-Migration

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.

www.admin-magazin.de

Admin

Ausgabe 01-2013

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.

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


Enterprise-Distributionen

Enterprise-Linux

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.

www.admin-magazin.de

Admin

Ausgabe 01-2013

37


Enterprise-Linux

Enterprise-Distributionen

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

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


Enterprise-Distributionen

Enterprise-Linux

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-

www.admin-magazin.de

Admin

Ausgabe 01-2013

39


Enterprise-Linux

Enterprise-Distributionen

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.

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


Enterprise-Distributionen

Enterprise-Linux

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,

Telefon) + Maintenance

(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,

Telefon) + Maintenance

(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!

www.admin-magazin.de

Admin

Ausgabe 01-2013

41

Wissen, wie’s geht.


Enterprise-Linux

Enterprise-Distributionen

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.

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


Enterprise-Distributionen

Enterprise-Linux

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.

www.admin-magazin.de

Admin

Ausgabe 01-2013

43


Enterprise-Linux

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.

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


Ubuntu Enterprise

Enterprise-Linux

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

Assurance, Wissensdatenbank,

Installation, Windows-Integration,

„Standard“: Landscape, Ubuntu

Assurance, Wissensdatenbank,

Installation

Virtualisierung

Preis 700 US-Dollar 105 US-Dollar

Premium-Preise für ein Jahr

Anzahl 1 Server 1 Desktop

Support-Umfang „Advanced“: Landscape, Ubuntu

Assurance, Wissensdatenbank,

Installation, Windows-Integration,

Virtualisierung, Clustering, angepasstes

„Advanced“: Landscape, Ubuntu

Assurance, Wissensdatenbank,

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.

www.admin-magazin.de

Admin

Ausgabe 01-2013

47


Enterprise-Linux

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

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


Satellite Server

Enterprise-Linux

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.

www.admin-magazin.de

Jetzt bestellen

unter: www.linuxuser.de/spezial

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

01-2013

49


Enterprise-Linux

Satellite Server

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.

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


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.

www.admin-magazin.de

Ausgabe 01-2013

51


Enterprise-Linux

Satellite Server

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.

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


Satellite Server

Enterprise-Linux

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.

www.admin-magazin.de

Admin

Ausgabe 01-2013

53


Enterprise-Linux

Satellite Server

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]

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


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

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


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.admin-magazin.de

www.iptam.com

Ausgabe 01-2013

57


Know-how

Windows Server 2012

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-

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


Windows Server 2012

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.

www.admin-magazin.de

Admin

Ausgabe 01-2013

59


Know-how

Windows Server 2012

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.

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


Windows Server 2012

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

(Abbildung 6).

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

www.admin-magazin.de

Admin

Ausgabe 01-2013

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

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


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.

www.admin-magazin.de

Admin

Ausgabe 01-2013

63


Virtualisierung

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

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


Proxmox

Virtualisierung

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.

www.admin-magazin.de

Admin

Ausgabe 01-2013

67


Virtualisierung

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-

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


Proxmox

Virtualisierung

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

Ausgabe 01-2013

69


Virtualisierung

Proxmox

schehen, sollte eine Verbindung zum

Proxmox-Webinterface unter der Adresse

»https://


Proxmox

Virtualisierung

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]

www.admin-magazin.de

Admin

Ausgabe 01-2013

71


Virtualisierung

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-

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


Open Stack

Virtualisierung

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


Virtualisierung

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.

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


Open Stack

Virtualisierung

»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

www.admin-magazin.de

Admin

Ausgabe 01-2013

75


Virtualisierung

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.

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


Open Stack

Virtualisierung

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.

www.admin-magazin.de

Admin

Ausgabe 01-2013

77


Virtualisierung

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

(Abbildung 5).

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.

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


Open Stack

Virtualisierung

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.

www.admin-magazin.de

Admin

Ausgabe 01-2013

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

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


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.

www.admin-magazin.de

Admin

Ausgabe 01-2013

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

(Abbildung 4).

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-

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


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

www.admin-magazin.de

Admin

Ausgabe 01-2013

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

(Abbildung 6).

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]

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


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

Low Energy Server

© 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

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


Low Energy Server

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

www.admin-magazin.de

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.

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


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

www.admin-magazin.de

Admin

Ausgabe 01-2013

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.

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


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

Linux

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

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


Automatische Portscans

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

www.admin-magazin.de

Admin

Ausgabe 01-2013

95


Security

Automatische Portscans

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

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


Automatische Portscans

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]

www.admin-magazin.de

Admin

Ausgabe 01-2013

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:

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


SQL-Injections

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“

www.admin-magazin.de

Admin

Ausgabe 01-2013

99


Security

SQL-Injections

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

(Abbildung 2).

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,

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


SQL-Injections

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€*

www.admin-magazin.de

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

Ausgabe 01-2013

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