Re: Docker
On Fri, 30 Jan 2015, Yasha Karant wrote: On 01/30/2015 10:32 AM, Brett Viren wrote: Yasha Karant ykar...@csusb.edu writes: For example, will a legally licensed MS Win application that does not run under Wine/CrossOver work under Docker under SL 7 the same as it would under VirtualBox with a full install of say MS Win 8.1 (soon MS Win 10)? Docker containers run on Linux (the kernel) so, no, if your application requires honest-to-badness MicroSoft Windows don't plan on using Docker. Can one make a Docker application package on the target host (e.g., SL 7) or does one need first a full install of the (virtual) base I don't know what target (host? guest?) means here. The application, say A, runs under environment (OS) X, not environment Y. One wants A under Y. The target is Y. Can one build A under Y using the appropriate chunks from X with Docker, or does one re-build (dockerise) A under X for target Y? In the first event, one only needs to be running Y; in the second event, one needs to be running X to build for Y. A Docker image is a full OS (minus the kernel). To start you write one line in a Dockerfile like: FROM fedora:20 and do a docker build You can follow up this line with additional instructions (such as yum install ...) to further populate. If you have a second image that shares some portion of these instructions, or as you add more instructions, any prior existing layer is reused. I don't find a lot of bases for SL but there are ways to add new base OSes from first principles (CMS has some scripts in github) and there are established ones for centos. -Brett. Presumably, any application that will run under CentOS, in particular, CentOS 7 that is the RHEL source release for other ports, such as SL 7, should be able to run under SL. My understanding is that SL 7 is not built from the actual RHEL 7 source that is used to build RHEL 7 that is licensed for fee, but from the RHEL packaged CentOS source (CentOS now effectively being a unit of Red Hat, a for-profit corporation) that is used to build CentOS 7 (that, as with SL 7, is licensed for free as a binary installable executable system that requires no building from source per se). Yasha SL is built from the source that Red Hat has provided . It is built from the same source that all rebuilds can build from. There is no such thing as RHEL packaged CentOS source . -- Connie J. Sieh Computing Services Specialist III Fermi National Accelerator Laboratory 630 840 8531 office http://www.fnal.gov cs...@fnal.gov
Re: Docker
On 02/02/2015 11:35 AM, Connie Sieh wrote: On Fri, 30 Jan 2015, Yasha Karant wrote: On 01/30/2015 10:32 AM, Brett Viren wrote: Yasha Karant ykar...@csusb.edu writes: For example, will a legally licensed MS Win application that does not run under Wine/CrossOver work under Docker under SL 7 the same as it would under VirtualBox with a full install of say MS Win 8.1 (soon MS Win 10)? Docker containers run on Linux (the kernel) so, no, if your application requires honest-to-badness MicroSoft Windows don't plan on using Docker. Can one make a Docker application package on the target host (e.g., SL 7) or does one need first a full install of the (virtual) base I don't know what target (host? guest?) means here. The application, say A, runs under environment (OS) X, not environment Y. One wants A under Y. The target is Y. Can one build A under Y using the appropriate chunks from X with Docker, or does one re-build (dockerise) A under X for target Y? In the first event, one only needs to be running Y; in the second event, one needs to be running X to build for Y. A Docker image is a full OS (minus the kernel). To start you write one line in a Dockerfile like: FROM fedora:20 and do a docker build You can follow up this line with additional instructions (such as yum install ...) to further populate. If you have a second image that shares some portion of these instructions, or as you add more instructions, any prior existing layer is reused. I don't find a lot of bases for SL but there are ways to add new base OSes from first principles (CMS has some scripts in github) and there are established ones for centos. -Brett. Presumably, any application that will run under CentOS, in particular, CentOS 7 that is the RHEL source release for other ports, such as SL 7, should be able to run under SL. My understanding is that SL 7 is not built from the actual RHEL 7 source that is used to build RHEL 7 that is licensed for fee, but from the RHEL packaged CentOS source (CentOS now effectively being a unit of Red Hat, a for-profit corporation) that is used to build CentOS 7 (that, as with SL 7, is licensed for free as a binary installable executable system that requires no building from source per se). Yasha SL is built from the source that Red Hat has provided . It is built from the same source that all rebuilds can build from. There is no such thing as RHEL packaged CentOS source . -- Connie J. Sieh Computing Services Specialist III Fermi National Accelerator Laboratory 630 840 8531 office http://www.fnal.gov cs...@fnal.gov Please correct me if I am in error. RHEL, binary licensed for fee, is built from a source that RH does not seem to release. Rather, RH releases, through the RH subsidiary CentOS and a GIT mechanism, a source for all rebuilds, supposedly including CentOS. Thus, SL and CentOS are built from the same source, but the actual RHEL source may or not may in fact (claims to the contrary notwithstanding) be the same, as no one outside of RH or a RH licensee actually sees the source for RHEL. If RHEL also is built through a GIT mechanism, I am assuming that the Internet path to the RHEL GIT is not the same as that to the public rebuildable CentOS GIT. In the event that Fermilab or CERN has licensed the actual RHEL 7 source as a RHEL licensee, would personnel at either non-RH entity be allowed to comment if in fact there were non-trivial differences between the actual RHEL 7 source and the rebuildable CentOS 7 source? Trivial differences would be the presence of RH logos and splash screens, each of which is replaced by whatever the rebuilder is using (SL for the SL rebuild) -- but all of the internal intellectual property references in the source code still (presumably) mentions RH in both the actual RHEL 7 source and the CentOS 7 rebuildable source. Yasha Karant
Re: Docker
On Mon, 2 Feb 2015, Yasha Karant wrote: On 02/02/2015 11:35 AM, Connie Sieh wrote: On Fri, 30 Jan 2015, Yasha Karant wrote: On 01/30/2015 10:32 AM, Brett Viren wrote: Yasha Karant ykar...@csusb.edu writes: For example, will a legally licensed MS Win application that does not run under Wine/CrossOver work under Docker under SL 7 the same as it would under VirtualBox with a full install of say MS Win 8.1 (soon MS Win 10)? Docker containers run on Linux (the kernel) so, no, if your application requires honest-to-badness MicroSoft Windows don't plan on using Docker. Can one make a Docker application package on the target host (e.g., SL 7) or does one need first a full install of the (virtual) base I don't know what target (host? guest?) means here. The application, say A, runs under environment (OS) X, not environment Y. One wants A under Y. The target is Y. Can one build A under Y using the appropriate chunks from X with Docker, or does one re-build (dockerise) A under X for target Y? In the first event, one only needs to be running Y; in the second event, one needs to be running X to build for Y. A Docker image is a full OS (minus the kernel). To start you write one line in a Dockerfile like: FROM fedora:20 and do a docker build You can follow up this line with additional instructions (such as yum install ...) to further populate. If you have a second image that shares some portion of these instructions, or as you add more instructions, any prior existing layer is reused. I don't find a lot of bases for SL but there are ways to add new base OSes from first principles (CMS has some scripts in github) and there are established ones for centos. -Brett. Presumably, any application that will run under CentOS, in particular, CentOS 7 that is the RHEL source release for other ports, such as SL 7, should be able to run under SL. My understanding is that SL 7 is not built from the actual RHEL 7 source that is used to build RHEL 7 that is licensed for fee, but from the RHEL packaged CentOS source (CentOS now effectively being a unit of Red Hat, a for-profit corporation) that is used to build CentOS 7 (that, as with SL 7, is licensed for free as a binary installable executable system that requires no building from source per se). Yasha SL is built from the source that Red Hat has provided . It is built from the same source that all rebuilds can build from. There is no such thing as RHEL packaged CentOS source . -- Connie J. Sieh Computing Services Specialist III Fermi National Accelerator Laboratory 630 840 8531 office http://www.fnal.gov cs...@fnal.gov Please correct me if I am in error. RHEL, binary licensed for fee, is built from a source that RH does not seem to release. Rather, RH releases, through the RH subsidiary CentOS and a GIT mechanism, a source for all rebuilds, supposedly including CentOS. Thus, SL and CentOS are built from the same source, but the actual RHEL source may or not may in fact (claims to the contrary notwithstanding) be the same, as no one outside of RH or a RH licensee actually sees the source for RHEL. If RHEL also is built through a GIT mechanism, I am assuming that the Internet path to the RHEL GIT is not the same as that to the public rebuildable CentOS GIT. In the event that Fermilab or CERN has licensed the actual RHEL 7 source as a RHEL licensee, would personnel at either non-RH entity be allowed to comment if in fact there were non-trivial differences between the actual RHEL 7 source and the rebuildable CentOS 7 source? Trivial differences would be the presence of RH logos and splash screens, each of which is replaced by whatever the rebuilder is using (SL for the SL rebuild) -- but all of the internal intellectual property references in the source code still (presumably) mentions RH in both the actual RHEL 7 source and the CentOS 7 rebuildable source. Yasha Karant I compared all of the RHEL 7 RC src.rpm's that were available on ftp.redhat.com with the reconsituted src.rpm's from git.centos.org and they were the same. -- Connie J. Sieh Computing Services Specialist III Fermi National Accelerator Laboratory 630 840 8531 office http://www.fnal.gov cs...@fnal.gov
Re: Docker
Yasha writes; Please correct me if I am in error. RHEL, binary licensed for fee, is built from a source that RH does not seem to release. You've already got it backwards: Red Hat publishes as much as possible as open source, preferably even freeware, and has been a champion if turning closed source into open source and freeware. Look at openjdk and all the kernel drivers that they publish, they've been *very* good about this. And no, they don't license *bnaries* for free, they publish source for free. Rather, RH releases, through the RH subsidiary CentOS and a GIT mechanism, a source for all rebuilds, supposedly including CentOS. Before RHEL, all the way up to Red HAt 9, they published SRPM and binaries for everything they could. Java was the most notorious exception, but there were various commercial tools they licensed for commercial subscribers they could not publish source for. Starting with RHEL up until RHEL 7, they published the SRPM's themselves worldwide. Scientific Linux, CentOS, the old whitebox Linux, and some hobby projects all reviewed the SRPM's, rebuilt binaries with their own GPG signatures, carefully stripped out trademark and copyrighted material they could not themselves republish, and provided invaluable tools in the best free software and open source tradidions. Thus, SL and CentOS are built from the same source, but the actual RHEL source may or not may in fact (claims to the contrary notwithstanding) be the same, as no one outside of RH or a RH licensee actually sees the source for RHEL. Red Hat claims the source at git.centos.org for RHEL 7, labeled as imports in the logs, is what they used. CentOS and SL are doing what they used to do: rebuilding from what Red Hat says is their source. It's conceivable that RHEL lied,and continues to lie about what is in the new git repositories and in their old SRPM's, and that they are not in fact the source used for the published binaries they provide to commercial clients. But they've been very good about their software publication, and I have professional confidence in them. I do have concerns about the new git.centos.org based publication. It's unnecessary, and there are no GPG tags on this source tree. So there is a real risk of manipulation oafter the repo is set up, especially if you use a third party clone of git.centos.org. I've raised this any number of times and gotten no satisfactory response to my concern. But I'm not so worried about CentOS project owners manipulating their own repos, some of them are Red Hat employees and the consequences would be devastating if they got caught manipulating things. I'm worried about third party repositories, clones or rsync mirrors or git access funneled through proxies that can effectively be man in the middle attacked. Saying but it has an SSL key, don'e you think we know how to run a secure site, as some of the current maintainers have done misses the point. SSL k eys can be forged. (There are too many stolen signature authorities to make a valid key with!). And mirrors or clones cannot be verified without enormous effort without GPG tags. . If RHEL also is built through a GIT mechanism, I am assuming that the Internet path to the RHEL GIT is not the same as that to the public rebuildable CentOS GIT. It's apparently not an internet path. It's a Red Hat internal network path, since it's now the official publication venue for RHEL 7 source code. In the event that Fermilab or CERN has licensed the actual RHEL 7 source as a RHEL licensee, would personnel at either non-RH entity be allowed to comment if in fact there were non-trivial differences between the actual RHEL 7 source and the rebuildable CentOS 7 source? Trivial differences would be the presence of RH logos and splash screens, each of which is replaced by whatever the rebuilder is using (SL for the SL rebuild) -- but all of the internal intellectual property references in the source code still (presumably) mentions RH in both the actual RHEL 7 source and the CentOS 7 rebuildable source. Yasha Karant The concern has been raised before, and people are checking precisely that. And the new import we call it a tag by mentioning it in the log, but it's not really a tag technique that CentOS is using has been verified by various folks in various projects. I've done a few myself (including Samba!)
Re: Docker
Yasha Karant ykar...@csusb.edu writes: On 01/30/2015 10:32 AM, Brett Viren wrote: The application, say A, runs under environment (OS) X, not environment Y. One wants A under Y. The target is Y. Can one build A under Y using the appropriate chunks from X with Docker, or does one re-build (dockerise) A under X for target Y? In the first event, one only needs to be running Y; in the second event, one needs to be running X to build for Y. I guess there are many approaches. I can think of at least these: 1) Build fully static A under X and use Docker to set up target Y just so that you can test that A works. End user doesn't know about Docker. 2) Build A under X, A' under Y, A'' under Z (maybe static, maybe shared) and distribute A, A', A''. Use Docker simply to provide convenient build platforms X, Y, Z. End user doesn't know about Docker. (This is my approach). 3) Build A in an X Docker image and distribute that entire image as a binary executable Docker container. End user is required to have Docker on the target Y to run the image but doesn't otherwise care what is in the image - that is, running the image appears to just be an executable. This is a heavy solution but if application A is huge, it might be a practical way to go. 4) As (3) but, for whatever reason, the user treats the image as an open box and exec's a shell instead of exec'ing the application. Presumably, any application that will run under CentOS, in particular, CentOS 7 that is the RHEL source release for other ports, such as SL 7, should be able to run under SL. It depends. As you first asked in this thread, any required shared libraries need to be available and compatible. If the application exec's any external executables they obviously need to exist. Likewise, if the application loads Python or other interpreters then there may be some modules required. My understanding is that SL 7 is not built from the actual RHEL 7 source that is used to build RHEL 7 that is licensed for fee, but from the RHEL packaged CentOS source (CentOS now effectively being a unit of Red Hat, a for-profit corporation) that is used to build CentOS 7 (that, as with SL 7, is licensed for free as a binary installable executable system that requires no building from source per se). I'm not a lawyer and quickly am underwater when it comes to licensing details. All I (think I) know is that if someone gives me a binary distributed under the GPL, they must provide me on request the source code with which I may do as I please (consistent with the GPL). -Brett. pgp9aDBt7TznY.pgp Description: PGP signature
