4:42 p.m.
IMHO, I think #3 is way too complicated. Complication invites issues
and confuse people.
Could we step back and try something simpler? When you copy the content
of one profile and modify it to create a new one, then it's a new
profile standing on its own. Why the parent-child relationship and
all? Seems like an administrator's nightmare. Maybe I missed out on the
irc discussion, but could you please give us a summary of the benefit
and how the benefit weights against development time and administration
maintenance, and support effort in the future on our end?
Anyway, I hope you will consider what I said in my earlier response. I
thought our goal was to provide a "centralized collection of profiles"
to ease administration effort. I hope we achieve simplicity rather than
create complication. It's just my personal preference.
thanks,
Christina
On 07/02/2014 02:02 PM, Endi Sukma Dewata wrote:
On 7/2/2014 12:17 PM, Ade Lee wrote:
> The problem with the above proposal is one of migration. Customers are
> used to both creating new profiles and modifying existing profiles to
> suit their needs. If we go along with this mechanism, we would have to
> tell these customers that they would need to rename their existing
> customized profiles (and update all the relevant clients etc.)
Just to clarify, so there are 3 proposals:
1. Stacked profiles (Fraser's proposal)
2. Pure LDAP profiles (Ade's proposal)
3. Separate file/LDAP profiles (my proposal)
As discussed over IRC, proposal #3 will be supplemented with a
mechanism to allow creating aliases for backward compatibility. I'm
trying to generalize the mechanism to become "profile inheritance".
Basically each LDAP profile will have an optional parent. The parent
can be the file-based system/default profile, or another LDAP profile.
A sub-profile will inherit all attributes, except when it's explicitly
declared in the sub-profile. This mechanism allows us to create just a
proxy/alias, a full clone, or anything in between. For example, a
proxy profile might only have a few attributes:
dn: cn=caAdminCert,ou=Profiles,ou=CA,{suffix}
objectClass: certProfile
cn: caAdminCert
parent: defaultAdminCert
visible: true
Let's say in the old system we have an unchanged caAdminCert and a
customized caUserCert. With proposal #1 we'll have:
1. caAdminCert (file)
2. caUserCert (LDAP)
3. caUserCert (file, inaccessible via REST due to the LDAP entry)
With proposal #2 we'll have:
1. caAdminCert (LDAP)
2. caUserCert (LDAP)
3. caAdminCert (file, for initial installation only)
4. caUserCert (file, for initial installation only)
With proposal #3 we'll have:
1. caAdminCert -> defaultAdminCert (proxy)
2. caUserCert (LDAP)
3. defaultAdminCert (file)
4. defaultUserCert (file)
The benefits of proposal #3 are:
1. The system/default profiles will be stored in /usr/share/pki.
People will be naturally discouraged to change them since it will be
overwritten during RPM upgrade. On the other hand, an LDAP profile,
although we can flag it as system profile or make it read-only, is
more tempting to change.
2. The original/unchanged system profiles will be accessible via REST
as well so people can use it directly and rely on auto update.
3. Backward compatibility can be maintained with proxy profiles. These
profiles will be updated automatically during RPM upgrade since it's
pointing to the file-based system profiles. No need to write upgrade
scripts.
4. The proxy profiles can be used to hide certain system profiles
without creating a full clone. With stacking, to hide caAdminCert we
probably would have to create a full clone then change the visibility,
and lose the auto update ability.
5. The mechanism can be used to extend/change the behavior of the
default profiles without having to create the full custom profile. For
example we want to create IPA-specific caUserCert with different
inputs. In this case we'll be able to just create a sub-profile with
the new inputs. No need to clone the entire profile.
> There is another problem, and that is that it is not clear that we want
> updates to the default profiles to be propagated to existing instances.
> I have looked at the profiles and there have been only a handful of
> changes over the last 7 years. Those changes include things like
> updating the default signing algorithms or the default validity. More
> likely than not, admins would prefer that we not change the behavior of
> profiles in existing instances underneath them.
>
> The changes that I have found are all behavioral - and therefore things
> that admin can opt out of -- or would prefer to do on their own
> schedule. There have been no structural changes.
>
> If there are structural changes, then we need to (and can) provide an
> upgrade script which would run with the automatic upgrade. An example
> of this would be a schema upgrade as we sort out how to represent
> profiles in LDAP.
As discussed, we're separating database changes into:
1. structural changes (e.g. schema change, adding/removing attributes)
2. behavioral changes (e.g. changing SHA1 to SHA512, default validity)
The structural changes will be semi-automatic. The admin decides when
to run them, but it's not necessary to review them one-by-one. The
behavioral changes should be reviewed by a security expert to make
sure that it won't affect their particular system negatively.
With proposal #3 the admin can decide whether to (a) trust us
(developers) to make the behavioral changes automatically by using the
default profiles directly or using proxy profiles, or (b) maintain a
full control of all behavioral changes using custom profiles. If all
profiles are in LDAP they might be limited to option (b) because the
upgrade script won't be able to tell whether the current value is a
default value that we can change, or it was intentionally set by the
admin.