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
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:
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 129.118.5.129:55856] AH00126: Invalid URI in request GET /../../../../../../../../../../../ HTTP/1.1
[Tue Mar 28 09:59:44.325105 2023] [core:error] [pid 1687409:tid 140010674177792] [client 129.118.5.129:40758] 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 129.118.5.129:40764] 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 129.118.5.129:45944] AH00126: Invalid URI in request GET \\ HTTP/1.0
[Tue Mar 28 09:59:47.284141 2023] [core:error] [pid 1687056:tid 140012222609152] [client 129.118.5.129:46520] 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 129.118.5.129:46526] 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 129.118.5.129:46532] 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 129.118.5.129:47224] 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 129.118.5.129:47408] AH00126: Invalid URI in request GET /servlet/com.livesoftware.jrun.plugins.ssi.SSIFilter/../../
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.
Regards,
Sagnik
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.
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 129.118.5.130:33766] AH02031: Hostname 129.118.104.150 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 129.118.5.130:38808] AH02031: Hostname 129.118.104.150 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 129.118.5.130:45006] AH02032: Hostname 129.118.104.150 provided via SNI and hostname oodheadnode.hpcc.ttu.edu 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 ?
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 - ondemand.hpcc.ttu.edu 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 oodheadnode.hpcc.ttu.edu, 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 ondemand.hpcc.ttu.edu
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 ondemand.hpcc.ttu.edu and nslookup oodheadnode.hpcc.ttu.edu
are exactly the same except
Non-authoritative answer:
ondemand.hpcc.ttu.edu canonical name = oodheadnode.hpcc.ttu.edu.
It seems to me that ondemand.hpcc.ttu.edu is the external name and should be all 3 you mention there. oodheadnode.hpcc.ttu.edu 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 ondemand.hpcc.ttu.edu 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: ondemand.hpcc.ttu.edu 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 ?
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.
We used the following command
openssl req -new -nodes -sha256 -newkey rsa:4096 -keyout ondemand.hpcc.ttu.edu.key -out ondemand.hpcc.ttu.edu.csr -days 356 -subj “/C=US/ST=Texas/L=Lubbock/O=Texas Tech University/CN=oodheadnode.hpcc.ttu.edu” -addext “subjectAltName = DNS:oodheadnode.hpcc.ttu.edu,DNS:ondemand.hpcc.ttu.edu”
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 ?
Hello,
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 ?