Springe zum Inhalt

Schlagwort: systemd

3

Veröffentlicht am 3 Kommentare zu Friendica: Update-Daemon und systemd

Für den Betrieb des dezentrale Netzwerk Friendica, welches auch hier auf einer eigenen Instanz läuft, 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:

d /run/friendica 0755 www-data www-data -

Das Verzeichnis wird mit den angegebenen Berechtigungen und Eigentümer angelegt. Damit das Verzeichnis sofort zur Verfügung steht, wird folgender Befehl verwendet:

systemd-tmpfiles --create --prefix /run/friendica

Anschließend wird das Unit-File für systemd unter "/etc/systemd/system/friendica-daemon.service" mit folgendem Inhalt angelegt:

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

[Service]
User=www-data
Group=www-data
WorkingDirectory=/srv/friends
Type=simple
StandardOutput=null
StandardError=syslog
ExecStart=/usr/bin/php ./bin/daemon.php start
ExecStop=/usr/bin/php ./bin/daemon.php stop
PIDFile=friendica/daemon.pid
PrivateTmp=true
InaccessibleDirectories=/home /root /boot /opt /mnt /media
ReadOnlyDirectories=/etc /usr
Restart=always

[Install]
WantedBy=multi-user.target

Der Pfad bei WorkingDirectory muss auf den Pfad der lokalen Friendica-Installation angepasst werden. Anschießend werden die Unit-Files von systemd neu geladen:

systemctl daemon-reload

Jetzt kann der Update-Daemon mit systemd gestartet werden:

systemctl start friendica-daemon.service

Nach dem erfolgreichen Start schreibt der Update-Daemon seine PID in die oben angegebene Datei "/run/friendica/daemon.pid". Die gleiche PID sollte in der Ausgabe des folgenden Befehls angezeigt werden:

systemctl status friendica-daemon.service

Sollte bis hier hin alles korrekt verlaufen sein, kann der Update-Daemon für den automatischen Start beim Systemstart aktiviert werden:

systemctl enable friendica-daemon.service

2

Veröffentlicht am 2 Kommentare zu systemd: NFS, IPSEC und Reihenfolgen

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.

Was aber nun, wenn die NFS-Mountpoints, wie bei mir, erst über bestehende IPSEC-Tunnel erreichbar sind? Dann muss manuell Hand angelegt werden. In die einzelnen mnt-*.mount-Files kann nichts manuell eingetragen werden, da diese beim Systemstart automatisch von systemd-fstab-generator erzeugt werden. Abhängigkeiten können dort also keine eingetragen werden. Abhilfe schafft nur, dass in strongswan.service eingetragen wird, dass die Unit vor remote-fs.target gestartet werden muss. Dazu wird "Before=remote-fs.target" in strongswan.service eingetragen:

# cat /etc/systemd/system/multi-user.target.wants/strongswan.service
[Unit]
Description=strongSwan IPsec IKEv1/IKEv2 daemon using ipsec.conf
After=network.target
Before=remote-fs.target
 
[Service]
ExecStart=/usr/sbin/ipsec start --nofork
ExecReload=/usr/sbin/ipsec reload
StandardOutput=syslog
 
[Install]
WantedBy=multi-user.target

Zum Aktualisieren der Konfiguration anschließend noch ein "systemctl daemon-reload" und ab jetzt wird beim Booten Strongswan vor den NFS-Mounts gestartet.

Veröffentlicht am

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. ...weiterlesen "FastCGI für Munin mit systemd"

Veröffentlicht am

Unit-Files für systemd für seafile und seahub sind im Seafile-Manual zu finden. 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.

2

Veröffentlicht am 2 Kommentare zu Tiny Tiny RSS: Update-Daemon unter systemd betreiben

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.

Anschließend muss der Service aktiviert werden:

systemctl enable ttrss-update.service

Danach muss die Konfiguration der Dienste durch systemd neu eingelesen werden:

systemctl --system daemon-reload

und abschließend der Dienst selbst gestartet werden:

systemctl start ttrss-update.service

Alle obigen Befehle müssen natürlich als root oder mit vorangestelltem "sudo " ausgeführt werden.

Weitere Beispiele der Servicekonfiguration sind im TTRSS-Forum zu finden.