[Freeipa-devel] [PATCH 0090] show optionally configured components in server-find/show command output

Fri Nov 6 15:22:55 UTC 2015

On 11/06/2015 01:09 PM, Martin Babinsky wrote:
> On 11/06/2015 11:06 AM, Petr Vobornik wrote:
>> On 11/06/2015 10:15 AM, Petr Spacek wrote:
>>> On 6.11.2015 09:25, Martin Kosek wrote:
>>>> On 11/05/2015 07:02 PM, Petr Vobornik wrote:
>>>>>> On 11/02/2015 12:37 PM, Martin Kosek wrote:
>>>>>>>> On 11/02/2015 06:10 AM, Jan Cholasta wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> On 22.10.2015 10:44, Martin Babinsky wrote:
>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5181
>>>>>>>>>>
>>>>>>>>>> This should be handled by a separate object plugin:
>>>>>>>>>>
>>>>>>>>>> $ ipa servercomponent-find master.ipa.test
>>>>>>>>>> ---------------------------
>>>>>>>>>> 6 server components matched
>>>>>>>>>> ---------------------------
>>>>>>>>>>     Component name: CA
>>>>>>>>>>     Enabled: TRUE
>>>>>>>>>>     Start order: 50
>>>>>>>>>>
>>>>>>>>>>     Component name: KDC
>>>>>>>>>>     Enabled: TRUE
>>>>>>>>>>     Start order: 10
>>>>>>>>>>
>>>>>>>>>>     Component name: KPASSWD
>>>>>>>>>>     Enabled: TRUE
>>>>>>>>>>     Start order: 20
>>>>>>>>>>
>>>>>>>>>>     Component name: MEMCACHE
>>>>>>>>>>     Enabled: TRUE
>>>>>>>>>>     Start order: 39
>>>>>>>>>>
>>>>>>>>>>     Component name: OTPD
>>>>>>>>>>     Enabled: TRUE
>>>>>>>>>>     Start order: 80
>>>>>>>>>>
>>>>>>>>>>     Component name: HTTP
>>>>>>>>>>     Enabled: TRUE
>>>>>>>>>>     Start order: 40
>>>>>>>>>> ----------------------------
>>>>>>>>>> Number of entries returned 6
>>>>>>>>>> ----------------------------
>>>>>>>>>>
>>>>>>>>>> This will allow us to consolidate all the ad-hoc
>>>>>>>>>> component-related code
>>>>>>>>>> scattered throughout IPA (search for enable component,
>>>>>>>>>> enable/disable
>>>>>>>>>> component, ...) into IPA command calls.
>>>>>>>>>>
>>>>>>>>>> I'm not opposed to showing a summary in server-show (although
>>>>>>>>>> we don't do
>>>>>>>>>> anything like this for any other hierarchical objects), but it
>>>>>>>>>> should be done
>>>>>>>>>> just for the users' sake, not for internal use (the ticket
>>>>>>>>>> suggests to use this
>>>>>>>>>> for topology visualisation).
>>>>>>>>>>
>>>>>>>>>> BTW as far as the scalability of the current solution goes, you
>>>>>>>>>> should have a
>>>>>>>>>> list of all the *non*-optional components and display
>>>>>>>>>> everything else.
>>>>>>>>
>>>>>>>> The API proposal should be in line with our future extensions of
>>>>>>>> the API. We
>>>>>>>> for example want to move "ipa-csreplica-manage"
>>>>>>>> set-renewal-master command to
>>>>>>>> API call. Or DNSSEC generation master. Or we may want to change
>>>>>>>> some other
>>>>>>>> flag/role of a master via this interface.
>>>>>>>>
>>>>>>>> So we will need something like
>>>>>>>> $ ipa server-add-role ipa.example.com --role "ca-renewal-master"
>>>>>>>> or
>>>>>>>> $ ipa servercomponent-add-role ipa.example.com CA
>>>>>>>> --role=renewal-master
>>>>>>
>>>>>> Depends on usage. If we want to internally unify manipulation with
>>>>>> configs for
>>>>>> component we can create low-level commands which won't be exposed
>>>>>> to CLI.
>>>>>>
>>>>>> E.g. ipa servercomponent-find ipa.example.com
>>>>>> Component name: ADTRUST
>>>>>> Config: enabledService, startOrder 60
>>>>>>
>>>>>> <other services>
>>>>>>
>>>>>> This is all what Web UI needs.
>>>>>>
>>>>>>
>>>>>>  From user perspective, for CLI, something different is better.
>>>>>> Martin used term
>>>>>> 'role', lets go with that.
>>>>>>
>>>>>> Idea 1:
>>>>>> $ ipa server-show ipa.example.com --roles
>>>>>> Server name: vm-073.idm.lab.eng.brq.redhat.com
>>>>>>    Managed suffix: dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com,
>>>>>> o=ipaca
>>>>>>    Min domain level: 0
>>>>>>    Max domain level: 1
>>>>>>    Role: dns-server, cs-server, ca-renewal-master, trust-controller
>>>>>>
>>>>>> --all would imply --roles
>>>> I am thinking "Roles" could be printed out even in default listing.
>>>> It looks as
>>>> an important piece of information you want to know about your master.
>>>> I also
>>>> originally used that with servercomponent, you moved it to server
>>>> itself. It
>>>> makes also sense.
>>>>
>>>> We will need a design for this servercomponent/roles anyway, to agree
>>>> on the
>>>> API with all stakeholders.
>>>>
>>>>>> $ ipa server-add-role ipa.example.com --roles=ca-renewal-master
>>>
>>> Just keep in mind that 'role' design requires yet another layer of
>>> indirection
>>> because there is no 1:1 mapping between services and roles. E.g.
>>> 'DNSSEC key
>>> master' role consists of several services, as 'DNS server' role etc.
>>>
>>> Also, we can get into trouble because role 'DNS server' in IPA 4.2 can
>>> contain
>>> different set of services than 'DNS server' in IPA 5.0 etc.
>>>
>>> For these reasons I question necessity of 'role' abstraction. Is it
>>> worth?
>>>
>>
>> IMO yes. Current patch is better than nothing but roles are more
>> friendly, components are implementation detail.
>>
>> Showing only CNs on components doesn't show all info. E.g.
>>
>> ipa server-show `hostname`
>>    Server name: ipa.example.com
>>    Managed suffix: dc=example,dc=com, o=ipaca
>>    Min domain level: 0
>>    Max domain level: 1
>>    Optional components: CA, DNS, DNSKeySync, ADTRUST, EXTID, KRA
>>
>> This doesn't show that the server is actually also a ca-renewal-master.
>>   What is the command I can use to solve: "show me what server is the
>> ca-renewal-master"?
>>
> In that case we would IMHO need to redesign the whole service to LDAP
> mapping to incorporate server roles in some sane and scalable way. I'm
> not sure if that fits in the 4.3 timeframe. If yes, the we should first
> start with first putting the plumbing in and then adding API calls on top.
>

It is not a blocker for 4.3.

Issue here is that we are discussing implementation and API purity 
without use-cases. The result doesn't have to be something big in the end.

So far the only real use case was a consumption by Web UI for topology 
visualization. This definitely won't be part of 4.3. And Web UI will do 
exactly what I wrote here(hidden behind term "role".

Just display which servers are:
- vault backend (KRA)
- CS
- ca-renewal-master
- trust controller
- DNS server
- DNS key master

E.g. in form of icon (not-yet designed).

Second use case is displaying the same but in CLI (Idea 1 above).

This doesn't required any fancy refactoring. The only thing which needs 
to be agreed on is terminology.

> It doesn't make much sense to push this patch first and then rework the
> whole thing.

I agree.

I digged out some wip patch which could be actually enough (attached). 
It won't probably apply and the object name might not be the best.

>
>> Then what's the difference between ADTRUST and EXTID? One is smb, second
>> winbind but from user perspective it is the same thing - AD Trusts
>> controller.
>>
>> Could there be DNS without DNSKeySync?
>
>

-- 
Petr Vobornik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wip-freeipa-pvoborni-0747-add-serverservice-internal-commands.patch
Type: text/x-patch
Size: 7927 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20151106/ef55ef76/attachment.bin>