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. > 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. -- Patrik Lundin _______________________________________________ Opendnssec-user mailing list [email protected] https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
