Adding more systemd service files

[mpeters]

Now all of the background stuff during the demo (tpm_server, tpm2-abrmd, keylime_ima_emulator, keylime_registrar, keylime_verifier, keylime_agent) can be run by systemd so you don't have to have it attached to a terminal and they are easy to restart.

For instance resetting the tpm emulation stuff is just

systemctl restart tpm_server tpm2-abrmd keylime_ima_emulator

And everything is also logging to /var/log so it's easy to show what's happening when you need to.

[mpeters]

Nice work @mpeters ! It's nice that we can restart all the TPM emulation with one command. We should add this to the keylime ansible playbook.

One thing to note is that it's still a lengthy command, so perhaps we can even script it, or preferably, perhaps we should create a new tpm-emulation pseudo application that these can all depend on so we can start/stop/restart all of it with one systemctl restart tpm-emulation command. WDYT?

That's an interesting idea. A shortcut would be nice I'll admit, but I also don't want the demo env to get too far away from what a real production setup will look like. As the demo evolves and we have actual hardware tpms, obv some of that will go away. tpm_server, keylime_ima_emulator. Does tpm2-abrmd go away as well?

Another possible avenue for the pseudo application: Sometimes the TPM emulator gets stuck and even the full systemctl restart command doesn't get things in the right state (and systemctl status shows everything up and running) and it needs to be run again. You can see this as keylime_ima_emulator runs ok, but spits out warnings/errors to it's log and then just sits there. So maybe the wrapper application would cause a restart of all those and do some sort of verification before exiting, so it would show up as failed in systemctl status

Definitely something to think about.

[font]

That's an interesting idea. A shortcut would be nice I'll admit, but I also don't want the demo env to get too far away from what a real production setup will look like. As the demo evolves and we have actual hardware tpms, obv some of that will go away. tpm_server, keylime_ima_emulator. Does tpm2-abrmd go away as well?

Yes, I agree. I should clarify that the nature of the suggestion was not necessarily to implement as part of this demo, but as a useful thing to have as part of the testing setup for keylime, such as its ansible playbook.

I think tpm2-abrmd will still be around to broker access to the hardware TPM, at least until the kernel RM gets to feature parity.

Another possible avenue for the pseudo application: Sometimes the TPM emulator gets stuck and even the full systemctl restart command doesn't get things in the right state (and systemctl status shows everything up and running) and it needs to be run again. You can see this as keylime_ima_emulator runs ok, but spits out warnings/errors to it's log and then just sits there. So maybe the wrapper application would cause a restart of all those and do some sort of verification before exiting, so it would show up as failed in systemctl status

:+1: