On 09/04/2016 01:26 PM, Patrik Lundin wrote: > Hello again, > > Another question that popped up when digging around: I am not entirely > certain of the role of /var/opendnssec/enforcer/zones.xml. > >>From what I can tell from the migration steps it is used by the signer > and is supposed to be initally created by copying the old > /etc/opendnssec/zonelist.xml there.
First of all, the zones.xml and zonelist.xml are two completely different beasts. They have a relation, but never mix them up. 1.4 did not have a zones.xml file, but (inappropriately) used the zonelist.xml. In order to migrate, it is fine to copy the zonelist.xml to zones.xml as this will get you into the fist state. I think it will get more clear when I describe the purpose of the two files as it stands currently. As for the zones.xml; The signer needs to know which zones need to be processed. It needs to get this information from the enforcer, because the enforcer first needs to handle a zone, if to be done properly. There are a number of reasons why to pass this information not directly into the signer, but through the enforcer. The enforcer produces the zones.xml file upon changes. It is not intended to be manipulated from the outside. The zonelist.xml; There are basically two ways people like to use OpenDNSSEC. There are people that want the list of zones in use to be in a file, edit the file themselves and let OpenDNSSEC use this file as a source. When items are added or deleted from the file, then OpenDNSSEC should take the actions to add or remove the zones from further down the pipeline. This entails more than just drop the zone, and this is immediately a drawback. You cannot add a zone in a specific state, or drop a zone and keep the files (or not). For bootstrapping, it is nice though. Another set of people just want commands (CLI) to add or delete a zone, with options and control. These two modes are not easily mixed. When you add a zone using the CLI and also adding or removing zones from the zonelist.xml you have two conflicting sources of truth. In 1.4 it was tried to marriage the two believes, resulting in sometimes zones to be removed automatically from your system, when you did not intend this. When adding a zone though the CLI, the zonelist.xml would be updated automatically, but the existing zonelist.xml might actually not be in sync with the list of zones in the enforcer database. > It is then stated that zonelist.xml is no longer updated automatically, > meaning the enforcer database is the authoritative source of information > rather than that file. As stated in the example zonelist.xml: > === > As a result in 2.0 the contents of the enforcer database should be considered > the 'master' for the list of currently configured zones, not the zonelist.xml > file as the file can easily become out of sync with the database. > === Because of possible conflicts with the CLI and the zonelist.xml import, and to be clear that there is one list of zones, we declare that the list of zones as in use by the enforcer is authoritative. To enable the use case of the zonelist.xml editing, there are import, export and flags to the zone add/del to synchronize the zonelist.xml and enforcer zone listing. The import and export commands in fact always existed and needed to be called in the 1.4 usage also. So in fact, only when trying to mix both cases (which is tricky) it changed a bit. Both use cases (CLI and file based) are valid and need to be supported, however we want to advice not to mix them in normal use-cases. > Instead I notice that /var/opendnssec/enforcer/zones.xml will be created or > appended to when a zone is added with "ods-enforcer zone add --zone > example.com". > Why has this file been introduced? Doesn't the "can easily become out of sync > with the database" hold true for this file as well? Any change to existence of zones causes the zones.xml to be re-written. As adding or deleting zones in a normal setup is done through the enforcer, only the failure to write the file or an outside process manipulating the file (putting back a backup) could be the cause of this. We can't really fight those cases though. Previously, mixing CLI and file based zonelist.xml manipulation could mix up the understanding of the one true zone listing. >>From my perspective there are now two files: zones.xml which is (hopefully) > always in sync with the database, and zonelist.xml which _may_ be in sync with > the database based on operational procedures (running "ods-enforcer zonelist > export" from time to time or adding zones with --xml like "ods-enforcer zone > add --zone example.com --xml". > > 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. That said, the interaction between enforcer and signer is now too much of a mixed back. Not just the zones.xml, but there are other processes. I personally think this could be better. > 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. With kind regards, Berry van Halderen _______________________________________________ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
