Bug 822014

Not immediately, no.  We only updated Fedora 17 because ruby was updated and the support in 2.6 for ruby-1.9 was non-existent.  Upstream doesn't even consider 2.7 to be supported with ruby-1.9 and recommends waiting for puppet-3.0.

I'm not jumping up and down at the prospect of pushing 2.7 to EPEL as there are issues of manifest compatibility and catalog compilation time.  Seeing that Fedora 17 isn't even released yet and all the other Fedora and EPEL branches are on 2.6, I'm not rushing to move them all just to keep up with the very bleeding edge.

I wish that compatibility was easier.  If we push 2.7 to EPEL, we make one group folks happy and another group rightfully upset that they have to do work to fix warnings and deal with new bugs in what was a working puppet installation.  Not really a happy prospect.

FWIW - I just ran across a bug with exec shell command quoting that is fixed in recent 2.7 versions, so getting 2.7 into EL6 and Fedora 16 would make me at least happier.

If you will be bumping version to 2.7, please make sure this backported issue is also included: https://bugzilla.redhat.com/show_bug.cgi?id=908655

+1 to this request generally. For Puppetlabs 2.6 development and bugfixes aren't being maintained so backporting fixes and bugs becomes a job for the package maintainer. Only security fixes really make it back to 2.6 these days - and even that may dry up eventually. As a PL developer I'm generally telling people to use our upstream yum.puppetlabs.com instead of EPEL as a consequence, as we ship 3.1.0 there, and we have backported Ruby 1.8.7 packages even for RHEL 5.

+1. The fact that the majority of people are having to go outside of EPEL to get the version that is relevant to them defeats the purpose of EPEL. EPEL must stay relevant to be beneficial to users.

That just means that at some point we'll be breaking our users configurations and causing them to do work after a yum update.  So it's not just an easy call.  We kept puppet update to date when it was pre-1.0 and that seemed acceptable to folks, but once it moved to 2.x to signify that it was more mature, telling users that each update requires manual intervention is not such an easy sell.

Clearly, we won't be shipping a ruby-1.8.7 for el5, for example.  That's something PL can do, but it's far from acceptable in EPEL. :)

There is Software Sollections effort (https://fedoraproject.org/wiki/SoftwareCollections) which could possibly help to solve this issue I mean.

Having a more recent version of Puppet in EPEL 6 becomes more important with every day. 2.6.x is generally not supported anymore.

Current example: puppetlabs-openstack (used e.g. by the Packstack tool) requires 2.7.12 or greater. 

The work of people having to get puppet from somewhere else is already far outweighing the workload for those who'd have to make changes. That's really a terrible reason to stick with such an old version anyway. It's not like people are forced to update to a new package version if they desperately want to stay with the old one.

(In reply to comment #9)
> Having a more recent version of Puppet in EPEL 6 becomes more important with
> every day. 2.6.x is generally not supported anymore.
> 
> Current example: puppetlabs-openstack (used e.g. by the Packstack tool)
> requires 2.7.12 or greater. 

The fact that many in the ruby community eschew backwards compatibility isn't a good reason to follow along, IMHO.

> The work of people having to get puppet from somewhere else is already far
> outweighing the workload for those who'd have to make changes. That's really
> a terrible reason to stick with such an old version anyway. It's not like
> people are forced to update to a new package version if they desperately
> want to stay with the old one.

I would strongly argue that's not true.  If folks did not want to update, they would be left with a package that was not updated for security vulnerabilities (see the recent 2.6.18 and the pile of important CVE's that it fixed).

We'll have to bite the bullet and update at some point, but pretending that it's as simple as just doing it and telling anyone that uses puppet for their core infrastructure to suck it up only makes people dislike EPEL and Puppet, neither of which is what I want to see.

Any movement on getting 2.7.x into EPEL?  2.6 is EOL.  Are all security bug fixes now in Fedora's responsibility to backport?  

I'm sure we've got a lot of customers who are scratching their heads (I am) about whether CVE-2013-3567 affects the EPEL 2.6 version; no mention of a 2.6 fix, but we do have an open bug at https://bugzilla.redhat.com/show_bug.cgi?id=974649 about it.

(In reply to Stephen Benjamin from comment #11)
> Any movement on getting 2.7.x into EPEL?  2.6 is EOL.  Are all security bug
> fixes now in Fedora's responsibility to backport?  
> 
> I'm sure we've got a lot of customers who are scratching their heads (I am)
> about whether CVE-2013-3567 affects the EPEL 2.6 version; no mention of a
> 2.6 fix, but we do have an open bug at
> https://bugzilla.redhat.com/show_bug.cgi?id=974649 about it.

Yes, 2.6 is affected.  That's why we have the epel-all tracking bug.

We'll have to backport the fix, which involves adding a vendored safe_yaml (which is amusing, as it imples that the stock yaml in ruby is unsafe -- go ruby!).

After that, we'll have to work on bumping to 2.7 or 3.x.  Either way, it's going to cause pain for users.

Thanks for dealing with this, Todd. 

Without expecting anyone to make any promises, do we have an approximate guess for how long it's likely to take until we have 2.7 or a back-ported 2.6 in EPEL? I've currently got my puppetmasterd stopped, and I'm wondering whether to uninstall the EPEL version and manually install 2.7 or to wait for EPEL.

I have a backported patch for 2.6 that I hope to get pushed to epel-testing in the next couple of days.  After that makes it to the stable repo, we'll have to work on pushin 2.7 to testing ASAP so that we don't get caught out like this again.

Thanks Todd, that's good to hear. Keep up the good work.

Any estimation of when this patch will be available?

CVE-2013-3567 has been patched by the vendor a month ago, I don't see moving to the puppetlabs repo a very easy transition for our environment.

I've built 2.7 into the updates-testing candidate target and I'm submitting an update in the next few minutes. Please note that I'm going to set the karma on this update to +5 because it's a high-risk change. Testing in an environment of a reasonable size would also be very much appreciated.

puppet-2.7.23-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/puppet-2.7.23-1.el6

Thanks for this work Sam.  May I suggest disabling karma entirely, so that the update does not get pushed out until you are comfortable with the testing?  All it takes is a few folks that do light testing to give it a thumbs up and the next thing you know a large update is pushed to everyone without much notice.  (Thankfully, not many people use epel-testing and give feedback :/).

Also, if you haven't already, a message to epel-announce and epel-devel would probably be good to give folks a heads up that this update is in the pipeline and what issues they might expect to see (deprecation notices, etc.).

Thanks!

Package puppet-2.7.23-1.el6:
* should fix your issue,
* was pushed to the Fedora EPEL 6 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing puppet-2.7.23-1.el6'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11765/puppet-2.7.23-1.el6
then log in and leave karma (feedback).

+1 for getting 2.7.x into epel6 ASAP and many thanks to Sam for pushing this along. Many forge modules have dropped puppet 2.6.x support, including all of the offical PL modules.  This afternoon I received a PR asking to add 2.6.x support to one my modules on the basis that 2.6 is what's suplied with epel6, which was the first I've heard in a long time of anyone actually still using puppet from epel.

Continuing to provide 2.6.x is a pain for packagers as upstream has moved on, it's a pain for users which can't use wide a number of popular modules, and it's a pain for module authors having to deal with compatability issues for a dead release series.

puppet-2.7.23-1.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.

There was no announcment to any epel-* list or fedora-* list of this change which broke EL5 puppetmasters.  It would have been nice to give a months notice or so as per comment #19.

Will there be an EL5 update to 2.7?  What are EL5 users supposed to do at this point?

Thanks.

I would appreciate some clarification as to whether EL5 will also be updated to puppet-2.7.  Thanks you.

I was planning on upgrading EL 6 first since I assumed people run their masters on more recent versions of EL than their agents. Using that assumption EL 6 got updates first, but yes, I'm planning on upgrading EL 5 very soon.

Will there be an announcement ahead of Puppet 2.7 dropping for EL5, or will it be like the Magic Monday yesterday when 2.7 dropped for EL6?

Also, is there a separate bug tracking the EL5/2.7 request we can monitor for status?

Thankfully we didn't have *much* break - just our test-before-commit script, but this bug https://projects.puppetlabs.com/issues/11317 is biting us, but we had to script our monitoring to ignore exactly 6 'skipped' resources to bypass it.  (Since its only fixed in Puppet 3.3.0)