[Spacewalk-list] Mr. 500 here... more info

[Máirí­n Duffy]

m.roth2006 at rcn.com wrote:
> Fascinating.
> 
> I found 
> <http://www.mail-archive.com/spacewalk-list@redhat.com/msg01001.html>.
>  In that, someone with the *same* problem as me, he suggests trying
> to browse to 
> <https://spacewalk.example.com/network/software/channels/manage/index.pxt>
> 
> 
> 
> So, on my system, I tried, and got my 500 error. Then I backed up... 
> and I can see a directory of 
> <mymachine>/network/software/channels/manage, and all the way down to
>  <mymachine>... and at that point, I get a *different* sign-in page, 
> at <mymachine>/rhn/Login.do
> 
> I just went back to com/network/software/channels/manage. If I point 
> my browser at delete_confirm.pxt, I get that. Every other .pxt there 
> gives me a 500 error.

Parts of the UI are JSPs (Java stack), parts are PXTs (perl stack). It
sounds like you're able to navigate the JSP application pages but only
one of the PXT pages. I have never gotten this problem on stable version
of Spacewalk (or Satellite for that matter) but running my own devel
version out of a repo checkout I have run into this PXTs == 500 problem 
sometimes when I'm running the app and then a change gets checked into 
one of the rhn.conf files and I pull it down. (without having it in 
front of me now, I think they are in rhn conf files in /etc/rhn or 
/etc/satellite or /etc/sysconfig/rhn, there's various PXT config 
settings to tweak in them) Usually my issue was that there is a DB 
location config line somewhere just for the PXT stack, and it'd be 
pointing to the wrong DB so I'd have to fix it. However, again, this is 
running a devel version out of checkout - never ever had an issue like 
that running a stable released version.

I seem to have missed from reading through your messages to this list 
the state the VM was in when you started installing Spacewalk onto it. 
Was it a clean install? Did it used to have some other app installed on 
it? Was it installed with @Base (I believe still the recommended 
starting point) or was more installed on it by default?

The reason I ask is because you should *never*, ever have to manually
muck around with file permissions, etc. when installing Spacewalk. Has
anyone else on the list here ever had to do this? (My guess is no.) The
installer should really handle that for you and if it didn't then
something must have gone wrong during installation or something on the
machine was not set up correctly. Whatever went wrong that caused those
permissions to not be set correctly is likely the problem, and changing
the permissions manually is really just treating the symptoms and sort
of pulling on the string sticking out of the rug and unravelling it
rather than re-weaving and fixing it ;-)

Do you remember if there were any errors or problems that occurred
during installation? E.g. maybe something took too long so you hit
Ctrl+C then came back later and restarted it? If not, since I'm not 
seeing any posts by anyone else running into this, I'm thinking there's 
some variable unqiue to your environment that is triggering this problem.

Can you post somewhere the full log that's written out during
installation? The RHN app logs (/var/log/rhn I think), the httpd logs,
and any install or other logs that cobbler may spit out? Any logs that
Oracle might spit out during the Spacewalk install? Also the first
snippet of the log you posted in your first post, mentioned it sent a
traceback to root at localhost - can you post that full traceback? Do you
see any errors that indicate perhaps the PXT stack can't correctly
contact the DB or can you see in the Oracle logs that it's receiving 
requests from the PXT stack?

DISCLAIMER: I am not a Spacewalk developer, I'm a UI designer so I
really don't know what's going on at a very deep level at all. I 
apologize if I'm belaboring the obvious. But hopefully maybe something 
I've written here might trigger something that leads to a solution.

~m