On Thu, 2014-07-03 at 12:59 -0500, Endi Sukma Dewata wrote:
On 7/3/2014 11:18 AM, Christina Fu wrote:
Actually, I did not know that this discussion was restricted to a replicated ("clone") environment. My view was more for a general organizational environment where there are multiple sub-ca's for different departments (which are not necessarily clones, but some could be) and there are two types of profiles: 1. centralized profiles (shared by all) 2. local profiles (customized by each department)
I think this view (let's adopt your term and call it proposal #4) is more flexible in serving both non-clones and clones and yet retains the simplicity.
Thanks for clarifying. Yes, the main purpose of this enhancement is to simplify replicating the profiles within a cluster (e.g. IPA). Proposal #4 is probably meant to be an inter-cluster profile management. Within a cluster itself, the replicas should be indistinguishable.
For example: * dept1 (cluster1: server1, server2): profile1, profile2 * dept2 (cluster2: server3, server4): profile1, profile3 * shared: profile1, profile4
I think proposal #4 can be done as a separate enhancement after we address the intra-cluster management (proposal #1-3).
Agreed. One of the things we would have to address, for instance, would be where the shared profiles would reside. Certainly it has to be a location that is available to all subCA's. Several possibilities come to mind: 1) under a baseDN 2) user-defined 3) in the security domain - particularly useful perhaps for storing customized system profiles to used during installation. Christina, can you open a ticket for this feature?
You are right, Endi, about how "local profiles" don't necessarily have to be on the disk. It's just a personal preference that I feel most comfortable editing files directly than using ui's. I have never used the java console to edit profiles. I don't know if there are others who feel the same way. Maybe a market research on administrators is needed here.
Here's the CLI that Fraser proposed: http://pki.fedoraproject.org/wiki/LDAP_Profile_Storage#Edit_profile
So instead of executing the following commands on each replica (and risking inconsistent changes):
$ vi /var/lib/pki/pki-tomcat/ca/profiles/ca/caUserCert.cfg $ systemctl restart pki-tomcatd@pki-tomcat.service
you can call this just once (it will use the same vi editor) from any machine:
$ pki <connection/auth params> profile-edit caUserCert
and it should automatically propagate the changes to all replica. Same thing with the UI, you'll only need to do the changes once.
Right, the idea is for the pki utility to spawn an editor -- we would likely default to "vi", but I suppose we could allow the user to specify others too. Ideally, what you would see is exactly the same as if you were editing a file today. The console would also continue to work, because it interacts with the ProfileSubsystem - which will know how to talk to LDAP.
The problem with local profiles in files is that they are not replicated, so in case the machine is hosed, all local settings is gone, including the profiles. Unless the admin created a backup for each machine, it will be difficult to restore the machine quickly. The replicated LDAP profiles will take care of this problem automatically. In other proposals the system profiles in files are read-only and not customizable, so there's no local profiles that need to be backed up.
If they don't do backups, losing profiles would not be their only issue there.
I think, ideally, if we lose a replica, other replicas should be able to replace it immediately. We still need a backup for the shared data/configuration, but we shouldn't need to backup individual replica. A replica should be something that you can add/remove relatively quickly. So, as a long term goal we should gradually migrate local configuration files into LDAP, starting with the profiles.
But anyway, like I said above, I think putting "local" profiles in the lda is fine. It's just the user experience of administration that has to change. I have no opinion on this other than stating my personal preference of editing files directly ;-)
Is the above CLI a good substitute?