Fundamentals for Puppet Goes Public

Heute geben wir bekannt, dass nach Veröffentlichung der Schulungsunterlagen unserer Foreman Schulung, auch die Unterlagen zum Kurs Fundamentals for Puppet als Github Pages und im Source-Code zum nicht kommerziellen Gebrauch bereit stehen. In den kommenden Wochen und Monaten werden Veröffentlichungen zu den weiterführenden Puppetschulungen folgen.

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.

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.

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.

Der Consultant und die lieben Zertifizierungen II

RHCA
Vielleicht erinnert sich noch jemand an meinen Blogpost bezüglich Zertifizierungen in dem ich angekündigt hatte auch noch den Performance-Tuning-Kurs bei Red Hat besuchen zu wollen. Nach einigem Hin und Her bei der Terminfindung durfte ich diesen nun endlich besuchen. Nach 4 Tagen Kurs die sich um Performance-Tuning und dem Sammeln der notwendigen Daten allgemein, den Tuning-Daemon tuned und das Tuning für verschiedene Workloads drehten, stand auch wieder eine Prüfung für das “Certificate of Expertise” an. Allein das Ziel dieses zu erlangen sorgte dafür, dass die 4 Tage Schulung jeweils aus mehr als 8 Stunden “Unterricht” und 2 Stunden “Nachlernen” bestanden. So tief hatte ich mich schließlich noch nie mit verschiedensten Kernelparametern, ihrer Auswirkung und den Berechnungen dahinter beschäftigt. Um nur ein Beispiel herauszupicken sei hier das Bandwidth delay product (BDP) mit dem so einiges aus den Verbindungen herauszuholen war. Natürlich kann aus einem optimal konfigurierten System nicht mehr viel herausgeholt werden, man spricht von 3-5%, aber das Wissen hilft auch erstmal diesen optimalen Zustand zu erreichen.

Vollgestopft mit diesem Wissen und trotzdem gefühlt vollkommen blank saß ich dann am Freitag in der Prüfung. Wie bei Red Hat üblich war dies eine praktische Prüfung am System. Das heißt man hat einem Pflichtenheft nicht unähnliche Aufgaben, die gelöst werden wollen. Im Gegensatz zu den bisher abgelegten Zertifizierungen hat diese auch viele “theoretische” Aufgaben bei denen Werte, Daten oder Zeiten ermittelt werden müssen, gerade bei diesen tut man sich schwer, wenn man sonst gewohnheitsmäßig ein anderes Werkzeug nutzt. Wer mein 4-stündiges emotionales Auf und Ab während der Prüfung beobachten konnte hatte sicher seine Freude, nach dem ersten Neustart und der Feststellung was nicht funktionierte wie gedacht war ich mir dann auch sicher nicht bestanden zu haben. Doch bereits wenige Stunden später kam das Prüfungsergebnis aus den USA und ich hatte genauso bestanden wie die beiden anderen Teilnehmer.

Zusätzlich zu dem Prüfungsergebnis kam überraschenderweise auch noch eine Mail, die mir zum Erlangen des Titels “Red Hat Certified Architect” gratulierte. Zwar wusste ich dass es mein fünftes “Certificate of Expertise” ist, aber ich hatte die Umstrukturierung so verstanden, dass man mittlerweile 5 bestimmte für die jeweilige Spezialisierung des RHCA wie beispielsweise “Datacenter” oder “Cloud” benötigt. Auch wenn ich überrascht war, freue ich mich nun zu den RHCAs zählen zu dürfen, denn dahinter steckt nicht nur viel erworbenes Wissen sondern auch viel aufgewendete Zeit. Ein Wissen, dass ich gerne an unsere Auszubildenden weitergeben und für unsere Kunden einsetze.

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.

Vom Noob-OS zum IPv4-Router

Dass man die Docker-Alternative LXD ohne große Hürden auch auf Mac OS X betreiben kann, habe ich in meinem letzten Blog-Post bereits detailliert erläutert.

Leider kann ich im Rahmen meiner Arbeit nicht alles in diesen Ubuntu-Containern betreiben. Die Entwicklungsumgebungen für so manche Anwendungen wie z. B. Icinga Web 2 werden mit Vagrant provisioniert und dieses Programm lässt sich nur sehr mühsam an LXD koppeln. Deshalb komme ich nur mit der einen LXD-VM wohl oder übel nicht aus.

Spätestens wenn die anderen VMs (oder deren Container) mit den LXD-Containern kommunizieren müssen, stößt dieses Setup an seine Grenzen… oder?

Das Setup im Detail

Wie auch jeder andere Gewerbebetrieb, in dem keine Schreibmaschinen mehr zum Einsatz kommen, verfügt NETWAYS über ein internes IP-Netz – beispielhaft mit den Host-Adressen 192.0.2.1 – 192.0.2.14. Der Router zum Internet beansprucht für sich die 192.0.2.1 und meinem Arbeitsgerät ist die 192.0.2.2 zugeteilt.

Um mit meinen virtuellen Maschinen kommunizieren zu können, teilt meine Workstation sich ein IP-Netz mit ihnen (192.0.2.17 – 192.0.2.30). Und schließlich sollen auch meine LXD-Container nicht so isoliert sein wie ein Schreibmaschinen-Nutzer – deshalb teilen sie sich ein wieder anderes IP-Netz (192.0.2.33 – 192.0.2.46) mit der LXD-VM.

Wenn nun ein Knoten einen anderen ansprechen will, muss er entweder im selben IP-Netz sein wie der gewünschte Gesprächspartner – oder in der Netz-Hierarchie unter einem Router stehen, der den gewünschten Gesprächspartner erreichen kann.

Beispiel #1

LXD-Container #1 will mit 192.0.2.50 kommunizieren, ist aber nicht im selben Netz. Ihm bleibt nichts anderes, als über sein Standard-Gateway, 192.0.2.33, zu senden und zu hoffen, dass die Verbindung erfolgreich zustande kommt. Die LXD-VM ist aber auch nicht im selben Netz. Daher muss sie sich wiederum auf ihren Standard-Gateway (192.0.2.17) verlassen. Meine Workstation delegiert wiederum an 192.0.2.1 usw.. Und wenn da draußen tatsächlich eine 192.0.2.50 online ist (und alle Internet-Router so rund laufen wie unser Firmen-Gateway) kommt letztendlich die Verbindung erfolgreich zustande.

Beispiel #2

VM #1 will mit 192.0.2.34 kommunizieren, ist aber nicht im selben Netz. Ihr bleibt nichts anderes, als an ihr Standard-Gateway, 192.0.2.17, zu delegieren. Leider weiß Mac OS nichts vom Netz 192.0.2.32/28 und delegiert an unser Firmen-Gateway. Das und alles dahinter kann noch so rund laufen, aber der Zug in Richtung des LXD-Container-Netzes ist längst abgefahren.

Aber ich würde nicht schon gut 3,5 Jahre bei NETWAYS arbeiten wenn ich diese Hürde nicht spielend einfach überwinden könnte. Dazu braucht es nur…

Statische Routen auf Mac OS X

Natürlich könnte ich auch auf jeder VM eine statische Route hinterlegen, aber das wäre zusätzlicher Aufwand bei jeder VM-Erstellung. Sollte darüber hinaus die Anzahl der VMs mit Linux-Containern zunehmen, steigt damit auch mein Aufwand beim Routen-Management nicht zu knapp…

Deshalb ist es langfristig so oder so sinnvoller, alle VMs an die Workstation delegieren zu lassen und diese zum Router zu befördern. Wie praktisch, dass Mac OS X auf 4.4BSD basiert und damit zur *nix-Familie gehört. Damit ist dieses Vorhaben ein Kinderspiel (wenn man weiß wie es geht).

Jetzt aber endlich mal Butter bei die Fische

Schritt 1: Konzentration!

Um Mac OS die gewünschten statischen Routen beizubringen, muss man tiefer ins System eingreifen, als es ein durchschnittlicher Mac-Nutzer es gewohnt ist. Dabei lässt sich mit ein bisschen Schusseligkeit sehr viel kaputt machen. Wenn Du gerade z. B. eine ordentliche Portion G&T konsumiert hast… habe Geduld. Morgen ist auch noch ein Tag und Mac OS läuft schon nicht weg.

Schritt 2: Root-Rechte

Obwohl Mac OS sich an weniger versierte Nutzer richtet, bietet es die Möglichkeit, Root-Rechte zu erlangen wie man das von verbreiteten GNU/Linux-Distributionen kennt:

Alexanders-MacBook-Pro:~ aklimov$ sudo -i
Password:
Alexanders-MacBook-Pro:~ root#

Schritt 3: Hilfs-Skripte

Die eben erlangten Privilegien berechtigen uns, Skripte in dem OS vorbehaltene Verzeichnisse zu platzieren – wovon wir auch Gebrauch machen, indem wir zunächst das Verzeichnis /usr/local/sbin erstellen und darin zwei Skripte ablegen:

Alexanders-MacBook-Pro:~ root# mkdir -p /usr/local/sbin
Alexanders-MacBook-Pro:~ root# vim /usr/local/sbin/add-static-route.pl
Alexanders-MacBook-Pro:~ root# chmod 0755 /usr/local/sbin/add-static-route.pl
Alexanders-MacBook-Pro:~ root# vim /usr/local/sbin/add-static-routes.sh
Alexanders-MacBook-Pro:~ root# chmod 0755 /usr/local/sbin/add-static-routes.sh

Das erste Skript, /usr/local/sbin/add-static-route.pl, dient dem Hinzufügen von statischen Routen, sobald die entsprechende Netzwerk-Schnittstelle online ist:

#!/usr/bin/perl

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

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

if (!(defined($destination) && defined($gateway))) {
    exit 2 # RTFM at https://wp.me/pgR2o-rlj
}


my $gatewayDec = ip4_2dec($gateway);

POLL: for (;;) {
    for (`/sbin/ifconfig`) {
        if (/^\tinet (.+?) netmask (.+?) /) {
            my $mask = hex($2);
            if (($gatewayDec & $mask) == (ip4_2dec($1) & $mask)) {
                my $status = system("/sbin/route", "add", "-net", $destination, $gateway) >> 8;
                die "/sbin/route: $status" if ($status != 0);
                last POLL
            }
        }
    }

    sleep 1
}


sub ip4_2dec
{
    hex(join("", map({ sprintf("%02x", $_) } split(/\./, shift()))))
}

Das zweite Skript, /usr/local/sbin/add-static-routes.sh, ruft das erste Skript auf und fügt damit konkrete Routen hinzu:

#!/bin/bash

set -e
set -o pipefail

/usr/local/sbin/add-static-route.pl 192.0.2.32/28 192.0.2.18

Die Kommandozeilen-Schnittstelle des ersten Skripts habe ich extra so gestaltet, dass die Routen-Liste (das zweite Skript) möglichst einfach erweitert werden kann. Wenn bspw. eine zweite LXD-VM mit der IP-Adresse 192.0.2.21 dazukommt und mit ihren Containern über das Netz 192.0.2.64/28 verbunden ist, gehört folgende Zeile ans Ende der Routen-Liste:

/usr/local/sbin/add-static-route.pl 192.0.2.64/28 192.0.2.21

Schritt 4: Autostart

Damit das zweite Skript nicht bei jedem Systemstart manuell ausgeführt werden muss, lassen wir Mac OS es für uns automatisch starten:

Alexanders-MacBook-Pro:~ root# pushd /Library/LaunchDaemons
/Library/LaunchDaemons ~
Alexanders-MacBook-Pro:LaunchDaemons root# vim mystaticroutes.plist
Alexanders-MacBook-Pro:LaunchDaemons root# launchctl load mystaticroutes.plist

Inhalt von mystaticroutes.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>Label</key>
    <string>MyStaticRoutes</string>
    <key>ProgramArguments</key>
    <array>
      <string>/usr/local/sbin/add-static-routes.sh</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
  </dict>
</plist>

Fazit

Obwohl mich die Kollegen aus den eigenen Reihen – aber auch aus NMS und PS – spätestens seit diesem Blogeintrag mit besorgten Blicken überschütten, werde ich einfach nicht müde, das Noob-OS von Apple auf biegen und brechen meinen seltsamen Bedürfnissen entsprechend aufzubohren.

Abonniert gerne kostenlos diesen Blog um auch über die nächste Runde informiert zu werden – wenn ich den abgebissenen Apfel bis auf den Kern schäle…

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.

Shopware Update

Jeder nutzt für seine Dienste die verschiedensten Tools. Wir bei NETWAYS kümmern uns im Hosting Bereich für Sie um eben diese Dienste und Tools, sodass Sie als User sich damit nicht beschäftigen müssen.
In diesem Rahmen betreuen wir auch Shopware Installationen unserer Kunden.
Jedoch wollen derartige Dienste auch Updates um aktuell zu bleiben. Ein Shopware Update ist meist nichts großes. Dennoch gibt es hier auch nicht nur eine Variante, wie diese am besten durchzuführen sind. Die Variante die für mich die “beste” ist, möchte ich hier kurz vorstellen.


Schritt 1

Zunächst benötigt man das Paket des jeweiligen Updates. Diese können hier heruntergeladen werden. Im Anschluss kurz entpacken und schon kann es los gehen. Wichtig hierbei ist, dass die Dateien des Updates, die Dateien der Shopware Installation überschreiben.

Deswegen: Ein Backup rettet manchmal jeden Admin! Dies gilt auch für die DB, da diese ebenfalls bearbeitet wird.

Schritt 2
Das Update einspielen.

root@shopware:/tmp# cp -a -R /tmp/update_5/update_5/* /var/www/shopware_directory

Schritt 3
Im Endeffekt war es das auch schon. Unter http://shopware-test.meinedomain.com/recovery/update kann nun das Update gestartet werden. Hier passiert bis auf einige wenige Klicks alles automatisch. Nach dem erfolgreichen Update, muss noch ein Ordner gelöscht werden, sodass das System wieder freigegeben wird.

root@shopware:/var/www/shopware_directory# rm -rf /update-assets

Nun sind keine weiteren Schritte mehr nötig. Auf Fehlermeldungen muss natürlich individuell eingegangen werden. Sollten Sie hierbei auf Probleme stoßen oder möchten ebenfalls eine Umgebung aufbauen, können Sie gerne Kontakt zu uns aufnehmen.

Marius Gebert

Autor:

Marius ist seit September 2013 bei uns beschäftigt. Er hat im Sommer 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und kümmert sich nun um den Support unserer Hostingkunden. Seine besonderen Themengebiete erstrecken sich vom Elastic-Stack bis hin zu Puppet. Auch an unserem Lunchshop ist er ständig zu Gange und versorgt die ganze Firma mit kulinarischen Köstlichkeiten. Seine Freizeit verbringt Marius gern an der frischen Luft und wandert dabei durch die fränkische Schweiz