Hubzilla mit einem YunoHost-Server betreiben<\/strong>
Wer einen Server (egal ob zu Hause, oder auf einem gemieteten VPS- oder Rootserver) mit YunoHost<\/a> betreibt, hat es einfach. Die Software nimmt einem sehr viel Verwaltungsarbeit im Detail ab und bietet unz\u00e4hlige Applikationen, die man mit wenig Aufwand installieren, in Betrieb nehmen und pflegen kann.
Auch Hubzilla<\/a> geh\u00f6rt zu den Apps<\/a>, die bei YunoHost angeboten werden. Hubzilla ist mit wenigen Eingaben und Voraussetzungen installiert.
Man ben\u00f6tigt eine eigene Domain oder Subdomain. Dabei ist darauf zu achten, dass unter dieser Domain noch keine andere Fediverse-Software installiert war. Das ist eine "Besonderheit" des Fediverse. Einmal verwendete Domains sind f\u00fcr das Fediverse "verbrannt", wenn man unter ihnen eine neue oder andere Fedi-Software installieren m\u00f6chte. Aber egal... wir nehmen einmal an, wir haben eine frische, "jungfr\u00e4uliche" Domain. Dann ist die Installation mit wenigen Klicks und Eingaben erledigt.
Leider ist es zeitweise aber so, dass Updates f\u00fcr die App "Hubzilla" bei YunoHost (auch wichtige, sicherheitsrelevante, die zeitnah durchgef\u00fchrt werden m\u00fcssten) nur verz\u00f6gert Einzug halten.
Aus genau diesem Grund, habe ich nun Hubzilla unter YunoHost auf eine andere Art installiert. Die Vorteile, die einem YunoHost bietet, bleiben dabei erhalten (einfache Backups, kein h\u00e4ndisches Einrichten von Reverse Proxy, Aktualit\u00e4t des zugrundeliegenden Systems, Einrichtung einer Datenbank etc.).
Und so funktioniert das:<\/strong>
YunoHost bietet eine "Universal-App", die als "My Webapp<\/a>" bezeichnet wird. Mit dieser kann eine benutzerdefinierte Webanwendung installiert werden. Sie bietet SFTP-Zugriff, bei Bedarf eine Datenbank und PHP. Es wird unter
Wer einen Server (egal ob zu Hause, oder auf einem gemieteten VPS- oder Rootserver) mit YunoHost<\/a> betreibt, hat es einfach. Die Software nimmt einem sehr viel Verwaltungsarbeit im Detail ab und bietet unz\u00e4hlige Applikationen, die man mit wenig Aufwand installieren, in Betrieb nehmen und pflegen kann.
Auch Hubzilla<\/a> geh\u00f6rt zu den Apps<\/a>, die bei YunoHost angeboten werden. Hubzilla ist mit wenigen Eingaben und Voraussetzungen installiert.
Man ben\u00f6tigt eine eigene Domain oder Subdomain. Dabei ist darauf zu achten, dass unter dieser Domain noch keine andere Fediverse-Software installiert war. Das ist eine "Besonderheit" des Fediverse. Einmal verwendete Domains sind f\u00fcr das Fediverse "verbrannt", wenn man unter ihnen eine neue oder andere Fedi-Software installieren m\u00f6chte. Aber egal... wir nehmen einmal an, wir haben eine frische, "jungfr\u00e4uliche" Domain. Dann ist die Installation mit wenigen Klicks und Eingaben erledigt.
Leider ist es zeitweise aber so, dass Updates f\u00fcr die App "Hubzilla" bei YunoHost (auch wichtige, sicherheitsrelevante, die zeitnah durchgef\u00fchrt werden m\u00fcssten) nur verz\u00f6gert Einzug halten.
Aus genau diesem Grund, habe ich nun Hubzilla unter YunoHost auf eine andere Art installiert. Die Vorteile, die einem YunoHost bietet, bleiben dabei erhalten (einfache Backups, kein h\u00e4ndisches Einrichten von Reverse Proxy, Aktualit\u00e4t des zugrundeliegenden Systems, Einrichtung einer Datenbank etc.).
Und so funktioniert das:<\/strong>
YunoHost bietet eine "Universal-App", die als "My Webapp<\/a>" bezeichnet wird. Mit dieser kann eine benutzerdefinierte Webanwendung installiert werden. Sie bietet SFTP-Zugriff, bei Bedarf eine Datenbank und PHP. Es wird unter
\/var\/www<\/code> ein Verzeichnis angelegt, welches \u00fcber die bei Installation gew\u00e4hlte Domain erreichbar ist.
![\"hzyh01.png\"](\"https:\/\/hub.hubzilla.hu\/photo\/09de6d9f-93e6-44b7-b318-880e5afb888d-2.png\" "\\"hzyh01.png\\"")
<\/a>
Also der optimale Ort f\u00fcr eine Hubzilla-Installation.
Zun\u00e4chst muss man also eine entsprechende Domain in YunoHost anlegen und selbstverst\u00e4ndlich auch ein Zertifikat erstellen (Let's Encrypt). Das funktioniert genau so, wie f\u00fcr die "normale" Hubzilla-Installation z.B. mit der Verwaltungsoberfl\u00e4che von YunoHost.
Man w\u00e4hlt unter Applikationen \u2192 +Installieren aus dem Katalog die Anwendung "My Webapp".
![\"hzyh02.png\"](\"https:\/\/hub.hubzilla.hu\/photo\/4f80854d-d709-4c40-8fbd-e58a6e4c3183-2.png\" "\\"hzyh02.png\\"")
<\/a>
Nun kann man eine Bezeichnung f\u00fcr das Label der Kachel (in der YH-Oberfl\u00e4che) eingeben, die Domain\/Subdomain ausw\u00e4hlen. Beim URL-Pfad sollte man, um Probleme zu vermeiden, nur "\/" stehen lassen. F\u00fcr einen \u00f6ffentlichen Hub, w\u00e4hlt man im Feld "Wer soll Zugriff auf diese App haben?" den Eintrag "Besucher".
Als PHP-Version f\u00fcr Hubzilla w\u00e4hlt man 8.2 aus und anschlie\u00dfend noch den Typ des Datenbank (MySQL oder Postgresql).
Dann startet man die Installation der Custom-Webapp.
Ist sie durchgelaufen, muss man sich per SSH am eigenen Server einloggen. Im Verzeichnis \/var\/www<\/code> findet man nun ein neues Verzeichnis my_webapp<\/code> und in diesem ein Unterverzeichnis www<\/code>. Letzteres ist das Verzeichnis, welches beim Aufruf der Domain vom Webserver geliefert wird.
Nun kann man ganz einfach nach der offiziellen Installationsanleitung Hubzilla installieren. Im Root-Verzeichnis (my_webapp\/www<\/code>) findet man eine Datei db_access.txt<\/code>, in welcher die Zugangsdaten f\u00fcr die Datenbank stehen. Wichtig: sichern!<\/strong> Die Daten (Datenbankname, Datenbanknutzer, Datenbankpasswort) ben\u00f6tigen wir f\u00fcr die Installation von Hubzilla noch.
Nun muss das Verzeichnis my_webapp\/www<\/code> geleert werden, also alle darin enthaltenen Dateien gel\u00f6scht, damit man das Hubzilla-Repo dorthin klonen kann.
Damit die Dateirechte sofort passen... und generell sowieso, empfiehlt es sich, an dieser Stelle als Benutzer "my_webapp" fortzufahren. Daf\u00fcr gibt man yunohost app shell my_webapp<\/code> ein.
Nun befindet man sich im Verzeichnis my_webapp<\/code>. Mit git clone https:\/\/framagit.org\/hubzilla\/core.git www<\/code> klont man das Repo an die richtige Stelle. Danach am besten sofort in das Verzeichnis www<\/code> wechseln: cd www<\/code>
Es wird beim Klonen auch eine Datei .htaccess<\/code> erzeugt. Diese dient der Konfiguration des Apache Webservers. Nun nutzt YunoHost aber nginx und nicht Apache, weshalb diese Datei nicht von Bedeutung ist.
Bei der Installation von My Webapp werden Konfigurationsdateien unter \/etc\/nginx\/conf.d\/<domain von my_webapp><\/code> erzeugt. Diese gen\u00fcgen aber den Anspr\u00fcchen von Hubzilla nicht. Die my_webapp.conf<\/code> muss wie folgt aussehen:
#sub_path_only rewrite ^\/$ \/ permanent;
location \/ {
\u00a0 # Path to source
\u00a0 alias \/var\/www\/my_webapp\/www\/;
\u00a0 if (!-e $request_filename) {
\u00a0 \u00a0 rewrite ^(.*)$ \/index.php?q=$1;
\u00a0 }
\u00a0 # Default indexes and catch-all
\u00a0 index index.php;
\u00a0 charset utf-8;
\u00a0 # Common parameter to increase upload size limit in conjunction with dedicated php-fpm file
\u00a0 client_max_body_size 50M;
\u00a0 client_body_buffer_size 128k;
\u00a0 location ~* \\.php$ {
\u00a0 \u00a0 try_files $uri =404;
\u00a0 \u00a0 fastcgi_pass unix:\/var\/run\/php\/php8.2-fpm-hubzilla.sock;
\u00a0 \u00a0 fastcgi_index index.php;
\u00a0 \u00a0 include fastcgi_params;
\u00a0 \u00a0 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
\u00a0 }
\u00a0 # make sure webfinger and other well known services aren't blocked
\u00a0 # by denying dot files and rewrite request to the front controller
\u00a0 location ^~ \/.well-known\/ {
\u00a0 \u00a0 allow all;
\u00a0 \u00a0 if (!-e $request_filename) {
\u00a0 \u00a0 \u00a0 rewrite ^(.*)$ \/index.php?q=$1;
\u00a0 \u00a0 }
\u00a0 }
\u00a0 # statically serve these file types when possible
\u00a0 # otherwise fall back to front controller
\u00a0 # allow browser to cache them
\u00a0 # added .htm for advanced source code editor library
\u00a0 # location ~* \\.(jpg|jpeg|gif|png|ico|css|js|htm|html|map|ttf|woff|woff2|svg)$ {
\u00a0 #\u00a0 expires 30d;
\u00a0 #\u00a0 try_files $uri \/index.php?q=$uri&$args;
\u00a0 # }
\u00a0 # block these file types
\u00a0 location ~* \\.(tpl|md|tgz|log|out)$ {
\u00a0 \u00a0 deny all;
\u00a0 }
\u00a0 # deny access to all dot files
\u00a0 location ~ \/\\. {
\u00a0 \u00a0 deny all;
\u00a0 }
\u00a0 #deny access to store
\u00a0 location ~ \/store {
\u00a0 \u00a0 deny all;
\u00a0 }
\u00a0 #deny access to util
\u00a0 location ~ \/util {
\u00a0 \u00a0 deny all;
\u00a0 }
\u00a0 # Include SSOWAT user panel.
\u00a0 include conf.d\/yunohost_panel.conf.inc;
}<\/code><\/pre>
F\u00fcr eine Hubzilla-Installation sind innerhalb des Hubzilla-Verzeichnisses (hier also my_webapp\/www<\/code>) einige Verzeichnisse mit entsprechenden Zugriffsrechten essenziell. Sie werden eigentlich bei der Installation \u00fcber den Webbrowser angelegt (aber wohl nicht immer). Es ist aber sicherer und schadet nicht, wenn man mit cd www<\/code> ins Hubzilla-Verzeichnis wechselt und diese mit
mkdir -p "store\/[data]\/smarty3"
chmod -R 777 store<\/code><\/pre>
anlegt.
Um auch die Hubzilla-Addons zu installieren, muss man noch
util\/add_addon_repo https:\/\/framagit.org\/hubzilla\/addons.git hzaddons
util\/update_addon_repo hzaddons<\/code><\/pre>
eingeben.
PHP-Extensions: F\u00fcr Hubzilla ab Version 9 (aktuell) sind die PHP-Extensions sodium, gmp (oder bcmath) und intl erforderlich. Bei meiner YunoHost-installation waren sodium unf gmp vorhanden, intl hingegen fehlte.
Herausfinden, welche Extensions installiert und aktiviert sind kann man mit diesem Kommando:
php -m<\/code>
Mit
sudo apt-get update<\/code>
und
sudo apt-get install php8.2-intl<\/code>
ist die fehlende Extension rasch installiert.
php -m | grep intl<\/code> sollte das nun auch anzeigen.
Jetzt ist der Moment gekommen, an welchem man im Webbrowser die URL der neuen Installation aufruft.
Eigentlich sollte nun alles problemlos durchlaufen (ansonsten auftretenden Fehlern ggf. gem\u00e4\u00df der offiziellen Installationsanleitung auf den Grund gehen).
Jetzt ist es erforderlich, die frisch erzeugte .htconfig.php anzuschauen und dort den Pfad zu PHP anzupassen:
\/\/ Location of PHP command line processor
App::$config['system']['php_path'] = '\/usr\/bin\/php8.2';<\/code><\/pre>
Wenn man nun noch immer als Benutzer my_webapp unterwegs ist, sollte man sich mit php -v<\/code> die aktuell genutzte PHP-Version anzeigen lassen. Es sollte die Version 8.2 angezeigt werden.
HINWEIS:<\/u><\/strong>
Der Aufruf von php<\/code> ohne Pfadangabe ruft \/usr\/bin\/php<\/code> auf. Dabei handelt es sich um einen symbolischen Link auf \/etc\/alternatives\/php<\/code>. Und dies wiederum ist ein symbolischer Link auf die im System generell verwendeten PHP-Programmdatei. Bei meiner Installation war es so, dass ich einmal eine App installiert hatte, die zwingend php7.4 ben\u00f6tigte. YunoHost hatte deshalb das php<\/code> unter \/etc\/alternatives<\/code> auf \/usr\/bin\/php7.4<\/code> verlinkt. Eigentlich sollte das in der my_webapp-Umgebung aber kein Problem sein und auf php8.2 (wie bei Installation gew\u00e4hlt) verweisen. Bei mir war das anfangs aber nicht so (inzwischen schon, weshalb auch immer).
Um das zu "reparieren", habe ich den symbolischen Link \/etc\/alternatives\/php<\/code> auf \/usr\/bin\/php8.2<\/code> umgebogen.
Das ist erforderlich, weil die PHP-Skripte aus util per shebang den Interpreter via #!\/usr\/bin\/env php<\/code> aufrufen und damit auf den Eintrag in
\/etc\/alternatives<\/code> zur\u00fcckgreifen. Bei der Verwendung von Skripten aus util kommt es, wenn dieser auf php7.4 verweist, zum Programmabbruch mit der Fehlermeldung, dass eine zu alte PHP-Version verwendet wird.
Jetzt folgt noch ein weiterer, sehr wichtiger Schritt: das Anlegen eines Cronjobs f\u00fcr wichtige Hintergrunddienste.
Hierf\u00fcr ruft man crontab -e<\/code> auf und f\u00fcgt die Zeile *\/10 * * * * cd \/var\/www\/my_webapp\/www; \/usr\/bin\/php8.2 Zotlabs\/Daemon\/Master.php Cron > \/dev\/null 2>&1<\/code> zu.
Und nun sollte die Hubzilla-Installation unter YunoHost ordentlich laufen. Der Rest sollte bekannt sein (als erstes einen Account mit der zuvor angegebenen Mailadresse registrieren... das ist der Admin-Account) und dann einfach "benutzen". ;-)
WICHTIGER HINWEIS ZU UPDATES VON YUNOHOST:<\/strong>
Zumindest beim letzten Update der verwendeten my_webapp auf Version 1.0-ynh18, ich vermute aber auch bei jedem folgenden, wird die nginx-Konfigurationsdatei in \/etc\/nginx\/conf.d\/deinedomain.d\/my_webapp.conf mit Standardeinstellungen \u00fcberschrieben, was dazu f\u00fchrt, dass Hubzilla nicht mehr funktioniert.
Deshalb ist es sinnvoll, diese Konfigurationsdatei in einem separaten Backupverzeichnis auf dem Server vorzuhalten und die aktualisierte Datei damit zu \u00fcberschreiben. Alternativ kann man sie auch aus der automatisch beim Update angelegten Backup-Datei von YunoHost extrahieren und sie wieder in o.g. Verzeichnis kopieren (\u00fcberschreiben).<\/div><\/div>
<\/div>","width":640,"height":426}