Jira (PUP-11241) Not all user attributes honor forcelocal (e.g. home, shell)
Title: Message Title Nate McCurdy updated an issue Puppet / PUP-11241 Not all user attributes honor forcelocal (e.g. home, shell) Change By: Nate McCurdy Affects Version/s: PUP 7.10.0 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.415709.1631667793000.130170.1631668860032%40Atlassian.JIRA.
Jira (PUP-11241) Not all user attributes honor forcelocal (e.g. home, shell)
Title: Message Title
Nate McCurdy updated an issue
Puppet / PUP-11241
Not all user attributes honor forcelocal (e.g. home, shell)
Change By:
Nate McCurdy
*Puppet Version:* 6.19.1, 7.9.0*Puppet Server Version:* N/A*OS Name/Version:* CentOS 7When setting {{forcelocal => true}} on a {{user}} resource, I'd expect all user attributes available via {{/etc/passwd}} to be used as the "is" value for the insync? check.This appears to not be the case for the {{home}] and {{shell}} attributes.Those are always checked against their values from directory services rather than from {{/etc/passwd}}, which means those attributes appear to change on each puppet run and the {{user}} resource is no longer idempotent.*Desired Behavior:*When an OS has directory services enabled (e.g. LDAP via SSSD) and a puppet-managed user exists in LDAP...Given an {{/etc/passwd}} file containing:{noformat}nate:x:1000:1001:hello world:/opt/hello:/bin/zsh{noformat}This code should read "shell", "home", and "comment" all from {{/etc/passwd}} when comparing the "is" state to the "should" state:{code}user { 'nate': ensure => present, forcelocal => true, shell => '/bin/zsh', home => '/opt/hello', comment=> 'hello world',}{code}*Actual Behavior:*Only "uid", "gid", "comment", and "groups" are fetched from {{/etc/passwd}} when {{forcelocal => true}}:https://github.com/puppetlabs/puppet/blob/7.11.0/lib/puppet/provider/user/useradd.rb#L60-L78"home" and "shell" are fetched from directory services, not from {{/etc/passwd}}.The user resource shows a change to "home" and "shell" on each Puppet run even though nothing is changing. *Related:*Support for "comment" when forcelocal is true was added here: https://github.com/puppetlabs/puppet/pull/7768Basically, I'm asking for that same support for all the other attributes pulled from {{/etc/passwd}} in [the finduser() method|https://github.com/puppetlabs/puppet/blob/7.11.0/lib/puppet/provider/user/useradd.rb#L80-L96]
Add Comment
Jira (PUP-11241) Not all user attributes honor forcelocal (e.g. home, shell)
Title: Message Title
Nate McCurdy updated an issue
Puppet / PUP-11241
Not all user attributes honor forcelocal (e.g. home, shell)
Change By:
Nate McCurdy
*Puppet Version:* 6.19.1, 7.9.0*Puppet Server Version:* N/A*OS Name/Version:* CentOS 7When setting {{forcelocal => true}} on a {{user}} resource, I'd expect all user attributes available via {{/etc/passwd}} to be used as the "is" value for the insync? check.This appears to not be the case for the {{home}] and {{shell}} attributes.Those are always checked against their values from directory services rather than from {{/etc/passwd}}, which means those attributes appear to change on each puppet run and the {{user}} resource is no longer idempotent.*Desired Behavior:*When an OS has directory services enabled (e.g. LDAP via SSSD) , and with a puppet-managed user exists in LDAP...Given an {{/etc/passwd}} file containing:{noformat}nate:x:1000:1001:hello world:/opt/hello:/bin/zsh{noformat}This code should read "shell", "home", and "comment" all from {{/etc/passwd}} when comparing the "is" state to the "should" state:{code}user { 'nate': ensure => present, forcelocal => true, shell => '/bin/zsh', home => '/opt/hello', comment=> 'hello world',}{code}*Actual Behavior:*Only "uid", "gid", "comment", and "groups" are fetched from {{/etc/passwd}} when {{forcelocal => true}}:https://github.com/puppetlabs/puppet/blob/7.11.0/lib/puppet/provider/user/useradd.rb#L60-L78"home" and "shell" are fetched from directory services, not from {{/etc/passwd}}.The user resource shows a change to "home" and "shell" on each Puppet run even though nothing is changing.
Add Comment
Jira (PUP-11241) Not all user attributes honor forcelocal (e.g. home, shell)
Title: Message Title
Nate McCurdy created an issue
Puppet / PUP-11241
Not all user attributes honor forcelocal (e.g. home, shell)
Issue Type:
Bug
Affects Versions:
PUP 7.9.0, PUP 6.19.1
Assignee:
Unassigned
Created:
2021/09/14 6:03 PM
Priority:
Normal
Reporter:
Nate McCurdy
Puppet Version: 6.19.1, 7.9.0 Puppet Server Version: N/A OS Name/Version: CentOS 7 When setting forcelocal => true on a user resource, I'd expect all user attributes available via /etc/passwd to be used as the "is" value for the insync? check. This appears to not be the case for the home}] and {{shell attributes. Those are always checked against their values from directory services rather than from /etc/passwd, which means those attributes appear to change on each puppet run and the user resource is no longer idempotent. Desired Behavior: When an OS has directory services enabled (e.g. LDAP via SSSD), and with an /etc/passwd file containing:
nate:x:1000:1001:hello world:/opt/hello:/bin/zsh
This code should read "shell", "home", and "comment" all from /etc/passwd when comparing the "is" state to the "should" state:
Jira (FACT-2929) Facter does not correctly detect that it is running inside of a podman container
Title: Message Title Yasmin Rajabi commented on FACT-2929 Re: Facter does not correctly detect that it is running inside of a podman container Hi Trevor Vaughan this isn't a workflow we have supported in the past so I'd love to understand a bit more what the use case is here and understand the high level story or business objective are you trying to accomplish? Thanks! 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.385244.1611846144000.129965.1631647500042%40Atlassian.JIRA.
Jira (PUP-11235) versioncmp() thinks 11.0 is greater than 11
Title: Message Title Tim Meusel commented on PUP-11235 Re: versioncmp() thinks 11.0 is greater than 11 The awesome Josh Cooper did some digging during the latest office-hours through the issue. The conversation: https://puppetcommunity.slack.com/archives/CFD8Z9A4T/p1631641997091600 tl;dr: > the algorithm is a little strange, if the version strings are different lengths, it'll always fall back to comparing the entire string... maybe it makes sense to add a python like coerce() method for all versioncmp() inputs? 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.413995.1630486051000.129917.1631644380465%40Atlassian.JIRA.
Jira (FACT-3065) submit facts for new facter releases to facterdb
Title: Message Title Ben Ford commented on FACT-3065 Re: submit facts for new facter releases to facterdb Basically, what we'd probably want to do is hook into the build/packaging CI pipeline. We would need automation to run puppet facts on each supported operating system and save the output to a file, like $ puppet facts > facts/4.2/centos-7-x86_64.facts then create a PR with all the files. Here's an example PR where a community member submitted facts. https://github.com/voxpupuli/facterdb/pull/181 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.412672.1629371747000.129609.1631633280269%40Atlassian.JIRA.
Jira (FACT-3022) `--json` flag inconsistencies between Facter 3 and Facter 4 when resolving external executable files
Title: Message Title Luchian Nemes assigned an issue to Luchian Nemes Facter / FACT-3022 `--json` flag inconsistencies between Facter 3 and Facter 4 when resolving external executable files Change By: Luchian Nemes Assignee: Luchian Nemes 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.396144.1618824316000.129536.1631631060163%40Atlassian.JIRA.
Jira (PDB-5262) Grouping by facts that contain "/" generates invalid SQL
Title: Message Title Sebastian Miclea created an issue PuppetDB / PDB-5262 Grouping by facts that contain "/" generates invalid SQL Issue Type: Bug Assignee: Unassigned Created: 2021/09/14 7:34 AM Priority: Normal Reporter: Sebastian Miclea Example query: ["extract",[["function", "count"], "facts.partitions.\/.size"], ["group_by", "facts.partitions.\/.size"]] Result: Unterminated identifier started at position 699 in SQL WITH inactive_nodes AS (SELECT certname FROM certnames WHERE (deactivated IS NOT NULL AND deactivated > '2021-08-31T14:29:44.254Z') OR (expired IS NOT NULL and expired > '2021-08-31T14:29:44.254Z')), not_active_nodes AS (SELECT certname FROM certnames WHERE (deactivated IS NOT NULL OR expired IS NOT NULL)) SELECT (fs.stable||fs.volatile)->'partitions'->'/'->'size' AS "facts.partitions./.size", count(*) count FROM factsets fs LEFT JOIN environments ON fs.environment_id = environments.id LEFT JOIN certnames ON fs.certname = certnames.certname WHERE NOT ((certnames.certname) in (SELECT certname FROM ( SELECT not_active_nodes.certname AS "certname" FROM not_active_nodes ) sub)) GROUP BY .size". Expected " char
Jira (FACT-3070) Facter allowlist
Title: Message Title Ciprian Badescu commented on FACT-3070 Re: Facter allowlist Vladislav Pozniak, on Facter 4 you can define your own fact groups and list the facts you want to block (https://puppet.com/docs/puppet/7/configuring_facter.html#configuring_facter-facter-conf-fact-groups), is this helping? What would be the purpose of blocking some facts? Blocking facts usually helps if all facts provided by a resolver are disabled (like all networking facts) while disabling specific networking fact will not increase speed since the networking resolver will still be executed. 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.414007.1630492281000.129359.1631619720210%40Atlassian.JIRA.
Jira (FACT-3070) Facter allowlist
Title: Message Title Ciprian Badescu updated an issue Facter / FACT-3070 Facter allowlist Change By: Ciprian Badescu Currently, there is feature to block groups of facts via 'blocklist' facter.conf option. But there is no feature to whitelist allowlist some facts.Practical example: I have XEN and KVM hypervisors. Networks on them are configured with network module. For bonding I need to gather macaddress_eth0 and macaddress_eth1 info to use it in config files. But with this facts, facter collects all the macaddresses of virtual servers on hypervisor, like:|macaddress_dxvkvottfafeuf|[ac:1f:6b:bd:65:9a|https://puppet.hosterby.com/fact/macaddress_dxvkvottfafeuf/ac%253A1f%253A6b%253Abd%253A65%253A9a]||macaddress_eshezzolxuwgui|[fe:16:3e:ca:52:56|https://puppet.hosterby.com/fact/macaddress_eshezzolxuwgui/fe%253A16%253A3e%253Aca%253A52%253A56]||macaddress_eth0|[ac:1f:6b:bd:65:98|https://puppet.hosterby.com/fact/macaddress_eth0/ac%253A1f%253A6b%253Abd%253A65%253A98]||macaddress_eth0.505|[ac:1f:6b:bd:65:98|https://puppet.hosterby.com/fact/macaddress_eth0.505/ac%253A1f%253A6b%253Abd%253A65%253A98]|So now I can't disable macadress_* facts totally, because I need some of them. And there is no option to block group and whitelist allowlist certain facts from blocked group, or maybe block with regex (in my case all except macaddress_eth*). Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97)
Jira (FACT-3070) Facter allowlist
Title: Message Title Ciprian Badescu updated an issue Facter / FACT-3070 Facter allowlist Change By: Ciprian Badescu Summary: Facter whitelist allowlist 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.414007.1630492281000.129352.1631619120032%40Atlassian.JIRA.
Jira (PUP-10925) Default timeout not respected for Windows services
Title: Message Title Ciprian Badescu updated an issue Puppet / PUP-10925 Default timeout not respected for Windows services Change By: Ciprian Badescu Fix Version/s: PUP 7.12.0 Fix Version/s: PUP 6.25.0 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.387947.1613664109000.129338.1631618040031%40Atlassian.JIRA.
Jira (FACT-3073) Inconsistencies to set Facter::Core::Execution.execute timeout
Title: Message Title Gabriel Nagy updated an issue Facter / FACT-3073 Inconsistencies to set Facter::Core::Execution.execute timeout Change By: Gabriel Nagy Release Notes: Bug Fix Release Notes Summary: Fix the mismatch of `Facter::Core::Execution.execute` arguments between Facter 3 and Facter 4. The `.execute` method now accepts a `timeout` option like Facter 3 does, and warns when unsupported options are passed in. (Fix contributed by community members https://github.com/smortex and https://github.com/johanfleury) 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.415028.1631164898000.129292.1631612400030%40Atlassian.JIRA.
Jira (FACT-3073) Inconsistencies to set Facter::Core::Execution.execute timeout
Title: Message Title Gabriel Nagy commented on FACT-3073 Re: Inconsistencies to set Facter::Core::Execution.execute timeout Merged to main in https://github.com/puppetlabs/facter/commit/2239630851761cb464fbb38cf75a8ee8f5b22ac3 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.415028.1631164898000.129290.1631612100032%40Atlassian.JIRA.
