Fear and Loathing in Debian/Ubuntu (or: who needs /etc/motd)
deadmemes.net
deadmemes.net
There are two (maybe three) nominal 'people' in this particular circle of hell, one is the developer who originally felt that the message of the day should reflect something important without having to actually edit it every day. One is the guy who wants the motd to have something different in it. Culturally the first guy is the 'lazy' type (in quotes because it reflects the culture of "hey I've got a computer here the more work it does the less I do" which is a popular meme in system administrator circles and elsewhere) and the other is the 'KISS' type (where KISS is the 'keep it simple stupid' type of person who oftens stresses simplicity over mechanism. The third (perhaps absent) person is the 'systems' person/distro owner who imposes an implicit design guideline on the system by virtue of the changes they accept or don't, commit or don't into what becomes the final product. In the kernel tree this is clearly Linus but in other parts of the system it isn't always clear whether or not there even is someone in this role.
Underlying this I find a strong sense of frustration at changes that are made to 'small, meaningless' parts of the system when large parts sit there on fire. Of course not everyone can fix bugs in EXT4 or memory leaks in long running daemons, everyone needs to start somewhere, and sometimes changing the colors around in ls(1) so that the default is unreadable on your favorite color scheme is probably some 'starter project' of someone who wants to become a bigger part of the solution.
It is the experience you get when you use Linux, and that experience is an artifact of how Linux is created. So hating it isn't particularly productive, although like UNIX-haters before it rooted in much the same arguments.
Without debating the (IMO very questionable) utility of changing motd behavior, or the (IMO too sloppy) change management of Ubuntu...
A three-line update to man motd would have solved the problem, and the motd maintainer didn't do that, and whoever accepted the patch didn't do that, and now anyone who wants to figure what the Penguin is going on is going to have to google for it and, hopefully, find the answer before they hit the "download source" rabbit hole.
All because of a few sentences.
Yeah, at home I don't use Ubuntu directly anymore. =)
> 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.
The fundamental problem here is the blog author didn't realize that `echo foo > /etc/motd` wouldn't work, even though the manpage did, in fact, inform him that /etc/motd was just a symlink to something that gets regenerated at boot time. I'm not really sure what the manpage could have done to make it more obvious what his problem was.
Now, it's possible the manpage is out of date, and that it's regenerated via some other mechanism than /etc/motd.tail. I don't know (since I don't use Debian, or even Linux in general). But the salient point here was that it points to a file that gets regenerated at boot time.
*Edit: On second look, it sounds like this change makes it regenerate on each login, not just each boot. I can understand why someone might think that `echo foo > /etc/motd` followed by a login would then print 'foo', given the current manpage. But they certainly wouldn't expect that it would still print 'foo' after a reboot unless the break the symlink (and breaking the symlink fixes the author's complaint).
A comment in the Description area that runs along these lines would have made the entire question a non-starter:
If /etc/motd is a non-symlinked file, regeneration will not occur.
"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."
It should probably read:
"On Debian GNU/Linux this file is usually a symbolic link pointing to /var/run. The contents of the file in /var/run are regenerated upon every system boot based on the contents of /etc/motd.tail."
To make it clear that the programs that generate the contents target the file in /var/run, and do not operate directly on /etc/motd.
I do not know how one can go from this to "to get traditional behavior, delete the symlink and make /etc/motd a regular file." Great, so it's a symlink to a file that gets regenerated. Now how do I make it do the traditional thing? The manpage doesn't offer any help, and I couldn't figure it out if I didn't know the answer already.
Furthermore, having a configuration switch depend on whether a file is a symbolic link or not is just asinine.
In Debian, almost everything in /etc can be edited, and the system is designed to preserve the sysadmin's changes. Maybe this isn't obvious to new users, but if you've been using Debian for a while, this behaviour is exactly what you would expect.
Also, a quick visit to #debian or #ubuntu IRC would have resolved this in a few minutes.
In the case of Ubuntu I think this definitely happens, although AFAIK the high-level design discussions & decisions largely happen behind closed doors (happy to be corrected on that point.)
In this case I wouldn't be surprised if there was a requirement/design decision to have the system explicitly remind the user if there were pending package/security updates and also prompting you about available new distro versions. At least, on default Ubuntu systems the motd does these things and has for some time - and it feels to me like a "by design" thing.
Why they rolled it from an update-motd standalone package to a built-in part of the pam module, I have no inkling over, though.
I tend to write posts on my blog in a particular style. It tends to run towards bombastic, deliberately, for effect. My point with this entire post was more how something simple can unravel into a deep hole, and how, in particular, I hate the way Ubuntu does many, many things. It's not that I hate change: I hate non-obvious change.
I often don't write posts as a systems administrator might approach something (my main complaints about honeycomb, as an example, were more focused on how an average user might interact with it as opposed to, say, me - I was just annoyed), and I tend to like to turn over rocks and see what is underneath. My post serves to relay an experience, rather than plead for help, or whine, if that makes any sense at all.
I should have titled the post better, admittedly. And for the record, I don't hate Ubuntu. Or Unix. Or Linux. I've been using them in various iterations for fifteen years. Try not to read so much into a rant written mostly to amuse a few of my friends.
Or if the symlink semantics just weren't something you considered at this point, which lead you to keep hunting.
It's hard to say in retrospect how obvious that clause is, but there's no reason the original author couldn't have raised a bug with Debian saying they didn't understand the man page, and can Debian please add another sentence saying "To have a static motd, delete the /etc/motd symlink and replace it with a plain text file." Ranting won't make it better, but a polite suggestion might.
Ditto raising a suggestion with Ubuntu about replacing "boot time" with "login time" in their manpage.
---
Except from the motd man page on Ubuntu oneiric:
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.
I can see the original author's frustration, but I got to the end of the post and thought "why didn't he submit a bug report mentioning the motd man page needed updating?"
Yes, this was a mistake in Ubuntu. Nevertheless, it didn't seem like one that the Ubuntu developers would be unwilling or incapable of fixing. In fact, lo and behold, it has been fixed!
I can see there's a broader point here in general, regarding the philosophy of "change vs not-change." However, that point doesn't seem to necessitate quite so much nerdrage.
That second 'this file' is ambiguous. I think the grammatically/semantically/whateveryoucallitally best interpretation (by a tiny margin) would be that both 'this file' would talk about the same file, but I am not sure, and I think that, in the real world, that is the incorrect interpretation.
Incidentally, to disable all chatter at login (as documented in man login, and it actually still works in Ubuntu 11.10):
touch ~/.hushloginPlaying with: http://ipinfo.info/netrenderer/index.php it seems that Internet Explorer won't display the strikeout characters because the font on HN is set to Verdana, which doesn't have the combining character. If I create a page without specifying the font, it works fine.
I have Verdana on my system, but the browsers and font libraries I have installed mean that the glyph is taken from another font when one is missing. I'm surprised Windows 7 browsers don't do the same. Or maybe you don't have the glyph in any font, which would also be disappointing.
Of course, a real webpage would use <strike> or CSS, and strikeouts are usually poor typography anyway, except as part of lame jokes. But other unicode combining-characters can be of real use.
Despite that, I wonder a bit, who is really manually editing that file by hand?
I can't tell you how many straightforward Unix configuration things -- network interfaces, resolv.conf, initscripts, etc. just plain can't be edited on a Debian or Ubuntu system except through Debian-specific tools because if you do, the Debian-spoecific tools will clobber your changes and/or other Debian-specific things won't work right.
This is why I use Arch. It's like everything I could want out of a Linux: the simplicity of Slackware, the completeness of Debian (if not quite as huge as Debian without the AUR), the rolling release schedule of Gentoo.
This specific instance of pointless complexity seems to be almost only the work of of Ubuntu.
/bin/rm -f /etc/motd
touch /etc/motd
chattr +i /etc/motdThen when they are in BSD, or Arch, it will be "Fuck you Arch" you don't have this man page right, I am switching OS again and bitching to the whole world about it.
Yeah I don't hear a lot of people complain about Arch and BSD and other "canonical" *nix systems. But it not because they are flawless, but because few people are using them compared to RHEL,CentOS and Ubuntu flavors.
Another way to look at it, if motd man page is what people are now mainly complaining about when it comes to Ubuntu, Ubuntu is doing great.
It has other issues but documentation isnt one of them.
Until the next update, of course!
% apt-cache show update-motd
...Description-en: superceded by pam_motd in libpam-modules
...The functionality formerly provided by this package is now integrated into pam_motd, in libpam-modules.
If you're looking for stability and steadfastness, you probably shouldn't be using a distro with a 6 month major release cycle. Things change, things get broken, and if you don't know that about Ubuntu by now, you're doing it wrong.
Things like why isn't my '/etc/cron.daily/blah.sh' script not running? I'll give you a hint its the period. Good luck realizing that if you come from any other Unix out there.
There is a need for progress but breaking everything just to try something new (pulseaudio, unity, and so on) is not progress just frustration.
Ubuntu on the other hand pushes changes before documenting them.
Debian is my primary distro and I still consider it the least evil - but sadly only in contrast to what the others have on offer.
Their mentality to patch and break everything at the slightest opportunity is a big problem. Don't get me started on the mess they make under /etc with all their ass-backwards wrappers for apache configs etc. Motd is not even the tip of the ice-berg here.
Personally I've long stopped relying on anything but the base-install for this reason.
Anything relevant to an application deploy is compiled from source or installed from a custom deb (postgres, nginx, et al). I have better things to do than figure out the latest brainfart of some package-maintainer about how to scatter a postgres-installation across the filesystem...
An update changed something, the documentation didn't have the answer so you checked with the source. Welcome to linux. Actually, welcome to the world of software.
Did you at least submit a bug report?
Seeing as how I share, almost verbatim, the author's rage, allow me to break it down into a sentence or two:
What possible benefit was there from overcomplicating the bloody MOTD file? I don't see anything but complexity for complexity's sake.
I dunno, but does it really matter? If the motd mattered anything to me, I would have been aware of the change.
I was blindsided by this change too and one day, like years ago, I noticed that the motd wasn't working as I expected and reset itself. I did (something to the effect of) this:
$ ls -l /etc/motd*
lrwxrwxrwx 1 root root 13 2008-09-23 21:44 /etc/motd -> /var/run/motd
-rw-r--r-- 1 root root 0 2009-06-14 15:01 /etc/motd.tail
Then I thought "oh I see what they did there", dropped a banner in motd.tail and moved on with life. Wow, yeah, 2 and a half years ago. Didn't care then, still don't care now.It sounds to me like this whole rant could have been replaced with a bug report on the documentation in Launchpad.
I happen to like a quick status check popping up for me to either look at or just ignore at my pleasure, especially since 99% of the time, the first thing I do when I log into a server is do exactly the sort of status check available in the Ubuntu MOTD.
There are benefits. That you don't consider them worthwhile is fine, but you don't need to go apoplectic about it.
There are a lot of things we could do on our own. Sometimes we don't have to. Sometimes, some set of people would prefer we did have to, but that doesn't mean we all have to acquiesce to their desires.
This seems to be a very blatant example of scope creep.
A choice has been made for Ubuntu's behavior. Other distributions are free to make their own choices. If you find Ubuntu's choice disagreeable, you can file a bug and try to change it, or you can change it for yourself on your own system, or you can just live with it, or you can change distributions. You can even fork Ubuntu and make just this change, if you like. You do have that choice.
Getting mad because Ubuntu's choices are different from choices you might make is just silly.
I'm not deciding that, other people made those decisions decades ago. It's a bad idea to mess with defaults for no good reason and then being too lazy to at least package it properly.
Getting mad because Ubuntu's choices are different from choices you might make is just silly.
I couldn't care less about ubuntu, I'm not using it. I just hate to see that mindless crap trickle down into one of the last semi-sane distros (debian). This only leads to forks in the future which means more work for everybody.
Again: If some distro-maintainer wants a fancy motd then great, make it a package and make that package the default for the desktop-install. Don't mess with core-stuff that has stood the test of time since before said maintainer was even born. Down that path lies SuSE linux.
This isn't decades ago, and Ubuntu is not Unix. It is Ubuntu. Decisions made decades ago for Unix are not inherently right, and have no special moral authority.
> I couldn't care less about ubuntu, I'm not using it.
Then perhaps you shouldn't speak on the subject. /etc/motd is the least of the things they've "messed with".
Trying to treat a modern operating system as if it's a 1970s operating system is absurd.
> Down that path lies SuSE linux.
There is nothing inherently wrong with SuSE. I don't happen to use it, but there are a lot of things I don't happen to use.
You're stuck in the past. A Unix-centric past, at that. If it works for you, great, but don't pretend we all have to stay there with you.
This attitude is not helpful and please don't "blame" it on Linux.
That may be the most amusingly misdirected statement ever considering the inane rant that is under discussion.
The motd file, by convention, is displayed whenever you log in to a Unix box. It has been this way for longer than you have been alive.
There is no question of 'use something else'. There is no app store for alternatives to /etc/motd. There is no dialog box that pops up that asks you what alternative to motd you would like to see.
The standard unified method for determining what a system file is composed of is called 'man'. This has also been around since long before you were alive. The author demonstrated correctly through the use of this tool that the ubuntu system for displaying the motd is (a) needlessly overcomplicated, (b) totally broken, and maybe most importantly (c) at odds with its documentation.
Please log out of the internet.
>There is no question of 'use something else'.
Yes, there _is_ an alternative. It's called use something else. Use a distro that doesn't change. Use a BSD, use Slackware, use RHEL/CentOS. Don't use a bleeding edge distro that is best known for change if what you really want is the same thing you've seen since before you were born.
If you don't like how Ubuntu does it, don't use Ubuntu.
1) Every distro out there has its weaknesses (everyone likes to tout Arch, but it was only recently that pacman got support for crypto-signing, for example).
2) If every user that ever found a problem with any Linux distribution just hopped to another Linux distribution then: 1) they would run out of distros real fast and 2) nothing would improve inside of said distros because there was no one complaining (or challenging the status quo).
Since "man motd" does not tell you how /etc/motd actually works, the solution to getting a working /etc/motd is to use another OS?
This all could have been avoided with "man motd" saying something useful.
So, what you're saying is that this new motd system is some seriously disruptive technology? Good on those ubuntu kids, showing us all how its done.
It's not disruptive. It's just idiotic.
[ For that matter, 9/11 was pretty disruptive, but I don't think that terrorism is a good start-up idea. Please refrain from knee-jerk reactions (i.e. "I can apply the word 'disruptive' here, therefore it's good"). ]
Not to mention the questionable desirability of stacking complexity upon a very simple goal...