Summary: | sysutils/puppet -- the 'Service' provider will get service names wrong when rc scripts contain a 'desc' parameter | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Ports & Packages | Reporter: | Matthew Seaman <matthew> | ||||||
Component: | Individual Port(s) | Assignee: | Steve Wills <swills> | ||||||
Status: | Closed FIXED | ||||||||
Severity: | Affects Some People | CC: | mmoll | ||||||
Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(swills) |
||||||
Version: | Latest | ||||||||
Hardware: | Any | ||||||||
OS: | Any | ||||||||
Attachments: |
|
Created attachment 156428 [details]
Poudriere build log after patching
A commit references this bug: Author: mmoll Date: Sun May 31 20:03:21 UTC 2015 New revision: 388162 URL: https://svnweb.freebsd.org/changeset/ports/388162 Log: sysutils/puppet: update to 3.8.1 add a patch to parse service names correctly [1] PR: 199995 [1] Differential Revision: https://reviews.freebsd.org/D2676 Submitted by: matthew [1] Approved by: swills (mentor, maintainer) Changes: head/sysutils/puppet/Makefile head/sysutils/puppet/distinfo head/sysutils/puppet/files/patch-lib_puppet_provider_service_freebsd.rb Committed together with the update to 3.8.1, thanks! |
Created attachment 156427 [details] Update to sysutils/puppet puppet groks the 'service_name' parameter by parsing the output of 'service foo rcvar'. Normall this works well, but in the case of eg. local_unbound, it goes comically wrong: {{{ :% service local_unbound rcvar # local_unbound : local caching forwarding resolver ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ # local_unbound_enable="NO" # (default: "") }}} The indicated text comes from the 'desc' variable in /etc/rc.d/local_unbound, and leads to puppet creating a file '/etc/rc.conf.d/local_unbound : local caching forwarding resolver' (embedded spaces and colons and all). Needless to say, this doesn't get read-in by the rc-system. Admittedly, local_unbound is one of only two rc-scripts in the base system that contain a desc fiels (at least, in 10.1-RELEASE) I've submitted a bug upstream, but in the mean time, the attached patch fixes the problem for me.