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

Mon Jun 3 18:58:56 UTC 2013

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 [3]

> 
> 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 [1]

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

Links:
------
[1]
https://gist.github.com/cswingler/66d00214ed5c789ce8c8
[2]
https://www.redhat.com/mailman/listinfo/spacewalk-list
[3]
https://fedorahosted.org/spacewalk/wiki/RegisteringClients#CentOS4
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20130603/dbe7e9ac/attachment.htm>