Problem:
Here’s a picture of the issue:
After successfully kickstarting a new host, I tried to register it as a content host and found that the registration process changed the “Build:” status from “Installed” to “Pending Installation”
I spent some time looking at what happens when you run the registration script, i.e the one that is generated via “Hosts > Register Host” in the GUI.
Here is what I found: (Followed by a poor workaround I would like to improve)
So I generate my registration script, looks something like this
btw, I’m unconcerned about these credentials this is a lab
curl -sS 'https://lab0l25.virtual.home.arpa:9090/register?activation_keys=CentOS8&lifecycle_environment_id=2&location_id=2&operatingsystem_id=2&organization_id=1&update_packages=false' -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjo0LCJpYXQiOjE2MzE3NzQ5OTksImp0aSI6Ijc5OWYyYjYwZGFlMDk2YmM1ODMxOGM5MDYwZDI4Zjc4MjkxYWQ5N2I2NzUzYjI4OWYyNmE4NWFjZTBhMGM2NGUiLCJleHAiOjE2MzE3ODkzOTksInNjb3BlIjoicmVnaXN0cmF0aW9uI2dsb2JhbCByZWdpc3RyYXRpb24jaG9zdCJ9.0O1fyi0YWzLCz4yiRGmDqePTx9tBpPWxjA60aWSz-Ro' | bash
I run the above on the host that I’m registering as a content host.
At the point in the script that this function:
register_katello_host(){
UUID=$(subscription-manager identity | head -1 | awk '{print $3}')
curl --silent --show-error --cacert $SSL_CA_CERT --request POST "https://lab0l25.virtual.home.arpa:9090/register" \
--data "uuid=$UUID" \
-H 'Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjo0LCJpYXQiOjE2MzE3NDgyNDgsImp0aSI6IjFmNWNkMDBhZGVjZjFkNWY1NDQwYTEwZDZkMjY2ZTE2NGYzMDAwNDc3NDVhOWFlMTk0YzM4Nzk0ZjYxMDI1ZDUiLCJleHAiOjE2MzE3NjI2NDgsInNjb3BlIjoicmVnaXN0cmF0aW9uI2dsb2JhbCByZWdpc3RyYXRpb24jaG9zdCJ9._up0suoZrVH0n2MYRl4o55lAdAxcx3c93GVpS4-gvSg' \
--data 'host[organization_id]=1' \
--data 'host[location_id]=2' \
--data 'host[lifecycle_environment_id]=2' \
--data 'update_packages=false' \
}
Is piped into bash here:
register_katello_host | bash
The build status changes from “Installed” to “Pending Installation”
Which should be fine, as long as it gets set back.
Well, unfortunately it doesn’t
This function:
foreman_curl() {
curl --silent --show-error --cacert $SSL_CA_CERT -o /dev/null --noproxy \* "$@"
}
Is called here:
foreman_curl 'https://lab0l25.virtual.home.arpa:9090/unattended/built?token=467dfb68-aef9-4ef3-8ec1-25ae5de19e24'
But the problem is the API that is listening on port 9090 doesn’t handle /unattended/built?token=xxx
It instead just responds with:
Requested url was not found
If i clone/modify the “Linux host_init_config default” template:
From:
foreman_curl '<%= foreman_url('built') %>'
To:
foreman_curl '<%= foreman_server_url %>/unattended/built?token=<%= @host.token %>'
This fixes the issue because it is no longer using port 9090 and instead uses port 443
I’m guessing the reason <%= foreman_url(‘built’) %>’ returns a URL with 9090 is related to the fact that that the curl that initially changed the build status from installed to pending was pointed at port 9090, but i don’t really know.
curl --silent --show-error --cacert $SSL_CA_CERT --request POST "https://lab0l25.virtual.home.arpa:9090/register" \
ok, on to my second issue.
At the same time the build status was changed from installed to pending, the Subscription Status changed from “Fully Entitled” to “Unkown Subsctiption Status”
In the “Linux host_init_config default” I see where it’s trying to do something with the subscription status
echo "Refreshing subscription data"
subscription-manager refresh
This does run without errors but it doesn’t fix the Subscription status
I ended up going with a drastic solution and adding this to the “Linux host_init_config default”
echo "Resetting Activation Key"
organizationid=$(subscription-manager identity | grep "^org ID:")
organizationid="${organizationid#org ID: }"
organizationid=$(echo "$organizationid" | awk '{ sub(/^[ \t]+/, ""); print }')
activationkey=$(subscription-manager list --consumed | grep "^Subscription Name:")
activationkey="${activationkey#Subscription Name:}"
activationkey=$(echo "$activationkey" | awk '{ sub(/^[ \t]+/, ""); print }')
subscription-manager register --force --org="$organizationid" --activationkey="$activationkey"
This fixed the “Unkown Subsctiption Status” and coupled with the other fix, all my immediate problems were solved.
That being said, are these bugs?
Should port 9090 be able to accept /unattended/built?
Is there a better way to resolve Foreman seeing the status of my content hosts as “Unkown Subsctiption Status”
Disclaimer: This hacks were suited for my lab, this is not advice to run these fixes in a production environment.
Expected outcome:
I expected the content host registration to not leave my Content Host with a build status of “Pending Installation”
I expected the content host registration to not leave my Content Hist with a subscription status of “Unknown Subscription Status”
Foreman and Proxy versions:
katello-4.2.0.rc1-1.el8.noarch
foreman-3.0.0-1.el8.noarch
Foreman and Proxy plugin versions:
Default install, no extra plugins
foreman-installer --scenario katello --foreman-proxy-tftp true --foreman-proxy-dhcp true --foreman-proxy-dhcp-nameservers 192.168.122.1
Distribution and version:
Foreman Host: CentOS Linux release 8.4.2105
Content Host: CentOS Linux release 8.4.2105
Other relevant data:
