[Freeipa-devel] [DESIGN] Server Roles

Fri Mar 18 14:58:03 UTC 2016

On Fri, 2016-03-18 at 15:28 +0100, Petr Vobornik wrote:
> 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 ?
> 
> 'Add' is fine with me. AFAIK, there is not use case for 'remove' now, 
> but in future it is probably OK.
> 
> > 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.
> >
> > 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.
> 
> I don't see them listed as a role in the design. They are just a service 
> of implicit 'master' role.

Sorry, then I misunderstood the page partially.

> >
> > Finally, although the KRA is a separate Role it has a dependency on the
> > CA Role, how is that expressed ?
> >
> > 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.
> >
> > My 2c,
> > Simo.
> >
> 
> I see roles as info for admins. Services are implementation detail.

Ok, I am just asking to explain why in the page, a couple of sentences,
no more.

> Use cases I see:
> 1. Administrator wants to know which servers are configured with 
> CA|KRA|DNS.
> 2. Administrator wants to know which server is CRL master.
> 3. We want this info to be able to display it in topology graph (but 
> this is for 4.5).

Ack, ack and ack.

> Should there be an NTP server role?

Probably.

-- 
Simo Sorce * Red Hat, Inc * New York