[systemd-devel] Unit file for motd (message of the day) (was: Trying systemd with Debian Sid/unstable on ASRock E350M1 with Crucial m4 SSD)

[Josh Triplett]

On Tue, Jun 19, 2012 at 08:04:45PM +0200, Lennart Poettering wrote:
> On Sun, 10.06.12 14:40, Paul Menzel (paulepanter at users.sourceforge.net) wrote:
> >           [ Roger Leigh ]
> >           * initscripts:
> >             - Don't generate or touch /etc/motd.  Instead, the dynamic part of
> >               /etc/motd is created as /run/motd.dynamic, leaving /etc/motd
> >               entirely under the control of the system administrator.  If
> >               /etc/motd is a symlink to /run/motd, /etc/motd.tail is moved
> >               back to /etc/motd.  Closes: #353229, #624391, #668307.  /etc/motd
> >               is not removed if initscripts is purged, since it's not owned by
> >               initscripts.
> >             - By default, /run/motd is just the output of uname, preserving the
> >               existing behaviour.  However, should the administrator wish to
> >               include dynamic information in the motd, they may write scripts
> >               to update /run/motd.dynamic as they please.  Closes: #437176.
> 
> Yikes, baroque.

Incremental improvement over the previous state, though.  I worked with
Roger Leigh to improve the current state of affairs here; the above
represents a compatible change possible without patches to PAM, since I
haven't yet gotten the necessary patches into PAM.  The previous
behavior had /etc/motd as a symlink to a dynamically generated motd that
included the admin's motd from /etc/motd.tail.  The new behavior leaves
/etc/motd as a normal file under admin control, and just generates a
separate /run/motd.dynamic shown via a separate pam_motd:

~$ grep pam_motd /etc/pam.d/login
session    optional   pam_motd.so  motd=/run/motd.dynamic
session    optional   pam_motd.so

I agree that this hasn't yet reached an optimal state, but it does
improve on the previous approach.

> Honestly I always found that this mangling of motd in Debian is
> quite confused. /etc should be considered read-only. Always writing
> to the root fs just because you boot the machine is a really bad idea.

This does not write to /etc at all, nor does it have a confusing symlink
from /etc; it writes to /run/motd.dynamic, and configures pam_motd to
read the dynamic motd directly from there.

> if the Debian folks really want to show the uname next to motd, then
> they should stop mucking with /etc/motd and instead hack pam_motd to
> simply optionally show the uname next to /etc/motd. That way it is
> guaranteed to be fully up-to-date, doesn't result in writing IO, is
> compatible with read-only root, and generally more robust and elegant.

I've actually written a PAM patch to fix this problem, in a slightly
more general way: I patched pam_exec to support displaying the output of
the exec'd command, which would allow an arbitrary dynamic motd.  As a
result, you can achieve the exact behavior of Debian's dynamic motd with
the following pam configuration:

session optional pam_exec.so type=open_session stdout /bin/uname -snrvm

See http://bugs.debian.org/670147 .  Debian's PAM maintainer doesn't
plan to include the patch unless PAM upstream does.  I've submitted the
patch to upstream PAM, but haven't managed to get any response yet.

As soon as that patch or something like it makes it into PAM, the PAM
scripts for login and similar services can switch to pam_exec, and
Debian's sysvinit can get rid of /etc/init.d/motd.

- Josh Triplett