22 Jan
2021
22 Jan
'21
9:02 p.m.
On 22/01/2021 20:45, Mike McGrath wrote:
On Fri, Jan 22, 2021 at 2:16 PM Phil Perry <pperry@elrepo.org mailto:pperry@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@centos.org <mailto:centos-devel@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@centos.org <mailto:centos-devel@centos.org> <mailto:centos-devel@centos.org <mailto:centos-devel@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).