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

Roadmap infrastructure database 2017

Posted by Felix Kronlage on Thursday, April 27, 2017

As we expose more customers to the infrastructure database and present the IDB at conferences more ideas pop up what to do next and what kind of features we - as well as customers - want to see within the product. With the release of the IDB-core as well as the adapters on github under OSI-approved licenses last year, we've accomplished the major milestone for the first year: Make sure that an internal tool becomes an open source solution.

We're currently within the scope of the 1.6 version. The versioning and development scheme of the IDB is fairly simple: We develop on the development branch, this is the default branch for the project, from which new versions are cut on release branches. For the 1.6 line we've reached the point where we will only add bug-fixes that are critical to a customer. That's why there is now a 1.6 branch from which potential 1.6.4, 1.6.5 releases will be made.

While the features of the IDB-core are tied to the main IDB version, features that only concern adapters are not coupled to this. As such, we have a version-based roadmap for IDB-core and a roadmap for the adapters. The roadmap lists all the major features to give you an idea on where we are heading, but it does not cover all the little improvements, bug-fixes and smaller ideas we are working on. For these, please check the issue tracker over at github.

Roadmap of IDB-core

Version 1.7 - to be released at the end of the second quarter 2017.

The 1.7 version will provide two major features that we've been working on this year:

  • Multi-Tenancy
  • The V3 version of the API


The IDB has the concepts of owners. Owners are associated with ressources like machines, inventory items and such. The multi-tenancy allows to scope the view of users within the IDB to a set of owners. We have a blogpost in the pipeline on how we implemented this.


With the third version of the API we want to introduce visibility of all ressources and not just machines and software components. For this to work in a good fashion, we had to make sure that we have scoped visibility first - which is the ground work of the multi-tenancy. From the list of things that the APIv3 will enable us to do, you see that this is one of the major items in the near future:

The APIv3 will allow us to access the complete datamodell of the IDB and opens us to the possiblity to finally add our NeDI as well as oxidized integration, since not only switches and networks can be added via the API as well, we can also attach files to objects in order to store router and firewall configurations.

The Ansible adapter mentioned in the section on adapters further down in this post will rely on the APIv3 and will be part of our work towards version 1.7.

Furthermore we want to look into reporting functionality - however this should not live inside the core application but instead be done by a real reporting tool. With the APIv3 it should be possible to hook software like JasperReports into the IDB for reporting.

Version 1.8 - to be released at the end of the third quarter 2017.

Major items for version 1.8 will be:

  • Password and credential management via Vault
  • Dashboard view with widgets
  • Expectation management

Password and credential management via Vault

An integrated password manager based on Hashicorp's Vault will be one of the major 1.8 features. Since the IDB adapters crawl lots of information sources, and we would want to store arbitrary credentials to ressources in a secure manner, anyways adding a password management for the users is another nice benefit.


The current interface is very technical and and not very appealing. For many tasks the table based UI is helpful, for quick overviews a dashboard-like interface could be very appealing as well. The idea is that users can create their own reporting widgets on the dashboard, for example to always list the ten machines that have the oldest serviced date. Most of the time, I look at the same set of data to begin with anyways.

Expectation management

Expectation management is the feature where we want to highline differences between the expected state of a ressource and the actual state. We will start this feature by adding the possiblity to submit network scans to the API of the IDB, and display whether any network ports are open on a maschine that should not according to the configuration within the idb. The application should then warn about this. Since we expose this kind of information over the API as well, one could even hook this into a monitoring system, that checks the IDB regularly for objects that do not reflect the desired state and alert upon that. Important: the infrastructure database is about aggegrating and summarizing information, the alerting needs to be done from the corresponding alerting tool.

Version 2.0 - to be released in time for christmas 2017.

For the 2.0 version we will only have the compliance feature on the agenda. We want to reserve development time for fine-graining the features that we added throughout the 1.7 and 1.8 release cycles.


The underlaying architecture of the core application already tracks changes to the objects. How cool would it be, if we would extend that with WORM functionality, so that the history of an object in the IDB can not be tampered with. If a system represented a certain state at one moment, this should be visible in the IDB and it should not be possible to adjust the past to match expectations.

Roadmap for the adapters

This is a list of adapters we will focus on throughout 2017.


The idbiaas adapter crawls various Infrastructure-as-a-service providers. We've started with DigitalOcean as well as libvirt-based environments. The next ones we want to add:

  • OpenStack
  • Amazon AWS
  • CloudStack

Ansible adapter

Since Ansible became quite popular, and couple of our partners and customers showed interest in having support for Ansible, we will provide an ansible adapter. Part of this work will be to make sure the IDB can serve as an external node classifier / inventory provider for Ansible as well.

OPSI adapter

OPSI is a solution for client management and has (as a linux-server based solution) a strong focus on Windows desktops. This is something we do not cover very well at the moment. Our idbad adapter is an attempt to gather information in Windows-based environments. OPSI features a nice REST-API and not only holds information about the machines but since it is used to distribute software to the clients, we can gather all the infos on the rolled-out software from it as well.

PuppetDB adapter

We've originated with the IDB with a strong focus on Puppet as an information source. As such, the PuppetDB information retrieval is currently not handled via an adapter, but as an internal process within IDB-core. To assure that all data that enters the infrastructure database goes via the one central point, we're going to rework the PuppetDB connection to a proper adapter.


Kopano - DeskApp als Standardmail-App einrichten

Posted by Ingo von Thielau on Tuesday, April 25, 2017

Kopano Webseite

Nicht gerade wenige Programme erlauben es, Dokumente direkt per E-Mail zu versenden. Sinnvoll ist das zum Beispiel, wenn man ein Dokument scannt. Das macht man ja nicht weil man es leid ist, aufs Papier zu starren. Eher will man es anderen zugänglich machen ;-).

Weitere Anwendungsszenarien:

  • Tabellenkalkulation: „Dokument per E-Mail senden“ öffnet direkt eine neue E-Mail mit der entsprechenden Tabelle als Attachment
  • Dateibrowser: Über das „Senden an“-Menü kann eine Datei direkt an eine E-Mail angehangen werden (… wenn man kein Drag&Drop nutzen möchte)

DeskApp als Standardmailclient unter Windows

In Windows gibt es die Funktion „Standardprogramme“. Diese erreicht man am einfachsten, indem man unter Start -> Ausführen oder in Windows 10 im Suchfeld neben dem Start-Button nach „Standard“ sucht (Bild 1). Windows 10 bittet dann um die Wahl der Standard-App für Kategorien. Die DeskApp wird dann als Standard-App für E-Mail gewählt (Bild 2).

Windows 7 hingegen listet alle Programme auf und lässt diese dann als Standard für alles was sie vorgeben zu können erheben. Ein Klick auf „Standards für dieses Programm auswählen“ listet dann alle möglichen Standards und bekannten Dateiendungen auf, die man manuell wählen kann. Das tut bei der DeskApp aber nicht Not – die wird einfach als Standard für alles was sie kann gewählt (Bild 3).

Click to enlarge Click to enlarge Click to enlarge

DeskApp als Standardmailclient unter macOS

Unter MacOS – das ist das OS, bei dem alles sehr intuitiv gehalten ist 😉 – ist alles anders. Hier muss die mitgelieferte Mail.app gestartet werden. Im Menüpunkt „Mail“ gibt es den Punkt „Preferences“, der den im Bild 4 zu sehenden Dialog öffnet. Dort findet sich das „Default email reader“-Dropdown, in welchem die Kopano DeskApp gewählt werden kann.

Click to enlarge

DeskApp als Standardmailclient unter Linux/Ubuntu

Ich nutze Ubuntu mit einer Gnome Shell. Hier findet sich die Einstellung der Standardclients als „Vorgabe-Anwendungen“, indem man nach „Einstellungen“ sucht und dort unter System -> Details wählt (Bild 5).

Click to enlarge

Disclaimer: Text und Bildmaterial wurde mit freundlicher Genehmigung bereitgestellt; Quelle


Kopano DeskApp autodiscovery

Posted by Felix Kronlage on Thursday, April 20, 2017

Kopano Webseite

There is a nice little feature in the Kopano DeskApp that makes you happy if you server an environment that holds a tad more than a dozen users and where you want to make it as easy as possible to login into the Kopano account for DeskApp users: autodiscovery of the servername.

Click to enlarge Click to enlarge

By adding a txt record to your DNS Zone, you can point the users based on their e-mail address to the correct WebApp address. Since the DeskApp connects to the configured WebApp host, this is where the setting comes from.

$ dig -t txt bytemine.net | grep webapp
bytemine.net.        170    IN    TXT    "kdiscover https://webapp.bytemine.net/"

Nice little settings helper!


The felt dependency on Microsoft Outlook

Posted by Andreas Rösler on Monday, April 17, 2017

This is a guest post by my friend and colleague at the OSBA Andreas Rösler - one of the minds behind Kopano.

Andreas published on his blog a german post on "the felt dependency on Microsoft Outlook" that I really liked and wanted to have a english version of it available. Please enjoy reading!

felix kronlage

The felt dependency on Microsoft Outlook

On 10th April an international journalist team around Harald Schumann of the German tagesspiegel published the results of researches they did over several months about “Europe’s dire dependency on Microsoft“. The article mainly focuses on LibreOffice as an alternative to Microsoft Office. I can only underline all of the explanations, experiences and facts described in this article from my eleven years of experience in the OpenSource groupware scene.

This post is not supposed to be any form of Microsoft-bashing. It is not the one big company, but the relationship between the company and its customers from the public sector - the ratio can be equated well with a strong, but only felt dependency. Why a "strong, but only felt dependency"? Because it is not correct to accuse Microsoft alone for this dependency. The other side easily could break out. But it does not do it. Microsoft is also not the only group that behaves in this way. However, the number of those who do not work with its software on a daily basis is rather countless.

Our evolution with the market power

Us - this means my company, my colleagues and myself - have seen the market power of Microsoft on the clients-side already a long time ago. With Zarafa we have built an alternative solution. Our goal at that time was to offer a server for Microsoft Outlook, which does not have to come from Microsoft. This had initially technical advantages, then financial and ultimately the word "openness" played an increasingly important role. This openness meant Open Source, but also the interfaces to user management systems or other infrastructures. While Microsoft Exchange - to the present the Microsoft server component behind Outlook - necessarily requires a Microsoft ActiveDirectory, which requires a Microsoft Windows server and so on, we were almost open from the beginning for OpenLDAP, Novell eDirectory and all other user directories following the Open LDAPv3 standard.

The leading client for Zarafa was MS Outlook. Why? Convenience. There is hardly anyone in the corporate world who does not have it. In addition to MS Word and MS Excel, quoted in the named article, Outlook is not just another, but in my experience a much stronger lead into this dependency. With its office suite LibreOffice offers good alternatives to the two first mentioned solutions. Here, as a user, you may be bothered by the look and feel and the little things that you can solve with trainings, as described in the article. But which software is used as an user in order to efficiently manage his e-mails, appointments, tasks and contacts? Here the market is sown thinly.

When Outlook 2010 was released, we realized at Zarafa that things are going to change. Where previously fixed, standardized out of habits interfaces were, there were suddenly fixed dependencies to MS Exchange in elementary basic functions. Maybe you realized it: where the Outlook installation routine used to ask whether you have Exchange, Lotus Notes, Groupwise, POP3 / IMAP or another mail server, the program asks for Office365 or Exchange only these days - both are from Microsoft. Even their connection to Outlook was changed. Outlook can no longer be the leading client of a groupware that is not named Exchange or Office365. Last but not least, we created Kopano as a fork from Zarafa, which primarily connects its own clients - DeskApp and WebApp. In doing so, we address exactly the dilemma posed in the previous paragraph.

The addiction to Outlook

Regarding the daily workflow in offices without Microsoft Outlook, I would like to quote a department manager of one of our customers in the public sector. The task she gave me was so special in my memory:

"Please give us something - anything - so that those who can no longer work with Outlook do not feel like second-class people!"

No Outlook = second class people?!?

This quotation summarizes in all brevity and conciseness, why I wrote in the summary of a "strong, but only felt dependency". What has Outlook that other solutions - in this case our own - do not have? Already one and a half years ago I once listed ten thoughts to ask when it feels like being dependent on Outlook. And it clearly shows: One can replace Outlook. Today we are even a few steps further.


"What is there to counteract Outlook? It should only be the same as Outlook." - a requirement, which I have heard in the last ten years countless times. "What does Outlook do?", is my usual reaction to this. Very few things are listed which our DeskApp does not cover. Mostly one wants to edit e-mails, use shared calendars, send e-mails directly from his desktop. And the assistance of the management needs Outlook – A vicious circle: Why does the assistance need Outlook? Because she learned it. Tadaa This is precisely the "dependence on the one provider" which "slows down the technical progress in the public sector", as Dietmar Harhoff, Director of the Max Planck Institute for Innovation and Competition, was quoted in the article .

And there are, the alternatives. One of these is our Kopano DeskApp. This "non-Outlook" runs on Windows, on macOS and on Linux. It even looks a bit like Outlook. You can write emails, work together in calendars, delegate tasks - actually do all that Outlook can do. And if you want to send a document in Microsoft Word or LibreOffice Writer, the DeskApp jumps up and a new e-mail with the attached document is ready for dispatch.

New dependencies on the part of Microsoft have been installed slowly and steadily in the form of Sharepoint and Skype. The Kopano DeskApp supports a file integration to integrate any file storage one already has in use and web meetings to communicate quickly and directly with one another.

There is endless more. But the most important thing is: All this is open source. This is how we can earn money as an European company, which we have been demonstrating for years. And that is how we deliver confidence. Our source code can be checked. There are the experts - be it in the student community, at the Max Planck Institute, or in the company specialising in audits, which also do this occasionally. Vulnerabilities in terms of security or compatibility are thus sought and discovered by a swarm intelligence. This helps everyone and does not exclude others from using their knowledge and experience.

Last but not least, it is a basis for innovation. Our files integration was a community add-on of a student of the university of Graz. We liked it and have taken it into our product and significantly expanded it. The web meetings are based on spreed.me, which is published under the AGPL license as well. Partners integrate their solutions, such as e-mail archiving software and others. All this goes without complex contracts, manufacturer certifications and mutual license payments, which would have to be paid by the customer in the end. This is innovation made by Open Source!


I could still write endlessly on this subject. With our customers and those who want to become one, and also in the OSB Alliance, I am almost always talking about these issues. But the main message of this blog post is: There is a dependency on Microsoft. This is, first and foremost, in the minds and is technically predominantly only a felt dependency. Courage is the only thing needed by the single authority to go the step away from Microsoft. Some already did it. We and many others in our ecosystem do everything to enable more of them!

Thanks to the journalist team for this work! The article describes everything I have experienced again and again for more than ten years.


Umstellung auf Kopano im Groupware Hosting

Posted by Ingo von Thielau on Monday, March 20, 2017

Kopano Webseite

Nach dem erfolgreichen (Re-) Launch von Kopano im vergangenen Jahr, freuen wir uns mitteilen zu können, dass wir unser Groupware Hosting komplett auf Kopano umgestellt haben. Der sorgfältig geplante Umstieg der beteiligten Server im Verbund verlief ohne große Auffälligkeiten oder Störungen.

Unseren Kunden stehen mit Kopano selbstverständlich alle vom Hersteller angebotenen Clients zur Verfügung: Neben der bereits von Zarafa bekannten WebApp können Kunden auch die DeskApp als Desktop Client einsetzen. Weiterhin stellt die Kopano Outlook Extension Benutzern von Microsoft Outlook einen erweiterten Funktionsumfang bei Anbindung per ActiveSync (via Z-Push) bereit, welches auch für die Anbindung mobiler Endgeräte zum Einsatz kommt.

Kopano tritt damit die Nachfolge von Zarafa in unserer Infrastruktur an und ist für uns die ideale Grundlage für gemeinsames, produktives Arbeiten. Als Open Source affines Unternehmen freuen wir uns insbesondere über den Schritt zu einer komplett quelloffenen Lösung und einem Abschied vom Open Core Modell. Wer Interesse an der Entwicklung hat findet im Kopano Community Portal neben dem Quellcode auch tagesaktuelle Softwarepakete, Fehlerberichte und ein stetig wachsendes Wiki.

Neugierig geworden? Nehmen Sie mit uns Kontakt auf oder besuchen Sie den Gemeinschaftsstand von Kopano und Univention auf der CeBIT in Hannover.


Tooling im Alltag - REST-API und Lexware

Posted by Felix Kronlage on Tuesday, February 14, 2017

REST-API als Microservice vor Lexware

Wir mögen Schnittstellen die als REST API implementiert sind, wir finden Microservices ganz klasse - aber vor allem sind Arbeitsabläufe, die sich angenehm in bestehende Werkzeuge einbetten lassen, im Alltag eine tolle Arbeitserleichterung. An dieser Stelle sind Microservices ein schönes Werkzeug.

Problemstellung: Zugriff auf die Datenbestände im Lexware

Das Herz eines Wirtschaftsbetriebes - auch wenn technik-verliebt wie die bytemine - ist die Faktura, Warenwirtschaft, Angebots- und Auftragsverfolgung. Wir setzen hier seit vielen Jahren Lexware ein. Dies wurde bei uns 2007 (seinerzeit "Faktura + Auftrag") eingeführt und ist bisher zwar immer wieder aktualisiert (mittlerweile sind wir bei Warenwirtschaft Pro) - jedoch nicht abgelöst worden (dazu gerne an anderer Stelle mehr).

Damit ist Lexware eine der wenigen nicht Open Source Lösungen die wir einsetzen. Bereits seit Längerem gibt es einige Arbeitsabläufe, die wir gerne anders als von Lexware vorgesehen gestalten würden. Des weiteren war die Verzahnung von Faktura und unserem Ticketing (Request Tracker) etwas, das wir zunehmend vermisst haben. Gerade in einem Betrieb, der primär im ITSM Bereich unterwegs ist, stecken viele abrechnungsrelevante Informationen im Ticketing.

Basierend auf RT-REST hab ich schon vor einigen Jahren ein internes Java-Tool geschrieben, mit dem wir die Erstellung von Abrechnungen aus dem Ticketing heraus stark vereinfachen konnten. Mittels dieses Werkzeuges erzeugen wir auch monatliche Übersichten für unsere Kunden mit Stundenkontingenten.

Letztes Jahr wollten wir dann zusätzlich einen E-Mailversand unserer Rechnungen etablieren. Dabei sollte es jedoch so sein, das alle Rechnungen (welche im Lexware entstehen) und digital verschickt werden, über das Ticketing versendet werden, so dass sichergestellt ist, das der Versand jeder Rechnung mit Datum und Empfänger(n) jederzeit nachvollzogen werden kann.

Click to enlarge

Für eine möglichst universelle Nutzung und damit wir es in eines unserer internen Tools - die Team-App (die Daniel bereits im November vorgestellt hat) - integriert bekommen, wollte ich dies als REST-API implementieren.


Als Framework für die Implementierung des REST-Service habe ich mich für das Java Framework Dropwizard entschieden. Damit lässt sich mit wenigen Schritten ein einfacher Webservice programmieren. Eine Alternative dazu wäre sicherlich Spark gewesen. Der Service exportiert jetzt Ressourcen wie Kunden, Aufträge (von Angebot, über Auftragsbestätigungen zu Rechnungen und Gutschriften) und diverse Jobs.

SQL Anywhere

Die grosse Hürde stellt dann - so dachte ich - die Sybase Datenbank von Lexware dar. Diese läuft auf dem Windows Server zusammen mit Lexware. Unter Windows gibt es diverse Tools, mit denen man sich einen weiteren Datenbankbenutzer anlegen kann, um als dieser von Windows Systemen dann via ODBC auf die Sybase zuzugreifen. Mir war aber die Zugriffsmöglichkeit von einem Linuxsystem aus wichtig. Wenn man im Internet nach "Sybase Lexware" sucht, findet man ausschliesslich Zugriffe aus Windows heraus. Erst wenn man konkret nach "JDBC Sybase" schaut, findet man hilfreiche Anleitungen.

SAP hat vor einiger Zeit Sybase aufgekauft und so gibt es - mittlerweile bei SAP - das SQL Anywhere. Dies kann man in der Version 16 auf OS X, Linux und Windows installieren. Unter Linux hat man dann einen JDBC-Treiber (sajdbc4.jar) sowie ein Shared-Object. Beides wird für den Zugriff benötigt.

Im Java-Code verwendet man dann einen regulären JDCB Treiber:

String lxodbcUrl= "jdbc:sqlanywhere:uid=USERNAME;pwd=PASSWORD;eng=LXDBSRV;

DriverManager.getConnection(lxodbcUrl); ist hierbei die Adresse des Windows Servers. LXDBSRV ist ein Alias (welcher automatisch(?) in Lexware Mehrplatzumgebungen existiert).

$ export LD_LIBRARY_PATH=/opt/sqlanyhwere/lib64
$ /usr/bin/java -Djava.library.path=/opt/sqlanywhere16/lib64/ -jar rt-crm-api-0.0.1-SNAPSHOT.jar server rt-api.yml

Hier sieht man auch den typischen Aufruf eines Dropwizard-Programms. In der rt-api.yml sind diverse Konfigurationsoptionen abgelegt.

Voilà: REST Api

Auf diesem Wege haben wir jetzt eine schöne REST-API um bestimmte Aktionen und Informationen im Lexware abzufragen, und können diese gleichzeitig mit Abfragen aus dem Ticketing verknüpfen.

Im folgenden Screenshot sieht man die Maske zum Verschicken einer Rechnung. Es muss lediglich die Rechnungsnummer eingeben werden. Anhand dieser wird der richtige Adressat aus dem Lexwarebestand geholt, und das passende Rechnungs-PDF anschließend über unser Ticketing verschickt. Gibt es dazu bereits einen bestehenden Vorgang (=> Ticket), beispielsweise mit dem Angebot, dann kann hier auch das bestehende Ticket angegeben werden.

Click to enlarge

Als nettes Nebenprodukt ist gleichzeitig ein Lexware-Adapter für die IDB entstanden: Kontakte aus dem Lexware können so bei den entsprechenden Ressourcen in der IDB angezeigt werden. Aber dazu mehr in einem separaten Blogpost.


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!

Older posts: 1 2 3 ... 23