This is the workbench generator code v2.
The initial workbench was mostly generated by 1 script, and a bit of manual setup. An advantage of that approach was that it was easy to recreate everything, to add the initial data, and to get the system up relatively quickly. But its 'architecture' had reached the limits of its usefullness; every change meant everything that was generated had to be generated again, including every derived zone, every key, etc.
The process has now been split up into multiple parts, and most of them are able to only update their respective elements, so the rest can be left alone.
The directory layout is as follows:
- /ext External tools, scripts, paths, freeform layout.
- /libs Internal libs for shared code between scripts
- /generators Scripts that generate the data, each subdirectory is one 'type' of generator.
- /input Static input data
- /output Generated and copied data is placed below this directory
Prerequisites:
- ldns and ldns-dev
Steps to get it running:
(cd ext/ldns-3597; make)
(cd ext/ldns-sign-special; make)
./create_configs.sh
./create_zones.sh
Steps to create additional content:
- Write a generator (to get entries into the db), or add to an existing one
- Run the generator
- only adds/updates entries in the db
- Run the content-creator
- takes db entries, and depending on them, generates 'stuff' ?- Run the zone-creator ? * takes the db entries, and copies/updates/adds zone files
- Run the zone-completer
- for each zone that has a DS record, add it to the parent zone, if any
- also updates SERIAL if necessary
- Run the signer(s)
- takes the db entries and zone files, and signs or copies them
- Run the config creator(s)
- takes the db entries and generates config files
- publish the zones/update the configs
- dependent on target...
The zones will have a number of duplicates, for two reasons; it keeps the separation of the steps more clean, and it makes it easier to update only parts of them.
The zone files go through a couple of stages (and dirs):
- input/ if there is any input (optional)
- uncompleted/ before the completer is done
- unsigned/ before they are signed
- signed/ after they are signed (copied if they are not signed at all)
- final/ if no processor_script, simply copied, otherwise the processor should place them here
Generators take some (local) input (or not), and generate entries for the zone db. Every zone that ends up in the system should have an entry in a file in the zone_db directory. Generators are free to hard-code them or use their own input files (conventionally under input//). The output file is conventionally called <generator_name>.db, and placed in the output/zone_db directory.
The db files are simple textual representations (currently in CSV), as written by the ZoneData class. In practice, this means generators make ZoneData objects, and write them to the files. All later tools in the chain should take these ZoneData objects as inputs to generate other data and zones.
See the static_zone generator for a simple example.
Most raw zone data in found in the input/ directory; this directory contains full zones that can be used for input in some generators, but it also contains a template/ directory with zone chunks (such as a list with all the NS records). By convention, neither contains a hostname part, this will have to be filled in by the generator (@ is used, so origin or previous name will be used).
A lot of (intermediate) output is generated. In the end there are two directories that matter: output/signed/ and output/servers
output/signed contains all zones ('unsigned' zones are simply copied) for all servers. For convenience we don't differentiate between zones that are and are not served on each server at this point, but simply share this directory with all servers.
output/servers contains a subdirectory for each server, named by their shortname. These contain two files; a .conf and an update.sh. In most cases, the .conf is the configuration file, and update.sh simply contains the command to reload it. In certain exceptional cases (like bind10), the .conf contains a list of commands, and the script pipes them to the system (in this example, through bindctl).