Ubuntu displays advertising in /etc/motd
bugs.launchpad.net
bugs.launchpad.net
Shouldn't that be more like "Instead, Ubuntu should not fetch the motd from the internet by default, but have this feature as opt-in"?
"[Bug 1691901] [NEW] 50-motd-news costs 5 seconds every login on disconnected systems"
By design:
- Asynchronously, about 60 seconds after boot, a systemd timer fires which runs "/etc/update-motd.d/50-motd-news --force"
- It sources 3 admin-editable config variables in /etc/default/motd-news. The defaults are: ENABLED=1, URLS="https://motd.ubuntu.com", WAIT="5"
- The admin can disable it entirely (ENABLED=0), change or add other MOTD news sources (your corporate IT team could run its own), and change the wait time in seconds
- If it's enabled, that systemd timer job will loop over each of the URLS (note, that it's important that these should be https with valid SSL certificates), trim them to 80 characters per line, and a maximum of 10 lines, and concatenate them to a cache file in /var/cache/motd-news
- Every ~12 hours thereafter (with a little bit of random timer fuzzing), this systemd timer job will re-run and update the /var/cache/motd-news
- Upon login, the contents of /var/cache/motd-news is just printed to screen. There was a bug (fixed now, working its way through the Ubuntu update process), in that an empty cache file was not getting, if the fetch failed, so the fetch was retried every time (and failed every time, with the $WAIT delay of 5 seconds). Obviously, it was a simple fix.
As I am generally responsible for this feature in Ubuntu (as the Ubuntu Product Manager for the design, and the Ubuntu Core Developer for the implementation) I'll also respond to the discussion about this feature being included in Ubuntu at all...
- Back in 2009, Ubuntu was the first distribution to add the concept of a "dynamic MOTD", by introducing the /etc/update-motd.d/* structure of scripts. I originally implemented it for Landscape (a commercial package management system by Canonical), but it has since also been adopted by Debian, Amazon Linux, and others.
- It's a flexible framework that enables distro packages or administrators to add executable scripts in /etc/update-motd.d/* to generate informative, interesting messages displayed at login.
- This was quite interesting, in that for almost 40 years of Linux/UNIX, the "Message of the Day" was anything but that... It was a message that was created at one point in time, when the distro released, and that's about it. And we managed to change that.
- If you look in your Ubuntu's /etc/update-motd.d/, you'll see a set of scripts. One prints the generic "welcome" banner. The next one prints 3 links, as to where to find help. You'll also find one that counts and displays the number of package updates available for the local system. Another tells you if a reboot is required.
- All of these are locally generated, based on local information available on the system.
- In Ubuntu 17.04, we added /etc/update-motd.d/50-motd-news. This is the script who's design is described above. The motivation is threefold:
* Sometimes, there's critical information that either we, the distro, or perhaps even the local IT administrator of a fleet of systems needs to communicate to users at login. Think, "ShellShock", "Heartbleed", "StackClash". This seems to happen every few months, in the current state of the world.
* Other times, we need to communicate something about the distribution. EoL messages, new feature availability, etc.
* And sometimes, it's just a matter of presenting a fun fact. News from the world of Ubuntu. Or even your own IT department. Such was the case with the Silicon Valley / HBO message. It was just an interesting tidbit of potpourri from the world of Ubuntu. Last week's message actually announced an Ubuntu conference in Latin America. The week before, we linked to an article asking for feedback on Kubuntu. Before that, we announced the availability of Extended Security Maintenance updates for 12.04. And so on.
- There is a team of engineering managers at Canonical (the ~ubuntu-motd team in Launchpad), all of who have shared write access to the source code repository (lp:ubuntu-motd in Launchpad). Going forward, we're going to review one another's proposed message merges. In fact, that's an open source repository. You're welcome to propose your own messages for merging, if you have a well formatted, informative message for Ubuntu users. We'll be happy to review and include them in the future.
As always, I'm impressed with the critical analysis of the HackerNews community. We, the Ubuntu ecosystem, are held by the HN community to a very high standard, and we're quite humbled by that. Thank you for the continued feedback and response.
Cheers, Dustin
- Why did you copy/paste this on the bug tracker (https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/17...) and find/replace 'Ubuntu Community' with 'HackerNews community'? Doesn't that seem a little bit patronising to both parties
- Why didn't you actually address the issue? You said a lot of words but at no point did you say whether or not you would be removing this "feature" OR keeping it.
Considering the example shown (which I also get logging in) is about HBO's use of Tensorflow, this also happens to be the best-targeted ad I've seen in a while. At that level, advertising actually does become something that's valuable/interesting for the recipient.
And if not, it takes about 10 seconds to disable.
Speaking for myself, I expect /etc/motd to contain information deemed relevant to me by the responsible sysadmin. I feel like this is the hi-jacking of a well-established communications channel, for ads no less.
The item linked in the MOTD isn't an ad, it's a news story about a relatively high-profile project that turns out to have been built with Ubuntu. The story isn't written by Canonical; in fact, in the relatively long list of people thanked for their help at the end, Canonical isn't even included. It doesn't make a sales pitch, and only mentions the word "Ubuntu" one time.
The only way to interpret it as "advertising" is if you believe literally anything that mentions Ubuntu is an ad, which would be stretching the meaning of the word far beyond the breaking point.
If Canonical wants to use /etc/motd to spotlight interesting projects people are doing with Ubuntu, as a user of Ubuntu desktop & server I personally don't see a problem with that.
Canonical has a history of doing weird things: how many times have they diverged from upstream with some in-house solution that never quite works out.
The 6 monthly releases aren't realistic for business, who use LTS, at which point you may as well use Debian and back ports/vendor repos for software you need more updated versions of.
Around the time I tried Ubuntu, I started encountering problems less and less. Maybe I got better, maybe all distributions got better, or maybe Ubuntu is more robust. I just don't feel any pain that would motivate me to try other distributions. Ubuntu also seems to be the de-facto standard, and anything with install instructions will first cover Ubuntu.
I can't deny the Ubuntu community is extensive and there are in-depth articles covering setup of just about anything on Ubuntu. Fortunately, owing to the Debian basis, it's fairly easy to convert the same tutorials to run on Debian.
Over in the Python world I'd be perfectly happy to use Debian. I'd just use it only to provide an operating system; then I'd compile the version of Python I want, and use virtualenvs and pip for managing the actual application code and dependencies.
For nodejs you're better off using a vendor like nodesource regardless of your distro.
I really wish other distributions would steal the idea of software collections from Red Hat. Having newer runtimes and database engines available out-of-band is a great idea, especially considering SCL packages live in an isolated root and won't interfere with the base system.
I'm not sure I know what you mean by out-of-band ? Installed via something other than rpms? Installed from non-official rpm repos?
It sounds like you just need packages built that allow for parallel installs of other versions of the same runtime/etc.
The PHP packages for 5.6 onwards on Debian are built such that they can be installed side-by-side.
Building on this basis, dotdeb.org and deb.sury.org have offered back ported versions of PHP built for stable, oldstable etc. From Buster (testing) it appears there will be multiple versions in the main repo (Buster currently has 7.0 and 7.1 packages)
Software Collections aren't part of the main repositories, they're an optional repository that can be enabled and have different guidelines for updates and new packages than the core repositories do. They're effectively divorced from the normal scrutiny and stability concerns that every package in the core RHEL repos has to go through, newer packages get pushed out faster as a result.
> It sounds like you just need packages built that allow for parallel installs of other versions of the same runtime/etc.
That's precisely what Software Collections do, they go one step further and isolate each runtime and require it be manually enabled for use (rhscl enable python3.5 `command goes here`) - there's no potential for the core system to be affected and you can layer different collections together if needed.
The second part sounds interesting - sounds vaguely like using a chroot, so the 'target' just knows to run python, not which specific version its going to run, for instance?
The vast majority of businesses aren't ever going to buy a red hat (or canonical) support contract. They're going to hire a Linux sysadmin to help them.
Commercial support has it's advantages, and it is why I do plan on switching all of our CentOS VM's to RHEL in the coming year (especially since we've chosen to adopt OpenShift after a PoC with the upstream release). Honestly, why would we NOT, it's ~$2000/yr per physical machine to have knowledge that engineers are available should something go wrong in a mission-critical deployment.
I would expect a sysadmin to do very basic troubleshooting, and if it's not a very quick fix, organise a new machine.
The sort of companies that will need to fix the issue on that box, rather than just replacing it, are the kind of companies that will buy a Red Hat support contract.
For most companies, it's probably not worth it.
Replacing hardware isn't always a solution, especially when it comes to specialized setups for databases, file storage, etc. Knowing your vendor has kernel engineers on staff that can tear through a kernel dump and get you a hotfix ASAP to test is important.
Startups may not care, smaller companies may not, but we're a medical billing company that has over 1,000 employees that need systems to be up - if they're down not only has work stopped but we're either paying employees for doing nothing or having to send them home unpaid (which makes THEM unhappy). Facebook having servers randomly kernel panicing affects their engineering team and causes small hiccups to their users (who don't pay them a dime), we have the productivity of our own employees and their livelihoods riding on the line.
Just wondering from a server point of view what's the difference.
Please forgive me asking you directly (others, feel free to jump in!) I can only find "use ubuntu if you're new, debian if not" with no real reason why
Ubuntu has always been about user-friendliness. I've never found the extraneous bits necessary for admin'ing a server from bash.
You can run `ubuntu-support-status` to determine what packages are currently supported.
Support status summary of 'acomputer':
You have 12 packages (0.8%) supported until January 2017 (9m)
Still a good over all indicator I suppose.
The package list (ie. apt cache) does not change after release. It cannot, because of mirror expectations and of course because it ends up on the images. Updates go through a separate updates pocket. Essentially the "Supported" field cannot be updated for all packages without issuing an update for all packages, which would require all users to download all packages again to get the new versions of each of them.
If "ubuntu-support-status" is telling you otherwise, that's a bug.
Packages in main are security supported by Canonical.
Packages in universe are security supported by anyone who wants to contribute acceptable fixes.
You can just basically search for "how to do x in ubuntu xx.xx" and get very helpful results, including solutions for Ubuntu desktop that are relevant to the server version.
Results may vary immensely with "how to do x in y", y being any other distro.
If that isn't a red flag to you, it should be.
Do you expect graphic designers also write SQL Stored Procedures, or DBA's to crank out PSD's?
Does your business/product manager moonlight as the head of security?
Are you saying you expect developers who don't know how to manage a server, to manage a server?
It's disappointing that in 2017 no Linux vendor ships with a default-denial Internet firewall configuration but I suppose stories like this explain why.
I don't believe that's accurate. On openSUSE and SLE you have SuSEFirewall2 which has such a configuration (from memory) and I would be surprised if RHEL doesn't have such a configuration.
You can also edit the URLS variable in that file, to point to more, or different sources of MOTD news.
(for anyone wondering, that's a comment on ethics)
What other distro is a competitor in this space? (I.e., not a minimalist distro, easy to use, with plenty of available software?) Fedora? Mint?