NETWAYS Blog

OSDC 2017: Community connects

von Michael Friedrich | Mai 18, 2017 | Events, OSDC

After a fully packed and entertaining first day at OSDC, we really enjoyed the evening event at Umspannwerk Ost. Warm weather, tasty food and lots of interesting discussions, just relaxing a bit and preparing for day 2 🙂

Warming up

Grabbed a coffee and started with Julien Pivotto on Automating Jenkins. Continuous integration matters these days and there’s not only Jenkins but also GitLab CI and more. Julien told us why automation for Jenkins is needed. Likewise, „XML Everywhere“ makes configuration a bit tad hard. Same thing goes for plugins, you literally can’t run Jenkins without. Julien also told us „don’t edit XML“, but go for example for Groovy and the Jenkins /script API endpoint. The Jenkins pipeline plugin even allows to use YAML as config files. In terms of managing the daemon, I learned about „init.groovy.d“ to manage and fire additional Groovy scripts. You can use the Job DSL Groovy plugin to define jobs in a declarative manner.
Julien’s talk really was an impressive deep dive leading to Jenkins running Docker and more production hints. After all an amazing presentation, like James said 🙂

At #OSDC @roidelapluie is giving an amazing comprehensive presentation on how to automate @jenkinsci

— James Just James (@purpleidea) May 18, 2017

I decided to stay in MOA5 for the upcoming talks and will happily await the conference archive once videos are uploaded in the next couple of days.
Casey Calendrello from CoreOS led us into the evolution of the container network interface. I’m still a beginner with containers, Kubernetes and also how networks are managed with it, so I learned quite a lot. CNI originates from rkt and is now built as separate project and library for Go-built software. Casey provided an impressive introduction and deep dive on how to connect your containers to the network – bridged, NAT, overlay networks and their pros and cons. CNI also provides many plugins to create and manage specific interfaces on your machine. It’s magic, and lots of mentioned tool names certainly mean I need to look them up and start to play to fully understand the capabilities 😉

Energetic delivery by @squeed at #OSDC pic.twitter.com/LbE2ha3jQt

— Felix Frank ? ‏ (@felis_rex) May 18, 2017

Yesterday Seth Vargo from HashiCorp had 164 slides and promised to just have 18 today, us moving to lunch soon. Haha, no – it is live demo time with modern secrets management with Vault. We’ve also learned that Vault was developed and run at HashiCorp internally for over a year. It received a security review by the NCC group before actually releasing it as open source. Generally speaking it is „just“ an encrypted key value store for secrets. Seth told us „our“ story – create a database password once, write it down and never change it for years. And the process to ask the DBA to gain access is so complicated, you just save the plain-text password somewhere in your home directory 😉
Live demo time – status checks and work with key creation. Manage PostgreSQL users and credentials with vault – wow, that simple? That’s now on the TODO list to play with too. Seth also released the magic Vault demo as open source on GitHub right after, awesome!

Wow. Manage #postgresql users and credentials with #vault – it just works 🙂 @sethvargo #osdc /mif pic.twitter.com/iTNYdIyHhC

— netways (@netways) May 18, 2017

Enjoying the afternoon

We had tasty lunch and were glad to see Felix Frank following up with „Is that an Ansible? Stop holding it like a Puppet!“ – hilarious talk title already. He provided an overview on the different architecture and naming schemas, community modules (PuppetForge, Ansible Galaxy) and also compared the configuration syntax (Hash-Like DSL, YAML). Both tools have their advantages, but you certainly shouldn’t enforce one’s mode onto the other.

OH @felis_rex "That's a thing which gets me a little wild." #namingthingsishard #ansible #puppetize #osdc pic.twitter.com/ixJwpng8Mc

— Michael Friedrich (@dnsmichi) May 18, 2017

Puh, I learned so many things today already. I’ve unfortunately missed Sebastian giving an introduction about our very own NETWAYS Web Services platform managed with Mesos and Marathon (I rest assured it was just awesome).
After a short coffee break we continued to make decisions – previously Puppet vs. Ansible, now VMware vs. Rudder, location-wise. I decided to listen to Dr. Udo Seidel diving into „VMware’s (Open Source) way of Container„. VMWare is traditionally not very open source friendly, but things are changing. Most likely you’ve heard about Photon OS serving as minimal container host. It was an interesting talk about possibilities with VmWare, but still, I left the talk with the „yet another platform“ feeling.
Last talk for a hilarious day about so many learnt things is about containerized DBs by Claus Matzinger from Crate.io. CrateDB provides shared nothing architecture and includes partitioning, auto-sharing, replication. It event supports structured and unstructured data plus SQL language. Sounds promising after all.
Dirk talked about Foreman as lifecycle management tool in MOA4, too bad I missed it.

"The usual intro applies: we are @netways, we are hiring, you know…all that jazz" – Dirk Götz at #OSDC pic.twitter.com/nj1hkCfxw4

— Felix Frank ? ‏ (@felis_rex) May 18, 2017

Conclusion

Coffee breaks and lunch unveiled so many interesting discussions. Food was really tasty and I’m sure everyone had a great time, so did I. My personal highlights this year: Follow-up Seth’s talk and try Consul and Vault and do a deep dive into mgmt and tell James about it. Learn more about Ansible and put it into context with Puppet, like Felix has shown in his talk. As always, I’m in love with Elastic beats and will follow closely how to log management evolves, also on the Graylog side of life (2.3 is coming soon, Jan and Bernd promised).
Many thanks to our sponsor Thomas Krenn AG for being with so long. And also for the tasty Linzer Torte – feels like home 🙂

Thank you @netways for the exciting #OSDC conference and for (OPEN)powering open source /wf pic.twitter.com/xa8s7cNda9

— Thomas-Krenn.AG (@ThomasKrennAG) May 18, 2017

Thanks for a great conference, safe travels home and see you all next year!
Save the date for OSDC 2018: 12. – 14.6.2018!

SNMPv3 INFORM in a high available setup

von Markus Frosch | Jul 29, 2016 | DevOps, Linux

SNMP is, and will be for a long time, one of the key protocols in monitoring. Widely used in hardware and appliance monitoring, and for sending events and alerts via TRAP or INFORM.
Now the problem of SNMPv1 or v2 is, that it has no real security. SNMPv3 offers that, but might cause you headaches, trying to understand, how it works.
With this post I want to explain, how snmptrapd can be used in a high availability setup, with the security of SNMPv3. I hope this gives you an inside and a quick start guide to try it out.

Security model

If you never worked with SNMPv3, just a quick introduction to authentication and security. There are no communities anymore, but a few other parameters are required:

securityName (username)
authProtocol (MD5 or SHA hashing algorithm)
authKey (secret to authenticate the peer)
privProtocol (AES or DES to encrypt the data)
privKey (secret to encrypt data)

Note: All keys are symmetric, which means both ends of the communication need to use the same keys (and protocol settings).
You can also disable authKey and/or privKey, but than why use SNMPv3? Check the manpage of snmptrapd for how to configure it in detail.

TRAP or INFORM?

With SNMPv3 a new notification type got introduced, called „INFORM“. The main differences between both types are:

INFORM is using a protocol to ensure delivery (Receiver sends an ack)
TRAP is working similar to v1/2, but its tricky with SNMPv3 security
INFORM has protection against message replay

Minimale Rechte und persönliche Accounts zur Administration

von Dirk Götz | Jul 8, 2016 | Linux, Icinga, Security

Nachdem in unserer letzten „Icinga 2“-Schulung die Diskussion aufkam wie man Icinga 2 am besten mit minimalen Rechten konfiguriert und administriert, will ich mich dieser Thematik mal annehmen. Dies wird zwar anhand des Beispiels Icinga 2 auf CentOS 7 sein, aber lässt sich so auf jeden Dienst anwenden, der in Konfigurationsdateien verwaltet wird.
Ausgangsbasis
Die Ausgangsbasis stellen immer die Rechte dar, die durch das Package bei der Installation vorgegeben werden. Diese sollen unverändert bleiben, da sie sonst bei einem Update wieder auf den Standard des Packages zurückgesetzt werden. Als zweites gehen wir mal davon aus, dass eine Anmeldung als unpriviligierter Benutzer mit einem persönlichen Account möglich ist, wobei egal ist ob dieser lokal angelegt ist oder aus einem zentralen Verzeichnisdienst kommt, und dass dieser zur Administration genutzt werden soll.
Bei Icinga 2 sehen die Rechte nach der Installation folgendermaßen aus:

Auf dem Hauptverzeichnis /etc/icinga2 hat root alle Rechte, die Gruppe icinga darf lesen und browsen, alle anderen haben keine Rechte.
Auf die Dateien und Unterverzeichnisse hat der Benutzer icinga alle Rechte, die Gruppe icinga darf lesen und Verzeichnisse browsen, alle anderen haben keine Rechte.
Die Ausnahme bildet die Datei /etc/icinga2/init.conf, bei der die Benutzerrechte auf root liegen, aber auch nicht editiert werden sollte.

Zusätzlich zu den Dateirechten brauchen wir zur Administration Befehle wie systemctl reload icinga2.service um Icinga 2 neuzustarten oder auch icinga2 daemon -C zum Validieren der Konfiguration. Die Systemkommandos können nur als root ausgeführt werden, die Icinga-Kommandos als root oder icinga. Der Benutzer icinga ist allerdings als Benutzer gedacht unter dem der Dienst läuft und hat daher keine Benutzerumgebung, Kommandos können mit sudo aber trotzdem mit seinen Rechten ausgeführt werden.
Ein unpriviligierter Account kann nun noch nicht mal die Konfiguration lesen oder auch nur durch die Verzeichnisse navigieren, den Dienst nicht steuern oder Icinga-Kommandos absetzen. Dies können wir auf zwei Arten lösen. Methode 1 sind Gruppenrechte, Methode 2 ACLs, beides angereichert um eine Prise sudo um Kommandos unter anderen Rechten auszuführen.
mehr lesen…

Dirk Götz

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

Lies mehr von Dirk und triff unser Team

OSDC 2016: More for your datacenter stack

von Michael Friedrich | Apr 28, 2016 | Events, OSDC

We need more coffee – the first talk of day 2 directly kicked off with automation and challenges. We are using Foreman at NETWAYS and it helps me on a daily basis to deploy development boxes with Opennebula. So it was interesting to find out about insights and challenges by Julien Pivotto with Automating a R&D lab with Foreman: What can be hard?.

#osdc moa 5 starts w/ @roidelapluie from @inuits on managing a R&D lab with @ForemanProject /mif pic.twitter.com/soED2QNoKO

— netways (@netways) April 28, 2016

Sadly the second talk about Interesting things you can do with ZFS by Allan Jude & Benedict Reuschling was at the same time – again one for the conference archive.

Allan Jude and Benedict Reuschling just started their talk "Interesting Things you can do with ZFS" /mn pic.twitter.com/i0J9ub6Rkw

— netways (@netways) April 28, 2016

Decisions decisions. Mesos and the Architecture of the New Datacenter by Jörg Schad or Hybrid Cloud – A Cloud Migration Strategy by Schlomo Shapiro. I guess I’m one of those devops hipsters going for Mesos. Although I hear that its implementation can be tricky (hi Sebastian) we’re using it at NETWAYS and I wanted to learn more about it. Especially since Mesosphere recently announced DC/OS.

.@mesosphere DC/OS #osdc pic.twitter.com/60PdU1Ljq7

— netways (@netways) April 28, 2016

Ingesting Logs with Style sounds like a swiss army knife presentation style. Logs always remind me of the days when there was not Logstash or Graylog around, just some unacceptable expensive Splunk license and your own central syslog server plus some custom handmade scripts. Pere gave an awesome outlook on what’s coming with Elastic Stack 5.0 including hist sports activities as live demos.

Real life @elastic stack demo from @purbon 's sports activities 🙂 #awesome #osdc /mif pic.twitter.com/XAA83HqTCG

— netways (@netways) April 28, 2016

Everyone knows about Docker. Everyone uses it in production already? Or at least tried to until the company’s security team stepped into? Inspecting Security of Docker formatted Container Images to find Peace of Mind provided insights on the most often asked questions when it comes to production deployments.
Right after lunch David Schmitt gave an interesting Introduction to Testing Puppet Modules. Being a developer and writing tests? Meh. The least exciting part right after the documentation bits. Though tests will make your life easier especially with Puppet modules ensuring they won’t break. The talk’s topic also reminds me of Tom de Vylder maintaining the Icinga puppet modules and insisting on rspec tests on every single PR – chapeau 🙂

@dev_el_ops talking about @puppetize testing at #osdc (rspec, rspec-puppet, beaker) pic.twitter.com/J8ZA7LIPqT

— mika (@mikagrml) April 28, 2016

Coming from MariaDB Colin Charles provided tipps and tricks on Tuning Linux for your Database.

. @bytebot from @mariadb is now on stage, talking about Tuning Linux for your Database! /mn pic.twitter.com/F6bQtRIM8p

— netways (@netways) April 28, 2016

An Introduction to Software Defined Networking (SDN) by Martin Loschwitz or Bareos Backup Integration with Standard Open Source Tools with Maik Aussendorf?

An introduction into SDN with @madkissTM at #osdc/be pic.twitter.com/InUn6I6Klp

— netways (@netways) April 28, 2016

Finally the last talks for this years OSDC. We already learned about Puppet and Salt, now it is time for Kaiten Zushi – Chef at Goodgame Studios by Jan Ulferts. Florian Lautenschlager with Chronix – A fast and efficient time series storage based on Apache Solr was again my favourite for the conference archive.

Thank you and see you in 2017

The conference archive will be made available in the next couple of days. Save the date – 16.-18.5.2017 🙂
PS: Everything is a freaking DNS problem!

@dnsmichi @bortzmeyer @jpmens I`m actually writing a book on the topic pic.twitter.com/uRhqhNV1J2

— Kris Buytaert (@KrisBuytaert) April 28, 2016

Compliance Reports in Foreman

von Dirk Götz | Mrz 11, 2016 | Security, Linux, Foreman

Foreman Logo
Ein Steckenpferd von mir ist Security und ich habe mich daher schon vor einer ganzen Weile auch mit OpenSCAP beschäftigt, um umgesetzte Sicherheitsmaßnahmen auch zu visualisieren und regelmäßig auf Compliance zu prüfen. Mein damaliger Workflow bestand dann noch aus Cronjobs, Monitoringplugin und selbstgestricktem Dateiupload, doch nun nimmt mir auch hier Foreman die Arbeit ab.
Doch einmal langsam und von vorne: Was ist OpenSCAP eigentlich? SCAP ist die Abkürzung für Security Content Automation Protocol. Dieses baut auf bereits etablierten Standards auf um sicherheitsrelevante Software-Fehler und Konfigurationsprobleme darzustellen und bringt diese in eine Form, die eine automatisierte Auswertung ermöglicht. OpenSCAP ist eine OpenSource-Implementierung dieses Standards und liefert beispielhafte Richtlinien für verschiedene Linux-Distributionen und Anwendungen wie Java oder Firefox, Werkzeuge zur Überprüfung und Anpassung der Richtlinien an Firmenvorgaben.
Diese Werkzeuge macht sich das Foreman-Plugin OpenSCAP zu Nutze um Compliance Reports zu integrieren. Prinzipiell besteht es aus drei Komponenten. Das eigentliche Plugin erweitert Foreman um die Möglichkeit SCAP-Regelwerke im Datastream-Format hochzuladen, im Anschluss darin enthaltene Profile Hostgruppen zuzuweisen, eine Anleitung für den Administrator zu erzeugen und zu guter Letzt die Reports der Systeme anzuzeigen. Die Kommunikation läuft hierbei über den Smart Proxy, der ebenfalls durch ein Plugin erweitert wird, das den Download der Profile und den Upload der Reports ermöglicht. Zur Konfiguration der Systeme kommt Puppet zum Einsatz wofür ein entsprechendes Modul zur Verfügung steht.
Das ganze sieht dann so aus:
OpenSCAP-Guide in Foreman
Foreman-OpenSCAP-Guide
OpenSCAP-Report in Foreman
Foreman-OpenSCAP-Report
Ergebnis inklusive Lösungsvorschlag im OpenSCAP-Report in Foreman
Foreman-OpenSCAP-Result
Wie man allerdings auf den Bildern sieht habe ich mir keine Mühe gegeben mein eigenes Demosystem weiter abzusichern. Nun könnte ich entweder die angemeckerten Missstände beheben oder ich nehme mir aus dem OpenSCAP-Projekt die SCAP-Workbench und schneidere mir mein eigenes Profil zurecht. Auch dies geht sehr simpel und graphisch, nur wenn neue Definitionen und Checks geschrieben werden müssen wird es komplizierter.

Wer sicherstellen will, dass seine Systeme bereits von Anfang an sicher installiert sind und auf Fedora, Red Hat Enterprise Linux, CentOS oder ein anderes Derivat setzt, kann hierfür sogar ein Plugin für den Installer Anaconda nutzen.
Anaconda-OpenSCAP
Mir hätte damals ein solcher Satz an Werkzeugen viel Arbeit abgenommen, daher hoffe ich zumindest einigen der Lesern etwas an die Hand gegeben zu haben um eine weitere Anforderung an ihre Umgebung zu lösen. Neben diesem gibts auch noch weitere Plugins die Foreman um ein vielfaches mächtiger machen, einen Teil davon auch in unserer Foreman-Schulung.