[Spacewalk-list] Spacewalk Upgrade Issue

[Michael Mraka]

Bedorf, Paul wrote:
% Description:
% 
% Hi, in our environment we are running the following:
% 
% spacewalk 1.8 nightly
% centos 5.9 64bit
% postgresql 8.4 (installed locally on the spacewalk server)
% 
% Spacewalk works absolutely perfect, no issues what's so ever. I have decided to upgrade spacewalk to the latest version 2.0, below you will find the steps that I took:
% 
% Upgrade:
% a.       I have followed the instructions on the following page:
% https://fedorahosted.org/spacewalk/wiki/HowToUpgrade19
% b.      Install spacewalk-repo
% rpm -Uvh http://yum.spacewalkproject.org/2.0/RHEL/5/x86_64/spacewalk-repo-2.0-3.el5.noarch.rpm
% c.       Enable nightly builds
% sed -i 's/enabled=0/enabled=1/' /etc/yum.repos.d/spacewalk-nightly.repo
% d.      sed -i 's/enabled=1/enabled=0/' /etc/yum.repos.d/spacewalk.repo

So you explicitly enabled nightly repo and disabled standard Spacewalk 2.0...

% e.      yum install cobbler-epel
% yum upgrade
% yum install rpmconf
% su - postgres -c 'PGPASSWORD=spacepw; createlang pltclu spaceschema ;'
% /usr/sbin/spacewalk-service stop
% /usr/bin/spacewalk-schema-upgrade
% f.        All is 100% successful at this point, I keep on going:
% spacewalk-setup --disconnected -upgrade
% /usr/share/spacewalk/setup/upgrade/rhn-enable-monitoring.pl
% /usr/sbin/spacewalk-service start
% g.       All is again 100% successful at this point, I restart the spacewalk server and can log in via admin URL and I see spacewalk has been upgraded to version 2.1 nightly

That's expected according to enabled repos above. On the other hand it
might be dangerous especially on production server because nightly repo
can contain buggy development code and can even cause data corruption / loss. 

% h.      All my configurations are there, and all of my systems are there.
% 
% Issue:
% 
% a.       I log in to one of the client machine's and attempt to re-register the client to spacewalk, just to ensure it is working correctly, I issue this command:
% 
% rhnreg_ks --force  -vvv --serverUrl=http://10.99.30.144/XMLRPC --activationkey=1-3768ca29596c8b11e3d7a8cad4136446
% D: rpcServer: Calling XMLRPC registration.welcome_message
% D: opening  db environment /var/lib/rpm/Packages joinenv
% D: opening  db index       /var/lib/rpm/Packages rdonly mode=0x0
% D: locked   db index       /var/lib/rpm/Packages
% D: rpcServer: Calling XMLRPC registration.welcome_message
% D: opening  db index       /var/lib/rpm/Providename rdonly mode=0x0
% D: rpcServer: Calling XMLRPC registration.new_system
% A protocol error occurred: Status 500 , attempt #1,
% Error communicating with server. The message was:
% Status 500
% D: closed   db index       /var/lib/rpm/Providename
% D: closed   db index       /var/lib/rpm/Packages
% D: closed   db environment /var/lib/rpm/Packages
% D: May free Score board((nil))

There should be more verbose error in /var/log/up2date on client and
/var/log/httpd/*error_log, /var/log/rhn/*.log and
/var/log/tomcat*/catalina.out on server.

% b.      I also receive an email with more info about this error message:
% 
% Exception reported from spacewalk2.corp.mosaic.com
% Time: Wed Oct 23 02:31:18 2013
% Exception type spacewalk.server.rhnSQL.sql_base.SQLSchemaError
% Exception while handling function registration.new_system Request object information:
% 
% URI: /XMLRPC
% Remote Host: phx-vld-sandbox01.corp.mosaic.com Server Name: 10.99.30.144:80 Headers passed in:
% Extra information about this error:
% SQL Error generated: (99999, 'ERROR:  current transaction is aborted, commands ignored until end of transaction block', '', <psycopg2.InternalError instance at 0x2ab9264c0fc8>)
...
%                              history = <type 'dict'> {'channels': ["Subscribed to base channel 'cent5_64bit_CD' (cent564bitcd)", "FAILED to subscribe to channel 'cent5_64bit_NAGIOS'", "FAILED to subscribe to channel 'cent5_64bit_UPDATES'", "FAILED to subscribe to channel 'Cent5_64bit_SPACECLIENTREPO18'", "FAILED to subscribe to channel 'cent5_64bit_389'", "FAILED to subscribe to channel 'cent5_64bit_EXTRAS'"], 'entitlement': 'Entitled as a Spacewalk Provisioning Entitled Servers member'}

Client can't subscribe to child channels (cent5_64bit_NAGIOS,
cent5_64bit_UPDATES, Cent5_64bit_SPACECLIENTREPO18, cent5_64bit_389,
cent5_64bit_EXTRAS). Is anything wrong with them?  Can other clients
subscribe to them?


Regards,

--
Michael Mráka
Satellite Engineering, Red Hat