RE: [Spacewalk-list] CentOS 5.4 64 bit and spacewalk client tools

2009-10-27 Thread Flaherty, Patrick
> We're installing the spacewalk client tools on a new CentOS 
> 5.4 64 bit machine but got the following error:
> 
> # yum install yum-rhn-plugin
> Loaded plugins: fastestmirror
> Loading mirror speeds from cached hostfile Setting up Install 
> Process No package cat available.
> No package /etc/issue available.
> Resolving Dependencies
> - --> Running transaction check
> - ---> Package yum-rhn-plugin.noarch 0:0.5.3-6.el5.6 set to be updated
> - --> Processing Dependency: rhn-client-tools >= 0.2.3 for package:
> yum-rhn-plugin
> - --> Processing Dependency: rhn-setup for package: yum-rhn-plugin
> - --> Running transaction check
> - ---> Package rhn-client-tools.noarch 0:0.4.17-8.el5 set to 
> be updated
> - --> Processing Dependency: rhnlib >= 2.1 for package: 
> rhn-client-tools
> - ---> Package rhn-setup.noarch 0:0.4.17-8.el5 set to be updated
> - --> Processing Dependency: rhnsd for package: rhn-setup
> - --> Running transaction check
> - ---> Package rhnlib.noarch 0:2.2.5-1.el5 set to be updated
> - ---> Package rhnsd.x86_64 0:4.6.1-1.el5 set to be updated
> - --> Processing Dependency: rhn-check >= 0.0.8 for package: rhnsd
> - --> Running transaction check
> - ---> Package rhn-check.noarch 0:0.4.17-8.el5 set to be updated
> - --> Processing Conflict: yum conflicts yum-rhn-plugin < 0.5.3-30.el5
> - --> Finished Dependency Resolution
> yum-3.2.22-20.el5.centos.noarch from installed has depsolving problems
>   --> yum conflicts with yum-rhn-plugin
> Error: yum conflicts with yum-rhn-plugin  You could try using 
> --skip-broken to work around the problem  You could try 
> running: package-cleanup --problems
> package-cleanup --dupes
> rpm -Va --nofiles --nodigest The 
> program package-cleanup is found in the yum-utils package.
> 
> 
> It seems that the recent yum in CentOS 5.4 64 bit is not 
> cooperating/willing to work with the yum-rhn-plugin provided 
> by the Spacewalk team.
> 
> How can we solve this dependency problem?

I'm seeing the same issue on 32 and 64 bit CentOS boxes when I try to
upgrade them from 5.3 to 5.4. The client tools repositories on the
listed on the setup page for centos5 haven't been updated since 2008.
The instructions for fedora point at http://spacewalk.redhat.com/yum/0.5
or http://spacewalk.redhat.com/yum/0.6/. Perhaps those packages will
work? I'll likely try them tomorrow if I have enough time.

Patrick

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list


RE: CentOS 5.3 to CentOS 5.4 upgrade and yum_rhn_plugin ==> WAS: Re:[Spacewalk-list] osa-dispatcher not running or not connecting

2009-10-30 Thread Flaherty, Patrick
Please see the thread "[Spacewalk-list] CentOS 5.4 64 bit and spacewalk
client tools", where this has been discussed for a fix.

http://article.gmane.org/gmane.linux.redhat.spacewalk.user/2988

Patrick 

> -Original Message-
> From: spacewalk-list-boun...@redhat.com 
> [mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Michiel van Es
> Sent: Friday, October 30, 2009 10:36 AM
> To: Joshua Roys
> Cc: spacewalk-list@redhat.com
> Subject: CentOS 5.3 to CentOS 5.4 upgrade and yum_rhn_plugin 
> ==> WAS: Re:[Spacewalk-list] osa-dispatcher not running or 
> not connecting
> 
> Yes :)
> The next problem I got is to install the correct 
> yum_rhn_plugin working with CentOS 5.4 ;) The problem is that 
> a lot of CentoS 5 machines are now upgrading to CenOS 5.4 
> with a new yum version not compatible with the yum_rhn_plugin 
> installed by wget -q 
> http://stahnma.fedorapeople.org/spacewalk-tools/spacewalk-clie
> nt-tools-0.0-1.noarch.rpm
> 
> The question is now: how can I upgrae my centos 5.3 to 5.4 
> without the dependency problems (yum_rhn_plugin being to old?)
> 
> Kind regards,
> 
> Michiel
> 
> Joshua Roys wrote:
> > On 10/30/2009 10:11 AM, Michiel van Es wrote:
> >> FIXED IT!
> >>
> >> changed the max open files from 1024 to 2024 in the .xml files and 
> >> moved /var/lib/jabberd/db to /var/lib/jabberd/old-jammer&&  mkdir 
> >> /var/lib/jabberd/db&&  chown jabber:jabber /var/lib/jabberd/db&&  
> >> chmod
> >> 777 /var/lib/jabberd/db
> >> and restarted jabberd and now I see all connection established :)
> >>
> >> Works like a charm! :D
> >>
> >> Michiel van Es wrote:
> > 
> > Nice!  Glad you finally got it.
> > 
> > Josh
> 
> ___
> 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: CentOS 5.3 to CentOS 5.4 upgrade and yum_rhn_plugin ==> WAS:Re:[Spacewalk-list] osa-dispatcher not running or not connecting

2009-10-30 Thread Flaherty, Patrick
Hey Michel,

I re-read my original message, I probably should have been less curt
(sorry!). The work around seems to be use the packages out the .6 repo (
http://article.gmane.org/gmane.linux.redhat.spacewalk.user/3009 ). It
also appears that the "offical" repos will be updated when the packages
are ported.

The packages I needed were:
 rhn-check-0.6.4-1.el5.noarch.rpm
 rhnlib-2.5.13-1.el5.noarch.rpm
 yum-rhn-plugin-0.6.2-1.el5.noarch.rpm
 rhn-client-tools-0.6.4-1.el5.noarch.rpm
 rhn-setup-0.6.4-1.el5.noarch.rpm

Patrick

> -Original Message-
> From: spacewalk-list-boun...@redhat.com 
> [mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Michiel van Es
> Sent: Friday, October 30, 2009 11:28 AM
> To: spacewalk-list@redhat.com
> Subject: Re: CentOS 5.3 to CentOS 5.4 upgrade and 
> yum_rhn_plugin ==> WAS:Re:[Spacewalk-list] osa-dispatcher not 
> running or not connecting
> 
> Hi PAtrick,
> 
> yes I know, that is my own thread but there is not a solution 
> for all my CentOS 5.3 machines wanting to upgrade to CentOS 
> 5.4 and how I can upgrade my yum_rhn_plugin packages...
> 
> Or am I missing a post?
> 
> Michiel
> 
> Flaherty, Patrick wrote:
> > Please see the thread "[Spacewalk-list] CentOS 5.4 64 bit and 
> > spacewalk client tools", where this has been discussed for a fix.
> > 
> > http://article.gmane.org/gmane.linux.redhat.spacewalk.user/2988
> > 
> > Patrick
> > 
> >> -Original Message-
> >> From: spacewalk-list-boun...@redhat.com 
> >> [mailto:spacewalk-list-boun...@redhat.com] On Behalf Of 
> Michiel van 
> >> Es
> >> Sent: Friday, October 30, 2009 10:36 AM
> >> To: Joshua Roys
> >> Cc: spacewalk-list@redhat.com
> >> Subject: CentOS 5.3 to CentOS 5.4 upgrade and 
> yum_rhn_plugin ==> WAS: 
> >> Re:[Spacewalk-list] osa-dispatcher not running or not connecting
> >>
> >> Yes :)
> >> The next problem I got is to install the correct yum_rhn_plugin 
> >> working with CentOS 5.4 ;) The problem is that a lot of CentoS 5 
> >> machines are now upgrading to CenOS 5.4 with a new yum version not 
> >> compatible with the yum_rhn_plugin installed by wget -q 
> >> http://stahnma.fedorapeople.org/spacewalk-tools/spacewalk-clie
> >> nt-tools-0.0-1.noarch.rpm
> >>
> >> The question is now: how can I upgrae my centos 5.3 to 5.4 without 
> >> the dependency problems (yum_rhn_plugin being to old?)
> >>
> >> Kind regards,
> >>
> >> Michiel
> >>
> >> Joshua Roys wrote:
> >>> On 10/30/2009 10:11 AM, Michiel van Es wrote:
> >>>> FIXED IT!
> >>>>
> >>>> changed the max open files from 1024 to 2024 in the .xml 
> files and 
> >>>> moved /var/lib/jabberd/db to 
> /var/lib/jabberd/old-jammer&&  mkdir 
> >>>> /var/lib/jabberd/db&&  chown jabber:jabber /var/lib/jabberd/db&& 
> >>>> chmod
> >>>> 777 /var/lib/jabberd/db
> >>>> and restarted jabberd and now I see all connection established :)
> >>>>
> >>>> Works like a charm! :D
> >>>>
> >>>> Michiel van Es wrote:
> >>> Nice!  Glad you finally got it.
> >>>
> >>> Josh
> >> ___
> >> 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 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: CentOS 5.3 to CentOS 5.4 upgrade and yum_rhn_plugin ==>WAS:Re:[Spacewalk-list] osa-dispatcher not running or not connecting

2009-11-02 Thread Flaherty, Patrick
Yep, I wget'd the files from the redhat spacewalk repo, scp'd them in a
directory on a few client machines and ran "rpm -Uvh ./*.rpm" from that
directory.

I have not been brave enough to add them to my spacewalk channels and
have been doing the process manually on machines I've needed to patch.

Patrick

> -Original Message-
> From: spacewalk-list-boun...@redhat.com 
> [mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Michiel van Es
> Sent: Saturday, October 31, 2009 7:56 AM
> To: spacewalk-list@redhat.com
> Subject: RE: CentOS 5.3 to CentOS 5.4 upgrade and 
> yum_rhn_plugin ==>WAS:Re:[Spacewalk-list] osa-dispatcher not 
> running or not connecting
> 
> Hi Patrick,
> 
> That is ok mate ;)
> But how did you do the upgrade on your centos 5.3 clients?
> Did you do an rpm -UVH from these packages?
> I really hope that stahma will update it's packages so an yum 
> update would supply the new yum version :)
> 
> Kind regards,
> 
> Michiel
> ____
> From: spacewalk-list-boun...@redhat.com 
> [spacewalk-list-boun...@redhat.com] On Behalf Of Flaherty, 
> Patrick [pflahe...@wsi.com]
> Sent: Friday, October 30, 2009 7:51 PM
> To: spacewalk-list@redhat.com
> Subject: RE: CentOS 5.3 to CentOS 5.4 upgrade and 
> yum_rhn_plugin ==>WAS:Re:[Spacewalk-list] osa-dispatcher 
> not running or not connecting
> 
> Hey Michel,
> 
> I re-read my original message, I probably should have been 
> less curt (sorry!). The work around seems to be use the 
> packages out the .6 repo (
> http://article.gmane.org/gmane.linux.redhat.spacewalk.user/300
> 9 ). It also appears that the "offical" repos will be updated 
> when the packages are ported.
> 
> The packages I needed were:
>  rhn-check-0.6.4-1.el5.noarch.rpm
>  rhnlib-2.5.13-1.el5.noarch.rpm
>  yum-rhn-plugin-0.6.2-1.el5.noarch.rpm
>  rhn-client-tools-0.6.4-1.el5.noarch.rpm
>  rhn-setup-0.6.4-1.el5.noarch.rpm
> 
> Patrick
> 
> > -Original Message-
> > From: spacewalk-list-boun...@redhat.com 
> > [mailto:spacewalk-list-boun...@redhat.com] On Behalf Of 
> Michiel van Es
> > Sent: Friday, October 30, 2009 11:28 AM
> > To: spacewalk-list@redhat.com
> > Subject: Re: CentOS 5.3 to CentOS 5.4 upgrade and 
> yum_rhn_plugin ==> 
> > WAS:Re:[Spacewalk-list] osa-dispatcher not running or not connecting
> >
> > Hi PAtrick,
> >
> > yes I know, that is my own thread but there is not a 
> solution for all 
> > my CentOS 5.3 machines wanting to upgrade to CentOS
> > 5.4 and how I can upgrade my yum_rhn_plugin packages...
> >
> > Or am I missing a post?
> >
> > Michiel
> >
> > Flaherty, Patrick wrote:
> > > Please see the thread "[Spacewalk-list] CentOS 5.4 64 bit and 
> > > spacewalk client tools", where this has been discussed for a fix.
> > >
> > > http://article.gmane.org/gmane.linux.redhat.spacewalk.user/2988
> > >
> > > Patrick
> > >
> > >> -Original Message-
> > >> From: spacewalk-list-boun...@redhat.com 
> > >> [mailto:spacewalk-list-boun...@redhat.com] On Behalf Of
> > Michiel van
> > >> Es
> > >> Sent: Friday, October 30, 2009 10:36 AM
> > >> To: Joshua Roys
> > >> Cc: spacewalk-list@redhat.com
> > >> Subject: CentOS 5.3 to CentOS 5.4 upgrade and
> > yum_rhn_plugin ==> WAS:
> > >> Re:[Spacewalk-list] osa-dispatcher not running or not connecting
> > >>
> > >> Yes :)
> > >> The next problem I got is to install the correct yum_rhn_plugin 
> > >> working with CentOS 5.4 ;) The problem is that a lot of CentoS 5 
> > >> machines are now upgrading to CenOS 5.4 with a new yum 
> version not 
> > >> compatible with the yum_rhn_plugin installed by wget -q 
> > >> http://stahnma.fedorapeople.org/spacewalk-tools/spacewalk-clie
> > >> nt-tools-0.0-1.noarch.rpm
> > >>
> > >> The question is now: how can I upgrae my centos 5.3 to 
> 5.4 without 
> > >> the dependency problems (yum_rhn_plugin being to old?)
> > >>
> > >> Kind regards,
> > >>
> > >> Michiel
> > >>
> > >> Joshua Roys wrote:
> > >>> On 10/30/2009 10:11 AM, Michiel van Es wrote:
> > >>>> FIXED IT!
> > >>>>
> > >>>> changed the max open files from 1024 to 2024 in the .xml
> > files and
> > >>>> moved /var/lib/jabberd/db to
> > /var/lib/jabberd/old-jammer&&am

[Spacewalk-list] 0.7 CentOS 4 Problems / new repos not having their data build

2009-12-17 Thread Flaherty, Patrick
I've got two point five issues since upgrading to Spacewalk 0.7.

1) CentOS 4 Systems now say. 
 # yum update
 Setting up Update Process
 Setting up repositories
 No Repositories Available to Set Up
 Reading repository metadata in from local files
 No Packages marked for Update/Obsoletion

2) I the updated rhn-plugin packages my centos5-spacewalktools repo, but
the clients don't see them when I run yum upgrade
2.5) I created a new channel with the client-0.7 rpms, subscribed
systems see this when I run yum upgrade:
 yum upgrade rhn-client-tools
 Loaded plugins: fastestmirror, rhnplugin
 Loading mirror speeds from cached hostfile
 Error: Cannot retrieve repository metadata (repomd.xml) for repository:
c5-i386-spacewalk. Please verify its path and try again

Anyone have any ideas?

Patrick

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list


Re: [Spacewalk-list] 0.7 CentOS 4 Problems / new repos not having theirdata build

2009-12-24 Thread Flaherty, Patrick
> 2) I the updated rhn-plugin packages my 
> centos5-spacewalktools repo, but the clients don't see them 
> when I run yum upgrade
> 2.5) I created a new channel with the client-0.7 rpms, 
> subscribed systems see this when I run yum upgrade:
>  yum upgrade rhn-client-tools
>  Loaded plugins: fastestmirror, rhnplugin  Loading mirror 
> speeds from cached hostfile
>  Error: Cannot retrieve repository metadata (repomd.xml) for 
> repository:
> c5-i386-spacewalk. Please verify its path and try again

Looks like task-o-matic crashed and didn't fix itself. Rebooting the
machine fixed the issue.

Patrick

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list


[Spacewalk-list] Spacewalk .07 with CentOS 4 clients

2010-01-15 Thread Flaherty, Patrick
 I'm guessing the requirement of yum 3.2.19-15 is why they aren't
shipping Centos4 clients for spacewalk. Has anyone tried to compile them
and see what breaks? I have a few c4 clients that worked fine with 0.6.
I upgraded to 0.7, and though the spacewalk webpage shows they have
available packages, running yum update shows no packages found. 

Patrick

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list


[Spacewalk-list] Oracle Size Limit Reached

2010-02-16 Thread Flaherty, Patrick
Hey All,
 I've had about 60 machines in spacewalk for over a year. Recently I ran
into some strange spacewalk problems (can't alter subscriptions, can't
build repos etc), which I tracked down to be database related using the
catapult log. I purged a bunch of channels and packages I didn't need,
and the problems have seemed to go away. However when I look at the
oracle webpage, I'm still within 10megs of the at the physical limit on
disk. I ran compact database which didn't appear to do anything. 

Does anyone have any hits on purging data?
If I were to dump the oracle database and reimport it, would it be any
smaller?

Patrick

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list


Re: [Spacewalk-list] Is there spacewalk-client software packagesavailable for CentOS 3 & 4?

2010-08-02 Thread Flaherty, Patrick
Hey Gregg,

CentOS 4 machines need to use up2date
https://fedorahosted.org/spacewalk/wiki/RegisteringClients, not yum.

I don't know about CentOS 3, I think you may be SOL, but if you manage
to get it to work I'm sure people would like to know about it.

Patrick

> -Original Message-
> From: spacewalk-list-boun...@redhat.com [mailto:spacewalk-list-
> boun...@redhat.com] On Behalf Of Gregg Phillips
> Sent: Monday, August 02, 2010 1:28 PM
> To: Spacewalk-list@redhat.com
> Subject: [Spacewalk-list] Is there spacewalk-client software
> packagesavailable for CentOS 3 & 4?
> 
>  Good Morning,
> 
> Along the lines of my previous post I am now setting-up channels for
> CentOS 3 & 4. Are there repositories for Spacewalk-1.0-client software
> for CentOS 3 & 4? If not, how does one get the client computers to
> check-in with the spacewalk server?
> 
> TIA,
> 
> Gregg.
> 
> ___
> 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] Oracle XE reached 4GB Limit

2010-10-14 Thread Flaherty, Patrick


> -Original Message-
> From: spacewalk-list-boun...@redhat.com [mailto:spacewalk-list-
> boun...@redhat.com] On Behalf Of Sabuj Pattanayek
> Sent: Wednesday, October 13, 2010 9:08 AM
> To: spacewalk-list@redhat.com
> Subject: Re: [Spacewalk-list] Oracle XE reached 4GB Limit
> 
> How did you know you hit the 4gb limit?
> 
> On Wed, Oct 13, 2010 at 7:56 AM, Rampersad, Shaun
>  wrote:
> >
> > Rampersad, Shaun wrote:
> >>> Hi all
> >>>
> >>>
> >>>
> >>> I've been using spacewalk to manage my centos servers. I have a
mix
> of
> >>> Centos 4 and 5, both 32 and 64 bit. I have created channels for
> each one
> >>> of them and have over 100 servers registered.
> >>>
> >>>
> >>>
> >>> The problem is that the Oracle XE DB has reached its 4GB limit.
How
> can
> >>> I get around this? Do I need to delete all "old" packages from the
> >>> repository and then delete the channel and upload?
> >>
> >>I do not have any solutions to offer other than trying to trim/purge
> old
> >>system profiles and packages.
> >
> > I have deleted the Centos4 i386 channels since I only had 6 servers
> registered on this. I have also deleted about 3000 orphaned packages
on
> spacewalk under "Manage Software Packages" but I still cannot load
> newer packages on Centos 5 channel. Its as if the delete did not free
> up the DB space and it is still on 4GB
> >
> > Anything else I can try? I wanted to delete the Centos4 x86_64 bit
> channel as well but if it has no effect then its pointless.
> >
> > Thanks
> > Shaun
> >
> >>
> >>
> >>> Are there any alternatives to Oracle XE? Has there been any
> progress on
> >>> Postgres? I see that this is scheduled for release on spacewalk
> 2.0.
> >>
> >>Postgres is progressing, slowly, but we have achieved a point where
> it
> >>can install and some very basic functionality seems to work, but it
> is
> >>not even in an alpha state. More information:
> >>
> >>https://www.redhat.com/archives/spacewalk-devel/2010-
> October/msg00017.html
> >>
> >>Spacewalk nightly can be installed without Oracle bits (developers
> only)
> >>
> >>NOTE: developers only...
> >>
> >>Cliff
> >
> > This e-mail is subject to a disclaimer, available at
> http://www.rmb.co.za/web/elements.nsf/online/disclaimer-
> communications.html
> >

I got this nagios check for free space. I'm very thankful to whoever
wrote it, learning oracle is almost as damaging as getting an MBA.
Change the variables for your spacewalk database username and password,
and call the script with your warning and critical arguments.

Patrick




#!/bin/bash

SPACEWALK_USER=" YourSpacewalkDB_Username"
SPACEWALK_PASS="YourSpacewalkDB_Password"
SPACEWALK_SID="XE"
WARNING_PERCENTAGE=$1
CRITICAL_PERCENTAGE=$2

if [[ ! `which sqlplus` ]]; then
 echo "CRITICAL - sqlplus command not found"
 exit 2
fi

SPACEWALK_DB_USED="$(echo "select trunc(sum(bytes)/1024/1024, 2) MB from
dba_segments where owner = '${SPACEWALK_USER}';" | sqlplus -s
${SPACEWALK_USER}/${spacewalk_pa...@${spacewalk_sid} | awk '$1 ~
/[0-9]+/{print $1}')"

if [[ $? != 0 ]]; then
 echo "CRITICAL - could not get space used data from oracle"
 exit 2
fi

SPACEWALK_DB_FREE="$(echo "scale=2; 4096-${SPACEWALK_DB_USED}" | bc)"

SPACEWALK_DB_USED_PERCENT="$(echo "scale=2;
(${SPACEWALK_DB_USED}/4096)*100" | bc)"

SPACEWALK_DB_FREE_PERCENT="$(echo "scale=2;
100-${SPACEWALK_DB_USED_PERCENT}" | bc)"

if (( `echo "${SPACEWALK_DB_FREE_PERCENT} <= ${CRITICAL_PERCENTAGE}" |
bc` )); then
  echo "CRITICAL - Less than ${CRITICAL_PERCENTAGE}% space left |
DB_USED=${SPACEWALK_DB_USED}MB;DB_FREE=${SPACEWALK_DB_FREE}MB;DB_USED_PE
RCENT=${SPACEWALK_DB_USED_PERCENT};DB_FREE_PERCENT=${SPACEWALK_DB_FREE_P
ERCENT}"
  exit 2
 elif (( `echo "${SPACEWALK_DB_FREE_PERCENT} <= ${WARNING_PERCENTAGE}" |
bc` )); then
  echo "WARNING - Less than ${WARNING_PERCENTAGE}% space left |
DB_USED=${SPACEWALK_DB_USED}MB;DB_FREE=${SPACEWALK_DB_FREE}MB;DB_USED_PE
RCENT=${SPACEWALK_DB_USED_PERCENT};DB_FREE_PERCENT=${SPACEWALK_DB_FREE_P
ERCENT}"
  exit 1
 elif (( `echo "${SPACEWALK_DB_FREE_PERCENT} > ${WARNING_PERCENTAGE}" |
bc` )); then
  echo "OK - Spacewalk DB size within limits |
DB_USED=${SPACEWALK_DB_USED}MB;DB_FREE=${SPACEWALK_DB_FREE}MB;DB_USED_PE
RCENT=${SPACEWALK_DB_USED_PERCENT};DB_FREE_PERCENT=${SPACEWALK_DB_FREE_P
ERCENT}"
  exit 0
 else
 echo "UNKNOWN - was unable to compare DB space values |
DB_USED=${SPACEWALK_DB_USED}MB;DB_FREE=${SPACEWALK_DB_FREE}MB;DB_USED_PE
RCENT=${SPACEWALK_DB_USED_PERCENT};DB_FREE_PERCENT=${SPACEWALK_DB_FREE_P
ERCENT}"
 exit 3
fi


___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list


Re: [Spacewalk-list] I dont understand how it should work :-)

2010-10-28 Thread Flaherty, Patrick
You probably have a two problems:
* /etc/yum.repo.d/ probably still has centos repos, yum will look thru there 
for places to download updates.
* you haven't updated your centos channels, or don't have spacewalk setup to 
update them on the reg.

/usr/bin/spacewalk-repo-sync --channel WHATEVERYOUCALLEDYOURCENTOSCHANNEL --url 
http:// WHEREEVERYOUPULLYOURECENTOSPACKAGES --type yum 

Make sure you have the files in cron described here: 
http://wiki.centos.org/HowTos/PackageManagement/Spacewalk#head-7a284eb582941c82ecd294ebc5c16c404a242e3e



> -Original Message-
> From: spacewalk-list-boun...@redhat.com [mailto:spacewalk-list-
> boun...@redhat.com] On Behalf Of Götz Reinicke - IT-Koordinator
> Sent: Thursday, October 28, 2010 4:30 AM
> To: spacewalk-list
> Subject: [Spacewalk-list] I dont understand how it should work :-)
> 
> Hey,
> 
> some time ago I set up spacewalk 1.0 and added a couple of servers.
> 
> Today I notices, that there should be some updates for a couple of
> centos 5 servers.
> 
> If I do a yum update on that system, those updates show up and are
> loaded from a centos mirror, not from my spacewalk server.
> 
> In spacewalk, the server looks up to date (0 Errata, 0 Packages)
> 
> My questions:
> 
> Why might those updates dont show up in spacewalk? (may be some sort of
> sync/connecting/requesting/checkin) is missing?
> 
> Why dose my server loads the updates from the internet and not from my
> spacewalk server?
> 
> May be I mixed up a couple of things, and maybe someone can help me
> out?!
> 
> Thanks and best regards,
> 
>   Götz
> 
> --
> Götz Reinicke
> IT-Koordinator
> 
> Tel. +49 7141 969 420
> Fax  +49 7141 969 55 420
> E-Mail goetz.reini...@filmakademie.de
> 
> Filmakademie Baden-Württemberg GmbH
> Akademiehof 10
> 71638 Ludwigsburg
> www.filmakademie.de
> 
> Eintragung Amtsgericht Stuttgart HRB 205016 Vorsitzende des
> Aufsichtsrats:
> Prof. Dr. Claudia Hübner
> 
> Geschäftsführer:
> Prof. Thomas Schadt


___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list


[Spacewalk-list] reposync Non-UTF Encoding in RPMs

2011-03-22 Thread Flaherty, Patrick
I just switched over to a postgres backend for my spacewalk 1.3 setup.
So far, there have been a couple centos 5 packages that don't import
correctly when I spacewalk-repo-sync from the command line.

# rpm -qf `which spacewalk-repo-sync`
 spacewalk-backend-tools-1.3.57-1.el5

Packages:
* aspell-is-0.51.1-2.2.2-50.i386
* man-pages-da-0.1.1-12.1.1-0.noarch

http://pastebin.com/047jy19W

Both of those packages appear to have non-utf8 characters in filename
paths which I guess could be the the problem. I'm capture the output of
the import, there may be more packages that show the same behavior.

So I can file the bug in the right place, does this look like:
* a spacewalk bug?
* a spacewalk postgres backend bug?
* a centos packaging bug?

What other information should I include in my bug report?

Thanks,
Patrick


___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list


Re: [Spacewalk-list] reposync Non-UTF Encoding in RPMs

2011-03-23 Thread Flaherty, Patrick
> -Original Message-
> From: spacewalk-list-boun...@redhat.com [mailto:spacewalk-list-
> boun...@redhat.com] On Behalf Of Jan Pazdziora
> Sent: Wednesday, March 23, 2011 5:04 AM
> To: spacewalk-list@redhat.com
> Subject: Re: [Spacewalk-list] reposync Non-UTF Encoding in RPMs
> 
> On Tue, Mar 22, 2011 at 06:44:31PM -0400, Flaherty, Patrick wrote:
> > I just switched over to a postgres backend for my spacewalk 1.3
> setup.
> > So far, there have been a couple centos 5 packages that don't import
> > correctly when I spacewalk-repo-sync from the command line.
> >
> > # rpm -qf `which spacewalk-repo-sync`
> >  spacewalk-backend-tools-1.3.57-1.el5
> >
> > Packages:
> > * aspell-is-0.51.1-2.2.2-50.i386
> > * man-pages-da-0.1.1-12.1.1-0.noarch
> >
> > http://pastebin.com/047jy19W
> >
> > Both of those packages appear to have non-utf8 characters in
filename
> > paths which I guess could be the the problem. I'm capture the output
> of
> > the import, there may be more packages that show the same behavior.
> >
> > So I can file the bug in the right place, does this look like:
> > * a spacewalk bug?
> > * a spacewalk postgres backend bug?
> > * a centos packaging bug?
> >
> > What other information should I include in my bug report?
> 
> We actually have this tracked as bug 658296.

Jan, 

 I should have checked bugzilla. Thank you for the update and the info. 

Patrick


___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list


[Spacewalk-list] RHN Traceback - violates unique constraint "rhn_sp_snep_uq"

2011-03-25 Thread Flaherty, Patrick
 After switching over to the postgres backend, I'm occasionally getting
the following traceback when attempting to change a single host's
channel assignment. The browser hangs and finally returns a 500. The
system shows iowaits in the 40s to 90s before I get the 500, and then
the iowaits return to normal when the 500 comes back.

So, since it says:
 IntegrityError: duplicate key value violates unique constraint
"rhn_sp_snep_uq"

Should I be investigating the iowaits, or the unique constraints error?

Patrick




Exception reported from scrubbed_spacewalk_host.local
Time: Fri Mar 25 14:01:44 2011
Exception type psycopg2.IntegrityError
Exception while handling function registration.delta_packages Request
object information:
URI: /XMLRPC
Remote Host: scrubbed_client.local
Server Name: scrubbed_spacewalk_host.local:0 Headers passed in:
Accept-Encoding: identity
Content-Length: 7258
Host: scrubbed_spacewalk_host.local
content-type: text/xml
user-agent: rhn.rpclib.py/$Revision: 102540 $
x-client-version: 1
x-info: RPC Processor (C) Red Hat, Inc (version 102540)
x-rhn-client-capability:
packages.verifyAll(1)=1,caneatCheese(1)=1,packages.extended_profile(1)=1
,reboot.reboot(1)=1,packages.verify(1)=1,packages.runTransaction(1)=1,pa
ckages.rollBack(1)=1
x-rhn-transport-capability: follow-redirects=2
x-transport-info: Extended Capabilities Transport (C) Red Hat,
Inc (version 102540)
x-up2date-version: 0.4.17-8.el5

Exception Handler Information
Traceback (most recent call last):
  File
"/usr/lib/python2.4/site-packages/spacewalk/server/apacheRequest.py",
line 118, in call_function
response = apply(func, params)
  File "/usr/share/rhn/server/handlers/xmlrpc/registration.py", line
866, in delta_packages
server.save_packages()
  File
"/usr/lib/python2.4/site-packages/spacewalk/server/rhnServer/server_wrap
per.py", line 75, in save_packages
ret = self.save_packages_byid(self.server["id"], schedule=schedule)
  File
"/usr/lib/python2.4/site-packages/spacewalk/server/rhnServer/server_pack
ages.py", line 223, in save_packages_byid
h.execute_bulk(package_data)
  File
"/usr/lib/python2.4/site-packages/spacewalk/server/rhnSQL/sql_base.py",
line 197, in execute_bulk
ret = ret + apply(self.executemany, (), subdict)
  File
"/usr/lib/python2.4/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.4/site-packages/spacewalk/server/rhnSQL/driver_postgre
sql.py", line 263, in _execute_wrapper
retval = apply(function, p, kw)
  File
"/usr/lib/python2.4/site-packages/spacewalk/server/rhnSQL/driver_postgre
sql.py", line 299, in _executemany
self._real_cursor.executemany(self.sql, all_kwargs)
IntegrityError: duplicate key value violates unique constraint
"rhn_sp_snep_uq"


Local variables by frame
Frame _executemany in
/usr/lib/python2.4/site-packages/spacewalk/server/rhnSQL/driver_postgres
ql.py at line 299
 val =  6.6.3
  all_kwargs =  [{'a': 'i386', 'e': '0',
'n': 'nss-devel', 'instime': None, 'sysid': 110720, 'r':
'1.el5.centos', 'v': '3.12.8'}, {'a': 'i386', 'e': '0', 'n':
'xorg-x11-drv-ast', 'instime': None, 'sysid': 110720, 'r': '1.el5',
'v': '0.89.9'}, {'a': 'i386', 'e': '0', 'n': 'xorg-x11-drv-i810',
'instime': None, 'sysid': 110720, 'r': '9.36.el5', 'v': '1.6.5'},
{'a': 'i386', 'e': '0', 'n': 'xorg-x11-drv-mga', 'instime': None,
'sysid': 110720, 'r': '7.el5', 'v': '1.4.10'}, {'a': 'i386', 'e':
'0', 'n': 'nss', 'instime': None, 'sysid': 110720, 'r':
'1.el5.centos', 'v': '3.12.8'}, {'a': 'i386', 'e': '0', 'n':
'xorg-x11-drv-fbdev', 'instime': None, 'sysid': 110720, 'r': '3',
'v': '0.3.0'}, {'a': 'i386', 'e': '0', 'n': 'xorg-x11-server-Xnest',
'instime': None, 'sysid': 110720, 'r': '48.76.el5_5.2', 'v':
'1.1.1'}, {'a': 'i386', 'e': '0', 'n': 'xorg-x11-server-Xorg',
'instime': None, 'sysid': 110720, 'r': '48.76.el5_5.2', 'v':
'1.1.1'!
 }, {'a': 'i386', 'e': '0', 'n': 'nss-tools', 'instime': None, 'sysid':
110720, 'r': '1.el5.centos', 'v': '3.12.8'}, {'a': 'i386', 'e': '0',
'n': 'xorg-x11-server-Xvfb', 'instime': None, 'sysid': 110720, 'r':
'48.76.el5_5.2', 'v': '1.1.1'}, {'a': 'i386', 'e': '1', 'n':
'xorg-x11-drv-evdev', 'instime': None, 'sysid': 110720, 'r':
'5.el5', 'v': '1.0.0.5'}, {'a': 'i386', 'e': '0', 'n':
'xorg-x11-drv-nv', 'instime': None, 'sysid': 110720, 'r': '3.el5',
'v': '2.1.15'}, {'a': 'i386', 'e': '0', 'n': 'firefox', 'instime': None,
'sysid': 110720, 'r': '2.el5.centos', 'v': '3.6.13'}, {'a': 'i386',
'e': '0', 'n': 'xorg-x11-drv-vesa', 'instime': None, 'sysid':
110720, 'r': '8.2.el5', 'v': '1.3.0'}, {'a': 'i386', 'e': '0', 'n':
'xulrunner', 'instime': None, 'sysid': 110720, 'r': '3.el5', 'v':
'1.9.2.13'}, {'a': 'i386', 'e': '0', 'n': 'nspr', 'instime': None,
'sysid': 110720, 'r': '1.el

Re: [Spacewalk-list] RHN Traceback - violates unique constraint "rhn_sp_snep_uq"

2011-04-05 Thread Flaherty, Patrick
> Sent: Tuesday, April 05, 2011 5:11 AM
> On Fri, Mar 25, 2011 at 05:46:01PM -0400, Flaherty, Patrick wrote:
> >  After switching over to the postgres backend, I'm occasionally
> getting
> > the following traceback when attempting to change a single host's
> > channel assignment. The browser hangs and finally returns a 500. The
> > system shows iowaits in the 40s to 90s before I get the 500, and
then
> > the iowaits return to normal when the 500 comes back.
> >
> > So, since it says:
> >  IntegrityError: duplicate key value violates unique constraint
> > "rhn_sp_snep_uq"
> >
> > Should I be investigating the iowaits, or the unique constraints
> error?
> 
> Can you be more specific about the actions that you do? You say
> "attempting to change a single host's channel assignment" but the
> traceback is from the server handler of registration code which is
> no longer used by the latest RHN client tools / yum-rhn-plugin.
> 
> Is the attempt to change channel some rhnreg_ks with activation key,
> or what exactly do you (knowingly) call? Is the list of the packages
> in /var/log/up2date? You might need to bump up the debug option in
> /etc/sysconfig/rhn/up2date to see the packages listed there.

This install of spacewalk has been around for a couple years. We started
with one of the early 0. releases (maybe 0.5?), and have been upgrading
in place whenever a new release comes out since then. Could there be
cruft and code / database entries that need to be purged? 

Steps to reproduce:
* Open browser, navigate to spacewalk web interface
* Login
* Click systems
* Click host
* Click "Alter Subscriptions"
* Receive 500 and a traceback. 

The traceback I received today when doing those step was *not* the one
with the uniq_key_restraint error. It could be that I had older
spacewalk clients checking in/registering around the same time as I got
the 500 last time and mixed up the tracebacks. I've included today's
traceback. There are also a few systems that cause rhn tracebacks when
they check in, I'll send in a separate email / thread for those.

Patrick

The following exception occurred while executing this request:
GET /rhn/systems/details/SystemChannels.do

Date:4/5/11 11:18:46 AM EDT
Headers:
  host: local_spacewalk_server
  user-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13)
Gecko/20101209 CentOS/3.6-2.el5.centos Firefox/3.6.13
  accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
  accept-language: en-us,en;q=0.5
  accept-encoding: gzip,deflate
  accept-charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
  Keep-Alive: 115
  connection: keep-alive
  referer:
https://local_spacewalk_server/rhn/systems/details/Overview.do?sid=1
1
  cookie: JSESSIONID=4FA3972BCE4B6CB4CDCF49B87E18CD97;
pxt-session-cookie=8257x99c65ebedd7dcce6710f76ef73994a72

Request:
Local Name = local_spacewalk_server
Server Name = local_spacewalk_server Requested Session Id came from
Cookie Requested Session Valid = true Session =
org.apache.catalina.session.StandardSessionFacade@17620cf[session=Standa
rdSession[4FA3972BCE4B6CB4CDCF49B87E18CD97]]
Protocol = https
Request Locale = en_US
Request Character Encoding = UTF-8
Attribute Names = rhnActiveLang,
javax.servlet.jsp.jstl.fmt.timeZone.request, systemChannelsForm,
avail_child_channels, javax.servlet.request.key_size, requestedUri,
javax.servlet.request.ssl_session, org.apache.struts.action.MESSAGE,
system, session, __sitemesh__filterapplied,
javax.servlet.request.cipher_suite,
org.apache.struts.action.mapping.instance,
org.apache.struts.action.MODULE, 


User Information:
User spacewalkadmin (id 1, org_id 1)

Exception:
javax.servlet.ServletException: ERROR: syntax error at or near "c"
at
org.apache.struts.action.RequestProcessor.processException(RequestProces
sor.java:535)
at
org.apache.struts.action.RequestProcessor.processActionPerform(RequestPr
ocessor.java:433)
at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:
237)
at
com.redhat.rhn.frontend.struts.RhnRequestProcessor.process(RhnRequestPro
cessor.java:82)
at
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
at
org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:269)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:188)
at
com.redhat.rhn.frontend.servlets.AuthFilter.doFilter(AuthFilter.java:101
)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:215)
at
org.a

[Spacewalk-list] Assigning a base channel internal error (updated to 1.4-rc) RE: WAS RHN Traceback - violates unique constraint"rhn_sp_snep_uq"

2011-04-12 Thread Flaherty, Patrick
> > Sent: Tuesday, April 05, 2011 5:11 AM
> > On Fri, Mar 25, 2011 at 05:46:01PM -0400, Flaherty, Patrick wrote:
> > >  After switching over to the postgres backend, I'm occasionally
> > getting
> > > the following traceback when attempting to change a single host's
> > > channel assignment. The browser hangs and finally returns a 500.
> The
> > > system shows iowaits in the 40s to 90s before I get the 500, and
> then
> > > the iowaits return to normal when the 500 comes back.
> > >
> > > So, since it says:
> > >  IntegrityError: duplicate key value violates unique constraint
> > > "rhn_sp_snep_uq"
> > >
> > > Should I be investigating the iowaits, or the unique constraints
> > error?
> >
> > Can you be more specific about the actions that you do? You say
> > "attempting to change a single host's channel assignment" but the
> > traceback is from the server handler of registration code which is
> > no longer used by the latest RHN client tools / yum-rhn-plugin.
> >
> > Is the attempt to change channel some rhnreg_ks with activation key,
> > or what exactly do you (knowingly) call? Is the list of the packages
> > in /var/log/up2date? You might need to bump up the debug option in
> > /etc/sysconfig/rhn/up2date to see the packages listed there.
> 
> This install of spacewalk has been around for a couple years. We
> started
> with one of the early 0. releases (maybe 0.5?), and have been
upgrading
> in place whenever a new release comes out since then. Could there be
> cruft and code / database entries that need to be purged?
> 
> Steps to reproduce:
> * Open browser, navigate to spacewalk web interface
> * Login
> * Click systems
> * Click host
> * Click "Alter Subscriptions"
> * Receive 500 and a traceback.
> 
> The traceback I received today when doing those step was *not* the one
> with the uniq_key_restraint error. It could be that I had older
> spacewalk clients checking in/registering around the same time as I
got
> the 500 last time and mixed up the tracebacks. I've included today's
> traceback. There are also a few systems that cause rhn tracebacks when
> they check in, I'll send in a separate email / thread for those.
> 
> Patrick

I updated to 1.4-rc to see if my alter base subscription problem went
away. I'm still getting the 500 error message. I also get the error if I
use the SSM. Using the SSM used to work, but no longer does.

Postgres backend, 1.4rc, on centos 5.6 i386.

Steps to reproduce:
 * Open browser, navigate to spacewalk web interface
 * Login
 * Click systems
 * Click host (freshly registered)
 * Click "Alter Subscriptions"
 * Select Base Channel, click confirm
 * Next page, click Modify Base Software Channel
 * Internal server error.

Steps to reproduce(ssm):
 * Open browser, navigate to spacewalk web interface
 * Login
 * Click systems
 * Check host (freshly registered)
 * Click manage
 * Click manage channel memberships
 * Select Base Channel, click confirm
 * Next page, click "Base Channel"
 * Highlight Appropriate channel and check Alter subscriptions
 * Next Page, click Alter subscriptions 
 * Internal server error.

Patrick

The following exception occurred while executing this request:
POST /rhn/systems/details/SystemChannels.do

Date:4/12/11 4:15:35 PM EDT
Headers:
  host: my-spacewalk.local
  user-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13)
Gecko/20101209 CentOS/3.6-2.el5.centos Firefox/3.6.13
  accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
  accept-language: en-us,en;q=0.5
  accept-encoding: gzip,deflate
  accept-charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
  Keep-Alive: 115
  connection: keep-alive
  referer:
https://my-spacewalk.local/rhn/systems/details/SystemChannels.do?sid=100
0011747
  cookie: JSESSIONID=E25C3C1A68D3D7B7D2FCB79576B9EB98;
pxt-session-cookie=8307x035cb3b3dc53f894c0feb56921a74995
  content-type: application/x-www-form-urlencoded
  content-length: 76

Request:
Local Name = my-spacewalk.local
Server Name = my-spacewalk.local Requested Session Id came from Cookie
Requested Session Valid = true Session =
org.apache.catalina.session.StandardSessionFacade@18aa90a[session=Standa
rdSession[E25C3C1A68D3D7B7D2FCB79576B9EB98]]
Protocol = https
Request Locale = en_US
Request Character Encoding = UTF-8
Attribute Names = rhnActiveLang, javax.servlet.request.ssl_session,
org.apache.struts.action.MESSAGE,
javax.servlet.jsp.jstl.fmt.timeZone.request, systemChannelsForm,
session, javax.servlet.request.key_size, __sitemesh__filterapplied,
javax.servlet.request.cipher_suite, requestedUri,
org.apache.struts.action.mapping.instance,
org.apache.struts.a

Re: [Spacewalk-list] Assigning a base channel internal error (updatedto 1.4-rc) RE: WAS RHN Traceback - violates uniqueconstraint"rhn_sp_snep_uq"

2011-04-29 Thread Flaherty, Patrick
> > > Sent: Tuesday, April 05, 2011 5:11 AM
> > > On Fri, Mar 25, 2011 at 05:46:01PM -0400, Flaherty, Patrick wrote:
> > > >  After switching over to the postgres backend, I'm occasionally
> > > getting
> > > > the following traceback when attempting to change a single
host's
> > > > channel assignment. The browser hangs and finally returns a 500.
> > The
> > > > system shows iowaits in the 40s to 90s before I get the 500, and
> > then
> > > > the iowaits return to normal when the 500 comes back.
> > > >
> > > > So, since it says:
> > > >  IntegrityError: duplicate key value violates unique constraint
> > > > "rhn_sp_snep_uq"
> > > >
> > > > Should I be investigating the iowaits, or the unique constraints
> > > error?
> > >
> > > Can you be more specific about the actions that you do? You say
> > > "attempting to change a single host's channel assignment" but the
> > > traceback is from the server handler of registration code which is
> > > no longer used by the latest RHN client tools / yum-rhn-plugin.
> > >
> > > Is the attempt to change channel some rhnreg_ks with activation
> key,
> > > or what exactly do you (knowingly) call? Is the list of the
> packages
> > > in /var/log/up2date? You might need to bump up the debug option in
> > > /etc/sysconfig/rhn/up2date to see the packages listed there.
> >
> > This install of spacewalk has been around for a couple years. We
> > started
> > with one of the early 0. releases (maybe 0.5?), and have been
> upgrading
> > in place whenever a new release comes out since then. Could there be
> > cruft and code / database entries that need to be purged?
> >
> > Steps to reproduce:
> > * Open browser, navigate to spacewalk web interface
> > * Login
> > * Click systems
> > * Click host
> > * Click "Alter Subscriptions"
> > * Receive 500 and a traceback.
> >
> > The traceback I received today when doing those step was *not* the
> one
> > with the uniq_key_restraint error. It could be that I had older
> > spacewalk clients checking in/registering around the same time as I
> got
> > the 500 last time and mixed up the tracebacks. I've included today's
> > traceback. There are also a few systems that cause rhn tracebacks
> when
> > they check in, I'll send in a separate email / thread for those.
> >
> > Patrick
> 
> I updated to 1.4-rc to see if my alter base subscription problem went
> away. I'm still getting the 500 error message. I also get the error if
> I
> use the SSM. Using the SSM used to work, but no longer does.
> 
> Postgres backend, 1.4rc, on centos 5.6 i386.
> 
> Steps to reproduce:
>  * Open browser, navigate to spacewalk web interface
>  * Login
>  * Click systems
>  * Click host (freshly registered)
>  * Click "Alter Subscriptions"
>  * Select Base Channel, click confirm
>  * Next page, click Modify Base Software Channel
>  * Internal server error.
> 
> Steps to reproduce(ssm):
>  * Open browser, navigate to spacewalk web interface
>  * Login
>  * Click systems
>  * Check host (freshly registered)
>  * Click manage
>  * Click manage channel memberships
>  * Select Base Channel, click confirm
>  * Next page, click "Base Channel"
>  * Highlight Appropriate channel and check Alter subscriptions
>  * Next Page, click Alter subscriptions
>  * Internal server error.
> 
> Patrick
> 
> The following exception occurred while executing this request:
> POST /rhn/systems/details/SystemChannels.do
> 
> Date:4/12/11 4:15:35 PM EDT
> Headers:
>   host: my-spacewalk.local
>   user-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13)
> Gecko/20101209 CentOS/3.6-2.el5.centos Firefox/3.6.13
>   accept:
> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>   accept-language: en-us,en;q=0.5
>   accept-encoding: gzip,deflate
>   accept-charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>   Keep-Alive: 115
>   connection: keep-alive
>   referer:
> https://my-
> spacewalk.local/rhn/systems/details/SystemChannels.do?sid=100
> 0011747
>   cookie: JSESSIONID=E25C3C1A68D3D7B7D2FCB79576B9EB98;
> pxt-session-cookie=8307x035cb3b3dc53f894c0feb56921a74995
>   content-type: application/x-www-form-urlencoded
>   content-length: 76
> 
> Request:
> Local Name = my-spacewalk.local
> Server Name = my-spacewalk.local Requested Session Id came from Cookie
> Requested Session Valid = true Session =
&g