Bug 1910072

Summary: katello-rhsm-consumer doesn't change /etc/rhsm/facts/katello.facts
Product: Red Hat Satellite Reporter: Taft Sanders <tasander>
Component: RegistrationAssignee: satellite6-bugs <satellite6-bugs>
Status: NEW --- QA Contact: Satellite QE Team <sat-qe-bz-list>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.8.0CC: ahumbe, ehelms, lstejska, zhunting
Target Milestone: UnspecifiedKeywords: Patch, Triaged
Target Release: Unused   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Taft Sanders 2020-12-22 14:38:04 UTC
Description of problem:
VM templating a registered system often creates the problem of templated systems registering with the wrong hostname and unregistering previously registered hostnames. Instead of specifying a condition for setting the network.hostname-override variable in the /etc/rhsm/facts/katello.facts file, why not set it consistently?

Version-Release number of selected component (if applicable):
subscription-manager-1.24.42-1.el7.x86_64
kernel-3.10.0-1062.12.1.el7.x86_64
satellite-6.8.1-1.el7sat.noarch

How reproducible:
Every time

Steps to Reproduce:
1. Register a system fitting the criteria to create the katello.facts hostname override value:
(test -f /etc/redhat-release && grep -q -i "Red Hat Enterprise Linux Server release 5" /etc/redhat-release) || \ (test -f /etc/centos-release && grep -q -i "CentOS Linux release 5" /etc/centos-release) || \  test ${RHSM_VERSION[0]:-0} -lt 1 -o ${RHSM_VERSION[1]:-0} -lt 18 -o \( ${RHSM_VERSION[1]:-0} -eq 18 -a ${RHSM_VERSION[2]:-0} -lt 2 \);

2. Template the registered system and build new systems off this template. Change the hostname on the new system via hostnamectl, cloud.init, etc

3. Register system to the same Satellite and watch the templated VM get unregistered

Actual results:
network.hostname-override fact is only being updated if it fits the above criteria. This criteria appears to be meant for RHEL 5 systems explicitly according to the comment in the code:
# EL5 systems and subscription-manager versions before 1.18.1-1 don't have the network.fqdn fact.
# For these cases, we have to update the "hostname-override" fact

network.hostname-override fact never gets updated, and new systems using the templated system unregister each other.

Expected results:
Let the network.hostname-override fact be updated with the correct hostname regardless of the version upon running the katello-rhsm-consumer script. Something like:

# if (test -f /etc/redhat-release && grep -q -i "Red Hat Enterprise Linux Server release 5" /etc/redhat-release) || \
#   (test -f /etc/centos-release && grep -q -i "CentOS Linux release 5" /etc/centos-release) || \
#   test ${RHSM_VERSION[0]:-0} -lt 1 -o ${RHSM_VERSION[1]:-0} -lt 18 -o \( ${RHSM_VERSION[1]:-0} -eq 18 -a #${RHSM_VERSION[2]:-0} -lt 2 \); then
FQDN="$(hostname -f 2>/dev/null || echo localhost)"
if [ "$FQDN" != "localhost" ] && [ -d /etc/rhsm/facts/ ]; then
  echo "{\"network.hostname-override\":\"$FQDN\"}" > /etc/rhsm/facts/katello.facts
fi
#fi

Additional info:
This is primarily a bug because the expression below does not evaluate as it should be intended:
# bash -x /usr/bin/katello-rhsm-consumer 
+ set -e
+ read -r -d '' KATELLO_DEFAULT_CA_DATA
+ true
+ read -r -d '' KATELLO_SERVER_CA_DATA
+ true
+ KATELLO_SERVER=satellite.zircon.local
+ KATELLO_SERVER_CA_CERT=katello-server-ca.pem
+ KATELLO_DEFAULT_CA_CERT=katello-default-ca.pem
+ KATELLO_CERT_DIR=/etc/rhsm/ca
+ PORT=443
+ PREFIX=/rhsm
+ CFG=/etc/rhsm/rhsm.conf
+ CFG_BACKUP=/etc/rhsm/rhsm.conf.kat-backup
+ CA_TRUST_ANCHORS=/etc/pki/ca-trust/source/anchors
+ test -f /etc/rhsm/rhsm.conf
+ type -P subscription-manager
+ test -f /etc/rhsm/rhsm.conf.kat-backup
+ echo 'Certificate:
--snip--
+ chmod 644 /etc/rhsm/ca/katello-server-ca.pem
+ echo 'Certificate:
--snip--
+ chmod 644 /etc/rhsm/ca/katello-default-ca.pem
+ '[' -n '' ']'
+ '[' -e /run/ostree-booted ']'
+ is_debian
+ '[' -r /etc/os-release ']'
++ sed -n -e 's/^ID\s*=\s*\(.*\)/\1/p' /etc/os-release
+ ID='"rhel"'
++ sed -n -e 's/^ID_LIKE\s*=\s*\(.*\)/\1/p' /etc/os-release
+ ID_LIKE='"fedora"'
+ '[' '"rhel"' = debian ']'
+ '[' '"fedora"' = debian ']'
+ '[' '"fedora"' = ubuntu ']'
+ return 1
+ BASEURL=https://satellite.zircon.local/pulp/repos
++ rpm -q '--queryformat=%{VERSION}' subscription-manager
++ tail -n1
++ tr . ' '
+ RHSM_V='1 24 42'
+ RHSM_VERSION=($RHSM_V) <<<< HERE
+ declare -a RHSM_VERSION<<<<< HERE
+ test 1 -gt 0 -o 24 -gt 96 -o '(' 24 -eq 96 -a 42 -gt 6 ')'
+ subscription-manager config --server.hostname=satellite.zircon.local --server.prefix=/rhsm --server.port=443 '--rhsm.repo_ca_cert=%(ca_cert_dir)skatello-server-ca.pem' --rhsm.baseurl=https://satellite.zircon.local/pulp/repos
+ subscription-manager config --rhsm.package_profile_on_trans=1
+ subscription-manager config --rhsm.report_package_profile=1
+ grep --quiet full_refresh_on_yum /etc/rhsm/rhsm.conf
+ sed -i 's/full_refresh_on_yum\s*=.*$/full_refresh_on_yum = 1/g' /etc/rhsm/rhsm.conf
+ '[' -d /etc/pki/ca-trust/source/anchors ']'
+ update-ca-trust enable
+ cp /etc/rhsm/ca/katello-server-ca.pem /etc/pki/ca-trust/source/anchors
+ update-ca-trust
+ '[' -f /usr/lib/systemd/system/docker.service ']'
+ '[' -f /etc/init.d/docker ']'
+ '[' -f /etc/init.d/goferd ']'
+ '[' -f /usr/lib/systemd/system/goferd.service ']'
+ test -f /etc/redhat-release
+ grep -q -i 'Red Hat Enterprise Linux Server release 5' /etc/redhat-release
+ test -f /etc/centos-release
+ test 1 -lt 1 -o 24 -lt 18 -o '(' 24 -eq 18 -a 42 -lt 2 ')'
+ exit 0

RHSM_V evaluates to '1 24 42'
RHSM_VERSION=($RHSM_V); declare -a RHSM_VERSION evaluates to '1'

Comment 1 Brad Buckingham 2021-01-04 15:34:23 UTC
Is this a regression in behavior?

Comment 2 Taft Sanders 2021-01-06 18:45:16 UTC
(In reply to Brad Buckingham from comment #1)
> Is this a regression in behavior?

Not that I'm aware of.

Comment 4 Eric Helms 2022-05-12 02:06:27 UTC
Moving this to registration as I think this should be handled by global registration going forward.

Comment 5 Brad Buckingham 2023-07-21 21:06:39 UTC
Upon review of our valid but aging backlog the Satellite Team has concluded that this Bugzilla does not meet the criteria for a resolution in the near term, and are planning to close in a month. This message may be a repeat of a previous update and the bug is again being considered to be closed. If you have any concerns about this, please contact your Red Hat Account team.  Thank you.