{"id":2575,"date":"2020-08-17T07:00:00","date_gmt":"2020-08-17T05:00:00","guid":{"rendered":"https:\/\/www.my-it-brain.de\/wordpress\/?p=2575"},"modified":"2020-08-11T10:04:16","modified_gmt":"2020-08-11T08:04:16","slug":"tdps-service-service-unit-fuer-den-teamdrive-personal-server","status":"publish","type":"post","link":"https:\/\/www.my-it-brain.de\/wordpress\/tdps-service-service-unit-fuer-den-teamdrive-personal-server\/","title":{"rendered":"tdps.service — Service-Unit f\u00fcr den TeamDrive Personal Server"},"content":{"rendered":"\n

Kaum eine Software verwende ich so lange wie TeamDrive<\/a>. Die ersten Artikel dazu in diesem Blog stammen bereits aus dem Jahr 2011 [0]<\/a>, [1]<\/a>.<\/p>\n\n\n\n

Nachdem ich den TeamDrive Personal Server<\/a> schon auf einem NAS installiert<\/a> und als Dienst konfiguriert<\/a> habe, dokumentiere ich in diesem Artikel die Erstellung einer Systemd-Service-Unit<\/a>. Dazu sei gesagt, dass ich kein Experte f\u00fcr Systemd-Units bin. Tats\u00e4chlich kenne ich mich nichtmal besonders gut damit aus. Folgende L\u00f6sung funktioniert auf meinem Server. Anregungen zur Verbesserung der Service-Unit nehme ich gern in den Kommentaren entgegen.<\/p>\n\n\n\n

Installation des TeamDrive Personal Server<\/h2>\n\n\n\n

Zuerst muss der TeamDrive Personal Server heruntergeladen<\/a> und installiert werden. Dabei hilft das dazugeh\u00f6rige Handbuch<\/a>. Auch wenn dieses schon einige Jahre auf dem Buckel hat, sind die enthaltenen Informationen weiterhin aktuell.<\/p>\n\n\n\n

Da die Installation hier im Blog bereits einmal beschrieben wurde,<\/a> gehe ich hier im Detail nicht weiter darauf ein. Im vorliegenden Fall wurde die Software im Verzeichnis \/opt\/tdps<\/em> installiert. Dar\u00fcber hinaus wurde ein Benutzer tdps<\/em> erstellt, welchem das Verzeichnis \/opt\/tdps<\/em> und die darin enthaltenen Dateien geh\u00f6ren.<\/p>\n\n\n\n

Systemd-Service-Unit tdps.service<\/h2>\n\n\n\n

Ich habe den TeamDrive Personal Server (TDPS) auf einem Debian 10 System installiert. Um diesen wie alle \u00fcbrigen Dienste mit dem Programm systemctl<\/a> verwalten zu k\u00f6nnen, habe ich die Datei \/etc\/systemd\/system\/tdps.service<\/em> mit folgendem Inhalt erstellt:<\/p>\n\n\n\n

[Unit]\nDescription=\"TeamDrive Personal Server\"\nAfter=network.target\n\n[Service]\nUser=tdps\nPIDFile=\/opt\/tdps\/tdpsd.pid\nExecStart=\/opt\/tdps\/tdpsd -c \/opt\/tdps\/tdps.config -m \/opt\/tdps\/mime.types -w \/opt\/tdps\nExecStop=\/opt\/tdps\/stop-tdps -p \/opt\/tdps\/tdpsd.pid\nKillMode=process\nPrivateTmp=yes\nProtectHome=yes\nProtectSystem=full\n\n[Install]\nWantedBy=multi-user.target<\/code><\/pre>\n\n\n\n
Im Abschnitt [Unit]<\/code> findet sich eine kurze Beschreibung der Service-Unit. Die Option After=network.target<\/code> gibt an, dass diese Unit erst gestartet werden soll, wenn das Netzwerk zur Verf\u00fcgung steht. Dies ist Voraussetzung, um den Dienst \u00fcber das Netzwerk nutzen zu k\u00f6nnen.<\/p>\n\n\n\n
Die Zeile im letzten Abschnitt [Install]<\/code> definiert, dass diese Unit Bestandteil des multi-user.target<\/code> ist und mit diesem geladen wird.<\/p>\n\n\n\n
Der Abschnitt [Service]<\/code> definiert die f\u00fcr den Dienst relevanten Parameter. Die gew\u00e4hlten Optionen werde ich im Folgenden erl\u00e4utern.<\/p>\n\n\n\n
User=<\/code> gibt den Namen des Benutzers an, mit dessen Rechten der Dienst ausgef\u00fchrt werden soll. In diesem Fall wird der extra f\u00fcr diesen Zweck erstellte User tdps<\/em> verwendet.<\/p>\n\n\n\n
PIDFile=<\/code> gibt den Pfad an, wo der Dienst seine PID speichert. Der Service-Manager liest die PID des Hauptprozess aus dieser Datei, nachdem der Service gestartet wurde.<\/p>\n\n\n\n
ExecStart=<\/code> gibt das Kommando mit allen notwendigen Argumenten an, um den Dienst zu starten. Ich habe hier ein wenig mit verschiedenen Aufrufen experimentiert. Dabei habe ich verschiedene M\u00f6glichkeiten gefunden, den Dienst erfolgreich zu starten. Worin die Unterschiede im Aufruf genau bestehen, kann ich leider nicht sagen. Am Ende habe ich mich f\u00fcr obige Kommandozeile entschieden, die ich im TeamDrive-Forum gefunden habe.<\/a> Aus diesem Foren-Beitrag habe ich auch Stumpf die Option KillMode=process<\/code> \u00fcbernommen. Zur Option selbst kann ich (noch) nicht viel sagen. Dies \u00e4nderst sich vielleicht noch, da ich mich noch etwas damit besch\u00e4ftigen m\u00f6chte.<\/p>\n\n\n\n
Mit ExecStop=<\/code> gibt man entsprechend an, wie der Dienst zu stoppen ist. Auch hier stammt die Kommandozeile aus oben verlinktem Foren-Thread.<\/p>\n\n\n\n
Die n\u00e4chsten drei Optionen PrivateTmp=<\/code><\/code>, ProtectHome=<\/code> und ProtectSystem=<\/code> dienen dazu den Dienst zu h\u00e4rten. Durch PrivateTmp=yes<\/code> erh\u00e4lt der gestartete Prozess einen eigenen Dateisystem-Namespace f\u00fcr \/tmp<\/em> und \/var\/tmp<\/em>. So kann der Prozess nicht auf die Dateien anderer Prozesse und Benutzer in den normalen Verzeichnissen \/tmp<\/em> und \/var\/tmp<\/em> zugreifen. Mit ProtectHome=yes<\/code>wird der Zugriff des Dienstes auf die Verzeichnisse \/home<\/em>, \/root<\/em> und \/run\/user<\/em> verhindert. ProtectSystem=full<\/code> sorgt daf\u00fcr, dass die Verzeichnisse \/boot<\/em>, \/etc<\/em> und \/usr<\/em> im Nur-Lese-Modus f\u00fcr den Prozess zur Verf\u00fcgung stehen. Damit ist sichergestellt, dass der von dieser Unit gestartete Prozess keine Dateien innerhalb dieser Verzeichnisse ver\u00e4ndern kann.<\/p>\n\n\n\n
Die drei im vorhergehenden Abschnitt genannten Optionen stellen einen zus\u00e4tzlichen Schutz dar. Zwar darf der Benutzer tdps<\/em> schon aufgrund der Datei- und Verzeichnisberechtigungen nicht in den genannten Verzeichnissen schreiben und Dateien ver\u00e4ndern bzw. diese \u00fcberhaupt lesen, doch bieten diese Optionen einen zus\u00e4tzlichen Schutz und greifen auch noch, wenn jemand Schindluder mit den Berechtigungen getrieben hat. Daher halte ich es f\u00fcr sinnvoll diese Optionen wenn m\u00f6glich in allen Service-Units zu nutzen.<\/p>\n\n\n\n
Neben den drei hier vorgestellten Optionen gibt es noch einige weitere, welche im englischsprachigen Artikel „Mastering systemd: Securing and sandboxing applications and services“<\/a> nachgelesen werden k\u00f6nnen. Ich finde diese so sinnvoll, dass ich mich ehrlich gesagt frage, warum die genannten Einstellungen nicht der Standard sind und man diese editieren muss, wenn man entsprechende Zugriffe explizit erlauben m\u00f6chte.<\/p>\n\n\n\n
Damit ist alles getan und dokumentiert. Der TDPS l\u00e4sst sich mit oben beschriebener Service-Unit starten und stoppen. Den Status abfragen kann man selbstverst\u00e4ndlich auch.<\/p>\n\n\n\n
Es bleibt ein kleiner Sch\u00f6nheitsfehler. Wird der Dienst mittels sudo systemctl stop tdps.service<\/code> gestoppt, endet die Unit im Status „failed“. Warum das so ist, habe ich noch nicht herausgefunden. Ich vermute, es h\u00e4ngt damit zusammen, dass der Dienst mittels SIGTERM beendet wird. Bin mir an dieser Stelle jedoch nicht sicher. Falls von euch jemand eine Idee dazu hat, freue ich mich \u00fcber euren Kommentar.<\/p>\n\n\n\n
Wie schreibt ihr eure Service-Units? Welche Optionen sollten eurer Meinung nach in keiner Unit fehlen? Wenn ihr m\u00f6gt, lasst uns gerne in den Kommentaren dar\u00fcber diskutieren.<\/p>\n\n\n\n
\u00c4ltere Artikel zu TeamDrive in diesem Blog<\/h2>\n\n\n\n