Description of problem:

humm, subscribed a rhel 5 client to the rhn tools channel,
yum install rhncfg-actions
rhn-actions-control --enable-all
yum list available
then within webui - selected this system into the System Set Manager and a RHEL
4 system with similar enablement of remote commands/actions with provisioning.
Went to reboot:
network/systems/ssm/misc/reboot_systems.pxt

Only the RHEL 4 system is listed, confirmed that under systems:
network/systems/ssm/system_list.pxt

I saw both and both had provisioning entitlement.. so.. what code is used to
render/list systems on reboot page.. 

<rhn-listview class="Sniglets::ListView::SystemList"
mode="system_set_supports_reboot_expanded">

This uses a query where part of it is:

                   AND PN.name = 'up2date'

Basically, for reboot capability, we say the system has to have 'up2date'
installed and be newer/greater than a specific RHEL 2.1 version of up2date,
which is why RHEL 3 and 4 are allowed for remote reboots (I also supect that the
newer RHEL 2.1 systems are listed for reboots as well). 

RHEL 4 - the reboot action is part of up2date:
[root@rlx-1-14 ~]# rpm -qf /usr/share/rhn/actions/reboot.py
up2date-4.4.69-25

with RHEL 5 the reboot action is part of rhn-check package:
[root@dhcp231-218 actions]# rpm -qf /usr/share/rhn/actions/reboot.py
rhn-check-0.4.13-1.el5
[root@dhcp231-218 actions]# 


This is the first time I heard of this bug, and most likely not only is it in
the 4.2 code, but also 5.0 Sat code in QA as well as RHN Hosted (rhn.redhat.com). 

Making a quick change:

[root@rlx-1-14 xml]# diff -u System_queries.xml.orig System_queries.xml
--- System_queries.xml.orig     2007-04-06 13:53:21.000000000 -0400
+++ System_queries.xml  2007-04-06 14:08:54.000000000 -0400
@@ -792,13 +792,13 @@
                        rhnPackageEVR PE
                  WHERE SP.server_id = S.id
                    AND SP.name_id = PN.id
-                   AND PN.name = 'up2date'
+                   AND PN.name in ('up2date', 'rhn-check')
                    AND SP.evr_id = PE.id
                    AND PE2.id = lookup_evr(NULL, '2.9.3', '2.2.1AS')
-                   AND PE.evr &gt;= PE2.evr
        )
 ORDER BY UPPER(S.name), S.id
   </query>
+#                   AND PE.evr &gt;= PE2.evr
 
 
 <mode name="systems_registered_with_key">
[root@rlx-1-14 xml]# 

Then allows the webui to schedule the reboot.
Checking a RHEL 2.1 box, I see that the same reboot function is available in the
newest/newer up2date programs.. so the WebUI should really say allows for
reboots of RHEL 2.1 and newer, with either rhn-check (RHEL 5) or up2date
(version greater than version 2.9.3-2.2.1AS). 

My quick hack just proved to me that if I did allow RHEL 5 clients with
rhn-check installed that the RHEL 5 reboot event can be scheduled and when
picked up, it from my test did complete successfully. 
Code... well logic needs, if system has up2date installed, make sure it is newer
than version 2.9.3-2.2.1AS, otherwise make sure it has rhn-check installed, and
of course if neither are true, do not return the system as allowed for reboots. 

Better code change would be something like:

diff -u System_queries.xml.orig System_queries.xml
--- System_queries.xml.orig     2007-04-06 13:53:21.000000000 -0400
+++ System_queries.xml  2007-04-06 16:19:40.000000000 -0400
@@ -792,10 +792,11 @@
                        rhnPackageEVR PE
                  WHERE SP.server_id = S.id
                    AND SP.name_id = PN.id
-                   AND PN.name = 'up2date'
                    AND SP.evr_id = PE.id
-                   AND PE2.id = lookup_evr(NULL, '2.9.3', '2.2.1AS')
-                   AND PE.evr &gt;= PE2.evr
+                   AND ((PN.name = 'rhn-check' AND PE2.id = PE.id)
+                   OR (PN.name = 'up2date' 
+                     AND PE2.id = lookup_evr(NULL, '2.9.3', '2.2.1AS') 
+                     AND PE.evr >= PE2.evr))
        )
 ORDER BY UPPER(S.name), S.id
   </query>
[root@rlx-1-14 xml]# 

As such, created a bug and placed under rhn421, as a minor bug, but easy to get
fixed...and also cloned it and placed under the RHN 5.0 Satellite. 

Please though - tell me if your trying to do reboots not via the System Set
Manager :) Of course, if you enable remote commands, you can schedule an event
to run the 'reboot' command. 

Cliff. 


David Parsley wrote:
> Hrm... I'm having a hard time figuring out the magic sauce needed to
> allow rebooting of RHEL5 machines via our local rhn satellite.  I
> would think this would be enabled by the appropriate
> rhn-actions-control commands; however both the script/run and
> configfiles/all files are present, but the web interface doesn't list
> the machines as rebootable.  Our older rhel 3 & 4 boxen both show up
> as rebootable.
> 
> Funny enough, I _can_ install a package, and run an arbitrary script
> on the box - say, /sbin/reboot - and that works.
> 
> Is this another 'bug to be fixed in 4.2.1', or am I just ignorant of
> what needs to be done to enable this feature?
> 
> Regards,
> David

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info: