Icon Rufen Sie uns an
+49 441.309197-69 +49 441.309197-69

Lists of installed software in IDB

Posted by Ruben Schuller on Thursday, January 19, 2017

First of all, if you have ideas for other use cases for the feature I'll describe in the following, don't hesitate to let us know about it!

One feature occasionally requested by our customers was to have lists of software installed on machines in the IDB. This feature is now in the development branch.

To be able to have these lists, the data has to somehow find its way into the IDB. Currently it can be imported from PuppetDB by using custom facts which are part of our idb-puppetintegration, or by using IDBs API. Manual input is not supported, as keeping this information up to date isn't really feasible, creates more work and violates the automate all boring things paradigm.

After there is some software data available, software can be searched for by name and version using the new software module. Here's a search for machines which have installed nmap and openvpn:

Click to enlarge

With this query you'll see a table with the search results. Here you can filter for additional things like operating system like in the usual list of machines. This looks like this on my local testing setup:

Click to enlarge

Clicking on a result leads you to the machine details, where a new entry "Software" can be found, showing every installed software for this machine together with its version.

Click to enlarge

Searching isn't only possibe by name, but also by name and version. test2.example.org has nmap version 2 installed, so let's search for machines with openvpn and nmap in this version:

Click to enlarge

As expected this only shows one machine, test2.example.org. Searching partial versions is also supported. To find all machines with python 2 one could use python=2 for example. The results would include every machine with a package named python and versions starting with 2 installed.

If you want to know more about the internals, take a look at the corresponding documentation!


cryptorage4UCS Preview auf dem Univention Summit 2017

Posted by Felix Kronlage on Tuesday, January 17, 2017

cryptorage Webseite

Am 26. Januar ist es wieder Zeit für den "Neujahrsempfang der Open Source Business Szene" - den Univention Summit. Für uns ist der Summit fester Bestandteil des Jahresanfangs und so freuen wir uns dort wieder als Silber-Sponsor auszustellen - dieses Jahr bringen wir jedoch mehr mit als "nur" eine neue Version von openvpn4ucs!


Auf dem diesjährigen Summit präsentieren wir die Preview von cryptorage4ucs, welches ab Februar über das App Center erhältlich sein wird. Mit cryptorage4ucs bringen wir unsere Lösungen für den sicheren und einfachen Dokumentenaustausch in das UCS Ecosystem.

cryptorage - sicherer Datenaustausch mit Weitsicht

cryptorage ist eine Webanwendung die dem Austausch von sensitiven Dokumenten zwischen mehreren beteiligten Parteien dient. Unser Anspruch an cryptorage ist, das die Anwendung so einfach wie ein Webmailsystem bedienbar ist und zeitgleich eine sichere Übertragung von Dateien und Dokumenten bietet. Auf unserem Portal, cryptorage, kann es jederzeit in vollem Umfang getestet werden!

Nahtlose Benutzerintegration

Wir setzen im Backend bei cryptorage auf einen Verzeichnisdienst zur Benutzerverwaltung - so lässt sich mittels der Univention Management Console ganz einfach wählen, welcher Benutzer ein cryptorage-Nutzer sein soll und welcher nicht.


Eine neue Funktion in der aktuellen Version ist die Verschleierung von Dateinamen in den Benachrichtigungen des Systems. Häufig beinhaltet ein Dateiname bereits soviel an Informationen, das Rückschlüsse auf den Inhalt eines Dokuments möglich sind. Um dieses Risiko auszuschalten, kann man einstellen, das anstatt des Datei-/Dokumentennamens nur ein eindeutiger Identifikator verwendet wird.

cryptorage benachrichtigung mit Verschleierung

cryptorage benachrichtigung mit Verschleierung


the idb!

Posted by Felix Kronlage on Thursday, December 01, 2016

idb logo

Awesome - I've been looking forward for this to happen for quite some time! Our infrastructure database has become an fully open source product and project.

We've been talking about our approach on how to handle the ever growing base of machines, instances, routers, switches and so on few times on this blog already. The journey towards the idb started more than four years ago and last year we've reached the point, where we thought it's more than just an internal tool, it has become a product. A bit more than a year ago, we've announced the availability of the idb (German blogpost), Before and after I gave various talks at conferences about what the idb does and what it will and should do at some point.

The talk at this years open source event in Kiel has been recorded and is available on YouTube (again: German content, sorry ;) At the european Ubucon I gave the talk titled Dr. Restless which is a nice summary of the current status quo of the idb. The English slides are available.

For a couple of weeks now the idb itself and the surrounding adapters are now open source and available through GitHub. We've put it into its own project scope in order not to just "throw it as source over the fence", but to be able to grow and foster a community around it.

the idb - tl;dr

The idb is a set of applications to (more or less) automatically collect data from various tools and APIs to give you a central place to keep your infrastructure in view. The central piece is idb-core which is a Ruby on Rails web application. Personally I see the idb as the application that pulls together all the strings that are already interwoven between applications like puppet, the foreman, vcenter, software and license management (opsi comes to mind), monitoring (icinga, icinga2) and of course the ever growing use of cloud providers. The idb is what enables a team to keep infrastructure coming and going in mind.

Click to enlarge


To make things easier, I want to clarify some terms. In the idb universe there are:

  • modules, which are part of idb-core and extend the functionality, for example the inventory module or the cloud provider addition we're working on currently.
  • adapters, which are the beef and connect to the various systems in your landscape to collect data. Adapters are meant to run on a regular base.
  • importers, which are meant to run once to import data from a certain source

are we there yet?

No, definitely not. While we have a nice set of adapters there are many more planned and in the pipeline. Another big leap will be to have more docs at hand - especially for getting everything up and running. Initially, since it was an internal project, we've bootstrapped everything with puppet, these bits however are tightly coupled with the rest of our stuff at bytemine. Part of the work over the last months was to make sure, the idb can be bootstrapped easily outside of our world.

down the road

The current version is 1.6.0, and once our issues are open you can see what is planned for the next minor and major releases. To give a slight overview, for the 1.6.x line we're working on making software<->machine mapping visible, so that you can search for things like:

  • show me all machines that run Ubuntu 16.04 and OpenSSL and php and WordPress

Furthermore we want to make sure one can see which data came through which adapter, as well as making sure the idb REST JSON API exposes all data. Topics like the UCS integration, i18n and multi tenacy are on the map for the 1.7 and 1.8 line. Personally I would like to see an integration with the icinga2 api, so that you can hover a mouse over an idb item and get the current status within icinga2 for that.

Of course we have several adapters planned, these include but are not limited to:

  • nedi - in order to find machines via nedi and hook them into the idb
  • oxidized - to crawl the configs of your router and switches and attach them to the relating idb objects
  • opsi - to get software and machines from opsi into the idb

packages, support and everything

While you can go ahead and grab the idb from GitHub, we offer ready-to-go packages for either Ubuntu or RHEL/CentOS (and integration into the Univention Corporate Server is planned) as part of a commercial subscription. We will publish more on the commercial side of the idb in the upcoming weeks.

Since this afternoon we've moved all our issue tracking to github as well!


Icinga2 API and Request Tracker

Posted by Ruben Schuller on Friday, November 18, 2016

Icinga 2 API and Request Tracker

In the process of switching to Icinga 2 for our monitoring, we needed a new solution to automatically create Request Tracker tickets for monitoring events. While our old solution worked well with Icinga (1), it was incompatible with the new Icinga release.

Meet the API

One of the new features of Icinga 2 is a HTTP API which enables you to receive various types of events, be it check results, notifications, acknowledgements and more. This made the descision for an approach to build the new tool easy: It should be an Icinga 2 API consumer which in turn creates and updates tickets via the RT API.

Too many tickets!

Of the various event streams one can select to receive from Icinga 2 choosing the right one can be a bit tricky. The first attempt was using the StateChange event type. While working, this led to many unwanted tickets being created. It turned out that the best choice for this problem would be the Notification type, the only events you'll receive there are about sent notifications. This allows to use the notification settings in Icinga 2 so that only the relevant events are emitted. The information about what caused the notification (event) to be send was a bit hidden in the JSON objects received from this stream, but after discovering it everything required was at hand.

As the Icinga 2 API could be useful for other things, a go package can be found on GitHub. Currently only event streams are implemented, but that could change in the future. Pull requests are welcome!

Round-trip Tickets

What prevented us from using our old solution was that Icinga 2 doesn't give you any information about what happened before the current event. There was no way to close a ticket if the problem disappeared. To solve this, a small caching layer was built using Bolt. Here the mapping from Icinga 2 host and service (which should be unique) to a rt ticket number is saved so tickets can be updated on new states or closed if the service goes back to OK.


This new tool is running for a few weeks now and works fine (with the occasional tweak needed). If you have a similar setup and want to use it, icinga2rt is on GitHub too. Again, enhancements are welcome!


Zugangsdaten verschlüsselt übertragen mit cryptorage

Posted by Daniel Rauer on Friday, November 11, 2016

Problemstellung: Zugangsdaten sicher übermitteln

Häufig müssen Zugangsinformationen wie Benutzernamen und Passworte an Kunden oder Partner übertragen werden. Dies können Zarafa Benutzerdaten sein, FTP Zugangsdaten, AuthCodes für Domains, und viele weitere sensitive Informationen die nicht per E-Mail übertragen werden sollten. Auch diese Herausforderung war ein Grund um unser Portal zum einfachen, verschlüsselten Datenaustausch cryptorage zu entwickeln. Hiermit können Dateien über eine Webanwendung hochgeladen werden: Sie werden automatisch verschlüsselt und der Empfänger bekommt die Daten zum Abruf der Dateien über getrennte Kanäle wie E-Mail und SMS.

Integration der Datenübertragung in unseren Workflow

Trotzdem war es immer ein wenig umständlich die Daten dann auch zu versenden. Sie mussten in eine .odt Datei mit unserem Briefpapier als Hintergrund kopiert werden, als .pdf abgelegt werden, dann musste man sich bei cryptorage anmelden und die Datei an den gewünschten Empfänger übertragen werden. Das sollte doch bequemer möglich sein!

Wir haben seit geraumer Zeit eine eigene Webanwendung (die Team App) für diverse interne Prozesse im Einsatz, es lag also nahe diese um eine Funktion zum Versand von Zugangsdaten zu ergänzen. Und da cryptorage über eine API [1] verfügt sollte das doch ohne grossen Aufwand möglich sein ...

Drei einfache Schritte zum perfekten Ergebnis

Klicken zum Vergrößern

  1. Die Daten werden von einem Mitarbeiter in ein Formular eingetragen und abgeschickt. Die Zugangsdaten werden dann serverseitig in eine .pdf Datei gerendert.
  2. Anschließend wird ein UploadRequest an die API gestellt [2] um Metadaten zu übermitteln und einen Dateislot zu reservieren.
  3. Es folgt der eigentliche Upload der .pdf Datei über einen weiteren Request [3].

Der Empfänger bekommt daraufhin eine E-Mail mit einem Link zum Abrufen der Datei, sowie eine SMS mit dem Passwort zum Entschlüsseln der Datei.

cryptorage Download E-Mail

Gerne unterstützen wir Sie bei der Integration

Falls Sie ebenfalls Interesse haben cryptorage in Ihren Workflow einzubinden sprechen Sie uns einfach an! Durch die flexible API sind vielfältige Möglichkeiten gegeben um aus Ihrer gewohnten Umgebung heraus Dateien schnell, einfach und sicher zu übertragen. Gerne stellen wir auch unseren Code zur Erzeugung und dem Versand von .pdf Dateien als Grundlage für Ihre Lösung zur Verfügung und passen ihn auf Ihre Bedürfnisse an. Sprechen Sie uns an damit wir Sie optimal beraten können!

Das Beste zum Schluss

Aktuell können Sie cryptorage 30 Tage kostenlos testen! Sie können währenddessen den vollen Funktionsumfang nutzen, eigene weitere Benutzer anlegen und unbegrenzt viele Dateien versenden. Registrieren Sie sich einfach unter cryptorage Webseite und beginnen Sie noch heute Dateien verschlüsselt auszutauschen.



Webinar Backup von Cloud-Infrastrukturen

Posted by Ingo von Thielau on Tuesday, November 01, 2016

ProfitBricks GmbH

Bacula Systems S.A.

Am 09.11. werden wir gemeinsam mit dem IaaS-Anbieter ProfitBricks und dem Software Hersteller Bacula Systems ein Webinar zum Thema Backup von Cloud-Infrastrukturen abhalten.

Das Webinar zeigt an ausgewählten Beispielen die Einsatzmöglichkeiten unseres gemeinsamen Angebotes, welches nun seit über einem Jahr besteht. Interessierte können sich über die Webseite von ProfitBricks anmelden.

9. November, 11 Uhr
bei ProfitBricks GmbH


bytemine auf der OpenRheinRuhr!

Posted by Felix Kronlage on Tuesday, October 18, 2016

OpenRheinRuhr Logo Nicht nur Kiel ist immer eine Reise wert - auch Oberhausen ist toll!

Wie bereits in der Vergangenheit verschlägt es uns dieses Jahr mal wieder nach Oberhausen. Dort findet am 5. und 6. November 2016 im LVR-Industriemuseum die OpenRheinRuhr 2016 statt.

Neben vielen Ausstellern gibt es auch ein reichhaltiges Vortragsprogramm. Ich habe die ehrenhafte Aufgabe am Sonntagmorgen den Frühsport machen zu dürfen! Um 10 Uhr erzähle ich etwas zu unserer idb und unsere Art des IT Infrastrukturmanagements.

Gerne zeigen wir an unserem Stand auch die Integration von privacyIDEA in die Kopano WebApp - dies passt auch gut, da wir direkt neben unseren Kollegen von Netknights stehen.

Besuchen Sie uns auf der OpenRheinRuhr 2016:

5. und 6. November
LVR-Industriemuseum in Oberhausen


2FA mit privacyIDEA in der Zarafa WebApp

Posted by Daniel Rauer on Friday, October 07, 2016

Nachdem wir gerade das google2FA Plugin für die aktuelle Zarafa WebApp angepasst haben konnten wir pünktlich zur gestrigen Kopano Konferenz ein eigenes Plugin veröffentlichen:

2FA mit Yubikey und privacyIDEA

Mit dem Plugin webapp-privacyidea ist es möglich sich zusätzlich zu der Anmeldung mit Benutzername und Passwort durch einen Yubikey als zweiten Faktor zu authentifizieren.

privacyIDEA ermöglicht es Benutzer und 2FA Token komfortabel zu verwalten, und über eine RADIUS Schnittstelle können Token und Benutzer validiert werden.

Diese Schnittstelle nutzt auch das neue Plugin: Ist es geladen und für den Benutzer aktiviert wird nach der klassischen Anmeldung zur Eingabe des Yubikey OTP aufgefordert. Dieser wird zusammen mit dem Benutzernamen zur Überprüfung an privacyIDEA gesendet; nur bei erfolgreicher Prüfung erfolgt die finale Anmeldung an der Zarafa WebApp.

Das Plugin bietet hierbei diverse Konfigurationsmöglichkeiten, um verschiedenen Szenarien und Bedürfnissen Rechnung zu tragen.

Klicken zum Vergrößern Klicken zum Vergrößern



2FA und Zarafa WebApp

Posted by Felix Kronlage on Wednesday, October 05, 2016

Dem Thema 2-Faktor Authentifizierung haben wir uns schon länger in verschiedenen Facetten verschrieben. Wir selbst setzen seit langem bei uns Tokens von Yubico im Zusammenspiel mit der quelloffenen Authentifizierungslösung privacyIDEA ein. privacyIDEA bietet dabei das Backend gegen welches die Token validiert werden; hierbei spricht man von 2-Faktor Authentifizierung.

Aufgrund unserer Erfahrung im Bereich Zarafa und Entwicklung hat uns unser Kunde Lumberg Connect GmbH angesprochen, ob wir ein bestehendes Zarafa WebApp Plugin zur Verwendung des Google Authenticators für die aktuelle Zarafa WebApp adaptieren können. Dieses Plugin wurde ursprünglich von Normann Thimm entwickelt. Selbstverständlich war für Lumberg auch, das die Auftragsarbeit nicht nur aus der reinen Adaption, sondern auch aus der sinnvollen Rückgabe der Patches in Form von Pull-Requests an den Autor stattfindet.

Die Einrichtung und Authentifizierung ist dabei denkbar einfach: Es wird ein QR-Code generiert (entweder durch die WebApp oder einen Google Dienst), welcher vom Anwender mit der Google Authenticator App gescannt wird. Anschliessend wird der Anwender nach jedem Login aufgefordert einen 6 stelligen Code einzugeben den die Google Authenticator App ihm anzeigt.

Klicken zum Vergrößern Klicken zum Vergrößern

In der aktuellen Version kann das Plugin nun auch mit der neuesten Version der Zarafa WebApp verwendet werden. Eine Adaption für die Kopano WebApp wird es in den kommenden Wochen geben.


Die erste Kopano Konferenz

Posted by Ingo von Thielau on Monday, September 26, 2016

Kopano Konferenz Webseite

Am 5. und 6. Oktober findet die erste Konferenz zum eigenen Fork der Zarafa-Macher Kopano statt und löst damit die bisherige Veranstaltungsreihe Zarafa Tour ab. Für das Ereignis wurde das wunderschöne Schloss Vaalsbroek in den Niederlanden, nahe der deutschen Grenze, ausgewählt.

Wir werden selbstverständlich als langjähriger Zarafa Gold Partner bei diesem Re-Launch der Veranstaltungsreihe dabei sein, und zwar als Sponsor. Weiterhin wird unser Geschäftsführer Felix Kronlage in unserer Rolle als Premium Partner von Univention einem Kurzbeitrag auf die Vorzüge der Kopano Integration, die mit dem Univention Corporate Server verfügbar ist, eingehen.

Als besonders interessant ist für viele sicherlich das Thema Zwei-Faktor-Authentifizierung. In diesem Kontext setzen wir selbst auf die Lösung privacyIDEA mit den allseits bekannten Yubikeys als Hardware-Token. Doch auch jenseits unserer Partnerschaft mit NetKnights, dem Hersteller von privacyIDEA, haben wir mit anderen Lösungen Erfahrungen gesammelt. Z.B. haben wir im Rahmen eines Kundenprojektes eine bereits für die WebApp 2.1 bestehende Integration des Google Authenticators für die WebApp 2.2 fit gemacht. Wer Fragen hierzu hat, kann uns natürlich gerne ansprechen.

Wir freuen uns auf ein Wiedersehen mit Kunden, Partnern und Gleichgesinnnten auf der ersten Kopano Konferenz.

Older posts: 1 2 3 ... 22