On 4.3.2014 14:23, Jerry Lundström wrote:
On 04 Mar 2014, at 13:59 , Petr Spacek <[email protected]> wrote:
OpenDNSSEC 2.x
==============
Naturally, we want to do key maintenance in a distributed manner :-)
The question is if you would accept patches adding support for LDAP backend to
OpenDNSSEC 2.x and patches supporting distributed operation (mainly in the
enforcer-ng).
I have looked into git/enforcer-ng/src/protobuf-orm and it seems that
everything is SQL-specific. Would you accept patches adding some abstraction to
the database interface?
Yes the current interface is very SQLish, I can see a few places where you
might be able to add another layer that would make a LDAP backend possible.
Could you be more specific? I would like to look at the code we are talking
about.
It would be even better to see some design document with database schema
description but I can't find one on https://wiki.opendnssec.org/ .
Maybe you can supply a patch (or parts of a patch) so we can get a betterview
> of what you want to do and discuss it further?
I can write some example code working with LDAP database if you tell me what
you want to see and what is the required schema/information in database.
I need to know something like this (the example is completely made up):
- A 'policy object' is represented as a row in table 'policies', database
schema is /here/ - i will transform it to LDAP schema somehow
- A key used for search (in WHERE clause) is only 'policyid'
- Required access patterns are:
-- Get all columns for given 'policyid' (What is the required representation?
Something dict-like? Protobuf object?)
-- Get list of pairs (policy id, policy name)
-- Remove policy with given 'policyid'
and so on.
Just a bit of a notice, we are currently discussing the usage of
> protobuf-orm and it may or may not be changed in the near future.
Could you tell me what are alternatives under consideration? What you like and
don't like about protobuf-orm? I'm curious if there is something fulfilling
you needs but not bound to SQL paradigm.
The next thing is key distribution. In long term, we plan to write and use a
SoftHSM equivalent backed with LDAP database and local cache for
key/certificate storage so key management/sharing will be solved transparently
from OpenDNSSEC's point of view.
Have you looked at SoftHSMv2 (https://github.com/opendnssec/SoftHSMv2) ? Maybe
make a LDAP backend for it would do for a distributed key management (just
guessing).
We are looking into it. My colleague Jan Cholasta (CCed) will write the
PKCS#11 interface for LDAP. One variant is to extend SSSD project
https://fedorahosted.org/sssd/
and re-use LDAP & caching & authentication capabilities from SSSD project.
Maybe we can share some code between SoftHSM v2 and SSSD PKCS#11 provider, we
will see.
Plain SoftHSMv2 is probably not the best use case because we plan to support
off-line operation and other things like that and we will want (I guess) to
re-use existing code.
So the main question is:
Would you accept patches for database backend abstraction and distributed
behavior (in enforcer-ng)?
Of course, we recently moved all our software to GitHub in order to better
handle submission of code.
Great. It will take some time before we get to writing some code (one or more
months) but we want to know if the idea is good or if we should search for
some other solution.
Looking forward to your pull requests! :)
BTW are proposed changes something that needs attention from "OpenDNSSEC
Architecture Board"? If so, who should I contact and how?
--
Petr Spacek @ Red Hat
_______________________________________________
Opendnssec-user mailing list
[email protected]
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
