Jira (FACT-3201) Facter should report macOS "extra" version from Rapid Security Response updates
Title: Message Title Clay Caviness commented on FACT-3201 Re: Facter should report macOS "extra" version from Rapid Security Response updates For what it's worth, we have a fleet of 180k+ machines running macOS 13, all using Puppet 7.20.0 and Facter 4.2.13 with no major compatibility issues. Also, macOS 14 will be announced in a few weeks, as well, likely released this fall. Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.485206.1683227494000.13308.1684163400040%40Atlassian.JIRA.
Jira (FACT-3201) Facter should report macOS "extra" version from Rapid Security Response updates
Title: Message Title Clay Caviness commented on FACT-3201 Re: Facter should report macOS "extra" version from Rapid Security Response updates Opened https://github.com/puppetlabs/facter/pull/2568 Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.485206.1683227494000.11068.1683227940026%40Atlassian.JIRA.
Jira (FACT-3201) Facter should report macOS "extra" version from Rapid Security Response updates
Title: Message Title Clay Caviness commented on FACT-3201 Re: Facter should report macOS "extra" version from Rapid Security Response updates I'm working on a pull request to fix this. Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.485206.1683227494000.11067.1683227520113%40Atlassian.JIRA.
Jira (FACT-3201) Facter should report macOS "extra" version from Rapid Security Response updates
Title: Message Title Clay Caviness created an issue Facter / FACT-3201 Facter should report macOS "extra" version from Rapid Security Response updates Issue Type: Improvement Assignee: Unassigned Components: Facter 4 Created: 2023/05/04 12:11 PM Priority: Normal Reporter: Clay Caviness Starting with macOS 13, Apple can use a "Rapid Security Response" process to push small system updates out. When one of these is applied, a new ProductVersionExtra field is output from the sw_vers command: $ sw_vers ProductName: macOS ProductVersion: 13.3.1 ProductVersionExtra: (a) BuildVersion: 22E772610a
Jira (PUP-11594) Puppet::Util.safe_posix_fork fails if /proc/self is not a directory
Title: Message Title Clay Caviness commented on PUP-11594 Re: Puppet::Util.safe_posix_fork fails if /proc/self is not a directory https://github.com/puppetlabs/puppet/pull/8927 should fix this issue. Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.456396.1658334423000.1081.1658337240162%40Atlassian.JIRA.
Jira (PUP-11594) Puppet::Util.safe_posix_fork fails if /proc/self is not a directory
Title: Message Title Clay Caviness created an issue Puppet / PUP-11594 Puppet::Util.safe_posix_fork fails if /proc/self is not a directory Issue Type: Bug Assignee: Unassigned Created: 2022/07/20 9:27 AM Priority: Normal Reporter: Clay Caviness Puppet Version: 7.12.0 Puppet Server Version: N/A OS Name/Version: macOS 12.5 If a host has /proc/self but as a file, safe_posix_fork will throw an unhandled Errno::ENOTDIR, leading to a failed puppet run. This is not typical, but we had a user on a macOS 12 machine set up /proc/self in this way: Append proc Volumes/proc to /etc/synthentic.conf sudo mkdir /Volumes/proc Reboot sudo touch /proc/self Subsequent puppet executions will fail: Error: Could not create resources for managing Puppet's files and directories in sections [:main, :agent, :ssl]: Could not get group list from DirectoryService Error: Could not prepare for execution: Could not create resources for managing Puppet's files and directories in sections [:main, :agent, :ssl]: Could not get group list from DirectoryService Adding
Jira (PUP-11164) launchd service provider fails if a parsable but invalid LaunchAgent or LaunchDaemon plist file exists
Title: Message Title Clay Caviness commented on PUP-11164 Re: launchd service provider fails if a parsable but invalid LaunchAgent or LaunchDaemon plist file exists I think https://github.com/puppetlabs/puppet/pull/8683 fixes this. Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.406437.1625784567000.77561.1625784780075%40Atlassian.JIRA.
Jira (PUP-11164) launchd service provider fails if a parsable but invalid LaunchAgent or LaunchDaemon plist file exists
Title: Message Title Clay Caviness created an issue Puppet / PUP-11164 launchd service provider fails if a parsable but invalid LaunchAgent or LaunchDaemon plist file exists Issue Type: Bug Affects Versions: PUP 7.8.0 Assignee: Unassigned Components: Types and Providers Created: 2021/07/08 3:49 PM Priority: Normal Reporter: Clay Caviness If a file in the LaunchAgents or LaunchDaemons paths is encountered that's parseable by Puppet::Util::Plist.read_plist_from_file but not a valid launchd plist file, then Puppet will crash with an error. To reproduce: # echo "aaa" >/Library/LaunchDaemons/invalid.txt # puppet resource service Error: Could not run: undefined method `has_key?' for "aaa":String In launchd.rb line 141, the parsed plist (job) is checked with .has_key? to
Jira (FACT-3053) Incorrect license for lib/facter/custom_facts/core/legacy_facter.rb?
Title: Message Title Clay Caviness created an issue Facter / FACT-3053 Incorrect license for lib/facter/custom_facts/core/legacy_facter.rb? Issue Type: Bug Assignee: Unassigned Created: 2021/06/30 8:45 AM Priority: Normal Reporter: Clay Caviness The top-level LICENSE file for Facter is MIT. However lib/facter/custom_facts/core/legacy_facter.rb has an Apache 2.0 license notice at the top of the file. Is this correct, or just a remnant of the old Facter license that was copied over? Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97)
Jira (FACT-2914) macOS 11 reports incorrect os.macosx.version.major
Title: Message Title Clay Caviness commented on FACT-2914 Re: macOS 11 reports incorrect os.macosx.version.major ... See https://tickets.puppetlabs.com/browse/FACT-3031 Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.383030.1610488621000.16494.1619107140094%40Atlassian.JIRA.
Jira (FACT-3031) Add os.macosx.version.patch fact
Title: Message Title
Clay Caviness created an issue
Facter / FACT-3031
Add os.macosx.version.patch fact
Issue Type:
New Feature
Assignee:
Unassigned
Components:
Facter 4
Created:
2021/04/22 8:46 AM
Priority:
Normal
Reporter:
Clay Caviness
Starting with macOS 11, Apple has more clearly started using major.minor.patch for OS versions. FACT-2914 changes how os.macosx.version.major is reported, but instead essentially splitting on the first . and concatenating the second set, it would be more correct to split into 3 and report major/minor/patch. Current:
❯ facter os.macosx.version
{
full => "11.2.2",
major => "11",
minor => "2.2",
Jira (FACT-2914) macOS 11 reports incorrect os.macosx.version.major
Title: Message Title Clay Caviness commented on FACT-2914 Re: macOS 11 reports incorrect os.macosx.version.major i've made https://github.com/puppetlabs/facter/pull/2365 to break things out into major/minor/patch. Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.383030.1610488621000.15642.1619034300055%40Atlassian.JIRA.
Jira (FACT-2914) macOS 11 reports incorrect os.macosx.version.major
Title: Message Title Clay Caviness commented on FACT-2914 Re: macOS 11 reports incorrect os.macosx.version.major Facter 3 determines it by splitting on the last '.', it seems: https://github.com/puppetlabs/facter/blob/4339472f441868ecdae694ffc71e7c8ed0fc24e3/lib/src/facts/resolvers/operating_system_resolver.cc#L168 Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.383030.1610488621000.113615.1610489940080%40Atlassian.JIRA.
Jira (FACT-2914) macOS 11 reports incorrect os.macosx.version.major
Title: Message Title
Clay Caviness updated an issue
Facter / FACT-2914
macOS 11 reports incorrect os.macosx.version.major
Change By:
Clay Caviness
The current macOS major version is {{11} } , but facter reports it as {{11.2}}.Starting with macOS 11, Apple is incrementing the second component of the release number for point releases (e.g., {{11.0}}, {{11.1}}, {{11.2}}). It's assumed that going forward a new major version would be {{12}}, {{13}}, etc.This is a change from previous releases, where Apple would increment the third digit (e.g., {{10.15.1}}, {{10.15.2}}), and a new major version would be {{10.x}}.This seems to be occurring [here|https://github.com/puppetlabs/facter/blob/bc5ccd4f3ef5b38dc72b7a6079a84fab6288ec77/lib/facter/facts/macosx/os/macosx/version.rb#L14]. I expect there will need to be logic to use the first component going forward, and the first two for versions starting with {{10}}.
Add Comment
This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
--
You received this message
Jira (FACT-2914) macOS 11 reports incorrect os.macosx.version.major
Title: Message Title
Clay Caviness created an issue
Facter / FACT-2914
macOS 11 reports incorrect os.macosx.version.major
Issue Type:
Bug
Assignee:
Unassigned
Created:
2021/01/12 1:57 PM
Environment:
macOS 11.2
Priority:
Normal
Reporter:
Clay Caviness
The current macOS major version is 11}, but facter reports it as {{11.2. Starting with macOS 11, Apple is incrementing the second component of the release number for point releases (e.g., 11.0, 11.1, 11.2). It's assumed that going forward a new major version would be 12, 13, etc. This is a change from previous releases, where Apple would increment the third digit (e.g., 10.15.1, 10.15.2), and a new major version would be 10.x. This seems to be occurring here. I expect there will need to be logic to use the first component going forward, and the first two for versions starting with 10.
Add Comment
Jira (PUP-10847) "puppet facts show fact" output differs from "facter fact"
Title: Message Title
Clay Caviness commented on PUP-10847
Re: "puppet facts show fact" output differs from "facter fact"
Tangential to this, the timing of these changes is going to complicate and slow migration to Puppet 7/Facter 4. Many folks use {facter -p fact} in various scripts and other tools. With puppet 6/facter 3, {puppet facts show fact} isn't workable, only {facter -p fact} . Puppet 7 adds a (mostly; this bug aside) working {puppet facts show fact}. However, Puppet 7 requires Facter 4, which fully deprecates {facter -p fact}. In order to effect the upgrade from Puppet 6 to Puppet 7 (and Facter 4), all places where {facter -p fact} is used will need to first check what version of Puppet is installed, and then call {facter -p fact} or {puppet facts show fact} as appropriate. And if the output of {puppet facts show} isn't changed to match {facter -p}, additional logic will be needed to handle the extra parsing required. I expect it's too late for this, but it would have eased things considerably if there was an overlap during which both {facter -p} and {puppet facts show} worked (with the same output, of course), say by having Puppet 7 support Facter 3 and 4. Then the process would be simpler, as we could update to Puppet 7, roll that out, then update tooling to use {puppet facts show} everywhere, roll those out, then update to Facter 4 (by which time all uses of {facter -p} have been fixed).
Add Comment
This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails
Jira (PUP-10847) "puppet facts show fact" output differs from "facter fact"
Title: Message Title
Clay Caviness updated an issue
Puppet / PUP-10847
"puppet facts show fact" output differs from "facter fact"
Change By:
Clay Caviness
*Puppet Version:* {{7.1}}*OS Name/Version:* macOS 11.1The output of "{{puppet facts show _somefact_}}" is not the same as "{{facter _somefact_}}", as it returns JSON, which requires subsequent parsing to get the the fact value.We use "{{facter --puppet _somefact_}}" quite a bit in non-puppet code, such as shell and python scripts and other internal management utilities. This is a strongly complicating issue in a migration from facter 3/puppet 6 to facter 4/puppet 7: "{{facter --puppet}}" no longer works in Facter 4, and I believe "{{puppet facts show _somefact_}}" only works in Puppet 7.This will mean all the various places we use "{{facter --puppet _somefact_}}" will have to have a case on the puppet version and then call "{{facter --puppet _somefact_}}" or "{{puppet facts show _somefact_}}" as appropriate. And we'll have to do extra processing on the output of "{{puppet facts show}}", as it sends JSON.*Desired Behavior:*{quote}$ puppet facts show facterversion4.0.47$ facter facterversion4.0.47{quote}*Actual Behavior:*{quote}$ puppet facts show facterversion\{ "facterversion": "4.0.47"} \ $ facter facterversion4.0.47{quote}
Add Comment
This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Jira (PUP-10847) "puppet facts show fact" output differs from "facter fact"
Title: Message Title
Clay Caviness updated an issue
Puppet / PUP-10847
"puppet facts show fact" output differs from "facter fact"
Change By:
Clay Caviness
*Puppet Version:* {{7.1}}*OS Name/Version:* macOS 11.1The output of "{{puppet facts show _somefact_}}" is not the same as "{{facter _somefact_}}", as it returns JSON, which requires subsequent parsing to get the the fact value.We use "{{facter --puppet _somefact_}}" quite a bit in non-puppet code, such as shell and python scripts and other internal management utilities. This is a strongly complicating issue in a migration from facter 3/puppet 6 to facter 4/puppet 7: "{{facter --puppet}}" no longer works in Facter 4, and I believe "{{puppet facts show _somefact_}}" only works in Puppet 7.This will mean all the various places we use "{{facter --puppet _somefact_}}" will have to have a case on the puppet version and then call "{{facter --puppet _somefact_}}" or "{{puppet facts show _somefact_}}" as appropriate. And we'll have to do extra processing on the output of "{{puppet facts show}}", as it sends JSON.*Desired Behavior:*{quote}$ puppet facts show facterversion4.0.47$ facter facterversion4.0.47{quote}*Actual Behavior:*{quote}$ puppet facts show facterversion \ { "facterversion": "4.0.47"} \ $ facter facterversion4.0.47{quote}
Add Comment
This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Jira (PUP-10847) "puppet facts show fact" output differs from "facter fact"
Title: Message Title
Clay Caviness created an issue
Puppet / PUP-10847
"puppet facts show fact" output differs from "facter fact"
Issue Type:
Bug
Affects Versions:
PUP 7.1.0
Assignee:
Unassigned
Components:
UX
Created:
2021/01/05 1:07 PM
Priority:
Normal
Reporter:
Clay Caviness
Puppet Version: 7.1 OS Name/Version: macOS 11.1 The output of "puppet facts show somefact" is not the same as "facter somefact", as it returns JSON, which requires subsequent parsing to get the the fact value. We use "facter --puppet somefact" quite a bit in non-puppet code, such as shell and python scripts and other internal management utilities. This is a strongly complicating issue in a migration from facter 3/puppet 6 to facter 4/puppet 7: "facter --puppet" no longer works in Facter 4, and I believe "puppet facts show somefact" only works in Puppet 7. This will mean all the various places we use "facter --puppet somefact" will have to have a case on the puppet version and then call "facter --puppet somefact" or "puppet facts show somefact" as appropriate. And we'll have to do extra processing on the output of "puppet facts show", as it sends JSON. Desired Behavior:
$ puppet facts show facterversion 4.0.47 $ facter facterversion 4.0.47
Actual Behavior:
$ puppet facts show facterversion
Unknown macro: { "facterversion"}
Jira (PUP-9148) apple.rake references incorrect location after Rakefile changed to use packaging as a gem
Title: Message Title Clay Caviness commented on PUP-9148 Re: apple.rake references incorrect location after Rakefile changed to use packaging as a gem Pull request here Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9148) apple.rake references incorrect location after Rakefile changed to use packaging as a gem
Title: Message Title Clay Caviness created an issue Puppet / PUP-9148 apple.rake references incorrect location after Rakefile changed to use packaging as a gem Issue Type: Bug Assignee: Unassigned Created: 2018/09/17 12:14 PM Priority: Normal Reporter: Clay Caviness Puppet Version: 5.5.6 OS Name/Version: 10.13.6 We are building puppet from source based of the method described in this post to the puppet-users list. A recent change to the puppet Rakefile started using packaging as a gem instead of expanding/vendoring/whatever the term is inside of ext/. However, the apple.rake task still references ext/packaging on line 73. This means that the PackageInfo.plist is not found, and the pkgbuild fails. I'm not sure what is expected here, or how your build systems works around this. Perhaps it is both using packaging as a gem and expanding into ext/? I have a small patch for this that works locally which I will send as a pull request shortly. Add Comment
Jira (PUP-9111) Restarting services using launchd service provider is flaky
Title: Message Title Clay Caviness commented on PUP-9111 Re: Restarting services using launchd service provider is flaky https://github.com/puppetlabs/puppet/pull/7053 Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9111) Restarting services using launchd service provider is flaky
Title: Message Title Clay Caviness created an issue Puppet / PUP-9111 Restarting services using launchd service provider is flaky Issue Type: Bug Affects Versions: PUP 5.4.0 Assignee: Unassigned Attachments: keepalive.plist, keepalive.pp, keepalive.sh Created: 2018/09/06 2:44 PM Priority: Normal Reporter: Clay Caviness Puppet Version: 5.4.0 OS Name/Version: macOS 10.13.6 Restarting jobs will frequently fail. When restarting a service, the launchd provider calls stop and then start. The stop method executes launchctl unload -w , and then calls enable The enable method reads the disable overrides pilst (/var/db/com.apple.xpc.launchd/disabled.plist) and modifies it. However, there is a race. While the launchd process is changing states, the disables plist is sometimes zero-length. When this occurs, read_plist (which is just Puppet::Util::(Plist.read_plist_file fails: Info: /Stage[main]/Main/File[/tmp/foo]: Scheduling refresh of Service[keepalive] Warning: Cannot read file /var/db/com.apple.xpc.launchd/disabled.plist; Puppet is skipping it.\nDetails: Execution of '/usr/bin/plutil -convert xml1 -o - /var/db/com.apple.xpc.launchd/disabled.plist' returned 1: /var/db/com.apple.xpc.launchd/disabled.plist: Property List error: Cannot parse
Jira (PUP-8545) puppet 5/ruby 2.4 can't handle invalid plists
Title: Message Title Clay Caviness commented on PUP-8545 Re: puppet 5/ruby 2.4 can't handle invalid plists I fail at formatting here. You get the idea. It seems to be a pretty simple fix: https://github.com/puppetlabs/puppet/pull/6733 Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8545) puppet 5/ruby 2.4 can't handle invalid plists
Title: Message Title
Clay Caviness commented on PUP-8545
Re: puppet 5/ruby 2.4 can't handle invalid plists
This happens because puppet prefetches resources for the launchd service provider. The code is triggered if there's any malformed plists it the /Library/LaunchDaemons directory, whether they're managed my puppet or not. This only triggers a warning; puppet continues processing. Trimmed debug output: {{Debug: Prefetching launchd resources for service [...] Debug: Reading launchd plist /Library/LaunchDaemons/good.plist Debug: Reading launchd plist /Library/LaunchDaemons/badcomment.plist }}Debug: Failed with CFFormatError on /Library/LaunchDaemons/badcomment.plist: # Line: 10 Position: 383 Last 80 unconsumed characters: > Debug: Plist /Library/LaunchDaemons/badcomment.plist ill-formatted, converting with plutil Debug: Executing: '/usr/bin/plutil -convert xml1 -o /dev/stdout /Library/LaunchDaemons/badcomment.plist' Warning: Cannot read file /Library/LaunchDaemons/badcomment.plist; Puppet is skipping it.\nDetails: Execution of '/usr/bin/plutil -convert xml1 -o /dev/stdout /Library/LaunchDaemons/badcomment.plist' returned 1: {{ KeepAlive}} {{ }} {{ Label}} {{ badcomment}} {{ ProcessType}} {{ Background}} {{ ProgramArguments}} {{ }} {{ /bin/true}} {{ }} {{ RunAtLoad}} {{ }} /dev/stdout: Operation not supported
Add Comment
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send
Jira (PUP-8545) puppet 5/ruby 2.4 can't handle invalid plists
Title: Message Title Clay Caviness created an issue Puppet / PUP-8545 puppet 5/ruby 2.4 can't handle invalid plists Issue Type: Bug Assignee: Unassigned Created: 2018/03/13 11:57 AM Priority: Normal Reporter: Clay Caviness Puppet Version: 5.4.0 Puppet Server Version: n/a OS Name/Version: macOS 10.13.3 Puppet 5.4.0 using ruby 2.4.3 can't handle invalid plists. If a plist contains and invalid comment (e.g., a comment with '–' in the text), CFPropertyList will fail to parse it, passing it on to a shell out to `plutil -convert xml1 -o /dev/stdout`. However, it seems some subsystem (I believe it may be ruby 2.4) doesn't allow operations on `/dev/stdout` Warning: Cannot read file /Library/LaunchDaemons/badcomment.plist; Puppet is skipping it.\nDetails: Execution of '/usr/bin/plutil -convert xml1 -o /dev/stdout /Library/LaunchDaemons/badcomment.plist' returned 1: Warning: Cannot read file /Library/LaunchDaemons/badcomment.plist; Puppet is skipping it.\n [...] /dev/stdout: Operation not supported To reproduce, add a comment containing '–' to any plist in /Library/LaunchDaemons, then run puppet. Desired Behavior: Puppet should handle the malformed plist and successfully call plutil. Actual Behavior: After CFPropertyList fails, the plutil call also fails. Add Comment
Jira (FACT-1452) facter 3.1.7/3.1.8 releases on github are versioned as 3.2.0
Title: Message Title Clay Caviness commented on FACT-1452 Re: facter 3.1.7/3.1.8 releases on github are versioned as 3.2.0 Ah, this is https://tickets.puppetlabs.com/browse/FACT-1425 Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6568) launchd service provider crashes if a non-text or binary plist file in {System,}/Library/Launch{Daemons,Agents} directory exists
Title: Message Title
Clay Caviness commented on PUP-6568
Re: launchd service provider crashes if a non-text or binary plist file in {System,}/Library/Launch{Daemons,Agents} directory exists
I think this PR fixes it
Add Comment
This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6568) launchd service provider crashes if a non-text or binary plist file in {System,}/Library/Launch{Daemons,Agents} directory exists
Title: Message Title
Clay Caviness updated an issue
Puppet / PUP-6568
launchd service provider crashes if a non-text or binary plist file in {System,}/Library/Launch{Daemons,Agents} directory exists
Change By:
Clay Caviness
If a file in the LaunchAgents or LaunchDaemons paths is encountered that's not:* a plain text file (plist or not)* a binary plist file (magic 'bplist00')then Puppet will crash with an error.To reproduce:{code}# cp /bin/ls /Library/LaunchDaemons# puppet resource serviceError: Could not run: invalid byte sequence in UTF-8{code}In [plist.rb line 34|https://github.com/puppetlabs/puppet/blob/ed209118fceb6433b51c88c10883cb7415b36adb/lib/puppet/util/plist.rb#L34] there's a check if it’s a binary plist or not.In the case of a binary blob that's on a binary plist, this will fail, and fall through to [parse_plist on line 55|https://github.com/puppetlabs/puppet/blob/ed209118fceb6433b51c88c10883cb7415b36adb/lib/puppet/util/plist.rb#L55], which tries to check the file's contents against the {{bad_xml_doctype]} regex.This fails because of the encoding.I expect the correct course of action is to handle the {{ArgumentError}} and return {{nil}}
Add Comment
This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at
Jira (PUP-6568) launchd service provider crashes if a non-text or binary plist file in {System,}/Library/Launch{Daemons,Agents} directory exists
Title: Message Title
Clay Caviness created an issue
Puppet / PUP-6568
launchd service provider crashes if a non-text or binary plist file in {System,}/Library/Launch{Daemons,Agents} directory exists
Issue Type:
Bug
Affects Versions:
PUP 4.5.2
Assignee:
Unassigned
Created:
2016/08/01 12:25 PM
Environment:
OS X 10.11.6 Puppet 4.5.2
Priority:
Normal
Reporter:
Clay Caviness
If a file in the LaunchAgents or LaunchDaemons paths is encountered that's not:
a plain text file (plist or not)
a binary plist file (magic 'bplist00')
then Puppet will crash with an error.
To reproduce:
Jira (PUP-6508) Multiple tidy resources with same path but different matches causes an error
Title: Message Title Clay Caviness commented on PUP-6508 Re: Multiple tidy resources with same path but different matches causes an error https://github.com/puppetlabs/puppet/pull/5121 Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6508) Multiple tidy resources with same path but different matches causes an error
Title: Message Title Clay Caviness commented on PUP-6508 Re: Multiple tidy resources with same path but different matches causes an error I believe this can be fixed by simply declaring tidy resources to be non-isomorphic (by adding @isomorphic = false to the type declaration). Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6508) Multiple tidy resources with same path but different matches causes an error
Title: Message Title Clay Caviness commented on PUP-6508 Re: Multiple tidy resources with same path but different matches causes an error This is confusing to me - exec sets command as namevar, but so long as each exec's resource's title is different, you can have multiple resources with the same command. Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6508) Multiple tidy resources with same path but different matches causes an error
Title: Message Title
Clay Caviness updated an issue
Puppet / PUP-6508
Multiple tidy resources with same path but different matches causes an error
Change By:
Clay Caviness
Having multiple {{tidy}} resources with the same {{path}} but different {{matches}} parameters causes an error:{code}$ puppet apply -e ' > tidy { "test1": > path => "/tmp/tidy", > matches => "some-regex.*", > recurse => true,> } > tidy { " test1 test2 ": > path => "/tmp/tidy", > matches => "some-other-regex.*", > recurse => true,> } > ' Error Notice : Evaluation Compiled catalog for derezzed.roam.corp.google.com in environment production in 0.05 seconds Error: Error while evaluating a Resource Statement, Duplicate declaration: Cannot alias Tidy[ test1 test2 ] is to ["/tmp/tidy"]; resource ["Tidy", "/tmp/tidy"] already declared in file :2; cannot redeclare at line 6 at line 6:1 on node localhost {code}The error is thrown during [catalog generation|https://github.com/puppetlabs/puppet/blob/master/lib/puppet/resource/catalog.rb#L189], the key passed into that alias method comes from the resource's [{{uniqueness_key}}|https://github.com/puppetlabs/puppet/blob/master/lib/puppet/resource/catalog.rb#L161] and class. The {{uniqueness_key}} is [generated|https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type.rb#L436] from the type's {{key_attributes}} which are all parameters that are [marked "isnamevar" or are called name|https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type.rb#L377]. The parameter Tidy declares {{isnamevar}} is [{{path}}|https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type/tidy.rb#L22], so having multiple Tidy resources with the same {{path}} will fail even if they have different {{matches}} parameters.
Add Comment
This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)
Jira (PUP-6508) Multiple tidy resources with same path but different matches causes an error
Title: Message Title Clay Caviness commented on PUP-6508 Re: Multiple tidy resources with same path but different matches causes an error I'm not sure exactly how to fix this; somehow I think namevar needs to be path+matches somehow? Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6508) Multiple tidy resources with same path but different matches causes an error
Title: Message Title
Clay Caviness created an issue
Puppet / PUP-6508
Multiple tidy resources with same path but different matches causes an error
Issue Type:
Bug
Affects Versions:
PUP 4.5.2
Assignee:
Kylo Ginsberg
Components:
Client
Created:
2016/07/15 7:53 AM
Priority:
Normal
Reporter:
Clay Caviness
Having multiple tidy resources with the same path but different matches parameters causes an error:
$ puppet apply -e '
tidy { "test1":
Jira (PUP-6502) puppet calls dscl pathologically often
Title: Message Title
Clay Caviness updated an issue
Puppet / PUP-6502
puppet calls dscl pathologically often
Change By:
Clay Caviness
A typical macOS puppet run triggers around 125 executions of {{/usr/bin/dscl}}; most of these are the {{ user }} {{ directoryservices }} provider calling {{ ' /usr/bin/dscl -plist . read /Users/ ShadowHashData ' }} for every user on the system.The provide provider already calls {{/usr/bin/dscl -plist . -readall /Users}}, however, and this plist contains the {{ShadowHashData}} for all the users.I think with some better memoization we can reduce the number of execs dramatically.
Add Comment
This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6502) puppet calls dscl pathologically often
Title: Message Title Clay Caviness commented on PUP-6502 Re: puppet calls dscl pathologically often I created https://github.com/puppetlabs/puppet/pull/5119; in local testing, this reduced the number of dscl execs from 125 to 20. Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6502) puppet calls dscl pathologically often
Title: Message Title Clay Caviness created an issue Puppet / PUP-6502 puppet calls dscl pathologically often Issue Type: Bug Affects Versions: PUP 4.5.2 Assignee: Kylo Ginsberg Components: Client Created: 2016/07/13 2:45 PM Environment: macOS 10.11.5 Priority: Normal Reporter: Clay Caviness A typical macOS puppet run triggers around 125 executions of /usr/bin/dscl; most of these are the user directoryservices provider calling '/usr/bin/dscl -plist . read /Users/ ShadowHashData' for every user on the system. The provide already calls /usr/bin/dscl -plist . -readall /Users, however, and this plist contains the ShadowHashData for all the users. I think with some better memoization we can reduce the number of execs dramatically.
Jira (FACT-1448) facter json output converts all booleans to true
Title: Message Title Clay Caviness commented on FACT-1448 Re: facter json output converts all booleans to true Serves me right for giving full repro steps Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1448) facter json output converts all booleans to true
Title: Message Title Clay Caviness commented on FACT-1448 Re: facter json output converts all booleans to true After seeing the fix (https://github.com/puppetlabs/facter/pull/1374/files), I'm now very curious how this was not affecting Arch Linux Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1448) facter json output converts all booleans to true
Title: Message Title Clay Caviness commented on FACT-1448 Re: facter json output converts all booleans to true I've no idea how to fix this, but https://github.com/puppetlabs/facter/pull/1373 might be an acceptance test that proves the bug. Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1452) facter 3.1.7/3.1.8 releases on github are versioned as 3.2.0
Title: Message Title Clay Caviness commented on FACT-1452 Re: facter 3.1.7/3.1.8 releases on github are versioned as 3.2.0 Also lib/CMakeLists.txt: set(LIBFACTER_VERSION_MAJOR 3) set(LIBFACTER_VERSION_MINOR 2) set(LIBFACTER_VERSION_PATCH 0) Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1452) facter 3.1.7/3.1.8 releases on github are versioned as 3.2.0
Title: Message Title
Clay Caviness created an issue
Facter / FACT-1452
facter 3.1.7/3.1.8 releases on github are versioned as 3.2.0
Issue Type:
Bug
Affects Versions:
FACT 3.1.8, FACT 3.1.7
Assignee:
Unassigned
Created:
2016/07/06 9:06 AM
Priority:
Normal
Reporter:
Clay Caviness
The tarball for facter versions 3.1.7 and 3.1.8, as available on https://github.com/puppetlabs/facter/releases, have PROJECT_NUMBER set to 3.2.0 in Doxyfile.
It is correctly set to 3.1.6 in the 3.1.6 tarball.
$ grep -r 3.2.0 ~/Downloads/facter-3.1.{6,7,8}
/Users/crc/Downloads/facter-3.1.7/lib/Doxyfile:PROJECT_NUMBER = 3.2.0
Jira (FACT-1448) facter json output converts all booleans to true
Title: Message Title
Clay Caviness created an issue
Facter / FACT-1448
facter json output converts all booleans to true
Issue Type:
Bug
Affects Versions:
FACT 3.1.4
Assignee:
Unassigned
Created:
2016/06/28 8:47 AM
Environment:
macOS 10.11
Priority:
Critical
Reporter:
Clay Caviness
When json output is requested, any fact value that is a boolean true/false is returned as true.
This is a pretty huge regression.
To recreate, add a simple fact like this:
Facter.add('jsontest') do
setcode do
Jira (PUP-6437) directoryservice user provider crashes if no ShadowHashData is found
Title: Message Title Clay Caviness commented on PUP-6437 Re: directoryservice user provider crashes if no ShadowHashData is found https://github.com/puppetlabs/puppet/pull/5056 Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6437) directoryservice user provider crashes if no ShadowHashData is found
Title: Message Title Clay Caviness created an issue Puppet / PUP-6437 directoryservice user provider crashes if no ShadowHashData is found Issue Type: Bug Affects Versions: PUP 4.5.2 Assignee: Unassigned Created: 2016/06/24 9:57 AM Environment: macOS 10.11.5 Priority: Normal Reporter: Clay Caviness Possibly related to link PUP-6410, if the user/directoryservice provider's get_attribute_from_dscl method returns nil when trying to fetch ShadowHashData, the whole thing explodes. We've only seen this rarely, and only when the provider's trying to read an empty username (which is probably another bug that should be handled). Debug: Prefetching directoryservice resources for user
Jira (PUP-5334) Puppet can't remove users from groups in OSX.
Title: Message Title Clay Caviness commented on PUP-5334 Re: Puppet can't remove users from groups in OSX. Ok, I had no idea group even had an auth_membership attribute. I've never set it before. If I add auth_membership => true to a group resource, it clears unwanted members correctly. So the bug, I guess?, is that without auth_membership there's a spurious notice of an attempted change. Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5334) Puppet can't remove users from groups in OSX.
Title: Message Title Clay Caviness commented on PUP-5334 Re: Puppet can't remove users from groups in OSX. If I change https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/nameservice/directoryservice.rb#L343 from: remove_unwanted_members(current_members, value) if @resource[:auth_membership] and not current_members.nil? to remove_unwanted_members(current_members, value) if not current_members.nil? then the resource applies successfully, and the extra group members are removed. But I have no idea what the :auth_membership parameter's supposed to be doing. Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)
Jira (PUP-5334) Puppet can't remove users from groups in OSX.
Title: Message Title
Clay Caviness commented on PUP-5334
Re: Puppet can't remove users from groups in OSX.
This is actually pretty important; if an unwanted user is added to a group that controls local admin ( {admin}
), puppet will not fix things properly.
Add Comment
This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5334) Puppet can't remove users from groups in OSX.
Title: Message Title Clay Caviness updated an issue Puppet / PUP-5334 Puppet can't remove users from groups in OSX. Change By: Clay Caviness Priority: Normal Major Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6410) launchd service provider crashes if a zero-length file in the {System,}/Library/Launch{Daemon,Agent} directory exists
Title: Message Title
Clay Caviness commented on PUP-6410
Re: launchd service provider crashes if a zero-length file in the {System,}/Library/Launch{Daemon,Agent} directory exists
https://github.com/puppetlabs/puppet/pull/5022
Add Comment
This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6410) launchd service provider crashes if a zero-length file in the {System,}/Library/Launch{Daemon,Agent} directory exists
Title: Message Title
Clay Caviness commented on PUP-6410
Re: launchd service provider crashes if a zero-length file in the {System,}/Library/Launch{Daemon,Agent} directory exists
Also, this is probably more an issue with Puppet::Util::Plist that the launchd service provider.
Add Comment
This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6410) launchd service provider crashes if a zero-length file in the {System,}/Library/Launch{Daemon,Agent} directory exists
Title: Message Title
Clay Caviness commented on PUP-6410
Re: launchd service provider crashes if a zero-length file in the {System,}/Library/Launch{Daemon,Agent} directory exists
I have a local patch that should fix this; let me do a bit more testing (and actually write some unit tests) to verify.
Add Comment
This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6410) launchd service provider crashes if a zero-length file in the {System,}/Library/Launch{Daemon,Agent} directory exists
Title: Message Title
Clay Caviness updated an issue
Puppet / PUP-6410
launchd service provider crashes if a zero-length file in the {System,}/Library/Launch{Daemon,Agent} directory exists
Change By:
Clay Caviness
If a zero-length file exists in the standard locations for OS X LaunchAgent or LaunchDaemons exist, puppet will exit with an error:{code}# touch /Library/LaunchDaemons/foo# puppet resource serviceError: Could not run: undefined method `elements' for nil:NilClass{code}Not only does this cause {{puppet resource}} to fail, but {{puppet apply}} as well, causing failures.I discovered this by adding some logging to {{provider/service/launchd.plist}}, and saw the failure was when trying to read {{/Library/LaunchDaemons/.plist.puppettmp_9913}}, so it appears an interrupted puppet run left the {{.puppettmp_9913}} file, which then caused future runs to fail.Puppet 3 is not affected, so this is a regression of sorts. It appears there's an unhandled exception down in {{ cfpropertlylist cfpropertylist }}:{code}$ sudo /Library/GoogleCorpSupport/bin/puppet resource --trace serviceError: Could not run: undefined method `elements' for nil:NilClass/Library/GoogleCorpSupport/Ruby/lib/ruby/site_ruby/cfpropertylist/rbREXMLParser.rb:22:in `load'/Library/GoogleCorpSupport/Ruby/lib/ruby/site_ruby/cfpropertylist/rbCFPropertyList.rb:312:in `load_str'/Library/GoogleCorpSupport/Ruby/lib/ruby/site_ruby/cfpropertylist/rbCFPropertyList.rb:248:in `initialize'/Library/GoogleCorpSupport/Ruby/lib/ruby/site_ruby/puppet/util/plist.rb:83:in `new'/Library/GoogleCorpSupport/Ruby/lib/ruby/site_ruby/puppet/util/plist.rb:83:in `new_cfpropertylist'/Library/GoogleCorpSupport/Ruby/lib/ruby/site_ruby/puppet/util/plist.rb:62:in `parse_plist'/Library/GoogleCorpSupport/Ruby/lib/ruby/site_ruby/puppet/util/plist.rb:39:in `read_plist_file'/Library/GoogleCorpSupport/Ruby/lib/ruby/site_ruby/puppet/provider/service/launchd.rb:196:in `read_plist'/Library/GoogleCorpSupport/Ruby/lib/ruby/site_ruby/puppet/provider/service/launchd.rb:138:in `block (2 levels) in make_label_to_path_map'/Library/GoogleCorpSupport/Ruby/lib/ruby/site_ruby/puppet/provider/service/launchd.rb:137:in `each'/Library/GoogleCorpSupport/Ruby/lib/ruby/site_ruby/puppet/provider/service/launchd.rb:137:in `block in make_label_to_path_map'/Library/GoogleCorpSupport/Ruby/lib/ruby/site_ruby/puppet/provider/service/launchd.rb:136:in `each'/Library/GoogleCorpSupport/Ruby/lib/ruby/site_ruby/puppet/provider/service/launchd.rb:136:in `make_label_to_path_map'/Library/GoogleCorpSupport/Ruby/lib/ruby/site_ruby/puppet/provider/service/launchd.rb:157:in `jobsearch'/Library/GoogleCorpSupport/Ruby/lib/ruby/site_ruby/puppet/provider/service/launchd.rb:106:in `instances'/Library/GoogleCorpSupport/Ruby/lib/ruby/site_ruby/puppet/type.rb:1162:in `block in instances'/Library/GoogleCorpSupport/Ruby/lib/ruby/site_ruby/puppet/type.rb:1155:in `collect'/Library/GoogleCorpSupport/Ruby/lib/ruby/site_ruby/puppet/type.rb:1155:in `instances'/Library/GoogleCorpSupport/Ruby/lib/ruby/site_ruby/puppet/indirector/resource/ral.rb:24:in `search'/Library/GoogleCorpSupport/Ruby/lib/ruby/site_ruby/puppet/indirector/indirection.rb:269:in `search'/Library/GoogleCorpSupport/Ruby/lib/ruby/site_ruby/puppet/application/resource.rb:225:in
Jira (PUP-6410) launchd service provider crashes if a zero-length file in the {System,}/Library/Launch{Daemon,Agent} directory exists
Title: Message Title
Clay Caviness created an issue
Puppet / PUP-6410
launchd service provider crashes if a zero-length file in the {System,}/Library/Launch{Daemon,Agent} directory exists
Issue Type:
Bug
Affects Versions:
PUP 4.4.1
Assignee:
Unassigned
Created:
2016/06/15 9:42 AM
Priority:
Normal
Reporter:
Clay Caviness
If a zero-length file exists in the standard locations for OS X LaunchAgent or LaunchDaemons exist, puppet will exit with an error:
# touch /Library/LaunchDaemons/foo
# puppet resource service
Error: Could not run: undefined method `elements' for nil:NilClass
Jira (FACT-1412) warning for falling back to system path?
Title: Message Title Clay Caviness created an issue Facter / FACT-1412 warning for falling back to system path? Issue Type: Bug Affects Versions: FACT 3.1.6 Assignee: Unassigned Created: 2016/05/06 1:52 PM Priority: Trivial Reporter: Clay Caviness If facter 3 is compiled with -DFACTER_PATH set, then anytime a binary isn't found a warning is issued. Is there a reason this is LOG_WARNING, and not LOG_INFO (or even LOG_DEBUG)? https://github.com/puppetlabs/facter/blob/4a495e877d68648b6315b1a68755627de4c3c52d/lib/inc/internal/util/agent.hpp#L25 My specific use case here is a compiled-from-OSS facter (and puppet), installed in a non-standard location. If I set FACTER_PATH, then every facter (and puppet) run, I see a warning: Warning: Facter: augparse not found at configured location , using PATH instead I would like to suppress this warning, or at least not have it at warning-level. Add Comment
Jira (FACT-1284) Facter::Util::Resolution.exec no longer sets $?.exitstatus based on exec result
Title: Message Title Clay Caviness commented on FACT-1284 Re: Facter::Util::Resolution.exec no longer sets $?.exitstatus based on exec result In the meantime, creating an :on_fail-like option for non-zero return would be great. Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1284) Facter::Util::Resolution.exec no longer sets $?.exitstatus based on exec result
Title: Message Title
Clay Caviness commented on FACT-1284
Re: Facter::Util::Resolution.exec no longer sets $?.exitstatus based on exec result
Not having access to the process return code is really making us do awkward things like Facter::Core::Execution.execute("/some/binary -with -args && echo true || echo false) == "true"
In my dreams, I wish that way back in the dawn of time, Facter::Core::Execution.execute (and the puppet equivalent}} was wrapping a popen3-style call, where I could pass in an array and get stdout, stderr, and return_code back separately.
Add Comment
This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6132) Puppet::Util::Plist should emit formatted plists
Title: Message Title Clay Caviness commented on PUP-6132 Re: Puppet::Util::Plist should emit formatted plists This isn't perfect; CFPropertyList uses 2 spaces for indent, but "proper" Apple plists are indented with tabs. Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6132) Puppet::Util::Plist should emit formatted plists
Title: Message Title Clay Caviness commented on PUP-6132 Re: Puppet::Util::Plist should emit formatted plists I've created https://github.com/puppetlabs/puppet/pull/4843 which fixes this. Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6132) Puppet::Util::Plist should emit formatted plists
Title: Message Title Clay Caviness created an issue Puppet / PUP-6132 Puppet::Util::Plist should emit formatted plists Issue Type: Bug Affects Versions: PUP 4.4.1 Assignee: Unassigned Created: 2016/04/06 2:25 PM Priority: Normal Reporter: Clay Caviness Puppet::Util::Plist's dump_plist and write_plist_file methods both emit poorly-formatted XML plists by default: $ ruby -e "require 'puppet';require 'puppet/util/plist'; puts Puppet::Util::Plist.dump_plist(['array','of','things'])"
Jira (FACT-1381) Facter module not available in at_exit
Title: Message Title Clay Caviness commented on FACT-1381 Re: Facter module not available in at_exit For the record, facter 2 works correctly: $ sudo facter -p uninitialized_constant facterversion facterversion => 2.4.4 uninitialized_constant => foo puts at exit Facter.warn at exit Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)
Jira (FACT-1381) Facter module not available in at_exit
Title: Message Title Clay Caviness created an issue Facter / FACT-1381 Facter module not available in at_exit Issue Type: Bug Affects Versions: FACT 3.1.4 Assignee: Unassigned Created: 2016/04/01 2:52 PM Priority: Normal Reporter: Clay Caviness A fact with an at_exit callback that uses the Facter module will fail with an uninitialized constant error. We're using this code to enable some fact caching: https://github.com/google/macops/blob/master/facter/cache.rb In it, we have an at_exit handler to ensure updated cached values are written on exit. Since the handler tries to use Facter.debug and other methods, a NameError is raised. A simpler code snippet to replicate this: require 'facter'
Jira (PUP-6073) LaunchDaemons/LaunchAgents with line continuations break puppet
Title: Message Title Clay Caviness commented on PUP-6073 Re: LaunchDaemons/LaunchAgents with line continuations break puppet After the usual git-confuses-me-so-blow-it-up-and-start-again shenanigans, I think I have a new pull request that's actually based on the 3.x branch. https://github.com/puppetlabs/puppet/pull/4804 Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6073) LaunchDaemons/LaunchAgents with line continuations break puppet
Title: Message Title Clay Caviness commented on PUP-6073 Re: LaunchDaemons/LaunchAgents with line continuations break puppet I don't have puppet 4 installed to verify, but I suspect puppet 4's use of CFPropertylist likely handles this correctly. I've made a pull request against puppet 3.8.6: https://github.com/puppetlabs/puppet/pull/4800 Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6073) LaunchDaemons/LaunchAgents with line continuations break puppet
Title: Message Title Clay Caviness created an issue Puppet / PUP-6073 LaunchDaemons/LaunchAgents with line continuations break puppet Issue Type: Bug Affects Versions: PUP 3.8.6 Assignee: Kylo Ginsberg Attachments: line.continuation.plist Components: Client Created: 2016/03/18 9:10 AM Environment: OS X 10.11, puppet 3.8.6 Priority: Normal Reporter: Clay Caviness When puppet encounters a valid (if rare) plist with a backslash line continuation, it will fail: Error: Could not prefetch service provider 'launchd': undefined method `to_ruby' for nil:NilClass I expect this is due to the plist-handling code in 3.8; if you catch NoMethodError and have the provider fall through to plutil
Jira (PUP-4714) /usr/bin and /usr/share immutable on OS X 10.11, breaking installers and upgrades
Title: Message Title Clay Caviness commented on PUP-4714 Re: /usr/bin and /usr/share immutable on OS X 10.11, breaking installers and upgrades Edited ext/osx/file_mapping.yaml and changed all the usr/ to usr/local/, and it works. Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-2855) Puppet agent segfault on OSX Mavericks when puppet master is running under passenger
Title: Message Title Clay Caviness commented on an issue Re: Puppet agent segfault on OSX Mavericks when puppet master is running under passenger I'm able to recreated this as well, puppet 3.6.1, OS X 10.9.4, system ruby. Add Comment Puppet / PUP-2855 Puppet agent segfault on OSX Mavericks when puppet master is running under passenger When running under the default WEBrick server puppet master and agents function as expected. When running under passenger agents on OSX Mavericks segfault (sorry, I don't have access to other versions of OSX currently). Agents running under CentOS 6.5 continue to function normally under passenger. Dump file attached. Here is the output: bash-3.2#... This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-2713) directoryservice provider has fragile version check
Title: Message Title
Clay Caviness created an issue
Puppet / PUP-2713
directoryservice provider has fragile version check
Issue Type:
Bug
Affects Versions:
3.5.1
Assignee:
Kylo Ginsberg
Components:
Types and Providers
Created:
02/Jun/14 1:53 PM
Priority:
Normal
Reporter:
Clay Caviness
The OS X directoryservice nameservice provider has a very fragile version check.
def self.fail_if_wrong_version
fail(Puppet does not support OS X versions 10.5) unless self.get_macosx_version_major = 10.5
end
If the major version were to ever be, say, 10.10, this will fail quite nicely.
The code should be updated to use something like:
fail() unless Gem::Version.new(self.get_macosx_version_major) = Gem::Version.new('10.5')
Jira (PUP-2713) directoryservice provider has fragile version check
Title: Message Title
Clay Caviness commented on an issue
Re: directoryservice provider has fragile version check
... and I bet there are other places where these poor comparisons happen.
Add Comment
Puppet / PUP-2713
directoryservice provider has fragile version check
The OS X directoryservice nameservice provider has a very fragile version check. {code} def self.fail_if_wrong_version fail(Puppet does not support OS X versions 10.5) unless self.get_macosx_version_major = 10.5 end {code} If the major version were to ever be, say, 10.10, this will fail quite nicely. The code should be updated ...
This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
--
You received this message because you are subscribed to the Google Groups Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-2713) directoryservice provider has fragile version check
Title: Message Title
Clay Caviness commented on an issue
Re: directoryservice provider has fragile version check
I think Puppet::Util::Package.versioncmp() may be preferred over Gem::Version
Add Comment
Puppet / PUP-2713
directoryservice provider has fragile version check
The OS X directoryservice nameservice provider has a very fragile version check. {code} def self.fail_if_wrong_version fail(Puppet does not support OS X versions 10.5) unless self.get_macosx_version_major = 10.5 end {code} If the major version were to ever be, say, 10.10, this will fail quite nicely. The code should be updated ...
This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
--
You received this message because you are subscribed to the Google Groups Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-2575) OS X group resource triggers spurious notice of a change
Title: Message Title
Clay Caviness commented on an issue
Re: OS X group resource triggers spurious notice of a change
And just to be certain, still happens with 10.9.3, puppet 3.5.1, facter 1.7.5.
$ echo 'group { somegroup: members = [root, clay] }
' | sudo puppet apply Notice: Compiled catalog for 379b828f-0a82-4649-8c1f-03007668ca38 in environment gmac_unstable in 0.13 seconds Notice: /Stage[main]/Main/Group[somegroup]/ensure: created Notice: Finished catalog run in 0.46 seconds $ echo 'group { somegroup: members = [clay, root] }
' | sudo puppet apply Notice: Compiled catalog for 379b828f-0a82-4649-8c1f-03007668ca38 in environment gmac_unstable in 0.13 seconds Notice: /Stage[main]/Main/Group[somegroup]/members: members changed 'root,clay' to 'clay,root' Notice: Finished catalog run in 0.30 seconds $ echo 'group { somegroup: members = [clay, root] }
' | sudo puppet apply Notice: Compiled catalog for 379b828f-0a82-4649-8c1f-03007668ca38 in environment gmac_unstable in 0.13 seconds Notice: /Stage[main]/Main/Group[somegroup]/members: members changed 'root,clay' to 'clay,root' Notice: Finished catalog run in 0.30 seconds
Add Comment
Puppet / PUP-2575
OS X group resource triggers spurious notice of a change
If I create a simple group resource on OS X: pre group { admin: members = [root, clay, localadmin] } /pre and apply it multiple times, each time it triggers a notice that the membership has changed, even though the group provider did not make any changes. pre # puppet -d group { admin: members = [root, clay, localadmin...
Jira (PUP-2575) OS X group resource triggers spurious notice of a change
Title: Message Title
Clay Caviness commented on an issue
Re: OS X group resource triggers spurious notice of a change
This still happens on OS X 10.9.2, puppet 3.2.3, and facter 1.7.2
Add Comment
Puppet / PUP-2575
OS X group resource triggers spurious notice of a change
If I create a simple group resource on OS X: pre group { admin: members = [root, clay, localadmin] } /pre and apply it multiple times, each time it triggers a notice that the membership has changed, even though the group provider did not make any changes. pre # puppet -d group { admin: members = [root, clay, localadmin...
This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
--
You received this message because you are subscribed to the Google Groups Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
