Re: [Freeipa-devel] [DESIGN] Server Roles
On 12.4.2016 12:57, Jan Cholasta wrote: On 12.4.2016 10:45, Petr Spacek wrote: On 12.4.2016 09:31, Martin Babinsky 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. 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. 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. 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 day. Do not be afraid to bring up other questions/remarks/comments. This is my first design documents so I expect them to be plenty. Hi list, We had a discussion with Petr Spacek and Jan Cholasta about the possible utilization of server role implementation for the generation of location specific DNAME records.[1] The thing that would make Petr's life a bit easier is a plugin that would associate a certain role with a set of DNS RRs and would be able to spew out configured RRs for all masters on which the role is enabled. For example, for the implicit "IPA Master" role we would spit out all configured LDAP/Kerberos/Kpasswd SRV records. I have updated the design[2] to include CLI commands that will to this job, although I think it would be enough to just have them in API and to not expose them on the command line. Let me know what you think. I agree. Even user-visible API can be too much. Can we make this purely internal interface? +1, these should be commands at all, but rather a new type of plugin. ... should *not* be... -- Jan Cholasta -- 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
Re: [Freeipa-devel] [DESIGN] Server Roles
On 12.4.2016 10:45, Petr Spacek wrote: On 12.4.2016 09:31, Martin Babinsky 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. 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. 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. 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 day. Do not be afraid to bring up other questions/remarks/comments. This is my first design documents so I expect them to be plenty. Hi list, We had a discussion with Petr Spacek and Jan Cholasta about the possible utilization of server role implementation for the generation of location specific DNAME records.[1] The thing that would make Petr's life a bit easier is a plugin that would associate a certain role with a set of DNS RRs and would be able to spew out configured RRs for all masters on which the role is enabled. For example, for the implicit "IPA Master" role we would spit out all configured LDAP/Kerberos/Kpasswd SRV records. I have updated the design[2] to include CLI commands that will to this job, although I think it would be enough to just have them in API and to not expose them on the command line. Let me know what you think. I agree. Even user-visible API can be too much. Can we make this purely internal interface? +1, these should be commands at all, but rather a new type of plugin. -- Jan Cholasta -- 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
Re: [Freeipa-devel] [DESIGN] Server Roles
On 12.4.2016 09:31, Martin Babinsky 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. >> >> 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. >> >> 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. >> >> 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 day. >> >> Do not be afraid to bring up other questions/remarks/comments. This is >> my first design documents so I expect them to be plenty. >> > Hi list, > > We had a discussion with Petr Spacek and Jan Cholasta about the possible > utilization of server role implementation for the generation of location > specific DNAME records.[1] > > The thing that would make Petr's life a bit easier is a plugin that would > associate a certain role with a set of DNS RRs and would be able to spew out > configured RRs for all masters on which the role is enabled. > > For example, for the implicit "IPA Master" role we would spit out all > configured LDAP/Kerberos/Kpasswd SRV records. > > I have updated the design[2] to include CLI commands that will to this job, > although I think it would be enough to just have them in API and to not expose > them on the command line. Let me know what you think. I agree. Even user-visible API can be too much. Can we make this purely internal interface? > [1] http://www.freeipa.org/page/V4/DNS_Location_Mechanism > [2] http://www.freeipa.org/page/V4/Server_Roles > -- Petr^2 Spacek -- 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
Re: [Freeipa-devel] [DESIGN] Server Roles
On 8.4.2016 17:26, Martin Babinsky wrote: > On 04/07/2016 10:28 AM, Petr Spacek wrote: >> On 6.4.2016 16:37, Martin Babinsky wrote: >>> 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 > backend. > > 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. +1 > > 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 > day. 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) b) configured/unconfigured (the installer for the role was/was not successfully run on the server, LDAP service entries exist) 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. >>> >>> I have updated the design page[1] according to the comments gathered in this >>> thread and offline discussion with principal reviewer, e.g. Jan. >>> >>> Again comments are welcome. >>> >>> [1] http://www.freeipa.org/page/V4/Server_Roles >> >> Hi, >> >> I wonder if proposed service list->role and ipaConfigString value->server >> attribute mappings will work for DNSSEC key master. >> >> DNS server consist of named-pkcs11 and ipa-dnskeysyncd services. >> DNSSEC key master adds opendnssec and ipa-ods-exporter services. >> >> Can this be represented in the described model? I'm not sure. >> > Yes that is something I was not quite sure about whether DNSSec master is more > defined by the presence of ipaConfigString or by presence of relevant service > entries. > > We can do both approaches since the mapping between roles/attributes and > service entries has to be quite flexible anyway. This is up to you as long as we are able to represent it somehow :-) -- Petr^2 Spacek -- 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
Re: [Freeipa-devel] [DESIGN] Server Roles
On 04/07/2016 10:28 AM, Petr Spacek wrote: On 6.4.2016 16:37, Martin Babinsky wrote: 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 backend. 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. +1 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 day. 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) b) configured/unconfigured (the installer for the role was/was not successfully run on the server, LDAP service entries exist) 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. I have updated the design page[1] according to the comments gathered in this thread and offline discussion with principal reviewer, e.g. Jan. Again comments are welcome. [1] http://www.freeipa.org/page/V4/Server_Roles Hi, I wonder if proposed service list->role and ipaConfigString value->server attribute mappings will work for DNSSEC key master. DNS server consist of named-pkcs11 and ipa-dnskeysyncd services. DNSSEC key master adds opendnssec and ipa-ods-exporter services. Can this be represented in the described model? I'm not sure. Yes that is something I was not quite sure about whether DNSSec master is more defined by the presence of ipaConfigString or by presence of relevant service entries. We can do both approaches since the mapping between roles/attributes and service entries has to be quite flexible anyway. -- Martin^3 Babinsky -- 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
Re: [Freeipa-devel] [DESIGN] Server Roles
On 6.4.2016 16:37, Martin Babinsky wrote: > 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 >>> backend. >>> >>> 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. >> >> +1 >> >>> >>> 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 >>> day. >> >> 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) >> b) configured/unconfigured (the installer for the role was/was not >> successfully run on the server, LDAP service entries exist) >> 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. >> > > I have updated the design page[1] according to the comments gathered in this > thread and offline discussion with principal reviewer, e.g. Jan. > > Again comments are welcome. > > [1] http://www.freeipa.org/page/V4/Server_Roles Hi, I wonder if proposed service list->role and ipaConfigString value->server attribute mappings will work for DNSSEC key master. DNS server consist of named-pkcs11 and ipa-dnskeysyncd services. DNSSEC key master adds opendnssec and ipa-ods-exporter services. Can this be represented in the described model? I'm not sure. -- Petr^2 Spacek -- 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
Re: [Freeipa-devel] [DESIGN] Server Roles
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 backend. 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. +1 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 day. 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) b) configured/unconfigured (the installer for the role was/was not successfully run on the server, LDAP service entries exist) 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. I have updated the design page[1] according to the comments gathered in this thread and offline discussion with principal reviewer, e.g. Jan. Again comments are welcome. [1] http://www.freeipa.org/page/V4/Server_Roles -- Martin^3 Babinsky -- 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
Re: [Freeipa-devel] [DESIGN] Server Roles
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 backend. 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. +1 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 day. 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: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [DESIGN] Server Roles
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 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. $ 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
Re: [Freeipa-devel] [DESIGN] Server Roles
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 backend. 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. +1 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 day. 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) b) configured/unconfigured (the installer for the role was/was not successfully run on the server, LDAP service entries exist) 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. -- Jan Cholasta -- 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
Re: [Freeipa-devel] [DESIGN] Server Roles
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 >> 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. >> > $ 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? Also, how do you plan hiding the "services" we were not interested in
Re: [Freeipa-devel] [DESIGN] Server Roles
On 03/18/2016 03:58 PM, Simo Sorce wrote: > On Fri, 2016-03-18 at 15:28 +0100, Petr Vobornik wrote: >> On 03/18/2016 02:59 PM, Simo Sorce wrote: ... >> 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. +1. *This* is what I was looking for in the Design page Use Case section, that I mentioned in my first reply. The rest of the design page should be written with these use cases in mind. >> Should there be an NTP server role? > > Probably. > -- 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
[Freeipa-devel] [DESIGN] Server Roles
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. 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. 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. 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 day. Do not be afraid to bring up other questions/remarks/comments. This is my first design documents so I expect them to be plenty. -- Martin^3 Babinsky -- 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
Re: [Freeipa-devel] [DESIGN] Server Roles
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. Martin -- Martin^3 Babinsky -- 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
Re: [Freeipa-devel] [DESIGN] Server Roles
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) -- Petr Vobornik -- 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
Re: [Freeipa-devel] [DESIGN] Server Roles
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
Re: [Freeipa-devel] [DESIGN] Server Roles
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 -- 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
Re: [Freeipa-devel] [DESIGN] Server Roles
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 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. $ 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 ... $ 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`? As an administrator I need to hide a misbehaving CA master from the topology so that CSRs are not forwarded to it. E.g. 'role_disable' can be also called internally when a 'singular' role (renewal master) is migrated to other master. 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) -- Martin^3 Babinsky -- Manage your
Re: [Freeipa-devel] [DESIGN] Server Roles
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 ? 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. The services should be moved only by installer code, I would prefer to only enable/disable roles (set the 'ipaConfigstring=enbaledService/disabledService' for each service comprising the role). This would not solve much in the current implementation (apart from marking the role o that master as disabled),but we discussed with Jan Cholasta that in the
Re: [Freeipa-devel] [DESIGN] Server Roles
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
Re: [Freeipa-devel] [DESIGN] Server Roles
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 > 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 Martin -- 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
Re: [Freeipa-devel] [DESIGN] Server Roles
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
