[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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,
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.



1: http://lists.freedesktop.org/archives/systemd-devel/2012-June/005417.html

Reply to: