OnDemand 2.0.27 New Install login failure

Kenny Hanson from Montana State University, Research Cyberinfrastructure. We’re trying to get OOD up and going for our cluster Tempest. We are using Rocky 8.6.
I used RPM install, ondemand-2.0.27-1.el8.src.rpm, and am using OnDemand Dex, ondemand-dex-2.27.0-2.el8.src.rpm, for LDAP authentication.

I’m having a devil of a time getting a simple login. Dex ldap auth is working, if I enter a bad password for my user it reports bad credentials. When I use the correct password, the web page sits there spinning for about 3-4 minutes before claiming it couldn’t find the user. I believe the user mapping is working, I turned on debug level for lua_log_level.

[Tue Aug 09 11:02:49.664923 2022] [lua:debug] [pid 36222:tid 140043994298112] @/opt/ood/mod_ood_proxy/lib/ood/user_map.lua(21): [client] Mapped 'w55c785' => 'w55c785' [0.009 ms]

There’s quite a bit of repetitive log entries then it finally ends with this:

[Tue Aug 09 11:05:01.409271 2022] [lua:debug] [pid 36222:tid 140043994298112] lua_request.c(1853): [client] AH01487: request_rec->dispatching info -> lua_CFunction
[Tue Aug 09 11:05:01.409291 2022] [lua:info] [pid 36222:tid 140043994298112] [client] req_accept="text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9" req_hostname="tempest-web.msu.montana.edu" req_content_type="" req_cache_control="" req_is_websocket="false" req_origin="" req_is_https="true" req_accept_encoding="gzip, deflate, br" req_handler="" res_location="" req_accept_language="en-us,en;q=0.9" log_id="YvKTOd4JSy7dINvefzwriAAAAIE" res_content_disp="" req_uri="/pun/sys/dashboard" req_protocol="HTTP/1.1" log_time="2022-08-09T17:05:01.408888.0Z" res_content_length="116" req_referer="" req_user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/ Safari/537.36" req_server_name="tempest-web.msu.montana.edu" local_user="w55c785" req_method="GET" time_user_map="0.009" res_content_location="" res_content_language="" req_accept_charset="" req_user_ip="" time_proxy="0" res_content_type="" req_status="404" res_content_encoding="" remote_user="w55c785" log_hook="ood" req_port="443" req_filename="/var/www/html/pun"

The web page finally displays:

Error -- can't find user for w55c785
Run 'nginx_stage --help' to see a full list of available command line options.

Here is the page produced by https://tempest-web.msu.montana.edu:5554/.well-known/openid-configuration:

  "issuer": "https://tempest-web.msu.montana.edu:5554",
  "authorization_endpoint": "https://tempest-web.msu.montana.edu:5554/auth",
  "token_endpoint": "https://tempest-web.msu.montana.edu:5554/token",
  "jwks_uri": "https://tempest-web.msu.montana.edu:5554/keys",
  "userinfo_endpoint": "https://tempest-web.msu.montana.edu:5554/userinfo",
  "device_authorization_endpoint": "https://tempest-web.msu.montana.edu:5554/device/code",
  "grant_types_supported": [
  "response_types_supported": [
  "subject_types_supported": [
  "id_token_signing_alg_values_supported": [
  "code_challenge_methods_supported": [
  "scopes_supported": [
  "token_endpoint_auth_methods_supported": [
  "claims_supported": [

I would sure appreciate some assistance or pointing in the right direction :slight_smile:

Kenny Hanson

Hi, my guess is there’s some lag/issue in your LDAP/SSSD stack. That error message is out of the Etc library which is calling these things.

irb(main):005:0>  Etc.getpwnam('joe')
Traceback (most recent call last):
        5: from /home/jeff/apps/ruby/2.7.6/bin/irb:23:in `<main>'
        4: from /home/jeff/apps/ruby/2.7.6/bin/irb:23:in `load'
        3: from /home/jeff/apps/ruby/2.7.6/lib/ruby/gems/2.7.0/gems/irb-1.2.6/exe/irb:11:in `<top (required)>'
        2: from (irb):5
        1: from (irb):5:in `getpwnam'
ArgumentError (can't find user for joe)

The question is, can that machine, the machine you’ve got OOD on, recognize the w55c785 user through su or shelling into it.

Hello Jeff,
Thanks for the prompt replay. You’re dead on. My SSSD wasn’t even configured yet. We auth against domain users ldap and then the login in verified by sssd against a private ldap. I completely forgot to set that up. Working on that now and will post results.

Thanks again!
Kenny Hanson

Got sssd configured then sssd-ldap is not a default package. I got the logins working, OOD is logging in properly. We can mark this as resolved.
Thanks for the assist, Jeff.

1 Like

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.