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

[Jan Cholasta]

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?

Honza

-- 
Jan Cholasta