Systemd

Für den Betrieb des dezentrale Netzwerk Friendica, müssen periodisch Nachrichten verschickt und notwendige andere Aufgaben abgearbeitet werden. Früher konnte dazu ein Cron-Job eingerichtet oder alternativ ein Addon installiert werden, welche diese Aufgaben periodisch ausführte. Mittlerweile hat Friendica dafür einen eigenen Daemon bekommen, dessen Einbindung in ein Debian-System mit systemd hier kurz vorgestellt wird.

Der Update-Daemon erzeugt ein PID-File, dessen Name und Pfad in der Konfigurationsdatei “config/local.config.php” eingestellt wird:

'system' => [
  'pidfile' => '/run/friendica/daemon.pid',
 ],

Beim Systemstart existiert obiges Verzeichnis noch nicht. Debian verwaltet flüchtige Dateien und Verzeichnisse mit systemd-tmpfiles. Damit dieses Verzeichnis beim Systemstart automatisch angelegt wird, kann in die Datei “/etc/tmpfiles.d/friendica.conf” Folgendes eingetragen werden:

Einige Distributionen haben auf das als eierlegende Wollmilchsau beschriebene und von anderen mehr als gehasste systemd umgestellt. Ein Service, der den Startprozess einfacher, paralleler und konfigurierbarer machen soll. In der mitgelieferten Konfiguration von systemd funktioniert auch alles erst mal nach einer frischen Installation, allerdings ist entsprechend der am meisten eingesetzten Konfigurationen vorgegeben, in welcher Reihenfolge was gestartet wird.

Beispiel NFS und Strongswan

Die Entwickler haben sich gedacht, dass wohl in den meisten Konfigurationen erst mal NFS gemounted werden muss und erst dann IPSEC bzw. Strongswan gestartet werden kann, denn es könnte ja sein, dass z.B. /usr ein NFS-Mountpoint ist, aus dem Strongswan erst nach dem Mounten seine Dateien laden könnte. Soweit so gut.

Munin kann so eingestellt werden, dass die Grafiken und HTML-Dateien nicht alle fünf Minuten sondern nur auf Anforderung bzw. beim Abrufen der jeweiligen Webseite erzeugt werden. Zuständig dafür sind die Einstellungen cgi_strategy und html_strategy in /etc/munin/munin.conf. Munin benötigt dazu zwei FastCGI-Schnittstellen, welche idealerweise über einen Socket angesprochen werden. Früher konnte man das Problem lösen, indem man an passender Stelle mit spawn-fcgi die entprechenden FastCGI-Schnittstellen über Sockets bereitstellte. Eine Lösungsmöglichkeit war z.B. folgende:

/usr/bin/spawn-fcgi -s /var/run/munin/fcgi-graph.sock -U www-data -u www-data -g www-data /usr/lib/munin/cgi/munin-cgi-graph
/usr/bin/spawn-fcgi -s /var/run/munin/fcgi-html.sock -U www-data -u www-data -g munin  /usr/lib/munin/cgi/munin-cgi-html

In Zeiten von systemd läßt sich das nun eleganter bewerkstelligen.

Unit-Files für systemd für seafile und seahub sind im Seafile-Manual. Für FastCGI muss das Skript für seahub entsprechend angepasst werden. Siehe den dortigen Kommentar

Das Major-Versionsupgrade von 4.2 auf 5.0 welches hier anstand hat mit der Methode “Schritt für Schritt jeden einzelnen Upgradeschritt aus ./update durchführen” problemlos funktioniert.

Mit der Version 5.0 hat sich die Wiki-Syntax für Links geändert. Leider werden bestehende Links nicht immer automatisch konvertiert.

Vor kurzem habe ich ein Distributions-Update durchgeführt und bin nun auch in den zweifelhaften Genuss von systemd gekommen. Im folgenden möchte ich beschreiben, wie der Update-Daemon von Tiny Tiny RSS unter systemd auf einem Debian 8 System betrieben werden kann.

Zuerst muss eine Konfigurationsdatei erstellt werden, die den Dienst beschreibt. Ich habe dazu die Datei /lib/systemd/system/ttrss-update.service mit folgendem Inhalt angelegt:

[Unit]
Description=Tiny Tiny RSS update daemon
After=network.target mysqld.service
Requires=network.target remote-fs.target nss-lookup.target

[Service]
User=www-data
Group=www-data
WorkingDirectory=/var/local/news
Type=simple
StandardOutput=null
StandardError=syslog
ExecStart=/usr/bin/php ./update_daemon2.php
PrivateTmp=true
InaccessibleDirectories=/home /root /boot /opt /mnt /media
ReadOnlyDirectories=/etc /usr

[Install]
WantedBy=multi-user.target

Unter WorkingDirectory muss dass Verzeichnis der TTRSS-Installation angepasst werden.