Vom Noob-OS zum IPv6-Router

Eigentlich habe ich in meinem letzten Blog-Post angekündigt, diesmal “den abgebissenen Apfel bis auf den Kern” zu schälen. Aber gerade als ich alle Vorbereitungen dafür abgeschlossen hatte, erinnerte mich ein außergewöhnlich religiöser Kollege (der an dieser Stelle nicht namentlich genannt werden möchte) daran, was Adam und Eva damals widerfahren ist, nachdem sie vom selbigen Apfel “nur” abgebissen hatten. Ein Risiko von solchem Kaliber für einen einzigen Blogpost einzugehen, wäre einfach nur unverhältnismäßig. Deshalb beschränke ich mich in diesem Beitrag darauf, dem Skript vom letzten mal IPv6-Unterstützung zu verleihen.

Bestandsaufnahme

Weder die Topologien der Netzwerke, noch die damit einhergehenden Probleme haben sich seit dem letzten Beitrag geändert. Das Setup wurde “lediglich” auf IPv6 umgestellt – schließlich wird man in Zukunft über die Nutzung von IPv4 wahrscheinlich ähnlich wertend reden wie heute über die Nutzung von Schreibmaschinen. Das Problem besteht darin, dass eine VM im Netz 2001:db8::192.0.2.16/124 nicht ohne weiteres mit Containern im Netz 2001:db8::192.0.2.32/124 kommunizieren kann, da sie nicht weiß, dass letztgenanntes Netz hinter der VM 2001:db8::192.0.2.18 liegt. Um dieses Problem zu beheben, kann man entweder jeder einzelner betroffener VM diesen Weg beizubringen – oder man nutzt…

Statische IPv6-Routen auf Mac OS X

Leider ist dies etwas schwieriger, als die Einrichtung von IPv4-Routen – zumindest wenn die VMs mit Parallels betrieben werden. Dem Host wird nämlich die IP 2001:db8::192.0.2.17 nicht automatisch zugewiesen. Und es gibt anscheinend keine Möglichkeit, dies über die Netzwerkeinstellungen dauerhaft zu ändern.

Dann eben durch die Hintertür…

Das zuletzt bereits angelegte Skript /usr/local/sbin/add-static-routes.sh, das beim Systemstart automatisch ausgeführt wird (siehe letzten Blogbeitrag), kann für diesen Zweck mitgenutzt werden, indem man am Ende folgende Zeile hinzufügt:

/usr/local/sbin/assign-inet6-address.pl "$(/usr/local/sbin/get-iface-by-inet-address.pl 192.0.2.17)" 2001:db8::192.0.2.17/124

Alle Skripte, die nicht im letzten Blogpost auftauchen stehen am Ende dieses Blogposts. Die konkreten Daten sind nicht aus der Luft gegriffen, sondern müssen mit den Parallels-Netzwerkeinstellungen übereinstimmen – wobei die Adresse der Netzwerk-Schnittstelle “Subnetz + 1” sein sollte:

2001:db8::c000:210 + 1 = 2001:db8::c000:211 = 2001:db8::192.0.2.17

Zurück zu der Route

Nach der eben vollendeten Überwindung der Parallels-Hürde steht der Eigentlichen statischen Route nichts mehr im Wege. Diese wird einfach in /usr/local/sbin/add-static-routes.sh mit aufgenommen:

/usr/local/sbin/add-static-route6.pl 2001:db8::192.0.2.32/124 2001:db8::192.0.2.18

Diese Route tritt spätestens nach einem Neustart in Kraft. Mangels Geduld kann man auch die zwei hinzugefügten Zeilen direkt auf der Kommandozeile ausführen:

# bash
bash-3.2# /usr/local/sbin/assign-inet6-address.pl "$(/usr/local/sbin/get-iface-by-inet-address.pl 192.0.2.17)" 2001:db8::192.0.2.17/124
bash-3.2# /usr/local/sbin/add-static-route6.pl 2001:db8::192.0.2.32/124 2001:db8::192.0.2.18

Fazit

“Warum extrem einfach wenn es auch unnötig kompliziert geht?” Diesem Motto werde ich auch weiterhin treu bleiben – also stay tuned!

Skripte

/usr/local/sbin/get-iface-by-inet-address.pl

#!/usr/bin/perl 

# (C) 2017 NETWAYS GmbH | GPLv2+
# Author: Alexander A. Klimov

my $inet_addr = shift;

exit 2 if ! defined $inet_addr; # RTFM at https://wp.me/pgR2o-rur


my $iface;
$inet_addr = quotemeta($inet_addr);

POLL: for (;;) {
	for (`/sbin/ifconfig`) {
		if (/^(\S+?): /) {
			$iface = $1
		} elsif (defined($iface) && /^\tinet $inet_addr /) {
			print $iface;
			last POLL
		}
	}

	sleep 1
}

/usr/local/sbin/assign-inet6-address.pl

#!/usr/bin/perl 

# (C) 2017 NETWAYS GmbH | GPLv2+
# Author: Alexander A. Klimov

my $iface = shift;
my $inet6_addr = shift;

exit 2 if !(defined($iface) && defined($inet6_addr) && $inet6_addr =~ m~^(.+)/(\d+)$~); # RTFM at https://wp.me/pgR2o-rur


my $status = system("/sbin/ifconfig", $iface, "inet6", $1, "prefixlen", $2) >> 8;
die "/sbin/ifconfig: $status" if ($status != 0)

/usr/local/sbin/add-static-route6.pl

#!/usr/bin/perl 

# (C) 2017 NETWAYS GmbH | GPLv2+
# Author: Alexander A. Klimov

my $destination = shift;
my $gateway = shift;

exit 2 if !(defined($destination) && defined($gateway) && $destination =~ m~^(.+)/(\d+)$~); # RTFM at https://wp.me/pgR2o-rur


$destination = $1;
my $destination_prefixlen = $2;
my $gatewayBin = ip6adr2bin($gateway);

POLL: for (;;) {
	for (`/sbin/ifconfig`) {
		if (/^\tinet6 (.+?)(?:%\S+)? prefixlen (\d+)/) {
			if (ip6bin2prefix($gatewayBin, $2) eq ip6bin2prefix(ip6adr2bin($1), $2)) {
				my $status = system("/sbin/route", "add", "-inet6", "-prefixlen", $destination_prefixlen, "-net", $destination, $gateway) >> 8;
				die "/sbin/route: $status" if ($status != 0);
				last POLL
			}
		}
	}

	sleep 1
}


sub ip6adr2bin
{
	my $raw = shift;

	if ($raw =~ /::/) {
		my ($head, $tail) = split(/::/, $raw);
		$head = ip6part2bin($head);
		$tail = ip6part2bin($tail);

		return $head . ("0" x (128 - (length($head) + length($tail)))) . $tail
	}

	ip6part2bin($raw)
}

sub ip6bin2prefix
{
	my $addr = shift;
	my $prefixlen = shift;

	substr($addr, 0, $prefixlen) . ("0" x (128 - $prefixlen))
}

sub ip6part2bin
{
	join("", map({ /\./ ? join("", map({ sprintf("%08b", $_) } split(/\./, $_))) : sprintf("%016b", hex($_)) } split(/:/, shift())))
}
Alexander Klimov

Autor: Alexander Klimov

Alexander hat 2017 seine Ausbildung zum Developer bei NETWAYS erfolgreich abgeschlossen. Als leidenschaftlicher Programmierer und begeisterter Anhänger der Idee freier Software, hat er sich dabei innerhalb kürzester Zeit in die Herzen seiner Kollegen im Development geschlichen. Wäre nicht ausgerechnet Gandhi sein Vorbild, würde er von dort aus daran arbeiten, seinen geheimen Plan, erst die Abteilung und dann die Weltherrschaft an sich zu reißen, zu realisieren - tut er aber nicht. Stattdessen beschreitet er mit der Arbeit an Icinga Web 2 bei uns friedliche Wege.

Foreman-Training nun auch mit Ansible und Monitoring-Integration

English version below
Foreman-Logo

Es ist nun bald anderthalb Jahre her, dass ich die Trainingsunterlagen veröffentlichen durfte, die in Zusammenarbeit mit dem Foreman-Projekt und dort auch als offizielles Training aufgeführt sind. In der Zeit hat sich im Projekt selbst aber auch vor allem an den Plugins viel getan. Auch konnte Feedback in offiziellen und Inhouse-Schulungen sowie Workshops gesammelt werden. Um dem Rechnung zu tragen versuche ich die Schulung regelmäßig zu aktualisieren und zu erweitern.

Foreman training presentation

Nachdem es sich bei dem Update diesmal um ein größeres handelt, dachte ich mir, ich fasse es mal in einem Blogpost zusammen. Diesmal habe ich es gewagt und statt wie bisher auf eine bereits länger veröffentliche Version auf den Release Candidate für 1.16 gesetzt, da mit diesem Support für Puppet 5 kommt. Auch wenn ich nicht über den höheren Ressourcenbedarf von Puppet 5 begeistert bin, da er deutlich höhere Anforderungen an unsere Schulungsnotebooks stellt, war es auch Zeit der Entwicklung hier Rechnung zu tragen und somit ist in den Schulungen ab sofort Puppet 5 der Standard. Wenn ich gerade von Konfigurationsmanagement rede, kann ich auch gleich die erste große Neuerung präsentieren und zwar ist nun auch die Ansible-Integration Teil der Schulung. Dies ist dem Interesse geschuldet, das sich sowohl in Anfragen in allen Bereichen bei NETWAYS, dem Interesse der Kollegen und auf den Foreman-Mailinglisten sowie auf dem Foreman-Geburtstag gezeigt hat.

Die zweite große Erweiterung ist die Monitoring-Integration, auf die ich persönlich sehr stolz bin. Allein in die Vorbereitung der Übung floss hier einiges an Zeit um den Schulungsteilnehmern ein möglichst gutes Trainingserlebnis zu gewährleisten. Den Neuerungen im OpenSCAP-Plugin wurde mit einer optionalen Übung Rechnung getragen. Optional damit es keine Zeit frisst, wenn bei Schulungsteilnehmern kein Bedarf besteht, aber gerade mit den Tailoring-Files lässt sich eine OpenSCAP-Policy sehr gut und einfach auf den eigenen Bedarf anpassen. Bereits beim letzten Update hatte ich das Plugin “Expire Hosts” hinzugefügt, da ich in vielen Kundenumgebungen entsprechende Anforderungen ausmachen konnte. Leider musste ich das ABRT-Plugin zumindest temporär rausnehmen, da dieses erst aktualisiert werden muss um wieder mit Foreman bzw. dem Smart-Proxy kompatibel zu sein.

(more…)

Dirk Götz

Autor: Dirk Götz

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Nagios, Puppet 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.

Monthly Snap September > SensorProbe 2+, Icinga Director, OSBConf 2017, DevOpsDays, Benchmarking Graphite, OSMC

In September, Isabel started with introducing Intelligente Überwachung mit der AKCP sensorProbe 2+ while Eric shared his tips on Hidden pearls in Icinga Web 2. Nicole shared important information on NETWAYS Web Services on Request Tracker.

Marius told us how VM volumes live works using blkdeviotune and Shopware Update, Julia announced for new upcoming Advanced Puppet training and 7 reasons for join OSBConf. Markus shared Trick 17 with the Icinga Director while Tobias shared Trick 42 with the Icinga Director – Job in order.

Julia Announced OSMC in Hackathon, DevOpsDays in Berlin and continued with reasons for OSBConf 2017,she also  said thank to sponsors of OSBConf.

Blerim told us about Benchmarking Graphite, Nicole reviewed Managed Services team event 2017, And Dirk again shared his insights in The Consultant and The dear Certifications II.

Keya Kher

Autor: Keya Kher

Keya hat im Oktober ihr Praktikum im Marketing bei NETWAYS gestartet. Letzten Dezember startete Sie gemeinsam mit Ihrem Mann das “Abenteuer Deutschland”. Seitdem lernt Sie fleißig deutsch und fühlt sich bei NETWAYS schon jetzt pudelwohl. Sie hat schon viele Erfahrungen im Social Media Marketing und ist gerade dabei auch im Grafikdesign ein Profi zu werden. Wenn sie nicht gerade dabei ist, sich kreativ auszuleben, entdeckt sie die Stadt und schmökert gerne im ein oder anderen Büchlein. Ihr Favorit ist hierbei “The Shiva Trilogy”.

Systemd-Unitfiles kurz erklärt

Tux
Nachdem ich feststellen musst, dass immer noch der ein oder andere mit Systemd und den Unitfiles auf Kriegsfuß steht und mit tieferem Wissen manches Problem zu vermeiden wäre, will ich mit ein paar kurzen Erklärungen Abhilfe schaffen.

Systemd hat als Ersatz für init bereits 2010 angefangen in die verschiedenen Distributionen Einzug zu halten und ist mittlerweile Standard. Somit haben auch die alten init-Skripte ausgedient und wurde durch Unitfiles ersetzt. Auf den ersten Blick lassen diese weniger Optionen zu, aber sobald man sich etwas weiter mit den Einstellmöglichkeiten auseinandersetzt, wird man wohl nichts an Funktionalität vermissen.

Für die Erläuterungen möchte ich ein Beispiel nehmen, dass vielleicht der ein oder andere schon kennt, und habe mich darum für Icinga 2 entschieden. Dieses findet sich in /usr/lib/systemd/system als icinga2.service und sieht folgendermaßen aus:

[Unit]
Description=Icinga host/service/network monitoring system
After=syslog.target network-online.target postgresql.service mariadb.service carbon-cache.service carbon-relay.service

[Service]
Type=forking
EnvironmentFile=/etc/sysconfig/icinga2
ExecStartPre=/usr/lib/icinga2/prepare-dirs /etc/sysconfig/icinga2
ExecStart=/usr/sbin/icinga2 daemon -d -e ${ICINGA2_ERROR_LOG}
PIDFile=/run/icinga2/icinga2.pid
ExecReload=/usr/lib/icinga2/safe-reload /etc/sysconfig/icinga2
TimeoutStartSec=30m

[Install]
WantedBy=multi-user.target

Als erstes möchte ich auf den Pfad selbst eingehen. Diese muss per Konvention heißen wie der Service, der über sie gesteuert wird, und auf .service enden, damit sie von anderen Units unterscheidbar ist. Andere Units wären beispielsweise Sockets für die socketbasierende Aktivierung oder Targets als Gruppierung von Services und Ersatz für die Runlevel. Der Pfad /usr/lib/systemd/system ist hierbei der Ablageort für Package-Maintainer und kann mit Dateien in /run/systemd/system oder /etc/systemd/system überschrieben werden, wobei letzteres für den Administrator gedacht ist.

Die Datei selbst ist dann im Ini-Format, heißt es gibt verschiedene Sektion wie [Unit] und Key-Value-Paare, die in der entsprechenden Sektion sein müssen. In der Sektion [Unit] finden sich somit allgemeine Einstellungen die bei jedem Unit-Typen vorkommen können, in diesem Fall die Beschreibung und mit After eine Liste von Units, die wenn vorhanden vor Icinga 2 gestartet sein sollen. Die Manpage systemd.unit gibt hierüber detailliert Auskunft.

In der für den Unit-Typ spezifischen Sektion in unserem Fall [Service] werden dann weitere Einstellungen vorgenommen. Hier wird Systemd gesagt wie das Startverhalten des Dienstes ist denn standardmäßig möchte Systemd Dienste im Vordergrund starten im Gegensatz zum Standardverhalten von init bei dem sich der Dienst in den Hintergrund forkt. Über EnvironmentFile, zusätzliche Skripte in ExecStartPre oder ExecStartPost und den eigentlich Aufruf des zu startenden Dienst mittels ExecStart wird das frühere init-Skript abgelöst. In Fall von Icinga2 wird im Pre-Skript sichergestellt, dass benötigte Verzeichnisse existieren und entsprechend berechtigt sind. Zusätzlich wird der Reload-Mechanismus durch ein Skript ersetzt, damit die Konfiguration validiert wird bevor gegebenenfalls der Dienst neugestartet wird. TimeoutStartSec ist prinzipiell selbsterklärend denk ich, nimmt im Gegensatz zu den Sekunden im Namen aber auch andere Einheiten an wie hier 30m für 30 Minuten. Hierbei bitte aufpassen, dass nur der Start-Timeout und nicht der allgemeine Timeout hochgesetzt wird, da letzterer auch für den Shutdown des Systems gilt. Mehr Details liefert die Manpage systemd.service.

Die letzte Sektion gibt an in welches Target der Dienst “installiert” werden soll, wenn systemctl enable ausgeführt wird.

Die Datei unter /usr/lib/systemd/system sollte nicht angepasst werden, da diese beim nächsten Update überschrieben wird. Kopiert man es aber nach /etc/systemd/system muss man die komplette Pflege übernehmen, da es das aus dem Paket gelieferte komplett ersetzt. Hierfür gibt es den Mechanismus der Drop-Ins. Diese müssen in ein Verzeichnis mit dem Namen der Unit abgelegt werden, in unserem Fall /etc/systemd/system/icinga2.service.d und auf .conf enden. Der Name ist hierbei prinzipiell egal, sollte aber sprechend gewählt werden und da sich Eigenschaften überschreiben bietet sich eine Priorität als Präfix an. Beim Inhalt nicht die Sektionsheader vergessen! Auch hierfür ein Beispiel aus Icinga 2:

# Icinga 2 sets some default values to extend OS defaults
#
# Please refer to our troubleshooting documentations for details
# and reasons on these values.
[Service]
TasksMax=infinity

# May also cause problems, uncomment if you have any
#LimitNPROC=62883

Mit dem Kommando systemctl property kann man genau diesen Mechanismus nutzen ohne sich um die Dateistruktur kümmern zu müssen, aber leider funktioniert dies nicht für alle Optionen. Kernel-Parameter, Posix-Limits und vieles mehr lassen sich hier einstellen, welche sich in systemd.exec finden, und Einstellungen für die Kontrolle über Ressourcen, welche Systemd mittels Cgroups umsetzt, finden sich in systemd.resource-control. Die Defaults hierfür finden sich übrigens in /etc/systemd/system.conf und müssen nicht immer gleich heißen, beispielsweise DefaultTasksMax und TasksMax. Die eingebundenen Drop-Ins zeigt systemctl status sehr schön an und die aktuellen Werte für alle Einstellungen eines Services inklusive Defaults liefert systemctl show.

Und abschließend nicht vergessen Systemd die vorgenommenen Änderungen mit systemctl daemon-reload auch mitzuteilen.

Ich hoffe diese kleine Erläuterung hilft dem ein oder anderen Unitfiles besser zu verstehen und er weiß nun wo er hin langen muss wenn Stellschrauben anzupassen sind.

Dirk Götz

Autor: Dirk Götz

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Nagios, Puppet 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.

NETWAYS stellt sich vor – Riccardo Gringer

This entry is part 33 of 33 in the series Mitarbeitervorstellung

Name: Riccardo Gringer

Alter: 19

Position bei NETWAYS: Junior Developer

Was genau gehört zu Deinem Aufgabenbereich bei NETWAYS?

Momentan arbeite ich mich noch in Icinga 2 und Icinga Web 2 ein und werde damit in der Zukunft arbeiten. Natürlich gibt es etliche kleinere Nebenprojekte die auch bearbeitet werden müssen.

An welchen Projekten arbeitest Du gerade?

Zur Zeit bin ich wie schon gesagt noch an einer Einarbeitungsphase. Das heißt ich versuche mich in die verschiedenen Programme und Projekte einzuarbeiten um einen Überblick über alles zu bekommen. Aktuell sind das Icinga 2 und Icinga Web 2.

Was macht Dir an Deiner Arbeit am meisten Spaß?

Ich glaube am meisten Spaß macht bis jetzt das tüfteln an einer Lösung für ein Problem. Bei jedem Problem gibt es Kleinigkeiten die anders behandelt werden müssen. Es gibt ja schließlich nicht immer eine Lösung die man immer anwenden kann!

Was machst Du, wenn Du mal nicht bei NETWAYS bist?

Meine Freizeit verbringe ich zu (nahezu) gleichen Teilen mit meinen Katzen (2 Perser), meinem Heimkino und dem zocken. Das Heimkino ist dabei ein Langzeitprojekt seit mehreren Jahren. Natürlich verbringe ich an Wochenenden auch viel Zeit mit Freunden, vor allem zur Kerwazeit ;).

Wie geht es in Zukunft bei Dir weiter?

Die Ausbildung wird in den nächsten drei Jahren die größte Aufmerksamkeit bekommen. Schließlich muss ich außerhalb der Arbeitszeiten noch für die Berufsschule lernen und Hausaufgaben machen. Natürlich versuche ich während der Ausbildung so viel wie möglich zu lernen und mitzunehmen um danach erfolgreich als Developer arbeiten zu können.

 

Riccardo Gringer

Autor: Riccardo Gringer

Riccardo hat bei NETWAYS sein Praktikum im Development gestartet. In seiner Freizeit bastelt er mit Feuereifer an einem Heimkino und kümmert sich nebenbei darum, dass sich seine zwei Perserkatzen nicht langweilen. Außerdem schaut er gerne Filme, liest viel und spielt natürlich auch gerne Computer. Für seine Zeit bei NETWAYS wünscht er sich, sein Praktikum und seine Ausbildung erfolgreich zu bestreiten und dabei selbstverständlich auch genug Spaß und Freude mit den Kollegen zu haben!

Puppet 5 – how new is that!

This entry is part 1 of 1 in the series Puppet 5


Have you heard? In July this year Puppet released its’ new software stack of the agent, server and db package to manage, control and orchestrate your IT infrastructure. Enough time has passed for us to test, upgrade and implement it in our environment. With this series we want to introduce some of the new features and inform you about the tasks you need to know or be aware of should you wish to upgrade.

Let us start with the basic changes in the new version. These are for example the switch from PSON to JSON encoding if the agent downloads his information, catalogues or metadata. This will help you to better integrate Puppet in your setup when it needs to communicate with other tools. You can also see an improved performance in handling facts and reports, especially when it matters to process larger quantities.

Another point to mention is the usage of the newer Ruby in version 2.4. Since version 4, Puppet ships all it needs in its’ packages, so you need to reinstall your manually added Puppet agent gems.

And the last point for today should be the version numbering of the new packages. Puppet focuses on keeping all major versions of agent, server and db in one counter and follows the Semantic Versioning as closely as possible. Which is one of the reason for the huge jump in the Puppet server version.

Stay tuned to learn more. And if you need further help or want to learn more about Puppet take a look at our products or training course .

Ronny Biering

Autor: Ronny Biering

Vor NETWAYS arbeitete Ronny bei einem der großen deutschen Internet- und Hosting Provider. Hier betreut er zusammen mit seinen Kollegen aus dem Bereich Managed Services die Plattformen unserer Kunden. Im Gegensatz zu dem üblichen Admin-Cliche, gehört Fitness zu einer seiner Lieblingsfreizeitbeschäftigung.