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.
Fwd: Yet another BMC vulnerability (SuperMicro)
As a member of LOPSA http://lopsa.org I recently got this message and I thought I'd share it with this group. I realize this isn't specific to SL but I wanted to make sure everyone is as aware as possible. Original Message Date: Fri, 20 Jun 2014 16:12:50 -0700 (PDT) From: Paul Heinlein To: t...@lists.lopsa.org Subject: [lopsa-tech] Supermicro IPMI mitigation You've undoubtedly seen reports of the vulnerability in Supermicro's BMC implementation that allows IPMI usernames and passwords to be retrieved via a simple HTTP GET query to port 49152: http://blog.cari.net/carisirt-yet-another-bmc-vulnerability-and-some-added-extras/ I ended up taking two different remediation tacks. First, in our local server room, all IPMI interfaces are connected to a single subnet. Our room is small enough that they're all connected to a single Cisco switch, but the same mitigation would work with a VLAN-based subnet. I created an access list that only allows tcp access to the http and https ports. All other tcp requests get blocked. More tricky was a single server we have running in a remote data center that I manage via IPMI. The Supermicro web interface allows firewall configuration based on source IP address, so most pokes at port 49152 would be rejected -- but our local network setup is such that a visitor to our office could conceivably contact that port. Thankfully it's Linux and iptables under the hood, so 1. Launch ssh session to remote BMC. 2. Upon login run shell sh to get a command-line shell. 3. # iptables -I INPUT -m tcp -p tcp --dport 49152 -j DROP 4. # iptables-save /nv/ipctrl/rultbl.sav I'm not yet clear what will happen to the new rule if we reconfigure the firewall from the web gui (presumably, it will get wiped out, but I'm just not sure) -- but for now it gives me some level of comfort. - Paul Heinlein heinl...@madboa.com 45°38' N, 122°6' W -- MCTMichael C Tiernan xmpp:mtier...@mit.edu +1 (617) 324-9173 MIT - Laboratory for Nuclear Science - http://www.lns.mit.edu High Perf Research Computing Facility at The Bates Linear Accelerator Please avoid sending me MS-Word or MS-PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
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: DELL server and hw Raid problem with latest 6.5 kernel
On 2014/06/23 11:34, Andras Horvath wrote:
On Tue, 17 Jun 2014 07:52:32 -0700
Patrick J. LoPresti lopre...@gmail.com wrote:
On Tue, Jun 17, 2014 at 1:25 AM, Andras Horvath m...@log69.com wrote:
I'm having problem with the latest kernel version for some time now. The previous kernel
version boots fine and everything works just well, but the latest kernel
(v2.6.32-431.17.1.el6.x86_64) cannot boot and Grub says something like trying to
reach blocks outside of partition and that's all the message there is and boot
hangs.
This sounds to me like your kernel has some blocks that lie beyond
what GRUB can read during boot (using the system BIOS). It worked
before because you got lucky; any time you reinstalled a kernel, you
were running the risk of some of the new boot image's blocks lying
outside the bootable range.
If this is correct, checking the inode number will not help. because
the problem the blocks inside the file itself, not the inode.
Possible fixes, in increasing order of difficulty:
Copy the kernel and initrd images until you get lucky again
See if your system BIOS has a setting related to booting from large disks
Reinstall grub with the --force-lba option
Reinstall the system, using an EFI boot partition (have fun)
Reinstall the system, creating a small (500M) /boot partition as the
first partition on the drive
That last is what I have done for years. I tried not doing so for my
last install on a large RAID -- figuring this is the 21st century --
and my system failed to boot. I reinstalled with a small /boot
partition and now it consistently works fine across dozens of
reinstalls. I do not know whether this is due to a buggy RAID BIOS or
something else, and I do not care...
Good luck.
- Pat
An update on my issue. The latest kernel update (2.6.32-431.20.3.el6.x86_64)
seems to have fixed my problem. The system boots fine without any grub or other
error message.
I hope it stays like this. Cheers and thanks for the help!
Andras
I recently installed a dual boot SL6 on top of the XP32 I had on the machine.
It's out in the last 64 megabytes on a two terabyte drive. It boots very well
going through ntldr to grubldr to Linux. That hints that even grub should be
quite happy at least in the first two terabytes of any disk or array of disks.
(This machine is a fakeraid to boot - something I am in the process of
changing if the 3Ware card I bought on E-Bay is going to work for me. Um, the
machine has PCI-X slots and is otherwise overpowered. So there's no sense
throwing it away when I can recycle it to run virtual machines for testing.)
{^_^} Joanne
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.
