11:18 a.m.
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 ;-)