Microsoft and GitHub – merge conflict?

For some time it has become clear that Microsoft is going to take over GitHub. As far as official sources can be trusted, GitHub will stay independent although a new CEO (Nat Friedman) will be introduced after the Microsoft takeover.

This question over GitHub’s future independence has raised a lot of skepticism within the developer community and many are considering moving their projects away from GitHub to a different location.
One alternative in this case could be GitLab. GitLab does not only have an online platform but it can as well be installed on your own hardware. Furthermore, it is an extremely solid piece of Open Source software you can fully rely on. This is also shown by the makers of GitLab themselves as they release updates each month – rolling out bug fixes, security updates and many recommendations regarding the use and configuration of your instance.
For those who would like to have their own GitLab instance, NETWAYS offers two options:
First one is available on our NETWAYS Web Services platform where we offer user-managed, hosted GitLab instances as Community or Enterprise Edition. The user does not need to take care of anything regarding installation or maintenance of his GitLab, but can directly go into production in no time with only a few steps needed. You as a customer are also free to decide for how long you would like to run your instances as any app is monthly callable. Furthermore, we regularly update these container based apps and monitor their health  for you. As a customer, you can register on NWS and try all the apps we offer 30 days for free.
The second product we offer is done by NETWAYS Managed Services which is exactly what it is called: With managed hosting you can get a virtual machine in our cloud or rented hardware running a full GitLab, either as Community or Enterprise Edition. You can choose the underlying ressources and we will do the rest for you, like installation with individual parameters and health monitoring. With managed hosting, our customers also have the choice to go full 24/7 support with “emergency” calls.

Nicole Frosch
Nicole Frosch
Sales Engineer

Ihr Interesse für die IT kam bei Nicole in ihrer Zeit als Übersetzerin mit dem Fachgebiet Technik. Seit 2010 sammelt sie bereits Erfahrungen im Support und der Administration von Storagesystemen beim ZDF in Mainz. Ab September 2016 startete Sie Ihre Ausbildung zur Fachinformatikerin für Systemintegration bei NETWAYS, wo sie vor allem das Arbeiten mit Linux und freier Software reizt. In ihrer Freizeit überschüttet Sie Ihren Hund mit Liebe, kocht viel Gesundes, werkelt im Garten, liest...

Ceph Training opensourced

 
Besides several other trainings, such as gitlab, foreman or graphite/grafana we’re happy to announce our newest member in the NETWAYS OpenSource training community.
You might have guessed it after reading the headline, we’ve published a ceph training.
 

This training is designed as a two days hands-on training introducing Ceph, its basics, cluster setup and many best practices.
The training participants will get an in-depth insight into the Ceph basics and configuration. They also learn about Ceph Cache Tier, Rados Gateway, RBD, CephFS, Monitoring and Sizing.

– README.md

As ceph is a project with huge momentum, not only regarding spreading but also development, changes are certain to happen.
The training right now is not very specific regarding OpenStack-Integration, so this will be in the focus in the next iteration.
Commits to the trainings are always welcome!
When you’re interested in a training with more interactivity and personal discussion, feel free to get an overview here.

Tim Albert
Tim Albert
System Engineer

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

Konfiguration mit Lsyncd synchronisieren

Hallo!
Heute möchte ich euch ein Tool vorstellen mit dem man relativ einfach, sicher und in nahezu realzeit Konfiguration auf andere Systeme und umgekehrt synchronisieren kann. Das Tool hoert auf den Namen Live Syncing (Mirror) Daemon, oder kurz gefasst Lsyncd.
Als erstes möchte ich etwas auf die Magie von Lsyncd eingehen, damit man einen Eindruck bekommt wie das Tool arbeitet und was für Möglichkeiten sich ergeben. Lsyncd verwendet unter Linux inotify und unter MacOS FSEvents um Änderungen am Verzeichnissbaum zu beobachten. Anhand dieses “Monitorings” kann Lsyncd feststellen, ob Änderungen im zur synchronisation bestimmten Verzeichnis passiert sind. Ist dies der Fall, startet Lsyncd die synchronisation mit den zuvor entsprechend gesetzten Parametern. Die Parameter sind z.B. welches Verzeichniss von soll wohin repliziert werden und welches Protokoll soll dafür genutzt werden z.B. rsync.
Kommen wir zum interessanteren Teil die Installation und Konfiguration von Lsyncd. In den meisten Distributionen ist Lsyncd bereits als fertiges Paket vorzufinden. Für die demonstration verwende ich eine CentOS 7.x Maschine in VirtualBox auf einem Laptop.
Vorbereitung/Installation (CentOS 7.x)
Zunächst installieren wir das lsyncd Paket mittels YUM und generieren bzw. verteilen anschließend unseren SSH-Key den wir später für Lsyncd nutzen.

[root@lsyncdemo ~]# yum install lsyncd
[root@lsyncdemo ~]# ssh-keygen -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (/root/.ssh/id_ed25519): /root/.ssh/id_lsync
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_lsyync.
Your public key has been saved in /root/.ssh/id_lsyync.pub.
The key fingerprint is:
SHA256:ntsHfyqPkwffQ3IPMUkZ6kIOMdSBqVhREwgag7V1TgI root@lsyncdemo
The key's randomart image is:
+--[ED25519 256]--+
| oE.+.+=B=.. .o |
|. * =o o+. .o |
| o o... . .. . |
| . . + . + |
| S o . o |
| . .o.. + |
| o * = o |
| o+.= + .|
| . o*oo . |
+----[SHA256]-----+
[root@lsyncdemo ~]# ssh-copy-id -i /root/.ssh/id_lsync i2node01

Konfiguration
Nun kommen wir zur Konfiguration unseres Lsyncd, hierfür existiert genau eine Konfigurationsdatei unter /etc/ (equivalenter pfad osx) mit dem Namen lsyncd.conf. Für unser Beispiel synchronisiere ich Verzeichnis mit Konfiguration auf meinen Icinga2 Master (i2node01).

[root@lsyncdemo ~]# vi /etc/lsyncd.conf
<...
- sync{default.rsyncssh, source="/var/www/html", host="localhost", targetdir="/tmp/htmlcopy/"} //Beispiel Konfiguration entfernen
+ sync{ //Icinga Configuration
+  default.rsync, //Wir nutzen rsync zum Synchronisieren
+  source="/home/mdeparade/icinga2/scripts", //Das Quellverzeichnis
+  target="i2node01:/etc/icinga2/scripts", //Das Zielverzeichnis
+  rsync={rsh ="/usr/bin/ssh -l root -i /root/.ssh/id_lsync", owner = true, perms = true,}
+ }
...>

Kurze Erläuterung: Die letzte Zeile unserer Konfiguration gibt rsync noch ein paar Informationen mit: Wir bauen einen SSH-Tunnel als Benutzer root auf, mit dem SSH-Key “id_lsync”, anschließend sagen wir noch das alle Berechtigungen der Dateien/Verzeichnisse erhalten bleiben sollen.
Abschluss
Nachdem wir Lsyncd mit Konfiguration versorgt haben, können wir diesen direkt starten und Überprüfen ob unser Synchronisation auch ordnungsgemaess funktioniert:

[root@lsyncdemo ~]# cat /etc/lsyncd.conf
----
-- User configuration file for lsyncd.
--
-- Simple example for default rsync, but executing moves through on the target.
--
-- For more examples, see /usr/share/doc/lsyncd*/examples/
--
sync{
default.rsync,
source="/home/mdeparade/icinga2/scripts",
target="i2node01:/etc/icinga2/scripts",
rsync={rsh ="/usr/bin/ssh -l root -i /root/.ssh/id_lsync", owner = true, perms = true,}
}
[root@lsyncdemo ~]# systemctl enable lsyncd --now
[root@lsyncdemo ~]# systemctl status lsyncd
● lsyncd.service - Live Syncing (Mirror) Daemon
 Loaded: loaded (/usr/lib/systemd/system/lsyncd.service; enabled; vendor preset: disabled)
 Active: active (running) since Fri 2018-04-09 10:49:36 BST; 1s ago
 Main PID: 1477 (lsyncd)
 CGroup: /system.slice/lsyncd.service
 └─1477 /usr/bin/lsyncd -nodaemon /etc/lsyncd.conf
Apr 09 10:49:36 lsyncdemo systemd[1]: Started Live Syncing (Mirror) Daemon.
Apr 09 10:49:36 lsyncdemo systemd[1]: Starting Live Syncing (Mirror) Daemon...
[root@lsyncdemo ~]# ll /home/mdeparade/icinga2/scripts
total 4
-rw-r--r--. 1 root root 5 Apr 09 10:52 test.conf
[root@lsyncdemo ~]# ssh -i /root/.ssh/id_lsync -l root 192.168.56.11 ls /etc/icinga2/scripts
test.conf
[root@lsyncdemo ~]# exit
logout
Connection to net-website-2019.test.netways.de closed.

Eindrücke aus Bayern: Die Alpen

Max Deparade
Max Deparade
Consultant

Max ist seit Januar als Consultant bei NETWAYS und unterstützt tatkräftig unser Professional Services Team. Zuvor hat er seine Ausbildung zum Fachinformatiker für Systemintegration bei der Stadtverwaltung in Regensburg erfolgreich absolviert. Danach hat der gebürtige Schwabe, der einen Teil seiner Zeit auch in der Oberpfalz aufgewachsen ist ein halbes Jahr bei einem Managed Hosting Provider in Regensburg gearbeitet, ehe es ihn zu NETWAYS verschlagen hat. In seiner Freizeit genießt Max vor allem die Ruhe, wenn...

Serveradministration mit ISPConfig 3

Für Administratoren die sich nicht viel mit der CLI (Command Line Interface) beschäftigen wollen, gibt es die Administrationssoftware ISPConfig 3, eine Open-Source Software für Linux.

Dieses Tool ermöglicht eine umfangreiche Verwaltung von einem oder mehreren Server durch ein webbasiertes Front-End, welches jedoch vorher über die CLI installiert wird. 🙂

Die Installation kann sowohl auf physischen sowie auf virtuellen Servern erfolgen und unterstützt werden die Distributionen:

  • Debian 5 – 9 (empfohlen)
  • Ubuntu 8.10 – 17.10 (empfohlen)
  • CentOS 5.2 – 7
  • Fedora 10 und 12  20
  • OpenSUSE 11.1 – 13.1

Die Zugriffsebenen teilen sich auf den Administrator, Wiederverkäufer und Kunden ein. Kunden und Wiederverkäufer können auf der Weboberfläche einfach über Kunden > Kunde/Reseller hinzufügen, hinzugefügt werden.

Automatisierte Installation der Konfigurationsoberfläche und der jeweiligen Server-Dienste wie E-Mailserver, Webserver, DNSserver, Dateiserver, Datenbankserver, vServer und XMPP Server durch einen Script, machen es dem unerfahrenen Linux Benutzer um einiges einfacher. Über die Oberfläche lassen sich Webseiten mit letsencrypt wie aus Magie kostenlos mit gültigen Zertifikaten signieren.

Unterstützte werden die Daemons:

  • HTTP: Apache2 und nginx
  • SMTP: Postfix
  • POP3/IMAP: Courier und Dovecot (1.2.x)
  • FTP: PureFTPd
  • DNS: BIND und MyDNS
  • Datenbank: MySQL
  • Statistiken: Webalizer und AWStats
  • Virtualization: OpenVZ

 

Quick-Guide für Ubuntu und Debian

Bitte nur auf einem frischen Server ohne jegliche Vorinstallationen ausführen um Probleme zu vermeiden.

Vorbereitung

apt-get update && apt-get -y upgrade
apt-get install -y unzip 
cd /tmp
wget --no-check-certificate -O installer.tgz "https://github.com/servisys/ispconfig_setup/tarball/master"
tar zxvf installer.tgz

Installation

cd *ispconfig*
bash install.sh

Die Installation erfolgt dann durch Beantwortungen von Fragen im auswählbaren Experten- oder Standartmodus, dazu gehört auch die Wahl zwischen der Einrichtung von einem Master- oder Slaveserver (Automatisiert nur im Expertenmodus und nur unter Debian).

Shall this server join an existing ISPConfig multiserver setup (y,n) [n]: y

Beispielsweise wird als erstes auf Server1 eine Masterinstallation durchgeführt, danach muss auf Server2 bei einer Slaveinstallation der Hostname und die dazugehörigen Datenbankinformationen des Server1, nach der bejahten Frage ob bereits ein Multiserver setup existiert, eingetragen werden. Der Rest wird dann im Hintergrund automatisch erledigt.

Weitere Informationen und Features zum ISPConfig 3: klick mich

Demo ISPConfig 3: klick mich

Nach der Installation erspart man sich als Admin einiges an Tipparbeit und vermeidet dadurch fatale Konfigurationsfehler.

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
Alexander Klimov
Developer

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

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
Alexander Klimov
Developer

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