The cluster uses NIS, so there’s nothing on /etc/passwd for it to consume via PAM, that’s why I left it with a htaccess file for now. I KNOW it’s insecure.
Error -- failed to map user (strube1)
strube1 is a valid user on the machine.
I set the lua log level to debug, because I didn’t get any other output.
Now I get this:
[Thu Mar 23 18:32:25.803935 2023] [auth_openidc:warn] [pid 3879689:tid 139634022960192] oidc_check_config_openid_openidc: the URL scheme (http) of the configured OIDCProviderMetadataURL SHOULD be "https" for security reasons!
[Thu Mar 23 18:32:25.803975 2023] [auth_openidc:warn] [pid 3879689:tid 139634022960192] oidc_check_config_openid_openidc: the URL scheme (http) of the configured OIDCRedirectURI SHOULD be "https" for security reasons (moreover: some Providers may reject non-HTTPS URLs)
[Thu Mar 23 18:32:36.011360 2023] [lua:debug] [pid 3879693:tid 139633971255040] @/opt/ood/mod_ood_proxy/lib/ood/user_map.lua(21): [client 134.94.52.183:61151] Mapped 'strube1' => '' [0.006 ms]
[Thu Mar 23 18:32:36.011363 2023] [lua:debug] [pid 3879693:tid 139633971255040] lua_request.c(1867): [client 134.94.52.183:61151] AH01488: request_rec->dispatching user -> string
[Thu Mar 23 18:32:36.011368 2023] [lua:debug] [pid 3879693:tid 139633971255040] lua_request.c(1858): [client 134.94.52.183:61151] AH01487: request_rec->dispatching write -> lua_CFunction
[Thu Mar 23 18:32:36.011667 2023] [lua:debug] [pid 3879693:tid 139633971255040] lua_request.c(1848): [client 134.94.52.183:61151] AH01486: request_rec->dispatching subprocess_env -> apr table
[Thu Mar 23 18:32:36.011675 2023] [lua:debug] [pid 3879693:tid 139633971255040] lua_request.c(1848): [client 134.94.52.183:61151] AH01486: request_rec->dispatching subprocess_env -> apr table
[Thu Mar 23 18:32:36.011702 2023] [lua:debug] [pid 3879693:tid 139633971255040] lua_request.c(1848): [client 134.94.52.183:61151] AH01486: request_rec->dispatching subprocess_env -> apr table
Ok for whatever reason this user_map_match: '.*' was never sent to the apache configuration!
The ood_portal.yml has
# Lua regular expression used to map authenticated-user to system-user
# This configuration is ignored if user_map_cmd is defined
# Example:
#user_map_match: '^([^@]+)@.*$'
# Default: '.*'
user_map_match: '.*'
but the apache conf file ends with the more complicated default scheme, somehow.
If I force the change on the apache’s config, it works. If I re-generate it, I get again the
SetEnv OOD_USER_MAP_MATCH "^([^@]+)@.*$" on ood-portal.conf
I want to make sure I understand the sequence. After making the changes to the ood_portal.yml you issued the update_ood_portal command and restarted apache and OOD and the setting for the user_map_match never shows up?
Do you have ondemand-dex installed? If we notice that this package is available in 2.0 we force some defaults, like user_map_match. I ask because your logs also output some auth_openidc:warn messages which imply that your using OIDC auth and not basic (another default we’re forcing because of dex).
If you have ondemand-dex installed and don’t wish to use it, then remove it and bounce httpd and check ood-portal.conf to see the correct things being populated.
That’s what comes by following the instructions for using Ubuntu:
ii ondemand 2.0.31 amd64 Open OnDemand is an open source release of the Ohio SuperComputer Center's
ii ondemand-dex 2.32.0 amd64 OnDemand Dex
ii ondemand-nginx 1.18.0 amd64 A high performance web server and reverse proxy server
ii ondemand-passenger 6.0.14 amd64 Phusion Passenger application server for OnDemand
ii ondemand-release-web 2.0.1 all OnDemand repo release files for 2.0 web repo
I want to use dex later, but I wanted first to have it running “single-user” so to speak - more than anything, to show a working prototype to the boss before putting work and making it into production.
And you are correct - by removing this package, it now works as intended. Should I submit a bug report?