PSA: If you're running a HTTP/2 server like NGINX on the 14.04 LTS you'll want to upgrade to this release.
Google Chrome will no longer support HTTP/2 on vanilla 14.04 after May 15th [0], even if you're using the latest official upstream NGINX packages. This is because 14.04 ships with a version of OpenSSL that does not support the ALPN extension (prior to OpenSSL 1.0.2 you're limited to NPN, now deprecated). There was a bit of back-and-forth about the exact date, as the change was originally scheduled for earlier. However, Chrome decided to specifically push back the date so that there would be an Ubuntu LTS release available with the required support [1]. If you're still stuck on SPDY, that's going to be dropped too, so there's really no good reason not to simply use HTTP/2 at this point.
It looks like Ubuntu 16.04 comes with Nginx 1.9.15, which is both not the latest stable release (it's a development, aka MAINLINE, release, although Nginx development branch is pretty stable) and it's one minor version ahead of Nginx's own development PPA, which is at 1.9.14.
No, many people get this wrong. Mainline is stable, and http://hg.nginx.org/nginx/ is dev. The labeled stable version is for distros that have strict upgrade policies.
nginx recommends using mainline over stable: "We recommend that in general you deploy the NGINX mainline branch at all times." [1]
> It looks like Ubuntu 16.04 comes with Nginx 1.9.15, which is both not the latest stable release (it's a development, aka MAINLINE, release, although Nginx development branch is pretty stable)
The stable branch will fork from the mainline branch shortly. The version shipped in 16.04 is very close to what the stable will be, because the fork hadn't taken place before 16.04's release. I expect there to be very few changes, which is why (as someone else pointed out) we expect to update 16.04 to the stable branch as soon as it is available.
> The ppa[1] notes there's a newer version[2] also
That's just noting that the version released in 16.04 is newer than the version provided in the PPA.
> Nginx's own development PPA
Actually it's a PPA maintained by a team that care about Nginx's availability in Ubuntu. In this case, the uploads to that PPA were made by the very same person who looks after the official Ubuntu Nginx packages available to Ubuntu users by default.
That is correct, upgrades are not enabled between LTS releases at this time, also for servers AFAIK.
Either way, personally I would never upgrade a server in place these days. Treat your servers like cattle not pets: Rebuild from new base image, validate, put into LB/proxy, terminate old stack.
With OpenSSL's complete lack of anything resembling a stable ABI, and it's popularity, there is no meaningful difference between an OpenSSL upgrade and a wholesale OS upgrade.
Is http2 supported on xenial now? It wasn't as of beta1 -- http2 was considered 'experimental' and wasn't included in the builds. We're using the PPA instead.
My understanding is that HTTP2 support in Apache was held out of Xenial but may be included later.[0] nginx in Xenial does have HTTP/2 support but no SPDY.
Xenial seems to include nginx 1.9.15 and OpenSSL 1.0.2, so it should fully support HTTP/2. Personally I would still use the official upstream nginx packages.
1) If you use the nvidia drivers from the graphics-drivers PPA, starting the default non-root X server will hang with no graphics output. Installing xserver-xorg-legacy fixes this.
Yeah, we've seen similar issues with runC on point 2. I don't think it's an upstream kernel issue as it didn't happen on openSUSE Tumbleweed when we had 4.4 (we're on 4.5 now). So presumably it's some patch Ubuntu applies.
no new ubuntu release would be complete without graphics issues from Nvidia and AMD.
I say AMD too because FGLRX is out of 16.04.
After all the Issues i had with intel/amd/nvidia stiwching gpus in the ivy bridge days i just gave up buying nvidia and AMD, and boy has it made linux easier.
Friends don't let friends write shell scripts targeting bash.
For context: Bash is not available|installed everywhere, and has some inter-version weirdness.
Write clean, posix-compliant shell scripts (i.e. target /bin/sh commonly referred to as bourne shell) and you're in a much better position.
On Debian your script will be run by Dash, on OS X it will be run by Bash, on Ubuntu or RedHat it could be different again, but the point is, they are specifically running in POSIX mode, so that you get reliable, reproducible results across systems and even across Bash versions.
And test them on a shell that isn't bash. Even with the --posix option bash accepts non-standard bashisms, particularly the execrable 'extension' of '>&'.
You're getting downvoted to oblivion, but I'm old enough to remember not being able to take bash for granted. The default shell on some modern systems (OpenBSD for example) comes to mind as well. I feel this battle has mostly been lost, however.
Depends on the use case. There are cases where I don't know how I'd live without arrays/associative arrays. Performant regex matching is also quite nice.
This is pretty much the only reason I've been waiting for 16.04 – to get rid of upstart scripts and standardize on systemd. Still going to wait for a couple months while people iron out initial bugs but definitely excited about this release.
I wonder how big the installation of Amazon Linux is? They are still not on systemd. Also, CentOS 6 still has support for 4 more years so probably can't throw away all the bash yet.
Except upstart actually allowed shell code in its configuration files[1]. Now, it did have the "exec" stanza which was far cleaner, but if you look through what Ubuntu actually did in practice, I think you'll find quite a lot of "script" stanzas in there.
Say what you will about Canonical, their whimsical naming scheme has helped expand my vocabulary of both obscure African mammals and little-used adjectives.
Using binaries provided by Mozilla is not a good idea (unless they do things differently with the snaps). They are not hardened in any way; ie. no PIE (rendering ASLR pretty much useless), no stack canaries, no relro, ..., making it a lot easier to exploit any given sec-related bug.
$ hardening-check ./firefox
./firefox:
Position Independent Executable: no, normal executable!
Stack protected: no, not found!
Fortify Source functions: no, only unprotected functions found!
Read-only relocations: no, not found!
Immediate binding: no, not found!
Absolutely ridiculous given the amount of vulns likely to linger in its codebase.
It should also be noted that Firefox is one of the few packages that Canonical keeps aligned with Mozilla releases (even 12.04 LTS has the latest firefox), and:
More "innovations" which "justify" their own existence with novelty, but eliminate useful properties, backward compatibility, interoperability and standards with blissful ignorance. Standardization is a Good Thing(TM)... many formats creates a confusing dependency hell across multiple systems. Deb/apt works well. This will be deprecated in 6 months after a major security incident. Canonical is mismanaged and capricious, and this is just another in a long line of examples.
What is the significance of this? Doesn't Canonical already update the package (lagging a day or two behind the official release) for the lifetime of the Ubuntu version?
I'd guess that Firefox is a fairly good candidate for this kind of packaging just because it has relatively few external dependencies, and lots of Mozilla-specific dependencies which are rarely used by other software
> Online searches in the dash are now disabled by default [1]
A welcome and saner default. I'm thinking of moving back to Ubuntu from LinuxMint (I was thinking of Arch as well but not too confident of being on the bleeding edge).
As someone who has used Arch for 4 years, the bleeding edge got boring. I haven't had a major breakage in at least a year, probably longer, unless you count KDE 4 -> 5 being a breakage - one any 14.04 to 16.04 upgrader will also have to contend with.
The last major show stopper I can recall was when Arch dropped security hooks from the kernel and I had to get rid of my MAC.
All my experiences running mint have amounted to a broken and out of date distribution which has poor hardware support. I hope it has become better wince those days (i believe it was the initial release of MATE) but I see no reason to use mint when you know enough about a Debian based distro to pick and choose what you really want.
I never moved to mint, but I did recommend trying it to some people who really didn't like unity. I pretty much stopped doing that when they had the security issues last year. Is that what is prompting you to look at switching back, or are you just more reconciled to unity in general now?
That is one and I read online (can't find the source now) that Mint development doesn't respect compatibility/play well with other open source developers. I don't know how much of it is true but for me, compatibility is important. For almost 5-6 years, I have never formatted my home directory. So if my distribution is, for example, creating config in a non-compatible fashion, I won't be able to move to another distro. I know that typically distros don't modify individual program's dotfile/config etc but I guess I'm a bit paranoid about it.
Readit News
Google Chrome will no longer support HTTP/2 on vanilla 14.04 after May 15th [0], even if you're using the latest official upstream NGINX packages. This is because 14.04 ships with a version of OpenSSL that does not support the ALPN extension (prior to OpenSSL 1.0.2 you're limited to NPN, now deprecated). There was a bit of back-and-forth about the exact date, as the change was originally scheduled for earlier. However, Chrome decided to specifically push back the date so that there would be an Ubuntu LTS release available with the required support [1]. If you're still stuck on SPDY, that's going to be dropped too, so there's really no good reason not to simply use HTTP/2 at this point.
[0] http://blog.chromium.org/2016/02/transitioning-from-spdy-to-...
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=557197
The ppa[1] notes there's a newer version[2] also
[1] https://launchpad.net/~nginx/+archive/ubuntu/development [2] https://launchpad.net/ubuntu/+source/nginx/1.9.15-0ubuntu1
nginx recommends using mainline over stable: "We recommend that in general you deploy the NGINX mainline branch at all times." [1]
[1]: https://www.nginx.com/blog/nginx-1-6-1-7-released/
The stable branch will fork from the mainline branch shortly. The version shipped in 16.04 is very close to what the stable will be, because the fork hadn't taken place before 16.04's release. I expect there to be very few changes, which is why (as someone else pointed out) we expect to update 16.04 to the stable branch as soon as it is available.
> The ppa[1] notes there's a newer version[2] also
That's just noting that the version released in 16.04 is newer than the version provided in the PPA.
> Nginx's own development PPA
Actually it's a PPA maintained by a team that care about Nginx's availability in Ubuntu. In this case, the uploads to that PPA were made by the very same person who looks after the official Ubuntu Nginx packages available to Ubuntu users by default.
Is this outdated or not applicable to servers?
Either way, personally I would never upgrade a server in place these days. Treat your servers like cattle not pets: Rebuild from new base image, validate, put into LB/proxy, terminate old stack.
However, you can also "upgrade" your stack by building a new image using 16.04 from scratch, and that doesn't need to wait until 16.04.1.
http://nginx.org/en/linux_packages.html
http://caniuse.com/#feat=spdy (77.39% global)
http://caniuse.com/#feat=http2 (70.15% global)
[0] https://wiki.ubuntu.com/XenialXerus/ReleaseNotes#HTTP.2F2_su...
Doe this mean 14.04 with Apache 2.2 is affected? Their blog doesnt explain and leave plenty of people confused...
1) If you use the nvidia drivers from the graphics-drivers PPA, starting the default non-root X server will hang with no graphics output. Installing xserver-xorg-legacy fixes this.
2) LXC+Linux 4.4 seems to be very broken: https://github.com/lxc/lxd/issues/1666#issuecomment-21290311...
3) Pulseaudio now uses shared memory and playing audio inside a firejail will break the pulseaudio server: https://github.com/netblue30/firejail/issues/69#issuecomment...
Seeing as my main use for my current 14.04 install is LXC containers, I think I will hold off a little then.
Thanks for the warning :)
After all the Issues i had with intel/amd/nvidia stiwching gpus in the ivy bridge days i just gave up buying nvidia and AMD, and boy has it made linux easier.
No need for bash scripts, custom watchdog and daemonise tools, etc.
Friends don't let friends write shell scripts targeting bash.
For context: Bash is not available|installed everywhere, and has some inter-version weirdness.
Write clean, posix-compliant shell scripts (i.e. target /bin/sh commonly referred to as bourne shell) and you're in a much better position.
On Debian your script will be run by Dash, on OS X it will be run by Bash, on Ubuntu or RedHat it could be different again, but the point is, they are specifically running in POSIX mode, so that you get reliable, reproducible results across systems and even across Bash versions.
Can you cite some sources here? No one knows what you're talking about.
https://www.freedesktop.org/software/systemd/man/systemd.ser...
There's going to be a 16.04.1 release just 3 months away from the initial LTS release; I believe it is just for that.
https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule - this schedule is for 14.04, but I believe it's been the same for quite a few years already.
For that matter, Ubuntu 14.04 is still supported for another two years, and that's still upstart.
The big deal now is that all the major distributions support the same mechanism.
[1] http://upstart.ubuntu.com/cookbook/#script
Afflicted Ass?
https://blog.mozilla.org/futurereleases/2016/04/21/firefox-d...
It should also be noted that Firefox is one of the few packages that Canonical keeps aligned with Mozilla releases (even 12.04 LTS has the latest firefox), and:
[0]: https://insights.ubuntu.com/2015/08/17/ibm-and-canonical-pla...
[1]: https://help.ubuntu.com/16.04/installation-guide/s390x/
A welcome and saner default. I'm thinking of moving back to Ubuntu from LinuxMint (I was thinking of Arch as well but not too confident of being on the bleeding edge).
[1]: https://wiki.ubuntu.com/XenialXerus/ReleaseNotes
The last major show stopper I can recall was when Arch dropped security hooks from the kernel and I had to get rid of my MAC.
https://ubuntugnome.org/
Always worth a read before you fire up the installer...