Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

common warnings for users #101

Open
dustymabe opened this issue Jun 14, 2021 · 4 comments
Open

common warnings for users #101

dustymabe opened this issue Jun 14, 2021 · 4 comments

Comments

@dustymabe
Copy link
Member

If I want a CLHM helper to warn users about something and wanted to share that warning for all CLHM users what would be the best way to go about implementing it? For example I want to warn users if there hardware clock is significantly out of date but I think it would have broader value than just for Fedora CoreOS.

Here's an example script:

[core@rpi4 ~]$ cat /tmp/foo.sh 
hwclocksse=$(date --utc --date="$(sudo hwclock --utc --get)" +%s)
currentsse=$(date --utc +%s)

date --date="@$hwclocksse"
date --date="@$currentsse"

hours="$(((currentsse-hwclocksse)/3600))"
hours=${hours#-} # absolute value. remove negative sign if it's there

if (( $hours >= 1 )); then
    echo "Detected hardware clock is more than $hours hour(s) out of date."
fi

and related output:

Fri May 28 09:03:11 UTC 2021
Mon Jun 14 19:12:06 UTC 2021
Detected hardware clock is more than 418 hour(s) out of date.

Obviously the output/wording needs fixing up a bit, but what's the best path to implement something like this as part of the files delivered with CLHM.

I'm split between running this as part of profile.sh (runs every time someone logs in) vs a one time boot script (which could get out of date). It also would need to be something someone could silence.

The alternative to including it here is to do something like coreos/fedora-coreos-config#926 and just add a service in FCOS to do the work.

@kelvinfan001
Copy link
Member

kelvinfan001 commented Jun 15, 2021

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.

@dustymabe
Copy link
Member Author

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?

@kelvinfan001
Copy link
Member

kelvinfan001 commented Jun 15, 2021

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.

@dustymabe
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants