On 03/11/2014 11:33 AM, Petr Spacek wrote:
do we need to convert SQLite ? I thought in phase 1 we would have
scripts exporting from OpenDNSSEC database and store in ldap, then the
data already exist in ldap. We would ned to replace the sofhthsm module
by our own pkcs11 module using ldap dn directly
On 10.3.2014 12:08, Martin Kosek wrote:
On 03/10/2014 11:49 AM, Petr Spacek wrote:
On 7.3.2014 17:33, Dmitri Pal wrote:
I do not think it is the right architectural approach to try to fix
use case with one off solution while we already know that we need a
I would rather do things right and reusable than jam them into the
I want to make clear that I'm not opposed to Vault in general. I'm
proposed release boundaries.
the necessity of Vault from the beginning because it will delay DNSSEC
+1, I also now see number of scenarios where Vault will be needed.
One of the proposals in this thread is to use something simple for
(with few lines of Python code) and migrate DNSSEC with Vault when
available and stable enough (in some later release).
I understand that Vault brings a lot of work to the table. But let
us do it
We will have one huge release with DNSSEC + Vault at once if we to
right and if it does not fit into 4.0 let us do it in 4.1.
DNSSEC to the same release as Vault.
As a result, it would be harder to debug it because we will have to
something is broken because of:
- DNSSEC-IPA integration
- Vault-IPA integration
- DNSSEC-Vault integration.
I don't think it is a good idea to make such huge release.
"Release early, release often"
I must say I tend to agree with Petr. If the "poor man's solution" of
without Vault does not cost us too much time and it would seem that
is not going to squeeze in 4.0 deadlines, I would rather release the
solution in 4.0 and switch to Vault when it's available in 4.1.
This would let our users test the non-Vault parts of our DNSSEC solution
instead of waiting to test a perfect solution.
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.
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).
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:
- key imported/exporter:
Initial state before upgrade:
- N IPA 4.0 replicas
- N DNSSECKeyImporterv1 service instances (i.e. key distribution for
- 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
- stop OpenDNSSECv1 service
- stop DNSSECKeyImporterv1 service
- 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
- convert private keys from LDAP to Vault *but let them in LDAP for a
- 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.
b) Another replica with DNSSECKeyImporterv1 service exists:
- *Temporarily* run DNSSECKeyImporterv2 which will do one-way key
conversion from Vault to LDAP.
- 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).
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.
Freeipa-devel mailing list