ADMIN Magazin Monitoring (Vorschau)

LVM: Der Logical Volume SSH: Tunnels, Port Forwarding Perl: GUIs auf 

Manager von Linux 

und VPNs mit der Secure Shell der Konsole 

ADMIN 

Netzwerk & Security 

Auf DVD: 

01 2012 

Jan. – Feb. 

6.1 

16 zum gleichen Preis! 

Seiten mehr Inhalt 

Monitoring 

Rechner und Dienste überwachen 

Monitoring-Software unter der Lupe: 

Benchmarks, Vergleiche, Tests 

pfSense 

Leistungsfähige 

BSD-Firewall 

Neu: UCS 3.0 

Der Univention Corporate 

Server ersetzt mit Samba 4 

jetzt Active Directory 

High Availability 

n Cluster-Agents im Eigenbau 

n GFS mit DRBD und Pacemaker 

Upstart 

Workshop zum Nachfolger 

des Linux-Init-Systems 

Expect 

Skripting interaktiver 

Programme 

www.admin-magazin.de 

D EUR 9,80 

A EUR 10,80 - BeNeLux EUR 11,25 

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

4 196360 509805 01

Sven Stornebel 

STRATO Hosting-Kunde 

www.stornebel.de 

Power Hosting 

schon ab 

€/Mon.* 

Jetzt starten und 6 Monate 

die Grundgebühr sparen! 

Den Kopf voller Ideen? 

Mit STRATO werden daraus erfolgreiche Websites! 

Bis zu 12 Domains, 30 MySQL-Datenbanken und unlimited Traffic 

NEU! Mehr Leistung: Bis zu 20.000 MB Speicher und 2 GB E-Mailspace 

1-Klick-Installation: Wordpress, Typo3, Joomla!, xt:Commerce, Contao 

NEU! Günstige Partnerangebote für individuelle Text- und Designkreation 

Hosting-Pakete | Online-Speicher | Webshops | V-Server 

* Preisaktion bis 31.01.2012: Alle PowerWeb-Pakete 6 Monate 0 €/mtl., danach ab 5,90 €. 

Einmalige Einrichtungsgebühr 14,90 €. Mindestvertragslaufzeit 12 Monate. Preise inkl. MwSt. 

Servicetelefon: 0 18 05 - 055 055 

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

Davids Chance 

Editorial 

Davids Chance 

Liebe Leserinnen und Leser, 

dieses Jahr, so prognostizieren die Analysten von IDC, wird sich die Schlacht 

um die Marktführerschaft beim Cloud Computing dramatisch verschärfen. Denn 

mehr als 80 Prozent aller neuen, kommerziellen Unternehmensanwendungen, 

schätzen die Experten, sollen auf Cloud-Plattformen eingeführt werden. Dabei 

geht es um sehr viel Geld: Allein Amazon Web Services wird für 2012 ein Umsatz 

von einer Milliarde Dollar mit Cloud-Diensten vorausgesagt. Und andere – etwa 

Google, Salesforce oder VMware – sind ebenfalls auf dem Sprung. 

Zu den kriegsentscheidenden Vorteilen wird es gehören, die eigenen Standards 

durchzusetzen. Noch ist das Rennen offen, aber die Kombattanten haben in den einschlägigen Gremien bereits 

ihre Geschütze in Stellung gebracht. Überall gibt es Arbeitsgruppen für Cloud-Standards: Bei der DMTF mit namhaften 

Mitgliedern wie Cisco, EMC, IBM oder Microsoft, bei der Cloud Security Alliance (mit Google, Intel, Oracle 

und 100 anderen), bei der mächtigen Storage Networking Industry Association (SNIA), beim Open Grid Forum 

mit 400 Mitgliedern und so weiter und so fort. Und bei der OSBF. Einem Verein vorwiegend mittelständischer 

Firmen aus Deutschland, viele mit regionaler Bekanntheit. Dort gibt es seit Kurzem eine Open Cloud Business 

Initiative. Ist das Größenwahn? 

Saul aber sprach zu David: Du kannst nicht hingehen wider diesen Philister, mit ihm zu streiten; denn du bist ein 

Knabe, dieser aber ist ein Kriegsmann von seiner Jugend auf. 

Welche Chance haben offene Standards in einem Multimilliarden-Poker? Kann ein relativ kleiner, nationaler Verein 

internationalen Goliaths Paroli bieten? Oder wenigstens etwas Nützliches beitragen? Nein? 

Im Moment schauen wir zu, wie Flash von Tag zu Tag an Bedeutung verliert und HTML 5, ein offener Standard, 

den Stich macht. Als offen müssen auch die anderen Standards des W3C gelten, und sie haben sich ebenfalls 

durchgesetzt: CSS etwa oder XML. Auch viele der in Tausenden RFCs beschriebenen Standards der IETF sind 

ebenso offen wie erfolgreich: zum Beispiel TCP/IP, um nur einen herauszugreifen. Dasselbe kann man von vielen 

ISO-Normen sagen, beispielsweise ISO/IEC 9075:2008, das ist SQL. Kurz: Offene Standards sind häufig ein Erfolgsmodell. 

Der Versuch, sie auch im Cloud Computing zu etablieren, ist eine lohnende Sache. 

Und David tat seine Hand in die Tasche und nahm einen Stein daraus und schleuderte und traf den Philister an 

seine Stirn, dass der Stein in seine Stirn fuhr und er zur Erde fiel auf sein Angesicht. 

@ leserbriefe@admin-magazin.de 

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


Admin 

Ausgabe 01-2012 

3

Service 



Inhalt 

01/2012 

Server und Dienste immer im 

Blick, mit unseren Artikeln zum 

Thema "Monitoring" ab S. 42. 

Eine Übersicht freier 

42Monitoring-Vergleich 

Software fürs Monitoring 

von Rechnern und Ressourcen. 

Login 

Netzwerk 


8 Branchen-News 

Neues von Firmen und Projekten. 

12 Vorgelesen 

Von Shell-Skripting und Wordpress 3. 

14 Admin-Story 

Tagebuch eines IT-Nomaden. 

28 Not-Lösung 

Remote-Shell-Zugriff über den 

Webbrowser. 

32 Schlüsselwächter 

SSH-Tipps für den Alltag: von Port 

Forwarding bis zum VPN. 

42 Unter Überwachung 

Freie Monitoring-Systeme für den Mittelstand 

im Überblick. 

50 Zwillingsforschung 

Von Nagios abgeleitetete 

Monitoring-Lösungen im 

Vergleich. 

16 Leserbriefe 

Kommentare und Meinungen. 

18 Think Twice 

Warum wird ständig alles neu erfunden? 

20 Monitoring a la mode 

Notizen von der vierten Open Source 

Monitoring Conference (OSMC). 

22 Wann ist Software geschützt? 

Eine juristische Perspektive. 

Service 

3 Editorial 

4 Inhalt 

6 Heft-DVD 

130 Impressum und Vorschau 

56 Kontrollzentrale 

Der Nagios-Ableger Open IT-Cockpit im 

Praxis-Kurztest. 

60 Aus einem Guss 

Das über Jahre gereifte freie Monitoring-Paket 

Zabbix bietet im praktischen 

Einsatz einige Vorteile. 

66 Zieleinlauf der Kontrolleure 

Monitoring-Lösungen auf Nagios-Basis 

im Benchmark-Test. 

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

Inhalt 

Service 

Was bringt Version 

80Univention 

3.0 des Univention 

Corporate Server? 

86pfSense 

Die BSD-basierte 

Firewall schützt das 

eigene Netzwerk. 

96OCF 

Cluster-Agents für 

eigene Applikationen 

selber programmieren lernen. 

Test 

72 Heiter bis wolkig 

Die Firma Kamp bietet mit ihrem Produkt 

"Virtual Core" eine private Cloud 

mit einfacher Verwaltung. 

74 Ausgepackt 

Microsofts System Center Operations 

Manager 2012 managt auch Linux. 

76 Testlabor 

Fedora 16 mit Cloud- und Virtualisierungs-Technologien. 

80 Runderneuert 

Der Univention Corporate Server 3.0 eignet 

sich dank Samba 4 auch als Ersatz 

für Active Directory. 

Security 

86 Schutzschild 

Die auf BSD basierende Firewall- und 

Router-Distribution pfSense. 

94 Abwehrverhalten 

Mit Apachebench lassen sich einfache 

Webangriffe bewerkstelligen. Eine Firewall 

mit IPTables wehrt sie ab. 

Know-how 

96 Agentenausbildung 

HA-Serie, Teil 8: OCF-Agenten selber 

programmieren. 

Basics 

112 Start me up 

Wie Upstart Linux-Distributionen bootet 

und man dafür eigene Skripte schreibt. 

Programmieren 

120 Fern gesteuert 

Mit Expect und Tcl können Administratoren 

interaktive Sitzungen skripten. 

106 Nichts exklusiv 

HA-Workshop, Teil 7: GFS mit DRBD und 

Pacemaker. 

118 Tortenstück 

Mit dem Logical Volume Manager (LVM) 

lässt sich Storage leicht nachträglich 

vergrößern und verkleinern. 

126 Old School 

Mit dem Perl-Modul Curses::UI sind textbasiere 

Benutzerschnittstellen auf der 

Konsole schnell erstellt. 

Mehr Infos auf Seite 6 

6.1 

n 64-Bit-Version zur Installation auf Festplatte 

n Community-Distribution, basierend auf 

Red Hat Enterprise Linux 


Admin 


5

SErvice 

Heft-DVD 

Heft-DVD 

Auf dem beiliegenden Datenträger finden Sie die Server- 

Ausgabe der neuesten CentOS-Version 6.1: 

◗ 64-Bit-Version für AMD 64 und Intel EM 64 T zur Installation 

auf Festplatte. 

◗ Freie Community-Distribution, basierend auf dem Code 

von Red Hat Enterprise Linux. 

◗ Sieben Jahre lang Support (Security-Updates). 

◗ Per Continuous Release auf die jeweils neueste Version 

aktualisierbar. 

Legen Sie einfach die DVD ins das Laufwerk ein und starten 

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

die richtige Boot-Reihenfolge einstellen, damit das DVD- 

Laufwerk vor der Festplatte an die Reihe kommt. n 

DVD kaputt? 

Wir schicken Ihnen kostenlos eine 

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

info@admin-magazin.de 

Info 

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

[2] Howtos: [http://wiki.centos.org/HowTos] 

[3] Continuous Release: [http://wiki.centos.org/AdditionalResources/Repositories/CR] 

6 Ausgabe 01-2012 

Admin www.admin-magazin.de

VIRTUAL POWER & 

VOLLER ROOTZUGRIFF 

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. Die Mindestvertragslaufzeit beträgt einen Monat. Keine Setupgebühr. Der Abrechnungszeitraum ist monatlich. Die Kündigungsfrist beträgt 4 Wochen zum Vertragsende. Wird der Vertrag 

nicht fristgerecht gekündigt, verlängert er sich jeweils um eine weitere Mindestvertragslaufzeit. Alle angegebenen Preise inklusive 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 4.0 mit Linux-Betriebssystem kostenlos hinzubuchen.

Login 

News 

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

Neue Software und Produkte 

Branchen-News 

EMEA: Servermarkt stagniert – Linux wächst 

Die Marktforscher von IDC bescheinigen 

dem Servermarkt der EMEA-Region 

(Westeuropa, Naher Osten, Afrika) im 

dritten Quartal 2011 ein bescheidenes 

Umsatzwachstum von 0,6 Prozent im 

Jahresvergleich. 

Damit beträgt der Quartalsumsatz 3,2 Milliarden 

US-Dollar für 546883 ausgelieferte 

Geräte. Die Zahl der Server ist gegenüber 

dem Vorjahresabschnitt um ein Prozent 

gesunken. Für den sehr bescheidenen Zuwachs 

macht IDC den schlechten Umsatz 

Die Herstellerrangliste im EMEA-Servermarkt. 

im westeuropäischen Gebiet verantwortlich, 

der mit einem Minus von 1,4 Prozent 

gegenüber Q3 2010 unterdurchschnittlich 

gewesen sei. Mit einem Anteil von rund 

75 Prozent am EMEA-Markt notieren die 

US-Marktforscher das bislang schlechteste 

Ergebnis für Westeuropa, seitdem 

IDC den Servermarkt statistisch aufbereitet. 

In Deutschland sei der Umsatz um 

3,6 Prozent gesunken, Frankreich und 

Großbritannien verzeichnen ein leichtes 

Wachstum. 

Bei den Geräten selbst erweisen sich die 

x86-Server als stärkste Triebkraft. Mehr 

als 98 Prozent der ausgelieferten Server 

seien x86-Systeme gewesen, so IDC. Der 

Umsatzanteil der x86-Systeme beträgt 

im Q3 2011 2,3 Milliarden US-Dollar. Der 

Umsatz von Nicht-x86-Servern dagegen 

ist unter die Milliardengrenze abgefallen 

und bei 875,5 Millionen US-Dollar 

gelandet. 

Windows-Server dominieren bei den Betriebssystemen 

mit einem Anteil von 53 

Prozent, verzeichnen aber ein vergleichsweise 

moderates Wachstum von 3,7 Prozent. 

Linux profitiert dagegen vom Trend 

hin zu den x86-Systemen und wächst 

bei den Betriebssystemen am schnellsten 

(plus 5,1 Prozent). Die Leidtragenden der 

x86-Welle sind Unix (minus 5,8 Prozent 

und z/OS (minus 15 Prozent). Hewlett- 

Packard verkauft seit nunmehr 15 Quartalen 

die meisten Server und hält so die 

Position eins vor IBM, Dell, Oracle und 

Fujitsu. 

ODF: OB Ude schreibt an EU-Kommissarin 

Münchens Oberbürgermeister Christian Ude hat sich in einem 

Brief an Neelie Kroes, EU-Kommissarin für die Digitale Agenda, 

für offene Dokumentenformate in der EU-Verwaltung ausgesprochen. 

Der Rathauschef schreibt „Im Namen vieler Städte und regionaler 

Behörden Deutschlands möchte ich Sie als Präsident 

des Deutschen Städtetages und Oberbürgermeister der Stadt 

München bitten, sich weiterhin für die Verbreitung von ,Offenen 

Standards’ in der Bürokommunikation und ,Freier und quelloffener 

Software’ einzusetzen.“ Als Argumente für seine Forderung 

an die EU-Verwaltung führt er Arbeitserleichterung 

und wegfallende Lizenzkosten für proprietäre Software wie 

Microsoft Office an. Das englischsprachige Schreiben ist in der 

Rathaus-Umschau 230 [http://www.muenchen.info/pia/RSS/230.pdf] 

(PDF-Dokument) in deutscher Übersetzung nachzulesen. 

Die Münchner Stadtverwaltung verwendet intern Open Office, 

das sie durch das freie Vorlagensystem Wollmux erweitert hat. 

In der Kommunikation mit den Bürgern setzt die Kommune auf 

das Open-Document-Format, RTF und PDF. 

Zugangserschwerungsgesetz erledigt 

Der Bundestag hat das umstrittene Zugangserschwerungsgesetz, 

das weitgehend nutzlose Internetsperren vorsah, nun 

zurückgenommen. 

Zu diesem Zweck wurde ein Aufhebungsgesetz [http://dipbt. 

bundestag.de/dip21/btd/17/066/1706644.pdf] (PDF) zum Zugangserschwerungsgesetz 

fraktionsübergreifend verabschiedet. Damit 

ist das erst im Februar 2010 in Kraft getretene Gesetz wieder 

kassiert, das vorsah, Seiten mit gesetzeswidrigen Inhalten auszufiltern. 

Gegen dieses Verfahren hatte es von verschiedenen 

Seiten und von Anfang an Einwände gegeben, weil diese 

Maßnahme sehr leicht zu umgehen ist. Durchgesetzt haben 

sich nun die Verfechter der Strategie „Löschen statt sperren“. 

„Die Internetbranche setzt sich seit Jahren erfolgreich für die 

fortlaufende Verbesserung der Löscherfolge ein. Hierzu gehört 

neben der Sicherung sämtlicher Beweise für die Strafverfolgung 

die internationale Zusammenarbeit. Inzwischen bekommen 

wir illegale Inhalte in wenigen Tagen aus dem Netz“, so Oliver 

Süme, Vorstand des Verbands der deutschen Internetwirtschaft 

eco für Recht, Regulierung und Politik. 


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

Red Hat Developer Conference in Tschechien 

Red Hat Tschechien lädt interessierte 

Linux- und JBoss-Entwickler zu seiner 

Developer Conference vom 17. bis 18. 

Februar 2012 ins tschechische Brno ein. 

Besucher aus dem benachbarten Ausland 

brauchen die Sprachbarriere offenbar 

nicht zu fürchten: Die Wiki-Seite zur Veranstaltung 

verzeichnet etliche Vorträge in 

englischer Sprache, die Themen reichen 

vom Deltacloud API über GTK+ 3 bis hin 

zum Test von Java-EE-Anwendungen. 

Die Teilnahme an der Konferenz in der 

Masaryk-Universität ist kostenlos und 

erfordert keine Voranmeldung. 

Wer sich allerdings ein Konferenz-T-Shirt 

und den Eintritt zur After-Party sichern 

möchte, muss sich mit der tschechischen 

Registrierungsseite auseinandersetzen. 

Alle weiteren Informationen zur 

Veranstaltung gibt es auf einer Seite im 

Fedora-Wiki [http://fedoraproject.org/wiki/ 

DeveloperConference2012]. 

Managed 

Hosting 

Rangliste der illegalen Praktiken von Admins 

Security-Anbieter Balabit hat für eine Studie 

über 200 IT-Mitarbeiter zu verbotenen 

Aktivitäten auf den ihnen anvertrauten 

Systemen befragt. 

Auf Platz 1 liegt, nach prozentualem Anteil, 

der Download von illegalem Content 

am Arbeitsplatz (54 Prozent). Es folgt die 

Änderung von Sicherheitseinstellungen 

(etwa Firewalls) mit 48 Prozent. Ziel der 

letztgenannten Praktik ist es, sich Zugriff 

auf IT-Ressourcen im Unternehmen zu 

verschaffen, etwa per Remote-Access. Die 

Beschaffung von firmeninternen Informationen 

(29 Prozent) folgt auf Platz drei. 

Der neugierige Blick in Gehaltslisten und 

Personalunterlagen und sonstige vertrauliche 

Geschäftsunterlagen nimmt Platz 

vier ein (25 Prozent). Mit 16 Prozent 

der Nennungen liegt das Mitlesen von 

Kollegen-Mails auf Platz fünf. Das Sextett 

vervollständigt die Manipulation von 

Log-Dateien (15 Prozent) und dies meist 

zum Zweck, eine der fünf vorgenannten 

Aktivitäten zu verschleiern. 

Befragt wurden rund 200 IT-Mitarbeiter 

zwischen Juli und Oktober 2011. 74 Prozent 

der IT-Fachleute räumten ein, dass 

sie bereits mindestens einmal IT-Systeme 

des Unternehmens auf unerlaubte Weise 

genutzt hätten. Rund 51 Prozent der Befragten 

sind für Großunternehmen tätig, 

17 Prozent für mittelständische und 25 

Prozent für kleine Firmen. Die Mehrzahl 

der Unternehmen ist im Bereich IT und 

Telekommunikation aktiv (53 Prozent), 

24 Prozent im Finanzsektor. In Behörden 

arbeiten 12 Prozent der befragten IT-Fachleute, 

im Bereich Handel und Dienstleistungen 

7 Prozent und in Fertigungsbetrieben 

4 Prozent. Die Studie [http://www. 

balabit.com/popular‐prohibited‐activities] ist 

bei Balabit verfügbar. 

Profitieren Sie von: 

aktueller Clustertechnologie 

ISO 27001 zertifiziertem 

Hochsicherheits-Datacenter 

DE-CIX Direktanbindung 

IPv4 und IPv6 Unterstützung 

24/7 Service und Support 

Professionelles Hosting 

Hosting mit persönlichem und 

kompetentem Support. 

Individuelle Hostinglösungen vom 

Server bis zum Clustersystem. Beratung, 

Planung und Service 24/7. 

Für mehr Performance, Sicherheit 

und Verfügbarkeit, jeden Tag, rund um 

die Uhr. 

hostserver.de/hosting 

Managed Hosting 

zertifiziert nach 

ISO 9001 : 2008 

Sündenfall: die Verbotsüberschreitungen der IT-Mitarbeiter aufgeschlüsselt. 

0 30 / 420 200 24 hostserver.de 

Berlin Marburg Frankfurt am Main 



9

Login 

News 

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

KDE-Konferenz Akademy 2012 in Estland 

Die KDE-Entwicklerkonferenz Akademy wird vom 30. Juni bis 

6. Juli in der estnischen Hauptstadt Tallinn stattfinden. Der 

angenommene Vorschlag für den Veranstaltungsort stammt von 

dem 26-jährigen Netzwerkadministratoren Laur Mõtus. Er wird 

die Koordination des lokalen Teams übernehmen, aus Berlin unterstützt 

ihn Claudia Rauch, Business-Managerin des KDE e.V. 

Auf dem KDE-Nachrichtenportal Dot gibt es ein Interview [http:// 

dot.kde.org/2011/11/24/akademy‐2012‐tallinn‐estonia] mit Laur, der über 

seine Motivation, sein Open-Source-Engagement sowie über die 

Stadt Tallinn spricht. 

Datentransfer-Weltrekord 

Physiker des amerikanischen California Institute of Technology 

(Caltech) haben einen neuen Weltrekord in der Disziplin 

Datentransfer aufgestellt. Die neue Rekordmarke liegt nun bei 

kombinierten 186 Gigabit pro Sekunde für eine Datenübertragung 

in zwei Richtungen und übertrifft den alten Rekord aus 

dem Jahr 2009 um rund 50 Prozent. Diese Geschwindigkeit 

würde ausreichen, um pro Tag 100 000 komplette Blu-ray-Discs 

zu transferieren. Der Versuch fand auf der International Conference 

for High Performance Computing, Networking, Storage 

and Analysis, SC11 in Seattle statt. 

Novell veröffentlicht OES 11 

Novell hat den Open Enterprise Server 11 freigegeben, der auf 

dem Suse Linux Enterprise Server 11 SP 1 (SLES) basiert, aber 

mehr Optionen bietet. Insbesondere die File- und Printservices 

wurden ausgebaut, beispielsweise das Apple Filing Protocol 

(AFP), was ihn für gemischte Linux-/Windows-/Mac-Umgebungen 

empfiehlt. Mit der Dynamic Storage Technology ist eine 

Technik an Bord, die seltener genutzte Inhalte auf billigeren 

und langsameren Speicher verschiebt und im Gegenzug häufig 

verwendete Dateien auf schnellen, aber teureren Medien lagert. 

Applikationen, die Microsofts Active Directory für die Authentifizierung 

nutzen, können mit dem OES stattdessen Novells 

eDirectory verwenden. Im Vergleich zum SLES11 wurden außerdem 

die verfügbaren Support-Optionen ausgebaut. 

Zarafa und LPI gemeinsam zertifiziert 

Zarafa und das Linux Professional Institute (LPI) haben bekanntgegeben, 

dass sie ein gemeinsames Trainings- und Zertifizierungsprogramm 

in Benelux, Deutschland, Österreich und 

in der Schweiz starten. Zarafa integriert das Zertifizierungsprogramm 

des LPI, wobei sich Zarafa Certified Engineers offiziell 

auf der Webseite des LPI für ihre LPI-Zertifizierungen anmelden. 

Vom 1. Januar 2012 an ist die Zertifizierung LPIC-1 oder 

alternativ der RHCSA von Red Hat eine Voraussetzung, um 

Zarafa Certified Engineer werden zu können. 

Die Übersicht über Zarafa-Schulungen ist unter [http://www. 

zarafa.com/trainings] verfügbar. Mehr Informationen zur LPIC-1- 

Zertifizierung gibt es unter [http://www.lpi.org/linux‐certifications/ 

programs/lpic‐1]. 

Neustart: OSBF stellt EOS Directory online 

Die Open Source Business Foundation 

(OSBF) hat das überarbeitete Enter prise 

Open Source Directory (EOS) online 

gestellt. Das Webportal soll Anlaufstelle 

rund um Open-Source-Produkte und 

Dienstleistungen für Interessierte aus 

Deutschland, Österreich und der Schweiz 

sein. Unter dem EOS-Dach 

stecken nach Angaben des 

Betreibers OSBF rund 400 

Open-Source-Produkte sowie 

qualifizierte Dienstleister und 

System-Integratoren. 

In der Datenbank landen laut 

OSBF nur Projekte, die ein Expertengremium 

als businesstauglich 

bewertet hat. Michael 

Kienle, der verantwortliche 

Vorstand der OSBF, sagt dazu: 

„Oberstes Ziel war es, Projekte 

und passende Systemintegratoren 

zu identifizieren, 

die häufig vorkommende 

Unternehmensanforderungen 

adressieren. Dabei haben wir nur solche 

Projekte und Produkte in das EOS- 

Directory aufgenommen, die sich schon 

im Markt bewährt haben und ein recht 

vollständiges Feature-Set aufweisen.“ 

Neben der Projektdatenbank ist im überarbeiteten 

EOS-Directory [http://www. 

Das EOS-Directiory hat wieder geöffnet. 

eosdirectory.com] auch ein Blog zu finden. 

Interessierte Anbieter finden dort auch 

Kontaktadressen zur OSBF. Die OSBF 

sucht überdies auch Sponsoren für das 

Verzeichnis. 

Die Open Source Business Foundation 

(OSBF) hatte das Portal im Mai übernommen. 

Ende 2006 gestartet 

und im Jahr 2007 von Optaros 

dann online eingeführt, ging 

das EOS später an den Open- 

Source-Consultant Bruno von 

Rotz, der dem Verzeichnis 

von Open-Source-Projekten 

und ‐Anbietern mit dem „Advisory 

and Expert Board“, ein 

Komitee von Ratgebern und 

Experten zur Seite stellte. Der 

neue Besitzer OSBF hatte im 

Mai angekündigt, das Portal 

zur Anlaufstelle und Informationsplattform 

für den 

deutschsprachigen Raum zu 

machen. 


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

Programm für DFN-CERT-Workshop 2012 

Das Programm des DFN-CERT-Workshops „Sicherheit in vernetzten 

Systemen“ am 21. und 22. Februar 2012 in Hamburg ist 

nun im Netz einsehbar. 

Der 19. DFN-CERT-Workshop wird sich wieder vielen interessanten 

Themen rund um die Computersicherheit zuwenden. 

Angekündigt sind unter anderem Vorträge zur Speicheranalyse 

unter Linux, zu den Risiken von URL-Verkürzungsdiensten, zur 

Sicherheit in HPC-Umgebungen, zum Schutz vor Innentätern in 

Universitätsrechenzentren oder zu Sicherheitsproblemen von 

IPv6 in lokalen Netzen. Das vollständige Programm findet sich 

hier [http://www.dfn‐cert.de/veranstaltungen/workshop.html]. 

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 

End of Life für Debian Lenny naht 

Der Security-Support für die Debian-Release 5.0 alias Lenny 

endet Anfang Februar 2012. Das hat Moritz Mühlenhoff vom 

Security-Team der Linux-Distribution auf dessen Mailingliste 

mitgeteilt. Der End-of-Life-Termin errechnet sich daraus, dass 

die jüngste Debian-Version 6.0 (Squeeze) am 6. Februar 2011 

veröffentlicht wurde, und die Anwender ein Jahr Zeit für das 

Upgrade bekommen. 

Nach dem Stichtag wird es keine neuen Security-Fixes mehr 

geben. Die bis dahin bereitgestellten Ausbesserungen bleiben 

aber über das Security-Repository verfügbar. 

Univention Corporate Server 3.0 fertig 

Die Bremer Firma Univention hat Mitte Dezember die Version 

3.0 ihres Corporate Servers freigegeben. Das auf Debian 

„Squeeze“ 6.0.3 basierende Server-Produkt wurde gegenüber 

der Vorgängerversion in den Bereichen Bedienung, Funktionsund 

Leistungsfähigkeit grundlegend überarbeitet. So wurde 

zum Beispiel die Usability der Univention Management Console 

verbessert. Der Univention Corporate Server (UCS) kann 

nun, dank der Integration von Samba 4, die Aufgaben eines 

Active-Directory-Domänencontrollers übernehmen. Die Virtualisierungstechnologie 

Xen ist nun in Version 4.1 enthalten. Der 

Linux-Hypervisor KVM wird ebenfalls unterstützt und bietet 

Snapshot- und Suspend-Funktionen. Die Monitoringsoftware 

Nagios wurde auf Version 3 aktualisiert. 

Seine Preislisten hat der Hersteller noch nicht aktualisiert. 

Bisher schlägt das UCS-Basissystem inklusive Maintenance 

mit jährlich 290 Euro zu Buche, zuzüglich knapp 26 Euro 

im ersten Jahr beziehungsweise knapp 9 Euro in Folgejahren 

pro Client und Nutzer. Module wie Groupware, Thin Client 

Services, Desktop-Virtualisierung und der Corporate Desktop 

werden separat berechnet. Kunden, die UCS in den letzten zwölf 

Monaten erworben haben und Kunden mit einem laufendem 

Maintenance-Vertrag können ihre Installation kostenlos auf das 

aktuelle UCS-Release aktualisieren. 

Mehr Informationen zum aktuellen Release und einen Ausblick 

auf kommende Neuerungen gibt die Univention-Website. Ein 

ausführlicher Test findet sich in diesem Heft auf S. 80. 


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 

Admin 


11

Login 

Bücher 

Bücher über Shellprogrammierung und zu Wordpress 3 

Vorgelesen 

In diesem Monat unter der Leselupe: ein enzyklopädischer Ratgeber zur 

Shellprogrammierung und ein umfassendes Handbuch zur Blogging-Software 

Wordpress. Jens-Christoph Brendel, Oliver Frommel 

Was als Erstes ins Auge fällt ist der 

enorme Umfang: Patrick Ditchens Buch 

über Shell-Skript-Programmierung ist mit 

über 820 Seiten ein kiloschwerer Wälzer. 

Das liegt zum einen an der gründlichen 

und systematischen Herangehensweise 

und den ausführlichen Erklärungen, die 

auch ohne Vorbildung verständlich sind. 

Zum anderen ist es aber auch das Resultat 

einer eher ärgerlichen Redundanz. 

Eine Kostprobe: S. 25: „Enthält eine 

Zeichenkette Leer- oder Sonderzeichen, 

muss sie in Anführungszeichen eingeschlossen 

werden.“ S. 51: „Zeichenketten, 

die Leer- oder Sonderzeichen enthalten, 

müssen Sie in Anführungszeichen schreiben.“ 

S. 53: „Strings, die Leerzeichen 

oder Sonderzeichen enthalten, müssen 

Sie in Quotes setzen.“ S. 296: „Zeichenketten, 

die Leer- und Sonderzeichen enthalten, 

müssen in Anführungszeichen 

gesetzt werden.“ S. 298: „Sobald in einer 

Zeichenkette Leerzeichen oder Sonderzeichen 

enthalten sind, muss sie in Anführungszeichen 

gesetzt werden.“ Und 

das sind nur die Fundstellen, die beim 

ersten Überfliegen ins Auge sprangen. 

Das Buch führt in grundlegende Programmierkonzepte 

und die Syntax von Bourne- 

Shell, Bash und Korn-Shell ein. Dabei 

berücksichtigt es sowohl die Verhältnisse 

unter Solaris wie unter Linux und deckt 

damit ein breites Anwendungsgebiet ab. 

Außerdem werden die wichtigsten Tools 

besprochen, die Shellprogrammierer häufig 

einsetzen: etwa sed, grep und in einem 

eigenen ausführlichen Kapitel awk. 

Zahlreiche Beispiele im dritten Teil des 

Werkes liefern nützliches Anschauungsmaterial. 

Trotz der Materialfülle gelingt es jedoch 

nicht, das Thema erschöpfend zu behandeln. 

Vergeblich sucht man beispielsweise 

ein Kapitel über die oft vernachlässigte 

Sicherheit von Shell-Skripten. 

„Sicherheit“ oder „Security“ sind nicht 

mal einen Eintrag im Index wert. 

Wordpress 

Wordpress hat sich in den letzten Jahren 

vom einfachen Blog-System zum ausgewachsenen 

Content-Management-System 

entwickelt. Zwar dreht es sich im Kern 

noch immer um eine Blog-Struktur mit 

Artikeln und festen Seiten. Über 10 000 

Plugins machen es aber mittlerweile 

vielfältig verwendbar, etwa zum Aufbau 

eines eigenen Webshops, von News-Sites 

und vieles mehr. 

Alexander Hetzel hat zu Wordpress 3 nun 

ein Buch verfasst, das der Galileo-Verlag 

als „umfassendes Handbuch“ vermarktet. 

Diesem Titel und dem im Vorwort 

formulierten Anspruch, eine möglichst 

breite Zielgruppe zu erreichen, wird es 

gerecht. Es beginnt bei der Installation 

und schließt dabei das Aufsetzen einer 

PHP/Apache/MySQL-Umgebung unter 

Windows ein. Lediglich etwas mehr Informationen 

über die Installation unter 

Linux, was etwa bei einem Internet-Provider 

meist die Regel ist, wären wünschenswert. 

Ausführlich widmet sich der Autor dann 

der Administration von Wordpress über 

die Weboberfläche, bevor er zu fortgeschrittenen 

Themen wie der Programmierung 

eigener Themes und Plugins 

kommt. Eine kurze Übersicht wichtiger 

und nützlicher fertiger Plugins hilft Nicht- 

Programmierern. Auch ein Kapitel über 

die Absicherung des gelegentlich durch 

Sicherheitslücken auf sich aufmerksam 

machenden Wordpress ist enthalten. Auf 

knapp zehn Seiten deckt es immerhin die 

wichtigsten Maßnahmen ab. Für fortgeschrittene 

Administratoren gibt es hier 

sicher noch unerwähntes Potenzial, etwa 

zur Härtung des Betriebssystems. 

„Wordpress 3“ ist empfehlenswert für 

jeden, der mit dem Gedanken spielt, 

eine dynamische Website aufzubauen. 

Es deckt alle Aspekte rund um Wordpress 

ab, von der Installation, Verwaltung und 

Bedienung bis hin zur Entwicklung eigener 

Plugins und Themes. Allgemeine Kapitel 

zu Vermarktung, Benutzer-Tracking 

und Suchmaschinenoptimierung runden 

den Allzweck-Ratgeber ab. Am nützlichsten 

ist es somit für denjenigen, der selbst 

eine Wordpress-basierte Website installieren 

und sie dann auch regelmäßig mit 

Inhalt füllen will. 

Das Buch beschäftigt basiert auf der eben 

erschienenen Wordpress-Version 3.2 und 

dürfte somit noch einige Zeit lang Gültigkeit 

besitzen. 

n 

Shell-Skript-Programmierung 

Patrick Ditchen 

Shell-Skript-Programmierung 

832 Seiten 

4. Auflage 

mitp 2011 

44,95 Euro 

ISBN 978-3-8266-9134-8 

Wordpress 3 

Alexander Hetzel 

Wordpress 3 

597 Seiten 

Galileo Press 2012 

29,90 Euro 

ISBN 978-3-8362-1727-9 


„Kennen Sie 

unser Thomas 

Krenn Wiki?“ 

Schauen Sie doch mal in unserem Thomas Krenn Wiki vorbei. 

Hier finden Sie die neuesten Beiträge zu DDR-SDRAM und vieles mehr! 

Werner Fischer, 

Technical Specialist 

MEHR ALS NUR EIN WIKI 

• IT Know-how der Server-Experten 

• Konkrete Problemlösungen 

• Über 700 Artikel und Hintergrundinfos 

zu Servertechnologien 

• Installations- und Konfigurationsanleitungen 

Beiträge unserer Experten unter: 

www.thomas-krenn.com/tk_wiki 

Thomas Krenn steht für Server made in Germany. Wir 

assemblieren und liefern europaweit innerhalb von 24 

Stunden. Unter www.thomas-krenn.com können Sie 

Ihre Server individuell konfi gurieren. 

Unsere Experten sind rund um die Uhr für Sie unter 

+49 (0) 8551 9150-0 erreichbar 

(CH: +41 (0) 848207970, AT +43 (0) 7282 20797-3600) 

Made in Germany! 

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

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

Login 

Admin-Story 

© Pedro Antonio SalaverrÃ a Calahorra, 123RF 

Aus dem Tagebuch eines IT-Nomaden 

Geflickt 

Das neue Spielzeug liegt auf dem Tisch, nur leider funktioniert es mit der 

aktuell eingesetzten Linux-Distribution nicht. Was tun? Ein eigenes RPM- 

Paket bringt die passende Software auf den Rechner. Die neueste Folge 

der Admin-Story verrät, wie das geht. Thorsten Scherf 

Am Ende wurde auch ich ein Opfer des 

Marketings und entschloss mich, mir ein 

iPad zuzulegen. Ein paar Leute werden 

jetzt sicherlich den Kopf schütteln und 

fragen, wieso es denn ausgerechnet ein 

Apple-Produkt sein musste, schließlich 

gibt es auch sehr nette Tablets mit Android. 

Um mich nicht in endlose Diskussionen 

zu verstricken – die habe ich bereits 

hinter mir – stelle ich den Kauf einfach 

mal als Fakt dar. 

Da ich sehr viel unterwegs bin, habe ich 

das Tablet meistens bei mir und nutze es 

oft, um Fotos direkt ins Netz oder auf den 

Computer zu übertragen. Das klappt mit 

iOS-Geräten, dank Libimobiledevice [1], 

auch ganz hervorragend. Mit der Library 

ist es problemlos möglich, alle Arten von 

Media-Dateien zwischen dem Tablet und 

Linux-Geräten zu synchronisieren, sogar 

die Aktivierung von iPhones funktioniert 

damit reibungslos. 

Vor einiger Zeit war es wieder so weit, 

es hatten sich jede Menge Bilder und 

Podcasts auf dem iPad angesammelt, und 

ich wollte diese gerne auf mein Desktop- 

System übertragen. Für die Bilder benutze 

ich Shotwell, bei Audiodateien hat 

sich Banshee bewährt. Beide Tools sind 

mittels Libimobiledevice in der Lage, die 

Dateien vom Tablet zu synchronisieren 

und zu verwalten. Nach dem Anschluss 

des Gerätes werde ich diesmal jedoch bitterlich 

enttäuscht. Nautilus meldet, dass 

es Probleme beim Einbinden des Gerätes 

gibt. Auch manuelle Versuche führen 

nicht zum gewünschten Erfolg. Was war 

geschehen? Ein schneller Blick in das 

Libimobiledevice-Forum bestätigt meinen 

Verdacht: Das kurz zuvor durchgeführte 

Update auf iOS 5 war schuld. 

Bei einem kurzen Zwischenstop im IRC- 

Kanal der Software bestätigen mir die 

Entwickler, dass das Git-Repository zwar 

schon Patches für iOS 5 enthält, diese 

aber noch nicht als Teil einer Archiv- 

Datei, geschweige denn in Form eines 

fertigen Installationspaketes verfügbar 

sind. Soll ich etwa so lange warten, bis 

die Maintainer des entsprechenden RPM- 

Paktes die Patches einbauen oder lieber 

selbst aktiv werden und ein eigenes Paket 

bauen? 

Ersteres hätte den Vorteil, dass ich nicht 

in der Paketverwaltung meines Systems 

herumfusche und eventuelle Probleme 

beim nächsten Paket-Update provoziere, 

allerdings könnte ich dann nicht mehr 

auf mein Tablet zugreifen und müsste 

so lange warten, bis ein neues Paket mit 

den notwendigen Patches zur Verfügung 

steht. So lange will ich jedoch nicht warten 

und entschließe mich doch, ein eigenes 

Paket zu bauen. 

Ausgecheckt 

Libimobiledevice setzt als Versionskontrollsystem 

Git ein. Um an die aktuellen 

Patches zu kommen, ist es am einfachsten, 

sich den kompletten Source-Baum 

aus dem Git-Repository des Projektes 

zu laden. Natürlich darf auch Rpmbuild 

nicht fehlen. Wenn die nötigen Entwicklungswerkzeuge 

und Bibliotheken auf einem 

Fedora-System noch fehlen, hilft der 

Aufruf von »yum groupinstall Development 

Libraries Development Tools« wei- 


Admin-Story 

Login 

ter. Wer erst einmal nachsehen möchte, 

welche Software er sich auf das eigene 

System holt, dem sei die Yum-Option 

»groupinfo« ans Herz gelegt. 

Bevor es ans Bauen eines neuen RPM- 

Paketes geht, ist zuerst das aktuellste 

Source-Paket aus dem Respository der 

Distribution zu laden: 

yumdownloader ‐‐source libimobiledevice 

Mittels »rpm ‐i libimobiledevice*.rpm« 

packt RPM das Paket aus und speichert 

die Source Dateien unterhalb von 

»~/rpmbuild/SOURCES«. Das Specfile, 

also der Bauplan für das Paket, liegt 

in »~/rpmbuild/SPECS«. Im Specfile 

findet sich ein Hinweis darauf, welche 

Version der Software in dem Paket zum 

Einsatz kommt, in diesem Fall ist es die 

Version 1.1.1. 

Parallel zu den Sourcen des RPM-Paketes, 

sind nun ebenfalls die aktuellen Sourcen 

aus dem Git-Repository des Software notwendig, 

schließlich suche ich die aktuellen 

Patches, um mein iOS-5-Problem zu 

beheben. Mittels Git hole ich diese also 

auf meinen eigenen Rechner: 

git clone git://git.sukimashita.com/U 

libimobiledevice.git 

Hierdurch entsteht der Unterordner 

»libimobiledevice«, in dem sich die 

Quellcode-Dateien befinden. Mit ein 

bisschen Git-Kung-Fu erhält man schnell 

einen Überblick über das Projekt. Mittels 

»git tag ‐l« zeigt Git beispielsweise die 

bekannten Tags auf. Das sind einfache 

Label, mit denen man auf bestimmte 

Snapshots der Software zurückgreifen 

kann. Tags werden gerne eingesetzt, um 

Release-Stände mit einem Label zu versehen. 

Das letzte Tag lautet 1.1.1, das 

deutet also darauf hin, dass dies wirklich 

das letzte Release der Software war. Das 

letzte verfügbare Tar-Archiv auf der Webseite 

trägt ebenfalls diese Versionsnummer. 

Jedoch heißt dies natürlich nicht, 

dass die Entwicklung seitdem stillsteht. 

Der folgende Git-Aufruf bestätigt, dass 

seit dem 1.1.1-Release einiges im Repository 

los war (Listing 1). 

Es wurden also 51 Zeilen im Programmcode 

hinzugefügt und 34 entfernt, das 

Ganze verteilt auf sieben Dateien. Mich 

interessieren natürlich die Commit-Messages, 

die jede Änderung dokumentieren 

(Listing 2). 

Das sieht doch sehr vielversprechend 

aus: Gleich zwei Patches enthalten einen 

Hinweis auf iOS-5-spezische Änderungen 

(Zeilen 2 und 6). Die will ich haben. Da 

es nichts schaden kann, auch die anderen 

Patches mit in mein eigenes Paket aufzunehmen, 

schreibe ich alle verfügbaren 

Änderungen in eine Patchdatei. Das geht 

mit einem Aufruf von 

git diff 1.1.1..HEAD > ~/rpmbuild/U 

SOURCES/ios5.patch 

Bevor ich weitermache, schaue ich mir jedoch 

erst einmal die Änderungen an. Da 

keine bösen Überraschungen zu erwarten 

sind, editiere ich das zuvor heruntergeladene 

Specfile von Libimobiledevice und 

führe die Patch-Datei in der Preamble 

mittels »Patch1: ios5.patch« auf. 

Paketbau 

In der »prep«-Sektion sorgt die Anweisung 

»%patch1 ‐p1« dafür, dass die Patches 

auch wirklich auf die Quellen der 

Software angewendet werden und die 

Änderungen nach dem Bauen des Paketes 

zur Verfügung stehen. Das klappt 

übrigens ohne große Probleme mittels: 

rpmbuild ‐bb ~/rpmbuild/SPECS/U 

libimobiledevice.spec 

Vor dem Aufruf ist es erst einmal notwendig, 

die Release-Nummer im Specfile zu 

erhöhen, damit der RPM-Paketmanager 

das Paket auch wirklich als Update erkennt. 

Mit dem so erzeugten Paket aktualisiere 

ich schließlich mein System 

per »yum update libimobiledevice«. Die 

Listing 2: Kommentare 

01 # git log ‐‐pretty=one 1.1.1..HEAD 

Spannung steigt, als ich mein iPAD erneut 

an den Rechner anschließe. 

Anschluss 

Wie erhofft, meldet Nautilus nun, dass 

ein neues Gerät gefunden wurde und 

hängt es auch gleich ein. Der Zugriff 

auf meine Media-Dateien ist nun wieder 

ohne Prob leme möglich. Auch meine 

Frau freut sich, hat sie ihren Mac nun 

wieder ganz für sich allein, ohne ständig 

von jemandem genervt zu werden, der 

mal eben sein Tablet syncen will. (ofr) n 

Infos 

[1] Libimobiledevice: 

[http:// www. libimobiledevice. org] 

Der Autor 

Thorsten Scherf arbeitet als Senior Consultant 

für Red Hat EMEA. Er ist oft als Vortragender 

auf Konferenzen anzutreffen. Wenn ihm neben 

der Arbeit und Familie noch Zeit bleibt, nimmt er 

gerne an Marathonläufen teil. 

Listing 1: Repository-Status 

01 # git diff 1.1.1..HEAD ‐‐stat 

02 configure.ac | 2 +‐ 

03 src/idevice.c | 17 +++‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 

04 src/lockdown.c | 31 

+++++++++++++++++++++++‐‐‐‐‐‐‐‐ 

05 src/notification_proxy.c | 4 +++‐ 

06 tools/idevicebackup2.c | 18 

+++++++++++++‐‐‐‐‐ 

07 tools/ideviceimagemounter.c | 1 ‐ 

08 tools/ideviceinfo.c | 12 ++++++++‐‐‐‐ 

09 7 files changed, 51 insertions(+), 34 deletions(‐) 

02 e855f246b3d869a60375207fde1294bbe761fe23 lockdown: iOS 5: handle 'Error' key in lockdown_check_result 

03 d2db9b97b0487e3e0c65cca0e0dd02a747a61113 Fix memory leak in idevice_device_list_free 

04 d51431edc3987cb9e595fdec874cdf869935d21d idevicebackup2: plug another memory leak 

05 c90fc4c934ac7b024c1fc1813bb3cffb5333e18f lockdown: move writing of device uuid to client struct inside 

lockdownd_client_new() 

06 f0487376671ffd6ac3fc121657f1fbd0acea3cb0 lockdown: fix support for iOS 5 

07 f8f3f299a56aeccce1b978fed7620137f7072518 idevicebackup2: plug a small memory leak 

08 ceae1d897597c66c19c2ed30b3049ce09db78233 ideviceimagemounter: remove bogus g_free() 

09 565b5901d666de3bfe538be27aebb9f443de98f0 notification_proxy: use free() instead of g_free() 

10 5c10f12e408b11afbd7c3cc93ddf7d85f1527417 ideviceinfo: fix possible segmentation fault when parsing 

empty data nodes 

11 27d0da3bc196d28c1095e7c74054f5a6efb7ccf2 idevicebackup2: fix restore command option handling 

12 f20cf2b4f14b66f38984e21dbed41da27c03e23a idevicebackup2: Add typedef for GStatBuf for backwards 

compatibility 

13 6dccecddf012a0a404d121cc2c42ddce7c485fb7 Remove deprecated gnutls_*_set_priority() and use gnutls_ 

priority_set_direct() 


Admin 


15

Login 

Leserbriefe 

Leser-Feedback 

Leserbriefe 

Haben Sie Anregungen, Kritik oder Kommentare? Dann schreiben Sie 

an [leserbriefe@admin‐magazin.de]. Die Redaktion behält es sich vor, die 

zuschriften und Leserbriefe zu kürzen. Sie veröffentlicht alle Beiträge 

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

alexwhite, 123RF 

Datenbankvergleich 

06/2011, S. 40: Bei den Benchmarks der 

von PostgreSQL und MySQL ist einiges 

unklar: Zum einen sollte man immer die 

Rahmenbedingungen angeben: Auf welcher 

Hardware liefen die Benchmarks, 

war es identische Hardware, welches OS, 

welcher Kernel und welches Dateisystem 

wurden genutzt? Gab es ein RAID? Ist 

es ein reiner SQL-Server? Und liegen die 

Daten auf verschiedenen Platten/Partitionen? 

Warum wurde nicht die Mount- 

Option »noatime« gesetzt? Desweiteren 

war der Benchmark relativ einseitig, da 

es überwiegend DML (Update, Insert, 

Delete) war. Jedoch hätten Sie auch 

DQL(Select)-Abfragen nehmen sollen. 

Grafikkarten testet man ja auch nicht 

nur mit einem Benchmark. 

In der vorigen Ausgabe vergleichen Sie im 

PostgreSQL-Artikel ein 20-Disk-RAID10- 

Array mit einer SSD. Finden sie nicht, 

dass der Vergleich etwas hinkt? Ein fairer 

Vergleich wäre gewesen, entweder gleich 

viele Platten zu nehmen oder soviele zu 

verwenden, dass der gleiche Preis dabei 

herauskommt. 

Stefan Krüger (auf Google+) 

Beim Datenbank-Benchmark ist die Hardware 

auf S. 42, erste Spalte unten, klar 

beschrieben und es steht auch unzweideutig 

da, dass alle Messungen auf derselben 

Hardware liefen. In diesem Punkt kann 

ich die Kritik nicht nachvollziehen. 

Der Benchmark deckt nur einen bestimmten 

Aspekt ab, im vorliegenden Fall nur 

einen OLTP-Workload. Selbstverständlich 

gibt es auch andere Aspekte, die man 

Für Kommentare und Anregungen können Sie mit der Redaktion auch über die Facebook-Seite in Kontakt 

treten, die Sie unter [http://www.facebook.com/adminmagazin] finden. 

testen könnte, nur ist es leider unmöglich 

alle denkbaren Szenarien in einem einzigen 

Artikel unterzubringen. 

Der Vergleich verschiedener Disk-Arrays 

mit einer SSD in Heft 5 ist auch nicht 

unfair, sondern aus meiner Sicht recht 

erhellend. Aus Kostengründen bildet man 

nun mal normalerweise keine Arrays mit 

20 SSDs, sondern nimmt dafür in der 

Regel die vergleichsweise billigen Festplatten. 

Diese Variante hat ihre Vorteile – und 

SSDs haben andere Vorteile. Das arbeitet 

der Beitrag klar heraus, sodass man sich 

in jeder Situation für die optimale Lösung 

entscheiden kann. (Jens-Christoph 

Brendel) 

Archipel 

06/2011, S. 62: Die Virtualisierungs-GUI 

Archipel macht zwar optisch einen guten 

Eindruck, aber wieder einmal handelt 

es sich nur um Beta-Software, die sich 

für den praktischen Einsatz kaum eignet. 

Warum gibt es immer wieder Tests von 

offensichtlich unausgegorenen Programmen? 

Martin Binser (per E-Mail) 

In den Anwendungsfeldern Virtualisierung 

und Cloud Computing vollzieht sich 

die Entwicklung in rasender Geschwindigkeit. 

Das ADMIN-Magazin versucht 

deshalb, seine Leserinnen und Leser 

auch über interessante Projekte auf dem 

Laufenden zu halten, die noch nicht völlig 

ausgereift sind. Daneben nehmen wir 

selbstverständlich auch immer wieder 

bewährte und stabile Software unter die 

Lupe. (Oliver Frommel) 

n 

@ leserbriefe@admin-magazin.de 

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


NUR 3,56€ * 

pro vServer in der Customer Cloud 

Endlich mit der Cloud 

mal richtig sparen! 

Die Private Cloud, die sich jedes Unternehmen leisten kann. Sparen Sie Ressourcen, 

Manpower und Budget: Ab 15,45 €* pro Monat können Sie sich Ihre eigene Virtual- Core® 

Customer Cloud ins Unternehmen holen. Gestalten Sie Ihre IT-Infrastruktur durch eine 

moderne und intelligente Virtualisierung so flexibel wie noch nie! 

Jetzt: 6 Monate kostenlos testen unter www.virtual-core.de 

* Preise inkl. MwSt. 

Virtual-Core® ist eine eingetragene Marke der Firma KAMP Netzwerkdienste GmbH – www.kamp.de

Login 

Think Twice 

Warum müssen Open-Source-Programmierer ständig das Rad neu erfinden? 

Vergebliche 

Liebesmüh 

Braucht die Menschheit wirklich 315 Linux-Distributionen? Die ewige Neuerfindung des Gleichen wird gerne als 

Vorzug der Open-Source-Welt gepriesen. Tatsächlich führt sie aber nur zu einem Wildwuchs unausgegorener 

Software. Oliver Frommel 

Als im letzten ADMIN-Heft mein Kollege 

Brendel die Vielfalt an Open-Source- 

Software lobte, war ich, vorsichtig gesagt, 

etwas überrascht. Denn der Schwerpunkt 

dieses Heftes zeigt, wohin das führt: Mehr 

als ein Dutzend Ableger des Monitoring- 

Paketes Nagios gibt es mittlerweile, da 

drängt sich doch schnell die Frage auf, 

wem dieses Chaos nützen soll. 

Heute existieren über 300 Linux-Distributionen 

mit mindestens vier verschiedenen 

Paketmanagement-Systemen [1]. 

Neuerdings fangen die Linux-Entwickler 

an, verschiedene Init-Systeme wie System-V, 

Upstart, Systemd und so weiter zu 

verwenden. Jetzt muss sogar ein neues 

Logging-Subsystem her, meint Lennart 

Poettering, der sich schon durch die Neuerfindung 

von Linux-Audio per Pulseaudio 

einen Namen gemacht hat. 

Natürlich haben Hersteller und Systemhäuser 

Interesse daran, Geld zu verdienen. 

Da mag es naheliegen, sich ein 

freies Software-Paket zu nehmen, es ein 

bisschen anzupassen und dann mit dem 

eigenen Stempel zu versehen. Doch auch 

sonst scheint die Neigung weit verbreitet 

zu sein, einen Fork oder gleich ein komplett 

neues Projekt zu starten. Prinzipiell 

gibt es dagegen wenig zu sagen, schließlich 

leben wir in einem freien Land, und 

jeder kann mit seiner Zeit anfangen, was 

er will. Wer beispielsweise anfängt, das 

Programmieren zu lernen, findet nur 

schwer ein Anwendungsfeld, das noch 

gänzlich unberührt ist. Außerdem 

ist es für Anfänger fruchtbar, ein 

Projekt von Grund auf zu entwickeln 

– auch wenn es Vergleichbares 

schon gibt. 

Not Invented Here 

© Igor Zakowski, 123RF 

Jenseits solcher Fälle neigen 

aber auch gestandene Programmierer 

bei freien und 

kommerziellen Linux-Distributionen 

dazu, Dinge zu programmieren, 

die es eigentlich 

schon gibt. Oft drängt sich der 

Eindruck auf, der Grund dafür sei 

einfach, dass das Bestehende von 

jemand gemacht wurde, der nicht 

zum eigenen Team gehört. Im englischsprachigen 

Raum ist das als „Not 

Invented Here“ (NIH) bekannt: Wenn es 

nicht von uns ist, muss es schlecht sein, 

also neu gemacht werden. Dabei läge 

der Sinn von freier Software doch eher 

darin, gemeinsam an einem Projekt zu 

arbeiten, Fehler zu finden, zu beheben 

18 Admin www.admin-magazin.de

und es damit Stück für Stück ein bisschen 

besser zu machen. Vorbilder dafür finden 

sich im Bestand der GNU-Software, etwa 

der GNU-Compiler, der Editor Emacs und 

der zahllosen Bibliotheken und kleinen 

Tools, die teilweise mehr als 20 Jahre alt 

und entsprechend ausgereift sind. 

Heute hat sich die Situation umgekehrt: 

Kleinste Unstimmigkeiten führen sofort 

zur Neugründung eines Projektes, wie 

man es etwa bei Google beobachten kann, 

das sich das Motto „Don’t be evil“ auf 

die Fahnen geschrieben hat. Existierende 

Open-Source-Webbrowser wie Firefox 

waren nicht gut genug, also musste das 

eigene Chrome her. Betriebssysteme für 

Mobiltelefone gab es ebenfalls schon als 

freie Software, sogar auf Linux basierend, 

doch Google wollte lieber Android 

neu erfinden, einschließlich einer neuen 

Runtime-Umgebung, die aber Java doch 

so ähnlich ist, dass Google nun darüber 

mit Oracle im Patentstreit liegt. 

Neuerfinder Google 

Seit Neuestem stößt sich Google auch 

an Javascript, das mittlerweile auf eine 

mehr als 10-jährige Geschichte mit entsprechend 

ausgereiften Tools, Standardisierung 

durch die ECMA und Know-how 

von Entwicklern zurückblicken kann. 

Jetzt soll es die Neuerfindung „Dart“ richten, 

denn schließlich leistet man sich mit 

Milliardenbudget nicht umsonst Sprachentwickler 

wie Gilad Bracha. Dass Dart 

[2] sich wieder nur minimal von anderen 

Programmiersprachen unterscheidet, 

muss nicht stören. Vermutlich lassen sich 

die anstehenden Probleme eines Web 3.0 

nur damit lösen. Die ebenfalls schon bei 

Google von Rob Pike und Ken Thompson 

entwickelte Programmiersprache Go fristet 

derweil ein Nischendasein. 

Vom Ubuntu-Hersteller Canonical erreicht 

uns die Nachricht, man verabschiede 

sich demnächst von der NoSQL- 

Datenbank CouchDB, weil diese nicht 

wie gewünscht skaliere. Man rechne für 

den eigenen Subskriptionsdienst Ubuntu 

One mit einem Wachstum bis zu Millionen 

Benutzern, und das könne CouchDB 

nicht stemmen. Die Lösung für das Problem 

sieht Canonical aber nicht etwa darin, 

eine der mehr als 20 existierenden 

NoSQL-Datenbanken auf dem Markt 

oder eine gute alte SQL-Datenbank mit 

Sharding (verteilt über viele Rechner) zu 

verwenden. Damit kommen zwar Top- 

Ten-Websites wie Twitter und Facebook 

zurecht, bei Canonical soll es aber lieber 

eine Eigenentwicklung mit dem Arbeitstitel 

U1DB richten. 

Was bringt es? 

Die Vorteile der chaotischen Entwicklung 

sind fragwürdig. Natürlich müssen 

gelegentlich Pakete oder Subsysteme 

komplett erneuert werden, sonst gäbe 

es keinen technischen Fortschritt. Andererseits 

ist die Schrotflintenmethode 

auch dafür nur eingeschränkt geeignet: 

Jeder entwickelt munter vor sich hin, 

und irgendwann wird sich schon zeigen, 

was brauchbar ist. Problematisch wird 

dieses Verhalten dann, wenn es sich, wie 

etwa in der Linux-Welt, auf den Zustand 

des Gesamtsystems auswirkt. Zu viel Zersplitterung 

wird zur Zumutung für den 

Anwender oder Administrator, der sich 

einem riesigen Angebot gegenübersieht, 

aus dem er auswählen muss. Gleichzeitig 

leidet die Kompatibilität von Systemen 

wie Ubuntu und Red Hat immer mehr: 

Nicht nur das Paketmanagement unterscheidet 

sich, auch für das Init-System 

oder den Bootloader muss der Administrator 

komplett umlernen. 

Kollege Brendel führt im letzten ADMIN- 

Heft als Vorteil die Auswahl an, die dem 

Anwender durch die Vielzahl an Software 

für den gleichen Zweck zu Verfügung 

steht. Meistens ist die große Auswahl 

aber eher Bürde als Chance. Wie soll 

denn ein Anwender aus den 40 Monitoring-Systemen 

auswählen, die es auf dem 

freien und kommerziellen Markt gibt?! 

Der Psychologe Barry Schwartz hat in 

seinem Buch „The Paradox of Choice – 

Why More is Less“ dargelegt, wieso ein 

Überangebot die Unzufriedenheit steigert. 

Wenigstens für die IT-Magazine und 

‐Websites hat die Sache ein Gutes, so 

lässt sich sarkastisch anfügen: Solange 

der Wildwuchs an freier Software weitergeht, 

gibt es für uns etwas zu schreiben. 

 

n 

Infos 

[1] Linux-Distributionen: [http:// distrowatch. 

com/ dwres. php? resource=popularity] 

[2] Dart: [http:// www. dartlang. org] 

& 



19

Login 

OSMC 

Notizen von der vierten Open Source Monitoring Conference (OSMC) 


à la mode 

Die OSMC ist mittlerweile ein fixer Termin im Kalender vieler Admins, die sich mit Überwachung von Soft- und 

Hardware auseinandersetzen. Auch in diesem Jahr führte die vom Nürnberger IT-Dienstleister Netways GmbH 

ausgerichtete Veranstaltung wieder viele Experten nach Franken. Jens-Christoph Brendel 

Abbildung 1: Olivier Jan während seines Vortrags „Monitoring solutions for the next decade“ auf der OSMC. 

Gute Ideen setzen sich durch. Das 

konnte man nicht zuletzt während der 

vierten Ausgabe der bewährten Nürnberger 

Monitoring-Konferenz bestätigt 

finden: Verteiltes Monitoring, Geschäftsprozessüberwachung, 

moderne Benutzeroberflächen 

– das sind nur einige der 

Trends, die sich nach und nach in jeder 

der verschiedenen Überwachungslösungen 

durchsetzen und deshalb in vielen 

Referaten auftauchten. 

Geteilte Last ist halbe Last 

Beispiel Lastverteilung: Eine einzelne 

Instanz für das Starten der Checks und 

die Verarbeitung der Rückgaben funktioniert 

in kleinen und mittleren Umgebungen 

tadellos. Muss man aber sehr 

viele Hosts überwachen – das haben 

viele schmerzlich mit dem klassischen 

Nagios gelernt – gelangt man mit dieser 

Architektur an eine Grenze. Moderne 

Entwicklungen wie etwa Shinken setzen 

deshalb von vornherein auf Lastverteilung: 

Jede der grundlegenden Aufgaben 

wie das Auslösen der Checks, das Abarbeiten 

von Plugins, die Benutzerbenachrichtigung 

und das Event-Handling oder 

die Rückgabeverarbeitung können hier 

auf jeweils beliebig viele Instanzen verteilt 

werden. Damit bewältigt Shinken in 

Benchmarks viermal so viele Checks wie 

der originale Nagios Core. 

OpenNMS konnte Ähnliches schon immer. 

Zumindest für das Scheduling von 

Checks rüstet mod_gearman das im klassischen 

Nagios nach, und auch Icinga hat 

ein solches Konzept zumindest in der 

Schublade. Dort soll Zero-MQ das künftige 

Fundament verteilter Verarbeitung 

bilden (Abbildung 1). 

Beispiel Geschäftsprozessüberwachung. 

Den Boss interessiert die Nummer des 

streikenden Routerports nicht, wohl 

aber welche Konsequenzen der Ausfall 

für Kunden und Mitarbeiter hat. Schon 

vor Jahren kam man darauf, das Nagios 

alleine mit seiner technisch orientierten 

Darstellung dem ungenügend gerecht 

wird. Seitdem blühen die Business Process 

Plugins. Allen voran das Business 

Process AddOn von Bernd Strößenreuther 

für Nagios, das jetzt mit seiner Hilfe noch 

tiefer in Incinga integriert werden soll. 

Aber auch Shinken verfügt seit Jahresanfang 

über ein ähnliches Regelwerk. 

Nun wartet auch Check_MK mit einer 

eigenen Implementation auf. Die großen 

kommerziellen Suiten konnten das eh 

schon länger. 

Beispiel moderne GUI. Hier geht es längst 

nicht mehr nur um ein paar Kurven für 

Messwerte-Zeitreihen. Dashboards mit 

frei anordenbaren Widgets sind state of 

the art. Icinga hat hier viele neue Ideen 

zu bieten, aber auch die Mitbewerber 

schlafen nicht: Ableger wie Centreon, 

Opsview oder OP5 hatten sich schon länger 

vom klassischen Nagios-Look&Feel 

gelöst, aber auch Check_MK fällt einem 

hier wieder ein. 

Gut ins Bild gesetzt 

Einen so umfassenden projektübergreifenden 

Überblick wie auf der OSMC 

erhält man anders nicht so leicht. Und 

die perfekte Organisation, das freundliche 

Tagungshotel oder der gemeinsame 

Abend in einer anregenden Location versüßen 

einem den Aufenthalt in Nürnberg 

zusätzlich. 

n 


Europe’s No.1 

Information Security Event 

SECURE THE FUTURE OF YOUR BUSINESS ASSETS, 

WHERE IT MATTERS 

>> Stay connected to your peers and network face-to-face 

>> Clearly navigate and understand increasingly complex legislation 

>> Keep up-to-date with the latest product and service solutions showcased 

at the event 

>> Source new suppliers 

>> Access thought-leading content through the extensive education 

programme 

For more information visit www.infosec.co.uk. If you are interested in 

exhibiting call +44 (0) 20 8910 7718/7991/7047 

or for US companies +1 203 840 5821 

Organised by: 

® 

24-26 April 2012 

Earls Court, London UK 

infosec.co.uk

Login 

Softwareschutz 

© braverabbit, 123RF 

Das gilt für Programme und Programmiersprachen 

Wann Software 

unter Schutz steht 

Darf man fremde Software ändern, wenn sie auch Open-Source-Code 

enthält? Wann ist Software patentierbar? Dieser Beitrag berichtet über 

die aktuelle Rechtsprechung und versucht, etwas Licht in das komplexe 

Softwarerecht zu bringen. Vilma Niclas 

Es ist nicht in jedem Fall verboten, 

fremde Software zu ändern. Stattdessen 

kann das zum einen erlaubt sein, wenn 

die Ursprungssoftware Open-Source- 

Komponenten enthält und insgesamt 

unter die GPL fällt. Zum anderen ist das 

aber auch deshalb erlaubt, weil die fragliche 

Software erst gar nicht urheberrechtlich 

geschützt ist. 

AVM, Hersteller des DSL-Routers Fritzbox, 

hatte die Cybits AG verklagt, die 

die Jugendschutzsoftware Surfsitter 

DSL vertreibt. Das Programm nutzt die 

Fritzbox als Plattform, rief zunächst die 

Original-Firmware auf und modifizierte 

sie dann so, dass einige Funktionen der 

Fritzbox deaktiviert wurden, was Nachteile 

mit sich brachte. Der Nutzer sah 

dadurch aber beispielsweise trotz aktivem 

Internetzugang die Statusmeldung 

„Nicht verbunden“. Zudem wurde die 

Original-Kinderschutzfunktion fälschlicherweise 

als aktiv bezeichnet und die 

Firewall deaktiviert. Neben der Fritzbox-Oberfläche 

erschien eine Surfsitter- 

Benutzeroberfläche. 

Rufschädigend 

AVM sah dies als eine nicht bestimmungsgemäße 

Nutzung der Firmware 

und wollte es unterbinden, denn viele 

Kunden hätten sich beim Support von 

AVM beschwert, da angeblich die Software 

nicht mehr richtig funktioniere. Die 

angeblichen Fehlfunktionen der Fritzbox 

seien jedoch auf die Installation von Surfsitter 

zurückzuführen. AVM verklagte das 

Unternehmen wegen Urheberrechtsverletzung, 

einem Wettbewerbsverstoß und 

Markenrechtsverletzung aufgrund der 

Produktveränderung. 

Die Firmware sei ein von angestellten Programmierern 

komplex erstelltes System 

mit zahlreichen Software-Modulen, deren 

Programmierung jeweils komplex sei. Mit 

der ausschließlich als Ganzes vertriebenen 

Fritzbox hätte AVM eine aufeinander 

abgestimmte Einheit aus Hardware und 

darauf optimierter Firmware geschaffen, 

in der sowohl Open-Source-Software als 

auch proprietäre Software enthalten sei. 

Dies sei insgesamt ein urheberrechtlich 

geschütztes Sammelwerk, heißt es in der 

Klage. Die Cybits AG vervielfältige mit 

der Software Surfsitter auch die in der 

Firmware enthaltene proprietäre Software 

von AVM. Die Entfernung einiger Dateien 

der Firmware sei eine nicht zulässige 

Umarbeitung, wobei leider nicht ganz 

klar aus dem Urteil hervorgeht, welche 

Teile der Software nun tatsächlich genau 

modifiziert worden waren. AVM störte 

sich im Wesentlichen aber nicht an der 

Umarbeitung, sondern daran, dass der 

Verbraucher die durch die Installation 

von Surfsitter ausgelösten Fehlfunktionen 

AVM zuordne. Dies beeinträchtige 

seinen guten Ruf und die Garantie für die 

Geräte und sei ein wettbewerbswidriges 

Verhalten. 

Die Cybits AG wies darauf hin, dass Nutzer 

von Surfsitter mit einem Häkchen 



Login 

bestätigen müssten, dass die Installation 

von Surfsitter bewirke, dass die 

Onlinestatusanzeige der Fritzbox ohne 

Funktion sei, die Kindersicherung nicht 

mehr verwendet werden könne und 

die Firwall durch eine Linux Standard 

Firewall ersetzt sei. Die Cybits AG stellte 

ihre Verteidigung dann aber im Wesentlichen 

auf urheberrechtliche Aspekte 

ab und meinte, die Firmware genieße 

keinen selbstständigen, über den Schutz 

ihrer Bestandteile hinausgehenden eigenen 

urheberrecht lichen Schutz, der Bearbeitungen 

verbiete. Da die Firmware 

Open-Source-Software enthalte, würde 

die GPL für die gesamte Firmware als 

Sammelwerk gelten. Dem Verfahren war 

aufseiten der Cybits AG ein Linux-Programmierer 

beigetreten, vertreten durch 

den Open-Source-Experten Rechtsanwalt 

Dr. Till Jaeger. 

Infektion mit der GPL 

Das Landgericht Berlin (AZ 16 O 255/10) 

entschied über den Fall am 8. November 

2011: Der mit der Klage geltend gemachte 

urheberrechtliche Unterlassungsanspruch 

habe keinen Erfolg. Bei der Firmware 

handle es sich um ein Sammelwerk, das 

aus zahlreichen einzelnen Dateien bestünde. 

Diese seien Grundlage der einzelnen 

Funktionen der Firmware, etwa für 

die Telefonie, das WLAN oder die Kindersicherung. 

Teil dieses Sammelwerkes sei 

der Kernel, der auf dem Linux-Betriebssystem 

basiere und der als sogenannte 

Open-Source-Software den Bedingungen 

der GPLv2 unterliege. Hiernach sei jedem 

Nutzer die Benutzung und Bearbeitung 

nach der eingeräumten Lizenz gestattet. 

Allerdings sei jeder Nutzer wiederum 

verpflichtet nach dem sogenannten Copyleft-Prinzip, 

seine Bearbeitungen ebenfalls 

der GPL zu unterstellen, andernfalls 

entfalle die Nutzungslizenz. Für Sammelwerke 

regle § 2 GPLv2, dass Werke, 

die Open-Source-Software enthalten, als 

Ganzes den Bedingungen der GPL unterliegen. 

Derjenige Nutzer der von der 

Software profitiere, solle sich ebenfalls 

an den Bedingungen der GPL festhalten 

müssen. Das Gericht führt aus: „Die Infizierung 

eines Sammelwerks insgesamt 

bei Verwendung von Open-Source-Software 

in einzelnen Teilen eines Sammelwerks 

begegnet keinen Bedenken, da das 

Sammelwerk eine einheitliche Funktionalität 

aufweist und maßgeblich von den 

Open-Souce-Bestandteilen abhängt. Danach 

stehen den Klägern an der Firmware 

als Ganzes – und so sind ihre Anträge 

zu verstehen – keine urheberrechtlichen 

Unterlassungsansprüche zu.“ 

Nach Ansicht der Autorin hätte das Gericht 

vielleicht anders entschieden, wenn 

klar festgestanden hätte, dass Surfsitter 

separat abgrenzbare proprietäre Computerprogramme 

von AVM geändert hatte. 

Das Gericht verneinte auch den Markenrechtsverstoß 

und eine gezielte Behinderung. 

Dennoch war die Klage teilweise 

erfolgreich, da die Installation der Software 

Surfsitter Fehlfunktionen verursache 

und dies die Interessen von AVM 

spürbar beeinträchtige. Die Funktionen 

würden nachteilig beeinflusst, und der 

Nutzer könne nicht ausmachen, auf wen 

dies zurückzuführen sei, besonders wenn 

© Paulo Cruz, 123RF 

Wer ist der Urheber? 

Ob man als angestellter Programmierer arbeitet 

oder als selbstständiger Auftragnehmer 

– Urheber bleibt dennoch immer der Programmierer 

oder das Team. Der Unternehmer, der 

den Programmierer angestellt hat, erhält das 

ausschließliche Nutzungsrecht, soweit im Arbeitsvertrag 

nichts anderes geregelt ist. Bei 

freien Programmierern kommt es darauf an, 

was vereinbart wurde. Wenn nichts geregelt 

ist, schützt das Gesetz den Urheber. Danach 

werden die Rechte nur so weit übertragen, wie 

es der Vertragszweck erfordert. Möglicherweise 

behält der Entwickler noch Rechte. 

er die Software nicht selbst installiert 

habe. Dies sei eine rufschädigende Entwertung 

des Produktes von AVM. Das 

Urteil war zum Redaktionsschluss noch 

nicht rechtskräftig. 

Ohne Garantie 

Deutlich wird: Die GPL kann ein Grund 

sein, warum man Software verändern 

darf. Jedoch kann das Wettbewerbsrecht 

dies verbieten. Anders liegt der Fall, 

wenn man als Anbieter von ergänzender 

Software klar deutlich macht, dass 

durch die Installation der Software gegebenenfalls 

der Garantieanspruch gegen 

den Hardwareanbieter erlischt. So 

heißt es etwa bei Freetz, einer anderen 

Firmware-Erweiterung und Modifikation 

für den Fritzbox-Router: „Die Original- 

Firmware des Herstellers wird um zusätzliche 

Funktionen erweitert und mit 

einer individuellen Zusammenstellung 

von Programmen ergänzt … Freetz ist 

freie Software und wird von Oliver Metz, 

Alexander Kriegisch und Team entwickelt 

… . WARNUNG: Die Installation einer 

modifizierten Firmware führt zum Verlust 

der Gewährleistung des Herstellers!“ 

Gänzlich erfolglos endete der Fall Facebook 

gegen StudiVZ, entschieden am 

16.06.2009 vom Landgericht Köln (AZ 33 

O 374/08): Facebook hatte Studi VZ vorgeworfen, 

das Look-and-Feel der Website 

übernommen zu haben. Hier verneinte 

das Gericht sowohl einen Urheber- als 

auch einen Wettbewerbsverstoß. Es wies 

Abbildung 1: Reine Daten ohne Programmanweisungen sind urheberrechtlich nicht geschützt, dasselbe gilt in 

aller Regel übrigens auch für Webseiten. 


Admin 


23

Login 


darauf hin, dass grundsätzlich Nachahmungsfreiheit 

bestünde. Zwar sei es nicht 

zu übersehen, dass sich beide Plattformen 

hinsichtlich der grafischen und funktionalen 

Gestaltung der Bildschirmoberflächen 

ähnelten oder übereinstimmten. Jedoch 

habe Facebook nicht beweisen können, 

dass PHP-Code übernommen worden sei. 

Es lägen keine besonderen Umstände vor, 

die das Nachahmen als wettbewerbswidrig 

erscheinen ließen. Das Look-and-Feel, 

also das Design einer Website ist sehr 

selten geschützt, es sei denn die einzelnen 

Elemente, wie Texte oder Bilder 

genießen Urheberrechtsschutz oder aber 

das Design ist so kreativ, dass es Schöpfungshöhe 

erreicht. 

Schutzlose Software 

Es kann aber auch sein, dass Software 

übernommen werden darf, weil sie nicht 

urheberrechtlich geschützt ist. Das Urheberrechtsgesetz 

schützt Computerprogramme 

als Sprachwerke und auch 

bereits das Entwurfsmaterial. Auch Darstellungen 

wissenschaftlicher oder technischer 

Art, wie Zeichnungen, Pläne, 

Karten, Skizzen, Tabellen und plastische 

Darstellungen genießen Urheberrechtsschutz, 

sofern diese persönliche geistige 

Schöpfungen sind, also individuellen 

Charakter haben. 

Geschützt sind nach dem Gesetz alle 

Ausdrucksformen eines Computerprogramms, 

also sowohl Objektcode als 

auch Source Code sowie in Hardware 

integrierte Software, etwa Firmware. 

In § 69 Urheberrechtsgesetz heißt es: 

„(1) Computerprogramme im Sinne dieses 

Gesetzes sind Programme in jeder 

Gestalt, einschließlich des Entwurfsmaterials. 

(2) Der gewährte Schutz gilt für alle 

Ausdrucksformen eines Computerprogramms. 

Ideen und Grundsätze, die einem 

Element eines Computerprogramms 

zugrundeliegen, einschließlich der den 

Schnittstellen zugrundeliegenden Ideen 

und Grundsätze, sind nicht geschützt.“ 

Damit einher geht § 69 d Absatz 3 des 

Gesetzes. Danach darf man das Funktionieren 

eines Programms beobachten, untersuchen 

oder testen, um die einem Programmelement 

zugrundeliegenden Ideen 

und Grundsätze zu ermitteln, wenn dies 

durch Handlungen zum Laden, Anzeigen, 

Ablaufen, Übertragen oder Speichern des 

Programms geschieht, zu denen der Nutzer 

berechtigt ist. 

Die Gedanken sind frei 

Geschützt sind aber eben nur Ausdrucksformen. 

Das Urheberrecht will keine bestimmten 

Programmfunktionen monopolisieren. 

Wie sich Idee und Ausdruck 

voneinander abgrenzen, verrät das Gesetz 

nicht. Frei sind auch allgemeingültige 

wissenschaftliche Lehren, abstrakte 

Lehrsätze, Rechenregeln, mathematische 

Formeln oder Grundsätze des Fachgebietes, 

wenn diese einem Programm 

zugrunde liegen. Es kommt also immer 

drauf an, was genau ein Algorithmus beinhaltet. 

Wird nur die reine technische, 

im Fachgebiet vorgegebene wissenschaftliche 

Lehre umgesetzt beziehungsweise 

fest standardisierte Betriebsabläufe, ohne 

dass der Programmierer dabei einen eigenen 

Gestaltungsspielraum hat, spräche 

dies gegen einen Schutz. Zur Frage wann 

Algorithmen geschützt sind, gibt es allerdings 

sehr vielfältige Rechtsansichten. 

Nicht geschützt sind ferner reine Daten, 

solange in ihnen keine Folge von Befehlen 

liegt, die das Programm zur Kontrolle 

oder Steuerung des Programmablaufes 

nutzt. 

Die WIPO, die World Intellectual Property 

Organisation, definiert den Begriff Computerprogramm 

in § 1 (i) der Mustervorschriften 

der WIPO wie folgt: „… eine 

Folge von Befehlen, die nach Aufnahme 

in einem maschinenlesbaren Träger fähig 

sind zu bewirken, dass eine Maschine mit 

informationsverarbeitenden Fähigkeiten 

eine bestimmte Funktion oder Aufgabe 

oder ein bestimmtes Ergebnis anzeigt, 

ausführt oder erzielt.“ 

HTML reicht nicht 

Es gibt kaum Rechtsprechung zu den einzelnen 

technischen Arten von Computerprogrammen. 

Nur bei HTML-Code ist die 

Rechtsprechung eindeutig. Er reicht als 

reine Auszeichnungssprache nicht aus, 

um in den Genuss des urheberrechtlichen 

Schutzes zu gelangen, es sei denn andere 

Komponenten mit Kontrollstrukturen im 

Code, wie JAVA-Script oder PHP sind 

sehr eng mit dem HTML verzahnt. Dies 

könnte theoretisch bei Webseiten der Fall 

sein, die auf HTML5 basieren, weil es 

dort zu einer technischen Verflechtung 

zwischen JavaScript und HTML kommt. 

Solange der Code aber im Wesentlichen 

nur Daten über die Formatierung der 

Seite enthält und nur Texte und Grafiken 

sichtbar macht, ist dieser nicht als Computerprogramm 

geschützt. Andererseits 

nahm das OLG Rostock den Schutz einer 

HTML-Seite ausnahmsweise an, weil 

der Code eine textbasierte Suchmaschinenoptimierung 

enthielt, die als Sprachwerk 

urheberrechtlichen Schutz genoss. 

Es kommt also sehr auf den Einzelfall an. 

Soweit das Programm Kontrollstrukturen 

oder Steuerbefehle enthält wie bei Java, 

Abbildung 2: Das Dekompilieren, also das Rückverwandeln maschinensprachlicher Anweisungen in 

menschenlesbaren Quellcode, ist unter bestimmten Bedingungen erlaubt. 



Login 

C+ oder C++ sind die Anforderungen 

an Computerprogramme aber nicht mehr 

allzu hoch. 

Schutz nur für 

Anspruchsvolles? 

Im Gesetz heißt es: „Computerprogramme 

sind nur dann geschützt, wenn 

sie individuelle Werke in dem Sinne darstellen, 

dass sie das Ergebnis der eigenen 

geistigen Schöpfung ihres Urhebers sind. 

Zur Bestimmung ihrer Schutzfähigkeit 

sind keine anderen Kriterien, insbesondere 

nicht qualitative oder ästhetische, 

anzuwenden.“ 

Die Anforderungen an die Schöpfungshöhe 

von Computerprogrammen sind seit 

Umsetzung der Europäischen Richtlinie 

über den Rechtsschutz von Computerprogrammen 

im Urheberrechtsgesetz nicht 

mehr allzu hoch. Früher war das Können 

eines Durchschnittsprogrammierers, 

also die rein handwerksmäßige Umsetzung, 

die mechanisch-technische Aneinanderreihung 

und Zusammenfügung 

des Materials, nicht geschützt. Dies ist 

heute anders. Es bedarf weder einer überdurchschnittlichen 

Individualität noch einer 

besonderen technischen Qualität. Es 

muss von einem Menschen geschaffen 

sein und auf eine schöpferische Leistung 

zurückgehen. Der Programmierer muss 

Gestaltungsspielraum gehabt und diesen 

ausgenutzt haben. 

Softwarepatente 

Software ist nur dann patentierbar, wenn sie 

eine neue technische Erfindung ist, die auf einer 

erfinderischen Tätigkeit beruht und gewerblich 

anwendbar ist. Das deutsche Patentgesetz 

nimmt Computerprogramme ausdrücklich 

vom Schutz aus, auch das europäische Recht. 

„Computerprogramme als solche“ sind nicht 

patentfähig. Nur computerimplementierte Erfindungen 

sind patentierbar. Dies ist der Fall, 

wenn Software zur Lösung eines technischen 

Problems eingesetzt wird und die Lösung darin 

Das sind Indizien für eine individuelle 

und damit schutzwürdige Leistung des 

Programmierers: Nutzt der Programmierer 

seine analytisch-konzeptionellen 

Fähigkeiten, sein Geschick, seinen Einfallsreichstum 

und sein planerisch-konstruktives 

Denken? Ausgenommen sind 

nur noch ganz triviale Programmierleistungen, 

also routinemäßige und allgemein 

angewandte Programmierungen, 

die jeder Programmierer auf ähnliche 

Art und Weise so umsetzen würde. Auch 

eine Aneinanderreihung von allgemein 

bekannten Programmbausteinen wäre 

demnach schutzlos. Nach dem Bundesgerichtshof 

wird bei komplexen Computerprogrammen 

die Individualität der 

Programmgestaltung sogar vermutet, 

wenn der Rechteinhaber dazu kurz etwas 

vorträgt. Nur wenn die Gegenseite 

darlegt, dass es sich um eine nur triviale 

Programmierleistung handelt, wird der 

besteht, eine Software so auszugestalten, dass 

diese auf die technischen Gegebenheiten der 

Hardware Rücksicht nimmt. Das Programm muss 

etwa die internen Funktionen der Hardware verbessern, 

also zum Beispiel dazu führen, dass 

der Arbeitsspeicher besser ausgenutzt wird, 

was kürzere Speicherzugriffszeiten bewirkt. 

Wenn also Hard- und Software unmittelbar aufeinander 

einwirken, kann ein Schutz gegeben 

sein. Auch hier besteht also ein erheblicher 

Auslegungsspielraum. 

Sachverhalt näher untersucht. Es ist im 

Ganzen also eine Ausnahme, dass ein 

Programm nicht geschützt ist. 

Sind Programmiersprachen 

geschützt? 

Umstritten ist bislang, ob eine Programmiersprache 

urheberrechtlich geschützt 

ist. Dem Europäischen Gerichtshof liegt 

dazu aktuell ein Fall vor. Er betrifft die 

Programmiersprache SAS (Statistical Analysis 

System). Die World Programming 

Limited (WPL) schuf eine alternative 

Software, das World Programming System 

(WPS). Es bildet einen großen Teil 

der Funktionalitäten von SAS-Komponenten 

nach. Die Programme der Kunden 

sollen, wenn sie mit WPS betrieben werden, 

genauso funktionieren, wie wenn 

sie mit den SAS-Komponenten betrieben 

würden. WPL richtete das Programm da- 

Linux-Magazin 

ACADEMY 

Online-Training 

IT-Sicherheit Grundlagen 

mit Tobias Eggendorfer 

Themen (Auszug): 

❚ physikalische Sicherheit 

❚ Sicherheitskonzepte 

❚ Sicherheitsprüfung 

❚ logische Sicherheit 

• Betriebssystem 

• Netzwerk 

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 E inkl. 19 % MwSt. 

@Kirsty Pargeter, 123RF 


Admin 


Informationen und Anmeldung unter: academy.linux-magazin.de/sicherheit 

25

Login 


Abbildung 3: Das Projekt Freetz – hier die Homepage – verweist klar auf den Garantieverlust in seiner Folge. 

her so ein, dass es das SAS-Datenformat 

versteht und interpretieren kann. 

Es gab keine Anhaltspunkte dafür, dass 

WPL Zugang zum Quellcode der SAS- 

Komponenten gehabt oder diesen kopiert 

haben könnte. Dem gleichnamigen Softwarehersteller 

gefiel dies nicht, und er 

verklagte den Konkurrenten wegen Urheberrechtsverletzung. 

Der High Court of 

Justice, der über den Fall zu entscheiden 

hat, legte dem EuGH mehrere spannende 

Fragen zur Auslegung der Europäischen 

Computersoftwarerrichtlinie in puncto 

Interoperabilität, Dekompilierung und 

der Frage vor, wann Programmiersprachen 

geschützt seien. In seinen Schlussanträgen 

meint der Generalanwalt, Programmiersprachen 

an sich seien nicht 

schutzfähig nach dem Urheberrecht. Die 

Programmiersprache sei ein Element, mit 

dem der Maschine Befehle erteilt werden 

könnten. Die Programmiersprache 

sei aber nur das Mittel, um sich auszudrücken, 

nicht aber die Ausdrucksform 

selbst und damit nicht geschützt. 

Er schreibt weiter: Ließe man zu, dass 

eine Funktionalität eines Computerprogramms 

als solche geschützt sei, dann 

würde dies dazu führen, Ideen zu monopolisieren. 

Dies würde wiederum dem 

technischen Fortschritt und der industriellen 

Entwicklung schaden. Allerdings 

könnten die jeweils eingeschlagenen 

Wege durchaus urheberrechtlich geschützt 

sein, auf denen man zu einer 

Konkretisierung der Funktionalitäten eines 

Programms gelange. Die Kreativität, 

das Können und der Erfindungsgeist des 

Programmieres kämen in der Art und 

Weise zum Ausdruck, wie das Programm 

ausgearbeitet sei. 

Interoperabilität ist 

erwünscht 

Im deutschen Gesetz, welches auf der 

Europäischen Richtlinie beruht, heißt es, 

die den Schnittstellen zugrunde liegenden 

Ideen und Grundsätze seien frei. Nur 

der Code, der die Schnittstelle umsetzt, 

könne im Einzelfall Urheberrechtsschutz 

genießen. Das Ziel des Gesetzgebers war 

Interoperabilität. § 69 e Urheberrechtsgesetz 

erlaubt daher die Dekompilierung, 

wenn diese unerlässlich ist, um die erforderlichen 

Informationen zur Herstellung 

der Interoperabilität eines unabhängig 

geschaffenen Computerprogramms mit 

anderen Programmen zu erhalten. 

Dies muss sich jedoch auf die Teile des 

ursprünglichen Programms beschränken, 

die notwendig sind, die Interoperabilität 

herzustellen. Ferner muss dies durch 

jemanden geschehen, der als Lizenznehmer 

oder anders zur Nutzung des 

Programms berechtigt ist und dem die 

für Interoperabilität notwendigen Informationen 

nicht ohne Weiteres vorliegen. 

Die so gewonnenen Informationen dürfen 

auch nicht zu anderen Zwecken als 

zur Herstellung der Interoperabilität des 

unabhängig geschaffenen Programms 

verwendet und nicht an Dritte weitergegeben 

werden, es sei denn, dass dies 

für die Interoperabilität des unabhängig 

geschaffenen Programms notwendig ist. 

In der Praxis trennt man oft das Dekompilierungs- 

vom Entwicklungsteam, um 

dies sicherzustellen. Wichtig: Die so gewonnenen 

Informationen dürfen nicht 

für die Entwicklung, Herstellung oder 

Vermarktung eines Programms mit im 

Wesentlichen ähnlicher Ausdrucksform 

oder für irgendwelche anderen das Urheberrecht 

verletzenden Handlungen verwendet 

werden. Bei der Auslegung des 

Gesetzes ist jeweils darauf zu achten, 

dass dies weder die normale Auswertung 

des Werkes beeinträchtigt, noch die berechtigten 

Interessen des Rechtsinhabers 

unzumutbar verletzt. 

Diese Normen sind vielen Entwicklern 

nicht bekannt und zugegeben sehr 

schwammig formuliert. Das Urteil des 

EuGH wird einige offene Fragen in Sachen 

Interoperabilität klären. Sollte das 

Gericht dem Generalanwalt folgen, wäre 

dies ein sehr positives Signal für kleinere, 

alternative Softwareanbieter und könnte 

Innovationen fördern. 

Fazit 

Grundsätzlich gilt: Die Ideen und Gedanken 

sind frei, und die Nachahmung ist 

erwünscht, nur Copy und Paste ist unerwünscht. 

Die Grenze zwischen Nachbau 

und Eigenschöpfung kann man leider oft 

nicht trennscharf ziehen, und letztendlich 

kommt es immer darauf an, ob es gelingt, 

die Übernahme von Code zu beweisen. 

Open-Source-Software ist – obwohl der 

Code offenliegt – auch urheberrechtlich 

geschützt, und ihr Anwender muss die 

GPL beachten, wenn er sie nicht ausschließlich 

nutzen, sondern bearbeiten 

möchte. Verstößt er dagegen, entfällt das 

Nutzungsrecht. Die Anforderungen an 

den Softwareschutz sind grundsätzlich 

gering, nur Auszeichnungssprachen fallen 

nicht darunter. (jcb) 

n 

Die Autorin 

Die Autorin ist Rechtsanwältin und Fachjournalistin 

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

seit 1997 in zahlreichen Medien zu Fragen des IT- 

Rechts und unterrichtet als Lehrbeauftragte für 

IT-Recht an der Beuth Hochschule für Technik. Zu 

ihren Beratungsschwerpunkten 

gehören das Softwarelizenz- 

und das Internetrecht, 

das Urheber-, Vertrags- und 

Markenrecht sowie Datenschutzfragen. 


1&1 SERVER 

NEXT GENERATION 

WELTNEUHEIT EXKLUSIV BEI 1&1: 

2 X 16 CORE 

AMD OPTERON PROZESSOR 6272 

Sicher: 

Modernste Rechenzentren, 

über 99,9 % 

Erreichbarkeit 

Einfach: 

Parallels ® Plesk 10.4 

unlimited enthalten 

DAS NEUE 1&1 DEDICATED SERVER PORTFOLIO: 

NEU: 1&1 SERVER MIT 

INTEL-PROZESSOREN! 

SERVER 

4i 

AKTION: JETZT 3 MONATE 

SPARPREIS SICHERN! 

SERVER 

XL 6 

EXKLUSIV BEI 1&1: DER WELT- 

SCHNELLSTE HOSTING-SERVER! 

SERVER XXL 

32 CORE 

Flexibel: 

Umfangreiche Betriebssystem- 

und Featureauswahl 

Schnell: 

Traffic Flatrate 

und über 275 GBit/s 

Anbindung 

■ Intel ® Xeon ® E3-1220 

■ 4 Cores bis zu 3,4 GHz 

■ 12 GB ECC RAM 

■ 1.000 GB RAID 1 mit 

2 x 1.000 SATA HDD 

79, 99 

€/Monat* 

■ AMD Hexa-Core Prozessor 

■ 6 Cores bis zu 3,3 GHz 



2 x 1.000 SATA HDD 

JETZT: 3 MONATE 

FÜR 0,– € * 

99, 99 

€/Monat* 

€/Monat* 

■ 2 x 16-Core AMD 

Opteron Prozessor 6272 

(„Interlagos”) 

■ 2 x 16 Core bis zu 3,0 GHz 



6 x 600 SAS HDD 

499, 99 

€/Monat* 

Fragen? 

Kostenloser Support 

rund um die Uhr 

Weitere 1&1 Server 

im Internet 

Jetzt informieren 

und bestellen: 

0 26 02 / 96 91 

0800 / 100 668 

www.1und1.info 

* Server 4i: 79,99 €/Monat. Server XL 6: 3 Monate 0,– €/Monat, danach 99,99 €/Monat. Server XXL 32 Core: 499,99 €/Monat. Einmalige Einrichtungsgebühr 99,- € (entfällt bei Server 4i und 

Server XXL 32 Core). Mindestvertragslaufzeit 12 Monate. Preise inkl. MwSt.

Netzwerk 

Shell im Browser 

Mehr Sicherheit 

Das verschlüsselte Abspeichern des Passworts 

mithilfe von »pwhash.php« verhindert zwar 

unberechtigte Logins, falls einem Angreifer 

die Konfigurationsdatei in die Hände fallen 

sollte. Sie sollten PHP Shell aber grundsätzlich 

über eine per SSL verschlüsselte Verbindung 

(HTTPS) aufrufen – andernfalls könnte ein 

Angreifer die eingegebenen Kommandos und 

Ausgaben im Klartext mitlesen. 

© Dorota C., 123RF 

Shell-Zugriff per Webbrowser 

Not-Lösung 

Eine Shell im Browser? PHP Shell und Shell in a Box machen es möglich 

und erleichtern damit das Verwalten von Webservern auch ohne SSH- 

Zugang – beispielsweise aus dem nächsten Internet-Café. Wolfgang Dautermann 

Die Verwaltung eines externen Webservers 

gestaltet sich per Secure Shell 

einfach, dank X-Forwarding kann man 

bei entsprechender Netzanbindung sogar 

grafische Programme zur Verwaltung 

am heimischen Rechner bedienen. 

Oft steht aber zur Administration nur 

ein Rechner zur Verfügung, auf dem 

man keine zusätzliche Software installieren 

kann oder darf. Häufig agiert auch 

die Firewall so restriktiv, dass außer 

HTTP(S) nichts hindurchkommt. PHP 

Shell und Shell in a Box ermöglichen in 

diesem Fall trotzdem den Shell-Zugriff 

auf den Server. 

PHP Shell 

PHP Shell ermöglicht den Shell-Zugang 

zu Servern, wo die Firewall den Zugang 

blockiert oder Sie keine Software 

im Dateisystem installieren können. Ein 

PHP-fähiger Webserver genügt, um Shell- 

Befehle auszuführen. Dazu darf der Safe- 

Mode von PHP nicht aktiviert sein, der 

dazu dient, PHP durch Einschränkungen 

gewisser Befehle sicher zu machen. 

Die Installation von PHP Shell funktioniert 

recht einfach: Sie laden die aktuelle 

Version von der PHP-Shell-Homepage [1] 

herunter und entpacken das ZIP-Archiv 

in ein Verzeichnis auf dem Webspace. 

Dann setzen Sie ein Passwort, wozu Sie 

die URL »http://Server/phpshell/pwhash. 

php« aufrufen. Dort geben Sie die gewünschte 

Kombination von Benutzernamen 

und Passwort ein. Sie erhalten als 

Ausgabe eine Zeile, die Sie im Abschnitt 

»[users]« der Konfigurationsdatei »config.php« 

eintragen. Bei Bedarf können 

Sie auch mehrere Benutzer anlegen. Neben 

Benutzernamen und Passwort lassen 

sich in »config.php« noch Shell-Aliases 

sowie ein Home-Verzeichnis für PHP 

Shell festlegen. 

In Grenzen 

Nun steht PHP Shell zum Einsatz bereit. 

Sie rufen es über die URL »https://Server/phpshell/phpshell.php« 

auf, melden 

sich mit Benutzernamen und Passwort 

an – und die Shell-Sitzung im Webbrowser 

kann beginnen. Sie geben nun 

Kommandos im PHP-Shell-Fenster ein 

(Abbildung 1). Nach dem Betätigen von 

[Eingabe] oder einem Klick auf »Execute 

Command« werden diese ausgeführt, das 

Ergebnis erscheint wiederum im Shell- 

Fenster. 

Die Kommandozeile, die PHP Shell im 

Browser zur Verfügung stellt, unterliegt 

dabei einigen Einschränkungen: 

n Jeder Befehl muss ohne weitere Benutzereingabe 

auskommen, interaktive 

Programme lassen sich nicht 

bedienen. 



Netzwerk 

G Abbildung 2: Shell in a Box wirkt auf den ersten Blick wie die echte 

Kommandozeile. 

F Abbildung 1: PHP Shell ist unschwer als Webanwendung zu erkennen. 

n Jedes Kommando muss in eine Zeile 

passen. PHP Shell erkennt nicht, dass 

ein Kommando noch fortgesetzt werden 

müsste. So gelingt beispielsweise 

die Eingabe einer For-Schleife in mehreren 

Zeilen (wie in der normalen 

Shell) nicht. 

n Die Befehle müssen innerhalb einer 

bestimmten Zeitspanne abgearbeitet 

sein, üblicherweise binnen 30 Sekunden. 

Hier handelt es sich jedoch nicht 

um eine durch PHP Shell bedingte Einschränkung: 

Sowohl der Webserver 

(meist Apache) als auch PHP brechen 

nach einer gewissen Zeit die Verarbeitung 

ab. Sie konfigurieren die entsprechenden 

Limits in Apache über die 

»Timeout«-Direktive, in PHP mittels 

der Einstellung »max_execution_time« 

in »php.ini«. 

PHP-Shell führt die Kommandos unter 

der User- und Group-ID des Webservers 

aus, wie sich unschwer mit dem »id«- 

Kommando überprüfen lässt. Das kann 

Kommando 

Tabelle 1: Funktionen von Shell in a Box 

»shellinaboxd ‐s 

/:LOGIN« 

»shellinaboxd ‐s /:SSH« 


/Bezeichner/:SSH:host. 

example.com« 


/systemstatus/:User: 

Gruppe:/:Programm« 

Funktion 

zuweilen recht nützlich sein – etwa, wenn 

man ein Verzeichnis anlegen möchte, in 

das nur der Webserver schreiben darf. 

Das klappt via FTP meist nicht, da man 

in diesem Fall unter einer anderen User- 

ID operiert und daher oft lediglich global 

beschreibbare Verzeichnisse anlegen 

kann. Mit PHP Shell klappt das dagegen 

problemlos. 

Geschichte 

PHP Shell bietet eine 

einfache History-Funktion, 

über die Sie mit 

den Cursor-Tasten in 

den zuletzt ausgeführten 

Kommandos vorund 

zurückblättern. 

Weitere History-Funktionen 

wie eine Suche 

unterstützt PHP Shell 

aber nicht. Die Größe 

des „Shell-Fensters“ 

Stellt eine Login-Shell am lokalen System unter 

dem Pfad »http://localhost:4200/« zur Verfügung. 

Stellt ein SSH-Login am lokalen System unter dem 

Pfad »http://localhost:4200/« zur Verfügung. Dazu 

muss ein SSH-Server (zumindest am Loopback- 

Device) laufen. 

Stellt ein SSH-Login für den entfernten Rechner 

»host.example.com« am lokalen System unter dem 

Pfad »http://localhost:4200/Bezeichner/« zur Verfügung. 

Dazu muss ein SSH-Server laufen. Auf diese 

Weise lässt sich Shell in a Box auch als Gateway zu 

sonst unerreichbaren Rechnern verwenden. 

Lässt unter »http://localhost:4200/systemstatus/« 

ein Programm mit den Rechten des angegebenen 

Users und der Gruppe laufen. Als Arbeitsverzeichnis 

dient das Wurzelverzeichnis. 

ändern Sie gegebenenfalls via »Size:« 

rechts unterhalb des Eingabebereichs. 

Dort tragen Sie einfach die gewünschten 

Werte ein und führen dann den nächsten 

Befehl aus. 

Die PHP Shell enthält auch einen einfachen 

Editor (»editor Datei«), mit dessen 

Hilfe Sie alle Dateien ändern können, 

für die die Benutzer-ID des Webserver 

Schreibrechte besitzt. 

E 

Jetzt 

anrufen 

und Termin 

sichern! 

Linux Schulungen 2012 – Nicht verpassen! 

• Python Programmierung für Check_MK: 23.4. 

• Linux - Crashkurs für Administratoren: 5.3., 21.5., 2.7. 

• Linux Administration für Fortgeschrittene: 26.3., 11.6. 

• Shellprogrammierung mit der BASH: 16.4. 

• Linux als Server im Internet und Intranet: 25.6. 

• Nagios für Einsteiger: 07.05. 

• Fortgeschrittenes Monitoring mit Nagios & Check_MK: 

19.3., 18.6. 

Gerne machen wir Inhouse-Schulungen direkt bei unseren Kunden vor 

Ort. Fragen Sie uns nach einem Angebot zu Ihrem Wunschthema. 

Tel.: 089 / 18 90 42 10 


Admin 

mk@mathias-kettner.de 

Ausgabe 01-2012 www.mathias-kettner.de 

29

Netzwerk 


Verschlüsselung und Zertifikate 

Die Verschlüsselung von Passwörtern und Daten zwischen Sender und Empfänger sorgt dafür, 

dass kein Unberechtigter mitlesen kann. Dazu braucht man Zertifikate, wie man sie von diversen 

Webseiten (oder auch Mailservern) kennt – meist nimmt man sie erst dann wahr, wenn der Browser 

ein Zertifikatsproblem meldet. Diese Zertifikate sollen sicherstellen, dass der Server auf der Gegenseite 

auch tatsächlich derjenige ist, für den er sich dem Client gegenüber ausgibt. Anderenfalls 

könnte sich ein Angreifer zum Abfangen des Datenverkehrs einfach als berechtigte Gegenstelle 

ausgeben. 

Zertifikate bekommt man einerseits von kommerziellen, kostenpflichtigen Zertifizierungsstellen: 

Sie verifizieren die Identität des Antragstellers und geben dann ein Zertifikat für einen Hostnamen 

aus. Der Browser erkennt das dann automatisch als korrekt: Er vertraut bestimmten eingebauten 

Zertifizierungsstellen. Eine Alternative bietet die Community-Lösung CACert [3]. 

Schließlich besteht die Möglichkeit, mithilfe von OpenSSL selbst signierte Zertifikate [4] auszustellen 

– Listing 1 führt die dazu notwendigen Schritte auf. Wenn Sie solche verwenden (Abbildung 3) 

und von anderen Rechnern aus über das Internet auf derart gesicherte Dienste zugreifen, sollten 

Sie sich dabei auf jeden Fall das Zertifikat anschauen und die zugehörigen MD5/SHA1-Fingerprints 

vergleichen. 

Shell in a Box (Abbildung 2) eignet sich 

dann, wenn Sie zwar Shell-Zugang zum 

Server haben und dort eigene Programme 

einrichten können, aber als Client einen 

Webbrowser verwenden wollen oder 

müssen. 

Das Projekt stellt neben dem Quellcode 

auf seinen Webseiten [2] auch Debian- 

Pakete zur Verfügung. Benutzer von Debian 

und dessen Derivaten sowie Ubuntu- 

User installieren die Binärpakete bequem 

über den Paketmanager. Verwenden Sie 

eine andere Distribution, entpacken Sie 

nach dem Herunterladen den Quellcode- 

Tarball in ein beliebiges Verzeichnis und 

übersetzen ihn dort mittels »./configure 

; make«. Anschließend installieren Sie 

Shell in a Box mit dem Befehl »make 

install« als Root. Der Aufruf richtet das 

Programm unterhalb des Verzeichnisses 

»/usr/local« ein. 

Shell in a Box bringt anders als PHP Shell 

einen eigenen Webserver mit, der per 

Default auf Port 4200 lauscht. Dabei kann 

das Programm eine Reihe von Diensten 

zur Verfügung stellen, die Sie nach dem 

Schema 

shellinaboxd ‐s Webpfad:Dienst 

starten. Für erste Versuche können Sie 

dabei mit der zusätzlichen Option »‐t« 

oder in der Langform »‐‐disable‐ssl« die 

Verschlüsselung via SSL (dazu später 

mehr) vorläufig deaktivieren. Welche 

grundsätzlichen Möglichkeiten es gibt, 

führt die Tabelle „Funktionen von Shell 

in a Box“ auf. Ein »shellinaboxd«-Prozess 

kann dabei durchaus mehrere Services 

zur Verfügung stellen, wie beispielsweise 

das Login zu mehreren Rechnern: 

shellinaboxd ‐s /host1/:SSH:host.example.comU 

‐s /host2/:SSH:host2.example.com 

So verbinden Sie sich unter der URL 

»http://localhost:4200/host1/« zu »host. 

example.com« verbinden, unter der URL 

»http://localhost:4200/host2/« öffnen 

Sie eine SSH-Verbindung zum Rechner 

»host2.example.com«. 

Anders die PHP Shell, bei der eine Zeile 

komplett eingegeben, diese dann verarbeitet 

und das 

Ergebnis wieder 

an den Browser 

zurückgeschickt 

wird, ermöglicht Shell in a Box das 

textbasierte interaktive Arbeiten, beispielsweise 

mit einem Editor wie Vi. Die 

Performance bleibt dabei etwas hinter 

jener im „normalen“ Terminal zurück, 

meist spürt man jedoch keine großen Einschränkungen. 

Shell in a Box stellt noch 

eine ganze Reihe weiterer Optionen zur 

Verfügung, ein Blick in die Dokumentation 

beziehungsweise auf die Webseite 

[2] lohnt sich. 

Während erste Experimente mit Shell 

in a Box am lokalen Rechner durchaus 

ohne Verschlüsselung erfolgen können, 

empfiehlt es sich dringend, im produktiven 

Einsatz alle Verbindungen mittels 

SSL abzusichern. Dazu benötigen Sie ein 

Zertifikat, das sich im entweder im aktuellen 

Verzeichnis befinden muss oder 

dessen Speicherort Sie durch die Option 

»‐‐cert=Verzeichnis« angeben. Näheres 

erläutert der Kasten „Verschlüsselung 

und Zertifikate“. (jlu/ofr) 

n 

Infos 

[1] PHP Shell: 

[http:// phpshell. sourceforge. net] 

[2] Shell in a Box: 

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

[3] CACert: [http:// www. cacert. org] 

[4] Eigenes SSL-Zertifikat: Florian Effenberger, 

„Brief und Siegel“, LU 06/2009, S. 31, 

[http:// www. linux‐community. de/ 18025] 

Der Autor 

Der Systemadministrator Wolfgang Dautermann 

hat neben vielen Linux-Varianten auch schon 

diverse Unixe gebändigt, darunter Solaris, Irix 

und Tru64. Er zählt zu den Organisatoren der 

Grazer Linux-Tage. 

Listing 1: SSL-Schlüssel 

Key erzeugen: 

# openssl genrsa ‐des3 ‐out server.key 1024 

Certificate Signing Request (CSR) erzeugen: 

# openssl req ‐new ‐key server.key ‐out server.csr 

Passwort vom Schlüssel entfernen: 

# cp server.key server.key.org 

# openssl rsa ‐in server.key.org ‐out server.key 

CSR signieren und Zertifikat erzeugen: 

# openssl x509 ‐req ‐days 365 ‐in server.csr ‐signkey server.key ‐out server.crt 

cat server.crt server.key > certificate.pem 

Abbildung 3: Ein selbst signiertes Zertifikat im Webbrowser. 


globalBusiness: 

weltweit mehr 

als 4.000 Orte 

verfügbar 

New York – Berlin zum Ortstarif: 

globalBusiness verbindet Sie mit der Welt. 

Und so geht’s: Sie erhalten von der outbox AG 

eine lokale Rufnummer z.B. aus New York. 

Alle Anrufe darauf werden umgehend auf Ihre 

Festnetznummer in Berlin – oder auf jedes 

andere beliebige Ziel – weitergeleitet. So sind 

Sie in Ihrem Büro in Deutschland für internationale 

Kunden zu deren Ortstarif erreichbar. 

Bieten Sie Ihren Kunden und Interessenten mit 

globalBusiness diese persönliche und günstige 

Kontaktmöglichkeit und sichern Sie sich Ihren 

Wettbewerbsvorteil. Alle verfügbaren Länder 

und Vorwahlen im Web: www.outbox.de/admin 

Infos und Beratung: 0800 / 66 474 640 

www.outbox.de/admin

Netzwerk 

SSH-Tipps 

© Pei Ling Hoo, 123rf.com 

SSH-Tipps für den Alltag 

Schlüsselwächter 

SSH wird meist dazu verwendet, eine verschlüsselte Verbindung zur Shell auf einem entfernen Host aufzubauen, 

um diesen zu administrieren. SSH kann aber mehr, zum Beispiel Dateien übertragen, Ports weiterleiten oder gar 

ein echtes VPN aufsetzen. Thomas Drilling 

Das Kürzel SSH („Secure Shell“) steht 

im allgemeinen Sprachgebrauch sowohl 

für das so bezeichnete Netzwerkprotokoll, 

als auch für ein Paket von Tools, 

mit deren Hilfe sich der Admin über eine 

verschlüsselte Netzwerkverbindung auf 

einem entfernten Gerät einloggen kann. 

Mit „der SSH“ deckt der Admin neben 

Remote Login eine ganze Reihe weiterer 

Remote-Anwendungen mit einem Tool 

ab, darunter auch Remote Execute, Remote 

Copy, Remote X11 Client sowie eine 

Reihe von Port-Forwarding-Szenarien. 

Insgesamt kann SSH mit den im SSH- 

Paket enthaltenen Tools ssh, slogin, scp 

und sftp die klassischen Unix-Befehle 

zum Ausführen von Befehlen auf entfernten 

Hosts »rsh«, »rlogin«, »rcp« und 

»telnet« vollständig durch Varianten mit 

Verschlüsslung und Authentifizierung 

ersetzen. 

Jedes dieser Kommandos führt eine Shell 

auf dem entfernten Host aus und erlaubt 

dem Benutzer das Aufrufen von Befehlen. 

Da jeder Client ein Benutzerkonto 

auf dem Host benötigt, auf dem er einen 

Befehl ausführen möchte, führen alle genannten 

Kommandos einen Authentifizierungsprozess 

durch. 

Während die klassischen r-Varianten dabei 

lediglich Benutzernamen und Passwörter 

ohne Verschlüsslung austauschen, 

verwenden alle SSH-Befehle eine Public- 

Key-Cryptography-Infrastruktur. Ebenfalls 

zum SSH-Paket gehören die Tools/ 

Kommandos »ssh‐keygen«, »ssh‐agent« 

und »ssh‐add« zur Unterstützung von 

Authentifizierungsvorgängen. Die vollständige 

Syntax inklusive aller möglichen 

Optionen liefert das Eingeben von 

»ssh« ohne Parameter oder der Aufruf 

von »man ssh«. 

SSH interaktiv 

Hat der Admin eine SSH-Verbindung aufgebaut, 

im einfachsten Fall etwa mit 

ssh ‐l Benutzer Remote‐Host 

gefolgt vom Nutzer-Passwort auf dem 

entfernten Host, leitet SSH sämtliche 

Tastatureingaben an den Remote-Host 

weiter. Weniger 

bekannt ist, dass 

sich über Escape- 

Sequenzen auch 

SSH selbst steuern 

lässt. Das Tilde- 

Zeichen zu Beginn 

einer neuen Zeile 

leitet bei SSH standardmäßig 

eine 

Escape-Sequenz 

ein; erst das folgende 

Zeichen kennzeichnet den Befehl: 

So zeigt »~#« sämtliche offenen SSH- 

Verbindungen, und »~« beendet die aktuelle 

Verbindung, was nützlich ist, wenn 

die Shell nicht mehr reagiert. Eine Liste 

aller möglichen Befehle liefert »~?«. Mithilfe 

der Option »‐e« ist es möglich, SSH 

ein anderes Zeichen zum Einleiten einer 

Escape-Sequenz mitzugeben. 

Wer selten mit Escape-Sequenzen arbeitet, 

mag vielleicht folgenden Hinweis 

nützlich finden: Je nach Tastatur-Layout 

kann es unter Umständen erforderlich 

sein, etwa unter Ubuntu, die Tastensequenz 

[AltGr][+] zum Erzeugen der 

Tilde (~) zweimal hintereinander einzugeben, 

gefolgt vom gewünschten Befehlszeichen. 

Die in der folgenden Abbildung 

sichtbare Zeichenfolge »~?« wurde so 

nicht eingegeben. Wollte der Admin diese 

Abbildung 1: SSH lässt sich auch über Escape-Sequenzen steuern. 


SSH-Tipps 

Netzwerk 

Abbildung 2: Die Abbildungen zeigen den Inhalt des gleichen Verzeichnisses 

»/root« auf dem entfernten Server »www.thomas‐drilling.de«, einmal via SSH 

und einmal lokal eingebunden via »sshfs«. 

Abbildung 3: Auch der Midnight Commander kann via SSH auf entfernte 

Verzeichnisse zugreifen. 

Zeichenfolge sichtbar eingeben, müsste 

er nach einmaligen Eingeben der Tilde- 

Sequenz [AltGr][+] die Leertaste drücken, 

was dann keine Escape-Sequenz, 

sondern reiner Text ist. 

Dateitransfer 

SSH lässt sich mithilfe des Kommandos 

»scp« auch zum Übertragen von Dateien 

nutzen. Da viele Admins lieber das ungleich 

mächtigere »rsync« verwenden, 

gerät diese Möglichkeit mitunter in Vergessenheit, 

obwohl sie für die meisten 

Zwecke ausreicht. Die komplette Syntax 

liefert wie üblich »man scp«. Im einfachsten 

Fall genügt: 

scp Datei1 User@Host:Datei2 

oder in umgekehrter Richtung 

scp User@Host:Datei1 Datei2 

Ganze Verzeichnisbäume lassen sich rekursiv 

mit dem Schalter »‐r« kopieren. 

Noch eleganter ist das Einbinden des entfernten 

Dateisystems via SSH, was sich 

mit dem Tool »sshfs« bewerkstelligen 

Wer es noch bequemer haben will, kann 

in Nautilus auch den Assistenten »Datei | 

Mit Server verbinden« benutzen, im Listenauswahlfeld 

»Typ« im Bereich »Serlässt. 

Dank der durch SSH gewährleisteten 

Authentifizierung und Verschlüsselung 

der übertragenen Daten ist »sshfs« 

eine sehr komfortable Variante für sichere 

Datentransfers über das Internet. 

Sshfs erlaubt einem nicht privilegierten 

Benutzer, ein fernes Dateisystem via SSH 

einzubinden, setzt allerdings auf Client- 

Seite das FUSE-Module (Filesystem in 

Userspace, [2]) voraus. Auf der Server- 

Seite dagegen braucht »sshfs« lediglich 

einen SSH-Server mit SFTP-Subsystem. 

Installiert der Admin auf Client-Seite das 

Paket »sshfs«, sorgt das Paketmanagement 

automatisch für die Installation von 

»fuse‐utils« und »lib‐fuse2«. Die Syntax 

von »sshfs« lautet im einfachsten Fall: 

sshf User@Host:Pfad U 

Lokaler‐Mountpoint [Optionen] 

Grafische Clients 

Im Übrigen können auch einige Dateimanager 

wie etwa Midnight Commander 

über eine SSH-Verbindung auf das Dateisystem 

eines entfernten Hosts zugreifen 

(Abbildung 3). Zwar setzt die Methode 

via »mc« keine Kernel-Unterstützung auf 

dem Client voraus, ist dann aber auch 

nur in »mc« verfügbar. FUSE-basierte 

Dateisysteme sind wie jedes herkömmliche 

Dateisystem mit jedem Programm 

verwendbar. 

Auch der Gnome-Dateimanager Nautilus 

unterstützt das SSH-Protokoll, wozu der 

Admin lediglich die gewünschte Adresse 

in der Form »ssh://Rechnername/Pfad« 

in der Adressleiste eingeben muss. Da 

die aktuelle Nautilus-Version 3.2.1 in 

Gnome 3 die Adressleiste per Default 

nicht mehr anzeigt, muss man sie erst 

mit [Strg]+[L] einschalten (Abbildung 

4), womit Nautilus den SSH-Anmelde- 

Dialog zeigt (Abbildung 5). 

Selbstverständlich kann man sich auch 

mit einem anderen Benutzernamen am 

SSH-Server anmelden: 

ssh://Benutzer@Hostname/Pfad 

Abbildung 4: Nautilus 3.2.1 erfordert ein manuelles Zuschalten der Adressleiste mit [Strg]+[L] bei Bedarf. 

Abbildung 5: Der Sftp-Zugriff via Nautilus gestaltet 

sich komfortabel. 


Admin 


33

Netzwerk 

SSH-Tipps 

Abbildung 6: Nautilus ermöglicht Gelegenheitsnutzern 

neben der direkten URL-Eingabe auch die komfortable 

Anmeldung an einem entfernten Server via 

SSH mithilfe des Dialogs »Mit Server verbinden«. 

Abbildung 7: Auch KDEs Dateimanager Dolphin erlaubt komfortable Sftp-Transfers. 

verdetails« des Dialogs »Mit Server verbinden« 

den Eintrag »ssh« wählen und 

die Authentifizierungsdaten über die 

zugehörigen Felder im Dialog eintragen 

(Abbildung 6). Ganz nebenbei funktioniert 

diese Art SFTP-/SSH-Anmeldung 

auch in den meisten anderen Gnome- 

Anwendungen. 

Auch in KDE ist SSH-Unterstützung 

schon länger vorhanden, allerdings lautet 

die zugehörige Adresseingabe-Syntax 

in Dolphin oder Konqueror: »fish://Rechnername/Pfad« 

beziehungsweise »fish:// 

Benutzer@Rechnername/Pfad«. Auch 

Dolphin zeigt in aktuellen Versionen 

die URL-Eingabeleiste per Default nicht 

mehr an, allerdings findet der Nutzer die 

zugehörige Funktion schnell im Menü 

»Ansicht | Adresse | Editierbare Adressleiste«. 

Dolphin präsentiert dann unmittelbar 

den Dialog zur Benutzer-Authentifizierung, 

allerdings ist hier zunächst der 

momentan gültige lokale Benutzername 

als Default eingetragen, der daher in den 

meisten Fällen mit dem entfernten Benutzernamen 

zu überschreiben ist (Abbildung 

7). 

Darüber hinaus können KDE-Nutzer in 

Dolphin auch unter »Orte | Netzwerk« 

mit »Netzwerkordner hinzufügen« einen 

SSH-Netzwerkordner als Bookmark hinzufügen 

(Abbildung 8). 

Übrigens funktioniert die beschriebene 

Fish-Syntax zum Zugriff auf entfernte 

Dateien im gesamten KDE-Kontext und 

damit auch aus den meisten KDE-Anwendungen 

heraus mit »Datei | Öffnen« (Abbildung 

9). Allerdings muss der Nutzer 

im KDE-Dateiselektor ebenfalls die per 

Default abgeschaltete editierbare Adress- 

Eingabe einschalten, wozu er direkt in 

der Dateiauswahl mit einem Rechtsklick 

neben der aktuellen Pfadanzeige das 

Kontextmenü des Dateiselektors aufruft 

und dort statt der Default-Option »Navigieren« 

auf »Bearbeiten« umstellt. 

Kompression nutzen 

SSH unterstützt übrigens auch Kompression, 

was besonders dann nützlich ist, 

wenn sich das Netz als Engpass erweist. 

Das Komprimieren der Kommunikation 

zwischen »ssh« und »sshd« erfordert zwar 

auf beiden Seiten etwas mehr Rechenzeit, 

dafür muss SSH aber nur etwa 50 

Prozent der Pakete übertragen. Baut der 

Admin die Kompression auf Server-Seite 

mithilfe der Zeile »Compression yes« permanent 

in der Datei »/etc/ssh/sshd_config« 

ein, lassen sich langsame DSL- oder 

gar ISDN-Übertragungsstrecken etwa in 

Verbindung mit Port Forwarding spürbar 

beschleunigen. 

Auf Client-Seite lässt sich eine permanente 

Kompression analog mit »Compression 

yes« in »$HOME/.ssh/config« 

festlegen. Zum temporären Einschalten 

einer komprimierten Übertragung genügt 

der Parameter »‐C«, nicht zu verwechseln 

mit »‐c« für die Cipher-Spezifikationen 

der Verschlüsselung. 

Der sogenannte Master Mode erlaubt es 

dem Admin, durch eine physische Verbindung 

weitere logische SSH-Verbindungen 

aufzubauen, wozu er eine SSH-Verbindung 

als Master startet. Jetzt lassen sich 

alle weiteren SSH-Verbindungen zum 

gleichen Host mit dem gleichen User auf 

der Gegenseite über diese Master-Verbindung 

schicken, ohne eine neue physische 

Verbindung aufbauen zu müssen. 

Dazu verbindet sich der Client mithilfe 

eines Unix-Socket auf den Master und 

nicht unmittelbar zum Server auf der 

Gegenseite, wozu allerdings ein entsprechender 

Master-Socket anzugeben ist. 

Das Übertragen mehrere Sitzungen über 

einen einzigen Master-Kanal kann ebenfalls 

einen signifikanten Latenz-Vorteil 

bringen. Zum Konfigurieren von „opportunistic 

sharing“ ergänzt man die Datei 

»$HOME/.ssh/config« beispielsweise um 

folgende Zeilen: 

Abbildung 8: Dolphin erlaubt auch die Einrichtung eines auf SSH basierenden Netzwerkordners. 


SSH-Tipps 

Netzwerk 

Abbildung 9: Unter KDE kann der Admin aus so ziemlich jeder Anwendung via Fish-Adresse eine Sftp-Sitzung 

öffnen und auf Dateien des entfernten Rechners zugreifen. 

Host * 

ControlPath ~/.ssh/master‐%l‐%r@%h:%p 

ControlMaster auto 

»Host *« sorgt dafür, dass die folgende 

Konfiguration für Verbindungen von jedem 

Host gilt; alternativ ließe sich ein 

fixer Hostname eintragen. Mit »ControlMaster 

auto« verwendet SSH wenn 

möglich eine existierende Verbindung für 

den Master Mode. Andernfalls öffnet SSH 

eine neue Verbindung. Der Eintrag 

ControlPath ~/.ssh/master‐%l‐%r@%h:%p 

gibt an, wo SSH das Socket-File anlegen 

soll, das die Master-Verbindung repräsentiert. 

Dabei wird »%r« durch den 

Login-Namen ersetzt, »%h« durch den 

Hostnamen und »%p« durch die Port 

Nummer. Das Initiieren der Master- 

Verbindung erfolgt dann mit »ssh ‐M ‐S 

$HOME/.ssh/Socket User@Host«. Der 

Aufbau aller weiteren Verbindungen zum 

gleichen Host mit gleichem User erfolgt 

dann mit »ssh ‐S $HOME/.ssh/Socket 

User@Host« 

X11-Forwarding 

Das sogenannte X11-Forwarding (Abbildung 

10) erlaubt es, Programme mit 

grafischer Oberfläche via SSH auf einem 

entfernten Rechner zu starten, die Ein- 

und Ausgaben aber auf dem lokalen 

Desktop anzeigen zu lassen. Das funktioniert 

prinzipiell sogar unabhängig vom 

Betriebssystem des entfernten Rechners, 

sofern sich das Programm an den X11- 

Standard hält, womit sich die Auswahl 

in der Praxis auf Linux, BSD und Unix 

beschränkt. 

Zwar gib es heute ein ganzes Bündel 

leistungsfähiger grafischer Fernzugriffs- 

Lösungen, SSH ist aber bei jedem Linux- 

System gratis an Bord, wenn auch nicht 

sonderlich schnell. Für den gelegent lichen 

Einsatz, etwa zur Systemadministration, 

reicht X11-Forwarding aber allemal. Zum 

Aktivieren von X11-Forwarding dient die 

Option »‐X«, nicht zu verwechseln mit 

»‐x« zum Deaktivieren von Port-Forwarding. 

Die Option gewährt dem auf dem 

entfernten Rechner zu startenden Programm 

nur eingeschränkte Rechte am 

lokalen Display, was bei der einen oder 

anderen Anwendung zu einem Abbruch 

führen kann. In diesem Fall kann der 

Admin dem Programm immer noch mit 

der Option »‐Y« volle Rechte einräumen, 

was aber nur in Ausnahmefällen zu empfehlen 

ist. 

Tabu ist die Option »‐Y«, wenn der Admin 

dem Administrator des entfernten 

Hosts nicht vertraut, weil die Option 

einen Tunnel installiert, der sich von 

böswilligen Zeitgenossen auch in umgekehrter 

Richtung für einen Angriff auf 

das eigene Display nutzen ließe. Übrigens 

kann der Admin SSH als Alternative zum 

Parameter »‐X« auch mit dem Parameter 

»‐o« aufrufen und diesem den Wert 

»ForwardX11=yes« mitgeben. Wahlweise 

ist es auch möglich, in »$HOME/.ssh/ 

config« die Zeile »ForwardX11 yes« einzutragen. 

Tunnelbau mit SSH 

Abbildung 10: Die Abbildung zeigt zweimal den grafischen GNOME-Editor Gedit unter Ubuntu 11.10, links via 

X11-Forwarding auf einem Server im lokalen Netz gestartet, rechts lokal gestartet. 

Mit SSH lassen sich sogar (beinahe) beliebige 

andere Protokolle absichern, etwa 

das alte POP3-Protokoll oder eine unsichere 

VNC-Verbindung. Mit Port Forwarding 

kann der Admin einzelne Ports 

durch eine sichere SSH-Verbindung umleiten, 

wobei SSH selbst quasi als Proxy 

fungiert, der auf der einen Seite des SSH- 

Tunnels die Verbindung entgegennimmt 

und auf der anderen Seite mit dem adressierten 

Server, dem Verbindungsendpunkt, 

verbindet. 

E 


Admin 


35

1&1 WEBHOSTING 

Das beste Hosting für Profi-Websites: 

Maximale Verfügbarkeit: 

Georedundanter Betrieb – parallel in 

räumlich getrennten Rechenzentren! 

Superschnell: 

275 GBit/s Anbindung! 

Umweltschonend: 

Grüner Strom! 

Zukunftssicher: 

1.000 Entwickler bei 1&1! 

1&1 DOMAINS 

■ Domain-Umzug 

■ Schnelle Domain- 

Aktivierung 

■ DNS-Verwaltung 

■ Domain-Umleitung 

■ E-Mail-Adresse 

zur Weiterleitung 

0, 49 

€/Monat* 

.de 

.eu 

0, 29 

€/Monat* 

.de-Domain 1 Jahr für 0,29 €/Monat, 

danach ab 0,49 €/Monat.* 

Weitere Domains mit 

Sparvorteil unter 

1und1.info 

1&1 DUAL PERFECT 

■ 6 DOMAINS INKLUSIVE 

■ 5 GB Webspace 

■ UNLIMITED Tr a f fi c 

■ 20 FTP-Accounts 

■ 10 MySQL-Datenbanken (je 1 GB) 

9, 99 

€/Monat* 

■ UNLIMITED Click & Build Apps (Auswahl aus 65 Applikationen) 

■ Zend Framework 

■ PHP6 (beta), PHP5, Perl, Python 

■ 24/7 Profi-Hotline 

0,–€/Monat* 

1&1 Dual Perfect 6 Monate 0,– €, 

danach 9,99 €/Monat.* 

Weitere Pakete mit 

6-Monats-Sparvorteil 

unter 1und1.info 

* .de und .eu Domain 12 Monate 0,– €/Monat, danach .de 0,49 €/Monat, .eu 1,49 €/Monat. 1&1 Dual Perfect und 1&1 Perfect Shop 6 Monate 0,– €/Monat, danach 1&1 Dual Perfect 9,99 €/Monat, 

1&1 Perfect Shop 19,99 €/Monat. Einmalige Einrichtungsgebühr 9,60 € (entfällt bei Domain-Paketen). 12 Monate Mindestvertragslaufzeit. Preise inkl. MwSt.

DAS SICHERSTE 

HOSTING 

6 MONATE0,–,–€/Monat* 

1&1 PERFECT SHOP 

■ 1.000 ARTIKEL 

■ 100 Warengruppen 

■ Marketing-Tools 

■ PayPal 

■ eBay-Tool 

■ UNLIMITED Click & Build Apps 

(Auswahl aus 65 Applikationen) 

19, 

99 

0,–€/Monat* 

1&1 Perfect Shop 6 Monate 0,–€, 

danach 19,99 €/Monat.* 

€/Monat* 

Weitere E-Shops mit 

6-Monats-Sparvorteil 

unter 1und1.info 

1&1 bietet alles rund ums Thema 

Hosting bequem aus einer Hand: 

Domains 

Hosting 

E-Shops 

Online Office 

Suchmaschinen- 

Werbung 

Online Speicher 

MailXchange u. v. m. 

Jetzt informieren 

und bestellen: 

0 26 02 / 96 91 

0800 / 100 668 

www.1und1.info

Netzwerk 

SSH-Tipps 

SSH kennt zwei unterschiedliche Betriebsarten, 

nämlich Local Port Forwarding, 

und Remote Port Forwarding, oft auch 

als ausgehender und eingehender Tunnel 

bezeichnet, wobei Local Port Forwarding 

weitaus häufiger zum Einsatz kommt. Die 

Richtung des Tunnels-Aufbaus, also Local 

oder Remote Port Forwarding, geben die 

Parameter »‐L« und »‐R« an. Local Port 

Forwarding leitet eine Verbindung, die bei 

einem frei wählbaren lokalen Client-Port 

eintrifft, durch den sicheren SSH-Kanal 

auf einen Port eines entfernten Servers 

weiter – ein klassischer „ausgehender“ 

Tunnel. Die allgemeine Syntax für Local 

Port Forwarding lautet: 

ssh remoteuser@remotehost ‐L localportU 

:remotehost:remoteport 

Das folgende Beispiel tunnelt eine unsichere 

FTP-Verbindung mit Standard- 

Port 21 über eine gesicherte SSH-Verbindung, 

wobei auf dem Rechner »www. 

thomas‐drilling.de« ein FTP-Server läuft 

und der Client-Rechner »ws1‐kubu« die 

sichere SSH-Verbindung aufbaut sowie 

anschließend in einer separaten Terminal-Sitzung 

den FTP-Client startet, und 

zwar mit der Zieladresse »localhost« auf 

dem Port 4444. 

drilling@ws1‐kubu:~$ sudo ssh dilli@U 

www.thomas‐drilling.de ‐L 4444:www.thomas‐U 

drilling.de:21 

Mit dem Befehl baut der Admin am SSH- 

Client eine sichere SSH-Verbindung als 

Benutzer »dilli« zum entfernten Rechner 

»www.thomas‐drilling.de« auf und 

lauscht außerdem auf sämtliche Anfragen, 

die auf dem lokalen Port 4444 

von »ws1‐kubu« eingehen, um sie dem 

entfernten Rechner »www.thomas‐drilling.de« 

auf Port 21 weiterzuleiten, wobei 

die Kommunikation über die zuvor 

aufgebaute SSH-Verbindung läuft. Jetzt 

kann der Admin am lokalen Rechner 

»ws1‐kubu« seine FTP-Verbindung wie 

folgt aufbauen (Abbildung 11): 

drilling@ws1‐kubu:~$ sudo ftp localhost 4444 

Leider ist die Syntaxbeschreibung zum 

Port Forwarding in der Manpage etwas 

missverständlich: »ssh ‐L [bind_address:] 

port:host:port user@remotehost«. Die Parameter 

»host« und »remotehost« dieser 

Syntax-Schreibweise stehen im obigen 

Beispiel für den gleichen entfernten Server, 

weil »host« aus der Sicht des betreffenden 

Systems anzugeben ist. Daher 

könnte man in der praktischen Umsetzung 

statt »www.thomas‐drilling.de:21« 

auch »localhost:21« schreiben, weil sich 

»localhost« dann auf die Perspektive des 

Remote Host bezieht. 

Bei der Wahl des Einstiegsports (SSH) ist 

zu beachten, dass die Verwendung von 

privilegierten Ports kleiner 1024 nur Root 

gestattet ist. Daher nutzt man für Local 

Port Forwarding normalerweise höhere 

Ports. Der zweite Port-Parameter gibt 

schließlich an, auf welchen Port auf Remotehost 

(sshd) beziehungsweise »host« 

die Weiterleitung führen soll und hängt 

demnach vom zu tunnelnden Dienst ab. 

Möchte der Admin nur die Port-Weiterleitung 

nutzen, aber remote keine Shell 

starten, kann er den Parameter »‐N« anhängen 


Möchte er etwa einen 

POP3-Mailserver 

auf seinem virtuellen 

Server über 

eine verschlüsselte 

Verbindung abfragen, 

richtet er mittels Local Port Forwarding 

einen verschlüsselten SSH-Tunnel 

für Port 110 auf seinen Vserver ein: 

ssh Benutzer@Remotehost ‐L 20110:U 

Remotehost:110 

Jetzt muss er nur noch in seinem Mailclient, 

etwa Thunderbird, den Host »localhost« 

mit der Portnummer 4444 als 

POP-Server konfigurieren, und Mails lassen 

sich ab sofort verschlüsselt übertragen, 

ohne das der Mailserver selber SSL 

unterstützt (Abbildung 13). 

Remote Port Forwarding funktioniert übrigens 

genau umgekehrt zu Local Port 

Forwarding, das heißt, die Verbindung 

kommt an einem Port auf dem Host an, 

auf dem »sshd« läuft. Dieser leitet die 

Daten dann durch den SSH-Tunnel an 

einen beliebig wählbaren Port am Client. 

Die Syntax lautet: 

ssh Remoteuser@Remotehost ‐R Remoteport:U 

localhost:Localport 

Dynamic Forwarding 

Mit der Dynamic-Option »‐D« kann sich 

ein SSH-Client auch wie ein Socks-Server 

(Socks-Proxy) verhalten und den automatisierten 

Zugriff auf entfernte Rechner 

durch einen sicheren SSH-Tunnel 

ermöglichen. Dynamic Port Forwarding 

ist ebenfalls nützlich, wenn man etwa 

von einem öffentlichen WLAN Hotspot 

über einen gesicherten Tunnel auf einen 

Dienst seines Heim- oder Firmen-Servers 

zugreifen möchte. 

Es muss sich lediglich um einen Dienst 

handeln, für den es einen passenden 

Socks-Client gibt, was auf jeden Fall für 

Webbrowser zutrifft. In dessen Verbindungs-Optionen 

ist lediglich der lokale 

SSH-Client als SOCKS-Proxy mit der frei 

wählbaren Portnummer einzutragen. Da 

G Abbildung 12: Der Parameter »‐N« verhindert beim Local Port Forwarding, 

dass auf dem entfernten System eine Shell gestartet wird. 

F Abbildung 11: Die Abbildung demonstriert den Aufbau eines SSH-Tunnels für 

das an sich unsichere FTP-Protokoll. Der Admin kann die jetzt gesicherte FTP- 

Verbindung vom Client aus komfortabel über den selbst gewählten lokalen Port 

aufbauen. 


SSH-Tipps 

Netzwerk 

Seit der Version 4.3 von OpenSSH ist 

es mithilfe der Option »‐w« sogar möglich, 

ein richtiges VPN als Layer 2- oder 

Layer-3-Tunnel mit virtuellen Netzwerk- 

Adaptern (TUN/TAP-Interfaces) aufzuan 

öffentlichen WLAN Hotspots die Übertragung 

der Daten vom Client-Rechner 

zum WLAN-Router unverschlüsselt ist 

und daher von jedem beliebigen Netzwerk-Sniffer 

mitgelesen werden kann, 

bietet sich dieses Verfahren immer an, 

wenn beim Webzugriff auf den eigenen 

Server Login- oder andere sensible Daten 

übertragen werden. Der Aufbau des 

Tunnels zum entfernten »sshd« erfolgt 

dann mit 

ssh ‐D Port Nutzer@Remotehost 

terschied besteht darin, dass sämtlicher 

Datenverkehr innerhalb der benutzen 

Applikationen SSH-Tunnel läuft, nicht 

aber DNS-Anfragen, sodass sich der SSH- 

Tunnel unter anderem nicht zum anonymen 

Surfen eignet. 

Sollen andere Programme oder Dienste 

außer HTTP via SSH getunnelt werden, 

ist unter Linux zu beachten, dass manche 

Programme keine SOCKS-Proxies 

unterstützen. Ist dies der Fall, kann der 

Nutzer unter Linux den Wrapper »tsocks« 

installieren und für unser Beispiel mit folgender 

Konfigurationsdatei »/etc/socks/ 

tsocks.conf« bestücken: 

server = localhost 

server_port = 12222 

server_type = 4 

bauen. Allerdings erfordert dies, dass der 

Admin auf Server- und Client-Seite die 

entsprechenden TUN/TAP-Devices durch 

Laden der zugehörigen Kernel-Module 

mittels »modprobe« einrichtet. Das Verfahren 

eignet sich also nicht zur Adhoc- 

Verwendung etwa im geschilderten Internet-Café-Szenario. 

Das Aufsetzen der 

zugehörigen virtuellen Netzwerk-Adapter 

auf Server und Client erfolgt auf dem 

Client mit: 

ifconfig tun0 10.0.2.1 netmask 255.255.255.252 

Auf dem Server sieht die Konfiguration 

dann so aus: 

ifconfig tun0 10.0.2.2 netmask 255.255.255.252 

route add ‐host Ziel‐Host dev eth0 

Erst danach kann der Nutzer ausgehend 

vom Client einen VPN-Tunnel aufbauen: 

ssh ‐l Benutzer ‐p Sshd‐port ‐w0:0 Ziel‐Host 

Damit das funktioniert, muss in der zugehörigen 

Sshd-Konfiguration auf dem 

Cloud mal anders: 

Samba 

Alfres co Nagios 

Djigzo OTRS 

I 

P 

N 

U 

- 

T 

Schulungen 

Installationen 

Hardware Support 

Softw are C onsulting 

Ubuntu 

Debian SUSE 

CentOS Red Hat 

OpenSUSE 

Asterisk 

MobyDick 

snom 

AASTRA 

Jetzt muss der Admin nur noch den lokalen 

SSH-Client als SOCKS-Proxy mitsamt 

dem angegeben Port in seine Browser- 

Einstellungen eintragen, im Bild am Beispiel 

Firefox (Abbildung 14). 

Auch in diesem Beispiel sorgt die Option 

»‐N« dafür, dass der Client zwar den Tunnel 

aufbaut, auf dem Server aber keine 

Shell startet. Der SSH-Tunnel als SOCKS- 

Proxy kommt einem ausgewachsenen 

VPN schon recht nahe. Der einzige Unin-put 

powered by linux since 1896 

Moltkestrasse 49 D-76133 Karlsruhe 

Tel.: 0721 / 6803288-0 Fax 0721 / 6803288-3 


www.in-put.de kontakt@in-put.de 

Admin 


39

Netzwerk 

SSH-Tipps 

Linux-Server die Option »PermitTunnel 

yes« aktiviert sein. 

Firewall durchbohren 

Schon die bisher gezeigten Verfahren 

sollten die Leistungsfähigkeit von SSH 

vor allem im Bereich Port Forwarding 

eindrucksvoll demonstriert haben. Dabei 

waren sämtliche Beispiele auch im Sinne 

des Erfinders. Ssh lässt sich in gewissen 

Grenzen aber auch zweckentfremden. 

Blockt etwa die firmeneigene Firewall 

den SSH-Port 22, der Admin möchte aber 

von zu Hause sicher auf Daten seines 

Firmenrechners zugreifen, kann er sich 

mit folgendem Trick behelfen, bei dem 

unter anderem Remote Portforwarding 

ins Spiel kommt. 

Dazu muss am Firmen-Rechner ein 

OpenSSH-Server laufen, auch wenn die 

Abbildung 14: Beim Dynamic Portforwarding 

fungiert der SSH-Client als SOCKS-Proxy. So muss 

ihn der Nutzer lediglich als »localhost« mit der 

angegebenen Portnummer in sein Browser-Setting 

eintragen. 

Firewall Anfragen 

auf Port 22 

unterbindet. Zum 

Verfügungstellen 

eines SSH-Servers kann der Admin neben 

dem Paket »openssh‐client« auch die 

Server-Komponenten für SSH in Form des 

Paketes »ssh« installieren. Waren vorher 

weder SSH-Client noch Server installiert, 

können Debian- und Ubuntu-Admins 

auch »tasksel« von der Kommandozeile 

starten und dann die Paket-Gruppe 

»OpenSSH server« auswählen. 

Das Nachvollziehen folgender Vorgehensweise 

empfiehlt sich selbstverständlich 

nur dann, wenn der Admin auch Administrator 

des entfernten Servers beziehungsweise 

Netzes ist oder ein etwaiger 

Versuch mit ihm abgesprochen ist, denn 

er verletzt mit Sicherheit firmeninterne 

Sicherheits-Policies. Zu Hause muss der 

Admin dann dafür sorgen, dass auch 

der Heimrechner SSH-Verbindungen 

annimmt, wozu gegebenenfalls neben 

OpenSSH-Client ebenfalls die Server- 

Pakete zu installieren sind. 

Außerdem muss der Heim-Rechner über 

eine DnyDNS-Adresse von außen erreichbar 

sein. Läuft der SSH-Server am Heimrechner, 

baut der Admin am Heimrechner 

einen SSH-Tunnel vom Typ Remote Port 

Forwarding für den Port 22 vom Firmenrechner 

zum Sshd am Heimrechner auf, 

allerdings unter Zuhilfenahme der öffentlich 

zugänglichen DynDNS-Adresse. 

ssh Benutzer@Firmenrechner ‐R U 

4444:Heimrechner:22 

F Abbildung 13: 

Via Local Port 

Forwarding lässt sich 

beispielsweise auch 

das unsichere POP3- 

Protokoll zum Abfragen 

eines entfernten 

Mailservers via SSH 

absichern, auch wenn 

der POP-Server kein 

SSL unterstützt. 

Dann lässt er diesen Tunnel schlicht stehen 

und baut mit »ssh Benutzer@Heimrechner 

‐p 4444« durch diesen Tunnel 

hindurch einen weiteren Tunnel zum 

Firmenrechner unter Verwendung der 

beim Remote Port Forwarding angegebenen 

Portnummer (4444) auf. Das Bei- 

spiel demonstriert zwar das Prinzip des 

doppelten Tunnels, wird aber dem selbst 

gesteckten Szenario selbstverständlich 

noch nicht gerecht, weil ja die Firmen- 

Firewall definitionsgemäß Anfragen 

auf Port 22 nicht passieren lässt. Die 

meisten Firmen-Firewalls sind aber so 

konfiguriert, dass Anfragen auf Port 80 

(HTTP) erlaubt sind. 

Es spricht also in diesem Beispiel nichts 

dagegen, den SSH-Server zu Hause auf 

einem anderem Port lauschen zu lassen, 

beispielsweise auch den eigentlich für 

HTTP reservierten Port 80. Trotzdem an 

dieser Stelle noch einmal der Hinweis, 

dass ein solches Vorgehen arbeits- oder 

gar strafrechtliche Konsequenzen haben 

kann. 

Fazit 

SSH gibt es seit 1995, OpenSSH mindestens 

seit der Jahrtausendwende, und es 

hat sich zu einem der wichtigsten Werkzeuge 

für Administratoren entwickelt. 

Dabei schöpfen viele Systemverwalter die 

Möglichkeiten des Tools nicht aus, weil 

sie nicht wissen, dass es weit mehr kann, 

als eine entfernte Shell zu öffnen. 

Wer sich mit seinen Fähigkeiten eingehend 

befasst, stellt fest, dass SSH unter 

anderem proprietäre VPN-Lösungen und 

Software für sichere Dateitranfer obsolet 

macht. Dafür bietet SSH – aktuelle 

Versionen von Server und Client vorausgesetzt 

– zeitgemäße Sicherheit mit Authentifizierung 

und Verschlüsselung nach 

standardisierten Verfahren, auf die somit 

auch externe Werkzeuge aufsetzen können. 

(ofr) 

n 

Infos 

[1] OpenSSH-Webseite: [http:// openssh. org] 

[2] FUSE: [http:// fuse. sourceforge. net] 

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ässig 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. 


Open Source goes 

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

der CeBIT 2012 zum Thema Linux und freie Software – 

hervorragend platziert in Halle 2! 

Kleine und mittlere Unternehmen treffen hier auf hochrangige Entscheider. 

Nirgendwo sonst finden Sie eine bessere Business-Umgebung für Ihre 

Open-Source-Lösungen. 

Ein rundum perfekter Messeauftritt ‒ 

maximaler Erfolg mit minimalem Aufwand: 

• individuelle Standgrößen ab 4 m² 

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

• direkte Ansprache zahlreicher Neukunden 

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

• Kontakt zur internationalen Open Source Community 

Jetzt anmelden! 

www.open-source-park.de 

oder 0 26 1 - 20 16 902 

In Kooperation mit: 

Veranstalter: 

pluspol.de 

Marketing Kommunikation Internet


Monitoring-Vergleich 

Monitoring für den Mittelstand im Vergleich 

Unter 

Überwachung 

Monitoring ist ein Problem der Backup-Klasse: Das Ob steht außer Frage, das Wie kann kompliziert sein. Die 

Lösung des Problems liegt in einer guten Strategie mit den richtigen Prioritäten, aber auch bei den passenden 

Tools. Aus diesem Grund hat das ADMIN-Magazin für diese Ausgabe wieder einmal eine kleine Bestandsaufnahme 

gängiger Monitoring-Tools zusammengetragen. Jens-Christoph Brendel 

Die Crux bei jeder Art von tabellarischen 

Software-Vergleichen im Sektor Monitoring 

wie anderswo ist: Die wichtigsten 

Features beherrschen alle einigermaßen 

ausgereiften Lösungen. Einerseits kann 

man unmöglich jedes denkbare Leistungsmerkmal 

vergleichen, fragt man 

aber andererseits nur das Vorhandensein 

der Wichtigsten ab, dann ergeben sich 

kaum Unterschiede: In 97 Prozent der 

Tabellenzeilen erscheint das Häkchen. Im 

Ergebnis würde sich dann zum Beispiel 

der irreführende Eindruck vermitteln, 

Icinga sei der Papierform nach dasselbe 

wie Tivoli – obwohl beide für denkbar 

unterschiedliche Ansätze stehen. Wer 

nun den Ausweg im Detail sucht, 

der muss sich von den einfachen 

Tabellen mit Ja-/Nein-Antworten 

lösen und gerät in Gefahr, die 

Übersicht zu verlieren. Dieser 

Artikel versucht sich deshalb 

an einem Kompromiss: Wir 

haben zwar Fragebögen 

verschickt, aber um 

beschreibende Antworten 

in Textform 

gebeten, die wir 

hier teils gekürzt 

einfließen lasen. 

Unvergleichlich 

© arcady3, 123RF 

größer ist der potenzielle Vorteil ihrer 

Integration unter einem Dach. Vergleicht 

man dagegen nur die relativ begrenzte 

Untermenge der Monitoring-Optionen 

mit einem Produkt, das ausschließlich 

in diesem einen Punkt Ähnliches bietet, 

dann verflüchtigt sich Tivolis Integrationsvorteil 

und es bleibt eine zu komschließt. 

Je mehr Module ich aus dem 

Tivoli-Portfolio benötige – etwa Asset-, 

Storage-, Sicherheits- und Vertragsmanagement, 

Bestandsverwaltung, Beschaffungswesen, 

Arbeitsmanagement, desto 

Außerdem haben wir uns bemüht, keine 

Äpfel mit Birnen zu vergleichen. Das 

schon erwähnte Tivoli etwa ist IBMs 

integrierte Lösung für das System- und 

Service-Management, die unter anderem 

auch Überwachungsfunktionen ein- 

plexe und zu teure Konstruktion, die immer 

zwei Nummern zu groß ist. Derartige 

Software haben wir deshalb diesmal 

nicht berücksichtigt. 

Andere Produkte hätten wir dagegen 

gerne aufgenommen, trafen aber auf das 

Desinteresse der Hersteller. So leitete die 

deutsche Dependance der Firma Quest 

Software, Hersteller von Big Brother, 

unseren Fragebogen zwar angeblich an 

die Marketingabteilung weiter, die aber 

ging daraufhin auf Tauchstation. Spätere 

Nachfragen von uns blieben unbeantwortet 

– möglicherweise war ja nach dem 

Studium unserer Fragen das Vertrauen 

ins eigene Produkt geschwunden … 

Neben Fragen zu einzelnen Features 

hatten wir auch die nach dem Unique 

Selling Point gestellt: Warum sollte 

man sich als Kunde gerade für 

diese oder jene Lösung entscheiden? 

Das bekamen wir 

zur Antwort: 

OpenNMS 

OpenNMS [1] betont 

besonders 

seine Skalierbarkeit: 

Von Umgebungen 

mit 200 Systemen 

bei einem kleineren Mittelständler 

bis zu solchen mit 70 000 Interfaces im 

Enterprise-Bereich sei OpenNMS problemlos 

einsetzbar. In jedem Fall seien dabei 

die vorkonfigurierten Elemente und die 

offenen Schnittstellen ein großer Vorteil, 

weil damit direkt nach der Installation 

bereits Standardmonitore für die wich- 




Tabelle 1: Rahmendaten 

Name OpenNMS Zabbix Icinga Nagios 

URL http://www.opennms.org http://www.zabbix.com https://www.icinga.org http://www.nagios.org 

Version 1.8.x 1.8.6 1.6 3.3.1 

Lizenz GPL V2 GPL V2 GPL V2 Core: GPL V2, Nagios XI: Commercial 

License 

Unterstützte 

Plattformen 

Davon in Paketform/Installer 

Linux, Windows, Solaris, Mac 

OS X 

Windows, Linux (Deb oder 

RPM) 

Zabbix-Server und ‐Proxy: 

Linux, Solaris AIX, HP-UX, 

FreeBSD, OpenBSD, NetBSD, 

andere Unix-Plattformen. Zabbix 

Agent: zusätzlich Windows 

Im Repository von Debian, 

Ubuntu, Fedora; Zudem Pakete 

für Open Suse/SLES, RHEL, 

CentOS, Slackware. 

Linux, Solaris, HP UX, AIX, 

Gentoo, BSD, Mac OS X 

Ubuntu, Debian, Red Hat, 

CentOS, SLES, Solaris, Mac 

Div. Unix-Derivate, Linux, BSD 

In nahezu allen Linux-Distributionen 

enthalten 

Erstes öffentliches 2000 2001 2009 1999 (als NetSaint) 

Release 

Preis Lizenzkostenfrei Lizenzkostenfrei Lizenzkostenfrei Core: kostenfrei. Kommerziell: 

50 Nodes ab 1300 US-Dollar 

Hardwarevoraussetzungen 

CPU: Ab 1 GHz Ab 200 MHz ARM, i386 Die einzige Voraussetzung für 

Nagios Core ist eine Maschine 

mit Linux oder einer Unix- 

Variante, Netzwerkzugriff und 

einem C-Compiler (sofern aus 

den Sourcen intalliert werden 

soll). 

RAM: Minimal 512 MByte Ab 16 MByte für die Applikation 

Ab 32 MByte (ARM-CPU) Keine Angabe 

Disk Space: Minimal 8 GByte Ab 32 MByte, abhängig von Ab 50 MByte 

Keine Angabe 

der Menge gesammelter 

Daten 

Softwarevoraussetzungen 

Datenbanken PostgreSQL MySQL, PostgreSQL, Oracle, 

SQLite, DB2 

MySQL, PostgreSQL, Oracle Optional MySQL 

Architekturmodell 

Skalierbarkeit 

Support 

Grundsätzlich agentenlos, 

aber mit offenen Schnittstellen, 

die auch eine Implementierung 

von Agenten 

ermöglichen. TCP, ICMP, WMI; 

SNMP kann in den Versionen 

V1, V2c und V3 abgefragt 

werden. Die Nagios-Agenten 

NRPE und NSClient++ Lassen 

sich vollständig nutzen. 

Die Skalierbarkeit ist grundsätzlich 

nicht durch die Softwarearchitektur 

beschränkt. 

Es existieren Installationen 

mit 70 000 IP-Interfaces 

und 800 000 Performancendaten, 

die alle 5 Minuten 

gesammelt werden. Einzelne 

Daemons (Poller, Datacollection, 

etc.) lassen sich auf 

eigene Hardware auslagern. 

Kommerzieller Support verfügbar. 

Agentenloses Monitoring mit 

verschiedenen Methoden 

(TCP-Checks, ICMP Ping, 

SNMP, IPMI, andere), zusätzlich 

nativer Agent für alle 

Plattformen. 

Dank verschiedener Techniken 

zur Performancesteigerung 

(z.B. Caching) kann ein 

Zabbix-Server Tausende Hosts 

überwachen, auch verteiltes 

Monitoring ist möglich. 

Support durch Hersteller und 

Partner verfügbar. 

Icinga unterstützt sowohl 

agentenloses Monitoring via 

TCP, SNMP, WMI als als auch 

die Verwendung von Agenten 

wie NRPE oder auch NSClient++ 

für Windows-Systeme. 

Im Interesse einer guten 

Skalierbarkeit lassen sich 

verschiedene Systeme in 

verteilten Umgebungen konfigurieren 

und zentral über 

ein Interface steuern. Desweiteren 

können die einzelnen 

Komponenten wie Core, 

Datenbank und Webinterface 

auf verschiedene Systeme 

verteilt werden. Ein zentrale 

Konfiguration und Steuerung 

der entfernten Systeme wird 

durch Addons und Icinga-Web 

unterstützt. 

Support ist vielen Varianten 

durch Dienstleister verfügbar. 

Grundsätzlich agentenlos, 

wenn Prüfungen über das 

Netzwerk sowie per SNMP 

als hinreichend angesehen 

werden. 

Weitergehende Prüfungen 

über Agenten (NSClient++ 

unter Windows, Nagios NRPE 

unter Linux/Unix/BSD) sind 

möglich. 

Verteilte Installationen von 

Nagios sind möglich, sei es 

aus Performancegründen, 

aber auch um Daten verschiedener 

Nagios Installation 

zentral zu aggregieren. 

Community Support und zahlreiche 

Dienstleister für die 

kommerzielle Version durch 

Nagios Inc. 


Admin 


43



tigsten Dienste bereitstehen – darunter 

HTTP, SMTP, POP3 oder DNS. OpenNMS 

kann dank eines integrierten SNMP-Trapund 

Syslog-Receivers ein zentralisiertes 

Logging realisieren. Performancedaten 

lassen sich via SNMP, WMI, HTTP, JMX, 

JDBC oder NSClient++ sammeln. 

Die OpenNMS-Experten der Firma 

Nethinks, einem zertifizierten OpenNMS- 

Partner und Ausrichter der europäischen 

OpenNMS User Conference, unterstreichen: 

„Ein weiterer Vorteil liegt darin, 

dass OpenNMS auch ohne die Nutzung 

von Agenten die IT-Infrastruktur hervorragend 

überwachen kann. Nichtsdestotrotz 

kann OpenNMS natürlich auch 

programmierte Anwendungen über einen 

Scripting-Monitor mit einbinden. Für 

die NRPE- und NSClient++-Agenten 

von Nagios existiert in OpenNMS sogar 

ein spezieller Monitor. All das macht 

OpenNMS zu einem professionellen, 

komfortablen und sicheren Netzwerkmanagement-System 

aus einem Guss – für 

kleine und mittlere Unternehmen bis in 

den Enterprise-Bereich – das ohne die 

Nutzung von Plugins alle Bereiche des 

FCAPS-Modells (Fault, Configuration, 

Accounting, Performance und Security 

Management) abdeckt.“ OpenNMS sei 

ein starker Konkurrent aus dem Open- 

Source-Bereich zu kommerziellen Enterprise 

Produkten wie HP Openview oder 

IBM Tivoli. 

Zabbix 

Zabbix [2] wirbt ebenfalls mit hoher Skalierbarkeit: 

Bis zu 100 000 überwachte 

Geräte mit bis zu einer Million verschiedener 

Metriken sollen laut Auskunft des 

Herstellers kein Problem sein. Dazu kann 

die Software Tausende Checks pro Sekunde 

verarbeiten. 

Ein weiterer Vorteil von Zabbix ist die 

leichte Konfigurierbarkeit mit einer zentralen 

Datenbank. Fortgeschrittene Features 

wie Performance-Diagramme oder 

Maps erfordern mit anderen Lösungen 

zunächst oft einen höheren Einarbeitungsaufwand, 

bis sie ähnliche Ergebnisse 

produzieren. Verglichen mit Nagios 

punktet Zabbix außerdem mit einem 

Auto-Discovery (wie OpenNMS). 

Icinga 

Abbildung 1: RRD-Grafen wie im Bild einer zur CPU-Auslastung lassen sich leicht in Zabbix konfigurieren. 

Auch dem Nagios-Fork Icinga [3] fällt 

es nicht schwer, mit eigenen Vorteilen 

zu werben. So ist die Software im Unterschied 

zur kommerziellen Spielart von 

Nagios zu 100 Prozent Open Source. Dabei 

unterstützt sie dank eines eigenen 

Datenbanklayers nicht nur MySQL und 

PostgreSQL, sondern auch das weitverbreitete 

Oracle. Icinga beinhaltet Dutzende 

Bugfixes, die Nagios fehlen. Ein 

besonderer Hingucker ist das neue, moderne 

Webinterface, das deutlich über 

die schon etwas altbackene klassische 

Nagios-Ansicht hinausgeht. Daneben 

gibt es eine Monitoring-App für Smartphones. 

Icinga wird mit festen Release- 

Zyklen und einer öffentlich einsehbaren 

Roadmap ständig weiterentwickelt und 

ist dennoch rückwärtskompatibel zu Nagios, 

dessen großen Vorrat an Plugins es 

so ebenfalls nutzen kann. 

In Icinga ist ein leistungsfähiges Reporting 

(auf der Basis von Jasper Reports) bereits 

integriert. Es erlaubt im Unterschied zu 

Nagios Core eine Authentifizierung auch 

via LDAP oder Active Directory. Icinga 

kommt mit IPv6 klar – das klassische 

Nagios nicht. Es unterstützt mehr als 20 

Sprachen und hat im Detail noch zahlreiche 

weitere Vorteile zu bieten. 

Nagios 

Nagios [4] ist stolz auf seine lange Geschichte 

und große Verbreitung. Sein 

Erfinder und Chefentwickler Ethan Galstad 

meint: „Organisationen vertrauen 

Nagios wegen seiner Flexibilität, langen 

Geschichte, der weltweiten Community 

und der Fülle freier Addons. Deshalb 

gab es mehr als drei Millionen neuer 

Nagios-Installationen in den letzten 12 

Monaten weltweit. Deshalb ist Nagios 

heute der Industriestandard für das Monitoring. 

… Nagios hat eine sehr viel 

größere Community als andere Projekte. 

Das verspricht Firmen eine mehr Unterstützung, 

eine bessere Dokumentation 

und mehr Addons.“ 

Prinzipiell muss man bei Nagios allerdings 

die freie und kostenlose Community 

Edition (Core) – um die es hier 

hauptsächlich geht – vom kostenpflichtigen 

Nagios XI unter einer proprietären 

Lizenz unterscheiden. Letzteres beschert 

dem zahlenden Anwender diverse Zusatz-Features 

wie Mandantenfähigkeit, 

verschiedene APIs zur Integration mit 

Applikationen, Trendberechnungen und 

andere Daten für das Capacity Management 

oder eine besser an eigene Wünsche 

anpassbare GUI. 

E 




Tabelle 2: Checks 

OpenNMS Zabbix Icinga Nagios 

Verfügbarkeitschecks 

Services Weil OpenNMS IP-Interfaces mittels SNMP 

zu einem Gerät zusammenfassen kann, 

ergeben sich besondere Unterscheidungsmöglichkeiten: 

Ist ein Dienst nicht mehr 

erreichbar, signalisiert OpenNMS einen 

»nodeLostService«. Ist ein kritischer 

Dienst nicht mehr erreichbar, wird unterschieden 

in »interfaceDown« und »node- 

Down«. Letzteres wird nur dann ausgelöst, 

wenn das System über keines seiner Interfaces 

erreichbar ist. 

Hosts 

Ein weiterer Vorteil von OpenNMS ist die 

Konfigurierbarkeit eines adaptiven Pollings. 

Per Default wird ein Service alle 5 

Minuten überprüft. Im Fehlerfall reduziert 

sich das Intervall aber auf 30 Sekunden. 

Ja, Besonderheit: Anstelle 

fester Schwellwerte lassen 

sich so genannte Trigger 

einrichten, die verschiedenste 

Werte verarbeiten 

und beispielsweise den 

Load Average auf dem 

NFS-Server mit der Verfügbarkeit 

des Webservers in 

Bezug setzen können. 

Ja, mittels Plugin check_ping. 

Ja Ja, mittels Plugin check_ping. Ja 

Performancechecks 

CPU-Auslastung Vorkonfiguriert Eingebauter Agent. Ja, mittels Plugin check_cpu. Ja 

I/O Vorkonfiguriert Eingebauter Agent. Ja, mittels Plugin check_io. Ja 

Memory Vorkonfiguriert Eingebauter Agent. Ja, mittels Plugin check_mem. Ja 

Netz Vorkonfiguriert Eingebauter Agent. Ja, mittels Plugin check_interfaces. 

Automatisches 

Baselinening und 

Drift Detection 

SNMP-Checks 

Die Datacollection verfügt hierzu über 

die Möglichkeit Langzeitwerte via SNMP, 

WMI, NSClient++, JMX, HTTP und JDBC zu 

beziehen. 

SNMP-Checks über den SNMP-Monitor 

durchführbar. Es lassen sich selbst ganze 

Tabellen durchgeben. Dabei kann man 

unterscheiden, ob ein Wert der Tabelle, 

jeder Wert oder eine bestimmte minimale 

oder maximale Anzahl an Werten mit dem 

Vergleichswert übereinstimmen. 

Ja, (Versionen 1, 2c, 3). 

Wird von Addons bereitgestellt. 

Ja, mittels Plugin check_snmp 

und verschiedenen SNMP-Plugins 

für die diversen Hersteller wie 

Cisco, HP, Juniper usw. 

Checks via Hardware-Schnittstellen 

SMART Ja Ja Ja Ja 

IPMI / LOM / ILO Ja Ja, eingebaut. Ja, mittels Plugin check_ipmi. Ja, via Plugins. 

Mit Hilfe von Triggern nachbildbar. 

End-to-End- 

Checks 

Flap-Detection 

(wiederholte Statusänderungen) 

Anomalieerkennung 

Derzeit existieren mit dem Mail Transport 

Monitor und dem Page Sequence Monitor 

zwei Monitore für eine End-to-End Messung. 

Der Mail Transport Monitor zeichnet 

auf, wie lange die Mailübermittlung dauert. 

Der Page Sequence Monitor misst Abläufe 

in Webanwendungen. Weitergehend ist es 

durch die Integration von Hyperic möglich, 

die Werte aus einem agentenbasierten 

Netzwerkmanagement System zu ermitteln 

und zu verarbeiten. 

Flapping erkennt der Vacuum Daemon. 

Er generiert er ein Event, das OpenNMS 

protokolliert. 

OpenNMS bietet Anbindungsmöglichkeiten 

für Systeme, die Anomalien erkennen. 

Zusätzlich verfolgt die NETHINKS GmbH 

gemeinsam mit der Hochschule Fulda mit 

dem Forschungsprojekt secMONET einen 

Ansatz, der genau diese Anforderung erfüllen 

soll. 

User-Verhalten lässt sich in 

Grenzen nachbilden. 

Ja, mit Hilfe von Triggern 

nachbildbar. 

Ja, mit Hilfe von Triggern 

nachbildbar. 

Dies ist mittels verschiedener 

Erweiterungen möglich. Ein 

konkretes Beispiel hierfür ist 

die Verwendung des Automatisierungswerkzeugs 

Auto-IT und 

dessen Anbindung an Icinga unter 

Verwendung von check_autoit. 

So können komplexe Client- 

Workflows getestet werden. Für 

die Automatisierung von Web- 

Workflows werden u. a. Selenium 

und Cucumber unterstützt. 

Ja 

Anhand von Baselining. 

Ja 

Ja 

Nein 

Ja 

Gegebenenfalls über 

verteilte Nagios- 

Installationen realisierbar. 

Ja 

Keine über die Flap- 

Detection hinausgehende. 


Admin 


45



Abbildung 2: Das Auto-Discovery von OpenNMS hat einen neuen Node gefunden. 

Was wie überwacht werden soll und wer 

gegebenenfalls wann zu benachrichtigen 

ist, das muss der Admin der Monitoringsoftware 

sagen. Wie einfach, schnell 

und sicher ihm das gelingt, ist ein wesentliches 

Qualitätskriterium. Die Unterschiede 

kommen hier ganz besonders in 

großen Umgebungen zum Tragen: Im Fall 

des klassischen Nagios muss jeder Host 

händisch und mit einer speziellen Syntax 

in Textfiles der Konfiguration hinterlegt 

werden. Das ist bei Tausenden Hosts ein 

immenser Aufwand. Andere Lösungen 

wie OpenNMS verfügen stattdessen über 

ein eingebautes Auto-Discovery, das 

Netzwerke scannt und die dort gefundenen 

Rechner automatisch in die Überwachung 

integriert. Der Fairness halber 

muss man allerdings ergänzen, dass auch 

das kommerzielle Nagios XI eine Autodiscovery-Komponente 

hat und es für die 

freie Version entsprechende Plugins gibt. 

Außerdem existiert Software, die die Resultate 

des Netzwerkscanners NMap in 

Nagios übernehmen kann. 

Einrichtung 

OpenNMS: OpenNMS bietet das schon 

erwähnte Auto-Discovery (Abbildung2), 

geht aber auch darüber noch hinaus. So 

gibt es auch eine semi-automatische Erfassung 

von Systemen, die beim Eintreffen 

eines SNMP-Traps oder einer Syslog- 

Nachricht überprüft, ob das Gerät bereits 

in der Datenbank aufgenommen wurde. 

Ist dies nicht der Fall, wird das System 

integriert und dabei daraufhin überprüft, 

welche der vordefinierten Dienste es 

möglicherweise bereitstellt. Durch den 

Provisioning-Daemon ist es auch möglich, 

Geräte manuell oder über Schnittstellen 

(HTTP, XML, DNS und REST) anzulegen. 

Insbesondere die Möglichkeit, 

Geräte über einen Webservice (REST) 

oder in Form einer XML-Datei in das System 

aufzunehmen, bietet hervorragende 

Möglichkeiten, vorhandene CMDBs an 

OpenNMS anzubinden. 

Mittels SNMP ist OpenNMS außerdem in 

der Lage, IP-Interfaces zu Nodes zusammenzuführen. 

Die IP-Interfaces werden 

dabei nicht als einzelne Geräte dargestellt, 

sondern als ein Gerät mit mehreren 

IP-Interfaces erkannt. 

Zabbix: Auch Zabbix kennt ein Auto-Discovery 

und die automatische Aufnahme 

von Geräten in die Überwachung, die 

anhand ihrer IP-Adresse oder via SNMP 

erkannt wurden. Daneben ist eine manuelle 

Erfassung genauso möglich. 

Icinga: Bei Icinga werden die zu überwachenden 

Systeme wie beim Altvorderen 

Nagios zunächst einmal prinzipiell manuell 

erfasst. Das automatische Durchsuchen 

von Netzen kann über ein Nagios- 

Plugin nachgerüstet werden. 

Nagios: Nagios hat ein Auto-Discovery- 

Modul in der kommerziellen Version. Die 

Community-Edition lässt sich wie Icinga 

durch ein Plugin aufrüsten. 

Konfiguration 

Neben der Aufnahme zu überwachender 

Objekte gilt es auch darauf zu achten, 

wo und wie sie abgelegt werden. 

Eine zentralisierte Konfiguration ist hier 

selbstverständlich, aber interessant ist 

beispielsweise, ob die Objekte in einer 

leicht durchsuchbaren Datenbank oder 

nur in Plaintext-Files landen. Auch das 

Webinterface entscheidet über die Usability 

der Konfiguration, wenngleich ein 

objektiver Vergleich hier schwieriger ist. 

OpenNMS: OpenNMS speichert seine 

Konfiguration in Form von XML-Dateien. 

Konfigurationsänderungen erfolgen 

hauptsächlich über das Webinterface. 

Das direkte Editieren der XML-Dateien 

ist aber ebenfalls möglich, was etwa für 

ein Mass-Deployment wichtig ist. 

Zabbix: Zabix legt nur einige grundlegende 

Einstellungen für seinen Daemon 

in Textfiles ab und speichert alle Informationen 

über die überwachten Systeme in 

einer Datenbank. Dafür kommen MySQL, 

PostgreSQL, Oracle, SQLite2 oder DB2 

infrage. 

Icinga: Icingas Konfiguration findet sich 

in klassischen ASCII-Dateien mit proprietärer 

Syntax. Allerdings gibt es einen 

Workaround: Unterschiedliche Add-ons, 

darunter NagiosQL, LConf oder Nconf, 

können Nagios-Konfigurationsfiles erzeugen, 

und diese Addons greifen dafür 

dann ihrerseits auf Datenbanken oder 

einen LDAP-Server zurück. 

Nagios: Für Nagios gilt im Prinzip dasselbe 

wie für Icinga. 

Checks 

Als Nächstes stellt sich die Frage, was 

überwacht werden kann. Hier sind die 

Unterschiede nicht so groß, die grundlegenden 

Services haben alle Lösungen outof-the-box 

im Blick. Spezielle Anforderungen 

lassen sich im Zweifelsfall mit einem 

Plugin abdecken. Im Detail zeichnen sich 

manche Lösungen aber aus, etwa wenn 

OpenNMS die für manche Fehler typischen 

dauernden Statuswechsel erkennt 

(Flap Detection), während man sich mit 

Zabbix dafür etwas selbst stricken nuss. 

Auch Nagios oder Icinga bringen einen 

entsprechenden Mechanismus mit. 

Benachrichtigung 

Wurde eine Störung erkannt, muss der 

Benutzer davon erfahren. Was so einfach 

klingt, ist tatsächlich deutlich komplizierter. 

Denn es ergeben sich zahlreiche 

Ausnahmen und Sonderfälle: Während 




einer geplanten Auszeit etwa möchte 

man keine Nachrichten erhalten, nachts 

nur im Notfall, beispielsweise ab einem 

bestimmten Schweregrad. Der Chef soll 

erst angefunkt werden, wenn die Sache 

eskaliert oder kein Mitarbeiter bestätigt 

hat, dass er das Problem bearbeitet. An 

Sonn- und Feiertagen sollen andere Regeln 

gelten als werktags. Manchmal soll 

ein Einzelner zu Hilfe gerufen werden, 

manchmal eine Gruppe. Der eine ist am 

besten via E-Mail erreichbar, ein zweiter 

via SMS, der Dritte per Telefon oder Piepser. 

Wenn klar ist, was der Auslöser des 

Problems ist, sollen etwaige Folgefehler 

nicht auch noch Alarme initiieren. Und 

so weiter und so fort. 

OpenNMS: OpenNMS kann Benachrichtigung 

sowohl an Benutzer und Gruppen 

als auch an vordefinierte Rollen verschicken. 

Dabei lassen sich ganze Benachrichtigungsketten 

an unterschiedliche 

Personen, Gruppen und Rollen über unterschiedlichste 

Medien wie SMS, Ins- 

tant Messaging oder E-Mail aufbauen. 

Die Ketten können auf Wunsch durch 

eine Bestätigung unterbrochen werden. 

Innerhalb geplanter Auszeiten können 

das Polling, die Benachrichtigung, das 

Thresholding und die Data Collection 

deaktiviert werden. Um Folgefehler zu 

unterdrücken, ist die Konfiguration von 

Path Outages möglich, die Alarme für 

abhängige Nodes unterdrücken. 

Zabbix: Wiederholte Benachrichtigungen, 

beliebig viele Eskalationsstufen, 

automatische Mitteilungen bis zur Problembeseitigung 

und im Erfolgsfall – auch 

Zabbix beherrscht das ganze Arsenal 

der Notifications. Mithilfe seiner Trigger, 

zwischen denen auch Abhängigkeiten 

definiert werden können, erlaubt Zabbix 

auch das Unterdrücken von Folgefehlern. 

Das geht in seinem Fall sogar mehrstufig: 

Ein lokaler Host kann beispielsweise von 

einem Switch an seinem Standort und 

zugleich von einem entfernten Router 

und zugleich von einem zentralen Router 

abhängen und würde dann nicht als defekt 

gemeldet, wenn tatsächlich eine der 

übergeordnete Komponente die eigentliche 

Ursache ist. 

Icinga: Bei der Vielfalt der Benachrichtigungsformen 

steht auch Icinga nicht 

zurück, es beherrscht ebenfalls etwa die 

mehrstufige Eskalation, und es unterdrückt 

abgeleitete Fehler, nachdem sie 

einmal bestätigt wurden. Eine Spezialität 

von Icinga sind Voice-Notifications, 

die sogar Menüs enthalten können, mit 

denen sich etwa die Ansage wiederholen 

oder der Erhalt der Nachricht auch fern 

von einer Tastatur bestätigen lässt. Daneben 

ist auch Icinga in der Lage, durch vorher 

festgelegte Eltern-Kind-Beziehungen 

die bloße Nichterreichbarkeit von einem 

tatsächlichen Ausfall zu unterscheiden. 

Nagios: Schließlich kann in dieser Sparte 

auch das klassische Nagios überall sein 

Kreuzchen machen. Im Wesentlichen beherrscht 

es dieselben Benachrichtigungstechniken 

wie die Konkurrenz. E 

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 


47



Das Benutzerinterface – in der Regel eine 

Weboberfläche – bestimmt die Usability 

entscheidend mit. Das klassische Vorbild 

bringt Nagios mit: Die Ampeldarstellung 

haben später viele Nachfahren 

übernommen. Mittlerweile wirkt das 

Design allerdings ein wenig antiquiert. 

Heutzutage erwartet man eher ein Dashboard 

mit frei platzierbaren Elementen, 

die Visualisierung von Zeitreihen durch 

Diagramme, eingebettete Karten und 

Grundrisszeichnungen oder Grafiken, die 

die Auswirkungen auf Business-Prozesse 

illustrieren. 

Benutzerinterfaces 

In dieser Disziplin hat sich besonders 

Icinga (Abbildung 3) mit einem innovativen 

Konzept hervorgetan. Ob es dafür 

nun gleich der Wortneuschöpfung 

„Cronk“ für ein GUI-Element bedurft 

hätte oder nicht – das Webinterface von 

Icinga ist innovativ und voller praktischer 

Lösungen. So kann man alle Spalten der 

Status-Übersichten beliebig gruppieren 

und nach jeder Spalte sortieren, es gibt 

zahlreiche Filter- und Suchmöglichkeiten. 

Zudem lassen sich einzelne Kommandos 

gleichzeitig an eine Auswahl von 

Hosts verschicken. Der Admin kann sich 

Views vorkonfigurieren oder auch an andere 

weitergeben – dank des flexiblen 

Berechtigungskonzepts wahlweise auch 

als Nur-Lese-Ansicht. 

Das freie Nagios ist davon, wie gesagt, 

recht weit entfernt, auch wenn sich 

das eine oder andere dort noch über 

ein Plug in nachträglich einfügen lässt. 

Wesentlich näher dran ist da schon 

OpenNMS, das ebenfalls benutzerspezifische 

Sichten kennt und bei dem sich 

die Benutzerrechte auch fein justieren 

lassen. Eine weitere Gemeinsamkeit von 

OpenNMS und Icinga sind die teils bereits 

vorgefertigten Reports, die besonders das 

Management beeindrucken. 

Damit sieht es bei Zabbix nicht ganz 

so gut aus, aber immerhin RRD-Diagramme 

oder Maps gehören auch dort 

zum Standard. 

Performance und 

Skalierbarkeit 

Der Performance widmet sich ein eigener 

Beitrag dieses Themen-Schwerpunkts, 

deshalb soll an dieser Stelle nicht ausführlich 

darauf eingegangen werden. 

Generell gilt: In kleinen und auch noch 

in mittelgroßen Umgebungen ist das 

selten ein Thema, in größeren dagegen 

schon. Denn hier potenzieren sich die 

Zeiten, die für das Auslösen der Checks 

und die Verarbeitung der Rückgaben benötigt 

werden. Das kann dazu führen, 

dass ein Check noch nicht abgearbeitet 

ist während der nächste Zyklus schon 

wieder fällig wäre. So kann sich unter 

Umständen ein nicht mehr abbaubarer 

Stau aufschaukeln, der das Monitoring 

zum Erliegen bringt. 

Das Zauberwort bei Performanceproblemen 

heißt: verteiltes Arbeiten. Die 

Möglichkeit für eine solche Lastverteilung 

bringt Nagios nicht von Haus aus 

mit. Allerdings existieren eine Reihe 

von Add-ons, die Verteilungsfunktionen 

nachrüsten. OpenNMS dagegen kann von 

vornherein einzelne Daemons auf verschiedenen 

Servern laufen lassen. Auch 

Icinga macht das mit Icinga-Web besser 

und gestattet das Auslagern von Core, 

Datenbank und Webinterface auf verschiedene 

Systemen. Zudem hat es mit 

IcingaMQ ein modernes Framework für 

das verteilte Monitoring der Zukunft in 

der Schublade. Auch Zabbix beherrscht 

das verteilte Monitoring bei sehr vielen 

Nodes. 

Fazit 

Für die Auswahl der individuell besten 

Monitoringlösung gibt es kein Patentrezept, 

aber einen Rat kann man geben: 

Ausprobieren! Alle Lösungen lassen sich 

relativ problemlos installieren, von einigen 

findet man auch fertige VMs wie beispielsweise 

das Icinga-Starterkit [5] oder 

die Zabbix-Appliance bei VMware [6]. 

Ansonsten ist auch die Installation aus 

Paketen oder Sourcen in der Regel nicht 

schwer, nur Zabbix kann ein kleines Problem 

sein, weil es ein PHP mit einkompiliertem 

Modul »bcmath« voraussetzt. Wo 

das fehlt, wird es umständlich. (jcb) n 

Abbildung 3: Icinga, hier mit dem Plugin Business Process View, bietet eine moderne und innovative Web- 

Benutzeroberfläche. 

Infos 

[1] OpenNMS: [http:// www. opennms. org] 

[2] Zabbix: [http:// www. zabbix. com] 

[3] Icinga: [http:// www. icinga.org] 

[4] Nagios: [http:// www. nagios. org] 

[5] Icinga-Starterkit: [https:// www. icinga. org/ 

2010/ 09/ 22/ starter‐kit‐icinga‐virtualappliance/] 

[6] Zabbix-Appliance: [http:// www. vmware. 

com/ appliances/ directory/ 353] 


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 01/2011 admin 02/2011 admin 03/2011 

admin 04/2011 admin 05/2011 admin 06/2011 

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


Nagios-Ableger 

© Alena Ozerova, 123RF 

Von Nagios abgeleitete Monitoring-Lösungen im Vergleich 

Zwillingsforschung 

Wie man sie auch bewerten mag – als überflüssige Dubletten, als kurzlebige Konkurrenz oder als wertvolle Bereicherung 

– Tatsache ist: Im Nagios-Umfeld hat sich eine bunte Palette aus oft ähnlichen Abkömmlingen und 

Nachfolgern, verschiedenen Integrationsprojekten und Erweiterungen entwickelt. Jens-Christoph Brendel 

Im Vergleich mit seinen vielen Verwandten 

versucht sich Nagios [1] als das Original 

zu positionieren, das in einer langen 

Entwicklungszeit zu unschlagbarer Reife 

und Stabilität gefunden und die größte 

Community auf sich verschworen hat. Ob 

es dabei auch mit Blick auf die Features 

tatsächlich die Nase vorn hat oder ins 

Hintertreffen geraten ist, das lässt sich 

insofern nicht pauschal beantworten, 

als einige der fraglichen Features zwar 

der Nagios Community-Edition fehlen, 

im kommerziellen und kostenpflichtigen 

Nagios XI aber verfügbar wären. Manchmal 

kommt man mit einem Nagios-Derivat 

aber immerhin unentgeltlich in den 

Genuss der Erweiterungen – manchmal 

werden aber auch für Enterprise-Varianten 

der Klone stolze Summen fällig. 

Eine verwandte Problematik ergibt sich 

durch Plugins, die jeden Nagios-Ableger 

um eine vermisste Funktion nachrüsten. 

Etliche Probanden heben sich hier dadurch 

ab, dass sie zum Vorteil für den 

Nutzer einen sinnvollen Mix dieser Addons 

bereits vorinstalliert haben. Andere 

gibt es als Software- oder Hardware- 

Appliance für den Plug-and-Play-Betrieb. 

Wie sehen sich die Nagios-Spielarten nun 

aber selbst? Was meinen sie besser zu 

können als das Vorbild? Wo sehen sie 

ihren Unique Selling Point? Wir haben 

bei einer ganzen Reihe solcher Projekte 

nachgefragt: Warum sollte man ihre 

Nagios-Version dem Original vorziehen?. 

Und das erhielten wir zur Antwort: 

Groundwork 

Groundwork versteht sich im Unterschied 

zu Nagios nicht nur als einfaches 

Monitoringprodukt, sondern als eine offene 

Plattform für die Überwachung und 

Verwaltung von Applikationen und Nachrichtenströmen 

im Netzwerk, in physischen, 

virtuellen oder Cloud-basierten 

Umgebungen. Groundwork will das dank 

seiner Integration vieler Open-Source- 

Programme leisten, darunter RRDTool, 

NeDi, Cacti oder NagVis. 

Groundwork [2] sieht sich dabei in einer 

ganz ähnlichen Rolle wie ein Linux- 

Distributor: Es liefert eigenen Code, der 

unterschiedliche freie Komponenten verbindet, 

und es steuert Performanceverbesserungen 

bei. So erhält der Kunde ein 

im Vergleich zu Nagios umfangreicheres 

und leistungsfähigeres Toolset. Daneben 

ergeben sich weitere Vorteile: 

n Eine voll dokumentierte XML/SOAP- 

API für die Zusammenarbeit etwa mit 

einem Ticketing-System oder einer 

CMDB. 




In dasselbe Horn stößt auch Open IT- 

Cockpit [4]. 

Open IT-Cockpit: „Open IT-Cockpit bietet 

deutlich mehr als nur reines technisches 

Infrastruktur-Monitoring – im Unterschied 

zu den meisten Nagios-basierten 

Varianten oder Forks. Der Fokus des 

Projektes liegt darauf, Business-Anforderungen 

an intelligente Überwachungssysteme 

zu erfüllen. Dazu gehören zum Bein 

Eine Konfigurationsdatenbank, die die 

Administration erleichtert. 

n Ein Portal auf der Grundlage von 

JBosss, in das sich auch kundenspezifische 

Widgets und Dashboards einbinden 

lassen. 

n Cloud-Konnektoren. 

n Bessere Skalierbarkeit und Performance 

als beim originalen Nagios. 

Dank Groundwork soll der gegenwärtige 

Nagios-User zum einen sein Know-how 

und die darin investierte Zeit und Mühe 

weiter nutzen und alle bereits erstellten 

Nagios-Konfigurationen importieren können, 

zum anderen bekommt er eine Zahl 

von zusätzlichen Features und die Integration 

weiterführender Open-Source- 

Projekte obendrauf. 

isyVmon 

Jeder Vorteil, den ein Nagios-Ableger ins 

Feld führt, ist natürlich zugleich ein stummer 

Vorwurf an Nagios, entsprechende 

Features nicht selbst bereitzustellen und 

so argumentiert dann auch das Projekt 

isyVmon [3] zuerst mit einer langen Liste 

an Nachteilen, die das reine Nagios aus 

seiner Sicht hat. 

isyVmon: „Schon bei den ersten Projekten 

bekamen wir die Nachteile einer reinen 

Nagios-Lösung aufgezeigt, darunter 

das rudimentäre und unflexible Webinterface 

oder die fehlenden Möglichkeiten für 

anschauliche Management-Reportings. 

Zudem wird die Administration sehr 

schnell unübersichtlich, wenn es viele 

Systeme und/oder Checks gibt. 

Komplexere Konfigurationen, etwa das 

Einbinden weiterer Standorte, erfordern 

bei Nagios detailliertes Know-how und 

hohen Aufwand. Jede Konfiguration 

muss in die Kommandozeile eingetragen 

und gepflegt werden. Nagios ist nur teilweise 

mandantenfähig (das Webinterface 

selbst gar nicht). Ein zentrales Management 

fehlt. So bleibt der Betrieb einer 

Nagios-Installation zeitaufwändig. 

Das eigentliche Monitoring beherrscht 

Nagios hervorragend. Warum sollte man 

das also ersetzen oder neu erfinden? 

Stattdessen baut isyVmon auf Nagios auf 

und nutzt dessen gewohnte Flexibilität – 

bereinigt um die oben erwähnten Nachteile 

einer reinen Nagios-Lösung. 

isyVmon wird im Umfeld der IT-Security- 

Beratung entwickelt. Das heißt nicht unbedingt, 

dass isyVmon sicherer ist als 

vergleichbare Produkte, aber es heißt, 

dass die Entwickler ihre Kunden und sehr 

viele beim Kunden eingesetzte Produkte 

sehr genau kennen – im Detail, im Betrieb, 

auch im Bereich Managed Security 

Services. Damit wissen wir sehr gut, was 

wir mit isyVmon monitoren wollen und 

müssen. Beispielsweise haben wir das 

Logmanagement-Tool Splunk in isyVmon 

integriert, nachdem es bei sehr vielen 

Kunden im Einsatz ist.“ 

Open IT-Cockpit 

Abbildung 1: Die Architektur von isyVmon – orange die zusätzlichen Module dieser Lösung. 

spiel die Geschäftsprozessüberwachung, 

IT-Service-Dashboards, SLA-Monitoring, 

SAP-Monitoring, End-to-End-Messungen, 

Eventkorrelation, Reporting und vor allem 

die Integration von angrenzenden 

Applikationen wie Ticketsystemen oder 

CMDBs über eine entsprechende API. 

Open IT-Cockpit besitzt zudem ein umfangreiches 

und leicht zu bedienendes 

Webfrontend zur Konfiguration und Administration 

von Nagios. Benötigte man 

für die Verwaltung des Originals noch 

erweiterte Nagios- und Linux-Kenntnisse, 

lässt sich Open IT-Cockpit einfach und 

intuitiv von jedermann bedienen. 

Open IT-Cockpit bietet ein Webfrontend, 

das mehrere Open-Source-Tools integriert 

und zu einer Einheit verschmilzt (Umbrella 

Management System). Ein Beispiel: 

Während bei anderen Projekten bereits 

eine eigene Kartenverwaltung kostenpflichtig 

hinzubestellt werden muss, ist 

für diese Zwecke bei Open IT-Cockpit 

ohne Aufpreis NagVis implementiert. 

Open IT-Cockpit eignet sich besonders 

zur Überwachung komplexer, unübersichtlicher 

oder über mehrere Standorte 

verteilter Infrastrukturen.“ 

Shinken 

Auch die Entwickler von Shinken [5] 

sind sich sicher, manches besser machen 

zu können als das Vorbild. Sie integrieren 

allerdings das originale Nagios nicht, 

sondern entwickeln es in Python von 

Grund auf neu. Was kann ihre Lösung, 

was Nagios nicht kann? Die Antworten 

kommen Schlag auf Schlag: 

Shinken: „Zum Beispiel skalieren. Durch 

die Aufteilung in spezialisierte Prozesse 

wird bei Shinken bereits ein Minimalsystem 

so weit entzerrt, dass Bottlenecks 

vermieden werden. Jede Komponente 

einer Shinken-Installation kann in beliebiger 

Zahl vorhanden sein und auf einem 

beliebigen Rechner laufen. Bei wachsender 

Anzahl von überwachten Objekten 

wächst das Monitoring-System einfach 

mit. Dies kann auch dynamisch geschehen, 

indem man Worker-Prozesse in eine 

Cloud verlagert und einfach zu- oder abschaltet. 

Trotz dieser flexiblen Architektur 

wird nur eine einzige Konfiguration 

gepflegt. Shinken kümmert sich um die 

ausgewogene Verteilung der Monitoring- 

Aufgaben. 

E 


Admin 


51



Abbildung 2: Der Host-Editor von OpMon erlaubt es, die Daten der zu überwachenden Hosts via Webformular 

einzugeben. 

Shinken bietet zudem mehr Ausfallsicherheit. 

Die Möglichkeit, mehrere Prozesse 

des gleichen Typs laufen zu lassen, 

dient nicht nur der Lastverteilung. Beim 

Ausfall eines Prozesses übernehmen die 

anderen dessen Aufgaben. Auch ist es 

möglich, Prozesse nur im Standby-Modus 

zu starten. Shinken kümmert sich dabei 

selbstständig um das Failover. 

Dedizierte Worker-Prozesse (die Plugins 

ausführen) können dort laufen, wo sie 

benötigt werden, beispielsweise in einer 

DMZ oder an einem Außenstandort. 

Checks für entsprechend markierte Hosts 

werden von Shinken automatisch zu diesen 

Workern geroutet. 

Eine eigene Logik für Business-Prozesse 

ist nativ in Shinken enthalten. Services 

können ein vordefiniertes Kommando 

»bp_rule« verwenden, dessen Argumente 

logische Verknüpfungen mit anderen 

Services sind. Der Status wird 

Abbildung 3: Auch die Community Edition von Opsview kennt schon eine grafische Darstellung der 

Netzwerkumgebung,. 

dann durch die Berechnung dieser logischen 

Formeln ermittelt. 

Im Unterschied zu Nagios kennt Shinken 

Prioritäten für Objekte. Das neue 

Attribut »business_impact« erlaubt die 

Kategorisierung von Hosts und Services 

nach ihrer Wichtigkeit. Dazu vergibt man 

Werte von »0« (unwichtig, Testsystem) 

bis »5« (hoch kritisch). Man kann damit 

etwa einstellen, dass nachts nur bei Ausfüllen 

von Hosts oder Services mit einem 

»business_impact« größer »3« Notifications 

verschickt werden. 

Probleme und Impacts: Für Shinken ist 

Critical nicht gleich Critical. Fällt zum 

Beispiel ein Switch aus, so wird er und 

alle dahinter hängenden Hosts als defekt 

angezeigt. Vorausgesetzt, es wurde eine 

Parent-Child-Beziehung zwischen dem 

Switch und den Hosts definiert, erkennt 

Shinken, dass der kaputte Switch ein 

Problem und die als Down angezeigten 

Hosts daraus resultierende Impacts sind. 

In der GUI gibt es eine eigene Sicht dafür. 

Man kann sich also durch Klick auf einen 

Host die Ursache anzeigen lassen sowie 

durch einen Klick auf den Switch die 

Auswirkungen des Defekts.“ 

NetEye 

Zahlreiche Funktionen, die es beim originalen 

Nagios nicht in dieser Form gibt, 

kann auch NetEye [6] aufzählen: 

NetEye: „Mit dem Modul Asset- und Inventory 

Management kann NetEye beispielsweise 

ein automatisches Inventar 

der Arbeitsplätze erstellen. Dafür integriert 

es die Open-Source-Projekte GLPI 

und OSC Inventory. Informationen zu 

Notebooks, Desktops, Monitoren, Druckern, 

Netzwerkgeräten und Servern 

werden in einer eigenen Datenbank automatisch 

gesammelt. Nach der Aktivierung 

dieses Dienstes ist es möglich, eine 

detaillierte Liste der Konfigurationen aller 

Hardware- und Softwarekomponenten im 

Netz zu erzeugen. 

Hersteller Würth Phoenix hat zudem mit 

Safed Agent einen universell einsetzbaren 

Syslog-Agenten unter der GPL entwickelt, 

der alle gängigen Plattformen unterstützt. 

Er liest Betriebssystemevents von Windows 

wie auch generische Logfiles und 

lässt sich einen eingebetteten Webserver 

konfigurieren, der HTTP sowie HTTPS 

unterstützt. 

C 

M 

Y 

CM 

MY 

CY 

CMY 

K 




Eine speziell entwickelte Message Console 

erlaubt die Auflistung klassifizierter 

Störfälle mit frei konfigurierbaren Fehlerklassen 

und Filterregeln. Das Web Service 

Monitoring wird wiederum durch ein eigens 

realisiertes Modul unterstützt. Als 

Basis-Engine wird hier das Open-Source- 

Projekt Webinject genutzt. Rund um 

Web inject entstand eine Web-Oberfläche, 

in die Test-Szenarien eingegeben werden 

können. Damit lassen sich auf einfache 

Art und Weise intelligente Checks für 

Web-Anwendungen realisieren. 

Der in NetEye integrierte SNMP-Trap- 

Handler kann verschiedene Filter- und 

Kategorisierungsmöglichkeiten über ein 

speziell entwickeltes Interface verwalten. 

Die gesammelten Daten können 

auch in die Message Console oder den 

Nagios Service Check Acceptor (NSCA) 

einfließen. Umfassende Suchfunktionen 

helfen dem Administrator dann anschließend 

beim Auffinden der zu analysierenden 

Traps. 

getD_043_Magazine_Ad_3.ai 1 6/22/11 9:22 PM 

Die Komponente Network Access Monitor 

erlaubt es, auf einfache Weise festzustellen, 

ob ein fremdes Gerät im Netz 

angeschlossen wurde, dessen Ports der 

Monitor dann auf Wunsch automatisch 

in ein isoliertes VLAN verschieben kann. 

Auf diesem Weg wurde ein einfaches Network 

Access Control-Modul mit geringer 

Komplexität realisiert. 

Das Modul Network Traffic Monitor wiederum 

nutzt das Open-Source-Projekt 

NFSEN, das in der Lage ist, NetFlow- 

Ströme von Routern und Switches auszuwerten. 

Die Daten lassen sich dann in 

eigene Profile aggregieren, sodass sich 

eine klare Darstellung der Bandbreite 

auf Applikationsebene ergibt. Durch das 

Ablegen der Profile in RRD-Files lassen 

sich auch Trendanalysen der Bandbreitennutzung 

auf Applikationsebene über 

ein ganzes Jahr hinweg realisieren. Damit 

ist ein Capacity Management wahlweise 

auf Jahres-, Monats- oder auch Wochenebene 

möglich. 

Ein speziell entwickeltes BSM-Modul erlaubt 

es NetEye schließlich, die Auswirkungen 

von IT-Störfällen auf Geschäftsprozesse 

darzustellen. Auch lassen sich 

Störungen simulieren (Business Impact 

Analyse). Mithilfe von NagVis wird auch 

ein Dashboard zur visuellen Darstellung 

zur Verfügung gestellt. Dies hilft 

bei der schnellen Identifizierung defekter 

Hardwarekomponenten und erlaubt 

eine logische Darstellung der eigenen IT- 

Infrastruktur mit einem frei definierbaren 

Detailierungsgrad.“ 

OpMon 

Einen etwas anderen Ausgangspunkt hat 

OpMon [7]: Hier waren es brasilianische 

Admins, die sich mit dem englischsprachigen 

Nagios schwertaten, weshalb die 

Firma OpServices in Sao Paulo eine Übersetzung 

der Software ins brasilianische 

Portugiesisch anfertigte. Und weil man 

einmal dabei war, baute man auch gleich 

IT-Admin? Computerfreak? Technikfan? 

Dann schau rein bei getDigital.de, dem Shop mit Gadgets, 

T-Shirts und Geschenken für Geeks und alle Computerfans! 

USB Gadgets 

USB Stressball 

=C23,90 

Drücken lässt 

den Bildschirm 

schrumpfen! 

USB Webcam Raketenwerfer 

Mit Webcam 

und fernsteuerbar 

per 

Skype! 

=C59,95 

Tools für Nerds T-Shirts für Admins Vorteilsgutschein 

USB Batterien 

ab 

=C16,95 

Batterien sind am USB-Anschluss 

aufladbar. 

Anyloader 

Lädt Handy und 

Co. mit 

Solarstrom. 

=C34,95 

=C= 34 

Turning it off and on again 

No. 

Alternativ 

geht 

natürlich 

auch diese 

Antwort. 

ab 

=C14,90 

Die 

Standardantwort 

im Support 

ab 

=C15,90 

RFID Schutzhülle 

=C4,95 

Mit dem Gutscheincode 

ITAM_TKKNRQ 

gibt es für Leser des IT-Admin- 

Magazins eine RFID Schutzhülle 

kostenlos zur Bestellung dazu! 


Admin 

www.getdigital.de 


53



noch ein paar Funktionen ein, die sich 

die Anwender wünschten. Beispielsweise 

ein eigenes, mehrsprachiges PHP-Webinterface, 

neue Report-Module und einen 

Scheduler für Reports, die die Bereiche 

SLAs, Capacity Planning oder Verfügbarkeit 

abdecken. 

Ganz oben auf der Wunschliste der Anwender 

stand auch eine bessere Visualisierung 

des Status der überwachten 

Prozesse. Dafür entstand das mächtige 

Dashboard DaVINCI, das auch in andere 

Nagios-Installationen integrierbar ist. 

Etliche der neuen Komponenten erforderten 

eine leistungsfähige Datenbankunterstützung, 

die erst noch geschaffen werden 

musste, was dann auch einen webbasierten 

Konfigurator möglich machte. Im 

Moment wollen die Entwickler OpMon 

als ITIL-Tool weiter ausbauen und einen 

Service Desk sowie eine CMDB. (OTRS) 

integrieren. 

OP5 

Skalierbarkeit, Benutzerfreundlichkeit 

und ein besseres Reporting zählt auch OP5 

[8] zu seinen Alleinstellungsmerkmalen. 

Das eigens dafür entwickelte Backend 

Merlin [9] offeriert dabei Loadbalancing 

und diverse Hochverfügbarkeitsszenarien 

in Nagios-Umgebungen. Zudem enthält 

es eine Datenbankschnittstelle, die auch 

andere Komponenten benutzen. 

Eine moderne, schnelle Ajax-basierte 

Oberfläche mit intuitiven Such- und 

Sortierfunktionen garantiert eine hohe 

Benutzerfreundlichkeit und erlaubt 

es nicht nur Nagios-Spezialisten, den 

Status aller IT-Prozesse im Auge zu behalten. 

Dabei kann nahezu jeder Messwert, 

den ein Systemcheck erhebt, in 

einem aussagekräftigen Graphen visualisiert 

werden. 

Dazu kommen eigene Reports, etwa zu 

Service Level Agreements oder zur Verfügbarkeit 

und ein eigenes Dashboard 

mit individuell konfigurierbaren Widgets 

sowie datenbankgestütztem Status. 

Schließlich verweist OP5 auch auf seinen 

kompetenten Support, den es – auch zusammen 

mit Partnern – international für 

600 Installationen anbietet. 

Opsview 

Auch Opsview [10] verweist gerne auf 

seinen weltweiten Support, ein Partnernetzwerk 

und namhafte Referenzkunden 

wie Symantec, Telefonica, Sky, Fujitsu 

oder die Allianz. Bei seinen Verbesserungen 

gegen den originalen Nagios setzt 

Opsview bei denselben Schwachstellen 

an wie viele seiner Mitbewerber: Es bietet 

bessere Reports, eine bessere Benutzerschnittstelle, 

bessere Skalierbarkeit und 

eine bessere Visualisierung. Dafür übernimmt 

es zahlreiche freie Add-ons. 

Einige der zusätzlichen Module setzen 

allerdings den Abschluss einer Enterprise 

Subscription voraus, die schon für 

schlappe 10 000 Dollar zu haben ist. Dafür 

bekommt man dann einen Connector, 

der automatisch Tickets im Service-Desk- 

System generiert, Alarme via SMS, eine 

Opsview-Testumgebung mit automatischer 

Synchronisation von Änderungen 

und Reports (auf der Grundlage von Jasper 

Reports), die automatisch erstellt und 

etwa im PDF-Format auch selbstständig 

verteilt werden. 

Centreon 

Centreon [11] verfolgt ein ganz ähnliches 

Konzept mit kommerziellen Modulen 

wie Opsview. In seinem Fall ist es unter 

anderem eine Erweiterung, die eine 

Darstellung der überwachten Objekte in 

interaktiven Karten realisiert, in die man 

hineinzoomen kann (Centreon MAP). 

Dazu gibt es auch hier ein spezielles Addon 

für das Reporting (Centreon BI) und 

ebenfalls eines für die Geschäftsprozessüberwachung: 

Business Activity Monitoring 

(Centreon BAM). 

Das alles kann man auf Wunsch eingebettet 

in eine spezielle Linux-Distribution 

auf der Grundlage von CenOS haben, 

dem Centreon Enterprise Server (CES). 

Dieser Server ist in vier Abstufungen zu 

haben. Während „Standard“ noch kostenlos 

ist,muss man für die höchste Ausbaustufe 

„Complete“ schon bis zu 14 000 

Dollar im Jahr bezahlen. 

n 

Abbildung 4: Auch Centreon kennt im Unterschied zum originalen Nagios eine webbasierte GUI für die 

Konfiguration – hier der Hosteditor. 

Infos 

[1] Nagios: [http:// www. nagios. org] 

[2] Groundwork: [http:// www. gwos. com] 

[3] isyVmon: [http:// www. isyvmon. com/ de/ 

home. html] 

[4] Open IT-Cockpit: 

[http:// www. open‐itcockpit. com] 

[5] Shinken: 

[http:// www. shinken‐monitoring. org] 

[6] NetEye: [http:// www. wuerth‐phoenix. com/ 

de/ loesungen/ wuerthphoenix‐neteye/] 

[7] OpMon: [http:// www. opservices. com. br] 

[8] OP5: [http:// www. op5. com] 

[9] Merlin-Backend: 

[http:// www. op5. org/ community/ 

plugin‐inventory/ op5‐projects/ merlin] 

[10] Opsview: [http:// www. opsview. com] 

[11] Centreon: [http:// www. centreon. com] 


Linux-Magazin 

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

*Zertifizierung als „Junior Level Linux Professional“ 

(zzgl. MwSt.) 

100% flexibel! 

Weitere Infos: academy.linux-magazin.de/solution



© poco_bw, Fotolia 

Im Test: Open IT-Cockpit Version 2.6.5 

Kontrollzentrale 

Nagios-Ableger gibt es mittlerweile viele. Open IT-Cockpit setzt auf reduzierten Funktionsumfang und Übersichtlichkeit. 

Was das im Detail bedeutet, verrät dieser Test. Bernhard Fahr 

Die Zeit der Dinosaurier ist vorbei: Nagios 

und eine Reihe von Open-Source-Tools 

mischen seit einiger Zeit den Markt für 

Systemmanagement und Monitoring auf. 

Sie überzeugen durch einen aufs Wesentliche 

reduzierten Funktionsumfang, 

große Flexibilität und nicht zuletzt niedrige 

(keine) Lizenzkosten. Ein Vertreter 

dieser Gattung ist Open IT-Cockpit, das 

von dem Fuldaer Dienstleister it-novum 

unter einer Open-Source-Lizenz veröffentlicht 

wurde. 

Open IT-Cockpit steht unter der GPLv2 

und ist laut der Community-Webseite [1] 

als zentrales Umbrella-Managementsystem 

konzipiert. Die Anwendung ist im 

Laufe verschiedener Systemmanagementprojekte 

entstanden. Am Anfang stand 

eine Nagios-Lösung, die laufend weiterentwickelt 

und ergänzt wurde. Seit Juni 

2010 steht Open IT-Cockpit unter einer 

Open-Source-Lizenz und lag für diesen 

Test in Version 2.6.5 vor. Nach Angaben 

des Herstellers soll Ende Januar 2012 Version 

2.7.1 veröffentlicht werden. 

Der Installer von Open IT-Cockpit unterstützt 

Linux-Derivate wie Ubuntu 10.04, 

Debian 6.x, OpenSuse 11.2 und Suse 

Linux Enterprise 11. Zu Testzwecken haben 

wir uns für Suse Linux Enterprise 11 

SP1 x86_64 entschieden. Die Installation 

sollte analog zum lizenzfreien OpenSuse 

11.1 x86_64 ablaufen. Für die Installation 

haben wir den neuen Shell-Skript- 

Installer gewählt. Nachdem es einige 

Kritik an dem alten Installer gab, weil er 

nur von einer externen Community-Seite 

heruntergeladen werden konnte, haben 

die Entwickler nachgezogen: Seit Kurzem 

gibt es ein eigenes Installationsskript 

(Version 0.1) auf der Open-IT-Cockpit- 

Communityseite. 

Anpassbar 

Ist die Tar-Datei von [2] entpackt, sieht 

man die Ordnerstruktur mit mehreren 

Include-Skripten zur nahtlosen Integration 

in die verschiedenen Derivate, die 

in das Hauptskript »install.sh« integriert 

sind. Nach den Angaben auf der 

Webseite werden neben 32- und 64-Bit- 

Systemen auch nicht gelistete Systeme 

grundsätzlich unterstützt – allerdings erst 

nach manueller Anpassung des Installer- 

Skripts. Wir empfehlen nur bedingt, von 

dieser Option Gebrauch zu machen. Neben 

Änderungen an Paketen, Libraries 

oder Abhängigkeiten spielt nämlich auch 

die unterstützte PHP-Version (zurzeit maximal 

5.2.x) eine entscheidende Rolle. 

Es ist deshalb denkbar, dass es unter 

neueren Derivaten wie Debian 6.0.1 oder 

ab OpenSuse 11.1 kleinere Probleme gibt, 

denn dort kommt bereits die neuere PHP- 

Version 5.3 zum Einsatz. In der Community 

sind aber bereits Bugfixes veröffentlicht 

worden. In Open IT-Cockpit 2.7.1 

ist dieses Problem behoben, die Version 

funktioniert mit PHP 5.3. 

Mit dem Shell-Befehl »lsb_release ‐d« 

lässt sich die exakte Bezeichnung des eigenen 

Linux-Derivats feststellen, um sie 

im Installer selbst von Hand anzupassen. 

Experimentierfreudige User sollten einen 

Blick in die »install.sh« unter der Funktion 

»Main«, Unterpunkt »# detect the 

system you are using« werfen, wo sich 

die Versionsprüfung befindet. 

Ist die komplett menügeführte Installation 

erst einmal angestoßen, läuft sie reibungslos 

durch und lädt neben Paketen 

und ihren Abhängigkeiten sämtliche zur 

Installation erforderlichen Komponenten 




selbstständig herunter. Neben Angaben 

zum Proxy (sofern noch nicht eingerichtet) 

werden Login-Daten für Datenbank, 

Weboberfläche oder auch die Lage der 

Datenbank (interessant bei separatem 

Hosting) abgefragt. 

Alle Änderungen in den Konfigurationen 

von Nagios, der Rechtevergabe, die Userbeziehungsweise 

Gruppenzuordnungen 

und der Weboberfläche nimmt der Installer 

automatisch selbst vor, sodass das 

System nach Abschluss der Installation 

sofort startklar ist. 

Der erste Kontakt 

Die Oberfläche von Open IT-Cockpit ist in 

PHP entwickelt und enthält einige Ajax- 

Elemente. Sie ist wahlweise englisch oder 

deutsch und zum größten Teil selbsterklärend. 

Nach erfolgreicher Installation 

loggt man sich mit dem Browser auf dem 

Monitoring-Server ein. Die Authentifizierung 

erfolgt über htaccess, dessen Login- 

Daten bereits bei der Installation angepasst 

wurden. Der erste Eindruck des 

Cockpits ist eine angenehm aufgeräumte 

Gesamtübersicht aller Host- und Service- 

Checks. Sie ist in zwei separate Graphen 

zusammengefasst, deren Details darunter 

zahlentechnisch dargestellt werden. 

Im Cockpit erhält man zügig einen Überblick 

über den Gesundheitszustand der 

kompletten Infrastruktur nebst Downtimes 

(Abbildung 1). Alternativ kann zur 

statusabhängigen Listenansicht gewechselt 

werden. Sie zeigt in Kurzform alle 

Hosts oder Services mit dem Status an, 

Links zur Dokumentation und den Performancedaten 

sind ebenfalls vorhanden. 

Die Liste kann im PDF-Format gespeichert 

werden. Eine Info-Box enthält die 

direkten statusorientierten Verlinkungen, 

zum Beispiel zu noch unbehandelten 

oder geplanten Problemen. 

Bei einer großen Zahl von Hosts beziehungsweise 

Services und lediglich kleineren 

Ausfällen kann man auf der Graphenansicht 

jedoch nicht mehr allzu viel 

erkennen. Man sollte daher immer auch 

die Zahlen darunter im Auge behalten. 

In allen Menüs befindet sich im linken 

oberen Rand eine Schnellsuchfunktion 

mit optional erweiterter Suche. Dadurch 

lassen sich Hosts direkt oder nach bestimmten 

Kriterien finden – das funktioniert 

gut und erleichtert die tägliche Ar- 

beit enorm. In manchen Menüs werden 

Radio-Buttons oder Check-Boxen nicht 

direkt betitelt, stattdessen öffnet sich die 

entsprechende Quickinfo-Box beim Verweilen 

mit dem Mauszeiger. Auch wenn 

uns die Open IT-Cockpit-Weboberfläche 

sehr gut gefällt, kann man die klassische 

Nagios-Oberfläche über »http://Host‐IP/ 

openitc/old/« erreichen. 

Der intuitiven Oberfläche sei Dank gestaltet 

sich das Einrichten der Devices 

und Service-Checks sehr einfach. Für den 

besonders schnellen Einstieg steht einem 

zudem ein Wizard zur Seite (Abbildung 

2). Nach der Einrichtung kann man in 

den detailierten Host-Informationen verschiedene 

Kommandos wie das manuelle 

Ausführen eines Checks oder das passive 

Senden eines Status zur Kontrolle vornehmen. 

Kleiner Wermutstropfen: Eine 

automatische Host-/Service-Discovery 

fehlt leider in der Community-Version 

und wird nur im Projektrahmen von itnovum 

angeboten. 

Die Import-/Exportfunktion 

Import-/Exportfunktionen befinden sich 

unter dem Reiter »Konfiguration | Import/Export« 

und sind für die Anpassung 

und Übertragung der geänderten Host-, 

Service-, Benachrichtigungsdaten und 

so weiter an den Nagios-Kernel zuständig. 

Es empfiehlt sich daher, nach dem 

ersten Login mithilfe des Host-Wizards 

(»Konfiguration | Systemkonfiguration«) 

mindestens einen Host (zum Beispiel localhost) 

und einen Service-Check (etwa 

LAN-PING) anzulegen und im Anschluss 

den Export durchzuführen. Erst dadurch 

werden die Devices für die Überwachung 

aktiviert. Generell empfiehlt es sich, bei 

der Export-Funktion die vorbelegte Option 

»cli restart« im Drop-down-Menu zu 

nutzen. Sie nimmt nicht nur ein Backup 

der alten Konfiguration vor, überprüft 

und spielt die neue Konfiguration ein, 

sondern führt auch einen kompletten 

Neustart des Nagios-Kernels durch. 

Erweitert 

Die gute Auswahl an Plugins und fertigen 

Servicevorlagen ermöglicht (mit kleineren 

Anpassungen) die schnelle Konfiguration 

einer Systemlandschaft. Grundfunktionalitäten 

wie Erreichbarkeit, Speicher-, 

CPU-, Festplattenauslastung und so weiter 

deckt Open IT-Cockpit problemlos 

ab. Die Schwellwerte, Prüfintervalle und 

Verhaltensweisen bei Statusänderungen 

und so weiter müssen natürlich an die 

jeweiligen Unternehmensbedürfnisse angepasst 

werden. 

E 

Abbildung 1: Die Startseite von Open IT-Cockpit präsentiert eine Übersicht des Systemstatus. 


Admin 


57



Hier macht sich einer der großen Vorteile 

von Open IT-Cockpit bemerkbar: Durch 

die Verwandschaft mit Nagios kann 

man auf die riesige Menge an Nagios- 

Plugins mit kompletter Dokumentation 

und Fachbüchern der Nagios Community 

zurückgreifen. Natürlich sollte man dabei 

mit einer gewissen Einarbeitungszeit 

rechnen. Wem das zu mühsam ist, der 

kann das Know-how kaufen. In großen 

IT-Umgebungen sind eventuell auch die 

kostenpflichtigen Zusatzmodule, zum 

Beispiel für die Überwachung von SAP- 

Systemen, SLAs oder End-to-End-Monitoring 

interessant. 

Für unser Testsystem nehmen wir jedoch 

die Anpassungen selbst vor. Auch weitere 

Service-Vorlagen erstellen wir selbst mit 

eigenen Werten. Die funktionelle Oberfläche 

in Kombination mit Eigenarbeit 

trägt schnell Früchte: Wir haben nun die 

Möglichkeit, innerhalb kurzer Zeit kleine 

bis große Anlagen frei skalierbar einzurichten. 

Kontrolle 

Neben der Zeitersparnis durch die Automatisierung 

und Überblickbarkeit essenzieller 

täglicher Aufgaben in der Oberfläche 

bietet Open IT-Cockpit auch ausgefeilte 

Rechteverwaltung: Die Anwendung 

lässt sich durch jeden autorisierten Mitarbeiter 

der IT-Abteilung bedienen. Das Berechtigungssystem 

ist sehr komfortabel, 

die Rechte einfach einstellbar. Die User 

sind in Benutzergruppen unterteilt. 

Da Open IT-Cockpit mandantenfähig ist, 

lassen sich mehrere virtuell getrennte 

Systeme in einem einzigen Open IT- 

Cockpit verwalten und ihre Benutzer in 

verschiedene Berechtigungsgruppen unterteilen. 

Dank eines TVD-Kalenders kann man 

Verfügbarkeiten und Urlaubsvertretungen 

der IT-Mitarbeiter sehr einfach organisieren. 

Das klappt mithilfe der Zeitzonenunterstützung 

sogar für ausländische 

Standorte. Für die Benachrichtigungen 

im Bedarfsfall lassen sich Kontaktpersonen, 

Kontaktgruppen und deren Benachrichtigungszeiträume 

(Servicezeiträume), 

Kommunikationsmedium (E-Mail, SMS) 

und Benachrichtigungsstatus einpflegen. 

Der E-Mail-Versand ist durch den Einsatz 

eines Postfix-Servers unabhängig vom internen 

Mailserver möglich. Nicht zuletzt 

Abbildung 2: Der Host-Wizard hilft bei der Einrichtung der zu überwachenden Rechner. 

existiert auch ein Eskalationsmanagement 

für Kontaktpersonen. 

Bei der täglichen Arbeit mit der Open 

IT-Cockpit-Oberfläche stellt man schnell 

fest, dass nicht der komplette Funktionsumfang 

von Nagios zur Verfügung steht. 

Der Hersteller hat vielmehr versucht, ein 

gutes Verhältnis zwischen Einfachheit und 

Funktionalität zu finden, weil darin der 

Vorteil von Open IT-Cockpit als Umbrella- 

Management-Lösung liegt. Unserer Meinung 

nach wurde dieses Ziel erreicht. 

Die Graphen 

Zur Darstellung von Graphen verwendet 

Open IT-Cockpit PNP4NAGIOS. Dieses 

Drittanbieterprojekt ist parallel zu Nagios 

entstanden. Es dient nicht nur der 

Analyse von Performance-Daten und 

ihrer Speicherung in RRD-Datenbanken. 

PNP4NAGIOS liefert auch eine Auswahl 

an verschiedenen Templates. Dadurch 

lassen sich einfache wie komplexe (gesamter 

Netzwerk-Traffic) Graphen individuell 

darstellen und anpassen, zum 

Beispiel separat dargestellte In- und 

Output-Graphen. Sinnvoll ist auch die 

Mehrfach-Zoom-Funktion zur Detailanalyse 

des Graphen. Über ein Auswahlrechteck 

kann man den Graphen gezielt 

vergrößern. Schwellwertlinien zeigen an, 

ob der Status »Warning« oder »Critical« 

erreicht wurde. 

Auf der Community-Seite von Open IT- 

Cockpit befindet sich ein weiteres Projekt: 

NSTA (Version 0.2) holt Daten aus 

verschiedenen Nagios-Satellitensystemen 

und übergibt sie chronologisch an 

»nagios.cmd«. Sollten Satellitensysteme 

über eine verschlüsselte SSH-Verbindung 

temporär nicht erreichbar sein, werden 

die Ergebnisse in einer Spool-Datei zwischengespeichert 

und bei nächster Erreichbarkeit 

der Reihenfolge nach an 

Nagios geschickt. 

In einer guten Monitoring-Lösung darf 

die Option zum Zusammenfassen von 

Gerätegruppen nicht fehlen. Open IT- 

Cockpit unterstützt Gruppierungen von 

Hosts, Switches, Router, Firewalls und 

so weiter. So lassen sich beispielsweise 

Service-Checks in einer Art Massenverarbeitung 

ändern – das spart Zeit und 

schont die Nerven. 

Der Kernel 

Laut dem Forumsbeitrag eines it-novum- 

Consultants kommt es derzeit bei bestimmten 

Kombinationen von Nagios 

und NDO zu Fehleinträgen in der Nagios- 

Datenbank. Es handle sich um einen bekannten 

Fehler, der Grund für den derzeitigen 

Einsatz des Nagios-Kernel-Release 

3.2.1 sei. Sobald die Nagios Community 

den bereits existierenden Patch in den 

Nagios-Kernel integriert hat, soll er auch 

Eingang in Open IT-Cockpit finden. 

Open IT-Cockpit ist für Mozilla Firefox 

ausgelegt, da dieser betriebssystemunabhängig 

verwendet werden kann. Im 

Test traten aber auch mit dem Internet 

Explorer 8 keine Probleme auf. Die Per- 


formance des Gesamtpaketes liefert also 

keinen Grund zu Beanstandungen – alle 

Menüs wurden zügig angezeigt und waren 

schnell erreichbar. Wegen der vergleichbar 

intensiven CPU-Nutzung des 

Nagios-Kernels, ergeben sich Grenzen 

für die maximale Anzahl an Checks pro 

Minute. Eine sinnvolle Auswahl der Prüfintervalle 

wirkt sich daher positiv auf die 

Anzahl der Gesamtchecks aus. 

Zusätzliche Erweiterungen 

Neben den integrierten Erweiterungen 

von Drittanbietern steht dem Open-IT- 

Cockpit-Benutzer im Netz eine große 

Auswahl weiterer Drittprojekte mit entsprechender 

Dokumentation zur Verfügung. 

Wer spezielle funktionelle Erweiterungen 

wie etwa SAP- oder Business- 

Process-Monitoring benötigt, kann bei 

it-novum die entsprechende Dienstleistung 

einkaufen. Der nächste Abschnitt 

wirft einen näheren Blick auf einige der 

bereits integrierten, also kostenlosen Erweiterungen. 

In der Nagvis-Erweiterung lassen sich 

von der Infrastruktur bis hin zu verschiedenen 

Standorten oder dem Rechenzentrum 

im Detail alle Überwachungsobjekte 

visuell darstellen. Verschiedene Karten, 

die man übereinander verschachteln 

kann, helfen durch Vererbungen zügig 

bei der Ursachenfindung. Neben den 

bereits existierenden Grafiken können 

eigene Karten (als PNG-Datei) hochgeladen 

werden. In der Oberfläche kann 

man sie unter »Konfiguration | Kartenverwaltung 

| Karteneditor | rechte Maustaste 

auf Karte | Verwalte | Hintergründe« 

importieren. Die Hintergründe können 

als Grundlage für verschiedene Karten 

dienen, mit denen auch aktive Elemente 

abgespeichert werden. Neben Fotos oder 

Grafiken lassen sich auch Struktogramme 

verwenden. Im gleichen Menü (unter 

»Objekte hinzufügen«) lassen sich aktive 

Elemente mit Icon- oder Linienauswahl, 

Größe, Koordinaten und so weiter anlegen. 

Die Bedienung ist hier nicht ganz so 

intuitiv, sodass es einer gewissen Eingewöhnungszeit 

bedarf. 

Das hilfreiche Zusatzmodul DokuWIKI 

liefert ein eigenes editierbares Wiki und 

ist im Host-Informations-Menü neben den 

Bearbeitungsbuttons erreichbar. Dadurch 

kann man zu jedem Host eine frei editier- 

bare Wiki-Seite pflegen, um im Fehlerfall 

schnell fündig zu werden. Die Bedienung 

ist selbsterklärend, allerdings ließen sich 

nach der Installation die Seiten und Menüs 

nicht bearbeiten. Im Forum findet 

sich dazu die Aussage, dieser Bug sei 

bekannt und werde in naher Zukunft behoben. 

Abhilfe schafft zwischenzeitlich 

die erneute Vergabe eines Passwortes im 

Reiter »Cockpit«, Menüpunkt »Persönliche 

Einstellungen« im Unterpunkt »Passwort 

ändern«. Nach dem Speichern funktionierte 

im Test alles einwandfrei. 

Fazit 

Das neue Projekt Open IT-Cockpit ist ein 

leistungsfähiges und sehr performantes 

Überwachungstool. Es wartet mit einigen 

interessanten Features auf, die andere 

Tools nicht liefern. Nach der Beseitigung 

des umständlichen und irritierend 

wirkenden Installationsweges über eine 

Drittwebseite, stellt Open IT-Cockpit 

derzeit eine der besten Ergänzungen zu 

Nagios dar. Binnen kurzer Zeit lassen 

sich Systeme einrichten und selbst komplexe 

Konstellationen, exotische Hosts 

oder heterogene Umgebungen abbilden. 

Auch weniger erfahrene Administratoren 

können Open IT-Cockpit leicht installieren, 

im Gegensatz zur oft aufwändigen 

Nagios-Einrichtung. Natürlich konfiguriert 

sich auch Open IT-Cockpit nicht von 

selbst. Investiert man aber zu Beginn 

etwas Zeit in einen ordentlichen Aufbau 

und die saubere Anpassung der verschiedenen 

Checks sowie der Vorlagen, zahlt 

sich das durch große Arbeitserleichterung 

beim Betrieb aus. Die erwähnten Bugs 

und die fehlende Unterstützung weiterer 

Linux-Derivate sind kleine Wermutstropfen. 

Es ist jedoch zu hoffen, dass sie 

in den nächsten Releases der Software 

behoben werden. (ofr) 

n 

Infos 

[1] Open IT-Cockpit: 

[http:// www. open‐itcockpit. com] 

[2] Download: 

[http:// www. open‐itcockpit. com/ web/ 

guest/ it‐cockpit‐versions] 

Der Autor 

Bernhard Fahr ist technischer Leiter beim Informations 

Service Center, IKK:ISC. 

Sie haben Ihre 

IT im Griff. 

In Zukunft auch 

ohne Überstunden? 

NETHINKS unterstützt Sie 

als zertifizierter deutscher 

OpenNMS-Partner mit: 

a Support 

a Schulung 

a Neukonzeptionen 

a Systemoptimierungen 

Sprechen Sie uns an! 

www.NETHINKS.com 

OpenNMS User Conference: 

10.05. – 11.05.2012 


NETHINKS GmbH | Bahnhofstr. 16 | 36037 Fulda 

T +49 661 25000-0 Ausgabe | info@NETHINKS.com 

01-2012 

59


Zabbix 

Monitoring mit Zabbix 

Aus einem Guss 

© Paul Fleet, 123RF 

Nagios ist wohl die bekannteste freie Monitoring-Software. Über Jahre hat jedoch Zabbix stetig aufgeholt und 

setzt zum Angriff auf den Marktführer an. Der Beitrag stellt die grundlegenden Funktionen vor und gibt eine Einführung 

in Items, Trigger und Aktionen. Thomas Drilling 

Bereits im Jahr 2001 hat Alexei Vladishev 

angefangen, an seiner Monitoring- 

Software Zabbix zu arbeiten. Inzwischen 

ist er CEO der im lettischen Riga ansässigen 

Firma Zabbix SIA, und Zabbix 

hat sich zum umfangreichen Monitoring- 

Werkzeug entwickelt, das Netzwerke, 

Server und andere IT-Ressourcen überwacht 

und zahlreiche Visualisierungs- 

Optionen bietet. 

Zabbix zeigt im Gegensatz zum Haupt- 

Konkurrenten Nagios nicht nur sämtliche 

Informationen im Webinterface beziehungsweise 

in einem speziellen Browser- 

Plugin an, sondern ermöglicht darüber 

hinaus die komplette Konfiguration der 

zu überwachenden Hosts im Webbrowser. 

Zum Speichern der Daten verwendet 

es wahlweise MySQL, PostgreSQL, SQLite 

oder Oracle RDBMS. 

Die Weboberfläche ist vollständig in PHP 

realisiert und bietet neben einfachen 

„Simple checks“ zum Überwachen von 

Standarddiensten wie SMTP oder HTTP 

auch für eine Vielzahl von Betriebssystemen 

verfügbare Agenten, mit deren Hilfe 

sich die unterschiedlichsten Daten sammeln 

und in der Zabbix-Weboberfläche 

grafisch darstellen lassen. In Notfällen 

verschickt Zabbix E-Mails, SMS oder IM- 

Sofortnachrichten. 

Funktionsvielfalt 

Die Möglichkeit, den Verkehr nach außen 

gerichteter Dienste wie FTP, SSH oder 

HTTP mit Bordmitteln zu untersuchen, 

gehört indes nicht zu den Stärken von 

Zabbix. Für den professionellen Einsatz 

ist das Installieren der verfügbaren Agenten 

zwingend. Darüber hinaus unterstützt 

Zabbix zum Einsammeln von Informationen 

selbstverständlich auch SNMP. 

Einer der wichtigsten Vorteile gegenüber 

der Konkurrenz besteht neben der Möglichkeit, 

die Überwachung von Hosts direkt 

im Webinterface konfigurieren zu 

können, in der komfortablen Kombinierbarkeit 

von Actions, Items und Triggern. 

Eine weitere erwähnenswerte Eigenschaft 

von Zabbix ist die komfortable Verwaltung 

von Graphs, Screens und Maps. Dabei 

ist insbesondere die Darstellung der 

einzelnen Hosts auf verschiedenen Typen 

von Maps (Landkarten, Infrastrukturplänen 

und so weiter) sehr elegant umgesetzt 

und gehört außerdem per Default 

zum Installationsumfang. 

Zabbix steht komplett unter der GNU 

GPL und lässt sich in der aktuellen Version 

1.8.9. von der Projektseite [1] herunterladen. 

Zur Wahl stehen neben den 

Source-Paketen auch vorkonfigurierte Appliances 

als ISO, USB-Stick oder Live-CD 

sowie als Virtual Applicance im VMDKoder 

OVF-Format auf Basis von Open 

Suse. Neben den Server-Applicances gibt 

es vorkompilierte Agenten für Windows, 

verschiedene Unix-Derivate und alle relevanten 

Linux-Versionen. 

Aufgeschlossen 

Zusätzlich ist Zabbix in den Paketquellen 

vieler wichtiger Distributionen zu finden, 

bei Ubuntu 11.04 etwa in der Version 

1.8.5. Neben Linux unterstützt Zabbix 

auf Serverseite auch Solaris, AIX, HP-UX, 

FreeBSD und OpenBSD. Für Windows- 

Systeme steht nur der passende Agent zur 

Verfügung, sodass sich Windows-Hosts 

problemlos von Zabbix überwachen lassen. 

Der Agent unterstützt sowohl 32-Bitals 

auch 64-Bit-Systeme. 

Die Zabbix-Infrastruktur besteht stets aus 

den drei Komponenten Server, Front end 

und Agent. Die gesammelten Daten las 


Zabbix 


sen sich von jedem Zabbix-Nutzer mit 

entsprechenden Rechten über das Browser-Frontend 

abrufen. Server und Webfrontend 

müssen nicht notwendigerweise 

auf der gleichen Maschine laufen. Auch 

die Datenbank kann problemlos auf einem 

separaten Host installiert sein. 

Bei den von den Entwicklern angegebenen 

Installations-Voraussetzungen 

von 128 MByte freien physikalischen Arbeitsspeicher 

und 256 MByte freien Festplattenplatz 

handelt es sich wie üblich 

nur um eine Empfehlung für ein erstes 

Start-Setup. Faktisch hängt die Größe des 

erforderlichen Festplattenplatzes von der 

Anzahl der zu überwachenden Hosts und 

anderen Faktoren ab. Trotzdem sollte die 

Netzwerküberwachung mit Zabbix wohl 

in den seltensten Fällen an den Hardwareanforderungen 

scheitern. 

Die recht überschaubaren Mindestvoraussetzungen 

sollten den Admin aber 

auch nicht dazu verleiten, einem beliebigen 

File-, Database oder Mail-Server 

im Unternehmen zusätzlich die Überwachungsrolle 

aufzubürden, weil ein Monitoring-System 

möglichst autark und ausfallsicher 

betrieben werden sollte, damit 

es seinen Zweck erfüllt. 

SNMP optional 

Wer nicht die Applicance installiert, muss 

auf seinem Linux-Server außerdem dafür 

sorgen, dass Apache, PHP 5.0 und 

das PHP-Modul GD installiert sind sowie 

das gewünschte Datenbanksystem nebst 

zugehörigem PHP-Modul, dessen Admin- 

Account selbstverständlich ebenfalls 

bekannt sein muss. Wer die Netzwerküberwachung 

mit Zabbix auf Basis von 

SNMP realisieren möchte, muss etwa unter 

Ubuntu außerdem die Pakete »snmp«, 

»libsnmp« und »php5‐snmp« installieren. 

Das gilt auch für das zu überwachende 

System, wenn es sich um einen Linux- 

Host handelt. 

Wer die aktuellste Zabbix-Version aus 

den Sourcen kompilieren möchte, benötigt 

neben den obligatorischen Build- 

Essentials außerdem die Entwicklerpakete 

für MySQL und NET-SNMP. Für das 

Web-Frontend ist selbstverständlich ein 

laufender Apache-Webserver mit PHP- 

Unterstützung (»libapache2‐mod‐php5«) 

obligatorisch. Beim manuellen Installieren 

muss der Admin außerdem das Da 

Tabelle 1: Zugangsdaten Zabbix-Appliance 

Komponente Administrator-Account Benutzer-Account 

System root:zabbix zabbix:zabbix 

Database root:zabbix zabbix:zabbix 

Zabbix-Frontend 

admin:zabbix 

Bei den Appliances sowie den vorkompilierten 

Versionen entfallen die genannten 

Schritte, sodass der Admin die weitere 

Konfiguration direkt im Web-Frontend 

vornehmen kann, das nach erfolgreicher 

Installation unter »http://Zabbix‐Server/ 

zabbix« zur Verfügung steht. In der Default-Konfiguration 

kann sich der Admin 

mit dem Nutzernamen »admin« und dem 

Passwort »zabbix« anmelden. Die übrigen 

in der Appliance vorkonfigurierten 

Passwörter stehen in Tabelle 1 und funktenbanksystem 

starten und die Datenbank 

»Zabbix« und die erforderlichen Tabellen 

anlegen, wozu das Verzeichnis der entpackten 

Sourcen einen Ordner »create« 

mit passenden Schemata enthält. 

Die Konfiguration des Zabbix-Server- 

Daemons findet in der Konfigurationsdatei 

»/etc/zabbix_server.conf« statt, wobei 

die meisten der in der Dokumentation 

beschriebenen Parameter mit einem 

vernünftigen Standardwert belegt sind. 

Die wichtigsten sind der Name der Datenbank 

(»DBName=zabbix«), der Datenbank-Nutzer 

(»DBUser=root«), das 

Datenbank-Kennwort (»DBPassword=«) 

sowie der Standardport, auf dem der Zabbix-Daemon 

per Default lauscht (»Listen 

Port=10051«). 

Analog zur Zabbix-Server-Konfiguration 

funktioniert die Konfiguration der 

Agenten in der Konfigurationsdatei 

»zabbix_agent.conf« mit den wichtigsten 

Parametern »Server=127.0.0.1« für 

die IP-Adresse des Zabbix-Servers, per 

Default mit »localhost« besetzt, sofern 

Server und Agent auf der gleichen Maschine 

laufen (es schadet ja nicht, auch 

den Zabbix-Server zu überwachen), und 

»ListenPort=10050« für den Port, auf den 

der Agent nach den Anfragen des Servers 

horcht. Es ist übrigens nicht unbedingt 

erforderlich, auch den Agenten als 

Daemon zu starten, wozu gegebenenfalls 

die Datei »/etc/zabbix/zabbix_agentd. 

conf« zu bearbeiten ist. 

Appliance-Variante 

Abbildung 1: Grundlage der Überwachung eines Hosts oder einer Ressource in Zabbix ist deren Konfiguration 

im komfortablen Webinterface. 


Admin 


61


Zabbix 

tionieren in gleicher Weise auch bei den 

in den Paketquellen der Distributionen 

enthaltenen Versionen. 

Die Installation des Windows-Agents gestaltet 

sich recht einfach und erfordert 

ebenfalls eine Konfigurationsdatei »C:\ 

zabbix_agentd.conf«, deren Syntax identisch 

mit der unter Linux/Unix ist, sodass 

der Admin einfach die mitgelieferte 

Beispieldatei kopieren und konfigurieren 

kann. Dann muss der Admin lediglich 

den Zabbix-Agenten als Dienst installieren, 

wozu er im Windows-Eingabemodus 

(Eingabeaufforderung oder Powershell) 

»zabbix_agentd.exe ‐‐install« eingibt. Der 

Pfad zur Konfigurationsdatei lässt sich 

mit »‐‐config« spezifizieren. 

Die bei Zabbix mitgelieferte Konfigurationsdatei 

für Linux lässt sich zwar 

wie beschrieben auch unter Windows 

verwenden, enthält allerdings Unix-typische 

Pfadangaben wie »/etc/zabbix/ 

zabbix_agentd.conf«, die der Admin entsprechend 

ersetzen muss, zum Beispiel 

durch »C:\zabbix_agentd.conf«. Außerdem 

muss der Admin gegebenfalls die 

entsprechenden Ports (10050, 10051) in 

der Firewall freigeben, damit Server und 

Agenten kommunizieren können. 

Konfigurieren von Hosts 

Um einen Host in die Zabbix-Überwachung 

einzubeziehen, klickt der Administrator 

im Webinterface auf »Configuration 

| Hosts«. Der Zabbix-Server selbst 

ist in der Host-Liste bereits enthalten, 

wenn der Admin die Appliance als Testumgebung 

nutzt. Es spricht durchaus 

nichts dagegen, den Zabbix-Server zu 

überwachen. Zum Konfigurieren eines 

weiteren Hosts, wählt er zunächst rechts 

oben im Drop-down-Menü »Group« den 

Eintrag »all« und klickt anschließend auf 

die Schaltfläche »Create Host«. Zabbix 

präsentiert jetzt eine umfangreiche Dialogseite 

zum Konfigurieren eines Hosts, 

wobei „Host“ in der Zabbix-Philosophie 

jede Art von Netzwerk-Gerät sein kann, 

das über eine IP-Adresse oder einen DNS- 

Namen verfügt. 

Nicht notwendigerweise den Hostnamen, 

sondern einen frei wählbaren Namen für 

die Überwachung erwartet der Dialog 

»CONFIGURATION OF HOSTS« ganz oben 

bei »Name« (Abbildung 1). Es spricht allerdings 

auch nichts dagegen, dieses Feld 

Abbildung 2: Nach erfolgreicher Definition und Aktivierung eines Items erscheint es in der Item-Liste. 

und das Feld »DNS name« unten gleich 

auszufüllen, falls der Admin ohnehin 

ein aussagekräftiges Namensschema in 

seiner DNS benutzt. Darunter lässt sich 

eine passende Host-Gruppe auswählen 

oder bei »new host group« neu anlegen. 

Die mitgelieferten beziehungsweise vorkonfigurierten 

Gruppen sind lediglich 

Beispiele. Erst dann folgen technische 

Parameter wie der DNS-Name, die IP- 

Adresse oder die Agent-Portnummer. 

Für einen ersten Test ist es übrigens 

nicht zwingend, dass der Zabbix-Agent 

auf dem betreffenden Gerät installiert ist. 

Außerdem genügt es, eines der Felder 

»DNS name« und »IP adress« auszufüllen. 

Das Feld »Port« ist bereits mit der in 

der Standard-Konfiguration eingestellten 

Zabbix-Portnummer 10050 befüllt, muss 

also zunächst nicht geändert werden. Soll 

Zabbix mit anderen Ports arbeiten, muss 

der Admin die entsprechenden Werte 

in »/etc/zabbix/zabbix_server.conf« 

auf dem Server beziehungsweise /»etc/ 

zabbix/zabbix_agent.conf« auf dem zu 

überwachenden Host anpassen, bevor er 

dieses Feld ändert. Die übrigen Optionen 

kann der Admin zunächst ignorieren und 

den Host mit »Save« anlegen. 

Sammelwut 

Ist der erste Host angelegt, kann Zabbix 

dessen Daten einsammeln. Um die Überwachung 

zu starten, klickt der Admin 

erneut auf »Configuration | Hosts«, und 

dann in der Spalte »Items« der Host-Liste 

auf den betreffenden Link, der derzeit 

noch keinen Eintrag enthält, zu erkennen 

an der Null im Link »Items (0)«. Deshalb 

ist die Liste im sich öffnenden Dialog 

»ITEMS« noch leer. 

Abbildung 3: Das Anlegen von Triggern ist die Basis für das Einrichten der Alarmierungsfunktion. 


Zabbix 


Mit einem Klick rechts oben auf »Create 

Item« zeigt Zabbix den Dialog »Item Hostname«. 

Im Listenauswahlfeld »Type« stellt 

Zabbix zahlreiche Überwachungstypen 

zur Verfügung, neben dem Default-Eintrag 

»Zabbix Agent« stehen verschiedene 

SNMP-Agents, ein IPMI-Agent, ein SSH- 

Agent, ein Database-Monitor und auch 

External Checks zur Verfügung. 

Einfache Checks 

Für das Beispiel soll das Auswählen des 

Eintrages »Simple Checks« genügen, womit 

der Zabbix-Server selbstständig, also 

ohne eigens installierten Agent, überprüfen 

kann, ob der Host zum Beispiel 

auf ICPM-Pings antwortet. Im Feld »Key« 

ist der zum gewählten Szenario (ICMP- 

Requests) passende interne Zabbix- 

Schlüssel einzutragen. Allerdings steht 

mit einem Klick auf »Select« eine entsprechende 

Auswahlliste zur Verfügung, 

die alle Schlüssel für Simple Checks auf 

einen Blick zeigt, sodass der Admin etwa 

den Eintrag »icmpping« schnell findet, 

womit im Feld Key der Eintrag 

icmpping[,,,,U 

] 

erscheint. Wer die angebotenen Optionen 

für einen ersten Test nicht benötigt, 

entfernt die Optionsliste inklusive der 

eckigen Klammern. Abschließend wählt 

man im Drop-down-Menü bei »Status« 

den Eintrag »Active«. Erwähnenswert ist 

noch das Feld »New application«. Zabbix 

meint mit »application« stets eine Gruppe 

von Items, die es als Einheit betrachtet. 

Im Beispiel-Szenario bietet sich hier etwa 

die Bezeichnung »Verfügbarkeit« an. Bei 

den übrigen Feldern kann man getrost 

die Default-Werte übernehmen und die 

Item-Definition mit »Save« abschließen 


Ob Zabbix die in der Item-Definition in 

Auftrag gegebenen Messwerte tatsächlich 

einsammelt, kann der Administrator 

leicht prüfen, indem er ausgehend 

vom Hauptmenü auf »Monitoring | Latest 

Data« klickt und den Description- 

Tree bei »verfuegbarkeit (1 items)« mit 

einem Klick auf das Pluszeichen entfaltet. 

Je nach eingestelltem Intervall sollte 

ein Neuladen der Seite nach 30 oder 60 

Sekunden das erwartete Ergebnis liefern. 

Sammelt Zabbix die Werte des eben ein 

gerichteten Items korrekt ein, kann sich 

der Admin der Konfiguration von Triggern 

zuwenden, wozu erneut das Menü 

»Configuration | Hosts« als Ausgangsbasis 

dient. Hierzu klickt der Admin in der 

Hostliste in der Spalte »Triggers« auf den 

zugehörigen Link. Zu Beginn ist die Liste 

der Trigger erwartungsgemäß leer. 

Das Anlegen eines neuen Triggers erfolgt 

mit »Create Trigger«. Der Dialog »CONFI 

GURATION OF TRIGGERS« (Abbildung 3) 

erwartet ganz oben wieder einen aussagekräftigen 

Namen. Der Admin sollte bei 

dessen Wahl bedenken, dass der Name 

auch gleichzeitig die Betreffzeile für die 

beim Auslösen des Triggers versendete 

E-Mail ist, etwa „Ping gescheitert – Host 

nicht verfügbar“. Das Eintragen des 

betreffenden Host-Namens als Trigger- 

Name ist hier nicht nötig. 

Mit einem Klick auf »Add« legt er dann die 

zugehörige »Expression« an. Sie definiert, 

unter welchen Bedingung der Trigger den 

Status wahr oder falsch annimmt, und ist 

im Prinzip ein Vergleich des momentanen 

Wertes des Items mit einem vorgegebenen 

Schwellwert. Mit einem Klick auf 

»Select« wählt der Admin zunächst den 

Eintrag aus der Items-Liste im Popup- 

Fenster aus. Ist diese relativ lang, muss 

der Admin darauf achten, auch den richtigen 

Eintrag zu erwischen. 

Auswahlhilfe 

Wie gehabt, engt der Admin zuvor die 

Item-Liste auf dem betreffenden Host ein, 

indem er oben rechts zuerst die betreffenden 

Host-Gruppe beziehungsweise den 

betreffenden Host explizit auswählt. Das 

ist eigentlich zunächst verwirrend, weil 

ja die gerade vorzunehmende Trigger- 

Definition explizit für diesen Host erfolgt, 

was auch an der URL-Zeile des 

Expressions-Dialoges gut zu erkennen 

ist. Unter Zabbix ist es aber trotzdem 

möglich, Items anderer Hosts für den 

Trigger zu benutzen. In den meisten Fällen 

dürfte es sich aber um den gleichen 

Host handeln. 

Das Feld »Item« enthält im Beispiel den 

Eintrag »Einfacher Ping Test.« Der Eintrag 

bei »Function« steht per Default auf 

»Last value = N,« was der Admin im 

Beispiel unverändert übernehmen kann 

und bedeutet, dass der Trigger den Status 

„wahr“ annimmt, sobald der letzte 

ermittelte Wert des Items »Einfacher Ping 

Test« »N« (Null) war. Dass »N« dem Wert 

Null (0) entspricht, definiert der Admin 

ganz unten im Feld »N«. Mit einem Klick 

auf »Insert« ist die Expression definiert, 

und der Admin landet wieder im Trigger- 

Dialog. Hier muss er nur noch die Dringlichkeit 

des Triggers mithilfe des Listenauswahlfeldes 

»Severity« klassifizieren 

etwa »Information« oder »Warning«. 

Zum Fertigstellen des Triggers genügt ein 

Klick auf »Save«. Die Trigger-Liste enthält 

anschließend den eben definierten 

Trigger. In der Spalte »Error« sollte ein 

grünes Häckchen signalisieren, dass die 

Definition erfolgreich war. Der Status des 

Triggers lässt sich anschließend jederzeit 

ausgehend vom Hauptmenü unter 

» Monitoring | Triggers« einsehen. Dabei 

ist darauf zu achten, mithilfe der Listenauswahlfelder 

»Host« oder »Group« die 

richtigen Filter zu setzen, damit Zabbix 

die eben definierten Filter auch anzeigt. 

Wenn der zu überwachende Host online 

ist, sollte der Status des eben angelegten 

Triggers auf »OK« stehen. Trennt der 

Admin den Testhost vom Netz, wechselt 

dessen Status auf »Problem«. 

Die Abbildung zeigt außerdem zwei Trigger 

mit Problem-Status für den Zabbix- 

Server, die daraus resultieren, dass in 

der getesteten Appliance noch nicht alle 

überwachten Dienste konfiguriert sind. 

Um beim Eintreten eines Triggers eine 

E-Mail versenden zu können, muss 

der Admin einen Mail-Server und eine 

C13 


Admin 


63


Zabbix 

Abbildung 4: Zabbix verfügt über eine komfortable Benutzerverwaltung. 

Aktion definieren. Zum Einrichten des 

Mail-Servers dient das Menü »Administration 

| Mediatypes«. In der Spalte 

»Description« stehen bereits Email, Jabber 

und SMS zur Verfügung. 

Um das Versenden einer E-Mail im Trigger-Fall 

einzurichten, klickt der Admin 

auf den Link »Email« und überschreibt 

dann die Default-Werte für SMTP-Server, 

Helo-String und »SMTP email« mit den 

gewünschten Werten. 

Mail-Einstellungen 

Abbildung 5: Sogenannten Actions komplettieren das Zusammenspiel zwischen Items, Triggern und Alarmen 

und definieren die im Trigger-Fall auszulösende Aktion. 

Abbildung 6: Die Installation von Zabbix-Agenten auf dem zu überwachenden Host ist die Voraussetzung für 

eine detaillierte und professionelle Netzwerküberwachung. 

Achtung: »SMTP email« ist die Absender-Adresse, 

unter der Zabbix die E-Mail 

verschickt. Die E-Mail-Adresse, an die 

Zabbix die Mails versendet, setzt der Admin 

dagegen im Menü »Administration | 

Users«. Hier muss er zunächst im Auswahlfeld 

rechts den Default-Eintrag »User 

Groups« auf »User« umstellen. Die Appliance 

enthält bereits zwei Default-User 

»Admin« und »guest« (Abbildung 4). 

Jetzt kann der Admin in der Spalte »Alias« 

auf den Link »Admin« klicken, um die 

Benutzerdaten des Administrators zu bearbeiten. 

Hier klickt er am unteren Ende 

des Dialoges beim Eintrag »Media« auf 

»Add« und trägt dann im Feld »Send to« 

die gewünschte E-Mail-Adresse ein. Mit 

den Checkboxen darunter kann der Admin 

einstellen, mit welchem Dringlichkeitsstatus 

Zabbix eine E-Mail verschickt. 

Ein Klick auf »Add« übernimmt die Konfiguration 

in den Dialog der Benutzer- 

Konfiguration, den der Admin dann mit 

»Save« beenden kann. 

Zum Einrichten einer Aktion klickt der 

Admin ausgehend vom Hauptmenü auf 

»Configuration | Actions« und wählt wieder 

rechts oben aus dem Auswahlfeld bei 

»Event Source« den Eintrag »Triggers«, gefolgt 

von einem Klick auf »Create Action«. 

Der Dialog in Abbildung 5 erwartet zuoberst 

einen frei wählbaren Namen für 

die zu definierende Aktion, etwa »Nachricht 

senden«. Das Feld »Event Source« 

sollte aufgrund der vorherigen Wahl den 

Eintrag »Triggers« enthalten. 

Im Feld darunter lässt sich der Standard- 

Betreff der zu versendenden Nachricht 

angeben. Per Default enthält das Feld 

bereits den Eintrag »{TRIGGER.NAME}: 

{TRIGGER.STATUS}«, den man beispielsweise 

noch um den Eintrag »{HOST 

NAME}: {TRIGGER.STATUS}« erweitern 


Zabbix 


Das illustrierte Minimal-Beispiel verwendete 

lediglich Simple Checks, die der 

Zabbix-Server ohne Mithilfe von Agenten 

durchführen kann, sollte aber das intuitiv 

und komfortabel konfigurierbare Zusammenspiel 

von Items, Triggern und Actions 

veranschaulicht haben, ebenso wie die 

erforderlichen Schritte zum Einrichten 

der Alarmierungsfunktion. Abbildung 6 

zeigt, dass der Item-Typ Zabbix-Agent 

eine wesentlich größere Menge an Keys 

bietet, die sich weit besser für den praktischen 

Einsatz eignet. 

Letztere stellt die komfortabelste Art 

der Netzwerküberwachung dar, weil die 

Unterstützung für das Netzwerküberwachungs-Protokoll 

SNMP in nahezu alle 

modernen Betriebssysteme oder die Firmware 

von Routern, Switches und so weiter 

eingebaut ist. Das Protokoll regelt in 

diesem Zusammenhang die Kommunikation 

zwischen den überwachten Geräten 

und der Überwachungsstation. 

Die bisherigen Ausführungen konnten 

den Funktionsumfang von Zabbix nur 

streifen. Ein direkter Vergleich mit Nakann, 

damit beim Eintreffen der E-Mail 

sofort ersichtlich ist, auf welchen Host 

sich das Problem bezieht. Den Default- 

Inhalt der zu sendenden Nachricht kann 

der Admin in gleicher Weise mit den verfügbaren 

Platzhaltern anpassen. Darunter 

im Bereich »Action conditions« des 

Dialogs muss der Admin bei »Conditions« 

das Häkchen für »(A) Trigger value = 

Problem« setzen. 

Danach klickt der Administrator rechts 

oben bei »Action operations« auf »New« 

zum Einfügen einer neuen Aktion, womit 

sich der Teilbereich des Dialogs in 

»Edit Operations« auffaltet. Hier kann der 

Admin dann endlich den Opera tionstyp 

»Send message« auswählen, bei »Send 

message to« den Eintrag »User group« 

einstellen und im Feld rechts davon den 

Eintrag »Zabbix Administrators« wählen, 

wozu er die Select-Schaltfläche benutzt, 

die ein Popup mit der Groups-Liste öffnet. 

Wahlweise könnte er auch im Feld 

darüber »Single User« und dann mit der 

Select-Schaltfläche explizit den Nutzer 

»Admin« als Mail-Empfänger auswählen. 

Jetzt kann der Administrator den Teil- 

Dialog »Edit operations« mit einem Klick 

auf »Add« beenden und anschließend 

den gesamten Action-Dialog mit »Save« 

schließen. Zum Testen kann er erneut 

den überwachten Testhost vom Netz 

trennen, woraufhin kurze Zeit später die 

konfigurierte E-Mail eintreffen sollte. 

Nur gestreift 

gios, Icinga und Shinken ist in einem 

anderen Artikel dieses Heft-Schwerpunktes 

zu finden. Das Konzept und die Architektur 

von Zabbix wirken allgemein 

wesentlich stimmiger als bei Nagios, das 

nur dank der zahllosen verfügbaren Erweiterungen 

funktional auf Augenhöhe 

mit Zabbix agiert. Dabei sind wir auf die 

eigentlichen Monitoring- und Visualisierungsfunktionen 

von Zabbix noch gar 

nicht eingegangen, ebenso wenig wie auf 

die Verwendbarkeit von Templates. 

Allerdings kann sich der Admin beim Verwenden 

der Appliance anhand der mitgelieferten 

und vorkonfigurierten Überwachungsfunktionen 

des Zabbix-Servers 

unter anderem mit Vorlagen vertraut machen. 

Die PHP-Software ist insgesamt so 

intuitiv aufgebaut und bedienbar, dass 

sich der Admin schnell zurechtfindet. So 

findet er im Hauptmenü »Monitoring« mit 

dem Dashboard ein komfortables Werkzeug, 

um sämtliche überwachten Geräte 

im Blick zu behalten. 

Was die ebenfalls vorzüglich umgesetzten 

Visualisierungsfunktionen angeht, 

sollte sich der Admin in jedem Fall auch 

die Menüs Graphs, Screens und Maps näher 

ansehen (Abbildung 7). Wer Nagios 

kennt, wird auch in diesem Punkt von 

Zabbix begeistert sein. Den vielen Möglichkeiten 

der Visualisierung mit Zabbix 

wird sich ein Beitrag in der nächsten 

ADMIN-Ausgabe widmen. 

Fazit 

Zweifelsohne demonstriert Nagios schon 

seit vielen Jahren, was Netzwerküberwachung 

mit Open-Source-Werkzeugen 

leisten kann und hat es auch zu entsprechend 

großer Bekanntheit gebracht. Zabbix 

macht es aber in fast allen Punkten 

besser und überzeugt mit einem in sich 

stimmigen Konzept. 

Wer erst in die Netzwerküberwachung 

einsteigt, kommt mit Zabbix schneller 

ans Ziel, wobei das hervorragende Web- 

Interface nicht nur als Überwachungszentrale 

im Mittelpunkt steht, sondern 

vor allem auch bei der Konfiguration von 

Hosts, Items, Trigger und Alarmen hilft. 

(ofr) 

n 

Abbildung 7: Zabbix bietet übersichtliche Visualisierungsfunktionen. 

Infos 

[1] Zabbix Download: 

[http:// www. zabbix. com/ download. php] 


Admin 


65


Nagios-Benchmarks 

© Dmitriy Shironosov, 123RF 

Monitoringlösungen auf Nagios-Basis im Benchmark-Vergleich 

Zieleinlauf der 

Kontrolleure 

In dem Maß, wie die Zahl der zu überwachenden Geräte wächst, wird Performance in Nagios-basierten Umgebungen 

zum Thema. Dieser Beitrag diskutiert einige grundlegende Eckdaten. Christoph Siess 

Eine Nagios-Umgebung beinhaltet viele 

unterschiedliche Komponenten, deren 

Zusammenspiel das Werkzeug zur Überwachung 

von IT-Systemen ausmacht. Angefangen 

beim Nagios-Kern, der für das 

rechtzeitige Ausführen von Checks und 

die daraus abgeleiteten Benachrichtigungen 

zuständig ist, über Visualisierungslösungen 

wie Nagvis oder Werkzeuge 

zur Trendermittlung greifen viele Räder 

ineinander. Jedes dieser Werkzeuge generiert 

eine unterschiedliche Last, für 

jedes Werkzeug gibt es unterschiedliche 

Ansätze, um den einen oder anderen Flaschenhals 

zu beseitigen. 

Eine vollständige Analyse dieser Komponenten 

und ihres Zusammenwirkens 

wäre extrem aufwändig. Deshalb konzentriert 

sich diese Betrachtung auf das 

Herzstück der Überwachungslösung, den 

Nagios-Kern. 

Nagios, die Greybox 

Der Kern soll unter einer vereinfachten 

Systemsicht betrachtet werden, denn es 

geht hier nicht darum zu begründen, welche 

Funktionsaufrufe Auswirkungen auf 

die Systemperformance haben. Vielmehr 

geht es um einen praxisbezogenen Test, 

einen Greybox-Test genau genommen, 

der die Interna des Kerns ignoriert. 

Abbildung 1 zeigt das System so, wie es 

im Folgenden analysiert werden soll. Der 

Nagios-Kern in der Mitte ist die zentrale 

Komponente. Ziel der folgenden Testreihen 

ist es, genauere Aussagen über das 

Verhalten dieses Kerns in unterschiedlichen 

Szenarien zu erhalten. Dafür ist zu 

definieren, welcher Output die Leistungsfähigkeit 

des Systems beschreiben soll. 

Auf der Input-Seite beschreiben andere 

Variablen verschiedene Szenarien. 

Eingangsparameter 

Das hier vorgestellte Vorgehen stellt 

einen pragmatischen Kompromiss hinsichtlich 

der Komplexität der Parameter 

dar. Natürlich gibt es noch viele weitere 

Einflussgrößen. Der Autor ist allerdings 




Abbildung 1: Stark vereinfachte Darstellung des Nagios-Systems. 

der Meinung, dass er mit seiner Auswahl 

eine gute Aussage über das System Nagios 

treffen kann. 

Anzahl Checks: Sinn und Zweck dieses 

Parameters ist es nachzustellen, ob die 

tatsächlich durch das System zu bearbeitende 

Anzahl an Servicechecks eine 

Auswirkung auf die Leistung hat. 

Return Codes: Ein Plugin, das ein Problem 

erkennt, meldet das über den Return 

Code an den Nagios-Kern. Der ergreift 

– abhängig von der Anzahl der Schlechtmeldungen 

für den Servicecheck – weitere 

Maßnahmen, wie das Berechnen eines 

Status. Am Ende dieser Logik stehen 

gegebenenfalls Benachrichtigungen. Dieser 

Parameter soll die Frage beantworten 

helfen, ob die Bewertungslogik Auswirkungen 

auf die Performance hat. 

Laufzeit: Die Laufzeit eines Plugins 

wird vom Aufruf über den Kern bis zur 

Rückgabe des Returncode gemessen. Im 

Configfile 

vorhanden 

Ja 

Statefile 

vorhanden 

Durchlauf, 

Rückgabewert 

einlesen 

Durchlauf 

inkrementieren 

Statuswechsel 

notwendig 

Nein 

Statefile 

schreiben 

Nein 

Nein 

Ja 

X-Verschiebung 

initialisieren 

Statefile anlegen 

Rückgabewert 

ändern 

Verzögerung 

Rückgabe 

Logfile 

schreiben 

Abbildung 2: Der für die Messungen verwendete 

Simulator als Flussdiagramm. 

schlimmsten Fall 

führt der Aufruf 

eines Plugins zu 

einem Timeout, 

weil die zu überwachende 

Komponente 

nicht 

erreichbar ist. Inwieweit 

diese Ausführzeit 

Einfluss 

auf das System hat, soll dieser Parameter 

klären. 

Ausgangsparameter 

Um die Systemperformance messen zu 

können, wurden im Test drei Messgrößen 

bestimmt: 

Nagios Latency: Das Planen der Ausführzeitpunkte 

der einzelnen Checks ist 

eine komplexe Angelegenheit, weil nicht 

sämtliche Überprüfungen gleichzeitig 

auszuführen sind. Dies hätte eine sehr 

ungleichmäßige Auslastung des Systems 

zur Folge. Aus diesem Grund verfügt der 

Nagios Core über einige Intelligenz, die 

dieses Verhalten steuert. Wie gut der Core 

diese Ausführzeitpunkte anpassen kann, 

wird durch die Nagios Latency gemessen. 

Sie bezeichnet die Differenz zwischen 

einem geplantem Ausführzeitpunkt eines 

Checks und dem tatsächlichen. Ist dieser 

Wert zu hoch, kommt das System bei 

steigender Menge an Checks nicht mehr 

nach. Die Liste der noch abzuarbeitenden 

Checks wird zu hoch, es können nicht 

mehr alle konfigurierten 

Überprüfungen 

auch wirklich 

durchgeführt 

werden. 

CPU-Load: Als 

klassisches Mittel 

zur Bestimmung 

der CPU-Auslastung 

hat sich die 

Anzahl der auf 

CPU-Zeit wartenden 

Prozesse etabliert. 

Gemeinsam 

mit der Anzahl 

der Prozesse, die 

gerade laufen, und 

jener, die auf I/O 

Zeit warten, bildet 

sie den sogenannten 

Load Average 

des Linux-Systems. Als grober Richtwert 

gilt: Liegt diese Zahl unter der Anzahl der 

im System verbauten CPU-Cores, ist alles 

im grünen Bereich. 

Da bei einigen Technologievergleichen 

auch die Verteilung der CPU-Zeit auf 

Prozesse im Kern beziehungsweise User 

Space interessant ist, wird an manchen 

Stellen diese Metrik verwendet. 

Memory: Neben der CPU-Belastung ist 

natürlich auch die Auslastung des Arbeitsspeichers 

ein interessanter Messwert 

in Linux-Systemen. Das Augenmerk gilt 

hier der Menge des durch eine Applikation 

maximal belegbaren Speichers, den 

man näherungsweise ermitteln kann, indem 

man vom »Used«-Wert die Werte für 

»Buffer« und »Cached« abzieht. 

Die Simulation 

Die Simulation soll das zu messende System 

selbst möglichst wenig beeinträchtigen. 

Im vorliegenden Fall sollen sich alle 

Input-Parameter verändern lassen und 

der CPU- und Speicherverbrauch dennoch 

möglichst gering sein. Gefragt ist 

also ein Plugin, das flexibel und CPUgünstig 

zugleich arbeitet. Der Autor hat 

sich für eine Eigenentwicklung in Perl 

entschieden. Dieses Plugin wird in der 

Nagioskonfiguration an virtuelle Servicechecks 

gebunden, die Servicechecks wiederum 

laufen auf virtuellen Hosts. 

define command{ 

command_name check_ok 

Abbildung 3: Die Nagios Latency steigt ab einer bestimmten CPU-Auslastung 

sprunghaft an. Abbildung 3 zeigt, wie sich die Nagios Latency über die Zeit verändert, 

auf der X-Achse ist der Zeitverlauf ersichtlich, die einzelnen Phasen mit der 

jeweils verschiedenen Anzahl von Checks wurden über der Achsenbeschriftung 

markiert. Auf der Y-Achse ist die Nagios Latency in Sekunden aufgetragen. Was sofort 

auffällt, ist, dass es keinen direkten Zusammenhang zwischen Latency und der 

Anzahl der Checks gibt. Die Erhöhung von 1000 auf 1400 Checks brachte nahezu 

keine Änderung bei der Latency. Erst bei 2200 Checks stieg diese sprunghaft an. 

E 


Admin 


67



Abbildung 4: Die CPU-Auslastung steigt in Stufen mit der Anzahl an Checks 

immer weiter an. 

Abbildung 5: Die Nagios-Latency sinkt schnell und deutlich ab, sobald zwei CPUs 

verfügbar sind. 

command_line /usr/lib/nagios/pluginsU 

/sampler_do_nothing.pl $HOSTNAME$ U 

$SERVICEDESC$ 

} 

So wird das Perlskript im System eingebunden. 

Wichtig sind die Parameter 

»$HOSTNAME$« und »$SERVICEDESC$«, 

die dem Plugin mitteilen, für welchen 

Host/Service es gerade die Simulation 

übernehmen soll. Dies ist insofern relevant, 

als eine gewisse Streuung der Ereignisse 

in der Simulation erwünscht ist. 

Es wäre realitätsfern, wenn alle Checks 

zur exakt selben Zeit von »OK« auf »Warning« 

beziehungsweise »Critical« wechseln 

würden oder wenn die Durchlaufzeit 

eines Checks immer gleich wäre. 

Abbildung 2 erläutert den Ablauf im Detail. 

Wird das Plugin das erste Mal in 

der entsprechenden Host/Service-Kombination 

aufgerufen, berechnet es eine 

Verschiebung des Zeitpunktes des Statuswechsels. 

Dadurch wird, in bestimmten 

Grenzen, festgelegt, in welchem Rhythmus 

die einzelnen Statuscodes zu durchlaufen 

sind. 

Für die Messung systemnaher Werte wie 

der CPU-Load wurde das Tool Sar aus 

dem Sysstat-Paket verwendet. Es speichert 

im Abstand von fünf Sekunden 

kontinuierlich Messwerte, die dann später 

mit »sadf« in ein CSV-Format umgewandelt 

und an Gnuplot zur grafischen 

Darstellung weitergegeben wurden. 

Nagios Core testen 

Die ersten drei Tests beschäftigen sich 

mit dem Standard Nagios Core ohne Patches 

oder sonstige Maßnahmen zur Performanceverbesserung. 

Ziel war es, ein 

besseres Verständniss dafür zu erhalten, 

welchen Einfluss die oben genannten Parameter 

auf die Systemleistung haben: 

Wie wirkt sich die Anzahl der Checks auf 

die Leistung aus? Gibt es einen direkten 

Zusammenhang zwischen der Anzahl der 

Checks und der CPU-Auslastung oder der 

Nagios Latency? 

Getestet wurde auf einem virtuellen System 

(ESX als Hypervisor) mit fixen Reservations 

für CPU und Memory. Konkret 

stand eine virtuelle CPU mit 1.5 GHz und 

512 MB RAM in der VM zur Verfügung. 

Ausgehend von diesen Hardware-Voraussetzungen 

wurde die Anzahl der Checks 

schrittweise erhöht. Auf anfänglich 1000 

Checks folgte eine Steigerung auf 1400 

und schlussendlich auf 2200 Checks. 

Ein Blick auf die CPU-Auslastung (Abbildung 

4) erklärt dieses Verhalten. Solange 

noch genug CPU-Zeit zur Verfügung steht 

(gelbe Linie), bleibt die Nagios Latency 

niedrig. Bei 2200 Checks steigt die CPU 

Belastung so weit an, dass fast keine Ressourcen 

verfügbar sind – das Resultat ist 

der sprunghafte Anstieg der Latency. 

Im Umkehrschluss würde das bedeuten, 

dass zwei virtuelle CPUs die Latency bei 

2200 Checks sofort wieder sinken lassen 

müssten. Abbildung 5 bestätigt dies. 

Auswirkungen von Laufzeit 

und Return Codes 

Ein weiterer Faktor, der in der Praxis relevant 

ist, ist die Ausführzeit für einzelne 

Checks. Viele Checks werden remote, 

etwa über SSH oder NRPE (Nagios Remote 

Plugin Executor) auf anderen Hosts 

ausgeführt. Dabei ist die CPU-Belastung 

am Nagios-System meist gering. Die 

Frage, die beantwortet werden soll, ist, ob 

die Nagios Latency von der Durchlaufzeit 

Abbildung 6: Der Verlauf der Nagios Latency mit einer künstlichen Verzögerung 

innerhalb der Checks. 

Abbildung 7: Nagios Latency mit einem Anteil von zehn Prozent Checks, die nicht 

»OK« zurückliefern. 




Abbildung 8: CPU-Auslastung mit zehn Prozent Checks, die nicht »OK« 

zurückliefern. 

Abbildung 9: Vergleichstest mit Mod_gearman. Das Modul sorgt für einen 

extremen Abfall der Latency im Test. 

dieser Checks beeinflusst wird. Getestet 

wurde wieder in derselben Konfiguration 

wie in den ersten Tests. Neu hinzukam, 

dass die Skripte nun zwischen 0 und 

10 Sekunden wegen eines »sleep()«-Calls 

warten mussten, bevor sie sich beenden 

konnten. 

Im Vergleich wird aus Abbildung 6 

ersichtlich, dass die Ausführzeit einen 

deutlichen Einfluss auf die Latency 

hat. CPU-seitig war keine Veränderung 

messbar. 

Im vorherigen Test gaben alle konfigurierten 

Checks immer den Status OK zurück, 

was nicht der Rea lität entspricht. 

Daher galt es herauszufinden, welche 

Auswirkungen Checks auf die Performance 

des Systems haben, die nicht OK 

zurückliefern. Weil der Nagios Core in 

diesem Szenario einige Berechnungen 

mehr durchzuführen hat, sollte die Performance 

schlechter sein. Die vorherige 

Konfiguration wurde übernommen: 2 

CPUs, 2200 Checks, alle 60 Sekunden 

ausgeführt, Verzögerung zwischen 0 und 

10 Sekunden. Nun wechselten allerdings 

zehn Prozent der Checks zwischen »OK«, 

»Warning« und »Critical«. 

Abbildung 7 zeigt eine klare Veränderung 

gegenüber Abbildung 6. Die 

Latency steigt von etwa fünf Sekunden 

auf einen Wert von durchschnittlich sieben 

Sekunden. 

Sehr interessant ist, dass das Schwingverhalten, 

das bei der Latency in Abbildung 

7 zu sehen ist, nicht direkt mit der CPU 

zusammenhängt. Die CPU-Auslastung 

liegt zwar fast bei 80 Prozent, aber offensichtlich 

noch knapp unter der Grenze, 

die im ersten Test gemessen wurde, sodass 

die Latency nicht sprunghaft ansteigt. 

Was lässt sich aus diesen Tests 

ableiten? Überraschend ist der fehlende 

direkte Zusammenhang zwischen Nagios-Latency 

und CPU-Auslastung. Eine 

voll ausgelastete CPU bewirkt zwar einen 

sprunghaften Anstieg der Latency, eine 

hohe Latency muss aber nicht unbedingt 

mit hoher CPU-Auslastung einhergehen. 

Alternative Technologien 

Im Laufe der letzten Jahre hat sich einiges 

im Nagios-Umfeld verändert. Lange Zeit 

führte am Nagios Core von Ethan Galstad 

kein Weg vorbei. Die oft kritisierte eher 

konservative Entwicklungspolitik rund 

um das klassische Nagios hat dazu geführt, 

dass inzwischen einige spannende 

Alternativen und Erweiterungen verfügbar 

sind (vergleichen Sie auch einen weiteren 

Beitrag in dieser Ausgabe). 

Icinga: Icinga konzentriert sich seit 2009 

hauptsächlich auf Frontend-Funktionalitäten. 

So verfügt es über ein sehr flexibles 

GUI und greift auf ein eigenes Datenbank-Backend 

zurück, das das vielfach 

kritisierte NDO-Datenbankschema von 

Nagios vermeidet. 

Mod_gearman: Sven Nierlein von der 

Münchner Firma Consol hat sich zum 

Ziel gesetzt, mit Mod_gearman einen Mechanismus 

zum verteilten Ausführen von 

Checks zu kreieren. Die Kommunikation 

zwischen den einzelnen Rechenknoten 

erfolgt über ein Framework, das speziell 

zur Lastverteilung entwickelt wurde. 

Das löst im Vorbeigehen viele Probleme 

der bestehenden Nagios-Architektur. Die 

zentral vom Gearman-Server verwalteten 

Queues bewerkstelligen eine Lastverteilung 

kombiniert mit der Möglichkeit, die 

Ausführung der Checks redundant zu gestalten. 

E 

Abbildung 10: Vergleichstest mit Mod_gearman (Ausschnittsvergrößerung). Die 

Latency ist auf unter eine halbe Sekunde gefallen. 

Abbildung 11: Die CPU-Auslastung im Vergleichstest mit Mod_gearman. Das Modul 

macht sich auch bei der Prozessorauslastung bemerkbar. 


Admin 


69



Abbildung 12: Die Latenz von Shinken im Vergleich. 

Abbildung 13: Die CPU-Auslastung von Shinken im Vergleichstest. 

Shinken: Jean Gabes, der Hauptentwickler 

von Shinken, hat Nagios im Hinblick 

auf verteiltes Monitoring analysiert. Er 

war mit den bestehenden Ansätzen unzufrieden 

und begann deshalb mit der 

Entwicklung eines neuartigen Konzeptes 

in Python. Nachdem es sich als unmöglich 

erwies, seinen Vorschlag für eine 

Neuimplementierung unter dem Dach 

des klassischen Nagios zu verwirklichen, 

entschloss er sich zu einem eigenständigen 

Projekt. 

Merlin: Merlin ist ein unter der GPL verfügbarer 

Teil der Monitoringlösung der 

schwedischen Firma op5 AB. Ähnlich 

wie bei Mod_gearman geht es um Lastverteilung 

über mehrere Rechenknoten. 

Merlin bedient sich dabei einer eigenen 

Kommunikationsarchitektur. Ein weiterer 

Untersschied zu Mod_gearman besteht 

darin, dass auf jedem der von Merlin 

bedienten Rechenknoten eine autarke 

Nagios-Installation notwendig ist. Diese 

Anforderung bewirkt allerdings auch, 

dass sich mit Merlin vollständig redundante 

Nagios-Implementierungen realisieren 

lassen. 

Die erwähnten Technologien wurden 

ebenfalls unter Laborbedingungen getestet. 

Alternativen im Test 

Der erste Vergleichstest übernimmt das 

Setup vom letzten Test am Nagios Core 

und schaltet zusätzlich das Mod_gearman-Broker-Module 

dazwischen. 

Das Ergebnis fällt noch deutlicher aus 

als erwartet. War die Nagios Latency im 

vorherigen Test (Abbildung 7) im Bereich 

von 7 Sekunden, so fällt sie nun extrem 

ab. Abbildung 10 verdeutlicht dieses Bild 

– die Latency sinkt auf unter 0,5 Sekunden. 

Abbildung 11 zeigt, dass nicht nur 

die Latency, sondern auch die CPU-Belastung 

deutlich sinkt. Ohne Übertreibung 

kann man also sagen, dass Mod_gearman 

einen Performanceschub verursacht und 

dabei zusätzlich noch deutlich sparsamer 

mit den Ressourcen umgeht. 

Dasselbe Setup wurde auch für eine 

Messung mit Shinken anstelle der Kombination 

Nagios mit Mod_gearman verwendet. 

Hier zeigt sich ein ähnliches Bild wie mit 

Mod_gearman: Die Latency sinkt deutlich, 

auch wenn der Wert etwas über 

dem von Mod_gearman liegt. Aus Sicht 

der CPU zeigt sich, dass Shinken zwar 

etwas mehr Ressourcen benötigt (Abbildung 

13), die Werte liegen aber auch hier 

deutlich unter denen eines klassischen 

Nagios-Kerns. 

Auch Icinga und das Merlin Broker-Modul 

wurden auf diese Weise vermessen. 

Das Ergebnis war eindeutig: Ein großer 

Unterschied zum Nagios Core war hier 

nicht feststellbar. Dies ist insofern auch 

nicht sonderlich verwunderlich, als alle 

auf einer sehr ähnlichen Codebase aufbauen. 

Die Verbesserungen, die in Icinga 

eingeflossen sind, haben jedenfalls bislang 

keine entscheidenden Performanceverbesserungen 

gebracht. Merlin per se 

bietet auch keinen Performancevorteil, 

interessant ist hier aber die Tatsache, dass 

dieses System durch zusätzliche Überwachungsknoten 

horizontal skalieren kann. 

Deshalb fällt auch die Steigung der Lastkurve 

bei einem Merlin-System mit zwei 

Knoten deutlich schwächer aus, weil die 

Last sich zwischen den beiden Knoten 

automatisch verteilen kann. 

Ausblick 

Die Erkenntnisse aus den Tests hat der 

Autor zum Anlass genommen, um mit 

Andreas Ericsson – einem der Core Developer 

im Nagios Projekt – auf Ursachenforschung 

zu gehen. Dabei stellte sich 

heraus, dass der Grund für die auffällig 

bessere Performance von Shinken und 

Mod_gearman in der Art und Weise liegt, 

wie die Checkresultate an den Nagios 

Core übergegeben werden. 

In einer klassischen Nagios-Umgebung 

passiert diese Übergabe über das Dateisystem: 

Die Resultate werden zuerst in 

einem temporären Verzeichnis zwischengespeichert, 

der Core überprüft anschließend 

dieses Verzeichnis in regelmäßigen 

Abständen und liest dabei diese Nachrichten 

in das System ein. Im Gegensatz 

dazu verläuft die Kommunikation im 

Falle von Mod_gearman oder auch bei 

Shinken direkt ab. 

Zwar hat Nagios im klassischen Fall eine 

geringere Komplexität – die Übergabe der 

Checkresultate über das Dateisystem ist 

aber merklich aufwändiger als die direkte 

Kommunikation mit dem Kern. Deshalb 

sind Mod_gearman und Shinken bei größeren 

Umgebungen stets deutlich im Vorteil, 

wenn es um die Systemperformance 

geht. Nagios verspricht allerdings in absehbarer 

Zeit Veränderungen im Nagios- 

Kern, die ihn so schnell wie Mod_gearman 

oder Shinken machen sollen. Man 

darf gespannt darauf sein. (jcb) n 

Der Autor 

Christoph Siess beschäftigt sich seit über zehn 

Jahren mit dem Einsatz von Open-Source-Software 

in Enterprise-Umgebungen. Er ist bei der 

Firma Bacher Systems EDV GmbH in Wien als 

IT-Consultant im Monitoring Competence Center 

für die Konzeption und Realisierung Nagiosbasierender 

Monitoringlösungen verantwortlich. 

In seiner Freizeit erkundet er gerne mit seinem 

Mountain Bike die Hügel rund um Wien. 


Admin-mAGAZin 

im JAhres-Abo 

Jede Ausgabe des Admin-Magazins bietet praktisch anwendbares Wissen 

von ausgewiesenen Experten und ausführliche Hintergrundberichte für alle 

Systemverwalter von Linux, Unix und Windows. Die Schwerpunkte reichen von 

Storage und Backup bis hin zu Netzwerk-Themen und Security. 

Ein Sonderteil hilft Admins heterogener Welten. 

15 % sparen 

Jetzt bestellen unter: 

www.admin-magazin.de/abo 

sichern sie sich ihr 

GrAtis Admin t-shirt! 

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

Mit dem Jahres-Abo erhalten Sie 6 Ausgaben des Admin-Magazins zum Vorzugspreis von E 49,90 * statt E 58,80 * 

(Lieferung frei Haus). 

* Preise gelten für Deutschland. Schweiz: SFr 82,32; Österreich: E 54,90; anderes Europa: E 59,90

Test 

Virtual Core 

© Mazuryk Mykola, 123rf.com 

Einfach administrierbare Private Cloud 

Heiter bis wolkig 

Mit einem originellen Ansatz versucht die KAMP Netzwerkdienste GmbH Mittelständler für Private Clouds zu 

begeistern. Jens-Christoph Brendel 

Wer seine Daten etwa wegen Sicherheits- 

oder Datenschutzbedenken nicht 

außer Haus geben mag, bereits über 

Server-Hardware und Storage verfügt, 

aber gleichzeitig keine Admins mit 

Cloud-Ambitionen im Haus hat, dem 

soll die „Customer Cloud“ der KAMP 

Netzwerkdienste GmbH aus Oberhausen 

auf den Leib geschrieben sein. Der Anwender 

nutzt die vorhandenen eigenen 

Rechen- und Speicherressourcen, verwaltet 

sie aber mit einer leicht bedienbaren 

Browserapplikation, die KAMP für ihn 

hostet. 

Damit die entfernt laufende Verwaltungssoftware 

und die Hardware vor Ort Hand 

in Hand arbeiten können, muss der lokale 

Server mit einem eigens erzeugten 

Betriebssystem-Image von CD oder USB- 

Stick gebootet werden. Damit startet er 

einen vorkonfigurierten und abgeschotteten 

Ubuntu-Server, der die Virtualisierung 

übernimmt. Danach loggt sich der Cloud- 

Admin in spe auf einem speziellen Internetportal 

ein, das ihm Verwaltungswerkzeuge 

für ein virtuelles Rechen zentrum 

präsentiert: Seine Virtualisierungsserver 

erscheinen dort als virtuelle Racks, die 

ihrerseits virtuelle Maschinen aufnehmen 

können. 

Bis dahin ist alles schnell und problemlos 

aufgesetzt, und auch die Oberfläche 

der Browserapplikation ist weitestgehend 

selbsterklärend (Abbildung 1), die Abfolge 

der Schritte logisch. Im Zuge der Inbetriebnahme 

empfiehlt es sich dann, als 

Erstes den Storage für die späteren virtuellen 

Maschinen (VMs) zu konfigurieren. 

Dafür ist zunächst eine lokale Festplatte 

oder ein lokal angeschlossenes Diskarray 

auszuwählen, das sich später in virtuelle 

Festplatten für die VMs zerlegen lässt. 

Lokaler Speicher ist Pflicht 

Aber hier liegt der Hase schon im Pfeffer: 

In absehbarer Zeit sollen sich zwar auch 

NFS- und iSCSI-Speicher einbinden lassen, 

in fernerer Zukunft vielleicht sogar 

Fibre-Channel-SANs, momentan funktionieren 

aber nur direkt verbundene Speichergeräte. 

Das kann naturgemäß nicht 

ohne Weiteres Shared Storage sein, auf 

den auch andere Virtualisierungshosts 

zugreifen, und deshalb wiederum sind 

die meisten der fortgeschritteneren Virtualisierungsfunktionen 

nicht realisierbar. 

So gibt es deswegen vor allem keine 

Live-Migration und also auch kein Load 

Balancing zwischen unterschiedlich ausgelasteten 

vRacks (sprich physischen 

Virtualisierungshosts). Auch Energiesparoptionen 

(Power Management), wie 

sie etwa der Marktführer VMware oder 

Citrix kennen, bei denen schlecht ausgenutzte 

Server ganz abgeschaltet werden, 

nachdem ihre VMs woanders unterkamen, 

sind nicht realisierbar. Daneben fallen 

auch Hochverfügbarkeitscluster unter 

den Tisch, die ebenfalls auf die Migration 

setzen müssten. Der Virtualisierungshost 

(aka vRack) bleibt so ein Single Point of 

Failure. 

Schon aus diesem Grund empfiehlt er 

sich nicht für geschäftskritische Anwendungen. 

Aber schlimmer noch: Im 

Moment ist auch ein Desaster Recovery 

der VMs schwierig. Snapshots fehlen 

nämlich ganz. Ein Export der virtuellen 

Platten steht zwar auf der Roadmap, ist 

aber noch nicht realisiert. Selbst wenn 


Virtual Core 

Test 

Abbildung 1: Die Browser-GUI von Virtual-Core nach der ersten Registrierung. Die nächsten Schritte werden 

schon aufgelistet. 

Dass sich der Server so zugeknöpft zeigt, 

hat zudem weitere Nachteile. Beispielsweise 

sind deshalb auch seine Linux- 

Logs unerreichbar, die Auskunft über den 

Zustand seiner Hardware oder auch über 

Sicherheitsvorfälle geben könnten. Lediglich 

ein vorgefiltertes Log der Applikation 

lässt sich über den Browser einsehen, das 

aber viele wichtige Details nicht enthält. 

Der Anwender steht damit im eigenen 

Rechenzentrum und unter seiner Verantwortung 

hilflos und verloren vor einer 

Black Box, einem womöglich defekten 

System, das die Diagnose verhindert und 

damit auch nicht mehr therapierbar ist. 

So unfertig wie in Bezug auf die Auses 

ihn gäbe, wäre die Konfiguration der 

VMs verloren und müsste aus manuellen 

Aufzeichnungen oder dergleichen rekonstruiert 

werden. Auch die Daten des virtuellen 

Data Center und seiner vRacks – 

also etwa die Benutzer, Gruppen, Rollen, 

Storage-Einstellungen und dergleichen 

– sind heute nicht sicherbar. Der Virtualisierungshost 

selbst sperrt sich gegen 

Login-Versuche und vereitelt damit auch 

prinzipiell denkbare Selbsthilfe. Damit 

steht man bei jedem Hardwareausfall vor 

einer unkalkulierbaren Downtime und 

Problemen, die gerade der weniger versierte 

Anwender, den die Lösung adressieren 

will, nicht mehr bewältigen kann. 

Abbildung 2: Ein einfacher Dialog ermöglicht die Zuweisung von Rechten zu jedem Benutzer-Account. 

Ähnliches lässt sich auch für Gruppen einstellen. 

fallsicherheit wirkt das Konzept auch in 

anderen Details. So gibt es zwar Benutzerrollen, 

aber man muss mit den vier 

vorgefertigten vorliebnehmen und kann 

keine eigenen einrichten oder vorhandene 

modifizieren. Alternativ sollen sich 

dafür Benutzergruppen eignen. Denen 

kann man rund ein Dutzend Rechte vergeben 

(Abbildung 2), die dabei immer 

gleichzeitig mit genau einer VM verbunden 

sind – VMware kennt zum Vergleich 

über 100 verschiedene Benutzerrechte. 

Auch ist es unmöglich, den Speicherplatz 

oder konsumierbare Netzwerkbandbreite 

via Quotas einzuschränken, denn die gibt 

es ebenfalls nicht. 

Im Vergleich mit anderen Virtualisierungslösungen 

offenbaren sich weitere 

Fehlstellen, zum Beispiel mit Blick auf 

das virtuelle Netzwerk (kein Bonding 

oder Failover, kein Load Balancing) oder 

mit Blick auf die Ressourcenverwaltung 

(es fehlen Ressourcenpools, garantierbare 

Zuteilungen und Limits, auch kann man 

auf einer Mehrprozessormaschine beispielsweise 

die CPU-Affinität einzelner 

VMs nicht beeinflussen). 

Preisfrage 

Bleibt als ein möglicher Wettbewerbsvorteil 

noch der Preis. Tatsächlich ist die 

Lösung recht günstig. KAMP berechnet 

pro Monat und Rack knapp 10 Euro plus 

knapp 3 Euro für jede VM. Macht bei 

einer kleinen Installation mit zwei Racks 

und je fünf VMs 600 Euro im Jahr. Für die 

Citrix XenServer Enterprise Edition muss 

man zum Vergleich schon 2500 Dollar pro 

Server hinlegen. Allerdings einmalig und 

mit unlimitierter Anzahl VMs. 

Und Citrix hat Load Balancing, Host 

Power Management, Snapshots, ein 

umfangreiches Alerting und Reporting, 

automatische Sicherung und Wiederherstellung 

von VMs, heterogene Ressourcenpools, 

HA-Features, eine echte 

rollenbasierte Administration und manches 

mehr. Eine Basisversion mit weniger 

Features gibt es zudem kostenlos. Der 

ESXi-Server von VMware ist für noch etwas 

mehr Geld noch etwas üppiger ausgestattet 

zu haben. Eine Einstiegsversion 

ist aber auch hier umsonst. Wo da Platz 

für eine Lösung bleibt, bei der man sich 

für mehrere Hundert Euro ein erhebliches 

Betriebsrisiko einkauft, bleibt fraglich.n 


Admin 


73

Test 

Operations Manager 2012 

© Natalia Lukiyanova, 123RF 

Microsoft System Center Operations Manager 2012 RC 

Ausgepackt 

Der neue System Center Operations Manager 2012 von Microsoft kann 

nicht nur Windows-Server überwachen. Auch das Monitoring von Linux- 

Servern und Netzwerkgeräten wie Switches oder Router ist in der neuen 

Version besser gelöst als in Vorgänger-Varianten. Thomas Joos 

Der System Center Operations Manager 

besitzt eine lange Geschichte, die 

irgendwo in England begann: Vor beinahe 

15 Jahren entwickelte die Firma 

Serverware ein Netzwerk-Managementsystem, 

das 1998 von Mission Critical 

Software aufgekauft wurde. Die wiederum 

schloss sich im Jahr 2000 mit NetIQ 

zusammen und verkaufte das Programm 

an Microsoft. Irgendwann wurden dann 

die Altlasten zu viel, und der Windows- 

Konzern entschloss sich mit dem System 

Center Operations Manager 2007 zu einem 

Neuanfang. Jetzt liegt der Release- 

Kandidat für System Center Operations 

Manager (OPS) vor, den dieser Artikel im 

Folgenden näher unter die Lupe nimmt. 

Grundlegend verbessert wurde im OPS 

2012 [1] das Monitoring heterogener 

Netzwerke. So sind die Anbindung von 

Linux-Servern sowie von Switches und 

Routern in der neuen Version wesentlich 

besser gelöst als in der Vorversion. 

Auch serverbasierte Anwendungen auf 

Basis von Java lassen sich mit OPS 2012 

überwachen. Java-Application-Server wie 

Websphere 6.1/7, WebLogic 10 und 11, 

JBooss und Tomcat können Unternehmen 

genauso überwachen wie Dotnet-Anwendungen 

und Microsoft-Serverdienste wie 

Exchange und Co. 

In der neuen Version benötigt der Überwachungs-Agent 

auf Linux-Servern nicht 

in jedem Fall Root-Rechte. Er arbeitet so 

lange mit eingeschränkten Rechten wie 

es möglich ist. Nur wenn ein Überwachungsprozess 

mehr Rechte verlangt, erhält 

der die Root-Rechte. Durch die bessere 

Umsetzung des Linux-Rechtemodells 

erhöht sich ein Stück weit die Sicherheit 

im Netzwerk. 

Microsoft meets Unix 

Linux ist nicht die einzige vom Operation 

Manager unterstützte Unix-Variante: Aktuell 

nennt Microsoft HP-UX 11i v2 und 

v3 (PA-RISC und IA64), Oracle Solaris 

9/10, Red Hat Enterprise Linux 4/5/6 

sowie Suse Linux Enterprise Server 9/ 

10SP1 und 11 als unterstützte Systeme. 

Auch IBM AIX 5.3, AIX 6.1 (POWER) und 

AIX 7.1 (POWER) lassen sich mit Agenten 

überwachen. In den meisten Fällen 

unterstützt der Agent 32-Bit- aber auch 

64-Bit-Systeme. Der Server selbst muss 

aber auf einem 64-Bit-Server installiert 

sein und am besten auch eine 64-Bit- 

Version von SQL Server 2008 oder 2008 

R2 mit aktuellen Servicepacks nutzen. 

Besonders interessant für Linux-Administratoren 

ist der Unix/Linux Shell Command 

Template Management Pack [2]. 

Abbildung 1: Operations Manager 2012 mit neuer Installationsoberfläche. 

Abbildung 2: Erstellen von Verwaltungs-Server-Gruppen. 


Operations Manager 2012 

Test 

Die Sammlung ermöglicht das Erstellen 

von Überwachungsregeln auf dem OPS 

2012 zur Ausführung von Linux-Befehlen 

direkt auf den überwachten Servern. Anleitungen 

finden Administratoren auf der 

Seite [3]. Diese gelten auch für aktuelle 

Versionen in den meisten Fällen. 

OPS 2012 integriert die Überwachung von 

Netzwerkgeräten und Servern. Das System 

erkennt zum Beispiel auch die Ports, 

an denen einzelne Server angeschlossen 

sind und kann diese gleichzeitig mit dem 

jeweiligen Server überwachen. Fällt ein 

Port aus, erkennt OPS 2012 daher auch, 

welche Server eingeschränkt funktionieren 

und kann entsprechende Regeln und 

Maßnahmen aktivieren. 

Bessere Verfügbarkeit und 

Verwaltung 

In bisherigen Versionen des Operation 

Manager gab es einen Überwachungs- 

Server, der über allen anderen angeordnet 

war. Dieser Root Management Server 

(RMS) stellte ein klares Single Point of 

Failure dar. Daher betrieben viele Unternehmen 

diesen in einem hochverfügbaren 

Setup, was zu hohen Kosten führte. 

In OPS 2012 sind alle Verwaltungsserver 

gleichberechtigt. RMS gibt es keine mehr, 

und ein Cluster für Verwaltungsserver 

ist weder notwendig, noch unterstützt. 

Dafür lassen sich Verwaltungsserver in 

der neuen Version gruppieren und verschiedenen 

Überwachungsaufgaben zuordnen. 

Fällt ein Server aus, übernehmen 

die anderen Server in der Gruppe seine 

Überwachungsaufgaben. 

Anwendungen und Netzwerkhardware 

wie Switches, Firewalls oder Router lassen 

sich mit OPS 2012 effizienter überwachen. 

In diesem Bereich kann OPS 2012 

den Durchsatz und die Verfügbarkeit der 

Komponenten besser darstellen. Die neue 

Version erkennt zum Beispiel, an welchem 

Port eines Switch ein überwachter 

Server angeschlossen ist und kann speziell 

diesen überwachen. Auch für die Abbildung 

der Infrastruktur ist das sinnvoll. 

OPS 2012 bietet sich deshalb für umfassendes 

Netzwerkmanagement an. 

Die Verwaltungskonsole hat Microsoft 

komplett überarbeitet. Zusätzlich gibt 

es eine vorkonfigurierte Webkonsole zur 

Bedienung des Operation Manager 2012, 

die sich gezielt auf einzelnen Servern ins- 

tallieren lässt. Auch die Powershell erhält 

durch Installation von OPS 2012 RC neue 

Commandlets und ermöglicht weitgehendes 

Skripting des Monitoring. 

Verschiedene Überwachungsaufgaben 

stehen auch als Webparts zur Verfügung, 

für die Einbindung in das eigene Intranet, 

zum Beispiel über Sharepoint. Mit 

ihnen können Administratoren schnell 

und einfach eigene Dashboards bauen, 

um genau die überwachten Server anzuzeigen, 

die aktuell im Fokus stehen. 

Dadurch ist die Darstellung nicht mehr 

mit zu vielen Informationen überfrachtet, 

sondern kann diese besser filtern. 

Microsoft erläutert die Vorgehensweise 

auf der Technet-Seite [4] und dem Blog 

der OPS-Entwickler [5]. 

Fazit 

Unternehmen, die eine Überwachungslösung 

für gemischte Netzwerke suchen, 

sollten sich OPS 2012 RC ansehen. Die 

Testversion steht bei Microsoft zum 

Download zur Verfügung 

[6]. Anleitungen 

zur Installation gibt es 

auf der Technet-Site 

unter [7]. 

Natürlich ist auch OPS 

2012 vor allem für den 

Einsatz in Microsoft- 

Netzwerken optimiert: 

Der Server steht nur 

für Windows zur Verfügung, 

die Webkonsole 

setzt den IIS voraus, 

und als Datenbank verlangt 

die Software den 

Microsoft SQL Server 

2008 oder R2. 

Wer überhaupt keine 

Windows-Server im 

Einsatz hat, findet in 

Systemen wie Nagios 

oder OpenNMS sicher 

bessere Möglichkeiten. 

In heterogenen Netzwerken 

mit Microsoftund 

mehreren Unixoder 

Linux-Servern ist 

der Operation Manager 

2012 allerdings leistungsfähiger 

als die 

Open-Source-Konkurrenz. 

(ofr) 

n 

Infos 

[1] System Center Configuration Manager 

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

en‐us/ server‐cloud/ system‐center/ 

configuration‐manager‐2012. aspx] 

[2] Unix/Linux Shell Command Template 

Management Pack: [http:// www. microsoft. 

com/ download/ en/ details. aspx? id=27974] 

[3] Blog zu Microsoft System Center von 

Anders Bengtsson: 

[http:// contoso. se/ blog/ ? p=459] 

[4] Create a Dashboard View: 

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

library/ hh227265. aspx] 

[5] Introducing Operations Manager 2012 

Dashboards: 

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

archive/ 2011/ 09/ 27/ introducing‐operations 

‐manager‐2012‐dashboards. aspx] 

[6] Eval Center: [http:// technet. microsoft. 

com/ de‐de/ evalcenter/ hh505660] 

[7] Installationsanleitung: 

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

library/ hh205996. aspx] 


Admin 


75

Test 

Fedora 16 

© Leonid Yastremskiyœ, 123RF 

Fedora 16 mit Cloud- und Virtualisierungs-Technologien 

Testlabor 

Die neueste Fedora-Version bietet ein gut gefülltes Sortiment neuester 

Basistechnologien. Da das Fedora-Projekt als Experimentierfeld für Red 

Hats Enterprise-Distributionen dient, kann der interessierte Administrator 

damit frühzeitig einen Blick auf kommende, für RHEL und RHEV geplante 

Technologien werfen. Thomas Drilling 

Fedora 16 positioniert sich mit seinen 

Schlüsselfeatures Kernel 3.1 und Gnome 

3.2.1 wie gewohnt als Pionier in Sachen 

Linux-Technotrends. Die von Fedora angepasste 

Gnome-Version 3.2.1 hat das 

Zeug, sich unter den Nicht-KDE-Distributionen 

an die Spitze der Nutzer-Gunst zu 

katapultieren und vor allem Ubuntu dank 

unglücklichem Unity-Start Nutzer abzujagen. 

Zwar wirkt Ubuntu in der Gesamtheit 

seiner Komponenten stimmiger, die 

in Fedora 16 enthaltene Gnome-Version 

überzeugt aber mehr als Unity. 

Für Administratoren sind nur einige Features 

von Gnome 3.2.1 interessant, wie 

etwa die desktopweite Integration von 

Online-Konten, samt zugehöriger Anwendungen 

Gnome Documents und Gnome 

Contacts, sowie die zahlreichen kleinen 

Verbesserungen an der Gnome-Shell, 

nur am Rande. Für Administratoren und 

Entwickler wichtiger sind die in Fedora 

16 enthaltenen Development-Tools, wie 

Perl 5.14, die GCC-Python-Plugins, die 

Haskell-Platform und D2, die neueste 

Version der Programmiersprache D. Noch 

bedeutender scheinen die mit dem Kernel 

3.1 einhergehenden neuen Funktionen 

für KVM und Xen sowie die überdurchschnittliche 

Ausstattung an Tools für Virtualisierung 

und Cloud Computing. 

Neuer Kernel 3.1 

Neben dem bei Fedora per Default aktiven 

SELinux lohnt sich vor allem ein 

Blick auf den neuen Kernel 3.1. Von den 

enthaltenen Verbesserungen am Btrfs- 

Dateisystem, wie etwa den geänderten 

Locking-Mechanismen, welche vorrangig 

für mehr Geschwindigkeit sorgen, profitiert 

Fedora 16 allerdings per Default 

noch nicht, weil sich die Red-Hat-Entwickler 

trotz ursprünglicher Planungen 

bei Fedora 16 noch einmal für Ext4 als 

Standard-Dateisystem entschieden haben. 

Der Grund dafür ist in erster Linie, 

dass es für Btrfs noch keine Reparatur- 

Tools gibt und das Dateisystem immer 

noch als experimentell gilt. 

Außerdem erfuhr die erstmals beim Kernel 

2.6.39 aufgenommene Unterstützung 

für Ipset einige Verbesserungen, die es 

unter anderem dem Firewall-Code ermöglicht, 

die Tabellen mit Filter-Informationen 

flexibler nutzen zu können. 

Außerdem erhielt der neue Kernel einen 

relativ umfangreichen Patch, der 

das seit 2.6.38 enthaltene iSCSI-Target- 

Framework LIO auf den Stand von LIO 

4.1 bringt. Der Kernel-Code für Software-RAID 

beherrscht jetzt Bad-Block- 

Management bei den RAID-Leveln 1, 4, 

5 und 6 und kann damit defekte Plattensektoren 

der für den RAID-Verbund 

benutzten Datenträger erkennen. 

Das im Kernel 3.1 zur Laufwerks-Verschlüsselung 

genutzte Dm-Crypt ist in 

der Lage, Discard-Kommandos an das darunterliegende 

Medium weiterzureichen. 

Damit lassen sich zum Beispiel SSDs mithilfe 

des ATA-Kommandos Trim über frei 

gewordene Bereiche in Kenntnis setzen, 

was Lebensdauer und Geschwindigkeit 

zugute kommt. 

Neben der turnusmäßigen Verbesserung 

der Hardware-Unterstützung haben die 

Kernel-Entwickler vor allem eine Reihe 

wichtiger Optimierungen für die Kernelbasierten 

Virtualisierungslösungen KVM 

und Xen implementiert, die den jeweiligen 

Funktionsumfang erweitern oder die 

Geschwindigkeit erhöhen. Nachdem die 

Kernel-Entwickler bereits den Kernel 3.0 

um die letzten noch fehlenden Komponenten 

für die Zusammenarbeit mit dem 

Xen-Hypervisor als Dom0 erweitert hatten, 

widmeten sie sich beim Kernel 3.1 

dem Xen-PCI-Backend. Mit dessen Hilfe 

lassen sich PCI/PCIe-Geräte an Xen-Gäste 

durchreichen. 

Für Fedora eher interessant: Der Kernel- 

Code für KVM besitzt jetzt grundlegende 

Funktionen, die es auch auf Systemen 

mit Intel-Prozessoren ermöglichen, Gast- 


Fedora 16 

Test 

systeme aus einem anderen Gastsystem 

heraus zu starten (Nested Virtualization). 

Der KVM-Kernel-Code für AMD-Prozessoren 

beherrschte Nested Virtualization 

schon seit 2009. Außerdem beherrscht der 

Kernel 3.1 jetzt die experimentelle Unterstützung 

von Zero-Copy-RX für Macvtap 

und Vhost-net, die aber per Default noch 

abgeschaltet ist. Mit Zero-Copy-RX lässt 

sich die Netzwerkperformance in der Virtualisierung 

verbessern, weil die Funktion 

den Verwaltungs-Overhead reduziert, der 

beim Empfangen oder Weiterreichen von 

Netzwerkdaten, beziehungsweise durch 

den Host selbst entsteht. 

Fedora Cloud 

Red Hat verfolgt seit einigen Jahren unübersehbar 

das Ziel, sich durch gezielte 

Zukäufe ein weiteres strategisches Standbein 

im Bereich Virtualisierung zu verschaffen. 

So basieren die eigenen Enterprise-Produkte 

im Virtualisierungssektor 

Abbildung 1: Fedora bringt das webbasierte Cloud-Management-Tool Aeolus mit. 

der derzeit am stärksten wachsenden 

Virtualisierungstechnologie. So positioniert 

sich Red Hats eigene Enterprisezwar 

auf freien Technologien wie KVM, 

Red Hat hat aber als KVM-Eigner großen 

Einfluss auf die Weiterentwicklung 

7,90€ * 

100 Seiten Linux 

+ DVD 

Die aktuelle Ausgabe von 

LinuxUser Spezial dringt in die 

Tiefen des Linux-Systems ein und 

zeigt, wie Sie Ihren Rechner auf 

der Kommandozeile administrieren. 

Jetzt bestellen 

unter: www.linuxuser.de/spezial 

Tel.: 089-9934110, Fax: 089-99341199, E-Mail: order@linuxnewmedia.de 


Admin 


77

Test 

Fedora 16 

Virtualisierungslösung RHEV neben 

VMWare und Citric Xen Server selbstbewusst 

als dritte Kraft im Wettstreit der 

großen Infrastrukturanbieter. Nutzer von 

Fedora 16 profitieren damit zwangsläufig 

von den für RHEV entwickelten Technologien, 

die weit über das hinausgehen, 

was der Kernel und damit auch andere 

Distributionen in Sachen Virtualisierung 

von sich aus bieten. 

Was das Thema Cloud angeht enthält 

Fedora 16 das verteilte Dateisystem 

HekaFS 0.7, eine für die Cloud ausgelegte 

Version von GlusterFS. Während 

HekaFS Cloud-fähige verteilte Dateisysteme 

zur Verfügung stellt, lassen sich 

Cloud- Instanzen mit dem Webinterface 

Aeolus Conductor (Abbildung 1) erzeugen 

und verwalten. Außerdem enthält Fedora 

16 die Cloud-Hochverfügbarkeitslösung 

Pacemaker nebst Open-Stack-Tools, mit 

denen sich Cloud- und Storage-Lösungen 

konfigurieren und betreiben lassen, sowie 

die IaaS-Implementierung Condor Cloud. 

Virtualisierungslösungen 

Zwar konzentriert sich Red Hat vorrangig 

auf KVM als zentrale Virtualisierungslösung, 

der in Fedora 16 enthaltene Kernel 

3.1 bietet aber mit dem beschriebenen 

Dom0-Support auch eine entscheidende 

Verbesserung für die ebenfalls freie Alternative 

Xen. Darüber hinaus haben 

die Red-Hat-Entwickler eine Reihe von 

Verbesserungen am grafischen Interface 

Virt-Manager (Abbildung 2) vorgenommen, 

mit dessen Hilfe der Admin jetzt 

deutlich mehr Informationen über den 

Status laufende Gastsysteme erhält und 

sogar lesend auf deren Gast-Dateisysteme 

zugreifen kann. 

Bei Windows-Gästen lässt sich sogar 

die Registry inspizieren. Außerdem 

verhindert Fedora 16 mit dem Virtual 

Machine Lock Manager, dass zwei virtuelle 

Maschinen gleichzeitig auf das 

gleiche Disk-Image zugreifen, was fatale 

Folgen hätte und etwa dann passieren 

kann, wenn der Admin die gleiche VM 

unbeabsichtigt zweimal startet. Fedora 

16 enthält eine neue Version des von Red 

Hat als zentrale Komponente für seine 

Server-Virtualisierung RHEV entwickelten 

Spice-Protokolls, sodass auch Fedora 

jetzt USB-Geräte zwischen Gast und Host 

teilen kann (USB Passthrough). Ein USB 

Redirect auf andere Hosts im Netzwerk 

ist ebenso möglich wie ein Abgleich der 

Lautstärke zwischen virtueller Maschine 

und Host-System. 

Allerdings bietet Spice noch keinen 

3D-Support, sodass sich GL-Effekte im 

Gastsystem, wie sie Fedora selbst oder 

Ubuntu als virtuelle Maschine verlangen, 

leider nicht nutzen lassen. Fedora 

16 lässt sich in verschiedenen Editionen, 

bei Fedora „Spins“ genannt, von der 

Projektseite [1] herunterladen. Einzelheiten 

zu den Neuerungen in Gnome 3 

und Fedora 16 finden sich in den Gnome 

Release Notes [2] sowie in den Fedora 

Release Notes [3]. 

Fazit 

Fedora 16 weist, wie der Codename 

„Verne“ mit seiner Reverenz an den 

Science-Fiction-Autor andeutet, einen 

Weg in die Zukunft und folgt in seiner 

Ausrichtung konsequent dem Motto, stets 

die Distribution mit den neuesten Technologien 

zu sein. Dass eine solche Philosophie 

nicht immer zu einem Produkt 

mit zufriedenen Endanwendern führt, 

haben frühere Versionen gelegentlich 

gezeigt. Allerdings haben die Red-Hat- 

Entwickler auch gar nicht das Ziel, die 

beste Desktop-Distribution am Markt zu 

bauen, sondern nutzen Fedora eher zum 

Test neuer Entwicklungen, die später in 

andere Produkte einfließen. 

Fedora 16 überzeugt indes in beiden Kategorien. 

Während der Gewinn des Titels 

als beste Desktop-Distribution vorrangig 

daran scheitert, dass das Nachrüsten 

proprietärer Komponenten wie Codecs 

umständlicher ist als bei der Konkurrenz, 

bietet Fedora 16 als Server-Distributionen 

einige Technologien, die sich so noch 

in keiner anderen Distribution finden. 

Übrigens ist Fedora 16 dem im Oktober 

2011 verstorbenen Unix-Pionier und 

Mit-Erfinder der Programmiersprache C 

Dennis Ritchie gewidmet. (ofr) n 

Infos 

[1] Fedora Download: [http:// fedoraproject. 

org/ de_CH/ get‐fedora‐options] 

[2] Gnome 3.2 Release Notes: [http:// library. 

gnome. org/ misc/ release‐notes/ 3. 2/] 

[3] Fedora 16 Release Notes: 

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

Fedora/ 16/ html/ Release_Notes/] 

Abbildung 2: Fedora installiert als Yum/RPM-basiertes System fehlende Pakete auch im laufenden Betrieb 

nach wie etwa KVM beim Start des Virtual Machine Managers. 

Der Autor 

Thomas Drilling ist seit mehr als zehn Jahren 

hauptberuflich als freier Journalist und Redakteur 

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

Er selbst und das Team seines Redaktionsbüros 

verfassen regelmäßig Beiträge zu den Themen 

Open Source, Linux, Server, IT-Administration und 

Mac OS X. Außerdem arbeitet Thomas Drilling als 

Buchautor und Verleger, berät als IT-Consultant 

kleine und mittlere Unternehmen und hält Vorträge 

zu Linux, Open Source und IT-Sicherheit. 


19 . DFN Workshop 

„Sicherheit in vernetzten Systemen” 

am 21. und 22. Februar 2012 

im Grand Elysée Hotel Hamburg 

- Vorträge zu verschiedenen Aspekten der 

IT-Sicherheit, u.a. Cloud Computing, IPv6 

und Netzwerksicherheit 

- Tutorium 

"DNSSEC in der Praxis“ 

Medienpartner: 

DFN 

Deutsches 

Forschungsnetz 

Weitere Informationen und die 

Anmeldung finden Sie unter: 

https://www.dfn-cert.de 

®

Test 

Univention 

© tasosk, 123RF 

Univention Corporate Server 3.0 

Runderneuert 

Mitte November ist der erste RC zum Univention Corporate Server 3.0 erschienen. Er bringt zahlreiche Verbesserungen 

mit und enthält als eine der ersten Distributionen das neue Samba 4. Florian Effenberger 

Wer eine große Zahl von Clients verwaltet, 

der benötigt vor allem Tools zum 

zentralen Management der Systeme sowie 

eine ausgereifte Benutzerverwaltung. 

Der Univention Corporate Server, kurz 

UCS, schickt sich an, all das in einem 

Linux-basierten Paket zu vereinen, und 

unterstützt dabei auch heterogene Umgebungen 

mit Windows. 

Weg mit den Turnschuhen! 

Geht es um Firmendesktops, unterscheiden 

sich die Anforderungen der 

Windows-Welt wenig von denen, die an 

Open-Source-Lösungen gestellt werden. 

Der wichtigste Aspekt ist die einfache 

Verwaltung der einzelnen Clients und 

Benutzer. Denn spätestens, wenn Hunderte 

Systeme an verschiedenen Standorten 

berücksichtigt werden müssen, stößt 

die vielzitierte Turnschuh-Administration 

schnell an ihre Grenzen. Während in der 

Windows-Welt zahlreiche Hersteller um 

die Gunst des Kunden buhlen und Small 

Business Server, System-Management- 

Tools und Identity-Lösungen feilbieten, 

vermögen routinierte Administratoren 

unter Linux das Zepter auch selbst in die 

Hand zu nehmen. Bevor man das Rad 

neu erfindet, lohnt es sich jedoch, einen 

Blick auf fertige Produkte zu werfen. Mit 

dem Corporate Server des Bremer Herstellers 

Univention [1] steht eine offene 

Lösung zur Verfügung, die zahlreiche 

freie Programme unter einem Dach vereint 

und dabei dem Administrator die 

nötigen Tools und Hilfsmittel an die Hand 

gibt, um auch ohne kryptische Kommandozeilenbefehle 

schnell zu Ergebnissen 

zu kommen. 

Für die aktuelle Version setzt der Bremer 

Hersteller dabei auf das bewährte Debian 

„Squeeze“ 6.0.3, und bietet ein eigenes 

Repository aller relevanten Pakete 


Univention 

Test 

an, das vereinzelt auch aktuellere Programmversionen 

beinhaltet. Als Kernel 

kommt Version 2.6.32 zum Einsatz, der 

grafische Desktop wird durch KDE 4.4 

bereitgestellt. Auch das Mailsystem basiert 

auf freien Komponenten: Mit Cyrus 

2.4 als IMAP- und Postfix 2.7 als SMTP- 

Server, Horde 4 für Webmail sowie dem 

erprobten Gespann aus Amavisd-new 

2.6, Spamassassin 3.3 und ClamAV 0.97 

kommen bewährte Tools zum Einsatz. 

Unterstützung für Shared Folders sowie 

einfache Verteilerlisten sind ebenfalls mit 

an Bord. Weiterhin enthalten sind Apache 

2.2, NTP 4.2 und PostgreSQL 8.4. 

Nimmt man die optional erhältlichen 

Komponenten hinzu, umfasst der UCS 

sowohl Serverbetriebssystem als auch 

Desktop-Umgebung, Client-Management 

mit Inventarisierungsfunktion und Identity-/Benutzerverwaltung. 

Die Virtualisierungslösungen 

KVM und Xen 4.1 sind 

standardmäßig als UMC-Modul „UCS 

Virtual Machine Manager“ (UVMM) vorhanden. 

Die Desktop Virtualization Services 

für virtualisierte Windows/Linux- 

Arbeitsplatz-Systeme ist dagegen eine 

zusätzliche Komponente, die man extra 

kaufen muss. 

Auch Terminal-Server und Kolab-Groupware 

sowie Netzdienste wie DHCP, DNS 

per BIND 9.8, ein Squid 3.1-Proxyserver, 

CUPS 1.4 als Printserver samt Quota- 

Support, Nagios 3.2 zum Systemmonitoring 

und die Systemsicherung per Bacula 

5.0 sind enthalten. Durch die Samba- 

Integration eignet sich UCS nicht nur für 

homogene Linux-Umgebungen, sondern 

ist dank Windows-Unterstützung auch in 

heterogenen IT-Landschaften einsetzbar. 

Abbildung 1: Der UCS arbeitet mit demselben Domänenmodell, das in der Windows-Welt gang und gäbe ist. 

eine Übersichtsseite mit zusätzlichen 

Links zu Nagios, Horde-Webmail und 

der integrierten Zertifizierungsstelle. Die 

eigentliche Konsole öffnet ihre Pforten 

mit dem Benutzernamen »Administrator« 

und dem bei der Installation vergebenen 

Passwort. Auch der SSH-Zugang steht ab 

Installation für »root« offen – im späteren 

Betrieb sollte hier jedoch unbedingt auf 

eine zertifikatsbasierte Anmeldung plus 

Sudo-Pflicht umgestellt werden. Intuitiv 

meldeten wir uns im Test zunächst als 

»root« im Webinterface an. Das funktioniert 

zwar, verwehrt aber die Einstelweitere 

Unterbrechung durch, startet das 

System neu und bringt es auf Wunsch per 

Online-Update auf den neuesten Stand. 

Zudem kann die Installation auch skriptgesteuert 

und damit vollständig automatisiert 

erfolgen. 

Alle weiteren Konfigurationsschritte 

nimmt der Administrator dann über die 

Weboberfläche vor, der Univention ein 

neues Modul namens Basiseinstellungen 

spendiert hat, was das Deployment 

mehrerer Server oder virtueller Maschinen 

erleichtern soll. Ein Aufruf von beispielsweise 

»http://192.168.1.1« zeigt 

Aller guten Dinge sind drei 

Zu Redaktionsschluss lag der erste RC der 

kommenden Version 3.0 vor, der nach 

Herstellerangaben [2] weitgehend dem 

Endprodukt entspricht. Die Installation 

geht schnell von der Hand, fragt sie doch 

nur die unbedingt nötigen Angaben wie 

beispielsweise Netzwerkeinstellungen ab. 

Gewöhnungsbedürftig ist lediglich, dass 

es nur ein textbasiertes Setup gibt. Das 

tut der Funktionalität zwar keinen Abbruch, 

geht bei umfangreichen Dialogen 

wie der Festplattenpartitionierung aber 

auf Kosten des Komforts. Sind alle Daten 

gesammelt, läuft die Installation ohne 

Abbildung 2: Bereits bei der Installation wird die Vielzahl der möglichen Anwendungsgebiete deutlich. 


Admin 


81

Test 

Univention 

Abbildung 3: Frisch und aufgeräumt präsentiert sich die Univention Management Console (UMC). 

lungen zur Domäne. Richtig ist daher, 

sich im Browser als »Administrator« einzuloggen. 

Frühjahrsputz 

Abbildung 4: Anstehende Änderungen werden vor Ausführung nochmals zusammengefasst. 

Die Konsole begrüßt den Administrator 

mit zweigeteilter Ansicht (siehe Abbildung 

3) und hat seit der Vorversion eine 

Generalüberholung erfahren. Sie wurde 

auf Basis von Ajax neu entwickelt und 

vereint die einstmals getrennten Module 

UMC (Management Console) und UDM 

(Directory Manager) unter einem Dach. 

Während die obere Hälfte Einstellungen 

zur Domäne beinhaltet – beispielsweise 

das Anlegen von Clients, die Verwaltung 

von Nutzern sowie das Festlegen von 

Richtlinien – sind die hostspezifischen 

Optionen wie Netzwerkkonfiguration, 

Serverrolle oder Virtualisierungseinstellungen 

in der unteren Hälfte gruppiert. 

Die Einstellungen sind auf Registerkarten 

(Tabs) zusammengefasst, die sich aber 

leider nicht verschieben lassen. Vereinzelt 

traten mit dem RC noch Probleme 

auf – so funktionierte die Änderung des 

Zertifikats erst im zweiten Anlauf, und 

das Online-Update vermochte nur auf der 

Kommandozeile seines Amtes zu walten. 

Alles in allem macht die Oberfläche aber 

einen schnellen, übersichtlichen und frischen 

Eindruck. Vor größeren Konfigurationen 

fasst eine Dialogbox nochmals alle 

Änderungen zusammen (siehe Abbildung 

4), und bei fehlerhaften Einstellungen 

wird das Tab farblich hervorgehoben, auf 

dem eine Korrektur nötig ist. 

Zudem bieten fast alle Dialoge das Filtern 

oder Sortieren von Elementen an, und wo 

möglich werden Einträge aus dem LDAP- 

Verzeichnis zur Auswahl angeboten, wobei 

Vererbung unterstützt wird. Schön 

gelöst ist die Integration der einzelnen 

Komponenten: Neu angelegte Rechner 

lassen sich automatisch zu Nagios hinzufügen, 

beziehen ihre Netzwerkkonfiguration 

aus vorher angelegten DHCP- und 

DNS-Einträgen (siehe Abbildung 5), und 

berechtigte Benutzer werden bei Bedarf 

als Gruppe beispielsweise zu Druckerfreigaben 

hinzugefügt. Zudem können 

Gruppen wiederum andere Gruppen beinhalten, 

was das Abbilden von Organisationsstrukturen 

erleichtert. 

Ebenso leistungsfähig ist die Benutzerverwaltung 

(siehe Abbildung 6). Hier 

wird nicht nur das Konto erstellt, sondern 

gleichzeitig festgelegt, welchen Gruppen 

und Organisationseinheiten es zugehört 

und welche Mailadresse angelegt werden 

soll. Die Berechtigungen sind dabei 

feingranuliert regelbar: Einzelne Anmeldeverfahren 

– beispielsweise der Zugang 

zu Windows-Clients – lassen sich deaktivieren, 

das Ablaufdatum für Passwörter 

oder Konten festlegen. 

Für die jeweiligen Systeme sind überdies 

zusätzliche Anmeldeeinstellungen 

verfügbar: Unter Windows können das 

Anmeldeskript samt Systempfaden sowie 

die erlaubten Login-Zeiten definiert werden, 

wogegen für Linux beispielsweise 

die Login-Shell eingestellt werden kann. 

Sogar vollständige Kontaktinformationen 

wie Telefonnummer und Anschrift nimmt 

der Verzeichnisdienst dankbar auf, von 

wo aus sie theoretisch von Drittanbieter- 

Applikationen wie Thunderbird ausgelesen 

werden könnten. 

Tanze Samba mit mir 

Mit UCS 3.0 steht eines der ersten kommerziellen 

Produkte zur Verfügung, 

das Samba 4 integriert. Zwar steht 

dieses Release offiziell noch gar nicht 

als finale Version zur Verfügung, [3] 

wird von Univention jedoch im Rahmen 

des Produktsupports offiziell und 

für den Produktiveinsatz unterstützt. 

Für das UCS-System, das auch Samba 4 

be inhaltet, spricht der Hersteller dabei 

von einer Skalierbarkeit bis mindestens 

5000 Nutzer. 

In der Praxis hängt die maximale Anzahl 

unterstützter User aber mehr von der 

verwendeten Hardware ab als von der 

Serversoftware. Bei der Vorgängerversion 


Univention 

Test 

des UCS mit Samba 3 berichtet Univention 

beispielsweise von Installationen mit 

bis zu 70 000 Anwendern. 

Im Vergleich zum Vorgänger Samba 3 

wurde die aktuelle Version von Grund auf 

neu konzipiert und unterstützt erstmals 

den Aufbau einer vollwertigen Windows- 

Domäne mit Active Directory samt Gruppenrichtlinien 

– lediglich Vertrauensstellungen 

und sogenannte Forest-Domänen 

fehlen derzeit noch. Samba-4-Domänen 

lassen sich mit denselben Tools konfigurieren 

wie ein echter Windows-Server, 

was die Hürde bei der Migration auf freie 

Software deutlich senkt. Da Samba 4 im 

Vergleich zum Vorgänger, der lediglich 

NT-Domänen anbot, einen eigenen LDAP- 

Server mitbringt, hat Univention für den 

Abgleich der Daten zwischen Samba 

und dem Rest des Systems einen eigenen 

Dienst entwickelt, der die Datenbestände 

konsistent hält. 

Wahlfreiheit 

Anwender, die das Update auf die aktuelle 

Version wegen der weitreichenden 

Änderungen und etwaiger nötiger 

Downtimes noch scheuen, können UCS 

3.0 auch problemlos mit der gewohnten 

3er-Version installieren, und die Aktualisierung 

erst später vornehmen. Auch die 

bisherige Version wird von Univention 

regulär im Rahmen des Produktsupports 

unterstützt. Die einzige Einschränkung: 

Ein Parallelbetrieb von Samba 3 und 

Samba 4 ist technisch nicht möglich, da 

die Windows-Systeme sich jeweils nur 

an einem der beiden Server anmelden 

können. Denkbar sind aber Update-Szenarien, 

in denen schrittweise von UCS 

2.4 mit Samba 3 auf UCS 3.0 mit Samba 4 

umgestellt werden soll, wozu das Herstellerwiki 

einen Leitfaden bereithält. [4] 

Fit für IPv6 

Abbildung 5: Das Anlegen eines neuen Rechners geht schnell von der Hand. 

Langsam aber sicher muss sich jeder 

Administrator mit der nächsten Generation 

des Internet-Protokolls beschäftigen, 

wird doch die Zahl der verfügbaren 

IPv4-Adressen immer knapper und die 

Vergabepolitik der Provider entsprechend 

strenger. Leider sind viele Hersteller von 

Soft- und Hardware mit der Unterstützung 

noch zurückhaltend. Umso erfreulicher 

ist, dass UCS 3.0 direkt bei der 

Installation die Einrichtung von IPv6- 

Netzwerkinterfaces anbietet, wobei neben 

der statischen Konfiguration auch 

Unterstützung für die Stateless Autoconfiguration 

enthalten ist. 

IPv6 verlangt dem Administrator jedoch 

einiges mehr an Sensibilität bezüglich der 

Sicherheit ab, denn auch vermeintlich 

interne Server erhalten dann eine von 

außen direkt erreichbare Adresse – der 

„Schutz“ durch NAT entfällt damit. Um 

diesen gestiegenen Sicherheitsanforderungen 

gerecht zu werden und gerade 

unbedarfte Systemverwalter vor bösen 

Überraschungen zu bewahren, ist bei einer 

Neuinstallation des UCS die Firewall 

künftig auf »deny all« gestellt, sprich: 

Eingehende Verbindungen sind nur auf 

die explizit installierten Dienste möglich. 

Bei einer Upgradeinstallation hingegen 

setzt UCS diese Einstellung nicht 

automatisch. 

Wir sind viele 

Auch die integrierten Virtualisierungsdienste 

haben eine Überarbeitung erfahren. 

So liefert UCS 3.0 standardmäßig 

zwei verschiedene Lösungen aus, namentlich 

Xen in Version 4.1, sowie das im 

Linux-Kernel standardmäßig integrierte 

KVM, wobei Letzteres auch Snapshots 

und Suspend unterstützt. Die Thin 

Client Services, eine Managementlösung 

zur Verwaltung von Thin-Clients unterschiedlicher 

Hersteller, wurden ebenfalls 

komplett überarbeitet und werden im 

Rahmen des eigenständigen Produktes 

UCS TCS voraussichtlich im ersten Quartal 

2012 auf den Markt kommen. 

Die Guten ins Töpfchen 

Auch im Detail bringt der UCS 3.0 einige 

Änderungen mit sich. Während Univention 

die eigenen Kolab-Pakete durch offizielle 

und zertifizierte Hersteller-Pakete 

ersetzt hat [5], wurde die Integration von 

Hylafax aus der Management Console 

entfernt, was allerdings einen Weg für 

Drittanbieter-Tools eröffnet. Gestrichen 

wurde zudem die sogenannte Sendebevollmächtigung 

– Univention verweist 

hierzu auf die Möglichkeit, den Absender 

im Mailprogramm beispielsweise bei 

Urlaubsvertretungen anders zu konfigurieren. 

Auch die Abkehr vom eigenen 

Backuptool »unidump« hin zu Bacula ist 

mit UCS 3.0 vollzogen. 

Sinnvoll erscheint der Verzicht auf eine 

eigene Installationsumgebung für Windows-Clients, 

bietet doch der Markt 

zahlreiche Lösungen wie beispielsweise 

Opsi [6], für das auch eine eigene UCS- 

Integration zur Verfügung steht. Zudem 

besteht somit die Möglichkeit, auch die 

installierten Anwendungsprogramme zu 

verwalten und dabei auf eine Vielzahl 

vordefinierter Pakete zurückzugreifen. 

Bestehende UCS-Systeme der Version 2.4 


Admin 


83

Test 

Univention 

lassen sich laut Herstellerwiki [7] zwar 

auf die neue Version updaten, je nach 

Konstellation ist dazu aber etwas Handarbeit 

nötig. 

Vorsicht ist beispielsweise beim Corporate 

Desktop oder bei Thin Clients geboten, 

da die auf UCS 3.0 aufbauenden 

Nachfolgeprodukte erst im Lauf des kommenden 

Jahres erscheinen werden und 

eine Kombination der alten Versionen 

mit dem neuen Basissystem nicht immer 

funktioniert. In den meisten Fällen lässt 

sich jedoch das bestehende UCS 2.x-System 

zum Slave degradieren und parallel 

zum UCS 3.0-Master betreiben. 

Kosten 

Eine Preisliste zur Version 3.0 stand bei 

Redaktionsschluss noch nicht zur Verfügung, 

voraussichtlich dürften aber 

etwa dieselben Konditionen wie für die 

Vorgängerversion [8] gelten: Ein Basissystem 

inklusive Maintenance schlägt 

beispielsweise mit jährlich 290 Euro zu 

Buche, zuzüglich knapp 26 Euro im ersten 

Jahr beziehungsweise knapp 9 Euro 

in Folgejahren pro Client und Nutzer. 

Module wie Groupware, Thin Client Services, 

Desktop-Virtualisierung und der 

Corporate Desktop kosten extra. 

Anwender, die die UCS-Vorgängerversion 

vor nicht mehr als 12 Monaten lizenziert 

haben und daher in den Genuss der 

Maintenance kommen oder den Maintenance-Vertrag 

entsprechend verlängert 

haben, können kostenfrei auf die neue 

Version umsteigen. Ebenfalls kostenfrei 

angeboten werden soll eine sogenannte 

Free-for-Personal-Use-Version [9], die 

alle Features des großen Bruders enthält, 

aber auf fünf Clients beschränkt ist. 

Ein Blick in die Kristallkugel 

Im Laufe des Jahres 2012 sollen weitere 

Produkte mit der neuen Systembasis freigegeben 

werden [10]. Im Fokus steht 

derzeit die Schulversion UCS@school, 

die Thin Client Services (TCS), die Desktop 

Virtualization Services (DVS) sowie 

der Corporate Desktop (UCD). Auch der 

Univention Corporate Server selbst soll 

weiterentwickelt werden: Unter anderem 

durch die Erweiterung der Management 

Console zur Verwaltung mehrerer Serversysteme, 

ergänzt um zusätzliche Berechtigungsprofile. 

Auch die Anbindung an 

andere Verzeichnisdienste soll ausgebaut 

werden. Ebenfalls auf der Agenda steht 

die Erweiterung des Xen-Hypervisors um 

Funktionen für Snapshots und Suspend, 

wie sie KVM schon unterstützt. 

Fazit 

UCS bringt in der aktuellen Version 3.0 

zahlreiche interessante Neuerungen, 

insbesondere die Management Console 

vermag zu überzeugen. Für Windows- 

Administratoren dürfte vor allem die Integration 

von Samba 4 von Interesse sein. 

Die Frage, ob eine Lösung aus einem Guss 

besser ist oder man die Flexibilität beim 

Zusammenstellen eines eigenen Systems 

bevorzugt, muss letzten Endes jeder Administrator 

für sich selbst entscheiden. 

An Funktionalität und Komfort stehen 

Linux-basierte Lösungen gleich welchen 

Herstellers den proprietären Konkurrenten 

mittlerweile in nichts nach – ganz im 

Gegenteil. (ofr) 

n 

Infos 

[1] Univention: [http:// www. univention. de] 

[2] Einschränkungen beim RC 1: [http:// forum. 

univention. de/ viewtopic. php? f=26& t=1617] 

[3] Diskussion über die Freigabe von Samba 

4: [http:// lists. samba. org/ archive/ 

samba‐technical/ 2011‐November/ 080482. 

html] 

[4] Updatepfade auf Samba 4: [http:// wiki. 

univention. de/ index. php? title=Update_to_ 

UCS_3. 0_Samba_4] 

[5] Zur Zarafa-Integration siehe: Thomas 

Drilling, Fundament für Teamarbeit, ADMIN 

06/2011 

[6] Florian Effenberger, Fenster mit Aussicht, 

Linux-Magazin 10/2009 

[7] Mischumgebungen mit UCS 2.x: [http:// 

wiki. univention. de/ ? title=UCS_3. 

0_‐_Auswahl_wichtiger_Neuerungen# 

Mischumgebungen_aus_UCS_2_und_UCS_3] 

[8] Preisliste: [http:// www. univention. de/ 

produkte/ preise/ preisbeispiele/] 

[9] FPU-Version: [http:// www. univention. de/ 

download/ free‐for‐personal‐use‐edition/] 

[10] Roadmap: [http:// www. univention. de/ 

produkte/ maintenance/ roadmap/] 

Abbildung 6: Auch die Benutzerverwaltung wartet mit zahlreichen Funktionen auf. 

Der Autor 

Florian Effenberger engagiert sich seit vielen 

Jahren ehrenamtlich für freie Software. Er ist 

Mitglied im Board of Directors der Document 

Foundation. Zuvor war er fast sieben Jahre im 

Projekt OpenOffice.org aktiv, zuletzt als Marketing 

Project Lead. Seine Arbeitsschwerpunkte 

liegen darüber hinaus in der Konzeption von 

Unternehmens- und Schulnetzwerken samt 

Softwareverteilungslösungen auf Basis freier 

Software. Zudem schreibt er regelmäßig für 

zahlreiche deutsch- und englischsprachige Fachpublikationen 

und beschäftigt sich dabei auch mit 

rechtlichen Fragestellungen. 




e14,95 

Jahres-DVD 

2011 

Alle Artikel des 

Jahres 2011 

■ Artikel zu Storage, Backup, 

Netzwerk, Monitoring, 

Virtualisierung u.v.m. 

■ Zum Lesen am Bildschirm 

oder Ausdrucken: PDF und 

HTML-Format 

■ Search Engine für 

Artikel-Volltext-Suche 

Außerdem auf der DVD: 

Bootbares Rettungssystem 

Jetzt gleich bestellen! 

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

Security 

pfSense 

© Alena Yakusheva, 123RF 

Firewall und Router-Distribution pfSense 

Schutzschild 

Auf den ersten Blick wirkt sie beinahe unscheinbar, beeindruckt aber 

beim näheren Hinsehen durch eine Fülle von Funktionen. Selbst fortgeschrittene 

Features wie Hochverfügbarkeit sind Teil ihres Repertoires. 

Ganz schön beeindruckend für eine kleine Firewall. Tim Schürmann 

Chris Buechler und Scott Ullrich waren 

unzufrieden. Zwar bot die FreeBSD-Distribution 

m0n0wall eine schnelle Einrichtung 

einer Firewall und eines Routers, 

war aber vollständig auf den Betrieb in 

eingebetteten Systemen zugeschnitten. 

Dort musste sie immer vollständig im 

Hauptspeicher laufen, wodurch sie sich 

unter anderem nicht besonders gut erweitern 

ließ. Also begannen die beiden 

ihre eigene Distribution zu stricken – pf- 

Sense war geboren. 

Die Ende September erschienene Version 

2.0 besteht im Kern aus FreeBSD 8.1, das 

auf den Einsatz als Firewall und Router 

zugeschnitten ist. Auf Wunsch arbeitet 

pfSense auch als DHCP-Server, Zulieferer 

für Sniffer wie Wireshark, VPN-Zugangspunkt, 

DNS-Server und sogar als WLAN 

Access Point. Dennoch bringt das komplette 

System gerade einmal 100 MByte 

auf die Waage, für den Start genügen 

ein USB-Stick und 128 MByte Hauptspeicher. 

Wem die eingebauten Funktionen 

noch nicht reichen, der darf pfSense über 

Pakete weiter aufbohren. So lassen sich 

beispielsweise ein Web-Proxy oder ein 

Intrusion Detection System (in Form von 

Snort) nachrüsten. Die Einrichtung sämtlicher 

Komponenten nimmt der Administrator 

bequem über eine ausgeklügelte 

Weboberfläche vor. Das alles ist dank 

BSD-Lizenz auch noch vollkommen kostenlos. 

Schweizer Messer 

Seinen merkwürdigen Namen hat pfSense 

von der aus OpenBSD übernommenen 

Firewall pf. Sie bietet eine zustandsorientierte 

Paketüberprüfung (Stateful Inspection), 

kann sich also merken, wer welche 

Verbindungen aufgebaut hat. Über Regeln 

blockt man nicht nur einzelne Ports 

oder Protokolle, sondern limitiert unter 

anderem auch die Anzahl gleichzeitiger 

Verbindungen für bestimmte Rechner 

und lenkt den Verkehr über vorgegebene 

Gateways. Mithilfe des Werkzeugs »p0f« 

unterscheidet pfSense sogar Betriebssysteme, 

sodass man beispielsweise allen 

Windows-Rechnern den Zugriff auf das 

Internet verbieten kann. Merkwürdig aussehende 

Pakete versucht pfSense automatisch 

zu korrigieren beziehungsweise 

zu normalisieren (Scrubbing) und so wiederum 

Angriffen vorzubeugen [2]. 

Um die Ausfallsicherheit zu erhöhen, 

lassen sich mehrere gleichzeitig lau- 


pfSense 

Security 

Abbildung 2: Hier sind die PCs nur über pfSense mit dem Internet verbunden. 

Seit pfSense 2.0 gibt es zusätzlich ein 

Image für USB-Sticks. Es bietet dieselben 

Inhalte wie die CD und ist für 

Rechner ohne CD-Laufwerk gedacht. 

Für diesen Fall sind die Dateien »pf- 

Sense‐memstick‐2.0‐RELEASE‐i386.img. 

gz« respektive »pfSense‐memstick‐2.0‐RE- 

LEASE‐amd64.img.gz« gedacht. 

Ergänzend zum Live-System stellen die 

Entwickler noch eine Embedded-Variante 

bereit. Sie startet von einer Cominteressant: 

Sobald 

man es aktiviert, 

müssen sich 

Benutzer zunächst 

auf einer speziellen 

Internetseite 

Abbildung 1: Die meisten der pfSense-Images sind für eingebettete Systeme authentifizieren, 

gedacht. Schnelle Netze erfordern aber auch einen schnellen Prozessor. um Zugang zum 

Netz beziehungsweise 

Internet zu erhalten [4]. 

fende pfSense-Firewalls koppeln. Fällt 

eine durch einen Hardwaredefekt aus, Besonders in größeren Netzen sorgt das 

übernimmt automatisch eine andere. Im Load Balancing für Entlastung. pfSense 

Hintergrund kommt dabei das Common verteilt dann den ausgehenden Datenverkehr 

auf mehrere WAN-Schnittstellen. 

Address Redundancy Protocol (CARP) 

zum Einsatz [3]. Auf Wunsch überträgt Fällt eine von ihnen aus, leitet pfSense 

eine pfSense-Installation seine geänderte den Verkehr automatisch auf die noch 

Konfiguration auf alle anderen und sorgt funktionierenden um. Analog kann pfper 

»pfsync« dafür, dass die Zustandstabellen 

aller laufenden Firewalls stets auf dungen auf mehrere Server verteilen. Das 

Sense eingehende Anfragen und Verbin- 

dem gleichen Stand sind. 

ist beispielsweise praktisch, wenn man 

stark frequentierte Webseiten betreibt. 

NAT und DHCP 

Sollte einer der Webserver ausfallen, leitet 

pfSense zudem die Anfragen automatisch 

an die übrigen um. 

Neben der Firewall enthält pfSense einen 

DHCP-Server und versteht sich auf Einen Wermutstropfen gibt es dann 

Network Adress Translation (NAT), die doch: pfSense unterstützt nur x86- oder 

selbstverständlich Port-Weiterleitung beherrscht 

und mit mehreren öffentlichen Systemanforderungen gelten zudem nur 

AMD64-Prozessoren. Die genügsamen 

IP-Adressen umgehen kann. pfSense lässt für eine einfache Firewall und ein kleines 

sich als Endpunkt für ein Virtual Private Netz. Sollen über den Rechner beispielsweise 

bis zu 200 Mbps laufen, verlangt 

Network (VPN) verwenden, sofern eines 

der Protokolle IPSec, OpenVPN oder PPTP pfSense schon einen Prozessor mit mindestens 

1 GHz. Nachträglich installierte 

zum Einsatz kommt. Das Captive Portal 

ist insbesondere für Hotspot-Betreiber Pakete, wie etwa Snort, verschlingen zu- 

sätzliches RAM. Eine praktische Berechnungstabelle 

haben die Macher unter [5] 

veröffentlicht. 

Wer der Downloadseite auf einen Mirror 

folgt, den erschlägt erst einmal eine 

Liste mit unzähligen Dateien (Abbildung 

1). Normalerweise benötigt man nur 

vom unteren Seitenrand das circa 100 

MByte große ISO-Image »pfSense‐2.0‐RE- 

LEASE‐i386.iso.gz«, auf einem AMD64- 

System greift man zu »pfSense‐2.0‐RE- 

LEASE‐amd64.iso.gz«. Auf eine CD gebrannt, 

startet von ihr dann wahlweise 

ein Installationsprogramm oder ein Live- 

System mit der Firewall. In dieser zuletzt 

genannten Betriebsart fehlen allerdings 

ein paar Funktionen, weshalb man pf- 

Sense möglichst auf einem Rechner oder 

in einer virtuellen Maschine installieren 

sollte. 

Image für Sticks 

Abbildung 3: Das Bootmenü von FreeBSD begrüßt den Admin nach dem Start von 

der CD beziehungsweise dem USB-Stick. 

Abbildung 4: Hier entscheiden zehn Sekunden, ob das Installationsprogramm 

oder das Live-System startet. 


Admin 


87

Security 

pfSense 

Abbildung 5: Die Schriftart, sowie Screen- und Keymap muss man nur in einigen 

seltenen Fällen ändern, wenn man über ein Terminal mit sfSense in Kontakt tritt. 

pact-Flash-Karte und läuft anschließend 

vollständig im Hauptspeicher. Von der 

Embedded-Fassung gibt es gleich mehrere 

Images: eines für jede Kombination 

aus Prozessorarchitektur, CF-Kartengröße 

(beziehungsweise internem Flash-Speicher) 

und Grafikkarte des Zielsystems. 

So enthält beispielsweise das Paket 

»pfSense‐2.0‐RELEASE‐1g‐amd64‐nanobsd_vga.img.gz« 

ein Image für eine CF- 

Karte mit 1 GByte Kapazität, die man in 

ein System mit AMD64-Prozessor steckt, 

das zusätzlich über eine Grafikkarte verfügt. 

Pakete ohne das Anhängsel »_vga« 

unterdrücken sämtliche Bildschirmausgaben 

und lassen sich am Rechner nur über 

eine serielle Schnittstelle ansprechen. 

Abschließend gibt es noch eine fertige 

virtuelle Maschine für VMware. Diese 

enthielt bei Redaktionsschluss allerdings 

noch die ältere Version 1.2.3. 

Um zu zeigen, wie einfach sich pfSense 

in Betrieb nehmen und einrichten lässt, 

soll es im Folgenden eine Fritzbox ersetzen, 

also ein kleines (Firmen-)LAN 

sicher mit dem Internet verbinden (wie 

in Abbildung 2). Benutzer erhalten in 

diesem Szenario nur dann Zugriff, wenn 

sie sich auf einer 

speziellen Portalseite 

gegenüber 

pfSense mit einem 

persönlichen Passwort 

authentifiziert 

haben. 

Fragestunde 

Nach dem Start 

der Live-CD überspringt 

man das 

Menü von FreeBSD 

einfach mit der Eingabetaste oder wartet 

zehn Sekunden (Abbildung 3). Wenn 

während des jetzt folgenden Bootprozesses 

Probleme auftauchen, sollte man 

die anderen Startoptionen von oben nach 

unten durchgehen: »2« schaltet ACPI aus, 

»4« startet einen abgesicherten Modus 

und »6« macht das unterliegende FreeBSD 

gesprächig, womit man wiederum störender 

Hardware auf die Schliche kommt. 

Läuft alles glatt, stellt pfSense irgendwann 

die Frage aus Abbildung 4. Hier 

drückt man möglichst innerhalb der 10 

Sekunden »i«. Verpasst man den Zeitpunkt, 

startet pfSense automatisch im 

Live-Modus. Dabei stellt es die gleichen 

Fragen wie bei seinem ersten Start von 

der Festplatte (dazu gleich mehr). 

War man schnell genug, erscheint jetzt 

ein kleiner Installationsassistent. In seinem 

ersten Menü übernimmt man die 

Voreinstellungen zur Schriftart und Tastatur 

via »Accept these Settings« (Abbildung 

5). Das jetzt angebotene »Quick/ 

Easy Install« macht seinem Namen alle 

Ehre: Man muss lediglich die Sicherheitsabfrage 

bestätigen, dann löscht der Assistent 

ohne Rücksicht auf Verluste die erste 

Festplatte und richtet auf dem gewonnenen 

Platz pfSense ein. Da im Beispiel auf 

dem Rechner nur pfSense laufen soll, 

ist dieser Punkt der Richtige. Eine benutzerdefinierte 

Installation via »Custom 

Install« ist nur dann notwendig, wenn 

man die Festplatte unbedingt manuell 

partionieren und einrichten möchte. 

Kernel-Wahl 

Sobald sich pfSense auf der Platte befindet, 

stellt sich die Frage nach dem zu verwendenden 

Kernel. Auf einem Standard- 

PC ist der erste Punkt »Symmetric multiprocessing 

kernel« bereits die richtige 

Wahl. Der »Embedded kernel« kommt 

auf eingebetteten Systemen zum Einsatz, 

denen ein Bildschirm (respektive eine 

Grafikkarte) und eine Tastatur fehlt. Der 

»Developers Kernel« ist wiederum nur für 

Anwender interessant, die pfSense selbst 

weiterentwickeln wollen. 

Abschließend muss man nur noch einen 

»Reboot« anstoßen, die CD entfernen 

und warten, bis pfSense von der 

Festplatte startet. Von dort meldet sich 

das bekannte Boot-Menü, das man per 

Eingabetaste überspringt. Nach einer 

Weile präsentiert pfSense eine Liste aller 

Netzwerkschnittstellen und erkundigt 

sich, ob man ein VPN einrichten möchte. 

Das ist nur dann notwendig, wenn man 

pfSense (ausschließlich) zwischen beziehungsweise 

mit VPNs einsetzen möchte. 

Da man die VPN-Funktion auch später 

noch bequem über die Weboberfläche 

anknipsen kann, verneint man die Frage 

mit einem »n«. 

Als Nächstes möchte pfSense den Namen 

der WAN-Schnittstelle wissen (Abbildung 

6). Dabei hilft die Liste mit allen 

Abbildung 6: In diesem Fall bildet die erste Karte »em0« die Schnittstelle zum 

WAN respektive Internet. 

Abbildung 7: Dieses Menü dient als Notnagel, wenn die Weboberfläche versagt. 

»14« öffnet beispielsweise den SSH-Zugang. 


pfSense 

Security 

Netzwerkschnittstellen. Ist man unsicher, 

kann man pfSense die passende Schnittstelle 

auch selbst ermitteln lassen. Dazu 

zieht man zunächst alle Kabel vom Rechner 

ab, tippt ein »a« ein, stöpselt nur die 

Strippe zum WAN wieder ein, drückt die 

Eingabetaste und hofft, dass pfSense die 

Schnittstelle automatisch erkennt. 

Netzwerknamen 

Im nächsten Schritt wird nach dem gleichen 

Prinzip der Name der Netzwerkschnittstelle 

zum LAN eingegeben. Existieren 

mehrere Schnittstellen, wiederholt 

man das Spielchen entsprechend oft. 

Auch hier bietet pfSense jeweils per »a« 

eine automatische Erkennung an. Sind 

alle Karten angemeldet, drückt man bei 

der Frage nach einer neuen LAN-Karte 

die Eingabetaste. pfSense listet jetzt noch 

einmal alle Zuweisungen auf. Stimmen 

sie, geht es mit »y« weiter. Doch Vorsicht: 

Es gilt die englische Tastaturbelegung. 

Wer auf einer deutschen Tastatur nicht 

»z« drückt, muss den gesamten Fragenkatalog 

noch einmal durchlaufen. Sobald 

das Menü aus Abbildung 7 erscheint, ist 

die Installation erfolgreich abgeschlossen, 

pfSense arbeitet jetzt ähnlich wie eine 

Fritzbox. Aktiv sind bereits DHCP-Server, 

Informationstheorie 

pfSense protokolliert seine Aktionen in mehreren 

Logs, die sich hinter »Status | System Logs« 

einsehen lassen. Auf dem »Firewall«-Register 

kann man sogar mit einem Klick auf eines der 

Symbole schnell eine neue Ausnahmeregel erzeugen. 

Die derzeit von der Firewall beobachteten 

Verbindungen zeigt ein eigener Bildschirm 

unter »Diagnostics | States« an. 

Ergänzend erhebt pfSense weitere statistische 

Daten wie die Anzahl der inspizierten Pakete. 

Sie landen in einer Round-Robin-Datenbank 

(RRD), aus der ältere Informationen herausfliegen, 

wenn neue hinzukommen. Auf Basis dieser 

Daten generiert pfSense ein paar interessante 

Statistiken und Diagramme. Einige findet man 

auf dem Dashboard, den Rest im Menü »Status 

| RRD Graphs«. Hier erfährt man nicht nur, wieviel 

»Traffic« und Pakete in den letzten Stunden 

und Tagen über die einzelnen Netzwerkschnittstellen 

gelaufen sind (wie in Abbildung 11), sondern 

auch, wie es um die Verbindungsqualität 

zum WAN steht (Register »Quality«). 

Welche Dienste laufen, verrät schließlich noch 

der Menüpunkt »Status | Services«. Dort lassen 

sie sich auch anhalten und wieder starten. 

NAT und Firewall. 

In der Regel sind 

aber noch ein paar 

Nacharbeiten in 

der Weboberfläche 

nötig. 

Erste 

Schritte 

Im Auslieferungszustand 

verteilt 

der eingebaute 

DHCP-Server an 

alle über die erste 

LAN-Schnittstelle 

angeschlossenen 

Rechner 

eine IP-Adresse aus dem Bereich von 

»192.168.1.100« bis »192.168.1.199«. 

Von dort steuert man jetzt mit einem 

Browser die Adresse »192.168.1.1« an, 

über die sich die Weboberfläche von pf- 

Sense erreichen lässt. Das angemahnte, 

von pfSense selbst ausgestellte Zertifikat 

akzeptiert man als Ausnahme. Zutritt zur 

Weboberfläche erhält man mit dem Benutzernamen 

»admin« und dem Passwort 

»pfsense«. Das Duo gehört dem allmächtigen 

Administrator, der an allen Schrauben 

drehen darf. Man sollte deshalb im 

Abbildung 8: Hat die Installation geklappt, erlangt der Administrator über diese 

Seite Zutritt zur Steuerzentrale von pfSense. 

ersten Schritt das Passwort ändern. Dazu 

ruft man den Menüpunkt »System | User 

Manager« zu Hilfe, klickt auf das »e«- 

Symbol rechts in der Zeile »admin« und 

vergibt unter »Password« ein neues (Abbildung 

9). Änderungen sind in pfSense 

grundsätzlich immer explizit über »Save« 

am unteren Seitenrand zu speichern. 

Mit einem Klick auf das pfSense-Logo 

in der linken oberen Ecke gelangt man 

wieder zurück zur Einstiegsseite, dem so 

genannten Dashboard. Es liefert einen 

ersten Überblick über das System und 

Abbildung 11: pfSense protokolliert eine Menge Daten und bereitet für den Administrator daraus Statistiken 

und Diagramme auf: Hier hat ein Client mit Ubuntu Linux eine Menge Updates geladen, anschließend 

erfolgten nur noch ein paar kleinere Seitenabrufe. 


Admin 


89

Security 

pfSense 

Abbildung 9: Im »User Manager« sollte man als Erstes das eigene Passwort tauschen. 

Wie ein Blick auf »Firewall | Rules« verrät, 

blockt die Firewall standardmäßig alle 

vom »WAN« eingehenden Pakete. Analog 

dürfen alle PCs im »LAN« Verbindungen 

nach außen aufbauen. Eine neue Regel 

legt man über das kleine Plussymbol 

rechts oben an. Es öffnet sich dann ein 

Formular, in dem man sich die Bedingung 

zusammenklickt (Abbildung 13). 

Dabei lauern allerdings zwei Stolperfallen: 

Aufgrund der nicht änderbaren 

»Anti-Lockout Rule« dürfen alle Rechner 

aus dem LAN immer auf den pfSense- 

Rechner zugreifen. Selbst mit der Reseine 

derzeitige Auslastung (Abbildung 

10). Weitere Informationen lassen sich 

in Form von Widgets hinzufügen, man 

muss nur auf das kleine Plussymbol unterhalb 

von »Status« klicken und sich 

eine neue Informationsquelle aussuchen. 

Nützlich sind beispielsweise die »Traffic 

Graphs«, die den geflossenen Datenverkehr 

grafisch darstellen. 

Standardmäßig holt pfSense für die WAN- 

Schnittstelle per DCHP-Client eine IP-Adresse. 

Gemäß RFC 1918 weist es dabei 

IP-Adressen aus den für private LANs 

reservierten Bereichen 10/8, 172.16/12 

und 192.168/16 ab. In einigen Fällen, 

wie etwa beim Zugang über UMTS, vergeben 

die Provider jedoch eben genau 

solche IP-Adressen. Damit pfSense diese 

akzeptiert, muss man unter »Interfaces | 

WAN« ganz unten den Haken vor »Block 

private networks« entfernen. Ein Haken 

bei »Block bogon networks« schließt übrigens 

von der IANA nicht zugewiesene 

Adressen aus, wie etwa »0.0.0/8«. Beide 

Funktionen erhöhen die Sicherheit, weshalb 

man sie nur aus gutem Grund deaktivieren 

sollte. 

Soll pfSense eine Internet-Verbindung 

über ADSL herstellen, muss man der 

WAN-Schnittstelle das PPPoE-Protokoll 

beibringen. Dazu setzt man einfach 

»Type« auf »PPPoE« und trägt dann in die 

Felder unter »PPPoE configuration« noch 

die Zugangsdaten ein. Viele ADSL-Provider 

trennen bei einer Flatrate die Verbindung 

automatisch nach 24 Stunden. 

Diese Zwangstrennung kann pfSense auf 

eine bestimmte Uhrzeit verlegen. Dazu 

stellt man unter »Periodic Reset« die Ausklappliste 

auf »Custom« und gibt dann 

über die beiden Felder die Zeit vor (Abbildung 

12). 

Alle angeschlossenen PCs im LAN erhalten 

automatisch eine IP-Adresse vom 

eingebauten DHCP-Server. Möchte man 

den einzelnen PCs die Adressen aus 

einem bestimmten Bereich zuweisen, 

wählt man zunächst im Menü »Services 

| DHCP-Server« und stellt dann den 

entsprechenden Adressbereich unter 

»Range« ein. Am unteren Rand der Seite 

findet sich noch eine (standardmäßig 

leere) Tabelle. Über sie kann man für 

einzelne PCs eine IP-Adresse vorgeben. 

Um solch eine Regel anzulegen, klickt 

man auf das kleine Plus-Symbol, trägt die 

MAC-Adresse des Geräts, die gewünschte 

IP-Adresse und den Hostnamen ein. 

Der Regulator 

Abbildung 10: Das Dashboard liefert zahlreiche Informationen über den aktuellen Zustand des Systems. Die 

einzelnen Widgets lassen sich im Dashboard bequem per Drag-and-Drop umsortieren. 


pfSense 

Security 

riert pfSense. Verschieben lässt sich eine 

Regel, indem man sie mit einem Mausklick 

markiert und dann am rechten Rand 

der Tabelle das Pfeilsymbol neben der 

neuen Position aktiviert. Stimmt die Reihenfolge, 

eine blockierende Regel greift 

aber dennoch nicht, sollte man hinter 

»Diagnostics | States» auf dem Register 

»Reset states« einmal alle aktuellen Zustände 

zurücksetzen. Wenn der Browser 

nach einem Klick auf »Reset« endlos lädt, 

muss man einmal kurz selbst die Seite 

neu laden. 

Personalabteilung 

Abbildung 12: Die Zwangstrennung durch den Provider erfolgt um 4:30 Uhr morgens, also dann, wenn noch 

niemand im Büro ist. 

Advanced« mit einem Haken bei »Antilockout« 

abschalten. Allerdings läuft man 

dann auch Gefahr, sich durch eine unachtsame 

Regel selbst auszusperren. 

Des Weiteren arbeitet die Firewall alle 

Regeln von oben nach unten ab. Die erste 

zutreffende Regel gilt, alle anderen ignogel 

aus Abbildung 13 könnte sich der 

Benutzer des PCs mit der IP-Adresse 

»192.168.1.66« weiterhin per SSH auf 

dem pfSense-Rechner anmelden (vorausgesetzt, 

dort ist der SSH-Zugang aktiviert). 

Um das zu unterbinden, kann man 

die Anti-Lockout-Regel unter »System | 

Abbildung 13: Diese Einstellungen verwehren beispielsweise dem Rechner mit der IP-Adresse 192.168.1.66 den 

Zugriff auf den TCP-Port 22, also den SSH-Dienst. 

Bevor die Benutzer des LANs ins Internet 

gehen, müssen sie sich auf einer speziellen 

Seite mit einem Benutzernamen und 

einem Passwort authentifizieren. Damit 

das klappt, sind diese beiden Informationen 

erst einmal in pfSense zu hinterlegen. 

Der Einfachheit halber soll das 

in unserem Beispiel über die in pfSense 

eingebaute Benutzerverwaltung erfolgen, 

die unter »System | User Manager« zu finden 

ist. In diesem Fall fügt man im User- 

Manager für jeden Benutzer über das 

Plus-Symbol ein neues Benutzerkonto 

hinzu. Im Formular muss man lediglich 

einen Benutzernamen und ein Passwort 

eintragen (Abbildung 14). Beim praktischen 

Einsatz in einem Firmennetz bietet 

sich statt des eingebauten User-Managers 

die Authentifizierung per RADIUS an. 

Die Seite für die eigentliche Anmeldung 

stellt das Captive Portal bereit. Um es 

einzuschalten, setzt man hinter »Services 

| Captive Portal« ein Häkchen vor »Enable 

captive portal«. Die Anmeldeseite soll 

erscheinen, wenn ein Benutzer aus dem 

LAN ins Internet gehen möchte, folglich 

markiert man noch »LAN« unter »Interfaces«. 

Wenn der Benutzer eine Weile untätig 

ist, meldet pfSense ihn automatisch 

wieder ab. Nach wie vielen Minuten dies 

passieren soll, bestimmt »Idle Timeout«. 

Bei einem leeren Feld gibt es kein Zeitlimit. 

Etwas strenger ist »Hard Timeout«: 

Nach den dort eingetragenen Minuten 

setzt pfSense den Benutzer gnadenlos 

vor die Tür – egal, ob er untätig war 

oder nicht. 

Nach erfolgreicher Anmeldung leitet pf- 

Sense den Benutzer automatisch zur URL 

weiter, die unter »After authentication 

Redirection URL« vorgegeben ist. Die Be- 


Admin 


91

Security 

pfSense 

Er fragt alle wichtigen Informationen ab, 

darunter etwa den Rechnernamen, der 

ansonsten einfach »pfsense.localdomain« 

lautet. 

Fazit 

Abbildung 14: Unter »Expiration Date« kann man ein Datum einstellen, an dem pfSense das Benutzerkonto 

automatisch deaktiviert. 

nutzernamen und Passwörter liegen im 

Beispiel in der pfSense-eigenen Benutzerverwaltung, 

weshalb man noch »Authentication» 

auf »Local User Manager / 

Vouchers« stellt. Wie der Name bereits 

andeutet, kann man über das Register 

»Vouchers« auch Gutscheine erstellen, 

mit denen dann ein Benutzer für eine 

Weile Zugang zum Internet erhält. Das ist 

beispielsweise in Hotels interessant, wo 

Gäste einen solchen Gutschein erwerben 

können. 

Abbildung 15: Hier muss ein Benutzer des LANs erst seinen Benutzernamen und 

das zugehörige Passwort hinterlassen, um Zugang zum Internet zu erhalten. Das 

Aussehen der Seite lässt sich selbstverständlich anpassen. 

Greift man nach dem Speichern mit 

»Save« von einem Client-PC aus dem 

LAN auf das Internet zu, landet man automatisch 

beim Anmeldebildschirm aus 

Abbildung 15. Erst wenn man hier die 

vorhin in der Benutzerverwaltung hinterlassenen 

Daten eintippt, erhält man 

Zugriff auf das Internet. 

Zum Abschluss noch einmal die Erinnerung: 

In der Weboberfläche sollte man 

vor dem Aufruf eines neuen Menüpunkts 

immer daran denken, alle Änderungen 

zu speichern, weil 

sie sonst verloren 

gehen. In einigen 

Fällen, wie etwa 

bei den Einstellungen 

zum DHCP- 

Server, muss man 

die neuen Einstellungen 

anschließend 

noch einmal 

explizit anwenden. 

Bei einer Einrichtung 

von pfSense 

auf einem produktiven 

System sollte 

man zudem einmal 

den Einrichtungsassistenten 

hinter 

»System | Setup 

Wizard« anwerfen. 

Dieser Artikel konnte nur die grundlegenen 

Features von pfSense vorstellen, der 

Funktionsumfang der Firewall-Distribution 

ist einfach riesig. Leider besteht die 

Dokumentation derzeit nur aus einem 

ziemlich lückenhaften und spärlich bestückten 

Wiki [6]. Dessen Artikel stützen 

sich, ähnlich wie die im Handel erhältlichen 

Bücher, größtenteils noch auf die 

ältere Version 1.2.x. Immerhin lässt sich 

vieles übertragen und wer sich mit den 

Diensten einigermaßen auskennt, sollte 

sich schnell zurechtfinden. Übrigens 

produzieren mittlerweile verschiedene 

Firmen Hardware beziehungsweise Appliances 

mit vorinstalliertem pfSense, 

eine Liste der von den Entwicklern empfohlenen 

Unternehmen findet sich unter 

[7]. (ofr/cth) n 

Infos 

[1] pfSense: [http:// www. pfsense. org] 

[2] pf und Scrubbing: 

[http:// docstore. mik. ua/ manuals/ openbsd/ 

faq/ pf/ scrub. html] 

[3] Common Address Redundancy 

Protocol (CARP): 

[http:// de. wikipedia. org/ wiki/ Common_ 

Address_Redundancy_Protocol] 

[4] Captive Portal: [http:// de. wikipedia. org/ 

wiki/ Captive_Portal] 

[5] Hardwareanforderungen von pfSense: 

[http:// www. pfsense. org/ index. php? 

option=com_content& task=view& id=52& 

Itemid=49] 

[6] pfSense-Wiki: [http:// doc. pfsense. org/ 

index. php/ Main_Page] 

[7] pfSense Appliances: 

[http:// www. pfsense. org/ index. php? 

option=com_content& task=view& id=44& 

Itemid=50] 

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. 


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... EinEn ClASSMATE PC 

ConVErTiblE TouChSCrEEn iM wErT Von 399 Euro! 

Einsendeschluss ist der 15.03.2012 

zur Verfügung gestellt von 

www.1edu.de

Security 

Apachebench 

© Andrii IURLOV, 123RF 

Das Apache-Benchmark-Tool legt Server lahm 

Abwehrverhalten 

Das verbreitete Benchmarking-Tool Apachebench kann effiziente Denial-of-Server-Attacken starten, wenn man 

sich nicht dagegen schützt. Chris Binnie 

Sie haben also viel Sorgfalt auf die Auswahl 

der neuen Hardware für den Webserver 

verwendet. Und Sie haben sich alle 

Mühe gegeben, die Datenbank zu tunen 

und zusammen mit Ihren Kollegen einige 

Wochen damit verbracht, eine brandneue, 

topaktuelle Website, basierend auf 

den leistungsfähigsten Technologien an 

den Start zu bringen. Jetzt wollen Sie 

sich zurücklehnen und einfach nur zuschauen, 

wie Tausende von Besuchern 

täglich von Ihrem neuen Webangebot Gebrauch 

machen. Sogar der Chef scheint 

ausnahmsweise einmal zufrieden. 

Doch dann nimmt das Schicksal seinen 

Lauf: Eines schönen Tages startet 

in irgendeinem fremden Land jemand 

mit zu viel Zeit ein völlig legitimes und 

weitverbreitetes Tool und zwingt Ihren 

schönen Server damit in die Knie. 

Dazu braucht er noch nicht einmal eine 

schnelle Internet-Anbindung, er schickt 

einfach nur ein paar Bytes über eine 

kleine DSL-Leitung. 

Listing 1: IPTables-Regeln 

Diese Bedrohung ist sehr real. Selbst eine 

durchdachte, leistungsfähige Infrastruktur 

kann mit einem einfachen Angriff 

lahmgelegt werden. 

Benchmarks 

Das Angriffs-Tool, um das es hier geht, 

ist das für einen guten Zweck entwickelte 

Apache-Benchmarking-Programm »ab« 

(Apachebench) [1]. Wie die Apache-Dokumentation 

es ausdrückt, ist Apachebench 

dafür entworfen worden, sich 

einen Eindruck davon zu verschaffen, 

wie schnell die eigene Apache-Installation 

arbeitet. Insbesondere soll es verraten, 

wie viele Requests pro Sekunde der 

Webserver verarbeiten kann. 

Das klingt sehr unschuldig, verschafft 

aber jedem Tunichtgut die Gelegenheit, 

mit etwas Cut-und-Paste großen Schaden 

anzurichten. Normalerweise ist es auf 

jeder Linux-Distribution verfügbar und 

erfordert außerdem keine Root-Rechte. 

Abbildung 1 zeigt Apachebench beim 

Einsatz, wie es gerade 2500 Anfragen bei 

einer Rate von 300 gleichzeitigen Verbindungen 

verarbeitet – mehr als genug, um 

die meisten Webserver-Installationen auf 

einem einzigen Server in Schwierigkeiten 

zu bringen. 

Jeder, der den Apache-Server näher 

kennt, weiß um die Vielzahl an Konfigurationsoptionen 

und Module, die er 

unterstützt. Zweifellos gehört die Flexibilität, 

mit der sich ein solcher modularer 

Server einrichten lässt, zu den Gründen, 

warum Apache so populär ist. Mit 

Apache bench verhält es sich ähnlich: Es 

besitzt mehr als 20 Schalter, über die der 

Anwender genau bestimmen kann, wie 

es seine Performance-Tests absolviert. 

Die Ergebnisse eines solchen Durchlaufs 

sind in Abbildung 2 zu sehen. 

In der unteren Hälfte ist der Abschnitt 

»Percentage of the requests served within 

a certain time (ms)« zu sehen, dem sich 

entnehmen lässt, ob der Webserver im 

01 iptables ‐A INPUT ‐p tcp ‐m multiport ‐‐dport 80,443 ‐m state ‐‐state NEW ‐m limit ‐‐limit 100/minute ‐‐limit‐burst 300 ‐j ACCEPT 

02 iptables ‐A INPUT ‐p tcp ‐m multiport ‐‐dport 80,443 ‐m state ‐‐state NEW ‐m limit ‐‐limit 100/minute ‐‐limit‐burst 300 ‐j LOG ‐‐log‐level info 

‐‐log‐prefix NEW‐CONNECTION‐DROP: 

03 iptables ‐A INPUT ‐p tcp ‐m multiport ‐‐dport 80,443 ‐m state ‐‐state RELATED,ESTABLISHED ‐m limit ‐‐limit 100/second ‐‐limit‐burst 100 ‐j ACCEPT 

04 iptables ‐A INPUT ‐p tcp ‐m multiport ‐‐dport 80,443 ‐m state ‐‐state RELATED,ESTABLISHED ‐m limit ‐‐limit 100/second ‐‐limit‐burst 100 ‐j LOG 

‐‐log‐level info ‐‐log‐prefix ESTABLISHED‐CONNECTION‐DROP: 

05 iptables ‐A INPUT ‐p tcp ‐m multiport ‐‐dport 80,443 ‐j DROP 


Apachebench 

Security 

G Abbildung 1: Apachebench auf der Kommandozeile. 

E Abbildung 2: Ergebnisse eines Apachebench-Durchlaufs. 

Lauf der Testzeit langsamer wird. Die 

Tabelle zeigt die Länge der Requests in 

Millisekunden und welcher Anteil an 

Gesamt-Requests in diesem Intervall abgearbeitet 

wurde. 

Gegenmaßnahme 

Statt Zehntausende von Euro in eine Lösung 

zu investieren, die Sicherheit gegen 

Denial-of-Service-Angriffe verschafft, 

können Sie auch eine selbst gestrickte 

Lösung versuchen, die in den meisten 

Fällen ausreichend ist. Sie erfordert nur 

einen Linux-Rechner, auf der die altbekannte 

Firewall-Software IPTables läuft. 

Mit etwas grundlegenden IPTables-Kenntnissen 

lässt sich der Regelsatz in Listing 1 

leicht entziffern. Neben dem Standard- 

Modul »ip_tables« sind zusätzlich die 

Kernel-Module »state« und »multiport« 

nötig, die beispielsweise unter Ubuntu 

unter den Namen »xt_multiport« und 

»xt_state« zur Verfügung stehen. Alternativ 

zum hier vorgestellten Weg gibt es 

ähnliche Ansätze, die auf dem IPTables- 

Modul »recent« basieren. 

Die Befehle in Listing 1 berücksichtigen 

Flooding-Angriffe gleichermaßen auf Port 

80 (HTTP) wie Port 443 (HTTPS) und 

neue wie bereits aufgebaute Verbindungen. 

Dieser Ansatz bremst einen Angriff 

recht effektiv aus. Eine einfachere Lösung 

könnte sich ausschließlich auf neue 

Verbindungen konzentrieren, wäre aber 

eher für Syn-Flodding-Attacken geeignet. 

In unserem Fall funktioniert das nicht, 

weil der Apache-Server in der Standard- 

Konfiguration per Keep-Alive Verbindungen 

geöffnet lässt, um darüber mehrere 

Anfragen zu verarbeiten. Also muss man 

auch bereits geöffnete Verbindungen berücksichtigen. 

Beim Testen kann man einen Einblick 

in das Verhältnis neuer zu bereits geöffneten 

Verbindungen und den damit verbundenen 

Traffic-Beschränkungen durch 

die Firewall-Regeln gewinnen, wenn man 

das Syslog im Auge 

behält. Grundsätzlich 

ist der Sinn 

dieser Regeln, 

Angreifer auszubremsen, 

die ein 

bestimmtes Muster 

verfolgen, aber 

regulären Website- 

Besuchern weiterhin die Nutzung der Site 

zu erlauben. Im Test hat das gut funktioniert, 

auch wenn der Server letztlich 

etwas langsamer wurde. 

In der ersten Zeile von Listing 1 findet 

sich die Option »‐‐limit 100/minute«, die 

festlegt, dass die Firewall alle Pakete eines 

Rechners verwirft, der auf den Ports 

80 und 443 Anfragen mit mehr als 100 

Paketen pro Minute stellt. Die Option 

»‐‐limit‐burst« ist etwas schwieriger zu 

verstehen. Im Prinzip sind erst einmal 

300 Pakete erlaubt, bevor das eben beschriebene 

Limit von 100 Paketen/min 

zum Tragen kommt. Die Idee dahinter ist, 

dass bei legitimer Nutzung der Website, 

sich zu Beginn ein höheres Datenaufkommen 

ergibt. 

Bei Experimenten mit den Werten für die 

beiden Limits zeigte sich, dass man recht 

leicht viel zu viel Traffic ausschließt. 

Auch die im Beispiel von Listing 1 abgedruckten 

Werte können für Ihre Webserver-Konfiguration 

noch zu restriktiv sein. 

Sie sollten also damit experimentieren 

und sie gegebenenfalls erhöhen. 

Denial of Service 

Ein anderer verbreiteter Angriff lässt sich 

mit den hier beschriebenen Firewall- 

Regeln nicht verhindern. Ähnlich wie 

der Angriff mit Apachebench, kann ein 

Angreifer auch mit dem Tool Slowloris 

[2] mit minimalen Mitteln einen Webserver 

lahmlegen. Interessant dabei ist, 

dass Slowloris nicht die üblichen Methoden 

einer Denial-of-Service-Attacke 

verwendet und möglichst viele Ressour- 

cen verbraucht. Es setzt vielmehr auf 

wenige, langsame Verbindungen, um den 

Apache-Server lahmzulegen. Mehr über 

Slowloris und passende Gegenmaßnahmen 

verrät ein frei verfügbarer Artikel in 

ADMIN 04/2010 [3]. (ofr) 

n 

Infos 

[1] Apache HTTP server benchmarking tool: 

[http:// httpd. apache. org/ docs/ 2. 0/ 

programs/ ab. html] 

[2] Ha.ckers.org website: 

[http:// ha. ckers. org/ slowloris] 

[3] Kurt Seifried, Die Entdeckung der Langsamkeit, 

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

Das‐Heft/ 2010/ 04/ Apache‐gegen‐Denialof‐Service‐Attacken‐wappnen] 

OpenSource Training Ralf Spenneberg 

Schulungen direkt vom Autor 

Linux Netzwerk Administration / LPIC2 

5 Tage 30.01. 03.02.2012 

IPv6 mit Linux 

3 Tage 06.02. 08.02.2012 

Virtualisierung mit XEN 

3 Tage 13.02. 15.02.2012 

Apache 2.x Webserver Administration 

4 Tage 21.02. 24.02.2012 

Virtualisierung mit KVM 

3 Tage 22.02. 24.02.2012 

Sichere Mailserver Lösungen mit Postfix 

5 Tage 05.03. 09.03.2012 

Snort IDS/IPS Technology 

4 Tage 06.03. 09.03.2012 

Firewall Lösungen mit Linux 

5 Tage 12.03. 16.03.2012 

Advanced Monitoring 

4 Tage 19.03. 22.03.2012 

Freie Distributionswahl: 

Opensuse, Fedora, Debian Squeeze, 

CentOS oder Ubuntu LTS 

Ergonomische Arbeitsplätze 

Umfangreiche Schulungsunterlagen mit 

Übungen 

Am Bahnhof 35 

48565 Steinfurt 

Tel.: 02552 638755 

Fax: 02552 638757 

Weitere Informationen unter www.ost.de 


Admin 


95

Know-how 

Eigene OCF-Agenten 

© Kirill Kurashov, 123RF 

HA-Serie, Teil 8: OCF-Agenten selbst programmieren 

Agentenausbildung 

Wer die Fähigkeiten von Pacemaker und besonders die Monitoring-Funktion bestmöglich ausnutzen möchte, 

setzt auf Resource Agents nach OCF-Standard. Gibt es für ein bestimmtes Programm noch keinen, heißt es Hand 

anlegen. von Martin Loschwitz 

In den bisherigen Artikeln der HA-Serie 

spielten die Resource Agents eine eher 

untergeordnete Rolle, sie waren im Wesentlichen 

Erfüllungsgehilfen. Die unscheinbare 

Schicht der Agents im Cluster- 

Stack ist in Wirklichkeit aber von großer 

Bedeutung für die Funktionalität des 

gesamten Clusters. Denn nur wenn die 

Resource Agents gut funktionieren, kann 

der Cluster seine Aufgabe perfekt wahrnehmen. 

Deshalb sind qualitativ hochwertige 

Resource Agents wichtig. Wenn 

für ein bestimmtes Programm ein guter 

Agent fehlt, dann kann es sich für den 

Admin des Clusters durchaus lohnen, 

selbst einen OCF-kompatiblen Agent aus 

der Taufe zu heben. Das erspart ihm in 

Zukunft wahrscheinlich viel Ärger, denn 

nicht standardkonforme Init-Skripte, 

die sich in Pacemaker ja als LSB-Klasse 

verwenden lassen, bringen den Cluster 

schnell aus dem Tritt. 

Wer schon mal in der Nacht einen Samba- 

Cluster repariert hat, weil das Samba-Init- 

Skript, das Debian liefert, das »monitor«- 

Target nicht ordentlich unterstützt, kann 

hiervon ein Lied singen. 

Wo Resource Agents 

ansetzen 

Der Linux-Cluster-Stack besteht aus 

mehreren Komponenten – Corosync oder 

Heartbeat übernehmen die Cluster-Kommunikation, 

Pacemaker kümmert sich 

um die Cluster-Dienste (im Fachjargon 

„Ressourcen“) und die Storage-Komponente 

ist in der Mehrzahl der Fälle DRBD. 

Die Ressourcen-Schicht, also Pacemaker, 

besteht intern aus mehreren einzelnen 

Teilen, die ineinandergreifen, um den 

Cluster bestmöglich zu steuern (Abbildung 

1). Pacemaker selbst ist der »crmd«, 

der clusterweite Resource Manager, der 

sicherstellt, dass insgesamt alle konfigurierten 

Dienste wie gewünscht gestartet 

sind. Er läuft auf jedem System, genauso 

wie der » lrmd«, der »Local Resource Management 

Daemon«. Der »lrmd« kommt 

aus dem »cluster‐glue«-Paket, dessen Installation 

Voraussetzung für Pacemaker 

ist. Er nimmt Befehle von »crmd« entgegen 

und setzt sie adäquat um. Auch 

der »lrmd« startet selbst allerdings keine 

Programme – an dieser Stelle kommen 

die Resource Agents ins Spiel, denn diese 

ruft der »lrmd« auf, wenn ein Dienst auf 

Abbildung 1: Deutlich zu erkennen sind die Prozesse »crmd« und »lrmd«, die ineinandergreifen, um 

Ressourcen zu starten und zu stoppen. 



Know-how 

einem Cluster-Knoten in Bewegung zu 

setzen ist. 

Resource Agents kommen üblicherweise 

aus drei verschiedenen Kategorien oder 

Klassen: LSB Agents sind Init-Skripte und 

liegen im Ordner »/etc/init.d«. Heartbeat 

Agents sind für den nunmehr veralteten 

Heartbeat 1 gedacht und gelten als deprecated. 

Die dritte und höchste Klasse 

sind die OCF Resource Agents. Sie folgen 

dem »Open Cluster Framework«-Standard, 

der spezifisch erfunden wurde, um 

qualitativ besonders hochwertige Agents 

zu ermöglichen. Wer in der Cluster-Welt 

etwas auf sich hält, verwendet diese 

Agent-Klasse bevorzugt. 

Die Vorteile von OCF 

Welche Vorteile bietet der OCF-Standard 

genau? Zunächst haben Admins dank der 

OCF-Spezifikation die Möglichkeit, Konfigurationsparameter 

einer Ressource direkt 

in der CRM-Konfiguration von Pacemaker 

festzulegen. Pacemaker gibt die 

Parameter unverändert an den Resource 

Agent weiter, der die Informationen dann 

in Befehle umsetzt. Ein klassisches Beispiel 

ist der Resource Agent, der sich 

um Cluster-IP-Adressen kümmert, also 

»ocf:heartbeat:IPaddr2«. Er bekommt per 

CRM-Konfiguration stets den Parameter 

»ip« mit auf den Weg und weiß so, welche 

IP die Cluster-IP ist. Ähnlich funktioniert 

der Filesystem-Agent, der aus der 

CRM-Konfiguration sämtliche Informationen 

bezieht, die er braucht, um ein Dateisystem 

zu mounten. Konfigurationsparameter 

funktionieren nur bei OCF-Agents, 

LSB-Skripte und Heartbeat Agents unterstützen 

das Feature nicht. Bei ihnen lassen 

sich zwar auch Parameter-Zeilen in 

der CRM-Shell eintragen, diese ignoriert 

Pacemaker aber vollständig. 

Der zweite große Vorteil der OCF-Agents 

besteht darin, dass sie unabhängig von 

der Distribution funktionieren, auf der 

sie eingesetzt werden. Dadurch ist es 

problemlos möglich, eine Cluster-Konfiguration 

ohne Änderung von einem 

Debian-System auf ein SLES-System 

zu übernehmen. Man kann sogar den 

Resource Agent als File auf den anderen 

Rechner kopieren und dort laufen lassen 

– wenn er dem OCF-Standard folgt, wird 

er hüben wie drüben klaglos funktionieren. 

Die Interoperabilität erstreckt sich 

über alle Details, die zu beachten sind. 

Auch sollten RA-Autoren sich im Klaren 

darüber sein, welche Parameter ihr Resource 

Agent unterstützen soll. Das hängt 

freilich davon ab, welche Optionen die 

Software selbst bietet 

Um diesen Artikel nicht zum reinen Trockenschwimmen 

werden zu lassen, demonstriert 

der Text im Folgenden den 

Eigenbau eines OCF Resource Agent für 

»asterisk«, den der Autor vor einigen Wochen 

in Zusammenarbeit mit mehreren 

anderen Entwicklern veröffentlicht hat. 

Asterisk eignet sich auf der einen Seite 

sehr gut, um die grundsätzliche Implementierung 

eines OCF-RAs zu diskutieren, 

andererseits lassen sich am Beispiel 

Asterisk aber auch sehr gut Ausnahmen 

demonstrieren, die applikationsspezifisch 

sind. In der einen oder anderen Art wird 

fast jede Applikation spezifische Eigenheiten 

aufweisen, die sich auch im OCF- 

RA wiederfinden. 

Anhaltspunkte dafür, welche Optionen 

die Aufnahme in den RA wert sind, geben 

beispielsweise die »default«-Files 

in Debian, die üblicherweise in »/etc/ 

default/« liegen (Abbildung 2) und nach 

dem Programm benannt sind, für das 

sie sinnvolle Standardeinstellungen enthalten. 

Im Beispiel von Asterisk findet 

sich hier zum Beispiel die Festlegung, als 

welcher Benutzer und mit welchen Rechten 

Asterisk laufen soll oder wie viele 

Files Asterisk gleichzeitig öffnen darf. 

Debian verwertet diese Einstellungen im 

Asterisk-Init-Skript, und auch im OCFübrigens 

auch auf Nicht-Linux-Systeme: 

Theoretisch soll der Cluster-Stack auch auf 

den üblichen BSD-Derivaten funktionieren. 

Allerdings dürfte das bisher nur sehr 

rudimentär in der Praxis getestet worden 

sein. Prinzipiell gilt aber, dass ein Agent 

überall dort funktioniert, wo der Cluster- 

Stack ebenfalls funktioniert.Nicht zuletzt 

trifft der OCF-Standard auch detaillierte 

Aussagen darüber, welchen Rückgabewert 

ein Agent in Abhängigkeit bestimmter Ereignisse 

an den »lrmd« zu liefern hat. Auf 

diese Weise bekommt der Cluster-Admin 

schnell einen Überblick über Missstände, 

falls im Cluster etwas schiefläuft. 

Die Gründe, auf OCF zu setzen, sind also 

vielseitig. Umso ärgerlicher ist es, wenn 

für eine bestimmte Applikation kein OCF- 

Agent vorhanden ist. Ein Grund zum 

Verzweifeln ist das aber nicht, denn mit 

den dazugehörigen Dokumenten und ein 

bisschen Bastelei lässt sich ein qualitativ 

hochwertiger Resource Agent nach OCF- 

Standard selbst herstellen. 

Zur Vorbereitung 

Bevor die erste Code-Zeile geschrieben 

ist, tun RA-Autoren gut daran, ein paar 

Details abzuklären. Stets griffbereit sollte 

einerseits der OCF-Standard sein, der im 

Netz unter [1] zu finden ist. Nützlich ist 

im Zusammenhang damit auch der »OCF 

Resource Agent Developer's Guide« in 

der aktuellen Version 1.0.2 [2], der aus 

der Feder von Florian Haas stammt. Er 

bietet in kürzester Zeit einen Überblick 

Abbildung 2: Auf Debian-Systemen geben die Default-Files Auskunft darüber, welche Parameter ein Resource 

Agent sinnvollerweise unterstützt. 


Admin 


97

Know-how 


Agent lassen sie sich als Parameter implementieren. 

Ein anderer Anhaltspunkt für 

Parameter ist üblicherweise der Aufruf 

eines Programms mit »‐‐help«. Aus der 

Liste der Parameter, die das Binary selbst 

unterstützt, gewinnen Autoren von OCF- 

Agents einen Überblick über die unterstützten 

Konfigurationswerte. 

Im Beispiel ergeben sich die folgenden 

Parameter, die der Resource Agent für 

Asterisk unterstützen soll: 

n »binary« legt fest, wo das eigentliche 

Asterisk-Binary liegt. 

n »canary_binary« bestimmt den Ort des 

»astcanary «-Binaries und 

n »config« die Stelle, an der »asterisk. 

conf« liegt. 

n »user« und »group« wirken wie oben 

beschrieben. 

n »additional_parameters« ermöglicht 

es, weitere Parameter händisch festzulegen, 

mit denen das Asterisk-Binary 

aufgerufen werden soll. 

n »realtime« regelt, ob Asterisk im Realtime-Modus 

laufen soll oder nicht. 

n »maxfiles« beschränkt die Telefonanlage 

hinsichtlich der Files, die 

diese gleichzeitig maximal geöffnet 

haben darf. 

Der Header des Resource 

Agents 

Damit kann es losgehen: Die erste Zeile 

des OCF Resource Agents ist dieselbe wie 

bei allen anderen Shellskripten auch – 

das Shebang. Es folgt eine allgemeine Beschreibung 

des Resource Agents und ein 

Copyright-Vermerk, danach sollte auch 

eine Liste der Parameter vorhanden sein, 

die dieser RA unterstützt, damit sie auf 

einen Blick ersichtlich sind. Der Header 

folgt dabei keiner spezifischen Syntax, 

für den Asterisk Agent könnte er also so 

aussehen wie in Listing 1. 

Im nächsten Schritt folgt die Initialisierung 

aller OCF-spezifischen Funktionen. 

Das geht so: 

: ${OCF_FUNCTIONS_DIR=${OCF_ROOT}/libU 

/heartbeat} 

. ${OCF_FUNCTIONS_DIR}/ocf‐shellfuncs 

Die Variable »OCF_ROOT«, auf die an 

dieser Stelle verwiesen ist, ist in der Pacemaker-Umgebung, 

in der das Skript später 

läuft, bereits gesetzt. Ab sofort stehen 

dem Agent sämtliche OCF-Funktionen 

zur Verfügung. 

Default-Werte für 

Konfigurationsparameter 

Jeden Parameter, der in einem OCF Resource 

Agent festzulegen ist, kann das 

Script selbst anschließend mit dem Präfix 

»OCF_RESKEY_« abrufen. Im Header 

des Agents findet sich darauf bereits ein 

Hinweis – um den Inhalt des Parameters 

»binary« abzurufen, genügt der Verweis 

auf die Variable »OCF_RESKEY_binary«. 

Ein guter Resource Agent setzt für die 

vorgegebenen Parameter Default-Werte, 

wo dies sinnvoll ist. Der zweite Teil 

des Agents sieht daher so aus, wie in 

Listing 2. 

Der auf den ersten Blick etwas umständliche 

Weg, zunächst eine Variable mit 

dem Namen »OCF_RESKEY_name_ 

default« zu definieren, ist wohlüberlegt: 

Auf diese Weise findet sich in der 

Variable nämlich stets der vorgegebene 

Listing 1: Der Header des Resource Agents 

01 #!/bin/sh 

02 # 

03 # 

04 # Asterisk 

05 # 

06 # Description: Manages an Asterisk PBX as an HA resource 

07 # 

08 # Authors: Martin Gerhard Loschwitz 

09 # Florian Haas 

10 # 

11 # Support: linux‐ha@lists.linux‐ha.org 

12 # License: GNU General Public License (GPL) 

13 # 

14 # (c) 2011 hastexo Professional Services GmbH 

15 # 

16 # This resource agent is losely derived from the MySQL resource 

17 # agent, which itself is made available to the public under the 

18 # following copyright: 

19 # 

20 # (c) 2002‐2005 International Business Machines, Inc. 

21 # 2005‐2010 Linux‐HA contributors 

22 # 

23 # See usage() function below for more details ... 

24 # 

25 # OCF instance parameters: 

26 # OCF_RESKEY_binary 

27 # OCF_RESKEY_canary_binary 

28 # OCF_RESKEY_config 

29 # OCF_RESKEY_user 

30 # OCF_RESKEY_group 

31 # OCF_RESKEY_additional_parameters 

32 # OCF_RESKEY_realtime 

33 # OCF_RESKEY_maxfiles 

34 # OCF_RESKEY_monitor_sipuri 

35 ####################################################################### 

Listing 2: Default-Werte für Parameter 

01 OCF_RESKEY_user_default="asterisk" 

02 OCF_RESKEY_group_default="asterisk" 

03 OCF_RESKEY_binary_default="asterisk" 

04 OCF_RESKEY_canary_binary_default="astcanary" 

05 OCF_RESKEY_config_default="/etc/asterisk/asterisk.conf" 

06 OCF_RESKEY_additional_parameters_default="‐g ‐vvv" 

07 OCF_RESKEY_realtime_default="false" 

08 OCF_RESKEY_maxfiles_default="8192" 

09 : ${OCF_RESKEY_binary=${OCF_RESKEY_binary_default}} 

10 : ${OCF_RESKEY_canary_binary=${OCF_RESKEY_canary_binary_default}} 

11 : ${OCF_RESKEY_config=${OCF_RESKEY_config_default}} 

12 : ${OCF_RESKEY_user=${OCF_RESKEY_user_default}} 

13 : ${OCF_RESKEY_group=${OCF_RESKEY_group_default}} 

14 : ${OCF_RESKEY_additional_parameters=${OCF_RESKEY_additional_parameters_ 

default}} 

15 : ${OCF_RESKEY_realtime=${OCF_RESKEY_realtime_default}} 

16 : ${OCF_RESKEY_maxfiles=${OCF_RESKEY_maxfiles_default}} 



Know-how 

Standard-Wert, sodass er später in den 

RA-Metadaten wiederverwendbar ist. 

Wenn an dieser Stelle gleich die eigentliche 

Variable auf einen bestimmten Wert 

festgelegt würde, so ginge der Standard- 

Wert verloren, sobald ein Admin einen 

Wert vorgibt. 

Die Usage-Funktion 

Die Usage-Funktion gibt Auskunft darüber, 

welche Parameter der Agent 

denn beim Aufruf unterstützt. Sie ist im 

OCF-Standard als »Optional« erwähnt, 

gehört aber zum guten Ton. Listing 3 

zeigt eine Usage-Funktion, wie der hier 

geschaffene Asterisk OCF-Agent sie verwenden 

könnte. Wichtig ist, dass auch 

wirklich nur die Targets Erwähnung finden, 

die der Agent unterstützt. Also mindestens 

»start«, »stop«, »monitor« und 

»meta‐data«. 

Die Meta-Daten des 

Resource Agents 

An dieser Stelle wird es zum ersten Mal 

wirklich haarig: Der Resource Agent muss 

das Target »meta‐data« unterstützen – die 

Ausgabe des Targets nutzt Pacemaker, um 

herauszufinden, welche Parameter der 

Resource Agent unterstützt und welche 

Operationen er ermöglicht (Abbildung 

3). Letztlich tut der Meta-Data-Befehl 

kaum etwas anderes als die »usage«- 

Funktion, nämlich Text ausgeben. Allerdings 

kommt es bei »meta‐data« darauf 

an, dass der ausgegebene Text einer Syntax 

auf XML-Basis entspricht (Abbildung 

3). Eingeleitet wird die Ausgabe von diesen 

Zeilen: 

 

 

 

1.0 

Dann folgt eine Beschreibung des Resource 

Agents, eingerahmt vom XML- 

Tag »« und eine 

Kurzbeschreibung, die von »« umrahmt ist – beide Tags 

sind freilich am Ende wieder mittels »« oder »« zu 

schließen. »« leitet den 

Abschnitt ein, in dem für jeden einzelnen 

Parameter Name und Typ sowie eine 

Lang- und eine Kurzbeschreibung fest- 

Abbildung 3: Die Information, die »crm ra info ocf:heartbeat:pacemaker« auf den Bildschirm holt, entspringt 

der »meta‐data«-Funktion des Agents. 

Die Werte legen die Default-Timeouts 

fest, nach denen Pacemaker einen Fehler 

melden soll, und für die Monitor-Operation 

auch das Standard-Intervall. Alle 

Werte lassen sich in der CRM-Shell später 

überschreiben. 

Der Eintrag »« zeigt 

Pacemaker an, dass die Meta-Daten des 

Agents damit vollständig ausgegeben 

sind. Ein syntaktisch korrektes jedoch 

unvollständiges Beispiel für eine stangelegt 

werden. Ein Beispiel, um den Parameter 

namens »binary« zu definieren, 

wäre das in Listing 4. 

Der Parameter »name« bestimmt den 

Namen des Parameters und »required« 

legt fest, ob der Parameter vom Admin 

angegeben werden muss. Im »content«- 

Bereich legt »type« fest, um welche Art 

von Wert es sich handelt. Mögliche Typen 

sind neben »string« auch »integer« und 

»boolean«. 

Im Asterisk-Beispiel wäre »maxfiles« 

ein Wert des Typs »integer« und »realtime« 

ein Wert des Typs »boolean«. Ist 

für jeden Parameter ein entsprechender 

Eintrag vorhanden ist, schließt »« 

die Parameter-Liste. Dann folgt 

noch eine Übersicht über die Operationen, 

die der Agent beherrscht: 

Listing 3: Die Usage-Funktion 

01 usage() { 

02 cat

Know-how 


dardkonforme »meta‐data«-Funktion des 

Asterisk-RAs findet sich im Listing 5. 

Einen Fallstrick gibt es noch: In den Beschreibungen 

der Parameter muss man 

< und > anstelle der Zeichen „“ verwenden, schließlich handelt 

es sich um XML-Syntax. 

Die Validate-Funktion 

Listing 4: Die Meta-Daten des »binary«-Parameters 

01 

02 

03 Location of the Asterisk PBX server binary 

04 

Jeder Resource Agent nach OCF-Standard 

braucht eine Validate-Funktion. Im vorliegenden 

Beispiel muss sie herausfinden, 

ob Asterisk mit der angegebenen 

Konfiguration überhaupt zu starten ist. 

Die Funktion überprüft beispielsweise, 

ob die per Parameter festgelegte Konfigurationsdatei 

existiert und ob es den 

Benutzer und die Gruppe, mit deren 

Rechten Asterisk laufen soll, auf dem 

lokalen System gibt. Der Resource Agent 

muss auch sicherstellen, dass er selbst 

funktionieren kann. Nutzt der Resource 

Agent Binaries, deren Existenz nicht auf 

jedem System vorauszusetzen ist, so hat 

er bereits in der Validate-Funktion zu 

05 Asterisk PBX server 

binary 

06 

07 

testen, ob diese Binaries vorhanden sind 

– und muss gegebenenfalls mit einem 

Fehler den Dienst quittieren. Das Listing 

6 enthält eine Validate-Funktion, wie sie 

für Asterisk funktioniert – bis auf den 

Teil mit »sipuri« ist diese Funktion allerdings 

sehr generisch, sodass sie sich 

so ähnlich für nahezu jedes Programm 

verwenden ließe. 

Monitor- und Status- 

Operation 

Eines der sehr angenehmen Features 

von Pacemaker ist die Möglichkeit, eine 

Ressource im Hinblick auf ihren Status 

zu untersuchen; das geschieht mittels 

der »Monitor«-Operation. Der Resource 

Agent muss, wenn Pacemaker ihn mit 

dem »monitor«-Target aufruft, überprü- 

Listing 5: Die Meta-Data-Funktion 

01 meta_data() { 

02 cat &1 

17 rc=$? 

18 if [ $rc ‐ne 0 ]; then 

19 ocf_log err "User $OCF_RESKEY_user doesn't exist" 

20 return $OCF_ERR_INSTALLED 

21 fi 

22 

23 getent group $OCF_RESKEY_group >/dev/null 2>&1 

24 rc=$? 

25 if [ $rc ‐ne 0 ]; then 

26 ocf_log err "Group $OCF_RESKEY_group doesn't exist" 


28 fi 

29 

30 true 

31 } 


Know-how 


dardkonforme »meta‐data«-Funktion des 

Asterisk-RAs findet sich im Listing 5. 

Einen Fallstrick gibt es noch: In den Beschreibungen 

der Parameter muss man 

< und > anstelle der Zeichen „“ verwenden, schließlich handelt 

es sich um XML-Syntax. 

Die Validate-Funktion 

Listing 4: Die Meta-Daten des »binary«-Parameters 

01 

02 

03 Location of the Asterisk PBX server binary 

04 

Jeder Resource Agent nach OCF-Standard 

braucht eine Validate-Funktion. Im vorliegenden 

Beispiel muss sie herausfinden, 

ob Asterisk mit der angegebenen 

Konfiguration überhaupt zu starten ist. 

Die Funktion überprüft beispielsweise, 

ob die per Parameter festgelegte Konfigurationsdatei 

existiert und ob es den 

Benutzer und die Gruppe, mit deren 

Rechten Asterisk laufen soll, auf dem 

lokalen System gibt. Der Resource Agent 

muss auch sicherstellen, dass er selbst 

funktionieren kann. Nutzt der Resource 

Agent Binaries, deren Existenz nicht auf 

jedem System vorauszusetzen ist, so hat 

er bereits in der Validate-Funktion zu 

05 Asterisk PBX server 

binary 

06 

07 

testen, ob diese Binaries vorhanden sind 

– und muss gegebenenfalls mit einem 

Fehler den Dienst quittieren. Das Listing 

6 enthält eine Validate-Funktion, wie sie 

für Asterisk funktioniert – bis auf den 

Teil mit »sipuri« ist diese Funktion allerdings 

sehr generisch, sodass sie sich 

so ähnlich für nahezu jedes Programm 

verwenden ließe. 

Monitor- und Status- 

Operation 

Eines der sehr angenehmen Features 

von Pacemaker ist die Möglichkeit, eine 

Ressource im Hinblick auf ihren Status 

zu untersuchen; das geschieht mittels 

der »Monitor«-Operation. Der Resource 

Agent muss, wenn Pacemaker ihn mit 

dem »monitor«-Target aufruft, überprü‐ 

Listing 5: Die Meta-Data-Funktion 

01 meta_data() { 

02 cat &1 

17 rc=$? 

18 if [ $rc ‐ne 0 ]; then 

19 ocf_log err "User $OCF_RESKEY_user doesn't exist" 


21 fi 

22 

23 getent group $OCF_RESKEY_group >/dev/null 2>&1 

24 rc=$? 

25 if [ $rc ‐ne 0 ]; then 

26 ocf_log err "Group $OCF_RESKEY_group doesn't exist" 


28 fi 

29 

30 true 

31 } 


Know-how 


verschwinden – und mögliche Fehlermeldungen 

mit ihnen. Wenn ein externes 

Programm aufzurufen ist, empfiehlt sich 

daher »ocf_run«. 

Übrigens: Das Beispiel verwendet die 

OCF-Funktion »ocf_is_true«, um den 

Wert des Parameters »realtime« über die 

Umgebungsvariable »OCF_RESKEY_realtime« 

abzufragen. Das hat den Vorteil, 

dass Admins in der CRM-Shell sowohl 

»realtime=true« als auch »realtime=yes« 

eintragen können (und ebenso die entsprechenden 

Negativ-Pendants) – die 

Funktion »ocf_is_true« erkennt all diese 

Parameter und verhält sich entsprechend. 

Würde der Agent »OCF_RESKEY_realtime« 

direkt per if-Klausel auf einzelne Werte 

hin überprüfen, würde das in wesentlich 

mehr Code resultieren. 

Die Monitor-Operation 

Anders als die Status-Operation überprüft 

die Monitor-Operation nicht, ob Prozesse 

vorhanden sind, sondern ob Asterisk auf 

Anfragen von außen reagiert. Für andere 

Programme wäre es beispielsweise denkbar, 

mittels eines Programms wie »telnet« 

oder »openssl s_client« zu testen, ob auf 

einem bestimmten Port eine Antwort 

kommt. Das Asterisk-Binary hat selbst 

einen Client-Modus, der mit »‐c ‐r« aufzurufen 

ist. Mithin könnte eine Monitor- 

Operation für Asterisk aussehen wie in 

Listing 8. Es ist übrigens kein Zufall, dass 

Läuft Asterisk nicht, soll der Agent den 

Dienst starten. An dieser Stelle spielt 

wieder Astcanary eine Rolle: Der wird 

von Asterisk selbst gestartet, sodass 

der Asterisk Agent sich darum nicht 

kümmern muss. Stirbt allerdings eine 

Asterisk-Instanz, so stirbt der dazugehörige 

Astcanary nicht automatisch mit. 

Deshalb muss die »start«-Funktion auch 

eventuelle Astcanary-Zombies aus dem 

Weg räumen, bevor sie einen neuen 

Asterisk starten kann. 

Schließlich kommt die Funktion zu ihrer 

eigentlichen Aufgabe. Weil Agents 

nach dem OCF-Standard nicht distribudie 

»asterisk_monitor«-Funktion gleich am 

Anfang »asterisk_status« aufruft und mit 

einem Fehler abbricht, falls der Rückgabewert 

nicht »OCF_SUCCESS« ist. Nach 

diesem Prinzip muss der Agent später 

nämlich beim Start mit dem »monitor«- 

Target nur die »asterisk_monitor«-Funktion 

laufen lassen. 

Die erwähnte Funktion »asterisk_rx« ist 

übrigens eine am Anfang des Agents definierte 

Hilfsfunktion, die so aussieht: 

asterisk_rx() { 

# if $HOME is set, asterisk ‐rx writes U 

a .asterisk_history there 

( 

unset HOME 

ocf_run $OCF_RESKEY_binary ‐r ‐s U 

$ASTRUNDIR/asterisk.ctl ‐x "$1" 

) 

} 

Die Funktion überprüft zunächst, ob 

Asterisk überhaupt läuft (dazu ruft sie 

wie erwähnt asterisk_status() auf) und 

bringt dann den Asterisk-Client dazu, auf 

der Asterisk-Console den Befehl »core 

show channels count« zu starten. Falls 

der Administrator ein SIP-URL beim 

Para meter »sipuri« eingetragen hat, versucht 

der Agent im Anschluss, eine SIP- 

Verbindung mit »sipsak« zu dieser URL 

aufzubauen. Je nach Erfolg der einzelnen 

Befehle gibt die Funktion 0 oder eine 

Fehlermeldung zurück. 

Die Start-Funktion soll freilich in erster 

Linie Sorge dafür tragen, dass der 

Asterisk-Daemon so läuft, wie es in der 

CRM-Konfiguration vorgesehen ist. Sie 

muss aber noch mehr leisten: Im OCF- 

Standard ist vorgesehen, dass sie in solchen 

Fällen, in denen Asterisk bereits 

läuft, OCF_SUCCESS zurückgeben muss, 

also 0. Es wäre dann ohnehin nicht sinnvoll, 

den Daemon nochmal zu starten, 

denn das würde höchstwahrscheinlich 

in einer Fehlermeldung enden. Ein mächtiges 

Werkzeug, um die Funktion von 

Asterisk zu testen, ist bereits in Form der 

»asterisk_monitor«-Funktion vorhanden 

– diese ruft »start« idealerweise auf und 

interpretiert deren Rückgabewert entsprechend, 

bevor die Funktion irgendetwas 

anderes tut. 

Die Start-Funktion 

Listing 8: Die Monitor-Funktion 

01 asterisk_monitor() { 

02 local rc 

03 

04 asterisk_status 

05 rc=$? 

06 

07 # If status returned an error, return that immediately 

08 if [ $rc ‐ne $OCF_SUCCESS ]; then 

09 return $rc 

10 fi 

11 

12 # Check whether connecting to asterisk is possible 

13 asterisk_rx 'core show channels count' 

14 rc=$? 

15 

16 if [ $rc ‐ne 0 ]; then 

17 ocf_log err "Failed to connect to the Asterisk PBX" 

18 return $OCF_ERR_GENERIC 

19 fi 

20 

21 # Optionally check the monitor URI with sipsak 

22 # The return values: 

23 # 0 means that a 200 was received. 

24 # 1 means something else then 1xx or 2xx was received. 

25 # 2 will be returned on local errors like non resolvable names 

26 # or wrong options combination. 

27 # 3 will be returned on remote errors like socket errors 

28 # (e.g. icmp error), redirects without a contact header or 

29 # simply no answer (timeout). 

30 # This can also happen if sipsak is run too early after asterisk 

31 # start. 

32 if [ ‐n "$OCF_RESKEY_monitor_sipuri" ]; then 

33 ocf_run sipsak ‐s "$OCF_RESKEY_monitor_sipuri" 

34 rc=$? 

35 case "$rc" in 

36 1|2) return $OCF_ERR_GENERIC;; 

37 3) return $OCF_NOT_RUNNING;; 

38 esac 

39 fi 

40 

41 ocf_log debug "Asterisk PBX monitor succeeded" 

42 return $OCF_SUCCESS 

43 } 



Know-how 

tionsspezifisch sein dürfen, fallen die 

distributionseigenen Werkzeuge wie 

»start‐stop‐daemon« auf Debian aus. Der 

Agent muss das Asterisk-Binary direkt 

aufrufen. Dazu konstruiert er aus den 

verschiedenen angegebenen Parametern 

einen Asterisk-Aufruf, den er dann mittels 

»ocf_run« ausführt. Zuvor stellt er 

noch sicher, dass die Ordner, die Asterisk 

zum Funktionieren braucht, existieren 

und dass der per Parameter festgelegte 

Asterisk-Benutzer dort auch tatsächlich 

Schreibrechte hat. Direkt nach dem Aufruf 

des Binaries überprüft die Start-Funktion 

mittels »monitor « nochmals, ob der 

Start auch tatsächlich funktioniert hat 

Listing 9: Die Start-Funktion 

und Asterisk so läuft, wie gewünscht. 

Von der Astcanary-Episode abgesehen ist 

die verwendete Start-Funktion eine typische, 

wie sie mit leichten Anpassungen 

auch für viele andere Daemons zum Einsatz 

kommen könnte. Die gesamte Start- 

Funktion sieht aus, wie in Listing 9. 

Die Stop-Funktion 

Sinn und Zweck der Stop-Funktion ist 

es, sicher zu wissen, dass Asterisk im 

Anschluss an den Agent-Aufruf nicht 

mehr läuft. Am Anfang der Funktion 

steht wiederum ein Aufruf von »monitor«, 

der »OCF_SUCCESS« zurückgibt, 

wenn Asterisk bereits abgeschaltet ist. 

Danach kommt ein viergliedriges Schema 

zum Einsatz: Erst bekommt Asterisk 

mittels »core stop now«-Befehl über die 

Asterisk-Shell den Befehl zum Beenden. 

Das sollte im Normalfall reichen. Tut es 

das nicht, folgt ein Kill mit »SIGTERM«. 

Sollte dieser Befehl nicht den Rückgabewert 

0 liefern, so bedeutet das, dass 

der Kill-Befehl gar nicht erst seine Arbeit 

verrichten konnte und der Daemon das 

Signal nie erhalten hat; der Agent steigt 

an dieser Stelle mit »OCF_ERR_GENE- 

RIC« aus, denn es ist wahrscheinlich, 

dass das System in gröberen Schwierigkeiten 

steckt. Wenn »kill ‐s TERM« keine 

01 asterisk_start() { 

02 local asterisk_extra_params 

03 local dir 

04 local rc 

05 


07 rc=$? 

08 if [ $rc ‐eq $OCF_SUCCESS ]; then 

09 ocf_log info "Asterisk PBX already running" 


11 fi 

12 

13 # If Asterisk is not already running, make sure there is no 

14 # old astcanary instance when the new asterisk starts. To 

15 # achieve this, kill old astcanary instances belonging to 

16 # this $ASTRUNDIR. 

17 

18 # Find out PIDs of running astcanaries 

19 astcanary_pid=`pgrep ‐d " " ‐f "astcanary $ASTRUNDIR/alt.asterisk. 

canary.tweet.tweet.tweet"` 

20 

21 # If there are astcanaries running that belong to $ASTRUNDIR, 

22 # kill them. 

23 if [ "$astcanary_pid" ]; then 

24 for i in $astcanary_pid; do ocf_run kill ‐s KILL $astcanary_pid; 

done 

25 fi 

26 

27 for dir in $ASTRUNDIR $ASTLOGDIR $ASTLOGDIR/cdr‐csv $ASTLOGDIR/ 

cdr‐custom; do 

28 if [ ! ‐d "$dir" ]; then 

29 ocf_run install ‐d ‐o $OCF_RESKEY_user ‐g $OCF_RESKEY_group 

$dir \ 

30 || exit $OCF_ERR_GENERIC 

31 fi 

32 # Regardless of whether we just created the directory or it 

33 # already existed, check whether it is writable by the 

configured 

34 # user 

35 if ! su ‐s /bin/sh ‐ $OCF_RESKEY_user ‐c "test ‐w $dir"; then 

36 ocf_log err "Directory $dir is not writable by $OCF_RESKEY_ 

user" 

37 exit $OCF_ERR_PERM 

38 fi 

39 done 

40 

41 # set MAXFILES 

42 ulimit ‐n $OCF_RESKEY_maxfiles 

43 

44 # Determine whether Asterisk PBX is supposed to run in Realtime mode 

45 # or not and make asterisk daemonize automatically 

46 if ocf_is_true "$OCF_RESKEY_realtime"; then 

47 asterisk_extra_params="‐F ‐p" 

48 else 

49 asterisk_extra_params="‐F" 

50 fi 

51 

52 ocf_run ${OCF_RESKEY_binary} ‐G $OCF_RESKEY_group ‐U $OCF_RESKEY_ 

user \ 

53 ‐C $OCF_RESKEY_config \ 

54 $OCF_RESKEY_additional_parameters \ 

55 $asterisk_extra_params 

56 rc=$? 

57 if [ $rc ‐ne 0 ]; then 

58 ocf_log err "Asterisk PBX start command failed: $rc" 

59 exit $OCF_ERR_GENERIC 

60 fi 

61 

62 # Spin waiting for the server to come up. 

63 # Let the CRM/LRM time us out if required 

64 while true; do 

65 asterisk_monitor 

66 rc=$? 

67 [ $rc ‐eq $OCF_SUCCESS ] && break 

68 if [ $rc ‐ne $OCF_NOT_RUNNING ]; then 

69 ocf_log err "Asterisk PBX start failed" 


71 fi 

72 sleep 2 

73 done 

74 

75 ocf_log info "Asterisk PBX started" 


77 }\ 


Admin 


103

Know-how 


Fehlermeldung zurückgibt, bedeutet das 

allerdings nicht, dass der Prozess auch 

tatsächlich stirbt. Der Agent überprüft 

das und schickt gegebenenfalls noch ein 

»SIGKILL« nach – solange, bis der Wert 

für den Timeout der Stop-Funktion erreicht 

ist. Läuft der Daemon danach noch 

immer, ist manuelles Eingreifen seitens 

des Admins notwendig. Insgesamt kann 

die »asterisk_stop«-Funktion aussehen, 

wie in Listing 10. 

Der Corpus des Resource 

Agents 

Bisher definiert der Agent im Wesentlichen 

Funktionen, die seine diversen 

Aufgaben wahrnehmen. Es fehlt noch 

der Teil, der diese Funktionen aufruft, 

wenn der Agent mit einem entsprechenden 

Target gestartet wird. In genau diesen 

Corpus gehören auch die zuvor schon er- 

Logging mit OCF 

In den Code-Snipplets der einzelnen Funktionen 

finden sich diverse Aufrufe von »ocf_log« mit 

verschiedenen Parametern, die die Relevanz der 

Ausgaben für den Admin festlegen. Die »Severity« 

eines »ocf_log«-Aufrufs sorgt dafür, dass 

im HA-Log die Logeinträge entsprechend markiert 

werden, sodass ein Admin später gezielt 

danach suchen kann. Die folgenden Kategorien 

kennt die Funktion: 

debug: Debug-Informationen, die für den normalen 

Betrieb des Clusters nur von sehr geringer 

Relevanz sind. Standardmäßig verschluckt 

wähnten Definitionen von »ASTRUNDIR« 

und »ASTLOGDIR« – jedenfalls gehören 

sie hinter den Aufruf der Validate-Funktion 

(denn wenn »validate« scheitert, 

lassen sie sich möglicherweise gar nicht 

setzen). Der Rest entspricht im Wesentlichen 

der Syntax, die beispielsweise 

auch viele Init-Skripte verwenden – das 

der HA-Stack auf den meisten Systemen diese 

Meldungen und zeigt sie gar nicht erst an. 

info: Allgemeine Logging-Informationen, die für 

den Administrator keinen unmittelbaren Handlungsbedarf 

signalisieren. 

warn: Warnungen, unerwartete Ereignisse, aber 

die nicht als Fehlermeldung gelten. 

err: Fehlermeldungen, an die der OCF-Agent 

jeweils ein »exit« mit dem dazugehörigen Returnwert 

anschließen sollte. 

crit: Kritische Fehler, die ein Eingreifen des Admins 

unbedingt und schnell notwendig machen. 

Listing 11 enthält ein vollständiges Beispiel, 

das in der Agent-Datei ganz an das 

Ende gehört. 

Den Resource Agent testen 

Es ist nicht zwingend notwendig, einen 

Pacemaker aufzusetzen, um zu testen 

Listing 10: Die »asterisk_stop«-Funktion 

01 asterisk_stop() { 

02 local pid 

03 local astcanary_pid 

04 local rc 

05 


07 rc=$? 

08 if [ $rc ‐eq $OCF_NOT_RUNNING ]; then 

09 ocf_log info "Asterisk PBX already stopped" 


11 fi 

12 

13 # do a "soft shutdown" via the asterisk command line first 

14 asterisk_rx 'core stop now' 

15 


17 rc=$? 


19 ocf_log info "Asterisk PBX stopped" 


21 fi 

22 

23 # If "core stop now" didn't succeed, try SIGTERM 

24 pid=`cat $ASTRUNDIR/asterisk.pid` 

25 ocf_run kill ‐s TERM $pid 

26 rc=$? 

27 if [ $rc ‐ne 0 ]; then 

28 ocf_log err "Asterisk PBX couldn't be stopped" 


30 fi 

31 

32 # stop waiting 

33 shutdown_timeout=15 

34 if [ ‐n "$OCF_RESKEY_CRM_meta_timeout" ]; then 

35 shutdown_timeout=$((($OCF_RESKEY_CRM_meta_timeout/1000)‐5)) 

36 fi 

37 count=0 

38 while [ $count ‐lt $shutdown_timeout ]; do 


40 rc=$? 


42 break 

43 fi 

44 count=èxpr $count + 1` 

45 sleep 1 

46 ocf_log debug "Asterisk PBX still hasn't stopped yet. Waiting 

..." 

47 done 

48 


50 rc=$? 

51 if [ $rc ‐ne $OCF_NOT_RUNNING ]; then 

52 # SIGTERM didn't help either, try SIGKILL 

53 ocf_log info "Asterisk PBX failed to stop after ${shutdown_ 

timeout}s using SIGTERM. Trying SIGKILL ..." 

54 ocf_run kill ‐s KILL $pid 

55 fi 

56 

57 # After killing asterisk, stop astcanary 

58 if ocf_is_true "$OCF_RESKEY_realtime"; then 

59 astcanary_pid=`pgrep ‐d " " ‐f "astcanary $ASTRUNDIR/alt.asterisk. 

canary.tweet.tweet.tweet"` 

60 if [ "$astcanary_pid" ]; then 

61 for i in $astcanary_pid; do ocf_run kill ‐s KILL $astcanary_pid; 

done 

62 fi 

63 fi 

64 

65 ocf_log info "Asterisk PBX stopped" 


67 } 



Know-how 

Abbildung 4: Der fertige Resource Agent lässt sich auch händisch auf der Kommandozeile testen, ohne einen 

Pacemaker aufzusetzen. 

Abbildung 5: Der »ocf‐testr« überprüft einen OCF-Agent im Hinblick auf seine Konformität mit dem OCF- 

Standard. 

(Abbildung 4), ob der Agent so funktioniert, 

wie er soll. Weil OCF-Agents Shellskripte 

sind, lassen sie sich auch von der 

Kommandozeile aus aufrufen. Wichtig 

ist dafür, dass die Umgebungsvariable 

»OCF_ROOT« gesetzt ist; auf den allermeisten 

Linux-Distributionen muss die 

Variable auf »/usr/lib/ocf« zeigen. 

Daneben sollten die OCF-spezifischen 

Umgebungsvariablen für die Parameter 

ebenfalls in der Shell gesetzt sein, beispielsweise 

»OCF_RESKEY_realtime« – 

besonders dann, wenn ein Parameter als 

»required« markiert ist oder kein Defaultwert 

dafür existiert. Dann lässt sich der 

Agent, der im Beispiel »asterisk« heißt 

und in »/usr/lib/ocf/resource.d/heartbeat« 

liegt, in diesem Ordner mit »./asterisk 

monitor« aufrufen, um den Status 

der Ressource zu testen. Freilich empfiehlt 

es sich, einen lauffähigen Asterisk 

(beziehungsweise das Programm, für das 

der Agent geschrieben ist) zu haben. Die 

Befehle »start«, »stop« und alle anderen 

festgelegten Kommandos funktionieren 

äquivalent. Wenn der Agent sich in bestimmten 

Aspekten nicht wie erwartet 

verhält, führt sein Aufruf mit vorangestelltem 

»sh ‐x« vermutlich zu weiterem 

Erkenntnisgewinn. 

Sollte ein funktionierender Pacemaker 

verfügbar sein, kann in diesem auch eine 

Ressource mit dem Agenten definiert werden 

(die Bezeichnung des Agents ist im 

Beispiel »ocf:heartbeat:asterisk«), um sie 

danach mit »ocf‐tester« zu testen. Unter 

der Prämisse, dass die Asterisk-Ressource 

»p_asterisk« heißt, wäre der vollständige 

OCF-Tester-Aufruf »ocf‐tester ‐n p_asterisk / 

usr/lib/ocf/resource.d/heartbeat/asterisk« 

(Abbildung 5). Sollte »ocf‐tester« eine 

Fehlermeldung ausgeben, weiß der 

Agent-Autor, dass mit dem Werk noch 

etwas nicht stimmt. 

Fazit 

Der OCF-Standard ist ein sehr mächtiges 

Werkzeug, um qualitativ hochwertige Resource 

Agents für Pacemaker zu schaffen. 

Weil er auf Shellscripting basiert, dürfte 

die Eingewöhnung den meisten Admins 

nicht schwerfallen. Der Artikel behandelt 

als Beispiel zwar Asterisk, die meisten 

Funktionen werden sich aber in fast jedem 

Agent so oder so ähnlich wiederfinden. 

Dabei wird aber jedes Programm 

seine typischen Eigenheiten haben, mit 

denen die Resource-Agent-Schöpfer jeweils 

zurechtkommen müssen. Wer einen 

Resource Agent geschaffen hat und 

diesen dann gern zum Bestandteil des offiziellen 

»cluster‐agents«-Paketes machen 

möchte, der hat übrigens die Möglichkeit, 

sein Werk auf der Linux-HA-Dev-Mailingliste 

öffentlich zur Diskussion zu stellen 

[4]. (jcb) n 

Infos 

[1] Die OCF-Spezifikation in ihrer letzten 

gültigen Fassung: [http:// www. opencf. 

org/ cgi‐bin/ viewcvs. cgi/ specs/ ra/ 

ResourceAgent‐api. txt? rev=HEAD] 

[2] Der Resource Agent Developer’s Guide 

1.0.2: [http:// www. linux‐ha. org/ doc/ 

dev‐guides/ ra‐dev‐guide. html] 

[3] Der vollständige Asterisk-Resource Agent: 

[https:// raw. github. com/ ClusterLabs/ 

ResourceAgents/ master/ heartbeat/ 

asterisk] 

[4] Die Linux-HA-Dev-Mailingliste: 

[http:// lists. linux‐ha. org/ mailman/ listinfo/ 

linux‐ha‐dev] 

Der Autor 

Martin Gerhard Loschwitz arbeitet als Principal 

Consultant bei hastexo. Er beschäftigt sich dort 

intensiv mit Hochverfügbarkeitslösungen und 

pflegt in seiner Freizeit den Linux-Cluster-Stack 

für Debian GNU/Linux. 

Listing 11: Der Korpus des Agenten 

01 case "$1" in 

02 meta‐data) meta_data 

03 exit $OCF_SUCCESS;; 

04 usage|help) usage 

05 exit $OCF_SUCCESS;; 

06 esac 

07 

08 

09 # Anything except meta‐data and help must pass validation 

10 asterisk_validate || exit $? 

11 

12 # Now that validate has passed and we can be sure to be able to read 

13 # the config file, set convenience variables 

14 ASTRUNDIR=`grep astrundir $OCF_RESKEY_config | awk '/âstrundir/ {print 

$3}'` 

15 ASTLOGDIR=`grep astlogdir $OCF_RESKEY_config | awk '/âstlogdir/ {print 

$3}'` 

16 

17 # What kind of method was invoked? 

18 case "$1" in 

19 start) asterisk_start;; 

20 stop) asterisk_stop;; 

21 status) asterisk_status;; 

22 monitor) asterisk_monitor;; 

23 validate‐all) ;; 

24 *) usage 

25 exit $OCF_ERR_UNIMPLEMENTED;; 

26 esac 


Admin 


105

Know-how 

GFS 

© SUNG KUK KIM, 123RF 

HA-Workshop, Teil 7: GFS mit DRBD und Pacemaker 

Nichts exklusiv 

Cluster-Dateisysteme wie GFS2 und OCFS2 ermöglichen vielen Clients den gleichzeitigen Zugriff auf ein Storage- 

Device. Dank DRBD und Pacemaker wird der Dienst so auf günstige Weise redundant – allerdings hat die Sache 

ein paar Haken. von Martin Loschwitz 

Auf Cluster-Dateisysteme trifft man 

häufig in Hochverfügbarkeitsclustern. 

Die bekanntesten Filesysteme dieser Art 

sind GFS2 und OCFS2, aber auch Lustre 

genießt einiges an Aufmerksamkeit und 

NFS bietet in Version 4 einen ähnlichen 

Dienst an (pNFS). Über den Sinn und 

Unsinn von Cluster-Filesystemen lässt 

sich trefflich streiten (siehe auch den 

Kasten „Die Gefahren von DRBD im 

Dual-Primary Modus“). Wenn aber die 

Entscheidung für ein solches Dateisystem 

gefallen ist, dann helfen Pacemaker und 

DRBD dabei, den Dienst hochverfügbar 

zu machen. 

Der folgende Artikel beschreibt am Beispiel 

von GFS, wie sich auf aktuellen Systemen 

Pacemaker zum Cluster-Manager 

für Cluster-Dateisysteme aufschwingt. 

Leider gibt es unter den vier „großen“ 

Enterprise-Distributionen – Debian, 

Ubuntu, SLES und RHEL – einiges an 

Uneinigkeit darüber, wie ein Setup dieser 

Art am besten aussehen sollte. Ein dicker 

Riss trennt dabei insbesondere Red Hat 

von den anderen drei Distributionen. 

Zur Geschichte von GFS 

Das Cluster-Dateisystem GFS existiert im 

Grunde bereits seit 1995, richtig an Verbreitung 

gewann die Software allerdings 

erst als Red Hat den damaligen Hersteller 

Sistina im Jahre 2005 kaufte und anfing, 

die Entwicklung voranzutreiben. Offiziell 

hielt GFS Einzug in Linux, als Linus 

Torvalds es zum Bestandteil der Kernelversion 

2.6.19 machte. GFS2 war damit 

später dran als OCFS2, das es schon in 

den Kernel 2.6.16 schaffte. 

GFS setzt im Kernel auf die Strukturen 

des Distributed Lock Managers (DLM). 

Diese Software, die ebenfalls aus der Feder 

von Red-Hat-Entwicklern stammt, ist 

im Wesentlichen ein großes Framework, 

das den gleichzeitgen Zugriff auf Storage- 

Ressourcen koordiniert. GFS2 funktioniert 

nur, wenn der Distributed Lock Manager 

aktiv ist und keine Probleme hat. Red 

Hats Wunsch, auch andere Software-Produkte 

mögen den DLM verwenden, ging 

in Erfüllung: cLVM, die Cluster-Variante 

von LVM, verwendet den DLM ebenfalls 

– wohl nicht zuletzt deshalb, weil Red 

Hat massiv an der LVM-Entwicklung beteiligt 

ist. 

Wer DLM und GFS nutzen möchte, muss 

dafür einerseits sicherstellen, dass die 

entsprechenden Kernel-Module geladen 

sind. Andererseits braucht jede der bei- 


GFS 

Know-how 

Abbildung 1: Um DRBD in den Dual-Primary-Modus zu verfrachten, ist es nötig, 

den Modus im »net«-Abschnitt der Ressource zu konfigurieren. Hinzu kommt 

Fencing auf Ressource-Ebene. 

herausstellte, gewann 

Pacemaker 

zusehends an Bedeutung. 

Red Hat 

stellte daraufhin 

für den DLM wie 

auch für GFS sogenannte 

»Control 

Daemons« her, 

mit denen sich die 

Software in Pacemaker 

integrieren 

ließ. Die Binaries 

dafür heißen 

»dlm_controld. 

pcmk« und »gfs_ 

controld.pcmk« 

und werden aus 

Pacemaker heraus 

wie alle anderen 

Ressourcen auch 

über Resource 

Agents gestartet. 

Weil sowohl der DLM als auch GFS zwischenzeitlich 

zu Teilen von Red Hats 

Cluster Suite (RHCS) geworden waren, 

wurden auch die Control-Daemons für 

Pacemaker mit der RHCS zusammen 

ausgeliefert. Bis einschließlich RHCS 

3.0 war die Welt also in Ordnung, wenn 

Pace maker und GFS zusammen funktionieren 

sollten. 

In der Red Hat Cluster Suite 3.1 kam 

dann allerdings der Sinneswandel: Red 

Hat beschloss, sein eigenes Cluster- 

Produkt massiv umzubauen. Das führte 

dazu, dass Pacemaker – dessen Hauptentwickler 

in der Zwischenzeit von Red 

Hat engagiert worden war – eine Schnittstelle 

für Cman bekam. Über diese sollte 

der CRM dann mit den Tools kommunizieren, 

die den DLM und GFS kontrollieren. 

In den Augen Red Hats waren die 

Pacemaker-Control-Daemons für DLM 

und GFS damit überflüssig, sie wurden 

kurzerhand entfernt. 

Novell hat allerdings aus nachvollziehbaren 

Überlegungen heraus große Skrupel, 

die RHCS zum Bestandteil des eigenen 

Produktes zu machen, obwohl das lizenzden 

Komponenten auch ein Gegenstück 

im Userland, welches die Kommunikation 

mit den Kernel-Modulen übernimmt und 

eine Schnittstelle für andere Programme 

bietet. Ein Control-Daemon für GFS sorgt 

beispielsweise dafür, dass zwischen den 

Knoten eines GFS-Clusters tatsächlich 

auch der gewünschte Datenaustausch 

stattfindet. 

Und genau hier liegt der Hund begraben: 

Um sich die Arbeit zu ersparen, einen 

eigenen Cluster-Manager für GFS zu implementieren 

(so, wie es zum Beispiel 

Oracle bei OCFS2 gemacht hat), waren 

bei GFS die Control-Daemons und der 

Red-Hat-eigene Cluster-Manager »Cman« 

stets eng verzahnt. Was sich aber in den 

letzten drei Jahren bei der Integration von 

GFS in die verfügbaren Cluster-Manager 

abspielte, mutet für Außenstehende an 

wie eine schlechte Komödie. 

Tunnelblick 

Als sich Corosync – maßgeblich von 

Red Hat propagiert – als Lösung der Zukunft 

in Sachen Cluster-Kommunikation 

Abbildung 2: Ist DRBD richtig konfiguriert, klappt’s auch mit dem Dual-Primary, wie hier gut zu erkennen. 

technisch freilich möglich wäre. Stattdessen 

pflegt Suse künftig die alten Control- 

Daemons der RHCS 3.0 auf eigene Faust 

weiter. Derzeit gibt es also zwei Methoden, 

um GFS auf Linux mit Pacemaker zu 

verheiraten – und sie unterscheiden sich 

stark voneinander: Auf RHEL 6 braucht 

es Pacemaker mit Cman-Integration, auf 

Debian, Ubuntu und SLES kommt hingegen 

die alte Variante zum Einsatz, die 

eigene Control-Daemons in Pacemaker 

für DLM und GFS vorsieht. 

Die nächste grundlegende Änderung im 

Hinblick auf GFS kommt übrigens ganz 

bestimmt: Die weiteren Pläne von Red 

Hat sehen vor, Cman komplett durch 

Pacemaker zu ersetzen. In nicht allzu 

ferner Zukunft ist deshalb damit zu rechnen, 

dass Red Hat die Control-Daemons 

für Cman kompatibel mit Pacemaker 

macht – um genau dort anzukommen, 

wo das Unternehmen in Version 3.0 der 

RHCS schonmal war. 

Grau ist alle Theorie, deshalb folgen nun 

Taten: Den Anfang macht ein GFS-Cluster-Setup 

für Debian, Ubuntu und SLES. 

Debian und Ubuntu liefern Pacemaker in 

ihren Standard-Distributionen zwar mit, 

allerdings ist die feilgebotene Version 

bereits etwas angestaubt. Im Ubuntu- 

HA-PPA [1] oder im Backports-Verzeichnis 

für Squeeze [2] finden sich für die 

Systeme aber aktualisierte Pacemaker- 

Pakete. Wer SLES auf seinen Servern einsetzt, 

braucht für GFS die High Availability 

Extension (HAE), in der die Pakete 

Listing 1: Ressourcen-Konfiguration 

01 primitive p_controld_dlm ocf:pacemaker:controld op 

monitor interval="120s" 

02 primitive p_controld_gfs ocf:pacemaker:controld 

params 

03 daemon="gfs_controld.pcmk" args="" op monitor 

interval="120s" 

04 clone cl_controld_dlm p_controld_dlm meta 

globally‐unique="false" 

05 interleave="true" 

06 clone cl_controld_gfs p_controld_gfs meta 

globally‐unique="false" 

07 interleave="true" 

08 colocation co_dlm_always_with_drbd_master inf: cl_ 

controld_dlm 

09 ms_drbd_gfs:Master 

10 colocation co_gfs_always_with_dlm inf: cl_controld_ 

gfs cl_controld_dlm 

11 order o_gfs_always_after_dlm inf: cl_controld_dlm 

cl_controld_gfs 

12 order o_dlm_always_after_drbd inf: ms_drbd_ 

gfs:promote cl_controld_dlm 


Admin 


107

Know-how 

GFS 

für GFS enthalten sind. Alternativ finden 

sich im Internet auch Pakete von Drittanbietern. 

Vorarbeit 

Auf Ubuntu 10.04 und Debian Squeeze 

sowie auf SLES sind wie erwähnt die 

„alten“ Daemons zu verwenden, die 

diesen Distributionen beiliegen. Sie finden 

sich in den Paketen »gfs‐pcmk« und 

»dlm‐pcmk«, die auf dem System vorhanden 

sein sollten. In SLES finden sich die 

benötigten Pakete über die Paketsuche. 

Der Artikel geht im Folgenden davon aus, 

dass DRBD installiert und mindestens 

eine DRBD-Ressource vorhanden ist. 

Diese Ressource sollte so eingerichtet 

sein, dass sie im Dual-Primary-Modus 

laufen darf (Abbildung 1). Ausgehend 

von einer „normalen“ Ressource, wie 

sie im Artikel zu DRBD in der HA-Serie 

[3] beschrieben ist, sind in der Konfiguration 

der Ressource dazu zwei Dinge 

zu ändern. Einerseits ist dem »net«-Absatz 

in der Ressourcen-Konfiguration 

der Eintrag »allow‐two‐primaries yes;« 

hinzuzufügen. Andererseits sollte DRBD 

auch erfahren, was es tun soll, falls 

eine Split-Brain-Situation eintritt. Das 

passiert mit 

after‐sb‐0pri discard‐zero‐changes; 

after‐sb‐1pri discard‐secondary; 

after‐sb‐2pri disconnect; 

ebenfalls im »net«-Absatz der Ressource. 

Überdies sollte Pacemaker installiert 

und grundlegend konfiguriert sein. Es 

sei an dieser Stelle darauf hingewie 

Die Gefahren von DRBD im Dual-Primary-Modus 

Der Betrieb einer DRBD-Ressource im Dual-Primary-Modus 

ist die zwingende Voraussetzung, 

um GFS2 auf dieser Ressource zu nutzen. Nicht 

zu unterschätzen sind dabei die Gefahren, die 

von dieser Art der DRBD-Benutzung ausgehen. 

Standard-Dateisysteme 

Dateisysteme existieren aus einem Grund: Sie 

machen Speicherplatz verwaltbar. Ohne ein 

Dateisystem wäre es schwierig, einmal auf das 

Speichermedium geschriebene Daten später 

wiederzufinden. Die Struktur des Dateisystems 

erlaubt es, Inhalte auf dem Datenträger erneut 

zu öffnen und zu verändern. Solange dem Dateisystem 

nichts in die Quere kommt, funktioniert 

dieses Prinzip ganz wunderbar. Und solange ein 

Datenträger konsistent ist, ist die Welt für den 

Admin in Ordnung. 

Bei ihrer Arbeit gehen Dateisysteme grundsätzlich 

davon aus, dass nur sie überhaupt auf den 

Datenträger zugreifen dürfen, und zwar nur 

genau die Dateisystem-Instanz, die zu einem 

bestimmten Mount gehört. Der gleichzeitige 

Zugriff zweier Dateisystem-Instanzen auf denselben 

Datenträger ist in den Konzepten der 

Standard-Dateisysteme unter Linux nicht vorgesehen. 

Die in Linux enthaltenen Dateisysteme 

geben sich entsprechend große Mühe, gleichzeitige 

Datenträgerzugriffe durch zwei oder mehr 

Instanzen eines Dateisystems auszuschließen. 

Ein bereits gemountetes Dateisystem lässt sich 

nicht woanders nochmal mounten. 

Solange der Datenträger nur einem einzigen 

System zur Verfügung steht, ist es für den 

Linux-Kernel kein Problem, dieses Prinzip aufrechtzuerhalten. 

Denn dort hat er die Deutungshoheit 

über die verfügbare Hardware. Im Falle 

von DRBD ist das aber nicht mehr der Fall: Die 

DRBD-Ressource ist grundsätzlich auf beiden 

Clusterknoten vorhanden, und der Ext3-Treiber 

von Knoten A hätte keine Möglichkeit, sich über 

den Zustand der gleichen DRBD-Ressource auf 

Knoten B zu informieren, wenn er schreibend 

darauf zugreift. Im schlimmsten Falle könnte es 

also passieren, dass auf beiden Seiten des Clusters 

auf die DRBD-Ressource geschrieben wird, 

wobei der jeweils andere Knoten von diesem 

Umstand vorerst gar nichts merken würde. Einen 

solchen Vorgang bezeichnet man als Concurrent 

Write. Wenn auf ein Medium von zwei Seiten 

gleichzeitig unkoordiniert geschrieben wird, ist 

sicher davon auszugehen, dass das Dateisystem 

Schaden nimmt. Admins holen dann die Backups 

raus, und Downtimes von Diensten gehören zu 

den unangenehmen Folgen. 

Was tun? 

DRBD schützt sich selbst gegen Concurrent 

Writes, indem es in der Standardkonfiguration 

stets im Primary-Secondary-Modus läuft. Auf 

dem Knoten, auf dem sich eine Ressource im Secondary-Modus 

befindet, sorgt der DRBD-Treiber 

dafür, dass kein Zugriff durch Userhand auf die 

Ressource stattfindet. Damit ist die Gefahr einer 

Korrumpierung des Dateisystems grundsätzlich 

gebannt. Der Nachteil: Cluster-Dateisysteme wie 

GFS oder OCFS2 beruhen auf dem Prinzip, dass 

sie auf sämtliche Datenträger innerhalb ihres 

Storage-Netzwerks uneingeschränkten Zugriff 

haben. Sie kümmern sich selbst darum, dass 

Concurrent Writes ausbleiben und sind somit auf 

die Schutzfunktion von DRBD nicht angewiesen. 

Damit GFS oder OCFS2 auf DRBD-Ressourcen 

funktionieren, muss DRBD also so konfiguriert 

sein, dass der schreibende Zugriff auf beiden 

Knoten für die Cluster-Dateisysteme möglich 

wird. Wie DRBD zu konfigurieren ist, ist in diesem 

Artikel ausführlich beschrieben. 

Der Pferdefuß 

Allerdings ist es nicht so, dass es völlig unproblematisch 

ist, DRBD-Ressourcen im Dual-Primary- 

Modus zu betreiben. Einerseits sind hinsichtlich 

der Clusterkonfiguration Details zu beachten: In 

einem Cluster, der DRBD-Ressourcen im Dual- 

Primary-Modus betreibt, ist ein funktionierendes 

STONITH-Setup Pflicht – denn sonst hat ein 

Knoten keine Möglichkeit, einen anderen Knoten 

aus dem Cluster zu werfen, wenn dieser Schwierigkeiten 

bereitet. Andererseits führt Fencing 

im Zusammenhang mit Clusterdateisystemen 

zu neuen Unannehmlichkeiten. Gelangt ein 

Knoten beispielsweise zur Überzeugung, dass 

ein anderer Knoten per STONITH abzuschießen 

sei, blockiert das Netzwerkdateisystem kurzerhand 

sämtlichen I/O-Traffic – und zwar auf 

allen Knoten, die zu einem Storage-Pool gehören 

– solange, bis der vermeintlich aus dem Tritt 

geratene Knoten sicher ausgeschlossen ist. Mit 

Blick auf die Performance kann das schnell zum 

Problem werden. 

Lieber zweimal nachdenken 

Angesichts der Nachteile, die der Dual-Primary- 

Modus hat, scheint es schwer nachvollziehbar, 

dass viele Setups von Anfang an auf eine solche 

Konfiguration setzen. Häufig finden sich im Netz 

zum Beispiel Clusteranleitungen, die verschiedene 

Konfigurationsdateien auf DRBDs mit Cluster-Dateisystemen 

legen, um diese auf beiden 

Clusterknoten parat zu halten. Eingedenk der 

enormen Komplexität, die dadurch zum Setup 

hinzukommt, ist Lösungen auf Basis von Csync2, 

Rsync oder auch Puppet/Chef allerdings der Vorzug 

einzuräumen. Ein Setup mit einem Cluster- 

Dateisystem sollte nur und ausschließlich dann 

überhaupt in Erwägung gezogen werden, wenn 

es dafür handfeste Gründe gibt. Denkbar wäre 

ein OCFS2-Setup für Oracle. 

Übrigens: Mancher Einfaltspinsel glaubt, er 

könne Ext3 & Co. ein Schnippchen schlagen, indem 

er den Dual-Primary-Modus bei DRBD nutzt, 

um auf einer der beiden Seiten des Clusters 

dann im Read-Only-Modus auf das Dateisystem 

zuzugreifen. Davon ist strikt abzuraten: Dateisysteme 

unter Linux gehen davon aus, dass nur 

sie die vollständige Kontrolle haben. Daten, die 

auf einem Read-Only-FS im Cache landen, werden 

dort nicht mehr aktualisiert – schließlich 

glaubt der Dateisystemtreiber, dass sie sich zwischenzeitlich 

nicht ändern können. Selbst wenn 

in diesen Szenarien also das Dateisystem nicht 

korrumpiert wird, so bekommen Clients beim Lesezugriff 

dort nach einer kurzen Zeit vermutlich 

keine aktuellen Daten mehr geliefert. 


GFS 

Know-how 

Abbildung 3: Die Ausgabe von »crm_mon ‐1« zeigt, dass alle Dienste, die zu GFS 

gehören, richtig konfiguriert sind und funktionieren. 

Abbildung 4: Der Resource-Agent »ocf:pacemaker:controld« existiert nur auf 

Ubuntu, Debian und SLES – auf RHEL-kompatiblen Systemen muss Cman für die 

Steuering von DLM und GFS herhalten. 

sen, dass Pacemaker unbedingt über 

eine funktionierende STONITH-Konfiguration 

verfügen sollte; nur diese gibt 

dem Cluster-Manager die Möglichkeit, 

amoklaufende Cluster-Knoten aus dem 

Cluster zu schießen. Schließlich setzt 

der Artikel voraus, dass die vormals 

erwähnte DRBD-Ressource bereits als 

solche in Pacemaker konfiguriert ist und 

als »ms_drbd_gfs« zur Verfügung steht. 

Zu beachten ist dabei, dass die »ms«- 

Ressource etwas anders anzulegen ist, 

als bei einem DRBD, das im Primary- 

Secondary-Modus läuft: 

ms ms_drbd_gfs p_drbd_gfs U 

meta master‐max=2 clone‐max=2U 

notify=true 

Wenn diese Voraussetzungen erfüllt sind, 

sollte die DRBD-Ressource auf beiden 

Clusterseiten mit »drbdadm primary Ressource« 

in den Modus »Primary« geschaltet 

werden (Abbildung 2). 

GFS2 im Cluster 

Dann folgt die Ressourcen-Konfiguration 

in Pacemaker. Für GFS braucht der 

Cluster zwei Dienste: »dlm_controld«, 

der die Kommunikation mit dem Distributed 

Lock Manager übernimmt, und 

»gfs_controld.pcmk«, der die Steuerung 

des GFS2-Daemons übernimmt. Die beiden 

Dienste werden über den Ressource- 

Agent »ocf:pacemaker:controld« gesteuert. 

Die Konfiguration in der CRM-Shell 

für dieses Beispiel sollte also so aussehen 

wie in Listing 1. Die genannten Einträge 

sorgen dafür, dass der Pacemaker grundsätzlich 

weiß, dass die Control-Daemons 

laufen sollen und dass sie stets auf allen 

Knoten des Clusters laufen – dies stellen 

die »clone«-Einträge sicher. Durch die 

Constraints ist sichergestellt, dass der 

DLM-Daemon immer bloß dort gestartet 

wird, wo die jeweilige DRBD-Ressource 

im Primary-Modus läuft und dass erst im 

Anschluss an den DLM-Start auch der 

GFS-Controld startet. 

Wenn der DLM und der GFS-Controld 

laufen, dann kann auch das GFS-Dateisystem 

auf der DRBD-Ressource landen: 

sudo mkfs.gfs2 ‐p lock_dlm ‐j2 ‐t pcmk:pcmkU 

Ressource 

Ressource ist der Device Node der DRBD- 

Ressource, zum Beispiel »/dev/drbd/ 

by-res/disk0/0«. 

Dann fehlt noch die Dateisystem- 

Ressource in Pacemaker, die das 

GFS auf den Clusterknoten mountet. 

»ocf:heartbeat:Filesystem« kommt mit 

GFS2 zurecht, die passende Ressourcen- 

Konfiguration sieht dann so aus wie in 

Listing 2. 

Die Primitive-Ressource sorgt in Kombination 

mit dem Clone-Eintrag dafür, 

dass das Dateisystem auf allen Clusterknoten 

läuft. Durch die Constraints ist 

aber festgelegt, dass die Ressourcen nur 

laufen dürfen, wenn der GFS-Controld 

einsatzbereit ist. 

Nach einem »commit« in der CRM- 

Shell sollte der Cluster aussehen wie im 

Abbildung 3. 

GFS2 auf RHEL 6 

Auf Red Hat Enterprise Linux 6 oder damit 

kompatiblen Distributionen gestaltet 

sich das GFS-Setup anders (Abbildung 4). 

Die Control-Daemons, die Pacemaker mit 

dem DLM und dem GFS verbinden, fehlen. 

Stattdessen hat Pacemaker eine direkte 

Schnittstelle zu Cman. Auf solchen 

Systemen wird nicht Corosync gestartet, 

der das Pacemaker als Modul nachlädt – 

so, wie es im Rahmen der HA-Serie bisher 

stets war. Stattdessen läuft Pacemaker als 

Kindprozess von Cman und erhält von 

diesem alle wichtigen Infos. 

Die Konfiguration der DRBD-Ressource 

unterscheidet sich auf RHEL nicht von 

der zuvor beschriebenen Konfiguration 

Listing 2: GFS2-Dateisystem-Ressource 

01 primitive p_filesystem ocf:heartbeat:Filesystem \ 

02 params device="/dev/drbd/by‐res/disk0/0" 

directory="/opt" fstype="gfs2" 

03 \ 

04 op monitor interval="120s" \ 

05 meta target‐role="Started" 

06 clone cl_filesystem p_filesystem \ 

07 meta interleave="true" ordered="true" 

08 colocation p_filesystem_always_with_gfs inf: cl_ 

filesystem cl_controld_gfs 

09 order o_filesystem_always_after_gfs inf: cl_controld_ 

gfs cl_filesystem 


Admin 


109

Know-how 

GFS 

für Debian, Ubuntu oder SLES. Auch auf 

RHEL sollte die DRBD-Ressource so eingerichtet 

sein, dass Dual-Primary geht. 

Wenn eine entsprechende DRBD-Konfiguration 

vorhanden ist, geht es mit der 

Konfiguration von Cman weiter, das im 

Normalfall erst zu installieren ist. 

Cman für Pacemaker 

Cman findet seine Konfiguration in »/etc/ 

cluster/cluster.conf«. Die Datei verwendet – 

wie Pacemaker intern auch – eine XML-basierte 

Syntax, allerdings ist sie nur einmal 

zu editieren und funktioniert dann klaglos. 

Für das Pacemaker-Beispiel könnte »cluster. 

conf« so aussehen wie in Listing 3. 

Das genannte Beispiel enthält auch Fencing-Direktiven, 

die Cman dazu bringen, 

Listing 3: »cluster.conf« 

01 

02 

03 

04 

05 

06 

07 

08 

09 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

Abbildung 5: »service cman start« startet Cman, der in weiterer Folge 

Pacemaker als eigentlichen Cluster-Manager aufruft. 

Fencing-Requests 

jedweder Art direkt 

an Pacemaker 

weiterzuleiten. 

Die »clusternode«- 

Einträge beziehen 

sich auf die Knoten 

des Clusters, 

statt »pcmk‐1« und 

»pcmk‐2« sollten 

die tatsächlichen 

Namen der Cluster 

hier erscheinen. 

Wenn die Cman- 

Konfigurationsdatei eingerichtet ist, gilt 

es, den dazugehörenden Dienst zu starten: 

»service cman start«. Der Output auf 

der Kommandozeile sollte aussehen, wie 

in Abbildung 5. Deutlich ist zu erkennen, 

dass Cman selbst sowohl den Control- 

Daemon für DLM als auch den für GFS 

startet. Anders als bei der Variante für 

Debian & Co. sind auf RHEL-kompatiblen 

Systemen diese Dienste also kein Teil der 

CIB mehr, über die Pacemaker wacht. 

DRBD für das Cman- 

Pacemaker-Gespann 

Nach dem ersten Start des Pacemakers 

ist die CIB logischerweise leer. Es empfiehlt 

sich daher, jetzt das Fencing und die 

grundlegenden Pacemaker-Einstellungen 

vorzunehmen. Auch die Ressource und das 

Master-Slave-Setup für DRBD können jetzt 

ihren Weg in die CIB finden; das passiert 

analog zu der Erklärung für die anderen 

Systeme im Artikel weiter oben. Auch auf 

RHEL ist darauf zu achten, dass DRBD von 

Pacemaker im Dual-Primary-Modus gestartet 

wird, indem der Wert » master‐max« auf 

»2« steht, genauso wie »clone‐max«. Das 

Beispiel bezieht sich auf diese Ressource 

wiederum als »ms_drbd_gfs«. 

GFS2-Dateisystem anlegen 

Im nächsten Schritt gelangt ein GFS- 

Dateisystem auf die DRBD-Ressource, 

nachdem diese dank Pacemaker auf beiden 

Cluster-Seiten im Primary-Modus 

läuft. Der Befehl dazu lautet 

mkfs.gfs2 ‐p lock_dlm ‐j 2 ‐tU 

pcmk:web Device 

wobei Device durch den Device Node 

der Ressource zu ersetzen ist, also beispielsweise 

»/dev/drbd/by‐res/drbd0/0«. 

Schließlich fehlt in Pacemaker eine 

Filesystem-Ressource, die das GFS auf 

den Cluster-Knoten verwendbar macht, 

samt passender Clone-Regel und Constraints: 

configure primitive p_gfs_fs ocf:U 

heartbeat:Filesystem params 

device="/dev/drbd/by‐res/drbd0/0"U 

directory="/opt" fstype="gfs2" 

clone cl_gfs_fs p_gfs_fs 

colocation co_cl_gfs_fs_always_with_U 

ms_drbd_gfs_master inf: cl_gfs_fs ms_U 

drbd_gfs:Master 

order o_cl_gfs_fs_always_after_ms_drbdU 

_gfs_promote inf: ms_drbd_gfs:promote U 

cl_gfs_fs 

Mögliche weitere Dienste, die Pacemaker 

auf beiden Seiten des Clusters starten 

soll, sobald das GFS auf beiden Knoten 

verfügbar ist, würden in der Folge per 

Colocation- und Order-Constraint freilich 

mit »cl_gfs_fs« verbunden. 

Fazit 

Wesentlich schwieriger als das Setup 

eines GFS-Clusters dürfte es sein, ein 

echtes Einsatzszenario für diese Konstellation 

zu finden. Besonders die 

Notwendigkeit eines umfangreichen 

Fencings wegen des DRBDs im Dual- 

Primary-Modus macht diese Variante 

nämlich ziemlich komplex. Möglicherweise 

schickt sich ja bald eine der Lösungen 

für replizierte Dateisysteme an, 

GFS & Co. auf die Plätze zu verweisen: 

Die Bewerber Gluster und Ceph scharren 

bereits mit den Hufen. (jcb) 

n 

Infos 

[1] Cluster-Pakete für Ubuntu 10.04 

LTS: [https:// launchpad. net/ 

~ubuntu‐ha‐maintainers/ +archive/ 

lucid‐cluster/ +packages] 

[2] Das Debian-Backports-Repository: 

[http:// backports. debian. org/] 

[3] ADMIN 04/2011, Martin Gerhard Loschwitz, 

Seite 80: „DRBD - Storage-Replikation mit 

Open Source.“ 

Der Autor 

Martin Gerhard Loschwitz arbeitet als Principal 

Consultant bei hastexo. Er beschäftigt sich dort 

intensiv mit Hochverfügbarkeitslösungen und 

pflegt in seiner Freizeit den Linux-Cluster-Stack 

für Debian GNU/Linux. 


Alles zum ThemA 

Android 

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

Kennenlernangebot: 

3 AusgAben 

für nur 3 euro 


www.android–user.de/miniabo 

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

Neu! 

am KiosK

Basics 

Upstart 

© Andrzej Kwiatkowski, 123RF 

Wie Upstart Ubuntu-basierte Systeme bootet 

Start me up 

Als Ersatz für das alte System-V-Init wirft Upstart viele geliebte wie gehasste 

Konzepte über Bord: Statt verwirrender Runlevel gibt es jetzt Jobs 

und Ereignisse, während parallel startende Dienste den Bootvorgang beschleunigen 

sollen. Dennoch ist die Konfiguration fast ein Kinderspiel. 

Tim Schürmann 

Sobald der Linux-Kernel die Hardware 

in Beschlag genommen und alle Treiber 

geladen hat, übergibt er die Kontrolle an 

das kleine Programm »init«. Ihm kommt 

die Aufgabe zu, den Rest des Systems 

einzurichten und hochzufahren. Bis vor 

wenigen Jahren nutzten noch fast alle 

Linux-Distributionen das so genannte 

System-V-Init mit seinem geliebten wie 

gehassten Runlevel-Konzept. Es startete 

brav einen Dienst nach dem anderen, 

was zu teilweise recht langen Bootzeiten 

führte. 

Bei Canonical begann man deshalb 2006 

mit der Entwicklung eines flotteren Ersatzes. 

Das Ergebnis namens Upstart fährt 

seitdem vor allem bei Ubuntu-Distributionen 

sowie Red Hat Enterprise Linux 

(RHEL) 6 die Dienste hoch. 

Gegenüber dem alten System-V-Init versucht 

Upstart alle notwendigen Dienste 

und Programme möglichst parallel zu 

starten. Darüber hinaus kann es auf bestimmte 

Ereignisse reagieren, beispielsweise 

wenn man während des Betriebs 

eine Festplatte einstöpselt oder austauscht. 

Schließlich beobachtet es auf 

Wunsch ohne umständliche Krücken die 

gestarteten Prozesse und startet sie bei 

einem Absturz automatisch neu. Um das 

alles leisten zu können, bricht es vollständig 

mit dem alten Runlevel-Konzept. 

Wer damit noch arbeiten muss, sollte 

im Folgenden kurz sein altes Wissen 

vergessen. 

Um ein Linux-System vollständig hochzufahren, 

muss Upstart verschiedene 

Aufgaben durchführen – wie etwa das 

Netzwerk aktivieren oder den Webserver 

»httpd« starten. Jede dieser Aufgaben 

bezeichnet Upstart als Job, den es 

allerdings immer nur dann bearbeitet, 

wenn zuvor ein passendes Ereignis eingetreten 

ist. Ein solches Ereignis könnte 

beispielsweise „Netzwerk aktiviert“ oder 

„Druckerdaemon gestartet“ sein. Gibt es 

zu einem Ereignis mehrere Jobs, so versucht 

Upstart, sie parallel zu bearbeiten. 

Das alles erfolgt vollautomatisch: Ein 

Webserver muss Upstart nur mitteilen, 

dass er gerne beim Ereignis „Netzwerk 

aktiviert“ starten möchte. Um alles andere 

kümmert sich Upstart. 

Jeder Job besitzt im Unterverzeichnis 

»/ etc/init« eine eigene Konfigurationsdatei 

mit der Endung ».conf«. So finden sich 

beispielsweise in »cups.conf« alle Informationen, 

die Upstart zum Aktivieren 

des Cupps-Druckerdaemon kennen muss. 

Der Dateiname ohne Endung ist gleichzeitig 

der offizielle Name des Jobs. 

Tod oder Leben 

Bester Freund des Administrators ist das 

zu Upstart gehörende Werkzeug »initctl«. 

Es kontrolliert und verwaltet sämtliche 

Jobs. Beispielsweise listet der Befehl 

initctl list 

sämtliche Jobs und ihren aktuellen Status 

auf (Abbildung 1). In jeder Zeile steht 

ganz vorne der Name eines Jobs. Der Begriff 

vor dem Schrägstrich verrät, ob der 

Job zuletzt gestartet (»start«) oder angehalten 

(»stop«) wurde. Nach dem Schrägstrich 

folgt sein aktueller Zustand. Sofern 

ein Job beziehungsweise der durch ihn 

gestartete Dienst läuft, steht am Ende 

auch gleich noch seine Prozess-ID. Einen 

laufenden Job beendet 

initctl stop jobname 

Damit man sich nicht immer die Finger 

wund tippen muss, darf man alternativ 

auch einfach nur 

stop jobname 

aufrufen. »stop« ist schlicht ein Wrapper-Skript 

für »initctl stop«, das ebenfalls 

zum Upstart-Paket gehört und normalerweise 

in »/sbin« liegt. In jedem Fall 

sendet Upstart dem betroffenen Prozess 

zunächst ein SIGTERM-Signal und wartet 

dann standardmäßig fünf Sekunden. 


Upstart 

Basics 

Abbildung 2: Gibt man dem Kernel den Parameter »‐‐debug« auf den Weg, plaudert Upstart alle seine 

Aktionen nebst den aufgetretenen Ereignissen aus. 

Abbildung 1: »initctl list« liefert den Zustand 

sämtlicher Jobs. 

Wenn der Dienst danach immer noch 

laufen sollte, beendet Upstart ihn umgehend 

mit dem SIGKILL-Signal. Ein einmal 

ausgesprochenes »initctl stop« ist somit 

endgültig. 

Neben »stop« gibt es natürlich auch noch 

»start« und »restart«, die einen Job starten 

beziehungsweise neustarten. Tabelle 

1 fasst die wichtigsten »initctl«-Befehle 

zusammen (zu den noch unbekannten 

Befehlen gleich noch mehr). Apropos 

»/sbin«: Darin liegt auch Upstart selbst 

unter dem Namen »init«, damit Linux es 

auch garantiert findet. 

Wer einen eigenen Dienst beim Booten 

hochfahren lassen möchte, braucht 

eine neue Job-Datei. Im einfachsten 

Troubleshooting 

Auftauchende Probleme protokolliert Upstart im 

Syslog – unter Ubuntu 11.10 also beispielsweise 

in »/var/log/syslog« (Abbildung 2). Wem die dort 

hinterlegten Informationen nicht ausreichen, 

macht Upstart mit 

initctl log‐priority info 

oder sogar 

initctl log‐priority debug 

noch gesprächiger. Im letzten Fall protokolliert 

es jeden einzelnen seiner Schritte. Das Kommando 

nützt freilich nichts, wenn die Probleme 

schon während des Bootens aufgetaucht sind. 

Dann kann man dem Kernel den Parameter 

»‐‐verbose« oder für die noch geschwätzigere 

Variante »‐‐debug« anhängen (unter Ubuntu indem 

man nach dem Einschalten die [Umschalt]- 

Taste gedrückt hält, dann [e] tippt, mit den 

Fall besteht diese aus lediglich einer 

einzigen Zeile: 

exec /usr/bin/messd ‐‐log=/var/log/laerm/U 

messung.log 

Hinter »exec« steht schlicht das Programm 

beziehungsweise der Dienst, den Upstart 

ausführen soll. Hier im Beispiel nimmt 

ein Lärmmessprogramm seine Arbeit auf, 

das unablässig über entsprechende Hardware 

den Schallpegel misst und seine gesammelten 

Messergebnisse in der angegebenen 

Logdatei ablegt. Sobald man die 

obige Zeile in einer Datei wie beispielsweise 

»messen.conf« verstaut und diese 

bei ihren Kolleginnen unter »/etc/init« 

geparkt hat, kann man die Messsoftware 

bereits als Administrator per 

sudo start messen 

hochfahren beziehungsweise via 

sudo stop messen 

beenden. In der Regel möchte man den 

Dienst automatisch beim Booten starten. 

In diesem Fall muss man die Job-Datei 

wie in Listing 1 noch etwas erweitern. 

Pfeiltasten zur Zeile »linux /boot/vmlinuz ...« 

fährt, [Ende] drückt, mit englischer Tastaturbelegung 

»‐‐debug« anhängt und [Strg+X] bemüht). 

Solange noch kein Syslog-Daemon aktiv 

ist, wandern alle Meldungen in das Kernel-Log. 

Man muss folglich sowohl das Kernel-Log als 

auch das Syslog im Auge behalten. Eine konkrete 

Job-Datei »messen.conf« klopft 

init‐checkconf messen.conf 

auf Tippfehler ab. Anschließend mahnt 

initctl check‐config 

noch alle in »/etc/init« abgelegten Jobs an, deren 

Ereignis-Bedingungen sich nie erfüllen – die 

also von sich aus niemals starten oder stoppen 

werden. Die beiden Befehle gibt es in dieser 

Form übrigens erst seit Upstart 1.3, das sein 

Debüt in Ubuntu 11.10 feierte. Schon seit Upstart 

Kommentare beginnen wie von Shellskripten 

gewohnt mit einem Hash (#). 

Hinter »start on« steht der Name eines 

Ereignisses. Sobald es eintritt, aktiviert 

Upstart automatisch den Dienst. Anstelle 

von »exec« darf man übrigens auch ein 

Skript einbinden: 

script 

# kleines Bash‐Skript: 

if [...]; then 

... 

fi 

end script 

Upstart führt dann nicht ein Programm 

aus, sondern arbeitet die Shellbefehle 

zwischen »script« und »end script« ab. 

Die Job-Dateien selbst sind übrigens 

reine Textdateien und sollten möglichst 

nicht ausführbar sein. 

Günstige Gelegenheit 

Die Upstart-Ereignisse, auf die ein Job 

warten kann, können aus mehreren Quellen 

stammen. Sobald Upstart die Arbeit 

aufnimmt, erzeugt es automatisch selbst 

ein Ereignis mit dem Namen »startup«. 

0.6.4 lässt sich auch ein Überblick über alle 

Jobs ausgeben: 

initctl show‐config ‐e > ausgabe.txt 

Die dabei entstandene Datei wandelt auf Wunsch 

»initctl2dot« in ein Graphviz-Diagramm um: 

initctl2dot ‐f ausgabe.txt ‐o ausgabe.dot 

aus dem Graphviz wiederum einen Abhängigkeitsgraphen 

zeichnet: 

dot ausgabe.dot ‐Tps > diagramm.ps 

Das Ergebnis ist dann eine Postscript-Datei, in 

der man für jeden Job sieht, von welchen anderen 

er abhängt beziehungsweise welche seiner 

Kollegen nur auf seinen Start warten (Abbildung 

4). Das Diagramm ist übrigens nicht ganz so 

verwirrend, wie es vielleicht auf den ersten Blick 

erscheint. 


Admin 


113

Basics 

Upstart 

Ein Dienst, der mit der Anweisung 

start on startup 

nur auf dieses Ereignis wartet, kann daher 

weder mit einem funktionierenden 

Netzwerk noch mit einem vorhandenen 

Dateisystem rechnen. Im Weiteren entsteht 

immer dann ein Ereignis, wenn irgendein 

Job startet oder stoppt. Mit der 

Zeile 

start on starting rsyslog 

würde Upstart etwa das Lärmmessprogramm 

gleichzeitig mit »rsyslog« starten. 

Möchte man sicherstellen, dass »rsyslog« 

schon läuft, nutzt man »started«: 

start on started rsyslog 

Damit würde das Lärmmessprogramm 

erst nach »rsyslog« loslegen – wann genau, 

lässt sich nicht vorhersagen. Man 

muss folglich damit rechnen, dass möglicherweise 

»rsyslog« noch nicht vollständig 

funktioniert. Schließlich kann Upstart 

den Job auch anwerfen, sobald sich ein 

anderer Dienst beendet beziehungsweise 

nicht läuft: 

start on stopped rsyslog 

Eine weitere Ereignisschleuder sind 

Systemdienste, allen voran der Gerätemanager 

»udev«. Beim Einstöpseln eines 

neuen Gerätes erzeugt er ein Ereignis 

der Form »sub‐device‐action«. »sub« steht 

dabei für das entsprechende Udev-Subsystem 

und »action« für die ausgeführte 

Aktion. Ein neu angeschlossener Datenträger 

löst beispielsweise das Ereignis 

»block‐device‐added« aus. 

Eine unvollständige Liste mit den grundlegenden 

und zumindest in jedem 

Ubuntu-System vorhandenen Ereignissen 

liefert die Manpage »man upstart‐events« 

(Abbildung 5). Eine weitere Quelle sind 

die schon vorhandenen Job-Dateien unter 

»/etc/init«. 

Abschließend kann ein Administrator mit 

»initctl« ein eigenes Ereignis auslösen: 

initctl emit meinereignis 

Diesen Befehl darf natürlich auch ein 

Skript in der Job-Datei aufrufen. Damit 

es nicht Upstarts Planungen durcheinanderwürfelt, 

muss man die Job-Datei dann 

noch mit der Zeile 

emit meinereignis 

würzen. Sie kündigt formal an, dass 

der Job irgendwann das Ereignis »meinereignis« 

auslöst. Sofern ein Job mehrere 

Ereignisse absetzen möchte, führt man 

sie jeweils in einer eigenen Zeile auf, 

wie etwa: 

emit start‐messung 

emit ende‐messung 

Die »emit«-Angaben benötigt übrigens 

auch zwingend »initctl check‐config«, um 

die Abhängigkeiten zwischen den Jobs 

korrekt überprüfen zu können (siehe 

Kasten „Troubleshooting“). 

Bindungen 

Einige Dienste setzen gleich mehrere Ereignisse 

voraus. Das Lärmmessprogramm 

könnte beispielsweise seine Daten nicht 

nur auf der Festplatte speichern, sondern 

sie auch in regelmäßigen Intervallen an 

einen Server im Internet versenden. Das 

Messprogramm kann folglich erst dann 

starten, wenn zum einen das Dateisystem 

vorhanden und zum anderen das 

Netzwerk hochgefahren ist – also die 

Ereignisse »filesystem« und »started network‐manager« 

eingetreten sind. Genau 

diese Bedingungen schreibt man jetzt 

einfach in die Job-Datei hinter »start on« 

und verknüpft sie mit einem »and«: 

start on (filesystem and started network‐U 

manager) 

Neben »and« gibt es noch das logische 

Oder (»or«). Zusammen mit den Klammern 

darf man mit ihnen nahezu beliebig 

komplexe Bandwurmbedingungen 

basteln, wie es unter anderem das Bootsplash-Utility 

Plymouth vormacht (zu 

den eckigen Klammern und »runlevel« 

später noch mehr): 

start on (starting mountall or (runlevelU 

[016] and (desktop‐shutdown or stopped U 

xdm or stopped uxlaunch))) 

Man darf die Zeile zwar umbrechen und 

mit Tabulatoren etwas übersichtlicher 

formatieren, mehrere »start on«-Zeilen 

sind jedoch nicht erlaubt. 

Auf welche Ereignisse die einzelnen 

Jobs warten beziehungsweise sie jeweils 

selbst absetzen, verrät der Befehl (Abbildung 

3): 

initctl show‐config 

Tabelle 1: »initctl«-Befehle im Überblick 

Befehl Kurzform Bedeutung 

initctl start jobname start jobname Startet den Job jobname 

initctl stop jobname stop jobname Hält den Job jobname an 

initctl restart jobname restart jobname Startet den Job jobname neu 

initctl status jobname status jobname Liefert den Status des Job jobname 

initctl list 

Listet alle vorhandenen Jobs und ihren Status 

initctl check-config 

Prüft alle Job-Dateien auf (Tipp-)Fehler 

initctl show-config 

Zeigt für jeden Job, auf welche Ereignisse er 

wartet und welche er selbst erzeugt. 

initctl emit ereignis 

Löst das Ergebnis ereignis aus. 

initctl reload-configuration 

Liest die eigene Konfiguration neu ein 

Abbildung 3: »initctl show‐config« listet alle 

Jobs und ihre Ereignisse auf. Diese recht 

unübersichtlichen Informationen … 


Upstart 

Basics 

Mit dem zusätzlichen Parameter »‐e« 

dröselt er auch komplexe Bedingungen 

auf und zeigt an, welche Teile Ereignisse 

und welche andere Jobs sind (siehe auch 

Kasten „Troubleshooting“). 

Ein Absturz des Lärmmessprogramms 

wäre ziemlich unangenehm. Selbst 

wenn ein Administrator sofort eingreifen 

würde, gingen für einige Zeit wertvolle 

Messwerte verloren. Glücklicherweise 

kann Upstart einen Dienst beobachten 

und bei einem Absturz automatisch neustarten. 

Dazu genügt es, in der Job-Datei 

eine Zeile mit dem Schlüsselwort 

respawn 

wait-for-state 

start on stop on $WAIT_FOR 

start on stop on 

control-alt-delete 


control-alt-delete 

friendly-recovery 


recovery 

network-interface-security 


networking 

ufw 



m odemmanager 

start on stop on network-manager 


plymouth-upstart-bridge 


avahi-daemon 


cups 


tty1 


setvtrgb 


plymouth 

plymouth-splash 



lxdm 


upstart-socket-bridge 


mountall-net 


network-interface 


failsafe 


dbus 


rsyslog 


xdm 


atd 


tty6 


tty4 


tty2 


alsa-restore 


socket 

net-device-up 

net-device-down 

net-device-added 

static-network-up 

local-filesystem s 

hwclock-save 


alsa-store 


zu hinterlassen. Damit Upstart den Dienst 

im Auge behalten kann, startet es übrigens 

standardmäßig alle Prozesse im Vordergrund. 

Man kann das nur umgehen, 

indem sich der hinter »exec« eingetragene 

Dienst selbst forkt. 

Der automatische Neustart hat allerdings 

auch einen kleinen Haken: Würde der 

Dienst durch einen Programmfehler immer 

wieder das Zeitliche segnen, würde 

ihn Upstart in einer Endlosschleife immer 

wieder reanimieren – und damit unter 

Umständen sogar das ganze System 

überlasten. Um das zu verhindern, ist es 

möglich, in der Job-Datei eine Zeitspanne 

vorzugeben. Mit dem Zweizeiler: 

oem-config 


kdm 

login-session-start 

uxlaunch 


desktop-shutdown 

filesystem 

respawn 5 60 

plymouth-stop 

start on 

stop on 


gdm 


desktop-session-start 

graphics-device-added 

net-device-removed 

deconfiguring-networking 

respawn 

ubiquity 


lightdm 


udev-fallback-graphics 


drm-device-added 

binfmt-support 


plymouth-log 


rc-sysinit 


tty3 


tty5 


apport 


failsafe-boot 

irqbalance 

runlevel 

fährt Upstart das Messprogramm lediglich 

fünf Mal in 60 Sekunden neu hoch. Das 

erste »respawn« stellt dabei nur die Zeitspanne 

ein, das zweite aktiviert schließlich 

die automatische Wiederbelebung. 

start on 

stop on 

ureadahead 


rc 


unmounted-remote-filesystems 

acpid 


Reinigungspersonal 

dmesg 

start on 

stop on 

mountall-shell 


hwclock 


mountall-reboot 


console-setup 


udev-finish 

start on stop on udevmonitor 


mountall 


upstart-udev-bridge 


udevtrigger 


remote-filesystems 

all-swaps 

mounting 

anacron 


cron 


rcS 


* -device-removed 

*-device-offline 

*-device-added 

*-device-changed 

Häufig muss man vor dem Start eines 

Dienstes noch ein paar Dinge geraderücken 

beziehungsweise nach seinem 

Ableben etwas aufräumen. Das Lärmmessprogramm 

will seine Daten im Verzeichnis 

»/var/log/laerm« ablegen. Es 

wäre also eine gute Idee, es vor seinem 

Start einzurichten. Glücklicherweise darf 

man in der Job-Datei ein Shellskript hinterlegen, 

das Upstart noch vor dem eigentlichen 

Start des Dienstes ausführt: 

*-device-online 

udev 


virtual-filesystems 

pre‐start script 

module-init-tools 


procps 

# Erstelle alle notwendigen Verzeichnisse 

hostnam e 



startu p 

mkdir ‐p /var/log/laerm 

end script 

ureadahead-other 

start on 

stop on 

mounted-var 


mounted-run 


mounted-dev 


mounted-debugfs 


mounte 

d 

Das Skript steht dabei zwischen »pre‐start 

script« und »end script«. Es ist ausschließlich 

für vorbereitende Maßnahmen ge- 

mounted-proc 


mounted-tmp 


Generated on 2011-12-06 18:03:32.492107 by initctl2dot 

(from file data). 

Boxes of color #DCDCDC denote jobs. 

Solid diamonds of color thistle denote events. 

Dotted diamonds denote ’glob’ events. 

Emits denoted by green lines. 

Start on denoted by blue lines. 

Stop on denoted by red lines. 

Listing 1: Beispiel für eine einfache Job-Datei 

01 # Start eines Lärmmessprogramms 

Abbildung 4: … lassen sich in ein wesentlich übersichtlicheres Diagramm verwandeln. Die Pfeile kennzeichnen 

dabei die Abhängigkeiten der Jobs untereinander. 

02 start on filesystem 

03 exec /usr/bin/messd ‐‐log=/var/log/laerm/messung.log 


Admin 


115

Basics 

Upstart 

dacht und darf nicht den eigentlichen 

Dienst starten. Im obigen Beispiel stellt 

es sicher, dass die Messsoftware das Verzeichnis 

für Ihre Daten findet. Analog 

gibt es eine »post‐stop script«-Sektion, 

die Upstart immer dann abarbeitet, wenn 

der Dienst terminiert. Für gewöhnlich 

räumen die dortigen Shell-Befehle auf, 

beim Messprogramm etwa: 

post‐stop script 

# Räume auf: 

rm ‐rf /var/log/laerm 

end script 

Abschließend gibt es noch ein »post‐start«- 

Skript, das Upstart immer zeitgleich mit 

dem hinter »exec« angegebenen Dienst 

startet. 

Die oben aufgeführten »pre‐start« und 

»post‐stop«-Skripte bestehen eigentlich 

nur aus einer Zeile, weshalb man sie 

auch etwas kürzer als 

pre‐start exec mkdir ‐p /var/log/laerm 

und 

Angaben informieren Administratoren 

über den Zweck des Jobs und nennen 

einen Ansprechpartner. 

Sobald das Ereignis »filesystem« eintritt, 

aktiviert Upstart den Job. Gleichzeitig 

setzt es das Ereignis »starting messen« 

ab, auf das andere Jobs reagieren können. 

Außerdem führt es die Shell-Befehle 

hinter »pre‐start script« aus. Sobald das 

geschehen ist, aktiviert es den Dienst 

»/usr/bin/messd« und verkündet gleichzeitig 

das Ereignis »started messen«. Diesen 

Ablauf veranschaulicht noch einmal 

Abbildung 6. 

Altes Laufniveau 

Viele Softwarepakete bringen noch keine 

Job-Dateien, sondern nur ältere System- 

V-Init-Skripte mit. Das gilt sogar für 

die meisten Dienste aus den aktuellen 

Ubuntu-Repositories. Wer beispielsweise 

den Apache-Webserver installiert, sucht 

unter »/etc/init« vergeblich eine passende 

Job-Datei. Stattdessen wandert 

wie zu guten alten Zeiten ein System-V- 

Init-Skript ins Verzeichnis »/etc/init.d«. 

Damit solche alten Skripte unter Ubuntu 

nicht über Nacht nutzlos werden, greift 

Upstart zu einem kleinen Trick: Ganz 

zum Schluss aktiviert es den Job »rc«, 

welcher das Skript »/etc/init.d/rc« ausführt. 

Dieses wiederum arbeitet alle alten 

SystemV-Init-Skripte unter »/etc/init.d« 

ab. Den dabei zu verwendenden Runlevel 

zieht Upstart entweder aus der Datei 

»/etc/inittab« oder übernimmt ihn von 

der Kernel-Kommandozeile. Im Zweifelsfall 

gilt der Runlevel 2, der zu einem 

System mit grafischer Oberfläche im 

Netzwerkbetrieb führt. 

Soll ein Job erst zusammen mit den Skripten 

eines bestimmten Runlevels anlaufen, 

verwendet man das »runlevel«-Ereignis: 

start on runlevel [23] 

In diesem Fall würde der Job nur in den 

Runlevels 2 und 3 starten – und zwar parallel 

zu allen darin liegenden Skripten. 

Das »runlevel«-Ereignis erzeugt Upstart, 

post‐stop exec rm ‐rf /var/log/laerm 

schreiben darf. 

Alle zusammen 

Die komplette Job-Datei der Messstation 

zeigt noch einmal Listing 2. Neu sind 

dort nur die ersten beiden Zeilen: Hinter 

»description« steht eine Beschreibung des 

Jobs, hinter »author« der Verfasser. Beide 

Listing 2: »messen.conf« 

01 description "Beispiel für einen Job" 

02 author "Tim Schürmann" 

03 

04 start on filesystem 

05 exec /usr/bin/messd ‐‐log=/var/log/laerm/messung.log 

06 

07 pre‐start script 

08 # Erstelle notwendiges Verzeichnis: 

09 mkdir ‐p /var/log/laerm 

10 end script 

11 

12 post‐stop script 

13 # Räume auf: 

14 rm ‐rf /var/log/laerm 

15 end script 

16 

17 respawn 

18 respawn limit 5 60 

19 stop on filesystem 

Abbildung 5: Die Manpage zu »upstart‐events« liefert nur einen kleinen Teil aller möglichen Ereignisse. 


sobald es die System-V-Init-Skripte eines 

Runlevels abarbeitet. Anhalten lässt sich 

ein solcher Job analog: 

stop on runlevel [!2345] 

Das Ausrufezeichen steht hier für die 

Verneinung. 

Des Weiteren imitiert Upstart das Verhalten 

des alten System-V-Init. So kann man 

weiterhin mit 

telinit 2 

in den Runlevel 2 wechseln, auch »reboot« 

und »shutdown« funktionieren 

weiterhin wie gewohnt. Unter der Haube 

sendet »telinit« jetzt allerdings nur ein 

entsprechendes Ereignis an Upstart. Den 

Standard-Runlevel setzt man zudem in 

der Job-Datei »rc‐sysinit.conf« hinter der 

Variablen »DEFAULT_RUNLEVEL«. 

Fazit 

Upstart räumt mit den alten unübersichtlichen 

Runlevels auf, bietet mit den einfach 

aufgebauten Jobs eine viel simplere 

Konfiguration und beschleunigt durch 

die Parallelisierung den Systemstart. 

Der System-V-Init-Ersatz ist jedoch kein 

Allheilmittel: Je nachdem, wie die Jobs 

voneinander abhängen, muss Upstart im 

schlimmsten Fall doch wieder stur einen 

nach dem anderen abarbeiten. 

Upstart befindet sich immer noch in der 

Entwicklung. Mit jeder neuen Version 

und jedem Ubuntu-Release kommen 

starting job 

started job 

stopping job 

stopped job 

pre-start 

exec 

post-start 

Dienst läuft 

pre-stop 

kill-Signal 

post-stop 

Zeit 

Abbildung 6: Der Lebenslauf eines Jobs: In der 

linken Spalte stehen die Ereignisse, rechts die von 

Upstart ausgeführten Aktionen. 


neue Funktionen oder kleinere Verbesserungen 

hinzu. In Zukunft soll es beispielsweise 

auch Ereignisse zeitgesteuert 

auslösen und somit gleichzeitig die 

Aufgaben von »cron« übernehmen. Die 

Entwickler von Upstart weisen deshalb 

auch ausdrücklich darauf hin, dass sich 

der Aufbau der Konfigurationsdateien 

durchaus noch ändern kann – was auch 

laufend geschieht. So kam in Version 

1.3 das Schlüsselwort »kill signal« hinzu, 

mit dem man in einer Job-Datei das SIG- 

TERM-Signal abfangen kann. 

Den aktuellen Entwicklungsstand findet 

man auf der Launchpad-Seite [2], die 

Upstart-Homepage zeigte bei Redaktionsschluss 

immer noch auf die veraltete 

Version 0.6.7 [1]. Wer eigene Jobs schreiben 

oder tiefer in ihre Programmierung 

einsteigen möchte, sollte unbedingt das 

ausführliche Cookbook studieren [3]. Es 

enthält viele wertvolle Tipps sowie Standardlösungen 

für häufig auftauchende 

Probleme und Fragen. 

Auf Upstart trifft man im Moment lediglich 

in Ubuntu, seinen offiziellen Derivaten 

(wie Kubuntu), den direkt darauf 

aufbauenden Distributionen, wie Linux- 

Mint, im bereits erwähnten RHEL 6 und 

in Googles Chromium OS. Die Tage in 

RHEL dürften allerdings gezählt sein, ist 

doch Fedora seit Version 15 auf den Konkurrenten 

»systemd« umgestiegen [4]. 

Ihn favorisieren auch viele Distributionen. 

Da Canonical sein eigenes Baby sehr 

wahrscheinlich nicht verstoßen wird, 

dürfen sich Administratoren zukünftig 

wohl mit gleich mehreren Init-Varianten 

herumschlagen. (ofr) 

n 

Infos 

[1] Upstart: [http:// upstart. ubuntu. com/] 

[2] Upstart auf Launchpad: 

[https:// launchpad. net/ upstart] 

[3] Upstart Cookbook: 

[http:// upstart. ubuntu. com/ cookbook/] 

[4] Systemd: [http:// freedesktop. org/ wiki/ 

Software/ systemd] 

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. 

CALL 

FOR 

PAPERS 

BIS 31.01. 

Die Konferenz zum Thema Einsatz 

von Open Source Software in Rechenzentren 

und großen IT Umgebungen. 

Schwerpunktthema 2012: 

AGILE INFRASTRUCTURES 

wwww.netways.de/osdc 

presented by 

NETWAYS ® 


117

Basics 

Einführung in LVM 

© svl861, 123RF 


Tortenstück 

Feste Partitionen auf Linux-Systemen lassen sich mit Tools wie Fdisk 

schnell erstellen, erscheinen aber immer im schlechtestmöglichen 

moment auf einmal falsch aufgeteilt oder zu klein. LVM verursacht bei der 

Installation ein wenig mehr Aufwand, der sich bald auszahlt. Charly Kühnast 

Wenn auf einem klassisch partitionierten 

System der Platz in einer Partition knapp 

wird, hat der Admin zunächst zwei Möglichkeiten. 

Er kann einen weiteren Datenträger 

auf einem neuen Mountpunkt 

einbinden und sich damit abfinden, dass 

er seine Pfade anpassen oder mit Alias- 

Konstruktionen arbeiten muss. Oder er 

ersetzt die Platte(n) durch größere und 

spielt ein Backup des Gesamtsystems 

auf die neuen Datenträger ein. Bei dieser 

Vorgehensweise steht das System für 

eine längere Zeit nicht zur Verfügung, 

und die Wahrscheinlichkeit ist hoch, dass 

auch die neuen Platten irgendwann wieder 

zu klein sind. LVM eröffnet einen 

Ausweg aus diesem Dilemma. Es legt 

sich als logische Schicht zwischen die 

physischen Datenträger oder Partitionen 

und das Dateisystem. 

Bevor dieser Artikel das an einem praktischen 

Beispiel demonstriert, lernen Sie 

die wichtigsten Begriffe der LVM-Welt 

kennen. Physical Volumes (PVs) sind 

Block-Devices, also eine ganze Festplatte 

oder eine Partition. Damit LVM ein PV 

nutzen kann, muss es mit einem Befehl 

initialisiert werden, den wir gleich kennenlernen 

werden. Dabei wird ein LVM- 

Label und einige Metadaten auf das PV 

geschrieben. Das PV wird dabei in gleich 

große Einheiten unterteilt (4 MByte per 

Default), die Physical Extents (PE) heißen. 

Ein PE stellt die kleinstmögliche allokierbare 

Datenmenge dar. Abbildung 1 

zeigt die Zusammenhänge grafisch. 

Wenn ein oder mehrere Physical Volumes 

existieren, können Sie daraus eine 

Volume Group (VG) erstellen. Auch sie 

besteht aus vielen kleinen Einheiten, den 

Logical Extents. In der Volume Group 

können die Logical Extents auf Physical 

Extents verweisen, die auf unterschiedlichen 

physischen Datenträgern liegen – 

genau diese Fähigkeit macht die Flexibilität 

und den Charme von LVM aus. 

Die fertige Volume Group ist der Speicherplatz-Pool, 

aus dem Sie später den 

Platz für Ihre logischen Partitionen (Logical 

Volumes, LV) schöpfen werden. Ein 

Logical Volume wird mit einem Dateisystem 

formatiert und steht dann dem 

Betriebssystem zur Verfügung. 

Die Befehle für die Arbeit mit den drei 

Ebenen PV, VG und LV sind konsequent 

nach dem gleichen Schema benannt, 

etwa »pvcreate«, »vgcreate«, »lvcreate« 

oder »pvscan«, »vgscan« und »lvscan«. 

Ein praktisches Beispiel 

Das Beispiel-System hat zwei Festplatten 

(oder SSDs, für LVM ist das unerheblich) 

zu je 100 GByte. Sie hören auf »/dev/ 

sda« und »/dev/sdb«. Auf »/dev/sda« 

sind drei Partitionen angelegt. Die erste, 

»sda1«, wird für den Auslagerungsspeicher 

(Swap) genutzt und ist fünf GByte 

groß. Das Wurzel-Dateisystem »/« liegt 

auf »sda2« und bekommt 20 GByte. Die 

restlichen 75 Gigabyte bekommt die Partition 

»sda3«. Sie soll per LVM mit der gesamten 

zweiten Festplatte »sdb« zusammengefasst 

werden. Das so entstandene 

Logical Volume mit einer Größe von 175 

GBbyte soll dem System unter »/backup« 

zur Verfügung gestellt werden. 

Wichtig ist, dass auf den Platten oder 

Partitionen, die LVM benutzen soll, noch 

kein Dateisystem angelegt ist. Ist das der 

Fall, müssen Sie es zunächst mithilfe von 

»fdisk« wieder entfernen. Jetzt bereiten 

Sie mit dem Kommando »pvcreate« die 

Partitionen »/dev/sda3« und »/dev/sbd« 

für die Benutzung mit LVM vor: 

pvcreate /dev/sda3 /dev/sdb 

Im Erfolgsfall antwortet das System mit: 

Physical volume "/dev/sda3" successfullyU 

created 

Physical volume "/dev/sdb" successfullyU 

created 

Wenn an dieser Stelle etwas schiefgeht, 

liegt es fast immer daran, dass bereits ein 

Dateisystem auf der Partition existiert. 

Der Befehl »pvscan« gibt eine Liste aller 

Physical Volumes aus (Listing 1). 

Wer mehr Details sehen möchte, benutzt 

den Befehl »pvdisplay«. Er liefert zusätzlich 

Informationen über die Anzahl der 

Physical Extents, wie viel Platz die Metadaten 

belegen, die UUID und mehr. 



Basics 

Im nächsten Schritt fassen Sie die frisch 

erstellten Physical Volumes zu einer Volume 

Group zusammen, das Kommando 

dazu lautet – wenig überraschend – 

»vgcreate«. 

vgcreate vg_backup /dev/sda3 /dev/sdb 

Vgcreate erwartet als ersten Parameter 

den Namen der Volume Group, den 

Sie frei wählen können – jedenfalls in 

gewissen Grenzen. Auf Umlaute und 

exotische Sonderzeichen sollte man verzichten, 

Binde- und Unterstriche sind 

aber erlaubt. Nach dem Namen folgen 

in beliebiger Reihenfolge die Bezeichner 

der Physical Volumes, die der neuen Volume 

Group hinzugefügt werden sollen. 

Analog zu den Befehlen »pvscan« und 

»pvdisplay«, die Sie schon kennengelernt 

haben, können Sie sich mit »vgscan« und 

»vgdisplay« Informationen über die Volume 

Groups anzeigen lassen. 

Aus dem Platz, den die Volume Group 

bietet, können Sie nun ein oder mehrere 

Logical Volumes anlegen – im Beispiel 

soll es ein einziges LV ein, das den Namen 

»lv_backup« erhalten soll, mit einer 

Größe von 170 GByte. Die vollen 175 

GByte stehen nicht zur Verfügung, weil 

LVM etwas Platz für seine Verwaltungsinformationen 

benötigt. 

lvcreate ‐L 170G ‐n lv_backup vg_backup 

Und selbstredend gibt es auch auf dieser 

Ebene auskunftsfreudige Helferlein, 

nämlich »lvscan« und »lvdisplay«. Der 

letzte Schritt besteht im Anlegen eines 

p 

PE 

PE 

v 

PE 

PE 

1 2 N-1 N 

Dateisystems. In diesem Beispiel soll Ext4 

zum Einsatz kommen: 

mkfs ‐t ext4 /dev/vg_backup/lv_backup 

Das Dateisystem können Sie jetzt mounten 

und sofort benutzen. Damit das 

Ganze auch reboot-fest ist, tragen Sie es 

aber besser in die Datei »/etc/fstab« ein. 

/dev/vg_backup/lv_backup /backup 

ext4 errors=remount‐ro 0 1 

Mehr Platz 

Irgendwann reichen die 170 GByte nicht 

mehr aus, eine Erweiterung steht an. Sie 

bauen also eine weitere Platte ein – im 

Beispiel soll sie 500 GByte groß sein – 

und nutzen LVM, um den zusätzlichen 

Plattenplatz unterbrechungsfrei zur Verfügung 

stellen zu können. 

Die folgenden Schritte sind in der Praxis 

erprobt und erfahrungsgemäß unproblematisch, 

ein aktuelles Backup zu haben, 

ist aber immer eine gute Idee. Das neue 

Laufwerk, es heißt »/dev/sdc«, muss zunächst 

für LVM initialisiert werden: 

pvcreate /dev/sdc 

Danach fügen Sie es zur bereits exisitierenden 

Volume Group »vg_backup« 

hinzu. Dazu benutzen Sie den Befehl 

»vgextend« (extend = erweitern): 

vgextend vg_backup /dev/sdc 

Mit dem Kommando »vgdisplay« können 

Sie sich davon überzeugen, dass die Er 

U 

weiterung der Volume Group geklappt 

hat: 

vgdisplay ‐v vg_backup 

Das Logical Volume und das Dateisystem 

wissen davon aber noch nichts. Dem 

Logical Volume fügen Sie den frischen 

Speicherplatz mit 

lvextend ‐L 500G /dev/vg_backup/lv_backup 

hinzu. Zuletzt kommt das Filesystem an 

die Reihe. Zum Glück lassen sich die 

meisten modernen Dateisysteme im laufenden 

Betrieb vergrößern. Für Ext4 erledigt 

das der Befehl 

resize2fs /dev/vg_backup/lv_backup 

Wenn der Befehl, wie hier, ohne weitere 

Parameter angegeben wird, vergrößert er 

das Filesystem auf die maximale Größe, 

die das logische Volume hergibt. 

Ausblick 

Dieser Workshop hat gezeigt, wie man 

mithilfe von LVM recht einfach Volumes 

anlegen kann, die sich online vergrößern 

und verkleinern lassen. Das verschafft 

dem professionellen Administrator die 

nötige Flexibilität, um wachsenden Datenmengen 

im lokalen Storage oder auf 

dem Server gewachsen zu sein. In einer 

weiteren Folge zu LVM wird es um Snapshots 

gehen, die den aktuellen Zustand 

des Speichers sichern. (ofr) 

n 

Infos 

[1] LVM Howto: 

[http:// www. tldp. org/ HOWTO/ LVM‐HOWTO] 

[2] Mailingliste zu LVM: [http:// www. redhat. 

com/ mailman/ listinfo/ linux‐lvm] 

Physical Volume 

Volume Group 1 

... Volume Group Z 

Physical Volume 1 

Physical Volume X 

PE 

PE 

PE 

PE 

1 2 N-1 N 

/root 

/home ... /var 

Logical Volume 1 

Logical Volume 2 

Logical Volume Y 

Abbildung 1: Physical und Logical Volumes sind die Elemente, aus denen Volume Groups aufgebaut sind. 

(Quelle: Blacknova/Wikipedia) 

PE 

PE 

PE 

PE 

1 2 N-1 N 

Der Autor 

Charly Kühnast administriert Unix-Betriebssysteme 

im Rechenzentrum Niederrhein in Moers. 

Zu seinen Aufgaben gehören die Sicherheit und 

Verfügbarkeit der Firewalls und der DMZ. Im heißen 

Teil seiner Freizeit frönt er dem Kochen, im 

feuchten Teil der Süßwasser-Aquaristik und im 

östlichen lernt er Japanisch. 

Listing 1: »pvscan« 

01 PV /dev/sda3 lvm2 [74.59 GB] 

02 PV /dev/sdb lvm2 [98.36 GB] 

03 Total: 2 [172.85 GB] / in use: 0 [0 ] / in no 

VG: 2 [172.85 GB] 


Admin 


119

Programmieren 

Expect 

© Manav Lohia, 123RF 

Skripting mit Expect und Tcl 

Ferngesteuert 

Für interaktives Skripting eignet sich die Tcl-Bibliothek Expect besonders gut. Damit lassen sich zum Beispiel 

virtuelle Maschinen in der Cloud, Atomuhren oder SSH-Sessions fernsteuern, wie dieser Artikel zeigt. Æleen Frisch 

Auch wenn sich mit der Bash oder anderen 

Unix-Shells viele Skripting-Aufgaben 

erledigen lassen, stößt man schnell 

an Grenzen, wenn ein Skript mit einem 

Kommandozeilenprogramm interagieren 

soll. Zum Beispiel sind viele Password- 

Prompts, etwa ein SSH-Login, so konfiguriert, 

dass sie nur Eingaben von einem 

Terminal verarbeiten. Auch die Ausgabe 

von Programmen zu verarbeiten, erfordert 

einiges an Anstrengung, wenn es 

sich um eine interaktive Session handelt. 

Das Expect-Tool ist dagegen extra dafür 

gemacht, interaktive Prozesse zu automatisieren 

[1], [2]. Die auf Expect basierenden 

Programme sind sogenannte 

Chat-Skripts, die aus einer Reihe von 

Prompt-Antwort-Paaren bestehen. Expect 

basiert auf der Skriptsprache Tcl 

und wurde von Don Libes geschrieben. 

Verfügbar ist es für die meisten Linuxund 

Unix-Varianten. Selbst für Windows 

gibt es einen Port [3]. 

Als einfaches Beispiel für die Anwendung 

von Expect soll ein Skript dienen, 

das eine SSH-Verbindung zu einem Host 

aufbaut, den man auf der Kommandozeile 

als Argument übergibt. Die erste 

Zeile des Skripts in Listing 1 ist das Tcl- 

Konstrukt, das der Variablen »host« mit 

»set« einen Wert zuweist. Das Gebilde 

in eckigen Klammern extrahiert mit dem 

Tcl-Kommando »lindex« aus dem Array 

»$argv« den ersten Wert (die Zählung 

startet bei Null). Die folgende Zeile weist 

der Variablen »timeout« den Wert 5 zu. 

Es handelt sich dabei um eine von Expect 

automatisch verwendete Variable, 

die festlegt, wie lange das Skript auf eine 

Eingabe wartet. 

Der Rest des Listings zeigt spezielle Expect-Schlüsselwörter, 

die in den meisten 

solcher Skripte vorkommen. Die drei 

Wichtigsten davon sind: 

n »spawn«: Startet ein Kommando und 

etabliert Ein- und Ausgabeverbindungen 

damit. 

n »expect«: Der namensgebende Befehl 

des Expect-Tools. Wartet darauf, dass 

in der Ausgabe des Befehls die angegebene 

Zeichenkette auftritt oder bis der 

als Timeout vorgegebene Zeitspanne 

verstrichen ist. Alles, was vor der gesuchten 

Zeichenkette auftritt, wird 

ignoriert, es genügt also meist, nach 

den letzten typischerweise auftretenten 

Zeichen einer Programmausgabe 

zu suchen. Der Default-Wert für den 

Timeout ist zehn Sekunden, der Wert 

»‐1« schaltet den Timeout ab. 

n »send«: Schickt eine Zeichenkette an 

den gestarteten Prozess. 

In Listing 1 versucht Zeile 5 per SSH eine 

Verbindung zum Rechner »$host« aufzubauen. 

Das folgende »expect« wartet 

auf die Zeichenkette »(yes/no)?«, die das 

Ende der Ausgabe von SSH beim Austausch 

der Schlüssel anzeigt. Zeile 7 antwortet 

daraufhin mit »yes« und dem Return-Zeichen. 

Im nächsten Schritt wartet 

das Skript auf die Ausgabe »password:«, 

dessen Erscheinen es mit dem Password 

plus Return-Zeichen quittiert (Zeile 10). 

Schließlich wartet es auf den Prompt der 

Shell auf dem entfernten Rechner, hier 

ein Dollar-Zeichen (Zeile 11). Ist es gefunden, 

übergibt das Skript die Kontrolle 

per »interact« an den Benutzer. Der Ablauf 

des Skripts ist in Abbildung 1 zu 

sehen. 

Interessant ist hier der Unterschied der 

beiden »expect«-Kommandos. Im ersten 

Fall (Listing 1, Zeile 7), ist ihm ein Block 


Expect 

Programmieren 

mit dem Send-Befehl untergeordnet. Er 

wird nur dann ausgeführt, wenn das 

Expect-Statement auch den gesuchten 

String findet. Taucht er während des 

Timeout-Zeitraums nicht auf, wird auch 

das Send nicht ausgeführt. Im Gegensatz 

dazu, führt das Skript das zweite Send 

in Zeile 10 auf jeden Fall aus, auch wenn 

nie ein Passwort-Prompt erscheint. Eine 

Expect-Anweisung ist folgendermaßen 

aufgebaut: 

expect { 

item1 { 

statements 

} 

item2 { 

statements 

} 

... 

} 

Die geschweiften Klammern nach dem 

Schlüsselwort »expect« sind nur dann nötig, 

wenn man auf mehr als eine Zeichenkette 

warten will. Beispiele dazu zeigt 

dieser Artikel weiter unten. Die Suche 

nach den Strings findet üblicherweise in 

der Reihenfolge statt, in der sie aufgeführt 

sind. Beim ersten passenden wird dann 

der dazugehörige Block ausgeführt. 

Das nächste Beispiel soll eine virtuelle 

Maschine in Amazons Cloud konfigurieren 

und dabei passwortlose Logins für 

den Default-User »ec2‐user« wie auch für 

den Root-Acount ermöglichen. Das Expect-Skript 

schickt dazu den Public Key 

des aktuellen Users an den Amazon-Host 

und fügt ihn dort der Datei »~/.ssh/ 

authorized_keys« beider Accounts hinzu. 

Zusätzlich ändert es die SSH-Konfiguration, 

sowohl des Root-Accounts wie auch 

der globalen Konfiguration des Daemons, 

den es außerdem noch neu startet. Hat 

alles geklappt, verlangen weder »ssh« 

noch »scp« in Zukunft nach Passwort 

oder ‐phrase. 

Login mit Zertifikat 

Das Expect-Skript heißt »ec2_ssh_init«, 

der erste Teil davon ist in Listing 2 zu sehen. 

Als Erstes speichert es das erste Argument 

des Aufrufs in der Variablen »h«. 

Es startet einen »scp«-Prozess und wartet 

auf dessen Ausgabe. Mit dem Schalter 

»‐i« verwendet der Befehl zur Authentifizierung 

gegenüber der Amazon-Instanz 

die dazugehörige Schlüsseldatei »AEF. 

pem«. Als Nächstes wartet das Skript auf 

den SSH-Schlüsselaustausch und bestätigt 

ihn mit »yes«. Am Ende schließt es 

die Verbindung und wartet noch einmal 

zehn Sekunden. 

Der in Listing 3 abgedruckte Rest des 

Skripts führt auf der Amazon-Instanz 

eine Reihe von Befehlen aus und öffnet 

dafür zu Beginn eine SSH-Sitzung. Alle 

Expect-Anweisungen warten auf Shell- 

Prompt-Zeichen, entweder des Accounts 

»ec2‐user« oder von Root. Zuerst fügt das 

Skript den Inhalt des kopierten Public- 

Keys der Datei »~/.ssh/authorized_keys« 

hinzu und löscht anschließend den Key. 

Dann öffnet es per »sudo« eine Root- 

Shell und kopiert die Authorized-Keys 

des EC2-Users. Das Skript wechselt 

dann in das Konfigurationsverzeichnis 

des SSH-Servers, macht eine Kopie der 

Konfigurationsdatei und editiert sie mit 

Listing 2: »ec2_ssh_init« (Teil 1) 

01 #!/usr/bin/expect 

02 

03 set h [lindex $argv 0] 

04 spawn /usr/bin/scp ‐i /home/aefrisch/.ec2/AEF.pem 

/home/aefrisch/.ssh/id_rsa.pub ec2‐user@${h}: 

05 expect "(yes/no)? " 

06 send "yes\r" 

07 expect "known hosts" 

08 close 

Listing 1: Automatisches SSH-Login 


02 

03 set host [lindex $argv 0] 

04 set timeout 5 

05 spawn /usr/bin/ssh aefrisch@$host 

06 expect "(yes/no)? " { 


08 } 

09 expect "password:" 

10 send "secret\r" 

11 expect "$" 

12 interact 

09 sleep 10 

Listing 3: »ec2_ssh_init« (Teil 2) 

01 spawn /usr/bin/ssh ‐i /home/aefrisch/.ec2/AEF.pem 

ec2‐user@$h 

02 expect "$" 

03 send "cat id_rsa.pub >> .ssh/authorized_keys; rm 

id_rsa.pub\r" 

04 expect "$" 

05 send "sudo tcsh\r" 

06 expect "#" 

07 send "cp .ssh/authorized_keys ~root/.ssh\r" 

08 expect "#" 

09 send "cd /etc/ssh; cp sshd_config{,.0}\r" 

10 expect "#" 

11 send "cat sshd_config.0 | sed -e 's/ 

forced‐commands‐only/yes/' > sshd_config\r" 

12 expect "#" 

13 send "/etc/init.d/sshd restart\r" 

14 expect "#" 

15 send "exit\r" 

Abbildung 1: Automatisiertes Login per SSH und Expect. Kleiner Schönheitsfehler dieser Lösung: Das Passwort 

ist im Klartext im Skript gespeichert. 

16 expect "$" 

17 send "logout\r" 


Admin 


121

Programmieren 

Expect 

01 set done 0 

02 stty ‐echo 

»sed«. Schließlich startet das Skript den 

SSH-Server neu. Der Rest des Skripts beendet 

die Root-Shell, loggt sich aus der 

SSH-Session aus und beendet das Spawn- 

Kommando. 

Dialog mit der Hardware 

Expect kann genauso dafür verwendet 

werden, mit Hardware zu kommunizieren, 

die einen interaktiven Modus besitzt. 

Listing 4 verbindet sich über die 

serielle Schnittstelle mit einer Atomuhr, 

um die aktuelle Zeit auszulesen. Als Erstes 

weist es der Variablen »clock« den 

Namen der seriellen Schnittstelle zu, im 

Beispiel »/dev/ttyS0«. Mit der Spawn- 

Listing 6: Schleife (Teil 2) 

03 while {$done == 0} { 

04 system /usr/bin/clear 

05 system $cmd 

06 stty raw 

07 expect -re "." {set done 1 } 

08 stty ‐raw 

09 } # end while 

10 stty echo 

11 exit 

Listing 5: Schleife (Teil 1) 


02 

03 set cmd [lindex $argv 0] 

04 if {"$cmd" == ""} { 

05 send "Usage: loop command \[refresh\]\n" 

06 exit 

07 } 

Listing 4: Kommunikation mit der Uhr 


02 

03 set clock /dev/ttyS0 

04 spawn ‐open [open $clock r+] 

05 

06 # set line characteristics for talking to clock 

07 stty ispeed 300 ospeed 300 parenb ‐parodd cs7 hupcl 

‐cstopb cread clocal ‐icrnl ‐opost ‐isig ‐icanon 

‐iexten ‐echo ‐noflsh < $clock 

08 

09 send "o" 

10 expect ‐re "." 

11 send "\r" 

12 expect ‐re "." 

13 expect ‐re "(................*)" 

14 exit 

08 set tout [lindex $argv 1] 

09 if {"$tout" == ""} {set tout 5} 

10 set timeout $tout 

Anweisung beginnt dann die Kommunikation 

mit dem Device. Dabei öffnet die 

Tcl-Anweisung »open« die Gerätedatei. 

Das folgende »stty« legt wie das gleichnamige 

Unix-Kommando die Übertragungsparameter 

fest, etwa die Übertragungsgeschwindigkeit, 

Parity-Einstellungen und 

so weiter. 

Der eigentliche Datenaustausch findet in 

den folgenden Send-/Expect-Anweisungen 

statt. Zuerst schickt das Skript ein 

»o« an die Uhr, die darauf mit einem 

Zeichen antwortet. Der Schalter »‐re« der 

Expect-Anweisung zeigt an, dass es sich 

um eine Regular Expression handelt. Expect 

wartet hier also auf ein beliebiges 

Zeichen. Darauf antwortet es seinerseits 

mit einem Return-Zeichen, das die Uhr 

anweist, die Zeit auszugeben. Das tut sie 

mit einem einzelnen Zeichen, das mit 

der Zeit direkt nichts zu tun hat, gefolgt 

von der eigentlichen Zeitangabe. Entsprechend 

enthalten die Expect-Anweisungen 

in den Zeilen 15 und 16 in Listing 4 die 

passenden Regular Expressions. 

Die zweite Regular Expression enthält 

16 Punkte, die jeweils für ein Zeichen 

stehen. Der folgende Stern gibt an, das 

weitere Zeichen optional folgen können. 

Die Klammern um den Ausdruck sind 

keine Zeichen, auf die Expect wartet, 

sondern geben an, dass die gefundene 

Zeichenkette später im Skript verwendet 

wird. Im Beispiel endet das Skript hier, 

aber es gibt automatisch den letzten verwendeten 

Ausdruck, in diesem Fall also 

die gefundene Zeit, aus. 

Alles wie Top 

Das Unix-Komando »top« ist einer dieser 

Befehle, die nicht nur einmal ein Ergebnis 

ausgeben, sondern so lange laufen 

und ihre Daten anzeigen, bis der Anwender 

sie beendet. Die Expect-Anweisung 

»loop« ermöglicht es, jeden beliebigen 

Befehl mit diesen Fähigkeiten auszustatten. 

Sie startet einen Befehl immer wieder 

neu, bis der Anwender ihn mit einem 

Tastendruck beendet. Zu Beginn legt das 

Skript in Listing 5 den auszuführenden 

Befehl und das Zeitintervall fest, in dem 

die Anzeige aktualisiert wird (die hier 

dem Expect-Timeout entspricht). 

An diesem Beispiel kann man sehen, 

wie sich über die If-Anweisung von Tcl 

das Vorhandensein eines Kommandozeilenarguments 

prüfen lässt. Die Send- 

Anweisung gibt eine Fehlermeldung aus, 

wenn das obligatorische Argument fehlt. 

Solange nicht mit Spawn ein Prozess gestartet 

wurde, bezieht sich Send auf die 

Standardein-/ausgabe des Skriptes und 

kann also dafür verwendet werden, Meldungen 

auszugeben. Wie in Zeile 5 zu sehen 

ist, muss man die eckigen Klammern 

in der Ausgabe mit Backslashes escapen, 

weil sie in Tcl sonst eine spezielle Bedeutung 

besitzen. Das zweite Argument 

des Skriptes ist optional und gibt das 

Zeitintervall an, in dem es die Ausgabe 

auffrischt, per Default fünf Sekunden. In 

Zeile 10 wird die Timeout-Variable auf 

diesen Wert gesetzt. 

Geschleift 

Der in Listing 6 abgedruckte Rest des 

Skriptes führt den Kommandozeilenbefehl 

aus und wartet dazwischen auf den 

Tastendruck des Anwenders. Die Variable 

»done« erhält den Wert 0, und vor der 

While-Schleife schaltet Stty die Ausgabe 

ab. Die While-Schleife wird wiederholt, 

solange »done« gleich 0 ist. Im While- 

Block führt Expect mit »system« zwei externe 

Unix-Kommandos aus. Anders als 

»spawn« führt »system« ein Kommando 

aus, ohne die Ein- und Ausgabe zu übernehmen. 

Wird das vom Benutzer spezifizierte 

Unix-Kommando ausgeführt, setzt das 

Skript das Terminal mit Stty in den 

Raw-Mode. Somit verarbeitet es Benutzereingaben 

Zeichen für Zeichen statt 

zeilenweise. Das dazugehörige Expect- 

Statement wartet mit einer Regular Expression 

auf ein beliebiges Zeichen. Tritt 

dieses Ereignis ein, setzt das Skript die 

Variable »done« auf 1, und beim nächsten 

Durchlauf endet die Schleife. Im Fall eines 

Timeouts passiert nichts, und »done« 

bleibt unangetastet. Nach dem Ende der 

While-Schleife setzt das Skript das Terminal 

zurück und endet dann. 

Multipel 

Listing 7 zeigt eine Alternative zum in 

Listing 1 vorgestellten SSH-Skript. Es 

kombiniert die verschiedenen Expect- 

Anweisungen in eine einzige, die auch 

wie eine Schleife funktioniert. Das Skript 

beginnt wie üblich mit der Zuweisung 


Expect 

Programmieren 

einiger Variablen. Außerdem zeigt es, wie 

man eine Umgebungsvariable in einem 

Expect-Skript verwendet: Der Ausdruck 

»$env(NAME)« gibt den Wert der Umgebungsvariable 

»NAME« zurück. So vermeidet 

es das Skript, einen Benutzernamen 

fest zu verdrahten und bezieht ihn 

stattdessen aus der Umgebungsvariablen 

»USER«. Die »expect«-Anweisung umfasst 

vier Blöcke: 

n »(yes/no?)«: Der bekannte Prompt vom 

SSH-Schlüsselaustausch. Wird dieser 

String gefunden, schickt das Skript die 

Antwort »yes« und fährt wegen der 

Anweisung »exp_continue« fort. 

n »word:«: Der Passwort-Prompt, den 

das Skript mit dem Passwort beantwortet. 

Daraufhin gibt das Skript eine 

Meldung aus, in der es darüber informiert, 

dass der Schlüsselaustausch 

noch nicht abgeschlossen ist. Die Anweisung 

»send_tty« gibt den String 

immer am Bildschirm aus, egal wohin 

die Standardausgabe gerade umgeleitet 

ist. Auch hier macht das Skript 

wegen der Anweisung »exp_continue« 

weiter. 

n »(|#|>)«: Eine Regular Expression, die 

drei Varianten eines Shell-Prompts abdeckt. 

Findet das Skript eines dieser 

Zeichen, begibt es sich nicht per »interact« 

in den interaktiven Modus. An 

dieser Stelle endet das Skript dann. 

n »timeout«: Dieses Label wird erreicht, 

wenn in der vorgegebenen Zeit keine 

Antwort vom SSH-Befehl zurückkommt. 

Das Skript gibt eine entsprechende 

Meldung aus und endet. 

Obwohl das eben vorgestellte Expect- 

Skript sehr nützlich ist, weist es ein kleines 

bis mittleres Security-Problem auf: 

Das Passwort steht im Klartext im Skript. 

Das ist im Allgemeinen keine besonders 

gute Idee, und man sollte das Skript wenigstens 

an einem sicheren Ort mit den 

entsprechenden Rechten verstauen. Das 

nächste Skript umgeht dieses Problem. Es 

zeigt, wie man vom Benutzer am Anfang 

ein Passwort einliest und es dann später 

verwendet. 

Listing 8 zeigt den ersten Teil des Skriptes, 

das die Kommandozeilenargumente 

verarbeitet: die auf den anderen Rechner 

zu kopierende Datei und den Usernamen 

auf dem anderen Rechner (im Default- 

Fall Root). Es liest eine Datei namens 

»xferhosts« im aktuellen Verzeichnis ein, 

das eine Liste der Hosts enthält, auf die 

die Datei kopiert werden soll. Dieser 

Code kann als Blaupause dafür dienen, 

mit Tcl Dateien aus einer externen Datei 

zu lesen: 

set file [open "xferhosts" r] 

set hlist [split [read $file] "\n"] 

close $file 

Dann fragt das Skript das Passwort auf 

dem anderen Rechner ab. Dazu schaltet 

»‐echo« die Anzeige der Eingabe aus, 

»echo« entsprechend später wieder ein: 

Listing 7: SSH 


02 

03 set host [lindex $argv 0] 


05 set user [lindex $argv 1] 

06 if {"$user" == ""} { set user $env(USER) } 

07 spawn /usr/bin/ssh $user@$host 

08 expect { 

09 "(yes/no)? " { 


11 exp_continue 

12 } 

13 "word:" { 

14 send "whatever\r" 

15 send_tty "Key exchange needed with $host\n" 


17 } 

18 ‐re "($|%|>) " { 

19 interact 

20 } 

21 timeout { 

22 send_tty "No response from $host\n" 

23 exit 

24 } 

25 } 

Listing 8: Argumente verarbeiten 


02 

03 set xfer [lindex $argv 0] 

04 set user [lindex $argv 1] 

05 if {"$user" == ""} { set user "root"} 

06 if {"$xfer" == ""} { 

07 send_user "Usage: xfer item \[user\]\n" 

08 exit 

09 } 


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 


123

Programmieren 

Expect 

01 #!/bin/bash 

02 

stty ‐echo 

send_tty "_" 

expect_tty "\n" 

set pwd [string trimright "$expect_outU 

(buffer)" "\n"] 

stty echo 

if {$pwd == ""} { exit } 

Die Set-Anweisung, die die Variable 

»pwd« belegt, liest per Tcl den Inhalt 

aus dem Expect-Puffer. Er besteht aus 

allen Zeichen, die Expect von dem vorigen 

Match bis zum aktuellen gelesen 

hat. In diesem Beispiel ist es das, was 

der Benutzer nach dem Passwort-Prompt 

Listing 10: Prompt und Timeout 


02 

03 set prompt [lindex $argv 0] 

04 set response [lindex $argv 1] 

05 set tout [lindex $argv 2] 

06 if {"$prompt" == ""} { 

07 set prompt "Enter response" 

08 } 

Listing 9: Schleife über eine Liste 

01 foreach h $hlist { 

02 if {"$h" != ""} { 

03 spawn scp -r $xfer $user@$h:/tmp 

04 expect { 

05 "(yes/no)? " { 



08 } 

09 "word:" { 

10 send "$pwd\r" 


12 } 

13 ‐re "." { 


15 } 

16 timeout { break } 

17 } 

18 } 

19 } 

09 if {"$tout" == ""} { set tout 5 } 

Listing 11: Anwendung 

03 # Example use of timed prompt script: 

04 # The default response is '"'red'"' 

05 color=`./timed_prompt "What is your favorite color? 

" red 2` 

06 echo "Your color is $color" 

07 echo 

08 color=`./timed_prompt "What is your favorite color? 

" red 20` 

09 echo "Your color is $color" 

eingegeben hat. Das Skript entfernt das 

Newline, das die Eingabe abschließt und 

zuerst noch Teil des Strings ist. 

Listing 9 zeigt die Schleife über die Liste 

der Hosts aus der Datei. Die Tcl-Anweisung 

»foreach« liest einen nach dem 

anderen, die If-Anweisung sorgt dafür, 

dass der Hostname nicht leer ist. Die 

»expect«-Anweisung ist ähnlich zu der im 

letzten Beispiel. Es kümmert sich um den 

Schlüsselaustausch und den Passwort- 

Prompt, wenn sie auftreten, und beendet 

die Schleife mit »break«, wenn das Skript 

zu lange warten muss. 

Der andere Fall in der »expect«-Anweisung 

ist eine Regular Expression, die 

einem beliebigen Zeichen entspricht. 

Das »scp«-Kommando sendet während 

der Arbeit Zeichen. Solange man welche 

empfängt, weiß man also, dass es 

noch läuft. Wenn die Regular Expression 

matcht, läuft exp_continue ab, was die 

Schleife fortsetzt und auch den Timeout 

zurücksetzt. 

Prompt mit Timeout 

Die Bash-Shell bietet einen Weg, Benutzereingaben 

mit »read« einzulesen und 

in einer Variablen zu speichern, wie im 

folgenden Beispiel: 

read ‐p "Prompt string: " answer < /dev/tty 

Ein solcher Prompt wird ewig auf eine 

Eingabe warten. Manchmal will man 

aber nur eine Zeit lang einen Prompt 

anzeigen und dann weitermachen, wenn 

nichts passiert. Expect bietet mit wenig 

Aufwand solche Prompts mit eingebautem 

Timeout. Das zugehörige Skript in 

Listing 10 beginnt wieder damit, die 

Argumente zu verarbeiten. Der Default- 

Prompt ist »Enter response«, der Default- 

Timout fünf Sekunden. Der folgende 

Code zeigt den Teil des Skriptes, der den 

Prompt-String anzeigt und die Benutzereingabe 

verarbeitet, wenn es eine gibt: 

send_tty "$prompt: " 

set timeout $tout 

set response "" 

expect "\n" { 

set response [string trimright "$expect_U 

out(buffer)" "\n"] 

} 

send $response 

Das Skript zeigt den Prompt am Bildschirm 

an, setzt den Timeout-Wert und 

weist der Variablen, die die Antwort 

speichert, einen Anfangswert zu. Die 

»expect«-Anweisung ändert den Wert auf 

die Eingabe des Benutzers. Das Skript 

endet damit, den Antwortwert zurückzugeben. 

Listing 11 zeigt ein Beispiel dafür. Die 

folgenden Zeilen zeigen, wie das Skript 

abläuft, wenn man bei der zweiten Eingabeaufforderung 

einen Wert eingibt, 

nicht aber bei der ersten: 

$ ./use_prompt 

What is your favourite color? 

Your color is red 

What is your favourite color? green 

Your color is green 

Beim ersten Mal gibt das Skript die Default-Farbe 

(rot) aus, im zweiten Fall die 

Farbe, die der Benutzer eingibt. 

Polyglott 

Viele Aufgaben, die ansonsten Benutzerinteraktion 

erfordern, lassen sich mit 

Expect skripten. Gelegentlich ist es nötig, 

ein bisschen mit Timeout-Werten 

zu experimentieren, damit die Skripte 

für echte Anwendungen robust genug 

sind. Neben der reinen Tcl-Variante von 

Expect gibt es auch Implementierungen 

in Python [4], Perl [5], Ruby [6] und 

andere Programmiersprachen. (ofr) n 

Infos 

[1] NIST Expect: 

[http:// www. nist. gov/ el/ msid/ expect. cfm] 

[2] Expect homepage: 

[http:// expect. sourceforge. net] 

[3] Expect für Windows: [http:// docs. 

activestate. com/ activetcl/ 8. 5/ expect4win] 

[4] Python-Expect: [http:// pexpect. 

sourceforge. net/ pexpect. html] 

[5] Perl-Expect: [http:// search. cpan. org/ 

~rgiersig/ Expect‐1. 15/ Expect. pod] 

[6] Ruby-Expect: [http:// www. ruby‐doc. org/ 

stdlib‐1. 9. 3/ libdoc/ pty/ rdoc/ IO. html# 

method‐i‐expect] 

Die Autorin 

Æleen Frisch besitzt mehr als 20 Jahre Erfahrung 

in der Administration von VMS, Unix, Linux und 

Windows. Sie ist die Autorin des Buches „Essential 

System Administration“. Mehr Informationen 

über ihre Bücher, Artikel und Vorträge sind auf 

[http:// www. aeleen. com] zu finden. 


Digitales aBO 

linuxUser: Das Monatsmagazin für die Praxis 

DigisUB * 

nur 56,10 € 

im Jahr (12 PDFs) 

* Digitales Abo, jederzeit kündbar 

Jetzt Bestellen Unter: 

www.linux-user.de/digisub 

Telefon: 07131 /2707 274 

Fax: 07131 / 2707 78 601 

E-Mail: abo@linux-user.de 

Lesen Sie News und Artikel 

fast 1 Woche vor dem Kiosk! 

Sparen Sie im Abo 15% im 

Vergleich zum PDF-Einzelkauf! 

Nutzbar auf Notebook und 

PC, Tablet oder Smartphone!

Programmieren 

Perl-Curses 

Textbasierte GUI mit Perl 

Old School 

© frannyanne, 123RF 

Es muss nicht immer eine Webanwendung sein. Manchmal ist es am einfachsten, ein interaktives Programm für 

das Textterminal zu schreiben. Auf Komfort muss man dabei nicht unbedingt verzichten. Oliver Frommel 

Auch wenn man es sich kaum noch 

vorstellen kann: Es gibt noch Software, 

die nicht im Webbrowser läuft. Wer 

selbst ein kleines Programm schreiben 

will, um beispielsweise Daten in eine 

Datenbank einzutragen, kommt auf der 

Kommandozeile oft schneller voran. Eine 

vollständige Webanwendung mit Fehlerbehandlung 

zu schreiben, gerät schneller 

als man denkt zu einem mittleren Projekt. 

Da helfen auch keine Frameworks 

wie Ruby on Rails oder Symfony, die 

noch dazu einiges an Einarbeitungszeit 

erfordern. 

Curses 

Wer dennoch in einem Terminal interaktive 

Programme schreiben will, greift mit 

der Programmiersprache C meistens auf 

die Ncurses-Bibliothek zurück, von der 

es auch Varianten für Skriptsprachen wie 

Perl, Python oder Ruby gibt. Besonders 

komfortabel lassen sich textbasierte „grafische“ 

Oberflächen mit dem Perl-Modul 

Curses::UI schreiben, das basierend auf 

Curses klassische GUI-Elemente wie Buttons, 

Dialoge und Fenster bietet. 

Fertige Pakete gibt es für die meisten 

Linux-Distributionen. Auf Debian und 

Ubuntu installieren Sie Curses::UI mit 

»apt‐get install libcurses‐ui‐perl«, Fedorasowie 

Red-Hat- und CentOS-Anwender tippen 

stattdessen »yum install perl‐Curses‐ 

UI« ein. Auf letzteren Systemen müssen 

Sie eventuell noch ein Third-Party-Repository 

wie Repoforge [2] einbinden, 

wenn das Paket in der Kerndistribution 

fehlt. Unix-Fans mit Mac OS X können 

das Perl-Modul beispielsweise mit Macports 

und »sudo port install p5‐curses‐ui« 

installieren. 

Um das Modul in eigenen Perl-Skripten 

zu verwenden, genügt zu Beginn des 

Skripts die Zeile: 

use Curses::UI; 

Die folgende Anweisung erzeugt eine Instanz 

des UI-Objekts, das als Handle für 

alle weiteren Aktionen dient: 

$ui = new Curses::UI( ‐color_support => 1 ); 

In farbfähigen Terminals (meist mit 

ANSI-Farbcodes angesteuert) schaltet der 

Parameter »‐color_support« die Farbunterstützung 

der Bibliothek ein. 

Wie häufig bei GUI-Bibliotheken wird 

die Benutzeroberfläche hierarchisch aufgebaut. 

Man hängt also beispielsweise 

ein Fenster-Element an das UI-Element 

an. Das Fenster-Element kann als Kinder 

weitere sogenannte Widgets enthalten, 

beispielsweise Container als Ordnungselemente 

zur Gruppierung oder gleich 

sichtbare Bestandteile wie Buttons oder 

Auswahllisten. 

Ein Fenster beispielsweise fügen Sie so 

der GUI hinzu und weisen es direkt einer 

Variablen zu: 

$window = $ui‐>add( 

'window1', 'Window', 

‐border => 1, 

); 

Der erste Parameter gibt eine ID an, über 

die sich das Fenster später im GUI-Baum 

wiederfinden lässt, danach folgt der Typ 

des Widgets, hier eben »Window«. Der 

Parameter »‐border« auf 1 (True) gesetzt, 

verschafft dem Fenster einen sichtbaren 

Rand. 

Wer die obigen Anweisungen in ein 

Skript einfügt und ausführt, bekommt 

eine Fehlermeldung zu sehen, aber auch 


Perl-Curses 

Programmieren 

G Abbildung 2: Curses::UI unterstützt UTF-8 und in modernen Terminalfenstern 

auch Farben. 

F Abbildung 1: Ein simples Programm mit Curses::UI umfasst nur wenige Zeilen, 

bietet aber immerhin ein eigenes Fenster und einen Dialog. 

nicht das gewünschte Ergebnis. Es fehlt 

nämlich noch der für GUI-Anwendungen 

typische Event-Loop, in dem das Programm 

verweilt und Benutzer-Eingaben 

verarbeitet. Curses::UI bietet dazu die 

Methode »mainloop()«: 

$ui‐>mainloop(); 

Bevor Sie das Programm starten, sollten 

Sie aber noch an den Ausstieg denken, 

denn mit dem bei Skripten sonst funktionierenden 

[Strg]+[C] kommen Sie 

hier nicht weiter. Am besten setzen Sie 

in jedem Programm eine Tastenzuweisung 

ein, mit der Sie es beenden können, 

etwa: 

$ui‐>set_binding( sub{ exit; } , "\cQ"); 

Das erste Argument der Methode »set_ 

binding« ist eine Referenz auf eine Perl- 

Funktion, die beim Tastendruck ausgeführt 

werden soll, etwa »\&myfunction«. 

Hier ist stattdessen einfach eine anonyme 

Funktion mit »sub« direkt definiert. Die 

Tastenkombination, die als zweiter Parameter 

folgt, entspricht hier [Strg]+[Q]. 

Text geben Sie beispielsweise über das 

UI-Element »Label« aus. Hängen Sie es 

einfach an das Window-Objekt an und 

übergeben Sie den Text als Parameter. Die 

meisten anderen Parameter sind optional 

und legen unter anderem fest, ob der Text 

fett oder unterstrichen erscheinen soll: 

$window‐>add( 

'label1', 'Label', 

‐text => 'Hier der Text', 

); 

Ein Label verarbeitet wie alle anderen 

Elemente auch Standard-Optionen, die es 

von der Widget-Klasse erbt, von der alle 

Elemente abgeleitet sind. Dazu gehören 

unter anderem Breite »‐width« und Höhe 

»‐height« sowie die Position innerhalb 

An die Antwort gelangt man wieder 

über den Return-Wert, wie die obige 

Zeile zeigt. Zur verdeckten Eingabe 

von Passwörtern gibt es übrigens eine 

eigene Widget-Klasse namens »PasswordEntry«. 

Neben den einfachen Dialogen 

bietet Curses::UI auch einen Datei- 

Browser, einen Progress-Bar und sogar 

einen Kalender! 

Komplexere Daten werden in grafischen 

Oberflächen meist in Dropdown- oder 

ähnlichen Listen angezeigt. Auch hier 

muss das kleine Perl-Modul nicht pasdes 

umgebenden Containers in Form von 

X- und Y-Koordinaten, die sich auf die 

linke obere Ecke des jeweiligen Elements 

beziehen und die mit »‐x« und »‐y« angegeben 

werden. 

Leerer Platz innerhalb und außerhalb des 

Widgets wird mit Padding-Werten angegeben. 

So legt »‐pad« den Wert für alle 

Achsen fest, »‐padright« für die rechte 

Seite, »‐padbottom« für den unteren Rand 

und so weiter. Analog verhält es sich mit 

der Innenseite, deren Werte entsprechend 

»‐ipad«, »‐ipadright«, »‐ipadleft« und so 

weiter heißen. 

Im Dialog 

Weil Dialoge zur Interaktion mit dem Anwender 

recht häufig vorkommen, bietet 

Curses::UI hierfür eigene Methoden an, 

und zwar gleich eine ganze Palette davon. 

Im einfachsten Fall »Dialog::Basic« 

handelt es sich nur um einen Dialog, den 

der Anwender mit einem Button bestätigen 

muss. Mit nur einer Zeile mehr lässt 

sich so das obige Programm mit einem 

Abschiedsdialog versehen: 

$ui‐>dialog(‐message => 'Goodbye!'); 

Das komplette Listing mit Fenster, Text 

und Dialog ist in Abbildung 1 zu sehen. 

Abbildung 2 zeigt das Resultat. 

Listing 1: Label 

01 $labels{1} = 'Red Hat Enterprise Linux'; 

02 $labels{2} = 'CentOS'; 

03 $labels{3} = 'Open Suse'; 

04 $labels{4} = 'Suse Linux Enterprise 

Server'; 

05 $labels{5} = 'Gentoo'; 

06 $labels{6} = 'Mandriva'; 

07 $labels{7} = 'Fedora'; 

08 $labels{8} = 'Solaris'; 

09 $labels{9} = 'FreeBSD'; 

10 $labels{10} = 'Solaris'; 

Für mehr als eine Antwort, zum Beispiel 

die klassische Auswahl zwischen OK 

und Cancel, übergeben Sie als Parameter 

ein Array mit den gewünschten Buttons, 

etwa so: 

‐buttons 

=> ['OK', 'Cancel'] 

Um herauszufinden, welchen Button 

der Anwender gedrückt hat, lesen Sie 

den Return-Wert aus, also » $return = 

$ui‐>dialog(...)«. 

Manchmal ist es aber nötig, statt einer 

einfachen Auswahl den Benutzer einen 

Wert eingeben zu lassen, zum Beispiel 

einen String oder eine Zahl. Dafür bietet 

Curses::UI die Klasse »Dialog::Question«. 

Sie wird folgendermaßen verwendet: 

$username = $ui‐>question('Benutzername:'); 

11 $labels{11} = 'SmartOS'; 

12 $labels{12} = 'Plan 9'; 

13 

14 $listbox = $win‐>add( 

15 'mylistbox', 'Listbox', 

16 ‐values => [1, 2, 3, 4, 5, 6, 7, 8, 

9, 10, 11, 12], 

17 ‐labels => \%labels, 

18 ‐multi => 1, 

19 ‐height => 12 

20 ); 


Admin 


127

Programmieren 

Perl-Curses 

sen. Mit dem Listbox-Widget lassen sich 

Listen anzeigen, aus denen der Anwender 

auswählen kann. Wie bei GUIs und 

auf HTML-Seiten üblich, erlaubt auch 

Curses::UI die Funktionen Einfach- oder 

Mehrfachauswahl. Die ausgewählten 

Werte übergeben Sie dem Label-Objekt 

als Array, die optionalen Label als Hash. 

Ein Beispiel dafür ist in Listing 1 zu sehen. 

Natürlich könnten Array und Hash 

die Indizierung auch bei 0 starten. 

Der Schalter für die Mehrfachauswahl 

heißt »‐multi«, wie in Listing 1 zu sehen 

ist, die Einfachauswahl legt stattdessen 

»‐radio« fest. 

Menüs 

Wer will, kann der eigenen Curses::UI- 

Anwendung auch ein komplettes Menü 

spendieren, das sich auf modernen Systemen 

sogar meistens mit der Maus bedienen 

lässt. Dazu bauen Sie erst ein 

Menü aus einer Datenstruktur auf, in 

der ein Menü aus einem Array besteht, 

in dem Untermenüs als Arrayreferenzen 

eingebunden werden. Diese Datenstruktur 

übergeben Sie dann dem Konstruktor 

für die Klasse »Menubar«: 

$ui‐>add( 

'menu', 'Menubar', 

‐menu => $menu_data 

); 

Ein Beispiel für die Datenstruktur findet 

sich in der Dokumentation der Menubar- 

Klasse. Damit ein Menü ausklappt, muss 

es aktiviert werden, im Curses::UI-Jargon 

den sogenannten Focus erhalten. Dafür 

bietet sich zum Beispiel ein Hotkey an, 

den Sie etwa so festlegen: 

$ui‐>set_binding(sub {$menu‐>focus()}, U 

"\cM"); 

Die Aufzählung der enthaltenen Widgets 

ließe sich noch eine Zeit lang fortsetzen, 

so gibt es sogar ein GUI-Element, das 

Texteditor-Funktionen samt Scrollbars 

und so weiter bietet. Eine vollständige 

Liste finden Sie in der Curses::UI-Dokumentation. 

Doku-Suche 

Dokumentation für Perl-Curses::UI ist 

dünn gesät. Neben der offiziellen CPAN- 

Dokumentation gibt es nur noch einen 

Vortrag von Marcus Thiesen mit einem 

Überblick über das Modul [3] und vereinzelte 

Mailinglisten-Beiträge. Lohnenswert 

ist ein Blick in das Verzeichnis 

»examples« der Quellcode-Distribution, 

das für alle GUI-Elemente ausführliche 

und verständliche Beispiele enthält. n 

Infos 

[1] Curses::UI: 

[http:// search. cpan. org/ dist/ Curses‐UI] 

[2] Repoforge: [http:// repoforge. org/ use] 

[3] Curses::UI – Eine Einführung: [http:// perl. 

thiesen. org/ talks/ curses‐ui. pdf] 



Online-Archiv 

Rund 2.000 Seiten Artikel, 

Studien und Workshops aus 

fünf Jahren Technical Review 

+ 

nur 

4,-e* 

im Monat 

Onlinezugriff auf alle 

Heftartikel aus dem 

ADMIN-Magazin 

der Jahrgänge 

2009 bis 2011! 

Volltextsuche 

Praxisrelevante Themen 

für alle IT-Administratoren 

* Angebot gültig nur 

für Abonnenten eines 

Print- oder vollen 

digitalen ADMIN Abos 

Bestellen Sie unter: www.admin-magazin.de/archiv 


Alles zum ThemA 

Android 

Neu! 

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

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

ihre Vorteile: 

+ News und Artikel 

fast 1 Woche vor 

dem Kiosk lesen! 

+ Hardware und App- 

Tests, Workshops, 

Tipps und Tricks für 

Anfänger und Profis! 

+ Nutzbar auf Smartphone, 

Tablet oder 

Notebook/PC! 


www.android–user.de/digisub 

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

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 

Chefredakteure 

Redaktion 

News/Report 

Software/Test 

Security/Networking 

Ständige Mitarbeiter 

Produktionsleitung 

Grafik 

Abo-Infoseite 

Abonnenten-Service 

Brian Osborn (Vorstand), bosborn@linuxnewmedia.de 

Hermann Plank (Vorstand), hplank@linuxnewmedia.de 

Oliver Frommel (V.i.S.d.P.), 

ofrommel@admin-magazin.de (ofr) 

Jens-Christoph Brendel 

jbrendel@admin-magazin.de (jcb) 

Ulrich Bantle (Ltg.), ubantle@linuxnewmedia.de (uba) 

Mathias Huber, mhuber@linuxnewmedia.de (mhu) 

Marcel Hilzinger, mhilzinger@linuxnewmedia.de, (mhi) 

Kristian Kißling, kkissling@linuxnewmedia.de, (kki) 

Markus Feilner, mfeilner@linuxnewmedia.de (mfe) 

Thomas Leichtenstern, tleichtenstern@linuxnewmedia.de (tle) 

Elke Knitter, Astrid Hillmer-Bruer (Schlussredaktion), 

Carsten Schnober, Tim Schürmann, Claudia Thalgott 

Christian Ullrich, cullrich@linuxnewmedia.de 

Klaus Rehfeld, Judith Erb 

Titel: Judith Erb, Bildmaterial: Vasiliy Yakobchuk, 123RF 

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 

Petra Jaser 

Tel.: 089/99 34 11 24, Fax: 089/99 34 11 99 

E-Mail: anzeigen@admin-magazin.de 

Pressevertrieb MZV, Moderner Zeitschriften Vertrieb GmbH 

Breslauer Straße 5, 85386 Eching 

Tel.: 089/31906-0, Fax: 089/31906-113 

Druck 

Vogel Druck und Medienservice GmbH 

97204 Höchberg 

Der Begriff Unix wird in dieser Schreibweise als generelle Bezeichnung für die Unix-ähnlichen Betriebssysteme 

verschiedener Hersteller, zum Beispiel Eurix (Comfood), Ultrix (Digital Equipment), HP/UX (Hewlett-Packard) oder Sinix 

(Siemens) benutzt, nicht als die Bezeichnung für das Trademark von X/Open. Linux ist eingetragenes Marken zeichen von 

Linus Torvalds und wird in unserem Markennamen mit seiner Erlaubnis verwendet. Alle anderen Marken sind Eigentum 

der jeweiligen Inhaber. Eine Haftung für die Richtigkeit von Veröffentlichungen kann trotz sorgfältiger Prüfung durch 

die Redaktion vom Verlag nicht übernommen werden. Mit der Einsendung von Manu s kripten gibt der Verfasser seine 

Zustimmung zum Abdruck im Admin-Magazin. Für unverlangt ein gesandte Manuskripte kann keine Haftung übernommen 

werden. Die Redaktion behält sich vor, Artikel zu kürzen. Das Exklusiv- und Verfügungsrecht für angenommene 

Manuskripte liegt beim Verlag. Es darf kein Teil des Inhalts ohne ausdrückliche schriftliche Genehmigung des Verlags in 

irgendeiner Form vervielfältigt oder verbreitet werden. Copyright © 1994–2012 Linux New Media AG 

Inserentenverzeichnis 

1&1 Internet AG http://www.einsundeins.de 27, 36 

ADMIN http://www.admin-magazin.de 49, 71, 85, 128 

Android User GY http://www.android-user.de 111, 129 

DFN-Cert Services GmbH http://www.dfn-cert.de 79 

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

German Unix User Group (GUUG) e.V. http://www.guug.de/ 19 

Hetzner Online AG http://www.hetzner.de 132 

Host Europe GmbH http://www.hosteurope.de 7 

Hostserver GmbH http://www.hostserver.de 9 

in-put Schulungen http://www.in-put.de 39 

Infosecurity Europe http://www.infosec.co.uk 21 

Kamp Netzwerkdienste GmbH http://www.kamp.net 17 

Kettner Mathias - Linux Experte http://www.mathias-kettner.de 29 

Linux User Spezial http://www.linux-user.de/spezial 77 

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

Linux-Magazin http://www.linux-magazin.de 93 

Linux-Magazin Academy http://www.academy.linux-magazin.de 25, 55 

Linux-Magazin Online http://www.linux-magazin.de 123 

LinuxUser http://www.linuxuser.de 125 

NETHINKS GmbH http://www.nethinks.com 59 

netways GmbH http://www.netways.de 117 

Netzwerktotal http://www.netzwerktotal.de 75 

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

pascom - Netzwerktechnik 

GmbH & Co.KG http://www.pascom.net 11 

Pluspol GmbH http://www.pluspol.de 41 

Spenneberg Training & Consulting http://www.spenneberg.com 95 

Stern & Schatz GmbH http://www.getdigital.de 53 

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

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

Ubuntu User http://www.ubuntu-user.de 131 

Autoren dieser Ausgabe 

Chris Binnie Abwehrverhalten 94 

Wolfgang Dautermann Not-Lösung 28 

Thomas Drilling Aus einem Guss 60 

Thomas Drilling Schlüsselwächter 32 

Thomas Drilling Testlabor 76 

Florian Effenberger Runderneuert 80 

Bernhard Fahr Kontrollzentrale 56 

Æleen Frisch Fern gesteuert 120 

Thomas Joos Ausgepackt 74 

Charly Kühnast Tortenstück 118 

Martin Loschwitz Agentenausbildung 96 

Martin Loschwitz Nichts exklusiv 106 

Vilma Niclas Softwareschutz 22 

Thorsten Scherf Gefiickt 18 

Tim Schürmann Schutzschild 86 

Tim Schürmann Start me up 112 

Christoph Siess Zieleinlauf der Kontrolleure 66 

VORSCHAU 

Somchai Suppalertporn, 123RF 

E-Mail 

ADMIN 02/2012 erscheint am 8. MÄRZ 2012 

Mit E-Mail-Diensten muss sich jeder 

Administrator früher oder später 

einmal beschäftigen. Das kommende 

ADMIN-Heft gibt dazu Praxis-Tipps und 

stellt taugliche Antispam-Lösungen 

sowie benutzerfreundliche Webmail- 

Frontends vor. 

vSphere 

Mit dem vSphere Hypervisor 

(ESXi) bietet VMware ein 

kostenloses Virtualisierungsprodukt 

auf professionellem 

Niveau. Was es kann und wie 

man es in der Praxis einsetzt, 

verrät unser Workshop. 

Tomas Skopal, 123RF 


UBUNTU 

Für echte 

Fans! 

James Thew, Fotolia 

Zeige Flagge für Ubuntu! 

• die aktuelle Ausgabe Ubuntu User 

• einen Schal mit eingesticktem Ubuntu User 

• eine Mütze mit eingesticktem Ubuntu User 

• einen Kugelschreiber mit Ubuntu User 

UBUNTU 

user 

UBUNTU 

user 

Fan-Paket 

nur 

14,95 € * 

auch ohne Heft für 

nur € 9,95 * erhältlich 

• einen Aufkleber mit “Oneiric Ocelot”, dem 

Maskottchen von Ubuntu 11.10 

• eine Postkarte mit “Oneiric Ocelot”, dem 

Maskottchen von Ubuntu 11.10 

*Preise gelten für Deutschland, nur solange der Vorrat reicht 

Jetzt online Bestellen: 

• www.ubuntu-user.de/fan-paket 

• Telefon 089 / 2095 9127 • Fax 089 / 2002 8115 • E-Mail: abo@ubuntu-user.de

ADMIN Magazin Monitoring (Vorschau)

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

Template löschen?

Als Template speichern?