Re: [Spacewalk-list] Clients show need for updates in GUI, but updates are not needed
Andy Ingham wrote: % Hello list -- % % I've got a number of spacewalk clients that indicate in the GUI that they % have critical updates needed, but the updates have been done (and yum on % the client is happy). % % I've tried everything I can think of to clear this discrepancy to no avail % (rhn-profile-sync, restarts of osad and rhnsd, GUI-forced package % verify, spacewalk server restart, re-registration of the client). ... % SNIP % 0, 'name': 'packages.verify'}) % XMLRPC ProtocolError: ProtocolError for [SERVER FQDN HERE] /XMLRPC: 500 % Internal Server Error Hi Andy, there should be more information about Internal Server Error in /var/log/httpd/*error_log and/or /var/log/rhn/*.log. Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Clients show need for updates in GUI, but updates are not needed
Thanks, Michael. I've looked at those logs as well and am noticing sql
connection errors such as:
/var/log/rhn/osa-dispatcher.log:2013/02/19 09:14:12 -04:00 2452 0.0.0.0:
osad/jabber_lib.main('ERROR', 'Traceback (most recent call last):\n File
/usr/share/rhn/osad/jabber_lib.py, line 117, in main\n
self.setup_config(config)\n File /usr/share/rhn/osad/osa_dispatcher.py,
line 112, in setup_config\nrhnSQL.initDB()\n File
/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/__init__.py,
line 124, in initDB\n__init__DB(backend, host, port, username,
password, database)\n File
/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/__init__.py,
line 55, in __init__DB\n__DB.connect()\n File
/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql
.py, line 171, in connect\nreturn self.connect(reconnect=0)\n File
/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql
.py, line 160, in connect\npassword=self.password)\nSQLConnectError:
(None, None, \'spaceschema\', \'Attempting Re-Connect to the database
failed\')\n')
Thankfully, it *does* appear that completely deleting and re-registering
clients does the trick. I sure wish there was a quicker way to
consistently flush these errors across a large number of clients, though.
Andy
On 2/22/13 3:56 AM, Michael Mraka michael.mr...@redhat.com wrote:
Andy Ingham wrote:
% Hello list --
%
% I've got a number of spacewalk clients that indicate in the GUI that they
% have critical updates needed, but the updates have been done (and yum on
% the client is happy).
%
% I've tried everything I can think of to clear this discrepancy to no
avail
% (rhn-profile-sync, restarts of osad and rhnsd, GUI-forced package
% verify, spacewalk server restart, re-registration of the client).
...
% SNIP
% 0, 'name': 'packages.verify'})
% XMLRPC ProtocolError: ProtocolError for [SERVER FQDN HERE] /XMLRPC: 500
% Internal Server Error
Hi Andy,
there should be more information about Internal Server Error in
/var/log/httpd/*error_log and/or /var/log/rhn/*.log.
Regards,
--
Michael Mráka
Satellite Engineering, Red Hat
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list
[Spacewalk-list] inability to completely purge orphaned packages
Hello again list -- I'm trying to use rhnpush to add a couple packages to a custom channel. I initially created a channel, added the packages and then (since I needed to define a different parent) deleted the channel, leaving the packages orphaned. I have (1) used the GUI to locate and remove the packages, and (2) run the following: spacewalk-data-fsck -v --remove Despite these attempts, each time I try to re-add the packages to the new channel (with correct parentage) I get the following errors: [root ~] $ rhnpush --nosig --channel=fuqua-rhnpush-centos5-x86_64 --server=http://localhost/APP --dir=/opt/installs/rhnpush_stage/x86_64 -v Connecting to http://localhost/APP Package /opt/installs/rhnpush_stage/x86_64/jdk-7u15-linux-x64.rpm already exists on the RHN Server-- Skipping Upload Package /opt/installs/rhnpush_stage/x86_64/jdk-6u41-linux-amd64.rpm already exists on the RHN Server-- Skipping UploadŠ. If I add the --force option, it gives me this error: Error Message: Package Upload Failed Error Class Code: 55 Error Class Info: The --force rhnpush option is disabled on this server. Please contact your Satellite administrator for more help. Any ideas for how to clear this so that I can PROPERLY add the packages? Many thanks in advance. Andy Andy Ingham IT Infrastructure Fuqua School of Business Duke University ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Spacewalk 1.7 CPU Maxed out by postgresql (8.4)
Also version 1.8 has a lot of improvements with PostgreSQL so an update may help you. But I'm curious what's the iowait on the pegged cpu?-- Sent from my HP Pre3On Feb 21, 2013 11:16 AM, Jan Pazdziora jpazdzi...@redhat.com wrote: On Tue, Jan 08, 2013 at 11:44:04AM -0500, Boyd, Robert wrote: Sometime this morning my spacewalk server pegged 100% on cpu utilization and has been staying there ever since. I tried a reboot, and just for grins updated errata/packages on the server. After rebooting it's still pegging the cpu usage with this process: postgres 2888 77.7 1.3 470128 53708 ?Rs 10:35 52:05 postgres: spaceuser spaceschema 127.0.0.1(46206) SELECT I am able to use the Spacewalk admin website without any problem other than a bit of slow response. How can I discover what is causing this (and hopefully fix it)? Try select * from pg_stat_activity; to see what select is causing the trouble and whether it's one select which is taking many minutes or a stream of selects.. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Spacewalk and Cobbler - Ignoring architecture
I had the same problem a while back and never figured it out. So I stopped using Spacewalk to provision VMs and started using ovirt (www.ovirt.org) instead. Spacewalk still maintains everything else though. *Much* easier to deal with, and you have more options for managing VMs. -I On Sun, Feb 17, 2013 at 7:24 PM, Ryan Davies r...@ryandavies.co.nz wrote: Hi Folks, I have Spacewalk sitting on a CentOS 6 server, I have a CentOS Channel set up with x86_64 architecture selected. However, when the Distribution is created from that, It's put into cobbler as i386. When koan kicks up to turn that into a virtual machine, it creates a i386 based KVM VM, and therefore the system cant kickstart because it's a 64Bit OS. If I go in via ssh and update the distribution using cobbler edit, and change the arch to x86_64, the systems kickstart as expected. Is this a known issue? Or am I selecting the wrong architecture in the Channel ? Regards, Ryan ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
