Re: [systemd-devel] troubleshooting Clevis
On 12/10/2021 16:54, Lennart Poettering wrote: On Di, 12.10.21 16:17, lejeczek (pelj...@yahoo.co.uk) wrote: I have 'clevis' set to get luks pin from 'tang' but unlock does not happen at/during boot time and I wonder if someone can share thoughts on how to investigate that? I cannot see anything obvious fail during boot, moreover, manual 'clevis-luks-unlock' works no problems. This is the systemd mailing list, not the clevis/tang mailing list. Please contact the clevis/tang community instead. May ask of any possible plans where systemd would, somehow similarly to 'tpm', utilize 'tang'(or similar) technique to unlock luks encrypted devices? You mean that networked unlock feature? I mean, it's not always clear what belongs and systemd and what does not. But outside of data centers I am not sure tang/clevis really has much use, and that's quite a limited userbase, so I'd say: no this should be done outside of systemd. Maybe a plugin for libcryptsetup's "token" feature. I cannot speak for datacentre conglomerates but I'd dare to pose a theory that increasingly more small setups, like mine with three nodes, start to find homes in our homes. In my basic setup where 'tang' on my laptops serves 'clevis' (or would if it worked) to unlock home HA cluster (also with Shamir's Secret Sharing implemented) having 'systemd' integrate all these techniques/method would be, not only for big datacentres, fantastic in my opinion. many thanks for all everybody's work. L. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] troubleshooting Clevis
On Di, 12.10.21 16:17, lejeczek (pelj...@yahoo.co.uk) wrote: > > > I have 'clevis' set to get luks pin from 'tang' but unlock does not happen > > > at/during boot time and I wonder if someone can share thoughts on how to > > > investigate that? > > > I cannot see anything obvious fail during boot, moreover, manual > > > 'clevis-luks-unlock' works no problems. > > This is the systemd mailing list, not the clevis/tang mailing > > list. Please contact the clevis/tang community instead. > > May ask of any possible plans where systemd would, somehow similarly to > 'tpm', utilize 'tang'(or similar) technique to unlock luks encrypted > devices? You mean that networked unlock feature? I mean, it's not always clear what belongs and systemd and what does not. But outside of data centers I am not sure tang/clevis really has much use, and that's quite a limited userbase, so I'd say: no this should be done outside of systemd. Maybe a plugin for libcryptsetup's "token" feature. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] troubleshooting Clevis
On 28/09/2021 12:33, Lennart Poettering wrote: On Di, 28.09.21 12:26, lejeczek (pelj...@yahoo.co.uk) wrote: Hi guys. I have 'clevis' set to get luks pin from 'tang' but unlock does not happen at/during boot time and I wonder if someone can share thoughts on how to investigate that? I cannot see anything obvious fail during boot, moreover, manual 'clevis-luks-unlock' works no problems. This is the systemd mailing list, not the clevis/tang mailing list. Please contact the clevis/tang community instead. May ask of any possible plans where systemd would, somehow similarly to 'tpm', utilize 'tang'(or similar) technique to unlock luks encrypted devices? ps. clevis + tang seem "broken" in CentOS stream & f35, unlocking @boot time to be specific, is not working. many thanks, L. Lennart -- Lennart Poettering, Berlin
[systemd-devel] Antw: [EXT] Re: [systemd‑devel] Removing bold fonts from boot messages
>>> Lennart Poettering schrieb am 12.10.2021 um 12:56 in Nachricht : > On Di, 12.10.21 12:09, Frank Steiner (fsteiner‑ma...@bio.ifi.lmu.de) wrote: > >> Hi, >> >> after upgrading from SLES 15 SP2 (systemd 2.34) to SP3 (systemd 2.46) >> the boot messages are not only colored (which I like for seeing failures >> in red) but partially printed in bold face. This makes messages indeed >> harder to read on serial console (with amt or ipmi), so I wonder if >> there is a place where the ascii sequences for colors and font faces >> are defined and can be adjusted? Stupid question: If you see bold face at the end of the serial line, wouldn't changing the terminal type ($TERM) do? Maybe construct your own terminal capabilities. > > Sounds like in an graphics issue in your terminal emulator, no? > >> Or is there some option to remove the bold face only, but not the colors? >> systemd.log_color=0 removes all formatting, but I'd like to keep the >> colors... > > No, this is not configurable. We are not a themeable desktop, sorry. > > Lennart > > ‑‑ > Lennart Poettering, Berlin
Re: [systemd-devel] Removing bold fonts from boot messages
On Di, 12.10.21 12:09, Frank Steiner (fsteiner-ma...@bio.ifi.lmu.de) wrote: > Hi, > > after upgrading from SLES 15 SP2 (systemd 2.34) to SP3 (systemd 2.46) > the boot messages are not only colored (which I like for seeing failures > in red) but partially printed in bold face. This makes messages indeed > harder to read on serial console (with amt or ipmi), so I wonder if > there is a place where the ascii sequences for colors and font faces > are defined and can be adjusted? Sounds like in an graphics issue in your terminal emulator, no? > Or is there some option to remove the bold face only, but not the colors? > systemd.log_color=0 removes all formatting, but I'd like to keep the > colors... No, this is not configurable. We are not a themeable desktop, sorry. Lennart -- Lennart Poettering, Berlin
[systemd-devel] Removing bold fonts from boot messages
Hi, after upgrading from SLES 15 SP2 (systemd 2.34) to SP3 (systemd 2.46) the boot messages are not only colored (which I like for seeing failures in red) but partially printed in bold face. This makes messages indeed harder to read on serial console (with amt or ipmi), so I wonder if there is a place where the ascii sequences for colors and font faces are defined and can be adjusted? Or is there some option to remove the bold face only, but not the colors? systemd.log_color=0 removes all formatting, but I'd like to keep the colors... cu, Frank -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. BioinformatikMail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr. 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: +49 89 2180-99-4049 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *