Microsoft and GitHub – merge conflict?

For some time it has become clear that Microsoft is going to take over GitHub. As far as official sources can be trusted, GitHub will stay independent although a new CEO (Nat Friedman) will be introduced after the Microsoft takeover.

This question over GitHub’s future independence has raised a lot of skepticism within the developer community and many are considering moving their projects away from GitHub to a different location.
One alternative in this case could be GitLab. GitLab does not only have an online platform but it can as well be installed on your own hardware. Furthermore, it is an extremely solid piece of Open Source software you can fully rely on. This is also shown by the makers of GitLab themselves as they release updates each month – rolling out bug fixes, security updates and many recommendations regarding the use and configuration of your instance.
For those who would like to have their own GitLab instance, NETWAYS offers two options:
First one is available on our NETWAYS Web Services platform where we offer user-managed, hosted GitLab instances as Community or Enterprise Edition. The user does not need to take care of anything regarding installation or maintenance of his GitLab, but can directly go into production in no time with only a few steps needed. You as a customer are also free to decide for how long you would like to run your instances as any app is monthly callable. Furthermore, we regularly update these container based apps and monitor their health  for you. As a customer, you can register on NWS and try all the apps we offer 30 days for free.
The second product we offer is done by NETWAYS Managed Services which is exactly what it is called: With managed hosting you can get a virtual machine in our cloud or rented hardware running a full GitLab, either as Community or Enterprise Edition. You can choose the underlying ressources and we will do the rest for you, like installation with individual parameters and health monitoring. With managed hosting, our customers also have the choice to go full 24/7 support with “emergency” calls.

Nicole Lang
Nicole Lang
Account Manager

Ihr Interesse für die IT kam bei Nicole in ihrer Zeit als Übersetzerin mit dem Fachgebiet Technik. Seit 2010 sammelt sie bereits Erfahrungen im Support und der Administration von Storagesystemen beim ZDF in Mainz. Ab September 2016 startete Sie Ihre Ausbildung zur Fachinformatikerin für Systemintegration bei NETWAYS, wo sie vor allem das Arbeiten mit Linux und freier Software reizt. In ihrer Freizeit überschüttet Sie Ihren Hund mit Liebe, kocht viel Gesundes, werkelt im Garten, liest...

Github Topics – Ein kleiner Blick in die Zukunft

Wir sind seit einiger Zeit damit beschäftigt, Icinga Exchange in neuem Licht erstrahlen zu lassen. Neben einem neuen Design wird es allerdings auch einige andere Änderungen und Neuerungen geben.
Eine dieser Neuerungen wird eine stärkere Github Integration sein. Wir werden unter anderem die bisher notwendige yaml Datei ablösen, indem wir Details über von Github synchronisierte Projekte über die API von Github abrufen. Dabei ist uns eine neue Funktion von Github ins Auge gefallen: Topics.
Diese ist seit Anfang des Jahres verfügbar und erlaubt es einem Repository bestimmte Begriffe zuzuordnen, ganz ähnlich den auf Icinga Exchange bekannten Tags. Mit der üblichen URL um Details zu einem Repository abzurufen wird man jedoch nicht fündig:<owner>/<repository>

Aktuell fand diese Funktion noch keinen Einzug in die offizielle API. Stattdessen muss man explizit angeben, eine bestimmte preview Version der API benutzen zu wollen, damit zugeordnete Topics in den Details ebenfalls erscheinen.
Dies erreicht man bei Github mit bestimmten media types im Accept header:


(Alle preview Versionen gibt es hier)
Um also über die API auf die Topics zuzugreifen, wird folgender media type benötigt:


In der Antwort der API erscheint daraufhin ein neuer Eintrag:

  "topics": [

Weil diese Funktion aber noch nicht Bestandteil der offiziellen API ist, werden wir vermutlich vorerst davon absehen diese in Icinga Exchange zu benutzen. Wir hoffen jedoch, dass sie bald Bestandteil der offiziellen wird oder absehbar ist, dass sie es sicher werden wird.
Ach, bevor Ihr fragt: Nein, wir haben noch keinen Release Zeitpunkt für die neue Version von Icinga Exchange. Aber vermutlich noch dieses Jahr. 😛

Johannes Meyer
Johannes Meyer

Johannes ist seit 2011 bei uns und hilft bei der Entwicklung zukünftiger Knüller (Icinga2, Icinga Web 2, ...) aus dem Hause NETWAYS.

Documentation matters or why OSMC made me write NSClient++ API docs

Last year I learned about the new HTTP API in NSClient++. I stumbled over it in a blog post with some details, but there were no docs. Instant thought “a software without docs is crap, throw it away”. I am a developer myself, and I know how hard it is to put your code and features into the right shape. And I am all for Open Source, so why not read the source code and reverse engineer the features.
I’ve found out many things, and decided to write a blog post about it. I just had no time, and the old NSClient++ documentation was written in ASCIIDoc. A format which isn’t easy to write, and requires a whole lot knowledge to format and generate readable previews. I skipped it, but I eagerly wanted to have API documentation. Not only for me when I want to look into NSClient++ API queries, but also for anyone out there.

Join the conversation

I met Michael at OSMC 2016 again, and we somehow managed to talk about NSClient++. “The development environment is tricky to setup”, I told him, “and I struggle with writing documentation patches in asciidoc.”. We especially talked about the API parts of the documentation I wanted to contribute.
So we made a deal: If I would write documentation for the NSClient++ API, Michael will go for Markdown as documentation format and convert everything else. Michael was way too fast in December and greeted me with shiny Markdown. I wasn’t ready for it, and time goes by. Lately I have been reviewing Jean’s check_nscp_api plugin to finally release it in Icinga 2 v2.7. And so I looked into NSClient++, its API and my longstanding TODO again.
Documentation provides facts and ideally you can walk from top to down, and an API provides so many things to tell. The NSClient API has a bonus: It renders a web interface in your browser too. While thinking about the documentation structure, I could play around with the queries, online configuration and what not.

Write and test documentation

Markdown is a markup language. You’ll not only put static text into it, but also use certain patterns and structures to render it in a beautiful representation, just like HTML.
A common approach to render Markdown is seen on GitHub who enriched the original specification and created “GitHub flavoured Markdown“. You can easily edit the documentation online on GitHub and render a preview. Once work is done, you send a pull request in couple of clicks. Very easy 🙂

If you are planning to write a massive amount of documentation with many images added, a local checkout of the git repository and your favourite editor comes in handy. vim handles markdown syntax highlighting already. If you have seen GitHub’s Atom editor, you probably know it has many plugins and features. One of them is to highlight Markdown syntax and to provide a live preview. If you want to do it in your browser, switch to

NSClient++ uses MKDocs for rendering and building docs. You can start an mkdocs instance locally and test your edits “live”, as you would see them on

Since you always need someone who guides you, the first PR I sent over to Michael was exactly to highlight MKDocs inside the 🙂

Already have a solution in mind?

Open the documentation and enhance it. Fix a typo even and help the developers and community members. Don’t move into blaming the developer, that just makes you feel bad. Don’t just wait until someone else will fix it. Not many people love to write documentation.
I kept writing blog posts and wiki articles as my own documentation for things I found over the years. I once stopped with GitHub and Markdown and decided to push my knowledge upstream. Every time I visit the Grafana module for Icinga Web 2 for example, I can use the docs to copy paste configs. Guess what my first contribution to this community project was? 🙂
I gave my word to Michael, and you’ll see how easy it is to write docs for NSClient++ – PR #4.


Lessions learned

Documentation is different from writing a book or an article in a magazine. Take the Icinga 2 book as an example: It provides many hints, hides unnecessary facts and pushes you into a story about a company and which services to monitor. This is more focussed on the problem the reader will be solving. That does not mean that pure documentation can’t be easy to read, but still it requires more attention and your desire to try things.
You can extend the knowledge from reading documentation by moving into training sessions or workshops. It’s a good feeling when you discuss the things you’ve just learned at, or having a G&T in the evening. A special flow – which I cannot really describe – happens during OSMC workshops and hackathons or at an Icinga Camp near you. I always have the feeling that I’ve solved so many questions in so little time. That’s more than I could ever write into a documentation chapter or into a thread over at 🙂
Still, I love to write and enhance documentation. This is the initial kickoff for any howto, training or workshop which might follow. We’re making our life so much easier when things are not asked five times, but they’re visible and available as URL somewhere. I’d like to encourage everyone out there to feel the same about documentation.


Ever thought about “ah, that is missing” and then forgot to tell anyone? Practice a little and get used to GitHub documentation edits, Atom, vim, MkDocs. Adopt that into your workflow and give something back to your open source project heroes. Marianne is doing great with Icinga 2 documentation already! Once your patch gets merged, that’s pure energy, I tell you 🙂
I’m looking forward to meet Michael at OSMC 2017 again and we will have a G&T together for sure. Oh, Michael, btw – you still need to join your Call for Papers. Could it be something about the API with a link to the newly written docs in the slides please? 🙂
PS: Ask my colleagues here at NETWAYS about customer documentation I keep writing. It simply avoids to explain every little detail in mails, tickets and whatnot. Reduce the stress level and make everyone happy with awesome documentation. That’s my spirit 🙂

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler 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 und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

Monthly Snap April > NETWAYS Web Services, Braintower, OSBConf, Teamweekend, AKCP, OSDC, GitLab CE, Galera, GitHub, Puppet

In April, Isabel startet with announcing a new Software Update for Braintower and Martin K. continued with a new NETWAYS Web Services tool: Rocket.Chat Hosting.
Then Julia announced the call for papers for the Open Source Backup Conference 2017 in Cologne while Marius wrote about the end of Ubuntu 12.04 LTS.
Later in April, Marius H. gave some practical tips for the Galera Cluster and Dirk wrote about contributing to projects on GitHub.
Then Martin K. presented the next NETWAYS Web Services App, GitLab CE Hosting, and Julia told about the latest OSDC-News.
Furthermore, Catharina reviewed the team event of the commercial departments while Noah told us how to block some Google searches in Google Chrome.
Lennart gave an insight in the monitoring project at htp GmbH and Daniel introduced himself.
Towards the end of April, Isabel told about the latest news concerning the AKCP sensorProbe 2+ and Martin S. explained external monitoring by the Icinga2 satellites at NETWAYS Web Services.
Last but not least, Jean reported on monitoring powershell scripts with Icinga 2, while Lennart went on with part 2 of automated monitoring with Puppet.

Neuigkeiten rund um die AKCP sensorProbe 2+

AKCP-SP2plusDer Online-Store hat schon immer Umweltmonitore von AKCP im Angebot. Die Qualität der Ware ist unbestritten und unsere Kunden und wir profitieren von der gut durchdachten Hardware. Bei unseren Kunden ist die Ware sehr beliebt und gehört zu unseren Topsellern.
Im vergangenen Jahr wurde nun die AKCP sensorProbe2 komplett überarbeitet und nennt sich nun sensorProbe2+. Alle bekannten Features blieben erhalten und auch die Kompatibilität mit allen Sensoren der sensorProbe-Reihe bleibt gegeben.
Ab der neuen Baureihe ist es endlich auch möglich, ein GSM-Modem zu integrieren, wobei dies bei der Erstbestellung der AKCP sensorProbe2+ zwingend mitbestellt werden muss. Außerdem sind bei allen Geräten der AKCP sensorProbe2+– Reihe die VPN Funktion und ein Upgrade auf SNMPv3 optional bestellbar. Neuheit: Bei der E-Mail-Alarmierung wird nun auf TLS-Verschlüsselung gesetzt, die es bislang nur bei den securityProbes gab.
Bei der AKCP SP2+ können neben den bekannten RJ45-Sensoren, von denen vier angeschlossen werden können, auch bis zu 20 potentialfreie Kontakte genutzt werden. Für den Anschluss der potentialfreien Kontakte ist sowohl der Kauf des Sensors: Inputs für potentialfreie Kontakte (5 potentialfreie Kontakte) und eine Lizenz, die jeweils für 5 potentialfreie Kontakte gilt, erforderlich.
Technische Daten AKCP sensorProbe2+

  • Anschlüsse: 4 RJ45 Ports, für sämtliche AKCP-Sensoren der sensorProbe-Reihe, bis zu 20 potentialfreie Kontakte (über speziellen Sensor + Lizenz)
  • Maße/Gewicht: (ca. BxHxT in cm) 11,5 x 6,35 x 3,2/ 0,3 kg
  • GSM-Modem: optional, inklusive externer Antenne
  • sensorProbe2+ Expansion: mit Expansion Unit für bis zu 100 Sensoren
  • Stromversorgung: 12 VDC, 1 Amp; inkl Modem: 12 VDC, 2 Amp
  • Arbeitsumgebung: Temperatur: -35 bis +80 C / Luftfeuchte: 20 bis 80 % (ohne Kondensation)

Intelligente Erweiterung: AKCP sensorProbe2+ Expansion
4 Sensoren reichen Ihnen nicht? Prima, dann können Sie die AKCP sensorProbe2+ Expansion nutzen. Einer der 4 RJ45 Ports kann dort dazu genutzt werden, die von der AKCP securityProbe Reihe bekannten Expansion Units anzuschließen. Hier kann auf die Erweiterung um 8 Ports und/oder die Erweiterung um 16 potentialfreie Kontakte zurückgegriffen werden. Im Daisy Chain Verfahren können somit bis zu 100 Sensoren angeschlossen werden. Ausnahme: Die o.g. VPN Funktion wurde zusätzlich eThermal Map Sensoringekauft. Damit verringert sich die Anzahl der Sensoren auf 50.
Thermal Mapping: Noch genauere Überwachung Ihrer Serverschränke möglich
Die genauere Auswertung und Erfassung thermischer Bedingungen eines Serverracks wird nun durch den neuen Thermal Map Sensor ermöglicht. Dabei wird der Sensor wie im Schaubild rechts zu sehen, an unterschiedlichen Stellen des Racks positioniert. So können “Hot-Spots” leicht lokalisiert werden, was ein gezieltes Eingreifen schneller ermöglicht. Hier kann durch effizientes Kühlen an den besonders warmen und kühlen Stellen, bares Geld gespart werden. Der Thermal Map Sensor kann separat gekauft werden, es gibt aber auch ein Bundle in Form der AKCP sensorProbe2+ inkl. Thermal Map Sensor (Temperatur + Luftfeuchte).
Neues Icinga 2 check-Plugin für AKCP sensorProbe 2+ verfügbar!
Ab sofort steht das neue Plugin für die AKCP sensorProbe 2+ im Github bereit. Unser Entwicklungsteam hat sich das bereits bestehende, seit Jahren funktionierende check_AKCP -Plugin zur Vorlage genommen und ein neues Plugin kreiert. Hier war es notwendig die erweiterte Funktionalität des Gerätes zu berücksichtigen. Hier mal eine Ansicht dazu:

Webinar AKCP SP2+: Die Neuheiten und Icinga 2 Integration
Wer sich die Funktionalität und die Integration in Icinga 2 einmal anschauen möchte, sei herzlich zu unserem Webinar zum AKCP sensorProbe 2+ am 27.04.2017 um 10:30 Uhr eingeladen. Im Anschluss an die Präsentation und die Livedemo gibt es auch die Möglichkeit per Chat Fragen zu stellen. Wir freuen uns auf Sie!

Isabel Salampasidis
Isabel Salampasidis
Account Manager

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...

Contributing to projects on GitHub

GitHub Logo
Today I want to share my workflow for contributing to projects hosted on GitHub because I believe it works very well for me and I regularly contribute to various projects. Of course most of this also applies to other hosted Git platforms like GitLab. It will not involve any Git magic as there are other posts to do that. So let’s use adding a check command to Icinga 2 as my example.
The obvious first step is finding the Git repository for the project and reading contribution guidelines because there are some projects which aren’t hosted on GitHub and some have additional requirements like submitting an issue in addition to a pull request. You should always familiarize yourself with and stick to those policies if you want your pull request to be accepted. For Icinga 2 there currently aren’t any additional project-specific guidelines.
Your next step is to create a fork on GitHub and clone the repository. So in the GitHub web interface click on “Fork” and select your own account (or company account as long as you are allowed to push). Once you’ve forked the repository you can check out a local copy using the following command:

git clone

Afterwards you should add another “remote” for the original Git repository in order to be able to update your own repository with changes from the upstream project:

cd icinga2/
git remote add upstream

After these initial steps you can create a Git branch for your feature or bug fix. Using the “master” branch for pull requests is strongly discouraged because things tend to get complicated once you have more than one pull request. Another recommendation is to use branch names that match the upstream repository’s style. This however is not a hard requirement:

git checkout -b feature/expand-check-foo

This also automatically switches to the newly-created branch which means you can now start to edit files for your pull request. Once you’re done you can add them to the Git index and create a commit. Typically upstream projects have guidelines for this, so do not forget to include documentation, make only one commit out of your work (perhaps by squashing) and so on.

vi itl/plugins-contrib.d/network-components.conf
vi doc/
git add itl/plugins-contrib.d/network-components.conf doc/
git commit -m "ITL: expanded check foo"

Afterwards push your commit to your forked repository and then create your pull request using the GitHub webinterface:

git push -u origin feature/expand-check-foo

When creating the pull request make sure to provide a detailed description of your changes and the reason why you feel that your pull request should be merged. Keep the setting checked to allow edits from maintainers. Depending on the project make sure to reference any related issues, fill in their pull request template or do whatever else they require for pull requests.
GitHub pull request
Typically once a pull request is created automated tests will be run and a review process by the project team will start, so it’s possible that you’ll be asked to make changes before your pull request is accepted. If this happens simply edit your branch to fix whatever problems were found during the review, amend your commit and force push it to your fork. This will also automatically update your pull request but you might want to provide a comment for the pull request as to what has changed:

vi doc/
git add doc/
git commit --amend -m "ITL: expanded check foo"
git push -f

Another commonly requested change is that you rebase your branch before the pull request is accepted. This usually happens when significant changes were made to the upstream repository while your pull request was waiting to be merged. In order to rebase your branch the following commands should be all you need, however in some cases you may also have to manually resolve conflicts:

git pull --rebase upstream master
git push -f

And of course you will sometimes want to create additional pull requests. For these make sure to start with a new branch based on the upstream repository:

git checkout master
git pull upstream master
git checkout -b fix/check-bar
git push -u origin fix/check-bar

So, this is it, this is my basic workflow for easy contributions on GitHub. I hope it helps you to get involved with your favorite projects and your fixes and features to get upstream. If you prefer to do all step in the command line, you can have a look at GitHub’s command-line wrapper for git hub. If you need more general Git knowledge I recommend the Git book and our training. If you need a GitLab system to play around, have a look at our NWS platform.

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Authentication with OAuth

It’s pretty safe to say, that everyone using the web has already made an account for some website. For the broad masses the most common ones would be social media sites like facebook, youtube and twitter. Then there are also online shopping platforms like e-bay and amazon, and more techie orientated pages like stack overflow and all sorts of version control repositories.
(And of course various others for anything and everything else…)

Third party applications often allow you to sign in with your account from another website.

The good thing is, that you don’t need to create a separate account for every single one, but are offered the possibility to just sign in with an account you created for a different service.
The page for which you want to use a different account needs to request data from the original website and use it to authenticate the user (without their input).
In order to give both the requesting website and the user assurance that the data will be safe and reliable some sort of standardisation is required.
Most commonly used is the open standard for authorisation OAuth.
With OAuth it is possible for users to grant access to their information from a certain website without giving away their credentials.

This is what it looks like when the user reviews the permissions.

In order for the third party application to obtain specific information about a user, it has to request an access token from the authorisation server, and when the user grants the permission, use that token to access the resources from the website.
In our specific case we want users to be able to log in to Icinga Exchange with their GitHub accounts.
If you now also want to integrate GitHub on your website and/or see how it’s done: they have a detailed tutorial here.

Jennifer Mourek
Jennifer Mourek
Junior Developer

Jennifer (von eigentlich jedem nur "Feu" genannt) verbrachte ihre Kindheit im schönen Steigerwald und kämpfte sich bis zum Abitur durch die Schule. Seit September 2016 unterstützt sie nun im Rahmen ihrer Ausbildung zum Fachinformatiker die Development Abteilung bei Netways und widmet sich dort dem Web Development. Ihre Freizeit verbringt sie hauptsächlich in den virtuellen Welten von 'Dota 2' und diversen anderen Games, an der Kletterwand in der Boulderhalle oder damit ihren Freunden und Kollegen auf...

Netways Managed Services Status Page – Github is your friend

Unser neues Familienmitglied

Als neuestes Angebot für unsere Hosting-Kunden haben wir nun eine Wartungsseite ins Leben gerufen. Diese ist öffentlich sichtbar unter und soll über Wartungsintervalle unserer Systeme informieren.

Diese Informationen sind in Form eines Blogs aufbereitet und umfassen Meldungen zu Wartungsbeginn, Wartungsende, Verlaufsupdates sowie den betroffenen Systemen und Services.

Blick hinter die Kulissen

Es gibt natürlich sehr viele Varianten, eine Webseite mit Blog umzusetzen. Eines unserer Kriterien war, dass die Wartungsseite extern gehostet sein sollte, um auch bei Wartungen an Webservern oder eventuellen Ausfällen den Informationsfluss zum Kunden garantieren zu können. Des Weiteren sollten Posts schnell und mit Methoden erstellt werden, die das Team bereits im Einsatz hat. Recht schnell fiel die Entscheidung dann auf das Format Github Pages, das all dies nativ bietet.

Wie funktioniert Github Pages?

Github Pages bietet die Möglichkeit, in einem Repository eine Webseite zu erstellen, die unter der URL <username> online verfügbar ist. Die Struktur der Webseite ist frei wählbar und kann mit den üblichen Layout-Sprachen wie HTML und CSS erstellt werden. Änderungen an der Webseite und das Hinzfügen von Posts können zum einen über die Github-Webseite, aber auch wie gewohnt über die git-Kommandozeile durchgeführt werden.
Nun fragen sich wahrscheinlich viele, wo denn jetzt der Clou an Github Pages ist – Jekyll!
Jekyll ist die Engine, die für uns im Hintergrund den Blog erstellt und die Webseite aktualisiert, sobald ein neuer Post oder eine Änderung an einem bereits bestehenden Post erfolgt. Dies ist nativ in Github Pages eingebaut, so dass hier nichts installiert werden muss – es gilt nur, die von Jekyll erwarteten Konventionen einzuhalten. Dazu gehören z. B. die Directory-Struktur im Repository sowie die File-Namen der Blog-Posts. Damit Jekyll den Blog korrekt generieren kann, werden Layouts hinterlegt, so dass die Posts als schön formatierte Einträge auf der Webseite erscheinen. Mithilfe dieser Layouts kann Jekyll die in Markdown verfassten Inhalte der Posts interpretieren.
Github Pages steht jedem zur Verfügung, der einen Github-Account besitzt. Was man daraus macht, bleibt einem selbst überlassen – jedoch sollte man sich dieses Angebot nicht entgehen lassen.
Als Startpunkt für die Reise durch Github Pages ist das Tutorial von Jonathan McGlone sehr zu empfehlen:
Creating and Hosting a Personal Site on GitHub
Ich wünsche allen Interessierten viel Spaß beim Ausprobieren!

Nicole Lang
Nicole Lang
Account Manager

Ihr Interesse für die IT kam bei Nicole in ihrer Zeit als Übersetzerin mit dem Fachgebiet Technik. Seit 2010 sammelt sie bereits Erfahrungen im Support und der Administration von Storagesystemen beim ZDF in Mainz. Ab September 2016 startete Sie Ihre Ausbildung zur Fachinformatikerin für Systemintegration bei NETWAYS, wo sie vor allem das Arbeiten mit Linux und freier Software reizt. In ihrer Freizeit überschüttet Sie Ihren Hund mit Liebe, kocht viel Gesundes, werkelt im Garten, liest...

Icinga2 API und BitBar auf MacOs

preview1Wir wollen APIs, warum? Weil sie schnell, einfach zu integrieren und zu bedienen sind. Nun hat Icinga2 eine API und es entstehen ganz viele Möglichkeiten diese zu nutzen. Wir bauen uns Dashboards mit Dashing oder zeigen den Status von Hosts in Foreman an.
Ich bin letztens über ein Tool BitBar gestolpert, dieses Tool kann mit einfachen Skripten die eigene “Mac OS X menu bar” erweitern. Hierfür braucht es nur die richtige Formatierung der Ausgabe und BitBar generiert ein weiteres Dropdown Menu.
Ich hab mir die Icinga2 API zu nutze gemacht und eine kleine Erweiterung gebaut um mir den Status von Icinga2 in meiner Menubar anzuzeigen.
Im Menu wird dann der globale Status entweder in grün oder rot, abhängig davon ob Hosts “down” und “unhandled” sind, angezeigt.
Der Aufruf dafür kann der Adresszeile im Browser entnommen werden.
Wenn wir am Ende dann ein “&format=json” an die URL hängen, haben wir ein gängiges Format um das Ergebnis in jeglichen Applikationen zu verwenden.
Mehr dazu gibts auf Github unter icinga2_api_examples oder natürlich in der Icinga2 Dokumentation.

Thilo Wening
Thilo Wening
Senior Consultant

Thilo hat bei NETWAYS mit der Ausbildung zum Fachinformatiker, Schwerpunkt Systemadministration begonnen und unterstützt nun nach erfolgreich bestandener Prüfung tatkräftig die Kollegen im Consulting. In seiner Freizeit ist er athletisch in der Senkrechten unterwegs und stählt seine Muskeln beim Bouldern. Als richtiger Profi macht er das natürlich am liebsten in der Natur und geht nur noch in Ausnahmefällen in die Kletterhalle.

OSDC 2015: Der Countdown läuft – nur noch 15 Tage

Mike Adolphs mit “How we run Support at GitHub

OSDC? Noch nie gehört…
Das ist aber schade und fast schon ein unentschuldbares Versäumnis!
Aber wir holen das nach:
Die Open Source Data Center Conference (kurz OSDC) ist unsere internationale Konferenz zum Thema Open Source Software in Rechenzentren und großen IT-Umgebungen. 2015 findet sie zum siebten Mal statt und bietet mit dem Schwerpunktthema Agile Infrastructures ganz besonders erfahrenen Administratoren und Architekten ein Forum zum Austausch und die Gelegenheit zur Aneignung des aktuellsten Know-Hows für die tägliche Praxis. Diesmal treffen wir uns dafür in Berlin!
Workshops am Vortag der Konferenz und das im Anschluss an die Veranstaltung stattfindende Puppet Camp komplettieren dabei das Rundum-sorglos-Paket für Teilnehmer, die gar nicht genug Wissen in sich aufsaugen können.