Die Agenda gliedert sich in zwei parallele Tracks mit Vorträgen zu den aktuellen Trends von jeweils ca. 45-minütiger Dauer und darauf folgender Diskussionsrunde. Zu den Referenten gehören bekannte Namen aus dem Open Source Umfeld wie Baron Schwartz (Percona), Dr. Michael Schwartzkopff (MultiNET Services GmbH) und Florian Haas (Linbit Information Technologies GmbH).

Hier ein Vorgeschmack auf einige interessante Vorträge:

• Baron Schwartz: Optimizing MySQL and InnoDB Performance
• Florian Haas: High Availability and Storagereplication – without limits
• Dr. Michael Schwartzkopff: Linux-HA: Quo Vadis?
• Wolfgang Stief: Ein Lustre Cluster für wirklich hohen Datendurchsatz
• Erkan Yanar: Containervirtualisierung mit OpenVZ
• Ralph Dehner: Virtualisierung mit KVM
• Jens Link: Einführung in IPv6
• Rainer Jung: What’s new in Apache 2.4?
• Michael Schlenzka: Delivering New, Powerful Reporting Solutions with Open Source Business Intelligence
• Jörg Möllenkamp: Insights to (Open)Solaris

Die aktuellsten Infos zur Konferenz finden sich auf der Konferenzwebsite unter: www.osdc.de. Für den 10%igen Rabatt einfach bei der Anmeldung im Feld „Anmerkungen“ auf den Blog verweisen!

Möchte man in fremden Netzwerken selbst sicherstellen, dass man nicht Opfer solcher Angriffe wird, ist es möglich mit Software das Netzwerk zu überwachen und bei verdächtigen Veränderungen gewarnt zu werden. Ein bekanntes Unix-Netzwerktool in diesem Bereich ist arpwatch, welches ich u.a. auch auf meinem Notebook unter Mac OS X betreibe. Um direkt über verdächtige Änderungen im Netzwerk informiert zu werden, habe ich ein kleines Python-Skript geschrieben, das die System-Log von Mac OS X nach arpwatch-Meldungen durchsucht und entsprechende Growl-Nachrichten erstellt. Eine solche Growl-Nachricht kann z.B. so aussehen:

Hier wird gemeldet, dass sich die MAC-Adresse der IP 192.168.0.2 zwischen den beiden aufgeführten Adressen hin und her ändert. Ein Hinweis auf eine doppelt vergebene IP-Adresse im Netzwerk oder aber auch ein Indiz für gefälschte ARP-Anfragen bei einem Man-in-the-middle-Angriff.

Im Wiki habe ich die Einrichtung der Software und die erforderlichen Skripte für den Nachbau dokumentiert.

Wer selbst schon Amazon Web Services einsetzt und vom lokalen Serverspeicherplatz (ephemeral storage) auf das Booten vom SAN (EBS boot) umstellen möchte, findet als Unterseite meine Notizen über die notwendigen Schritte hierfür: Umstellung AWS EC2 ephemeral store auf EBS boot.

Alles Begann mit einer Umstrukturierung des internen Netzwerks im Juli 2008.Es wurde geplant, das Netz in mehrere Segmente aufzuteilen und diese mit einem Layer-3 Switch zu verbinden. Die Entscheidung fiel auf einen Dell PowerConnect 6224. Da dies ein zentraler Knotenpunkt werden sollte, erwarben wir auch den Pro Support mit 4h vor Ort Austausch-Service.

Im Februar tauchten sporadisch kurze Netzwerkausfälle auf, die sich immer weiter häuften. Es stellte sich heraus, dass der Switch sporadisch neustartete. Nach einem Anruf bei Dell hatten wir innerhalb einer Stunde ein Austauschgerät. Respekt!

Allerdings war das Problem damit nicht behoben. Nach ca. 3 Wochen Mailverkehr mit der Softwareentwicklung in Irland bekam ich den Hinweis, doch das SSH mal abzuschalten und siehe da, es war Ruhe im Karton.In ca. 1 Monat sollte eine neue Software erscheinen mit einer neuen SSH-Implementierung. Das war zwar etwas unschön, da wir den Switch primär über SSH managen, aber für 1 Monat würde das gehen. Leider wurden daraus 3 Monate. Diese lief auch stabil und behob noch ein anderes Manko, nämlich, dass man das DHCP Relay nur global einschalten konnte, und nicht pro vlan.

Im November fingen die Probleme dann richtig an, als ich für ein VLAN das Routing abschalten wollte. Über einen Zeitraum von ca. 15 min. funktionierte das Routing für das gesamte Netz nicht mehr. Interessanterweise passierte es nicht plötzlich, sondern nach und nach waren immer mehr Systeme nicht mehr erreichbar, als wenn der Routing Cache erst leerlaufen musste. Wenn man das Routing für das vlan wieder aktivierte lief wieder alles. Es ist mir nicht gelungen, dieses vlan abzuschalten ohne das Netz lahmzulegen, also habe ich es erstmal gelassen. Als wir später 2 zusätzliche LAG’s an den Switch anbinden wollten, bildeten sich plötzlich Netzwerkschleifen, wodurch das Netz zeitweise nicht  mehr benutzbar war.  Wir haben mehrere Tage intensiv den ganzen Netzaufbau nach möglichen Ursachen dafür abgesucht, konnten aber nichts finden. Also fragten wir mal beim Dell Support nach. Dieser verwies uns mehrfach an den kostenpflichtigen Konfigurationssupport . Beim dritten Anfruf endlich bekam ich die Aussage, dass die Software kurz nach der Veröffentlichung wieder zurückgezogen wurde, weil Diese Fehler en masse enthalte und ich solle doch bitte wieder ein Downgrade auf die alte Software durchführen. Gesagt, getan und wirklich, alles lief wieder vernünftig, ausser SSH natürlich.  Bis heute, nach über einem Jahr, ist noch keine neue Software erschienen und SSH ist nach wie vor nicht nutzbar.

Fazit: Der teure ProSupport von Dell nützt einem bei Softwareproblemen leider gar nichts. Mit den Servern von Dell haben wir wirklich sehr gute Erfahrungen gemacht, aber von den Switches, speziell dem 6224 und dem ProSupport dafür bin ich mehr als enttäuscht. Der nächste Layer-3 Switch wird definitiv kein Dell werden.  Schade, Dell hier besteht noch einiges an Nachholungsbedarf.

Generell kann ich Switches von Dell nicht sehr empfehlen, das reicht von langen Bootzeiten über nicht mehr erreichbare Webinterfaces (bis zum nächsten Neustart,eher suboptimal bei Netzwerkknotenpunkten) bis hin zu den merkwürdigsten Effekten in den Webinterfaces.

Update: Das Problem wird von DELL auch im englischen Community-Forum ignoriert: Link zum Post.

Update 2: Dell hat jetzt ein neues Minor-Release veröffentlicht, welches aber, laut den Release Notes, nicht das SSH-Problem behebt.

Update 3: Vor einigen Wochen hat Dell wieder eine neue Version der 3-er Reihe veröffentlicht und wir haben es eingespielt. Und oh Wunder, es gab noch keine Probleme und wir haben endlich wieder ssh. Super Dell, nach ca. 1,5 Jahren haben wir endlich mal wieder eine sauber funktionierende Software…

Ein paar Gründe für meinen Umstieg von FosWiki auf Confluence:

• Sehr gute Bedienbarkeit (Usability), z.B. Anhängen von Dateien an Wiki-Seiten per Drag&Drop.
• Lese- und Schreibzugriff auf alle Wiki-Daten per WebDAV.
• Schnelle und gute Suche mit Indizierung gängiger Dateitypen.
• Intuitiver Wiki-Code und ausgereifter WYSIWYG-Editor.
• Schneller Seitenaufbau, kurze Ladezeiten.

Auf Anfrage erstelle ich gerne Benutzer im Wiki zum Mitarbeiten an Dokumenten. Ansonsten lässt sich jedes Wiki-Dokument auch anonym kommentieren. Viel Spaß mit dem neuen System!

// rebind to authenticate the password now we know the user exists
$entries = $search->entries();
$bind_result = $ldap->bind($entries[0]->dn(), $password);

Und genau hier gab es Probleme mit dem Code, zumindest auf unserer Standard Debian LAMP-Installation mit Apache 2.2 und PHP 5. Wenn der LDAP-Bind fehl schlägt, soll eigentlich der Fehlercode abgefragt und mittels einem “False-Return” der Anwendung mitgeteilt werden, dass die angegebenen Legitimationsdaten inkorrekt sind:

if ($ldap->getCode() == LDAP_INVALID_CREDENTIALS) {
return false;

Soweit kam die Anwendung jedoch nicht. Bei einem fehlgeschlagegen LDAP-Bind hat das PEAR LDAP-Modul die Anwendung einfach mit einem DB-Fehler und einem “die” beendet.

Die Lösung: Mittels folgender PEAR-Anweisung lässt sich die Standard-Fehlerbehandlung auf “PEAR_ERROR_RETURN” umstellen, so dass bei einem fehlgeschlagenen LDAP-Bind nicht mehr die Anwendung beendet, sondern nur einer Fehlercode zurückgegeben wird:

PEAR::setErrorHandling(PEAR_ERROR_RETURN);

Partition unmounten und Verschlüsselung schließen:

# sudo umount /home/fileserver
# sudo cryptsetup luksClose fileserver

LVM vergrößern (hier um 512GB):

# sudo lvresize /dev/data/fs_crypt -L +512G

Verschlüsselung wieder aktiveren:

# sudo cryptsetup luksOpen /dev/data/fs_crypt fileserver

Dateisystemcheck durchführen (sonst beschwert sich resize2fs):

# sudo e2fsck -f /dev/mapper/fileserver

Schließlich Dateisystem auf dem verschlüsseltem Device vergrößern:

# sudo resize2fs /dev/mapper/fileserver

Mal sehen, wie lange das jetzt hält

Nun aber zum Thema: Das Mini-ITX Gehäuse ES34069 von Chenbro, mit dem ich bisher sehr zufrieden bin, hat einen Schönheitsfehler: Der Geräuschpegel der beiden, hinteren 70cm Lüfter, die die vier vorderen SATA-Festplattenslot kühlen, ist recht hoch. Gerade in einer ruhigen Umgebung sind die Lüfter deutlich zu hören. Nach ein paar Tests mit niedrigeren Spannungen an den Lüftern (7-10V) stand fest, dass mit einer Lüftersteuerung der Geräuschpegel stark abgesenkt werden kann. Die Wahl fiel auf den T-Balancer MiniNG, eine 2-Kanal Lüftersteuerung, die im Chenbro-Gehäuse über dem ITX-Mainboard Platz findet. Einen der beiden zur Verfügung stehenden Temperatursensoren habe ich in einen der SATA-Wechselslot befestigt, um dort direkt die Temperatur der Festplatten zu ermitteln.

Das Ergebnis ist eine fast nicht mehr hörbare Kühlung bei normaler Umgebungstemperatur. Zudem gehen die Lüfter komplett aus, wenn die Festplatten in Standby fahren – ein großer Vorteil gegenüber einem festen Herabsetzen der Lüfterspannung (z.B. 7V) ohne Steuerungselektronik.

Bilder und weitere Details zur Konfiguration der Lüftersteuerung finden sich im Abschnitt Geräuscharme Kühlung im HomeServer-Wiki-Artikel.

Datenschutz / Sicherheit / Privatsphäre:

Download / Bedienung:

Erweiterungen / Tools:

Web-Entwicklung:

Web Security / Penetration:

Fehlen noch unschlagbare Plugins, die umbedingt erwähnt werden sollten? Über Ergänzungen der Liste per Kommentar würde ich mich freuen.

Der erste Vortrag heute handelte über das Clusterdateisystem GPFS von IBM. Da wir selbst eher weniger gute Erfahrungen mit dem Clusterdateisystem von Oracle (OCFS2) gemacht haben, waren wir von dem alternativen Cluster-Produkt von IBM und den Erfahrungen, die die vortragende Firma damit in Kundenprojekten sammeln konnte, recht angetan. Alle wichtigen Notizen aus dem Vortrag sind unterhalb des LinuxTag 2009-Wiki-Dokuments zufinden.

hdparm -S Zeitangabe /dev/sdX

Nach Ablauf der Zeitangabe (siehe Manpage, je nach Höhe ein Vielfaches von Sekunden oder Minuten) wird die Festplatte, wenn in dieser Zeit kein Zugriff erfolgt ist, heruntergefahren und automatisch wieder hochgefahren, wenn wieder darauf zugegriffen wird.

Leider unterstützten diese Funktion einige, neuere Festplatten nicht mehr. Daher muss der Inaktivitäts-Timer als Software realisiert und die Festplatte nach Ablauf der Zeit manuell heruntergefahren werden. Eine solche Implementierung ist hd-idle, die sich unter Ubuntu/Debian recht einfach einrichten lässt. Der Ubuntu-Homeserver-Artikel wurde hierfür um ein neues Kapitel erweitert, welches die Einrichtung von hd-idle kurz erläutert.

Die CPU-Spannung lässt sich zum einen im BIOS einiger Mainboardhersteller herabsetzen oder auch per Software während des Betriebs. Unter Linux existiert das Linux-PHC Projekt.

Für Ubuntu steht in einem externen Repository der aktuelle Ubuntu-Linux-Kernel 2.6.28.11 mit den entsprechenden Linux-PHC-Patches zur Verfügung. Die Installation und die Verwendung mit einem Intel E5200 Dual-Core CPU und dem Intel DG45FC Mainboard ist im Wiki beschrieben.

Mit Hilfe von Undervolting konnte bei 100%iger CPU-Auslastung der erwähnten Systemkonfiguration 11 Watt eingespart werden. Leider limitiert das Intel DG45FC Mainboard das Undervolting. Bei anderen Mainboards sind weitere Einsparungen und diese auch im Idle möglich.

Bei dieser Gelegenheit habe ich den Stromverbrauch meines Mini-ITX-Systems in verschiedenen Konfigurationen getestet. Hier die interessantesten Ergebnisse:

• Ausgeschaltet mit GBe Link: 1.4W
• Idle nur mit 2.5″ Systemplatte: 35W
• Volllast nur mit 2.5″ Systemplatte: 51W (ohne Undervolting: 62W)
• 4x 1TB WD10EADS Idle im IntelliPark: +10W
• 4x 1TB WD10EADS Idle ohne IntelliPark: +16W
• 2×2GB statt 1×2GB RAM: +1.5W
• Idle ohne GBe Link: -1.2W

Der Idle-Wert von 35W schlägt sich im Vergleich zu aktuellen Dual-Core Atom-Systemen mit 25W (bis 35W je nach Ausstattung) recht gut. Dabei steht bei Bedarf wesentlich mehr CPU-Leistung als mit einem Atom-CPU zur Verfügung. Möchte man z.B. hohe IO-Raten mit Verschlüsselung erreichen kann es mit einem Atom-System eng werden (siehe dazu Performance-Einbrüche beim Zugriff auf verschlüsselte Daten auf NAS-Geräte mit Atom-CPUs).

Weitere Ergebnisse und Stromkostenberechnungen finden sich im Wiki.

Ich kann zwar noch nicht mit Langzeittests dienen, jedoch laufen die Time Machine Backups bisher sehr zuverlässig und reibungslos. Time Machine mounted automatisch die AFP-Freigabe auf dem Ubuntu-Server und das darin befindliche Image vor dem Backup und unmounted es nach Gebrauch wieder. Ist der Server nicht erreichbar, schlägt das Backup zwar fehl, funktioniert nach dem Einschalten des Servers dann aber wieder ohne Probleme und ohne manuellem Eingriff. Auch die Backups über WLAN funktionieren bisher gut.

Als nächstes stand die automatische Verschlüsselung der Swap- und Temp-Partitionen mit einem zufälligen Schlüssel und die manuelle Verschlüsselung anderer Datenpartitionen per Passwort an. Da der Server nicht ständig laufen soll, ist die Eingabe des Passworts für die verschlüsselten Backup-Partitionen beim Hochfahren des Systems jedoch sehr unpraktisch. Daher wurde für diese Partitionen zusätzlich ein Keyfile auf einem USB-Stick angelegt, der automatisch beim Hochfahren des Systems ausgelesen wird. Somit steckt man den USB-Stick mit dem Keyfile an den Servern, fährt das System hoch, während die verschlüsselten Partitionen automatisch gemounted werden und kann dann den USB-Stick wieder entfernen. Meines Erachtens eine bequeme und dennoch halbwegs sichere Lösung. Die einzelnen Schritte zur Einrichtung sind im Wiki dokumentiert.

Als Betriebssystem kommt Ubuntu Server 9.04 (Jaunty) zum Einsatz. Die vier großen Festplatten werden per Software in einem RAID5-Verbund betrieben. Im Wiki-Dokument UbuntuHomeserver werde ich sämtliche Konfigurationsschritte festhalten, die ich im Laufe der Einrichtung des Systems durchführen werde. Neben den schon erwähnten Hardware-Infos, ist dort aktuell die Partitionierung, die Liste der installierten Ubuntu-Pakete und kurze Beschreibungen zu Wake-on-Lan und dem Auslesen der Temperatursensoren (CPU und HDDs) dokumentiert.

Die MD3000i ist in diesem Test mit 8 x 1TB SATA-Festplatten im RAID-10 Verbund konfiguriert. Als weiteres Hardware-Equipment stehen zwei managebare Gigabit-Switches für ein dediziertes ISCSI-Netzwerk und zwei ähnliche Serversysteme mit Windows Server 2003 und CentOS 5.3 zur Verfügung. Die Server sind mit 2 x 1GBe (loadbalancing) und das Storage mit 2 x 2 x 1GBe (redundanter Controller und loadbalancing) angebunden. Genauere Informationen zur Hardware und zum Test-Aufbau findet sich im Wiki.

Unter Windows wurden die Performancetests mit IOMeter und ORION (Oracle I/O Calibration Tool) durchgeführt. Leider erzielten die Tests mit IOMeter unter Linux noch aus ungeklärten Gründen nur einen Bruchteil der Performancewerte unter Windows: z.B. 180MB/s sequentielles 32k-Lesen unter Windows vs. 40MB/s unter Linux. Erst mit einer Block-Größe von 1MB statt 32k konnte ein ähnlicher, sequentieller Durchsatz erreicht werden. Daher wurde unter Linux erst einmal nur mit bonnie++ und dd getestet werden.

Die MD3000i erzielte eine maximale sequentielle Leserate von 200MB/s (6414 IOPS x 32k), eine sequentielle Schreibrate von 125MB/s (4025 IOPS x 32k) und 685 IOPS bei 8k-Random-Zugriff mit 70% Leseanteil. Interessanter als die nominalen Ergebnisse dieser spezifischen Storage-Konfiguration waren jedoch die Auswirkungen auf die Performancewerte bei unterschiedlichen Test-Parameter: Zugriff auf Raw-Device oder NTFS/Ext3/XFS-Dateisystem, Zugriff mit mehreren offenen IOs und Threads, Aktivierung von Flow-Control und Jumbo-Frames im ISCSI-Netzwerks. Die wichtigsten Erkenntnisse im Überblick:

• Bei der Verwendung von NTFS mit 64k Clustergröße verringert sich die CPU-Belastung bei intensiven Schreibzugriffen zwischen 20 und 40%. Dabei verschlechtert sich die Performance bei Random-Zugriffen etwas (7%), der sequentielle Durchsatz bleibt konstant.
• Auch bei aktiviertem Flow-Control im ISCSI-Netzwerk nimmt die CPU-Belastung stark bei intensiven Schreibzugriffen ab (20-40%). Im Vergleich zu NTFS 64k bricht dabei jedoch die Performance bei Random- und sequentiellem Zugriff nicht ein, sondern steigt minimal an. Fazit: Beste Performance bei annehmbarer CPU-Belastung.
• Wird Jumbo-Frames im ISCSI-Netzwerk aktiviert, erhält man die geringste CPU-Belastung im gesamten Test: 13% geringer bei Random-Zugriff, 52% geringer bei seq. Lesen und 130% bei seq. Schreiben. Die Performance nimmt jedoch auch ab: 4,5% schlechtere Werte bei 32k seq. Lesen und 10% beim Random-Zugriff. Fazit: Geringste CPU-Belastung bei guter Performance.

Weitere Details und Testergebnisse unter Linux sind im Wiki-Dokument festgehalten.

Wenn es die Zeit zulässt, folgen noch Updates bezüglich einer weiteren Senkung der CPU-Belastung beim Einsatz von TOE (TCP Offload Engine) und Performance-Vergleichtests beim Einsatz von RAID-5/6 statt RAID-10.

Ausblick auf neue Blog-Themen:
In den nächsten Monaten wird das aufgebaute Hardware-Equipment für intensive Tests der drei großen Virtualisierungslösungen Citrix XenServer, Virtual Iron und VMWare ESX zum Einsatz kommen. Erste, unvollständige Grundlagen dazu finden sich hier.

Als nächstes bin ich auf die DOM-Parser-Implementierung XPathQuery gestoßen. Im Vergleich zu SAX wird bei DOM (“Document Object Model“) das komplette Dokument eingelesen und eine Baumstruktur im Speicher aufgebaut, über die man auf die verschiedenen Knoten und Elemente des XML-Dokuments zugreifen kann. XPathQuery unterstützt neben XML explizit auch das Parsen von HTML und kommt auch mit nicht wohlgeformten HTML-Code zurecht. Doch erste Tests auf der IPhone Hardware machte schnell deutlich, dass das Erstellen eines DOM-Trees mit Objective-C Objekten für ein über 800kb großes HTML-Dokument mit 10MB Speicherverbrauch und über 15 Sekunden Parse-Zeit die falsche Wahl auf dem IPhone ist.

Nach weiteren DOM-basierten Parsern (Übersicht im Techstories-Wiki), die ich eventuell in einem späteren Blog-Eintrag vorstellen werde, bin ich schließlich auf die Klasse AQXMLParser aufmerksam geworden. AQXMLParser baut auf NSXMLParser auf und löst die folgenden Probleme von NSXMLParser:

• Inkrementelles Einlesen von XML-Dokumenten, dadurch geringerer Speicherverbrauch und Parsen während des Downloads möglich
• Parsen von nicht wohlgeformten HTML-Code

Leider ist aber auch diese Klasse nicht ganz fehlerfrei. Folgende Probleme konnte ich jedoch mit einem Patch beheben:

• Speicherzugriffsfehler beim Einlesen eines kompletten Dokuments
• Abbruch des kompletten Parse-Vorgangs bei Parser-Fehlern (ist jetzt über die Methode setAbortOnErrors konfigurierbar)

Mit der gepatchten AQXMLParser-Klasse steht eine performante und ressourcen- effektive Lösung für das Parsen von großen, nicht wohlgeformten HTML- und natürlich auch XML-Dokumenten auf dem IPhone zur Verfügung. Bei kleineren Dokumenten kommen jedoch auch DOM-basierte Parser in Frage, da sie meist einfacher zu implementieren sind.

Weitere Details und Beispiel Implementierungen finden sich im Wiki. Der Patch kann direkt hier heruntergeladen werden.

Das erste Anwendungsbeispiel (Neustart von Webanwendungen) war Auslöser für meinen Kauf des USB-Geräts. Eine sich auf Grund von application loops und memory leaks ständig aufhängende Webanwendung konnte so für eine Übergangszeit durch die Nutzer der Anwendung selbst neugestartet werden, bis der Hersteller die Probleme gelöst hatte. Positiver Effekt: Die Mitarbeiter freuten sich anfangs regelrecht, wenn die Anwendung wieder hing und sie durch das zeremonielle Betätigen des Panic Buttons im IT-Büro das Problem selbst lösen konnten

Doch leider wird der Panic Button nur mit einer Windows Software ausgeliefert, die lediglich ein Screenshot im Vollbild anzeigt, wenn der Knopf betätigt wurde. Voreingestellt ist ein Screenshot von einem offenen Excel Sheet, dass fleißiges Arbeiten suggerieren soll, wenn der Chef um die Ecke kommt (Chef-Taste). Meines Erachtens eher nutzlos.

Daher habe ich mit USB Sniffertools die Kommunikation zwischen der Windows Software und dem Button mitgeschnitten und analysiert, um eine eigene Software zu entwickeln, die auch andere Aktionen beim Betätigen der Taste durchführen kann. Das Ergebnis ist das Perl-Modul USB::Device::PanicButton, mit dem recht einfach das Gerät unter Linux, prinzipiell aber auch unter Windows ausgelesen werden kann.

Weitere Details zum Perl-Modul und Beispielcodes für C (libhid & libusb), Perl (USB::Device) und CoreFoundation (Mac OS X) findet sich im Wiki.

Ich bin gespannt auf eure Einsatzgebiete und Ideen

Nun habe ich mich etwas in die IPhone SDK eingearbeitet und mein erstes, kleines, privates App namens FS20Lite geschrieben. Dieses verbindet sich per HTTPs zu meiner NSLU2, liest den Status des FHEM-Servers aus und stellt alle verfügbaren FS20-Aktoren in einer einfachen Liste dar. Mit einem Klick können diese ein und ausgeschaltet werden. Wie das live aussehen kann, zeigt ein kurzes Video im Wohnzimmer (ich stehe links vom Esstisch, über dem eine Tischlampe hängt). Vielleicht baue ich das App bei Gelegenheit weiter aus, um auch Lichter dimmen und die Temperatur in den Räumen auslesen und anpassen zu können.

• Je 16 Festplatten (Fassungsvermögen eines EqualLogic-Systems) wird ein weiteres, vollwertiges Storage-System fällig. Mehrere Storage-Systeme (Array-Members) werden zu einer logischen Einheit (SAN-Group) zusammengefasst und erscheinen nach außen wie ein großes Storage-System mit einer virtuellen IP. Beste Voraussetzung für eine gute Skalierung vor allem im Bereich Performance. Die Kosten steigen jedoch auch linear.
• Die EqualLogic bietet “Virtualisierungsfunktionen” für VMWare ESX und XenServer. Damit lassen sich Storage-Funktionen wie Neuanlegen von Volumes, Anpassen der Größe und Erstellen von Snapshots direkt in der Virtualisierung-Managementsoftware von VMWare und ESX durchführen. Hierzu ein Demo mit XenServer und EqualLogic.

Weitere Notizen zum Workshop findet sich im Wiki.

Tom und ich haben heute erfolgreich unsere LPIC-1 Zertifizierung bei AlphaBit in Wiesbaden abgelegt. Folgende Bücher haben wir zur Vorbereitung genutzt:

• LPIC-1. Vorbereitung auf die Prüfung des Linux Pro[..] von Peer Heinlein
• LPIC-1: Vorbereitung auf die Prüfungen 101 und 102 von Harald Maaßen

Das erste Buch gibt einen guten, komprimierten (326 Seiten) Überblick über alle Prüfungsthemen, geht jedoch nur bedingt ins Detail ein. Für erfahrende Administratoren reicht das als Vorbereitung aus, allen anderen kann ich das zweite Buch zusätzlich empfehlen. Vor allem die Testfragen im Buch haben so manche Wissenslücke noch aufgedeckt.

Meine Notizen beim Erarbeiten der Bücher habe ich im Wiki abgelegt. Sie dienten mir zur Wiederholung von Themen und Details, die mir nicht mehr so geläufig waren. Könnte eine gute Kontrolle für jemanden sein, der selbst bald die LPIC-1 Zertifizierung durchführen möchte. Schaut doch mal rein.

Noch ein paar generelle Hinweise zur LPIC-Prüfung:

• Es ist ausreichend Zeit. Ich bin die Fragen ganz langsam durchgegangen und war trotzdem nach der Hälfte der verfügbaren Zeit (90 Minuten) durch.
• Lest unbedingt die Fragen genau durch und auch alle Antwortmöglichkeiten. Es passen manchmal mehrere Fragen, es ist jedoch oft nur die bestmögliche Antwort gefordert.
• Für einigermaßen erfahrene Linux-Admins ist LPIC-1 wirklich schaffbar, macht euch nicht verrückt

Viel Spaß beim Lesen!