[Pki-devel] replication of new/modified profiles

[Christina Fu]

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.

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.

a few more comments in-line below...

On 07/02/2014 07:51 PM, Endi Sukma Dewata wrote:
> On 7/2/2014 1:09 PM, Christina Fu wrote:
>> In general, I think we all agree that putting profiles on ldap  is a
>> good idea.  However, in practice, I think we want to allow admins to
>> make changes to local files as they see fit.
>>   Please see my in-line response below.
>
> This is probably something that the admins will have to adapt 
> eventually. I think in a replicated environment we shouldn't treat 
> each server as unique individuals with "local" settings in files 
> (including profiles). From user's perspective all replicas should be 
> (mostly) identical. An admin, agent, or end entity should be able to 
> go to any replica and get the same services, see the same data, etc. 
> For this to work consistently, we want to minimize possible 
> misconfiguration, so the number of local files should be minimized. 
> The configuration (including profiles) should gradually be moved to 
> LDAP, and the CLI/UI will be the primary way to manage the configuration.

again, what I had in mind was a bunch of departments under the same 
organization where they might want to share some but customize some.

>
> To help the transition, CLI like proposed by Fraser could provide the 
> experience of editing a local file but it's actually stored on LDAP. 
> Also in the future the UI could provide an intuitive interface to 
> manage the profiles, so the admins will no longer need to memorize the 
> syntax of profile configuration file.

Yes to the CLI's and UI's.

>
>> Perhaps we can view files v.s. ldap as "localized" v.s. "centralized"
>> instead of "system" v.s. "customized".
>> Again, the benefit of putting profiles in ldap is so that it can be
>> configured once and utilized by many.
>> My comments below are based on such view.
>
> Let's call this proposal #4: Localized & centralized profiles. If I 
> understand this correctly, as an example server1 may have local 
> profile1 and profile2, server2 may have local profile1 and profile3, 
> then we have centralized LDAP profile1 and profile4. The profile1 in 
> server1, server2, and LDAP can be completely different although they 
> share the same name.

Yes.

>
>>> 1. Continue to provide the system profiles in files.  These files will
>>> be parsed and stored in LDAP when an instance is created.
>
>> if the ldap copies are the "centralized" ones, then we don't want to
>> override them at each installation of an instance. We could give admins
>> an option to override what's stored in ldap during configuration.
>
> I think the process to import the system profiles into LDAP should be 
> done only once regardless of the number of replicas. Otherwise, 
> suppose we removed one of the centralized profile (e.g. profile1), it 
> might get added again when we install another replica.
With proper access control in place, we should allow admins to do what 
they want to do in a reasonably convenient way.

>
>> When a profile with the same id exists in both ldap and local system,
>> then by default the one on ldap takes precedence. Although we could add
>> "per profile" config param for each instance to change the view
>> (remember the unix ns/yp config where you can set the order of the
>> source? so if "file" is 1st in the order, then the local ones have
>> priority, etc.)
>
> I don't have a lot of experience as system admin, but I think managing 
> individual machines is difficult so NIS (or LDAP, NFS, DNS, etc.) is 
> used to transition to a centrally managed system. The order of sources 
> is set up such that eventually everything can be moved into a single 
> source. For example, once we have NIS, we add new users in NIS instead 
> of locally on each machine (unless absolutely necessary) even if a 
> user might use a specific machine only.
again, I wasn't thinking of a strictly cloned environment.


>
>> With this, a site that has carefully crafted their profiles and stored
>> in ldap to share among all ca instances don't have to bother changing
>> anything for each ca instance created (because they are default to the
>> ldap).
>> Upgrade will also not affect the ldap copies inadvertently.
>
>>> 2. All profiles for an instance should live in LDAP.  This makes it
>>> simple - no need to check to see if a profile is in LDAP or files or
>>> both, and which has priority etc.  Tools will be provided to manage/
>>> create/delete profiles etc.
>
>> It might be simple, but we need to think about what's the value of them
>> existing in ldap and not being shared by others.
>
> What is the use case for having local profiles that will not or cannot 
> be shared with other replicas? If sharing the profile doesn't pose any 
> problem we might as well store "local" profiles in LDAP so they can be 
> handled more consistently.
again, I wasn't thinking of a strictly cloned environment.

>
>>> 3. Updates to system profile files will not affect the existing LDAP
>>> profiles.  We can provide update scripts or manual instructions for
>>> admins to run when they opt to do so.  This will be for behavioral
>>> changes.
>
>> so, in the view I specified above, update to the "local" profiles will
>> only affect the  instance where they exist, however, we can allow option
>> for admins to "publish" 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.  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 ;-)