Systemd und dm over dm

Du kommst mit der Installation nicht voran oder willst noch was nachfragen? Schau auch in den "Tipps und Tricks"-Bereich.
wanne
Moderator
Beiträge: 7447
Registriert: 24.05.2010 12:39:42

Re: Systemd und dm over dm

Beitrag von wanne » 01.03.2017 23:22:18

So habe es jetzt hinbekommen. Das problem war, dass das überladen des systemd-cryptsetup services nicht funktioniert hat.
Ich habe jetzt die crypttab ganz weggeworfen, den Service in ext_crypt umbenannt und mit cryptsetup statt crypttdisk geschrieb. (Eigentlich ist das eh die besser Variante, das cryptsetup um einiges mächtiger ist.)

Hier der Volle jetzt funktionierende Aufbau:
/etc/systemd/system/ext_cache.service:

Code: Alles auswählen

Description=Cache-device for ext_home
Requires=local-fs.target


[Service]
Type=oneshot
RemainAfterExit=yes
TimeoutSec=5
ExecStart=/sbin/dmsetup create ext_cache --table '0 456534016 cache /dev/sda7 /dev/sda8 /dev/sdb4 2048 1 writeback default 0' 
ExecStop=/sbin/dmsetup suspend ext_cache ; /sbin/dmsetup clear ext_cache ; /sbin/dmsetup remove ext_cache 

[Install]
WantedBy=multi-user.target
/etc/systemd/system/ext_crypt.service

Code: Alles auswählen

[Unit]
Description=Crypto-device for ext_home
Requires=ext_cache.service
After=ext_cache.service


[Service]
Type=oneshot
RemainAfterExit=yes
TimeoutSec=5
ExecStart=/sbin/cryptsetup open --type luks --key-file /etc/hompw --allow-discards /dev/mapper/ext_cache ext_home 
ExecStop=/sbin/cryptsetup close ext_home
                                                                                                                                     
[Install]                                                                                                                            
WantedBy=multi-user.target
/etc/fstab

Code: Alles auswählen

[…]
LABEL=ext_home          /home/wanne/VirtualBox\040VMs  btrfs nofail,compress=zlib,subvol=/VMs,x-systemd.after=ext_crypt.service        0 0
LABEL=ext_home          /home/live                     btrfs nofail,compress=zlib,subvol=/live,x-systemd.after=ext_crypt.service       0 0
Vielen dank nochmal an TomL für die Mühe.
rot: Moderator wanne spricht, default: User wanne spricht.

Benutzeravatar
schorsch_76
Beiträge: 2535
Registriert: 06.11.2007 16:00:42
Lizenz eigener Beiträge: MIT Lizenz

Re: Systemd und dm over dm

Beitrag von schorsch_76 » 02.03.2017 07:44:02

Nur ein kleiner Hinweis:

Code: Alles auswählen

Requires=local-fs.target
Vermutlich willst du dass diese Unit NACH local-fs.target gestartet wird. Deshalb gibt es da das Pattern

Code: Alles auswählen

Requires=local-fs.target
After=local-fs.target

https://www.freedesktop.org/software/sy ... html[quote]
Requires=
Configures requirement dependencies on other units. If this unit gets activated, the units listed here will be activated as well. If one of the other units gets deactivated or its activation fails, this unit will be deactivated. This option may be specified more than once or multiple space-separated units may be specified in one option in which case requirement dependencies for all listed names will be created. Note that requirement dependencies do not influence the order in which services are started or stopped. This has to be configured independently with the After= or Before= options. If a unit foo.service requires a unit bar.service as configured with Requires= and no ordering is configured with After= or Before=, then both units will be started simultaneously and without any delay between them if foo.service is activated. Often, it is a better choice to use Wants= instead of Requires= in order to achieve a system that is more robust when dealing with failing services.
[/quote]

Siehe auch:
http://serverfault.com/questions/812584 ... d-requires

wanne
Moderator
Beiträge: 7447
Registriert: 24.05.2010 12:39:42

Re: Systemd und dm over dm

Beitrag von wanne » 02.03.2017 09:47:21

schorsch_76 hat geschrieben:Vermutlich willst du dass diese Unit NACH local-fs.target gestartet wird.
Kp. Ich habe das nur eingebaut, weil TomL das gesagt hat.
rot: Moderator wanne spricht, default: User wanne spricht.

wanne
Moderator
Beiträge: 7447
Registriert: 24.05.2010 12:39:42

Re: Systemd und dm over dm

Beitrag von wanne » 02.03.2017 13:27:02

Von wegen:
Das ganze funktioniert nur, wenn ich nicht als live angemeldet bin.
Bin ich als live angemeldet und fahre dann herunter passiert das:

Code: Alles auswählen

Unmounting /home/live
umount: /home: target is bus
systemd[1]: Stopping Crypto-device for ext_home...
cryptsetup[2503]: device-mapper: remove ioctl on ext_home failed: Device or resource busy
systemd[1]: home.mount mount process exited, code=exited status=32
systemd[1]: Failed unmounting /home.
[…]
systemd[1]: ext_crypt.service: control process exited, code=exited status=5
a) Systemd Versucht weiterhin das device zu removen, obwohl er es nicht selber erstlle.
b) Er versucht /home/live zu unmounten obwohl ich noch eingeloggt bin. Das schlägt fehl. Daraufhin fährt einfach mit der ganz normalen Bootreihenfolge fort.
c) Die x-systemd werden fleisig ignoriert. Er gibt das schlicht und einfach dem mount Befehl mit.
rot: Moderator wanne spricht, default: User wanne spricht.

wanne
Moderator
Beiträge: 7447
Registriert: 24.05.2010 12:39:42

Re: Systemd und dm over dm

Beitrag von wanne » 02.03.2017 14:04:41

so ich habe jetzt aufgegeben und für jeden mount einen eigenen unit file erstellt.
Das funktioniert. der systemd cryptsetup service versucht immer noch dazwischen zu pfuschen. Faild dann aber zum glück.
Log dazu:

Code: Alles auswählen

cryptsetup[2345]: device-mapper: remove ioctl on ext_home failed: Device or resource busy
Und das obwohl er das Device nie anlegt.

Hier noch ein paar Highlights aus dem log zu systemd-cryptsetup:
Ganz ein schlauer ist das:

Code: Alles auswählen

systemd-cryptsetup[995]: Key file /dev/urandom is world-readable. This is not a good idea!
Glaube ich doch. Ich glaube meine Sicherheit wäre ziemlich im Eimer, wenn niemand mehr Zufallszahlen bekommen würde…

sdb5_crypt ist das Device für /. Wird entsprechend vom Kernel verwaltet.
systemd-cryptsetup versucht es trotzdem nochmal:

Code: Alles auswählen

systemd-cryptsetup[851]: Volume sdb5_crypt already active.
Ach ne.. Und beim Runterfahren dann:

Code: Alles auswählen

systemd-cryptsetup[2365]: Failed to deactivate: Device or resource busy
systemd[1]: systemd-cryptsetup@sdb5_crypt.service: control process exited, code=exited status=1
systemd[1]: Unit systemd-cryptsetup@sdb5_crypt.service entered failed state
Du sitzt selber auf dem device… Dir ist schon klar das du dich damit selbst zerstören würdest?
rot: Moderator wanne spricht, default: User wanne spricht.

TomL

Re: Systemd und dm over dm

Beitrag von TomL » 02.03.2017 17:02:14

wanne hat geschrieben:
schorsch_76 hat geschrieben:Vermutlich willst du dass diese Unit NACH local-fs.target gestartet wird.
Kp. Ich habe das nur eingebaut, weil TomL das gesagt hat.
Nein, der Eintrag "After=local-fs.target" fehlt ja immer noch oben in der Unit! Obwohl ich schon ganz zu Anfang darauf hingewiesen habe und dann noch einmal und Schorsch jetzt auch erneut. BTW, ich halte auch den Type oneshot für falsch - weil es sich hier um fortlaufend verschlüsselte "Kommunikation" handelt, die eben ein Daemon leistet. Ich hätte das vermutlich anders aufgebaut... zunächst mal keine 2 Units, sondern nur 1..... eher so:

Code: Alles auswählen

[Unit]
Description=luks-device.service:   Open local Harddisk as Luks-Device with persistent CryptCredentials
After=local-fs.target
Requires=local-fs.target
ConditionPathExists=/etc/hompw 

[Service]
Type=forking
RemainAfterExit=yes

ExecStartPre=/sbin/dmsetup create ext_cache --table '0 456534016 cache /dev/sda7 /dev/sda8 /dev/sdb4 2048 1 writeback default 0'
ExecStart=/sbin/cryptsetup open --type luks --key-file /etc/hompw --allow-discards /dev/mapper/ext_cache ext_home
ExecStop=/sbin/cryptsetup close ext_home
ExecStopPost=/sbin/dmsetup suspend ext_cache ; /sbin/dmsetup clear ext_cache ; /sbin/dmsetup remove ext_cache 

[Install]
WantedBy=multi-user.target
Und speziell hier hätte ich die Verwendung der fstab sowieso nicht weiter erwogen, sondern direkt über eigene Mount-Units nachgedacht. Wenn ich mehrere Mounts auf dieses Cryptdevice verbinden müsste, würde ich kurzerhand dafür eine eigene Unit mit multiple ExecStarts im Anschluß (after=) dieser Service-Unit ausführen. Und hätte ich nur EINEN Mount, würde ich den einfach direkt hier in der Mitte platzieren, mit Start und Stop, und dann Cryptsetup open/close kurzerhand auf Pre und Post verlegen.... und fertig ist die Kiste.

Das Problem ist, das es speziell hier im Laufe des Thread aufgrund ständig stark gekürzter und unverständlichen Angaben irgendwie immer unheimlich schwer ist, die Probleme überhaupt zu diagnostizieren. Erst anhand der 2 obigen Units kann man erkennen, wie der Hase läuft. Man hatte vorher kaum ein Gesamtbild über Start, Wegstrecke, verwendete "Fahrzeuge", geplantes Ziel und welche Probleme an welcher Stelle auftauchen.

Eigentlich ist das an dieser Stelle ganz einfach... wenn man die Befehle, mit denen man den kompletten Ablauf manuell im Terminal erfolgreich durchführen könnte, einfach auf eine Service-Unit überträgt..... das funktioniert imho immer.
Zuletzt geändert von TomL am 02.03.2017 20:35:25, insgesamt 1-mal geändert.

wanne
Moderator
Beiträge: 7447
Registriert: 24.05.2010 12:39:42

Re: Systemd und dm over dm

Beitrag von wanne » 02.03.2017 19:08:01

TomL hat geschrieben:BTW, ich halte auch den Type oneshot für falsch - weil es sich hier um fortlaufend verschlüsselte "Kommunikation" handelt, die eben ein Daemon leistet.
Zuerstmal ist der [Service] Teil das Originalbeispiel (mit angepassten Namen) von feedesktop.org – Also den Machern von Systemd selbst.
Ansonsten ist cryptsetup eben kein Daemon. Es kofiguriert die IO im Kernel lediglich anders statt im Klartext zu schreiben schreibt er danach direkt verschlüsselt. Es beleibt danach kein Prozess übrig der irgend was macht. Lediglich die Arbeitsweise des Kernels wird verändert. Lediglich die Schreibfunktion des Kernels wird verändert. Er muss auch eigentlich überhaupt nicht beendet werden. Das zurücksetzen auf defaults ist eher der Schönheit wegen.
TomL hat geschrieben:Und speziell hier hätte ich die Verwendung der fstab sowieso nicht weiter erwogen, sondern direkt über eigene Mount-Units nachgedacht. Wenn ich mehrere Mounts auf dieses Cryptdevice verbinden müsste, würde ich kurzerhand dafür eine eigene Unit mit multiple ExecStarts im Anschluß (after=) dieser Service-Unit ausführen. Und hätte ich nur EINEN Mount, würde ich den einfach direkt hier in der Mitte platzieren, mit Start und Stop, und dann Cryptsetup open/close kurzerhand auf Pre und Post verlegen.... und fertig ist die Kiste.
[…]
Das Problem ist, das es speziell hier im Laufe des Thread aufgrund ständig stark gekürzter und unverständlichen Angaben irgendwie immer unheimlich schwer ist, die Probleme überhaupt zu diagnostizieren. Erst anhand der 2 obigen Units kann man erkennen, wie der Hase läuft. Man hatte vorher kaum ein Gesamtbild über Start, Wegstrecke, verwendete "Fahrzeuge", geplantes Ziel und welche Probleme an welcher Stelle auftauchen.
[…]
das funktioniert imho immer.
Wenn es mir nur um dieses eine Problem auf meinem lokalen PC gegangen wäre hätte ich einfach ein bash-Script in die rc.local gehauen und das Problem wäre erledigt gewesen. Oder alternativ einfach SystemV init installiert.

Das Ding ist, dass mir das Abhängigkeitsmanagement in Systemd (Insbesondere mit Devices und mounts) nicht das erste (und auch garantiert nicht das letzte) mal verfolgt.
Auf der Arbeit läuft z.B. parktisch gar nichts direkt über systemd. Startup läuft über Scripte in von Hand gepflegter Reihenfolge, Dann gibts es zwei Monitoring Lösungen von Drittanbietern und jede menge Gefrikel für HA, wenn die was feststellen.
Wäre eigentlich schön, wenn man sowas mit Systemd machen könnte.

Deswegen wäre ich an einer Systemd-Lösung für sowas wie Abhängigkeitsmanagement interessiert gewesen. Eigentlich war das ja für sowas gedacht.
Alles sequenziell in manuell vorgegebenenr Reihenfolge nacheinander in ein bash Script schreiben und mich dann um Monitoring und und Ausfälle von Hand kümmern ist für meinen PC machbar aber für größere Umgebungen absolut untauglich.

Deswegen habe ich den Eigentlichen Inhalt weggelassen. Ich wollte keine Endlosdiskussionen über die eigentlichen Services, und durch was man die alles ersetzen könnte. Sondern ob und wie es möglich ist, Abhängigkeitsmanagement von beliebigen Services Systemd erledigen zu lassen.

Offensichtlich funktioniert das eher nicht. Auch jetzt funktioniert das ganze ja nur, weil das Fehlschalgen von systemd-cryptsetup halt harmlos ist.
rot: Moderator wanne spricht, default: User wanne spricht.

TomL

Re: Systemd und dm over dm

Beitrag von TomL » 02.03.2017 19:24:30

wanne hat geschrieben:Sondern ob und wie es möglich ist, Abhängigkeitsmanagement von beliebigen Services Systemd erledigen zu lassen.
Offensichtlich funktioniert das eher nicht.Auch jetzt funktioniert das ganze ja nur, weil das Fehlschalgen von systemd-cryptsetup halt harmlos ist
Und genau diese Aussage kann ich überhaupt nicht nachvollziehen. Ich glaube fast, dass das Fehlschlagen vielleicht andere Gründe hat. Ich nutze Cryptsetup in mehreren Varianten und unterschiedlichen festen und variablen Devices und fehlerhaftes Abhängigkeitsmanagement habe ich noch nie beobachten können. Meiner Meinung nach ist es gerade unter Systemd wirklich einfach, eine Kette von Abhängigkeiten zu bilden.... es muss dann im Anschluß nur gelingen, diese Kette an die richtige Stelle in den gesamten Boot-Prozess sauber einzufügen. Aber das betrifft dann auch nur wieder das erste Glied dieser Kette. Aber auch dabei kenne ich jetzt keine Probleme mehr. Allerdings fällt mir zu diesem aktuellen Problem jetzt wirklich kein Rat mehr ein.... :|

Benutzeravatar
schorsch_76
Beiträge: 2535
Registriert: 06.11.2007 16:00:42
Lizenz eigener Beiträge: MIT Lizenz

Re: Systemd und dm over dm

Beitrag von schorsch_76 » 02.03.2017 20:16:27

Meiner Meinung nach ist das Problem, das es an das multi-user.target gehängt ist.

Das Ziel ist ja, ein lokales Filesystem bereit zu stellen das auf einem Software, Kernel block device läuft. Sprich: local-fs.target wäre schon rightig (meiner Meinung nach).

Erst wenn beim Shutdown local-fs.target geschlossen wird, muss auch der dm-cache weg. Dann ist auch sicher kein User mehr eingeloggt und es läuft keine VM mehr. Da wir hier sehr sehr früh im Systemstart sind, müssen die default dependencies ausgeschalten werden. Ein Beispiel ist z.b. di HW Uhr an meinem Pi:

Code: Alles auswählen

cat /etc/systemd/system/hwclock-pi.service 
[Unit]
Description=HWClock at the I2C Bus of the Raspberry pi
Before=basic.target
Conflicts=shutdown.target
DefaultDependencies=no

[Service]
Type=oneshot
ExecStart=/bin/sh -c "modprobe i2c_bcm2835 && modprobe i2c_bcm2708 && modprobe rtc_ds1307 && sleep 1 && echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device && /sbin/hwclock -s"
ExecStop=/sbin/hwclock -w
RemainAfterExit=yes

[Install]
WantedBy=basic.target
Hier soll auch sehr früh das Modul geladen werden und ein paar Befehle ausgeführt werden. Oneshot, da kein Prozess da bleibt, der Überwacht wird, wie bei wanne.

Genauso würde ich es auch bei dem ext_home cache machen. Alles in eine Unit, keine default dependencies und WantedBy=local-fs.target und Before=local-fs.target

Ich bin mir nur gerade nicht sicher, ob wanne es an local-fs.target hängen kann. basic.target funktioniert hier bei der Uhr sehr gut.

Siehe auch
https://www.freedesktop.org/software/sy ... ootup.html

Edit: Ich denke local-fs.target ist noch in der initrd. Hier wird es nicht gehen. basic.target ist noch vor allen Diensten. ;)

EDITH: sagt:
Du solltest auch noch überlegen mit was das beendet wird. Ich denke
Conflicts=shutdown.target
Conflicts=sysvinit.target

So macht systemd das:

Code: Alles auswählen

cat  /var/run/systemd/generator/home.mount
# Automatically generated by systemd-fstab-generator

[Unit]
SourcePath=/etc/fstab
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
Before=local-fs.target
Requires=systemd-fsck@dev-laptop-home.service
After=systemd-fsck@dev-laptop-home.service

[Mount]
What=/dev/laptop/home
Where=/home
Type=ext4
Options=defaults,discard

TomL

Re: Systemd und dm over dm

Beitrag von TomL » 02.03.2017 20:45:23

Sorry, "DefaultDependencies=no" war ein Fehler von mir, den ich oben korrigert habe. Die Berücksichtigung der DefaultDependencies hier an der Stelle ist m.M.n. absolut korrekt. Und ich bin auch der Meinung, dass die Anbindung an multiuser.target richtig ist.... deshalb, weil ich davon ausgegangen bin, dass es sich bei den "angehängten" Crypt-Devices um reine verschlüsselte Daten-Devices handelt, ohne systemische Bedeutung, die wirklich erst im MultiUser-Level relevant sind. Meiner Meinung nach gibts hier auch keinen Konflikt mit dem Shutdown.Target, weil die Crypt-Ressource tatsächlich dann ordentlich vor dem lokalen Filesystem geschlossen wird, was ja richtig ist. "Conflicts" wäre erst dann notwendig, wenn ein asynchroner Effekt möglich wäre, weil mir der Shutdown beim Schließen von local-fs.target die Filesysteme unterm Hintern wegzieht, bevor das Cryptdevice geschlossen ist.... aber das kann imho wg. "after local-fs.target" nicht passieren.

Und wie gesagt, ich hätte auch nicht 'Oneshot' gewählt, sondern jetzt (ich gebe meinen Irrtum mit 'forking' zu) besser 'simpel' .... aber ich sehe das bei mir auch vor dem Hintergrund, dass ich das alles in einer Unit löse, also den device-mapper, crypt-setup und sofort auch den Mount, und beim Shutdown den gleichen Weg zurück. Da gibts es keine Konflikte oder Umstimmigkeiten mit dem Abhängigkeitsmanagement. Und ich wollte auch nicht, dass es wegen 'oneshot'" wartet, bis alles durch ist und dann erst mit Follow-Up-Units weitermacht. Aber möglicherweise ist das bei hier mehreren verketteten Units ein besserer Weg.... aber requires und after führen imho hier zum gleichen Ziel.

Benutzeravatar
schorsch_76
Beiträge: 2535
Registriert: 06.11.2007 16:00:42
Lizenz eigener Beiträge: MIT Lizenz

Re: Systemd und dm over dm

Beitrag von schorsch_76 » 02.03.2017 22:08:27

Hallo wanne,
das löst dein Problem :)

Code: Alles auswählen

 cat /etc/systemd/system/ext-cache.service 
[Unit]
Description=EXT CACHE
Before=local-fs.target umount.target shutdown.target
Conflicts=umount.target shutdown.target
DefaultDependencies=no

[Service]
Type=oneshot
ExecStart=/bin/sh -c "sleep 10 && echo Start EXTCACHE"
ExecStop=/bin/sh -c "sleep 20 && echo Stop EXTCACHE"
KillMode=none
RemainAfterExit=yes

[Install]
WantedBy=local-fs.target
Das hier wird vor dem loca-fs.target ausgeführt und nach vor dem local-fs.target beendet :D

TomL

Re: Systemd und dm over dm

Beitrag von TomL » 03.03.2017 10:00:33

Moin

Sorry... aber ich verstehe diesen Satz hier nicht:
schorsch_76 hat geschrieben:Das hier wird vor dem loca-fs.target ausgeführt und nach vor dem local-fs.target beendet :D
Und ich verstehe auch nicht, in welchem Zusammenhang diese neue Unit Einfluss auf das Problem haben könnte. In welcher Richtung muss ich da denken? :?
Was ist der Sinn, sie vor local-fs.target UND shutdown.target auszuführen, aber durch das "conflicts-statement" beim Shutdown dann doch zwangsweise beenden zu lassen? Welchen Einfluss hat das überhaupt, eine verschlüsselte Nicht-System-Partition-Unit überhaupt vor dem local-fs.target anzuziehen, wenn die doch erst bei multi-user.target benötigt wird? Und ich verstehe auch nicht, welchen Sinn es hat, sie aus den Default-Dependencies herauszulösen, wo doch gerade die Filesysteme auch von den Default-Dependencies abhängig sind.... ich denke da jetzt nur an Netzwerkverbindungen usw. Die Def-Dep haben eine implizite Abhängigkeit mit "After=" zu sysinit.target und basic.target. Welchen Vorteil hat es, das abzuschalten?

Benutzeravatar
schorsch_76
Beiträge: 2535
Registriert: 06.11.2007 16:00:42
Lizenz eigener Beiträge: MIT Lizenz

Re: Systemd und dm over dm

Beitrag von schorsch_76 » 03.03.2017 14:38:22

Ups ... war undeutlich ausgedrückt.

Es wird beim Start vor dem Target local-fs.target gestartet. Beim Runterfahren wird bevor umount.target das Ding wieder gestoppt.

Antworten