Do you (or anyone else on the list) have the spacewalk-client-tools-0.0-1.noarch.rpm package quoted at https://fedorahosted.org/spacewalk/wiki/RegisteringClients#CentOS4 ? It seems like it's necessary in order to get them to accept config files.
On Mon, Jun 3, 2013 at 1:58 PM, Spacewalk User < [email protected]> wrote: > ** > > I have a Satellite with RHEL4 clients, and pushing config files works for > them. I can't make out what's going on with your traceback, but if I had > just a handful of systems to do a small set of ad hoc tasks on, rather than > try to troubleshoot through this I'd just set up a private-public key pair > trust and script some scp and ssh stuff to do it. > > On 2013-06-03 14:40, Chris Swingler wrote: > > > 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 > [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
