Deterministic/reproducible builds (Was: Clarity on current status of Scientific Linux build)
Patrick J. LoPresti lopre...@gmail.com writes: See https://wiki.debian.org/ReproducibleBuilds or https://blog.torproject.org/category/tags/deterministic-builds or http://www.chromium.org/developers/testing/isolated-testing/deterministic-builds or just try a search of your own. To add, if deterministic builds were not possible it would mean this could not exist: http://nixos.org/nix/ Regards, -Brett. pgp5Omo83hFLU.pgp Description: PGP signature
Re: Clarity on current status of Scientific Linux build
On 07/02/2014 12:18 AM, Patrick J. LoPresti wrote: On Tue, Jul 1, 2014 at 5:09 PM, jdow j...@earthlink.net wrote: On 2014-07-01 08:16, Patrick J. LoPresti wrote: The *goal* of CentOS used to be binary compatibility, even if it was never 100% achieved. ... Pat, this is nominally impossible with modern compilers as I discovered a long time ago. Incorrect. If it's so incorrect, then why is it mentioned in the gnu.org GPL FAQ? No, traceability is the irrelevant side issue here. In NTP terms, if I can have a stratum 1 source that's nice, but a stratum 2 may be enough for the job at hand. If I truly need real stratum 1 then I need to pay for the proper number and types of refclocks to obtain real stratum 1 capability (I have this exact need here, and am building out the necessary number and types of refclocks to achieve that goal; for non-astronomical purposes stratum 4 or 5 is more than sufficient as long as those are traceable to stratum 1 sources, such as tick and tock and the various standards maintained by NIST). A single GPS-disciplined clock, such as an HP/Agilent/Symetricom Z3816A or Z3805 is just not enough by itself. Once again, the only relevant question is whether and how Scientific Linux can be a rebuild of Red Hat Enterprise *and not CentOS*,... This remains to be seen. It may not be possible. But in order for the SL team to accomplish this, traceability to Red Hat of the sources will be required, since it is apparent that source RPMs on a public ftp server are not coming back any time soon, if ever. If this traceability means that the SL team internally audits against upstream's source RPMS obtained via subscription, and they silently release SL7 without publicly revealing the results of that audit, will that meet your standards? (My gut feel is that only a rebuild of subscription-obtained SRPMs publicly released would meet your standards, but that may not be something anyone is willing to do.) I trust the Scientific Linux team. Obviously, I do not trust Red Hat which includes CentOS. Time will tell how well my trust is placed. If you don't trust Red Hat then why use their obviously different from upstream sources in the first place? Any straight rebuild of Red Hat's sources cannot be more trustworthy than Red Hat's sources, unless every line of source code being rebuilt is completely security audited, which goes way beyond a typical rebuild.
Deterministic/reproducible builds (Was: Clarity on current status of Scientific Linux build)
On Wed, 2 Jul 2014, Brett Viren wrote: To add, if deterministic builds were not possible it would mean this could not exist: http://nixos.org/nix/ or that this website makes assertions not accurate There are timestamps and build IDs and more which, unless tinkered with, will mean that building ANY package at two different times will have (non-functional) differences that prevent an exact binary duplicate from ever existing. Similarly, with parallel threaded (-j N) build systems, a Makefile might comclude one time that sub-element FOO was done first, otehr times sub-element BAR, and so to traverse a build path in differing orders. Not anything invidious, but not 'identical' either -- Russ herrold
Re: Clarity on current status of Scientific Linux build
Dear Yasha [...] From a query I posted on this matter to the SL list: 2. Evidently, Singh and other core CentOS team members actually are Red Hat employees, just as the core SL team have been Fermilab or CERN employees (presumably in some cases actually paid by the research collaborations funded by various government agencies through various universities -- e.g., in the USA, NSF or DOE with each PI typically holding a tenure-stream faculty position at a university). Will the core SL team or the core CERN linux team likewise become Red Hat employees? CERN linux team is and will be CERN employees: Our only relationship with Red Hat is that we are customers. To clarify little bit: Our primary mission at CERN is to provide support for linux platform for our customers - experiments and working groups - not to build linux distribution. (yes - we did it in last 10 years since in 2004 this was the only option) End question. Are Jerek Polok et al. now Red Hat employees, or still CERN employees? Yes we are CERN employees: the fact of using this or that linux version does not change it - why would it ? Additional questions: A. Will the SL/SLC source tree for RPM builds be a separate copy from the CentOS git, downloaded therefrom? I am speaking for SLC here: no: we are going to use CentOS. A.1 Will the SL/SLC source tree be compared to the original SRPMs that CERN seems to have under license from Red Hat to verify that the CentOS git source is in fact unadulterated RHEL 7 source, other than for obvious Red Hat logos and the like? Speaking for SLC here: yes, we could do it (so could SL and anybody else), but please note: this does not change anything for everybody else on this list: if somebody decides to distrust Red Hat and CentOS ... why would that person trust us ? ... B. Jarek states above: Whatever the case, there will continue to exist a linux of production quality and of free or affordable cost. That was actually a quote from Konstantin's post- but I fully agree with it. What is affordable cost and to what is this cost to be paid? Red Hat? CERN? Fermilab (technically, the consortium responsible for operating Fermilab as USA federally funded research facility) for USA-based university sites using SL 7? For us at CERN the affordable cost is dedicating some resources (manpower/hardware/network bandwidth/ .. etc) towards support/maintenance (and development only if needed) of a freely distributable linux version matching our computing platform requirements. I do not fully understand your question about the cost to be paid I'm afraid: What is your current cost of using SL ? Why would that cost change if you use CentOS (or SL built with CentOS sources) ? Best Regards Jarek __ --- _ Jaroslaw_Polok __ CERN - IT/OIS/WLS _ _ http://cern.ch/~jpolok tel_+41_22_767_1834 _ _ +41_76_487_9487 _
Re: Clarity on current status of Scientific Linux build
Jarek, good morning: I was unfortunately paged about someone else's hardware problem and happen to be up. On Tue, Jul 1, 2014 at 2:54 AM, Jarek Polok jaroslaw.po...@cern.ch wrote: Dear Yasha Are Jerek Polok et al. now Red Hat employees, or still CERN employees? Yes we are CERN employees: the fact of using this or that linux version does not change it - why would it ? Yasha has occasionally been known to spend a great deal of thought in some very elaborate models of how things work procedurally, that do not always match what is actually going on. Reviewing or clarifying the situation can sometimes reveal some interesting points, so it's not something to begrudge him. Additional questions: A. Will the SL/SLC source tree for RPM builds be a separate copy from the CentOS git, downloaded therefrom? I am speaking for SLC here: no: we are going to use CentOS. There are, for me and for clients I encourage, some very useful features of SL that CentOS never has and, I think, never will support. These especially include the various yum configurations for third party repositories, such as EPEL, repoforge, and rpmfusion. A.1 Will the SL/SLC source tree be compared to the original SRPMs that CERN seems to have under license from Red Hat to verify that the CentOS git source is in fact unadulterated RHEL 7 source, other than for obvious Red Hat logos and the like? Speaking for SLC here: yes, we could do it (so could SL and anybody else), but please note: this does not change anything for everybody else on this list: if somebody decides to distrust Red Hat and CentOS ... why would that person trust us ? ... Because you're aware of the possibly of HTTPS git repositories being surreptitiously replaced and poisoning all downstream builds. GPG tags would help that, GPG signed RPM's and SRPM's also help that. Why would that cost change if you use CentOS (or SL built with CentOS sources) ? Best Regards Jarek For me, at least, I'd lose SL's clear separation of 'vendor' and 'non-vendor' code, and the ease of access to and management of the 3rd paty repositories.
Re: Clarity on current status of Scientific Linux build
All members of the SL user community (including systems users, not just endusers) should be very thankful to Jarek for his clear candor. From Jarek: I am speaking for SLC here: no: we are going to use CentOS. End quote. At this point, unless Fermilab is planning something else, it appears that SL fundamentally is dead. SL is going to be CentOS, so the SL non-CERN community might as well switch to CentOS or to license real Red Hat EL for fee. CERN is no longer willing to invest the resources (human and machine) to support a separate distro. Does Fermilab have the resources to go it alone? SLC evidently will be CentOS with specific additional hardware drivers and software applications to meet the needs of the CERN LHC collaborations, including running the LHC detectors and data reduction and analysis environment. The second point also is in this quote from Jarek: Speaking for SLC here: yes, we could do it (so could SL and anybody else), but please note: this does not change anything for everybody else on this list: if somebody decides to distrust Red Hat and CentOS ... why would that person trust us ? ... End quote. Unless the SRPMs distributed by Red Hat are a misrepresentation, a build from these SRPMs should yield RPMs that are identical (bit for bit, e.g., under a real binary compare) to the installable RPMs provided by Red Hat. Once this is verified, one knows that a build of SL derived from these SRPMs in fact will be a functionally faithful clone of RHEL (specific release and versions in the SRPMs -- functionally faithful because the actual logos, etc., will be different). Red Hat is a for profit corporation, providing source, etc., back to the not-for-profit community only because of a marketing model and/or GPL, etc., restrictive covenants (licenses). However, the for-profit competitors of Red Hat, notably Oracle, are using RHEL source to build a competitor linux distro that Oracle evidently distributes without fee. Thus, Red Hat now is using CentOS. Will CentOS be a faithful copy of RHEL? I personally fear that it will not be to stymie Oracle and the like. The git, etc., mechanism that Red Hat is using presents no obstacle to deep pocket (well capitalized) for-profits such as Oracle, but only an inconvenience. Thus, this model only will work if CentOS lacks some vital feature, or else Red Hat has elected this path for no clear reason. However, if CERN and/or Fermilab actually do compare the CentOS git to the real Red Hat EL SRPMs -- a tedious task unless it can be automated -- there is no reason in my opinion not to trust the CentOS EL source. I do trust that CERN and/or Fermilab personnel will do an honest compare. I am not being paranoid -- I am simply applying the way for-profit USA corporations (such as Red Hat, Oracle, Microsoft, and many others) operate -- and this operation is not in the interest of the commons. [Aside: The closest I have found to such a USA corporation recently operating in the interest of the commons is the apparent promise of Tesla (electric battery automobiles) to release the fundamental energy storage and propulsion technology it uses to competitors at no charge. However, Tesla corporation seems to be the rare exception, not the rule.] Please pardon any statements of societal philosophy -- the practical question is very simple: can we bet the farm that the new CentOS SL will be a reliable production system in a hostile (under attack) environment? If I understand Jarek, CERN is so betting, presumably to save the cost of RHEL 7 licensing to the governments (and perhaps private philanthropy at some of the universities participating in the CERN LHC collaborations) that are funding the experiments. Yasha Karant On 06/30/2014 11:54 PM, Jarek Polok wrote: Dear Yasha [...] From a query I posted on this matter to the SL list: 2. Evidently, Singh and other core CentOS team members actually are Red Hat employees, just as the core SL team have been Fermilab or CERN employees (presumably in some cases actually paid by the research collaborations funded by various government agencies through various universities -- e.g., in the USA, NSF or DOE with each PI typically holding a tenure-stream faculty position at a university). Will the core SL team or the core CERN linux team likewise become Red Hat employees? CERN linux team is and will be CERN employees: Our only relationship with Red Hat is that we are customers. To clarify little bit: Our primary mission at CERN is to provide support for linux platform for our customers - experiments and working groups - not to build linux distribution. (yes - we did it in last 10 years since in 2004 this was the only option) End question. Are Jerek Polok et al. now Red Hat employees, or still CERN employees? Yes we are CERN employees: the fact of using this or that linux version does not change it - why would it ? Additional questions: A. Will the
Re: Clarity on current status of Scientific Linux build
On 07/01/2014 03:40 AM, Yasha Karant wrote: At this point, unless Fermilab is planning something else, it appears that SL fundamentally is dead. SL is going to be CentOS, so the SL non-CERN community might as well switch to CentOS or to license real Red Hat EL for fee. CERN is no longer willing to invest the resources (human and machine) to support a separate distro. Does Fermilab have the resources to go it alone? SLC evidently will be CentOS with specific additional hardware drivers and software applications to meet the needs of the CERN LHC collaborations, including running the LHC detectors and data reduction and analysis environment. ??? That is not at all what I got from his reply. What I got was that CERN will still be committing resources, but instead of duplicating effort they're joining up with the CentOS effort. I even get the impression that it's the same amount of resources as was put towards the separate SLC distribution, which will likely now be a SIG of CentOS. This is good for everyone, since here is a dedicated team that is not comprised of Red Hat employees vested in CentOS. Unless the SRPMs distributed by Red Hat are a misrepresentation, a build from these SRPMs should yield RPMs that are identical (bit for bit, e.g., under a real binary compare) to the installable RPMs provided by Red Hat. The rebuilt RPMs have never been 100% bit-for-bit identical with the Red Hat binary RPMs; that's not what binary-compatible means. That's part of the reason the CentOS team has changed the statement '100% binary compatible' to 'functionally compatible' since they do mean different things, but the latter is more indicative of reality than the former ever has. Red Hat is a for profit corporation, providing source, etc., back to the not-for-profit community only because of a marketing model and/or GPL, etc., restrictive covenants (licenses). That is inaccurate; Red Hat is not obligated to provide source to the public, nor is anyone who receives source from Red Hat obligated to share it publicly. Red Hat is being as close to a good member of the community as is possible within the constraints of a publicly traded corporation, and they are going above and beyond the letter of the GPL (but perhaps not as far as the spirit of the GPL) in providing source (including timely updates) that is publicly accessible. No one yet in this thread has provided a public, no login required, link to up-to-date sources for SLES 11. The newest publicly available sources for SLES 11 that I have been able to find are nearly a year old. However, the for-profit competitors of Red Hat, notably Oracle, are using RHEL source to build a competitor linux distro that Oracle evidently distributes without fee. Oracle's support is not without fee. Oracle and Novell both seem to be attempting to provide direct support not necessarily for their own distributions, but for actual RHEL itself, too. This was the cause of many pieces of formerly open information (including bugzilla entries) to go private, to make it more difficult for RH's competitors. The community was unfortunately negatively impacted by that, too, but it's a balancing act between openness and business sense. I personally wish things could be completely open; but I also know that the community is heavily, almost entirely, dependent upon Red Hat's business survival. However, if CERN and/or Fermilab actually do compare the CentOS git to the real Red Hat EL SRPMs -- a tedious task unless it can be automated -- there is no reason in my opinion not to trust the CentOS EL source. I do trust that CERN and/or Fermilab personnel will do an honest compare. Now this is interesting. You're trusting a third party to compare Red Hat's product to Red Hat's community edition (essentially) but not trusting Red Hat to do that itself? If you don't trust Red Hat to provide and continuously verify the contents of git.centos.org themselves, then how in blue blazes can you trust Red Hat to provide the source code you're using? Whether Red Hat says they're doing it or not, it's a really good bet that a Red Hat engineer is tracking git.centos.org continuously to make sure the upstream sources remain unblemished. While I would prefer Red Hat to state that plainly, at the same time I believe it is strongly implied by the presence of Red Hat employees other than the CentOS team on the centos-devel mailing list. I am not being paranoid -- I am simply applying the way for-profit USA corporations (such as Red Hat, Oracle, Microsoft, and many others) operate -- and this operation is not in the interest of the commons. At this I have to take exception. Red Hat has many times proven its commitment to the community in both word and deed. can we bet the farm that the new CentOS SL will be a reliable production system in a hostile (under attack) environment? Here you really *are* being paranoid,
Re: Clarity on current status of Scientific Linux build
[...] ??? That is not at all what I got from his reply. What I got was that CERN will still be committing resources, but instead of duplicating effort they're joining up with the CentOS effort. This is what I meant. I even get the impression that it's the same amount of resources as was put towards the separate SLC distribution, which will likely now be a SIG of CentOS. Actually we (SLC) are putting these resources in CentOS Core SIG. (and in the future perhaps in other SIGs too - Cloud / Virt / ..etc) - as a matter of fact - little bit less than 'same amount' - since we still continue building SLC6 and SLC5 in-house. This is good for everyone, since here is a dedicated team that is not comprised of Red Hat employees vested in CentOS. [ ... ] Jarek __ --- _ Jaroslaw_Polok __ CERN - IT/OIS/WLS _ _ http://cern.ch/~jpolok tel_+41_22_767_1834 _ _ +41_76_487_9487 _
Re: Clarity on current status of Scientific Linux build
And in case I haven't already thanked you (and I think I did, Yes, you did (more than once actually ;-)) but it bears repeating) thanks for sticking with IA64 up to SLC 5.4; As you know we had to stop this effort .. I believe by now we do not have any IA64 systems remaining at CERN .. it made my job of rebuilding CentOS 5 packages on IA64 much much easier, and SLC 5.4 is still my startup distribution for bootstrapping an Altix before pointing to my C5 rebuild repos (I haven't spun ISO's as yet, just rebuilt the packages). Do you have your rebuild available somewhere to the public ? Regards Jarek -- __ --- _ Jaroslaw_Polok __ CERN - IT/OIS/WLS _ _ http://cern.ch/~jpolok tel_+41_22_767_1834 _ _ +41_76_487_9487 _
IA64 C5 rebuilt packages (was: Re: Clarity on current status of Scientific Linux build)
On 07/01/2014 10:06 AM, Jarek Polok wrote: it made my job of rebuilding CentOS 5 packages on IA64 much much easier, and SLC 5.4 is still my startup distribution for bootstrapping an Altix before pointing to my C5 rebuild repos (I haven't spun ISO's as yet, just rebuilt the packages). Do you have your rebuild available somewhere to the public ? Not at the moment, as the packages are unsigned, and I haven't been exactly speedy on keeping up with updates. If demand were to ramp up, I would be willing to make them available, after I set up signing infrastructure, doing the signing, and setting up some automation for the builds. I would not be willing to make a 'timeliness' commitment on updates, though, since it is very much a secondary effort here right now. But my gut feel is that there is very little demand right now.
Re: Clarity on current status of Scientific Linux build
On Tue, Jul 1, 2014 at 6:17 AM, Lamar Owen lo...@pari.edu wrote: ??? That is not at all what I got from his reply. What I got was that CERN will still be committing resources, but instead of duplicating effort they're joining up with the CentOS effort. Whatever. The relevant questions are: (1) Will SL's goal continue to be creating a re-spin of Red Hat Enterprise and *not* CentOS, since Red Hat's clear goal in acquiring CentOS is to create divergence between the two; and (2) what mechanism(s) will SL use to achieve that goal? (Specifically, will SL compare the git sources against actual SRPMs obtained via subscription?) That's part of the reason the CentOS team has changed the statement '100% binary compatible' to 'functionally compatible' since they do mean different things, but the latter is more indicative of reality than the former ever has. The *goal* of CentOS used to be binary compatibility, even if it was never 100% achieved. Since the acquisition by Red Hat, that is no longer even the goal, for obvious reasons. Red Hat is being as close to a good member of the community as is possible within the constraints of a publicly traded corporation, Disingenuous claptrap. Red Hat is blatantly violating the clear intent of the license that the authors of the code placed on their work. Why Red Hat does this is frankly irrelevant. No one yet in this thread has provided a public, no login required, link to up-to-date sources for SLES 11. Yes, you keep bringing this up as if it were an argument. No one has provided a public, no login required link to an up-to-date photo of my bare rear end, either, which would be precisely as relevant. We are talking about Red Hat; the actions of SUSE, Oracle, Microsoft, Tesla, and your cat have zero bearing on the discussion. Nobody cares about SUSE because nobody cares about SUSE. - Pat
Re: Clarity on current status of Scientific Linux build
On 07/01/2014 11:16 AM, Patrick J. LoPresti wrote: On Tue, Jul 1, 2014 at 6:17 AM, Lamar Owen lo...@pari.edu wrote: ??? That is not at all what I got from his reply. What I got was that CERN will still be committing resources, but instead of duplicating effort they're joining up with the CentOS effort. Whatever. Well, apparently I understood Jarek's post correctly. The relevant questions are: (1) Will SL's goal continue to be creating a re-spin of Red Hat Enterprise and *not* CentOS, since Red Hat's clear goal in acquiring CentOS is to create divergence between the two; It would be detrimental to their bottom line to do so, since so many people are out there who could potentially blow the whistle on any such divergence. and (2) what mechanism(s) will SL use to achieve that goal? (Specifically, will SL compare the git sources against actual SRPMs obtained via subscription?) If the SL developers want to reply, they will. I trust Connie and all the rest are working on the situation, and I trust their judgement for their project. The *goal* of CentOS used to be binary compatibility, even if it was never 100% achieved. What matters is what they intended it to mean, which has never been 'bit for bit identical.' What does 'binary compatibility' really mean? (I take it to mean that all software compiled and linked for one will run on the other; and that doesn't require the packages to be anywhere close in terms of a binary compare; the CentOS test includes more than that.) The following post from 2011 points to the info on how the CentOS project has historically done the binary compatibility test: http://lists.centos.org/pipermail/centos/2011-April/109483.html (the actual script has been moved to vault; see http://vault.centos.org/4.9/build/distro/tmverifyrpms for the actual script, dated March 10, 2011). Further, '100% binary compatibility' to me means that 100% of the software built for one will run absolutely unmodified with identical behavior on both systems (the binaries built on one are 100% compatible with the other). Compatible doesn't mean and has never meant identical at the byte for byte compare level. ... No one yet in this thread has provided a public, no login required, link to up-to-date sources for SLES 11. Yes, you keep bringing this up as if it were an argument. It's a valid counter-example. If the violation of not publicly releasing source RPMS and tying subscription status with continued access were so egregious then SuSE would have been sued into oblivion long ago, and the absence of such suits makes it more difficult for the argument to be made that Red Hat, which is making up-to-date sources available, is violating where SuSE is not (which does not make up-to-date sources available).
Re: Clarity on current status of Scientific Linux build
On 07/01/2014 11:54 AM, Yasha Karant wrote: From: http://en.wikipedia.org/wiki/GPL#Copyleft Conversely, if one distributes copies of the work without abiding by the terms of the GPL (for instance, by keeping the source code secret), he or she can be sued http://en.wikipedia.org/wiki/Lawsuit by the original author under copyright law. End quote. From the gnu.org GPL FAQ: Does the GPL require that source code of modified versions be posted to the public? The GPL does not require you to release your modified version, or any part of it. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization. But /if/ you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users, under the GPL. Thus, the GPL gives permission to release the modified program in certain ways, and not in other ways; but the decision of whether to release it is up to you. ... If I know someone has a copy of a GPL-covered program, can I demand he give me a copy? No. The GPL gives him permission to make and redistribute copies of the program /if he chooses to do so/. He also has the right not to redistribute the program, if that is what he chooses. ... Does the GPL allow me to sell copies of the program for money? Yes, the GPL allows everyone to do this. The right to sell copies is part of the definition of free software. Except in one special situation, there is no limit on what price you can charge. (The one exception is the required written offer to provide source code that must accompany binary-only release.) Does the GPL allow me to charge a fee for downloading the program from my site? Yes. You can charge any fee you wish for distributing a copy of the program. If you distribute binaries by download, you must provide “equivalent access” to download the source—therefore, the fee to download source may not be greater than the fee to download the binary. ... If I distribute GPL'd software for a fee, am I required to also make it available to the public without a charge? No. However, if someone pays your fee and gets a copy, the GPL gives them the freedom to release it to the public, with or without a fee. For example, someone could pay your fee, and then put her copy on a web site for the general public. ... End of quotes. This last point is the real meat, and is the issue which is so controversial. And that issue of 'does a vendor have to right to draw up a terms of use for a means of access to software that makes not redistributing materials obtained via that means a condition for continued use of that means of access?' There's an old posting that somewhat addresses this, but not for this current exact situation: http://linuxmafia.com/faq/RedHat/rhel-isos.html I am not a JD (or equivalent in any nation-state), but I do teach the professional computer science ethics course my School (Department) uses to meet ABET accreditation. This includes an article by Stallman on the concepts of free software. This is laudable, and I'm glad someone is doing this. I am a member of a committee developing certification standards for accreditation of some computer-related educational fields, and having the ethics of various IT/IS/CS/CE/SE situations dealt with in depth is critical, and something I've lobbied for. I'm a very 'free' leaning person, actually, as it would be my preference for all software to be free in the freedoms 0-3 sense of the word free. I'm also a realist and I know that there are tradeoffs made in real life that idealists forget to their detriment. My understanding is that under the GPL the full source code must be made available -- full, including whatever is required to build the software application. Of course then you also know that that does not include certain pieces of the operating system, like the compiler and kernel used, although the exact versions of those must be noted (RPMs 'note' those versions through build and install dependencies). Thus, the statement that the actual binaries for non-Red Hat RHEL that are built (before the actual clone distribution that no longer uses the Red Hat logos, etc.): RH sometimes uses an unreleased version of bar in order to build foo. Rebuilders like CentOS and SL have to make do with the released version of the bar srpm in order to build foo. (From: Date: Tue, 1 Jul 2014 05:05:56 -0400 Message-ID: CAOdo=SzsNsJWn2c-u+sjE_tigvGhVe0_=_hy_5gcgej38kn...@mail.gmail.com Subject: Re: Clarity on current status of Scientific Linux build From: Tom H tomh0...@gmail.com ) End quote seems to violate the GPL as there is a (very important) bit of source code
Re: Clarity on current status of Scientific Linux build
On 2014-07-01 08:16, Patrick J. LoPresti wrote:
On Tue, Jul 1, 2014 at 6:17 AM, Lamar Owen lo...@pari.edu wrote:
...
That's part of the
reason the CentOS team has changed the statement '100% binary compatible' to
'functionally compatible' since they do mean different things, but the
latter is more indicative of reality than the former ever has.
The *goal* of CentOS used to be binary compatibility, even if it was
never 100% achieved. Since the acquisition by Red Hat, that is no
longer even the goal, for obvious reasons.
Pat, this is nominally impossible with modern compilers as I discovered a
long time ago. The compilers I am used to embed a time stamp in the various
files compiled. This time stamp will differ between machines used to compile
the code. So when you perform the binary compare you will hit errors. The
compiler on which I discovered this first (Microsoft C7) the embedded dates
were not even the same length. So once I hit that difference the binary
compare was broken for the rest of the file. If GNU C has this same feature
prattling about binary identity and so forth is nonsense.
...
- Pat
It is good that some of these issues are being aired. But some of the issues
raised smokescreen other more pertinent and substantive issues such as RHEL
traceability. (In the hardware world I infested long ago all test equipment
had to be calibrated in a manner traceable to NBS (now NIST). That issue was
solved.) This RHEL traceability issue is significant as is traceability back
to creators for non-RHEL code replacements for RHEL proprietary software and
for any add-on software provided by sources in the path from SL back to RHEL.
Fussing about binary compatibility is needless obfuscation.
The issue at its base is who do you trust? It helps to know who is asking
you to trust when you make that decision.
{^_^} Joanne
Re: Clarity on current status of Scientific Linux build
On Tue, Jul 1, 2014 at 5:09 PM, jdow j...@earthlink.net wrote: On 2014-07-01 08:16, Patrick J. LoPresti wrote: The *goal* of CentOS used to be binary compatibility, even if it was never 100% achieved. Since the acquisition by Red Hat, that is no longer even the goal, for obvious reasons. Pat, this is nominally impossible with modern compilers as I discovered a long time ago. Incorrect. If GNU C has this same feature It does not, and it never has. See https://wiki.debian.org/ReproducibleBuilds or https://blog.torproject.org/category/tags/deterministic-builds or http://www.chromium.org/developers/testing/isolated-testing/deterministic-builds or just try a search of your own. prattling about binary identity and so forth is nonsense. Before accusing someone of prattling about a topic, may I suggest learning something about it? This RHEL traceability issue is significant as is traceability back to creators for non-RHEL code replacements for RHEL proprietary software and for any add-on software provided by sources in the path from SL back to RHEL. No, traceability is the irrelevant side issue here. (Granted, binary reproducibility is also a side issue; just one where you happen to be wrong.) Once again, the only relevant question is whether and how Scientific Linux can be a rebuild of Red Hat Enterprise *and not CentOS*, when Red Hat's clear motivation and intention is to make those different things. The issue at its base is who do you trust? Whom. OK OK too pedantic. I trust the Scientific Linux team. Obviously, I do not trust Red Hat which includes CentOS. Time will tell how well my trust is placed. - Pat
Re: Clarity on current status of Scientific Linux build
Hello all. On 06/27/2014 09:44 PM, Konstantin Olchanski wrote: On Fri, Jun 27, 2014 at 08:17:19PM +0100, Mark Rousell wrote: However, based upon the balance of probabilities, it looks likely that SL7 will not be based directly on RHEL7 but on CentOS. If so, ... why continued with SL at all. The 800lbs gorilla in the room is CERN (and other large physics labs), who require a linux (some linux) to run the large compute farms for analysis of LHC data. Since I'm involved in Linux @ CERN, let me answer your questions: For historical reasons, this linux has been Red Hat based (and we know it under the names SL and SLC). Will it remain Red Hat based? Yes. (as already mentioned by others in this thread: http://cern.ch/linux/nextversion.shtml) Will the next cern linux be ubuntu/debian based? No. Will Red Hat relax their rules to keep CERN (and the HEP community)? Not sure which rules are we talking about. (but I'm not aware of any special rules for CERN as a Red Hat customer) As an added kink, with the major changes from RHEL6 to RHEL7, the cost of going from SLC6 to RHEL based SLC7 becomes comparable to going from SLC6 to a ubuntu/debian based SLC? Absolutely not. Starting migration from SLC6 to CentOS 7 requires minor tweaks to some of our in-house configuration / system mgmt. tools. Changing to a different platform would be a whole new story ... [ I'm not talking about experiments software stacks here, some of these may be validated on other platforms, some not .. Same applies to 3rd party commercial products ] Whatever the case, there will continue to exist a linux of production quality and of free or affordable cost. Best Regards Jarek -- __ --- _ Jaroslaw_Polok __ CERN - IT/OIS/WLS _ _ http://cern.ch/~jpolok tel_+41_22_767_1834 _ _ +41_76_487_9487 _
Re: Clarity on current status of Scientific Linux build
On 06/27/2014 07:06 PM, Mark Rousell wrote: On 27/06/2014 23:45, Lamar Owen wrote: Again, this is not a new issue in general; it's just now impacting more people than before who are surprised by something that's been around for a long time. ... a) It's a new issue in the specific context in which it matters here (as I said, if it wasn't a new issue in this context then there would not be the problem that is at hand), Just because it took some folk by surprise does not make it a new issue. It might be 'new to you' but 'new to you' doesn't make it objectively 'new.' Some people, including me, have been thinking about this very issue for years (in my case ever since RHL 6.2E was first released; RHAS 2.1 split a little further, and RHEL3 made it official; I still have a personal archive of a non-public mailing list of what lots of people, including myself, thought about it at the time it happened); I honestly was pleasantly surprised when the source RPMS for EL6 were still up for public consumption, and while a bit disappointed I am not really surprised that Red Hat has made this particular business decision for EL7. Reality is and has always been a balancing act; in this case the balance is between openness and business survival. And for SL, CentOS, and all the other RHEL rebuilds out there, survival of their respective distributions is rather extensively dependent upon survival of Red Hat the company. b) the comments by Bradley Kuhn and others back in 2011 do not fully apply to the situation at hand now (even though it is a longstanding issue in general), and Sure they do; those comments are about the GPL and the 'preferred method of source delivery.' The 'same source' is still out there in a different form. (Yes, I'm aware of the issues with making sure it's the same source, and I think those issues will be addressed). c) as I said in my message posted at 23:41:46 +0100, just because it is a longstanding issue that is increasingly common practice does not mean that it is acceptable or that it will necessarily stand if well challenged. Are you volunteering to be the challenger here? Until someone who actually owns copyright in a GPL-covered package being distributed by Red Hat makes challenge, it is what it is. And unless I am mistaken it does require a copyright holder to challenge a copyright license violation (mere users of the program wouldn't have standing). The FSF is one such organization, and they have not yet made challenge (and history shows that the FSF is not at all shy about challenging when they feel that they have a case). Time well tell if this latest wrinkle in this long-standing issue will tip the scales far enough to cause one of the copyright holders make a challenge to this business model. My gut feel is that the source still being available through the git.centos.org mechanism will keep most potential challengers, with actual standing, from spending the time and money to foist a challenge. Historical lack of action does not necessarily legitimise, justify or explain current or future lack of action. Opinions can and do change. What is or is not legal is entirely a matter of opinion (it will of course boil down to a court's opinion if it's challenged). It's not clear cut. If you want clarification from Red Hat, well, you're going to get their own opinion on what they're doing. Red Hat had chosen in the past to release source RPMs to the public, which at least in my opinion is going above and beyond the letter of the GPL requirements, at least for the main stream of packages (and people, including me, have been saying for years that Red Hat has been going above and beyond the letter of the GPL in doing so). But if it is legally ok to hold back from the public *any* source RPM that is under the GPL, then it is legally ok to hold back from the public *all* source RPMs under the GPL (and Red Hat has held back some source RPMs from public distribution for a number of years). As long as the people to whom the binaries are distributed can get the sources to those specific binary packages the GPL is satisfied in letter. At least until a court of law holds otherwise. And courts' opinions can change, too. I'm not saying I agree with it or not; I know my preferences, and business realities often clash with my preferences. And, of course, Red Hat could decide to reverse their decision; time will tell. And I'll leave the thread with this link to a bugzilla from 2007 (and please note the names of many of the participants): https://bugzilla.redhat.com/show_bug.cgi?id=230412
Re: Clarity on current status of Scientific Linux build
On 23/06/2014 14:54, Steven Timm wrote: I was at the HEPiX meeting at which those slides were presented and there was further discussion during the course of the week as to what would happen. RedHat/CentOS was also represented at that meeting in the person of Karanbir Singh. You should not presume that the presentations given at that meeting are the final word. You notice that nobody with a cern.ch or fnal.gov E-mail address has responded to this thread up until now. When they have something concrete they will respond with the details. Steve Timm (Apologies if you've seen this twice. Posting via Hotmail is less than ideal). So, in short, complete clarity is not yet available, if I understand correctly? However, based upon the balance of probabilities, it looks likely that SL7 will not be based directly on RHEL7 but on CentOS. If so, it does raise the question of why continued with SL at all. It would be very sad indeed if this is the case.
Re: Clarity on current status of Scientific Linux build
Thanks to everyone who commented and I apologise for the delay in replying. So it seems that complete clarity is not yet available. Ok. A couple more questions in the search for clarity:- 1) Can anyone confirm or deny that Red Hat places contractual limitations on what a subscriber (who has access to the RHEL7 SRPMs) can do with the source code so obtained? Yes, I know this has been discussed but I don't think it has been explicitly confirmed. One must infer that there are contractual limitations (otherwise why remove public access to SRPMs) but it would be nice to be absolutely clear. 2) This is a legal question but it is relevant: If Red Hat uses a contract with its customers to prevent a customer who is a recipient of the GPLd source code (when received via SRPM) from redistributing it or rebuilding it as they please, wouldn't this mean that Red Hat itself was in breach of the GPL licence conditions?
Re: Clarity on current status of Scientific Linux build
On 06/27/2014 03:28 PM, Mark Rousell wrote: 1) Can anyone confirm or deny that Red Hat places contractual limitations on what a subscriber (who has access to the RHEL7 SRPMs) can do with the source code so obtained? Please read http://lwn.net/Articles/432012/ and http://ebb.org/bkuhn/blog/2011/03/05/open-core-slur.html (especially the 12th paragraph). For legal advice, you should consult with your lawyer. We non-lawyer types aren't qualified to give legal advice; the lawyers on this list won't likely give you legal advice in public, either.
Re: Clarity on current status of Scientific Linux build
On Fri, Jun 27, 2014 at 08:17:19PM +0100, Mark Rousell wrote: However, based upon the balance of probabilities, it looks likely that SL7 will not be based directly on RHEL7 but on CentOS. If so, ... why continued with SL at all. The 800lbs gorilla in the room is CERN (and other large physics labs), who require a linux (some linux) to run the large compute farms for analysis of LHC data. For historical reasons, this linux has been Red Hat based (and we know it under the names SL and SLC). Will it remain Red Hat based? Will the next cern linux be ubuntu/debian based? Will Red Hat relax their rules to keep CERN (and the HEP community)? As an added kink, with the major changes from RHEL6 to RHEL7, the cost of going from SLC6 to RHEL based SLC7 becomes comparable to going from SLC6 to a ubuntu/debian based SLC? Whatever the case, there will continue to exist a linux of production quality and of free or affordable cost. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: Clarity on current status of Scientific Linux build
On 06/27/2014 01:14 PM, Lamar Owen wrote: On 06/27/2014 03:44 PM, Konstantin Olchanski wrote: The 800lbs gorilla in the room is CERN (and other large physics labs), who require a linux (some linux) to run the large compute farms for analysis of LHC data. For historical reasons, this linux has been Red Hat based (and we know it under the names SL and SLC). Will it remain Red Hat based? ... The CERN direction I would think is crystal-clear: http://www.karan.org/blog/2014/06/10/centos-community-buildsystem-bootstraping-by-the-cern-linux-team/ http://linux.web.cern.ch/linux/docs/GDB%2020140212%20-%20Future%20of%20Scientific%20Linux%20in%20light%20of%20recent%20CentOS%20project%20changes..pdf http://lists.centos.org/pipermail/centos-devel/2014-June/010517.html In a nutshell: it sure looks like SLC will remain Red Hat based. SLC developers have joined the CentOS Core SIG and are actively working on CentOS infrastructure. If you want to see more, follow the centos-devel list; come to your own conclusions by seeing the actions. Just so that the SL list has a specific inclusion of this information (in the event the CentOS lists somehow become unavailable), below is the last item in the above set. CentOS-devel] Welcoming CERN Linux Distro team *Karanbir Singh* kbsingh at centos.org mailto:centos-devel%40centos.org?Subject=Re:%20%5BCentOS-devel%5D%20Welcoming%20CERN%20Linux%20Distro%20teamIn-Reply-To=%3C53970C1B.9040305%40centos.org%3E /Tue Jun 10 13:46:03 UTC 2014/ * Previous message: [CentOS-devel] CentOS 7 Artwork http://lists.centos.org/pipermail/centos-devel/2014-June/010519.html * Next message: [CentOS-devel] Welcoming CERN Linux Distro team http://lists.centos.org/pipermail/centos-devel/2014-June/010518.html * *Messages sorted by:* [ date ] http://lists.centos.org/pipermail/centos-devel/2014-June/date.html#10517 [ thread ] http://lists.centos.org/pipermail/centos-devel/2014-June/thread.html#10517 [ subject ] http://lists.centos.org/pipermail/centos-devel/2014-June/subject.html#10517 [ author ] http://lists.centos.org/pipermail/centos-devel/2014-June/author.html#10517 Hi Everyone, We would like to welcome onboard the CERN Linux Distro team ( http://cern.ch/linux ) to the CentOS Core SIG. Thomas Oulevey and Jaroslaw 'Jarek' Polok are going to be bootstrapping the CentOS Community Buildsystem around Koji and helping run it going forward. The community buildsystem is going to be the central place for all source to binary builds used by all efforts other than CentOS Core ( for now ). The initial target is to get a test instance running in the coming weeks, and then work on the git.centos.org integration, with the aim of having the 'production' buildsys online soon. This is the build service that all SIG's and Core SIG builds will consume going forward ( with the exception of CentOS Linux, we have quite a bit of work to do before we can migrate that ). Communications on this effort will be on the centos-devel mailing list ( http://lists.centos.org/mailman/listinfo/centos-devel ) and on the #centos-devel irc channel on irc.freenode.net. Hardware resources for the effort have been identified, setup and access is being setup so things can start rolling fairly quickly. Mike McLean and Fabian Arrotin are going to be working with them. You can keep up with Jarek on his google+ page at https://plus.google.com/+JaroslawPolok/ and Thomas tweets at https://twitter.com/thomasnomas ; They both also contribute to the http://linux.web.cern.ch/linux/ blog. Please join me in welcoming Thomas and Jarek to the CentOS Project. - KB End quote. Several questions: 1. Is CERN linux the same as SL? 1.1 Are any of the Fermilab team doing the same as in the posting from Singh? 2. Evidently, Singh and other core CentOS team members actually are Red Hat employees, just as the core SL team have been Fermilab or CERN employees (presumably in some cases actually paid by the research collaborations funded by various government agencies through various universities -- e.g., in the USA, NSF or DOE with each PI typically holding a tenure-stream faculty position at a university). Will the core SL team or the core CERN linux team likewise become Red Hat employees? 2,1 As Red Hat employees, one assumes their primary loyalty are to and directions come from their corporate employer. Is this consistent with a SL-type distribution in which the user community (such as the CERN LHC collaborations) have ultimate needs, not those of a for-profit corporation? 3. Will SL just be a SIG of CentOS? Yasha Karant
Re: Clarity on current status of Scientific Linux build
On 27/06/2014 20:43, Lamar Owen wrote: On 06/27/2014 03:28 PM, Mark Rousell wrote: 1) Can anyone confirm or deny that Red Hat places contractual limitations on what a subscriber (who has access to the RHEL7 SRPMs) can do with the source code so obtained? Please read http://lwn.net/Articles/432012/ and http://ebb.org/bkuhn/blog/2011/03/05/open-core-slur.html (especially the 12th paragraph). Yup, I've read those and whilst they address the issue they only answer it by inference and reference, not quite as explicitly as I'd ideally like. I think this the paragraph in the latter article you meant (it certainly covers the key point you responded to): I do have strong, negative opinions about the RHEL business model; I have long called it the if you like copyleft, your money is no good here business model. It's a GPL-compliant business model merely because the GPL is silent on whether or not you must keep someone as your customer. Red Hat tells RHEL customers that if they chose to engage in their rights under GPL, then their support contract will be canceled. Indeed, I am aware of this. I was in fact going to write Can anyone confirm or deny that Red Hat places contractual limitations (where the contract is freely entered into) in my earlier message but it was too much of a mental mouthful. Whilst Red Hat can certainly create whatever contractual terms it wants and customers can freely agree to them, this does not in general automatically or necessarily mean that Red Hat itself is not in breach of a licence (GPL in this case) by creating certain limiting contractual terms with its customers. It does surprise that limiting a customer's rights with respect to GPL (even if it just while the customer freely chooses to remain a customer of Red Hat) is not a GPL-violating action for Red Hat itself. Clearly, however, Red Hat's lawyers (and the FSF it seems) think such a limitation is not a violation of GPL. For what it's worth, such limiting contractual terms (even if freely entered into) do seem on the face of it to be a violation of clause 6 of GPL2 and possibly clause 12 of GPL3 (amongst others possibly). Anyway, as above, it seems that FSF disagrees with me so I need to read GPL2 and 3 much more thoroughly! For legal advice, you should consult with your lawyer. We non-lawyer types aren't qualified to give legal advice; the lawyers on this list won't likely give you legal advice in public, either. Well, that's the usual advice but of course this does seem to be a relevant issue. Anyway, I accept that the question over Red Hat's legal right to effectively restrict GPL can't go much further on this list.
Re: Clarity on current status of Scientific Linux build
On Fri, Jun 27, 2014 at 4:49 PM, Yasha Karant ykar...@csusb.edu wrote: 1. Is CERN linux the same as SL? http://linux.web.cern.ch/linux/scientific.shtml
Re: Clarity on current status of Scientific Linux build
On 27/06/2014 22:16, Mark Rousell wrote: On 27/06/2014 20:43, John Lauro wrote: One reason to remove public sources is to keep the load off of their servers. Yes, that's one reasons. There are other reasons too, of course. My might will infer that other reasons are the overridingly significant ones in this case. ;-) Oops, a typo. I meant to write: Yes, that's one reason. There are other reasons too, of course. One might well infer that the other reasons are the overridingly significant ones in this case. ;-)
Re: Clarity on current status of Scientific Linux build
On Fri, Jun 27, 2014 at 08:28:49PM +0100, Mark Rousell wrote: 1) Can anyone confirm or deny that ... For you, I can confirm or deny anything and everything. The moon is made out of Swiss cheese. 100% confirmed. Yes. (but is it helpful?) 2) This is a legal question but ... For this you need legal advice. Free legal advice is not legal advice. A couple more questions in the search for clarity:- You will not find clarity on the net of a million lies. Do your own research and hire your own lawyer. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: Clarity on current status of Scientific Linux build
On 06/27/2014 05:07 PM, Mark Rousell wrote: Clearly, however, Red Hat's lawyers (and the FSF it seems) think such a limitation is not a violation of GPL. For what it's worth, such limiting contractual terms (even if freely entered into) do seem on the face of it to be a violation of clause 6 of GPL2 and possibly clause 12 of GPL3 (amongst others possibly). Anyway, as above, it seems that FSF disagrees with me so I need to read GPL2 and 3 much more thoroughly! For what it's worth, Bradley Kuhn has spent a great deal of time and effort in dealing with GPL violations. The fact that even he concedes it is likely not a GPL violation speaks volumes; the fact that he, the FSF, etc, have not initiated a lawsuit against Red Hat for a GPL violation speaks even louder. I was taught as a child that actions speak louder than words; and inaction speaks louder yet, especially as he finds Red Hat's practice to be distasteful. If there were a case to be made I would think Mr. Kuhn or another similarly-opinioned individual would have made it by now; this issue has been around for a decade, it's not a new thing. But my favorite line from his other post is simply this: I do find myself wishing that the people debating whether the exact right number of angels are dancing on the head of this particular GPL pin would instead spend some time helping to end the flagrant, constant, and obvious GPL violations with which I spent much time dealing time each week.
Re: Clarity on current status of Scientific Linux build
On 06/27/2014 04:49 PM, Yasha Karant wrote: ... 1. Is CERN linux the same as SL? Scientific Linux CERN is what is being talked about here. 1.1 Are any of the Fermilab team doing the same as in the posting from Singh? ... You should read the archives of the centos-devel list and note the number of accepted patches to the buildsystem and to packages that are being made by persons with fnal.gov affiliation. 2,1 As Red Hat employees, one assumes their primary loyalty are to and directions come from their corporate employer. Is this consistent with a SL-type distribution in which the user community (such as the CERN LHC collaborations) have ultimate needs, not those of a for-profit corporation? You know, I have to chuckle at this. SL is already driven by the needs of Red Hat, counting by number of lines of source code (and the source doesn't just drop out of the sky fully formed, after all; Red Hat invests a large amount of development time building the source to begin with, including funding developers for the upstream projects that all Linux distributions utilize (yes, the Linux kernel itself, to which Red Hat has done a massive amount of work)). Nothing says Red Hat's needs and the communities' needs are not or cannot be in alignment; on the contrary, the fact of the SL rebuild even existing shows how well Red Hat's needs and the communities' needs are aligned. The other fact of the matter is that both fnal and CERN have and use RHEL licenses for other areas. The fact that Red Hat is able to turn a profit and still so closely match the communities' needs is quite remarkable. 3. Will SL just be a SIG of CentOS? The SL team will have to answer that one, in their own time. IOW, be patient. In reality, there are far more things in common between SL and CentOS than are different, as they are after all built from almost entirely the same source code base. It's great to see open collaboration going on in the rebuild effort; a breath of fresh air, really.
Re: Clarity on current status of Scientific Linux build
On 06/27/2014 05:26 PM, Mark Rousell wrote: The cessation of SRPM distribution in general to non-customers, which is the specific issue at hand here, is a new issue that has new considerations to take into account. Whilst it has similarities to the kernel issue in 2011 it also goes further. The SRPM issue is not a new one, either. Try to find the EUS sources, for instance. Or, to go to another, different, distribution, let's find the SuSE Enterprise Linux Server SRPMS, the updates of which have been only available to subscribers for, to the best of my knowledge, at least ten years. You certainly won't find SRPMS in a quick skim of ftp.suse.com. (The latest SLES download is SLES 11 SP3, from July of 2013, nearly a year ago. I know that there are security updates since then, but where are they for non-subscribers? Where is the source for the updates for non-subscribers? I'd love to find it so I could add another supportable OS for my SGI Altix IA64 boxen). This is not a new issue. See Dag's take on it from 2007 at http://dag.wiee.rs/blog/why-is-there-no-open-source-sles
Re: Clarity on current status of Scientific Linux build
On 27/06/2014 23:00, Lamar Owen wrote: On 06/27/2014 05:07 PM, Mark Rousell wrote: Clearly, however, Red Hat's lawyers (and the FSF it seems) think such a limitation is not a violation of GPL. For what it's worth, such limiting contractual terms (even if freely entered into) do seem on the face of it to be a violation of clause 6 of GPL2 and possibly clause 12 of GPL3 (amongst others possibly). Anyway, as above, it seems that FSF disagrees with me so I need to read GPL2 and 3 much more thoroughly! For what it's worth, Bradley Kuhn has spent a great deal of time and effort in dealing with GPL violations. The fact that even he concedes it is likely not a GPL violation speaks volumes As I observed in another message (posted at 22:26:52 +0100), I am not aware of any comment by Bradley Kuhn (or anyone similarly knowledgeable) about the specific issue at hand here and now. As I said in that message, all of the comments by Bradley Kuhn and others date from 2011 and relate to RH's kernel distribution changes at that time; they do *not* relate directly to the new issue about limitations surrounding SRPMs in general which limit things significantly further as far as I can see. Whilst there are certainly significant similarities between the kernel issue from 2011 and this new issue, they are not the same. the fact that he, the FSF, etc, have not initiated a lawsuit against Red Hat for a GPL violation speaks even louder. As above, this seems to be a substantively new issue. If it wasn't a substantive new issue then these threads on the subject would not exist at all and SL7 would be based on RHEL7 SRPMs. I can fully understand why the changes in 2011 did not breach GPL: Everything that was required was still available. However, limiting all SRPM source code usability, the issue at hand now, is a different kettle of fish. It is no longer an issue about preferred form or prominent notice of changes or support for potentially arbitrary code changes that so concerned people in 2011. This is different and substantively extended although, as I mentioned above, it does share some similarities to the 2011 issue. I also expect to be shown at some stage how RH's new, extended, behaviour on this matter still complies with GPL but I can nevertheless say that my own reading of GPL2 (as in my other message I referred to) indicates to me that limiting what a customer can do with source code (regardless of the fact that they freely entered into a contract with RH) puts RH and/or the customer in breach of GPL2. Of course, I should note that I can only infer what RH's new, extended, behaviour is because I haven't seen a contract that really describes any limitation/restrictions/limits on what a RH customer can do in this context. I was taught as a child that actions speak louder than words; and inaction speaks louder yet, especially as he finds Red Hat's practice to be distasteful. I agree but bear in mind that a) The practice about which he commented in 2011 has been significantly extended in such a way that it seems to me to bring new licence clauses into play, and b) lack of action does not in and of itself necessarily imply lack of intent or lack of breach (as things stand now). As I mentioned above and despite all my comment, I still won't be surprised if nothing happens even now. If there were a case to be made I would think Mr. Kuhn or another similarly-opinioned individual would have made it by now; this issue has been around for a decade, it's not a new thing. And yet it most certainly *has* taken on a new form. That changes things. The threads about it on this mail list would not exist if there had not been such a substantive, real world, change. I do find myself wishing that the people debating whether the exact right number of angels are dancing on the head of this particular GPL pin would instead spend some time helping to end the flagrant, constant, and obvious GPL violations with which I spent much time dealing time each week. Aren't discussion of relevant issues such as this pretty much what he seeks? :-) Contractually limiting what a customer does with SRPMs (note, an extended issue compared to kernel source code limitations and incomplete documentation back in 2011) seems like an obvious breach of clause 6 of GPL2 to me.
Re: Clarity on current status of Scientific Linux build
On 06/27/2014 06:16 PM, Lamar Owen wrote: ... I'd love to find it so I could add another supportable OS for my SGI Altix IA64 boxen. After writing that, I thought that perhaps someone has missed the note of sarcasm there. I know full well where the sources are, and I also know that you seem to have to have a login to get the update packages source (and that the source for the particuler SP level is available under the same conditions as the year-old installer ISO is available). But in this case I would really love to be proven wrong.
Re: Clarity on current status of Scientific Linux build
On 06/27/2014 06:29 PM, Mark Rousell wrote: And yet it most certainly *has* taken on a new form. That changes things. The threads about it on this mail list would not exist if there had not been such a substantive, real world, change. On February 29, 2012, CentOS and SL both stopped support for version 4 of their respective distributions. However, Red Hat still has Extended Lifecycle Support for RHEL4 until February 28, 2015. Where are those SRPMS? Subscribers to the Extended Support can get them, but they're not publicly available, and never have been to the best of my knowledge. RHEL3 was supported by the EUS mechanism until January of 2014, yet CentOS 3 went out of support October 31, 2010 (can't rebuild if there's no public source from which to rebuild). That's a period of over three years where subscribers could get packages and SRPMS that were not available to the public. Again, this is not a new issue in general; it's just now impacting more people than before who are surprised by something that's been around for a long time. From the CentOS mailing list, back in May of 2012: On 05/18/2012 04:32 PM, Dennis Jacobfeuerborn wrote: Hi, I just learned that there exists a z-stream channel upstream that apparently carries some important bugfixes. Does anyone know what the policies are for this channel and how this relates to centos releases? Regards, Dennis The Z-Stream channels contain nothing important ... in fact they are not even released publicly. Z-Stream is security updates that you can apply to that stream and stay on an older point release. So, they would be the samba updates for the 5.6.z channel and be able to stay on 5.6 instead of moving to 5.7/5.8. However, like I said before, it is moot point because Red hat does not release the Z-Stream Source code publicly ... just like they do not release the EUS code publicly. If you want those kinds of services, you will need to get them from Red Hat on as a paid service. BUT, and I want to make sure everyone understands this, the Z-Stream items are not things that you do not get in the main (regular) tree ... they are just some security updates that are already rolled into the main tree that are also back ported an older, paid for, stabilized tree. Here is a link to read about the Z-Stream offerings: https://access.redhat.com/support/policy/updates/errata/#vii Again, these z-streams are not allowed to be rebuilt and not offered to the public, but they are also not anything that is required to be up to date security wise. They are just a slower moving subscription service offered as an add on service with additional cost to RHEL customers by Red Hat. If you need what this service offers (a slower update cycle for a specific point release version) that still has updates backported, then it might be worth the RHEL subscription and the added zstream subscription ... but since it is not released publicly, it is not a service CentOS can offer.
Re: Clarity on current status of Scientific Linux build
On 27/06/2014 23:45, Lamar Owen wrote: On 06/27/2014 06:29 PM, Mark Rousell wrote: And yet it most certainly *has* taken on a new form. That changes things. The threads about it on this mail list would not exist if there had not been such a substantive, real world, change. On February 29, 2012, CentOS and SL both stopped support for version 4 of their respective distributions. However, Red Hat still has Extended Lifecycle Support for RHEL4 until February 28, 2015. Where are those SRPMS? Subscribers to the Extended Support can get them, but they're not publicly available, and never have been to the best of my knowledge. RHEL3 was supported by the EUS mechanism until January of 2014, yet CentOS 3 went out of support October 31, 2010 (can't rebuild if there's no public source from which to rebuild). That's a period of over three years where subscribers could get packages and SRPMS that were not available to the public. Again, this is not a new issue in general; it's just now impacting more people than before who are surprised by something that's been around for a long time. Yup, I do take your point. Nevertheless, I still cannot help but observe that: a) It's a new issue in the specific context in which it matters here (as I said, if it wasn't a new issue in this context then there would not be the problem that is at hand), b) the comments by Bradley Kuhn and others back in 2011 do not fully apply to the situation at hand now (even though it is a longstanding issue in general), and c) as I said in my message posted at 23:41:46 +0100, just because it is a longstanding issue that is increasingly common practice does not mean that it is acceptable or that it will necessarily stand if well challenged. It is all too easy for people to become inured to issues like these and think that they are an inevitability or fully legal just because there has been no real challenge to them, just because they are there. Historical lack of action does not necessarily legitimise, justify or explain current or future lack of action. Opinions can and do change.
Re: Clarity on current status of Scientific Linux build
On 27/06/2014 23:41, Mark Rousell wrote: And then, finally, the banking industry lost a court case and the government regular got round to doing something about it. What had been totally accepted, barely questioned, common practice was outlawed and improperly taken fees had to be paid back. s/government regular/government regulator/
Re: Clarity on current status of Scientific Linux build
On 06/22/2014 02:41 PM, Nico Kadel-Garcia wrote: On Sun, Jun 22, 2014 at 4:42 PM, Mark Rousell markrlon...@hotmail.co.uk wrote: I've been following the discussions on this list about the changes in RHEL's source availability and I'd like to confirm my understanding of the current situation. Someone on another mail list made this comment: RedHat have said that they'll not be releasing source RPMs any more, so the response by the Scientific Linux people has more or less been Either use CentOS or our very own re-packaged CentOS thingie. This is incorrect (in terms of both statements that it makes), isn't it. Here is my current understanding. Please feel free to correct or confirm:- 1) RH now makes SRPMs available only to customers (but SRPMs are nevertheless still available on those terms). 2) The RHEL source is publicly also available on git.centos.org. 3) But it is not *absolutely* crystal clear what on git.centos.org is pure unadulterated RHEL source and what is CentOS source. 4) The SL project is writing tools to automatically extract RHEL source from git.centos.org. 5) SL7 will therefore be based on RHEL7 and definitely not on CentOS. 6) Anything I've forgotten? Thanks to anyone who can help with this. Step 4 is not reliable, and may cause profound problems, without step 3. Without verifiable GPG signed tags, in fact, a malicious proxy could use any of the stolen SSL root certificates, sign a forged 'git.centos.org' SSL signature, and interprose their trojan software burdened git repository. Moving away from the public SRPM's is burdensome to rebuilders other than CentOS, at least without those steps. Please correct me if the statements below are in error. The SL distribution (re)packaging team are employed by Fermilab/CERN. These entities subscribe to RHEL, and thus can get the SRPMs that are genuine RHEL, not just CentOS. Can the SL repackagers, after building the source from the CentOS git repositories, compare this source with the actual RHEL source, and thus identify the sort of compromises and contamination that, say, a compromised SSL certificate and signature could permit? Although most SL sites do not have a RHEL license, and thus cannot be allowed to see the SRPMs, can a site which does do the comparison? If so, can a failure of the comparison be disclosed without revealing the actual contents of the RHEL SRPMs? Or, can such a failure (and thus probable compromise or professional incompetence on the part of the CentOS distributors) only be revealed to RH, forcing the community to be in limbo (using a source and binaries known to have failed comparison to RHEL)? Obviously, trivial differences, e.g., absence of RH logos and the like, are not a matter of concern. Yasha Karant
Re: Clarity on current status of Scientific Linux build
Le 22/06/2014 22:42, Mark Rousell a écrit : Here is my current understanding. Please feel free to correct or confirm:- 1) RH now makes SRPMs available only to customers (but SRPMs are nevertheless still available on those terms). 2) The RHEL source is publicly also available on git.centos.org. 3) But it is not*absolutely* crystal clear what on git.centos.org is pure unadulterated RHEL source and what is CentOS source. 4) The SL project is writing tools to automatically extract RHEL source from git.centos.org. 5) SL7 will therefore be based on RHEL7 and definitely not on CentOS. 6) Anything I've forgotten? It seems it is more likely that Scientific LInux 7 will become a Special Interest Group (SIG) of CentOS 7. See the presentations at the Hepix meeting in Annecy Le Vieux, last May, on SL 10 years, notably the ones from Connie Sieh and Jarek Polok: http://indico.cern.ch/event/274555/session/11/#20140519 Alain -- Administrateur Système/Réseau Laboratoire de Photonique et Nanostructures (LPN/CNRS - UPR20) Centre de Recherche Alcatel Data IV - Marcoussis route de Nozay - 91460 Marcoussis Tel : 01-69-63-61-34
Re: Clarity on current status of Scientific Linux build
On Mon, Jun 23, 2014 at 2:44 AM, Yasha Karant ykar...@csusb.edu wrote: On 06/22/2014 02:41 PM, Nico Kadel-Garcia wrote: On Sun, Jun 22, 2014 at 4:42 PM, Mark Rousell markrlon...@hotmail.co.uk wrote: I've been following the discussions on this list about the changes in RHEL's source availability and I'd like to confirm my understanding of the current situation. Someone on another mail list made this comment: RedHat have said that they'll not be releasing source RPMs any more, so the response by the Scientific Linux people has more or less been Either use CentOS or our very own re-packaged CentOS thingie. This is incorrect (in terms of both statements that it makes), isn't it. Here is my current understanding. Please feel free to correct or confirm:- 1) RH now makes SRPMs available only to customers (but SRPMs are nevertheless still available on those terms). 2) The RHEL source is publicly also available on git.centos.org. 3) But it is not *absolutely* crystal clear what on git.centos.org is pure unadulterated RHEL source and what is CentOS source. 4) The SL project is writing tools to automatically extract RHEL source from git.centos.org. 5) SL7 will therefore be based on RHEL7 and definitely not on CentOS. 6) Anything I've forgotten? Thanks to anyone who can help with this. Step 4 is not reliable, and may cause profound problems, without step 3. Without verifiable GPG signed tags, in fact, a malicious proxy could use any of the stolen SSL root certificates, sign a forged 'git.centos.org' SSL signature, and interprose their trojan software burdened git repository. Moving away from the public SRPM's is burdensome to rebuilders other than CentOS, at least without those steps. Please correct me if the statements below are in error. The SL distribution (re)packaging team are employed by Fermilab/CERN. These entities subscribe to RHEL, and thus can get the SRPMs that are genuine RHEL, not just CentOS. That seems very reasonable. I've not yet personally bought a subscription to RHEL 7 to verify SRPM access. I assume it's still using 'yum-rhn-setup', which is burdensomely slow compared to anonymous FTP or HTTP access. (I's been a busy week!) Also note that there will always be disparities between release versions of individual packages and what is at git.centos.org, due to migration delays. But I think yes, one can theoretically start from there. Can the SL repackagers, after building the source from the CentOS git repositories, compare this source with the actual RHEL source, and thus identify the sort of compromises and contamination that, say, a compromised SSL certificate and signature could permit? Although most SL sites do not have a RHEL license, and thus cannot be allowed to see the SRPMs, can a site which does do the comparison? If so, can a failure of the comparison In theory? I think yes. In practice? That's an automation nightmare. It also makes it awkward for SL to maintain their current vendor repository of SRPM's, with a direct copy of unmodified code from upstream that is automatically used along with the modified packages from SL. be disclosed without revealing the actual contents of the RHEL SRPMs? Or, can such a failure (and thus probable compromise or professional incompetence on the part of the CentOS distributors) only be revealed to RH, forcing the community to be in limbo (using a source and binaries known to have failed comparison to RHEL)? Obviously, trivial differences, e.g., absence of RH logos and the like, are not a matter of concern. Yasha Karant Those are precisely what would make the automation hard right now. It's very difficult to predict where, and precisely how, the rebranding changes would occur and in what packages. A simple consistent branching and tagging convention at git.centos.org, say of creating signed ''r7_pkg-version-relase.el6 pure imports or branched and resynced copies of the upstream SRPM contents would be very helpful and could address the faked SSL certificate man-in-the-middle attack problem that I've raised. Such tags could, in theory, be signed with Red Hat GPG keys from the RHEL installation media and subscription keys, rather than a CentOS specific tag.
Re: Clarity on current status of Scientific Linux build
On 06/23/2014 03:34 AM, Alain Péan wrote: Le 22/06/2014 22:42, Mark Rousell a écrit : 6) Anything I've forgotten? It seems it is more likely that Scientific LInux 7 will become a Special Interest Group (SIG) of CentOS 7. See the presentations at the Hepix meeting in Annecy Le Vieux, last May, on SL 10 years, notably the ones from Connie Sieh and Jarek Polok: http://indico.cern.ch/event/274555/session/11/#20140519 Given two CERN people, involved in SL for a long time, are now part of the CentOS Core this does seem likely. If anyone wants to see another effort that is ongoing, I encourage you to check out Russ Herrold's work on clefos, a link to which he has already posted.
Re: Clarity on current status of Scientific Linux build
Great resource/links Lamar, I especially took note of these two PDFs: http://indico.cern.ch/event/274555/session/11/contribution/39/material/slides/1.pdf (CentOS variant, however still building SL7 in parallel). http://indico.cern.ch/event/274555/session/11/contribution/54/material/slides/0.pdf (CentOS may just be fully adopted and no need for a custom Linux distribtution). Very intriguing. On Mon, Jun 23, 2014 at 9:15 AM, Lamar Owen lo...@pari.edu wrote: On 06/23/2014 03:34 AM, Alain Péan wrote: Le 22/06/2014 22:42, Mark Rousell a écrit : 6) Anything I've forgotten? It seems it is more likely that Scientific LInux 7 will become a Special Interest Group (SIG) of CentOS 7. See the presentations at the Hepix meeting in Annecy Le Vieux, last May, on SL 10 years, notably the ones from Connie Sieh and Jarek Polok: http://indico.cern.ch/event/274555/session/11/#20140519 Given two CERN people, involved in SL for a long time, are now part of the CentOS Core this does seem likely. If anyone wants to see another effort that is ongoing, I encourage you to check out Russ Herrold's work on clefos, a link to which he has already posted. -- http://stevenmiano.com/ Miano, Steven M. http://stevenmiano.com
Re: Clarity on current status of Scientific Linux build
I was at the HEPiX meeting at which those slides were presented and there was further discussion during the course of the week as to what would happen. RedHat/CentOS was also represented at that meeting in the person of Karanbir Singh. You should not presume that the presentations given at that meeting are the final word. You notice that nobody with a cern.ch or fnal.gov E-mail address has responded to this thread up until now. When they have something concrete they will respond with the details. Steve Timm It seems it is more likely that Scientific LInux 7 will become a Special Interest Group (SIG) of CentOS 7. See the presentations at the Hepix meeting in Annecy Le Vieux, last May, on SL 10 years, notably the ones from Connie Sieh and Jarek Polok: http://indico.cern.ch/event/274555/session/11/#20140519 Alain -- Administrateur Système/Réseau Laboratoire de Photonique et Nanostructures (LPN/CNRS - UPR20) Centre de Recherche Alcatel Data IV - Marcoussis route de Nozay - 91460 Marcoussis Tel : 01-69-63-61-34 -- Steven C. Timm, Ph.D (630) 840-8525 t...@fnal.gov http://home.fnal.gov/~timm/ Fermilab Scientific Computing Division, Scientific Computing Services Quad. Grid and Cloud Services Dept., Associate Dept. Head for Cloud Computing
Re: Clarity on current status of Scientific Linux build
well what I dont understand here is all of RHEL SRPMs are on a web server an can be downloaded if you have an entitlement. all you need is 1) the CA cert located here /usr/share/rhn/RHNS-CA-CERT on any Red Hat host. 2) the entitlement cert from subscription manager winch you can get off of access.redhat.com go to Subscriptions - Subscription Management - UNITs then click on the subscription you would like to use. you will see a Download button on the top left side of the screen. 3) on the page where you downloaded the certificate there is a sub tab called Content Set take the URL's listed there and prefix them with https://cdn.redhat.com if you connect with a browser you can see its just a standard yum repo which uses the certificates for authentication, so most yum mirroring tools will work just fine as long as it can supply the the PKI (entitlement) cert to their web server. On Mon, Jun 23, 2014 at 9:54 AM, Steven Timm t...@fnal.gov wrote: I was at the HEPiX meeting at which those slides were presented and there was further discussion during the course of the week as to what would happen. RedHat/CentOS was also represented at that meeting in the person of Karanbir Singh. You should not presume that the presentations given at that meeting are the final word. You notice that nobody with a cern.ch or fnal.gov E-mail address has responded to this thread up until now. When they have something concrete they will respond with the details. Steve Timm It seems it is more likely that Scientific LInux 7 will become a Special Interest Group (SIG) of CentOS 7. See the presentations at the Hepix meeting in Annecy Le Vieux, last May, on SL 10 years, notably the ones from Connie Sieh and Jarek Polok: http://indico.cern.ch/event/274555/session/11/#20140519 Alain -- Administrateur Système/Réseau Laboratoire de Photonique et Nanostructures (LPN/CNRS - UPR20) Centre de Recherche Alcatel Data IV - Marcoussis route de Nozay - 91460 Marcoussis Tel : 01-69-63-61-34 -- Steven C. Timm, Ph.D (630) 840-8525 t...@fnal.gov http://home.fnal.gov/~timm/ Fermilab Scientific Computing Division, Scientific Computing Services Quad. Grid and Cloud Services Dept., Associate Dept. Head for Cloud Computing
Re: Clarity on current status of Scientific Linux build
Please correct me if the comment below is in error. My understanding is that Red Hat has changed the rules for use of the official RHEL SRPMs, but still using the finest JDs and laws that money can be buy (as have many other for-profit corporations) and thus stay in compliance with letter of the the GPL, linux, etc., licenses, if not the spirit. Those SRPMs may no longer be used to build any installable/executable image other than for a machine that has a RHEL paid license,, even if all RH logos, etc., are removed. Only the evidently unverifiable source via a CentOS git repository may be used to build a competitor distribution for installation on other than a Red Hat licensed machine. My understanding is that this was for a twofold for-profit business purpose: force those of us who require a verifiable build chain from commercial supported enterprise sources to purchase a genuine Red Hat license; and to prevent real for-profit competitors, such as Oracle, from supplying a RHEL-based distribution. If SL ends up being just a CentOS SIG branch, then why continue with SL? And, if CentOS cannot be verified as a professional and faithful clone of RHEL, use CentOS only with the greatest trepidation and risk. Would Red Hat want CentOS compromised? No. But, CentOS would degenerate into an environment akin to Fedora -- something not sound enough for production use. Would CERN be willing to endorse published experimental data (e.g., Higgs boson results) that used CentOS without a proper verification chain of the source and build process? Yasha Karant On 06/23/2014 01:00 PM, Paul Robert Marino wrote: well what I dont understand here is all of RHEL SRPMs are on a web server an can be downloaded if you have an entitlement. all you need is 1) the CA cert located here /usr/share/rhn/RHNS-CA-CERT on any Red Hat host. 2) the entitlement cert from subscription manager winch you can get off of access.redhat.com go to Subscriptions - Subscription Management - UNITs then click on the subscription you would like to use. you will see a Download button on the top left side of the screen. 3) on the page where you downloaded the certificate there is a sub tab called Content Set take the URL's listed there and prefix them with https://cdn.redhat.com if you connect with a browser you can see its just a standard yum repo which uses the certificates for authentication, so most yum mirroring tools will work just fine as long as it can supply the the PKI (entitlement) cert to their web server. On Mon, Jun 23, 2014 at 9:54 AM, Steven Timm t...@fnal.gov wrote: I was at the HEPiX meeting at which those slides were presented and there was further discussion during the course of the week as to what would happen. RedHat/CentOS was also represented at that meeting in the person of Karanbir Singh. You should not presume that the presentations given at that meeting are the final word. You notice that nobody with a cern.ch or fnal.gov E-mail address has responded to this thread up until now. When they have something concrete they will respond with the details. Steve Timm It seems it is more likely that Scientific LInux 7 will become a Special Interest Group (SIG) of CentOS 7. See the presentations at the Hepix meeting in Annecy Le Vieux, last May, on SL 10 years, notably the ones from Connie Sieh and Jarek Polok: http://indico.cern.ch/event/274555/session/11/#20140519 Alain -- Administrateur Système/Réseau Laboratoire de Photonique et Nanostructures (LPN/CNRS - UPR20) Centre de Recherche Alcatel Data IV - Marcoussis route de Nozay - 91460 Marcoussis Tel : 01-69-63-61-34 -- Steven C. Timm, Ph.D (630) 840-8525 t...@fnal.gov http://home.fnal.gov/~timm/ Fermilab Scientific Computing Division, Scientific Computing Services Quad. Grid and Cloud Services Dept., Associate Dept. Head for Cloud Computing
Re: Clarity on current status of Scientific Linux build
On Mon, 23 Jun 2014, Paul Robert Marino wrote: well what I dont understand here is all of RHEL SRPMs are on a web server an can be downloaded if you have an entitlement. all you need is 1) the CA cert located here /usr/share/rhn/RHNS-CA-CERT on any Red Hat host. 2) the entitlement cert from subscription manager winch you can get off of access.redhat.com go to Subscriptions - Subscription Management - UNITs then click on the subscription you would like to use. you will see a Download button on the top left side of the screen. 3) on the page where you downloaded the certificate there is a sub tab called Content Set take the URL's listed there and prefix them with https://cdn.redhat.com if you connect with a browser you can see its just a standard yum repo which uses the certificates for authentication, so most yum mirroring tools will work just fine as long as it can supply the the PKI (entitlement) cert to their web server. Exactly, if it is easy to download SRPM packages from RHN (provided you have the necessary funding to pay for various entitlements). Then the oft-repeated statement that the reason for not making the SRPMs publicly available as before, is to prevent competitors (i.e. Oracle) from being able to rebuild RHEL. Well, if anyone is able to pay for entitlements, it surely is Oracle and the likes. So in essence this change only harms community projects who may not have the yearly funding for the various entitlements (incl. RHSCL, HA, ...) Or what am I missing here ? -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, cont...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: Clarity on current status of Scientific Linux build
On Mon, Jun 23, 2014 at 4:00 PM, Paul Robert Marino prmari...@gmail.com wrote: well what I dont understand here is all of RHEL SRPMs are on a web server an can be downloaded if you have an entitlement. all you need is 1) the CA cert located here /usr/share/rhn/RHNS-CA-CERT on any Red Hat host. 2) the entitlement cert from subscription manager winch you can get off of access.redhat.com go to Subscriptions - Subscription Management - UNITs then click on the subscription you would like to use. you will see a Download button on the top left side of the screen. 3) on the page where you downloaded the certificate there is a sub tab called Content Set take the URL's listed there and prefix them with https://cdn.redhat.com Redistributing those, as SL does with its vendor directory, can be legally problematic. Some of the published source packages for our favorite vendor's clients are *not* freeware or open source that can be safely repackaged. They're excellent about freeing those packages up for inclusion in the public mirrors, but you can't just script get only the freely redistributable SRPM's. Also, the subscription only gets the packages for which you've bought a subscription: so if you want to run a mock build environment for 32-bit or 64-bit or different releases, and want to review and modify the source code for them, you're encumbered by the discrepancies between the older SRPM distribution and the new, hopefully quickly evolving, git based model. if you connect with a browser you can see its just a standard yum repo which uses the certificates for authentication, so most yum mirroring tools will work just fine as long as it can supply the the PKI (entitlement) cert to their web server. The PKI doesn't provide access to all relevant upstream repositories. The upstream web access, and worldwide mirrors, did. I'm quite saddened at the loss.
Clarity on current status of Scientific Linux build
I've been following the discussions on this list about the changes in RHEL's source availability and I'd like to confirm my understanding of the current situation. Someone on another mail list made this comment: RedHat have said that they'll not be releasing source RPMs any more, so the response by the Scientific Linux people has more or less been Either use CentOS or our very own re-packaged CentOS thingie. This is incorrect (in terms of both statements that it makes), isn't it. Here is my current understanding. Please feel free to correct or confirm:- 1) RH now makes SRPMs available only to customers (but SRPMs are nevertheless still available on those terms). 2) The RHEL source is publicly also available on git.centos.org. 3) But it is not *absolutely* crystal clear what on git.centos.org is pure unadulterated RHEL source and what is CentOS source. 4) The SL project is writing tools to automatically extract RHEL source from git.centos.org. 5) SL7 will therefore be based on RHEL7 and definitely not on CentOS. 6) Anything I've forgotten? Thanks to anyone who can help with this.
Re: Clarity on current status of Scientific Linux build
On Sun, Jun 22, 2014 at 4:42 PM, Mark Rousell markrlon...@hotmail.co.uk wrote: I've been following the discussions on this list about the changes in RHEL's source availability and I'd like to confirm my understanding of the current situation. Someone on another mail list made this comment: RedHat have said that they'll not be releasing source RPMs any more, so the response by the Scientific Linux people has more or less been Either use CentOS or our very own re-packaged CentOS thingie. This is incorrect (in terms of both statements that it makes), isn't it. Here is my current understanding. Please feel free to correct or confirm:- 1) RH now makes SRPMs available only to customers (but SRPMs are nevertheless still available on those terms). 2) The RHEL source is publicly also available on git.centos.org. 3) But it is not *absolutely* crystal clear what on git.centos.org is pure unadulterated RHEL source and what is CentOS source. 4) The SL project is writing tools to automatically extract RHEL source from git.centos.org. 5) SL7 will therefore be based on RHEL7 and definitely not on CentOS. 6) Anything I've forgotten? Thanks to anyone who can help with this. Step 4 is not reliable, and may cause profound problems, without step 3. Without verifiable GPG signed tags, in fact, a malicious proxy could use any of the stolen SSL root certificates, sign a forged 'git.centos.org' SSL signature, and interprose their trojan software burdened git repository. Moving away from the public SRPM's is burdensome to rebuilders other than CentOS, at least without those steps.
