I use 2 scripts - one fixes the default issue and one creates the InRelease and release.gpg
I have a 1.24 foreman that the deb subscription works perfectly. Its a bit frustrating that this doesn’t. I’ll find the links I used and post them
finally all working Thanks everyone.
You need to install the apt-transport-katello-package on the host, otherwise apt will not know what to do with the katello://-URLs.
Please also make sure that katello-upload-profile is installed, so the installed deb-packages are reported back to katello.
Apperently there were not installed. I installed them and run a new ‘apt update’
For some reason it wants to use i386
Reading package lists… Done
Building dependency tree
Reading state information… Done
All packages are up to date.
N: Skipping acquire of configured file ‘all/binary-i386/Packages’ as repository ‘katello://foreman-z01.infra.zgt.local/pulp/deb/ICT-ZGT/acceptatie/CV_Ubuntu-18/custom/Ubuntu/Ubuntu_Subscription-manager default InRelease’ doesn’t support architecture ‘i386’
N: Skipping acquire of configured file ‘all/binary-i386/Packages’ as repository ‘katello://foreman-z01.infra.zgt.local/pulp/deb/ICT-ZGT/acceptatie/CV_Ubuntu-18/custom/Ubuntu/Ubuntu_18_04_Security_amd64 default InRelease’ doesn’t support architecture ‘i386’
N: Skipping acquire of configured file ‘all/binary-i386/Packages’ as repository ‘katello://foreman-z01.infra.zgt.local/pulp/deb/ICT-ZGT/acceptatie/CV_Ubuntu-18/custom/Ubuntu/Ubuntu_18_04_Updates_amd64 default InRelease’ doesn’t support architecture ‘i386’
N: Skipping acquire of configured file ‘all/binary-i386/Packages’ as repository ‘katello://foreman-z01.infra.zgt.local/pulp/deb/ICT-ZGT/acceptatie/CV_Ubuntu-18/custom/Ubuntu/Ubuntu_18_04_amd64 default InRelease’ doesn’t support architecture ‘i386’
Yes, this is an issue with Ubuntu we are still working on. amd64-packages should work, though.
So you should be fine ignoring these messages for now 
.
The problem here is that Ubuntu automatically expects to find amd64 as well as i386 packages in a repository, if no architecture is explicitly specified. Unfortunately, the subscription-manager and katello do not exchange the available architectures within the repository right now.
Ah ok, now I loook beter it is just a warning.
Then I think I’m up and running
Thank you all for your help.
If I need any assistant I know where to find it
regards
Jurgen
This is a section from our preseed that fixes this
dpkg --remove-architecture i386
subscription-manager repos > /dev/null
subscription-manager refresh >/dev/null
yes I looked into this problem in our lab about 6 months ago and passing the available architecture in katello is quite a complex change. I like the “publish_default_release” in deb_distributor.json it stops having to fix the rhsm.sources by script.
As I said, we are working on this to get the full story done:
- host tells candlepin via sub-man which archs are supported
- katello tells candlepin which archs are supported for a repo
- candlepin only provides repos a host does support
- sub-man writes debian repository file including supported arch
See https://github.com/candlepin/subscription-manager/pull/2213
Nice, that makes the output somewhat cleaner.
I will add this to the ubuntu_register snippet in foreman. (which I included in the preseed_finish.)
Hello.
I ran into issues after installation gnome desktop.
The package-profile-upload failed:
root@research-deploy:/etc/apt# /usr/bin/package-profile-upload
Traceback (most recent call last):
File "/usr/bin/package-profile-upload", line 11, in <module>
load_entry_point('subscription-manager==1.25.1', 'console_scripts', 'package-profile-upload')()
File "/usr/lib/python2.7/dist-packages/subscription_manager/scripts/package_profile_upload.py", line 42, in main
report = command.perform(force_upload=args.force_upload)
File "/usr/lib/python2.7/dist-packages/subscription_manager/packageprofilelib.py", line 42, in perform
ret = profile_mgr.update_check(self.uep, consumer_identity.uuid, force=force_upload)
File "/usr/lib/python2.7/dist-packages/subscription_manager/cache.py", line 439, in update_check
if not uep.supports_resource(PACKAGES_RESOURCE):
File "/usr/lib/python2.7/dist-packages/rhsm/connection.py", line 950, in supports_resource
self._load_supported_resources()
File "/usr/lib/python2.7/dist-packages/rhsm/connection.py", line 937, in _load_supported_resources
resources_list = self.conn.request_get("/")
File "/usr/lib/python2.7/dist-packages/rhsm/connection.py", line 746, in request_get
return self._request("GET", method, headers=headers)
File "/usr/lib/python2.7/dist-packages/rhsm/connection.py", line 772, in _request
info=info, headers=headers)
File "/usr/lib/python2.7/dist-packages/rhsm/connection.py", line 603, in _request
conn.request(request_type, handler, body=body, headers=final_headers)
File "/usr/lib/python2.7/httplib.py", line 1099, in request
self._send_request(method, url, body, headers)
File "/usr/lib/python2.7/httplib.py", line 1139, in _send_request
self.endheaders(body)
File "/usr/lib/python2.7/httplib.py", line 1095, in endheaders
self._send_output(message_body)
File "/usr/lib/python2.7/httplib.py", line 898, in _send_output
self.send(msg)
File "/usr/lib/python2.7/httplib.py", line 860, in send
self.connect()
File "/usr/lib/python2.7/httplib.py", line 1312, in connect
HTTPConnection.connect(self)
File "/usr/lib/python2.7/httplib.py", line 837, in connect
self.timeout, self.source_address)
File "/usr/lib/python2.7/socket.py", line 557, in create_connection
for res in getaddrinfo(host, port, 0, SOCK_STREAM):
socket.gaierror: [Errno -2] Name or service not knownThis would mean that the server cannot be reached. Can you still ping the foreman-/katello-server?
Maybe something with the name-resolution is broken, though I am not sure how installing gnome would trigger this 
I can still ping the foreman server and also no issues with the name resolution.
wait, I can ping the server with the hostname, but not with FQDN!!
This happens all after the installation of ‘gnome-session’
root@research-deploy:~# nslookup foreman-z01
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: foreman-z01.infra.zgt.local
Address: 10.40.30.158
root@research-deploy:~# nslookup foreman-z01.infra.zgt.local
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: foreman-z01.infra.zgt.local
Address: 10.40.30.158
root@research-deploy:~# nslookup 10.40.30.158
158.30.40.10.in-addr.arpa name = foreman-z01.infra.zgt.local.
Authoritative answers can be found from:
root@research-deploy:~# ping -c 5 foreman-z01.infra.zgt.local
ping: foreman-z01.infra.zgt.local: Name or service not known
root@research-deploy:~# ping -c 5 foreman-z01
PING foreman-z01.infra.zgt.local (10.40.30.158) 56(84) bytes of data.
64 bytes from foreman-z01.infra.zgt.local (10.40.30.158): icmp_seq=1 ttl=62 time=0.681 ms
64 bytes from foreman-z01.infra.zgt.local (10.40.30.158): icmp_seq=2 ttl=62 time=0.699 ms
64 bytes from foreman-z01.infra.zgt.local (10.40.30.158): icmp_seq=3 ttl=62 time=0.693 ms
issue found in de nsswitch.conf
It changes the hosts entry.
hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname
after changing it to
hosts: file dns myhostname
it works again.
regards
Jurgen
1 Like
The issue is caused by our domain name, which end with .local
I found this:
Your company uses a DNS domain ending with .local , which is actually a special-purpose suffix and is reserved by IETF for Multicast DNS. So because you have a mDNS client installed (mdns4_minimal), it gets configured for priority handling of all *.local names.
I am having a similar issue, but with CentOS 8. I have seven repositories, three of which are CentOS 8:
- PowerTools
- AppStream
- BaseOS
When I run subscription-manager repos --list, only the BaseOS repo is missing. I have validated the repo is syncing, has content, is published in the Content View, and that the Content Host has access to said repo. In checking the repository configurations, I noticed they all have “Architecture: Default”.
However, when analyzing the JSON returned by wget --certificate=/etc/pki/consumer/cert.pem --private-key=/etc/pki/consumer/key.pem https://foreman.mydomain.com/rhsm/consumers/d2579e09-f65c-4c26-9573-a41b665bc599, I noticed that the BaseOS repo has arches : x86_64 in the array. The six repos that are showing as available via subscription-manager have arches : null in their arrays.
I have tried to set and reset the Architecture setting for the repos, but it doesn’t appear to have any effect and the issue remains that BaseOS is unavailable.
As such, is this the same bug, but for CentOS?
Thanks!
I’m not sure if this is related, but the entitlement certificate that subscription-manager doesn’t appear to have the BaseOS repo listed.
It would appear something is not right in how data is being provided to subscription-manager.
# rct cat-cert /etc/pki/entitlement/3288316626973312046.pem
+-------------------------------------------+
Entitlement Certificate
+-------------------------------------------+
Certificate:
Path: /etc/pki/entitlement/3288316626973312046.pem
Version: 3.4
Serial: 3288316626973312046
Start Date: 2020-10-21 14:54:49+00:00
End Date: 2049-12-01 00:00:00+00:00
Pool ID: 8a9084ac754b9a7a01754ba7cceb0003
Subject:
CN: 2d28efe990c4448094f80eeca504fa84
O: My_Awesome_Org
Issuer:
C: US
CN: foreman-client.mydomain.com
L: My City
O: My Awesome Org
OU: Infrastructure
ST: My State
Product:
ID: 927803325001
Name: CentOS
Version:
Arch: ALL
Tags:
Brand Type:
Brand Name:
Order:
Name: CentOS
Number:
SKU: 927803325001
Contract:
Account:
Service Type:
Roles:
Service Level:
Usage:
Add-ons:
Quantity: Unlimited
Quantity Used: 1
Socket Limit:
RAM Limit:
Core Limit:
Virt Only: False
Stacking ID:
Warning Period: 0
Provides Management: False
Authorized Content URLs:
/My_Awesome_Org/CentOS_8_Virtual_Servers/CentOS_8_Virtual_Servers/custom/CentOS/8_-_AppStream
/My_Awesome_Org/CentOS_8_Virtual_Servers/CentOS_8_Virtual_Servers/custom/CentOS/8_-_PowerTools
Content:
Type: yum
Name: 8 - AppStream
Label: My_Awesome_Org_CentOS_8_-_AppStream
Vendor: Custom
URL: /My_Awesome_Org/CentOS_8_Virtual_Servers/CentOS_8_Virtual_Servers/custom/CentOS/8_-_AppStream
GPG: ../../katello/api/v2/repositories/3/gpg_key_content
Enabled: True
Expires: 1
Required Tags:
Arches: ALL
Content:
Type: yum
Name: 8 - PowerTools
Label: My_Awesome_Org_CentOS_8_-_PowerTools
Vendor: Custom
URL: /My_Awesome_Org/CentOS_8_Virtual_Servers/CentOS_8_Virtual_Servers/custom/CentOS/8_-_PowerTools
GPG: ../../katello/api/v2/repositories/5/gpg_key_content
Enabled: True
Expires: 1
Required Tags:
Arches: ALL
Again, I’ve verified the Activate Key, Lifecycle Environment, and Content View are all properly configured. I’ve verified the Content Host shows in Foreman as having access to the BaseOS repo. However, subscription-manager and the data it receives from the /rhsm endpoint on the Foreman host are reporting different.
Thanks in advance for any assistance you can provide.
It might be that something in your configuration is still incorrect.
Have you already tried a subscription-manager refresh to get new certificates?
The architectures-problem however does not affect rpm-repositories, so this should be a different topic.
So I would kindly ask you to open a separate thread for your issue.
@m-bucher Thanks for the response.
Yes, I’ve tried subscription-manager refresh and re-registering the Content Host (unregister, clean, then register), including deleting all data for the Content Host in-between each re-registration dance. I ran into this problem with 1.24 and my Content Hosts (CentOS and RHEL 7+8) and it was suggested that I upgrade. So I setup a new Foreman host running 2.1 and the issue appears to persist. I’m not sure what I’m doing wrong as I didn’t have this problem with previous versions of Foreman.
I will start a new thread like you suggested. Apologies if I bumped a dead thread or presented an issue out-of-context.
Thanks!
are you still having this problem? I have checked my centos 7 and 8 and they are OK with all repos. Using 2.1