Jira (PUP-10967) Puppet always prints errors in debug when trying to resolve account to SID
Title: Message Title Josh Cooper created an issue Puppet / PUP-10967 Puppet always prints errors in debug when trying to resolve account to SID Issue Type: Bug Affects Versions: PUP 7.5.0 Assignee: Unassigned Created: 2021/03/16 6:16 PM Priority: Minor Reporter: Josh Cooper Puppet on Windows shows the following errors when running with debugging: C:\> puppet agent -t --debug ... Debug: Processing report from xxx with processor Puppet::Reports::Store Debug: Could not retrieve raw SID bytes from 'Administrator': Failed to convert string SID: Administrator: The security ID structure is invalid. Debug: Could not retrieve raw SID bytes from 'Administrator': Failed to convert string SID: Administrator: The security ID structure is invalid.
Jira (FACT-2988) Facter takes 20+ seconds on Windows due to azure metadata query
Title: Message Title Josh Cooper updated an issue Facter / FACT-2988 Facter takes 20+ seconds on Windows due to azure metadata query Change By: Josh Cooper Summary: Facter is slow takes 20+ seconds on windows Windows due to azure metadata query 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.391392.1615942373000.167988.1615942500050%40Atlassian.JIRA.
Jira (FACT-2988) Facter takes 20+ seconds on Windows due to azure metadata query
Title: Message Title
Josh Cooper updated an issue
Facter / FACT-2988
Facter takes 20+ seconds on Windows due to azure metadata query
Change By:
Josh Cooper
The azure metadata fact takes 20+ seconds before timing out on Windows. {noformat} $ cmd /c facter --version4.0.52$ time cmd /c facter > /dev/nullreal 0m22.431suser 0m0.000ssys 0m0.000s{noformat} When running with debug you can see: {noformat} [2021-03-17 01:49:16.036357 ] DEBUG Facter::Resolvers::Az - Querying Az metadata[2021-03-17 01:49:37.076303 ] DEBUG Facter::Util::Resolvers::Http - Trying to connect to http://169.254.169.254/metadata/instance?api-version=2020-09-01 but got: execution expired{noformat} The EC2 fact uses the same IP address, so I'm not sure if the EC2 fact is blocked by default, or is excluded based on other criteria, or because the EC2 fact uses a very small connect timeout: [ https://github.com/puppetlabs/facter/blob/f169f54ddae91787b2f36a25d6e7cbc2330c5bbc/lib/facter/util/resolvers/http.rb#L10 ] Redhat8 doesn't have this issue:{noformat}[2021-03-17 00:53:25.649111 ] DEBUG Facter::Resolvers::Az - Querying Az metadata[2021-03-17 00:53:25.670289 ] DEBUG Facter::Util::Resolvers::Http - Trying to connect to http://169.254.169.254/metadata/instance?api-version=2020-09-01 but got: Failed to open TCP connection to 169.254.169.254:80 (Network is unreachable - connect(2) for "169.254.169.254" port 80){noformat}
Add Comment
This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Jira (FACT-2988) Facter is slow on windows due to azure metadata query
Title: Message Title Josh Cooper created an issue Facter / FACT-2988 Facter is slow on windows due to azure metadata query Issue Type: Bug Affects Versions: FACT 4.0.52 Assignee: Unassigned Created: 2021/03/16 5:52 PM Priority: Normal Reporter: Josh Cooper The azure metadata fact takes 20+ seconds before timing out on Windows. $ cmd /c facter --version 4.0.52 $ time cmd /c facter > /dev/null real 0m22.431s user 0m0.000s
Jira (PDB-5065) Stop returning HTML error from the API
Title: Message Title Austin Blatt created an issue PuppetDB / PDB-5065 Stop returning HTML error from the API Issue Type: Task Assignee: Unassigned Created: 2021/03/16 4:31 PM Priority: Normal Reporter: Austin Blatt If we don't do it as a part of PDB-5063, we should stop returning HTML errors because they are displayed poorly in the console Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Jira (PDB-5064) Handle \0x00 byte error and return a generic error message
Title: Message Title
Austin Blatt updated an issue
PuppetDB / PDB-5064
Handle \0x00 byte error and return a generic error message
Change By:
Austin Blatt
Acceptance Criteria:
- Catch the error and ensure the error message is just {{ERROR: invalid byte sequence for encoding UTF8: 0x00}}
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.391375.1615936736000.167961.1615937280032%40Atlassian.JIRA.
Jira (PDB-5064) Handle \0x00 byte error and return a generic error message
Title: Message Title
Austin Blatt updated an issue
PuppetDB / PDB-5064
Handle \0x00 byte error and return a generic error message
Change By:
Austin Blatt
You can reproduce the error in with{code}curl -G 'http://localhost:8080/pdb/query/v4?query=nodes\{certname="foo%00"\}' --output -{code}curl needs the {{--output -}} flag to allow printing the null byte to the terminal.
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.391375.1615936736000.167960.1615937220040%40Atlassian.JIRA.
Jira (PDB-5064) Handle \0x00 byte error and return a generic error message
Title: Message Title Austin Blatt created an issue PuppetDB / PDB-5064 Handle \0x00 byte error and return a generic error message Issue Type: Task Assignee: Unassigned Created: 2021/03/16 4:18 PM Priority: Normal Reporter: Austin Blatt 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
Jira (PUP-10966) Allow full-relative path references in file(), template(), related functions
Title: Message Title
Josh Cooper commented on PUP-10966
Re: Allow full-relative path references in file(), template(), related functions
Yeah the pseudo-relative thing is super confusing. I think my only concern is about not breaking existing modules. Someone might be currently using file('modname/files/a') and have a file in $codedir/environments//modname/files/files/a. With this change, puppet would look for $codedir/environments//modname/files/a which could be different than the old one. So we'd need to handle precedence and fallbacks...
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.391231.1615913392000.167615.1615924200048%40Atlassian.JIRA.
Jira (PUP-10937) Send release announcement (Puppet Platform 7.5.0)
Title: Message Title Eric Griswold assigned an issue to Eric Griswold Puppet / PUP-10937 Send release announcement (Puppet Platform 7.5.0) Change By: Eric Griswold Assignee: Morgan Rhodes Eric Griswold 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.388516.1614100285000.167562.1615921560036%40Atlassian.JIRA.
Jira (PUP-10937) Send release announcement (Puppet Platform 7.5.0)
Title: Message Title Morgan Rhodes assigned an issue to Morgan Rhodes Puppet / PUP-10937 Send release announcement (Puppet Platform 7.5.0) Change By: Morgan Rhodes Assignee: Jacklyn Kinsler Morgan Rhodes 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.388516.1614100285000.167324.1615914300043%40Atlassian.JIRA.
Jira (PUP-10966) Allow full-relative path references in file(), template(), related functions
Title: Message Title
Reid Vandewiele updated an issue
Puppet / PUP-10966
Allow full-relative path references in file(), template(), related functions
Change By:
Reid Vandewiele
One of Puppet's most confusing long-standing idioms is its use of pseudo-relative module file references. Most notably, in {{file()}}, {{template()}}, and related functions.{code:java}# This retrieves content from /modname/files/filenamefile('modname/filename')# This retrieves content from /modname/templates/filenametemplate('modname/filename') {code}This is difficult for new users to understand, and when ported to the command-line it breaks normal Unix behavior in that forward-slash does not reliably indicate a real file path, even relatively.h2. Feature RequestAnywhere these confusing references are used, permit instead full-relative path references, following this convention:{{/full/relative/path}}So, the examples above could be used instead as:{code:java} # This retrieves content from /modname/files/filenamefile('modname/files/filename')# This retrieves content from /modname/templates/filenametemplate('modname/templates/filename') {code}The same way that it has become best practice to always use a DSL option that includes the literal string "facts" when referencing facts for clarity*, this capability would improve intuitiveness, readability, and discoverability for new users.This will also make using a an ecosystem consistent full-relative module path more tenable in CLI applications.* e.g., don't use {{$::osfamily}}. Use {{getvar('facts.osfamily)}} or {{$facts['osfamily']}} instead.
Add Comment
Jira (PUP-10966) Allow full-relative path references in file(), template(), related functions
Title: Message Title
Reid Vandewiele created an issue
Puppet / PUP-10966
Allow full-relative path references in file(), template(), related functions
Issue Type:
Improvement
Assignee:
Unassigned
Created:
2021/03/16 9:49 AM
Priority:
Normal
Reporter:
Reid Vandewiele
One of Puppet's most confusing long-standing idioms is its use of pseudo-relative module file references. Most notably, in file(), template(), and related functions.
# This retrieves content from /modname/files/filename
file('modname/filename')
# This retrieves content from /modname/templates/filename
template('modname/filename')
This is difficult for new users to understand, and when ported to the command-line it breaks normal Unix behavior in that forward-slash does not reliably indicate
Jira (FACT-2930) Inconsistent handling of Date types in custom facts
Title: Message Title
Josh Cooper updated an issue
Facter / FACT-2930
Inconsistent handling of Date types in custom facts
Change By:
Josh Cooper
If a custom fact returns a {{Time}} value, then facter will report:{noformat}$ mkdir facts$ cat > facts/time.rb
Jira (FACT-2930) Inconsistent handling of Date types in custom facts
Title: Message Title
Josh Cooper updated an issue
Facter / FACT-2930
Inconsistent handling of Date types in custom facts
Change By:
Josh Cooper
If a custom fact returns a {{Time}} value, then facter will report: {noformat} $ mkdir facts$ cat > facts/time.rb
Jira (FACT-2965) Facter 4 outputs the processors.speed fact differently on AIX
Title: Message Title
Florin Dragos commented on FACT-2965
Re: Facter 4 outputs the processors.speed fact differently on AIX
The difference here is a result of c++ rounding up, and ruby rounding the number down. The read value is 342500 (Hz) when converted to Ghz results in 3.425. When this gets rounded to 2 decimals, it ends up as 3.42 in ruby and 3.43 in c++. This only happens when the Ghz value has more than 2 decimals and ends with 5. As a fix we can round the number before formatting: https://github.com/puppetlabs/facter/blob/b9f6c32acb7433f05fe6227cc25d9d1c359b2f5b/lib/facter/util/facts/unit_converter.rb#L22 like
format('%.2f', displayed_speed: validated_speed.round(2)).to_s
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
Jira (FACT-2987) Facter 4 outputs hypervisors.zone_id fact differently on Solaris
Title: Message Title
Gabriel Nagy updated an issue
Facter / FACT-2987
Facter 4 outputs hypervisors.zone_id fact differently on Solaris
Change By:
Gabriel Nagy
Running *puppet facts diff* on Amazon 6 Solaris 11 gives the following output:{code:json}" virtual hypervisors.zone.id ": { "new_value": " xen 0 ", "old_value": "xenhvm" 0 } , {code} Facter 4 reports a string, while Facter 3 reports an integer.Facter 4: https://github.com/puppetlabs/facter/blob/main/lib/facter/resolvers/solaris/zone.rb#L35Facter 3: https://github.com/puppetlabs/facter/blob/3.x/lib/src/facts/resolvers/zone_resolver.cc#L44Again, this can be an issue with how Facter represents integers, as Facter 3 saves a string value but outputs an integer.
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
Jira (FACT-2987) Facter 4 outputs hypervisors.zone_id fact differently on Solaris
Title: Message Title
Luchian Nemes created an issue
Facter / FACT-2987
Facter 4 outputs hypervisors.zone_id fact differently on Solaris
Issue Type:
Bug
Assignee:
Unassigned
Created:
2021/03/16 7:16 AM
Priority:
Normal
Reporter:
Luchian Nemes
Running puppet facts diff on Amazon 6 gives the following output:
"virtual": {
"new_value": "xen",
"old_value": "xenhvm"
}
Jira (FACT-2986) Facter 4 outputs virtual fact differently on Amazon 6
Title: Message Title
Gabriel Nagy updated an issue
Facter / FACT-2986
Facter 4 outputs virtual fact differently on Amazon 6
Change By:
Gabriel Nagy
Running *puppet facts diff* on Debian 9 Amazon 6 gives the following output:{code:json}" os.distro.description virtual ": { "new_value": " Debian GNU/Linux 9 (stretch) xen ", "old_value": " Debian GNU/Linux 9.0 (stretch) xenhvm "}{code} The minor version is missing in Facter 4
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.391213.1615903997000.166989.1615904160035%40Atlassian.JIRA.
Jira (FACT-2986) Facter 4 outputs virtual fact differently on Amazon 6
Title: Message Title
Luchian Nemes created an issue
Facter / FACT-2986
Facter 4 outputs virtual fact differently on Amazon 6
Issue Type:
Bug
Assignee:
Unassigned
Created:
2021/03/16 7:13 AM
Priority:
Normal
Reporter:
Luchian Nemes
Running puppet facts diff on Debian 9 gives the following output:
"os.distro.description": {
"new_value": "Debian GNU/Linux 9 (stretch)",
"old_value": "Debian GNU/Linux 9.0 (stretch)"
}
The minor version is missing in Facter 4
Jira (FACT-2985) Facter 4 outputs os.distro.description differently on Debian 9
Title: Message Title
Gabriel Nagy updated an issue
Facter / FACT-2985
Facter 4 outputs os.distro.description differently on Debian 9
Change By:
Gabriel Nagy
Running *puppet facts diff* on macOS Debian 9 gives the following output:{code:json} { " mountpoints os . /Volumes/puppet-agent-6 distro . 21.1.28.g8d35b8853-1.osx10.14.options.0 description ": { "new_value": " read-only Debian GNU/Linux 9 (stretch) ", "old_value": " readonly Debian GNU/Linux 9.0 (stretch) "}{code} There The minor version is an extra hyphen for {{readonly}} missing in the mountpoint options in Facter 4 . This is probably the culprit in 3: https://github.com/puppetlabs/facter/blob/3.x/lib/src/facts/bsd/filesystem_resolver.cc#L55.On the other hand, Facter 4, uses sys-filesystem: https://github.com/djberg96/sys-filesystem/blob/9880f127465e680534263ec0de078179d73ef18b/lib/sys/unix/sys/filesystem.rb#L16
Add Comment
This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
--
You
Jira (FACT-2985) Facter 4 outputs os.distro.description differently on Debian 9
Title: Message Title
Luchian Nemes created an issue
Facter / FACT-2985
Facter 4 outputs os.distro.description differently on Debian 9
Issue Type:
Bug
Assignee:
Unassigned
Created:
2021/03/16 7:09 AM
Priority:
Normal
Reporter:
Luchian Nemes
Running puppet facts diff on macOS gives the following output:
{
"mountpoints./Volumes/puppet-agent-6.21.1.28.g8d35b8853-1.osx10.14.options.0": {
"new_value": "read-only",
"old_value": "readonly"
}
There is an extra hyphen for readonly in the mountpoint options in Facter 4. This is probably the culprit in 3: https://github.com/puppetlabs/facter/blob/3.x/lib/src/facts/bsd/filesystem_resolver.cc#L55. On the other hand, Facter 4, uses sys-filesystem:
Jira (FACT-2984) Facter 4 outputs mountpoints facts differently on macOS
Title: Message Title Gabriel Nagy updated an issue Facter / FACT-2984 Facter 4 outputs mountpoints facts differently on macOS Change By: Gabriel Nagy Summary: CLONE - Facter 4 outputs mountpoints facts differently on macOS 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.391211.1615903504000.166981.1615903800046%40Atlassian.JIRA.
Jira (FACT-2984) CLONE - Facter 4 outputs mountpoints facts differently on macOS
Title: Message Title
Gabriel Nagy updated an issue
Facter / FACT-2984
CLONE - Facter 4 outputs mountpoints facts differently on macOS
Change By:
Gabriel Nagy
Running *puppet facts diff* on Solaris 11 SPARC macOS gives the following output:{code:json} "hypervisors.ldom.role_control": { " new_value": "false", "old_value": false},"hypervisors mountpoints . ldom /Volumes/puppet-agent-6 . role_io": { "new_value": "false", "old_value": false},"hypervisors 21 . ldom 1 . role_root 28.g8d35b8853-1.osx10.14.options.0 ": { "new_value": " false read-only ", "old_value": false}, " hypervisors.ldom.role_service readonly " : { "new_value": "false", "old_value": false } , {code} This may be due to how Facter 3 represents boolean values There is an extra hyphen for {{readonly}} in general, as ldom facts appear to be strings when placed the mountpoint options in Facter 4. This is probably the collection culprit in 3 : https://github.com/puppetlabs/facter/blob/3.x/lib/src/facts/ solaris bsd / ldom_resolver filesystem_resolver .cc#L55 .On the other hand, Facter 4, uses sys-filesystem: https://github.com/djberg96/sys-filesystem/blob/9880f127465e680534263ec0de078179d73ef18b/lib/sys/unix/sys/filesystem.rb#L16
Add Comment
This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Jira (FACT-2984) CLONE - Facter 4 outputs mountpoints facts differently on macOS
Title: Message Title
Luchian Nemes created an issue
Facter / FACT-2984
CLONE - Facter 4 outputs mountpoints facts differently on macOS
Issue Type:
Bug
Assignee:
Unassigned
Created:
2021/03/16 7:05 AM
Priority:
Normal
Reporter:
Luchian Nemes
Running puppet facts diff on Solaris 11 SPARC gives the following output:
"hypervisors.ldom.role_control": {
"new_value": "false",
"old_value": false
},
"hypervisors.ldom.role_io": {
"new_value": "false",
"old_value": false
Jira (FACT-2983) Facter 4 outputs ldom facts differently on Solaris SPARC
Title: Message Title
Gabriel Nagy updated an issue
Facter / FACT-2983
Facter 4 outputs ldom facts differently on Solaris SPARC
Change By:
Gabriel Nagy
Running *puppet facts diff* on Solaris 11 SPARC gives the following output:{code:json}" mountpoints hypervisors . /proc ldom . available role_control ": { "new_value": null, " old_value false " : "0 bytes"} ," mountpoints./proc.available_bytes": { "new_value": null, " old_value": 0 false }," mountpoints hypervisors . /proc ldom . capacity role_io ": { "new_value": null, " old_value false " : "100%"} ," mountpoints./proc.device": { "new_value": null, " old_value": "proc" false }," mountpoints hypervisors . /proc ldom . filesystem role_root ": { "new_value": null, " old_value false " : "proc"} ," mountpoints./proc.options.0": { "new_value": null, " old_value": "dev=860" false }," mountpoints hypervisors . /proc ldom . size role_service ": { "new_value": null, " old_value false " : "0 bytes"} ," mountpoints./proc.size_bytes": { "new_value": null, " old_value": 0 false }, "mountpoints./proc.used": { "new_value": null, "old_value": "0 bytes"},"mountpoints./proc.used_bytes": { "new_value": null, "old_value": 0},"mountpoints./system/contract.available": { "new_value": null, "old_value": "0 bytes"},"mountpoints./system/contract.available_bytes": { "new_value": null, "old_value": 0},"mountpoints./system/contract.capacity": { "new_value": null, "old_value": "100%"},"mountpoints./system/contract.device": { "new_value": null, "old_value": "ctfs"},"mountpoints./system/contract.filesystem": { "new_value": null, "old_value": "ctfs"},"mountpoints./system/contract.options.0": { "new_value": null, "old_value": "dev=8680001"},"mountpoints./system/contract.size": { "new_value": null, "old_value": "0 bytes"},"mountpoints./system/contract.size_bytes": { "new_value": null, "old_value": 0},"mountpoints./system/contract.used": { "new_value": null, "old_value": "0 bytes"},"mountpoints./system/contract.used_bytes": { "new_value": null, "old_value": 0},"mountpoints./system/object.available": { "new_value": null, "old_value": "0 bytes"},"mountpoints./system/object.available_bytes": { "new_value": null, "old_value": 0},"mountpoints./system/object.capacity": { "new_value": null, "old_value":
Jira (FACT-2983) Facter 4 outputs ldom facts differently on Solaris SPARC
Title: Message Title
Luchian Nemes created an issue
Facter / FACT-2983
Facter 4 outputs ldom facts differently on Solaris SPARC
Issue Type:
Bug
Assignee:
Unassigned
Created:
2021/03/16 6:58 AM
Priority:
Normal
Reporter:
Luchian Nemes
Running puppet facts diff on Solaris 11 gives the following output:
"mountpoints./proc.available": {
"new_value": null,
"old_value": "0 bytes"
},
"mountpoints./proc.available_bytes": {
"new_value": null,
"old_value": 0
Jira (FACT-2982) Facter 4 outputs mountpoints facts differently on Solaris
Title: Message Title
Gabriel Nagy updated an issue
Facter / FACT-2982
Facter 4 outputs mountpoints facts differently on Solaris
Change By:
Gabriel Nagy
Running *puppet facts diff* on AIX 7.1 and AIX 7.2 Solaris 11 gives the following output:{code:json}"mountpoints./proc.available": { "new_value": null, "old_value": "0 bytes"},"mountpoints./proc.available_bytes": { "new_value": null, "old_value": 0},"mountpoints./proc.capacity": { "new_value": null, "old_value": "100%"},"mountpoints./proc.device": { "new_value": null, "old_value": "proc"},"mountpoints./proc.filesystem": { "new_value": null, "old_value": "proc"},"mountpoints./proc.options.0": { "new_value": null, "old_value": "dev=860"},"mountpoints./proc.size": { "new_value": null, "old_value": "0 bytes"},"mountpoints./proc.size_bytes": { "new_value": null, "old_value": 0},"mountpoints./proc.used": { "new_value": null, "old_value": "0 bytes"},"mountpoints./proc.used_bytes": { "new_value": null, "old_value": 0},"mountpoints./system/contract.available": { "new_value": null, "old_value": "0 bytes"},"mountpoints./system/contract.available_bytes": { "new_value": null, "old_value": 0},"mountpoints./system/contract.capacity": { "new_value": null, "old_value": "100%"},"mountpoints./system/contract.device": { "new_value": null, "old_value": "ctfs"},"mountpoints./system/contract.filesystem": { "new_value": null, "old_value": "ctfs"},"mountpoints./system/contract.options.0": { "new_value": null, "old_value": "dev=8680001"},"mountpoints./system/contract.size": { "new_value": null, "old_value": "0 bytes"},"mountpoints./system/contract.size_bytes": { "new_value": null, "old_value": 0},"mountpoints./system/contract.used": { "new_value": null, "old_value": "0 bytes"},"mountpoints./system/contract.used_bytes": { "new_value": null, "old_value": 0},"mountpoints./system/object.available": { "new_value": null, "old_value": "0 bytes"},"mountpoints./system/object.available_bytes": { "new_value": null, "old_value": 0},"mountpoints./system/object.capacity": { "new_value": null, "old_value": "100%"},"mountpoints./system/object.device": { "new_value": null, "old_value": "objfs"},"mountpoints./system/object.filesystem": { "new_value": null,
Jira (FACT-2982) Facter 4 outputs mountpoints facts differently on Solaris
Title: Message Title
Gabriel Nagy updated an issue
Facter / FACT-2982
Facter 4 outputs mountpoints facts differently on Solaris
Change By:
Gabriel Nagy
Running *puppet facts diff* on AIX 7.1 and AIX 7.2 gives the following output:{code:json} { "mountpoints./ proc . capacity available ": {"new_value": "24.86%" null ,"old_value": " 57.10% 0 bytes " }, "mountpoints./ proc . used available_bytes ": {"new_value": null, " 509 old_value": 0},"mountpoints . 04 MiB /proc.capacity " : { "new_value": null ,"old_value": " 2.00 GiB 100% " }, "mountpoints./ proc . used_bytes device ": {"new_value": 533770240 null ,"old_value": 2147483648 "proc" }, "mountpoints./ admin proc . capacity filesystem ": {"new_value": "0.28%" null ,"old_value": " 50.07% proc " }, "mountpoints./ admin proc . used options.0 ": {"new_value": "364.00 KiB" null ,"old_value": " 128.00 MiB dev=860 " }, "mountpoints./ admin proc . used_bytes size ": {"new_value": 372736 null ,"old_value": 134217728 "0 bytes" }, "mountpoints./ home proc . capacity size_bytes ": {"new_value": null, " old_value": 0 },"mountpoints . 02% /proc.used " : { "new_value": null ,"old_value": " 50.01% 0 bytes " }, "mountpoints./ home proc . used used_bytes ": {"new_value": null, " 1004 old_value": 0},"mountpoints . 00 KiB /system/contract.available " : { "new_value": null ,"old_value": " 4.00 GiB 0 bytes " }, "mountpoints./ home system/contract . used_bytes available_bytes ": {"new_value": 1028096 null ,"old_value": 4294967296 0 }, "mountpoints./ opt system/contract .capacity": {"new_value": "18.86%" null ,"old_value": " 55.20 100 %" }, "mountpoints./ opt system/contract . used device ": {"new_value": "1.13 GiB" null ,"old_value": " 6.00 GiB ctfs " }, "mountpoints./ opt system/contract . used_bytes filesystem ": {"new_value": 1214803968 null ,"old_value": 6442450944 "ctfs" }, "mountpoints./ tmp system/contract . capacity options.0 ": {"new_value": "3.41%" null ,"old_value": " 50.87% dev=8680001 " }, "mountpoints./ tmp system/contract . used size ": {"new_value": "69.89 MiB" null ,"old_value": " 2.00 GiB 0 bytes " }, "mountpoints./ tmp system/contract . used_bytes size_bytes ": {"new_value": 73281536 null ,"old_value": 2147483648 0 }, "mountpoints./ usr system/contract . capacity used ": {"new_value": "43.94%" null ,"old_value": " 64.08% 0 bytes " }, "mountpoints./ usr system/contract . used used_bytes ": {"new_value": null, " 2 old_value": 0},"mountpoints . 20 GiB /system/object.available " : { "new_value": null ,"old_value": " 5.00 GiB 0 bytes " }, "mountpoints./ usr system/object . used_bytes available_bytes ": {"new_value": 2358939648 null ,"old_value": 5368709120 0 }, "mountpoints./ var system/object .capacity": {
Jira (FACT-2982) Facter 4 outputs mountpoints facts differently on Solaris
Title: Message Title
Luchian Nemes created an issue
Facter / FACT-2982
Facter 4 outputs mountpoints facts differently on Solaris
Issue Type:
Bug
Assignee:
Unassigned
Created:
2021/03/16 6:52 AM
Priority:
Normal
Reporter:
Luchian Nemes
Running puppet facts diff on AIX 7.1 and AIX 7.2 gives the following output:
{
"mountpoints./.capacity": {
"new_value": "24.86%",
"old_value": "57.10%"
},
"mountpoints./.used": {
"new_value": "509.04 MiB",
Jira (FACT-2963) Facter 4 outputs networking facts differently on AIX
Title: Message Title Sebastian Miclea commented on FACT-2963 Re: Facter 4 outputs networking facts differently on AIX This output is consistent with the other resolvers implemented for MacOs an Linux. For Solaris we've created FACT-2981 to address the inconsistency. 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.390824.1615557133000.166957.1615901580031%40Atlassian.JIRA.
Jira (FACT-2981) Loopback IPv6 ip is not returned correctly
Title: Message Title Sebastian Miclea created an issue Facter / FACT-2981 Loopback IPv6 ip is not returned correctly Issue Type: Bug Assignee: Unassigned Created: 2021/03/16 6:31 AM Priority: Normal Reporter: Sebastian Miclea In the IPv6 short notation `::` represents unspecified and `::1` represents loopback ip. Tested on solaris-11-x86_64 Output for networking.interfaces.lo0.bindings6.network and networking.interfaces.lo0.bindings6.address is `::` and should be `::1` according to the definition above. Facter3 does not output IPv6 on solaris at all. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Jira (FACT-2963) Facter 4 outputs networking facts differently on AIX
Title: Message Title Sebastian Miclea commented on FACT-2963 Re: Facter 4 outputs networking facts differently on AIX In the IPv6 short notation `::` represents unspecified and `::1` represents loopback ip. We've encountered this bug in Facter3 when implementing FACT-2878 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.390824.1615557133000.166930.1615900740030%40Atlassian.JIRA.
Jira (FACT-2807) Investigate differences on Aix
Title: Message Title Andrei Filipovici commented on FACT-2807 Re: Investigate differences on Aix Regarding the mountpoints fact, Facter 3 outputs the same value for used and size values. This is fixed in Facter 4. More info on this in: https://tickets.puppetlabs.com/browse/FACT-2964 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.372632.1600697236000.166929.1615900620126%40Atlassian.JIRA.
Jira (FACT-2964) Facter 4 outputs mountpoints facts differently on AIX
Title: Message Title
Andrei Filipovici commented on FACT-2964
Re: Facter 4 outputs mountpoints facts differently on AIX
Reproduced on aix71-power and aix72-power with: Facter 3.14.16 (commit d3b0a04d6722084993ab2dd3ee4180718ad71942) Facter 4.0.50 Facter 3.14.16 has an issue when it outputs the mountpoints data. The value for the mountpoint's size is identical to that of the mountpoint's used space. For example:
/ => {
available => "1.66 GiB",
available_bytes => 1785569280,
capacity => "54.60%",
device => "/dev/hd4",
filesystem => "jfs2",
options => [
"rw",
"log=/dev/hd8"
],
size => "*{color:red}2.00 GiB{color}*",
size_bytes => *2147483648*,
used => "*{color:red}2.00 GiB{color}*",
Jira (FACT-2980) Facter 4 outputs the processors.speed fact differently on Linux
Title: Message Title
Gabriel Nagy updated an issue
Facter / FACT-2980
Facter 4 outputs the processors.speed fact differently on Linux
Change By:
Gabriel Nagy
Running * puppet facts diff Note: * This might be an issue only on AIX 7 non-virtualized systems (with processors that support variable frequency)facter 3{code}$ /usr/bin/facter processors . 1 and AIX 7 speed4 . 2 gives the following output: 20 GHz {code :json } { facter 4 (2 consecutive queries) { code} " $ bundle exec facter processors.speed " 3.18 GHz$ bundle exec facter processors.speed1.06 GHz{code}Facter 4 reads from /proc/cpuinfo which reports the current speed of the processors : { code} "new_value" $ grep 'cpu MHz' /proc/cpuinfocpu MHz : "3 1724 . 42 GHz", 163 "old_value" cpu MHz : "3 1899 . 43 GHz" 271 cpu MHz : 2135.291cpu MHz : 1625.782cpu MHz : 1729.682cpu MHz : 1817.039cpu MHz : 1729.482cpu MHz : 1993.369{code } Facter 3 reads the max speed from the first CPU (in kHz, then converts it):{code } $ cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq420 {code} Note Facter 3 relevant code path : *EXCLUDE_LIST* from https://github.com/puppetlabs/ puppet facter /blob/ 6 3 .x/lib/ puppet src / face/ facts /linux/processor_resolver . rb cc # L5 needs to be manually emptied to see above results. L192 More info Facter 4 relevant code path : [ https:// docs github . google. com/ document puppetlabs / d facter / 1QlX_mv17fZ4eVZa9zHxvTRVJ5sq88aj3GjUC6lVFiz0 blob / edit#heading=h 5f092a30cd5c33c2715619cada943bc1a8e0fa04/lib/facter/resolvers/processors . gnnvlmulav1v] rb#L75
Add Comment
Jira (FACT-2980) Facter 4 outputs the processors.speed fact differently on Linux
Title: Message Title Gabriel Nagy updated an issue Facter / FACT-2980 Facter 4 outputs the processors.speed fact differently on Linux Change By: Gabriel Nagy Summary: CLONE - Facter 4 outputs the processors.speed fact differently on Linux 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.391203.1615892875000.166885.1615892940027%40Atlassian.JIRA.
Jira (FACT-2980) CLONE - Facter 4 outputs the processors.speed fact differently on Linux
Title: Message Title
Luchian Nemes created an issue
Facter / FACT-2980
CLONE - Facter 4 outputs the processors.speed fact differently on Linux
Issue Type:
Bug
Assignee:
Unassigned
Created:
2021/03/16 4:07 AM
Priority:
Normal
Reporter:
Luchian Nemes
Running puppet facts diff on AIX 7.1 and AIX 7.2 gives the following output:
{
{
"processors.speed": {
"new_value": "3.42 GHz",
"old_value": "3.43 GHz"
}
}
Jira (FACT-2960) Facter.conf doesn't accept in ttls singular form of time measure words
Title: Message Title Claire Cadman updated an issue Facter / FACT-2960 Facter.conf doesn't accept in ttls singular form of time measure words Change By: Claire Cadman Labels: doc_reviewed 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.390508.1615369213000.166847.1615888140027%40Atlassian.JIRA.
Jira (FACT-2962) Facter 4 should accept the same time units in ttls (config file field) as Facter 3
Title: Message Title Claire Cadman updated an issue Facter / FACT-2962 Facter 4 should accept the same time units in ttls (config file field) as Facter 3 Change By: Claire Cadman Labels: doc_reviewed 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.390510.1615373937000.166841.1615887660096%40Atlassian.JIRA.
