A personal Linux backup solution

Having personal backups is a must, but what can you do if you don’t have a mac that runs timemachine?

My first instinct was using the tool of choice of a friend: duplicity. It’s free software, does encryption and incremental backups, what more could you want? But duplicity does not offer a very user experience. The docs are work in progress, the –help is a bit of a mess and the man page is too verbose for a quick start. Obviously I have little problem reading and learning before using a tool, which is why I gave up and looked for a different one.

Restic does all what I want and duplicity can, but it has a good documentation, bash completion and other optional bonuses for making usage and, in turn, my life much easier.  It makes sense to think about what to backup before thinking about the right tool. I only want to backup from ~, I don’t care about `/etc` or other places with config or data, it would be no use to me when someone was to throw this laptop down a bridge. So just how much is lying around in my home directory?

$ du -h -d1 /home/jflach | grep "G" 
1.9G	/home/jflach/i2
4.3G	/home/jflach/.ccache
20G	/home/jflach/git
108G	/home/jflach/vmware
6.6G	/home/jflach/.cache
20G	/home/jflach/Documents
1.2G	/home/jflach/.thunderbird
3.3G	/home/jflach/Downloads
5.6G	/home/jflach/.vagrant.d
171G	/home/jflach

Luckily I have no folder with an upper case “G” in the name and I can see that over 50% are used up by vmare/. I don’t really need to backup my virtual machines, it’d be annoying to lose them but no reason to panic. `.ccache/`, `.cache/` and `Downloads` are completely irrelevant, bringing the total down to just above 50GB.

Back to restic. Creating a new local backup repository is easy:

$ restic init --repo /tmp/backup                                                                                                    
enter password for new backend: 
enter password again: 
created restic backend 929fc4f740 at /tmp/backup

Please note that knowledge of your password is required to access
the repository. Losing your password means that your data is
irrecoverably lost.

Now the for the actual backup, I have a file containing the excluded directories:

$ cat ~/.config/restic.exclude
Downloads
vmware
.ccache
.cache

And the command is simply:

$ restic -r /tmp/backup backup ~ --exclude-file=.config/restic.exclude
enter password for repository: 
password is correct
scan [/home/jflach]
scanned 10123 directories, 64039 files in 0:00
[11:07] 100.00%  76.166 MiB/s  49.612 GiB / 49.612 GiB  74162 / 74162 items  0 errors  ETA 0:00 
duration: 11:07, 76.12MiB/s
snapshot dd45c515 saved

It took eleven minutes on my machine to encrypt and compress about 50GiB of data. Restic starts a few threads and voraciously consumes CPU time and memory as it runs. Get yourself a fresh cup of coffee, working is no fun while the tool runs.

All that’s now left to do is to copy the directory to some external server or hard drive. Restic offers support for common sync tools like sftp, google cloud or rclone, whatever you use it will be your job to automate and define its behavior.

Jean-Marcel Flach

Autor: Jean-Marcel Flach

Geboren und aufgewachsen in Bamberg, kam Jean (das "-Marcel" ist still) nach einem Ausflug an die Uni, als Azubi zu NETWAYS. Dort sitzt er seit 2014 im Icinga 2 core Entwicklungsteam.

GitLab Security Update Reviewed

NETWAYS schreibt die Sicherheit ihrer gehosteten Kundenumgebungen groß – daher kamen auch wir nicht um das Sicherheitsupdate in den GitLab Community Edition und Enterprise Edition Versionen herum.

GitLab machte Mitte März öffentlich, dass man auf eine Sicherheitslücke sowohl in der Community als auch in der Enterprise Edition gestoßen sei. Dabei soll es sich um sogenannte Server Side Request Forgery (SSRF) handeln, was Angreifern unter anderem den Zugriff auf das lokale Netzwerk ermöglich kann. GitLab löste dieses Problem nun durch ein Software Update und den Einbau der Option “Allow requests to the local network from hooks and services“, die per default deaktiviert ist und somit den Zugriff der Software auf das lokale Netz unterbindet.

Das Update auf eine neuere Version ist für viele Nutzer eine gute Lösung – allerdings nur, wenn diese keine Webhooks oder Services, die das lokale Netz als Ziel haben, nutzen. Denn wenn plötzlich die Webhooks und Services nicht mehr funktionieren und weder der Admin noch der User weiß, dass man bei der obigen Option einen Haken setzen muss, dann beginnt erst mal die Fehlersuche.

Fazit: Wer unbedingt auf Webhooks und ähnliches angewiesen ist, muss wohl oder übel vorerst mit der Sicherheitslücke leben.

Eingebaut wurde der Fix in folgende GitLab CE und EE Versionen: 10.5.6 / 10.4.6 / 10.3.9. Eine vollständige Übersicht an Releases findet man hier: GitLab Release

Managed Hosting bei NETWAYSGitLab CE und GitLab EE

NETWAYS Web Services – 30 Tage kostenfreies Testen von GitLab CE und GitLab EE

Nicole Lang

Autor: Nicole Lang

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 Bücher und zockt auch mal gerne.

Elastic{ON} 2018 Reisebericht und Rückblick

Wie alle guten Weine brauch auch manchmal ein Erlebnis eine Weile um zu einer guten Erfahrung zu reifen. So war es für mich mit der Elastic{ON} 2018 und passend zum Feiertag hole ich für euch nun unsere Review aus dem Keller, öffne die Flasche und wir schauen gemeinsam zurück auf das Event.

Thomas Widhalm und ich waren  für NETWAYS bei der Elasti{CON}2018 für euch vor Ort und haben uns die neuesten Entwicklungen und Best Practice Geschichten für euch angehört.

 

Keynote und Party

Die Keynote geführt von Gründer Shay Banon ging schon spannend los, nach dem wir von unzähligen Mitarbeitern in einem Intro begrüßt wurden, folgten für alle Produkte des Elastic Stacks kurze Feature Vorstellungen fürs nächste Release. Highlight dieser Keynote war der Vortrag von Ryan Kazanciyan der technische Consultant für die Serie Mr. Robot. Eine weitere große Ankündigung war mit Abstand die “Doubling down on open” Strategie, welche eine Veröffentlichung der Quellen des X-Pack  mit sich bringt. Dies bedeutet aber nicht das diese Quellen unter eine Open Source Lizenz gestellt werden. Hierzu gab es noch einen Nachruf von Philipp Krenn im Elastic Blog, denn dieses Thema sorgte für viel Diskussionsstoff und hinterließ zuerst einige Unklarheiten.

Bei der Anschließenden Keynote-Party ging es spielerisch mit Frischlufteinlage zu. Denn der Feueralarm ertönte als die Party im vollen Gange war und wir mussten das Gebäude kurzfristig verlassen. Für alle die uns kennen, soll gesagt sein, Thomas und ich hatten damit nichts zu tun.

 

1 Konferenztag

Am ersten Konferzenz-Tag haben Thomas und ich uns auf die unterschiedlichen Sessions verteilt. Thomas Schwerpunkt lag am ersten Tag hier auf den Talks zu den einzelnen Tools des Stacks und deren neuen Features, während ich mich auf Best Practice und BoF (Birth of Feather) Sessions konzentriert.

Die hier spannendste BoF Session war die zur GDPR welche zum 25.Mai 2018 in kraft tritt. Hier wurde in einer großen Runde darüber diskutiert wie man im Bezug auf Logmanagement und das Auswerten von Logingdaten zu reagieren hat. Klar ist das es einige Möglichkeiten gibt mit denen die sensiblen Daten wie eine IP mit dem Fingerprint Filter gehasht werden können. Aber auch die Auflagen zur Absicherung des Zugangs zu den Daten und deren Aufbewahrungszeiten gilt es zu berücksichtigen. Zu dieser Session findet sich im Elastic Blog eine sehr gute Zusammenfassung.

Thomas konnte für uns einen sehr guten Überblick über die Neuerungen im Stack am ersten Tag gewinnen. Da diese nicht gerade wenig sind, haben wir hier für euch kurz zu jedem Tool drei Punkte:

Elasticsearch

  • Cross-Cluster Search ersetzt vollständig die Tribe Node Funktion, die Tribe Node Funktion wurde entfernt. Mit einem Node als Cross-Cluster-Node ist das verbinden mehrere Cluster und der Darstellung der Cluster-Daten in einem zentralen Kibana möglich. Wichtig dabei ist, dass laut Plan drei Major Versions in einem Verbund unterstützt werden. Diese Funktion kann unter anderem sehr nützlich bei Migrationen und Upgrade-Szenarien sein.
  • “Cross-Cluster-Sync”, wodurch Daten zwischen Clustern synchronisiert werden können. Damit können Daten in verschiedenen Standorten synchron gehalten werden ohne einen Cluster über mehrere Rechenzentren zu spannen (was nicht supported wird)
  • Die Angabe von minimum master nodes um Split Brain zu verhinden wird automatisch werden. Wie und wie die eingestellt werden kann wurde noch nicht genau gezeigt.

Kibana

  • Mit X-Pack gibt’s mehr Authentifizierungsbackends (inkl. SAML)
  • Query Autocompletion kommt
  • KQL wird die neue Querysprache, als Ersatz für die Lucene Query Syntax. Die beiden ähneln sich aber stark.
  • Neue Visualisierung: Waffle Map und Canvas sollen kommen

Beats

  • Es kommt eine Prometheus Integration
  • Auditbeat bekommt neue Features. Wird damit eine Kombination aus Auslesen von auditd plus Aide.
  • Beats senden jetzt eine Art Heartbeat, in dem auch ein paar Eckdaten des Hosts, auf dem sie installiert sind enthalten sind. So hat man ein rudimentäres Monitoring in Kibana und sieht auch gleich, ob alle Beats aktiv sind.

Logstash

  • Mit X-Pack soll ein Konfigmanagement für mehrere Logstash Instanzen inkl. Konfiguration von Pipelines kommen.
  • Logstash erhält einen Secret Key Store, mit dem Passwörter für Verbindungen sicher gespeichert werden können
  • Visual Pipeline Builder, mit dem in Kibana abgebildet wird, wie die Pipeline konfiguriert sind.

Party

Wer uns von NETWAYS kennt weis, dass wir immer gerne Feiern. Am Abend des ersten Tages waren wir zur Party von unseren Freunden von Graylog geladen. Ebenfalls eine Software für das Logmanagement welche unter anderem auch Elastic Software nutzt, wie zum Beispiel Elasticsearch zum speichern der Dokumente.

 

2 Konferenztag

Am zweiten Konferenztag waren wir überwiegend gemeinsam Unterwegs und durften uns über die Überklimatisierung der Räume erfreuen, welche für Eiszeiten sorgte. An diesem Tag nahmen Thomas und ich an einer Videostory teil, welche bis jetzt wohl noch nicht veröffentlich ist.

 

Talks

Der Talk der an diesem Tag für Thomas und mich besonders erwähnenswert war, war der Talk “The seven deadly Sins of Elasticsearch Benchmarking“.  In diesem Talk gaben Elastic Mitarbeiter aus der Entwicklung Einsicht in Ihre Erfahrung aus dem täglichen Elastisearch Support und wie Sie Elasticsearch zu Performance verhelfen. Klare Empfehlung ist immer auf der gleichen Infrastruktur zu testen wie diese in Produktion verwendet wird. Ein wichtiges Werkzeug für das Testen von Elasticsearch-Clustern wurde vorgestellt und auf Github zu finden https://github.com/elastic/rally.

Unsere Entdeckung

Unser Blerim Sheqa alias bobapple ist auf der “Thank you to the Contributors wall” für seine Beats verewigt!YEAHY!

Schön wars…

Es war insgesamt eine sehr gute Konferenz welche uns sehr viele Erfahrungsmehrwerte verschaffte und uns die Möglichkeit bot eine Zertifizierung einzufahren. Thomas und ich bedanken uns auch bei Bernd bedanken, dass wir unsere Firma vertreten durften.

Mein persönliches Highlight war wohl der AMA-Stand. Diese Chance mit den Schöpfern und den Supportern der Software direkt zu sprechen nehme ich gerne war um meine offenen Verständnisfragen zum Elastic Stack zu schließen und nicht eine konkrete Aufgabenstellung zu lösen. Jetzt bleibt nur noch zu sagen das wir von neuem Wissen und mehr Wissen nur so strotzen und wenn Ihr offene Fragen habt dann besucht doch einfach eine unserer Elastic Stack Trainings z.b  Anfang Juni. Oder meldet euch, wenn Ihr konkret Unterstützung braucht und von unserem mit neuen Informationen angereicherten Wissen profitieren wollt, bei den Kollegen vom Sales Team. So zum Abschied noch eine kleine Weisheit : “You Know for Search!”

Daniel Neuberger

Autor: Daniel Neuberger

Nach seiner Ausbildung zum Fachinformatiker für Systemintegration und Tätigkeit als Systemadministrator kam er 2012 zum Consulting. Nach nun mehr als 4 Jahren Linux und Open Source Backup Consulting zieht es ihn in die Welt des Monitorings und System Management. Seit April 2017 verstärkt er das Netways Professional Services Team im Consulting rund um die Themen Elastic, Icinga und Bareos. Wenn er gerade mal nicht um anderen zu Helfen durch die Welt tingelt geht er seiner Leidenschaft für die Natur beim Biken und der Imkerei nach und kassiert dabei schon mal einen Stich.

Icinga Web 2 – todsicher.

Nachdem ich mich zuletzt in den Sänften Apples ausgeruht habe, geht es heute zurück ans eingemachte – oder besser gesagt: Back to the Roots! Selbst als alter Icinga Web 2– und Modulentwickler habe ich noch längst nicht alle Vorzüge dieses Feldes beansprucht.

Einer davon ist die Möglichkeit, alles Mögliche für die Authentifizierung herzunehmen. Einzige Voraussetzung: der Webserver muss mitspielen. Manche Authentifizierungsverfahren gelten als sicher, andere nur wenn das Passwort weise gewählt ist… aber zumindest eines ist todsicher: TLS (aka “SSL”) Client-Zertifikate. Die Vorteile liegen auf der Hand:

  • mit der folgenden Anleitung relativ einfach umzusetzen
  • Erstellung unsicherer Zertifikate (analog zu den Passwörtern) nicht möglich
  • keine geheimen/privaten Schlüssel werden während der Authentifizierung übertragen (kann man von Passwörtern nicht behaupten)
  • Unbefugte werden schon vom Webserver “abgefangen” und kommen gar nicht erst an Icinga Web 2 heran

Na dann riegeln wir mal ab…

Zertifikate erstellen

Sowohl der Webserver als auch jeder Client brauchen je ein TLS-Zertifikat, das von einer der Gegenseite vertrauenswürdigen Zertifizierungsstelle (CA) unterschrieben ist. Diese Unterschriften könnte ich einkaufen oder kostenlos beziehen, aber der Einfachheit halber erstelle ich mir für beide Seiten je eine CA und unterschreibe je ein Zertifikat.

Die Sänfte Apples bieten in der Schlüsselbundverwaltung einen Zertifikatsassistenten, aber auch der eingefleischte Linux-Sysadmin hat mit Openssl ein Umfangreiches Bordmittel zur Verfügung.

Server

Im Gegensatz zum Client müssen Nutzer beider Betriebssysteme darauf achten, dass das Server-Zertifikat über einen sog. “subjectAltName” verfügt. Sonst staunt man beim Aufbau der Umgebung nicht schlecht: Trotz Vertrauen in die CA und passendem commonName erkennt zumind. Google Chrome das Zertifikat nicht an.

Die hervorgehobenen Stellen müssen höchst wahrscheinlich an die eigene Umgebung angepasst werden – z.B. eine Domäne statt einer IP Adresse und damit auch CN_KIND=DNS.

openssl req -x509 -newkey rsa:4096 -subj '/CN=example com CA - server' -md5 -keyout ca-server.key -out ca-server.crt -nodes

CN_KIND=IP ; CN=172.28.128.3

openssl req -newkey rsa:4096 -subj "/CN=$CN" -keyout server.key -out server.csr -nodes

openssl x509 -req -in server.csr -sha512 -out server.crt -CA ca-server.crt -CAkey ca-server.key -CAcreateserial -extensions SAN -extfile <(printf '[SAN]\nsubjectAltName=%s:%s' "$CN_KIND" "$CN")

Client

Bis auf den hier nicht nötigen “subjectAltName” – das gleiche in grün.

openssl req -x509 -newkey rsa:4096 -subj '/CN=example com CA - client' -md5 -keyout ca-client.key -out ca-client.crt -nodes

openssl req -newkey rsa:4096 -subj '/CN=Alexander Klimov' -keyout client.key -out client.csr -nodes

openssl x509 -req -in client.csr -sha512 -out client.crt -CA ca-client.crt -CAkey ca-client.key -CAcreateserial

Kleines Easter-Egg am Rande: Es spielt keine Rolle, ob ein Root-CA-Zertifikat mit SHA512, MD5 oder handschriftlich signiert wurde, da es nur auf dessen Vorhandensein im eigenen Schlüsselbund ankommt.

Zertifikate importieren

Ein nicht offizielles Server-CA-Zertifikat und das eigene Client-Zertifikat muss natürlich in den Browser importiert werden. Dafür ist ein kleiner Zwischenschritt nötig:

alexanders-mbp:debian aklimov$ openssl pkcs12 -in client.crt -inkey client.key -export -out client.p12
Enter Export Password:
Verifying - Enter Export Password:
alexanders-mbp:debian aklimov$

“client.p12” (und evtl. “ca-server.crt”) kann anschließend in den Browser importiert werden. Leider ist ein temporäres Passwort unumgänglich, aber “123456” o.ä. geht auch.

Wer diesen Schritt verschleppt, fällt bei der Einrichtung von Icinga Web 2 auf die Nase: Entweder beschwert sich der Browser über eine “nicht sichere” Verbindung oder der Webserver weist die Verbindung ab.

Icinga Web 2 installieren

DIST=$(awk -F"[)(]+" '/VERSION=/ {print $2}' /etc/os-release); \
echo "deb http://packages.icinga.com/debian icinga-${DIST} main" >  /etc/apt/sources.list.d/${DIST}-icinga.list; \
echo "deb-src http://packages.icinga.com/debian icinga-${DIST} main" >>  /etc/apt/sources.list.d/${DIST}-icinga.list

wget -qO - https://packages.icinga.com/icinga.key | apt-key add -
apt update
apt install icingaweb2 -y

cp /vagrant/server.crt /etc/ssl/certs/todsicher.pem
cp /vagrant/server.key /etc/ssl/private/todsicher.pem
cp /vagrant/ca-client.crt /etc/ssl/certs/todsicher-ca.pem

a2dissite 000-default.conf
a2enmod ssl
a2enmod headers
vim /etc/apache2/sites-available/todsicher.conf
a2ensite todsicher.conf
service apache2 restart

Nachdem das Icinga-Repository hinzugefügt wurde, kann auch schon das Paket “icingaweb2” installiert werden. Dieses bringt den Apache-Webserver mit und integriert sich entsprechend. Darauf hin müssen die Zertifikate installiert und deren Verwendung konfiguriert werden.

/etc/apache2/sites-available/todsicher.conf

<VirtualHost *:80>
	ServerAdmin webmaster@localhost
	DocumentRoot /var/www/html
	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined

	RewriteEngine On
	RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]
</VirtualHost>

<VirtualHost *:443>
	ServerAdmin webmaster@localhost
	DocumentRoot /var/www/html
	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined

	SSLEngine on
	SSLCertificateFile /etc/ssl/certs/todsicher.pem
	SSLCertificateKeyFile /etc/ssl/private/todsicher.pem
	Header always set Strict-Transport-Security "max-age=2678400"

	SSLCACertificateFile /etc/ssl/certs/todsicher-ca.pem
	SSLVerifyClient require
	SSLVerifyDepth 1
	SSLUserName SSL_CLIENT_S_DN_CN
</VirtualHost>

Sollte jemand auf die Idee kommen, den Server mit HTTP anzusprechen, wird er bedingungslos auf HTTPS umgeleitet – und diese Tat auch nicht wiederholen.

Außerdem wird ein TLS-Client-Zertifikat verlangt, das von entsprechender CA unterschrieben sein muss. Dessen commonName wird im Erfolgsfall als Nutzername behandelt – und genau auf diesen Zug springt Icinga Web 2 auf…

Icinga Web 2 einrichten

Nun greift man via Browser auf Icinga Web 2 zu und richtet es wie gewohnt ein… naja, fast wie gewohnt…

Nachdem der Browser nach dem zu verwendenden Client-Zertifikat gefragt hat, grüßt die Anmeldemaske, die auf den Einrichtungsassistenten verweist. Dieser fordert wie zu erwarten den Einrichtungstoken. Nach dessen Eingabe habe ich ausnahmsweise sämtliche Module deaktiviert, da… dieser Blogpost eh schon viel zu lang ist. (Aber nur die Ruhe, wir haben’s schon fast.)

Nach einer kleinen Anpassung der PHP-Konfiguration und einem darauf folgenden Neustart des Webservers…

root@contrib-stretch:~# perl -pi -e 's~^;date\.timezone =.*?$~date.timezone = Europe/Berlin~' /etc/php/7.0/apache2/php.ini
root@contrib-stretch:~# service apache2 restart

… bestätigt auch schon die erste Ausnahme die Regel: Der Typ des Authentifizierungs-Backends ist auf “Extern” zu setzen, da dies der Webserver übernimmt. Die folgenden Einstellungen des Backends können bei dem voreingetragenen belassen werden. Wenn alles richtig konfiguriert wurde, schlägt der Assistent den bedienenden Benutzer als Administrator vor. Ab da bleiben nur noch die Formalitäten…

Fazit

Wer auf das Monitoring-System Zugriff hat, hat viel Macht.

Bernd Erk, NETWAYS CEO

Tja Bernd, auf mein Monitoring-System hat kein Unbefugter mehr Zugriff – todsicher.

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.

Philips Brilliance 258B6 and macOS

With Apples policy to get rid of established connection methods and switching entirely to USB-C, we faced the need for keeping hardware connected to the new Apple devices.

As there are many offers for adapting USB-C to any other connectors, we looked thoroughly through these possibilities.

In the end we found a charming solution, Philips’ Brilliance 258B6 (Review)

It provides USB-A, HDMI, DSUB, DVI, Audio connectivity, Ethernet, Display Connection and Power Supply via one single USB-C Slot so other devices could still be connected directly at the MacBooks USB-C ports.

While this setup has been runnig smoothly with mostly Dell Notebooks with Windows and Fedora, macOS was sometimes having issues.

The most annoying one has been intermittend Network connection loss. We have discussed this topic at length and could determine, that there is no fault at our network setup.

After a lot of testing, Philips came up with a solution: Installing the correct driver! You may find version 1.0.17 here.

Having installed this specific version, the monitors started to act as expected.

Another issue some users had to face, was a random vertical shift by one pixel.

Using the OSD you might want to switch off “Pixel Orbiting” and this strange behaviour stopped.

So if you’re thinking about buying a new monitor for your new devices, this monitor might be a very good choice.

Tim Albert

Autor: Tim Albert

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert, wobei seine Tätigkeit als Werkstudent bei IDS Scheer seinen Schwenk von Lehramt zur IT erheblich beeinflusst hat. Neben dem Studium hat Tim sich außerdem noch bei einer Werkskundendienstfirma im User-Support verdingt. Blerim und Sebastian haben ihn Anfang 2016 zu uns ins Managed Services Team geholt, wo er sich nun insbesondere um Infrastrukturthemen kümmert. In seiner Freizeit engagiert sich Tim in der Freiwilligen Feuerwehr - als Maschinist und Atemschutzgeräteträger -, spielt im Laientheater Bauernschwänke und ist auch handwerklich ein absolutes Allroundtalent. Angefangen von Mauern hochziehen bis hin zur KNX-Verkabelung ist er jederzeit einsatzbereit. Ansonsten kocht er sehr gerne – alles außer Hase!

Spielen in der Cloud

Für unsere firmeninternen LAN-Parties habe ich vor kurzem eine Möglichkeit gesucht, auf unseren MacBook bzw. Azubi-Notebooks Spiele laufen zu lassen. Diese verfügen leider nur über die üblichen, integrierten Intel-Grafikkarten und sind damit nicht für anspruchsvolle Spiele zu gebrauchen.

Bei meiner Suche bin ich auf die Idee gestoßen, die Spiele auf EC2-Instanzen in der Amazon-Cloud laufen zu lassen. Für wenig Geld (ca. 0,50€/Stunde) lassen sich VMs mit einer NVIDIA GRID K520-Grafikkarte starten.

Zusammen mit Steam In-Home-Streaming und einem Layer-2-Tunnel (damit Steam denkt, dass die VM im gleichen LAN-Segment läuft) lässt sich daraus der perfekte Spielerechner basteln. Dass ich nicht der erste bin, der diesen Plan hatte, zeigen diverse Anleitungen, die einige Details bei der Installation besser erklären, als ich es hier in aller Kürze könnte.

Ich habe das ganze natürlich ausführlich mit Guild Wars 2 getestet (nicht während meiner Arbeitszeit 😜) und mir ist nur vereinzelt aufgefallen, dass das Spiel ja gar nicht lokal läuft: Die Steuerung ist absolut verzögerungsfrei und nur bei schnellen Kameraschwenks sieht man für ein paar Millisekunden Kompressionsartefakte.

Gunnar Beutner

Autor: Gunnar Beutner

Vor seinem Eintritt bei NETWAYS arbeitete Gunnar bei einem großen deutschen Hostingprovider, wo er bereits viel Erfahrung in der Softwareentwicklung für das Servermanagement sammeln konnte. Bei uns kümmert er sich vor allem um verschiedene Kundenprojekte, aber auch eigene Tools wie inGraph oder Icinga2.