Description of problem: * Satellite-5.3.0-RHEL4-re20081022.0 / s390x * Solaris x86 custom channel * solaris x86 machine subscribed to this custom channel using activationkey After successful registration, I disassociated client machine with its base channel, but wasn't unable to assiciate it back again: list of base channels (rhn/systems/details/SystemChannels.do) is always empty. Same procedure with a 5.2.0 satellite works smoothly. Version-Release number of selected component (if applicable): Satellite-5.3.0-RHEL4-re20081022.0 / s390x
I'm not sure whether this is related or not, but when I do the following: * register a sun4v machine to my satellite (with enabled solaris support) * disassociate it with its base channel * delete the machine profile * re-run the registration from the sun4v machine, I get following message on the sun4v client system: Could not retrieve action item from server <Server for rhndev6.z900.redhat.com/XMLRPC> Error code: -31 Error Message: Service not enabled for system profile: "rhnsun16.rhnsun.rdu.redhat.com" Error Class Code: 31 Error Class Info: This system does not have a valid entitlement for Red Hat Network. Please visit https://rhndev6.z900.redhat.com/rhn/systems/SystemEntitlements.do or login at https://rhndev6.z900.redhat.com, and from the "Your Spacewalk" tab, select "Subscription Management" to enable RHN service for this system. Explanation: An error has occurred while processing your request. If this problem persists please enter a bug report at bugzilla.redhat.com. If you choose to submit the bug report, please be sure to include details of what you were trying to do when this error occurred and details on how to reproduce this problem. Following error is present in /var/log/httpd/error.log: ('Server has invalid release and token contains no base channels', 1000010091, [{'note': 'solaris-sun4v', 'usage_limit': None, 'user_id': 1, 'org_id': 1, 'server_id': None, 'token_desc': 'RHN Satellite Management Entitled Servers', 'token_type': 'enterprise_entitled', 'token': '1-c720f6bad3e91799051867e6e1ee5544', 'token_id': 1, 'deploy_configs': 'N', 'kickstart_session_id': None, 'is_base': 'Y'}]) RHN 16854 2008/10/25 10:38:14 -04:00: ('Server Not Entitled', 1000010091) And most importantly, something manipulates with the db: SQL> select * from rhnServerServerGroupArchCompat where server_arch_id = lookup_server_arch('sparc-sun4v-solaris'); no rows selected SQL> select * from rhnServerServerGroupArchCompat where server_arch_id = lookup_server_arch('sparc-sun4v-solaris'); no rows selected SQL> select lookup_server_arch('sparc-sun4v-solaris') from dual; LOOKUP_SERVER_ARCH('SPARC-SUN4V-SOLARIS') ----------------------------------------- 1022 SQL> All of the selects from above where returing sane data before the whole procedure (universe.deploy.sql contains the rows that are now missing).
Needless to say, the machine I was trying to register did appear in the system list in the webui, but it was unentitled. After I do following, everything returns back to normal (i.e. I'm able to register the machine again without any problems): SQL> insert into rhnServerServerGroupArchCompat (server_arch_id, server_group_type) values (lookup_server_arch('sparc-sun4v-solaris'), lookup_sg_type('enterprise_entitled')); 1 row created. SQL> insert into rhnServerServerGroupArchCompat (server_arch_id, server_group_type ) values (lookup_server_arch('sparc-sun4v-solaris'), lookup_sg_type('provisioning_entitled')); 1 row created.
In comment #1 I forgot to include this query: SQL> select * from rhnServerChannelArchCompat where server_arch_id = LOOKUP_SERVER_ARCH('sparc-sun4v-solaris'); no rows selected
The problem with channel disassociation / association is not specific to solaris (or custom) channels only. Same thing happens with Red Hat channels too.
I believe this was fixed by Brad in bz #477530. I'm moving this one to ON_QA.
I followed the reproducer, and I was able to associate/dissociate base channels for each of my Solaris machines, with the list being populated with the correct number of applicable channels each time. I believe that we can consider this bug VERIFIED, tested on the 4/14 ISO.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-1434.html