Inhaltsverzeichnis

Volkszaehler bei einem Webhoster mit Plesk installieren

Motivation

Nicht jeder hat vielleicht einen eigenen 24/7 Server für den Volkszähler zu Verfügung oder es nervt die Performance eines low-cost LAMP Ansatzes (z.B. auf RaspberryPi). Wer bei einer Monatsanzeige schon mal gefühlte Stunden gewartet hat, sehnt sich nach mehr Leistung. Ein Lösungsansatz kann eine Webhoster Implementierung sein. Für einen erträglichen Monatsbetrag (geht so ab 1,99€/Monat los) bekommt man eine eigene Domain und ein paar GigaByte Webspace. Diese preiswerten Angebote bieten allerdings keinen root-Zugang und somit ist die Einrichtung des Volkszählers nicht über den Standardweg zu erledigen. Dafür bekommt man hübsche Webfrontends und fertige Tools über die man die Einrichtung vornehmen kann.

Das ganze hat aber auch Nachteile: Es gibt eine Menge verschiedener Hoster mit diversen Konfigurationen. Sollte es Probleme geben setzt das einiges an Erfahrung voraus und unsere Möglichkeiten zu unterstützen sind da sehr eingeschränkt. Der Support des Hosters ist in der Preisklasse auch keine große Hilfe weil die sich nur um die Bereitstellung kümmern, wenn es an der Anwendung klemmt ist der Kunde zuständig.

Voraussetzungen

Im folgendem wird die Einrichtung bei https://www.netcup.de/ beschrieben. Stand 2022 nutzen sie zur Administrierung der kleinen Pakete das recht verbreitet „Plesk“ in der Version „Onyx“. Teilweise findet das auch bei anderen Hoster Anwendung, vielleicht sogar unter anderem Label. Aber je nach Softwarestand unterscheiden sich die verfügbaren Funktionen erheblich.

Passen die hier erwähnten Schritte nicht haben wir noch eine andere Anleitung für Hosts die mit weniger PHP-Memory und ohne SSH daher kommen: Volkszaehler bei einem Webhoster ohne SSH installieren

Für unsere Installation auf dem Webhoster gelten die gleichen Bedingungen für den VZ wie für jeden anderen Server. Auf die folgenden Punkte sollte man bei der Auswahl des Hosters achten:

Subdomain

In der Regel wird man auf dem Host noch ein bisschen mehr liegen haben wie nur den Volkszaehler. Daher legen wir uns erstmal eine Subdomain an.

Das Git wird geclont, die Subdomain angelegt.

Von hier ab navigieren wir zu den meisten Einstellungen.

PHP

Richten wir direkt PHP passend ein.

Composer

Wir müssen Composer (Paketmanager für PHP) installieren und ausführen. Dafür gibt es zwei Wege (je nach Hoster und Plesk-Version)

Plesk

Wie schon erwähnt gib es teilweise schon die Möglichkeit Composer per Klick einzubinden.

Ist die Website über „hosting-Einstellungen“ deaktiviert wird diese Option nicht angeboten.


Ist ziemlich selbsterklärend, einfach den Anweisungen folgen.

Falls die Scripte nicht korrekt ausgeführt werden den Composer von „Produktionsumgebung“ auf „Entwicklungsumgebung“ umstellen.

SSH Zugang

Wir richten uns einen Nutzer für SecureShell ein.

cd /tmp
curl -sS https://getcomposer.org/installer | php
mkdir /composer
mv composer.phar /composer
chmod +x /composer/composer.phar
cd /volkszaehler
php /composer/composer.phar install

Datenbank

Richten wir nun die Datenbank ein.

Der automatisch erstellte User hat vollen Schreib- und Lesezugriff auf die neue, ihm zugewiesene Datenbank.

Falls ein Abzug einer vorherigen Datenbank verfügbar ist kann man den an der Stelle direkt hochladen und importieren.

Config

Ist die Datenbank eingerichtet passen wir die VZ-Konfiguration darauf an. Über den Dateimanager /volkszaehler/etc/config.dist.yaml öffnen.

Datenbank erstellen

Ist keine Datensicherung einer vorhergegangen Datenbank vorhanden müssen wir die Struktur noch erstellen.
Dazu nochmal per SSH einloggen und doctrine ausführen.

cd /volkszaehler
php bin/doctrine orm:schema-tool:create

Schlägt der Schritt fehl liegt ein Fehler in der zuvor erstellten Konfigurationsdatei vor.

An der Stelle können wir auch direkt die Tabellen für die Aggregation anlegen lassen

php /volkszaehler/bin/aggregate run -m full -l day -l hour -l minute
Falls hier ein Fehlermeldung wegen falscher PHP-Version kommt direkt auf "Geplante Aufgaben" ausweichen. Dort kann man die PHP-Version auswählen, für PHP-CLI ist das nicht möglich.

Stammverzeichnis

Zum Abschluss passen wir das Stammverzeichnis der Subdomain an unsere Verzeichnisstruktur an.

Das Frontend sollte nun zur Verfügung stehen und neue Kanäle anlegbar sein, bzw. alte Kanäle sollten abonniert werden können.
Erscheint stattdessen eine Fehlermeldung wie

ist Fehlersuche notwendig.

Rewrite?

Etwas Schwierigkeiten macht bei Hostern gerne der Rewrite, aus Sicherheitsgründen sind unsere Möglichkeiten da recht eingeschränkt. Ein Ansatz das in Griff zu bekommen war bei PHP den FPM statt FastCGI zu nutzen. Der ist allerdings aus der Mode gekommen und wird teils nicht mehr angeboten.
Funktioniert der Rewrite also nicht wie gewünscht besteht die Möglichkeit die Middleware umzukonfiguriern das sie weitestgehend ohne auskommt. Dazu in /volkszaehler/htdocs/js/options.js die Zeile 42 von

| /volkszaehler/htdocs/js/options.js
url: 'api'

ändern zu:

url: 'middleware.php'

vzlogger

Jetzt folgt die Anpassung (bzw. Erstellung) der 'vzlogger.conf' auf dem System, das die Daten senden soll.

Falls der vzlogger schon brav seinen Dienst verrichtet, braucht man lediglich in der Konfigdatei

"middleware": "http://localhost/middleware.php",

den Middlewarepfad auf http://volkszaehler.domain.tld/middleware.php anpassen, den Prozess per systemd stoppen und neu starten.

Aggregation

Auch wenn beim Hoster die erforderliche Leistung bei Anfragen über große Zeiträume kein Problem darstellt ist es dennoch nicht verkehrt die Aggregation der Middleware einzurichten.

Die Anzahl der „cronjobs“ ist bei Webhostern oft eingeschränkt. Man kann aber Problemlos alle 3 Aggregationsstufen in einen Aufruf packen.
Benachrichtigung (Email) bei Fehler ist ratsam, sonst versickern Störungen unbemerkt im Logfile.

Fehlersuche

Wenn es nun doch nicht wie gewünscht funktioniert:

  1. An die URL das Unterverzeichnis /frontend/ anhängen. z.B. http://demo.volkszaehler.org/frontend/ Wird diese URL nicht aufgelöst liegt ein Problem beim Rewrite vor.
  2. Die Middleware ohne Einfluss von Frontend kann man über direkten Aufruf eines Kanal prüfen: z.B. http://demo.volkszahler.org/middleware.php/data/7d3aa8c0-9e87-11e6-878f-b724ca3bd16b.json
  3. Ob die Middleware auf die Datenbank zugreifen kann prüft man mit einem Aufruf wie z.B. http://demo.volkszaehler.org/middleware.php/capabilities/database.json?. Sehr wahrscheinlich ist die Konfiguration der Middleware falsch.
    1. Eine Antwort wie {„version“:„0.3“,„capabilities“:{„database“:{„data“:{„rows“:0,„size“:49152},„aggregation“:{„rows“:0,„size“:49152,„ratio“:0}}}} ist IO
    2. Sowas {„version“:„0.3“,„exception“:{„message“:„Class \“Doctrine\\Common\\Annotations\\AnnotationRegistry\„ not found“,„type“:„Error“,„code“:0}} deutet auf Probleme mit Composer hin (Entwicklungsumgebung?).
    3. Bei {„version“:„0.3“,„exception“:{„message“:„An exception occurred in driver: SQLSTATE[HY000] [2002] Connection refused“,„type“:„ConnectionException“,„code“:0}} sind die Serverdaten (IP, Port) falsch.
    4. Mit falschen Zugangsdaten bekommt man {„version“:„0.3“,„exception“:{„message“:„An exception occurred in driver: SQLSTATE[HY000] [1045] Access denied for user 'xxxx'@'xxxx' (using password: YES)“,„type“:„ConnectionException“,„code“:0}}
  4. Zielführendere Diagnose bei DB-Zugriffsfehler erhält man auch wenn man die PHP-Fehlerausgabe über den http aktiviert und die Datenbank mit einem kurzen Skript direkt anspricht:
<?php
$servername = "localhost";
$username = "vz";
$password = "demo";
$database = "volkszaehler";
 
$conn = new PDO("mysql:host=$servername;dbname=$database", $username, $password);
 
$sql = ("SELECT * FROM entities");
foreach ($conn->query($sql) as $row) {
   echo $row['uuid']."<br />";
}
?>

Update

Die Aktualisierung aus dem Git über einen der Knöpfe im Webhostingportal anstoßen.

Danach den Composer aktualisieren. Dabei immer bei dem Weg bleiben den man bei der Installation gewählt hatte. Also entweder per Knopfdruck in Plesk oder SSH:

cd /volkszaehler
php /composer/composer.phar update