Hello,
I like to use [dsconf](https://directory.fedoraproject.org/docs/389ds/design/dsadm-dsconf.html) to manage my 389ds instances.
I like also Ansible to manage the configuration. From Ansible, if I run dsconf command I see some problems of idempotency.
For example, if I run the first time in a new fresh installation
``` dsconf -D cn=Directory Manager -w **** ldap://localhost:389 plugin attr-uniq set attribute uniqueness --subtree=c=en --enabled=on --attr-name=uid --across-all-subtrees=off ```
it returns 0 and the output
*Successfully changed the cn=attribute uniqueness,cn=plugins,cn=config*. If I re run the same command I will see:
*There is nothing to set in the cn=attribute uniqueness,cn=plugins,cn=config plugin entry*
and the exit status is 1.
Of course I can manage the output in Ansible in order to reclassify as well the task result. But I have to do that in a lot of cases (best effort).
Of course I can use some idempotent ldapmodify module, but I like to trust `dsconf`.
So I wonder if you could consider the benefit to make `dsconf` more idempotent. For instance, in the above case the exit status could be 0. The same behavior could be adopted in all results of "already exists" output messages when the value to set is equal to the value already present (ie: `dsconf -D cn=Directory Manager -w *** ldap://localhost:389 backend index add ...` returns "already exists" and the exit status 1 if the idex is already defined)
If you have any other hints to address this problem could let me know.
Thank you very much Kind Regards Marco
On 25 Mar 2021, at 21:42, Marco Favero m.faverof@gmail.com wrote:
Hello,
I like to use [dsconf](https://directory.fedoraproject.org/docs/389ds/design/dsadm-dsconf.html) to manage my 389ds instances.
I like also Ansible to manage the configuration. From Ansible, if I run dsconf command I see some problems of idempotency.
For example, if I run the first time in a new fresh installation
dsconf -D cn=Directory Manager -w **** ldap://localhost:389 plugin attr-uniq set attribute uniqueness --subtree=c=en --enabled=on --attr-name=uid --across-all-subtrees=offit returns 0 and the output
*Successfully changed the cn=attribute uniqueness,cn=plugins,cn=config*. If I re run the same command I will see:
*There is nothing to set in the cn=attribute uniqueness,cn=plugins,cn=config plugin entry*
and the exit status is 1.
Of course I can manage the output in Ansible in order to reclassify as well the task result. But I have to do that in a lot of cases (best effort).
Of course I can use some idempotent ldapmodify module, but I like to trust `dsconf`.
So I wonder if you could consider the benefit to make `dsconf` more idempotent. For instance, in the above case the exit status could be 0. The same behavior could be adopted in all results of "already exists" output messages when the value to set is equal to the value already present (ie: `dsconf -D cn=Directory Manager -w *** ldap://localhost:389 backend index add ...` returns "already exists" and the exit status 1 if the idex is already defined)
If you have any other hints to address this problem could let me know.
I actually think that in this case, dsconf is about doing a task, not about achieving a state or outcome.
We have talked about creating a stateful configuration tool that is *seperate* to dsconf though, because we don't consider the api (interface) of dsconf as stable - we have and probably will change it's options in the future.
Alternately, we could create an ansible module for this, because internally the python library used in dsconf IS capable of stateful operations.
Thank you very much Kind Regards Marco _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs, Australia
I also found myself in the same situation as Marco's, and I saw that the feature request that he opened was closed as won't fix. I think it would be very useful to anybody wanting to automate their 389 deployments, to have an Ansible module that uses the same library that dsctl and such are using. Have there been any developments on this?
Hi Marco,
I agree with you that the command setting the attributes to the same existing values should not fail. Output could differ from "Successfully changed ..." to let us know that no MOD were applied but IMHO it should succeeds as well.
Please would you open a new bug (https://github.com/389ds/389-ds-base/issues/new/choose) ?
regards thierry On 3/25/21 12:42 PM, Marco Favero wrote:
Hello,
I like to use [dsconf](https://directory.fedoraproject.org/docs/389ds/design/dsadm-dsconf.html) to manage my 389ds instances.
I like also Ansible to manage the configuration. From Ansible, if I run dsconf command I see some problems of idempotency.
For example, if I run the first time in a new fresh installation
dsconf -D cn=Directory Manager -w **** ldap://localhost:389 plugin attr-uniq set attribute uniqueness --subtree=c=en --enabled=on --attr-name=uid --across-all-subtrees=offit returns 0 and the output
*Successfully changed the cn=attribute uniqueness,cn=plugins,cn=config*. If I re run the same command I will see:
*There is nothing to set in the cn=attribute uniqueness,cn=plugins,cn=config plugin entry*
and the exit status is 1.
Of course I can manage the output in Ansible in order to reclassify as well the task result. But I have to do that in a lot of cases (best effort).
Of course I can use some idempotent ldapmodify module, but I like to trust `dsconf`.
So I wonder if you could consider the benefit to make `dsconf` more idempotent. For instance, in the above case the exit status could be 0. The same behavior could be adopted in all results of "already exists" output messages when the value to set is equal to the value already present (ie: `dsconf -D cn=Directory Manager -w *** ldap://localhost:389 backend index add ...` returns "already exists" and the exit status 1 if the idex is already defined)
If you have any other hints to address this problem could let me know.
Thank you very much Kind Regards Marco _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Hello,
thank you for the feedback. I tried to open a Feature Request here:
https://github.com/389ds/389-ds-base/issues/4703
Thank you to consider this.
Kind Regards Marco
389-users@lists.fedoraproject.org
-
Andrei Corduneanu -
Marco Favero -
thierry bordaz -
William Brown