common warnings for users about console-login-helper-messages HOT 4 OPEN

Perhaps a new service similar to console-login-helper-messages-gensnippet-os-release.service? We use a systemd service that executes a script that writes to the MOTD directories. This will have the information be displayed every time someone logs in (in FCOS, this means every time someone logs in via SSH and console), but at the same time, we can make this easily silence-able (by doing e.g. systemctl disable --now console-login-helper-messages-gensnippet-common-warnings.service. We probably also need to add ExecStop= to the CLHM systemd units that write to /run/motd.d to clean up the snippets that they own from the /run directories so users don't need to reboot for the messages to be silenced the next time they log in.
(But this also means there will be yet another systemd preset users will need to enable when installing/using CLHM, https://github.com/coreos/console-login-helper-messages/blob/main/doc/manual.md#integrating-into-a-distribution is unforunately quite long right now 😅)

While we're at it, would it be a good idea to give the "failed systemd units" warning currently implemented as part of profile.sh the same treatment? Currently, the only way to silence failed systemd units warning is by uninstalling console-login-helper-messages-profile.

Edit: the above solution doesn't make sense for this use case since we want a way for the script to be run every time a user logs in, and still be easily silence-able.

from console-login-helper-messages.

ah, sorry, I misinterpreted the issue. The emphasis here is on running the script more frequently (upon login), instead of displaying frequently.

ehh. I think I wasn't super clear. I think there are two things I'm rolling into this discussion:

• how (where?) do we easily add new warnings/helpers for people that we want to share
  • need to also make it easy to know how to disable the helper/warning
• can we handle the case where the warning/helper needs to run more than once per boot
  • if yes, what's the best way to do that?

So if I'm understanding the problem correctly, what we want to figure out now is a way to have a script be updated/run regularly (e.g. every time a user logs in, like profile.sh), but also be easily silenced. In this case, a systemd timer unit does indeed sound promising.

Yeah a timer might be nice.

from console-login-helper-messages.

I think one thing to think about here is helpers that are sufficient to run once on boot (i.e. the check for cgroups v1 versus v2 needs to only happen once) versus helpers that need to be updated periodically while booted (like systemd failed units check). Not sure if there is an easy way to service that second class without the profile.d bits, but maybe there are clever solutions we could use. Maybe a systemd timer to periodically run them?

from console-login-helper-messages.

ah, sorry, I misinterpreted the issue. The emphasis here is on running the script more frequently (upon login), instead of displaying frequently.
So if I'm understanding the problem correctly, what we want to figure out now is a way to have a script be updated/run regularly (e.g. every time a user logs in, like profile.sh), but also be easily silenced. In this case, a systemd timer unit does indeed sound promising.

from console-login-helper-messages.