[Spacewalk-list] Enrolling/managing CentOS 4 Hosts in 2013 on Spacewalk

[Paul Robert Marino]

EL 4 is not supported by any recent versions of spacewalk.
For all intensive purposes EL4 is past its End Of Life while you can get an
extended critical security patch only support contract from RedHat its
really only meant as s supplement for equipment you expect to retire in the
next year or two best focus on replacing them.


On Mon, Jun 3, 2013 at 1:10 PM, Chris Swingler <chris at chrisswingler.com>wrote:

> Hello Spacewalk List!
>
> As much as I'd like to throw them in the river, I've got a handful of
> CentOS 4 systems that we'd like to get enrolled in Spacewalk.  All we
> really want to do with them is push them a couple RPMs and some config
> files to get zabbix-agent up and running on them while we regroup and come
> up with a proper plan of attack to get rid of them.
>
> But I digress.
>
> I added a new Channel and Activation Key for CentOS 4. I also set up a
> Base channel and synced it against the CentOS 4.9 Base in Vault.
> I stood up a CentOS 4.9 x86_64 VM, managed to get it to run rhnreg_ks
> without issue, and it shows up in the Spacewalk UI.  So far, so good.
>
> Pushing an RPM to the CentOS host through the Spacewalk UI gets me:
>
> This action's status is: Failed.
> The client picked up this action on 06/ 3/13 11:30:53 AM CDT.
> The client completed this action on 06/ 3/13 11:30:54 AM CDT.
> Client execution returned "Failed: There was a communication error talking
> to the server" (code 21)
>
> Okay. Let's try it using up2date on the other end:
>
> [root at old_vm yum.repos.d]# up2date --channel centos-4-x86-64-base aide
>
> Fetching Obsoletes list for channel: centos-4-x86-64-base...
> ########################################
>
> Fetching rpm headers...
> ########################################
>
> Name                                    Version              Rel
>     Arch
>
> ----------------------------------------------------------------------------------------
> aide                                    0.13.1              3.el4
>       x86_64
>
>
> Testing package set / solving RPM inter-dependencies...
> ########################################
> aide-0.13.1-3.el4.x86_64.rp ########################## Done.
> Preparing              ########################################### [100%]
>
> Installing...
>    1:aide                   ###########################################
> [100%]
> There was a fatal error communicating with the server. The message was:
> Internal Server Error
>
> Though, it does seem like it completes:
> [root at old_vm rhn]# rpm -qa | grep aide
> aide-0.13.1-3.el4
>
> ...and it does appear in the Spacewalk UI for the system's installed
> software list after an rhn_check and refresh of the list page.
>
> That up2date prompts Spacewalk to spam me with tracebacks via email:
>
> Exception Handler Information
> Traceback (most recent call last):
>  File
> "/usr/lib/python2.6/site-packages/spacewalk/server/apacheRequest.py", line
> 122, in call_function
>    response = apply(func, params)
>  File "/usr/share/rhn/server/handlers/xmlrpc/registration.py", line 845,
> in add_packages
>    server.save_packages()
>  File
> "/usr/lib/python2.6/site-packages/spacewalk/server/rhnServer/server_wrapper.py",
> line 75, in save_packages
>    ret = self.save_packages_byid(self.server["id"], schedule=schedule)
>  File
> "/usr/lib/python2.6/site-packages/spacewalk/server/rhnServer/server_packages.py",
> line 228, in save_packages_byid
>    h.execute_bulk(package_data)
>  File
> "/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/sql_base.py",
> line 197, in execute_bulk
>    ret = ret + apply(self.executemany, (), subdict)
>  File
> "/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/sql_base.py",
> line 172, in executemany
>    return apply(self._execute_wrapper, (self._executemany, ) + p, kw)
>  File
> "/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql.py",
> line 282, in _execute_wrapper
>    retval = apply(function, p, kw)
>  File
> "/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql.py",
> line 318, in _executemany
>    self._real_cursor.executemany(self.sql, all_kwargs)
> InternalError: -20243 : (package_arch_not_found) - Package architecture
> could not be found
> CONTEXT:  SQL statement "SELECT
>  rhn_exception.raise_exception('package_arch_not_found')"
> PL/pgSQL function "lookup_package_arch" line 14 at PERFORM
>
> Full email at https://gist.github.com/cswingler/66d00214ed5c789ce8c8
>
> It looks like it's tripping over the package arch somewhere...
>
>
> So, a couple questions:
> * What's going on with that traceback, and how do I fix it?
> * Is it even _possible_ to deploy configuration files via Spacewalk to EL4
> hosts?
> * Should I continue to try to get this to work? :)
>
> Thanks
> -Chris
>
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20130603/2298a227/attachment.htm>