[Pki-devel] replication of new/modified profiles

[Christina Fu]

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 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