Re: errors with ldap/init-directory

On kwi 01, Jan Kowalsky wrote: I wasn't sure. But if it works as you say it does, great! The credentials are defined in these variables[1]. By default this will result in `uid=<local UNIX account>,ou=People,dc=example,dc=org` Distinguished Name. This can be overridden, either through Ansible inventory, or through a set of environment variables on the Ansible Controller. This way you can share the DebOps project directory between multiple people and each person will use their own credentials, stored in their own `pass` password store, which lives outside of the DebOps project directory. [1]: https://github.com/debops/debops/blob/master/ansible/roles/ldap/defaults/... The LDAP directory credentials are stored in the olcRootDN and olcRootPW attributes in the `cn=config` database. The `cn=admin` object created during installation by the postinstall script is not needed for authentication, and it may cause confusion if you don't synchronize the passwords if they change. If it's more than a couple of accounts I would say skip the YAML and go with LDIF instead. The LDAP tasks that create the entries are almost LDIF-like when they are written in YAML, and if you do it via Ansible it will be infinitely slower than with a `slapadd` import. Ansible needs to do a round-trip to execute a new Python script for each LDAP task ann this takes longer and longer the more accounts you want to manage. Go old school - if you have a user database already, generate LDIFs for the entries and import them. Or if you want to handle updates frequently, write a script that imports the data from your user database to LDAP directory. It will be much faster than going with this via Ansible. Yes, you can use the ldap__*_tasks variables to manage LDAP entries. You can define them in the inventory and run the 'debops service/ldap' playbook against the OpenLDAP hosts to apply the changes. No, this variable activates or deactivates the entire 'ldap' directory - it's needed since that role is still included in the 'common' playbook and can be used on non-LDAP enabled hosts this way. You can write a normal Ansible playbook that uses the 'ldap_entry' and 'ldap_attrs' Ansible modules to manage LDAP entries. There's no need to involve the DebOps 'ldap' role for this. The default LDAP schema in DebOps is the 'rfc2307bis' schema[2]. It changes a few things, namely makes the posixGroup object clas an AUXILLIARY class, which lets you apply it to existing objects. You can then create an inetOrgPerson object with posixGroup class and define gidNumber in a single object - that's how DebOps handles User Private Groups in LDAP[3]. As for th constraint violation - gidNumber uniqueness is enfoced globally by the 'slapd' role[4] to avoid collisions and accidental security issues. If you want to create a new user with unique UID and GID number, it's best to reserve one via special LDAP objects prepared just for that[5], similar to how FusionDirectory does it. [2]: https://docs.debops.org/en/master/ansible/roles/slapd/ldap-schema.html#th... [3]: https://docs.debops.org/en/master/ansible/roles/ldap/ldap-posix.html#posi... [4]: https://github.com/debops/debops/blob/master/ansible/roles/slapd/defaults... [5]: https://docs.debops.org/en/master/ansible/roles/ldap/ldap-posix.html#next... I hope that the explanations helped. :-) Maciej