Closed pat-s closed 2 years ago
jp-gouin
commented
2 years ago Hi @pat-s , sorry I was a bit off the past few weeks. I ll look asap into your issue.
for the test yes it’s still working , for Ivan-c if I recall, there was an issue with his .ldif file
Can you post yours and the values that you are using please ?
pat-s
commented
2 years ago Sure.
Here's the file, I masked all sensitive values
version: 1
# Entry 1: dc=test,dc=link
dn: dc=test,dc=link
dc: test
o: Example Inc.
objectclass: top
objectclass: dcObject
objectclass: organization
# Entry 2: cn=admin,dc=test,dc=link
dn: cn=admin,dc=test,dc=link
cn: admin
description: LDAP administrator
objectclass: simpleSecurityObject
objectclass: organizationalRole
objectclass: top
userpassword: foo
# Entry 3: ou=groups,dc=test,dc=link
dn: ou=groups,dc=test,dc=link
objectclass: organizationalUnit
objectclass: top
ou: groups
# Entry 5: cn=users,ou=groups,dc=test,dc=link
dn: cn=users,ou=groups,dc=test,dc=link
cn: users
gidnumber: 500
memberuid: admin
objectclass: posixGroup
objectclass: top
# Entry 6: ou=users,dc=test,dc=link
dn: ou=users,dc=test,dc=link
objectclass: organizationalUnit
objectclass: top
ou: users
# Entry 7: cn=admin admin,ou=users,dc=test,dc=link
dn: cn=admin admin,ou=users,dc=test,dc=link
cn: admin admin
gidnumber: 501
givenname: admin
homedirectory: /home/admin
loginshell: /bin/bash
mail: admin@test.com
objectclass: inetOrgPerson
objectclass: posixAccount
objectclass: top
sn: admin
uid: admin
uidnumber: 10006
userpassword: foo
dn: cn=first last,ou=users,dc=test,dc=link
cn: first last
gidnumber: 500
givenname: first
homedirectory: /home/first
loginshell: /bin/bash
mail: foo@test.com
objectclass: inetOrgPerson
objectclass: posixAccount
objectclass: top
sn: last
uid: first
uidnumber: 10001
userpassword: fooHi @pat-s ,
Again sorry for the delay.
as a matter of fact those 2 entries are the problem as they are already created by the container image during first run.
# Entry 1: dc=test,dc=link
dn: dc=test,dc=link
dc: test
o: Example Inc.
objectclass: top
objectclass: dcObject
objectclass: organization
# Entry 2: cn=admin,dc=test,dc=link
dn: cn=admin,dc=test,dc=link
cn: admin
description: LDAP administrator
objectclass: simpleSecurityObject
objectclass: organizationalRole
objectclass: top
userpassword: fooIf you use
# Entry 3: ou=groups,dc=test,dc=link
dn: ou=groups,dc=test,dc=link
objectclass: organizationalUnit
objectclass: top
ou: groups
# Entry 5: cn=users,ou=groups,dc=test,dc=link
dn: cn=users,ou=groups,dc=test,dc=link
cn: users
gidnumber: 500
memberuid: admin
objectclass: posixGroup
objectclass: top
# Entry 6: ou=users,dc=test,dc=link
dn: ou=users,dc=test,dc=link
objectclass: organizationalUnit
objectclass: top
ou: users
# Entry 7: cn=admin admin,ou=users,dc=test,dc=link
dn: cn=admin admin,ou=users,dc=test,dc=link
cn: admin admin
gidnumber: 501
givenname: admin
homedirectory: /home/admin
loginshell: /bin/bash
mail: admin@test.com
objectclass: inetOrgPerson
objectclass: posixAccount
objectclass: top
sn: admin
uid: admin
uidnumber: 10006
userpassword: foo
dn: cn=first last,ou=users,dc=test,dc=link
cn: first last
gidnumber: 500
givenname: first
homedirectory: /home/first
loginshell: /bin/bash
mail: foo@test.com
objectclass: inetOrgPerson
objectclass: posixAccount
objectclass: top
sn: last
uid: first
uidnumber: 10001
userpassword: fooIt works without issue , i have created a branch https://github.com/jp-gouin/helm-openldap/tree/pat-s-issue-boostrap with a values as example for you
You can set logLevel to debug to see what is happening for your ldif processing.
I'll add a troubleshooting section :)
pat-s
commented
2 years ago @jp-gouin Thanks for your help!
I've tried this but I am still not successful, even when using the exact values you used in the fork you linked :/
I've also started from scratch without using a persistent volume to just avoid any issues with existing deployments.
There is no issue during deployment but the users are not created - and I don't see any hint in the log related to this, even though I've set logLevel: debug.
Any idea what I might be doing wrong?
Using helm chart version "2.1.6" with image.tag: stable and an ingress (which should not matter) - everything else is stock.
jp-gouin
commented
2 years ago Could you post the log of the first openldap pod during startup ?
pat-s
commented
2 years ago Here's the full debug log output of a new startup. I've redacted LDAP_PASSWORD and LDAP_DOMAIN.
Thanks a lot for your help!
pat-s
commented
2 years ago I was never successful to get it working with our current structure but using a fresh deployment without a PV and carefully adding the required buildings blocks (groups, users, etc.) made it work 🎉
If persistence is enabled, bootstrapping will be skipped.
Thanks for your help @jp-gouin, definitely helped me along the way!
I am facing moderate pain trying to start an HA instance with
customLdifFiles.It seems this might be related to https://github.com/jp-gouin/helm-openldap/issues/31. There, the issue that bootstrapping is skipped if one of the following dirs is not empty:
In my current instance, I see bootstrapping is skipped:
In
/etc/ldap/slapd.dI see the following files/var/lib/ldapcontains the database, which might be empty during the first start. I've deployed fresh, i.e. with no PV and no PVC. Still, the bootstrapping is skipped. This let's me assume that something writes into this dir before https://github.com/osixia/docker-openldap/blob/v1.5.0/image/service/slapd/startup.sh#L182-L183 is reached.I also checked with
logLevel: debug, however there is no debugging line indicating why Bootstrapping might be skipped, so this action is not really helping.Maybe @ivan-c can share how he made bootstrapping work?
@jp-gouin Are tests still working with respect to this as you mentioned in https://github.com/jp-gouin/helm-openldap/issues/31#issuecomment-841047132?