On Wed, May 30, 2018 at 9:42 AM Allison Karlitskaya <allison.karlitskaya@redhat.com> wrote:
hi Stephen,

On Wed, May 30, 2018 at 3:17 PM, Stephen Gallagher <sgallagh@redhat.com> wrote:
However, this will require modification of the default configuration on Fedora Server (at minimum) or possibly Fedora in general. Presently, no PAM stack shipped by default on Fedora includes pam_motd.so. I think that the value of having Cockpit information in the MOTD is worthwhile, so we should consider adding it to at least the SSHD PAM stack, so that users who have only remote access to the machines can still be informed of the availability of the Cockpit admin console.

Another approach would be to make it more generally available by adding it to the 'postlogin' PAM stack, which would mean that the MOTD would be seen by anyone logging in via any standard login mechanism. If we did this, we'd assuredly remove the /etc/issue implementation, as it would be redundant. The downside to this is that the default configuration for postlogin is to also run on things like `su` and `sudo -i`, so that could be noisy. We could deak with this by splitting the 'postlogin' stack into one that handled "real" logins (sshd, getty, etc.) and one that handles local privilege escalations (su, sudo, etc.). This would require coordination with the PAM maintainers in Fedora.

The middle-ground approach would be to add pam_motd.so solely to the SSHD PAM stack and then leave /etc/issue to display the console for local purposes. The Cockpit folks can chime in if I've gotten this right, but apparently there's a newer way we can generate the /etc/issue content so that it can now display the hostname as well. So we'd retire the current way we're doing it for IP addresses. The benefit to this approach is that for rack-mounted systems that probably have a common serial interface console (or just a rolling cart monitor), the user can just glance at the login prompt and see that Cockpit is available without requiring them to log in first.

You've characterised the situation fairly accurately.

imho, adding pam_motd for SSH is the reasonable thing to do here.

As for the /etc/issue question, that's rather easy to deal with as well.  /etc/motd.d/cockpit is just a symlink to /run/cockpit/motd (which itself is always a link to the appropriate text to display).  We could just add another link for /etc/issue.d/cockpit, and reuse the same text.  I could add this link to cockpit upstream, if that's what we decide to do.


This is definitely the simplest and least-invasive approach we can take. It probably has the highest cost-benefit ratio as well. I think the noise level is too high for adding it to postlogin and breaking that up into multiple stack snippets seems like an unnecessary amount of work for the benefit. (Sure, it would work for someone who decided to log in via rsh, but do we really want to encourage that?)

Assuming we took this approach, the remaining question is whether we want to do this for Server Edition only, or if we should take this to Fedora as a whole. I personally think that there's no particular need to restrict this to Server Edition; if someone on Workstation or KDE or Atomic decides to have Cockpit active and listening, we should probably inform their users about it. I think we should file a Self-Contained Change Proposal[1] so that FESCo can approve it for general use. I'd be happy to co-own this Change.

[1] https://fedoraproject.org/wiki/Changes/Policy