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.