Einen kleinen Show-Stopper erlebt man dann, wenn auf den virtuellen Maschinen noch ISO-Abbilder, die nicht auf dem gemeinsamen Cluster-Speicher abgelegt wurden, eingehängt sind (beispielsweise lokale CD-Laufwerke). In diesem Fall lässt sich die VM nicht verschieben und der Clusterknoten wechselt nicht in den Wartungsmodus, manuelle Interaktion ist notwendig.

Das kann, je nach Anzahl der ISOs, die eingehängt wurden, Zeit und Nerven kosten. Abhilfe schafft das folgende kleine PowerShell-Skript, welches ich für diesen Zweck geschrieben habe:

PowerCLI C:\scripts> vim VMISOs.ps1

#Get all virtual machines with mounted ISOs and dismount (if wanted)
#2013 By Christian Stankowic 

##################################################################

#Get array of all Clusters
$myClusters = Get-Cluster

#Create VMs array
$VMs = @()

Write-Host "Okay - I'm going to check all VMs whether there are mounted ISO files."
Write-Host "This will take some time - get yourself some coffee..  "
Write-Host ""

#Get vms of cluster
foreach ($cluster in $myClusters) {
                #Get VMs
                #$thisVMs = Get-VM
                $thisVMs = Get-Cluster $cluster | Get-VM
                $counter=0;

                #Get VM information
                foreach ($vm in $thisVMs) {
                               #Get view
                               $vmView = $vm | Get-View

                               if( (($vm | Get-CDDrive).ISOPath) -or (($vm | Get-CDDrive).RemoteDevice) -or (($vm | Get-CDDrive).HostDevice) )
                               {
                                               #Setup output
                                               $VMInfo = "" | Select "VM","Host","ISO","RemoteDevice","HostDevice"

                                               #Write-Host "VM = $vm | Host = " ($vm | Get-VMHost).name " | ISO = " ($vm | Get-CDDrive).ISOPath " / Remote-Device = " $(vm | Get-CDDrive).RemoteDevice " / HostDevice = " $(vm | Get-CDDrive).HostDevice

                                               #Defining hostname, ESX host and ISO path
                                               $VMInfo."VM" = $vm.Name
                                               $VMInfo."Host" = ($vm | Get-VMHost).Name
                                               $VMInfo."ISO" = ($vm | Get-CDDrive).ISOPath
                                               $VMInfo."RemoteDevice" = ($vm | Get-CDDrive).RemoteDevice
                                               $VMInfo."HostDevice" = ($vm | Get-CDDrive).HostDevice

                                               #Add to array
                                               $VMs += $VMInfo
                               }

                               $counter++;
                               if( $counter % 10 -eq 0 ) {
                               Write-Host "Check $counter of " $thisVMs.length " in " $cluster " so far..."
                               }
                }
}

#sort array by Cluster
$VMs | Sort Cluster

#disconnect
$answer = Read-Host "Found " $VMs.length " mappings - force disconnect now? (y/n)"
if($answer -eq "y")
{
                foreach ($vm in $VMs)
                {
                               Write-Host "Disconnect on " $vm.VM "..."
                               Get-VM $vm.VM | Get-CDDrive | Set-CDDrive -NoMedia -Confirm:$false
                }
}
else { Write-Host "Disconnect aborted by user." }

Das Skript erfordert eine installierte PowerShell und VMware PowerCLI. Nachdem eine Verbindung zum vCenter hergestellt wurde, fragt das Skript alle Cluster und alle darin hinterlegten virtuellen Maschinen nach eingehängten CD-ROMs/ISOs ab. Anschließend wird eine Liste der betroffenen VMs angezeigt – nach einer Bestätigung werden die Medien ausgehängt, damit die Administrationsaufgaben ausgeführt werden können.

PowerCLI C:\scripts> Connect-VIServer TVM-VCENTER

PowerCLI C:\scripts> .\VMISOs.ps1
Okay - I'm going to check all VMs whether there are mounted ISO files.
This will take some time - get yourself some coffee..  

Check 10 of  136  in  Demo-Cluster  so far...
....
VM           : TVM-WEB01
Host         : hypervisor01.localdomain.loc
ISO          :
RemoteDevice : /usr/lib/vmware/isoimages/windows.iso
HostDevice   :

Found  6  mappings - force disconnect now? (y/n): y
Disconnect on  TVM-WEB01 ...
...

Insbesondere vor Wartungsarbeiten spart mir das Skript viel Zeit.

Wenn es darum geht, Daten zwischen mehreren Hosts stets synchron zu halten, ist die Verwendung eines DRBDs (Distributed Replicated Block Device) meistens die eleganteste und einfachste Lösung.

So kann man seine Server beispielsweise mit dedizierten LUNs ausstatten und auf diesen die durch den späteren Cluster zu schützende Applikationen ablegen. In Kombination mit heartbeat, Pacemaker oder ähnlichen HA-Lösungen ergibt DRBD das Herzstück für hochverfügbare Linux-Applikationen.

Das Konzept ist simpel und genial zugleich – den Möglichkeiten sind hier keine Grenzen gesetzt, wie das folgende, etwas realitätsferne, Beispiel zeigt.

Hochverfügbarkeit ad absurdum

Wer gerne online soziale Kontakte pflegt, kennt die verschiedensten Instant-Messenger, von denen Skype, ICQ und Jabber nur drei prominente Vertreter sind. Um diese Protokolle auch unter Linux zu verwenden, gibt es Multiprotokoll-Messenger, wie beispielsweise Pidgin. Von Pidgin existiert eine Variation, die keine grafische Oberfläche verwendet und stattdessen auf eine curses-Textoberfläche zurückgreift – Finch. Dieses Tool dient hier als unternehmenskritische Applikation, die mithilfe von heartbeat später in einem Active/Passive Cluster betrieben wird. Das Resultat ist ein hochverfügbarer Instant-Messenger, der im Fehlerfall auf einen zweiten Node in einem anderen Brandabschnitt wechselt – ohne dabei seine Konfiguration und Protokolle zu verlieren. Sicherlich werden sich jetzt viele Leser fragen, wie sie bisher ohne eine solche Applikation leben konnten.

In diesem Beispiel gibt es zwei Raspberry Pi, die hinter jeweils einem herkömmlichen DSL-Router betrieben werden. Über eine Portfreigabe, die auf beiden Routern äquivalent einzurichten ist, ist ein Zugriff von “außen” (WAN) über SSH auf den Raspberry Pi möglich – idealerweise nimmt man hier jedoch nicht den Standardport 22. Über ein Tool namens GNU screen kann eine Terminal-Sitzung mit ausgeführten finch jederzeit fortgesetzt werden – so hat man von jedem Host mit Internetverbindung Zugriff auf die “Chat-Shell“. Die beiden Router sind in diesem Beispiel mit einem IPSec-VPN verbunden, die beiden Raspberry Pi können sich also anpingen und über einen verschlüsselten Kanal kommunizieren, obwohl sie sich in unterschiedlichen, voneinander getrennten, Netzwerksegmenten befinden.

Mithilfe eines Tools namens heartbeat wird später eine gegenseitige Überprüfung auf Verfügbarkeit durchgeführt (daher das VPN zwischen den Routern; die Clusternodes müssen einander anpingen können – eine andere Möglichkeit wäre ein Point-to-Point-VPN, beispielsweise mittels OpenVPN). Fällt ein Clusternode aus, bekommt dies der andere Node mit, übernimmt den Zugriff auf die gemeinsame Speicherressource (dazu später mehr!) und startet die Anwendung schnellstmöglich neu (entspricht dem Active/Passive Cluster-Prinzip).

Neben den zwei Raspberry Pi werden noch zwei USB-Sticks benötigt, die in diesem Aufbau das zu replizierende Blockgerät darstellen – DRBD mag keine Pseudo-devices, wie beispielsweise mit dd angelegte Dateien. Auf dieser “Cluster-Disk” werden die Konfigurations- und Protokolldateien von Finch gespeichert. So verfügt die Applikation stets über die selben Daten – unabhängig davon, wo sie gerade ausgeführt wird.

Aufbau und Netzwerk

Für dieses Beispiel habe ich mir einen NoIP-Hostname zugelegt – nach der Registrierung kann die mit dem dynamischen Hostname verbundene IP über ein NoIP-eigenes Linux-Utility aktualisiert werden. Dieses muss auf den beiden Raspberry Pi übersetzt und installiert werden:

both-nodes # apt-get install gcc curl
both-nodes # wget http://www.no-ip.com/client/linux/noip-duc-linux.tar.gz
both-nodes # tar xfz noip-duc-linux.tar.gz
both-nodes # cd noip-*
both-nodes # make && make install
...
Please enter the login/email string for no-ip.com  
Please enter the password for user '...'  ***
...
Please enter an update interval:[30]  44640
...

Standardmäßig läuft der NoIP-Client im Hintergrund – genau das wollen wir in diesem Cluster-Setup jedoch nicht. Über heartbeat erfolgt später ein geskriptetes Update im Falle eines Failovers. Wenn die Anwendung also von einem Node zum anderen wechselt, wird die IP-Adresse, mit der auf die Chat-Shell zugegriffen wird, aktualsiert. Durch eine manuelle Ausführung kann sichergestellt werden, dass das Tool ordnungsgemäß funktioniert:

any-node # /usr/local/bin/noip2 -i $(curl --silent http://icanhazip.com)
any-node # ping chat.noip.com

Für den späteren Clusterbetrieb müssen noch Software-Pakete für drbd und heartbeat installiert werden:

both-nodes # apt-get install drbd8-utils heartbeat

DRBD

Bevor der gemeinsame Clusterspeicher eingerichtet wird, ist es notwendig sicherzustellen, dass die beiden Nodes einander finden. Auch bei funktionierendem DNS sollte man hierfür immer einen lokalen Eintrag in der /etc/hosts vornehmen (um unabhängig von einem evtl. anfälligen DNS-Service zu sein) und die Nodes anpingen:

both-nodes # vi /etc/hosts
....

192.168.1.2   hostA.fqdn.dom hostA
192.168.2.2   hostB.fqdn.dom hostB

ESC ZZ

node-a # ping hostA
node-a # ping hostB
node-b # ping hostA
node-b # ping hostB

Die beiden angeschlossenen USB-Sticks werden neu partitioniert (vorhandene Partitionen werden entfernt), sie erhalten eine Linux-Partition (Typ 83). Anschließend wird die DRBD-Konfigurationsdatei angepasst:

both-nodes # fdisk /dev/sda << EOF
d
4
d
3
d
2
d
1

n
p
1

w
EOF

both-nodes # cp /etc/drbd.conf /etc/drbd.conf.initial
both-nodes # vim /etc/drbd.conf
...
resource drbd1 {
  protocol C;

  syncer {
    rate 75K;
    al-extents 257;
  }
  on hostA.fqdn.dom {
    device    /dev/drbd1;
    disk      /dev/sda1;
    address   192.168.1.2:7789;
    meta-disk internal;
  }
  on hostA.fqdn.dom {
    device    /dev/drbd1;
    disk      /dev/sda1;
    address   192.168.2.2:7789;
    meta-disk internal;
  }

}

Definiert wird hier ein Volume drbd1, welches auf den beiden Nodes hostA.fqdn.com und hostB.fqdn.com jeweils auf dem Gerät /dev/sda1 synchronisiert wird.

Sehr wichtig ist auch folgende Zeile:

rate 75K;

Sie definiert die maximale Synchronisierungsrate in Byte pro Sekunde, hier 75 KB/s. Die Synchronisierungsgeschwindigkeit ist von vielen Faktoren abhängig und sollte sorgfältig ausgewählt werden. Die Geschwindigkeit sollte beispielsweise nicht höher sein, als der verwendete Speicher es zulässt. Wenn für DRBD und die Applikation das gleiche Netzwerksegment verwendet wird (idealerweise hat man für DRBD ein eigenes Netzwerk), muss auf den üblichen Netzwerktraffic Rücksicht genommen werden.

Eine Faustregel besagt, den Wert der Syncer rate auf das 0.3-fache der effektiv verfügbaren Bandbreite zu setzen – ein Beispiel findet sich im Handbuch von DRBD:

110 MB/s Bandbreite * 0.3 = 33 MB/s
...
syncer rate = 33M;

Lässt das Netzwerk die definierte Maximalgeschwindigkeit nicht zu, wird automatisch gedrosselt. Mehr Informationen zur Synchronisation finden sich im Handbuch von DRBD: [klick mich!].

Anschließend wird einem Node das Volume angelegt, aktiviert und formattiert. Danach wird das neue Volume eingehängt:

node-a # drbdadm create-md drbd1

==> This might destroy existing data! <==
Do you want to proceed? [need to type 'yes' to confirm] yes ...

node-a # drbdadm up drbd1
node-a # drbdadm primary drbd1
node-a # mkfs.ext4 /dev/drbd1
both-nodes # mkdir /finch
node-a # mount /dev/drbd1 /finch

Auf dem anderen Node werden die Änderungen nachgezogen, was bei der initialien Synchronisierung schon etwas dauern kann (Zeit für einen Kaffee!) – in meinem Beispiel dauerte die Initialisierung eines 256 MB USB-Sticks über VPN bei 75 kbit/s Upload ca. eine Stunde – der Status kann über die Datei /proc/drbd eingesehen werden:

node-b # drbdadm connect drbd1
node-b # uptime
 16:40:30 up  2:08,  1 user,  load average: 0,20, 0,16, 0,10

both-nodes # cat /proc/drbd
version: 8.3.13 (api:88/proto:86-96)
srcversion: A9694A3AC4D985F53813A23

 1: cs:SyncTarget ro:Secondary/Primary ds:Inconsistent/UpToDate C r-----
    ns:0 nr:104320 dw:104320 dr:0 al:0 bm:6 lo:1 pe:2321 ua:0 ap:0 ep:1 wo:f oos:148564
        [=======>............] sync'ed: 42.0% (148564/252884)K
        finish: 0:32:11 speed: 64 (24) want: 71,680 K/sec

Sobald die Synchronisation abgeschlossen ist, sollte überprüft werden, ob Änderungen repliziert und Rollen problemslos gewechselt werden. Dazu wird folgendes ausgeführt:

• Erstellen einer Datei auf dem primären DRBD-Node, MD5-Summe erstellen
• Aushängen des Dateisystems, auf sekundäre Rolle herabstufen
• Heraufstufen des zweiten DRBD-Nodes, Dateisystem einhängen
• Datei finden, MD5-Prüfsumme überprüfen
• Datei löschen und weitere anlegen
• Zurückstufen der Rollen

In diesem Beispiel kann immer nur der primäre Node exklusiv auf das Volume zugreifen, der sekundäre Node hat keinen Zugriff auf das Volume. Soll ein Volume von beiden Nodes zeitgleich aktiv eingesetzt werden können (beispielsweise, weil ein Active/Active Cluster implementiert wird), ist ext4 hier das falsche Dateisystem. In einem solchen Fall muss ein Cluster-Dateisystem, wie GFS oder OCFS2, verwendet werden. Diese Dateisysteme bieten spezielle Locking-Mechanismen, die die Zugriffe der einzelnen Nodes auf das Volume regeln.

node-a # dd if=/dev/zero of=/finch/bla.bin bs=1024k count=1
node-a # md5sum /finch/bla.bin > /finch/bla.bin.md5sum
node-a # umount /finch
node-a # drbdadm secondary drbd1

node-b # drbdadm primary drbd1
node-b # mount /dev/drbd1 /finch
node-b # ls /finch
lost+found    bla.bin    bla.bin.md5sum
node-b # md5sum -c /finch/bla.bin.md5sum
/finch/bla.bin: OK
node-b # rm /finch/bla.bin*
node-b # dd if=/dev/zero of=/finch/foo.bin bs=1024k count=1
node-b # md5sum /finch/foo.bin > /finch/foo.bin.md5sum
node-b # umount /finch
node-b # drbdadm secondary drbd1

node-a # drbdadm primary drbd1
node-a # mount /dev/drbd1 /finch
node-a # ls /finch
lost+found    foo.bin    foo.bin.md5sum
node-a # md5sum -c /finch/foo.bin.md5sum
/finch/foo.bin: OK

Scheint wunderbar zu funktionieren!

Finch

Wie vorhin erwähnt, dient der Multiprotokoll-Messenger Finch (Pidgin) in diesem Fall als unternehmenskritische Applikation. Wie es sich für eine solche Applikation gehört, bekommt sie einen Serviceuser mit einer einheitlichen UID verpasst, damit das Tool nachher über heartbeat auf den Nodes geskriptet gestartet werden kann. Hierzu wird GNU Screen als Terminal-Multiplexer verwendet, um das Tool im Hintergrund zu starten und die Möglichkeit zu schaffen, remote auf die Sitzung zuzugreifen.

both-nodes # apt-get install screen finch
both-nodes # useradd -u 1337 -m -d /finch/home su-finch
both-nodes # gpasswd -a su-finch tty
both-nodes # passwd su-finch

Die Hinzufügen von su-finch in die Gruppe tty ist übrigens notwendig, damit GNU screen später auf das Terminal zugreifen kann, wenn es über den su-Mechanismus gestartet wird.

Vorab kann man finch allerdings schon mal konfigurieren und ein Instant Messenger-Konto seiner Wahl hinzufügen:

node-a # su - su-finch
node-a # screen
node-a # finch

Wer schon einmal Pidgin benutzt hat, wird die Buddy-Liste und Chat-Fenster wiedererkennen.

Die Fenster werden in der Regel mittels Tastenkombinationen gewechselt, in Kombination mit GNU screen besteht jedoch auch die Möglichkeit der Maussteuerung. Einige wichtige vordefinierte Tastenkombinationen:

• nächstes Fenster: ALT + N
• vorheriges Fenster: ALT + P
• markiertes Fenster schließen: ALT + C
• Kontextmenü aufrufen: F11
• Aktionsmenü aufrufen: ALT + A
• Menü des aktuellen Fensters aufrufen: STRG + P

heartbeat – Computer, lebst Du noch?

heartbeat dient primär, wie der Name vermuten lässt, zur Kommunikation von Clusternodes, um deren Verfügbarkeit zu gewährleisten. Das Tool kommuniziert mit benachbarten Clusternodes regelmäßig über einen verschlüsselten Tunnel und kann so schnell auf Ausfälle reagieren. Tritt ein solcher Ausfall ein, starten vorher definierte Skripte, um diesen zu kompensieren. In diesem Beispiel werden zwei Cluster-Resourcen auf dem nächsten Node neugestartet: der gemeinsame DRBD-Speicher und der Dienst finch.

Im Cluster-Betrieb kann es, je nach Größe und Applikation, erforderlich sein, sicherzustellen, dass fehlerhafte Nodes an der Wiederaufnahme ihrer Dienste gehindert werden. Dieser Mechanismus wird als STONITH (Shoot the other node in the head) bezeichnet. Es gibt zahlreiche Schnittstellen, um das “Liegenbleiben” des fehlerhaften Clusternodes zu bewerkstelligen, beispielsweise:

• Remote-Interface des Servers (iLO, DRAC, LOM,…)
• USV, an der der Server angeschlossen ist
• PDU (Power Distribution Unit), über welche der Clusternode mit Strom versorgt wird
• Blade-Enclosure Management-Schnittstelle

Wird kein STONITH angewandt, kann es im Extremfall zu Datenkorruptionen kommen, wenn beide Clusternodes (beispielsweise aufgrund eines Netzwerkausfalls) der Meinung sind, der einzig aktive Node zu sein und ihre Applikation ausführen. Implementieren lässt sich STONITH auch unter Linux – unter anderem mit heartbeat oder Pacemaker. In diesem Beispiel würde das jedoch den Rahmen der Übersichtlichkeit sprengen.

Anwendungen lassen sich mit heartbeat sehr einfach im Cluster betreiben, da zur Dienst-Steuerung auf herkömmliche Init-Skripte zurückgegriffen wird. Im Idealfall kann man einfach mit symbolischen Links arbeiten, um einen Dienst in das Cluster zu integrieren.

In diesem Beispiel wird ein benutzerdefiniertes Init-Skript angelegt, welches Finch startet und anschließend den NoIP-Hostname aktualisiert.

Zuerst wird eine clusterweite Konfigurationsdatei (/etc/ha.d/ha.cf) angelegt, in ihr werden grundlegende Parameter, wie Logdateien und Schwellwerte definiert:

node-a # vi /etc/ha.d/ha.cf
debugfile /var/log/ha-debug
logfile /var/log/ha-log
logfacility local0
keepalive 10
deadtime 30
warntime 20
initdead 60
ucast eth0 192.168.2.2
udpport 694
auto_failback off
node hostA.fqdn.dom
node hostB.fqdn.dom

ESC ZZ

node-b # vi /etc/ha.d/ha.cf
...
ucast eth0 192.168.1.2
...

ESC ZZ

Die Datei unterscheidet sich je Node in einer Zeile (ucast) – hier ist jeweils die IP-Adresse des anderen Nodes einzutragen.

Zu den einzelnen Parametern:

• debugfile / logfile / logfacility – Debug-Log und herkömmliches Log; zu verwendende Syslog-Facility
• keepalive – Zeitabstände in Sekunden, in denen Keepalives versendet werden
• warntime – Zeitspanne, ab wann ein Node zu verfallen droht
• deadtime – Zeitspanne, ab wann ein Node tot zu sein scheint
• initdead – Zeitpunkt, ab wann ein Node aus dem Cluster entfernt wird
• ucast – IP-Adresse, an welche über Unicast Heartbeat-Pakete versendet werden
• udpport – UDP-Port
• auto_failback – definiert, ob nach Wiedereintritt eines Clusternodes die Ressourcen zurückverschoben werden sollen (sofern dieser Clusternode ein präferierter Node für bestimmte Ressourcen war)
• node – definiert die vorhandenen Clusternodes nacheinander

Da die Clusterkommunikation verschlüsselt abläuft, muss auf beiden Clusternodes eine Datei unter /etc/ha.d/authkeys angelegt werden:

both-nodes # vi /etc/ha.d/authkeys
auth 1
1 sha1 superlangesundsicherespasswort08151337666

Anschließend erfolgt eine Zuteilung der jeweiligen Cluster-Ressourcen – in der Datei /etc/ha.d/haresources:

both-nodes # vi /etc/ha.d/haresources
hostA.fqdn.dom
hostB.fqdn.dom  drbddisk::drbd1 Filesystem::/dev/drbd1::/finch::ext4    finch

Die Datei listet zunächst einmal alle Clusternodes und – durch einen Tab abgetrennt – deren primäre Ressourcen auf. In diesem Beispiel gibt es zwei Hosts, wovon der zweite der primäre Clusternode für folgende Ressourcen ist:

• exklusiv verwendetes DRBD-Volume drbd1
• ext4-Dateisystem auf /dev/drbd1, welches unter /finch eingehängt wird
• Den Dienst finch (/etc/init.d/finch)

Das bedeutet: sofern beide Clusternodes zur Verfügung stehen, werden die oben genannten Ressourcen immer auf Node 2 (hostB.fqdn.dom) gestartet. Steht der Node nicht zur Verfügung, werden die Ressourcen auf Node 1 (hostA.fqdn.dom) gestartet. Ein automatisches “Zurückverschieben” der Ressourcen erfolgt aufgrund der Einstellung “auto_failback off” (in /etc/ha.d/ha.cf) nicht.

Zuletzt fehlt noch das Initskript zum Starten und Stoppen des Finch-Dienstes – wie bei herkömmlichen Diensten, wird das Skript unter /etc/init.d/finch abgelegt:

# vi /etc/init.d/finch
#!/bin/bash
#
# finch        Startup script for finch including noip update
#

start() {
        /usr/local/bin/noip2 -i $(curl --silent http://icanhazip.com) >/dev/null 2>&1
        chmod g+rw $(tty)
        su -c "screen -d -m" su-finch
        RESULT=$?
        return $RESULT
}
stop() {
        /usr/bin/killall -u su-finch
        RESULT=$?
        return $RESULT
}
status() {
        su -c "screen -ls" su-finch
        cat /proc/drbd
        dig +short foo.noip.com
        RESULT=$?
        return $RESULT
}

case "$1" in
  start)
        start
        ;;
  stop)
        stop
        ;;
  status)
        status
        ;;
  *)
        echo $"Usage: finch {start|stop|status}"
        exit 1
esac

exit $RESULT

Das eben erwähnte Initskript kennt die Parameter start, stop und status – und dürfte damit sogar schon fast LSB-kompatibel sein.

Je nach Parameter wird eine GNU screen-Sitzung unter dem Benutzerkonto von su-finch (Servicebenutzer) gestartet oder beendet – bei der Verwendung des status-Parameters werden aktuelle DRBD- und IP-Zuordnungen inklusive offener Sitzungen angezeigt.

Wenn heartbeat finch-Ressourcen startet oder stoppt, wird dieses Skript verwendet.

Funktionstest

Schön, das war jetzt viel Theorie – doch wie sieht’s in der Praxis aus? Funktioniert das überhaupt?

Natürlich – und das zeigt das folgende Beweisvideo am Besten:

Monitoring

Wie es sich für unternehmenskritische Anwendungen gehört, darf ein entsprechendes Monitoring nicht fehlen. Neben der Verfügbarkeit der einzelnen Nodes ist der DRBD- und heartbeat-Status von Interesse. Während sich die Verfügbarkeit des heartbeat-Dienstes kinderleicht mit dem altbekannten check_procs Nagios-/Icinga-Plugins überprüfen lässt, gibt es für DRBD auf der Webseite von MonitoringExchange ein Shell-Skript zum kostenfreien Download: [klick mich!]

Dieses Skript lässt sich ohne Probleme in Nagios bzw. Icinga einbinden und verwenden, hier beispielsweise auf einer passiven Icinga-Instanz:

# cat /etc/icinga/commands.cfg
...
# 'check_drbd' command definition
define command{
        command_name    check_drbd
        command_line    $USER2$/check_drbd -d $ARG1$ -e "Connected" -o "UpToDate" -w "SyncingAll" -c "Inconsistent"
}

# cat /etc/icinga/objects/hostA.cfg
...
define service{
        use                             generic-service
        host_name                       hostA
        service_description             HW: drbd1
        check_command                   check_drbd!1
        }

Im oben zu sehenden Beispiel wird überprüft, ob das drbd-Volume /dev/drbd1 zur Verfügung steht. Sofern die Plugin-Antwort (auf Basis der Datei /proc/drbd) nicht “Connected/UpToDate” lautet, liegt ein Fehler vor. Bei aktiver Synchronisation (SyncingAll) wird eine Warnung ausgegeben, ein inkonsistentes Volume (Inconsistent) ergibt einen Fehler.

Fazit

Zweifelsfrei ist dieses Anwendungsbeispiel eher realitätsfern und belustigend. Ich wollte damit zeigen, wie einfach die Implementation von Hochverfügbarkeit unter Linux sein kann. Es gibt viele Wege, die zum Ziel führen – mit heartbeat und DRBD ist hier nur eine von vielen HA-Konstellationen genannt. Die Thematik ist bei weitem nicht so komplex, wie oftmals fälschlicherweise angenommen. Ob nun eine Datenbank oder ein Instant-Messenger über heartbeat “geclustert” wird, ist erstmal irrelevant – der Implementationsaufwand ist überschaubar.

heartbeat gilt eher als veraltetes Tool, mit Pacemaker und OpenAIS/Corosync gibt es zwei modernere Programme, mit denen sich in Kombination mit DRBD weitaus komplexere und umfangreichere HA-Szenarien bewerkstelligen lassen.

Prinzipiell sollte man vor der Implementation von Software HA-Lösungen zuerst die Hardware-Komponenten redundant auslegen – in diesem Beispiel gibt es einige Architekturfehler, die man im Praxisfall idealerweise beheben sollte:

• kein dediziertes Netzwerk für Node-Kommunikation (Heartbeat-Netzwerk)
• kein redundanter Speicher für den Clusterspeicher (RAID-Volume)
• Netzwerkadapter sind nicht redundant gehalten (keine doppelten NICs und entsprechend verbundenen Switches; LACP?)
• keine redundante Stromversorgung

Immerhin wurden hier verschiedene Brandabschnitte gewählt (die Raspberry Pi stehen in zwei verschiedenen Wohnungen)!

Wer jedoch Interesse daran hat, seinen Instant-Messenger redundant zu halten, weiß ja nun, wie es geht.

Ich erinnere mich noch genau an meinen ersten eigenen Rechner, der seinen Dienst mit MS-DOS verrichtete – hier habe ich erste Programmier-Erfahrungen mit Microsoft QBasic sammeln können. Später folgten Microsoft Visual Basic und Borland Delphi. Bevor ich mit PHP und Java zwei Programmiersprachen entdeckt habe, die mich bisher am stärksten interessierten, beschäftigte ich mich oberflächlich mit C und C++.

Im Laufe der letzten Jahre habe ich immer wieder gelegentlich programmiert – nicht zuletzt, um Lösungen für persönliche, recht spezielle Anwendungsanforderungen zu implementieren und zu veröffentlichen – beispielsweise checkform und JTrainer.

Mit dem ersten Android-Smartphone vor zwei Jahren entstand Interesse an der Programmierung von “Apps“. Da ich schon Erfahrungen mit modernen Web-Schnittstellen und Java hatte, konnte ich schnell an vorhandenes Wissen anknüpfen. Schon nach kurzer Zeit entstand meine erste Android-App – JTrainer für Android.

Weiterbildungsstipendium

Vor zwei Jahren, als ich meine Ausbildung zum Fachinformatiker absolvierte, hatte ich das Glück von der durch die IHK beworbenen Begabtenförderung (ugs. Weiterbildungsstipendium) der SBB (Stiftung Begabtenförderung berufliche Bildung) zu profitieren.

Einmal im Jahr werden, je nach Kammer, zwischen 30 und 50 Plätze verteilt – über die Verteilung entscheidet ein Ausschuss, bei welchem man sich idealerweise mit einem interessanten Projekt oder einer gut durchdachten beruflichen Zukunftsvision bewirbt. Ich selbst habe mich mit einem Projekt, über das ich noch nicht zu viel verraten möchte, beworben – und hatte das Glück ausgewählt zu werden. Jedem Stipendat stehen über drei Jahre lang bis zu maximal 6.000 EUR insgesamt für förderfähige Leistungen, wie beispielsweise Schulungen oder Lernmaterialien, zur Verfügung.

Ich kann nur jedem, der prinzipiell für das Stipendium infrage kommt, nahelegen, sich zu bewerben! Die Chancen einen Platz zu bekommen sind höher, als man sich vorstellt. Ich habe mich letztendlich einfach auf “gut Glück” beworben und hatte nicht wirklich damit gerechnet, ernsthaft davon profitieren zu können.

Weitere Informationen zum Weiterbildungsstipendium gibt es auf der Homepage der SBB: http://www.sbb-stipendien.de

Objective-C Schulungen – die Qual der Wahl

Natürlich sprangen mir gleich zahlreiche Ideen in den Kopf, die Förderleistungen des Staats in Anspruch zu nehmen – eine geplante Schulung sollte sich um die Entwicklung von Anwendungen für Apple Smartphones und Tablets drehen.

Fakt ist – wer mit einem Online-Projekt und mobilen Apps erfolgreich sein will, kommt um eine native iOS-Anwendung nicht herum. Auch wenn die Verbreitung von iPhones und iPads durch immer stärkere Android-Konkurrenten gelitten hat, sind die mobilen Gerätschaften aus Cupertino weiterhin sehr beliebt.

Ich habe nach einer entsprechenden Schulung gesucht – und entdeckt, dass der Markt hier recht groß ist. iOS und Objective-C Schulungen gibt es mittlerweile von vielen Anbietern – den Überblick zu behalten fällt hier schwer. Ich habe primär nach einer bezahlbaren Schulung gesucht, die in meiner Nähe stattfindet und über eine möglichst breite Agenda verfügt. Viele der gefundenen Schulungen waren sehr teuer und bedienten sich dabei lediglich sehr oberflächlicher Gliederungen (“Was ist iOS? Was ist Objective-C? Hello World, danke und Tschüß!”).

ObjectiveCeeds – development and training made in Baden-Würtemberg

In einem Blog-Artikel (den ich jetzt leider nicht mehr finde) habe ich vom IT-Freiberufler Manfred Kreß erfahren. Unter dem Namen ObjectiveCeeds bietet er Schulungen rund um die Themen Objective-C, OS X und iOS an. Als erfahrener Software-Entwickler und freiberuflicher IT-Dozent beschäftigt sich Manfred Kreß stets mit den aktuellen Errungenschaften der Apple-Programmierung und gibt diese pädagogisch wertvoll weiter.

Mir ist sofort die umfassende Agenda, die neben Grundlagen in Objective-C auch ein breites Spektrum an iOS-relevanten Themen enthielt, aufgefallen – das konnte ich bisher in keiner anderen Schulung in der selben Preiskategorie finden.

Ein absolutes Highlight ist der äußerst ausgefallene und exklusive Seminarort – das Bonsai Zentrum Heidelberg. Ich habe ja schon an einigen Schulungen teilgenommen, aber so eine geniale Location war bisher noch nicht dabei!

Zwischen formschönen Bonsais wird munter programmiert und entwickelt – in den Pausen gibt es neben den zahlreichen Schalen-Bäumen auch viele farbenfrohe Kois zu beguachten. Eine angenehmere Seminaratmosphäre habe ich bis dato nicht erlebt.

Da die Teilnehmergruppen meist nicht größer als 6, 7 sind, bleibt immer Zeit für Zwischenfragen und Troubleshooting am Teilnehmer-Notebook. Um an der Schulung teilzunehmen, ist es übrigens nicht notwendig, ein MacBook sein Eigen zu nennen – es besteht die Möglichkeit, für drei Tage Schulung ein MacBook Pro zu leihen.

Mir hat die Schulung sehr viel Spaß gemacht. Neben der Vielfalt der Bonsai-Kunst sind mir nun auch die Grundlagen der Objective-C und iOS-Programmierung bekannt – Ziel erreicht.

Wenn sich in den nächsten Jahren etwas an meinem akuten Zeitmangel ändert, weiß ich, welche Kunst ein interessantes Hobby für mich wäre – die Bonsai-Kunst. Ich habe mich bisher nie damit beschäftigt und war verdutzt, wie spannend dieses Hobby doch eigentlich ist. Wer sich für Botanik oder speziell Bonsai interessiert, sollte unbedingt mal das Bonsai Zentrum Heidelberg besuchen.

Résumé

Wer sich ernsthaft mit Objective-C- und iOS-Programmierung beschäftigen möchte und nach einer Schulung mit einem fairen Preis-/Leistungsverhältnis sucht, sollte sich die Seminarangebote von ObjectiveCeeds näher anschauen.

Ich war sehr zufrieden mit der angenehmen Seminaratmosphäre, der inhaltlichen Agenda und dem locker-lustigen Schulungssstil von Manfred Kreß.

Ich hatte mich schon vor einiger Zeit mit Buch und Mac Mini in den Dschungel der Apple-Programmierung begeben. Viele Dinge sind einfach unverständlich geblieben – das hat sich mit dieser Schulung geändert.

Wer mehr über das Angebot von ObjectiveCeeds erfahren möchte, sollte sich die Webseite von Manfred Kreß anschauen: http://www.objectiveceeds.com.

OpenVPN-Profile

Mit OpenVPN Connect gibt es einen guten OpenVPN-Client für iOS-Geräte ab der Version 5.0.

Mithilfe der App können ganz komfortabel mehrere VPN-Tunnel verwaltet und verwendet werden. Die jeweiligen OpenVPN-Konfigurationsdateien lassen sich jedoch nicht direkt am iPhone, iPod oder iPad anpassen, wie man das beispielsweise von der Android-App kennt. Die erste Einrichtung gestaltet sich demnach also etwas anspruchsvoller, da man die Konfigurationsdateien am Rechner anpassen und anschließend mittels iTunes übertragen muss.

Darüber hinaus gibt es noch einige weitere Einschränkungen:

• Zertifikate müssen in die OpenVPN-Konfigurationsdatei integriert werden
• TAP-Devices werden derzeit nicht unterstützt
• Fehlermeldungen bei der Zertifikatverwaltung sind nicht scrollbar, passen im vertikalen Modus nicht auf den Bildschirm

Die jeweilige iOS OpenVPN-Konfiguration variiert je nach Serverkonfiguration. Wie bereits erwähnt werden TAP-Konfigurationen derzeit nicht unterstützt.

Ich verwende OpenVPN in Verbindung eines IPCop-Routers. Dieser verwendet standardmäßig TUN und Zertifikate für Benutzer- und CA. In dieser Konstellation ist es erforderlich, die einzelnen Zertifikate (Benutzer, CA) zu extrahieren (benötigt ein installiertes OpenSSL) damit sie anschließend in die OpenVPN-Konfiguration integriert werden können:

# openssl pkcs12 -in name.p12 -nocerts -nodes -out keys.pem
Enter Import Password:
MAC verified OK
# openssl pkcs12 -in name.p12 -cacerts -nodes -out ca.pem
Enter Import Password:
MAC verified OK
# openssl pkcs12 -in name.p12 -out name.pem
Enter Import Password:
MAC verified OK
Enter PEM pass phrase:

Das von IPCop / IPFire erzeugte Client-ZIP enthält eine fertige Konfigurationsdatei, die noch angepasst werden muss. Das vermerkte Krypto-Archiv (pkcs12) wird entfernt oder auskommentiert – die jeweiligen, vorher extrahierten Zertifikate, werden im XML-Syntax angehängt:

#OpenVPN Server conf
tls-client
client
dev tun
proto udp
tun-mtu 1400
remote HOSTNAME PORT
#pkcs12 name.p12
cipher BF-CBC
verb 3
ns-cert-type server

#ca.pem
<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>
#name.pem
<cert>
-----BEGIN CERTIFICATE-----
....
-----END CERTIFICATE-----
</cert>
#keys.pem
<key>
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
</key>

Anschließend wird die OpenVPN-Konfiguration gespeichert und mittels iTunes auf das iOS-Gerät übertragen. Hierfür sollte nach der Installation von OpenVPN Connect eine entsprechende Registerkarte (nach unten scrollen!) existieren.

OpenVPN-Log

Mittels Drag & Drop kann die Datei komfortabel übertragen werden. Auf dem iOS-Gerät wird das neue Profil erkannt und kann anschließend importiert werden.

Verbindungsaufbauten werden automatisch mitgeloggt – im Fehlerfall kann man also nachlesen, warum die Verbindung nicht zustandekommt. Aktive VPN-Verbindungen werden, wie IPSec- und PPTP-Tunnel mit einem VPN-Icon angezeigt.

# netstat -r|grep default

…obwohl ein entsprechendes Gateway sowohl in der Netzwerk-Hauptkonfiguration…

# cat /etc/sysconfig/network
...
GATEWAY=10.24.36.1

…als auch in der Schnittstellen-Konfiguration vermerkt wurde:

# cat /etc/sysconfig/network-scripts/ifcfg-eth0
...
GATEWAY=10.24.36.1

Abhilfe schafft hier folgender Eintrag in einer noch anzulegenden Routing-Datei:

# vi /etc/sysconfig/network-scripts/route-eth0
default via 10.24.36.1 dev eth0 onlink

Nach einem Neustart des Netzwerkes wird die Standard-Route vermerkt:

# service network restart
# netstat -r|grep default
default       10.24.36.1     0.0.0.0     UG    0 0     0 eth0

2006 wurde eine Petition gestartet – Inhalt dieser war die Freilegung des CDE-Programmcodes. Nach 6 Jahren wurde der lang ersehnte Quellcode im September 2012 veröffentlicht. CDE steht seitdem in einer Alpha-Version für Linux zur Verfügung.

Zur Liste der derzeit unterstützten Linux-Distributionen gehört auch Debian Squeeze – Zeit, sich das Ganze auch mal anzuschauen, oder?

Vorbereitung

Sofern noch nicht vorhanden, müssen HAL, DBUS und die X-Server Kernkomponenten installiert werden:

# apt-get install xserver-xorg-core xinit dbus hal xserver-xorg-input-kbd xserver-xorg-input-mouse xserver-xorg-input-vmmouse

CDE benötigt noch einige Entwicklerwerkzeuge und -bibliotheken, die ebenfalls nachinstalliert werden müssen:

# apt-get install git libxp-dev libxt-dev libxmu-dev libxft-dev libxaw7-dev libx11-dev libjpeg-dev libjpeg62-dev libfreetype6-dev lesstif2 x11-xserver-utils ksh m4 ncompress xfonts-100dpi* rpcbind bison xbitmaps libmotif* x11-xserver-utils tcl-dev lprng

Übersetzung

Der Quellcode kann entweder über den GIT-Mirror oder über einen aktuellen Tar-Snapshot bezogen werden. Anschließend werden X-Server Header verlinkt und CDE übersetzt. Nach erfolgreicher Übersetzung werden Installations- und Konfigurationsskripte ausgeführt und ein Spool-Directory für die Kalender-Anwendung angelegt.

Weitere Informationen finden sich in der offiziellen Installationsanleitung: [klick mich!]

# w3m http://downloads.sourceforge.net/project/cdesktopenv/src/cde-src-2.2.0c-alpha.tar.gz
# tar xfz cde-src-2.2.0c-alpha.tar.gz
# cd cdesktopenv-code/cde
# mkdir -p imports/x11/include
# cd imports/x11/include
# ln -s /usr/include/X11 .
# cd cdesktopenv-code/cde
# make World
# admin/IntegTools/dbTools/installCDE -s /path-to-cdesktopenv-code/cde/
# admin/IntegTools/post_install/linux/configRun -e
# chmod -R a+rwx /var/dt
# mkdir -p /usr/spool/calendar

Display-Manager

Man kann entweder den ebenfalls auf Motif basierenden dtlogin Display-Manager verwenden…

# export PATH=$PATH:/usr/dt/bin
# LANG=C /usr/dt/bin/dtlogin

…oder einen neueren Display-Manager, wie beispielsweise SLiM, dahingehend konfigurieren, dass er CDE startet:

# apt-get install slim
# vi /etc/slim.conf
...
#login_cmd           exec /bin/bash -login /etc/X11/Xsession %session
login_cmd        exec /bin/bash -login /usr/dt/bin/startxsession.sh

ESC ZZ

# vi /usr/dt/bin/startxsession.sh
#!/bin/sh
export PATH=$PATH:/usr/dt/bin
export LANG=C
/usr/dt/bin/Xsession

ESC ZZ

# service slim start

Galerie

Anbei natürlich noch einige Screenshots des Retro-Desktops:

Auf den ersten Blick sehen die beiden Produkte gleich aus und auch aus technischer Sicht gibt es starke Ähnlichkeiten, da die Produkte beide auf der selben quelloffenen Software-Kernkomponenten aufbauen: Red Hat Spacewalk. Red Hat Spacewalk wurde 2008 durch Red Hat als Open-Source freigegeben und bildet die Basis für den kommerziellen Satellite Server.

Wo genauen liegen also die Unterschiede zwischen den Produkten? Die folgende Tabelle zeigt die Gemeinsamkeiten und Detailunterschiede:

Zentrale Verwaltung von RHEL- und SLES-Systemen mit einer Suite?

Was für Möglichkeiten bestehen für den Fall, dass RHEL- und SLES-Systeme parallel betrieben und zentral verwaltet werden sollen?

Genau die Frage habe ich mir auch gestellt, im Internet recherchiert und über Twitter einen Kontakt zu SUSE geknüpft.

Letztendlich gibt es zwei denkbare Möglichkeiten – ob diese praktikabel sind, liegt im eigenen Ermessen des Administrators.

1.Möglichkeit – SUSE Expanded Support

Im Rahmen des “SUSE Expanded Support” bietet SUSE neben den eigenen SLES-Patches auch digitale Flicken für RHEL. Das Ganze ist für langwierige Migrationen gedacht und soll den Red Hat Support überflüssig machen, da Patches nicht mehr direkt über das Red Hat Network bezogen werden. Die Patches kommen direkt von SUSE, wo sie aus den von Red Hat veröffentlichten Quellcodes übersetzt werden. Letztendlich sollte die Qualität der Software-Pakete die selbe sein, da sie ja dem gleichen Quellcode entspringen – ich persönlich würde es jedoch bevorzugen, meine Distributionspatches auch vom ursprünglichen Distributor zu erhalten.

Wenn man nicht gerade eine Migration plant und lediglich beabsichtigt, das Beste aus beiden “Welten” zu kombinieren, ist dieser Lösungsansatz meiner Meinung nach nicht der Beste.

2.Möglichkeit – mrepo

Eine andere Möglichkeit wäre die Verwendung eines Tools namens mrepo. Dieses Programm legt einen Spiegel eines YUM-Repositories an und stellt so die jeweiligen RPM-Pakete lokal zur Verfügung – laut Webseite soll das auch mit RHN-Kanälen möglich sein. Ich kann mir nur schwer vorstellen, dass diese Lösung lizenzrechtlich unbedenklich ist, da das lokale Vorhalten von RPM-Paketen aus dem RHN ja bewusst erschwert wird. In aller Regel soll das lokale Cachen nur über den RHN Satellite Server erfolgen.

Für Testzwecke wäre das sicherlich eine denkbare Lösung, in produktiven Umgebungen, in welchen ein sauberer Support-Status stets gegeben sein muss, würde ich von diesem Ansatz jedoch Abstand nehmen.

Fazit

Letztendlich handelt es sich bei RHN Satellite und SUSE Manager um identische Produkte (quasi “das Selbe in grün”  ) – an eine unkomplizierte Kombination von beiden “Welten” ist jedoch leider nicht zu denken.

Das Problem ist dabei weniger technischer, sondern lizenzrechtlicher Natur, wie ich kürzlich in einem Gespräch mit einem SUSE-Mitarbeiter erfahren habe. Die Gründe sind natürlich auch nachvollziehbar – die Hersteller wollen natürlich in erster Linie ihr eigenes Produkt “an den Mann bringen“, um konkurrenzfähig zu bleiben.

Wenn man beide Produkte verwendet und eine zentrale Management-Suite sucht, muss man sich meiner Meinung nach entweder für eine Migration der anderen Systemlandschaft entscheiden oder mehr Geld in die Hand nehmen, um beide Produkte parallel zu betreiben. Alternativ kann man sich auch eines Tricks bedienen, um RPM-Pakete aus dem Red Hat Network zwischenzuspeichern und zu verteilen. Wenn es keine Rolle spielt, woher die zu installierenden RHEL-Patches stammen, kann man auch auf den “SUSE Expanded Support” zurückgreifen.

Ich persönlich lege großen Wert auf lückenlosen Support durch den ursprünglichen Distributor und würde mich daher in jedem Fall für die Implementation beider Management-Produkte entscheiden.

Galerie

Anbei noch einige Screenshots der einzelnen Management-Suiten.

ifconfig war 1983 das erste Mal Bestandteil der 4.2BSD-Distribution und entwickelte sich rasch zum Standard-Tool zur Netzwerkkonfiguration unter Linux – auch in kommerziellen Unices, wie Solaris oder HP-UX nahm das Programm Einzug.

Einige Linux-Distributionen setzen ifconfig nicht mehr ein (z.B. ArchLinux) – andere Distributionen (z.B. SuSE/SLES und Fedora) weisen darauf hin, dass das Tool bald nicht mehr zur Verfügung stehen wird:

# man ifconfig
...
       WARNING: Ifconfig is obsolete on system with Linux  kernel  newer  than
       2.0.  On  this  system  you  should  use ip. See the ip manual page for
       details
...
NOTE
       This program is obsolete! For replacement check ip addr and ip link.
       For statistics use ip -s link.

Unter Solaris gibt es seit Version 11 dafür das Kommando ipadm (danke für den Tipp, Prometheus!).

ip funktioniert ab Linux 2.2. Es ist moderner und vereint darüber hinaus u.a. die Funktionen der Tools route und arp.

Anbei einige der wohl meist verwendeten ifconfig-/route-Aufrufe und deren ip-Pendants:

ifconfig

ip addr show

ifconfig eth0

ip addr show eth0

ifconfig eth0 down

ip link set eth0 down

ifconfig eth0 up

ip link set eth0 up

ifconfig eth0 [IP] netmask [NM]

ip addr [IP]/[CIDR] dev eth0

route
netstat -r

ip route

route add default gw [IP] eth0

ip route add default via [IP]

ip kann natürlich noch eine Menge mehr – um mal ein paar Beispiele zu nennen:

• MTU und Promiscuous Mode aktivieren/deaktivieren
• Multicasting und VLANs konfigurieren
• ARP-Tabellen verwalten

Ähnlich ist es mit nslookup, da schon seit geraumer Zeit obsolet ist. Mit host und dig gibt es zwei Nachfolger-Tools, die einiges mehr beherrschen. Der quelloffene DNS-Server bind rät vom Einsatz von nslookup ab (Quelle):

Due to its arcane user interface and frequently inconsistent
behavior, we do not recommend the use of nslookup.
Use dig instead.

Anbei einige geläufige nslookup-Befehle und deren dig-Pendants.

nslookup google.de

dig google.de
dig +short google.de

nslookup [IP]

dig -x [IP]
dig +short -x [IP]

nslookup google.de [DNS]

dig @[DNS] google.de
dig @[DNS] +short google.de

nslookup -query=mx google.de

dig google.de MX
dig +short google.de MX

nslookup -timeout=42 google.de

dig google.de +time=42
dig +short google.de +time=42

Die Option +short ist recht nützlich, wenn man einfach nur eine IP, bzw. einen Hostname erhalten will. Standardmäßig gibt dig noch zahlreiche Zusatzinformationen, wie beispielsweise die IP des verwendeten DNS-Servers und dessen Antwortzeit, aus:

; <<>> DiG 9.9.2-P2 <<>> google.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33883
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 16384
;; QUESTION SECTION:
;google.de.                     IN      A

;; ANSWER SECTION:
google.de.              300     IN      A       173.194.44.56
google.de.              300     IN      A       173.194.44.55
google.de.              300     IN      A       173.194.44.63

;; Query time: 66 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Sun Apr  7 17:18:22 2013
;; MSG SIZE  rcvd: 86

# dig +short google.de
173.194.44.55
173.194.44.56
173.194.44.63

Auch hier lohnt sich ein Blick in die Manpage von dig, da das Tool weitaus mehr Features, als die eben kurz angesprochenen, bietet.

Wer also gerne bastelt oder Raspbian “zu Mainstream” findet, kann mit einer SD-Speicherkarte mit mindestens 1 GB Speicher und einer Kanne Kaffee jede Menge Spaß haben.

Partitionierung und Einhängen

Die folgenden Partitionen müssen auf der SD-Karte angelegt werden:

• 1.Partition, später /dev/mmcblk0p1 – /boot, VFAT, mindestens 100 MB
• 2.Partition, später /dev/mmcblk0p2 – /, ext3, mindestens 512 MB
• 3.Partition, später /dev/mmcblk0p3 – swap, idealerweise 100-512 MB

Idealerweise macht man das unter Linux, da im Anschluss noch Archive im neuen Dateisystem entpackt werden müssen:

# fdisk /dev/sdX
...
# mkfs.vfat /dev/sdX1
# mkfs.ext3 /dev/sdX2
# mkswap /dev/sdX3
# mkdir -p /mnt/{b,r}oot
# mount /dev/sdX2 /mnt/root
# mount /dev/sdX1 /mnt/boot

Kopieren und Konfigurieren

Auf die FAT-Partition werden nun die folgenden Dateien kopiert:

• alle Dateien (mit Ausnahme von kernel_emergency.img) aus dem folgenden GIT-Tree: https://github.com/raspberrypi/firmware/tree/master/boot
• Angepasster Kernel: http://crux-arm.nu/files/devices/raspberrypi/current/kernel.img
• RAMDisk: http://crux-arm.nu/files/devices/raspberrypi/current/initrd.gz
• Boot-Konfigurationsdatei: http://crux-arm.nu/files/devices/raspberrypi/cmdline-ramdisk.txt – bitte als cmdline.txt speichern
• Kernel-Module: http://crux-arm.nu/files/devices/raspberrypi/current/modules-3.6.1-raspberrypi_20130305.tar.xz
• CRUX-ARM 2.8 Root-Dateisystem für den Raspberry Pi: http://crux-arm.nu/releases/2.8/crux-arm-rootfs-2.8-hardfp-raspberrypi.tar.xz

Nachdem alle Dateien kopiert wurden, werden das Root-Dateisystem und die Kernel-Module entpackt:

# tar -pxf /mnt/boot/crux-arm-rootfs-2.8-hardfp-raspberrypi.tar.xz -C /mnt/root
# tar -pxf /mnt/boot/modules-3.6.1-raspberrypi_20130305.tar.xz -C /mnt/root

Anschließend werden noch einige Zeilen der /etc/fstab angepasst:

# vi /mnt/root/etc/fstab
...#/dev/#REISERFS_ROOT#  /         reiserfs  defaults               0      0
/dev/mmcblk0p2    /         ext3      defaults               0      1
/dev/mmcblk0p1          /boot   vfat    defaults        0       2
...
#/dev/#XFS_ROOT#       /         xfs       defaults               0      0
/dev/mmcblk0p3           swap      swap      defaults               0      0
...

ESC ZZ

Die Datei cmdline.txt muss noch wie folgt angepasst werden:

# vi /mnt/boot/cmdline.txt
smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 console=tty0 root=/dev/mmcblk0p2 rootfstype=ext3 rootwait

ESC ZZ

Nach sicherem Aushängen der SD-Karte sollte CRUX-ARM 2.8 bootfähig sein:

# cd
# umount /mnt/{b,r}oot
# eject /dev/sdX

Netzwerkkonfiguration

Die Netzwerkkonfiguration muss noch angepasst werden. Standardmäßig wird eine statische IP (192.168.1.100/24) vergeben, was wohl in einigen Fällen nicht passen dürfte – z.B., wenn man DHCP verwendet:

# vi /etc/rc.d/net
...
start)
        # loopback
        /sbin/ip addr add 127.0.0.1/8 dev lo broadcast + scope host
        /sbin/ip link set lo up
        # ethernet
        /sbin/ip link set eth0 up
        /sbin/dhcpcd eth0
        ;;
stop)
        /usr/bin/killall dhcpcd
        /sbin/ip route del default
        /sbin/ip link set eth0 down
        /sbin/ip link set lo down
        /sbin/ip addr del 127.0.0.1/8 dev lo
        ;;

ESC ZZ

Nach einem Neustart des Netzwerk-Dienstes sollte das Netzwerk funktionieren:

# /etc/rc.d/net restart
# ping google.de

Wenn nicht, einfach mal einen Blick auf die Fehlermeldung werfen.

Updates

Seit der Erstellung des CRUX-ARM 2.8 Raspberry Pi-Images wurden einige Updates veröffentlicht – diese kann (und sollte!) man installieren. Wichtig ist dabei, erstmal das richtige Datum/die richtige Uhrzeit zu setzen, da ansonsten die Übersetzung mit einem Fehler abbricht:

# date --set="3 Apr 2013 19:50:00"     # bitte ersetzen!
# ports -u
# echo "Updates: $(ports -d|tail -n+2|wc -l)"
# prt-get sysup
...

Hier unbedingt Zeit und/oder Zeit mitbringen. Der Raspberry Pi darf jetzt sämtliche verfügbare Aktualisierungen übersetzen – und das dauert (im Anbetracht der verbauten CPU) natürlich etwas..

Tools

Im Minimal-Image von CRUX-ARM 2.8 fehlen noch einige rudimentäre Tools, wie beispielsweise GNU screen, elinks und ntp:

# useradd ntp; groupadd ntp
# prt-get depinst screen ntp elinks python

Bitte auch hier etwas Geduld mitbringen – der Winzling ist natürlich nicht der schnellste und braucht für das Übersetzen der einzelnen Quellcodes ein wenig Zeit.

Tweaks

Wer möchte, kann den Raspberry Pi noch ein wenig “tunen” und ihn übertakten, Overscaling deaktivieren, etc.:

# vi /boot/config.txt
disable_overscan=1
arm_freq=950
gpu_mem=16
core_freq=250
sdram_freq=450

ESC ZZ

Diese Einstellungen entsprechen weitestgehend der Raspbian “High“-Einstellung und übertakten die CPU auf 950 Mhz, Core auf 250 Mhz und den RAM auf 450 Mhz. Overscan wird deaktiviert und für die GPU werden 16 MB Speicher reserviert – ideal, wenn man den Raspberry Pi als Server einsetzen möchte.

Aktuell brodelt wieder die Gerüchteküche – einigen verlässlichen Quellen zufolge sollen der Distribution zukünftig einige große Strategieänderungen – auf die ich in diesem Artikel eingehen möchte – widerfahren.

Neuer Unterbau: Fokus auf ARM – erstmals kein GNU/Linux?

Insider-Informationen zufolge soll mittelfristig der Umzug auf eine neue Kernel-Plattform erfolgen. In der Vergangenheit hat sich die Pflege des Linux-Kernels als sehr zeitaufwändig und komplex erwiesen. Spezielle Ubuntu-Anpassungen müssen nachträglich angewandt werden und neue Geräte-Treiber sind oftmals unreif, was die Begeisterung beim Kunden mindert.

Laut internen Analysen sind diese Probleme vorwiegend auf das nicht mehr zeitgemäße monolithische Design des Linux-Kernels zurückzuführen. Um dieses Problem mittelfristig zu lösen, finden bereits erste Tests auf alternativen Kernel-Architekturen statt. Sehr angetan ist man offensichtlich von einem nicht näher benannten unixoiden Hybrid-Kernel, der auf dem Mach-Prinzip aufbaut und über einzelne monolithische Elemente verfügt.

Ein weiteres Ziel ist es, den Hardware-Support auf einige exklusive Hersteller zu beschränken – diese sollen dann aber zu 100% unterstützt werden. Als potentielle Vertragspartner werden drei Computer-Hersteller aus Round Rock, Raleigh und Cupertino vermutet. Der Endanwender müsste sich so keine Gedanken mehr über Treibersupport machen und könnte aus dem breiten Produktportfolio der drei Hersteller auswählen.

Die klassische 32bit-Architektur i686 ist zukünfig nicht mehr von Interesse und soll einschlägigen Andeutungen zufolge mit dem kommenden Release “13.10 Sloppy Seagul” eingestellt werden. Mittelfristig soll voraussichtlich auch die 64bit-Architektur x86_64 weichen – man möchte sich offensichtlich auf die Unterstützung von ARM-Geräten konzentrieren, da diese für den Consumer-Markt von größerem Interesse sind. Repräsentativen Studien und Marktanalysen zufolge sollen 2014 die Verkaufszahlen von Tablets und Smartphones viermal so hoch wie die konventioneller Personal Computer sein. Auf diesen Trend möchte man sich offensichtlich vorbereiten und alle technischen Strukturierungsmaßnahmen einleiten.

Die Ausrichtung auf den Consumer-Markt hat auch Auswirkungen auf die Pflege des Ubuntu Servers – er soll ab 2014 lediglich für ARM-basierte Server angeboten werden. Die Unterstützung für die i686- und x86_64-Architekturen wird vermutlich zeitgleich mit der Unterstützung der Desktop-Releases eingestellt.

Neue Release-Zyklen und Update-Mechanismen

Der übliche 6 monatige Release-Zyklus mit zusätzlichen 1,5 bis 2 Jahren Update-Pflege soll einem neuen als “Short Term Support (STS)” bezeichneten System weichen. Zukünftige Releases werden bis zu 6 Monate lang mit Sicherheitsupdates versorgt.

Primärziel dieser Umstrukturierung ist es, immer die neueste Software anbieten zu können. Durch die Einsparung von Arbeitszeit für erweiterten Hardware-Support (siehe oben) steht mehr Man-Power zur Verfügung, um neueste Software unter verschiedenen Aspekten zu testen und (falls notwendig) zu patchen.

Updates und zusätzliche Anwendungen sollen zukünftig nicht mehr über apt oder aptitude bezogen werden können, hier soll ein Subskiptionsprinzip, welches sich bei zahlreichen Enterprise Linux-Distributionen etabliert hat, zum Tragen kommen. Diese Subskriptionen sollen über einen eigenen Multimedia-Store, der auch Filme und Bücher anbietet, erworben werden können. Zusätzliche Anwendungen werden als separate käufliche “Apps” angeboten.

Software-Vereinheitlichung

Neben der Kernel-Wartung hat sich ein weiteres Ziel herauskristallisiert: die Standardisierung des umfangreichen Software-Portfolios von Ubuntu.

Aktuell gibt es für Ubuntu zahlreiche Desktop-Umgebungen, unter anderem GNOME, KDE und LXDE. Diese Programm-Vielfalt entspricht nicht mehr der ursprünglichen Ubuntu-Faustregel, für jede Aufgabe eine Anwendung zur Verfügung zu stellen.

Die oben erwähnten Desktop-Umgebungen verfolgen jeweils eigene Ziele und haben allesamt Vor- und Nachteile, die es zu vereinen gilt.

Nachdem im März 2013 die Arbeit an Mir, einem eigenen Display-Server, bekannt gegeben wurde, will man zukünftig noch einen Schritt weiter gehen – die Entwicklung einer eigenen Desktop-Umgebung. Sie soll den Namen Ubuntu Desktop Environment (UDE) tragen und mit einem aufgeräumten Erscheinungsbild überzeugen. Eine Steuerung mit Maus und externer Tastatur ist nicht vorgesehen – stattdessen soll eine sehr ausgereifte Spracherkennung, die in Zusammenarbeit mit hessischen und schwäbischen Universitäten entstand, zum Einsatz kommen. Zahlreiche interne Tests verliefen sehr zufriedenstellend und versprechen eine globale Anwender-Begeisterung.

Anwendungen sollen zukünftig ausschließlich im Vollbild-Modus ausgeführt werden – ein Prinzip, das man schon heute von Smartphones und Tablets kennt. Wegfallen soll der Support von Multitasking, da Benutzer – laut eigenen Analysen – in der Regel ohnehin nie mehr als eine Anwendung gleichzeitig bedienen.

Ab in die Cloud: komplette Ubuntu One-Anbindung

Nachdem 2009 mit Ubuntu One erstmals Cloudspeicher zur Verfügung gestellt wurde, möchte man zukünftig offensichtlich das Ganze toppen und lokale Benutzerkonten aus dem Funktionsumfang des freien Betriebssystems entfernen.

Benutzerkonten sollen zukünftig über das populäre soziale Netzwerk Facebook implementiert werden. Da persönliche Daten zukünftig nicht mehr auf einer dedizierten /home-Partition sondern ausschließlich auf Ubuntu One gesichert werden sollen, ergibt sich für den Benutzer der Vorteil der wegfallenden (aufwändigen) Datensynchronisation. Anwender können sich auf jedem Ubuntu-Endgerät mit Gesichtserkennung oder einem dreistelligen Sicherheitscode einloggen und auf ihre sensiblen Daten zugreifen.

Angeschlossene USB-Datenspeicher sollen automatisch in die Cloud aufgenommen werden. Vorhandenes Musik- oder Filmmaterial soll automatisiert mit eingeschlägigen Internet-Portalen synchronisiert werden.

Ausblick: erste Screenshots und neue Release-Namen

Nachdem man früher die Namen zukünftiger Releases eher kurzfristig entschied und bekanntgab, wurden nun erstmal im Voraus zahlreiche Namen festgelegt. Hier bleibt man beim altbewährten System und verwendet weiterhin Tiernamen in Kombination mit Adjektiven als Codenamen:

Erste geheime Screenshots der zukünftigen Benutzeroberfläche “Ubuntu Desktop Environment (UDE)” haben bereits den Weg ins weltweite Netz gefunden – sie sind hier zu finden: [klick mich!]

Ein Video von UDE in Aktion gibt es hier: [klick mich!]