[Pki-devel] replication of new/modified profiles

Tue Jul 8 01:40:54 UTC 2014

On Mon, Jul 07, 2014 at 09:31:27AM -0700, Christina Fu wrote:
> Oh, and Fraser, Ade, and Endi, please keep
> https://fedorahosted.org/pki/ticket/1067 in mind when you implement the
> "replication of new/modified profile" so that they can seamlessly co-exist
> in the future.
> 

Sure thing, I will add a reference to the LDAP Profiles design
document.

There will be some similar questions as were raised for the hybrid
LDAP/files model, i.e. questions of precedence, or whether name
collisions are even allowed.  I don't see any fundamental issues,
though.

Cheers,

Fraser

> thanks,
> Christina
> 
> On 07/07/2014 09:21 AM, Christina Fu wrote:
> >Done.
> >https://fedorahosted.org/pki/ticket/1067
> >
> >thanks,
> >Christina
> >
> >On 07/07/2014 04:44 AM, Ade Lee wrote:
> >>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?
> >>>
> >>
> >
> >_______________________________________________
> >Pki-devel mailing list
> >Pki-devel at redhat.com
> >https://www.redhat.com/mailman/listinfo/pki-devel
> 
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel