For a Handful of (Vagrant) Boxes

Servus alle miteinand,

Wer kennt das folgende Szenario nicht? Mit viel neuer Software, welche gerade (manuell) getestet werden muss, dachte ich mir, ich baue mal schnell eine Vagrant Box auf Basis von Debian 9, um Tests unter einem Stretch durchzuführen.

Falsch gedacht !!

Anstelle eines libvirt install auf der Kommandozeile und eines tar-Befehls zum Packen des eigentlichen Box-Images,
musste ich mit einer kleinen Widrigkeiten im Bereich der Netzwerkkonfiguration kämpfen.

Aber eins nach dem anderen.
Fangen wir mit dem Image für die libvirt Maschine an:

virt-install --name=linuxconfig-vm \
--vcpus=1 \
--memory=1024 \
--cdrom=/tmp/debian-9.4.0-amd64-netinst.iso \
--disk size=10 \
--os-variant=debian9

Dies war noch der unproblematische Teil der Installation.
Danach erfolgt in der VM das nachziehen von Berechtigungen für den Vagrant User.

sudo visudo -f /etc/sudoers.d/vagrant
vagrant ALL=(ALL) NOPASSWD:ALL

Hinzufügen des Vagrant public Keys:

mkdir -p /home/vagrant/.ssh
chmod 0700 /home/vagrant/.ssh
wget --no-check-certificate \
https://raw.github.com/mitchellh/vagrant/master\/keys/vagrant.pub \
-O /home/vagrant/.ssh/authorized_keys
chmod 0600 /home/vagrant/.ssh/authorized_keys
chown -R vagrant /home/vagrant/.ssh

Wenn man nicht so Wach war, um rechtzeitig im Installationsmenü schon SSH mitzuinstallieren, muss es per Hand nachgeholt werden:

sudo apt-getinstall -y openssh-server
sudo nano /etc/ssh/sshd_config
AuthorizedKeysFile %h/.ssh/authorized_keys

Danach kann das System so präpariert werden, wie man es benötigt.

Das Image der VM noch verkleinern und in box.img umbenennen:

qemu-img convert -c -O qcow2 debian9.qcow2 small.qcow2
mv small.qcow2 box.img

Alles handlich verpacken und dem Vagrant Box Store hinzufügen:

tar czvf debian9.box ./metadata.json ./Vagrantfile ./box.img
vagrant box add --name debian9 debian9.box

Hier allerdings fingen meine Probleme an.
Nach dem Packen der Box, dem Hinzufügen zum Boxstore und einem Erwartungsvollen “vagrant up” erhielt ich “==> default: Waiting for domain to get an IP address…”, was zu keinem Erfolg führte und ich wahrscheinlich jetzt immer noch warten würde.

Nach einem erneuten Hochfahren der VM mit dem virt-manager und nachschauen, ob das network device fehl konfiguriert ist, konnte ich keinen Fehler feststellen.

# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp

Gefühlte Jahrtausende von Recherche später, wurde mir folgendes klar:

Debian hat in neuen Versionen eine Änderung der Device-Namen vorgenommen.
Vagrant wartet vergeblich auf “eth0”, weil ein network device Namens “ens21” existiert, wenn ich die VM mit “vagrant up” starte.

Also zurück in die VM und das folgende Kommandos abgesetzt:

sudo nano /etc/default/grub

Im Editor dann folgende Anpassungen vornehmen:

GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"

Damit das auch greift, muss abschließend die Konfiguration für den Grub-Bootmanager neu erstellt werden:

sudo grub-mkconfig -o /boot/grub/grub.cfg

Reboot. “vagrant up” und Tada … Spannung Trommelwirbel => Tusch ! Die VM erhält eine IP und startet wie man es schon von Anfang an erwartete.

Ich hoffe ich konnte damit den ein oder anderen vor dem Verlust von allzuviel Lebenszeit bewahren.

Ein sonniges WE wünscht

David Okon

Autor: David Okon

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu glücklichen Menschen zu machen.

Noob vs. Icinga 2

Nachdem unser Michael Friedrich letzte Woche einen Blog-Post zum 9. Icinga Geburtstag auf icinga.com veröffentlicht hat, fängt man schon mal an, über die eigenen ersten Schritte mit dem Icinga 2 Stack nachzudenken. Vor allem, wenn man auf einem Live-System mal wieder über etwas aus der Anfangszeit stolpert.

 

Eines meiner ersten Aha!-Erlebnisse war recht klein, jedoch wurde mir dann versichert, dass da auch gestandene User bzw. Admins darüberstolpern. Kern der Frage war damals: “Warum geht dieser *biep* http-check nicht?!” Als Symptom zeigte sich, dass unserem Check der Zugriff verweigert wurde – und das, obwohl doch alle Permissions korrekt gesetzt waren. Da grübelt und googlet der Junior System Engineer erstmal eine Zeit lang. Um das Verfahren hier abzukürzen – es gibt folgende Möglichkeiten, das Problem anzugehen:

Der Grund liegt darin, dass der Check durch den Parameter –expect einen String mit dem Returnwert 200 als Default erwartet. Von daher kann man

  • als Quick’n’Dirty Lösung ganz einfach eine leere Datei mit dem Namen index.html im entsprechenden Verzeichnis angelegt werden
  • den String nach –expect auf einen sicher zu erwartenden Wert setzen, z. B. 302.
  • mit –url einen Pfad angeben, der geprüft werden soll, z. B. /start/menu

Auch schön war der Punkt, an dem man verstanden hat, was es mit dem Parameter command_endpoint auf sich hat – und man plötzlich merkt, dass unterschiedliche Festplatten z. B. auch unterschiedliche Füllstände aufweisen. Genauso faszinierend ist es natürlich auch, dass man durch Apply Rules viele Services weitläufig ausrollen oder umgekehrt auch einschränken kann.

Um nun abschließend einen unserer NETWAYS Consultants zu zitieren: “Das Kommando icinga2 daemon -C sollte man jedem neuen User irgendwohin tätowieren!”

Als Fazit aus den letzten zwei Jahren mit Icinga 2 kann ich ziehen, dass einem der Einstieg recht gut und schnell gelingt – egal, ob es sich um das Aufsetzen, die Wartung oder die täglich Nutzung handelt. Wer sich vor allem von letzterem gerne selbst überzeugen möchte, kann bei den NETWAYS Web Services in unserem kostenfreien Testmonat sowohl einen Icinga 2 Master als auch Satellite starten. Wer sich gerne tiefer in die Materie einarbeiten möchte, kann sich auf icinga.com schlau machen. Dort ist nicht nur die offizielle Dokumentation zu finden, sondern auch Termine zu Trainings und Events. Sehr zu empfehlen ist auch die überarbeitete Auflage des Buches Icinga 2: Ein praktischer Einstieg ins Monitoring von Lennart Betz und Thomas Widhalm.

Bildquelle: https://memegenerator.net/instance/40760148/jackie-chan-dafuq-is-wrong-with-ur-icinga-checks

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.

Running Icinga in NWS with Slack notifications

Slack notifications through Icinga2. This is what we activated last week for our Icinga2 Master apps on our NWS platform! The feature came highly recommended, so we decided to give it a try. And we did. It really is awesome!!

First of all, I want to show you how it will look like on your side, so have a look at the small demo-video!

 

To work with this feature, all you need is a Slack workspace and a chatroom for your alerts. once you are done with configuration part, just follow the 7 steps below.

  1. Go to Configuration/Commands in your Icinga2 app
  2. Open command-slack-host/command-slack-service and open the drop-down Custom properties
  3. Fill in the slack_channel you want to use
  4. Fill in the slack_webhook_url (You can get your webhook url from your Slack-account settings)
  5. Create a new user in Configuration/User and add user to the two groups for Slack-Message on critical hosts/services. Also give user the user template user-template in Imports
  6. Add the states you want to receive as a notifications for to the Configuration / User/Contacts / User-template / modify / State and transition type filtersfield
  7. Deploy your changes in the Configuration/Deployments

If you have ideas for more features for our apps, just contact us via email, twitter, facebook or our NWS chat!

 

This slideshow requires JavaScript.

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

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 blog.netways.de closed.

Eindrücke aus Bayern: Die Alpen

Max Deparade

Autor: Max Deparade

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 er nicht gerade fieberhaft auf sein neues Macbook wartet.

NETWAYS Web Services: WordPress now up and running!

This entry is part of 1 in the series NWS

We are proud to announce a new app hosted in our NWS platform! WordPress is now available!

“Simply for everyone – Perfect for everyone who wants to create individual content. Simple and safe.”

Just as our slogan for this app tells you, we decided to create an app for our users, which can be used by anybody. An app, which is ready to use, easy to configure and practically for almost everyone, without writing code or configuring credentials etc.

We built up an automated migration program, so you can migrate your existing WordPress instance to our platform, no matter which version you are running. We also decided to give the users the opportunity to restore their website by their self and to manage their website without the need of one of our WordPress experts.

The WordPress app includes our S3 compatible replication-based and distributed storage.

All in all it will bring you the following enhanced functions to your cloud:

  • Automated Updates
  • Easy migration
  • Super fast assests delivery via S3
  • Full domain freedom / No domain needed
  • Free CNAME
  • It is available immediately
  • Automated Backups, which are stored for 24 hours
  • Preinstalled plugins and themes
  • Access to DocRoot / Backup via WebDAV

Give it a try! If you are new to our platform, you can use it 30 days for free. The app is of course monthly callable but we think you will like it!

 

This slideshow requires JavaScript.

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

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.