[Pki-devel] replication of new/modified profiles
Ade Lee
alee at redhat.com
Mon Jul 7 11:44:58 UTC 2014
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 at 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?
>
More information about the Pki-devel
mailing list