[Opendnssec-user] OpenBSD porting questions regarding 2.x

[Berry A.W. van Halderen]

On 09/06/2016 06:16 PM, Patrik Lundin wrote:
> On Mon, Sep 05, 2016 at 02:08:13PM +0200, Berry A.W. van Halderen wrote:
>
>> [...]
>
> Thanks for taking the time to share information regarding the current
> state off affairs :).
>
>>> If the goal is to not have two places that may get out of sync, why
not have
>>> the signer fetch information directly from the database?
>>
>> The zones.xml solution is not holy.  And the current solution is very
>> much under discussion.  There are some drawbacks.  The current signer
>> does not need to know anything about the enforcer datastructures and
>> operation.  Synchronization between enforcer and signer is explicit,
>> so the enforcer 'tells' the signer when there are updates and the signer
>> does not need to monitor for changes.
>> Our database transactions can not be real simple, since there is only
>> one process doing changes.
>>
>> It is possible to run signer and enforcer on different systems, without
>> shared filesystem.  It is not unthinkable to make it possible to split
>> the signing over multiple machines in future.

Yes, but you need to make tooling for it, to transfer the files, and
the enforcer calls the signer CLI to inform it of changes. You should
also handle that. So it is possible, but your tooling probably needs
to change again with new releases. Since the enforcer does not need
to do a lot, there is little need for it. It is more interesting
to be able to use multiple signers on multiple machines, which should
need some support for the enforcer.
At the moment I would not split enforcer and signer over multiple
machines, as this makes the set-up more fragile.

>
> Just so I am following: is the above statement that it is possible to
> run signer/enforcer on different machines without a shared filesystem
> possible today? Or did you mean that it is possible given that the use
> of a file for synchronization (zones.xml) is traded for some other
> solution?
>
>>> Finally, what is the appropriate thing to do with zones.xml on a
fresh install?
>>> I notice an error is thrown since it is missing (not created by
>>> ods-enforcer-db-setup):
>>> ===
>>> Sep  4 12:31:22 obsd-amd64-t01 ods-signerd: [file] unable to stat
file /var/opendnssec/enforcer/zones.xml: ods_fopen() failed
>>> ===
>>>
>>> Is it standard operating procedure to get that error on a fresh
install, and
>>> then making the system happy with the addition of the first zone?
>>>
>>
>> I think that is a proper procedure for now.  Maybe it would be better
>> for the default "make install" to create the zones.xml?  I think
>> most people still just ignore this message.  In many use cases the
>> zonelist.xml (whether empty or not) is immediately imported and at
>> this time the zones.xml is created.  For pure CLI use, a human will
>> start with the first zone.  But it would be better that no warning
>> was generated here in this case.
>>
>
> Thanks for the info. At this point I have a bunch of diffs against
> 2.0.1 (as well as some runtime observations). I feel it would be
> good to discuss them prior to creating PRs since some may be
> interesting for merging upstream while others wont. Is there a
> suitable way for doing this? I could post on this this list but I am
> afraid it would cause a bunch of uninteresting noice for other members.
>

I'm not too worried about using the list for this for the moment. The
alternative would be to use Jira or a PR. If you use the same subject
in the mailing list that will make it easier for others.
If the list gets real busy, then we can change it.

\Berry