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