You can do this already with ln -s /dev/null /etc/motd.d/cockpit, see `man pam_motd`. This will also be mitigated by bug 1872562.

I'll do some experiments wrt. %config and %ghost -- I may have misunderstood what %ghost is for.

Martin,
 thanks for picking this up. Yes, linking to /dev/null would be an option, but as pointed out, rpmverify will then fail for that package.
RHBZ#1772562 makes sense indeed, but maybe even admins don't want to see this message, as cockpit - as in my CU case is only installed as part of a dependency.

So, I'd prefer an option to completely disable the creation of issue/motd snippets.
Given other bug, why not have a configuration option like DisplayMotd={no,root,wheel,...}, same for Issue. Or something like that?

I conducted some experiments to validate my understanding of how rpm works [1][2].

With the current

  %config %{_sysconfdir}/motd.d/cockpit

a package upgrade brings it back:

  rm /etc/motd.d/cockpit
  rpm -U --force --verbose cockpit-ws-*.rpm 
  ls -l /etc/motd.d/cockpit

%config(noreplace) has a better semantics, but still does not (and is not meant to) consider the removal of a config file as a state to retain (that's in contrast to dpkg, which does respect conffile removals):

  %config(noreplace) %{_sysconfdir}/motd.d/cockpit

Without any qualifier, the file would not have any particular configuration status at all, and *any* change to it, even changing to /dev/null would be reverted on upgrade -- that's even worse.

Just "%ghost /etc/motd.d/cockpit" alone does not work, as then the file wouldn't be shipped in the RPM in the first place.

In other words, rpm does not have any mechanics to properly deal with a removed configuration file, and thus it needs to be done manually in %post. I tried that with


--- tools/cockpit.spec
+++ tools/cockpit.spec
@@ -478,7 +478,8 @@ authentication via sssd/FreeIPA.
 %config(noreplace) %{_sysconfdir}/cockpit/ws-certs.d
 %config(noreplace) %{_sysconfdir}/pam.d/cockpit
 %config %{_sysconfdir}/issue.d/cockpit.issue
-%config %{_sysconfdir}/motd.d/cockpit
+# created in %post
+%ghost /etc/motd.d/cockpit
 %ghost /run/cockpit/motd
 %ghost %dir /run/cockpit
 %dir %{_datadir}/cockpit/motd
@@ -516,6 +517,13 @@ getent group cockpit-wsinstance >/dev/null || groupadd -r cockpit-wsinstance
 getent passwd cockpit-wsinstance >/dev/null || useradd -r -g cockpit-wsinstance -d /nonexisting -s /sbin/nologin -c "User for cockpit-ws instances" cockpit-wsinstance
 
 %post ws
+set -x
+if [ "$1" = 1 ]; then
+    # first-time install; if admin removed /etc/motd.d/cockpit, don't bring it back on upgrades
+    mkdir -p /etc/motd.d
+    ln -s /run/cockpit/motd /etc/motd.d/cockpit
+fi
+
 %systemd_post cockpit.socket
 # firewalld only partially picks up changes to its services files without this
 test -f %{_bindir}/firewall-cmd && firewall-cmd --reload --quiet || true
@@ -524,6 +532,9 @@ test -f %{_bindir}/firewall-cmd && firewall-cmd --reload --quiet || true
 %systemd_preun cockpit.socket
 
 %postun ws
+if [ "$1" = 0 ]; then
+    rm -f /etc/motd.d/cockpit
+fi
 %systemd_postun_with_restart cockpit.socket
 %systemd_postun_with_restart cockpit.service

which *almost* works -- but upgrading from the current cockpit-ws version to this new one removes the file. Unfortunately rpm scripts [3] can only tell whether the package is being installed or upgraded, but not which version it is being upgraded from (again unlike dpkg's "$2" argument). So I can't write a %post script that says "create the symlink on fresh install, or when upgrading from version < 227". It could be possible to have a %pre script that sets a flag file somewhere for the %post script to look at, but it starts getting really complicated here..

[1] http://ftp.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html
[2] https://www.cl.cam.ac.uk/~jw35/docs/rpm_config.html
[3] https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_syntax

@Oliver: FTR, another way to disable the motd message without breaking rpm -V is "systemctl mask cockpit-motd".

Martin,
 thanks a lot for carrying out these tests!

I'm not sure I understand your comment #5. If I empty the motd or link it against /dev/null and mask the service, rpmverify will still complain - we'd just make sure it's not recreated, isn't it?

%ghost would, I agree, lead to no file being shipped with the RPM, but what's the issue with that? It would anyway be created if you enable the service (and/or can be created upon install). And upon removal of the package, we could delete the file if it's there in order to not leave it dangling around.

What do you think?

@Oliver: It's not "and", it's "or" -- in a default install, "systemctl mask cockpit-motd" will prevent /run/cockpit/motd from ever getting created, and thus the motd message disappears. No need to fiddle with /etc/motd.d/cockpit then.

%ghost> Right, we'd need to create it upon package install, that's what my %post does above. The issue is with upgrading from the current version, which would unintentionally remove /etc/motd.d/cockpit as well. I have some idea how to fix that, it's just turning the whole thing into quite a state machine.

Hi Martin!

If we do not create /run/cockpit/motd, then we have a dangling symlink in /etc/motd.d - rpmverify will be happy, but (in my case) a red blinking dangling symlink in /etc also looks pretty bad.

So... Cockpit does have a configuration file in /etc/cockpit/cockpit.conf (BTW, we do not ship this in the RPM). Why not have a configuration option there to enable/disable the motd/issue creation? I guess we'll need to address this upstream, but it's probably the best option we have, isn't it?

@Oliver: No, I'm not a big fan of adding another way of configuring that to the two that already exist, it's becoming too confusing then. Kyle and I were pondering a more global way of disabling default distribution motd reminders which would also quiesce Insights and similar things, and would also apply to /etc/issue.d/; that could be a flag file like /etc/motd-disable-os; this still needs some more discussion, though.

For now I'd devote this bug to making rm /etc/motd.d/cockpit work as expected.

Hi Martin!

Thanks for getting back to me on this topic. Let me add the following use-case and I'll leave it to your judgement what the best way is to solve it :-)

* Users (even root/wheel) users, shall not see the banner - as the less-experience users may believe they _have to_ enable the service.
* We want a clean rpm -Va cockpit\* output.

Thanks a lot for considering this!

> Users (even root/wheel) users, shall not see the banner

Hiding the banner to non-admin users is bug 1872562, which is blocked by bug 1861640. Of course the whole point of that thing is to *do* show the message to admins (root/wheel).

Martin,
 the problem here is that you may pull in these packages via some dependencies and *do not* want cockpit to be running. Eg. SAP documentation states to install the @Server group, which pulls in Cockpit, but you really don't want to *run* it on these machines and therefore also don't want to see the information to enable it.

Makes sense?

I sent an upstream PR which fixes that, and adds integration tests for all scenarios I could think of: https://github.com/cockpit-project/cockpit/pull/15784

When I log into our RHEL 8 servers, a message from /etc/motd.d displays:

 Activate the web console with: systemctl enable --now cockpit.socket

Cockpit is already enabled and running.  I know from a similar issue, I can stop this from displaying by linking it to /dev/null.

I would think that whatever checked cockpit and determined it should be enabled should delete this file when it finds that it *is* enabled.

Running Red Hat Enterprise Linux release 8.3 (Ootpa)

Thanks and best regards,

Steve

Fixed in 244, will be packaged for 8.5 in the next days.

Steve: We got this reported quite a few times recently (mostly in Fedora, though). Can you please test on 8.4 beta or CentOS 8 Stream? So far all other reporters mentioned that it is fixed now. If not, please file a separate bugzilla about that, as this bz is about the possibility to rm the file in /etc.

Hi Martin.

I upgraded to 8.4 yesterday. Is 8.5 coming out soon?

I guess it's fix but it seems it was fixed in a weird way:

1. /etc/motd.d/cockpit is linked to /run/cockpit/motd
2. /run/cockpit/motd is then linked to /run/cockpit/active.motd

(In reply to Martin Pitt from comment #17)
> Fixed in 244, will be packaged for 8.5 in the next days.
> 
> Steve: We got this reported quite a few times recently (mostly in Fedora,
> though). Can you please test on 8.4 beta or CentOS 8 Stream? So far all
> other reporters mentioned that it is fixed now. If not, please file a
> separate bugzilla about that, as this bz is about the possibility to rm the
> file in /etc.

Hi Martin.

I upgraded to 8.4 yesterday. Is 8.5 coming out soon?

I guess it's fix but it seems it was fixed in a weird way:

1. /etc/motd.d/cockpit is linked to /run/cockpit/motd
2. /run/cockpit/motd is then linked to /run/cockpit/active.motd

@Steve: 8.5 should come in roughly half a year, the official rhythm now.

The file structure you mention has existed since RHEL 7, this is nothing new. The fix here is that you can "rm /etc/motd.d/cockpit" as an officially supported way of quiescing the message. This didn't work before, as that link would come back with the next package upgrade.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (cockpit bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:4380