On 28 Jan 2021, at 19:13, Angel Bosch Mora
<abosch(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)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.fedoraproje...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia