Donnerstag Mrz 24, 2016

nc (netcat) als primitiver Portscanner

Wenn man kurz mal wissen möchte, ob z.B. eine Portrange offen ist, geht das recht flott mit nc (netcat) z.B.: 

nc -w 2 -zv 10.0.0.1 30000-30003

Connection to 10.0.0.1 30000 port [tcp/*] succeeded!
Connection to 
10.0.0.1 30001 port [tcp/*] succeeded!
Connection to 
10.0.0.1 30002 port [tcp/*] succeeded!
Connection to 
10.0.0.1
 30003 port [tcp/*] succeeded!

Mit -w geben wir ein Timeout von 2 Sek. an, damit wir nicht so lange warten müssen. -z prüft, ob der Port offen ist, -v macht nc etwas gesprächiger und hinten gibt man dann noch die IP und die Port(s) an.

Läuft Docker Container im privilegierten Modus?

Wie findet man raus, ob ein Docker Container im privilegierten Modus läuft?

docker inspect --format='{{.HostConfig.Privileged}}' <container id>

Dienstag Mrz 01, 2016

PID eines Prozesses auf dem Docker Host einem Docker Container zuordnen

Wenn man auf einem Server Docker am Laufen hat, sieht man vielleicht mal Prozesse auf diesem Host mit top, ps o.ä. mit hoher CPU-Belastung. Nun möchte man wissen, in welchem Container dieser Prozess läuft. Das findet man mit folgendem Kommando raus.

sudo docker ps -q | sudo xargs docker inspect --format '{{.State.Pid}}, {{.Id}}'

Die erste Spalte zeigt die PID an und dahinter die Container ID.

Dienstag Sep 08, 2015

Ersatz für KDE Quadkonsole

Bei KDE 4 hatte ich immer u.a. die KDE App Quadkonsole im Einsatz. Wird aber leider schon länger nicht mehr weiterentwickelt und unter Archlinux mit KDE Plasma 5 klappte das mit selber kompilieren auch nicht so wirklich. Als Ersatz habe ich Terminator gefunden, eine Konsole mit der man das Konsolenfenster in mehrere Teile splitten kann.

Montag Aug 31, 2015

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.

Samstag Aug 08, 2015

Wo ist mein Speicherplatz hin?

cd /in/ein/verzeichnis
du -h . | grep -P '^[0-9\.]+G

Alternativ das Tool ncdu installieren...

Gentoo - Alle installierten Pakete auflisten

equery list "*"

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.

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.

Freitag Aug 07, 2015

QuantumUI

QuantumUI sind UI Komponenten, die nativ auf AngularJS und Bootstrap CSS basieren. 

Donnerstag Aug 06, 2015

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.

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

React Developer Tools

Wer mit ReactJS entwickelt, dem könnten diese Developertools eine wertvolle Hilfe sein.

Nützliche Tools für NodeJS Projekte

Eine ganze Reihe nützlicher Tools für NodeJS Projekte listet diese Website auf.

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.