Re: [Pki-devel] replication of new/modified profiles
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).
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(a)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.
> 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?
--
Endi S. Dewata