everflux

Nach der enttäuschenden Feststellung, dass selbst ein Raspberry Pi3 lediglich 100mbit als Netzwerkport und mit USB Gigabit Ethernetadaptern auch nur maximal 450mbit aufgrund der USB 2 Bandbreite zu erzielen ist, musste ein anderes Gerät her.

Ausgewählt habe ich einen Odroid-XU4, der auch Gigabit direkt onboard mitbringt und dank USB 3 auch in der Lage ist Gigabit zu bedienen. Aufgrund der Big-Little Architektur gibt es hier zwar acht CPU Kerne, diese sind jedoch unterschiedlich leistungsfähig. Um die optimale Netzwerkgeschwindigkeit zu erzielen, müssen einige Einstellungen am Odroid vorgenommen werden. Andernfalls ist auch bei rund 170-200 mbit Durchsatz Ende.

Zum einen muss der Interrupt für die Netzwerkkarte auf eine andere CPU als die Default-CPU 0 gelegt werdenm denn die ist mit Interrupts sowieso gut beschäftigt.

Zum anderen kann man noch dem Netzwerkstack mitteilen, mit welchen IRQs anstehende Daten behandelt werden sollen.

echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus

Um stets die bestmögliche Performance zu erzielen kann noch der CPU Governor angepasst werden.

Google hat mit der Wahl der Jetbrains Platform für ihr Android Studio eine gute Wahl gemacht. (Auch wenn ich mir persönlich gewünscht hätte, dass es NetBeans wird, aber das war bei dem Verhalten von Oracle ja kaum zu erwarten.) Dennoch gibt es ab und zu Gründe, ohne Android Studio eine Installation der Android Entwicklungswerkzeuge vorzunehmen. (Zum Beispiel, wenn man NativeScript nutzt und dabei in WebStorm unterwegs ist…)

Nach der Umstellung des SDK ist es schwierig, aktuelle Anleitungen für Ubuntu zu finden, die nicht mit „Download Android Studio…“ beginnen.

Darum hier jetzt meine Kurzanleitung:

1. Auf 64bit Systemen wird noch immer eine 32bit Umgebung benötigt, diese installiert man mittels
   sudo apt-get install lib32ncurses5 lib32stdc++6 libstdc++6
2. Ordner anlegen, wo das Android SDK und die Werkzeuge landen sollen, ich wähle mal
   mkdir ~/tools/android-sdk<c/ode>
3. Download der Kommandozeilen Werkzeuge des SDK
   wget https://dl.google.com/android/repository/sdk-tools-linux-3859397.zip
4. Das wird dann unter ~/tools/android-sdk ausgepackt, entstehen wird danach der Ordner „tools“
5. Die entstehenden Android Verzeichnisse werden in den PATH aufgenommen, damit von der Kommandozeile die Programme gefunden werden. Ob das jetzt in die ~/.bashrc oder ~/.zshrc oder ~/.sonstwasrc muss, wird jeder selbst wissen.
   

   export ANDROID_HOME=~/tools/android-sdk
   export PATH=$PATH:$ANDROID_HOME/emulator:$ANDROID_HOME/tools:$ANDROID_HOME/tools/bin:$ANDROID_HOME/platform-tools

6. Nun folgt ein umfangreicherer Download….
   

   sdkmanager --update
   sdkmanager "extras;android;m2repository" "extras;google;m2repository" "system-images;android-25;google_apis;x86" "system-images;android-25;google_apis;x86_64" "platforms;android-25" "build-tools;25.0.3"

7. Und „schon“ kann ein Android Emulator Image instantiiert werden
   avdmanager create avd -d 9 --abi google_apis/x86 --name nexus5x  -k "system-images;android-25;google_apis;x86"

8. Gestartet wird das ganze dann z.B. so:
   emulator @nexus5x -skin 768x1280

Schon ist das Android SDK Setup unter Ubuntu fertig.

Leider stehen einige Optionen, wie „–skin“ bei dem avdmanager (noch) nicht zur Verfügung, so dass beim Emulator Start der Parameter mit angegeben werden muss. Sonst gibt es ein Guckloch im Format einer Briefmarke für den Emulator…

Let’s encrypt hat es vorgemacht, jetzt zieht der Let’s encrypt Partner StartCOM nach: Neuerdings gibt es eine API! Damit ist es deutlich einfacher, neue Zertifikate in einem automatisierten Prozess zu erhalten.

Laut Webseite ist die API auch für die kostenlosen Domain-Validated Zertifikate nutzbar, jedoch auf 5 Domains beschränkt. Für die meisten privaten Nutzer sollte das mehr als ausreichend sein. Im Gegensatz zu Let’s encrypt Zertifikaten sind die StartCOM StartSSL Zertifikate ein Jahr gültig, so dass es seltener nötig ist, neue Zertifikate zu holen.

Infos im Blogpost von StartSSL: https://startssl.com/NewsDetails?date=20160428 direkt zur API geht es hier: https://startssl.com/startapi

I you are using Netbeans to develop a maven based (multi-module) (web) application you may have encountered this problem: The resources are not copied when re-running the application. The easy option: Build the project always before running it.

This is slow and just feels wrong. Netbeans lets you customize the life-cycle of your project, so you can hook all maven executions you like, especially the ‚resources‘ build step.

Open project properties, select ‚Actions‘ and add ‚resources:resources‘ to the front of the ‚execute Goals‘ field:

You can add your own custom action as well, in case you want to trigger a specific step independently of the overall project lifecycle, for example the ‚resources:resources‘ goal:

As I regularly test different versions of Netbeans as part of the community acceptance program (NetCAT) and for my own fun and benefit I sometimes struggle to start of the right version: Usually the release version is the right one to go. During NetCAT the beta version needs to be tested and when new features are so promising that you want to run the nightly, you go with that.

I came up with a simple solution to never  launch the wrong edition: Differently colored Netbeans icons. This is how my Gnome launcher looks:

Easy to tell that red is the nightly, without looking at the icon text! If you want that for yourself, you can get the icons here:

The icons are created using Gimp and just rotating the colors, so it’s a little hacky but does the trick.

In Gnome you can use the application ‚alacarte‘ (or ‚main menu‘ if you run the english locale) to customize your launchers. Just change the icon:

Vielleicht hilft dieser Tipp dem einen oder anderen weiter, der gerne die Netbeans IDE zur PHP Entwicklung verwendet und auch Vagrant nutzt: Wenn man mit Vagrant arbeitet, so werden die lokalen Dateien in der virtuellen Maschine gemounted. Für Netbeans konfiguriert man daher „lokalen Webserver“ als Umgebung.
Die Konfiguration von xdebug sieht dann am einfachsten so aus:

[xdebug]
xdebug.remote_enable = 1
xdebug.remote_connect_back = 1
;xdebug.remote_autostart = 1
xdebug.remote_handler=dbgp

Hier wird xdebug angewiesen, sich zum Aufrufer zurück zu verbinden – die IP wird aus dem Request genommen. Das passt in der Regel, wenn man innerhalb von Vagrant nicht noch wilde Sachen (Proxy) macht.
Was leider nicht passt: Die Pfade. Netbeans weißt xdebug für Breakpoints an, welche Datei – inkl. Pfad – an welcher Stelle einen Breakpoint erhalten soll. Die Ordnerstruktur ist innerhalb der virtuellen Maschine höchstwahrscheinlich anders, als auf dem Host-System.
Hierzu gibt man innerhalb von Netbeans noch ein Pfad-Mapping an: Projekt Konfiguration, „Run Configuration“, „Advanced“.
Nun waehlt man aus, wo man innerhalb der Vagrant bzw. VirtualBox Umbebung den Projekt Ordner eingebunden hat. In meinem Beispiel ist das /var/www/localhost

Anschließend kann man den Netbeans Debugger verwenden.
Möchte man spezielle Requests, wie z.B. PUT, mittels curl aufrufen kann man dies auch ganz einfach machen, in dem man den Xdebug Trigger als Parameter anhängt:

curl -X PUT -d '{}' http://localhost:8080/rest/endpoint.php/duplicates\?XDEBUG_SESSION_START\=netbeans-xdebug


Ein Screenshot der Netbeans Konfiguration als Referenz:

Middleman ist ein static site generator der sich einiges von Ruby-On-Rails leiht, aber eben nur statische Seiten generiert. In vielen Anwendungsfällen ist das auch genau das richtige.

Um die Web-Entwicklung zu erleichtern – vor allem auch mit mobilen Geräten – gibt es das vorzügliche Werkzeug „livereload“. Damit wird im Browser ein reload ausgelöst, wenn sich die Quellen geändert haben. Das spart Zeit und man muss nicht dauernd aus dem Texteditor oder der IDE raus um im Browser einen Reload manuell auszulösen. Zur Integration gibt es zum einen native Browser Extensions, zum anderen kann dies auch über ein JavaScript integriert werden.
Hinter den Kulissen nutzt livereload einen Websocket (ggf. mit Polyfill über Flash) um  den Client dann zu informieren.

Was liegt nun näher, als middleman als static site generator mit livereload zu verbinden. Am besten das ganze noch mit vagrant, so dass man eine isolierte Entwicklungsumgebung hat. Da vagrant mit VirtualBox arbeitet, kommt etwas mehr Komplexität auf einen zu. Der middleman läuft nun nicht mehr auf dem physischen Rechner sondern virtualisiert – damit hat er auch eine andere IP. Einzelne Ports koennen in die virtuelle vagrant Maschine reingereicht werden, das ist für das livereload wegen des Websockets schon mal wichtig. Dazu muss in der vagrant Konfiguration (Vagrantfile) folgender Eintrag vorhanden sein:

#middleman live reload port
config.vm.network :forwarded_port, host: 35729, guest: 35729


Jetzt muss middleman noch konfiguriert werden, dass es auch livereload verwendet:
Im Gemfile für middleman:

gem 'middleman-livereload'


In der middleman Konfigurationsdatei muss nun das livereload konfiguriert werden. Hier ist nun die Besonderheit: Das Livereload Plugin differenziert nicht zwischen der Host-Angabe um das Interface zu bestimmen an den der Websocket Server gebunden wird, und der URL die für den Zugriff auf den livereload Server verwendet wird. Gibt man hier „127.0.0.1“ an, bindet er nur an das lokale Interface in der virtuellen Maschine. Gleiches für „localhost“. Gibt man die externe IP des Hosts an, dann findet das rack-livereload das Interface nicht.

Da hilft als letztes nur noch das „Universalbinding“ – zum Glück ist das auch vom Browser nachher aufrufbar:

activate :livereload, :host => '0.0.0.0', :no_swf => true

Was in meinem Fall noch wichtig war: Das Assset hashing darf nicht ausserhalb der build Konfiguration aktiviert sein, andernfalls wird kein JavaScript beim Middleman-server injected.

Was nun noch wichtig ist: Das von VirtualBox verwendete Filesystem-Mounting unterstuetzt kein notify. Damit muss der middleman server zwingend den Polling-Modus verwenden:

middleman server --force-polling

Der einzige Wermutstropfen: Das funktioniert natürlich dann nur auf dem Entwicklungsrechner. Mit ipad oder Android Telefon im WLAN kommt man mit dem „0.0.0.0“ nicht weit. Aber immerhin funktioniert so das live reload mit vagrant.

Durch eine unglueckliche Konstellation kam es dazu, dass mir von laufenden, produktiven, KVM Maschinen die Images abhanden kamen. Kurzum: Gelöscht. Aber da die Maschinen noch liefen eine gute Gelegenheit sich an der Rettung zu versuchen, und nicht über ein Backup zu arbeiten.
Dadurch, dass die Datei Images noch in Benutzung waren, war ein File-Handle mit dem jeweiligen Prozess verknüpft. Dieser kann nach Belieben noch mit der Datei arbeiten, auch das Dateisystem betrachtet die zu der Datei gehörenden Datenblöcke nicht als frei und bewahrt sie somit vor Verlust. Solange der Prozess läuft aber nur.

Zur Illustration verwenden wir einmal folgende Kommandos:

wget --limit-rate=1000 http://releases.ubuntu.com/14.04/ubuntu-14.04-desktop-amd64.iso

Der Download ist extra langsam gedreht, so dass genug Zeit ist zum experimentieren.
Nun loeschen wir die Datei – das wget laeuft weiter.

rm ubuntu-14.04-desktop-amd64.iso

Suchen wir nun nach Prozessen, die auf gelöschte Dateien zugreifen und filtern nach Dateien mit dem Wort „ubuntu“:

lsof | grep deleted | grep ubuntu
wget 10694 tkruse 4w REG 252,1 195943 1573596 /home/tkruse/ubuntu-14.04-desktop-amd64.iso (deleted)


Der einfachste Weg den Inhalt zu retten wäre nun, einfach die Datei(inhalte) zu kopieren. Dazu suchen wir das Filehandle des Prozesses „10694“ (dem wget aus dem lsof)

ls -l /proc/10694/fd             
total 0
lrwx------ 1 tkruse tkruse 64 Jul 12 13:02 0 -> /dev/pts/7
lrwx------ 1 tkruse tkruse 64 Jul 12 13:02 1 -> /dev/pts/7
lrwx------ 1 tkruse tkruse 64 Jul 12 13:02 2 -> /dev/pts/7
lrwx------ 1 tkruse tkruse 64 Jul 12 13:02 3 -> socket:[797560]
l-wx------ 1 tkruse tkruse 64 Jul 12 13:02 4 -> /home/tkruse/ubuntu-14.04-desktop-amd64.iso.1 (deleted)

Das Datei handle können wir als Quelle nehmen, und den Inhalt nun kopieren:

cp /proc/10694/fd/4 /home/tkruse/rescue


Da die Maschinen noch laufen, wäre es eigentlich schön nicht einen Zustand zu kopieren, sondern die Datei auf ’nicht gelöscht‘ setzen zu können. Das ging mal mit ln -L, wurde jedoch aus Sicherheitsgründen aus dem Kernel entfernt.

Dazu kann man nur noch direkt ins Dateisystem eingreifen. Nichts für Angsthasen – und ein fsck sollte danach besser stattfinden.
Mittels debugfs kann man einen neuen Link auf die inode der Datei anlegen. Darüber kann danach wieder ein Zugriff erfolgen. Jedoch wird dabei der Link-Count nicht erhöht, so dass die Datei nicht wirklich wieder hergestellt ist.
Die inode ist die Zahl aus dem lsof vor dem Dateipfad, in diesem Fall „1573596“. Legen wir also eine neue Datei an, die diese inode nutzt:

sudo debugfs -w /dev/mapper/ubuntu--gnome--vg-root -R "link <1573596> rescue"

Anschließend kann man den Prozess, der die Datei bisher noch offen und damit am Leben gehalten hat, beenden und die Datei (auf ein anderes Dateisystem) kopieren.

cp rescue ....

Ist man damit fertig, kann man den Link wieder aufheben.

sudo debugfs -w /dev/mapper/ubuntu--gnome--vg-root -R "unlink rescue"


Durch durch das debugfs ist es im Prinzip auch möglich den Linkcount zu reparieren, das war mir jedoch etwas zu warm. Auch bin ich nicht sicher, wie es sich mit dem „gelöscht“ Flag tatsächlich verhält, so dass ich die Daten dann auf ein anderes Dateisystem kopiert habe (um versehentliches überschreiben zu verhindern), das betroffene Dateisystem ausgehängt und per fsck geprüft habe.
Soweit ich das beurteilen kann: Die Datei wurde perfekt gerettet und alles läuft mit minimaler Downtime weiter.

Wäre es nicht fantastisch, wenn es ein Tool gäbe, dass wie tcpdump auf System-Ebene arbeitet? Vielleicht noch gemischt mit lsof. Und strace. Und das ganze vielleicht auch so dass man im Nachhinein filtern kann!

Das gibt es. Es nennt sich „sysdig“ und ist OpenSource: http://www.sysdig.org/ bzw. https://github.com/draios/sysdig/

Die Installation auf einem Ubuntu 14.04 sollte eigentlich so funktionieren:

curl -s https://s3.amazonaws.com/download.draios.com/stable/install-sysdig | sudo bash

Das hat leider nicht ganz geklappt:

curl -s https://s3.amazonaws.com/download.draios.com/stable/install-sysdig | sudo bash
[sudo] password for tkruse:
* Detecting operating system
* Installing Draios public key
OK
* Installing Draios repository
* Installing kernel headers
E: Package 'linux-headers-3.11.0-12-generic' has no installation candidate
Unable to find kernel development files for the current kernel version 3.11.0-12-generic
This usually means that your system is not up-to-date or you installed a custom kernel version.
The installation will continue but you'll need to install these yourself in order to use sysdig.
Please write to the mailing list at https://groups.google.com/forum/#!forum/sysdig
if you need further assistance.
* Installing Sysdig
Selecting previously unselected package sysdig.
(Reading database ... 207643 files and directories currently installed.)
Preparing to unpack .../sysdig_0.1.82_amd64.deb ...
Unpacking sysdig (0.1.82) ...
Processing triggers for man-db (2.6.7.1-1) ...
Setting up sysdig (0.1.82) ...
Loading new sysdig-0.1.82 DKMS files...
First Installation: checking all kernels...
Building only for 3.11.0-12-generic
Module build for the currently running kernel was skipped since the
kernel source for this kernel does not seem to be installed.

Offenbar war mein Kernel nicht beim Update auf Ubuntu 14.04 mitgezogen worden:

uname -a
Linux charix 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Dafuer gab es keine Kernel-Header mehr, so dass die sysdig Module nicht kompiliert und installiert werden konnten.
Das ist schnell zu beheben, neuer Kernel und neue Header:

sudo apt-get install linux-image-3.13.0-24-generic
sudo dpkg-reconfigure sysdig
Removing old sysdig-0.1.82 DKMS files...

-------- Uninstall Beginning --------
Module: sysdig
Version: 0.1.82
Kernel: 3.13.0-24-generic (x86_64)
-------------------------------------

Status: Before uninstall, this module version was ACTIVE on this kernel.

sysdig-probe.ko:
- Uninstallation
- Deleting from: /lib/modules/3.13.0-24-generic/updates/dkms/
- Original module
- No original module was found for this module on this kernel.
- Use the dkms install command to reinstall any previous module version.

depmod....

DKMS: uninstall completed.

------------------------------
Deleting module version: 0.1.82
completely from the DKMS tree.
------------------------------
Done.
Loading new sysdig-0.1.82 DKMS files...
Building for 3.11.0-12-generic and 3.13.0-24-generic
Module build for the currently running kernel was skipped since the
kernel source for this kernel does not seem to be installed.
Building initial module for 3.13.0-24-generic
Done.

sysdig-probe:
Running module version sanity check.
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/3.13.0-24-generic/updates/dkms/

depmod....

DKMS: install completed.

Danach kann dann sysdig auch schon benutzt werden.
Hier ein Beispiel: „Zeige alle Prozesse, die auf Dateien in /etc zugreifen“

sudo sysdig evt.type=open and fd.name contains /etc

Die Ausgabe sieht z.B. dann so aus:

208208 13:10:12.791863631 0 DNS (4278) < open fd=73(/etc/hosts) name=/etc/hosts flags=1(O_RDONLY) mode=0 
208307 13:10:12.792037164 3 DNS (4283) < open fd=74(/etc/hosts) name=/etc/hosts flags=1(O_RDONLY) mode=0 
444807 13:10:27.793785895 0 DNS (5019) < open fd=72(/etc/hosts) name=/etc/hosts flags=1(O_RDONLY) mode=0 
470806 13:10:32.317263671 1 gnome-settings- (3411) < open fd=19(/etc/fstab) name=/etc/fstab flags=1(O_RDONLY) mode=0 
546476 13:10:42.794281200 2 DNS (4278) < open fd=72(/etc/hosts) name=/etc/hosts flags=1(O_RDONLY) mode=0 

Auch kann man mal eben schnell schauen wer am meisten Netzwerkbandbreite braucht:

sudo sysdig -c topprocs_net

Beispielausgabe:

Bytes     Process   
------------------------------
23.82KB   Socket
546B      dnsmasq
239B      pidgin
215B      DNS

(Socket ist hier der Firefox, der eine Webseite lädt.)

Das ist extrem praktische für diverse Diagnosen. Ein interessantes Beispiel für den Einsatz liefert der Blog-Post der Entwickler, die dabei im Nachhinein analysieren, was bei einem Einbruch in einen Honeypot-Server passierte: http://draios.com/fishing-for-hackers/

Viele weitere Beispiele (IO, CPU, Security…) finden sich auf dieser Seite: https://github.com/draios/sysdig/wiki/Sysdig%20Examples

Das hat echt eine Weile gedauert dieses Yak zu shaven: Dank Vagrant und VirtualBox habe ich ein Web-Projekt mit einer leicht zu startenden Entwicklungsumgebung versehen.

Das hat vorher auch schon prima geklappt, und das Verfahren hat sich bewährt – besonders, wenn das Setup etwas komplexer ist, oder es Entwickler gibt die nicht mit Linux/Debian/Ubuntu arbeiten. Jedoch hat mich heute ein Bug gequält den ich wirklich einige Stunden suchen durfte. Alles fing damit an, dass es JavaScript Fehler hagelte.

Uncaught SyntaxError: Unexpected token ILLEGAL

Jedoch nur, wenn die Datei aus Vagrant per nginx ausgeliefert wurde. Mit Netbeans und dem eingebauten mini-Webserver für HTML5 Projekte lief alles super.

Eine Google Suche brachte unglaublich viele Ergebnisse – jedoch keine Lösung. Man solle nach bösen Zeichen schauen, am besten nach Whitespace das komisch ist. Eine super Chance auf den Holzweg abzubiegen und da eine Weile unterwegs zu sein.

Die Quellcode-Ansicht von Firefox brachte dann erstaunliches zu Tage:

Das sieht in der Tat kaputt aus. Mal schnell im Editor schauen – nein da ist alles gut. Auf der Vagrant Maschine nachschauen, auch da alles in Ordnung. (Sowas in der Art hatte ich schonmal wenn die Guest-Additions von VirtualBox nicht mehr so recht zur Umgebung passen. Aber das war hier nicht der Fall.)

Auch das Einfügen von dummy-Text änderte weder etwas an dem Muell am Ende der Datei, noch wurde der Text angezeigt. Nanu, was kann das sein? Schnell noch einen Holzweg her! „Ist bestimmt Caching.“

Das Rätsels Lösung ist dann ein 5 Jahre alter Bug in VirtualBox, wohl auch bei Apache oder sogar Versionsverwaltungssoftware zuschlagen kann: VirtualBox hat Probleme mit direktem mmap zwischen zwei Filehandles, wenn es sich dabei um per vboxfs gemountete Verzeichnisse handelt.

Hier das Ticket dazu: https://www.virtualbox.org/ticket/819

Bei nginx kann man sendfile sehr einfach ausschalten:

sendfile off;

Danach klappt alles wie erwartet.