Interview mit Frank Karlitschek – Gründer von Nextcloud

2
Foto: Frank Karlitschek

Vor einiger Zeit hatte ich Interviews mit diversen Blog-Betreibern rund um die Thematik Open Source geführt. Nun wollte ich auch Entwickler zu Wort kommen lassen, was sie motiviert ihre Projekte als Open Source auf den Markt zu bringen.

Heute steht mir Frank Karlitschek, der Geschäftsführer und Gründer von Nextcloud, Rede und Antwort.

intux: Hallo Frank! Seit über sechs Jahren nutze ich privat Eure Cloud. Alles begann mit der owncloud auf dem Raspberry Pi. Mittlerweile läuft die Nextcloud auf einem vServer. Was hat Dich inspiriert, eine Cloud für jedermann zu entwickeln?

Frank: Ich bin schon seit über 20 Jahren in verschiedenen Open Source Projekten, wie zum Beispiel KDE aktiv. Dabei ging es immer darum den Benutzern die Kontrolle über Ihren Computer und Ihre Daten zu geben. Als vor einigen Jahren Cloud Services populär wurden, war mir klar, dass wir Open Source und verteilte Alternativen dazu brauchen. Das genau ist das Ziel von Nextcloud.

intux: Wie wichtig ist es Dir/Euch, dass die Cloud auf einem Einplatinencomputer wie dem Raspberry Pi läuft und so als Speicherlösung dem technikaffinen Heimanwender dient? War das eher Zufall oder Absicht?

Frank: Die Idee hinter Nextcloud ist, dass die Benutzer einen Service so betreiben können wie sie es für richtig halten. Das kann ein kleiner Homeserver sein oder ein großer Cluster für Millionen von Benutzern. Der Raspberry Pi ist hier sicherlich der Extremfall. Es ist uns wichtig, dass Nextcloud gut auf einem Raspberry Pi läuft, auch wenn wir, realistisch gesehen, schon empfehlen, etwas stärkere Hardware zu verwenden. Zum Beispiel ist es empfohlen einen redundanten Storage zu verwenden was mit einem Raspberry Pi schwierig ist. 

intux: Du hast ja Dein eigenes Projekt vor drei Jahren geforkt. Wie schwer fiel es Dir, ownCloud zu verlassen und mit Nextcloud neu zu starten?

Frank: Der Entscheidungsfindungsprozess hat viele Monate gedauert. Dem Kernteam und mir ist mit der Zeit aufgefallen, dass sich das damalige Projekt und die Firma in die falsche Richtung entwickelt haben. Auch die Entwicklercommunity ist geschrumpft, da das Unternehmen damals schlechte Entscheidungen getroffen hat. Ich habe damals versucht, das zu korrigieren, was mir leider nicht gelungen ist. So stand das Kernteam und ich vor der Wahl, die eigenen Ziele und Ideale aufzugeben oder eben den Fork zu wagen. Wir sind super stolz darauf, dass Nextcloud inzwischen besser und stabiler dasteht, als es das Vorgänger-Projekt es jemals war.

intux: Gab es während dieser Phase die Befürchtung es eventuell nicht zu schaffen?

Frank: Natürlich. Es gibt immer Dinge, die man nicht voraussehen kann. Das Ganze war schon ein kleines Abenteuer. Umso mehr freuen wir uns bei Nextcloud, dass wir jetzt besser aufgestellt sind als jemals zuvor. Wir haben die bessere und aktivere Community, wir sind 100% Open Source, was wir in der Vergangenheit nicht waren, die Software ist besser, schneller, sicherer und hat mehr Funktionalität, wir sind als Firma profitabel und haben keine Abhängigkeiten zu Investoren. Wir sind also etwas stolz darauf, dass sich das Abenteuer gelohnt hat. 

intux: Wie klug war es, die ownCloud unter die AGPL zu stellen, unter der nun auch auch die Nextcloud lizensiert ist?

Frank: Ich habe damals entschieden die AGPL zu nehmen. Nach wie vor finde ich, dass das die ideale Lizenz ist, um die Sicherheit, Offenheit und Unabhängigkeit von Nextcloud sicherzustellen.

intux: Welche Anforderungen gibt es an Community-Apps, und welche Revisionen müssen diese in Eurem Hause durchlaufen? Welche Regeln müssen die Entwickler einhalten?

Frank: Grundsätzlich ist ja Nextcloud komplett Open Source, was bedeutet, dass jeder die Software modifizieren und erweitern kann, ohne mit dem Kern-Team sprechen zu müssen. Wenn man allerdings in unseren App Store aufgenommen werden will, dann haben wir bestimmte Sicherheits- und Qualitätskriterien. Die App muss mit einem persönlichen Key des Entwicklers signiert sein, um sicherzustellen, das kein schadhafter Code einfließt. Außerdem haben wir eine Reihe von Sicherheit- und Qualitäts-Checks die man bestehen muss, um aufgenommen zu werden.

intux: Die Nextcloud wird immer populärer und wichtiger für Unternehmen und Behörden. Zuletzt gab es Meldungen, dass selbst die Bundesverwaltung auf Euer System setzt. Hast Du mit diesem Erfolg gerechnet?

Frank: Gerechnet nicht, aber gehofft habe ich es schon. Die Nextcloud Community entwickelt ja Nextcloud nicht nur zum Spass. Sondern wir hoffen schon, dass so viele Benutzer wie möglich Nextcloud nutzen. Wir wollen ja die Daten und die Cloud wieder dezentralisieren. Da freut uns der Erfolg und das positive Feedback schon sehr.

intux: Wie wichtig ist Dir/Euch die Community?

Frank: Die Contributor Community ist der Kern von Nextcloud. Zum Beispiel haben beim letzen Release über 2000 Freiwillige mitgewirkt. Das ist deutlich mehr als die ca. 30 Entwickler, die wir als Unternehmen bezahlen, um an Nextcloud zu arbeiten. Die Community ist also super wichtig, ohne die wir es nicht mit Microsoft, Google usw. aufnehmen könnten.

intux: Was ist Dein Lieblings-Betriebssystem und welches setzt Du produktiv ein?

Frank: Ach die Zeiten sind bei mir vorbei, wo ich noch Leidenschaft für Betriebssysteme hatte. 😉 Ich bin da inzwischen ganz pragmatisch. Auf dem Server verwende ich alles mögliche. Auf einem privaten Server verwende ich Ubuntu Server, da ich die regelmäßige Aktualisierungen mag. In der Firma verwenden wir viel Debian. Im Kundenumfeld arbeiten wir viel mit Red Hat und SUSE, da es dort guten kommerziellen Support gibt. Auf meinem Laptop habe ich MacOS und eine Fedora VM für die Entwicklung. Und dann habe ich sogar noch einen Windows PC für Gaming.

intux: Eine abschließende Frage noch: Bleibt neben Deinen zahlreichen Engagements für Freie und quelloffene Software eigentlich noch genügend Zeit für Hobbies?

Frank: Ja klar. Schliesslich ist ja Nextcloud auch mein Hobby. 😉
Aber Spaß bei Seite. Ich reise sehr gerne, was sich gut mit meinen vielen Vorträgen auf Konferenzen verbinden lässt. Außerdem fotografiere ich gerne. Am liebsten Portraits von interessanten Menschen. Einige davon kann man auf https://karlitschek.de/photos anschauen.

intux: Vielen Dank für das Interview, Frank.

Mastodon dockerized auf anderen Server umziehen

0
Quelle: https://github.com/tootsuite/mastodon

Wenn man die Docker-Variante von Mastodon auf einen anderen Server umziehen möchte, geht das recht einfach. Ich setze hierbei voraus, dass Docker-Compose auf dem neuen Server schon installiert ist und der Reverse Proxy analog dem alten Server inklusive Zertifikaten eingerichtet wurde.

Vorbereitung auf dem neuen Server

Der Server sollte im beschriebenen Fall als root über den Port 22 während des Kopierens erreichbar sein. Auf dem neuen Server wird nun das Verzeichnis /root/live angelegt.

Daten vom alten auf den neuen Server kopieren

Zuerst werden alle Masodon-Container gestoppt. Damit geht die Instanz offline.

Danach bedienen wir uns rsync und starten den Datenversand auf dem alten Server.

Vorgehensweise auf dem neuen Server

Nachdem die Daten kopiert wurden, gehen wir auf dem neuen Server in das zuvor erstellte Verzeichnis und starten die Container.

Zum Schluss sollten die Rechte für das Verzeichnis puplic wieder angepasst werden.

Wenn alles wie zuvor schon beschrieben eingerichtet wurde, sollte die Mastodon-Instanz, nach dem Setzen der neuen A-Records, auf dem neuen Server nun wieder erreichbar sein.

Viel Spaß!

DD-WRT auf OpenWrt

0
LoboStudioHamburg / Pixabay

Vor einiger Zeit hatte ich meinen Router TP-Link Wr940n mit DD-WRT geflasht. Leider musste ich feststellen, dass ich meinen Repeater nicht mehr in das Netzwerk einbinden konnte. Da ich zuvor schon OpenWrt auf den Router installieren wollte, hatte ich nach einer geeigneten Anleitung gesucht. Leider bin ich damals nicht wirklich fündig geworden.

Hier nun mein Lösungsweg, um den Router von DD-WRT auf OpenWrt zu flashen:

Vorbereitung

Zuerst musste im Webinterface von DD-WRT der SSH-Zugang über Port 22 freigegeben werden.

DD-WRT – SSH Zugang

Dann wurde die von OpenWrt heruntergeladene Firmware via Terminal mit scp an den Router in das Verzeichnis /tmp übertragen.

Installation

Hierzu wählt man sich via SSH in den Router ein

und wechselt dort in das Verzeichnis /tmp.

Jetzt führt man den folgenden Befehl aus:

Nach ein paar Sekunden ist die neue Firmware installiert und der Router startet neu.

Achtung: der OpenWrt-Router hat nun eine neue IP-Adresse!

Nach der Eingabe von http://192.168.1.1 im Browser kann man sich als root ohne Passwort einwählen und den Router konfigurieren.

OpenWrt

Ein SSH-Zugang ist ebenfalls über diese IP-Adresse möglich.

SSH OpenWrt

Viel Spaß!

Prosody checken

0
qimono / Pixabay

Hier ein paar wichtige Befehle, um die Gesundheit meines XMPP-Servers zu checken.

Konfiguration von ddclient für spDYN

0
geralt / Pixabay

Vor einiger Zeit bin ich zum Dynamic-DNS-Service von Securepoint auf spDYN umgezogen. Das Konfigurationsfile für ddclient sieht hierfür wie folgt aus:

Zuvor muss man sich natürlich einen Account bei Securepoint Dynamic-DNS-Service einrichten. Die Konfigurationsdatei ist dann entsprechend (eMail, Passwort, Host Name) an die eigenen Daten anzupassen.

GRUB2 reparieren

2
Super Grub2 Disk

Ich hatte am Wochenende das Problem, dass mein GRUB2 (GRand Unified Bootloader) nicht mehr wollte. Mit Hilfe von Super Grub2 Disk konnte ich mein System booten und den GRUB im laufenden System nach dem Wiki-Eintrag zu GRUB 2 reparieren.

Conky auf der GNOME Shell

0
Systemmonitor Conky
Systemmonitor Conky

Ein kleiner Systemmonitor, wie er auf dem Beitragsbild zu sehen ist, lässt sich auf der GNOME Shell unter Debian schnell einrichten. Dazu wird zuerst das Paket conky installiert.

Dann erstellt man die Datei ~/.conkyrc mit

und kopiert den nachfolgenden Inhalt hinein.

Das Ganze wird mit Ctrl + o gespeichert und der Editor mit Ctrl + x wieder verlassen. Im Anschluss richtet man den Autostart ein.

Auch hier wird der Inhalt hinein kopiert und die Datei gespeichert.

Nach einem Reboot sollte der Desktop in etwa so aussehen wie auf der Abbildung oben.

Quelle: https://www.hiroom2.com/2017/06/26/debian-9-install-conky/

Nachtrag

Im Beispiel werden die Informationen zum WLAN ausgegeben. Wer LAN oder beides überwachen möchte, sollte dies noch entsprechend anpassen.

Größe des Swap am vServer ändern

0
jarmoluk / Pixabay

Da ich nun testhalber Mastodon selbst hoste und mein vServer mit dem zur Verfügung gestellten RAM in den Spitzen einige Probleme hatte, musste ich den Swap-Speicher entsprechend vergrößern. Die voreingestellten 256MB bei 6GB RAM waren dann schon etwas knapp. Der neue Swap wird nun über ein Swap-File realisiert. Dazu wurde ein entsprechendes File (2GB) wie folgt angelegt

und die Rechte entsprechend gesetzt.

Nun musste folgender Eintrag mit

noch in die /etc/fstab eingetragen werden, damit die Änderungen auch einen Neustart des Servers überleben.

Um Konflikte zu verhindern, wurde die alte Swap-Partition auskommentiert.

Abschließend erfolgte die Abschaltung des alten Swap das Mounten des neue und die Aktivierung des neuen Swap-Speichers.

Upgrade Mastodon Docker

0
Quelle: https://blog.joinmastodon.org/

Das ging aber jetzt fix Mastodon Docker von Version 2.8.3 auf 2.8.4 anzuheben.

Farben des Elgg-Themes ändern

0
TeroVesalainen / Pixabay

Für die Community-Seite von hality.org habe ich mich damals für Elgg entschieden. Mit diesem CMS wird alles abgedeckt, was wir als Community brauchen. Elgg bringt von Hause aus schon ein recht gutes Responsive Theme (Aalborg) mit.

Das einpflegen eines Logos lässt sich via Plugin HeaderLogoChanger realisieren. Die Farben des Themes passt man in der layout.css via

an. Wirksam werden diese Änderungen jedoch erst nach dem Rücksetzen der Seitencaches.