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

Mon Jun 3 19:07:02 UTC 2013

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 <
spacewalk at epperson.homelinux.net> 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 <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
>
>
> _______________________________________________
> Spacewalk-list mailing listSpacewalk-list at redhat.comhttps://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/87cf1f7e/attachment.htm>