Fix to start pcscd appropriately

[sarroutbi]

No description provided.

[oldium]

Just curious - the tcscd cannot be started by SystemD? I was solving the same service problem in TPM 1.2 code with tcsd (from trousers package, one letter less 😁) and have it working both for SystemD (Dracut) and non-SystemD (Dracut without SystemD, initramfs-tools).

[sarroutbi]

Just curious - the tcscd cannot be started by SystemD? I was solving the same service problem in TPM 1.2 code with tcsd (from trousers package, one letter less 😁) and have it working both for SystemD (Dracut) and non-SystemD (Dracut without SystemD, initramfs-tools).

Do you mean pcscd? We need it started in dracut, before Systemd appears ...

[oldium]

Yes, I mean pcscd 🙈 (typo, ehm).

You need to start pcscd before unlocking, not before SystemD, right? I added Wants+After tcsd dependency to clevis-luks-askpass.service, so that it is started before unlocking by SystemD automatically. I am now talking about the case when Dracut has SystemD enabled.

But maybe I just miss something...

Edit: This is not the only change. I also added a patch to tcsd SystemD service (via system-wide tcsd.service.d override) to allow starting it early (it adds DefaultDependencies=no and few dependencies).

My goal was to use as much existing configuration (service, data) as possible to remove the need to maintain full parallel configuration to third-party tools.

[sarroutbi]

Yes, I mean pcscd 🙈 (typo, ehm).

You need to start pcscd before unlocking, not before SystemD, right? I added Wants+After tcsd dependency to clevis-luks-askpass.service, so that it is started before unlocking by SystemD automatically. I am now talking about the case when Dracut has SystemD enabled.

But maybe I just miss something...

Edit: This is not the only change. I also added a patch to tcsd SystemD service (via system-wide tcsd.service.d override) to allow starting it early (it adds DefaultDependencies=no and few dependencies).

My goal was to use as much existing configuration (service, data) as possible to remove the need to maintain full parallel configuration to third-party tools.

Sincerely, I don't feel comfortable changing this so that it is called by systemd inside Dracut. IMHO, this is far more simple.

[oldium]

Ok, understood.

I was also afraid originally, but that was before I got more experience with it. SystemD inside Dracut (“initrd” bootup) works actually very similar to normal bootup (“system manager” bootup), so my goal was simple - if it works in one SystemD environment, it will work in the other environment. It not only unlocks the boot disk in the initrd phase, but it is also able to unlock other disks early in normal boot. So that I had to make it work once and it works great. Moreover, I do not have to care about parallel startup of my tcsd and the one started by SystemD service. I see that clevis-luks-pkcs11 is trying to prevent this situation (ps auxf | grep "[p]cscd"), but that does not stop SystemD from starting its instance. I decided to leave it on SystemD entirely because I did not want to cope with parallel startup of services and startup failures.

Edit: This is just my rationale for my implementation, I felt it is good to mention it when there is new implementation coming. But of course do whatever you feel fits better. 😊

[sergio-correia]

LGTM, thanks