On 5/31/2016 4:24 AM, Ade Lee wrote:
Hey guys,
I had some time during layovers/flights and threw a couple of ideas
together about how to handle the DB changes we have to perform for fine
grained authz and sub CAs, and other future changes ..
http://pki.fedoraproject.org/wiki/Tracking_db_migrations
Please take a look and comment.
Thanks,
Ade
This is a bit complex, but here's my initial thoughts:
1. I think we need more fine-grained trackers due to differences in how
the DS contents are shared and replicated. Please take a look at this
page: http://pki.fedoraproject.org/wiki/DS_Deployment_Scenarios
a) There should be a separate tracker for DS schema (e.g.
cn=schema,cn=trackers) since the schema is shared by all backends in the
same DS instance (unless the subsystems use separate DS instances) and
it's replicated to all clones.
b) There should be a separate tracker for DS configuration (e.g.
cn=config,cn=<DS hostname & port>,cn=trackers) since the configuration
is shared with all backends in the same DS instance (unless the
subsystems use separate DS instances), but it's not replicated to other
clones.
c) There should be a separate tracker for each subsystem subtree (e.g.
cn=ca,cn=subtrees,cn=trackers) since the subtree is not shared with
other backends, but it's replicated to all clones.
d) There should be a separate tracker for each subsystem indexes (e.g.
cn=ca,cn=indexes,cn=<DS hostname & port>,cn=trackers) since the indexes
are not shared with other backends and they are not replicated to other
clones.
2. I don't think global updates have to necessarily happen before local
updates. The upgrade scripts should have their own sequence number to
allow flexible execution order. The version numbers stored in the
trackers should be independent of each other, but the upgrade scripts
can enforce certain dependency. For example:
01-UpdateSchema
02-UpdateSubtreeToUseTheNewSchema
Script #1 will do something like this:
if schema.version < MIN_SCHEMA_VERSION:
update_schema()
Script #2 will do something like this:
if schema.version >= MIN_SCHEMA_VERSION:
update_subtree()
So if the schema was already updated while upgrading another subsystem,
the schema will not be updated again since the version number may
already meet the minimum requirement.
3. Although we don't have a top-level DN now, different PKI subsystems
using the same DS instance can share the same trackers stored in one of
the subsystem subtree. The base DN of the trackers can be stored in a
file in each PKI instance/subsystem, so it can be customized depending
on the deployment scenario. When we have the top-level DN in the future,
the trackers can be moved there too.
4. In the future there we might want to keep track of the optional
security upgrades as well:
https://fedorahosted.org/pki/ticket/1135
As shown in the example, at some point we might want to remove obsolete
algorithm (e.g. SHA1withRSA), but we cannot do that automatically since
some people might still depend specifically on it.
So these types of upgrades should be optional, they should not block
other upgrades, and the server should continue to function even without
these upgrades. However, we need to keep track of them to remind people
that in the future they will be required to do the upgrade.
This can be done by adding tracking entries under one of the above
trackers depending on the scope. For example:
cn=Remove SHA1withRSA from caAdminCert profile,
cn=ca,cn=subtrees,cn=trackers
assuming the profiles are in LDAP, or
cn=Remove SHA1withRSA from caAdminCert profile,
cn=ca,cn=config,cn=<DS hostname & port>,cn=trackers
if the profiles are still stored in locally in the CA subsystem that
uses the above DS instance.
Nothing to change in the design, but we just need to make sure this can
be done in the future.
--
Endi S. Dewata
_______________________________________________
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel
