[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/latest/journald/index.html

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/realmd/index.html
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_KerberosKeyDistributionCenter.html

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_profile-1.0.pdf

Simple Identity Management Profile
http://www.dmtf.org/sites/default/files/standards/documents/DSP1034_1.1.0.pdf

Role Based Authorization Profile
http://www.dmtf.org/sites/default/files/standards/documents/DSP1039_1.0.0.pdf

Certificate Management Profile
http://www.dmtf.org/sites/default/files/standards/documents/DSP1096_1.0.0.pdf

Integrated Access and Control Policy Management Profile
http://www.dmtf.org/sites/default/files/standards/documents/DSP1106_1.0.0_0.pdf

-- John
-- 
John