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).