#48951 RFE dsadm and dsconf
Closed: wontfix None Opened 4 years ago by firstyear.

As we have started to lay the foundations for new administration tools and commands in lib389, we now need the command line tools to utilise them.

This will add unified administration tools dsadm and dsconf.

dsadm will administer the local instance of the server, for tools that require local access. This includes, db2bak, bak2db, installing instances, removing instances, start, stop.

dsconf will administer configuration of the directory server via the ldap interface. This includes plugins, indices, logging settings, backends: generally everything in cn=config.

Please help us to review your patches...

It'd be nice to provide us some usage patterns using them. Like, the steps of setup, configuration, and operation command lines?

Could there be any "interactive mode"? Or everything is given via options? How about the silent mode equivalent?

Probably, you could start a page or two on port389.org... ;)

Yes, I think I need to make a design document for this. I will do that to help with the review.

Thanks for your advice!

Thank YOU, William.

May I ask you the most basic question? :) Why you separated dsconf from dsadm? If dsadm does everything with a config option, the administrators do not have to memorize 2 command names?

And I noticed your 5 patches show progress in them. Like the 3rd patch fixes something in the 1st or 2nd patch... That means, we should apply all the patches once and generate one patch by ourselves?

This is a great start! I just have a few comments...


"dsconf" I see you are using "-Z' for startTLS, but in all the other scripts (DS utils & dsadm) -Z is used to specify the server instance. I know ldapsearch uses -Z(-ZZ) for SSL, but I think we should be consistent with "our" command line tools, and we should not use -Z in dsconf for startTLS.

In lib389/cli_base/init.py

connect_instance() this should call:

ds.open(starttls=starttls, connOnly=True)

Otherwise it performs all kinds of unnecessary searches per connection. Unless that's what you want, but if it's just to open a connection(and not populate other fields of the DirSrv object) then connOnly should be set to True.


Looks good


Looks good


Looks good


Looks good

I'll give my ack, but look into my comments and adjust the patch as needed.

connOnly is a good idea. I'll add that and test before I push. I want to completely rip out parts of the DirSrv object later anyway, but this is a start.

With the startTls, I would rather us do the same as the openldap tools. Given we point people to ldapsearch -Z ... we should be consistent to that IMO.

It's certainly not set in stone in anyway shape or form, so I think we can discuss this further.

commit 6ea44f1575e12b537819fc7775da1d29f4492a30
Writing objects: 100% (29/29), 14.61 KiB | 0 bytes/s, done.
Total 29 (delta 13), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/lib389.git
45445e8..6ea44f1 master -> master

Made the connOnly change, squashed all to one commit.

We can continue to discuss the name and -Z option, and then add a second commit to change these.

commit bf4172be8892db9196412733d78ade64d62def04
Writing objects: 100% (17/17), 3.95 KiB | 0 bytes/s, done.
Total 17 (delta 10), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/lib389.git
7ccbc8c..bf4172b master -> master

Metadata Update from @firstyear:
- Issue assigned to firstyear
- Issue set to the milestone: lib389 1.0.3

4 years ago

Metadata Update from @mreynolds:
- Issue close_status updated to: None (was: Fixed)
- Issue set to the milestone: None (was: lib389 1.0.3)

a year ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/2010

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix

7 months ago

Login to comment on this ticket.