[Pki-devel] replication of new/modified profiles

[Endi Sukma Dewata]

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.

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.

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

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

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

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

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

-- 
Endi S. Dewata