Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🐛 - Gitlab LDAP bindDN and base not fully qualified #118

Closed
eformat opened this issue May 19, 2022 · 4 comments · Fixed by #119
Closed

🐛 - Gitlab LDAP bindDN and base not fully qualified #118

eformat opened this issue May 19, 2022 · 4 comments · Fixed by #119
Assignees

Comments

@eformat
Copy link
Member

eformat commented May 19, 2022

when deploying the base tl500 helm chart - the ldap creds for gitlab are automatically created by looking up the OAuth identity provider

this is done in the _helpers.tpl code

BUT .. we just had an instance where the "bind_dn" and "base" in the GITLAB_OMNIBUS_CONFIG was set wrong ! here are the screenshots:

Screenshot from 2022-05-19 10-22-07

Screenshot from 2022-05-19 10-58-25

They should be:

'bind_dn' => 'uid=ldap-sa,cn=users,cn=accounts,dc=rht-labs,dc=com',
'base' => 'cn=accounts,dc=rht-labs,dc=com'

So, the lookup is failing somehow.

I have noticed similar behavior in another chart where you NEED to escape the ',' e.g.

helm upgrade --install my-chart \
--set ldap_bind_dn="uid=ldap_admin\\,cn=users\\,cn=accounts\\,dc=redhatlabs\\,dc=dev"

Anyway .. this needs looking into root cause. It doesn't happen in every deployment, this is the first i have seen it in the real !

@jfilipcz
Copy link
Contributor

Root cause was simple - since I've started to works with those helm-charts, we had some issues with gitlab integration (with configuration set through the helper), and resorted back to using values set manually:)

@jfilipcz
Copy link
Contributor

I will give it another test on my private cluster, and if all works out we can close the issue (possibly with a documentation update)

@jfilipcz
Copy link
Contributor

Tests confirmed all is working fine.

@jfilipcz jfilipcz linked a pull request May 19, 2022 that will close this issue
@eformat
Copy link
Member Author

eformat commented May 19, 2022

@jfilipcz thanks for confirming ! OK .. yeah \, escaping needed :) if setting values for ldap

the lookup logic works fine though, has not broken ever as far as i can tell

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants