thanks for your response Mark,

I can see that two other options are removed. I used to configure retro-changelog like this:

dsconf myinstance plugin retrochangelog set --max-age 2d dsconf myinstance plugin retrochangelog set --attribute nsuniqueid:targetUniqueId

but now it doesn't accept those settings. what's the correct way to configure that?

abosch

----- Missatge original -----

De: "Mark Reynolds" mreynolds@redhat.com Per: "General discussion list for the 389 Directory server project." 389-users@lists.fedoraproject.org, "Angel Bosch Mora" abosch@imasmallorca.net Enviats: Dimecres, 27 de Gener 2021 14:43:19 Assumpte: [389-users] Re: plugin names and debian packages

Well 1.4.0 is quite old and is no longer maintained/supported. In newer versions of 389 it was changed to "retro-changelog".  It probably was changed in 1.4.1.

HTH,

Mark

On 1/27/21 5:41 AM, Angel Bosch Mora wrote:

...

hi!

I'm testing my install recipes on debian and I've found two little problems.

on CentOS I execute

 dsconf myinstance plugin retro-changelog enable

but today I tried in debian and it says is an invalid choice:

 dsconf instance plugin: error: invalid choice:
 'retro-changelog' (choose from 'memberof', 'automember',
 'referint', 'rootdn', 'usn', 'accountpolicy', 'attruniq',
 'dna', 'linkedattr', 'managedentries', 'passthroughauth',
 'retrochangelog', 'whoami', 'list', 'get', 'edit')

So retro-changelog is called now retrochangelog.

Is that a Debian thing or it changed it's name on a recent version?

In addition I executed the command with the new name and it gives me a message without a correct variable.

 dsconf myinstance plugin retrochangelog enable
 Enabled plugin '%s' Retro Changelog Plugin

 dsconf myinstance plugin retrochangelog status
 Plugin '%s' is enabled Retro Changelog Plugin

it seems a cosmetic error but I just want to be sure if I need to open a bug.

here are the version of the packages:

dpkg -l | grep 389 ii 389-ds-base 1.4.0.21-1 amd64 389 Directory Server suite - server ii 389-ds-base-legacy-tools 1.4.0.21-1 amd64 Legacy utilities for 389 Directory Server ii 389-ds-base-libs:amd64 1.4.0.21-1 amd64 389 Directory Server suite - libraries ii python3-lib389 1.4.0.21-1 all Python3 module for accessing and configuring the 389 Directory Server

thanks in advance,

abosch -- Institut Mallorqui d'Afers Socials. Aquest missatge, i si escau, qualsevol fitxer annex, es dirigeix exclusivament a la persona que n'es destinataria i pot contenir informacio confidencial. En cap cas no heu de copiar aquest missatge ni lliurar-lo a terceres persones sense permis expres de l'IMAS. Si no sou la persona destinataria que s'hi indica (o la responsable de lliurar-l'hi) us demanam que ho notifiqueu immediatament a l'adreca electronica de la persona remitent. Abans d'imprimir aquest missatge, pensau si es realment necessari. _______________________________________________ 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....

--

389 Directory Server Development Team _______________________________________________ 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....

Again I think you are looking at the older version of the server.

ok, I understand.

I see that version 2 is already out. Can I expect additional changes in dsconf interface or will you try to mantain a stable set of parameters?

As sysadmin I create a lot of script to install/manage services and is confusing having commands that change that often.

Please take this as a positive criticism :)

abosch

On 28 Jan 2021, at 06:50, Mark Reynolds mreynolds@redhat.com wrote:

On 1/27/21 2:57 PM, Angel Bosch wrote:

...

...

Again I think you are looking at the older version of the server.

ok, I understand.

I see that version 2 is already out. Can I expect additional changes in dsconf interface or will you try to mantain a stable set of parameters?

Great question. There are no plans to change the "dsconf" interface. But, I'd like to make some improvements to the "dsctl" command. Some of the functions in dsctl (ldif2db, db2ldif, etc) do not follow the same design that dsconf uses. So I want to improve this in 2.0.x, to be more consistent with dsconf. But there are no plans to change "dsconf", or "dsidm".

...

As sysadmin I create a lot of script to install/manage services and is confusing having commands that change that often.

You may find it "more stable" to use lib389 directly rather than the CLI then. I think the team should talk about the CLI having an "interface guarantee", and today I don't think I personally would want to commit to that (but the team hasn't decided on this). I still see room to change and grow the CLI in ways that may be breaking, but the core of lib389 today seems "pretty stable".

I think you were using a early version of 1.4.0 btw. I can see in 1.4.0.x we switched it over to use "retro-changelog" in 389-ds-base-1.4.0.22 via this commit:

commit 1f15e966cb8265fb636e12e18ac516bb127c2db0
Date:   Mon Feb 18 22:45:01 2019 +0100

So 389-ds-base-1.4.0.21 uses "retrochangelog", and 1.4.0.22 uses "retro-changelog"

In 1.4.1 this change landed in: 389-ds-base-1.4.1.2 So anything earlier than this release is still using "retrochangelog"

...

Please take this as a positive criticism :)

Absolutely, and any suggestions for improvements are always welcome.

Thanks, Mark

...

abosch

---

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....

--

389 Directory Server Development Team _______________________________________________ 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....

— Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server SUSE Labs, Australia

On 28 Jan 2021, at 19:13, Angel Bosch Mora abosch@imasmallorca.net wrote:

...

...

...

As sysadmin I create a lot of script to install/manage services and is confusing having commands that change that often.

You may find it "more stable" to use lib389 directly rather than the CLI then. I think the team should talk about the CLI having an "interface guarantee", and today I don't think I personally would want to commit to that (but the team hasn't decided on this). I still see room to change and grow the CLI in ways that may be breaking, but the core of lib389 today seems "pretty stable".

I understand your recommendation but I don't think I'm going to do that, and I think I "shouldn't" do that.

my job as sysadmin is installing, managing, mantaining and monitoring, and dsconf wrapping is just what I need. If I have, for example, a command that tells me if a drive is out of space I don't expect to change that command over the years on different linux systems with different versions.

I understand that 389 is under heavy refactoring these last years, I'm just a little bit tired of version conditionals in my recipes (and by the way, I can't find an easy method to check the version with dsconf/dsctl, worth a feature request?).

so taking my own example I just expect that `dsconf instance plugin retro-changelog enable' is still valid a year/version later.

The problem here is that there is a difference between "a command line that is good for humans" and "a command line that is good for machine/API consumption".

If we target good for APIs, and commit to making the CLI interface "stable", then we lose the possibility to improve things for humans. LDAP has a reputation for being difficult to administer, and this is just a small step to fixing that. But to commit to CLI interface stability means we would stop being able to progress on this front. We would again become stagnant, and I don't want to see that after we have made so much progress already.

But we *do* have something that *is* API stable - our python API. We *have* to maintain that and it's behaviours, and at this point it's core has not undergone significant churn. It's also much easier to script and manipulate compared to shell. In a recent email I sent this example to someone:

from lib389 import DirSrv import logging

log = logging.getLogger() log.setLevel(logging.DEBUG)

ds = DirSrv(verbose=True, external_log=log) ds.remote_simple_allocate(ldapuri="ldaps://ldapuri", binddn="", password="") ds.open()

from lib389.config import Config dsconfig = Config(ds) dsconfig.set('nsslapd-port', '389')

Alternately, we have another interface that *is* stable and we strongly commit to keeping it the same - our cn=config and ldap interface that you can directly modify.

Regardless, as a project we need to discuss what level of CLI interface stability we want to commit to - today you must assume that it is *not* a commitment we are making.

again, please take my point of view as a frustrated admin with too many tasks to do and too little beers to take on my free time (everything is closed right now in Mallorca :P)

I too was once upon a time, a frustrated admin with too many tasks and too little time. Some of the initial code for the python tooling you use today was written when I was in that role, and it's what inspired me to want to make this CLI better for human admins. But for programmatic tasks, you should always use a programming language like python. I used to use python to script satellite 5 via it's api for example.

And maybe it's hard/frustrating to hear today, because it seems like more work, but any process/progress is like that. For you to learn python would be a challenge in the short term, but long term it will pay off multiple times over.

Hope that helps,

cheers,

abosch -- Institut Mallorqui d'Afers Socials. Aquest missatge, i si escau, qualsevol fitxer annex, es dirigeix exclusivament a la persona que n'es destinataria i pot contenir informacio confidencial. En cap cas no heu de copiar aquest missatge ni lliurar-lo a terceres persones sense permis expres de l'IMAS. Si no sou la persona destinataria que s'hi indica (o la responsable de lliurar-l'hi) us demanam que ho notifiqueu immediatament a l'adreca electronica de la persona remitent. Abans d'imprimir aquest missatge, pensau si es realment necessari. _______________________________________________ 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....

— Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server SUSE Labs, Australia