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.

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.

VM Volumes live anpassen mittels blkdeviotune

This entry is part 2 of 2 in the series Cloud Management

Wir bei NETWAYS setzen für das erstellen von VMs bestimmte Templates ein. In diesen Templates sind alle möglichen Konfigurationen hinterlegt. Unter anderem auch für die VM Volumes. Doch nicht immer passen diese Konfigurationen und so sind einzelne Anpassungen an der laufenden VM nötig. Mittels “blkdeviotune” ist man als Admin in der Lage, live die Volume-Daten der VMs zu bearbeiten.
Hierzu begibt man sich mittels “virsh” in das dazugehörige Terminal.

root@virt-system:~# virsh
Welcome to virsh, the virtualization interactive terminal.
Type: 'help' for help with commands
'quit' to quit
virsh # list
Id Name State
----------------------------------------------------
01 one-1000 running
02 one-1001 running
03 one-1002 running
04 one-1003 running

In diesem Terminal hat man verschiedene Parameter die man anpassen kann. Welche verfügbar sind, kann man wie folgt anzeigen lassen. Hierbei wird die ID aus obigen Kommando benötigt:

virsh # blkdeviotune 02 vda
total_bytes_sec: 62914560
read_bytes_sec : 0
write_bytes_sec: 0
total_iops_sec : 500
read_iops_sec : 0
write_iops_sec : 0

Folglich ist hier die Möglichkeit gegeben, oben genannte Parameter anzupassen. Ob man hier nun die Limitierungen der IOPs und die “Bytes per second” bezüglich “read” und “write” unterscheidet, oder ob man einen totalen Wert angibt, bleibt jedem Admin selbst überlassen. In diesem Beispiel hat die VM mit der OpenNebula ID “one-1001” Limitierungen auf die Parameter “total_bytes_sec” und “total_iops_sec“. Die anderen Werte sind hier unlimitiert, jedoch werden sie durch den übergeordneten Parameter beschränkt. Wenn man die Werte nun entsprechend seiner Wünsche anpassen möchte, ist es wie im folgenden Beispiel wichtig, alle Werte mit anzugeben, auch wenn sie nicht verändert werden sollen. Als Beispiel wird hier nun der Parameter “total_bytes_sec” auf 0 zurück gesetzt und einzelne Limitierungen für die Werte “read_bytes_sec” und “write_bytes_sec” gesetzt. Ebenso werden die maximal zulässigen IOPs erhöht.

virsh # blkdeviotune 02 vda 0 31457280 31457280 1000 0 0
virsh # blkdeviotune 02 vda
total_bytes_sec: 0
read_bytes_sec : 31457280
write_bytes_sec: 31457280
total_iops_sec : 1000
read_iops_sec : 0
write_iops_sec : 0

Derartige Änderungen können live geschehen und benötigen keine weiteren Aktionen innerhalb der VMs. Wir bei NETWAYS reagieren so zum Beispiel auf temporäre Mehrauslastungen einzelner VMs.

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

Cloud Management – Teil 1: blkdeviotune/migrate-setmaxdowntime

This entry is part 1 of 2 in the series Cloud Management

Viele von euch haben bestimmt schon einmal von OpenNebula oder OpenStack gehört, beiden Plattformen verwenden standardmäßig libvirtd als Hypervisor, da jedoch die darunter liegende Hardware mit unter stark beansprucht werden wird, vor allem im Cloud Bereich, wo mehrerer KVM Instanzen auf einem Virt Host um CPU/Speicher/IO Resourcen konkurrieren, ist es gelegentlich notwendig die einen oder andere Instanz zu bändigen bzw. in die Schranken zu weisen.

Unsere Cloud läuft derzeit noch mit OpenNebula, wir selbst sind sehr zufrieden mit dem Stack, da sich dieser leicht Verwalten lässt und sich auch gut mit unserem Ceph als Backend verträgt, natürlich verwenden wir in unserem Cloud Stack noch andere Tools, diese sind aber nicht Gegenstand dieses Artikels, mehr dazu in späteren Teilen der Serie.

Libvirtd kann mit CLI Tools wie virsh gesteuert werden, auch besteht die Möglichkeit libvirtd über die entsprechende libvirt C API oder durch seine ScriptLanguage Bindings für ruby/python/perl/javascript/etc… anzusprechen bzw. anzusteuern zu können.

So beispielsweise unterstützt man OpenNebula wenn die Migration einer KVM Instanz von Virt Host A zu Virt Host B aufgrund von Last auf der Instanz selbst partout nicht klappen will…

root@virt1: ~ $ virsh migrate-setmaxdowntime --downtime 1800 one-8366
error: Requested operation is not valid: domain is not being migrated (dieser Fehler kommt nur wenn sich die Instanz nich im Status Migrate befindet, ist hier also nur exemplarisch mit abgebildet)

…oder wenn die Instanz AMOK läuft und somit andere Instanzen zu stark beeinträchtigt…

root@virt1: ~ $ virsh blkdeviotune one-8366 vda --live
total_bytes_sec: 62914560
read_bytes_sec : 0
write_bytes_sec: 0
total_iops_sec : 400
read_iops_sec  : 0
write_iops_sec : 0

…dann limitieren wir diese einfach ein bisschen…

root@virt1: ~ $ virsh blkdeviotune one-8366 vda --live 62914560 0 0 200 0 0

…und vergewissern uns nochmal ob unsere neuen IOPs Limits übernommen wurden…

root@virt1: ~ $ virsh blkdeviotune one-8366 vda --live
total_bytes_sec: 62914560
read_bytes_sec : 0
write_bytes_sec: 0
total_iops_sec : 200
read_iops_sec  : 0
write_iops_sec : 0

…ich denke, damit sollte klar sein worauf wir hier abzielen möchten.

In folgenden Teilen dieser Serie werden wir euch noch mehr Tips & Tricks mit auf den Weg geben, die helfen sollen eure Cloud zu bändigen bzw. aufkommende Probleme anzugehen, also bleibt gespannt. 😉

Enrico Labedzki

Autor: Enrico Labedzki

Enrico ist beruflich ganz schön rumgekommen – IT hat ihn aber immer beschäftigt. Nach einem Ausflug in die Selbstständigkeit im Bereich Webentwicklung und Network Solutions, wurde es dann Zeit Nägel mit Köpfen zu machen und endlich den Weg als Softwareentwickler und Systemintegrator einzuschlagen. In seiner Freizeit widmet sich der passionierte Bastler der Elektrotechnik und Animatronik. Bei Netways bereichert er mit seinem vielseitigen Know-How das Managed Service-Team.

“Willkommen auf der dunklen Seite der Macht, Alexander …”

Nein, ich meine nicht die antagonistische Fraktion aus einer sehr populären Filmreihe (deren Name nicht genannt werden muss), sondern die Apple-Fraktion bei NETWAYS.

Letzten Monat habe ich nämlich meine Ausbildung zum Fachinformatiker für Anwendungsentwicklung abgeschlossen und wurde in die Development-Abteilung übernommen.

Neuer Status – neues Gehalt, neue Aufgaben … und neues Arbeitsgerät. Ich habe mich bewusst für ein MacBook Pro entschieden, weil auf dieser Plattform sehr vieles viel besser und einfacher funktioniert und ich nicht bei jeder Kleinigkeit erst den Linux-Kernel patchen und neu kompilieren, SELinux abschalten oder die IPTables-Regeln anpassen muss. 😉

Wer weiß wann ich mit dem nächsten Kunden von Angesicht zu Angesicht zu tun haben werde – diesbzgl. will ich keine Risiken eingehen.

Abstriche muss ich keine machen – schließlich bietet MacOS X alles, was das Entwickler-Herz begehrt. Außer vielleicht …

Container

Auf Linux haben sie sich breit gemacht wie ein Türsteher: Docker, LXC, LXD und wie sie alle heißen. Auch BSD macht mit seinen Jails keine Kompromisse in Sachen Virtualisierung und Sicherheit.

Umso mehr wundert es mich, dass das BSD-basierende MacOS X dieses Feature nicht übernommen hat. Aber es wäre kein *nix-System, wenn man das nicht mit ein wenig Geschick nachrüsten könnte …

Dann eben so …

Auf meinem alten Arbeitsgerät habe ich Ubuntu 16.04 verwendet. Diese GNU/Linux-Distribution enthält von Haus aus LXD in den Paketquellen, womit ich in einer leichtgewichtigen und sicher isolierten Umgebung mal schnell was ausprobieren konnte.

Dieses Werkzeug kann ich mit einer Virtuellen Maschine problemlos weiterhin verwenden – nicht nur in der VM selbst, sondern auch vom Mac-Host aus. Genau dafür braucht man das o. g. “wenig Geschick” …

LXD Server einrichten

Man logge sich in die VM ein und erlange Administratorrechte. Dann installiert man LXD und richtet diesen darauf hin ein:

$ sudo -i
(...)
# apt install lxd
(...)
# lxd init
Name of the storage backend to use (dir or zfs) [default=dir]: 
Would you like LXD to be available over the network (yes/no) [default=no]? yes
Address to bind LXD to (not including port) [default=all]: 
Port to bind LXD to [default=8443]: 
Trust password for new clients: 
Again: 
Do you want to configure the LXD bridge (yes/no) [default=yes]?

Fast alle Abfragen des Installations-Assistenten können bedenkenlos mit der Eingabetaste bestätigt werden. Die von mir hervorgehobene Frage allerdings muss mit “yes” beantwortet werden – ansonsten fällt die Nutzung vom Host aus ins Wasser. Außerdem muss ein einigermaßen sicheres Passwort gewählt werden.

Der Frage nach der “LXD bridge” folgt ein weiterer, “pseudo-grafischer” Installations-Assistent. Dessen Fragen kann man ausnahmslos mit der Eingabetaste bestätigen.

Des weiteren wird später die IP der VM benötigt:

# ifconfig
enp0s5    Link encap:Ethernet  HWaddr 00:1c:42:8b:e9:ba  
          inet addr:10.211.55.19  Bcast:10.211.55.255  Mask:255.255.255.0
          inet6 addr: fdb2:2c26:f4e4:0:880a:a527:1a6:1130/64 Scope:Global
          inet6 addr: fdb2:2c26:f4e4:0:fc54:870c:56af:cba0/64 Scope:Global
          inet6 addr: fe80::fbc7:ab4d:d29f:e227/64 Scope:Link
(...)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
(...)

lxdbr0    Link encap:Ethernet  HWaddr 00:00:00:00:00:00  
          inet addr:10.83.127.1  Bcast:0.0.0.0  Mask:255.255.255.0
          inet6 addr: fdb3:61e3:ffb6:f62f::1/64 Scope:Global
          inet6 addr: fe80::4024:c9ff:fe4a:691b/64 Scope:Link
(...)

LXD Client einrichten

Da die Entwickler von LXD sich bemüht haben, nicht von Linux-spezifischen Funktionalitäten Gebrauch zu machen, funktioniert der LXD Client auch auf MacOS. Den muss man nur noch vom LXD Server in Kenntnis setzen.

Sobald das getan ist, kann auch schon der erste Container in Betrieb genommen werden.

$ brew install lxc
(...)
$ lxc remote add u1604vm 10.211.55.19
Certificate fingerprint: a761f551dffdf47d9145da2aa16b4f6be242d960ce1697994c969e495b0724fd
ok (y/n)? y
Admin password for u1604vm:
Client certificate stored at server:  u1604vm
$ lxc launch ubuntu:16.04 u1604vm:test1
Creating test1
Starting test1ge: rootfs: 100% (37.78MB/s)
$ lxc exec u1604vm:test1 -- bash
root@test1:~# man perlfunc

Fazit

Es muss nicht immer Docker sein.

Gerade wenn das Testsystem sich möglichst so verhalten soll wie eine VM oder eine Physische Maschine ist LXD auf jeden Fall einen Blick Wert – auch auf dem Mac.

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 räumt auf

Foreman Logo

Dank Virtualisierung und automatischer Provisionierung sind schnell und einfach Entwicklungs- und Testsysteme zur Verfügung gestellt und jeder bestellt fleißig neue Systeme, aber wie viele melden sich dann wirklich zurück wenn ein System nicht mehr gebraucht wird? Aus meiner Erfahrung heraus möchte ich behaupten die wenigsten tun dies. So kommt es, dass Ressourcen reserviert sind und brach liegen oder schlimmer noch tatsächlich belegt aber nicht mehr wirklich genutzt werden. Manuelle Aufräumaktionen treffen dann entweder zu wenig oder zu viele Systeme und kosten zu viel Zeit und Nerven. Wie schön wäre es wenn man die Kollegen erziehen könnte? Da es mit den Kollegen wohl nicht klappen wird, erziehen wir stattdessen unsere Umgebung und zwar mit dem Plugin “Expire Hosts” für Foreman.

Die Installation übernimmt wie mittlerweile bei fast allen Plugins der Foreman Installer und danach können wir auch direkt konfigurieren wie Systeme zukünftig von diesem Plugin behandelt werden sollen.

Foreman Expire Hosts Settings

Wie man sieht kann man drei Zeiten einstellen und zwar wann die erste und zweite Benachrichtigung relativ zum Ablaufdatum erfolgen soll und nach wie viel Tagen es nach Ablauf gelöscht werden soll nachdem das System am Ablaufdatum heruntergefahren wurde. Außerdem kann eingestellt werden, ob der Besitzer des Systems oder nur der Administrator das Ablaufdatum nachträglich ändern darf und ob die Angabe eine Pflicht ist. Wer dies als Administrator will kann sich auch auf die Liste der zusätzlichen Email-Empfänger setzen, da sonst nur der Besitzer benachrichtigt wird.

Wenn die allgemeinen Einstellungen nun passen erhält jeder Host ein Eingabefeld zur Einstellung seines Ablaufdatums unter den zusätzlichen Informationen.

Foreman Expire Hosts Host

Zusätzlich zur Email-Benachrichtigung zeigt Foreman auch noch im Webinterface den Status an und warnt auch hier vor dem Ablauf.

Foreman Expire Hosts OkForeman Expire Hosts Warning

Zwar ist das Plugin primär für virtuelle Maschinen gedacht, funktioniert aber auch bei physikalischen Systemen. Wenn Foreman das Powermanagement für diese steuern kann, fährt es diese auch herunter. Wenn nicht weiß der Administrator zumindest, dass das System zum Herunterfahren und Löschen freigegeben ist.

Ich denke mal für dieses Plugin finden so einige Administratoren einen sinnvollen Anwendungsfall, weshalb ich es auch neben vielen weiteren Plugins in die Foreman-Schulung aufgenommen habe.

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.