On Tue, 2014-03-11 at 11:33 +0100, Petr Spacek wrote: > Yesterday we have agreed that DNSSEC support is not going to depend on Vault > from the beginning and that we can migrate to Vault later. > > Here I'm proposing safe upgrade path from non-vault to Vault solution. > > After all, it seems relatively easy.
Ok let me put my 2c in. > TL;DR version > ============= > Use information in cn=masters to detect if there are old replicas and > temporarily convert new keys from Vault to LDAP storage (until all old > replicas are deleted). I think this is not necessary, we do not support running an infrastructure for long times with mixed major IPA versions. So we should not need to do this. > Full version > ============ > IPA 4.0 is going to have OpenDNSSEC key generator on a single IPA server and > separate key import/export daemon (i.e. script called from cron or something > like that) on all IPA servers. > > In 4.0, we can add new LDAP objects for DNSSEC-related IPA services (please > propose better names :-): > - key generator: > cn=OpenDNSSECv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example As Martin said -> DNSSEC, the version is irrelevant here unless you are proposing to be able to run v1 or v2 conditionally with the same code base, if not then on upgrade the new openDNSSEC code will simply be upgraded like all other freeipa components. We do not capture version number for any of them. > - key imported/exporter: > cn=DNSSECKeyImporterv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example This is probably not needed as a separate key, if we are using systemd then we simply make one unit file depend on another so both start together in master, while on replica we only have 1 service to start anyway. If we are on sysv we will deploy our own init script that start both components at the same time on master, only one on replicas. The difference about what to start will be that only one master is configured as key generator, we do not even need to represent this in ldap in theory, because you cannot move the role by simply changing an LDAP entry anyway, and the difference can simply be a configuration file on the keygenerator master. > Initial state before upgrade: > - N IPA 4.0 replicas > - N DNSSECKeyImporterv1 service instances (i.e. key distribution for IPA 4.0) > - 1 OpenDNSSECv1 service instance (key generator) > > Now we want to upgrade a first replica to IPA 4.1. For simplicity, let's add > a > *requirement* to upgrade the replica with OpenDNSSECv1 first. (We can > generalize the procedure if this requirement is not acceptable.) I think we can proceed with this restriction for now, either tat or the admin is required to stop and unconfigure the key generator service anyway. > Upgrade procedure: > - stop OpenDNSSECv1 service > - stop DNSSECKeyImporterv1 service stpo DNSSEC (will stop both) > - convert OpenDNSSECv1 database to OpenDNSSECv2 > This step is not related to Vault. We need to covert local SQLite database > from single-node OpenDNSSEC to LDAP-backed distributed OpenDNSSEC. > > - convert private keys from LDAP to Vault *but let them in LDAP for a while*. This is only true *if* we'll decide to move storage to the Vault, we may not want to, or it may happen in a separate release. > - walk through cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example and check if there > are any other replicas with DNSSECKeyImporterv1 service: > a) No such replica exists -> delete old-fashioned keys from LDAP. I say we do this step unconditionally if we move to the vault, all other DNS server have functional keys for a while anyway (should always have at least 1 month autonomy), and we clearly state people must upgrade the infrastructure in a week not in months. So we should never need to keep old keys. > b) Another replica with DNSSECKeyImporterv1 service exists: > - *Temporarily* run DNSSECKeyImporterv2 which will do one-way key conversion > from Vault to LDAP. We do not need this, you must update all replicas to a vesion that knows what to do and then they'll find the new keys where they are. > - DNSSECKeyImporterv2 can check e.g. daily if all DNSSECKeyImporterv1 > instances were deleted or not. Then it can delete old-fashioned keys from > LDAP > and also stop itself when all old replicas were deleted (and compatibility > mode is not needed anymore). We also avoid this. The *only* thing we really need to do IMO is that if a DNS server finds out it's key for a zone are expired then it shuts down itself and makes itself unavailable so clients will start falling over to another DNS server and the admin will have to troubleshoot and resolve out why the keys were not accessible. If the reason is that they forgot to update a replica then they should just proceed and update and the DNS server will restart after that (we may want to make sure we have a way to pull the latest key at upgrade or we have chick egg issue where replica update fails because DNS does not start). > This approach removes time constraints from upgrade procedure and prevents > DNS > servers from failing when update is delayed etc. As a result, admin can > upgrade replica-by-replica at will. I want time constraints and I want DNS server to fail fast. constraints are in the order of 1 month though, not a few days. I think 1 month is sufficient. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipaemail@example.com https://www.redhat.com/mailman/listinfo/freeipa-devel