Mai 27, 2022

Hubzilla in der Dose (HiD)

Stand: 16.02.2019

Mein Hubzilla in der Dose läuft!

Hier werde ich nun in lockerer Folge die einzelnen Schritte erläutern, die man bis zum Ziel abarbeiten muss (oder sollte), um einen eigenen Hub auf einem Raspberry Pi daheim ins Netz zu bringen.
Ich versuche es so zu beschreiben, dass auch nicht ganz so erfahrene Nutzer nachvollziehen können, was alles zu tun ist… und ermutigt werden, das Projekt nachzuvollziehen.
Klar… überwiegend schreibe ich aus meiner(!) Perspektive und beschreibe auch, wo ich auf Probleme gestoßen bin und wie ich diese gelöst habe.

Viel Spaß beim Lesen… und vielleicht beim Nachmachen…

1 – Erste Schritte

Um einen Hubzilla-Hub auf einem Raspberry Pi zu installieren, braucht man zunächst einmal einen… … … genau, einen Raspberry Pi (Raspi). Es gibt inzwischen einige Modelle mit unterschiedlichen Spezifikationen und Features. Aktuell sind die Modelle 3 A+, 3 B, 3 B+ und Zero.

Modellwahl

Die 3er-Modelle unterscheiden sich zunächst durch Prozessortakt und Hauptspeicher. 3 A+ und 3 B+ sind mit 1.400 MHz getaktet, 3 B mit 1.200 MHz. Sie laufen mit einem ARM Cortex-A53 64-Bit-Prozessor mit 4 Prozessorkernen. Das A-Modell verfügt über 512 MB Hauptspeicher, die B-Modelle über 1 GB. Der Zero wird mit einem ARM11Prozessor, 1.000 MHz und nur einem Prozessorkern betrieben. Der Hauptspeicher liegt bei 512 MB.

Das Zero-Modell funktioniert sicherlich, denn das war ja der Typ, mit dem Marlon seine erfolgreichen Versuche durchgeführt hat. Allerdings sind Hauptspeicher und Prozessorleistung wichtige Faktoren für die Leistungsfähigkeit, weshalb ich die Modelle 3 A und 3 B für geeigneter halte.

Die Taktfrequenz von 1.200 MHz des Modells B sollte ausreichend sein. Gegen das Modell A+ spricht für mich der Hauptspeicher, der mit 1/2 GB ein wenig knapp bemessen ist… und die Tatsache, dass es über keine Ethernet-Schnittstelle verfügt. Klar… WLAN haben sie alle und man kann das auch für einen Hub nutzen… ich persönlich bevorzuge aber ein Kabel (WLAN nutze ich nur, wenn es auf Ortsunabhängigkeit ankommt… ist meine persönliche Macke). Modell A bietet außerdem nur eine USB 2.0 Schnittstelle, wogegen die B-Modelle mit vier daherkommen (das ist praktisch für die Installation Tastatur und Maus brauchen schon zwei USB… so kann man sich einen externen HUB sparen).

Für mich fiel der 3 A+ damit raus… Ich habe mich deshalb für das Modell 3 B entschieden, weil es für mich sofort verfügbar war und mich die „fehlenden“ 200 MHz nicht gejuckt haben. Grundsätzlich sollte es aber mit allen angesprochenen Systemen klappen, einen Hub aufzusetzen. Meine Beschreibungen sollten auch unabhängig vom Modell funktionieren (bei Modellen ohne Ethernet-Schnittstelle muss man aber noch das WLAN konfigurieren).

„Verpackung“ und Zubehör (die Dooose)

Wenn man den Raspi nicht irgendwo speziell einbauen möchte, dann sollte auch ein Gehäuse her. Ich habe das Standard-Gehäuse 3B+ in schwarz gewählt. Ein passendes Netzteil muss auch sein… und eine SD-Speicherkarte… 8 GB sollten es schon sein… 16 GB sind besser. Für die Installation benötigt man dann noch ein HDMI-Kabel für den Anschluss eines Monitors, eine Tastatur und eine Maus. Für den Ethernet-Anschluss muss man natürlich auch noch ein passendes Kabel haben.

Ich habe mir ein komplettes Set bestellt, bei dem außerdem noch Kühlkörper für die Chips das Raspi dabei waren. Über die Notwendigkeit von Kühlkörpern scheiden sich die Geister… eigentlich sollen sie gar nicht nötig sein… aber ehrlich… die kosten auch einzeln nicht viel und Kühlung schadet echt nicht.

Der mechanische Zusammenbau ist keine Kunst. Die Kühlkörper sind schnell aufgeklebt und die Platine findet selbsterklärend Platz im Gehäuse… zu schrauben braucht man nichts.

Ein Betriebssystem installieren

Raspbian

Auf einem Raspi kann man etliche Betriebssysteme installieren. Für einen Hub und weil es der Standard ist, habe ich mich für Raspbian entschieden, eine Debian Linux Version für den Raspi. Man kann Raspbian z.B. hier herunterladen: Raspbian.
Wer Windows nutzt kann nun das entpackte Image z.B. mit Win32DiskImager auf die SD-Karte bringen, MacOS- und Linux-Benutzer erledigen das mit dd.
Das beschreibe ich hier jetzt aber auch nicht ausführlich. Das sollte man schon hinbekommen (ggf. im Netz danach suchen).

Man verkabelt nun den Raspi (Monitor an HDMI, Maus und Tastatur an USB), setzt die SD-Karte in den Slot und stöpselt schließlich das Netzteil an (damit startet der Raspi, der keinen extra Netzschalter hat).

Bootet man den Raspi, landet man nach einiger Zeit bei dem Programm raspi-config, wo man die erforderlichen ersten Einstellungen vornehmen kann. Sinnvoll ist es, den Menüpunkt „Expand Filesystem“ zu wählen, damit die Partition auf die gesamte SD-Karte ausgedehnt wird (wirksam erst nach Reboot). Das Konfigurationsprogramm ermöglicht es auch, Tastatur und Systemsprache (locale) auf die eigene Sprache (vermutlich Deutsch) umzustellen. Dann folgt ein Reboot. Man kann dann auch noch die Auslagerungsdatei (swap) auf 1024 MB erweitern und sollte anschließend die Software aktualisieren. Dazu gibt man im Terminal

sudo apt-get update
sudo apt-get dist-upgrade
sudo rpi-update

ein.

Ggf. ist ein weiterer Reboot erforderlich.

Raspbian mit Noobs installieren – kinderleicht

Noch einfacher ist die Installation mit Noobs (New out of box software). Noobs kann man sich hier herunterladen: Noobs (am besten NOOBS LITE Network install only wählen).

Die SD-Karte wird FAT/FAT32 formatiert und die Daten des Noobs-Zipfiles werden auf die SD-Karte entpackt. Bootet man mit der solchermaßen vorbereiteten SD-Karte landet man bei einem grafischen Installationsprogramm, mit dem man z.B. Raspbian ganz einfach auf die Karte bringt (Netzwerkverbindung erforderlich, weil das Betriebssystem aus dem Netz heruntergeladen wird). Einfacher geht nicht.

Auch hier wieder nach der Installation aktualisieren:

sudo apt-get update
sudo apt-get dist-upgrade
sudo rpi-update

Grundlegende Absicherung

Nach der Installation ist der Standard-Benutzer „pi“ und das Standard-Passwort „raspberry“. Weil der Rechner ja irgendwann im Internet hängt und auch von außerhalb erreichbar sein wird, MUSS das Passwort geändert werden. Hier sollte man auch nicht kleckern, sondern klotzen und ein Passwort wählen, das komplex und lang genug ist (Tipps dafür gibt es ausreichend im Netz… Diceware wäre eine gute Idee, damit man es sich merken kann). Der Benutzer „pi“ kann nämlich per „sudo“ ohne weitere Passwortabfrage Root-Rechte bekommen… ein Angreifer hat damit das System faktisch übernommen.

Es wird verschiedentlich auch empfohlen, einen neuen Benutzer (mit anderem Benutzernamen) und den gleichen Rechten wie „pi“ anzulegen und den Benutzer „pi“ anschließend zu löschen. Halte ich bei einer wirklich guten Passwortwahl für überflüssig.

Wichtig für die Sicherheit ist außerdem, das System regelmäßig mit Updates zu versorgen. Das kann man automatisieren. Ich nutze aus Bequemlichkeit „unattended-upgrades“.

Dazu gibt man im Terminal

sudo apt-get install unattended-upgrades update-notifier-common

ein, um die notwendige Software zu installieren. Die Konfiguration startet man mit

sudo dpkg-reconfigure -plow unattended-upgrades

und bestätigt mit „YES“.

Für die automatischen Updates editiert man nun die Datei „/etc/apt/apt.conf.d/10periodic“ mit

sudo nano /etc/apt/apt.conf.d/10periodic

Ich möchte eine tägliche Überprüfung auf Updates. Damit man sich die SD-Karte nicht mit veralteten Paketen zumüllt, sollen alte Pakete einmal wöchentlich gelöscht werden. Dazu ändert man die Datei wie folgt:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7";
APT::Periodic::Unattended-Upgrade "1";

(Speichern und beenden bei Nano immer mit Strg-O und Strg-X)

Um Bruteforce-Angriffe zu verhindern, empfiehlt sich außerdem fail2ban zu installieren:

sudo apt-get install fail2ban

In der Standard-Konfiguration werden IP-Adressen nach sechs fehlerhaften Anmeldungen für 10 Minuten gesperrt. Ändern könnt Ihr das in der Datei „/etc/fail2ban/jail.conf “.

Schließlich kann man auch noch eine Firewall mit Iptables einrichten. Das spare ich mir hier aber für später auf, weil man damit auch viel „verzerkonfigurieren“ kann und sich evtl. Fehler aufhalst, die man als unerfahrener Benutzer nur schwer findet.

Das System ist soweit auch erst einmal ausreichend abgesichert.

Im nächsten Teil geht es weiter mit der Einrichtung von SSH, damit man Monitor, Tastatur und Maus abklemmen kann und den Rechner von seinem „normalen“ Rechner aus bedienen kann. Außerdem wird ein FTP-Server eingerichtet, damit man Daten auf den Raspi schaufeln kann.


2 – SSH und FTP einrichten

Der Raspi soll irgendwann ja ganz unauffällig und geräuschlos neben dem Router im Regal liegen… Monitor, Tastatur und Maus würden da stören und sind auch nicht nötig, solange man ohnehin einen „richtigen“ Computer (wobei… der Raspi ist durchaus ein richtiger Computer… echt leistungsfähig, die kleine Schachtel) am Router zu hängen hat… oder woanders mit Internetzugang.

SSH

Was es am Raspi als Server/Hub zu tun gibt, erfolgt ohnehin auf der Textkonsole und kann mit SSH-Zugriff bequem vor anderen Rechner aus erfolgen.

SSH sollte bereits bei Raspbian installiert sein, es muss nur aktiviert werden. Das erledigt man am besten mit dem Tool „raspi-config“:

sudo raspi-config

Nun kommt es auf die Version an, wo man die Aktivierung von SSH findet… bei meiner Version ist die Aktivierung unter „5 Interfacing Options -> P2 SSH“ zu finden. Hier kann SSH aktiviert werden.

Bei mir hängt der Raspi am heimischen Router… diese und alle weiteren Beschreibungen beziehen sich damit auch auf solch einen Anwendungsfall.

Um nun vom „normalen“ Rechner (nenne ich ab jetzt nur noch Rechner), der ebenfalls am Router hängt, auf den Raspi zugreifen zu können, muss man die interne IP kennen, die vom Router für den Raspi vergeben wurde.

Um die IP herauszufinden gibt man beim Raspi

ifconfig

ein. In der Ausgabe erfährt man dann die interne IP… z.B.

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.6  netmask 255.255.255.0  broadcast 192.168.1.255

Alternativ kann man am Rechner das Webinterface des Routers aufrufen und sich dort die angeschlossenen Geräte anzeigen lassen.

Nun kann man vom Rechner aus in einer Konsole

ssh pi@192.168.1.6

eingeben (ich nutze hier und künftig die IP aus dem Beispiel oben 192.168.1.6… das muss man natürlich an seine eigenen Verhältnisse anpassen, also die IP des eigenen Raspi verwenden).

Es wird nach dem Passwort des Benutzers „pi“ gefragt, das man blind eingeben muss… und schon ist man auf dem Raspi eingeloggt und man arbeitet, als säße man direkt an einer Konsole des Raspi.

FTP

Hat man nun Daten auf dem Rechner und möchte man sie auf den Raspi kopieren, ist es sinnvoll, dies mittels FTP-Zugang zu machen. Dafür muss auf dem Raspi ein FTP-Server laufen.

Zur Installation von proftpd (in meinen Augen am sinnvollsten) gibt man

sudo apt-get install proftpd

ein.

Die Konfiguration startet dann automatisch und man wird nach der Variante gefragt. Hier wählt man „standalone“.

Hinweis:

Es kann sein, dass bei der verwendeten Version von Raspbian der Konfigurationsdialog (from inetd / standalone) nicht erscheint.

Das ist dann kein Problem und kann ignoriert werden.

Nun ist es zunächst nur möglich, sich als „pi“ mit dem bekannten Passwort einzuloggen… man hat aber nur Zugriff auf sein Home-Verzeichnis, um dort Dateien hochzuladen oder von dort herunterzuladen. Später, wenn wir den Webserver Apache installieren, müssen die Daten aber ins Verzeichnis (in der Standard-Konfiguration) „/var/www“ hochgeladen werden. Um eine entsprechende Einrichtung kümmern wir uns, wenn Apache installiert wurde.

Im nächsten Teil kümmern wir uns um die Installation und Einrichtung des Webservers Apache und der Skriptsprache PHP.


3 – Apache Webserver und PHP

Für Hubzilla braucht es einen Webserver. Hubzilla läuft mit Apache, Nginx und soll auch schon mit lighttpd zum Laufen gebracht worden sein. Die Nutzung von Apache ist allerdings am besten dokumentiert, weshalb sich dieser Webserver anbietet.

Apache

Für die Installation muss man lediglich

sudo apt-get install apache2

eingeben.

Ist die Installation erfolgt, kann man im Webbrowser am Rechner einmal die IP des Raspi eingeben… also beispielsweise http://192.168.1.6

Es sollte dann die Standardseite von Apache angezeigt werden:

Das Verzeichnis für Webinhalte, die Apache „serviert“ ist „/var/www/html“.

PHP

Hubzilla benötigt außerdem PHP (und MySQL). Die Installation ist wiederum sehr einfach:

sudo apt-get install php php-mysql

Ob PHP richtig läuft, kann man sich anzeigen lassen, indem man eine Datei „phpinfo.php“ im Verzeichnis „/var/www/html“ erzeugt:

sudo nano /var/www/html/phpinfo.php

Die Datei muss folgenden Inhalt haben:

<?php
 phpinfo();
?>

Ruft man nun wieder die IP des Raspi auf und hängt „phpinfo.php“ an, sollte die Informationsseite von PHP angezeigt werden. Benötigt wird auch das Modul „php-db“, das noch installiert werden muss:

sudo apt-get install php-db

In der Standard-Konfiguration erlaubt PHP den Upload von Dateien mit einer Maximalgröße von 2 MB. Das ist definitiv zu wenig. Schon der Import eines Channels liegt oftmals darüber. Um dieses Limit zu erhöhen, editiert man die Datei „/etc/php/php.ini“:

sudo nano /etc/php/7.0/apache2/php.ini

In der Datei sucht man den Bereich „File Uploads“ (ungefähr in der Mitte der Datei) und ändert die Zeile

upload_max_filesize = 2M

in

upload_max_filesize = 8M

(…oder, wenn man meint, es reicht, auch 4 oder 6M)

Im nächsten Abschnitt dann die Installation der Datenbank MySQL und dem DB-Tool phpMyAdmin.


4 – Datenbank: MySQL und phpMyAdmin

Für den Betrieb von Hubzilla benötigt man eine Datenbank. Es können MySQL, MariaDB oder postgres zum Einsatz kommen. Ich habe mich für MySQL entschieden… das ist quasi wieder der „Standard“ bei Hubzilla.

MySQL

MySQL ist schnell installiert

sudo apt-get install mysql-server mysql-client

…muss dann aber noch konfiguriert werden:

sudo mysql_secure_installation

Nach Eingabe dieses Kommandos folgen einige Fragen:

  1. Abfrage des aktuellen Passworts für den DB-Benutzer „root“. Da wir noch keines vergeben haben, einfach „enter“ drücken.
  2. Set root password? [Y/n] Antwort: „Y“ Hier sollte nun ein gutes(!) Passwort gewählt werden, um den Datenbankzugriff abzusichern.
  3. Remove anonymous users? [Y/n] Antwort: „Y“ Wir wollen keinen anonymen Benutzer.
  4. Disallow root login remotely? [Y/n] Antwort: „N“ Ein Remote-login in die Datenbank muss möglich sein.
  5. Remove test database and access to it? [Y/n] Antwort: „N“ Die Testdatenbank sollte erhalten bleiben.
  6. Reload privilege tables now? [Y/n] Antwort: „Y“ Damit werden die getroffenen Einstellungen sofort aktiviert.

Die Installation von MySQL ist damit abgeschlossen.

phpMyAdmin

Um auch vom Rechner aus komfortabel mit der Datenbank umgehen zu können, empfiehlt sich die Installation von phpMyAdmin, einer Weboberfläche für die Datenbankverwaltung. Die Installation erfolgt mit

sudo apt-get install php-mysql phpmyadmin

In der folgenden Konfiguration wählen wir als Webserver „apache2“.

Nun folgt die Frage, ob benötigte Datenbanken erzeugt werden sollen. Das bestätigen wir.

Das Konfigurations-Skript fragt nun nach dem root-Passwort, das wir bei Installation von MySQL vergeben haben.

Schließlich wird noch ein Passwort gewählt, das zum einloggen bei phpMyAdmin verwendet werden soll. Nach Eingabe und Bestätigung ist die Installation erledigt.

Apache2 muss nun noch mit phpMyAdmin „verknüpft“ werden. Dazu editiert man die Datei „/etc/apache2/apache2.conf“:

sudo nano /etc/apache2/apache2.conf

und fügt ganz am Ende der Datei

Include /etc/phpmyadmin/apache.conf

an.

Anschließend Apache2 neu starten:

/etc/init.d/apache2 restart

Gibt man nun wieder die IP des Raspi, gefolgt von „phpmyadmin“ ein, also z.B.

http://192.168.1.6/phpmyadmin/

erscheint die Loginseite, wo man sich als Benutzer „root“ und dem soeben vergebenen Passwort einloggen kann und in der DB-Verwaltung landet.

Die Datenbank ist also auch vorbereitet… als nächstes folgt die Einrichtung der Mail-Funktionalität.


5 – eMail-Funktionalität

Damit der Hub später in der Lage ist (ist zwingend notwendig), eMails zu versenden, müssen wir dem Raspi zu dieser Fähigkeit verhelfen. Man könnte nun einen vollwertigen Mailserver aufsetzen… aber das wäre mit Kanonen auf Spatzen geschossen, denn es muss letztlich nur möglich sein, eMails per PHP zu versenden… ein Mail-Empfang ist nicht erforderlich. Wenn man über einen Mail-Account verfügt (ob selbst gehostet oder bei einem Mail-Provider), dann kann man den Raspi so einrichten, dass er eMails über diesen Mailserver sendet. Für diese Funktionalität gibt es mehrere Möglichkeiten… z.B. ssmtp oder postfix.

ssmtp klang für mich zunächst „einfacher“ oder „leichtgewichtiger“ (postfix klingt dann doch eher wieder nach echtem, fetten Mailserver), weshalb ich es damit versucht habe. Ich erläutere hier jetzt aber nicht die Installation und die Konfiguration, weil ich daran nach etlichen Stunden endgültig gescheitert bin. Es wollte mir partout nicht gelingen, ssmtp so zu konfigurieren, dass es mit dem Mail-Account meines Hosting-Providers zusammenarbeiten wollte. Sucht man im Netz nach Lösungen, so findet man meist Beispiele für das Zusammenspiel mir einer gmail- oder GMX-Mailadressen. Da ich aus meinem Internet-Mittelalter noch brachliegende und ungenutzte Mail-Accounts sowohl beim Gockel, als auch bei GMX hatte, habe ich es auch – nur zum Ausprobieren – mit beiden getestet… ebenfalls vergeblich. Die Dokumentation von ssmtp ist… vorsichtig und nett ausgedrückt… suboptimal… Versuche mit verschiedenen Konfigurationen führten entweder dazu, dass der Mailserver gar nicht erreicht wurde oder dass das Login an vermeintlich „falschen Logindaten“ scheiterte. Und das für alle Accounts, die ich probiert habe. Ich habe etliche Stunden mit den Konfigurationsdateien herumexperimentiert und im Netz recherchiert… und dann irgendwann aufgegeben.

Da postfix eine vergleichbare Funktionalität bietet habe ich ssmtp dann vom Raspi geschmissen und es mit postfix probiert. Hätte ich gleich machen sollen, denn die Dokumentation ist vorbildlich, die Einrichtung einfach… nach wenigen Minuten gelang es mir, Mail über den Mailaccount meines Hosting-Providers zu versenden.

Hier also die „Anleitung“ für die Postfix-Lösung…

Die Postfix-Installation erfolgt mit

apt-get install postfix

Das Konfigurationsskript fragt nun nach dem Anwendungszweck… hier wählt man „Sattelitensystem“ („Satellite System“), womit keine Mails empfangen werden, aber Mails über einen Smart-Host versendet werden können.

Nun muss die Datei „/etc/postfix/main.cf“ angepasst werden…

nano /etc/postfix/main.cf

Hier sind folgende Einträge wichtig:

relayhost = <entfernter_mailserver>:<port>
mail_owner = postfix
setgid_group = postdrop
mtp_sasl_auth_enable=yes
smtp_sasl_password_maps=hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options=

Bei „relayhost“ müsst Ihr den Mailhost Eures Mail-Providers und den Port für SMTP-Mailversand eingeben.

Nun muss noch die Passwort-Datei angelegt werden:

nano /etc/postfix/sasl_passwd

Hier werden die Zugangsdaten eingetragen…

entfernter_mailrerver>:<port> <loginname>:<passwort>

Nun die Passwortdatei gegen unberechtigten Zugriff sichern:

chmod 600 /etc/postfix/sasl_passwd

Und schließlich die Benutzen-Datenbank mit

postmap hash:/etc/postfix/sasl_passwd

erzeugen. Jetzt nur noch postfix neu starten…

systemctl restart postfix

Damit sollte der Mailversand auch schon klappen. Ausprobieren kann man es mit

echo „Testmail“ | mail -s „Test Mail“ <mailadresse>

Falls etwas nicht klappt, sollte man in den Dateien „/var/log/mail.err“ und „/var/log/mail.log“ nachschauen.

Als nächstes sollte der Raspi jetzt „im Internet bekannt gemacht werden“… soll heißen, wir brauchen eine Domain, damit der Raspi von überall erreicht werden kann, ohne die IP zu kennen… das geschieht zuhause, wo man von seinem Internet-Provider regelmäßig andere IP zugewiesen bekommt, mit dynamischem DNS (dDNS). Wie das funktioniert… folgt im nächsten Abschnitt.


6 – dynamisches DNS

Damit der Raspi im Internet erreichbar ist, benötigt man eine Domain. Damit man über eine Domain einen Webserver erreicht, muss die Domain in einem DNS-Server eingetragen sein, wo der Domain die entsprechende IP-Adresse des Servers zugewiesen wird.

Nun soll der Hubzilla-Raspi ja zu Hause stehen… er hängt also am Router und ist über den Zugang des Internet-Providers mit dem Internet verbunden. Er hat also eine eindeutige IP… nur… die ändert sich öfter. Internet-Provider teilen ihren Kunden wechselnde IP zu (einige Provider bieten eine feste IP… das kostet aber ordentlich). Wird der Internet-Zugang getrennt (z.B. bei einem Router-Reset, nach einem Stromausfall oder einer sonstigen Trennung vom Netz) und verbindet sich wieder, dann erhält man eine zufällige IP aus dem Fundus des Providers. Außerdem gibt es bei den meisten Providern eine tägliche routinemäßige Trennung vom Netz, die auch für eine neue IP sorgt. Ein Eintrag der IP bei einem DNS-Server hätte also eine ausgesprochen kurze „Haltbarkeit“ und Aufrufe der Domain würden regelmäßig ins Leere laufen.

Ein Eintrag bei einem DNS-Service ist also nicht sinnvoll.

dDNS

Für diesen Anwendungsfall gibt es aber dynamisch DNS-Dienste, die genau dieses Problem lösen. Hier wird die Domain automatisch auf die neue IP „umgebogen“, wenn sie sich ändert. Bekannte Dienste dieser Art sind z.B. DynDNS Service, DNSdynamic, No-IP, Securepoint DynDNS, clickIP

Ich nutze No-IP. Hier gibt es einen kostenlosen Dienst, der auf drei Hostnamen bei eingeschränkter Domainauswahl beschränkt ist und alle 30 Tage eine „Auffrischung“ des Accounts erforderlich macht (man erhält eine eMail-Benachrichtigung). Für gut 21 € im Jahr (also keine zwei Euro im Monat) bekommt man da aber auch den Enhanced Dynamic DNS Dienst, der über 25 Hostnamen bei über 80 Domains bietet und keine „Auffrischung“ erforderlich macht. Ich habe mich für den kostenpflichtigen Dienst entschieden, aber auch der kostenlose Service ist eigentlich völlig ausreichend, solange man sich nicht an der regelmäßigen Reaktivierung stört und man mit drei Hostnamen auskommt.

Hat man sich also z.B. bei No-IP angemeldet und einen DNS-Host (A) registriert, muss man seinen Router noch für diesen dDNS-Dienst konfigurieren. Wie das geht, hängt vom Router ab. Viele Router verfügen über vorkonfigurierte Einstellungen der gängigsten dDNS-Dienste… No-IP ist in der Regel dabei.

Meine Domain für den Hub ist pepecyb.ddns.net. Im Router musste ich nun die Provider-URL (in meinem Fall also http://www.no-ip.com), meinen Benutzernamen (bei No-IP), das Passwort und meinen Hostnamen eingeben (also pepecyb.ddns.net).

Damit der Apache Webserver auch von Außen erreichbar ist, müssen im Router auch noch Portweiterleitungen für die interne IP des Raspberry mit den Ports 80 und 443 (wir richten ja ein SSL-Zertifikat mit Let‘s Encrypt ein) eingerichtet werden. Auch das ist von Router zu Router unterschiedlich… man findet aber für nahezu jedes Modell Anleitungen im Internet. Außerdem muss man ggf., wenn der Router eine Firewall betreibt, auch noch eine DMZ für die interne IP der Raspberry aktivieren… auch das hängt vom Router ab.

Ist das erledigt, sollte bei Aufruf der URL der dDNS-Domain (bei mir http://pepecyb.ddns.net) nun die Standard-Seite des ja bereits laufenden Apache-Webservers erscheinen. Glückwunsch… der Raspi ist im Internet. 😉

Als nächstes erzeugen wir uns mit Let‘s Encrypt ein SSl-Zertifikat und richten es ein.


7 – SSL-Zertifikat mit Let‘s Encrypt

Nun fehlt nur noch ein Zertifikat, damit unser Hubzilla in der Dose per https erreicht werden kann. Gerade bei Diensten, wo teilweise sensible Daten übertragen werden, ist eine Verschlüsselung dieser wichtig und absolut notwendig.

Dank Let‘s Encrypt ist es ja nun möglich, kostenlose Zertifikate zu erstellen und zu verwenden, die von fast allen Webbrowsern anerkannt werden.

Let‘s Encrypt

Let‘s Encrypt installieren wir uns am besten via git. Sollte git beim verwendeten Raspbian noch nicht installiert sein (unwahrscheinlich), muss das rasch nachgeholt werden:

sudo apt-get install git

Da wir in der Konfiguration von Apache „herumpfuschen“, sollten wir Apache erst einmal stoppen:

sudo systemctl stop apache2

Nun wechseln wir in unser Home-Verzeichnis und ziehen uns Let‘s Encrypt:

git clone https://github.com/letsencrypt/letsencrypt

Jetzt wechseln wir in das Verzeichnis „letsencrypt“:

cd letsencrypt

Für die Erzeugung und Installation des Zertifikats brauchen wir einmal die Domain (<domain>), für welche das Zertifikat erstellt werden soll, sowie eine funktionierende Mail-Adresse (<email-adesse>). Das Erstellen des Zertifikats erfolgt nun mit:

./letsencrypt-auto -d <domain> --redirect -m <email-adresse> --apache

Der Parameter „–redirect“ sorgt dafür, dass http-Zugriffe auf https umgeleitet werden, „–apache“ sorgt dafür, dass das Zertifikat gleich korrekt für die Nutzung mit dem Apache-Webserver konfiguriert wird.

Nun die Nutzungsbedingungen lesen und akzeptieren. Fertig!

Da Let‘s Encrypt Zertifikate eine Gültigkeitsdauer von drei Monaten haben, müssen wir darauf achten, das Zertifikat rechtzeitig zu erneuern. Das Erneuern funktioniert mit:

./letsencrypt-auto -d <domain> --redirect -m <email-adresse> --agree-tos --renew-by-default

Damit wir nicht ständig daran denken müssen, das Zertifikat rechtzeitig zu erneuern, lassen wir das von einem Cronjob erledigen…

sudo crontab -e

.

0 2 1 * * /home/pi/letsencrypt/letsencrypt-auto -d <domain> --redirect -m <email-adresse> --agree-tos --renew-by-default

Damit wird das Zertifikat an jedem Monatsersten um 2 Uhr in der Nacht automatisch erneuert.

Jetzt schnell noch Apache neu starten:

sudo systemctl start apache2

Rufen wir nun vom Rechner aus https://<domain> auf, sollte wieder die Apache-Standardseite angezeigt werden… und der Browser zeigt Euch (hoffentlich), dass es sich um eine „sichere Verbindung“ handelt.

Der nächste Schritt ist nun schon die Installation von Hubzilla… wobei ich das in zwei Teile unterteile. Zuerst schildere ich die Probleme und Fallstricke, die mir begegnet sind… und wie man die Probleme lösen kann… und im zweiten Teil beschreibe ich die einzelnen Schritte, um Hubzilla zu installieren und in Betrieb zu nehmen.


8 – Installation von Hubzilla – Fallstricke und Probleme

Wie „angedroht“ hier zunächst die Probleme, über die ich bei der Installation gestolpert bin…

Das sind drei Komplexe: url_rewrite, das Verzeichnis „store/[data]/smarty3“ und Rechte, Rechte, Rechte (nicht die politische Gesinnung, sondern Schreib- und Leserechte für die verschiedenen Verzeichnisse 😉 😀 )

Na… dann mal ran, flott ins Verzeichnis „/var/www“ gewechselt und mit git Hubzilla gezogen…

Nöööö… als Benutzer „pi“ geht das nicht… also zum „root“ gemacht… nochmal…

Nächstes Gemecker: Das Verzeichnis html ist nicht leer!
Logisch, Apache hat ja seine Standard-Seite da hineingeschrieben.

Also das Verzeichnis html geleert… Hubzilla gezogen, in html gewechselt und mit git noch die Addons nachgeholt.

Die leere Datenbank hatte ich schon angelegt… dann am Rechner meinen Raspi aufgerufen (bei mir ja https://pepecyb.ddns.net) und gleich wieder ausgeschimpft worden.

Das Verzeichnis „store/[data]/smarty3“ existiere nicht und/oder sei nicht beschreibbar. Komisch… das war mir bei meinen diversen Probe-Installationen bei Uberspace nicht passiert… das Verzeichnis befindet sich nicht im Git-Repository, war nach der Installationsroutine aber dann immer vorhanden und beschreibbar.

Ok… kann man ja anlegen:

mkdir -p "store/[data]/smarty3"
chmod -R 777 store

Nun blieb die Fehlermeldung aus. Was mir auffiel: es rödelte und rödelte… dann irgendwann erschien die Seite mit den Systemchecks. Und zeigte den nächsten Fehler an.

Url rewrite funktioniert nicht! Hmmm… ob das Modul nicht aktiviert ist?

sudo a2enmod rewrite

und zur Sicherheit gleich noch

sudo a2enmod actions

nachgeschoben, falls das auch nicht aktiviert sein sollte.

Nächster Versuch… Waaaartezeit… und wieder:

Url rewrite funktioniert nicht!

Seltsam! Ein Aufruf von phpinfo.php behauptete das Gegenteil… url_rewrite ist geladen.

Und warum funktioniert das jetzt nicht? Ich habe mich wie ein Ochse durch verschiedenste Anleitungen aus dem Internet gewühlt und stolperte immer wieder über „AllowOverride All“. Und tatsächlich… in der Datei „/etc/apache2/apache2.conf“ war das nicht gesetzt. Das ist aber erforderlich dass die lokale .htaccess genutzt werden kann.

Danach war das Problem Vergangenheit.

Ich hatte zwischendurch das Verzeichnis „html“ noch einmal geleert und neu gezogen. Dabei habe ich vergessen, das Verzeichnis „store/[data]/smarty3“ anzulegen, aber die Rechte für /var/www/html neu gesetzt:

sudo chmod -R 770 /var/www/html/

Obwohl ich also „store“ nicht angelegt hatte, lief die Installation aber trotzdem durch und das Verzeichnis wurde automatisch für mich angelegt. Lag also wohl an den Verzeichnisrechten.

Noch ein Tipp zu Rechten… Das Verzeichnis war nach der Installation von Apache dem Benutzer „root“ und auch der Gruppe „root“ zugeordnet. Ich habe das geändert und die Gruppe „www-data“ zugewiesen:

sudo chown -R root:www-data /var/www/html/

Der Benutzer „pi“ war außerdem nicht in der Gruppe „www-data“, was ich aus Gründen der Bequemlichkeit auch noch erledigt habe:

sudo usermod -aG www-data pi

Das klingt jetzt so, als wäre das kein großes Ding, aber die Suche nach den Fehlerquellen und das Finden der (eigentlich simplen) Lösungen hat zwei volle Tage gefressen.

Hier die Zusammenfassung:

  1. Vor dem git-clone von Hubzilla, die Standard-Dateien, die von Apache angelegt wurden, aus dem Verzeichnis „/var/www/html“ entfernen.
  2. Die Rechte für das Verzeichnis setzen: sudo chmod -R 770 /var/www/html/
  3. Sicherheitshalber: sudo a2enmod rewrite; sudo a2enmod actions ausführen.
  4. In der Datei „/etc/apache2/apache2.conf“ überall AllowOverride All setzen.
  5. sudo chown -R root:www-data /var/www/html/
  6. sudo usermod -aG www-data pi

Und nun folgt im nächsten Teil die Beschreibung der Installation.


9 – Hubzilla installieren

Nach der ganzen Vorrede nun kurz und knapp die Installation von Hubzilla auf dem Raspi. Das ist keine große Aktion, wenn der Server ordentlich konfiguriert ist.

Als erstes erstellen wir uns die benötigte Datenbank mit phpMyAdmin und merken uns den Namen. Als Encoding wählen wir „utf8mb4_unicode_ci“.

Wir wechseln in das Verzeichnis „/var/www“

cd /var/www

Nun stellen wir sicher, dass das dort eventuell vorhandene Verzeichnis „html“ leer ist und clonen uns mit git das Hubzilla-Repository:

git clone https://framagit.org/hubzilla/core.git html

Das müssen wir anschließend noch für die Addons erledigen:

cd html
git clone https://framagit.org/hubzilla/addons.git addon

Anschließend geht es im Webbrowser weiter. Wir rufen unsere, durch dDNS erreichbare Domain auf und die Installation beginnt. Zunächst werden die Voraussetzungen für die Installation überprüft. Wenn wir den Raspi so vorbereitet haben, wie in den bisherigen Abschnitten beschrieben und wir auch an die Vermeidung der „Fallstricke“ aus dem vorigen Abschnitt gedacht haben, sollte die Prüfung erfolgreich verlaufen. Der nächste Schritt ist die Anbindung und Initialisierung der Datenbank.

Im Dialog der erscheint, lassen wir die Einträge für „Datenbank-Servername“ und „Datenbank-Port“ unverändert. Bei Datenbank-Benutzername geben wir „root“ ein und bei „Datenbank-Kennwort“ das Passwort für MySQL. Schließlich noch den Namen der gerade erzeugten leeren Datenbank bei „Datenbank-Name“ eingeben und kontrollieren, dass bei „Datenbanktyp“ auch „MySQL“ ausgewählt ist. Nun auf Bestätigen klicken.

Jetzt erscheint ein Formular zum Anlegen des Hub-Administrators.

Bei „E-Mail-Adresse des Seiten-Administrators“ geben wir eine gültige Mailadresse ein… Diese Adresse muss auch später die Mail-Adresse des Zugangs/Kanals des Administrators sein, damit man Zugang zu den Admin-Funktionen hat.

Bei „Server-URL“ wird die dDNS-URL des Raspi eingetragen, „Erweiterte Funktionen für Hubzilla aktivieren“ sollte man auf „Ja“ setzen. Schließlich noch die Auswahl der „Sandart-Zeitzone für Deinen Server“ und anschließend auf „Bestätigen“ klicken.

Bevor wir uns nun bei unserem Hub registrieren (zuerst für den Admin-Account), müssen wir nochmals zum Terminal greifen, um einen Cronjob anzulegen:

crontab -e

Im Editor geben wir dann die Zeile

*/10 * * * * cd /var/www/html; /usr/bin/php Zotlabs/Daemon/Master.php Cron

ein, speichern mit Ctrl-O und beenden den Editor mit Ctrl-X.

Ist das erledigt, geht es im noch offenen Browserfenster weiter. Hier klicken wir auf „Go to your new hub registration page…“ und wir landen bei der Registrierung.

Hier wählen wir als „Ihre E-Mail Adresse“ die Mailadresse, die wir gerade eben für die Hub-Installation eingegeben haben, denken uns ein gutes(!) Passwort aus, bestätigen unser Alter (über 13), akzeptieren unsere Nutzungsbedingungen und klicken schließlich auf „Fortfahren und Deinen ersten Kanal anlegen“.

Nun wird uns mitgeteilt, dass wir auf die angegebene Mail-Adresse eine eMail erhalten haben, wo uns ein Sicherheitscode mitgeteilt wird, den wir eingeben müssen, bevor wir fortfahren können. Das erledigen wir… und dann legen wir uns einen Kanal an. Hier halte ich es für sinnvoll, einen separaten neuen Kanal (mit passendem Namen) nur für Administrationszwecke anzulegen.

Jetzt haben wir im Hauptmenü oben links den Eintrag „Administration“ von wo aus wir unseren Hub konfigurieren und administrieren können.

Im nächsten Teil erläutere ich einige – in meinen Augen sinnvolle – Einstellungen, Konfigurationen und erläutere, wie man die Terms of Service Seite und die Datenschutzerklärung einbaut bzw. ändert.


10 – Administration

Der frisch gebackene Hub läuft… es gibt aber noch einige Dinge, die man einstellen sollte. Dazu ruft man in seinem Admin-Kanal den Menüpunkt „Administration“ auf.

Nun werden die Wichtigsten Daten des Hub angezeigt:

Wir rufen das Untermenü „Seite“ (Seitenleiste links) auf, um dort einige Änderungen vorzunehmen.

Wenn wir einen öffentlich sichtbaren und ggf. nutzbaren Hub betreiben, sollten wir ihm einen „sprechenden“ Namen geben (bei „Seitenname“ eintragen), vielleicht noch ein „Logo“ mitgeben (als Text bei „Banner/Logo“ eintragen) und auch das Feld „Administrator-Informationen“ sinnvoll befüllen. Da ich für meinen Hub verantwortlich bin, habe ich dort, fast wie bei einem vereinfachten Impressum, meine Kontaktdaten inkl. eMail-Adresse eingetragen. Diese Informationen erscheinen bei Aufruf der Seite „siteinfo“.

Nun muss man sich überlegen, ob man die Registrierung auf dem eigenen Hub erlaubt. Man sollte bedenken, dass mit der Zahl registrierter Konten auch die Last für den kleinen Raspi steigt und der Speicherplatzbedarf zunimmt. Eine völlig freizügige Möglichkeit zur Registrierung ist also nicht sinnvoll. Wenn man es trotzdem bestimmten Nutzern möglich machen möchte, ein Konto anzulegen, empfiehlt es sich, Registrierungen zu erlauben, aber den Eintrag „Nur mit Einladung“ auf „Ja“ zu stellen. Damit kann man den gewünschten Nutzern einen Einladungscode geben, mit dem diese in der Lage sind, sich zu registrieren. Dabei aber immer im Hinterkopf behalten… unser Hub läuft „nur“ auf einem Raspi. Ich habe, weil mein Hub frei im Internet verfügbar sein soll, die Einstellung „Meine Seite hat nur freien Zugriff“ eingestellt. Je nach beabsichtigten Verwendungszweck kann man hier andere Einstellungen machen.

Der Unterpunkt „Richtlinien“ ist auch noch interessant… „E-Mail-Adressen überprüfen“ sollte man einschalten… na und hier seht Ihr, was ich bei meinem Hub dort für Einstellungen getroffen habe:

Bei „Funktionen“ und „Addons“ trifft man eine Auswahl nach eigenem Geschmack. 😉

Um rechtlich „sauber“ mit seinem Hub daherzukommen, sollte man sich auch noch um die Nutzungsbedingungen und die Datenschutzerklärung kümmern.

Diese werden über die Datei „doc/TermsOfService.md eingebunden, die zunächst folgenden Inhalt hat:

Privacy Policy
==============

#include doc/gdpr1.md;


Terms of Service
================

#include doc/SiteTOS.md;

Die Datenschutzerklärung liegt in englischer Sprache als Datei „gdpr1.md“ vor. Ich habe diese Erklärung übersetzt und wer mag, kann sich die Markdown-Datei mit dieser inoffiziellen Übersetzung herunterladen: gdpr1.md
Die Datei „doc/gdpr1.md“ ersetzt man einfach mit der gleichnamigen Übersetzung… schon ist die Datenschutzerklärung in deutscher Sprache da.

Die Datei „SiteTOS.md“ existiert nach der Hubzilla-Installation nicht… die muss man sich selbst erstellen oder zusammenbauen. Hier die von mir verwendeten Nutzungsbedingungen ebenfalls zur freien Verfügung: SiteTOS.md

In dieser Datei die „Platzhalter“

<Name>
<Ort>
<eMail>
<Name der Seite>
<Anschrift>

mit den eigenen Angaben ersetzen, dann die Datei ins Verzeichnis „doc“ auf dem Raspi kopieren… und das war‘s dann jetzt erstmal.

Nun steht an, dass ich mich in die Thematik der Speicherplatzvergrößerung einarbeite, und experimentiere. Wenn ich da eine gute Lösung gefunden habe, folgen hier weitere Teile… aber jetzt bin ich erstmal feddich… mit dem Hubzilla in der Dose.


3 Gedanken zu “Hubzilla in der Dose (HiD)

  1. Nicht schlecht, so eine Dose 😉

    Eventuell noch als „Tipp“, ich benutze z.b. im /var/www Verzeichnis in der Konsole immer sudo -u www-data vor dem eigentlichen Befehl. Damit spare ich mir den chown weil alles mit www-data angelegt wird. Geht zumindest in meinem Setup wunderbar so.

  2. Hi.
    Danke für die Anleitung und die Impressumstexte!

    Ich denke, „doc/gdpr1.md“ sollte besser nach „doc/de/gdpr1.md“ oder „doc/de-de/gdpr1.md“ gehen. Entsprechend müsste man auch „doc/TermsOfService.md“ in das Unterverzeichnis für die deutsche Übersetzung kopieren und die includes entsprechend anpassen. Dann hat man den Text sowohl in Englisch als auch in Deutsch zur Verfügung, je nach Einstellung des Nutzers.

    Den letzten Abschnitt im gdpr hätte ich, glaube ich, eher mit:
    „““
    [NAME OF COMPANY] ist der Halter (und Verarbeiter) der Daten für die Zwecke der DPA 18 und der DSGVO 3.

    Wenn Sie Bedenken hinsichtlich der Verarbeitung Ihrer Daten haben, wenden Sie sich bitte an:
    „““
    übersetzt.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

* Mit der Nutzung dieses Formulars erklärst du dich mit der Speicherung und Verarbeitung deiner Daten durch diese Website einverstanden. Bitte dazu die Datenschutzerklärung beachten.