Re: Docker

[David Sommerseth]

On 03/02/15 00:25, 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  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, 

No, you are wrong.  You pay for a subscription, which may include
updates, support and so on, depending on what you sign up for.  You
don't pay for a license at all, only subscription.  Which is what Red
Hat calls it all over their site.



> is built from a source that RH does not seem to release. 




--
kind regards,

David Sommerseth

-- 
kind regards,

David Sommerseth

Re: Docker

[Yasha Karant]

On 02/03/2015 05:00 AM, David Sommerseth wrote:

On 03/02/15 00:25, 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  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,

No, you are wrong.  You pay for a subscription, which may include
updates, support and so on, depending on what you sign up for.  You
don't pay for a license at all, only subscription.  Which is what Red
Hat calls it all over their site.




is built from a source that RH does not seem to release.




--
kind regards,

David Sommerseth



To be clear, the legal language may be "license for fee", "subscription 
for fee", or "stand on your head for fee".   The operative language is 
"FEE".  The RHEL 7 binary executable and the RPM updates are not 
available from Red Hat (not CentOS, SL, etc.) except to those who pay a 
fee, irrespective of whether or not one wants any "support".  Note that 
SL, in the USA, is a Fermilab project, and thus is ported and/or 
"supported" at public expense under grants and contracts ultimately from 
USA Federal agencies (in addition to whatever private/corporate funding 
may be provided under separate arrangement).  The above are not to be 
regarded as negative or positive comments about the business practices 
of Red Hat that is a for-profit corporation and thus needs profit and 
cash flow models and mechanisms.


Regards,

Yasha Karant

Re: Docker

[Jamie Duncan]

I've never heard of Open Binary Licenses, or Open Package Licenses.
Why does this keep coming up?

On Tue, Feb 3, 2015 at 11:12 AM, Yasha Karant  wrote:

> On 02/03/2015 05:00 AM, David Sommerseth wrote:
>
>> On 03/02/15 00:25, 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  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,
>>>
>> No, you are wrong.  You pay for a subscription, which may include
>> updates, support and so on, depending on what you sign up for.  You
>> don't pay for a license at all, only subscription.  Which is what Red
>> Hat calls it all over their site.
>>
>> 
>>
>>  is built from a source that RH does not seem to release.
>>>
>> 
>>
>>
>> --
>> kind regards,
>>
>> David Sommerseth
>>
>>
> To be clear, the legal language may be "license for fee", "subscription
> for fee", or "stand on your head for fee".   The operative language is
> "FEE".  The RHEL 7 binary executable and the RPM updates are not available
> from Red Hat (not CentOS, SL, etc.) except to those who pay a fee,
> irrespective of whether or not one wants any "support".  Note that SL, in
> the USA, is a Fermilab project, and thus is ported and/or "supported" at
> public expense under grants and contracts ultimately from USA Federal
> agencies (in addition to whatever private/corporate funding may be provided
> under separate arrangement).  The above are not to be regarded as negative
> or positive comments about the business practices of Red Hat that is a
> for-profit corporation and thus needs profit and cash flow models and
> mechanisms.
>
> Regards,
>
> Yasha Karant
>



-- 
Thanks,

Jamie Duncan
@jamieeduncan

Re: Docker

[David Sommerseth]

On 03/02/15 17:12, Yasha Karant wrote:
> To be clear, the legal language may be "license for fee", "subscription
> for fee", or "stand on your head for fee".   The operative language is
> "FEE".  The RHEL 7 binary executable and the RPM updates are not
> available from Red Hat (not CentOS, SL, etc.) except to those who pay a
> fee, irrespective of whether or not one wants any "support".

This is an odd way to twist things.  You may register FOR FREE at
 and get the possibility to download install
images which gives your 30 days access - FOR FREE.  But, yes, you are
right, to get the recent updates after those 30 days, you have to pay a fee.

And just to have that said: There are nothing in any GPL or F/OSS
licenses that requires binaries to be made available without any costs.
 What might be required (such as GPL licensed software) is access to the
source code.

And, just to mention it, support is optional, as there is a self-support
alternative these days.



> The above are not to be regarded as negative or positive comments about
> the business practices of Red Hat that is a for-profit corporation and
> thus needs profit and cash flow models and mechanisms.

Yes, Red Hat is a for-profit company.  But lets not forget that they are
also providing the paychecks to several thousand employees all over the
globe, giving them a possibility to contribute back to the community
through Fedora, RHEL and a lot of different upstream projects.  In
addition they provide access to the source RPMs for all of the software
they release, which enables projects like SL.


David S.

Re: Docker

[Tom H]

On Mon, Feb 2, 2015 at 6:25 PM, Yasha Karant  wrote:
> On 02/02/2015 11:35 AM, Connie Sieh wrote:
>> On Fri, 30 Jan 2015, Yasha Karant wrote:
>>>
>>> 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).
>>
>> 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" .
>
> 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.

1) RH doesn't license RHEL; it provides subscriptions to RHEL. The
individual have licenses...

2) What might be the rationale for RH to release SRPMs (as SRPMs
previously and as a git tree now) that are different from the SRPMs
from which it builds RHEL?!

3) The RPMs that are distributed by SL and CentOS are sometimes
different from the RPMs that are distributed by RH because, for
example, RH might use brpackage-x.y-1.el7 to satisfy
package-i.j-k.el7's BuildRequires but might only release
brpackage-x.y-2.el7. So SL and CentOS have to use the latter to build
package-i.j-k.el7's.

Re: Docker

[prmarino1]

Ok for clarification the subscription is a subscription for support not the 
software per the terms of the GPL license.

In no way is Red Hat required to provide BINARY RPM's SRPM's ‎or even the spec 
files to generate RPM, however in the past they did. Now they still provide the 
patches and spec files but they don package them for you because that is part 
of the "support" you get with the subscription and the GPL and the GNU 
manifesto clearly states that they are not only allowed to do this but in fact 
this was a recommended business model for free speech software since long 
before the Linux kernel was created.

Red hat is doing nothing wrong and reality has a long standing history of going 
above and beyond what they are required to do for the community‎. 

By the way the Pre RHEL version of Red Hat still exists they just renamed it 
Fedora and stopped charging for box sets because once people started getting 
DSL lines and CD/DVD burners it didn't make sence to still attempt to put it in 
a pretty box in a retail store and charge $90 for a bunch of CD's you could 
have downloaded over your 28.8k modem if you were willing to tie up a phone 
line for a few days.


Sent from my BlackBerry 10 smartphone.
  Original Message  
From: Tom H
Sent: Tuesday, February 3, 2015 12:18
To: SL Users
Subject: Re: Docker

On Mon, Feb 2, 2015 at 6:25 PM, Yasha Karant  wrote:
> On 02/02/2015 11:35 AM, Connie Sieh wrote:
>> On Fri, 30 Jan 2015, Yasha Karant wrote:
>>>
>>> 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).
>>
>> 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" .
>
> 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.

1) RH doesn't license RHEL; it provides subscriptions to RHEL. The
individual have licenses...

2) What might be the rationale for RH to release SRPMs (as SRPMs
previously and as a git tree now) that are different from the SRPMs
from which it builds RHEL?!

3) The RPMs that are distributed by SL and CentOS are sometimes
different from the RPMs that are distributed by RH because, for
example, RH might use brpackage-x.y-1.el7 to satisfy
package-i.j-k.el7's BuildRequires but might only release
brpackage-x.y-2.el7. So SL and CentOS have to use the latter to build
package-i.j-k.el7's.

Re: Docker

[Nico Kadel-Garcia]

On Tue, Feb 3, 2015 at 12:17 PM, Tom H  wrote:

> 1) RH doesn't license RHEL; it provides subscriptions to RHEL. The
> individual have licenses...

I think you meant "individual components have licenses", It's cool.

> 2) What might be the rationale for RH to release SRPMs (as SRPMs
> previously and as a git tree now) that are different from the SRPMs
> from which it builds RHEL?!

The most likely real reason would be accidental error. `Some SuSE 9
SRPM's for example, sometimes included different components form the
source tree in the SRPM depending on build options. Fedora and RHEL
have been very good about including *all* compnents, even if only used
for particular OS version or builds. I applaud them for consistency.

The other *potential* source of such a discrepancy would be a
manipulative weasel hiding hacks or concealing features incompatible
with patent or copyright law. I'm not saying this is *likely*, our
favorite upstream vendor has been really good about this, and I've met
enough of their employees in the Boston area to have some confidence
in them to not pull this sort of stunt. and if they got caught it
would be disastrous for public confidence and for their business

The potential of "trojan" binaries, even GPG signed trojan binaries,
are was one of the big reasons that when there have been any security
concerns about the upstream build servers thaey are so quickly taken
out of service, new build environments built, and the GPG keys
updated. Our friends at our favorite upstream vendor have been very
good about trying to deal with any question of the provenance of code.

> 3) The RPMs that are distributed by SL and CentOS are sometimes
> different from the RPMs that are distributed by RH because, for
> example, RH might use brpackage-x.y-1.el7 to satisfy
> package-i.j-k.el7's BuildRequires but might only release
> brpackage-x.y-2.el7. So SL and CentOS have to use the latter to build
> package-i.j-k.el7's.

Yeah, managing the relevant mock or koji resources can get a bit
tricky. There are also a few SRPM's in Red Hat's public repositories
up until now that have lacked necessary build components in any public
repository I've been able to find.  I particularly noticed the issue
when trying to compile Java based tools from the top level of
http://ftp.redhat.com/pub/redhat/ That's the sort of thing that makes
me throw up my hands and kick Java based applications out the door as
unsupportable.

But I'm also pretty picky.