Description of problem: Users define with download_bootdisk permission is not able to download the host-specific boot iso image when it is generated. For generic boot disk the user is able to download the iso image. Version-Release number of selected component (if applicable): Product: Satellite Version 6.0.8 # yum list foreman* katello* Installed Packages foreman.noarch 1.6.0.53-1.el6sat @rhel-6-server-satellite-6.0-rpms foreman-compute.noarch 1.6.0.53-1.el6sat @rhel-6-server-satellite-6.0-rpms foreman-gce.noarch 1.6.0.53-1.el6sat @rhel-6-server-satellite-6.0-rpms foreman-libvirt.noarch 1.6.0.53-1.el6sat @rhel-6-server-satellite-6.0-rpms foreman-ovirt.noarch 1.6.0.53-1.el6sat @rhel-6-server-satellite-6.0-rpms foreman-postgresql.noarch 1.6.0.53-1.el6sat @rhel-6-server-satellite-6.0-rpms foreman-proxy.noarch 1.6.0.33-1.el6sat @rhel-6-server-satellite-6.0-rpms foreman-selinux.noarch 1.6.0.14-1.el6sat @rhel-6-server-satellite-6.0-rpms foreman-vmware.noarch 1.6.0.53-1.el6sat @rhel-6-server-satellite-6.0-rpms katello.noarch 1.5.0-30.el6sat @rhel-6-server-satellite-6.0-rpms katello-certs-tools.noarch 1.5.6-1.el6sat @rhel-6-server-satellite-6.0-rpms katello-default-ca.noarch 1.0-1 installed katello-installer.noarch 0.0.67-1.el6sat @rhel-6-server-satellite-6.0-rpms katello-server-ca.noarch 1.0-1 installed How reproducible: 1 of 1 attempt Steps to Reproduce: Option 1: 1. Add a new user 2. Create a role 3. Assign all permission to that role (or permission that allow the user to build/manage a host and download_bootdisk) 4. Assign the user to that role and uncheck the Administrator checkbox 5. Login with the user and build a host using kickstart provisioning 6. In the host user interface click the Boot disk button --> Host <hostname> image Option 2: 1. Go to Hosts --> New Host 2. Click existing host 3. In the host user interface click the Boot disk button --> Host <hostname> image Actual results: WebUI "Host not found. Please try to update your request" Foreman logs: Processing by HostsController#bootdisk_iso as HTML Parameters: {"id"=>"lnpnpriftest003v.int.asurion.com"} Rendered common/404.html.erb within layouts/application (2.2ms) Rendered home/_submenu.html.erb (6.5ms) Rendered home/_user_dropdown.html.erb (2.3ms) Read fragment views/tabs_and_title_records-10 (0.2ms) Rendered home/_topbar.html.erb (12.0ms) Rendered layouts/base.html.erb (14.0ms) Filter chain halted as :find_by_name_bootiso rendered or redirected Completed 404 Not Found in 93ms (Views: 19.6ms | ActiveRecord: 15.9ms) Expected results: User should be able to download the generated host-specific boot iso image Additional info: Note: in the backend the boot ISO is generated since we are able to download it by just copying the URL of the iso (not going through clicking on the Boot disk --> Host <hostname> image) using a user with Administrator role configured, this is after Option 1 steps.
Since this issue was entered in Red Hat Bugzilla, the release flag has been set to ? to ensure that it is properly evaluated for this release.
Since this issue was entered in Red Hat Bugzilla, the pm_ack has been set to + automatically for the next planned release
Btw for Option 2 steps to reproduce, please follow sequence 1-4 in Option 1 first before starting Option 2 steps. Thanks
Hello, in addition to the download_bootdisk permission, the user must be also allowed to read hosts (or particular host). Since permission dependency is not implemented, you need to manually add that permission. The missing permission is view_hosts. Can you re-test with this one please?
(In reply to Lukas Zapletal from comment #5) > Hello, > > in addition to the download_bootdisk permission, the user must be also > allowed to read hosts (or particular host). Since permission dependency is > not implemented, you need to manually add that permission. > > The missing permission is view_hosts. Can you re-test with this one please? This is the test that I did. 1. I've Assigned all default built-in roles to the user (Boot Disk Access, Manager, Site Manager, Edit Hosts, View Hosts etc.... ) - still not working 2. I have added all possible permission (manually added, basically I created a new role and add all permission to that role and assign the user to it) and the only thing left is that I did not check the Administrator check box. - still not working I will reproduce the issue and post the foreman logs, btw some additional information for this issue is that I'm using that user to provision a VM through network based provisioning, I will try the bare metal and see if I also encounter the issue.
Issue is same with bare metal provisioning. Also I see this error when viewing the provisioning template of the host using the same user: Steps: 1. Login with a non administrator user 2. Go to Hosts -> All hosts -> Edit a Host 3. At the host detail go to Templates and click the drop down then click Review In this example I was trying to access the a finish template (issue is same when accessing all templates) Foreman logs Processing by UnattendedController#finish as HTML Parameters: {"hostname"=>"lnpnpriftest003v.int.asurion.com"} Operation FAILED: There was no default layout for UnattendedController in #<ActionView::PathSet:0x007f35cd0415c8 @paths=[/usr/share/foreman/app/views, /opt/rh/ruby193/root/usr/share/gems/gems/katello-1.5.0/app/views, /opt/rh/ruby193/root/usr/share/gems/gems/katello-1.5.0/engines/bastion/app/views, /opt/rh/ruby193/root/usr/share/gems/gems/ui_alchemy-rails-1.0.12/app/views, /opt/rh/ruby193/root/usr/share/gems/gems/foreman-tasks-0.6.9/app/views, /opt/rh/ruby193/root/usr/share/gems/gems/foreman_bootdisk-2.0.6/app/views, /opt/rh/ruby193/root/usr/share/gems/gems/redhat_access-0.0.4/app/views, /opt/rh/ruby193/root/usr/share/gems/gems/foreman_discovery-1.3.0/app/views, /opt/rh/ruby193/root/usr/share/gems/gems/apipie-rails-0.2.5/app/views]> Completed 500 Internal Server Error in 151ms ArgumentError (There was no default layout for UnattendedController in #<ActionView::PathSet:0x007f35cd0415c8 @paths=[/usr/share/foreman/app/views, /opt/rh/ruby193/root/usr/share/gems/gems/katello-1.5.0/app/views, /opt/rh/ruby193/root/usr/share/gems/gems/katello-1.5.0/engines/bastion/app/views, /opt/rh/ruby193/root/usr/share/gems/gems/ui_alchemy-rails-1.0.12/app/views, /opt/rh/ruby193/root/usr/share/gems/gems/foreman-tasks-0.6.9/app/views, /opt/rh/ruby193/root/usr/share/gems/gems/foreman_bootdisk-2.0.6/app/views, /opt/rh/ruby193/root/usr/share/gems/gems/redhat_access-0.0.4/app/views, /opt/rh/ruby193/root/usr/share/gems/gems/foreman_discovery-1.3.0/app/views, /opt/rh/ruby193/root/usr/share/gems/gems/apipie-rails-0.2.5/app/views]>): app/controllers/application_controller.rb:313:in `generic_exception' lib/middleware/catch_json_parse_errors.rb:9:in `call' app/controllers/application_controller.rb:235:in `block (2 levels) in render_403' app/controllers/application_controller.rb:234:in `render_403' app/controllers/application_controller.rb:55:in `deny_access' app/controllers/application_controller.rb:47:in `authorize' app/controllers/unattended_controller.rb:20:in `block (2 levels) in <class:UnattendedController>' app/models/concerns/foreman/thread_session.rb:33:in `clear_thread'
Thanks, no need of additional testing. I've reproduced upstream today, investigated the issue a bit and I think it has to do something with permission upgrade/update or database migrations. On my development setup I am able to reproduce the issue. This instance have been upgraded and migrated several times with the bootdisk plugin. On a clean upstream Foreman nightly instance, I am able to create new user, adding it Boot disk access and View hosts roles and it just works. Since this bug effectively prevent you from delegating bootdisk creation to non-admin users, I am filing this as 6.0.z errata. This needs further investigation. Not sure if this is rather Bootdisk issue or generic Users and roles issue.
For the record the issue in comment 7 is a different one, perhaps this known issue: https://access.redhat.com/solutions/1238853
If the issue is Users and Roles it could be related since I can do what is describe in comment 7 with a user that has a Administrator role with no issue and the solution in https://access.redhat.com/solutions/1238853 is already configured in the Satellite server.
Marek, can you have a look? thanks
Bootdisk role and Viewer role should be really enough to generate bootdisks. It looks like Viewer role does not have permission to view/preview templates. We need to fix that: https://bugzilla.redhat.com/show_bug.cgi?id=1221146
After investigating and talking with Lukas, it's unrelated to permissions, seems like taxonomies issue.
Hello, I was finally able to resolve this issue. I have found out that there are problems when templates has wrong taxonomies. Can you verify please the following: - verify that the Operating System you use has iPXE template assigned - verify that both Bootdisk* templates (Boot disk iPXE - generic host and Boot disk iPXE - host) are in the Organization and Location of the user you are trying with - do the same (Org/Loc) for all templates assigned to the Operating System you use for the host (specifically iPXE template) - make sure the user is assigned to Bootdisk and Viewer roles
Just to inform you, this does not seem to be bug in either 6.0 or 6.1. Organization and Location must be set properly (see the comment 16 for more info). I am closing this bug, in case you still need help please re-open and provide more information. Thanks.
Hi Lukas, Sorry for the delayed response. I have verified all associations in the templates/org/location/user/operating system and I still have the same result. My next question is why I was able to generate and download the "Generic Image" but not "Host '<hostname>' Image", isn't this related iPXE templates? The "Boot disk iPXE - generic host" and "Boot disk iPXE - host" has the same settings and associations in my current setup. It would be great if you can share the specific fix you did from your environment where you have replicated the issue. Thanks, Ryan
Hello, I was finally able to reproduce it properly. Unfortunately I have no workaround for you for 6.0. We will fix this in 6.1. REPRO STEPS: Create a non-admin user (e.g. viewer role only), create new host, and as the viewer user log on and try to view a template. 2015-06-03 14:35:41 [I] Started GET "/unattended/iPXE?hostname=bdsktest.local.lan" for 127.0.0.1 at 2015-06-03 14:35:41 +0200 2015-06-03 14:35:41 [I] Processing by UnattendedController#iPXE as HTML ... app/controllers/application_controller.rb:224:in `block (2 levels) in render_403' app/controllers/application_controller.rb:223:in `render_403' app/controllers/application_controller.rb:63:in `deny_access' app/controllers/application_controller.rb:55:in `authorize' app/controllers/unattended_controller.rb:20:in `block (2 levels) in <class:UnattendedController>' app/models/concerns/foreman/thread_session.rb:32:in `clear_thread' lib/middleware/catch_json_parse_errors.rb:9:in `call' We have two issues basically: A) Permissions are not checked properly (we obviously use template kinds as actions and we don't have such permissions) B) Method render_403 does not work from UnattendedController context (layout error).
Just to make sure: The original error can be solved by assigning Org/Loc to all objects involved in this process: user, bootdisk templates, host, installation media. Use Organization - Mismatches report to verify. The latter bug reported here is a valid one, a patch was proposed upstream.
Upstream bug component is Provisioning
Connecting redmine issue http://projects.theforeman.org/issues/13039 from this bug
Moving to POST since upstream bug http://projects.theforeman.org/issues/13039 has been closed
Verified in Sat 6.3 snap 6 according to comment #19. User with viewer role can see the host's templates without exception, with proper permissions can access the bootdisk as well.
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