<div dir="ltr">Hello Spacewalk List!<div><br></div><div style>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.</div>
<div style><br></div><div style>But I digress.</div><div style><br></div><div style>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.</div>
<div style>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.</div><div style><br></div><div style>Pushing an RPM to the CentOS host through the Spacewalk UI gets me:</div>
<div style><br></div><div style><div>This action's status is: Failed.</div><div>The client picked up this action on 06/ 3/13 11:30:53 AM CDT.</div><div>The client completed this action on 06/ 3/13 11:30:54 AM CDT.</div>
<div>Client execution returned "Failed: There was a communication error talking to the server" (code 21)</div><div><br></div><div style>Okay. Let's try it using up2date on the other end:</div><div style><br>
</div><div style><div>[root@old_vm yum.repos.d]# up2date --channel centos-4-x86-64-base aide</div><div><br></div><div>Fetching Obsoletes list for channel: centos-4-x86-64-base...</div><div>########################################</div>
<div><br></div><div>Fetching rpm headers...</div><div>########################################</div><div><br></div><div>Name Version Rel Arch</div><div>----------------------------------------------------------------------------------------</div>
<div>aide 0.13.1 3.el4 x86_64</div><div><br></div><div><br></div><div>Testing package set / solving RPM inter-dependencies...</div><div>########################################</div>
<div>aide-0.13.1-3.el4.x86_64.rp ########################## Done.</div><div>Preparing ########################################### [100%]</div><div><br></div><div>Installing...</div><div> 1:aide ########################################### [100%]</div>
<div>There was a fatal error communicating with the server. The message was:</div><div>Internal Server Error</div><div><br></div><div style>Though, it does seem like it completes:</div><div style><div>[root@old_vm rhn]# rpm -qa | grep aide</div>
<div>aide-0.13.1-3.el4</div><div><br></div><div style>...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.</div><div style><br></div><div style>
That up2date prompts Spacewalk to spam me with tracebacks via email:</div><div style><br></div><div style><div>Exception Handler Information</div><div>Traceback (most recent call last):</div><div> File "/usr/lib/python2.6/site-packages/spacewalk/server/apacheRequest.py", line 122, in call_function</div>
<div> response = apply(func, params)</div><div> File "/usr/share/rhn/server/handlers/xmlrpc/registration.py", line 845, in add_packages</div><div> server.save_packages()</div><div> File "/usr/lib/python2.6/site-packages/spacewalk/server/rhnServer/server_wrapper.py", line 75, in save_packages</div>
<div> ret = self.save_packages_byid(self.server["id"], schedule=schedule)</div><div> File "/usr/lib/python2.6/site-packages/spacewalk/server/rhnServer/server_packages.py", line 228, in save_packages_byid</div>
<div> h.execute_bulk(package_data)</div><div> File "/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/sql_base.py", line 197, in execute_bulk</div><div> ret = ret + apply(self.executemany, (), subdict)</div>
<div> File "/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/sql_base.py", line 172, in executemany</div><div> return apply(self._execute_wrapper, (self._executemany, ) + p, kw)</div><div> File "/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql.py", line 282, in _execute_wrapper</div>
<div> retval = apply(function, p, kw)</div><div> File "/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql.py", line 318, in _executemany</div><div> self._real_cursor.executemany(self.sql, all_kwargs)</div>
<div>InternalError: -20243 : (package_arch_not_found) - Package architecture could not be found</div><div>CONTEXT: SQL statement "SELECT rhn_exception.raise_exception('package_arch_not_found')"</div><div>
PL/pgSQL function "lookup_package_arch" line 14 at PERFORM</div><div><br></div><div><div>Full email at <a href="https://gist.github.com/cswingler/66d00214ed5c789ce8c8">https://gist.github.com/cswingler/66d00214ed5c789ce8c8</a></div>
</div><div><br></div><div style>It looks like it's tripping over the package arch somewhere...</div></div><div style><br></div><div style><br></div><div style>So, a couple questions:</div><div style>* What's going on with that traceback, and how do I fix it?</div>
<div style>* Is it even _possible_ to deploy configuration files via Spacewalk to EL4 hosts? </div><div style>* Should I continue to try to get this to work? :)</div><div style><br></div><div style>Thanks</div><div style>
-Chris</div><div style><br></div></div></div></div></div>