Apache not forwarding localhost://rpc/api queries to tomcat #9543
Replies: 2 comments
-
|
Ran httpd manually/interactively and got Which seems at first glance to pretty much confirm that's the problem, leaving the question of why is apache httpd looking for the module under /srv/www/modules? However, the other working server reports the exact same error running httpd interactively. So how does one succeed and yet another fails? |
Beta Was this translation helpful? Give feedback.
-
|
OK, there is definitely something wrong with the post-migration configuration on this system. It's gone through two container upgrades and still having these issues. Some more data points:
The properly functioning Uyuni system shows those starts and stop, but with the stops succeeding. The stuff about machine slices and cgroups in the service status output seems to confirm that there's something seriously wrong with the container, which somehow isn't getting fixed by the upgrade. I have no understanding of what cgroups and inotices are except that they have something to do with docker/podman. I am seriously out of my depth here and have no idea how to fix this. I'm not seeing any SELinux errors in the audit log, so it seems unlikely to be due to that. Any idea on how to narrow down what could be going wrong here? We no longer have the original non-container installation, so re-doing the migration isn't an option. Any suggestions on how to fix this? |
Beta Was this translation helpful? Give feedback.
-
After the container migration of our two Uyuni servers, one works fine and the other has issues with spacecmd and with cobbler back-authentication through the rpc/api URL. I discussed this in this post and others after it in the general migration documentation discussion.
I'm still having the problem. It appears that the issue is with the Apache URL rewrite rules not properly redirecting to tomcat.
spacecmd's error is
ERROR: Failed to connect to http://localhost/rpc/apiWhen I look at the cobbler log it says
and doing a
curl http://localhost:/rpc/apireturnsI've also confirmed that the tomcat log doesn't show rpc/api references so the calls aren't getting that far and the apache log is full of
with my curl command also showing up.
/var/log/apache2/access_log:::1 - - [05/Dec/2024:13:38:38 +0000] "GET /rpc/api HTTP/1.1" 404 - "-" "curl/8.6.0"It looks like that URL should be getting handled in zz-spacewalk-www.conf with the third RewriteRule in this section
and the last rewriterule in this block lower down
Tomcat is listening on port 8009 for AJP, so the above rewriterules have got to be failing.
The only thing I can think of is that the proxy_ajp module in Apache isn't working or isn't loading so that block of rules isn't executed.
/etc/apache2/sysconfig.d/loadmodule.conf contains a loadmodule line for it though
LoadModule proxy_ajp_module /usr/lib64/apache2-prefork/mod_proxy_ajp.so
If I grep the apache error log I get different errors over time, starting with
then
and nothing after Oct07.
On startup, the Apache2 error log shows
but I don't think that's relevant, although it probably wouldn't be a bad thing to have the default config files not result in those being thrown.
Any idea what could be going wrong with proxy_ajp and how I go about fixing it? We started container migration with 2024.08 and since upgraded to the 2024.10 container. Thus, if it was an issue with the executable in the container image, I would think it would have been replaced by the upgrade, and not stick through it.
Beta Was this translation helpful? Give feedback.
All reactions