Skip to content
GitLab
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
    Projects Groups Topics Snippets
  • Register
  • Sign in
  • GitLab GitLab
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
    • Locked files
  • Issues 9,362
    • Issues 9,362
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Jira
    • Jira
  • Merge requests 139
    • Merge requests 139
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
    • Test cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar

Do not update/delete: Banner broadcast message test data

Do not update/delete: Notification broadcast message test data

  • GitLab.orgGitLab.org
  • GitLabGitLab
  • Issues
  • #3082
Closed
Open
Issue created Aug 02, 2017 by username-removed-1209486@johneismeier

ERROR -- omniauth: (ldapmain) Authentication failure! ldap_error: Errno::ECONNRESET, Connection reset by peer @ io_fillbuf - fd:18

Summary

(Summarize the bug encountered concisely)

upgrade to 9.4.2 or 9.4.3 for EE only.

ERROR -- omniauth: (ldapmain) Authentication failure! ldap_error: Errno::ECONNRESET, Connection reset by peer @ io_fillbuf - fd:18

Steps to reproduce

(How one can reproduce the issue - this is very important)

Running 9.4.1 configuration works. Upgrade to 9.4.2 or 9.4.3 and: ERROR -- omniauth: (ldapmain) Authentication failure! ldap_error: Errno::ECONNRESET, Connection reset by peer @ io_fillbuf - fd:18

Example Project

(If possible, please create an example project here on GitLab.com that exhibits the problematic behaviour, and link to it here in the bug report)

(If you are using an older version of GitLab, this will also determine whether the bug has been fixed in a more recent version)

What is the current bug behavior?

(What actually happens)

I can't login with our LDAP auth. I know there was discussion and repairs on LDAP for the 9.4.3 release but it didn't work for our configuration.

What is the expected correct behavior?

(What you should see instead) I don't know? Please advise? I reverted to 9.4.1 release until this issue is repaired.

Relevant logs and/or screenshots

(Paste any relevant logs - please use code blocks (```) to format console output, logs, and code as it's very hard to read otherwise.)

Output of checks

(If you are reporting a bug on GitLab.com, write: This bug happens on GitLab.com)

Results of GitLab environment info

Expand for output related to GitLab environment info

(For installations with omnibus-gitlab package run and paste the output of: sudo gitlab-rake gitlab:env:info)

(For installations from source run and paste the output of: sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production)

Results of GitLab application Check

Expand for output related to the GitLab application check

(For installations with omnibus-gitlab package run and paste the output of: sudo gitlab-rake gitlab:check SANITIZE=true)

(For installations from source run and paste the output of: sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)

(we will only investigate if the tests are passing)

Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Edited Aug 04, 2017 by username-removed-1144264
Assignee
Assign to
Time tracking