motd handling in jessie & beyond
motd handling spans multiple packages (libpam-modules, login, ssh,
base-files, initscripts, systemd) and multiple uncoordinated half-baked
attempts to take it to different directions have left the current state
of affairs a bit of a mess. Steve Langasek (rightfully) suggested on
#764841 to use debian-devel as a venue to discuss this so here goes (but
note that I am not a maintainer of any of the affected packages).
Here's what's currently inconsistent:
- Behavior is different between login & sshd. login has (#741129):
session optional pam_exec.so type=open_session stdout /bin/uname -snrvm
session optional pam_motd.so
but SSH has:
session optional pam_motd.so motd=/run/motd.dynamic
session optional pam_motd.so noupdate
Switching SSH to use pam_exec was refused in #764841, as to not break
existing update-motd.d behavior. (see below)
- Behavior is different between systemd and other init systems.
initscripts ships /etc/init.d/motd whose sole purpose is to execute
uname -snrvm > /var/run/motd.dynamic on boot but systemd ships an
*empty* motd.service file overriding this, presumably for performance
reasons (see [1], where upstream suggested something PAM-based
instead). Under systemd, nothing writes to /run/motd.dynamic.
- pam_motd provides a facility (via a custom patch, brought over by
Ubuntu) that run-parts /etc/update-motd.d. The directory exists in
Ubuntu (along with default scripts that set Ubuntu's motd) but not in
Debian, although https://wiki.debian.org/motd documents it.
Moreover, this is broken in jessie right now (#743286) as pam_motd
writes the run-parts output to (/var)/run/motd but nothing ever reads
that. Ubuntu's pam_motd is patching this to be /run/motd.dynamic which
is in accordance with sshd's pam configuration (and in Ubuntu,
login's).
All of the above result to, on an up-to-date jessie system:
* If you login via SSH you don't get the uname line, but only if you use
systemd. You get the uname line if you login via the console *or* if
you login via SSH but you are using SysV init.
* If you follow wiki's advice and manually create an /etc/update-motd.d
directory, you won't see the motd being altered. The scripts *will*
run on both console and SSH logins (for different reasons), though,
and a /var/run/motd will be created (but not read by anything) leading
to confusion. One can symlink /etc/motd to /var/run/motd and emulate
Ubuntu's behavior, although the uname line will still remain a
discrepancy between the two types of logins that can only be solved by
editing the PAM configuration.
I believe this to be broken behavior. Going forward, my (non-maintainer)
take on this would be that hardcoding the uname call in the PAM config
sounds suboptimal, as is overriding an init script with an empty unit
file. Providing Ubuntu's update-motd.d facility sounds ideal to me since
it's more generic and nicer to the sysadmin and especially since the
hardest part (the pam patch) is already in Debian.
For this to happen, we'll need:
a) login reverting the pam_exec.so change and using pam_motd
/run/motd.dynamic again (like wheezy had and jessie's sshd has).
b) libpam-modules switching the run-parts output location from
/var/run/motd to to /run/motd.dynamic (like Ubuntu)
c) base-files shipping /etc/update-motd.d, plus a script:
00-uname: #!/bin/sh\nuname -snrvm\n
d) (optionally) removing the now-redundant /etc/init.d/motd from
initscripts & the empty motd.service override from systemd.
The changes are in total 2+1+3 lines, plus killing two files, so
relatively simple. On the flip side, this touches five
essential/required packages so it might be a bit too much for jessie's
freeze, although I also wonder if the current state of affairs is okay
to release with.
Opinions?
Regards,
Faidon
1: http://lists.freedesktop.org/archives/systemd-devel/2012-June/005417.html
Reply to: