Description of problem: Satellite 6 offers four possibilities to register a new host: * Preconfigure host in Foreman * Using `bootstrap.py` * Using subscription-manager * Facts upload with pulp While preconfiguring hosts and bootstrap.py results in identical configuratilon, subscription-manager and puppet gives different users experience. This BZ addresses subscription-manager Version-Release number of selected component (if applicable): Satellite 6.2.12 How reproducible: always Steps to Reproduce: 1. Download https://sat6.example.net/pub/katello-ca-consumer-latest.noarch.rpm 2. subscription-manager register --org=myOrg --name=`hostname -f` --activationkey=myKey --force Actual results: Without example.com in the list of known domains: -> Host is named "server.example.com", primary interface is named "server.example.com", domain of primary interface is blank. With example.com in the list of known domains: -> Host is named "server.example.com", primary interface is named "server", domain is "example.com". Expected results: Host is named as FQDN (Foreman standard), the name of the primary interface is the shortname and the domain set to the host's domain. In case the domain doesn't exist, create an error. This would be consistent to the WebUI and bootstrap.py. Additional info: While bootstrap.py was created to circumvent all issues in the registration through subscription-manager, it's need for a Satellite user login and password is a blocker for enterprise customers.
That subscription-manager create the foreman host is implicity done. There is no way to disable this to force the new bootstrap.py. If bootstrap.py is the way forward then all other implicit host creations must fail. Better give an error than do something that creates incorrect configuraiton. For me as a customer this would help me a lot to make sure i am only using processes that are really working.
Hi Beat, Thanks for the well written bugzilla. Would this be a duplicate of bug 1344011 or bug 1376808? It appears that the --name is not being honored. Thanks!
Brad, thanks for the pointers. bz1376808 looks good and describes the behavior I saw by reproducing the issue. The customer uses katello.facts to override the hostname as the application (SAP) insists on shortnames: [root@brownie ~]# hostname brownie [root@brownie ~]# cat /etc/rhsm/facts/katello.facts {"network.hostname-override":"brownie.example.com"} I'll close this BZ. *** This bug has been marked as a duplicate of bug 1376808 ***