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

[Petr Vobornik]

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

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