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

qspweissen · March 24, 2020, 12:56pm

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

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

qspweissen · March 24, 2020, 1:11pm

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 `’

qspweissen · March 26, 2020, 7:54am

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

MrGeneration · April 2, 2020, 6:10pm

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

github.com/zammad/zammad

LDAP - Error occurred during Import: undefined method `ord' for nil:NilClass

opened 09:50AM - 07 Mar 18 UTC

closed 05:14AM - 17 Oct 18 UTC

Sandalas

bug import LDAP verified prioritised by payment

### Infos: * Used Zammad version: 2.3.0 * Installation method (source, packa…ge, ..): yum * Operating system: CentOS 7 * Database + version: PostgreSQL 9.2.23 * Elasticsearch version: 5.6.7 * Browser + version: Firefox/Chrome ### Expected behavior: After the configuration and the successful analyse, at the end of the configuration steps, of the import, the import should run without a crash. ### Actual behavior: I want to import 1923 users from LDAP. After around 1200-1300 the import stops with following error: **An error occurred: undefined method &grave;ord' for nil:NilClass** [nilClass.txt](https://github.com/zammad/zammad/files/1788425/nilClass.txt) First I thought, the problem is one of the users itself. So I imported the users only partially (via LDAP Filter), to find the one. But everything went fine. The partial imports were all successful. 1. a-e (397 User) working 2. f-j (343 User) working 3. k-o (480 User) working 4. p-t (507 User) working 5. u-z (197 User) working 6. f-t (1330 User) working 7. f-z (1527 User) **!!! error !!!** Unfortunately the error log gives me no hint, how to handle this or where to search. ### Steps to reproduce the behavior: 1. Configure the Import via ldap or ldaps 2. Try to import more than 1500 people Yes I'm sure this is a bug and no feature request or a general question.

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)

qspweissen · April 3, 2020, 5:50am

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?

MrGeneration · April 7, 2020, 8:05pm

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

qspweissen · April 8, 2020, 6:40am

We use the official docker-compse files from github:

github.com

zammad/zammad-docker-compose/blob/master/docker-compose.yml

---
version: '3.8'

x-shared:
  zammad-service: &zammad-service
    environment: &zammad-environment
      MEMCACHE_SERVERS: ${MEMCACHE_SERVERS}
      POSTGRESQL_DB: ${POSTGRES_DB}
      POSTGRESQL_HOST: ${POSTGRES_HOST}
      POSTGRESQL_USER: ${POSTGRES_USER}
      POSTGRESQL_PASS: ${POSTGRES_PASS}
      POSTGRESQL_PORT: ${POSTGRES_PORT}
      REDIS_URL: ${REDIS_URL}
      # Allow passing in these variables via .env:
      AUTOWIZARD_JSON:
      AUTOWIZARD_RELATIVE_PATH:
      ELASTICSEARCH_ENABLED:
      ELASTICSEARCH_HOST:
      ELASTICSEARCH_PORT:
      ELASTICSEARCH_SCHEMA:

This file has been truncated. show original

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

MrGeneration · April 8, 2020, 11:06am

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

github.com

zammad/zammad-docker-compose/blob/master/.env#L6


IMAGE_REPO=zammad/zammad-docker-compose
POSTGRES_PASS=zammad
POSTGRES_USER=zammad
RESTART=always
# don't forget to add the minus before the version
VERSION=-3.3.0-19

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.

qspweissen · April 8, 2020, 11:25am

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

qspweissen · April 24, 2020, 10:22am

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).

qspweissen · April 28, 2020, 8:52am

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.

MrGeneration · April 28, 2020, 8:53am

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

system · August 26, 2020, 8:53am

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