[Spacewalk-list] Enrolling/managing CentOS 4 Hosts in 2013 on Spacewalk
Chris Swingler
chris at chrisswingler.com
Mon Jun 3 18:40:15 UTC 2013
> 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.
Yes, I'm well aware that EL4 and CentOS 4 are, for all intents and
purposes, very, very dead.
> EL 4 is not supported by any recent versions of spacewalk.
Is that documented anywhere? The documentation still explains how to
register CentOS/EL4 systems:
https://fedorahosted.org/spacewalk/wiki/RegisteringClients#CentOS4
On Mon, Jun 3, 2013 at 1:04 PM, Paul Robert Marino <prmarino1 at gmail.com>wrote:
> 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
>>
>
>
> _______________________________________________
> 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/ac520ceb/attachment.htm>
More information about the Spacewalk-list
mailing list