Verschlüsselten File-Container mittels cryptsetup und LUKS erstellen


Datenschutz wird im Jahr 2018 so groß geschrieben wie nie zuvor. Verschiedene Anforderungen an die Absicherung der Daten zwingen Admins, sich elegante und sichere Setups einfallen zu lassen. Ich nehme das zum Anlass, eine neue Serie zur Dateiverschlüsselung zu eröffnen, bei der es um die verschiedensten Möglichkeiten geht, die gespeicherten Daten gegen den Zugriff Unbefugter abzusichern.
Oftmals ist eine Verschlüsselung der Daten aufgrund bestehender Infrastrukturen oder mangels Rechten (z. B. bei extern angemieteten Storages) nicht so einfach möglich. Früher war hier ECryptFS im Linux-Umfeld und TrueCrypt bei Windows State of the Art. Heute haben sich die Anforderungen geändert und ECryptFS ist wegen einer zu restriktiven Beschränkungen der Dateinamen nicht mehr alltagstauglich. Daher stelle ich hier eine moderne Alternative mit cryptsetup in Ergänzung mit LUKS vor.

Vorbereitung

Installation von cryptsetup (Beispiel Debian-Derivate)

sudo apt-get install cryptsetup

Laden des Kernel-Moduls (nur bei initialer Einrichtung)

sudo modprobe dm-crypt

File-Container erstellen

Zunächst wird mittels dd ein File-Container mit 1GB Größe erstellt, der Wert kann natürlich je nach Anforderung angepasst werden

dd if=/dev/zero of=/storage/my_container bs=1M count=1024

File-Container mittels cryptsetup initialisieren

 cryptsetup -y luksFormat /storage/my_container

Nun die gewünschte Passphrase eingeben. Aber Achtung, ohne ein gut gewähltes Passwort nutzt die stärkste Verschlüsselung nichts!
Verschlüsselten Container öffnen und Dateisystem erstellen

cryptsetup luksOpen /storage/my_container my_mount

hier wird das Kennwort abgefragt, dies sollte man sich natürlich zuvor gut merken. Der Container ist nun unter /dev/mapper/my_mount eingebunden.  Anschließend wird ein ext4-Dateisystem in dem Container erzeugt.

mkfs.ext4 -j /dev/mapper/my_mount

File-Container am Wunschort mounten

Ordner zum mounten erstellen

mkdir /my_data
mount /dev/mapper/my_mount /my_data

Fertig – alle Daten die nun in /my_data erzeugt werden, landen am Ende verschlüsselt im Container, wie in meinem Beispiel unter /storage/my_container

Mount aushängen und File-Container schließen

Damit die Daten während der Nichtnutzung auch wirklich sicher sind, empfehle ich, den Container wieder abzuschließen.

umount /my_data
cryptsetup luksClose my_mount

Protip

Ich habe auf diese Art der Verschlüsselung bei meiner Nextcloud zurückgegriffen, da mir die Bordmittel von Nextcloud nicht gefallen, oder zu langsam sind. Im nächsten Artikel werde ich auch erklären, wie man den Container entsprechend vergrößern kann. Alle mit my_ verwendeten Variablen, können natürlich auf die jeweiligen Bedürfnisse angepasst werden.

Haben wollen?

Wir bieten natürlich bei uns im Managed-Hosting individuelle Lösungen an. Falls unsere (potentiellen) Kunden ein solches Setup wünschen, so sind wir natürlich für jeden Spaß zu haben.

Disclaimer

LUKS verwaltet die Verschlüsselungsdaten im Header. Ohne den Header (oder im Falle einer Beschädigung), ist ein Zugriff auf die Daten nicht mehr möglich. Es gibt verschiedene Tools, wie beispielsweise zuluCrypt, mit denen die Schlüssel und Header verwaltet und gesichert werden können, doch dazu in einem späteren Artikel mehr. Die Anleitung wurde nach bestem Wissen und Gewissen erstellt, testet bitte jedoch selbst ausreichend, bevor diese Lösung in die Produktion geht, damit das ihr die Funktionsweise versteht und Datenverlust vermeidet.

Georg Mimietz
Georg Mimietz
Lead Support Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

The Future of Open Source Data Center Solutions – OSDC 2018 – Day 1

Now for the fourth time OSDC started in Berlin with a warm Welcome from Bernd and a fully packed room with approximately 140 attendees. This year we made a small change to the schedule by doing away with the workshop day and having an additional smaller conference afterwards. The Open Source Camp will be on Foreman and Graylog, but more on this on Thursday.
First talk was Mitchell Hashimoto with “Extending Terraform for Anything as Code” who started by showing how automation evolved in information technology and explained why it is so important before diving into Terraform. Terraform provides a declarative language to automate everything providing an API, a plan command to get the required changes before you then apply all this changes. While this is quite easy to understand for something like infrastructure Mitchell showed how the number of possibilities grew with Software-as-a-Service and now everything having an API. One example was how HashiCorp handles employees and their permissions with Terraform. After the examples for how you can use existing stuff he gave an introduction to extending Terraform with custom providers.
Second was “Hardware-level data-center monitoring with Prometheus” presented by Conrad Hoffmann who gave us some look inside of the datacenter of Soundcloud and their monitoring infrastructure before Prometheus which looked like a zoo. Afterwards he highlighted the key features why they moved to Prometheus and Grafana for displaying the collected data. In his section about exporters he got into details which exporter replaced which tools from the former zoo and gave some tips from practical experience. And last but not least he summarized the migration and why it was worth to do it as it gave them a more consistent monitoring solution.
Martin Schurz and Sebastian Gumprich teamed up to talk about “Spicing up VMWare with Ansible and InSpec”. They started by looking back to the old days they had only special servers and later on virtual machines manually managed, how this slowly improved by using managing tools from VMware and how it looks now with their current mantra “manual work is a bug!”. They showed example playbooks for provisioning the complete stack from virtual switch to virtual machine, hardening according their requirements and management of the components afterwards. Last but not least for the Ansible part they described how they implemented the Python code to have an Ansible module for moving virtual machines between datastores and hosts. For testing all this automation they use inSpec and the management requiring some tracking of the environment was solved using Ansible-CMDB.
After lunch break I visited the talk about “OPNsense: the “open” firewall for your datacenter” given by Thomas Niedermeier. OPNsense is a HardenedBSD-based Open Source Firewall including a nice configuration web interface, Spamhouse blocklists, Intrusion Prevention System and many more features. I think with all these features OPNsense has not to avoid comparison with commercial firewalls and if enterprise-grade support is required partners like Thomas Krenn are available, too.
Martin Alfke asked the question “Ops hates containers. Why?” he came around in a customer meeting. Based on this experience he started to demystify containers in a very entertaining and memorable way. He focused on giving OPS some tips and ideas about what you should learn before even thinking about having container in production or during implementing your own container management platform. As we do recording I really recommend you to have a look into the video of the talk when recordings are up in a few days.
Anton Babenko in his talk “Lifecycle of a resource. Codifying infrastructure with Terraform for the future” started were Mitchell’s talk ended and dived really deep into module design and development for Terraform. Me being not very familiar with Terraform he at least could convince me that it seems possible to write well designed code for it and it makes fun to experiment and improve with your own modules. Furthermore he gave tips for handling the next Terraform release and testing code during refactoring which are probably very useful for module authors.
“The Computer Science behind a modern distributed data store” by Max Neunhöffer did a very good job explaining theory used in cluster election and consensus. The second topic covered was sorting of data and how modern technology changed how we have to look at sorting algorithm. Log structured merge trees as the third topic of the talk are a great way to improve write performance and with applying some additional tricks also read performance used by many database solutions. Fourth section was about Hybrid Logical Clocks to solve the problem of system clocks differing. Last but not least Max talked about Distributed ACID Transactions (Atomic Consistent Isolated Durable) which are important to keep data consistent but are quite harder to achieve in distributed systems. It was really a great talk while only covering theoretical computer science Max made it very easy to understand at least basic levels and presented it in way getting people interested in those topics.
After this first day full of great talks we will have the evening event in a sky bar having a good view of Berlin, more food, drinks and conversations. This networking is perhaps one of the most interesting parts of conferences. I will be back with a short review of the evening event and day 2 tomorrow evening. If you want to have more details and a more live experience follow #osdc on Twitter.

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman 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 wie nun bei NETWAYS.

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

kostenfreie TLS-Zertifikate mit Let's Encrypt

Let’s Encrypt hat seit gut einem Jahr die Testphase verlassen und verteilt fleißig Zertifikate – kostenfrei versteht sich. Wo anfangs in der Testphase “nur” wenige Millionen Zertifikate ausgegeben wurden, ist diese Zahl inzwischen kräftig gewachsen – Tendenz steigend. WordPress und andere Dienste setzen Let’s Encrypt in breitem Maße ein um das Internet ein bisschen besser (sicherer) zu machen.
Neben der reinen Absicherung der Verbindung hilft ein Zertifikat noch beim Ranking und dem lästigen Wegklicken von Sicherheitswarnungen bei selbstsignierten Zertifikaten, beispielsweise bei Testumgebungen. Chrome bemängelt seit der Version 39 auch die Sicherheit von normalen HTTP-Verbindungen und kennzeichnet diese als “nicht sicher”.
Die Zertifikate von Let’s Encrypt sind nicht besser oder schlechter als andere Zertifikate – nur kosten sie nichts und sind nicht so lange gültig – durch Automatismen zur Erneuerung eher ein Vorteil als ein Nachteil. Bei Let’s Encrypt gibt es keine Wildcard- oder EV-Zertifikate, wenn der Wunsch nach diesen besteht, greift man lieber zu kommerziellen Produkten. Auch wenn die Validierung mehr Sicherheiten bringen soll, als eine Domain-Validierung (hier wird ein Hash in einem vhost hinterlegt und von Let’s Encrypt geprüft), wird einem ein kommerzielles Produkt nahe gelegt.
Also eignen sich die Zertifikate für folgende Anwendungsfälle: Basisabsicherung von Diensten, wo sonst keine Verschlüsselung unbedingt notwendig wäre (z. B. WordPress-Blog), Absicherung von Staging-Systemen, Absicherung als kostenfreie Zugabe des Hosters, Absicherung von internen Diensten und zur Absicherung von privaten Websiten.
Aber wie kommt man nun zu den Zertifikaten?
Hier gibt es verschiedene Wege, allerdings gehe ich nur kurz auf die Command-Line basierte Beantragung ein. Dafür wird von Let’s Encrypt selbst der Certbot empfohlen, der bringt alles mit.
Nach dem Download / der Installation des Certbots (hier kommt es auf die Distribution an) kann dieser mittels dem einfachen Aufrufs

./certbot-auto

starten. Jetzt werden die weiteren Abhängigkeiten noch aus dem jeweiligen Paketmanager nachinstalliert. Ein Wizard startet und fragt welche Domains abgesichert werden sollen und ob ein automatischer (sicherer) redirect von HTTP auf HTTPS erfolgen soll (Hierzu werden Rewrite-Rules in der VHost-Config angelegt). Der Rest geht von alleine, eine CSR wird erstellt, ein vhost für die Domain-Validierung wird angelegt, es wird von extern gecheckt, ob der String im vhost erreichbar ist, Zertifikat wird ausgeteilt und gleich eingerichtet.
Achtung, nachdem der Wizard angestoßen wurde, wird mehrfach der Webserver neugestartet und Configfiles verändert. Für eine alternative Beantragung mit mehr Eigenverantwortung bitte die Hinweise zu certonly und webroot lesen.
Zertifikat nur 90 Tage gültig – was tun?
Die TLS-Zertifikate von Let’s Encrypt sind nur 90 Tage gültig. Die Beweggründe hierfür sind unterschiedlich. Aber aus meiner Sicht ist dies ein wesentlicher Sicherheitsvorteil. Damit es zu keinen Zertifikatsfehlern kommt, heißt es hier im richtigen Moment die Erneuerung der Zertifikate anzustoßen. Denn ein neues Zertifikat bekommt man erst kurz vor Ablauf des alten Zertifikates. An dieser Stelle komme ich an die vormals angesprochenen Automatismen zurück. So reicht es eigentlich täglich 1-2x einen Cron laufen zu lassen:

./certbot-auto renew

Durch dieses Kommando schaut der Certbot beim jeweiligen Lauf des Crons, ob das Zertifikat in Kürze abläuft. Wenn ja, wird ein neues Zertifikat beantragt und hinterlegt, wenn nicht meldet sich der Certbot nur mit einer kurzen Meldung im Log:

INFO:certbot.renewal:Cert not yet due for renewal

Auch hier sicherheitshalber nochmal der Hinweis, dass alle Abhängigkeiten beim renew aktualisiert werden (zu vermeiden mit dem –no-self-upgrade Flag). Desweiteren wird auch wieder ein vhost angelegt und der Webserver-Dienst durchgestartet.
Auch unsere Kunden mit komplexen Setups hinter Loadbalancern und HA-Clustern können von Let’s Encrypt profitieren – wir bauen hierzu die passende Lösung.
Freuen wir uns auf die nächsten Jahre, der wichtigste Schritt wurde bereits gemacht. Wer bei uns Kunde ist, kann schon heute von diesem tollen Service profitieren.

Georg Mimietz
Georg Mimietz
Lead Support Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

Docker on OSX

DockerLogoRunning Docker on OSX can be made possible using different methods:

Docker containers require kernel features which are only available in modern Linux kernels. In order to run Docker on OSX for example, one needs a virtual machine with a smallish Linux running in it.

Docker for Mac Beta

Docker for Mac uses xhyve, a lightweight OS X virtualization solution built on top of Hypervisor.framework. This requires you to run OS X 10.10 Yosemite and higher. The VM is provisioned with Alpine Linux running Docker engine.
The Docker API is exposed in /var/run/docker.sock where the docker and docker-compose CLI commands may directly communicate with. This is one of the benefits compared to Docker machine, especially when you do not need to manage your docker VM, or set specific environment variables before running it. Docker for Mac is further installed as native OSX application and only provides symlinks to /usr/local/bin/{docker,docker-compose}.
After the app is installed, I only had to manually add the bash-completion provided by Homebrew.

cd /usr/local/etc/bash_completion.d
ln -s /Applications/Docker.app/Contents/Resources/etc/docker.bash-completion
ln -s /Applications/Docker.app/Contents/Resources/etc/docker-machine.bash-completion
ln -s /Applications/Docker.app/Contents/Resources/etc/docker-compose.bash-completion

I was granted a beta access key for Docker for Mac today 🙂 Even if this is still beta, it already feels much more integrated into my test and development workflow rather than using Docker machine. Awesome job! 🙂

 

Docker Machine

Docker machine will use Virtualbox as VM provider. In order to avoid manual interaction in each terminal I’m opening I’ve added an alias into my bashrc file.

vim $HOME/.bashrc
alias enable_docker=". '/Applications/Docker/Docker Quickstart Terminal.app/Contents/Resources/Scripts/start.sh'"

This script doesn’t do much except for starting the VM using the Virtualbox cli tools and then source the exported variables into your current shell environment. That way the docker client will be able to communicate with the docker daemon running inside the VM.

Parallels instead of Virtualbox

While Virtualbox works fine there are significant performance improvements when using Parallels on OSX. Furthermore it is reasonable to only use one application firing virtual machines (the Icinga Vagrant boxes also provide support for Parallels as Vagrant provider).
I was therefore looking for a native Parallels driver for Docker. Following this issue shed some light on the history of Docker drivers and their support as plugins. Parallels doesn’t seem to be officially supported by Docker themselves according to their documentation. Though there is an official driver plugin from Parallels themselves which works for Pro and Business subscriber editions only. The main reason seems to be the limited cli features in the Standard edition.

Requirements for Parallels

The main requirement is at least Docker 1.9.1 providing the Docker toolbox 0.5.1+.

Installation

I’m using Homebrew, the manual installation parts are described in the documentation. Brew tries to pull docker-machine as well – if you’re using the version from docker.com you can safely ignore the linking error.

brew install docker-machine-parallels

Create a docker machine

docker_machine_parallels_runUse the driver “parallels” and add the name “docker-parallels”. This will create a new Parallels VM with 20GB HDD and 1GB RAM by default. In case you want to disable sharing the /User mounts, add –parallels-no-share.

docker-machine create --driver=parallels docker-parallels

Add the environment variables to your shell and run docker pulling the latest Fedora container.

eval $(docker-machine env docker-parallels)
docker run -ti fedora:latest bash

Automate it

I’ve partially modified the Docker toolbox script in order to support Parallels.

wget https://raw.githubusercontent.com/dnsmichi/docker-tools/master/toolbox/scripts/osx/start.sh -O /usr/local/bin/enable_docker
chmod +x /usr/local/bin/enable_docker
enable_docker

 

Conclusion

While the Docker Machine integration allows room for improvement the Parallels driver works like a charm. Though I have to admit – while looking into the Parallels integration, Docker announced Docker for Mac and I was eagerly waiting for it.
Both methods are working, but the Docker for Mac application integrated natively into OSX is pretty slick. I like it a lot!
If you are looking for more Docker and its many possibilities – follow our blog closely and visit the Docker training sessions 🙂

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

OSDC 2015 – Enterprise integration with open source

Last year’s OSDC already was a huge success and I really enjoyed all the technical presentations as well as – of course – the tasty food & evening event. So why bother joining my colleagues and the conference this year again? Reading through the speakers list unveiled a certainly interesting program fully packed into 2 days with one day full of Vagrant/Docker/Logstash workshops in advance. For what it’s worth, day 1 was already mind-blowing to me.
After Bernds funny-as-we-love-it welcome presentation Nigel Kersten took over in room MOA5 with “In defense of datacenters”. What we learned is definitely that Europe and the US think different with “putting something into the cloud”. While there are still people around being “cloud skeptic”, the presentation also unveiled some changes going on – from “automate all the things” towards “how to integrate your app containers” into.


 
Not only Nigel was taking that into account, Mitchel Hashimoto (I tend to call him “Mr. Vagrant”, life-saver in many Icinga ways) also referred to that later on in his presentation on “Automating the Modern Datacenter: Development to Production”. He also explained how tools at HashiCorp work, and added examples on how to combine open source tools such as Vagrant, Packer, Consul, and Terraform.
Kelsey Hightower did go fast in his presentation towards an awesome live demo on distributed systems with CoreOS, Kubernetes & Fleet. Actually this demo looked pretty easy, I bet everyone can just do that on their notebooks while driving back home from OSDC. And it also made it clear – the cli is becoming important again with all the tools involved. User interfaces are nice, but the real processing happens on the command line, combined with clusters, automation, monitoring, etc.


Entertaining and smiling the noise irritations away, James Fryman gave an awesome insight on why you would want to use #chatops. Some ops stories from GitHub while sharing real world scenarios from his current employer StackStorm, plus the advice to make your bot a human character (“Bob”) let time just go by and we certainly will have to look into Hubot and how they are called 😉 Pricessless answer to “How much does #chatops disturb admins in $dayjob?” – “It saved them a lot of time, let them slack off a bit.”


Jan-Piet Mens started early with G&T time reducing the nervosity level – according to the audience his talk on MQTT for the datacenter was pretty much a blast. And hey, he didn’t mention the “N”-word, but just #icinga 😉


I did know about Apache Mesos a bit as we were evaluating it for package build clusters at NETWAYS a while back. The presentation on “Why the Datacenter Needs an Operating System” by Bernd Mathiske included an introduction into the entire framework with programmable interfaces and orchestration. It’s pretty clear – there is so much going on the near future in the open source world, and so little time to put everything together 😉
Bernd Ahlers gave an introduction into configuration management systems, including Icinga 2 which is – obviously – a personal interest. Other than that it’s also primarly Graylog for log management and putting it all together. As we certainly learnt from many places – APIs all over with enterprise intergration.
Time-series databases have been referenced in many of the talks before so it was really a pleasure listening to David Norton on InfluxDB finishing the first day of OSDC. 1.2 million series & 400k points/seconds sounds pretty impressive for the upcoming 0.9.0 release. And it can be directly hooked into third-party user interfaces such as Grafana which beats sort of Graphite Web vhost and other problems.


Right now we are preparing for the evening event at the Paulaner-“we can’t spell the rest, not important anyways” in Berlin – be sure to follow the #osdc twitter feed for some updates & pictures. If you can’t be here – save the date already for next year – 26.-28.4.2016 – and join us then 🙂 Or, as Nigel Kersten said – convince your boss 😉


Cheers!

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

After "next generation floating" in HTML

Gang und gäbe ist mittlerweile der Gebrauch von umfließenden Container in HTML (float). Allerdings führt das oft zu Problemen wenn man z.B mit unterschiedlichen Abständen und Positionierungen hantiert. Außerdem ist dieses Modell einfach umständlich und grausig zu implementieren.
Mit einem W3C Vorschlag Ende 2013 hielt das “Flexible Box Layout Module” Einzug in den CSS3 Standard. Die Idee hat man schon früher in der graphischen Programmierung. Innerhalb eines Containers wird eine unbestimmte Menge an Elementen untergebracht. Die Aufteilung der verfügbaren Breite erfolgt anhand von Anteilen.
Knapp ein Jahr später ist das Feature auch in den meisten Browsern verfügbar (Versionen später als November 2013).
Ein Beispiel
CSS:

.flex-container {
    display: flex;
}
.flex-item {
    flex: 1 1 auto;
    border: 1px #ff8000 solid;
}

HTML1 (gleiche Aufteilung):

Column 1
Column 2
Column 3

HTML2 (unterschiedliche Aufteilung):

Column 1
Column 2
Column 3
Column 4
Column 5

Weitere Informationen (z.B. Ausbreitung und Ausrichtung) findet man in den folgenden Links:
http://css-tricks.com/snippets/css/a-guide-to-flexbox/
https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Flexible_boxes
http://www.w3.org/TR/2012/CR-css3-flexbox-20120918/
Fazit: Endlich geile Container 😉

Marius Hein
Marius Hein
Head of Development

Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert, dann als Application Developer gearbeitet und ist nun Leiter der Softwareentwicklung. Ausserdem ist er Mitglied im Icinga Team und verantwortet dort das Icinga Web.

Man reiche mir einen Pimple!

Die genaue Übersetzung des Begriffes “Pimple” ist eher unappetitlich und hat auch nichts mit einem fränkischen Gummistöpsel zum reinigen von Toiletten oder ähnlichem zu tun. Es handelt sich eher um einen Dependency Injection (DI) Container für PHP5.3 welcher dafür zuständig ist, Objekte für den Gebrauch in der Applikation bereitzustellen und an einer zentralen Stelle aufzubewahren.
DI ist ein Entwurfsmuster und zielt damit auf ein Paradigma aus der objektorientierten Programmierung ab, welches eine “Steuerungsumkehr” vorschreibt (IoC = Inversion of Control). Mit diesem Muster baut eine Klasse seine Abhängigkeit nicht selbst sondern bekommt diese injiziert. Damit muss die Klasse die konkrete Implementierung nicht selbst kennen, lediglich die darauf aufbauende Schnittestelle.
Ein Beispiel aus der Zeit wo Mark Zuckerberg noch Erich Mielke hieß:

store = new SessionStorage("DING");
        }
        public function writeToDump() {
                $this->store->store((array) $this);
        }
        public function __destruct() {
                $this->writeToDump();
        }
}
class User {
        public function __construct() {
                $this->session = new Session();
                $this->session['authenticated'] = false;
        }
        public function setAuthenticated() {
                $this->session['authenticated'] = true;
        }
}

Diese Vorgehensweise wird zum Problem wenn die Klasse “Session” öfters verwendet wird – und das wird der Fall sein. Man kann sie nicht einfach ersetzen. Entweder schmeißt man die bisherige Implementierung über Board oder muss im kompletten Code die Handhabung anpassen um mit der neuen Implementierung umzugehen. Idealer Anwendungsfall sind UnitTests. In diesem Fall könnte man eine Dummy-Session schreiben (Mock-Objekt) welche die Daten einfach verwirft, da dies für den Test nicht relevant ist (Oder zum Fehler führt da in der Testumgebung eventuell kein valider Cookie Container existiert).
Um dem Herr zu werden bauen wir das ganze um und geben die Implementierung mit (Constructor Injection):

store = $s;
        }
        public function writeToDump() {
                $this->store->store((array) $this);
        }
        public function __destruct() {
                $this->writeToDump();
        }
}
class User {
        public function __construct(ISession $session) {
                $this->session = $session;
                $this->session['authenticated'] = false;
        }
        public function setAuthenticated() {
                $this->session['authenticated'] = true;
        }
}

Jetzt muss beim instantiieren immer ein gültiges Session Objekt mit zugegeben werden was “einiges” an Verdrahtungsarbeitet kostet. Die Implementierung kann aber leichter ausgetauscht werden. Konfigurierbar ist dieses Vorgehen aber noch nicht und kostet daher weiterhin Wartungsaufwand wenn Änderungen durchgeführt werden müssen.
Jetzt wird es Zeit für Pimple. Wir konfigurieren uns einen Container und kleben die Implementierung zur Laufzeit zusammen:

$session = new Pimple();
// Konfigurationsanteil
$session['cookie_name'] = 'DING';
$session['session_storage_class'] = 'SessionStorage';
$session['session_class'] = 'Session';
$session['session_storage'] = function($c) {
        return new $c['session_storage_class']($c['cookie_name']);
};
$session['session'] = $session->share(function($c) {
        return new $c['session_class']($c['session_storage']);
});

Zwecks besserer Übersicht sind die Schnittstellen und Klassen raus gelassen. Mit dem obigen Beispiel kan man zur Laufzeit alles erdenkliche steuern und die Container-Klasse als Provider beliebig in der Applikation verwenden. Für eine neue Session oder einen Storage-Provider, tauscht man die Implementierung per Konfiguration aus – fertig!
Man könnte sogar noch weiter gehen und die Konfiguration in XML oder INI Dateien verpacken. Allerdings mit dem Nachteil in der Konfiguration zu “programmieren” was das Konstrukt zerreist und bei großen Projekten zur Unübersichtlichkeit führt.
Bei Compilersprachen wird dieses Feature für mehr Flexibilität benutzt um Austauschbarkeit zur Laufzeit zu erreichen. Bei Scriptsprachen hingegen gibt es oft eigene (sehr eigene ;-)) Möglichkeiten, Methoden zu überschreiben oder irgendwelche Wrapper einzubinden.
Natürlich ist DI nicht die einzige Möglichkeit. Einige dieser Patterns, z.B. “Service/Locator”, “Observer”, Fasaden, … zielen auf IoC ab. Auch Singletons könnte man dazu zählen – Sollte man aber nicht.
Natürlich ist alles nicht immer nur mit Vorteilen verbunden. Man muss also genau abwägen in wie weit einem dies nützt und bei der Durchführung eines Projekts unterstützt. Auch darf man es, wie bei allen Pattern, nicht zu sehr übertreiben. Für die Ausgabe von drei Zeilen Text muss ich keine 20 Paradigmen aufgreifen um guten Code zu schreiben.
Die positive Seite der Medaille: Der Code wird wandelbarer und damit leichter zu warten!

PimpleInversion of ControlSubstrate – PHP5/SPL

Marius Hein
Marius Hein
Head of Development

Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert, dann als Application Developer gearbeitet und ist nun Leiter der Softwareentwicklung. Ausserdem ist er Mitglied im Icinga Team und verantwortet dort das Icinga Web.