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)

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, ...

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.

xref: https://bugzilla.redhat.com/show_bug.cgi?id=1861640

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
  ●
  ●
  ●

Feature Request

Environment

Fedora CoreOS

Desired Feature

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.

Other Information

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:

• SSH keys (currently in issuegen)
• network interfaces from udev (currently in issuegen)
• OS release (currently in motdgen)
• failed systemd units (currently in profile)

This includes:

• output path to generate snippets to (need for this in #7)
• whether to output to issue, motd, or profile, or other (in case there is another way of outputting messages we would like to support), or none at all (#15)
• on/off switch for outputting of each piece of information (#15)

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).

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 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/

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

• documentation in README.md (#8, #9, #10)
• build has been done in copr and tested on:
  • Fedora Cloud Base {28, 29, 30}
  • Fedora Atomic Host {28, 29, 30}
  • Fedora CoreOS
• license is added, and attributions given
• upload .tar.gz of source code on GitHub

Bug

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

Full log at: https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/rpminspect-pipeline/job/master/61657/testReport/(root)/tests/_shellsyntax/

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.

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.

See coreos/fedora-coreos-config#32 (comment)

Needs adding to {%name}-motdgen.service and {%name}-issuegen.service files.

Bug

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.

Operating System Version

Fedora 36+

CLHM Version

console-login-helper-messages-issuegen-0.21.2-4.fc36.noarch

Environment

Expected Behavior

No AVC denials audited

Actual Behavior

AVC denials audited

Reproduction Steps

activate the 90-console-login-helper-messages-gensnippet_if nm-dispatcher plugin

Other Information

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.

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.

Should describe what the the package does and what the user can do with the package.

• list of the login messages displayed and when, and how the info is sourced (at a high level)
• the locations where the user may drop files to be displayed
• how the default behaviour of the package may be changed/overridden/suppressed

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).

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 ).

Explain how the components of this package source information, and what the package relies on to have the messages displayed.

• explain motd, issue, profile separately
  • include upstream functionality relied on
  • mention udev, systemd-tmpfiles, systemd pathchanged

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.

try out the package, and find out why this is happening

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.

Shades of https://github.com/coreos/bootupd/blob/3e62c9db9dc06bfb0acacdf1e862b28d84d7d8fa/systemd/bootupd.service#L7

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.

Make a new release to include latest fixes from #103 and push RPM packages update.

This would involve:

• packaging as a .deb for package managers such as apt and apt-get
• check how login information (before and at login) is displayed (PAM/sshd/agetty?)
• can the same mechanism using systemd service units be used?
• SELinux and other upstream changes needed?

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.

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

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.

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.

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).

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)

See: coreos/fedora-coreos-tracker#1232

Add a warning if we find that /sysroot is not read only.

Decide whether to do this in profile or motd.

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.

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.

Reproducer

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'

Feature Request

Environment

Fedora CoreOS

Desired Feature

Warn if the SELinux policy has been modified from the default and might thus be outdated after an update.

Other Information

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
...

#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