LDAP Import: An error occurred: undefined method `ord' for nil:NilClass

Technical assistance
1

Infos:

  • Used Zammad version: 3.3
  • Installation method (source, package, …): Official Zammad Docker-compose
  • Operating system: Debian 9
  • Database + version: Official Zammad Docker-compose
  • Elasticsearch version: Official Zammad Docker-compose
  • Browser + version: Chrome 80.0.3987.149

Expected behavior:

Successful LDAP Import without errors like in our other zammad docker instance (zammad version 3.2).

Actual behavior:

Setup LDAP Integration works fine but after that the sync produce the following error:
An error occurred: undefined method `ord’ for nil:NilClass

zammad1
zammad11569×661 75.7 KB

Log from the Docker railsserver:

I, [2020-03-24T10:29:29.435076 #1-47035551746740] INFO – : Started GET “/api/v1/integration/ldap/job_start?=1585045746323" for 10.0.0.18 at 2020-03-24 10:29:29 +0000 I, [2020-03-24T10:29:29.440955 #1-47035551746740] INFO – : Processing by Integration::LdapController#job_start_index as JSON I, [2020-03-24T10:29:29.441058 #1-47035551746740] INFO – : Parameters: {"”=>“1585045746323”} I, [2020-03-24T10:29:29.467198 #1-47035551746740] INFO – : Completed 200 OK in 26ms (Views: 0.5ms | ActiveRecord: 15.6ms)

At my logs there is not any error regarding to my problem. I only have “INFO” messages.

Our LDAP settings are correct and verified with LDAP Browser and our second zammad instance (version 3.2). We sync only 170 users. But even with the error the sync works fine. New Users will be added to the system but the warning confuses. So how can we debug the problem? Is there any console command to get more infos for the ldap integration?

Steps to reproduce the behavior:

Restart LDAP Sync or wait for scheduler

2

I found the command to start the LDAP Import from the rails console. Here is the output:

root@8ba0d3c45187:/opt/zammad# rails r ‘ImportJob.create(name: ‘Import::Ldap’).start’
I, [2020-03-24T13:09:10.371026 #625-47230543316420] INFO – : Setting.set(‘models_searchable’, [“User”, “Chat::Session”, “Organization”, “KnowledgeBase::Answer::Translation”, “Ticket”])
not verifying SSL hostname of LDAPS server ‘XXX:636’
not verifying SSL hostname of LDAPS server ‘XXX:636’
not verifying SSL hostname of LDAPS server ‘XXX:636’
not verifying SSL hostname of LDAPS server ‘XXX:636’
I, [2020-03-24T13:09:13.384335 #625-47230543316420] INFO – : Enqueued SearchIndexJob (Job ID: 563153d9-f498-4ee0-8d63-c2d84f14a412) to DelayedJob(default) with arguments: “User”, 168
I, [2020-03-24T13:09:13.388818 #625-47230543316420] INFO – : Enqueued SearchIndexAssociationsJob (Job ID: 389e283e-3f9b-4eaa-9dac-816d32490ac3) to DelayedJob(default) with arguments: “User”, 168
E, [2020-03-24T13:09:13.875323 #625-47230543316420] ERROR – : ImportJob ‘Import::Ldap’ failed: undefined method ord' for nil:NilClass E, [2020-03-24T13:09:13.875408 #625-47230543316420] ERROR -- : undefined method ord’ for nil:NilClass (NoMethodError)
/usr/local/bundle/gems/net-ldap-0.16.1/lib/net/ldap/connection.rb:77:in getbyte' /usr/local/bundle/gems/net-ldap-0.16.1/lib/net/ber/ber_parser.rb:169:in read_ber’
/usr/local/bundle/gems/net-ldap-0.16.1/lib/net/ldap/connection.rb:234:in block in read' /usr/local/bundle/gems/net-ldap-0.16.1/lib/net/ldap/instrumentation.rb:19:in instrument’
/usr/local/bundle/gems/net-ldap-0.16.1/lib/net/ldap/connection.rb:233:in read' /usr/local/bundle/gems/net-ldap-0.16.1/lib/net/ldap/connection.rb:201:in queued_read’
/usr/local/bundle/gems/net-ldap-0.16.1/lib/net/ldap/connection.rb:441:in block (2 levels) in search' /usr/local/bundle/gems/net-ldap-0.16.1/lib/net/ldap/connection.rb:399:in loop’
/usr/local/bundle/gems/net-ldap-0.16.1/lib/net/ldap/connection.rb:399:in block in search' /usr/local/bundle/gems/net-ldap-0.16.1/lib/net/ldap/instrumentation.rb:19:in instrument’
/usr/local/bundle/gems/net-ldap-0.16.1/lib/net/ldap/connection.rb:388:in search' /usr/local/bundle/gems/net-ldap-0.16.1/lib/net/ldap.rb:784:in block (2 levels) in search’
/usr/local/bundle/gems/net-ldap-0.16.1/lib/net/ldap.rb:1303:in use_connection' /usr/local/bundle/gems/net-ldap-0.16.1/lib/net/ldap.rb:783:in block in search’
/usr/local/bundle/gems/net-ldap-0.16.1/lib/net/ldap/instrumentation.rb:19:in instrument' /usr/local/bundle/gems/net-ldap-0.16.1/lib/net/ldap.rb:782:in search’
/opt/zammad/lib/ldap.rb:72:in search' /opt/zammad/lib/sequencer/unit/import/ldap/users/sub_sequence.rb:15:in process’
/opt/zammad/lib/sequencer/unit/base.rb:202:in process' /opt/zammad/lib/sequencer.rb:77:in block (4 levels) in process’
/opt/zammad/lib/mixin/start_finish_logger.rb:7:in log_start_finish' /opt/zammad/lib/sequencer.rb:76:in block (3 levels) in process’
/opt/zammad/lib/sequencer/state.rb:150:in process' /opt/zammad/lib/sequencer.rb:74:in block (2 levels) in process’
/opt/zammad/lib/sequencer/units.rb:29:in block in each' /opt/zammad/lib/sequencer/units.rb:28:in each’
/opt/zammad/lib/sequencer/units.rb:28:in each' /opt/zammad/lib/sequencer.rb:72:in each_with_index’
/opt/zammad/lib/sequencer.rb:72:in block in process' /opt/zammad/lib/mixin/start_finish_logger.rb:7:in log_start_finish’
/opt/zammad/lib/sequencer.rb:70:in process' /opt/zammad/lib/sequencer.rb:25:in process’
/opt/zammad/lib/import/mixin/sequence.rb:15:in process' /opt/zammad/lib/import/integration_base.rb:99:in start’
/opt/zammad/app/models/import_job.rb:24:in start' /usr/local/bundle/gems/railties-5.2.4.1/lib/rails/commands/runner/runner_command.rb:41:in ’
/usr/local/bundle/gems/railties-5.2.4.1/lib/rails/commands/runner/runner_command.rb:41:in eval' /usr/local/bundle/gems/railties-5.2.4.1/lib/rails/commands/runner/runner_command.rb:41:in perform’
/usr/local/bundle/gems/thor-1.0.1/lib/thor/command.rb:27:in run' /usr/local/bundle/gems/thor-1.0.1/lib/thor/invocation.rb:127:in invoke_command’
/usr/local/bundle/gems/thor-1.0.1/lib/thor.rb:392:in dispatch' /usr/local/bundle/gems/railties-5.2.4.1/lib/rails/command/base.rb:69:in perform’
/usr/local/bundle/gems/railties-5.2.4.1/lib/rails/command.rb:46:in invoke' /usr/local/bundle/gems/railties-5.2.4.1/lib/rails/commands.rb:18:in ’
/usr/local/bundle/gems/bootsnap-1.3.2/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:21:in require' /usr/local/bundle/gems/bootsnap-1.3.2/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:21:in block in require_with_bootsnap_lfi’
/usr/local/bundle/gems/bootsnap-1.3.2/lib/bootsnap/load_path_cache/loaded_features_index.rb:65:in register' /usr/local/bundle/gems/bootsnap-1.3.2/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:20:in require_with_bootsnap_lfi’
/usr/local/bundle/gems/bootsnap-1.3.2/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:29:in require' /usr/local/bundle/gems/activesupport-5.2.4.1/lib/active_support/dependencies.rb:291:in block in require’
/usr/local/bundle/gems/activesupport-5.2.4.1/lib/active_support/dependencies.rb:257:in load_dependency' /usr/local/bundle/gems/activesupport-5.2.4.1/lib/active_support/dependencies.rb:291:in require’
bin/rails:9:in `’

3

@MrGeneration does the payload / traceback above help for further support?

4

This issue might be connected to the following issue from 2018:

What seemed to have helped was the following command within the rails console:
Setting.set('ldap_config', Setting.get('ldap_config').merge(connect_timeout: 100.minutes.to_i))

If your issue persists, please ensure to be on latest Zammad version possible.
Your type of ldap would be interesting, so what software you’re using (e.g. Microsoft Active Directory)

5

I set it to 100.minutes and verify it with “Setting.get(‘ldap_config’)” but the problem exists:

… “connect_timeout”=>6000}

We are useing the latest zammad version and Microsoft Active Directory. As i said in my inital post we also have a second zammad instance with version 3.2 and there is no problem with the ldap integration. Maybe the issue is a bug after all?

6

Which docker tag are you using?
I can’t reproduce this issue on docker or within other installations.

7

We use the official docker-compse files from github:

So i think it has to be latest. Here the output from the console:

sudo docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
zammad/zammad-docker-compose zammad-postgresql-3.3.0-11 cb412be89507 4 weeks ago 38.2MB
zammad/zammad-docker-compose zammad-elasticsearch-3.3.0-11 264e24f34e66 4 weeks ago 822MB
zammad/zammad-docker-compose zammad-3.3.0-11 312701ea9a3e 4 weeks ago 639MB
memcached 1.5.22-alpine 0dbf6b4c454b 2 months ago 9.19MB

8

The version being used for your containers lives in the .env file:

You’re using 3.3.0-11 at least that’s what your console output above shows.
You can find available tags here:
https://hub.docker.com/r/zammad/zammad-docker-compose/tags

I suggest to at least upgrade to 3.3.0-19 and try again - you could also jump to 3.3.0-23 as this would be the current latest stable at the moment.

I can’t reproduce your issues with a 3.3.0-19 container and currently am missing the time to test other containers, sorry.

9

Thanks for feedback. I will test it with the latest version!

1 Like
10

So i tested it with version 3.3.0-19 and the error still exists. It seems that the ldap sync stops after 125 Users and import not all users (169).

11

After further investigations we found the problem. We us haproxy as a HA server in front of our dcs. The connections timeouts were to short. After increasing these timeouts everything works as expected.

12

Ah! Good to know. Glad you could solve the issue!

1 Like
13

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