[Spacewalk-list] yup update/install gives 404 error

[Michael Mraka]

Clouse, Raymond:
> We're having a vexing issue with a new Spacewalk 2.6 installation.

Hello Raymond,

Is there a specific reason why to use Spacewalk 2.6 and not the latest 2.7?

> We've made it a slave to a master (security reasons; only one SW is exposed to the Internet) and have everything synchronized and communicating successfully.  But when we try to do an update or install with yum, we get a 404 error like this:
> 
> Error downloading packages:
>   nss-tools-3.28.4-8.el7.x86_64: failed to retrieve getPackage/nss-tools-3.28.4-8.el7.x86_64.rpm from our_repo
> 
> I find errors get logged in /var/log/httpd/error_log simultaneously like this:
> 
> [Mon Dec 18 20:02:31.638648 2017] [:error] [pid 53696] Spacewalk 53696 2017/12/18 20:02:31 +01:00: WARNING: log path not found; attempting to create /var/log/rhn
> [Mon Dec 18 20:02:31.638680 2017] [:error] [pid 53696] Spacewalk 53696 2017/12/18 20:02:31 +01:00: (None, None)
> [Mon Dec 18 20:02:31.638810 2017] [:error] [pid 53696] Spacewalk 53696 2017/12/18 20:02:31 +01:00: ERROR: unable to create log file path /var/log/rhn
> [Mon Dec 18 20:02:31.638837 2017] [:error] [pid 53696] Spacewalk 53696 2017/12/18 20:02:31 +01:00: (<type 'exceptions.OSError'>, OSError(13, 'Permission denied'))
> 
> Of course, /var/log/rhn exists and has proper permissions.  I even set permissions to 777 just in case with no positive effect.

Except for standard permissions it may also mean a selinux error.
Any AVC in /var/log/audit/audit.log?

> One other possible clue: in /var/log/rhn/rhn_taskomatic_daemon.log I found this:
> 
> INFO   | jvm 1    | 2017/12/18 20:06:32 | com.mchange.v2.cfg.DelayedLogItem [ level -> FINE, text -> "The configuration file for resource identifier '/mchange-commons.properties' could not be found. Skipping.", exception -> java.io.FileNotFoundException: Resource not found at path '/mchange-commons.properties'.]
> 
> And in Googling that I found an unreplied post here that says:
> --
> Tomcat6 is having a problem finding mchange-commons when it's starting up which causes the web / api interface to fail, causing other parts of spacewalk to fail to initialize.
> 
> How / where can I get the mchange-commons installed and linked properly so that tomcat will be able to start?

I vaguely remeber there were issues with 2.6 and java package upgrades in EPEL
which moved jars from /usr/share/java to a subdirectory. And the solution
was to create symlinks back in /usr/share/java.

> --
> So, in summary:
> - Spacewalk set up as slave
> - Clients can see SW
> - SW knows which systems need upgrades
> - Upgrades or installs fail with 404 error

Regards,

--
Michael Mráka
System Management Engineering, Red Hat