> 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"? :-)

Highest benefit! That phrase is really awkward in English. 


> 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


Yes, this sounds like the best approach to me. No one else seems to be chiming in to disagree, so let’s move ahead with this. I’ll send a PR for F28 and F29 to drop the /etc/issue from Server on fedora-release shortly. I assume you will bring the issue.d change back to F28’s Cockpit?