On Wed, May 30, 2018 at 8:52 AM Allison Karlitskaya <
allison.karlitskaya(a)redhat.com> wrote:
hi,
Cockpit 169 (released today) contains a change to take advantage of the
recently added PAM support for /etc/motd.d to display a helpful note to the
admin about how to start or access cockpit.
The required PAM changes have already landed in Fedora 28.
It seems that the PAM configuration of Fedora 28 (at least in our test
images here) doesn't use pam_motd at all, though.
I'd like to start a discussion about what would be appropriate here. We
want at least a message displayed when people log in to an interactive
session with ssh, but it might also be useful to display a message at the
virtual console, before or after login.
Thoughts?
I had a short conversation about this on IRC with Allison and Martin Pitt
which I'll summarize for the wider discussion, as well as including some
additional thoughts I've had while typing.
The current state on Fedora Server is that we have a specialized version of
/etc/issue that will display something along the lines of:
Admin Console:
https://0.0.0.0:9090/ or https://[::::]:9090/
(with the actual public IP address of the machine there)
Cockpit has recently grown the capability to generate certain files when
the cockpit.socket unit is started, allowing us to have more control over
what messages we want people to see. In particular, Cockpit 169 now has the
ability to generate files in /etc/motd.d that will enable systems that have
pam_motd.so in their PAM session stack to display the Cockpit console
address after the user logs in. These generated files can also insert the
machine's public hostname instead of the simple IP address we have now,
which will play better with SSL Certificates.
Today, the /etc/issue implementation is only seen by people who can see a
console login, either by having a keyboard and monitor attached to the
machine or else via a physical or virtual serial connection. With this new
pam_motd.so implementation, we will be able to inform users about the admin
console who are using other login mechanisms, most notably SSH.
However, this will require modification of the default configuration on
Fedora Server (at minimum) or possibly Fedora in general. Presently, no PAM
stack shipped by default on Fedora includes pam_motd.so. I think that the
value of having Cockpit information in the MOTD is worthwhile, so we should
consider adding it to at least the SSHD PAM stack, so that users who have
only remote access to the machines can still be informed of the
availability of the Cockpit admin console.
Another approach would be to make it more generally available by adding it
to the 'postlogin' PAM stack, which would mean that the MOTD would be seen
by anyone logging in via any standard login mechanism. If we did this, we'd
assuredly remove the /etc/issue implementation, as it would be redundant.
The downside to this is that the default configuration for postlogin is to
also run on things like `su` and `sudo -i`, so that could be noisy. We
could deak with this by splitting the 'postlogin' stack into one that
handled "real" logins (sshd, getty, etc.) and one that handles local
privilege escalations (su, sudo, etc.). This would require coordination
with the PAM maintainers in Fedora.
The middle-ground approach would be to add pam_motd.so solely to the SSHD
PAM stack and then leave /etc/issue to display the console for local
purposes. The Cockpit folks can chime in if I've gotten this right, but
apparently there's a newer way we can generate the /etc/issue content so
that it can now display the hostname as well. So we'd retire the current
way we're doing it for IP addresses. The benefit to this approach is that
for rack-mounted systems that probably have a common serial interface
console (or just a rolling cart monitor), the user can just glance at the
login prompt and see that Cockpit is available without requiring them to
log in first.
I'm looking for us to come to a general consensus on how we present this
information to the user. I'd appreciate any input you might be willing to
provide.
Thank you for reading to the end, I know it was a long one.