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