Getting started, after initial OOD installations

Dear all,
I installed OOD and followed up with the Apache module installations. I modified the “/etc/ood/config/ood_portal.yml” file’s initial few lines to:
servername: desired_server_name

  - 'SSLEngine on'
  - 'SSLCertificateFile "/etc/pki/tls/certs/*certificate_file*"'
  - 'SSLCertificateKeyFile "/etc/pki/tls/private/*key_file*"'

But rest all lines are commented out I believe with “#” in front of them.
I am now facing an issue of “Internal Server Error” and not able to see a basic portal page.
One other aspect is that I have Rocky 8.4 in the system and httpd -v gives me:
Server version: Apache/2.4.37 (rocky)
But I don’t have httpd24 as a directory or service separately.
I saw this issue:

but I’m not sure what the specifics of this part of the /etc/ood/config/ood_portal.yml file would be. The link above suggests:

  -'AuthType Basic'
  -'AuthName "OnDemand"'
  -'AuthUserFile "/opt/rh/httpd24/root/etc/httpd/.htpasswd"'
  -'Require valid-user'

but as I mentioned I don’t have the httpd24 service separately.
Any thought on this would help.
Thank you.


Thanks for your post. What do your apache logs show? Should be under /var/log/httpd/errors.log


Dear Gerald,
These are the logs from yesterday: I can tell something’s amiss, either an extra step that I missed or some line I needed to comment in from the /etc/ood/config/ood_portal.yml but forgot.

[Mon Mar 27 12:26:36.590071 2023] [mpm_event:notice] [pid 3898:tid 140590812453184] AH00491: caught SIGTERM, shutting down
[Mon Mar 27 12:26:37.192274 2023] [core:notice] [pid 1598530:tid 139632233351488] SELinux policy enabled; httpd running as context system_u:system_r:httpd_t:s0
[Mon Mar 27 12:26:37.193373 2023] [suexec:notice] [pid 1598530:tid 139632233351488] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
AH00016: Configuration Failed
[Mon Mar 27 14:00:01.643141 2023] [core:notice] [pid 1599216:tid 140170128566592] SELinux policy enabled; httpd running as context system_u:system_r:httpd_t:s0
[Mon Mar 27 14:00:01.644301 2023] [suexec:notice] [pid 1599216:tid 140170128566592] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
AH00016: Configuration Failed
[Mon Mar 27 14:20:02.046995 2023] [core:notice] [pid 1686956:tid 140013054990656] SELinux policy enabled; httpd running as context system_u:system_r:httpd_t:s0
[Mon Mar 27 14:20:02.048137 2023] [suexec:notice] [pid 1686956:tid 140013054990656] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
AH00016: Configuration Failed
[Mon Mar 27 14:22:10.590632 2023] [core:notice] [pid 1687053:tid 140012892027200] SELinux policy enabled; httpd running as context system_u:system_r:httpd_t:s0
[Mon Mar 27 14:22:10.591671 2023] [suexec:notice] [pid 1687053:tid 140012892027200] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Mon Mar 27 14:22:10.615136 2023] [lbmethod_heartbeat:notice] [pid 1687053:tid 140012892027200] AH02282: No slotmem from mod_heartmonitor
[Mon Mar 27 14:22:10.619301 2023] [mpm_event:notice] [pid 1687053:tid 140012892027200] AH00489: Apache/2.4.37 (rocky) OpenSSL/1.1.1k configured -- resuming normal operations
[Mon Mar 27 14:22:10.619333 2023] [core:notice] [pid 1687053:tid 140012892027200] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'

And these are a few lines from today:

[Tue Mar 28 09:59:35.337283 2023] [core:error] [pid 1687055:tid 140011353659136] [client] AH00126: Invalid URI in request GET /../../../../../../../../../../../ HTTP/1.1
[Tue Mar 28 09:59:44.325105 2023] [core:error] [pid 1687409:tid 140010674177792] [client] AH00126: Invalid URI in request GET mediawiki-1.16.0beta2 HTTP/1.0
[Tue Mar 28 09:59:44.326043 2023] [core:error] [pid 1687409:tid 140012197431040] [client] AH00126: Invalid URI in request GET bad397 HTTP/1.0
[Tue Mar 28 09:59:46.915465 2023] [core:error] [pid 1687056:tid 140011840206592] [client] AH00126: Invalid URI in request GET \\ HTTP/1.0
[Tue Mar 28 09:59:47.284141 2023] [core:error] [pid 1687056:tid 140012222609152] [client] AH00126: Invalid URI in request GET CMS/ HTTP/1.0
[Tue Mar 28 09:59:47.285187 2023] [core:error] [pid 1687057:tid 140012205823744] [client] AH00126: Invalid URI in request GET bad397/ HTTP/1.0
[Tue Mar 28 09:59:47.286528 2023] [core:error] [pid 1687057:tid 140012214216448] [client] AH00126: Invalid URI in request GET cms/ HTTP/1.0
[Tue Mar 28 09:59:47.625830 2023] [core:error] [pid 1687055:tid 140011328481024] [client] AH00126: Invalid URI in request GET boards/ HTTP/1.0
[Tue Mar 28 09:59:47.710022 2023] [core:error] [pid 1687409:tid 140012231001856] [client] AH00126: Invalid URI in request GET /servlet/com.livesoftware.jrun.plugins.ssi.SSIFilter/../../

Can you please disable SELinux and firewalld? Let’s see what that does, please.

I don’t recognize any of those GET Paths. Is your server used for more than Open OnDemand?


Dear Gerald,
We use our server exclusively for OOD. I was surprised too regarding the GET commands.
By the way, I don’t have authentication setup yet. Do you think I should try setup a basic authentication first then disable SELinux and firewall ?
Thank you.

Those requests look like a malicious attacker. I’d keep selinux enabled and firewalld up just because it looks like you’re already under attack.

At glance, you likely have this misconfiguration -

-'AuthUserFile "/opt/rh/httpd24/root/etc/httpd/.htpasswd"'

It should likely be and you may have to issue some commands to initialize it.

-'AuthUserFile "/etc/httpd/.htpasswd"'

That said - I’d say this: basic auth is very insecure. Given that you’re already under attack from someone, I’d suggest adding SSL and a better authentication scheme (OIDC if you have it or your campus Shibboleth or similar) ASAP.

If you reconfigure using the suggestion above and still have issues, I’d also like to see the error messages in the logs from your 500s. They should be in /var/log/httpd/<desired_server_name>_error.log

Although this message AH00016: Configuration Failed is important and indeed may indicate what I’ve indicated above.

This command may tell you more about a configuration error.

sudo /sbin/httpd -S

Dear Jeff,

Thanks for your response.

I used the 2nd line in the /etc/ood/config/ood_portal.yml file:

-'AuthUserFile "/etc/httpd/.htpasswd"'

That gives the following messages in /var/log/httpd/ondemand.hpcc.ttu.edu_error_ssl.log

[Tue Apr 04 10:19:19.874167 2023] [ssl:error] [pid 508526:tid 140194393069312] [client] AH02031: Hostname provided via SNI, but no hostname provided in HTTP request
[Tue Apr 04 10:19:26.236099 2023] [ssl:error] [pid 508525:tid 140194619574016] [client] AH02031: Hostname provided via SNI, but no hostname provided in HTTP request

Also the file /var/log/httpd/ssl_error_log explains the same situation of hostname mismatch
[Tue Apr 04 09:55:31.180106 2023] [ssl:error] [pid 685679:tid 140194275636992] [client] AH02032: Hostname provided via SNI and hostname provided via HTTP have no compatible SSL setup

What I did for the SSL certificate request was a Multi domain request from InCommon. I wanted the server name to be different than the website name. Do you think there might be a problem in my approach there ?

And the output of the command

sudo /sbin/httpd -S

on our ondemand server is the following:

[root@oodheadnode ~]# /sbin/httpd -S
VirtualHost configuration:
*:80          (/etc/httpd/conf.d/ood-portal.conf:46)
*:443                  is a NameVirtualHost
         default server (/etc/httpd/conf.d/ood-portal.conf:53)
         port 443 namevhost (/etc/httpd/conf.d/ood-portal.conf:53)
         port 443 namevhost (/etc/httpd/conf.d/ssl.conf:40)
ServerRoot: "/etc/httpd"
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/etc/httpd/logs/error_log"
Mutex authdigest-opaque: using_defaults
Mutex watchdog-callback: using_defaults
Mutex proxy-balancer-shm: using_defaults
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
Mutex authdigest-client: using_defaults
Mutex lua-ivm-shm: using_defaults
Mutex ssl-stapling: using_defaults
Mutex proxy: using_defaults
Mutex ldap-cache: using_defaults
Mutex authn-socache: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/etc/httpd/run/" mechanism=default
Mutex cache-socache: using_defaults
PidFile: "/etc/httpd/run/"
User: name="apache" id=48
Group: name="apache" id=48

What’s the URL you’re trying to connect to in your browser? Are you trying to use the IP in your browser?

From a google search, that issue AH02031 seems to indeed be an SSL negotiation error. I’m not sure if you can have a servername that differs from the website name. That’s very much an apache thing to determine how to route requests because one apache can serve requests many websites.

That is, you can have an internal hostname, that differs, that’s fine. But external DNS entries need to point to that hostname.

That is - needs to be a valid DNS entry and needs to be the servername and needs to be the URL you supply in the browser. The actual server can have an internal hostname of, but you need a DNS record that maps the external hostname to the internal host. Your certificates should be able to respond to the external hostname

Though @tdockendorf may know more/spot something that I didn’t see/correct me.

Dear Jeff,
Thanks for pointing that out. What do you think is a prudent way to resolve the issue of 1) website name 2) DNS entry and 3) server name too ?

May I say this that the outputs of
nslookup and
are exactly the same except

Non-authoritative answer: canonical name =

for the first one and a blank for the second one.


It seems to me that is the external name and should be all 3 you mention there. is the internal name, something only your administrators (or you) care about (when they actually shell into it or need to update it).

That is - it seems to me that your users will be interacting with for no other reason than it looks nicer/more appealing than the other. I’m pretty sure that’s the only reason to make a DNS entry - to give a server a prettier name than the internal one.

Hi Jeff,
Apologies, I missed your previous question. The website name I am trying to connect to is: and I wasn’t using the IP address. I was directly using the web address.

You are right. That is indeed the one the users would interact with.
So change the hostname, get a new SSL certificate and then resume the process right ?

Thank you.

The hostname Apache is configured to use needs to be external name and the cert needs to be valid for that external name. You can use cert AltNames to have multiple names be valid and ServerAlias in Apache can allow additional names to be responded to by Apache. The aliases in ood_portal are server_aliases which is an array of additional names.

Other parts of thread mentioned using BasicAuth with htpasswd file. I’d very strongly recommend against doing that on anything that is facing the internet or consumed by actual users as it’s incredibly insecure.

Thank you for your response.

  • We used the following command
    openssl req -new -nodes -sha256 -newkey rsa:4096 -keyout -out -days 356 -subj “/C=US/ST=Texas/L=Lubbock/O=Texas Tech University/” -addext “subjectAltName =,”
    for generating the SSL certificate request file.

  • Do you think I could go ahead and take care of the authentication (our university prefers Shibboleth is what we were last told) and then deal with the SSL certificate error if any ?


Regarding this, I had one more question.
Does one require only Apache service and configuration of the ood_portal.yml file or also the nginx_stage.yml in addition to that ?

Thank you.