[Freeipa-devel] [PATCHES] Bring back old outputting functionality

[Rob Crittenden]

Pavel Zuna wrote:
> I compiled 3 patches, that effectively bring back all the functionality 
> we had before Jasons big patch (i.e. before introducing output 
> validation and the common output interface).
> 
> --all and --raw are back, but this time as global options
> replacing DNs with primary keys is back
> clever attribute printing (word-wrapping etc.) is back too
> 
> To implement --all and --raw as global options, we had to find a way to 
> propagate additional information (apart from command name and 
> parameters) from client to server. We extended the XML-RPC signature from:
> 
> (arg0, arg1, ..., options)
> 
> to:
> 
> (args, options, extras)
> 
> The extras dict is currently only filled with the 'print_all_attrs' and 
> 'print_raw_attrs' settings when forwarding a call. The server saves the 
> extras dict into the thread specific context variable.
> 
> I also replaced the decoding table in Encoder, because it didn't really 
> work as expected in special cases. It now uses a dont-decode function. 
> In the case of ldap2, this function checks attribute type OIDs and 
> returns False for binary types.
> 
> This patch introduces a little problem with the env command, because it 
> fixes a bug/feature, that made it work before. Before outputting an 
> attribute, we check if it isn't of type str. If it is, we assume it is 
> binary and decode it. All values in Env are str. I propose we either 
> write a specific output_for_cli for the env command or think about 
> switching from str to unicode. I tried the later and it didn't cause any 
> problems so far.
> 
> How it's supposed to work:
> 
> # ./ipa user-show admin
>   User login: admin
>   Last name: Administrator
>   Home directory: /home/admin
>   Login shell: /bin/bash
> 
> # ./ipa --all user-show admin
>   dn: uid=admin,cn=users,cn=accounts,dc=pzuna
>   User login: admin
>   Last name: Administrator
>   Full name: Administrator
>   Home directory: /home/admin
>   GECOS field: Administrator
>   Login shell: /bin/bash
>   Kerberos principal: admin at PZUNA
>   UID: 1083719807
>   GID: 1083719807
>   Last password change date: 20100208132706Z
>   Password expiration date: 20100509132706Z
>   Member of groups: admins
>   objectclass: top, person, posixaccount, krbprincipalaux, 
> krbticketpolicyaux, inetuser
> 
> # ./ipa --raw user-show admin
>   uid: admin
>   sn: Administrator
>   homedirectory: /home/admin
>   loginshell: /bin/bash
> 
> # ./ipa --all --raw user-show admin
>   dn: uid=admin,cn=users,cn=accounts,dc=pzuna
>   uid: admin
>   sn: Administrator
>   cn: Administrator
>   homedirectory: /home/admin
>   gecos: Administrator
>   loginshell: /bin/bash
>   krbprincipalname: admin at PZUNA
>   uidnumber: 1083719807
>   gidnumber: 1083719807
>   krblastpwdchange: 20100208132706Z
>   krbpasswordexpiration: 20100509132706Z
>   memberof: cn=admins,cn=groups,cn=accounts,dc=pzuna
>   objectclass: top
>   objectclass: person
>   objectclass: posixaccount
>   objectclass: krbprincipalaux
>   objectclass: krbticketpolicyaux
>   objectclass: inetuser
> 
> Pavel

Generally looks ok, have some questions though:

- We currently rely on the fact that binary objects are encoded as 
python str, it's how we determine what to base64-encode. What mechanism 
will we have to do that now?
- Is print_* the right prefix for these new global variables? It affects 
more than just printing in the case of all because it returns everything 
over XML-RPC as well.
- Is there/should there be a way for a plugin to define its own extras? 
And not to be too pedantic but is extras the best description for these 
values? Not that I have any suggestions for an improvement :-( Perhaps 
global_options?
- Why are you removing get_options() from LDAPSearch()?

It doesn't look like this is going to conflict too much with the 
parallel work I've done in regard to including member/memberof in return 
values, nor in the output work I've done. So you don't need to work on 
the individual plugins at all, I've got that ready in my tree though I'm 
going to hold onto it until we can get these patches committed.

rob