[Freeipa-devel] [PATCH] Modified ipa help behavior

Adam Young ayoung at redhat.com
Mon Dec 6 17:07:55 UTC 2010


On 12/06/2010 09:45 AM, Dmitri Pal wrote:
> Jan Zelený wrote:
>    
>> Rob Crittenden<rcritten at redhat.com>  wrote:
>>
>>      
>>> Jan Zelený wrote:
>>>
>>>        
>>>> Jan Zelený<jzeleny at redhat.com>   wrote:
>>>>
>>>>          
>>>>> Now each plugin can define its topic as a 2-tuple, where the first
>>>>> item is the name of topic it belongs to and the second item is
>>>>> a description of such topic. Topic descriptions must be the same
>>>>> for all modules belonging to the topic.
>>>>>
>>>>> By using this topics, it is possible to group plugins as we see fit.
>>>>> When asking for help for a particular topic, help for all modules
>>>>> in given topic is written.
>>>>>
>>>>> ipa help - show all topics (until now it showed all plugins)
>>>>> ipa help<topic>   - show details to given topic
>>>>>
>>>>> https://fedorahosted.org/freeipa/ticket/410
>>>>>
>>>>>            
>>>> Sorry for the wrong sequence number, sending the correct one now.
>>>>
>>>>          
>>> I think this is a good start but I find the output hard to read, both
>>> with a single topic (like user) or multiple (like sudo). The dashed
>>> lines and the extra spaces make my eyes cross a bit
>>>
>>> What I don't have is any good suggestion to change it up. I realize you
>>> are jamming together discrete things that may or may not look nice
>>> together.
>>>
>>> I suppose a few suggestions might be:
>>>
>>> - a SEEALSO-like where you print the topics at the bottom so it is
>>> obvious that multiple things are jammed together
>>> - A single dashed-line all the way across (more or less) with a single
>>> space before and after might be a less jarring separator. IIRC we have
>>> some output code that should handle screen sizes for you.
>>> - I'm not sure if combining all the commands into a single list is the
>>> right thing or not. It may not be necessary with the SEEALSO.
>>>
>>> So nack for now but this is headed in the right direction.
>>>
>>> rob
>>>
>>>        
>> After the last discussion at the meeting, I started to work on this again. The
>> goal is to implement suggested idea with SEE ALSO topics. But there is one
>> more issue to solve. It occurred to me that hbac topic would contain 3
>> subtopics: hbac, hbacsvc and hbacsvcgroup. Now the issue is when I type:
>>
>> ipa help hbac
>>
>> How should the program distinguish the topic hbac from the hbac subtopic? The
>> simplest solution here is to rename the module, but that doesn't seem right to
>> me. Other solution could be to rename the topic, but that would be against the
>> basic reason why we should implement topic grouping. Any suggestions?
>>
>> Frankly, I'm wonder if the topic-based grouping is worth the effort, but I have
>> an idea a little bit different from this approach. When typing
>>
>> ipa help hbac*
>>
>> user would receive a filtered list of topics, where only topics with module
>> name starting with "hbac" would be. The result would look like this:
>>
>> ipa help hbac*
>> Usage: ipa [global-options] COMMAND ...
>>
>> Help topics:
>>    hbac          Host-based access control
>>    hbacsvc       HBAC Services
>>    hbacsvcgroup  HBAC Service Groups
>>
>> The only limitation of this concept is that topic groups wouldn't be "stable".
>> For example the result of ipa help hbac would be different from ipa help
>> hbacsvc. Also some incorrect grouping might occur (host and hostgroup at the
>> moment). Before I start working on this, I'd like to know your opinions.
>>
>>
>>      
> May be use hbac for the high level topic group and hbacrule for the hbac
> rule management?
>    

+1.  I was going to sugget that myself.  We should rename the HBAC 
entity to HBAC Rule, and that makes Sudo and HBAC consistant.  Note that 
DNS2 does this, with the top level entity being the dnszone.

> This way there is no name collision. I do not know how big of a change
> it is and how it would affect UI/CLI/man etc.
> At this point of the project we need to try to minimize changes. It will
> affect SUDO too...
>
> Other approach might be to allow subtopics as another parameter:
>
> Usage: ipa help topic subtopic
>
> ipa help hbac hbac
>
> May be for the purpose of help we can do:
>
> ipa help hbac
> Usage: ipa [global-options] COMMAND ...
>
> Help subtopics:
>    rule          Host-based access control rules
>    service       HBAC Services
>    group         HBAC Service Groups
>
>
> ipa help hbac rule
>
>      ...
>
> ipa help hbac service
>
>      ...
>
> ipa help hbac group
>
>      ...
>
> Will that work? AFAIU this will not have any impact on the commands and
> would not require any changes to the UI/CLI other than to the help
> system itself.
>
> Thanks
> Dmitri
>
>    
>> Thanks
>> Jan
>>
>> _______________________________________________
>> Freeipa-devel mailing list
>> Freeipa-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-devel
>>
>>      
>
>    




More information about the Freeipa-devel mailing list