coreos / console-login-helper-messages Goto Github PK
View Code? Open in Web Editor NEWA set of scripts to show helpful system information to the login terminal.
License: BSD 3-Clause "New" or "Revised" License
A set of scripts to show helpful system information to the login terminal.
License: BSD 3-Clause "New" or "Revised" License
Fedora CoreOS
Warn if the SELinux policy has been modified from the default and might thus be outdated after an update.
Frequent source of SELinux denials / errors for users.
To figure out if the policy has been modified, we can use:
$ sudo ostree admin config-diff | grep selinux
...
Following #45, #7, #60, it would be helpful to provide a single command that the user can run to check the user's configuration of PAM, agetty
, SELinux, etc. and then prompt the user on whether they would like to make changes to those configurations to allow CLHM to make full use of upstream functionality.
While porting this to RHEL8 I noticed following, briefly:
issuegen runs even when disabled
# systemctl is-enabled console-login-helper-messages-issuegen
disabled
but
# ls -la /run/console-login-helper-messages/40_console-login-helper-messages.issue
-rw-r--r--. 1 root root 255 14. Mai 21:47 /run/console-login-helper-messages/40_console-login-helper-messages.issue
because
/usr/lib/udev/rules.d/90-console-login-helper-messages-issuegen.rules
passes the systemd state.
So,
/usr/libexec/console-login-helper-messages/issuegen
should check "is-enabled" or is executed manually via systemctl start.
Explain how the components of this package source information, and what the package relies on to have the messages displayed.
There are several parameters which would be useful to enable configuring for each piece of information that the issuegen, motdgen, and profile scripts display.
The information which would have the configuration options:
This includes:
If there is a separate config file for each of the information above, one format could look like:
# /usr/lib/console-login-helper-messages/udev_if_snippetgen.conf
ISSUE_OUTPUT_DIR=/run/console-login-helper-messages/issue.d
ISSUE_ENABLE=true
# Example if we wanted to generate network interface information from udev to motd
# as well as issue, and we wanted to drop the snippet in the "public" run/motd.d directory.
MOTD_OUTPUT_DIR=/run/motd.d
MOTD_ENABLE=true
A script called something like udev_if_snippetgen
would be invoked by a udev rule (could be a systemd service or other, for other types of information). This script would source the above config file and look for each variable named *_OUTPUT_DIR
and place a copy of the snippet in each of these files. In order to separate the scripts like this, this would likely require re-architecting issuegen
to be a service that has an associated .path
systemd unit, which triggers issuegen
upon snippets being created in /run/console-login-helper-messages/issue.d
(started in #43).
Prior to rearchitecting issuegen
, the current issuegen
could also work with the above config file by sourcing /usr/lib/console-login-helper-messages/udev_if_snippetgen.conf
and look for ISSUE_OUTPUT_DIR
to output the udev interface snippets to. If this variable is unset, then the path would be set to a default path (possibly chosen after checking the util-linux
version on the system). Similar can be done for motdgen
.
This setup does sound quite complicated for scripts that are sourcing simple pieces of information, but long term it'd ease development to have each type of information interface with issuegen
, motdgen
, and the profile.sh
script in a common way - that way support for new types of information (e.g. #34) could be added without modifying the issuegen
, etc. scripts. (E.g. the purpose of issuegen/motdgen/profile could be to only look for snippets that land in its input snippet directory /run/console-login-helper-messages/issue.d
, in #43 ). It would also mean that issuegen
doesn't operate on all the information it displays, if only one is modified (e.g. right now issuegen
will regenerate the SSH key snippet, if a udev rule for the network interfaces was invoked).
That'd mean when packaging this, the default types of information (SSH keys, udev interfaces, etc) could be included in an optional subpackage like console-login-helper-messages-defaults
, and users could further configure it if they wanted to turn off some of the defaults. issuegen
, motdgen
, etc. could still be used by custom snippet generators if the users wanted to. (Currently there hasn't been mention of a need for this, but it seems useful to have).
Currently, issuegen
will only regenerate the issue snippet (/run/console-login-helper-messages/40_console-login-helper-messages.issue
) upon new info being added to display (e.g. by https://github.com/coreos/console-login-helper-messages/blob/master/usr/lib/udev/rules.d/90-console-login-helper-messages-issuegen.rules), but the changes won't be reflected in currently open serial (agetty) consoles, only when opening a new agetty
console. This could cause problems e.g. if a network interface changed and got a new IP address during the time the console was left open.
This should be fixed by having issuegen
do agetty --reload
at the end of the script.
(brought up in https://bugzilla.redhat.com/show_bug.cgi?id=1846169)
Latest console-login-helper-messages-0.21.2-3.fc36 build triggers test failures in fedora-ci.koji-build.rpminspect.static-analysis for /usr/libexec/console-login-helper-messages/gensnippet_if_udev: https://bodhi.fedoraproject.org/updates/FEDORA-2021-26e7a4489d
Error Message
Test "/shellsyntax" failed.
Find out more about this test in the documentation: https://github.com/rpminspect/rpminspect#rpminspect
Found a bug? Please open an issue in the issue tracker: https://pagure.io/fedora-ci/general/issues
Standard Output
rpminspect version: 1.9-0.1.202112021505git.fc36 (with data package: 1.8)
rpminspect profile: rawhide
new build: console-login-helper-messages-0.21.2-3.fc36
old build: console-login-helper-messages-0.21.2-2.fc35 (found in f36-updates koji tag)
Test description:
For all shell scripts in the build, perform a syntax check on it using the shell defined in its #! line (shell must also be listed in shell section of the configuration data). If the syntax check returns non-zero, report it to the user and return a combined stdout and stderr. If comparing two builds, perform the previous check but also report if a previously bad script is now passing the syntax check.
======================================== Test Output ========================================
shellsyntax:
------------
1) /usr/libexec/console-login-helper-messages/gensnippet_if_udev is not a valid bash script on noarch
Result: BAD
Waiver Authorization: Anyone
Details:
/var/tmp/rpminspect/console-login-helper-messages-0.21.2.BaRMNc/after/noarch/console-login-helper-messages-issuegen-0.21.2-3.fc36.noarch//usr/libexec/console-login-helper-messages/gensnippet_if_udev: line 27: syntax error near unexpected token `|'
/var/tmp/rpminspect/console-login-helper-messages-0.21.2.BaRMNc/after/noarch/console-login-helper-messages-issuegen-0.21.2-3.fc36.noarch//usr/libexec/console-login-helper-messages/gensnippet_if_udev: line 27: ` | write_via_tempfile ${outfile}'
Suggested Remedy:
The referenced shell script is invalid. Consider debugging it with the '-n' option on the shell to find and fix the problem.
Should describe what the the package does and what the user can do with the package.
Brief instructions (to the effect of "run this script") on building and testing the changes manually.
Once CI is set up, the instructions to test manually will be replaced with instructions to run the CI process (#5 ).
On RHCOS nodes we sometimes see this systemd unit in a failed state:
systemd[1]: Starting Generate /run/issue.d/console-login-helper-messages.issue...
issuegen[984000]: cat: /run/console-login-helper-messages/40_console-login-helper-messages.issue.staged: No such file or directory
systemd[1]: console-login-helper-messages-issuegen.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: console-login-helper-messages-issuegen.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Generate /run/issue.d/console-login-helper-messages.issue.
systemd[1]: console-login-helper-messages-issuegen.service: Consumed 20ms CPU time
This might be due to a race between two invocations, one from /usr/lib/udev/rules.d/90-console-login-helper-messages-issuegen.rules
and one from /usr/lib/systemd/system/console-login-helper-messages-issuegen.service
, but I do not see any logs from udev so I cannot know for sure.
sudo bash -c 'while systemctl restart console-login-helper-messages-issuegen.service; do systemctl reset-failed console-login-helper-messages-issuegen.service; done'
sudo bash -c 'while /usr/libexec/console-login-helper-messages/issuegen remove f; do true; done'
See: coreos/fedora-coreos-tracker#1232
Add a warning if we find that /sysroot is not read only.
If I set up a bond or a teaming interface it would be nice to be able to see that information on the serial console of the machine. So for example I have an interface team0
set up via teaming but on the serial console I see:
Red Hat Enterprise Linux CoreOS 44.81.202003090830-0 (Ootpa) 4.4
SSH host key: SHA256:zEvF/82ozWT4o6nbeC6KKxX7pyjmSGsXIhCw2eeU3og (ECDSA)
SSH host key: SHA256:OCWlL6jAXCcGPzsyXSQ+jsJ8GNhUdZsNMgygZooWGck (ED25519)
SSH host key: SHA256:npHt7nbvXg9zPabiFKwC5iN8n7G7vzp5sWwjOcsXJi8 (RSA)
ens2:
ens3:
localhost login:
where I should probably see something like:
Red Hat Enterprise Linux CoreOS 44.81.202003090830-0 (Ootpa) 4.4
SSH host key: SHA256:zEvF/82ozWT4o6nbeC6KKxX7pyjmSGsXIhCw2eeU3og (ECDSA)
SSH host key: SHA256:OCWlL6jAXCcGPzsyXSQ+jsJ8GNhUdZsNMgygZooWGck (ED25519)
SSH host key: SHA256:npHt7nbvXg9zPabiFKwC5iN8n7G7vzp5sWwjOcsXJi8 (RSA)
team0: 192.168.122.197
localhost login:
For more on teaming see: https://dustymabe.com/2020/03/05/network-teaming-using-networkmanager-keyfiles-on-fedora-coreos/
Decide whether to do this in profile or motd.
This will prevent the installed symlink (currently /etc/motd.d/console-login-helper-messages.motd -> /run/console-login-helper-messages/console-login-helper-messages.motd
) being broken before the message in /run
is generated by the console-login-helper-messages-motdgen.service
unit.
I spun up an OCP 4.6 cluster in libvirt and noticed that the service had failed; I think the problem is our .path
unit is triggering too often.
sh-4.4# systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● console-login-helper-messages-issuegen.service loaded failed failed Generate console-login-helper-messages issue snippet
...
sh-4.4# systemctl status console-login-helper-messages-issuegen.service
● console-login-helper-messages-issuegen.service - Generate console-login-helper-messages issue snippet
Loaded: loaded (/usr/lib/systemd/system/console-login-helper-messages-issuegen.service; enabled; vendor preset: enabled)
Active: failed (Result: start-limit-hit) since Wed 2020-11-04 22:37:42 UTC; 12min ago
Docs: https://github.com/coreos/console-login-helper-messages
Process: 1754 ExecStart=/usr/libexec/console-login-helper-messages/issuegen (code=exited, status=0/SUCCESS)
Main PID: 1754 (code=exited, status=0/SUCCESS)
CPU: 9ms
Nov 04 22:37:42 localhost.localdomain systemd[1]: Starting Generate console-login-helper-messages issue snippet...
Nov 04 22:37:42 localhost.localdomain systemd[1]: Started Generate console-login-helper-messages issue snippet.
Nov 04 22:37:42 localhost.localdomain systemd[1]: console-login-helper-messages-issuegen.service: Consumed 9ms CPU time
Nov 04 22:37:42 localhost.localdomain systemd[1]: console-login-helper-messages-issuegen.service: Start request repeated too quickly.
Nov 04 22:37:42 localhost.localdomain systemd[1]: console-login-helper-messages-issuegen.service: Failed with result 'start-limit-hit'.
Nov 04 22:37:42 localhost.localdomain systemd[1]: Failed to start Generate console-login-helper-messages issue snippet.
Nov 04 22:37:42 localhost.localdomain systemd[1]: console-login-helper-messages-issuegen.service: Start request repeated too quickly.
Nov 04 22:37:42 localhost.localdomain systemd[1]: console-login-helper-messages-issuegen.service: Failed with result 'start-limit-hit'.
Nov 04 22:37:42 localhost.localdomain systemd[1]: Failed to start Generate console-login-helper-messages issue snippet.
One simple fix might be a sleep 1
in the service at the end; we don't need to regenerate more than once a second. But we should also probably adjust the start limits per the bootupd PR above.
Starting from pam 1.4.0-6
, pam_motd
filters motd by user and group. MOTD snippets generated by console-login-helper-messages
are allowed to be read by root only. We should change ownership to be able to be read by all users since we would like to display this information to everyone.
Fedora CoreOS
Add a message to inform the admin when Zincati / rpm-ostree is failing to apply updates to the system. This usually happens if there are packages layered and conflicts arise.
#57 will introduce separate units such as console-login-helper-messages-gensippet-os-release.service
for sourcing information and writing out a MOTD snippet including the information, to be displayed at SSH login. The script this service runs, gensnippet_os_release
, specifies an output directory, which is not exposed outside of the script. After some time, once necessary pieces in PAM and SELinux land in RHEL, services like this should be switched to just write a snippet within /run/motd.d
rather than /run/console-login-helper-messages/motd.d/
.
Alternatively, make the output directory configurable (e.g. through an Environment=
var through the service unit). In Fedora 32+, all the needed bits in external packages are in place to use /run/motd.d
(as root user). However, there isn't any major issue with going through /run/console-login-helper-messages/motd.d/
for now - waiting is still fine.
(Additionally once the upstream bits land in RHEL, the RHCOS manifest should be updated include console-login-helper-messages-motdgen
like FCOS does.)
Related: #7
On FCOS F33, after login, the names of the failed systemd units are not shown properly:
[core@cosa-devsh system]$ bash
[systemd]
Failed Units: 3
●
●
●
This adds printing information on the system (current version, whether updates are available) from yum
and rpm
.
This information should be printed only if its descendent package manager is not available from the command line. That is, information from yum
only gets printed if dnf
is not available, and information from rpm
is printed only if yum
and dnf
are not available as commands.
Adding this would allow motdgen
to display information for CentOS7, and any earlier versions of Fedora and CentOS that have only rpm
or yum
available.
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.
This involves adding automake to the project and anything else that automake needs to be supported.
This is useful for things like build macros, which are enclosed with @
throughout source files (see an example in Cockpit. Having macros for directories, source file paths and names would ensure the source files and the specfile are in sync. It also means the package name can easily be changed with minimal manual changes.
Automated testing by installing the console-login-helper-messages*
packages on a vanilla {Fedora/Atomic/CentOS}
system, starting the systemd units, and checking that the expected output is produced at login (by sshd
for motd, agetty
for issue, and by the bash terminal for profile
) would save time manual testing this.
A build of the RPMs, an install, and a test run should trigger once when a PR is opened.
Users should be able to turn on/off showing the components listed under https://github.com/rfairley/console-login-helper-messages#usage. Discuss how this might happen.
Possibly just split each component into its own individual unit and have it generate to motd or issue or both.
Currently, the default in Fedora is to have agetty
search /etc/issue.d/
for issue files to display before login at the serial console.
issuegen
generates an issue at runtime, and places the generated file in /run/issue.d/
. To have agetty
display this, a symlink from /etc/issue.d/
to /run/issue.d/
is needed.
It would be preferable not to need a symlink, and instead have agetty
search /run/issue.d/
by default (in addition to /etc/issue.d/
. This requires changing upstream code that will go into Fedora. SELinux policy changes may be needed as well to allow agetty
to read other directories (related).
The change would implement near equivalent functionality of a similar change in pam_motd.
Alternatively, the pam_issue
module could be modified to support a list of issue paths, and have the Fedora default way of displaying issue
files changed from agetty
to a service that uses pam_issue
. But changing the Fedora default is a lot more significant than the first option, and unlikely to be adopted just for the console-login-helper-messages
package.
try out the package, and find out why this is happening
watch the private paths e.g. /run/console-login-helper-messages/motd.d
for new messages dropped in, and regenerate the motd
probably use a systemd unit
The motd messages generated by looking at output from rpm-ostree/dnf are only updated when motdgen.service
runs at startup. These messages should be updated as soon as an update is available. This might mean something like update the motd message if a file is written somewhere once an update comes in (motdgen.path
would trigger the motd to regenerate).
Consider using restorecon instead of mv -Z in /usr/lib/console-login-helper-messages/libutil.sh. It is not actually a bug report, but rather a change request. It turns out using mv -Z requires a lot of SELinux rules to access the policy database, whereas using plain mv/cp and subsequently restorecon needs less rules.
Fedora 36+
console-login-helper-messages-issuegen-0.21.2-4.fc36.noarch
No AVC denials audited
AVC denials audited
activate the 90-console-login-helper-messages-gensnippet_if nm-dispatcher plugin
This would involve:
.deb
for package managers such as apt
and apt-get
Currently if you put a file in:
/run/console-login-helper-messages/motd.d/30_foo.motd
/etc/console-login-helper-messages/motd.d/30_foo.motd
Then the contents of both files will get printed. Basically we don't allow for things to be overridden or canceled out, we just include it all.
This will probably be solved when we move to the native implementations of motd.d (#60) and issue.d (#7).
See https://bugzilla.redhat.com/show_bug.cgi?id=2120544 and https://src.fedoraproject.org/rpms/console-login-helper-messages/pull-request/12.
Some distributions already ship the following tmpfiles.d config:
d /run/motd.d - - - - -
Thus leading to noise in the journal:
/usr/lib/tmpfiles.d/setup.conf:2: Duplicate line for path "/run/motd.d", ignoring.
So we need to add a condition or another target to the Makefile to install that optionally.
Use PRETTY_NAME
instead of composing a name from NAME
and VERSION
when generating the 21_os_release.motd
file, since PRETTY_NAME
is designed to be displayed to the user.
Relevant part of the code: https://github.com/rfairley/console-login-helper-messages/blob/24ab329cef042f0bf196cdd1b6d78707c6f5727d/usr/libexec/console-login-helper-messages/motdgen#L28
Related: coreos/fedora-coreos-tracker#245
Make a new release to include latest fixes from #103 and push RPM packages update.
See coreos/fedora-coreos-config#32 (comment)
Needs adding to {%name}-motdgen.service
and {%name}-issuegen.service
files.
The specfile should include checks preceded by the macro %check
to make sure the package has installed properly. This includes checking that files exist where they should, symlinks are produced correctly and not dangling, ...
Currently, the udev rule will only respond to events from interfaces with names matching the glob e*
, e.g. eth0
. It's possible for other interfaces with names of other patterns to exist, we should be more flexible. E.g. for custom names: #43 (comment)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.