Black Friday mal ganz in Orange – Es darf gespart werden

Black, Black, Black! Auch bei uns im NETWAYS Online Shop purzeln die Preise!

Bis zum 30. November kann bei unseren NETWAYS Monitor satt gespart werden!

 

Um bei dem Wust von Angeboten diese Woche den Durchblick zu behalten, klickt direkt hier und schon kann gespart werden!

Was unser NETWAYS Monitor alles kann? Unter dem Label von NETWAYS kann die Temperatur und Luftfeuchte in Ihren Serverräumen und Rechnenzentren gemessen werden. Selbstverständlich ist das Gerät voll SNMP-fähig und kann prima in die Monitoringumgebung, bestenfalls Icinga 2 eingebunden werden.

Schaut euch hierfür das Demo an oder direkt im Shop findet ihr ebenfalls weitere Informationen. Der Rabatt wird direkt im Warenkorb abgezogen. Unser Team steht natürlich immer für weitere Fragen zur Verfügung. Also, loslegen und kräftig sparen!

Silke Panayiotou

Autor: Silke Panayiotou

Silke ist seit März 2018 wieder zurück bei NETWAYS und unterstützt nun das Sales Team. Hier ist sie für alle Belange des Online Stores verantwortlich und treibt den Ein- und Verkauf der Monitoring Hardware und die Weiterentwicklung des Shops mit ihrem bekannten Tatendrang gehörig voran. Da sie privat den Zweitjob Mama hat und sich um ihre kleine Tochter kümmert, ist sie nur vormittags im Haus.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 9: Profile

Es ist nun nahzu schon ein Jahr her, dass in dieser Blogserie ein Artikel erschien. Zeit diese Serie fortzusetzen, auch weil wir für diese Jahr noch den Release 2.0.0 des Moduls puppet-icinga2 planen. In den kommenden Artikeln möchte ich sukezessive eine Profil-Klasse entwickeln, die einen Icinga-2-Server inklusive Plugins, IDO, Api und Icinga Web 2 installiert und konfiguriert. Als weitere Anforderung soll dies erfolgreich auf RedHat- wie auch Debian-Systemen durchgeführt werden können. Getestet wurde der Code auf Debian-9 (stretch) und CentOS-7.

Als erstes Teilziel für diesen Artikel soll Icinga 2 nebst Plugins enthalten sein. Bei den Plugins soll auch berücksichtig sein, dass es Plugins wie check_icmp oder check_dhcp gibt, die erweiterte Berechtigungen benötigen. So dürfen ICMP-Pakete oder auch DHCP-Request auf Unix nur im Ring-0 erzeugt werden. Auf RedHat wird dies über das Setzen des setuid-Bits erreicht, unter Debian mittels Posix Capabilities. Damit stellt uns Debian nicht vor größere Herausforderungen, die Plugins für RedHat-Systeme erfordern jedoch, dass der Aufrufende Benutzer Mitglied der Gruppe nagios sein muss. Um dies Anforderung zu realisieren, muss der Benutzer icinga der Gruppe nagios hinzugefügt werden, dass bei Puppet heißt, er ist via User-Resource zu verwalten. Am besten überlässt man das Anlegen vom Benutzer icinga weiterhin dem Paket icinga2, damit werden solche Eigenschaften wie UID oder das Home-Verzeichnis dem Paketverantwortlichen überlassen, d.h. aber auch die Paketinstallation muss vor der User-Resource und die wiederum vor der Klasse icinga2 abgearbeitet werden. Der Service, der von der Klasse verwaltet wird, darf erst gestartet werden, wenn der Benutzer schon korrekt konfiguriert ist. Andernfalls würde Icinga als Prozess weiterhin unter einem Benutzer laufen, der zum Startzeitpunkt von seiner Zugehörigkeit zur Gruppe nagios noch nichts wusste.
Zusätzlich muss auch die Gruppe nagios vor der User-Resource vorhanden sein, was sichergestellt ist, wenn vorher das Paket nagios-plugins-all installiert ist.

class profile::icinga2::server {

  case $::osfamily {
    'redhat': {
      require ::profile::repo::epel
      require ::profile::repo::icinga

      $manage_package = false
      $manage_repo    = false

      package { [ 'nagios-plugins-all', 'icinga2' ]:
        ensure => installed,
        before => User['icinga'],
      }

      user { 'icinga':
        groups => [ 'nagios' ],
        before => Class['icinga2']
      }
    } # RedHat
    'debian': {
      $manage_package = true
      $manage_repo    = true

      package { 'monitoring-plugins':
        ensure => installed,
      }
    } # Debian
    default: {
      fail("'Your operatingsystem ${::operatingsystem} is not supported.'")
    }
  } # case

  class { '::icinga2':
    manage_package => $manage_package,
    manage_repo    => $manage_repo,
  }
}

Die Plugins befinden sich bei RedHat in einem zusätzlichen Repository, dem EPEL-Repository, das in der dedizierten Profilklasse profile::repo::epel verwaltet wird. Gleiches gilt für das Icinga-Repo mit der Klasse profile::repo::icinga, was auf RedHat für die gesonderte Paketinstalltion vorhanden sein muss und damit nicht, wie unter Debian, der Klasse icinga2 überlassen werden kann.

class profile::repo::epel {
  yumrepo { 'epel':
    descr => "Extra Packages for Enterprise Linux ${::operatingsystemmajrelease} - \$basearch",
    mirrorlist => "https://mirrors.fedoraproject.org/metalink?repo=epel-${::operatingsystemmajrelease}&arch=\$basearch",
    failovermethod => 'priority',
    enabled => '1',
    gpgcheck => '1',
    gpgkey => "http://dl.fedoraproject.org/pub/epel/RPM-GPG-KEY-EPEL-${::operatingsystemmajrelease}",
  }
}

class profile::repo::icinga {
  yumrepo { 'ICINGA-release':
    descr => 'ICINGA (stable release for epel)',
    baseurl => 'http://packages.icinga.org/epel/$releasever/release/',
    failovermethod => 'priority',
    enabled => '1',
    gpgcheck => '1',
    gpgkey => 'http://packages.icinga.org/icinga.key',
  }
}
Lennart Betz

Autor: Lennart Betz

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

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

Autor: Henrik Triem

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:


rebloop.sh
#!/bin/bash
sudo losetup -l -P /dev/loop1 "/home/training/my-cluster/osd-$HOSTNAME/30GB.img"

and the service file:


rebloop.service
[Unit]
Description=Reattach loop device after reboot

[Service]
Type=simple
ExecStart=/bin/bash /usr/bin/rebloop.sh

[Install]
WantedBy=multi-user.target

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 rebloop.sh /usr/bin/rebloop.sh
# 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/disk.py 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.

 

Sources:

http://tracker.ceph.com/issues/36603

https://tracker.ceph.com/issues/23337

https://github.com/NETWAYS/ceph-training

 

 

 

Tim Albert

Autor: Tim Albert

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 um Infrastrukturthemen kümmert. In seiner Freizeit engagiert sich Tim in der Freiwilligen Feuerwehr - als Maschinist und Atemschutzgeräteträger -, spielt im Laientheater Bauernschwänke und ist auch handwerklich ein absolutes Allroundtalent. Angefangen von Mauern hochziehen bis hin zur KNX-Verkabelung ist er jederzeit einsatzbereit. Ansonsten kocht er sehr gerne – alles außer Hase!

OSCamp took a close look at Puppet

If you want to meet the masterminds behind a certain project, one of the best things to do is join OSCamp. Each event in the OSCamp-series throws a spotlight on another Open Source tool. OSCamp‘s second edition was on Puppet – one of the leading configuration management tools, that has been used in many productive environments for years.

Taking place in the same venue as OSMC, the Puppet users among the OSMC attendees took the chance to join the Camp and get in touch with a lot of experienced Puppet people.

From NETWAYS my colleague Dirk Götz took part in the OSCamp as a speaker. Here is his what he experienced that day:

With Walter Gildersleeve being ill we had a changed agenda, so Martin Alfke (picture) started with a great talk on how you should handle Puppet modules. It was one of the best explanaitions of the Roles and Profiles pattern you can get including many pitfalls you should avoid handling the upstream modules.

Tim Meusel‘s first talk was on scaling and monitoring Puppetserver full of practical tipps for configuring Puppetserver, Foreman, PostgreSQL, and PuppetDB.

Bram Vogelaar talked about bootstraping a cloud infrastructure with Puppet and the Hashicorp stack based on his experience from doing so at a costumer.

Containers, de-mystified

Martin volunteered to give his great “Ops hates containers. Why?” talk as a second one which shows a good example for what Devops should not look like. But then he de-mystified containers and explained how to combine container and configuration management in a good way.

After lunch I tried to squeeze all my tipps on deploying Foreman into an already existing Puppet environment into 30 minutes and to convince attendees to do so with a demo.

Kris Buytaert and Lander Van den Bulcke explained why it is so complicated to get on newer versions of Puppet in an enterprise environment and shared helpful information on how to get this done successfully.

Introduction into Vox Pupuli

Tim finished the round of talks with an introduction into Vox Pupuli the biggest community maintaining Puppet modules. It is always fascinating and inspiring to see how much work some Open Source communities do to get the tool of their choice into its best shape.

Afterwards a platform for open discussion was provided so people could share more knowledge, learn from each other and get new ideas and optimization hints for their own environment. Stay tuned to get to know what Open Source project the our next OSCamp will focus on!

Julia Hornung

Autor: Julia Hornung

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