Hi Marek, Actually that's the confusion, please clarify the following Q#1. Currently in facts upload API regular user authentication takes place or not? Q#2 If answer to q#1 is no, I am able to authenticate regular user Q#3 If answer to q#1 is yes, then does it always need admin to fire this api or any other user with 'upload_facts' permission can fire this. Q#4 If any user with 'upload_facts' permission can fire the facts upload API, why the behaviour is different for admin and non-admin user?
Q#1. Currently in facts upload API regular user authentication takes place or not? yes Q#2 If answer to q#1 is no, I am able to authenticate regular user that's correct Q#3 If answer to q#1 is yes, then does it always need admin to fire this api or any other user with 'upload_facts' permission can fire this. any user can fire this API, he/she needs upload_facts to start the action Q#4 If any user with 'upload_facts' permission can fire the facts upload API, why the behaviour is different for admin and non-admin user? Because when domain does not exist, we try to create it but we don't know into which Organization and Location we should assign the newly created domain. Since the user is not admin, he/she can't create the resource without specifying Orgs and Locs. It fails silently. The related code is at https://github.com/theforeman/foreman/blob/1285cc0d7d0c94a75dd8c7b78a21453a008ab340/app/services/puppet_fact_parser.rb#L87 Note that this is not specific to Domain but any taxable resource we create from facts. Maybe we could set the Org and Loc of new objects based on "Default organization" and "Default location" settings. The user under which the API is fired would need to be assigned to these. Also note that the setting is global for all organizations within Satellite, so we should first with customer that this is acceptable. Other possible solution is to assign all user's Orgs and Locs. Or just keep it the way it is now but just start logging the error (good idea anyway).
Just a comment to expand on the facts upload API authentication, as per the last of your message. It is not as simple as just 'regular user/pw authentication'. The facts upload API can be triggered through regular authentication or smart_proxy authentication. Smart proxies are NOT users but they're able to upload facts (and domains etc.. get created). Same goes for subscription-manager. Now, how do smart proxies do this? Go to Administer > Settings, tab 'Authentication'. Notice the 'trusted puppetmaster hosts' setting. You can add ANY fqdn or IP in there, as an array of values. Any requests to POST api/v2/hosts/facts will bypass regular authentication if they come from these hosts. What happens with locations & organizations? There is another setting, tab 'Puppet'. Notice 'organization_fact' and 'location_fact'. Any host that is created via the facts API will be put in the organization and location that come from these facts (or none, if not set). It will save as hosts created via the facts API don't validate the inputs. However, domains, etc.. if they're new and created via facts, they would NOT be placed automatically into the host organization/location. I would call that a bug (for new domains, it should set it into the host org/loc, and for existing ones, leave it as is (this is what Satellite calls a org/loc mismatch)) As far as I can tell, the customer could add the host that pretends to make these calls to trusted_puppetmaster_hosts. The customer should also set a 'organization_fact' and 'location_fact' and make sure the JSON they send contain these facts. That way domains/arch/os, etc.. get created, the host gets created in the right location/organization, and there are no user credentials needed as Satellite trusts the host. Let us know if this is what the customer wanted, as what I describe is feasible with 6.2
I'm the customer who opened the originating case (01744905) for these issues. I give you the full context of these issues. See the following comment on the related bug: https://bugzilla.redhat.com/show_bug.cgi?id=1399619#c8 Currently we can work with the behaviour. Once the domain is explicitly saved correctly, it works as expected. If there are problems we will add the proxy that uploads the reports and facts to trusted puppetmaster hosts.
Hello Phillipp, thanks for you reactions. Would the solution that Daniel described in comment 4 worked for you? The fix we'd need to provide would be to assign the domain to what's reported for host's org/loc if it's new domain (unknown to Satellite). The same would apply for what I described in comment 3 (Default organization and Default location settings) if no custom fact would be provided for such host. That should remove the burden that you need to save the domain manually after initial facts import.
For now I can work with the current behaviour, we don't have a lot of domains. Once the domain is registered properly it works as desired. The domains are more static than the sources. If it would become a problem I would get back to the suggested workaround with trusted_puppetmaster
Thank you for your interest in Satellite 6. We have evaluated this request, and we do not expect this to be implemented in the product in the foreseeable future. We are therefore closing this out as WONTFIX. If you have any concerns about this, please feel free to contact Rich Jerrido or Bryan Kearney. Thank you.