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

_______________________________________________
Spacewalk-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-list

Reply via email to