Select Page

NETWAYS Blog

Ein zweiter Blick auf die OSMC

Diese Woche fand wieder die Open Source Monitoring Conference statt, ich war zum zweiten mal dabei. Und diesmal mehr als Teilnehmer als als helfende Hand, so konnte ich mir knapp die Hälfte aller Vorträge anhören. Für viel mehr hätte ich mich teilen oder durch die Zeit reisen müssen, die Vorträge werden aber ab kommende Woche im Archiv zum anschauen und herunterladen erhältlich sein. Bei meinem ersten Besuch letzten Jahres war ich gerade einen Monat bei NETWAYS und hatte nicht viel Ahnung von Monitoring, Graphing und co, das hat sich aber geändert und ich konnte allen Vorträgen folgen.
Da meine Kollegen schon seit Montag fleißig über die Veranstaltung, Abendveranstaltung und Vorträge bloggen habe ich mir zwei Vorträge herausgesucht die mir besonders gefallen haben und über die ich ausführlicher berichten möchte.

Prometheus: A Next-Generation Monitoring System – Fabian Reinhartz

Prometheus ist ein Monitoring System aus dem Hause Google und soundcloud das ich seit Juni verfolge als ich einen Vortrag dazu auf der letzten GPN gesehen habe. Prometheus unterscheidet sich von Icinga in dem das es metrikbasiertes symptom-based Monitoring betreibt (im Gegensatz zu Icingas zustandsorientierten cause-based Vorgehen), dafür bring es ein paar sehr schöne Features mit sich wie eingebaute Dashboards die mit vorberechneten Daten gefüttert werden können, einem alertmanager der mit sogenannten rules, welche sehr komplex und mächtig werden können, gesteuert werden kann. Das ganze funktioniert sogar ganz ohne Abhängigkeiten, eine Leistung die die Sprache Go ermöglicht.
CUFtA3tWoAAVEXL
Nach dem Vortragen der Fakten wechselte Fabian Reinartz in die Konsole und setzte schnelle ein Demo System auf. Falls das jemand ausprobieren will: Es gibt Docker Container

Testing in Production – Devdas Bhagat

Go ahead, deploy to production! It’s just a testing environment anyways.

Mit diesem Zitat fasste Devdas Bhagat am Ende seinen Vortrag zusammen. Hier erwähne ich gleich dass der Referent aus dem E-Commerce Bereich kommt und man diese Philosophie bitte nicht in Sicherheitskritischen Designs einsetzen sollte, etwa Brücken, Raketen oder Kaffeemaschinen.
Mit seinem Vortrag "Testing In Production"
Die Idee dahinter ist anstatt lange herumzuüberlegen und dann Entscheidungen zu treffen einfach alle Alternativen in der realen Welt zu testen und dann anhand von Kunden Reaktionen die erfolgreichste auszuwählen. Dabei greift Devdas eine ungern gehörte Wahrheit auf: Kein System kann perfekt sein, vor allem nicht wenn es mit Menschen in Kontakt kommt. Daher eröffnete er auch das Credo:

Good enough is good enough

Das treibt jeden Perfektionisten die Schweißperlen auf die Stirn, aber Tautologien sind nun mal immer wahr. Leider ging er mir in seinem Vortrag zu wenig auf Details ein: Wie sammle ich die Metriken? Was für Programmierer brauche ich die sich trauen “einfach mal zu machen”? Damit war ich auch nicht der einzige und es gab eine sehr interessante und fröhliche Fragerunde nach dem Vortrag so dass alle ohne Unklarheiten in die Pause gehen konnten.
 
So bleibt mir noch zu sagen das ich mich auf die OSMC nächstes Jahr schon freue, hoffentlich wieder mit vielen interessanten Vorträgen.

dwm – Der beste Window Manager

Screenshot

Ein Screenshot meiner dwm Umgebung auf der Arbeit. Zu sehen sind die statusbar, das tiling und floating Verhalten und die Workspaces


Der dynamic window manager ist, im Gegensatz zu seinem Windows Namensvetter “Desktop Window Manager”, eine ressourcenschonende, volle tiling Umgebung. Wie bei allen anderen suckless Projekten stehen auch bei dwm die Vermeidung von bloat und die Codequalität im Vordergrund. So bewegt sich der Sourcecode im Bereich eines halben Megabytes während i3 schon mit über zehn daher kommt. Er kommt extrem minimalistisch in seiner Grundform, mit nur ein paar sinnvollen default Einstellungen, aber auch hoch konfigurierbar.
Konfiguration wird direkt im Quellcode vorgenommen was zur folge hat dass das Programm nach jeder Änderung neu kompiliert werden muss. Deshalb ist auch wenig sinnvoll Pakete für dwm zu verwenden, Gentoo feeling auf allen Distributionen also. Und wo wir grade bei Distributionsunabhängigkeit sind: Die beste Quelle für Informationen und Tipps zur Verwendung von dwm ist sein Eintrag in der ArchWiki.
config.h

Ein Ausschnitt aus der config.h


Ganz im Geiste der Sache wird in Form von Patches die in die eigene Konfiguration gemerged werden erweitert. Das wohl praktischste, gar notwendige Tool dabei ist dmenu, mit diesem Leichtgewicht
lassen sich bequem jederzeit Programme starten. Auch eine Uhr oder Batterieanzeige sind keine Selbstverständlichkeit und müssen entweder selbst gebaut oder von anderen dwm Nutzern übernommen werden.
Am Ende war es mir den Aufwand jedenfalls wert, wenn ich jetzt noch eine ordentliche Konsolen alternative für pidgin finde muss ich die Maus gar nicht mehr berühren.

Host-only network with virtual CentOS 7 instances

There are a bunch of guides out there on how to create a virtualbox network to work with about every client distribution there is. This is another one, for CentOS 7. All you will need to do this is a text editor and a minimal CentOS 7 installation, no networkmanager, no ifconfig.
If you want your box to be able to connect to the internet you will first need to add a NAT adapter, which is the default so you probably won’t have to do anything.
Now to the hard part:

1. Create a Host-Only network

Create Host-Only network
You can ignore the ipv6 part. But you should use an ipv4 address and network mask that make sense. A /24 should do the job in most cases. Also make sure disable the DHCP Server

2. Add a Host-Only network adapter to your machine

add network

3. Configure the vbox network

The following commands are to be run from the box itself and assume a standard CentOS 7 installation.
First you need to know the name of your Host-Only interface.

# ip a 

The right interface is the one without an ipv4 address, in my case enp0s8.
Now you will need to create an ifcfg for that interface.

# vim /etc/sysconfig/network/scripts/ifcfg-enp0s8 
TYPE="Ethernet"
BOOTPROTO="static"
IPADDR="192.168.24.10"
NETMASK="255.255.255.0"
NAME="enp0s8"
DEVICE="enp0s8"
ONBOOT="yes"

Now just restart the network service

# systemctl restart network.service 

To check whether everything worked check ip a and try to ping the new ip from the host machine.

Azubis erzählen: Juli 2015 Jean

This entry is part 11 of 17 in the series Azubis erzählen

Name: Jean-Marcel Fach
Ausbildungsberuf: Fachinformatiker für Anwendungsentwicklung
Abteilung: Icinga2 core development
Lehrjahr: 1

Nach einer längeren Berufsschul- und Urlaubsphase kam ich wieder in Firma, dort liefen schon die Vorbereitungen für Icinga 2.4. Nach einem ein-wöchigem Workshop war grob umrissen wie der Arbeitsplan für die nächsten paar Monate aussieht. Als erster Meilenstein gilt der HTTP Server, welcher Anfragen dieses Schemas entgegennimmt und antwortet. Einen Teil der Information machen die URLs auf die der Server angesprochen wird aus, für diese einen Parser zu schreiben wurde meine Aufgabe.
Nun sind *normale* URLs wie “https://www.netways.de/” allen bekannt und jedem der mal genauer hin geschaut hat wird aufgefallen sein, dass sich bei allen Seiten im Internet ein Muster erkennen lässt. Dieses URL-Muster wurde zuerst im RFC 1738 und später im RFC 3986 genauer beschrieben, diese 60 Seiten Dokument lassen sich grob so zusammenfassen: Das Muster einer URL ist immer `Schema:Autorität/Pfad?Anfrage#Fragment`. Nun haben die einzelnen URL-Teile wieder eigene Regeln. Etwa bedeutet ein ‘//’ in der Autorität, dass ein Hostname zu erwarten ist. Oder ein ‘gopher’ als Schema ändert nochmal mehr. Es ergeben sich so eine Reihe von URLs die gültig aussehen, es aber nicht sind und anders herum, aber dazu später mehr.
Im Bezug auf die Implementation, dachte ich zuerst an eine Zustandsmaschine: aus dem vorherigen Zeichen ergibt sich, wie das nächste zu verstehen ist. Leider konnte ich mich mit keiner Implementation in c++ so richtig anfreunden. Ein riesiges switch-case Konstrukt fällt aus da es eben riesig und daher unübersichtlich und hässlich würde. Und die Alternative mit Objekten schien zu dieser Zeit den Rahmen zu sprengen, würde mir aber dieselbe Aufgabe noch einmal gestellt werden, würde ich aber diesen Weg wählen. So fiel die Wahl am Ende, nach all dem Rumprobieren, doch auf eine sequentielle Abarbeitung der fünf Teile. Da die URLs nur http oder https sein werden, konnten viele Probleme umgangen werden.
URL tests
Die tatsächliche Implementation war dann relativ einfach, doch dann kamen die Randfälle. “/” ist gültig und “/??[]=?#?=@” auch, wenn sie auch unsinnig sind. Daher mussten Tests geschrieben werden. Und dann wurde so lange geschraubt, bis alle Tests erfolgreich durchgeführt wurden.
Der Code findet sich wie immer im Icinga 2 git.

Python statt PHP

Gründe gegen die Verwendung von PHP findet man im Internet viele, auch Alternativen werden in regen Mengen angepriesen. Nun musste ich mir eine davon aussuchen wenn ich meine Vorurteile gegenüber PHP nicht bestätigen oder verlieren wollte.
Zum Glück wurde ein Kollege auf mein Dilemma aufmerksam und konnte mich in Richtung Flask weisen und so all meine Probleme lösen, und zwar mit Python. Um Bjarne Stroustrup zu paraphrasieren: “There are only two kinds of languages: the ones people complain about and the ones nobody uses. And then there is Python” Mehr oder weniger. Nun verkauft sich Flask als microframework, als ich das letzte mal davon hörte mussten Banken gerettet werden und der Schrottmarkt brach ein. Laut Flask ist damit natürlich kein Wirtschaftsplan gemeint sondern (Übersetzt von mir):

“Das “micro” in microframework bedeutet Flasks Ziel ist es den Kern einfach aber erweiterbar zu halten”

Soso, sehr schön. Damit ist auch das Anstands-Erwähnen der Philosophie abgehakt und endlich kann Code gezeigt werden.

from flask import Flask
app = Flask(__name__)
@app.route("/")
def hello():
    return "Hello World!"
if __name__ == "__main__":
    app.run()

Etwas länger als ein `echo “Hello World!\n”;` aber definitiv ein Programm mit einer Main Funktion, return und imports. Fühlt sich eben besser an als diese schwarze Magie die sonst am Werk ist. Leider reicht das nicht um eine schöne Seite zu bauen, daher kommt Flask mit Jinja2, dank dieser Template Engine kann das Design einfach ausgelagert und von der Programm Logik getrennt werden. So ist es möglich die Entwicklung des Backends des Frontends und die des Frontends des Frontends auch bei kleinen Projekten aufzuteilen. Also genau das was ich brauche. Python, ho!