Bug 1379877

Summary:	puppet-stdlib included with satellite packages should be updated
Product:	Red Hat Satellite	Reporter:	Craig Donnelly <cdonnell>
Component:	Puppet	Assignee:	satellite6-bugs <satellite6-bugs>
Status:	CLOSED NOTABUG	QA Contact:	Katello QA List <katello-qa-list>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.2.2	CC:	bbuckingham, jcallaha, rballang, rjerrido
Target Milestone:	Unspecified	Keywords:	Triaged
Target Release:	Unused
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-05-31 20:28:37 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Craig Donnelly 2016-09-28 00:58:16 UTC

Description of problem:
Currently with Satellite 6.1 + 6.2 we are shipping a 2014 version of puppet-stdlib, and while installing foreman plugins we ship, such as the plugin for OpenSCAP - we will attempt to pull in the puppet-stdlib via RPM from Red Hat and we receive the old version.

If customers are writing modules based on newer versions of puppet-stdlib, this can cause issues and causes customer to have to perform manual steps to get things working properly. (Either extracting the openscap module from the RPM, or using it from upstream)

Version-Release number of selected component (if applicable):
puppetlabs-stdlib-4.2.1-1.20140510git08b00d9.el7sat.noarch
(This seems mostly similar between Sat 6.1/6.2. - This one came from rhel-7-server-satellite-6.2-rpms)

How reproducible:
100%

Steps to Reproduce:
1. On Satellite: `yum install puppet-foreman_scap_client`
2. 
3.

Actual results:
Dependencies required bring puppetlabs-stdlib of old version.

Expected results:
Provide ability to (easily) update puppetlabs-stdlib without issue, or ship newer version so customers are not limited by old versions.

Additional info:

Comment 2 Rich Jerrido 2017-05-31 20:28:37 UTC

A user can provide their own puppet modules, either by syncing from Puppet Forge, OR by uploading them to a Puppet Repo. Modules included in a content view (and that content view's associatedsupercede those included in Puppet's 'BaseModulePath' (/usr/share/puppet/modules). 


By leveraging this, the customer can use whichever version they'd like independent of the version we ship.

Comment 3 Ryan 2017-06-14 20:16:06 UTC

Rich,

Thank you for giving attention to this bugzilla.  In evaluating this, we found that the version of puppetlabs-stdlib in the content view puppet environment was not used, but the version in /usr/share/puppet/modules was used. There is a bug in the version installed in /usr/share/puppet/modules (4.2.1) which produces error messages from classes using the file_line module:

Error: Failed to apply catalog: Validation of File_line[Restrict Access to su command] failed: When providing a 'match' parameter, the value must be a regex that matches against the value of your 'line' parameter at /etc/puppet/environments/KT_Fastenal_Production_Puppet_48/modules/pam/manifests/init.pp:144

After uninstalling the version locally installed by running yum -y erase puppetlabs-stdlib, the puppet modules operates as expected as puppetlabs-stdlib (4.17.0) was used from the puppet environment.

For whatever reason, puppet agent is preferring the copy in /usr/share/puppet/modules over the version in the puppet environment when the agent runs.

If you have any questions, please do not hesitate to get in touch with us, or review the associated RH support case 01708730.

Thanks,
Ryan

Comment 5 Ryan 2017-07-11 18:58:15 UTC

As a workaround, we wrote a puppet module which takes the contents of the stdlib package from puppetlabs and copies it into /usr/share/puppet/modules/stdlib. This way the latest version is "installed", both openscap and our existing puppet modules function.  Hopefully this can be fixed in a more permanent way than the hack we put together in the near future.