At last week’s Fedora Server Working Group meeting, we encountered some confusion as to what exactly a role should look like. We seemed to be of differing opinions, technologically, on how to implement the roles. I recommended that we take a step back and try to design the user experience that a role should accomplish first. I recommended that we probably wanted to take one example and provide a user story for it and use that as a straw-man to work out the more general cases of server roles.
What is FreeIPA?
FreeIPA is a comprehensive identity-management and domain controller system, providing LDAP and Kerberos services.
How would I get it up and running?
In the world of Fedora 20 and earlier, the expected behavior would be that the user would first install the appropriate set of packages (either as part of installation using the GUI or kickstart or by installing the packages manually using yum on a running system). They would then run a command-line tool (ipa-server-install) to perform the configuration and initial setup of the domain (being prompted with a lot of low-level information). Joining other machines to that new domain would then be done manually or via scripts using other command-line tools.
The process to enroll additional FreeIPA domain controllers (aka replicas) is very similar: install all of the patches and then run ipa-replica-install, providing the necessary configuration information in an answer file or interactive prompt.
The goal of the role-based approach would be to present the minimal amount of information to the user necessary to produce a working FreeIPA domain. Additionally, it should be easy to determine from a management console which machines are configured in this manner. For this proposal, I am going to use a hypothetical Cockpit role interface to describe and illustrate the process. Please note that these are mock-ups and not representative of a final design.
Once we connect to the machine, we would first want to examine the roles currently assigned to that machine.
Presuming that the FreeIPA/Domain Controller role is not already on the machine, we would then elect to deploy one there. (We’ll assume this is the first such machine now and defer discussion of replicas).
From here, we select the FreeIPA Domain Controller and proceed to query the user for the minimal set of information necessary to deploy a FreeIPA server.
Here, the minimal set of information is the domain name (which may be auto-guessed from the machine’s `hostname -d` as well).
The next step here shows the majority of the operations representative of my view of a role. It’s not enough to install the necessary packages and then leave things to the administrator to complete (or script) the setup. Up until this point, we are doing the information-gathering for a role deployment.
Here, we demonstrate the actual deployment of a role. At this point, Cockpit (or whatever other management tool we are using) should be relaying the gathered data to the managed system and the role-installation mechanism should take over. In the FreeIPA case, this means:
- Package Installation
- Hostname/Domain configuration
- Installation and configuration of the FreeIPA server (unattended execution of ipa-server-install)
- Opening of the appropriate firewall ports
- Configuring the services to start immediately and persistently
Once installation is complete, we should be able to view the status of the FreeIPA services through either the role or services tabs in Cockpit. This display should also include a link to the FreeIPA Web UI for full management.
Additionally, the role interface should also offer simplified deployment of descendant roles, such as adding DNS services to a FreeIPA domain, but that’s not currently represented in the mock-ups (due to time-constraints).
All images above are copyright “The Cockpit Project” and licensed CC-BY-SA 3.0.