Describe the Bug

facter is not detecting that my cloud provider is aws on a specific system

Expected Behavior

A clear and concise description of what you expected to happen.
facter -p cloud should return
{
provider => "aws"
}

Steps to Reproduce

Steps to reproduce the behavior:
This system has been around for years. It started as CentOS7, changed to RHEL7, then upgraded to RHEL8. I don't have clear steps to reproduce, but I suspect this may be coming up because of what virt-what is returning. I can see that virt-what returns the following on the EC2 instance that is not detecting aws cloud provider.
xen
xen-hvm
aws

Environment

Red Hat Enterprise Linux release 8.9 (Ootpa)
facter 4.6.1
virt-what 1.25
puppet 8.5.1

Additional Context

root$ facter -p cloud --debug
[2024-04-30 16:05:03.650960 ] INFO Facter - executed with command line: -p cloud --debug
[2024-04-30 16:05:03.651031 ] DEBUG Facter - Facter version: 4.6.1
[2024-04-30 16:05:03.651054 ] DEBUG Facter - blocking collection of ec2_userdata facts
[2024-04-30 16:05:03.651076 ] DEBUG Facter::FactManager - Resolving facts sequentially
[2024-04-30 16:05:03.651648 ] DEBUG Facter::FactLoader - Loading all internal facts
[2024-04-30 16:05:03.653063 ] DEBUG Facter::FactLoader - Loading custom facts
[2024-04-30 16:05:03.902397 ] DEBUG Facter::FactManager - resolving fact with user_query: aio_agent_version
[2024-04-30 16:05:03.906898 ] DEBUG Facter::FactManager - Searching fact: aio_agent_version in file: aio_agent_version.rb
[2024-04-30 16:05:03.907329 ] DEBUG Facter::FactManager - Searching fact: aio_agent_version in core facts and external facts
[2024-04-30 16:05:03.907367 ] DEBUG Facter::FactLoader - Loading all internal facts
[2024-04-30 16:05:03.909855 ] DEBUG Facter::QueryParser - List of resolvable facts: [#<Facter::SearchedFact:0x00007f0f8736aa18 @name="aio_agent_version", @fact_class=Facts::Linux::AioAgentVersion, @user_query="aio_agent_version", @type=:core, @file=nil>]
[2024-04-30 16:05:03.910073 ] DEBUG Facter::FactLoader - Loading external facts
[2024-04-30 16:05:03.910760 ] DEBUG Facter::FactManager - fact "aio_agent_version" has resolved to: 8.5.1
[2024-04-30 16:05:04.007301 ] DEBUG Facter::FactManager - resolving fact with user_query: os.name
[2024-04-30 16:05:04.012362 ] DEBUG Facter::FactManager - Searching fact: os.name in file: os.name.rb
[2024-04-30 16:05:04.013167 ] DEBUG Facter::FactManager - Searching fact: os.name in core facts and external facts
[2024-04-30 16:05:04.013206 ] DEBUG Facter::FactLoader - Loading all internal facts
[2024-04-30 16:05:04.015744 ] DEBUG Facter::QueryParser - List of resolvable facts: [#<Facter::SearchedFact:0x00007f0f8a056860 @name="os.name", @fact_class=Facts::Rhel::Os::Name, @user_query="os.name", @type=:core, @file=nil>]
[2024-04-30 16:05:04.016029 ] DEBUG Facter::FactLoader - Loading external facts
[2024-04-30 16:05:04.016115 ] DEBUG Facter::FactManager - fact "os.name" has resolved to: RedHat
[2024-04-30 16:05:04.016609 ] DEBUG Facter::FactManager - resolving fact with user_query: os.family
[2024-04-30 16:05:04.017221 ] DEBUG Facter::FactManager - Searching fact: os.family in file: os.family.rb
[2024-04-30 16:05:04.018028 ] DEBUG Facter::FactManager - Searching fact: os.family in core facts and external facts
[2024-04-30 16:05:04.018064 ] DEBUG Facter::FactLoader - Loading all internal facts
[2024-04-30 16:05:04.020309 ] DEBUG Facter::QueryParser - List of resolvable facts: [#<Facter::SearchedFact:0x00007f0f88a09990 @name="os.family", @fact_class=Facts::Rhel::Os::Family, @user_query="os.family", @type=:core, @file=nil>]
[2024-04-30 16:05:04.020406 ] DEBUG Facter::FactLoader - Loading external facts
[2024-04-30 16:05:04.020486 ] DEBUG Facter::FactManager - fact "os.family" has resolved to: RedHat
[2024-04-30 16:05:04.084780 ] DEBUG Facter::FactManager - resolving fact with user_query: os.release.full
[2024-04-30 16:05:04.089231 ] DEBUG Facter::FactManager - Searching fact: os.release.full in file: os.release.full.rb
[2024-04-30 16:05:04.090148 ] DEBUG Facter::FactManager - Searching fact: os.release.full in core facts and external facts
[2024-04-30 16:05:04.090185 ] DEBUG Facter::FactLoader - Loading all internal facts
[2024-04-30 16:05:04.093480 ] DEBUG Facter::QueryParser - List of resolvable facts: [#<Facter::SearchedFact:0x00007f0f8737ec48 @name="os.release", @fact_class=Facts::Rhel::Os::Release, @user_query="os.release.full", @type=:core, @file=nil>]
[2024-04-30 16:05:04.093768 ] DEBUG Facter::FactLoader - Loading external facts
[2024-04-30 16:05:04.093853 ] DEBUG Facter::FactManager - Searching fact: os.release.full in all custom facts
[2024-04-30 16:05:04.093886 ] DEBUG Facter::FactLoader - Loading custom facts
[2024-04-30 16:05:04.098519 ] DEBUG Facter::FactManager - fact "os.release" has resolved to: {"full"=>"8.9", "major"=>"8", "minor"=>"9"}
[2024-04-30 16:05:04.105809 ] DEBUG Facter::FactLoader - Loading external facts
[2024-04-30 16:05:04.106781 ] DEBUG Facter::QueryParser - List of resolvable facts: [#<Facter::SearchedFact:0x00007f0f889bf6b0 @name="cloud.provider", @fact_class=Facts::Linux::Cloud::Provider, @user_query="cloud", @type=:core, @file=nil>]
[2024-04-30 16:05:04.107176 ] DEBUG Facter::Core::Execution::Posix - Executing command: uname -m &&
uname -n &&
uname -p &&
uname -r &&
uname -s &&
uname -v
[2024-04-30 16:05:04.116125 ] DEBUG Facter::Core::Execution::Posix - Executing command: virt-what

Use Case

Starting with Amazon Linux 2023, Amazon provides a minor release every three months and provides a timestamp within specific minor versions.

Currently, Facter only provides the major version of the OS for Amazon Linux:

$ facter os.distro
{
  codename => "Amazon Linux",
  description => "Amazon Linux release 2023 (Amazon Linux)",
  id => "Amazon",
  release => {
    full => "2023",
    major => "2023"
  }
}

Describe the Solution You Would Like

Facter should return as much information about the OS version as it can, including the minor release version and, within the os.distro.release.full fact, the timestamp (e.g. 2023.2.20230901). Something like this seems ideal:

$ facter os.distro
{
  codename => "Amazon Linux",
  description => "Amazon Linux release 2023 (Amazon Linux)",
  id => "Amazon",
  release => {
    full => "2023.1.20230912",
    major => "2023"
    minor => "1"
  }
}

It seems like Amazon does not provide this OS version information in the typical places that most vendors use, like /etc/os-release. It does look like querying the system-release package provides the full OS version information we'd need:

$ rpm -qa system-release
system-release-2023.1.20230912-0.amzn2023.noarch

Use Case

The processors.models fact can grow very large on systems with high core count, but low physical count. Since the model name is determined by the physical count, trimming this down to match the physical chips would reduce the sice of the fact list and avoid some confusion.

Describe the Solution You Would Like

Find the model name based on the physical chip used rather than just blindly for each core.

Describe Alternatives You've Considered

Filtering the fact out to reduce network burden.

Additional Context

I'm not sure if a set would be sufficient as you can infer if all the model names are identical than you have model count equal to physical count, but you wouldn't be able to directly count the number of different chips which would be handy.

Describe the Bug

After upgrading puppet 6.x to puppet 7.X facter failed in various ways:

Error: Facter: Permission denied @ rb_sysopen - /proc/1/environ
Error: Facter: Permission denied @ rb_sysopen - /proc/1/environ
Error: Facter: Permission denied @ rb_sysopen - /proc/1/environ
Error: Facter: Permission denied @ rb_sysopen - /proc/1/environ
Error: Facter: Permission denied @ rb_sysopen - /proc/1/environ
Error: Facter: Permission denied @ rb_sysopen - /proc/1/environ
Error: Facter: Permission denied @ rb_sysopen - /proc/1/environ
Error: Facter: Permission denied @ rb_sysopen - /proc/1/environ
Error: Facter: Permission denied @ rb_sysopen - /proc/1/environ
Error: Facter: Permission denied @ rb_sysopen - /proc/1/environ
Error: Facter: No such file or directory @ dir_initialize - /sys/block
Error: Facter: No such file or directory @ dir_initialize - /sys/block
Error: Facter: No such file or directory @ dir_initialize - /sys/block
Error: Facter: No such file or directory @ dir_initialize - /sys/block
Error: Facter: No such file or directory @ dir_initialize - /sys/block
Error: Facter: Permission denied @ rb_sysopen - /proc/1/environ
Error: Facter: Permission denied @ rb_sysopen - /proc/1/environ
Error: Facter: Permission denied @ rb_sysopen - /proc/1/environ
Error: Facter: Permission denied @ rb_sysopen - /proc/1/environ
Error: Facter: Permission denied @ rb_sysopen - /proc/1/environ
Error: Facter: Permission denied @ rb_sysopen - /proc/1/environ
Error: Facter: Permission denied @ rb_sysopen - /proc/1/environ
Error: Facter: Resolving fact cores_per_socket, but got undefined method `split' for nil:NilClass at /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter/resolvers/processors_lscpu.rb:34:in `build_threads_per_core'
Error: Facter: Resolving fact threads_per_core, but got undefined method `split' for nil:NilClass at /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter/resolvers/processors_lscpu.rb:34:in `build_threads_per_core'
Error: Facter: Permission denied @ rb_sysopen - /proc/1/environ

Expected Behavior

the puppet working on this container type (vservers) worked perfectly for many years but this upgrade it seems facter is a lot more brittle and need some files to be here even in container and chroot :)

Steps to Reproduce

enter a vserver container, launch facter 4.6.1

[2024-03-27 09:56:19.163808 ] ERROR Facter::InternalFactManager - Permission denied @ rb_sysopen - /proc/1/environ 
[2024-03-27 09:56:19.163908 ] ERROR Facter::InternalFactManager - Permission denied @ rb_sysopen - /proc/1/environ 
[2024-03-27 09:56:19.163953 ] ERROR Facter::InternalFactManager - Permission denied @ rb_sysopen - /proc/1/environ 
[2024-03-27 09:56:19.163995 ] ERROR Facter::InternalFactManager - Permission denied @ rb_sysopen - /proc/1/environ 
[2024-03-27 09:56:19.164036 ] ERROR Facter::InternalFactManager - Permission denied @ rb_sysopen - /proc/1/environ 
[2024-03-27 09:56:19.164083 ] ERROR Facter::InternalFactManager - Permission denied @ rb_sysopen - /proc/1/environ 
[2024-03-27 09:56:19.164126 ] ERROR Facter::InternalFactManager - Permission denied @ rb_sysopen - /proc/1/environ 
[2024-03-27 09:56:19.164166 ] ERROR Facter::InternalFactManager - Permission denied @ rb_sysopen - /proc/1/environ 

[2024-03-27 09:56:19.167729 ] ERROR Facter::Resolvers::Linux::Lscpu - Resolving fact cores_per_socket, but got undefined method `split' for nil:NilClass at /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter/resolvers/processors_lscpu.rb:34:in `build_threads_per_core' 
[2024-03-27 09:56:19.176157 ] ERROR Facter::Resolvers::Linux::Lscpu - Resolving fact threads_per_core, but got undefined method `split' for nil:NilClass at /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter/resolvers/processors_lscpu.rb:34:in `build_threads_per_core' 

[2024-03-27 09:56:19.176304 ] ERROR Facter::InternalFactManager - Permission denied @ rb_sysopen - /proc/1/environ 
[2024-03-27 09:56:19.176361 ] ERROR Facter::InternalFactManager - Permission denied @ rb_sysopen - /proc/1/environ 
[2024-03-27 09:56:19.176469 ] ERROR Facter::InternalFactManager - Permission denied @ rb_sysopen - /proc/1/environ 
[2024-03-27 09:56:19.176542 ] ERROR Facter::InternalFactManager - Permission denied @ rb_sysopen - /proc/1/environ 
[2024-03-27 09:56:19.179346 ] ERROR Facter::InternalFactManager - Permission denied @ rb_sysopen - /proc/1/environ 
[2024-03-27 09:56:19.179404 ] ERROR Facter::InternalFactManager - Permission denied @ rb_sysopen - /proc/1/environ 

[2024-03-27 09:56:19.199505 ] ERROR Facter::InternalFactManager - No such file or directory @ dir_initialize - /sys/block 
[2024-03-27 09:56:19.199539 ] ERROR Facter::InternalFactManager - No such file or directory @ dir_initialize - /sys/block 
[2024-03-27 09:56:19.199559 ] ERROR Facter::InternalFactManager - No such file or directory @ dir_initialize - /sys/block 
[2024-03-27 09:56:19.199586 ] ERROR Facter::InternalFactManager - No such file or directory @ dir_initialize - /sys/block 
[2024-03-27 09:56:19.199603 ] ERROR Facter::InternalFactManager - No such file or directory @ dir_initialize - /sys/block 

[2024-03-27 09:56:19.211224 ] ERROR Facter::InternalFactManager - Permission denied @ rb_sysopen - /proc/1/environ 
[2024-03-27 09:56:19.247188 ] ERROR Facter::InternalFactManager - Permission denied @ rb_sysopen - /proc/1/environ 
[2024-03-27 09:56:19.291965 ] ERROR Facter::InternalFactManager - Permission denied @ rb_sysopen - /proc/1/environ 
[2024-03-27 09:56:19.293036 ] ERROR Facter::InternalFactManager - Permission denied @ rb_sysopen - /proc/1/environ 

Environment

• Version puppet agent and server 7
• Platform ubuntu jammy for server, debian 10/11 for containers

Additional Context

the issue arrived after upgrading from puppet 6.x to 7.29

the first error seems to be in resolvers/containers.rb see farther for why.
the second one is lscpu in a container returning an error because the containers have an empty /sys directory

[~]: lscpu
lscpu: failed to determine number of CPUs: /sys/devices/system/cpu/possible: No such file or directory

the third is access to /sys/block as there is no /sys/block file at all in resolvers/partitions.rb and resolvers/disks.rb, i think a little check could be missing for this case ?

the first is generated because the container system show the /proc/1/environ file as here and readable but it block the access, so it is readable but not really. On previous factor it was not an issue this was skipped for vserver container but not here.

The second error is that lscpu is using /sys that is not present in the container (or chroot) and therefor the facts linked to it fail in error, /proc/cpuinfo is here and readable but not /sys/.

best regards,
Ghislain.

Currently, Facter requires Ruby >= 2.5 in order to be compatible with Puppetserver 7, older versions of which use JRuby 9.2.y.z (which targets compatibility with MRI 2.5).

We have attempted to drop Ruby 2.5 support in #2674, but encountered compatibility issues with those older versions of Puppetserver and had to revert in #2686

After the Puppet 7 series has been retired, we should bump up Facter’s minimum Ruby version to 3.1 to match with Puppet and Puppetserver 8.

We may want to wait until a new major Facter version to do this, although many projects drop compatibility with older versions of Ruby in minor releases (see Bundler, Nokogiri, AWS SDK, and more).

Describe the Bug

Even if EC2 is in the blocklist for facter, the cloud.provider fact will still make a call to EC2. The spot where it calls EC2 is here.

Expected Behavior

When EC2 is in the blocklist for facts, no calls should be made to EC2.

Workaround

Add the cloud.provider fact in the blocklist as well as EC2 to prevent the call.

Is related to #2672

Describe the Bug

Seen in the wild:

Error: Facter: undefined method `empty?' for nil:NilClass\n\n                       'gce' unless Facter::Resolvers::Gce.resolve(:metadata).empty?

Expected Behavior

Nil dereferences should not occur

Describe the Bug

On an ARM MacOS environment, facter's builtin processors.isa and os.architecture facts report the architecture being emulated by Rosetta, not the architecture of the host hardware.

Rosetta 2 is MacOS's system for the execution of Intel binaries on ARM-based (M1/2/3) Macs.

When a binary is Intel-only, or when a binary is "universal" and contains segments for both Intel and ARM, Rosetta 2 can be used to run it as x86_64.

Expected Behavior

• The computer's processors don't change to contain different silicon based on whether an emulation layer is present, so processors.isa (and hardwareisa) should not change based on whether facter is being run in an emulated capacity.
• The architecture for which MacOS was installed cannot change, so os.architecture (and architecture) should not change based on whether facter is being run in an emulated capacity.

Steps to Reproduce

1. Use MacOS 13 or better on an ARM (M1, M2, M3 etc) Mac. The arch command run without arguments should report arm64 or arm64e.
2. Install Rosetta on that Mac: softwareupdate --install-rosetta
3. Install facter.
4. Run facter in the arm64 architecture (should be the default), and observe that the isa/architecture related facts match the computer's hardware:

> arch -arch arm64 facter | grep 'isa\|arch'
architecture => "arm64",
isa => "arm",

5. Run facter via Rosetta emulation, and observe that the isa/architecture facts are now incorrect:

> arch -arch x86_64 facter | grep 'isa\|arch'
architecture => "x86_64",
isa => "i386",

Environment

MacOS 14.5, also reproduced on MacOS 13.

I was unable to install facter directly via gem as the dependency on the now-deprecated hpricot prevented compilation on my machine.

Instead, I reproduced this using two puppetlabs-official distributions of facter: facter 4.6.1 via brew install --cask puppet-agent (which ships with an ARM-only ruby 2.7.8p225 (2023-03-30 revision 1f4d455848) [arm64-darwin23]), and facter 4.7.0 via brew install --cask puppet-bolt (which ships with an x86_64 ruby 2.7.8p225 (2023-03-30 revision 1f4d455848) [x86_64-darwin21]. The x86-ness isn't implicated here, and is likely temporary pending resolution of a low-priority issue I reported))

Additional Context

This seems to be due to the os/processor facts' dependency on the uname propvider (e.g. here). uname is not an appropriate way to get hardware information on MacOS. It reports information about the current runtime/emulation context, not about the machine itself:

> uname -a
Darwin atropos.local 23.5.0 Darwin Kernel Version 23.5.0: Wed May  1 20:12:58 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6000 arm64
> arch -arch arm64 uname -a
Darwin atropos.local 23.5.0 Darwin Kernel Version 23.5.0: Wed May  1 20:12:58 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6000 arm64
> arch -arch x86_64 uname -a
Darwin atropos.local 23.5.0 Darwin Kernel Version 23.5.0: Wed May  1 20:12:58 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6000 x86_64

Use Case

I think those facts don't make much sense. They change on each puppet run and produce a lot of IO on PuppetDB and postgresql. Monitoring the system load should be done by a monitoring system. And instead of reporting the uptime, facter should only report the boot time.

Describe the Solution You Would Like

Less facts that change on each run

Describe Alternatives You've Considered

A clear and concise description of any alternative solutions or features you've considered.

Additional Context

Add any other context or screenshots about the feature request here.

Describe the Bug

Facter 4.5.2 returns the following:

C:\facter>bundle exec facter -j os.windows
{
  "os.windows": {
    "edition_id": "ServerStandard",
    "installation_type": "Server",
    "product_name": "Windows Server 2019 Standard",
    "release_id": "1809",
    "system32": "C:\\Windows\\system32"
  }
}

Facter 4.6.0 returns:

C:\facter>bundle exec facter -j os.windows
{
  "os.windows": {
    "edition_id": 1,
    "installation_type": 1,
    "product_name": 1,
    "release_id": 1,
    "system32": "C:\\Windows\\system32"
  }
}

Expected Behavior

It should return the same values as in facter 4.5.2.

Steps to Reproduce

C:\> cmd /c start /w msiexec /qn /i https://downloads.puppet.com/windows/puppet7/puppet-agent-7.29.0-x64.msi
C:\> "C:\Program Files\Puppet Labs\Puppet\bin\facter" -j os.windows
{
  "os.windows": {
    "edition_id": 1,
    "installation_type": 1,
    "product_name": 1,
    "release_id": 1,
    "system32": "C:\\Windows\\system32"
  }
}

Environment

• Version facter 4.6.0, which is included in both puppet-agent 7.29.0 and 8.5.0
• Platform All Windows

Additional Context

The regression was introduced in 2c291fe#diff-10a200cea4737fabe6bb18f02ff3e23802ec3e6a4526577ac7ae917d1366ddca. The value parameter was misnamed.

Describe the Bug

As seen in CI: if networking fails to resolve ipv6 interfaces (for example), a failure will be seen reporting an attempt to use each on a nil class. This line of code resolves to

A simple check for nil will prevent the exception.

Expected Behavior

find_in_interfaces should return nil if argument supplied is nil

We're not running in a cloud environment and don't want or need facter to hit metadata services. The docs say adding EC2 will prevent the facts being resolved but facter still tries to access the metadata services.

Testing with facter 4.2.8 on CentOS 7.9 and AlmaLinux 8.9.

Describe the Bug

$ facter cloud on Amazon Linux 2023 does not return anything:

$ facter --debug --trace cloud
[2023-11-27 18:59:57.339847 ] INFO Facter - executed with command line: --debug --trace cloud
[2023-11-27 18:59:57.339934 ] DEBUG Facter - Facter version: 4.5.1
[2023-11-27 18:59:57.345168 ] DEBUG Facter::FactManager - Resolving facts sequentially
[2023-11-27 18:59:57.345351 ] DEBUG Facter::FactLoader - Loading all internal facts
[2023-11-27 18:59:57.345468 ] DEBUG Facter::FactLoader - Loading custom facts
[2023-11-27 18:59:57.346790 ] DEBUG Facter::FactLoader - Loading external facts
[2023-11-27 18:59:57.348652 ] DEBUG Facter::QueryParser - List of resolvable facts: [#<Facter::SearchedFact:0x0000ffffab44e700 @name="cloud.provider", @fact_class=Facts::Linux::Cloud::Provider, @user_query="cloud", @type=:core, @file=nil>]
[2023-11-27 18:59:57.349621 ] DEBUG Facter::Core::Execution::Posix - Executing command: virt-what
[2023-11-27 18:59:57.352435 ] DEBUG Facter::Core::Execution::Posix - Failed while executing 'virt-what': No such file or directory - virt-what
[2023-11-27 18:59:57.352876 ] DEBUG Facter::Core::Execution::Posix - Executing command: vmware -v
[2023-11-27 18:59:57.355203 ] DEBUG Facter::Core::Execution::Posix - Failed while executing 'vmware -v': No such file or directory - vmware
[2023-11-27 18:59:57.355405 ] DEBUG Facter::Core::Execution::Posix - Executing command: virt-what
[2023-11-27 18:59:57.357737 ] DEBUG Facter::Core::Execution::Posix - Failed while executing 'virt-what': No such file or directory - virt-what
[2023-11-27 18:59:57.358147 ] DEBUG Facter::Util::FileHelper - File at: /proc/xen/capabilities is not accessible.
[2023-11-27 18:59:57.358288 ] DEBUG Facter::Core::Execution::Posix - Executing command: ["/usr/sbin/xl", "/usr/sbin/xm"] list
[2023-11-27 18:59:57.362118 ] DEBUG Facter::Resolvers::Xen - Command ["/usr/sbin/xl", "/usr/sbin/xm"] list completed with the following stderr message: sh: line 1: [/usr/sbin/xl,: No such file or directory

$

Expected Behavior

As with previous versions of Amazon Linux, I would expect Facter to return information about what cloud provider it is running on.

For example, on Amazon Linux 2:

$ facter os.distro.description
Amazon Linux release 2 (Karoo)
$ facter cloud
{
  provider => "aws"
}

Environment

$ facter --version
4.5.1
$ rpm -qa system-release
system-release-2023.2.20231113-1.amzn2023.noarch

Additional Context

It seems like previous versions of Amazon Linux had virt-what already installed and Facter was using that to detect that it was running in AWS.

In Amazon Linux 2023, that package is not present and we are falling through into other virtual detectors that do not appear to give us the information we need to determine that we are running in AWS.

However, Facter is able to resolve the ec2_metadata fact.

Facter has the same issue as puppet, see puppetlabs/puppet#9306 for complete details

Describe the Bug

While rearching #2664 and #2715 I noticed a few different classes of issues with Facter's logging system.

Tests often overwrite the global Logger with an instance_spy, but don't restore the original logger after each test:

before do
  Facter::Log.class_variable_set(:@@logger, logger_double)
end

This causes global state to leak across tests leading to rspec reporting:

 #<InstanceDouble(Facter::Log) (anonymous)> was originally created in one
    example but has leaked into another example and can no longer be used.

Tests also overwrite the global logger with an instance spy and restore it with a different logger instance instead of the original instance:

before do
  Facter::Log.class_variable_set(:@@logger, logger_double)
end

after do
  Facter::Log.class_variable_set(:@@logger, Logger.new(STDOUT))
end

A similar problem exists with resolvers as the each resolver class has a Facter::Log instance:

before do
  augeas.instance_variable_set(:@log, log_spy)
end

The problem is made worse, because some resolvers eagerly create their resolver:

class Uname < BaseResolver
  @log = Facter::Log.new(self)

While others rely on the BaseResolver to lazily create it:

class BaseResolver
  def self.log
    @log ||= Log.new(self)

As a result, you can never be sure if a resolver has a logger, and if so, who created it (the code or test).

Finally if aggregated facts are evaluated twice, they attempt to log a message to a nil logger.

Expected Behavior

Since Facter's Logger and Facter::Log are global state, they should be immutable.

Please consider adding more filtering capabilities to facter.

Consider the following use cases:

• large structured fact sub-trees, like rhsm.enabled_repo_ids
• sensitive data inside a structured fact, like gce.instance.project.attributes.ssh-keys
• facts based on values, like mountpoints /var/lib/docker/overlay*
• exclude values, everything except cpuinfo.0 (see #2677)

The feature was previously requested in archive project https://puppet.atlassian.net/browse/FACT-769

Use Case

Some manufactures put their model information under "Version" others under "Product Name". Having both will help include the expected information. The "Family" field may also be useful

Describe the Solution You Would Like

Include the Version field from the dmi information

Describe Alternatives You've Considered

Weird local hacks

Additional Context

From a Dell system:

System Information
        Manufacturer: Dell Inc.
        Product Name: Precision 3660
        Version: Not Specified
        Serial Number: D7DJSAY
        UUID: 4c4caa44-00a7-3a10-804a-c4c0bb37c933
        Wake-up Type: Power Switch
        SKU Number: 0A9F
        Family: Precision

From a Lenovo system:

System Information
        Manufacturer: LENOVO
        Product Name: 30C6S3WT00
        Version: ThinkStation P330
        Serial Number: MA09AC3D
        UUID: be1aa8a2-a3da-e9b1-bfc5-00ddd190e433
        Wake-up Type: Power Switch
        SKU Number: LENOVO_MT_30C6_BU_Think_FM_ThinkStation P330
        Family: ThinkStation P330

From a Supermicro system:

System Information
        Manufacturer: Supermicro
        Product Name: X9DRW
        Version: 0123456789
        Serial Number: 0123456789
        UUID: 00000000-0000-0000-0000-0000000000
        Wake-up Type: Power Switch
        SKU Number: To be filled by O.E.M.
        Family: To be filled by O.E.M.

From a HP system:

System Information
        Manufacturer: HPE
        Product Name: ProLiant DL380 Gen10
        Version: Not Specified
        Serial Number: CD29A00ANK
        UUID: 3738aa38-3b30-5ac3-32a9-323dd04c4e4b
        Wake-up Type: Power Switch
        SKU Number: 868703-B21
        Family: ProLiant

From an Asus system:

System Information
        Manufacturer: ASUSTeK COMPUTER INC.
        Product Name: RS720A-E11-RS24U
        Version: 00
        Serial Number: NAS0SD003059
        UUID: 78d8a699-a4cd-270e-9ac2-0b421ddcabaaa
        Wake-up Type: Power Switch
        SKU Number: SKU
        Family: Server

From an Intel system:

System Information
        Manufacturer: Intel(R) Client Systems
        Product Name: NUC10i7FNH
        Version: K61081-302
        Serial Number: GEFN00000000
        UUID: 32102a1f-30ea-1a60-801a-1c690a6aaf53
        Wake-up Type: Power Switch
        SKU Number: BXNUC10i7FNH
        Family: FN

Facter uses the ronn gem for generating manpages. However, ronn and its dependencies (like hpricot) have been unmaintained for ~14 years.

Recently, Clang 16 has started raising errors for building native extensions for hpricot (as reported in Homebrew and also seen in FreeBSD). It seems unlikely that this will be fixed upstream, and we will probably see more issues with ronn and hpricot as time goes on.

Homebrew has recently gone through this process and ultimately ended up going with Kramdown: Homebrew/brew#16868

ronn-ng is also an option: https://github.com/apjanke/ronn-ng

Use Case

for each cpu core a fact with cpu information is generated. On systems with a high cpu count (for example AMD epyc with 128 cores) a lot of facts are generated. (more then 16k facts)

Describe the Solution You Would Like

have the possibility filter all cpuinfoinformation except cpuinfo.0

Describe Alternatives You've Considered

blocklist cpuinfo will block all information. having the flags of the first core provides enough information for most use cases.

Describe the Bug

Line 115 of aggregate.rb tries to call 'log.warn', but 'log' is unknown, which breaks legacy builds.

Expected Behavior

Custom facts using legacy aggregate reference do not cause errors to be thrown during puppet install

Steps to Reproduce

Steps to reproduce the behavior:

1. Create new module with lib/facter/[customfact].rb that uses 'Facter.define_fact([name], type: :aggregate)' and 'define_resolution([name], type: :aggregate)
2. Run puppet

Environment

• Version facter [4.7.0] puppet [8.6.0]
• Platform [RHEL 8]

Additional Context

Describe the Bug

facter -d shows that "desktop management interface facts cache file expired, missing or is corrupt" even that it set to cache by settings.

/etc/puppetlabs/facter/facter.conf

facts : {
    blocklist : ["EC2","hypervisors"]
    ttls : [{"desktop management interface":"30 days"},{"virtualization":"30 days"},{"path":"30 days"},{"ssh":"30 days"},{"timezone":"30 days"},{"id":"30 days"},{"fips":"30 days"},{"augeas":"30 days"},{"Xen":"30 days"},{"EC2":"30 days"},{"GCE":"30 days"}]
}

facter -d dmi
[2024-05-07 09:29:00.081147 ] INFO Facter - executed with command line: -d dmi
[2024-05-07 09:29:00.081228 ] DEBUG Facter - Facter version: 4.5.1
[2024-05-07 09:29:00.081254 ] DEBUG Facter - blocking collection of EC2 hypervisors facts
[2024-05-07 09:29:00.081313 ] DEBUG Facter::ClassDiscoverer - There is no module named Centos
[2024-05-07 09:29:00.083404 ] DEBUG Facter::FactManager - Resolving facts sequentially
[2024-05-07 09:29:00.086731 ] DEBUG Facter::FactLoader - Loading all internal facts
[2024-05-07 09:29:00.098411 ] DEBUG Facter::FactLoader - Loading custom facts
[2024-05-07 09:29:00.099477 ] DEBUG Facter::FactLoader - Loading external facts
[2024-05-07 09:29:00.155169 ] DEBUG Facter::QueryParser - List of resolvable facts: [#<Facter::SearchedFact:0x0000000002176428 @name="dmi.product.name", @fact_class=Facts::Linux::Dmi::Product::Name, @user_query="dmi", @type=:core, @file=nil>, #<Facter::SearchedFact:0x0000000002176018 @name="dmi.product.serial_number", @fact_class=Facts::Linux::Dmi::Product::SerialNumber, @user_query="dmi", @type=:core, @file=nil>, #<Facter::SearchedFact:0x0000000002175898 @name="dmi.product.uuid", @fact_class=Facts::Linux::Dmi::Product::Uuid, @user_query="dmi", @type=:core, @file=nil>, #<Facter::SearchedFact:0x0000000002174ec0 @name="dmi.board.product", @fact_class=Facts::Linux::Dmi::Board::Product, @user_query="dmi", @type=:core, @file=nil>, #<Facter::SearchedFact:0x0000000002174560 @name="dmi.board.serial_number", @fact_class=Facts::Linux::Dmi::Board::SerialNumber, @user_query="dmi", @type=:core, @file=nil>, #<Facter::SearchedFact:0x00000000023f2f08 @name="dmi.board.asset_tag", @fact_class=Facts::Linux::Dmi::Board::AssetTag, @user_query="dmi", @type=:core, @file=nil>, #<Facter::SearchedFact:0x00000000023f2a80 @name="dmi.board.manufacturer", @fact_class=Facts::Linux::Dmi::Board::Manufacturer, @user_query="dmi", @type=:core, @file=nil>, #<Facter::SearchedFact:0x00000000023f1c20 @name="dmi.chassis.asset_tag", @fact_class=Facts::Linux::Dmi::Chassis::AssetTag, @user_query="dmi", @type=:core, @file=nil>, #<Facter::SearchedFact:0x00000000023f1180 @name="dmi.chassis.type", @fact_class=Facts::Linux::Dmi::Chassis::Type, @user_query="dmi", @type=:core, @file=nil>, #<Facter::SearchedFact:0x00000000023e1ac8 @name="dmi.bios.version", @fact_class=Facts::Linux::Dmi::Bios::Version, @user_query="dmi", @type=:core, @file=nil>, #<Facter::SearchedFact:0x00000000023e1050 @name="dmi.bios.vendor", @fact_class=Facts::Linux::Dmi::Bios::Vendor, @user_query="dmi", @type=:core, @file=nil>, #<Facter::SearchedFact:0x00000000023e0830 @name="dmi.bios.release_date", @fact_class=Facts::Linux::Dmi::Bios::ReleaseDate, @user_query="dmi", @type=:core, @file=nil>, #<Facter::SearchedFact:0x00000000023e0218 @name="dmi.manufacturer", @fact_class=Facts::Linux::Dmi::Manufacturer, @user_query="dmi", @type=:core, @file=nil>]
[2024-05-07 09:29:00.155686 ] DEBUG Facter::CacheManager - desktop management interface facts cache file expired, missing or is corrupt
[2024-05-07 09:29:00.155743 ] DEBUG Facter::Util::FileHelper - File at: /opt/puppetlabs/facter/cache/cached_facts/desktop management interface is not accessible.
[2024-05-07 09:29:00.156122 ] DEBUG Facter::CacheManager - desktop management interface facts cache file expired, missing or is corrupt
[2024-05-07 09:29:00.156472 ] DEBUG Facter::CacheManager - desktop management interface facts cache file expired, missing or is corrupt
[2024-05-07 09:29:00.156901 ] DEBUG Facter::CacheManager - desktop management interface facts cache file expired, missing or is corrupt
[2024-05-07 09:29:00.157371 ] DEBUG Facter::CacheManager - desktop management interface facts cache file expired, missing or is corrupt
...

cat /opt/puppetlabs/facter/cache/cached_facts/desktop\ management\ interface
{
  "bios_version": "2.19.0",
  "bios_release_date": "12/12/2023",
  "serialnumber": "F5SX9Q2",
  "uuid": "4C4C4544-0035-5310-8058-C6C04F395132",
  "boardproductname": "02C2CP",
  "boardserialnumber": ".F5SX9Q2.CNIVC0082Q0694.",
  "chassistype": "Rack Mount Chassis",
  "dmi.bios.version": "2.19.0",
  "dmi.bios.release_date": "12/12/2023",
  "dmi.product.serial_number": "F5SX9Q2",
  "dmi.product.uuid": "4C4C4544-0035-5310-8058-C6C04F395132",
  "dmi.board.product": "02C2CP",
  "dmi.board.serial_number": ".F5SX9Q2.CNIVC0082Q0694.",
  "dmi.chassis.type": "Rack Mount Chassis",
  "cache_format_version": 1
}

Expected Behavior

dmi data should be cached properly and not rerun every run puppet/facter.

Steps to Reproduce

Steps to reproduce the behavior:
facter -d dmi

Environment

• Version [4.5.1], puppet version 7.27
• Platform [CentOS7, Oracle Linux 9]

Additional Context

ls -al /opt/puppetlabs/facter/cache/cached_facts/

-rw-r--r--. 1 root root   90 May  7 00:07 augeas
-rw-r--r--. 1 root root  608 May  7 10:07 desktop management interface
-rw-r--r--. 1 root root   56 May  7 00:07 fips
-rw-r--r--. 1 root root  192 May  7 00:07 id
-rw-r--r--. 1 root root  100 May  7 00:07 path
-rw-r--r--. 1 root root 3062 Nov  8 22:25 processor
-rw-r--r--. 1 root root 2509 May  7 00:07 ssh
-rw-r--r--. 1 root root   52 May  7 00:07 timezone
-rw-r--r--. 1 root root   79 May  7 10:07 virtualization

files virtualization and desktop management interface shouldn't changed every puppet run because it should be cached and renewed only one time in 30 days as it set in facter config.

Use Case

Currently I observe that a lot of facts/factsets pushed in puppetdb which is not needed. For example I don't need info about virtual interfaces on host, like cali, docker, veth and etc. Currently I can block only all interfaces in blocklist like "networking.interfaces" but not "networking.interfaces.cali.*", "networking.interfaces.veth.*", "networking.interfaces.docker.*", "networking.interfaces.macvtap.*", "networking.interfaces.vnet.*", "networking.interfaces.tunl.*".
Also it's impossible to block on puppetdb level because of new structure with hashes instead of flat sctructure.
Also block doesn't work for 3rd level of hierarchy like "networking.interfaces.docker0" doesn't block this fact, only whole "networking.interfaces" works.

Describe the Solution You Would Like

I would like to store less facts in puppetdb and/or output in facter output. It would be perfect if we can block facts/facts block by wildcard/regexp (like in puppetdb with facts-blocklist-type = regex).

Describe the Bug

$ /opt/puppetlabs/bin/facter networking
{
  dhcp => "xxx.xxx.xxx.xxx",
  domain => ".",
  fqdn => "xxx-xxx-prd-vm03..",
  hostname => "xxx-xxx-prd-vm03",
  [...]

This happens because:

$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 37 Mar 23 10:47 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf
$ cat /run/systemd/resolve/stub-resolv.conf
# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search .

Commenting out the search entry fixes the issue. This happens because this machine is configured without a domain, but with a search path, leading to this being executed:
https://github.com/puppetlabs/facter/blame/7bfd75b1c76bb5d531c35131b717fb0697a54426/lib/facter/resolvers/linux/hostname.rb#L101-L103

And then a wrong concatenation:
https://github.com/puppetlabs/facter/blame/7bfd75b1c76bb5d531c35131b717fb0697a54426/lib/facter/resolvers/linux/hostname.rb#L110

Expected Behavior

facter should not read search in the first place. search is a client lookup option, and it is not intended to set the machine's hostname.

Steps to Reproduce

See resolv.conf configuration above. Make sure the machine has no domain configured.

Environment

# /opt/puppetlabs/bin/facter --version
4.6.1
 # uname -a
Linux xxx-xxx-prd-vm03 5.10.0-22-amd64 #1 SMP Debian 5.10.178-3 (2023-04-22) x86_64 GNU/Linux

Additional Context

Introduced in: #2296
CC @oanatmaria : I know it's been a while since you've made this contribution, but I couldn't find the reason that facter is reading search. Could you shed some light on this ?
EDIT: Tracking the git history seems to point to it being there since a long time, e.g. 0599a60

Use Case

As various vendors begin setting target micro architectures for their products, it is becoming more important to know what CPU microarch or extensions your processor supports.

Describe the Solution You Would Like

For x86_64 systems a fact listing what micro architectures the system supports.
For aarch64 systems a fact listing what CPU extensions the system supports.

Ideally this would be some sort of array with a consistent name so I don't need to build complex if/else paths based on aarch64 vs x86_64 to check for a feature.

Describe Alternatives You've Considered

Building my own module to parse this out.

Additional Context

https://discourse.ubuntu.com/t/trying-out-ubuntu-23-04-on-x86-64-v3-rebuild-for-yourself/40963
https://developers.redhat.com/articles/2024/01/02/exploring-x86-64-v3-red-hat-enterprise-linux-10
https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels
https://en.wikipedia.org/wiki/AArch64#ARMv8.x_and_ARMv9.x_extensions_and_features