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
