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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141231142036.ga16...@tty.gr