[Freeipa-devel] DN patch and documentation

Rob Crittenden rcritten at redhat.com
Thu Aug 9 18:08:51 UTC 2012


Martin Kosek wrote:
> On 08/08/2012 11:02 PM, John Dennis wrote:
>> All the issues Martin discovered (except for the ip-address parameter) are now
>> fixed and pushed to the dn repo. Also now the dn repo is fully rebased against
>> master (except for one commit for ticket 2954 which I had to revert, see ticket
>> for details).
>>
>> Thank you for the continued testing.
>>
>> FYI: to use the dn repo:
>>
>> git clone git://fedorapeople.org/~jdennis/freeipa.dn.git
>> git checkout dn
>>
>
> Good. I see that all issues except the ipa-replica-prepare are now fixed. I
> verified that this is indeed an issue caused by the DN refactoring, I am
> attaching a patch fixing the issue. With this patch, ipa-replica-prepare issue
> disappears.
>
> Petr Vobornik also noticed an issue with trust-show command. I am attaching a
> patch with fix as well. We push the patches when we are pushing your work.
>
> I have not found any more show-stopping issues, so I will just continue my
> testing, and also give space to other testers in case they discover something else.
>
> Martin

I've been going through the diffs and have some questions in ldap2.py, 
these are primarily pedantic:

What is the significance of L here:

'2.16.840.1.113730.3.8.L.8'      : DN,  # ipaTemplateRef

There are quite a few assert isinstance(dn, DN). I assume this is mainly 
meant for developers, we aren't expecting to handle that gracefully at 
runtime?

It seems to me that allowing a DN passed in as a string would be nice in 
some cases. Calling bind, for example, looks very awkward and isn't as 
readable as cn=directory manager, IMHO. What is the downside of having a 
converter for these?

search_ext() has an extra embedded line which makes the function a bit 
confusing to read.

Do we need to keep _debug_log_ldap?

In search_ext_s() (and a few others) should we just return 
self.convert_result() directly?

In ldap2::__init__ what would raise an AttributeError and would we want 
to hide that fact with an empty base_dn? Is this attempting to allow the 
use of ldap2.ldap2 in cases where the api is not initialized?

In ipaserver/ipaldap.py there is a continuance of the assertions, some 
of which don't seem to be needed. For example, in toDict() it shouldn't 
be possible to create an Entry object without having self.dn be a DN 
object, so is this assertion necessary?

rob




More information about the Freeipa-devel mailing list