On 03/21/2016 09:28 AM, Jan Cholasta wrote:
On 17.3.2016 18:16, 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

I have not touched the design much from the post-Devconf session, mainly
because there are some points to clarify and agree upon.

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.

These shouldn't be (sub-)roles at all - they are inherently a
one-to-many relationship between the logical services and servers,
whereas roles are many-to-many relationship between the logical services
and servers. I would rather see them exposed in the global service
config, such as:

$ ipa dnsconfig-mod --sec-master=ipa12.example.com
   DNSSEC master: ipa12.example.com

2.) I guess the role names should be case insensitive so that users are
not hindered by trying to get the case right.


3.) Do we need an internal API call which will add all services
belonging to a role to the corresponding master entry? (basically a
'server_add_role' type of command). Currently, each service instance
adds its own service entry during service installation so we probably do
not need to duplicate this functionality.

+1, we don't need more duplicate code.

That is all I can think of right now. I had many more questions popping
up during this night's bout of insomnia, but they got lost during the

How are we going to expose the different states of server roles? They
can be:

a) available/unavailable (the package providing the role was/was not
installed on the server)
How would we query whether the package providing the role was installed? By trying to import the module(s) providing the package on the server side and catching the error? That could be manageable IMHO.

b) configured/unconfigured (the installer for the role was/was not
successfully run on the server, LDAP service entries exist)
Presence of LDAP entry would indicate that installer was run succesfully, although this is not guaranteed since the installer could crash *after* the entry was added to the service container.

c) enabled/disabled

My preference would be to make server-role commands work on top of
available services, like this:

# ipa server-role-show $HOSTNAME DNS
ipa: ERROR: DNS: server role not found

# dnf install freeipa-server-dns

# ipa server-role-show $HOSTNAME DNS
   Name: DNS
   Configured: False
   Enabled: False

# ipa-dns-install

# ipa server-role-show $HOSTNAME DNS
   Name: DNS
   Configured: True
   Enabled: True

Do not be afraid to bring up other questions/remarks/comments. This is
my first design documents so I expect them to be plenty.

The CLI commands are a little bit self-inconsistent, see any other
plugin for how the general layout of arguments should look like.

Ok I will fix that.

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