Bug 732350

When navigating to my server I get redirected to /rhn/Login.do but am greeted with a 404 saying:

HTTP Status 404 -

type Status report

message

description The requested resource () is not available.
Apache Tomcat/6.0.32

We were able to reproduce the problem internally with Spacewalk nightly.

Tomáš, could you investigate more?

Yes, the trouble is c3p0 that is available now in F15 repo in a higher version that the package we'd like to use from jpackage repo.

The quickest workaround is to step back f.e.
# yum downgrade c3p0 -y
to use c3p0-0.9.1.2-2.jpp5 from jpackage repo.

It seem that the fedora package cannot find appropriate logger ...
java.lang.ClassNotFoundException: com.mchange.v2.log.MLog

I created:
Bug 735460 - java.lang.ClassNotFoundException: com.mchange.v2.log.MLog
for c3p0 fedora 15 component.

(In reply to comment #3)
> Yes, the trouble is c3p0 that is available now in F15 repo in a higher version
> that the package we'd like to use from jpackage repo.
> 
> The quickest workaround is to step back f.e.
> # yum downgrade c3p0 -y
> to use c3p0-0.9.1.2-2.jpp5 from jpackage repo.

Can we just require (in rpm dependencies) the exact c3p0 version on Fedora 15 for now?

(In reply to comment #6)
> (In reply to comment #3)
> > Yes, the trouble is c3p0 that is available now in F15 repo in a higher version
> > that the package we'd like to use from jpackage repo.
> > 
> > The quickest workaround is to step back f.e.
> > # yum downgrade c3p0 -y
> > to use c3p0-0.9.1.2-2.jpp5 from jpackage repo.
> 
> Can we just require (in rpm dependencies) the exact c3p0 version on Fedora 15
> for now?

Actually, mchange-commons is already installed on my Fedora 15, so the trick is to do

# ln -s /usr/share/java/mchange-commons.jar /var/lib/tomcat6/webapps/rhn/WEB-INF/lib

(In reply to comment #7)
> 
> Actually, mchange-commons is already installed on my Fedora 15, so the trick is
> to do
> 
> # ln -s /usr/share/java/mchange-commons.jar
> /var/lib/tomcat6/webapps/rhn/WEB-INF/lib

And this is what I did for Fedora 15 in Spacewalk master, 5024fea0db061d82a0ba61d6b80c7843c34678b4.

Tagged as spacewalk-java-1.6.39-1.

nice work people :).  To test do I just have to enable the nightly builds as per

* https://fedorahosted.org/spacewalk/wiki/HowToInstall

(In reply to comment #9)
> nice work people :).  To test do I just have to enable the nightly builds as
> per
> 
> * https://fedorahosted.org/spacewalk/wiki/HowToInstall

Well, if you don't want to pollute your released installation with nightly bits, just do

# ln -s /usr/share/java/mchange-commons.jar /var/lib/tomcat6/webapps/rhn/WEB-INF/lib/mchange-commons.jar
# service tomcat6 restart

-- that should do the trick.

excellent.  well, i can confirm that after doing the symlink everything now works on a fresh install; including a dependency issue I used to have with tanukiwrapper which is no doubt unrelated here..

is this where I change the status of this bug to CLOSED??

(In reply to comment #11)
> excellent.  well, i can confirm that after doing the symlink everything now
> works on a fresh install; including a dependency issue I used to have with
> tanukiwrapper which is no doubt unrelated here..
> 
> is this where I change the status of this bug to CLOSED??

We will close this bugzilla once the fix is in released Spacewalk -- so far we only have it in nightly builds (and we have this manual workaround). Please leave it open, we will take care of it later.

Created attachment 521801 [details]
rhn_taskomatic_daemon.log

hmmm, well even though the installation seemed to work and I have been able to create a new channel with 3 repositories bound to it there is an issue related to the scheduler where according to spacewalk "The scheduling service appears down. Please contact your Satellite administrator.".

[root@spacewalk ~]# service taskomatic status
RHN Taskomatic is running (6632).

[root@spacewalk ~]# netstat -pant|grep task
tcp   0  0 127.0.0.1:32001  127.0.0.1:31003   ESTABLISHED 6632/taskomaticd

From looking at taskomatic's log output I noticed that it referenced "mchange", being the library I manually linked before.


For this new installation I did a dvd installation, updated, installed spacewalk as per the fedorahosted guide on to postgres and then went through the creation of channels and repos.

should I file a separate bug and if so what extra information would be required?

thanks again for your assistance

Yes, we need to add the /usr/share/java/mchange-commons.jar to taskomatic wrapper.java.classpath as well (in /etc/rhn/default/rhn_taskomatic_daemon.conf).

(I'll fix and test the change as soon as I get my F15 machine running.)

Created attachment 523466 [details]
patch for rhn_taskomatic_daemon.conf

I can confirm that including the mchange jar fixes taskomatic.  All i did was modify the conf file and restarted taskomatic.  within seconds it started working through its schedule and now all is good.

Thanks again everyone for your assistance :)

(In reply to comment #15)
> Created attachment 523466 [details]
> patch for rhn_taskomatic_daemon.conf
> 
> I can confirm that including the mchange jar fixes taskomatic.  All i did was
> modify the conf file and restarted taskomatic.  within seconds it started
> working through its schedule and now all is good.
> 
> Thanks again everyone for your assistance :)

Tomáš, is it OKay / harmless to have this patch applied even on OSes where the thing does not exist as a separate .jar?

Yes, it's safe. And also much better than to link different jars for every OS.

spacewalk.git: 2f93f6226b9634c1b1b34c86bef6ece21e342e8e

*** Bug 742576 has been marked as a duplicate of this bug. ***

Spacewalk 1.6 has been released.