Audex - KDE CD Ripper
Ein wirklich gutes Programm zum CD rippen unter KDE ist Audex. Alles Mögliche lässt sich einfach und praktisch über die GUI einstellen inkl. der Dateinamen usw. Ziemlich durchdacht.
Posted at 01:32nachm. Aug. 31, 2015 by cetixx in Links | Kommentare [0]
Wo ist mein Speicherplatz hin?
cd /in/ein/verzeichnis
du -h . | grep -P '^[0-9\.]+G
Alternativ das Tool ncdu installieren...
Posted at 12:55vorm. Aug. 08, 2015 by cetixx in Tipps | Kommentare [0]
Gentoo - Alle installierten Pakete auflisten
equery list "*"
Posted at 12:55vorm. Aug. 08, 2015 by cetixx in Tipps | Kommentare [0]
Muguet - DNS Server & Reverse Proxy für Docker
Muguet ist ein DNS Server & Reverse Proxy für Docker, der automatisch generierte Hostnamen zu Conainter IPs auflöst. Außerdem enthält Muguet einen Reverse Proxy, der den Zugriff auf Web-Apps in den Container auf Port 80 ermöglicht.
Posted at 12:54vorm. Aug. 08, 2015 by cetixx in Links | Kommentare [0]
TauCharts
Wem andere JS-Chart-Libs zu kompliziert sind, hat mit TauCharts vielleicht mehr Glück. Hier geht es weniger um noch mehr "fancy" Effekte, sondern mehr um die Daten und wie man sie möglichst schnell und unkompliziert darstellen kann.
Posted at 12:54vorm. Aug. 08, 2015 by cetixx in Links | Kommentare [0]
QuantumUI
QuantumUI sind UI Komponenten, die nativ auf AngularJS und Bootstrap CSS basieren.
Posted at 04:35nachm. Aug. 07, 2015 by cetixx in Links | Kommentare [0]
Apache Mesos Testcluster für daheim
Was ist Mesos und Voraussetzungen
Ganz grob und einfach gesagt ist Apache Mesos ein "verteiltes Betriebssystem für Datenzentren", wenn man so will. Dabei spielt es keine Rolle, ob man Rechner, VMs oder beides hat und wo diese Rechner/VMs stehen. Man hat eine einheitliche Sicht auf alle Resourcen, auf welche man dann von Frameworks Tasks verteilt werden (u.a. auch Docker Container). Marathon und Chronos sind z.B. solche Frameworks und es gibt noch eine Reihe anderer und man kann selbst welche bauen. Alle Rechner, die in diesem Cluster-Verbund sind, stellen sich nach Außen als ein einzelner Pool an Resourcen dar. Das Ganze skaliert über einige zehntausend Nodes (soweit man sie denn hat ;-) ), ist ausfallsicher mit Hilfe von ZooKeeper, unterstützt Docker seit einiger Zeit, isoliert Tasks mit Hilfe von Linux Containern und bietet Java, Python, C++ und Go APIs, um direkt neue parallele Applikationen mit Mesos zu entwickeln.
Um Mesos einigermaßen realistisch zu testen (realistisch in dem Sinne, das man eine gewisse Anzahl von VMs hat und auch das HA-Setup mal testen kann), macht es Sinn, sich wie für den produktiven Betrieb auch, mindestens 3 Master-VMs (oder wer Rechner hat, dann 3 Rechner) und 2-3 Slaves (die dann die Tasks ausführen) zu installieren. Die Master-VMs benötigt man für ZooKeeper, der dafür sorgt, das immer ein Mesos-Service der sog. Master ist (die anderen sind soz. im Standby-Modus) und bei Ausfall des Masters, ein neuer Master bestimmt wird. Da der Master seine Aufgaben alle an die Slaves delegiert, hält sich die Belastung was CPU & Co. anbelangt bei ihm in Grenzen. Damit man ein Quorum hat, machen immer eine ungerade Anzahl von ZooKeeper-Instanzen Sinn (normalerweise 3 oder 5).
Für eine Testinstallation bietet es sich an, einige VMs zu installieren. Um VMs aufzusetzen, kann man z.B. Vagrant mit Virtualbox verwenden. Da ich libvirt drauf hab und in Vagrant nicht so tief drin bin, habe ich die 6 Ubuntu 14.04 LTS VMs mit virsh-install installiert. Wie das geht, habe ich prinzipiell hier beschrieben. Wenn man dann eine Ubuntu-VM installiert hat, kann man das fertige qcow2-File einfach kopieren (solange die VM nicht gestartet ist) und entsprechend dann in libvirt konfigurieren. Ich gehe darauf jetzt aber nicht weiter ein. Noch einfacher geht die Sache allerdings mit virt-builder (Teil des libguestfs Pakets ab Version 1.26, wenn ich mich nicht irre).
Wenn man dann die 6 VMs hat, kann man sich in der /etc/hosts noch Einträge machen, damit man die VMs per Namen und nicht per IP ansprechen kann. In meinem Fall:
192.168.122.252 me-master01
192.168.122.251 me-master02
192.168.122.250 me-master03
192.168.122.249 me-slave01
192.168.122.248 me-slave02
192.168.122.247 me-slave03
Der Netzbereich 192.168.122.0/24 ist bei mir die Default-Range, die bei libvirt vorgegeben war. Hab ich einfach übernommen. Ebenso die von libvirt erzeugte Bridge virbr0. Nicht schaden kann auch die Installation des ntp Pakets auf allen VMs, damit die Zeiten überall gleich sind.
Allgemein
Nachdem die VMs einsatzbereit sind, machen wir Ubuntu das Mesosphere Repository bekannt auf ALLEN VMs und updaten den Repo-Index:
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv E56151BF
DISTRO=$(lsb_release -is | tr '[:upper:]' '[:lower:]')
CODENAME=$(lsb_release -cs)
echo "deb http://repos.mesosphere.io/${DISTRO} ${CODENAME} main" | sudo tee /etc/apt/sources.list.d/mesosphere.list
sudo apt-get -y update
Auf den Master-Hosts (und nur da) installieren wir das mesosphere-Metapaket das u.a. ZooKeeper, Mesos, Marathon (für langlaufende Tasks) und Chronos (für verteilte Cronjobs) enthält (das Metapaket hat aktuell ca. 330 MB):
sudo apt-get install mesosphere
Auf den Slave-Hosts installieren wir das mesos-Paket, das ist gut 100 MB kleiner und enthält u.a. ZooKeeper:
sudo apt-get install mesos
Als Nächstes konfigurieren wir ALLE VMs so, das sie alle die gleiche ZooKeeper Verbindungsinformation haben zu unseren ZooKeeper-Masterservern. Dazu editieren wir die Datei /etc/mesos/zk. Normalerweise finden wir dort den Eintrag zk://localhost:2181/mesos (der ist dafür gedacht, wenn man nur einen ZooKeeper hat), welchen wir ersetzen wollen. Statt localhost:2181 (2181 ist der ZooKeeoper Port) geben wir kommasepariert die IP's und Port unserer Master-ZooKeeper Server an. In meinem Fall sieht der Eintrag dann also so aus:
zk://192.168.122.252:2181,192.168.122.251:2181,192.168.122.250:2181/mesos
Master-Hosts/VMs (Mesos-Master)
Auf den Master-Hosts müssen wir nun jeder ZooKeeper-Instanz eine eindeutige ID verpassen. Dazu editieren wir /etc/zookeeper/conf/myid auf jedem Master. Die ID darf eine Zahl von 1-255 sein. In meinem Fall nehme ich das letzte Oktet von der IP der jeweiligen Master-VM also ID 252 für master01, 251 für master02 und 250 für master03.
Dann müssen wir der ID einen Host zuweisen. Dieses Mapping macht man in der Datei /etc/zookeeper/conf/zoo.cfg und sieht wie folgt aus:
server.252=192.168.122.252:2888:3888
server.251=192.168.122.251:2888:3888
server.250=192.168.122.250:2888:3888
Hinter server. steht also unsere ID, die wir oben vergeben haben und hinter dem "=" dann die IP des zugehörigen Hosts. Der erste Port 2888 wird verwendet, um mit dem Master zu kommunizieren. Der zweite Port 3888 wird verwendet, wenn ein neuer Master gewählt werden muss. Sollte man eine Firewall zwischen den Hosts haben, muss man die Ports natürlich freischalten! ZooKeeper ist damit soweit fertig.
Kümmern uns nun um die Mesos Master selber. Zuerst müssen wir das Quorum anpassen. Das Quorum legt fest, wie viele Nodes im Cluster noch funktionieren müssen, damit der Cluster noch als funktional eingestuft werden kann und Entscheidungen treffen kann. Über 50% des Clusters sollten noch funktionieren, damit Entscheidungen getroffen werden können. D.h. in unserem Fall von den drei Master-Hosts müssen mindestens zwei noch laufen. Wir setzen also auf ALLEN Master-VMs in /etc/mesos-master/quorum einen Wert von 2 (Default ist 1).
Dann schreiben wir auf ALLEN Master-VMs in /etc/mesos-master/ip die IP des jeweiligen Hosts, auf dem wir die Datei gerade editieren. Das Gleiche machen wir in/etc/mesos-master/hostname (alternativ kann man hier auch den Hostnamen rein schreiben, allerdings sollte man dann alle Hosts in der /etc/hosts stehen haben auf allen Mesos-Hosts/VMs, damit man nicht von einem DNS-Server abhängig ist - und falls der ausfällt, ist das eher ungünstig, zumindest wenn das Ganze produktiv wird ;-) ).
Master-Hosts/VMs (Marathon)
Als Nächstes ist dann die Marathon Konfiguration an der Reihe - die verteilte init System Implementierung, wenn man so will. Marathon startet u.a. lang laufende Prozesse. Marathon läuft auf allen Master-Hosts, aber nur der Leader kann Jobs ausführen. Die anderen Marathon Instanzen leiten die Requests transparent an den Leader weiter. Für jede Marathon Instanz müssen wir wie bei Mesos auch schon, wieder den Hostnamen festlegen. Hierzu können wir einfach /etc/mesos-master/hostname nach /etc/marathon/conf/hostname kopieren, müssen aber vorher noch das Verzeichnis auf jedem Master-Host anlegen (mkdir -p /etc/marathon/conf).
Dann müssen wir eine Liste von ZooKeeper Master für Marathon festlegen, die Marathon benötigt für den Informationsaustausch und Scheduling. Die Liste hat das gleiche Format wie wir es für Mesos in /etc/mesos/zk schon festgelegt haben. Auf ALLEN Master-Hosts kopieren wir also die Datei
sudo cp /etc/mesos/zk /etc/marathon/conf/master
Damit erlauben wir Marathon sich mit dem Mesos Cluster zu verbinden. Allerdings soll Marathon seine eigenen Informationen in ZooKeeper speichern können. Dafür nehmen wir wieder die gleiche Konfigurationsdatei und passen nur den Endpunkt (/marathon anstatt /mesos) an. Auf allen Master-Hosts kopieren wir
sudo cp /etc/marathon/conf/master /etc/marathon/conf/zk
Dann editieren wir /etc/marathon/conf/zk und tauschen, wie oben schon erwähnt, den Endpunkt /mesos durch /marathon aus. Dann sind wir mit Marathon soweit durch.
Auf den Master-Hosts sollen keine Slave-Prozesse laufen, deshalb beenden wir diese (soweit sie überhaupt laufen) und sorgen dafür, das sie beim Reboot nicht wieder starten:
sudo stop mesos-slave
echo manual | sudo tee /etc/init/mesos-slave.override
Nun soll dann auch endlich unser Konfiguration aktiv werden, an der wir schon die ganze Zeit rum basteln ;-)
sudo restart zookeeper
sudo start mesos-master
sudo start marathon
Wenn wir alles richtig gemacht haben, können wir uns auf einen der Master mal die GUI (Port 5050) anschauen z.B. http://192.168.122.251:5050/ . Man wird dann automatisch auf den Leader weitergeleitet, wenn man ihn nicht auf Anhieb erwischt. Bei Problemen kann man auf den Master-Hosts auch mal einen Blick in das ZooKeeper Log unter /var/log/zookeeper werfen. Da wir noch keine Slaves am Laufen haben, sieht die GUI noch nicht sehr spannend aus ;-)
Auf die Marathon-GUI können wir auch einen Blick werfen, welche unter Port 8080 läuft z.B. http://192.168.122.251:8080/ . Auch hier geht es nicht sonderlich spannend zu im Moment ;-)
Slave-Hosts/VMs
Da wir jetzt mit den Master-Hosts fertig sind, kümmern wir uns um die Slave-Hosts. Da wir hier keinen ZooKeeper und Mesos Master benötigen, fahren wir die Services runter (soweit sie laufen) und sorgen auch dafür, das diese Services beim Reboot nicht wieder starten. Auf ALLEN Slave-Hosts also:
sudo stop zookeeper
sudo echo manual | sudo tee /etc/init/zookeeper.override
sudo stop mesos-master
sudo echo manual | sudo tee /etc/init/mesos-master.override
Auch für die Slave-Hosts müssen wir wieder Hostname und IP festlegen diesmal im Verzeichnis /etc/mesos-slave. In unserem Fall sieht das für den ERSTEN Slave-Host dann so aus
echo "192.168.122.249" | sudo tee /etc/mesos-slave/ip
sudo cp /etc/mesos-slave/ip /etc/mesos-slave/hostname
Für die weiteren Slave-Hosts passt man die IP entsprechend an und führt die Kommandos dort aus. Dann können wir die Mesos Slaves auf ALLEN Slave-Hosts starten:
sudo service mesos-slave start
Wenn wir uns nun wieder auf eine der Mesos-Master GUIs einloggen (z.B. http://192.168.122.251:5050/), sollte auf der linken Seite irgendwo Slaves / Activated 3 stehen. Etwas weiter unten sieht man die Resourcen, die uns insgesamt im Cluster dann zur Verfügung stehen - also etwa die Anzahl der CPUs und RAM. Weitere Infos über die Slaves bekommt man, wenn man oben im Menü auf Slaves klickt.
Damit ist ZooKeeper, Mesos und Marathon soweit einsatzbereit. Über die Marathon-GUI (z.B. http://192.168.122.251:8080/) können wir dann oben links auf New Apps klicken und einen Task definieren. Zum Testen kann man einfach mal bei der ID Hello eingeben und beim Command
echo hello; sleep 10;
Man sieht dann, das alle 10 Sek. der Task auf einem Slave gestartet wird, nachdem er sich beendet hat.
Posted at 11:56nachm. Aug. 06, 2015 by cetixx in Tipps | Kommentare [0]
JAWS: The Javascript + AWS Stack
Wer mal seine Applikation komplett ohne Server und nur mit Javascript und AWS-Services aufbauen will, kann JAWS ausprobieren. Es baut komplett auf AWS-APIs und Services auf und verwendet z.B. keine EC2-Instanzen. Zum Einsatz kommen:
Javascript:
Node.js (In AWS Lambda Funktionen)
jQuery (Front-End Site)
AWS Services:
DynamoDB - Managed, NOSQL Data Storage
Lambda - Worker Tasks
API Gateway - APIs deren URLs auf Lambda Funktionen zeigen
S3 - Statische Elemente wie Bilder, CSS, usw.
Weitere:
JSON Web Tokens
Posted at 11:56nachm. Aug. 06, 2015 by cetixx in Links | Kommentare [0]
React Developer Tools
Wer mit ReactJS entwickelt, dem könnten diese Developertools eine wertvolle Hilfe sein.
Posted at 11:56nachm. Aug. 06, 2015 by cetixx in Links | Kommentare [0]
Nützliche Tools für NodeJS Projekte
Eine ganze Reihe nützlicher Tools für NodeJS Projekte listet diese Website auf.
Posted at 11:56nachm. Aug. 06, 2015 by cetixx in Links | Kommentare [0]
Polaris UI Free – User Interface Pack
Polaris ist ein schönes User Interface Set für eine Website mit Elementen wie Edit Boxes, Check Boxes, Radio Buttons, Page Navigation, Menu, Buttons und noch ein paar mehr, das man sich kostenlos herunterladen kann.
Posted at 11:56nachm. Aug. 06, 2015 by cetixx in Links | Kommentare [0]
FastoNoSQL
Eine GUI für Redis, Memached, LevelDB und SSDB (MongoDB und RocksDB sollen folgen). Mit Autovervollständigung, Tabs, Redis Cluster Support und SSH-Verbindung.
Posted at 12:12vorm. Aug. 05, 2015 by cetixx in Links | Kommentare [0]
VM mit virsh-install installieren
Wenn man libvirtd (und die div. virsh*-Tools) installiert hat, kann man sich mit folgenden Kommando eine Ubuntu 14.04 VM erzeugen:
export VMNAME=vm_name
export VMRAM=1024
export VMCPU=3
virt-install \
--extra-args 'console=ttyS0,115200n8 serial'
vm_name ersetzt man durch den Namen, den die VM später haben soll und bei virsh list angezeigt wird. VMRAM gibt die RAM-Größe an und VMCPU die Anzahl der CPUs, die die VM nutzen darf. Wenn libvirtd gestartet ist, gibt es normalerweise auch ein Netzwerk-Interface virbr0. Sollte das br0 o.ä. heissen, muss man das entsprechend anpassen.
Posted at 12:12vorm. Aug. 05, 2015 by cetixx in Tipps | Kommentare [0]
Wacken 2015 Konzerte bei 3sat
Folgende sechs Einzelkonzerte stehen schon mal fest (jeweils 60 Min.), die im TV übertragen werden:
In Flames
10. August, 2.05 Uhr (3sat) / 08. August, 20.15 Uhr (ZDFkultur)
The Boss Hoss
10. August, 3.05 Uhr (3sat) / 08. August, 21.15 Uhr (ZDFkultur)
In Extremo
10. August, 4.05 Uhr (3sat) / 08. August, 22.15 Uhr (ZDFkultur)
Running Wild
10. August, 5.05 Uhr (3sat) / 08. August, 23.15 Uhr (ZDFkultur)
Queensrÿche
14. August, 4.10 Uhr (3sat) / 08. August, 0.15 Uhr (ZDFkultur)
Cradle Of Filth
14. August, 5.10 Uhr (3sat) / 08. August, 1.15 Uhr (ZDFkultur)
Posted at 12:41vorm. Aug. 03, 2015 by cetixx in Arts | Kommentare [0]
Wacken 2015 – Vier Stunden als VOD, Sabaton LIVE
Am Samstag 1.8. übertrug 3sat 4 Stunden vom Wacken 2015. Das Konzert von Sabaton wurde LIVE übertragen. Dieses Sabaton-Konzert kommt im Winter auch als DVD raus. Unbedingt rein ziehen! Ein Hammer-Konzert! Und bei TSO & Savatage gab es eine Wacken-Premiere: Sie spielten auf zwei Bühnen gleichzeitig. Die ganzen 4 Stunden gibt es jetzt in der Mediathek!
Posted at 12:38vorm. Aug. 03, 2015 by cetixx in Arts | Kommentare [0]