Hi,
How is the core SIG looking at improving and speeding up (more than one person) builds of updates? As I see it the longer the time between vendor release and CentOS release people know that we are hittable if they have a viable exploit?
I ask this as I see that the core SIG is not concentrating on the job at hand and concentrating on the work of their new masters - Red Hats CentOS? Their heads are in the cloud. ;-)
Regards
Phil
On 15/12/16 23:43, Phil Wyett wrote:
Hi,
How is the core SIG looking at improving and speeding up (more than one person) builds of updates? As I see it the longer the time between vendor release and CentOS release people know that we are hittable if they have a viable exploit?
I ask this as I see that the core SIG is not concentrating on the job at hand and concentrating on the work of their new masters - Red Hats CentOS? Their heads are in the cloud. ;-)
unsure if this is a troll post or you actually meant to raise tangiable concerns ?
On 16/12/16 10:37, Karanbir Singh wrote:
On 15/12/16 23:43, Phil Wyett wrote:
Hi,
How is the core SIG looking at improving and speeding up (more than one person) builds of updates? As I see it the longer the time between vendor release and CentOS release people know that we are hittable if they have a viable exploit?
I ask this as I see that the core SIG is not concentrating on the job at hand and concentrating on the work of their new masters - Red Hats CentOS? Their heads are in the cloud. ;-)
unsure if this is a troll post or you actually meant to raise tangiable concerns ?
I am in complete agreement.
7.3.1611 took 39 days from the upstream release which is 2 weeks longer than the previous el7 drops.
The latest https://rhn.redhat.com/errata/RHSA-2016-2946.html which is a critical update for firefox released on the 14th is still not released for CentOS 7 after 2 days.
It appears the core team have lost focus on what's important. The SIG stuff should be peripheral. The altarch stuff should be peripheral. Concentrate on what's important - it's the DISTRO. The rest of it may be nice to have but the important part is the core of the distro. Anything else is just distraction.
Trevor
On 16/12/16 10:49, Trevor Hemsley wrote:
7.3.1611 took 39 days from the upstream release which is 2 weeks longer than the previous el7 drops.
I am going to try and work this out - plan on doing a better teardown and work through the issues early Jan once this release has settled. We got a few things right, a couple of things went sideways. But I agree, we should aim to turn around a major release in 15 days or less.
The latest https://rhn.redhat.com/errata/RHSA-2016-2946.html which is a critical update for firefox released on the 14th is still not released for CentOS 7 after 2 days.
It appears the core team have lost focus on what's important. The SIG stuff should be peripheral. The altarch stuff should be peripheral. Concentrate on what's important - it's the DISTRO. The rest of it may be nice to have but the important part is the core of the distro. Anything else is just distraction.
I strongly disagree. The overall ecosystem is important and key to the distro as well. For tangible issues, like the distro taking xx days - is something we can work on and try to fix, but lets not get carried away and declare blame based on a limited view on what is going on.
regards,
On 16/12/16 12:08, Karanbir Singh wrote:
On 16/12/16 10:49, Trevor Hemsley wrote:
7.3.1611 took 39 days from the upstream release which is 2 weeks longer than the previous el7 drops.
I am going to try and work this out - plan on doing a better teardown and work through the issues early Jan once this release has settled. We got a few things right, a couple of things went sideways. But I agree, we should aim to turn around a major release in 15 days or less.
I'm pretty new to CentOS: since only the last official release is supported, does this mean that users get no security updates at all during the time frame between Red Hat's official RHEL 7.3 release and the availability of our rebuild? Something like 15 days ideally, or 39 days in this particular instance? If this is true, perhaps we should enable the CR repo by default, at the risk of stuff breaking?
During the normal lifetime of a point release, security updates normally become available 24-72 hours after Red Hat publishes the fixes - has that changed recently?
Another issue with security updates is how long it sometimes takes for them to arrive in our SCL repositories. In one case, there was a delay of 4 months for PHP[1] and I also remember a critical fix for Python 3 taking several weeks. Couldn't we get some sort of notification on new commits in Red Hat's public repo?
[1] https://www.redhat.com/archives/sclorg/2014-November/msg00008.html [2] https://www.redhat.com/archives/sclorg/2014-November/msg00005.html
The latest https://rhn.redhat.com/errata/RHSA-2016-2946.html which is a critical update for firefox released on the 14th is still not released for CentOS 7 after 2 days.
The original advisory[3] for Firefox 50.1 lists a few more CVEs than Red Hat's bulletin (the critical security fixes are backported by Mozilla in the ESR version "where feasible", which is why the Canonical Security Team decided to offer the normal Firefox releases in Ubuntu LTS, not the ESR ones). [4]
[3] https://www.mozilla.org/en-US/security/advisories/mfsa2016-94/ [4] http://www.chriscoulson.me.uk/blog/?p=111
Best regards, Laurențiu
On 16/12/16 13:12, Laurentiu Pancescu wrote:
I'm pretty new to CentOS: since only the last official release is supported, does this mean that users get no security updates at all during the time frame between Red Hat's official RHEL 7.3 release and the availability of our rebuild? Something like 15 days ideally, or 39 days in this particular instance? If this is true, perhaps we should enable the CR repo by default, at the risk of stuff breaking?
the CR repo will typically see content at point release time fairly quickly. Through the life of the release, security updates are released within 24 hrs. The avg time in the last 12 months has been less than 18 hrs or so.
the CR model is perhaps something we need to reconsider a bit - there is wider impact than just the distro; eg. the SIGs needed to line up content and we tried to work with the ci infra and the cbs infra to get something like a sync release out - and it didnt work out as planned. When we did not do this last time, we also had impact - just that this time it was different. And we should have that conversation, build the model and the automation required around it - and get better next time.
The 15 day point is for the distro content turnaround. To me, that means any existing user should be able to yum update to the new content - not always mapping to the ISO media itself.
During the normal lifetime of a point release, security updates normally become available 24-72 hours after Red Hat publishes the fixes - has that changed recently?
Its only gotten better.
Another issue with security updates is how long it sometimes takes for them to arrive in our SCL repositories. In one case, there was a delay of 4 months for PHP[1] and I also remember a critical fix for Python 3 taking several weeks. Couldn't we get some sort of notification on new commits in Red Hat's public repo?
[1] https://www.redhat.com/archives/sclorg/2014-November/msg00008.html [2] https://www.redhat.com/archives/sclorg/2014-November/msg00005.html
This is really something to work with the SCLo SIG around, maybe we can do some automation and help with testing in someway to try and improve that delta ?
The latest https://rhn.redhat.com/errata/RHSA-2016-2946.html which is a critical update for firefox released on the 14th is still not released for CentOS 7 after 2 days.
The original advisory[3] for Firefox 50.1 lists a few more CVEs than Red Hat's bulletin (the critical security fixes are backported by Mozilla in the ESR version "where feasible", which is why the Canonical Security Team decided to offer the normal Firefox releases in Ubuntu LTS, not the ESR ones). [4]
[3] https://www.mozilla.org/en-US/security/advisories/mfsa2016-94/ [4] http://www.chriscoulson.me.uk/blog/?p=111
On 12/16/2016 07:12 AM, Laurentiu Pancescu wrote:
On 16/12/16 12:08, Karanbir Singh wrote:
On 16/12/16 10:49, Trevor Hemsley wrote:
7.3.1611 took 39 days from the upstream release which is 2 weeks longer than the previous el7 drops.
I am going to try and work this out - plan on doing a better teardown and work through the issues early Jan once this release has settled. We got a few things right, a couple of things went sideways. But I agree, we should aim to turn around a major release in 15 days or less.
I'm pretty new to CentOS: since only the last official release is supported, does this mean that users get no security updates at all during the time frame between Red Hat's official RHEL 7.3 release and the availability of our rebuild? Something like 15 days ideally, or 39 days in this particular instance? If this is true, perhaps we should enable the CR repo by default, at the risk of stuff breaking?
We don't get to look at source code before release of RHEL .. then we get the source code on git.centos.org.
We have no real idea of the exact build order, it is trial and error. Once we get rpms built, they go through some initial QA. Then we release them as CR. Goals for each are listed below.
During the normal lifetime of a point release, security updates normally become available 24-72 hours after Red Hat publishes the fixes - has that changed recently?
That is for normal updates after the point release is done before the next point release.
For a point release .. 7-14 days for CR and then 14-21 days for the official tree (after CR) has always been the goal.
Another issue with security updates is how long it sometimes takes for them to arrive in our SCL repositories. In one case, there was a delay of 4 months for PHP[1] and I also remember a critical fix for Python 3 taking several weeks. Couldn't we get some sort of notification on new commits in Red Hat's public repo?
SCLs are a SIG, not part of the Core SIG. The SIG would have to address that.
[1] https://www.redhat.com/archives/sclorg/2014-November/msg00008.html [2] https://www.redhat.com/archives/sclorg/2014-November/msg00005.html
The latest https://rhn.redhat.com/errata/RHSA-2016-2946.html which is a critical update for firefox released on the 14th is still not released for CentOS 7 after 2 days.
The original advisory[3] for Firefox 50.1 lists a few more CVEs than Red Hat's bulletin (the critical security fixes are backported by Mozilla in the ESR version "where feasible", which is why the Canonical Security Team decided to offer the normal Firefox releases in Ubuntu LTS, not the ESR ones). [4]
[3] https://www.mozilla.org/en-US/security/advisories/mfsa2016-94/ [4] http://www.chriscoulson.me.uk/blog/?p=111
Best regards, Laurențiu _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 12/16/2016 08:12 AM, Laurentiu Pancescu wrote:
On 16/12/16 12:08, Karanbir Singh wrote:
On 16/12/16 10:49, Trevor Hemsley wrote:
The latest https://rhn.redhat.com/errata/RHSA-2016-2946.html which is a critical update for firefox released on the 14th is still not released for CentOS 7 after 2 days.
The original advisory[3] for Firefox 50.1 lists a few more CVEs than Red Hat's bulletin (the critical security fixes are backported by Mozilla in the ESR version "where feasible", which is why the Canonical Security Team decided to offer the normal Firefox releases in Ubuntu LTS, not the ESR ones). [4]
Firefox 45.6 (firefox-45.6.0-1.el7.centos.x86_64.rpm) coming down through yum as I write this.
CentOS has no control over the RHEL package; CentOS rebuilds the exactly as released (even if not exactly when released). If you want CentOS to depart from the ESR train you need to bug Red Hat to change RHEL's package so that the source propagates to CentOS.
On Fri, 2016-12-16 at 10:49 +0000, Trevor Hemsley wrote:
On 16/12/16 10:37, Karanbir Singh wrote:
On 15/12/16 23:43, Phil Wyett wrote:
Hi,
How is the core SIG looking at improving and speeding up (more than one person) builds of updates? As I see it the longer the time between vendor release and CentOS release people know that we are hittable if they have a viable exploit?
I ask this as I see that the core SIG is not concentrating on the job at hand and concentrating on the work of their new masters - Red Hats CentOS? Their heads are in the cloud. ;-)
unsure if this is a troll post or you actually meant to raise tangiable concerns ?
I am in complete agreement.
7.3.1611 took 39 days from the upstream release which is 2 weeks longer than the previous el7 drops.
The latest https://rhn.redhat.com/errata/RHSA-2016-2946.html which is a critical update for firefox released on the 14th is still not released for CentOS 7 after 2 days.
It appears the core team have lost focus on what's important. The SIG stuff should be peripheral. The altarch stuff should be peripheral. Concentrate on what's important - it's the DISTRO. The rest of it may be nice to have but the important part is the core of the distro. Anything else is just distraction.
Trevor
Total agreement.
Regards
Phil
On Fri, 2016-12-16 at 10:37 +0000, Karanbir Singh wrote:
On 15/12/16 23:43, Phil Wyett wrote:
Hi,
How is the core SIG looking at improving and speeding up (more than one person) builds of updates? As I see it the longer the time between vendor release and CentOS release people know that we are hittable if they have a viable exploit?
I ask this as I see that the core SIG is not concentrating on the job at hand and concentrating on the work of their new masters - Red Hats CentOS? Their heads are in the cloud. ;-)
unsure if this is a troll post or you actually meant to raise tangiable concerns ?
Hi Karanbir,
How dare you class me as troll!
At present one person pushes updates and as of this email we are still waiting on a firefox update????
Regards
Phil
On Fri, Dec 16, 2016 at 12:24 PM, Phil Wyett philwyett.hemisphere@gmail.com wrote:
On Fri, 2016-12-16 at 10:37 +0000, Karanbir Singh wrote:
On 15/12/16 23:43, Phil Wyett wrote:
Hi,
How is the core SIG looking at improving and speeding up (more than one person) builds of updates? As I see it the longer the time between vendor release and CentOS release people know that we are hittable if they have a viable exploit?
I ask this as I see that the core SIG is not concentrating on the job at hand and concentrating on the work of their new masters - Red Hats CentOS? Their heads are in the cloud. ;-)
unsure if this is a troll post or you actually meant to raise tangiable concerns ?
Hi Karanbir,
How dare you class me as troll!
Is what a troll would say.
But here's why I think you sound like a troll
1 - An accusing tone. 1a - Especially on a product which has no cost.
2 - Very general accusations.
3 - Slurring many groups together in order to antagonize the greatest amount of people. 3a - SIG's, Red Hat employees, etc...
If you are not a troll, then it might be nice to try changing the way you write your emails, because you certainly sound like one. If you change the way your write your emails, you might get much more done, in a much faster timeframe.
On Fri, 2016-12-16 at 12:44 -0600, Troy Dawson wrote:
On Fri, Dec 16, 2016 at 12:24 PM, Phil Wyett philwyett.hemisphere@gmail.com wrote:
On Fri, 2016-12-16 at 10:37 +0000, Karanbir Singh wrote:
On 15/12/16 23:43, Phil Wyett wrote:
Hi,
How is the core SIG looking at improving and speeding up (more than one person) builds of updates? As I see it the longer the time between vendor release and CentOS release people know that we are hittable if they have a viable exploit?
I ask this as I see that the core SIG is not concentrating on the job at hand and concentrating on the work of their new masters - Red Hats CentOS? Their heads are in the cloud. ;-)
unsure if this is a troll post or you actually meant to raise tangiable concerns ?
Hi Karanbir,
How dare you class me as troll!
Is what a troll would say.
But here's why I think you sound like a troll
1 - An accusing tone. 1a - Especially on a product which has no cost.
2 - Very general accusations.
3 - Slurring many groups together in order to antagonize the greatest amount of people. 3a - SIG's, Red Hat employees, etc...
If you are not a troll, then it might be nice to try changing the way you write your emails, because you certainly sound like one. If you change the way your write your emails, you might get much more done, in a much faster timeframe
Hi,
I have asked questions that will not apparently be answered. This is the centos project, a community project and I am asking basic questions and getting hit/replies from redhat employees and being called a troll. I know when a I am being bullied. I will be quiet now.
Regards
Phil
On 12/15/2016 06:43 PM, Phil Wyett wrote:
How is the core SIG looking at improving and speeding up (more than one person) builds of updates? As I see it the longer the time between vendor release and CentOS release people know that we are hittable if they have a viable exploit?
I'm trying to not come across too harshly, but if you need a guaranteed speed of update, then you need to purchase an RHEL subscription.
The same source that is being rebuilt for CentOS is publicly available, and there is nothing preventing you from rebuilding it at the speed you need.
From my point of view I'm happy just getting the updates at any time, even if there is a delay in release. If I want better speed of updates, I buy RHEL subscriptions (and I do have one personally for a critical machine). Or I rebuild from the same sources that CentOS uses, although I have found that the CentOS developers almost always beat me to getting packages built, even when I do try to do the rebuild myself. (As Johnny alluded to, it's not just 'take this group of sources and build in any arbitrary order' and the so-called point releases can be much more difficult than ordinary updates due to build order puzzles.)
The CentOS developers have, in my opinion, done a fantastic job of turning out timely updates since 6.0/5.6/4.9 days, and I am personally and professionally grateful for the time spent, at no cost to me, for this to happen.
On 16/12/16 00:43, Phil Wyett wrote:
As I see it the longer the time between vendor release and CentOS release people know that we are hittable if they have a viable exploit?
That's true, and I think that's the primary reason for the recommendation to pay for RHEL for critical systems. This applies for any distro that builds on top of another, not just CentOS - there will always be a delay due to rebuilding the binaries. If paying for a commercial enterprise distro isn't possible, and you need both long-term stability and immediate security updates, the only other options I'm aware of are Debian and Ubuntu LTS.
I ask this as I see that the core SIG is not concentrating on the job at hand and concentrating on the work of their new masters - Red Hats CentOS? Their heads are in the cloud. ;-)
"their new masters"? Really?! So everyone who disagrees, or simply happens to be interested in using CentOS in the cloud, is a mindless servant of some evil master? There was actually a lot of work going on for the transition to 7.3, and "the cloud" was certainly not the reason for the delay. If anything, the cloud stuff was somewhat neglected in favor of the core distro during the transition. The 1611 Vagrant release wasn't as smooth as I would have liked due to the unforeseen problems with XFS compatibility.
There is no community version of e.g. SLES; CentOS and other RHEL clones can only exist because Red Hat provides the RHEL sources to _everybody_, not just to their customers, as the GPL requires them to. They have enough engineers as it is, I doubt their cloud effort would be doomed without the 5 people in the CentOS Core SIG. And if they wanted to sabotage CentOS, they could just stop publishing the sources, instead of resorting to secretive orders to the CentOS Core team. I see the opposite, their engineers actively helping CentOS in the SIGs, not to mention Fedora too. They do this because they want to, but they don't owe us anything; I feel that imperative, loud demands for them (or anybody else for that matter) to behave in a certain way, or to spend resources to do stuff for us for free, pretty troubling.
I see Red Hat's hiring of the Core team as a positive thing, since it provides financial stability for them to be able to work full-time on the distro (Red Hat has a pretty hands-off approach regarding the team, if I understood correctly). I don't think it would be in anybody's best interest to have a repeat of the difficult transition to CentOS 6, but, if Red Hat's direct involvement concerns you, why don't you see if you can help Scientific Linux? It's an independent, active RHEL clone, developed by Fermilab and several universities and science labs (CERN switched to CentOS 7, but they used SL 6 before and co-developed it).
I am not associated with Red Hat in any way, and never was their employee, contractor, shareholder or whatever. I spent most time on Debian since 2001 (although Red Hat Linux 4.2 was the first distro I tried, back in 1997), but I am aware of the huge positive impact Red Hat had, if only from the press - they were there from the beginning, one of the first distros and Linux companies. The Linux kernel wouldn't be where it is today without them hiring a pretty large number of kernel hackers, and they are the second biggest corporate contributor to the Linux kernel, right behind Intel.[1] They offered free licenses to their patents for open-source software, open-sourced pretty much everything they did or got from acquisitions, they sponsor a large number of open-source projects (I'm not aware of any attempt to influence or control the direction of projects they sponsor) and even paid commercial font foundries to design good fonts for the Linux desktop, and released them for everyone to use. And other distros also benefit from tools developed by Red Hat or Fedora: I remember having used the readahead-fedora package in Debian, a few years ago, to significantly reduce my boot time.
[1] https://www.linux.com/blog/top-10-developers-and-companies-contributing-linu...
What bothers me is the docs behind the meetings. How are you engaging the community. No your not... You have a club going and the masses don't see what is going on.
Real docs! CentOS is not a community project!
Obvious as that might be, I have a different opinion. The meetings are held on #centos-devel, and the minutes are publicly available on the web. If documentation is missing or obsolete, it's just because of a lack of resources, not an attempt to keep people out. I had problems with the CentOS Vagrant images some months ago, and, after debugging together with Karanbir and others about 3 days on #centos-devel, Karanbir asked me if I wouldn't be interested in becoming a contributor. They brought me up to speed via direct links to the wiki, there were some direct sessions with Brian and the rest, just emails, conversations on IRC, bug tracking, patches on GitHub... If the documentation are lacking, just ask people on #centos-devel, they were always very helpful.
As for Karanbir, he was always immensely helpful and he sometimes answered my questions even late at night - I don't think he should apologize to anyone in this case.
Best regards, Laurențiu
-
Johnny Hughes -
Karanbir Singh -
Lamar Owen -
Laurentiu Pancescu -
Phil Wyett -
Trevor Hemsley -
Troy Dawson