[Freeipa-devel] user interfaces & default values = problem

[Martin Kosek]

On 02/11/2013 12:57 PM, Petr Spacek wrote:
> Hello list,
> 
> I realized one general problem we have with user interfaces for IPA & default
> values for various configuration options.
> 
> Let me use DNS dynamic update as an example:
> - We have "built-in" default configuration (disabled)
> - We have "global" configuration object (ipaDnsConfig)
> - We have "per-object" configuration (in each DNS zone)
> 
> IMHO user interface would be more usable if user can *see* which value is
> effective for particular service (and more generally any other object).
> 
> At the moment, command "ipa dnszone-show example.com" will not show "dynamic
> update" value if it is not configured in the zone itself.
> 
> E.g.
> [root at ipa1 ~]# ipa dnszone-show example.com
>   Zone name: example.com
>   Authoritative nameserver: ipa1.example.com.
>   Administrator e-mail address: hostmaster.example.com.
>   SOA serial: 1360583295
>   SOA refresh: 3600
>   SOA retry: 900
>   SOA expire: 1209600
>   SOA minimum: 3600
>   Active zone: TRUE
>   Allow query: any;
>   Allow transfer: none;
> 
> # No "Dynamic update" value is shown above ...
> 
> $ ipa dnsconfig-show
> [root at ipa1 ~]# ipa dnsconfig-show
> ---------------------------------
> Global DNS configuration is empty
> ---------------------------------
> 
> What is the built-in default? It is in bind-dyndb-ldap documentation ...
> 
> 
> It is hard to debug things when you can't *see* effective value. IMHO it would
> be good to add lines like:
>   Dynamic update: FALSE (inherited built-in default)
> and
>   Dynamic update: FALSE (inherited global configuration)
> 
> + some graphical representation of same thing to WebUI.
> 
> Exactly same problem applies to PAC type for each service etc, so some general
> solution would be nice.
> 
> Microsoft has something called "Resultant Set of Policy" for this purpose.
> 

Hello Petr,

in case of Dynamic update, we always configure the attribute with the setting,
we just do not show the attribute by default to not make the output
confusing... You need to pass --all option to show all zone configuration
settings, including update policy:

# ipa dnszone-show example.com --all
  dn: idnsname=example.com,cn=dns,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
  Zone name: example.com
  Authoritative nameserver: vm-037.idm.lab.bos.redhat.com.
  Administrator e-mail address: hostmaster.example.com.
  SOA serial: 1360583513
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  BIND update policy: grant IDM.LAB.BOS.REDHAT.COM krb5-self * A; grant
IDM.LAB.BOS.REDHAT.COM krb5-self
                      * AAAA; grant IDM.LAB.BOS.REDHAT.COM krb5-self * SSHFP;
  Active zone: TRUE
  Dynamic update: FALSE   <<<<<<<<
  Allow query: any;
  Allow transfer: none;
  nsrecord: vm-037.idm.lab.bos.redhat.com.
  objectclass: top, idnsrecord, idnszone

If people want to see this setting by default, we can of course show it by default.

As for the description - while text comments added to values look interesting:

>   Dynamic update: FALSE (inherited global configuration)

it is not so straightforward to be done in our framework. We try quite hard to
assign appropriate LDAP data types for different attributes which are then
encoded to appropriate native Python types in our framework. "Dynamic update"
is a BOOL type, so framework cannot return any text attached to it.

We now return this format:

{
    "error": null,
    "id": null,
    "principal": "admin at EXAMPEL.COM",
    "result": {
        "count": 1,
        "results": [
            {
                "error": null,
                "result": {
                    "dn": "idnsname=example.com,cn=dns,dc=example,dc=com",
                    "idnsallowdynupdate": [
                        "FALSE"
                    ],
                    "idnsallowquery": [
                        "any;"
                    ],
                    "idnsallowtransfer": [
                        "none;"
                    ],
                    ...
                },
                "summary": null,
                "value": "@"
            }
        ]
    },
    "version": "3.1"
}


To support what you propose, we would also need to to return something like
"meta-data" for the resulting dictionary returned by IPA server, for example as
another attribute in resulting dict:


{
    "error": null,
    "id": null,
    "principal": "admin at EXAMPEL.COM",
    "result": {
        "count": 1,
        "results": [
            {
                "error": null,
                "result": {
                    "dn": "idnsname=example.com,cn=dns,dc=example,dc=com",
                    "idnsallowdynupdate": [
                        "FALSE"
                    ],
                    "__rsop_idnsallowdynupdate": [
                        "inherited global configuration"
                    ],
                    ...
                },
                "summary": null,
                "value": "@"
            }
        ]
    },
    "version": "3.1"
}

... or in a separate tree:

{
    "error": null,
    "id": null,
    "principal": "admin at EXAMPEL.COM",
    "result": {
        ...
        },
    "meta": {
        "rsop": {
            "results": [
                {
                    "dn": "idnsname=example.com,cn=dns,dc=example,dc=com",
                    "idnsallowdynupdate": [
                        "inherited global configuration"
                }
                ],
            }
    }

Martin