Seite wählen

NETWAYS Blog

Cyanogenmod – die bessere Alternative zur Originalfirmware

Vorweg: Es ist nichts Neues, dass es Cyanogenmod gibt und die Popularität dieser Android-Distribution ist wohl größer denn je. Aber da ich a) nun selbst vom Apfel-Telefon zum Androiden konvertiert bin und da b) der neue Cyanogenmod-Installier vor kurzem erschienen ist, wird es Zeit für einen Blogpost. Vielleicht kann ich damit auch einige Zweifler davon überzeugen auf Ihre Gerätegarantie keine Rücksicht zu nehmen und sich das (IMHO) bessere Androidpaket auf dem Telefon zu installieren.
Cyanogenmod ist eine auf dem dem Stock-Android beruhende Android-Distribution, die einige Erweiterungen/Verbesserungen aufweisen kann und ohne unnötigen Ballast, wie diverse vorinstallierte Apps, daher kommt. Wer in den Downloadbereich des Projektes einen kurzen Blick wirft, wird mit Sicherheit eine Version von Cyanogen für sein eigenes Telefon oder Tablet finden können. Die Geräteliste ist für ein freies Projekt wirklich riesig und wird wohl durch die Gründung der Cyanogen Inc. deutlich steigen. Bereits wenige Wochen nach Gründung der Firma konnten die Entwickler einen deutlichen Anstieg der Entwicklungsgeschwindigkeit verzeichnen.
Jetzt aber zu den Vorteilen. Mit Sicherheit werden viele die tollen Oberflächen von Samsung, HTC und Co. kennen und entweder lieben oder verfluchen. Dieser Post zielt natürlich auf Menschen ab, bei denen zweiteres zutrifft (Da zähle ich mich mit dazu 😉 ). Cyanogenmod macht insgesamt einen deutlich schnelleren Eindruck, zumindest was die GUI betrifft. Zu meinem Erstaunen gab es immer wieder Ruckler bei einem neuen Samsung S4 Mini (jaja, Motzen auf hohem Niveau), was bei dem Alternativprodukt nicht der Fall ist. Ebenso ist Cyanogen für Bleeding Edge Menschen die bessere Wahl, da die Hersteller sich ja bekannter Weise immer sehr viel Zeit mit Updates lassen, wodurch so manch praktisches Feature erst gefühlte Jahre später auf dem Endgerät verfügbar ist… wenn überhaupt etwas erscheint.
Auch geht Cyanogenmod mit den zur Verfügung gestellten Ressourcen sparsamer um. Die Anwendungsverwaltung hat einen „KillAll“ Button (Killerfeature, wortwörtlich!!), der ein Segen ist und immer für genügend freien RAM sorgt. Diverse Wischgesten wurden mit eingebaut, die für eine deutlich angenehmere Bedienung sorgen. Umfassend sind es viele Kleinigkeiten, die Mensch jedoch nicht mehr missen will, wenn er sie bereits hat.
Einzige Hürde ist jedoch, dass das Geräte gerootet werden muss und somit die Gerätegarantie entfällt. Das ist natürlich ein hoher Preis, den man bezahlen muss, lohnt sich aber. Zum Glück kann bei einigen Geräten sogar der Eingriff wieder komplett rückgängig gemacht werden, sodass die Garantie auch kein Problem darstellen sollte.

Wenn der Apfel mal wieder madig ist…

Auch wenn Apple die wohl schönsten Computer baut, so kommt es vor, dass doch ab und an mal ein Zahnrad klemmt.
Da sich NETWAYS mit mir einen ehemaligen Apple-Supportler ins Boot geholt hat (sollte in jeder Firma vertreten sein, wo mehrere Macs am Start sind 😉 ), kennt man bereits die ein oder andere Macke der Geräte und deren schnelle Problemlösung.
Oftmals sind es die komischten Sachen, die in solchen Situationen der Fehlfunktion doch helfen können. Das sind zum einen der PRAM-Reset und der SMC-Reset. Beide Resets ähneln von den Tastenkombinationen eher einer Fingerdehnübung und derer Durchführung und Erfolg scheint auch mehr dubios. Manchmal hilft’s dann aber doch 😉
Nach erfolgreich vollzogenem Beschwörungstanz sollten die Räucherstäbchen nun auch bis zur Hälfte hinuntergebrannt sein, nun kann das Tastendrücken los gehen!
PRAM-Reset:
Hierbei wird der Mac komplett heruntergefahren und anschließend wieder angeschaltet. Dabei sollte er immer am Netzteil sein und das Netzteil in der Steckdose stecken 😉 Anschließend werden die Tasten P, R, ALT und CMD gedrückt (und sie bleiben weiterhin gedrückt) bevor der allseits bekannte Startton erklingt. Man verharrt nun in dieser Position so lange, bis der Ton das dritte mal aus den Lautsprechern schallt. Danach können die Tasten gelöst werden und der Mac fährt nun wie gewohnt hoch.
SMC-Reset:
Hierbei wird ebenfalls der Mac heruntergefahren und an seiner Stromversorgung angeschlossen. Bei diesem Ritus müssen die Tasten CTRL, ALT und Shift gedrückt werden und dann wird der PowerButton gedrückt und es muss wieder in dieser Position mindestens 20 Sekunden gewartet werden. Danach alle Tasten lösen und den Rechner wie gewohnt anschalten.
Safe-Boot:
Das kennt man. Wohl noch von Windows 95 und seinen abgesicherten Modus. Beim Mac verhält sich das ähnlich.
Zunächst sollte der Stand der Räucherstäbchen kontrolliert werden. Sind sie heruntergebrannt? Nun heißt es schnell sein, Nachschub einlegen!
Glüht das Stäbchen, so kann mit dem Prozedere fortgefahren werden. Hierbei wird wieder der Mac komplett herunter gefahren und im Anschluss mit gedrückter Shift Taste hochgefahren. Das veranlasst den Mac sich auf sein elementares zu besinnen und fährt in den Safe-Mode hoch. Ein kleiner Balken sollte erscheinen (Sollte etwas außerhalb vom Monitor erscheinen, empfehle ich von den Räucherstäbchen in Zukunft Abstand zu nehmen). Dabei werden beim Start diverse Checkroutinen durchgeführt. Ist der Mac nun hochgefahren, fällt auf, dass der grafische Firlefanz nicht mehr so schick aussieht wie zuvor. Das liegt daran, dass nur die wichtigsten Dienste und Treiber geladen wurden. Grafikbeschleunigung zählt leider nicht dazu 🙁
Der Safe-Mode ist ganz nützlich, wenn das System unter normalen Umständen nicht mehr richtig funktioniert, oder man gar selbst einen Treiber eingespielt hat, der das OS zum Abstürtzen zwingt (ich denke da mal an die guten USB->RS232 Adapter – meinen Mac zwang der Treiber schonmal in die Knie).
Ich hoffe ich konnte euch ein paar wertvolle Tips mit auf den Weg geben, die euch bei der weiteren Reise durchs Leben mit eurem Mac helfen können.
Und zur Vervollständigung auch nich die Links zu den KB-Artikeln bei Apple, die das Verfahren etwas sachlicher darlegen:
PRAM-Reset
SMC-Reset
Safeboot

Load Balancing mit dem Raspberry Pi – ein kleines Praxisbeispiel mit ldirectord

Was im großen geht, das geht natürlich auch im Kleinen.
Da sich meine Bastelaktivitäten mit dem Raspberry Pi mit der Zeit immer mehr eingestellt haben, da einige Projekte umgesetzt und andere wiederum im Sande verlaufen sind, stellte sich die Frage, was man denn nun mit den kleinen Rechenzwergen anfangen könnte. Zum brach rumliegen sind sie ja definitiv zu schade 😉
Da ich es immer schon ein wenig n3rd1g fand ein Webprojekt direkt von daheim zu hosten und das ganze möglichst ausfallsicher zu gestalten, entschied ich mich dazu einen kleinen Blog auf meinen RPi’s zu betreiben.
Damit alle meine Pi’s eine sinnvolle Tätigkeit bekommen, entschied ich mich einen Loadbalancer auf dem einen zu installieren und die restlichen zwei als „App-Server“ laufen zu lassen.
Hierbei ist die Software IPVS in Verbindung mit dem Ldirectord auf jeden Fall eine gute Wahl. Ldirectord ist ein Daemon, welcher mit IPVS spricht und noch viele Funktionen mitbringt, die IPVS von Hause aus nicht abdecken kann, wie zum Beispiel das automatische Herausnehmen eines Servers aus einem Load Balancing Pool, wenn dieser nicht den gewünschten Content ausliefert.
Es stehen mehrere Möglichkeiten zur Auswahl, wie der Load Balancer mit den Real-Servern (also unsere App-Server) die Daten austauschen kann. Die wichtigsten stellen wohl das Direct-Routing und das Masquerading dar.
In diesem Beispiel habe ich mich für Direct-Routing entschieden, da Masquerading doch zu einem Teil auf die Rechenleistung des Raspberry’s niederschlägt.
Auf dem Loadbalancer reicht es aus, wenn das Paket ldirectord installiert wird. Alle benötigten Abhängigkeiten wie IPVS werden automatisch mit installiert.

Konfiguration ldirectord

Nach abgeschlossener Installation muss zunächst die Datei /etc/default/ldirectord angepasst werden. Hier wird über die Variable „CONFIG_FILE“ der Ort der Config definiert:

# Set the following variable to define a default configuration
# file for ldirectord.
CONFIG_FILE=/etc/ldirectord.cf

Im Anschluss muss jene Datei natürlich noch angelegt und mit dem richtigen Inhalt befüllt werden, wie in folgendem Beispiel:

# Global Directives
checktimeout=10
checkinterval=10
fallback=127.0.0.1:80
autoreload=yes
logfile="/var/log/ldirectord.log"
quiescent=no
#callback="/usr/local/bin/sync_ldirectord"
# Virtual Server for HTTP
virtual=192.168.0.40:80
real=192.168.0.41:80 gate
real=192.168.0.42:80 gate
service=http
request="alive.html"
receive="foobar3000"
scheduler=rr
# persistent=600
protocol=tcp
checktype=negotiate

Die Config ist an und für sich recht einfach zu verstehen. Ein paar Einträge möchte ich jedoch erklären:
callback: Hier kann ein Script angegeben werden, welches nach einem Autoreload ausgeführt wird. Üblicherweise sollte hier eine Synchronisation zu einem zweiten Load Balancer statt finden.
virtual: Die IP samt Port für den Service, der balanced werden soll. Diese IP ist von außen direkt ansprechbar (einfach gesagt: Die IP kommt in den A-Record 😉 ) und muss auf dem Load Balancer als zusätzliche IP konfiguriert werden. Dahinter stehen die Realserver, auf die Anfragen verteilt werden.
checktype: Art der Überprüfung, ob ein Realserver ordnungsgemäß funktioniert. Bei einem Webdienst ist negotiate anzuraten, da hierbei ein Ergebnis (receive) angegeben werden kann, welches bei der Anforderung (request) zurückgegeben werden muss.
scheduler: Die Art, wie verteilt wird. Hier wird nur die Abkürzung eingetragen. Welche Arten es gibt, kann in der Man-Page von ipvsadm nachgelesen werden (Schalter -s, –scheduler)
fallback: Der Name ist selbsterklärend 😉 Sollten Alle Realserver aus dem Pool rausspringen, so wird ein Fallback Server (in unserem Beispiel localhost) eingesetzt. Hier kann beispielsweise eine Wartungsseite ausgeliefert werden.
Nachdem nun auch die Service-IP auf dem Load Balancer-Pi eingerichtet wurde (ifconfig eth0:1 192.168.0.40/32 – in unserem Beispiel), kann der Ldirectord gestartet werden. Im definierten Logfile werden wir jedoch feststellen, dass der Ldirector seine Realserver noch nicht erreichen kann und somit auf den Fallback Server geschaltet hat.

Konfiguration App-Server

Unsere Realserver können leider nicht ohne Weiteres die Anfragen, die vom Load Balancer kommen verarbeiten. Immerhin wird ja die Anfrage direkt an die IP 192.168.0.40 gestellt, welche ja auf den Systemen nicht bekannt ist. Damit das funktioniert, muss die Service-IP auf den Real-Servern noch als Loopbackdevice gebunden werden, damit sich der Realserver auch angesprochen fühlt. Jedoch Vorsicht: Nicht einfach so die Service IP als Loopback einbinden! Das würde dazu führen, dass der Realserver ARP-Anfragen mit seiner MAC-Adresse beantwortet, was wir ja nicht wollen. Das könnte den gesamten Dienst still legen. Hier muss im Vorfeld noch folgendes in die /etc/sysctl.conf eingetragen und mit sysctl -p übernommen werden, was das Verhalten unterbindet:

net.ipv4.conf.all.arp_ignore = 0
net.ipv4.conf.default.arp_ignore = 0
net.ipv4.conf.eth0.arp_ignore = 1
net.ipv4.conf.lo.arp_ignore = 0
net.ipv4.conf.all.arp_announce = 0
net.ipv4.conf.default.arp_announce = 0
net.ipv4.conf.eth0.arp_announce = 2
net.ipv4.conf.lo.arp_announce = 0

Nun kann das Loopbackdevice hochgefahren werden:

root@rpi1:~# ifconfig lo:1 192.168.0.40/32

Sobald nun der Realserver die Datei „alive.html“ mit dem Inhalt „foobar3000“ ausliefern kann, wird er auch im Load Balancer als aktiv markiert und die Anfragen werden entsprechend weitergeleitet. Das der Webdienst richtig dafür eingerichtet wurde, setze ich an der Stelle einfach mal voraus 😉
Das Schöne am Ldirectord ist, dass er sich nicht nur auf Webdienste beschränkt. Es kann jeder TCP/UDP Dienst über den Load Balancer verteilt werden. Durch die optional einstellbare Persistenz kann auch sichergestellt werden, dass eine Verbindung immer wieder bei dem gleichen Realserver ankommen wird (für den konfigurierten Zeitraum).

Paketierung mit Ruby Gem FPM

Als Sysadmin kennt man das Problem: Man hat Software XYZ gepatcht oder möchte eigene Files über ein Paket bereitstellen und sucht dafür natürlich den schnellsten und einfachsten Weg. Für solche Angelegenheiten hat sich bereits das Urgestein „checkinstall“ bewährt. Heut möchte ich eine Alternative dazu vorstellen.
Das Ruby Gem „FPM“ bietet eine einfache Möglichkeit diverse Pakete aus diversen Quellen zu erstellen. So kann z.B. ein Verzeichnis angegeben werden, welches dann den Inhalt eines Paketes darstellt.

# fpm -s dir -t deb -a all -n mein-paket -v 1.0 /opt/mein-paket

FPM bietet eine Vielzahl an zusätzlichen Parametern, mit denen man beispielsweise den Paketmaintainer, die Version und Revision des Paketes, Post- und Pre-Skripte definieren kann. Hier lohnt sich ein genauer Blick in das Wiki des Projektes.

Fertig.

Nicht mit den Nerven, sondern mit meiner Ausbldung zum Fachinformatiker für Systemintegration. Diese konnte ich letzte Woche Mittwoch nämlich erfolgreich beenden und bin somit nun offziell ein Fachinformatiker für Systemintegration. Juhu!
Die letzte Hürde bestand aus der Präsentation meines Projektes „Aufbau einer Cloud mittels OpenNebula“ und einem anschließenden Fachgespräch.
Die besagte Cloud habe ich aus drei Servern aufgebaut, welche nun als Testcloud für uns dient, damit wir Updates von OpenNebula vorher ausgiebig testen und anschließend auf unsere Produktiv-Umgebung anwenden können.
Mit dem Wissen angereichert, welches mir meine Kollegen und Bildungseinrichtungen vermittelt haben, beschreite ich nun den Weg meiner beruflichen Laufbahn und beginne diese, wie sollte es auch anders sein, bei NETWAYS, wo ich nun als „Systems Engineer“ mit dabei bin.