Hi,

It seems centos/httpd:latest doesn't set SSLSessionCache. But the official document states no cache hurt performance:

none
This disables the global/inter-process Session Cache. This will incur a noticeable speed penalty and may cause problems if using certain browsers, particularly if client certificates are enabled. This setting is not recommended.

Would enabling this a necessary and a quick way to improve performance?

Best,
-CC

The image is currently using ruby 2.3 which is EOL. We should update to 2.5.5 or later (2.5.5 is what container-ruby is currently at).

Maybe we should also change to run ruby-install with --system (just like ManageIQ/manageiq-appliance-build#234)?

With mod_auth_openidc v2.4.9.4 we're receiving the following warning:

[Fri Mar 31 22:45:43.989302 2023] [auth_openidc:warn] [pid 1:tid 140146011806016] oidc_check_config_oauth: The OAuth 2.0 Resource Server functionality is deprecated and superseded by a new module, see: https://github.com/zmartzone/mod_oauth2!

Similar to ManageIQ/container-httpd-init#1

Thanks for providing the container! I have a question about one httpd config:AuthnCacheContext.
It seems the official document recommends to change the default directory, which is conservative and not optimal. A better policy is to name the AuthnCacheContext for the password provider: for example a htpasswd file or database table.

Maybe it's better to set that to specify a context string for use in the cache keyin the comfig file? Thanks.

Rework done to run as unprivileged user is much appreciated.

Sample templates for manageiq-pods in Ivanchuk release refer to docker.io/manageiq/httpd:latest and httpd pod fails to start (in openshift).

Is it possible to provide compatibility with Ivanchuk release or get guidance on how to make it work?

Many thanks in advance for your help!

From what I can tell, this can't be done in a pure Dockerfile, so we'll have to do that in a bin/build script. As such, I don't know if this can be done automatically with dockerhub builds.

Currently it's LABEL name="manageiq-apache"
https://github.com/ManageIQ/container-httpd/blob/master/Dockerfile#L6-L14

my httpd pod is failing (never starts). contents of journalctl -xe inside the httpd container

Sep 10 12:52:58 httpd-1-x08c9 systemd[1]: Failed to load environment files
: No such file or directory
Sep 10 12:52:58 httpd-1-x08c9 systemd[1]: httpd.service failed to run 'sta
rt' task: No such file or directory
Sep 10 12:52:58 httpd-1-x08c9 systemd[1]: Failed to start The Apache HTTP
Server.-
-- Subject: Unit httpd.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit httpd.service has failed.
--
-- The result is failed.
Sep 10 12:52:58 httpd-1-x08c9 systemd[1]: Unit httpd.service entered faile
d state.
Sep 10 12:52:58 httpd-1-x08c9 systemd[1]: httpd.service failed.

note: this is a duplicate of ManageIQ/manageiq-pods#215; however as I'm unsure whether the issue resides in the container itself or its configuration via the miq-template, I've put it in both places.

@miq-bot add_label bug

What steps did you take and what happened:
[A clear and concise description of what the bug is.]

[root@gyliu-ocp-1-inf deploy]# oc exec httpd-579bfdf9d5-dn4lz -- ps -eaf
time="2020-05-02T05:04:22Z" level=error msg="exec failed: container_linux.go:349: starting container process caused \"exec: \\\"ps\\\": executable file not found in $PATH\""
exec failed: container_linux.go:349: starting container process caused "exec: \"ps\": executable file not found in $PATH"
command terminated with exit code 1

I recalled I can use ps to check the process in httpd container.

FYI @carbonin @Fryguy @chessbyte

What did you expect to happen:

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Environment:

• ManageIQ version:
• Minikube/KIND/OCP version:
• Kubernetes version: (use kubectl version):
• OS (e.g. from /etc/os-release):

This issue was moved to this repository from ManageIQ/manageiq-pods#480, originally opened by @gyliu513

The Dockerfile has x86_64 references and currently fails at

Proposed Solution
We can probably have ARCH as a build-arg defaulting to x86_64.

also, this image is based on ubi:8.1, should it be updated to use ubi8.2 with centos-8 repositories like say
https://github.com/ManageIQ/manageiq-pods/blob/d479be07d23825f183f4c8b3416ee4a847239bbf/images/manageiq-base/Dockerfile#L48