On Wed, May 30, 2018 at 9:42 AM Allison Karlitskaya <
allison.karlitskaya(a)redhat.com> wrote:
hi Stephen,
On Wed, May 30, 2018 at 3:17 PM, Stephen Gallagher <sgallagh(a)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