9:51 p.m.
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