Bug 1351766
| Summary: | Can't access inherited parameters from host | ||
|---|---|---|---|
| Product: | Red Hat Satellite | Reporter: | Fabian von Feilitzsch <fabian> |
| Component: | Users & Roles | Assignee: | orabin |
| Status: | CLOSED ERRATA | QA Contact: | Peter Ondrejka <pondrejk> |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.2.0 | CC: | bbuckingham, bkearney, cwelton, ehelms, fabian, inecas, jcallaha, jkim, jmatthew, jmontleo, orabin, riehecky |
| Target Milestone: | Unspecified | Keywords: | Triaged |
| Target Release: | Unused | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| 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: | |||
| Bug Depends On: | 1296662 | ||
| Bug Blocks: | 1212602 | ||
|
Description
Fabian von Feilitzsch
2016-06-30 18:50:19 UTC
I did some additional looking, it seems that if I set User.current in the console to one of the admin users I am able to view the host parameters, however the generated kickstart still does not get access to them. Is it possible that if the kickstart is fetched by an API call that User.current would not be set? This seems to actually break builds where the host inherits an activation key from the hostgroup completely, outside of the Quickstart Cloud Installer plugin. If I set an activation key in the hostgroup parameters, add that hostgroup to a host, and then trigger a build, this check in the kickstart template is false, and the host is not registered to Satellite:
<% if @host.params['kt_activation_keys'] %>
I have verified that host.params['kt_activation_keys'] is present on the command line with the user set to any of the users in the database. I have tried setting the User manually on the QCI side, but it doesn't seem to carry over to whatever Foreman does when it triggers the build and tries to access host.params.
I can't think of another way to work around it on the QCI side, and it breaks all QCI deployments. I have gotten my team pinned one commit behind, and we will not be able to update until this issue is fixed or a workaround is found.
Ori, Will this commit fix the issue described in the BZ? https://github.com/theforeman/foreman/pull/3624 As per BZ 1296662 No, it shouldn't be related. The issue here seems to be a user that is missing the view_params permission but it's not clear which user. The user that can reproduce the steps from comment 1 - can that role be checked out to make sure it has view_params? So the request that is getting the provisioning template is being processed by the UnattendedController, which doesn't seem to set a User. I debugged a bit and saw that when the kickstart is requested, inside the host.params method User.current is nil. I added the line "set_admin_user" to the UnattendedController.host_template method, before render_template is called. This made the provisioning work as expected. I also tried adding view_params to every Role in the database, it had no effect, the kickstart still did not render correctly, which makes sense since it seems there was no set User for the unattended routes. For the record - as discussed on irc, the steps to reproduce without the kickstart are also reproducible only when User.current is nil. Since there is no user changing the roles won't help. Created redmine issue http://projects.theforeman.org/issues/15599 from this bug Upstream bug assigned to orabin Upstream bug component is Users & Roles Upstream bug assigned to orabin Moving to POST since upstream bug http://projects.theforeman.org/issues/15599 has been closed Moving to POST since upstream bug http://projects.theforeman.org/issues/15599 has been closed Verified in satellite-6.3.0-21.0.beta.el7sat.noarch Host group parameters are correctly inherited when discovered host is provisioned with the set hostgroup, also when a hostgroup is changed afterwards new parameters are inherited Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2018:0336 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2018:0336 |