[CentOS-devel] First round of RHEL programs announced

On 22/01/2021 20:45, Mike McGrath wrote:
> 
> 
> On Fri, Jan 22, 2021 at 2:16 PM Phil Perry <pperry at elrepo.org 
> <mailto:pperry at elrepo.org>> wrote:
> 
>     On 22/01/2021 18:13, Leon Fauster via CentOS-devel wrote:
>      > Am 22.01.21 um 14:53 schrieb Neal Gompa:
>      >> On Fri, Jan 22, 2021 at 8:32 AM Leon Fauster via CentOS-devel
>      >> <centos-devel at centos.org <mailto:centos-devel at centos.org>> wrote:
>      >>>
>      >>> Am 22.01.21 um 14:18 schrieb Mike McGrath:
>      >>>>
>      >>>>
>      >>>> On Fri, Jan 22, 2021 at 5:39 AM Peter Eckel via CentOS-devel
>      >>>> <centos-devel at centos.org <mailto:centos-devel at centos.org>
>     <mailto:centos-devel at centos.org <mailto:centos-devel at centos.org>>>
>     wrote:
>      >>>>
>      >>>>      Hi Mike,
>      >>>>
>      >>>>      thanks for the information, this is at least partly good
>     news.
>      >>>>
>      >>>>      Whet I currently can't figure out - maybe you have some
>      >>>> information
>      >>>>      about it - is the situation with, e.g. Vagrant.
>      >>>>
>      >>>>      I rely a lot on Vagrant boxes for development and testing
>     work,
>      >>>> and
>      >>>>      up to now the situation with RHEL is that there are none,
>     probably
>      >>>>      due to legal issues and because RHN registration doesn't
>     mix well
>      >>>>      with instances created and deleted on-the-fly. The obvious
>      >>>> solution
>      >>>>      is - or rather, was - CentOS, which so far fit my needs.
>     CentOS
>      >>>>      Stream in all likelyhood will not fill that gap.
>      >>>>
>      >>>>      Are there plans for making it possible to create Vagrant
>     boxes and
>      >>>>      similar items based on "FreeRHEL"?
>      >>>>
>      >>>>
>      >>>> I don't think we're going to ship vagrant images directly.  I know
>      >>>> several customers are using vagrant with RHEL and we've got
>     some people
>      >>>> using it internally.  We've got some kbase and docs on the
>     customer
>      >>>> portal (which you do have access to with these developer program
>      >>>> accounts).
>      >>>>
>      >>>>
>     https://access.redhat.com/documentation/en-us/red_hat_container_development_kit/2.2/html/getting_started_guide/introducing_red_hat_container_development_kit
>     <https://access.redhat.com/documentation/en-us/red_hat_container_development_kit/2.2/html/getting_started_guide/introducing_red_hat_container_development_kit>
> 
>      >>>>
>      >>>>
>     <https://access.redhat.com/documentation/en-us/red_hat_container_development_kit/2.2/html/getting_started_guide/introducing_red_hat_container_development_kit
>     <https://access.redhat.com/documentation/en-us/red_hat_container_development_kit/2.2/html/getting_started_guide/introducing_red_hat_container_development_kit>>
> 
>      >>>>
>      >>>>
>      >>>> de-registering a box could be made part of the teardown
>     process I would
>      >>>> think.  I've also heard stale boxes (IE: registered systems
>     that are no
>      >>>> longer check-ing in) have some way to do an automated cleanup
>     after 2
>      >>>> days or so?  I'm a little confused on how that process works
>     though,
>      >>>> its
>      >>>> actually on my todo list to check out in February when the new
>     simpler
>      >>>> content access is in place.
>      >>>>
>      >>>
>      >>> Honestly not so much experience with mock but what about mock build
>      >>> environments. While mock bootstraps the context to build rpms quite
>      >>> often, there is the need to access the repos. Does mock support
>     "login"
>      >>> into such "RH accounts" and logout (deregister)?
>      >>>
>      >>> CentOS with there mirrors was quite easy in this case.
>      >>>
>      >>
>      >> It does not, unfortunately. You need to have subscription-manager
>      >> configured on your host to be able to use RHEL content with Mock
>      >> (which is a bit of a hassle in its own right...).
>      >>
>      >
>      > Thanks, I was afraid reading this. So free RHEL make it more worse.
>      >
> 
>     If you are building a lot of stuff in mock, you will almost certainly
>     want to set up your own internal mirror of RHEL content for mock to
>     build against.
> 
> 
> I asked around about this a bit.  I think you're allowed to download 
> whatever content you are entitled to and keep an internal mirror as long 
> as it is protected somehow (IE: don't let unentitled people get access 
> to it as I think you'd run afoul of redistribution problems).   In other 
> words, if you're downloading a repo and using it for your purposes, I 
> don't think that violates our agreement.  It turns out this is the thing 
> that makes satellite possible.
> 
>             -Mike
> 

Yes, absolutely, and to clarify, that's exactly what I meant by 
"internal mirror" just for mock to build against (populate the mock 
buildroot).