Description of problem: The kickstart of virtualized guest can be observed on page: /rhn/systems/details/kickstart/ScheduleWizard.do The page has three sub-tabs: [ Session Status ] [ Schedule ] [ Variables ] After the kickstart fails, user is unable to visit the [ Schedule ] sub-tab. Observing the Permission Error. Version-Release number of selected component (if applicable): Satellite 5.4.1 on RHEL6 How reproducible: always Steps to Reproduce: 1. start the kickstart of a machine 2. make it fail (e.g by stopped libvirtd on the client) 3. Click on the [ Schedule ] sub-tab Actual results: Permission Error Expected results: Page renders. Additional info: tail -f /var/log/httpd/* ==> /var/log/httpd/ssl_access_log <== 10.34.27.115 - - [05/May/2011:06:55:54 -0400] "GET /rhn/systems/details/kickstart/ScheduleWizard.do?sid=1000010006 HTTP/1.1" 200 7930 ==> /var/log/httpd/ssl_request_log <== [05/May/2011:06:55:54 -0400] 10.34.27.115 TLSv1 DHE-RSA-CAMELLIA256-SHA "GET /rhn/systems/details/kickstart/ScheduleWizard.do?sid=1000010006 HTTP/1.1" 7930 ==> /var/log/httpd/ssl_access_log <== 10.34.27.115 - - [05/May/2011:06:55:54 -0400] "GET /rhn/dwr/engine.js HTTP/1.1" 200 46055 ==> /var/log/httpd/ssl_request_log <== [05/May/2011:06:55:54 -0400] 10.34.27.115 TLSv1 DHE-RSA-CAMELLIA256-SHA "GET /rhn/dwr/engine.js HTTP/1.1" 46055 ==> /var/log/httpd/ssl_access_log <== 10.34.27.115 - - [05/May/2011:06:55:54 -0400] "GET /rhn/dwr/interface/DWRItemSelector.js HTTP/1.1" 200 413 ==> /var/log/httpd/ssl_request_log <== [05/May/2011:06:55:54 -0400] 10.34.27.115 TLSv1 DHE-RSA-CAMELLIA256-SHA "GET /rhn/dwr/interface/DWRItemSelector.js HTTP/1.1" 413
The page is accessible when the acls is disabled for the page. In the struts configuration /var/lib/tomcat6/webapps/rhn/WEB-INF/struts-config.xml for the ScheduleWizard action <action path="/systems/details/kickstart/ScheduleWizard" ... comment out the: <set-property property="acls" value="system_feature(ftr_kickstart)"/>
Just for the record, I was using the admin account.
Correction to the comment 0, the permission error is always there, no need to fail the kickstart.
The cause is that the system does not have Provisioning entitlement. If the Provisioning entitlement is added to the system, 413 Permission error goes away. The problem is that the route of system-provisioning and virtual-guest- provisioning is the same from some point. These three tabs in question are sub-tabs of [Provisioning -> Kickstart]. The [Provisioning -> Kickstart -> Schedule] page is responsible for scheduling system-kickstart while the [Virtualization -> Provisioning] is responsible for virtual-guest-kickstart. We may want to not offer [Schedule] page, when presenting the progress of virtual-guest-kickstart
Also note that if the system does not have Provisioning entitlement there is no path for the user to return on his [Session Status] page. Where he was redirected after submitting [Provisioning -> Kickstart].
*** Bug 784825 has been marked as a duplicate of this bug. ***