Greetings,
We have OOD 3.1.X running on a RHEL 9 server, and it was working fine until a couple of weeks ago. Now when we go to the landing page, we get an http error 500. The OnDemand logs do not detect any errors, but the httpd error log shows a single error for every attempt:
lua error: /opt/ood/mod_ood_proxy/lib/ood/user_map.lua:12 bad argument #1 to match (string expected, got nil)
Your assistance is much appreciated.
What auth are you using? Potentially sounds like your auth mechanism is not passing anything back to OOD.
I agree. If you’re using OIDC it’s the oidc_remote_user_claim setting that’s telling your OIDC system what to pass back (i.e., what claim to pass back to apache as the REMOTE_USER).
I tried basic and then I tried none for authentication as I suspected that this could be an issue, and both are throwing the same error. We have an OOD cluster on the “public” network, and the CAS authentication is working like a charm on there because our Center has a central LDAP authentication server that we’re leveraging. The OOD node that has the lua error is on a private network, and we haven’t worked up a secure authentication scheme for it yet.
Did you set user_env in ood_portal.yml? This also controls the CGI environment variable that holds the authenticated user name used as the argument for the user mapping command.
I did not. I’m not on-site to try it today, but I can set it tomorrow and let you know. Although I’m not sure what to set it to! Your documentation has “OIDC_CLAIM_preferred_username”, but I don’t know what that does.
You shouldn’t set it to anything if you haven’t already. Can you share your ood_portal.yml configurations?
I’m removing the domains for security reasons. I believe that this is how it looks like, but I will double check for typing errors tomorrow:
---
servername: gauss.xxx.xxx.xxxx.xxx
ssl:
- ‘SSLCertificateFile “/etc/pki/tls/certs/gauss-server.crt”’
- ‘SSLCertificateKeyFile “/etc/pki/tls/private/gauss-server-nopass.key”’auth:
- ‘AuthType None’
- ‘Require All Granted’
- ‘Satisfy Any’host_regex: ‘[\w.-]+.xxx.xxx.xxxx.xxx’
node_uri: ‘/node’
rnode_uri: ‘/rnode’
lol - AuthType None is your issue. If you can directly login without providing credentials - how’s the system know who you are?
It wasn’t working with the basic authentication either, where I was being prompted to enter a username and password at login (browser). I do not remember the configuration file off the top of my head. I will edit ood_portal.yml tomorrow to go back to the basic password authentication and upload it here
Updated ood_portal.yml back to previous configuration. Here is the Authentication section:
- ‘AuthType Basic’
- ‘AuthBasicProvider file anon’
- ‘AuthUserFile “/etc/htpasswd/.htpasswd”’
- ‘Anonymous_NoUserID off’
- ‘Require valid-user’
- ‘Require user gistambo’
- ‘AuthName “Password Authentication”’
We still see an http 500 error, but is now different than before in the logs:
[proxy:warn] [pid 171014:tid:17113] [client 140.xxx.xxx.xxx:56283] AH01144: No protocol handler was valid for the URL /pun/sys/dashboard (scheme ‘unix’). If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.
Note that the client IP above is the (right) address of the remote terminal that’s making the request.
There is another lua message (at the info level, not an error) below that error with more information, but since I can’t copy and paste from an isolated network, typing that message here would take up a lot of time.
The loaded proxy modules in Apache are:
proxy_module (shared)
proxy_ajp_module (shared)
proxy_balancer_module (shared)
proxy_connect_module (shared)
proxy_express_module (shared)
proxy_fcgi_module (shared)
proxy_fdpass_module (shared)
proxy_ftp_module (shared)
proxy_http_module (shared)
proxy_hcheck_module (shared)
proxy_scgi_module (shared)
proxy_uwsgi_module (shared)
proxy_wstunnel_module (shared)
proxy_http2_module (shared)
Let me know if you want me to start a new thread since this is a different error.
What version of OOD specifically are you on? We’ve had a whole kerfuffle with httpd recently over this very issue. 3.1.9 (or 10) should fix this error.
It was 3.1.7. Updating it yesterday night to 3.1.10 fixed the issue.
Thanks for the quick responses. You can close this ticket.