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

Re: motd handling in jessie & beyond

On Fri, Jan 02, 2015 at 11:56:44AM +0100, Ansgar Burchardt wrote:
> as this seems to be only about including the output of `uname' in motd,
> how about just *not* including it? I never found it to be particular
> helpful anyway...
> If you want to include information about the machine you are connecting
> to, then the OS version, amount of RAM, number and speed of processors,
> and system architecture are probably more helpful than just the kernel
> version the system is running.

I hear you -- the OS version alone is far more useful than uname in my

However, I think this is a separate question. This discussion is about
the common interface between a number of key packages that:
a) makes the behavior consistent between different login methods and
init systems (a jessie regression),
b) moves that uname call in one config file and one package rather than
hardcoding that uname call in 2-4 places (including pam.d configs & init
scripts, which while config files, people generally avoid to customize),
c) allows customization by the sysadmin and/or other packages.

The /etc/update-motd.d mechanism as is shipped in Ubuntu and partially
shipped in Debian is excellent for this in my opinion, as it's just
arbitrary scripts that can run and print whatever you want them to.  For
example, Ubuntu's update-notifier ships /etc/update-motd.d stanzas that
print the number of package upgrades pending and whether a reboot is
required because the kernel has been previously upgraded.

Now, what really belongs in our motd and what doesn't is a discussion
that is probably worth having, but I'd personally prefer it if we defer
it for after we have a common interface that allows us to do those
customizations and do them in one place.


Reply to: