Springe zum Inhalt

2

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:

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

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:

In Zeiten von systemd läßt sich das nun eleganter bewerkstelligen. ...weiterlesen "FastCGI für Munin mit systemd"

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

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:

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

Anschließend muss der Service aktiviert werden:

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

und abschließend der Dienst selbst gestartet werden:

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.