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 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code