Hello all,
In the last month, FreeIPA [1] team was discussing options for remote management and deployment of FreeIPA servers, replicas and clients. We see the OpenLMI as the transport layer of choice for that task. We would like to share our use cases with this list and hopefully get advise and recommendations about the ways we should take (and avoid reinventing the wheel).
In short, we have 2 main scenarios in mind: A) Extend FreeIPA Web UI&CLI and allow Administrators to easily enroll hosts in the network to FreeIPA install additional FreeIPA replica servers or control which services are supported by existing FreeIPA servers B) Allow deploying FreeIPA infrastructure from other tools, like Foreman
Drop down of the particular use cases we identified for the 2 main scenarios:
== FreeIPA management scenarios ==
A1) Retrieve status of a host User wants to detect what clients are available and enabled for OpenLMI and check whether they are already connected to FreeIPA. User interacts with FreeIPA Web UI/CLI that in turn invokes a remote OpenLMI call per system to check the state of the system. The system should be able to return at least following status: - I do not understand OpenLMI - I am not enrolled - I am enrolled with a particular domain of given type (FreeIPA, AD, LDAP, ...) - I am a FreeIPA server with following services configured (AD Trusts, Legacy clients, DNS, DNSSEC, PKI, Vault, ...), I am master server for following services (PKI/DNSSEC/...) - I am a FreeIPA server/client and I am in the middle of a particular deployment operation (see below)
As Stephen Gallagher already suggested, this should be able to work with SLP discovery protocol and query systems individually to be just a fallback. I think some of the data could be already retrieved via existing realmd provider [2] that John Dennis wrote.
A2) FreeIPA Client enrollment User wants to change a system into a FreeIPA client. User calls FreeIPA UI/CLI, that in turn connects to remote host over OpenLMI and checks the enrollment status. If the machine does not have FreeIPA client bits installed, command to enroll a client is issued. While this is happening status checks above should return status indicating that system is in process of becoming a client.
This is already mostly possible, as per Stephen's blog [3].
A3) FreeIPA Replica deployment User wants to promote a FreeIPA Client to a Replica. User calls FreeIPA UI/CLI, that in turn connects to a remote host over OpenLMI and issues a command for a client to become a replica. Client turns into a replica. While this is happening status checks above should return status indicating that system is in process of becoming replica.
Stephen suggested this should be implemented via Server Roles.
A4) FreeIPA Replica decommissioning User wants to remove a FreeIPA Replica. User calls FreeIPA UI/CLI, that in turn removes the replica from FreeIPA replication agreements, connects to a remote host over OpenLMI and issues a command for a replica to uninstall.
Stephen suggested this should be implemented via Server Roles.
A5) Configure FreeIPA service User wants to configure an optional service on FreeIPA server (DNS, AD Trusts, ...). User calls FreeIPA Web UI/CLI, that in turn connects to a remote host over OpenLMI and issues a command to install the service. While this is happening status checks above should return status indicating that system is in a process of installing a service.
Stephen suggested this may be implemented via Server Roles.
A6) Configure FreeIPA master service Some FreeIPA services require a single FreeIPA node in the infrastructure to be the master for that service and e.g. generate CRL in case of PKI service or generate DNSSEC keys in case of DNS service.
User wants to configure FreeIPA server as the new service master Server. User calls FreeIPA UI/CLI, that in turn connects to remote host over OpenLMI and issues a command to turn it in a master server for given service.
This is tricky, as for some services, it may be also necessary to connect to previous master server and turn it into regular server and do additional migration steps. While this is happening status checks above should return status indicating that system is in a process of configuring a master server.
A7) Log gathering User wants to send logs to e.g. Red Hat Access Portal using integration with FreeIPA Web UI. User selects a different server or client. FreeIPA server connects to a selected host over OpenLMI and inspects available logs. User then chooses logs to upload. Server then issues a command over OpenLMI to collect the chosen logs.
As per Stephen's info, log collection is under investigation in OpenLMI, though without a given time frame yet.
== Remote management systems scenarios ==
B1) Deploy cluster of FreeIPA servers User of a provisioning system invokes a UI/CLI that calls OpenLMI to deploy a cluster of several IPA servers. It is expected that it would connect to a chosen node, pass the required work plan that might include following information: list of nodes (by IP or names or MACs) with user names (if not Pegasus user) and passwords to use, admin and DM passwords, topology to use (full, ring, star, hub and spoke, etc). It is expected that the first node will process the work plan, install the first server, connect to other systems using use case A1, configures clients using A2 and promote them into replicas by using A3. Since this procedure takes time the provisioning system might fire the work plan and periodically check. In this case the head node should respond with the corresponding status: installing server, deploying clients, promoting clients to replicas, etc.
B2) FreeIPA Replica deployment User of a provisioning system invokes a UI/CLI that calls OpenLMI to deploy another replica in the existing cluster. This case is a sub case of B1 when provisioning system has a work plan to extend an existing cluster. In this case, it provides a modification work plan and then IPA node processes it using capabilities covered in section A.
B3) Create Trust relationship between FreeIPA and other domain (like Active Directory) User of a provisioning system invokes a UI/CLI that calls OpenLMI to get a status of the trust relations of a specific IPA domain. This is a slightly different type of status than covered in A1 as it needs to be exposed over OpenLMI only for external systems.
B4) Change Trust relationship between FreeIPA and other domain User of a provisioning system invokes a UI/CLI that calls OpenLMI to change trust relationships between a selected IPA realm and other AD forests. Required information is provided and corresponding trusts are added or removed.
==========================
This is the main set of use cases, we will be looking forward to your recommendation on how to address them with OpenLMI. We would be also interested whether you would recommend designing&implementing simply via our own CIM model, not integrated in DMTF ecosystem (i.e. mostly just implementing RPC interface) or rather going the hard way and follow the DMTF models and profiles?
[1] http://www.freeipa.org [2] http://www.openlmi.org/sites/default/files/doc/admin/openlmi-providers/0.4.2... [3] http://sgallagh.wordpress.com/2014/06/13/using-openlmi-to-join-a-machine-to-...
Thank you.
On 07/30/2014 02:42 PM, Martin Kosek wrote:
Hello all,
In the last month, FreeIPA [1] team was discussing options for remote management and deployment of FreeIPA servers, replicas and clients. We see the OpenLMI as the transport layer of choice for that task. We would like to share our use cases with this list and hopefully get advise and recommendations about the ways we should take (and avoid reinventing the wheel).
In short, we have 2 main scenarios in mind: A) Extend FreeIPA Web UI&CLI and allow Administrators to easily enroll hosts in the network to FreeIPA install additional FreeIPA replica servers or control which services are supported by existing FreeIPA servers B) Allow deploying FreeIPA infrastructure from other tools, like Foreman
Drop down of the particular use cases we identified for the 2 main scenarios:
== FreeIPA management scenarios ==
A1) Retrieve status of a host User wants to detect what clients are available and enabled for OpenLMI and check whether they are already connected to FreeIPA. User interacts with FreeIPA Web UI/CLI that in turn invokes a remote OpenLMI call per system to check the state of the system. The system should be able to return at least following status:
- I do not understand OpenLMI
- I am not enrolled
- I am enrolled with a particular domain of given type (FreeIPA, AD, LDAP, ...)
These three are already implemented.
- I am a FreeIPA server with following services configured (AD Trusts, Legacy
clients, DNS, DNSSEC, PKI, Vault, ...), I am master server for following services (PKI/DNSSEC/...)
- I am a FreeIPA server/client and I am in the middle of a particular
deployment operation (see below)
These two are not. AFAIK realmd does not report 'I'm in the middle of a particular operation', it just has synchronous 'join domain' method. And it does not support FreeIPA _server_ management.
As Stephen Gallagher already suggested, this should be able to work with SLP discovery protocol and query systems individually to be just a fallback. I think some of the data could be already retrieved via existing realmd provider [2] that John Dennis wrote.
A2) FreeIPA Client enrollment User wants to change a system into a FreeIPA client. User calls FreeIPA UI/CLI, that in turn connects to remote host over OpenLMI and checks the enrollment status. If the machine does not have FreeIPA client bits installed, command to enroll a client is issued. While this is happening status checks above should return status indicating that system is in process of becoming a client.
This is already mostly possible, as per Stephen's blog [3].
Almost. As I wrote, realmd does not report 'I am enrolling just now', thus OpenLMI provider does not report it too. [2] is really the complete API we provide for domain membership and you can see it's really simple one. We're open for suggestions and/or patches.
A3) FreeIPA Replica deployment User wants to promote a FreeIPA Client to a Replica. User calls FreeIPA UI/CLI, that in turn connects to a remote host over OpenLMI and issues a command for a client to become a replica. Client turns into a replica. While this is happening status checks above should return status indicating that system is in process of becoming replica.
Stephen suggested this should be implemented via Server Roles.
A4) FreeIPA Replica decommissioning User wants to remove a FreeIPA Replica. User calls FreeIPA UI/CLI, that in turn removes the replica from FreeIPA replication agreements, connects to a remote host over OpenLMI and issues a command for a replica to uninstall.
Stephen suggested this should be implemented via Server Roles.
A5) Configure FreeIPA service User wants to configure an optional service on FreeIPA server (DNS, AD Trusts, ...). User calls FreeIPA Web UI/CLI, that in turn connects to a remote host over OpenLMI and issues a command to install the service. While this is happening status checks above should return status indicating that system is in a process of installing a service.
Stephen suggested this may be implemented via Server Roles.
I am also inclined to implement A3-A6 as server role - you write the DBus API (for the role) and then anyone can use it, regardless if it is CLI, GUI (Cockpit) or remote API (OpenLMI).
Or, it doesn't need to be a server role, it may be IPA's own configuration API (DBus is preferred).
A6) Configure FreeIPA master service Some FreeIPA services require a single FreeIPA node in the infrastructure to be the master for that service and e.g. generate CRL in case of PKI service or generate DNSSEC keys in case of DNS service.
User wants to configure FreeIPA server as the new service master Server. User calls FreeIPA UI/CLI, that in turn connects to remote host over OpenLMI and issues a command to turn it in a master server for given service.
This is tricky, as for some services, it may be also necessary to connect to previous master server and turn it into regular server and do additional migration steps. While this is happening status checks above should return status indicating that system is in a process of configuring a master server.
Well, OpenLMI is just a remote API. It can do anything that someone writes providers for. Architecturally, the above is possible. Out of curiosity, how does your UI/CLI talk to remote nodes now?
A7) Log gathering User wants to send logs to e.g. Red Hat Access Portal using integration with FreeIPA Web UI. User selects a different server or client. FreeIPA server connects to a selected host over OpenLMI and inspects available logs. User then chooses logs to upload. Server then issues a command over OpenLMI to collect the chosen logs.
As per Stephen's info, log collection is under investigation in OpenLMI, though without a given time frame yet.
We do have simple API to read journald logs. It's not particularly fast (ssh + cat will always be much faster), but it _can_ iteratively read logs. See its API and use cases at:
http://www.openlmi.org/sites/default/files/doc/admin/openlmi-providers/lates...
Is it enough or do you need something better? We're open for suggestions here.
== Remote management systems scenarios ==
B1) Deploy cluster of FreeIPA servers User of a provisioning system invokes a UI/CLI that calls OpenLMI to deploy a cluster of several IPA servers. It is expected that it would connect to a chosen node, pass the required work plan that might include following information: list of nodes (by IP or names or MACs) with user names (if not Pegasus user) and passwords to use, admin and DM passwords, topology to use (full, ring, star, hub and spoke, etc). It is expected that the first node will process the work plan, install the first server, connect to other systems using use case A1, configures clients using A2 and promote them into replicas by using A3. Since this procedure takes time the provisioning system might fire the work plan and periodically check. In this case the head node should respond with the corresponding status: installing server, deploying clients, promoting clients to replicas, etc.
B2) FreeIPA Replica deployment User of a provisioning system invokes a UI/CLI that calls OpenLMI to deploy another replica in the existing cluster. This case is a sub case of B1 when provisioning system has a work plan to extend an existing cluster. In this case, it provides a modification work plan and then IPA node processes it using capabilities covered in section A.
B3) Create Trust relationship between FreeIPA and other domain (like Active Directory) User of a provisioning system invokes a UI/CLI that calls OpenLMI to get a status of the trust relations of a specific IPA domain. This is a slightly different type of status than covered in A1 as it needs to be exposed over OpenLMI only for external systems.
B4) Change Trust relationship between FreeIPA and other domain User of a provisioning system invokes a UI/CLI that calls OpenLMI to change trust relationships between a selected IPA realm and other AD forests. Required information is provided and corresponding trusts are added or removed.
I do not see any obvious obstacles in B1-B3, all should be possible. I am not sure if current OpenLMI realmd provider is good enough, it's quite primitive. The same applies to underlying realmd.
I would propose that someone from IPA looks if realmd (both the DBus service and OpenLMI API) is good enough and we can then together make the OpenLMI provider better.
For all the scenarios above, everything is possible, still it implies quite lot of work. CIM (and OpenLMI) is just remote API and someone has to implement the API.
==========================
This is the main set of use cases, we will be looking forward to your recommendation on how to address them with OpenLMI. We would be also interested whether you would recommend designing&implementing simply via our own CIM model, not integrated in DMTF ecosystem (i.e. mostly just implementing RPC interface) or rather going the hard way and follow the DMTF models and profiles?
DMTF does not say anything about AD or Kerberos server management. I would recommend to write your own models and make them as close to underlying implementation (DBus API or IPA libraries) as possible.
If CIM is just a protocol between various IPA components (e.g. GUI talking to remote IPA installation to turn itself to be a replica), it may be even proprietary, not documented and unstable. And it does not need to be CIM at all.
if CIM is used as public remote API to manage IPA, it _should_ be stable and somewhat generic to allow future modifications without breaking existing users of the API, but you know, sometimes is the best just to break the API. CIM allows versioning, so the client can check what version of the API remote server supports and adapt accordingly.
[2] http://www.openlmi.org/sites/default/files/doc/admin/openlmi-providers/0.4.2...
[resending because openlmi-devel list rejected post by non-member]
On 08/04/2014 07:48 AM, Jan Safranek wrote:
On 07/30/2014 02:42 PM, Martin Kosek wrote:
Hello all,
In the last month, FreeIPA [1] team was discussing options for remote management and deployment of FreeIPA servers, replicas and clients. We see the OpenLMI as the transport layer of choice for that task. We would like to share our use cases with this list and hopefully get advise and recommendations about the ways we should take (and avoid reinventing the wheel).
In short, we have 2 main scenarios in mind: A) Extend FreeIPA Web UI&CLI and allow Administrators to easily enroll hosts in the network to FreeIPA install additional FreeIPA replica servers or control which services are supported by existing FreeIPA servers B) Allow deploying FreeIPA infrastructure from other tools, like Foreman
Drop down of the particular use cases we identified for the 2 main scenarios:
== FreeIPA management scenarios ==
A1) Retrieve status of a host User wants to detect what clients are available and enabled for OpenLMI and check whether they are already connected to FreeIPA. User interacts with FreeIPA Web UI/CLI that in turn invokes a remote OpenLMI call per system to check the state of the system. The system should be able to return at least following status:
- I do not understand OpenLMI
- I am not enrolled
- I am enrolled with a particular domain of given type (FreeIPA, AD, LDAP, ...)
These three are already implemented.
- I am a FreeIPA server with following services configured (AD Trusts, Legacy
clients, DNS, DNSSEC, PKI, Vault, ...), I am master server for following services (PKI/DNSSEC/...)
- I am a FreeIPA server/client and I am in the middle of a particular
deployment operation (see below)
These two are not. AFAIK realmd does not report 'I'm in the middle of a particular operation', it just has synchronous 'join domain' method. And it does not support FreeIPA _server_ management.
As Stephen Gallagher already suggested, this should be able to work with SLP discovery protocol and query systems individually to be just a fallback. I think some of the data could be already retrieved via existing realmd provider [2] that John Dennis wrote.
A2) FreeIPA Client enrollment User wants to change a system into a FreeIPA client. User calls FreeIPA UI/CLI, that in turn connects to remote host over OpenLMI and checks the enrollment status. If the machine does not have FreeIPA client bits installed, command to enroll a client is issued. While this is happening status checks above should return status indicating that system is in process of becoming a client.
This is already mostly possible, as per Stephen's blog [3].
Almost. As I wrote, realmd does not report 'I am enrolling just now', thus OpenLMI provider does not report it too. [2] is really the complete API we provide for domain membership and you can see it's really simple one. We're open for suggestions and/or patches.
A3) FreeIPA Replica deployment User wants to promote a FreeIPA Client to a Replica. User calls FreeIPA UI/CLI, that in turn connects to a remote host over OpenLMI and issues a command for a client to become a replica. Client turns into a replica. While this is happening status checks above should return status indicating that system is in process of becoming replica.
Stephen suggested this should be implemented via Server Roles.
A4) FreeIPA Replica decommissioning User wants to remove a FreeIPA Replica. User calls FreeIPA UI/CLI, that in turn removes the replica from FreeIPA replication agreements, connects to a remote host over OpenLMI and issues a command for a replica to uninstall.
Stephen suggested this should be implemented via Server Roles.
A5) Configure FreeIPA service User wants to configure an optional service on FreeIPA server (DNS, AD Trusts, ...). User calls FreeIPA Web UI/CLI, that in turn connects to a remote host over OpenLMI and issues a command to install the service. While this is happening status checks above should return status indicating that system is in a process of installing a service.
Stephen suggested this may be implemented via Server Roles.
I am also inclined to implement A3-A6 as server role - you write the DBus API (for the role) and then anyone can use it, regardless if it is CLI, GUI (Cockpit) or remote API (OpenLMI).
Or, it doesn't need to be a server role, it may be IPA's own configuration API (DBus is preferred).
A6) Configure FreeIPA master service Some FreeIPA services require a single FreeIPA node in the infrastructure to be the master for that service and e.g. generate CRL in case of PKI service or generate DNSSEC keys in case of DNS service.
User wants to configure FreeIPA server as the new service master Server. User calls FreeIPA UI/CLI, that in turn connects to remote host over OpenLMI and issues a command to turn it in a master server for given service.
This is tricky, as for some services, it may be also necessary to connect to previous master server and turn it into regular server and do additional migration steps. While this is happening status checks above should return status indicating that system is in a process of configuring a master server.
Well, OpenLMI is just a remote API. It can do anything that someone writes providers for. Architecturally, the above is possible. Out of curiosity, how does your UI/CLI talk to remote nodes now?
A7) Log gathering User wants to send logs to e.g. Red Hat Access Portal using integration with FreeIPA Web UI. User selects a different server or client. FreeIPA server connects to a selected host over OpenLMI and inspects available logs. User then chooses logs to upload. Server then issues a command over OpenLMI to collect the chosen logs.
As per Stephen's info, log collection is under investigation in OpenLMI, though without a given time frame yet.
We do have simple API to read journald logs. It's not particularly fast (ssh + cat will always be much faster), but it _can_ iteratively read logs. See its API and use cases at:
http://www.openlmi.org/sites/default/files/doc/admin/openlmi-providers/lates...
Is it enough or do you need something better? We're open for suggestions here.
== Remote management systems scenarios ==
B1) Deploy cluster of FreeIPA servers User of a provisioning system invokes a UI/CLI that calls OpenLMI to deploy a cluster of several IPA servers. It is expected that it would connect to a chosen node, pass the required work plan that might include following information: list of nodes (by IP or names or MACs) with user names (if not Pegasus user) and passwords to use, admin and DM passwords, topology to use (full, ring, star, hub and spoke, etc). It is expected that the first node will process the work plan, install the first server, connect to other systems using use case A1, configures clients using A2 and promote them into replicas by using A3. Since this procedure takes time the provisioning system might fire the work plan and periodically check. In this case the head node should respond with the corresponding status: installing server, deploying clients, promoting clients to replicas, etc.
B2) FreeIPA Replica deployment User of a provisioning system invokes a UI/CLI that calls OpenLMI to deploy another replica in the existing cluster. This case is a sub case of B1 when provisioning system has a work plan to extend an existing cluster. In this case, it provides a modification work plan and then IPA node processes it using capabilities covered in section A.
B3) Create Trust relationship between FreeIPA and other domain (like Active Directory) User of a provisioning system invokes a UI/CLI that calls OpenLMI to get a status of the trust relations of a specific IPA domain. This is a slightly different type of status than covered in A1 as it needs to be exposed over OpenLMI only for external systems.
B4) Change Trust relationship between FreeIPA and other domain User of a provisioning system invokes a UI/CLI that calls OpenLMI to change trust relationships between a selected IPA realm and other AD forests. Required information is provided and corresponding trusts are added or removed.
I do not see any obvious obstacles in B1-B3, all should be possible. I am not sure if current OpenLMI realmd provider is good enough, it's quite primitive. The same applies to underlying realmd.
I would propose that someone from IPA looks if realmd (both the DBus service and OpenLMI API) is good enough and we can then together make the OpenLMI provider better.
For all the scenarios above, everything is possible, still it implies quite lot of work. CIM (and OpenLMI) is just remote API and someone has to implement the API.
==========================
This is the main set of use cases, we will be looking forward to your recommendation on how to address them with OpenLMI. We would be also interested whether you would recommend designing&implementing simply via our own CIM model, not integrated in DMTF ecosystem (i.e. mostly just implementing RPC interface) or rather going the hard way and follow the DMTF models and profiles?
DMTF does not say anything about AD or Kerberos server management. I would recommend to write your own models and make them as close to underlying implementation (DBus API or IPA libraries) as possible.
If CIM is just a protocol between various IPA components (e.g. GUI talking to remote IPA installation to turn itself to be a replica), it may be even proprietary, not documented and unstable. And it does not need to be CIM at all.
if CIM is used as public remote API to manage IPA, it _should_ be stable and somewhat generic to allow future modifications without breaking existing users of the API, but you know, sometimes is the best just to break the API. CIM allows versioning, so the client can check what version of the API remote server supports and adapt accordingly.
[2] http://www.openlmi.org/sites/default/files/doc/admin/openlmi-providers/0.4.2...
I don't agree that DTMF has nothing to say about Kerberos nor for that matter the type of things that IPA does. In 5 minutes of googling I came up with these, they are a reasonable starting point for further investigation concerning existing CIM models that would impact an IPA server and clients. I know there are more models that are relevant because I found them when I was researching in preparation for the realmd provider, this is just what I could find in a couple of minutes.
CIM_KerberosKeyDistributionCenter http://wbemservices.sourceforge.net/moftree/schema/CIM_KerberosKeyDistributi...
CIM_KerberosCredential http://schemas.dmtf.org/wbem/cim-html/2.39.0+/CIM_KerberosCredential.html
CIM_Identity http://schemas.dmtf.org/wbem/cim-html/2/CIM_Identity.html
Dell Active Directory Client Profile http://media.community.dell.com/en/dtc/attach/dcim-active_directory_client_p...
Simple Identity Management Profile http://www.dmtf.org/sites/default/files/standards/documents/DSP1034_1.1.0.pd...
Role Based Authorization Profile http://www.dmtf.org/sites/default/files/standards/documents/DSP1039_1.0.0.pd...
Certificate Management Profile http://www.dmtf.org/sites/default/files/standards/documents/DSP1096_1.0.0.pd...
Integrated Access and Control Policy Management Profile http://www.dmtf.org/sites/default/files/standards/documents/DSP1106_1.0.0_0....
-- John
On 08/04/2014 09:11 PM, John Dennis wrote:
On 08/04/2014 07:48 AM, Jan Safranek wrote:
On 07/30/2014 02:42 PM, Martin Kosek wrote:
This is the main set of use cases, we will be looking forward to your recommendation on how to address them with OpenLMI. We would be also interested whether you would recommend designing&implementing simply via our own CIM model, not integrated in DMTF ecosystem (i.e. mostly just implementing RPC interface) or rather going the hard way and follow the DMTF models and profiles?
DMTF does not say anything about AD or Kerberos server management. I would recommend to write your own models and make them as close to underlying implementation (DBus API or IPA libraries) as possible.
If CIM is just a protocol between various IPA components (e.g. GUI talking to remote IPA installation to turn itself to be a replica), it may be even proprietary, not documented and unstable. And it does not need to be CIM at all.
if CIM is used as public remote API to manage IPA, it _should_ be stable and somewhat generic to allow future modifications without breaking existing users of the API, but you know, sometimes is the best just to break the API. CIM allows versioning, so the client can check what version of the API remote server supports and adapt accordingly.
[2] http://www.openlmi.org/sites/default/files/doc/admin/openlmi-providers/0.4.2...
I don't agree that DTMF has nothing to say about Kerberos nor for that matter the type of things that IPA does. In 5 minutes of googling I came up with these, they are a reasonable starting point for further investigation concerning existing CIM models that would impact an IPA server and clients. I know there are more models that are relevant because I found them when I was researching in preparation for the realmd provider, this is just what I could find in a couple of minutes.
CIM_KerberosKeyDistributionCenter http://wbemservices.sourceforge.net/moftree/schema/CIM_KerberosKeyDistributi...
CIM_KerberosCredential http://schemas.dmtf.org/wbem/cim-html/2.39.0+/CIM_KerberosCredential.html
Well, yes, there are some classes that describe KDC & Kerberos ticket, but there is no profile for it, it seems abandoned. Look at them and you can reuse them if you find them appropriate, but it won't make you interoperable with others in any way.
CIM_Identity http://schemas.dmtf.org/wbem/cim-html/2/CIM_Identity.html
Simple Identity Management Profile http://www.dmtf.org/sites/default/files/standards/documents/DSP1034_1.1.0.pd...
Role Based Authorization Profile http://www.dmtf.org/sites/default/files/standards/documents/DSP1039_1.0.0.pd...
Certificate Management Profile http://www.dmtf.org/sites/default/files/standards/documents/DSP1096_1.0.0.pd...
Integrated Access and Control Policy Management Profile http://www.dmtf.org/sites/default/files/standards/documents/DSP1106_1.0.0_0....
These are profiles to describe users, groups, roles and policies. I got an impression that we're managing IPA server itself and not users and policies stored in it.
Dell Active Directory Client Profile http://media.community.dell.com/en/dtc/attach/dcim- active_directory_client_profile-1.0.pdf
This is Dell proprietary profile.
Jan
On 08/05/2014 09:28 AM, Jan Safranek wrote:
On 08/04/2014 09:11 PM, John Dennis wrote:
On 08/04/2014 07:48 AM, Jan Safranek wrote:
On 07/30/2014 02:42 PM, Martin Kosek wrote:
This is the main set of use cases, we will be looking forward to your recommendation on how to address them with OpenLMI. We would be also interested whether you would recommend designing&implementing simply via our own CIM model, not integrated in DMTF ecosystem (i.e. mostly just implementing RPC interface) or rather going the hard way and follow the DMTF models and profiles?
DMTF does not say anything about AD or Kerberos server management. I would recommend to write your own models and make them as close to underlying implementation (DBus API or IPA libraries) as possible.
If CIM is just a protocol between various IPA components (e.g. GUI talking to remote IPA installation to turn itself to be a replica), it may be even proprietary, not documented and unstable. And it does not need to be CIM at all.
if CIM is used as public remote API to manage IPA, it _should_ be stable and somewhat generic to allow future modifications without breaking existing users of the API, but you know, sometimes is the best just to break the API. CIM allows versioning, so the client can check what version of the API remote server supports and adapt accordingly.
[2] http://www.openlmi.org/sites/default/files/doc/admin/openlmi-providers/0.4.2...
I don't agree that DTMF has nothing to say about Kerberos nor for that matter the type of things that IPA does. In 5 minutes of googling I came up with these, they are a reasonable starting point for further investigation concerning existing CIM models that would impact an IPA server and clients. I know there are more models that are relevant because I found them when I was researching in preparation for the realmd provider, this is just what I could find in a couple of minutes.
CIM_KerberosKeyDistributionCenter http://wbemservices.sourceforge.net/moftree/schema/CIM_KerberosKeyDistributi...
CIM_KerberosCredential http://schemas.dmtf.org/wbem/cim-html/2.39.0+/CIM_KerberosCredential.html
Well, yes, there are some classes that describe KDC & Kerberos ticket, but there is no profile for it, it seems abandoned. Look at them and you can reuse them if you find them appropriate, but it won't make you interoperable with others in any way.
CIM_Identity http://schemas.dmtf.org/wbem/cim-html/2/CIM_Identity.html
Simple Identity Management Profile http://www.dmtf.org/sites/default/files/standards/documents/DSP1034_1.1.0.pd...
Role Based Authorization Profile http://www.dmtf.org/sites/default/files/standards/documents/DSP1039_1.0.0.pd...
Certificate Management Profile http://www.dmtf.org/sites/default/files/standards/documents/DSP1096_1.0.0.pd...
Integrated Access and Control Policy Management Profile http://www.dmtf.org/sites/default/files/standards/documents/DSP1106_1.0.0_0....
These are profiles to describe users, groups, roles and policies. I got an impression that we're managing IPA server itself and not users and policies stored in it.
Dell Active Directory Client Profile http://media.community.dell.com/en/dtc/attach/dcim- active_directory_client_profile-1.0.pdf
This is Dell proprietary profile.
Jan
Thanks to both for information. We indeed do not plan to investigate managing users and IdM components (services, certificates, users, RBAC, OTP, ...) at this point, we mostly care about deployment and deployment status of servers, replicas and clients.
From the references above, it seems our best show may be to "invent" the model
ourselves, potentially based on available, though not developed existing DMTF models.
Martin
On 08/05/2014 08:00 AM, Martin Kosek wrote:
Thanks to both for information. We indeed do not plan to investigate managing users and IdM components (services, certificates, users, RBAC, OTP, ...) at this point, we mostly care about deployment and deployment status of servers, replicas and clients. From the references above, it seems our best show may be to "invent" the model ourselves, potentially based on available, though not developed existing DMTF models. Martin
Fair enough, you just want to deploy IPA via CIM for the moment. But don't forget CIM has already defined a structure to represent services and more importantly classes of services. The question is are you going to try and fit into the model the governing standards body (DMTF) has defined or are you going to ignore it and roll your own incompatible *proprietary* non-standard implementation.
Here is a hint for something I had to learn the hard way. The DMTF site is remarkably poorly organized. If you're looking for existing classes and the profiles that define those classes there isn't an easy way to locate them (at least when I was working). So what I did was download ALL the mof's and then concatenated them together into a single file I could search in a text editor. That allowed me to find a class and also to see where it was being used. Once I found a class I was interested in I would then go back to the profiles and figure out which profile was referencing that class (which usually also gave a detailed explanation of the intended usage and how it fit into the larger scheme of things).
It is a tedious process but after a while you'll begin to realize there is a pattern. You'll also discover at some point someone at least tried to define things like authentication services, domain name services, credentials, etc. (most of which IPA is). In other words someone has previously tried to define a range of objects and more importantly the specific service (classes) that provide those objects (i.e. what IPA is). Now, whether that's all vapor specifications meant to be ignored or not is a question I can't answer. But on the other hand completely ignoring the specifications the governing standards body put into place that covers our specific technology area might be short sighted. I don't know. What I do know is it's really hard to figure out :-)
On 08/05/2014 02:36 PM, John Dennis wrote:
On 08/05/2014 08:00 AM, Martin Kosek wrote:
Thanks to both for information. We indeed do not plan to investigate managing users and IdM components (services, certificates, users, RBAC, OTP, ...) at this point, we mostly care about deployment and deployment status of servers, replicas and clients. From the references above, it seems our best show may be to "invent" the model ourselves, potentially based on available, though not developed existing DMTF models. Martin
Fair enough, you just want to deploy IPA via CIM for the moment. But don't forget CIM has already defined a structure to represent services and more importantly classes of services. The question is are you going to try and fit into the model the governing standards body (DMTF) has defined or are you going to ignore it and roll your own incompatible *proprietary* non-standard implementation.
I think that we should at least try to go the right way and only fall back to non-standard implementation when we could not go this way.
Here is a hint for something I had to learn the hard way. The DMTF site is remarkably poorly organized. If you're looking for existing classes and the profiles that define those classes there isn't an easy way to locate them (at least when I was working). So what I did was download ALL the mof's and then concatenated them together into a single file I could search in a text editor. That allowed me to find a class and also to see where it was being used. Once I found a class I was interested in I would then go back to the profiles and figure out which profile was referencing that class (which usually also gave a detailed explanation of the intended usage and how it fit into the larger scheme of things).
It is a tedious process but after a while you'll begin to realize there is a pattern. You'll also discover at some point someone at least tried to define things like authentication services, domain name services, credentials, etc. (most of which IPA is). In other words someone has previously tried to define a range of objects and more importantly the specific service (classes) that provide those objects (i.e. what IPA is). Now, whether that's all vapor specifications meant to be ignored or not is a question I can't answer. But on the other hand completely ignoring the specifications the governing standards body put into place that covers our specific technology area might be short sighted. I don't know. What I do know is it's really hard to figure out :-)
Hmm, makes sense to me - we should not just blindly implement own models. For me, it is still difficult to assess and scope how difficult this approach would be, we will probably simply need to dive in the related models first and see. Thanks for the tip and reasoning!
Martin
On Tue, 05 Aug 2014 15:47:18 +0200 Martin Kosek mkosek@redhat.com wrote:
On 08/05/2014 02:36 PM, John Dennis wrote:
On 08/05/2014 08:00 AM, Martin Kosek wrote:
Thanks to both for information. We indeed do not plan to investigate managing users and IdM components (services, certificates, users, RBAC, OTP, ...) at this point, we mostly care about deployment and deployment status of servers, replicas and clients. From the references above, it seems our best show may be to "invent" the model ourselves, potentially based on available, though not developed existing DMTF models. Martin
Fair enough, you just want to deploy IPA via CIM for the moment. But don't forget CIM has already defined a structure to represent services and more importantly classes of services. The question is are you going to try and fit into the model the governing standards body (DMTF) has defined or are you going to ignore it and roll your own incompatible *proprietary* non-standard implementation.
I think that we should at least try to go the right way and only fall back to non-standard implementation when we could not go this way.
If the DMTF model doesn't fit your use case well, just ignore it. Don't try too hard to implement it. You may try to find out if anybody is actually implementing the model you choose. If not... What's the point in trying to be compatible when there is nothing to be compatible with? Being first is no big win for you here. Might be a loss for your users if you make too many usability compromises just to conform to an useless standard.
Regards,
On 08/15/2014 10:16 AM, Tomáš Smetana wrote:
If the DMTF model doesn't fit your use case well, just ignore it. Don't try too hard to implement it. You may try to find out if anybody is actually implementing the model you choose. If not... What's the point in trying to be compatible when there is nothing to be compatible with? Being first is no big win for you here. Might be a loss for your users if you make too many usability compromises just to conform to an useless standard.
You ask what's the point? Because standards are supposed to assure interoperability. Just because you're the first one to implement doesn't mean you get to ignore the standard. What happens when someone else does implement the standard? All of a sudden we're inoperable.
One of the major driving reasons we selected the DMTF technologies is because it was supposed to be an industry standard, implemented by multiple vendors and interoperable. If we have little intention of being interoperable then why are we using this **awful** technology instead of being a technology leader and producing something **sane** the community can rally around? (Sorry, I have a very low opinion of CIM, to me it's a classic example of what you get when standards bodies run amok, useless complexity that no one wants to use, including us apparently).
I have no illusions about the merits of committee designed standards. Most standards designed by committee stink and have poor adoption rates. If the fact is no one else has bothered to implement the models designed by the committee then I rest my case and reiterate why are we using this technology? But we have made a decision haven't we? We've hitched our wagon to DMTF and CIM. If that's the case then ignoring the standards published by the DMTF working groups doesn't make a lot of sense to me.
To my mind it boils down to this, either implement the standards as designed or give up on CIM and design something sensible that will become a standard by default, which is the way real standards are made. Look, if all we're really doing is treating CIM like a poor mans DBus (or pick your favorite RPC) and ignoring the models then why aren't we just using RPC and a per node broker? There are vastly better and simpler data exchange and RPC mechanisms that are currently in wide use with high adoption rates with multiple implementations on diverse OS's and numerous language bindings and already include essential features such as authentication (REST with JSON being one such example). What's missing? An agreed upon API. Well then let's define such a (REST?) API because if you're not going to follow the CIM "API" (i.e. the models) and design your own CIM API then what have you really accomplished other than being forced to use a data exchange and RPC mechanism that is truly horrible by contemporary standards?
It seems to me that CIM got some early uptake on Windows but I don't see any *serious* interest in CIM in the Unix/Linux space. Are people really flocking to this standard? Or do the existing implementations exist merely because it was the only thing available at the moment and those will likely atrophy due to disinterest?
You said it yourself, why "conform to a useless standard"?
Just my 2 cents.
On Fri, 15 Aug 2014 11:45:51 -0400 John Dennis jdennis@redhat.com wrote:
On 08/15/2014 10:16 AM, Tomáš Smetana wrote:
If the DMTF model doesn't fit your use case well, just ignore it. Don't try too hard to implement it. You may try to find out if anybody is actually implementing the model you choose. If not... What's the point in trying to be compatible when there is nothing to be compatible with? Being first is no big win for you here. Might be a loss for your users if you make too many usability compromises just to conform to an useless standard.
You ask what's the point? Because standards are supposed to assure interoperability. Just because you're the first one to implement doesn't mean you get to ignore the standard. What happens when someone else does implement the standard? All of a sudden we're inoperable.
We implement the standards where possible in OpenLMI. However quite often the models simply don't fit the real world. In such a case the best approach (IMO) is to bend the model according to the reality (or create a completely new one). Nothing stops you from going back to the DMTF then and propose a new standard: a one that actually works for somebody...
Regards,
openlmi-devel@lists.stg.fedorahosted.org
-
Jan Safranek -
John Dennis -
Martin Kosek -
Tomáš Smetana