From teward at trekweb.org Fri Jun 12 16:54:03 2015 From: teward at trekweb.org (Thomas Ward) Date: Fri, 12 Jun 2015 12:54:03 -0400 Subject: NGINX in Ubuntu: Course of Action - Opinions Please Message-ID: <557B0EAB.6020804@trekweb.org> All: So, we're in the Wily development schedule. Now would be a perfect time to be merging in NGINX from Debian since they released an update. However, due to what they've actually uploaded, I want additional opinions. As most are aware, NGINX in Ubuntu has a binary package now included in main, nginx-core, which has been in Main since 14.04. As such, it gets security updates, and could be included in the images if we so chose. We also have me providing bugfixes as I can, with my having upload privileges to upload direct and then loop in the SRU/Release team. The version of NGINX in Vivid (and Wily) is the NGINX stable 1.6.x branch of releases. What many may not be aware of, however, is that on April 21, 2015, the 1.6.x branch was deprecated, and is no longer supported by upstream. It was replaced by the NGINX 1.8.x stable branch, which is based off of the previous 1.7.x mainline branch, but is now stable. The mainline version was replaced with 1.9.x (currently 1.9.1). As Debian does, sometimes to my chagrin, they have 'switched' briefly to the Mainline branch and packaged 1.9.1 for Debian Unstable, which I'm told is something they do between releases of Debian. Unfortunately, that puts me in a very difficult position of having to decide the course of action for the future of the NGINX package in Ubuntu, specifically whether we continue to use Debian's packaging or use a separate Stable packaging from me, and I don't feel immediately qualified to make that decision on my own. >From understanding of how Ubuntu handles releases, it's preferred to stay on 'stable' branches of software rather than rely on an in-development, new-features-available-each-update like branch for the software. Debian packages NGINX 1.9.x, which adds some complexity to my decision. While NGINX 1.8.x has all the features from NGINX 1.7.x (which has many new features not present in the 1.6.x branch), 1.9.x has many more features but is more 'actively developed', which leads to additional bugs. The following is the response I was able to get from the NGINX Product Manager on this, where I asked specifically about the release handling process of nginx, as well as a general description of projected next-major-version releases, as well as current development plans for 1.9.x and such: --- "The mainline release is our new-feature development stream, carrying an odd-numbered minor version. In parallel, we maintain a ?stable? release with a lower even-numbered minor version. For example, the current mainline release is 1.9.x, and the stable release (1.8.x) was forked from this in April (http://nginx.com/blog/nginx-1-8-and-1-9-released/). Stable will be supported for one year, and will receive critical bug and security updates only. Every year, typically in April, we do the following: * End support for the current stable release * Branch the current mainline release to create the next annual stable release * Update the version number in the current mainline release to create the next annual mainline release There?s a description of the process here: http://nginx.com/blog/nginx-1-6-1-7-released/ In April 2016, we are likely then to release 1.10.x (stable) and 1.11.x (mainline) (or possibly 2.0.x and 2.1.x - we have not decided) New features planned for the mainline release in 2015/16 include support for HTTP/2 and a new dynamic modules architecture." --- Currently, I maintain the NGINX PPAs (see https://launchpad.net/~nginx), with both 1.8.x and 1.9.x branches in separate PPAs (1.9.x is pending a third party module actually providing an update to the module as a point release so we don't pull git head from them), and am comfortable enough with the system there to provide support for either and to package them, even if we package 1.8.x by hand and directly upload to the repositories and ignore merges in the interim, and just import changes from Debian case by case until they go back to the Stable branch of NGINX. However, as I said above, I need more discussion points on this, and more advice and input. The consideration point for this is a huge one, as it likely impacts both Wily now, and likely the next LTS (16.04). If we go NGINX Mainline, we must support 1.9.x and many new additionally developed features for both Wily, and likely the next LTS (16.04). We must also handle bugs that come from those additional features, some of which we won't easily be able to resolve. And as we know, an actively-developed branch is not necessarily the most stable. If we go NGINX Stable, we must manually build the package of 1.8.x, and nitpick Debian's changes on a case by case basis, and upstream fixes for security bugs and such. (I am comfortable enough building the package and updating the third party modules in the Universe-pocket binaries for code differences to build packages and manually upload them, as I have a 1.8.x code base in the PPA already that mirrors Debian's packaging, with some minor changes, and introducing the Ubuntu delta back in will not be exceedingly difficult.) So, that's the issue at hand. Note that I have put this item onto the Server Team's agenda, as I would like the server team's input on this with regards to making the long term decision, and I will not be choosing any hard option until the Ubuntu Server Team meeting on Tuesday. Please discuss, and let's see if we can come up with a decision that we can all live with. Thomas From seth.arnold at canonical.com Sat Jun 13 05:22:57 2015 From: seth.arnold at canonical.com (Seth Arnold) Date: Fri, 12 Jun 2015 22:22:57 -0700 Subject: NGINX in Ubuntu: Course of Action - Opinions Please In-Reply-To: <557B0EAB.6020804@trekweb.org> References: <557B0EAB.6020804@trekweb.org> Message-ID: <20150613052256.GA16928@hunt> On Fri, Jun 12, 2015 at 12:54:03PM -0400, Thomas Ward wrote: > If we go NGINX Mainline, we must support 1.9.x and many new additionally > developed features for both Wily, and likely the next LTS (16.04). We > must also handle bugs that come from those additional features, some of > which we won't easily be able to resolve. And as we know, an > actively-developed branch is not necessarily the most stable. I think following Debian and importing 1.9.x makes sense: - it's traditional - it'll provide some bugreports to nginx from enthusiast users - it'll provide us with knowledge of what's coming in (hypothetical) 1.10 before 16.04 LTS Going with 1.9.x now does run the risk that we'll be "stuck" with it for 16.04 LTS rather than 1.10. Hopefully it'll just be a few small changes away from the 1.10 that nginx is planning on releasing in April. (If we're lucky we might even get them to aim for an early-enough release that 1.10 can be included in 16.04 LTS.) But I think being "stuck" with 1.8.x in 16.04 LTS isn't a great position to be in -- people will want the new features -- probably better http/2.0, generic tcp loadbalancing, SO_REUSEPORT, etc. And I don't think 1.8.x will be a significant improvement in security either -- on the one hand, it will have received a year's scrutiny and updates, on the other hand, all the patches will be one year and a development cycle behind. I think on the whole the balance suggests moving to 1.9.x sooner. Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From cp at axs.org Sun Jun 21 20:54:30 2015 From: cp at axs.org (Chuck Peters) Date: Sun, 21 Jun 2015 20:54:30 +0000 Subject: Please backport fix to Exim4: [Bug 1384232] Re: Certificate hostname verification fix Message-ID: <20150621205430.GA22878@xen.axs.org> Andreas Metzler pointed to a set of patches which are included in the upcoming release of Exim4. I would like to see this issue resolved for trusty and newer releases. Is someone from the Server Team, or Security Team, backporting this set of patches? If so, will we see a backport for trusty? Perhaps this issue could be discussed at the next Security Team meeting Monday or Server Team meeting Tuesday? Thanks, Chuck ----- Forwarded message from Andreas Metzler <1384232 at bugs.launchpad.net> ----- Date: Sun, 21 Jun 2015 05:33:47 -0000 From: Andreas Metzler <1384232 at bugs.launchpad.net> To: cp at axs.org Subject: [Bug 1384232] Re: Certificate hostname verification fix This seems to be enabled by default in 4.86RC. http://git.exim.org/exim.git/commit/01a4a5c5cbaa40ca618d3e233991ce183b551477 -- You received this bug notification because you are subscribed to exim4 in Ubuntu. Matching subscriptions: Chuck Peters https://bugs.launchpad.net/bugs/1384232 Title: Certificate hostname verification fix Status in exim4 package in Ubuntu: Confirmed Bug description: We did a automatic static analysis on exim4 packages in Ubuntu and found that EXIM will not verify the hostname of a SMTP server against its certificate. This will possibly result in man-in-the-middle attack. We reported this bug directly to exim.org in May 2014 and they fixed this problem in their latest release. So plz fix this issue in Ubuntu. Bug: http://bugs.exim.org/show_bug.cgi?id=1479 Fix: http://git.exim.org/exim.git/commit/e51c7be22dfccad376659a1a46cee93c9979bbf7 ----- End forwarded message ----- From robie.basak at ubuntu.com Mon Jun 22 10:14:57 2015 From: robie.basak at ubuntu.com (Robie Basak) Date: Mon, 22 Jun 2015 11:14:57 +0100 Subject: Please backport fix to Exim4: [Bug 1384232] Re: Certificate hostname verification fix In-Reply-To: <20150621205430.GA22878@xen.axs.org> References: <20150621205430.GA22878@xen.axs.org> Message-ID: <20150622101457.GA22443@mal.justgohome.co.uk> Hi Chuck, On Sun, Jun 21, 2015 at 08:54:30PM +0000, Chuck Peters wrote: > Andreas Metzler pointed to a set of patches which are included in the > upcoming release of Exim4. I would like to see this issue resolved > for trusty and newer releases. Thank you for bringing this bug to our attention. I've stated my opinion in the bug itself. > Is someone from the Server Team, or Security Team, backporting this > set of patches? I don't believe so. > If so, will we see a backport for trusty? I don't think so, but discussion welcome. > Perhaps this issue could be discussed at the next Security Team > meeting Monday or Server Team meeting Tuesday? I suggest that we discuss options for this feature in the bug itself so the discussion stays in one place. But if there's anything that requires a decision, please feel free to take it to the server team meeting. Robie -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From alex.moldovan at canonical.com Mon Jun 22 16:07:05 2015 From: alex.moldovan at canonical.com (Alex Moldovan) Date: Mon, 22 Jun 2015 12:07:05 -0400 Subject: How to fix the problem when the disk is full while running apt-get? In-Reply-To: References: Message-ID: After removing older kernels, you can also delete their respective folders in: /usr/src/ Alex M. On Mon, May 25, 2015 at 11:20 AM, Alex Muntada wrote: > Peng Yu: > > The following packages were automatically installed and are no longer >> required: >> linux-headers-3.13.0-27 linux-headers-3.13.0-27-generic >> linux-headers-3.13.0-29 linux-headers-3.13.0-29-generic >> linux-headers-3.13.0-30 linux-headers-3.13.0-30-generic >> linux-headers-3.13.0-32 linux-headers-3.13.0-32-generic >> linux-headers-3.13.0-34 linux-image-3.11.0-20-generic >> linux-image-3.13.0-27-generic linux-image-3.13.0-29-generic >> linux-image-3.13.0-30-generic linux-image-3.13.0-32-generic >> linux-image-3.13.0-34-generic linux-image-extra-3.11.0-20-generic >> linux-image-extra-3.13.0-27-generic linux-image-extra-3.13.0-29-generic >> linux-image-extra-3.13.0-30-generic linux-image-extra-3.13.0-32-generic >> linux-image-extra-3.13.0-34-generic >> Use 'apt-get autoremove' to remove them. >> > > That means that you can safely remove the no longer needed headers and > kernels, which usually take a lot of space and inodes. Just run the > suggested 'apt-get autoremove' and later try to fix the broken packages > running 'apt-get install -f' as already suggested. > > Cheers, > Alex > > -- > ubuntu-server mailing list > ubuntu-server at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-server > More info: https://wiki.ubuntu.com/ServerTeam > -- Alex Moldovan, Ubuntu Support Analyst Canonical Corporate Services, Montreal, QC, Canada Ubuntu support -------------- next part -------------- An HTML attachment was scrubbed... URL: From robie.basak at ubuntu.com Tue Jun 23 09:50:05 2015 From: robie.basak at ubuntu.com (Robie Basak) Date: Tue, 23 Jun 2015 10:50:05 +0100 Subject: nginx exception request In-Reply-To: <20150613052256.GA16928@hunt> References: <557B0EAB.6020804@trekweb.org> <20150613052256.GA16928@hunt> Message-ID: <20150623095005.GF22443@mal.justgohome.co.uk> Dear Release Team, We (server team) would like to discuss some kind of one-off feature freeze and/or SRU exception for nginx that we expect to want to land either after feature freeze for X or shortly after it is released. I think the situation is similar to what we do for Openstack - that we expect an upstream final release around the time of our own release, so we want to follow upstream closely with updates after our own feature freeze and possibly shortly after our own release. However, in nginx's case there is no upstream feature freeze until their actual final "release" as they start their 1.10 series, so it is possible that we will end up introducing new features during X feature freeze or even shortly after X is released. Previous discussions: ubuntu-server ML[1] ubuntu-server IRC meeting[2] Please note that nginx use an odd-development/even-stable version numbering scheme which I think is quite similar to the old Linux versioning scheme. 1.9 (development/"mainline") has recently opened, and Debian are currently following 1.9 in unstable. 1.10 (stable) is expected in April 2016. Option A: we think that what we want to do in Ubuntu is merge 1.9 from Debian, follow it through while X is in development, and move to 1.10 in X (via x-updates if necessary) as soon as 1.10 is released in April 2016. This will result in LTS users on X getting the upstream nginx stable branch. However, this may involve some late or post-release feature bumps in X that violate the usual feature freeze and SRU policies. Option B: the alternative would be to diverge from Debian, maintain 1.8 (the current nginx stable version as of this message) directly from upstream, and release X with 1.8. However this will result in limited support from upstream as they will drop maintenance for the 1.8 series almost immediately as 1.10 is opened around the same time as X is released, and users will end up with a particularly old nginx for the LTS duration. If we want to execute option B, then ideally we need to decide this now so that we don't have to regress users back from 1.9 to 1.8 in future. We think option A fits better with the needs of nginx users, but welcome further discussion. Please can we agree on feature freeze and SRU policy exceptions so that we can execute option A, or otherwise discuss alternatives? Thanks, Robie Basak and Thomas Ward Ubuntu Server Team [1] https://lists.ubuntu.com/archives/ubuntu-server/2015-June/007072.html [2] http://irclogs.ubuntu.com/2015/06/16/%23ubuntu-meeting.html#t16:20 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From serge.hallyn at ubuntu.com Tue Jun 23 16:38:01 2015 From: serge.hallyn at ubuntu.com (Serge Hallyn) Date: Tue, 23 Jun 2015 16:38:01 +0000 Subject: Server team 20150623 meeting minutes Message-ID: <20150623163801.GB10331@ubuntumail> ==== Review ACTION points from previous meeting ==== Two action items were completed, one was apparently invalid. ==== W Development ==== Of the two high priority server bugs, one was already fixed, and one is deemed pretty easy - smoser will triage. ==== Kernel Updates ==== Arges is debugging a kernel bug impacting nested kvm. ==== Open Discussion ==== An "Upcoming CFP" section is being added to the meeting, since often "upcoming server events" are past CFP before they are brought up here. Everyone is encouraged to mention here any events for which they are considering submitting a paper in the next two weeks. ==== Agree on next meeting date and time ==== Next meeting will be on Tuesday, June 30th at 16:00 UTC in #ubuntu-meeting. The full notes with irc logs can also be found at https://wiki.ubuntu.com/MeetingLogs/Server/20150623 From robie.basak at ubuntu.com Tue Jun 30 10:08:59 2015 From: robie.basak at ubuntu.com (Robie Basak) Date: Tue, 30 Jun 2015 11:08:59 +0100 Subject: nginx exception request In-Reply-To: <20150623095005.GF22443@mal.justgohome.co.uk> References: <557B0EAB.6020804@trekweb.org> <20150613052256.GA16928@hunt> <20150623095005.GF22443@mal.justgohome.co.uk> Message-ID: <20150630100859.GB4062@mal.justgohome.co.uk> On Tue, Jun 23, 2015 at 10:50:05AM +0100, Robie Basak wrote: > Please can we agree on feature freeze and SRU policy exceptions so that > we can execute option A, or otherwise discuss alternatives? Any thoughts please? Although we'd not execute on any exception until 2016, Thomas needs to know now whether to merge 1.9 from Debian or diverge on 1.8 for Wily. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From teward at trekweb.org Tue Jun 30 14:55:10 2015 From: teward at trekweb.org (Thomas Ward) Date: Tue, 30 Jun 2015 10:55:10 -0400 Subject: nginx exception request In-Reply-To: <20150630100859.GB4062@mal.justgohome.co.uk> References: <557B0EAB.6020804@trekweb.org> <20150613052256.GA16928@hunt> <20150623095005.GF22443@mal.justgohome.co.uk> <20150630100859.GB4062@mal.justgohome.co.uk> Message-ID: <5592ADCE.10800@trekweb.org> On 06/30/2015 06:08 AM, Robie Basak wrote: > On Tue, Jun 23, 2015 at 10:50:05AM +0100, Robie Basak wrote: >> Please can we agree on feature freeze and SRU policy exceptions so that >> we can execute option A, or otherwise discuss alternatives? > > Any thoughts please? Although we'd not execute on any exception until > 2016, Thomas needs to know now whether to merge 1.9 from Debian or > diverge on 1.8 for Wily. There is also another option that is likely less desirable than the other aforementioned options in the previous emails in this chain by Robie: We (or rather, I) could do absolutely nothing for Wily, and we can ultimately just deal with this closer to 16.04, such that we can have this discussion for a longer period of time. By doing nothing, 1.6.x will remain in Ubuntu for the duration of Wily. Features from 1.7.x which are now present in 1.8.x (nginx stable) will not exist in Ubuntu Wily, and even newer features (and to my chagrin, the "Disable SSLv3 By Default" change at the source code level) from 1.9.x will not exist in Ubuntu Wily either. This option allows us on the Server Team, and myself, to not have to immediately worry about merging, while users who want the newer features in 1.8.x and 1.9.x can simply use the already-existing NGINX PPAs that I maintain which package both NGINX versions for all supported Ubuntu releases. While input from the Release team is sought for Wily, so we can try and have less of a merge delta by 16.04, we can theoretically do nothing now for Wily, and then go with 1.9.x in 16.04, and then focus on the one-off policy exceptions or potential other alternatives then, rather than require the release team's input immediately. However, I believe it is a better option to consider 1.8.x or 1.9.x now for Wily rather than do nothing. ------ Thomas Ward