[Pki-devel] db changes

[Endi Sukma Dewata]

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