[Freeipa-devel] [PATCH] 761 keytab manipulation permission management

[Petr Viktorin]

On 10/03/2014 05:02 PM, Martin Kosek wrote:
[...]
>> I like these the best. Maybe with a -to or -by suffix.
>>
>>>
>>> or if we expect more operations in a future:
>>>
>>> ipa host-allow-operation HOSTNAME --operation read-keys --users=STR
>>> --groups STR
>>> ipa host-disallow-operation HOSTNAME --operation read-keys --users=STR
>>> --groups STR
>>> ipa host-allow-operation HOSTNAME --operation write-keys --users=STR
>>> --groups STR
>>> ipa host-disallow-operation HOSTNAME --operation write-keys --users=STR
>>> --groups STR
>>>
>>> or if we want to keep 'add' and 'remove' in command names:
>>>
>>> ipa host-add-retrieve-keytab-right HOSTNAME --users=STR --groups=STR
>>> ipa host-add-create-keytab-right HOSTNAME --users=STR --groups=STR
>>> ipa host-remove-retrieve-keytab-right HOSTNAME --users=STR --groups=STR
>>> ipa host-remove-create-keytab-right HOSTNAME --users=STR --groups=STR
>>>
>>>
>>> personally I'm not a fan o the --operation switch, but could be
>>> persuaded by a 'future' usage.
>>
>> Not a fan either, because it is not consistent with the rest of the
>> framework.
>> Also, non-optional options are not really options.

To quote optparse docs:
> If there is a piece of information that your program absolutely  requires
> in order to run successfully, that’s what positional arguments are for.

How about something like:

ipa host-allow-operation HOSTNAME read-keys --users=STR --groups STR
ipa host-disallow-operation HOSTNAME read-keys --users=STR --groups STR
ipa host-allow-operation HOSTNAME write-keys --users=STR --groups STR
ipa host-disallow-operation HOSTNAME write-keys --users=STR --groups STR

> Right. Though mandatory options is a concept already existing in FreeIPA
> framework in many places. What I see as a deal breaker is that with
> --operation switch, we are ready for dozens of potential future
> operations. With operation hardcoded in command name, we are not.

Positional arguments (multiple *keys) also have their precedents, in DNS 
or automount plugins.

> Also note that framework internals can be changed more easily (to
> achieve more consistency) than API.
>
> Martin


-- 
Petr³