Hello Stephen,
Stephen Gallagher [2018-05-30 9:49 -0400]:
> imho, adding pam_motd for SSH is the reasonable thing to do
here.
Considering the alternatives, I agree. That plus dropping the Fedora Server
specific /etc/issue, and using /etc/issue.d/cockpit instead.
> 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 hope you mean "lowest"? :-)
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.
Agreed. Conversely, if someone uninstalls cockpit, they should no longer see
this message. This is why a static /etc/issue is quite bad, aside from the
usability problems [1].
[1] showing long IP numbers really isn't helpful on a console, where you don't
even have copy&paste - and they are not what humans use to identify a
machine, that's why we invented names and DNS
Summarizing the proposal:
* Drop the Fedora Server specific /etc/issue
* Land
https://github.com/cockpit-project/cockpit/pull/9274 to provide a
dynamic issue.d/ replacement for the above
* Add pam_motd to /etc/pam.d/sshd
Thanks!
Martin