NETWAYS Web Services: GitLab CE Hosting

This entry is part of 5 in the series NETWAYS Web Services

GitLab CE HostingGitLab CE (Community Edition) ist die frei verfügbare Variante von GitLab, welche alle wichtigen Features von GitLab in einer Open Source Version vereint. GitLab bietet eine webbasierte Oberfläche für Softwareprojekte auf Basis der Versionsverwaltung git. Dazu verfügt GitLab über diverse Management und Bug-Tracking-Funktionalitäten, sowie mit GitLab CI ein System zur kontinuierlichen Integration.

NETWAYS bietet das Hosting von GitLab CE in unserer NETWAYS Web Services an. Wir übernehmen hier nicht nur die Installation und Konfiguration, sondern auch den kompletten Betrieb inkl. regelmäßiger Updates auf die aktuellste Version. Unser Angebot wird verteilt über zwei Rechenzentren in Nürnberg gehostet und betrieben. Somit stellen wir einen sicheren und zuverlässigen Service an einem (sehr schönen) Standort in Deutschland zur Verfügung.

GitLab CE

Alle GitLab CE Instanzen laufen isoliert in einem eigenen Container und alle nötigen Ressourcen sind exklusiv für Ihr Projekt reserviert. Und bei uns sind die GitLab Runner schon mit dabei!

Und wie gewohnt bei NWS – Sie können GitLab CE bei uns 30 Tage kostenfrei testen. Jetzt schnell anmelden!

 

Martin Krodel

Autor: Martin Krodel

Der studierte Volljurist leitet bei NETWAYS die Sales Abteilung und berät unsere Kunden bei ihren Monitoring- und Hosting-Projekten. Privat reist er gerne durch die Weltgeschichte und widmet sich seinem ständig wachsenden Fuhrpark an Apple Hardware.

AB HEUTE LIVE: NWS – NETWAYS Web Services

Im kleinen Kreis haben wir unsere neue Plattform bereits auf der OSMC gezeigt, ab heute sind wir aber für alle am Start und dürfen mit großen Stolz verkünden: NWS ist live!

Die NETWAYS Web Services (NWS) sind ein SaaS Angebot, welches komplett auf die Bereitstellung von Open Source Anwendungen setzt.

Die Anmeldung und der Start der ersten Anwendung ist in wenigen Minuten erledigt und alle Tools können in den ersten 30 Tagen kostenfrei getestet werden. Mit NWS können Sie sich voll auf Ihr Business konzentrieren – wir übernehmen den kompletten Betrieb der jeweiligen Anwendung.

Hier finden Sie die aktuell verfügbaren Apps:

Icinga 2 Satellite

Ihr persönlicher Icinga 2 Satellite an drei Wunschstandorten: Europa (Nürnberg), USA (Kalifornien) und Asien (Tokyo). Überwachen Sie Ihre Dienste aus Kundensicht und integrieren Sie den Satelliten ganz einfach und sicher in Ihr Icinga 2 Monitoring.

Einsatzzweck: Überwachung von externen Diensten (Webseiten, Shops, SMTP, DNS etc.) und einfache Integration in eine bestehende Icinga 2 Installation über das Icinga 2 Clusterprotokoll.

Icinga 2 Master

Der komplette Icinga 2 Stack als eigenständiges System in drei verschiedenen Größen für jeden Einsatzzweck.

Einsatzzweck: Überwachung von externen Diensten (Webseiten, Shops, SMTP, DNS etc.) als Standalone-System mit Icinga Web 2, Icinga Director und Grafana. Natürlich ist Icinga 2 API voll nutzbar.

 

Rocket.Chat

Rocket.Chat ist die Open Source Lösung für den Chat (intern und extern), Video-Chat und Screensharing, File-Sharing und als Helpdesk Chat-Lösung für jede Unternehmensgröße.

Einsatzzweck: Unternehmensinterne Kommunikation für agile Teams und als Channel für den einfachen Dialog mit Ihren Kunden.

Nextcloud

Nextcloud ist die Filesync und -share-Lösung für Unternehmen.

Einsatzzweck: Sicheres Filesharing in Ihrem Unternehmen und mit Ihren Kunden und Nutzung einer webbasierten Office Lösung, welche die Bearbeitung von Dokumenten im Team ermöglicht.

More to come

Wir bauen NWS kontinuierlich aus und werden in den nächsten Monaten noch viele spannende Open Source Tools aufnehmen.

Hier die Projekte der nächsten Monate:

 

Sie vermissen eine Anwendung? Wir freuen uns über Ihre Kontaktaufnahme.

Webinar

Sie wollen noch mehr zu den NETWAYS Web Services erfahren? Mein Kollege Christian Stein stellt die Plattform in einem Webinar am 15. März um 10:30h vor.

Jetzt schnell kostenlos anmelden!

Was steckt dahinter?

Wir haben die komplette Umgebung natürlich nur mit Open Source Mitteln gebaut. Wer mehr wissen will, meldet sich umgehend zur OSDC 2017 in Berlin an und lauscht Sebastians Vortrag.

Vielen Dank an dieser Stelle an unser NWS-Team für den tollen Einsatz und wir freuen uns auf Fragen und Feedback rund um unser neues Angebot.

Martin Krodel

Autor: Martin Krodel

Der studierte Volljurist leitet bei NETWAYS die Sales Abteilung und berät unsere Kunden bei ihren Monitoring- und Hosting-Projekten. Privat reist er gerne durch die Weltgeschichte und widmet sich seinem ständig wachsenden Fuhrpark an Apple Hardware.

Ist schon wieder Webinar Zeit?

netways Auch in der Hitze des Sommers gibt es natürlich weiterhin Bedarf an diversen IT-Dienstleistungen wie Outsourcing, Hosting, Monitoring, Configuration Management und natürlich allem voran Umweltüberwachung.

In den kommenden Monaten wollen wir genau diese Themen in unseren Webinaren ansprechen und – sofern möglich – anhand von Live-Demos veranschaulichen. Die nächsten Termine stehen dabei schon fest:

Titel Zeitraum Registrierung
NETWAYS Cloud: Der Weg zur eigenen VM 15. Juli 2016 – 10:30 Uhr Anmelden
Foreman: Berechtigungen 28. Juli 2016 – 10:30 Uhr Anmelden
Umweltüberwachung im Rechenzentrum 04. August 2016 – 10:30 Uhr Anmelden
SMS Alarmierung einrichten 25. August 2016 – 10:30 Uhr Anmelden
Foreman: Docker Integration 05. Oktober 2016 – 10:30 Uhr Anmelden

Alle unsere Webinare zeichnen wir auf, damit diese auch nachträglich noch einmal angesehen werden können. Hinterlegt werden Sie dann in unserem Webinar-Archiv.

Christian Stein

Autor: Christian Stein

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Monthly Snap June: Icinga2, Training, Foreman, GitLab, Icinga director, OpenNebula

Martin presented in June our new book about Icinga 2 written by our very own Lennart Betz and Thomas Widhalm.

Julia announced the official Foreman training material and Michael recommended the new DEV-Trainings: Git and Jenkins.weekly snap

Tim explained how to use OpenNebula ACLs and Foreman in Part 1 and Part 2 while Florian showed us how to animate vector graphics with CSS.

Julia gave us a nice update of our new training facility – the „Kesselhaus“.

Dirk announced that the Foreman Project will be 7 years at the 21st of July – so safe the date and visit us at the German Foreman birthday event that will take place in our event room „Kesselhaus“.

Enrico shared some tips and tricks about how to work with GitLab web hooks and Thomas Gelf showed us the new and shiny Icinga director 1.10.

Vanessa Muschweck

Autor: Vanessa Muschweck

Vanessa ist unser Head of Finance und somit mit ihrem Team für das Geld, Controlling und Personalverwaltung zuständig. Außerhalb des Büros ist sie sportlich unterwegs und widmet sich neben Tennis hauptsächlich dem professionellem Yoga. Hier macht sie gerade die offizielle Trainer-Ausbildung und kann dann die älter werdende Belegschaft bei NETWAYS ertüchtigen.

GitLab – Webhooks

gitlab-webhooks

Da ich vor kurzem für einen unserer namhaften Kunden ein GitLab Setup aufsetzten durfte und dieser sich nun auch Automatische Checkouts seiner Live Branches auf seinen Produktiv Systemen wünschte, habe ich mich dazu entschlossen euch ein bisschen an der Einrichtung dieser Mechaniken teilhaben zu lassen, natürlich nicht im vollem Umfang des Projektes für unseren Kunden, das eine oder andere habe ich für diesen Artikel verständlicherweise leicht abwandeln müssen, das hier gezeigte funktioniert trotzdem, ich habe es selber ausprobiert.

Dann legen wir mal los…

In einem klassischen Git Setup werden die Hooks direkt im Repository im Unterordner hooks abgelegt, hier mal ein Beispiel wie das aussehen kann…

$ MyAwesomeProject/hooks $ ll
-rwxrwxr-x 1 enzo enzo  452 Jun 28 11:46 applypatch-msg.sample*
-rwxrwxr-x 1 enzo enzo  896 Jun 28 11:46 commit-msg.sample*
-rwxrwxr-x 1 enzo enzo  189 Jun 28 11:46 post-update.sample*
-rwxrwxr-x 1 enzo enzo  398 Jun 28 11:46 pre-applypatch.sample*
-rwxrwxr-x 1 enzo enzo 1642 Jun 28 11:46 pre-commit.sample*
-rwxrwxr-x 1 enzo enzo 1239 Jun 28 11:46 prepare-commit-msg.sample*
-rwxrwxr-x 1 enzo enzo 1352 Jun 28 11:46 pre-push.sample*
-rwxrwxr-x 1 enzo enzo 4898 Jun 28 11:46 pre-rebase.sample*
-rwxrwxr-x 1 enzo enzo 3611 Jun 28 11:46 update.sample*

GitLab geht hier allerdings einen anderen Weg, da dieses das hooks Verzeichnis durch einen Symbolischen Link auf System eigene Hooks umlenkt (wie hier Beispielhaft zu sehen ist)…

gitlab-webhooks-art2

…nun sollte man hier auch besser die Finger heraus lassen, da GitLab dieses Verzeichnis für allerlei anderen Mechaniken benötigt, der Weg über die Webhooks ist meiner Meinung nach aber auch flexibler (allein schon wegen der einfachen Anbindung an Web Dienste wie GitHub, Bitbucket, Heroku, etc.).

Nun direkt zum spaßigen Teil, im GitLab benötigen wir einen neuen User ohne irgendwelche besonderen Rechte incl. SSH Public Key, fangen wir mit dem Key selbst an, da der Checkout User keinen besonderen Rechte benötigt außer einen Pull/Fetch zu tätigen, reicht es uns den Key also entsprechend Unprivilegiert zu preparieren (bei der Passwortabfrage bitte nichts angeben, einfach mit Enter bestätigen)…

$ ssh-keygen -t rsa -b 2048 -O clear -O no-agent-forwarding -O no-port-forwarding -O no-pty -O no-user-rc -O no-x11-forwarding -f gitlab.key
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in gitlab.key.
Your public key has been saved in gitlab.key.pub.
The key fingerprint is:
4b:f3:ae:60:d4:5d:5e:02:75:64:4c:7f:ce:09:ec:8a enzo@ebony
The key's randomart image is:
+--[ RSA 2048]----+
|          ...+=  |
|           ..o.. |
|            oo. o|
|       . . o.o.oo|
|      . S . .. .o|
|     . . +. .    |
|      o .E..     |
|     . . .       |
|        ...      |
+-----------------+
$ ll
insgesamt 8
-rw------- 1 enzo enzo 1675 Jun 28 11:52 gitlab.key
-rw-r--r-- 1 enzo enzo  392 Jun 28 11:52 gitlab.key.pub

…nun benötigen wir lediglich noch einen User im GitLab, das sollte keine große Herausforderung darstellen, bitte stellt auch sicher das ihr den SSH PublicKey in unserem Beispiel gitlab.key.pub dem User, lasst ihn uns hier der Einfachheit halber checkout nennen zuweist, da die Webhooks mit den Berechtigungen des Standard Apache User www-data läuft (das ist zumindest unter Debian/Ubuntu der Fall, unter Redhat Systemen heißt dieser wwwrun) solltet ihr dem Key als Identifier so etwas wie www-data to gitlab oder ähnliches benennen, damit ihr später ganz einfach den Überblick behalten könnt…

gitlab-webhooks-art4
gitlab-webhooks-art5

…nun müssen wir unserem User checkout lediglich noch in unser Projekt aufnehmen, die Rechte eines Reporter sollten dafür ausreichend sein um Fetch/Pull oder auch Clone zu können, mehr benötigen wir an dieser Stelle nicht…

gitlab-webhooks-art9

…somit sind wir auf schon fast fertig, zumindest was das GitLab Setup selbst betrifft, nun müssen wir lediglich noch die URL unseres Webhook konfigurieren und schon können wir uns dem Hook selber widmen…

gitlab-webhooks-art7

gitlab-webhooks-art8…bitte beachtet auch, das es beim Entwickeln eines Webhooks sehr hilfreich sein kann wenn ihr über den Button [Test Hook] den Push Event einfach mal Manuell triggert, ansonsten würde euer Webhook erst aufgerufen werden wenn ihr wirklich in das Repository Pusht (das geht natürlich auch, legt euch hierzu einfach ein neues Repository zum spielen an).

So nun geht es an den Server der unseren Webhook ausführen soll, ihr benötigt lediglich einen simplen Apache/NginX vHost mit Standard Rechten, man kann selbstverständlich auch ein komplizierteres Deployment bauen aber darum geht es in diesem Artikel nicht (ich nutzte hier den Apache2 mit PHP5, da dieser bereits auf dem Kunden System vorhanden wahr und zusätzliche Scriptsprachen installieren ist meist schlechte Praxis sowie auch unnötiger Aufwand).

Ich habe mich hier für den Standard Pfad des Apache Setups entschieden da der Standard vHost bereits auf diesen zeigt und dieser auch nur aus dem internen Netz bedienbar ist, somit ist sichergestellt das Niemand von außerhalb Unfug treiben kann.

Dort habe ich im DocumentRoot des Apache ein Verzeichnis api erstellt, der volle Pfad lautet hier /var/www/html/api, dort habe ich mein Webhook mit Namen on-push.php abgelegt, dieser hat nun folgenden Inhalt…

<?php
    // global settings
    define( "DEBUG", true );
    define( "OK", "Status: 200" ); 
    define( "ERR", "Status: 503" );
    define( "LOGFILE", getcwd()."/on-push.log" );
 
    // project settings
    define( "PROJECTROOT", "/var/www/project1/htdocs" );
    define( "BRANCH", "staging" );
    define( "COMMAND", "/bin/bash -c \"git fetch --all && git reset --hard origin/".BRANCH."\"" );
 
    // user which can do/trigger some updates on our staging branch
    $USERS = array( 'operator', 'developer1', 'developer2' );
 
    // =================================== MAIN =============================================
 
    try { 
        if( DEBUG ) {
            if( file_exists( LOGFILE ) ) unlink( LOGFILE );
            msg( "====== SERVER VARIABLES BEGIN ======" );
            msg( print_r( $_SERVER, true ) ); 
            msg( "====== SERVER VARIABLES END ======" );
        } 
 
        if( $_SERVER['REQUEST_METHOD'] === 'POST' ) {
            $obj = getRequestBody();
            msg( "====== JSON OBJ BEGIN ======" );
            msg( print_r( $obj, true ) );
            msg( "====== JSON OBJ END ======" );
 
            if( $obj->object_kind == 'push' ) {
                if( $obj->ref == 'refs/heads/'.BRANCH ) {
                    $allowed = false;
                    foreach( $USERS as $user ) {
                        msg( "permission test ( ".$obj->user_name ." == ". $user." ) ..." );
                        if( preg_match( "/$user/i", $obj->user_name ) ) {
                            msg( $user . " allowed to do updates on refs/heads/".BRANCH." branch" );
                            $allowed = true;
                            break;
                        }
                    } 
 
                    if( $allowed ) {
                        if( $obj->before != "0000000000000000000000000000000000000000" ) {
                            msg( "changing directory to ".PROJECTROOT );
                            chdir( PROJECTROOT );
 
                            msg( "executing: ". COMMAND );
                            $fh = popen( COMMAND." 2>&1", "r" );
                            $result = fread( $fh );
                            while( !feof( $fh ) ) {
                                msg( rtrim(fgets( $fh, 4096 )) );
                            } 
                            pclose( $fh );
                        } else {
                            msg( "it's a empty repository, we'll do nothing at this point" );
                        } 
                    } else {
                        msg( "permission denied for ". $obj->user_name );
                    }
                } else {
                    msg( "everybody can push to ". $obj->ref.", but we'll do nothing, please check your project settings" );
                }
            } else {
                msg( "[ ". $obj->object_kind ." ] event handler not yet implemented" );
            }
        } else {
            msg( strtoupper($_SERVER['REQUEST_METHOD'])." from [ ".$_SERVER['REMOTE_ADDR'] ." ] is not allowed, please check your server settings" );
            return_status( ERR );
        }
    } catch( Exception $e ) {
        msg( "======= EXCEPTION BEGIN ========" );
        msg( $e->getMessage() );
        msg( "======= EXCEPTION END ==========" );
        return_status( ERR );
    }
 
    return_status( OK ); 
 
    // ================================ FUNCTIONS ===========================================
    function return_status( $status = ERR ) { header( $status ); }
    function getRequestBody() { return json_decode( file_get_contents('php://input') ); }
    function msg( $message ) { if( $message != null ) file_put_contents( LOGFILE, $message."\n", FILE_APPEND ); } 
?>

..damit das nun funktionieren kann, müssen wir nun noch das Projekt Klonen und die SSH Settings anlegen, fangen wir daher direkt mit den SSH Settings an…

# (beginne mit Root Login)
su - -s /bin/bash www-data
mkdir -p .ssh && chmod 0600 .ssh
exit
cp gitlab.key /var/www/.ssh/ && chown www-data. /var/www/.ssh/gitlab.key && chmod 0400 /var/www/.ssh/gitlab.key
su - -s /bin/bash www-data
vi .ssh/config

…die .ssh/config sieht dabei wie folgt aus…

Host gitlab.example.org
    UserKnownHostsFile /dev/null
    StrictHostKeyChecking no
    IdentityFile ~/.ssh/gitlab.key
    User git
    LogLevel VERBOSE

…speichert nun das ganze und Klont eurer Projekt nach /var/www/project1/htdocs

# (beginne mit Root Login)
su - -s /bin/bash www-data
cd /var/www/project1
git clone git@gitlab.example.org:test/number1.git htdocs

…wenn ihr nun Lokal mit eurer Arbeitskopie arbeitet und an dem Punkt seit das ihr alles fertig zuhaben scheint und dann einen Push in euren staging Branch macht, wird GitLab jedesmal den Webhook on-push.php Aufrufen und auf dem Projekt/Web -Server einen Fetch/Pull ausführen lassen, um das Projekt auf den selben Stand wie eure Arbeitskopie zu bringen.

Zugegeben der PHP Handler oben ist keinesfalls perfekt, ich bin auch kein guter PHP Programmierer, genau genommen eigentlich gar keiner ;). Der Hook für das Kunden Projekt umfasst zudem noch mehr Fähigkeiten und würde mit seine zu diesem Zeitpunt ca. 800 Zeilen diesen Artikel in jedem Fall sprengen, aber ich denke das der gezeigte Webhook oben bereits eine gute Ausgangsbasis darstellt, sodass ich euch hoffentlich dazu Animieren konnte, das ganze doch einmal selber nachzubauen.

Zum zweck des Debugging, loggt dieser zur Kontrolle nach /var/www/html/api/on-push.log , hier lohnt also ein Blick.

Noch ein kleiner Hinweis meinerseits, der eine oder andere von euch wird schnell feststellen, das GitLab selber im Admin Panel auch einen Menü Eintrag mit der Bezeichnung [Deploy Keys] bereitstellt, womit sich das oben gezeigte auch umsetzten lässt, aufgrund einiger bedenken bzgl. Sicherheit dieses allerdings nicht immer gewünscht ist, da alle Keys die dort hinterlegt werden automatisch, für allen Projekte (auch für zukünftige) direkt verwendet werden können.

Nützliche Links:

Enrico Labedzki

Autor: Enrico Labedzki

Enrico ist beruflich ganz schön rumgekommen – IT hat ihn aber immer beschäftigt. Nach einem Ausflug in die Selbstständigkeit im Bereich Webentwicklung und Network Solutions, wurde es dann Zeit Nägel mit Köpfen zu machen und endlich den Weg als Softwareentwickler und Systemintegrator einzuschlagen. In seiner Freizeit widmet sich der passionierte Bastler der Elektrotechnik und Animatronik. Bei Netways bereichert er mit seinem vielseitigen Know-How das Managed Service-Team.

DEV-Trainings: Git und Jenkins

training_jenkinstraining_gitWir starten 2016 voll durch mit einem erweiterten Schulungsportfolio – neben Foreman und Ceph fokussieren wir uns im Development auf Git und Jenkins.

Die ersten Schulungen mit frisch erstellten Unterlagen fanden letzte Woche In-House bei einem unserer Kunden statt, sozusagen die “Feuertaufe” für die kommenden Schulungen.

git_introduction_basics_03_three_statesNach einer kurzen Einführung in die Geschichte von VCS und der Entstehungsgeschichte von Git haben wir anhand von praktischen Beispielen erste Schritte mit Git gemacht – wie initialisiere ich ein Repository, was bedeutet “modified”, “staged”, “committed”, was passiert bei “git add” und “git commit”? Bevor wir uns in die Tiefe mit Remote Repositories gestürzt haben, kam auch noch das Arbeiten mit Branches und unterschiedlicher Commit-Historie und – natürlich absichtlich provozierten – Fehlern beim Merge und Rebase dran.

Um das Gelernte auch in der Praxis weiterhin verwenden zu können, wurde die Arbeit mit einem lokalen Git-Server und fetch, pull, push und Branches vertieft. Das ganze kombiniert mit den unterschiedlichen Workflows (Feature-Branch, Gitflow, Forking) und praktischen Beispielen und nachgehender Analyse.

Die Brücke zur Jenkins-Schulung haben wir mit einem Git-Hook geschlagen, der für einen Git-Commit einen Jenkins-Job ansteuert.

jenkins_job_chuck_norrisNach der Installation des Jenkins-Installationspakets haben wir uns sogleich in die Konfiguration gestürzt – und natürlich in den ersten gemeinsamen Job. Ein Python-Script will gebaut werden, und später dann auch paketiert. In erster Linie haben wir uns Code Coverage und Qualität für CI und Test-Frameworks angesehen. Mit verschiedenen Build-Schritten und der Hilfe des Trainers gings dann auch gleich weiter mit der Einbindung an einen Jenkins-Agenten, der dediziert die Jenkins-Jobs ausführen sollte. Hierbei gibts einige Fallstricke zu beachten, gerade was SSH-Keys und shared Workspaces betrifft. Die Köpfe haben geraucht – aber spätestens dann als der frisch installierte Git-Hook den Jenkins-Paket-Bau angestossen hat, gabs für jeden das persönliche Erfolgserlebnis.

git_integrations_jenkins_git_hook
Neben den praktischen Beispielen haben wir uns auch Zeit genommen, gezielt Fragen zur eigenen Umgebung zu diskutieren, oder auch aus dem Nähkästchen zu plaudern. Git und Jenkins ist Teil unserer täglichen Arbeit an Icinga & Co und da gibts schon ein bissl Best Practice zu erzählen 😉

Für kurz entschlossene wissbegierige Anwender und jene die ihr Wissen auffrischen wollen – es gibt noch Plätze in unserer Git-Schulung am 28.6.2016 und Jenkins-Schulung am 30.8.2016 🙂

Und für all jene, die das Git-Fachwissen schon in sich aufgesaugt haben – wir hosten auch die eigene GitLab CE Instanz in unserer Cloud. Lust auf mehr? Kommt einfach auf uns zu!

PS: Trainings machen mir Spass – darum werd ich auch den diesjährigen Git-Workshop auf der OSMC halten 🙂

 

Michael Friedrich

Autor: Michael Friedrich

Michael ist seit vielen Jahren Icinga Developer und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht im Monitoring-Portal helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst das schöne Nürnberg. Oder - at an Icinga Camp near you 😉