Die OSMC startet Early-Bird-Phase und Call for Papers

Nachdem die Open Source Monitoring Conference letztes Jahr ihr zehnjähriges Bestehen feiern durfte, starten wir nach der erfolgreichen OSDC in Berlin dieses Jahr voller Elan in die Vorbereitungen für den Beginn des zweiten OSMC-Jahrzehnts.

Die international ausgerichtete Konferenz findet vom 29. November bis 02. Dezember 2016 in Nürnberg statt und wird auch in diesem Jahr wieder ein breites Spektrum zum Thema Open Source Monitoring bieten. Konferenzteilnehmer können sich hier auf den neuesten Stand bringen, inspirieren lassen, oder auf unserer Abendveranstaltung in entspannter Atmosphäre mit den Entwicklern in Kontakt treten. Das macht die OSMC für unsere Teilnehmer so einzigartig.

BereitsAktuelles_Konfbanner_CFP jetzt suchen wir wieder jede Menge interessante Vorschläge für unser Konferenzprogramm. Sollten Sie eine Idee haben, kann diese in Form eines Vortragsvorschlages bis zum 30. Juni 2016 über das Call for Papers Formular auf der OSMC Website eingereicht werden.

Möchten auch Sie dieses Jahr Teil des „Klassentreffen für Systemadministratoren“ sein? Das können Sie! – sowohl als Speaker, als auch als Teilnehmer.
Sparfüchse haben natürlich auch dieses Jahr wieder die Möglichkeit, sich bereits jetzt ihr heiß begehrtes Konferenzticket bis zum 30.06.2016 zum verbilligten Early-Bird-Preis zu sichern.

Die Tickets sind sowohl mit als auch ohne Übernachtung erhältlich. Beliebig als Add-Ons hinzubuchbar sind die am Vortag stattfindenden Workshops, sowie der Hackathon am letzten Tag, den wir aufgrund des großen Erfolges auch in diesem Jahr wieder durchführen werden.

Also, nicht lange warten – sparen! Hier geht’s zu den Tickets.

P.S.: Dieses Jahr lässt sich die OSMC auch wieder mit einem Besuch auf dem Nürnberger Christkindlesmarkt verbinden. Und der ist – genau wie unsere Konferenz – immer einen Besuch wert 😉

Julia Hackbarth

Autor: Julia Hackbarth

Julia ist seit 2015 bei NETWAYS. Sie hat im September ihre Ausbildung zur Kauffrau für Büromanagement gestartet. Etwas zu organisieren macht ihr großen Spaß und sie freut sich auf vielseitige Herausforderungen. In ihrer Freizeit spielt Handball eine große Rolle: Julia steht selbst aktiv auf dem Feld, übernimmt aber auch gerne den Part als Schiedsrichterin.

HWgroup STE2: Softwareupdate verfügbar

HW group STE2Das HW group STE 2 ist ein Netzwekthermometer der neuesten Generation. Bestückt mit vielen neuen Features ist es ein adäquater Nachfolger des Vorgängers HW group STE. Eine Integration in Icinga oder Nagios durch ein angepasstes Plugin versteht sich von selbst. Hard- und Software sind komplett umgestaltet und neu aufgelegt worden. Dies kann natürlich so am Anfang der Markteinführung zu häufigen Updates führen.

Einer unserer Kunden wies uns auf den Fehler hin, dass die SNMP-Community nicht von “public” auf “private” geändert werden. Diesen gaben wir nach einem internen Test umgehend an die HW group weiter und freuten uns über das rasche Fixen durch das aktuelle Softwareupdate. Dieses kann ab sofort bequem übe HW group heruntergeladen werden. Wir haben es getestet und können nur sagen: Es hält, was es verspricht.

ChangeLog:

  • Fix: SNMP Community
  • Add: HWg-SMS-GW3 support

 

Isabel Salampasidis

Autor: Isabel Salampasidis

Isabel ist seit Februar zurück bei NETWAYS. Bis 2009 war sie unsere Office Managerin und verstärkt nun ab sofort das Sales Team. Hier ist sie für alle Belange des Online Stores verantwortlich. Der Ein- und Verkauf der Monitoring Hardware sowie die Weiterentwicklung des Shops und seines Portfolios wird sie mit ihrem bekannten Tatendrang gehörig vorantreiben. Privat verbringt die halbgriechische Ruhrpott-Fränkin sehr gerne so viel Zeit wie möglich mit ihren bald 4-jährigen Patensöhnen oder schreit sich für den Club - als stolze Dauerkartenbesitzerin! - die Seele aus dem Leib.

Tips für Bahnreisende – Heute: Bahn Wagenreihungsplan

Für Menschen, die viel mit der Deutschen Bahn durch Deutschland gondeln, ist eine Sitzplatzreservierung oft unverzichtbar.

Wenn man nun, wie z.B. in Frankfurt oder München, in einem Kopfbahnhof ein- oder aussteigen will, stellt sich oft die Frage, welcher Wagen steht denn da wo.

Bisher ist diese Info, außer am Bahnsteig, schwer zu bekommen. Man konnte nur versuchen in der Datensammlung auf grahnert.de etwas brauchbares zu finden. Leider sind die Daten oft nicht aktuell.

Durch einen Tipp auf Twitter wurde ich auf die App Bahnhof Live aufmerksam (Android) (iOS), und das hilft – zumindest mir – schon mal sehr.

Und tatsächlich, dort kann man für den aktuell Tag bei jedem Bahnhof den Wagenreihungsplan finden. Das ist doch schon mal eine tolle Quelle.

Zumindest sagt die Bahn dass voraussichtlich dieses Jahr noch mehr kommen soll. (Hoffentlich direkt bei der Sitzplatzwahl)

Bahnhof-Live-2

Markus Frosch

Autor: Markus Frosch

Markus arbeitet bei NETWAYS als Principal Consultant und unterstützt Kunden bei der Implementierung von Nagios, Icinga und anderen Open Source Systems Management Tools. Neben seiner beruflichen Tätigkeit ist Markus aktiver Mitarbeiter im Debian Projekt.

Docker on OSX

DockerLogoRunning Docker on OSX can be made possible using different methods:

Docker containers require kernel features which are only available in modern Linux kernels. In order to run Docker on OSX for example, one needs a virtual machine with a smallish Linux running in it.

Docker for Mac Beta

Docker for Mac uses xhyve, a lightweight OS X virtualization solution built on top of Hypervisor.framework. This requires you to run OS X 10.10 Yosemite and higher. The VM is provisioned with Alpine Linux running Docker engine.

The Docker API is exposed in /var/run/docker.sock where the docker and docker-compose CLI commands may directly communicate with. This is one of the benefits compared to Docker machine, especially when you do not need to manage your docker VM, or set specific environment variables before running it. Docker for Mac is further installed as native OSX application and only provides symlinks to /usr/local/bin/{docker,docker-compose}.

After the app is installed, I only had to manually add the bash-completion provided by Homebrew.

cd /usr/local/etc/bash_completion.d
ln -s /Applications/Docker.app/Contents/Resources/etc/docker.bash-completion
ln -s /Applications/Docker.app/Contents/Resources/etc/docker-machine.bash-completion
ln -s /Applications/Docker.app/Contents/Resources/etc/docker-compose.bash-completion

I was granted a beta access key for Docker for Mac today 🙂 Even if this is still beta, it already feels much more integrated into my test and development workflow rather than using Docker machine. Awesome job! 🙂

 

Docker Machine

Docker machine will use Virtualbox as VM provider. In order to avoid manual interaction in each terminal I’m opening I’ve added an alias into my bashrc file.

vim $HOME/.bashrc

alias enable_docker=". '/Applications/Docker/Docker Quickstart Terminal.app/Contents/Resources/Scripts/start.sh'"

This script doesn’t do much except for starting the VM using the Virtualbox cli tools and then source the exported variables into your current shell environment. That way the docker client will be able to communicate with the docker daemon running inside the VM.

Parallels instead of Virtualbox

While Virtualbox works fine there are significant performance improvements when using Parallels on OSX. Furthermore it is reasonable to only use one application firing virtual machines (the Icinga Vagrant boxes also provide support for Parallels as Vagrant provider).

I was therefore looking for a native Parallels driver for Docker. Following this issue shed some light on the history of Docker drivers and their support as plugins. Parallels doesn’t seem to be officially supported by Docker themselves according to their documentation. Though there is an official driver plugin from Parallels themselves which works for Pro and Business subscriber editions only. The main reason seems to be the limited cli features in the Standard edition.

Requirements for Parallels

The main requirement is at least Docker 1.9.1 providing the Docker toolbox 0.5.1+.

Installation

I’m using Homebrew, the manual installation parts are described in the documentation. Brew tries to pull docker-machine as well – if you’re using the version from docker.com you can safely ignore the linking error.

brew install docker-machine-parallels

Create a docker machine

docker_machine_parallels_runUse the driver “parallels” and add the name “docker-parallels”. This will create a new Parallels VM with 20GB HDD and 1GB RAM by default. In case you want to disable sharing the /User mounts, add –parallels-no-share.

docker-machine create --driver=parallels docker-parallels

Add the environment variables to your shell and run docker pulling the latest Fedora container.

eval $(docker-machine env docker-parallels)

docker run -ti fedora:latest bash

Automate it

I’ve partially modified the Docker toolbox script in order to support Parallels.

wget https://raw.githubusercontent.com/dnsmichi/docker-tools/master/toolbox/scripts/osx/start.sh -O /usr/local/bin/enable_docker
chmod +x /usr/local/bin/enable_docker
enable_docker

 

Conclusion

While the Docker Machine integration allows room for improvement the Parallels driver works like a charm. Though I have to admit – while looking into the Parallels integration, Docker announced Docker for Mac and I was eagerly waiting for it.

Both methods are working, but the Docker for Mac application integrated natively into OSX is pretty slick. I like it a lot!

If you are looking for more Docker and its many possibilities – follow our blog closely and visit the Docker training sessions 🙂

Michael Friedrich

Autor: Michael Friedrich

Michael ist Icinga-Core-Developer und im Rahmen des Icinga-Projekts schon viele Jahre mit NETWAYS in Kontakt. Im Dezember 2012 hat er das schöne Wien verlassen und ist nun bei uns in den Bereichen Development und Consulting im Einsatz. Durch seine unglaubliche Aktivität im Monitoring-Portal und auf diversen Mailinglisten ist Michael in den vergangenen Jahren für ca. 20% des österreichischen Webtraffics verantwortlich.

Getting started Opennebula API

In wenigen Tagen starten die OpenNebula Techdays welche von Netways gesponsort werden. Da auf diesen einige interessante Dinge gezeigt werden gibt es hier jetzt eine kleine Einführung in die API.

Wenn man die API von OpenNebula benutzen möchte, gibt es zwei Möglichkeiten. Einmal “RPC XML” und zweitens mit einem Ruby Binding. In meinem Beispiel werde ich mich auf das Ruby Binding beziehen.

Um mit der API rumspielen zu können benötigen wir erstmal eine passende OpenNebula Umgebung. Hierfür können wir uns ganz einfach eine vorinstallierte VM als VirtualBox image herunterladen.

Um nun auch auf die API zugreifen zu können, muss man noch eine Portweiterleitung für den Port “26330” einrichten (Port 9869 ist optional, sollte man auch auf das Web-interface zugreifen wollen). Die Weiterleitung kann unter Setting > Network > Advanced > Port Forwarding eingerichtet werden.

Jetzt kann man anfangen sich gegen die API zu connecten. Als erstes fügt man die benötigten Ruby Gems hinzu. Dies wird mit

require 'opennebula'
include OpenNebula

gemacht.

Danach erstellt man Variablen für die login credentials und den Endpoint. Ich benutze dafür die default Username und Passwort Kombination.

CREDENTIALS = "oneadmin:opennebula"
ENDPOINT    = "http://<DeineVBoxIP>:26330/RPC2"

 

Nachdem dies erledigt ist, kann man eine Verbindung zur API festlegen. Hierfür legt man wieder eine Variable fest. (Bitte beachtet, das die credentials und endpoint variablen genauso heißen, wie oben festgelegt!)

client = Client.new(CREDENTIALS, ENDPOINT)

 

Als nächstes initialisiert man den Virtual Maschine Pool. Dafür wird die Variable vm_pool angelegt.

vm_pool = VirtualMaschinePool.new(client, -1)

 

Um mögliche Fehler abzufangen kann man eine kurze Fehlerabfrage einrichten. Diese gibt uns, im Falle eines Fehlers, gleich den richtigen Fehler Code zurück.

rc = vm_pool.info
if OpenNebula.is_error?(rc)
     puts rc.message
     exit -1
end

 

Damit jetzt jede Virtuelle Maschine gestoppt wird, richtet man eine kleine Schleife ein die uns pro VM, die sich im vm_pool befindet, eine Funktion ausführt.

vm_pool.each do |vm|
     rc = vm.shutdown
end

 

Mit der oben eingerichteten Fehlerabfrage kann man sich hier auch gleich noch den aktuellen Status bzw eine Success oder Fehlermeldung ausgeben lassen. Dafür fügt man ein paar Zeilen zu seiner Schleife hinzu.

vm_pool.each do |vm|
     rc = vm.shutdown
     if OpenNebula.is_error?(rc)
          puts "Virtual Machine #{vm.id}: #{rc.message}"
     else
          puts "Virtual Machine #{vm.id}: Shutting down"
     end
end

 

Das ganze noch mit einem sauberen

exit 0

abschließen und das erste Script ist fertig!

 

Um das Endprodukt testen zu können, muss man noch eine VM in OpenNebula erstellen. Hierfür kann man ein schon vorgefertigte Template nutzen.

OpenNebula API

Dieses einfach instantiieren und warten bis die VM hochgefahren ist. (Meist ca 10 Sekunden).

Wenn man jetzt das Ruby Script ausführt sollten man folgende Ausgabe erhalten:

Virtual Machine 1: Shutting down

 

Wie man an diesem Beispiel sehen kann, ist es sehr einfach eigene Scripte für Opennebula zu schreiben. Noch mehr spannende Dinge gibt es auf den diesjährigen TechDays!

Kay Probst

Autor: Kay Probst

Nachdem ihm sein Praktikum bei uns gefallen hat, kam Kay im September 2015 zu NETWAYS, um seine Ausbildung zum Fachinformatiker für Systemintegration zu beginnen. Er kann es schon jetzt kaum abwarten, bald an eigenen Projekten arbeiten zu dürfen. Auch privat beschäftigt er sich mit dem Computer und versetzt sich bei diversen Computerspielen gerne in andere Charaktere hinein.