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.

Allison