Bug 2228107

Summary:	Wrong puppet service in NetworkManager dispatcher
Product:	[Fedora] Fedora EPEL	Reporter:	brgerig
Component:	puppet	Assignee:	Orphan Owner <extras-orphan>
Status:	NEW ---	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	epel9	CC:	brandfbb, ekohlvan, extras-orphan, igor.raits, terje.rosten
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		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 brgerig 2023-08-01 12:20:55 UTC

Description of problem:
The puppet package creates a systemd service called puppet.service. It also sets up a NetworkManager dispatcher at /usr/lib/NetworkManager/dispatcher.d/98-puppet in order to restart puppet on network changes. However, the dispatcher runs the command /bin/systemctl condrestart puppetagent.service instead of puppet.service, resulting in errors in /var/log/messages like nm-dispatcher[1321]: Failed to try-restart puppetagent.service: Unit puppetagent.service not found.

Version-Release number of selected component (if applicable):
7.20.0-1.el9

How reproducible:
Always

Steps to Reproduce:
1. Install puppet package

Actual results:
/usr/lib/NetworkManager/dispatcher.d/98-puppet contains puppetagent.service

Expected results:
/usr/lib/NetworkManager/dispatcher.d/98-puppet contains puppet.service

Additional info:
Puppet Systems Engineer says that their source tree is correct and uses puppet.service in the dispatcher.

Comment 1 Ewoud Kohl van Wijngaarden 2023-08-01 15:45:40 UTC

This is contained here:

https://src.fedoraproject.org/rpms/puppet/blob/rawhide/f/puppet-nm-dispatcher.systemd

And that link is for rawhide, but the same thing is present everywhere.

I do wonder if it's still needed. It was originally introduced for https://bugzilla.redhat.com/show_bug.cgi?id=532085 but since puppet 7.7.0-2 (https://src.fedoraproject.org/rpms/puppet/c/2ab5939cfe8126773d6cd6159e0de1e3625ac4e4?branch=rawhide) we no longer ship puppetagent.service (as an alias) and haven't heard bug reports I question if the bug is still present.

I'm now leaning to removing the whole NetworkManager dispatcher hook.

Comment 2 brgerig 2023-08-01 15:59:23 UTC

I am running into something similar, and I wonder if it's tangentially related. I'm deploying VMs on VMware ESXi, cloning from a template with a customization script, and using cloud-init to take care of the initial puppet connection. However, puppet seems to be getting stuck running under the hostname of the template, even after customization/cloud-init change the hostname. It very well could be a problem with my scripts and/or configs (I'm still somewhat new to this), but I wonder if a NetworkManager dispatcher hook on hostname change to restart puppet would take care of that. Thoughts?

Comment 3 Ewoud Kohl van Wijngaarden 2023-08-01 16:04:50 UTC

I suspect that's different. Puppet has a certname setting and if you have generated certificates in the template then it very well may end up using those in every instance. So that highly depends on how you created the template.

Comment 4 Breno 2023-08-08 21:20:13 UTC

(In reply to Ewoud Kohl van Wijngaarden from comment #1)
> This is contained here:
> 
> https://src.fedoraproject.org/rpms/puppet/blob/rawhide/f/puppet-nm-
> dispatcher.systemd
> 
> And that link is for rawhide, but the same thing is present everywhere.
> 
> I do wonder if it's still needed. It was originally introduced for
> https://bugzilla.redhat.com/show_bug.cgi?id=532085 but since puppet 7.7.0-2
> (https://src.fedoraproject.org/rpms/puppet/c/
> 2ab5939cfe8126773d6cd6159e0de1e3625ac4e4?branch=rawhide) we no longer ship
> puppetagent.service (as an alias) and haven't heard bug reports I question
> if the bug is still present.
> 
> I'm now leaning to removing the whole NetworkManager dispatcher hook.

I agree with you, I think we could just remove it.