FFe: /etc/motd contains duplicate welcome/documentation blurbs on lucid

[Tomas Cassidy]

Binary package hint: base-files

When logging into a lucid-server virtual machine, the MOTD message contains duplicate information about documentation:

For official documentation, please visit:
 * http://help.ubuntu.com/

Welcome to Ubuntu!
 * Documentation: https://help.ubuntu.com

The first two lines come from /etc/update-motd.d/00-header which is printing the contents of /etc/motd.tail
The second documentation reference comes from /etc/update-motd.d/10-help-text

I'm guessing that since the VM is only running the generic kernel (not the server kernel), its printing out the normal documentation URL from 10-help-text instead of the serverguide URL.

I don't think that the same documentation/help URL needs to be printed out twice in the MOTD on login.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: base-files 5.0.0ubuntu13
ProcVersionSignature: Ubuntu 2.6.32-17.26-generic 2.6.32.10+drm33.1
Uname: Linux 2.6.32-17-generic i686
Architecture: i386
Date: Sun Mar 28 16:13:58 2010
InstallationMedia: Error: [Errno 13] Permission denied: '/var/log/installer/media-info'
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: base-files

[Daniel Richard G. (skunk)]

Duplicate documentation URLs in general are a problem right now in Lucid Beta1. Here's what I see on logging into my minimal/desktop install:

$ ssh root@test-ubuntu
root@test-ubuntu's password:
Linux test-ubuntu 2.6.32-18-generic #27-Ubuntu SMP Fri Mar 26 19:51:10 UTC 2010 i686

Welcome to Ubuntu!
 * Documentation: https://help.ubuntu.com/

Welcome to Ubuntu!
 * Documentation: https://help.ubuntu.com/
Last login: Tue Mar 30 12:30:59 2010
root@test-ubuntu:~#

[Daniel Richard G. (skunk)]

/etc/motd.tail, as installed, contains the same "Welcome to Ubuntu!" text as /etc/update-motd.d/10-help-text. One or the other needs to go.

[Daniel Richard G. (skunk)]

Dustin, could you have a look at this?

[Dustin Kirkland  (kirkland)]

Hi, thanks for the report.

Can you tell me if this is persistent across reboots, or is it just after the upgrade, but before the reboot?

My reading of the code indicates that this should be cleared on the next reboot (when /var/run is wiped, which is where /etc/motd points).

[Daniel Richard G. (skunk)]

It's persistent across reboots. And this is on a system installed from the Beta1 netboot/alternate installer, not a dist-upgrade.

What is generating /etc/motd.tail? For that matter, what's the proper way to (re)generate /etc/motd? /etc/init/mounted-varrun.conf seems to do this itself, without bothering with /etc/update-motd.d/*. (Shouldn't there be an update-motd(8) script or something? I can't find what's supposed to do the run-parts call.)

This is looking like a "too many cooks" problem....

[Tomas Cassidy (tomas-cassidy)]

I can confirm that it's persistent across reboots, on a system installed from Ubuntu Server Lucid beta1 installer.

APT is saying that the update-motd package in karmic/lucid has been superceded by pam_motd in libpam-modules.

[Dustin Kirkland  (kirkland)]

I don't have an /etc/motd.tail at all in my freshly installed Lucid
desktop. So I suspect that's probably where the problem lies. I'd
imagine we might need some upgrade logic in base-files postinst that
conditionally removes /etc/motd.tail if we can determine that
everything in there is handled elsewhere.

What's the output of this:

dpkg -S /etc/motd.tail

:-Dustin

[Dustin Kirkland  (kirkland)]

The run-parts call is now handled by the pam_motd module (C program).

It's run against everything in /etc/update-motd.d at login.

Quickly-running scripts just get run on every login.

Ones that take a long time to run (updates-available,
upgrade-available), or ones who's information doesn't expire quickly
should cache their data in /var/run and background an update when it
determines that it's data is stale.

The /etc/update-motd.d/00-header script prints /etc/motd.tail if it
exists. As far as I can tell, motd.tail should really be empty on
most modern Lucid systems, and should now only be used for the Admin
to manually jam some information in the MOTD.

[Tomas Cassidy (tomas-cassidy)]

The output of dpkg -S /etc/motd.tail is:

dpkg: /etc/motd.tail not found.

I booted into a Lucid Beta1 Desktop VM and /etc/motd.tail is empty, but /etc/motd.tail.old contains the same text as /etc/motd.tail on the Ubuntu Server Lucid Beta1 VM.

/etc/motd on the Desktop VM contains just the output of "uname -a", while /etc/motd on the Server VM contains the output of "uname -a" plus the duplicate documentation text I put in the bug description, and the following text below it:
Checking for a new ubuntu release
No new release found

[Daniel Richard G. (skunk)]

Ditto here, /etc/motd.tail is not owned by any package.

Dustin, thanks for clarifying how things work now. The pam_motd(8) man page says nothing about doing run-parts stuff, so I'll file a bug against libpam-modules to get that documented. Do you see the goings-on in /etc/init/mounted-varrun.conf as a problem?

I suspect that /etc/motd.tail might be getting generated by the alternate installer (which is the only one I've used so far). I'll see if I can confirm this.

[Dustin Kirkland  (kirkland)]

Okay, I've tracked this bug down, and I have a fix in the attached debdiff.

I think we're going to need to get a FFe granted, and/or a String Freeze exception granted.

I think this solution is much cleaner, more logical, and the most flexible. Hopefully the powers that be will agree.

[Daniel Richard G. (skunk)]

In the blurb in 99-footer, I would swap the words "executable" and "numbered"---it took me a couple glances to realize the former was an adjective.

Otherwise, looks good.

[Dustin Kirkland  (kirkland)]

Thanks, got it.

[Dustin Kirkland  (kirkland)]

Updated debdiff.

[Steve Langasek (vorlon)]

Looks good to me for upload.

[Launchpad Janitor (janitor)]

This bug was fixed in the package base-files - 5.0.0ubuntu14

---------------
base-files (5.0.0ubuntu14) lucid; urgency=low

  Fix double-printing of motd.tail, LP: #550561
  * debian/postinst.in: motd.tail should no longer be generated by this
    package; rather it's where the sysadmin would add static text to
    append to the dynamically generated /etc/motd
  * debian/update-motd.d/*, debian/rules:
    - move update-motd scripts to this dir, clean up install rules
      (scripts were getting installed in two places)
    - 00-header: add the lsb_release information, which seems at least
      as pertinent as the kernel's version and build-date
    - 00-header, 99-footer: split the header (uname, lsb_release) and
      the footer (admin's motd.tail) to two separate scripts
 -- Dustin Kirkland <email address hidden> Wed, 31 Mar 2010 14:56:49 -0500

[caroeber (alex-roeber)]

I think that the issue is still happening as I have done a dist-upgrade and had a motd
$ ls -al /etc/motd
lrwxrwxrwx 1 root root 13 2009-03-23 15:22 /etc/motd -> /var/run/motd
I have now replace the motd file for the third (3) time and it still reads:

Linux brwebd1 2.6.32-21-generic-pae #32-Ubuntu SMP Fri Apr 16 09:39:35 UTC 2010 i686 GNU/Linux
Ubuntu 10.04 (lucid)

Welcome to Ubuntu!
 * Documentation: https://help.ubuntu.com/