GitLab Training v2.5.0 released

We have released v2.5.0 of our GitLab training today. Based on the feedback from previous trainings, and many things learned together with the students, we aim for the next classes already.

Dive deep into Git rebase, merge, squash, cherry-pick, get to know real-life development workflows and explore the possibilities of CI/CD pipelines and even more fancy GitLab features. Check our training schedule and register now!

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

Request Tracker: Highlight tickets based on due dates

A while ago we’ve announced a new extension for Request Tracker which allows to highlight tickets in search results even better.

Next to “last updated by” and custom field conditions, we’ve now added a requirement from production:

  • light red coloring for tickets with a due date in 3 days
  • dark red coloring for everything where the due date already passed

When there’s a ticket which matches one of the other conditions, due date wins over “last updated by” which itself wins over custom field conditions.

v2.0.0 is available on GitHub. Consider asking our sales engineers when building a new RT instance in NWS 🙂

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

RequestTracker: Optimize Session Handling

To provide features like login or persistence to the user, stateless protocols like HTTP depend heavily on sessions. Almost every web application is using it.

An easy job you would say? Of course! But what about high availability setups with hundreds of concurrent users? And sessions need to be shared between application servers so that that users do not lose their current login session.

RT’s vanilla way is to put this in MySQL which produces queries on every request. Second bad thing is the created GET_LOCK query which slows down the environment after a while.

Better way is to use files because file sessions are extremely fast. No network overhead and not greatly influenced by differential IO. But then you have to share sessions between application servers and you should say good bye to that idea because we do not live in an ideal world and shared file systems are terribly slow.

What Next?

I opt for Redis. Meanwhile available on every system, fast as the LHC in Geneva and rock-solid like carbon. Redis is so adorable simple that you only can fall in love with this single-core-minimal-footprint-key-value-store thingy. But I’ll stop hallowing now.

RequestTracker uses Apache::Session::* default implementation and we choose the NoSQL module from there which provides access to Apache Cassandra and Redis.

Configuration Examples

# Annouce Redis to RequestTracker
Set($WebSessionClass, "Apache::Session::Redis");

# Single server
  server => ''

# Sentinel
  sentinels => [ '' ],
  service => 'mymaster',
  sentinels_cnx_timeout => 0.1,
  sentinels_read_timeout => 1,
  sentinels_write_timeout => 1

You can find more information in the product documentation.


It’s just a glimpse, but there a lot of ways to bring RequestTracker to enterprise level with more than 300 concurrent users and millions of tickets and attachments. Of course, highly available and scaled in every direction. You only need to ask us how to do!

Marius Hein
Marius Hein
Head of Development

Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert, dann als Application Developer gearbeitet und ist nun Leiter der Softwareentwicklung. Ausserdem ist er Mitglied im Icinga Team und verantwortet dort das Icinga Web.


Australia, Austria, Belgium, Canada, Czech Republic, Cyprus, Denmark, Estonia, France, Germany, Ireland, Israel, Italy, Latvia, Luxembourg, Netherlands, Poland, Spain, Sweden, Switzerland, Turkey, USA – more than 300 attendees and 47 speakers from 22 countries joined us: What would OSMC have been without them? To be honest: Not happening.


….to all our attendees and speakers: You made OSMC special, inspiring and fun by joining or contributing to it! Thanks for your support! 4 days, 3 tracks of talks, 4 workshops, the fun community Hackathon, the Evening Event at Loftwerk, Lambada (former Checkpoint Jenny), Tapasitos, Schimanksi: It was a blast!

Travel back in time

Convince yourselves: Take a look at our Archive with all video recordings of the talks, the speakers‘ slides and conference pictures. And make sure you don’t miss this next year!

Save the date: #OSMC 2019 | November 04 – 07, 2019 | Nuremberg
Julia Hornung
Julia Hornung
Marketing Manager

Julia ist seit Juni 2018 Mitglied der NETWAYS Family. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.

git gud! or: How I Learned to Stop Worrying and Love my Code

(…and I’m only 13 years late to the party…)
First of all, I have a confession to make. I’m code shy. At least that’s what I thought I was.
One of the fresh-faced young trainees this year here at NETWAYS, I’m not entirely “new” to the scene. Having gone to university (with varied success) I never was bestowed with the confidence to actually contribute to anything. In terms of feedback, my lecturers and I only looked at what I was doing wrong – yes, admittedly, to get me to stop what I was doing wrong, but approaching code like this made me feel like I was always doing something wrong.
Again, admittedly, I probably was always doing something wrong, but I felt like I shouldn’t contribute, I mustn’t contribute, the only thing I would add to an open source project would be bugs, I would mess things up more than I would be helpful to anybody. I’ve written some small stuff for myself at home, but.. why would anybody rely on my code?
It was an awful feeling. So I never did contribute. And that’s how I became code shy.
Three months into my stint at NETWAYS, and it all changed massively. Apart from my wonderful colleagues, git helped in a big way to give me more confidence, to be more active in my participation, to instill a kind of pride in my work I haven’t felt before – to stop worrying and love my code.

So – why write the millionth paragraph about git?

This won’t be a technical introduction, but rather a little recollection of my thoughts and emotions while getting introduced to git and using it at work – because my mind has been thoroughly blown.

What’s git?

Well, let’s take a look at good ol’ Wikipedia:

Git (/ɡɪt/) is a version-control system for tracking changes in computer files and coordinating work on those files among multiple people.

Version-control? Now, what’s that supposed to mean? Is that like back in the days when I sent my source code files to my professor via mail, so he could check over them and see if I did my stuff?
Well, in a way, that could be some sort of version control system as well – just not a very automated and effective one. Version control is about the general management of files, code, data – it keeps track of changes, who did what, when (and if you’re lucky, you’ll even find a hint or two explaining why), and it allows for reversion of changes and modifications people have made.
My ears perked up when I heard this.
I can go around and mess things up and nobody would get mad at me? I won’t break stuff from the get go? I was amazed.

But how does git do it?

At work we have remote repositories hosted on GitLab, from which I could pull all of the files of the project onto my local machine. So now I have my own copy of the project, in which I could move, delete, add or modify files to my liking – and I wouldn’t break anything doing so, because the remote repository on GitLab would be completely unchanged.
In a way, it’s a sandbox for me, where I can go ahead and code, take care of issues, fix bugs, or add features, test them – until I feel safe to share the work I’ve done with other people. You can see how that is a comforting feeling to have – you can code without worries.

So – what happens behind the scenes?

Git takes snapshots of my work. A snapshot is the way git keeps track of all of the files belonging to a project. Git will checksum them, generate a SHA-1 hash. These hashes are the way git knows about the changes to the code inside the files. After I’ve staged my modified files, I can commit the changes I’ve made. Committing will checksum all of the project directories and store them in the repository – and it will store a pointer to the commit that came before it. This is awesome! So now I can have multiple points to revert the project back to, just in case. But… how would I go about doing that?
Well, let’s talk about branches. Branches are pointers to these commits, the default one being the master branch. There is a master branch on my local machine as well as on GitLab – which made me immediately nervous again. But luckily, I can just branch off of my local master, give it a meaningful name, and even push and store the commits belonging to that branch to GitLab, with the master being untouched. Again, another safe environment for me to go about my work, be more assertive in sharing it, all in a peaceful state of mind.
So – thanks to git, I feel safe in being much more creative and independent when going about contributing to our projects here at NETWAYS – and thanks to the awesome work environment here, I do have space and time to try to add to these projects in a constructive way. My colleagues can look at my code, give me tips and hints, and neither them nor me have to worry about me being a nuisance messing things up.
But what if I’ve finally fixed a bug, or added an awesome feature to one of our projects? Then it’s time to make a merge request. On GitLab, I pick a branch of mine, write a little bit about the new functions or which bugs I (hopefully) fixed, and request for these changes to be added into the master. From there, my fate lies in the hands of the project maintainers…
A successful merge request might just be the greatest feeling of all.
I know that there are a million new ways I could break things if I use git wrongly. So, getting good at git is something I must and will learn at NETWAYS. And – bursting with pride and with a newfound confidence – I look forward to learning more every day.

Henrik Triem
Henrik Triem
Junior Developer

Henrik is Anwendungsentwickler in Ausbildung, verhindeter Rockstar, kaffeegetrieben und Open Source-begeistert. Zuhause lässt er es auch mal ruhiger mit Tee angehen, entspannt an Klavier oder Gitarre, erkundet neue Musik oder treibt sich mit seinen Freunden in Deutschland herum.

Ceph Mimic | Using loop devices as OSD

For quite some time we have been using ceph-deploy to deploy OSD in folders during the Ceph trainings held by Netways. This worked perfectly with jewel, but newer versions don’t allow this behaviour anymore.
There are several reasons for this, however, as we have a quite regulated setup for our training notebooks, we had to come up with some kind of workaround. This approach is, while working fine in our training setup, not recommended for production!
The following steps apply to a current CentOS 7 system.
As stated before, we will deploy an OSD on a block device. Though you could use a separate partition for this, we will use a loop device. For this, the first step is to create a file:
For this, create an OSD directory

$ mkdir -p /home/training/my-cluster/osd-$HOSTNAME
$ cd /home/training/my-cluster/osd-$HOSTNAME/

in this folder, create a file for later use

$ fallocate -l 30G 30GB.img

test it

# losetup -l -P /dev/loop1 "/home/training/my-cluster/osd-$HOSTNAME/30GB.img"
# wipefs -a /dev/loop1
# lsblk

This should then display your new loopdevice.
As loop devices are not reboot safe, you need to go some steps further. If you like to use rc.local for this, you’re free to do so.
We’re going to create a service, which will essentially execute the prior mentioned losetup command. For this, we need a script with the command and a .service file, which will execute the script:
sudo losetup -l -P /dev/loop1 "/home/training/my-cluster/osd-$HOSTNAME/30GB.img"

and the service file:

Description=Reattach loop device after reboot
ExecStart=/bin/bash /usr/bin/

These files have to be executable and be copied to the correct folders. Afterwards, the service must be enabled and can be started.

# chmod +x rebloop.*
# cp /usr/bin/
# cp rebloop.service /etc/systemd/system
# systemctl enable rebloop.service
# systemctl start rebloop.service

Ceph, however, will still not want to create an OSD on this device, instead give you following error message:

-->  RuntimeError: Cannot use device (/dev/mapper/<name>). A vg/lv path or an existing device is needed 

You have to make changes to /usr/lib/python2.7/site-packages/ceph_volume/util/ on the OSD host:
in line 201, add “or TYPE==’loop'”:

# use lsblk first, fall back to using stat
TYPE = lsblk(dev).get('TYPE')
if TYPE:
return TYPE == 'disk' or TYPE == 'loop'

and in line 286, change the “skip_loop” switch from “True” to “False”:

 def get_block_devs(sys_block_path="/sys/block", skip_loop=False): 

For testing purposes, simply reboot your system and verify if the loop device gets reattached correctly.
If yes, you can deploy an OSD. We’re using ceph-deploy here:

$ ceph-deploy osd create --data /dev/loop1 $HOSTNAME

When the command was successfully executed on your hosts, you can create your first pool

# ceph osd pool create rbd 100 100 replicated

examine ceph status

# ceph status

tag the pool with an application

# ceph osd pool application enable rbd rbd

As you can see, there are quite some changes to be made, and each of it is failure-prone.
Best practice is to simply use a real block device and for production you really should stick to this.
If, however, there are certain needs to be fulfilled, ceph can be convinced to comply.

Tim Albert
Tim Albert
System Engineer

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert, wobei seine Tätigkeit als Werkstudent bei IDS Scheer seinen Schwenk von Lehramt zur IT erheblich beeinflusst hat. Neben dem Studium hat Tim sich außerdem noch bei einer Werkskundendienstfirma im User-Support verdingt. Blerim und Sebastian haben ihn Anfang 2016 zu uns ins Managed Services Team geholt, wo er sich nun insbesondere...