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

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

EN

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!

EN

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.

Alternatives

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

Summary

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.

DE

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.

DE

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.

Dropwizard

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;
database=F2;links=tcpip(host=10.10.1.10:2638);driverType=4;"

DriverManager.getConnection(lxodbcUrl);

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

EN

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!

DE

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!

cryptorage4ucs

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.

Dateinamenverschleierung

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

EN

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

nomenclature

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!

EN

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.

Closing

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!

DE

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.

Dokumentation

Older posts: 1 2 ... 22