[Freeipa-devel] default / unexpressed / implicit values in LDAP and elsewhere

[Petr Spacek]

On 26.11.2015 14:58, Jan Cholasta wrote:
> Hi,
> 
> On 26.11.2015 14:17, Petr Spacek wrote:
>> Hello,
>>
>> The Problem
>> ===========
>> During work on DNSSEC patches for FreeIPA it repeatedly happened that I had to
>> hard-code default values for optional LDAP attributes to various places.
>>
>> A constant in code is a nice thing, but it does not help to CLI/WebUI/API
>> users because they do not see the default in ipa dnszone-show output etc.
>>
>> Moreover, even the constant does not help when multiple code-bases are using
>> the default value, e.g. bind-dyndb-ldap (written in C) and FreeIPA framework
>> (written in Python).
>>
>> What next?
>> ==========
>> I do not know :-) Following text is just boiling pure water.
>>
>> Simplest thing to do would be to create a Python module like
>> ipa.defaults and create a dictionary with defaults for each object class.
>>
>> I can imagine something like:
>>
>> idnszone = {
>>      'idnssecinlinesigning': False
>> }
>>
>> Then in Python code it would be easy to do
>> complete_object = ipa.defaults.idnszone.copy().update(object_from_LDAP)
>> And now the complete_object contains everything including optional (but in
>> fact not present) attributes which has a default value defined.
> 
> This would be very alien in the framework.
> 
>>
>> We might want to have some metadata for each attribute for various reasons.
>> E.g. some values should be only shown in WebUI and the attribute will be
>> populated, e.g. uid attribute is generated from first and last name when user
>> submits the form with empty 'uid' field. In other words, this default makes
>> sense on object creation but on when reading existing objects from LDAP.
>>
>> The example with uid obviously calls for something more fancy. When one
>> attribute is generated from other attributes of the same object, it might be
>> sufficient to define a regex based on other attributes. Regex is easy to
>> evaluate in C, Python and Javascript, if we limit ourselves to intersection of
>> regex languages supported by libraries of our choice.
>>
>> Now, we can take this dictionary and generate #define strings from it ...
> 
> Dynamic defaults would have to be fetched from the server with an API call.
> This will likely be part of the thin client / API compatibility feature.
> 
>>
>>
>> The open question is how to handle defaults taken from another object, e.g.
>> when idnsallowtransfer attribute is inherited from global DNS configuration
>> entry.
>>
>> Any ideas?
> 
> Is api.Object.dnszone.get_default() not sufficient?

Good! I wanted something like this :-) We can dig into it later.

-- 
Petr^2 Spacek