On 03/21/2016 09:02 AM, Martin Kosek wrote:
On 03/18/2016 03:43 PM, Martin Babinsky wrote:
On 03/18/2016 02:44 PM, 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
document concerning the concept of Server Roles as a user-friendly
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,
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
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
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
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"


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.

$ server-role-find
Certificate Authority
Manages certificate requests and revocation...
(optionally list masters)
Enabled on: master1.ipa.test, replica3.ipa.test

DNS Server
manages forward and reverse name resolution
Enabled on: master1.ipa.test

CA renewal master
Manages automatic renewal of certificates nearing expiration
Enabled on: replica3.ipa.test

Even though I disliked having renewal master as separate role and rather as a
property of existing CA role, this looks reasonable.

What plans do you have around the data model, that currently "CA renewal
master" and "Certificate Authority" roles are implemented completely
differently in cn=masters? (I mean LDAP entry vs. LDAP attribute) It would be
transformed during upgrade?

IMHO e may not need to touch LDAP structure at all if we use subtree search of LDAP entries. Consider the following search for CA renewal master: http://fpaste.org/343249/85492491/

I plan to use a set (meta)classes which will dynamically provide attributes and values to match against for each role.

The obvious disadvantage here is the additional DN manipulation to get the master entry itself.

But maybe I am missing something.

Also see Jan's reply to OP, he proposes that these singular "(sub) roles" be transformed into virtual attributes coupled to each role:

ipa server-find --dnssec-key-master/--ca-renewal-master=True
1 IPA server matched
  Server name: master1.ipa.test
  Managed suffixes: domain, ca
  Min domain level: 0
  Max domain level: 1
Number of entries returned 1

ipa server-role-show "DNS Server"
DNS server
manages forward and reverse name resolution
Enabled on: master1.ipa.test
DNSSec key master: master1.ipa.test

Also, how do you plan hiding the "services" we were not interested in seeing
(like KADMIN that Simo mentioned) from these commands?

I have updated the design page to mention this: there will be a default implicit IPA master role grouping the services that must be running on each master. This role will not be displayed in the UI.

Alternatively, since these services will not be part of any role the code which will perform the search for roles will simply ignore them.

Anyway, I think the best next step would actually be following Petr Spacek's
idea and start with designing the user interface (CLI) and all the proposed
commands that would solve the use cases Petr V. mentioned elsewhere.

That would help us assess the sanity and usability of the proposed approach.


Martin^3 Babinsky

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

Reply via email to