[Pkg-shadow-devel] Bug#764841: please use pam_exec to display "dynamic" motd
vorlon at debian.org
Sun Oct 12 21:39:31 UTC 2014
On Sun, Oct 12, 2014 at 09:50:14PM +0200, Michael Biebl wrote:
> > > Please consider doing the same in openssh-server's pam configuration.
> > Doesn't the motd stuff do considerably more than just uname? On my
> > Ubuntu system it says:
> > Welcome to Ubuntu Utopic Unicorn (development branch) (GNU/Linux 3.16.0-17-generic x86_64)
> > * Documentation: https://help.ubuntu.com/
> > 485 packages can be updated.
> > 0 updates are security updates.
> > *** System restart required ***
> > So I think I need to find a way to avoid regressing that.
> Since you still keep the pam_motd line, the worst that can happen
> afaics, is that on Ubuntu the uname information would be printed twice
> (if you don't want to have delta)
> Or what kind of regression did you have in mind?
/etc/pam.d/sshd on Ubuntu does the following:
session optional pam_motd.so motd=/run/motd.dynamic
session optional pam_motd.so noupdate
Calling 'pam_exec uname' on Debian would not be a regression. It is,
however, the wrong way to go about this. /etc/init.d/motd's writing to
/run/motd.dynamic was itself something that Roger implemented in Debian
despite the fact that update-motd support was already present in pam_motd in
Debian, for purposes of supporting much more dynamic information than just
the uname. I can't entirely blame him, since I didn't exactly advertise
update-motd heavily in Debian or push for it; nevertheless, I think this is
part of a very bad pattern of people implementing changes to base interfaces
in Debian without any kind of central coordination with the project (i.e.,
debian-devel). The bugs being filed to ask maintainers to pam_exec uname
are a further example of this pattern.
> Bringing Steve into the loop here, as PAM maintainer:
> Quoting IRC:
> <vorlon> mbiebl: I believe we should use /etc/update-motd.d for this,
> yes. In principle I think it's also fine to do this via pam_exec, but
> update-motd needs to be externalized as a script first.
> As for jessie, I don't know how much effort it would be to switch to the
> update-motd mechanism and also update the login package accordingly.
To use update-motd in Debian, there's one missing piece from Ubuntu, which
is adding /etc/update-motd.d/00-header to populate the uname information.
In Ubuntu, this is part of the base-files package, which I think is a
reasonable place for it to live in Debian as well.
With that done, it would be fairly straightforward to have the login and ssh
packages using pam_motd in Debian for jessie.
I'll mention one caveat, which is that in some cases dynamic pam_motd
presents usability problems. However, the problematic scripts in Ubuntu
belonged to packages such as update-notifier and
ubuntu-release-upgrader-core, which are not likely to be installed on the
kind of Debian system where one cares about console login time, so this may
A complete solution to this bug consists of:
- externalizing the update-motd handling out of pam_motd to an update-motd
- having login and ssh call pam_exec update-motd
- calling update-motd *on boot* to pre-cache the results so that first
login after boot isn't unnecessarily slow
- dropping the pam_motd patches after a suitable transition
> Steve, do you think it's too late to do that for jessie? What would you
I don't think it's too late for jessie. It should be discussed on
debian-devel, so that we can all get on the same page, and it needs
agreement from the relevant maintainer about who should ship
/etc/update-motd.d/00-header (whether it's base-files, or something else).
> We did mask the motd init script in systemd after we were told that the
> login package was updated to no longer require it and we weren't aware
> that there were other users of that motd.dynamic file.
I assume you were told that by Josh, who filed bug #735521 and bug #741129
without ever talking to the pam maintainer about this change.
> We can certainly revert this change again for jessie, if you think the
> uname information for ssh logins is important enough.
> That said, if this can be avoided and we find an agreeable solution for
> everyone which doesn't involved generating a motd.dynamic file, then I'd
> certainly prefer that.
I think the change in systemd absolutely should be reverted. Regardless of
the implementation that is ultimately agreed, the systemd package has no
business overriding the initscripts package. *If* /etc/init.d/motd is to be
dropped it should be dropped at the source, *not* by an override in systemd
that results in inconsistent boot time behavior between different init
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek at ubuntu.com vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: Digital signature
More information about the Pkg-shadow-devel