[Freeipa-devel] [DESIGN] Server Roles

Fri Mar 18 14:28:45 UTC 2016

On 03/18/2016 02:59 PM, Simo Sorce wrote:
> On Fri, 2016-03-18 at 14:44 +0100, Petr Vobornik wrote:
>> On 03/18/2016 10:59 AM, Martin Kosek wrote:
>>> On 03/18/2016 10:47 AM, Martin Babinsky wrote:
>>>> On 03/18/2016 10:21 AM, Martin Kosek wrote:
>>>>> On 03/17/2016 06:16 PM, Martin Babinsky wrote:
>>>>>> Hi list,
>>>>>>
>>>>>> here is a link (http://www.freeipa.org/page/V4/Server_Roles) to WIP design
>>>>>> document concerning the concept of Server Roles as a user-friendly abstraction
>>>>>> of the services running on IPA masters.
>>>>>>
>>>>>> The main aim of this feature is to provide a higher level interface to query
>>>>>> and manipulate service-related information stored in dirsrv backend.
>>>>>>
>>>>>> I have not touched the design much from the post-Devconf session, mainly
>>>>>> because there are some points to clarify and agree upon.
>>>>>
>>>>> Initial thoughts:
>>>>>
>>>>> * Use Cases: these are rather vague points what you want to implement. In Use
>>>>> Case section, I would like to see what specific *user* use cases you are
>>>>> addressing, i.e. what user problems you are solving. Ideally in a form of a
>>>>> user story. Like here:
>>>>>
>>>>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Use_Cases
>>>>> or here:
>>>>> http://www.freeipa.org/page/V4/Authentication_Indicators#Use_Cases
>>>>> or here:
>>>>> http://www.freeipa.org/page/V4/External_trust_to_AD#Use_Cases
>>>>>
>>>> Ok I will thing of some clearer points.
>>>>
>>>>>> I have the following points to discuss:
>>>>>>
>>>>>> 1.) the design assumes that there is a distinction between roles such as DNS
>>>>>> server, CA, etc. and the more specific sub-roles such as DNSSec key master, CRL
>>>>>> master, etc. Now in the hindsight I think this distinction is quite artificial
>>>>>> and just clutters the interface unnecessarily. We might implement this kind of
>>>>>> hierarchy in the code itself but that is something the user needs not be
>>>>>> aware of.
>>>>>
>>>>> Well, there are dependencies. A server cannot be a CRL master without also
>>>>> being a CA role. I assume same applies to DNSSEC master.
>>>>>
>>>>> I think we need to think more about distinguishing what is role, what is just
>>>>> an attribute of a role, etc. AD for example distinguishes roles, role service
>>>>> and features:
>>>>>
>>>>> https://technet.microsoft.com/en-us/library/cc754923.aspx
>>>>>
>>>> We will have to implement the role/subrole/unicorn hierarchy anyhow. What I
>>>> would like to discuss is whether it is necessary to expose this hierarchy to
>>>> the users. Consider a case when user wants to find which server is a CA renewal
>>>> master:
>>>>
>>>> ipa server-role-find "CA renewal master"
>>>>
>>>> vs.
>>>>
>>>> ipa server-role-find --subrole "Renewal master"
>>>>
>>>> Behind the scenes, the code has to do the same thing (e.g. issue a search using
>>>> (&(cn=CA)(ipaConfigString=enabledService)(ipaConfigString=caRenewalMaster))),
>>>> but the UX is a bit different.
>>>
>>> Well, even the LDAP structure is different in this case. CA role is an object
>>> in cn=masters, caRenewalMaster is it's property. So they will likely be
>>> different user objects too.
>>>
>>> For your example, I can image a search like that:
>>>
>>> $ ipa server-role-find "CA" --subrole "renewal-master"
>>>
>>> (for the case when you have "DNS" role also with "renewal-master" sub-role).
>>>
>>> Martin
>>>
>>
>> I don't have a strong option about this matter.
>>
>> Number of roles will be limited. I don't see any point in developing
>> hierarchies in CLI/API/Web UI. Simply describing the roles and their
>> dependencies in server-role help should be enough.
>>
>> Hierarchy and dependency should be checked internally.
>>
>> Question is how it should behave in practice. There is no example in the
>> design page. Imagine these use cases:
>>
>> $ server-role-find
>> "CA"
>> "CA renewal master"
>> "DNS server"
>> "DNSSec Key Master"
>> ...
>>
>> maybe is should print also description, but help might be enough.
>>
>>
>> $ ipa server-role-enable $SERVER "CA renewal master"
>> Error: Server must have a "CA" role.
>>
>> $ ipa server-role-enable $SERVER "CA"
>> Error: run ipa-ca-install on $SERVER to enable the CA role
>>
>> Note: if in future we implement a privileged daemon then the
>> installation can be done by the daemon.
>>
>> # ipa-ca-install
>>
>> $ ipa server-role-enable $SERVER "CA"
>> INFO: Server already in CA role
>>
>> $ server-show $SERVER
>> ...
>> Roles: DNS Server, CA
>> ...
>>
>> $ ipa server-role-enable $SERVER "CA renewal master"
>> SUCCESS: $server is now "CA renewal master"
>> INFO: "CA renewal master" role was unset from $SERVER_PREVIOUS
>>
>> What is a purpose of `ipa server-role-disable`?
>>
>> If in future we need to configure a role then:
>>
>> $ ipa server-role-mod $SERVER $ROLE --fooattr=value (this is not
>> supported in FW now because the attrs might differ based on $ROLE)
>
> I am not sure why we use enable/disable verbs here, why not a simple
> add/remove ?
> enable/disabled usually means you can add a role but keep it disabled,
> or that you can keep a role installed and just disabled it, but that is
> not really the case.
>
The services should be moved only by installer code, I would prefer to 
only enable/disable roles (set the 
'ipaConfigstring=enbaledService/disabledService' for each service 
comprising the role).

This would not solve much in the current implementation (apart from 
marking the role o that master as disabled),but we discussed with Jan 
Cholasta that in the future we could have a small service running on 
each IPA master, monitoring changes in LDAP and doing stuff on the local 
system reflecting the state of LDAP tree.

With this service in mind, we could mark a role as disabled remotely, 
and the daemon running on the affected master would pick this up and 
disable all systemd services running on that host which comprise the role.

> Also I would like to draw attention to one other aspect.
> Roles != Services, in the list of roles for example I see memcached, it
> is in the list because you picked up all services and made a role out of
> them, but they are not all roles.
>
> in fact memcached is just an implementation detail of the framework and
> should not be mentioned at all (and in fact we are planning to stop
> using it altogether).
>
> Another "role" thaat should probably not exist is kpasswd, again kpasswd
> is there only because we required to start a separate service to
> implement its functionality, but semantically it is just an
> implementation detail of the KDC role. A master KDC will *always* have
> it, and in future, a Read Only KDC will not have it or use a different
> service that can proxy password change requests to a writable master, in
> any case an admin should not be able to "enable/disable" this role
> disjointly from the KDC role.

KDC, PASSWD, MEMCACHE, KEYS and few other should be either part of  some 
default role not exposed to the users or not used in the role concept at 
all. The mapping is several services -> single role so no, roles are not 
services.

>
> Finally, although the KRA is a separate Role it has a dependency on the
> CA Role, how is that expressed ?
>
That would be a part of implementation discussion I guess. I imagine 
roles having a hierarchy so that you e.g. could not mark a server as CRL 
master if his CA role is disabled. I should put together a prototype 
code illustrating this.

> Last but not least, why do we need a "role" concept ? Cab't we simply
> expose the running services ? If not, the reasons why need to be
> explained in the design page, as currently it only says that Role are
> introduced to expose the information, but it doesn't say why just
> exposing the information w/o changing any semantics is not desirable.
>
The problem is that if you just list only a list of services running on 
a master it can be quite hard for the user to know e.g. which services 
mean that the machine is a AD Trust controller (lemme check: ADTRUST, 
EXTID) or which CA is the renewal master (CA service is there and some 
ipaConfigString=caRenewalMaster attribute is set). IMHO it is a useful 
abstraction to hide these details and present them as "some roles that 
the master fulfills".

This abstraction also simplifies some steps migration of e.g. renewal 
master or DNSSec key master: Instead of searching for server with 
'ipaConfigString=caRenewalMaster' attribute, removing it from the entry 
and adding it to another CA master, you just call a single API command 
and be done with it.

> My 2c,
> Simo.
>

-- 
Martin^3 Babinsky