[Spacewalk-list] Problem with rhncfg after upgrading to Spacewalk 1.2

[Will Lovins]

On Mon, Dec 13, 2010 at 11:56, Will Lovins <wlovins at gmail.com> wrote:
>
> This weekend I updated a spacewalk 1.0 installation to 1.2 and have run into a few problems (such as the missing dependency on quartz-oracle) and where the migrations died (http://spacewalk.pastebin.com/YAdZ0AUF - commented out DROP INDEX rhn_package_path_idx - terrible, I know), but I got threw them and spacewalk seems to be working properly except for the rhncfg tool. Specifically, rhncfg-manager is no longer working.
> When I attempt to use rhncfg-manager on a server that hasn't been updated to the latest client, I get this:
> rpm -q rhncfg-management rhncfg
> rhncfg-management-5.9.19-1.el5
> rhncfg-5.9.19-1.el5
>
> touch /usr/src/foo
> rhncfg-manager add -ctest 123 /usr/src/foo
> Red Hat Network username: rpmbuild
> Password:
> Traceback (most recent call last):
>   File "/usr/bin/rhncfg-manager", line 46, in ?
>     sys.exit(Main().main() or 0)
>   File "/usr/share/rhn/config_common/rhn_main.py", line 187, in main
>     handler.run()
>   File "/usr/share/rhn/config_management/rhncfg_add.py", line 64, in run
>     if not r.config_channel_exists(channel):
>   File "/usr/share/rhn/config_management/rpc_repository.py", line 182, in config_channel_exists
>     return (config_channel in self.list_config_channels())
>   File "/usr/share/rhn/config_management/rpc_repository.py", line 222, in list_config_channels
>     self.config_channels = self.rpc_call(
>   File "/usr/share/rhn/config_common/repository.py", line 362, in rpc_call
>     result = apply(method, params)
>   File "/usr/lib64/python2.4/xmlrpclib.py", line 1096, in __call__
>     return self.__send(self.__name, args)
>   File "/usr/share/rhn/config_common/rpc_wrapper.py", line 226, in _request
>     return self._call_function(rpclib.Server._request, (self, methodname, params))
>   File "/usr/share/rhn/config_common/rpc_wrapper.py", line 174, in _call_function
>     raise e #Don't raise the NoMoreServers error, raise the error that triggered the failover.
> xmlrpclib.Fault: <Fault 1: "While running 'config.management.list_config_channels': caught\nexceptions.TypeError : descriptor 'get' requires a 'dict' object but received a 'str'\n">
>
>
> When I upgrade to the latest client released client (5.9.33), I get this error:
> rhncfg-manager add -ctest 123 /usr/src/foo
> Traceback (most recent call last):
>   File "/usr/bin/rhncfg-manager", line 46, in ?
>     sys.exit(Main().main() or 0)
>   File "/usr/share/rhn/config_common/rhn_main.py", line 67, in main
>     if utils.startswith(arg, server_name_opt):
> AttributeError: 'module' object has no attribute 'startswith'
>
> Now, I do see https://bugzilla.redhat.com/show_bug.cgi?id=656895 which mentions the bug, but I don't see a .35 package anywhere. I did try the latest nightly package (5.9-37), but that just caused the original " descriptor 'get' requires a 'dict' object but received a 'str' " error to return.
> Updates uploaded or made in the spacewalk web UI work properly. It seems limited to a client-side (rhncfg-*.rpm) issue. Unfortunately, we rely on scripts which use rhncfg-manager for pushing a few hundred updates per day, so manually updating files in the interface isn't feasible. Any help that anyone can provide to get this working (even if it is a manual change until a proper package is available) would be greatly appreciated.
> Spacewalk System:
> Spacewalk 1.2
> CentOS release 5.5 (Final)
> Oracle DATABASE 11g RELEASE 11.2.0.1.0
> Client System
> CentOS release 5.5 (Final)
> Spacewalk 1.2 client - fully updated

I should also mention that rhncfg-client seemed to work with 5.9-19
and 5.9-37, but both rhncfg-client and rhncfg-manager both break with
.33 with the same " 'module' object has no attribute 'startswith' "
error. If I use the file /usr/share/rhn/config_common/rhn_main.py from
.37 with the .33 packages, it does resolve the rhncfg-client problem,
but the rhncfg-manager error changes from the "startswith" error to
the "'get' requires a 'dict' " error.