> 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 <[email protected]>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 <[email protected]>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@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@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 >> [email protected] >> https://www.redhat.com/mailman/listinfo/spacewalk-list >> > > > _______________________________________________ > Spacewalk-list mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/spacewalk-list >
_______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
