On Thu, Apr 28, 2022 at 11:38 PM Demi Marie Obenour
<demiobenour(a)gmail.com> wrote:
>
> On 4/28/22 07:09, Nico Kadel-Garcia wrote:
>> On Wed, Apr 27, 2022 at 9:08 PM Demi Marie Obenour
>> <demiobenour(a)gmail.com> wrote:
>>>
>>> On 4/27/22 07:40, Ewoud Kohl van Wijngaarden wrote:
>>>> On Tue, Apr 26, 2022 at 09:03:45PM -0500, Carl George wrote:
>>>>> On Tue, Apr 26, 2022 at 1:25 PM Ewoud Kohl van Wijngaarden
>>>>> <ewoud+fedora(a)kohlvanwijngaarden.nl> wrote:
>>>>>>
>>>>>> Hello everyone,
>>>>>>
>>>>>> There is an ancient version of Puppet in EPEL-7. Version 3.6 has
been
>>>>>> EOL for ages now.
https://binford2k.com/2016/11/22/puppet-3.x-eol/ has a
>>>>>> nice EOL overview:
>>>>>>
>>>>>> * Puppet 3 - 2016-12-31
>>>>>> * Puppet 4 - 2018-10-??
>>>>>> * Puppet 5 - 2021-02-??
>>>>>>
>>>>>> Puppet 6 requires a newer Ruby version than is available in EL7
so
>>>>>> rebasing the whole stack is not going to work. In theory you
could use
>>>>>> SCLs but I think it's unrealistic to expect that.
>>>>>>
>>>>>> However, all bugs open for Puppet relate to EPEL-7[1] so I'm
wondering
>>>>>> what to do.
>>>>>>
>>>>>> We can close all bugs as WONTFIX (including the security ones),
but
>>>>>> would it be better to also remove the package from EPEL-7?
>>>>>>
>>>>>> Regards,
>>>>>> Ewoud Kohl van Wijngaarden
>>>>>>
>>>>>> [1]:
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASS...
>>>>>
>>>>> Retiring epel7's puppet may be the preferred option. It is
allowed
>>>>> [0], but if you go this route please mention it on the epel-devel
list
>>>>> (and perhaps epel-announce) first.
>>>>
>>>> I should have realized this, will bring it up there.
>>>>
>>>>> Alternatively, have you considered doing an incompatible update [1]
to
>>>>> version 5? It may already be EOL, but surely that's a better
option
>>>>> than the current version 3 or removing it entirely.
>>>>
>>>> The Ruby version in EL7 is simply too old. In theory you could write a
>>>> ton of patches to make it compatible again, but the Puppet modules users
>>>> have may be assuming Ruby 2.4+ with Puppet 5. Also note that Puppet 5
>>>> itself is already EOL (for more than a year), but packaging Puppet 6 vs
>>>> Puppet 5 (or really, Puppet 7 as well) isn't a big difference: you
need
>>>> a newer Ruby. After that it's all minor differences.
>>>>
>>>>> [0]
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retireme...
>>>>> [1]
https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
>>>
>>> Bundle a newer Ruby?
>>
>> RHEL 7 has published "software collection library" versions of ruby,
>> titled "rh-ruby25".
>>
>> As somebody who's backported bulky software for RHEL based operating
>> systems, like Samba and current ansible and airflow and yes, years
>> ago, puppet, I don't recommend installing your own ruby. Resolving the
>> dependencies gets painful, fast.
>
> In that case, I would be fine with saying, “if you need to run Puppet
> on RHEL 7, do so in a container or VM based on a newer RHEL”.
>
Puppet is not very useful in a container. It's a systems management
tool, so it's designed to manage the computer itself.
Good catch, sorry. I had not thought of that.
If Puppet supports managing chroots, one could use a privileged
container that has the host’s root directory bind-mounted into it,
and uses host namespaces except for mount. Still, your point stands.
--
Sincerely,
Demi Marie Obenour (she/her/hers)