Re: lib389 usage cheatsheet

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

 



On Mon, May 14 2018 at 13:16:02 +1000, William Brown <william@xxxxxxxxxxxxxxxx> wrote:
> On Fri, 2018-05-11 at 09:41 +0200, Simon Pichugin wrote:
>> Hi Thierry,
>> I agree with you, it was exactly my proposition :)
>> 
>> Keeping main python-ldap elements is important because we don't want
>> to implement or mask/wrap this basic functionality (like working with
>> controls, etc)
>> we just want to redirect them.
>> 
>> Ideally, we should make our admin library very intuitive for the
>> people
>> who already knows python-ldap and just LDAP concepts.
>
> The issue is that if we want to use python-ldap, we wouldn't have
> lib389. We'd just use raw ldap all over the place .... 
>
>> 
>> I will continue adding more information to the docs regarding
>> DSLdapObject
>> and I'll try to make it a bit closer to LDAP concepts (at least in
>> wording), I already have something in mind.
>> 
>> Thanks,
>> Simon
>
>> 1. I think it is okay to use instance.add_s and instance.modify_s
>>    for simple operations.
>
> The issue here is that Entry() isn't py3 safe. It also really limits
> what we can do, and the whole "dirsrv is a subclass of
> simpleldapobject" and intercepts operations to create Entry is just
> complex.
>
>> 2. If you'd like to make your life easier, you can use DSLdapObjects
>> API
>>    (and I'll help you with that)
>> 3. We should stop using old lib389 API because we don't support it
>> anymore
>>    and it will be depricated in the future. We should use
>> DSLdapObject
>>    instead and we should improve it if we don't like something about
>> it.
>
>
> The point of DSLdapObject is to:
>
> * capture knowledge of administration to an accessible api
> * To make a bridge between py2/3
> * to give a higher level abstraction that "raw ldap" (which is frankly
> unusable)
> * to allow the elimination of Entry() and the DirSrv subclassing of
> simple ldap object.
>
> So everytime you find your self writing ".add_s()" or ".modify_s()",
> it's REALLY LIKELY that an adminsitrator needs to do this too!
It's not just about CLI tools. Please don't forget about tests. There we
need fine-grained access to LDAP primitives to write correct
reproducers. High level abstractions can stand in a way and do not
*exactly* do what is required.
>
> And although it's more work to encapsulate this to dsldapobject, it
> means we have implemented it once and can re-use it - and the jump from
> dsldapobject to a cli tool is very very short. It also makes the new
> webui easier because that will need to access all those apis too!
>
> There is much more vision here in this api then maybe I let on. It's a
> much bigger scope than some convinence functions, it's actually a
> gateway to ldap administration to eliminate the unusability of ldap.
>
> Of course, given my history with lib389, I would strongly advise us to
> follow options 2 or 3. I'm also happy to write up and knowledge
> transfer anything needed for the team. (And I apologise deeply for my
> recent abscence on mailing lists, I was traveling, and needed some time
> off).
>
> Thanks,
>
> William,
>
> _______________________________________________
> 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx

Attachment: signature.asc
Description: PGP signature

_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx

[Index of Archives]     [Fedora Directory Announce]     [Fedora Users]     [Older Fedora Users Mail]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Review]     [Fedora Art]     [Fedora Music]     [Fedora Packaging]     [CentOS]     [Fedora SELinux]     [Big List of Linux Books]     [KDE Users]     [Fedora Art]     [Fedora Docs]

  Powered by Linux