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:

or here:
or here:

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:


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

ipa server-role-find "CA renewal master"


ipa server-role-find --subrole "Renewal master"

Behind the scenes, the code has to do the same thing (e.g. issue a search using
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).


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

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,

I see roles as info for admins. Services are implementation detail.

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).

Should there be an NTP server role?
Petr Vobornik

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to