Instead, https://motd.ubuntu.com should show relevant items to those that use Ubuntu Server (relevant security issues, etc), instead of items for desktop users.
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"?
Reading the bug report, this did lead me to wonder what happens when one tries to log in to an Ubuntu server which is behind a firewall and without internet access. Does this nonsense cause a timeout delay in getting into the box ?
Howdy! I'm the author of the code in question, a bug in said code, and the fix to the bug in the code :-)
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.
- 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.
Good for them. Ubuntu does lots of good work that benefit the whole community, and if this allows them to stay in business, and pay people well to write open-source software, I'm not complaining.
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.
I don't think that the advertisement itself is the issue, but rather the medium chosen for it.
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.
It still baffles me why people choose Ubuntu for a server.
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.
I used to use Debian, and Gentoo before that. I still remember spending days trying to get a somewhat recent version of php to compile on these systems.
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.
Debian has the problem that its packages are older, so if you need specific versions of PHP or other runtimes, you are much better off using Ubuntu. It's worth noting that Debian can be made to support PPAs as well, but all this is native to 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.
The main issue is trying to use the distro packages for dependencies of the things you'll actually use the server for.
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.
Agreed. Package managers are OK for a lay user, but if you actually want to run code in production you're better off with a reproducible and isolated environment you created yourself.
Updated php builds are available from https://deb.sury.org - they're available for both Debian and Ubuntu. The operator of that repo is also a Debian maintainer, so they follow the same practices.
For nodejs you're better off using a vendor like nodesource regardless of your distro.
> Debian has the problem that its packages are older, so if you need specific versions of PHP or other runtimes, you are much better off using Ubuntu.
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)
> Installed via something other than rpms? Installed from non-official rpm repos?
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 first part sounds like it's solved by a combination of the $release-backports repo, and vendor repos.
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?
There are people who need to operate linux servers without great familiarity with any of them, Ubuntu just seems to have a much greater available knowledge base.
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.
The worst part of LTS is that it only applies to the OS itself. Security updates for applications actually running on it (e.g. Apache) expire after a considerably shorter period of time. We found this out after an internal vote between Ubuntu and CentOS. We'd have picked the latter if we'd known.
You can run `ubuntu-support-status` to determine what packages are currently supported.
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.
Because it works out of the box. Ubuntu is a great system for people who want to use Linux to do their work, as opposed to working on Linux. I.e. developers, not sysadmins.
Until recently, Ubuntu had a much better story around long term support releases than Debian did. Debian averaged 3 years of support, Ubuntu offered 5. That has changed with Debian's support of LTS in one of the recent distros.
As someone that's always used CentOS for servers until recently when software choices have forced the hand to ubuntu - what do you get with ubuntu that you don't with debian?
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
I've never quite understood this for anyone but the biggest companies.
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.
A sysadmin isn't going to be troubleshooting kernel panics that suddenly started happening on a production system, or why a new version of libfoo without a soname bump is causing service xyz to segfault.
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.
> A sysadmin isn't going to be troubleshooting kernel panics
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.
Let's take this example: Kernel update with security fix gets pushed out, said fix ended up causing issues with a network card or some other component and causes panics. Can a sysadmin revert to previous kernel revision? Sure. Should they have to do so, submit a bug and pray someone pays attention to it? I don't think that's a great idea.
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.
Debian stable with the backports repo and/or vendor repos as required for more recent releases e.g. php, nodejs, varnish, mysql/percona/mariadb, postgres etc.
Off Topic. I find it funny that you would have a hard time watching "HBO's Silicon Valley" on an Ubuntu machine legally. HBO still uses flash based DRM.
At the same time, it's considered poor practise to give servers open internet access. The only outgoing connections that should be allowed are to update servers. I'd second disabling this 'feature' on a server - it seems very unnecessary to get a MOTD from the internet in the first place, let alone if there's going to be advertising in it.
And updates are ideally pulled from a local cache so that only one server in the DMZ needs to connect to Ubuntu's 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.
> 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.
That's exactly right! Think of it, like Google's doodle that sometimes appears above the search bar. Interesting, fun facts, that likely have nothing to do with what you're Googling ;-)
Ubuntu as an end-user OS is fine, this discussion is specifically for servers. I personally use Mint though, purely for the Cinnamon GUI. Mint is basically Ubuntu underneath so there's no reason to switch.
Now this is either poor marketing or poor taste. They tried with desktop with Amazon applets now /etc/motd for server guys. This is really bad for ubuntu
Then you apparently don't work on PCI grade machines. Many particular industry security standards dictate you put a 'if you are not authorised disconnect now' message in the motd.
AFAIK the theory is that it helps with prosecution - if they got this prompt they clearly were told where they are and that they are not welcome and can't try to excuse themselves through some mistake or not knowing that they shouldn't access.
To be a bit pedantic: I would expect that kind of message to be put in /etc/issue so it is shown before login. /etc/motd is only shown after a successful login, which is a bit late for such a warning.
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"?