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?