Default MOTD for server should point to documentation URL

What browser? ;)

Also note that this would appear on desktop consoles too, so can't reference the server edition.

Couldn't you just patch /etc/init.d/bootmisc.sh to add a different message if the machine was installed from a Server ISO, or is running the server kernel?

Use a different /etc/motd.tail possibly. A quick example:

        # Update motd
        uname -snrvm > /var/run/motd
        $server=$(uname -snrvm | grep -o server)
        if [ $server ]; then
                [ -f /etc/motd_server.tail ] && cat /etc/motd.tail >> /var/run/motd
        else
                [ -f /etc/motd.tail ] && cat /etc/motd.tail >> /var/run/motd
        fi

Just my thought.

When I ran openbsd the first time I was delighted with the ease of getting good advice right after booting up. E.g. there is an "afterboot" man page which you can also see here:

http://www.openbsd.org/cgi-bin/man.cgi?query=afterboot&sektion=8

which gives lots of good advice and links to other critical man pages.

I like asommer's idea for a custom motd, and wonder if it should be based on the lack of a graphical login screen (gdm etc) rather than presence of a standard server kernel.

Isn't it better to point to the ubuntu documentation instead of server documentation, so there it no problem if we are on Desktop or Server? so the MOTD will be:

"To access official Ubuntu documentation, please visit :
  http://help.ubuntu.com/8.04"

Attaching debdiff with the proposed changes.

Steve: can you take a look at this one?

Raising the prio in order to get some attention on this

For the server edition, in my opinion the motd should contain instructions for the user to access locally installed documentation with whatever the default browser is, rather than referring to the website. That's the whole point of installing the ubuntu-serverguide package on the server edition (bug 45944)

Mathiaz and soren looked at this and it is not as trivial a problem as it would have first seemed to be. Here are the problems we currently face:

 * We have yet to find a way to determine, in the post install script of the package, whether we are installing a server or not.
     - The running kernel is not yet a server kernel at this stage.
     - /proc/cmdline does not directly contains information that shows we are installing a kernel.
     - We cannot check the content of the CD as this would not work when doing network installs.

 * Modifying the motd at runtime could be a solution, only if the motd has not been changed, unfortunately the /usr/share/base-files/motd.md5sums was not updated when the motd was modified for Ubuntu, so we have no means to check whether the original file as been changed by the admin (in which case we should not change it, obviously).

Any ideas are welcome at this point...

nxvl's suggestion seems pretty reasonable to me; point to a top-level documentation page and let the user sort it out. They probably know better than we do what they need help on!

If you do insist on having a different motd, though (which I think is unwise; it's not uncommon to run small-scale servers by installing a desktop and then sticking a few server packages on top, and people logging into those servers might want help too), then remember that resolving conflicts among packages is always much easier if you don't try to cram everything into the same file. You could have /etc/motd.tail.d/ and have /etc/init.d/bootmisc.sh concatenate uname information, followed by /etc/motd.tail, followed by everything in that directory. This smells somewhat of overengineering, but I don't see how else to fulfil your requirements.

With regard to motd.md5sums, this should clearly be updated to match all versions of that file that have been in Ubuntu. That could be done retrospectively. However, you still shouldn't edit it at runtime; the handling of this file is complicated enough already without trying to have it be controlled by multiple packages at once.

On Mon, Mar 17, 2008 at 10:58 AM, Colin Watson <email address hidden> wrote:
> nxvl's suggestion seems pretty reasonable to me; point to a top-level
> documentation page and let the user sort it out. They probably know
> better than we do what they need help on!

On the basis of the other comments in this bug, that does seem to be
the easiest solution. However, in relation to the serverguide, it
means that the user may not discover that the documentation is
available to be installed on the system locally, rather than read on
the website - which is kinda the whole point of creating an
ubuntu-serverguide package. However, if it isn't possible to customise
the MOTU for server systems (whether basic server installations or
desktop installations with server packages), then I can't really think
of any other solution.

--
Matthew East
http://www.mdke.org
gnupg pub 1024D/0E6B06FF

I agree that nxvl proposal is the simplest to implement. The doc team has agreed to modify help.ubuntu.com landing page to include a direct pointer to the server guide (which is currently a bit hidden). As I don't think we should have to update the MOTD for each release, I am enclosing a slightly shortened version of nxvl patch.

Could you attach a new debdiff against the latest version of the package in the archive ?

The most recently provided patch also doesn't handle updating /etc/motd with the new default on upgrade from previous releases, which is done by updating share/motd.md5sums. Nicolas, can you provide a patch that handles the upgrade as well?

Uploading changes as suggested.

The md5sum that's been included doesn't seem to match the one on my hardy system. I see the following:

$ awk 'NR > 2' /etc/motd | md5sum | awk '{print $1}'
b96a46f1f55c293787c096d1e5f5ce31
$

As a result, the package fails to upgrade the motd when I install it, because it assumes the motd has been locally modified (which, TTBOMK, it hasn't been).

I guess the checksum you included is for the *new* motd, which doesn't help us with upgrades?

I think the correct line to add to share/motd.md5sums is this:

 b96a46f1f55c293787c096d1e5f5ce31 8.04 hardy Linux

can you confirm?

Yes i think i added the new one, thinking that's what needed.

This has been fixed now in an upload of base-files; looks like the change wasn't registered because the bug was assigned to the wrong package. Here's the changelog:

base-files (4.0.1ubuntu3) hardy; urgency=low

  * Added information about the docs web page (LP: #159371)

 -- Nicolas Valcarcel <email address hidden> Thu, 03 Apr 2008 00:13:05 -0500