Minimalistic Logging Support

[blitz]

This PR is an alternative to #87. The end result is the same: When everything goes well, lanzaboote gives no output (fixing #84).

The approach is different in that we don't allow any runtime modification of logging level. The release build will only print warnings and errors. I think too much configurability is not really helping and just introduces complexity which we can avoid.

Closes #84.

[dasJ]

Things you could pick from the original PR (or we create a new PR for them):

• c3fa37a
• dd0e18f

[nikstur]

Things you could pick from the original PR (or we create a new PR for them):

I think a separate PR makes more sense.

[RaitoBezarius]

While I agree that added complexity is not desirable, moving forward with lanzaboote will expose it to various users and we will definitely encounter the need for runtime log level changes IMHO because users will not have an easy way to "enable a debug build" of lzbt in their state. So I am okay with this change as-is, because it's a move in the right direction (logging rather than no logging), but I am not satisfied with "no runtime modification".

I don't know when is the right moment to introduce it, so if you have a plan @blitz or if you think we need to have a formal discussion on it and track this feature, let's do it. :)

[blitz]

we will definitely encounter the need for runtime log level changes

I'm not so sure. But time will tell. :)

So I am okay with this change as-is, because it's a move in the right direction (logging rather than no logging), but I am not satisfied with "no runtime modification".

Fair enough. Let's cross this bridge when we get there.

[blitz]

@dasJ I've cherry picked 07ebc47. The error handling change is better done in a separate PR.

[nikstur]

LGTM

[nikstur]

we will definitely encounter the need for runtime log level changes IMHO because users will not have an easy way to "enable a debug build" of lzbt in their state.

Just to make sure: are you speaking about the stub or the tool?

I think the tool definetely needs configurable logging at some point but the stub does not. Does systemd-stub have configurable logging? From what I can tell it doesn't.

[RaitoBezarius]

we will definitely encounter the need for runtime log level changes IMHO because users will not have an easy way to "enable a debug build" of lzbt in their state.

Just to make sure: are you speaking about the stub or the tool?

The stub.

I think the tool definetely needs configurable logging at some point but the stub does not. Does systemd-stub have configurable logging? From what I can tell it doesn't.

It does not have, but also, there are issues such as systemd/systemd#25911 where I do think configurable debugging will make easier bug reports.

Anyway, I am fine with revisiting this once we hit enough usage that it becomes useful.