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

[Martin Babinsky]

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 doesn't make much sense to push this patch first and then rework the 
whole thing.

> 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?


-- 
Martin^3 Babinsky