| I am using some lesser known distro derivatives of ubuntu and running into issues with how some of the core facts parse os information. Several modules don’t work when puppet installs packages since the distro codename is used instead of the upstream codename. As an example the docker and puppet-agent fail to download packages because those modules rely on the apt module which configures an apt source with a codename that is only useful for the distro maintainer. I think we should be referencing UBUNTU_CODENAME instead if available.
This ends up creating errors during package installation because the apt source is pointing to a package that does not exist and never will.
Error: Could not update: Execution of '/usr/bin/apt-get -q -y -o DPkg::Options::=--force-confold --force-yes install puppet-agent=6.21.1-1pisces' returned 100: Reading package lists... |
Building dependency tree... |
Reading state information... |
W: --force-yes is deprecated, use one of the options starting with --allow instead. |
E: Version '6.21.1-1pisces' for 'puppet-agent' was not found |
Error: /Stage[main]/Puppet_agent::Install/Package[puppet-agent]/ensure: change from '6.21.1-1bionic' to '6.21.1-1pisces' failed: Could not update: Execution of '/usr/bin/apt-get -q -y -o DPkg::Options::=--force-confold --force-yes install puppet-agent=6.21.1-1pisces' returned 100: Reading package lists... |
Building dependency tree... |
Reading state information... |
W: --force-yes is deprecated, use one of the options starting with --allow instead. |
E: Version '6.21.1-1pisces' for 'puppet-agent' was not found
|
This of course fails puppet and the node is unable to run. The problem is facter is deriving the codename from the lsb-release file which should be reserved for lsbdistro facts only and not merged into the os.distro fact. The codename should be bionic IMHO since that is what is found in /etc/os-release. This OS is a specialized distro for crypto mining purposes and there are dozens others just like it. I do not think making one off exceptions for all them is feasible. Instead supporting this pattern is a better approach when there is a upstream distro that it follows. LinuxMint is the same way, but facter already has exceptions I believe.
1:>> $os |
=> { |
"architecture" => "amd64", |
"distro" => { |
"codename" => "pisces", |
"description" => "MMP 2.8.20 stable", |
"id" => "MMP", |
"release" => { |
"full" => "2.8.20", |
"major" => "2.8", |
"minor" => "20" |
} |
}, |
"family" => "Debian", |
"hardware" => "x86_64", |
"name" => "Ubuntu", |
"release" => { |
"full" => "18.04", |
"major" => "18.04" |
}, |
"selinux" => { |
"enabled" => false |
} |
} |
|
3:>> $::lsbdistcodename |
=> "pisces" |
4:>> $::lsbdistdescription |
=> "MMP 2.8.20 stable" |
5:>> $::lsbdistid |
=> "MMP" |
6:>> $::lsbdistrelease |
=> "2.8.20" |
7:>> $::lsbmajdistrelease |
=> "2.8" |
8:>> $::lsbminordistrelease |
=> "20"
|
I have not confirmed facter 4 has this issue, but facter 3 does. The workaround for me is
ini_setting{'DISTRIB_CODENAME': |
ensure => present, |
path => '/etc/lsb-release', |
value => 'bionic', |
setting => 'DISTRIB_CODENAME', |
before => Stage[main] |
}
|
|
