> 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?