Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • G gitlabhq1
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 21
    • Issues 21
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 12
    • Merge requests 12
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • gpt
  • large_projects
  • gitlabhq1
  • Issues
  • #10081

Closed
Open
Created Mar 12, 2016 by Administrator@rootOwner

Configuring secondary LDAP server causes malfunctions

Created by: RevChas

My company set up a new GitLab 7.10.4 server on a Centos 7 server from the Crntos YUM repos.

I first noticed a problem when trying to ass an SSH key. The sidekiq job that was supposed to add the key got stuck in the queue and never run.

When I tried to reconfigure and restart the GitLab instance, it would not connect properly to the socket at /var/opt/gitlab/gitlab-rails/sockets/gitlab.socket. Then I shutdown the GitLab server and removed the socket file and it wasn't recreated.

Working with one of your expert volunteers we tried to look at some configuration info and saw this at the start of the output:

# gitlab-rake gitlab:env:info rake aborted! Devise::OmniAuth::StrategyNotFound: Could not find a strategy with name Ldapsecondary'. Please ensure it is required or explicitly set it using the :strategy_class option.

I deleted the 2 LDAP servers that were configured in /etc/gitlab/gitlab.rb and restarted the GitLab instance with no problems. Apparently, configuring 2 LDAP servers causes problems.

Assignee
Assign to
Time tracking