New Request Tracker Extensions: Search Result Highlights, Quick Assign & User Overview

We use Request Tracker on a daily basis, and have written many extensions for our own workflows and visualizations. Lately we’ve been helping a customer to migrate from OTRS to RT running in NWS, and learned about new ways to improve our workflows.

Highlight Search Results on Conditions

When you own a ticket, but someone else updated the ticket with a comment/reply, you want to immediately see this. Our extension makes this possible with either a background color or an additional icon (or both).
You can also limit this to replies/comments from customers, where the last update wasn’t performed by users in a specific group. This allows to immediately see support or sales tickets which need to be worked on in the dashboards.
Another use case is to highlight search result rows when a custom field matches a specified value. If you’re setting tickets for example, you can visually see the difference between a “bought ticket” and “paid ticket” state.
While developing the extension, I’ve also fixed an upstream RT bug which has been merged for future releases. There’s even more possibilities, as we’ve recognised that one of the BestPractical/RT developers forked our extension already 🙂


Quick Assign People to Tickets

By default, one needs to edit the “People” tab to assign a ticket to a privileged user, or modify adminCC and the requestor. This takes far too long and as such, our own NETWAYS extension improved this with drop-downs and action buttons. We have now open-sourced this feature set into a new extension on GitHub: rt-extension-quickassign.


Show Ticket Count per User and Status

This extension was released a while ago, and we’ve fixed a bug with empty sets in there. In addition to that, we’ve added a new configuration option which allows to list specific groups and their members, and not only privileged users. This comes in handy to only show the NETWAYS members but not any root or meta accounts. Read more on GitHub.
Do you need more customizations for Request Tracker, or want to run RT in a managed cloud environment? Just get in touch 🙂

OSMC Hackathon: Feature complete?

Our fourth OSMC hackathon started fully packed after an overwhelming conference – free form, and our introduction round provided many interesting topics to keep up with.
MQTT, OpenNMS, NSClient++, Elastic/Graylog, Migration from Nagios to Icinga 2, Zabbix, Prometheus, MySQL, ARM packages, Notification issues, Golang frameworks, Ansible, Puppet, Icinga Web 2 modules, Vsphere, Director, Maps, … holy moly, that’s super effective for just one day. Missed it? Join us next year!
Jens Schanz from Müller (Hint: The environment with 17k hosts and 200k services) mentioned a problem with missing notifications in his OSMC talk on Wednesday. So we did a deep dive in the production environment into one-time delayed notification without recovery for their ticket system integration. Turns out, that we’ve found a bug in Icinga, and also a quick workaround for production. Jens also knows how to use the debug console for future troubleshooting. Real #monitoringlove ❤️
Gian Arb from InfluxDB joined for the first hours, so “everyone who has questions, be quick”. Maybe he’ll stay longer next year, since he’s said that OSMC feels like home already. Rihards Olups shared Zabbix insights and focussed on improving MySQL monitoring. Our friends Tarus Balog and Ronny Trommer from OpenNMS looked into pushing sensor values into MQTT and OpenHAB, Tarus had his first success 🙂 Julien open-sourced an AMPQ adapter which forwards alerts from Prometheus.
Nicolai Buchwitz is building Icinga 2 for ARM hardware, and asked me to look into failing tests during the Debian package build. This turned out to be a very deep analysis with memory access violations and specific gcc and libstdc++ versions on this hardware, x86 works just fine. 50% are solved, more investigation needed.
Michael Medin implemented a huge new feature: Native Powershell support in NSClient++.  Cannot wait to see this being released! Dave Kempe started working on translation for the famous Icinga 2 book, together with Thomas Mr. Icinga Book. Or as they say: “Translating Austrian to Australian (English) …” 😉 Thilo jumped right into Jinja templates for the Icinga Ansible modules, and also offered help on enhancing the graph integration in mail notifications.
Noah and Jean played with the Gin library in Golang, providing an HTTP framework. They also discussed the state logic in Icinga 2 together with Eric and our friends from Syseleven, Max and Maurice. Max also did a deep-dive into new enhancements for Icinga Web 2 with more advanced scheduled downtime options. Together with Eric, he found a bug in the forms too. First time hackathon attendees discovered how to write Icinga Web 2 with the help from Eric.
The Map module for Icinga Web 2 received a docs patch from Jens, while Thomas Mr. Director looked into improvements for the business process module, Director, Cube (PR from Nicolai) and certainly the newly released Vsphere module. Last but not least, Flo was for the rescue and helped Jens to modify his Batman theme for Icinga Web 2. Dave also shared the color blind theme for Icinga Web 2 with Jennifer, and to mention too, Jean helped Jens with a DNS/network problem on Icinga startup.
It is INCREDIBLE what we achieved together as OSMC hacking family. We are never feature complete, always exploring and developing new things. See you next year, mark November 4th–7th, 2019 in your calendar!

DEV Retreat 2018 Recap

We had a lovely time somewhere in the “Franconian Alps”, away from daily development business. Our dev retreat always includes one day of “looking back, looking forward”, the second day is reserved for fun stuff.
After a relaxed breakfast on Friday, Marius invited us into the icebreaker game. Rock-Paper-Scissors combined with catching the other team on win, really a challenge and discussions on failure afterwards. Before diving into a strategic outlook with Icinga and NETWAYS development, Flo made a shout-out for the first round of beer pong. Another group was like “hey, what’s cards against humanity with monitoring?” and just started playing, that was pure fun 🙂
Later on, we did a full retrospective of the past year in our development team. Everyone shared their current mood, with then collecting three important topics (good or bad) from the past year. This entire timeline with many milestones was put in contrast with everyone’s mood over time. Reflecting the not-so-good tasks towards the “we really love this project and technology” we created our own team “graph”.
Having shared this many feelings and milestones, we made it into another round – direct feedback on everyone’s important points, be it good or bad. We’ve then built a topic cloud from these and voted topics we would like to discuss and define solutions. The two of them were selected and we started to discuss, help each other, criticise specific points and agree on a solution together. Pure energy, and not even the BBQ being ready could have stopped us. Knowledge transfer, trainee practice, more direct feedback, interesting technologies and new projects coming up …
After all we enjoyed a lovely evening and night sitting by the campfire, playing another round of beer pong, chatting and enjoying life.
The next day our plan was to escape a room. 60 minutes, lots of puzzles and hints, to finally solve everything. It is hard to describe as everyone finds his/her role pushing the others to the next level and puzzle. And there’s discussion and “anger” afterwards that you’ve lost 20 minutes on such a stupid question … but you failed together, and that’s a good feeling even 🙂
Next to getting to know colleagues and new trainees better, my personal highlights this year are these two quotes:

During our debugging sessions, I never had that feeling that I am treated as a “dumb” trainee. My ideas and knowledge are taken into account, and I really like this in our team.

Your mission as Senior Developer or experienced developer is to share your knowledge and experience with your colleagues. Help them improve and learn from you, with the most detailed feedback you can give.

And on we go, we have to develop projects like Icinga DB, Reporting, NoMa, Mobile, support daily business with Icinga 2, Icinga Web 2, Icinga Exchange, Request Tracker, Pretix, Discourse, GitLab, Jenkins and so much more filling the timeline for next year’s dev retreat already 🙂

GitLab training v2.3.0 released

We really had an awesome time in the last 2 days practicing Git and GitLab. With all those ideas from a training, I’ve updated the material and tagged v2.3.0.
This release includes bugfixes for “hard to understand” slides and continues with new features added to the training, done “on the fly” yesterday: Issue boards, Web IDE with commits & CI pipeline jobs, improved workflows with milestone, issue and merge request handling and much more.
Cannot wait to practice this? Get your ticket for our GitLab training soon enough! 🙂

A peek into GitLab 11, the Web IDE and Auto DevOps with Kubernetes

GitLab 11 was just released last week and introduces a bunch of new features. I’ve picked the most exciting ones for a short peek as our hosted production environment was already upgraded by Stefan 🙂


You can already add and edit files directly in your browser. Dirk mentioned this in his blog post, it motivates open source contributors to enhance the documentation. For larger changes we are used to fire up an IDE like Visual Studio, JetBrains Goland, PHPStorm, Atom, Eclipse, etc.
Sometimes you don’t need a full blown IDE, or you don’t have access to on your mobile device. It would be nice to have immediate results from build, compile and test stages, best in an isolated (container) environment.
The newly introduced GitLab Web IDE attempts to become a new player in the field. On the right you can already see the current pipeline job status from the latest commit. Once we’ve edited the file, we can commit (and push at once) and the CI will trigger a new job run. Just awesome!

In its current implementation, the IDE is accessible from files view only, but the roadmap proves that there’s more to come on project creation. Just type t in the main project view and search for a specific file. Then pick Web IDE from the upper left bullets and rock on. There is syntax highlighting and code auto-completion included ❤️


Auto DevOps with Kubernetes

Our vision is to replace disparate DevOps toolchains with a single integrated application that is pre-configured to work by default across the complete DevOps lifecycle.

Auto DevOps enables your CI/CD workflow to advance even further with pipeline container environments built on Kubernetes. GitLab provides its own Kubernetes integration, accompanied with default templates for projects and build pipelines. This isn’t limited to build, test, deploy stages but also includes a variety of additional stages:

  • Build and Test
  • Code Quality checks
  • Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), Dependency and container scanning for vulnerabilities
  • Review Apps, deploy current state to temporary application environment in Kubernetes (optional)
  • Deploy to Kubernetes production environment (optional)
  • Monitoring for fetching deployment metrics from the Kubernetes cluster via Prometheus exporter (optional)

You can see the changes inside the menu where Operations was introduced and provides settings for environments and Kubernetes integration. This was previously found in the CI/CD section. A Kubernetes cluster can be assigned to a specific project, you can safely play and test without harming a global environment.
Nicole and Gabriel shared more insights into GitLab 11 features in their OSDC talk on “Git things done with GitLab!”. Check the archive for a live demo especially on the Auto DevOps feature, first time I fully understood its purpose 🙂

Notable Changes

In terms of roles, GitLab renamed “Master” to “Maintainer”.

GitLab also decided to release the “Squash and Merge” option into the Open source edition. This feature allows you to develop a merge request in multiple commits, and upon merge back to master, it will automatically squash the commits into a single one. Want to learn more about git squash? We’ve got you covered in our GitLab training 🙂

I really hope that GitLab will also open-source Merge request approvals in future releases. This is something which we use for code review and release managed on GitHub on a daily basis and would enhance our GitLab flow too.
Still not enough? I’d love to talk GitLab with you in our upcoming training sessions, including the best development workflows from our daily work 🙂

Hurra, hurra … der Bio-Milch-Mann ist da!

Vor einiger Zeit haben wir über das Billig-Milch-Dilemma bei Aldi, Rewe, etc. diskutiert. Zunächst auf Twitter, dann aber auch mal offline in lockerer Runde. Dass am Ende sehr wenig Ertrag bei unseren Bauern ankommt, steht ausser Frage. Und dass wir das nicht gut gefunden haben, auch. Da wir bei NETWAYS gerne mal Tagesthemen und Probleme angehen, haben wir uns gefragt, wo wir selbst noch nachhaltiger werden können. Dabei ist uns aufgefallen, dass die Paletten an Milch für unseren Kaffee und die myMuesli-Versorgung auch auf dieser Milch-Billig-Schiene basieren. Haltbarmilch, fettarm, aber dennoch … “wir sollten Biomilch einkaufen, fertig, aus.” war eine spontane Idee von Bernd und Vanessa.
Es ist ein bisschen Gras über die Sache gewachsen. An einem schönen Tag im Büro waren plötzlich keine Milchpackerl mehr da. Stattdessen Biomilch in grösseren Behältnissen, frisch mit Sahne oben drauf. Eine ganz andere Welt, die gut schmeckt, und mit dem Gefühl der Nachhaltigkeit noch deutlich besser schmeckt 🙂

Wer sich nun frägt – “das ist ja Plastik und kein Glas”. Jepp, wir reinigen die Flaschen selbst und geben diese bei unserer wöchentlichen Lieferung wieder zurück. Grössere Kühlschränke brauchen wir jetz halt, aber das kriegn ma auch noch 😉
Ich habe mich selbst dabei ertappt, dass ich im Supermarkt nicht mehr zu meiner “üblichen” schnellen Milch greife (die auch den 61-Cent-Stempel trägt, wenn man mal genau hinschaut), sondern selektiv Bio-Milch nehme. Kostet zwar einen Euro, dafür schmeckt der Julius-Meinl-Kaffee deutlich besser damit. Die guten Dinge im Leben muss man einfach nachhaltig geniessen ❤️

Continuous Integration with Golang and GitLab

Today you not only develop code and collaborate with other developers in your Git branches and forks. In addition continuous integration helps with “instant” compile and runtime tests. Which Git commit caused a failure, are there any performance changes with the recent code history?
Today I want to dive into our latest insights into Golang and building our code inside GitLab on each push and merge request. Golang extensively supports unit tests and also their analysis with coverage tests. This ensures that code isolated in test interfaces runs rock-solid and you can focus on the more important tasks and features.
In order to abstract the Go build and install calls, we add a Makefile for convenience. This also allows developers to manually use it, if they want.

$ vim Makefile
.PHONY: all test coverage
all: get build install
        go get ./...
        go build ./...
        go install ./...
        go test ./... -v -coverprofile .coverage.txt
        go tool cover -func .coverage.txt
coverage: test
        go tool cover -html=.coverage.txt

The “coverage” target runs the tests and stores the coverage results in “.coverage.txt”. This is then converted into HTML and can be opened with a browser for example.
Inside GitLab we need a CI runner configured for our project and job pipeline. This is already available in the NWS app. If you want to learn more about GitLab CI/CD, containers, jobs and pipelines, I’ll invite you to join me for the official GitLab training sessions 🙂
The CI configuration file is stored in “.gitlab-ci.yml” inside the Git repository and uses the Golang image for Debian Stretch in this example.

$ vim .gitlab-ci.yml
image: golang:1.10-stretch
  - build
  - apt-get update && apt-get install -y make curl
  - curl | sh
  - mkdir -p /go/src/
  - ln -s /builds/icingadb/icingadb /go/src/
  - cd /go/src/
  - dep init && dep ensure
  stage: build
    - make test

The “before_script” tasks can be moved into your own Docker image which can be made available in the GitLab container registry too. At some later point when dependencies are fixed, we’ll remove the “dep init” step and just use the locked versions from inside our Git repository.
The test coverage should also be highlighted in the job output. This can be extracted with a regular expression using the shell output from the tests. Nagivate into “Settings > CI/CD > General pipeline settings > Test coverage parsing” and add the following regex:


Each pushed branch and merge request will then automatically be built and also shows the test coverage. There’s room for improvement here, the next months will ensure to add more unit and runtime tests ?

Releasing our Git and GitLab training as Open Source

Development is super fast these days, there are many tools and integrations to make it more comfortable. One of the version control systems is Git, next to well-known SVN and CVS. Git got really pushed by GitHub and most recently GitLab which provide entire collaboration suites. Nowadays you not only commit code revisions/diffs, you can also test and deployment changes immediately to see whether your code is good on defined platforms or breaks. Issue and project management is put on top and makes it very easy to collaborate.
Continuous integration (CI) allows for deeper code quality too. Add code coverage reports, unit test results, end2end tests and actually build distribution packages with tests on many platforms included. In addition to CI, continuous deployment (CD) adds the icing on the cake. Once CI tests and package builds are fine, add a new build job to your pipeline for automated deployments. This could for example push updated RPM packages for your repository and immediately install the bugfix release in production on all your client hosts with Puppet or Ansible.
You can do all of this with the ease of GitHub or your own hosted GitLab instance (try it out in NWS right now!). Don’t forget about the basics for development and devops workflows:

  • Untracked files, staging area, … what’s within the .git directory?
  • What is a “good commit“?
  • I want to create patch for an open source project – what’s a “pull request“?
  • Workflow with branches?
  • A developer asked me to “rebase your branch against master” and “squash the commits” … what’s that?

Our Git training sessions have been renewed into a two day hands-on session on Git and GitLab. Many of us are using Git on a daily basis at NETWAYS, in addition to GitLab. Knowledge which we share and improve upon. The training starts with the Git basics, diving into good commits, branching, remote repositories and even more. Day 1 also provides your own NWS hosted GitLab instance.
Starting with day 2, you’ll learn about development workflows with branches and real-life use cases. Continuing with CI/CD and generating your own Job pipeline, and exploring GitLab even further. We’ll also discuss integrations into modern development tools (Visual Studio, JetBrains, etc.) and have time to share experiences from daily work. I’ve been working with Git since the beginning of Icinga more than nine years ago.
We have open-sourced our GitLab training material. We truly believe in Open Source and want make it easier for development and contributions on your favourite OSS project, like Icinga.
You are welcome to use our training material for your own studies, especially if you are an open source developer who’s been learning to use Git, GitLab and GitHub. For offline convenience, the handouts, exercises and solutions are provided as PDF too.
Many of the mentioned practical examples and experiences are only available in our two day training sessions at NETWAYS so please consider getting a ticket. There’s also time for your own experience and ideas – the previous training sessions have shown that you can always learn something new about Git. You can see that in the Git repository and the newer Git commits, where this feedback was added to the training material ❤️
See you soon at the famous NETWAYS Kesselhaus for a deep-dive into Git and GitLab!
Please note that the training material is licensed under Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International.

Modern open source community platforms with Discourse

Investing into open source communities is key here at NETWAYS. We do a lot of things in the open, encourage users with open source trainings and also be part of many communities with help and code, be it Icinga, Puppet, Elastic, Graylog, etc.
Open source with additional business services as we love and do only works if the community is strong, and pushes your project to the next level. Then it is totally ok to say “I don’t have the time to investigate on your problem now, how about some remote support from professionals?”. Still, this requires a civil discussion platform where such conversations can evolve.
One key factor of an open source community is to encourage users to learn from you. Show them your appreciation and they will like it and start helping others as you do. Be a role model and help others on a technical level, that’s my definition of a community manager. Add ideas and propose changes and new things. Invest time and make things easier for your community.
I’ve been building a new platform for based on Discourse in the last couple of days. The old platform based on Woltlab was old-fashioned, hard to maintain, and it wasn’t easy to help everyone. It also was closed source with an extra license, so feature requests were hard for an open source guy like me.
Discourse on the other hand is 100% open source, has ~24k Github stars and a helping community. It has been created by the inventors of StackOverflow, building a conversation platform for the next decade. Is is fast, modern, beautiful and both easy to install and use.

Setup as Container

Discourse only supports running inside Docker. The simplest approach is to build everything into one container, but one can split this up too. Since I am just a beginner, I decided to go for the simple all-in-one solution. Last week I was already using the 1.9.0beta17, running really stable. Today they released 1.9.0, I’ll share some of the fancy things below already 🙂
Start on a fresh VM where no applications are listening on port 80/443. You’ll also need to have a mail server around which accepts mails via SMTP. Docker must be installed in the latest version from the Docker repos, don’t use what the distribution provides (Ubuntu 14.04 LTS here).

mkdir /var/discourse
git clone /var/discourse
cd /var/discourse

The setup wizard ask several questions to configure the basic setup. I’ve chosen to use as hostname, and provided my SMTP server host and credentials. I’ve also set my personal mail address as contact. Once everything succeeds, the configuration is stored in /var/discourse/container/app.yml.

Nginx Proxy

My requirement was to not only serve Discourse at /, but also have redirects for other web applications (the old Woltlab based forum for example). Furthermore I want to configure the SSL certificates in a central place. Therefore I’ve been following the instructions to connect Discourse to a unix socket via Nginx.

apt-get install nginx
rm /etc/nginx/sites-enabled/default
vim /etc/nginx/sites-available/proxy.conf
server {
    listen 443 ssl;  listen [::]:443 ssl;
    ssl on;
    ssl_certificate      /etc/nginx/ssl/;
    ssl_certificate_key  /etc/nginx/ssl/;
    ssl_protocols TLSv1.2 TLSv1.1 TLSv1;
    ssl_prefer_server_ciphers on;
    # openssl dhparam -out /etc/nginx/ssl/dhparam.pem 4096
    ssl_dhparam /etc/nginx/ssl/dhparam.pem;
    # OCSP Stapling ---
    # fetch OCSP records from URL in ssl_certificate and cache them
    ssl_stapling on;
    ssl_stapling_verify on;
    location / {
        error_page 502 =502 /errorpages/discourse_offline.html;
        proxy_intercept_errors on;
        # Requires containers/app.yml to use websockets
        proxy_pass http://unix:/var/discourse/shared/standalone/nginx.http.sock:;
        proxy_set_header Host $http_host;
        proxy_http_version 1.1;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
ln -s /etc/nginx/sites-available/proxy.conf /etc/nginx/sites-enabled/proxy.conf
service nginx restart

Another bonus of such a proxy is to have a maintenance page without an ugly gateway error.
The full configuration can be found here.


Installation is a breeze – just add the installation calls into the app.yml file and rebuild the container.

# egrep -v "^$|#" /var/discourse/containers/app.yml
  - "templates/postgres.template.yml"
  - "templates/redis.template.yml"
  - "templates/web.template.yml"
  - "templates/web.ratelimited.template.yml"
  db_default_text_search_config: "pg_catalog.english"
  LANG: en_US.UTF-8
  - volume:
      host: /var/discourse/shared/standalone
      guest: /shared
  - volume:
      host: /var/discourse/shared/standalone/log/var-log
      guest: /var/log
    - exec:
        cd: $home/plugins
          - git clone
          - git clone
          - git clone
  - exec: echo "Beginning of custom commands"
  - exec: echo "End of custom commands"
./launcher rebuild app

Akismet checks against spam posts as you know it from WordPress. We’ve learned that spammers easily crack reCaptcha, and the only reliable way is filtering the actual posts.
The second useful plugin is for accepting an answer in a topic, marking it as solved. This is really useful if your platform is primarily used for Q&A topics.

Getting Started

Once everything is up and running, navigate to your domain in your browser. The simple setup wizard greets you with some basic questions. Proceed as you like, and then you are ready to build the platform for your own needs.
The admin interface has lots of options. Don’t fear it – many of the default settings are from best practices, and you can always restore them if you made a mistake. There’s also a filter to only list overridden options 🙂

Categories and Tags

Some organisation and structure is needed. The old-fashioned way of choosing a sub forum and adding a topic in there is gone. Still Discourse offers you to require a category from users. Think of monitoring – a question on the Icinga Director should be highlighted in a specific category to allow others to catch up.
By the way – you can subscribe to notifications for a specific category. This helps to keep track only for Icinga related categories for example.
In addition to that, tags help to refine the topics and make them easier to search for.

Communication matters

There are so many goodies. First off, you can start a new topic just from the start page. An overlay page which saves the session (!) is here for you to edit. Start typing Markdown, and see it pre-rendered live on the right side.
You can upload images, or paste an URL. Discourse will trigger a job to download this later and use a local cache. This avoids broken images in the future. If you paste a web link, Discourse tries to render a preview in “onebox”. This also renders Github URLs with code preview.
Add emotions to your discussion, appreciate posts by others and like them, enjoy the conversation and share it online. You can even save your draft and edit it amongst different sessions, e.g. after going home.


Tutorials, Trust Level and Rewards

Once you register a new account (you can add oauth apps from Twitter, Github, etc.!), a learning bot greets you. This interactive tutorial helps you learning the basics with likes, quotes, urls, uploads, and rewards you with a nice certificate in the end.
New users don’t start with full permissions, they need to earn their trust. Once they proceed with engaging with the community, their trust level is raised. The idea behind this is not to have moderators and admins regulating the conversation, but let experienced members to it. Sort of self healing if something goes wrong.
Users who really engage and help are able to earn so-called badges. These nifty rewards are highlighted on their profile page, e.g. for likes, number of replies, shared topics, even accepted solutions for questions. A pure motivation plaything built into this nice piece of open source software.


Wiki and Solved Topics

You can change topics to wiki entries. Everyone can edit them, this way you’ll combine the easiness of writing things in Markdown with a full-blown documentation wiki.
Accepting a replay as solution marks a topic as “solved”. This is incredibly helpful for others who had the same problem.



As an administrator, you’ll get automated page profiling for free. This includes explained SQL queries, measured page load time, and even flame graphs.
If you ever need to reschedule a job, e.g. for daily badge creation, admins can access the Sidekiq web UI which really is just awesome.
Plugin development seems also easy if you know Ruby and EmberJS. There are many official plugins around which tested before each release.

Discourse also has a rich REST API. Even a monitoring endpoint.


You can create backups on-demand in addition to regular intervals. You can even restore an old backup directly from the UI.



Discourse is used by many communities all over the world – Graylog, Elastic, Gitlab, Docker, Grafana, … have chosen to use the power of a great discussion platform. So does as a #monitoringlove community. A huge thank you to the Discourse team, your software is pure magic and just awesome 🙂
My journey in building a new community forum from scratch in just 5 days can be read here 🙂 running Discourse is fully hosted at NETWAYS, including SSL certificates, Puppet deployment and Icinga for monitoring. Everything I need to build an awesome community platform. You too?

Replace spaces with tabs in Visual Studio 2017

Visual Studio has several source code edit settings. This defaults to 4 spaces and no tabs by default and is slightly different to what we use in Icinga 2. There we put focus on tabs in our code style.
Editing the Icinga 2 source code on Windows with Visual Studio requires adjusting the editor settings. Navigate into Tools > Options > Text Editor > C# and C++ and adjust the settings to “Keep tabs”.

I accidentally forgot to specify these settings for C# too, and had the problem that half of the Icinga 2 setup wizard code had 4 spaces instead of tabs. Luckily I’ve found this blog post which sheds some lights in the comments.
Hit Ctrl+H to open the replace search window. Tick the icon to use regular expressions and search for “((\t)*)([ ]{4})”. Add “\t” as replacement text.

Happy coding for Icinga 2 v2.8 – ready for OSMC 🙂