Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 2069797

Summary: foreman throws hundreds of puppetrun errors per host if puppet_proxy yml files exist
Product: Red Hat Satellite Reporter: Jessica Richards <jrichards2>
Component: PuppetAssignee: satellite6-bugs <satellite6-bugs>
Status: CLOSED WORKSFORME QA Contact: Satellite QE Team <sat-qe-bz-list>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.10.2CC: casl, jcrumple, myoder, nalfassi, vsedmik, wpinheir
Target Milestone: UnspecifiedKeywords: 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: 2023-05-30 12:43:21 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:
Embargoed:

Description Jessica Richards 2022-03-29 17:44:50 UTC
Description of problem:

When these two files exist:

/etc/foreman-proxy/settings.d/puppet_proxy_customrun.yml.rpmsave
/etc/foreman-proxy/settings.d/puppet_proxy_puppetrun.yml.rpmsave

Or when these two files exist:

/etc/foreman-proxy/settings.d/puppet_proxy_customrun.yml
/etc/foreman-proxy/settings.d/puppet_proxy_puppetrun.yml

Satellite accumulates hundreds of errors like this each day, for each registered host:

[W|app|39519d2e] Setting puppetrun has no definition, please define it before using

Under these conditions, those errors can also be provoked by running this command on a host:

# subscription-manager facts --update


Note:  The customer I worked with had a few hundred registered hosts, and over time more than one million such errors had accumulated on their system.


Version-Release number of selected component (if applicable):

customer server:
satellite-6.10.2-1.el7sat.noarch
foreman-2.5.2.18-3.el7sat.noarch
puppetserver-6.15.3-1.el7sat.noarch
puppet-agent-6.22.1-1.el7sat.x86_64

my reproducer:
satellite-6.10.3-1.el7sat.noarch
foreman-2.5.2.19-1.el7sat.noarch
puppetserver-6.15.3-1.el7sat.noarch
puppet-agent-6.22.1-1.el7sat.x86_64


How reproducible:

100%


Steps to Reproduce:
1.  install the puppet_proxy files in /etc/foreman-proxy/
2.  run "satellite-installer"
3.  reboot
4.  run "subscription-manager facts --update" on a host

Actual results:

I see this in /var/log/foreman/production.log:

[W|app|39519d2e] Setting puppetrun has no definition, please define it before using


Expected results:

No error message.

Additional info:

I was able to reverse this issue on my reproducer by following these steps:

1.  move the puppet_proxy files in /etc/foreman-proxy/ to another location
2.  run "satellite-installer"
3.  reboot

Comment 4 Jessica Richards 2022-04-27 00:24:13 UTC
Follow-up:  After further testing, I've found that my workaround (mentioned in the problem description, and also below) is not, in fact, a reliable fix:

1.  move the puppet_proxy files in /etc/foreman-proxy/ to another location
2.  run "satellite-installer"
3.  reboot

Comment 5 myoder 2022-05-16 14:00:54 UTC
I have been able to reproduce this issue easily just by registering my content host to a Satellite 6.10 server.

I've done a little investigating, and I see the error is thrown from this file, from the SettingRegistry class:

~~~
  /usr/share/foreman/app/services/setting_registry.rb
~~~

We see the definition is getting assigned here, by seeing if the name "puppetrun" exists in the settings table from the foreman db:

~~~
 16   def find(name)
 17     logger.warn("Setting is not initialized yet, requested value     for #{name} will be always nil") unless ready?
 18     @settings[name.to_s]
 19   end
~~~


I can see that Satellite 6.8 does have the puppetrun entry in the foreman settings table, but 6.9 and 6.10 do not.  Only Satellite 6.10 throws this error, while Satellite 6.9 does not.

Further, I think this wasn't caught until the SettingRegistry class was introduced, which appears to have been added in Satellite 6.10.  Since seeing this bug, I have seen this issue appear in multiple customer environments (usually heavily logged since each host is triggering this).

I'm not exactly sure where the value of puppetrun is getting introduced (i.e. the rhsm libraries from the content host, or somewhere still from the Satellite server).  Is there any way we can disable this feature, to prevent all of these WARN logging messages?

Kind regards,

Comment 6 Vladimír Sedmík 2022-05-18 14:35:00 UTC
Puppetrun was removed from 6.9 and later versions (see https://bugzilla.redhat.com/show_bug.cgi?id=1905096), so there shouldn't be any way how to disable something what should be missing. Strange that this bug manifests in 6.10 and not in 6.9.

Comment 7 Charles Slivkoff 2022-12-20 16:10:12 UTC
This seems to no longer be occurring with 6.10.

Comment 8 nalfassi 2023-05-30 12:43:21 UTC
After thorough testing and analysis on Satellite 6.13, I regret to inform you that I was unable to reproduce the issue as described in the ticket. Despite following the provided steps, the issue could not be replicated.
As a result, I am closing the BZ ticket. However, please note that if the issue reoccurs or if additional information becomes available, we can reopen the ticket for further investigation.