Description of problem: cockpit is polluting the MOTD when disabled Version-Release number of selected component (if applicable): cockpit-ws-178-1.fc28.x86_64 Steps to Reproduce: 1. Install the Server compose of Fedora 2. disable unnecessary services: systemctl disable cockpit.socket Actual results: Noise in MOTD: $ ssh host Activate the web console with: systemctl enable --now cockpit.socket Last login: Fri Sep 28 09:56:14 2018 from 192.168.0.24 [jtomko@host ~]$ # dnf erase cockpit-ws Expected results: The cockpit service accepts its fate and quietly waits for reactivation.
Does removing the cockpit and cockpit-ws packages remove the message from motd?
Yes, after removing cockpit-ws the message disappeared, even with other cockpit packages installed: # rpm -qa | grep cockpit cockpit-bridge-178-1.fc28.x86_64 cockpit-networkmanager-178-1.fc28.noarch cockpit-system-178-1.fc28.noarch cockpit-storaged-178-1.fc28.noarch
Seems like removing the package removes all traces of cockpit in motd. Not sure what the problem is ... But I'll leave the final call to Martin Pitt.
This is actually working exactly as designed. As cockpit.socket is not enabled by default (as per Fedora policy), we want to point out to sysadmins how to enable it. Once cockpit.socket gets started, the motd message is replaced with something like "Web console: https://...". If you don't want this message, remove /etc/motd.d/cockpit. Note that in previous Fedoras, we had a similar (but much worse) message in /etc/issue. See bug 1591389. This mechanism is dynamic and much more useful. So this is a question whether we want this feature, not whether it's buggy.
(In reply to Martin Pitt from comment #4) > So this is a question whether we want this feature, not whether it's buggy. It's just an opinion, but I was quite surprised when I saw this message as well. I think it sets a bad precedent, because the approach does not scale. There are many software components, and many of them require a specific step to activate or configure. Just imagine if every single other component that can be activated with systemd did the same thing. On my Fedora 28 system, right now, that would be 54 packages talking through motd. This is why I'm saying it does not scale. What about simply emitting the message at installation time? It makes sense then: "you just installed package X, it's not active by default, activate it with this command". That scales well to as many packages as we want. And it's talking to the right person, i.e. the person who just did the installation.
Installation time is not a good idea as this could be hidden if installed by a graphical interface (gnome software), or if using a automated installation tool. And this doesn't scale better if you install several packages at once, and it do get annoying because you just get popup that you may not care about when you reinstall a system. Personally, I do like the "distraction free" nature of rpm package as they are packaged right now by Fedora.
(In reply to Michael Scherer from comment #6) > Installation time is not a good idea as this could be hidden if installed by > a graphical interface (gnome software), or if using a automated installation > tool. Someone using such graphical tools is also not going to see the MOTD. > And this doesn't scale better if you install several packages at once, and > it do get annoying because you just get popup that you may not care about > when you reinstall a system. Personally, I do like the "distraction free" > nature of rpm package as they are packaged right now by Fedora. I was not suggesting pop-ups. Homebrew on macOS has this notion of installation messages, and they all show at the end of a multi-package installation. I don't know if rpm has a similar feature, but if not, that might be useful.
Removing (or commenting out) the pam_motd.so module from /etc/pam.d/sshd is one method to stop the messages.
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
The same still happens on Fedora 30. Updating version to avoid end-of-life close.
This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '30'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 30 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
'cockpit-217-1.fc32.x86_64' still adds the message.
Even more annoyingly, this message doesn't go away even if you DO activate it system-wide.
Would be great to have a config-option to enable/disable this behaviour of cockpit-ws. The solution described in pam_motd(8) fits best for me: ln -sfn /dev/null /etc/motd.d/cockpit ln -sfn /dev/null /etc/issue.d/cockpit.issue So package-update won't bring the original links back
Another method is `systemctl mask cockpit-motd`.
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle. Changing version to 35.
This message is a reminder that Fedora Linux 35 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '35'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 35 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
(In reply to Michael S. from comment #6) > Installation time is not a good idea as this could be hidden if installed by > a graphical interface (gnome software), or if using a automated installation > tool. > > And this doesn't scale better if you install several packages at once, and > it do get annoying because you just get popup that you may not care about > when you reinstall a system. Personally, I do like the "distraction free" > nature of rpm package as they are packaged right now by Fedora. (A few releases later) Since then, I noticed that Homebrew does have installation-time messages, which are collectively displayed after you install a series of packages. So the approach has been shown to work and scale relatively well.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle. Changing version to 38.
Good Advice from Christophe: Christophe de Dinechin 2018-10-10 15:54:36 UTC There are many software components, and many of them require a specific step to activate or configure. Just imagine if every single other component that can be activated with systemd did the same thing. On my Fedora 28 system, right now, that would be 54 packages talking through motd. This is why I'm saying it does not scale. What does Red Hat do? The opposite, as usual.
This message is a reminder that Fedora Linux 38 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 38 on 2024-05-21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '38'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 38 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Still reproduces: $ ssh localhost Activate the web console with: systemctl enable --now cockpit.socket Last login: Tue Apr 30 16:14:57 2024 from fde6:1546:a01c::9e3 $ rpm -q cockpit-ws cockpit-ws-316-1.fc40.x86_64
I finally want to do something about that. Proposal sent to Fedora server mailing list [1] but also copying here: The original reasons for introducing these messages predate me, but I suppose back then Cockpit was "new" and "important" (especially for RHEL) and needed some more advertising. But I agree with the "clutter" and "does not scale" points here. My preference would be to keep the /etc/issue.d snippet, so that you can see it in the console (also for VMs). But drop the motd one -- when I ssh into a machine, I don't need to be told about Cockpit, and it's also a bit too annoying. [2] lays some preparatory groundwork for that, but doesn't change behaviour yet. [1] https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject.org/thread/OBGW2T3BR75L3DE3XNHVYERJR3CYRCYI/ [2] https://github.com/cockpit-project/cockpit/pull/21398
Discussion on the server ML shows that most people actually prefer the status quo. We support removing /etc/motd.d/cockpit and/or /etc/issue.d/cockpit.issue, which provides obvious enough configurability if it gets in the way.
Can you link to this discussion? I really dislike this behaviour of polluting motd, and cockpit is always the first thing I remove when installing Fedora to try to stop it.
Richard: I did in comment 25. Seems the server is down at the moment, but it worked a few days ago. https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject.org/thread/OBGW2T3BR75L3DE3XNHVYERJR3CYRCYI/ Note: I don't have a strong opinion here. This predated me, and I'm mostly listening to feedback.