Philipp Deneu, Autor bei NETWAYS GmbH

Migration von Virtual Box nach VMware Fusion

von Philipp Deneu | Jul 18, 2011 | Mac, Virtualisierung, Linux

Vor ca. zwei Monaten erklärte Christoph Niemann wie man VMware Server Images nach Xen migrieren kann. Sein Einsatzgebiet im Blogpost war das Rechenzentrum. Virtualisierung spielt sich aber längst nicht mehr nur in Rechenzentren ab sondern ist auch stark auf dem Desktop PC / Notebook vertreten. Dank schnellen Prozessoren und großen Arbeitsspeicherkapazitäten ist es eine durchaus praktikable Lösung um Testumgebungen auf dem Arbeitsplatz- oder Heimrechner aufzubauen.
Die Qual steckt hier weniger in der Installation der Gastsysteme sondern mehr in der Wahl der Software. Die einen schwören auf die kostenlose Lösung VirtualBox aus dem Hause Oracle, andere nutzen das kostenpflichtige Parallels Desktop oder die Lösung des Platzhirsches – VMWare Fusion. Die Wahl des geeigneten Produktes sei an dieser Stelle jedem selbst überlassen.
In diesem Fall habe ich die Vorzüge von VMware Fusion erkannt, einige meiner Kollegen schwören hingegen auf VirtualBox o.a. Generell ist dies auch kein Problem, es sein denn man kommt an an den Austausch der Image Dateien dieser Guestsysteme. VMware Fusion mag nur *.vmdk als Dateiformat und VirtualBox nennt das ganze *.vdi oder neuerdings auch *.vbox. VirtualBox bringt von Haus aus das Tool ‚VBoxManage‘ mit, welches das vorhandene *.vdi File in ein *.vmdk konvertiert

# VBoxManage clonehd virtualdisk.vdi virtualdisk.vmdk --format VMDK

Anschließend unter VMware eine neue virtuelle Maschine erstellen und die eben konvertierte Disk als Festplatte auswählen. Voilà – wir haben ein Gastsystem von VirtualBox nach VMware Fusion konvertiert. Den Weg zurück gibt es ein beim nächsten mal…

Spiegeln unter dem roten Hut

von Philipp Deneu | Jun 16, 2011 | Linux, Technology

In vielen unserer Umgebungen nutzen wir DRBD zur Spiegelung der Festplatten über zwei Server hinweg. So lassen sich Hochverfügbarkeitskonzepte auch ohne den Einsatz einer shared Storage aufbauen.
DRBD wird bei vielen Distributionen schon im Standart Package Repository mitgeliefert. Die Ausnahme der Regel machen hier die „Kommerziellen“.
Bei SuSE Linux Enterprise Server muss dafür die HA Extension gekauft werden. Bei RedHat ist es leider nicht in der Cluster Suite enthalten. Abhilfe schafft hier das CentOS Extra Repository.

rpm --import http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5
yum install drbd83 kmod-drbd83

Das ganz klappt bis RHEL 5.6 wunderbar, ab Version 6 stehen leider derzeit noch keine RPM Pakete zur Verfügung.
Kein Problem, kompilieren wir uns das ganz doch einfach selbst und weil wir nicht auf den Kopf gefallen sind bauen wir auch direkt RPM Pakete daraus um uns den Schritt für den zweiten Node zu ersparen.
Fangen wir mit den Vorbereitungen für unser DBRD Menü an:
Zutaten bereitlegen

yum install kernel-devel rpm-build gcc bison flex
wget http://oss.linbit.com/drbd/8.3/drbd-8.3.10.tar.gz
tar xzvf drbd-8.3.10
cd drbd-83.10
cp /boot/config-`uname -r` .config

Zutaten verrühren

./configure --with-km --with-utils
make
cd drbd
make clean all

In den Backofen schieben
Als erstes erstellen wir die DRBD Pakete (DRBD, DRBD Utils, DRBD Hearbeat- und Pacemakerskripte, DRDB-Xen etc.) und anschließend das Paket was uns DRBD als Kernel Modul lädt.

make rpm
make km-pm

Verzehr

cd /root/rpmbuild/RPMS/x86_64 (oder i368)
rpm -ivh drbd-*.rpm

Zum Abschluß können die erstellten DRBD RPM Pakete auf den zweiten Node kopiert und installiert werden.

OpenLDAP – Flaggschiff unter den OpenSource Verzeichnisdiensten

von Philipp Deneu | Mai 18, 2011 | OpenLDAP, Linux, Icinga, Nagios

Ein Verzeichnisdienst gehört zu den Grundbausteinen jeder IT-Infrastruktur und dabei ist es ganz egal ob es sich um 20 oder 2000 Anwender im Unternehmen handelt.
Sinn und zweck von Verzeichnisdiensten
In der Regel dient er als hierarchische angeordnete Ablage zur zentralen Speicherung von Benutzerdaten, der Gruppenverwaltung, dem Rechtemanagement oder dem bereitstellen von Applikationen.
Meist liegt dieser Datensammlung eine Datenbank zu Grunde welche die Informationen speichert und über verschiedene Netzwerkprotokolle (DAP, LDAP, LDAPS, Kerberos, NCP etc.) zur Verfügung stellt. Weil es in der Datenbank selten große Schreibvorgänge gibt ist sie dahingehend optimiert beim reinen Lesezugriff schnell zu antworten.
LConf nutzt diese Funktionalität ebenfalls, dient aber nicht zum speichern von Benutzerdaten sondern, dank eines angepassten Schemas, zum speichern der Nagios- oder Icingakonfigurationsdaten. Durch die hierachische Vererbung von Objekten lassen sich so schnell eigene und effiziente Strukturen aufbauen.
OpenLDAP ist DER Verzeichnisdienst unter den OpenSource Verzeichnisdiensten und muss sich schon lange nicht mehr hinter propertären Lösungen wie ActiveDirectory (Microsoft) oder eDirectory (Novell) verstecken. Auch eine möglicher Einsatz als Metadirecotry Server ist möglich. In einem solchen Szenario würden Identitätsdaten mittels verschiedener Konnektoren zu anderen Verzeichsdiensten repliziert bzw. synchronisiert.
Das OpenLDAP Projekt gibt es seit 1998 und wird von drei Hauptentwicklern vorangetrieben (Weitere Informationen: http://www.openldap.org/project/).
OpenLDAP 2.4
Die aktuelle Version OpenLDAP 2.4 hat im Bereich Performance und Funktionalität zugelegt so das dieser auch oft als zentrale Instanz in IdentityManagement Konstrukten eingesetzt wird.
Ein großer Vorteil ist das relativ neue Konfigurationsschema bei dem die Einstellungen direkt im DIT (Directory Information Tree) landen. Viele Konfigurationsänderungen können auf diese Weise ohne einen Neustart des LDAP-Servers übernommen werden. Neben diesen Features wurde das Replikationsschema um zwei weitere Möglichkeiten erweitert die jede denkbare Replikation erlauben: MirrorMode und N-Way MultiMaster
Beim MirrorMode lassen sich LDAP Server verteilt über beispielsweise zwei Standorte aufbauen und erlauben eine Replikation der Daten über zwei Provider.
In diesem Fall hat der erste Provider die Verbindung zu jedem MasterServer, schreibt aber die Daten nur auf einen Server, welcher diese wiederum repliziert. Der zweite Provider läuft als Standby mit und fängt den ersten Provider auf sollte dieser ausfallen und führt die restlichen Schreibvorgänge solange durch bis Provider 1 wieder online ist.
Der N-Way MultiMaster Replikationsweg ermöglicht es mehrere aktive Master Replikationen zu schalten welche in N-Wegen zueinander stehen können und wiederum Slaveserver besitzen können.
Neben dem „Standardaufbau“ von Master / Slave Konstrukten lassen sich mit OpenLDAP auch LDAPProxy Server zwischenschalten um ggf. an Standorten die Administration in den Slave hinein zu ermöglichen ohne Zugriff auf den Master zu benötigen.
Mittels dieser verschiedenen Architekturmöglichkeiten die OpenLDAP bietet lassen sich viele beliebige Szenarien abbilden.
OpenLDAP ermöglicht ein Onlinebackup der Datenbank (ldapsearch) oder ein Offlinebackup (slapcat).
Zudem nutzt OpenLDAP Checkpointing, welches die Fehlertoleranz anhand von einem Snapshot ähnlichem Mechanismus bietet um im Fehlerfall oder Absturz Datenbankinkonsistenz zu vermeiden.
Die Replikation sowie das Laufzeitverhalten lässt sich mit verschiedenen Nagios und Icinga Plugins monitoren.

Nagios Config Interfaces – NagiosQL

von Philipp Deneu | Apr 21, 2011 | Icinga, Nagios, Serien

Nach fast 10 Monaten eifriger Recherche befassen wir uns mit dem dritten Produkt der Blog Serie: NagiosQL
NagiosQL ist wie NConf ein auf PHP basierndes Konfigurationstool für Nagios und Icinga. Alle Informationen werden in einer MySQL Datenbank gespeichert und in Konfigurationsdateien exportiert. NagiosQL kann unter nagiosql.org kostenfrei (New BSD License) heruntergeladen werden.
Installationsvoraussetzungen
Die Installation von NagiosQL ist einfach und dank dem Wizard für jedermann leicht händelbar. Der „NagiosQL Installations Assistent“ weist uns auf alle fehlenden Pakete und falschen Berechtigungen unser Installation hin.
Voraussetzungen im Groben sind ein Webserver mit PHP, ein Pear Paket und eine MySQL Datenbank.
Nach der Beendigung des Installationswizards ist man dann auf sich selbst und das eigene Suchvermögen gestellt, um die letzten Konfigurationsschritte abzuschließen.
Die Dokumentation auf nagiosql.org darf diesbezüglich noch verbessert werden.
Handling / Usability
Die Oberfläche ist strukturiert und übersichtlich aufgebaut, Menüpunkte sind den Konfigurationsobjekten nach benannt (Hosts, Services, Commands etc.) und durch das Berechtigungskonzept lassen sich unterschiedliche Ansichten für verschiedene Benutzergruppen einrichten.
Funktionen wie das Klonen/Kopieren bestehender Objekte vereinfachen die Arbeit und auch das Host- und Servicetemplate Konzept ist durchdacht. Ein paar Abstriche muss man jedoch in Kauf nehmen. Leider gibt es keine Funktionsübergreifende Suchfunktion und auch verschiedene Konfigurationsmöglichkeiten die Nagios und Icinga liefern, stellen sich als umständlich heraus.
Das Webinterface könnte im Ganzen noch dynamischer sein und sich der Materie Web 2.0 nähern.
Funktionsumfang
Der Funktionsumfang deckt derzeit alle Konfigurationsmöglichkeiten von Nagios ab.
Einige Punkte wie z.B. die Zuordnung von Hosts zu Hostgruppen bzw. das Zuordnen von Gruppenmitgliedern zu einer Hostgruppe, können noch verbessert werden.
Sehr positiv zu erwähnen ist, dass alle Funktionen sowohl für Nagios als auch Icinga funktionieren.
Enterprise Environments
NagiosQL ermöglicht es Konfigurationsdateien verschiedener Instanzen zu administrieren.
Nach dem Erstellen einer „Domäne“ lassen sich Konfigurationsdateien via SSH oder FTP auf eine weitere Nagios oder Icinga Instanz exportieren. Auch das Starten und Stoppen der Instanzen funktioniert über SFTP oder SSH aus der Weboberfläche heraus.
Datenimport
Der Datenimport lässt sich aus der Weboberfläche starten. Zur Auswahl stehen im Standard alle Konfigurationsdateien unterhalb des Nagios ‚/etc‘ Verzeichnisses. Beim Importieren beachtet NagiosQL neben den Host- und Servicetemplates auch, ob ein Host vorher aktiviert oder deaktiviert war.