Rob Crittenden wrote:
Pavel Zuna wrote:
Rob Crittenden wrote:
Pavel Zuna wrote:
Rob Crittenden wrote:
Pavel Zuna wrote:
Rob Crittenden wrote:
The user plugin is crapping out on line 317 of ldap2.py because
attr is coming back None. The attribute it is looking for is member.
I think the fix involves setting member_attributes = ['member']
to the user plugin.
I wonder if we need to make the ldap2 plugin a bit more robust
too so it can handle it better if the schema lookup returns None.
rob
This should fix the issue.
Yes, this will fix it (I did a similar fix to work around it) but
what does it mean if there is no attribute found? Is that possible?
Should we catch it and return a more specific error message instead?
rob
If it doesn't find the attribute, PROBABLY nothing will happen...
Fortunately, we don't have to worry about it anymore. I played with
python-ldap a bit today and it seems to have the
convert_attr_synonyms functionality built-in. :)
Here's a replacement patch.
Pavel
nack. I don't see where python-ldap is replacing it. We weren't
seeing it done before were we?
That's because we were doing it wrong.
We were requesting all attributes ('*') + ACIs ('aci'). After this
patch we explicitly request all attributes in the new entry (i.e. all
attributes that are going to be updated) and python-ldap will always
return them named as they were requested. In other words: If we
request localityName as l, python-ldap will return it as l, if we
request it as localityName, python-ldap will return it as localityName.
Also, we need to request the 'aci' attribute for the aci plugin to work.
And we do so, because after this patch, we're requesting all
attributes explicitly.
Well, no, you're requesting all attributes in the current entry. The
code looked like this once before and caused the aci plugin to break. I
guess some other change fixed that, things are working as expected.
If by current entry you mean the dict containing the changes passed to
ldap2.update_entry then yes. When modifying ACIs, the 'aci' attribute is present
and therefore requested.
ack
rob
Pavel
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
