Virtualisierung – Virtuelle Maschine oder Container?

Beim Planen und Nachdenken über die unsere zukünftige Schul-IT begegnete mir unweigerlich auch das Thema Virtualisierung. In den letzten Jahren ist dieses Thema teilweise sehr gehypt worden, wenn man z.B. nur an die Containerlösung Docker denkt. Insgesamt kann man wohl sagen, dass heute wesentlich mehr und häufiger virtualisiert wird, als das noch vor 5 Jahren der Fall war, wo man eher noch auf „bare-metal“ gesetzt hat.

In unserem konkreten Fall wollen wir auch virtualisieren, um die einzelnen Anwendungen auf dem Server besser zu isolieren und zu trennen. Im Opensource-Bereich gibt es einige Lösungen, wie man seine Anwendungen auf dem Server virtualisieren kann. Grundlegend unterscheidet man hier zwischen virtuellen Maschinen (der Hypervisor virtualisiert das ganze OS inkl. Kernel) und Containern (Container nutzen den Kernel des Hosts/Hypervisors). Jede Lösung hat seine Anwendungsszenarien, so kann man z.B. nie ein Windows in einem Container auf einem Linux-Host laufen lassen, da sie unterschiedliche Kernel verwenden. Allerdings kann man CentOS in einem Container auf Ubuntu starten (gleicher Kernel).

Ich habe mir in den letzten Monaten überblicksweise folgende Virtualisierungs-Lösungen angeschaut:

  • KVM (entwickelt von RedHat)
  • Virtualbox (hauptsächlich um auf dem Desktop verschiedenen Softwarelösungen auszuprobieren)
  • LXD (Canonical) → Container-VMs

Alternativen sind noch Xen oder VMWare, welche auch recht weit verbreitet sind, wobei bei VMWare nicht als Opensource-Lösung gilt und einiges an Lizenzkosten fällig wird.

Virtualbox

Virtualbox nutze ich gern auf meinem Rechner, um Software zu testen und auszuprobieren. Es ist recht einfach ein komplettes Netzwerk nachzubilden. So habe ich oft eine kleine Router-VM (vorzugsweise pfSense), welche ein weiteres (isoliertes) Netz bereitstellt. Dann habe ich meist ein oder zwei Server-VMs und noch ein paar Clients, um z.B. PXE-Boot und/oder andere Dienste zu nutzen. Das funktioniert recht gut, solange der Rechner mit genügend Cores und RAM ausgestattet ist (ist bei mir nur teilweise der Fall…)

KVM

KVM hat mir bisher am meisten zugesagt, wenn es um die Virtualisierung „richtiger“ VMs geht. Ich nutze hauptsächlich den virt-manager, um meine VMs zu verwalten, aber es gibt noch unzählige andere Frontends für KVM. Proxmox ist noch sehr bekannt oder virsh für die Konsole. KVM ist sicher nicht die einfachste VM-Lösung, aber dafür sehr flexibel einsetzbar. Snapshots der einzelnen VMs sind ohne Probleme mit dem virt-manager oder einem anderen Management-Werkzeug möglich.

LXD

LXD 2.0 ist erst vor kurzem Erschienen und wird in Ubuntu 16.04 am besten anwendbar sein. Es gibt derzeit eine Blogreihe von einem der Hauptentwickler, die ich jedem ans Herz lege, der sich damit auseinander setzen möchte. LXD finde ich äußerst spannend – aus verschiedenen Gründen:

  • Container VMs → man kann sehr einfach und schnell (!) ein Linux starten und seine Anwendung drin laufen lassen
  • durch den Einsatz von ZFS als Speicherbackend kann man super Snapshots im laufenden Betrieb usw. machen
  • man kann wesentlich mehr Container als echte VMs starten (bessere Ausnutzung des Servers)
  • Konfiguration und Bedienung von lxd finde ich sehr intuitiv
  • sehr geringer Overhead

Allerdings gibt es auch Sachen, die nicht oder nicht ohne weiteres möglich sind, da es halt Container und keine vollwertigen VMs sind. So kann man keine ISO „booten“ (es gibt aber für alle wichtigen OS Images). Ich wollte z.B. freeIPA / FOG in einem CentOS Container auf Ubuntu 16.04 testen und bin nicht ganz zum Ziel gekommen, da die Installation an manchen Stellen nicht sauber durchlief, da z.B. Ubuntu und CentOS verschiedene Technologien einsetzen (SELinux vs. Appamor). Das schaue ich mir aber noch mal genauer an. Insgesamt könnte ich mir LXD Container sehr gut für reine Webanwendungen vorstellen, sozusagen als Webserver-VMs. Das Anlegen, Starten, Backup und Restore sind einfach super easy mit LXD! Kann ich nur empfehlen sich das mal anzuschauen.

Derzeit tendiere ich zu KVM für vollwertige VMs für alle Infrastruktur-Dienste (AD, NFS, DHCP, DNS) und zu LXD für zusätzliche Webanwendungen, welche wir hier in der Schule zu einsetzen bzw. einsetzen werden. Dazu folgt noch ein extra Blogeintrag.

Ubuntu und Probleme mit ttf-mscorefont-installer

Vorgestern habe ich meinen Laptop mit Ubuntu 16.04 neu aufgesetzt und eines der Pakete, dich nach so einer Installation installiere, ist ubuntu-restricted-extras. Teil dieses Meta-Pakets ist der Installer für Microsoft-Schriftarten wie Arial, Time New Roman, Verdana usw. Leider schlug der Download der Schriftarten fehl (Hash Sum mismatch / Hash-Summe stimmt nicht überein) und somit auch die Installation.

Folgendes hat das Problem gelöst:

Schriftarten Meta-Paket installieren:

sudo apt-get install ttf-mscorefonts-installer

Schriftarten herunterladen und installieren:

TMP=$(mktemp -d)
cd "$TMP"
awk '/Url/ {system("wget "$2)}' /usr/share/package-data-downloads/ttf-mscorefonts-installer
sudo /usr/lib/msttcorefonts/update-ms-fonts "$TMP"/*

Benachrichtung über ausstehende Installation abschalten:

sudo touch /var/lib/update-notifier/package-data-downloads/ttf-mscorefonts-installer

Aufräumen :)

cd ..
rm -r "$TMP

Quelle: http://askubuntu.com/questions/543673/mscorefonts-problems

Von FxOS bis freeIPA

In den letzten Wochen und Monaten habe ich mich mit verschiedensten Themen beschäftigt. Heute möchte ich das einmal kurz zusammenfassen und davon berichten.

Firefox OS

Vor einer ganzen Weile hat Mozilla mehr oder weniger das aus von FxOS für Smartphones verkündet. Ich hatte es bis dato fast 2 Jahre ausschließlich auf verschiedenen Geräten genutzt (Keon, Flame und zuletzt auf einem Nexus 5). Die Idee hinter diesem Projekt hat mich schon immer sehr angesprochen, aber in der Umsetzung hat man dann doch gemerkt, dass man in vielen Bereichen sehr weit Android oder iOS hinterherhinkt. Man konnte es nicht wirklich miteinander vergleichen. Seit dem Aus von FxOS nutze ich jetzt Cyanogenmod auf meinem Nexus ohne den Google Apps. Die Bedingung ist super und mir gefällt es auch, wenn ich Android wesentlich weniger Vertrauen entgegenbringe als FxOS. Vielleicht wird Ubuntu Phone noch mal eine ernste Alternative…

freeIPA, FOG, LML, …

In der Schule, an der ich arbeite, sind wir gerade dabei die IT neu zu strukturieren und umzubauen. Bisher setzen wir v.a. Windowssoftware ein, aber dafür gibt es eigentlich keinen triftigen Grund 😉 Also haben ich mich mit vielen Themen rund um Netzwerke, Server, Switche, Benutzerverwaltung, Konfigurationsmanagement usw. auseinander gesetzt. Das war teilweise echt spannend und das ein oder andere Setup wurde auf meinem Rechner virtuell durchgespielt und getestet. Wenn man heutzutage als Schule eine gute Softwarelösung sucht, gibt es einige Projekte, die sich diesem speziellem Umfeld widmen.

Eine sehr interessante Lösung ist die Linuxmusterlösung. Sie versucht viele Probleme zu lösen, die man typischerweise in einer Schule antrifft. Auf dem letzten Linuxtag 2016 in Chemnitz gab es hierzu einen Vortrag. Insgesamt ein tolles Produkt, welches dazu noch eine sehr hilfsbereite und aktive Mailingliste hat. Wir werden uns diese Lösung auf jeden Fall noch weiter anschauen, denn sie bietet eigentlich fast alles, was man so als Schule braucht.

Eine weitere Alternative ist, dass man sich aus verschiedenen Komponenten selbst eine Struktur aufbaut. Wir benutzen z.B. Google Apps for Education an unserer Schule, sodass wir viele Features der LML gar nicht brauchen (Räume buchen, Dateien austeilen und einsammeln, …). FreeIPA ist eine Lösung zur Verwaltung von Benutzern und deren Rechten. Es ist ähnlich zu einem Active Directory von Microsoft, halt nur für die Linuxwelt. Es macht auf mich einen sehr guten Eindruck, wird dazu noch aktiv von bezahlten Entwicklern weiterentwickelt (Redhat) und hat einige sehr interessante Features. Die Einrichtung eines freeIPA-Servers und der Clients ist sehr einfach, ebenso die Verwaltung der Benutzer. Einmalpasswörter sowie Zwei-Faktor-Authentifizierung sind z.B. mit dabei. Um die Clients einfach zu verwalten wäre das FOG Projekt eine gute Lösung. Zur Zeit passiert da sehr viel in der Entwicklung (u.a. ein Linux- und MacOS-Client). FOG zusammen mit freeIPA könnten eine gute Basis für unsere Anforderungen bieten, auch wenn sie vielleicht etwas mehr Verständnis in der Einrichtung brauchen, dafür bieten sie auf der anderen Seite IMHO mehr Freiheiten.

Bis zum Sommer soll sich da entscheiden in welche Richtung wir weitergehen (es ist auch nicht ausgeschlossen, dass der Microsoft-Weg eingeschlagen wird…).

Hat jemand von euch mit den oben genannten Projekten schon Erfahrung sammeln können?

BibleZ nun auch für Android verfügbar

Seit Firefox Mobile 29 unterstützt Mozilla die Installation von gepackten privilegierten Apps. Das sind Apps, die bestimmte APIs nutzen, z.B. Zugriff auf Netzwerkverbindungen (um Cross-Origin-Request Probleme zu umgehen).

BibleZ ist nun ab heute auch im Firefox Marketplace für Android verfügbar. Wer es dazu auch noch am Rechner installieren möchte, findet die Desktop-Version hier.

Hinweis: BibleZ befindet sich weiterhin in einem Beta-Status. Viele wichtige Funktionen fehlen noch… Wer einen Bug findet, kann ihn gern hier eintragen.

[Update] BibleZ NG

Update: BibleZ ist nun für FirefoxOS im Marketplace verfügbar!

Vor einigen Monaten hatte ich bereits über mein Projekt berichtet, BibleZ HD (die webOS App) in eine „richtige“ webApp zu portieren. In den letzten Wochen hatte ich wieder etwas mehr Zeit zum programmieren und so wurden wesentliche Features hinzugefügt.

Ich habe die App für FirefoxOS und auch für Firefox (Desktop, Android) im Marketplace von Mozilla eingereicht. In den nächsten Tagen sollte die App dann veröffentlicht werden. Wer die App bereits jetzt schon testen möchte, kann dies gern tun: http://zefanjas.de/biblezng

Um die App auch als solche zu installieren, öffnet man am besten die Webconsole (STRG + SHIFT + K) und gibt folgendes ein:

navigator.mozApps.install("http://zefanja.github.io/biblez-ng/app/manifest.webapp");
BibleZ NG - Firefox, Ubuntu 12.04

BibleZ NG – Firefox, Ubuntu 12.04

Der Sourcecode befindet sich auf Github.

FirefoxOS 1.3

Noch ein kleines Wort zu FirefoxOS an sich. Mittlerweile gab es einige Neuerungen und Verbesserungen im Handling und der Bedienung. Es fühlt sich teilweise immer noch umständlich im Vergleich zu webOS an, aber nicht mehr so schlimm, wie das noch mit der Version 1.0 war. Ich bin gespannt auf die weitere Entwicklung und hoffe auf leistungsstärkere Smartphones und Tablets!

Losungen 2014

Das neue Jahr hat begonnen und somit gibt es auch ein Update für die Losungen App für webOS. Das Update ist seit ein paar Tagen eingereicht und wird hoffentlich bald als Update verfügbar sein. Wer nicht so lang warten möchte, kann sich die IPK hier herunterladen und mit Preware oder webOSQuickInstall direkt installieren.

Mittlerweile gibt es auch ein Web App für Losungen, welche man sich z.B. auf seinem Firefox OS Gerät oder direkt im Browser installieren kann.

Ich wünsche allen ein gesegnetes neues Jahr!

Build a Robot #2 – Fernsteuerung mit dem Smartphone

Heute soll es uns um die Steuerung des kleinen Roboters mit einem Smartphone/Tablet gehen. Dabei soll die Fernsteuerung möglichst plattform-unabhängig sein. Aus diesem Grund habe ich mich für eine einfache Website entschieden, welche die Daten des Gyroskop ausliest und entsprechende Befehle an den Roboter schickt.

Die Serverseite

Ich habe in den letzten Jahren viel mit Javascript programmiert und aus diesem Grund habe ich mich für eine nodejs basierte Lösung entschieden. Javascript ist für die Steuerung von GPIOs eigentlich nicht wirklich geeignet (single threading, Latenzen, …), aber für das An- und Ausschalten von Motoren passt es ganz gut.

Zuerst sollte man also nodejs auf dem Raspberry Pi installieren. Da die Version in den Repositories nicht gerade aktuell ist, kann man sich manuell ein compiliertes Paket direkt bei nodejs downloaden. Die Installation ist in diesem Artikel ganz gut beschrieben.

Bei Github findet man verschiedene Pakete für die Ansteuerung der GPIOs. Ich habe mich für node-rpio entschieden, da die API der Python-API entspricht, die wir im letzten Beitrag verwendet haben. Weiterhin ist die API synchron, was in unserem Fall sinnvoll ist, da wir sonst mit vielen vielen Callbacks zu tun hätten 😉 Um node-rpio zu nutzen, muss es noch compiliert werden. Dazu gibt man einfach den Befehle

npm install -g node-gyp
node-gyp rebuild

ein, nachdem man das Github-Repo geklont hat. Nun ist alles fertig, um die Motoren über nodejs zu steuern. Da die API gleich ist, können wir im Prinzip den Quelltext aus dem letzten Beitrag nehmen und nur ein klein wenig anpassen:

var gpio = require("./node-rpio/lib/rpio");

//Setup GPIO Pins
gpio.setmode(gpio.BOARD);
gpio.setup(13, gpio.OUT);
gpio.setup(15, gpio.OUT);
gpio.setup(16, gpio.OUT);
gpio.setup(18, gpio.OUT);

gpio.output(13, 1);
gpio.output(15, 0);
gpio.output(16, 1);
gpio.output(18, 0);

process.on('SIGINT', function() {
    console.log("\nGracefully shutting down from SIGINT (Ctrl+C)");
    //Cleanup
    gpio.cleanup();
    process.exit();
});

Der letzte Teil dient dazu, dass man mit Ctrl+C das Skript abbrechen kann, denn sonst würden die Motoren ständig weiterdrehen.

Ok, jetzt können wir zwar die Motoren ansteuern, aber nur direkt am Raspberry Pi. Die Verbindung zum Smartphone fehlt noch. Socket.io ist ein großartiges Projekt, welches eine direkte Verbindung über webSockets zwischen Server und Client ermöglicht. Man kann Daten sehr einfach hin- und herschicken und eigene Ereignisse definieren, auf die dann der Server bzw. Client reagieren kann. Was wir brauchen ist nun eine HTML-Datei, welche den Gyroskop ausliest und die entsprechenden Befehle an den nodejs Server sendet, welche dieser dann verarbeitet:

Als nächstes wird der nodejs Server mit

sudo node robot.js

gestartet. Nun muss man nur noch die Adresse: http://IP-des-Raspberry-Pi aufrufen und schon kann man den Roboter mit einem Smartphone oder Tablet steuern.

Stromversorgung und Wlan

Es gibt nur noch ein Problem. Der Rapsberry Pi hängt bisher noch an zwei Kabeln: dem Netzwerkkabel und dem USB-Kabel für die Stromversorgung. Für beiden gibt es Lösungen. Das Netzwerkkabel habe ich durch einen Wlan-USB Dongle ersetzt. Wie man diesen einrichtet und welchen man kaufen sollte, findet man in diesem Artikel.

Das verbleibende USB-Kabel habe ich einfach durch ein mobiles USB-Ladegerät ersetzt, welches man für wenig Geld zu kaufen bekommt. Diese liefern die benötigen 5V. Man sollte darauf achten, dass sie neben den 5V auch mindestens 1A liefern, ansonsten wird der Raspberry Pi nicht starten.

Und so sieht das ganze jetzt aus 😉

mobile Stromversorgung und WLAN-Dongle mobile Stromversorgung und WLAN-DongleIch werde in den nächsten Tagen noch ein ein Video machen…

Wie geht es jetzt weiter? Die Steuerung muss noch verbessert werden. Gerade das Lenken ist noch ungenau und das Fahren somit etwas schwierig. Ein weiteres Ziel ist, mit Hilfe eines Ultraschall-Sensors dem Roboter das autonome Fahren beizubringen.

Bisherige Artikel

 

Build a Robot #1 – Motoren ansteuern

Wie ich in meinem letzten Beitrag erwähnte, möchte ich gern den Roboter mit dem Raspberry Pi steuern. Da man mit einem Pi Motoren nicht direkt ansteuern kann, benutze ich das L298N Chip als Motor Driver.  Nach folgendem Video habe ich alles zusammengesteckt bzw. alle fehlenden Kabel noch angelötet. Im Video wird nur ein Motor angeschlossen, aber die restlichen 4 GPIO Pins habe ich genutzt, um den zweiten Motor zu steuern.

Ich habe das im Video verwendet Testskript für den zweiten Motor erweitert, um die Motoren zu testen.

import RPi.GPIO as gpio
import time

gpio.setmode(gpio.BOARD)
gpio.setup(7, gpio.OUT) 
gpio.setup(11, gpio.OUT) 
gpio.setup(13, gpio.OUT) 
gpio.setup(15, gpio.OUT) 
gpio.setup(12, gpio.OUT) 
gpio.setup(16, gpio.OUT) 
gpio.setup(18, gpio.OUT) 
gpio.setup(22, gpio.OUT)

gpio.output(7, True) 
gpio.output(11, True) 
#Enable B für den 2. Motor 
gpio.output(12, True) 
gpio.output(22, True) 

#Motor 1 
gpio.output(13, True) 
gpio.output(15, False) 
#Motor 2 
gpio.output(16, True) 
gpio.output(18, False) 
time.sleep(2) 

gpio.output(13, False) 
gpio.output(15, True) 
gpio.output(16, False) 
gpio.output(18, True) 
time.sleep(2) 

gpio.output(13, False) 
gpio.output(15, False) 
gpio.output(16, False) 
gpio.output(18, False)   

gpio.cleanup()

Mit diesem kleinen Testskript kann man den Roboter vor und zurück fahren lassen. Das mitgelieferte Batteriefach hat Platz für 3 AA Batterien. Diese liefern insgesamt zu wenig Spannung für die Motoren, sodass das Fahrzeug zwar fährt, aber nicht genügend Drehmoment („Kraft“) hat. Ich werde ein neues besorgen, welches Platz für vier oder mehr AA Batterien hat.

Und hier noch ein Bild:

Der aktuelle Stand - Raspberry Pi mit L298N

Der aktuelle Stand – Raspberry Pi mit L298N