Fear and Loathing in Debian/^H^H^H^H^H^H^HUbuntu (or: who needs /etc/motd)

Whoever looked at /etc/motd on ubuntu and thought, HEY, I KNOW WHAT THIS NEEDS – SHELL SCRIPTS! can kindly go die. Seriously? /etc/update-motd.d?

Ubuntu introduced the update-motd framework, by which the motd(5) is 
dynamically assembled from a collection of scripts at login.

…Okay, great. Where’s /etc/default/STOP_IT?

You know what’s even better then making something overcomplicated? Changing decades of expected behavior and not providing a way to, say, opt out. I don’t want to run a fuckload of stupid shell scripts every time I login that do super informative tasks like telling me the IP address assigned to my loopback device. I also don’t want to be told that I should use Landscape, or that there are 83 processes running on my machine.

Still, I could accept all of this if you could just make it go away….but you can’t.

root@tessier:~# cat > /etc/motd
FUCK YOU

Nope….still there.

Want to know what’s even better? Deprecating /etc/motd and not updating its own manpage:

NAME
       motd - message of the day

DESCRIPTION
       The  contents of /etc/motd are displayed by login(1) after a 
       successful login but just before it executes the login shell.

       The abbreviation "motd" stands for "message of the day", 
       and this file has  been  traditionally used for exactly 
       that (it requires much less disk space than mail to all 
       users).

       On Debian GNU/Linux this file is a symbolic link pointing to  /var/run.
       The  contents of this file are regenerated upon every system boot based
       on the contents of /etc/motd.tail.

Way to win, guys!

It would be fine, completely fine, if this was just some cron job that could just be disabled (preferably with an /etc/default switch!). I could live with that. It’s reasonable behavior. Before Lucid, that was basically what was happening:

NAME
       update-motd - Automatically update the message-of-the-day (MOTD)

SYNOPSIS
       update-motd                                [--disable|--enable|--force]
       [d|hourly|daily|weekly|monthly]

OPTIONS
       --disable
              Prevent update-motd from running. This is useful for
              temporarily disabling automatic updates of /etc/motd
              by the /etc/cron.d/update-motd cronjob. Note that 
              this regenerates a base MOTD without the update-motd 
              additions, and then exits.

But, no, no, this is far more insidious. /etc/motd was sooooo 1980, bro!

Regular files are for losers, don’t you want to use w3m to update your MOTD with headlines from Google News? Shit, I mean, why use a plain file when you can use a PAM module?

So, here it is, in login and sshd:

# Prints the motd upon succesful login
# (Replaces the `MOTD_FILE' option in login.defs)
session    optional   pam_motd.so

Okay, disabling that results in nothing being printed. And hey, the manpage for pam_motd helpfully says:

NAME
       pam_motd - Display the motd file

SYNOPSIS
       pam_motd.so [motd=/path/filename]

DESCRIPTION
       pam_motd is a PAM module that can be used to 
       display arbitrary motd (message of the day) files after a
       successful login. By default the /etc/motd file is shown. 
       The message size is limited to 64KB.

OPTIONS
       motd=/path/filename
           The /path/filename file is displayed as 
           message of the day.

….Uh oh. /etc/motd is shown by default? That doesn’t sound right! Well, maybe the module will actually accept the option its manpage advertises:

session    optional   pam_motd.so motd=/etc/motd

Hahaha! Of course not! Why would that work?! I still get a bunch of shit output from shell scripts.

Okay, fine. Now, I really want to know why:

                                                                           
root@tessier:/usr/src# locate pam_motd.so                                       
/lib/security/pam_motd.so                                                       
root@tessier:/usr/src# dpkg -S /lib/security/pam_motd.so                        
libpam-modules: /lib/security/pam_motd.so                                       
root@tessier:/usr/src# apt-get source libpam-modules                            
Reading package lists... Done                                                   
Building dependency tree                                                        
Reading state information... Done                                               
Picking 'pam' as source package instead of 'libpam-modules'                     
NOTICE: 'pam' packaging is maintained in the 'Bzr' version 
control system at:
https://code.launchpad.net/~ubuntu-core-dev/pam/ubuntu                          
Please use:                                                                     
bzr get https://code.launchpad.net/~ubuntu-core-dev/pam/ubuntu                  
to retrieve the latest (possibly unreleased) updates to the package.            

…At this point, words fail me.

But, hey, let’s just take a look at the source, first. I want to know what’s going on, at least. It seems really unlikely that pam_motd is just blithely ignoring its options:

PAM_EXTERN
int pam_sm_open_session(pam_handle_t *pamh, int flags,
                        int argc, const char **argv)
{
    int retval = PAM_IGNORE;
    int fd;
    const char *motd_path = NULL;
    char *mtmp = NULL;

    if (flags & PAM_SILENT) {
        return retval;
    }

    for (; argc-- > 0; ++argv) {
        if (!strncmp(*argv,"motd=",5)) {

            motd_path = 5 + *argv;
            if (*motd_path != '\0') {
                D(("set motd path: %s", motd_path));
            } else {
                motd_path = NULL;
                pam_syslog(pamh, LOG_ERR,
                           "motd= specification missing 
                           argument - ignored");
            }
        }
        else
            pam_syslog(pamh, LOG_ERR, "unknown option: %s", *argv);

…Huh. Okay, looks completely reasonable. Now, for shits and giggles, let’s check out that “updated” source, on the chance it’s different. I install bzr, and dutifully ask it to fetch what I need:

bzr get https://code.launchpad.net/~ubuntu-core-dev/pam/ubuntu
Branched 836 revision(s).  

….Did that really just take as long as I thought? This machine has a gigabit connection to the Internet. I must be imagining something.

time bzr get https://code.launchpad.net/~ubuntu-core-dev/pam/ubuntu

Branched 836 revision(s).                                                                                                                

real	0m42.193s
user	0m10.690s
sys	0m0.290s

….Okay, I wasn’t imagining something. It must have downloaded a TON of source!

root@tessier:/usr/src/ubuntu# du -sh
19M	.

…Oh. I guess not. But, hey, fuck git, or something.

Still! Finally, now we have the Magic Ubuntu Source, which may or may not be the same as the APT Source. Why there isn’t an apt-get magicubuntusource is beyond me.

But, hey, at least Ubuntu’s APT is kind enough to tell me I may need to not use it.

On further examination, the source for the file is the same. Okay, I guess my bone to pick is somewhere else. Let’s look at the patches getting applied as part of the dpkg build process:

Patch for Ubuntu bug #399071

Provide a more dynamic MOTD, based on the short-lived 
update-motd project.

Authors: Dustin Kirkland 

Upstream status: not yet submitted

Index: pam-1.0.1/modules/pam_motd/pam_motd.c

Oh. I see what you did there.

Looking at the patches, suddenly, I am enlightened:

/* Run the update-motd dynamic motd scripts, outputting to 
/var/run/motd. If /etc/motd -> /var/run/motd, the 
displayed MOTD will be dynamic. Otherwise, the admin
can force a static MOTD by breaking that symlink and
publishing into an /etc/motd text file. */

Huh. Okay then. Guess I’ll just go “publish” into my text file.

root@tessier:/etc# rm -rf motd && echo "DO I WORK NOW??" > /etc/motd
[aisling:~]$ ssh tessier
DO I WORK NOW????
Last login: Tue Oct 19 13:47:20 2010 from 
pool-98-110-153-141.bstnma.fios.verizon.net

Well, THAT was a great usage of my time.

So…the best way to fix the pernicious issue of displaying /etc/motd to the end user (read: cat) was 1) to make a PAM module responsible for it, 2) get rid of the “old way” of updating it (cron job), and last but not least, 3) add a completely undocumented behavior (if /etc/motd is a symlink, it is dynamic) that contradicts the man page for said module.

I’m going back to blaming Ubuntu. I also need to step out of the room and have an aneurysm now.

42 Replies to “Fear and Loathing in Debian/^H^H^H^H^H^H^HUbuntu (or: who needs /etc/motd)”

  1. But the scripts are still running each login, which I don’t like. The best solution I found was to chmod -x all files in the update-motd.d directory, and edit the motd (still linked to the /var one) to my liking. It works. And it has the bonus that if any package upgrades or puts a new script in that dir, I’ll notice it right away and will chmod -x it too. But I agree with you, that’s was a very bad job, they should have just left it alone.

  2. Instead of all that, you should just be able to do ‘touch ~/.hushlogin’ I haven’t tested it because I don’t use ubuntu (for reasons like this), but I am kinda curious if it worked.

  3. Solution: Install Slackware

    No more Ubuntu ten thousand interlinked shell scripts to do silly things like update /etc/motd.

    Problem solved.

  4. From https://bugs.launchpad.net/ubuntu/+source/pam/+bug/805423

    Thank you for reporting this issue and helping to improve Ubuntu.

    I understand your concern about the performance impact; however, we are not going to change the default behavior of pam_motd in Ubuntu. There is consensus that the dynamic motd should be enabled by default, and the current behavior is the best way to implement this: the cronjob you refer to was abandoned because it was very wasteful in the common case.

    You are right that the ability to log in is more important than presenting a motd. If this behavior is a problem for you, there are several ways that you can disable it:

    – comment out the ‘pam_motd’ line in /etc/pam.d/sshd if you don’t want to display a motd.
    – delete the contents of the /etc/update-motd.d directory.
    – chmod -x the scripts in /etc/update-motd.d that you don’t want to run.

    Given this existing array of options, I don’t think there’s anything further that we can do here short of changing the default behavior, which we won’t do; so marking this bug “wontfix”.

    1. This does exactly nothing to dispell the notion that you are in fact a bunch of nosy ne’er-do-wells insisting on breaking perfectly good and well-established expected behaviour in favour of your “consensus”. It is true that it is not limited to this one thing, and you’re not the only bunch with hard-ons for meddling with gay abandon of all sense either. But that doesn’t change the well-justified reaction you’re getting as ought all like-minded bunches be getting:

      Fuck you and the concensus you rode in on.

  5. There’s a further aspect which your article did not address. /etc/motd was in early Unix. The idea was that you’d log in to *a shared time-sharing system* and get “the message of the day” (hence, motd). It was somewhere to announce changes, local news (“Off to the Derry at 6pm!”, that’s a pub by the way), but … now? What’s the point in having it at all? That’s more than weird, it’s necromancy. Let’s face it, we all have Twitter, Gmail, Google+, not even ASR-33s, let alone a Flexowriter. Oh! I forgot SMS, and no doubt there’s someone in Telcoland that will try to keep that one alive.

    The technology has changed, and systems should begin to reflect that.

    1. /etc/motd and /etc/issue are useful on multi-user boxes where those users might log into several different machines. You can use it to dispatch reminders about system quirks, maintenance windows, or anything else relating to the administration and operation of the system.

      Hell, you could make the same argument about man pages. We all have web browsers, right? The problem is that every time you do, someone will point out that it’s not quite the same. It’s why nothing’s ever removed from Unix.

      1. Yes, exactly. Also, don’t forget that some systems require disclaimers be displayed to the usersfor legal reasons – we have one of these at my current job – and /etc/motd is a great way to do just that.

        I dunno – Ubuntu seems all wrapped up with progress for the sake of progress, and not coming up to solutions to problems. I wonder what the point of it all is.

    2. There is still a reason for using /etc/motd – it is to give news about the server to the active users of the server.

      Good example: downtime announcements. “This server will be down next tuesday from 8 to 12.”. Everyone that uses the server regularly will see it.

    3. I’m sorry, but you’re wrong. Mind, because this issue shows a deep lack of understanding in those making the change.

      /etc/motd is just the thing for showing a system-wide message after login to /all/ users. There already exists a mechanism for running whatever you want on login /just for you/. There is a reason shells tend to have two config files, one run (yes, _run_) on login and one run (again, yes, _run_) on subshells.

      It is trivial to build your own dotlogindotd type system out of that. It is possibly more trivial still to apply such a thing for all users out of the system-wide default shell login startup file. If done well it also supports the usual “don’t bother me”-mechanisms that are so glaringly lacking in ubuntu’s meddling.

      So changing the motd mechanism to be “more flexible” (and with subtle breakage and failing to properly document it to boot) where that flexibility already exist in much less convoluted construction is simply a silly bugger with nary a clue meddling with a perfectly fine system to make it worse. That is all.

      Sadly, the linux community is full of this, in fact embracing it. To more or less everyone’s detriment, even outside linux. Some achievement, that.

  6. I’m confused about what Debian has to do with this. Having just tested it on my Debian system /etc/motd behaves exactly as you want it. Removing it causes no motd to show. Making it a text file instead of a symlink causes it to display that. So… how is this anything to do with Debian?

    1. Debian has nothing to do with it. The title is “Fear and Loathing in Debian^H^H^H^H^H^H/Ubuntu”, and “^H” is a control sequence for backspace, i.e. the author enters “Debian” and then does 6 backspaces, erasing the word “Debian”, resulting in “Fear and Loathing in /Ubuntu”. I’m not even even sure why the author made such title in the first place, Debian and Ubuntu are quite different in philosophy and Debian hasn’t done any such shenanigans.

      1. Regarding the number of backspaces: You are technically correct, the very best type of correct. I made a mistake! I corrected it, after all these long years.

        Regarding Debian’s implementation: /etc/motd is not a symlink, yes, but it is still infested with PAM module crap. But that is indeed something, I suppose. Half points.

  7. at this point, words just fail me

    so right. and not updating the manpage is really the key issue here – it takes a huge effort every time to figure out whatever did and what the hell they were smoked while building this.

  8. I had a similar problem with their post-install scripts. Almost regularly the debian packages for any daemon/server i install kept setting themselves to be run on startup .Damn annoying it was, i spent some time figuring it out, before giving up and switching to fedora.

    1. But guess what, even fedora’s recent versions seem to be taking baby steps in the same direction as ubuntu…(Gnome 3).. Maybe I should just replace the Desktop and window Manager on whichever system i install.

  9. Hello, Hacker News.

    @David Kerschner: Yes, you’re technically correct, the best type of correct. I’ve corrected the title. Go in peace.

    @jan: Yes – you understand why I wrote this post, whereas a multitude of other people just assume I’m a knownothing.

    @Charles Forsyth: Okay, I’ll admit, you do make an interesting point, one that I’ll need to consider. πŸ™‚

  10. If you thought this was fun, here’s a cool project: figure out how a USB key gets mounted when it’s inserted and what program decides what options to pass to mount(8). Extra credit: change the default permissions used by all USB keys.

    (As I understand it, the answer’s different on every one of the last 4 subsequent ubuntu releases, although you can twiddle the configuration to make them resemble each other.)

  11. As much as I love a good rant, the sniping at bzr is a bit off topic. I generally use git myself, but bzr is not bad, and I can clone that repo in < 2 minutes.

  12. YES.

    THANK YOU.

    Why the fuck can’t people leave well enough alone.

    Could it be that they think their need to parade their wretched ego trumps the work they will cause thousands of other people.

    @enkdoo @Charles Forsyth Yes things have moved on. That is not a reason to break existing stuff. If you think “motd is a bit dated, why not make it dynamic” – great. Write dyn-motd and let people install it if they want. Same sort of wrong thinking as the changes in /etc/alternatives, which totally unnecessarily messed up the standard way of configuring applications.
    The default way of thinking at Ubuntu seems to be “forget all that old stuff, we can make it up any way we want.” for “old stuff” read “millions of man-years of education & experience of linux/unix users/advocates.”
    Now if you HAVE to break something to make new possibilities available – by all means. I mean surely if you wanted more than a 32 bit word for IP addresses, presumably doing that without causing chaos would be beyond the wit of man.

    See what I did there ;->

  13. Hehe, I’ve found that too some year ago while investigating why ubuntu logon’s take few seconds on my uberserver irrelevant to RSA key size.

    I ended disabling all these PAM modules, and some more Ubuntu bloatware.

  14. Just to add something to the discussion:

    For more dynamic information, for example recent news, system state etc.,
    the BSD news subsystem is still available and perfectly functional. This can be set to run “news” in your shell startup on login, so that the dynamic stuff gets printed immediately after the motd.

    Back when I used centrally administered multiuser SunOS systems, the BSD news was kept constantly updated with global headlines, weather, system information, etc., and was a simple but effective solution.

    Regards,
    Roger

  15. Or you could decide to, you know, abandon the koolaid and run a real Unix system with an old-fashioned motd.

  16. Every feeling in expressed in this blog post is familiar to me. I felt the same way between 1998 and 2002 using Red Hat 5.2 and SuSE 7.1. I bought the big “Dr. Linux” book with my first distro, but many things in Red Hat and almost everything in SuSE contradicted what the book said, along with other bits and pieces I’d picked up about unix. Funnily enough, one of my first problems was with /etc/motd, and /etc/issue too. It was generated by script, and it took me quite a while to learn my way around the system well enough to find the script. I think it was buried deep in /etc/init.d/rc.M or whatever those distros called it, which I found completely unreadable at the time. It wasn’t just the book, everything I could find on motd and issue was contradicted by what these distros did.

    The entirety of my Linux usage has been like this. Always something somewhere changing, blocking what I was used to and comfortable with There’s always a reason, but it’s rare for the solution to be well thought out. Sometimes the reason is a really bad one. Usually the documentation is updated better than this, but not always.

  17. I feel your pain brother…

    But yes, not to mention the security implications of scripts that run on every login (as root no doubt).

    The reality is motd was never the place for the things that are being put in it by these folks. (Big fail if two people log in at once as well). The right place was, wait for it, the scripts that run when a user logs in… i.e. something in /etc/profile.d

  18. Ubuntu dispute that they made this change to be able to chase advertisement dollars:

    The other thing Ubuntu did was to add a tracking query parameter to browsers (at least Firefox), which really annoyed me. It took some deep diving to temporarily disable (upgrades overwrites you customization). Ubuntu was a short an unpleasant experience for me, and I went back to Debian as soon as there was a workable installer for my (current) hardware.

    I am quite worried about systemd and it is being adapted by a lot of the distributions. What was a 10 second change before to /etc/cron.d/certbot, now required the following process:

    1. find /lib/systemd -name certbot\*
    2. edit the certbot.service config file

    Ehh… wrong, that gets overwritten by later updates. Instead you need to:

    2. mkdir /etc/systemd/system/certbot.service.d
    3. vi $!/local.conf
    4. Figure out what the DSL is for making a change diff to the config file I located in 1,
    which turns out to be:

    [Service]
    ExecStart=
    ExecStart=/usr/bin/certbot -q renew ….

    5. Then you have do systemctl daemon-reload, apparently.
    6. Never figured out how to debug/dry-run this timer invoked script, but `systemctl cat certbot` at least told me that my config file was being picked up.

    The syslog-ng configuration I had for years and years stopping working with Debian 9. It is not possible to disable the journal, but in Debian 8 you could at least tell i to pass everything to syslog and not write its own binary(!) log files. With Debian 9 that configuration disables all logging, and I have seriously not found a way to just make journal go away.

    You can elect not to run systemd, but that may or may not work in the future. I will probably give Devuan a whirl. Any other distributions to consider? I tried to run OpenBSD but there were no support for X with nvidia hardware at the time.

    1. I am going to probably move a good number of my machines back (I say back, because I was a frothy-mouthed FreeBSD user in 4.x days, which – frankly – seems like an aeon ago) to FreeBSD. I will also probably use Devuan, since the people responsible for it have done a lot of other great stuff.

Leave a Reply

Your email address will not be published. Required fields are marked *