[389-devel] Instance discovery tools in lib389

Mark Reynolds mareynol at redhat.com
Thu Aug 6 21:01:10 UTC 2015


Hi William,

On 08/06/2015 12:54 AM, William Brown wrote:
> Hi,
>
> I have been working on lib389 recently to bring in a number of the tools I have
> developed professionally into the project so that others can benefit from this.
> As you may have seen I've already submitted a few patches related to this.
>
> I've done some of the api changes needed, but now I would like to make it a bit
> easier to add command line tools that can utilise lib389.
This is right inline with what we would like to do as well.
>
> I would like to add a "tools" directory to lib389 with a number of the cli tools
> and helpers that I have written [1]. Is this the best location for these tools?
If there are really simple, maybe they could just be added to the 
tools.py/utils.py files?  More on this below...
> Some of them could arguably go into the main line 389ds codebase, but I want to
> use lib389 to back them.
This really depends on the tool, but see below...
>
> Second, with these tools I don't want them to be complex.
+1  For lib389 inclusion they should be very simple, so that other tools 
can utilize them.
> For example, I would
> like a tool that can show what attribute can be held by what objectClass. I
> would want the calling syntax to be as easy as:
>
> attribute_query.py -i <instance name> <attribute name>
>
> In order to achieve this there are a few changes I want to make.
>
> First, is that there is already a DirSrv.list() function. This works well to
> list instances on the system, but it's missing the instance name, so I want to
> add this to the dictionary that is returned.
>
> Second, I want to make it possible to initialise the DirSrv object from an
> instance directory returned by the list() function. Normally this is done
> through the allocate() function to establish the details of the connection, at
> the moment the instance function doesn't return enough data to support this.
>
> Either, I can add in functionality to the list() function to return more data
> about each instance, possibly enough to just take the result from list() and put
> it in as allocate(args) and have a working connection. Alternately I write a new
> allocate_from_instance() (or some other name ...?) function that is able to do
> the discovery of the needed data, and then call allocate.
>
> Which would be the preferred method.
Both.  Expand the instance dictionary(your proposal could be useful for 
many other tasks/tools), and create the new allocate_from_instance 
function.
>
> Comments and advice is appreciated.
>
>
> [1] The tools I want to add are:
> * List all known system instances
> * schema query tools (list of object classes, attributes, query which
> objectclasses can take which attribute)
This should really be added to schema.py, or at least the core 
functionality added to schema.py, then build your tool off of that?
> * aci testing and manipulation tools. For example, "does aci X do what I
> suspect".
> * aci inversion tool. convert != aci's into == aci's to help conversion to white
> lists.
Maybe these aci tools could be partially integrated into a new acl.py 
file?  Kind of like what I suggested with the schema tools.

> * Probably many more that I haven't thought of yet to help make administration
> of a 389ds instance simpler.

Ultimately, I would like to see some of your new functionally go into 
the existing core module, and then write your tools based off of those.  
This way it can be leveraged outside of your "specific task" tools - for 
use in other new/future tools.  Of course I am specualting a bit, 
because I have not seen what you are working on yet.

Perhaps others on this list might have some opinions & thoughts as well?

In the meantime I would like to see what you are working on, and we can 
discuss this together and work towards an ideal approach.

Thanks again for your interest and contribution to the lib389 project!

Mark
>



More information about the 389-devel mailing list