dsconf idempotency

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux