Re: [Pki-devel] replication of new/modified profiles

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.

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(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. >>> >>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 &gt;Pki-devel(a)redhat.com >https://www.redhat.com/mailman/listinfo/pki-devel _______________________________________________ Pki-devel mailing list Pki-devel(a)redhat.com https://www.redhat.com/mailman/listinfo/pki-devel